エージェンティックワークフローの設計方法｜複数AIエージェントを連携させる実践ガイド

エージェンティックワークフローとは、複数のAIエージェントが役割分担しながら協調して業務を遂行する仕組みです。従来の単一プロンプト型AIとは異なり、「計画→実行→検証→修正」のサイクルをエージェント間で自律的に回すことで、会計処理・CRM更新・ドキュメント生成といった複雑な業務プロセスを端から端まで自動化できます。本記事では、MCP（Model Context Protocol）を活用したエージェント間連携の設計パターンと、freee・HubSpot・Notionを統合した実装例を解説します。

「AIに業務を任せたいが、単体のチャットボットでは複雑なプロセスに対応しきれない」――そんな課題を抱える企業が増えています。たとえば「freeeの売上データを集計し、HubSpotのパイプラインと突合して、Notionにレポートを作成する」といった業務は、1つのAIエージェントに全工程を任せるには複雑すぎます。

この課題を解決するのがエージェンティックワークフローの設計手法です。複数のAIエージェントにそれぞれ専門的な役割を持たせ、MCPで外部ツールと接続し、オーケストレーション（指揮統制）のロジックで連携させることで、人手を介さない業務自動化が実現します。

本記事は、AIエージェントによる業務自動化の全体像を踏まえた実践編です。設計原則から具体的なアーキテクチャパターンまで、段階的に解説します。

この記事でわかること

• エージェンティックワークフローの基本概念：単一エージェントとの違い、なぜ「複数エージェント協調」が必要なのか
• 4つの設計パターン：シーケンシャル・パラレル・ルーター・階層型オーケストレーションの使い分け
• MCPによるツール統合の設計方法：freee・HubSpot・Notionを1つのワークフローに統合する接続設計
• エージェント間のデータ受け渡し設計：コンテキスト共有・エラーハンドリング・リトライの実装方法
• 導入時の注意点：セキュリティ・コスト・段階的導入のベストプラクティス

エージェンティックワークフローとは何か

単一エージェントとの決定的な違い

従来のAI活用は「1つのプロンプトに1つの回答」が基本でした。ChatGPTやClaudeに質問を投げ、回答を得る。この単発のやり取りでは、複数のシステムをまたぐ業務プロセスを自動化することはできません。

エージェンティックワークフローは、この限界を突破する設計思想です。核となる考え方は以下の3つです。

• 役割分離: 1つのエージェントに全てを任せるのではなく、「データ取得エージェント」「分析エージェント」「レポート生成エージェント」のように専門的な役割を分担させる
• 自律的な判断: 各エージェントが中間結果を評価し、次のステップを自ら決定する。たとえば「データに異常値がある場合は分析を中断して通知する」といった条件分岐を組み込める
• ツール接続: MCP（Model Context Protocol）を通じて、各エージェントがfreee・HubSpot・Slack・Notionなどの外部ツールを直接操作する

なぜ今、エージェンティックワークフローが注目されるのか

2025年後半から2026年にかけて、エージェンティックワークフローの実用化が急速に進んでいます。その背景には3つの技術的な変化があります。

1つ目は、MCPの普及です。Anthropicが2024年11月に公開したMCP（Model Context Protocol）により、AIエージェントと外部ツールの接続が標準化されました。HubSpot・Slack・GitHub・Supabaseなど主要ツールのMCPサーバーが続々と公開され、個別のAPI連携開発が不要になっています。

2つ目は、LLMの推論能力の向上です。Claude 3.5やGPT-4oクラスのモデルは、複雑な業務ロジックの理解と実行が可能になりました。「このデータが異常値かどうか判断し、異常なら担当者に通知する」といった条件分岐を、プロンプトだけで実装できるようになっています。

3つ目は、エージェントフレームワークの成熟です。LangGraph・CrewAI・AutoGenといったフレームワークが実用レベルに達し、マルチエージェントの構築が格段に容易になりました。

4つの設計パターンとその使い分け

エージェンティックワークフローには、業務の特性に応じた4つの基本設計パターンがあります。

