【Epic】LLM 基盤を Vercel AI Gateway から AWS Bedrock（日本リージョン）へ移行し、実行基盤を AWS に統一する

[yu23ki14]

LLM の実行基盤を Vercel AI Gateway から AWS Bedrock（日本国内リージョン） へ移行し、観測は Langfuse Cloud で継続する。併せて、トピック分析 worker の実行基盤を Google Cloud Run Job から AWS ECS Fargate + EventBridge Scheduler へ移す。

PR #26（VercelOidcStack）で Vercel → Bedrock の IAM ロールは用意済みだが、アプリ側は 1 行も Bedrock を向いていない。本 Epic はそのアプリ側移行と、それに伴うインフラ・観測・運用の変更を扱う。

前提

本サービスはローンチ前であり、Bedrock 移行の完了後に稼働を開始する。 稼働中のトラフィックも利用者データも無い。したがって本 Epic では次の方針を取る。

• Vercel AI Gateway との併存や段階移行は行わない。 アプリ全体を1プロバイダに固定する段階移行フラグ（LLM_PROVIDER 等）は設けず、一気に置き換えて AI_GATEWAY_API_KEY を撤去する。
  • 撤去するのは Gateway（ルーティングサービス） であり、OpenAI / Google へのアクセスではない。テスト環境では引き続き ChatGPT / Gemini を使える。ただし Gateway 経由ではなく各プロバイダを直接叩く形になり、OPENAI_API_KEY / GOOGLE_GENERATIVE_AI_API_KEY が新たに必要になる（【基盤】AI SDK に provider registry を導入し、論理モデルID＋プロバイダ許可リストで本番を Bedrock 固定にする #42）。
  • 使えるプロバイダの制御は AI_ALLOWED_PROVIDERS（許可リスト）が担う。本番は bedrock のみ、テスト環境は bedrock,openai,google。
• 移行前後の性能・品質の比較は行わない。 【検証】構造化出力15箇所の Bedrock 適合性検証とクォータ確認 #47 の検証は Bedrock 単独での絶対水準の合否判定として実施し、合格ラインを測定前に決める。結果はローンチ可否の判断材料になる。
• 後方互換の維持もデータ移行も不要。 全環境が新規構築であり、旧形式のモデルIDが DB に入っていることはない（interview_config.chat_model は DEFAULT NULL で seed も設定していない）。

決定済みの方針

論点	決定
リージョン	日本国内限定（単一リージョンである必要はない）。Claude は jp. CRIS（東京+大阪）、gpt-oss は東京 In-Region。global.* は IAM で明示 Deny
モデル	Claude Sonnet 4.6 / Claude Haiku 4.5 / gpt-oss-120b。Nova は採用しない（Pro は東京未提供、Lite は max output 5K + 構造化出力非対応）
プロバイダ	本番は Bedrock 固定。テスト環境では OpenAI / Gemini 直も許可（許可リストで制御）
web_search	廃止（Bedrock 経由の Claude は非対応）
worker 実行基盤	EventBridge Scheduler + ECS Fargate（確定。Vercel Cron は採用しない。理由は下記 ADR コメント参照）
Guardrail	適用する。streamProcessingMode は sync / async を環境変数で切替可能にする（既定 sync）。実測してから運用で判断する
コスト検証	推定値のみになるため、AWS Cost Explorer の実請求額との月次突合を運用に入れる
GCP	実装は残置（切り戻し用）。Cloud Scheduler は移行完了後に停止

方針の背景・代替案・トレードオフは本 Issue のコメントに ADR ドラフトとして記載している。実装着手前に ADR を確定させる。

子Issue

フェーズ0: 前処理（他Issueの対象範囲を減らす）

• 【整理】旧 Vercel フェーズ連鎖版トピック分析（api/topic-analysis/phases）を削除する #51 【整理】旧 Vercel フェーズ連鎖版トピック分析（api/topic-analysis/phases）を削除する
• 【観測】Langfuse を JS SDK v5（@langfuse/otel）へ移行し forceFlush でトレース欠落を防ぐ #41 【観測】Langfuse を JS SDK v5（@langfuse/otel）へ移行し forceFlush でトレース欠落を防ぐ
• 【適用】公開チャットの web_search ツールを廃止する #44 【適用】公開チャットの web_search ツールを廃止する

フェーズ1: Bedrock 基盤

• 【インフラ】Bedrock IAM ポリシーを日本CRIS（jp.）対応にし global.* を明示 Deny する #45 【インフラ】Bedrock IAM ポリシーを日本CRIS（jp.）対応にし global.* を明示 Deny する
• 【基盤】AI SDK に provider registry を導入し、論理モデルID＋プロバイダ許可リストで本番を Bedrock 固定にする #42 【基盤】AI SDK に provider registry を導入し、論理モデルID＋プロバイダ許可リストで本番を Bedrock 固定にする ← 本 Epic の中核
• 【適用】モデルカタログ・コスト表・UI選択肢を Bedrock（日本リージョン）へ再定義する #43 【適用】モデルカタログ・コスト表・UI選択肢を Bedrock（日本リージョン）へ再定義する

フェーズ2: 実行基盤の AWS 化

