このガイドの背景
受注画面を開き、顧客名と金額を会計ソフトへコピーする。便利なツールを導入したはずなのに、その間を人がつないでいる。入力のたびに同じ確認を繰り返していませんか。
転記のルールが決まっていて、双方のサービスが必要なAPIを提供していれば、自動化を検討できます。人の判断を残す場所も含め、最初に任せる作業と費用の考え方を整理します。
転記の前にしている確認まで、見てみる
説明用の例として、営業が確定した受注を経理の請求候補へ移す仕事を考えます。コピーしているのは顧客名と金額でも、実際には「承認が済んでいるか」「請求先が支店ではなく本社か」を確かめているかもしれません。ここを無視して転記だけ自動化すると、判断が必要な情報まで次の仕事へ流れてしまいます。
まず担当者に、普段の一件を処理してもらいます。開始のきっかけ、参照する資料、迷う場面、終わったと分かる状態を拾います。初期範囲を「承認済み受注から請求候補を作る」までにし、請求書の発行は経理が行う案なら、判断を残しつつ転記を減らせます。全自動にすることより、毎日同じ確認をしている部分から減らすのが出発点です。
検討の流れ説明用の例：受注から請求候補を作る- 01承認済みを選ぶ
未確定の受注は自動転記に含めない
- 02候補を登録する
顧客IDと金額を対応させ、不明分は保留
- 03経理が発行する
請求候補を確認して既存の承認へ進む
入力を自動化する範囲と、請求を確定する人の判断を分けた構成です。
両方を最新にしたいときほど、更新元を決める
顧客名はCRMで管理し、請求先住所は会計側で経理が直している場合、CRMの住所をそのまま送ると正しい訂正を消すおそれがあります。正しい値を決める場所は、システムごとではなく項目ごとに決めます。双方向同期という機能を付けるだけでは、同時に変更された情報のどちらを採用するかは決まりません。
取引先の識別も、名前の一致だけには頼れません。同名企業や支店、改名に対応するため、両サービスのIDを結び付けます。対応がない顧客は無理に新規登録せず、担当者が確認する一覧へ出す方法があります。空欄が未入力なのか削除の指示なのか、金額の丸めや日付の基準も、少数の実例で確かめると違いを発見しやすくなります。
表が収まらない場合は横にスクロールできます。
説明用の例：転記前に決めるデータの扱い| 情報 | 基準にする場所 | 判断が必要な場面 |
|---|
| 取引先 | CRMと会計のID対応 | 未登録・統合済みの顧客 |
|---|
| 請求先住所 | 会計で確認した値 | 営業側の住所変更 |
|---|
| 請求候補の金額 | 承認済みの受注明細 | 締め後の訂正や丸め差 |
|---|
| 取消 | 受注側の処理状態 | 請求済みの案件の取消 |
|---|
使っているツール名が分かれば、調査を始められる
APIが公開されているかに加え、契約中のプランで使えるか、必要な項目を読んだり書いたりできるかを調べます。履歴や添付、削除されたデータの扱いも対象です。自社側では、管理者が誰か、接続を承認できるかを確認してください。アカウントを用意するまで開発や試験が進まない場合があります。
大量の取り込みでは呼び出し制限が効きます。Amazon SP-APIのように、操作やアカウントとアプリの組み合わせなどで条件が変わるAPIもあります。平常日の件数だけでなく、初回の過去分と、停止後に取り戻す分を含めて調べます。接続調査で可否と制約を明らかにしてから本開発を判断する案なら、不明点が多い段階でも相談を進められます。
参考：Amazon：Usage Plans and Rate Limits
すべての情報を即時に反映する必要はある？
出荷の指示は締め切り前に必要でも、社内の集計は翌朝までに揃えばよいかもしれません。誰がいつその情報で判断するかを聞くと、必要な反映速度が分かります。変化を知らせるWebhook、一定間隔での取得、担当者が実行する取り込みを、業務に合わせて選びます。即時という言葉だけで、反映が遅れた場合の対処まで決まるわけではありません。
ShopifyはWebhookの順序や配送だけに依存せず、定期的に元データを照合する考え方を示しています。これを踏まえた設計なら、通知で早く取り込み、別の確認で漏れを探す役割分担ができます。照合でも取得時点の違いは生じるため、処理中のものと未反映のものを区別します。差があるたびに無条件で上書きする仕組みにはしないことが大切です。
参考：Shopify：Best practices for webhooks
API連携の費用は、何ができるところまで含むかで変わる
ダンドリの公表料金では、特定作業を改善する小規模な開発・業務自動化は40万円〜です。必要な設計・開発の作業量は、1人月160万円、160時間換算を基準に個別に見積もります。説明用の算式では40時間と仮定すると160万円×40÷160＝40万円ですが、API連携が40時間で完成するという工数保証ではありません。
費用を変えるのは、取得だけか書き込みもあるか、データの変換、過去分の移行、保留や復旧の仕組みです。外部サービスの利用料は別途必要になります。予算が限られるなら、連携先を減らすだけでなく、最初は承認済みデータの一方向転記へ絞る案もあります。必要な記録や重複防止を省くより、業務の対象を狭めて見積もりを比べる方が運用を考えやすくなります。
一度つながった後に、担当者が困らないかを試す
受注の登録後に通信が切れたら、送り直す前に相手の登録結果を確かめる必要があります。失敗表示が出たものをすべて未処理とみなすと、二重登録になるおそれがあるためです。説明用の例では、対象受注を番号で追い、登録済み、保留、結果不明を分けて見られる状態を目指します。手作業で補った分も、後の自動処理と重ならないよう記録します。
依頼先には、正常な転記に加えて、顧客IDが不明、途中だけ成功、権限切れといった場面の扱いを示してもらいます。担当者が保留の理由を読み、直す相手を判断し、対象を指定して再開できるかが確認点です。完成した仕様書がなくても、利用サービスと転記例、困る例外があれば、この範囲の相談を始められます。
検討・発注前のチェックリスト
担当者と確認状況を添えて、社内の検討メモや打ち合わせの議題にご活用ください。
チェックリストをテキストで保存確認日：________________ / 担当者：________________
- □毎日繰り返す転記と、人の判断が必要な作業を分ける。確認状況・メモ：
- □項目ごとに正しい値を決める場所を選ぶ。確認状況・メモ：
- □利用プランと接続を承認する管理者を確認する。確認状況・メモ：
- □反映が必要な締め切りを業務ごとに決める。確認状況・メモ：
- □初回移行と停止後の再取得も見積もりへ含める。確認状況・メモ：
- □保留・結果不明・手動処理済みを区別できるか試す。確認状況・メモ：
よくある質問
APIがないツールも自動化できますか？
正式に提供されるCSV入出力や既存の連携機能を確認します。ダンドリのAPI連携サービスでは、公開APIのないサービスの画面操作を模した自動化は対象外です。手作業を一部残す案も含めて考えます。
自動化した後も、全件の目視確認が必要ですか？
確認する対象は業務の影響と精度の検証結果から決めます。最初は従来の結果と比較し、安定した処理は例外と差分を確認する運用へ移す案があります。確認負担が減るかも試験運用で評価します。
参考資料
製品の仕様・提供条件は変更されることがあります。採用時には公式資料と契約内容をご確認ください。
記事の内容を、自社の検討へ
毎日の転記を減らす開発について相談する
利用中のツールと、繰り返し入力している項目をお知らせください。APIの利用条件から確認し、ご予算に合わせて最初に自動化する範囲をご提案します。
相談で整理すること対象業務・開発する範囲・運用の分担。まだ決まっていないことも含めて、一緒に整理します。
API連携・自動化を相談する →この記事について
編集・発行：株式会社ダンドリ
AI・業務システム・Webサービスの設計、開発、運用を支援する会社です。開発を検討する方が判断に使えるよう、公式資料と公開情報をもとに解説しています。
説明用の例と公開事例を区別し、参照した資料は本文と記事末尾に掲載しています。
会社情報を見る →
