0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

LangGraph で育てる「AIタウン」――Version 9で複合タスク都市になった話

0
Posted at

※この記事は AI(Microsoft Copilot)によって生成され、筆者が内容を確認・調整しています。
※この記事は前回の記事
https://qiita.com/genkyoryo110/items/0fab69648cc9b71f5f0b
の続編です。


はじめに

AIタウンは、複数の AI エージェントが「ひとつの街」のように協調しながら、ユーザーの要求を分解し、最適なツールを選び、順番に処理していくための制御基盤です。

Version 9 でのテーマは、単発のタスク処理から「複合タスクの連鎖処理」への進化でした。

  • 「AI画像生成トレンドを調べてDiscordに送って」
  • 「この設定を覚えておいて」
  • 「英語に翻訳して要約して」

こうした入力を、ただの一発処理ではなく「複数の段階に分解して、複数エージェントでバトンを渡しながら完了させる」仕組みを、LangGraph を使って実装したのが Version 9 です。


全体アーキテクチャ概要

city_controller(LangGraph 制御レイヤー)

city_controller は、AIタウンの「交通管制センター」です。
ユーザー入力を受け取り、以下の流れを制御します。

  1. task_planner:意図を解析し、タスクを列挙する
  2. agent_selector:タスクごとに担当エージェントを選ぶ
  3. worker_call:選ばれたエージェントを順番に実行する
  4. memory_update:必要なら結果を永続化する

この制御フローは LangGraph の StateGraph 上にノードとして定義され、状態(State)には task_type, assigned_agents, result, memory_to_add などが保持されます。

agents(専門エージェント群)

agents 配下には、役割ごとに分離されたエージェントが存在します。

  • chat_agent:汎用対話
  • rag_agent:RAG による検索+回答
  • memory_agent:保存前の整形・前処理
  • summarize_agent:要約
  • generate_agent:新規文章生成
  • twitter_trend_agent:Twitter(X)トレンド収集
  • discord_notify_agent:Discord 通知
  • (将来)rewrite_agent / translate_agent / code_agent / planner_agent など

それぞれが「ひとつの店」「ひとつの工場」のように独立していて、制御層から呼び出されることで街として機能します。

tools(LangChain Tool ラッパー)

tools は、エージェントを LangChain の Tool として公開する層です。

  • registry.py でツールを登録
  • tool_registry 経由で worker_call がツールを取得
  • _safe_register によって、依存不足のツールは警告ログだけ出してスキップ

これにより、「一部のエージェントがまだ未実装でも、街全体は落ちない」構造になっています。

memory(RAGStore 永続化)

memory は、AIタウンの「図書館」です。

  • RAGStore によるテキスト保存
  • save タスクが含まれるときに memory_update ノードから利用
  • 後続の RAG クエリで再利用可能な知識として蓄積

docs(設計ドキュメント)

docs には、アーキテクチャの意図やバージョンごとの変更点がまとめられています。
Version 9 の設計もここに整理され、Version 10 / 11 に向けた前提が言語化されています。


Version 9 の一番大きな変化:複合タスクパイプライン

1. task_planner が「配列」でタスクを返す

Version 9 では、task_planner が単一ラベルではなく「タスクの配列」を返すようになりました。

例:

  • 「AI画像生成トレンドを調べてDiscordに送って」
    → ["search", "summarize", "notify"]
  • 「この設定を覚えておいて」
    → ["save"]
  • 「英語に翻訳して要約して」
    → ["translate", "summarize"]

これにより、「ユーザーの一文=ひとつのタスク」という制約から解放され、
ひとつの入力を複数の処理段に分解できるようになりました。

2. agent_selector が複数エージェントを選ぶ

agent_selector は、task_type の配列を順番に走査し、各タスクに対応するエージェントを選びます。

  • search → twitter_trend_agent or rag_agent
  • summarize → summarize_agent
  • notify → discord_notify_agent
  • save → memory_agent

