生成AIの利用申請を受け付け、承認番号を付け、表計算ソフトの台帳へ登録する。 この仕組みを整えたのに、数か月後には「いまも使っているのか」「モデルや利用規約は変わっていないか」 「期待した効果が出ているか」を答えられない企業は少なくありません。

問題は、台帳の項目数ではありません。申請時の情報が、調達、セキュリティ、個人情報保護、 業務運用、効果測定、インシデント対応と分断され、更新のきっかけと責任者が決まっていないことです。 その状態では、台帳が増えるほど確認作業が重くなり、現場は登録を避け、経営には古い集計だけが届きます。

経済産業省・総務省の「AI事業者ガイドライン（第1.2版）」は、環境・リスク分析、 ゴール設定、システムデザイン、運用、評価というサイクルでAIガバナンスを構築し、 経営層がモニタリングする考え方を示しています。NISTのAI RMFも、AIリスクを Govern、Map、Measure、Manageの継続的な活動として扱います。

本記事では、AI資産台帳を監査用の一覧ではなく、価値とリスクを更新し続ける意思決定基盤に変えるための 5つのステップを整理します。特定の法域への適合判断ではなく、日本企業が日常の管理へ取り入れやすい実務設計に焦点を当てます。

具体的な課題：申請時点の「静止画」では変化を管理できない

AIサービスは、従来の業務システムより短い周期で変化することがあります。 提供モデル、接続先、学習・保存条件、利用規約、料金、機能、出力品質が変われば、 同じ名称のユースケースでも価値とリスクは同じではありません。 社内で入力するデータや、AI出力を使う業務判断が変わる場合もあります。

ところが、台帳が「利用部門・ツール名・承認日」だけで構成されていると、次の問いに答えられません。

  • どの業務成果を狙い、実際にどの指標が改善しているか。
  • どのデータを、どの契約・設定・接続経路で処理しているか。
  • 出力が顧客、従業員、取引先、重要な意思決定へどう影響するか。
  • 誤りや不適切な出力を誰が発見し、停止・修正・報告を判断するか。
  • モデル、用途、データ、規約が変わったとき、誰が再評価を始めるか。
AI資産台帳の役割は、AIを数えることではありません。 「使い続ける・条件を変える・止める」を、根拠を持って判断できる状態をつくることです。

考え方：一つのAIを「ユースケース単位」で捉える

同じ生成AIサービスでも、社内文書の下書きと、顧客への回答生成では、 入力データ、誤りの影響、人による確認、必要な証跡が異なります。 そのため、ベンダーやモデルだけを一行で管理するのではなく、 「誰が、何の業務で、どのデータを使い、どの結果へつなげるか」というユースケース単位で登録します。

その上で、モデル・API・SaaS・データソース・外部委託先を構成要素として関連付けます。 一つのサービスを複数部門が使う場合は、共通のベンダー評価を再利用しつつ、 用途ごとの事業影響と統制を分けます。これにより、重複審査を減らしながら、 高い影響を持つ用途へ確認時間を配分できます。

欧州委員会が公表するAI Actの汎用AIモデル提供者向け情報でも、技術文書、 下流のAIシステム提供者が能力と限界を理解するための情報、リスク評価やインシデント報告など、 ライフサイクルとサプライチェーンを通じた文書化が重視されています。 適用対象や義務は立場・提供地域・用途などで異なるため、個別の適用判断とは切り分けつつ、 「後から説明できる構成情報」を平時から持つ実務上の参考になります。

実践手順1：登録の主語を「ツール」から「業務目的」へ変える

最初に、登録票の先頭へツール名ではなく業務目的を書きます。 例えば「問い合わせ返信案の作成時間を短縮する」「設備点検記録から見落とし候補を提示する」のように、 利用者と期待する結果が分かる粒度にします。

最低限、次の項目を一つのレコードとして結び付けます。

  • 目的と価値：対象業務、利用者、期待する成果、基準値、継続判断に使う指標
  • データ：入力・参照・出力するデータ、機密性、個人情報の有無、保存先
  • 構成：サービス、モデル、バージョン、API、連携先、委託先、利用環境
  • 影響：誤り、偏り、漏えい、停止が人や事業へ与える影響と回復可能性
  • 責任：業務オーナー、技術責任者、リスク受容者、運用・問い合わせ窓口

項目を埋めること自体を目的にせず、分からない情報は「未確認」と明示します。 空欄を隠すより、未確認項目を可視化して次の調査や契約確認へつなげる方が、実効性のある管理になります。

実践手順2：リスクだけでなく「価値の仮説」を同じ場所で管理する

AIガバナンスが審査部門だけの仕事になると、台帳には禁止事項とリスクだけが増えます。 一方、事業部門が価値だけを管理すると、精度低下や利用条件の変化が投資判断から外れます。 価値とリスクを同じレコードで確認し、両方に責任者と見直し日を設定します。

価値指標は、利用回数だけでなく、目的に近い指標を選びます。

  • 処理時間の短縮と、人による確認時間を合わせて測る。
  • 採用率だけでなく、修正率、差し戻し、利用者・顧客からの指摘を追う。
  • 自動化率だけでなく、例外件数、停止件数、回復に要した時間を確認する。
  • 売上・コストへの寄与は、AI以外の要因を含むことを前提に、仮説として検証する。

NIST AI 600-1は、生成AIのリスク管理で、ガバナンス、コンテンツの来歴、 導入前テスト、インシデント開示を主要な考慮事項として整理しています。 効果測定に加え、どのデータ・モデル・設定で評価したかを残すと、更新後の比較や原因分析がしやすくなります。

