8月31日、O'Reillyが「Architectural Guardrails for AI-Generated Code」と題した記事を公開した。この記事では、AIコーディングエージェントが引き起こすアーキテクチャ崩壊のパターンと、それを防ぐために必要な「エンジニアリングガバナンス」層について詳しく解説されている。
AIは「正しいコード」を書く。でも「正しくない判断」をする
記事の冒頭に登場するのは、あるスタッフエンジニア「Priya」のPRだ。340行。テストはパス。コードは綺麗。しかしそのPRは、顧客テーブルに対して内部APIを経由せず直接書き込む実装になっていた。
チームはその禁止決定を2年前にADR（Architectural Decision Record）として記録していた。ADRとは、アーキテクチャ上の意思決定をその背景・理由・結果とともに残す軽量ドキュメント手法で、2011年にMichael Nygardが提唱して以来、特にマイクロサービス移行を経たチームの間で広く普及してきた。しかし、そのADRはワークフローが参照しないディレクトリに眠っており、AIエージェントにも、レビュアーにも、届いていなかった。
2週間後、監査ログの欠落が発覚。該当エンドポイントは書き直され、1スプリントがクリーンアップに消えた。
記事はこれを「ハルシネーションではない」と明確に述べる。出力は構文的に正確で、慣用的なコードだった。「モデルの品質問題でもない」とも言う。より優れたモデルを使っても、コンテキストにADRがなければ結果は同じだ。これは組織的な記憶の問題である、と。
コードチャーンが861%増という数字
Faros AI（エンジニアリング分析プラットフォーム）が2026年に公開したレポートによれば、22,000人以上の開発者・4,000以上のチームのテレメトリを分析した結果、AI導入率が低い時期から高い時期にかけてAIコードの受け入れ率が20%から60%に上昇した一方、コードチャーン（追加後数日以内に削除される行数）は861%増加したという。
Faros自身も「全てが悪いリワークとは限らない」と慎重に注釈しているが、それでもこの数字は、リポジトリに入るコードと「生き残るコード」の間に大きなギャップがあることを示している。
既存ツールが「間違った層」にある理由
記事が核心に触れるのがここだ。多くのチームがこのギャップを埋めようと既存のツールに手を伸ばすが、いずれも問題の形に合っていないと指摘する。
- Cursor RulesやCLAUDE.md：正しい発想だが解像度が低い。バージョン管理も優先順位も、違反を検出する仕組みもない。「設定の形をしたドキュメント」に過ぎない。
- リンターやフォーマッター：構文レベルの強制は得意だが、「顧客データの書き込みはAPIを経由すること」のような意味的な決定は扱えない。
- 依存関係スキャナー：既知の脆弱なライブラリは検出できる。Priyaのケースには何も引っかからない。問題はライブラリではなく、チーム内のルーティング判断だからだ。
- LLMによるコードレビュー：PRを別のAIに読ませる手法。表面的なバグは見つけられるが、最初のAIと同じ盲点を持つ。「同じ死角を2回確率的に通過しても、1回の決定論的な検証にはならない」と記事は言う。
- 人間によるレビュー：AIエージェントは、人間レビュアーが1件を精査する時間に、複数の実装・PR・リビジョンを生成できる。コード出力はスケールするが、レビューの注意力はしない。
「これらのツールが悪いのではない。ドリフト問題に対して層が違うだけだ」と記事は結論づける。
必要なのは「エンジニアリングガバナンス」層
記事が提唱する解決策は、チームが記録した工学的決定をAIツールと繋ぐ専用の層を設けることだ。記事はこれを「エンジニアリングガバナンス」と呼ぶ。データガバナンスやセキュリティガバナンスと同じ文脈で使われるこの言葉は、「組織が暗黙的に従っているルールを明示的・強制可能にする仕組み」を意味する。
なお、この層はRAG（Retrieval-Augmented Generation）とは異なる位置づけにある。RAGが「関連ドキュメントを確率的に取得してLLMの回答精度を高める」手法であるのに対し、ガバナンス層が求めるのは「どのADRが適用されたか」を後から監査・再現できる決定論的な強制だ。確率的な推論が許されるのはあくまで「取得・推薦」の段階までであり、強制の判断は決定論的でなければならないという点が、単純なRAG活用との本質的な違いである。
この層に求められる4つの機能は以下の通りだ：
- ADRを優先順位とライフサイクルのメタデータ付きで保持する（どのADRが有効か、どれが廃止されたか）
- 決定を確実に検索・取得できる（同じコードが常に同じ関連決定を返す）
- エージェントがコードを書く前にコンテキストへ注入する（事後に検出するのではなく事前に反映させる）
- CIで強制する（違反コードをブロックまたはフラグを立て、特定のADR・マッチしたルールにトレーサブルにする）
「なぜこのPRがブロックされたか」という問いに対して、答えが「AIがそう言ったから」であってはならない。コード、ADR、取得ログ、ルールテキストという成果物から再現可能であることが、コンプライアンス審査や障害の振り返りで「説明できる」ための条件だ。
また、この層が何でないかも明確に定義されている：自律的なエージェントではなく、RAG的な「記憶」でもなく、AIによるコードレビューでもなく、特定ベンダーへの依存もない。Cursor、Claude Code、GitHub Copilot、Codexを並行使用するチームにとって、ガバナンス層はツールやモデルから独立している必要がある。
エンジニアリングリーダーへの処方箋
記事は、ツール選定とは独立に「今四半期中にやるべきこと」として3点を挙げる：
- ADRを棚卸しする。内容は最新か。廃止した決定を明示的に参照しているか。チームがADRを書いていないなら、今が始め時だ。
- 強制のスタンスを明示的に決める。警告のみにするか、マージをブロックするか。PRごと・開発者ごとに判断が揺れないよう、チームで合意すること。
- 「モデルが良くなれば解決する」と思わない。より優れたモデルでも、コンテキストに渡されていないADRには従えない。アーキテクチャドリフトを防ぐには、次のモデルを待つのではなく、周囲のシステムを変える必要がある。
詳細はArchitectural Guardrails for AI-Generated Codeを参照していただきたい。