• 【インフラ】トピック分析 worker の実行基盤を Cloud Run Job から ECS Fargate + EventBridge Scheduler へ移行する #48 【インフラ】トピック分析 worker の実行基盤を Cloud Run Job から ECS Fargate + EventBridge Scheduler へ移行する
• 【インフラ】admin の実行トリガを ecs:RunTask に切り替え、Vercel から GCP_SA_KEY を廃止する #49 【インフラ】admin の実行トリガを ecs:RunTask に切り替え、Vercel から GCP_SA_KEY を廃止する

フェーズ3: 品質・運用

• 【適用】Bedrock Guardrails をアプリの LLM 呼び出し経路に接続する #46 【適用】Bedrock Guardrails をアプリの LLM 呼び出し経路に接続する
• 【検証】構造化出力15箇所の Bedrock 適合性検証とクォータ確認 #47 【検証】構造化出力15箇所の Bedrock 適合性検証とクォータ確認
• 【運用】Langfuse Cloud に Bedrock 用カスタムモデル定義（価格）を登録する #50 【運用】Langfuse Cloud に Bedrock 用カスタムモデル定義（価格）を登録する

依存関係と進め方

#51 ─┐
#41 ─┼─→ #45 ─→ #42 ─→ #43 ─→ #47
#44 ─┘          │
                └─→ #46
#48 ─→ #49
#43 ─→ #50

• 【整理】旧 Vercel フェーズ連鎖版トピック分析（api/topic-analysis/phases）を削除する #51 → 【基盤】AI SDK に provider registry を導入し、論理モデルID＋プロバイダ許可リストで本番を Bedrock 固定にする #42/【適用】モデルカタログ・コスト表・UI選択肢を Bedrock（日本リージョン）へ再定義する #43 の順序が重要: 旧フェーズ連鎖版を先に消すと、プロバイダ書き換えとモデルカタログ差し替えの対象が 5 ファイル分減る。
• 【観測】Langfuse を JS SDK v5（@langfuse/otel）へ移行し forceFlush でトレース欠落を防ぐ #41 は最初に: 以降の Issue のデバッグに観測基盤が必要になる。現行実装は forceFlush() を呼んでいないためストリーミングのトレースを取りこぼしている可能性があり、この状態で Bedrock を調査すると「Bedrock が失敗した」のか「トレースが記録されなかっただけ」なのかを切り分けられない。Bedrock と独立していて小さいので先に片付ける。
• 【インフラ】Bedrock IAM ポリシーを日本CRIS（jp.）対応にし global.* を明示 Deny する #45 は 【基盤】AI SDK に provider registry を導入し、論理モデルID＋プロバイダ許可リストで本番を Bedrock 固定にする #42 より先に: IAM が jp. に対応していないと 【基盤】AI SDK に provider registry を導入し、論理モデルID＋プロバイダ許可リストで本番を Bedrock 固定にする #42 の疎通確認ができない（現状 arn:aws:bedrock:ap-northeast-1::foundation-model/* のみで、大阪の foundation-model が許可されていない）。
• 【インフラ】トピック分析 worker の実行基盤を Cloud Run Job から ECS Fargate + EventBridge Scheduler へ移行する #48 / 【インフラ】admin の実行トリガを ecs:RunTask に切り替え、Vercel から GCP_SA_KEY を廃止する #49 は対で完成する。【インフラ】トピック分析 worker の実行基盤を Cloud Run Job から ECS Fargate + EventBridge Scheduler へ移行する #48 だけマージすると手動トリガが Cloud Run を向いたままになる。
• 【検証】構造化出力15箇所の Bedrock 適合性検証とクォータ確認 #47 は 【適用】モデルカタログ・コスト表・UI選択肢を Bedrock（日本リージョン）へ再定義する #43 の後。全モデル確定後でないと意味のある検証にならない。

最優先で着手すべきもの

#49 はセキュリティ改善として独立した価値がある。 現状 admin は 長期の GCP サービスアカウント鍵（GCP_SA_KEY、JSON 丸ごと）を Vercel の環境変数に保持している。ECS 移行によりこれを完全に廃止し、PR #26 の OIDC ロールに一本化できる。

ローンチ前に確認すること

Cloud Scheduler（毎朝 6:00 JST の --mode=analyze-all）と EventBridge Scheduler のどちらか一方だけが有効な状態にする。 現行の Cloud Scheduler は infra/cloud-run/provision.sh が作成しており、SCHEDULER_PAUSED=1 で停止できる。どの環境で有効になっているかを #48 の着手時に確認し、ローンチ前に片方に寄せる。

前提となる運用作業（コード外）

• Bedrock コンソールで対象モデル（Anthropic / OpenAI）のアクセス申請（dev / prd 両アカウント）
• Service Quotas で TPM / RPM を確認、必要なら引き上げ申請（リードタイムがあるため早めに）
• Vercel プロジェクト（web / admin）の環境変数設定
  • 全環境: AWS_REGION=ap-northeast-1（Vercel が自動上書きするため明示必須）、AWS_ROLE_ARN
  • production: AI_ALLOWED_PROVIDERS=bedrock
  • preview: AI_ALLOWED_PROVIDERS=bedrock,openai,google ＋ OPENAI_API_KEY ＋ GOOGLE_GENERATIVE_AI_API_KEY
• OpenAI / Google Generative AI の API キー発行（テスト環境用。従来は Vercel AI Gateway が仲介していたため未取得）
• AWS IAM に Vercel OIDC IdP の登録（カスタム audience sts.amazonaws.com を Audiences に追加）

関連

