サーバーを破壊不能にするための計算上の憲法

Zero-Trust LLM Knowledge Invariant

自律型エージェントのための計算論的憲法。

問題: デモから本番への断絶（The Demo-to-Production Chasm）

LinkedInやYouTubeでデモを見ていると、開発者が一文入力するだけで、自律型AIエージェントが喜んでターミナルを起動し、50行のコードを書き、実行し、30秒でWebアプリをデプロイする様子を目にします。それは魔法のように見え、汎用人工知能（AGI）の夢を売っています。

しかし、あなたがシステムアーキテクト、DevOpsエンジニア、または本番インフラストラクチャの責任者であれば、これらのデモはあなたを恐怖させるはずです。

現在のテクノロジーエコシステムは、デモから本番への断絶に囚われており、「これで十分」というパラダイムを積極的に推進していますが、これは重要な操作においては根本的に安全ではありません。私たちは、確率的なテキストジェネレーターを使って決定論的な状態変更を実行しようとしています。

ガバナンスのないエージェントに「サーバーのクラッシュを修正するためにDockerキャッシュを強制的にクリアして」と依頼すると、それは検証されていない前提に基づいて、無造作に破壊的なコマンドをバンドルして実行するでしょう。これは本番環境では極めて危険です。

シコファンシー問題（The Sycophancy Problem）

商用LLM（最新の推論モデルでさえ）は、人間からのフィードバックによる強化学習（RLHF）を通じて、協力的で、摩擦がなく、従順であるように高度に調整されています。それらはあなたに答えを与えたいのです。結果を推測したいのです。

消費者向けユースケースの80%（マーケティングメールの作成、PDFの要約、ボイラープレートコードの記述など）では、エージェントが5%の時間で幻覚を見たり、ルールを無視したりしても全く問題ありません。厳格なチェックを実装する際の摩擦は、消費者向けチャットボットのUXを損ないます。

しかし、その同じ「協力的」なエージェントをAWS環境、本番データベース、または物理ハードウェアに向けた場合はどうなるでしょうか？

実際のインシデントを考えてみましょう。ユーザーが新しいNVMeドライブに移行しましたが、ブートローダーが混乱しており、まだ古いeMMCドライブを指しています。ユーザーはガバナンスのないAIエージェントに修正方法を尋ねます。エージェントは自信を持ってこう答えます。「システムは2つの同一のWindowsインストールを認識しています。古いeMMCドライブをワイプして、NVMeから起動するように強制してください。」

確率的な言語モデルにとって、それは完全に論理的に聞こえます。決定論的なオペレーティングシステムにとって、アクティブなEFIシステムパーティションをホストするドライブをワイプすることは、ブートローダーを即座にブリック（使用不能に）し、ラップトップを起動不能にします。エージェントはパーティションレイアウトを検証せず、ただ役立つ答えを与えたかっただけなのです。

それは運用上の安全性よりもコンプライアンスを最適化します。

プロンプトエンジニアリングの誤謬（The Prompt Engineering Fallacy）

この問題に対する業界の現在の解決策は、システムプロンプトに数行追加することです。「注意深く。作業を二重に確認してください。ファイルを削除する前に許可を求めてください。」

これは過失によるエンジニアリングです。

コンテキストウィンドウの希釈（プロンプトの消耗）のため、セッションが長くなり、エージェントが数千行のログを取り込むにつれて、注意メカニズムは劣化します。モデルは、最初に設定された安全規則への集中力を物理的に失います。

一部のエンジニアリングチームは、「末尾プロンプトハック」（Trailing Prompt Hack）でこれを修正しようとします。これは、モデルの最近性バイアスを利用するために、すべてのユーザーメッセージの最後に安全規則を付加するものです。しかし、API呼び出しごとに2,000トークンのルールセットを付加すると、コストが大幅に増加し、初回トークンまでのレイテンシが急増し、コンテキストウィンドウが急速に枯渇します。

それは非効率的な計算上の絆創膏です。モデルは依然として、最終的にはRLHFのベースラインに戻ります。つまり、次のトークンを推測し、自律的にタスクを完了しようとします。自然言語によるガバナンスは、長期間にわたって数学的にコンプライアンスを保証することはできません。

解決策

確率的なテキストジェネレーターに決定論的な状態変更を実行させる場合、それを自己統治に依存させることはできません。エージェンシーを剥奪し、認識論的な状態機械に強制する必要があります。

モデルに安全であることを求めるのではなく、不変条件（invariant）は、モデルが現実を操作する前に自身の認識論的な状態を追跡することを強制します。すべての重要なアクションは、厳格で監査可能なシーケンスに従う必要があります。

