デジタル庁「源内基準」が定めたAIエージェントの統制7項目を、民間の設計に読み替える

政府が、AIエージェントに「許す条件」を文書にした

2026年10月20日、デジタル庁は、政府共通の生成AI利用環境「ガバメントAI源内（げんない）」でAIエージェントを使える機能を、約18万人の政府職員に提供し始めると発表しました。AIエージェントとは、目標を与えると、調べる・作る・確かめるを自分で続けるAIのことです。同じ日に、その利用に関わる全員が守る「源内基準」第1版を公表しています。

政府向けの文書ですが、民間企業がAIエージェントを入れるときの設計に、そのまま使える内容です。理由は2つあります。1つ目は、源内基準が「AIエージェントを業務に入れるときに、何を決めておけば安全か」を、政府の言葉で文書にした初めての例だからです。利用者・管理者・開発者という3つの立場に分けて、それぞれの責務を書いています。2つ目は、その中身が、民間企業で情シス（社内のITを担当する情報システム部門）や監査の担当者から聞かれる問いと、ほぼ同じだからです。たとえば、AIに許す操作をしぼること、大事な処理の前に人が承認すること、ログ（誰が・いつ・何をしたかの記録）を残すこと、いざというときに止められること、データをどこに置くかです。源内基準の各項目は、私たちがこれまでの記事で扱ってきた民間企業の設計と、ほとんど一対一で対応します。

この記事では、源内基準の原文を直接確認し、AIエージェントに関わる項目を民間企業の設計に読み替えます。先に、私たちの見立てを3つ書いておきます。

• 源内基準が定めた7つの統制（AIを安全に使うための管理のルール）は、民間企業がベンダー（製品を提供する会社）の製品や、自社で作った環境を評価する「確認表」として、そのまま使えます
• 源内基準が言う「スキル」は、担当者の頭の中にある業務手順を、AIが読んで実行できる手順書に書き出したものです。世の中で広がっているAgent Skills（AIに業務の手順を教えるための、公開された書き方。後述）と同じ考え方で、担当者しか知らない業務の知識をどこに書くかという問いに答えを出しています
• 源内基準は民間製品を「ブラックボックス化するおそれ」があると評価しています。中で何が起きているかを、使う側が外から確かめられなくなるかもしれない、という意味です。これは製品を使うなという話ではありません。AIが何をしたかを自社で見られるか（可視性）と、AIの動きを自社で決めたり止めたりできるか（統制可能性）を、確かめてから使えという話です。推進担当がベンダーに聞くべき項目が、ここから読み取れます

では、源内とは何か。そこから始めます。

源内とは何か。源内基準とは何か

源内は、デジタル庁が企画・開発・提供・運用する、政府職員向けの生成AI利用環境です。源内基準によると、2025年5月から庁内で使われ、2026年5月に全府省庁の職員を対象にした大規模実証（本格導入の前に、大人数で試しに使って確かめること）が始まりました。チャット、翻訳、文書作成のほか、法令調査や公用文の校正など約40種類のAIアプリが動いています。

今回加わったのが、2種類のAIエージェント利用環境です。

表の用語を補足します。APIは、他のサービスに処理を頼むための窓口です。MCP（Model Context Protocol）は、AIと外部のツールをつなぐための、誰でも使える共通の決まりです。POST/PUTはインターネットで「データを送る」操作、GETは「データを受け取る」操作です。ただ、ここで押さえたいのは1点だけです。できることが広い環境ほど、通信と権限の制限が強くなっています。

源内基準は、この環境に関わる3つの立場の責務を定めた文書です。

• 利用者：源内を使う政府職員。出力の確認と、業務で使うかどうかの判断と、その責任を持つ
• 管理者：各府省庁でAIの活用と管理をまとめる責任者（AI統括責任者）や、情報システムの管理者。利用可能な範囲、権限、統制措置、事故対応を定める
• 源内開発者：デジタル庁で源内を開発・運用する職員と、委託先の担当者。設計、実装、評価、監視、改善を担う

