AIと踊る
# ソフトウェアエンジニアリングChatGPT 3.5が登場したばかりの頃は、翻訳ツールとしては便利だったが、プログラミングに使うとなると、せいぜいスクリプトや簡単な関数を書く程度だった。
2023年、CursorはまだBeta段階で、売りとしていた機能はtab補完だけだった。それ以前にはGitHub Copilotも使ったことがあるが、試した結果、精度が低すぎて使い続けるのをやめた。
その後GPT-4oが出て、確かにモデル能力の飛躍を実感した。だが、プログラミングという行為は、僕の中では依然として人間の領域だった。AIは助けにはなるが、まだ本当に代替することはできなかった。
2024年から、状況は静かに変わり始めた。Cursorは単なるtab補完からAI Agentを加え、開発は「たまに試すもの」から「不可欠なもの」へ変わった。LLMはすでに単独で動くDemoを書けるようになっていたが、productionレベルのコードには、なお大量の人手による介入とレビューが必要だった。
そして2025年。各社のモデルは、ほぼ月単位で進化していった。年の半ばにClaude Codeの存在を知ったとき、僕は初めてモデルの質的飛躍を感じた。開発者の深い関与によるReviewと指示は必要だが、すでに実用に足る設計を書けるし、その設計に従って対応するコードまで書けるようになっていた。
かつて人間が手で書いていたコードは、1年も経たないうちに、AI Agent主導の形へと急速に移り始めた。
2026/02/26、Cursorの共同創業者Michael Truellが投稿したツイートで、この過程は明確に3つの時代に切り分けられた。
- 第1の時代はTab補完——AIが反復的な作業を見つけて自動化し、開発者はtabを押しながらコードを書く
- 第2の時代は同期型Agent——エンジニアがpromptでAIを指揮し、やり取りしながら協力してタスクを完了する
- 第3の時代——Agentがクラウド上の仮想マシンで数時間にわたって独立稼働し、より大規模なタスクを自律的に完遂し、エンジニアは最後に成果をレビューするだけでよい
たった1年あまりで、ソフトウェア開発はすっかり別物になった。
AIによるソフトウェア開発の置き換え
当時、僕は「AIがソフトウェア開発やソフトウェアエンジニアを置き換える」という話を見ても、鼻で笑っていた。AI企業の営業トークや誇張だと思っていたからだ。
第一線の開発者として、その頃のモデル水準では日常開発を置き換えることなど到底できなかった。簡単なスクリプトや関数のリファクタリングならまだしも、contextが増え、コードが複雑になれば、モデルはまったく対応できず、返答も支離滅裂なことが多かった。
ところがモデルの能力は驚くほど速く進歩した。以前のAIはあくまで補助役で、コードの大半は人間が書いていた。今ではAIが書くコードの比率が半分を超え、多くのコードはAIが生成し、僕たち人間はそれをレビューし、設計する役目になっている。
システム設計やドキュメント作成にまでAIを関与させ、議事録に至っては完全にAIが自動生成するようになった。
理由は単純で、モデルの能力がすでに日常開発をこなせるところまで来ており、なかにはコードを読まずにそのまま製品を反復改善している人までいるからだ。
それは本当に良いことなのか。以前の僕なら大きな疑問符をつけていただろう。だが今は少しずつ考えが変わっている。ある条件下では、人間の関与こそが最大のボトルネックなのだ。
I ship code I don’t read
もうひとつ考えるべきなのは、この言葉を誰が言ったのか、という点だ。Wiwiが自分のブログで触れていたように、
誰の心の中にも、こっそり「この人は頭が良いはずだ」というデフォルト値がある。同じくだらない話でも、デフォルト値が高い人が言えば、僕たちは勝手に理由を探し、深い意味を読み取ろうとする。デフォルト値が低い人が言えば、すぐに「こいつはバカだ」と判断する。
Peter SteinbergerはもともとiOS界隈で活躍していたエンジニアで、2011年にはPDF SDK「PSPDFKit」を作り、開発者向けツールを企業向けの文書技術会社へと育て上げた。
Burnoutでしばらくプログラミングから離れていた彼は、AIをきっかけに再びコードを書くのを好きになり、OpenClawを開発した。少なくともプログラミングに関しては、彼の技術力に疑いの余地はない。
ソフトウェア開発は変わったが、ソフトウェアエンジニアリングの核心原則は変わっていない。システム設計、ドキュメント作成、テストを書くことの重要性は、むしろ増している。
テストケースはAIがきちんと仕事をするための境界であり、ドキュメントはAIが文脈を理解するための土台であり、システム設計は全体アーキテクチャが高速な生成によって崩壊しないようにするものだ。AIに任せられることは今後ますます増える。そしてこれらの原則こそが、人間が主導権を握るための方法なのだ。
だが、品質管理はテストを書くことだけではない。
僕のこれまでの経験では、第一線の開発者はたいてい良いQAではない。
開発者は自分の実装に詳しすぎるがゆえに、無意識にバグを生みやすい操作経路を避けてしまい、テストでは常にhappy pathを通ってしまう。
同時に、要件の理解も実装の仕方に縛られがちだ。コードの書き方を知っていると、一歩引いてユーザーの視点で見直すのが難しくなる。これは能力の問題ではなく、役割による構造的な制約だ。
未来、何が重要になるのか？
実行コストが限りなくゼロに近づくなら、方向性こそがすべてだ。ユーザーの問題を、明確で実行可能な計画へと変換することが重要になる。
これまでの開発経験は、ここでは諸刃の剣だ。知識の呪いにもなりうるし、自分を先行させる武器にもなりうる。
Harness EngineeringはSoftware Engineeringの言い換えにすぎない、という人もいる。確かに、AIの範囲を制限すること、AIに閉ループで検証させること、何が良くて何が悪いかを明確な基準で定義すること。こうした考え方は以前から存在していた。
最近読んでいる『機制化之神』を思い出す。
自分にとって当たり前の「良い」を、参照可能で再現可能な基準に変える。昔はチーム協業を円滑にするためだったが、今はAIにも再現させるためでもある。これがHarness Engineeringの本質だ。
方向性があるだけでは足りない。その方向を現実に押し進める必要がある。
AIはプロジェクトを前に進められない。僕たちは利害関係者やユーザーと対話し、他部門を説得し、自分たちの案が実現可能だと示さなければならない。組織の中にある奇妙で厄介な問題にも向き合う必要がある。これらはAIでは解決できない。
責任感は、この1年で僕が最も重要だと学んだことだ。
以前の働き方やチーム分業では、責任の線引きが明確で、「とにかく自分の仕事をきちんとやればいい」と考えがちだった。
だが同じAIでも、人によって出力と結果はまったく異なる。違いは、成果に責任を持つ覚悟があるかどうかだ。
半沢直樹を思い出す。彼は自分が担当する案件なら、どれほど理不尽な環境や上司に遭っても、一つずつ突破しようとする。さらにその先、顧客の次の一手、十手先まで考える。
能力の組み合わせも、今あらためて考え直す必要がある。AIが70点を出せるなら、80点に達するだけではまったく足りない。AIは僕より安く、従順で、使いやすい。純粋なスペシャリスト路線にはトップレベルの能力が必要で、Andrej Karpathyのような人物は今も各社が欲しがるが、それはピラミッドの頂点の話だ。
多くの人に僕が勧めたいのは、ジェネラリストに加えて何か一つの専門分野を持つ道だ。表面をかすめるだけではだめで、各分野について少なくともSeniorレベルの認知を持つ必要がある。将来、職能間の境界はますます曖昧になる。設計、アーキテクチャ、開発、テスト、デプロイ、運用まで、良い判断を下すには十分に深い理解が求められる。
最後は品味だ。
アーキテクチャ、技術選定、システムデプロイ、UI/UX。これらの意思決定の背後には、ひとつの中心原則が必要になる。品味とは、自分の経験、背景、価値観から形作られるその原則のことだ。それは何度も実践を重ねることでしか育たない。
そして品味は技術的判断だけに限らない。製品そのものに対する判断も含む。僕自身も含めて、開発者は本来プロダクトに最も近い存在で、各機能の実装詳細を隅々まで知っているのに、必ずしも製品について何か意見を持っているとは限らない。要件が来たら作り、終わったら納品する。それだけで、「この機能は本当にユーザーの問題を解決しているのか」と一歩引いて問うことは少ない。
ソフトウェアエンジニアは、これからProduct Builderの方向へ進むべきだ。ただ作るだけではだめで、製品そのものに対する考えを持ち、改善の方向性まで自ら提案できなければならない。AIが実装コストを極限まで下げる時代には、「何を作るか」「なぜ作るか」を定義できる人のほうが、「どう作るか」しか分からない人より価値が高くなる。
ソフトウェアエンジニアの新しい形——Forward Deployed Engineer
僕はForward Deployed Engineerという職種を起点に考えたい。これこそが、ソフトウェアエンジニアのキャリアの未来として試す価値のある道かもしれない。以下はOpenAIのForward Deployed Engineerの募集要項だ。
Forward Deployed Engineerは、顧客の現場に直接入り込んで働く役割だ。実際の業務の流れを観察し、痛点を見つけ、自ら解決策を作り上げ、プロジェクトをリリースまで押し進める。
あらゆる大企業がAI導入を進めている。それがFDE需要が爆発している理由だ。
AI導入は、Vibe Codingで一発解決できるものではない。多くの場合、企業に入り込み、彼らの難題に向き合い、社内チームと協力し、調整することを意味する。
Engineerという職名が存在するのは、日常業務の中に、依然として自分の手でコードを書いて解決しなければならない問題が大量にあるからだ。PoCの作成、productionレベルのコードの記述とデプロイ、現場のプロダクトチームとの共同作業などが含まれる。
The Pragmatic Engineerによれば、FDEの役割は新興企業のCTOに似ており、小規模チームの中で高リスク案件を端から端まで握ることにある。Salesforceの分析では、2025年の最初の9か月でFDEの求人は800%以上増加し、Salesforce自身も1,000人規模のFDEチームを作ると発表した。
この役割の核心能力は、曖昧な要件を実際に実行可能な方向へ変換することだ。
顧客は自分たちのどこがうまくいっていないかは分かっていても、何が欲しいのかははっきり言えないことが多い。FDEの仕事は、この混沌の中から輪郭を見つけ、それを現実のものにすることだ。
短時間で顧客の信頼を得て、本当の問題を話してもらう必要がある。利害関係者を説得し、自分の案が実現可能だと信じてもらう必要がある。資源が限られ、期限が迫る現実の中で、不完全だが十分に良い答えを出さなければならない。
AIという開発ツールの諸刃の剣
Huliの『AI 與鴨子，惰性與真實』や高見龍の『AI 時代寫程式，你是在學習還是在偷懶』でも触れられているように、彼らは基礎が重要だと考え、Vibe Codingが基礎を学ぶ動機を奪っていると見ている。
僕はこの2本の文章にはいくつか共通する概念があり、しかもそれらに強く共感している。
- AIの出力を盲目的に受け入れないこと：Duck理論はDuck Typingに由来する。AIの出力を比喩するには非常に適切だ。以前は「動けばいい」は開発者の間の冗談だったが、今それだけを求めるなら、それはVibe Codingと同じだ
- テストの重要性が大きく増したこと：両方の記事でテストの重要性が語られている。テストはAIの自己検証を助けるだけでなく、AIが暴走しないようにする手段でもある
- AIは補助であること：AIは学習を加速したり、より価値の高い仕事を処理したりするために使うべきだ。たとえば製品の方向性を考えたり、ユーザー要件を明確にしたりすることだ
- 判断力と基礎能力：しっかりしたプログラミング基礎がなければ、初心者はAIが出したコードの良し悪しを判断できない
AlphaGoからの示唆
僕はよくオリンピックの意味について考える。人類の発展にどれほどの貢献があるのか。もし明日から誰も野球をしなくなり、どんな試合も開催されなくなったら、世界は何か変わるのか。
長く考えた末、僕は一つの結論に至った。限界を追い求めること自体に意味があるのだ。それが世界をより良くしないとしても。さらに踏み込めば、生存を維持すること以外、人間の行動の大半は実は「無意味」だ。それでも僕たちはそれをやめないし、むしろ楽しんでいる。
それでAlphaGoを思い出した。2016年に人間の棋士を打ち負かしたが、囲碁の大会は消えなかったし、人間が碁を打つのをやめることもなかった。
むしろ棋士たちはAIから学び、何百年も続いてきた定石や思考を打ち破り、先人が一度も通らなかった手を打つようになった。AIの介入によって囲碁はより豊かになった。（なぜか黒嘉嘉がずっと僕のYouTubeおすすめに出てくる）
では、プログラミングも同じ道をたどるのだろうか。
いつか手書きのコードを書くことが、万年筆で文字を書くことやフィルムカメラで写真を撮ることのような、純粋な楽しみになるのかもしれない。効率のためではなく、その過程そのものを楽しむためにやる。コードの大半はAIが生成し、それでも手書きを貫く人たちは、もはや「必要」ではない技を味わっているだけなのかもしれない。
僕にはまだ答えがない。
それでも資工系に行く必要はあるのか？
資工系の学生は、もともともっと難しい問題を解くべきだ。もし資工系に入る目的が、4年後にCRUDアプリを1つ作れるようになることだけなら、確かに学ぶ必要はない。なぜならLLMはすでにそれをできるからだ。
だが逆に考えると、誰もが低いハードルでプロダクトを作れるようになった今、より難しい問題の価値はむしろ高まっている。では「より難しい問題」とは何か。
いくつか例を挙げる。
- Linux kernelの進化——AIワークロードはOSに新しい要求を突きつけている。より優れたscheduler、より安全なmemory model、高い予測可能性を持つreal-timeシステムだ。これらの問題は、AIがコードを書けるようになったからといって消えるわけではなく、むしろAIの普及によってより差し迫ったものになる
- 次世代の計算アーキテクチャ——GoogleのTPUやNVIDIAのTensor Coresのような専用設計はすでにあるが、現在のLLM推論のボトルネックはなおメモリ帯域と遅延にある
- コンパイラとプログラミング言語設計——AIが大量のコードを生成しても、その正しさ、安全性、性能を最終的に決めるのは、やはり土台となる言語とコンパイラだ
AIはアプリケーション層のハードルを下げたが、同時に下層の課題をより高く、より重要なものに押し上げた。資工系の価値は、そもそもコードの書き方を教えることではなく、こうした難題を解く力を鍛えることにある。
新封建時代
独占と封建の違いは何か。独占は価格を支配し、封建は能力を支配する。独占は物を高く買わせるが、封建はそこから離れられなくする。
AI時代の権力集中が、どちらに近いのかを僕はずっと考えている。
過去のテクノロジー独占は僕たちも経験してきた。MicrosoftがOSを独占していた時代、開発者は「仕方なく」Windowsを使った。Googleが検索を独占していた時代、広告主は「仕方なく」Google Adsを買った。だがこうした独占が影響するのは配分、つまり誰がどれだけ金を得るか、という問題だ。MicrosoftがOSを独占しても、あなたのスキル自体が価値を失うわけではない。別のプラットフォームに移っても、あなたは同じエンジニアのままだ。
AIは違う。モデルがあなたの労働を直接置き換えるなら、独占者が左右するのは価格だけではなく、あなたの労働に価値があるかどうかだ。
これはむしろ封建的な依存構造に近い。
伝統的な封建社会では、小作農は地主から離れられなかった。資本主義はこの依存を壊し、誰もが市場に参加し、資本を蓄積し、自分のスキルを持って資本市場で一席を得られるようにした。
今の状況は、逆戻りしつつある。AI開発を本気で活用するには、Claude CodeやCodexが必需品だ。これらのツールはAnthropic、Google、OpenAIに強く集中しており、技術的な参入障壁も資本的な参入障壁も高すぎて、ほとんど再現不可能だ。もしあなたが使わず、同僚たちがAI開発を使っているなら、あなたは競争上不利になる。この圧力は今後さらに強まるだろう。
これはただの資本独占で、目新しくないと言う人もいる。
僕は、決定的な違いは交渉材料にあると思う。歴史上、労働条件の改善――労働時間の短縮、賃金の上昇――の多くは、構造が自発的に与えたものではなく、労働運動や政治的圧力によって交渉材料と引き換えに勝ち取ってきたものだ。
労働者の最大の交渉材料は、「僕たちがいないと困る」という点にある。僕がストライキをすれば、工場は止まる。だがモデルがストライキを代替できるなら、ストライキ自体がもはや武器ではない。
本当に不安なのは、知識労働者という集団が構造的な交渉力を失いつつあるのに、新しい交渉材料がまだ現れていないことだ。
Llama、Mistral、DeepSeekのようなオープンソースモデルは、確かに参入障壁を下げている。だが汎用能力では、御三家との差はまだ明らかだ。モデル訓練に必要なデータ規模、計算資源規模、そしてその背後にあるエンジニアリングの蓄積は、オープンソースコミュニティが短期間で追いつける量ではない。
オープンソースモデルの進化や個人向け計算資源の普及は、この時代の印刷術になるのかもしれない。だが印刷術が発明されてから、実際に権力構造を揺るがすまでには何百年もかかった。僕たちにそこまで時間があるのか、僕には分からない。
AI Slopについて
最近、多くの人がネット上のAIゴミコンテンツの増加を嘆いている。AIっぽい言い回しで書かれた粗製乱造の記事、いかにもAI生成だと分かる画像や動画。人々はこの現象をAI Slopと呼んでいる。
ある技術が工業化されるたび、市場には安くて粗雑な製品が大量にあふれる。ハンドドリップコーヒー好きの目線で見れば、インスタントコーヒーは十悪不赦のslopだ。（僕はハンドドリップもインスタントコーヒーも好きだ）
品質を求めない人は多い。あなたがAI Slopだと思うものは、彼らにとってはちょうどいい産物なのだ。ハンドドリップコーヒー好きから見れば、僕もきっと場末の田舎者に見えるのだろう。
Slopは、技術が本当に普及した後の必然的な産物だ。別の見方をすれば、ソフトウェア開発もまもなく工業化の段階に入るということでもある。
AIは、文法的には整っていて論理も通っているが、真の見解が何もない文章を簡単に生成できる。本当に意見があり、経験があり、人間味のあるコンテンツは、むしろもっと希少になり、もっと高価になる。
最終的には市場が自ら均衡点を見つけるはずだ。
スローダウンする
コンサートの意味は、スタジオ録音版を完璧に再現することではなく、即興やミス、観客とのやり取りから生まれる瞬間にある。
AIが書くコードは、僕が書くものより「正しい」かもしれない。だが、デバッグの過程で偶然見つけたedge caseや、痛い目を見たあとに身についた直感こそが、本当に価値のあるものだ。品味は、不完全な経験から育つ。
AIはアウトプットを極端に簡単にした。
ブログを書くこと、メモを取ること。こうした「遅い」作業の本質は、反省のプロセスにある。自分の考えを整理する行為そのものが、速度に流されることへの抵抗なのだ。
むしろ「時間の無駄」に見えることが重要になってきた。手書きでコードを書いて基礎原理を理解すること、仕事と関係ない本を3時間かけて読むこと、人と対面で話すこと、数十人しか読まないブログを運営すること。こうしたことの見返りは、予想もしない時点で突然やってくる。
僕は、あなたの不完全さをもっと見たいし、悩みを聞きたい。
経験の閾値
大谷翔平は最近、NHKのインタビューでこう語っていた。「過程の積み重ねは大事だが、技術的なコツを掴むのは一瞬」
過程の積み重ねは大事だが、技術的なコツを掴むのは一瞬
どんな技能も同じだ。閾値に達するまでの積み重ねはもちろん重要だが、本当に変化が起こる瞬間はたいてい一瞬だ。
その変化の瞬間が来るまで努力を続けられるかどうか、それが鍵になる。
AI時代の不安の多くは恐れから来ており、その恐れは未知から来ている。
多くのことは、自分で行動し、経験を積み重ねて初めて体感できる。AIはその閾値をあなたの代わりに越えることはできない。積み重ねを加速することはできるが、その「一瞬の気づき」は、自分の足でたどり着くしかない。
AIと踊る
AIをうまく使い、加速装置にする。反復作業はAIに任せ、その分の時間を、僕にしかできないことに使う。問題を定義し、方向を設計し、人とコミュニケーションを取り、成果に責任を持つことだ。
Slopはいずれ過ぎ去る。過渡期はもともとそういうものだ。インスタントコーヒーがスペシャルティコーヒーを消さなかったように、AI生成コンテンツも、見解のある創作を消すことはない。
スローダウンすることは、自ら追求する価値がある。低ROIに見える積み重ねは、いつか思いもよらない瞬間に回収され、他の人と違う自分を形作る。
AIがどんどん強くなる時代ほど、人と人とのつながりはむしろ重要になる。AIはコードを書き、データを整理し、レポートを生成できるが、信頼を築き、経験を共有し、迷っているときに本当の言葉をくれることはできない。
もしこの記事が気に入ったら、ぜひ手紙を書いて僕に感想を聞かせてほしい。