あなたの AI エージェントにはルールファイルがあります。システムのモデルはありません。

あなたのリポジトリのルートにある CLAUDE.md、AGENTS.md、.cursor/rules を開いて、エージェントに届くときと同じように読んでみてください。ひとかたまりのテキストとして、どの行がまだ正しいのかを示すものが何ひとつ入っていない状態で。

そこにあるものの大半は規約です。タブを使う。any を使わない。早期に return する。エラーは %w でラップする。こうした行は長持ちします。コードを一行どう書くかを述べているからで、エージェントは目の前のコードにそれを当てはめます。

そしてもう一種類の行があります。あなたのシステムを記述する行です。どんなサービスが存在するのか、どの package が何を持っているのか、レイヤー同士がどう会話してよいのか。このファイルを持つ価値はその行にあり、そして腐るのもその行です。

私にはそれが分かります。私たちのファイルが腐ったからです。

私たちのファイルで古びたもの

Archyl のリポジトリにはルートに CLAUDE.md があります。このジャンルの水準からすれば出来のよいものです。422 行、アーキテクチャのツリー、設定変数、dependency injection の配線、discovery パイプラインの説明。このコードベースに触れるエージェントは、他の何をするよりも先にこれを読みます。

これを書いた日の朝、2026 年 8 月 5 日の時点で、そこにはこう書かれていました。392 行目：

No test suite: The codebase currently has no Go test files or frontend tests.

テストスイートなし：このコードベースには現在、Go のテストファイルもフロントエンドのテストも存在しない。

backend/ の下に 146 個の _test.go ファイルがあり、frontend/src/ の下に 31 個のテストファイルがあります。

140 行目にはこうあります：

AI Provider Abstraction: Supports both OpenAI and Ollama via ai.Provider interface.

AI プロバイダーの抽象化：ai.Provider インターフェース経由で OpenAI と Ollama の両方をサポートする。

backend/internal/adapter/ai/resolver.go は、プラットフォーム管理の OpenAI・Ollama 経路に加えて、OpenAI、Anthropic、Gemini、Bedrock、および OpenAI 互換のあらゆるエンドポイントへルーティングしています。ひとつの switch 文に五つのプロバイダータイプ。ファイルが名前を挙げているのは二つです。

そしてアーキテクチャのツリーは、74 行目から 87 行目にかけて internal/domain/ の下に十一の package を挙げています。c4、project、user、team、adr、projectdoc、flow、insight、subscription、dependency、history。今日、internal/domain/ には四十一のディレクトリがあります。挙げられていない三十のうちには次のものが含まれます。conformance、drift、apicontract、marketplace、reality、managedagent、mcpsession。つまり、このファイルが書かれて以降にプロダクトがなってきたものの、ほとんどです。

これらの行はどれも、打ち込まれた日には正しいものでした。そのあと訂正されたものはひとつもありません。訂正するには人が気づく必要があり、そして誰も見張っていなかったからです。

ここはアーキテクチャドキュメントを売っている会社です。もし規律が解決策なら、ここでこそ機能していたはずです。

そのファイルの二つの半分には、何ひとつ共通点がない

規約の側は強制できます。「Go で fmt.Println を使わない」は grep です。「Go のファイル名は snake_case でなければならない」はスクリプトです。エージェントがどれかに違反すれば、CI で linter がそう言います。規約そのものが変われば、linter が落ちはじめて誰かがファイルを更新します。フィードバックループがあり、そしてそれは機能するだけの短さです。

システムの側には、それに相当するものがありません。「決済サービスはデータベースへの直接アクセス禁止」に対する go vet は存在しません。その文をパースするものはなく、リポジトリと突き合わせるものもなく、一致しなくなったときに失敗するものもありません。markdown ファイルの中の散文であり、散文には失敗モードがありません。

つまりルールファイルとは、ひとつのファイル名を共有する二つの文書です。片方は継続的に検証され、もう片方は一度も検証されず、そしてファイルの中にその二つを区別するものはありません。「エラーは %w でラップする」と「このコードベースにはテストがない」が、同じリストに、同じ声で並んでいます。片方はエージェントの目の前にあるコードについてのルールです。もう片方は、エージェントが見てもいない 146 個のファイルについての主張です。

