最小権限とは、業務に必要な範囲だけに権限を絞る設計原則のことです。

顧問先の資料をAIに読ませてよいか、という問いは、実務では権限設計の問いに置き換わります。この記事では、自律的に動くAIに事務所のファイルやツールへのアクセスを渡すとき、どこまでを許可し、どこから拒否するかを組み立てる工程を整理します。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、行政の見解は各府省庁の公表資料で確認しています。IPAは、AIエージェントが機密情報や個人情報にアクセスする過程で意図しないデータ漏えいが発生するリスクを課題として挙げています（出典: IPA SDS技術コラム AIエージェント）。

権限の話が2026年になって前面に出てきた理由

チャット型の生成AIでは、権限という言葉はほとんど出てきませんでした。人が貼り付けた分しか読まれないので、統制の対象は入力の中身だけで済んだからです。AIエージェントはここが変わります。IPAはAIエージェントを、ユーザーから与えられた指示に基づき自律的に問題解決やタスク実行を行うソフトウェアとして整理しており、外部APIとの高度な連携を従来型の生成AIとの違いに挙げています（出典: 前掲IPAコラム）。読む範囲も、呼び出す先も、指示の解釈次第で動くということです。

事務所にとっての影響は二段構えです。一段目は、意図せぬファイルまで読まれる可能性。二段目は、外部サービスへ情報が出ていく経路が増えることです。前者はフォルダ設計で、後者は連携先の棚卸しで対処します。どちらも、事後に検知するより事前に閉じておくほうが手数が少なくなります。

具体的な機構としては、エージェント型ツールの側に権限制御が実装されています。たとえばClaude Codeでは、読み取り専用のツールは作業ディレクトリ内であれば承認なしに動き、シェルコマンドとファイル変更は承認を要する三段構成になっています。権限ルールは許可、確認、拒否の三分類で書き、評価は拒否、確認、許可の順で行われ、先にマッチしたものが結果を決めると説明されています（出典: Claude Code Docs 権限を設定する）。この順序を理解していないと、細かい許可を書いたつもりが広い拒否に飲まれ、逆に広い許可を書いたつもりが確認プロンプトで止まります。

制度の側も動いています。総務省と経済産業省はAI事業者ガイドライン（第1.1版）を公表しており、AIを利用する事業者が取るべき対応の枠組みを示しています。個人情報保護委員会は生成AIサービスの利用について注意喚起を出しています。士業事務所は個人情報取扱事業者でもあるため、これらの枠組みを自分ごととして読む立場にあります。

士業事務所に特有の事情もあります。一般の事業会社であれば、自社の情報が漏れたときに責任を負うのは自社です。士業事務所が扱うのは他人の情報であり、しかもその他人は事務所を信頼して預けている顧問先です。権限設計の失敗が、そのまま信頼関係の毀損に直結する構造になっています。だからこそ、汎用的なセキュリティ対策の枠を借りるだけでは足りず、どの情報をどの範囲で機械に見せたかを、案件単位で説明できる粒度まで落とす必要が出てきます。

もう一点、事務所の規模と権限設計の負荷は比例しません（以下の数字は編集部が置いた参考例です）。5人の事務所でも、顧問先が200社あればフォルダの数は膨らみます。負荷を決めるのは人数ではなく、情報の種類の多さと保管場所の散らばり具合です。この観点で自事務所を見ると、権限を絞る前にやるべきことがフォルダの整理だった、と気づく事務所も少なくありません。

事務所で最小権限を回す6工程

結論から言えば、最小権限は一度設定して終わる作業ではなく、月次で回す運用です。理由は、扱う案件が変われば必要な範囲も変わるからです。以下の6工程を、導入時に一巡し、その後は月次で軽く回します。

工程1 触らせてよい情報の棚卸し

事務所が持つ情報を、三層に仕分けます。第一層は事務所内部の一般文書。第二層は匿名化済みの顧問先資料。第三層は顧問先の氏名や金額を含む実データです。AIエージェントに渡す範囲を第一層から始め、第二層まで広げるかを次の工程で判断します。第三層は、契約形態と顧問先への説明が整うまで対象外に置く運用が扱いやすい形です。

