戦略会議でリアルタイム提示する AI カンペを「発話終了から 1.5 秒前後で出す」 ことを設計目標にした理由と、 Bedrock + Anthropic Direct API のハイブリッド構成、 プロンプトキャッシュ運用、 latency / cost の現実的なトレードオフを実装ベースで解説。
Issue-Axis（戦略会議をリアルタイム支援する AI）の核は、 会議中に発話終了から 1.5 秒前後で「論点抜け」 「想定質問」 「So What 補完」 のカンペを画面右端に出す機能です。
「1.5 秒」 という目標値はなぜそこなのか、 そしてその目標を満たすために採用した Bedrock（AWS）+ Anthropic Direct API のハイブリッド構成について、 実装ベースで共有します。
なぜ 1.5 秒なのか
「リアルタイム」 を謳う AI プロダクトは多いですが、 体感の質は応答時間で全く変わります。 設計時に内部で議論した時間軸はおおむね以下です。
| 体感 | 発話終了 → 提示までの時間 |
|---|---|
| 即座（人間の追従が追いつく） | 〜 1.0 秒 |
| 自然（軽い違和感、 多くのユーザーが許容） | 1.0 〜 2.0 秒 |
| 「ちょっと遅い」 | 2.0 〜 3.5 秒 |
| 会議の流れを止めるほど遅い | 3.5 秒以上 |
会議で「直前の発言を踏まえた助け舟」 を出す用途では、 議論の流れに置いていかれない限界が体感 2 秒程度。 ここに STT（音声認識）の遅延 + ネットワーク往復 + LLM 推論が乗るので、 LLM 単独の予算は「1.0 〜 1.5 秒以内」 が現実的な上限です。
その制約を起点に技術選定を逆算しました。
モデル選定の前提
戦略会議のカンペ生成タスクで必要な能力は以下です。
- 論理構造の把握: 「経営会議の発話の流れ」 を MECE / Issue Tree で読む
- 戦略コンサル思考フレームの内蔵: So What / Why So / ピラミッドストラクチャー
- 日本語の自然さ: ビジネス文脈での言い回し、 敬語、 用語選択
- 業種文脈の対応: SaaS / 金融 / 製造業 / 小売 等で当然の論点が変わる
候補に挙がったのは Claude Haiku 4.5 / Claude Sonnet 4.7 / GPT-4o-mini / Gemini 2.x Flash 等。 dogfooding で評価した結果:
- Haiku 4.5: 速い・安い・日本語の自然さもビジネス用途で十分・思考フレームの追従度も実用的
- Sonnet 4.7: 論理飛躍検出・複雑な議論の構造把握では Haiku を上回る、 ただし latency と cost が 2-3 倍
最終的に 「Light プランは Haiku、 Pro プランは Sonnet」 の二段構成 + ユーザー切替可とし、 会議中のカンペ生成は基本 Haiku 固定（Sonnet にすると latency が体感閾値を超える）に決めました。
なぜ Bedrock + Anthropic Direct のハイブリッドか
Claude を本番運用する場合、 主な経路は 2 つあります。
| 経路 | 強み | 弱み |
|---|---|---|
| Anthropic Direct API | 最新モデルが即日提供、 token streaming が滑らか | リージョンが米国中心、 日本からの latency が +50-100ms |
| AWS Bedrock | 東京リージョン提供、 IAM / VPC で AWS と統合運用、 latency が国内最短 | 最新モデル提供が Direct から数日〜数週間遅れ、 一部機能差分あり |
両方使える状況で、 会議中のリアルタイム経路は Bedrock 東京、 会議準備 / 議事録生成は Anthropic Direct という割り当てに行き着きました。
判断軸:
- latency 最優先 = リアルタイム Cue 生成: Bedrock 東京を選択。 同じ Haiku でも国内 endpoint で東京 -> us-east 間の往復 50-100ms を削れる
- 品質重視 + バッチ的処理 = prepare / postmeeting: Anthropic Direct を選択。 LLM 推論が 5-15 秒かかっても許容、 最新モデルで品質を取りに行く
- 災害時の冗長: Bedrock が一時障害なら Anthropic Direct にフェイルオーバー、 逆も同様。 単一プロバイダ依存の可用性リスクを避ける
「ハイブリッド」 と言っても、 アプリケーション層で経路を抽象化していて、 内部の bedrock-client.ts と anthropic-client.ts を呼び分ける薄い dispatcher を 1 枚挟んでいるだけです。
レイテンシの内訳と最適化ポイント
実測ベースで「発話終了 → カンペ提示」 の内訳はおおむね以下です（条件: 良好な ネットワーク、 国内ユーザー、 Haiku, Bedrock 東京）。
| 工程 | 標準 | 最適化後 |
|---|---|---|
| STT 確定（Deepgram interim → final） | 800-1,200ms | 600ms（VAD chunking 調整 + interim 採用） |
| アプリ → Bedrock 往復 + queueing | 100-200ms | 80ms |
| Bedrock 推論（Haiku、 入力 ~2K token / 出力 ~150 token） | 700-1,000ms | 400-600ms（プロンプトキャッシュ HIT 時） |
| クライアント描画 | 50-100ms | 50ms |
| 合計 | 1,650-2,500ms | 1,130-1,330ms |
最適化で効いたのは大きく 2 つ。
1. プロンプトキャッシュの HIT 率最大化
Anthropic の prompt caching は 「先頭から一致する部分」 を 5 分間キャッシュしてくれる機能で、 system prompt と長い文脈（プロジェクト履歴 / 添付資料抜粋 / 思考フレーム定義）を毎回頭に固定する設計にすると、 同じ会議中の 2 回目以降のカンペ生成で input token が事実上 0 token として課金されます。
実装の要点は 「変動する部分（直近 transcript）を末尾に置く」 こと。
``` [system prompt: 思考フレーム定義 + 業種文脈] <- キャッシュ対象（5 分有効） [文脈: プロジェクト履歴サマリ + 添付要約] <- キャッシュ対象 [直近 30 発話の transcript] <- 毎回変わる、 末尾に [user 指示: "次に検討すべき論点を 3 つ"] ```
これで会議中の 2 回目以降は input token 90%+ がキャッシュ HIT、 課金も latency も大幅に削減できます。
2. 出力 token の上限と stop sequence
カンペは「短い 3 行 × 3 件」 で十分、 出力が長くなるほど latency に直結します。 max_tokens を 200 程度に絞り、 さらに 「3 件目を出し終えたら止まる」 ような stop sequence で打ち切る運用にしました。
加えて、 streaming で受けて UI に逐次描画することで「全部生成し終えるまで何も出ない」 体感を避けています。 「最初の 1 行が出るまでの時間（TTFT, Time To First Token）」 こそが体感速度の鍵です。
コスト感
Issue-Axis Pro プラン（月 50 時間利用、 Haiku で会議中 Cue + Sonnet で議事録生成）の 想定コスト試算は概ね以下（公開時点の単価ベース、 実数値は変動）。
| 項目 | 月間予算（推定） |
|---|---|
| Bedrock Haiku（会議中 Cue 生成、 50 時間 × 平均 60 回 / 時間） | 数百円〜数千円程度 |
| Anthropic Sonnet（議事録 / 準備、 50 件 × 1 万 token） | 数百円〜数千円程度 |
| Deepgram STT（50 時間 × $0.0043/分） | 約 1,500 円 |
| Supabase / Vercel / Resend 固定費 | 共通配賦 |
プロンプトキャッシュ HIT 率を 80%+ で維持できれば、 LLM コストは 想定 1 ユーザー月 1,000-2,000 円程度で収まる試算です。
具体額は使い方とモデル単価変動の影響を強く受けるので、 公開時点でも継続的に観測しています。
失敗 / 学び
実装途中で踏んだ落とし穴をいくつか。
学び 1: 「速い」 だけだと使われない
最初の prototype で latency 800ms のカンペを作った時、 dogfooding で「速いけど内容が薄くて結局見ない」 という FB をもらいました。 速度と品質はトレードオフなので、 「品質の下限を切らない速度」 を探すのが正しい問い。 出力 token 数を絞りすぎないこと、 system prompt に「具体的な思考フレーム」 をしっかり詰めることで、 同じ Haiku でも体感品質が大きく変わりました。
学び 2: streaming UI を作る時の race
stream で逐次描画していると、 「一瞬前の Cue がまだ完全に表示しきれていないうちに新しい Cue リクエストが来る」 状態が頻発します。 Cue を「現行版を maybe-stale にしながら新しい版を fade-in」 する UI 制御をミスすると、 ちらつきが酷くなります。 リクエスト ID で世代管理して、 古い世代の chunk を破棄するパターンに落ち着きました。
学び 3: Bedrock の rate limit は早めに上限申請
東京リージョン Haiku の default quota は意外と厳しく、 開発初期に何度か ThrottlingException を踏みました。 Bedrock コンソールから「Service quotas」 で各モデル別の TPM / RPM 上限申請を出しておくと、 本番で詰まりません（申請から有効化まで数日かかるので早めに）。
学び 4: フォールバックは静かに、 でもログに残す
Bedrock が一時障害で ServiceUnavailable を返した時、 自動で Anthropic Direct にフェイルオーバーする実装にしましたが、 ログを残さないと 2 日後に「コストが想定の倍出てる」 という事態に。 fallback 経路はメトリクスとアラートを必ず付けてから本番投入するべき。
まとめ
会議中のリアルタイム AI カンペを 1.5 秒前後で出すには、
- モデル選定: 体感閾値から逆算して Haiku を採用（Sonnet は latency 重視タスクには重い）
- 経路選定: Bedrock 東京 + Anthropic Direct のハイブリッド（latency と最新モデル / 冗長性を両立）
- プロンプトキャッシュ: system / 文脈を先頭固定、 transcript を末尾に
- streaming + 出力 token 上限: TTFT を最短に、 全文待たない UI
の 4 点を押さえることが肝要でした。 これから「リアルタイム LLM」 系の機能を作る方の参考になれば。
Issue-Axis 自体に興味を持っていただけた方は、 使い方ガイド で会議準備 → 会議中 → 議事録生成までの一連の体験を確認いただけます。 料金プラン で Light / Pro の違いをご覧ください。
関連記事 / 参考リンク
関連