• PR feat: VercelからBedrockへOIDC Federationでアクセスするためのスタックを追加 #26（VercelOidcStack）、PR feat: AWS Bedrock Guardrailsによる有害コンテンツ検知・ブロックを追加 #28 / fix: PROMPT_ATTACKフィルタのoutputStrengthをNONEに修正 #30（Bedrock Guardrails）、VercelからAWS BedrockへOIDC Federationでセキュアにアクセスする #25（OIDC 調査）
• docs/20260609_1200_トピック分析CloudRun実行基盤設計.md
• docs/20260809_1026_AWS_Bedrock_CDK基盤_運用開始までの作業手順.md
• docs/20251007_2159_Langfuse導入設計.md

[yu23ki14]

以下は実装着手前に議論・確定させるための ADR ドラフトです。Issue 群（#41〜#51）の方針の根拠をまとめています。この内容を叩き台に議論し、確定後に docs/adr/ へ正式な ADR として起こす想定です。

---

ADR 0000: LLM 実行基盤を Vercel AI Gateway から AWS Bedrock（日本リージョン）へ移行し、バッチ実行基盤を ECS Fargate に統一する

ステータス

提案中

日付

2026-08-21

コンテキスト

佐賀市 AI 広聴基盤は、公開チャット・AI インタビュー・トピック分析・インタビューシミュレーションの各機能で LLM を利用している。現状の実装は以下の状態にある。

• LLM 呼び出しは AI SDK（ai@6.0.3）の暗黙の既定プロバイダ = Vercel AI Gateway に依存している。streamText({ model: "openai/gpt-5.2" }) のように文字列モデルIDを渡すだけで、Gateway が解決する。認証は AI_GATEWAY_API_KEY 1本。呼び出し箇所は web 4 / admin 12 / packages/topic-analysis-core 5 の計 21 ファイル。
• 観測は Langfuse Cloud（トレース + プロンプト管理）。ただし依存は v3 系（langfuse@3.38.5 / langfuse-vercel@3.38.5 の LangfuseExporter）で、Langfuse 公式ドキュメントは既に @langfuse/otel（JS SDK v5 系）に移行しており、v4 ingestion への切替期限が 2026-11-16 とアナウンスされている。
• トピック分析・意見再抽出バックフィルは Google Cloud Run Job で動いている。毎朝 6:00 JST の Cloud Scheduler と、admin UI からの手動トリガ 3 系統。admin から Cloud Run を起動するために 長期の GCP サービスアカウント鍵（JSON 丸ごと）を Vercel の環境変数に保持している。
• PR feat: VercelからBedrockへOIDC Federationでアクセスするためのスタックを追加 #26 で Vercel → AWS Bedrock の OIDC Federation ロールを CDK に追加済み。ただしアプリ側は 1 行も Bedrock を向いていない。

解決すべき課題は 3 つある。

1. データ所在の要件: 本案件は自治体（佐賀市）の広聴基盤であり、利用者から集めた意見テキストを LLM に投げる。推論を日本国内リージョンに限定する必要がある。Vercel AI Gateway はどのリージョンで推論されるかをアプリ側で保証できない。
2. 本番と検証で必要なプロバイダが異なる: 本番は Bedrock 一択だが、検証環境ではモデル比較のため OpenAI / Gemini も使いたい。「本番で誤って国外プロバイダに流れる」ことを設定ミスで起こさない仕組みが必要。
3. クラウドの分散: LLM は AWS、バッチは GCP、アプリは Vercel と 3 クラウドに分散しており、認証情報の管理点が増えている。本プロジェクトは AWS を前提とする方針が決まった。

制約:

• 本サービスはローンチ前であり、この移行の完了後に稼働を開始する。 稼働中のトラフィックも利用者データも無いため、Gateway との併存・段階移行・後方互換の維持は不要であり、移行前後の性能比較も判断材料にならない。品質は Bedrock 単独での絶対水準として評価する。
• ai@6.0.3 を使用中。ai@7 へのメジャーアップは今回のスコープ外（@ai-sdk/amazon-bedrock は 4.x 系を選ぶ必要がある）。
• Vercel Function の最大実行時間は Pro プランで 800s（GA）／1800s（beta）。現行の Cloud Run Job は 3600s を予算に取っている。
• 構造化出力（generateObject / Output.object）を 15 箇所で使用しており、プロバイダ変更が出力品質に直接影響する。

決定

1. LLM プロバイダ

AWS Bedrock を日本国内リージョン限定で使用する。

論理ID	Bedrock modelId	経路	構造化出力	max output
bedrock:claude-sonnet-4-6	jp.anthropic.claude-sonnet-4-6	JP CRIS（東京+大阪）	✓	64K
bedrock:claude-haiku-4-5	jp.anthropic.claude-haiku-4-5-20251001-v1:0	JP CRIS（東京+大阪）	✓	64K
bedrock:gpt-oss-120b	openai.gpt-oss-120b-1:0	東京 In-Region	✓	16K

• Sonnet 4.6 は東京 In-Region 非対応（Geo のみ）のため jp. プレフィックスが必須。
• gpt-oss-120b は東京 In-Region のみで Geo/Global が存在しない。単一リージョン完結なのでデータ所在は最も厳格。
• global.* は使用禁止とし、IAM の明示 Deny（aws:RequestedRegion: unspecified の StringEquals Deny）で構造的に封じる。
• 要件は「日本国内」であり単一リージョンである必要はない（2026-08-21 確定）。したがって jp. CRIS が東京・大阪の 2 リージョンにルーティングされることは許容する。可用性の観点でも CRIS の方が望ましい。

