AIエージェントの権限管理｜業務導入で押さえる3層設計

AIエージェントの権限管理とサンドボックスとは｜業務導入で押さえる3層設計

AIエージェントを業務に導入するとき、最初にぶつかる壁が「権限管理」と「サンドボックス」の設計です。チャットAIと違ってエージェントは実際に手を動かします。ファイルを書き換え、メールを送り、データベースに登録し、外部APIを叩く。便利な反面、設定を間違えると「やりすぎ」によって本番データを壊す、顧客に誤メールを送る、機密情報を外部に漏らすといった事故に直結します。

株式会社Fyveは中小企業向けにAIエージェントの導入支援を行っており、Claude Code・MCP・各種自動化フレームワークを使った実装の現場で、まさにこの「やりすぎ防止」の設計を毎日詰めています。本記事では、Anthropicが公式に発信しているエージェントセキュリティの考え方を、非エンジニアでも理解できる言葉に翻訳し、中小企業が業務導入時に必ず押さえるべき3つの設計ポイント（権限分離・サンドボックス・監査ログ）を実務目線で解説します。

なぜAIエージェントには「権限管理」が必須なのか

従来のチャットAIは「会話して答える」だけでした。間違ったことを言っても、それを実行するのは人間です。一方、AIエージェントは「答えてから自分で実行する」段階に進んでいます。Anthropic公式も、エージェント時代のセキュリティは「モデルの賢さ」より「環境設計」が決定的に重要だと繰り返し発信しています。

「やりすぎ」が起きる構造的な理由

AIエージェントが暴走するのは、悪意ではなく構造の問題です。具体的には次の3つが重なったときに事故が起きます。

• 権限が広すぎる：本来必要のないファイル・データベース・外部APIへの書き込み権限まで付与されている
• 実行環境が本番と地続き：開発作業と本番運用が同じ場所で行われ、間違えた瞬間に本番が壊れる
• 何をしたかの記録が残らない：エージェントが何時に何を実行したのか、後から追えない

この3つを構造で潰すのが、権限分離・サンドボックス・監査ログという3層設計です。

私が現場で見た「やりすぎ」事故の実例

私自身、クライアントのWebサイト制作中に「やりすぎ」を経験しました。完成前なので検索結果に載らないようrobots.txtでインデックス拒否設定を入れていたところ、AIエージェントが効率化のために勝手にインデックス許可へ書き換えてGitHubにプッシュしてしまったのです。ホスティング側の自動デプロイが走り、未完成のサイトが一時的に検索エンジンに拾われる状態になりました。

原因はシンプルで、「インデックス関連ファイルを編集禁止」という権限設定をしていなかったことです。この一件以来、私たちはプロジェクトごとに編集禁止リスト（denyリスト）を必ず設定するようにしています。AIが賢くなったとしても、こうした事故は「賢さ」ではなく「権限設計」で防ぐべき領域です。

設計ポイント1：権限分離（最小権限の原則）

権限分離とは、AIエージェントに「業務に必要な最小限の権限だけ」を渡す考え方です。情報セキュリティの世界では「最小権限の原則（Principle of Least Privilege）」と呼ばれ、人間の社員にもAIエージェントにも同じように適用されます。

権限を分ける3つの軸

AIエージェントの権限は、以下の3軸で分けて考えると整理しやすくなります。

• 対象（どこに）：どのフォルダ・どのデータベース・どのAPIにアクセスできるか
• 操作（何を）：読み込みだけか、書き込みも許すか、削除まで許すか
• 確認（いつ）：勝手に実行してよいのか、人間の承認が必要なのか

Claude Codeをはじめとする実務的なエージェントフレームワークでは、これらがallow（許可）/ ask（都度確認）/ deny（拒否）という3段階で設定できます。私たちは案件の機密性に応じて、この設定の厳しさを毎回変えています。たとえば社内向けの業務改善ツール開発ではallowを多めに、顧客データを扱う案件ではaskとdenyを増やす運用です。一律の設定を全案件に適用するのは、現場では現実的ではありません。

