デジタル庁は、約18万人の職員が日々の業務で活用できる生成AI環境をガバメントクラウド上に構築し、各省庁への展開を進めている。その中核となるのが、AWSが公開する生成AIアプリ構築用のオープンソースソフトウェア（OSS）「Generative AI Use Cases」（GenU）をベースに内製開発された生成AI基盤「庁内」だ。職員が直感的に操作できるUIと、行政特有の多様な業務アプリを接続できる拡張性を備えている。
約18万人を対象とした大規模な展開フェーズ
「庁内」は現在、約18万人の職員を対象とする大規模な展開フェーズにある。デジタル庁は、厳格なセキュリティが求められる大規模なマルチテナント環境を、インフラ専任エンジニア1～2人の体制で運用している。
同基盤の開発をリードするデジタル庁の大月真士氏（戦略・組織グループ AI実装統括監 クラウドエンジニア）が、その設計思想と運用の詳細を明かした。AIエージェントの暴走を防ぐ物理的な防壁やLLM（大規模言語モデル）の記憶容量を防ぐ工夫、運用負担を減らす自動化の仕組みなど、「庁内」のアーキテクチャのポイントを詳説する。
マルチクラウド構成とUIの工夫
「庁内」は2025年5月のデジタル庁内での利用開始から中枢省庁への試験導入を経て、現在は約18万人を対象とした大規模導入実証の最中にある。2026年度中に全府省庁の約18万人が生成AIを利用可能になることを見据えた展開だ。
「庁内」のUIには「デジタル庁デザインシステム」を適用した。アクセシビリティに配慮し、直感的に操作できるデザインを採用している。物品管理システムやガイドライン適合性の確認など、行政業務に特化したAIアプリケーションを追加できる拡張性を備えている点も特徴だ。
「庁内」の中核システムはAWSに構築されているが、連携するAIアプリの稼働環境や呼び出すLLMは固定していない。AWSに加えて、Googleのクラウド基盤「Google Cloud」やMicrosoftのクラウド基盤「Microsoft Azure」も併用するマルチクラウド構成を採用している。「常にその時点で最適な生成AIモデルを利用できるよう、AWS上のシステムでありながらも、推論エンジンとして『Gemini』や『GPT』をはじめ、多様なLLMを呼び出せる設計にしています」と大月氏は語る。
さらに、行政機関に求められるガバナンスを満たすため、GenUに対して独自の拡張も施している。ユーザー管理庫（CMEK）に対応したほか、ログ環境も実装した。オブジェクトストレージ「Amazon S3」の書き込み保護機能「S3 Object Lock」を利用してデータを改ざん不可能な状態で保管し、サニタイズ（無害化）処理を経て、データをSQLで解析できるクエリサービス「Amazon Athena」を使って分析する。
初期化処理とフックでエージェントを制御
「庁内」には、自律的にタスクを遂行するAIエージェント機能が実装されている。エージェントの実行基盤として、AWSが提供するランタイム「Amazon Bedrock AgentCore Runtime」を採用した。その上にオープンソースSDK「Strands Agents」を利用したエージェントの実装を組み込み、Amazon Bedrock AgentCoreのサンドボックス機能「Code Interpreter」などと連携させている。
エージェントが自律的に状況を判断して目的を達成できるよう、「庁内」では初期化処理と、プログラムの要所に独自の処理を割り込ませる「Event Hook」（フック）の仕組みによって、エージェントの挙動を制御している。初期化時にセッション履歴をロードして過去の文脈（コンテキスト）を判断させ、実行中はフックを使って巨大な入出力データの圧縮や、利用状況の分析をトリガーにしたコスト積算などを自動的に実行する。
こうした内部処理は複雑だが、ユーザーに見えるのは「作業フォルダ」を示すだけのシンプルなUIだ。チャット画面に設けられた作業フォルダは、ユーザーとAIエージェントの双方がファイルを読み書きする共有スペースだ。裏側のユーザーストレージとしてAmazon S3を利用している。
ユーザーが業務文書を作業フォルダにアップロードし、依頼を指示したとする。AIエージェントは該当ファイルを読み込んで処理し、その依頼結果を新たなファイルとして作業フォルダ内に直接保存する。それ以降は、ユーザーが細かな背景を説明しなくても、AIエージェントが過去のファイルを読み込んでコンテキストを理解し、より的確に動作するようになる。
AIエージェントを安全に動かす「3つのセキュリティ境界」
AIエージェントは、自律的にさまざまなツールを試行錯誤して使いこなし、目的を達成する。しかし、AIに自由な振る舞いを無制限に許せば、他のユーザーのデータを覗き見たり、外部の不審なWebサイトと通信したりといった不正操作を引き起こすリスクがある。
「庁内ではAIエージェントが安全に動ける『檻』を作り、その外側に境界を設けることで危ない操作を物理的にできない仕組みにしました」と大月氏は説明する。
第1の境界は「ユーザー境界」だ。ユーザーからのリクエストに含まれる認証情報のJWT（JSON Web Token）を、AWSのサーバーレス実行環境「AWS Lambda」で検証し、「そのユーザーのデータにしかアクセスできない一時的な庫（AWS一時クレデンシャル）」をAIエージェントに渡す。エージェントはこの庫で動作するため、他のユーザーのデータにアクセスしようとしても、AWSの権限管理サービス「AWS Identity and Access Management」（IAM）が即座にブロックする。
第2の境界は「ネットワーク境界」だ。情報漏えいを防ぐため、外部への通信は許可されたドメインにしか到達できないよう制御している。エージェントが稼働するネットワーク（VPC）から外部への通信を、DNSクエリをフィルタリングする「Amazon Route 53 Resolver DNS Firewall」と、ファイアウォールサービスの「AWS Network Firewall」で監視し、許可されていないドメインへのアクセスを拒否する。
第3の境界は「アカウント境界」だ。間接的プロンプトインジェクションなどによって悪意ある指示が外部から混入した際、AIエージェントがだまされないことを保証するのは難しい。そこで、AWSのサービスへつながる通信の出所で、「自組織のAWSアカウントにしかアクセスを許可しない」という厳格なポリシーを設定している。万一AIエージェントがだまされた場合でも、攻撃者が管理するAWSアカウントへのデータ送信を不可能にしている。
UNIXコマンドとパイプ処理でLLMのコンテキスト領域を節約
LLMが一度に処理できるコンテキスト領域（記憶）の容量を防ぐために、「庁内」ではUNIXエンジニアに慣れ親しんだアプローチを採用している。
AIエージェントにファイル操作を行わせる際、独自命令とその使い方を一から説明するとコンテキスト領域を大きく消耗してしまう。そこで、「ls」や「cat」など、LLMが既に学習しているUNIXコマンド名を作業指示に利用した。これによって、事前説明のトークン消耗量を870から400へと半分以下に減らしている。裏側ではLLMが発行したコマンドを、独自に開発したアダプター「s3adapter」で自動変換し、クラウドストレージのファイルを安全に読み書きさせている。
「独自のツール仕様を理解させて複雑なデータの抽出や集計を実行するのは困難です。そこで、複数のコマンドを数珠つなぎにするUNIXのパイプ処理を応用し、LLM自身にコマンドを組み合わせて実行させ、必要なデータをシステム側で絞り込ませています」
「巨大なログからエラー件数を集計して」と指示すると、LLMは「catで開き、grepで絞り出し、sortとuniqで数え上げる」というパイプ処理コマンドを自律的に組み立てて実行する。100MB（10万行）のログデータがシステム側で絞られ、300バイト（10行）の集計結果に絞り込まれる。LLMはこの抽出された結果だけを読み込めばよく、コンテキスト領域を大幅に節約できる。
さらに、大量のデータが直接入力された際の防衛策として「Index Card」と呼ばれる抽出機能も導入した。フックによって入力サイズを自動分類し、64KB以上のデータはLLMに読み込ませず、Amazon S3に保存する。そして、LLMにはファイルサイズや先頭・末尾の一部といった概略（Index Card）だけを通知する。LLMはその概略から自律的に判断し、適切なツールを使ってデータを処理するため、コンテキストの容量を未然に防ぐ。
マルチテナント運用のデータ混在を防ぐ「サイロモデル」
「庁内」を約18万人の職員に展開するには、複数の省庁が共用するマルチテナント運用が欠かせない。一般的なSaaSはインフラを相乗りして効率化するのに対し、「行政機関では分離の徹底が外せない要件だった」と大月氏は説明する。そこで、「庁内」では運用の手間が増えることを承知で、省庁ごとに環境を完全に独立させる「サイロモデル」を選択した。
インフラをコードで定義して構築する「AWS CloudFormation」や「AWS Cloud Development Kit」（AWS CDK）の環境（スタック）を省庁ごとに切り離し、専用のNoSQLデータベース「Amazon DynamoDB」やAmazon S3を個別に構築している。環境を物理的に分けることで、万一プログラムのバグなどで誤って他省庁のデータを参照しようとしても、IAMが防壁になり確実にブロックする。
だが、サイロモデルを採用したことで運用の負担は格段に増大する。環境が独立している分、システムの更新や管理にかかる手間が、利用する省庁の数に応じて膨れ上がる。
少数チームでの運用を可能にする「宣言的インフラ管理」の仕組み
「庁内」のインフラ専任エンジニアは1～2人だ。この少数チームで40以上のテナントを運用し、新機能の開発も並行して進めるためには、徹底した運用の自動化が不可欠だった。そこで、逐一コマンドを叩き込むのではなく、インフラの「あるべき姿」をシステムに提示（宣言）して管理するアプローチを採用した。
それを実現するために、システムをユーザーがAIエージェントを利用する環境（Application Plane）と、それを裏側から自動で構築、管理する仕組み（Control Plane）に分けている。管理者は設定変更などの要件をYAML形式の指示書に記述し、GitHubにチェックインするだけでよい。
これをトリガーにしてControl Plane内の複数のプログラム（Lambda関数）が連動する。最初にシステム構成の正本（SSoT：Single Source of Truth）となるDynamoDBのテーブル「Tenant Master」に指示内容をマージして最新の状態に更新し、現在のインフラの状態と比較する。変更が必要な差分が見つかった場合にのみ、構築作業（デプロイ）を自動的に実行する。
800回の手作業を指示書1つに 5カ月で18万人への展開を実現
ソースコード管理ツールに置いた指示書を起点にしてインフラを自動制御する「GitOps」のアプローチによって、サイロモデルの課題だった運用負担は大きく減った。
40のテナントに20個のアプリを配布するには通常800回の手作業を要するが、「庁内」では指示書をGitHubにチェックインするだけでControl Planeが各テナントに自動配布する。新規テナントの立ち上げも約30行の指示書1つで完結する。Control Planeによる自動配布により、わずか5カ月で約18万人を対象とする展開フェーズに到達した。
一見手の込んだ仕組みを構築したのは、少数チームでシステム運用と新機能の開発を両立させるためだったと大月氏は振り返る。
「これらをうまく解決しながらインフラの運用負荷を最小限にするという命題を解くために、私たちは『全部を宣言にする』という選択肢をとりました。この『庁内』のAIエージェントは、18万人規模の中枢省庁での評価および実証を経た後に、オープンソースとして公開する予定です。ぜひ、皆様の環境でもお試しください」
本稿は、Amazon Web Services（AWS）が主催したイベント「AWS Summit Japan 2026」（開催日：2026年6月25～26日）でデジタル庁の大月真士氏（戦略・組織グループ AI実装統括監 クラウドエンジニア）が「政府の生成 AI 基盤『庁内』| ガバメントクラウド上での AI 実装と AgentCore によるエージェント AI への進化|」というテーマで講演した内容を編集部で再構成したものだ。