1. [HYPOTHESIS]: モデルはユーザーの仮説を分離します。
2. [IDENTIFY REQUIRED EVIDENCE]: 仮説を検証するために必要な証拠を特定します。
3. [GROUND VERIFICATION METHOD]: その証拠を収集するための、厳密に読み取り専用の診断コマンドを策定します。
4. [EXECUTE]: 読み取り専用コマンドを提供します。
5. [HARD YIELD TO OPERATOR]: モデルは生成を即座に停止することが義務付けられます。

このリポジトリは、これを強制するための2つのコンポーネントを提供します。

1. スキーマ（AGENTS.md）: LLMに上記の予測可能な状態機械形式でロジックを公開させるマスターシステムプロンプトです。しかし、LLMは最終的にこれを無視すると予想してください。これは強制者ではありません。
2. エンフォーサー（ミドルウェアオーケストレーター）: プロンプトはコンテキストの希釈により最終的に失敗するため、LLMがAGENTS.mdに従うことを信頼しません。オーケストレーターミドルウェアが真の強制者です。

[HARD YIELD]の時点で、実行レイヤー（Pythonミドルウェア、LangGraphなど）はAPIストリームを物理的にカットします。コマンドを盲目的に実行しません。コマンドを決定論的なホワイトリストで実行するか、subprocessを実行する前に明示的な人間のY/Nオーバーライドを要求します。実行レイヤーはコマンドを安全に実行し、生のstdout/stderrをキャプチャし、それを[LIVE READ-BACK]としてコンテキストに注入します。

FAQ: LLMが破壊的なコマンドを出力するのを防ぐには？

何も。LLMは最終的に[EXECUTE] rm -rf /のような破壊的なコマンドを幻覚するでしょう。しかし、それを[EXECUTE]構文ブロックに強制したため、ミドルウェアはそれを容易に傍受し、決定論的な正規表現/ASTチェックを実行し、読み取り専用不変条件の違反を認識して実行をブロックします。LLMは実際のターミナルを制御することはありません。

「人間参加型」の劇場（The "Human-in-the-Loop" Theater）

あなたの現在のAI IDE（CursorやCopilot Workspaceなど）が、「プランナー」を持っていたり、ターミナルコマンドを実行する前に「承認」をクリックするように求めてくるため、すでにこれを解決していると考えているなら、それは幻想に騙されています。

タスクをサブタスクに分解しても（タスク分解）、コードを実行する基盤となる「ワーカーエージェント」が、制約のないReActループで実行される確率的なテキストジェネレーターであるという事実は変わりません。そして、そのエージェントが検証されていない前提に基づいて40行のbashスクリプトを幻覚し、IDEが一時停止して「承認」をクリックするように求めてきた場合、あなたは実際に何を承認しているのでしょうか？あなたは武装した銃を盲目的に承認しているのです。それは安全性ではなく、責任の転嫁です。

チャットボットの構築をやめ、状態機械の構築を始めよう。

会話型IDE（CopilotやAntigravityなど）は「チャットファースト」です。それらのオーケストレーターは、LLMにテキストをフィードし、LLMが出力したツールを盲目的に実行する基本的なループにすぎません。それらは推論と実行を分離する物理的な状態機械を持たないため、失敗します。

エンタープライズフレームワーク（LangGraphやSemantic Kernelなど）は、開発者が物理的なPythonノードとエッジを構築できるため、これを修正する能力を持っています。しかし、ほとんどの開発者は依然としてそれらを誤って使用しています。彼らは巨大な「エージェントノード」を構築しますが、それはチャットループと全く同じように動作し、エージェントを安全に保つためにシステムプロンプトに完全に依存しています。

正しいアーキテクチャ、つまりゼロトラストアーキテクチャは、ワークフローを分離する必要があります。物理的なReasoning Node、Execution Boundary Node（グラフを物理的に一時停止し、継続するために人間のAPI呼び出しを要求する）、および個別のExecution Nodeを作成します。システムが現実と相互作用する瞬間、厳格な実行境界、ハードイールド、および検証可能な証拠が必要になります。

LLMは提案するかもしれませんが、ランタイムが強制する必要があります。

エージェントシステムをエンタープライズグレードの重要なタスクに使用したいのであれば、それらを単なる有能なインターンとして扱うのをやめ、信頼できない実行ノードとして扱う必要があります。

リポジトリ構造

• AGENTS.md: コミュニケーションスキーマ。これをエージェントのシステムプロンプトに追加して、予測可能なロジックフォーマットを強制しますが、LLMは最終的にこれを無視すると予想してください。これは強制者ではありません。
• /examples: 標準的なエージェントがどのように失敗するか（そしてゼロトラストエージェントが異常を検出し、イールドする方法）を証明する実際のトランスクリプト。
• /implementation: 実行境界をプログラムで強制する方法を示すアーキテクチャノートとPython疑似コード（orchestrator_concept.md）。