2026.10.03 DX

ワークフローシステム連携の方式と設計：API・CSV・DB直結・iPaaSの選び分け

ワークフローシステムで承認まで電子化しても、承認後のデータを会計や人事のシステムへ手で打ち直していれば、転記の手間とミスは残ります。連携の方式はAPI・CSVファイル・データベース直結・iPaaSの4つに分かれ、選び分けの判断基準は申請件数、反映までに許される時間、連携先が公開している仕様です。この記事では、4方式の違いと選び分けの基準、会計・人事給与・kintone・Teams通知といった連携先別の設計、組織改編で承認経路を壊さないマスタ同期の方法を整理します。最後に、製品の標準連携で足りない場合に受託開発へ出す範囲と、見積りで確かめる観点を示します。

まとめ：ワークフローシステム連携は方式より件数・即時性・正のデータで決める

連携方式の結論は単純です。承認済みデータを1日に数十件、翌朝までに会計へ渡せばよいならCSVファイル連携で十分です。承認と同時に別システムへ起票したい、または通知を飛ばしたい場合はAPIとWebhookを組み合わせます。データベース直結は、両システムが自社内にあり同じ管理者が両方を保守できる場合を除いて採りません。

設計で先に決めるのは方式ではなく「どのシステムのデータを正とするか」です。組織と役職は人事システム、勘定科目と取引先は会計システムを正とし、ワークフロー側は参照に回すと二重管理が起きません。標準コネクタやiPaaSで組めない連携、たとえば承認取消に合わせた逆仕訳や、失敗時の再送と監視まで求める連携は、受託開発の対象になります。

ワークフローシステム連携の4方式：API・CSVファイル・DB直結・iPaaSの違い

4方式は「データをどちら向きに、どの頻度で渡すか」で整理すると違いがはっきりします。ワークフローシステムそのものの機能や選び方はワークフローシステムの機能と選び方の解説にまとめているので、ここでは連携の部分だけを掘り下げます。

承認済みデータを渡す方向と即時性で整理する連携4方式の比較表

同じ「連携」でも、仕組みと保守の担い手は方式ごとに大きく異なります。主な違いを表にまとめます。

方式	反映の速さ	向く件数	主な失敗要因	保守の担い手
CSVファイル連携	日次・手動取込	1日数十〜数百件	取込漏れ・二重取込	情報システム担当
API連携	数秒〜数分	件数を問わない	上限超過・認証切れ	開発者
DB直結	即時	大量	製品更新で表構造が変わる	両製品を知る技術者
iPaaS	即時〜定期実行	少量〜中量	実行回数課金の膨張	業務部門でも可

表の「反映の速さ」は製品と設定によって変わるため目安として読んでください。読み取ってほしいのは、方式が下に行くほど速さと引き換えに保守の前提が重くなる点です。

CSVファイル連携が今も基幹連携で選ばれる理由と二重取込の防ぎ方

会計ソフトや給与ソフトの多くは、仕訳や支給データのCSV取込画面を標準で備えています。ワークフロー側で承認済み申請をCSVに書き出し、経理担当が翌朝に取り込む運用なら、個別の開発をせずに開始することが可能です。月末に締める経費精算のように、承認から計上まで1日の遅れが業務上問題にならない処理には、この方式で足ります。

弱点は、人が取り込む工程に二重取込と取込漏れが入り込むことです。対策は2つあります。出力済みの申請に「連携済み」の印を付け、次回の出力から外す設定にすること。取込側では申請番号を摘要や外部キーの列に入れ、同じ番号が2回入ったら検知できるようにすることです。この2点を設定できない製品の組み合わせなら、CSVではなくAPIを検討します。

API連携とWebhookの役割分担：起票はAPI・承認完了の知らせはWebhook

APIは、こちらから相手のシステムへ「このデータを登録して」と要求を送る仕組みです。Webhookはその逆で、承認完了のような出来事が起きた瞬間に、相手が用意したURLへシステムの側から知らせを送ります。両者は対立する選択肢ではありません。承認完了をWebhookで受け、受けた処理がAPIで会計システムへ起票する、という組み合わせが標準形です。

この形をとると、定期的に「新しい承認はあるか」と問い合わせる処理が要らなくなり、無駄なリクエストが減ります。注意点は、Webhookの受け口が一時的に落ちていると知らせを取りこぼすことです。取りこぼしを拾うために、1日1回だけ承認済み一覧をAPIで取得して突き合わせる処理を併せて置きます。APIの基本的な仕組みはAPI連携の仕組みとデータ連携との違いで詳しく扱っています。

