アーキテクチャ

AIワークフロー設計：マルチステップエージェントプロセスの5つのパターン

著者：IdeaBosque最終更新：2026年9月1日

重要なポイント

OpenAI経由のMCPツール呼び出しは2026年8月に1月レベルの98倍に達し、8月だけで2倍以上に増加（AAIF）——1つのユーザーリクエストが現在多数の呼び出しからなるワークフローを引き起こし、プロンプト設計ではなくワークフロー設計が生産規律となっています。
Gartnerは2028年までにエージェントワークフローあたりのAI推論コストが5倍以上に増加すると予測——トークンあたりの価格が下がる一方でワークフローあたりのコストは上昇します。エージェントワークフローはチャットより桁違いに多くのトークンを消費するためです。
MCPロードマップはTasksを公式拡張（SEP-2663）に改め、Multi Round-Trip Requests（SEP-2322）を追加して、マルチステップフローがステートレスサーバー上で生き残れるようにしました——プロトコルは現在、作業が長時間実行され複数ラウンドにまたがることを想定しています。
OpenAIは、そのミスアラインメントモニターが「エージェントが長期間実行されているタスク」を一時停止する可能性があること、APIタスクは再開ではなく停止すると明示しています——本番ワークフローは、生きたプロセスからではなく永続的状態から再開可能でなければなりません。
38ツールのRFQモジュールがこれらのパターンをすべてコードで実行します——ガードで強制されたステータス遷移、15分TTLでの冪等なホールド解放、見積時点で凍結されたFXスナップショット。

Agentic AI Foundationの使用分析によると、ChatGPTユーザーのMCPツール呼び出しは2026年8月に1月レベルの98倍に達しました——しかも8月だけで2倍以上に増加しています。ResendのMCPトラフィックはプロバイダー側から同じ物語を伝えています：4月は106,719回、8月は1,062,650回の呼び出し。プロトコルのメンテナー自身が新しいMCPロードマップで運用上の結論を示しています：「現代のエージェントワークロードは、もはや標準的なリクエスト・レスポンスパターンには収まりません。ループはより長く実行され、サーバーはストリーミング結果をプッシュでき、作業を途中で誘導する明確な必要性があります。」

難しかったのはチャットではありません。ワークフローです：1つのRFQの背後にあるカタログ照会のファンアウト、ERP書き込みの前に到着しなければならない承認、見積の途中でタイムアウトするサプライヤーAPI、価格設定と予約の間で変動してはならない為替レート。Gartnerは2028年までにワークフローあたりの推論コストが5倍以上に上昇すると予測しています。トークンあたりの価格が下がっているにもかかわらず、エージェントワークフローは多くの呼び出しにわたって推論し、交渉し、自問するためです。本記事は、マルチステップエージェントプロセスがその負荷に耐えられるかを決める5つのワークフローレベルパターン——ファンアウト、チェックポイント、補償、永続的状態、測定に基づく分岐——を定義し、それぞれをGraphQLバックエンドに対して38のMCPツールを登録する稼働中のRFQ実装に根付かせます。

ワークフローはあなたが設計する単位です。以下の図は5つのパターンを1分に圧縮したものです：並列読み取りのファンアウト、2つの人的ゲートを持つ直列化された書き込みの背骨、失敗時の型付き補償、そしてそれらを結びつける永続的状態のルール。

パターン1：読み取りはファンアウト、書き込みは直列化

最初のワークフロー決定は依存グラフの形状です。ほとんどのマルチステップエージェントプロセスは大部分が並列です：1つのRFQには3つのサプライヤーカタログからの価格帯、5つの明細のバッチ在庫確認、顧客セグメントが必要です——これらは互いに依存しません。それらのステップを直列化すると、レイテンシがステップ数倍になり、1回のタイムアウトの影響半径も倍増します。正しいデフォルトは、独立した読み取りをすべて並列に発行し、各ステップが前のステップの出力を消費する書き込みチェーンだけを直列化することです。

見積ワークフローの書き込みチェーンが厳格に順序付けされているのは、技術的ではなくビジネス上の理由からです：リクエスト確定 → 見積作成 → 在庫ホールド → 分割払い計画。私たちのRFQエンジンは、コード内のoperation guardsでこれを強制します——RequestOperationGuardは未確認のリクエストからの見積作成を拒否し、QuoteOperationGuardは見積が編集可能ウィンドウを過ぎると明細の変更を拒否します。ワークフローパターンはすべてのシステムで同じです：バッチローダーの背後の並列読み取り、状態変更書き込みのための狭い直列化された背骨、そしてプロンプトではなくコード内のガード。実行のたびに「順序を決める」エージェントは、不変条件のないワークフローです。

