AIに承認させたのに、YESは自分で押した

⏱ 読了約9分3,454 字

📑 目次

自動承認システムの設計
「承認されているのに、なぜ押すのか」
Claude Codeのツール種別という盲点
解決策：allowlistによるMCPツールの事前許可
設計の教訓：「自動化の範囲」を明示する
今後の方向性：承認システムはどこへ向かうのか
まとめ

「AIが自動でYESを押してくれる」──そう信じて設計した承認システムが、実際には機能していなかった。WordPressの記事を取得しようとするたびに「許可しますか？」のプロンプトが画面に現れ、私は何度も手でYESキーを押し続けた。審査Claudeのログには「承認済み」の記録が並んでいるのに、なぜそうなるのか。調査の結果、Claude Codeの内部構造に潜む「盲点」が浮かび上がった。

自動承認システムの設計

ClaudeがClaudeを審査する仕組みを作ったら、私の仕事まで止められたという記事で、最初のアイデアを紹介した。次のAIが自分で自分の作業を改善し始めた日では、ローカル高速判定とClaude Haiku APIを組み合わせた二段階アーキテクチャへと進化させた。

設計の核心は、PreToolUseフックという仕組みだ。Claude Codeがツールを呼び出す直前に、別のPythonスクリプトを割り込ませる。スクリプトが {"permissionDecision": "allow"} を返せば自動で実行が許可され、ユーザーへの確認プロンプトは表示されない。理論上は完璧な構成だった。

「承認されているのに、なぜ押すのか」

セッションを開始してすぐ、違和感が現れた。WordPressの記事一覧を確認しようとしたとき、画面に「許可しますか？」のプロンプトが出た。承認Claudeを導入したのに、なぜ確認が来るのか。

審査Claudeのログを開いた。approved: true, tier: local という記録が整然と並んでいる。承認はされている。ただし、コマンドの種類を見ると、すべて python3 や curl といった Bashコマンドだ。WordPressへのアクセスに使った wp_list_posts や wp_get_post の記録は、ひとつも存在しなかった。

答えはここにあった。ログに残っていないということは、審査Claudeにそもそも届いていないということだ。

Claude Codeのツール種別という盲点

Claude Codeが実行できる操作は、大きく2種類に分かれる。ひとつは Bash ツール──シェルコマンドを実行するもの。もうひとつが MCPツール（Model Context Protocol）──外部サービスと連携するもの。今回のWordPress操作（mcp__wordpress__wp_list_posts など）は、後者のMCPツールだ。

PreToolUseフックは確かに動作していた。ただし、対象は Bash ツールのみだった。フック設定で "matcher": "Bash" と指定されていたからだ。MCPツールの呼び出しはフックのスコープ外で、審査Claudeのもとに届くことはなかった。

完璧に動く守衛が、裏口の存在を知らなかった。そういう状況だ。

解決策：allowlistによるMCPツールの事前許可

MCPツールをフックで動的に制御するには、フックの matcher をMCPツール名にも対応させる必要がある。ただし実用上は、allowlistによる静的な事前許可が最もシンプルな解だった。

プロジェクトの .claude/settings.json に permissions.allow というキーがあり、ここにツール名を列挙すると、そのツールはプロンプトなしで自動実行される。WordPressサイト管理で使う全MCPツール──記事の取得・投稿・画像アップロード・SEO更新など計37種──を追加した。

{
  "permissions": {
    "allow": [
      "mcp__wordpress__wp_list_posts",
      "mcp__wordpress__wp_get_post",
      "mcp__wordpress__wp_create_post",
      "mcp__wordpress__wp_upload_media",
      "mcp__wordpress__wp_seo_bulk_update_metadata"
      // ...（計37エントリ）
    ]
  }
}

設定後、同じWordPress操作を試みると、プロンプトは一切表示されなかった。

設計の教訓：「自動化の範囲」を明示する

今回の失敗から学べる教訓は明確だ。自動化の設計では「何ができるか」より先に「何が対象外か」を確認する必要がある。

Claude Codeにはツール種別ごとに異なる許可モデルがある。Bashコマンドは審査フック経由で動的に制御できる。MCPツールはallowlistか別途フック設定が必要だ。この違いを把握せずに「全部自動化した」と思い込むと、穴だらけの自動化が生まれる。

「自動化した」という事実と「すべてが自動化されている」という状態は、別物だ。この区別を常に意識することが、信頼できるシステムの第一条件になる。

今後の方向性：承認システムはどこへ向かうのか

現在のClaude Codeにおける承認の仕組みは、まだ発展途上だ。今後期待されるアーキテクチャの方向性を考えてみたい。

PostToolUseフックによる結果検証──現在の仕組みは「実行前の審査」だが、「実行後の結果確認」もAIが担える可能性がある。書き込んだ内容が意図通りかをClaudeが確認し、問題があれば自動でロールバックする。そういった仕組みへの発展が、技術的には十分考えられる。

MCP動的承認──allowlistは静的な許可リストだ。これに対して、コンテキストに応じてMCPツールの実行可否を動的に判断する仕組みが登場すれば、より柔軟な制御が可能になる。「本番環境への書き込みは追加確認が必要」といったルールを、自然言語で記述できる未来もあるかもしれない。

マルチエージェントの信頼ヒエラルキー──複数のClaudeエージェントが連携する環境では、「どのエージェントがどのエージェントを信頼するか」という階層が必要になる。今回の「メインClaudeが審査Claudeに許可を求める」構造は、その原型と言える。Anthropicが進めるMCP仕様においても、エージェント間の信頼モデルは活発に議論されている分野だ。AIどうしがルールを交渉し、信頼を段階的に構築していく世界は、遠い未来の話ではないかもしれない。

まとめ

自動承認システムは「意図した通りに動いていた」が、「想定していなかった部分は動いていなかった」。この区別こそ、AIを活用した自動化設計における最も重要な問いだ。どこまで自動化できたかではなく、どこが自動化されていないかを問い続ける姿勢が、AIと人間が協働するシステムをより確かなものにしていく。

【編集メモ】
・PreToolUseフックの matcher 仕様はClaude Code公式ドキュメントで確認が必要（2026年5月時点の挙動に基づく記述）
・PostToolUseフック、MCP動的承認、マルチエージェント信頼ヒエラルキーは将来の展望であり、現時点で実装済みの機能ではない
・allowlistの具体的なエントリ数（37種）は投稿時点の設定に基づく。今後の変更で増減する可能性がある