階層別のAI権限設定とは、職責に応じて使える範囲を分ける運用のことです。

事務所で生成AIを使えるのは誰までか、という問いに一行で答えられるでしょうか。この記事では、有資格者・勤務有資格者・補助者・事務員・外部委託という5つの階層で、生成AIの利用範囲をどう切り分けるかを整理します。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、行政の見解は各府省庁と委員会の公表資料で確認しています。守秘義務の根拠は職種ごとに別の条文に置かれており、たとえば税理士は税理士法第38条、社会保険労務士は社会保険労務士法第21条に定めがあります。

権限設定が事務所の規程で最後まで残る理由

生成AIの規程づくりで最後まで決まらないのが、誰にどこまで使わせるかです。理由は、ツールの設定では切れず、事務所の職責の設計に踏み込む必要があるからです。

多くの事務所は、まず入力してよい情報の線引きから着手します。秘密情報は入れない、個人情報は仮名化する、といったルールです。ここまでは全員共通のルールとして書けます。ところが、実際の運用では同じ情報でも扱ってよい人と扱ってはならない人が分かれます。担当していない案件の資料を補助者が参照できるか、事務員が顧問先の名簿を検索できるか。この区別は、従来はファイルサーバのアクセス権限とキャビネットの鍵で担保されていました。

生成AIは、この担保を素通りする性質があります。事務所内で共通のAIに文書を蓄積して横断検索させる構成は、アクセス権限の設計とは別のレイヤーで情報を混ぜます。東京弁護士会の会報LIBRAが2026年7・8月合併号で組んだ特集も、事務所内で共通の生成AIを利用する場合、ある事件の情報が学習または参照の対象になると他の弁護士が別の事件で同じAIを利用した際にその情報が出力される可能性を指摘し、従来の情報管理の枠組みでは想定されていなかったリスクだと述べています（出典: 東京弁護士会 LIBRA Vol.26 No.7-8 特集）。

法令の側から見ると、従業者の扱いには独立した条文が置かれています。個人情報保護法第24条は、個人情報取扱事業者が従業者に個人データを取り扱わせるにあたり、安全管理が図られるよう必要かつ適切な監督を行うことを定めた条文です。同法第23条の安全管理措置とは別に、従業者の監督が独立して置かれている構造は、権限設計が組織側の課題であることを示しています。

もう1つの背景が、事務所の人員構成です。士業事務所は、有資格者と無資格の補助者が同じ案件を分担する構造を持ちます。無資格者が有資格者の指揮のもとで補助する形は業務の前提ですが、生成AIが介在すると、その指揮の範囲が曖昧になります。AIが下書きを出し、補助者がそれを整え、有資格者が最後に見る。この流れのどこで責任が移るのかを決めないまま運用すると、後から遡って説明できません。

5つの階層で利用範囲を切り分ける設計

結論として、権限は人ではなく職責に紐づけて設計します。人に紐づけると異動や採用のたびに設計が崩れるためです。

第1階層は、有資格者（所長・パートナー）です。すべての案件情報にアクセスでき、生成AIへの入力可否を判断する権限を持ちます。出力を成果物として採用するかどうかの最終判断も、この階層が担います。逆に言えば、この階層が判断しない限り、AIの出力は事務所の外へ出ません。

第2階層は、勤務有資格者（アソシエイト・勤務税理士など）です。担当案件の範囲で入力可否を判断できますが、担当外の案件情報を参照する権限は持ちません。新しいツールの導入判断や、入力ルールの例外適用は、第1階層に上げる設計にします。

第3階層は、補助者（有資格者の指揮のもとで実務を担う無資格スタッフ）です。仮名化・抽象化された情報の範囲で生成AIを使えます。顧客名や個人情報を含む原文をそのまま入力する権限は持たせず、仮名化の作業自体を手順として渡します。出力の採否判断は行わず、指摘の一覧を有資格者へ回すところまでが役割です。

