AIエージェント連携の3方式｜API・ファイル・画面操作と書き込み前の6項目

AIエージェント連携は、基幹システムやSaaSに公式のAPIがあればAPIで直接つなぎ、無ければ定型ファイルの受け渡しか連携基盤を挟み、どちらも無いときだけ画面操作の代行を暫定で使う、という順で方式を決めます。3つの方式は、相手側の改修が要るか、止まったときに何が起きるか、情報システム部門がどんな手間を持つかで違います。方式を決めたら、読み取りから始めて下書き、書き込みへと許す範囲を段階的に広げ、書き込みの前に承認や更新履歴の残し方など6項目を決めておきます。

この記事の答え

• AIエージェント連携は、APIで直接つなぐ・ファイルや連携基盤を挟む・画面操作を代行する、の3方式を上から順に当てて決める
• 書き込みまで許すかどうかは、精度ではなく、書いた後の取り消し方・承認・記録を決めてあるかで判断する
• つなぐ相手を1つに絞り、まず読み取りから下書きまでを通して、認証の申請や社内審査にかかる日数をつかむ

AIエージェント連携が、精度の確認の後で止まる理由

AIエージェントの検討は、たいてい出力の精度から始まります。読み取りの正しさ、分類の当たり方、文面の質は短期間で確かめられるため、話が進みやすい部分です。

止まるのは、AIエージェントと基幹システムの連携に進む段階です。読み取った内容を既存の販売管理へ入れる、SaaS上の案件情報を書き換える、社内のデータベースを参照して突き合わせる。この段になって、相手のシステムに外からデータを入れる口が無い、認証情報を誰が持つか決まっていない、本番へ書き込む承認を誰が出すのかが決まっていない、といった話が一度に出てきます。

つなぎ方は、精度と違って後から差し替えるのが重くなります。認証の申請、権限の設計、社内の審査が絡むためです。そのため、精度の確認と並行して、どの方式でつなぎ、どこまで書き込みを許すかを先に決めておきます。

関連記事：生成AIの内製化とは｜メリット・デメリットと始め方、外注に残す範囲

AIエージェント連携のつなぎ方を3つに分ける

AIエージェントとSaaSの連携、基幹システムとの連携のどちらも、方式は細かい製品名を並べる前に、性質の違いで3つに分けられます。方式ごとの向き不向きは次のとおりです。

APIでつなぐ前に確かめる3点

APIで直接つなぐ形は、反映がすぐで、件数が増えても人手が増えません。ただし、口があるというだけで決めると後で止まります。着手の前に次の3点を確かめます。

1. 必要な操作が口として提供されているか。参照はできても更新はできない、更新はできても添付ファイルは扱えない、という形で範囲が限られていることがあります。
2. 単位時間あたりの呼び出し回数の上限。締め日に処理が集中する業務では、この上限で止まります。
3. 検証用の環境を借りられるか。本番でしか試せない場合、確認できる時間帯が業務時間外に限られ、実装より待ち時間が長くなります。

自社で開発したシステムに口が無い場合は、そのシステムを改修することになります。見落としやすいのは、改修の費用より、保守ベンダーの対応枠が空くまでの待ち時間です。対応枠が埋まっていると、連携の実装が始められません。

MCPに対応したSaaSとつなぐ場合

MCP（Model Context Protocol）とは、AIを使うアプリと外部のデータやツールをつなぐための公開された共通の取り決めです。仕様では、メッセージをJSON-RPC 2.0の形式でやり取りし、つながれる側（サーバー）が、参照用のデータ、定型の指示、AIが実行できる機能（ツール）を提供する形が定められています。相手のSaaSがMCPに対応していれば、AIエージェントごとに個別の接続部分を作らずに済む場合があります。

MCPでつないでも、書き込みまで許す範囲を決める作業は残ります。仕様は、ツールを任意の処理を実行できるものとして慎重に扱うこと、ツールを呼び出す前に利用者の明示的な同意を得ることを求めています。一方で、この原則を仕組みとして強制することはできず、同意や権限の確認は、つなぐ側の実装に任されているとしています。後の節で扱う承認や記録の決め方は、MCPを使う場合も同じように必要です。

関連記事：n8nでAIエージェントを作る手順｜MCP・RAGのつなぎ方

ファイルや連携基盤を挟むときの注意点