連携方式を選ぶ判断基準：申請件数・即時性・連携先の仕様で決める選び分け

方式の候補が出そろったら、次の3つの条件で絞り込みます。件数とAPIの上限、データベースに直接触れてよいか、iPaaSで組める範囲かどうかです。

1日の申請件数と連携先APIの上限値から逆算する一括処理と即時処理

API連携を選んでも、連携先には1日あたりのリクエスト数や1回で扱える件数の上限があります。kintoneの例では、サイボウズ公式のAPIリクエスト数の解説（2026年1月時点）によると、1日のリクエスト数は日本時間の毎朝9時に数え直され、複数レコードの登録は1回100件まで、取得は500件までです。

この上限から設計を逆算します。承認1件ごとに1回登録する即時処理は、月末に申請が集中しても1日数百件程度までなら上限内に収まりやすい構成です。逆に、毎月1日に数千件の勤怠承認をまとめて流す処理は、100件ずつの一括登録に切り替えないとリクエスト数が膨らみます。即時性が要らないデータは一括処理に寄せる、これが上限で詰まらないための原則です。

DB直結を選んでよいのはオンプレ同士で同じ管理者が保守する場合だけ

ワークフローシステムのデータベースへ直接SQLを発行する方式は、仕組みとしては最も速く、APIの上限にも縛られません。それでも、クラウド型の製品ではそもそもデータベースへの接続が許されていないことがほとんどです。オンプレミス型で接続できる場合でも、表の構造は製品の内部仕様であり、バージョンアップで列名や型が予告なく変わります。

採用してよい条件ははっきりしています。両方のシステムが自社内にあり、製品更新の前に連携部分を試験する体制を同じ管理者が持っていること。この条件を満たさないなら、直結は選びません。更新のたびに連携が止まり、原因を知る人が社内にいない状態が最も高くつくからです。参照だけが目的なら、製品が用意する参照用ビューやデータ出力機能を使います。

iPaaSで足りる連携の範囲と実行回数の課金が割に合わなくなる条件

iPaaSは、ワークフロー製品と会計・チャット・ストレージなどのクラウドサービスを画面上の設定でつなぐサービスです。承認完了をきっかけに、PDFをストレージへ保存し、チャットへ投稿し、表計算に1行足す、といった数段の処理なら、開発なしで組めます。業務部門の担当者が自分で直せる点も強みです。

割に合わなくなるのは2つの場合です。料金が処理の実行回数で決まる製品が多く、申請件数が増えると月額が件数に比例して膨らむこと。そして、失敗時の再送や、条件によって分岐する複雑な変換を設定画面だけで組むと、保守できる人が限られることです。件数が月数千件を超える、または変換ロジックが10以上の条件分岐を持つ連携は、iPaaSから個別開発への切り替えを比べる段階です。料金の数え方はiPaaSの仕組みと料金の数え方で整理しています。

連携先別の設計ポイント：会計・人事給与・ERP・kintone・Teams通知の注意点

方式が決まっても、連携先ごとに決めておかないと後で揉める項目があります。経理と人事の両方に関わる会計連携から順に見ていきます。

会計システム連携で先に決める仕訳の粒度・勘定科目の対応・計上日

経費精算や支払申請を会計システムへ渡すとき、技術より先に経理と合意すべき項目が3つあります。1つ目は仕訳の粒度で、申請1件を1仕訳にするか、取引先や部門ごとに月次で集約するかです。2つ目は、申請画面の費目と会計側の勘定科目・補助科目・税区分の対応表です。3つ目は計上日で、申請日・承認日・支払日のどれを使うかによって月をまたぐ申請の扱いが変わります。

対応表はワークフロー側で持たず、会計システムの科目マスタを正として定期的に取り込むのが安全です。経理が科目を新設したのにワークフロー側が古い一覧のままだと、承認は通るのに取込でエラーになります。ERPと連携する場合も同じで、取引先コードや部門コードの参照元はERP側のマスタです。経費申請自体をどちらのシステムで回すかは経費精算システムとワークフローシステムの使い分けが判断の材料になります。

kintone連携のREST APIリクエスト例とレコード登録に要る権限の設定

承認済み申請をkintoneのアプリへ登録する処理は、kintone REST APIのレコード登録の仕様どおりに組むと次のようになります。APIトークンはアプリの設定画面で発行し、ヘッダーに入れて送ります。フィールドコードは連携先アプリの設定に合わせて読み替えてください。

