行政機関18万人を支える「源内」 わずか1〜2人での運用を実現した“一見手の込んだ仕組み”：AWS Summit Japan 2026

省庁ごとに環境を分ければセキュリティは上がるが、運用の手間はテナントの数だけ膨らむ――。約18万人の職員が利用する生成AI基盤「源内」で、デジタル庁はこの二律背反をどう乗り越えたのか。インフラ担当者1〜2人体制で「高いセキュリティ」と運用の効率化を両立させる設計とは。

[名須川竜太，ITmedia]

　デジタル庁は、行政機関の職員が日々の業務で活用できる生成AI環境をガバメントクラウドに構築し、各省庁への展開を進めている。それが、Amazon Web Services（AWS）が公開する生成AIアプリ構築用のオープンソースソフトウェア（OSS）「Generative AI Use Cases」（以下、GenU）をベースに内製開発された生成AI基盤「源内」だ。職員が直感的に操作できるUIと、行政特有の多様な業務アプリを接続できる拡張性を備えている。

　源内は現在、約18万人の職員を対象とする大規模な展開フェーズにある。デジタル庁は、厳格なセキュリティが求められる大規模なマルチテナント環境を、インフラ専任エンジニア1〜2人の体制で運用している。

　同基盤の開発をリードするデジタル庁の大月真史氏（戦略・組織グループ AI実装総括班 クラウドエンジニア）が、その設計思想と運用の詳細を明かした。AIエージェントの暴走を防ぐ物理的な防御壁やLLM（大規模言語モデル）の記憶枯渇を防ぐ工夫、運用負担を減らす自動化の仕組みなど、源内のアーキテクチャのポイントを紹介する。

マルチクラウド構成の「源内」　使いやすさと拡張性はどう両立させた？

　源内は2025年5月のデジタル庁内での利用開始から中央省庁への試験導入を経て、現在は約18万人を対象とした大規模導入実証の最中にある。2026年度中に全府省庁の約18万人が生成AIを利用可能になることを見据えた展開だ。

　源内のUIには「デジタル庁デザインシステム」を適用した。アクセシビリティに配慮し、直感的に操作できるデザインを採用している。物品管理システムやガイドライン適合性の確認など、行政業務に特化したAIアプリケーションを追加できる拡張性を備えている点も特徴だ。

図1　源内のトップページ（左側）とアプリケーション選択画面（右側）。多様な業務アプリを選択できる（出典：大月氏の講演資料）

　源内の中核システムは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」（フック）の仕組みによって、エージェントの挙動を制御している。初期化時にセッション履歴をロードして過去の文脈（コンテキスト）を把握させ、実行中はフックを使って巨大な入出力データの圧縮や、利用状況の分析をトリガーにしたコスト積算などを自動的に実施する。

図2　初期化処理とEvent Hookを組み合わせたAIエージェントの内部構造（出典：大月氏の講演資料）

　こうした内部処理は複雑だが、ユーザーに見えるのは「作業フォルダ」を示すだけのシンプルなUIだ。チャット画面に設けられた作業フォルダは、ユーザーとAIエージェントの双方がファイルを読み書きする共有スペースだ。裏側のユーザーストレージとしてAmazon S3を利用している。

　ユーザーが業務文書を作業フォルダにアップロードし、要約を指示したとする。AIエージェントは該当ファイルを読み込んで処理し、その要約結果を新たなファイルとして作業フォルダ内に直接保存する。それ以降は、ユーザーが細かな背景を説明しなくても、AIエージェントが過去のファイルを読み込んでコンテキストを理解し、より的確に動作するようになる。

図3　源内のチャット画面。複雑な内部処理を隠し、「作業フォルダ」を介してAIエージェントとファイルを共有するシンプルなUIになっている（出典：大月氏の講演資料）

AIエージェントを安全に動かす「3つのセキュリティ境界」

　AIエージェントは、自律的にさまざまなツールを試行錯誤して使いこなし、目的を達成する。しかし、AIに自由な振る舞いを無制限に許せば、他のユーザーのデータを盗み見たり、外部の不審なWebサイトと通信したりといった不正操作を引き起こすリスクがある。

　「源内ではAIエージェントが安全に動ける“箱”を作り、その外側に境界を設けることで危ない操作を物理的にできない仕組みにしました」と大月氏は説明する。

　第1の境界は「ユーザー境界」だ。ユーザーからのリクエストに含まれる認証情報のJWT（JSON Web Token）を、AWSのサーバレス実行環境「AWS Lambda」で検証し、「そのユーザーのデータにしかアクセスできない一時的な鍵（AWS一時クレデンシャル）」をAIエージェントに渡す。エージェントはこの鍵で動作するため、他のユーザーのデータにアクセスしようとしても、AWSの権限管理サービス「AWS Identity and Access Management」（IAM）が即座にブロックする。

図4　源内のユーザー境界の設計。JWTを使って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はこの抽出された結果だけを読み込めばよく、コンテキスト領域を大幅に節約できる。

図5　源内では、UNIX風のファイル操作コマンドとパイプ処理を採用し、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」に指示内容をマージして最新の状態に更新し、現在のインフラの状態と比較する。変更が必要な差分が見つかった場合にのみ、構築作業（デプロイ）を自動的に実行する。

図6　YAMLで書いた指示書をGitHubにチェックインすると、それを読んだControl Planeによって自動的にデプロイが実行される（出典：大月氏の講演資料）

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 への進化−」というテーマで講演した内容を編集部で再構成したものだ。