相手が定型のファイルを出力できる、または取り込めるなら、その機能をそのまま使います。所定の置き場にファイルを出し、AI側がそれを読み、処理した結果を取込用のファイルとして戻す形です。連携基盤（iPaaS）を挟む場合も性質は同じで、間に一段置いて受け渡します。処理が落ちても置き場にファイルが残っているだけなので、直してから流し直せます。

最初に入れるのは、同じファイルを二度読まない仕組みです。処理済みのファイルを別の場所へ移す、あるいは取り込んだファイル名を記録しておく、という単純な仕組みで足ります。これを決めずに始めると、再実行のたびに同じデータが二重に入ります。加えて、相手の出力で列が増えたり減ったりしたときに気づける形にしておきます。列の位置で読んでいると、ずれた値が気づかれないまま入り続けます。

画面操作の代行を使うときの条件

画面操作の代行は、人が画面で行う操作をそのまま自動化する方法です。相手側の改修が要らないため最短で始められますが、常に使い続ける方式としては勧めにくい選択です。

多くのSaaSでは、利用規約で自動操作の扱いが定められています。契約書と規約を確認せずに始めると、後から止めることになります。使うなら、APIやファイルの口が用意されるまでのつなぎと位置づけ、いつ見直すかを決めてから始めます。既存のRPAで動いている処理がある場合は、作り替える範囲を小さく保つほうが進めやすくなります。

関連記事：業務システムの内製化｜AIに置き換える業務と残すシステムの線引き

基幹システム・SaaSとの連携方式を選ぶ順序

上から順に当てて方式を決める

3つを並べて比べるより、上から順に当てて、取れなかったものだけ次へ落とす形にすると迷いません。順に当てるのは、下の方式ほど止まりやすく、止まったときの復旧を自社で抱えることになるためです。

参照と反映で方式を分けてもよい

同じ相手に対して、複数の方式を混ぜても構いません。たとえば、参照はAPIで取り、反映は日次のファイルで戻す、という組み合わせは現実的です。更新の口だけが用意されていない相手でも、読み取りはAPIで始められます。

読み取りだけを許す段階を先に置く

つなぎ方が決まっても、最初から書き込みまで通す必要はありません。許す範囲を段階に分けると、判断が要る場所が減ります。

写しと本番の読み取りを分ける理由

段階1と2を分けているのは、権限の申請と本番への影響を切り離すためです。写しを使う段階では、社内の審査で問われる点が「どのデータをどこへ渡すか」に絞られます。ここで扱う情報の範囲を確定させてから本番の参照権限を申請すると、審査が早く進みます。

関連記事：生成AIのセキュリティ審査｜情シスが確認する12項目と申請・稟議の書き方

下書きの段階を飛ばさない

反映しない下書きを一定期間作り続けると、人がどれだけ直しているかが数として残ります。この修正の割合が、書き込みを許してよいかを決める材料になります。下書きの段階を飛ばすと、書き込みを許す根拠が「試したら合っていた」という印象だけになります。

関連記事：AIエージェントの精度をどう評価するか｜合格ラインの決め方と、本番に出す前の確認手順

書き込みまで許す前に決める6項目

書き込みを許すかどうかは精度だけでは決まらず、書いた後に何が起きるかを決めてあるかで決まります。段階4へ進む前に、次の6項目を決めます。

連携専用のIDは最初に用意する

個人のIDを借りて動かすと、本人が操作していない更新が本人名義で並びます。監査で更新者を説明できなくなるうえ、その人の異動や休職で連携が止まります。IDの申請は社内の手続きに日数がかかることが多いため、6項目の中で最初に着手します。

相手のシステムの履歴だけに頼らない

相手のシステムに更新履歴が残る場合でも、まとめて元に戻す手段が無いことがあります。取り消しのための控えと記録は、AIエージェントの側にも持たせます。相手のシステムのログと突き合わせられるよう、双方に同じ識別子を残しておくと、問い合わせへの調査が早くなります。

再実行しても二重にならない形にする

止め方と再実行は、運用に入ってから効いてきます。同じ処理を二度流しても結果が変わらない形にしておくと、止めた後の再開が単純な作業になります。この形にしていないと、復旧のたびに人が重複を探して消すことになります。

承認をどこに置くかは、取り消せるかで決まる

承認を1件ごとに置くと安全ですが、件数が多い業務では人の手が空きません。判断の軸は、あとから取り消せるかと、社外の相手に届くかの2つで足ります。

