AIエージェントが書いたコードは引き継げるか
買い手のリードエンジニアがgit logを開くと、コミットの大半が短期間に集中していた。コミットメッセージは整っているが、機能追加の粒度が不自然に大きく、一つのコミットで数千行が一度に追加されている。git blameを辿ると、コードの作者は数名の人間名義だが、変更のパターンは明らかに人間の手によるものとは異なる。これは、DevinやCursorのエージェント機能が大半を書いた事業だった。問題は、その事実が開示資料のどこにも書かれていなかったことだ。
本連載では、AIが書いたコードの資産価値を「資産価値ゼロ」の観点（#37）で扱った。本稿はそれと地続きだが、焦点を変える。コードという「成果物」の静的な品質ではなく、AIエージェントが介在した「開発履歴」そのもの ── どのように作られ、誰が意思決定し、なぜその設計になったのかという記録 ── を資産としてどう評価するかを扱う。開発履歴は、買収後にその事業を維持・拡張できるかを左右する、もう一つの見えない資産だ。
本稿では、開発履歴がなぜ資産なのか、AIエージェント介在が履歴に与える影響、開発履歴の質を評価するDDの観点、そして売り手・買い手それぞれの実務を整理する。AIエージェントの利用は否定すべきものではない。問われるのは、その介在が「引き継げる開発履歴」を残しているかどうかだ。
1. 開発履歴はなぜ資産なのか
1-1. コードは「現在」、履歴は「なぜ」を記録する
ソースコードは、システムの「現在の状態」を表す。しかし、なぜそのコードがその形になったのか ── どんな選択肢があり、何を選び、何を捨てたのか ── は、コードそのものには書かれていない。これを記録するのが開発履歴だ。コミット履歴、プルリクエストの議論、Issue、設計ドキュメント、レビューのやり取り。これらは「なぜ」の記録であり、将来の保守者が意思決定を辿るための地図になる。
買収後にシステムを維持・拡張するチームにとって、この「なぜ」の記録は決定的に重要だ。なぜこの実装を選んだのか分からなければ、変更が安全かどうか判断できない。開発履歴は、コードを「読めるが理解できない」状態から「理解して改変できる」状態に引き上げる、引き継ぎ可能性の中核資産だ。
1-2. 履歴が薄い事業は「凍結された資産」になる
開発履歴が薄い、あるいは意思決定の記録が残っていない事業は、コードが動いていても「凍結された資産」になりやすい。誰も変更の影響を予測できないため、触るのが怖くなり、機能追加もバグ修正も停滞する。新しいチームは、既存コードの意図を推測しながら手探りで進むしかなく、保守の生産性が著しく落ちる。
これは事業の成長性に直結する。買収後に機能を追加し、市場の変化に対応していくには、コードを安全に変更できる必要がある。履歴の薄さは、買収後の事業の「動かしやすさ」を奪い、成長シナリオの実現可能性を下げる。財務指標には現れないが、将来のキャッシュフローを左右する要素だ。
2. AIエージェント介在が開発履歴に与える影響
2-1. 高速な生成が意思決定の記録を飛ばす
DevinやCursorのようなAIエージェントは、人間が数日かける実装を数時間で生成する。この速度自体は強力だが、副作用として「意思決定の記録」が飛ばされやすい。人間の開発であれば、設計を議論し、レビューでやり取りし、選択の理由がIssueやPRに残る。エージェントが一気に生成すると、その過程が圧縮され、「なぜこうしたか」が記録されないまま成果物だけが残る。
結果として、コミット履歴は存在しても、それは「何が追加されたか」の記録であって「なぜそうしたか」の記録ではなくなる。AIエージェントの速度は、成果物の生成を加速する一方で、開発履歴という資産の蓄積を希薄化させ得る。これは速度と引き継ぎ可能性のトレードオフだ。
2-2. 介在の事実が開示されないという問題
より根深いのは、AIエージェントの介在が開示されないことがある点だ。コミットは人間名義で記録され、外形上は通常の開発に見える。しかし実態として、設計の大半をエージェントが担い、人間はプロンプトを与えてレビューも限定的だった場合、その事業の「開発能力」は、人間チームではなくエージェントとプロンプトに宿っている。
買い手がこれを知らずに「優秀な開発チームがいる事業」として評価すると、買収後に実態とのギャップに直面する。AIエージェント介在の有無と程度は、事業の開発能力がどこに存在するかを左右する重要事実であり、DDで明らかにすべき開示事項だ。隠す必要のあるものではなく、正しく評価されるべき事実だ。
3. 開発履歴の質を評価するDDの観点
3-1. コミット粒度と意思決定の追跡可能性
DDでは、git logとPR履歴を実際に精査する。コミットの粒度が適切か（巨大な一括コミットが多くないか）、コミットメッセージが「なぜ」を含むか、PRにレビューと議論の記録があるか、設計上の判断がIssueやドキュメントに残っているか。これらは、開発履歴が「なぜ」を記録しているかの指標になる。
意思決定が追跡可能であれば、新しいチームはコードの意図を理解して変更できる。追跡不能なら、コードは読めても改変は危険を伴う。履歴の追跡可能性は、買収後の保守生産性を予測する代理指標だ。
3-2. テスト・レビューゲートの実在性
AIエージェントが書いたコードであっても、人間のレビューと自動テストのゲートを通っていれば、品質と理解の両方が担保される。DDでは、コードがレビューを経ているか（PRに実質的なレビューコメントがあるか）、テストが存在し意味のあるカバレッジを持つか、CIで品質が検証されているかを確認する。
これは本連載のVibe Coding回（#37）で挙げた「例外的に価値が残る条件」と一致する。AIエージェントの生成物に、人間のレビューと自動テストという二つのゲートが効いていれば、開発履歴は引き継ぎ可能な資産として成立する。逆に、ノーレビュー・ノーテストで生成物が直接本番に入っている事業は、履歴が品質を保証していない。
3-3. 「人間が説明できるか」テスト
最も実践的なDDは、対象企業のエンジニア（または創業者）に、システムの主要な設計判断について「なぜそうしたのか」を質問することだ。明確に答えられれば、たとえAIエージェントが書いたコードでも、人間が理解し統制している証拠になる。答えられず「AIがそう書いたので」としか言えなければ、その事業の開発能力は人間側に存在しない。
このテストは、コードの作者がAIか人間かではなく、「現在その事業を統制している人間が、システムを理解しているか」を直接確かめる。理解している事業は引き継げる。理解していない事業は、AIエージェントなしには一行も安全に変更できない。
4. AIエージェント介在事業の価値評価
4-1. 「再現可能な開発プロセス」としての価値
AIエージェントを使った開発が、再現可能なプロセスとして確立されていれば、それ自体が価値になり得る。プロンプトやワークフローが文書化され、エージェントへの指示の出し方がチームの知見として蓄積され、生成物のレビュー基準が定まっている事業は、買収後も同じ速度で開発を続けられる。これは「速く作れる能力」という資産だ。
逆に、特定個人だけがエージェントを使いこなし、その属人的なスキルに開発が依存している場合、その個人が抜ければ開発速度が崩壊する。AIエージェント活用が、属人的な技から再現可能なプロセスへと昇華されているかが、その能力を資産として評価できるかの分かれ目だ。
4-2. 履歴の質をバリュエーションに反映する
開発履歴の質は、買収後の保守・拡張の生産性を通じて、将来キャッシュフローに影響する。履歴が「なぜ」を記録し、レビューとテストのゲートが効き、人間が設計を理解している事業は、成長シナリオの実現可能性が高く、減点幅が小さい。履歴が成果物の羅列に過ぎず、誰も意図を説明できない事業は、保守停滞リスクを織り込んだ評価が必要だ。
これは「AIが書いたから減点」という単純な話ではない。問われるのは、AIエージェントの介在が、引き継げる開発履歴と再現可能なプロセスを残しているか、それとも理解不能な成果物だけを残したかだ。同じAI活用でも、この差が事業価値を大きく分ける。
5. 買い手・売り手の実務
5-1. 買い手のチェックリスト
買い手は、①AIエージェント介在の有無と程度の開示確認、②コミット粒度と意思決定の追跡可能性、③PRレビューの実在性、④テストカバレッジとCIの実効性、⑤「人間が設計を説明できるか」テスト、⑥AIエージェント活用が再現可能なプロセスか属人的か、を確認する。これらを通じて、開発履歴が引き継ぎ可能な資産かを評価する。
重要なのは、コードの静的レビューだけでなく、履歴とプロセスと人間の理解を見ることだ。「動くコードがある」ではなく「変更し続けられる開発体制がある」かを評価することが、AIエージェント時代のコードDDの要諦になる。
5-2. 売り手のスタンス
売り手は、AIエージェントの活用を隠すのではなく、正しく開示し、その上で「引き継げる開発体制」を実証する。意思決定の記録を残し、レビューとテストのゲートを設け、エージェント活用のワークフローを文書化し、人間が設計を説明できる状態を保つ。これらは、AI活用事業の価値を守る投資だ。
AIエージェントで速く作れることは強みだが、それが引き継げる形で蓄積されていなければ、買い手にとっては不安要素にしかならない。「AIで速く作り、かつ人間が理解し統制している」事業を実証できる売り手は、AI活用を減点ではなく加点に転じさせられる。
結論：問われるのは作者ではなく、「理解と統制が引き継げるか」
AIエージェントが開発に介在する時代において、コードの作者が人間かAIかという問いは、もはや本質ではない。本質は、その開発が「なぜそうしたか」の記録を残し、人間が設計を理解し、再現可能なプロセスとして確立されているか ── つまり、買収後のチームが理解と統制を引き継げるかどうかだ。開発履歴は、その引き継ぎ可能性を映す、財務諸表に載らない資産だ。
買い手にとっては、履歴とプロセスと人間の理解を評価することが、保守停滞リスクを見極める手段になる。売り手にとっては、AI活用を開示した上で引き継げる開発体制を実証することが、その能力を資産として評価させる道になる。技術的DDの本質は、「速く作れた」という結果ではなく、「作り続けられる」という持続的な能力を見極めることにある。AIエージェント介在事業の評価は、その視点が最も鋭く問われる最前線だ。
