源内AIのコードをGitHubから読む——genai-webとgenai-ai-apiのAWS構成

「GitHubを開いたら、ファイルが多すぎてどこから読めばいいか分からなかった」

源内（GENAI）のリポジトリに初めて触れると、こう感じる方は多いはずです。packages/ 配下のディレクトリ構成、複数の CDK スタック、Python と TypeScript が混在するコード。README に「GenU ベース」と書いてあるだけでは、実際に何がどう動くのか掴みにくい。

この記事では、genai-web と genai-ai-api の 2 つのリポジトリを順番に読み解き、「CDK deploy で何が立ち上がるか」「GenU から何を追加したか」「民間向けに最初に触るべきファイルはどこか」を整理します。

関連記事 源内AIとは何か——インフラエンジニアがデジタル庁OSSでサービスを作ることにした理由 コスト概算・全体像の概要はこちらを先にどうぞ。

この記事でわかること

• genai-web と genai-ai-api の役割分担と接続方法
• packages/web（React フロントエンド）と packages/cdk（インフラ定義）の構成
• CDK deploy で立ち上がる AWS サービスの全体像（Mermaid 図）
• GenU から源内が追加した 3 つの機能（チーム管理 / ExApp / SAML 複数IdP認証）
• genai-ai-api の Bedrock + OpenSearch Serverless RAG 設計
• 民間向けにカスタマイズするとき「最初に触るべき箇所」

2 リポジトリの役割分担（「インターフェース」と「AI 処理」を分けた理由）

源内は 2 つの GitHub リポジトリで構成されています。

digital-go-jp/genai-web      → AIインターフェース（フロントエンド + バックエンド）
digital-go-jp/genai-ai-api   → AIアプリ・RAGのAPI層

この分割には明確な設計意図があります。genai-web は「誰でも使えるポータル」であり、genai-ai-api は「AI アプリの実体」です。RAG テンプレートの追加・差し替えを genai-web に影響を与えずに行える構成になっています。

2 つの接続ポイントは ExApp（外部 AI アプリ連携） という仕組みです。genai-web が inputs/outputs 形式の JSON API で genai-ai-api を呼び出す設計で、「genai-web がポータル、genai-ai-api が機能提供者」という関係で動作します。ExApp の詳細は後のセクションで改めて解説します。

genai-web のディレクトリ構成（packages/ を中心に読む）

genai-web リポジトリの核心は packages/ ディレクトリです。

genai-web/
└── packages/
    ├── web/     → React フロントエンド
    ├── cdk/     → AWS CDK インフラ定義
    │   ├── bin/           → CDK エントリポイント（スタック起動順を定義）
    │   ├── lambda/        → Lambda 関数（API ロジック）
    │   │   ├── repository/    → DynamoDB へのアクセス処理
    │   │   └── *.ts           → 各エンドポイントの実装
    │   └── lib/
    │       ├── construct/     → 再利用可能な CDK Construct
    │       └── *-stack.ts     → CDK スタック定義
    ├── common/  → フロントとバックエンドで共有するユーティリティ
    └── types/   → 共有型定義

packages/web（React フロントエンド）

TypeScript 製の React アプリです。React + Tailwind CSS + Zustand（状態管理）で構成されており、GenU のフロントエンドをベースに源内固有の UI が追加されています。チーム選択画面・ExApp 一覧・SAML 認証フローなど、GenU にはない画面がここに実装されています。

packages/cdk（AWS CDK インフラ）

インフラ定義はすべてここに集約されています。lib/ 配下の *-stack.ts がスタックの定義ファイルです。スタックの起動順序は bin/ 配下のエントリポイントで管理されており、CloudFront 用 WAF スタック（us-east-1 固定）・メインの API スタック・チーム管理スタックなど複数のスタックが連携して動作します。

lib/ 配下のスタック一覧を確認するだけで、どの AWS リソースが立ち上がるか大まかに把握できます。コードを全部読まなくても、スタック名で構成が分かる命名になっているのは助かります。

CDK deploy で立ち上がる AWS サービスの全体像

cdk deploy を実行すると、以下のリソースが自動的に構築されます。

WAF は IP アドレス制限または地理的制限を設定した場合のみデプロイされます。Web ACL は 2 つ構成で、CloudFront 用（us-east-1 固定）と Regional 用（ap-northeast-1）に分かれます。Regional Web ACL 1 つが API Gateway・Cognito User Pool・チーム管理 API の 3 リソースをまとめて保護する設計です。

CloudFront 用 WAF が us-east-1 固定である以上、CDK bootstrap は東京（ap-northeast-1）と us-east-1 の両リージョンで実行しておく必要があります。（これを知らずに cdk deploy を走らせると、デプロイ途中でスタックが止まるので要注意）

