本文へスキップ
スキルアップカレッジ

AI 台帳と AI 影響評価

レッスン4:AI 台帳と AI 影響評価

このレッスンで学ぶこと

  • AI台帳に登録すべき項目と、管理する粒度の決め方を理解できる
  • 台帳に載っていないAIを見つけるための棚卸しの回し方を理解できる
  • AI影響評価の観点と、案件ごとに軽重をつける考え方を理解できる
  • 評価結果を承認判断に接続する設計を理解できる

前回のレッスンでは、利用申請の様式設計と決裁ラインの引き方を学びました。今回のレッスンでは、承認されたAI、そして既存の業務にすでに組み込まれているAIを、継続的に管理する「AI台帳」と、利用開始前に影響の大きさを確かめる「AI影響評価」を扱います。レッスン1で示した中核メッセージの1つ、「台帳に載っていないAIは、存在しないのではなく見えていないだけである」は、このレッスンの出発点です。

AI台帳とは何か——なぜ必要か

AI台帳とは、社内で利用されているAIサービスやAI機能を、一覧として管理する仕組みです。英語ではAIインベントリと呼ばれることもあります。台帳が必要とされる理由は、単純です。台帳がなければ、経営層も情報システム部門も、「自社が今どれだけのAIを、どの部門で、どのような用途に使っているか」という全体像を答えられないためです。

レッスン1で紹介した3つの引き金——取引先からの質問状、インシデント、内部監査——のいずれの場面でも、最初に問われるのは「一覧で示せますか」という問いです。台帳がない企業では、この問いに答えるだけで、複数の部門への聞き取りが必要になり、数週間かかることも珍しくありません。台帳が整っていれば、この作業は数分で完了します。

💡 ポイント AI台帳の価値は、平常時にはあまり実感されません。しかし、質問状・インシデント・監査という「有事」の場面で、台帳の有無が対応スピードを大きく左右します。台帳の整備は、地味に見えて、もっとも投資対効果の高いガバナンス施策の1つです。

AI台帳に何を登録するか——項目設計

AI台帳に登録する項目は、レッスン3で扱った申請様式の内容を土台に、継続管理に必要な項目を加えた形で設計します。代表的な項目を整理します。

項目カテゴリ 具体的な項目
基本情報 AIサービス名、提供事業者名、導入日、利用部門
用途情報 用途の概要、出力の使途
データ情報 扱うデータの区分、個人情報の有無
責任情報 申請時の責任者、現在の管理責任者
契約情報 契約形態(法人契約か個人契約か)、契約の更新時期
評価情報 AI影響評価の実施日、評価結果の概要
状態情報 利用状況(稼働中・休止・廃止)、最終確認日

これらの項目をすべて詳細に管理しようとすると、台帳の更新作業そのものが重くなり、レッスン1で触れた「更新が半年以上前で止まっている」という兆候につながります。台帳を機能させ続けるには、項目の粒度を、更新の負担と情報の価値のバランスで決める必要があります。

台帳の粒度をどう決めるか

台帳の粒度、つまり「何を1つの単位として登録するか」は、実務で意外と迷う論点です。粒度の決め方には、大きく3つの考え方があります。

サービス単位の粒度は、1つのAIサービスを1件として登録する考え方です。「Aという生成AIサービスを、営業部門と人事部門が使っている」という形で、サービスを軸に管理します。もっとも粗い粒度で、台帳の件数を少なく保てる一方、部門ごとの使われ方の違いが見えにくくなります。

部門×サービス単位の粒度は、同じサービスでも利用部門ごとに別の行として登録する考え方です。「Aというサービスを、営業部門が顧客提案に使っている」「Aというサービスを、人事部門が求人票の作成に使っている」を、それぞれ別の行として管理します。用途ごとのリスクを個別に追跡できる一方、同じサービスが台帳上で複数行に分割されるため、契約情報の更新時に見落としが生じやすくなります。

用途単位の粒度は、部門×サービスよりもさらに細かく、1つの用途を1件として登録する考え方です。もっとも詳細な情報が残る一方、台帳の件数が膨れ上がり、更新の負担が大きくなります。

粒度 件数 更新の負担 向いている企業規模
サービス単位 少ない 軽い AI利用がまだ限定的な企業
部門×サービス単位 中程度 中程度 多くの企業にとっての標準的な選択肢
用途単位 多い 重い AIの利用が広範囲かつリスクの高い業種

多くの企業にとって、部門×サービス単位が実務上の落としどころになります。サービス単位では見えない部門ごとのリスクの違いを捉えつつ、用途単位ほど細かくしすぎないことで、更新の負担を現実的な範囲に収められます。

🔰 初学者の方へ 最初から完璧な粒度を決める必要はありません。まずはサービス単位の粗い台帳から始め、運用しながら「もう少し細かく管理したい」と感じた部分だけ、部門×サービス単位に切り替えていく進め方でも構いません。台帳は一度作って終わりではなく、育てていく文書だと捉えてください。

台帳の記入例——1行を実際に埋めてみる

