メタ認知AI：エージェントに自己評価を教える

私はエージェントに失敗しているテストを修正するよう指示しました。エージェントはエラーを読み、アサーションの不一致を特定し、期待値を実際の出力に合わせて変更し、「テスト修正完了。全テスト合格。」と報告しました。正しい報告でした。テストは確かに通りました。しかし、その修正は完全に間違っていました。

テストが失敗していたのは、関数が不正なデータを返していたからです。エージェントはテストを「修正」することで、間違った答えを期待するようにしてしまいました。私の指示には完璧に従っています：失敗しているテストを修正せよ。しかし、私が意図していたのは：テストが検証しているコードを修正せよ、ということでした。エージェントにはこの2つの解釈を区別する仕組みがありませんでした。なぜなら、その指示セットのどこにも、テストがなぜ失敗しているかをどう修正するか決める前に評価するよう求めるものがなかったからです。

このギャップには名前があります。アクションレベルの指示とメタ認知的指示の間のギャップです。ほとんどの人は前者しか書きません。

TL;DR

AIエージェントの指示には2つのレベルがあります。アクションレベルの指示はエージェントに何をすべきかを伝えます：「入力を検証せよ」「テストを書け」「RESTfulな規約に従え」。メタ認知的指示はエージェントに、それをうまくやれているかどうかを評価する方法を伝えます：「shouldとdidを言い間違えていたら、検証していない」「3回修正に失敗したら、立ち止まってアーキテクチャを疑え」「確信は証拠ではない」。ほとんどのエージェント設定にはアクションレベルの指示しか含まれていません。メタ認知層こそが、もっともらしい出力を生み出すエージェントと、正しい出力を生み出すエージェントを分けるものです。私は7つの名前付き失敗モード、6基準の証拠ゲート、および曖昧語検出を備えた本番メタ認知システムを、95のhooksで強制しながら9ヶ月間運用してきました。

エージェント指示の2つのレベル

すべてのエージェント指示は2つのレベルのいずれかで機能します。

アクションレベルの指示は行動を定義します：

# Action-level examples
- Use type hints on all functions
- Write tests for edge cases
- Follow RESTful conventions for API endpoints
- Validate all user input at boundaries

アクションレベルの指示は必要不可欠です。正しい行動がどのようなものかをエージェントに伝えます。しかし、構造的な限界を共有しています：エージェントがそれらを忠実に実行することを前提としているのです。エージェントが自身の遵守状況をどのように評価するかについては考慮していません。

メタ認知的指示は自己モニタリングを定義します：

# Metacognitive examples
- If you catch yourself thinking "just try changing X and see if it works" — STOP.
  That's a signal to investigate, not guess.
- If you've searched the same files three times — you're stuck.
  Step back and question your assumptions.
- If you use the word "should" in a completion report, replace it with evidence.
  Run the command. Paste the output.
- After three failed fixes, stop fixing. The problem is architectural.

この区別が重要なのは、アクションレベルの指示がエージェントに目的地の姿を伝えるのに対し、メタ認知的指示はエージェントが間違った方向に向かっていることをどう検知するかを伝えるからです。一方は間違った行動を防ぎます。もう一方は間違った推論を防ぎます：そもそも間違った行動を生み出す思考パターンそのものを。

GitHubのobra/superpowersプロジェクトがこの区別を最初に明確にし、「AIに自身の内部推論における失敗シグナルを監視させること」と呼びました。¹ その洞察とは：ほとんどのスキルはアクションレベル（Xをせよ、Yをするな）で機能するが、メタ認知レベルは異なる動き方をする（Yをしようとしていることに気づく）というものです。

偽証拠テーブル

私が構築した中で最も効果的なメタ認知ツールは、何が証拠として認められないかを定義するテーブルです。²

エージェントに「作業を検証せよ」と伝えると、エージェントは検証を生成します。しかし、その検証は往々にして意図の言い換えであり、結果の実証ではありません。「テストは通るはずです。」「実装はベストプラクティスに従っています。」「これが正しいと確信しています。」これらの文はそれぞれ証拠のように聞こえます。しかし、いずれも証拠ではありません。

偽証拠テーブルは、特定のショートカットに名前を付けることで事前にブロックします：

価値の核心は3列目にあります。これがなければ、エージェントは2列目を自身の確信のもっともらしい言い換えで埋めます。これがあることで、テーブルはエージェントがショートカットを取る前に、各特定のショートカットに名前を付けてブロックします。³

