じめに｜行政AIエージェントは「便利なチャット」ではなく実行主体になる
行政機関や自治体で生成AIの活用が進むなか、次の論点になっているのが「AIエージェント」の扱いです。従来の生成AIは、職員が入力した質問に対して文章を返す補助ツールとして使われることが中心でした。しかしAIエージェントは、外部システムやデータベース、業務アプリと連携し、目標に向けて計画を立て、必要な操作を実行する存在になり得ます。
シンガポールIMDAのAgentic AI向けガバナンスフレームワークでも、AIエージェントは情報を生成するだけでなく、外部システムと相互作用し、データ更新や支払いなど環境への変更を行う可能性があるものとして整理されています。つまり、行政AIエージェントは「回答するAI」ではなく、「行動するAI」として設計・管理する必要があります。
行政領域では、住民情報、税務情報、福祉情報、入札情報、政策資料など、扱うデータの機微性が高くなります。AIエージェントが誤った権限で情報を参照したり、意図しないAPI操作を実行したりすれば、単なる出力ミスでは済みません。だからこそ、導入前に考えるべき中心テーマは「何ができるか」ではなく、「どこまで許すか」「何を記録するか」「問題発生時に止められるか」です。
行政AIエージェントで権限制御が重要になる理由
AIエージェントは権限を持つとリスクも大きくなる
AIエージェントの強みは、業務をまたいで処理を進められることです。たとえば、住民からの問い合わせ内容を読み取り、関連する制度文書を検索し、必要に応じて申請案内を作成する。さらに進めば、予約管理、通知文作成、担当部署への連携、内部台帳の更新まで担う可能性があります。
しかし、ここで問題になるのが権限です。人間の職員であれば、所属部署、職位、担当業務に応じて閲覧・編集できる情報が分かれています。AIエージェントにも同じように、あるいはそれ以上に厳格な権限制御が必要です。
特に危険なのは、「便利だから」と広い権限を一括で与えてしまうことです。広範な閲覧権限、書き込み権限、外部送信権限を持ったAIエージェントが、誤った判断やプロンプトインジェクションの影響を受ければ、被害範囲は一気に広がります。権限は最初から大きく与えるのではなく、業務ごと、データごと、操作ごとに細かく分ける必要があります。
静的なRBACだけでは不十分になる
これまでの情報システムでは、職員の役職や所属に応じて権限を付与するRBAC、つまりロールベースアクセス制御が多く使われてきました。これは今後も基本になりますが、AIエージェントにはそれだけでは足りません。
AIエージェントは、同じユーザーからの指示でも、文脈によって実行内容が変わります。制度文書を要約するだけなら低リスクですが、住民情報を検索し、通知文を生成し、外部送信するとなるとリスクは大きく変わります。したがって、権限は「誰が使っているか」だけでなく、「何をしようとしているか」「どのデータに触れるか」「結果が可逆か不可逆か」で動的に判断する必要があります。
ここで重要になるのが、ゼロトラストの考え方です。Cloud Security AllianceのAgentic Trust Frameworkは、AIエージェントに対しても「最初から信頼しない」「行動を継続的に検証する」という考え方を適用し、アイデンティティ、振る舞い、データガバナンス、セグメンテーション、インシデント対応の5要素で統制する必要性を示しています。
行政AIエージェントの権限制御で設計すべきポイント
1. AIエージェントにも固有のIDを持たせる
まず必要なのは、AIエージェントを「誰かの裏側で動く処理」として曖昧に扱わないことです。どのエージェントが、どの職員の指示で、どの業務目的のために動いたのかを追跡できなければ、事故発生時に原因を特定できません。
AIエージェントごとに固有IDを付与し、所有部署、利用目的、接続可能なシステム、許可された操作、責任者を明確にすることが出発点です。人間の職員アカウントをそのまま使い回すのではなく、AIエージェント専用のサービスアカウントや実行IDを設計し、監査ログとひも付ける必要があります。
2. 最小権限を業務単位で定義する
AIエージェントに与える権限は、「できるだけ少なく、必要なときだけ」が原則です。たとえば、FAQ回答用エージェントに住民基本台帳の編集権限は不要です。申請書類の不備確認エージェントにも、外部送信権限を常時持たせる必要はありません。
重要なのは、閲覧、検索、要約、生成、更新、送信、削除といった操作を分けて設計することです。さらに、個人情報、要配慮情報、内部決裁資料、公開済み資料など、データ分類ごとに権限を変えるべきです。
3. 実行直前に再チェックする
AIエージェントの権限制御では、最初にログインできたかどうかだけでなく、実行直前の確認が重要です。たとえば「この文書を要約して」という指示の途中で、エージェントが別システムの個人情報を参照しようとした場合、その瞬間に止められる仕組みが必要です。
この考え方は、RAGや業務データ検索でも重要です。検索結果をAIに渡す直前に、ユーザーやエージェントの権限と照合し、閲覧権限のない文書チャンクを除外する。これにより、AIの回答に本来見せてはいけない情報が混ざるリスクを下げられます。
4. 高リスク操作には人間の承認を残す
AIエージェントにすべてを自動実行させる必要はありません。むしろ行政では、不可逆な操作や影響範囲の大きい操作には、人間の承認を残すべきです。
たとえば、住民への通知送信、データ削除、権限変更、支払い処理、外部機関への情報提供などは、AIが下書きや候補を作る段階に留め、最終実行は職員が確認する設計が現実的です。
ただし、単に「承認ボタン」を置くだけでは不十分です。承認者が何を判断すべきか分からなければ、自動化バイアスによってAIの提案をそのまま通してしまう可能性があります。IMDAのフレームワークでも、Human-in-the-loopは自動化バイアスを踏まえて設計し、高リスクまたは不可逆な行動に重要な承認ポイントを置くことが示されています。
監査ログ設計で記録すべき内容
監査ログは「あとで見る記録」ではなく統制の中核
行政AIエージェントの監査ログは、単なる操作履歴ではありません。AIがどの情報を根拠に、どのような計画を立て、どのツールを呼び出し、どの結果を出したのかを再現できる必要があります。
NIST AI RMFは、AIリスク管理の中核としてGOVERN、MAP、MEASURE、MANAGEの4機能を示し、AIシステムには説明可能性、透明性、プライバシー保護、公平性、安全性などの観点が必要であると整理しています。行政AIエージェントの監査ログも、このリスク管理を運用するための基盤として設計する必要があります。
記録すべきログ項目
最低限、次の情報は記録対象にすべきです。
- 利用者ID、AIエージェントID、実行セッションID
- 入力プロンプト、業務目的、実行計画
- 参照した文書、データソース、RAG検索クエリ
- 呼び出したAPI、ツール、外部システム
- 実行前の権限判定結果
- 生成された出力、修正履歴、送信履歴
- 人間の承認者、承認時刻、差し戻し理由
- エラー、警告、ブロック、異常検知の内容
特にRAGを使う場合は、回答の根拠となった文書IDやチャンクIDを残すことが重要です。これにより、誤回答が発生した際に、モデルの問題なのか、検索された文書の問題なのか、権限制御の問題なのかを切り分けやすくなります。
ログは改ざんできない形で保全する
監査ログは、あとから書き換えられてしまえば意味がありません。行政システムでは、ログの完全性、保全期間、閲覧権限、検索性をあらかじめ決めておく必要があります。
また、ログ自体にも個人情報や機密情報が含まれる可能性があります。したがって、監査ログは「たくさん取ればよい」のではなく、目的に応じて必要な情報を記録し、ログへのアクセスも厳格に管理する必要があります。
調達仕様書に入れるべきAIエージェント管理要件
行政AIエージェントを外部サービスやベンダー製品として導入する場合、運用開始後に権限制御や監査ログを追加しようとしても、システムの構造上できないことがあります。したがって、調達段階で要件に入れることが重要です。
デジタル庁の生成AI調達・利活用ガイドライン改定案では、企画者が調達チェックシートを参照し、生成AIシステムのガバナンス、データの取扱い、偽誤情報対策、個人情報・知的財産保護、セキュリティ、説明可能性などを調達仕様書に盛り込む考え方が示されています。
仕様書には、少なくとも次の観点を入れるべきです。
- AIエージェントごとのID管理ができること
- ユーザー権限とエージェント権限を分離できること
- 操作ごとの許可・拒否を制御できること
- RAG検索結果に対して権限フィルタを適用できること
- API呼び出し前にポリシーチェックができること
- 監査ログを構造化データとして出力できること
- ログの保全、検索、エクスポートができること
- 高リスク操作に人間承認を挟めること
- 異常時にエージェントを停止・降格できること
- ベンダー側の再委託、学習利用、データ保管条件を明示できること
ここを曖昧にすると、導入後に「AIは便利だが、誰が何をしたか分からない」という危険な状態になります。
自治体・行政機関が導入前に整えるべき運用体制
CAIO・情報システム部門・原課の責任分界を決める
AIエージェントの管理は、情報システム部門だけでは完結しません。業務内容を知る原課、セキュリティを担う部門、個人情報保護担当、法務・契約担当、そしてAI統括責任者が連携する必要があります。
デジタル庁の概要資料では、AI統括責任者、企画者、提供者、利用者などの役割に応じたルール整備や、リスクケース発生時の報告・対応が示されています。運用開始後も安全性や品質を定期的に検証することが求められています。
小さく始めて段階的に自律性を上げる
行政AIエージェントは、最初から完全自律で導入すべきではありません。まずは、閲覧・要約・候補作成など低リスクな範囲から始め、ログを確認しながら、段階的に権限を広げるべきです。
CSAのAgentic Trust Frameworkでも、AIエージェントの自律性は最初から与えるのではなく、実績と統制状況に応じて段階的に上げる考え方が示されています。問題が起きた場合は、権限を下げる、停止する、サンドボックスに戻すといった仕組みも必要です。
OWASPの脅威モデルをチェックリスト化する
AIエージェントには、従来のWebアプリケーションとは異なるリスクがあります。OWASP Top 10 for Agentic Applications 2026では、自律型・エージェント型AIシステムにとって重要なセキュリティリスクが整理されています。
行政機関では、プロンプトインジェクション、ツールの誤用、過剰権限、エージェント間通信の不備、メモリ汚染、連鎖的な失敗などを想定し、導入前のテスト項目に落とし込むことが必要です。
まとめ｜行政AIエージェントは「権限」と「ログ」から設計する
行政AIエージェントの導入は、業務効率化や住民サービス向上につながる可能性があります。しかし、AIが外部システムに接続し、データを参照し、操作を実行する段階に入ると、リスクの性質は大きく変わります。
重要なのは、AIエージェントを単なる便利ツールではなく、権限を持つ実行主体として扱うことです。固有IDを付与し、最小権限を徹底し、実行直前にポリシーチェックを行い、高リスク操作には人間の承認を残す。そして、すべての判断と行動を監査ログとして追跡できる状態にする必要があります。
行政AIの本格活用に必要なのは、AIの性能比較だけではありません。むしろ、権限制御、監査ログ、停止機構、調達仕様、責任分界を先に整えることが、安心してAIエージェントを使うための前提になります。次の段階では、実際の自治体業務ごとに、どの業務をAIエージェント化できるのか、どこに人間の判断を残すべきかを具体的に整理していく必要があります。
コメント