生成AIの社内利用ルール｜1業務から始める6項目の作り方

今日やることは3つです。まず、試す業務を1つ選び、目的・入れるもの・出るもの・終わり方まで1文で書きます。次に、切り分け4問で、専門部門へ先に回すべき業務かどうかを見分けます。最後に、6項目をまとめて関係部門へ確認を依頼します。依頼票には、今回の対象か（適用範囲）、裏づけを取れたか（根拠状態）、いま出せる条件は何か（提案条件）を分けて書きます。

共通規程を先に完成させようとすると、現場は動けません。当社は、共通規程より先に1業務の設計票を作るほうが早いと考えます。ここでいうガバナンス（誰が、何を、どの証拠で、いつ見直すかを決めて記録する仕組み）は、この6項目の設計票へ落とし込みます。先に代表用途を1文にし、高リスクだけ専門部門へ回し、残った用途の確認依頼を出します。許可の記録は、関係部門の確認が戻ってからです。本記事でいう関係部門は、法務・情報セキュリティ・情報システム・規程管理者といった、確認依頼の宛先を指します。

依頼を出す前と、確認が戻ったあとでは、使う道具が変わります。依頼の前に使うのは、今日の3作業と、次章の切り分け4問です。確認が戻ったあとに使うのは、項目ごとの承認4結果と、用途全体の試行5状態です。

まず、試す業務を1つだけ選んで1文で書きます。これを代表用途と呼びます。AIに入れてよいものも、仮に決めておきます。そのうえで、次の切り分け4問を確かめます。人の権利・安全・財産に大きく響くか。資格の要る判断が混じるか。AIが外部へ自動で送る、または実行するか。間違えたときに、説明して取り消す手立てが無いか。1つでも当てはまるなら、6項目の確認依頼より先に専門部門へ回します。取り返しがつかない用途を、自社だけで決めないためです。

代表用途は「誰が、何を入力し、AIが何を作り、誰の確認で完了するか」を1文で書きます。人事の例は「人事担当者が社内規程を入力し、AIが問い合わせ回答案を作り、規程管理者の確認で完了する」です。同じ型で、営業なら「営業担当者が公開カタログだけを入力し、AIが提案文案を作り、営業責任者の確認で完了する」と書けます。どちらも見本であり、入力範囲も仮置きします。

切り分け4問が当てはまらなくても、自動的に許可にはなりません。次は適用範囲・根拠状態・提案条件を別欄にし、確認依頼へ進みます。

切り分け4問のいずれかがYesなら、先に専門部門へ回します。許可の記録は、権限者が確認した後にだけ置きます。

AIに入れてよいものの確認と、出てきた結果の確認は、分けて決めます。結果は、何と照合してから使うかを決め、確認した人を記録します。使える人と、記録の保存先・保存期間も先に決めます。問題が起きたときに止める・報告する・再開する流れは、1本にまとめておきます。

出力確認は「人が見る」だけでは足りません。社内規程の要約なら原文との一致、数値なら元データとの一致、対外文面なら担当者の承認など、照合対象を先に決めます。確認できないまま外部へ送る経路は、開始条件から外します。

権限は利用者・管理者・承認者を分け、共有範囲とログの保存先を決めます。ログに個人データや機密が含まれる場合は、保存期間と閲覧権限も確認します。学習利用の可否は入力の項目、国外送信は入力と権限・ログ、契約上の保持期間は権限・ログで見ます。再開を認める人も、事故対応の承認者として先に置きます。

確認依頼を出す前に、依頼前4分岐（進める・条件を直す・別手続きへ移す・止めて相談する）から1つ選びます。進めるのは、入口9欄がそろっているときです。条件を直すのは、確認先や期限がまだ埋まらないときです。別手続きへ移すのは、切り分け4問に当てはまり、専門部門の確認が先のときです。止めて相談するのは、代表用途か確認先が決められないときです。確認が戻ったあとの承認4結果と試行5状態は、最終章で示します。承認は、根拠がそろってから記録します。

