つなぎ先が決まらないまま、精度の検証だけが進む
AIエージェントの検討は、たいてい出力の精度から始まります。読み取りの正しさ、分類の当たり方、文面の質。ここは短期間で確かめられるため、話が進みやすい部分です。
止まるのはその次です。読み取った内容を既存の販売管理へ入れる、SaaS上の案件情報を書き換える、社内のデータベースを参照して突き合わせる。この段になって、相手のシステムに外からデータを入れる口が無い、認証情報を誰が持つか決まっていない、本番へ書き込む承認を誰が出すのかが決まっていない、といった話が一度に出てきます。
つなぎ方は、精度と違って後から差し替えるのが重くなります。認証の申請、権限の設計、社内の審査が絡むためです。この記事では、つなぐ方式を3つに分けて既存側の改修・止まったときの影響・情報システム部門が持つ手間で並べ、読み取りだけを許す段階と書き込みまで許す段階の切り方を整理します。どこまでを自社で持つかという全体の線引きは 生成AI・AIエージェントの内製化とは で扱っています。
つなぎ方を3つに分ける
方式は数えるほどしかありません。細かい製品名を並べる前に、性質の違いで3つに分けます。
| つなぎ方 | 相手側の改修 | 止まったときに起きること | 情報システム部門が持つ手間 | 向く条件 |
|---|---|---|---|---|
| APIで直接つなぐ | 口があれば不要。無ければ相手側の改修が要る | その場で処理が失敗する。誤った内容もその場で反映される | 認証情報の管理、権限の絞り込み、仕様変更への追随 | 即時に反映したい、件数が多い |
| ファイルの受け渡しや連携基盤を挟む | 既存の出力・取込機能を使えば不要なことが多い | 反映が遅れるだけ。相手のシステムは影響を受けない | 置き場の権限、文字コードや列の変更、二重取り込みの防止 | 日次・月次でまとめて反映してよい |
| 画面の操作を代行する | 不要 | 画面の変更で止まる。途中で止まると中途半端な状態が残る | 実行環境と専用ID、多要素認証、利用規約の確認 | 口が用意されるまでの暫定 |
APIで直接つなぐ
相手のシステムが公開している口を使う形です。反映が即時で、件数が増えても人手が増えません。
確かめる点は3つあります。ひとつは、必要な操作が口として提供されているかどうかです。参照はできても更新はできない、更新はできても添付ファイルは扱えない、という形で範囲が限られていることがあります。ふたつめは、単位時間あたりの呼び出し回数の上限です。締め日に処理が集中する業務では、この上限で止まります。みっつめは、検証用の環境を借りられるかどうかです。本番でしか試せない場合、確認できる時間帯が業務時間外に限られ、実装より待ち時間が長くなります。
自社で開発したシステムに口が無い場合は、そのシステムを改修することになります。ここで見落としやすいのが、改修の費用より改修の待ち行列です。保守ベンダーの対応枠が埋まっていると、連携の実装が始められません。
ファイルの受け渡しや連携基盤を挟む
相手が定型のファイルを出力できる、または取り込めるなら、その機能をそのまま使います。所定の置き場にファイルを出し、AI側がそれを読み、処理した結果を取込用のファイルとして戻す形です。連携基盤（iPaaS）を挟む場合も性質は同じで、間に一段置いて受け渡します。
利点は、相手のシステムを触らずに始められることと、失敗しても相手側に何も起きないことです。処理が落ちても、置き場にファイルが残っているだけなので、直してから流し直せます。
注意する点は、同じファイルを二度読まない形にすることです。処理済みのファイルを別の場所へ移す、あるいは取り込んだファイル名を記録しておく、という単純な仕組みで足ります。これを決めずに始めると、再実行のたびに同じデータが二重に入ります。加えて、相手の出力に列が増減したときに気づける形にしておきます。列の位置で読んでいると、静かにずれた値が入り続けます。
画面の操作を代行する
口もファイルも無い場合の手段です。人が画面で行う操作をそのまま自動化します。相手側の改修が要らないため最短で始められますが、常設の方式としては勧めにくい選択です。
理由は3つあります。画面の変更で止まること、途中で止まったときに登録の途中という状態が残ること、そして多くのSaaSでは利用規約で自動操作の扱いが定められていることです。契約書と規約を確認せずに始めると、後から止めることになります。
使うなら、口が用意されるまでの暫定と位置づけ、いつ見直すかを決めてから始めます。既存の仕組みを作り替える範囲の考え方は 業務システムのAI内製化 で扱っています。
どれから当てるかの順序
3つを比べて選ぶというより、上から順に当てて、取れなかったものが次に落ちる形になります。
順序を守る理由は、下へ行くほど止まりやすく、止まったときの復旧を自社で抱えることになるためです。同じ相手に対して複数の方式を混ぜても構いません。参照はAPIで取り、反映は日次のファイルで戻す、という組み合わせは現実的です。
読み取りだけを許す段階を先に置く
つなぎ方が決まっても、最初から書き込みまで通す必要はありません。許す範囲を段階に分けると、判断が要る場所が減ります。
| 段階 | AIが触る範囲 | 人が行うこと | 次へ進む条件 |
|---|---|---|---|
| 1. 写しを読む | 書き出したデータの複製だけ | 出力を目で確かめる | 出力の傾向が安定し、直す点が挙がりきる |
| 2. 本番を読む | 参照権限のみで本番を読む | 出力を目で確かめる | 参照の範囲と件数が想定どおりに収まる |
| 3. 下書きまで作る | 反映用の内容を作るが反映しない | 内容を確認して自分で反映する | 修正の割合が業務として許せる水準に収まる |
| 4. 条件を絞って書き込む | 決めた項目・件数の範囲で反映する | 承認と、書いた内容の抜き取り確認 | 承認での差し戻しが続けて発生しない |
| 5. 範囲を広げる | 対象の項目や業務を足す | 記録の確認と例外の処理 | ― |
段階1と2を分けているのは、権限の申請と本番への影響を切り離すためです。写しを使う段階では、社内の審査で問われる点が「どのデータをどこへ渡すか」に絞られます。ここで扱う情報の範囲を確定させてから、本番の参照権限を申請すると話が早くなります。外部サービスを使う場合の確認項目は 生成AIサービスのセキュリティ審査をどう通すか で扱っています。
段階3を飛ばさないことも大切です。反映しない下書きを一定期間作り続けると、人がどれだけ直しているかが数として残ります。この修正の割合が、書き込みを許してよいかの材料になります。判断の当たり外れをどう測るかは AIエージェントの精度をどう評価するか が参考になります。
書き込みを許す前に決める6つのこと
段階4へ進むかどうかは、精度だけでは決まりません。書いた後に何が起きるかを決めてあるかどうかで決まります。
| 決めること | 決め方の目安 | 決めないと起きること |
|---|---|---|
| どのIDで書くか | 連携専用のアカウントを作る | 担当者個人のIDで動き、異動で止まり、記録も本人の操作と区別できない |
| 書ける範囲 | 対象の項目と1回あたりの件数に上限を置く | 想定外の対象まで一度に更新される |
| 承認の位置 | 1件ごと・まとめて・事後のどれかを業務ごとに決める | 承認が形だけになるか、承認待ちが滞る |
| 取り消し方 | 上書き前の値を控え、戻す手順を書いておく | 誤りに気づいても元に戻せない |
| 記録の残し方 | 入力・判断の根拠・書いた値・実行時刻を1か所に残す | 問い合わせのたびに原因を追えない |
| 止め方と再実行 | 止める人と手順を決め、二度流しても結果が変わらない形にする | 復旧のつもりの再実行で二重に登録される |
どのIDで書くかは最初に決めます。個人のIDを借りて動かすと、監査で更新者を説明できなくなるうえ、その人の異動や休職で止まります。連携専用のアカウントを作り、必要な権限だけを付けます。
書ける範囲は、項目と件数の両方で絞ります。項目は、更新してよい欄だけに限定します。件数は、1回の実行で更新できる上限を置いておくと、条件の書き間違いで全件が書き換わる事故を止められます。
承認の位置は、業務の性質で分かれます。次の節で扱います。
取り消し方は、書き込みを許す前に手順として書いておきます。上書き前の値を控えておけば、戻す作業は単純になります。相手のシステムに更新履歴が残る場合でも、まとめて戻す手段が無いことがあるため、自分側にも控えを持ちます。
記録の残し方は、どの入力から、どんな判断で、どの値を書いたかが1件ずつ辿れる形にします。相手のシステム側のログと突き合わせられるよう、双方に同じ識別子を残しておくと調査が早くなります。
止め方と再実行は、運用に入ってから効いてきます。同じ処理を二度流しても結果が変わらない形にしておくと、止めた後の再開が単純な作業になります。この形にしていないと、復旧のたびに人が重複を消すことになります。
承認をどこに置くかは、取り消せるかで決まる
承認を1件ごとに置くと安全ですが、件数が多い業務では人の手が空きません。判断の軸は2つで足ります。あとから取り消せるかと、社外の相手に届くかです。
社内の管理情報を更新するだけで、誤りに気づけば戻せるものは、まとめて承認するか、事後に抜き取りで確認する形で回せます。一方、社外へ送る文面、取引先へ通知される数値、支払や契約の確定に関わる更新は、件数が少なくても1件ごとに人が確定させます。ここを件数の都合で緩めると、戻せない誤りが外に出ます。
事後の確認にする場合は、全件を見るのではなく、条件を決めて抜き出します。金額が一定を超えたもの、AIの判断が例外に当たったもの、過去に修正が多かった相手のもの、という3つの条件を置くと、確認の件数は業務量に比例しなくなります。
止まったときに気づける形にする
連携は、動かなくなったことより、静かに間違い続けることが問題になります。次の3つは、書き込みを許す前に入れておきます。
- 件数の見張り … 1日の処理件数が普段の範囲から外れたら知らせる。0件になったときも知らせる（口が止まった場合、処理は成功したまま件数だけが消えます）
- 失敗の通知 … 相手の応答が返らない、認証が切れた、といった失敗を業務の担当者が見る場所へ流す。ログの中だけに残すと気づかれません
- 未処理の滞留 … 承認待ちのまま何日も残っている件を一覧で出す。承認を挟む設計では、ここが最初に詰まります
通知先は、情報システム部門と業務の担当者の両方に置きます。認証の期限切れのように情報システム部門しか直せないものと、承認の滞留のように業務側しか動かせないものが混ざるためです。誰が直すかの分担は 内製したAIエージェントの運用・保守 で扱っています。
どこまでを内製で持つか
連携部分は、外注しても自社に残るものが多い領域です。線を引く目安は次のようになります。
自社で持つのは、どの項目にどんな値を書くかという仕様、認証情報の管理、止まったときの一次対応です。この3つを外に預けると、仕様変更のたびに依頼が要り、止まった日に自社で何もできません。とくに認証情報は、外部に預けたまま契約が終わると、権限の棚卸しができなくなります。
外に出しやすいのは、最初の実装と、慣れていない口の調査です。相手のシステムの仕様書を読み解く作業や、認証方式の実装は、経験のある側が行うほうが早く終わります。ただし、書いたコードと設定を自社の管理下に置く形にしておきます。引き継ぎの範囲は 外注していたAI開発を内製へ切り替える にまとめています。
着手の順序
つなぐ相手が複数あるときは、まとめて設計せず、1つに絞って通します。選ぶ目安は、口が用意されていること、扱う情報が社外に出ないこと、間違えても確定の前に気づけることの3つです。
1本目で通すのは、読み取りから下書きまでです。ここまでで、相手の仕様の癖、認証の申請にかかる日数、社内の審査で問われる点が分かります。この3つは相手が変わっても共通するため、2本目からの見積もりが立てやすくなります。
書き込みへ進むのは、下書きの段階で人が直した記録が溜まってからです。どの項目に修正が集中するかが分かってから範囲を決めると、承認の置き方も件数の上限も根拠を持って決められます。連携の仕様を文書として残す形は AIエージェントの要件定義の書き方 が参考になります。
まとめ：基幹システム・SaaSとの連携を決めるときの要点
- つなぎ方は、APIで直接つなぐ形、ファイルの受け渡しや連携基盤を挟む形、画面の操作を代行する形の3つ。相手側の改修、止まったときの影響、情報システム部門の手間で並べて選ぶ
- 上から順に当て、取れないものが下に落ちる形にする。画面操作の代行は口ができるまでの暫定と位置づけ、見直す時期を決めてから始める
- APIでは、必要な操作が口として提供されているか、呼び出し回数の上限、検証環境を借りられるかの3点を先に確かめる
- ファイル経由では、同じファイルを二度読まない形と、列の増減に気づける形を最初に入れる
- 許す範囲は段階に分ける。写しを読む、本番を読む、下書きまで作る、条件を絞って書き込む、範囲を広げるの順に進める
- 書き込みを許す前に、どのIDで書くか、書ける範囲、承認の位置、取り消し方、記録の残し方、止め方と再実行の6つを決めておく
- 承認の位置は、取り消せるかと社外に届くかで決める。戻せない更新と社外に出る内容は、まとめずに人が1件ごとに確定させる
- 件数の見張り・失敗の通知・承認待ちの滞留を、情報システム部門と業務の担当者の両方が見える場所へ出す
- 仕様、認証情報の管理、止まったときの一次対応は自社に残す。最初の実装や口の調査は外に出しやすい
Augueでは、既存の基幹システムやSaaSとの連携を含めたAIエージェントの設計・実装と、社内で運用と改修を続けられる体制づくりを支援しています。どの方式から着手するか、どこまでを自社で持つかを整理したい方は、是非ご相談ください。
関連する記事
内製化の全体像と層ごとの線引きは 生成AI・AIエージェントの内製化とは、既存のExcel運用を含めた作り替えの範囲は 業務システムのAI内製化 を参照してください。
自作と既製ツールの分かれ目は AIエージェントは既製ツールか自作か、反映まで含めた業務の組み方の例は 請求書処理の自動化をAIで進める、運用に入った後の分担は 内製したAIエージェントの運用・保守 で扱っています。
よくある質問
連携部分の実装にはどれくらいの期間を見ればよいですか？
相手のシステムによって差が大きいため一律には出せません。見積もりの前に、口の有無（公式の連携機能があるか）、認証の申請に社内で何日かかるか、検証用の環境を借りられるかの3点を確かめると、期間のばらつきの大半が説明できます。特に検証環境が無く本番でしか試せない場合は、確認できる時間帯が限られるため、実装そのものより待ち時間が長くなります。
相手のSaaSにAPIが無い場合、契約プランを上げるべきですか？
上げる前に、その連携で何件・どの頻度の処理を行うかを数えます。月に数十件で、担当者が数分で終わる転記なら、上位プランの差額のほうが大きくなることがあります。件数が多い、あるいは締め日に集中して残業が発生しているなら、プラン変更は検討に値します。判断の材料は件数と処理にかかる時間で、機能の有無だけで決めないほうが妥当です。
監査や内部統制の観点では何を求められますか？
一般には、誰の権限でその更新が行われたか、いつ何を変えたか、承認の記録が残っているかを説明できることが求められます。担当者個人のIDで動かしていると、本人が操作していない更新が本人名義で並ぶため、説明が難しくなります。連携専用のアカウントを用意し、その操作であると分かる形にしておくと、記録の説明が単純になります。
既存のRPAで作った連携は作り直したほうがよいですか？
動いているものを止める必要はありません。決まった画面を決まった順に操作する処理は、そのまま使えます。作り直しを検討する対象は、書式や文面のばらつきを条件分岐で吸収しようとして分岐が増えた部分です。その判断部分だけをAI側へ寄せ、確定後の反映は既存の仕組みに任せると、置き換える範囲が小さく済みます。