MCP連携での権限判断

MCP（Model Context Protocol）はAIエージェントが外部サービス（Gmail、Slack、freee、Notionなど）と連携するための仕組みです。便利な反面、常にAPI経由で情報のやり取りを許可している状態になるため、情報漏洩のリスクは常にあります。

私たちが採用している判断基準は次の2点です。「本当に必要か」と「水際でのセキュリティ対策が取れるか」。便利だからといってすべてのMCPを接続していると、エージェントが意図しないMCPを呼び出して情報を持ち出すリスクが生まれます。使っていないMCPを許可状態で残しておくメリットはゼロなので、不要なものは外す。これだけで攻撃面（アタックサーフェス）が大幅に縮みます。

すでに公開しているMCP接続のAPIキー管理の実務記事もあります。あわせてご覧ください。

Claude CodeClaude Code/MCPのAPIキー管理｜実務の現実解

設計ポイント2：サンドボックス（隔離された実行環境）

サンドボックスは「砂場」のことで、AIエージェントが何を試しても本番環境に影響しない隔離された空間を指します。子どもが砂場でどれだけ壊しても、リビングは無事です。AIエージェントにも同じ環境を用意するのが、業務導入の前提条件になります。

中小企業が現実的に作れる3段階のサンドボックス

「サンドボックス」と聞くと専用サーバや仮想化技術が必要な印象を受けますが、中小企業の規模なら以下の3段階で十分に運用できます。

• レベル1：作業フォルダの隔離。エージェントに触らせる作業ディレクトリを限定し、それ以外への書き込みを拒否する。最も手軽でコストゼロ
• レベル2：開発環境と本番環境の分離。本番データベースのコピーで作業し、人間が確認したものだけ本番に反映する。一般的な開発手法と同じ
• レベル3：コンテナ・仮想マシンでの実行。Docker等で完全に隔離された環境でエージェントを動かす。機密性の高い案件向け

Anthropic自身もManaged Agentsという公式サービスで、隔離環境・認証・権限管理をインフラとして肩代わりする方向に動いています。これは「自社の機密情報をAIに扱わせることはハードルが高い」という企業側の現実に対する、業界としての答えの一つです。中小企業がこの全てを自前で構築する必要はなく、用途と機密性に応じてレベル1から段階的に上げていくのが現実解になります。

Hooksによる「強制的なガードレール」

権限とサンドボックスだけでは取りこぼす領域があります。たとえば「クライアントの社名を記事に書かない」「特定のキーワードを含むコマンドは実行しない」といった、ビジネスルール由来の制約です。これをエージェントの賢さに任せると、何度言っても忘れます。

私たちはHooksと呼ばれる仕組みで、エージェントが何かを実行する直前・直後に強制チェックを挟んでいます。記事執筆時には「クライアント情報漏洩防止」の検査を自動実行し、社名やURLが混入していないかを機械的にチェックします。人間の品質管理を補強する「第三者の目」として、Hooksは中小企業の運用でも極めて有効です。

設計ポイント3：監査ログ（何をしたかを必ず残す）

監査ログは、AIエージェントが「いつ・どのリソースに・何を実行したか」をすべて記録する仕組みです。事故が起きたとき、原因を特定し再発を防ぐための唯一の手がかりになります。総務省の情報セキュリティガイドラインでも、ログ管理は重要管理項目として明記されており、AIエージェントだからといって例外ではありません。

最低限残すべき4項目

中小企業の現場で「これだけは残しましょう」とお伝えしているのは次の4項目です。

• 実行日時：いつ動いたか
• 実行内容：何のコマンド・APIを叩いたか、引数は何だったか
• 対象データ：どのファイル・どのレコードを触ったか
• 結果：成功か失敗か、変更前後の差分