不在のほうが難しい半分

古びることは、誰もが思い浮かべられる失敗です。より静かなほうが重要です。ルールファイルには、誰かが書き留めようと思いついたものしか入っておらず、そしてその中に「これは存在しない」と「誰も言及しなかった」を区別するものは何もありません。

私たちのファイルは internal/adapter/marketplace/ に一度も触れていません。この package には provider インターフェースと八つのアダプターが入っています。GitHub、GitLab、Argo CD、Datadog、Prometheus、Sentry、SonarQube、PagerDuty。CLAUDE.md のアダプター一覧は git、ai、stripe、email、osv、registry で止まっています。このファイルが marketplace について述べていることに、間違いはひとつもありません。このファイルには marketplace がないのです。

九つ目のインテグレーションを追加するようエージェントに頼む実験を、私はやっていません。そしてそれが何を出力するかをあなたに語るつもりもありません。結果をでっち上げることになるからです。私が言えるのは、地図の上に marketplace は載っていないということ、そしてこれが私の読んできたあらゆるルールファイルの、自分で書いたものも含めた、ごく普通の状態だということです。

モデルにはその性質がありません。モデルには何が存在するかを尋ねられますし、意味のある答えが返ってきます。その答えが、散文の中の検索ではなく、集合に対するクエリだからです。「決済サービスと会話しているのは何か」は、グラフなら答えられて段落には答えられない問いです。

明白な二つの答えと、そのどちらも成り立たない理由

もっとよいルールファイルを書く。 もっと長く、もっと注意深く、pull request のテンプレートにチェックボックスをひとつ。チームはこれをやりますし、数週間はうまくいきます。長続きはしません。規律とは無関係な理由によってです。システムを記述する行はどれも、よそに存在するもののキャッシュされたコピーであり、キャッシュには無効化が必要です。ここでの無効化とは、人間が気づくことです。それが仕組みのすべてであり、そしてそれはこの二十年間アーキテクチャ図を正確に保つはずだったのと同じ仕組みです。どうなったかは私たちも知っています。drift 検出のガイドはこの議論の長いバージョンです。

エージェントにリポジトリを読ませる。 できますし、ファイル一個についての問いであれば読ませるべきです。しかしコードを読んでも、どの境界が意図的なものだったのかは分かりません。サービスの前に置かれたインターフェースは、二年前のインシデントの後に下された決定によってそこにあるのか、それとも誰かがインターフェースを好きなだけなのか、まったく同じ見た目をしています。意図は、そこから生まれた成果物からは復元できません。そもそもルールファイルが存在する理由がそれであり、そして削除することも答えにならない理由もそれです。

この会社の外にも、同じことに気づいた人がいる

Thoughtworks は「Architecture drift reduction with LLMs」を Technology Radar Vol. 34 の Assess リングに置きました。2026 年 4 月の公開です。その冒頭：

Increased use of AI coding agents can accelerate drift from the intended codebase and architecture designs. Left unchecked, this drift compounds as agents and humans replicate existing patterns, including degraded ones, creating a feedback loop where poor code begets poorer code.

AI コーディングエージェントの利用が増えると、意図したコードベースおよびアーキテクチャ設計からの乖離が加速しうる。放置すれば、この drift は、エージェントと人間が既存のパターン（劣化したものも含めて）を複製するにつれて積み重なり、質の低いコードがさらに質の低いコードを生むというフィードバックループを作り出す。

Assess とは、レーダー自身の定義では "worth exploring with the goal of understanding how it will affect your enterprise" — 自社にどう影響するかを理解する目的で探索する価値がある、という意味です。これは何かの推奨ではありませんし、まして私たちの推奨ではありません。彼らのいくつかのチームがこれを試していて、まだ早い段階にある、というメモです。

有用なのは、彼らが描いている形です。決定論的な解析ツール（Spectral、ArchUnit、Spring Modulith を挙げています）と LLM による評価の組み合わせ。構造はプログラムで検査でき、意図は検査できないからです。彼らが報告している教訓も盗む価値があります。最初のスキャンは、誰もがトリアージしたいと思う量を超える違反を掘り出します。

