--- title: "Amazon Bedrock Flowsとは｜ノード14種・料金・上限とboto3実装【2026年最新】" url: "https://www.issoh.co.jp/tech/details/3376/" published: 2024-08-22 updated: 2026-08-01 categories: ["AWS"] publisher: "株式会社一創" --- # Amazon Bedrock Flowsとは｜ノード14種・料金・上限とboto3実装【2026年最新】 Amazon Bedrock Flowsは、プロンプト・エージェント・ナレッジベース・Lambda関数をノードとして線でつなぎ、生成AIのワークフローを組み立てる機能です。2024年7月にプレビュー公開された当時の名称は「Prompt Flows」でしたが、2024年11月22日の一般提供（GA）に合わせてAmazon Bedrock Flowsへ改称されました。名称だけでなく課金方式も2025年2月に切り替わっているため、プレビュー期の解説記事をそのまま参照すると見積もりを外します。ここでは14種類のノード、ノード遷移にもとづく課金の計算、設計を縛るクォータ上限、boto3での実装までを公式ドキュメントの記述に沿って整理します。 ## まとめ Amazon Bedrock Flowsの要点は次のとおりです。旧称Prompt Flowsとは同一機能で、2024年11月22日のGAで改称されました。利用できるノードは入出力・条件分岐・反復といったロジック系と、プロンプトやLambda関数などのデータ処理系を合わせて14種類です。料金は2025年2月1日から「ノード遷移（node transitions）1,000回あたり0.035ドル」が加わり、これに基盤モデルの推論料金とS3などの利用料が別途かかります。設計上いちばん効いてくる制約は1フローあたりの総ノード数40で、この値は引き上げできません。実行はInvokeFlowによる同期呼び出し（最大1時間）と、プレビュー段階のフロー実行（全体最大24時間）の2系統に分かれます。 以降では、改称で何が変わったのか、ノードをどう選ぶのか、費用と上限をどう見積もるのかを順に見ていきます。 ## 旧称Prompt Flowsからの改称とGAでの機能追加 ### 旧称Prompt Flowsとの関係 AWSは一般提供の告知で本機能を「previously known as Prompt Flows」と説明しており、プレビュー期のPrompt Flowsと現在のFlowsは同じ機能です。既存のフロー定義を作り直す必要はありません。ただし公式ドキュメントの用語はFlowsに統一されているため、検索で「Prompt Flows」の解説にたどり着いた場合は、その内容が2024年後半以前の仕様である可能性を疑ってください。特に料金の記述は、後述する2025年2月の課金開始より前のものだと結論が変わります。 ### GAで追加された安全性とトレース機能 一般提供のタイミングでは、安全性と可観測性に関わる機能が加わりました。まずプロンプトノードとナレッジベースノードでAmazon Bedrock Guardrailsを適用できるようになっています。ナレッジベースノードについては、公式ドキュメントが「Guardrails can only be applied when using `RetrieveAndGenerate` in a knowledge base node」と明記しており、検索結果を配列でそのまま返す使い方ではガードレールが効きません。 可観測性の面では、入力ノードと出力ノードのトレースが取得できるようになり、各ノードの入出力・実行時間・エラーを実行経路に沿って追えます。ビジュアルビルダー上ではノードの妥当性がその場で色分け表示され、接続の不備を実行前に見つけられます。Bedrock全体の課金体系やモデルの選び方を先に押さえたい場合は、[Amazon Bedrockの使い方｜料金・モデル・APIの始め方を4ステップで解説【2026年版】](/tech/details/2942/)が入口になります。 ## ノード14種の役割と選び分け ノードは「フローの制御を担うロジック系」と「データを処理し外部と連携するデータ系」に分かれ、ユーザーガイドの掲載は合計14種類です。なお、API Referenceの`FlowNode`の`type`有効値は16個あり、後述のDoWhileループはAPI上では`Loop`・`LoopInput`・`LoopController`の3型に分かれています。コンソールで組む場合とAPIで定義する場合で名称が一致しない箇所なので、定義をコード管理するなら有効値のほうを基準にしてください。 ### フロー制御に使うロジック系ノード | ノード | 役割 | フローあたり上限 | | --------- | -------- | --------- | | Input | フローの起点 | 1 | | Output | フローの終点 | 20 | | Condition | 条件分岐 | 5 | | Iterator | 配列の逐次展開 | 1 | | Collector | 反復結果の再集約 | 1 | | DoWhile | 条件付き反復 | 公式クォータ未定義 | 入力ノードはInvokeFlowリクエストの`content`を受け取る起点で、フローに1つだけ置けます。出力ノードは終点で、分岐がある場合は経路ごとに複数置けます。条件ノードで注意したいのは評価順です。公式ドキュメントは「Conditions are evaluated in order. If more than one condition is satisfied, the earlier condition takes precedence.」と述べており、複数の条件が同時に成立する場合は先に定義したものが勝ちます。条件は1ノードにつき5個までなので、分類の粒度が細かい振り分けは条件ノードを直列に並べるか、Lambda関数ノードへ寄せる設計になります。 反復処理はイテレータ／コレクタの組と、2025年9月に追加されたDoWhileループノードで性格が異なります。イテレータは配列の各要素を順に処理する用途で、要素は並列ではなく逐次に処理されます。DoWhileは条件が真である限り同じ処理を繰り返す用途で、条件評価の前に必ず1回実行される点が特徴です。無限ループを避けるための`maxIterations`は既定値が10で、正の数のみ指定できます。生成結果を評価して基準に達するまで書き直させる、といった品質のつくり込みはDoWhileの守備範囲です。 ### データ処理と外部連携に使うノード データ系は8種類です。接続を組むときは、各ノードが返す出力名が固定されている点を先に把握しておくと迷いません。 | ノード | APIのtype | 固定の出力名 | | -------- | -------------- | --------------------------- | | プロンプト | Prompt | modelCompletion | | エージェント | Agent | agentResponse | | ナレッジベース | KnowledgeBase | retrievalResults／outputText | | S3ストレージ | Storage | s3Uri | | S3取得 | Retrieval | s3Content | | Lambda関数 | LambdaFunction | functionResponse | | インラインコード | InlineCode | response | | Lex | Lex | predictedIntent | 日本語名とAPIの`type`が直結しないのはS3系の2つなので、定義をコードで書くときは表の中央列を参照してください。プロンプトノードはPrompt managementに保存した資産を参照する方式と、ノード内にインラインで書く方式のどちらも選べます。エージェントノードはBedrockのエージェントを呼び出すもので、情報が足りないときにフローを一時停止してユーザーへ追加入力を求めるマルチターン呼び出しに対応します。この挙動を使う場合、後述するInvokeFlowのサンプルのように結果を受け取って終わりにはできず、追加入力を要求するイベントを受け取って再度呼び出す実装が必要になります。 Lexノードは公式ドキュメントが「Currently, the Lex node doesn’t support multi-turn conversations. One Lex node can only process one utterance.」と明記しており、1ノードで扱えるのは1発話だけです。対話の往復が必要ならLexではなくエージェントノードを選んでください。S3取得ノードには「the data in the S3 location must be a UTF-8 encoded string」という制約があり、バイナリやUTF-8以外のエンコードのファイルはそのまま読み込めません。Lambda関数ノードは任意のビジネスロジックを挟む口で、Bedrockが送る入力イベントには`messageVersion`、フローのARN、ノード名と各入力の解決済みの値が含まれます。 プロンプトそのものの精度やコストを詰める手段はフローの外側にもあります。冗長なプロンプトを機械的に整える方法は[Amazon Bedrockのプロンプト最適化機能の詳細と利用方法](/tech/details/4318/)で、同一の前置きを繰り返し送る構成の費用削減は[Amazon Bedrockのプロンプトキャッシュとは｜仕組み・対応モデル・料金・実装方法【2026年最新】](/tech/details/4764/)で扱っています。 ### プレビュー段階のノードを本番に載せる判断 インラインコードノードは、Lambda関数を用意せずにフロー内へ直接コードを書ける機能ですが、公式ドキュメントに「Inline code node is in preview release for Amazon Bedrock and is subject to change」と明示されたプレビュー機能です。仕様変更が前提であることに加えて、次の制約が実務に効きます。 - 使える言語はPython 3.12のみです - 返るのは最後に実行した行の結果だけで、コンソール出力は捕捉されません - 入力は最大5個、インラインコードノードはフローあたり5個までです - 1つのAWSアカウントで同時に実行できるのは25ノードまでです - コードは5MBを超えられず、実行環境にインターネット接続はありません - 後述する非同期のフロー実行では利用できません デバッグ時に効いてくるのが2番目の制約です。Pythonの`print`で書いた内容はどこにも残らないため、途中経過を見たいなら結果を辞書にまとめて最終行に置く必要があります。短いデータ整形であればインラインコードで十分ですが、外部APIを叩く、依存ライブラリを使う、非同期実行に載せる、のいずれかに該当するならLambda関数ノードを選んでください。プレビュー機能をクリティカルパスに置くと、仕様変更のたびにフロー全体の再検証が必要になります。 ## フロー作成からエイリアス公開までのboto3実装 コンソールで組む場合は、ナビゲーションペインの「Amazon Bedrock Flows」からフローを作成し、ノードをドラッグ＆ドロップで配置して出力と入力を線でつなぎ、テストウィンドウの実行で挙動を確かめ、バージョンとエイリアスを作って公開する、という流れになります。ただし環境間で同じフローを再現するならAPIで定義したほうが確実です。作成系のAPIはビルドタイムエンドポイントの`bedrock-agent`、実行はランタイムエンドポイントの`bedrock-agent-runtime`と、クライアントが分かれます。 次はジャンルと曲数を受け取ってプレイリストを生成する最小構成で、入力ノード・プロンプトノード・出力ノードの3つだけを持つフローです。 ``` import boto3 client = boto3.client(service_name='bedrock-agent') FLOWS_SERVICE_ROLE = "arn:aws:iam::123456789012:role/MyFlowsRole" input_node = { "type": "Input", "name": "FlowInput", "outputs": [{"name": "document", "type": "Object"}] } prompt_node = { "type": "Prompt", "name": "MakePlaylist", "configuration": { "prompt": { "sourceConfiguration": { "inline": { "modelId": "amazon.nova-lite-v1:0", "templateType": "TEXT", "inferenceConfiguration": {"text": {"temperature": 0.8}}, "templateConfiguration": { "text": {"text": "Make me a {{genre}} playlist consisting of the following number of songs: {{number}}."} } } } } }, "inputs": [ {"name": "genre", "type": "String", "expression": "$.data.genre"}, {"name": "number", "type": "Number", "expression": "$.data.number"} ], "outputs": [{"name": "modelCompletion", "type": "String"}] } output_node = { "type": "Output", "name": "FlowOutput", "inputs": [{"name": "document", "type": "String", "expression": "$.data"}] } # 入力ノードの出力を、プロンプトノードの各入力へつなぐ connections = [] for node_input in prompt_node["inputs"]: connections.append({ "name": "_".join([input_node["name"], prompt_node["name"], node_input["name"]]), "source": input_node["name"], "target": prompt_node["name"], "type": "Data", "configuration": {"data": { "sourceOutput": input_node["outputs"][0]["name"], "targetInput": node_input["name"] }} }) # プロンプトノードの出力を、出力ノードの入力へつなぐ connections.append({ "name": "_".join([prompt_node["name"], output_node["name"]]), "source": prompt_node["name"], "target": output_node["name"], "type": "Data", "configuration": {"data": { "sourceOutput": prompt_node["outputs"][0]["name"], "targetInput": output_node["inputs"][0]["name"] }} }) response = client.create_flow( name="FlowCreatePlaylist", executionRoleArn=FLOWS_SERVICE_ROLE, definition={"nodes": [input_node, prompt_node, output_node], "connections": connections} ) flow_id = response.get("id") ``` 各ノードの`expression`は、丸ごと届いた入力から必要な部分だけを取り出すJSONPath風の指定です。`$.data.genre`のように書くと、入力オブジェクトの該当キーだけがそのノードの入力値になります。`connections`には、どのノードのどの出力をどのノードのどの入力へつなぐかを`sourceOutput`と`targetInput`で列挙します。`executionRoleArn`に渡すのはフローの操作を代行させるサービスロールで、必要な権限はAWS公式ドキュメントのFlows用サービスロールの項に一覧があります。ここを用意せずに実行すると作成の時点で失敗します。 作成しただけでは実行できません。作業中のドラフトを反映し、スナップショットとなるバージョンを固定し、そのバージョンを指すエイリアスを作る、という3段階を踏みます。 ``` client.prepare_flow(flowIdentifier=flow_id) flow_version = client.create_flow_version( flowIdentifier=flow_id ).get("version") flow_alias_id = client.create_flow_alias( flowIdentifier=flow_id, name="latest", description="Alias pointing to the latest version of the flow.", routingConfiguration=[{"flowVersion": flow_version}] ).get("id") ``` エイリアスはフローあたり10個、バージョンも10個までです。本番用と検証用のエイリアスを分けておくと、アプリケーション側のコードを変えずに参照先バージョンだけを切り替えられます。 ## InvokeFlowと非同期フロー実行の使い分け ### 同期実行のInvokeFlow 公開したフローを呼び出す基本形が`invoke_flow`です。レスポンスはイベントストリームとして返るため、逐次受け取って結合します。 ``` client_runtime = boto3.client('bedrock-agent-runtime') response = client_runtime.invoke_flow( flowIdentifier=flow_id, flowAliasIdentifier=flow_alias_id, inputs=[{ "content": {"document": {"genre": "pop", "number": 3}}, "nodeName": "FlowInput", "nodeOutputName": "document" }] ) result = {} for event in response.get("responseStream"): result.update(event) if result['flowCompletionEvent']['completionReason'] == 'SUCCESS': print(result['flowOutputEvent']['content']['document']) else: print("completionReason:", result['flowCompletionEvent']['completionReason']) ``` 成否は`flowCompletionEvent`の`completionReason`で判定し、本文は`flowOutputEvent`の`content`から取り出します。InvokeFlowは同期呼び出しで、フローが完了するか1時間でタイムアウトするかのいずれか早いほうまで待ちます。単発のモデル呼び出しだけで足りる処理までフローに載せる必要はなく、その場合は[Amazon Bedrock Converse APIの使い方｜boto3実装・ConverseStream・Tool Use・IAM権限【2026年最新】](/tech/details/2391/)のほうが構成要素が少なく済みます。 ### 非同期のフロー実行（プレビュー） 1時間を超える処理や、呼び出し側を待たせたくない処理にはフロー実行を使います。`StartFlowExecution`で開始し、返ってきた`executionArn`を使って`GetFlowExecution`で状態を追う方式です。実行時間の上限は個々のノードが5分、フロー全体で24時間まで広がります。状態はRunning、Succeeded、Failed、TimedOut、Abortedの5つで、24時間を超えた実行はTimedOutになります。 デバッグ時は`ListFlowExecutionEvents`が有効です。`eventType`にNodeを指定すると中間ノードを含む全ノードの入出力がタイムスタンプ付きで並び、どのノードで値が壊れたかを追えます。実行中にフロー定義が更新される可能性があるため、開始時点の定義は`GetExecutionFlowSnapshot`で取得できます。ただしフロー実行自体がプレビューであり、終了した実行は90日で自動削除されるので、監査ログとして残したい情報は自前で退避してください。 ## ノード遷移にもとづく課金の見積もり方 プレビュー期のFlowsには機能自体の課金がなく、基盤モデルの推論料金だけを見ておけば済みました。2025年2月1日からこれが変わり、ノード遷移（node transitions）1,000回あたり0.035ドルが加算されます。AWSの料金ページはノード遷移の厳密な定義を示していないため、見積もりは公式の計算例に合わせるのが確実です。 その計算例では、1回のフロー実行で25回の遷移が発生する構成を、1時間あたり2回、24時間、週5日、4週間で合計960回実行しています。25×960×0.035÷1,000で月額0.84ドルです。フロー機能そのものの費用は、この規模ではほぼ無視できる水準に収まります。 金額を押し上げるのは併用するサービスのほうです。プロンプトノードとエージェントノードが呼ぶ基盤モデルの推論料金、S3ノードのストレージとリクエスト料金、Lambda関数ノードの実行料金が別建てで乗ります。見積もりで効くのは遷移回数そのものより、イテレータやDoWhileで反復するたびにモデル推論が走る箇所です。反復回数×1回あたりのトークン数が実質的なコストドライバーになるので、`maxIterations`は既定の10のまま放置せず、用途に見合う値へ絞ってください。なお対応リージョンと利用できるモデルはBedrock本体の提供状況に連動して増減するため、採用前に公式のサポート対象一覧で最新の状況を確認してください。 ## 設計を縛るクォータ上限 Flowsのクォータは大半が引き上げ不可です。フローを設計してから上限に当たると作り直しになるため、着手前に確認しておく価値があります。 | クォータ | 既定値 | 引き上げ | | --------------------- | ----- | ---- | | 総ノード数／フロー | 40 | 不可 | | プロンプトノード／フロー | 20 | 可 | | エージェント／ナレッジベース／Lambda | 各20 | 不可 | | 条件ノード／フロー（条件は1ノード5個） | 5 | 不可 | | S3ストレージ／S3取得 | 各10 | 不可 | | フロー／アカウント | 100 | 可 | | フロー実行／アカウント | 1,000 | 可 | 最初にぶつかるのは総ノード数40です。プロンプトノード単体では20まで置けても、入出力・条件・Lambdaを含めた合計が40を超えられません。イテレータとコレクタが各1という制限も見落としがちで、配列処理を2箇所で行う設計は素直には組めません。この場合は配列処理をLambda関数ノードへ寄せるか、フローを分割してエージェントノード経由で呼び分ける構成に変えます。 ## Bedrock AgentsとStep Functionsとの使い分け Flowsは万能な選択肢ではありません。処理の順序があらかじめ決まっていて、その順序を非エンジニアも含めて図として共有したい場合に最も効きます。次に何をするかをモデル自身に判断させたいなら、それはFlowsではなくBedrock Agentsの領域です。Flowsのエージェントノードは、決まった流れの一部としてエージェントを呼ぶための口であって、フロー全体の制御をモデルに委ねる仕組みではありません。エージェントを本番運用する構成については[Amazon Bedrock AgentCore APIの使い方｜SDK・CLIでAIエージェントを本番デプロイ【2026年最新】](/tech/details/8230/)で扱っています。 Flowsを採用すべきでない場面は具体的に挙げられます。ノード数が40に収まらない大規模なパイプライン、リトライやバックオフの制御を細かく設計したい処理、生成AIの呼び出しが全体のごく一部しかない業務フロー、この3つに当てはまるならAWS Step Functionsで組んでBedrockの呼び出しだけをタスクとして埋め込むほうが適します。Flowsの価値はノーコードで生成AIワークフローを組める点にあり、その利点は上限40という枠の内側でしか成立しないためです。 プロンプトの試行錯誤が主で分岐も数えるほど、という段階でStep Functionsを持ち出すと、フローを1つ直すたびに定義とデプロイの往復が発生します。改訂頻度が高い立ち上げ期はFlowsで回し、処理が固まってノード数が上限に近づいた時点でStep Functionsへ移す、という順序が現実的です。 ## よくある質問 ### Prompt Flowsという名前は今も使えますか 機能としては同一のもので、2024年11月22日の一般提供に合わせてAmazon Bedrock Flowsへ改称されました。AWSは告知の中で「previously known as Prompt Flows」と説明しており、プレビュー期に作成したフロー定義をそのまま使い続けられます。旧称で書かれた解説記事を参照する場合は、2025年2月の課金開始やGAで追加されたガードレール適用が反映されていない可能性を前提に読んでください。 ### Flows自体に利用料はかかりますか かかります。2025年2月1日からノード遷移1,000回あたり0.035ドルが課金されるようになりました。AWSの計算例では、1回の実行で25回の遷移が発生するフローを月960回動かして0.84ドルという水準です。フロー機能そのものの費用は小さく、実際の請求で大きいのはプロンプトノードやエージェントノードが呼ぶ基盤モデルの推論料金と、S3やLambdaなど併用するサービスの料金になります。反復処理を含むフローではモデル呼び出しの回数がそのまま費用に効くため、見積もりでは遷移回数より反復回数を先に確認してください。 ### 1つのフローに置けるノード数の上限はいくつですか 合計40ノードで、この値はクォータの引き上げ申請の対象外です。個別の上限としては、プロンプトノードが20（引き上げ可）、エージェント・ナレッジベース・Lambda関数・出力の各ノードが20、条件ノードが5で1ノードあたりの条件も5、S3ストレージとS3取得が各10、入力・イテレータ・コレクタが各1と定められています。プロンプトノードだけで20置けても、入出力や条件を足した合計は40を超えられません。この枠に収まらない規模なら、フローを分割するかAWS Step Functionsでの実装を検討する段階です。 ### ループ処理はできますか 2025年9月に追加されたDoWhileループノードで、条件が真である限り処理を繰り返せます。条件を評価する前に必ず1回は実行される点と、無限ループを防ぐ`maxIterations`の既定値が10である点に注意してください。生成結果を評価して基準を満たすまで書き直させる、といった使い方に向きます。配列の各要素を順に処理するだけならイテレータノードを使いますが、こちらはフローあたり1つしか置けず、要素は並列ではなく逐次に処理されます。なおAPI Reference上はDoWhileという型名ではなく`Loop`・`LoopInput`・`LoopController`に分かれています。 ### インラインコードノードでprintの出力を確認できますか できません。返るのは最後に実行した行の結果だけで、Pythonのコンソール出力は捕捉されない仕様です。途中経過を確認したい場合は、見たい値を辞書にまとめてコードの最終行に置くか、Lambda関数ノードに置き換えてCloudWatch Logsで追ってください。インラインコードノード自体がプレビュー機能で、使える言語はPython 3.12のみ、入力は最大5個、フローあたり5ノードまで、コードは5MB以内、実行環境にインターネット接続なし、という制約もあります。非同期のフロー実行では利用できない点も設計前に確認が必要です。 ## 関連記事 - [Amazon Bedrockの使い方｜料金・モデル・APIの始め方を4ステップで解説【2026年版】](/tech/details/2942/) - [Amazon Bedrock Converse APIの使い方｜boto3実装・ConverseStream・Tool Use・IAM権限【2026年最新】](/tech/details/2391/) - [Amazon Bedrock AgentCore APIの使い方｜SDK・CLIでAIエージェントを本番デプロイ【2026年最新】](/tech/details/8230/) - [Amazon Bedrockのプロンプトキャッシュとは｜仕組み・対応モデル・料金・実装方法【2026年最新】](/tech/details/4764/) - [Amazon Bedrockのプロンプト最適化機能の詳細と利用方法](/tech/details/4318/) --- 出典: [Amazon Bedrock Flowsとは｜ノード14種・料金・上限とboto3実装【2026年最新】]()（株式会社一創）