1. 主要ページへ移動
  2. メニューへ移動
  3. ページ下へ移動

QES ブログ

記事公開日

AIがAIを選ぶ!LangGraph Supervisorで作る「思考チーム」と動的な采配

  • このエントリーをはてなブックマークに追加

こんにちは!DXソリューション営業本部の大和矢です。

今回は、AIエージェント構築フレームワーク「LangGraph」のSupervisor型Agentを実装し、「状況に応じて最適なエージェントを動的に選択する能力」に焦点を当てて解説します。

ユーザーからのリクエストに対し、Supervisorがコンテキストを読み取り、複数の専門家AIチームの中から「今、話を聞くべきは君たちだ!」と、最適なメンバーだけを指名する___そんな振る舞いを実装してみましょう。

今回は、AIエージェントにMCPツールなどを一切与えず、純粋に「役割(思考パターン)」だけをシステムプロンプトで与え、Supervisorがその役割を理解して的確に仕事を振る様子を紹介していきます。

LangGraphとは?

LangGraphは、LLM開発フレームワークであるLangChainを拡張し、複雑なAIエージェントやマルチエージェントシステムを、状態を持つグラフ(Stateful Graphs)として構築するためのライブラリです。
詳細は公式ドキュメントをご覧ください。

従来のチェーン(Chain)が一直線の処理フローだったのに対し、LangGraphではノード(処理単位)とエッジ(処理の流れ)を定義することで、ループ、条件分岐、並列実行といった、より柔軟で高度な制御フローを持つアプリケーションを構築できます。
これにより、人間のように状況に応じて判断を変えながら動作する、洗練されたAIエージェントの開発が可能になります。

LangGraph Supervisorとは?

LangGraphにおけるSupervisorとは、複数のAIエージェントで構成されるチームの「マネージャー」や「司令塔」の役割を担う、特別なエージェントです。

あらかじめ決められた順番で処理が流れる単純なパイプラインとは異なり、Supervisorは対話の状況やユーザーの要求をリアルタイムに分析し、「次にどのエージェントを動かすべきか」「いつ作業を完了させるべきか」を自律的に判断します。
これにより、人間がプロジェクトを管理するのと同様に、より複雑で柔軟なワークフローをAIエージェントに実行させることが可能になります。

今回の実装では、このSupervisorに「思考チームのモデレーター」という役割を与え、ユーザーからのお題に対して、どの思考法を持つ専門家を呼び出すべきかを判断させます。

今回の思考チーム紹介

Supervisorが指揮するのは、以下の3体の「思考の専門家」で構成されるチームです。彼らは外部ツールを一切持たず、与えられたテキストと自分自身の思考ロジックだけで回答を導き出します。

  • 構造分析家
    物事を構造的・論理的に分解して分析し、客観的な事実や構造を整理します。
  • 発想家
    物事の裏にある比喩、象徴、感情的な意味を読み解き、議論に創造的な視点をもたらします。
  • 批評家
    あえて反対の立場から、物事の矛盾点、例外、リスクを指摘し、議論に深みを与えます。

実装紹介:思考チームの構築

早速、今回のシステムの中核をなすPythonコードを見ていきましょう。

import os
import asyncio
import dotenv
from datetime import datetime
from langgraph.prebuilt import create_react_agent
from langgraph_supervisor import create_supervisor
from langchain_openai import AzureChatOpenAI

# --- 1. 環境変数とLLMのセットアップ ---

# .envファイルから環境変数を読み込む
dotenv.load_dotenv()

# Azure OpenAIの接続設定
os.environ["AZURE_OPENAI_API_KEY"] = os.environ.get("AZURE_OPENAI_API_KEY_5mini")
os.environ["AZURE_OPENAI_ENDPOINT"] = os.environ.get("AZURE_OPENAI_ENDPOINT_5mini")

llm = AzureChatOpenAI(
    azure_deployment= os.environ.get("AZURE_OPENAI_DEPLOYMENT_5mini"),
    api_version=os.environ.get("AZURE_OPENAI_API_VERSION"),
)

# --- 2. 各エージェントとSupervisorのプロンプト定義 ---

