「うちは生成AIを何に使っているのか」と取引先や監査の場で問われて、その場で答えに詰まることがあります。利用ルールは配ってある。契約書もある。禁止事項の一覧も回覧した。それでも、どの部署がどの業務でどう使い、そこへ何のデータが入り、出力がどこへ行っているのかは、誰の手元にもまとまっていない。この記事では、生成AIの利用実態を、禁止一覧でも製品一覧でもなく、責任者と見直しへつながる管理記録として残す方法を整理します。
対象は、中小企業の経営者、AI・DXの責任者、情報システムやリスク管理の担当者、そして各部門で実際に使う側の責任者です。特定の製品やデータベースの知識は前提にしません。導入済みのもの、試行中のもの、会社が把握できていない利用が混在している状態を想定します。サービスの比較や採用審査、社内ルールの本文、権限の割り当て表、資産管理台帳の全体設計、法令上の届出が必要かどうかの判定は、本稿では扱いません。
- 1 発見：稟議や契約からたどれる利用と、たどれない利用の双方を拾う。会社が把握していなかった利用も、ここで台帳の入口へ入る
- 2 登録：業務目的を持つ use case を一行として立て、名称・目的・owner・利用者・使っているサービスと版・入力するデータの区分・出力の行き先を書く
- 3 リスクに応じた確認：人の確認を経ない外部への作用があるか、人の評価や採否に影響するかを見て、深く確認する行を絞る
- 4 運用：自社で決めた間隔で見直し、見直した日・見た人・変えた欄を残す。確かめていない項目は空欄のまま見えるようにしておく
- 5 変更・停止・廃止：サービスや版の切替、用途の拡大、業務の終了に応じて行を更新する。廃止した行も、定めた期間は台帳の中に置く
- 各行から伸びるリンク：サービス審査の記録、データの分類、権限表、試験と監視の記録、事故対応手順。台帳は内容を抱え込まず、在り処を指す
矢印は行が動く順序を表します。この5段の並びは本記事の編集上の整理であり、NIST が定めた手順ではありません。米国国立標準技術研究所（NIST）の『AI RMF 1.0』本体は、Core の冒頭で 「Actions do not constitute a checklist, nor are they necessarily an ordered set of steps.」（各アクションはチェックリストを構成するものではなく、順序づけられた手順の集合であるとも限らない）と明記しています。
1. ルールと契約の一覧だけでは利用実態が見えない
利用ルール、禁止事項の一覧、契約中のサービスの一覧、稟議の記録。並べるとひととおり揃って見えますが、「今この会社で、生成AIはどの業務にどれだけ使われているか」と問われると、どの文書もその形の答えを持っていません。ルールは何を許すかを書いた文書であり、契約一覧は何を買ったかの記録だからです。使われ方は、そのどちらにも書かれていません。
NIST の『AI RMF Playbook』は、GOVERN 1.6 の解説で、機能するAIシステム台帳が「速やかに解消し得る」問いの例を挙げています。書き出しは 「A serviceable AI system inventory may allow for the quick resolution of:」（機能するAIシステム台帳は、次の事柄の速やかな解消を可能にし得る）で、serviceable（機能する）という条件と may allow（可能にし得る）という留保がついています。
- 「このモデルが最後に更新されたのはいつか」といった、単一のモデルに関する個別の照会
- 「自組織内で現在いくつのモデルが配備されているか」、「自組織のモデルによって何人の利用者が影響を受けるか」といった、全モデルを横断する高い視点からの照会
この二種類の問いが、ルール一覧でも契約一覧でも答えられなかったものです。台帳の中心にある Core outcome は GOVERN 1.6 で、「AIシステムを台帳化する仕組みが整備され、組織のリスク優先度に応じて資源が配分されている」と書かれています。仕組みと、そこへ配る資源の話であって、文書の枚数の話ではありません。
参照する資料の性格
AI RMF Playbook は自身について 「The Playbook is neither a checklist nor set of steps to be followed in its entirety.」（Playbook はチェックリストでも、全体として従うべき手順の集合でもない）、「Playbook suggestions are voluntary. Organizations may utilize this information by borrowing as many – or as few – suggestions as apply to their industry use case or interests.」（Playbook の提案は自主的なものである。組織は自らの業界のユースケースや関心に当てはまる提案を、多く借りることも、ごくわずかだけ借りることもできる）と述べています。本稿は「NIST 準拠」といった表現を用いません。また、これらは米国の自主的な枠組みであり、日本企業に対する義務を定めた文書ではありません。
社内ルールの本文そのものは小さな会社のAI利用ルールの作り方で扱っています。本稿が扱うのは、そのルールが実際にどこへ適用されているのかを、後から確かめられる形で残す側です。
2. 台帳の単位を「サービス」ではなく「業務目的を持つ use case」で決める
台帳を作ろうとして最初に決まらないのが、一行が何を表すのかです。契約しているサービスを一行にすると表は短くなりますが、同じサービスが社内の複数の業務で使われている場合、その一行は、どの業務を見ても正確とは言いにくくなります。議事録の下書きに使うのと、顧客への回答文の下書きに使うのとでは、入るデータも、外へ出る影響も、間違えたときの結果も違うためです。
本稿は、一行の単位を「業務目的を持つ use case」に置くことを提案します。同じサービスでも目的が違えば別の行になり、逆に複数のサービスを併用している一つの業務は一行にまとまります。台帳を見る側が知りたいのは製品の名前ではなく、その利用が業務のどこに触れているかだからです。
この単位の選び方は、本記事の編集判断です。NIST の Playbook は、台帳について一貫して models or systems（モデルまたはシステム）を単位として語っており、「use case ごとに登録する」とは述べていません。本稿が use case を単位に置くのは、生成AIでは同じサービスが多目的に使われ、製品単位の一行では業務上のリスクが判別しにくいという実務上の理由によるものです。NIST を根拠として提示できる整理ではありません。
ただし、目的を書き残すこと自体には対応する outcome があります。MAP 1.3 は「AI技術に関する組織のミッションと関連する目標が理解され、文書化される」、MAP 1.4 は、事業上の価値または事業利用の文脈が明確に定義される（既存のAIシステムを評価する場合には再評価される）としており、その Suggested Action にも事業上の価値または事業利用の文脈を文書化することが挙げられています。
MAP 1.3 の解説は、目的を書く効用をこう述べます。「AIシステムの具体的な事業上の目的を、より広い社会的価値の文脈の中で定義し文書化することは、チームがリスクを評価する助けとなり、配備するかどうかの「go/no-go」の判断の明確さを高める」。目的の欄が「業務効率化」だけで埋まっている台帳は、この助けを受け取れていません。
3. 最低 field：名称、目的、owner、利用者、service／model、入力データ区分、出力の用途、外部作用、判断への影響、status
欄を決める前に、原典が何を挙げているかを先に確認します。Playbook が挙げているものと、本稿が提案するものは範囲が違うため、表を分けて示します。
Playbook の解説が挙げている項目
GOVERN 1.6 の解説は、AIシステム台帳を「AIシステムまたはモデルに関連する成果物を整理したデータベース」と説明したうえで、こう続けます。「It may include system documentation, incident response plans, data dictionaries, links to implementation software or source code, names and contact information for relevant AI actors, or other information that may be helpful for model or system maintenance and incident response purposes.」（それは、システム文書、インシデント対応計画、データディクショナリ、実装ソフトウェアまたはソースコードへのリンク、関連するAI関与者の氏名と連絡先、あるいはモデル・システムの保守やインシデント対応に役立ち得るその他の情報を、含み得る）
「may include」（含み得る）であり、末尾は「or other information...」で開いたまま閉じられています。必須の欄を定めた一覧ではなく、例示です。
Suggested Actions の側も、台帳化すべき属性を定める方針を確立すること、という形です。挙がっている属性は解説と重なり、その例示は 「e.g,」（原典のままのタイポ）で導かれています。属性そのものを指定しているのではなく、「属性を定める方針を組織が置く」という形になっています。
本記事が提案する最低 field
上の例示は、モデルや自社開発システムの保守を念頭に置いたものです。中小企業が外部の生成AIサービスを業務で使う場面へ持ってくると、そのままでは埋められない欄と、足りない欄が出ます。以下は本稿が提案する10欄で、右列に原典との対応の有無を明記します。
| 欄 | 書く内容 | 原典との対応 |
|---|---|---|
| 名称 | この use case を社内で呼ぶ名前 | 対応なし（本記事） |
| 目的 | どの業務のどの工程を、何のために | MAP 1.3／1.4 が目的の文書化を扱う。欄名は本記事 |
| owner | この行の内容と結果について答える人 | 対応なし（下の注記） |
| 利用者 | 使う範囲。部署、習熟度、社外を含むか | 対応なし（本記事） |
| service／model | 使っている製品、版、確認日 | 解説の system documentation に近いが、欄名は本記事 |
| 入力データ区分 | 入れてよいと決めたもの、入れないと決めたもの | 対応なし（本記事） |
| 出力の用途 | 出力の行き先。社内限りか、社外へ出るか | 対応なし（本記事） |
| 外部作用 | 人の確認を経ずに送信・登録・実行が起きる経路があるか | 対応なし（本記事） |
| 判断への影響 | 人の評価・採否・取引条件に影響するか | 対応なし（本記事） |
| status | 試行中／運用中／停止中／廃止済み | GOVERN 1.7 の解説が廃止済みの台帳内保持に触れる |
右列に「対応なし」と書いた欄は、本稿が実務上の必要から足したものです。とくに外部作用と判断への影響の二欄は、生成AIの使われ方が「文章を作る」から「作って送る」「作って決める」へ広がったときに、リスクの段が変わる場所です。この段差を台帳の上で見えるようにするために置いています。
「責任者」という語は、この文脈で二つの意味を持ちます。混ぜると出典が壊れます。
Playbook の Suggested Action が挙げているのは「台帳の維持に責任を負う特定の個人またはチームを定める方針を確立する」であり、Transparency & Documentation の問いも「AIシステム台帳の詳細を文書化し維持する責任者は誰か」です。いずれも「台帳そのものを維持する責任者」を指しています。
本稿が最低 field へ置いた use case ごとの owner は、これとは別の概念です。個々の利用の内容と結果について答える人であり、上記の NIST の記述を根拠にはできません。台帳の管理者を一人立てることと、一行ごとに答える人がいることは、別に決める事項です。本稿の副題でいう「責任者」は、後者——use case ごとの owner——を指します。
4. 証拠への link：service 審査、data 分類、権限表、test／monitoring、incident plan
10欄を決めると、次に起きるのは欄の増殖です。審査結果も、データの取り扱いも、試験の記録も台帳へ書き込みたくなります。書き込んだ台帳は、更新が止まりやすくなります。
先に見たとおり、Playbook の解説は台帳を「成果物を整理したデータベース」と呼び、含み得るものとして「実装ソフトウェアまたはソースコードへのリンク」を挙げています。リンクという語が原文に入っている点が要点です。台帳は内容を抱え込む場所ではなく、内容の在り処を指す場所として説明されています。
| 台帳から指す先 | 何を指すか | 原典との対応 |
|---|---|---|
| サービス審査の記録 | そのサービスを採用してよいと判断した根拠 | 対応なし（本記事） |
| データの分類と取り扱い | 入力してよい区分の定義と、その根拠 | data dictionaries が近いが同一ではない |
| 権限表 | 誰がどの範囲で使えるか | 対応なし（本記事） |
| 試験と監視の記録 | どの条件で何を確かめ、何を確かめていないか | 対応なし（本記事） |
| 事故対応手順 | 気づいた人の初動、連絡先、記録の残し方 | incident response plans（解説・SA の双方） |
サービスそのものを採用してよいかの審査は、この台帳の仕事ではありません。何を証拠として集め、どの条件で採用・保留・不採用を決めるかは生成AIサービス選定の実務チェックリストで扱っています。台帳の側が持つのは、その審査結果がどこにあるかを指す一本のリンクです。
同じ考え方で、本番の業務へ載せてよいと判断した根拠は生成AI PoCの設計──本番移行を判断する受入条件の判定記録へ、誰がどの範囲で使えるかはAIエージェントを最小権限で使うための権限設計の権限表へ、入力してよい情報の区分はAIに渡す情報の管理と権限設計の分類へ、気づいた人の初動は生成AIインシデントの初動対応へ、それぞれリンクで結びます。ただし、サービス審査・データ分類・権限表・試験記録へのリンクを台帳へ置くという整理は、本稿によるものです。
この形にすると、リンク先が無いことも情報になります。権限表の欄に指す先がない行は、誰がどこまで使えるかが決まっていない行です。
5. 全件把握と risk 優先の両立
「全部載せるのは無理だ」と「危ないものだけ見ればいい」は、どちらも台帳の議論を止めます。原典は、この二つを同じ一文の中に置いています。
Playbook の Suggested Action は次のとおりです。「Establish policies that define which models or systems are inventoried, with preference to inventorying all models or systems, or minimally, to high risk models or systems, or systems deployed in high-stakes settings.」（どのモデルまたはシステムを台帳化するかを定める方針を確立する。全モデル・全システムを台帳化することを優先される考え方とし、最低限であれば、高リスクのモデル・システム、または影響の大きい場面に配置されたシステムを対象とする）
読み方を取り違えないようにします。「preference」は優先される考え方であって、全件登録の義務ではありません。同じ一文の中に 「or minimally」（最低限であれば）以下が並んで置かれています。解説の側も 「Typically inventories capture all organizational models or systems, as partial inventories may not provide the value of a full inventory.」（通常、台帳は組織の全モデル・全システムを収める。部分的な台帳では、全体を収めた台帳の価値が得られないことがあるためである）と述べています。「Typically」（通常は）と「may not」（得られないことがある）を落とさずに読むと、これは断定ではなく傾向の記述です。
本稿が実務へ落とすなら、次の形になります。全件は薄く、一部は深く。把握できている use case については名称・目的・owner・status の四欄だけを埋め、外部作用や判断への影響がある行についてのみ、証拠へのリンクと見直しの記録を揃える。この二段の運用は本稿の整理です。リスクを何段に分けるか、何を高リスクとするかについて、参照した資料に基準はありません。自社で決める空欄です。
全件を載せられない理由は、入力の手間だけとは限りません。何が使われているかを会社が把握していない、という側にあることがあります。欄の設計をどれだけ精緻にしても、この部分は埋まりません。埋めにいくのは節7の側の作業です。
6. 登録、変更、定期 review、停止、廃止の lifecycle
台帳が古びる一因は、書いた後に何も起きないことにあります。行が動く契機を先に決めておくと、更新は思い出す作業ではなく手順になります。この節では、登録済みの行が動く契機を五つに分けて扱います。
登録の根拠は GOVERN 1.6 です。見直しの側には GOVERN 1.5 があり、「リスク管理プロセスとその結果についての継続的な監視と定期的な見直しが計画され、組織の役割と責任が明確に定義される。定期的な見直しの頻度を決定することを含む」とされています。頻度そのものを決めることが outcome の中に入っている点が要点で、具体的な間隔が示されているわけではありません。
背景は解説にあります。「AIシステムは動的であり、配備時または配備後に予期しない振る舞いをすることがある」。GOVERN 1.6 の Transparency & Documentation にも、このAIの目的を踏まえたとき依然として正確か、偏りがないか、説明可能かを確かめる適切な間隔はどれくらいか、という項目があります。問いの形で置かれており、答えは書かれていません。
廃止には GOVERN 1.7 があり、AIシステムを安全に、かつリスクを増大させず組織の信頼性を損なわない形で廃止し段階的に停止するための、プロセスと手順が整備されている、という outcome を置いています。解説は 「Irregular or indiscriminate termination or deletion of models or AI systems may be inappropriate and increase organizational risk.」（モデルまたはAIシステムの不規則あるいは無差別な終了・削除は、不適切となり、組織のリスクを高めることがある）と述べ、理由として規制上の要求や将来の調査に関わり得ることを挙げています。止めることと、記録ごと消すことは別に扱う、という読み方になります。
廃止の方針が通常扱う事項として、Suggested Action は、評判・事業継続・上下流の依存関係・規制上の要求（例：データの保持）・将来の調査の可能性・後継システムへの移行を挙げています。「規制上の要求（例：データの保持）」は、保持期間を定めよという指示ではありません。年数は参照した資料に示されていません。
| 契機の区分 | 行が動く契機 | 台帳に残すこと |
|---|---|---|
| 登録 | 稟議、契約、部門からの申告、把握外の利用の発見 | 10欄の初期値と、登録日 |
| 変更 | サービスや版の切替、用途の拡大、利用範囲の拡大 | 変更前の値、変更日、理由 |
| 定期見直し | 自社で決めた間隔、または監視で拾った事象 | 見直した日、見た人、変えた欄、確かめていない項目 |
| 停止 | 事故、リスクが許容範囲を超えたとき、代替への移行 | 停止日、判断した人、再開の条件 |
| 廃止 | 業務の終了、後継システムへの移行の完了 | 廃止日、status の更新、台帳内に置く期間 |
この五つの契機の区分も、本記事の編集上の整理です。引用した GOVERN 1.5／1.6／1.7 の outcome は達成されるべき状態であり、順序づけられた手順ではありません。とくに「変更」の段は、本稿が実務から足したものです。なお、モデルや参照データを変更したときに何をどこまで再確認するかは生成AIの変更管理──モデル・プロンプト・参照データの更新を再評価するで扱っています。
7. 未承認利用を見つけたときの扱い──断罪より事実確認と risk 判定
台帳を作り始めると、載っていない利用が出てきます。個人の契約で使っていた、無料の範囲で試していた、部署の判断で入れていた。ここでの初動が、その後に台帳が実態を持てるかどうかを左右します。処分だけを前面に出すと、報告をためらわせる可能性があります。そうなると台帳は「報告してよいものだけの一覧」に近づきます——これらはいずれも本記事の実務上の懸念であり、参照した資料が述べていることではありません。
原典に近い記述はありますが、同じものではありません。Playbook の MAP 1.5 の Suggested Action は 「Review uses of AI systems for "off-label" purposes, especially in settings that organizations have deemed as high-risk. Document decisions, risk-related trade-offs, and system limitations.」（とくに組織が高リスクと判断した場面について、AIシステムの「off-label」な目的での利用を見直す。判断、リスクに関するトレードオフ、システムの限界を文書化する）と述べ、Transparency & Documentation は 「What conditions and purposes are considered "off-label" for system use?」（システムの利用について、どのような条件と目的が「off-label」と見なされるか）と問うています。
「off-label」は、想定されていない目的での利用を指します。会社が把握していないツールの利用（いわゆる shadow AI）とは別の概念です。本稿は、Playbook が挙げる「想定外の目的での利用を見直し、判断とトレードオフと限界を文書化する」という考え方を、把握外の利用を見つけた場面へ応用しています。この応用は本記事の編集判断であり、NIST がそう述べているのではありません。
実務としては、確かめる順序を決めておくと処分の話へ流れにくくなります。何の業務に使っていたか、何を入力していたか、出力はどこへ行ったか、人の確認を経ずに社外へ出た経路があったか、そして今後も必要か。ここまでが事実確認で、リスクの判定はその後です。判定の結果は、台帳へ一行を足して use case として登録するか、代替の手段へ移すか、止めるかのいずれかになります。止めると決めた場合も、判断した理由は台帳へ残します。同じ利用が別の部署で再び始まったとき、そこが参照先になります。正規の形へ移す進め方はAI導入支援とは何か──中小企業が外部支援を使う前に整理すべき判断軸で扱っています。
体制が薄い組織については、GOVERN 1.5 の解説に手がかりがあります。「Establishing and maintaining incident response plans can reduce the likelihood of additive impacts during an AI incident. Smaller organizations which may not have fulsome governance programs, can utilize incident response plans for addressing system failures, abuse or misuse.」（インシデント対応計画を策定し維持することは、AIインシデントの際に影響が積み重なる可能性を減らし得る。十分なガバナンス体制を持たないことがある小規模な組織も、システムの障害、乱用、誤用への対処にインシデント対応計画を活用できる）。体制が整うのを待たずに始められる、と読める記述です。
8. 一枚の利用台帳テンプレート
ここまでの欄を一枚へ落とすと、そのまま台帳の様式になります。この様式は本記事の編集上の整理であり、NIST が定めた様式ではありません。
| 欄 | 書くこと | 対応する節 |
|---|---|---|
| 管理番号・名称・登録日 | 社内で一意に呼べる名前と、いつ載せたか | 節3 |
| 目的（業務・工程） | どの業務のどの工程を、何のために | 節2 |
| owner | この行の内容と結果について答える人。交代時の引き継ぎ | 節3 |
| 利用者の範囲 | 部署、習熟度、社外を含むか | 節3 |
| service／model と版 | 使っている製品、版、確認日 | 節3 |
| 入力データ区分 | 入れてよいと決めたもの、入れないと決めたもの | 節3 |
| 出力の用途 | 出力の行き先。社外へ出るか | 節3 |
| 外部作用 | 人の確認を経ない送信・登録・実行の経路があるか | 節3 |
| 判断への影響 | 人の評価・採否・取引条件に影響するか | 節3 |
| 証拠へのリンク | 審査、データ分類、権限表、試験と監視、事故対応手順 | 節4 |
| 見直しの間隔と直近の見直し日 | 間隔は自社で決める空欄。見た人も書く | 節6 |
| status と変更の記録 | 試行中／運用中／停止中／廃止済み、変更前の値と理由 | 節3・節6 |
| 未確認の項目 | 確かめていないと分かっていること | 節9 |
数値の欄は空欄のまま置いています。自社のリスクとユースケースに応じて埋める欄です。
この様式で効くのは、最後の一行です。未確認の項目が空欄のまま目に見えることが、台帳が「整った一覧」に見えてしまうことへの歯止めになります。埋まっていない欄があること自体は問題ではありません。埋まっていないと分かったうえで判断するのか、気づかずに判断するのかが違います。
9. 台帳で分かること／分からないこと
台帳が整うと、それが安全や適法の証明のように見えてくることがあります。ここは分けておきます。
| 台帳で分かること | 台帳では分からないこと |
|---|---|
| 現在どれだけの use case が動いているか（横断的な照会） | 各 use case の出力の内容が正しいかどうか |
| ある use case が最後に見直されたのはいつか（個別の照会） | その利用が法令や契約に適合しているかどうか |
| 各行の owner が誰か、利用者がどこまで広がっているか | 台帳に載っていない利用が存在しないこと |
| 証拠へのリンクが空になっている行はどれか | 残っているリスクが許容範囲の内側にあるかどうか |
| 人の確認を経ない外部作用を持つ行はどれか | その利用が社内で承認されているかどうか |
左側の上二行は、節1で引いた照会の型です。「serviceable」（機能する）という条件と「may allow」（可能にし得る）という留保がついた記述であり、台帳があれば分かる、と書かれているのではありません。下三行は、本稿が節3・節4で置いた欄から導いたものであり、原典の照会の型そのものではありません。
右側の「分からないこと」は、本記事が読者保護のために置いた限定です。本稿が参照した NIST の資料は、台帳の限界について述べていません。NIST を根拠に提示できる整理ではなく、本稿が実務上の必要から加えたものです。載っているのは「その利用を把握している」という事実であり、載っていない行があるという前提で運用するほうが、実態に近いはずです。節7を一度きりの棚卸しではなく続く作業として置いているのは、このためです。
まとめ
生成AIの利用台帳を、禁止事項の一覧でも製品の一覧でもないものにするために要るのは、三つです。一行の単位を業務目的を持つ use case に置くこと、各行に owner と、行が動く契機を持たせること、そして証拠を抱え込まずリンクで結び、空のリンクを空のまま見せること。節8の様式は、この三つを一枚へ落とすためのものです。
根拠として引いた GOVERN 1.6（節1）は、達成されるべき状態を述べたものであり、欄の名前も、見直しの間隔も、リスクの段数も指定していません。空欄は、自社で埋める場所として残されています。
手元で把握している生成AIの利用をいくつか書き出して、節8の様式の欄を上から埋めてみてください。そこで手が止まった欄が、台帳より先に社内で決める事項です。
引用元・参考文献
公的機関・一次情報
- NIST『Artificial Intelligence Risk Management Framework (AI RMF 1.0)』（NIST AI 100-1、2023年1月。GOVERN 1.5／1.6／1.7、MAP 1.3／1.4 の各 outcome、および「Actions do not constitute a checklist, nor are they necessarily an ordered set of steps.」／確認日：2026年8月27日）：https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
- NIST『AI RMF Playbook』GOVERN 機能（GOVERN 1.5／1.6／1.7 の About、Suggested Actions、Transparency & Documentation。台帳の説明「An AI system inventory is an organized database of artifacts...」、「A serviceable AI system inventory may allow for the quick resolution of:」、「Typically inventories capture all organizational models or systems...」、および廃止に関する記述を含む／確認日：2026年8月27日）：https://airc.nist.gov/airmf-resources/playbook/govern/
- NIST『AI RMF Playbook』MAP 機能（MAP 1.3／1.4／1.5 の About、Suggested Actions、Transparency & Documentation。目的・事業文脈の文書化、および「off-label」な目的での利用の見直しに関する記述／確認日：2026年8月27日）：https://airc.nist.gov/airmf-resources/playbook/map/
※ 本記事が編集上の整理として置いたものを明示します。(1) 登録の単位を「業務目的を持つ use case」に置く判断——Playbook は台帳について一貫して models or systems を単位に語っており、use case 単位の登録を述べていません。(2) 節3の最低 field のうち、名称・利用者・入力データ区分・出力の用途・外部作用・判断への影響、および use case ごとの owner——原典に対応する記載がありません。Playbook が挙げる責任者は「台帳を維持する責任者」であり、本記事の use case ごとの owner とは別概念です。(3) 節6の五つの段の並びと、とくに「変更」の段——引用した outcome は達成されるべき状態であり、順序づけられた手順ではありません。(4) 節8の一枚の様式——NIST が定めた様式ではありません。(5) 節7の未承認利用への適用——Playbook が扱う「off-label」は想定外の目的での利用であり、会社が把握していないツールの利用とは別概念です。本記事はこれを応用しています。(6) 節9の「分からないこと」と、同節の表の左列下三行——参照した資料は台帳の限界を述べておらず、本記事が読者保護のために置いた限定です。(7) 節4の証拠リンク先のうち、サービス審査・データ分類・権限表・試験と監視——原典に対応する記載がありません。なお AI RMF も Playbook も自主的なものであり、Playbook の Suggested Actions は提案です（"Playbook suggestions are voluntary."）。いずれも日本企業に対する義務を定めた文書ではありません。AI RMF 1.0 は改訂作業中であることが公式ページに告知されており（"The AI RMF 1.0 is being updated. A revised version is in progress."）、Playbook についても "The Playbook will be updated after the AI RMF is revised." と記されています。改訂版の公表予定日は表示されていません（2026年8月27日確認）。本稿に見直しの頻度、保存や保持の年数、リスクの段数、件数の数値を置いていないのは、参照した資料にそれらの指定がないためです。