AIエージェントの設計パターン一覧｜5つの型の違いと選び方

AIエージェントの設計パターンは、まず「1 回の呼び出しで足りないか」を確かめ、手順を事前に決められるならワークフローの 5 つの型から選び、手順を決められないときだけエージェントにする、という順で選びます。 型の名前を覚えるより、この順番を持っておくほうが設計は速く決まります。

この記事では、Anthropic の公開文書「Building effective agents」に沿って、5 つの型（プロンプトチェイニング・ルーティング・並列化・オーケストレーターとワーカー・評価と改善）を一覧表で比べ、型ごとに図と Python の骨組みを載せます。Microsoft の文書で使われる用語（シーケンシャル、コンカレント、ハンドオフなど）との対応表も付けました。

確認環境（確認日 2026-10-06）：Python 3.11.15。掲載のコードは、モデルを呼び出さずに動く形（プロンプトの先頭の語に応じて決まった文字列を返す代役を置いたもの）で実行しました。図は Mermaid のコードを @mermaid-js/mermaid-cli 11.14.0 と Chromium で描画できることを確かめています。型の定義と使いどころは、Anthropic「Building effective agents」（2024 年 12 月 19 日公開）と、Microsoft Azure アーキテクチャ センター「AI エージェント オーケストレーション パターン」（2026 年 2 月 12 日更新）を今回開いて確認した範囲です。

この記事の結論

• 最初に確かめるのは「1 回の呼び出しで足りないか」。 検索結果や例をプロンプトに足すだけで済む作業は多い。
• 手順を事前に決められるなら、ワークフロー（5 つの型）。 決めた道筋をコードで書き、モデルは各手順の中身だけを担当する。
• 手順を決められないときだけ、エージェント。 次の一手をモデルが決めるぶん、時間と費用が増え、誤りが積み重なりやすい。
• 型は組み合わせて使う。 たとえばルーティングの先にプロンプトチェイニングを置く、並列化の結果を評価と改善にかける、という形になる。

5つの型の早見表

5 つの型はどれも「ワークフロー」に入ります。比較のために、エージェントも並べます。

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

Anthropic の文書は、2 つを次のように分けています。

• ワークフロー：あらかじめ決めたコードの道筋に沿って、モデルと道具を動かす仕組み。
• エージェント：モデルが自分で進め方と道具の使い方を決め、作業の進め方の主導権を持ち続ける仕組み。

同じ文書は、できるだけ単純な解決策から始め、必要なときだけ複雑にすることを勧めています。エージェント的な仕組みは、作業の出来と引き換えに応答の遅さと費用を受け入れるものなので、その交換が見合う場面で使う、という考え方です。

型の選び方（フローチャート）

flowchart TD
    A[作りたい処理] --> B{1回の呼び出しで足りるか}
    B -- はい --> C[1回の呼び出し + 検索や例の追加]
    B -- いいえ --> D{手順を事前に決められるか}
    D -- いいえ --> E{作業の分け方だけが決められないか}
    E -- はい --> F[オーケストレーターとワーカー]
    E -- いいえ --> G[エージェント]
    D -- はい --> H{入力の種類で処理が変わるか}
    H -- はい --> I[ルーティング]
    H -- いいえ --> J{独立した作業に分けられるか}
    J -- はい --> K[並列化]
    J -- いいえ --> L{明確な評価基準で繰り返し直すか}
    L -- はい --> M[評価と改善]
    L -- いいえ --> N[プロンプトチェイニング]

条件から選ぶ表にすると、次のとおりです。

迷ったときは、表の上にあるものから試します。上にあるものほど呼び出し回数が少なく、確かめやすいからです。

型ごとの図とコード

コードはすべて、次の代役（fake_llm.py）を呼びます。実際のモデルにつなぐときは、call_llm の中身を各社の SDK の呼び出しに差し替えます。

# fake_llm.py  モデルの代役。プロンプトの先頭の語を見て、決まった文字列を返す
import json

CALLS = 0   # 呼び出し回数を数える

