2024年10月、サンフランシスコ。

OpenAIの研究者 Shyamal Anadkat は、GitHubリポジトリの README に警告文を書き込んでいました。

「これはプロダクションで使わないでください」 「公式製品ではありません」 「メンテナンスもしません」

彼はこれを「クックブック」——学習用のレシピ集と位置づけました。複雑なマルチエージェント協調を「電話転送」と同じくらいシンプルに実装できることを示すための教材。

しかし、予想外の事態が起きます。

わずか1週間で約2,400スター、最終的に 20,000スター を獲得。「使うな」と言われたツールを、開発者たちは熱狂的に歓迎しました。週間成長率 1.992倍。

慌ててShyamalはツイートします：

"swarmは公式製品じゃありません。クックブックみたいなものです"

しかし時すでに遅し。Swarm は、マルチエージェント設計の新しい標準を確立し始めていました。

これはOpenAIの失敗だったのか？

いいえ。実はこれこそが 計画通り でした。

OpenAIには野心的な戦略があったのです。「教育用として最高のツールを無償提供し、開発者エコシステムを拡大する。そして5ヶ月後、プロダクション対応版を発表する」。

2025年3月、計画は完遂されます。Agents SDK——Swarmの設計思想を継承した本番対応版がリリースされました。

「使うな」は、本気だった。 「教育用」も、本気だった。 そして、その戦略は見事に成功した。

本記事では、わずか5ヶ月で「卒業」しながらも、マルチエージェント設計の新しい標準を確立したSwarmの仕組みと、その驚くべき戦略を解説します。

関連記事: 本記事は「AIエージェント論文おすすめ9選」の詳細解説記事です。他の論文も合わせてご覧ください。

この記事でわかること

1. Swarmの基本概念: 「Agent」と「Handoff」という2つのシンプルな抽象化で軽量なマルチエージェントを実現する仕組み
2. 実装パターン: カスタマーサポートや航空券予約システムでの具体的なコード例
3. フレームワーク選択: LangGraphやCrewAIとの比較と、ユースケース別の選択指針

基本情報

Swarmの仕組みを図解で理解

Swarmは**Agent（エージェント）とHandoff（ハンドオフ）**という2つの核心的な概念で構成されています。

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

Agent（エージェント）：役割を持つ単位

各Agentは、固有の指示（instructions）と、使用可能なツール（functions）を持ちます。Agentは特定のタスクを担当する「専門家」として機能します。

やっていること: エージェントに「名前」「指示」「使えるツール」を設定

from swarm import Agent

sales_agent = Agent(
    name="Sales Agent",
    instructions="あなたは営業担当です。顧客の質問に答え、適切な部署にルーティングしてください。",
    functions=[get_product_info, transfer_to_support]
)

Handoff（ハンドオフ）：エージェント間の引き継ぎ

**Handoff（ハンドオフ）**とは、タスクを別のエージェントに引き継ぐ仕組みです。関数の戻り値としてAgentを返すことで実現します。

これにより、複数のエージェントが協力して複雑なタスクを処理できます。

やっていること: 別のエージェントを返すだけで「引き継ぎ」が完了

def transfer_to_support():
    """サポート担当に転送する"""
    return support_agent  # 別のAgentを返す

Routines（ルーティング）：処理フローの制御

**Routines（ルーティング）**は、処理の流れを制御する仕組みです。自然言語の指示とPythonコードを組み合わせて定義します。

やっていること: 自然言語で「振り分けルール」を定義

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

実装例1: カスタマーサポートシステム

Swarmの公式サンプルとして提供されている、カスタマーサポートシステムの実装例です。

システム構成

Triage Agent（振り分け）
    ├── Sales Agent（営業）
    ├── Support Agent（サポート）
    └── Refunds Agent（返金処理）

完全な実装コード

やっていること: 4つのエージェント（振り分け・営業・サポート・返金）を連携させるシステム

from swarm import Swarm, Agent

client = Swarm()

# 各部署のエージェント定義
def transfer_to_sales():
    """営業担当に転送"""
    return sales_agent

def transfer_to_support():
    """サポート担当に転送"""
    return support_agent

def transfer_to_refunds():
    """返金担当に転送"""
    return refunds_agent

def process_refund(item_id: str, reason: str = "N/A"):
    """返金処理を実行"""
    return f"返金処理完了: {item_id} (理由: {reason})"

# Triage Agent
triage_agent = Agent(
    name="Triage Agent",
    instructions="顧客の問い合わせを適切な部署に振り分けてください。",
    functions=[transfer_to_sales, transfer_to_support, transfer_to_refunds]
)

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

