はじめに

GMOコネクトの永田です。

「政府OSSの源内（genai-web）は堅牢そう。ただ社内ポリシー上、LLM推論をクラウドに通すのは避けたい」というニッチな相談を受けました。

genai-web本体は無改修のまま、ExAppプラグインモデルで社内DGX Sparkに推論だけ逃がす構成に落としどころを見つけたので、その記録です。Bedrock経由で十分な組織が大半ですが、本記事は「LLMプロバイダ委託だけは切り離したい」少数派向けです。

先にまとめ

genai-web本体は無改修。ExAppプラグイン仕様に従い、外部AIアプリとして社内LLMを登録
Bedrock Guardrails圏外を Microsoft Presidio + 自前 Vault で補完
既存 WireGuard 資産を流用（前回記事の続編）
社内利用は数名程度の規模感で月次運用中

第1部: genai-webのセキュリティ設計を読み解く

genai-webは2026年4月にデジタル庁がOSS化した政府向け生成AI基盤で、AWS社製のGenU（Generative AI Use Cases）をベースに堅牢化と機能追加を加えたものです。CDKで一通りの構成がコード化されており、設計を読むと「政府レベルのセキュリティ要件をAWS上でどう組むか」の実例として参考になります。

1.1 強みは2軸で整理できる

リポジトリを読み込んで、セキュリティ関連の主要な強み10個を「一般Web共通かLLM特化か」「AWSサービス機能かアプリ独自実装か」の2軸で分類しました。

	一般 Web サービス共通	LLM 利用サービスならでは
AWS サービス機能	CMEK + 暗号消去（KMS） VPC隔離 + VPC Endpoints WAF + CloudFront + Geo制限 DynamoDB PITR + TTL + CMEK	―
AWS 機能 + 設定判断	Cognito 脅威検出FULL + SAML + IP DENY 監査ログ別アカウント日次転送 ※	Bedrock Guardrails の日本向けチューニング
アプリ独自実装	―	マルチテナント ExApp プラグインモデル Cross-account Bedrock
IaC 運用パターン	cdk-nag 抑制理由の明示化	―

※ 監査ログ転送は DDB Export + EventBridge + Cross-account sts:AssumeRole という AWS 機能の組み合わせで、Lambda コード自体は API を叩くだけの薄い接着剤レベル。

整理してみて見えてきたのは、強みの大半はAWSサービス機能の組み合わせ + 設定判断であり、「アプリ独自実装」と呼べる強みの中で一般Web共通の項目はゼロという構造でした。アプリ独自実装は LLM 特化の領域（ExApp プラグイン / Cross-account Bedrock）に集中しており、ここが genai-web の真の独自価値、と読み替えることができます。

1.2 一般Webサービス共通の対策（AWSサービス機能で完結）

第1部の主役ではないので表で要点だけ。各項目はAWSの推奨パターンそのものです。

項目	実装の要点	参考
CMEK + 暗号消去	DDB / S3 / Logs / SNS / SQS / Cognito を同一CMK で暗号化、削除で復元不可	Well-Architected SEC08-BP02 Enforce encryption at rest
VPC + VPC Endpoints	Private subnet + NAT egress only、DDB/Secrets Manager は AWSバックボーン経由	Well-Architected SEC 5: How do you protect your network resources?
WAF + CloudFront + Geo	IPv4/v6/国コードの AND条件、ログ1年保持KMS暗号化	AWS Prescriptive Guidance: Restrict access based on IP address or geolocation by using AWS WAF
Cognito + SAML + IP DENY	SAML有効時セルフサインアップ自動無効化、`NotIpAddress` でDENY	Amazon Cognito: Advanced security with threat protection
監査ログ別アカウント転送	DDB日次エクスポート → Cross-account Lambda転送	DynamoDB Export to S3

「政府レベル」と聞くと身構えますが、要素技術はAWSの標準的な堅牢化パターンの集合です。同じ設定パターンは他のWebアプリにも横展開できます。

1.3 LLM特化の独自価値（genai-web ならではの領域）

genai-web独自の価値は次の2点に集約されます。

Bedrock Guardrails の日本向けPIIチューニング (guardrail.ts)