def call_llm(prompt: str) -> str:
    global CALLS
    CALLS += 1
    head = prompt.split("\n")[0]
    if head.startswith("見出しを作る"):
        return "1. 予約の流れ\n2. 取り消しの方法\n3. よくある質問"
    if head.startswith("見出しから本文を書く"):
        return "予約は画面の「新規予約」から行います。取り消しは一覧から選びます。"
    if head.startswith("英語に訳す"):
        return "Reservations are made from the New Reservation screen."
    if head.startswith("分類する"):
        text = prompt.split("\n", 1)[1]
        return "不具合" if "エラー" in text else "使い方" if "方法" in text else "その他"
    if head.startswith("観点:"):
        return f"{head[3:].strip()}の指摘: 1 件"
    if head.startswith("計画を立てる"):
        return json.dumps(["予約一覧の画面を直す", "取り消し API を直す", "テストを足す"], ensure_ascii=False)
    if head.startswith("作業する"):
        return f"完了: {prompt.split(chr(10))[1]}"
    if head.startswith("まとめる"):
        return "3 件の作業をまとめました。"
    if head.startswith("評価する"):
        ok = "締め切り" in prompt.split("\n")[1]          # 2 行目（下書き）だけを見る
        return json.dumps({"ok": ok, "feedback": "" if ok else "締め切りの日付を入れてください"}, ensure_ascii=False)
    if head.startswith("下書きを書く"):
        return "備品の棚卸しにご協力ください。" + ("締め切りは 10 月 20 日です。" if "締め切り" in prompt else "")
    return f"（{head} への回答）"

1. プロンプトチェイニング

作業を決まった順の手順に分け、前の出力を次の入力にします。Anthropic の文書は、途中の手順にプログラムによる点検（ゲート）を置いて、道筋から外れていないかを確かめられると述べています。1 回ごとの作業を易しくするぶん、応答は遅くなります。

flowchart LR
    In[入力] --> A[呼び出し1 見出しを作る]
    A --> G{点検}
    G -- 合格 --> B[呼び出し2 本文を書く]
    G -- 不合格 --> X[止める]
    B --> C[呼び出し3 訳す]
    C --> Out[出力]

# chaining.py  プロンプトチェイニング: 決まった順に呼び、途中で点検する
from fake_llm import call_llm

def gate(outline: str) -> bool:
    """次へ進めてよいかをプログラムで点検する（見出しが 3 つ以上あるか）。"""
    return len(outline.splitlines()) >= 3

def run(topic: str) -> str:
    outline = call_llm(f"見出しを作る\n題材: {topic}")           # 手順 1
    print("手順 1 見出し:", outline.replace("\n", " / "))
    if not gate(outline):                                        # 点検（ゲート）
        raise ValueError("見出しが足りないので止めます")
    body = call_llm(f"見出しから本文を書く\n{outline}")          # 手順 2: 前の出力を入力にする
    print("手順 2 本文:", body)
    translated = call_llm(f"英語に訳す\n{body}")                 # 手順 3
    print("手順 3 英訳:", translated)
    return translated

if __name__ == "__main__":
    run("備品予約システムの使い方")

実行結果：

手順 1 見出し: 1. 予約の流れ / 2. 取り消しの方法 / 3. よくある質問
手順 2 本文: 予約は画面の「新規予約」から行います。取り消しは一覧から選びます。
手順 3 英訳: Reservations are made from the New Reservation screen.

2. ルーティング

入力を分類し、種類ごとに専用のプロンプトや処理へ送ります。種類ごとにプロンプトを分けられるので、ある種類のために直した内容が、別の種類の出来に影響しません。Anthropic の文書は、問い合わせの種類による振り分けと、問いの難しさに応じて使うモデルを分ける例を挙げています。

flowchart LR
    In[入力] --> R[呼び出し1 分類する]
    R -- 不具合 --> A[不具合用の処理]
    R -- 使い方 --> B[使い方用の処理]
    R -- その他 --> C[その他の処理]
    A --> Out[出力]
    B --> Out
    C --> Out

# routing.py  ルーティング: 入力を分類し、種類ごとの専用の処理へ送る
from fake_llm import call_llm

def answer_bug(text):   return call_llm(f"不具合の受付文を書く\n{text}")
def answer_howto(text): return call_llm(f"手順を説明する\n{text}")
def answer_other(text): return call_llm(f"担当へ引き継ぐ文を書く\n{text}")

# ラベルと処理の対応表。種類が増えたらここに 1 行足す
ROUTES = {
    "不具合": answer_bug,
    "使い方": answer_howto,
}

def run(text: str) -> str:
    label = call_llm(f"分類する\n{text}").strip()        # 1 回目: 分類だけを行う
    handler = ROUTES.get(label, answer_other)            # 知らないラベルは「その他」へ
    print(f"分類: {label} → {handler.__name__}")
    return handler(text)                                 # 2 回目: 専用のプロンプトで答える

if __name__ == "__main__":
    for q in ("予約ボタンを押すとエラーになります", "予約を取り消す方法は？", "こんにちは"):
        print(run(q))

実行結果：

