本記事は AI エージェント時代の開発における「思想レベル」の整理を試みたものです。
まだ発展途上の考え方であり、ツッコミ・議論・異なる視点からのフィードバックを歓迎します。
はじめに：AI エージェント時代のコンテキスト汚染と「ゆらぎ」をどう制御するか
こんにちは、データ･AI ソリューション本部 データインフラ統括部のイマムラです。
普段は、社内の新規事業プロジェクトを中心に Web アプリケーション開発のフロントエンド業務を担当しています。
最近は、Cursor などの AI エージェントに コード生成・修正・テスト実行・ファイル編集 まで任せる場面が増え、これが半ば"標準的な開発の流れ"になりつつあります。
うまくハマれば驚くほど速い一方で、同じように指示しているはずなのに出力がブレてきたり、いつの間にか古い仕様に基づいたコードが再生成されてしまったりする違和感も増えてきました。
ここでは、そうした AI エージェントを使った開発を実務で試し続ける中で見えてきた
「どこで破綻しやすくなるのか」「どう扱えば安定するのか」 といったポイントを中心にまとめています。
より踏み込んだ内容は、以下の記事 *1 に書いているため、今回は特に重要な部分だけを取り上げます。
本記事では次の 4 つに焦点を当てて整理します：
- コンテキスト汚染をどう防ぐか（SSoT / Mini-PoC / DR）
- AI の出力の「ゆらぎ」をどう扱うか（誤り訂正の考え方）
- Vibe Coding などで作った PoC コードを“流用しないべき理由”
- それらをまとめた考え方としての Guarantee-Driven Development（GDD）
※本記事でいう 「AI エージェントを使った開発」 とは、Cursor などのツールにタスクを与え、コード生成・修正・ファイル編集・テスト実行を広く任せる開発スタイル を指します。
- はじめに：AI エージェント時代のコンテキスト汚染と「ゆらぎ」をどう制御するか
- 1. なぜ AI エージェントを使った開発のアウトプットは「変にブレる」のか
- 2. コンテキスト汚染とは何か
- 3. コンテキスト汚染の解決方法：SSoT / Decision Record / Mini-PoC
- 4. 出力の「ゆらぎ」をどう扱うか：誤り訂正からの発想
- 5. Vibe Coding / 高速 PoC で作ったコードを「流用しない」理由
- 6. Guarantee-Driven Development（GDD）とは何か
- 7. まとめ：AI 時代の開発とは「正しさを設計し続ける営み」
1. なぜ AI エージェントを使った開発のアウトプットは「変にブレる」のか
AI エージェントを使った開発をしていると、こんな違和感に悩まされます。
- 同じようにプロンプトを投げているはずなのに、アウトプットが毎回微妙に違う
- 昨日まで正しかったはずのコード出力が、いつの間にか古い仕様に基づいたものになっている
モデルの性能だけの問題に見えますが、実際には、仕様が時間とともに濁っていき、コンテキストが汚染されるという構造的な原因があります。
AI は「どの情報が今も有効で、どれが過去の試行錯誤なのか」を、自動では判断できません。
その結果、
- 古い仕様や PoC のノイズ
- 不完全な設計メモ
- 変更途中の議論ログやコメントやメモ
といったものが、正式な仕様と同じ重みで参照されてしまう。
これが本記事で言う 「コンテキスト汚染」 です。
同時に、AI の出力は本質的に 確率的（stochastic） です。
同じ仕様・同じプロンプトでも、温度や前後文脈によって表現がわずかに変わります。
この「ゆらぎ」もまた、放置するとプロジェクト全体の整合性をじわじわ崩していきます。
この 2 つ――
- コンテキスト汚染（仕様の濁り）
- 出力のゆらぎ（確率的なばらつき）
にどう構造的に対処するかが、AI エージェントを使った開発の核心です。
2. コンテキスト汚染とは何か
まずは「コンテキスト汚染」を、もう少しはっきりと言葉にします。
コンテキスト汚染とは：
不要な情報・古い文脈・発散ノイズが、正式な仕様や判断基準に混入し、AI の出力を不安定にさせる現象。
実務レベルでは、次のような形で現れます。
- 半年前の PoC の仕様が、まだ現役の仕様として参照されてしまう
- 一度却下した設計案が、AI の提案として何度も復活する
- 「とりあえず書いたメモ」が、正式仕様と同じ扱いで読まれる
- 変更理由がどこにあるか分からず、「なぜこうなっているのか」が誰も説明できない
人間は文脈から「これはもう古い情報だな」と判断できますが、
AI にとってはすべてが等しく「テキスト」です。
だからこそ、情報の構造と寿命を設計しない限り、コンテキスト汚染は必ず起こります。
この問題に対する、私なりの解法が SSoT / Decision Record / Mini-PoC の三本柱です。
3. コンテキスト汚染の解決方法：SSoT / Decision Record / Mini-PoC
3-1. SSoT（正式仕様・Single Source of Truth）：AI が参照する「唯一の真実」
SSoT（正式仕様 / Single Source of Truth） は、
- 「今このプロジェクトで有効な仕様は何か」
- 「どこまでが不変で、どこからが変えてよいのか」
を定義する 唯一の事実源 です。
ポイントは、従来の「人間が読む仕様書」とは役割が違うことです。
- 対象読者の主役は AI
- 人間の読みやすさより、曖昧さのなさ・機械可読性を優先
- if / then, 真理表、正規表現、具体例、Contract Test などで徹底的に定義
人間は、その上で AI に「要約して見せて」と頼めばよい。
一次情報は SSoT に、読みやすいビューは AI に任せる、という分担です。
この SSoT をきちんと構造化し、寿命（いつまで有効か）を管理することが、
コンテキスト汚染を防ぐ最初の防衛線になります。
3-2. DR（判断記録・Decision Record）：意図と境界を保存し、AI の誤補完を防ぐ
もう一つの柱が DR（判断記録 / Decision Record） です。
DR は、単なる ADR（アーキテクチャ決定記録）の焼き直しではなく、
AI に誤補完させないための「意図と境界の保存装置」として位置づけています。
1 つの DR には、最低限つぎの 3 つを書きます。
- 前提条件：この判断が必要になった背景
- 採用した選択肢と、棄却した選択肢
- 廃棄条件：どんな変化が起きたら、この判断は無効になるか
そして、
- 「何が正しいか」は SSoT に書き
- 「なぜそうなのか」は DR に書く
という分業を徹底します。
これにより、
- AI は SSoT だけ見て、現在の原則に基づいてコードを生成できる
- 人間は DR を見て、判断の妥当性や前提条件の変化を検証できる
という構造になります。
3-3. Mini-PoC：PoC のノイズを仕様層に持ち込まないための隔離箱
AI 時代の PoC は、特に Vibe Coding のような高速プロトタイピングを前提にすると、
とんでもない速度で増殖します。
ここで一番危険なのは、
PoC の発散プロセスで生まれたコードやノイズを、そのまま本番仕様（SSoT）や実装に流用してしまうことです。
PoC には、次のようなノイズが大量に含まれています。
- 失敗した試行
- 一度採用しかけて却下した仮仕様
- 中間段階の設計
- 「一旦これで」の暫定実装
これらが正式な仕様層に混入すると、最悪のコンテキスト汚染が起こります。
そこで導入するのが Mini-PoC という考え方です。
- PoC / Vibe Coding で作るコードは、あらかじめ「破棄前提」の箱（Mini-PoC）に隔離する
- Mini-PoC には 明確な破棄条件（Destruction Condition） を書いておく
- 採用された内容だけを抽象化して SSoT と DR に還元し、コード自体は捨てる
PoC → 知見抽出 → 仕様（SSoT）・DR への還元 → 正式実装はゼロから再生成
という流れを徹底することで、
「PoC のノイズが本番に紛れ込む」ルートを構造的に断つことができます。
4. 出力の「ゆらぎ」をどう扱うか：誤り訂正からの発想
もう一つの問題は、そもそも AI の出力が 確率的に揺らぐことです。
- 同じ仕様でも、変数名・コメント・分岐の書き方が毎回少しずつ違う
- 「この 1 行だけ変えたい」という指示が、思わぬ範囲まで波及する
この性質は、量子力学における
「観測するまで状態が確定しない」という発想にどこか似ています。
テストという「観測」をしないかぎり、
AI が生成したコードは 「正しいかもしれない」状態にとどまります。
そして運用を続けるうちに、仕様変更や再生成によって、また不安定化していく。
ここで必要になるのが、いわば 誤り訂正コーディング的な発想です。
4-1. 三層構造としての「誤り訂正」
私はこれを、次の三層として整理しました。
Purity Layer（純度の層）
- SSoT を純度高く管理し、PoC ノイズを Mini-PoC に隔離する
- 入口でのコンテキスト汚染を防ぐ
Context Layer（文脈の層）
- DR に Intent / Boundary / 前提条件を記録し、
「なぜそうするのか」という文脈を AI から失わせない
- DR に Intent / Boundary / 前提条件を記録し、
Safety Layer（安全の層）
- Contract Test やモニタリングで、
「古い仕様への巻き戻り」や「意図しないスコープ拡大」を検出・補正する
- Contract Test やモニタリングで、
Safety Layer は、量子計算における誤り訂正のように、
「ゆらぎや巻き戻りを検出し、構造として補正する最後の防衛線」として機能します。
出力のゆらぎはゼロにはなりませんが、
この三層を通すことで 「許容できる範囲に閉じ込める」 ことができます。
5. Vibe Coding / 高速 PoC で作ったコードを「流用しない」理由
AI と対話しながら UI をサクサク作っていく Vibe Coding は、
PoC / MVP フェーズで非常に強力です。
しかし、そのまま本番に乗せようとすると、次のような問題が起きます。
- PoC 時点の曖昧な仕様が、本番コードのあちこちに埋め込まれる
- 試行錯誤の途中で入れた「一旦これで」が、そのままずっと残る
- チームが変わったときに、「どこまでが検証用で、どこからが正式仕様なのか」が誰も分からない
AI 時代の重要な前提は、
仕様さえ明確であれば、実装の再生成にかかるコストは従来よりも大幅に下がり、ほとんど無視できるレベルに近づいていくという点です。
だからこそ、
- PoC / Vibe Coding は 「仕様を決めるための実験」 に徹し、
- そこで得た知見は SSoT と DR に構造化して残し、
- コード自体は破棄し、正式版はゼロから再生成する
という方針が合理的になります。
PoC コードを「もったいない」と思って流用するほど、コンテキスト汚染と技術的負債は加速度的に増えていきます。
逆に言えば、再生成コストがほぼゼロになったからこそ取れる贅沢な戦略でもあります。
6. Guarantee-Driven Development（GDD）とは何か
ここまでの要素を束ねているのが、Guarantee-Driven Development（保証駆動開発 / GDD） です。
GDD を一言で表すと、
AI エージェントを使った開発が当たり前になった時代において、プロジェクトの正しさを長期的に保証するための情報構造アーキテクチャということになります。
6-1. GDD の構成要素
GDD は、ざっくり次の 4 要素で構成されます。
Specification（仕様）
- 純度管理された SSoT。
意図・境界・前提条件を含む「保証要求の源」。
- 純度管理された SSoT。
Test（テスト）
- Guarantee を実行可能にする投影。
Contract Testing や E2E テストと統合される。
- Guarantee を実行可能にする投影。
Guarantee（保証）
- Purity / Context / Safety を統合した「誤り訂正構造」。
時間が経っても正しさを維持し続けるための運用レイヤ。
- Purity / Context / Safety を統合した「誤り訂正構造」。
PoC（Proof of Concept）
- 仕様を決めるための実験。
PoC コードは流用せず、知見だけを SSoT / DR に還元し、
正式版はゼロから再生成する。
- 仕様を決めるための実験。
これらを先ほどの三層（Purity / Context / Safety）の中で運用することで、
- コンテキスト汚染を防ぎ
- 出力のゆらぎを許容範囲に閉じ込め
- PoC の発散ノイズを本番に持ち込まず
という状態を、構造として維持できるようにするのが GDD の狙いです。
では、この GDD がどのような規模・性質のプロジェクトに向いているのかを、少しだけ整理しておきます。
6-2. 適用範囲：特に中〜大規模の AI エージェント開発で真価を発揮する
GDD は小さなプロジェクトでも有効ですが、本領を発揮するのは AI エージェントを使った中〜大規模開発だと考えています。
- チーム数・期間・境界（サービスや職種）が増えるほど、
「どの情報が正式仕様で、どれが過去の PoC やメモなのか」が爆発的に複雑になる- SSoT / DR / Mini-PoC で情報の役割と寿命を分離しておく価値は、規模が大きいほど跳ね上がる
- PoC〜本番の距離が遠いほど、
「PoC のコードを土台にしない」「知見だけを還元して再生成する」 という方針のリターンが大きい- 1 プロダクトを何年も育てる前提なら、PoC 由来のノイズを最初から持ち込まない設計が効いてくる
- 人の入れ替わりや責務分担が細かい組織ほど、
SSoT / DR が「組織の記憶装置」として機能する- 「誰がいつ何を決めたか」を個人の記憶に頼らず、AI にも人にも参照可能な形で残せる
逆に、数人・短期間の小規模プロジェクトでは、
- GDD の全部をフルセットで入れるというよりは、
- 「PoC を正式コードに流用しない」
- 「SSoT を 1 ファイルでもよいので用意する」 といった 軽量版から導入する 方が現実的です。
こうした事情から、GDD は
「AI エージェントを前提にした中〜大規模・長期開発」に最適化されたパラダイム
として位置づけるのが自然だと考えています。
7. まとめ：AI 時代の開発とは「正しさを設計し続ける営み」
AI エージェントを使った開発では、
- コードを書くコストは急速に下がり
- 仕様を決めるコストと
- コンテキストを清潔に保つコストと
- ゆらぎを検知・訂正するコスト
が相対的に重くなっていきます。
このとき、私たちが本当に設計すべきなのは、
一度きりの「正しい実装」ではなく、時間と変更に耐える「正しさの維持構造」そのものです。
SSoT / Mini-PoC / DR / 誤り訂正的な Safety 構造を組み合わせ、
コンテキスト汚染と出力のゆらぎに対抗するための思想としてまとめたものが、
ここで述べた Guarantee-Driven Development（保証駆動開発 / GDD） です。
この考え方はまだ思想レベルのものであり、実践を通じた検証が必要です。
ですが、AI エージェントと共に開発する時代において、
保証構造を中心に据えた開発体系は今後必要になると考えています。
今後は実際の業務への適用を通じて、この考え方の有効性と実用性を検証していきたいと思います。
イマムラ ヨウイチ Yoichi Imamura
データ･AI ソリューション本部 データインフラ統括部 データインフラ部 シニアエンジニア
2011年からキャリアをスタートし、フロントエンドエンジニアとして様々なWebサイトの設計・実装を経験。インタラクティブエージェンシーではナショナルクライアントをはじめとした多数の案件に従事。関係者が100人を超える大規模サイトの設計や実装、システムやサーバーサイドとの連携など幅広い領域を担う。現在パーソルキャリアにて新規事業開発に携わり、フロントエンド開発、UIデザインなどを担当。
※2025年12月現在の情報です。
*1:リンク先および本記事の内容は個人の見解であり、所属組織を代表するものではありません。
