2026年4月24日、デジタル庁がガバメントAI「源内」のソースコードを公開した（当時の解説記事）。リポジトリを眺めながら考えていたのは、「これはAWSの外でも動くのか」という素朴な問いだった。源内はガバメントクラウド上のAWSを前提に構築されており、公開されたコードにもCDK、Cognito、DynamoDBといった依存がそのまま残っている。コードが読めることと、自分の環境で動かせることのあいだには、かなりの距離がある。
EastCloudでは2026年6月、この距離を実測するために、源内のWebフロントエンドをさくらのクラウド上で動かす検証プロジェクトを社内で立ち上げた。先に結論を書いておく。エージェントを選び、実行し、さくらのAI Engineから回答が返ってくるという最小限の体験は、さくらのクラウドのマネージドサービスの組み合わせで成立した。ただし、源内の全機能が動いたわけではない。本稿では、何を動かし、何を意図的に後回しにし、どこでつまずいたかを記録する。
前提 — これは公式の移植ではない
最初に断っておきたい。ここで扱うのは、当社が社内で「源内 on Sakura」と呼んでいる検証実装であり、デジタル庁の公式プロジェクトでも、デジタル庁が認めた移植版でもない。公開されたOSSを、ライセンスの範囲で第三者が別のクラウドへ載せてみた、という位置づけである。
ライセンス面は少し注意がいる。源内のWeb側リポジトリ genai-web はMITライセンスが中心だが、一部のLambdaやCDK関連ファイルはAmazon Software Licenseの対象になっている。取り込む範囲を決める際には、ファイル単位でヘッダを確認した。今回の検証では上流のv1.0.7を固定し、取り込んだ範囲・除外した範囲・当社で改変した範囲をコミットで分離して、どこまでが源内由来でどこからが改修かを後から説明できるようにしている。AWS依存の塊であるインフラ定義（CDK）は、そもそも持ち込んでいない。
なぜさくらのクラウドで動かすのか
理由は源内そのものの文脈にある。源内は、政府のAI基盤を特定ベンダーへの依存を抑えながら育てるという流れの中にいて、国産LLMの選定もOSS公開もその一環と読める。一方、受け皿となる国内インフラの側では、さくらのクラウドがガバメントクラウドの対象クラウドサービスとして正式採択された（経緯はこちらの記事）。
つまり「政府製のAIアプリケーション資産」と「国産のガバメントクラウド対応インフラ」が、それぞれ別の理由で揃いつつある。なら実際に載せてみればいい、というのが今回の動機である。なお、EastCloudはさくらインターネットのパートナーとして日常的にさくらのクラウドを扱っているが、本稿は検証の記録であり、動いたものは動いた、動かなかったものは動かなかったとそのまま書く。
源内のAWS依存を数えるところから始めた
移行でやりがちな失敗は、AWSのサービス名を国産クラウドのサービス名へ1対1で読み替えて、そのまま持ち込もうとすることだ。今回はまず、源内のWeb側が実際に何へ依存しているかを棚卸しし、そのうえで「初期の最小構成に必要なもの」と「今は置き換えないもの」を切り分けた。主要な依存と今回の扱いは次のとおり。
| AWS側 | 源内での役割 | 今回の扱い |
|---|---|---|
| S3 + CloudFront | フロントエンド配信 | オブジェクトストレージ+ウェブアクセラレータを検証したうえで、初期構成ではAppRun同梱配信を採用（後述） |
| API Gateway + Lambda | APIの入口とバックエンド処理 | AppRun上のGo製ゲートウェイ / APIへ責務ごと置き換え |
| Cognito | ユーザー認証 | 持ち込まない（Cognitoは今回使っていない）。代わりに検証用の共有アクセスゲートを別途用意（個別アカウント管理は範囲外） |
| DynamoDB | チャット履歴などの永続化 | 使わない。履歴永続化そのものを初期範囲から除外 |
| Bedrock | モデル実行 | さくらのAI Engineをプロバイダアダプタ経由で利用 |
| Secrets Manager / KMS | シークレット保護 | さくらのシークレットマネージャ / KMSを正本に |
| CloudWatch | ログ・監視 | AppRunの標準ログでリクエストIDを突き合わせて動作・障害を確認。ダッシュボードやアラート等の監視設計は未着手 |
表にすると整然として見えるが、実際の判断はもう少し泥臭い。たとえばLambdaは「Lambdaの代替探し」をすると失敗する。HTTPの同期APIなのか、キュー処理なのか、スケジュール実行なのかで置き換え先は変わるからで、今回はHTTP同期APIだけを対象に、AppRun上の常駐Goプロセスへ寄せた。キューやスケジュールの置き換えは、それを必要とする機能に手を付けるときに個別に考える。
最小構成のかたち
今回の構成はこうなった。
設計上こだわった点が3つある。
第一に、AIの呼び出しをサーバサイドへ閉じたこと。ブラウザからAI Engineを直接叩かず、APIキーもフロントエンドへ出さない。エージェント定義のうちシステムプロンプトのような実行時情報はサーバ側だけが持ち、画面には表示用の情報だけを渡す。
第二に、失敗を成功に見せないこと。プロバイダが未設定なら「未設定」というエラーで止める。AI Engine側でエラーが返れば、サンプル回答やそれらしいダミーで取り繕わず、安全なエラーとして返す。この種の検証では一般に、ダミー応答を本物の成功と取り違えたまま進んでしまう事故が起きやすい。今回は、そうならないことを失敗系のテストで確認しながら進める方針を最初に決めた。
第三に、追跡IDの境界を決めたこと。障害調査にはリクエストの追跡IDが要る。ただ、AIプロバイダ側の内部IDをそのままブラウザへ返すと、外部サービスの内部情報を利用者へ露出することになる。今回はゲートウェイが発行するリクエストIDだけをクライアントへ返し、プロバイダ側IDとの対応はサーバのログに閉じた。
認証について補足しておく。今回の「共有アクセスゲート」は、検証環境に鍵をかけるための入口であって、ユーザー認証ではない。個別アカウントも、テナントも、権限管理も、監査証跡も、ここからは何も主張できない。Cognitoの置き換えは、この検証の範囲外として明確に残してある。
動いたもの
最終的に、次の一連の流れがさくらのクラウド上で動いた。
- ブラウザでアクセスし、共有アクセスゲートを通過する
- エージェントの一覧と詳細を表示する
- テキスト生成系のエージェントを選んで実行する
- さくらのAI Engineが生成した回答が画面に返る
成功パターンだけでなく、失敗パターンも確認した。プロバイダ設定を意図的に壊した状態で実行すると、フェイクの成功応答に化けることなく、エラーとして返ってくる。地味だが、この失敗系の確認こそ検証の本体だと思っている。
動かしていないもの
ここを曖昧にすると「源内がさくらで完全に動いた」という誤解が独り歩きするので、動かしていないものを明記する。
- チャット履歴・実行履歴の永続化（データベースを使っていない）
- RAG、ファイルアップロード、画像生成などの拡張機能
- ユーザー別の認証・テナント・権限・管理画面
- 利用量・コスト管理、監査ログの永続化
- 本番運用を前提とした監視・アラート・運用手順
つまり動いたのは「源内の最小の背骨」であって、源内互換の完成品ではない。背骨が通ることと、全身が動くことは別の話である。ただ、この距離感そのものが、移行を検討する人にとっては有用な情報になるはずだ。
つまずいた壁 — 3つだけ挙げる
検証で越えた壁のうち、ほかの人も踏みそうなものを3つ記録しておく。
壁1. SPAのdeep linkが404になる
源内のフロントエンドはReact RouterのSPAで、/chat/:id のようなURLへの直接アクセスに対して、配信側が index.html を返す仕組みを前提にしている。AWSではCloudFrontのカスタムエラーレスポンスが担っているこの挙動が、さくらの静的配信には見当たらなかった。今回はAppRun上のゲートウェイでルートを分類して解決した。ここは論点が多いので、続編の記事で検証内容ごと掘り下げる。
壁2. シークレットの注入
シークレットマネージャを秘密情報の正本にしたが、AppRun（共用型）のアプリケーションからシークレットマネージャの値を直接参照する方法は、検証時点では確認できなかった。今回は検証限定の暫定運用として、同じ値をAppRun側へ手動登録する二重管理にした。二重管理は更新漏れの温床になるので、長く続けたい形ではない。ここはAppRunからシークレットマネージャを直接参照できる公式対応を待ちたいところで、それまでは、APIやIaCで両者の同期を自動化して更新漏れを防ぐのが現実的だと考えている。
壁3. どこまで隠すか
AIプロバイダの生のエラー本文をそのまま返すと、内部情報が漏れる。かといって全部を握りつぶすと調査ができない。公開してよいエラーコードとメッセージを許可リストで定め、それ以外はサーバログ側で追う、という整理に落ち着いた。
なお、この種の検証結果には賞味期限がある。上記はいずれも2026年6月中旬から下旬にかけての実機検証に基づくもので、さくらのクラウドは機能追加のペースが速い。実際、当社の別の検証では、一度「構造的に不可能」と結論づけた制約が、その後の機能提供で解けた例もあった。重要な判断の前には、必ず現行の公式ドキュメントを確認してほしい。
さくらのクラウドに期待したいこと
検証を終えて、要望を2つに絞るならこうなる。1つは、静的配信側での任意ルートfallback。存在しないURLへのアクセスを指定ドキュメントへ返せれば、SPAはオブジェクトストレージとウェブアクセラレータだけで完結し、AppRunはAPIに専念できる。もう1つは、AppRunからシークレットマネージャへの直接参照。この2つが揃うと、AWSで当たり前だった構成との段差がだいぶ埋まる。
一方で、擁護もしておきたい。AppRunにフロントエンドとゲートウェイを同梱する構成は、回り道のようでいて、どのルートを画面へ返しどのルートをAPIとして扱うかが設計として明示される利点があった。そして何より、コンテナレジストリにイメージを置き、AppRunへ載せ、AI Engineへつなぐという流れは素直で、最小構成のMVPまでは想像より短い距離で到達できた。
まとめ
- 源内のWebフロントエンドは、さくらのクラウド（AppRun + AI Engine + シークレットマネージャ等）の上で、エージェント実行の最小体験まで動いた
- 動かしていない領域（履歴・RAG・認証・運用堅牢化）は多く残っており、「動いた」と「置き換えられた」は別物である
- AWS依存はサービス名の読み替えではなく、責務単位で棚卸ししてから置き換える
- 検証結果には日付を付ける。クラウドの制約は動く
源内のOSS公開を「読む」ところから「動かす」ところへ進めてみて、参照実装としての政府OSSという設計の意味が、少しだけ体感として分かってきた。続編では、今回さらりと流したSPA deep linkの壁を、検証で確認できた事実ベースで掘り下げる。
よくある質問
Q1. 政府AI「源内」とは何か
デジタル庁が内製で開発・運用している政府職員向けの生成AI利用環境である。2026年4月にWeb側の genai-web とアプリ側の genai-ai-api がGitHubで公開され、第三者もライセンスの範囲で利用できる。
Q2. 源内のソースコードは商用利用できるか
中心はMITライセンスであり商用利用できる。ただし一部のファイルはAmazon Software Licenseの対象なので、利用する範囲をファイル単位でヘッダ確認したい。
Q3. 源内はAWS以外のクラウドでも動くか
そのままでは動かない。Cognito・DynamoDB・CloudFrontといったAWS前提の依存を棚卸しし、責務単位で代替へ置き換える必要がある。本記事の検証では、さくらのクラウド上でエージェント実行の最小構成が動作した。
Q4. さくらのクラウドで源内を動かすには、どのサービスを使うか
本検証では、AppRun（コンテナ実行）、さくらのAI Engine（モデル実行）、シークレットマネージャ、コンテナレジストリを組み合わせた。チャット履歴の永続化やユーザー別認証は、検証範囲に含めていない。
Q5. さくらのAI Engineとは何か
さくらインターネットが提供する生成AIの実行基盤で、APIから各種モデルを呼び出せる。本検証では、AWSのBedrockが担っていたモデル実行の置き換え候補として、サーバサイドのアダプタ経由で利用した。
Q6. 「源内 on Sakura」はデジタル庁の公式プロジェクトか
違う。EastCloudが社内検証のために使っている呼び名であり、デジタル庁とは関係のない非公式の検証実装である。
Q7. 源内をさくらのクラウドで動かすときの一番の壁は何か
2026年6月の検証時点では、SPAのdeep link（URL直接アクセス）への対応と、AppRunからのシークレット直接参照の2点だった。前者はAppRun上のゲートウェイで解決し、後者は検証限定の暫定運用で回避した。
