AIエージェントがシステム連携を実行する時代へ｜「つなぎ込み」保守負債の見直し方

「販売管理と会計と在庫と、SaaSを何本かつないでいるが、その"つなぎ込み"が今いくらの保守費になっているか、即答できるだろうか。」 システム開発の見積もりを見ると、多くの経営者は画面や機能の数に目が行く。だが、システムが増えた企業でじわじわ効いてくるのは、機能そのものではなく、システムとシステムのあいだをつなぐ「連携（インテグレーション）」の保守費だ。1本の仕様変更が別の連携を止め、その調査と修正に人と時間がかかる。この領域に、AIエージェントで手を入れる動きが出てきた。

データ連携基盤HULFT／DataSpiderで知られる株式会社セゾンテクノロジーが、AIエージェントを統合的に運用・管理し、社内に散在するデータソースとの連携やジョブ実行を組み合わせる基盤「Agent Orchestration」を打ち出した。データ連携プラットフォーム「HULFT Square」の一部として提供され、AIエージェントに外部APIやデータ連携ジョブを実行させる方向性が示されている。本記事では、この動きを起点に、連携という「見えないコスト」をどう見直すか、そしてAIに任せてよい連携と人が設計し続けるべき連携をどう線引きするかを、発注する側の視点で整理する。

この記事の要点

• セゾンテクノロジーはAI業務実行基盤「Agent Orchestration」を2026年7月1日に提供開始した。HULFT SquareのAI-Startパックには標準搭載、Standard／Enterpriseにはアドオンとして提供する。
• 同基盤は、複数のAIエージェントを登録し、アクセスできるデータ・使うLLM・利用ユーザー・行動範囲を設定できる。DB検索やWeb検索、HULFT Squareのジョブや外部APIを「アクション」として呼び出せることを公式発表で確認した。
• システムが増えるほど連携の組み合わせは足し算ではなく掛け算で増え、1本の仕様変更が他の連携を止める。連携は機能開発より見えにくいまま保守負債として積み上がる。
• AIエージェントは「連携をつくる・つなぎ直す・監視する」作業の一部を効率化しうるが、データの意味の定義、例外の扱い、止まったときの責任は人が握り続ける領域である。
• 連携を新規発注するときは、仕様変更への追随・監視・停止時の通知・エラー時の責任分界を見積もりと契約で確認する。まず自社の連携を棚卸しすることが出発点になる。

セゾンテクノロジー「Agent Orchestration」で示された方向性

まず事実を整理する。セゾンテクノロジーは、AIエージェントを全社で統合的に運用・管理する基盤「Agent Orchestration」を2026年7月1日に提供開始した。位置づけは、同社のデータ連携プラットフォーム「HULFT Square」の一部だ。同社の公式発表によれば、AIエージェントを安全に全社展開するための「業務実行基盤」であり、単なるチャットボットではなく、業務のアクションを実行させることに軸足がある。

公表されている機能像を、発注側の言葉に置き換えると次のようになる。

ここで注目したいのは、最後から二番目の「HULFT Squareのジョブや外部APIを連携アクションとして登録」という部分だ。これは、AIエージェントに「システム連携を実行させる」という発想であり、従来は人が手順書に沿って回していた連携処理や、都度の手作業でのデータ受け渡しを、AIの判断や自然言語の指示から起動できるようにする方向を示している。公式発表時の価格は、AI-Startパックが月額68万円（税別）から、Standard／Enterpriseへのアドオンが月額20万円（税別）である。契約時は最新の価格と含まれる機能を確認したい。

重要なのは、特定製品を勧めることではない。この発表が示すのは「連携という作業領域にAIが入り始めた」という潮流であり、それは自社の連携コストと運用を今のうちに棚卸ししておく理由になる、ということだ。ツールがどうであれ、つないでいる中身を把握していない企業は、自動化の恩恵も受けにくいし、自動化に伴うリスクも管理できない。

なぜ「連携」がシステム保守費の見えない主役になるのか