そのレシピに入っていないものに注目してください。エージェントが加速させる drift への答えとして、より長い markdown ファイルを挙げている人は誰もいません。

その成果物が満たすべき条件

二つの性質です。どちらも風変わりなものではありません。

列挙できなければならない。 何が存在するかを尋ねたら、誰かの記憶ではなく集合が返ってくるべきです。つまり、読むのではなく問い合わせる成果物であるということで、その差がいちばん厳しく現れるのは、誰も書き留めなかった問いに対してです。

反証可能でなければならない。 何かがそれをコードと突き合わせ、どの部分が正しくなくなったかを報告しなければなりません。しかも「人間が気づいたとき」ではないスケジュールで。ArchUnit は Java のレイヤールールについてこれをやります。dependency-cruiser は JavaScript の import についてやります。どちらも意図的に狭い範囲であり、そしてどちらも論点を示しています。持つ価値のある成果物とは、プログラムが異議を唱えられる成果物です。

ルールファイルはその両方で落第します。列挙しませんし、何もそれに異議を唱えられません。

私たちの立ち位置と、私に言えないこと

Archyl はあなたのシステムの C4 モデルを維持します。システム、コンテナ、コンポーネント、関係。AI ディスカバリーがリポジトリから生成し、人が描くのではなく人が承認します。このモデルが列挙可能な側であり、エージェントは MCP 経由で、181 個のツール分の広さでそこに到達します。だからエージェントは、誰かが書き留めてくれていることを期待するのではなく、何が存在するかを尋ねます。規約の側は conformance カタログです。名前の付いた 23 の技術にまたがる 169 のルールと、言語非依存のセット。散文ではなく決定論的なチェックです。そしてモデルはコードと再度突き合わせられ、スコアが付きます。これが反証可能性の性質です。

MCP サーバーを持っていること自体は面白い部分ではありませんし、それを差別化要因として売り込んでくる相手は、あなたにコンセントを売っているだけです。Structurizr も出していますし、IcePanel のものはオープンベータ中です。議論する価値のある問いは、コンセントの向こう側にあるものが維持されているかどうかです。3 月に古びたモデルを配信するエンドポイントは、より速く間違うための手段でしかないからです。

私はそれが重要な違いだと思っています。証明はできません。維持されたモデルから作業するエージェントが、丁寧なルールファイルから作業するエージェントより形の良いコードを書くかどうかを、誰も測定していません。誰かが測定するまで、その文はメカニズムについての主張であって、結果ではありません。そのように保持してください。そして、私が今言ったよりも断定的に言う人がいたら、押し返してください。

ここには正直に言っておくべき折り目もあります。Archyl はルールファイルを生成します。MCP ツール get_agent_context は、アーキテクチャを、あなたのリポジトリに commit できる markdown のブリーフィングとして返します。これは名前の違うルールファイルです。ファイルが問題だったことは一度もありません。問題は、その背後に何も立っていなかったこと、だから何もそれを再生成できなかったことです。維持されたモデルのキャッシュであるルールファイルは、問題ありません。唯一のコピーであるルールファイルは、ある一人がある午後に信じていたことのスナップショットです。

五分でできるバージョン。あなたには何のコストもかかりません

上に書いたことは全部無視して、代わりにこれをやってください。

あなたのルールファイルを開きます。一行ずつたどって、それぞれを規約（エージェントにコードの書き方を伝えている行）か、主張（エージェントにあなたのシステムについて何かを伝えている行）のどちらかに印を付けます。そのうえで、主張のひとつひとつについて、それがもう正しくなくなったと分かる手がかりが何かを書き出します。

私の予想では、あなたは二列目が空のままファイルの末尾に到達します。それがギャップです。それについて何をするかは別の判断であり、そしてそれを見るために何かを買う必要はありません。

私たちのファイルでは数分かかり、間違った行が三つ出てきました。直すのは commit ひとつぶんで、構造的には何も変わりません。次の行は同じように古びますし、その行を見張っているものもまた、何もないからです。