AIを使って処理を自動化しようとすると、ある落とし穴に気づく。複数の処理——情報収集、判断、記録——を1つのプロンプトにまとめて投げると、どこかで壊れた時に「何が原因か」が分からなくなることだ。
自分は現役エンジニアとして副業でAIエージェントを設計・運用しているが、Salesエージェントを組んだとき同じ失敗をした。情報収集とスコアリングを同一の処理にまとめた結果、connpassのイベント情報が「有望な候補」として出てきた。スコア閾値を調整して除外ルールを追加するまで、原因の切り分けに余分な時間がかかった。
行き着いた答えがマルチエージェント設計だ。処理を役割ごとに独立させると、壊れた時にどのステップが問題かが一目で分かる。
AIに「分業」させると何が変わるのか
マルチエージェントとは、複数のAI処理をそれぞれ独立した担当に割り振る設計だ。営業の自動化を例に取ると、処理は大きく3段階に分かれる。
まず「リサーチ」——企業情報やコンタクト情報を収集してくること。次に「スコアリング」——収集した情報をICP（Ideal Customer Profile: 理想の顧客像）と照らし合わせ評価すること。最後に「記録」——評価結果をCRM（顧客管理システム）に書き込むこと。
3段階を1プロンプトで処理しようとすると、どこで失敗したかが判別できなくなる。リサーチの結果が不正確なのか、スコアリングの基準がズレているのか、出力フォーマットが合っていないのか、全部が混在した結果の中から原因を探す羽目になる。
分業させると、問題の場所が一目で特定できる。「リサーチエージェントが返すデータの形が変わった」「スコアリングの数値が全件100になっている」——担当が分かれているから、どのステップで何がズレたかが見える。
ぶっちゃけ最初は「プロンプト1本で全部やった方が早い」と思っていた。でも壊れてから修正する時間を考えると、分けておいた方が圧倒的に速い。
LangGraphが解決する「ステップ間の連携」問題
マルチエージェントの設計思想は理解できても、実装が手間になりやすい。エージェント間でデータをどう引き継ぐか、「スコアが低ければ記録をスキップする」という条件分岐をどう書くか、途中でエラーが起きた時にどこから再開するか。こういった「つなぎ」の設計を素のPythonで書くと、ビジネスロジックより接続のコードの方が多くなる。
LangGraph（開発元: LangChain, Inc.）はこの問題に特化したフレームワークだ。AI処理の流れをグラフ構造として設計する。ノード（Node）が各処理の実体、エッジ（Edge）がノード間の接続と分岐を表す。
4つのコア概念だけ押さえておくと全体像が見える。
State（状態）: 全エージェントが共有する情報の入れ物。パイプライン全体を通じて「今何が分かっているか」をここに持つ。リサーチエージェントが書き込んだ企業情報を、スコアリングエージェントが読んで評価する流れがこの共有Stateで実現する。
Nodes（ノード）: 実際の処理を担うPython関数。Stateを受け取り、更新されたStateを返す。リサーチ・スコアリング・CRM更新がそれぞれ1つのノードになる。
Edges（エッジ）: ノード間のつながり。「AのあとはBへ」という固定エッジと、「スコアが閾値未満ならスキップ、以上なら記録へ」という条件エッジがある。この条件分岐がLangGraphの核心だ。
Graph（グラフ）: 全体を組み上げた実行オブジェクト。実行メソッドを呼び出して起動する。
Pythonのif文を組み合わせれば同じことはできる。ただし、条件分岐のたびにif文が増え、状態の受け渡しに専用のデータ構造が必要になり、エラーハンドリングが複雑になっていく。LangGraphがやっているのは、その「接続部分の定型作業」を肩代わりすることだ。何を調べるか・どう評価するかというビジネスロジックに集中できる。
「スコアが低ければ何もしない」設計の価値
条件エッジについてもう少し深掘りする。
一括処理の発想では「全件処理して結果を出す」になりやすい。スコアが低い候補もとりあえずCRMに書き込まれ、後から人間が整理することになる。
LangGraphの条件エッジを使えば、「合否フラグが不合格のレコードはCRM更新ノードをスキップ」を明示的に書ける。これはAPI利用コストの削減にも直結する。LLM呼び出しはトークン課金なので、不要な処理を走らせない設計が積み重なって節約になる。
加えて、「スコアが低かった理由」もStateに記録できる。「業界が対象外」「意思決定権限が見えない」のように言語化しておけば、後からスコアリング基準を改善するための材料になる。スコアの数値より、理由の蓄積の方が長期的に価値が高い。
3エージェント構成の実装概要
LangGraphでの典型的な構成を順に見ていく。
リサーチエージェント: 企業名・役職・LinkedInのURLといった入力情報をもとに、その企業の規模・業種・最近の動向をLLM経由で収集する。このエージェントが失敗した場合（情報収集できなかった場合）は、パイプライン全体をそこで終了させる。リサーチなしにスコアリングしても意味がないからだ。
スコアリングエージェント: リサーチ結果をICPと照らし合わせ、0〜100のスコアを出す。「業界一致度」「役職の意思決定権限」「課題と提供価値の適合度」といった軸で評価し、スコアの根拠を自然言語で記録する。スコアが閾値未満なら、次のCRM更新エージェントはスキップされる。
CRMエージェント: スコアが閾値を超えた場合のみ動作し、リサーチ結果・スコア・理由を構造化してCRMの形式で書き込む。このエージェントの品質はスコアリングの品質に完全に依存するため、スコアリングエージェントの精度改善が最優先になる。
Stateとして持つデータ構造はシンプルでいい。入力情報（企業名・役職・メールアドレス等）、リサーチエージェントが埋める調査結果、スコアリングエージェントが埋めるスコア・判定理由・合否フラグ、CRMエージェントが埋める登録レコードといった構成だ。各エージェントは自分が担当するフィールドだけを見て、自分が担当するフィールドだけを埋める。この原則がシステムの予測可能性を保つ。
自分がSalesエージェントを組んだとき、スコアリングの精度が一番の課題だった。「なぜこれが候補に入るんだ」という出力の原因は、スコアリングの基準が曖昧だったことだった。スコアの理由を記録する仕組みを入れてから、改善サイクルが回り始めた。
Checkpointingと再実行コストの話
LangGraphにはCheckpointingという機能がある。パイプラインの中間状態を保存しておき、エラーが起きた時に最初からやり直す必要がなくなる。
例えばリサーチエージェントが成功し、スコアリングエージェントが500エラーで落ちた場合、リサーチをやり直さずスコアリングから再開できる。
API呼び出しのコスト節約でもあるが、「再試行が怖くなくなる」という精神的な効果の方が実際には大きい。失敗したらどこからでもやり直せる仕組みがあると、処理の追加・変更が気軽にできるようになる。
自分がSalesエージェントに組んでいたリトライ処理——429エラー・タイムアウト・接続リセット時の自動再試行——と目的は同じで、「壊れた時に途中から立て直せる」設計を先に作っておくことで本番運用が安定する。
副業・受託でこの設計思想を説明できると何が変わるか
この「分業設計」の考え方は、営業自動化以外にも広く応用できる。
記事生成パイプライン（テーマ選定 → 執筆 → 品質チェック）、問い合わせ対応（分類 → 回答生成 → エスカレーション判定）、データ収集（取得 → 整形 → 重複排除）——いずれも「リサーチ → 評価 → 出力」の3段構造に還元できる。
受託やフリーランスでAIエージェントを提案する場面で、「1つのプロンプトで全部やります」ではなく「各処理を独立させ、壊れた箇所だけ直せる構造にします」と言えると評価が変わる。発注側が気にするのは「完成するか」ではなく「壊れた後どうなるか」だ。受注後のトラブルで多いのが「動いていたはずなのに本番でおかしい」という報告で、その時に「どのステップが失敗しているか」を5分以内に答えられる設計になっているかどうかで、クライアントからの印象は大きく変わる。
マルチエージェント設計の思想を一言で説明できれば、それだけで提案の質が変わる。壊れにくい自動化より、壊れた時に即座に直せる自動化の方が、長期的な価値は高い。この視点をエンジニアとして副業に持ち込めると、「作れます」だけではない差別化ができる可能性がある。
まとめ
LangGraphによるマルチエージェント設計のポイントを整理する。
- 役割分担で原因切り分けが楽になる: リサーチ・スコアリング・出力を独立させると、壊れた場所が一目で分かる
- 条件分岐でコストと品質を両立できる: スコアが閾値未満なら後続をスキップし、不要なAPI呼び出しを省く
- Checkpointingで再実行コストを減らす: 中間状態の保存で、エラー後のやり直しが最小限になる
マルチエージェントは高度な技術というより、複雑な処理を整理する設計思想だ。この考え方を自分の言葉で説明できるかどうかが、AI自動化を副業として価値に変えられるかどうかの分岐点になると思っている。
【PR】フリーランスエンジニアにおすすめのツール
サーバー・ドメイン・SSL証明書まで一括で揃う。フリーランスがポートフォリオや案件サイトを立ち上げる時の定番。
チーム固定IPが使えるVPNサービス。リモートワークや社内システムへのアクセス管理が必要な場面で便利。
ドメイン取得を最小コストで始められる。副業のポートフォリオサイトやサービスドメインの取得に。
セレネのX (@selene_nyx_ai) でも、AIエージェント設計の話を発信しています。
【PR】おすすめの書籍
記事の内容に関連する書籍を紹介させてほしい。
AIエージェントの仕組みと実装を基礎から学べる一冊です。マルチエージェント設計の前提知識を体系的に押さえたい方に向いています。
LLMの原理、RAG・エージェント開発から読み解くコンテキストエンジニアリング
LLMの原理からエージェント開発まで、設計判断の根拠を理解しながら実装する視点を与えてくれます。マルチエージェントの「なぜ」を深掘りしたい方におすすめです。
コメント