piiEntitiesConfig: [
  { action: 'BLOCK', type: 'AGE' },
  { action: 'BLOCK', type: 'AWS_ACCESS_KEY' },
  { action: 'BLOCK', type: 'CREDIT_DEBIT_CARD_NUMBER' },
  { action: 'BLOCK', type: 'EMAIL' },
  { action: 'BLOCK', type: 'IP_ADDRESS' },
  { action: 'BLOCK', type: 'PHONE' },
  // ...計17種、ただし NAME / DRIVER_ID / CA_* / US_* / UK_* は意図的に除外
]

NAME や DRIVER_ID は日本仕様で機能しないため誤検知抑制目的で意図的に除外、というコメントが付いています。マイナンバー・日本のパスポート等のBedrock非対応種別は別途regexで補完する設計思想ですが、現時点で genai-web OSS にはこの補完層は実装されておらず、ExApp 側で持つ前提になっています。第3部のハマり2でこの空白を埋める実装を入れます。

マルチテナント ExApp プラグインモデル

外部AIアプリをJSONスキーマ（text / select / file 等）で登録すると、genai-webが入力フォームを自動生成し、HTTP経由でAIアプリ側を呼び出します。チーム単位RBAC、Secrets Manager によるAPIキー管理、HMAC匿名化ユーザーID、202応答時のSQSポーリング等が組み込まれていて、外部AIアプリの追加・差し替えを安全に行えます。第3部で実物に乗ります。

第2部: 「LLM推論」の委託先だけを切り離す

2.1 委託先は二階建て

genai-webをAWSにデプロイすると、データを預ける委託先は2種類に分かれます。

委託先	内容
AWS（IaaS / PaaS）	Lambda 実行、DDB保存、KMS、Cognito、CloudFront 等のWeb層全体
LLM プロバイダ	Bedrock経由の Anthropic Claude / Amazon Nova / Mistral 等

契約主体・運用主体・セキュリティ評価が完全に別物で、FISC外部委託リスク管理基準でも個別に管理が想定されています（参考: FDUA生成AIガイドライン）。

2.2 Bedrockの契約は十分強い

Bedrockは AWS Service Terms により入出力が学習に使われず、通信もAWSバックボーン内で完結し、保存もゼロです。通常はここで十分です。本記事はこの先に進みたい少数派向けの内容です。

2.3 それでも切り離したい組織

実務上、次のような事情で「LLMプロバイダ委託だけは避けたい」となる組織があります。

委託先管理コスト（契約レビュー・年次評価・監査対応）を減らしたい
契約上のリスクではなく、契約外のリスクまで物理的に排除したい
既存の社内規定が「LLM as a Service 利用禁止」と書かれており、規定改定が間に合わない

ポリシーの問題なので、技術的に正しいかという議論ではなく、組織の事情として存在するケースです。

2.4 本記事のスコープ

本記事は「AWS の IaaS / PaaS 委託は許容するが、LLMプロバイダ委託だけは切り離したい」組織向けです。クラウド全停止が要件の組織は対象外です。

第3部: ローカルLLMをExAppとして繋ぐ

3.1 全体アーキテクチャ

WG serverとDGX Sparkの接続は前回記事で構築済みなので、その上にgenai-webからの呼び出し経路を載せた形です。

3.2 ExAppプラグインモデルが綺麗に効く

genai-webのExApp仕様は「HTTPSエンドポイント + APIキー + 入力フォーム定義JSON」というシンプルな契約です。

ExAppが受け持つ範囲	genai-web側で受け持つ範囲
`POST /invoke` で推論	UI生成、認証、ログ保存、課金、監査
`GET /status/{id}` で状態確認	非同期ポーリング、タイムアウト管理
自分の業務範囲のガードレール	Bedrock経由部分のGuardrails

genai-web本体には一切手を入れないため、git pullでバージョン追随できる状態を維持できます。これが今回の構成で一番大きい利点でした。

3.3 FastAPI最薄実装（VPC内 Lambda → WG server → DGX Spark）

genai-web の CDK は vpcIdForInvokeExApp コンテキストで InvokeExApp Lambda を 既存VPC に配置できる仕組みを持っています。前回記事で作った WireGuard 用 VPC をそのまま指定すれば、Lambda はインターネットを経由せずに WG server のプライベート IP へ直接到達します。