システム開発を発注するとき、経営者や情シスの意識は「どんな画面が、どんな機能で動くか」に集中しやすい。見積書でも、機能一覧や画面数は目に見える形で並ぶ。ところが、稼働してから数年かけて費用を食っていくのは、その機能そのものよりも、システムとシステムのあいだをつなぐ連携であることが多い。

理由は、連携が「他人の都合」で壊れるからだ。自社が何も変えていなくても、つなぎ先のSaaSが仕様を変える、APIのバージョンが上がる、認証方式が切り替わる、項目が増減する——こうした外部要因で連携は止まる。機能は自社の中で完結するが、連携は常に相手のあるものだ。だからこそ、連携は「作って終わり」にはならず、つなぎ先の変化を追いかけ続ける保守が発生する。

さらに厄介なのは、連携が止まったときの症状が分かりにくいことだ。画面が真っ白になれば誰でも異常に気づく。しかし連携は、裏側でデータが半分だけ流れていた、昨夜の同期が失敗して数字が古いまま、といった形で静かに壊れる。気づいたときには、会計と販売の数字が合わない、在庫が実態とずれている、といった業務の混乱として表面化する。見えないところで壊れ、業務の下流で問題が噴き出す。これが連携保守の難しさだ。

そして、この保守を担える人が社内に薄いのが中堅企業の実情だ。ひとり情シスや兼任情シスの体制では、連携がどこにいくつあり、どんな条件で動いているかを把握しきれない。作った当時のベンダーが分かる人もいなくなり、「触ると何が止まるか分からないから触れない」という塩漬け状態になる。連携は、見えないまま増え、見えないまま壊れ、見えないまま人依存になる。これが保守負債の正体だ。自社の連携やシステムの現在地を客観的に見立てたい場合は、DX成熟度診断のような第三者の物差しで一度可視化しておくと、投資判断の土台になる。

連携の組み合わせは足し算ではなく掛け算で増える

連携が厄介なのは、システムを1つ増やすたびに、増える連携が1本では済まないからだ。ここを直感で捉え違えると、システム投資の判断を誤る。

システムをそれぞれ個別に直接つなぐ（ポイント・ツー・ポイント）構成を考える。システムが3つなら、つなぐ組み合わせは最大3通り。4つなら6通り。5つなら10通り。6つなら15通り。システムの数をNとすると、組み合わせは N×(N−1)÷2 で増えていく。つまりシステムが倍になると、連携はおおむね4倍近くまで膨らむ余地がある。実際には全部をつなぐわけではないが、「システムを1つ足すこと」と「連携を1本足すこと」はコスト感がまったく違う、という点が本質だ。

この掛け算の効果が、保守で二重に効く。第一に、連携の本数そのものが増えるので、監視・更新の対象が増える。第二に、1本の仕様変更が波及する範囲が広がる。ある基幹システムの項目を1つ変えただけで、そこにぶら下がっている連携すべてを直す必要が出る。「小さな変更のはずが、なぜか見積もりが大きい」という場面の多くは、この波及範囲を見落としているために起きる。変更したい機能は小さくても、それが触れる連携の本数だけ、影響調査と回帰確認のコストがかかる。

だからこそ、システムを足すたびに「つなぎ方」を無計画に増やすと、数年後の保守費が静かに肥大化する。連携は、増やすときのコストより、抱え続けるコストの方が大きい。新しいSaaSを1本入れる意思決定のときに、「これは既存の何本とつなぐのか」「そのつなぎは誰が保守し続けるのか」までセットで考える習慣が、後年のコストを大きく左右する。

AIエージェントが連携で自動化できること・できないこと

ではAIエージェントは、この連携の負債をどこまで肩代わりしてくれるのか。過度な期待も過度な警戒も避け、作業の粒度で分けて考えるのが実務的だ。