2. プロバイダ切り替えの実装方式

createProviderRegistry + 論理モデルID（"provider:modelId"）+ プロバイダ許可リスト（AI_ALLOWED_PROVIDERS） を採用する。

• 本番: AI_ALLOWED_PROVIDERS=bedrock
• プレビュー / ローカル: AI_ALLOWED_PROVIDERS=bedrock,openai,google
• DB（interview_config.chat_model）や admin UI から来たモデルIDを、解決の前に許可リストで検証して弾く。許可外はフォールバックせずエラーにする。
• Vercel AI Gateway は registry に含めず、AI_GATEWAY_API_KEY ごと撤去する。 アプリ全体を1プロバイダに固定する段階移行フラグ（LLM_PROVIDER 等）による併存期間は設けない。
• 撤去対象は Gateway（ルーティングサービス） であり、OpenAI / Google へのアクセスではない。検証環境では各プロバイダを直接叩く（OPENAI_API_KEY / GOOGLE_GENERATIVE_AI_API_KEY を新規に用意する）。プロバイダの利用可否は AI_ALLOWED_PROVIDERS が制御し、キーの有無とは独立した軸として扱う。

3. Bedrock への認証

実行環境ごとに資格情報の解決方法を分ける。

• Vercel（production / preview）: OIDC Federation（@vercel/oidc-aws-credentials-provider + PR feat: VercelからBedrockへOIDC Federationでアクセスするためのスタックを追加 #26 のロール）。静的キーを持たない。
• ECS Fargate / ローカル: 既定の credential chain（Task Role / ~/.aws）。

4. バッチ実行基盤

EventBridge Scheduler + ECS Fargate（ecs:RunTask）に移行する。Vercel Cron は採用しない。

• 定期実行: EventBridge Scheduler → ecs:RunTask（containerOverrides.command = ["--mode=analyze-all"]）
• 手動実行: admin（Vercel）→ OIDC → ecs:RunTask
• ネットワーク: パブリックサブネット + assignPublicIp: ENABLED（NAT Gateway を作らない）
• GCP 実装（infra/cloud-run/、admin/src/lib/cloud-run-job.ts）は切り戻し用に残置し、Cloud Scheduler のみ停止する。

5. 機能の縮退

公開チャットの web_search ツールを廃止する。 Bedrock 経由の Claude はサーバーサイド web search に対応していない。

6. 観測

Langfuse Cloud を継続し、SDK を JS v5 系（@langfuse/otel の LangfuseSpanProcessor）へ移行する。ストリーミング経路には after(() => forceFlush()) を追加する。Bedrock のモデルIDは Langfuse 組み込み価格表にマッチしないため、正規表現マッチのカスタムモデル定義を Langfuse Cloud 側に登録する。

7. Guardrails の適用方式

Bedrock Guardrails をアプリの LLM 呼び出し経路に接続する。ストリーミング時の検査モード（streamProcessingMode）は sync / async を環境変数で切り替えられる設計にする。

• BEDROCK_GUARDRAIL_STREAM_MODE=sync|async（既定は sync）
• コード変更・再デプロイなしに切り替えられること。両モードの挙動差（sync = チャンクごとに検査して確実にブロック／TTFB 悪化、async = 高速だが一部が利用者に到達してからブロック）を代表的な負荷で比較し、運用しながら判断できる状態にする。
• 併せて BEDROCK_GUARDRAIL_ID 未設定時は Guardrail 無効で動作継続とする（ローカル開発を止めないため）。

8. コスト計上の検証方法

Bedrock は providerMetadata に実課金額を返さないため、アプリ側のコストは推定値のみになる。正解は AWS の実請求額とし、月次で chat_usage_events の合計と AWS Cost Explorer の Bedrock 実費を突合する運用を入れる。

根拠

技術的な考慮事項

なぜ registry 方式か（globalThis.AI_SDK_DEFAULT_PROVIDER ではなく）

ai@6 は globalThis.AI_SDK_DEFAULT_PROVIDER を差し替えることで、文字列モデルIDの解決先を変更できる。呼び出し側 21 ファイルを一切触らずに済むため差分は最小になる。しかしプロバイダを混在させられないため、「本番は Bedrock、検証は OpenAI/Gemini も」という要件を満たせない。registry 方式は 21 ファイルの書き換えが必要だが機械的であり、いずれも deps?.model によるDI口を既に持っているためテスト構造への影響がない。

なぜ Gateway を一気に捨てるか（併存期間を設けないか）

ローンチ前で守るべき稼働中トラフィックが無いため、フラグによる段階移行が守るものが存在しない。併存させると registry に gateway エントリと AI_GATEWAY_API_KEY を残すことになり、「本番が Gateway を向いたままローンチする」という事故経路を自分で作ることになる。撤去して、Gateway を向く手段そのものを無くす方が安全。

なお、これは検証環境で ChatGPT / Gemini を使えなくすることを意味しない。Gateway が担っていた「複数プロバイダへの振り分け」の役割は createProviderRegistry + AI_ALLOWED_PROVIDERS が引き継ぎ、各プロバイダは直接叩く。Gateway を挟まない分、経路が短く認証も単純になる（プロバイダごとの API キーは増えるが、本番では Bedrock 以外のキーを持たない構成になる）。