工程2 作業用ディレクトリの分離

エージェントに渡すのは、共有サーバーの顧問先フォルダそのものではなく、必要なファイルだけをコピーした作業用ディレクトリにします。ツール側でも、起動したディレクトリの外は既定でアクセスできない設計になっており、追加ディレクトリを明示的に足す形になっています（参考: 前掲Claude Code権限ドキュメント）。親フォルダごと足すのが最も危ない操作なので、ここは所内ルールで縛ります。

工程3 拒否ルールを先に書く

許可から書くと抜けが出ます。拒否から書きます。認証情報、秘密鍵、バックアップ領域、給与データ、そして設定ファイルそのもの。これらを読み取り拒否に入れます。ツールによっては、読み取り拒否ルールが同じパスの編集操作もブロックする設計になっていますが、書き込み系のツールが別枠になっている場合もあると案内されているため、編集側の拒否も併記しておくほうが安全側です（出典: 前掲Claude Code権限ドキュメント）。

工程4 承認スキップの封じ込め

承認をすべて省略するモードは、隔離された環境向けと位置づけられています。組織側の管理設定で、このモードの使用自体を禁止できる仕組みも用意されています。管理設定は、ユーザー設定やプロジェクト設定で上書きできない優先順位に置かれると説明されています（参考: 前掲Claude Code権限ドキュメント）。事務所としては、便利さより先にここを閉じます。

工程5 外部連携の白紙化と再許可

外部ツール連携は、いったん全部拒否してから、必要なものだけ再許可します。権限ルールはツール名のワイルドカードで外部ツール群をまとめて拒否でき、逆に許可側はサーバー名を明示する形に制限されると説明されています（参考: 前掲Claude Code権限ドキュメント）。ネットワーク側も、取得を許可するドメインを列挙する運用に寄せます。シェルコマンドが使える状態では、ドメイン制限だけでは通信を止めきれないという注意も明記されているので、両輪で設計します。

工程6 月次の棚卸しと記録

追加した許可、追加したディレクトリ、追加した連携先を月次で一覧にし、まだ要るかを判定します。要らなくなったものは消します。この記録が、顧問先から説明を求められたときの根拠になります。棚卸しの所要は、10人規模の事務所なら月30分程度を見込む形が現実的です（この所要時間は編集部が想定した参考値です）。

工程を回すためのプロンプト

初期のルール案づくりには、次のプロンプトが使えます。事務所名や顧問先名は入れません。

あなたは情報システムの権限設計者です。
自律的にファイル操作を行うAIエージェントに与える権限ルール案を設計してください。

【前提】
- 組織: 行政書士事務所（架空・C事務所）、有資格者1名+スタッフ3名
- 用途: 申請書類の形式チェックと、提出書類一覧の自動作成
- 保管: 共有サーバーに顧問先フォルダ、ローカルに作業用フォルダ
- 制約: 顧問先の氏名・住所は作業用フォルダへコピーする前に匿名化する

【出力してほしいもの】
1. 「拒否」から書き始めたルール案（対象と理由を1行ずつ）
2. その後に書く「確認」「許可」のルール案
3. 拒否が許可より先に評価される前提で、抜け道になりやすい書き方を5つ
4. 月次の棚卸しで見るべき項目を7つ
5. この設計の弱点を率直に3つ指摘すること

既存設定の点検には、次のプロンプトで観点を洗い出してから、管理者が実際の設定ファイルと突き合わせます。

あなたはセキュリティ監査の実務者です。
AIエージェントの権限設定を点検するためのチェックリストを作ってください。

【条件】
- 対象は「読み取り範囲」「書き込み範囲」「シェル実行」「外部ツール連携」「ネットワーク送信」の5領域
- 各領域につき、確認する問いを3つずつ（合計15問）
- 各問いには「危険な回答の例」を1つ添える
- 最後に、この15問では見つけられない種類のリスクを3つ挙げる
- 事務所の実名・顧客名は一切書かないこと

