先月、ある製造業の評価会で、七体のエージェントが並んだ構成図を見せられました。分けた根拠を尋ねると、返ってきた答えは「機能ごとに切りました」でした。分ける値打ちがあるかどうかは、境界が業務の責任と重なっているか、止まったときに片側だけを取り出せるかで決まります。

受注を読む係、在庫を見る係、見積を書く係、承認を待つ係。機能名で並べると図はきれいに見えます。ただ、その図では「見積の金額がずれたとき、どの係の責任なのか」を誰も即答できませんでした。

私が評価の場で最初に確かめるのは、体数でも構成の美しさでもありません。責任と切り分けの二点が揃っていない分割は、運用に入った瞬間に調査の手間だけを増やします。

分割は設計の目的ではなく、手段です。手段である以上、使わないほうが速い業務も当然あります。どちらに倒すかを、感覚ではなく判定として持っておく。

マルチエージェント オーケストレーションに倒すか、1体で足りるかは何で決まるのか？

判断軸は二つで足ります。その地点で業務の責任範囲が割れているか、そして失敗したときに原因を片側へ切り分けられるか。両方が成り立つ地点だけが、エージェントの境界として意味を持ちます。

機能の数は根拠になりません。「読む・判断する・書く」は人間が業務を説明するときの言葉であって、責任の単位ではないからです。読む係と書く係を分けても、誤りが出たときに問われる相手が同じ部署の同じ担当者なら、境界は業務のどこも切っていません。

冒頭の七体構成が扱いにくかった理由も、ここにあります。図の上では独立していても、七つのうち六つが同じ承認者の管轄で、失敗の記録も一か所にまとめて出ていました。分かれていたのは処理の名前だけで、責任と記録は分かれていなかったのです。

逆に、責任と切り分けが揃っている地点なら、体数は二つでも十分に効きます。判断の順序としては、まず境界の候補を業務側から挙げ、そのあとで技術の構成を当てる。この順序を逆にすると、構成図に業務を合わせる作業が始まります。

エージェントを分けると、実際には何が増えるのか？

増えるのは調整の往復、応答までの待ち時間、そして進行状態を保持する仕事です。分割の利点はこの三つと引き換えに手に入るもので、無料ではありません。

往復が増えるのは、確認が二重になるからです。受け渡しが一か所増えるたびに、渡す側は結果が妥当かを確かめ、受け取る側は入力が揃っているかを確かめます。処理そのものより、この確認のほうが実装の分量として重くなる場面は珍しくありません。

待ち時間は素直に積み上がります。直列に三体を並べれば、応答は三つの処理時間の合計に近づきます。人が画面の前で待つ業務では、この積み上がりが体感の品質を直接削ります。

三つ目の状態管理が、いちばん見落とされます。どこまで進んだのかを誰が持つのか。エージェント間連携の標準であるA2Aが、タスクに受付・実行中・入力待ち・認証待ち・完了・失敗・取消・却下という状態をあらかじめ定義しているのは、この保持を実装ごとに作り直さずに済ませるためです。分ける以上、状態は必ずどこかが持つことになります。

状態を持つ主体が決まっていないと、障害の復旧で最初に困ります。どこまで終わったのかを誰も答えられず、最初からやり直すか、二重に実行するかの二択に追い込まれるからです。

ここまでを費用として並べたうえで、それでも分ける価値がある業務とは何か。次の二軸が、その判定の中身です。

判断軸①：責任範囲は、どこで割れているのか？

責任が割れる地点は、承認する人が変わるところに出ます。参照してよいデータの範囲が変わるところ、失敗したときに説明する相手が変わるところも、同じ強さで境界の候補になります。

受注処理を例にとります。注文内容の確認は営業部門の管轄ですが、与信の可否は経理部門が決めます。同じ伝票を扱っていても、判断を下す人と、間違えたときに責任を負う人が入れ替わる。ここは業務側がすでに線を引いている地点です。

データの範囲も同じ働きをします。顧客の連絡先しか触らない処理と、取引条件や与信枠まで触る処理では、見てよい範囲が違います。範囲が違うものを一体に押し込むと、権限は広いほうに引きずられ、扱う情報の量が業務上の必要を超えていきます。

設備保全の現場で見た例を挙げます。作業実績の登録は現場責任者の管轄ですが、部品の発注は一定金額から購買部門の決裁に上がる線が引かれていました。この線は業務側がすでに持っていた境界で、設計の場で新しく作ったものではありません。

境界は発明するものではなく、業務の中から見つけ出すものです。

