( 姉妹本:源内Webアプリのソースコードを理解してみようのご紹介はこちら )

政府の AI ソースコードを読み解く本を書きました

「政府が使っている AI のソースコードが公開されている」

この事実を知ったとき、あなたはどう感じましたか？

私は正直、最初は半信半疑でした。「サンプルコードっぽいものが置いてあるだけでしょ」と。でも、デジタル庁が公開している「源内（GenAI）」リポジトリを実際に開いてみて、考えが変わりました。

これは本物だ。

AWS CDK のスタック設計、Python Lambda の RAG パイプライン、Azure の vLLM セルフデプロイ設定、BigQuery ML を使った法令検索 AI——省庁職員が実際に使っているシステムのコードが、MIT ライセンスで GitHub に置いてある。しかも、実務の判断の痕跡がコードのあちこちに残っている。

このリポジトリを読み解く本を書きました。

「公開されている」と「理解できる」は別の話

ソースコードは誰でも読めます。でも「読める」と「理解できる」は違います。

たとえば、AWS 版の RAG パイプライン。コードを追えば「クエリ拡張して Knowledge Base に投げて回答を生成している」ことはわかります。でも、こういった問いにはすぐ答えられないはずです。

なぜ ConfigManager は 3 層構造になっているのか
なぜ KB 検索の結果を threading.Thread で並列処理しているのか
なぜ invoke_converse_with_system という関数があるのに、どの core モジュールもそれを呼んでいないのか
sanitize_filename() がなぜ拡張子のドットまでハイフンに変換するのか

コードには、書かれていない文脈があります。「なぜこの設計なのか」「この設定値の意味は何か」「どんな問題へのトレードオフなのか」——本書はそこに答えようとしました。

本書が扱う 3 つの AI アプリ

AWS：クエリ拡張 RAG

ユーザーの質問を LLM で複数のクエリに展開し、Bedrock Knowledge Base と OpenSearch Serverless を組み合わせて幅広く検索する RAG システムです。

構成は TypeScript（CDK）と Python（Lambda）の 2 層。CDK スタックは 4 つに分割されており、アプリ名をプレフィックスにするだけで複数インスタンスを並行デプロイできる設計になっています。

RAG パイプラインは 4 ステップで構成されています。

① クエリ拡張     — ユーザーの質問を n 個の検索クエリに展開
② KB 検索 + 関連性評価  — 複数クエリを並列で KB に投げ、LLM でスコアリング
③ 回答生成      — 上位 k 件のコンテキストを使って最終回答を生成
④ 参考情報生成   — 出典情報を Markdown 形式で整形

単純な RAG との違いは②にあります。「1 クエリで検索して上位 k 件を使う」のではなく、「複数クエリで検索して関連度スコアで絞り込む」ことで、単一クエリでは拾えなかった関連文書を回収できる。この設計がなぜ必要なのかは、コードを読むだけではなかなか見えてこない部分です。

Azure：vLLM セルフデプロイテンプレート

Hugging Face のモデルを Azure の GPU 仮想マシンで動かし、APIM（API Management）経由で API として提供するテンプレートです。実装例には PLaMo 翻訳モデルが使われています。

興味深いのは、vLLM ベースのセルフホストモデルと Azure OpenAI Service の両方を、同一の APIM エンドポイントから利用できる設計になっている点です。モデルを差し替えても呼び出し元のコードを変えなくていい。

Google Cloud：法令検索 AI

「法令 × デジタル」ハッカソンの最優秀賞「Lawsy」に触発されて開発されたシステムです。e-Gov 法令検索のデータを BigQuery ML でベクトル化し、Gemini と組み合わせて法令 Q&A を行います。

質問の意図を解析して 6 パターンのレポートから最適な構造を自動選択する点が特徴的です。3 段階フォールバック、バイグラム類似度による法令名の整合性チェック、Mermaid のサニタイズ処理など、実運用を経た判断がコードに刻まれています。

書いていて「よくできているな」と感じた箇所

あとがきにも書いたのですが、コードを読んでいて「なるほど、こう解決するのか」と感じた場面がいくつかありました。

TOML の 2 層設定管理は特に印象的でした。デフォルト設定ファイルとアプリ個別設定ファイルが分かれており、アプリ個別設定はデフォルトの差分だけ書けばいい。同じ Lambda コードをデプロイしながら、TOML の差し替えだけで用途の異なる複数のアプリを運用できる。

KMS キーの管理方式も面白い。個別 CMEK・共通 CMEK・S3 Vectors の 3 通りから選択でき、データ削除戦略とコスト最適化のトレードオフが設定で切り替えられる設計です。

一方で「まだ発展していきそうだ」と感じる箇所も正直あります。Azure Automation の Runbook がデプロイ後に手動設定が必要だったり、テストが AWS サブプロジェクトに集中していたり。でもそれもまた、実際に動いているシステムのリアルな姿です。完璧なシステムより、動いているシステムの方が、学べることが多い。

対象読者

本書は実務経験 3〜5 年のソフトウェアエンジニアを想定しています。AWS CDK・Python Lambda・Azure Bicep・Google Cloud Terraform のいずれかに触れたことがあれば、読み始められます。

生成 AI の利用経験は問いません。本書は「生成 AI の使い方」ではなく、「生成 AI を活用したシステムを設計・構築・デプロイするための実装パターン」を扱う本です。

本書で伝えたかったこと

「コードの説明」ではなく「コードを読む力」を伝えることを意識して書きました。

本書を読んだ後、他のリポジトリを開いたときにも「なぜこの設計なのか」という問いを立てられるようになっていれば、目的は達成されています。

デジタル庁が源内リポジトリを公開した事実には、大きな意味があると思っています。行政システムがブラックボックスではなく、誰でも読めるオープンソースとして存在する。日本のソフトウェアエンジニアへの、ひとつの贈り物だと感じています。

このコードを読み、自身のプロジェクトに応用し、さらに良い形でコントリビューションする——そういうサイクルが生まれることを願いながら書きました。

リポジトリ情報

本書は https://github.com/digital-go-jp/genai-ai-api の v1.0.3 タグを元に記述しています。リポジトリ自体は MIT ライセンスで公開されており、誰でも読むことができます。

本書は、そのコードを読む「地図」として使ってもらえれば嬉しいです。