ひとことで言うと
Bedrock の部品（プロンプト・Knowledge Base・エージェント・Guardrails）と AWS の部品（Lambda・S3・Lex）をノードとして並べ、出力と入力を線で繋いで1本のワークフローにするものです。完成したフローは版とエイリアスを持ち、アプリは InvokeFlow をエイリアスに投げるだけになります。
要するに、Bedrock 専用のパッチベイです。汎用のオーケストレータと違い、挿せる端子があらかじめ決まっている——プロンプト、ナレッジベース、エージェント、Lambda。その代わり配線は視覚的に引けて、ノード間のデータは $.name のような式で「全体の入力からどこを取るか」を書くだけで通ります。汎用性を捨てて、Bedrock の周りの配線だけを速くした道具です。
なぜ生まれたか
「プロンプトで意図を判定 → ナレッジベースを引く → 結果によって分岐 → Lambda で外部システムを叩く」という定型を、アプリのコードで書くと繋ぎ目の全部が自前になります。
| アプリのコードで書いていたこと | Flows に移すと |
|---|---|
| 各段の呼び出し・入出力の受け渡しを実装 | ノードを置いて出力と入力を線で繋ぐ。型は実行時に検証される |
分岐条件がコード内の if に散る | condition ノードとして1か所に集まり、図として読める |
| ワークフロー全体の版管理が無い（コードの版に混ざる） | フローがバージョン（不変のスナップショット）とエイリアスを持つ |
| 切り戻しがアプリのロールバック | エイリアスの向き先を旧バージョンに変えるだけ |
| ガードレールを各呼び出しに書き足す | prompt ノード / knowledge base ノードの設定として持てる |
公開日付を年表にできる記述が公式ドキュメント側に無いため、経緯の構造だけ置きます。作った瞬間に作業ドラフト（DRAFT）とテスト用エイリアス（TSTALIASID）ができ、そこから版を切って別のエイリアスで本番に出す——この2段構えが、上の表の後半をまとめて実現している仕掛けです。
何に使うか
ノードは「フローの筋道を制御するもの」と「データを扱うもの」に分かれます。どのノードがあるかを覚えているかどうかで、設問の選択肢の切り方が変わります。
| 分類 | ノード | 何をするか | 関連ドメイン |
|---|---|---|---|
| 制御 | Input | InvokeFlow の content を受ける。1フローに1つだけで、必ずここから始まる | D2 |
| 制御 | Output | 結果を返す。分岐があれば複数置ける | D2 |
| 制御 | Condition | 条件で送り先を変える。== != > >= < <= と and / or / not | D1 / D2 |
| 制御 | Iterator | 配列を1件ずつ下流に流す。arrayItem と arraySize を出す | D2 |
| 制御 | Collector | 反復してきた結果を配列（collectedArray）に畳み直す | D2 |
| 制御 | DoWhile | 条件が真の間ループ。最低1回は実行してから条件を見る | D2 |
| データ | Prompt | Prompt Management のプロンプト（promptArn）か、インライン定義のプロンプトを実行。出力は modelCompletion | D1 |
| データ | Knowledge Base | ナレッジベースに問い合わせる。modelId を書けば生成まで、省けば検索結果の配列が返る | D1 |
| データ | Agent | エージェントのエイリアス ARN を呼ぶ。マルチターンで追加入力を求めて一時停止できる | D2 |
| データ | Lambda | 任意のビジネスロジック。別アカウントの関数も呼べる | D2 |
| データ | Inline code | Python 3.12 のコードをその場で実行（プレビュー） | D2 |
| データ | S3 storage / S3 retrieval | S3 への書き出し・読み込み | D2 |
| データ | Lex | Lex ボットで発話の意図（predictedIntent）を判定 | D2 |
試験でどう問われるか
**D1.6 の末尾に「逐次チェーン・条件分岐・前後処理」として名指しされ、D2.5 では「ノーコードのアプリ統合パターン」として出ます。**最大の分岐は Flows か Step Functions かで、ここは選択肢の書き方で決まります。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| Flows か Step Functions か | 部品が Bedrock 中心（プロンプト・KB・エージェント）で、ビジュアルビルダー・ノーコード・低コードが要件に出る → Flows | 人間承認（HITL）・サーキットブレーカー・リトライ戦略・複雑な状態遷移が要件に出ているのに Flows を選ぶ（そちらは Step Functions の領分） |
| 「本番のワークフローを即座に前の挙動へ戻したい」 | エイリアスのルーティング設定を旧バージョンに向ける。バージョンは不変なので巻き戻しが安全 | 「ドラフトを編集して元に戻す」（ドラフトは可変なので、そもそも戻す先が無い） |
| 「フローが1時間で打ち切られる／もっと長く走らせたい」 | StartFlowExecution による非同期実行。ノード単位で最大5分、フロー全体で最大24時間 | InvokeFlow のタイムアウトを延ばす設定を探す（InvokeFlow は最長1時間で固定） |
| 「フロー内の有害出力をブロックしたい」 | prompt ノードと knowledge base ノードに guardrail を設定する。KB ノードは RetrieveAndGenerate（＝modelId 指定）のときだけ | Lambda ノードや condition ノードにガードレールを付ける案 |
| 「配列を処理してスループットを上げたい」 | Iterator は1件ずつ逐次処理。並列化の手段ではない（並列にしたいなら設計自体が別） | 「iterator ノードで並列処理する」 |
| 「複数の条件のうち2つが同時に成立したら？」 | 条件は定義順に評価され、先に書いた条件が勝つ | 「より具体的な条件が優先される」「両方の枝に流れる」 |
| 「ナレッジベースの生の検索結果を後段で加工したい」 | KB ノードの modelId を省くと retrievalResults が配列で返る | modelId を指定したまま検索結果だけ取り出そうとする案 |
| 「無限ループを防ぎたい」 | DoWhile の maxIterations（既定10） | condition ノードで自前のカウンタを組む案（DoWhile に上限が備わっている） |
| 「フローが途中で止まった。どのノードで何が入ったか見たい」 | ListFlowExecutionEvents を eventType=Node で叩き、中間ノードの入出力を見る（D5.2） | CloudWatch のメトリクスだけで原因を特定する案 |
1問拾える境目: フローには Flow input ノードが1つしか置けませんが、Flow output ノードは複数置けます（分岐した枝ごとに出口を作るため）。「入口も出口も1つ」「入口を複数置いて合流させる」はどちらも外れます。
実務でどう使うか
- 編集しただけでは反映されません。 変更を作業ドラフトに適用するために Prepare が要ります。テストは
TSTALIASID経由でドラフトに当たります - Inline code ノードは制約が多いプレビュー機能です。 Python 3.12 のみ／最後に実行された行の結果だけが出力（
printは拾われない）／入力は5つまで／1フローに5ノードまで／1アカウントで同時25ノードまで／コードは 5MB まで／インターネットアクセス無し／非同期のフロー実行では使えません - S3 retrieval ノードが読めるのは UTF-8 の文字列だけです。 バイナリを流す前提で設計すると詰まります
- Lex ノードはマルチターン非対応です。 1ノードで1発話しか処理できません。会話を続けたいなら Agent ノード側の仕事です
- 非同期実行はエイリアスが前提です。
StartFlowExecutionにはフロー ID とエイリアス ID を渡します。状態はRunning/Succeeded/Failed/TimedOut/Abortedの5つで、GetFlowExecutionをポーリングして終端に達したらListFlowExecutionEventsで結果を取ります - 走行中にフロー定義を書き換えられるので、スナップショットが取られています。 デバッグ時は
GetExecutionFlowSnapshotで「その実行が実際に使った定義」を取れます。実行中に直した定義と突き合わせて悩まないで済みます - 終了した非同期実行は90日で自動削除されます。 監査目的で残すなら自分で S3 等に落とす設計が要ります
課金の主語がフローではありません。Flows の料金はフローが使ったリソース側で発生します——prompt ノードがモデルを呼べばそのモデルの料金、Lambda ノードを叩けば Lambda の料金。「フローを1本作って置いておく」こと自体ではなく、1回のフロー実行が何回モデルを呼ぶかがコストの単位です。DoWhile と Iterator は、この呼び出し回数を静かに掛け算します。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| AWS Step Functions | Flows は Bedrock の部品を繋ぐ専用の配線盤。Step Functions は AWS 全体の汎用の状態機械で、HITL・サーキットブレーカー・ReAct 実装のような込み入った制御はそちら |
| Amazon Bedrock Prompt Management | あちらは部品1個（プロンプト＋推論設定）、こちらは部品を繋ぐ配線。prompt ノードから promptArn で参照する片方向の関係 |
| Bedrock のエージェント | エージェントは経路をモデルが決める。Flows は経路を設計者が固定する。再現性が要るならフロー、判断が要るならエージェント |
| Amazon Bedrock AgentCore | 手順が決まった工程を組むのが Flows。AgentCore はエージェントを動かす実行基盤側の話で、層が違う |
| Amazon Bedrock Guardrails | Guardrails は単体では検閲器でしかない。Flows はそれをノードの設定として組み込む器（prompt / knowledge base ノードのみ） |
| AWS Lambda 単体 | 「Lambda ノードがある」ので混同しやすいが、Flows が持っているのはノード間の型検証・分岐・版とエイリアス。Lambda を並べただけでは、この4つが全部自前になる |
想起チェック
Q1. Flows と Step Functions を分ける決め手は何ですか。
要件に出てくる部品と制御の重さです。Bedrock の部品中心でノーコード・ビジュアル構築が求められるなら Flows、人間承認・サーキットブレーカー・複雑なリトライや状態遷移が要るなら Step Functions です。
Q2. 本番のフローを1つ前の挙動に戻す最短手は？
エイリアスの向き先を旧バージョンに変えることです。バージョンは不変のスナップショットなので、ドラフトを編集して戻す必要がありません。
Q3. フロー内でガードレールを設定できるノードは？ また、KB ノードで付けられる条件は？
prompt ノードと knowledge base ノードだけです。KB ノードは RetrieveAndGenerate を使うとき（＝modelId を指定して生成させるとき）に限られます。
Q4. `InvokeFlow` で足りず `StartFlowExecution` が要るのはどんなときですか。
1時間を超える処理のときです。InvokeFlow は最長1時間で打ち切られ、非同期のフロー実行ならノード最大5分・全体最大24時間まで走ります。ただし inline code ノードは非同期実行では使えません。