AIエージェントやAIを組み込んだ連携ツールが効きやすいのは、次のような「判断より作業」の領域だ。連携をつくる初期作業のうち、ドキュメントを読んでAPIの叩き方の下書きを作る、項目のマッピング案を提示する、テストデータを流して差分を洗う、といった定型的で参照可能な作業。日々の運用のうち、ログを見て異常のパターンを拾う、失敗したジョブの再実行を試みる、エラーメッセージから原因の当たりをつけて候補を示す、といった一次対応。こうした「調べる・下書きする・繰り返す」作業は、AIが得意とし、人の工数を圧縮しやすい。自社の定型業務にこうしたAIを組み込む設計は、AIエージェント導入の要件定義として整理していくと進めやすい。

一方で、AIに任せきると危ういのは、次のような「作業ではなく判断」の領域だ。この線引きを曖昧にしたまま自動化を広げると、静かに壊れる連携を量産することになりかねない。

• データの意味の定義：「顧客コード」が販売システムと会計システムで同じ意味とは限らない。同じ名前の項目が別物を指すことは頻繁にあり、その突き合わせは業務を知る人の判断がいる。AIは形式は合わせられても、意味の一致までは保証できない。
• 例外の扱い：正常系はAIでも回せる。だが「値引きが規定を超えたらどうするか」「重複データが来たらどちらを正とするか」といった例外の設計は、業務ルールそのものであり、経営や現場の意思が必要になる。
• 止まったときの責任：連携が失敗し、誰にどう通知し、どこまで自動で再実行し、どこから人が判断するか。この停止時の運用設計は、責任の所在を決める行為であり、AIに委ねるべきものではない。

つまりAIエージェントは、連携の「筋肉」を効率化するが、「背骨」——何を正とし、例外をどう扱い、止まったら誰が責任を持つか——は人が握り続ける。ここを取り違えて「AIが全部つないでくれる」と考えると、かえって統制の効かない連携が増える。だからこそ、セゾンテクノロジーの基盤も「エージェントごとにアクセスできるデータや行動範囲を設定する」統制機能を備えているのだと読める。自動化の価値は、統制とセットで初めて成立する。

人が設計し続けるべき「背骨」を発注仕様に落とす

前節の「背骨」を、発注や運用の言葉に翻訳しておくと、ベンダーとの認識ずれを防げる。連携を外部に任せるとしても、次の4点は自社が意思を持って決め、仕様書に書き込む対象だ。

1. 正データの定義：連携で突き合わせる項目それぞれについて、どのシステムの値を正とするか。マスタはどこか。名寄せのルールは何か。これを決めずに連携を作ると、数字の不一致が起きたとき、どちらが正しいか誰も断言できなくなる。
2. 例外時の分岐：想定外のデータや業務ルール違反が来たとき、止めるのか、保留にするのか、警告付きで通すのか。この分岐は業務判断であり、ベンダーに白紙委任してはいけない。
3. 監視と通知の設計：連携が失敗したことを、いつ・誰が・どの手段で知るのか。「翌朝までメールも来ない」設計だと、静かに壊れて業務下流で気づく事態になる。
4. 再実行と責任分界：失敗したとき、どこまで自動リトライし、どこから人が判断するか。復旧の責任は自社かベンダーか、契約でどう定めるか。

この4点は、AIエージェントで連携を自動化する場合でも変わらない。むしろ自動化が進むほど、この背骨が曖昧なまま高速に動いてしまうリスクが上がる。人手なら「なんか変だ」と気づけた違和感を、自動化は素通りさせてしまうからだ。

「つなぐ」を減らす設計：集約と標準化という上流の一手

保守負債を根本から軽くする有力な手は、「うまくつなぐ」だけでなく「つなぐ本数を減らす」ことだ。ポイント・ツー・ポイントの最大組み合わせは N×(N−1)÷2 で増えるため、ハブ型へ寄せて本数を抑えれば、監視・変更・障害切り分けの対象を減らせる。方向性は大きく3つある。

