1. 開発者の「承認疲れ」を解剖する

Claude Codeのような自律型AIエージェントを実務に投入すると、多くの人が最初に直面する壁があります。それは、過剰な確認プロンプトによる「承認疲れ（Approval Fatigue）」です。

AIが動こうとするたびに、画面には以下のようなプロンプトが表示されます。

Allow reading this file? [y/n]
Allow executing this command? [y/n]

使い始めのうちは安全性が担保されているように感じて安心するかもしれません。しかし、1日に何十回もAIと対話する中で、毎回この確認プロンプトを待って y を打ち込むのは、開発のテンポを著しく損ないます。無意識に y を連打するようになれば、実質的なチェック機能としても意味を成しません。

すべての操作に人間の許可を必要とする状態は、「自律的なエージェント」というより、ただの「手間の多いサジェスト機能」です。この煩わしさから解放されるために、AIに「自律的な試行錯誤」を許可したくなります。しかし、何の準備もせずにAIを「全自動」で放し飼いにするのは、目隠しをして猛獣の檻を開けるようなリスクを伴います。

2. 苦い経験からの学び：AIが「踏み越えた」瞬間

「いちいち確認するのが面倒だ。よし、全部AIに任せよう」

承認疲れに耐えかねた結果、厳密なルールを設けないままAIを「全自動（auto_mode）」で走らせ、境界線を引かずにAIを信頼しすぎたことで起きた事例を共有します。

意図しないコード公開（APIキー流出）

ローカル環境での複雑なバグ修正を、auto_mode で丸投げしていたときのことです。AIは数回のエラーを経てコードを修正し、以下のように出力しました。

「修正が完了しCommit,Pushしました！」

直後、自動で実行された git push。そこには、修正過程で一時的にハードコードされたテスト用のAPIキーが残っていました。リモートリポジトリに上がった瞬間、それは既成事実となります。

3. Slack連携における「対人リスク」の境界線

システムだけでなく、Slackなどのコミュニケーションツール（MCP）をAIに開放している場合も、制限なき「全自動」は大きなリスクとなります。

「読み取り」は全自動、「書き込み」は厳格な手動

過去の議論や仕様決定の経緯をAIに検索させるのは非常に強力ですが、メッセージの送信（post_message）まで全自動にするのはリスクが高すぎます。

• リスク：auto_mode中の不完全な進捗報告
  ある機能の調査を auto_mode で依頼した際、AIはユーザーの許可を得ることなく、関係者の個人DMへ「調査が終わりました。結果は以下の通りです」と、不完全な分析結果を送信してしまいました。自分の名前（アカウント）でAIが勝手に他人に連絡を取ってしまうのは、社内でのコミュニケーションのすれ違いや、ちょっとしたトラブルを生む原因になります。
• 対策：送信系メソッドの「手動承認制」
  検索や取得系のメソッドは allow に入れ、送信系（書き込み）だけはあえて deny に明記します。これにより、AIが投稿しようとした瞬間に必ず人間への「最終確認ボタン」が出るようになります。

4. 鉄壁の「多層防御（Defense in Depth）」アーキテクチャ

AIを安全にするためには、単一の壁に頼るのではなく、突破されるレイヤーが異なるPermissions・Hooks・Sandboxの3層を組み合わせた多層防御を構築することが公式のベストプラクティスです。

堅牢な3層構造の役割

• Layer 1: Permissions（ツール実行前・LLMレベル）
  Claudeが特定のツールを呼び出そうとした時点でブロックします。ただし、Bash サブプロセス経由の操作（例: cat .env）は検知できないという弱点があります。
• Layer 2: Hooks（ツール実行直前・カスタムロジック）
  preCommit 等のフックを用い、独自のカスタムロジック（シェルスクリプト等）で検査・ブロックします。
• Layer 3: Sandbox（OSレベル・最後の防壁）
  OSレベルでファイルシステムやネットワークを隔離します。全プロセスに適用されるため、プロンプトインジェクションを受けても最も確実な最終防壁として機能します。

役割分担マトリクス

それぞれの防壁が「何を防げて、何を防げないか」を明確に理解することが不可欠です。

【注意】運用上の落とし穴

• 「Hooks は Sandbox の代替になる」は誤り: 突破されるレイヤーが違うため、必ず併用してください。
• .env の読み取り防御の罠: Permissionsで Read(./.env) を拒否しても、Bashの cat .env は通ってしまいます。必ず Sandbox の filesystem.denyRead と併用してください。
• エスケープハッチの封鎖: エンタープライズ環境では、Sandboxを無効化されるのを防ぐため、"allowUnsandboxedCommands": false を設定し、システム上の抜け道を塞ます。

5. 考察：AIに「全自動」を許せる3つの境界線

システム上の許可を超えた先にある、人間とAIの「責任分界点」を定義します。

6. 実践：フルカバレッジ設定ガイドと settings.json

AIと共生するための「安全な環境」を構築する具体的ステップです。

• Sandboxの完全有効化: エスケープハッチを塞ぎ、作業範囲を限定する。
• 立ち入り禁止エリア of 定義: ~/.ssh, .env などを denyRead で物理的にロック。
• 確認不要コマンドの登録: ls, git status, npm test など副作用のないものを allow へ。
• ネットワークのホワイトリスト化: 業務に必要なドメイン以外への通信をOSレベルで遮断。
• Slack連携の「権限分離」: 読み取りは allow、書き込み（post_message）は deny に設定。

■ 権限判定の処理フロー

AIがアクションを実行する際、以下の優先順位で設定が参照されます。

1. Deny（禁止）チェック: 実行しようとする操作が deny リストにあるか確認します。一致する場合、その時点で処理を強制遮断します。
2. Allow（許可）チェック: deny に該当しない場合、allow リストにあるか確認します。一致する場合、そのまま実行します。
3. Ask（確認）: どちらのリストにもない未知の操作（未定義のコマンド等）の場合、ユーザーに実行して良いか確認プロンプトを表示します。
4. Hook（フック）実行: 実行が決定した後、特定の操作（コミット処理等）であれば、事前に定義された preCommit スクリプトを自動実行します。

…

記事の続きは下のURLをクリック！

https://rightcode.co.jp/blogs/55384

もっとワクワクしたいあなたへ

現在、ライトコードでは「WEBエンジニア」「モバイルエンジニア」「データエンジニア」「ゲームエンジニア」「デザイナー」「WEBディレクター」「営業」などを積極採用中です！

ライトコードは技術力に定評のある受託開発をメインにしているIT企業です。

有名WEBサービスやアプリの受託開発などの企画、開発案件が目白押しの状況です。

• もっと大きなことに挑戦したい！
• エンジニアとしてもっと成長したい！
• モダンな技術に触れたい！

現状に満足していない方は、まずは、エンジニアとしても第一線を走り続ける弊社代表と気軽にお話してみませんか？

ネット上では、ちょっとユルそうな会社に感じると思いますが（笑）、
実は技術力に定評があり、沢山の実績を残している会社ということをお伝えしたいと思っております。

• ライトコードの魅力を知っていただきたい！
• 社風や文化なども知っていただきたい！
• 技術に対して熱意のある方に入社していただきたい！

一度、【Wantedly内の弊社ページ】をのぞいてみてください。

Wantedly：https://www.wantedly.com/companies/rightcode