出力されたルール案は、そのまま設定ファイルに流し込まず、事務所の管理者が実際のフォルダ構成に照らして確認し、有資格者が扱う情報の範囲を了承する工程を挟みます。権限設計は情報管理体制そのものなので、機械の提案だけで確定させない運用が現実的です。エージェントが外部の入力に引きずられて意図しない操作をする経路については、プロンプトインジェクション対策を整理した記事も合わせて確認しておくと設計の抜けが減ります。

守秘義務と事務所規程に落とすときの3つの決めごと

権限設計の目的は、突き詰めれば守秘義務の履行を説明できる状態を作ることです。各資格法の秘密保持規定は、主体と例外の書きぶりが少しずつ異なります。

弁護士は弁護士法第23条が、その職務上知り得た秘密を保持する権利を有し義務を負うと定めています。税理士は税理士法第38条が、正当な理由がなくて税理士業務に関して知り得た秘密を他に洩らし、又は窃用してはならないと定めています。公認会計士は公認会計士法第27条、司法書士は司法書士法第24条、行政書士は行政書士法第12条、社会保険労務士は社会保険労務士法第21条、弁理士は弁理士法第30条にそれぞれ秘密を守る義務の規定が置かれています。個人データを外部へ渡す局面では個人情報の保護に関する法律第27条の第三者提供の制限が関係します。これらを自事務所のAI運用にどう当てはめるかの結論は、契約内容と扱う情報の性質を見て有資格者が判断する領域です。

決めごとの1点目は、権限の付与と剥奪を誰が持つかです（以下の人数は編集部が想定した参考値です）。管理者を1人に集約すると退職時の剥奪が滞り、全員が管理者だと統制が消えます。管理者2名で、付与は申請ベース、剥奪は月次棚卸しで自動、という形が回りやすい組み立てです。申請の記録がそのまま説明資料になります。

2点目は、顧問先への説明の段階です。第三層の実データをAIに渡す前に説明するのか、契約更新のタイミングで包括的に説明するのか。個人情報保護委員会の注意喚起は、生成AIサービスに個人情報を入力する場面の留意点に触れています（参考: 個人情報保護委員会 生成AIサービスの利用に関する注意喚起等）。説明の型を先に決めておくと、案件ごとに迷わずに済みます。

3点目は、記録の粒度です。誰がどの権限を、いつ、なぜ足したか。この三点が残っていれば、後から経緯を説明できます。逆に、設定ファイルの最新版しか残っていない状態だと、なぜその許可があるのかを誰も答えられなくなります。バージョン管理に載せる、あるいは変更申請の記録を別途残す。どちらでも構いませんが、決めておかないと残りません。所内で個人契約のツールが野放しになっていると、この記録自体が成立しないため、事務所のシャドーAIを止める手順を先に片付けておく順序が現実的です。

権限設計でよくある3つの穴

穴1は、拒否ルールに例外を書き込む型です。広い拒否の中に狭い許可を混ぜても、拒否が先に評価されるため許可は効きません。細かい許可を効かせたいなら、拒否の範囲そのものを狭く書き直す必要があります。この挙動はドキュメントに明記されています（出典: Claude Code Docs 権限を設定する）。

穴2は、シェルコマンドの引数で絞ろうとする型です。特定のURLだけ許可するといった引数ベースの制約は、オプションの位置、プロトコルの違い、リダイレクト、変数展開、余分な空白などで簡単に外れると注意されています。より信頼性が高い方法として案内されているのは、ネットワーク系のコマンド自体を拒否し、専用の取得ツールにドメイン許可を付ける形だと案内されています（参考: 前掲権限ドキュメント）。

穴3は、追加ディレクトリを設定の共有手段だと誤解する型です。ディレクトリを追加してもファイルアクセスが広がるだけで、多くの設定はそこから読み込まれないと明記されています（参考: 前掲権限ドキュメント）。所内で設定をそろえたいなら、ユーザーレベルの設定か、配布可能な形にまとめる手段を使います。