第一に、ハブを置く。 すべてのシステムを互いに直接つなぐのではなく、真ん中に連携基盤（ハブ）を1つ置き、各システムはハブとだけつなぐ構成にする。こうすると連携本数は N×(N−1)÷2 から N 本前後まで下がる。iPaaSやデータ連携基盤が担うのがこの役割だ。新しいシステムを足すときも、ハブと1本つなげば済む。1本の変更が全体に波及する事態も、ハブで受け止めて吸収できる。

第二に、データを一箇所に集約する。 各システムがそれぞれ勝手にデータを持ち、都度つなぎ合わせる構造は、連携を増やす温床だ。分析や参照に使うデータを一度データ基盤（データウェアハウス／レイクハウス）に集約すれば、「集計のためにあちこちをつなぐ」連携を大きく減らせる。連携の主目的が「リアルタイムの業務処理」なのか「分析・可視化」なのかを分け、後者は集約に寄せるのが定石だ。この集約の設計は、データ活用基盤構築として要件を整理すると、後々の連携本数を根本から減らせる。

第三に、つなぎ方を標準化する。 同じ相手に対して、ある連携はCSVの夜間バッチ、別の連携はAPIのリアルタイム、さらに別のは手作業のExcel、とバラバラだと、それぞれに保守が要る。接続方式・データ形式・認証を社内で標準化し、「新しい連携はこの型で作る」と決めておくと、保守の型も一本化できる。AIエージェントに連携を任せるにしても、標準化されていない連携ほど自動化は難しい。標準化は自動化の前提条件でもある。

この3つは、いずれも「個別の連携をどう作るか」より上流の、システム全体の構え方の話だ。だからこそ、目先の一本を安く作ることより、全体をどう構えるかの設計が効く。ここはシステム開発の上流工程として、機能要件と同じ重さで検討する価値がある。

連携を新規発注するとき、見積もりと契約で確認すること

新しい連携を発注する、あるいは既存の連携を作り直すとき、見積書と契約書で確認しておきたい観点を挙げる。連携は「作る費用」より「抱える費用」が大きいので、初期費用の安さだけで選ぶと後で高くつく。

特に見落とされやすいのが「仕様変更への追随」と「停止時の通知」だ。前者を保守契約に含めずに発注すると、つなぎ先が変わるたびに追加費用が発生し、見積もり時の想定と実際の年間コストが大きくずれる。後者を設計に入れておかないと、静かに壊れる連携の症状に、業務が混乱してから気づくことになる。見積書のどこにも「監視」「通知」「追随」の記述がないなら、それは含まれていないと考えて確認したほうがよい。見積もりの読み解きに不安があれば、発注前の第三者チェックとして開発の見積もりや要件を相談するという使い方もできる。

自社の連携を棚卸しする手順

自動化を検討するにも、保守負債を減らすにも、出発点は「今どれだけ、何を、どうつないでいるか」を可視化することだ。以下の手順で一度洗い出しておくと、投資判断もベンダー相談も具体的になる。

1. 連携を一覧化する。 販売・会計・在庫・人事・各SaaS間で、データが行き来している経路をすべて書き出す。夜間バッチ、API、手作業のExcelコピペ、RPA——手段を問わず、データが移動しているものはすべて連携として数える。
2. 各連携の属性を埋める。 つなぐ元と先、流れるデータ、頻度（リアルタイム／日次／手作業）、使っている手段、作った時期、作ったベンダー、保守契約の有無。この時点で「誰も分からない連携」が出てきたら、それが最優先のリスクだ。
3. 止まったときの影響を評価する。 その連携が半日止まると、どの業務が困るか。業務停止に直結するものと、多少遅れても問題ないものを分ける。すべてを同じ重さで守ろうとすると、費用がいくらあっても足りない。
4. 手作業の連携を特定する。 人がExcelでコピペしている、目視で突き合わせている経路は、ミスと属人化の温床であり、自動化の効果が最も出やすい候補だ。
5. 重複と迂回を探す。 同じデータを別々の経路で二重に流していないか、本来ハブを通せば1本で済むものを直接つないでいないか。ここが「つなぐを減らす」余地になる。

