AIエージェントのワークフローパターン:実際に勝つ7つのパターンと使い分け (2026)

AIエージェントのワークフローパターン:実際に勝つ7つのパターンと使い分け (2026)

AIエージェントのワークフローパターンに、つい数字が付くようになりました。2026年1月、Google Researchは180のエージェント構成を評価し、同じコーディネーションの変更が、並列化できる金融推論を80.9%向上させる一方で、PlanCraftの順次プランニングを最大70%も低下させることを発見しました。同じレバーなのに、結果は真逆です。勝敗を分ける変数はエージェントの数ではなく、タスクの分解可能性です。以下では、7つのパターンをベンダーの図ではなく、公開されている実測データに照らして判定します。

• 重要なパターンは7つ:シーケンシャル、ルーティング、並列化、オーケストレーター-ワーカー、リフレクション、ReAct、プラン&エクスキュート。
• 勝者を決めるのはタスクの分解可能性。並列化できる仕事は伸び、順次処理の仕事は劣化する。
• エージェントは1つで始める。単一エージェントの精度が約85%を下回って頭打ちになったときだけ、2つ目を足す。

AIエージェントのワークフローパターン一覧:データが示すこと

7つのAIエージェントパターンとは、シーケンシャル(プロンプトチェーン)、ルーティング(ハンドオフ)、並列化(ファンアウト/ファンイン)、オーケストレーター-ワーカー、リフレクション(評価者-最適化者)、ReAct、プラン&エクスキュートです。5社のベンダーがそれぞれ違う名前で呼んでいますが、この7つの形が、Anthropic、OpenAI、Vercel、Microsoft、Google Cloudが現在公開しているすべての分類をカバーします。ヒューマンインザループは7つのうちの1つではありません。どれにでも巻き付けられるコントロールレイヤーです。

実測コラムは懐疑的に読んでください。実際の数字があるのは3行だけで、4行は「公開されている測定はなし」です。これが2026年時点のこの分野の正直な状態です。5社のベンダーが、実質3つか4つの形にすぎないものに5通りの違う名前を付けて公開しています。最後のコラムは、それらの名前を元の形に逆引きできるようにするためにあります。この記事の残りの部分では、1つのファミリーずつ詳しく見ていきます。

SERP上の誰も議論していないコラムが2つあります。トークンコストとレイテンシバジェットです。シーケンシャルとルーティングはどちらも最も少なく、オーケストレーター-ワーカーはどちらも最も多くなります。並列化はトークン消費を実時間でトレードします。パターンは、見栄えのする図ではなく、タスクが実際に制約しているリソースで選んでください。

AIエージェントのワークフローパターンとは(AIワークフローの4つのステージとは?)

AIエージェントのワークフロー設計パターンとは、LLM呼び出し・ツールの使用・制御ロジックを1つのシステムに組み上げるための、再利用可能な形のことです。すべてのベンダーの分類に繰り返し登場する7つは、シーケンシャル、ルーティング、並列化、オーケストレーター-ワーカー、リフレクション、ReAct、プラン&エクスキュートです。それぞれトークンコスト・レイテンシ・精度のトレードオフが異なるため、正しい選択は使っているフレームワークではなく、タスクの構造に依存します。

典型的なAIエージェントのワークフローは、4つのステージをループで回します。

1. Plan(計画):モデルは、ゴールとこれまでの履歴を踏まえて、次に何をするか決める。
2. Act(行動):ツールを呼び出す。2026年では通常、MCPサーバーかfunction callのこと。Model Context Protocol(MCP)はこのツール層をモデル間で標準化する。
3. Observe(観測):ツールの結果が新しいメッセージとしてコンテキストに戻る。
4. Reflect / loop(振り返り/ループ):モデルは結果が十分かどうかを判断し、ループするか停止する。

この記事のすべてのパターンは、これら4つのステージの異なる配線方法です。シーケンシャルは順序をコードで固定します。ReActはモデルに毎ターン次のステージを選ばせます。オーケストレーター-ワーカーはループを複数のモデルに分割します。

