18万人に展開する生成AI基盤、開発チームは4～5人 - デジタル庁「源内」の舞台裏

デジタル庁は、政府内製の生成AI基盤「源内」を全府省庁の職員約18万人に展開する大規模実証を進めている。6月25日に開催された「AWS Summit Japan 2026」では、同庁の大月真史氏が、AIエージェントの実装やセキュリティ対策、約40テナントへの展開を支える運用設計を紹介した。4～5人の開発チームで大規模な基盤をどのように構築・運用するのか。その技術的な工夫を解説する。

デジタル庁戦略・組織グループ AI実装総括班クラウドエンジニア　大月真史氏

政府の生成AI基盤「源内」、約18万人を対象に大規模実証

源内は2024年12月に初版をデプロイし、2025年5月にデジタル庁職員が利用を開始した。2026年1月には19省庁へ試験導入し、同年5月から全府省庁の約18万人を対象とする大規模導入実証を開始。2027年度からの本格利用を目指している。

デジタル庁での利用、19省庁での試験導入を経て、約18万人を対象とした大規模導入実証へ。2027年度からの本格利用と、その先の「AIネイティブ行政」を見据える

源内は、全職員が共通の画面から利用できる一方、用途に応じてAIアプリケーションを追加できる。講演時点では20種類以上のAIアプリを提供し、チーム単位で利用できるアプリを出し分ける仕組みを備えていた。補助金制度の調査やガイドラインへの適合確認など、行政ならではの用途に対応するほか、AWSだけでなくGoogle CloudやAzureも組み合わせたマルチクラウド構成を採用している。

さらに、AIエージェントでは、ユーザーとエージェントが同じストレージを作業場所として使う。たとえば、エージェントがPDFを要約し、その結果を自ら書き戻す。職員とエージェントがAmazon S3上のワークスペースを共有し、セッション履歴はAmazon DynamoDBで管理する構成だという。

エージェントの実行基盤にはAmazon Bedrock AgentCore Runtimeを採用し、AIが推論とツールの呼び出しを繰り返す処理にはStrands Agentを利用する。さらに、初期化処理とイベントフックを組み合わせ、セッション履歴の保存やコストの積算、大量の入出力データの圧縮などを制御している。

AIエージェントが「だまされても危ないことができない」3つの仕組み

AIエージェントは、自ら手順を考えてツールを呼び出し、得られた結果を基に次の処理を決める。この試行錯誤を自動で繰り返せることが強みだが、自由に動ける範囲が広いほど、セキュリティ上のリスクも増す。

そこで源内では、エージェントそのものに「やってはいけない」と教え込むだけではなく、エージェント自身が変更できないインフラ層に境界を設ける考え方を採用した。具体的には、他のユーザーとして振る舞えない「ユーザー境界」、許可されていない外部通信を防ぐ「ネットワーク境界」、持ち込まれたクレデンシャルを使って組織外のAWSアカウントへデータを送ることを防ぐ「アカウント境界」の3つだ。

AIエージェントの自律性を損なわず、安全性を確保するための3つの境界。ユーザー、ネットワーク、アカウントの各レベルで危険な操作を防ぐ

大月氏は、エージェントの動作は毎回同じになるとは限らず、プロンプトだけで「だまされないこと」を保証するのは難しいと説明する。そこで目指すのが、「だまされても危ないことができない」仕組みだ。悪意ある文書から間接プロンプトインジェクションを受けても、許可されていない外部アカウントへのデータ送信をインフラ側で拒否する。

具体的には、ユーザーごとにアクセス可能なデータをIAMで制限し、ネットワークでは許可されていないドメインへの通信を遮断する。さらに、AWSのAPIを経由した通信についても、組織外のアカウントへのアクセスを制限する。エージェントの動きを一律に制限するのではなく、危険な操作だけを実行できなくする考え方である。

Unix/Linuxのコマンドを活用、ツール説明のトークン数を54%削減

エージェントを効率よく動かすための工夫も紹介された。その一つが、ファイル操作のツールを独自仕様にするのではなく、「ls」「cat」「grep」といったUnix/Linuxで一般的な語彙に寄せることだ。

独自のツール名を使うと、LLMは説明を読んで操作方法を理解しなければならない。一方、学習データに数多く含まれる一般的なコマンドなら、「まずlsでファイルを確認し、catやgrepで必要な情報を取り出す」といった手順をあらかじめ知っている。「LLMに教え込まない。LLMがすでに知っていることを使う」という設計である。

この設計により、ツールの使い方をLLMに説明するためのトークン数は、従来の870から400へと約54%削減された。独自の操作方法を一から説明するのではなく、LLMが学習済みの知識を活用することで、コンテキストの消費を抑えている。

さらに、100MBのログをそのままLLMへ渡すのではなく、grepやcut、sort、uniqなどで必要な情報を絞り込み、約300バイトにしてから渡す例も示された。大量のデータでコンテキストを使い切り、「エージェントが記憶喪失にならない」ようにする工夫だ。

Unix/Linuxのコマンドを組み合わせ、100MBのログから必要な情報を約300バイトまで絞り込む処理の例

大量のデータを扱う際には、「Index Card」と呼ぶ仕組みも採用している。入力やツールの出力が大きくなった場合、内容をそのままLLMに渡すのではなく、ファイルの先頭・末尾や行数、頻出する語句などをルールに基づいて抽出する。

特徴は、LLM自身に要約させないことだ。要約の過程で重要なキーワードや数値が失われることを避け、必要な情報をエージェントが後から取り出せるようにする。こうした仕組みによってコンテキストの枯渇を防ぎ、処理の継続性を確保している。

4～5人の開発チームで約40テナントを管理する仕組み

後半のテーマは、源内を中央省庁へ大規模展開するためのマルチテナント運用だ。源内ではセキュリティ上の分離を重視し、テナントごとに独立した環境を持たせる方式を採用している。一方、環境を分離すれば、テナント数に比例してデプロイや更新の運用負荷が増えてしまう。

テナント分離には、インフラを共有する「プールモデル」ではなく、テナントごとに独立したシステム構成を持つ「サイロモデル」を選択した。データやリソースを分離しやすく、IAMによって他のテナントへのアクセスも防止できる一方、環境ごとのデプロイや更新が必要になる。源内では、この運用負荷を宣言的なインフラ管理によって抑える方針を採った。

新しいテナントを作る際、管理者が本番環境に入って一つずつリソースを構築する必要はない。YAMLに望ましい状態を記述してGitHubへマージすると、コントロールプレーンが現状との差分を検出し、必要な設定やデプロイを自動で実行する。