AIブラックボックス化した事業を買うリスク
「バグが出ました。どこを直せばいいか分かりません。売り手さんに聞いたんですが、彼も分からないと言っていて……」
これは架空の話ではありません。AIエージェントを活用した個人開発サービスのM&Aが増えた2024年以降、買い手からこの種の相談が増えています。買収した翌月に予期せぬエラーが出て、売り手に連絡したら「Cursorに任せて作ったので、正直細かいロジックは把握していないんです」と返ってきた、というケースです。
かつてのM&Aにおける技術的なリスクといえば、「スパゲティコード」でした。長年ツギハギで運用されてきた汚いコード、属人的な命名規則、コメントすら書かれていない関数の山。確かに引き継ぎは大変でしたが、それでも「人間が書いたコード」である以上、読み解けないということはほぼありませんでした。しかし今、M&A市場に出回り始めているAIエージェント産のプロダクト群は、従来のスパゲティコードとは全く異なる種類の、そしてある意味でより深刻なリスクを内包しています。
本記事では、AIが書いた「完璧に見えるコード」を買収することのリスクと、それを事前に見抜くための技術的DDの具体的な視点を解説します。
1. スパゲティコードより怖い「完璧すぎるコード」の正体
1-1. 昔のスパゲティコードが「まだマシ」だった理由
スパゲティコードというのは、プログラムの処理が麺のように絡み合い、どこで何をしているか追いづらくなった状態を指します。保守性の観点では最悪の状態ですが、M&Aにおける引き継ぎという文脈では、実は「まだ読み解ける余地がある」という側面がありました。
人間が書いたコードには、どれだけ汚くても「書いた人の思考の痕跡」が残ります。変数名の付け方の癖、処理を分割した（あるいはしなかった）判断の跡、コメントが書かれている箇所と書かれていない箇所のパターン。これらは言うなれば「設計者の脳の化石」であり、引き継ぐ側のエンジニアはこの化石を手がかりに「なぜこういう構造になったのか」を推測しながら、理解を積み上げることができました。実際、古い企業システムの保守を担当するエンジニアたちはこうした「コード考古学」に日々取り組んでおり、それ自体が一つのスキルセットとして確立されています。
つまりスパゲティコードが厄介なのは事実ですが、「人間が書いた」という一点において、解読の手がかりが存在していたのです。
1-2. AIが生成したコードが「完璧」ゆえに危険な理由
では、AIエージェントが生成したコードはどうでしょうか。CursorやGitHub Copilotが吐き出すコードは、構文上の誤りがなく、命名規則も統一されており、場合によっては自動でコメントまで付けられています。一見するとシニアエンジニアが書いたような、整然とした美しいコードです。
しかしこの「美しさ」には、決定的に欠けているものがあります。それは「なぜそうしたのか」という設計意図です。
AIは与えられた要件に対して統計的に「もっともらしいコード」を生成します。その選択の背景に、「この処理が将来的にこういう拡張をされる可能性があるから」「このインフラ構成では○○の制約があるから」といった文脈的な判断は存在しません。プロンプトに書かれていない考慮事項は、原則として無視されます。コードが動いているのは「たまたまその要件ではバグが出なかった」からであって、「すべてのケースを考慮した上で設計されている」からではないのです。
これが何を意味するか。本番環境で想定外のエラーが発生したとき、「なぜこの処理がこうなっているのか」を遡る手がかりが、コードの中に存在しないのです。スパゲティコードは汚くても読み解けましたが、AIが生成した「完璧なコード」は、エラーの原因を追うための「設計の文脈」が根本的に欠落しているため、ある意味で解読不能になりえます。
2. 「引き継ぎ（PMI）」の現場で実際に何が起きるか
2-1. 売り手に聞いても「AIに聞いてください」しか返ってこない
AIエージェントを活用した開発の特徴の一つは、売り手本人がコードの全容を把握していないケースが珍しくないという点です。これは批判ではなく、AIエージェントを使った開発の自然な帰結です。「こういう機能を作ってほしい」とプロンプトを投げ、動いたコードをそのまま本番に反映させていく開発スタイルでは、開発者は「何を作るか」の意思決定をしていますが、「どのように作るか」の実装判断はAIに委ねています。
平時はこれで問題ありません。しかしM&Aで第三者に引き渡す場面になると、この構造が一気に問題化します。買い手がバグの対応を求めて売り手に連絡しても、売り手が答えられるのは「当時こういうプロンプトで作った」という事実だけで、「このエラーがなぜ起きているのか」という技術的な根拠を説明できない。当時使ったAIのセッションログはすでに消えており、再現する手段もない。こういうケースが現実に発生しています。
2-2. 「属人化」の形が根本的に変わった
従来のM&Aにおける「属人化リスク」とは、特定の人物しか知らない業務知識や設定情報が文書化されておらず、その人が抜けたあとに組織が機能不全に陥るリスクでした。対策は明快で、引き継ぎ期間を設けてドキュメントを整備し、知識を形式知化すればよかった。
ところがAIエージェント時代の属人化は、この構図を根本から変えています。問題は「知識がその人の頭の中にある」ことではなく、「知識がAIとの対話セッションの中にしか存在しなかった」ことです。売り手の頭を引き継ぐことはできませんでしたが、少なくとも売り手に聞けば答えが得られました。しかしAIとの対話ログは残らず、そのセッションの文脈は再現不能です。「その人しか知らない知識」が「どこにも残っていない知識」に変質してしまったのです。
さらに深刻なのは、「自分では実装できないのに、AIを使えば高度なシステムを作れてしまう」という現代特有の状況です。個人開発者がAIエージェントを駆使して、本来であれば数人のエンジニアチームでなければ構築できなかったようなシステムを短期間で作り上げ、それをM&Aで売却するケースが増えています。買い手にとっては「このシステムを作れる人物が付いてくる」という前提で買収したのに、実際には「このシステムをAIに作らせた人物が付いてくる」だけだった、という事態が発生するのです。
3. ブラックボックスを見抜く技術的DDの具体的な視点
3-1. コードの美しさではなく「変更容易性」を見よ
技術的DDにおいて、AIが生成したコードかどうかを見極めようとすることはあまり意味がありません。重要なのは「このシステムが引き継いだ後に、どのくらいの工数で変更・修正・拡張できるか」という変更容易性（保守性）です。
具体的に確認すべき項目を挙げます。
まずテストコードのカバレッジと質。テストコードが存在するかどうかだけでなく、どのようなケースをカバーしているかを確認します。AIが自動生成したテストコードは、正常系（ハッピーパス）しかカバーしていないことが多く、異常系・エッジケースへの対応が薄い傾向があります。テストの内容を読めば、そのシステムを「どこまで考えて作ったか」が透けて見えます。
次に設計ドキュメントの有無。なぜこのアーキテクチャを選んだのか、DBの設計意図はどこにあるのか、外部APIへの依存はどのような理由で選定されたのか。これらを説明できるドキュメント（ADR：アーキテクチャ決定記録）が存在するかどうかは、そのシステムに「人間の設計意図があるかどうか」のバロメーターになります。
そして依存ライブラリのバージョン管理状況。使用しているライブラリが適切にバージョン固定されているか、セキュリティアップデートへの追従が行われているかを確認します。AIが生成したコードは、その時点で「もっともらしい」ライブラリを採用しますが、長期的なメンテナンス性まで考慮しないことがあります。
3-2. Gitの履歴とIssueログが語る「本当の開発体制」
Gitのコミット履歴は、そのシステムがどのように作られてきたかを正直に映し出します。人間が試行錯誤しながら積み上げてきたコードと、AIに一括生成させたコードでは、コミット履歴のパターンに歴然とした差が現れます。
AIエージェントを多用した開発の典型的なパターンは次のようなものです。「数日間のうちに大量のファイルが一括でコミットされる」「コミットメッセージが機械的に均質すぎる」「PRレビューのコメントがほぼ存在しない」。これは開発プロセスの中に「他者の目線によるレビュー」がなかったことを示しており、想定外の動作を引き起こすコードが素通りしていた可能性を示唆します。
また、GitHubのIssueログやプロジェクト管理ツールの記録も重要な判断材料です。機能追加や不具合修正の経緯が丁寧に記録されているシステムは、それだけ「運用の文脈」が蓄積されています。逆にIssueが皆無であれば、問題が発生したときどう対処してきたかの履歴がなく、買い手は一からシステムを理解し直す必要があります。
3-3. 「このバグを直してください」と実際に依頼してみる
DDの終盤で実施すると効果的なのが、売り手に対して意図的に小さな修正依頼を投げることです。実際には存在しないダミーの不具合でも、「○○の画面でこういう動作になっているのですが、意図した動作ですか」という確認ベースの問い合わせでも構いません。
ここで見たいのは、売り手がどのくらいの速度で、どのような精度で回答できるかです。自分のコードを本当に理解している売り手であれば、「あそこの処理はこういう意図で実装しているので、おそらく○○が原因です」という回答がすぐに返ってきます。一方、AIに任せていた部分の話になった途端に回答が遅くなったり、「確認します」と言ったきり音信不通になったりする場合、引き継ぎ後のサポートは期待できないと判断すべきです。
この確認を契約前に実施することで、「引き継いでから気づいた」という最悪のシナリオを未然に防ぐことができます。
4. 引き継ぎリスクを契約で潰すための3つの論点
4-1. 「引き継ぎ期間と売り手の稼働義務」を契約書に明記する
技術的DDで一定のリスクを把握したうえで買収を進める場合、そのリスクを契約条件に反映させることが重要です。具体的には、売り手の引き継ぎサポート期間・対応範囲・稼働時間・報酬体系を契約書に明示的に記載することです。
よくある落とし穴は「引き継ぎは誠実に対応します」という抽象的な合意だけで終わるケースです。「誠実」の定義は人によって異なるため、いざとなると「メールに返信しているので対応している」と主張される可能性があります。「引き継ぎ期間は3ヶ月、週○時間の稼働を保証し、緊急の障害発生時は24時間以内に初期対応する」といった具体的な条件設定が、後々のトラブルを防ぎます。
4-2. 「再現性の確認」をDD項目に必ず入れる
システムの引き継ぎにおいて最初につまずくのが「ローカルで動かせない」という問題です。売り手の環境では動いていたシステムが、買い手の環境では動かない。原因を探ろうにも、環境構築の手順が文書化されていない。こうした初歩的な詰まりがPMIの最初の数週間を潰すことは珍しくありません。
DDの段階で確認すべき再現性のチェック項目として、以下を押さえておきましょう。ローカル開発環境の構築手順が文書化されているか。DockerやVagrantなど、環境を再現するための仕組みが整備されているか。本番環境のインフラ設定がIaC（Terraform・Ansibleなど）として管理されているか、あるいはサーバー内に「手作業の設定」が残っていないか。最後の「サーバーの秘伝のタレ」問題は、特にVPSや専用サーバーで長年運用されてきたシステムに頻出します。本番環境にしかない謎の設定ファイルや、売り手だけが知っているSSHの鍵管理、cronジョブの存在。これらは引き継ぎ後に初めて発覚することが多く、発覚したタイミングで売り手とのサポート期間が終わっていれば完全な詰みです。
4-3. 「ブラックボックス度スコア」という考え方
上記の確認項目を整理する上で有用なのが、システムのブラックボックス度を定量的に把握するフレームワークです。感覚的な「なんとなく怪しい」「なんとなく大丈夫そう」という判断ではなく、チェック項目をスコアリングすることで、複数の買収候補を客観的に比較できるようになります。
簡易的なスコアリング例として、以下の項目を各5点満点で評価する方法があります。①テストコードのカバレッジと質、②設計ドキュメント（ADR）の充実度、③Gitコミット履歴の健全性、④ローカル環境の再現容易性、⑤売り手の技術的な質問への回答精度。25点満点で20点以上であれば引き継ぎリスクは低め、15点以下であれば契約条件に保護条項を盛り込む必要があると判断する、といった基準です。
もちろんこのスコアはあくまで補助的なツールであり、システムの種類や規模によって重み付けは変わります。ただし「何を、どのように確認したか」という記録を残すこと自体が、後のトラブル時に自分を守る証拠にもなります。買収後に想定外の問題が発覚したとき、「DDでここまで確認した」という記録があることで、「確認しなかった側の責任」という不当な主張を退けることができます。
AIエージェント全盛期のM&Aにおいて、「コードが綺麗かどうか」はもはや安心の根拠にはなりません。むしろ綺麗すぎるコードこそが、最も深いブラックボックスを隠している可能性があります。「このシステムを引き継いだあとに、自分たちは本当に運用できるか」。その問いに答えるために、技術的DDの視点を持つことが、AI時代の買い手にとって不可欠なスキルになりつつあります。