なぜ許可リストを env で持つか

「本番で誤って国外プロバイダに推論を投げる」ことは、自治体案件では単なるバグではなくコンプライアンス事故になる。これをコードレビューや運用注意で防ぐのは脆い。AI_ALLOWED_PROVIDERS=bedrock を本番の環境変数に置き、解決前に検証してエラーで落とす設計にすれば、DB の値が古かろうと UI から変な値が来ようと、本番から Bedrock 以外に出る経路が存在しなくなる。フォールバックさせないのは、黙って別プロバイダに流れると事故に気づけないため。

なぜ ECS Fargate か（Vercel Cron ではなく）

これはこのリポジトリが一度 Vercel でやって捨てた設計である。docs/20260609_1200_トピック分析CloudRun実行基盤設計.md §0 が Cloud Run へ移した理由を明記している。

• 5分/呼び出しの制限: 1チャンクを5分に収める必要があり、大規模議案では分割が必須。
• ベストエフォートで耐障害性なし: 内部 fetch（自己トリガ）が失敗するとチェーンが静かに停止し、自動再開しない。
• 同時実行の制御が弱い
• 可観測性が低い（ログが複数の関数呼び出しに分散）

その実装は今もリポジトリに残っている（admin/src/app/api/topic-analysis/phases/phase{1,2,3}/route.ts、各 maxDuration = 300、trigger-next-phase.ts が自己 fetch でチェーン）。数字で見ても、Vercel Function は Pro で 800s（GA）／1800s（beta、Secure Compute 非対応）に対し、現行 Cloud Run Job は 3600s を予算に取っている。--mode=analyze-all は全議案を順次処理するため所要時間が議案数に比例し、Vercel の枠に収める保証がない。

一方 ECS Fargate は、

• worker/Dockerfile の ENTRYPOINT ["pnpm","exec","tsx","src/main.ts"] に引数が後付けされる構造が Cloud Run Job と同一で、--args → containerOverrides.command の読み替えだけでロジック変更ゼロで動く
• 実行時間の上限がない
• Task Role で Bedrock 認証が完結する（OIDC も静的キーも不要）。「Cloud Run から AWS へどう認証するか」という課題自体が消える

なぜ NAT Gateway を作らないか

worker の通信先は Supabase / Bedrock / Langfuse Cloud で、すべて公開エンドポイント。プライベートサブネット + NAT にすると月 $30〜 が常時発生するのに対し、Fargate 本体は 1vCPU/2GB を1日20分で月 $1 未満。VPC エンドポイントを整備する動機が現時点では無い。

ビジネス要件

• 自治体案件としてデータ所在（日本国内）が必須要件。jp. CRIS と東京 In-Region の組み合わせでこれを満たす。
• 検証環境でのモデル比較は、インタビュー品質の改善サイクル（admin/src/features/interview-simulation）に必要な機能であり、Bedrock 単独に絞ると失われる。許可リスト方式でこれを両立させる。

コスト面の影響

• Bedrock は on-demand 課金で Gateway 経由と単価構造は同等。ただし providerMetadata.gateway.cost が来なくなるため、コスト計上が modelPricing テーブル（ap-northeast-1 価格）に完全依存する。この表が間違っていると日次/月次のコストリミット（CHAT_DAILY_TOTAL_COST_LIMIT_USD 等）が正しく機能しないため、精度が実質的な安全装置になる。
• Fargate の追加コストは月 $1 未満（NAT を作らない前提）。Cloud Run Job の停止分と相殺される。
• gpt-oss-120b を軽量パスに充てることで、Claude 単独構成よりトークン単価を下げられる余地がある。

時間的制約

Langfuse の v4 ingestion 切替期限が 2026-11-16。Bedrock 移行と独立して #41 を先に済ませる必要がある。

影響

メリット

• 推論が日本国内リージョンに限定され、データ所在の要件を満たせる。
• 本番から国外プロバイダに推論が流れる経路が構造的に存在しなくなる（許可リスト + IAM の global.* Deny の二重防御）。
• Vercel から長期の秘密情報（GCP_SA_KEY、AI_GATEWAY_API_KEY）が消える。 残るのは OIDC で交換される一時資格情報のみ。
• Gateway を撤去するため、「本番が意図せず Gateway を向く」経路がコード上に存在しなくなる。
• クラウドが AWS + Vercel の 2 つに減り、認証情報の管理点が減る。
• Bedrock Guardrails（既に PR feat: AWS Bedrock Guardrailsによる有害コンテンツ検知・ブロックを追加 #28/fix: PROMPT_ATTACKフィルタのoutputStrengthをNONEに修正 #30 で定義済みだが Lambda からしか使われていない）をアプリ経路に接続でき、有害コンテンツ・プロンプトインジェクションの防御層が増える。
• worker の実行時間上限がなくなり、議案数の増加に対してスケールする。

懸念点

• web_search の廃止で公開チャットの回答品質が下がる

  • 緩和策: 影響範囲を実測する。法案の背景情報は Langfuse 管理のプロンプトに含まれる billContent / knowledgeSource から供給されており、web 検索への依存度は元々低い可能性がある。品質低下が実測で問題になる場合、Tavily 等の外部検索 API を自前 tool として実装する（本 Epic のスコープ外の追加 Issue）。