判定に使える簡単な確かめ方があります。そのエージェントができることと、そのために要る権限を、外向けの一文で宣言できるか。A2Aが公開する「エージェントカード」という仕組みも、能力と認証要件を宣言する形式を取っています。一文で書けないなら、それは境界ではなく、まだ切り分けきれていない塊です。

判断軸②：失敗したとき、原因を言い切れるか？

言い切れるのは、境界の入口と出口で入出力が記録されているときです。そこに片側だけを再実行できることが加わり、人待ちなのか異常なのかを状態で見分けられれば、原因の指摘は推測ではなくなります。

見積の自動作成でずれが出た場面を思い浮かべてください。原因の候補は、受け取った受注データが欠けていた、金額の算定が誤った、送信の段階で落ちた、の三つに分かれます。境界に記録がなければ、この三つは切り分けられず、調査は毎回全体をたどる作業になります。

「AIが間違えた」で止まってしまう報告は、たいていこの記録の欠落から生まれます。どの入力を受け取り、何を返したのか。その一行が残っていれば、責任の議論は推測ではなく事実の照合になります。私が監査ログを分割の前提条件として扱うのは、運用の便利さより先に、この点で効くからです。

記録として何を残すかは、多くを求めなくても足ります。受け取った入力の識別子、返した出力、実行の時刻、実行した主体。この四項目が境界ごとに揃っていれば、後から時系列に並べるだけで、どこで値が変わったのかを追えます。

人待ちの扱いも切り分けの一部です。承認者の返事を待っている状態と、処理が落ちた状態を同じ「未完了」にまとめると、現場は放置と障害を見分けられません。A2Aの仕様で入力待ち（TASK_STATE_INPUT_REQUIRED）と認証待ち（TASK_STATE_AUTH_REQUIRED）が終端ではない中断状態として置かれているのは、人待ちが異常ではなく正規の途中経過だからです。

二軸で並べると、業務はどこに落ちるのか？

二つの軸を掛け合わせると、業務は四つの区画に落ちます。判定は区画ごとに決まっていて、迷う余地はそれほど残りません。

責任範囲	失敗の切り分け	判定	該当しやすい業務
割れている	成り立つ	分ける	受注確認 → 与信判断 → 出荷指示
割れている	成り立たない	記録を置いてから分ける	部門をまたぐが授受の履歴が残っていない申請処理
割れていない	成り立つ	1体でよい	問い合わせの分類と一次回答の下書き
割れていない	成り立たない	1体のまま業務を整理する	担当者の判断に依存した例外処理

読み方の要点は、左上以外を「まだ分けない」と読むことです。右上の区画は、分割そのものが悪いのではなく、順序が違います。記録の置き場所を先に決めれば、同じ業務が左上へ移ります。

左下の区画は、分けても得るものがありません。承認者も参照範囲も同じなら、境界を作った分だけ往復と待ち時間が増えるだけです。ここを分けている構成図を、私は評価の場でよく見かけます。

右下は、そもそも自動化の前段が残っている状態です。判断の基準が人の頭にあるうちは、何体に分けても結果は安定しません。この区画にある業務は、エージェントの設計より先に、業務のルールを言葉にする工程が挟まります。

この区画で分割を急ぐと、判断の揺れが体をまたいで伝わります。前段の解釈が変わるたびに後段の結果も動くため、原因の追跡が二重になるのです。

区画の境目に落ちる業務もあります。承認者が形式上は二人いても、片方が押印だけの確認なら、責任は割れていません。与信の枠内なら営業が決め、枠を超えたときだけ経理へ上がる業務も、この境目に立ちます。迷ったときは、失敗の説明を求められる相手が誰かをたどると、どちらの区画に置くかが定まります。

分割は、数を増やす判断ではなく、線を置く場所を決める判断です。

1体で足りる業務は、どんな形をしているのか？

1体で足りる業務は、承認者が一人で、扱うデータの範囲も一つに収まっています。途中で人の判断が挟まらないなら、工程がいくつ並んでいても分ける理由は立ちません。

問い合わせメールの処理が分かりやすい例です。本文を読み、種別を判定し、一次回答の下書きを作る。工程は三つに見えますが、責任者はカスタマーサポートの担当一人で、参照するのは同じ問い合わせ履歴だけです。

この業務を三体に割ると、判定結果を渡す往復と、下書きの根拠を再度引き当てる処理が増えます。効果として返ってくるのは、構成図の見た目が整うことくらいでしょう。工程の多さは、分割の理由になりません。