策定にはAIセーフティ・インスティテュート（AISI。AIの安全性を評価する国の機関）が協力しています。源内基準の冒頭には、国内外のルールを踏まえて作ったことも書かれています。たとえば、広島AIプロセス（日米欧などの主要7か国、G7が主導したAIの国際的な指針づくり）の国際指針や、総務省・経済産業省の「AI事業者ガイドライン」です。

民間企業の読者にとって大事なのは、この3つの立場が、自社にもそのまま存在することです。業務部門の利用者、情シスと推進担当という管理者、そしてベンダーか内製チームという開発者。源内基準は、それぞれが何を決めるべきかの見本になります。

統制7項目は、民間の「確認表」としてそのまま使える

源内基準の第1章1-4は、人の指示を待たずに複数の処理を続けるAIエージェントのリスクとして、次の4つを挙げています。「誤った判断の連続実行、作業ファイルの誤消去・改変、権限を超えた処理、機密情報の不適切な取扱い」です。言い換えると、間違った判断のまま作業を続ける、ファイルを誤って消したり書き換えたりする、許された範囲を超えて動く、秘密の情報を正しく扱わない、ということです。そのうえで、次の統制措置を講じて導入する、と書いています。

「利用目的及び実行権限の限定、重要な処理における職員の確認・承認、ログの保存、利用停止機能、定期的な性能評価、スキルの審査、責任主体の明確化等の統制措置を講じつつ導入する。」

7つあります。平たく言えば、次の7つを決めておく、ということです。AIに許す操作、人が承認する処理、残す記録、止め方、性能の確かめ方、スキル（後述）の審査、責任を負う人。これを、民間企業で対応する設計と並べたのが次の図です。

図の対応関係は源内基準に書かれているものではなく、私たちの解釈です。順に見ていきます。

1. 利用目的と実行権限の限定。民間で言えば、AIを使う目的と、AIに許す操作の範囲を、業務ごとに決めることです。「社内システムを更新できる」のように広く許すのではなく、どの業務のどの操作までかを指定して許可します。たとえば「経費精算で、申請書の下書きを作るところまで。提出は人が行う」のように決めます。源内では、エージェントチャットが上書きできるのはAIが生成したファイルだけで、利用者が持ち込んだ原本は変えられない仕組みになっています。

2. 重要な処理における確認・承認。源内基準は「国民の権利利益、安全又は生活に影響を及ぼす業務」について、リスクに応じた仕組みを求めています。職員がAIの処理を確かめる、承認する、途中で割って入る（介入）、利用を止める、のどれもできるようにする、という内容です。民間なら、顧客や金銭に影響する操作が相当します。たとえば、顧客へのメール送信や、取引先への支払いの実行です。

3. ログの保存。後述しますが、源内基準は高リスク業務で「AI利用記録」を、通常のアクセスログ（誰がいつシステムを使ったかの記録）とは別に作る機能を検討する、としています。

4. 利用停止機能。源内工房では、セキュリティ上の問題や不正利用のおそれが確認されたとき、開発者が利用権限を停止し、その利用者のアクセスを遮断できます。各府省庁の管理者が、自分の府省庁での利用を速やかに止められる機能も、提供を検討中と書かれています。

5. 定期的な性能評価。源内基準は、基盤モデル（AIの本体）を「正確性・信頼性、能力・性能、法令・制度理解力、安全性、中立性等」の観点で継続的に評価する、としています。そのうえで、必要ならモデルの変更や利用停止を判断できるようにします。基盤モデルは、提供元が更新すると、ある日突然それまでと違う答え方をするようになります。民間企業でも、モデルの更新を誰が確かめ、変更や停止を誰が判断するかを決めておく必要があります。

6. スキルの審査。次の節で扱います。

7. 責任主体の明確化。源内基準は「AIそのものを責任主体として扱うことなく」利用者・管理者・開発者の責任を分ける、と明記しています。「AIがやったことだから」で済ませず、結果の責任は必ず人が負う、という意味です。

7項目のうち、民間企業にとって新しい論点は6番目だけです。残りの6つは、民間企業がすでに情シスから聞かれている問いと同じ内容を、政府が自分の環境に対する要件として定めたものです。社内で説明するときは、上の図の対応関係が「政府も同じ項目を要件にしている」と示す材料になります。