分類: 不具合 → answer_bug
（不具合の受付文を書く への回答）
分類: 使い方 → answer_howto
（手順を説明する への回答）
分類: その他 → answer_other
（担当へ引き継ぐ文を書く への回答）

3 つ目の「こんにちは」は、対応表に無いラベルとして「その他」の処理へ送られています。

3. 並列化

複数の呼び出しを同時に行い、結果をプログラムでまとめます。Anthropic の文書は 2 つの形を挙げています。

• 分担（セクショニング）：作業を独立した部分に分けて同時に進める。
• 多数決（ボーティング）：同じ作業を複数回行い、複数の答えから決める。

flowchart LR
    In[入力] --> A[呼び出し 読みやすさ]
    In --> B[呼び出し 安全性]
    In --> C[呼び出し テストの抜け]
    A --> M[プログラムでまとめる]
    B --> M
    C --> M
    M --> Out[出力]

# parallel.py  並列化: 独立した作業を同時に呼び、結果をプログラムでまとめる
from concurrent.futures import ThreadPoolExecutor
from fake_llm import call_llm

VIEWPOINTS = ["読みやすさ", "安全性", "テストの抜け"]     # 分担（セクショニング）

def review(viewpoint: str, code: str) -> str:
    return call_llm(f"観点: {viewpoint}\n次のコードを点検する\n{code}")

def run(code: str) -> list[str]:
    with ThreadPoolExecutor(max_workers=3) as pool:        # 同時実行数はここで抑える
        results = list(pool.map(lambda v: review(v, code), VIEWPOINTS))
    return results                                         # まとめ方はプログラムで決める

def vote(question: str, n: int = 3) -> bool:
    """多数決（ボーティング）: 同じ問いを n 回たずね、過半数で決める。"""
    with ThreadPoolExecutor(max_workers=n) as pool:
        answers = list(pool.map(lambda _: call_llm(f"分類する\n{question}"), range(n)))
    return answers.count("不具合") > n // 2

if __name__ == "__main__":
    for line in run("def cancel(id): ..."):
        print(line)
    print("不具合と判定:", vote("保存するとエラーになります"))

実行結果：

読みやすさの指摘: 1 件
安全性の指摘: 1 件
テストの抜けの指摘: 1 件
不具合と判定: True

代役は毎回同じ答えを返すので、多数決は必ず 3 対 0 になります。実際のモデルでは答えが割れることがあり、そのときに過半数で決める、というのがこの形の使いどころです。

4. オーケストレーターとワーカー

指揮役のモデルが作業を分け、作業役に配り、結果をまとめます。図の形は並列化に似ていますが、作業の一覧が事前に決まっていない点が違います。並列化では観点の一覧をコードに書きましたが、こちらは指揮役が入力を見てから一覧を作ります。

flowchart LR
    In[入力] --> O[指揮役 計画を立てる]
    O -.-> W1[作業役1]
    O -.-> W2[作業役2]
    O -.-> W3[作業役N]
    W1 -.-> S[指揮役 まとめる]
    W2 -.-> S
    W3 -.-> S
    S --> Out[出力]

# orchestrator.py  オーケストレーターとワーカー: 分け方そのものをモデルが決める
import json
from fake_llm import call_llm

MAX_SUBTASKS = 5                                           # 作業の数に上限を置く

def run(request: str) -> str:
    # 1. 指揮役が、依頼を見てから作業の一覧を作る（数も中身も事前には決まっていない）
    plan = json.loads(call_llm(f"計画を立てる\n{request}\nJSON の配列で返す"))
    if not isinstance(plan, list) or not plan:
        raise ValueError("計画を読み取れないので止めます")
    plan = plan[:MAX_SUBTASKS]
    # 2. 作業役が、1 件ずつ受け持つ
    results = []
    for task in plan:
        results.append(call_llm(f"作業する\n{task}\n依頼の全体: {request}"))
        print(results[-1])
    # 3. 指揮役が、結果を 1 つにまとめる
    return call_llm("まとめる\n" + "\n".join(results))

if __name__ == "__main__":
    print(run("予約の取り消しを、開始 1 時間前まで受け付けるように変える"))

実行結果：

完了: 予約一覧の画面を直す
完了: 取り消し API を直す
完了: テストを足す
3 件の作業をまとめました。

5. 評価と改善

書く役のモデルが案を作り、評価する役のモデルが基準と照らして指摘を返す、という往復を繰り返します。Anthropic の文書は、はっきりした評価基準があり、繰り返し直すことで目に見えて良くなる場合に向くと述べています。