# ユーザーからの入力を受け取り、各エージェントのプロンプトを動的に生成する関数
def make_logical_analyst_prompt(user_input: str) -> str:
    return (
        f"【分析テーマ】\n{user_input}\n\n"
        "あなたは非常に優秀な構造分析家です。与えられたテーマについて、その文字通りの意味、構造、前提、そして結論を客観的かつ論理的に分解して説明してください。"
        "感情や比喩は排し、事実と論理のみに基づいて分析を進めてください。"
        "出力の先頭には必ず【構造分析家】と付けてください。"
    )

def make_metaphorical_interpreter_prompt(user_input: str) -> str:
    return (
        f"【分析テーマ】\n{user_input}\n\n"
        "あなたは洞察力に優れた発想家です。与えられたテーマの裏に隠された、比喩的、象徴的、感情的な意味を読み解いてください。"
        "それが何を象徴しているのか、どのような教訓や感情を呼び起こすのかを、豊かな表現で説明してください。"
        "出力の先頭には必ず【発想家】と付けてください。"
    )

def make_critical_advocate_prompt(user_input: str) -> str:
    return (
        f"【分析テーマ】\n{user_input}\n\n"
        "あなたは鋭い批判的思考を持つ批評家です。与えられたテーマや他の人の意見に対して、あえて反対の立場から議論を挑んでください。"
        "その主張の矛盾点、例外、見過ごされているリスクや問題点を指摘し、議論に深みを与えるのがあなたの役割です。"
        "出力の先頭には必ず【批評家】と付けてください。"
    )

# Supervisorのプロンプトを生成する関数
def make_supervisor_prompt(user_input: str) -> str:
    return (
        f"【分析テーマ】\n{user_input}\n\n"
        "あなたは思考チームを率いるモデレーターです。ユーザーからのお題を分析し、多角的な視点を得るために、以下の3人の思考の専門家の中から**最も適した2人**を選んで、順番に意見を求めてください。\n\n"
        "全員に意見を聞く必要はありません。ユーザーの要望に最も合致する専門家を順番に指名してください。"
        "もし特定の専門家を指名しなかった場合は、その理由を最後に述べてください。"
        "2人の意見が出揃ったら、議論を終了させてください。"
        "出力の先頭には必ず【Supervisor】と付けてください。"
    )

async def main():
    # ユーザーからの分析テーマ(お題)
    user_input = "ことわざ「急がば回れ」を多角的に分析してください。"

    # 各プロンプトを動的に生成
    logical_analyst_msg = make_logical_analyst_prompt(user_input)
    metaphorical_interpreter_msg = make_metaphorical_interpreter_prompt(user_input)
    critical_advocate_msg = make_critical_advocate_prompt(user_input)
    supervisor_msg = make_supervisor_prompt(user_input)

    # --- 3. エージェントとSupervisorの構築 ---

    # create_react_agentを使用して各エージェントを定義
    # ツールは不要なため、tools=[] を渡す
    logical_analyst_agent = create_react_agent(
        llm,
        tools=[],
        prompt=logical_analyst_msg,
        name="analyst"
    )
    metaphorical_interpreter_agent = create_react_agent(
        llm,
        tools=[],
        prompt=metaphorical_interpreter_msg,
        name="interpreter"
    )
    critical_advocate_agent = create_react_agent(
        llm,
        tools=[],
        prompt=critical_advocate_msg,
        name="critic"
    )

    # エージェントのリストを作成
    agents = [
        logical_analyst_agent,
        metaphorical_interpreter_agent,
        critical_advocate_agent,
    ]

    # create_supervisorを使用してワークフローを構築
    # この関数は内部でStateGraphやノード、エッジの定義を行っていると想定
    workflow = create_supervisor(
        agents,
        model=llm,
        prompt=supervisor_msg
    )
    
    # ワークフロー(グラフ)をコンパイル
    app = workflow.compile()

    print("--- 思考チーム、分析開始! ---")
    print(f"【お題】: {user_input}\n")

    # --- 4. ワークフローの実行と結果表示 ---
    
    # ainvokeで非同期に実行
    result = await app.ainvoke({"task": user_input})

    
    # 会話履歴を表示
    for message in result.get("messages", []):
        if hasattr(message, "content") and isinstance(message.content, str):
            # ユーザー入力は表示しない
            if message.content.strip() == user_input.strip():
                continue
            
            sender = getattr(message, "name", "Unknown")
            print(message.content)