カタログの前に、1つ重要な区別があります。ワークフローは事前に決められたコードパスであり、エージェントはモデルに制御を委ねます。AnthropicはBuilding Effective Agentsの中でこう線を引いています。「ワークフローは、明確に定義されたタスクに対し、予測可能性と一貫性を提供する。一方エージェントは、柔軟性とモデル主導の意思決定が大規模に必要とされる場面で、より良い選択肢となる。」

AIにおけるエージェントの古典的な種類(単純反射、モデルベース、ゴールベース、学習型)を探してここにたどり着いた方へ。その分類はLLM以前のものです。上記の7つのパターンこそが、あなたのプロダクトが無事リリースできるかどうかを分けるものです。

決定論的なパターン:シーケンシャル、ルーティング、並列化

3つのパターンは、制御をモデルではなくコードの中に保ちます。実行コストは最も安く、デバッグも最も簡単です。2026年3月のClaudeチームのガイダンスは、どこから始めるべきかについて率直です。「問題を解決する最もシンプルなパターンから始めよ。デフォルトはシーケンシャル。」

シーケンシャル(プロンプトチェーン)

1つの呼び出しが次に給餌します。難しいタスクを順序付きのステップに分割し、各ステップは前のステップの出力を入力として受け取ります。利点は可読性です。すべての中間結果を検査でき、各ステップをキャッシュできます。サブタスクが独立している場合は避けてください。必要のない順序付けのためにレイテンシを支払うことになります。ステップ間やセッションをまたいで状態を維持する必要があるなら、それはチェーンの問題ではなくメモリの問題です。その切り分けはエージェントメモリガイドを参照してください。公開されている唯一のお墨付きは「デフォルトである」ということです。チェーン自体の効果を測定した研究はありません。他のすべてのパターンが追加コストを払ってでも打ち負かそうとするベースラインだからです。

from anthropic import Anthropic

client = Anthropic()

def chain(steps: list[str], context: str = "") -> str:
    for step in steps:
        msg = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            messages=[{"role": "user", "content": f"{context}\n\n{step}"}],
        )
        context = msg.content[0].text
    return context

summary = chain([
    "Extract the five key claims from this report: {report}",
    "Rewrite those claims as bullets an engineer would trust.",
])

ルーティング(ハンドオフ)

安い分類器が入力を読み取り、専門家のプロンプトやモデルに振り分けます。OpenAIはAgents SDKのドキュメントの中でこう位置づけています。「トリアージエージェントが会話を専門家にルーティングし、その専門家がそのターンの残りの間、アクティブなエージェントになる。」分類器が汎用の1パスをそのまま実行するより信頼できない場合は、ルーティングを避けてください。すべての誤ルーティングが、サイレントな誤答になるからです。ここでの名前付きの失敗モードは、ハンドオフをまたいだコンテキストロスです。専門家はルーターが転送したものしか見えません。完全なトレースを引き継ぐかどうかはコンテキストエンジニアリングの判断であり、それを間違えることが、ルーティングされたシステムが忘れっぽく感じる理由です。とはいえ、トークンの計算はルーティングに有利です。分類器は小さなモデル(上記ではgpt-4o-mini)で動くため、ルーターはリクエストごとに数百の安いトークンを追加するだけで、2つ目の高価な呼び出しにはなりません。

from openai import OpenAI

client = OpenAI()
SPECIALISTS = {
    "billing": "You answer billing and refund questions.",
    "technical": "You debug API errors and integration issues.",
}

def route(question: str) -> str:
    triage = client.responses.create(
        model="gpt-4o-mini",
        input=f"Reply with exactly one of {list(SPECIALISTS)}: {question}",
    )
    key = triage.output_text.strip().lower()
    return client.responses.create(
        model="gpt-4o",
        instructions=SPECIALISTS.get(key, SPECIALISTS["technical"]),
        input=question,
    ).output_text

