エージェンティックワークフローとは、複数のAIエージェントが役割分担しながら協調して業務を遂行する仕組みです。従来の単一プロンプト型AIとは異なり、「計画→実行→検証→修正」のサイクルをエージェント間で自律的に回すことで、会計処理・CRM更新・ドキュメント生成といった複雑な業務プロセスを端から端まで自動化できます。本記事では、MCP（Model Context Protocol）を活用したエージェント間連携の設計パターンと、freee・HubSpot・Notionを統合した実装例を解説します。
「AIに業務を任せたいが、単体のチャットボットでは複雑なプロセスに対応しきれない」――そんな課題を抱える企業が増えています。たとえば「freeeの売上データを集計し、HubSpotのパイプラインと突合して、Notionにレポートを作成する」といった業務は、1つのAIエージェントに全工程を任せるには複雑すぎます。
この課題を解決するのがエージェンティックワークフローの設計手法です。複数のAIエージェントにそれぞれ専門的な役割を持たせ、MCPで外部ツールと接続し、オーケストレーション（指揮統制）のロジックで連携させることで、人手を介さない業務自動化が実現します。
本記事は、AIエージェントによる業務自動化の全体像を踏まえた実践編です。設計原則から具体的なアーキテクチャパターンまで、段階的に解説します。
従来のAI活用は「1つのプロンプトに1つの回答」が基本でした。ChatGPTやClaudeに質問を投げ、回答を得る。この単発のやり取りでは、複数のシステムをまたぐ業務プロセスを自動化することはできません。
エージェンティックワークフローは、この限界を突破する設計思想です。核となる考え方は以下の3つです。
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つの基本設計パターンがあります。
最もシンプルなパターンです。エージェントAの出力をエージェントBの入力として渡し、順番に処理を進めます。
| 項目 | 内容 |
|---|---|
| 適用場面 | 前工程の結果が次工程に必須な業務 |
| 具体例 | freeeから月次売上取得 → データ集計 → Notionにレポート作成 |
| メリット | 設計がシンプル、デバッグが容易 |
| デメリット | 処理時間が長い（直列のため） |
たとえば「月次経営レポートの自動生成」では、freee MCPで会計データを取得するエージェントが最初に動き、その出力を受けて分析エージェントが集計・分析を行い、最後にNotion MCPでレポートページを作成するエージェントが仕上げます。
複数のエージェントが同時に異なるタスクを実行し、結果を集約するパターンです。
| 項目 | 内容 |
|---|---|
| 適用場面 | 互いに独立したデータソースから情報を集める業務 |
| 具体例 | freee売上取得とHubSpotパイプライン取得を同時実行 → 統合レポート |
| メリット | 処理時間の短縮 |
| デメリット | 結果の統合ロジックが必要 |
会計データ（freee）とCRMデータ（HubSpot）の取得は互いに依存しないため、並列で実行できます。両方の結果が揃った時点で、統合エージェントがデータを突合してレポートを生成します。
入力データの内容に応じて、異なるエージェントに処理を振り分けるパターンです。
| 項目 | 内容 |
|---|---|
| 適用場面 | 入力の種類によって処理が分岐する業務 |
| 具体例 | 問い合わせ内容を判別 → 技術質問はナレッジ検索、見積依頼はCRM登録 |
| メリット | 柔軟な対応が可能 |
| デメリット | 分類精度がワークフロー全体の品質を左右する |
ルーターエージェントは「交通整理役」です。たとえばHubSpotのフォームから入った問い合わせを分析し、「製品に関する技術的質問」ならナレッジベース検索エージェントに、「見積依頼」ならHubSpotのDeal作成エージェントに、「クレーム」ならSlack通知エージェントにそれぞれ処理を委任します。
最も高度なパターンです。「オーケストレーター（指揮者）」となるエージェントが全体計画を立て、配下のエージェントにタスクを割り振り、結果を統合します。
| 項目 | 内容 |
|---|---|
| 適用場面 | 複雑で動的に手順が変わる業務 |
| 具体例 | 経営ダッシュボード更新（データ取得→異常検知→原因分析→レポート→通知） |
| メリット | 複雑な業務フローに対応可能 |
| デメリット | 設計・テストの難易度が高い |
オーケストレーターは、最初に業務の全体計画を立てます。たとえば「前月のKPIを更新する」というタスクに対して、「(1) freeeから売上データ取得、(2) HubSpotからMRR・解約率取得、(3) 前月比の異常値を検出、(4) 異常値があればSlackで通知、(5) Notionのダッシュボードを更新」というステップを自動で計画し、各ステップを担当エージェントに振り分けます。
エージェンティックワークフローの実効性は、AIエージェントがどれだけ多くの業務ツールを直接操作できるかにかかっています。MCPはこの課題を解決する標準プロトコルです。
BtoB企業で特に利用頻度が高いMCPサーバーの組み合わせは以下のとおりです。
| 領域 | MCPサーバー | 主な用途 |
|---|---|---|
| 会計・経理 | freee MCP | 売上・経費・仕訳データの取得と登録 |
| CRM・営業 | HubSpot MCP | コンタクト・Deal・パイプラインの参照と更新 |
| ドキュメント | Notion MCP | ページ・データベースの作成と更新 |
| コミュニケーション | Slack MCP | メッセージ送信・チャンネル読み取り |
| 開発・コード | GitHub MCP | リポジトリ操作・Issue管理 |
| データベース | Supabase MCP | SQLクエリ実行・テーブル操作 |
この6つのMCPサーバーを組み合わせることで、BtoB企業の主要な業務プロセスの大部分をカバーできます。
freee（会計）・HubSpot（CRM）・Notion（ドキュメント）を統合するワークフローは、多くのBtoB企業で共通する需要があります。具体的な設計パターンを見てみましょう。
ユースケース：月次経営レポートの自動生成
この業務フローは、階層型オーケストレーションで設計します。
このワークフローでは、ステップ2と3が並列処理（パラレルパターン）、全体は階層型オーケストレーションで管理されるという、パターンの組み合わせになっています。
MCPサーバーを組み合わせる際に意識すべき設計ポイントは3つあります。
認証の分離管理: 各MCPサーバーのAPIトークンは環境変数で管理し、エージェントのプロンプトには絶対に埋め込みません。トークンのローテーション（定期的な更新）も設計に含めます。
データフォーマットの標準化: freeeは日本語のフィールド名、HubSpotは英語のプロパティ名を使います。エージェント間でデータを受け渡す際に、中間フォーマット（JSON Schema等）を定義しておくことで、各エージェントが他ツールの仕様を知る必要がなくなります。
レート制限への対応: freee APIは1分あたり300リクエスト、HubSpot APIは1秒あたり10リクエストといったレート制限があります。パラレルパターンで複数のAPIを同時に呼び出す場合は、リトライロジックとバックオフ（待機時間の段階的増加）を実装します。
複数のエージェントが協調するためには、中間データの受け渡し方法を明確に設計する必要があります。
方式1：直接引き渡し
前のエージェントの出力を、次のエージェントの入力プロンプトにそのまま含めます。シーケンシャルパターンで最もよく使われる方式です。シンプルですが、データ量が多い場合にLLMのコンテキストウィンドウを圧迫するリスクがあります。
方式2：共有メモリ（中間ストレージ）
Supabaseやローカルファイルシステムに中間結果を書き込み、後続のエージェントがそこから読み取ります。大量データを扱う場合や、パラレルパターンで複数エージェントの結果を集約する際に適しています。
方式3：イベント駆動
エージェントの完了時にイベントを発火し、次のエージェントをトリガーします。非同期処理が求められる場合や、処理時間が不定な場合に有効です。
エージェンティックワークフローで最も重要かつ見落とされがちなのが、エラーハンドリングの設計です。
| エラー種別 | 原因例 | 対処パターン |
|---|---|---|
| API接続エラー | freee APIのレート制限超過 | 指数バックオフでリトライ（最大3回） |
| データ不整合 | HubSpotのDealに必須フィールドが未入力 | デフォルト値で補完 or スキップして通知 |
| LLM出力エラー | エージェントの回答がJSON形式でない | プロンプトを調整して再実行 |
| 権限エラー | MCPサーバーのトークン期限切れ | Slackで管理者に即時通知 |
設計時のルールとして、「失敗しても全体が止まらない」ことを意識します。たとえばfreeeからのデータ取得が失敗しても、HubSpotデータだけでレポートの一部を生成し、「会計データは手動確認が必要です」という注記を付ける設計にすれば、ワークフロー全体が停止することを防げます。
最初のステップは、1つのエージェントに1つのMCPサーバーを接続することです。たとえば「HubSpot MCPを接続したエージェントに、毎朝の新規リード一覧をSlackに投稿させる」といった小さな自動化から始めます。
この段階で検証すべきポイントは以下です。
フェーズ1で安定性が確認できたら、2〜3のエージェントをシーケンシャルに接続します。たとえば「HubSpotからリード取得 → リードスコアリング → Notionにリストを作成」という3ステップのワークフローです。
この段階では、エージェント間のデータフォーマットの標準化と、エラー発生時のフォールバック処理を重点的に設計します。
シーケンシャルパターンが安定したら、並列処理や階層型オーケストレーションに拡張します。ここまで来ると、「月次経営レポートの完全自動生成」「問い合わせの自動分類・振り分け・初回対応」といった、従来は人手に頼っていた業務プロセスを丸ごと自動化できるようになります。
エージェンティックワークフローは複数のSaaSのAPIトークンを扱うため、セキュリティ設計が欠かせません。
エージェンティックワークフローのランニングコストは、主に「LLMのAPI利用料」と「各SaaSのAPI利用料」で構成されます。
コストを抑えるためのポイントは3つあります。
基本的な設計と運用にはプログラミングスキルが必要です。ただし、LangGraphやCrewAIといったフレームワークがPythonベースで提供されているため、Python の基礎知識があれば構築可能です。MCPサーバーの接続設定はJSON形式の設定ファイルで行えるため、API連携の経験がなくても取り組みやすくなっています。
「頻度が高く」「手順が定型化されており」「ミスをしても致命的でない」業務から始めることを推奨します。たとえば「日次のリード通知」「週次レポートのドラフト作成」「問い合わせメールの初期分類」などが好適です。いきなり月次決算の自動化に取り組むのは避けてください。
MCPサーバーが公式に提供されていないツールでも、REST APIを公開していればカスタムMCPサーバーを開発できます。Anthropicが公開しているMCPサーバーのテンプレートを使えば、中規模のAPIラッパーを数日で実装できます。あるいは、Zapierや n8n といったiPaaS経由でMCP対応ツールと間接的に接続する方法もあります。
階層型オーケストレーションパターンでは、オーケストレーターエージェントが最終的な判断権を持ちます。たとえば、分析エージェントが「売上は順調」と判断し、異常検知エージェントが「異常値あり」と判断した場合、オーケストレーターが両方の根拠を確認し、最終判断を下します。重要な判断には必ずHuman-in-the-Loop（人間のレビュー）を組み込むことを推奨します。
コストはワークフローの複雑さとLLMの選択によって大きく変わります。たとえば、3エージェント構成のシーケンシャルワークフローを1日1回実行する場合、LLMのAPI利用料は月額数千円程度に収まるケースが一般的です。パラレルや階層型で10エージェント以上を動かす場合は、月額数万円規模になることもあります。前述のモデル使い分けとキャッシュ活用で、コストを半分以下に削減できる場合があります。
エージェンティックワークフローは、AIエージェントの活用を「単発の質疑応答」から「業務プロセス全体の自動化」へと進化させる設計手法です。
設計のポイントを振り返ります。
AIエージェントを活用した業務自動化の全体像については「AIエージェントによる業務自動化の完全ガイド」もあわせてご覧ください。MCPの仕組みについて詳しく知りたい方は「MCP（Model Context Protocol）とは？AI×ツール連携の標準規格を解説」をご参照ください。
エージェンティックワークフローの設計・導入には、AIエージェントの特性を理解した上での業務プロセス分析とシステム設計が必要です。StartLinkでは、CRM（HubSpot）を軸としたAIエージェント活用のコンサルティングを提供しています。「自社の業務にエージェンティックワークフローを導入したい」「MCPを使ったツール統合の設計を相談したい」といったご要望がありましたら、お気軽にご相談ください。