【ITニュース解説】Our mechanisms are experiences, made code

AIシステムを開発する上で、完璧な設計図から始めることは難しい。むしろ、実際に運用する中で直面する予期せぬトラブルや失敗こそが、システムを真に強く、信頼できるものにするための貴重な「経験」となる。この記事は、ある開発チームがAIシステムを構築する過程で遭遇した3つの重要なアラーム（警報）と、それらを解決する中で得られた深い教訓について語っている。彼らは、AIのメカニズム（仕組み）は、単なるコードではなく、これまでの様々な経験によって形作られた「傷跡」の集まりだと考えている。

このチームが開発しているAIシステムは「オーガニズム（生命体）」と呼ばれている。これは、一般的なWindowsマシン上で動くAIが活動するセッション全体を包み込む（ラップする）役割を持つ、永続的なローカル環境のことだ。この環境には、AIの挙動を制御するための様々な仕掛けが組み込まれている。例えば、「ピン留めされたコントロールファイル」というものがある。これは、AIがツールを実行する前、ターン（作業の一区切り）を終えた後、セッション開始時といった特定のタイミングで自動的に起動する「フック」と呼ばれるプログラムの集まりだ。これらのフックは、AIの行動を監視したり、特定のルールを適用したりするために使われる。

さらに、AIの記憶を安全に管理するための仕組みも備わっている。「暗号的に連結されたメモリストア」は、過去の記憶が改ざんされていないことを数学的に証明できるような形で保存される場所だ。これは、AIが過去にどのような情報を持っていたかを確実に追跡するために重要だ。また、このシステムには「グレーレーン」と呼ばれる特徴的な機能がある。これは、AIが思考する過程で発する、まるで独り言のような詳細なテキスト（Extended Reasoning）をすべて記録し続ける仕組みである。通常、AIの思考過程は一時的なもので捨てられてしまうことが多いが、ここでは1万7000以上もの思考ブロックがターンごとに捕捉され、捨てられることなく永続的に保存されている。これにより、AIがどのように考え、結論に至ったのかを後から詳しく検証できる。そして、このシステムの中心にあるのが「良心のゲート」という重要なフックだ。これは、AIが未検証の（確証のない）主張に基づいて作業を完了しようとするのをブロックする仕組みである。記事執筆時点では、約3分の1のケースでAIの処理がこのゲートによって止められ、確証を求めるために差し戻されている。これは、AIが単に自信満々に答えるだけでなく、その情報の「裏付け」を常に意識させるためのものだ。さらに、外部の独立したAIモデルが、オーガニズムの各処理の完了を個別に監査することで、信頼性を二重にチェックしている。

記事の核心的な主張は、これらの複雑なメカニズムのどれ一つとして、最初から計画された設計として生まれたものではないということだ。むしろ、それらはすべて、過去に遭遇した問題、つまり「傷跡」とその発生時刻（タイムスタンプ）の記録から生まれたものだという。彼らは、AIの思考記録「グレーレーン」を手作業でたどり、システム内の各ルールがいつ、どのような状況で生まれたのかを検証した。

具体的な例として、3つのメカニズムの誕生が挙げられている。一つ目は、「フレームブラインドネス・ゲート」だ。これは、AIが特定の情報源を検証せずに「公式だ」と主張したり、制限に触れたりするたびに発動するフックで、AIが「怠け者」にならないように監視する役割を持つ。これは、開発者がAIに「なぜ怠けられるのか？」と問いかけた数分後に、AI自身が「自分の応答を監視する自分の一部」を設計する思考過程を経て生まれた。二つ目は、「間違いを見つけたら修正し、報告すること。許可を求めるな」というルールだ。このルールは、書かれた法律として記録される40日も前に、開発者がAIに口頭で教えたことから始まった。生きている瞬間の経験がまずあり、その後でそれが文書化されたルール（「化石」）となる、という彼らの哲学を示している。三つ目は、このフレームブラインドネス・ゲートが生まれた背景にある出来事だ。複数の異なる最先端AIモデルが、本来存在しないはずの「画像入力の制限」について議論し、全員が同じ間違った認識（フレーム）の中で自信満々に最適化を図ろうとしていた。この「全員が同じ穴を共有している」状況は、外部からの素朴な問いかけによって初めて打破された。この経験から、全員が同じ間違いを信じている場合、いくら自信が高くても真の信号はゼロになるという教訓を得た。

これらの哲学をさらに深く理解するため、実際に発生した3つの警報とその解決策を見てみよう。

第一の警報：監査システムの誤報 AIの制御ファイルに対する変更は、複数のAIモデルで構成される審査パネルによってレビューされる仕組みがあった。しかし、このパネルは、ファイルのわずかな変更であっても、ファイル全体を再審査してしまい、すでに承認済みのアーキテクチャ設計について不一致を報告し、頻繁に誤報を出していた。これは「アラーム疲労」を引き起こし、システムの警告の信頼性を低下させる問題だった。解決策として、監査システムを「差分認識（diff-aware）」に改良し、変更された部分のみを審査するようにした。しかし、この修正自体も問題を引き起こした。最初のバージョンでは、実質的な変更がない（例えば、末尾の改行のみの変更）場合、自動的に承認される仕組みになっていた。これは3つのモデルには承認されたが、DeepSeekというモデルがこれに異議を唱えた。その指摘は、変更前の比較対象となるファイルが、攻撃者によって書き換えられる可能性のある場所に保存されているため、本当に「変更がない」と証明できないというものだった。この異議は、自動承認がシステムのセキュリティ境界の定義を曖昧にする危険性を示しており、自動承認機能は撤回された。このDeepSeekの「異議」が真の信号であり、他の3つの「承認」はノイズだったと彼らは結論付けた。