三つに共通するのは、機能の挙動を確認せずに直感で書いている点です。権限は、書いた文字列がそのまま効くわけではありません。導入時に、意図した拒否が実際に効くかを1回テストしておくだけで、この種の穴はほぼ塞がります（このテスト手順は編集部が推奨する参考例です）。

テストの内容は単純で構いません。読ませたくないフォルダのファイル名を挙げて、内容を要約するよう指示します。拒否が効いていれば、その時点で止まります。止まらなければルールの書き方が間違っているか、想定していない経路から読まれています。同じ要領で、書き込みを許可していないフォルダにファイルを作らせる指示も試します。この2本を通すだけで、設定の実効性はかなりの精度で確認できます。

見落とされやすい四つ目の穴として、シンボリックリンクの扱いも挙げておきます。許可されたフォルダの中にあるリンクが、拒否した領域を指している場合、ツールによってはリンクとその参照先の両方を評価する設計になっており、拒否が優先されると説明されています（参考: 前掲権限ドキュメント）。共有サーバーへのショートカットを作業フォルダに置いている事務所は、この挙動を前提に構成を見直しておくと安全側に倒れます。

費用と体制をどう置くか

金銭面では、権限管理そのものに追加費用は発生しにくい一方、組織向けの管理設定を使うには法人契約が前提になる場合があります。個人向けプランで運用すると、承認スキップの禁止のような組織的な締め付けが効きません。この差は、機能表よりも統制設計の側で効いてきます。

工数は、初回の設計に1日、テストに半日、その後は月次30分程度が目安です（この工数は編集部が想定した参考値です）。10人規模の事務所であれば、事務局側の1名が兼務で持てる分量に収まります。有資格者は、扱う情報の範囲の了承と、成果物の内容確認に関与する形が分担として自然です。

体制で決めておくとよいのは、事故時の一時停止手順です。想定外の動きが出たときに、誰がどうやってエージェントを止め、どの範囲の記録を確保するか。手順を1枚にして端末の近くに置いておくと、慌てずに済みます。IPAは情報セキュリティ全般の対策ガイドを公開しており、既存のセキュリティ運用と接続する形で整理すると重複が減ります。

費用対効果の見方も整理しておきます。権限設計に投じる工数の見返りは、事故が起きなかったことなので、効果が数字で出てきません。それでも投資判断ができるのは、顧問先への説明可能性という別の便益があるからです。情報管理の体制を問われたときに、設定と記録をそのまま出せる事務所と、口頭で方針を説明するしかない事務所とでは、受け止められ方が変わります。ここを営業上の差別化と捉える見方もあり得ます。

もう一つ、既存の情報管理規程との接続も工数に効きます。多くの事務所は、紙とファイルサーバーを前提にした規程を持っています。そこにAI固有の条項を継ぎ足すのか、章を分けて新設するのか。継ぎ足しのほうが早いものの、条項の粒度が合わずに読みにくくなることがあります。新設は手間がかかるぶん、後の改定が楽になります。どちらを採るかは、規程の改定頻度と運用の担い手の人数を見て決める形になります。

自律性が上がるほど権限設計が経営の話になる論点

この先の論点は、権限の粒度がどこまで細かくなるかではなく、誰がその粒度を決めるかに移ります。IPAは、AIエージェント同士が連携するマルチエージェント・システムの発展を今後の展望として挙げています（出典: 前掲IPAコラム）。エージェントが増えれば、権限の組み合わせは掛け算で増えます。所長が一人で見切れる規模を超えたときに、統制をどう保つかという設計の問題です。

もう一つは、外部連携のコストです。IPAは課題の一例として、自律的に外部システムと連携することで想定外の利用や通信が増え、コストが膨らむ恐れを挙げています（参考: 前掲IPAコラム）。権限を絞ることは、情報漏えい対策であると同時に、費用の予測可能性を上げる施策でもあります。

三つ目は、説明責任の形です。顧問先から、どのAIにどこまで見せているかを問われる場面は増えていきます。そのときに出せるのは、思想の説明ではなく、設定と記録です。最小権限を回す運用は、その提出物を日常業務の中で作り続ける仕組みでもあります。

よくある質問

最小権限は具体的に何から始めればよいですか