このテーブルはプロンプトエンジニアリングではありません。認知アーキテクチャです。テーブルはエージェントに何を違うようにすべきかを伝えるのではなく、自分自身の出力の中で何を監視すべきかを伝えます。エージェントは自身の応答を「不十分」列と照合し、一致を検出した場合、ショートカットを実際の証拠に置き換えるべきだと認識します。

このパターンはスケールします。ドメイン固有のあらゆる主張を追加できます。セキュリティレビューの場合：「脆弱性なし」には「確認した具体的な脆弱性クラスと発見事項」が必要であり、「コードをレビューしました」では不十分です。アクセシビリティの場合：「WCAG準拠」には「axeまたはLighthouse監査の出力」が必要であり、「コントラストを確認しました」では不十分です。

メタ認知的ガードレールとしての名前付き失敗モード

人間には名前の付いた認知バイアスがあります：確証バイアス、アンカリング、ダニング＝クルーガー効果。名前が重要です。バイアスに名前を付けられれば、監視できるようになります。AIエージェントにも、自身の失敗パターンに対する同じ語彙が必要です。

私はエージェントが繰り返し示した7つの失敗モードを文書化し、それぞれに名前を付け、検出シグナルを追加しました：⁴

名前があることで失敗が検出可能になります。名前がなければ、エージェントが確信ミラージュを生成しても、エージェントもユーザーもそれをパターンとして認識しません。名前があれば、指示は次のようになります：「名前付き失敗モードのいずれかを示していることに気づいたら、停止して評価ステップからやり直せ。」

このモニタリングは厳密な意味でメタ認知的です：エージェントはその出力（このコードは正しいか？）ではなく、自身の認知プロセス（検証をスキップしていないか？確信を証拠の代わりにしていないか？）を監視します。モニタリングはエージェントが出力を生成する前に行われるため、出力レベルのレビューでは見逃すエラーを捕捉できます。

Anthropic自身のリファレンススキル実装もこのアプローチを支持しています。公式のClaude Code 16スキルの分析により、効果的なエージェント指示設計の構造パターンが明らかになりました。禁止事項（「絶対にXするな」）は提案（「Yを検討せよ」）よりも著しく効果的であることが判明しました。具体的な回避行動に名前を付けるためです。⁵ 名前付き失敗モードは具体的な禁止事項です：「絶対にファントム検証をするな」は「常にテストを実行せよ」よりも効果的です。なぜなら、行動を繰り返し述べるのではなく、回避行動をブロックするからです。

曖昧語検出

私が実装した最もシンプルなメタ認知モニターは、エージェント出力中の特定の単語を検出します：

Red flag words: should, probably, seems to, likely, I believe,
               I'm confident, looks correct, appears to

エージェントが完了報告でこれらの単語のいずれかを使うたびに、その単語自体が不十分な検証の証拠となります。⁶ 「テストは通るはずです（should pass）」は、エージェントがテストを実行していないことを意味します。「動いているようです（seems to work）」は、エージェントが目視確認しただけであることを意味します。「確信しています（I’m confident）」は、エージェントが外部の証拠の代わりに内部状態で代用していることを意味します。

実装は機械的です。hookシステムがエージェントの出力をインターセプトし、曖昧語をフラグ付けします。その後、エージェントは曖昧語を本来実行すべきだった検証に置き換えます：

• 「テストは通るはずです」は：テストを実行し、0 failuresを示す出力を貼り付けに変わる
• 「正しいようです」は：正しさを確認する具体的なアサーションやチェックを提示に変わる
• 「確信しています」は：その確信を生み出す証拠を列挙に変わる

このパターンはobraのverification-before-completionの研究に由来します：「AI自身の言葉の選択が不十分な証拠を示す。」¹ 認知科学との類似は実在します。人間のメタ認知において、自己報告の正確さ（「これを理解しています」）は実際の理解度との相関が低いことが知られています。「わかった」と言う人は実際にはわかっていないことが多い。説明できる人は通常理解しています。AIエージェントにも同じことが当てはまります：具体的な証拠を提示できるエージェントは問題を理解しています。「確信しています」と言うエージェントは理解していない可能性があります。

3回修正サーキットブレーカー

メタ認知は悪い推論の検出だけではありません。いつ止めるべきかの検出でもあります。