並列化(ファンアウト/ファンイン)

独立したサブタスクを同時に実行し、マージステップで結合します。Anthropicはこれをセクショニング(作業を分割する)とボーティング(同じタスクを数回実行して比較する)に分けています。これはGoogle Researchが2026年1月に、並列化できる金融推論で単一エージェント比+80.9%と測定した形そのものです。まさにタスクがきれいに分解できたからこそ、その数字が出ました。ステップn+1がステップnの出力に依存するようになった瞬間、並列化は避けてください。依存チェーンの並列化は、誤答をより速く並べ替えるだけです。レイテンシは効果のもう半分です。独立した呼び出しは並行して走るため、実時間はワーカー数におおむね反比例して下がり、トークンの総消費量は横ばいです。

from concurrent.futures import ThreadPoolExecutor
from anthropic import Anthropic

client = Anthropic()

def run(subtask: str) -> str:
    msg = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": subtask}],
    )
    return msg.content[0].text

def fan_out(subtasks: list[str]) -> list[str]:
    with ThreadPoolExecutor(max_workers=len(subtasks)) as pool:
        return list(pool.map(run, subtasks))

parts = fan_out([
    "Summarize Q1 revenue drivers in two sentences.",
    "Summarize Q1 churn drivers in two sentences.",
])
merged = run(f"Combine into one executive summary:\n{parts}")

ReAct vs プラン&エクスキュート:どの推論パターンを使うべきか?

ReActは推論と行動を交互に行います。モデルは考え、ツールを呼び、結果を観測し、その後でのみ次のステップを決めます。プラン&エクスキュートは、ツールを実行する前に完全な計画を書き上げ、その後ステップを順番に実行します。ReActは実行中の不意の事態に適応します。プラン&エクスキュートは最初に大きな計画呼び出し1回のコストを払い、ルートを信頼します。

ReActは観測のたびに次のステップを決め、プラン&エクスキュートは最初のツール呼び出しの前にルート全体を確定します。

ReActはYao et al.(arXiv 2210.03629、v1は2022年10月、v3は2023年3月)に由来し、模倣学習と強化学習のベースラインに対して、ALFWorldで+34ポイント(絶対値)、WebShopで+10ポイントの成功率向上を報告しました。使用したのはわずか1つか2つのインコンテキスト例だけです。これはツールを使うエージェントの大半の背後にあるデフォルトのループであり、SERP3位の結果の隙間でもあります。Microsoft Learnの7,133語のオーケストレーション文書は、ReActを完全に省略しています。この「観測して決める」というリズムのおかげで、ReActはオープンエンドなタスク(「Xを見つけるまでブラウズする」)を、事前の計画よりも上手に扱えます。計画するには、ページを読む前にその中身を推測しなければなりません。

プラン&エクスキュートはWang et al.のPlan-and-Solve Prompting(arXiv 2305.04091、ACL 2023)に由来し、まずタスクをサブタスクに分割する計画を立て、それからそれらを実行します。この論文は、評価した10のデータセットすべてでゼロショットのchain-of-thoughtを上回ったと報告しています。単一の数値を引用しないのは、論文の要旨が数値を一切公開していないためです。ルートが予測可能で、ステップごとの再計画がトークンの無駄になる場合に使用してください。トレードオフは脆さです。ステップ3が失敗した場合、プラン&エクスキュートのループには明示的な再計画フックが必要ですが、ReActは構造的に再計画します。

実測エビデンスの行が、正直な手がかりです。ReActにはタスクレベルの数値を伴う2022年の論文があります。プラン&エクスキュートには10データセットの一括評価がありますが、見出しになる数値はありません。これが、ベンチマークされるより引用されることの方が多い一因です。

from anthropic import Anthropic

client = Anthropic()

