COLUMNS

TOP > COLUMNS
AIインベントリとは
2026.07.10 AIガバナンス
ai-inventory-what-to-record

専門部署に散った「誰が、どのAIに、何を渡しているか」という利用実態を、一枚の台帳に集めて次の統治判断に使える形にする。これがAIインベントリです。総務省の令和7年版情報通信白書によれば、日本企業で生成AIを業務利用する割合は55.2%に達しました。導入を止める最大の要因は規制でも予算でもなく、「効果的な活用方法がわからない」という運用設計の不在です。活用を広げると、管理外への情報送信、誤った出力の混入、利用履歴を後から辿れないという穴が同時に開きます。では、その出発点である台帳に何を書けばいいのか。結論を先に言うと、様式を自社でゼロから設計する必要はありません。NISTが記録対象の例を示しており、原文を踏まえて実務の台帳に落とせます。台帳の様式づくりに外注費や設計工数をかけずに始められる、という話です。

活用が広がるほど、誰が何を使っているか分からなくなる

白書の数字は、活用の広がりに他国との差が残ることも示します。中国95.8%、米国90.6%、ドイツ90.3%に対し、日本は55.2%です。差を生んでいるのは、使い方が定まらないまま各部署が個別にツールを触っている状態です。

人が判断していた業務をAIに移すと、穴が具体的な失敗になって現れます。営業担当が顧客情報を無料版のチャットに貼って社外へ送る。誤った出力に気づかず提案書に載せる。半年後に問題が起きても、誰がどのツールに何を入れたかの記録がなく追えない。

2024年2月、カナダのBritish Columbia Civil Resolution Tribunal(ブリティッシュコロンビア州の民事紛争解決機関)は、チャットボットが誤って案内した割引運賃をめぐり、航空会社に約650カナダドルの賠償を命じました。判定文は、Air Canadaの主張を「チャットボットは、自らの行為に責任を負う別個の法主体だと言っているに等しい」と整理し、そのような抗弁は成り立たないと退けています。金額は小さくても、示したものは大きい。「AIが誤った」という説明で、企業は実害の責任を免れないということです。台帳がなければ、この誤りを誰が管理していたかを事後に指し示すこともできません。

NISTが「台帳に何を書くか」の例を示している

米国NISTのAIリスクマネジメントフレームワーク(AI RMF)のプレイブックは、GOVERN 1.6で「AIシステムを棚卸しする仕組みを、組織のリスク優先度に応じて用意する」という考えを示しています。ここでのAIインベントリを、NISTは「AIシステムに関する成果物を整理したデータベース」と説明します。例として挙がっている情報は、システム文書、インシデント対応計画、データ辞書、実装ソフトやソースコードへのリンク、関係するAIアクター(担い手)の氏名と連絡先です。

さらにNISTは、台帳を誰が維持する責任者か、全AIシステムをどう対象に入れるかまで扱っています。GOVERN 1.7では、AIシステムを安全に廃止・停止する手順にも触れています。棚卸しから、対象範囲、責任者の割り当て、廃止までを一連で考えるわけです。

同じ方向を指す公的文書は日本にもあります。AIセーフティ・インスティテュート(AISI)の『CAIO設置・AIガバナンス実務マニュアル(案)』は、AIインベントリを整備・維持すべき基盤文書として挙げています。

ただし、NISTとAISIは性格が違います。NISTは任意の枠組みで、AISIは実務マニュアルの案です。強制力も対象も同じではありません。AISIはAIインベントリを基盤文書として位置づけていますが、本記事執筆時点で確認できる公開情報では台帳の詳細項目までは示されていません。そこで今回は、項目を具体的に公開しているNISTを参考にして説明します。

写せるのは様式だけ、中身は社内でしか集まらない

まず、NISTの原文に近い形で並べると、AIインベントリに含める情報の例は次の5つです。

  • システム文書
  • インシデント対応計画
  • データ辞書
  • 実装ソフトウェアまたはソースコードへのリンク
  • 関係するAIアクターの氏名と連絡先

これを実務の台帳に落とすなら、独自解釈としてはこうなります。システム文書にはAIシステム名、用途、提供元、利用部門を書く。インシデント対応計画には誤出力、情報漏えい、停止時の連絡先と初動を書く。データ辞書にはデータ項目名、意味、形式を書く。リンク欄には管理画面、リポジトリ、設定資料を置く。AIアクター欄には利用者、管理者、開発者、外部ベンダーの氏名と連絡先を書く。

ここで区別が要ります。NISTから写せるのは、原文にある情報項目と、それを列にする考え方です。各セルを埋める中身(AIシステム名、用途、データ項目、関係者の氏名と連絡先など)は、自社の中でしか集まりません。当社が実装を支援する現場でも、台帳の様式より「誰に聞けば埋まるか」で止まります。各部署が何を使っているかを正直に開示してもらわないと、列は空のままです。外注先はこの開示を強制できず、嘘の回答も見抜けません(この線引きはCAIOを外注する記事で扱いました)。

「うちは小さいから、全部を埋めるのは重すぎる」という反論には、対象と着手順を分けて答えます。台帳の対象は全AIシステムです。ただし、全項目を一度に揃える必要はありません。顧客データや与信判断など、外れたときの損失が大きい業務から、上の5項目で1行分の所在を埋めれば、台帳は動き始めます。

台帳があっても、誤った出力そのものが消えるわけではありません。台帳が果たすのは、誰がどのAIを管理していたかを事前に決めておくことです。Air Canadaの事例で欠けていたのは、まさにこの責任の所在でした。

まとめ、今日始められる一手

AIインベントリとは、自社のAI利用実態を一枚に集めた台帳です。NISTは、AIインベントリに含める情報の例を示しています。原文を踏まえれば、自社で様式をゼロから設計する工数も、それを外注する費用も要りません。

限界も同じだけはっきりしています。写せるのは原文にある情報項目と、そこから作る列の見出しまでで、中身は社内ヒアリングでしか埋まりません。これらの文書に法的な強制力はなく、台帳を作っても規制適合を保証するものでもありません。

次の一手は具体的です。まず高リスクな業務を1つ選び、GOVERN 1.6の5つの例示項目をExcelの列にして1行だけ作る。最終的な対象は全AIシステムですが、様式の設計で立ち止まらず、原文の項目と上の独自解釈を対応させて埋める。なぜ検知ツールより先に棚卸しをやるのかという順番の話は、シャドーAIの記事で扱いました。

参考・一次ソース

■お問い合わせ

台帳の列はNISTの項目を起点に作れても、各部署に利用実態を開示してもらって中身を埋める旗振りや、どの業務から先に棚卸しするかの線引きに手が回らないときは、アハクラフトにご相談ください。棚卸しのヒアリング設計から運用への落とし込みまで、実装側から立ち上げをお手伝いします。

お問い合わせ