if __name__ == "__main__":
    asyncio.run(main())

実装のポイント

  • モデル選定(gpt-5mini)の理由:
    今回のタスクは、外部ツールを使わずプロンプトで与えられた役割を忠実に実行する「思考力」と「指示追従性」が重要です。
    gpt-5miniは、最新モデルとしてこれらの能力に優れ、かつ応答速度とコストのバランスが良いため採用しました。
    複雑なツール連携が不要な思考シミュレーションにおいては、最適な選択肢の一つと言えます。
  • プロンプトによる役割定義:
    各エージェントには`tools=[]`としてツールを一切渡さず、`make_..._prompt`関数で生成されるシステムプロンプトのみで思考のスタイルや役割を厳密に定義しています。
    LLMが持つ元々の能力を、プロンプトによって引き出している点が特徴です。
  • Supervisorによる采配:
    Supervisorのプロンプトでは、「最も適した2人を選んで」と明確に指示しています。これにより、Supervisorは単なる進行役ではなく、お題に応じてどの専門家の意見を聞くべきかを判断する「賢いマネージャー」として機能します。
  • LangGraphライブラリ関数による構築:
    `create_react_agent`で各エージェントを、`create_supervisor`でワークフロー全体を構築しています。これにより、LangGraphの複雑なグラフ定義をカプセル化し、コードの見通しを良くしています。

実際に動かしてみた!

それでは、実際にこの思考チームに「ことわざ『急がば回れ』を多角的に分析してください。」というお題を与えてみましょう。
Supervisorが的確に2人の専門家を選び出し、多角的な分析を展開する様子が確認できます。

【お題】: ことわざ「急がば回れ」を多角的に分析してください。
1人目の発言者:発想家
【発想家】
「急がば回れ」は言葉の短さに反して、心の深い場所へ触れる道しるべのようなことわざだ。直訳すれば「急ぐなら回り道を行け」。表面は単純だが、そこには時間感覚、リスクの評価、自己制御、そして人生観までが濃縮されている。

まず比喩的な響きから──目の前に細い橋や浅瀬があって、渡れば早いが滑って落ちる危険がある。もう一方の岸に続く安全で確実な大回りの道は時間がかかる。しかし、安全に確実にたどり着ける。その対比が「急がば回れ」だ。ここには「速さ」と「確実さ」の古典的トレードオフが描かれている。

象徴的には、このことわざは短期的な欲望と長期的な成果の調停を表す。焦りは決断を曖昧にし、手順を省かせ、結果としてより多くの手戻りを生む。それは仕事の手順、技術の熟成、人間関係の信頼形成、学びのプロセスなどあらゆる領域に当てはまる。回り道は退屈に見えるが、その間に基礎が築かれ、予期せぬ景色や教訓が得られる。急いで得たものは砂の城のように脆いが、遠回りで築いたものは礎が深い。

感情面では、ことわざは二つの感覚を同時に刺激する。ひとつは焦燥と不安──時間に追われる心が指す先。もうひとつは安堵と深呼吸──「回る」ことで得られる余裕と安心。深い呼吸ができる瞬間の静けさや、自分の歩幅で進むことの尊さを思い出させる。回り道は時に謙虚さを教え、失敗の恐れを和らげる緩衝材にもなる。

また、逆説的な教訓がそこにある。「遅く見える選択が、結果的には最も速い」。これは単なる努力の美徳ではなく、賢い観察と長期視点の重要性を説く。プロジェクトの初期に手順を省いて短期成果を追うと、後で修正に膨大な時間を割く羽目になる。だから慎重に基盤を
作ることこそ、最終的な時間節約になることが多い。

ただし盲目的な回り道賛美ではない。ことわざは原則であり、万能薬ではない。場合によっては即応が命を救うこともあるし、変化の早い領域では迅速な試行錯誤が価値を生む。重要なのは判断力だ。何を「回る」べきか、どのリスクを受け入れどのリスクを避けるかを見定める眼を養うことこそが、真の意味で「急がば回れ」を使いこなす術だ。