def react(question: str, tools: list, max_steps: int = 8) -> str:
    messages = [{"role": "user", "content": question}]
    for _ in range(max_steps):
        msg = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            tools=tools,
            messages=messages,
        )
        if msg.stop_reason == "end_turn":
            return msg.content[0].text
        messages.append({"role": "assistant", "content": msg.content})
        messages.append({"role": "user", "content": dispatch(msg.content)})
    return "Stopped: hit the iteration cap with no final answer."

このイテレーション上限はオプションではありません。終了条件のないReActループは、予算が尽きるまでトークンを燃やし続けます。max_stepsは、この記事全体で最も安いガードレールです。プラン&エクスキュートには、同じガードが1つ上の階層に必要です。ステップだけでなく再計画の回数にも上限を設けてください。さもないと、失敗する計画が無限に自己再生成します。

品質のパターン:リフレクション、評価者-最適化者、ヒューマンインザループ

品質のパターンは、出力品質を上げるために追加のトークンを費やします。そして、品質を測定できる場合にのみ報われます。リフレクション(Anthropicは評価者-最適化者と呼ぶ)は、生成者と批評者をループで回します。あるモデルがドラフトし、別のモデルが批評し、ドラフトが改善されます。テスト・ルーブリック・採点モデルで出力をスコアリングできないなら、批評者はただ自分自身と口論する追加トークンです。そのスコアラーを作ることこそが難しい部分です。使えるスコア関数に何が必要かは、本番環境でのエージェント評価ガイドでカバーしています。前提条件が成り立つ場所で、このパターンは安い保険です。Anthropicは評価者-最適化者を、ループ内の2つのLLM呼び出し(1つが生成し、1つが批評する)と説明しており、数秒の追加レイテンシで測定可能な品質向上を買えます。

誰も図にしない失敗モードが、暴走リフレクションです。批評者と生成者が永遠にループする、あるいは最悪の場合、発振します。修正方法は、ハードなイテレーション上限と、改善なし打ち切りです。プロンプトで要求するのではなく、コードで書きます。

def refine(task: str, score_fn, max_rounds: int = 4) -> str:
    best = generate(task)
    best_score = score_fn(best)
    for _ in range(max_rounds):
        critique = critic(task, best)
        candidate = generate(f"{task}\n\nCritique:\n{critique}")
        score = score_fn(candidate)
        if score <= best_score:
            break  # no improvement: stop spending tokens
        best, best_score = candidate, score
    return best

ヒューマンインザループは8つ目のパターンではなく、コントロールレイヤーです。7つのどれにでも巻き付けられます。不可逆なステップが実行される前に、人間が承認します。SERP上位6件のうち、これをカバーしているのはわずか2件です。ゲートは、不可逆なアクション、実際の支出、そして外部へのコミュニケーションとしてシステムから出ていくものすべてに置いてください。それ以外はすべて、無人で実行されるべきか、そもそも実行されないべきかのどちらかです。ゲート自体は、もう1つのLLMではなく、愚直なコードであるべきです。承認キュー、支出閾値、ドメインの許可リストなどです。人間が見るべきかどうかの判断をモデルに任せるのは、目的を台無しにします。

マルチエージェントは15倍のトークンを払う価値があるのか?ベンチマークが実際に言うこと

オーケストレーター-ワーカーは7つ目のパターンです。リードエージェントがタスクを分解し、断片をワーカーエージェントに委任し、戻ってきたものを統合します。「マルチエージェント」とは、このパターンを極限まで推し進めたものであり、別の形ではありません。したがって、本当の問題は、オーケストレーターがそのオーバーヘッドに見合うのはいつか、ということです。

単一エージェントではなくマルチエージェントを使うべきなのはいつですか?単一エージェントがそのタスクで約85%の精度を下回って頭打ちになったとき、それだけです。この経験則は、Google Researchの研究とともにr/AI_Agents(2026-04-23)で広まったもので、実測データとも一致します。この基準を超えると、エージェントの追加は精度を加えずにコストとエラー増幅だけを加えます。

