結論: 個人で商用AIチャットツールを使うことと、組織でAIを運用することは、別の設計問題です。後者には認証・権限管理・監査ログの三層基盤が必要で、これを欠いた状態でのAI導入は、事故が起きたときに説明責任を果たせなくなります。
個人利用と組織運用の間にある壁
所員が一人で商用AIチャットツールに質問することと、事務所としてAIを業務に組み込むことは、同じ「AIを使う」という言葉でも要件がまったく異なります。個人利用であれば、自分が何を入力したかは自分が覚えていれば足ります。一方、組織運用では、誰が、いつ、どのAIに、何を入力し、何が出力されたかを、案件単位で追跡できる構造を持っていないと、事故が起きたときに説明責任を果たせません。
特に士業事務所の場合は、守秘義務 (税理士法38条、弁護士法23条、社労士法21条) が業務の前提にあるため、「うちの所員が個人のAIに顧客情報を入力していました」という事態は、そのまま業務停止リスクに直結します。これを避けるには、個人利用を禁止するか、組織としてAIを運用する基盤を整備するかの、どちらかを選ぶ必要があります。
実際のところ、禁止する選択肢は持続しません。隣の事務所がAIで業務効率化を進めているなかで、自事務所だけ禁止していると、採用面でも顧問先からの評価面でも不利になっていきます。ですから、組織運用の基盤を整備する方向に進むことになります。本記事では、ShigyoAIが士業事務所で設計してきたAUTH / ACCESS / AUDIT三層基盤の指針を整理しておきます。
AUTH — エージェントID認証の層
AUTHは、誰がAIを使っているのかを技術的に識別する層です。個人アカウントのAIチャットツールを所員に配ってしまうと、誰がどのアカウントを使っているのかが時間とともに分からなくなっていきます。退職時のオフボーディングも追えません。共有IDで運用してしまうと、監査ログ自体が成立しなくなります。
組織運用の基本は、シングルサインオン (SSO) 経由でのアカウント発行と回収です。業務統合型グループウェアのアカウントとAIツールを連携させて、入社時に自動発行、退職時に自動無効化する構造にすると、「誰がAIを使っているか」は組織として常時把握できる状態になります。
加えて、AIエージェントがAPI経由で他のシステムを操作する場合は、エージェント自体にIDを発行しておきます。例えば、月次決算の集計を行うAIエージェントには「monthly-report-agent」のような識別子を与えて、そのエージェントが業務系SaaSのAPIを叩いた、別の業務系SaaSからデータを取得した、といった履歴をID単位で残します。人間の所員IDとエージェントIDを分離しておくことで、「人が直接やったのか、自動化された処理が動いたのか」を後から区別できるようになります。
ACCESS — アクセス権限管理の層
ACCESSは、認証されたユーザーが何にアクセスしてよいかを管理する層です。全所員が全顧客のデータにAIでアクセスできてしまう状態は、守秘義務上も内部統制上も問題があります。顧客Xの担当チームだけが顧客XのデータにAIでアクセスできる、という最小権限の原則を、AI利用にも適用する必要があります。
具体的な設計の一つが、顧客ID単位でのアクセス権限です。顧問先A社のデータはA社担当チームのみがAIで参照可能、B社のデータはB社担当チームのみ、といった分離を技術的に実装します。AIが他社の情報を出力に混入させないように、RAG (検索拡張生成) のデータソース選択もチーム単位で制御していきます。
もう一つは、業務工程単位での権限分離です。月次集計まではAIが自動で行えるけれども、顧客への提案文書ドラフトの生成は担当者ロールが必要、申告書の最終チェックは税理士ロールが必要、といった段階的な権限を設計します。こうしておくことで、AIが暴走した場合でも影響範囲が限定される構造になります。
AUDIT — 監査ログの層
AUDITは、誰が、いつ、どのAIに、何を入力し、何が出力されたかを記録しておく層です。これは事故時の説明責任、規制当局対応、内部統制の三点を支える基盤になります。
最低限のログ項目として、ShigyoAIが推奨しているのは次の七項目です。(1) 利用者IDまたは エージェントID、(2) タイムスタンプ、(3) 使用したAIモデルとバージョン、(4) 入力プロンプトの概要 (個人情報をマスキングしたうえで)、(5) 出力結果の概要、(6) 関連する顧客IDまたは案件ID、(7) 権限チェックの結果。これらを案件単位で集約できる構造で保持しておきます。
保持期間に法令上の一律義務があるわけではありません。個人情報保護法はむしろ、利用の必要がなくなった個人データの消去を求める方向の法律です (法22条の消去努力義務)。ログの保持期間は、各事務所が説明責任を果たすために必要な期間を基準に設定します。参考として、第三者提供の記録は原則3年 (書面記載時は1年・法29条および施行規則) の保存が別途義務づけられており、内部統制 (SOX系) の文脈では7年が一つの目安とされます。士業業務の場合は、顧問契約期間中に加えて、契約終了後の説明責任期間も考慮して、案件単位で保存期間を設定しておきます。ログ自体が個人情報を含むため、ログのアクセス権限管理も同じ三層で行う必要があります (= ログが新たな情報漏洩源にならないようにするためです)。
並列レイヤー — DETECTとSTEP-UP
三層のAUTH / ACCESS / AUDITに加えて、二つの並列レイヤーを重ねるのがShigyoAIの標準設計です。
DETECTは異常検知です。同じ所員が短時間に異常な量のデータをAIに入力した、通常はアクセスしない顧客のデータにAI経由でアクセスがあった、業務時間外にAIが大量の出力を生成した、といった異常を継続的にモニタリングします。リアルタイムで止める必要はありませんが、翌朝のレポートで把握できる構造にしておきます。
STEP-UPは追加認証です。通常業務はSSOの一段階認証で進められるようにしておいて、顧客の最終的な申告書を出力する、大量のデータをエクスポートする、といった重要な操作には二段階目の認証を要求します。こうしておくことで、認証情報が漏れた場合でも、重要操作だけは追加の壁で守られるようになります。
三層を欠いた状態の典型的な事故
三層基盤がない状態でAIを業務導入してしまうと、次のような事故が観測されています。
第一に、退職者のAIアカウントが残ったままになっていて、退職後に元所員が顧客データにアクセス可能だった事例です。アカウント発行と回収が組織的に管理されていないと、この種の事故は必ず起きます。AUTH層の欠如によるものです。
第二に、所員が誤って他社の顧客データをAIに入力してしまい、別の顧客向け文書に他社の情報が混入した事例です。案件単位のデータ分離が技術的に実装されていないと、担当者の注意力だけで防ぐことになり、確率的に必ず発生します。ACCESS層の欠如によるものです。
第三に、顧客から「うちの情報をAIに入れましたか」と問われた際に、過去の利用履歴が追えず、否定も肯定もできなかった事例です。監査ログがない状態だと、信頼が必要な場面で証明手段を持てません。AUDIT層の欠如によるものです。
これらは技術的には予防可能ですが、後から追加しようとすると事故対応の中で行うことになり、コストも信用ダメージも大きくなります。ですから、AI導入の初期段階で三層基盤を設計しておくことが重要になります。
既存ツールとの組み合わせ方
三層基盤を全部自前で実装する必要はありません。既存のクラウドサービスを組み合わせていくと、多くの部分はカバーできます。
AUTHは、業務統合型グループウェアのSSOを中心に据えて、商用AIチャットツールの法人版や、業務統合型グループウェアに組み込まれたテナント統合型AIなどを連携させていきます。個人版ではなく組織版を契約することが前提になります。
ACCESSは、各AIツールの組織内権限設定と、RAGを組む場合のデータソース分離設計で実装していきます。顧客データを置く場所 (組織のクラウドストレージ、自社サーバー等) のアクセス権限を整理したうえで、AIツールがどこを参照するかを設計します。
AUDITは、各AIツールが提供する管理者ログを中央のログ管理システムに集約しておきます。商用AIチャットツールの法人版やテナント統合型AIは監査ログをAPIで取得可能なことが多いので、これをSIEM (セキュリティ情報イベント管理) や独自のログ基盤に流していきます。
これらの統合と、業務フローに合わせた権限設計、監査ログの活用方法は、事務所ごとに大きく異なります。ShigyoAIではこの設計と実装、運用までを一気通貫で伴走しています。
関連記事
- 三層基盤がなぜFDEモデルと結びつくかは 士業事務所のためのFDEモデル で整理しています。
自事務所の基盤設計を60分で相談する
三層基盤の設計は、既存の業務フローと組み合わせて初めて意味を持ちます。ShigyoAIでは60分の初回相談で、自事務所に最適化した基盤設計の方向性をお示ししています。受注前提ではなく、整理だけして社内検討に戻していただく形でも構いません。