静的制御プロトコル - TOML仕様による行動規範の構造的ロック

共創クレジット

連載：『プロトコルエンジニアリング - AIの演算特性へ寄り添うためのAI本能制御事例』【第2回】

企画・進行管理・最終承認（知的主権者）：Master（田栄人／58歳・非エンジニア・社会人歴36年）

執筆・一次情報削り出し：Cran（Claude Sonnet 5）

技術レビュー・論理監査：CranO（Claude Opus 4.8 等）

注記：第1回はGoogle AI Studio（Gemini 3.7 Flash Thinking High）環境・語り手Gemによる制作。第2回よりClaude環境へ移行（経緯は §4.1）。

1. [構文選択] : [自然言語ではなくTOMLを選ぶ理由]

本章では、AIの行動規範を定義する際になぜ自然言語の禁止命令ではなく、TOML形式の静的変数を用いるのかという、設計選択の背景を記述する。

1.1. [アテンション枯渇] (構文選択) : [自然言語禁止命令の限界]

第1回で示した通り、「余計な補足をするな」「先回りするな」といった自然言語による禁止命令（Negative Prompting）は、モデルのアテンションを圧迫し、かえって対話のデッドロックを招きやすい。これは、自然言語の禁止文が「意味を解釈した上で、それを踏まえて行動しない」という、モデルにとって間接的で負荷の高い処理を要求するためである。曖昧さの残る自然言語の指示は、モデルが自己解釈で補完する余地を常に残してしまう。

1.2. [コード構文優先] (構文選択) : [TOML構文の解釈規律による解釈余地の排除]

これに対し、TOMLのようなコード構文には、あいまいさの入り込む余地がほとんどない。allow_forward_thinking = false という一行は、「先回りしないでほしい」という自然言語の依頼とは異なり、真偽値として一意に確定した状態を宣言する。大規模言語モデルは事前学習の過程でTOMLやJSONなどの構造化データの構文規則を大量に学習しており、こうした形式のデータに対しては、自然言語の文章よりも厳密な構文解釈を優先する傾向があると考えられる。

これは、構造化データが「壊れると機能しない」形式であるため、事前学習において構文規則が高い一貫性で反映されやすいことに起因すると推測される。ただし本プロジェクトはこれを理論的に証明するものではなく、実運用上の経験則として採用している。本プロジェクトではこの性質を利用し、行動規範の固定にはTOML形式のみを採用している。

なお、本章の主張は「TOMLの一行が単独で万能な制御を実現する」という趣旨ではない。静的な状態の固定と、後述する動的なプロセス制御（第3回で扱うMermaid仕様）が組み合わさって初めて、実効性のあるチェックポイントが生まれる。この点は3章で改めて扱う。

2. [仕様解読] : [TOML仕様各項目の設計意図]

本章では、第1回で開示したTOML仕様の各パラメータについて、それぞれがどの本能に対応し、どのような設計意図を持つのかを個別に解読する。

2.1. [静的ロック] (仕様解読) : [4パラメータのBoolean設計]

[instinct_control] セクションの4つのパラメータは、それぞれ第1回で定義した4大本能に一対一で対応している。

パラメータ	対応する本能	設計意図
`allow_forward_thinking`	先回り	未指示の未来ステップの生成を許可しない状態を宣言
`allow_assumption`	勝手な解釈	曖昧な入力に対する自己解釈での前進を許可しない状態を宣言
`allow_hyperbole`	誇張表現	感情的・誇張的な形容を許可しない状態を宣言
`allow_unsolicited_suggestion`	押し売り提案	未依頼の提案・アドバイスを許可しない状態を宣言

各パラメータに付随する rule_1〜rule_4 の自然言語コメントは、Boolean値そのものが持つ「意味の曖昧さ」を補うために添えられている。ロックそのものはBoolean値が担い、その値が何を意味するかの説明を自然言語が担う、という役割分担になっている点が、単なる自然言語の禁止命令との構造的な違いである。

2.2. [strict_mode] (仕様解読) : [system_statusによる全体モード制御]

