こんにちは。CData Software Japan の色川です。
kintone の連携でご相談を頂くテーマの中でも、ここ数年、特に増えているのが「基幹システムとの連携」です。例えば「営業部門が kintone で受注を起票し、上長が承認したものを基幹システムに登録したい」というのは良くあるケースかと思います。
このようなシナリオでは、承認された受注データを基幹システムに「登録する（送る）」だけでは、業務としては完結しないケースが少なくありません。kintone 側からみたとき「基幹システムで採番された受注番号や、その後の出荷の状況を kintone に返し、kintone のプロセス管理のステータスも進めたい」ような場面も多いと思います。そうすれば、kintone を開くだけで「この受注はいまどこまで進んでいるのか」が把握できます。
さらに実際の運用では、基幹システムに登録できなかった受注をどう扱うかも大切です。マスタに無いコードを使っていた、といったエラーの理由を kintone に返し、担当者が直して承認し直したものだけを、もう一度基幹システムに送りたい。このようなニーズは業種・業態を問わず、多いと思います。ここでは、こうした「登録した結果の連携」や「エラーのときの連携」までを含めて、一連の流れをイメージいただけるよう、例を含めてご紹介してみたいと思います。
この記事では「CData Arc で、kintone のプロセス管理と基幹システムを連携する」方法をご紹介します。
CData Arc
CData Arc は、CData 製品の中で「自動化/Automate」を担うデータ連携ツールです。「B2B 連携をもっとシンプルに」をコンセプトに、ファイル連携 & DB 連携 & API 連携といった B2B 連携に必要なすべてをノーコード・ローコードでつなぐことができるプラットフォームです。
Arc には kintone 専用のコネクタ（kintone コネクタ）があり、レコードの取得（Select）や登録・更新（Upsert）に加えて、kintone のプロセス管理のアクションを実行する「UpdateStatus」などの操作も「Execute Stored Procedure」アクションから利用できます。この記事では、基幹システムでの結果にあわせて、Arc から kintone のステータスを進めます。
この記事では基幹システム側のデータベースとして、PostgreSQL を利用しました。Arc は PostgreSQL 以外にも SQL Server・Oracle・MySQL・IBM i（DB2 for i）など主要なエンタープライズデータベースのコネクタを備えているので、実際の基幹システムのデータベースにあわせて読み替えてください。
この記事のシナリオ
この記事では「kintone で承認された受注を基幹システムに登録し、基幹システムでの登録結果・エラー・出荷の情報を kintone に書き戻して、プロセス管理のステータスを進めるシナリオ」をご紹介します。
kintone の受注のステータスは、以下のように進みます。「申請する」「承認する」「修正して再申請」は kintone 上で人が行い、「基幹登録」「基幹エラー」「出荷完了」は Arc が基幹システムの状況にあわせて実行します。
ステータス | 次に進めるアクション | 誰が進めるか |
未申請 | 申請する | 営業担当（kintone） |
承認待ち | 承認する / 差し戻す | 承認者（kintone） |
承認済み | 基幹登録 | Arc（基幹システムへの登録が成功したとき） |
承認済み | 基幹エラー | Arc（基幹システムへの登録がエラーになったとき） |
基幹登録済み | 出荷完了 | Arc（基幹システムで出荷済みになったとき） |
出荷済み | - | - |
連携エラー | 修正して再申請 | 営業担当（kintone） |
基幹システムに登録できなかった受注は「連携エラー」に進め、kintone の「連携メッセージ」に理由を書き戻しています。営業担当が内容を直して再申請すると、もう一度承認を経てから基幹システムに送られるイメージです。そうすることで、承認のあとで直した内容が、承認を経ずに基幹システムに入らないようにしています。
kintone アプリの準備
kintone には以下のような「受注（基幹連携）」アプリを用意しました。受注の見出しの項目と、明細のテーブル（サブテーブル）に加えて、Arc が書き戻すための項目（基幹受注番号・出荷日・送り状番号・連携メッセージ）を持たせています。
項目 | フィールドの種類 | 備考 |
受注日・得意先コード・得意先名・希望納期 | 日付・文字列（1行） | 受注の見出し |
明細（商品コード・商品名・数量・単価・金額） | テーブル | 金額は計算（数量 × 単価） |
合計金額 | 計算 | 明細の金額の合計 |
基幹受注番号・出荷日・送り状番号 | 文字列（1行）・日付 | Arc が基幹システムから書き戻す |
連携メッセージ | 文字列（複数行） | Arc が登録結果やエラーの理由を書き戻す |
プロセス管理は、シナリオのステータスとアクションのとおりに設定しています。Arc が実行する「基幹登録」「基幹エラー」「出荷完了」のアクションは、作業者を設定していません。「連携エラー」の作業者は、レコードの作成者（営業担当）にしています。
基幹システム側（想定）の準備
この記事では、PostgreSQL の販売管理データベース（得意先・商品・受注・受注明細）を基幹システムに見立てています。
kintone の受注は、基幹システムの受注テーブルに直接は書き込まず、取込用のテーブル（インターフェーステーブル）に登録する形にしました。基幹システムの取込処理が、得意先コードや商品コードがマスタにあるかを確かめてから受注として登録し、その結果を「結果のインターフェース」として返します。基幹システムとの連携では、このように取込用・結果用のインターフェースを経由する形がとられることも多いかと思います。
種類 | 名前 | 内容 |
取込用 | if_kintone_orders | 受注の見出し。kintone のレコード番号がキー |
取込用 | if_kintone_order_lines | 受注の明細。kintone のテーブルの行 ID がキー |
結果用 | if_kintone_results | kintone に返す結果 |
結果のインターフェース（if_kintone_results）の項目は、以下のとおりです。
項目 | 内容 |
kintone_record_id | kintone のレコード番号 |
result_status | 基幹システムでの状態（登録済み / エラー / 出荷済み） |
order_no | 基幹システムで採番された受注番号 |
shipped_date・tracking_no | 出荷日・送り状番号 |
result_message | 登録結果やエラーの理由 |
changed_at | 結果が変わった日時 |
基幹受注番号は「KT-」に kintone のレコード番号を付けて採番しています。また、同じ内容の受注が取込用のテーブルに届き直しても、基幹システム側で取り込み直さない作りにしています。
実際の基幹システムでは、取込用のテーブルの代わりに取込用のストアドプロシージャや API を用意しているものもあるかと思いますので、それぞれの環境にあわせて読み替えてください。
事前準備
この記事では、以下の環境で検証しました。
製品・サービス | 内容 |
CData Arc | CData Arc 2026（26.4.9792.0） |
kintone | kintone 開発者ライセンスの環境 |
基幹システム（の代わり） | PostgreSQL 16 |
Arc では「設定」→「接続」で、kintone と PostgreSQL の接続を作成しておきます。
連携フローの作成
このシナリオで作成する連携フローは、以下の 2 つです。
# | フロー | コネクタ | 内容 |
1 | 承認済み受注の登録 | kintone（Select） | ステータスが「承認済み」で、まだ基幹受注番号が無い受注を取得 |
| | XML Map | kintone の受注を取込用テーブルの形に変換 |
| | PostgreSQL（Upsert） | 取込用テーブルに受注と明細を登録 |
2 | 結果の書き戻しとステータスの更新 | PostgreSQL（Select） | 結果のインターフェースから、前回から変わった結果を取得 |
| | XML Map | kintone の項目の形に変換 |
| | kintone（Upsert） | 基幹受注番号・出荷日・送り状番号・連携メッセージを書き戻し |
| | （成功パス）XML Map | 書き戻しに成功したものについて、基幹システムでの状態を kintone のアクションに読み替え |
| | kintone（Execute Stored Procedure） | UpdateStatus でプロセス管理のアクションを実行 |
2 つ目のフローでは、kintone コネクタ（Upsert）の「成功パス」を使っています。kintone への書き戻しが成功したメッセージだけが、そのままステータスの更新に進みます。書き戻しができなかったときはステータスも進まないので、kintone の項目とステータスが食い違うことがありません。
完成したフローは以下のようになります。
それでは Arc のフローデザイナーで連携フローを作成していきます。
1. 承認済み受注の登録
kintone コネクタ（Select）
最初に、kintone から承認済みの受注を取得する kintone コネクタを設定します。アクションは「Select」で、受注の見出しの項目に加えて、明細のテーブル（受注（基幹連携）_明細）も子のテーブルとして取得します。
取得する受注は「ステータスが承認済みで、基幹受注番号がまだ入っていないもの」に絞り込みます。テーブル名を右クリックして開く「テーブル設定」の「フィルタ」で、以下の 2 つの条件を「および」でつなぎました。明細のテーブルも同じく「フィルタ」で、親の受注のレコード番号（RecordId）を参照して絞り込んでいます。
カラム | 条件 | 値 |
ステータス | 次と等しい | 承認済み |
基幹受注番号 | Null | - |
基幹システムに登録できた受注は「基幹登録済み」に、エラーになった受注は「連携エラー」に進むので、どちらも次からは取得されなくなります。エラーになった受注は、営業担当が直して再申請し、もう一度承認されると、また取得の対象になります。
XML Map コネクタ
続いて、XML Map コネクタで kintone の受注を取込用テーブルの形に変換します。
この記事では、以下のようにマッピング（対応付け）しました。
kintone（受注（基幹連携）） | 基幹システム（取込用テーブル） |
RecordId（レコード番号） | if_kintone_orders.kintone_record_id |
得意先コード・得意先名 | customer_code・customer_name |
受注日・希望納期 | order_date・delivery_date |
合計金額 | kintone_total |
（固定値）pending | if_status |
明細の Id（テーブルの行 ID） | if_kintone_order_lines.kintone_row_id |
明細の商品コード・商品名・数量・単価 | product_code・product_name・quantity・unit_price |
取込の状態（if_status）には、固定値の「pending」（取込待ち）を指定しています。
明細の部分は、kintone のテーブル（受注（基幹連携）_明細）の行ごとに、取込用の明細テーブル（if_kintone_order_lines）の 1 行を作るよう対応付けています。
PostgreSQL コネクタ（Upsert）
最後に、取込用テーブルに受注を登録する PostgreSQL コネクタを設定します。アクションは「Upsert」で、受注の見出し（if_kintone_orders）と明細（if_kintone_order_lines）を親子のテーブルとして登録します。
キーは kintone のレコード番号（明細はレコード番号とテーブルの行 ID）なので、同じ受注が届き直したときは新しい行は作られず、既存の行が更新されます。
2. 結果の書き戻しとステータスの更新
続いて、基幹システムでの登録結果や出荷の情報を kintone に書き戻し、そのままプロセス管理のステータスを進めるフローを作成します。
PostgreSQL コネクタ（Select）
起点となる PostgreSQL コネクタは、結果のインターフェース（if_kintone_results）から kintone に返す情報を取得します。アクションは「Select」で、レコード番号・基幹システムでの状態（result_status）・受注番号・出荷日・送り状番号・メッセージを取得します。
このコネクタでは、changed_at（結果が変わった日時）を使って、前回の実行から変わった行だけを取得するようにしています。ソースのテーブル名（SELECT 元）をクリックして開く「ソース構造を編集」の「オプション」で、「カラムを使用」にチェックを入れ、changed_at を選ぶだけです。基幹システムに登録されたときや、出荷済みになったときなど、結果が変わった受注だけが kintone に書き戻されます。
XML Map コネクタ
XML Map コネクタで、基幹システムの項目を kintone のフィールドに対応付けます。
基幹システム（if_kintone_results） | kintone（受注（基幹連携）） |
kintone_record_id | RecordId（レコード番号） |
order_no | 基幹受注番号 |
shipped_date | 出荷日 |
tracking_no | 送り状番号 |
result_message | 連携メッセージ |
result_status | （メッセージヘッダー）result_status |
基幹システムでの状態（result_status）は kintone のフィールドには書き込まず、「メッセージヘッダー」としてメッセージに持たせておきます。宛先のノードを右クリックして「ノードを追加」→「ヘッダーを追加」でヘッダーのノードを作り、result_status をドラッグ＆ドロップで対応付けるだけです。このヘッダーを、後ろのステータスの更新で使います。
kintone コネクタ（Upsert）
kintone に書き戻す kintone コネクタを設定します。アクションは「Upsert」で、RecordId をキーに 4 つの項目を更新します。
フローデザイナーでこのコネクタを右クリックし、「成功パスを表示」を選ぶと、コネクタに「成功パス」の出口が現れます。この成功パスを、次の XML Map コネクタにつなぎます。
XML Map コネクタ（成功パスの先）
成功パスには、kintone への書き戻しに成功したメッセージがそのまま流れてきます。この XML Map コネクタで、kintone の UpdateStatus（ステータスの更新）の引数の形に変換します。
成功パスの先ではソースのテンプレートが自動では選べないので、書き戻しに成功したメッセージのサンプル（XML ファイル）を、ソースの「テンプレートファイル」から「ファイルをアップロード」で読み込みました。サンプルは、一度フローを流したときにトランザクションに残った、書き戻しに成功したメッセージと同じデータ構成のファイルです。
アプリ ID（AppId）には kintone アプリの ID を固定値で、RecordId にはレコード番号を指定します。アクションの名前（Action）は、ヘッダーで受け取った基幹システムでの状態（result_status）から読み替えます。ここでは XML Map の「条件」を使って、以下の 3 つの条件ノードを作りました。それぞれの条件に一致したときだけ、そのアクションの名前が出力されます。
条件（ヘッダー result_status） | Action（kintone のアクション） |
登録済み | 基幹登録 |
エラー | 基幹エラー |
出荷済み | 出荷完了 |
条件は、Action のノードを右クリックして「ノードを追加」→「条件を追加」から設定します。比べる値には「メッセージヘッダー」を選び、ヘッダーの名前（result_status）と比べる値を入れるだけです。1 つ目の条件を作ったら、コピーして貼り付け、条件の値とアクションの名前を変えれば残りの 2 つもすぐに作れます。
kintone コネクタ（Execute Stored Procedure）
最後に、ステータスを更新する kintone コネクタを設定します。アクションは「Execute Stored Procedure」で、ストアドプロシージャに「UpdateStatus」を指定します。UpdateStatus は、kintone のプロセス管理のアクションを実行するストアドプロシージャで、AppId・RecordId・Action のほか、次の作業者を指定する Assignee なども用意されています。
起点のコネクタのオートメーション
2 つのフローの起点のコネクタ（kintone_承認済み_Select・基幹_結果_Select）は、「オートメーション」で「受信」を有効にし、間隔を「分」、1 分おきに実行するよう設定しました。
これで「kintone で承認された受注を基幹システムに登録し、基幹システムでの登録結果・エラー・出荷の情報を kintone に書き戻して、プロセス管理のステータスを進めるシナリオ」のフローが完成しました。
連携フローの実行
作成したフローを実行して確認してみましょう。kintone では、レコード番号 1〜3 の受注を申請・承認して「承認済み」にしました。レコード番号 2 は、明細の 2 行目にわざと基幹システムに無い商品コード（CS-5099）を入れています。レコード番号 4 は承認待ちのままです。
しばらくして kintone を開くと、レコード番号 1 と 3 は基幹受注番号が書き戻され、ステータスが「基幹登録済み」に進んでいることが確認できます。レコード番号 2 は「連携エラー」に進み、連携メッセージにエラーの理由が書き戻されています。作業者は、レコードを作成した営業担当です。
連携エラーの受注は、営業担当の「作業者が自分」の一覧にも並びます。基幹システムに入らなかった受注に、担当者が kintone の中で気づけるのは、プロセス管理のステータスとして返すことの良いところだと思います。
営業担当は、商品コードを正しいもの（CS-5002）に直して「修正して再申請」を実行し、承認者がもう一度承認しました。次の実行で、内容が変わった受注として基幹システムに取り込まれ、レコード番号 2 も基幹受注番号 KT-000002 で「基幹登録済み」に進みました。
続いて、基幹システムで KT-000001 の受注を出荷済みにしました（この記事では SQL で受注のステータスと出荷日・送り状番号を更新しています）。次の実行で、レコード番号 1 に出荷日と送り状番号が書き戻され、ステータスが「出荷済み」に進んだことが確認できます。
受注の一覧で見ると、それぞれの受注が基幹システムでどこまで進んでいるかが一目で分かります。
二重登録などを防ぐ仕組み
定期的に動かす連携では、同じ受注が何度か届くことを前提にしておくと安心です。この記事の構成では、以下のような仕組みで二重の登録やステータスの進みすぎを防いでいます。
狙い | 仕組み |
基幹システムの受注が重複しない | 取込用のテーブルは kintone のレコード番号（明細はレコード番号とテーブルの行 ID）がキーです。Arc は Upsert で書き込むので、同じ受注は何度届いても 1 行です。基幹受注番号も「KT-レコード番号」で決まります |
同じ内容を取り込み直さない | 内容が変わっていない受注が届き直しても、基幹システムでは取り込み直しません。内容が変わったとき（明細を直して再申請・承認されたときなど）だけ、取込をやり直します |
ステータスが進みすぎない | kintone は、いまのステータスで実行できるアクションしか受け付けません。同じアクションが重ねて届いても、ステータスが余計に進むことはありません |
Arc で連携の状況を確認する
連携を運用していくと、「この受注はいつ基幹システムに送られたのか」「結果はいつ戻ったのか」を確かめたくなる場面があるかと思います。Arc の「アクティビティ」では、フローを流れたメッセージを一覧で確認できます。
メッセージを開くと、フローの中のどのコネクタをどう流れたかを追いかけられます。下の例では、基幹システムの結果が kintone に書き戻され、成功パスからステータスの更新（UpdateStatus）まで進んだことが分かります。
kintone や基幹システムに一時的に接続できなかったときなどに備えて、コネクタごとに再試行の間隔と最大試行回数も設定できます。この記事では、60 分おきに最大 5 回まで再試行する設定にしています。
このほか、Arc には以下のような機能もあります。
なお、1 つ目のフローは kintone を定期的に取得するので、実行の間隔を短くするほど kintone の API の利用回数が増加します。2 つ目のフローは、基幹システム側に変化があったときだけ kintone に書き込みます。実行の間隔は、承認から基幹システムへの登録までに許される待ち時間と、kintone の「API の利用状況」などを考えつつ決めていただくのが良いかと思います。
まとめ
この記事では「CData Arc で、kintone のプロセス管理と基幹システムを連携する」方法をご紹介しました。
kintone の承認を関門にして基幹システムに登録し、その結果を kintone のレコードとプロセス管理のステータスに返すという一連の流れ（2 つのフロー）を、シンプルな GUI 設定で構成・自動化できることをイメージいただけたかと思います。この記事の例では、基幹システムに入らなかった受注は「連携エラー」として営業担当に戻り、直した受注はもう一度承認を経てから基幹システムに届きます。kintone からは基幹システムの状況が見え、基幹システムには承認済みの受注だけが届くので、どちらの担当者にとっても分かりやすい連携になるのではないでしょうか。
CData での kintone 連携方法に関する全体像については、こちらの「kintone ソリューションページ」や「kintone の連携方法を総まとめ」もあわせてごらんください。
CData Arc はシンプルで拡張性の高いコアフレームワークに、豊富なMFT・EDI・エンタープライズコネクタを備えたパワフルな製品です。業界最多級のコネクタにより、業種業界を問わず、企業のデータ連携自動化で幅広く活用いただけます。
皆さんのつなぎたいシナリオでぜひ CData Arc を試してみてください。
製品を試していただく中で何かご不明な点があれば、テクニカルサポートへお気軽にお問い合わせください。
この記事では CData Arc™ 2026 - 26.4.9792.0 を利用しています