第4階層は、事務員（総務・経理・受付）です。事務所内部の業務、たとえば定型メールの下書き、マニュアルの整備、経費書類の整理などに範囲を限定します。案件情報にはアクセスせず、顧問先の固有名詞を含む入力も行いません。この階層で使うサービスを、案件用と分けている事務所があります。

第5階層は、外部委託先（記帳代行の外注、翻訳、システム保守など）です。事務所が使う生成AI環境へのアクセスは原則として与えず、必要な場合は委託契約に情報の取扱いを明記したうえで、対象を限定します。

この5階層に対して、決めることは4つです。アクセスできる案件の範囲、入力してよい情報の粒度、使用してよいサービスとプラン、出力の採否を判断する権限の有無。この4つを階層ごとに埋めれば、規程の骨格になります。より広い規程の枠組みは事務所のAI利用ガイドラインの作り方に整理しています。

階層を分ける単位は、ツール側で切れる粒度に合わせます。組織向けプランでワークスペースやプロジェクトを分けられるサービスなら、その単位が階層の境界になります。分けられないサービスであれば、そのサービス自体を第4階層以下では使わないという判断も選択肢に入ります。規程の表と実際の設定が一致していない状態は、点検のたびに説明が必要になり、結局は運用されなくなります。

各階層に何を渡すかを決めるとき、判断と作業を分けて考えると設計が速くなります。判断とは、入力してよいかどうか、出力を成果物にしてよいかどうかを決めることです。作業とは、仮名化する、貼り付ける、整形する、記録を残すことです。判断は上位階層に集め、作業は下位階層に降ろす。この原則だけで、5階層の中身の大半は埋まります。残るのは、事務所ごとの案件構成と人員の実情で調整する部分です。

実装の手順は次のようになります。

1. 現在の人員を5階層のどこに置くかを一覧にします。兼務がある場合は、高いほうの階層ではなく、業務ごとに分けて書きます。
2. 使用中のサービスを洗い出し、アカウントが個人契約か組織契約かを利用者ごとに確認します。個人契約が混ざっていると、階層設計が意味を持ちません。
3. 組織向けプランの管理機能で、階層に対応するグループを作ります。ワークスペースやプロジェクトを分けられるサービスであれば、案件情報を扱う領域と事務所内部の業務用領域を物理的に分けます。
4. 仮名化の手順書を作ります。第3階層以下が使う手順なので、判断を要する記述を残さず、置換対象を列挙する形にします。
5. 出力の採否を記録する様式を決めます。誰が、どの出力を、採用・修正・不採用のどれにしたかを残します。
6. 例外申請の経路を決めます。階層を超えた利用が必要になる場面はいずれ出てくるので、その場で判断させず、上位階層へ上げる導線を作ります。
7. 半年ごとの点検日を決めます。人の異動とサービス仕様の変更、両方に追随する必要があります。

有資格者が最終確認を担うのは、上記の1と5です。誰をどの階層に置くかの判断と、出力を成果物にするかどうかの判断は、事務所の責任の所在に直結します。

階層設計を文章に起こすとき、生成AIを下書きに使えます。以下は架空の事務所を前提にしたプロンプトです。

あなたは事務所の内部規程の草案づくりを補助するアシスタントです。
以下の階層と業務内容をもとに、生成AI利用の権限表を作成してください。

【階層】
1. 有資格者（所長）
2. 勤務有資格者
3. 補助者（無資格・有資格者の指揮下）
4. 事務員（総務・経理・受付）
5. 外部委託先

【各階層について記載する項目】
- アクセスできる案件の範囲
- 入力してよい情報の粒度（原文可／仮名化必須／固有名詞禁止）
- 使用してよいサービスとプラン種別
- 出力の採否を判断する権限の有無
- 例外が必要になったときの申請先

条件:
- 法的な評価や当てはめは書かないでください。運用として何をするかだけを書いてください。
- 各項目は一文で言い切り、解釈の余地を残さない書き方にしてください。
- 判断できない項目は「要確認」と明記してください。

仮名化の手順書を作らせるときは、判断を挟ませない形に固定します。