以下が、私たちが検証できたすべての公開数値を並べたものです。

クリックする前に1つ注意があります。上記のGoogle Researchの数値はすべて2026-01-28のブログ記事から取ったもので、その背後にある論文(arXiv 2512.08296)はその後改訂されています。そのため、現在のバージョンでは、ブログの180構成・0.513ではなく、260構成・R² = 0.373と報告されています。方向性はどちらのバージョンでも変わりません。正確な数値は、どのバージョンを読んでいるかに依存します。

これらの行のうち2つは日常的に誤って引用されるため、ここで計算を示します。Anthropicの15倍という数値はチャットとの比較で測定されたもので、単一エージェントの数値は4倍です。つまり、マルチエージェントは単一エージェントのトークンの約15 / 4 = 3.75倍のコストであり、15倍ではありません。そして、Google Researchのエラー増幅、独立エージェント17.2倍 vs 中央集権型4.4倍は、オーケストレーターがエージェントを無監督で走らせるより約17.2 / 4.4 = 3.9倍エラー増幅が少ないことを意味します。

AnthropicのレポートとGoogle Researchの数値を突き合わせて読むと、私たちの読みは、勝敗を分ける変数はエージェントの数ではなく分解可能性だ、というものです。Anthropicのリサーチタスクは並列のサブ検索にきれいに分解できたため、エージェントを増やすと効果がありました。Googleの順次プランニングタスクは分解できなかったため、エージェントを増やすと互いに邪魔をしました。

これは、システムが本番に入ると実務家が言うこととも一致します。r/AI_Agentsで、「Multi agent systems are a total nightmare in production(マルチエージェントシステムは本番では完全な悪夢だ)」というタイトルのスレッド(2026-04-23、56ポイント、68コメント)は、20件以上のクライアントシステムをリリースしてきた投稿者によるものです。「実際に動き続けているものは…ほとんど恥ずかしいほどシンプルだ」「そして、あるエージェントが別のエージェントと話すたびに、コンテキストが失われる。伝言ゲームのようなものだ。」最上位のコメントがこのセクション全体を要約しています。「まず単一エージェントで問題を解け。そのエージェントの精度が85%を超えているなら、マルチエージェントシステムは何の価値も加えない。」

エージェントを追加する前に、Anthropicが測定した安い修正を試してください。ツール説明1つの改善でタスク完了時間が40%短縮され、並列ツール呼び出しでリサーチ時間が最大90%削減されました。どちらもコスト面で2つ目のエージェントを上回ります。実際のツールでマルチエージェントに進む場合は、Claude Codeサブエージェントが行ごとに検査できるオーケストレーター-ワーカーです。

同じパターン、5つの名前:フレームワーク対照表

同じ4つの形が、すべてのベンダーのドキュメントで違う名前で登場し、その命名はフレームワーク間で引き継げません。Microsoftの「magentic」や「group chat」は、翻訳しない限りOpenAI SDKでは何の意味も持ちません。その翻訳コストは、この表が取り除く実際のコストです。

5社のベンダー、5つの語彙、実際の形は3つか4つ。実際のコストは、フレームワークを乗り換えるときに現れます。MicrosoftのAgent FrameworkからOpenAI SDKに移るチームは、コードを1行も移行する前に、「magentic」をagents-as-toolsに、「group chat」をハンドオフグラフに再マッピングしなければなりません。Google Cloudの11の名前からなる分類が最も長く、Anthropicの7つの名前のリストが最も多く引用され、Claudeブログの3つの名前は、あなたが最初に実装するものになるでしょう。形を読んでから、SDKを読んでください。コラムの見出しはドキュメントそのものです:Anthropic、Claudeブログ、OpenAI Agents SDK、Vercel AI SDK、Microsoft Learn、Google Cloud。形が見えるようになれば、フレームワーク選びは別の判断です。2026年のベストAIエージェントフレームワークのまとめと、LangGraph vs CrewAI vs OpenAI Agents SDKの比較が、その判断をカバーします。