パターン2：人間のチェックポイントは状態であり、プロンプトではない

2番目のパターンは、人間がどこに位置するかを統治します。プロンプトのみの設計では、「送信前にユーザーに確認する」はモデルが従うことも従わないこともある提案です。ワークフロー設計では、チェックポイントは永続的状態です：プロセスは名前付きステータスで停止し、続行に必要なすべてを永続化し、人間のアクションだけがそれを前進させます。9月1日、OpenAIが明らかにしたところによれば、同社の本番ミスアラインメントモニターは、潜在的に未承認の活動を自動的に停止できます——そしてその代償を誠実に認めています：セーフガードは「正当な活動を潜在的なサイバー悪用として時折フラグ付けすることがある……これには、サイバーセキュリティに直接関係していないように見える作業や、エージェントが長期間実行されているタスクが含まれる可能性がある」。ChatGPTとCodexでは、ユーザーは一時停止されたタスクのレビューを求められます。APIでは、タスクは停止します。

その世界のために構築されたワークフローは、一時停止を例外ではなく設計された状態として扱います：実行レコードには、完了したもの、保留中のもの、再開パスが示されます。私たちのRFQエンジンの2つの利便性ツール——confirm_request_and_create_quotesとconfirm_quote_and_create_installments——が存在するのは、まさに人間のゲートがそれらの間に位置するからです：人間が確認し、その後マルチステップの機械的な作業が1つの監査された呼び出しとして実行されます。Camundaの1,150人のシニアITリーダーへの調査では、組織の71%がAIエージェントを使用しているものの、ユースケースの11%しか本番に到達していないことがわかりました。そのギャップを越えるワークフローは、承認がシステムプロンプト内の一文ではなく、システムが何時間も留まれるステータスであるワークフローです。チェックポイントを実行時層で強制するメカニズムはLoop Engineering：なぜエージェントランタイムが新しいミドルウェアなのかにあります；ワークフローパターンは、何も出荷する前に、どのステップが人間の前で停止し、プロセスがどの状態から再開するかを決めることです。

パターン3：すべての前進ステップに補償パスが必要

3番目のパターンは、チュートリアルが省略するものです：何がステップを取り消すのか。長時間実行されるワークフローは途中で失敗します——サプライヤーAPIが5明細のうち4明細目でエラーを返す、エージェントが価格を計算している間にホールドが失効する、見積は承認されたが支払いスケジューリングが失敗する。補償チェーンのないワークフローは、すべての失敗を手動クリーンアップに変換します。補償を持つワークフローは、すべての失敗を型付きの冪等な逆操作に変換します。

見積実装はその構造を示します。在庫ホールドは15分TTLで失効し、失敗面は型付きエラーとして列挙されます——HOLD_NOT_FOUND、HOLD_ALREADY_EXPIRED、AVAILABILITY_INSUFFICIENT——それぞれが異なる回復にマッピングされます：再確認、再取得、または人間へのエスカレーション。ホールドの解放は冪等であるため、ネットワーク分断後のリトライが二重解放することはなく、ホールドの確認が二重に減算されることもありません。ツール呼び出しは指数バックオフ付きのリトライデコレータでラップされ、すべての呼び出しのステータス、所要時間、ペイロード（400KB超はオブジェクトストレージにオフロード）が監査レコードに記録されます。これが一般化されたパターンです：前進ステップはリソースを取得し、補償ステップはそれを解放し、すべての補償は2回実行しても安全です。ワークフローが各ステップの取り消し方を名指しできないなら、それはワークフローを持っていません——サプライヤー障害にまだ出会っていないデモを持っているだけです。

パターン4：ステートレスなプロトコル、ステートフルなワークフロー

4番目のパターンは、2026-07-28 MCP仕様における一見矛盾を解決します。仕様は、サーバーが状態を保持せずに水平スケールできるよう、プロトコルレベルのセッションと初期化ハンドシェイク（SEP-2575、SEP-2567）を廃止しました。そしてロードマップはTasksを公式拡張（SEP-2663）に改め、Multi Round-Trip Requests（SEP-2322）がサーバー起点のリクエストを置き換えたため、elicitationフローはタスクの途中でも機能し続けます。プロトコルはステートレスです。状態を運ぶのはワークフローです。具体的には：すべてのリクエストは自己完結して到着しなければならず、ワークフローの状態は永続的で検査可能なレコード——サーバーのメモリではなく——に存在します。