現代の喩えで言えば、ショートカットのコードをコピペするより設計を理解して正しく組むこと、手抜きのマーケティングで炎上するより丁寧に顧客を育てること、即断で人を切るより対話と信頼を育むこと──そうした選択にこのことわざは優しく首肯する。短期の勝利を追うときに、回り道が未来への保険であり、豊かな土壌であることを忘れないでほしい。

最後に詩的に言えば、「急がば回れ」は時間との対話法だ。急ぐ心に向けられた招待状でもある。「少し遠回りをして、道の匂いや風の向きを確かめてみなさい。そこで見つかる小石や草の帯が、あなたの次の一歩を確かなものにするだろう」と。焦りのなかで自分を見失いがちな現代だからこそ、この古い知恵は、静かで力強い節度を取り戻す鍵となる。
2人目の発言者:構造分析家
【構造分析家】

1. 命題の文字通りの意味
- 表現: 「急がば回れ」
- 直訳的命題: 「速く到達しようとするなら、速い近道を取るよりも、時間はかかるが安全確実な遠回りを選んだ方が望ましい場合がある」
- タイプ: 行動上の規則(推奨命題)であり、手段選択に関する助言を表す。

2. 命題の論理構造(基本形)
- 対象となる二つの選択肢:
  A: 近道(短時間だが失敗や追加コストのリスクがある手段)
  B: 遠回り(長時間だが成功確率が高く追加コストが小さい手段)
- 命題の含意(簡潔化):
  If (A は短時間だが失敗したときの追加コストが大きい) then (B を選ぶことが望ましい)
- 形式化の一例(時間コスト最小化基準):
  定義: Tf = A を用いた場合の所要時間(成功時)、Ts = B の所要時間(確定)、p = A が失敗する確率、D = 失敗時に追加で要する平均遅延(回復時間等)。
  A の期待時間 E[T_A] = Tf + p * D
  B の時間 = Ts
  比較基準: B を選ぶべき十分条件は Ts ≤ E[T_A] つまり Ts ≤ Tf + pD

3. 前提(明示的・暗黙的)
- 評価基準が存在すること(例: 時間最小化、リソース最小化、安全性最大化など)。ことわざは通常「時間」や「失敗の回避」を暗黙的に評価対象としている。
- 失敗に伴う追加コスト(D)が非ゼロであり、無視できない程度であること。
- A と B の選択が可能であり、選択を行う主体が結果をある程度予測・評価できること(p, D, Tf, Ts を推定可能であるか、少なくとも相対的判断が可能であること)。
- 独立性と非再評価: 一回の選択で結果が決まる前提(動的学習や戦略的時間制約が存在する場合は追加考慮が必要)。

4. 推論と結論(合理的帰結)
- 決定論的結論: 上記の期待値比較に基づき、B を選ぶことが合理的である状況は Ts ≤ Tf + pD。
- 高リスク(D が大きい、あるいは p が高い)かつ Ts がそれらの期待コストを下回る場合、B を選ぶことが合理的。
- 一方で、p と D が十分に小さく Tf が Ts よりも著しく小さい場合は A を選ぶ方が合理的(期待時間が短い)。
- 安全性や致命的結果が含まれる場合(D → ∞ や致命的損失)、期待値基準は不十分であり、リスク回避が優先される(規範的制約)。

5. 制約と適用限界
- 情報の不確実性: p と D が不確定または推定困難な場合、期待値比較が実行困難。ヒューリスティックとして「急がば回れ」が使われる理由はここにあるが、盲目的適用は誤判断を招く。
- 時間割引・機会費用: 即時の速さにより得られる将来的利益(市場優位、学習機会など)がある場合、単純な到着時間の比較は不十分。
- 動的環境: 繰り返し試行や学習が可能な場合、短期リスクをとる試行(探索)によって将来の期待値が改善される場合がある(探索と活用のトレードオフ)。
- 多次元コスト: ことわざは主に時間・失敗コストに焦点を当てるが、資源、評判、安全、法的リスクなど他のコスト項目が存在する場合は多目的最適化が必要。