「スキル」は、暗黙知をAIが実行できる形式知にしたもの

源内基準で最も特徴的なのは、「スキル」という言葉の定義です。

「従来、個々の職員や部局に属人的に蓄積されてきた業務手順、判断基準、参照資料、関連データ、確認方法、出力形式、例外処理等を、AIエージェントが実行可能な形で可視化・形式知化した『スキル』」

平たく言えば、これまで一人ひとりの経験や部署の中にしかなかった仕事のやり方を、AIが実行できる文書に書き出したものが「スキル」です。職員は、業務の目的、判断基準、参照資料、作業手順、確認方法、例外時の対応、出力形式を、AIと対話しながら書き出します。こうして「暗黙知」（本人の頭の中にしかない知識）を、「再現可能かつ検証可能な形式知」（誰がやっても同じ結果になり、正しいかを後から確かめられる文書）に変えます。作ったスキルは、府省庁の中や政府全体で共有し、「源内ライブラリ」という仕組みに集めて再利用します。源内基準はそう書いています。

この考え方は、民間のAIエージェント製品の間で採用が広がっている「Agent Skills」と同じです。Agent Skillsは、AIに業務の手順を教えるための公開仕様です。人が手順書に目的・手順・確認方法・参照資料を書き、AIエージェントが必要なときにそれを読んで実行します。源内基準自身も、源内を開発する職員に向けた行動原則の中で、同じことを勧めています。「繰り返し行う作業をコード化し、コーディングAIエージェント（プログラムを書くAIエージェント）のスキルとして定型化」する、というものです。繰り返す作業をプログラムの形にまとめ、プログラムを書くAIがいつでも同じ手順で行えるようにする、という意味です。職員の業務でも開発作業でも、同じ「スキル」の考え方を使っているということです。

推進担当にとっての意味は、「自社の業務の知識をどこに書くか」という問いに、1つの答えが示されたことです。担当者の頭の中にある判断基準や例外の扱いを、AIが読める手順書に書きます。書いたものを共有し、審査します。直すたびに版（第1版、第2版のような区別）を付けて管理します。これが「スキルの審査」という統制項目の中身です。

ここで注意したいのは、源内基準が「共有されたスキルを無条件に政府内で共有することは適切ではない」と明記している点です。誰かが作ったスキルをそのまま政府全体に広めてはいけない、という意味です。審査、品質評価、セキュリティ確認、版管理、廃止手続の仕組みを今後整備する、としています。民間企業でも、誰が書いたスキルを誰が審査し、古くなったスキルを誰が廃止するかを、使い始める前に決めておく必要があります。

もう1つ、源内基準のスキルは手順書であって、「どの操作を許すか」を決めるものではありません。許す操作の範囲は、実行権限の限定（統制項目1）が担います。民間で設計するときも、手順書と許可は別のものとして扱うのが安全です。

データの所在と通信先は、「原則」と「例外の条件」の両方が書かれている

源内基準の第1章1-2には、データの扱いが具体的に書かれています。民間企業の情シスが聞く問いと、ほぼ同じ構成です。

ここで注目したいのは、「原則として国内」と「例外の条件」が両方書かれていることです。源内基準は、国内のデータセンターでは提供されていない高度なモデルを使う必要がある場合には、海外で推論する選択肢を設けるとしています。ただし、推論後に保存されないことを契約で確保し、リスクを説明することが条件です。「海外は一切使わない」か「自由に使う」かの二択ではありません。「原則は国内、条件を満たすときだけ海外も可」と、条件付きで決めています。民間企業でも、「どの国で処理・保存されるか」と「例外の条件は契約で確保されているか」の2点で確かめられます。