• 構造化出力（15箇所）の失敗率がプロバイダ変更で悪化する可能性

  • 緩和策: 【検証】構造化出力15箇所の Bedrock 適合性検証とクォータ確認 #47 で合格ラインを先に決め、seed で用意した入力を使って全パスを 10 回ずつ通し、成功率・レイテンシ・失敗フィールドを表にして記録する。既に with-timeout-retry.ts（LLM_MAX_ATTEMPTS = 2）があるため、リトライの適用漏れを棚卸しする。合格ラインを割る場合はスキーマ側の .max() 制約を緩めて後処理でトリムする方向に切り替える。

• モデル選択肢が大幅に減る（OpenAI 11種 + Gemini 3種 → Claude 2種 + gpt-oss 1種）

  • 緩和策: 検証環境では許可リストで OpenAI / Gemini を残すため、シミュレーションによるモデル比較機能は維持される。本番の選択肢が減ることは、データ所在要件からの必然として受け入れる。

• コスト計上が推定値のみになり、modelPricing テーブルが単一障害点になる

  • 現状は Vercel AI Gateway が providerMetadata.gateway.cost として実課金額を返しており、resolveCostUsd() がそれを第一候補に使っている。Bedrock はこれを返さないため、移行後は「トークン数 × コード内の単価表」という推定値だけが残る。この表が間違っていると、日次/月次のコストリミット（CHAT_DAILY_TOTAL_COST_LIMIT_USD / CHAT_MONTHLY_TOTAL_COST_LIMIT_USD）が誤作動する。安すぎれば暴走課金を止められず、高すぎれば正常な利用者がブロックされる。
  • 緩和策1: AWS Cost Explorer の Bedrock 実費と chat_usage_events の合計を月次で突合する。これが唯一の正解との照合手段。乖離したら単価表を直す。【適用】モデルカタログ・コスト表・UI選択肢を Bedrock（日本リージョン）へ再定義する #43 の検証項目に含める。
  • 緩和策2: calculate-ai-cost.test.ts に ap-northeast-1 の単価を明示した回帰テストを置き、価格改定時に気づけるようにする。
  • 緩和策3（副次的）: 【運用】Langfuse Cloud に Bedrock 用カスタムモデル定義（価格）を登録する #50 で Langfuse 側にも同じ単価を登録する。これは Langfuse ダッシュボードでコストが 0 表示にならないようにするのが主目的であり、転記ミスの検出にはなるが単価そのものの正しさは担保しない（両方に同じ誤った値を入れれば一致してしまう）。正しさの担保は緩和策1 が担う。

• Cloud Scheduler と EventBridge Scheduler の二重実行リスク

  • 緩和策: 【インフラ】トピック分析 worker の実行基盤を Cloud Run Job から ECS Fargate + EventBridge Scheduler へ移行する #48/【インフラ】admin の実行トリガを ecs:RunTask に切り替え、Vercel から GCP_SA_KEY を廃止する #49 のデプロイ手順に「Cloud Scheduler を SCHEDULER_PAUSED=1 で停止」を明記し、移行完了の確認項目に含める。加えて topic_analysis_version の one_active_version_per_bill 一意制約が原子的ガードとして機能するため、二重起動しても片方は skipped になる。

• Bedrock のクォータ（TPM/RPM）が現行の並列度に足りない可能性

  • 緩和策: 【検証】構造化出力15箇所の Bedrock 適合性検証とクォータ確認 #47 で実測する。特に意見再抽出バックフィルの OPINION_BACKFILL_CONCURRENCY = 30 が最もクォータを踏みやすい。Service Quotas の引き上げ申請にはリードタイムがあるため、Epic の前提作業として早期に着手する。

• ECS Fargate を採用すると VPC・ECR・タスク定義・CI（イメージ push）という新しい運用対象が増える

  • 緩和策: すべて CDK（infra/aws-cdk）で管理し、既存の GitHubOidcStack によるデプロイ経路に乗せる。手動作成のリソースを作らない。

代替案

案A: Vercel AI Gateway の BYOK で Bedrock を使う

Gateway に AWS 資格情報を登録し、Gateway 経由で Bedrock を呼ぶ。

• 主な特徴: アプリ側の変更がほぼゼロ。モデルIDの形式も維持できる。
• メリット: 移行コストが最小。gateway.cost によるコスト取得も維持される。
• デメリット: 推論リクエストが Vercel の基盤を経由するため、データ所在をアプリ側で保証できない。Gateway 自体の可用性・レイテンシに依存し続ける。
• 不採用の理由: 「Vercel 社が提供する LLM 基盤から離れる」という本移行の目的そのものを満たさない。データ所在要件も満たせない。

案B: Vercel Cron + Vercel Function でバッチを実行する

vercel.json の cron でフェーズ連鎖版を復活させる。

• 主な特徴: 追加インフラがゼロ。実装も既にリポジトリに残っている。
• メリット: AWS 側の新規リソース（VPC / ECR / ECS / EventBridge）が不要。
• デメリット: docs/20260609_1200_...md §0 が列挙した 4 つの弱点（5分制限・自己トリガの静かな停止・同時実行制御の弱さ・可観測性の低さ）がそのまま戻る。800s（GA）では --mode=analyze-all が収まらない見込みで、1800s は beta。
• 不採用の理由: 一度採用して問題が出て捨てた設計であり、明確な後退になる。

案C: Vercel Cron をトリガーとして使い、実行は ECS