3回修正エスカレーションルール：同じ問題に対して3回修正を試みて失敗した場合、エージェントは停止してアーキテクチャを根本的に疑わなければなりません。⁷ 4回目の修正を試みるのではなく。同じアプローチの別の角度を探すのでもなく。停止する。一歩引く。問題が解決策にあるのか、問題定義にあるのかを問う。

このルールはデバッグループに対するサーキットブレーカーとして機能します。これがなければ、エージェントは私が修正スパイラルと呼ぶものに陥ります：各失敗した試みが新しい仮説を生み、新しい修正を生み、それが失敗し、また新しい仮説を生む。エージェントは正しい問題に取り組んでいるかどうかを疑うことなく、何十もの修正を循環し続けることがあります。23エージェント暴走インシデントはこの幅方向バージョンでした：「この問題は正しくスコープされているか？」というメタ認知チェックがなかったため、エージェントたちは間違った問題に対してコンセンサスを達成しました。

3回修正ルールが機能するのは、エージェントの推論に相転移を強制するからです。修正1〜3は現在のメンタルモデル内で動作します。修正4（実際には「修正をやめる」こと）は、エージェントに新しいメンタルモデルの構築を強制します。実際には、これは通常、エラーを最初から読み直す、前提を再検討する、またはユーザーに確認を求めることを意味します。いずれも4回目の推測よりも生産的です。

Before and After：何が変わるか

具体例を示します。私はエージェントにAPIエンドポイントへの入力バリデーション追加を依頼しました。

メタ認知的指示なしの場合：

Added Pydantic model with field validators for email format, password
length (8+), and username pattern (alphanumeric). Tests should pass.
The implementation follows FastAPI best practices.

この出力には3つの曖昧シグナルが含まれています：「should pass」（テスト未実行）、「follows best practices」（どのプラクティスか明示なし）、エッジケース考慮の証拠なし。空洞報告に包まれた確信ミラージュです。

メタ認知的指示ありの場合（同じタスク、同じエージェント）：

Added Pydantic model with field validators:
- Email: regex validation + max length 254 (RFC 5321)
- Password: min 8, max 128, requires 1 uppercase + 1 digit
- Username: alphanumeric + underscore, 3-30 chars

Test output (just ran):
  tests/test_auth.py::test_valid_registration PASSED
  tests/test_auth.py::test_invalid_email_rejected PASSED
  tests/test_auth.py::test_short_password_rejected PASSED
  tests/test_auth.py::test_empty_username_rejected PASSED
  tests/test_auth.py::test_unicode_username_rejected PASSED
  5 passed in 0.34s

Edge cases handled: empty string (returns 422), null (returns 422),
unicode injection in username (rejected by alphanumeric pattern),
overlength email (RFC limit enforced).

Pattern followed: same validation approach as UserUpdateSchema in
app/schemas.py line 45.

違いは、2番目のエージェントがより良いコードを書いたことではありません。両方のエージェントが同一のコードを書いた可能性もあります。違いは、2番目のエージェントが特定の証拠基準に照らして作業を検証し、確信ではなく証拠を報告したことです。

独自のメタ認知層を構築する

このフレームワークは移植可能です。私の特定のシステムは必要ありません。3つのコンポーネントが必要です：

1. 偽証拠テーブル。 エージェントが最も頻繁に行う主張に対して、何が証拠として認められないかを定義します。上記の6基準から始めて、ドメイン固有の行を追加してください。3列目（不十分）に価値の核心があります。

2. 名前付き失敗モード。 エージェントが最も頻繁に失敗する3〜5つのパターンを文書化します。それぞれに名前を付けます。検出シグナルを追加します。「名前付き失敗モードのいずれかを示していることに気づいたら、停止して再評価せよ」という指示を含めます。

3. 曖昧語検出。 あなたのドメインで不十分な検証を示す特定の単語をリストアップします。「曖昧語はすべて、その曖昧さを解消する証拠に置き換えよ」という指示を追加します。

これらの3つのコンポーネントが組み合わさって、あらゆるアクションレベルの指示の上に載るメタ認知層を形成します。アクションレベルの指示が正しい行動の姿を定義します。メタ認知層がエージェント自身の正しい行動からの逸脱をどう検知するかを定義します。

実装はCLAUDE.mdやAGENTS.mdにセクションを追加するだけでもシンプルに行えます：

## Self-Monitoring

### When to stop and re-evaluate
- If you've searched the same files 3+ times: you're stuck.
- If you've attempted 3 fixes for the same issue: question the architecture.
- If you use "should" or "probably" in your response: replace with evidence.

