AI利用台帳とは？導入判断・記載項目・運用手順を実務テンプレートで解説
DX推進
生成AIの社内定着・業務効率化のご相談を承っています
戦略策定から現場研修まで、Mojiが一貫して支援します。
AI利用台帳とは、社内で利用する生成AI、AI API、AIエージェント、AIを組み込んだSaaSについて、誰が・何の業務で・どの情報を入力し・どこまで任せ・誰が確認するかを記録し、継続して見直すための管理台帳です。
結論からいうと、AI利用台帳は「契約しているAIツールの一覧」だけでは、導入可否や運用条件を判断しにくいことがあります。利用目的、入力データの区分、外部への操作権限、人による確認、評価結果、変更時の再確認条件までを1件ごとに結び付けると、導入・横展開・停止を判断する材料になります。
本記事では、AI利用台帳を組織が利用・提供するAIの用途、データ、権限、責任、検証、運用状態を追跡するための実務上の台帳として扱います。これは法律や規格で名称と列が一律に定義された帳票ではありません。以下の項目・手順・判定表は、特記がない限りMojiによる実務上の提案です。
AIリスク管理では、組織の方針・責任・文書化、利用文脈の把握、リスク測定、対応と継続改善を分けて扱う考え方が参考になります。NIST AI RMF 1.0は、これをGOVERN、MAP、MEASURE、MANAGEの4機能で整理し、GOVERN 1.6ではAIシステムのインベントリを設ける仕組みを示しています。NIST AI RMF 1.0
AI利用台帳が必要になる場面
次の状態が一つでもあるなら、スプレッドシートなどで小さく始める価値があります。
- 部門ごとに異なる生成AIやAI機能付きSaaSを導入しており、全体像を説明できない。
- 「顧客情報を入れてよいか」「出力をそのまま送ってよいか」を担当者ごとに判断している。
- チャット利用だけでなく、社内文書検索、CRM更新、メール送信、決済・発注など、AIが外部システムへ操作できる範囲が広がっている。
- モデル、料金プラン、データ利用条件、連携先が変わったとき、影響を受ける業務を特定できない。
- 導入効果を説明する際に、利用件数しか分からず、品質・時間・事故・再作業を確認できない。
特に、未承認の個人契約や部署単位の利用を把握しないまま禁止だけを強めると、利用実態がさらに見えにくくなるおそれがあります。可視化、公式代替手段、監査を組み合わせる考え方は、シャドーAIのリスクと対策でも解説しています。
AI利用台帳と「ツール一覧」「監査ログ」の違い
管理対象 | 主に答える質問 | 管理単位 | AI利用台帳との関係 |
|---|---|---|---|
ツール・契約一覧 | 何を契約しているか、費用はいくらか | ベンダー、契約、ライセンス | 台帳の入力元になるが、業務用途や確認者までは分からないことが多い |
AI利用台帳 | どの業務で、どの情報を使い、どこまで任せてよいか | AI利用ケース、AIシステム、業務フロー | 導入・継続・変更・停止を判断する中心台帳 |
監査ログ | いつ誰が何を実行し、何が起きたか | 個別の実行・操作イベント | 台帳に記した運用が守られたかを確認する証跡 |
AI利用台帳は、日々の全プロンプトを保存するためのものではありません。台帳は「利用設計と責任の地図」、監査ログは「実際の操作の記録」と分けると、個人情報や営業秘密を必要以上に集めない設計にしやすくなります。
なお、EU AI ActのArticle 12およびArticle 19は、高リスクAIシステムの提供者に関する規定です。Article 12はライフサイクル中のイベントを自動記録できるログ機能を求め、Article 19は提供者の管理下にある自動生成ログの保存を定めています。これは一般的な社内AI利用台帳に直接同じ法的義務を課すものではありません。ただし、重要なAI利用について、設計上の台帳と実行上のログを分けて追跡できるようにする際の参考にはなります。EU AI Act（Article 12、Article 19）
最初に決めること：台帳へ載せる単位
最も扱いやすい単位は、原則として「AI製品」ではなく「AIを使う業務ケース」です。同じAIサービスでも、会議メモの下書きと顧客への回答送信では、入力情報、失敗時の影響、人の確認方法が異なります。
たとえば同じ社内チャットAIであっても、次は別レコードにします。
- 広報部が公開済み資料からSNS投稿案を作る。
- 営業部が顧客向け提案書の初稿を作る。
- 人事部が応募者情報を含む面接メモを要約する。
- 情報システム部が社内規程を検索して回答する。
ただし、同じ用途・同じデータ区分・同じ権限・同じ確認フローで多数の部署が使う場合は、共通レコードに部署別の利用者範囲を持たせても構いません。細かく分けすぎて更新されなくなるなら、台帳の目的を失います。
最低限そろえるべき記載項目
以下は、初版のAI利用台帳に推奨する最小構成です。項目数を増やす前に、空欄のまま承認・運用されない仕組みを作ることを優先してください。
分類 | 項目 | 記載する内容 | 判断に使う場面 |
|---|---|---|---|
識別 | 利用ケースID・名称 | 業務ケースを一意に識別するIDと名称 | 変更・障害・監査時の参照 |
目的 | 対象業務・期待成果 | どの工程を支援し、何を改善したいか | 導入目的との適合、KPI設定 |
責任 | 業務責任者・運用担当・承認者 | 判断、日常運用、例外承認の担当 | 問い合わせ、事故対応、更新依頼 |
AI構成 | 提供者・製品・モデル・連携先 | 利用中のサービス、モデル、API、接続する業務システム | 仕様変更、契約変更、脆弱性対応 |
データ | 入力データ区分 | 公開情報、社内情報、個人情報、要配慮情報、営業秘密など | 入力可否、契約・設定確認 |
操作 | AIができる操作 | 閲覧、下書き作成、検索、登録、送信、削除、発注など | 承認・権限・停止条件の設計 |
人の関与 | 確認者・確認タイミング | 出力確認、送信前承認、例外処理の担当 | 誤情報・誤操作の抑止 |
評価 | 評価指標・許容誤差・評価日 | 正確性、必須項目漏れ、再作業時間、誤送信など | 本番化・継続・改善の判定 |
運用 | 見直し日・変更トリガー・停止条件 | 定期確認日と、再審査する条件、利用停止する条件 | モデル更新や事故後の対応 |
個人情報を含む入力があり得る場合は、台帳に「個人情報あり」とだけ書いて終わらせず、入力目的、対象者、入力の必要性、サービス提供者側での学習利用や二次利用に関する確認先、承認者を記録してください。個人情報保護委員会は、個人情報取扱事業者が本人同意なしに個人データを含むプロンプトを入力し、そのデータが応答以外の目的で扱われる場合、個人情報保護法に違反する可能性があるとして、提供事業者が機械学習に利用しないことなどを確認するよう注意喚起しています。個人情報保護委員会：生成AIサービスの利用に関する注意喚起
記載項目を増やす判断基準：3段階の管理レベル
すべてのAI利用を同じ重さで審査すると、低リスクな利用まで滞留します。反対に、すべてを簡易申告だけで済ませると、重要な利用を見落とします。そこでMojiでは、入力データの機微性、出力・操作の影響、外部への不可逆性で管理レベルを分けることを提案します。
レベル | 目安 | 例 | 台帳で追加する確認 |
|---|---|---|---|
レベル1：補助 | 公開情報または影響の小さい社内情報を使い、人が成果物を確定する | 公開記事の要約、会議アジェンダの下書き | 用途、責任者、利用ツール、入力区分、確認者 |
レベル2：業務支援 | 社内情報や顧客関連情報を扱う、または業務システムを閲覧する | 社内規程の検索、顧客メールの下書き、CRM情報の参照 | データフロー、アクセス権、評価ケース、再確認日、例外対応 |
レベル3：重要操作・重要判断支援 | 個人・顧客・従業員へ大きく影響する、外部送信・金銭・権限変更などを含む | 採否判断の参考、顧客への自動送信、返金処理、発注・削除 | 責任者の明示、事前評価、承認ゲート、ログ、停止・復旧手順、定期レビュー |
この区分は、モデル名だけで決めません。同じモデルでも、入力品質、評価データ、許容できる誤り、出力が及ぼす影響によって必要な管理は変わります。生成AIの出力はもっともらしくても誤っていることがあり、NISTの生成AIプロファイルはこの種のリスクをconfabulationとして扱っています。NIST AI 600-1：Generative AI Profile
AI利用台帳を作る5ステップ
1. 対象範囲と目的を1文で決める
最初から「全AI・全社員・全業務」を対象にしないことが重要です。まずは、対象を次のように限定します。
- 対象組織：営業本部と情報システム部のみ
- 対象技術：外部の生成AIサービス、AI API、AI機能付きSaaS
- 対象行為：業務での入力、社内データ検索、外部システム連携
- 目的：入力可否と承認要否を判断し、未承認利用を減らす
業務選定から始めたい場合は、生成AI導入前の業務棚卸しと現場定着の進め方の業務棚卸しと組み合わせてください。業務棚卸しが「どこにAIを使うか」を決め、AI利用台帳が「採用した使い方をどう管理するか」を記録します。
2. 利用実態を3経路から集める
申告フォームだけでは、見つかるのは申告してもよいと考えられた利用に偏ります。少なくとも次の3経路を突き合わせます。
- 責任者申告：部署責任者に、用途・入力データ・連携先を申告してもらう。
- 契約・支出確認：購買、経費、法人カード、SSO、SaaS管理台帳から候補を拾う。
- システム確認：APIキー、OAuth連携、ブラウザ拡張、社内データ連携を確認する。
ここで見つかったが用途が不明なものは削除せず、「確認中」の状態で台帳に残します。未確認の利用をゼロ件として扱うより、調査対象として追える状態の方が安全です。
3. 1件ずつ、用途・データ・操作・確認者を確定する
「ChatGPTを営業で利用」のような抽象的な記載では、判断に使えません。次の質問に答えられる粒度まで具体化します。
- AIを使わない場合、誰がどの工程を行うか。
- AIは下書きを作るだけか、検索・登録・送信まで行うか。
- 入力に含まれ得る情報は何か。不要なら除外できるか。
- 誤った出力や操作が起きたら、誰にどの影響が出るか。
- 公開・送信・確定の前に、人が何を確認するか。
4. 承認ではなく「利用条件」を決める
台帳の状態を「承認済み」にするだけでは、利用者は現場で判断できません。利用条件を短文で記載してください。
記載例（架空の例）：
「公開済みの製品資料のみを入力可。顧客固有の価格、連絡先、契約内容は入力不可。出力は営業担当者が原資料と照合し、顧客への送信は担当者が実施する。CRMへの自動登録は不可。」
生成AIの社内ルール全体の設計は、生成AIの社内ルール設計で詳しく解説しています。AI利用台帳には、ルール全文を複製するのではなく、その利用ケースに適用される条件と例外承認の窓口を記録します。
5. 更新を「イベント」に結び付ける
四半期ごとの棚卸しだけでは、モデル変更や新しい連携によるリスクを見逃すことがあります。次のいずれかが起きたときに、台帳を再確認する運用を設けます。
- 利用モデル、提供者、料金プラン、データ利用条件が変わった。
- 入力データの種類が増えた。
- AIが使える権限や外部操作の範囲が広がった。
- 人の確認を減らす、または自動送信・自動登録を始める。
- 重大な誤回答、誤送信、権限逸脱、苦情が発生した。
- 評価指標が未達になった、または業務目的が変わった。
外部の利用者や第三者へ影響し得る利用では、説明に必要な情報を取り出せる状態にしておくと、問い合わせや見直しに対応しやすくなります。台帳には、利用者へ実際に開示・通知する文面そのものではなく、利用目的、利用範囲、責任者、確認手順、相談窓口など、説明の根拠となる情報を記録します。
コピペ用：AI利用台帳テンプレート
以下はMojiによる提案テンプレートです。スプレッドシートでは1行を1利用ケースとし、詳細な評価結果、契約確認、インシデント記録は別シートまたはチケットへリンクします。
列名 | 入力内容 |
|---|---|
利用ケースID | 一意のID |
利用ケース名 | 「部門名＋業務工程＋AIの役割」で命名 |
状態 | 確認中／試行中／利用中／条件変更審査中／停止 |
業務責任者 | 成果と業務判断に責任を持つ担当 |
運用担当 | 日常の設定・問い合わせ・更新を担う担当 |
目的・対象工程 | 改善対象とAIが担う工程 |
提供者・製品・モデル | サービス名、モデル名、利用リージョンなど確認可能な範囲 |
連携先・操作権限 | 検索、閲覧、下書き、登録、送信、削除など |
入力データ区分 | 公開情報／社内情報／個人情報／要配慮情報／営業秘密など |
入力制限 | 入力可・不可の具体的な条件 |
出力の利用先 | 社内下書き、顧客送付、公開、業務システム登録など |
人の確認・承認 | 誰が、何を、いつ確認するか |
評価指標・許容誤差 | 正確性、必須項目、誤操作、処理時間など |
評価結果へのリンク | 評価データ、報告書、チケットなど |
停止条件・復旧手順 | 止める条件、停止権限者、代替業務 |
確認日・次回見直し日 | 確認実施日と更新予定日 |
変更トリガー | モデル、データ、権限、用途、事故などの再審査条件 |
導入・継続・停止を判断するチェックリスト
利用開始前
- 対象業務と、AIを使わない場合の手順を説明できる。
- 入力するデータの区分と、入力しない情報が定義されている。
- AIが閲覧・作成・変更・送信できる対象が明確である。
- 出力または操作を確認する人と、確認基準が決まっている。
- 評価に使う実データまたは安全に加工したデータが用意されている。
- 未達時に停止・縮小・人手へ戻す条件が決まっている。
利用中
- 台帳の用途と、現場の実際の使い方が一致している。
- モデル、連携先、権限、入力データに変更がないか確認している。
- 品質、再作業、例外、苦情、インシデントを定期確認している。
- 評価結果に基づき、継続・条件変更・停止を判断している。
停止・見直し時
- 利用停止後に残るデータ、APIキー、OAuth連携、権限を無効化する担当が決まっている。
- AIが止まっても業務を継続できる代替手順がある。
- 発生した失敗と対策を、次の利用ケースの審査・評価へ反映できる。
よくある失敗と直し方
失敗 | なぜ問題か | 直し方 |
|---|---|---|
ツール名と契約部署だけを記録する | 同じツールの異なる利用リスクを区別できない | 業務ケース単位で、用途・データ・操作・確認者を記録する |
個人情報の有無だけを記録する | 目的外利用、入力の必要性、提供者側の取り扱いを判断できない | データの種類、目的、入力制限、設定・契約の確認先を残す |
「人が確認する」とだけ書く | 誰が何を確認するか不明で、確認が形式化する | 確認対象、確認者、送信・確定前のゲートを具体化する |
導入時だけ評価する | モデル変更、業務変更、データ変化で品質が変わっても気付けない | 変更トリガーと定期レビューを台帳に持たせる |
全利用に重い審査を課す | 低リスク利用が隠れ、台帳が更新されなくなる | データ・影響・不可逆性で管理レベルを分ける |
経営・事業責任者が最初の会議で決めるべき5項目
- 台帳のオーナー：情報システム、法務、事業部のいずれか単独ではなく、誰が最終的な更新責任を持つか。
- 対象範囲：外部AIサービスだけか、AI機能付きSaaS、社内開発、API連携まで含めるか。
- 管理レベル：どの条件なら簡易登録、追加評価、責任者承認を求めるか。
- 例外ルール：緊急時に誰が暫定利用を認め、いつまでに正式審査へ戻すか。
- 判断に使う指標：利用数ではなく、対象業務の品質、時間、再作業、事故、利用定着をどう見るか。
AI導入の成否をPoCのデモだけで決めず、本番移行・利用定着・停止までの基準を先に決める考え方は、AI PoCを本番化する進め方も参考にしてください。
まとめ：AI利用台帳は「AIを増やす表」ではなく、任せ方を判断する仕組み
AI利用台帳の目的は、利用を一律に止めることではありません。どのAI利用なら安全に広げられるか、どこに人の確認や追加評価が必要か、何が変われば再確認すべきかを、部署横断で判断できるようにすることです。
Mojiの提案例としては、まず高頻度に使われるAI利用ケース、個人情報・機密情報を扱うケース、外部操作を伴うケースから20件程度を対象に始めます。台帳の完成度よりも、用途・データ・操作・確認者・停止条件を曖昧にしたまま利用を広げないことを優先してください。