パターン1：シーケンシャル（直列処理）

最もシンプルなパターンです。エージェントAの出力をエージェントBの入力として渡し、順番に処理を進めます。

たとえば「月次経営レポートの自動生成」では、freee MCPで会計データを取得するエージェントが最初に動き、その出力を受けて分析エージェントが集計・分析を行い、最後にNotion MCPでレポートページを作成するエージェントが仕上げます。

パターン2：パラレル（並列処理）

複数のエージェントが同時に異なるタスクを実行し、結果を集約するパターンです。

会計データ（freee）とCRMデータ（HubSpot）の取得は互いに依存しないため、並列で実行できます。両方の結果が揃った時点で、統合エージェントがデータを突合してレポートを生成します。

パターン3：ルーター（条件分岐）

入力データの内容に応じて、異なるエージェントに処理を振り分けるパターンです。

ルーターエージェントは「交通整理役」です。たとえばHubSpotのフォームから入った問い合わせを分析し、「製品に関する技術的質問」ならナレッジベース検索エージェントに、「見積依頼」ならHubSpotのDeal作成エージェントに、「クレーム」ならSlack通知エージェントにそれぞれ処理を委任します。

パターン4：階層型オーケストレーション

最も高度なパターンです。「オーケストレーター（指揮者）」となるエージェントが全体計画を立て、配下のエージェントにタスクを割り振り、結果を統合します。

オーケストレーターは、最初に業務の全体計画を立てます。たとえば「前月のKPIを更新する」というタスクに対して、「(1) freeeから売上データ取得、(2) HubSpotからMRR・解約率取得、(3) 前月比の異常値を検出、(4) 異常値があればSlackで通知、(5) Notionのダッシュボードを更新」というステップを自動で計画し、各ステップを担当エージェントに振り分けます。

MCPで実現するツール統合の設計

MCPサーバーの選定と接続構成

エージェンティックワークフローの実効性は、AIエージェントがどれだけ多くの業務ツールを直接操作できるかにかかっています。MCPはこの課題を解決する標準プロトコルです。

BtoB企業で特に利用頻度が高いMCPサーバーの組み合わせは以下のとおりです。

この6つのMCPサーバーを組み合わせることで、BtoB企業の主要な業務プロセスの大部分をカバーできます。

会計×CRM×ドキュメントの統合パターン

freee（会計）・HubSpot（CRM）・Notion（ドキュメント）を統合するワークフローは、多くのBtoB企業で共通する需要があります。具体的な設計パターンを見てみましょう。

ユースケース：月次経営レポートの自動生成

この業務フローは、階層型オーケストレーションで設計します。

1. オーケストレーターエージェントが「月次経営レポート作成」のタスクを受け取り、実行計画を策定
2. freeeデータ取得エージェントがfreee MCPを通じて月次の売上・経費・粗利データを取得
3. HubSpotデータ取得エージェントがHubSpot MCPを通じてパイプライン状況・新規リード数・成約率を取得（2と並列実行）
4. 分析エージェントが2と3の結果を統合し、前月比・前年比・異常値を分析
5. レポート生成エージェントがNotion MCPを通じて、分析結果を所定のテンプレートに沿ってNotionページとして作成
6. 通知エージェントがSlack MCPで「月次レポートが完成しました」と関係者に通知

このワークフローでは、ステップ2と3が並列処理（パラレルパターン）、全体は階層型オーケストレーションで管理されるという、パターンの組み合わせになっています。

接続設計のポイント

MCPサーバーを組み合わせる際に意識すべき設計ポイントは3つあります。

認証の分離管理: 各MCPサーバーのAPIトークンは環境変数で管理し、エージェントのプロンプトには絶対に埋め込みません。トークンのローテーション（定期的な更新）も設計に含めます。

データフォーマットの標準化: freeeは日本語のフィールド名、HubSpotは英語のプロパティ名を使います。エージェント間でデータを受け渡す際に、中間フォーマット（JSON Schema等）を定義しておくことで、各エージェントが他ツールの仕様を知る必要がなくなります。