1件ごとに人が確定させる更新

社外へ送る文面、取引先へ通知される数値、支払や契約の確定に関わる更新が当たります。戻せない更新と社外に出る内容は、件数が少なくても1件ごとに人が確定させます。ここを件数の都合で緩めると、戻せない誤りが外に出ます。

まとめて承認・事後確認で回せる更新

社内の管理情報を更新するだけで、誤りに気づけば戻せるものは、まとめて承認するか、事後に抜き取りで確かめる形で回せます。事後の確認は全件を見ず、条件を決めて抜き出します。金額が一定を超えたもの、AIの判断が例外に当たったもの、過去に修正が多かった取引先のもの、という3つの条件を置くと、確認の件数は業務量に比例して増えなくなります。

止まったときに気づける形にする

連携は、動かなくなることより、気づかれないまま間違い続けることが問題になります。書き込みを許す前に、次の3つを入れておきます。

• 件数の見張り1日の処理件数が普段の範囲から外れたら知らせます。口が止まると、処理は成功したまま件数だけが0件になるため、0件のときも知らせます。
• 失敗の通知相手の応答が返らない、認証が切れた、といった失敗を業務の担当者が見る場所へ流します。ログの中だけに残すと気づかれません。
• 承認待ちの滞留承認待ちのまま何日も残っている件を一覧で出します。承認を挟む設計では、ここが最初に詰まります。

通知先は、情報システム部門と業務の担当者の両方に置きます。認証の期限切れのように情報システム部門しか直せないものと、承認の滞留のように業務側しか動かせないものが混ざるためです。

関連記事：内製したAIエージェントの運用・保守｜壊れたときに誰が直すかと、外部支援を外すタイミング

AIエージェント連携のどこまでを内製で持つか

連携部分は、外注しても自社に残るものが多い領域です。線を引く目安は次のようになります。

自社で持つもの

どの項目にどんな値を書くかという仕様、認証情報の管理、止まったときの最初の対応の3つです。この3つを外に預けると、仕様変更のたびに依頼が要り、止まった日に自社で何もできません。とくに認証情報は、外部に預けたまま契約が終わると、誰がどの権限を持っているかを確かめられなくなります。

外に出しやすいもの

最初の実装と、慣れていない口の調査です。相手のシステムの仕様書を読み解く作業や、認証方式の実装は、経験のある側が行うほうが早く終わります。ただし、書いたコードと設定は自社の管理下に置く形にしておきます。

関連記事：外注していたAI開発を内製へ切り替える｜引き継ぐものの一覧と、止めずに移す順序

着手の順序

つなぐ相手が複数あるときは、まとめて設計せず、1つに絞って通します。進め方は次のとおりです。

1. つなぐ相手を1つ選ぶ口が用意されていること、扱う情報が社外に出ないこと、間違えても確定の前に気づけることの3つを満たす相手を選びます。
2. 読み取りから下書きまでを通す相手の仕様の癖、認証の申請にかかる日数、社内の審査で問われる点が分かります。この3つは相手が変わっても共通するため、2本目からの見積もりが立てやすくなります。
3. 人が直した記録が溜まってから書き込みへ進むどの項目に修正が集中するかが分かってから範囲を決めると、承認の置き方も件数の上限も根拠を持って決められます。

関連記事：【テンプレート付き】AIエージェント要件定義の書き方｜8項目のNG例・OK例

まとめ：AIエージェント連携の3方式と、書き込みまで許す前に決めること

• AIエージェント連携の方式は、APIで直接つなぐ・ファイルや連携基盤を挟む・画面操作を代行する、の3つ。上から順に当て、取れなかったものだけ次へ落とす
• APIでは、必要な操作が提供されているか、呼び出し回数の上限、検証環境を借りられるかを先に確かめる。MCPでつなぐ場合も、承認と権限の決め方は自分たちで用意する
• ファイル経由では、同じファイルを二度読まない仕組みと、列の増減に気づける形を最初に入れる
• 画面操作の代行は、口ができるまでのつなぎと位置づけ、利用規約を確かめ、見直す時期を決めてから始める
• 許す範囲は、写しを読む、本番を読む、下書きまで作る、条件を絞って書き込む、範囲を広げるの順に広げる
• 書き込みの前に、IDの持ち方、書ける範囲、承認の位置、取り消し方、記録の残し方、止め方と再実行の6項目を決める
• 戻せない更新と社外に出る内容は、まとめずに人が1件ごとに確定させる
• 仕様、認証情報の管理、止まったときの最初の対応は自社に残し、最初の実装や口の調査は外に出してよい