以下の文書種別について、生成AIへ入力する前の仮名化手順を作成してください。

【文書種別】
（顧問契約書、申告書控え、就業規則、相談メモ など。実物は貼らない）

条件:
- 置換対象を列挙してください（人名、法人名、住所、電話番号、口座番号、
  生年月日、案件番号、固有の金額 など）。
- 置換後の表記ルールを決めてください（例: 法人名はA社、B社の順に割り当てる）。
- 作業者が判断に迷う余地を残さないでください。迷う可能性がある箇所は
  「有資格者に確認」と明記してください。
- 置換漏れを検出するためのチェック手順を最後に付けてください。

出力された手順書は、実際の文書で一度試してから運用に載せます。机上で作った手順は、実物の書式に当たると穴が見つかります。

補足として、階層をまたぐ引き継ぎの設計も決めておきます。補助者が仮名化して入力し、出てきた下書きを有資格者が確認するとき、有資格者は元の原文と突き合わせる必要があります。仮名化した対応表を誰が持ち、どこに保管し、いつ破棄するのか。この対応表そのものが秘密情報の塊になるため、扱いを決めずに運用すると、仮名化した意味が薄れます。案件終了時に対応表を破棄する工程を、案件のクローズ手続きに組み込んでいる事務所があります。

出力の記録についても、粒度を先に決めておくほうが続きます。すべての対話を残す運用は現実には維持できません。成果物として外へ出た文書について、どのAIを使い、誰が採否を判断したかだけを残す形であれば、日々の業務の中でも回ります。記録の目的は監視ではなく、後から説明できる状態を作ることです。この目的を共有しておかないと、記録の作業だけが形骸化して残ります。

職種ごとに異なる守秘義務の根拠と、無資格者の扱い

権限設計を規程に落とすとき、根拠となる条文は職種ごとに別々の法律に置かれています。ここを1つにまとめて書くと、実務では使えない規程になります。

弁護士法第23条は、弁護士または弁護士であった者が職務上知り得た秘密を保持する権利を有し義務を負うと定め、法律に別段の定めがある場合を除く旨の但書を置いています。税理士法第38条は、税理士が正当な理由がなくて税理士業務に関して知り得た秘密を他に洩らし、または窃用してはならないと定めています。司法書士法第24条、行政書士法第12条、社会保険労務士法第21条、弁理士法第30条にも、それぞれ秘密を守る義務の規定が置かれています。

条文の文言は職種ごとに違います。正当な理由という要件を置く法律もあれば、正当な事由と書く法律もあり、対象を業務上取り扱った事項とするか、知ることのできた秘密とするかも一致しません。複数の資格者が在籍する事務所では、規程の根拠条文を職種ごとに並べて書くほうが、後から参照しやすくなります。

無資格の補助者や事務員については、これらの条文が直接適用される構造にはなっていません。だからこそ、事務所側の設計で埋める必要が出てきます。手当てとして実務で使われているのは、雇用契約や就業規則での秘密保持条項、入所時の誓約書、そして生成AI利用に関する個別の同意書です。第5階層の外部委託先については、委託契約に情報の取扱いを明記する形が中心になります。

個人情報を含む文書を扱う場面では、個人情報保護法第24条が従業者の監督を、同法第23条が安全管理措置を定めています。個人情報保護委員会は法令とガイドラインを公式サイトで公開しており、安全管理措置の具体的な内容はガイドラインの通則編に整理されています。事務所の規程で階層別の権限を書くときは、この安全管理措置の枠組みに接続する形にしておくと、監査や顧問先への説明のときに一貫した説明ができます。

生成AIへの個人データの入力については、個人情報保護委員会が2023年6月2日付で注意喚起を公表しています。個人情報取扱事業者があらかじめ本人の同意を得ることなく生成AIサービスに個人データを含むプロンプトを入力し、当該個人データがプロンプトに対する応答結果の出力以外の目的で取り扱われる場合、法違反となる可能性があるという内容です（出典: 個人情報保護委員会 生成AIサービスの利用に関する注意喚起等）。この指摘は階層に関係なく効くため、第3階層以下に仮名化を義務づける設計の根拠として使えます。

