外部サービス連携で、失敗・遅延・重複をどう扱うか
APIや定期同期について、接続先の停止、通信遅延、再送、部分失敗を検知し、安全に復旧する仕組みを整理します。
03 / BUILD
つくるフェーズ
外部サービスや業務システムとつなぐための設計と実装を整理する。
API接続という言葉を聞くと、高度なシステム開発や大規模な基幹システムを思い浮かべるかもしれません。
しかし実際には、お問い合わせフォームからの通知、CRMへの顧客情報登録、Slackへの自動通知、Googleサービスとの連携、決済システムとの連携など、日常的なWeb運用の中にもAPI接続は多く使われています。
Flying High Works(FHW)では、API接続を「外部サービスとつなぐ技術」ではなく、情報を流すための仕組みとして捉えています。
私たちが日常的に利用している多くのサービスは、APIによって連携されています。
こうした連携は、単にシステムをつなぐためではなく、必要な情報を必要な場所へ正しく流すために行います。
企業のシステム運用では、同じ情報を複数の場所で管理しているケースが少なくありません。
例えば、お問い合わせフォームから届いた内容を担当者が確認し、Salesforceへ転記し、社内システムへ登録し、Slackへ共有する、といった流れです。
このような運用では、次のような問題が発生します。
API接続を利用することで、一度入力した情報を複数のシステムへ自動連携できるようになります。
その結果、入力作業の削減、情報共有の高速化、ヒューマンエラーの削減、運用負荷の軽減につながります。
私たちはこれまで様々なAPI接続を行ってきました。
また近年では、Zapierなどのノーコードサービスを利用し、社内システムとの連携を行うケースもあります。
API接続というとシステム開発のイメージが強いですが、実際にはCRM、通知、決済、会員管理、顧客管理、業務改善など幅広い領域で活用されています。
私たちは単にAPIを接続するだけではなく、業務フロー全体を整理しながら設計を行っています。
Salesforceを情報管理の中心とし、建物情報、個室情報、空室情報、問い合わせ情報などを一元管理し、Webサイトへ反映する構成を提案・構築しています。
担当者がSalesforceで情報を更新し、Webhook通知を受けたWebシステムがDBを更新し、Webサイトへ反映する流れです。
これにより、更新作業の一元化やリアルタイム反映を実現します。
人材紹介・人材派遣業界向けのPortersでは、求人情報、企業情報、求職者レジュメなどの情報を取得し、Webサイトと連携しました。
また、面接管理や選考フローなど、運用との連携も行っています。
顧客情報を取得し、ログインシステム、会員情報、マイページ情報との同期を行っています。
顧客情報の更新内容をWebシステムへ反映したり、逆にWebサイトから登録された情報をCRMへ連携したりすることで、運用の一元化を実現しています。
API接続で最も重要なのは、どこを情報の起点とするのかを決めることです。
例えばSalesforceを情報管理の中心にする場合、建物情報、個室情報、空室情報、問い合わせ情報などをSalesforceで管理し、Webサイトへ連携することができます。
重要なのは、どこで情報を管理するのかを最初に決めることです。
これが曖昧なまま連携を始めると、二重管理、情報不整合、更新漏れの原因になります。
API連携には大きく2つの考え方があります。
情報が更新された瞬間に通知を受け取り、即座に処理を行う方法です。
例えば、Salesforceで空室情報を更新し、Webhook通知を受けたWebシステムが更新され、Webサイトへ反映する流れになります。
一定時間ごとにAPIへアクセスし、変更内容を取得する方法です。
リアルタイム性は下がりますが、安定した運用が可能です。
私たちは要件に応じて、WebhookとAPIポーリングを使い分けています。
API接続はWebサイトだけの技術ではありません。
私たちは社内業務改善にも活用しています。
共有メールアドレスに届いたメールを自動判定し、Slackへ通知する仕組みです。
などを自動で通知し、見落としを防ぎます。
Googleフォームから受け付けた依頼を、Backlog、Slack、スプレッドシートなどへ連携し、担当振り分けや進行管理を行う仕組みです。
依頼がメールやチャットに散らばることを防ぎ、業務の見える化を実現します。
API接続で重要なのは、接続そのものではありません。
リアルタイム連携が必要な情報もあれば、JsonSnapshotのように事前生成した方が良い情報もあります。
空室情報、会員情報、在庫情報はAPI連携向きです。
一方で、路線ごとの件数、駅ごとの件数、ランキング情報などはJsonSnapshotによる事前生成の方が向いています。
API接続では、認証情報、アクセストークン、APIキーなどを扱います。
そのため、次のような対応が必要になります。
また、どこまでをWeb側が管理し、どこからを外部システム側が管理するのかという責任範囲の整理も重要です。
API接続はシステム同士をつなぐ技術である一方、運用設計の要素も強く含んでいます。
API接続は、接続できたら終わりではありません。
運用を続ける中で、次のような変更が発生します。
そのため、将来的な変更を前提とした設計が必要になります。
私たちは、「今つながるか」だけではなく、数年後も運用できるかという視点で設計しています。
接続後の失敗検知、重複防止、再試行、照合、手動復旧については、 外部サービス連携の実務知識で詳しく整理しています。
私たちはAPI接続を、単なる技術実装としては考えていません。
大切なのは、システム同士をつなぐことではなく、情報を正しく流すことです。
利用するサービスは変わっても、情報の流れを整理するという考え方は共通しています。
私たちは、どのサービスを使うかではなく、どのように情報を流し、どのように運用するのかという視点でAPI接続を設計しています。
API接続は単独で存在するものではなく、CMS、会員システム、業務システム、通知システムなどをつなぐ情報連携の基盤だと考えています。
同じ「つくるフェーズ」から、あわせて読みたい内容をご案内します。
同期失敗時の再処理、CSVとの使い分け、業務の状態管理を設計する際の確認事項です。
APIや定期同期について、接続先の停止、通信遅延、再送、部分失敗を検知し、安全に復旧する仕組みを整理します。
CSVの一括登録・更新で、識別キー、空欄、部分失敗、事前確認、再実行、復旧を安全に扱う確認方法を整理します。
紙やPDFで行ってきた申込・注文業務をWeb化するとき、利用者の操作、受付側の確認、例外処理、計算、保存、外部連携までを一続きで設計する方法を整理します。