cron が数秒で終わる関数を叩き、そこから ecs:RunTask する。

• 主な特徴: EventBridge Scheduler を作らずに済む。
• メリット: AWS 側のリソースが 1 つ減る。手動トリガと定期トリガのコードパスが完全に共通化できる。
• デメリット: スケジュール定義が vercel.json に散りタスク定義と離れる。Vercel の本番デプロイが存在しないと cron が動かない。cron 自体にリトライがない。
• 不採用の理由: 実装としては成立するが、スケジュールを CDK に置いてタスク定義と同じ場所で管理する方が運用上明快であり、Vercel の本番デプロイ存在に依存しない。2026-08-21 の議論で EventBridge Scheduler を採用することが確定したため、本案は不採用で確定。

案D: EventBridge Scheduler + Lambda（コンテナイメージ）

• 主な特徴: 既に LambdaStack があり、VPC が不要。
• メリット: VPC・ECS クラスタを作らずに済む。コールドスタートが速い。
• デメリット: 15 分の実行時間上限。現行が 3600s を予算に取っている --mode=analyze-all には足りない。議案単位の --mode=analyze なら収まる可能性があるが、全議案処理を Step Functions で分割する追加設計が必要になる。
• 不採用の理由: 実行時間上限が要件に合わず、分割設計を入れると案B と同じ「分割の複雑さ」を持ち込むことになる。

案E: Vercel Workflows

Vercel が提供する durable execution（pause/resume で状態を保持し実行時間制限なし）。

• 主な特徴: Vercel 上で長時間処理が書ける。
• メリット: AWS 側のバッチ基盤が不要。リトライ・状態管理がプラットフォーム機能として提供される。
• デメリット: プログラミングモデルの書き換えが必要で、「実行の殻を差し替えるだけ」で済む今回の移行に対して過剰。AWS 前提という方針にも逆行する。
• 不採用の理由: 移行コストが目的に対して過大。

案F: Nova を採用する

• 不採用の理由: 調査の結果、Nova Pro は ap-northeast-1 にリージョン行が存在せず提供されていない。Nova Lite は東京 In-Region で利用可能だが、max output = 5K かつ Bedrock ネイティブの structured outputs 非対応で、インタビュー summary レポート生成（interviewChatWithReportSchema）に使えない。軽量パス専用に入れる価値も、gpt-oss-120b（16K / 構造化出力対応）があるため薄い。

今後の方向性

後続アクション

1. 本 ADR を確定させ、docs/adr/ に正式版として配置する。
2. Epic 【Epic】LLM 基盤を Vercel AI Gateway から AWS Bedrock（日本リージョン）へ移行し、実行基盤を AWS に統一する #52 のフェーズ順（【整理】旧 Vercel フェーズ連鎖版トピック分析（api/topic-analysis/phases）を削除する #51/【観測】Langfuse を JS SDK v5（@langfuse/otel）へ移行し forceFlush でトレース欠落を防ぐ #41/【適用】公開チャットの web_search ツールを廃止する #44 → 【インフラ】Bedrock IAM ポリシーを日本CRIS（jp.）対応にし global.* を明示 Deny する #45/【基盤】AI SDK に provider registry を導入し、論理モデルID＋プロバイダ許可リストで本番を Bedrock 固定にする #42/【適用】モデルカタログ・コスト表・UI選択肢を Bedrock（日本リージョン）へ再定義する #43 → 【インフラ】トピック分析 worker の実行基盤を Cloud Run Job から ECS Fargate + EventBridge Scheduler へ移行する #48/【インフラ】admin の実行トリガを ecs:RunTask に切り替え、Vercel から GCP_SA_KEY を廃止する #49 → 【適用】Bedrock Guardrails をアプリの LLM 呼び出し経路に接続する #46/【検証】構造化出力15箇所の Bedrock 適合性検証とクォータ確認 #47/【運用】Langfuse Cloud に Bedrock 用カスタムモデル定義（価格）を登録する #50）で実装する。
3. Epic 本文の「前提となる運用作業」（Bedrock モデルアクセス申請、Service Quotas 確認、Vercel 環境変数、OIDC IdP 登録）を並行して進める。リードタイムのある申請系を先に出す。

将来の検討事項

• ai@7 へのメジャーアップ: @ai-sdk/amazon-bedrock@5.x / Langfuse の registerTelemetry() + @langfuse/vercel-ai-sdk 方式が使えるようになる。ただし ai@7 は Node.js 22+ が必要。本移行が安定した後の別 Epic とする。
• web 検索の再導入: 品質低下が実測で問題になった場合、Tavily / Brave 等を自前 tool として実装する。
• プロンプトキャッシュの活用: Claude は 1h TTL のキャッシュに対応している。インタビューのシステムプロンプト（billContent を含む長文）はキャッシュヒットしやすく、コスト削減余地がある。
• VPC エンドポイント: Bedrock へのトラフィックをインターネットに出さない要件が出た場合、com.amazonaws.ap-northeast-1.bedrock-runtime の Interface Endpoint を検討する（NAT / PrivateLink のコストとのトレードオフ）。

この決定を見直すトリガー