flowchart LR
    In[入力] --> G[書く役 下書きを書く]
    G --> E[評価役 基準と照らす]
    E -- 直す点を返す --> G
    E -- 合格 --> Out[出力]
    E -- 上限回数 --> H[人が確認する]

# evaluator.py  評価と改善: 書く役と評価する役を分け、基準を満たすまで繰り返す
import json
from fake_llm import call_llm

MAX_ROUNDS = 3                                             # 回数の上限を必ず置く

def run(request: str) -> str:
    feedback = ""                                          # 評価役からの指摘（最初は空）
    draft = ""
    for round_no in range(1, MAX_ROUNDS + 1):
        draft = call_llm(f"下書きを書く\n依頼: {request}\n直す点: {feedback}")
        verdict = json.loads(call_llm(f"評価する\n{draft}\n基準: 締め切りの日付がある"))
        print(f"{round_no} 回目: {'合格' if verdict['ok'] else '直す → ' + verdict['feedback']}")
        if verdict["ok"]:
            return draft                                   # 基準を満たしたら終える
        feedback = verdict["feedback"]                     # 指摘を次の下書きに渡す
    return draft + "\n（上限回数に達したため、人が確認する）"

if __name__ == "__main__":
    print(run("備品の棚卸しのお願いを書く"))

実行結果：

1 回目: 直す → 締め切りの日付を入れてください
2 回目: 合格
備品の棚卸しにご協力ください。締め切りは 10 月 20 日です。

比較用：エージェントのループ

5 つの型と見比べるために、エージェントの最小形も載せます。違いは 1 か所で、次に何をするかを、コードではなくモデルの応答が決めている点です。

flowchart LR
    In[目的] --> M[モデルが次の一手を決める]
    M -- 道具を使う --> T[道具を実行する]
    T -- 結果を渡す --> M
    M -- 終わりと判断 --> Out[出力]
    M -- 上限回数 --> S[止める]

# agent.py  比較用: エージェント（次の一手をモデルが決めるループ）の最小形
MAX_TURNS = 5
SCRIPT = [("search", "予約 取り消し"), ("read", "cancel.py"), ("finish", "取り消し処理は cancel.py にあります")]

def fake_model(history):            # モデルの代役: 履歴の長さに応じて次の一手を返す
    return SCRIPT[len(history)]

def run_tool(name, arg):
    return f"{name}({arg}) の結果"

def run(goal: str) -> str:
    history = []
    for turn in range(1, MAX_TURNS + 1):
        action, arg = fake_model(history)       # 次に何をするかは、毎回モデルが決める
        if action == "finish":
            return arg
        history.append(run_tool(action, arg))   # 道具を実行し、結果を次の判断材料にする
        print(f"{turn} 手目: {history[-1]}")
    return "上限回数に達したので止めます"

if __name__ == "__main__":
    print(run("取り消し処理の場所を調べる"))

実行結果：

1 手目: search(予約 取り消し) の結果
2 手目: read(cancel.py) の結果
取り消し処理は cancel.py にあります

Anthropic の文書は、エージェントには最大の繰り返し回数などの止める条件を置くこと、区切りや行き詰まったときに人の確認を挟めるようにすること、囲われた環境で十分に試すことを勧めています。

呼び出し回数を数える

型を選ぶときは、呼び出し回数がそのまま応答時間と費用の見積もりになります。上のコードを 1 回ずつ動かし、代役が呼ばれた回数を数えました。

単一エージェントとマルチエージェントの違い

Microsoft の文書は、複雑さを 3 段階に分けています。

同じ文書は、プロンプトの工夫で解ける問題にエージェントは要らないこと、単一エージェントには繰り返し回数の制限が要ることも述べています。「マルチエージェントにするか」は最後に考える問いで、まず単一で足りるかを確かめる、という順番は Anthropic の文書と同じです。

Microsoftの用語との対応表

Microsoft の文書は、マルチエージェントの組み合わせ方を 5 つのオーケストレーション パターンとして挙げています。別名として書かれている語を手がかりに、この記事の型と並べました。

名前は違っても、問うていることは同じです。順番に進むのか、同時に進むのか、誰が次を決めるのかの 3 点で見ると、どちらの用語でも読み替えられます。

型を組み合わせる例

架空の「備品予約システムの問い合わせ対応」を例に、型を組み合わせた形です。

