ガバメントクラウド時代に、AI基盤構築は「実験」から「実装」へ進む
行政における生成AI活用は、単なるチャットボットの試行段階から、業務システム・文書管理・住民サービスと接続する実装段階へ移りつつあります。とくにガバメントクラウドの整備が進むことで、各府省庁や自治体は、既存の行政ネットワークや業務データを守りながら、AIをどのように安全に使うかを具体的に検討する必要が出てきました。
デジタル庁はガバメントクラウドの対象クラウドサービスを公表しており、2026年3月時点では「さくらのクラウド」についても本番環境の提供が可能になったとされています。これにより、AWS、Google Cloud、Microsoft Azure、Oracle Cloud Infrastructureに加え、国内クラウドを含めた選択肢が広がっています。
一方で、AI基盤はクラウドにサーバーを立てれば完成するものではありません。入力情報に個人情報や機密情報が含まれる可能性、AI回答の誤り、利用ログの監査、費用の膨張、職員のスキル差といった課題が必ず発生します。アップロード資料でも、ガバメントクラウド環境におけるAI基盤構築は、技術構成だけでなく、ガバナンス、ネットワーク、セキュリティ、運用設計を含めて検討すべきテーマとして整理されています。
ガバメントクラウド上のAI基盤に求められる基本条件
ガバメントクラウド上でAIを活用する場合、まず押さえるべき条件は「安全性」「業務適合性」「運用継続性」の3つです。
安全性とは、個人情報、機密情報、政策形成に関わる未公開情報などを不用意に外部へ流出させないことです。政府情報システムでは、情報セキュリティ水準を確保するための統一的な枠組みとして「政府機関等のサイバーセキュリティ対策のための統一基準群」が位置付けられています。クラウドやAIを使う場合でも、このような基準を前提にした設計が必要です。
業務適合性とは、AIが一般的な文章生成だけでなく、自治体や行政機関が保有する条例、要綱、業務マニュアル、FAQ、過去文書などを踏まえて回答できる状態を指します。行政分野では、汎用AIの知識だけでは不十分です。最新の制度や組織固有の運用ルールに基づいた回答が求められるため、RAG、つまり検索拡張生成の設計が重要になります。
運用継続性とは、導入後も継続して使える体制を作ることです。生成AIは導入直後の注目度が高くても、使い方が難しい、回答が信用できない、費用が読めない、責任範囲が曖昧といった理由で定着しないケースがあります。そのため、AI基盤は「システム導入」ではなく「業務運用の再設計」として捉える必要があります。
構築パターン1：マネージドAIサービスを活用する
もっとも現実的な選択肢は、各クラウド事業者が提供するマネージドAIサービスを活用する方法です。Azure OpenAI Service、Amazon Bedrock、Google Cloud Vertex AIなどを利用し、クラウド事業者側が管理するAIサービスにAPI経由で接続する形です。
この方式の利点は、導入の速さと運用負荷の低さにあります。サーバー、GPU、ミドルウェア、モデル管理をすべて自前で抱える必要がなく、既存の業務システムやWebアプリケーションからAPI連携しやすい点が大きなメリットです。AI活用を早期に始めたい自治体や、まず庁内業務の効率化から取り組みたい組織には向いています。
ただし、マネージドサービスを利用する場合でも、入力データの扱い、ログ保存、アクセス制御、利用範囲の制限は自組織側で設計しなければなりません。ISMAPでは、政府情報システムに利用するクラウドサービスについて、安全性評価を受けたサービスリストが公開されています。クラウド選定時には、単にAI機能があるかどうかではなく、行政利用に耐えるセキュリティ評価や契約条件を確認する必要があります。
構築パターン2：RAGで行政文書・庁内知識と接続する
行政AI基盤で特に重要なのが、RAGによる独自知識連携です。RAGは、AIにすべてを記憶させるのではなく、必要な文書を検索し、その検索結果を根拠として回答を生成させる仕組みです。
たとえば、自治体の条例、例規集、補助金要綱、手続きマニュアル、議会答弁、住民向けFAQなどをベクトルデータベースに格納し、職員の質問に応じて関連文書を検索します。そのうえで、AIが検索結果を参照しながら回答を生成することで、一般的なAI回答よりも業務に即した回答を得やすくなります。
ただし、RAGを導入すれば自動的に正確になるわけではありません。古い文書が残っていれば古い制度に基づいて回答する可能性がありますし、文書の粒度が粗ければ、必要な根拠にたどり着けないこともあります。したがって、RAGの成否は、AIモデルそのものよりも、文書の構造化、更新ルール、検索対象の整理、回答検証フローに左右されます。
行政分野では、最終的な判断責任をAIに委ねるのではなく、AIを「下書き」「検索補助」「論点整理」のために使い、人間が確認する運用が現実的です。デジタル庁の生成AI調達・利活用ガイドラインでも、生成AIの利活用促進とリスク管理を一体で進めることが重視されています。
構築パターン3：IaaS・専有環境でモデルを構築する
高度な機密性や特殊な用途が求められる場合、IaaSや専有環境上にGPUインスタンスを立て、オープンソースLLMや独自モデルを運用する方法もあります。モデルの内部制御、データ保管場所、ファインチューニング、推論環境を細かく設計できるため、柔軟性は高くなります。
しかし、この方式は技術的難度と運用負荷が大きくなります。GPUコスト、モデル更新、脆弱性対応、性能監視、負荷分散、障害対応などを自組織または委託事業者が継続的に担う必要があります。自治体や中小規模の行政組織が最初からこの方式を採用するのは、現実的ではない場合も多いでしょう。
そのため、基本方針としては、まずマネージドAIサービスや共通基盤を活用し、どうしても要件を満たせない場合に限って専有環境を検討する流れが妥当です。これはコスト、セキュリティ、人材確保の観点からも堅実な判断です。
ネットワーク接続ではLGWAN・閉域接続・インターネット接続を分けて考える
行政システムでは、AI基盤と既存ネットワークをどう接続するかが大きな論点になります。自治体ではLGWANなど、インターネットから分離された環境で業務システムを運用しているケースが多く、AIサービスに接続する際も経路設計が重要です。
代表的な接続方法としては、専用線による閉域接続、クラウド間接続サービス、限定的なインターネットVPN接続などがあります。機密性の高い業務では閉域接続が望ましい一方、概念実証や限定利用では、対象データを絞ったうえでインターネット経由の接続を使うケースも考えられます。
ここで重要なのは、すべてを一律に厳しくすることではありません。扱うデータの重要度、利用する業務、想定されるリスクに応じて接続方式を分けることです。たとえば、公開情報をもとにした職員向けFAQと、個人情報を含む相談記録の分析では、求められるネットワーク設計もセキュリティ要件も異なります。
セキュリティ・ガードレールはAI基盤の前提条件になる
AI基盤で避けられないのが、入力制御と出力制御です。職員がプロンプトに個人情報や機密情報を入力してしまう可能性は常にあります。これを職員の注意だけで防ぐのは限界があります。
そのため、DLP、つまりデータ損失防止の仕組みによって、マイナンバー、住所、氏名、電話番号、機密語句などを検知し、送信前にマスキングまたは警告する仕組みが必要です。また、SSOや職員IDと連携し、誰が、いつ、どのAI機能を、どの業務で使ったのかを記録することも重要です。
加えて、AIの出力には誤情報や不適切表現が含まれる可能性があります。AIがもっともらしい文章を生成しても、それが制度上正しいとは限りません。行政文書、住民向け案内、政策判断に関わる用途では、回答をそのまま公開・送付するのではなく、人間による確認プロセスを必ず組み込むべきです。
「源内」と「A1」は共通利用基盤の方向性を示している
政府・自治体領域では、個別組織がそれぞれAI基盤をゼロから作るのではなく、共通利用基盤を整備し、ノウハウやアプリを共有する方向が強まっています。
デジタル庁のガバメントAI「源内」は、政府職員向けの生成AI利用環境として整備が進められており、2026年4月にはOSSとして公開されています。また、2026年度中に全府省庁の約18万人の政府職員が利用可能となる予定も示されています。
東京都とGovTech東京が進める生成AIプラットフォーム「A1（えいいち）」も注目されます。A1は、職員が業務課題に応じたAIアプリを作成・共有できる共通基盤として位置付けられており、他自治体での再利用も視野に入れた「デジタル公共財」としての展開が期待されています。
これらの事例が示しているのは、行政AIの価値は単体ツールではなく、組織横断で使える共通基盤にあるということです。プロンプト、業務アプリ、RAG用データ、利用ルール、研修教材を共有できれば、小規模自治体でもAI活用の入口を作りやすくなります。
導入時に失敗しやすいポイント
ガバメントクラウド上のAI基盤構築で失敗しやすいのは、技術選定だけを先に進めてしまうことです。どのクラウドを使うか、どのモデルを使うか、どのAPIを使うかは重要ですが、それ以前に「何の業務を、どの範囲で、どの責任体制でAI化するのか」を決める必要があります。
たとえば、個人情報を含む相談業務にAIを使う場合、入力制限、ログ保存、アクセス権限、回答確認、住民説明のすべてが必要になります。一方、公開資料の要約や会議資料の下書きであれば、比較的低リスクに始められます。
もう一つの失敗要因は、費用管理です。生成AIは利用回数や処理量に応じてコストが増えるため、庁内で利用が広がるほど予算超過のリスクがあります。部署別の利用上限、用途別のモデル選択、軽量モデルの活用、月次レポートによる可視化が必要です。
まとめ：AI基盤構築は「クラウド選定」ではなく「行政運用設計」である
ガバメントクラウド環境におけるAI基盤構築では、マネージドAIサービス、RAG、IaaS・専有環境という複数の構築パターンがあります。最初の一歩としては、運用負荷の低いマネージドサービスを活用し、業務固有の知識が必要な領域ではRAGを組み合わせる方法が現実的です。
ただし、AI基盤は技術だけでは成立しません。ネットワーク接続、DLP、SSO、ログ監査、回答確認、費用管理、職員教育を含めた運用設計が不可欠です。とくに行政分野では、AI回答の便利さよりも、説明責任と信頼性が重視されます。
今後、ガバメントAI「源内」や東京都の「A1」のような共通利用基盤が広がれば、自治体単独では難しかったAI導入のハードルは下がる可能性があります。しかし、共通基盤を使う場合でも、自組織の業務、データ、責任範囲に合わせたガバナンス設計は避けて通れません。
2026年以降の行政AI活用では、「AIを導入するかどうか」ではなく、「どの業務に、どの安全策を置き、どの責任体制で使うか」が問われます。ガバメントクラウド上のAI基盤は、行政DXを支える重要な土台になりますが、その成否は、技術選定よりも運用設計の成熟度にかかっています。
コメント