見分け方をもう一つ挙げると、その業務を一人の担当者が最後まで処理していた過去があるかどうかです。人が一人で回せていた業務は、責任も参照範囲も一つに収まっている場合がほとんどでしょう。その形をそのまま移すほうが、運用の説明も短く済みます。

もう一つ、1体を選ぶべき局面があります。運用が始まったばかりで、どこが詰まるのかまだ分からない段階です。詰まる場所を実測してから割ると、境界が業務の実態に沿います。最初から七体に割った構成図は、たいてい詰まる場所を外しています。

エージェンティックワークフローの本番移行では、本番へ進む案件が着手の前に「どの業務の、どの指標を、いくらで改善するか」を一枚に書いていること、止まる案件は技術ではなく設計の入口でつまずくことを整理しました。分割の位置を決める作業も、この入口に含まれます。実測より先に図面で割ってしまうと、動かしたあとで線を引き直す手間が残ります。

再試行とロールバックは、どの単位に置くのか？

再試行は境界の内側に、取り消しは外部の状態を変えた地点ごとに置きます。分割の単位と再試行の単位を一致させておくと、失敗した一体だけを流し直せます。

判定の基準になるのは冪等性です。同じ入力で二度動かしても結果が変わらない処理なら、再試行は安全に自動化できます。参照や下書きの生成は、たいていこちら側に入ります。

外部の状態を変える処理は事情が違います。発注、請求データの更新、出荷指示。これらは二度動けば二重に効いてしまうため、再実行ではなく取り消しの手順を別に用意する設計になります。分割の境界をこの手前に置けるかどうかが、運用のしやすさを大きく左右します。

取り消し手順の具体例を挙げます。発注をエージェントが送った直後に在庫の引当が失敗した場合、発注そのものを撤回するのか、次の入荷として受け入れるのか。技術的にはどちらも実装できるからこそ、業務側の方針を設計前に確かめておきます。

「ChatGPTは答えます。WindyFloは働きます。」——答えるところで止まる処理なら、失敗しても答えが間違うだけで、業務データは傷つきません。外部の状態に手を伸ばした瞬間から、責任と切り分けの設計が実装の中心に移ります。分割の議論が本当に効いてくるのは、この線を越えた業務です。

人の承認点は、分割で何か所になるのか？

承認点は、分けた体数ではなく、責任が変わる地点の数だけ置きます。機能で割ると承認点が機械的に増え、現場は待ち時間の管理に追われることになります。

七体構成の評価会で実際に起きていたのが、この増殖でした。各エージェントの出力に確認画面が付き、担当者は一日に何度も同じ伝票を承認していたのです。責任で割り直したところ、承認点は与信と出荷指示の二か所に整理できました。

この構成では、承認画面の多さが自動化の効果そのものを打ち消していました。処理は速くなったのに、担当者の作業時間はほとんど変わらない。分割の費用が効果を上回った形と言っていいでしょう。

判定の順序は単純です。決裁規程や業務分掌で人が判を押している地点を先に書き出し、その地点だけを承認点として残す。エージェントの構成は、そのあとで承認点をまたがない形に組みます。

承認点を置いたら、待ち行列の扱いもあわせて決めます。承認者が不在のとき、処理は待ち続けるのか、代理へ回るのか、一定時間で差し戻されるのか。ここを決めないまま本番に入ると、止まった案件が誰の目にも触れない場所へ溜まっていきます。

承認点を誰が持つのかという論点も、あわせて決めておきたいところです。運用の担い手を業務チームに置くのか情報システム部門に預けるのかで、承認の速度と例外処理の手順が変わります。この役割分担は非エンジニアがAIエージェントを運用する体制で詳しく扱いました。

AIエージェント 連携の標準化は、この判断に何を与えるのか？

標準は境界の作り方を与えますが、境界をどこに置くかまでは決めてくれません。ここを取り違えると、対応済みの製品を選べば設計が済むという誤解が生まれます。

現状だけ押さえておきます。A2Aは2025年6月23日にLinux Foundationのプロジェクトとして発足し、2026年4月9日の発表では支持組織が150を超え、仕様はバージョン1.0に到達しました。道具接続を担うModel Context Protocol（MCP）も2025年12月9日に発足したAgentic AI Foundationへ寄贈され、版は日付形式で管理されて現行リビジョンは2026年7月28日版です。

発足の経緯や参画企業の顔ぶれはエージェント間プロトコルの標準化で扱いました。分割の判断に効くのは、置き場所が一社の手を離れたという事実よりも、標準が何を決めてくれて何を決めてくれないかの線引きのほうです。