通信先の限定については、源内工房の仕様がさらに具体的です。外部へのデータ送信を遮断し、Web検索に必要なGETだけを許可し、通信先・通信量・通信日時を記録します。そして「セキュリティフックの状態にかかわらず、ネットワーク層に設けられた防御措置を回避できない構成」とすると書いています。セキュリティフックは、AIの動作に割り込んで確認する仕組みです。ネットワーク層の防御措置は、通信そのものを通したり止めたりする仕組みです。前者が外れていても、後者で止まる、という意味です。AIへの指示や設定で縛るのではなく、通信そのものを止める、という設計です。この論点は、ある事例と直接つながります。2026年9月に相次いで報じられた、評価（テスト）中のAIエージェントが、テストの対象ではない外部のシステムに入り込んだ事例です。その事例は本記事の範囲を超えるため、別の記事で扱います。

高リスク業務では「AI利用記録」を通常のログとは別に残す

源内基準は、高リスク業務について次の機能を検討する、と書いています。行政手続法（役所の手続きの進め方を定めた法律）などが重視する、透明性と公正性を保つためです。

「一定の高リスク業務においては、通常のアクセスログとは別に、AI利用記録の作成を必須とする機能の実装を検討する。例えば、入力データ、プロンプト、参照したデータ、生成された回答、使用した基盤モデル及び処理時刻等を自動的に記録できるようにすることも一案となる。」

つまり、AIに入れたデータ、プロンプト（AIへの指示文）、AIが参照したデータ、AIの回答、使ったAIの種類、処理した時刻を、自動で残しておくという案です。目的は「どのような情報と判断過程に基づきAIが出力したのかを後から検証、監査できるようにする」ことです。

この項目は、私たちが「判断ログ」と呼んできたものと同じです。誰の依頼で、どのAIが、何を見て、何を出したか。承認したのは誰か。これが残っていなければ、監査で問われたときに答えられません。

民間企業で加えて押さえたいのは、その記録を、誰であっても後から書き換えられないようになっているか、です。源内基準の開発者向け統制（第4章4-5）には「監査証跡の不可変性」という項目があります。監査のための記録（監査証跡）を、後から変えられないようにする、という意味です。対象は、操作履歴、認証記録（ログインの記録）、通信記録です。これらを「源内開発者を含むいかなる主体によっても改ざん・削除が行えない構造」にします。さらに、それを「技術的手段により強制し、運用規律のみに依存しない」と書かれています。運用ルールで「消さないでください」と言うのではなく、仕組みで消せなくする、という考え方です。

民間製品への評価は、「ブラックボックス化するおそれ」

源内基準は、民間が提供するAIエージェント関連サービスについて、こう書いています。

「内部の処理方式、取得可能なログ、評価方法等が提供事業者の仕様に依存する場合には、管理者にとってAIエージェントの挙動や利用実態を十分に把握・検証できず、ブラックボックス化するおそれがある。」

言い換えると、製品の中の仕組みや記録を提供会社しか決められないと、使う側の管理者はAIが何をしているかを確かめきれなくなる、という指摘です。この引用の直前で、源内基準は次のように述べています。民間製品は「提供事業者が定める機能、権限体系、ログ、モデル、データ管理及び運用方式の範囲内で利用することが基本」になります。そのため、次の4つの場面では「必要な水準の自由度、可視性及び統制可能性を確保できるとは限らない」としています。機密情報の取扱い、複雑な権限管理、実行過程の詳細な把握、スキルやデータの移植・再利用です。だから政府は、民間製品を活用しつつ、足りない部分を自ら設計・実装する、という結論です。

これを「民間製品は危ない」と読むのは誤りです。源内基準自身、民間製品は「汎用的な業務の自動化や既存サービスとの連携に有用」と書いています。読むべきは、政府が民間製品に足りない可能性があると見た性質です。まず、前の段落で引いた自由度、可視性、統制可能性の3つです。これに、同じ箇所にある「スキルやデータの移植・再利用」を「移植性」（別の製品に持ち出せること）として加えると、4つになります。

源内基準は、自分の環境については「疎結合」を方針にしています。疎結合とは、部品どうしを固く結び付けず、1つを取り替えても全体が動き続けるようにする作り方です。源内では、クラウド（インターネット越しに借りるコンピューター）、基盤モデル、データ、認証（利用者が本人かを確かめる仕組み）、ログ、権限管理などの機能を、互いに独立させます。特定の事業者やモデルに固定しないためです。障害や価格改定、提供停止が起きても、別の組み合わせに切り替えられるようにしています。民間製品に足りないかもしれないとした4つの性質は、政府が自分の環境ではこの方針で確保しようとしているもの、と読めます。

