AI競争の次戦はモデルより行政の運用力で決まる
行政機関が高性能なAIモデルを導入しても、それだけで信頼できるAIサービスにはならない。実務を左右するのは、エージェントがどの資料を読めるのか、どのシステムを操作できるのか、誰が結果を承認し、後からどこまで再現できるのかという運用設計である。
チャットボットは回答や文案を表示するだけで終えられる。AIエージェントは検索、資料作成、内部照会、API呼び出し、申請処理までを連続して実行できる。同じモデルでも権限と承認の構造が違えば、行政上の影響は大きく変わる。2026年の韓国・米国・日本の公的資料を比べると、競争の軸がモデル選定から運用力へ移る理由が見えてくる。
この記事のために制作した概念写真です。特定の官庁、製品、会議、稼働中の行政システムを撮影したものではありません。
韓国はサービス・データ・個人情報を同じ議題に置いた
韓国政策ブリーフィングによると、第5回AI責任者協議会は2026年10月2日に開催された。参加範囲は従来の28機関から42の中央行政機関へ拡大された。AI立法フレームワーク、12月の正式提供を準備するEveryone’s AI、政府横断データパイプライン、公共部門の個人情報保護管理という4議題が扱われた。
Everyone’s AIをめぐっては、公開済み公共APIとの接続、未公開API・データの追加開放、AIエージェントの個人情報処理・利用基準、サービスのセキュリティ・安全性検証が関係機関の協力事項として挙げられた。これは準備状況の発表であり、12月提供予定の全機能と安全性がすでに本番環境で実証済みという意味ではない。
運用面では「APIに接続する」だけでは要件が粗すぎる。公開情報を読む、住民の資格情報を照会する、申請を送信するという3つの操作は失敗した際の影響が異なる。読み取りと状態変更を別の権限にし、法的・金銭的効果を生む操作には担当者の明示的な承認を置く必要がある。
日本の源内は約18万人の実証とエージェント環境をつなぐ
デジタル庁のガバメントAI「源内」案内は、2026年度に全府省庁の約18万人を対象とする大規模実証を進めると説明している。対話、文章作成、翻訳などの汎用機能だけでなく、行政実務用アプリ、政府共通データセット、国内LLMの試用を同じ政策の中に置く。本格利用は2027年度以降の予算措置と区別されている。
デジタル庁が9月18日に公表した源内OSS Ver 2.0の計画には、ウェブ検索、資料生成、コード実行、スキル実行を組み合わせるエージェントチャット、個人専用のコーディング環境「源内工房」、利用実績を出力・分析する仕組みが含まれる。組織をまたぐスキル共有のマーケットプレイスは企画・構想段階とされている。
同ページは公開予定の資材がすべて開発中で、今後変更される可能性があると明記する。OSS Ver 2.0は2027年2月頃の公開予定であり、政府内エージェント環境も2026年10月頃の導入予定という説明である。10月3日時点で全府省庁の本番運用が確認されたと読み替えてはいけない。
約18万人が利用できることは配布規模の指標であり、約18万人が同じ品質で安全に使えていることとは別である。アプリの責任者、研修、権限、評価、利用状況の可視化、問い合わせ対応がそろって初めて運用成果になる。
米国はエージェントの身元と権限を基盤として扱う
米国NISTが2026年5月に公表したAIエージェントのセキュリティに関する意見分析は、エージェント固有の脅威が導入の障壁となり、従来のサイバーセキュリティ原則も調整が必要だという幅広い意見を整理した。政府の役割として、実装ガイダンス、情報共有、標準の促進が挙げられた。これは意見募集の要約であって、完成した強制規格ではない。
9月24日のNIST NCCoE更新情報は、ソフトウェア開発工程でAIエージェントを識別し、認証し、認可する実装例の範囲を検討していると説明する。10月28日のウェビナーと11月9日の意見締切は、10月3日時点では今後の日程である。
役職の高い職員を支援するという理由で、エージェントに包括的な管理者権限を持たせるべきではない。エージェント自体に検証可能な身元を与え、特定の業務に必要な権限だけを短時間付与する。別のエージェントやツールへ委任する場合も、その連鎖を記録し、子の処理が元の業務より広い権限を得ないようにする。
「読む・提案する・実行する」を分ける
初期の権限設計は3段階に整理できる。
- 読む: 承認済みの公開・内部資料を検索して根拠を示す。外部状態は変えない。
- 提案する: 回答案や判断案を作るが、保存・送信・申請はしない。担当者が編集して承認する。
- 実行する: 承認されたAPIを使い、通知、予約、登録変更などを行う。業務単位の承認と実行後確認を要する。
権限は職員の職位だけで決めない。同じ担当者でも案内文の下書きと給付決定では必要な権限が違う。長期間有効な共有資格情報より、業務IDに結び付いた短時間のトークンを使う方がよい。
間接経路も確認する。データベースへ直接入れないエージェントが、広い閲覧権限を持つ分析ツールを呼び出すことがある。メール送信権限がなくても、通知を発生させるキューへ書き込める場合がある。最初のツール名ではなく最終的な効果で認可を判断する。
運用モデルを7層に分ける
行政AIエージェントは少なくとも次の7層で設計すると監査しやすい。
- 業務境界: 行う仕事と拒否すべき仕事を一文で定義する。
- データ境界: 公開、一般内部、個人、機微情報を分け、結合可能な範囲を決める。
- 身元: 職員、エージェント、サービスアカウント、外部ツールを別の主体として識別する。
- 認可: 検索、下書き、保存、対外連絡、状態変更を分離する。
- 人の統制: 権利、金銭、個人情報、公的回答に影響する処理の承認者を定める。
- 追跡: モデル、スキル、参照資料、ツール呼び出し、承認、修正、結果の版を残す。
- 封じ込めと復旧: 資格情報を失効し、処理を止め、関係者へ通知し、戻せる変更を戻す。
この構造は1社の管理画面だけでは完成しない。組織のID基盤、文書保存年限、内部監査、インシデント対応、業務責任者と接続する必要がある。モデル更新時にも同じ統制を通す。
人の承認画面は判断材料を示す
「承認しますか」というボタンだけでは、確認作業が形式化しやすい。担当者が影響を理解できるよう、少なくとも次を同じ画面に出す。
- 参照した原資料と更新日時
- 現在値とAIが提案する変更値
- 影響を受ける人、金額、期限、法的状態
- 見つからなかった情報と矛盾
- 実行後に取り消せるか、その期限
- 同じ業務で最近起きた誤りと人の介入
低リスクの可逆操作と、給付否認、個人情報提供、対外声明、支出を同じ承認方式にしない。すべてでクリックを求めると承認疲れが起きる。一方で高リスク操作を無承認にすると誤りが大量に増幅する。金額、情報区分、対外送信、法的効果で承認の強度を変える。
承認件数だけでなく、修正・却下率、確認に使えた時間、後日の監査で不足していた情報を測る。人がいることではなく、人が判断できたことが統制の目的である。
監査ログは会話履歴より広い
チャット全文だけを保存しても、エージェントの行動は再現できない。作業ID、職員とエージェントのID、権限の発行・失効時刻、モデルとスキルの版、資料の識別子、ツール呼び出し、戻り値、承認・却下、最終結果、例外、復旧操作をつなげる。
ログへ個人情報の原文を何度も複製する必要はない。権限のある原本へ到達できる参照値を使う方法がある。監査ログ自体にも閲覧権限と保存期間を設定しなければ、セキュリティ記録が新しい個人情報集積になる。
エージェントの管理者と証跡を削除できる人を分け、処理の途中でイベントが欠けた場合は警告する。外部サービスが障害を起こした際にも、どこまで実行済みかを判別できる連続した記録が必要である。
90日で統制を先に試す
1〜30日目は読み取り専用の業務を1つ選び、従来の処理時間、再作業、誤りを基準値として測る。データ所有者を確認し、未承認資料を拒否するか試す。支払いや権利状態を変える業務から始めない。
31〜60日目は提案まで許可し、全件を人が確認する。誤った資料、古い版、文脈不足、過剰アクセス、不正なツール呼び出し、エスカレーション失敗、承認画面の不足に分類する。資格情報流出と誤った更新を想定した机上訓練も行う。
61〜90日目は、取り消し可能な操作だけを限定して許可する。1日の件数、対象部署、利用可能時間を制限し、短時間権限と明示承認を使う。緊急停止を実際に試し、停止から復旧までの時間を測る。
評価には、100件当たりの人の修正・却下、根拠なし回答、権限超過の試みと遮断、不要な個人情報露出、誤実行と取り消し、検知から資格情報失効までの時間、職員の監督負担を含める。処理速度だけが改善しても、説明不能な行動や復旧時間が悪化したなら拡大条件を満たしていない。
調達契約はモデル変更後も残る統制を買う
契約では、顧客データを学習に使わないという条項だけでなく、エージェントごとに別のサービスIDを作れるか、権限に期限を付けられるか、全ツール呼び出しを出力できるか、更新前後の結果を再現できるかを確認する。
サポート時に誰がプロンプト、取得資料、ログへアクセスするのかを明記する。事故通知期限、調査協力、契約終了時の作業コピー・派生ログ削除も必要である。再委託事業者や外部モデル提供者がいる場合は、それぞれのアクセス範囲を分ける。
業務定義、承認規則、評価結果、監査イベントを文書化された形式で移行できることも重要だ。供給者を変えたときに統制証跡まで失う仕組みは、長期の行政基盤に向かない。
結論は「より大きなモデル」より「より小さな権限」
韓国は国民向けサービス、API・データ、個人情報、セキュリティを政府横断の同じ議論に置いた。日本は約18万人規模の実証を行政アプリ、共通データ、エージェント環境の計画と接続する。米国NISTの取組は、エージェントの身元、認証、認可を実装上の基盤として扱う。
3か国が同じ制度を採用したわけではなく、引用した計画がすべて実装済みということでもない。それでも、モデル性能だけでは行政AIを運営できないという方向は共通する。無権限の行動を止め、承認理由を残し、失敗から復旧できることが信頼をつくる。次の競争力は無制限の自律性ではなく、証跡と責任者に結び付いた最小限の有用な権限である。
