結論: 組織でAIを使う場合は、誰が使ったか（AUTH）、何へアクセスできるか（ACCESS）、何を実行したか確認できるか（AUDIT）を、用途とリスクに応じて設計します。三層という名称はShigyoAIの整理であり、法令が定める唯一の基盤構成ではありません。
個人利用と組織利用で変わること
組織利用では、本人の記憶だけに頼らず、アカウント、権限、承認、変更、退職時の回収を管理します。AIの利用を全面禁止するか、必ず導入するかの二択ではありません。対象業務、扱う情報、契約、内部統制を確認し、利用しない業務と利用する業務を分けられます。
本記事は、認証・権限・ログがなければ特定の事故が必ず起きると主張するものではありません。事故時の調査可能性と、平時の権限制御を高めるための点検モデルです。
AUTH — 利用者と実行主体を識別する
人と自動処理を区別できるようにします。
- 職員ごとに個別アカウントを発行する
- 共有IDを避け、必要に応じてSSO・MFAを使う
- 自動処理には人のアカウントを流用せず、専用のサービスIDを使う
- 入社、異動、退職、委託終了時の発行・変更・失効を手順化する
- 緊急停止と管理者復旧の手順を確認する
SSOを使えばすべてのAPIキーや外部アカウントが自動失効するとは限りません。失効の挙動はサービスごとに実測します。
ACCESS — 必要なデータと操作だけを許可する
最小権限を、AI経由のアクセスにも適用します。
- 顧客・案件・部門単位で参照できるデータを分ける
- 読み取り、生成、書き込み、送信、削除の権限を分ける
- AIの出力を顧客へ送る工程には、人の承認を置く
- RAGや検索では、取得前に利用者の権限を評価する
- 顧客Aの情報が顧客Bの処理へ混ざらないか、架空データで試験する
「顧客IDを分ければ情報混入が起きない」とは限りません。検索インデックス、キャッシュ、ログ、外部転記先も含めて分離を検証します。
AUDIT — 後から事実を確認できる記録を残す
ログ項目は用途と法令・契約に合わせて決めます。候補は次の通りです。
- 利用者IDまたはサービスID
- 実行日時
- 利用したサービス・モデル・機能
- 対象顧客・案件
- 実行した操作と結果
- 参照した情報の出典または識別子
- 承認者、訂正、差し戻し
- 権限チェックと失敗理由
入力・出力本文をすべてログへ複製すると、ログ自体が新たな機密情報の保管場所になります。目的に必要な範囲、マスキング、アクセス権、暗号化、削除を設計します。
保存期間は「一律3年」「一律7年」と決めません。対象記録に適用される法令、受任契約、紛争対応、内部統制、個人情報の最小化を確認し、記録種別ごとに決めます。第三者提供記録等の保存義務を、すべてのAIログへそのまま転用しないことが重要です。
DETECTとSTEP-UPは追加統制の例
リスクに応じて、異常検知（DETECT）や追加認証（STEP-UP）を組み合わせられます。
- 通常と異なる大量取得や権限失敗を検知する
- 顧客への送信、大量エクスポート、権限変更に追加承認を要求する
- 検知ルールの誤警報・見逃しを記録し、見直す
- 追加認証で保護する操作と、操作自体を禁止する範囲を分ける
翌朝確認で足りるか、即時停止が必要かは、操作の影響と復旧可能性で判断します。
事故例ではなく、試験すべき失敗経路
次はShigyoAIが顧客事務所で観測した事故ではなく、設計時に試験する仮想シナリオです。
- 退職者のアカウントまたはAPIキーでアクセスできてしまう
- 別顧客の情報が検索結果や出力へ混ざる
- 顧客から利用状況を問われても、入力・出力・承認を追えない
- AIが誤った内容を書き込み、変更者と戻し方が分からない
- ログに機密情報が集中し、過剰な閲覧権限が残る
テストでは、発生有無だけでなく、検知、停止、調査、復旧、報告判断まで実行します。
既存製品を組み合わせるとき
SSO、SCIM、監査ログ、API、権限制御の提供範囲は、製品・プラン・契約で異なります。「法人版なら監査ログをAPI取得できることが多い」といった一般論だけで構成を決めず、公式仕様と実環境で確認します。
導入前に、次を証拠として残します。
- 契約プランと確認日
- 管理画面の設定値
- テスト用アカウントでの権限試験
- ログに記録された実行結果
- アカウント停止後のアクセス試験
- バックアップと復旧試験
関連記事
参考
本記事は一般的なセキュリティ設計の情報です。ShigyoAIの実装実績、事故発生率、特定の相談サービスや成果を示すものではありません。