curl -X POST "https://example.cybozu.com/k/v1/record.json" \
  -H "X-Cybozu-API-Token: 発行したAPIトークン" \
  -H "Content-Type: application/json" \
  -d '{
    "app": 123,
    "record": {
      "申請番号": { "value": "WF-2026-001234" },
      "申請者コード": { "value": "E10025" },
      "金額": { "value": "48000" },
      "承認日": { "value": "2026-10-01" }
    }
  }'

# 成功時の応答（登録されたレコードの番号とリビジョン）
{ "id": "100", "revision": "1" }

権限で詰まる箇所は決まっています。APIトークンにはレコード追加の権限が必要で、値を入れる各フィールドに編集権限がないと登録できません。作成者や作成日時のフィールドを書き込みたい場合は、アプリ管理の権限まで必要です。申請番号は重複禁止のフィールドにしておくと、再送時の二重登録をkintone側で止められます。4方式の判定とAPI制限の設計はkintoneのデータ連携を実装視点で選ぶ解説で詳しく扱っています。

Teams・Slackへの承認依頼通知と2026年5月のコネクタ停止の影響

承認依頼をチャットへ流す連携は、効果が見えやすい割に、Teams側の仕組みが2026年に変わった点に注意が要ります。Microsoftの告知によると、TeamsのOffice 365コネクタは2026年5月18日から22日にかけて段階的に無効化されました。旧コネクタのWebhook URLへ送る実装は、すでに届きません。

移行先はTeamsのWorkflowsアプリで、受信Webhookの公式ドキュメントには、メッセージの上限が28KB、毎秒4回を超える要求は調整されると書かれています。見落としやすいのは、ワークフローがチャネルではなく作成した個人に紐づく点です。作成者が退職すると通知が止まるため、共同所有者を必ず追加します。Slack側の実装手順はSlack Incoming Webhookの実装手順を参照してください。

マスタ同期と組織改編：承認経路を壊さない人事・組織データの連携設計

ワークフロー連携で最も障害が起きやすいのは、会計への出力ではなく、承認経路の元になる組織と人のデータです。

人事システムを正とする組織・役職マスタの同期方式とSCIMの使いどころ

承認経路は「申請者の所属部署の課長、金額が50万円を超えたら部長」のように組織と役職で組まれます。この組織・役職・所属の情報をワークフロー側で手入力していると、人事異動のたびに更新漏れが出て、退職者に承認依頼が届きます。人事システムやIDの管理基盤を正とし、ワークフロー側へ自動で流す設計が基本です。

流し方の標準がSCIMです。Microsoft EntraのSCIMの解説では、SCIM 2.0はRFC 7642・7643・7644で定義され、ユーザーとグループのエンドポイントで作成・更新・削除を行うと説明されています。ワークフロー製品がSCIMの受け口を持っていれば、入社・異動・退職を開発なしで反映できます。ただし兼務や承認権限の金額上限のような項目は標準の属性に収まらないことが多く、そこを補う手段は拡張属性か別の連携です。仕組みの詳細はSCIMによるID自動プロビジョニングの解説にあります。

4月の組織改編で承認途中の申請が止まる失敗パターンと切替の手順

典型的な失敗は、4月1日に新組織のマスタを流し込んだ瞬間、3月中に起票されて承認途中だった申請の次の承認者が「存在しない部署の課長」になり、誰の画面にも出なくなることです。月末の支払申請が止まれば、支払遅延に直結します。

防ぐ手順は次の順で組みます。

改編の2週間前に、新組織のマスタを適用開始日つきで登録しておく
改編日の前日に、承認途中の申請を一覧で出し、旧組織の承認者で完了させるか差し戻すかを決める
改編日の朝に同期を実行し、主要な申請書で経路のテスト申請を1件ずつ通す
止まった申請を拾うため、改編後1週間は管理者が滞留一覧を毎日確認する

適用開始日をマスタに持てない製品では、手順1が組めず、改編日の夜間に一斉に切り替えるしかありません。組織改編が年2回以上ある会社は、この機能の有無を製品選定の条件に入れておくべきです。

標準連携で足りない場合の受託開発：開発範囲と見積りで確認したい観点

製品の標準コネクタとiPaaSで組めない部分だけを開発に出すと、費用と保守の両方を抑えられます。

