今、僕たちがAIと掘っている穴

皆が忘れかけているので、ChatGPTが登場する直前のIT業界がどんなだったか、というのをちゃんと振り返っておきたい。

ChatGPTの登場は2022年11月だから、2022年10月のはてなブックマークを見ていると、ちょうどいい記事があった。

Readableなコード、マネジメント、TypeScriptとReact。この記事以外のものを付け加えると、まだ皆がRTXでpytorchを動かしていた頃のPythonとWeb3.0（ブロックチェーンとメタバース）ぐらいか。僕らが大好きだったエンジニア・ブログ・スフィアの最後の姿とは、こういうものだった。

このうち、Readableコードと、TypeScriptのアクロバチック型定義とReactの脳が裏返りそうなヘンテコアーキテクチャの話題はすっかり霧散してしまった。人間が書くプログラムにはいくらでも文句のつけようがあるが、AIの書くそれに文句を言っても始まらない、と皆が早々に諦めてしまったのが窺える。結局は莫大な無断引用データとH100がないと学習もままならないことがわかって、Pythonの記事も減った。（Web3.0については、AI関係なく黙っててもそのうち消えていたろうから言及しない）

そして、このブログが代表すべき業界の下世話な話題でいえば、「人手不足」が最大の話題だったように思うが、今や誰もその話をしていない。

これはもうはっきりとAIの影響だ。「人手不足」の話題というのは、端的に言えば「いかにしてエンジニアを採用し、教育し、定着させるか」という話だったわけだけど、この話が、「AIを使いこなし、10人分の成果を出すエンジニアになるにはどうすればいいか」みたいな話題にすり替わってしまった。

これ、考えればけっこう奇妙な話で、別にAIがいても人は人で採用すれば生産性は10倍が20倍、30倍になるんだからいいように思うんだけど、そうでなく、「人手がいらないとは言わないけど、とりあえず今ここにはいらない」みたいな話になっている。10倍になればそれで十分だし、AIで済むなら人間は僕の案件に入ってほしくない、みたいな意思すら感じる。というか実際、僕自身がそうなのだ。

ChatGPT直前まで僕がやっていたRailsなどのWebアプリケーションに「段階的に」Reactなどのモダンフロントエンドを導入する仕事を例にとってみよう。

この手のプロジェクトは、控えめに言っても「面倒」だった。バックエンド（Rails）とフロントエンド（React）の両方に精通したエンジニアは希少で、常に奪い合いだった。結果として、チームは多くの場合、Railsに詳しい人とReactに詳しい人の混成チームになる。

すると、何が起きるか。まず、膨大なコミュニケーションコストが発生する。APIの仕様をどうするか。データフォーマットはどうする。状態管理はどちらが持つべきか。毎日毎日、そのすり合わせに時間が溶けていく。それぞれの技術スタックに対する「常識」が違うから、しばしば不毛な対立も起きた（今までerbやrequirejsで動的に必要なjQueryのプラグインをincludeできたのに、どうして君たちのReactは全てをバンドルする必要があるのか？みたいなね）

さらに深刻なのは、個人の認知負荷だ。Railsエンジニアは慣れないReactのビルドプロセスやコンポーネントのライフサイクルを理解する必要に迫られ、ReactエンジニアはRailsの複雑なモデルや「暗黙の規約」の森で迷子になる（例えば定義をgrepできないマジックメソッドの存在）
新しいメンバーを一人追加するたびに、この「相互理解」のための教育コストがチーム全体にのしかかる。これが、ChatGPT以前の「人手不足」の現実だった。人を増やせば増やすほど、調整コストが指数関数的に増大していくような徒労感があった。

さて、今、同じ仕事を一人でやるとしたらどうなるか。

まず、APIの設計で迷えばAIに叩き台を作らせる。「RailsをAPIモードで動かして、こういう仕様のJSONを返すControllerのコードを書いて」と。React側では「このAPIを叩いて結果を表示するコンポーネントを、TypeScriptとTailwind CSSで作って」と指示すれば、数秒で骨格が出来上がる。Railsの知らない規約も、Reactのライブラリの使い方も、すべてAIが教えてくれる。

