AIガバナンスの議論は、方針文書の整備に寄りやすい。しかし実際に事故が起きるのは文書の外側、つまり実装の細部である。どのデータがどこへ流れ、AIがどの権限で何を実行し、誤った出力が誰の確認も経ずに反映されるか。ここが設計されていなければ、方針文書が何ページあっても結果は変わらない。
本記事では、業務システムに生成AIを接続する際に設計すべき制御点を6つに整理する。実際に起きた事故の類型については「生成AIの事故事例2025-2026」で扱っている。
この記事の対象読者
- 生成AIやAIエージェントを社内システムに接続する設計を担う情報システム部門・開発部門の方
- AI利用ルールを策定したが、実装レベルに落ちているか不安がある推進担当者の方
- ベンダーの提案するAI構成をセキュリティ観点で評価する必要がある方
AIガバナンスは文書ではなく実装で決まる
方針文書と実装の間には、典型的なギャップが3つある。
| 文書上の記述 | 実装で問われること |
|---|---|
| 「機密情報を入力しない」 | 何が機密かを誰が判定するか。判定を人の注意力に依存していないか |
| 「出力は必ず確認する」 | 確認しないと次に進めない仕組みがあるか。確認の記録は残るか |
| 「適切な権限で運用する」 | AIに付与した権限は具体的に何か。人間の権限をそのまま渡していないか |
左列は守れているかを検証できない。右列は設計として存在するかどうかを確認できる。ガバナンスの実効性は、検証可能な形に落ちているかで決まる。
実装時に設計する6つの制御点
| 制御点 | 設計する内容 | 主な失敗 |
|---|---|---|
| 1. データ境界 | どのデータがどの環境まで出るか | 契約上の制限と実装が食い違う |
| 2. 権限設計 | AIに与える実行権限の範囲 | 人間の権限をそのまま委譲する |
| 3. 入力の信頼境界 | 外部由来のテキストの扱い | 取り込んだ文書の指示に従ってしまう |
| 4. 出力の検証 | 人が確認する地点と方法 | 確認が任意になっていて省略される |
| 5. 監査ログ | 何を、いつまで、誰が見られるか | 事後に経緯を再現できない |
| 6. モデル更新 | 更新の判断と再検証の手順 | 挙動が変わったことに気付かない |
1. データ境界
最初に確定させるのは、どのデータがどこまで出るかである。判断は業務単位で行う。全社一律のルールにすると、厳しすぎて使えないか、緩すぎて守れないかのどちらかになる。
確認すべきは次の3点である。
- 契約・規程上の制約：顧客との契約に第三者提供の制限があるか。業界規制で越えられない境界があるか
- 実際の経路：APIの送信先、ログの保存先、ベンダーの再委託先まで含めて、データが物理的にどこへ行くか
- 学習利用の有無：入力データが提供元のモデル学習に使われる設定になっていないか
制約が越えられない場合、自社環境で完結する構成が選択肢になる。判断材料は「オープンウェイトモデルとは？定義とライセンスの読み方」で整理している。
2. 権限設計
AIエージェントが社内システムを操作する構成では、ここが最大の論点になる。よくある実装は、担当者のアカウント権限をそのままAIに渡すものである。これは避けるべきである。
理由は2つある。第一に、人間は「やらない判断」を常時行っているが、AIにその抑制は期待できない。第二に、権限を共有すると監査ログ上で人とAIの操作が区別できなくなる。
設計の原則は次のとおりである。
- AI専用の実行主体を作る：人間のアカウントを使い回さない。ログ上で必ず区別できるようにする
- 付与するのは操作単位の権限：「参照のみ」「特定テーブルへの追記のみ」といった粒度で切る。ロールをそのまま当てない
- 不可逆な操作を除外する：削除、送信、決裁、支払い。これらは権限から外し、人間の実行に限定する
- 段階的に広げる：最小権限から始め、運用実績を見て必要な範囲だけ追加する
最初から広く付与して後で絞る運用は、実務上ほぼ機能しない。絞る作業には業務を止めるリスクがあるため、先送りされ続ける。
3. 入力の信頼境界
生成AIは、指示とデータを同じテキストとして受け取る。この性質から、外部由来の文書に含まれる文言が指示として解釈される事象（プロンプトインジェクション）が起きる。
問題になるのは、次のような構成である。
- 受信メールの本文をAIに要約させ、その結果に基づいて処理を分岐させる
- Webページを取得してAIに読ませ、内容に応じて社内システムを操作させる
- 顧客が提出したファイルをAIに解析させ、出力を台帳へ反映する
いずれも、外部から持ち込まれたテキストがAIの動作に影響する経路を持つ。実装上の対応は次のようになる。
- 外部由来のテキストは常にデータとして扱う：取り込んだ内容に書かれた指示を実行しない前提で設計する
- 取り込みと実行を分離する：外部データを読む処理と、権限を伴う操作を行う処理を別の実行主体に分ける
- 副作用のある操作は人の承認を挟む：外部入力を起点とする処理で、送信・更新・決裁を自動実行しない
- 出力を次の入力にそのまま渡さない：連鎖する構成では、途中で検証を挟む
完全な防御は現時点で確立していない。「防ぎきる」ではなく「影響範囲を限定する」設計が現実的である。
4. 出力の検証
検証は、任意にすると省略される。工程として組み込む必要がある。
設計の要点は、業務ごとに検証の厚みを変えることである。一律の厳格なルールは、守られないか、効果を消すかのどちらかになる。
| 出力の用途 | 検証の水準 |
|---|---|
| 社内向けの下書き・要約 | 利用者本人の確認で足りる |
| 社外提出物・顧客向け文書 | 別の担当者による確認を必須にする |
| 引用・数値・法令・判例を含む文書 | 出典に当たった確認を必須にする。未確認のまま提出させない |
| 法的効果を持つ文書、金銭的責任が生じる回答 | AIの自由生成を使わず、定型回答か人の作成に限定する |
Deloitteの豪州政府向け報告書や、米国の弁護士に対する制裁は、いずれもこの検証工程の欠落によって起きている。事例の詳細は「生成AIの事故事例2025-2026」を参照されたい。
検証工数を削減効果の試算に含めることも実務上重要である。含めずに見積もると、実際の削減率が試算を下回る。試算の手順は「AIアセスメントとは？業務棚卸しと投資対効果の設計」で解説している。
5. 監査ログ
事故が起きたとき、経緯を再現できるかどうかで対応の質が決まる。記録すべき項目は次のとおりである。
- 実行主体（人間かAIか、どのAI実行主体か）
- 入力（プロンプトと、参照したデータの識別子）
- 使用したモデルとバージョン
- 出力
- 後続の操作（何を更新したか、誰が承認したか）
設計上の判断が要るのは保存期間とアクセス権限である。プロンプトには業務データが含まれるため、ログ自体が保護対象になる。誰がログを閲覧できるかを決めずに記録だけ始めると、ログが新たな漏洩経路になる。
6. モデル更新
モデルが更新されると、同じプロンプトでも挙動が変わる。APIサービスでは提供側の都合で更新・廃止が起きる。
必要なのは次の3点である。
- バージョンの記録：どの業務がどのモデルバージョンで検証済みかを管理する
- 再検証の基準：更新時に何を確認すれば運用継続と判断できるかを、業務ごとに定めておく
- 切り戻しの手段：更新後に問題が出た場合、従来の運用に戻せる経路を残す
自社環境でバージョンを固定する選択もあるが、その場合はセキュリティ修正を取り込む責任が自社に移る。固定は放置ではない。
ガイドラインとの関係
国内では、経済産業省・総務省が「AI事業者ガイドライン」を公表し、AIの開発者・提供者・利用者それぞれの立場に応じた指針を示している。専門職団体でも整備が進んでおり、東京弁護士会は2025年3月27日に「弁護士業務における生成AIサービスの適正利用ガイドライン」を施行し、出力を業務に用いる際の一次資料確認を推奨している。
これらの文書は「何を守るべきか」を示すが、「どう実装するか」は各社の設計に委ねられている。本記事の6つの制御点は、その実装側の設計項目にあたる。ガイドラインへの準拠を宣言することと、準拠を実装で担保することは別の作業である。
FDXの支援
FDX株式会社は、AIの業務適用を設計段階から支援している。ガバナンスは、適用範囲の設計と一体で決まる。
- 1Day AIアセスメント：業務ごとにAI対応可能性を判定する際、データの所在・検証の要否・セキュリティ要件を条件として明示する
- 1Day FDE：FDE（Forward Deployed Engineer）が週1日常駐し、権限設計・検証工程・ログ設計を実装に落としたうえで現場に定着させる
よくある質問（FAQ）
Q1. AI利用ルールの文書を整備すれば、ガバナンスは成立するか？
A. 文書だけでは成立しない。「機密情報を入力しない」「出力は必ず確認する」といった記述は、守られているかを検証できない。実効性を持たせるには、判定を人の注意力に依存させない仕組み、確認しないと次に進めない工程、記録が残る設計が必要になる。文書は必要条件であって十分条件ではない。
Q2. AIエージェントに社内システムの操作権限を与えても安全か？
A. 権限の切り方による。担当者のアカウント権限をそのまま渡す実装は避けるべきである。AI専用の実行主体を作り、操作単位で最小限の権限を付与し、削除・送信・決裁・支払いといった不可逆な操作は権限から外して人間の実行に限定する。最初から広く付与して後で絞る運用は、絞る作業に業務停止リスクが伴うため先送りされ、実務上ほぼ機能しない。
Q3. プロンプトインジェクションは技術的に防ぎきれるか？
A. 現時点で完全な防御手法は確立していない。前提は「起こり得る」であり、設計方針は影響範囲の限定に置く。外部由来のテキストを常にデータとして扱い、取り込み処理と権限を伴う操作を別の実行主体に分離し、副作用のある操作には人の承認を挟む。この3点で、成立しても被害が限定される構成になる。
Q4. 監査ログはどこまで記録すべきか？
A. 事故時に経緯を再現できる水準が基準となる。実行主体、入力プロンプトと参照データの識別子、モデルとバージョン、出力、後続操作と承認者が最低限の項目である。同時に、プロンプトには業務データが含まれるためログ自体が保護対象になる。保存期間と閲覧権限を決めずに記録だけ始めると、ログが新たな漏洩経路になる。
Q5. クラウドAPIを使う場合、入力データが学習に使われないか確認する方法は？
A. 提供元の利用規約と、アカウント・契約プランごとの設定を確認する。法人向けプランでは学習利用を行わない設定が既定になっていることが多いが、プランや契約形態によって異なり、規約は改訂される。導入時の確認で終わらせず、契約更新やプラン変更のタイミングで再確認する運用が必要である。あわせて、ログの保存先とベンダーの再委託先まで含めてデータ経路を把握する。
Q6. ガイドラインに準拠していると宣言するには何が必要か？
A. 準拠の宣言と、準拠を実装で担保することは別の作業である。ガイドラインは何を守るべきかを示すが、実装方法は各社の設計に委ねられている。宣言の裏付けとするには、本記事の6つの制御点それぞれについて、自社の実装がどうなっているかを文書化し、検証可能な形にしておく必要がある。第三者から問われた際に、設計として存在することを示せるかどうかが基準になる。
次に読むべき記事
まとめ
- AIガバナンスの実効性は、方針文書ではなく実装が検証可能な形になっているかで決まる
- 設計すべき制御点は6つ。データ境界、権限設計、入力の信頼境界、出力の検証、監査ログ、モデル更新
- 権限設計では、人間のアカウントを流用せずAI専用の実行主体を作り、操作単位で最小権限を付与する。削除・送信・決裁・支払いは権限から外す
- プロンプトインジェクションは防ぎきれない前提で、取り込みと実行の分離、副作用操作への人の承認で影響範囲を限定する
- 出力の検証は業務ごとに厚みを変える。一律の厳格なルールは守られないか効果を消すかのどちらかになる
- 監査ログは事故時の再現可能性が基準。同時にログ自体が保護対象であり、閲覧権限を先に決める
- ガイドラインは「何を守るか」を示すが「どう実装するか」は各社の設計に委ねられている。宣言と実装での担保は別の作業
AI実装のガバナンス設計を相談する
適用範囲の設計と、権限・検証・ログの実装までを一体で支援します。
実装体制のご相談は、お問い合わせからご連絡ください。
出典・参考文献
- 経済産業省・総務省「AI事業者ガイドライン」
- 独立行政法人情報処理推進機構（IPA）「AI利活用におけるセキュリティ」関連資料
- 東京弁護士会「弁護士業務における生成AIサービスの適正利用ガイドライン」（2025年3月27日施行）
- OWASP「Top 10 for Large Language Model Applications」