国内・海外の事例から読み解く ── 住信 SBI・セゾン・Toyota・Pfizer は何をしたか
対象読者：実装は把握したが、自社の現場でどう価値に転換するかを、他社の選択を見て言語化したい読者 難易度：★★☆☆☆（読み物・概念整理） 想定読了時間：約 40 分 関連章：第 3 章（他社比較）/ 第 4 章（機能カタログ）/ 第 17 章（アンチパターン）
ここまで来て、もう一度問いに戻る
第 3 章で他社サービスとの設計差を扱ったとき、こんな問いを残した。「住信 SBI ネット銀行・みずほ銀行・Pfizer は、OpenAI 直叩きでも Azure OpenAI でもなく、なぜ Bedrock を選んだのか」。
第 5 章では「モデルを選ぶ」というテーマで「意図理解は軽量モデル、最終判断は高精度モデル」という階層使い分けを紹介したが、これを実装に落とすとどうなるのかは抽象的だった。
第 8 章で組み立てた Knowledge Bases ベースの RAG は、デフォルト設定でもそれなりに動いた。しかし「Knowledge Bases 比 +22 % の精度」を出すには何が必要なのか、第 8 章の本文では深堀りを避けた。
第 10 章で乗り換えた AgentCore は、機能の組み合わせとしては理解できたが、「v1 の RAG ベース実装から v2 の AgentCore 実装に乗り換えた現場の決め手は何だったのか」は、機能仕様書を読んでも答えが出ない。
これらの問いの答えは、機能ドキュメントの中ではなく、実際に作って運用している現場の中にある。本章では国内 4 件・海外 3 件の事例を深堀りし、最後に 5 つの共通パターンとして、自分の現場で再現できる形に圧縮する。
なお本シリーズは「事例カタログ」を目指していない。事例から 設計判断のテンプレートを取り出すことが目的だ。「どこが Bedrock を使った」ではなく「なぜ Bedrock だったのか・何を工夫したのか・何が効いたのか」を読んでほしい。
国内事例 4 件を深堀りする
事例 1：住信 SBI ネット銀行「NEOBANK ai」── 階層モデルとジェネレーティブ UI の組み合わせ
住信 SBI ネット銀行は、銀行サービスの操作体系そのものを「階層メニューから自然言語へ」転換する挑戦として「NEOBANK ai」を立ち上げた。ユーザーは「先月の家賃の振込履歴を見せて」「家族に 5 万円振り込みたい」のように話しかけるだけで、画面 UI が動的に生成され、操作が進む。テキスト・音声・画像のマルチモーダル入力に対応している点も特徴的だ。
採用された技術スタックの中心は Amazon Bedrock AgentCore Runtime。これに API Gateway + Lambda + DynamoDB（レートリミット管理と監査証跡）と AgentCore Observability が組み合わさっている。第 10 章で扱った AgentCore の主要コンポーネントを、銀行業務という最も厳格なドメインで実用に乗せている事例だ。
設計上のキモが、第 5 章で予告した 階層モデル使い分けにある。
ユーザー発話 → 「意図理解」(軽量・高速モデル) → アクション組み立て
→ 「ガードレール判定」(高精度モデル) → 承認 / 拒否
→ アクション実行意図理解は高速性が支配的なので軽量モデルで捌き、ガードレール判定は誤判定のコストが大きいので高精度モデルに任せる。これは「Claude Sonnet で全部叩く」設計の対極にあり、コストと品質を両立させる現実的な解だ。第 5 章で示した「タスクの 40〜60 % は Haiku で済む」という指針が、銀行業務という最高難度のドメインでさえ通用することを示している。
公表されている数値は限定的で、AWS 公式記事には「ピーク時の安定応答」「高コスト効率の両立」と定性的に記載されているのみだ。だが採用理由として明示されている スケーラビリティ・モデル柔軟性・可視性・セキュリティの 4 要件は、第 1 章で示した「Production Ready の 3 つの壁」とほぼ等価で、銀行という最厳格ドメインで「壁を越える道具」として AgentCore が選ばれた事実そのものに重みがある。
そして、第 3 章で予告した通り、銀行業務における顧客データ・取引データの取り扱いを考えれば、OpenAI 直叩きという選択肢は構造的に取りえない。「顧客データは AWS アカウント内に閉じ、モデルプロバイダーに渡らない」という Bedrock のデータ取り扱いポリシー（FMaaS の核心）が、ここでは採用の前提条件として効いている。
出典：住信 SBI ネット銀行、Amazon Bedrock AgentCore を活用した AI 銀行サービス「NEOBANK ai」で顧客体験を革新（AWS 公式日本ブログ）
事例 2：セゾンテクノロジー（HULFT サポート）── Advanced RAG で Knowledge Bases を超える
データ連携ミドルウェア HULFT のテクニカルサポートを運営するセゾンテクノロジーは、数万ページに及ぶマニュアル・FAQ・過去問い合わせから回答を生成する Advanced RAG チャットボットを構築した。
技術スタックの組み合わせがそのまま設計判断のお手本になっている。
- クエリ生成：Claude 3 Haiku（軽量・高速）
- 回答生成：Cohere Command R+（多言語・コンテキスト長・コスト効率）
- ベクトル DB：FAISS
- トークナイザ：sudachi（日本語形態素解析）
- 検索：ハイブリッド検索（ベクトル + キーワード）+ 階層的チャンク + クエリ拡張
- インフラ：Lambda + ECR + Guardrails for Bedrock（機密入力制限）
注目すべきは Knowledge Bases そのものを使わず、Bedrock の素のモデル呼び出しと FAISS を組み合わせている点だ。第 8 章で扱った Knowledge Bases は「すぐ動く」が、本格的な日本語ドキュメントを扱うにはチャンキング・トークナイザ・検索方式のすべてに介入が必要になる ── ということを、この事例は実装で証明している。
数値：
- 回答作成時間を 最大 30 % 短縮
- サポート全体で 約 10 % の業務効率化
- 精度向上は Amazon Kendra 比 +14 %、Bedrock Knowledge Bases 比 +22 %
この「+22 %」が示しているのは、単に Knowledge Bases を有効化しただけのベースラインに対して、sudachi + ハイブリッド検索 + クエリ拡張を積み上げた効果だ。第 8 章で「チャンキングを Default で放置するな」と書いたが、その先に何があるかをセゾンテクノロジーは見せてくれている。
なお、第 11 章で扱った Guardrails Contextual grounding は 2026 年 6 月時点で日本語非対応であり、セゾンテクノロジーは「Guardrails for Bedrock の機密入力制限機能」を活用する形で安全性を担保している。日本語 RAG では「Guardrails で完全に守る」のではなく「入力サイドの Guardrails + 評価による事後検知」のハイブリッド設計が現実解になる。
出典：セゾンテクノロジー様の AWS 生成 AI 事例（AWS 公式日本ブログ）
事例 3：NTT ドコモ ── 100 万台超のネットワーク機器を AgentCore で守る
NTT ドコモは モバイルネットワーク保守業務の AI エージェントを Bedrock AgentCore 上に構築した。対象規模が桁違いで、100 万台超のネットワーク機器からのデータを解析し、異常検知と対処策をオペレータに提示する。
採用の決め手は規模そのものだ。100 万台というスケールで「機器ごとの状態を文脈に保ちながら、異常時に推論し、過去の対処履歴を引いてレコメンドする」処理は、ステートフルな会話・ツール呼び出し・観測の 3 点が揃っていないと成り立たない。これは第 10 章で扱った AgentCore の Memory / Identity / Observability がそのまま当てはまる要件だ。
もし自社でこれをスクラッチで作るなら、ステートストアの設計、認証統合、トレースのスキーマ、エラー時のフォールバックを全て自前で書く必要がある。Bedrock Agents の Action Groups で組むにはステート管理が薄すぎる。AgentCore がリリースされたタイミング（2025 年 10 月 GA）と、NTT ドコモのような大規模事業者の本番採用が並行したのは偶然ではない。
公表されている数値の詳細は限定的だが、「100 万台超の機器を扱うエージェント基盤として AgentCore を選んだ」事実そのものが、「マネージドな Agent ランタイムが大規模インフラ運用にも耐える」という重要な工業的証拠になっている。
出典：NTTドコモ、モバイルネットワーク保守業務のAIエージェント開発 Amazon Bedrock活用で（EnterpriseZine）
事例 4：情報戦略テクノロジー「パイオにゃん」── 既存 SaaS との統合が価値を生む
情報戦略テクノロジーは、社内に散らばる情報を横断検索する AI エージェント秘書「パイオにゃん」を構築した。検索対象は Slack・Google Drive・GitHub。それぞれが API・権限モデル・データ形式すべて異なるが、これを一つのエージェントから扱えるようにした。
技術スタックは Bedrock Knowledge Bases（RAG）+ Strands Agents SDK。重要なのは メタデータフィルタによる権限管理で、ユーザーごとに「見える情報・見えない情報」を Knowledge Bases の検索段階で絞り込んでいる。これは第 8 章でメタデータフィルタを扱った際の典型的なエンタープライズ運用例だ。
数値：
- 情報探索業務 83 % 改善（年間 24,000 時間 → 4,000 時間）
- 1 回あたりの探索時間 3 分 → 30 秒
「年 20,000 時間削減」を額面で見ると衝撃的だが、本質はそこではない。Slack・Drive・GitHub という日常的な SaaS にエージェントが入った瞬間、情報探索のコストが桁違いに下がるという構造の話だ。これは「Bedrock を入れたから生産性が上がった」のではなく、「Bedrock を 既存の業務システムに統合したから、業務そのものが置き換わった」と読むべきだ。
第 18 章のエピローグでも触れる予定だが、Production Ready な AI の価値は、孤立した賢いチャットボットではなく、既存システムと配管された Agent から生まれることを、パイオにゃんは見事に示している。
出典：株式会社情報戦略テクノロジー様の AWS 生成 AI 活用事例（AWS 公式日本ブログ）
国内事例 13 件の俯瞰表
深堀りした 4 件以外も、業界 × 用途のマトリクスで俯瞰しておく。リサーチ 04 §1 にまとめた 13 件を 1 行ずつ整理する。
| 企業 | 業界 | 用途 | キー数値・特徴 |
|---|---|---|---|
| 住信 SBI ネット銀行 | 金融 | NEOBANK ai（ジェネレーティブ UI 銀行） | AgentCore Runtime、階層モデル使い分け |
| みずほ銀行 | 金融 | 生成 AI 標準プラットフォーム | PrivateLink + 大阪リージョン、複数モデル統合 |
| SBI 生命保険 | 保険 | コールセンタードキュメント検索 | 研修期間 30 % 短縮、Kendra + Bedrock |
| セゾンテクノロジー | IT | HULFT サポート Advanced RAG | Knowledge Bases 比 +22 %、回答 30 % 短縮 |
| KDDI | 通信 | 生成 AI ソリューション外販 | 社内問い合わせ 3 割軽減、グループ実証から外販へ |
| NTT ドコモ | 通信 | モバイルネットワーク保守 Agent | 100 万台超機器対応、AgentCore |
| CyberAgent / ABEMA | メディア | サッカー中継ハイライト自動生成 | Bedrock + Rekognition、業務量大幅減 |
| タキヒヨー | 製造（繊維） | デザイン・社内文書・議事録 | 月 450 時間削減、1 デザイン 2 時間効率化 |
| RIZAP テクノロジーズ | 健康 | 社内ナレッジチャットボット | 月 400 件問い合わせ削減 |
| メック | 製造（電子材料） | 研究業務効率化 Agent | 3 週間で PoC、AgentCore + S3 Vectors |
| 情報戦略テクノロジー | IT | パイオにゃん（社内秘書） | 83 % 改善（24,000h → 4,000h/年） |
| BTM | IT | システム調査自動化 | 半日 → 10 分、PM 工数 95 % 削減 |
| 北海道文化放送 | メディア | ニュース原稿・動画 | ニュース配信数大幅増 |
これらを業界 × 用途で配置すると、次のような分布になる。
quadrantChart
title 国内事例マッピング（業界 × 用途）
x-axis 内部業務効率化 --> 顧客向けプロダクト
y-axis ドキュメント検索 --> エージェント実行
quadrant-1 顧客向け Agent
quadrant-2 顧客向け RAG
quadrant-3 社内 RAG
quadrant-4 社内 Agent
住信 SBI: [0.85, 0.85]
みずほ銀行: [0.3, 0.7]
SBI 生命: [0.25, 0.2]
セゾンテク: [0.7, 0.3]
KDDI: [0.2, 0.2]
NTT ドコモ: [0.4, 0.9]
ABEMA: [0.75, 0.45]
タキヒヨー: [0.3, 0.4]
RIZAP: [0.2, 0.25]
メック: [0.25, 0.85]
パイオにゃん: [0.25, 0.7]
BTM: [0.2, 0.8]
UHB: [0.4, 0.3]この分布から読み取れるのは、「社内 RAG」から始め、ROI が見えたら「社内 Agent」へ、最終的に「顧客向け Agent」へ拡張するという時系列パターンだ。住信 SBI ネット銀行のような顧客向け Agent は最も難易度が高い領域だが、社内事例の積み上げが先行している。
海外事例 3 件を深堀りする
事例 5：Toyota Motor North America ── v1 RAG から v2 AgentCore への移行
Toyota Motor North America と Toyota Connected は、全米のディーラー網に AI アシスタントを展開している。最初のバージョン（v1）は RAG ベースで、公式車両情報への即時アクセスを提供するもの。引用元表示付き、コンプライアンス対応済みという、第 8 章で扱った Knowledge Bases の典型的な活用形だ。
v1 は成功し、月 7,000 インタラクション以上を全米ディーラー網で処理する規模になった。ところが、ディーラーからの要求は単なる情報検索を超え始める ── 「ローカル在庫を確認したい」「この車両の見積もりをその場で出したい」。これらは「文書を読んで答える」RAG の枠を超え、「外部 API を叩いて状態を取得・変更する」Agent の領域だ。
そこで Toyota は v2 で AgentCore Runtime / Identity / Memory を導入した。第 10 章で扱ったコンポーネントがそのままラインナップされている。
| AgentCore コンポーネント | Toyota v2 での役割 |
|---|---|
| Runtime | 認証・スケール・分離されたセッション実行を AWS マネージドで |
| Identity | ディーラーごとの認証統合（DMS = Dealer Management System との接続） |
| Memory | 「先ほどの見積もりの 2.5L グレードで」のような会話継続 |
AWS の発表記事は採用理由を明示している：「認証・スケール・メモリ管理を自前で作らずマネージド化したかった」。
これは第 10 章で「Bedrock Agents から AgentCore への進化線」を辿ったときの一般論を、Toyota が実装と数値で証明した形だ。RAG で出発し、現場のフィードバックで Agent 化が必要になり、自前のステート管理を諦めて AgentCore に乗り換える ── このパターンは 2025〜2026 年に多数の現場で繰り返されている。
出典：AWS re:Invent 2025 Recap for Automotive and Manufacturing（AWS 公式）、Toyota Powers Intelligent Dealership Experiences using Amazon Bedrock & AgentCore（YouTube）
事例 6：Pfizer「VOX」── 製薬業界が選んだデータ主権
製薬業界は、AI が最も入りにくい業界の一つだ。臨床研究データ・特許情報・治験結果は、社外に出ることが文字通り規制違反になる。OpenAI 直叩きという選択肢は構造的にあり得ない。
Pfizer は SageMaker + Bedrock を組み合わせた生成 AI ソリューション「VOX」を構築した。用途は臨床研究の加速と製品歩留まり予測。Bedrock 経由で Anthropic Claude を活用しつつ、機密データを社外に出さない設計を実現している。
Anthropic と Pfizer は Pfizer-Amazon Collaboration Team（PACT） という共同体制を組み、14 プロジェクトを推進している。
数値：
- 研究者の検索時間を 年 16,000 時間削減
- インフラコスト 55 % 削減
特に「インフラコスト 55 % 削減」が示しているのは、自前で構築した LLM インフラを Bedrock マネージドサービスに置き換えたことによる効果だ。GPU 調達・KV キャッシュ管理・モデル更新・スケーリングを全部やめ、Bedrock に投げると、運用エンジニアの工数とインフラ請求が同時に下がる。
そして本シリーズで何度も繰り返してきた「顧客データはモデルプロバイダーに共有されず、FM の学習にも使用されない」という Bedrock のデータ取り扱いポリシー（第 3 章・第 14 章で引用）が、製薬という規制業界で 採用の絶対条件として機能している。第 3 章で「OpenAI 直叩きから Bedrock への移行動機はデータ主権に収束する」と書いたが、Pfizer はその最たる例だ。
出典：Driving Patient-Centric Innovation in Life Sciences Using Generative AI with Pfizer（AWS Case Study）、Pfizer’s integration of Claude in Amazon Bedrock（Anthropic）
事例 7：United Airlines ── 50 年もののレガシーを Bedrock で翻訳する
United Airlines は航空業界の最高難度のレガシーフォーマットである PNR（Passenger Name Record）の翻訳に Bedrock を使った。PNR は 50 年以上前から存在する乗客情報の標準フォーマットで、独特の略号と独自の構文を持ち、人間でも読み解くのに訓練が必要だ。
これを 数か月の手作業でやっていたものを、Bedrock で自動翻訳に置き換えた。技術的にはモデルにフォーマット仕様と例を与えて翻訳させるだけで、特別に複雑なアーキテクチャは公表されていない。
この事例の価値は「Bedrock の使い方の中で最も地味で、最も再現性が高い」点にある。RAG も Agent もなく、Converse API での単純な変換タスクだ。第 6 章で書いた最初の InvokeModel / Converse API 呼び出しが、巨大企業の現実の問題を年単位で解いている。
ハードな AI 機能ばかりに目が行きがちだが、「手作業の翻訳・分類・抽出を Bedrock に置き換える」だけで価値が出るユースケースは社内に大量に眠っている。読者が自分の現場を見直す出発点として、この事例は最も使いやすい。
その他、海外事例で押さえておくべきもの
| 企業 | 業界 | 用途 | 特徴 |
|---|---|---|---|
| Toyota Motor Europe | 自動車 | メインフレームレガシーコード文書化 | レガシー保守の属人化解消 |
| Audi | 自動車 | 溶接接合部 AI 品質検査 | ほぼ全数検査を実現 |
| Fujitsu | IT サービス | サプライチェーン Agent | Guardian Agent パターン |
Audi の品質検査は、人間が抜き取りでしか確認できなかった溶接接合部を AI で「ほぼ全数検査」するところまで持っていった事例で、品質保証プロセスそのものを書き換える性質を持つ。Fujitsu の Guardian Agent パターンは、第 17 章のアンチパターン章で扱う「エージェントを別エージェントで監視する」設計思想の代表例だ。
事例から読み取る 5 つの共通パターン
ここまでの 7 事例（深堀り）と 13 件の俯瞰表から、再現可能な共通パターンを 5 つ抽出する。
mindmap
root((成功事例の<br/>5 共通パターン))
階層モデル使い分け
意図理解=軽量
最終判断=高精度
ガードレール=高精度
PoC→本番への評価設計
Day 1 から評価
LLM-as-a-Judge
AgentCore Evaluations
データ主権が決め手
金融
医療
VPC + Geographic CRIS
AgentCore 移行
v1 RAG → v2 Agent
Memory / Identity / Runtime
2025-2026 トレンド
既存システム統合
人事 API
社内 Wiki
Slack/Drive/GitHubパターン 1：階層モデル使い分けが事実上のスタンダードになっている
住信 SBI ネット銀行が「意図理解 = 軽量」「ガードレール = 高精度」、セゾンテクノロジーが「クエリ生成 = Haiku」「回答生成 = Command R+」、AWS 公式実測で Intelligent Prompt Routing が「RAG で 63.6 % 削減、87 % が Haiku ルーティング」。
これらが指す結論は一致している：「Sonnet で全部叩く」は最適解ではなく、「軽量モデルでハンドリングし、判断が必要なところだけ高精度モデルに任せる」のが現実的なアーキテクチャだ。第 5 章で示した選定基準を、これらの事例が実装の数値で裏付けている。
パターン 2：PoC → 本番の壁は「評価設計」で越える
メックは AWS ハッカソンを起点に 3 週間で PoC を構築した。BTM は調査時間を 半日 → 10 分に圧縮した。これらが本番運用に進めたのは、PoC の段階で 「定量的に良くなった」と説明できる評価軸を持っていたからだ。
PoC が止まる現場の典型は「動いた、すごい、で終わる」パターン。Production に進む現場は **「Knowledge Bases 比 +22 %」「研修期間 30 % 短縮」「情報探索 83 % 改善」**のように、ベースライン比較の数値を持っている。第 12 章で扱った Day 1 評価の重要性が、ここでも形になっている。
パターン 3：データ主権が金融・医療で決め手になっている
Pfizer がインフラコスト 55 % 削減を達成した背景には、Bedrock のデータ取り扱いポリシー（モデルプロバイダーに渡さない・学習に使わない）がある。みずほ銀行は PrivateLink + 大阪リージョンでデータレジデンシー要件に対応した。
第 3 章で「データ取り扱いポリシーが他社サービスとの最大の設計差」と書いたが、これは机上の話ではなく 金融・医療・製薬では Bedrock 採用の絶対条件として機能している。「OpenAI で十分」と言える業界と、構造的にそうは言えない業界がある。業界の規制要件が、AI 基盤の選定を決めている。
パターン 4：2025〜2026 年は AgentCore への移行トレンドが本格化
NTT ドコモ・住信 SBI ネット銀行・メック・Toyota Motor North America のすべてが AgentCore を本番採用している。AgentCore は 2025 年 7 月 Preview、10 月 GA という新しいサービスだが、Bedrock Agents から AgentCore への移行が 2025〜2026 年の主要トレンドになっている。
理由は単純で、自前で書くとつらいもの（認証・ステート・観測・スケール）が全部マネージドになるから。第 10 章で示した「Bedrock Agents の限界」を、現場が実感した結果として AgentCore に流れている。これから新規に Agent を作る場合、AgentCore からスタートするのが事実上のデフォルトになりつつある。
パターン 5：既存システムとの統合が価値の源泉
パイオにゃんが情報探索 83 % 改善を達成できたのは Slack・Drive・GitHub への統合があったから。住信 SBI ネット銀行の NEOBANK ai が銀行業務として成り立つのは API Gateway 経由で既存の銀行システムと配管されているから。Toyota v2 が「ローカル在庫確認」を実現できるのは Dealer Management System との Identity 統合があるから。
Bedrock の価値は孤立したチャットボットではなく、Action Groups や Tool Use 経由で既存システムに配管された Agent から生まれる。第 9 章の Action Groups、第 10 章の AgentCore Identity / Gateway がここで効いてくる。spec.md で定義した架空アプリ「helpdesk-ai」が 人事 API・社内 Wiki と連携する設計になっているのも、この共通パターンを意識したものだ。
5 パターンを設計判断のマトリクスに整理する
最後に、これら 5 パターンを「いつ・どこで意識すべきか」のマトリクスにまとめる。
| パターン | 意識すべき設計フェーズ | 関連する本シリーズの章 |
|---|---|---|
| 1. 階層モデル使い分け | Part 2（モデル選定 + 実装） | 第 5 章、第 15 章 |
| 2. PoC → 本番の評価設計 | Part 3（評価・観測） | 第 12 章、第 13 章 |
| 3. データ主権 | Part 1（位置付け）+ Part 3（セキュリティ） | 第 3 章、第 14 章 |
| 4. AgentCore 移行 | Part 2（Agent 構築） | 第 9 章、第 10 章 |
| 5. 既存システム統合 | Part 2（Tool Use・Action Groups） | 第 7 章、第 9 章、第 10 章 |
このマトリクスは、自分の現場の状況に応じて「今、どのパターンを優先するべきか」の判断に使える。例えば「金融機関で社内向け RAG を作る」なら 3 → 2 → 1、「メディア企業で生産性ツールを作る」なら 5 → 1 → 2、のように。
次章への接続
成功事例には共通の構造があり、それを 5 パターンに圧縮することができた。だが当然ながら、Bedrock の現場には成功事例と同じ数だけ失敗事例がある。AWS 公式ブログ・classmethod の DevelopersIO・サードパーティのコスト分析記事は、「こうやって失敗した・こう直した」の蓄積で埋まっている。
第 17 章では、これらの失敗から 9 つのアンチパターンを抽出する。「不要な Provisioned Throughput 購入で月数十万円の損失」「max_tokens 未設定でスロットリング多発」「Guardrails 後付けで本番障害」── 本シリーズの中でも最も「読んで防げる損失」が多い章になる。
成功事例は希望を与え、アンチパターンは事故を防ぐ。両輪が揃って初めて Production Ready の地図が完成する。
章末まとめ
- 国内 4 件（住信 SBI / セゾン / NTT ドコモ / 情報戦略テクノロジー）と海外 3 件（Toyota / Pfizer / United）を深堀りし、設計判断のテンプレートを抽出した
- 共通パターン 1：階層モデル使い分けが事実上のスタンダード。Haiku でハンドリング、Sonnet で判断
- 共通パターン 2：Day 1 からの評価設計が PoC → 本番の壁を越える鍵。「+22 %」「83 % 改善」のような数値が説明力になる
- 共通パターン 3：データ主権が金融・医療で決め手。Bedrock 採用の絶対条件として機能
- 共通パターン 4：Bedrock Agents から AgentCore への移行が 2025〜2026 年の主要トレンド。Toyota v1→v2 が典型
- 共通パターン 5：既存システム統合が価値の源泉。チャットボット単体ではなく、配管された Agent から成果が出る
- 次章では、成功事例の裏側にある 9 つのアンチパターンを扱う