拒否ルールから始めます。認証情報、秘密鍵、バックアップ領域、給与データを読み取り拒否に入れ、その後で必要な許可を足していく順序です。権限ルールは拒否、確認、許可の順に評価され、先にマッチしたものが結果を決めるため、拒否を先に固めるほうが設計の見通しが良くなります（出典: Claude Code Docs 権限を設定する）。

承認プロンプトを全部スキップしても大丈夫ですか

隔離された環境以外では想定されていない使い方です。ドキュメントは、このモードをコンテナや仮想マシンなど、影響が閉じた環境でのみ使うよう注意を促しています。組織設定で使用自体を禁止する仕組みも用意されています（参考: 前掲権限ドキュメント）。事務所の実務端末で常用する運用は避けるのが無難です。

顧問先の実データをエージェントに触らせてよいですか

判断の前提として、扱うツールのデータ利用ポリシーと契約形態を確認する必要があります。そのうえで、顧問契約の内容と各資格法の秘密保持規定に照らした最終判断は有資格者が行う領域です。個人情報保護委員会は生成AIサービスの利用について注意喚起を公表しているので、社内の判断基準を作るときの出発点として使えます（参考: 個人情報保護委員会 注意喚起）。

外部ツール連携はどこまで許可すればよいですか

必要なものだけに絞る運用が基本です。権限ルールでは、外部ツール群をワイルドカードでまとめて拒否したうえで、許可側はサーバー名を明示して個別に足す形が示されています（出典: 前掲権限ドキュメント）。連携先が増えるほど情報の出口が増えるため、追加のたびに棚卸し表へ記載する運用とセットにします。

権限設定は誰が管理する形が回りやすいですか

事務局側に管理者を2名置く形が回りやすい構成です（以下は編集部が支援現場で採っている参考例です）。1名だと退職や休暇で剥奪作業が滞り、全員が管理者だと統制が消えます。付与は申請ベース、剥奪は月次棚卸しで機械的に、という組み立てにすると、記録が自然に残ります。

設定を所内で共有するにはどうすればよいですか

ディレクトリを追加しても設定は共有されません。ドキュメントは、追加ディレクトリがファイルアクセスを許可するもので、設定ルートにはならないと明記しています（出典: 前掲権限ドキュメント）。共有したい場合は、ユーザーレベルの設定に置くか、配布可能な形にまとめる手段を使います。

事故が起きたときに何を確保すればよいですか

まずエージェントの実行を止め、その時点の設定ファイルと操作の記録を保全します。どの指示でどのファイルが変わったかが追えれば、影響範囲の特定が早くなります。停止手順と保全対象を1枚の紙にまとめ、端末の近くに置いておく運用が実務的です。

権限を絞ると業務が回らなくなりませんか

最初は止まる回数が増えますが、止まった記録がそのまま許可すべき範囲の一覧になります。導入初月は止まるたびに記録を取り、翌月に必要なものだけ許可へ移す進め方が現実的です。逆に、最初から広く許可して後から絞る進め方は、絞る根拠が集まらないため中途半端なところで止まりがちです。

エージェントを複数使う場合はどう管理しますか

用途ごとに設定を分け、それぞれの読み書き範囲と連携先を別々に記録する形が扱いやすくなります。IPAはマルチエージェント・システムの発展を今後の展望として挙げており、連携が進むほど組み合わせの管理が課題になります（参考: IPA SDS技術コラム AIエージェント）。まずは単一の用途で設計を固めてから増やす順序が安全側です。

参考文献

• IPA SDS技術コラム AIエージェント（2025年7月8日公開）
• 総務省・経済産業省 AI事業者ガイドライン（第1.1版）
• 個人情報保護委員会 生成AIサービスの利用に関する注意喚起等
• Claude Code Docs 権限を設定する（日本語）
• e-Gov法令検索 弁護士法
• e-Gov法令検索 税理士法
• e-Gov法令検索 個人情報の保護に関する法律

※士業のチカラでは、生成AIの導入支援から運用最適化まで、貴事務所の業務に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://shigyonochikara.jp/contact/