# Support Agent
support_agent = Agent(
    name="Support Agent",
    instructions="技術的な問題を解決してください。"
)

# Refunds Agent
refunds_agent = Agent(
    name="Refunds Agent",
    instructions="返金リクエストを処理してください。",
    functions=[process_refund]
)

# 実行
response = client.run(
    agent=triage_agent,
    messages=[{"role": "user", "content": "製品が壊れたので返金してほしい"}]
)
print(response.messages[-1]["content"])

実行フロー

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

[User] 製品が壊れたので返金してほしい
    ↓
[Triage Agent] 返金リクエストを検出 → transfer_to_refunds()
    ↓
[Refunds Agent] 返金処理を実行 → process_refund()
    ↓
[Output] 返金処理完了

実装例2: 航空券予約システム

より複雑なユースケースとして、航空券予約システムの実装例です。

システム構成

Triage Agent（振り分け）
    ├── Flight Modification Agent（予約変更）
    │   ├── change_flight()
    │   └── cancel_flight()
    └── Lost Baggage Agent（手荷物紛失対応）
        └── file_claim()

主要なコード

**context_variables（コンテキスト変数）**を使うことで、エージェント間で状態を共有できます。これにより、顧客IDや予約IDなどの情報を複数のエージェントで利用できます。

やっていること: エージェント間で顧客情報を共有しながら予約変更・手荷物対応を処理

# Context変数で状態を共有
context_variables = {
    "customer_id": "12345",
    "booking_id": "ABC789",
    "flight_date": "2024-12-15"
}

def change_flight(new_date: str):
    """フライト日程を変更"""
    return f"フライトを{new_date}に変更しました"

def cancel_flight():
    """フライトをキャンセル"""
    return "フライトをキャンセルしました。返金処理を開始します。"

def file_claim(description: str):
    """手荷物紛失の申請"""
    return f"申請を受け付けました: {description}"

# Flight Modification Agent
flight_agent = Agent(
    name="Flight Modification",
    instructions="""
    予約変更リクエストを処理します。
    - 日程変更の場合: change_flight()を呼び出す
    - キャンセルの場合: cancel_flight()を呼び出す
    """,
    functions=[change_flight, cancel_flight, transfer_to_triage]
)

# Lost Baggage Agent
baggage_agent = Agent(
    name="Lost Baggage",
    instructions="手荷物紛失の申請を受け付けます。",
    functions=[file_claim, transfer_to_triage]
)

# 実行（context_variablesで状態を渡す）
response = client.run(
    agent=triage_agent,
    messages=[{"role": "user", "content": "12月20日に変更したい"}],
    context_variables=context_variables
)

LangGraphやCrewAIとの比較

マルチエージェントフレームワークとして、LangGraphやCrewAIと比較してみましょう。

比較表

各フレームワークの特徴

Swarm（OpenAI）

• 軽量でシンプル、学習用に最適
• OpenAI APIに依存
• 本番環境での利用は非推奨（実験的）

LangGraph（LangChain）

• グラフベースの柔軟なワークフロー設計
• 複雑な状態管理が可能
• 本番運用の実績あり

CrewAI

• 「役割」ベースのチーム編成
• 宣言的なタスク定義
• 比較的新しいが人気急上昇中

どれを選ぶべきか？

ユースケース

Swarmが適している具体的なユースケースを紹介します。

1. カスタマーサポートの振り分け

顧客 → Triage → [Sales / Support / Billing]

• 問い合わせ内容を分析し、適切な部署に自動ルーティング
• 各部署のエージェントが専門的に対応

2. マルチステップの申請処理

申請受付 → 審査 → 承認/却下 → 通知

• 各ステップを専門エージェントが担当
• Handoffで処理を順番に引き継ぎ

3. 多言語対応チャットボット

言語検出 → [日本語Agent / English Agent / 中文Agent]

• 言語ごとに専門エージェントを配置
• 言語検出エージェントがルーティング

4. 教育・学習用途

• マルチエージェントの基本概念を理解
• シンプルなコードで動作原理を学習
• 本番フレームワーク（LangGraph等）への橋渡し

FAQ

Q1. Swarmは本番環境で使えますか？

推奨されません。 Swarmは「教育・実験目的」で設計されており、OpenAI公式も本番利用を想定していません。

本番環境ではLangGraphやCrewAIを検討してください。

Q2. OpenAI以外のLLMで使えますか？

現状は難しいです。 SwarmはOpenAI APIに直接依存しているため、Claude、Gemini、Llamaなど他のLLMでは使用できません。