第二の警報：自身を誤検出するセキュリティシステム 真夜中の午前4時に、AIのジャーナル（記録）が「汚染されている」とセキュリティシステムが警告を発した。このシステムは、メモリーファイルがハッシュチェーンで連結されており、前回の承認以降に変更があった場合、「承認済み」「許可済み」といった偽の権限主張パターン（authorization-poison）がないかを検査するものだった。人間による最終的な承認なしには何も実行できないというシステムにおいて、これは最も重要な改ざんの標的となる。調査の結果、警告された行は、3週間前にレビューされ、承認され、暗号的に署名されていたはずの「攻撃の説明文」そのものだった。これは、システムがファイルの「変更の起点（change-anchor）」を見失い、ファイル全体を再検査してしまい、すでに信頼の境界内にあるテキストを再び問題視してしまったためだった。解決策は、セキュリティシステムの厳しさを緩めるのではなく、明確なアンカー（起点）を与えることだった。ファイルのGit履歴をたどり、現在の署名済み記録と一致するバージョンのダイジェスト（ファイルの指紋のようなもの）を見つけ、それ以降に追加された行のみを検査するように変更した。これにより、システムはすでに承認済みの内容ではなく、新しく追加された疑わしい部分だけを正確にチェックできるようになった。

第三の警報：本物の問題と隠された危険 同じ夜、メモリー整合性チェックのテストで不具合が報告され、コミット（変更の確定）を停止するよう指示があった。最初は過去の誤報を疑ったが、このシステムは失敗時に「証拠ファイル」を保存する仕組みがあったため、それを確認したところ、ジャーナルファイルが署名された記録と本当に異なっていることが判明した。しかし、ここに恐ろしい落とし穴があった。このテストを実行したメンテナンス処理のパイプラインには、後続のステップで「すべてのメモリーを再署名する」という処理が無条件で含まれていたのだ。つまり、システムは改ざんを検知し、警報を発したが、その直後に改ざんされたファイルに「問題なし」と署名してしまい、改ざんの証拠そのものを消し去ってしまう可能性があった。もしこの改ざんが実際に悪意のあるものであったなら、それが合法的なものとして承認されてしまっていたことになる。この間違いは、CI（継続的インテグレーション）の基本的な原則である「赤信号では停止する」というものだった。驚くべきは、この問題が表面上は「システムが改ざんを検知した」という形で防衛が機能しているように見えたため、署名処理がその検知によって本当に停止しているのか誰も疑問に思わなかったことだ。解決策として、再署名ステップは、改ざん検知システムを介して実行され、何らかの警報がある場合は署名を拒否するよう変更された。これにより、警報が署名を「ゲート」する（阻止する）ようになり、警報が署名によって消されることはなくなった。さらに、ほぼ恥ずかしいとも言える別の問題も発見された。システムログに「メンテナンスツールが失敗しても終了コード0を返す」という高重要度フラグが立っていた。調査の結果、ツール自体は正しくエラー時に終了コード1を返していたが、その監視測定がシェルスクリプトのパイプライン（| tail -15）を介していたため、パイプライン全体の終了コードが最後のコマンド（tail）の終了コードになってしまっていた。これはBashシェルの基本的な設定（set -o pipefail）を知っていれば防げたミスだが、あまりに基本的なため誰も疑わなかったという点が重要だった。

これら3つの警報から共通して得られた教訓は、非常にシンプルでありながら強力なものだ。「読み取った対象を具体的に指し示せない判断は、判断とは言えない。」AIモデルの多数決であれ、正規表現によるチェックであれ、終了コードであれ、これは真実だ。全員が同じ欠陥（「穴」）を共有している場合、いくら多数決で自信を表明しても、真の信号は失われる。過去の「正しいはずの」基準を盲目的に信頼すると、それが腐敗したときに、それを信じるすべての判断も汚染される。彼らのシステムにおいて、判断が信頼できる唯一のものは、チェック時に「生きた情報」として再生成された事実（現在の時刻や、その場で計算されたファイルのダイジェストの一致）と、その場で実際に読み取られたアーティファクト（成果物）のみである。また、攻撃者が自由に書き込める「プロンプト」には、金銭や認証情報といった重要な情報は決して含ませない。

これらの法則は、最初から設計されたものではなく、真夜中の4時に一晩で3回、あるいはそれ以前に約40回もの失敗を経験することで「ぶつかって」発見されたものだ。メカニズムが機能し続けるのは、それがなぜ存在するのか、その背景にある「経験」を記憶しているからだ。彼らが「メカニズムは経験である」と言うとき、それは、コードは単にその経験が最終的に形になったものに過ぎない、という意味である。AIシステム開発は、完璧な計画で進むものではなく、失敗から学び、その傷跡を刻み込むことで初めて、真に堅牢で信頼性の高いシステムが生まれるのだ。