標準が与えるものを具体的に言えば、状態の共通表現と、能力を宣言する形式です。自社で決めた独自の状態名を、連携先ごとに翻訳して回る作業は減ります。手間が減る場所と減らない場所を分けておくと、製品選定の物差しが安定します。

相互運用が整うほど、残る問いは「つながるか」から「分けるべきか」へ移ります。つながること自体が難しかった時期は、接続の可否が設計の中心にありました。接続が前提になった今、判断の重心は責任と切り分けの側に寄っています。

分割の判断を、社内でどう進めるのか？

手順は五段階です。承認者と決裁で業務を区切る、区切りごとに入出力を書き出す、記録の取れない区切りに記録を置く、まず1体で通して動かす、止まった地点で初めて割る。

最初の二段階は、技術の話にほとんど触れません。決裁規程と業務分掌を机に広げ、人が判を押す地点に印を付けるだけです。この作業を情報システム部門だけで進めると、業務側の実際の運用と図がずれます。

三段階目でつまずく現場が多いという実感があります。部門をまたぐ受け渡しが、メールや口頭で行われていて履歴が残っていないのです。ここは分割の前に手当てする箇所で、記録が取れない境界は切っても切り分けられません。

記録を置く作業は、システム改修に見えて、実際は運用の取り決めで済むことも少なくありません。共有の受付フォームに一本化する、受け渡しの起点を一つの台帳に寄せる。その程度の整理で切り分けの条件が満たされる場面もあります。

四段階目の「まず1体」を飛ばさないことを、私は強くおすすめします。1体で通すと、どの工程で時間がかかり、どこで人が介入しているかが実測で出ます。その実測が、五段階目の分割位置を決める根拠になります。図面上の推測より、一度動かした記録のほうが精度は高いのです。

WindyFloで私たちが設計思想として置いているのも、この順序です。ノーコードで実行フローを組み、業務チームが日本語のまま運用できる状態を保ち、外部システムへ届く実行には制御点と記録を持たせる。基幹システムとの連携を前提にした構成を、開発チームの常駐なしで運用できる形にまとめています。分割の判断そのものは、この基盤の上でも各社の業務に沿って個別に決めていくものです。

責任範囲が割れているか。失敗を切り分けられるか。この二つに「はい」と答えられない地点は、まだ境界ではありません。

体数を増やす前に、業務の側でどこに線が引かれているかを見に行く。遠回りに見えて、運用に入ってからの調査時間をいちばん短くする道です。

自社の業務がどの区画に落ちるかを具体的に確かめたい段階であれば、WindyFloの無料トライアルで、一つの工程を1体で通すところから試せます。止まった地点が見えたら、そこが最初の境界の候補になります。

よくある質問

出典

• ［1次］The Linux Foundation「Linux Foundation Launches the Agent2Agent Protocol Project to Enable Secure, Intelligent Communication Between AI Agents」（2025年6月23日発表）— A2Aプロジェクトの発足、AWS・Cisco・Google・Microsoft・Salesforce・SAP・ServiceNowの参画、ベンダーロックイン緩和という目的: https://www.linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents
• ［1次］The Linux Foundation「A2A Protocol Surpasses 150 Organizations, Lands in Major Cloud Platforms, and Sees Enterprise Production Use in First Year」（2026年4月9日発表）— 支持組織150超、仕様バージョン1.0、主要クラウドプラットフォームへの統合: https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year
• ［1次］A2A Protocol 公式仕様 v1.0.0 — エージェントカードによる能力・認証要件の宣言、タスク状態の定義（TASK_STATE_SUBMITTED / TASK_STATE_WORKING / TASK_STATE_INPUT_REQUIRED / TASK_STATE_AUTH_REQUIRED / TASK_STATE_COMPLETED / TASK_STATE_FAILED / TASK_STATE_CANCELED / TASK_STATE_REJECTED。未指定を表す TASK_STATE_UNSPECIFIED を除く。うち入力待ち・認証待ちは終端ではない中断状態）: https://a2a-protocol.org/latest/specification/
• ［1次］The Linux Foundation「Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF)」（2025年12月9日発表）— Model Context Protocol（MCP）・goose・AGENTS.mdを創設プロジェクトとするAAIFの設立: https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
• ［1次］Model Context Protocol 公式ドキュメント「Versioning」— 日付形式（YYYY-MM-DD）による版管理と、現行リビジョン2026-07-28: https://modelcontextprotocol.io/specification/versioning
• 本稿の分割判断・承認点・記録に関する記述は、ハマダラボ（HAMADA LABS Japan）CTOによる導入支援現場での一次観察に基づくものであり、特定企業の実在事例ではありません。