デジタル庁の生成AIガイドラインをClaude社内規程に転用する
デジタル庁が2025年5月に策定した行政向け生成AI調達・利活用ガイドラインのリスク判定の枠組みを、民間企業がClaudeの社内利用規程を作るときのひな形として読み替える方法をまとめます。
デジタル庁ガイドラインは、なぜ民間企業でも参照できるのか
「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン」は、2025年5月27日にデジタル社会推進会議の幹事会が決定した、政府職員向けの正式なルール文書です(DS-920)。民間企業に適用義務はありません。それでも読む価値があるのは、中身が特定のAIサービスや政府機関に依存しない、リスクの見つけ方と役割分担の型だからです。
骨格は3つあります。AI統括責任者(CAIO)を置く体制、利活用のリスクを判定する4つの軸、そして企画・調達・運用・利用の各段階で誰が何をするかという役割分担です。Claudeを業務に入れようとする企業は、この3つを社内規程の骨格にそのまま借りられます。ゼロから章立てを考えるより、公開済みの型に自社の事情を当てはめるほうが早く、抜け漏れも減ります。
一方で、ガバメントクラウドの利用検討義務や公共調達の要件など、政府機関だけに関わる条項も混在しています。公共調達でClaudeがどこまで適用対象外になるかは公共調達でClaude等生成AIが適用対象外になる条件で個別に扱っています。転用では、汎用のリスク管理の型と行政固有の制度を最初に仕分けます。
リスクレベルを判定する4つの軸
判定の核は、本文の表4「リスク軸とその考え方」です。軸ごとに選択肢が決まっていて、単独ではなく組み合わせで評価します。次の表は、政府向けの原文の観点を、企業がClaudeを使う場面に読み替えたものです。
| リスク軸 | 政府向けの原文の観点 | 企業への読み替え |
|---|---|---|
| A. 利用者の範囲・種別 | 政府向けの原文の観点国民等による府省庁外利用/複数府省庁横断での利活用/単一府省庁内での利活用 | 企業への読み替え社外の顧客向け公開/複数部門共有/単一部門限定 |
| B. 業務の性格 | 政府向けの原文の観点過失が重大な影響を及ぼす可能性のある業務で利活用するか否か | 企業への読み替え与信・採用・人事評価など権利や処遇に直結する業務か否か |
| C. 機密・個人情報の学習等 | 政府向けの原文の観点機密性2情報・個人情報が保存または学習される/取り扱うが保存・学習されない/取り扱わない | 企業への読み替え顧客情報や人事データをプロンプトに入れるか、入れた場合に学習や保存の対象になるか |
| D. 出力の政府職員による判断 | 政府向けの原文の観点出力の適切さを職員が判断せずに利活用するか | 企業への読み替え担当者が出力をレビューせずに自動反映するか |
軸Aは影響が及ぶ範囲、軸Bは間違えたときの重大さ、軸Cは入力データの機微度、軸Dは人間が最後に確認する工程の有無を見ています。軸Bの原文は、重大な影響の例として国民の基本的権利や安全、機微な政策分野、人の生命・身体・財産、資格が求められる業務、高い説明可能性が求められる業務を挙げています。企業側では、与信や採用に加えて、医療・法務・会計のような有資格者の判断を伴う業務も、この軸で見ることになります。
軸Cには、見落としやすい点があります。原文の選択肢は3段階で、情報が「保存または学習される」場合だけでなく、「取り扱うが保存・学習されない」場合も区別されています。企業の読み替えでも、学習利用の設定がオフであることは、機密情報を入力してよい理由にはなりません。入力データの機微度と、入力先の扱いを別々に判定します。
原文が挙げる高リスクの例2件と、企業での読み替え
例1: 外部に提供するシステム
府省庁外に提供するシステムが、誤作動で国民の権利や安全に大きな影響を与えうる業務に使われるケースです。企業では、顧客向けチャットボットの自動応答が近い例になります。
例2: 個人情報を使う重要業務
個人情報を使い、人の生命・身体・財産に影響する業務で権利侵害の恐れがあるケースです。原文は軸Cの①(保存・学習される)と②(取り扱うが保存・学習されない)の両方を対象にしています。企業では、与信審査や採用選考の一次判定が近い例です。
2例の組み合わせに軸Dは含まれず、表4で軸Dはリスク軸の1つとして並びます。規程では、軸Dをリスクを下げる条件にせず、判定の独立した項目として扱うのが原文の並びに沿います。原文は、出力結果を判断せずそのまま利活用する業務設計ではリスクが高くなると考えられる、と書いています。
判定シート(別紙1)の選択肢にも注目してください。軸Aから軸Dのどれにも「企画時点で未定」が用意されています。社内規程でも、導入時点で決まっていない項目は未定のまま申請を受け付け、確定した時点で再判定する設計にできます。判定ロジックは図で示されており、4つの回答だけで「高リスクに該当する可能性が高い」か「低い」かを簡易に出します。
約款への同意だけで使うClaudeは、どの導入類型にあたるか
原文は、生成AIシステムの導入を「開発の実施有無」と「契約の形態」で3類型に分けています。
原文の導入類型A・B・C
A: 約款への同意だけ
個別開発も個別契約もなく、定型約款や規約への同意でサービスを使います。原則、要機密情報を扱わない想定です。
B: 約款に加えて個別契約
個別開発は行わず、約款への同意に加えて個別契約を結びます。
C: 個別開発と個別契約
個別に開発し、個別契約も結びます。
以下は原文が示したものではなく、類型の定義にClaudeの契約形態を当てはめた読み替えです。利用規約への同意だけで個人が使い始める形は類型Aに近い使い方です。営業経由で個別契約を結ぶEnterpriseは類型Bに近づきます。一方、Teamのようにセルフサーブで申し込めるプランは、約款への同意のみで成立するのか個別契約を伴うのかで類型が変わるため、契約の実態を見て自社の審査で決めます。
APIを自社アプリに組み込む形は個別開発にあたりますが、類型Cは個別契約も前提にしています。Commercial Termsへの同意だけで使う場合はどの類型にもそのまま当てはまらないため、個別契約の有無でBやCと同等の扱いにするかを決めます。
類型Aについて、原文(6.1.1③)は強い制限を置いています。不特定多数に提供され、約款への同意のみで使えるクラウド型の生成AIを業務で使う場合、原則として要機密情報は扱えません。要機密情報を扱わない場合でも、使える業務の範囲を先に決めます。そのうえで、利用目的や利用者の範囲について企画者が申請し、許可権限者が審査し、利用状況を管理します。個人アカウントで業務利用が始まっている企業には、この3段階(範囲の特定・申請と審査・利用状況の管理)がそのまま規程の雛形になります。
利活用ルールのひな形(別紙2)には、例外の書き方もあります。要機密情報を扱う場合は情報セキュリティ責任者の許可を必要とし、国外にサーバー装置がある場合は現地の法令が適用され、現地の政府等による検閲や接収を受ける可能性がある、という内容です。
もう1点、原文は類型Aでも確認を求めています。調達チェックシートと契約チェックシートの内容に照らして、約款の項目に矛盾がないかを見ます。求めたい要求事項があるなら、類型BかCの形で調達することを検討する、という流れです。
要求レベルは一律ではありません。原文は、概念検証(PoC)の段階か本番開発の段階か、高リスクの可能性が高いか、ユースケースの性格はどうか、を踏まえて取捨選択するよう求めています。例として、行政内部で大量の文書を検索する用途では、「有害情報の出力制御」などの要求が不要になりうると書かれています。社内の試行段階にすべての条項を課すと、対策が過剰になるわけです。
政府の役割分担を、企業の部門にどう対応させるか
ガイドラインは立場を、AI統括責任者(CAIO)・企画者・開発者・提供者・利用者の5つに分けています。表3は、これがAI事業者ガイドラインのどの立場にあたるかも示しています。CAIOは「経営者を含む事業執行責任者」、企画者は「AI開発者又はAI提供者」、利用者は「AI利用者」に対応します。
| ガイドラインの役割 | 原文での位置付け | 企業での対応部門の例 |
|---|---|---|
| AI統括責任者(CAIO) | 原文での位置付け生成AIのリスク管理を統括する司令塔。報告の要否の最終決定も担う | 企業での対応部門の例情報システム部門長やDX推進責任者 |
| 企画者 | 原文での位置付け目的を決め、リスク分析と調達に責任を持つ部署・チーム | 企業での対応部門の例導入を主導する事業部門・情報システム部門 |
| 開発者 | 原文での位置付けモデルやシステム基盤を構築する者(内製の場合) | 企業での対応部門の例自社でClaudeを組み込んだツールを作る開発チーム |
| 提供者 | 原文での位置付け生成AIを組み込んだサービスを職員や国民に提供し、運営する者 | 企業での対応部門の例社内向けにClaudeの環境を運営する管理者 |
| 利用者 | 原文での位置付け実際に生成AIを使う者。本ガイドラインの直接の対象ではない | 企業での対応部門の例Claudeを使う全社員 |
ここで注意したいのは、AnthropicのようなAI事業者の位置です。原文は、政府と契約して生成AIシステムを提供する事業者を、ガイドラインの直接の対象に含めていません。企画者や提供者が、調達手続や契約、事業者の監督を通じて、ガイドラインの遵守を確保する構造です。企業でも、Anthropicは役割表の行ではなく、調達と契約で管理する相手として扱うことになります。
利用者についても、原文は直接の対象としていません。CAIOが策定した利活用ルールと、企画者が策定した各システムの利活用ルールを守ることが求められる立場です。社員に求める事項は、規程と個別システムのルールの2層に分けて書けます。
CAIOの設置については、各府省庁のデジタル統括責任者または副デジタル統括責任者が兼ねることも可能だと注記されています。企業でも新設は必須ではなく、既存の情報システム部門長や法務・コンプライアンス部門が兼ねて足ります。大切なのは肩書きではなく、利活用ルールを策定し、リスクケース発生時に最終判断する人を、1人か1つの部門に決めておくことです。曖昧なまま複数部門が並行して導入すると、部門ごとにルールが乱立します。
CAIOが策定する利活用ルールに盛り込む事項として、原文は次の4つを挙げています。
- 利用前に最低限理解しておく知識と、要機密情報の取扱いなどの留意事項
- 利用目的の範囲内での利活用や、AI生成物を使った業務に係る説明責任に関する心得
- 生成AIを使って職務上作成した文書の取扱い
- リスクケース発生時のCAIOへの報告
この4点は、社内AI利用規程にAI事業者ガイドラインは何を求めるかを踏まえたClaude利用規程の章立てに、ほぼそのまま使える粒度です。
企画時だけでなく、運用開始後にも再判定する
原文のもう1つの特徴は、リスク判定が一度きりでない点です。企画時には生成AIの利活用を認識しておらず、リリース後や構築後に認識した場合も同じ扱いです。
原文が想定する報告のタイミング
- 1
企画時
リスク評価を行い、高リスクの可能性があれば、目的・リスク軽減策・運用時の品質確保策を報告します。
- 2
構築時・リリース時
事情の変化で高リスクの可能性が生じたら、この時点でも報告します。
- 3
運用開始後
運用中に高リスクの可能性が生じた場合も報告します。
- 4
随時(定期報告)
再判定の報告とは別に、CAIOは運営状況を随時一覧的にとりまとめ、四半期に一度程度を目安とする頻度で定期的に報告します。
企業に置き換えると、Claudeの導入後に使い方が変わる場面が再判定の契機になります。たとえば、社内限定で始めた利用を顧客向けの機能に広げる場合や、個人情報を含む業務に使い始める場合です。軸A・軸Cの回答が変わるため、導入時の判定が有効なままとは限りません。規程には、判定のやり直しを求める条件を書いておくと運用が回ります。
政府固有の条項は、企業規程に持ち込まない
ガイドラインには、行政機関だけに関わる条項も含まれています。転用では、次の3つを切り分けて除外します。
- 先進的AI利活用アドバイザリーボードへの報告: 高リスク判定時に政府内の助言機関へ報告する仕組みで、民間には対応する制度がありません。社内では、CAIO相当の責任者やリスク管理委員会への報告に置き換えます
- ガバメントクラウドの利活用検討義務: 国の行政機関等が情報システムを整備する際の義務です。企業では既存のクラウド利用方針に従えば足ります
- デジタル・スタートアップの公共調達優遇: 公共調達市場でのスタートアップ育成策です。民間のベンダー選定基準としては参考程度にとどめます
そのまま使える部分もあります。企画者が調達時に使う調達チェックシートと、契約書の検討に使う契約チェックシートです。
調達チェックシートは、事業者を評価・選定するための項目表です。分類は「組織要件」「開発・運用工程要件」「生成AIシステムの基本機能要件」の3つで、項目は次の3区分に分かれます。
| 区分 | 意味 |
|---|---|
| 基本項目 | 意味原則必須の要求事項 |
| 「〇〇の場合は適用」 | 意味条件を満たす場合に原則必須になる項目 |
| 任意追加項目(加点項目) | 意味必須ではないが考慮したほうがよい観点 |
契約チェックシートは、契約書に盛り込むことを検討する事項の一覧です。「取り決め事項」の列は原則必須とされ、条項の例文は例示にとどまり、すべてを満たす必要はないと明記されています。調達仕様書に盛り込むほうが適当な事項は、そちらへ回します。入力データの利用目的・利用条件・権利帰属や、出力の知的財産権の帰属を扱う項目もあり、Claudeの入力データの扱いを確認する際の観点になります。
企業がAnthropicやSaaSベンダーと契約する場面では、この区分が使えます。この3区分は、Anthropicを含むベンダーとの契約審査の項目表にそのまま使えます。Commercial Terms側でこれらの観点がどこまで扱われているかは、Claude Commercial Termsのチェックポイントで個別に扱っています。
社内規程の章立てにどう落とし込むか
ガイドラインの節構成を踏襲せず、企業の意思決定に必要な要素だけを抜き出すと、Claudeの社内利用規程は次の6章で組み立てられます。
Claude社内利用規程の6章
- 1
目的と適用範囲
どの部門を対象にするか。どのプラン(個人のPro/MaxかTeam/Enterpriseか)で使うかも、前の節の対応を参考に、自社の審査で決めます。
- 2
リスク判定の手順
4軸のチェックリストと、高リスクに該当した場合の承認ルート、運用開始後の再判定の条件を書きます。
- 3
入力データの取扱い
顧客情報・人事情報・未公開情報をプロンプトに入れてよい条件と、学習利用の設定の扱いを書きます。軸Cの3段階に合わせて分けられます。
- 4
出力の検証義務
誰が、どの業務で、出力をそのまま使わずにレビューするかを書きます。軸Dに対応する章です。
- 5
文書の取扱い
Claudeで作成した文書の保管・管理の扱いと、公開前に確認する範囲を書きます。
- 6
リスクケース発生時の報告体制
誰に、いつまでに、何を報告するかを書きます。
5番目の章の元は、CAIOが策定する利活用ルールの項目にある「生成AIを活用して職務上作成した文書の取扱い」です。原文は、この項目の中身を公文書管理法に沿った適切な管理としています(別紙2)。企業では、AI生成物を文書管理規程のどこに位置づけるかを書きます。AI利用の明記の要否は原文にない論点です。規程に入れる場合は、ガイドラインの転用部分と自社で追加した項目を区別して書きます。
6番目の章の下書きには、原文が例示するリスクケースが使えます。偏見や差別を含む出力、攻撃的・危険なコンテンツの生成、ハルシネーションによる不利益、既存作品に類似した出力による著作権侵害の問題の4つです。原文は、リスクをゼロにはできないという前提で、リスクが顕在化した場合の準備を求めています。発生時はCAIOと提供者が中心になって対応し、情報セキュリティインシデントの性質も併せ持つ場合は、両方の対応体制が連携します。
別紙はガイドライン本体のPDFに同梱されている
利活用ルールひな形(別紙2)、調達チェックシート(別紙3)、契約チェックシート(別紙4)、高リスク判定シート(別紙1)は、本文中で参照される別紙です。ガイドライン本体のPDFは、本文の後ろに別紙1から別紙4までが続く構成です。別紙1は、軸A〜Dの設問と選択肢、判定ロジックの図を含みます。規程を実際に作る際は、PDFの別紙部分の設問と選択肢を、自社の用語に置き換えながら書き写すのが近道です。
まとめ
行政向けの文書でも、4軸の判定と役割分担は、Claudeの社内利用規程の骨格に使えます。企業側で決めるのは、軸Dを独立した判定項目として扱うか、約款同意だけの利用をどこまで認めるか、運用開始後の再判定をいつ起こすか、の3点です。
よくある質問
中小企業でもこのガイドラインを参考にする意味はありますか
あります。4軸は業務の性格を問わない汎用の枠組みです。別紙の分量は多いため、まず4軸のチェックリストと役割分担の2点だけを抜き出して、簡易版から始める進め方があります。原文も、PoCか本番かでリスクと対策のバランスを考えるよう求めています。
社内規程は法務部門が単独で作るべきですか
原文の構造は、業務側の企画者と、統括側のCAIOの連携を前提にしています。企画者の対応事項(6.3.1)でも、業務の知見者と生成AIシステムの知見者が連携する体制を築いて企画するよう努めることとされています。法務・情報システム・実際にClaudeを使う事業部門が関わる体制のほうが、原文の設計に近くなります。
Claude Code向けの規程も同じ枠組みで作れますか
同じ4軸で考えられますが、軸Cの評価が変わります。Claude Codeはソースコードやリポジトリ内のデータを扱います。原文の軸Cは機密性2情報と個人情報ですが、Claude Codeでは設計情報や認証情報も同じ軸で見るのが実務的です。これは記事側の読み替えです。
ガイドラインが改定されたら、社内規程はどう追従しますか
原文は、CAIOが策定するルールを、ガイドラインの改定や生成AIの最新の動向・利活用状況を踏まえて随時改定する、と定めています。社内規程でも、見直しの時期を固定せず、ガイドラインの改定や使い方の変化を契機にする形が原文に沿います。