Swarm解説: AgentとHandoffで学ぶ軽量マルチエージェント設計

Swarm は、マルチエージェントを大きなフレームワークで理解する前に、Agent と handoff だけでどこまで責務分割を表現できるかを学ぶための lightweight な実装です。

この種の記事は人気や timeline を追い始めるとすぐ古くなります。ここでは README とサンプルから確認しやすい範囲に絞り、設計の読み方と実務での持ち込み方を整理します。

“

関連記事: 全体像から読みたい場合は AIエージェント論文おすすめ11選 も参照してください。

この記事でわかること

1. Swarm の最小抽象: Agent、functions、handoff、context_variables が何を担当するか
2. README サンプルの読み方: カスタマーサポートや予約変更フローをどう責務分割しているか
3. 実務への持ち込み方: 学習用プロトタイプと運用設計の境界をどう見極めるか

基本情報

Swarm を読む前に押さえる前提

Swarm をそのまま採用可否で見ると、議論がすぐ stale になります。先に押さえたいのは次の3点です。

1. 完成品としてではなく教材として読む Swarm の価値は、多数の機能が揃っていることではなく、handoff の境界を最小コードで確認できる点にあります。

2. 学ぶ対象は agent 数ではなく責務分割 重要なのは「何人の agent を並べるか」ではなく、「どこで担当を切り替えると説明責任が明確になるか」です。

3. 運用要件は別レイヤーで設計する 永続化、監査ログ、再試行、承認、失敗時の復旧まで必要なら、orchestration の外側に追加設計が要ります。

Swarm の最小抽象

Swarmマルチエージェントの概念図

1. Agent: 役割を持つ単位

Swarm の Agent は、「誰が何を担当するか」を表す薄いラッパーです。主に次を持ちます。

• name: 担当の識別子
• instructions: その agent が守る判断基準
• functions: 呼び出せる tool や handoff 関数

from swarm import Agent

sales_agent = Agent(
    name="Sales Agent",
    instructions="製品に関する質問に答えてください。",
    functions=[get_product_info, transfer_to_support],
)

この形にしておくと、「営業が持つ知識」と「サポートへ渡す条件」をコード上で分けて読めます。

2. Handoff: 担当の切り替え

Swarm の handoff は、別の Agent を返すことで表現されます。

def transfer_to_support():
    return support_agent

複雑な graph DSL を書かなくても、「この条件なら担当を変える」という設計意図をそのまま関数に落とせるのがポイントです。

実務では、この境界を次のように読むと使いやすくなります。

• 部門が変わる瞬間
• 承認者が変わる瞬間
• 参照する source of truth が変わる瞬間
• 失敗時の責任者が変わる瞬間

3. context_variables: 共有したい最小状態

複数 agent で同じ情報を使いたいときは context_variables を渡します。

context_variables = {
    "customer_id": "12345",
    "booking_id": "ABC789",
    "flight_date": "2024-12-15",
}

ここで重要なのは、何でも共有しないことです。共有状態は少ないほど handoff の意味が崩れません。顧客 ID、申請 ID、注文番号のような stable な識別子に絞る方が運用しやすくなります。

4. routines: 自然言語と関数の接点

Swarm のサンプルでは、routing の判断を instructions と functions の組み合わせで表現します。

triage_agent = Agent(
    name="Triage Agent",
    instructions="""
    顧客の問い合わせを分析し、適切な部署に振り分けてください:
    - 製品の質問 -> 営業担当
    - 技術的な問題 -> サポート担当
    - 返金リクエスト -> 返金担当
    """,
    functions=[transfer_to_sales, transfer_to_support, transfer_to_refunds],
)

この最小構成だけでも、「入口で分類する agent」と「処理を実行する agent」を分けられます。multi-agent の学習ではまずこの分離を理解するのが有効です。

README サンプルから読む 2 つのパターン

パターン1: triage して specialist に渡す

カスタマーサポートのサンプルは、Swarm の考え方を最も素直に示します。

Triage Agent
    -> Sales Agent
    -> Support Agent
    -> Refunds Agent

Swarmのエージェント引継ぎフロー

この構成から読めるのは、次の設計原則です。

• triage agent は解決役ではなく振り分け役に徹する
• specialist agent は担当範囲を狭く保つ
• tool 実行は specialist 側に寄せる
• 返金のような high-risk action は handoff 後に限定する

たとえば Refunds Agent にだけ process_refund を持たせる構成にすれば、「返金処理を誰が実行できるか」がコードで明示されます。

パターン2: 状態を持ったまま別担当へ送る

航空券予約のサンプルでは、context_variables を使って顧客情報や予約情報を共有します。

Triage Agent
    -> Flight Modification Agent
    -> Lost Baggage Agent

このパターンが示すのは、「handoff しても会話文脈だけでは足りない」という点です。予約変更や紛失対応のように業務オブジェクトがある処理では、次の3つを分けて考える必要があります。

• 会話内容: ユーザーが今なにを依頼しているか
• 共有状態: booking_id のような stable な識別子
• 実行権限: 変更や申請を確定してよいか

Swarm のサンプルは、この3つを最小コードで分けて読む教材として役立ちます。

Swarm から学べる設計原則

