  |
はてなキーワード: typescriptとは
以前ここでTypeScriptは💩みたいなことを言ったらもしかしてIDE入れてないの？って言われて
でも一箇所直したら全部に波及してどれかがエラーになる
いい加減でもぽちぽち作れたJavaScriptとは違って、TypeScriptは設計力が必要とされる気がする
でも言語に罪はなくて俺が💩なだけだ
まぁ性質なのかな。
終電帰り
深夜リリース
PagerDutyで夜中に叩き起こされる
でも最後に必ずこう書く。
”今振り返れば貴重な経験でした。”
・「最高の仲間」に異様に感謝する
最高のチームでした
途中で突然出てくる。
React
Terraform
「この会社でこれらを学びました」
・プロダクト愛を語る
退職するのにめちゃくちゃ愛を語る。
だがなぜ辞めるのかはぼかす。
本音は
将来性
だがこう表現される。
"次のチャレンジをしたいと思いました"
・やたら長い
普通の人なら3行で終わる内容が
締めはだいたいこれ。
挑戦はまだ続きます。
人生は旅の途中です。
そして最後に
（おまけ）
いいね数がやたら多い
PR出したらPRをクローズされて、その後に僕のコミット内容を使って著者がコミットしてたし、
それを指摘したら勝手に「まことにすみませんでした」って記事を出しては僕の指摘ツイートを大々的に引用して公開処刑してきたから、
好きになれない。
https://x.com/i/status/1771474271594074622
笑
そもそもお前がGitHub上の問題をわざわざXに持ち出して大事にしたのが原因やんけ笑
大層な被害者意識をお持ちで笑
こいつの本質は全部自分のメリットしか考えてないことなんだよな。コミュニティへの貢献とか、そもそもZennの世界観とは真逆の存在。
OSSの記事書くなーの件も、自分の嫉妬心を掻き立てられるとかいう自分勝手な理由だし、アメリカの大学卒業記事に対する件もZennのルールを隠れ蓑にして自分の嫉妬心をぶつけてるだけだろう。サバイバルTypeScriptの件も自分のコントリビューションのことばっかり考えてて、貢献が第一の目的に来てなくて迷惑。
コミュニティのことを考えてるなら客観的に物事を考えられるようにならないとダメなんだよな。こういう奴が一番困る存在だよ。無駄に熱心だし。
浪人留年休学繰り返して、ようやく28歳で旧帝大理系卒業したピエロが入ったのはSESだった。
「理系なら食いっぱぐれない」ってテンプレを信じたかったんだろうな。臥薪嘗胆の物語で自分を誤魔化してた。
現場出てコード書いて打ち合わせして、なんとなく社会人っぽい顔してた。でもキラキラとかエッジとか起きるわけなく、いつの間にか「これでいいのか？」だけが蓄積。神経衰弱理論がじわじわ発動。
で、29歳でメンタル病んで休職。休んだら戻れると思ってた。戻れなかった。結局そのまま退職。チャージスポット切れまくり。
今は傷病手当金もらいながら生きてる。生きてるって言っても貯金なんて当然できない。月末近づくほど心拍数上がるタイプの生活。「節約してるのに増えない」じゃなくて、「節約しないと減るスピードが怖い」側。ヌクモリンすら残らない。
再就職も一応探した。でも微経験30歳を採ってくれる奇特な会社なんてどこにあんだよ。求人眺めては「実務◯年以上」の条件で手が止まって、タブ閉じる。これを無限ループ。カイカンチュア止まり確定。
今の一番の問題は、これからどうすりゃいいか……じゃなくて、どうしたいのかがわからなくなってる方だ。「こうなりたい」がない。いや、あったはずなのにどっか消えた。意思って体力と一緒に削れていくんだな。魂の格がtの公遺症で染みつきすぎ。
とりあえずブルーベリー本読んでTypeScript勉強してる。ページ進むと一瞬だけ「俺、まだ動けるかも」って錯覚できる。読み終わったらReactでもやろうかな。別に「React好き」とかじゃない。ただ、次のページ用意しておかないと、何もない時間が怖すぎる。セルフ男子校状態。
年収900万でコレジャナイって言えるエリサラ人生もあるらしい。こっちは年収0万でコレジャナイだ。
どっちもコレジャナイなら、いったい“コレ”って何なんだろうな。アマンレジデンス眺める資格すらなく、幻資痛で眺めるだけ。予後暗すぎる。
浪人留年休学を繰り返して、旧帝大理系を28歳でようやく卒業した俺が入ったのはSESだった。
「理系なら食いっぱぐれない」とか、そういうテンプレを信じたかったんだと思う。
現場に出て、コード書いて、打ち合わせして、なんとなく社会人っぽい顔をしてた。
でも、別にキラキラした何かが起きるわけでもなく、いつの間にか「これでいいのか？」だけが増えていった。
休んだら戻れると思ってた。戻れなかった。結局そのまま退職した。
今は傷病手当金をもらいながら生きてる。
生きてる、って言っても、貯金なんて当然できない。月末が近づくほど心拍数が上がるタイプの生活だ。
「節約してるのに増えない」じゃなくて、「節約しないと減るスピードが怖い」側。
再就職も一応探した。
でもさ、微経験30歳を採ってくれる奇特な会社って、どこにあるんだ。
求人を眺めては、応募条件の“実務◯年以上”で手が止まって、タブを閉じる。これを無限にやってる。
今の一番の問題は、これからどうしていけばいいのか……というより、どうしたいのかが分からないことだ。
「こうなりたい」がない。いや、あったはずなのに、どっか行った。
意思って、体力と一緒に削れていくんだな。
とりあえず、ブルーベリー本を読んでTypeScriptの勉強をしてる。
ページが進むと一瞬だけ「俺、まだ動けるかも」って錯覚できる。
読み終わったら、Reactの勉強でもしようかな。
別に“Reactが好き”とかじゃない。ただ、次のページを用意しておかないと、何もない時間が怖い。
どっちもコレジャナイなら、いったい“コレ”って何なんだろうな。
Rustの悪魔「お前もRust最高と言いなさい！」
まずはarrayの型にreadonlyを付けるのをおすすめします！ https://t.co/6F0dKo3r6E
— suin・読者6万人『サバイバルTypeScript』公開中！ (@suin) October 4, 2025
3ヶ月前、うちの開発チームに新しいエンジニアがやってきた。佐々木（仮名）、29歳。
経歴書を見た時点で、正直ビビった。
React、Vue、Next.js、TypeScript、Go、Rust、Docker、Kubernetes…もう何がなんだかわからない。
「また意識高い系が来たよ」
俺も同感だった。
レガシーなコードを見て「これはちょっと…」みたいな顔をする。
と提案してくる。
うぜぇ。
そんな中で何とか動くものを作ってるんだよ。
綺麗なコードなんて書いてる余裕ないんだよ。
3日で仕上げてくる。
悔しかった。
「やっぱりな。恵まれた環境にいたから、あんなことできるんだよ」
俺たちは佐々木を妬んでいた。
そう思っていた。
ところが先週、佐々木と飲みに行く機会があった。
新卒で入った会社は、まさに俺たちと同じようなSIer。Java とCOBOLでレガシーシステムの保守をやっていた。
でも、佐々木はそこで諦めなかった。
土日は技術書を読み漁り、
オンライン講座を受講し、
個人開発を続けた。
「平日は合計3時間、土日は10時間以上勉強してました。それを4年間続けました」
俺は計算した。
＝6,880時間。
「最初の転職活動は100社受けて全部落ちました。でも諦めずに勉強を続けて、2回目の転職活動でようやく今のレベルの会社に入れました」
俺は恥ずかしくなった。
佐々木を「恵まれた環境にいたから」と妬んでいたが、実際は俺たちと同じ、いやそれ以下のスタートラインから、血のにじむような努力で這い上がってきた人だった。
俺は何をしていた？
「環境が悪い」
「時間がない」
そう言い訳して、
家に帰ったらゲームして、
努力の量だ。
「今からでも遅くないですよ」
と佐々木は言った。
恥ずかしかったけど、頷いた。
毎朝1時間でもいい。変わりたい。
29歳。まだ間に合うよな？
テスラの「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やダッシュボード、プロビジョニング自動化の開発）という具体の採用と整合的である。
今時点の使えそうな Sonnet4 を使ってコード生成とか業務でやる時に Typescript は案外うまくいかないことが多い。
UIとかシンプルなものであれば結構うまくいくけど、graphql, prisma みたいなところになると、token数すごくなるし結局完成しない。
この辺りが、なんとも小骨がひっかかるから。Typescriptの型ってやっぱりあれなのかと思って調べてもらったんだ。
↓↓↓↓↓↓↓
## ソフトウェア工学から見たTypeScriptの3つの根本課題
Web上の専門的な議論や論文では、TypeScriptの課題は主に以下の3点に集約されます。これらはすべて、JavaScriptという土台との不適合性に起因するものです。
1. 不健全な型システム (Unsound Type System)
ソフトウェア工学において、型システムの**「健全性（Soundness）」**とは、「コンパイル時に型エラーがなかったプログラムは、実行時に型エラーを起こさない」という保証を指します。
TypeScriptは、この健全性を意図的に放棄しています。
設計目標の不在: TypeScriptの公式ドキュメントには「健全であること」は設計目標ではないと明記されています。これは、JavaScriptとの互換性や開発者の利便性を優先した、根本的なトレードオフです。
具体的な不健全さ:
配列の扱い: string 型の変数に (string | number) 型の配列を代入できてしまうなど、配列の扱いに不健全な部分があります。これが原因で、実行時に数値を取り出してしまい、string型のメソッドを呼び出してエラーになる、といったことが起こり得ます。
any型と型アサーション: any型の存在や、開発者がコンパイラに「これはこの型で間違いない」と強制する型アサーション（as構文）は、健全性を根本から破壊する「抜け道」です。
関数の引数（Bivariance）: 関数の引数の型チェックが、他の多くの言語（反変）とは異なり、より緩いルール（双変）になっています。これも実用性を優先した結果、理論的な正しさを犠牲にしている例です。
学術的な観点では、この「不健全さ」はTypeScriptの型システムが持つ最大の弱点と見なされています。
2. 構造的部分型（Structural Typing）の罠
TypeScriptは、クラス名などによらず「構造が同じなら同じ型」とみなす構造的部分型を採用しています。これはダックタイピングが主流のJavaScript文化に合わせた賢い選択ですが、ソフトウェア工学的にはいくつかの罠があります。
意図しない互換性: 全く異なる目的で作られた二つのオブジェクトが、偶然同じ構造を持っていたために、型チェックをパスしてしまうことがあります。これにより、ドメイン（業務領域）の意図とは無関係にコードが結合してしまい、予期せぬバグを生む原因となります。
過剰なプロパティの許容: const config: { port: number } = { port: 8080, host: 'localhost' }; のように、変数経由で代入すると、型に定義されていない余分なプロパティ（host）がエラーになりません。これは仕様ですが、開発者の意図しないデータが紛れ込むことを許容してしまい、セキュリティやバグのリスクに繋がります。
これは「TypeScriptの型は、データの『形状』を記述するが、その『意味』や『文脈』を保証しない」という根本的な限界を示しています。
3. 「漏れのある抽象化（Leaky Abstraction）」としての本質
Joel Spolskyが提唱した「漏れのある抽象化の法則」に倣えば、TypeScriptはまさにその典型例です。
TypeScriptは「静的型付け」という抽象化レイヤーを提供しますが、開発者は常にその下にあるJavaScriptの泥臭い現実（undefined, null, thisの挙動など）を意識し続けなければなりません。
抽象化の不徹底: 型を書いているときも、最終的にそれがundefinedになりうることや、thisが何を指すかを常に考えなければなりません。抽象化レイヤーが、下位レイヤーの詳細を隠蔽しきれていないのです。
摩擦コスト: この「漏れ」が、これまで議論してきた「Union地獄」や「境界での型変換の手間」といった、開発上の継続的な摩擦コストを生み出しています。
## 結論
ソフトウェア工学的な観点から見ると、Web上の専門家の議論は我々の対話の結論を強く裏付けています。
TypeScriptの課題は、個別の機能の優劣ではなく、「健全性を犠牲にしてでも、JavaScriptという動的な土台との互換性を最優先した」という、その成り立ちそのものにあります。その結果として生じる「不健全さ」「構造的部分型の罠」「漏れのある抽象化」といった問題は、この言語を使い続ける限り、アーキテクトが向き合い続けなければならない、本質的なトレードオフなのです。
昔のJSの頃も複雑で面倒ではあったけどまぁどうにかなるものだった
実行してエラーが出るところをそのライブラリの変更点に応じて変えるくらいだったし
でもTSになると実行すれば動くものなのに型エラーが山ほど出る
関連ツールも増えてしかも依存関係があるから片方だけあげて見るとかはできず全部上がる
最近あったのはこれまでだと期待通りに推論されてたところが勝手にanyとみなされるようなった
その結果あちこちに暗黙的な any の受取はダメみたいなエラー
さすがに何百ページもあるのにそれ全部に実際の型を書いてられない
型がとても複雑だから推論に任せてたのに
その原因を辿ろうにもTS自体の推論方法が変わったのかライブラリの推論させるための型定義が変わったのかわからない
深く探ろうにもライブラリが多数組合わさってるところで簡単に特定できない
そもそも原因をできたところでどうしようもないと思う
さすがにこの規模はやってられないということでアップデートはせず元のバージョンに戻した
数年もすればきっと大幅に作り直すことになるんだろうし、そのときに一から作り直せばいいんじゃないかなと未来に投げた
ただそのプロジェクトに関わるメンバーの再編でビジネスロジックの実装レベルならできるが開発環境を更新とかそういう事できる人が残ってないわけで、どうなるんだろうな
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）」といった、様々な「
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）」といった、様々な「
めちゃくちゃいっぱいある。
順不同、脈絡なく書いていく。
最近まで知らなかったことだけじゃなく、書いたけど結局わからんことも書く（そっちのほうが多い）。
5Sといって整理、整頓、清掃、清潔、躾だそうだ。
全部日本語じゃねーかって思った。
QCサークルとか、サークルっていうから酒でも飲むのかと思ったら普通に業務じゃないか。
簿記とか会計に疎かったので、営業利益とか経常利益とか違いがわからんかった。
ググってみても、本業の稼ぎが営業利益とか出てきて意味がわからなかった。
経費削減っていうから、会社の支出は全部経費かと思ったら、材労経だろJK
原価といっても全部原価とか直接原価とか標準原価とか次々新しい名前が出てきていまでもわからん。
雑損てなんだ？
散々計算した挙句、所得の定義が国税と地方税で違うとか温厚な俺でもキレそうになる。
税金難しすぎる。
消費税の仕組み、仮払いとか仮受けとかも知らんかった。
一番よくわからない。善意の第三者っていえば、普通に考えて、親切な人だろ？なんで事情を知らない人をいうんだよ？
ヒトのことを、法人に対して自然人というとか、お前頭沸いてんのか？と思った。
法令はそうそう変えられないから、細かいことは政令に政令に定めるとか省令に任せるってことにしといて、パブコメだけで規則変えるのって頭いいけどズルくね？
母数は分母のことじゃないとか、n=100は標本数じゃなく標本サイズだとか、そういうの。
分類とクラスタリングは違うとか、俺がなにか喋るたびに訂正される。
自転車は車道って言われても、5叉路とかになるとどの信号みていいかわからん。
降りて歩行者になってる。
仕組みがよくわからん。
なんでこんな何枚も似たような書類をいろんなところに書かないといけないのか。
事業者に書類書いて、なんちゃら福祉事務所に書いて、自治体に書いてとまあ。
自治体に提出しにいくと、これは福祉課、これは子育て支援課、年収判定は課税課、子育て支援でゴミ袋無料になるから環境課に行けとかいろいろ。
その度に住所と名前を書く。
あとイールドカーブとかも知らんかった。
なんで住所情報を管理するシステムと家族関係を管理するシステムが別なのかわからん。
ジークアクスみてるんだけど、宇宙世紀は教養なのか？知らねーよ。
もう全部わからん。
コマンドプロンプトとPowerShellの違いすらわかんないってのに、TypeScriptとJavaScriptの違いなんか興味もないわな。
下地ってなんだ？
ジェスチャーでエンジンの動きを教えてくれた人がいてさ、水平対向エンジンはこう、Vツインはこう、と熱心にモノマネしてくれたんだけど、気が狂ったのかと思った。
実は、そもそも4サイクルと2サイクルの仕組みすらわかってないんだ。
ディーゼルはまた別なんだろ？
前項でエンジンわからんって言ったけど、身の回りの電化製品とかもほとんどわからん。
株式だってよくわかってないし、先物とかオプションとかスワップとかって説明されてもわからん。
生理周期とメンタルが関連するって聞いたけど、機嫌が悪いのは生理前なのか生理のときなのか生理直後なのか。
聞くのも憚られるから、女が怒ってるときは「なんかわかんないけどホルモンのせいだな」と諦めてる。
そもそも、自民党と共産党以外、どの党がどういう支持母体でなりたってるのかわかってない。
htmlも覚えたのにcssに取って替わられるし、JavascriptだフレームワークだモダンCSSだJamstackだTypeScriptだやってらんねーわ。