依頼を出す前の分岐は、次の4つです。本記事ではこれを依頼前4分岐と呼びます。確認が戻ったあとの承認4結果（許可・条件付き・不許可・要エスカレーション）とは別物なので、ここでは使いません。要エスカレーションは、専門部門や権限者へ判断を上げる状態です。

• 進める（確認依頼へ進む）：入口9欄がそろっている。承認判断は未記録のまま渡す
• 条件を直す：確認先・期限など9欄のどれかが未定で、埋められる。埋めてから依頼する
• 別手続きへ移す：切り分け4問のいずれかが疑わしい。確認依頼より先に専門部門へ回す
• 止めて相談する：代表用途または確認先が埋められないため、依頼しない

確認依頼の前に、次の9欄をそろえます。本記事ではこれを入口9欄と呼び、そのまま1枚の入口票になります。内訳は3種類です。適用範囲・根拠状態・期限・次回見直し日の4欄は、6項目で共通なので、表の直後にまとめてあります。提案条件・確認先・担当者の3欄は、項目ごとに違うので、下の表にあります。代表用途と戻り先の2欄は用途に1つずつで、代表用途は前章の1文を、戻り先は表の下の依頼文を使います。表にある「依頼と同時にやること」の列は、9欄には数えません。

• 代表用途：誰が何を入れ、AIが何を作り、誰の確認で終わるか（1文）
• 適用範囲：項目全体が対象か（適用対象／対象外）。使わない範囲は提案条件へ
• 根拠状態：裏づけを確認したか（依頼を出す時点は未確認）
• 提案条件：6項目ごとに、いま出す条件（下の表の提案条件の列）
• 確認先：6項目ごとに、誰へ確認するか（下の表の確認先と担当の列）
• 期限：いつまでに回答がほしいか（見本は5営業日以内）
• 担当者：6項目ごとに、確認や記録を行う人（下の表の確認先と担当の列）
• 次回見直し日：いつ見直すか（見本は試行開始後の初月末）
• 戻り先：回答を集約する人（見本は業務責任者）

表と依頼文は人事の見本1本です。同じ1文の型で営業文面や議事録要約を書くときは、提案条件・確認先・担当者だけを項目ごとに変え、共通する4欄は使い回します。ただし、この見本を埋めただけでは許可になりません。承認は権限者の確認後に記録します。

NIST・デジタル庁・ICOの3つは、確認の抜けを探す補助線として使います。使ってよいかを決めるのは、自社の担当部門と、契約・規程です。デジタル庁の第2.0版は、行政機関が生成AIを調達・利活用するための資料です。同じ版のPDFの附則には、全体の施行日として2026年9月1日と、それに先立つ段階的な適用が定められています。2026年8月18日に確認した時点では、まだ施行前でした。NISTのAI RMF 1.0は更新中、ICOのガイダンスは見直し中と、それぞれの原典に書かれています。3つとも、2026年8月18日に確認した時点の公開内容なので、いま読んでいる時点では変わっていることがあります。導入するときは、原典を開き直します。

明日の確認依頼を出すだけなら、この章は飛ばして構いません。3資料の位置づけはそれぞれ違います。NISTは任意、デジタル庁は行政向け、ICOはデータ保護法域です。法的性格が違うため、合格点や順位にはしません。NISTが示すのは、AI RMF Core（Govern・Map・Measure・Manageの4機能で整理する枠組み）に沿う提案です。Playbookは、AI RMF 1.0の改訂後に更新される予定です。

NIST AI RMF Playbookは、AI RMF Coreの4機能の各サブカテゴリーに沿う任意の提案アクションを示す実務資料です。チェックリストとして全体を順に実行するものではありません。法的基準や自社の許可判断を置き換えるものではなく、原典の節名・ページは末尾の参考資料で確認できます。

6項目は本記事の整理です。守る線は一つです。公開資料だけでは自社の許可範囲を確定せず、担当者と契約・規程を確認する。そのうえで自社の契約・規程・データ分類へ置き換え、関係部門の合意を設計票へ残します。本記事が読んだのは、この3資料だけです。日本の民間向けに出ている指針、たとえば総務省・経済産業省のAI事業者ガイドラインは範囲に入れていません。自社のルールでどう扱うかは、法務と情報セキュリティで確定します。