エージェントワークフローをそもそも使うべきでないのはいつか?

多くの場合、使うべきではありません。r/AI_Agentsで最も支持を集めた判断ラダー(2026-03-09)は、率直にこう述べています。「if…then文で済むなら、それを使え。次に、従来のワークフローで済むなら、それを使え。それでもダメなら、エージェント型AIを使え。」SERP上位3件のうち2件は、構造的に「作るな」とは言えないクラウドのドキュメントです。私たちは言えます。この記事のデータも同じ方向を指しています。実測された最大の2つの効果(+80.9%と+90.2%)は、どちらもきれいに分解できるタスクから生まれ、実測された最悪の損失(−70%)は、分解できないタスクにエージェントを無理やり当てたことから生まれました。

失敗モードには名前が付いており、それぞれに今や数字が付いています。

• ハンドオフをまたぐコンテキストロス:エージェント間のメッセージは、毎回状態を落とす(r/AI_Agentsの「伝言ゲーム」の苦情、2026-04-23)。
• エラー増幅:独立エージェントで17.2倍、中央集権型で4.4倍(Google Research、2026-01-28)。
• 暴走リフレクションループ:上記のコードのように、イテレーションに上限を設け、改善なしで打ち切る。
• 順次タスクの劣化:分解できない仕事を並列化すると、39〜70%悪化する(Google Research、2026-01-28)。
• コストの膨張:マルチエージェントシステムでは、チャットの約15倍のトークン(Anthropic、2025-06-13)。

これらの失敗モードにはすべて、10行のコードで書ける上限があり、その上限はいつでも、今にも追加しようとしていたエージェントより安いです。

CognitionのWalden Yanは、Don't Build Multi-Agents(2025-06-12)の中で、作り手の側から同じ主張をしました。「コンテキストを共有せよ。個々のメッセージだけでなく、エージェントの完全なトレースを共有せよ」「アクションは暗黙の意思決定を運び、矛盾した意思決定は悪い結果を運ぶ。」r/AI_Agentsの比較が、私たちが何度も立ち返るものです。「マルチエージェントは、どんどんマイクロサービスに似てくる。境界が本物なら強力だし、発明されたものなら苦痛だ。」

Techsyのパターン選定アプローチ

以下のラダーは、Google ResearchとAnthropicの知見、そして実務家のスレッドに対する私たちの読みであり、私たち自身の実測結果ではありません。上から下へ実行し、当てはまる最初の行で止めます。

この記事のデータから、3つのことが導かれます。シーケンシャルから始めること。Anthropicがそう言っており、SERP上でそれを覆すものは何もないからです。分解できるものだけを並列化すること。同じコーディネーションの変更が+80.9%と測定された一方で、−70%とも測定されているからです。そして、2つ目のエージェントは最後の手段として扱うこと。トークン請求は現実であり、エラー増幅は実測されているからです。一貫したメッセージは、エージェントの追加は品質の施策ではなくスケーリングの施策だということです。ベンチマークがそれに報いるのは作業が分割できる場所だけで、実務家のスレッドはそれ以外の場所でそれを裏付けています。構築前にアーキテクチャのセカンドオピニオンが欲しい場合は、無料相談をご利用ください。

よくある質問

AIエージェントの7つのパターンとは?

7つとは、シーケンシャル(プロンプトチェーン)、ルーティング(ハンドオフ)、並列化(ファンアウト/ファンイン)、オーケストレーター-ワーカー、リフレクション(評価者-最適化者)、ReAct、プラン&エクスキュートです。AnthropicからGoogle Cloudまで、すべてのベンダーの分類で違う名前で繰り返し登場します。ヒューマンインザループはこれらと並べて語られますが、7つのどれにでも巻き付けられるコントロールレイヤーであり、8つ目のパターンではありません。

AIエージェントワークフローの4つのステージとは?