この棚卸しは、特別なツールがなくても表計算1枚から始められる。むしろ、この一覧が埋まらない・埋められる人がいない、という事実自体が、自社の連携がどれだけ人依存でブラックボックス化しているかの診断結果になる。

ベンダーに送る確認文テンプレート

既存の連携をベンダーに整理してもらう、あるいは新規連携を相談するとき、そのまま使える確認文の例を挙げる。自社の状況に合わせて調整してほしい。

お世話になっております。現在弊社で稼働している（または新規に検討している）
システム連携について、下記の点を確認させてください。

【現状把握】
・現在稼働している連携の一覧（つなぐ元・先、流れるデータ、頻度、手段）
・各連携の仕様書・項目マッピングの有無と、最新化されているか
・作成時期と、現在保守契約の対象になっているか

【変更への強さ】
・つなぎ先（SaaS/API）が仕様変更した場合、追随対応は保守に含まれるか、
 都度費用か。過去1年で追随対応が何件発生したか
・特定の項目や仕様を1つ変えると、影響が及ぶ連携はどれか

【運用】
・連携が失敗したことを、いつ・誰が・どの手段で検知しているか
・失敗時の再実行と復旧の手順、担当（自社／御社）の分界
・監視・通知は費用に含まれているか、別料金か

【将来】
・他社でも保守を引き継げる形になっているか（特定担当者への依存の有無）
・つなぐ本数を減らす（ハブ集約・データ基盤集約）余地はあるか

現状の見える化を目的としていますので、
「分からない」「記録がない」という回答も、そのままお知らせください。

最後の一文が効く。「分からない」という回答が返ってくること自体が、その連携のリスクの高さを示す。きれいな答えを求めるより、空白がどこにあるかを見つけることが、この確認の目的だ。

自社の連携が、今いくらの保守負債になっているか整理しませんか

システムやSaaSが増えて「つなぎ込み」の保守費が見えにくくなっている、仕様変更のたびに想定外の追加費用が出る、止まっても気づけない連携が残っている——こうした段階での棚卸しと整理を、GXOは発注する側の立場で支援します。特定ツールありきではなく、まず自社の連携の現在地を可視化し、AIに任せてよい連携と人が設計すべき連携を分けるところから始められます。

システム連携の棚卸し・見直しを相談する → GXO お問い合わせ

AIに任せてよい連携／人が設計すべき連携の線引き

最後に、自動化をどこから始めるかの判断軸を、連携の性質で整理しておく。すべてを一律にAI化するのでも、すべてを人手で抱えるのでもなく、性質で分けるのが現実的だ。

読み方はシンプルだ。表の左側に寄る連携ほど、AIエージェントや連携ツールに任せて工数を削る効果が出やすい。右側に寄る連携ほど、自動化しても背骨は人が設計し続ける必要がある。そして、右側の連携を「楽そうだから」と安易に自動化に寄せることが、静かに壊れる連携を生む典型的な失敗だ。まず左側から自動化して手応えを掴み、右側は統制と監視をセットで慎重に、という順序が、無理のない進め方になる。

セゾンテクノロジーの発表が示すように、連携という作業領域にAIが入り始めたのは確かだ。だが、ツールが賢くなるほど、「何をつなぎ、何を正とし、止まったら誰が責任を持つか」という発注側の設計の重要性はむしろ増す。自動化の恩恵を受けるのは、自社の連携を把握し、線引きができている企業だ。

よくある質問（FAQ）

Q1. 連携（インテグレーション）と、システムの機能開発は何が違うのですか？

機能開発は自社のシステムの中で完結しますが、連携は常に「相手のある」開発です。つなぎ先のSaaSやAPIが仕様を変えれば、自社が何もしなくても連携は止まります。そのため、連携は作って終わりにはならず、つなぎ先の変化を追いかける保守が続きます。見積もりでは機能に目が行きがちですが、年間コストで効いてくるのは連携の保守であることが少なくありません。

Q2. AIエージェントで連携を自動化すれば、情シスがいなくても回りますか？

