【2025年最新】AIインベントリの作り方｜監査リスクを1週間で解消する実践手順
本記事のポイント
- AIガバナンスは「何を使っているか」の把握から始める
- AIインベントリ（台帳）は監査・事故対応・調達管理の共通言語
- 最小項目と更新運用を決めれば、1週間で運用可能な仕組みを構築できる
なぜ今、AIインベントリが必須なのか
結論：AIを安全に活用するには「現状把握」が最短ルートです。
AIは導入が容易な反面、部署単位でツールやAPI利用が急増しやすく、気づいた時には「どこで、誰が、何のデータを入れて、どんな判断に使っているか」が把握できない状態に陥ります。
"見えないAI"が引き起こす4つのリスク
1. 情報漏えい
機密や個人情報を意図せず外部AIに入力してしまい、データ流出のリスクが高まります。
2. 監査対応の失敗
判断根拠、ログ、承認プロセスが説明不能となり、監査で指摘を受けます。
3. 品質事故
誤った回答を前提に業務が進行し、クレームや損失が発生します。
4. 調達の混乱
ベンダーやSaaSが無秩序に増加し、契約条件や責任分界が不明確になります。
政府のガイドラインでも、リスクの大きさに応じて対策を変える「リスクベースアプローチ」の重要性が示されています。しかし、リスクを測定するには対象が可視化されている必要があります。そこで、AIインベントリ（台帳）が土台となるのです。
基本用語の整理
| 用語 | 定義 |
|---|---|
| AIインベントリ(台帳) | 社内で利用しているAI（ツール・API・モデル・業務機能）を一覧化し、責任者・データの扱い・リスクなどを管理する表 |
| ユースケース | AIを「何の業務目的で、どんな入力を与え、どんな出力を、誰がどう使うか」という利用単位 |
| リスクベースアプローチ | 影響の大きさや発生確率に応じて、対策の強度を変える考え方 |
| AIマネジメントシステム | 組織としてAIの方針・目的・プロセスを整備し、継続改善する枠組み（ISO/IEC 42001として国際標準化） |
| AI RMF | NIST（米国標準技術研究所）が公開するAIリスク管理フレームワーク |
AIインベントリ構築の3ステップ
Step 1. 「AI利用」の定義と棚卸し対象の決定ツール利用・API・組み込み機能まで含めて範囲を明確化Step 2. 台帳の「最小項目」設計と1週間での完成完璧を求めず、まず動く形を作るStep 3. 更新ルールを業務フローに組み込む 申請・調達・変更管理プロセスと連動させる
実務で使える進め方（最短1週間プラン）
Day 1：対象範囲の設定（スモールスタート）
優先度1：社外にデータが出る可能性があるAI
- 生成AI（ChatGPT、Claude、Gemini等）
- 外部API
- 外部SaaS
- 外部委託先のAI利用
優先度2：社内限定でも判断に影響する用途
- 与信判断
- 採用選考
- 審査業務
- 顧客対応テンプレート生成
この順序で進めることで、事故予防の効果を早期に実現できます。
Day 2-3：3ルート収集法で効率的に情報を集める
| ルート | 収集方法 | 主な発見対象 |
|---|---|---|
| A. 調達・経費精算 | SaaS・API課金・外注費の記録を調査 | 契約済みサービス |
| B. ネットワーク・SSO・ID管理 | 認証ログ・連携アプリの記録を調査 | 実際に使用中のツール |
| C. 現場ヒアリング | 各部署へのインタビュー | 「便利ツール」「検証用」の隠れた利用 |
Day 4-5：台帳の最小項目設計（完璧より完成を優先）
原則：項目数を増やすほど運用が続かなくなる
最初は以下の7項目で十分です。
| 区分 | 項目 | 記入内容 | 目的 |
|---|---|---|---|
| 特定 | ユースケース名・部署 | どの部署が何に使っているか | 全体像の把握 |
| 責任 | 業務オーナー・管理者（情シス） | 担当者の明確化 | 問い合わせ・事故対応の起点 |
| データ | 入力データ種別 | 機密・個人情報・公開情報 | 漏えいリスクの判断 |
| 外部性 | 外部送信の有無・提供先 | ベンダー名・サービス名 | 契約・越境リスクの確認 |
| 目的 | 出力の使い方 | 参考・自動処理・意思決定 | 影響度の判定 |
| 証跡 | ログ・保存先・保持期間 | 記録の所在（要確認でも可） | 監査・説明責任 |
| 状態 | 運用状態 | 本番・PoC・停止 | 鮮度維持 |
Day 6-7：リスク評価と更新ルールの策定
シンプルな3段階リスク評価
高度な評価は後回しで問題ありません。まず「赤・黄・緑」の3色分類から始めましょう。
| レベル | 判定基準 | 対応方針 |
|---|---|---|
| 🔴 赤(高リスク) | 個人情報・機密を扱う／社外送信あり／自動判断に利用 | 詳細レビュー必須 |
| 🟡 黄(中リスク) | 社外送信ありだが公開情報中心／出力は参考利用 | 定期確認 |
| 🟢 緑(低リスク) | 社外送信なし／影響の小さい内部用途 | 簡易確認 |
更新運用の3つのルール
- 新規導入時：利用開始前に台帳登録（申請フォームと連動）
- 変更時：データ種別・提供先・用途が変わる際は再レビュー
- 定期点検：四半期に1回、部署オーナーが内容を確認
よくある失敗パターンと対策
失敗1：項目を盛りすぎて誰も記入しない
症状：30項目以上の詳細な台帳を作成したが、半分も埋まらず放置される対策： 最小項目（7項目）でスタート → 高リスク（🔴赤）のみ詳細化する二段階方式
失敗2：Excelファイルが更新されず形骸化
症状：最初は頑張って作成したが、3ヶ月後には誰も見ない・更新しないファイルに対策： 調達・SaaS申請・変更管理フローに「台帳更新」をチェックポイントとして組み込む
失敗3：「監視される」と現場が隠蔽する
症状：情シスの取り締まりと受け取られ、影で使い続ける部署が発生対策： 目的を「禁止」ではなく「安全に使える環境づくり」と明確に伝え、協力体制を構築
失敗4：PoCが知らない間に本番運用になる
症状：検証のつもりだったツールが、いつの間にか業務に組み込まれている対策： 状態（PoC/本番）と利用期限を必須項目にし、期限切れは自動的に再承認プロセスへ
実装チェックリスト（コピペして活用可）
準備フェーズ
- [ ] 当社における「AI利用」の定義（ツール・API・組み込み）を決定
- [ ] 棚卸し対象を「社外送信の可能性があるAI」から開始することを決定
- [ ] 台帳の業務オーナーと管理者（情シス）の役割分担を明確化
台帳設計フェーズ
- [ ] ユースケース名の命名規則（目的＋業務＋出力の使い方）を策定
- [ ] 入力データ分類（公開・社外秘・機密・個人情報）の定義を整備
- [ ] 外部送信の有無と提供先（ベンダー名）を必須項目に設定
- [ ] 出力の利用形態（参考・自動処理・意思決定）を必須項目に設定
- [ ] ログ・保存先・保持期間の記録欄を用意
- [ ] 運用状態（本番・PoC・停止）を必須項目に設定
リスク管理フェーズ
- [ ] 3段階リスク評価（🔴赤・🟡黄・🟢緑）を採用
- [ ] 高リスク（🔴赤）のみ詳細レビューする運用ルールを決定
運用定着フェーズ
- [ ] 新規導入時は利用開始前の台帳登録を義務化
- [ ] データ種別・提供先・用途変更時の再レビュープロセスを確立
- [ ] 四半期ごとの棚卸し確認（各部署オーナー）をスケジュール化
- [ ] 台帳更新を申請・調達・変更管理フローに統合
- [ ] 「取り締まり」ではなく「安全に使うための支援」という方針説明を準備
まとめ
3つの重要ポイント1.AIガバナンスの第一歩は「見える化」 AIインベントリ（台帳）なしに、リスク管理も監査対応も始められません
-
最小項目でスタートし、段階的に深化 7項目の台帳からスタート → 高リスク（🔴赤）のみ詳細化する二段階方式で運用を継続
-
更新は業務フローに組み込む 「お願いベース」では形骸化します。申請・調達・変更管理プロセスに台帳更新を統合することが成功の鍵
参考資料（公式・一次情報）
日本政府のガイドライン
国際標準・フレームワーク
- NIST：AI Risk Management Framework（公式ページ）
- NIST：AI RMF 1.0（PDF）
- ISO：ISO/IEC 42001:2023（標準の概要）
- OECD：AI Principles（概要）
免責事項
本記事は一般的な情報提供を目的としており、法務・監査に関する個別助言ではありません。実際の運用にあたっては、貴社の社内ルールおよび専門家にご確認ください。