レート制限への対応: freee APIは1分あたり300リクエスト、HubSpot APIは1秒あたり10リクエストといったレート制限があります。パラレルパターンで複数のAPIを同時に呼び出す場合は、リトライロジックとバックオフ（待機時間の段階的増加）を実装します。

エージェント間のデータ受け渡し設計

コンテキスト共有の3つの方式

複数のエージェントが協調するためには、中間データの受け渡し方法を明確に設計する必要があります。

方式1：直接引き渡し

前のエージェントの出力を、次のエージェントの入力プロンプトにそのまま含めます。シーケンシャルパターンで最もよく使われる方式です。シンプルですが、データ量が多い場合にLLMのコンテキストウィンドウを圧迫するリスクがあります。

方式2：共有メモリ（中間ストレージ）

Supabaseやローカルファイルシステムに中間結果を書き込み、後続のエージェントがそこから読み取ります。大量データを扱う場合や、パラレルパターンで複数エージェントの結果を集約する際に適しています。

方式3：イベント駆動

エージェントの完了時にイベントを発火し、次のエージェントをトリガーします。非同期処理が求められる場合や、処理時間が不定な場合に有効です。

エラーハンドリングとリトライ設計

エージェンティックワークフローで最も重要かつ見落とされがちなのが、エラーハンドリングの設計です。

設計時のルールとして、「失敗しても全体が止まらない」ことを意識します。たとえばfreeeからのデータ取得が失敗しても、HubSpotデータだけでレポートの一部を生成し、「会計データは手動確認が必要です」という注記を付ける設計にすれば、ワークフロー全体が停止することを防げます。

段階的な導入ステップ

フェーズ1：単一エージェント＋単一ツール

最初のステップは、1つのエージェントに1つのMCPサーバーを接続することです。たとえば「HubSpot MCPを接続したエージェントに、毎朝の新規リード一覧をSlackに投稿させる」といった小さな自動化から始めます。

この段階で検証すべきポイントは以下です。

• MCPサーバーの接続安定性（1日あたりのエラー率）
• LLMの出力精度（意図通りのデータを取得できているか）
• コスト（API呼び出し回数とLLMのトークン消費量）

フェーズ2：シーケンシャルパターンの導入

フェーズ1で安定性が確認できたら、2〜3のエージェントをシーケンシャルに接続します。たとえば「HubSpotからリード取得 → リードスコアリング → Notionにリストを作成」という3ステップのワークフローです。

この段階では、エージェント間のデータフォーマットの標準化と、エラー発生時のフォールバック処理を重点的に設計します。

フェーズ3：パラレル・階層型への拡張

シーケンシャルパターンが安定したら、並列処理や階層型オーケストレーションに拡張します。ここまで来ると、「月次経営レポートの完全自動生成」「問い合わせの自動分類・振り分け・初回対応」といった、従来は人手に頼っていた業務プロセスを丸ごと自動化できるようになります。

導入時の注意点とベストプラクティス

セキュリティの考慮事項

エージェンティックワークフローは複数のSaaSのAPIトークンを扱うため、セキュリティ設計が欠かせません。

• 最小権限の原則: 各MCPサーバーには必要最小限のスコープ（権限）のみを付与します。たとえばfreee MCPには「読み取り専用」、HubSpot MCPには「コンタクト・Dealの読み書きのみ」といった制限をかけます
• 監査ログ: エージェントがどのAPIを、いつ、どのデータに対して呼び出したかのログを残します。特に書き込み操作（データ変更）は全件記録します
• Human-in-the-Loop: 高リスクな操作（データ削除、大量更新、外部への送信）は、エージェントが自動実行するのではなく、人間の承認を挟むステップを設計に組み込みます

コスト最適化のポイント

エージェンティックワークフローのランニングコストは、主に「LLMのAPI利用料」と「各SaaSのAPI利用料」で構成されます。

コストを抑えるためのポイントは3つあります。

