本記事では、Amazon BedrockのAgents（エージェント）とFlows（フロー）の違いと使い分けを整理します。 「とりあえずエージェントを作ってみたけど、フローと何が違うの？」「どちらから使い始めればいい？」といった疑問を解消するのがゴールです。
公式ドキュメントでは、以下のように定義されています。
◎エージェント： 「FM・データソース・アプリケーション・ユーザー会話のオーケストレーションを行い、ユーザーのタスクを自動化するコンポーネント」
◎フロー： 「ノードをつないで生成AIワークフローを構築する仕組み」
本記事では、この2つを以下の住み分け整理していきます。
「タスク遂行の担い手」＝Agent 「アプリ全体の流れをつなぐ司令塔」＝Flows
1. Amazon Bedrock Agentsとは？：タスクを自律的にこなす「実務担当者」
Amazon Bedrock Agentsは、ユーザーの自然言語によるリクエストを理解し、必要に応じてAPIを呼び出したり、ナレッジベースに問い合わせたりしながら、タスクを自律的にこなすコンポーネントです。
公式ドキュメントを要約すると、エージェントの特徴は次の通りです。
- 自然言語で指示すると、FM（基盤モデル）が意図を理解しタスクを分解してくれる
- アクショングループを通じて、社内システムや外部APIを自動的に呼び出せる
- ナレッジベースと連携して、社内ドキュメントを検索・要約しながら回答できる
- ユーザーとマルチターンの会話を行い、足りない情報を質問しながら手続きを進められる
- Guardrailsや暗号化・IAMロールなど、セキュリティ・ガバナンスと統合されている
イメージとしては、「問い合わせ〜判断〜システム操作までを一気通貫でやってくれる高度なチャットボット」です。 「請求を手伝って」「旅行の予約をして」「契約情報を更新して」といった業務を、 ユーザーとの対話を通じて自動化するユースケースに向いています。 エージェントが得意なことをもう少し具体的に書くと、次のようになります。
- 対話の文脈理解：ユーザーの発話履歴を踏まえて意図を理解し、会話を継続できる
- タスク分解：大きな依頼を「情報ヒアリング」「検証」「API実行」「結果説明」といったステップに自動分解
- ツール呼び出し：アクショングループ経由でLambdaや社内APIを呼び、実際の処理を実行
- ナレッジ参照：FAQ・マニュアル・規程集などのドキュメントを参照して回答精度を上げる
つまり、エージェントは「ユーザーに寄り添って仕事を進める、フロント寄りのAIワーカー」だと捉えると分かりやすいです。
2. Amazon Bedrock Flowsとは？：サービス全体をつなぐ「オーケストレーター」
Amazon Bedrock Flowsは、複数のFM（基盤モデル）、エージェント、ナレッジベース、Guardrails、Lambda、Lexなどをノードとしてつなぎ、1つのエンドツーエンドなワークフローに仕立てるための機能です。
公式には、フロー・ノード・コネクションが基本概念として定義されています。
- Flow：ノードの集合と、それらを結ぶ接続のセット。入力が最初のノードに入り、最後の出力ノードまで処理が流れるパイプライン。
- Node：FM呼び出し・エージェント呼び出し・ナレッジベース呼び出し・条件分岐・ループなど、フロー中の1ステップ。
- Connection：ノード間のつながり。フローの制御の流れ（どのノードのあとにどのノードを実行するか）を決める。
Flowsは、ドラッグ&ドロップのビジュアルビルダーでワークフローを組み立てられる点も大きな特徴です。Prompts、Agents、Knowledge bases、Guardrails、Lambdaなどをつなぎ、コードを書かずに生成AIアプリの流れを定義できます。
まとめると、Flowsは次のような特性を持つと整理できます。
- 複数コンポーネントの接着剤：FM・エージェント・ナレッジベース・AWSサービスをひとつのフローとして統合
- 視覚的なワークフロー設計：条件分岐・ループ・並列処理などをノーコードで構成
- A/Bテストやバージョン管理：複数バージョンのフローを用意して切り替え・検証がしやすい
- APIとしての公開：作成したフローをAPI経由で呼び出し、既存アプリから再利用可能
イメージ的には、「生成AI機能を組み込んだStep Functions」あるいは「AIワークフロー専用のオーケストレーター」のような立ち位置です。
3. AgentsとFlowsの役割の違いを一枚で整理
ここまでの内容を、設計時に意識したい観点ごとに整理すると次の表のようになります。
| 観点 | Bedrock Agents | Bedrock Flows |
|---|---|---|
| 主な役割 | ユーザーの意図を理解し、対話しながらタスクを遂行する「AIワーカー」 | 複数のFM・エージェント・AWSサービスをつないで全体フローを制御する「オーケストレーター」 |
| 粒度 | 1つの業務タスク（例：見積取得、契約変更、FAQ回答） | サービス全体や業務プロセス全体（例：問い合わせ受付〜審査〜結果通知） |
| インターフェース | チャットUIや音声インターフェースからの自然言語入力がメイン | バックエンドAPIからの呼び出しがメイン（フロントから直接叩くことも可能） |
| 得意なこと | 会話・タスク分解・API呼び出し・ナレッジ参照 | 条件分岐・マルチステップ処理・複数エージェント/FMsの連携 |
| 設計の視点 | 「このエージェントにどんな仕事を任せるか」を定義 | 「アプリ全体の流れの中で、どこで誰（どのエージェント/FMs）に何をさせるか」を定義 |
| 代表的な利用例 | カスタマーサポートBot、申込手続きBot、FAQ Botなど | 問い合わせ分類→適切なエージェント呼び出し→結果をまとめて通知 など |
4. どんなときにエージェント単体を使うべきか？
まずは、「エージェントだけで完結させた方がよい」典型パターンを見ていきます。 共通するのは、「1つの会話の中で完結するタスク」であることです。
エージェント単体が向いているケースの例：
- FAQチャットボット 社内規程・商品仕様・マニュアルなどをナレッジベースに入れ、エージェントが検索＋要約して回答するケース。
- 1つのAPIで完結する業務 「このIDの契約情報を表示して」「このユーザーの請求書をPDFで出して」といった、裏側で1〜2個のAPIを呼べば完結するタスク。
- シンプルな手続きフロー 住所変更・連絡先変更など、ヒアリング→確認→1つの更新API呼び出し、で終わるような業務。
- PoCフェーズのチャットUI とにかく早く会話型UIを立ち上げたい、まずはユーザーとの対話を試したいとき。
こうしたケースでは、エージェントにアクショングループとナレッジベースを紐づけるだけでも、かなりリッチな対話体験を構築できます。
逆に言うと、次のような要件が無いなら、無理にFlowsを使わずエージェントだけで十分なことが多いです。
- 複数のエージェントを切り替える必要はない
- 複雑な条件分岐・ループ・並列処理は不要
- 外部サービス連携は少数（1〜2システム程度）
- ワークフロー全体を他のチームと共有・再利用する必要が薄い
5. どんなときにFlowsを使うべきか？
一方、Flowsは「アプリ全体の流れが複雑になってきたとき」に真価を発揮します。特に以下のような要件がある場合は、Flowsの利用を前提に設計を検討するとよいです。
- 複数のエージェントを使い分けたい 例：問い合わせをまず分類エージェントにかけ、 ・請求関連 → 請求担当エージェント ・契約関連 → 契約担当エージェント ・テクニカルサポート → 技術サポートエージェント へ振り分けたい。
- FMとエージェントを組み合わせる必要がある 例：最初はFM単体で要約・分類させ、その結果をもとに特定エージェントを呼び出す、といった構成。
- Guardrails・ナレッジベース・Lambda・他AWSサービスを組み合わせたい 例：入力をGuardrailsで検査 → ナレッジベース検索 → エージェント呼び出し → Lambdaで後処理、という一連の流れ。
- A/Bテストやバージョン違いのワークフローを試したい 複数のフロー定義を作り、レスポンス品質やコストの観点で比較・検証したい場合。
- 「対話なし」のバックエンド処理にも生成AIを使いたい 例：バッチでの文書要約、ログ分析、レポート生成など、会話型でないワークフロー。
Flowsを使うと、「このタイミングでこのエージェントを呼ぶ」「この条件なら別のノードにつなぐ」といった制御を視覚的に設計できます。 結果として、業務担当者や他チームにとってもフロー構造が理解しやすくなり、変更の影響範囲も把握しやすくなります。
6. エージェント＋Flowsのハイブリッド構成例
実務では、エージェントだけ / Flowsだけというより、「Flowsの中でエージェントを呼ぶ」構成が強力です。AWS公式のサンプルでも、Flowsからエージェントやナレッジベースを呼び出すテンプレートが用意されています。
例えば、次のような構成が考えられます。
- Step 1：問い合わせ内容の理解（FMノード） ユーザーの入力をFMに渡し、「カテゴリ」「緊急度」「必要情報」などを抽出。
- Step 2：カテゴリに応じて分岐（条件ノード） ・請求関連 → 請求エージェント ・契約関連 → 契約エージェント ・システム障害 → ナレッジベース＋技術エージェント
- Step 3：各エージェントがタスク遂行 対話を通じて情報を補い、必要に応じてAPI・DB・アプリケーションを呼び出し。
- Step 4：結果を整形して返却（FM or Lambdaノード） 複数エージェントから返ってきた情報を整理し、ユーザー向けメッセージを生成。
このように、Flowsは「どのエージェント（またはFM）に話を振るか？」を決める司令塔として使い、エージェントは「振られたタスクを遂行する専門家」として働かせると、設計が非常にきれいに整理できます。
7. 「エージェントかフローか」を決めるチェックリスト
実際に要件を聞きながら「エージェントだけでいくか、Flows前提で設計するか」を判断する際には、次のチェックリストが役立ちます。
- ① タスクは1種類か、複数種類か？ 1種類のタスクだけを自動化したい → エージェント単体から検討 複数のタスクを振り分けたい → Flows＋複数エージェントを検討
- ② 会話の有無・重要度は？ ユーザーとの対話が中心 → エージェントが主役 バッチ処理やシステム間連携が中心 → Flows主体で、必要に応じてエージェントを呼ぶ
- ③ 外部システムの数・複雑さは？ 1〜2システムに対する単純なAPI呼び出し → エージェントのアクショングループで十分 複数システムをまたぐ複雑なプロセス → Flowsでオーケストレーションした方が安全
- ④ 条件分岐・ループ・並列実行が必要か？ YesならFlowsの出番。Noならエージェントだけでも十分な可能性が高い。
- ⑤ どのチームが運用するか？ 開発者中心でコードベースの制御が好まれる → エージェント＋アプリ側ロジックでもOK 業務部門や他チームにもフローを見える化したい → Flowsでワークフローを可視化
8. システム構成イメージ：Webアプリでの典型パターン
Webアプリや社内ポータルでBedrockを使うケースを想定して、典型的な構成パターンをテキストで整理しておきます。
- パターンA：エージェント単体構成
- フロントエンド：React / Vue / SPAなどのWebアプリ
- バックエンド：API Gateway + Lambda（or 既存のAPIサーバ）
- AI部分：LambdaからBedrock Agents APIを叩く（またはAmplifyなどから直接呼び出し）
- 用途：FAQ Bot、簡単な手続きBot
- パターンB：Flows＋エージェント構成
- フロントエンド：Web/モバイル/LINE Botなど
- バックエンド：API Gateway + Lambda
- AI部分：LambdaからBedrock Flowsを呼び出し、フロー内でエージェントやFMノードを活用
- 用途：問い合わせ分類＋各種エージェント呼び出し、審査・承認フロー、複数部門横断の業務
- パターンC：非対話型のFlows構成
- トリガー：EventBridgeスケジュール、S3アップロード、アプリケーションからのAPI呼び出しなど
- AI部分：Flowsで「読み取り→要約→分類→レポート生成」を自動化
- 用途：日次レポート生成、ログ分析、ドキュメント自動レビューなど
「いきなり複雑なFlows構成を組む」のではなく、まずはエージェント単体でPoC → その後、Flowsで周辺コンポーネントをオーケストレーションするという段階的な導入もおすすめです。
9. 運用視点で押さえておきたいポイント
最後に、設計だけでなく運用を考えるうえで重要なポイントを、エージェント・Flows共通でまとめておきます。
- IAMロールと最小権限 エージェントやFlowsに紐づけるロールは、呼び出すAPI・サービスに対して最小権限になるよう設計します。
- コストとレイテンシ ノードやアクショングループが増えるほど呼び出し回数が増え、コスト・レイテンシが増加します。ログを見ながら「本当に必要な呼び出しだけ」に絞る設計が重要です。
- バージョン管理とデプロイ戦略 エージェントのエイリアスやFlowのバージョンを活用し、 ・開発環境 ・ステージング ・本番 を分けてロールアウトすると安全です。
- 監視・ロギング CloudWatch LogsやBedrockのトレース情報を活用し、「どのノード/アクションで時間やエラーが発生しているか」を可視化することで、チューニングが行いやすくなります。
- ガバナンス・コンプライアンス Guardrailsで入力/出力の制限をかける、ナレッジベースにpersonal dataを載せる範囲を明確にするなど、外部規約や規程との整合も早めに検討しておきましょう。
10. まとめ：まずは「誰にどんな仕事を任せるか」を決める
本記事では、Amazon BedrockのエージェントとFlowsの違いと使い分けを、設計視点で整理しました。
- エージェントは、ユーザーと対話しながらタスクをこなすAIワーカー
- Flowsは、複数のFM・エージェント・AWSサービスをつなぐオーケストレーター
- 単純なタスクならエージェント単体、複雑な業務プロセスならFlows＋エージェントのハイブリッドが有効
- 判断のポイントは、タスクの数・外部システムの複雑さ・条件分岐の多さ・関係者への見える化ニーズなど
最初の一歩としては、「このエージェントにどんな仕事を任せるか？」をシンプルに決めてPoCを行い、その後、必要に応じてFlowsによるオーケストレーションを追加していく進め方が現実的です。
今後、「Bedrock Flows Samples」などのテンプレートやサンプルコードも充実してきていますので、AWS公式リポジトリやドキュメントをうまく活用しながら、自社システムにフィットするアーキテクチャを検討してみてください。
コメント