顧問先への説明では、事務所の中で誰がどこまでAIを使うのかを、階層の言葉で伝えるほうが伝わります。担当者だけが使いますという説明より、原文を入力できるのは有資格者のみで、補助者は仮名化後の文書しか扱いませんという説明のほうが、確認する側も検証しやすくなります。

階層設計でつまずく4つのパターン

1つ目は、階層を作ったのにアカウントが分かれていないケースです。規程の表では第3階層が仮名化必須になっているのに、全員が同じ組織アカウントで同じワークスペースを見ている。この状態では、規程は自己申告に頼る運用になります。回避策は、階層に対応するグループやワークスペースを、ツール側で先に作ることです。

2つ目は、兼務を高いほうの階層に寄せてしまうケースです。事務所によっては、事務員が特定の案件の補助も担っています。この人を第3階層に置くと、総務の業務でも案件用の権限が付いたままになります。回避策は、人ではなく業務単位で階層を割り当て、使うワークスペースを業務ごとに切り替えさせることです。

3つ目は、例外の扱いを決めていないケースです。締切直前に、補助者が原文のまま入力しないと間に合わない場面が出てきます。申請の経路がないと、その場の判断で例外が生まれ、記録も残りません。回避策は、例外申請を口頭でも受け付ける代わりに、事後に記録を残す様式を用意することです。

4つ目は、私物の端末やアカウントでの利用を放置するケースです。階層設計は事務所が管理するアカウントの中でしか効きません。管理外の利用が並行して起きていれば、設計は形だけになります。この問題の対処は事務所のシャドーAI・私物利用への対策で整理しました。

5つ目として、階層を作ったあと誰にも周知しないケースがあります。規程が共有フォルダに置かれているだけで、日々の作業をする人が自分の階層を認識していない状態です。回避策は、階層の定義を1枚にまとめ、入所時の説明と定期点検の両方で読み合わせることです。文書量を増やすより、1枚に収めて全員が同じものを見る形のほうが定着します。

なお、階層設計は事務所の人数が少ないほど省略されがちですが、少人数ほど兼務が多く、権限の境界が曖昧になりやすい構造があります。所長と事務員だけという構成でも、事務所内部の業務と案件情報を扱う業務でワークスペースを分ける意味は残ります。人数ではなく、扱う情報の性質の違いが分ける理由になります。

いずれも、規程の文言ではなく実装の抜けから起きます。書いた階層がツール側の設定と一対一で対応しているかを、点検の項目に入れておくと防ぎやすくなります。

費用と工数、誰がこの設計を持つか

費用は、組織向けプランへの切り替えとアカウント数で決まります。階層ごとにワークスペースを分ける構成を取ると、管理機能を持つプランが前提になります。料金は各社とも随時変わるため、この記事では金額を挙げず、公式サイトでの確認を前提とします。

工数は、初回の設計と、その後の維持で性質が変わります。初回は、人員の階層割り当て、アカウントの整理、仮名化手順の作成で、事務所の規模にかかわらずまとまった時間がかかります。ここを事務局に丸投げすると、判断を要する部分で止まります。有資格者が階層の定義だけを決め、割り当てとアカウント整理を事務局が進める分担が現実的です。

維持の工数は、人の出入りに連動します。採用と退職のたびに、階層の割り当てとアカウントの権限を更新します。入所と退所の手続きに、AI環境の権限付与と削除を組み込んでおくと、抜けが減ります。退職者のアカウントが残っている状態は、階層設計そのものを無効にします。

AIエージェントに事務所のシステムを操作させる構成まで進む場合は、人の階層とは別に、エージェント側の権限設計が必要になります。この論点はAIエージェントの権限管理 事務所が最小権限を回す6工程と拒否ルールで扱っています。人の権限とエージェントの権限を同じ表に混ぜると、どちらの設計も曖昧になります。

階層の粒度は、AIの自律性が上がるほど細かくなる