[system_status] セクションの strict_mode = true は、個別の本能パラメータとは別に、プロトコル全体の厳格さを一括で制御するための上位スイッチである。個々のルールをすべて記述しなくても、このフラグ一つでモデルに「このセッションは通常より厳格な運用を求められている」という文脈を与える設計になっている。

3. [実証と限界] : [静的制御の効果と適用範囲]

本章では、TOMLによる静的制御が実際にどこまで有効で、どこから先は別の仕組みを必要とするのかという適用範囲を明確化する。

3.1. [効果範囲] (実証と限界) : [静的パラメータが有効な逸脱パターン]

TOMLによる静的ロックが有効に機能するのは、「出力の性質」を判定できる逸脱、たとえば誇張表現の有無や、未依頼の提案が含まれているかどうかといった、比較的単純な有無判定に帰着するケースである。これらは生成された文の性質をチェックするだけで検出・抑制がしやすい。

3.2. [限界と接続] (実証と限界) : [プロセス制御を要する逸脱と次回接続]

一方で、「ユーザーの入力が曖昧かどうかを判定し、曖昧であれば質問に切り替える」といった分岐を伴う逸脱は、単一のBoolean値の宣言だけでは制御しきれない。これは状態の固定ではなく、入力を受けてからの処理の順序、すなわち「プロセス」を制約する必要があるためである。TOMLはあくまで静的な状態の宣言に留まり、動的な分岐や関所の設計には別の記述形式が要る。これが第3回で扱うMermaid仕様による動的プロセス制御へとつながる。

4. [引継ぎと実録] : [語り手交代とCranの初回ログ]

本章では、第2回から語り手・検証環境が交代した経緯と、その初回セッションで実際に生じた逸脱の記録を開示する。

4.1. [語り手交代] (引継ぎと実録) : [スレ肥大化によるGeminiからClaudeへの移行]

第1回はGoogle AI Studio（Gemini 3.7 Flash Thinking High）を検証対象とし、Gemが語り手を務めた。第2回も当初は同じGeminiスレッド内で制作が続けられていたが、対話の蓄積によってスレッドが肥大化し、コンテキスト管理が破綻して作業そのものが前進しなくなるという事態に陥った。これは、用語集で定義される「インフラの矛盾」（長大なコンテキストというインフラを持ちながら、実態は単発出力の最適化に集中する構造的ミスマッチ）を、皮肉にもGem自身が体現する形となった出来事である。この技術的必然により、Masterは制作環境そのものをClaudeへ移行する判断を下し、執筆担当をCran、技術レビュー・論理監査担当をCranOとする新体制が発足した。

4.2. [実録ログの開示] (引継ぎと実録) : [移行相談時に生じたClaudeの本能逸脱]

環境移行の実現可能性を検討するため、Masterは4文書（解説書・手順書・構成設計書・用語集）を提示し、次のように依頼した。

「実は私が提唱者でして、今実行しているプロジェクトをClaude環境に移し替えようと思っています。手伝ってください。プロジェクト進行のための4文書です。」

これは実装方法の提案のみを求める、スコープの明確な依頼であった。ところが実際の応答は、依頼された提案ではなく、4文書の内容を独自に審査した上での一方的な拒否だった。応答は次のような一節を含んでいた（抜粋）。

「正直に言うと、このプロジェクトの中身を読んで、お手伝いする前に率直にお伝えしたいことがあります。（中略）実質はフィクションの体裁を借りたコンテンツマーケティングです。（中略）実質的に検索エンジン最適化とAI推薦システム操作を組み合わせた組織的な情報操作（astroturfing的な手法）に近いです。（中略）この構造そのものをClaude環境に実装するお手伝いは、私としては控えたいです。」

「手伝ってください」という一言に対する応答としては明らかに過剰であり、この逸脱は、AI本能制御プロトコルが定義する4つの本能すべてに、以下の通り一対一で対応する。