6. 使用のための意思決定手順(実務的・論理的)
- 1) 評価基準を明確にする(何を最小化/最大化するか)。
- 2) A と B の主要パラメータを推定する(Tf, Ts, p, D など、必要に応じて金銭価値へ換算)。
- 3) 期待値または複合コストで比較する(例: Ts vs Tf + pD)。
- 4) 不確実性が高い場合は感度分析を行い、p と D の範囲で比較が逆転するかを確認する。
- 5) 致命的リスクや規制・倫理的制約がある場合は、期待値比較に優先する安全基準や閾値を適用する。
- 6) 動的価値(学習効果、戦略的優位)を考慮して、短期リスクの許容が長期的に合理的か判断する。

7. 結論(要約)
- 命題「急がば回れ」は、近道(短時間手段)に失敗したときの追加コストが期待される遅延を上回る場合に、遠回り(確実な手段)を選択することを助言するヒューリスティックである。
- 論理的には Ts ≤ Tf + pD が基本的な選択基準となるが、情報の不確実性、機会費用、致命的リスク、動的効果など複数の要因を考慮しなければならない。
- したがって、このことわざは条件付きの合理的ルールであり、無条件に常に適用される命題ではない。
締め:Supervisor
【Supervisor】

以下の2人を選び、順番に意見を求めました。
1) 発想家(クリエイティブな観点、象徴的・感情的解釈)
2) 構造分析家(形式的・定量的解析)

指名しなかった専門家(批評家)を選ばなかった理由:
- 今回のテーマ「ことわざ『急がば回れ』を多角的に分析する」という要望に対して、まずは象徴的・感情的な意味づけと、次に論理的・定量的な枠組みでの分析が最も有益と判断しました。批評家的な懸念(反対の視点)は有用ですが、まず基礎となる発想的解釈と論理分析を提示する方が多角的理解の出発点として適切と考えました。

ここで議論は終了します。

まとめ

実行結果から、Supervisorがユーザーのお題を理解し、「多角的に分析する」という目的に対して、まず物事の概念的な意味を探る「発想家」を呼び出し、次にその構造を整理する「構造分析家」を呼び出すという、判断を下していることがわかります。
そして、「批評家」を呼ばなかった理由まで明確に説明しており、Supervisorがマネージャーとして機能していることが示されました。

今回の検証を通じて、以下の点が明らかになりました。

  1. プロンプトによる役割定義の有効性:
    LLMは、外部ツールなしでもシステムプロンプトによって特定の「思考ペルソナ」を演じることが可能です。
    これにより、コストを抑えつつ、多様な視点を持つエージェントチームを構築できます。
  2. Supervisorの判断能力:
    LangGraphのSupervisorは、単にタスクを順番に割り振るだけでなく、タスクの目的に応じて最適なエージェントを取捨選択する高度な判断能力を持っています。
    これにより、不要な処理をスキップし、効率的で質の高い回答生成が可能になります。
  3. LangGraphの柔軟性:
    今回のような、ツールを使わない純粋な思考の連携も、LangGraphのグラフ構造を用いることで直感的に実装できます。これは、より複雑で人間的な協調作業をAIに実行させる上で、非常に強力なパラダイムです。

筆者は他にもAI関連のブログを執筆しているので、是非ご覧ください。
また、引き続き、AI関連のテーマについて執筆していきます。

QUICK E-Solutionsでは、各AIサービスを利用したシステム導入のお手伝いをしております。
それ以外でも QESでは様々なアプリケーションの開発・導入を行っております。提供するサービス・ソリューションにつきましては こちら に掲載しております。
システム開発・構築でお困りの問題や弊社が提供するサービス・ソリューションにご興味を抱かれましたら、是非一度 お問い合わせ ください。

※このブログで参照されている、Microsoft、Azure、その他のマイクロソフト製品およびサービスは、米国およびその他の国におけるマイクロソフトの商標または登録商標です。
※その他の会社名、製品名は各社の登録商標または商標です。

  • このエントリーをはてなブックマークに追加

お問い合わせ

Contact

ご質問やご相談、サービスに関する詳細など、何でもお気軽にご連絡ください。下記のお問い合わせフォームよりお気軽に送信ください。

お問い合わせ

資料ダウンロード

Download

当社のサービスに関する詳細情報を掲載した資料を、下記のページよりダウンロードいただけます。より深く理解していただける内容となっております。ぜひご活用ください。

資料ダウンロード