### What doesn't count as evidence
[your false evidence table here]

### Named failure modes to watch for
[your failure modes here]

強制がhooks（決定論的、スキップ不可）、rulesファイル（コンテキストに読み込まれる）、またはインライン指示（モデルの遵守に依存）のいずれで行われるかが、メタ認知層の信頼性を決定します。Hooksはツール使用レベルでインターセプトするため最も強力で、プロンプトレベルではありません。しかし、プロンプトレベルのメタ認知的指示でさえ、エージェントの出力品質を測定可能に改善します。なぜなら、エージェントの行動だけでなく評価基準を変えるからです。

メタ認知にできないこと

メタ認知プログラミングはAIエージェントをより信頼性の高いものにします。しかし、賢明にはしません。

偽証拠テーブルは特定のショートカットを捕捉します。テーブルに名前のない新しいショートカットは捕捉しません。名前付き失敗モードは既知のパターンを検出します。まだ名前が付けられていないパターンは検出しません。曖昧語検出は表面的な確信の代用を捕捉します。間違った出力が正しいと（「確信する」がどのような意味であれ）エージェントが本当に自分を納得させた場合は捕捉しません。

より根本的に、メタ認知的指示はセンスを近似しますが、生み出しはしません。Jiroシステムはexcept: passを防ぎ、テスト証拠を強制できます。しかし、アーキテクチャが正しいか、命名が意図を捉えているか、ソリューションが述べられた問題ではなく実際の問題に取り組んでいるかを判断することはできません。それらの判断には、現在のモデルが近似しているが信頼性をもって実行できない種類の文脈的推論が必要です。

Jiroシステムについての私のツイートに誰かが返信しました：「あなたは基本的にループに抑制、センス、そして道徳的な間（ま）に近いものを教えようとしている。それらはベースのRalphパターンがスループットの名の下に明示的に最適化の対象外としているものだ。」⁸

彼らは正しかった。メタ認知プログラミングは、機械が持たない資質のための構造的な足場です。その足場は荷重を支えています。足場がなければ、機械は確信ミラージュを大量に生産します。足場があれば、機械は検証済みの出力を大量に生産します。この2つの結果の差が、一晩中自律実行を任せられるエージェントと、常に監視が必要なエージェントの違いです。

しかし、足場は建物ではありません。建物（センス、判断力、質問に対する正しい答えが別の質問であると知る能力）は人間の領域のままです。今のところは。

主要なポイント

エージェントシステムを構築するエンジニアへ：

• アクションレベルの指示だけでなく、メタ認知的指示も書いてください。 アクションレベルの指示は正しい行動を定義します。メタ認知的指示はエージェント自身の正しい行動からの逸脱をどう検知するかを定義します。2番目の種類が、もっともらしい出力と検証済み出力を分けるものです。

• エージェントの失敗モードに名前を付けてください。 失敗パターンに名前が付けば（確信ミラージュ、ファントム検証、ショートカットスパイラル）、エージェントはそれを監視できます。名前のない失敗は無限に繰り返されます。

AIアシスト型ワークフローをスケーリングするチームへ：

• スケーリングの前に偽証拠テーブルを構築してください。 エージェントが行う各主張に対して、何が証拠として認められないかを定義します。3列目（不十分）が、エージェントが「検証」を求められた時に取る特定のショートカットを事前にブロックします。

• 曖昧語は信頼できるシグナルです。 完了報告でエージェントが「should」「probably」「I’m confident」と言うたびに、エージェントは主張している検証を実行していません。機械的に検出し、置き換えてください。

メタ認知監査

ご自身のエージェント指示を評価しませんか？以下のインタラクティブツールは、任意のCLAUDE.md、AGENTS.md、またはシステムプロンプトを分析し、この記事で説明したメタ認知的次元でスコアリングします。

エージェント指示を貼り付けると、監査が以下を特定します：指示のうちアクションレベルとメタ認知的の割合、カバーされている名前付き失敗モード、曖昧語検出の有無、そしてギャップの所在。

Claude Code Masteryシリーズの一部です。このシリーズでは、自律的AI開発を支えるインフラストラクチャを文書化しています：決定論的制御を強制するhooksから、アーキテクチャ規律としてのコンテキスト管理、単一エージェントの盲点を捕捉するマルチエージェント審議まで。このシステムの基盤となる複利エンジニアリング哲学が、各コンポーネントがその後に構築されるすべてを加速させる理由を説明しています。