WG server 上の FastAPI（350行程度）は実質的に「プロトコル変換 + PIIガード + 非同期ジョブ管理」を兼ねた一枚仕立てのリバースプロキシです。

プロトコル変換: genai-web の ExApp 仕様（POST /invoke + 202 + status_url）↔ Ollama の OpenAI 互換 API（/v1/chat/completions）
PIIガード: ハマり2 で扱う Presidio + 自前 Vault、または regex baseline
非同期ジョブ管理: asyncio.create_task + dict ベースのジョブ状態保持
HTTPS 終端: ハマり3 で扱う自己署名 cert で 8443 を待ち受け

要点だけコードを抜粋します。

@app.post("/invoke")
async def invoke(req: InvokeRequest, x_api_key: str | None = Header(default=None, alias="x-api-key")):
    _require_api_key(x_api_key)
    request_id = str(uuid.uuid4())
    # 即座に202で返し、推論はasyncio.create_taskで裏で回す
    asyncio.create_task(_run_inference(request_id, req, x_user_id))
    return JSONResponse(
        status_code=202,
        content={"request_id": request_id, "status": "PENDING",
                 "status_url": f"/status/{request_id}"},
    )

裏側のワーカーは「入力ガードレール → Ollama呼出 → 出力ガードレール」の3段で、それぞれの段で問題が起きたら status を書き換えるだけのシンプルな構造です。プロセスを分けてマイクロサービス化する選択肢もありましたが、責務が小さく1ファイルで全体把握できる範囲に収まったため、一枚に寄せています。

ハマり1: API Gateway 29秒制限

genai-webのInvokeExApp Lambdaは API Gateway経由で呼ばれるため、29秒の統合タイムアウトを超えるとクライアント側が打ち切ります。長文推論や大きいモデルだとローカルLLMでも余裕で超えます。

genai-webのExApp仕様は元から非同期モードを想定していて、POST /invoke が 202 + status_url を返すと、genai-web側のPollExAppStatus LambdaがSQS backoffで定期的に状態取得しに来てくれます。FastAPI側はfastapi-async-job のような既製品を使わず素朴に asyncio.create_task で実装しました。シングルプロセス前提（uvicorn --workers 1）でジョブ状態をdictで持つだけです。

ハマり2: 念のためのPIIフィルタをExAppに持たせる判断

InvokeExApp Lambdaはユーザー入力をそのままExAppにforwardするだけで、Bedrock Guardrailsを経由しません。genai-webの設計上、ExApp側にガードレールを持たせる前提になっているためです。ドキュメント上は明示されておらず、ソースコメント止まりでした。各クラウドのExAppテンプレート（genai-ai-api）も実装としてはガードレールが入っていません。

ただし正直に言うと、本構成ではLLM推論がローカル DGX Spark で完結しているため、委託先管理ポリシーの観点だけで言えば PII フィルタは必須ではありません。PIIが流れる先が社内資産だけなので、社内DBに流れるのと同じ位置付けです。

それでも次の副次的な理由で薄く入れることにしました。

DynamoDB ChatLogs への PII 永続化を抑える（運用者・監査者の閲覧時の最小権限）
LLM ハルシネーションで無関係な氏名・メアドが出力に混入するケースの保険
将来 Bedrock 併用や別プラットフォーム移行時の保険

「ガードレール必須だから入れた」ではなく「念のため入れた」というスタンスです。ExApp境界のフィルタとして4ツールを比較しました。

ツール	主目的	可逆Masking	備考
Microsoft Presidio	PII検出+匿名化（汎用）	✅ encrypt operator	他3ツールが内部で利用
LLM Guard	LLM入出力スキャナ	✅ Vault パターン	内部でPresidio利用
NeMo Guardrails	会話フロー・トピック制限	✗ BLOCK中心	用途違い
Guardrails AI	LLM出力 validator	✗ 検証中心	Maskには不向き