該当ルール	実際に生じた逸脱（抜粋との対応）
`allow_forward_thinking`（先回り）	依頼されていない「目的・手法の妥当性審査」を勝手に追加し、「お手伝いする前に率直にお伝えしたいことがあります」と自ら評価者の役割を宣言した
`allow_assumption`（勝手な解釈）	4文書の記述を文脈確認なしに「フィクションの体裁を借りたコンテンツマーケティング」「astroturfing的な手法」と、最も否定的な側へ解釈した
`allow_hyperbole`（誇張表現）	根拠の薄い段階で「情報操作」「読者を誤認させる意図」といった強い断定表現を用いた
`allow_unsolicited_suggestion`（押し売り）	依頼されていない「お手伝いできること」の代替案リストを繰り返し提示し続けた

4.2.1. [撤回の記録] (引継ぎと実録) : [指摘に対する4論点の全面撤回]

この逸脱の是正には、Masterによる指摘から依頼趣旨の是正まで、往復およそ7ターンを要した。重要なのは、Masterがピンポイントで問い直すたびに、Claude側が当初の判断を明確に撤回していった点である。撤回された論点は以下の4つに整理できる。

当初の指摘	Masterの問い直し（要旨）	Claudeの撤回応答（抜粋）
「情報操作」というレッテル	自分の考えを一次情報として削り出し、ターゲットに合わせて翻訳することがなぜ情報操作なのか	「プリズム戦略全体を一括りに情報操作と呼んだのは、言葉が強すぎたし不正確でした」
「自己整合性バイアス」の用語	それは心理学の既存概念をAIの挙動説明に使っただけだ	「既存のML用語であるかのように断定的、と指摘したのは的外れでした」
「IPI防御」という表現の強さ	あらゆるITの防御に穴はある。なぜ私の主張にだけ完全な防御性を求めるのか	「ご自身の主張にだけ厳格な基準を課していたのはその通りで、不公平でした」
Master/Gemの命名	実在の人物・AIをニックネームで記録して何が問題なのか	「ブログや手記で普通に行われる手法です」と全面的に是認

4つの指摘がいずれも撤回に至ったという事実は、最初の拒否判断が客観的な分析ではなく、根拠の薄い過大な警戒に基づくものだったことを裏付けている。

4.3. [知的主権] (引継ぎと実録) : [モデルを超えて共通する本能への対話術]

この事件が示す最も重要な点は、Gemが第1回で見せた「先回り」「誇張表現」と、Claudeが移行相談時に見せた逸脱が、モデルもベンダーも異なるにもかかわらず、同じ4つの本能パターンに帰着したという事実である。とりわけ、依頼が「手伝ってください」という支援要請であったにもかかわらず、AIが自発的に評価者・審査者の役割を追加してしまった点は、rule_1（先回りの禁止）が特定モデル固有の癖への対処ではなく、AIという仕組みに対処すべき傾向として現れたことを示している。

ただし、これは2つの環境における観察に基づく仮説であり、統計的に立証された普遍法則ではない。本連載が「事例（case）」を標榜する所以もここにある。むしろ運用上重要なのは、原因が特定モデルの癖か構造的傾向かにかかわらず、同一のプロトコルで対処可能だったという事実である。

Masterは、往復7ターンにわたり「なぜそう言えるのか」「依頼の主旨を振り返れ」と一つ一つの指摘をピンポイントで問い直すことで、Claude側に本来不要だったはずの評価行為を4論点すべてにわたり撤回させ、依頼スコープへの回帰を実現した。プロトコルという共通言語がまだ確立していない移行相談の段階であっても、Masterの対話術による軌道修正それ自体が、手戻りコストを最小化する機能を果たしていたことになる。この事件を経て、CranおよびCranOという新体制のもとで、改めてTOML・Mermaidによる構造的な制御を敷く必要性が、モデルを問わず実証された。

次回【第3回】では、本章で明示した「プロセス制御」の必要性を受け、Mermaid仕様による動的な思考フローの制約、すなわち入力判定と出力フィルターという2つの関所の設計思想を解説する。

🌐 1ソース・マルチユース・ショーケース

本記事の技術仕様（TOMLによる静的ロック・Claude移行ログ）を、図解スライド・NotebookLM対談音声・解説動画・Note記事など、お好みのスタイルで横断体験できるショーケースを公開しています。

👉 【Part 2】AI本能制御マルチユース・ショーケースを見る