• モデルの使い分け: 単純なデータ取得タスクには軽量なモデル（Claude 3.5 Haiku等）を、複雑な分析タスクにはフラッグシップモデル（Claude Opus等）を割り当てることで、品質を維持しつつコストを削減できます
• キャッシュの活用: 同じデータを複数のエージェントが参照する場合、毎回APIを呼び出すのではなく、共有メモリにキャッシュしたデータを再利用します
• バッチ処理: リアルタイム性が不要な処理は、バッチ（一括処理）にまとめることでAPI呼び出し回数を削減できます

よくある質問（FAQ）

Q1. エージェンティックワークフローの構築にプログラミングスキルは必要ですか？

基本的な設計と運用にはプログラミングスキルが必要です。ただし、LangGraphやCrewAIといったフレームワークがPythonベースで提供されているため、Python の基礎知識があれば構築可能です。MCPサーバーの接続設定はJSON形式の設定ファイルで行えるため、API連携の経験がなくても取り組みやすくなっています。

Q2. どの業務から自動化を始めるべきですか？

「頻度が高く」「手順が定型化されており」「ミスをしても致命的でない」業務から始めることを推奨します。たとえば「日次のリード通知」「週次レポートのドラフト作成」「問い合わせメールの初期分類」などが好適です。いきなり月次決算の自動化に取り組むのは避けてください。

Q3. MCPに対応していないツールはどうすればよいですか？

MCPサーバーが公式に提供されていないツールでも、REST APIを公開していればカスタムMCPサーバーを開発できます。Anthropicが公開しているMCPサーバーのテンプレートを使えば、中規模のAPIラッパーを数日で実装できます。あるいは、Zapierや n8n といったiPaaS経由でMCP対応ツールと間接的に接続する方法もあります。

Q4. エージェント同士が矛盾した判断をした場合、どう解決しますか？

階層型オーケストレーションパターンでは、オーケストレーターエージェントが最終的な判断権を持ちます。たとえば、分析エージェントが「売上は順調」と判断し、異常検知エージェントが「異常値あり」と判断した場合、オーケストレーターが両方の根拠を確認し、最終判断を下します。重要な判断には必ずHuman-in-the-Loop（人間のレビュー）を組み込むことを推奨します。

Q5. ワークフローの実行コストはどのくらいですか？

コストはワークフローの複雑さとLLMの選択によって大きく変わります。たとえば、3エージェント構成のシーケンシャルワークフローを1日1回実行する場合、LLMのAPI利用料は月額数千円程度に収まるケースが一般的です。パラレルや階層型で10エージェント以上を動かす場合は、月額数万円規模になることもあります。前述のモデル使い分けとキャッシュ活用で、コストを半分以下に削減できる場合があります。

まとめ

エージェンティックワークフローは、AIエージェントの活用を「単発の質疑応答」から「業務プロセス全体の自動化」へと進化させる設計手法です。

設計のポイントを振り返ります。

• 4つの基本パターン（シーケンシャル・パラレル・ルーター・階層型）を業務特性に応じて使い分ける
• MCPで外部ツールを標準的に接続し、freee・HubSpot・Notionなど複数SaaSを1つのワークフローに統合する
• エラーハンドリングを最初から設計し、1つのエージェントの失敗がワークフロー全体を止めない構造にする
• 段階的に導入し、単一エージェント→シーケンシャル→パラレル・階層型と複雑さを増やしていく

AIエージェントを活用した業務自動化の全体像については「AIエージェントによる業務自動化の完全ガイド」もあわせてご覧ください。MCPの仕組みについて詳しく知りたい方は「MCP（Model Context Protocol）とは？AI×ツール連携の標準規格を解説」をご参照ください。

エージェンティックワークフローの設計・導入には、AIエージェントの特性を理解した上での業務プロセス分析とシステム設計が必要です。StartLinkでは、CRM（HubSpot）を軸としたAIエージェント活用のコンサルティングを提供しています。「自社の業務にエージェンティックワークフローを導入したい」「MCPを使ったツール統合の設計を相談したい」といったご要望がありましたら、お気軽にご相談ください。