確認が戻ったら、項目ごとに、承認4結果（許可・条件付き・不許可・要エスカレーション）のどれかを記録します。用途全体は、試行5状態（未集約／試行可／条件充足後に試行可／試行不可／要エスカレーション）に集約します。承認が1項目でも未記録なら、用途全体は未集約のままにし、試行可にも条件充足後に試行可にも置きません。教育記録と版管理の担当を決め、質問・事故・仕様変更・定期日を見直しのきっかけにします。用途全体が試行可になってから小さく試し、記録を次の用途へ渡します。

確認が戻ったら、まず項目ごとに承認4結果を記録し、そのあとで用途全体を試してよいかを決めます。承認が1項目でも未記録なら、用途全体は未集約のままにします。未記録の項目は、確認して問題が無かったのか、まだ誰も見ていないのかを区別できないからです。この状態で試すと、あとで不許可が出ても、止める根拠が記録に残りません。

• 未集約：不許可も要エスカレーションも無いが、項目別の承認が一つでも未記録。試行可にも条件充足後に試行可にも置かない
• 試行可：必須の各項目が許可または条件付きで、条件付きの開始前証拠がある。限定範囲で小さく試す
• 条件充足後に試行可：全項目が記録済みで、開始前条件がまだ足りない。証拠・確認者・確認日を書いて再集約する
• 試行不可：不許可があり、要エスカレーションは無い。試行を止め、再検討条件を残す
• 要エスカレーション：確認不能・高リスク・禁止が残る。専門部門へ戻し、解除まで開始しない

この記事の6項目は、共通規程を補う業務別の記録です。これは編集上の目安であり、自社基準に置き換えてよい。項目の数と名前は自社の基準に合わせて増減してかまいません。自社の契約・規程・製品設定の承認結果は、関係部門の記録を正本にします。

1. 代表用途を1つ選び、9欄をそろえて確認依頼を渡す
2. 関係部門が各項目の根拠・証拠・次の行動を確認する
3. 項目別の承認と、条件付きの開始前証拠を記録し、用途全体を集約する
4. 用途全体が試行可になってから小さく試し、質問・事故・仕様変更で版を更新する

参考資料（最終確認日・参照範囲）

1. NIST AI RMF Playbook — 取得日：2026年8月18日（JST）。参照範囲：PlaybookページのGovern／Map／Measure／Manageと、任意の提案アクションである旨の説明。法的許可基準ではなく、4機能の観点を設計票へ編集上対応付けるために使用
2. デジタル庁：行政の進化と革新のための生成AIの調達・利活用に係るガイドライン第2.0版 — 取得日：2026年8月18日（JST）。参照範囲：ページの「1.概要」「2.資料」「3.変更履歴」と、第2.0版の公開日・改定説明。日本政府・各府省庁向け資料であり、自社の許可基準の代替にはしない
3. デジタル庁：ガイドライン第2.0版PDF（附則部分を参照） — 取得日：2026年8月18日（JST）。参照範囲：p.5「2.2 対象範囲」、p.6「2.2.2 本ガイドラインが対象とする生成AI」、附則の施行日・段階適用。本文の許可判断や自社規程の代替には使わない
4. ICO：Guidance on AI and data protection — 取得日：2026年8月18日（JST）。参照範囲：「What is a risk-based approach to AI?」「accountability and governance」「accuracy」「Article 22」「security and data minimisation」「individual rights」。英国のデータ保護法域の資料であり、日本企業への法的助言ではない

最終確認日：2026年8月18日（JST）。各資料の取得日は上の参考資料欄に記載しています。公開資料は自社の法務・契約・データ分類・業務リスクの判断を代替しません。デジタル庁第2.0版は2026年6月12日に公開された版です。同版のPDF附則には、全体施行日として2026年9月1日と、それに先立つ段階的な適用が記載されています。本記事が確認した2026年8月18日時点では施行前です。導入時点の原典と自社の契約・規程が正本です。NIST AI RMF 1.0は更新作業中で、Playbookも改訂後に更新される予定です。ICOのAI・データ保護ガイダンスはData (Use and Access) Actの動向を受けて見直し中です。