マルチエージェントを動かしてみよう｜クラウド上で複数AIを協調させる最小構成
「マルチエージェント」と聞くと LangGraph や AutoGen のような専用フレームワークを想像しがちですが、本質は 「役割の違う複数のLLM呼び出しを、自前のコードでつなぐ」だけ です。
この記事では特定のフレームワークに頼らず、LLM API直叩き＋数十行のPython で複数AIを協調させる最小構成を作ります。
- 対象読者：Pythonの基本文法が分かり、LLMのAPIを1回でも叩いたことがある初級エンジニア。
- 読み終えると：3体のエージェント（計画役・作業役・レビュー役）が順番に協調して1つのタスクを仕上げる仕組みを、自分のコードで動かせるようになります。さらにそれをクラウド上で動かすところまで体験できます。
- フレームワーク非依存：仕組みが分かれば、後でどのフレームワークに乗り換えても「内部で何が起きているか」が読めるようになります。前提・環境
項目
内容
言語
Python 3.10以上（3.12 で確認）
ライブラリ
openai（2.x 系）アカウント
OpenAI API キー（他社LLMでもほぼ同じ構造で書けます）
クラウド
後半で GPUSOROBAN（ハイレゾのGPUクラウド）を使用
想定コストこの記事の手順は 数十円〜数百円程度（モデルや入力量で変動） で試せます。
- ローカル＋OpenAI APIでの動作確認：1回のフル実行（3エージェント分の呼び出し）でおおよそ数円程度。10回試しても数十円。
- GPUSOROBAN：1時間50円〜の従量課金。今回の検証は1〜2時間あれば終わるので100円程度。停止中は課金されないので、使い終わったらインスタンスを停止すればそれ以上はかかりません。
LLMのAPI課金は「使った分だけ」なので、ループが暴走して何百回も呼び出すと一気に高額化 します。対策は後述の「コスト・運用上の注意」で必ず設定してください。
NVIDIA H200を搭載したGPUが、業界最安値で使える！
最先端のNVIDIA H200を、業界最安値クラスでご提供。学習・推論のスピードはそのままに、GPUコストを大幅圧縮。生成AI・LLM学習・シミュレーションなど大規模計算に最適。オンプレミスや他社クラウドと比べても圧倒的に低コストで、最新GPUを手軽に利用できます。
そもそも「マルチエージェント」とは？
マルチエージェントとは、自律的判断・行動できる複数のAIが、協力・分業をしながら、課題を解決する仕組みです。
身近な例えで言うと、1人のスーパーマンに全部やらせる代わりに、役割分担した小さなチームで仕事を回す発想です。
- シングルエージェント：1つのプロンプトに「調べて、書いて、チェックして」と全部詰め込む。指示が複雑になると、要件の取りこぼしが起きることがあります。
- マルチエージェント：「計画する人」「作業する人」「レビューする人」に分け、それぞれに専念させる。各エージェントのプロンプトはシンプルになり、品質が安定しやすい。
今回作る最小構成は、次の3体がバケツリレー方式（順番に渡していく） で協調します。
ポイントは、真ん中の「オーケストレーター」が普通のPythonコードでしかないことです。
エージェント同士が直接おしゃべりするのではなく、オーケストレーターが「次は誰に何を渡すか」を制御します。
Aiエージェントをゼロから作る方法は、こちらの記事で紹介しています。
マルチエージェントを動かすまでのステップ
ここからは、最小構成を実際に手を動かして組み立てていきます。
まず1体のエージェントを動かし、次に3体を連携させ、最後にレビューでのやり直しループとクラウド実行までを、段階的に難易度を上げながら進めます。
STEP
01
まず1体のエージェントを動かす（最小の最小）
まず「エージェント1体 = 役割を与えたLLM呼び出し1回」を関数にします。
import os
from openai import OpenAI
client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
def run_agent(role_prompt: str, user_input: str) -> str:
"""役割(role_prompt)を与えたエージェントを1回だけ動かす最小単位。"""
resp = client.chat.completions.create(
model="gpt-5.5-instant",
messages=[
{"role": "system", "content": role_prompt},
{"role": "user", "content": user_input},
],
)
return resp.choices[0].message.content
if __name__ == "__main__":
planner_role = "あなたは計画担当です。依頼を達成するための手順を3つ、箇条書きで簡潔に出してください。"
result = run_agent(planner_role, "初心者向けに『マルチエージェント入門』のブログ構成を作って")
print(result)
実行してみます。
pip install openai
export OPENAI_API_KEY="*****" # WindowsのPowerShellなら $env:OPENAI_API_KEY="*****"
python agent.py
run_agent() という関数が「エージェント」の正体です。システムプロンプトで役割を変えれば、別のエージェントに変更できます。
💡 ハマりどころ①
：
KeyError: 'OPENAI_API_KEY'環境変数を設定し忘れるとこのエラーになります。exportした同じターミナルでpythonを実行してください。別のターミナルを開くと環境変数は引き継がれません。
STEP
02
エージェント3体を協調させる
ここからが本番です。Planner → Worker → Reviewer の順に、前のエージェントの出力を次のエージェントの入力に渡します。
# orchestrator.py
from agent import run_agent
# 3体それぞれの役割を定義
PLANNER = "あなたは計画担当です。依頼を達成する手順を3〜5個、箇条書きで簡潔に示してください。"
WORKER = "あなたは作業担当です。渡された計画に従い、成果物そのものを作成してください。説明は不要、成果物だけを出力します。"
REVIEWER = (
"あなたはレビュー担当です。成果物をチェックし、問題がなければ先頭に『OK』とだけ書いてください。"
"修正が必要なら先頭に『NG』と書き、その後に具体的な修正指示を箇条書きで示してください。"
)
def coordinate(task: str) -> str:
# ① 計画を立てる
plan = run_agent(PLANNER, task)
print("=== 計画 ===\n", plan, "\n")
# ② 計画をもとに作業する
work_input = f"依頼: {task}\n\n計画:\n{plan}"
draft = run_agent(WORKER, work_input)
print("=== 初稿 ===\n", draft, "\n")
# ③ レビューする
review = run_agent(REVIEWER, f"依頼: {task}\n\n成果物:\n{draft}")
print("=== レビュー ===\n", review, "\n")
return draft if review.startswith("OK") else draft + "\n\n[要修正]\n" + review
if __name__ == "__main__":
final = coordinate("社内向けに、リモートワークのセキュリティ注意点を200字でまとめて")
print("=== 最終成果物 ===\n", final)
コマンドから実行してみます。
これで3体のAIが協調して1つの成果物を作る最小構成が動きました。
役割の違うrun_agent()呼び出しを、普通のPythonで3回つなぎます。
💡 ハマりどころ②
Workerが「成果物」ではなく「説明」を返してくる
「成果物だけを出力して」と指示しても、
はい、承知しました。以下が成果物です：のような前置きが付くことがあります。役割プロンプトに「前置き・後置きは禁止」と明記する、もしくは後段で正規表現で削るなどの後処理を入れると安定します。LLMは「言われた通り」より「親切に」振る舞いがちなので、出力フォーマットは口を酸っぱくして指定するのがコツです。
STEP
03
レビュー結果を受けて作り直す
エージェント起動だけでは「レビューでNGが出ても直さない」ので不完全です。
ここでReviewerが「NG」を返したらWorkerに戻して作り直すループを足します。
from agent import run_agent
PLANNER = "あなたは計画担当です。依頼を達成する手順を3〜5個、箇条書きで簡潔に示してください。"
WORKER = "あなたは作業担当です。渡された計画と（あれば）修正指示に従い、成果物そのものだけを出力してください。前置き・後置きは禁止です。"
REVIEWER = (
"あなたは厳しいレビュー担当です。成果物を評価し、問題なければ先頭に『OK』とだけ書きます。"
"改善余地があれば先頭に『NG』と書き、続けて修正指示を箇条書きで示してください。"
)
MAX_RETRY = 3 # ★暴走防止：最大リトライ回数を必ず決める
def coordinate(task: str) -> str:
plan = run_agent(PLANNER, task)
draft = run_agent(WORKER, f"依頼: {task}\n\n計画:\n{plan}")
for i in range(MAX_RETRY):
review = run_agent(REVIEWER, f"依頼: {task}\n\n成果物:\n{draft}")
print(f"--- レビュー{i + 1}回目 ---\n{review}\n")
if review.startswith("OK"):
print(f"✅ {i + 1}回目のレビューで合格")
return draft
# NGなら修正指示を添えて作り直す
draft = run_agent(
WORKER,
f"依頼: {task}\n\n前回の成果物:\n{draft}\n\n修正指示:\n{review}",
)
print("⚠️ 最大リトライ回数に到達。現時点の成果物を返します。")
return draft
if __name__ == "__main__":
print(coordinate("社内向けに、リモートワークのセキュリティ注意点を200字でまとめて"))
MAX_RETRY でループ回数に必ず上限を設けるのがポイントです。これがないと「Reviewerが永遠にNGを出し続ける → 無限ループ → API課金が止まらない」という事故になります。
💡 ハマりどころ③永遠にOKが出ない
Reviewerを「厳しく」しすぎると、何を出しても粗探しをしてNGを返し続けます。
MAX_RETRYで必ず止めるのに加えて、レビュー基準を「重大な問題のみ指摘。軽微な好みの違いはOKとする」のように緩めると現実的に収束します。
STEP
04
クラウド上で動かす（GPUSOROBAN でLLMごと自前ホスト）
ローカルで動いたら、いよいよ「クラウド上で複数AIを協調させる」最終形にします。今回はGPUSOROBANを使います。
GPUSOROBANを使う最大のメリットは、GPUがあるのでLLMそのものを自前でホストできることです。APIを叩く代わりに、オープンソースのLLMをGPUインスタンス上で動かし、3体のエージェントはそのローカルLLMに話しかけます。
これで「複数AIが、自分のクラウドGPUの上で協調する」最小構成が完成し、外部APIへのトークン課金もかかりません。
① GPUインスタンスを起動する
GPUSOROBANのコンソールからGPU種別を選んでインスタンスを作成します。
② SSHで接続する
③ オープンLLMをホストする（OpenAI互換API）
Ollamaを使うと、オープンLLMを「OpenAIと同じ形式のAPI」で立てられます。
curl -fsSL https://ollama.com/install.sh | sh
ollama serve & ollama pull gpt-oss:20b # 好きなオープンモデルを取得
④ run_agent の「向き先」だけを差し替える
ここがフレームワーク非依存のポイントです。オーケストレーターのロジックは変更せず、 エージェントが話しかける相手（base_urlとモデル名）を変えるだけです。
# agent_local.py ── agent.py の「向き先」だけ差し替えた版
from openai import OpenAI
# GPUSOROBANインスタンス上のOllama（OpenAI互換API）を指す
client = OpenAI(
base_url="http://localhost:11434/v1",
api_key="ollama",
)
def run_agent(role_prompt: str, user_input: str) -> str:
resp = client.chat.completions.create(
model="gpt-oss:20b", #モデル名を合わせる
messages=[
{"role": "system", "content": role_prompt},
{"role": "user", "content": user_input},
],
)
return resp.choices[0].message.content
最後に orchestrator_loop.pyの冒頭を from agent import run_agent → from agent_local import run_agent に変更します。
OpenAIのAPIでも自前GPU上のLLMでも、協調を制御するコードは同じまま動きます。
これで3体のエージェントが、GPUSOROBANのGPU上で動くLLMを使って協調するようになりました。
💡 ハマりどころ④：
ollama pullが遅い／終わらないオープンLLMは数GB〜数十GBあります。初回ダウンロードには時間がかかるので、回線を待ちましょう。まずは小さめのモデルで動作確認するのがおすすめです。
💡 ハマりどころ⑤：
CUDA out of memoryモデルがGPUのVRAMに載りきらないと出ます。より小さいモデルに変えるか、VRAMの大きいインスタンスを選び直してください。20Bクラスなら VRAM 16GB 以上が一つの目安です。
コスト・運用上の注意
マルチエージェントのコスト構造は、「LLMをどこで動かすか 」で大きく変わります。
それぞれの注意点を押さえましょう。
1. 外部API（OpenAIなど）を使う場合（トークン課金）
外部APIを使う場合は、呼び出し回数 ×（入力＋出力トークン）で課金されます。エージェントを増やすほど、ループを回すほど料金は掛け算で増えます。
MAX_RETRYのようなループ上限を必ず設ける。- 1リクエストの
max_tokens（出力上限）を設定し、長文の暴発を防ぎます。 - OpenAIダッシュボードの Usage limits / Billing で毎月の上限額を設定する。超えるとAPIが自動で止まり、使い過ぎを防止できます。
2. GPUSOROBANで自前ホストする場合（起動時間課金）
GPUSOROBANの課金対象は、インスタンスの起動時間（1時間50円〜）が基本です。インスタンスの休止間は追加課金がありません。インスタンスの停止忘れがあると課金が発生してしまうので注意が必要です。
- 検証が終わったら必ずインスタンスを停止しましょう。
MAX_RETRYのループ上限は設けておきましょう（GPUを無駄に占有しないため）。
AI開発のかかる費用の詳細はこちらの記事で解説しています。
まとめ・次のステップ
この記事で、マルチエージェントの正体は「役割を変えたLLM呼び出しを、自前のコードでつなぐ」までを実践しました。
次の発展の方向はいくつかあります。
- 協調パターンを変える：今回は順番に渡す「逐次型」でしたが、複数のWorkerに並列で作業させて結果を統合する「並列型」、上位エージェントが下位に指示を出す「階層型」などがあります。
- エージェントに道具を持たせる：Web検索やDB参照などのツールを持たせると、調べ物をするエージェントが作れます。
- フレームワークへ移行する：状態管理やログが複雑になってきたら、LangGraphや OpenAI Agents SDKに乗り換えると、今回手書きした部分を任せられます。
- GPUを活かす：自前ホストなら、より大きなモデルへの差し替えや、複数モデル（速い小型モデルと賢い大型モデルの使い分け）を1台のGPU上で試すといった発展もできます。
まずは今回のコードのプロンプトやMAX_RETRYをアレンジして、エージェントたちの協調の挙動が変わる様子を観察してみてください。
NVIDIA GPUを搭載したクラウドが、業界最安値で使える！
GPUSOROBANのGPUインスタンスを実際に動かすには、GPUSOROBANのアカウントが必要です。
公式サイトから無料で会員登録でき、名前・メールアドレス・パスワードを入力して申し込むと、届いた認証メールのURLをクリックするだけで登録が完了します。
最小スケールでは、1時間50円〜の従量課金なので、今回の検証用に1台立てるだけなら数百円で試せます。
👉 [会員登録はこちらから]