標準コネクタ・iPaaS・個別開発の3択で受託開発に出すべき連携の条件

判断の順序は、まず製品の標準コネクタ、次にiPaaS、最後に個別開発です。個別開発に出すのは、次のいずれかに当てはまる場合に限ります。承認の取消や差戻しに合わせて会計側で逆仕訳や取消を自動で起こす必要がある。連携先が自社独自の基幹システムで、公開されたAPIを持たない。月数千件を超える件数で、iPaaSの実行回数課金が開発費の償却額を上回る。

逆に、承認完了の通知やファイル保存のような一方向の単純な連携に個別開発は過剰です。iPaaSで組み、件数が増えた時点で見直せば足ります。個別開発に該当する連携は、既存システム間のAPI開発・システム連携として、連携先の仕様調査から設計・試験まで受託で進められます。

システム連携開発の見積りを左右するエラー処理・再送・監視の設計範囲

連携開発の見積りで差が出るのは、正常時の処理ではなく失敗時の扱いです。見積りを比べるときは、次の項目が範囲に入っているかを確認します。

同じ申請を2回送っても1件しか登録されない仕組み（申請番号を外部キーにする等）
連携先が止まっていた場合の自動再送の回数と間隔
再送しても失敗した申請を担当者に知らせる通知と、手動で再実行する画面
どの申請がいつどこへ連携されたかを追える処理履歴の保存期間

これらが見積りに入っていないと、本番で連携が1件失敗するたびに、開発会社へ調査を依頼することになります。連携先の数や方向による工数の増え方はワークフローシステムの費用相場と内訳で試算しているので、あわせて確認してください。

よくある質問

ワークフローシステムの連携を検討する担当者から寄せられやすい質問に答えます。

APIを持たない会計ソフトともワークフローシステムは連携できますか？

多くの会計ソフトは仕訳のCSV取込に対応しているため、ワークフロー側から承認済みデータをCSVで書き出せば連携できます。その際は、会計ソフトの取込レイアウトを確認したうえで、列の順序や日付形式を揃えてください。製品によっては主要な会計ソフト向けの出力形式を標準で選べます。毎日の取込作業を人が行う点は残るため、件数が増えて取込漏れが問題になった段階でAPI連携やファイルの自動転送を検討してください。

シングルサインオンとSCIMの連携はどちらを先に導入すべきですか？

目的が違うため、順番は課題で決めます。シングルサインオンはログインを1回で済ませる仕組みで、パスワード管理の負担を減らすためのものです。SCIMは利用者や組織の情報を自動で登録・更新する仕組みで、異動や退職の反映漏れを防ぎます。承認経路の更新漏れが問題になっているならSCIMが先です。どちらも同じIDの管理基盤から設定することが多いため、製品選定の段階で両方への対応を確認しておくと二度手間を避けられます。

ワークフローシステムの連携はRPAとiPaaSのどちらで組むべきですか？

連携先がAPIを公開しているならiPaaSを選びます。RPAは画面操作を再現する仕組みで、連携先の画面が変わると止まるため、APIで済む処理に使う理由はありません。RPAが向くのは、APIもCSV取込も無い古いシステムへ入力するしかない場合です。その場合でも、入力件数が多く業務の中心にある処理なら、RPAで延命するより連携先側にAPIを作る開発を比べる価値があります。

承認依頼をTeamsやSlackに通知するだけでも開発は必要ですか？

多くのクラウド型ワークフロー製品は、TeamsやSlackへの通知を標準機能かオプションで備えているため、通知だけなら開発は要りません。製品に通知機能が無い場合も、承認完了のWebhookをiPaaSで受けてチャットへ投稿すれば足ります。開発が必要になるのは、チャット上のボタンで承認まで完結させたい場合です。Teamsではボタンを伴うカードの扱いに制約があり、Workflowsアプリだけでは組めない構成になります。

ワークフローシステムを乗り換えるとき既存の連携はどう移せばよいですか？

まず現行の連携を一覧にし、連携先・方式・頻度・担当者を書き出します。乗り換え後の製品が同じ方式に対応していても、CSVの列構成やAPIの項目名は変わるため、連携先側の取込設定も変更が必要です。移行期間は新旧の製品を並行稼働させ、新製品から出したデータを連携先のテスト環境に取り込んで、件数と金額が旧製品と一致するかを照合してから切り替えます。承認途中の申請は旧製品で完了させ、新規の起票から新製品に移すと混乱が少なく済みます。