弊社は生成AIを強みとするベトナムオフショア開発・ラボ型開発や、生成AIコンサルティングなどのサービスを提供しており、最近はありがたいことに生成AIと連携したシステム開発のご依頼を数多く頂いています。
OpenAI が発表した Swarm は、複数のAIエージェントを協調させて複雑なタスクを実行するための、軽量で人間工学に基づいた実験的なフレームワークです。
本記事では、Swarmの特徴や仕組み、そしてGoogle Colabで動作する簡単なサンプルをご紹介しようと思います。
1. Swarm の概要
1.1 Swarm とは何か?
Swarm は、複数のAIエージェントを協調させて複雑なタスクを実行するためのフレームワークです。
「軽量」「人間工学に基づいた」「実験的」というキーワードで表現されます。これは、最小限の抽象化でエージェントの構築とオーケストレーションを可能にすることを目指しており、ユーザーは複雑な設定なしにマルチエージェントシステムを簡単に構築・実験できます。
Swarm は、複雑な問題を小さなタスクに分割し、それぞれのタスクを専門のエージェントに割り当てることで、効率的な問題解決を可能にします。
1.2 Swarm の特徴
- 軽量で人間工学に基づいた設計: シンプルなインターフェースと最小限の抽象化により、マルチエージェントシステムの構築を容易にします。複雑な設定やボイラープレートコードを必要とせず、直感的に利用できます。
- 高度な制御性とテスト容易性: Swarm は、エージェントの動作を詳細に制御し、テストを容易にするための機能を提供します。各エージェントの役割や機能をカスタマイズし、システム全体の動作を細かく調整できます。
- スケーラビリティと柔軟性: 必要に応じてエージェントを追加することで、システムを容易にスケールできます。各エージェントは特定のタスクに特化できるため、複雑な問題を効率的に処理できます。
- ハンドオフとルーチン: Swarm のコアコンセプトは「ハンドオフ」と「ルーチン」です。ルーチンはエージェントの動作を定義し、ハンドオフはエージェント間の制御の移行を管理します。これにより、複数のエージェントが連携して複雑なタスクを処理できます。
- クライアントサイド実行: Swarm は、OpenAI の Assistants API (o1-preview/mini) とは異なり、クライアントサイドで実行されます。つまり、ユーザーは Swarm の動作を完全に制御し、状態や処理内容を把握できます。これは、デバッグやシステムの挙動の理解に役立ちます。
2.マルチエージェントってなに?
シングルエージェントとマルチエージェントの仕組みには、大きな違いがあります。以下にそれぞれの特徴とマルチエージェントのメリットをまとめます。
2-1. シングルエージェント(一度に実行):
- 仕組み: シングルエージェントは、1回の入力に基づいて一度にすべてのタスクを実行します。与えられたプロンプトに基づいて、一気にアクションを実行します。
- 実行の流れ:
- LLM(大規模言語モデル)が入力を処理します。
- エージェントがツールの呼び出しを生成します。
- すべてのツールが一度に実行され、結果が返されます。
メリット:
- シンプルで計算ステップが少なく、構成が簡単。
- 反復やフィードバックが必要ない、単純なタスクには最適。
デメリット:
- 反復処理や、途中の結果に基づいて行動を修正することができない。
- 複雑なタスクや段階的な意思決定が必要な場合には不向き。
2-2. マルチエージェント(マルチステップ / ReAct):
- 仕組み: マルチエージェントまたは反復処理を行う単一エージェントによって、タスクが複数のステップに分割され、観察結果に基づいてアクションを調整しながら繰り返し実行されます。
- 実行の流れ:
- LLMが入力を処理します。
- エージェントがタスクと以前の観察結果に基づいてツールの呼び出しを生成します。
- ツールが実行され、その結果が観察されます。
- エージェントは記憶と推論を更新し、結果に基づいてアクションを調整します(思考 → 行動 → 観察ループ)。
- タスクが解決されるまで、これを繰り返します。
メリット:
- 反復的な推論: 各ステップの結果を元に、次のアクションを改善できる。
- 柔軟性: より複雑で段階的な問題解決に適しており、途中で結果を見ながら柔軟に対応できる。
- エラー処理: 実行中にエラーや最適でない結果が出た場合、その都度修正できる。
- 記憶の活用: 各ステップの観察結果を記憶し、次のステップに活かすことで、より賢明な判断が可能。
デメリット:
- 複雑さ: 構成や実行が複雑で、リソースを多く消費する。
- 実行時間の長さ: 反復的な処理を行うため、解決までの時間がかかることがある。
3. Swarm の技術的仕組み
Swarm は「エージェント」と「ハンドオフ」という2つの基本的な抽象化に基づいています。
3.1 エージェント
エージェントは、特定の指示、機能、ツールをカプセル化したものです。エージェントは、会話の任意の時点で他のエージェントに制御をハンドオフできます。エージェントは、特定のワークフローやステップを表現するためにも使用できます。
- 指示 (Instructions): エージェントがどのように動作すべきかを指示するテキストです。例えば、「あなたは顧客サポートエージェントです。」のように、エージェントのペルソナを定義します。指示は文字列として直接指定することも、コンテキスト変数を受け取る関数を指定することも可能です。この関数は、client.run() に渡された context_variables を引数として受け取ります。
- 関数 (Functions): エージェントが実行できる Python 関数のリストです。関数は通常、文字列型の値を返します。関数がエージェントオブジェクトを返すと、制御はそのエージェントにハンドオフされます。関数は context_variables を引数として受け取ることができ、これにより、エージェントは現在のコンテキストに基づいて動作を調整できます。
- 機能スキーマ (Function Schemas): Swarm は、提供された関数を自動的に JSON Schema に変換します。このスキーマは、Chat Completions API にツールとして渡され、エージェントが適切なツールを選択し、正しい引数で呼び出すのに役立ちます。docstring、型ヒント、必須パラメータなどがスキーマ生成に利用されます。
- コンテキスト変数 (Context Variables): エージェント間で共有される変数です。これにより、エージェントは情報を共有し、協調してタスクを実行できます。client.run() に辞書形式で渡され、エージェントの指示や関数で使用できます。
3.2 ハンドオフ
ハンドオフは、あるエージェントから別のエージェントへの制御の移行です。これは、関数がエージェントオブジェクトを返すことで実現されます。ハンドオフにより、異なる専門知識を持つエージェント間でタスクをスムーズに引き継ぐことができます。
- Result オブジェクト: Result オブジェクトは、ハンドオフ、値の返却、コンテキスト変数の更新を同時に行うための仕組みです。Result オブジェクトは、value (関数の戻り値)、agent (ハンドオフ先のエージェント)、context_variables (更新されたコンテキスト変数) を属性として持ちます。
- 状態機械: Swarm の動作は状態機械としてモデル化できます。各エージェントは1つの状態を表し、ハンドオフは状態遷移を表します。ユーザーからの入力やエージェントの関数呼び出しによって、状態遷移がトリガーされます。
3.3 Swarm の動作原理
- 初期エージェントの選択: client.run() に初期エージェントとユーザーメッセージが渡されます。
- プロンプト生成と LLM 呼び出し: Swarm は、現在のエージェントの指示とメッセージ履歴を元にプロンプトを生成し、OpenAI API 互換クライアントを通して LLM (例: GPT-4o) を呼び出します。
- 関数呼び出し: LLM が関数を呼び出す指示を返した場合、Swarm は対応する Python 関数を実行します。
- ハンドオフ: 関数がエージェントオブジェクトを返した場合、Swarm は現在のエージェントをハンドオフ先のエージェントに切り替えます。
- コンテキスト変数の更新: 関数が Result オブジェクトを返した場合、Swarm はコンテキスト変数を更新します。
- レスポンスの返却: LLM が関数呼び出し以外の応答を返した場合、Swarm はそれをユーザーへのレスポンスとして返します。
- ステップ2〜6の繰り返し: LLM が最終的な回答を返すまで、ステップ2〜6を繰り返します。
4. Swarm のユースケースと価値提供
Swarm は様々なユースケースで活用でき、開発者に多くの価値を提供します。
4.1 ユースケース
- 複雑なシミュレーション: 複数のエージェントが相互作用する複雑なシミュレーションを構築できます。例えば、市場の動向をシミュレートする際に、各エージェントを異なる市場参加者(消費者、企業、政府など)としてモデル化できます。
- 大規模データ分析: データの分割と並列処理によって、大規模なデータ分析を効率化できます。各エージェントがデータの一部を処理し、結果を統合することで、処理時間を短縮できます。
- 動的な問題解決環境: 状況に応じてエージェントの動作を動的に変更することで、複雑な問題を解決できます。例えば、リアルタイムのデータに基づいて意思決定を行う必要がある場合、Swarm を使用することで、状況の変化に柔軟に対応できます。
- カスタマーサービスボット: 顧客の質問に応じて適切な担当エージェントに転送するなど、高度なカスタマーサービスボットを構築できます。例えば、「払い戻し」に関する質問は払い戻しエージェントに、「販売」に関する質問は販売エージェントに転送できます。(例:航空会社の顧客サービス、サポートボット
- パーソナルアシスタント: 複数のタスクを処理できるパーソナルアシスタントを構築できます。例えば、スケジュールの管理、情報の検索、商品の購入など、様々なタスクを異なるエージェントに割り当てることができます。
- 複雑なワークフローの自動化: 複数のステップを含むワークフローを自動化できます。例えば、商品の注文から発送、顧客への通知まで、一連のプロセスを複数のエージェントに分割して自動化できます。
4.2 Swarm が提供する価値
上記のようなユースケースを通して、Swarm は開発者に以下の価値を提供します。
- 多数の独立した機能や指示の効率的な処理: 単一のプロンプトでは表現が難しい複雑なシステムを、複数のエージェントに分割することで、効率的に構築・管理できます。
- マルチエージェントシステム学習の促進: シンプルな API と明確な動作原理は、マルチエージェントシステムの概念理解を容易にし、学習コストを低減します。
- システム動作の完全な制御: クライアントサイド実行により、デバッグやシステム挙動把握が容易になり、開発者は高いレベルでシステムを制御できます。
- 軽量でスケーラブルなソリューション: Swarm の設計は軽量でスケーラブルであるため、リソースに制約がある環境や大規模システムにも適しています。
5. OpenAI の既存言語モデルとの比較
Swarm は OpenAI の大規模言語モデル (LLM) を活用して動作しますが、単体の LLM とは異なる特徴を持ちます。ここでは、OpenAIが提供するGPT-4o および Assistants API との比較を通して Swarm の特徴を明確化します。
5.1 GPT-4o との比較
Swarm は GPT-4o のような単一の言語モデルを利用しますが、その役割は異なります。GPT-4o は強力な言語理解と生成能力、画像や音声の理解能力を持つ単一のモデルですが、Swarm は複数のエージェントをオーケストレートするためのフレームワークです。
GPT-4o は、APIを通して利用する場合、メモリ機能(会話履歴の保持)は提供されません。ただし、ChatGPT のインターフェースを通じて GPT-4o を利用する場合は、メモリ機能を利用可能です。
Swarm は、複雑なタスクを小さなタスクに分割し、それぞれを GPT-4o などの LLM を搭載したエージェントに割り当てることで、全体的な効率と柔軟性を向上させます。GPT-4o 単体では、複雑なマルチステップのタスクや、異なる専門知識を必要とするタスクを効率的に処理することが難しい場合があります。
Swarm は、このようなタスクを複数のエージェントに分割することで、問題を解決します。また、Swarm は Python で実装されており、関数の呼び出しや外部システムとの連携が容易です。一方、GPT-4o は API 経由で利用するため、Swarm のような柔軟な制御はできません。
5.2 Assistants API との比較
Swarm は Assistants API とも設計思想が大きく異なります。
Assistants API は、会話履歴やツールの利用状況などを OpenAI のサーバーサイドで管理するマネージドサービスです。
一方、Swarm はクライアントサイドで実行され、状態を保持しません。つまり、各 client.run() 呼び出しは独立しており、前の呼び出しの状態は引き継がれません。これは、Assistants API のようなセッション管理やメモリ機能を必要としない軽量なアプリケーションに適しています。
Swarm は、開発者がシステムの動作を完全に制御し、カスタマイズしたい場合に適しています。また、Assistants API は OpenAI の API キーが必要ですが、Swarm は OpenAI API 互換クライアントを介して様々な LLM を使用できるため、オープンソースの LLM や独自の LLM を利用することも可能です。
6. オープンソース化の理由
Swarm は、マルチエージェントシステム構築のための実験的なフレームワークとして、教育的な目的でオープンソース化されました。
OpenAI は、Swarm を通じて、より多くの人にマルチエージェントシステムの設計と実装を学び、その可能性を探求してもらいたいと考えています。オープンソース化により、コミュニティからのフィードバックや貢献を通じて、Swarm 自体の発展も期待されています。
ただし、実験的なプロジェクトであるため、公式サポートや積極的な開発は行われていない点に注意が必要です。
7. Swarm の使用方法
7.1 インストール
Python 3.10 以上が必要です。
pip install git+https://github.com/openai/swarm.git
7.2 基本的な使用方法
from swarm import Swarm, Agent
# Swarm クライアントの初期化
client = Swarm()
# エージェントBへの転送関数
def transfer_to_agent_b():
return agent_b
# エージェントAの定義
agent_a = Agent(
name="Agent A",
instructions="あなたは親切なエージェントです。",
functions=[transfer_to_agent_b], # ハンドオフ関数
)
# エージェントBの定義
agent_b = Agent(
name="Agent B",
instructions="俳句だけで話してください。",
)
# Swarm の実行
response = client.run(
agent=agent_a, # 初期エージェント
messages=[{"role": "user", "content": "エージェントBと話したいです。"}],
)
# レスポンスの出力
print(response.messages[-1]["content"])
7.3 Google Colab での実行例: GPT-4o-mini を使用
以下は、Google Colab で実行可能な、GPT-4o-mini をバックエンドとして使用したコード例です。実際に実行するには、OpenAI API キーの設定が必要です。openai ライブラリのインストールと認証も忘れずに行ってください。
!pip install openai
!pip install git+https://github.com/openai/swarm.git
import os
from google.colab import userdata
# OpenAI API キーを環境変数に設定
os.environ["OPENAI_API_KEY"] = userdata.get("OPENAI_API_KEY")
from swarm import Swarm, Agent
# Swarm クライアントの初期化
client = Swarm() # 環境変数に設定されたAPIキーが自動的に使用される
# エージェントBへの転送関数
def transfer_to_agent_b():
return agent_b
# エージェントAの定義
agent_a = Agent(
name="Agent A",
instructions="あなたは親切なエージェントです。",
model="gpt-4o-mini", # モデルを指定
functions=[transfer_to_agent_b], # ハンドオフ関数
)
# エージェントBの定義
agent_b = Agent(
name="Agent B",
instructions="俳句だけで話してください。",
model="gpt-4o-mini", # モデルを指定
)
# Swarm の実行
response = client.run(
agent=agent_a, # 初期エージェント
messages=[{"role": "user", "content": "エージェントBと話したいです。"}],
)
# レスポンスの出力
print(response.messages[-1]["content"])
実行すると、以下のようなレスポンスが返ってきました。
風の中
ささやく声が
響き合う
# --- 以下、前のエージェントを再利用した例(状態は引き継がれない)---
messages = [{"role": "user", "content": "俳句を詠んでください。"} ]
response = client.run(agent=agent_a, messages=messages)
print(response.messages[-1]["content"])
上記のように定義済みのエージェントへ再度メッセージを送ってみます。
もちろんです!以下のような俳句はいかがでしょうか。
秋の風
葉が舞い散る
夕焼け空
他のテーマや季節についての俳句を希望される場合は、お知らせください。
俳句はもう十分なので、別のタスクをやってもらいます。本当は関数としてちゃんとした処理を実装しなければいけませんが、今回はテストなので、ダミーの処理だけ入れています。
# --- 以下、関数呼び出しの例(ツール呼び出し)---
# 関数の定義
def get_weather(location: str):
"""指定された場所の天気を取得します。"""
# 実際には外部API等を呼び出す - この例ではダミーデータを返す
return f"{location}の天気は晴れです。"
# エージェントAにツールを追加
agent_a.functions = [get_weather]
messages = [{"role": "user", "content": "ハノイの天気を教えてください。"} ]
response = client.run(agent=agent_a, messages=messages)
print(response.messages[-1]["content"])
すると、以下のような回答が返ってきます。
ハノイの天気は晴れです。
これだけだとエージェントがやっているタスクが簡単過ぎてなにが便利なのかわかりませんが、ハンドオフが簡単にできるため、今はワークフローなどを作ってやっている業務を、エージェントに自律的にやってもらうということができそうです。
8. Swarm の将来と課題
Swarm は実験的なフレームワークであるため、今後の開発が期待されます。長期記憶の管理、マルチエージェントの連携強化、ツール拡充などが挙げられています。
- 長期記憶の管理: 現在の Swarm は、client.run() の呼び出しごとに状態がリセットされます。長期記憶を導入することで、より複雑なタスクや継続的な対話が可能になります。
- マルチエージェントの連携強化: エージェント間の通信や協調動作をより洗練させることで、複雑な問題解決能力を向上させることができます。
- ツール拡充: 画像処理、音声処理、外部 API 連携など、より多様なツールを提供することで、Swarm の適用範囲を広げることができます。
また、LLM が抱える課題への対策も重要です。
- ハルシネーション: LLM は事実とは異なる情報を生成する「幻覚」を起こす可能性があります。Swarm でもこの問題は発生する可能性があり、対策が必要です。
- エラー処理: LLM が予期しない出力を生成した場合や、ツールの実行に失敗した場合のエラー処理を robust に実装する必要があります。
- パフォーマンス: LLM の呼び出し回数が増えると、計算コストとレイテンシが増加します。エージェントの設計やプロンプトエンジニアリングによって、LLM の呼び出し回数を最小限に抑えることが重要です。