項目と粒度の考え方を、実際の記入例で確認しておきます。次の表は、部門×サービス単位で台帳の1行を埋めた例です。

項目 記入例
AIサービス名 生成AI文章作成サービスX
提供事業者名 X社
導入日 2026年4月1日
利用部門 営業部門
用途の概要 顧客向け提案資料の下書き作成
扱うデータの区分 社内限定情報(個人情報は含まない)
契約形態 法人契約
管理責任者 営業企画課長
AI影響評価の実施日 2026年3月20日
評価結果の概要 影響小、簡易チェックリストにて確認済み
利用状況 稼働中
最終確認日 2026年8月1日

この例からわかるとおり、台帳の1行には、申請時点の情報だけでなく、「最終確認日」のように、継続的な棚卸しの結果を反映する項目も含まれます。台帳は一度作って終わりの静的な文書ではなく、定期的に更新され続ける動的な文書として運用する必要があります。

棚卸しの回し方——台帳に載っていないAIをどう見つけるか

台帳を作った時点では、既知のAIサービスがすべて登録されていても、時間が経つにつれて、台帳に載っていない利用が生まれます。新しく契約したサービス、業務システムのアップデートで追加されたAI機能、個人契約のまま使われ続けているサービスなどです。こうした「見えていないAI」を発見する作業が、棚卸しです。

棚卸しの手法には、複数のアプローチがあります。

申請・届出ベースの棚卸しは、レッスン3で扱った事前申請と事後届出の記録を、定期的に台帳へ反映する方法です。もっとも基本的な棚卸しの形ですが、申請や届出が漏れているケースは捕捉できません。

契約情報ベースの棚卸しは、経理部門や調達部門が持つ契約・支払いの記録を確認し、AIサービスへの支払いが台帳に反映されているかを照合する方法です。個人の経費精算で契約されているAIサービスの発見にもつながります。

ヒアリングベースの棚卸しは、各部門の責任者に対して、定期的に「現在使っているAIサービスを教えてください」と確認する方法です。手間はかかりますが、システム的に把握しきれない利用実態を拾える利点があります。

技術的なログベースの棚卸しは、社内ネットワークのアクセスログなどから、AIサービスへの通信を機械的に検出する方法です。導入には情報システム部門の技術的な対応が必要ですが、もっとも網羅性の高い方法です。

📝 補足 4つの手法は、どれか1つだけで完結させるのではなく、組み合わせて使うのが実務的です。多くの企業では、日常的には申請・届出ベースの棚卸しを回しながら、半年から1年に一度、契約情報ベースとヒアリングベースの棚卸しを実施し、台帳の網羅性を定期的に検証する運用を採用しています。

AI影響評価とは何か——観点と軽重の付け方

AI台帳に新しいAIサービスを登録する前、あるいは既存のAIサービスの使い方を大きく変える前に、そのAIが業務や関係者にどのような影響を与えうるかをあらかじめ確認する作業が、AI影響評価です。

AI影響評価では、次のような観点から確認を行います。

  • 公平性への影響:AIの判断が、特定の属性を持つ人に対して不利に働く可能性はないか
  • 正確性への影響:AIの出力に誤りが含まれていた場合、誤った意思決定につながる可能性はどの程度あるか
  • 説明可能性への影響:AIの判断の根拠を、関係者に説明できる状態にあるか
  • 人への影響の大きさ:AIの判断が、人の採用・評価・与信・処遇など、重要な意思決定に直結するか

すべての用途に対して、これらの観点をすべて詳しく確認する必要はありません。AI影響評価の実務上の要点は、案件ごとに評価の軽重をつけることです。文章の下書きを作る程度の用途であれば、簡易的なチェックリストで数分で完了させ、人の採用や評価に関わる用途であれば、AI委員会での審議を含む、より丁寧な評価を行う、という段階分けが現実的です。

影響の大きさ 典型的な用途 評価の重さ
小 文章の下書き作成、社内資料の要約 簡易チェックリスト(申請者自身が記入)
中 顧客対応の下書き、社内向けレポートの分析 事務局による確認
大 採用選考の補助、人事評価の補助、与信判断の補助 AI委員会での審議

この段階分けは、レッスン3で扱った決裁ラインの階層設計と、多くの部分で対応します。決裁ラインの高さと、AI影響評価の重さを、あわせて設計しておくと、審査の全体像が一貫したものになります。

⚠️ 注意 「影響が小さいはずだ」という思い込みだけで評価を省略すると、後になって想定外の影響が判明することがあります。簡易チェックリストであっても、必ず何らかの形で確認の記録を残しておくことが、後から振り返る際の重要な材料になります。

個人データを扱う場合——評価の二重運用を避ける設計

AIが個人データを扱う用途では、AI影響評価に加えて、個人データの取り扱いに関する評価が別途必要になる場合があります。この個人データ側の評価そのものの手法や、実施が必要な要件については、プライバシー関連の実践コースが専門に扱う領域であり、本コースでは扱いません。

ここで本コースが扱うのは、AI影響評価と個人データ側の評価を、別々の担当者が別々のタイミングで、重複した内容の確認を行ってしまう「二重運用」を避けるための設計です。