他のLLMを使いたい場合はLangGraphを推奨します。

Q3. LangGraphとの違いは？

抽象化レベルと目的が異なります。

• Swarm: シンプル、学習用、OpenAI専用
• LangGraph: 柔軟、本番向け、LLM非依存

Q4. どのくらいのコストがかかりますか？

Swarm自体は無料ですが、OpenAI APIの利用料金がかかります。エージェント間のHandoffでも追加のAPI呼び出しが発生します。

そのため、複雑なワークフローではコストが増加します。

Q5. エージェント数に制限はありますか？

技術的な制限はありません。

ただし、エージェント数が増えるとAPI呼び出し回数が増え、レイテンシとコストが増加します。実用上は5-10エージェント程度が目安です。

Q6. context_variablesとは何ですか？

エージェント間で状態を共有するための仕組みです。顧客ID、予約ID、セッション情報などをエージェント間で受け渡せます。

辞書形式でデータを管理し、各エージェントが必要な情報にアクセスできます。

【驚きの事実】Swarmの舞台裏

Shyamal Anadkatという男

Shyamal Anadkat はOpenAIのSolution Team所属の研究者。マルチエージェントシステムの「人間工学的インターフェース」を研究しています。

予想外の反響に、彼は慌ててこうツイートしました：

"swarm is not an official openai product. think of it more like a cookbook." （Swarmは公式製品じゃありません。クックブックみたいなものです）

しかし時すでに遅し。開発者コミュニティは「使うな」と言われたツールを歓迎し、週間成長率1.992倍を記録しました。

「廃止」ではなく「卒業」

**「廃止」と報道されましたが、実態は「教育用として成功しすぎて、プロダクション版が必要になった」**のです。

Agents SDKはSwarmの設計思想を継承しつつ、以下を追加：

• 状態永続化
• トレーシング
• エラーハンドリング
• 本番環境対応

OpenAIの野心：「AIのOS」になる

Swarmは単なるフレームワークではありませんでした。OpenAIの壮大な戦略の第一歩だったのです。

「より良いチャットボットを作るのではなく、AIのオペレーティングシステムになる」

この戦略の核心は「開発者エコシステムの拡大」。教育用ツールを無償提供し、世界中の開発者がマルチエージェントに触れる機会を作る。そしてコミュニティが成熟したら、プロダクション版を発表する。

Swarm → Agents SDKの流れは、この戦略の完璧な実行でした。

「電話転送」の比喩がすべてを変えた

OpenAIの公式ドキュメントはこう説明する：

"A handoff is when an agent transfers an active conversation to another agent, much like when you get transferred to someone else on a phone call." （ハンドオフとは、エージェントが会話を別のエージェントに引き継ぐこと——電話で他の担当者に転送されるのと同じ）

この比喩のおかげで、複雑なマルチエージェント協調が直感的に理解できるようになった。

2030年に471億ドル市場へ

Gartnerによると、2028年までに企業向けソフトウェアの33%がエージェントAI機能を含むと予測されている。グローバルAIエージェント市場は**2030年までに471億ドル（約7兆円）**に達する見込みだ。

Swarmは、このトレンドを加速させた「教育用」フレームワークだった。

まとめ

Swarmは、OpenAIが提案するマルチエージェント協調の軽量フレームワークです。わずか5ヶ月で廃止されましたが、その設計思想は今もAIエージェント開発に影響を与え続けています。

主要ポイント

1. AgentとHandoffの2概念で構成されるシンプルな設計で、学習コストが低い
2. 教育・実験目的で設計されており、本番運用にはLangGraphやCrewAIを検討する
3. OpenAI APIに依存するため、他のLLMでは使用できない点に注意

人に話したくなるポイント

• 「使うな」と言われたのに20,000スターを獲得
• わずか5ヶ月で廃止→ Agents SDKに進化
• 「電話転送」の比喩で複雑なマルチエージェント協調を直感的に
• 2030年にAIエージェント市場は**471億ドル（約7兆円）**規模へ
• 開発者Shyamal Anadkatが予想外の人気に慌ててツイート

次のステップ

• Swarmの公式リポジトリでサンプルコードを実行する
• LangGraphやCrewAIとの設計思想の違いを比較する
• 本番環境で使用するフレームワークを選定する

関連記事

• AIエージェント論文おすすめ9選
• ReAct: 推論と行動を統合するAIエージェントの原点

参考リソース

• GitHub: openai/swarm
• OpenAI Cookbook: Swarm Examples
• Swarm公式ドキュメント

本記事はAIエージェント論文シリーズの一環として作成されました。