IP 制限・地理的制限を有効にした構成では、Web ACL 2 つで $10/月（$5/月 × 2）のベースコストが発生します。コスト実数の詳細は gennai-ai-intro 記事 に記載しています。

DynamoDB には会話履歴・チーム管理情報・ExApp の登録情報・ExApp 呼び出し履歴の 4 種類のデータが格納されます。packages/cdk/lambda/repository/ 配下の TypeScript ファイルが各テーブルへのアクセスを担っており、DynamoDB の構造を把握したいときはここを読むのが一番早いです。

GenU から何を追加したか（源内固有の 3 機能）

genai-web は AWS が公開している OSS「Generative AI Use Cases（GenU）」をベースに開発されています。源内が GenU に追加した機能は以下の 3 つです。

チーム管理機能（ASL 対象の 17 ファイル）

組織単位でアクセス制御できる機能です。チームごとに利用できる AI アプリや会話履歴を分離でき、大人数での共同利用を想定した設計になっています。

この機能を担う Lambda 関数（createTeam / deleteTeam / listTeams 等）と CDK Construct には、Amazon Software License（ASL）が適用される 17 ファイルが含まれています。ASL には「AWS サービス上でのみ使用できる」という制約があります。AWS 上にデプロイする限りこの制約は実質的に問題になりませんが、Azure や GCP に移植する場合はこれらを独自実装に差し替える必要があります。

ASL 対象ファイルのリストは genai-web リポジトリの docs/ASL対象ファイル.md に明記されています。

ExApp（外部 AI アプリ連携）の仕組み

genai-web をポータル化する核心機能です。inputs/outputs 形式の JSON API を定義するだけで、外部の AI アプリを源内のポータルから呼び出せるようになります。

ExApp の連携フロー:
1. 管理画面で ExApp を登録（名前・API エンドポイント・inputs/outputs スキーマ）
2. ユーザーが ExApp を選択してリクエストを送信
3. genai-web が登録済み API に JSON リクエストを転送
4. レスポンスを genai-web のチャット UI で受け取る

genai-ai-api との接続もこの仕組みを使います。「Bedrock RAG アプリ」「文書要約アプリ」などを ExApp として登録し、genai-web から呼び出す構成です。AI アプリを独立して開発・デプロイしながら、ユーザー向けインターフェースは genai-web に集約できる点が、この設計の最大のメリットです。（マイクロサービスっぽい思想で、個人的には好きな設計です）

SAML 複数IdP認証（政府向け要件）

プライマリ IdP と追加 IdP を、アクセスする URL パス（サインインパス）によって切り替える仕組みを実装しています。政府システムで要求される「組織・グループごとに異なる IdP でログインさせたい」という要件に対応した仕様です。

民間向けに使う場合、大半の組織ではここまでの認証複雑度は不要です。Cognito User Pool のメールアドレス + パスワード認証に差し替えるか、既存の SAML 対応 IdP（Microsoft Entra ID / Okta 等）との 1 段階接続に簡略化できます。

関連記事 源内AIとは何か——インフラエンジニアがデジタル庁OSSでサービスを作ることにした理由 源内の向き不向き・コスト・東京リージョン推奨の理由はこちらを参照してください。

genai-ai-api の AWS 構成（Bedrock + OpenSearch Serverless RAG）

genai-ai-api は Python 製の API 層で、3 クラウド対応のテンプレートが含まれています。

genai-ai-api/
├── aws/
│   └── query-expansion-rag/    → Bedrock + OpenSearch Serverless RAG（CDK プロジェクト）
├── azure/                      → Azure 向けテンプレート
└── google-cloud/               → GCP 向けテンプレート

多くの AWS ユーザーが使うのは aws/ ディレクトリのみです。Azure / GCP 向けテンプレートも同リポジトリに含まれていますが、読み飛ばして構いません。

Bedrock Knowledge Base + OpenSearch Serverless の構成

RAG の中核は Amazon Bedrock Knowledge Base です。S3 に格納したドキュメントを Bedrock Knowledge Base でインデックス化し、OpenSearch Serverless をベクトル検索のバックエンドとして使用します。

RAG のクエリフロー:
1. クエリ拡張：ユーザーの質問を Bedrock で複数クエリに展開（デフォルト 3 件）
2. KB 検索 + 関連性評価：各クエリで Knowledge Base を並列検索し、LLM で関連性スコアリング
3. 回答生成：評価済み検索結果をコンテキストとして Bedrock（Claude 等）に渡して回答を生成
4. 出典生成：引用セクション（reference）を付与して genai-web に返す

aws/query-expansion-rag/lib/constructs/rag-lambda/invokeModel/ 配下の Python Lambda 関数がこのフロー全体をオーケストレーションします。ベクトル化は Bedrock Knowledge Base 内部が自動処理するため、Lambda が担うのはクエリ拡張・関連性評価・回答生成・出典生成の 4 ステップです。各モジュール（core/query_expansion.py / kb_retrieve_and_rating.py / answer_generation.py / reference_generation.py）が分離されており、独自のプロンプトや前処理を挟むカスタマイズポイントになっています。

