7月14日、InfoQが「Comprehension at AI Speed: Building a Context Store for Evolutionary Architecture」と題した記事を公開した。この記事では、AIが加速するコード生成の裏側で失われていく「設計の意図」をどう保持するか、そのための「コンテキストストア」という仕組みについて詳しく紹介されている。以下に、その内容を紹介する。

AIが速くするのはコードだけで、理解は置き去りにされる

2025年、METRが経験豊富な開発者を対象に行ったランダム化比較試験で、AIツールを使った開発者は使わない開発者より19%遅かったという結果が出た。興味深いのはその後で、同じ開発者たちに自己評価させると「AIのおかげで20%速くなった」と回答した。認識と実態の乖離は39ポイントに達する。

なぜこうなるのか。記事の核心はここにある。AIは機能の最初の80%——スキャフォールディング、コンパイル、テスト生成、デモ——を劇的に速くする。しかし残りの20%、既存システムとの統合、エッジケース、「なぜ前のバージョンがその設計判断をしたか」という制度的記憶、そこにこそアーキテクチャが宿っている。AIはその最も遅くて重要な部分を、手遅れになるまで隠してしまう。

問題をより構造的に言い換えると、コードを書くことと、そのコードがなぜそうなっているかを理解することが切り離されてしまった。従来、開発者はコードを書く行為を通じて自然に理解を獲得していた。AIはその「強制的な学習」の仕組みを取り除いた。コードは機械のスピードで出荷されるが、理解は出荷されない。

事故は「見えない」うちに積み上がる

記事はこの問題を2つのレイヤーで示している。

チームレベルでは、2026年3月のAmazonストアフロント障害が引き合いに出される。AI支援によって加えられた変更が適切なレビューなしにマージされたことが原因とされ、Amazonはその後、AIによるコードへのシニアエンジニアの承認要件を導入した。だがこれはあくまで手続き上の対処であり、「その変更の背後にある設計の根拠を誰も持っていなかった」という構造問題には手が届いていない。

組織レベルでは、Googleの2025年DORАレポートがAI導入とソフトウェアデリバリーの不安定化の相関を報告している。スループットは上がるが、テスト・バージョン管理・フィードバックループの弱点が露呈する。CTOはダッシュボードで「何かが変わった」と分かる。しかし何がアーキテクチャレベルで変わったのかを、取締役会に説明できない。

解決策：コンテキストストアという概念

記事が提唱するのがコンテキストストアだ。設計の意図、振る舞い、アーキテクチャへの適合性を、バージョン管理された決定論的な記録として保持する仕組みで、人間のレビュアーとAIエージェントの双方がクエリできる。LLMの記憶に頼るのではなく、リポジトリ内のアーティファクトそのものがソースオブトゥルースとなる。

このコンテキストストアを構築・維持するのが、以下の3つの検証ディシプリンを一つのシステムとして動かすことだ。

1. スペック起点のSDD（仕様駆動開発）

意図のレイヤーを担う。機能の意図・スコープ・制約・受け入れ条件を記述した機械可読な仕様書をコードと並べてリポジトリに置き、すべての変更でそれを強制する。仕様書はAIエージェントへのブリーフィングであり、人間レビュアーの参照先でもある。

Martin Fowlerが「spec-first-then-discard（仕様を書いてから捨てる）」と呼ぶアンチパターンに注意が必要だ。エージェントへのブリーフィングのためだけに仕様を作り、その後更新しなければ、エージェントは古い意図に基づいてコードを生成し続ける。なお、2026年のMarriらの銀行マイクロサービス事例では、仕様レイヤーで制約を強制することで制約なし生成と比較してセキュリティ欠陥が73%減少したと報告されている。

最初の一歩：今スプリントで1機能分の /specs/ ファイルをコミットし、コードと同様にレビュー対象とする。

2. TDD（テスト駆動開発）

振る舞いのレイヤーを担う。本番コードより先にテストを書く、あのRed-Green-Refactorだ。AIの文脈でTDDの重要性が増している理由は単純で、コードが人間が読み切れないスピードで届くとき、テストこそがレビュアーが見落とした振る舞いのリグレッションを捕まえる唯一の層になるからだ。

記事が強調するのは、エンジニアが「何をテストすべきか」を判断する力こそが、このループの要になるという点だ。プロンプトスキルと同時に技術的な深度に投資することが、コンテキストストアの信頼性を保つ。

最初の一歩：次のエージェント主導の変更で、生成されたコードを受け入れる前に失敗するテストを書く。

3. アーキテクチャ適合性関数（Fitness Functions）

構造のレイヤーを担う。モジュール性、パフォーマンス、セキュリティ、デプロイ可能性、オブザーバビリティといったアーキテクチャ特性を自動・実行可能なチェックで検証する。ArchUnit（Java）やdependency-cruiser（TypeScript）といったライブラリがCIパイプラインに組み込まれ、アーキテクチャ特性が退行した際にマージをブロックする。Ford・Parsons・Kua・Sadalageの著作で体系化され、Thoughtworksが実践手法として発展させた概念だ。

最初の一歩：最もリスクの高い特性について、CIをブロックする適合性関数を3つコードに組み込む。

「理解可能性」はアーキテクチャ特性になった

記事の最後の主張は示唆に富む。可用性・弾力性・レジリエンス・セキュリティと並んで、「comprehension（理解可能性）」がアーキテクチャ特性として設計・保護すべき対象になったというものだ。

コード生成がコモディティ化した世界では、設計フェーズが必須となり、差別化の源泉はドメインを理解することとシステムの論理をライフサイクル全体で保持するガードレールを設計することにシフトする。コンテキストストアはその「ガードレール」の実装形態だ。

詳細はComprehension at AI Speed: Building a Context Store for Evolutionary Architectureを参照していただきたい。