二重運用を避けるためには、2つの評価の間で、確認すべき項目のうち重なる部分を明確にしておくことが有効です。例えば「扱うデータに個人情報が含まれるか」という確認項目は、AI影響評価にも個人データ側の評価にも共通して登場します。この共通項目については、どちらか一方の評価で確認した結果を、もう一方の評価にそのまま引き継ぐ運用にしておけば、同じ質問に2回答えるという申請者の負担を減らせます。

実務では、申請様式の中で「個人情報を扱う」という選択肢が選ばれた場合に、AI影響評価のフローに加えて、個人データ側の評価フローも自動的に案内される、という設計がよく採用されます。2つの評価を完全に統合するのではなく、入口を1つにしたうえで、必要な評価へ振り分ける、という考え方です。

📖 もっと詳しく 評価の統合をどこまで進めるかは、企業の組織構造にもよります。個人データの評価を法務やコンプライアンス部門が担い、AI影響評価をAI推進の事務局が担うというように、担当部門が分離している企業では、完全な統合よりも、情報共有の仕組みを整えるほうが現実的な場合があります。体制の設計はレッスン5で扱います。

評価結果を承認判断にどう接続するか

AI影響評価を実施しても、その結果が承認の判断に反映されなければ、評価は形だけの作業になってしまいます。評価結果を承認判断に確実に接続するための、実務上のポイントを整理します。

1つ目は、評価結果を承認の必須条件にすることです。 影響の大きい用途では、AI影響評価が完了していない申請を、そもそも決裁ラインに進められない仕組みにしておきます。

2つ目は、評価で見つかった懸念を、条件付き承認の形で反映することです。 評価の結果、一定の懸念が見つかったものの、致命的なものではない場合、「この条件を満たせば利用可能」という形で、承認の条件に組み込みます。例えば「AIの出力を必ず人が確認してから使うこと」といった条件です。

3つ目は、評価結果をAI台帳に記録し、後から参照できるようにすることです。 評価の結果は、一度きりの確認で終わらせず、台帳の評価情報の項目に記録し、レッスン8で扱う定期的な見直しの際に、再確認できるようにしておきます。

この3つのポイントに共通するのは、AI影響評価を「通過するための儀式」にしないという姿勢です。評価を通すこと自体が目的化してしまうと、懸念が見つかっても記録に残らず、次に似た用途の申請が来たときに、同じ懸念を一から洗い出す羽目になります。評価結果を台帳という共有の資産に蓄積しておけば、似た用途の審査を、ゼロからではなく過去の知見を踏まえて進められるようになります。

講師の現場メモ②

上場IT企業の情報システム企画で、AI台帳の立ち上げを担当したときの経験です。台帳を作る前の社内ヒアリングで、情報システム部門が把握していたAIサービスの数は7件でした。ところが、経理部門の支払い記録を確認したところ、AI関連の支払いは23件にのぼることが判明しました。

差の16件のほとんどは、各部門が個人の経費精算や、部門予算の少額決裁で契約していた、いわば「善意の見えないAI」でした。悪意を持って隠していたわけではなく、単に「これはAIサービスだが、報告するという発想がなかった」というケースがほとんどでした。この経験から、台帳の網羅性を高めるうえで、申請・届出だけに頼るのではなく、契約情報ベースの棚卸しを組み合わせる重要性を痛感しました。

もう1つ印象的だったのは、この16件の中に、個人情報を扱う用途で使われていたサービスが2件含まれていたことです。幸い深刻な問題には至りませんでしたが、AI影響評価を経ずに使われ続けていたことが、後から判明しました。この経験を経て、私は「台帳は性善説で作ってはいけない」という考えを持つようになりました。悪意がなくても、報告される仕組みが整っていなければ、見えないAIは必ず生まれます。台帳の設計は、性善説ではなく、報告しやすい仕組みと、定期的な棚卸しの両方を前提に組み立てる必要があります。

まとめ

このレッスンでは、以下のことを学びました。

  • AI台帳は、有事の場面で対応スピードを左右する、投資対効果の高いガバナンス施策である
  • 台帳の粒度は、サービス単位・部門×サービス単位・用途単位の3段階があり、多くの企業では部門×サービス単位が実務上の落としどころになる
  • 棚卸しは、申請・届出ベース、契約情報ベース、ヒアリングベース、ログベースの4つの手法を組み合わせて回す
  • AI影響評価は、公平性・正確性・説明可能性・人への影響の大きさという観点から、案件ごとに軽重をつけて実施する
  • 個人データ側の評価とは、共通項目の重複確認を避け、入口を1つにして振り分ける設計にする
  • 評価結果は、承認の必須条件・条件付き承認・台帳への記録という形で、承認判断に確実に接続する

次のレッスンでは、これらの器を実際に動かす「AI推進体制」を、AI委員会・事務局・責任者という3点セットで設計します。台帳と影響評価という器は、それを回す人がいて初めて機能するため、体制の設計は、本コースの後半に進むための欠かせない土台になります。


確認クイズ

このレッスンの理解度をチェックしましょう。