flowchart TD
    In[問い合わせ] --> R{分類する}
    R -- 使い方 --> A1[手引きを探す]
    A1 --> A2[回答を書く]
    R -- 不具合 --> B1[再現手順を整理する]
    R -- 不具合 --> B2[似た報告を探す]
    B1 --> B3[受付文にまとめる]
    B2 --> B3
    R -- その他 --> C[担当へ引き継ぐ]
    A2 --> E{基準と照らす}
    B3 --> E
    E -- 直す --> F[書き直す]
    F --> E
    E -- 合格 --> Out[返信]
    C --> Out

設計のチェックリスト

• 1 回の呼び出しで足りないことを、実際のプロンプトで確かめたか
• 手順を紙に書けるか（書けるならワークフロー）
• 各手順の入力と出力の形を決めたか
• 手順の間に、プログラムでの点検を置いたか
• 繰り返しのある型（評価と改善、オーケストレーターとワーカー、エージェント）に、回数の上限を置いたか
• 上限に達したときの動き（人に確認する、途中の結果を返す）を決めたか
• 呼び出し回数を見積もり、応答時間と費用が見合うか確かめたか
• 途中の出力を記録し、どの手順でずれたかを追えるようにしたか

確かめて分かったこと

• 並列化とオーケストレーターとワーカーは、図にするとほぼ同じ形になる。 違いはコードに出る。並列化は観点の一覧がコードに書かれ、オーケストレーターとワーカーはモデルの応答から一覧を作る。
• ルーティングは、対応表に無いラベルの行き先を書いておかないと動かなくなる。 骨組みでは、知らないラベルを「その他」へ送る 1 行（ROUTES.get の第 2 引数）で受けている。
• 評価と改善は、回数の上限を置いても最大で「2 × 上限」回呼ぶ。 上限 3 回なら 6 回。応答時間の見積もりはこの値で行う。
• Microsoft の文書では、評価と改善にあたる形がグループ チャットの一種として書かれている。 独立した項目を探すと見つけにくい。
• Microsoft のハンドオフは、別名にルーティングが挙がっているが、行き先を途中で決め直す点が違う。 最初の分類だけで行き先が決まるものは、Anthropic の文書でいうルーティングにあたる。

よくある質問

Q. AIエージェントの設計パターンとは何ですか？ A. モデルの呼び出しをどう組み合わせるかの定番の形です。Anthropic の文書では、ワークフローの 5 つの型（プロンプトチェイニング、ルーティング、並列化、オーケストレーターとワーカー、評価と改善）と、モデルが進め方を決めるエージェントに分けて説明されています。

Q. ワークフローとエージェントの違いは何ですか？ A. 次の一手をコードが決めるのがワークフロー、モデルが決めるのがエージェントです。手順を事前に決められるならワークフローのほうが、回数を見積もりやすく、確かめやすくなります。

Q. 並列化とオーケストレーターとワーカーの違いは何ですか？ A. 作業の一覧を誰が決めるかが違います。並列化はコードに書いた一覧を同時に実行し、オーケストレーターとワーカーは指揮役のモデルが入力を見てから一覧を作ります。

Q. マルチエージェントにしたほうがよいのはどんなときですか？ A. 1 つのエージェントでは指示が長くなりすぎる、複数の専門にまたがる、というときです。Microsoft の文書は、直接のモデル呼び出し、道具を持つ単一エージェント、マルチエージェントの順に複雑になると整理しており、手前の段階で足りるかを先に確かめます。

Q. どの型を選べばよいか決められないときはどうすればよいですか？ A. 呼び出し回数の少ないものから試します。1 回の呼び出し、プロンプトチェイニング、ルーティングの順に試し、足りないところにだけ次の型を足すと、どこで良くなったかが分かります。

まとめ

• まず 1 回の呼び出しで足りないかを確かめる。 足りるなら、それが一番速く、確かめやすい。
• 手順を決められるならワークフロー、決められないときだけエージェント。
• ワークフローの型は 5 つ。 プロンプトチェイニング、ルーティング、並列化、オーケストレーターとワーカー、評価と改善。
• 型は呼び出し回数で比べる。 回数がそのまま応答時間と費用の見積もりになる。
• 繰り返しのある型には、回数の上限と、上限に達したときの動きを置く。
• 用語が違っても、順番か同時か、誰が次を決めるかの 3 点で読み替えられる。

参考・出典

• Anthropic「Building effective agents」（2024 年 12 月 19 日公開） https://www.anthropic.com/engineering/building-effective-agents （2026-10-06 確認）
• Microsoft Azure アーキテクチャ センター「AI エージェント オーケストレーション パターン」（2026 年 2 月 12 日更新） https://learn.microsoft.com/ja-jp/azure/architecture/ai-ml/guide/ai-agent-design-patterns （2026-10-06 確認）

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。