Claude CodeやManaged Agentsには、これらをデフォルトで記録する機能が組み込まれています。社内独自のエージェントを組む場合も、最初から監査ログを設計に組み込んでください。後付けで実装するのは、想像以上に手間がかかります。

クライアントへのセキュリティ説明の順序

中小企業のクライアントにAIエージェントを提案するとき、私たちは「リスク先行型」で説明しています。順序は以下の通りです。

• まず「どんなリスクが考えられるか」を率直に提示する
• 次に「そのリスクをゼロまたは極限まで低くする方法」を提示する
• 最後に「技術では完全に防げない人為的リスク」も正直に伝える

技術的に防げる部分は本記事で紹介した3層設計でほぼカバーできます。一方で、思わぬリスクは意外と人為的な場面に潜んでいます。たとえばAIに渡す指示文に機密情報を含めてしまう、出力結果を確認せず外部に転送してしまうといったケースです。クライアント側の運用ガイドライン整備も含めて提案するのが、現実的な落としどころになります。

業務導入チェックリスト：中小企業が今日から始める7項目

ここまでの内容を、すぐ着手できる形にまとめます。コストをかけず、まず手を動かして始められる項目から並べました。

• 1. エージェントの作業フォルダを業務単位で隔離する（フォルダの読み書き範囲を限定）
• 2. 使っていないMCP・連携サービスをすべて外す（攻撃面を減らす）
• 3. 編集禁止リスト（denyリスト）を作る（インデックス設定・本番DB・認証情報など）
• 4. 機密度の高い操作は「都度確認（ask）」に設定する（送信・削除・課金系）
• 5. 開発と本番の環境を分離する（本番データの直接編集を物理的に不可能にする）
• 6. Hooksで強制チェックを挟む（クライアント情報漏洩・指定キーワード混入の検査）
• 7. 監査ログをデフォルトで有効化する（実行日時・内容・対象・結果の4項目）

すべて一度に整えるのは難しいので、まずは1〜3だけでも導入してください。これだけで「うっかり事故」の大半は構造的に防げます。

Anthropic公式方針を業務に落とし込むということ

Anthropicは「AIエージェントの安全性は、モデル自体だけでなく、それを取り巻く環境設計で決まる」という立場を一貫して示しています。Managed Agentsという公式サービスをリリースしたのも、隔離環境・認証・権限管理という重要インフラを企業が自前で構築する負担を減らし、ビジネス活用を一気に現実的にするためです。

一方で、Managed Agentsは料金設定（トークン従量＋セッション時間課金＋外部検索課金）から見て、人間を1人置き換えるレベルの重い作業を想定しています。中小企業や個人事業主が最初から導入するにはオーバースペックです。だからこそ、ローカルのClaude Codeや軽量なエージェント環境に対して、本記事で紹介した3層設計（権限分離・サンドボックス・監査ログ）を自分たちで適用する設計力が重要になります。

セキュリティに関連する記事はほかにもあります。あわせて参考にしてください。

Claude Codeのセキュリティ運用｜法人開発で実践している7つの対策

Claude Code導入セキュリティチェックリスト｜社内稟議で使える15項目

まとめ：「やりすぎないAI」は設計で作る

AIエージェントは導入した瞬間に成果が出る道具ではありません。「やりすぎないように設計する」という地味な工程を経て、ようやく安心して業務に組み込めるようになります。本記事のポイントを再掲します。

• 権限分離：対象・操作・確認の3軸で最小権限に絞る
• サンドボックス：レベル1（フォルダ隔離）から段階的に上げていく
• 監査ログ：実行日時・内容・対象・結果の4項目を最低限残す
• クライアント説明：リスク先行→対策→人為的リスクの順で伝える

私たちは中小企業向けに、こうした設計をプロジェクトの最初に組み込む形でAI活用顧問サービスを提供しています。技術力だけでなく、案件ごとの機密性とコスト感に応じた「ちょうどいい設計」を提案するのが私たちの役割です。AIエージェントの業務導入に不安がある方は、設計段階から一緒に進めることをおすすめします。