📌 あわせて読みたい: Claude CodeやCodexを使うときの権限と承認の基本はこちらの記事へ。この記事はその先、閲覧・下書き・限定実行・外部公開という段階ごとに、誰が承認し、何を記録し、事故の時に何を戻すかという運用設計だけを扱います。特定製品の機能比較ではありません。
AIエージェントに仕事を任せたいと考えたとき、多くの人がつまずくのは「権限をどこまで渡せばいいか」です。全部任せるのは怖いが、毎回人が確認するのでは自動化にならない——この記事は、権限を仕事の重要度と回復可能性に応じて段階分けし、各段階に承認者と記録と切り戻し手段を先に決めておくという考え方を、公式資料に基づいて整理します。
結論:権限を一括で渡さない
AIエージェントに与える権限は、仕事の重要度と「失敗したときにどれだけ元に戻せるか」に応じて決めます。閲覧、下書き、限定的な実行、外部への公開を、同じ一つの権限として扱わないことが出発点です。NIST(米国立標準技術研究所)のAIリスク管理フレームワーク(AI RMF)は、組織のリスク判断、文書化された人間監督、AIシステムのライフサイクルを通じた継続的なリスク管理を扱っており、この記事の段階分けはその考え方を運用に落とし込んだものです。
まず業務と影響範囲を地図化する
権限を決める前に、AIエージェントに任せようとしている業務が、失敗したときにどこまで影響するかを洗い出します。読むだけの業務なのか、社内向けの下書きを作る業務なのか、外部に公開される文章や取り消しにくい操作を含む業務なのかで、必要な備えは大きく変わります。NISTのAI RMFは、AIシステムの開発・展開に伴うリスク判断について組織の経営層が責任を担うことをGovern(統治)機能の成果の一つに位置づけています。つまり、どこまでの権限を許すかという線引き自体が、現場の裁量だけに任される話ではなく、組織として引き取るべき判断だということです。地図化の段階では、業務ごとに「取り消しやすさ」を軸に並べておくと、次の権限分けがしやすくなります。
閲覧・下書き・限定実行・公開を分ける
業務の影響範囲が見えたら、AIエージェントに与える権限を段階に分けます。目安になるのは、影響が読むだけにとどまる「閲覧」、成果物は作るが人の確認を経るまで外に出ない「下書き」、決められた範囲内でだけ実際の操作を行わせる「限定実行」、そして社外に情報が出る、または取り消しにくい「外部公開」という4段階です。OpenAIのAPIプラットフォームは、プロジェクト単位でワークスペース内のアクセス・利用量・支出をきめ細かく制御する機能や、組織所有者・セキュリティチームがアクセスと権限を管理するAdmin APIを案内しており、ChatGPT Enterprise/Eduなどではグループごとのカスタムロールで、ChatGPT Work、Codex、接続ツール、ワークスペースエージェントなどの権限を設定できるとしています。ただし、こうした閲覧・下書き・実行・公開の4段階が、すべての製品・すべてのプランに標準搭載されているとは限りません。この記事で示す段階分けは、各社が案内する権限管理機能を業務の設計に落とし込むための編集上の整理であり、特定製品の必須仕様ではない点に注意してください。
実行権限はファイル・操作の単位までしぼる
「限定実行」を任せる場合、対象をできるだけ絞り込むことが安全設計の基本になります。OpenAIのChatGPT Work/Codexの案内では、ローカルフォルダについてタスクに必要なファイルだけへのアクセスを許可する運用や、重要な操作を人が承認できる仕組みが説明されています。AIエージェントに「このフォルダの全権限」のような広い許可を渡すのではなく、「この業務に必要なファイルだけ」「この操作だけ」という単位まで絞り込み、それ以上の操作が必要になった場面ではあらためて人の承認を挟む、という発想です。切り戻し試験を実施するかどうかは、運用設計として決めます。
承認ゲートと例外の扱いを決める
限定実行や外部公開の段階に進む業務では、「誰が」「何を基準に」承認するかを先に言葉にしておきます。承認者が不在のときにどう扱うか、通常の手順から外れる例外的な依頼が来たときにどう扱うかも、事前に決めておかないと、現場が都度その場で判断することになり、段階分けの意味が薄れます。NISTのAI RMFは、組織方針に沿った人間監督のプロセスを定義・評価・文書化することをMap(対応付け)機能の成果の一つとして挙げています。承認ゲートを「一応レビューする」という曖昧な運用にせず、誰が・どの基準で・どこまで見るかを文書化しておくことが、後から振り返る際にも効いてきます。
実行記録と確認項目を残す
AIエージェントに実行させた操作は、後から「何が・いつ・誰の承認で行われたか」をたどれる形で記録しておきます。OpenAIのAPIプラットフォームは、セキュリティ・コンプライアンス上のリスクを可視化する機能としてAudit Logs APIを案内しています。NISTのAI RMFは、Govern機能で整えた体系的な文書化を、MapおよびMeasure(測定)の各機能で使うことが透明性と説明責任を高めるとしており、記録は承認の実施を証明するためだけでなく、次の判断の材料としても使う前提になっています。何を記録するかは業務ごとに違いますが、少なくとも「対象」「実行者(AIか人か)」「承認者」「結果」がたどれる状態を目指します。
失敗時の停止・切戻しを先に試す
権限設計は、うまくいく前提だけで組むと機能しません。むしろ大事なのは、想定外の出力や誤操作が起きたときに、どこで止め、どう元に戻すかを先に用意しておくことです。NISTのAI RMFは、人間とAIの構成を含むリスクをMeasure(測定)し、その知識をManage(管理)の判断に使う考え方を示しています。これは、事前に「起こり得るリスク」を測っておくことが、実際に問題が起きたときの対応判断の材料になるという発想です。停止・切り戻しの手段は、権限段階が上がるほど、実際に一度動かして確認しておく価値があります。使う場面が来てから初めて試すのでは、切り戻し自体が想定通りに機能するか分からないためです。
定期見直しと既存記事への導線
権限段階、承認ゲート、実行記録、切り戻し手段は、一度決めたら終わりではなく、業務内容やAIエージェントの利用範囲が変わるたびに見直す対象です。NISTのAI RMFは、AIリスク管理をAIシステムのライフサイクルを通じて継続的かつ適時に行うものとしており、4機能を順番どおりに消化するチェックリストではないと明記しています。つまり、Govern・Map・Measure・Manageは一度きりの手順ではなく、業務やAIエージェントの使い方が変わるたびに繰り返し立ち戻る枠組みとして位置づけられています。複数のAIを役割分担させている場合の記録や確認者の考え方は、後述の記事もあわせて参考にしてください。
🔗 次に読む
- 複数のAIを使い分ける際の役割・記録・確認者の整理はこちらの記事へ。
- 生成AI業務活用の全体像は生成AIの業務活用 完全ガイドへ。
※本記事は2026年7月18日確認時点のNIST AI RMFおよびOpenAI公式案内に基づく整理です。製品の権限機能はプラン・契約・提供地域により異なり、変更されることがあります。AIエージェントに権限を与えても事故が起きないことを保証するものではなく、実際の運用では各社の最新の公式情報をご確認ください。
コメント