作業の一部は効率化できますが、情シスが不要になるわけではありません。AIは「調べる・下書きする・繰り返す」作業を肩代わりできますが、どのデータを正とするか、例外をどう扱うか、止まったときに誰が責任を持つか、といった判断は人が握り続ける領域です。むしろ自動化が進むほど、この判断を誰かが設計・統制する必要が高まります。

Q3. うちはExcelのコピペで連携している経路が多いのですが、まず何から手をつけるべきですか？

手作業の連携は、ミスと属人化の温床である一方、自動化の効果が最も出やすい候補です。ただし、いきなり自動化する前に、まず連携の棚卸しをおすすめします。どの経路が、どのデータを、どれだけの頻度で流していて、止まると何が困るかを一覧化する。その上で、影響が大きく手作業のものから優先して手を入れると、投資の効果が読みやすくなります。

Q4. 連携を新規で発注するとき、見積もりで一番見落とされるのはどこですか？

「つなぎ先の仕様変更への追随」と「停止時の通知・監視」です。前者を保守に含めずに発注すると、つなぎ先が変わるたびに追加費用が出て、想定した年間コストとずれます。後者を設計に入れないと、静かに壊れた連携に、業務が混乱してから気づくことになります。見積書に「監視」「通知」「追随」の記述がなければ、含まれていない前提で確認してください。

Q5. 「つなぐ本数を減らす」とは具体的にどうすることですか？

各システムを互いに直接つなぐのではなく、真ん中に連携基盤（ハブ）を置いて各システムはハブとだけつなぐ、分析用のデータは一度データ基盤に集約して都度の連携を減らす、接続方式やデータ形式を社内で標準化する、といった上流の設計です。連携は本数が掛け算で増えるため、本数を減らせれば保守は大きく軽くなります。個別の連携を安く作ることより、全体の構え方を設計するほうが、長期のコストに効きます。

まとめ：ツールが賢くなるほど、発注側の「設計」が効く

セゾンテクノロジーがAIエージェントからHULFT Squareのジョブや外部APIを実行できる基盤を提供したことは、これまで人手と属人的な知識で支えてきた連携の領域に、AIが入り始めた合図と言える。連携は、システムが増えるほど掛け算で膨らみ、1本の仕様変更が他を止め、見えないまま保守負債として積み上がる。この負債にツールで手を入れられるのは、前向きな動きだ。

だが、自動化の恩恵を受けるのは、自社の連携を把握し、AIに任せてよい連携と人が設計すべき連携を線引きできている企業だ。何をつなぎ、何を正とし、例外をどう扱い、止まったら誰が責任を持つか——この背骨は、ツールがどれだけ賢くなっても発注側が握り続ける領域である。まずは自社の連携を1枚の表に棚卸しし、手作業と重複を洗い出すところから始めたい。

GXOは、特定の連携ツールを売る立場ではなく、発注する側の視点で、連携の棚卸し、見積もりの読み解き、つなぐ本数を減らす設計、そしてAIに任せる範囲と人が握る範囲の線引きを支援している。連携の現在地を整理したい段階の相談を歓迎する。システム開発やデータ活用基盤構築、AIエージェント導入の入口として、DX成熟度診断で自社の現在地を可視化するところからでも始められる。

参考情報

• セゾンテクノロジー公式「Agent Orchestration」（2026年6月9日。提供開始時期、機能、HULFT Squareとの関係、価格を2026年7月27日に再確認）：https://www.saison-technology.com/en-apac/company/news/20260609_agent_orchestration/
• セゾンテクノロジー公式「HULFT Squareの新機能、リリース情報」（2026年7月1日リリースを確認）：https://www.saison-technology.com/service/product/lineup/hulft-square/release/
• ※ 本記事のうち、連携本数の増加や発注・運用上の判断は、公表機能を踏まえたGXOの実務整理です。製品が既存連携を自動的に作成・修復するとの断定はしていません。

関連記事

• DX/システム開発 TOP
• データ活用基盤構築
• AIエージェント導入
• DX成熟度診断