コストと拡張ポイント

OpenSearch Serverless の費用が最大のコスト要因です。インデックス用・検索用それぞれ最低 1 OCU 必要で、最小構成でも月額 $174〜$350 程度かかります。RAG を有効にする場合は、この費用を予算に事前に含めておく必要があります。

なお genai-ai-api には rag-s3vectors-kb-stack.ts という S3 Vectors 版の KB スタックも同梱されています。Bedrock Knowledge Base のバックエンドを S3 Vectors に差し替えることで、OpenSearch Serverless の固定費を大幅に削減できます。PoC 段階やコストを抑えたい構成では、こちらを選ぶ選択肢があります。

社内ドキュメントを RAG の検索対象に追加するには、S3 バケットに PDF や Markdown ファイルをアップロードして Bedrock Knowledge Base の同期を実行するだけです。インデックス化のパイプラインは genai-ai-api 側で完結しており、genai-web の改修は不要です。（思っていたより拡張が楽で、最初は少し拍子抜けするかもしれません）

民間向けにカスタマイズするとき「最初に触るファイル」

実際に民間向けに改修する際に考えられる具体的な一例と場所を整理します。

1. SAML 複数IdP認証を Cognito 標準認証に差し替える

対象は packages/cdk/lib/construct/auth.ts（認証 Construct）です。プライマリ IdP の設定を Cognito User Pool のデフォルト認証に変更し、追加 IdP の設定を無効化することで、シンプルな Cognito 認証に切り替えられます。

Microsoft Entra ID や Okta を使う組織は、SAML フェデレーションを 1 段階の IdP 接続に書き換える形で対応できます。Cognito は SAML フェデレーションをサポートしているため、Lambda のロジック変更なしに設定変更のみで動作します。

2. WAF 構成の見直し

packages/cdk/lib/construct/common-web-acl.ts が WAF の実体です。このWAFは IP アドレス許可リスト + 国制限 の実装で、デフォルトアクションは「ブロック」です。許可したIPレンジまたは国コードを設定することで、その範囲以外からのアクセスを遮断します。AWS Managed Rules は使用していません。

WAF は allowedIpV4AddressRanges / allowedIpV6AddressRanges / allowedCountryCodes のいずれかを設定したときのみデプロイされます。IP・国制限が不要であれば、これらのパラメータを設定しないことで WAF 自体をデプロイしない構成にできます。有効にした場合の固定費は $5/月 × 2 Web ACL = $10/月です。

3. genai-ai-api に独自 RAG テンプレートを追加する

aws/query-expansion-rag/ の CDK プロジェクトに新しいスタックを追加し、ExApp として genai-web に登録するのが最もシンプルな拡張方法です。既存の RAG テンプレートを参考に、独自のプロンプトや検索ロジックを実装できます。genai-web 側の改修は ExApp の登録操作のみで完結します。

まとめ

genai-web はフロントエンド（packages/web）とインフラ定義（packages/cdk）を packages/ 配下で一元管理する TypeScript プロジェクトです。CDK deploy で CloudFront・Cognito・API Gateway・Lambda・DynamoDB が立ち上がり、IP 制限設定時は WAF（2 Web ACL）が加わります。genai-ai-api の Bedrock + OpenSearch Serverless RAG と ExApp 経由で接続される構成です。

GenU からの追加機能はチーム管理・ExApp 連携・SAML 複数IdP認証の 3 つです。民間向けにカスタマイズする場合、SAML 認証の簡略化・WAF ルールの見直し・独自 RAG テンプレートの追加が主な改造ポイントになります。

まずは GitHub の genai-web/packages/cdk/lib/ を開いて *-stack.ts ファイルの一覧を確認するところから始めてみてください。スタック名を見るだけで、どの AWS リソースが立ち上がるか大まかに把握できます。実際のデプロイ記録・コスト実測・構成カスタマイズの続きは源内 AI シリーズで随時公開中です。

参考文献

• GitHub: digital-go-jp/genai-web — 源内 Web の公式リポジトリ（CDK スタック・Lambda 実装を直接確認）
• GitHub: digital-go-jp/genai-ai-api — 源内 AI アプリ・RAG API の公式リポジトリ
• デジタル庁のガバメントAI「源内（GENAI）」がOSS化されたので、GenUとの差分を調べながらAWSアカウントにデプロイしてみた（Classmethod DevelopersIO） — GenU との差分・技術スタックの詳細
• Digital Agency GenAI の ExApp 機能を調べてみた（Classmethod DevelopersIO） — ExApp 連携の仕組みと操作方法
• デジタル庁「ガバメントAI『源内』をOSSとして公開します」 — OSS 公開の公式発表（2026年4月24日）