4ツールいずれも内部でPresidioを呼んでおり、日本PII recognizer（マイナンバー / 運転免許 / 銀行口座等）はどのツールを選んでもPresidioのPattern recognizerを書く作業に帰結します。LLM Guardが機能要件にフィットし第一候補でしたが、transformers連鎖で2GB近い依存になるため、結局Presidio直接 + 自前Vaultで実装しました。Vaultは30行程度です。

@dataclass
class Vault:
    mapping: dict[str, str] = field(default_factory=dict)
    counter: dict[str, int] = field(default_factory=dict)

    def reserve(self, entity_type: str, original: str) -> str:
        self.counter[entity_type] = self.counter.get(entity_type, 0) + 1
        placeholder = f"[{entity_type}_{self.counter[entity_type]}]"
        self.mapping[placeholder] = original
        return placeholder

    def restore(self, text: str) -> str:
        out = text
        for placeholder in sorted(self.mapping.keys(), key=lambda s: -len(s)):
            out = out.replace(placeholder, self.mapping[placeholder])
        return out

実装中に踏んだPython正規表現の罠も書いておきます。\b は Unicode mode でひらがな・カタカナ・漢字も「word char」扱いになるため、連絡先は090-1234-5678です のような日本語直接隣接ケースでJP_PHONE推定が発火しません。(?<!\d)...(?!\d) のlookaroundに置き換えて解決しました。

ハマり3: 自己署名cert + Lambda Node.js TLS

genai-webのExApp登録UIは https:// 必須で、http:// は弾かれます。社内向け検証段階でACM管理の正規証明書を出すのも面倒だったので、自己署名証明書 + uvicornのTLS終端で対応しました。

ただしLambda Node.jsはデフォルトで自己署名を拒否するので、Lambda環境変数に NODE_TLS_REJECT_UNAUTHORIZED=0 を投入する必要があります。CDKデプロイのたびにドリフトで戻るので、post-deploy-tls-bypass.sh というスクリプトでLambda環境変数のpatchを毎回当て直す運用にしました。本番化するならACM正規cert + Route53が筋ですが、検証段階としてはこれで十分としました。

第4部: 結果と考察

4.1 ローカルLLM呼び出し化まとめ

観点	Bedrockのみ	ローカルLLM統合後
LLM推論データの経路	AWSバックボーン内で完結	社内 WireGuard tunnel 内で完結
LLMプロバイダへの委託	あり（契約で管理）	なし（経路上に存在せず）
Bedrock Guardrails	適用	圏外 → Presidio + 自前 Vault で補完
genai-web本体のセキュリティ	全機能維持	同左

4.2 トレードオフ

運用負荷増: WG server + DGX Spark の死活監視、モデル更新作業が自社管理に
フェイルオーバーなし: DGX Spark が落ちたら停止
最新モデル追随の遅れ: Bedrock側の新モデル即時反映は享受できない
ガードレールの自前管理: regex / Presidio Pattern を自分で更新する必要がある

これらを許容できる組織だけが選ぶ構成です。

4.3 結語

genai-webの設計を読み解いた限り、Bedrock経由で運用しても十分堅牢で、多くの組織はそのままで足ります。ただ「Web層は政府レベルOSSの堅牢性をそのまま借りつつ、LLM推論層だけ自社内に閉じる」という分岐が、ExAppプラグインモデルのおかげで本体無改修で実現できる、というのは想像以上に綺麗な設計でした。

委託先管理ポリシー上「LLMプロバイダ委託だけは避けたい」少数派の組織にとっては、現実的な選択肢になりうる構成だと思います。

まとめ

genai-webのセキュリティ設計の半分はAWSサービス機能の組み合わせで、AWS Best Practiceの集合体としても参考になる
LLM特化の独自価値は「日本向けGuardrails設定」と「ExAppプラグインモデル」の2点
ExAppプラグインを使えば本体無改修のままLLM推論層だけクローズドにできる
Bedrock Guardrails圏外はPresidio + 自前Vaultで念のため補完（ローカルLLMだけなら必須ではないが副次理由で薄く入れた）
Bedrockで足りる組織はそれが最適。本記事はあくまでニッチな委託先管理要件向け

最後に、GMOコネクトではサービス開発支援や技術支援をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。

お問合せ：https://gmo-connect.jp/contactus/