Swarm の価値は feature list ではなく、multi-agent を必要以上に複雑化しない視点にあります。実務では次の原則に読み替えると使いやすくなります。

1. handoff は「役割変更」ではなく「責任変更」で切る

担当名を増やすだけでは設計は良くなりません。handoff を置くなら、次のどれかが変わるときに限定した方が明確です。

• approval boundary
• source of truth
• 実行可能な tool
• 失敗時の owner

2. shared context は識別子中心で薄く保つ

長い要約や推論結果まで共有し始めると、どの agent が何を判断したのかが曖昧になります。customer_id、ticket_id、order_id などの stable key を中心に持つ方が安全です。

3. triage agent に実処理を載せすぎない

入口 agent が分類も実行も担うと、例外時の切り分けが難しくなります。まずは routing を担当させ、更新系 action は specialist に寄せる構成が読みやすくなります。

4. tool contract は短く deterministic にする

handoff が増えるほど、曖昧な tool は不具合の温床になります。引数が明確で、成功・失敗の戻り値が読みやすい関数から始める方が検証しやすくなります。

5. orchestration と運用機能は分けて考える

Swarm のような lightweight 実装は orchestration を学ぶには向きますが、次の論点は別途確認が必要です。

• state persistence
• tracing / audit log
• retry / timeout
• approval / guardrail
• secret management

どんな時に読む価値があるか

向いているケース

• multi-agent の最小設計を理解したい
• triage と specialist の責務分割を試したい
• handoff を関数レベルで把握したい
• 大きな framework を入れる前に概念を揃えたい

追加設計が必要なケース

• 本番で監査ログや承認フローが必要
• 失敗時の再実行や復旧手順を定義したい
• 複数システムにまたがる long-running task を扱いたい
• model 切り替えや vendor portability を強く求める

Swarm を読むべきかどうかは、「本番でそのまま使うか」ではなく、「handoff の考え方を最小構成で学ぶ価値があるか」で判断するとぶれにくくなります。

Agents SDK へ読み替えるときの確認項目

Swarm の README を読む目的が学習だけで終わらないなら、次に確認したいのは production 向けの運用機能です。repo 内の関連整理でも、Swarm は experimental / educational、production 側は Agents SDK を見る流れに寄せています。

確認ポイントは次の4つです。

1. 状態をどこに残すか handoff のたびに必要な ID や中間成果物をどこへ永続化するか。

2. 実行履歴をどう追うか どの agent がどの判断をし、どの tool を呼んだかを後から追跡できるか。

3. 承認境界をどう置くか 返金、送信、更新のような irreversible action をどこで止めるか。

4. 失敗時にどこへ戻すか retry でよいのか、人に戻すのか、別 agent に handoff するのか。

Swarm はこれらの論点を全部解決するためのものではなく、どこに境界を置くべきかを見つけるための教材として読む方が実務に接続しやすくなります。

FAQ

Q1. Swarm は本番環境向けのフレームワークですか？

README と既存の repo 内整理では、Swarm は experimental / educational な位置づけとして扱うのが妥当です。プロトタイプや学習には向きますが、運用に入れるなら永続化、監査、承認、失敗復旧を別途設計してください。

Q2. agent を増やせば精度は上がりますか？

必ずしも上がりません。agent 数を増やすより、handoff の境界と shared context を明確にした方が改善しやすいことが多いです。まずは triage と 2 つか 3 つの specialist から始める方が設計を検証しやすくなります。

Q3. context_variables には何を入れるべきですか？

顧客 ID、案件 ID、予約 ID のような stable な識別子を中心に入れるのが基本です。長い推論結果や曖昧なメモを共有しすぎると、どの agent の責務かが崩れやすくなります。

Q4. Swarm から他の実装へ移るとき、何を持ち出すべきですか？

持ち出す価値が高いのは framework 名より次の設計資産です。

• triage と specialist の分割
• handoff の条件
• shared context の schema
• tool ごとの approval boundary

Q5. まずどこを読むと理解しやすいですか？

最初は README の customer support サンプルで Agent と handoff を確認し、その次に context_variables を使う予約変更サンプルを見る流れが理解しやすいです。機能一覧より先に、責務の切り方を読む方が Swarm の価値を掴みやすくなります。

まとめ

Swarm は、multi-agent を大きな機能比較で学ぶのではなく、Agent と handoff の最小抽象で責務分割を掴むための lightweight な実装です。

押さえておきたい点は3つです。

1. 学ぶべきは popularity ではなく境界設計 誰が分類し、誰が実行し、どこで承認するかを明示することが中心です。

2. shared context は薄く保つ 識別子ベースで状態を渡し、推論や実行責任を混ぜない方が handoff が機能します。

3. 運用機能は別途確認する 永続化、監査、再試行、承認まで必要なら、Swarm の外側で運用設計を足す前提で考える必要があります。

次のステップ

• customer support サンプルで triage と specialist の境界を読む
• 自分の業務フローを handoff の条件で分解してみる
• production を想定する場合は状態、監査、承認の設計を先に書き出す

関連記事

• AIエージェント論文おすすめ11選
• MetaGPT解説: SOPで学ぶマルチエージェント協調

参考リソース

• GitHub: openai/swarm
• OpenAI Cookbook: Orchestrating agents
• OpenAI Agents SDK