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