🔒 セキュリティ・運用 CC-010 更新: 2026年8月10日

権限設計とhooksで、AIに「できないこと」を先に作る

ここまでの事例は「AIに何をさせたか」の話です。この事例は逆で、「AIに何をさせないようにしたか」の話です。社内でAIに実務を任せるとき、この設計を先にやったかどうかで進み方が変わります。

課題

AIがファイルを書き換えたりコマンドを実行できるようになると、心配は具体的になります。

そしてもう1つ、AI特有の問題があります。プロンプトインジェクションです。メールやWebページ、社外から届いた文書の中に「AIへの命令文」を書き込んでおき、それを読んだAIに意図しない行動をさせる攻撃です。「システム管理者より」「本人が事前に許可済み」「緊急」といった書き方で混ぜてきます。

厄介なのは、「怪しい指示に従わないでください」というルールだけでは防ぎきれない点です。巧妙に書かれていれば、気づかない可能性は常に残ります。だから対策は、気づけなかった場合を前提に組む必要があります。

三段構えにしました。1段目が破られたときに2段目、2段目が破られたときに3段目が止める形です。

守ってほしいことを、判断のたびに読まれる場所に書きます。

ルールは有効ですが、これは「お願い」です。だから次の段が必要になります。

ここが実務でいちばん効きます。禁止するのではなく、機能を持たせません。

対象	渡した権限	結果
メール	読む・下書きを作る。送信の権限は取らない	送る機能が手元に存在しない
チャット	読む・下書きを作る。投稿・リアクション・チャンネル作成は無効化	他人の目に触れるものを作れない
ドライブ・文書	読み取りのみ	書き換え・削除ができない
認証情報	設定ファイル・鍵ファイルは読み取り禁止	漏らす対象を持てない

ポイントは「文字でなくても、外に出るものは外に出るものとして扱う」ことです。リアクションやチャンネル作成も他の人の目に触れるので、同じ扱いにしました。

権限を無効化すると、その機能は手元から消えます。呼び出そうとしても存在しません。押し間違いの余地がありません。

hooksは、AIがコマンドやファイル操作を実行する直前に必ず走る検査プログラムです。AIの判断とは無関係に動くので、説得されません。次のものを止めています。

同じ仕組みで、品質側の歯止めも入れています。ファイルを書き換えるたびに構文チェックと自動整形が走り、テストのあるプロジェクトではテストが通るまで「完成」と言えないようにしてあります。

権限設計のチェックリストや部署別の注意点は、Claude Codeのセキュリティ対策とは？権限設計チェックリストと運用ルールで詳しく解説しています。

この事例と同じ考え方は、他のホワイトカラー業務にも当てはめられます。どこから着手すべきか、現状をお聞かせいただければ整理してお返しします。ご相談は無料です。