検証のスピードは、もう課題じゃなくなった
私は現在、検証色の強いプロジェクトで、AIエージェントを活用したサービス開発に取り組んでいます。開発スタイルはいわゆる「エージェント駆動開発」。設計と判断は人間が行い、実装はAIエージェントに委ねる形です。私自身、もうほとんど手でコードを書いていません。
これは劇的な変化でした。「作ってみないと分からない」を確かめるコストが下がり、プロトタイピングの速度はもはやボトルネックではありません。
……と、ここまでは良かったのです。
速くなったのに、チームは遅くなっていた
ところが、チーム全体を見渡すと、妙なことが起きていました。
プロトタイプや機能はどんどん生まれるし、テストも通ってちゃんと動く。それなのに、作った本人以外、誰も中身を分かっていないのです。
実害も出はじめていました。いつの間にか仕様が変わっていて、次の設計のときに初めて「これ、どうなってるんだっけ？」が発覚する。考慮が漏れていてデグレが起きる。個人の検証速度は上がったのに、チームとしての理解はむしろ遅れていく。そんな逆転現象です。
この状態には名前があります。認知的負債。Margaret-Anne Storeyらは、ソフトウェア開発における「負債」を3つに整理しています（From Technical Debt to Cognitive and Intent Debt）。
- 技術的負債：コードや設計の妥協が、後のコストになる（コードにたまる負債）
- 認知的負債：システムについての共有された理解が失われていく（人の頭の中にたまる負債）
- 意図負債：なぜそう作ったかが、どこにも残されていない（記録の欠落としてたまる負債）
うちのチームで起きていたのは、この認知的負債の蓄積でした。
従来、認知的負債は「属人化」の文脈で語られてきました。特定の人しか分からないコードがある、という話です。しかし、AIに書かせる開発では事情が違います。属人化なら「あの人に聞けば分かる」が成立しますが、AIが書いたコードは、書いた本人ですら細部を把握していないことがある。聞く相手はいるのに、聞いても答えられないことがあるのです。
負債が生まれる場所、たまる場所
うちのチームで負債がたまっていく流れを観察すると、こうなっていました。
- 各メンバーが、AIエージェントを使って個別にプロトタイプを作る
- 設計の判断が、その人とエージェントの対話の中だけで完結する
- テストと動作確認で「動く」ことだけは担保され、先へ進む
- なぜそう作ったかが言葉にされないまま、理解のコストが積み上がる
ポイントは、これが2段構造になっていることです。
負債が生まれるのは、設計の時点（2）。設計の理解がその人とエージェントの対話に閉じた時点で、チームから見れば認知的負債が生まれています。そして、それがたまり続けるのは、なぜそう作ったかの記録が残らないから（4）。こちらは意図負債の問題です。意図さえ残っていれば後から追いかけて返せたはずの負債が、返す手がかりごと失われていく。
だったら、打ち手もこの2か所に当てればいい。そう考えて、チームで2つの取り組みを始めました。
打ち手1: 設計を「モブワーク」にする
1つ目は、認知的負債が生まれる場所への打ち手です。実装に入る前の設計フェーズを、メンバー全員のモブワークにしました。画面を共有しながら、構造や責務の分け方、どの方式を採用するかを、全員で話しながら決めていきます。
実装をエージェントに任せるスタイルでは、人間の仕事は「設計と判断」に集約されます。だったら、その一番大事なところに全員を投入しよう、という発想です。
効果は明確でした。意図がその場で言葉になり、その場で合意される。「なんでこの構造？」を後から聞き直すことが、ほとんどなくなりました。負債がたまってから返すのではなく、たまる前に潰す。
もちろん、全員の時間を使うのでコストはかかります。今のところ、アーキテクチャに関わる判断はモブ、細かい実装は個人、という線引きで運用しています。
打ち手2: 変更の「なぜ」をADRに残す
2つ目は、たまり続ける原因、つまり意図負債への打ち手です。アーキテクチャや機能に変更があったら、ADR（Architecture Decision Record）を残すことにしました。決めた内容だけでなく、検討したけどやめた案と、なぜその判断にしたのか（背景、制約、トレードオフ）を必ずセットで書きます。結論だけの記録は、半年後に読んでも何も分かりません。
ADRの生成自体はエージェントのルールに組み込み、変更前に必ず書かせるところまで自動化しています。
そして、運用して分かったのは、ADRの主な読み手がもはや人間ではない、ということです。正直に言えば、たまっていくADRを人が全部読み通すことは、すでにしていません。それでもADRが効いているのは、エージェントのコンテキストとして働くからです。ADRを読み込んだエージェントに「これ、どうなってるんだっけ？」と聞けば、決めた経緯や捨てた案ごと、答えが返ってくる。先ほど、AIが書いたコードは聞いても本人が答えられないことがある、と書きました。意図を残す仕組みを入れたことで、その「聞けば分かる」が、人ではなくエージェント相手に成立するようになったのです。これが想像以上に大きかった。
モブに参加できなかったメンバーや、後から入るメンバーへのフォローとしても、この「聞けば分かる」は機能しています。
一方で、自動化の結果「増えすぎて重要な判断が埋もれる」という新しい課題も出てきました。人が全部読むわけではないとはいえ、細かすぎるADRはエージェントのコンテキストにとってもノイズになります。どの粒度の変更までADRにするか、線引きは現在も調整中です。
ボトルネックはどこへ移ったか
この2つの取り組みは、きれいに役割が分かれています。モブ設計は意図を「作る」仕組みで、認知的負債がたまる前に共有理解を作る。ADRは意図を「残す」仕組みで、意図負債を塞ぐ。モブで生まれた意図をそのままADRに書き下ろせば、2つはつながります。実感として、設計の場で過去の作りを掘り起こす「これどうなってんの？」というやり取りは、目に見えて減りました。
AIに実装を任せる時代、ボトルネックは「コードを書く速さ」ではなく、「なぜそう作ったかを共有する仕組み」に移っている。これが、この経験から得た一番の学びです。
実装が速くなるほど、言葉にされないままの「判断の理由」は増えていきます。コードは資産になっても、そこに至った思考が残らなければ、チームは同じ議論を繰り返すことになる。
モブ設計とADRは、この「共有する仕組み」の、うちのチームなりの最初の一手です。同じようにエージェント駆動の開発に取り組むチームの、何かの参考になれば幸いです。