実践手順3：影響度で審査経路を分け、低リスク利用を滞留させない

すべてのAI利用を同じ会議で審査すると、件数の増加に耐えられません。 データの機密性、個人・顧客への影響、重要判断への関与、外部公開、自動実行、 回復可能性を使って影響度を分類し、確認の深さと承認者を変えます。

  1. 標準利用：承認済み環境で、低機密データを扱い、人が出力を確認する用途。簡易登録と利用ルールへの同意で開始する。
  2. 要確認利用：社内システム連携、一定の機密データ、顧客向け出力を含む用途。データ、評価、人の確認、ログ、停止方法をレビューする。
  3. 重点管理利用：権利・機会・安全・重要業務へ大きく影響し得る用途。経営、業務、法務、セキュリティなどを交え、導入前評価と継続監視を設計する。

分類名や閾値は自社の事業とリスク許容度に合わせて決めます。 自動分類は担当者の見落としを減らす補助として使い、最終判断の理由と責任者を記録します。

実践手順4：再評価の「イベント」を先に決める

年1回の棚卸しだけでは、AIの変化を追い切れない場合があります。 日付による定期確認に加え、次のイベントが発生したら再評価を始めるルールを設定します。

  • モデル、サービス、主要機能、API、データソース、システム連携を変更した。
  • 利用対象の部門・顧客・地域、または出力を使う意思決定を広げた。
  • 利用規約、データ保存、学習利用、再委託、料金体系に重要な変更があった。
  • 品質指標が許容範囲を外れた、苦情・不適切出力・セキュリティ事象が発生した。
  • 関連する法令、行政資料、業界基準、社内方針が更新された。

ベンダー通知、変更管理、インシデント管理、契約更新を台帳へ連携し、 「誰かが気づいたら連絡する」運用を避けます。自動連携が難しい初期段階では、 月次の運用会議で変更イベントの有無を確認するだけでも、静止した台帳から前進できます。

実践手順5：経営向け指標を「件数」から「判断可能性」へ変える

登録件数や承認件数だけでは、ガバナンスが機能しているか分かりません。 経営層には、価値の実現状況と、重大な不確実性・例外・未完了の対応を一緒に示します。

  • 重要ユースケースのうち、責任者・構成・データ・監視条件が確認できている割合
  • 価値指標が改善、横ばい、悪化、未測定のユースケース数と投資額
  • 再評価期限を超過した件数、重大な未確認項目、例外の残存期間
  • インシデント・苦情・停止・手動介入の傾向と、再発防止策の完了状況
  • 重複ツール、未利用契約、共通基盤へ統合できる候補

この指標なら、経営は「AIを何件使っているか」ではなく、 「どこへ追加投資するか」「どの条件を改善するか」「どの利用を止めるか」を判断できます。

最初の60日で一つの重点ユースケースを一周させる

  1. 1〜15日：重要なAIユースケースを一つ選び、目的、データ、構成、影響、責任者を整理する。
  2. 16〜30日：価値指標とリスク指標、影響度、承認条件、停止条件を決める。
  3. 31〜45日：モデル変更、規約変更、品質悪化、インシデントを想定し、再評価の流れを机上で試す。
  4. 46〜60日：判断に使えなかった項目を削り、不足した情報と連携を追加して次の用途へ展開する。

期間は一例です。全社台帳の完成を待つより、価値とリスクが大きい一つの用途で 登録、評価、変更、再評価、継続判断までを実際に回し、使われる項目だけを標準化します。

注意点：台帳を「安全の証明」にしない

  • 登録済み・承認済みという状態だけで、出力の正確性や法令適合性を保証しない。
  • 外部ベンダーの説明をそのまま転記せず、自社の用途、設定、データ、運用条件で評価する。
  • 個人情報や機密情報を必要以上に台帳へ複製せず、保管場所とアクセス権を分ける。
  • リスク分類を固定せず、用途、対象者、連携、自動化範囲の変化で見直す。
  • 法務・セキュリティだけへ責任を集めず、価値と業務影響を持つ業務オーナーを明確にする。

個人情報保護委員会は、個人情報取扱事業者が生成AIサービスへ個人データを入力する場合、 利用目的の範囲や、提供事業者が機械学習に利用しないことなどを十分確認するよう注意喚起しています。 実際の確認事項は、利用するサービス、契約、データ、目的によって異なります。

本記事は公的資料をもとに一般的なAIガバナンスの実務を整理したものであり、 個別の法令適合性、契約、監査、認証に関する法律上・専門上の助言ではありません。 具体的な適用判断は、最新の一次資料、契約条件、関係部門および必要に応じた専門家の確認を踏まえて行ってください。

まとめ

AI資産台帳を機能させる鍵は、申請項目を増やすことではありません。 ユースケースを主語に、価値、データ、構成、影響、責任を結び付け、 影響度で審査を分け、変更イベントで再評価し、経営が継続・改善・停止を判断できる情報へ変えることです。

まずは重要な一つの用途で、登録から再評価までを一周させてください。 現場が更新でき、審査部門が優先順位を付け、経営が投資判断に使えるようになったとき、 台帳は監査用の静止画から、AI活用を安全に前へ進める運用基盤へ変わります。

参考にした公式資料

FW

WRITTEN BYFourthWall Consulting Teamテクノロジーと経営の両面から、企業変革を支援しています。

← 技術ブログ一覧へ戻る