AIと踊る
ChatGPT 3.5がリリースされた当時のことを今でも覚えている。翻訳ツールとしては優秀だったが、プログラミングに使うとなると、スクリプトや単純な関数を書く程度のことしかできなかった。
2023年、CursorはまだBeta段階で、目玉機能はTabによる自動補完だけだった。それ以前にGitHub Copilotも使ってみたが、精度が低すぎて使い続けるのをやめてしまった。
その後GPT-4oが登場し、モデルの能力の飛躍を確かに実感したが、プログラミングという行為は、僕の目には依然として人間の領域に映っていた――AIは手助けにはなるが、本当に取って代わることはできないと。
2024年、Cursorは単なるTabオートコンプリートからAI Agentを導入し、開発において「たまに試す」ものから「不可欠」な存在へと変わった。LLMはすでに単独で動作するデモコードを書けるようになっていたが、本番（production）レベルのコードには依然として多くの人的介入とレビューが必要だった。
そして2025年。各社のモデルはほぼ月単位で進化を遂げた。年央にClaude Codeの存在を知ったとき、僕は初めてモデルの質的な飛躍を肌で感じた。開発者の深いレビューや指示が必要とはいえ、実用に耐えうる設計を書き上げ、さらにはその設計に沿ったコードまで書けるようになっていたのだ。
元々は人間が手書きしていたコードが、1年足らずの間に、AI Agent主導のモデルへと急速に移行しつつある。
2026/02/26、Cursorの共同創業者であるMichael Truellがツイートを投稿し、このプロセスを3つの時代に明確に区分した：
- 第一の時代はTab――AIが反復的な作業を識別して自動化し、開発者はTabキーを叩き続けてコードを書く
- 第二の時代は同期型Agent――エンジニアがプロンプトを通じてAIに指示を出し、インタラクティブに協調しながらタスクを完了させる
- 第三の時代――Agentがクラウド上の仮想マシンで数時間にわたって独立して稼働し、より大規模なタスクを自律的に完遂する。エンジニアは最後に成果をレビューするだけでよい
ほんの1年余りで、ソフトウェア開発は完全に様変わりした。
AIがソフトウェア開発に取って代わる
当時、「AIがソフトウェア開発やソフトウェアエンジニアに取って代わる」という言説を目にしたとき、僕は鼻で笑っていた。AI企業のポジショントークや誇大広告に過ぎないと思っていたのだ。
第一線の開発者として、当時のモデルのレベルは日常の開発を代替できるものには到底及ばなかった。単純なスクリプトを書いたり関数をリファクタリングしたりする程度なら問題ないが、コンテキストが増え、コードが複雑になると、モデルは全く処理できず、返ってくる回答も要領を得ないものばかりだった。
だが、モデルの能力の向上速度は凄まじかった。元々はAIが単なる補助役に過ぎず、コードの大部分は人間が書いていた。それが今ではAIが書くコードの割合が半分を超え、大部分のコードがAIによって生成され、人間はレビューや設計を担当するようになった。僕に初めてこの感覚をもたらしたのは、2025年の半ばにClaude Codeを触り始めてからのことだった。
システム設計やドキュメント作成にすらAIを参加させるようになり、会議の議事録に至っては完全にAIによって自動生成されるようになった。
理由は単純で、モデルの能力が日常の開発をこなせるレベルにまで達し、中にはコードを読まずにそのままプロダクトをイテレーションする人すら現れたからだ。
これで本当にいいのだろうか？ 以前の僕なら大きな疑問符を投げかけていただろう。だが今、僕の態度は徐々に変わりつつある。一定の条件下においては、人間の関与こそが最大のボトルネックになっているのが現実だ。
I ship code I don’t read
また、考えるべきなのは「この言葉を誰が言ったのか」という点だ。Wiwiが自身のブログでかつてこう書いていたように：
僕たちの心の中には、人それぞれに密かに「IQのデフォルト値」が設定されている。同じくだらない言葉でも、「デフォルト値が高い」人の口から出れば、僕たちは自発的に理由を探し、その深い意味を解釈しようとする。一方で「デフォルト値が低い」人が言えば、即座にバカだと決めつけてしまう。
Peter Steinbergerは、もともとiOSコミュニティで活躍していたエンジニアで、2011年にPDF SDKの「PSPDFKit」を開発し、一開発者向けツールから多くの企業に採用されるドキュメントテクノロジー企業へと育て上げた人物だ。
バーンアウトによって一時期プログラミングから離れていた彼は、AIをきっかけに再びコードを書く楽しさに目覚め、OpenClawを開発した。少なくともプログラミングに関して、彼の技術力に疑いの余地はない。
ソフトウェア開発のあり方は変わったが、核となるソフトウェアエンジニアリングの原則は変わらない。システム設計、ドキュメントの記述、テストの作成といった事柄の重要性は、むしろ高まっている。
テストケースはAIが正しく仕事をするための境界線であり、ドキュメントはAIがコンテキストを理解するための基盤であり、システム設計は高速なコード生成によって全体構造が暴走しないように保つためのものだ。AIに任せられることは増えていく一方であり、これらの原則こそが人間が主導権を握り続けるための手段なのだ。後にこれは「ハーネスエンジニアリング（Harness Engineering）」と呼ばれるようになった。
未来において何が重要になるのか？
開発のハードルがかつてないほど下がり、実行のコストがゼロに近づくとき、「方向性」がすべてになる。
これまでの開発経験は、ここにおいては諸刃の剣だ。「知識の呪い」になることもあれば、自分を一歩リードさせる強みになることもある。
ハーネスエンジニアリングは単にソフトウェアエンジニアリングを言い換えただけに過ぎないと言う人もいる。
確かに、AIの守備範囲をどう制限するか、AIに閉ループで検証を行わせるか、何が良くて何が悪かを定義する明確な基準をどう持つかといった概念は、以前から存在していたものだ。
これは最近読んでいる本『機制化之神』を思い起こさせる。
自分が当たり前だと思っている「良い状態」を、参照可能で再現可能な基準に落とし込む。この作業は、以前はチームでの協調をスムーズにするためのものだったが、今ではAIに再現させるためのものになった。これこそがハーネスエンジニアリングの神髄だ。
方向性があるだけでは不十分だ。AIはプロジェクトを自力で前進させることはできない。ステークホルダーやユーザーと対話し、他部署に自分の提案が実現可能であることを納得させ、組織内の不条理や人間関係の摩擦にも立ち向かわなければならない。これらはAIが解決できることではない。
責任感こそが、僕がこの1年で学んだ最も重要なことだ。
以前の働き方やチームの分業体制では、「とりあえず自分の持ち場をきちんとこなせばいい」と、責任の範囲を明確に線引きしがちだった。
しかし同じAIを使っても、人によって成果や結果はまったく異なってくる。その違いは、成果に対して責任を持つ覚悟があるかどうかにかかっている。
これは『半沢直樹』を想起させる。彼が担当する案件であれば、どんなに理不尽な環境や上司に遭遇しても、あらゆる手を尽くして一つひとつ突破し、クライアントの次の一手、十手先まで先回りして考える。
スキルの組み合わせについても再考が必要だ。AIが70点の仕事をできるとすれば、人間が80点を出したところで遠く及ばない――AIのほうが安く、素直で、使い勝手がいいからだ。純粋なスペシャリストの道を歩むにはトップクラスの能力が必要で、Andrej Karpathyのような人材はどの企業も喉から手が出るほど欲しがるが、それはピラミッドの頂点の話だ。
多くの人にとって、僕がお勧めしたいのはゼネラリストに特定の専門分野を掛け合わせたルートだ。単にかじる程度ではなく、それぞれの領域で最低でもシニアレベルの解像度を持った理解が必要になる。これからの時代、職能の境界線はますます曖昧になっていくだろう。デザイン、アーキテクチャ、開発、テスト、デプロイから運用に至るまで、的確な判断を下すには十分に深い理解が求められる。
そして最後に「センス」だ。
アーキテクチャ、技術選定、システムデプロイ、UI/UX。これらすべての意思決定の根底には、一つのコアとなる原則が必要だ。センスとは、自らの経験、バックグラウンド、価値観を通じて形作られるその原則のことだ。それは、幾度とない実践の積み重ねからしか生まれてこない。
センスは技術的な意思決定に限らず、プロダクトそのものに対する判断にも及ぶ。僕自身を含め、開発者はプロダクトに最も近い場所にいて、個々の機能の実装詳細を熟知しているはずなのに、プロダクトそのものに対しては何の考えも持っていないことが少なくない。要望が来たら作り、できたら納品するだけで、「この機能は本当にユーザーの課題を解決しているのか？」と一歩引いて問いかけることはめったにない。
ソフトウェアエンジニアは今後、「Product Builder」の方向へと進むことになる。単にものを作るだけでなく、プロダクトそのものに考えを持ち、自ら改善の方向性を提示しなければならない。AIが実装コストを極限まで押し下げた今、「何を作るか」や「なぜ作るか」を定義できる人は、単に「どう作るか」を知っているだけの人よりもはるかに価値がある。
ソフトウェアエンジニアの新しい姿――Forward Deployed Engineer
ここでForward Deployed Engineer（FDE）という職種を起点に考えてみたい。これはソフトウェアエンジニアのキャリアにおいて、今後挑戦しうる道の一つかもしれない。以下はOpenAIのForward Deployed Engineerの求人票だ。
Forward Deployed Engineerとは、クライアントの現場に直接入り込んで働く役割だ――実際の業務フローを観察し、ペインポイントを見つけ出し、自らの手でソリューションを構築して、プロジェクトをローンチまで牽引する。
名だたる企業が一斉にAIの導入を進めていること、それがFDEの需要が爆発している理由だ。
AIの導入は、Vibe Codingでさくっと解決策を一つ作れば済むような話ではない。それは往々にして企業に常駐し、彼らの難題に向き合い、社内チームと協調し、調整を図ることを意味する。
Engineerという肩書きがついている以上、日々の業務の中には自らの手でコードを書いて解決すべき問題が山ほど存在する。PoCの作成、本番レベルのコードの記述とデプロイ、そして現場のプロダクトチームとの協働などが含まれる。
The Pragmatic Engineerによれば、FDEの責務はスタートアップのCTOに似ており、少人数チームでリスクの高いプロジェクトの実行をエンドツーエンドで主導する。Salesforceの分析によると、2025年の最初の9か月間でFDEの求人数は800%以上増加し、Salesforce自身も1,000人規模のFDEチームを立ち上げると発表した。
この職種の核心的な能力は、曖昧な要求を実行可能な具体的な方針へと落とし込む力だ。
クライアントは「何かがうまくいっていない」ことは分かっていても、自分が何を求めているのかを言葉でうまく説明できないことが多い。FDEの仕事は、その混沌の中から輪郭を見出し、それを形あるプロダクトへと具現化することだ。
短期間でクライアントの信頼を勝ち取り、本当の課題を打ち明けてもらう必要がある。関係者を説得し、提案の実現可能性を信じてもらう必要がある。そして限られたリソースと厳しい納期の現実の中で、不完全であっても十分に機能する答えを出さなければならない。
開発ツールとしてのAIが持つ諸刃の剣
Huliが書いた『AI 與鴨子，惰性與真實』や、高見龍が書いた『AI 時代寫程式，你是在學習還是在偷懶』で述べられているように、彼らは基礎の重要性を説き、Vibe Codingが基礎を学ぶ動機を奪いつつあると警鐘を鳴らしている。
僕はこの2本の記事にいくつかの共通する概念があり、同時に強く共感している：
- AIの出力を盲信しないこと：アヒルの理論はダックタイピング（Duck Typing）に由来する。AIの生成物を例えるのに非常に言い得て妙だ――「動けばそれでいい」というのは、かつては開発者の間での自虐ネタだったが、今本当に動くだけで満足してしまうなら、それは単なるVibe Codingと同じだ
- テストの重要性が大幅に向上したこと：両記事ともテストの重要性に触れている。AIに自己検証を行わせるだけでなく、テストはAIの暴走を防ぐための命綱でもある
- AIは補助であること：AIを使って学習を加速させたり、プロダクトの方向性を考えることやユーザーニーズを明確にするといった、より価値の高いタスクに時間を使うべきだ
- 判断力と基礎力：しっかりとしたプログラミングの基礎がなければ、初学者はAIが提示したコードが良いものなのか悪いものなのかすら判断できない
AlphaGoが遺した示唆
僕はよく、オリンピックの意義について考えることがある。人類の発展に何か重大な貢献をしているのだろうか？ もし明日から誰も野球をしなくなり、あらゆる競技大会が開催されなくなったら、世界は何一つ変わるのだろうか？
長く考えた末、僕は一つの結論に至った。極限への探求それ自体に意味があり、たとえそれが世界をより良くするものでなくても構わないのだと。さらに突き詰めて言えば、生存を維持すること以外、人間の行動のほとんどは本質的には「無意味」かもしれないが、それでも僕たちはそれをやり続け、心から楽しんでいる。
このことはAlphaGoを思い出させる。2016年にAlphaGoが人間の棋士を打ち負かしたが、囲碁の大会が消滅することはなく、人類が碁を打つのをやめることもなかった。
むしろ棋士たちはAIから学び始め、何百年も続いてきた定石や思考の枠組みを打ち破り、先人が足を踏み入れたことのない手を指すようになった。AIの介入によって、囲碁の世界はより豊かになったのだ。（なぜか黑嘉嘉の動画が僕のYouTubeのおすすめにずっと表示され続けているけれど）
では、プログラミングも同じ道を辿るのだろうか？
いつの日か、手でコードを書くことが純粋な趣味や嗜みになるのかもしれない。万年筆で文字を書いたり、フィルムカメラで写真を撮ったりすることを選ぶ人がいるように。それは効率のためではなく、そのプロセスそのものを楽しむためだ。コードの大部分はAIが生成し、それでも手書きにこだわる人々は、もはや「必要」ではなくなった職人技を楽しんでいるに過ぎない。
僕にはまだその答えが出ていない。
まだ情報系の学部に進学する必要はあるのか？
情報系の学生は、本来もっと難易度の高い課題を解決するべき存在だ。大学の情報系学部に入る目的が、4年後にCRUDアプリケーションを一つ作れるようになることだけなら、確かに進学する必要はない――そんなものは今やLLMがこなせてしまうからだ。
だが裏を返せば、誰もが極めて低いハードルでプロダクトを作れるようになったからこそ、より難易度の高い課題の価値が際立つことになる。では「より難易度の高い課題」とは何だろうか？
思いつく例をいくつか挙げてみよう：
- 次世代の計算アーキテクチャ――GoogleのTPUやNVIDIAのTensor Coreのような専用設計はすでに登場しているが、現在のLLMの推論フェーズにおけるボトルネックは、依然としてメモリ帯域幅とレイテンシに阻まれている
- コンパイラとプログラミング言語の設計――AIが大量のコードを生成するとしても、そのコードの正当性、安全性、パフォーマンスを最終的に決定づけるのは、低レイヤーの言語とコンパイラだ
AIはアプリケーション層の敷居を下げたが、同時に低レイヤーにおける挑戦の重要性をより高め、より困難なものにした。情報系学部の価値は、単にコードを書くことだけにあるのではなく、こうした難問を解決できる力を養うことにある。
自分が情報系出身ではないと強調するな。今世紀においては、実力がなければ誰もが非情報系出身だ Jserv
新たなる封建時代
独占と封建の違いは何だろうか？ 独占は価格をコントロールし、封建は能力をコントロールする。独占はものを高く買わせ、封建はそこから離れられなくさせる。
最近、AI時代における権力の集中は、果たしてこのどちらに近いのだろうかとずっと考えている。
過去のテクノロジーによる独占は誰もが経験してきた。マイクロソフトがOSを独占していた時代、開発者はWindowsを「使わざるを得なかった」。Googleが検索を独占したとき、広告主はGoogle Adsを「買わざるを得なかった」。しかし、これらの独占が影響を与えたのは分配であり、誰がいくら金を手にするかという問題だった。
だが、AIモデルが人間の労働を直接代替できるようになれば、独占者が左右するのはもはや価格だけではない。僕たちの労働に価値があるかどうかそのものになる。
伝統的な封建社会において、小作農は地主から離れて生きていくことができなかった。資本主義はこの従属関係を打ち破り、誰もが市場に参加し、資本を蓄積し、自分のスキルを武器に資本市場で居場所を勝ち取ることができるようになった。
今、その状況が逆戻りしつつある。AIを活用した開発を行うには、Claude CodeやCodexが必需品となっている。これらのツールはAnthropic、Google、OpenAIの手に高度に集中しており、技術的・資本的なハードルは高すぎてほぼ模倣不可能だ。もし使わなければ、周囲の同業者たちがこぞってAIで開発を進める中、自分だけが競争上の圧倒的不利に立たされる。このプレッシャーは今後強まる一方だろう。
これは単なる資本の独占に過ぎず、何も目新しい話ではないと言う人もいるかもしれない。
しかし、決定的な違いは交渉の切り札（手持ちのカード）にあると僕は考えている。歴史上、労働条件が改善されてきた過程――労働時間の短縮や賃金の引き上げ――の多くは、システム側が自発的に与えてくれたものではなく、労働運動や政治的圧力を通じて、切り札を武器に勝ち取ってきたものだ。
労働者にとって最大の切り札は「お前は俺たちがいなければ何もできない」という点だった。ストライキを起こせば工場は止まる。しかし、モデルがストライキを無力化できるなら、ストライキそのものがもはや武器にならなくなる。
僕が心底不安を覚えるのは、知識労働者が一つの集団として構造的な交渉力を失いつつあり、それに代わる新たな切り札がまだ現れていないことだ。
LlamaやMistral、DeepSeekといったオープンソースモデルは確かに参入障壁を下げている。しかし汎用的な能力においては、御三家との差は依然として歴然としている。モデルの訓練に必要なデータ規模、計算リソースの規模、そして背後にあるエンジニアリングの蓄積は、オープンソースコミュニティが短期間で追いつけるような次元ではない。
オープンソースモデルの進化や個人向け計算能力の普及は、あるいはこの時代における印刷術になるのかもしれない。だが、印刷術が発明されてから実際に既存の権力構造を揺るがすまでには数百年を要した。僕たちにそれほどの時間が残されているのかどうか、僕には分からない。
AI Slopについて
最近、ネット上にAIによるゴミコンテンツ（Slop）が溢れかえっていることへの不満をよく耳にする――いかにもAIらしい口調で書かれた粗製乱造の記事や、明らかにAIによって生成された画像や動画。人々はこの現象をAI Slopと呼んでいる。
ある技術が工業化されるたび、市場には必ず安価で粗悪な製品が大量に溢れ出す。ハンドドリップコーヒーの愛好家の目から見れば、インスタントコーヒーは救いようのないSlopだろう。（ちなみに僕はハンドドリップもインスタントも両方好きだ）
多くの人は品質を追求していない。あなたにとってのAI Slopは、彼らにとっては「ちょうどいい」成果物なのだ。ハンドドリップ愛好家から見れば、僕自身も品のない俗物に映っているかもしれない。
Slopとは、技術が真に普及した後に訪れる必然的な産物だ。見方を変えれば、ソフトウェア開発もまた工業化の道へと足を踏み入れようとしていると言える。
AIは、文章の筋が通り論理構成もしっかりしているが、血の通った見解が一切含まれていない記事をいとも簡単に生成できる。だからこそ、独自の視点や経験、人間味のあるコンテンツは、むしろ希少価値を帯び、より貴重なものになっていくはずだ。
市場はいずれ自らバランスを見つけ出すだろう。
スピードを落とすこと
AIが書くコードは、人間が書くものより「正しい」かもしれない。しかし、デバッグの過程で偶然遭遇したエッジケースや、落とし穴にハマった末に培われた直感こそが、真に価値のあるものなのだ。センスとは、不完全な経験の中からこそ育まれる。
AIはアウトプットを極限まで容易にした。
ブログを書くこと、ノートを取ること。こうした「スローな」営みは、本質的には思索と内省のプロセスだ。自分の思考を整理する行為そのものが、猛スピードに押し流されないための抵抗なのだ。
むしろ、一見すると「時間の無駄」に思えるようなことが重要になってくる。手でコードを書いて低レイヤーの原理を理解すること、仕事とは無関係の本を3時間かけて読むこと、人と顔を合わせて雑談すること、数十人しか見ていないブログを運営し続けること。こうしたことのリターンは、思いもよらない瞬間に突然姿を現す。
僕は、あなたの不完全さをもっと見たいし、あなたがどんなことに悩んでいるのかを聞いてみたい。
経験の閾値
大谷翔平選手が最近NHKのインタビューで語った言葉がある。「過程の積み重ねは大事だが、技術的なコツを掴むのは一瞬」
過程の積み重ねは大事だが、技術的なコツを掴むのは一瞬
あらゆるスキルの習得において、まったく同じことが言える。閾値に達するまでの積み重ねが重要なのは言うまでもないが、本当に変化が起きる瞬間は、いつだって一瞬なのだ。
その変化の瞬間が訪れるまで、努力を継続できるかどうかがすべてだ。
AI時代における焦燥感の大半は恐怖から生まれ、恐怖は未知から生まれる。
多くの物事は、自ら行動を起こし、経験を蓄積して初めて実感できるようになる。AIはあなたの代わりにその閾値を越えてはくれない。AIは積み重ねを加速させることはできても、あの「一瞬の閃き」に辿り着けるのは、自分自身の足で歩んだ人間だけだ。
AIと踊る
AIを使いこなし、自分を加速させるブースターにしよう。反復的な作業はAIに任せ、浮いた時間をあなたにしかできないことに充てるのだ。課題を定義し、方向性を描き、人と対話し、成果に対して責任を持つ。
Slopはいずれ通り過ぎていく。過渡期とはそういうものだ。インスタントコーヒーがスペシャリティコーヒーを駆逐しなかったように、AIが生成したコンテンツも、血の通った視点を持つ創作を消し去ることはない。
スピードを落として向き合うことには、自ら進んで追求する価値がある。一見すると費用対効果の低い積み重ねこそが、予期せぬ瞬間に実を結び、あなたを他者とは違う唯一無二の存在にしてくれる。
AIがますます強力になっていく時代だからこそ、人と人との繋がりは一層かけがえのないものになる。AIはコードを書き、資料を整理し、レポートを生成してくれるかもしれない。だが、信頼を築き、経験を分かち合い、あなたが道に迷ったときに本音の言葉をかけてくれるのは、AIではないのだから。
この記事が気に入ったら、ぜひ手紙（メール）であなたの考えを聞かせてほしい！
関連記事
- 改めて考えるJWTとSession Cookie JWTとSession Cookieはそれぞれどのような場面に適しているのか？セキュリティ、実装コスト、ユーザー体験の観点から、この古典的なテーマを改めて整理する。
- 2026年、AWSはもういらないかもしれない クラウドプラットフォームを選ぶ前に、チームがAWSに支払っている真の代償をまずはっきり計算してみよう
- なぜサービスデプロイに ECS を使うべきなのか AWS上でコンテナサービスを動かす際、なぜECSがEC2やEKSよりも現実的な選択肢なのか、そしてデプロイの複雑さがいかにコストを蝕むのか
- ソフトウェアエンジニアリングの幻滅、再び LLMモデルの大幅な進化によってソフトウェア開発のあり方は完全に変わり、アプリケーションを1本作るのにほとんど参入障壁がなくなった