今後の論点は、AIの自律性が上がるにつれて、階層の設計が人だけでは足りなくなることです。

いまの階層設計は、人が入力し人が出力を受け取る前提で組めます。ところが、AIが事務所のシステムを直接読み書きする構成が入ると、誰の権限で動いているのかという問いが生まれます。補助者が起動したエージェントが、有資格者しかアクセスできない領域を読めてしまえば、階層は迂回されます。国が示すガイドラインの読み解きはAI事業者ガイドライン第1.2版 士業事務所の規程に落とす7項目とAI介在設計で整理しました。

もう1つは、階層の説明責任が外へ出ていく流れです。顧問先が自社のAIガバナンスを整えるほど、委託先である事務所の体制も確認の対象になります。誰がどこまで使えるのかを説明できる状態は、いずれ受注条件の一部になっていきます。

設計の出発点は、いまの事務所の職責をそのまま書き出すことです。生成AIのために新しい組織を作る必要はありません。すでにある指揮監督の関係を、ツールの設定として写し取れるかどうかが、この設計の実質です。

よくある質問

事務員に生成AIを使わせてよいですか

事務所の判断で決める事項です。使わせる場合は、扱える情報の範囲を先に決めるのが実務的です。事務所内部の定型業務に限定し、顧問先の固有名詞を含む入力を行わない設計にしている事務所があります。個人情報保護法第24条は従業者の監督を定めており、範囲を決めずに使わせる運用は、この監督の設計と噛み合いにくくなります。

補助者には仮名化を義務づけるべきでしょうか

義務づけている事務所があります。理由は、原文の入力可否の判断が、案件の内容と顧問先との合意に依存するためです。判断を要する工程を有資格者に残し、作業を要する工程を補助者に渡す切り分けが、責任の所在をはっきりさせます。仮名化の手順書は、判断を挟ませない書き方にするのが要点です。

無資格の職員に守秘義務の法律上の根拠はありますか

各士業法の秘密保持規定は、原則としてその資格者を名宛人としています。無資格の職員については、雇用契約や就業規則の秘密保持条項、入所時の誓約書、個別の同意書といった契約上の手当てで補うのが一般的な実務です。事務所として何を根拠に何を求めるのかを、書面で整理しておく形が取られています。

階層を分けると業務が回らなくなりませんか

回らなくなる場面が出るのは、例外の経路を用意していない場合です。締切直前や、担当者が不在のときに、階層を超えた作業が必要になります。事前の許可ではなく事後の記録で運用する例外経路を作っておくと、業務を止めずに記録を残せます。

ワークスペースはどこまで分けるべきですか

案件情報を扱う領域と、事務所内部の業務を扱う領域を分けるのが最小構成です。さらに、利益相反が問題になり得る案件どうしを分ける必要が出る場合があります。東京弁護士会の特集は、事件が係属している間は当該事件の情報をAIに学習させない、あるいは入力自体を制限する運用を挙げています（出典: 東京弁護士会 LIBRA Vol.26 No.7-8 特集）。

外部委託先にAI環境を使わせてもよいですか

原則として与えない設計にしている事務所があります。必要な場合は、委託契約に情報の取扱いを明記し、対象となる案件と期間を限定する形が取られます。委託先の再委託の有無も、確認事項に入ります。

権限設定はどのくらいの頻度で見直せばよいですか

人の異動があったときと、定期の点検日の両方で見直す形が続けやすくなります。定期点検を半年ごとに置いている事務所があります。サービス側の仕様や管理機能は事務所への告知なく変わることがあるため、設定画面を実際に開き直す工程を点検に含めておきます。

参考文献

• e-Gov法令検索 個人情報の保護に関する法律
• 個人情報保護委員会 生成AIサービスの利用に関する注意喚起等
• 個人情報保護委員会 法令・ガイドライン等
• e-Gov法令検索 税理士法
• e-Gov法令検索 社会保険労務士法
• 東京弁護士会 LIBRA Vol.26 No.7-8 特集 弁護士業務における生成AIの利活用と留意点

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