このアーキテクチャの選択こそが、前のパターンを存続可能にします。私たちのRFQエンジンでは、ホールドのhold_tokenとhold_expires_atは見積行項目に直接置かれ、FXレートは見積時点でfx_rate_locked_atタイムスタンプ付きで凍結されます——スナップショットであり、ライブ参照ではありません。どのサーバーインスタンスも次のリクエストを引き受けられます。再起動されたプロセスはRAMからではなくレコードから再開します。そしてAstraの警告により、再開可能性はクラッシュ耐性だけでなく、プラットフォーム相互作用の要件になりました：フロンティアモデルのセーフガードがあなたの38時間の無人実行を一時停止した場合、生き残るワークフローは、状態をプロセスの外に保持していたワークフローです。ステートレス仕様のデプロイメントメカニクスはMCPステートレスプロトコル：B2Bデプロイメントで何が変わるかで扱っています；ワークフローレベルでのルールはシンプルです——どのステップも一時停止前の最後のステップかもしれないとして設計し、次のステップが監査証跡から再構築できるようにすることです。

パターン5：モデルの判断ではなく、測定されたデータで分岐する

5番目のパターンは条件分岐を統治します。マルチステップワークフローには意思決定ポイントがあります——この明細は見積するだけの利益率があるか、このバッチは動きが遅くてフラグを立てるべきか、この顧客セグメントは割引ティアを解除するか。モデルにそれらの分岐を即興させると、決定論的動作が重要な唯一の場所に分散が再導入されます。ワークフローの答えは測定されたゲートです：データがフラグを運び、分岐がそれを読みます。

RFQエンジンでは、各見積明細はバッチレコードから読み込まれたguardrail_price_per_uomとslow_move_itemを運びます——「リスト価格で見積」と「マージンレビュー用にフラグ」の分岐は、モデルにマージンを推定させる代わりに2つのフィールドを読みます。割引ルールは、4つの階層スコープ（グローバル、セグメント、品目、プロバイダー品目）からデータとして組み合わされ、推論ステップとしてではありません。ここはワークフロー設計がコストと出会う場所でもあります：Gartnerの推論分析は「タスクをエージェント推論モデルにルーティングすると、プロバイダーの推論コストが少なくとも5倍増加する」と警告し、「高度に最適化された推論ティアリング、ルーティング、オーケストレーション」を推奨しています。保存されたフラグに基づいて分岐するワークフローは、モデル推論を必要とするステップ——価格判断、例外解釈、交渉ドラフト——に取っておき、残りは型付きデータに決めさせます。同じ規律はデータプラットフォームにも現れており、Dagsterのオーケストレーションコンテキストの取り組みは、マテリアライゼーションイベントを、ワークフローが再導出するのではなく消費する運用コンテキストとして扱います。

5つのパターン、それぞれ1行で

読み取りはファンアウト、書き込みは直列化——形状はビジネス不変条件であり、ガードとして符号化する。チェックポイントはシステムが留まれる状態である。なぜならプラットフォーム自体があなたを一時停止するから。補償はすべての前進ステップに対する第一級のステップであり、構造的に冪等である。状態はプロトコルやプロセスではなく、永続的レコードに存在する。分岐は測定されたフラグを読み、モデル推論はその代償を支払うステップに取っておく。これらのパターンはどれもフレームワーク移行を必要としません；すべて、ステップごとに誰がそれを所有するか——モデル、ランタイム、それとも人間か——を決めることを必要とします。

代表的な構築事例

ホテル、フライト、アクティビティにわたり週200件のグループ予約RFQを処理する中堅ツアーオペレーターが、これらのパターンに基づいて見積ワークフローを再構築しました。読み取りは並列に発行されます——5つのカタログ、バッチ在庫、価格帯——11のドメインミックスインにわたって38のツールを公開する単一のMCPモジュールを通じて、各ツールのスキーマは型付きで、すべての呼び出しが監査されます。書き込みの背骨は直列化されます：リクエスト確定、見積時点でFXを固定して見積を組み立て、15分TTLと冪等な解放でホールドを取得、分割払い計画をスケジュール。2つの human ゲートが資金が拘束される場所——リクエスト確認と見積確認——に位置し、各ゲートはプロセスが何時間も待機できる永続化された状態です。サプライヤーAPIが価格計算の途中でタイムアウトすると、型付きエラーがその明細を破壊するのではなく再確認へルーティングします。見積のターンアラウンドは、手動照会の3日から4時間未満に短縮され、すべての書き込みに人間の承認が付きました。結果は、人員の置き換えではなく、少人数チームのための見積能力です。