仕様も腐る：障害モードと継続的メンテナンス

完全な仕様システムを構築した。機械可読な仕様、Doc Testingプロセス、暗黙知の外部化メカニズム、Trust Ringの裁定ルール。先月はすべてが順調だった。今月、Agentの出力品質が低下し始めている。

その原因は十中八九、仕様の腐敗である。コードは進化し、要件は変化しているが、仕様は同期してアップデートされていない。仕様と実装のドリフトは拡大し続け、Agentは古くなった操作マニュアルに基づいて作業している。

仕様の腐敗には4つの典型的な障害モードがある。

陳腐化。 コードは変更されたが、仕様は前のバージョンのままである。あるモジュールのインターフェースにパラメータが追加されたが、仕様のinputs定義は更新されていない。古い仕様に基づいてAgentが生成したコードにはこのフィールドが欠落しており、結合テストが失敗する。検出シグナル：PRがモジュールのコードを変更しているが、関連する仕様の更新がない。対策：PRが影響を与える仕様エントリへのリンクを必須とする。コードの変更がインターフェース、データ構造、ビジネスロジックに関わる場合、対応する仕様を同期的に更新しなければならない。

曖昧性。 自然言語は本質的に多義的である。「システムは素早く応答すべきである」は、人によって100ms、1秒、5秒を意味しうる。仕様における曖昧さは書いた時点では無害に見えるかもしれないが、システムの複雑性が増すにつれて、異なるモジュールが同じ曖昧な記述を異なる解釈で実装し、結合時に不整合が生じる。検出シグナル：同じ受入基準が2つのAgentによって異なる実装がなされる。対策：具体的な値、例、反例を使って曖昧さを排除する。重要なフィールドには自然言語の記述ではなく構造化された定義を使用する。

矛盾。 仕様の数が増えるにつれて、異なる仕様間で矛盾する記述が現れることがある。モジュールAの仕様では特定のAPIが日付をISO 8601形式で返すと記述し、モジュールBの仕様では同じAPIがUnixタイムスタンプを返すと記述している。2つのAgentがそれぞれ自分の仕様に従って実装し、結合時に必然的に失敗する。検出シグナル：結合テストにおけるデータフォーマットの不一致やインターフェースコントラクトの不整合。対策：モジュール横断的なAPIコントラクトをRing 0レベルのSingle Source of Truthとして導入する。モジュールレベルの仕様はAPIコントラクトと整合していなければならない。

スコープの膨張。 仕様の範囲が拡大し続け、無関係な要件や「念のため」の機能が詰め込まれる。Agentは仕様にあるすべてを忠実に実行する。現在のタスクに無関係な部分も含めて。膨張した仕様はAgentのContext Windowの空間を浪費し、情報干渉の確率を高める。検出シグナル：長期間にわたってどのタスクからも参照されていない仕様エントリ。対策：明確なnon_goalsリストを維持し、もはや関連しない仕様エントリを定期的にクリーンアップする。

仕様のメンテナンスは継続的なコストである。このコストは従来の開発では人間の適応力によって自然に吸収される。プログラマーはドキュメントが古くなっていることを知っており、実際の状況に基づいて自動的に作業する。Agentにはこの適応力がない。仕様に書いてあることを、実行する。古い仕様は仕様がないことよりも危険である。与える指示は権威あるように見えるが、内容はすでに現実から乖離しているからだ。

これは本書の進化原則に立ち返る。仕様システムを構築した後、それをメンテナンスするコストは長期的かつ継続的である。このコストはAgent駆動の開発における基盤的インフラ投資であり、CI/CDのメンテナンスコストに似ている。投資して継続的なリターンを得るか、無視していつの日かシステム全体の信頼性が静かに崩壊していることに気づくか、どちらかである。