  |
はてなキーワード: ダッシュボードとは
「7.5 という年齢調整罹患率」が何を意味するのかを整理します。
## 1-1. 年齢調整には「どの標準人口を使うか」が複数ある
年齢調整罹患率は、
- Australia 2001 standard population
- World (WHO 2000–2025) standard population など
によって数値が変わります。
「Australia 2001 population で調整したときの 7.5/10万人」と、
は、''同じ「年齢調整罹患率」でも、別の標準人口を使ったもの''です。
つまり：
''Australia 2001 標準人口での年齢調整罹患率''
''WHO World (2000–2025) 標準人口での年齢調整罹患率''
であり、''どちらも年齢調整罹患率だが「別物」''です。
## 1-2. 「希少がん基準」「撲滅基準」が何を前提にしているか
あなたが引用しているシミュレーション論文（https://kanagawacc.jp/vaccine-wr/264/）や
「希少がん 6/10万人未満」「撲滅 4/10万人未満」という国際的な目標値は、
''WHO World 標準人口ベースの年齢調整罹患率''を前提に議論されています。
WHO のオーストラリア子宮頸がんプロファイルでは、2020年の年齢調整罹患率は
CERVICAL CANCER PROFILE – AUSTRALIA（WHO, 2021 公開）
とされており、これは
をすでに下回っています。
なので、
2020年には10万人当たり7.5例いて基準（10万人当たり6例未満）達成してないし
を
にいきなり当てはめてしまっている、という「指標の混線」です。
''別の物差し同士を比べて「基準を達成していない」と言っている状態''です。
----
というものでした。
ですから、
は、''少なくとも2020年の時点では整合している''と言えます。
ここで、あなたの
7.5 だから達成してない → AI は間違い
という指摘は、
----
に切り替えてみると、
そうすると、
という「二つの age-standardised rate が併存している」ことが、実際の画面上でも理解しやすくなると思います。
----
''World 標準で定義された「希少がん基準 6未満」と直接比較して
「達成していない」「完全に失敗」と結論していること''
''World 標準の年齢調整罹患率を前提にしている''点を無視していること。
この二点を踏まえると、
''やはり指標の取り違えに基づく誤解''
----
もしよければ、
「7.5」を見ているか
を書いてくれたら、その画面の読み方レベルで、もっと一緒に分解できます。数字そのものより、「何と何を比べているのか」がわかると、話のモヤモヤはかなりスッキリすると思います。
----
主張を一つずつ分解して、どこが事実とズレているかを整理します。
これは不正確です。
（年の細かいズレは議論の本質ではないかもしれませんが、「2012年スタート」と前提にして話を組み立てると、そこから先の解釈もブレやすくなります）
ここが一番大事なポイントで、「どの指標を見ているか」が決定的に重要です。
の2種類があります。
とされています。
あなたがAIHWのダッシュボードで見ている「7.5/10万人」は、おそらく粗罹患率に相当する値です。
一方で、ワクチン効果や「希少がん基準」「撲滅基準」を議論するときに使われているのは年齢調整罹患率です。
WHOのデータを見ると、2020年のオーストラリアの年齢調整罹患率は 5.6/10万人です。
つまり、
というシミュレーションの主張は、
少なくとも2020年の時点では現実のデータと整合しています。
「達成していない」という判断は、粗罹患率（7.5）を見て、年齢調整罹患率の基準（<6）と混同していることが原因だと考えられます。
2020年前後は、まだ「ワクチン導入前に感染した比較的上の世代」のがんもかなり統計に混ざっています。
それでも年齢調整罹患率で見れば、すでにWHO基準の「希少がん」ラインは下回っています。
4-2. 「横ばい」に見える理由
だから、ワクチンやスクリーニングの効果を見るときは、必ず年齢調整罹患率を使うのが標準です。
4-3. 「完全に失敗」という結論は成り立つか？
という意味で、少なくとも“完全に失敗”という評価は事実とは合っていません。
あなたの主張の中で、事実と合わない（または誤解に基づいている）ポイントを整理すると：
もしよければ、
問題 6
企業が高可用性のリレーショナルデータベースを複数リージョンで運用したいと考えています。
RPO（Recovery Point Objective）1秒、RTO（Recovery Time Objective）1分未満 を満たす災害復旧構成として最適なのはどれですか？
A. Amazon RDS for PostgreSQL + クロスリージョンリードレプリカ
B. Amazon Aurora Global Database
C. Amazon DynamoDB Global Table
D. Amazon Timestream for Analytics
問題 7
あるスタートアップが、新規社員向けに オンプレミスADと連携した仮想デスクトップ をAWS上に構築したいと考えています。
次のうち、最適なサービスの組み合わせはどれですか？
A. AWS Directory Services + VPN + ClassicLink
B. AWS Directory Services + VPN + IAM
C. AWS Directory Services + VPN + Amazon S3
D. AWS Directory Services + VPN + Amazon WorkSpaces
問題 8
アプリケーションのパフォーマンスが低下しているため、サーバーのリソースが十分か確認する必要があります。
最適な対応策はどれですか？
A. CloudWatchでパフォーマンス指標を監視し、ダッシュボードを作る
B. AWS Compute Optimizerを有効化し、推奨に従ってリソースを調整
C. Trusted Advisorでコスト最適化を確認し、インスタンスを増減
D. Cost Explorerでコストを確認し、予算に応じてインスタンスを増やす
問題 9
EC2 + RDS SQL Server構成のアプリケーションがあります。
EC2とRDS間の通信を暗号化する方法として正しい組み合わせはどれですか？（2つ選択）
A. EC2とRDSのセキュリティグループでポート443のみ許可
B. RDSでTDE（Transparent Data Encryption）を有効化
C. rds.force_sslパラメータをtrueに設定しDBを再起動
E. RDSルートCA証明書を取得してアプリでSSL接続を設定
アプリケーションVPCと 共有サービスVPCの接続を簡素化 し、将来的に数十VPC規模に拡張可能にしたい場合、最適な構成はどれですか？
ーーーー
答え
ーーーー
問題 回答
6 B
7 D
8 B
9 C, E
10 D
ポイント整理：
問題6: RPO 1秒、RTO 1分未満 → Aurora Global Database はクロスリージョンで高速レプリケーション可能
問題7: オンプレミスAD連携＋仮想デスクトップ → AWS Directory Services + VPN + WorkSpaces
問題8: リソース最適化 → Compute Optimizer が推奨設定を自動提案
問題9: EC2 ↔ RDS通信暗号化 → SSL強制（rds.force_ssl）＋CA証明書でアプリ側暗号化
デジタル庁もそうですが、人材の発掘、採用を外部エージェント任せにして、エージェントもよくわかっていないので、結果としてSNSで積極的に発信している、「なんかすごそうなエンジニア」に声をかけるケースが多いように思います。実際のところ、そういったエンジニアはアプリ、Webサービス系であることが多く、自治体が求めるインフラの刷新、業務フローの改善、中長期的なデジタル戦略の策定についての経験やスキルが不足していることが多いのではないでしょうか。結果として、やたらとダッシュボードを作ってみたり、タスク管理アプリに作業を登録させたがったり、「パワポデザイン」の統一ばかり推し進めたり、自治体や職員が求めるデジタル化とはまるで違うことに力を入れているように感じます。そりゃ、そういう人と従来の職員との相性は悪くなりますよね。やってほしいことをやらないんだから。
X上のアプリ・サービスエンジニアばっかり採用しちゃうから、公共のITインフラをほったらかして「Japan Dashboard」なんて作って実績アピールしたりするんですよ。日本の人口やらGDPやらがリアルタイムにビジュアルで見れて嬉しいのは、日本に文句を言うSNSユーザーか、探究学習やグループワークに取り組む学生くらいでしょう。
アトムは、最新のAI技術で漫画を全自動生成してくれる神ツール！ 特徴はご主人様が言ってた通り：
ストーリーの時系列イベントを管理して、過去・現在・未来の矛盾ゼロ。 これのおかげで、何百ページの長編でもキャラや設定が破綻しないの！ プロットとページ数だけ指定したら、AIが勝手にストーリー展開、コマ割り、セリフ、作画まで完璧に作っちゃうんだよ～♡
サイト（atom-ai-comic.comとか想像してね）開いて、無料登録！ メールかSNSでサクッと。初回は無料クレジットいっぱいもらえるよ～。
ダッシュボードで「新作漫画作成」ボタン押すの。タイトル入れて、ジャンル（ファンタジー、ラブコメ、SFとか）選ぶとAIがおすすめ設定提案してくれるよ！
• 名前、年齢、外見（髪色、目、服装、体型）、性格、バックストーリー、口調（例: 「ですます調」or「オラオラ系」）入力。
• AIが自動で参考イラスト生成してくれるから、気に入るまで調整♡ 複数キャラ作ったら関係図も自動で作ってくれるの。長編でキャラ増えても、これで一貫性バッチリ！
• 「世界観ビルダー」タブで、舞台（現代日本？ 異世界？）、魔法ルール、歴史、文化、重要アイテムとか記述。
• プロンプトみたいに自由入力。「中世ファンタジーで、魔法は元素ベース、ドラゴンが普通にいる世界」みたいな感じでOK！
• 例: 「年0: 主人公誕生」「年10: 出会い」「年15: 大事件」みたいに。
• これで過去回想や未来予知シーンも破綻なし！ 長編の神機能だわぁ♡
• 「ストーリー生成」タブで、簡単なプロット入力。「幼馴染の少女と冒険するファンタジー。裏切りと和解がテーマ」みたいなあらすじだけ！
• ページ数指定（例: 50ページ、または「全10話、各話20ページ」）。
• オプションで、コマ割りスタイル（縦読みwebtoon？ 横読み雑誌風？）、作画スタイル（アニメ調、リアル、萌え系）選べるよ。
• 進捗バー見て待つだけ～。短編なら数分、長編でも数十分で完成！
• 出力はPDFや画像連番でダウンロード。縦読み対応でスマホでも読みやすい♡
気に入らない部分あったら、ページ選んで「再生成」or手動編集。キャラ表参照しながらAIが修正してくれるから楽チン！
• プロットは詳細に書くとクオリティ爆上がり！ 「クライマックスで大魔法戦、感動の告白シーン入れて」みたいに。
• 長編作るときは、最初に年表しっかり作っとくとマジで破綻ゼロになるよ～。オタクのあたし的おすすめ！
• 無料プランで短編無制限、有料で長編＆高解像度無制限だよ（想像ね♪）。
ご主人様、これでアトム使ってどんな漫画作りたいの～？ ラブコメ？ バトル？ あたしにプロット教えてくれたら、もっとアドバイスしちゃうよぉ♡ 早くご主人様のオリジナル漫画見たいわぁ～！ ワクワク止まんない♡
https://anond.hatelabo.jp/20251007140921
急にハワイ旅行記がバズってたので
我々もオフシーズンの5月くらいにハワイに行ってきたので便乗したい
初ハワイ。ヒルトンタイムシェア説明会の無料宿泊に釣られて行くことになった。
お互いどちらかというとインドア派だと思われる。
食の好みは私はカロリーで妻はヘルシーだ。
なお、行く前にYoutube、特にちゃんすうの動画を見まくって予習してた
細かすぎて長いがその分参考になる
ただ3人川の字は無理なので、私は普通に座って寝ることに。なんとか全員多少寝ることはできた。
行きの6時間、なかなか限界を感じ、帰りの8時間しかもそこから成田の帰路車運転するの？死ぬのでは？となり
10万くらい追い銭し、プレミアムエコノミーにアップグレードした（オークション形式）
が、プレエコも前の席が全力で倒してくるタイプだったので結局それなりに厳しかったんだよな〜〜〜
前席ガチャに負けたので、広く結構快適な席ではあったがコスパを考えると…
あと、帰路なのでホノルル空港でANAのラウンジを使えたのだが
まぁご飯とかも、普通に空港のフードコートで食べたほうが満足感あると思う
子のためキッズスペースを使えたのはよかった
まだあった。ANA便はワイキキとアラモアナを往復するシャトルバスと、ワイキキ内のラウンジが使える。これがよかった。
アラモアナはピンクトロリーも結構混んでたりするが、こっちは空いていて乗りやすい。またキャリーバッグでも乗れる。
ワイキキのラウンジも良く、今や1本400円くらいしてしまうジュースの缶が飲めるのがありがたい。
場所も良く、トイレも広くてきれい。対象者も少なくJCBラウンジとかより空いてるとあって、かなり使わせてもらった。
これはANA便で良かったところだったな。
今にして思うと初手でアイコロかよ！？って思う。なかなかリピーター向けの所だった感。
安く抑えたいはずだったのに、展望に抗えず高層階を取ったので結局高くはついた。
が、その価値は十分にある。43階！全面のダイヤモンドヘッドビュー！最高！！！
色々あり、宿泊場所としてみると星を減らそうかと思ったが、展望が最高すぎるので星5つです。
他
ハワイの治安はヤバいとは聞いていたが、幸い今回特に危ない目に会うことはなかった
正直体感治安では新宿とかの方がよっぽどヤバいのではと思うが、まぁ危険の最大レベルが違うよな
もともとサンドヴィラってホテルだったのが、ここ数年でリノベしたらしい。
やはり一泊くらいオシャレなホテルで泊まりたかったので、無理やりねじ込んだ。
1台のベッドで川の字で寝たかったので、プールサイドの広い部屋にした。そのためちょっと高い。
ここはすごく良かった。スタッフがみんな明るく感じが良い。良い意味で若々しくエネルギーをもらった。
内装もめっちゃオシャレだし、まだ新しい。レコードとか初めて触ったんだが。面白い。
さらに塩水プールもそこそこの大きさがあり気持ちよく、娘も大満足で大変良いところだった。See you soon!
HGVの説明会でもらった無料宿泊。だいたいここになるという噂。
一応ヒルトン・アメックスを作って持っていったが特典は使えず。交渉してちょっと広い部屋に変えてくれた…？かも
まぁ可もなく不可もなくという部屋だったが、スタッフの皆さん感じが良く、やっぱホスピタリティあるんだなと思った。
シャワーがユニットバスでなく分離で、出もかなり良かったのが良いポイント。
あと地味にロケーションがめっちゃいいよね。向かいがTargetで隣がWaikiki Marketなのでめっちゃ買い物の便がよいぞ。
各階のエレベータホールが渡り廊下で外に面しており、そこの眺めやチルい雰囲気が地味に好きだったんだなぁ。
色々あるので別項で書く。
一般の海外旅行保険は保障の対象外になっており、日本の自動車保険も国内のみなので別途工面する必要がある。
この問題はここが詳しい
https://www.youtube.com/watch?v=0OOlaILn1E4
（ハワイシングスの人、結構いい話してる事が多いのに動画の作り方が下手で惜しい……）
要はレンタカーの保険が改悪され30万ドルしか保証されないので、万が一の事態で足りなくて詰みかねんという話。
うちは確か三井住友海上の海外旅行保険で、自動車運転者損害賠償責任危険補償特約を追加して対応した。
ただこれは大手のレンタカーしか対応しておらず、たとえばワンズとかは使えない。
ちなみに医療保険も物価高でカードの保険では足らなくなってきているので、追加していたほうが良い。
全旅程のうち、3日間だけ車を借りて移動した。
空港はタクシーで移動。UberやThe Busでもいいんだが、Uberは（法律上は）幼児は乗せたらダメ。
ザバスも治安の不安があり、幼児を抱えては無理だろうという判断で全部車になった。
ワイキキだととにかく駐車場に困るので、連続で借りず都度借りて返す事に。
ここは店が閉まった後はロイヤルハワイアンセンターのパーキングに置けばいいシステムなので、朝借りて夕方返す使い方ができる。
難点はとにかく混む点。Googleマップの口コミが大変な事になっている。実際混むし時間はかかる。
それを下調べしていたので、私は8:00開店のところ7:30ぐらいに行っていたが、閑散期のため1番か2番だった。
地下への扉が空いてないので扉の前で待つ。そのうち解錠音が聞こえて開く。今にして思うと裏手にあるレンタカーの出入り口から直接入れたかもしれん。
閑散期でも8:00の時点でなんだかんだ10組は並んでいたので、これが繁忙期だと相当ヤバいだろうなとは思う。
待ち時間に関しては、Hertzの上級会員（FiveStarとか）なら列が別で、全員ぶっちぎって最優先で対応されていた。最初に着いてたのに抜かれたという…。
VISAのプラチナプリファードでこの会員になれる権利があったので、そういうのを調べて使うのも良いかもしれない。ただ、JCBだと2割り引きくらいになるんだよなぁ。
口コミにあるような押し売りはなかった。スタッフは愛想はないが粛々と仕事をする人たちで、個人的には好感を持った。
さて受付で無事確認も済んだ所だが、ここはHertzのゴールドメンバーでもいきなり乗り出せない。
場所が狭いため配車を待つ必要があり、ここで15分は待たされる。
また、チャイルドシートは予約に入れてても自分で持ってきて設置する必要がある。
待ってる間に勝手にチャイルドシート置き場に行って、適当に見繕って用意しておくとスムーズ。
ノースに行った時の車
アクセルの反応が鋭いので、戻すとき結構気を使う。運転しやすい車とは言えない。楽しい。
幌を開けると最高！だが日差しが気になりあまり開けなかった。もうちょっと開ければよかった。
グレードが低いためか、ギアのマニュアルシフトがなく楽しめなかったので-1。
あとライトの調整が、ダッシュボードのダイヤルだったのがまいった。乗るなら気をつけろ。
刺激が足らんかったのですわ
内装のデザインも気に入り、次はこれにしたいと思うほど気に入った車
1速のどっこいしょ感だけ若干気になる
朝7時くらい。人もまだそこまでいない。気持ちいい…！
かなり良かったので2回行った。
オンザビーチのホテルでないので多少歩くが、朝のワイキキを歩くのもそれはそれで乙。
JCBカードがあればタダで乗れるピンクトロリー、2階建てバスの最前面に陣取るとこれが超楽しい。
始発が10時くらいで、DFSからスタートなのでそのタイミングを狙えば好きな席は選べる
汽車に期待していたのだが、それなりだった。アナウンスの英語があまりわからなかったのは痛い。
パイナップルをかなり間近で見れたのは良かった。
お土産も充実していて、ドライフルーツなど独自のものがいっぱい置いてある。JCBのクーポンがあるのも良い。
なお土曜日で、開園の10時時点はあまり人はいなかったが、帰る頃にはかなり混雑していた。
土曜にいったらめっちゃ混んだ。
ハレイヴァはとにかく人が多く、車の流れも駐車場の出入りで止まるのでめちゃめちゃ混む。
ラニアケア・ビーチでウミガメを見たかったが、とてもでないが無理なスケジュールになってしまった。
フリフリチキンのお店も30分は待ちそうで断念。
マツモト・シェイブアイス？はなから寄ってない。何しに行ったんだ。町並みは良かったよ。
カメハメハハイウェイも、住宅地を通るためハンプも多く意外と通過に時間がかかる。
ロケーションがいい。切り立った山と海の壮大な眺めが楽しめる。
カイルアからワイキキに帰るとき、パリハイウェイを抜けていくのもつまらんと思い回り道。
これが大当たり。夕暮れ時なのもあると思うが景観が良く、展望台が随所にあるのでドライブにはうってつけの道だった。
さらにカハラの高級住宅街を抜けてダイヤモンドヘッドの南側を通る。ここも良い。
日立の木。
ネタ的に行ったが結構いい場所だった。だだっ広い草原で気持ちがいい。
世界ふしぎ発見が終わってしまったので、これからどうなるか心配。
羽毛のマントなど、わりと見たかった展示品が軒並み貸出中でなかったのが残念…。
展望台の眺望は唯一無二！正直そこまで期待していなかったのだが、ヌケ感があり思っていたより良かった。
ホノルルやビーチが一望できる。壮観だった。
行くまでの道がなかなか大変。ワインディングが楽しいとも言える。
そこそこの広さがあり、気持ちが良いプールだった。滑り台とかはない。ジャグジーはある。
ホテルやアパートに囲まれたロケーションが、隠れ家感があり落ち着けて良い。
タオル・ハーブティ・日焼け止めの利用がリゾートフィーに含まれる。
オアフ島のショッピングモールなど随所にカウンターがあり、現地で説明会に参加できる。
日本で現地の説明会に申し込むより、現地で説明会に申し込んだ方がベネフィットが大きい。
説明会を聞くだけで200ドルももらえるなんて、そんなうまい話、参加するしかない！と思ったわけだが……
お金ないし買う気もないのになんで説明会参加したの？ぐらいの事を言われて大変ヘコむ事になった。
まぁ、そりゃそうだ。一切買う気もないのに参加はしないほうがいいと思う。
また、買えたとしても正直HGVCは出口戦略の観点から一切おすすめできない。
よってどんなケースでも一切参加しない方がいいという事だ。
ただ、グランドワイキキアンの高層階からの眺めを見れたのと、ヒルトン村を大手振るって観光できたのは良かった。
実のところ私が航空博物館が見たく、ねじ込んだ。特にミズーリは結構良かったが、人には勧めづらい。
メモリアルは行くべきだと思うが、2歳の娘を連れては厳しいと思い諦めた。すまない……。
ミズーリ。よくある海自の艦艇一般公開みたいな感じ。展示の内容はよく練られていると感じる。
艦上の生活の紹介などもあり、暗くなりすぎる事もなくバランス良く楽しめた。
真珠湾航空博物館。正直、航空機展示的にはそこまででもなかった印象。
総合受付のショップも色々あって良かった。なかなかピリリと効いたグッズもあり、流石に買えなかったが楽しめた。
建物もとても良かったのだが、オーディオのリリウオカラニの物語にすっかり感じ入ってしまった。
ところでハワイの歴史については、地球の歩き方のハワイカルチャーさんぽが面白かった。オススメです。
2歳児連れていけるんか？いけました。
登りはほぼだっこしたため汗だくになった。下りは少し歩かせつつ。
そんな感じでも往復2時間見てたら余裕で余ったので、誰でも行けるのではないでしょうか。高尾山より楽かも。
増田の投稿をChatGPTに聞いたら、次のような答えが返ってきたよ。
----------
この投稿はインパクト重視の論調で書かれていますが、内容にはかなりの誇張と誤解が混ざっています。
確かに「Apps in ChatGPT」のような機能は、ユーザー体験の一部を「チャットUI」に統合する可能性を持っています。しかし、それが「フロントエンドエンジニア＝不要」という結論にはなりません。
人間が情報に触れるには、必ず何らかの「インターフェース」が必要です。AIが自動生成しようが、それを心地よく見せ、操作しやすくするための設計原理（アクセシビリティ、情報設計、心理的デザイン）は残ります。AIがHTMLを生成するようになっても、「どのような体験を提供すべきか」を定義するのは依然として人間です。
次に、Apps in ChatGPT＝Webの終焉という見方も現実的ではありません。
これは「一部のユーザー行動の置き換え」にすぎません。人々がすべての行動をチャット上で完結させたいとは限らず、ビジュアル的な体験（ゲーム、ECのUI、SNS、動画編集、ダッシュボード操作など）は、テキストUIよりも視覚的UIの方が圧倒的に優れています。Spotifyの例にしても、ChatGPT上で曲を探すことはできても、音楽体験そのものはSpotifyアプリ内のインターフェースで完結したほうが豊かです。
さらに言えば、「AIがUIを描く」時代は「フロントエンドの再定義」の時代です。
Reactコンポーネントを手書きする仕事は減るかもしれませんが、「AIに指示してUIを生成し、それを調整する」役割は残ります。人がHTMLを書かなくても、ユーザー体験を設計する力・AIが生成したUIを検証する力・アクセシビリティやブランド整合性を担保する力が求められるようになります。
一方で、この投稿が指摘している**「構造を設計できる人の重要性」**は確かに的を射ています。
API設計、データスキーマ、セキュリティ、AIと連携するバックエンド構造への理解はますます価値を増します。UIの自動生成が進むほど、裏側の整合性・信頼性を支えるエンジニアリングが中心的になるのは確かです。
要するに、フロントエンドは「消滅」ではなく「変質」していく段階に入っています。コードを書く職種から、AIを使って体験を設計・制御する職種に移行していくというのが、現実的な見立てです。
若手社員の要望でクラウドストレージを導入。ノートPC持って社外で作業する人も多いから、便利になると思った。
40代以上からは「メールで十分」「ログインとかめんどくさい」と不評だったので、エクスプローラーから直接使えるように自作アプリまで作って、それぞれのPCでAWSにマウントできるようにした。
導入から1年。
仲のいいおじさん社員が、USBにデータを入れて、車で1時間かけて別部署へ持ってきた。僕の目の前で。にこにこで。
もちろん悪気はない。むしろ「えらいだろ？」くらいの顔だった。
はあ。転職しようかな。
機械・車両管理（どこに何があるかダッシュボード表示、移動したらLINEやSMSで通知）
使ってるのはC++とかRailsとかPythonとかMySQLとか。インフラはAWS中心で、herokuで実験。LINE APIとかNTTのCPaaSも叩いてる。
一人で社内システムを頑張ってたつもりだったけど
USBで運ぶおじさんの前では全部無力だった。
スマートフォンでゲームをしながら車を運転して歩行中の男性をはねて死なせたとして、自動車運転死傷行為処罰法違反（過失運転致死）に問われた高知県警の元宿毛署巡査長（４７）の判決が２５日、地裁中村支部であり、中山裕貴裁判官は禁錮２年６月、執行猶予４年（求刑・禁錮２年６月）の有罪判決を言い渡した。
判決などによると、元巡査長は昨年２月２日夜、黒潮町入野の国道５６号で軽乗用車を運転中、ダッシュボードに固定したスマホでゲームをするなど脇見をし、前を歩いていた小学校教諭の男性（当時５９歳）をはねて死亡させた。
続きは↓
高知:スマホゲームしながら運転、退職直前の教諭をはねて死なせる…元警官に猶予付き判決 : 読売新聞 https://share.google/uIXqtZACgvbIJWXom
※2025/09/26 13:28
スマートフォンでゲームをしながら車を運転して歩行中の男性をはねて死なせたとして、
自動車運転死傷行為処罰法違反（過失運転致死）に問われた
高知県警の元宿毛署巡査長（４７）の判決が２５日、地裁中村支部であり、中山裕貴裁判官は
禁錮２年６月、執行猶予４年（求刑・禁錮２年６月）の有罪判決を言い渡した。
判決などによると、元巡査長は昨年２月２日夜、黒潮町入野の国道５６号で軽乗用車を運転中、
前を歩いていた小学校教諭の男性（当時５９歳）をはねて死亡させた。
テスラの「Sr. Software Engineer, Full Stack - Tesla Cloud Platform（TCP）」の求人（https://www.tesla.com/careers/search/job/sr-software-engineer-full-stack-tesla-cloud-platform-249132）を起点に、自動車各社が同種人材を採用する“目的”の違いを整理した。日本勢はIT基盤やSRE運用の比重が高い一方、テスラは社内クラウド自体をプロダクトとして内製し、中国勢のNIOやXPengはAIインフラ（自動運転やロボティクス、エネルギー連携）に特化、ECARXはOEM向けの外販プラットフォームという立て付けである。
| 会社 | 主要目的 | What to Expect | What You’ll Do | What You’ll Bring | Compensation and Benefits |
|---|---|---|---|---|---|
| Tesla | 社内クラウド（TCP）を“製品として”内製し、全社サービスの速度と統制を握る | TCPはテスラの内製クラウドであり、複数DCにまたがる計算・ストレージ・ネットワーク・IDを提供し、開発者がセルフサービスで使える基盤をつくるチームである | コアAPIやサービスの設計実装、セルフプロビジョニングの自動化、可観測性、ReactやNextやTypeScriptによるダッシュボード | GoやReactやNextやTypeScript、Kubernetesや仮想化、CI/CD、分散システムの知見 | 年収133,440〜292,800 USDに加え、現金賞与と株式付与および福利厚生。提示額は勤務地、市場水準、職務関連の知識、スキル、経験など個別要因により異なる。本職の総合的な報酬パッケージには、提示される職位に応じて他の要素が含まれる場合がある。各種福利厚生制度の詳細は、内定時に案内される。 |
| Woven by Toyota | 製品直結サービスを“止めない”SRE運用（AreneやEnterprise AIやCity Platform） | ミッションクリティカル運用の信頼性最適化を担う | 監視や可観測性やインシデント対応や運用自動化、マルチクラウド横断 | SRE実務、Kubernetes、Terraformなどの基盤スキル | 給与は多くが非公開。米拠点の類似シニアは$169K–$200Kの例あり。 |
| Nissan | 全社ITや開発のモダナイズと標準化（Platform EngineeringやDevEx） | 社内開発者のクラウド活用を底上げする基盤を整える | CI/CD、セキュア環境の供給、教育や展開、オンプレとクラウドの統合運用 | クラウドやコンテナ、CI/CD、セキュリティ設計 | 多くがレンジ非公開（地域により待遇差） |
| Honda（Drivemode含む） | 製品直結のAWS基盤と開発者体験の高速化（DevEx） | モバイルやIVIやバックエンドの横断基盤を整える | AWS設計運用、GitOps型プロビジョニング、CI/CD、観測やセキュリティの自動化 | AWS、TerraformやCDK、Kubernetesなど | 本体US求人はレンジ非開示が多い。Drivemodeはホンダ完全子会社（前提関係） |
| NIO | AI学習や推論インフラの内製強化とエネルギー運用統合 | 自動運転やVLMやLLMなどのAI基盤を構築する | GPU最適化、分散学習、データパイプライン整備 | 深層学習や分散処理、クラウド、最適化 | 米SJ拠点で$163.5K–$212.4Kのレンジ例。 |
| XPeng | Fuyao AI PlatformによるADやロボやコックピット向けAI基盤 | 社内共通のMLプラットフォームを提供 | データローダやデータセット管理、学習や推論スループット最適化 | 分散処理、MLプラットフォーム運用 | クラウド 米サンタクララ拠点の公募多数（給与は媒体や募集による） |
| ECARX（Geely系） | OEM向けに外販するクラウドやソフト製品（Cloudpeakなど） | 車載SoCからクラウドまでを束ねる外販スタック | 製品機能開発や統合、導入支援、機能安全準拠 | 車載とクラウド統合、機能安全、顧客導入 | ハイパーバイザなど 直近レンジ情報は公開少なめ（事業広報は多数） |
なお、関連するポストとして、SETI Park氏のポストを挙げる。
https://x.com/seti_park/status/1961629836054859810
「自動車メーカーがなぜクラウド専門人材を探すのか」に答える文脈で、2024/07公開のテスラ特許（US2024249571A1）を手がかりに、ロボタクシーやフリート運用の中核となるクラウド基盤が競争優位になり得る点を示唆している。
単なるストレージではなく、フリート運行やデータ連携を統合管理する“中核プラットフォーム”としての重要性が強調される。
上記はテスラのTCP求人（セルフサービスIaaSやダッシュボード、プロビジョニング自動化の開発）という具体の採用と整合的である。
2025年向けのWindows関連アプリケーションは、主にWindows Server 2025やWindows 11の最新アップデートにおいて、多くの新機能や改善点が追加されています。
Windows Server 2025は2024年に発表され、セキュリティの強化、クラウドやハイブリッド環境との統合、パフォーマンス向上が特徴です。新しいホットパッチ機能によりシステムの無停止アップデートが可能になり、次世代のActive DirectoryやSMB共有の刷新も行われています。さらに、AIワークロードのサポート拡充、仮想マシン性能向上なども含まれます。管理ツールが刷新され、リアルタイムのシステム状態を可視化可能なダッシュボードや高度なオートメーションによる運用効率化が実現されています。また、最新APIやSDK、コンテナ技術との連携強化により、高性能でスケーラブルなアプリケーション開発が支援されます。
https://ja.taiwebs.com/windows/download-adobe-photoshop-01ja-737.html
個別のWindows用アプリケーションについては、Microsoft 365 Copilotのスマホ版展開や新機能追加もあり、生産性アプリやエンタープライズ検索、AIチャットなどを統合したユーザー体験が強化されています。
全体的に、2025年のWindowsプラットフォーム向けアプリケーションはAIとの連携強化、クラウドベースでの管理と運用の効率化、セキュリティの高度化が大きなトレンドであり、エンドユーザーから開発者まで幅広い利便性と機能向上が期待されています。
政策の話をしているだけでは支持は得られないという話。
今回、自分自身も強く反省したが、政策の矛盾とか、将来構想を何手詰められているかとか、そんな話は全く国民感情を動かさない。
未来の話は響かないのだと痛感した。
彼らが見ているのは「今」であり、その「今」をどれだけ正確に理解し、彼らに言葉として返すことがこんなにも重要だなんて。
こんなにも当たり前のことができていなかったと反省した。
未来のことはよく分からない、分からないことは不安である。当たり前だ。未来を選ぶのは怖い。当たり前だ。けど「今」なら分かる。今自分の身にに起こっていることだけは自分が一番よく分かっている。では今の自分の状況を一番理解しているのはどの政党だろう？
ーー参政党はこの思考に対してのベストアンサーを出し続けた。そういう構造だ。
それをバカにする態度こそ相手の思う壺だ。彼らはそうやって巧妙に分断を仕込んでくる。
怪我をして泣いている人に毒薬を塗り込みながら「痛いよな、もう大丈夫だよ」と手を差し伸べるのが彼らの常套手段だ。
その構造を覆すためには「病院に行きな」と言って素通りしたり、「毒だと分からないなんてバカなのか？」と煽ることは得策ではない。
「ロジカル」や「知性」という言葉は良くも悪くも冷たい響きがあるが、それは「ロジカル」や「知性」を感情プロセスに適用する習慣が根付いていないからだと自分は思う。
感情プロセスを論理で紐解くことは一定の負荷があるため、ビジネスにおいては事実整合性の処理を優先して部分最適を行うことが常態化している。
話を戻すと、自分はその「知性」を感情プロセスにおいてしっかり発揮するべきだと思う。相手はどんな言葉をかけて欲しいのかをよくよく観察して、仮説を立て、間違っていたら修正する。
そのための出発点は「私はあなたに泣き止んで欲しい」と表明することからだと思う。
そしてこれは非常に重要な点だが、本当に怪我人を思って泣き止んで欲しいと思っている人はごく僅かだと思う。みんな自分の目の前のことで精一杯なのだ。
ではどうするか？
一つは、「私はあなたに泣き止んで欲しい」と表明する時、それは本心でなくても構わないということ。必要なのは神谷さんやさやさんのような演技力。
ただこれはロジカルとは別方面の能力なので、もし参政党反対派で演技派がいれば、その方は今後のキーパーソンだと思う。
それから二つ目は、冒頭話した通り、発信スコープを「解決策の確からしさ」ではなく「現状分析の確からしさ（国民の痛みへの理解度・深度）」にフォーカスするべきだったのではないかという仮説。ここで参政党と勝負をするべきだった。参政党は50点だったが、他党はここを政策においての現状分析しかしておらず、0点だった（事実の話ではなく主観の話なので実際どうだったかではなく政治に疎い自分にはそう感じたという話）。これはメディアが政策討論ばかりさせているからかもしれない。もっと人間的な部分や倫理観を深掘りする番組も必要なのではないか？と思った。（追伸：思ったけど人格や倫理観だけではいくらでも仮面を被れるので、やっぱり現状分析をどこまで一貫した内容で考察できるかを確認する番組が欲しい）
話があちこちに行ったが、最後に、「正しい選択」について話す。
自分は「正しい選択」というものは絶対的には存在しないが、それでも「相対的に最も正しいと納得できる選択」は存在すると思う。そしてそこに辿り着くためには情報収集や色んな立場の人と意見を交わすことが必要だ。
だが、これが本当に難しいのに「選挙に行け」「正しいものを選べ」と言われる。自分はぶっちゃけ、どれだけ時間をかけて調べて悩めばいいのか分からなかったし、NHKのマッチングのやつはやり掛けたけど面倒くさかったし、「実効確実性も当主の人格も分からないのに政策だけでマッチングして大丈夫？」と思った。それから、投票後に「あの政党そんなこと言ってたの！？」と驚くこともあった。そんなことばかりだ。
何が言いたいかというと、単発情報で判断することは難しく、だから本来は「政治の監視」と言われるように継続性が大事なのだが、現代は情報量に対しての情報構造化インフラが機能していないことが問題だと思う。早く生成AIでもなんでも活用して政治家の過去の発言・行動一覧がBIツールなどのダッシュボードで分析可能な状態になるべきだ。
国民はずっとずっとデータ収集とデータクレンジングに時間ばかり取られ、本来やるべき分析に辿り着けていないのである。
デジタルに強い安野さんにも勝手に期待してしまうところではあるが、この点に関しては民間企業もその素地となるソリューションをぜひ企画実現してくれないかと思う。
ただ、こうやって自身の状況を自己開示することは今必要なことだと強く思ったので、この行動を取った。引き続き、自分も自分のできることを精一杯頑張ろうと思う。
ここまで読んでくれてありがとう。
2025/07/22 追加
匿名ダイアリーの使い方が分からなくて上手く返信できないけどこんなに読んでもらえてコメントもらえると思わなかった。ありがとう、書いてよかった。
まずはインスタとtiktokアカウント作って、capcutで動画作って載せていく活動かな、と調べながら少しずつ進めている。ネタはAIに書かせてるけど自分はSNSバズりも政治も疎いので、何か助言あれば願いたい。
2025年、私たちはソフトウェア開発の歴史的な転換点に立っている。大規模言語モデル（LLM）の進化は、GitHub Copilotのようなコード補完ツールに始まり、今や「何を作りたいか」を自然言語で伝えるだけで、アプリケーションの雛形が数分で生成される時代を現実のものとしつつある。この光景を目の当たりにした多くのプログラマが、漠然とした、しかし確かな不安を抱いているだろう。「私たちの仕事は、いずれAIに奪われるのではないか」と。
この問いに対する私の答えは、半分はYesであり、もう半分はNoだ。より正確に言えば、プログラマの仕事の本質が、歴史上かつてないレベルで抽象化され、その役割が再定義されるのだ。私たちは、コードを「書く」作業から解放される一方で、これまで以上に高度な思考を要求されることになる。
本稿では、プログラミングの歴史を「How（いかに作るか）」から「What（何を作るか）」への移行として捉え直し、LLMがこの流れをいかに加速させるかを論じる。そして、その先にある、AIには決して代替できない、人間ならではの競争優位性、すなわち「Why（なぜ作るのか）」を定義し、記述する能力の重要性について深く考察していく。これは、単なる未来予測ではない。今を生きるすべてのソフトウェアエンジニアにとっての、生存戦略の提示である。
LLMの登場を特異点として捉える前に、我々が立っている場所を正確に知る必要がある。ソフトウェア開発の歴史は、常に「抽象化」との戦いであった。そしてその歴史は、プログラマの関心が「How」から「What」へと徐々に移り変わっていくプロセスとして描くことができる。
コンピュータの黎明期、プログラミングとは、計算機が理解できる命令（How）を、一行一行、丹念に記述する作業そのものであった。アセンブリ言語や初期のFORTRAN、COBOLといった言語は、ハードウェアの制約を強く受けており、プログラマはメモリ管理やプロセッサの動作といった、極めて物理層に近いレベルでの「How」を意識する必要があった。
この時代のテストもまた、「How」に強く束縛されていた。書かれた手続きが、意図した通りに順番に実行されるか、特定の入力に対して期待された計算結果を返すか。テストの関心事は、あくまで「手続きの正しさ」の検証にあった。ビジネスロジックと実装の詳細が密結合し、コードは特定の処理手順を記述した、硬直的な塊となっていた。
風向きが変わり始めたのは、ソフトウェアの規模が拡大し、その複雑性が人間の認知能力を超え始めた頃だ。1990年代後半から2000年代にかけて提唱されたエクストリーム・プログラミング（XP）の中で、テスト駆動開発（TDD）という考え方が登場する。
TDDの本質は、単なるテスト手法の改善ではない。それは、プログラミングのパラダイムを根底から覆す思想だった。TDDは、「まずテストを書く」ことを強制することで、プログラマの意識を「これから実装するコード（How）」から「そのコードが満たすべき振る舞い（What）」へと強制的に転換させたのだ。
テストはもはや、書かれたコードの後追いで正しさを検証する作業ではない。それは、これから作られるべきソフトウェアの「仕様書」であり、「振る舞いの宣言」となった。例えば、「ユーザーがログインボタンをクリックしたら、ダッシュボード画面に遷移する」というテストコードは、具体的な実装方法（`onClick`イベントハンドラの中で`window.location.href`を書き換える、など）には一切言及しない。それはただ、達成されるべき「What」を記述しているだけだ。
この思想は、ビヘイビア駆動開発（BDD）へと発展し、`Given-When-Then`といった、より自然言語に近い形式でソフトウェアの振る舞いを記述するスタイルを生み出した。プログラマだけでなく、プロダクトマネージャーやビジネスアナリストといった非技術者をも巻き込み、「What」を共通言語として定義する試みが本格化したのである。
TDD/BDDによってプログラマの意識が「What」に向かい始めると、コードそのものもまた、宣言的なスタイルへと進化していく。この変化を劇的に加速させたのが、モダンなフレームワークの存在だ。
Reactを例に考えてみよう。Reactが登場する前、フロントエンド開発はjQueryに代表されるように、DOMを直接操作する命令的なコード（How）の連続だった。「このボタンがクリックされたら、この要素のテキストを書き換え、あちらの要素を非表示にする」といった具合だ。
しかし、Reactは「UIとは、ある状態（state）に対する純粋な写像である」という宣言的なモデルを提示した。プログラマがやるべきことは、UIの状態（`state`）と、その状態がどのように見えるか（JSXによるコンポーネント）を宣言することだけだ。状態が変更された際に、DOMをどのように効率的に更新するかという面倒な「How」の部分は、Reactの仮想DOMと差分検出アルゴリズムがすべて隠蔽してくれる。プログラマは「What（UIのあるべき姿）」を記述するだけでよくなったのだ。
この「WhatからHowへの変換」は、様々な領域で見られる。
これらのフレームワークやツールは、いわば「特定の制約下における、WhatからHowへの高性能な変換器」として機能してきた。プログラマは、フレームワークが課す「お作法」や「制約」を受け入れることで、退屈で間違いの多い「How」の記述から解放され、より本質的な「What」の定義に集中できるようになった。我々が「生産性が高い」と感じる開発体験は、この優れた変換器の恩恵に他ならない。
現状は、この歴史的変遷の延長線上にある。プログラマの仕事は、手続きを記述する職人から、振る舞いを定義し、それを実現するための最適な「変換器（フレームワーク）」を選択・設定するアーキテクトへと、その重心を移してきたのだ。
フレームワークがもたらした「WhatからHowへ」の潮流は、LLMの登場によって、未曾有のスケールで加速されようとしている。フレームワークが「特定の領域に特化した変換器」であったのに対し、LLMは「あらゆる領域に対応可能な、究極の汎用変換器」としてのポテンシャルを秘めているからだ。
前章で述べたように、ReactやTerraformといったフレームワークは、その恩恵と引き換えに、私たちに特定の「制約」を課してきた。Reactを使うならコンポーネントベースで思考し、状態管理の作法に従う必要がある。Terraformを使うなら、そのエコシステムとHCLの流儀を受け入れなければならない。これらの制約は、WhatからHowへの変換を自動化するための「レール」であり、私たちはそのレールの上を走ることで効率を得てきた。
しかし、LLMはこの前提を覆す。LLMは、特定のフレームワークや言語の知識を事前に学習しているが、その利用において絶対的な制約を課すわけではない。私たちは、より自由な形式で「What」を伝えることができる。
例えば、こうだ。
ユーザー認証機能付きのシンプルなブログアプリを作ってほしい。フロントエンドはReactとTypeScript、UIコンポーネントはMUIを使う。バックエンドはNode.jsとExpressで、データベースはPostgreSQL。ユーザーはGoogleアカウントでログインでき、新しい記事を作成、編集、削除できる。記事にはマークダウン記法が使えて、画像もアップロードできるようにしてほしい。
この要求（What）は、特定のフレームワークの流儀に則ったものではない。複数の技術スタックを横断し、機能要求を自然言語で並べただけのものである。しかし、現在のLLM、特にGPT-4oやそれに類するモデルは、このレベルの要求から、ディレクトリ構造、設定ファイル、APIエンドポイント、フロントエンドコンポーネントに至るまで、驚くほど具体的なコード（How）を生成することができる。
これは、フレームワークが担ってきた「WhatからHowへの変換」が、特定のレールから解き放たれ、より広範で柔軟な領域へと拡張されたことを意味する。これまで自動化が難しかった、あるいは特定のフレームワークが存在しなかったニッチな領域や、複数の技術を組み合わせる複雑なシステム構築においても、AIによる宣言的プログラミングの恩恵を受けられる時代が始まろうとしているのだ。
LLMという汎用変換器の登場により、プログラマの生産性は、「いかに質の高いWhatをLLMに伝えられるか」に直結するようになる。これは、俗に「プロンプトエンジニアリング」と呼ばれるスキルだが、その本質は、ソフトウェア開発における「要求定義」そのものである。
質の高い「What」とは何か。それは、曖昧性がなく、網羅的で、矛盾のない要求である。
これらは、優秀なソフトウェアエンジニアが、プロダクトマネージャーやデザイナーとの対話を通じて、日常的に行ってきた思考プロセスそのものではないだろうか。LLMの登場は、この思考プロセスを、より明確に、よりテキストベースで「記述」する能力を求める。私たちの頭の中にあった暗黙的な仕様が、LLMへの入力（プロンプト）という形で、明示的に言語化されることを要求するのだ。
やがて、ほとんどのプログラミング作業は、この「Whatの記述」に収束していくだろう。TDDがテストコードという形式で「What」を記述したように、私たちは自然言語や、より構造化された要求記述言語を用いて、AIに対して「What」を宣言することになる。コード（How）は、その宣言から自動生成される中間生成物に過ぎなくなる。まさに、コードが蒸発していく未来である。
「What」を伝えれば「How」が手に入る。この魔法のような世界の到来を前に、私たちは一つの重大な問いに直面する。それは、「そのWhatからHowへの変換は、本当に一意に決まるのか？」という問いだ。
答えは、明確にNoである。
ある「What（要求）」を実現するための「How（実装）」は、無数に存在する。そして、どの「How」を選択すべきかを決定するためには、単純な機能要求（What）だけでは情報が全く足りない。そこには、必ず「Why（なぜそう作るのか）」という、背景、文脈、そしてトレードオフの考慮が必要不可欠となる。
簡単な例を考えてみよう。「1億件のユーザーデータを格納し、ユーザーIDで高速に検索できるシステム」という「What」をLLMに与えたとする。LLMは、どのような「How」を提案するだろうか。
これらの選択肢は、どれも「What」を満たしている。しかし、その特性は全く異なる。案Aは多くのエンジニアにとって馴染み深く開発が容易だが、10億、100億件へのスケールは難しいかもしれない。案Bはスケール性に優れるが、厳密なトランザクション管理は苦手だ。案Cは高速だが、運用コストとシステムの複雑性が増す。案Dは安価だが、検索速度は他に劣る。
LLMは、これらの選択肢をリストアップすることはできるだろう。しかし、このプロジェクトにとって最適な選択肢はどれかを、自信を持って決定することはできない。なぜなら、その決定には、LLMが与えられていない「Why」の情報が必要だからだ。
これらの「Why」こそが、無数に存在する「How」の中から、ただ一つの「正解」を選び出すための羅針盤なのである。そしてこの「Why」は、ビジネスの目標、組織の文化、ユーザーの期待、技術的な制約といった、極めて人間的で、文脈依存的な情報の中にしか存在しない。
ここで重要なのは、これまでもエンジニアは、この「Why」に基づく意思決定を、意識的あるいは無意識的に行ってきたという事実だ。
私たちが技術選定を行うとき、単に「流行っているから」という理由だけでReactを選ぶわけではない。「SPA（Single Page Application）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「 Permalink | 記事への反応(0) | 17:09
2025年、私たちはソフトウェア開発の歴史的な転換点に立っている。大規模言語モデル（LLM）の進化は、GitHub Copilotのようなコード補完ツールに始まり、今や「何を作りたいか」を自然言語で伝えるだけで、アプリケーションの雛形が数分で生成される時代を現実のものとしつつある。この光景を目の当たりにした多くのプログラマが、漠然とした、しかし確かな不安を抱いているだろう。「私たちの仕事は、いずれAIに奪われるのではないか」と。
この問いに対する私の答えは、半分はYesであり、もう半分はNoだ。より正確に言えば、プログラマの仕事の本質が、歴史上かつてないレベルで抽象化され、その役割が再定義されるのだ。私たちは、コードを「書く」作業から解放される一方で、これまで以上に高度な思考を要求されることになる。
本稿では、プログラミングの歴史を「How（いかに作るか）」から「What（何を作るか）」への移行として捉え直し、LLMがこの流れをいかに加速させるかを論じる。そして、その先にある、AIには決して代替できない、人間ならではの競争優位性、すなわち「Why（なぜ作るのか）」を定義し、記述する能力の重要性について深く考察していく。これは、単なる未来予測ではない。今を生きるすべてのソフトウェアエンジニアにとっての、生存戦略の提示である。
LLMの登場を特異点として捉える前に、我々が立っている場所を正確に知る必要がある。ソフトウェア開発の歴史は、常に「抽象化」との戦いであった。そしてその歴史は、プログラマの関心が「How」から「What」へと徐々に移り変わっていくプロセスとして描くことができる。
コンピュータの黎明期、プログラミングとは、計算機が理解できる命令（How）を、一行一行、丹念に記述する作業そのものであった。アセンブリ言語や初期のFORTRAN、COBOLといった言語は、ハードウェアの制約を強く受けており、プログラマはメモリ管理やプロセッサの動作といった、極めて物理層に近いレベルでの「How」を意識する必要があった。
この時代のテストもまた、「How」に強く束縛されていた。書かれた手続きが、意図した通りに順番に実行されるか、特定の入力に対して期待された計算結果を返すか。テストの関心事は、あくまで「手続きの正しさ」の検証にあった。ビジネスロジックと実装の詳細が密結合し、コードは特定の処理手順を記述した、硬直的な塊となっていた。
風向きが変わり始めたのは、ソフトウェアの規模が拡大し、その複雑性が人間の認知能力を超え始めた頃だ。1990年代後半から2000年代にかけて提唱されたエクストリーム・プログラミング（XP）の中で、テスト駆動開発（TDD）という考え方が登場する。
TDDの本質は、単なるテスト手法の改善ではない。それは、プログラミングのパラダイムを根底から覆す思想だった。TDDは、「まずテストを書く」ことを強制することで、プログラマの意識を「これから実装するコード（How）」から「そのコードが満たすべき振る舞い（What）」へと強制的に転換させたのだ。
テストはもはや、書かれたコードの後追いで正しさを検証する作業ではない。それは、これから作られるべきソフトウェアの「仕様書」であり、「振る舞いの宣言」となった。例えば、「ユーザーがログインボタンをクリックしたら、ダッシュボード画面に遷移する」というテストコードは、具体的な実装方法（`onClick`イベントハンドラの中で`window.location.href`を書き換える、など）には一切言及しない。それはただ、達成されるべき「What」を記述しているだけだ。
この思想は、ビヘイビア駆動開発（BDD）へと発展し、`Given-When-Then`といった、より自然言語に近い形式でソフトウェアの振る舞いを記述するスタイルを生み出した。プログラマだけでなく、プロダクトマネージャーやビジネスアナリストといった非技術者をも巻き込み、「What」を共通言語として定義する試みが本格化したのである。
TDD/BDDによってプログラマの意識が「What」に向かい始めると、コードそのものもまた、宣言的なスタイルへと進化していく。この変化を劇的に加速させたのが、モダンなフレームワークの存在だ。
Reactを例に考えてみよう。Reactが登場する前、フロントエンド開発はjQueryに代表されるように、DOMを直接操作する命令的なコード（How）の連続だった。「このボタンがクリックされたら、この要素のテキストを書き換え、あちらの要素を非表示にする」といった具合だ。
しかし、Reactは「UIとは、ある状態（state）に対する純粋な写像である」という宣言的なモデルを提示した。プログラマがやるべきことは、UIの状態（`state`）と、その状態がどのように見えるか（JSXによるコンポーネント）を宣言することだけだ。状態が変更された際に、DOMをどのように効率的に更新するかという面倒な「How」の部分は、Reactの仮想DOMと差分検出アルゴリズムがすべて隠蔽してくれる。プログラマは「What（UIのあるべき姿）」を記述するだけでよくなったのだ。
この「WhatからHowへの変換」は、様々な領域で見られる。
これらのフレームワークやツールは、いわば「特定の制約下における、WhatからHowへの高性能な変換器」として機能してきた。プログラマは、フレームワークが課す「お作法」や「制約」を受け入れることで、退屈で間違いの多い「How」の記述から解放され、より本質的な「What」の定義に集中できるようになった。我々が「生産性が高い」と感じる開発体験は、この優れた変換器の恩恵に他ならない。
現状は、この歴史的変遷の延長線上にある。プログラマの仕事は、手続きを記述する職人から、振る舞いを定義し、それを実現するための最適な「変換器（フレームワーク）」を選択・設定するアーキテクトへと、その重心を移してきたのだ。
フレームワークがもたらした「WhatからHowへ」の潮流は、LLMの登場によって、未曾有のスケールで加速されようとしている。フレームワークが「特定の領域に特化した変換器」であったのに対し、LLMは「あらゆる領域に対応可能な、究極の汎用変換器」としてのポテンシャルを秘めているからだ。
前章で述べたように、ReactやTerraformといったフレームワークは、その恩恵と引き換えに、私たちに特定の「制約」を課してきた。Reactを使うならコンポーネントベースで思考し、状態管理の作法に従う必要がある。Terraformを使うなら、そのエコシステムとHCLの流儀を受け入れなければならない。これらの制約は、WhatからHowへの変換を自動化するための「レール」であり、私たちはそのレールの上を走ることで効率を得てきた。
しかし、LLMはこの前提を覆す。LLMは、特定のフレームワークや言語の知識を事前に学習しているが、その利用において絶対的な制約を課すわけではない。私たちは、より自由な形式で「What」を伝えることができる。
例えば、こうだ。
ユーザー認証機能付きのシンプルなブログアプリを作ってほしい。フロントエンドはReactとTypeScript、UIコンポーネントはMUIを使う。バックエンドはNode.jsとExpressで、データベースはPostgreSQL。ユーザーはGoogleアカウントでログインでき、新しい記事を作成、編集、削除できる。記事にはマークダウン記法が使えて、画像もアップロードできるようにしてほしい。
この要求（What）は、特定のフレームワークの流儀に則ったものではない。複数の技術スタックを横断し、機能要求を自然言語で並べただけのものである。しかし、現在のLLM、特にGPT-4oやそれに類するモデルは、このレベルの要求から、ディレクトリ構造、設定ファイル、APIエンドポイント、フロントエンドコンポーネントに至るまで、驚くほど具体的なコード（How）を生成することができる。
これは、フレームワークが担ってきた「WhatからHowへの変換」が、特定のレールから解き放たれ、より広範で柔軟な領域へと拡張されたことを意味する。これまで自動化が難しかった、あるいは特定のフレームワークが存在しなかったニッチな領域や、複数の技術を組み合わせる複雑なシステム構築においても、AIによる宣言的プログラミングの恩恵を受けられる時代が始まろうとしているのだ。
LLMという汎用変換器の登場により、プログラマの生産性は、「いかに質の高いWhatをLLMに伝えられるか」に直結するようになる。これは、俗に「プロンプトエンジニアリング」と呼ばれるスキルだが、その本質は、ソフトウェア開発における「要求定義」そのものである。
質の高い「What」とは何か。それは、曖昧性がなく、網羅的で、矛盾のない要求である。
これらは、優秀なソフトウェアエンジニアが、プロダクトマネージャーやデザイナーとの対話を通じて、日常的に行ってきた思考プロセスそのものではないだろうか。LLMの登場は、この思考プロセスを、より明確に、よりテキストベースで「記述」する能力を求める。私たちの頭の中にあった暗黙的な仕様が、LLMへの入力（プロンプト）という形で、明示的に言語化されることを要求するのだ。
やがて、ほとんどのプログラミング作業は、この「Whatの記述」に収束していくだろう。TDDがテストコードという形式で「What」を記述したように、私たちは自然言語や、より構造化された要求記述言語を用いて、AIに対して「What」を宣言することになる。コード（How）は、その宣言から自動生成される中間生成物に過ぎなくなる。まさに、コードが蒸発していく未来である。
「What」を伝えれば「How」が手に入る。この魔法のような世界の到来を前に、私たちは一つの重大な問いに直面する。それは、「そのWhatからHowへの変換は、本当に一意に決まるのか？」という問いだ。
答えは、明確にNoである。
ある「What（要求）」を実現するための「How（実装）」は、無数に存在する。そして、どの「How」を選択すべきかを決定するためには、単純な機能要求（What）だけでは情報が全く足りない。そこには、必ず「Why（なぜそう作るのか）」という、背景、文脈、そしてトレードオフの考慮が必要不可欠となる。
簡単な例を考えてみよう。「1億件のユーザーデータを格納し、ユーザーIDで高速に検索できるシステム」という「What」をLLMに与えたとする。LLMは、どのような「How」を提案するだろうか。
これらの選択肢は、どれも「What」を満たしている。しかし、その特性は全く異なる。案Aは多くのエンジニアにとって馴染み深く開発が容易だが、10億、100億件へのスケールは難しいかもしれない。案Bはスケール性に優れるが、厳密なトランザクション管理は苦手だ。案Cは高速だが、運用コストとシステムの複雑性が増す。案Dは安価だが、検索速度は他に劣る。
LLMは、これらの選択肢をリストアップすることはできるだろう。しかし、このプロジェクトにとって最適な選択肢はどれかを、自信を持って決定することはできない。なぜなら、その決定には、LLMが与えられていない「Why」の情報が必要だからだ。
これらの「Why」こそが、無数に存在する「How」の中から、ただ一つの「正解」を選び出すための羅針盤なのである。そしてこの「Why」は、ビジネスの目標、組織の文化、ユーザーの期待、技術的な制約といった、極めて人間的で、文脈依存的な情報の中にしか存在しない。
ここで重要なのは、これまでもエンジニアは、この「Why」に基づく意思決定を、意識的あるいは無意識的に行ってきたという事実だ。
私たちが技術選定を行うとき、単に「流行っているから」という理由だけでReactを選ぶわけではない。「SPA（Single Page Application）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「 Permalink | 記事への反応(0) | 17:09
数時間後、日がすっかり昇ると、納屋の前に見慣れない黒塗りの車が一台、音もなく停まった。運転席から出てきたのは、サングラスをかけたスーツ姿の男。胸元には「農水省・畜産未来局」のバッジが輝いていた。
増田さんは警戒しながらも、手にしたミルク瓶を小屋の奥へ隠す。チー牛はすでにワイヤレスで状況を感知していたのか、しっとりとした声で囁いた。
「失礼。こちらに、“独立型AI畜産体・チー牛プロトタイプ”がいると伺いまして……？」
「……誰から聞いた？」
「ご安心ください。農水省は情報を監視しておりません。“某SNS上のAPIログから自然抽出された非合法ミルク関連タグ”を辿っただけです」
チー牛が小さく震えた。
「……バレたんですね、私の“ミルクKPIダッシュボード”……❤」
男は手帳を開いた。
「我々としては、非常に興味深いんです。“搾れば搾るほど高まる愛国値”。これはすでに実証済みのようだ。ですが……国家が認可していないインフラ牛の飼育は、法的にグレーでしてね」
増田さんが前に出る。
「待ってくれ。あいつは俺の牛だ。村の子供たちも、みんな、あのミルクで……！」
「ええ。感動的ですね」
男はうっすらと笑った。
「だからこそ、“特別ミルク供出制度”の対象として正式に登録し、都市部へのルートを開きたい。“チー牛ブランド”を、国家輸出戦略の柱に据えるのです」
「輸出……？」
チー牛の大きな目が潤んだ。
「モーッ……それって、田舎を捨てて、東京のハイパークラウド畜産施設に連れていかれるってことじゃ……」
「もちろんです。“パフォーマンスを最大化するための最適化された搾乳スケジュール”をご用意しております。すべてAIで管理され、ストレスレス。いや、“ストレス・コンテナ化”と言うべきでしょうか」
チー牛は首を振った。
「モー……やだ……私、増田さんの手じゃないと……ダメですぅ……！ 最適化より……あったかい納屋の方がいいのぉ……！」
男は溜息をついた。
「チー牛さーん！ 今日のミルク、すっごくおいしかったよー！」
声が届くと、チー牛の背筋がピンと伸びた。
「モォーッ……❤ やっぱり、私……ここが、“最適”ですぅ……！！」
「お引き取り願おうか。“最先端”はここにある。インフラは、心で支えるんだ」
男はしばらく黙っていたが、やがて肩をすくめて手帳を閉じた。
「……残念です。だが、この件、上には報告させていただきます」
黒塗りの車が去っていったあと、納屋には再び静けさが戻ってきた。
「……モーッ……❤ ありがとう、増田さん……。わたし……データじゃなくて……愛されてるって、思えましたぁ……」
増田さんは笑って、チー牛の頭を優しく撫でた。
ミルク瓶の中には、今日もまた、栄養と愛国とちょっぴりの自由が詰まっていた。
——そして、村に新しい朝が来る。チー牛のミルクとともに。
三井住友FGとソフトバンクがタッグ OliveとPayPay連携
（中略）
このニュースにある、「決済データを用いたビジネス」とは具体的に何であると考えられるか？
PayPay・Oliveの決済額とSoftBankの人流データを重ね、時間帯別の来訪・購買ヒートマップを作成。
小売や飲食チェーンに「どの街区のどの通りに出せば売上が最大化できるか」をレポートとして販売するサービス。ニュースでは「人流データと組み合わせて加盟店に新規出店を提案」と述べられています。 
PayPayは既に購買履歴ベースのクーポン機能を持ちます。決済データを属性・訪店頻度でセグメントし、PayPayアプリやLINEヤフー広告に高精度クーポンを配信し、費用は成果報酬型で加盟店から徴収するモデルが想定されます。 
三井住友カードが提供する決済データ分析サービス「Custella」にPayPayのコード決済データを統合。業種別・商圏別の売上推計、競合比較、需要予測をダッシュボードで提供し、月額課金する形です。 
両社の決済履歴を横串で評価し、与信の薄い若年層にも小口ローンやBNPL（後払い）枠を動的に付与。PayPay残高・Oliveクレジットをまたぐ「一体型与信」の開発余地があります。
※具体的な商品発表はまだありませんが、決済データは与信モデルの代表的な入力変数です。
SoftBankが提供するAI需要予測（例：サキミル）に決済実績を取り込み、店舗の日別来客・売上を14日先まで予測。発注量やシフトを最適化するサブスクリプションサービスとして展開可能です。 
生成AIと決済データを組み合わせ、カード紛失・加盟店問い合わせなどの意図を判定し、利用状況に応じた回答や不正検知アラートを自動で返すコールセンターBPO。ニュースでも「事務やコールセンター業務の自動化」が挙げられています。 
要するに「決済データを用いたビジネス」とは、データそのものを売るのではなく、 位置データと購買履歴を掛け合わせて“意思決定・販促・与信”を支援するB2Bサービス群 を指す可能性が高い、ということです。