計画、行動、観測、振り返りです。モデルは次のステップを計画し、ツールを呼び出して行動し、ツールの結果がコンテキストに入るのを観測し、ゴールが達成されたかを振り返ってループするか停止します。この記事のすべてのパターンは、これら4つのステージを異なる方法で配線したものです。

AIワークフローとAIエージェントの違いは?

ワークフローは事前に決められたコードパスに従います。エージェントはモデルに自身の制御フローを指示させます。Anthropicのルールは、明確に定義されたタスクの予測可能性にはワークフローを、モデル主導の意思決定が大規模に必要とされる場面での柔軟性にはエージェントを、というものです。本番システムのほとんどは、内部にいくつかのエージェントステップを含むワークフローです。

ReAct vs プラン&エクスキュート:どちらを使うべき?

次のステップが直前のツール呼び出しの戻り値に依存し、ルートが実行中に変化しうるなら、ReActを使ってください。ルートが事前に予測可能で、ステップごとの再計画がトークンの無駄になるなら、プラン&エクスキュートを使ってください。ReActはALFWorldで+34ポイントと測定されました(Yao et al., 2022)。プラン&エクスキュートは10のデータセットでゼロショットCoTを上回りました(Wang et al., 2023)。

これらのパターンを使うのにLangGraphのようなフレームワークが必要か?

いいえ。この記事のすべてのコードブロックはプレーンなSDK呼び出しであり、パターンはそれらに名前を付けたフレームワークより前から存在します。フレームワークがその価値を発揮するのは、状態の永続化・リトライ・トレーシングにおいてであり、パターンそのものにおいてではありません。選定中であれば、フレームワーク比較がトレードオフをカバーしています。

リフレクションループが永遠に続くのを止めるには?

2つのガード、どちらもコードで書きます。ハードなイテレーション上限(私たちは4ラウンドを使用)と、批評者の書き直しが現在のドラフトより良いスコアを取れなくなった瞬間に止める、改善なし打ち切りです。ループを終わらせるのをプロンプトに信頼しないでください。モデルはコストを何一つ理解していません。

単一エージェントで十分なのはいつか?

そのタスクでおおよそ85%の精度をクリアしているときです。この経験則は、Google Researchの研究とともにr/AI_Agents(2026-04-23)で広まったもので、ベンチマークとも一致します。この基準を超えると、追加のエージェントは精度を加えずにコストとエラー増幅だけを加えます。より大きなものを設計する前に、単一エージェントのベースラインを測定してください。

コード付きのAIエージェントワークフローパターンの例はどこで見つかるか?

上記の5つのPythonブロックが、シーケンシャル、ルーティング、並列化、ReAct、リフレクションをカバーしており、すべてがそのまま引き上げられるプレーンなSDK呼び出しです。ベンダー流の例としては、Vercel AI SDKがパターンごとに実行可能なTypeScriptを同梱しており、OpenAI Agents SDKのドキュメントはハンドオフとagents-as-toolsをカバーしています。両方へのリンクは、下記のSourcesリストにあります。

Sources

• Anthropic, Building Effective Agents (2024-12-19)
• Anthropic, How we built our multi-agent research system (2025-06-13)
• Google Research, Towards a science of scaling agent systems (2026-01-28); paper: arXiv 2512.08296
• Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models (v3 2023-03-10)
• Wang et al., Plan-and-Solve Prompting (ACL 2023)
• Claude by Anthropic, Common workflow patterns for AI agents (2026-03-05)
• OpenAI Agents SDK, Orchestrating multiple agents
• Vercel AI SDK, Workflow Patterns
• Microsoft Learn, AI Agent Orchestration Patterns (updated 2026-05-12)
• Google Cloud, Choose a design pattern for your agentic AI system (2026-05-28)
• Cognition (Walden Yan), Don't Build Multi-Agents (2025-06-12)
• r/AI_Agents, Multi agent systems are a total nightmare in production (2026-04-23); Wait, are workflows actually better than multi-agent systems? (2026-03-09)