解説
大規模なマルチテナント環境において、高いセキュリティレベルを維持しつつ運用効率を上げることは、システム開発・運用の大きな課題です。この記事では、デジタル庁が運営する生成AI基盤「源内」の設計思想に焦点を当てています。
単に性能が高いだけでなく、「どう安全に」「どう効率的に動かし続けるか」という、大規模な運用上の知見が詰まっています。特に、行政特有の厳格なセキュリティ要件と、多数の部署が共用する高い拡張性を両立させている点がポイントです。
自社で複数の部門やシステムを扱う際に、「分離性(サイロ化)」と「自動運用」のバランス設計を検討する上で、参考となるアーキテクチャや概念が多く確認できます。
ポイント
- デジタル庁が運用する生成AI基盤「源内」は、AWS上で構築されたマルチクラウド構成のシステムである。
- 各省庁ごとに環境を物理的に分離する「サイロモデル」を採用し、セキュリティを極限まで高めている。
- この大規模かつ多テナントな環境を少数精鋭のチームで運用するため、「GitOps」を用いた徹底した自動化(コントロールプレーン)が導入されている。
情シスへの影響
1. アーキテクチャ構造とガバナンスに関連する設計
源内は、AWS, Google Cloud, Microsoft Azureを併用するマルチクラウド構成であり、生成AIの基盤として複数のパブリッククラウドサービス(LLM推論エンジンなど)を扱う必要があります。これは、セキュリティやコンプライアンスの観点から、利用可能な全ての外部APIおよびデータフローに対する厳格なポリシー設計が求められることを示唆します。
2. セキュリティ制御と境界防御の実装
以下の3層構造による高度なアクセス制御が行われています。AIエージェント(自律動作するシステム)の行動を制約し、情報漏洩や不正操作を防ぐ「物理的な防御壁」が設けられています。
-
ユーザー境界: AWS LambdaとIAMを利用して、利用者のデータのみに限定された一時的な認証情報(AWS一時クレデンシャル)を与えることで、他のテナントへの越境アクセスを阻止します。
-
ネットワーク境界: Amazon Route 53 Resolver DNS FirewallやAWS Network Firewallを用いて、外部通信先を許可されたドメインに限定し、意図しないデータ漏洩リスクを低減しています。
-
アカウント境界: AWSのポリシー設定により、AIエージェントが万一だまされた場合でも、組織(本自組織)のAWSアカウント以外の外部への不正な送信を防ぐ仕組みがあります。
3. 運用の自動化とガバナンス体制(GitOps的アプローチ)
多数のテナントを個別に運用する「サイロモデル」は管理負荷が高い反面、セキュリティ上の分離性は最大化されます。この高負荷な環境を運用するために、「GitOps」という仕組みが採用されています。
-
インフラ構成の定義と変更(意図される「あるべき姿」)をYAML形式で記述し(宣言)、それをGitHubなどのソースコード管理ツールにコミットすることを起点として、コントロールプレーン側から各テナント環境への自動デプロイ(差分検出・適用)を行う仕組みです。
-
これにより、手動による操作ミスを防ぎつつ、多数のテナントに対する一貫した構成管理とアップデートを低コストで実現しています。
影響範囲
AWS (AWS Lambda, IAM, S3 Object Lock, Amazon Athena, AWS Network Firewall, Amazon Route 53 Resolver DNS Firewallなど), Google Cloud, Microsoft Azureを利用するマルチクラウド環境全般。特に、複数のテナント(省庁別)を持つ大規模なSaaSやAIプラットフォームを管理・運用している情シス部門が対象。影響範囲は、認証認可(IAMの概念)、データストレージ(S3での改ざん防止設定)、ネットワーク通信制御(VPC、ファイアウォール、DNSフィルタリング)、そしてインフラ構成管理の方法論(Infrastructure as Code / GitOps)全般にわたる。
※具体的にどのAWSサービスや機能が使われているかの知見は必要だが、これらの概念自体は一般的な情シスで管理対象となる。
重要度
★★★★☆
対象者
- セキュリティ担当者
- ネットワーク管理者
- DevOpsエンジニア
優先度
計画的に対応
優先度の理由
「源内」の技術は実証段階での成功事例紹介であり、即時的な脆弱性や仕様変更に基づく危機管理行動は求められません。しかし、自社でマルチテナント環境を構築・運用する際(特に複数の部門や部署が利用する基幹システムの場合)に、「サイロモデルによる分離」と「GitOpsによる運用の自動化」という高度な設計思想を参照し、今後の計画的なアーキテクチャ検討およびセキュリティポリシーの強化に活かす必要があるため。
確認手順
-
- 現在管理しているマルチテナント環境におけるデータ分離(テナント間隔離)の方法論を確認する(物理的分離か、ロジカル分離か)。
-
- 外部接続が必要なシステムについて、通信先IPアドレスやドメインを事前に特定し、DNS/FWによる出所指定型フィルタリングが適用されているか確認する。
-
- インフラストラクチャの構成定義ファイル(IaC)が存在するか、また、その変更履歴管理とデプロイプロセスがGitOpsの考え方に基づいているかを確認する。
-
- AWS IAMなどの権限管理サービスを利用し、最小権限の原則に基づき、一時的な認証情報やロールを用いてリソースへのアクセス制御を行っているかレビューを行う。
推奨対応
- 自社でマルチテナント環境を構築する場合、セキュリティ要件に応じて「サイロモデル」と「論理分離(例:特定のIAMポリシーによる厳格な権限管理)」のトレードオフを明確に定義してください。
運用の自動化に関しては、「GitOps」アプローチを採用し、インフラ構成管理をコードとして定義・バージョン管理することで、人的ミスを排除し、継続的なコンプライアンス遵守体制を構築することが推奨されます。具体的には、設定ファイルの変更(desired state)を起点に、実際の環境(actual state)と差分を取り、自動で適用するパイプラインの整備を進めてください。
– AIエージェントの自律行動の利用を検討する場合、今回紹介されたような「役割限定型」の認証情報付与や、「外部連携API」に対する厳格な出所指定型のアクセス制御メカニズム(Boundary)の実装を検討し、セキュリティポリシーを見直してください。
出典・公式情報:
行政機関18万人を支える「源内」 わずか1~2人での運用を実現した“一見手の込んだ仕組み”
本記事は、上記の公開情報をもとに、情報システム担当者向けに要点・影響・確認ポイントを整理したものです。脆弱性対応・製品仕様・更新情報は変更される可能性があります。実際の対応前に必ず元記事・公式情報をご確認ください。