Augueでは、既存の基幹システムやSaaSとの連携を含めたAIエージェントの設計・実装と、社内で運用と改修を続けられる体制づくりを支援しています。どの方式から着手するか、どこまでを自社で持つかを整理したいなど、ご興味がある方は是非ご相談ください。

社内でAIを使いこなせる人を育てませんか？

研修だけで終わらせず、現場の業務で使い続けられる体制づくりまで伴走します。研修の内容と進め方は、サービス資料で紹介しています。

資料をダウンロードする無料相談に申し込む

よくある質問

連携部分の実装にはどれくらいの期間を見ればよいですか？

相手のシステムによって差が大きいため一律には出せません。見積もりの前に、口の有無（公式の連携機能があるか）、認証の申請に社内で何日かかるか、検証用の環境を借りられるかの3点を確かめると、期間のばらつきの大半が説明できます。特に検証環境が無く本番でしか試せない場合は、確認できる時間帯が限られるため、実装そのものより待ち時間が長くなります。

相手のSaaSにAPIが無い場合、契約プランを上げるべきですか？

上げる前に、その連携で何件・どの頻度の処理を行うかを数えます。月に数十件で、担当者が数分で終わる転記なら、上位プランの差額のほうが大きくなることがあります。件数が多い、あるいは締め日に集中して残業が発生しているなら、プラン変更は検討に値します。判断の材料は件数と処理にかかる時間で、機能の有無だけで決めないほうが妥当です。

監査や内部統制の観点では何を求められますか？

一般には、誰の権限でその更新が行われたか、いつ何を変えたか、承認の記録が残っているかを説明できることが求められます。担当者個人のIDで動かしていると、本人が操作していない更新が本人名義で並ぶため、説明が難しくなります。連携専用のアカウントを用意し、その操作であると分かる形にしておくと、記録の説明が単純になります。

既存のRPAで作った連携は作り直したほうがよいですか？

動いているものを止める必要はありません。決まった画面を決まった順に操作する処理は、そのまま使えます。作り直しを検討する対象は、書式や文面のばらつきを条件分岐で吸収しようとして分岐が増えた部分です。その判断部分だけをAI側へ寄せ、確定後の反映は既存の仕組みに任せると、置き換える範囲が小さく済みます。

関連する記事

生成AIの内製化とは｜メリット・デメリットと始め方、外注に残す範囲生成AIの内製化とは、対象の選定から業務が変わったときの修正までを社内の判断で回せる状態です。メリット・デメリットと何から始めるかを先に答え、層ごとに外注へ残す範囲と、併走を終える判断を表で整理しました。業務システムの内製化｜AIに置き換える業務と残すシステムの線引きExcelとメールで回す業務のうち、AIに置き換えるものと既存システムに残すものの分け方を、業務システムの内製化の4分類で示します。入口・判断・出口の切り方、既存システムとのつなぎ方、AIへ渡すデータの範囲まで扱います。AIエージェントは既製ツールか自作か｜選び分けと、途中で切り替える見極め既製ツールで始めるか自作かを、費用・運用の手間・社内に残るものの3点で比べます。例外が設定に落ちない、処理の途中で社内システムにつなぐ、権限と記録の要件が厳しい、の3つが出たら自作へ切り替える見極め方も示します。請求書処理の自動化｜AIに任せる工程と人が承認を残す箇所請求書処理の自動化を6工程に分け、AIに任せられる工程と人が承認を残す工程を先に示します。発行元ごとに違う書式の受け止め方、検算と突合、会計システムへの渡し方、月次締めまでの段取りも整理します。内製したAIエージェントの運用・保守｜壊れたときに誰が直すかと、外部支援を外すタイミング内製したAIに起きる不具合を、指示の調整で済むもの、接続先の仕様変更、権限の問題に分けて一次対応者を決める方法から、月次点検の項目、精度低下への気づき方、外部支援を外す目安までを整理します。n8nとは？n8nの使い方・読み方・できること・無料の範囲を解説n8nとは、ノードをつないで業務を自動化するツールです。n8nの使い方を、登録から公開までの手順と式・テンプレート・Webhookの扱いで解説し、読み方や無料の範囲、日本語での扱いもまとめます。