• jp. CRIS の対象モデルに Sonnet の後継が含まれない場合 → 東京 In-Region 対応モデルへの切り替え、またはリージョン方針の再検討。
• 構造化出力の失敗率が 【検証】構造化出力15箇所の Bedrock 適合性検証とクォータ確認 #47 で定めた合格ラインを下回る → プロバイダ構成の再検討、またはスキーマ設計の抜本的な見直し。
• Bedrock のクォータが引き上げ申請でも足りない → 並列度の設計変更、またはプロビジョンドスループットの検討。
• 月次のコスト突合で chat_usage_events と AWS 実請求額が有意に乖離する → modelPricing の単価と、キャッシュトークンの計上ロジックを見直す。乖離が構造的なら、Cost Explorer の実費をコストリミット判定の入力に使う設計（日次バッチで取り込む等）へ変更する。
• Guardrail の誤検知率が運用上許容できない → MEDIUM の強度設定、または Guardrail 自体の適用範囲を見直す。sync/async の切替は環境変数で可能なので、この見直しには含めない。

参考

リポジトリ内

• docs/20260609_1200_トピック分析CloudRun実行基盤設計.md — §0 に Vercel フェーズ連鎖を捨てた理由、§2.1 に packages/topic-analysis-core への移設記録
• docs/20260609_1230_トピック分析CloudRunプロビジョニング手順.md
• docs/20260715_1043_トピック分析スケジューラー化.md
• docs/20260809_1026_AWS_Bedrock_CDK基盤_運用開始までの作業手順.md
• docs/20251007_2159_Langfuse導入設計.md
• infra/cloud-run/provision.sh — Cloud Scheduler / Job の現行設定
• PR feat: VercelからBedrockへOIDC Federationでアクセスするためのスタックを追加 #26（VercelOidcStack）、PR feat: AWS Bedrock Guardrailsによる有害コンテンツ検知・ブロックを追加 #28 / fix: PROMPT_ATTACKフィルタのoutputStrengthをNONEに修正 #30（Bedrock Guardrails）、VercelからAWS BedrockへOIDC Federationでセキュアにアクセスする #25（OIDC 調査）

外部

• AI SDK: Provider & Model Management
• AI SDK: Amazon Bedrock provider
• Vercel: Connect to Amazon Web Services (AWS)
• Vercel Functions Limits
• Vercel Cron Jobs: Usage & Pricing
• AWS: Prerequisites for inference profiles
• AWS: Supported Regions and models for inference profiles
• AWS: Claude Sonnet 4.6 model card
• AWS: Claude Haiku 4.5 model card
• AWS: gpt-oss-120b model card
• AWS: Nova Pro model card / Nova Lite
• AWS: Cross-Region inference for Claude Sonnet 4.5 / Haiku 4.5 in Japan and Australia
• Langfuse: Vercel AI SDK integration
• Langfuse: Versions & Compatibility
• Langfuse issue #13325: no cost tracking when using bedrock inference profiles
• AWS re:Post: Web Search for Anthropic Models in Bedrock

[ushios]

@claude

#51 ─┐
#41 ─┼─→ #45 ─→ #42 ─→ #43 ─→ #47
#44 ─┘          │
                └─→ #46
#48 ─→ #49
#43 ─→ #50 

これを、マーメイドで人間でもわかりやすいように見やすくリンク付きにしてください。

[ushios]

[ushios]

graph LR
    n51["#51 旧Vercelフェーズ連鎖版トピック分析を削除"]
    n41["#41 Langfuseを JS SDK v5へ移行しforceFlushでトレース欠落防止"]
    n44["#44 公開チャットのweb_searchツールを廃止"]
    n45["#45 Bedrock IAMを日本CRIS対応にしglobal.*を明示Deny"]
    n42["#42 AI SDKにprovider registry導入、本番をBedrock固定に"]
    n43["#43 モデルカタログ・コスト表・UI選択肢をBedrockへ再定義"]
    n47["#47 構造化出力15箇所のBedrock適合性検証とクォータ確認"]
    n46["#46 Bedrock GuardrailsをLLM呼び出し経路に接続"]
    n50["#50 LangfuseにBedrock用カスタムモデル定義（価格）を登録"]
    n48["#48 トピック分析workerをECS Fargate+EventBridge Schedulerへ移行"]
    n49["#49 adminの実行トリガをecs:RunTaskに切替、GCP_SA_KEY廃止"]

    n51 --> n45
    n41 --> n45
    n44 --> n45
    n45 --> n42
    n42 --> n43
    n43 --> n47
    n43 --> n46
    n43 --> n50
    n48 --> n49

    click n51 "https://github.com/codeforjapan/saga-broadlistening/issues/51" _blank
    click n41 "https://github.com/codeforjapan/saga-broadlistening/issues/41" _blank
    click n44 "https://github.com/codeforjapan/saga-broadlistening/issues/44" _blank
    click n45 "https://github.com/codeforjapan/saga-broadlistening/issues/45" _blank
    click n42 "https://github.com/codeforjapan/saga-broadlistening/issues/42" _blank
    click n43 "https://github.com/codeforjapan/saga-broadlistening/issues/43" _blank
    click n47 "https://github.com/codeforjapan/saga-broadlistening/issues/47" _blank
    click n46 "https://github.com/codeforjapan/saga-broadlistening/issues/46" _blank
    click n50 "https://github.com/codeforjapan/saga-broadlistening/issues/50" _blank
    click n48 "https://github.com/codeforjapan/saga-broadlistening/issues/48" _blank
    click n49 "https://github.com/codeforjapan/saga-broadlistening/issues/49" _blank

Loading