ここで重要なのは、AIは文句を言わないし、疲れないし、政治的な振る舞いもしない、完璧なペアプログラマーだということだ。僕一人の頭脳と、AIという無限の知識と実行力を持つアシスタント。この組み合わせの前では、かつてあれほど問題だった技術スタック間の断絶や、人間同士のコミュニケーションコストはほぼゼロになる。

こうなると、かつて切望した「もう一人の優秀なエンジニア」の存在は、むしろ邪魔ですら感じられるようになる。彼をチームに迎え入れるための面接、オンボーディング、日々のすり合わせ、コードレビューのやり取り…想像するだけでゾッとしてしまう。AIと一人で没頭している「ゾーン」とはかけ離れた世界だ。

生産性が10倍になった状態で、なぜ人を増やして20倍、30倍を目指さないのか。
答えは単純で、人を増やすことで生じる「摩擦」が、生産性の向上分を上回ると、肌感覚でわかっているからだ。一人とAIで完結できる仕事に、「もう一人分の人間（あるいは人間＋AI）の複雑さ」を混ぜ込みたくない、というのが多くのAI協業プログラマの本音ではないだろうか。

だが、ここで立ち止まってよく考えてみたい。「人手不足」とは本当にそういう話だっただろうか？という点だ。上司に対する言い訳の一つだったとしても、僕たちは違う主張をしていたように記憶している。それは「プロジェクトの属人性」だ。

「あの人がいないと、もう誰もこの仕様を説明できない」
「このコードは、Aさんが書いた秘伝のタレだから誰も触れない」

僕たちは、特定の個人に知識や権限が集中することのリスクを、声高に叫んでいなかっただろうか。トラックナンバー（そのプロジェクトの主要メンバーが何人トラックに轢かれたらデッドロックするか、という指標）を憂い、ペアプログラミングやモブプログラミングを推奨し、ドキュメントの重要性を説き、知識のサイロ化を批判していたはずだ。人を増やして知識を分散させることこそが、プロジェクトを健全に、そして持続可能にする唯一の道だと信じていた。

さて、翻って現在の「AI協業プログラマ」である僕たちの姿を見てみよう。

AIという完璧なアシスタントと対話しながら、一人で設計し、一人でコードを書き、一人でテストを回す。思考のプロセスは、僕の頭の中と、AIとの対話ログの中にしかない。なぜそのアーキテクチャを選んだのか、どんな代替案を検討して捨てたのか、どのビジネス要件がこの複雑なロジックを生んだのか。その決定に至るまでの文脈や機微は、他の誰にも共有されないまま、コードという成果物だけが積み上がっていく。

これは、かつて僕たちが最も忌み嫌っていたはずの「究極の属人性」の姿そのものではないだろうか。（あなたが自分が全くそうでないにも関わらず、AIと人間の対話ログ、あるいはAIが書き殴ったマークダウンテキストを丹念に読んでくれる他者を仮定できるなら話は別だが）

AIは僕の生産性を10倍にしてくれた。しかし、それは同時に、僕という個人への依存度を10倍にしただけなのかもしれない。僕がこのプロジェクトを去れば、後任のエンジニアは、文脈が抜け落ちたAIとの対話ログと、AIが生成した膨大なコードの海を前に立ち尽くすことになる。それは、僕たちがかつて批判した「秘伝のタレ」のコードを解読する作業と、何が違うというのだろうか。

バイブコーディングは快適だ。誰にも邪魔されず、自分のペースで、圧倒的な成果を出せるのだから。だが、その快適さの裏側で、僕たちは自分たちが乗りこなすプロジェクトのトラックナンバーを、自らの手で「1 or AI」にしている。

僕たちは今まさにAIと墓穴を掘っているのかもしれない。