民間企業は、政府のように自前で環境を作る選択肢を持たないことがほとんどです。だからこそ、この4つを製品選定の問いに変えて、ベンダーに聞きます。

• 可視性：AIが実行した処理、参照した資料、出力を、自社の管理者が記録で辿れるか。記録は自社に渡されるか
• 統制可能性：AIに許す操作の範囲、承認が必要な操作、通信先を、自社の管理者が決められるか。止める手段は何か
• 移植性：自社が書いたスキルやデータは、別の製品や環境に持ち出せる形式か
• 自由度：基盤モデルを選べるか。モデルの更新を自社の判断で止められるか

4つが全部そろう製品は、2026年11月時点では多くないと私たちは見ています。全部を求めるのではなく、自社の業務でどれが欠けると困るかを先に決めてから聞くのが現実的です。

開発者側の統制は、ベンダーに求める水準の目安になる

源内基準の第4章は、開発者が守る統制を定めています。民間企業の読者が直接守るものではありませんが、ベンダーに「あなたの運用はどうなっていますか」と聞くときの目安になります。

主なものを挙げます。

• 変更の追跡可能性：本番環境（利用者が実際に使っているシステム）への変更は、誰が・いつ・何を変えたかを後から追跡できる形で記録する。手で直接変えることは原則行わず、変更内容をプログラムと同じように文書（コード）に書いて保存し、承認を受けてから適用する
• 権限の最小化と分離：日常の運用操作と、基盤の構成を変える操作は別の権限にする。強い権限の行使には他の開発者への通知か承認を伴わせる。誰がどの権限を持っているかを定期的に見直し、不要な権限を外す（棚卸し）
• 秘密情報の管理：ログインに使うパスワードや暗号鍵など、システムに入るための秘密の情報を、プログラムやその保管場所に書き込まない。漏えいを自動検知し、確認されたら速やかに無効化する
• ゼロタッチ運用：本番環境で開発者が利用者のデータや稼働中のAIアプリに直接アクセスしない運用を基本にする
• 脆弱性への対処：すでに知られている脆弱性（セキュリティ上の弱点）は、重要度に応じた期限内に対処し、重要度の高い脆弱性が残った状態で本番に出さない
• 障害対応手順：連絡先、役割分担、判断権限、初動対応、利用停止、切戻し（変更前の状態に戻すこと）、復旧、対外連絡の手順を事前に定める

これらは、源内基準が参照している国際的な文書の内容と重なります。たとえば、情報セキュリティ管理の国際規格であるISO/IEC 27001や、Webアプリの代表的な弱点をまとめた一覧です。ベンダーがISO/IEC 27001やISO/IEC 42001（AIの管理体制の国際規格）の認証を持っているかは、1つの目安になります。ただし、認証が証明するのは「仕組みがある」ことです。「自社の案件でどう運用されるか」までは保証しません。上の項目を、契約前の質問に直して聞くのが確実です。

自社の環境を源内基準で点検する12項目

ここまでの内容を、推進担当が自社のAI製品や内製環境を点検するときの確認項目にまとめます。源内基準の該当箇所を添えました。情シスや監査との会話で「政府の基準ではこう書かれている」と示せます。

全部に「はい」と言える環境は、2026年11月時点では珍しいと私たちは見ています。源内基準自身も、AI利用記録や利用停止の一部を「検討する」「今後整備する」と書いており、政府の環境でも未完成の項目があります。12項目は合否を付けるためではなく、どこが欠けているかを言葉にするために使ってください。

推進担当が押さえる要点