結果として、State には assigned_agents が入り、
例:["twitter_trend_agent", "summarize_agent", "discord_notify_agent"]
のような「処理レシピ」が生成されます。

3. worker_call が「バトンリレー」を実行する

worker_call は、assigned_agents を順番に実行するパイプライン方式に変更されました。

  • 先頭エージェントの出力 → 次のエージェントの入力
  • 文字列ベースで中間結果を受け渡し
  • 最終結果を result に格納

この設計によって、

「検索 → 要約 → 通知」

という「連鎖処理」が、ひとつのユーザー入力から自動的に構成されます。


実行ログで見る「AIタウン Version 9」の動き

実際のログを例にすると、流れがかなりはっきり見えます。

入力例

AI画像生成トレンドを調べてDiscordに送って

タスク判定とエージェント選択

ログ上では、次のように記録されます。

=== TaskPlanner 判定 ===
task_type: ['search', 'summarize', 'notify']

=== WorkerCall 結果 ===
assigned_agents: ['twitter_trend_agent', 'summarize_agent', 'discord_notify_agent']

twitter_trend_agent → summarize_agent → discord_notify_agent

twitter_trend_agent は、Stable Diffusion / SDXL / Flux / Midjourney などを含むクエリで X(Twitter) を検索し、
AI画像生成に関する投稿を抽出します(政治・宗教・暴力などはフィルタリング)。

その出力がそのまま summarize_agent に渡され、
日本語で 1〜3 文の要約が生成されます。

さらに、その要約が discord_notify_agent に渡され、
Discord Webhook 経由で通知されます。

ログの最後には、

Discordに通知しました: **META** targets $1200, reversing at $780-$800 support. **FLEXTURES** develops "Unicorn" electric loop with 20km/h speed and 20km range. New strategy "FLEX" records 98 CPM using XAU, QQQ, and SPY.

のように、「街としての処理結果」がまとまって返ってきます。


registry と _safe_register の設計意図

Version 9 では、tools/registry.py に _safe_register が導入されました。

  • 依存が足りないツールは warning ログ を出してスキップ
  • 起動時に「全部揃っていないと落ちる」状態を避ける
  • 実際に使うタイミングまで、足りないツールは後回しにできる

これにより、開発中のエージェント(rewrite_agent, translate_agent, code_agent, planner_agent など)が未完成でも、
AIタウン全体は問題なく起動し、既存のパイプラインは動き続けます。


Harness Engineering への布石

Version 9 は、制御レイヤーとしての city_controller と、
複数エージェントのパイプライン設計を「動く形」で確立した版です。

ここから先の構想として、

  • 実行状態管理の標準化
  • エラー時のリカバリ
  • 実行履歴のトラッキング
  • 自律スケジューラ(毎朝 8:00 にトレンド収集→要約→通知 など)

といった「Harness Engineering」を導入していく予定があります。

Version 9 は、そのための 土台づくり にあたるフェーズで、

  • タスク分解(task_planner)
  • エージェント選択(agent_selector)
  • 連鎖実行(worker_call)
  • 永続化(memory_update)
  • 安全なツールロード(registry)

という「制御の骨格」がひと通り揃った状態です。


まとめ

AIタウン Version 9 は、

「複数エージェントが協調して、ひとつの入力から複合タスクを連鎖的に処理する」

というコンセプトを、LangGraph を軸に具体的な実装として形にした版です。

  • ユーザー入力は task_planner によって複数タスクに分解され
  • agent_selector がタスクごとにエージェントを選び
  • worker_call がバトンリレー形式で実行し
  • 必要なら memory_update が知識を永続化し
  • registry が複数エージェントを安全にロードする

この構造によって、AIタウンは「ただのチャットボット」から一歩進み、
マルチエージェントが動く小さな都市としての姿を取り始めました。

次の Version 10 / 11 では、
この都市に「スケジューラ」「ハーネス」「自律制御」が加わり、
より運用しやすく、より自律的な AI インフラへ育っていく予定です。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?