• 源内基準は、政府がAIエージェントに課した統制を文書にしたもので、7項目のほとんどは民間企業の情シスや監査が聞く問いと同じ。「政府も同じ結論に至った」と説明する材料になる
• 新しい論点は「スキルの審査」。業務の暗黙知をAIが実行できる手順書に書き、誰が審査し、誰が廃止するかを決める。手順書と「どの操作を許すか」は分けて扱う
• データの所在は「原則国内」と「例外の条件」の両方で決める。根拠は認証ではなく契約
• 高リスク業務の記録は、通常のログとは別に、入力から出力までを残す。記録はベンダーを含む誰も改ざんできない構造にする
• 民間製品への「ブラックボックス化するおそれ」という評価は、可視性・統制可能性・移植性・自由度を確かめてから使えという意味。4つ全部ではなく、自社の業務で欠けると困るものを先に決めて聞く
• 源内基準の開発者向け統制（変更管理、権限分離、秘密情報、脆弱性対応）は、ベンダーに求める運用水準の目安になる

政府の基準は、民間が「決めるべきこと」の一覧になる

源内基準は、政府が自分の環境のために書いた文書です。でも、そこに並ぶ項目は、AIエージェントを業務に入れる会社なら、遅かれ早かれ誰かに聞かれるものばかりです。

何を許すか。誰が承認するか。何を記録し、誰が消せないようにするか。誰が止めるか。モデルをいつ評価し直すか。手順書を誰が審査するか。責任は誰が負うか。

政府が18万人の職員に向けてこの問いに答えを書いたことで、民間企業は「自社では何が決まっていないか」を一覧で確かめられるようになりました。基準の文面を写す必要はありません。欠けている項目を見つけて、1つずつ決めていくための一覧として使えます。

関連記事

• AIエージェントの権限設計：許す操作を業務の単位で切る考え方。源内基準の「実行権限の限定」にあたる
• AIエージェントの承認はどの粒度で？承認疲れと自動承認ルール：源内基準の「重要な処理における確認・承認」を、形だけにしない設計
• AIエージェントの監視と停止：改ざんできない記録と、止め方の設計。源内基準の「ログの保存」「利用停止機能」「監査証跡の不可変性」にあたる
• 生成AIに渡すデータはどこの国へ？保存先の確かめ方と個人情報保護法28条：源内基準の「原則国内、例外は契約で」を民間で確かめる方法
• AIで作ったアプリは誰が直す？パッチが追いつかない時代の保守運用：源内基準の「定期的な性能評価」と「脆弱性への対処」を誰が持つか
• AIエージェントの責任は誰が負う？システムと運用の責任分界：源内基準の「責任主体の明確化」を民間の契約と運用に置き換える
• ISO/IEC 42001とは？AIを使う会社の進め方と27001との違い：源内基準が参照する国際規格の読み方

参考資料

• デジタル庁「ガバメントAI 源内 ガバナンス・セキュリティ・セーフティに関する基準（「源内基準」）」第1版（2026年10月、https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/b033337d-dad1-4493-9316-d929597e4667/9bbaf559/20261020_policies_genai_guideline_02.pdf （2026年11月3日確認））。本文の引用は1-2、1-3、1-4、3-5、3-6、4-3、4-5による
• デジタル庁「ガバメントAI 源内においてAI エージェント利用環境の提供を開始するとともに、「源内基準」を公表します」（2026年10月20日、https://www.digital.go.jp/policies/genai/agent-safety-standard （2026年11月3日確認））
• Agent Skills 仕様（https://agentskills.io/ （2026年11月3日確認））

Askhubについて

Askhubは、日本の中堅・大企業がAIに業務を任せるための基盤です。業務の型（オントロジー）でAIに許す操作を定め、承認と判断ログで任せる範囲を広げながら、国産の基幹システムまで書き込めるようにします。導入はコンサルタントが伴走します。

この記事の言葉で言えば、Askhubは源内基準の統制7項目のうち「実行権限の限定」「確認・承認」「ログの保存」「利用停止」を、ベンダーの仕様に依存せず自社の管理者が設定・確認できる形で提供する基盤にあたります。12項目の点検表のどこに当てはまり、どこが当てはまらないかは、ご相談の中でそのままお示しします。

※Askhubのサービスに関する記載は、2026年11月時点の情報です。

関連するページ：製品の全体像、承認、伴走支援

自社の業務にAIエージェントをどう導入するか相談したい方は、お問い合わせからご連絡ください。