Salesforce 連携がプロトコルで失敗することは、まずありません。認証は解決済みの問題ですし、レコードを 1 件登録するのも解決済みの問題です。プロジェクトを終わらせるのは、1 日あたりのリクエスト割り当てと、データモデルの形のほうです。しかもその両方は、たいてい本番稼働から三週間ほど経った頃、夜間ジョブがエラーを返しはじめ、なぜテストでは通っていたのか誰も説明できなくなった時点で発見されます。
パターンは予測できるほど一貫しています。開発者は Developer Edition 組織に対して実装し、すべて通り、顧客が検収します。そのコードがやがて出会うのは、マーケティング用コネクタと、データウェアハウスへの抽出処理と、2019 年から動いている Apex トリガーがすでに同居している本番組織です。潤沢に見えたリクエスト予算は、他人がすでに使っている共有の財布だったと判明します。
この記事では、その驚きを先回りして並べます。どの API を使うべきか、割り当てはどう計算されるのか、自分の書き込みが自分の書いていないコードを起動するとどうなるのか、認証はどう変わったのか、そしてあとから覆すと高くつくデータモデルの判断は何か、です。
Salesforce 連携の成否を決めるのは何か。 プロトコルではなく、割り当てとデータモデルです。1 日あたりの API リクエスト割り当ては組織全体で共有され、エディションとライセンス数から導かれます。つまり、行儀のよい連携が、同じ組織にいる出来の悪い連携のせいで枯渇させられます。最初の一行から一括処理を前提に設計し、何かを書き込む前に外部 ID と upsert を合意し、送るレコードはすべて誰かの Apex を起動すると考えてください。
Salesforce 連携が外してはいけないこと
四つあり、重みは同じではありません。
一つめは割り当てです。コードが行う同期呼び出しは、すべて組織全体で共有される 1 日あたりの単一の割り当てから引かれます。その組織を使う他のあらゆる利用者と、同じ財布を分け合っています。
二つめは、その下にあるプラットフォームです。Salesforce は HTTP インターフェースの付いたデータベースではありません。アプリケーションプラットフォームであり、あなたの書き込みは、あなたのプロジェクトなど聞いたこともない管理者が設定したトリガー、フロー、入力規則、重複ルール、積み上げ集計項目を実行します。
三つめはデータモデルです。Lead、Contact、Account、Opportunity は互いに置き換えできず、それらの間の変換は一方向で副作用を伴い、選び方を誤ればコードの修正ではなくデータ移行になります。
四つめは同一性です。自分のシステムと Salesforce が、どのレコードがどれなのかをどう合意するかという問題です。ここを外すと、機械の速度で重複が生まれます。ここから先の話は、すべてこの四つのいずれかから派生します。
API の全体像と、本当に必要なもの
Salesforce は大きな API 群を公開しています。権威ある一覧は Salesforce API インデックス であり、以下の名称は記憶ではなくそこから取っています。
REST API と SOAP API
REST API は、レコードの形をした処理すべての既定の選択肢です。作成、参照、更新、削除、クエリ、describe。Web フォームが Lead を書き込む場合、ポータルが顧客の未完了のケースを読む場合、そして量の少ない対話的な経路には、これが正解です。
SOAP API は同じ仕事を WSDL 経由で行い、いまも現役です。企業向けミドルウェアの多くがこれをネイティブに話すからであり、クライアントを生成できる強く型付けされた契約が手に入るからでもあります。よくある誤解は、SOAP は旧式で REST が現代的だと決めつけることです。どちらも現行であり、SOAP の create() と update() はそれぞれ最大 200 件のレコードを受け付けます。通信形式よりも、こちらのほうが効いてきます。
Bulk API 2.0
Bulk API 2.0 は、量を扱うための非同期でジョブ型の経路です。CSV をアップロードすると Salesforce がそれを分割して背後で処理し、結果はポーリングで取得します。Salesforce の Bulk API の制限 は、移動する 24 時間あたり最大 15,000 バッチ、同じ枠内で最大 1.5 億件のレコード取り込み、そして 150 MB のジョブファイル上限を認めています。
よくある誤解は、Bulk をあとで効かせるチューニング項目として扱うことです。これは別のプログラミングモデルです。結果は非同期に、レコード単位で返ってきますし、コードは最初からその形で結果を受け取らなければなりません。
Composite と sObject Collections
この二つは REST API のなかで最も価値が高く、最も使われていない部分です。composite リクエスト は一回の呼び出しで最大 25 個のサブリクエストを運び、そのうち最大 5 個をクエリまたは sObject Collections の操作にでき、後続のサブリクエストは先行するサブリクエストが返した ID を参照できます。sObject Collections は同一オブジェクトのレコードを一度のリクエストで最大 200 件まで扱います。どちらも 1 日の割り当てに対しては 一回の呼び出し として数えられ、それこそが要点です。
よくある誤解は、その存在を知らないことです。Account を作り、次に Contact を作り、次に Opportunity を作るという三回の逐次呼び出しは、一回の composite リクエストの三倍の割り当てと、三倍の待ち時間を使います。
Streaming、変更データキャプチャ、Pub/Sub
Streaming API は、PushTopic、汎用イベント、プラットフォームイベント、変更イベントのための CometD ベースの購読チャネルです。変更データキャプチャは、レコードが作成、更新、削除、復元されたときにほぼリアルタイムで通知を発行するので、外部のストアはポーリングなしで Salesforce に追随できます。Platform Events は自分で定義する独自のイベントです。
Pub/Sub API は、発行、購読、スキーマ取得、トピック検出を一つの API にまとめた、より新しい gRPC と HTTP/2 のインターフェースで、ペイロードは JSON ではなく Avro です。新規にイベント駆動で作るなら、ここから始めてください。
よくある誤解は、イベントを保証された配信とみなすことです。イベントは突合の代わりにはなりません。理由は次の節にあります。
API リクエスト制限こそが本当の制約
これがアーキテクチャを決める節であり、たいていは設計が終わったあとに読まれる節でもあります。
1 日の割り当ての計算方法
Salesforce の API リクエスト制限のドキュメント は、割り当てをユーザー単位でもアプリケーション単位でもなく、エディションとライセンス数で定めています。API アクセスのある Enterprise と Professional のエディションは 100,000 回に加えて Salesforce または Salesforce Platform ライセンス 1 件あたり 1,000 回、Unlimited と Performance のエディションは 100,000 回に加えてライセンス 1 件あたり 5,000 回です。Developer Edition は一律 15,000 回、Full サンドボックスは 5,000,000 回です。
ここから二つのことが導かれます。60 ユーザーの Enterprise 組織は 1 日およそ 160,000 回であって、無制限の供給ではありません。そして割り当てがライセンスから導かれる以上、増やす方法はユーザーライセンスを増やすか、追加の API 呼び出しを買うかの二つだけで、どちらも Salesforce の Your Account アプリ経由の購入になります。
何が数えられ、使い切ると何が起きるか
割り当ては、24 時間のあいだにその組織へ行われたすべての呼び出しの合計に対して測られ、REST API、SOAP API、Bulk API、Bulk API 2.0、そして大半の Connect REST API の呼び出しをまとめて対象にします。モバイルアプリなど、特定の Salesforce 接続アプリケーションからの呼び出しは除外されます。
この合算がくせものです。あなたの連携に固有の予算はありません。レポート用コネクタ、マーケティングプラットフォーム、そして組織にある他のすべての連携と一つの予算を共有しており、三十秒ごとにポーリングする出来の悪い利用者が一つあるだけで、それを飲み干し、まったく正しく振る舞っているコードを枯渇させられます。
組織が割り当てを超えると、リクエストは 403 と REQUEST_LIMIT_EXCEEDED で失敗します。有償の本番組織には強制の前にいくらかの超過が認められますが、トライアル組織と Developer Edition にはその猶予がありません。猶予はないものとして設計してください。
設計を確定する前に測る
コードを書く前に、組織の割り当てと現在の 1 日の消費量を管理者から入手してください。REST API にはそのための組織制限リソースがあります。既存の利用者がすでに 70% を使っているなら、レコード単位の同期連携は成立しませんし、チューニングでどうにかなるものでもありません。
一括処理は最適化ではなく設計判断
割り当てが有限で共有されていると受け入れた時点で、設計は自然に決まります。
単一レコードの呼び出しをループで回してはいけません。5,000 件の Contact を一件ずつ作るジョブは 5,000 回を使います。同じ 5,000 件を sObject Collections で 1 リクエストあたり 200 件ずつ送れば 25 回です。この 200 倍という係数が、中規模組織の割り当てに収まる連携と、収まらない連携の分かれ目になります。
作業がリストではなくグラフの形をしているところでは Composite を使ってください。親とその子を一回のリクエストで作れば、往復も、ID を待つあいだにコードが抱える中間状態も消えます。
トランザクションというより読み込みや書き出しに近いものには、Bulk API 2.0 を使ってください。設計上は非同期で、利用者に同期的な答えを返さないので、対話的な経路には向きません。
参照データはキャッシュしてください。選択リストの値、レコードタイプの ID、describe の結果はめったに変わらないのに、毎回意味もなく取り直されています。この一つの変更だけで、素朴に作った連携の呼び出し量の四分の一が消えることがよくあります。
ガバナ制限：あなたの書き込みは他人のコードを動かす
Salesforce は、顧客が書いた Apex を厳格なトランザクション単位の上限の内側で実行します。連携にとって効いてくる Apex ガバナ制限 は、同期トランザクションあたり 100 件の SOQL クエリ、SOQL が取得するレコード 50,000 件、150 件の DML ステートメント、DML が処理するレコード 10,000 件、同期 CPU 時間 10 秒、そしてヒープ 6 MB です。
その Apex を書いたのはあなたではありません。それでもこれらの制限に当たります。あなたの受信側の書き込みが、そのオブジェクトに存在するあらゆるトリガーを走らせるトランザクションを開始するからです。
Apex を書かない人のための一括化
この考え方は、Apex のファイルを一度も開かないとしても理解する価値があります。
Salesforce はトリガーにレコードの コレクション を渡します。一件ではありません。正しく書かれたトリガーは、コレクション全体を一回のクエリと一回の更新で処理します。常に一件だけ受け取る前提で書かれたトリガーは、レコードごとに 一回のクエリと一回の更新を走らせます。
後者のトリガーは何年も完璧に動きます。利用者は画面から一件ずつ保存するからです。そこへあなたの連携が一回のリクエストで 200 件を送ると、トリガーはクエリを 200 回走らせ、100 件のクエリ上限を突き抜け、バッチ全体が失敗します。
Bulk API 2.0 は取り込みデータを 200 件ずつのかたまりで、それぞれ別のトランザクションとして処理するので、これは机上の話ではありません。歴史のある組織への最初の一括ロードでは、これが標準的な形です。
どう手を打つか
納期を約束する前に、書き込む予定のすべてのオブジェクトについてトリガーとフローを監査してください。一括化されていないトリガーがあれば、誰かがそれを直す必要があり、その誰かには Apex の技能とリリース枠が要ります。見積の一項目として計上してください。
修正が範囲外なら、バッチサイズを下げてください。1 リクエストあたり 200 件は上限であって義務ではなく、50 件まで落とせばトリガーの改修を待つあいだに出荷できる余裕が生まれることがあります。割り当てを食うので、暫定措置として扱ってください。
来年も動く認証
この領域は大きく変わっており、公開されている手引きの多くはもう正しくありません。
OAuth 2.0 のユーザー名とパスワードのフローは、避けるべきものです。資格情報をリクエストに直接さらしますし、新しい組織では Salesforce が既定でこれを遮断しており、接続アプリケーションでの廃止も予定されています。まだこれを使っている連携には、日付の入った移行計画が必要です。
人が介在しないサーバー間の処理では、いまの答えは二つです。証明書でアサーションに署名する JWT ベアラーフローと、コンシューマ鍵とシークレットをトークンに交換するクライアントクレデンシャルフローです。統合ユーザーとクライアントクレデンシャルで REST API を呼び出す という Salesforce の手引きは、このフローがリフレッシュトークンを発行しないことを明示しており、古いトークンが期限切れになったらクライアントが新しいアクセストークンを要求します。
接続アプリケーションと外部クライアントアプリケーション
これらを収める入れ物は、かつては接続アプリケーションでした。いまは外部クライアントアプリケーションです。Salesforce は Spring ‘26 以降、接続アプリケーションの作成が制限される とはっきり述べ、代わりに外部クライアントアプリケーションを推奨し、それをセキュリティを高めパッケージングの問題を解決するために設計された新世代だと説明しています。
連携の手順書に「接続アプリケーションを作成する」と書いてあるなら、それは新しい組織では提供されないかもしれない経路を説明しています。作業を見積もる前に、対象の組織にどちらが当てはまるかを確認してください。
専用の統合ユーザーで動かし、更新を計画に入れる
連携には、最小アクセスで API 専用のプロファイルを持つ専用ユーザーを与えてください。特定の従業員として動かしてはいけません。その従業員が退職してアカウントが無効化された瞬間、連携は止まります。最悪のタイミングで、どこも指していないエラーとともにです。
証明書は期限切れになり、シークレットは更新されます。どちらもその日が来るまでは静かで、どちらも連携を部分的にではなく完全に停止させます。期限は人が持つカレンダーに入れ、資格情報はシークレット管理に置き、本番で必要になる前にサンドボックスで更新手順を試してください。
データモデルの罠
ここは三週間を失う箇所です。取り消すにはコードではなくデータを動かすことになるからです。
Lead、Contact、Account、Person Account
Lead は、まだ会社レコードに結びついていない未認定の見込み客です。Contact は Account に紐づく人です。Account は組織です。変換は Lead を Account と Contact に変え、必要なら Opportunity も作りますが、SOAP の convertLead 呼び出しは変換先の空の項目だけが上書きされると明示しているので、丁寧に埋めた Lead の項目が期待どおりの場所に届くとは限りません。
Person Account はこれをさらに複雑にします。消費者向けの組織はこれを有効化して個人を Account と Contact の複合として表現するので、法人 Account モデルを前提に書かれた連携は、それを使う組織ではそのままでは動きません。これは気の滅入るほどの規則性で、遅れて発覚します。
受信したレコードがどのオブジェクトになるのかは、事業側と書面で決めてください。技術的な判断ではありません。
外部 ID と upsert
これは Salesforce が与えてくれる唯一まともな冪等性の仕組みであり、交渉の余地はないものとして扱うべきです。オブジェクトに外部 ID として指定したカスタム項目を作り、そこに自分のシステムの主キーを入れます。そうすれば upsert 操作、つまり /sobjects/{Object}/{ExternalIdField}/{Value} に対する PATCH が使えます。一致するものがなければレコードを作成し、ちょうど一件一致すれば更新します。一致ゼロは 201、一致一件は 200、複数一致は推測せずに 300 で失敗します。
その帰結ははっきり書く価値があります。upsert があれば、失敗したリクエストの再試行は安全です。なければ、再試行はすべて重複の候補であり、夜間ジョブ中の一瞬の通信断が、日数で測る後始末に変わります。
書き込みで発火するルール
重複ルールは、連携が作るレコードを遮断したり警告したりできます。入力規則は、管理者が設定した条件を満たさないレコードを拒否します。必須項目は出荷から何か月も経ってから追加されることがあり、その時点で、動いていた連携がすべてのレコードで失敗しはじめます。
どれもバグではありません。組織が設定どおりに動いているだけです。誤りは、拒否された書き込みを転送エラーとみなして永遠に再試行することで、正しい対応は項目単位の理由を添えて人に見せることです。同じ種類の話は 外部 API 連携の費用と障害パターン の解説でも別の場所で扱っています。
エラー処理、冪等性、再実行
再実行の仕組みを持たない連携は、手作業のデータ修復に変わります。これは予測ではなく、実際にそうなります。
部分的な成功が通常の状態です。sObject Collections は allOrNone の既定値が false なので、200 件のリクエストが 187 件の成功と 13 件の失敗を個別の理由つきで返すことがありますし、Bulk API 2.0 も同じようにレコード単位の結果を返します。外側の HTTP ステータスだけを見るコードは、レコードを黙って落としながら成功を報告します。
再試行の前に失敗を分類してください。行ロック、タイムアウト、割り当ての枯渇のような一時的な状態には指数バックオフが値します。入力規則違反や必須項目の欠落のような確定的な失敗は、永遠に同じように失敗しますし、再試行は惜しい割り当てを燃やすだけです。
回復不能なレコードは、ペイロードとエラーを添えてデッドレターの保管先に送り、人が確認して再送できるようにします。書き込みが外部 ID を鍵にしている以上、再送は安全です。自分の識別子と Salesforce の ID の対応は両側でログに残してください。半年後、ある顧客のレコードがなぜ間違っているのかを説明できるのは、そのログだけです。
そして突合してください。プラットフォームイベントと変更イベントはイベントバスに 72 時間保持され、Salesforce の プラットフォームイベントの割り当て は 1 日の配信を Enterprise で 25,000 件、Unlimited と Performance で 50,000 件に制限しています。レコード件数と更新日時を定期的に比較すれば、ストリームが落としたものを捕まえられます。
ミドルウェアか直結か
点と点をつなぐ直結は、プラットフォームベンダーが認めるより多くの場面で正解です。一つの源、一つの宛先、一方向、控えめな量、安定した契約。それなら直接作って、ライセンスは省いてください。
ミドルウェアが費用に見合うのは、構成が一本の線でなくなったときです。複数のシステムがデータを交換する、業務側の担当者がリリースなしで変換を変えたい、独立に故障するシステムをまたいで調整が要る、監視と再試行を中央に集める本当の必要がある、といった場合です。
正直に言えば、ミドルウェアは費用を無くすのではなく移すだけです。マッピングも、エラー処理も、運用の知識も引き続き払いますし、そこにライセンスと、二本目のパイプラインと、採用すべき二つめの技能が加わります。ミドルウェアもあなたのコードが呼ぶのと同じ API を呼ぶので、API の割り当ては変わりません。
構成がそれを必要とするから選ぶのであって、コードが減るように見えるから選ぶのではありません。自社開発か既製品かの判断ガイド は下層のシステムについて同じ二者択一を扱っており、CRM と ERP の連携ガイド は複数システムの場合を扱っています。議論ではなく評価をご希望なら、そこが弊社の ソフトウェア開発 の出発点です。
サンドボックス、リリース、API バージョン
サンドボックスで作ってください。本番に対してではなく、本番の設定を共有しない Developer Edition 組織に対してでもありません。壊してくるのは、その設定だからです。
更新が何をするかを理解してください。更新はサンドボックスを本番からの新しい複製で置き換えるので、そこにしか存在しなかったテストデータは消えます。更新を生き延びる必要があるものは、スクリプト化して何度でも流せる形にしなければなりません。チームはたいてい、テスト用データを一週間分失って学びます。
すべてのリクエストパスで API バージョンを明示的に固定し、廃止の方針を把握してください。Salesforce の API のサポート終了方針 は、各バージョンを最低三年間サポートし、サポート終了の少なくとも一年前に顧客へ通知することを約束しています。バージョン 21.0 から 30.0 は Summer ‘25 で廃止され、廃止済みバージョンへのリクエストは 410 Gone を返します。
これは劣化ではなく完全な停止であり、だからこそバージョンの固定は保守計画に属します。同じ規律は自分が公開する API にも当てはまり、それは API バージョニング の記事で扱っています。
英国のデータ保護と CRM のデータ
CRM はほぼ全体が個人データです。氏名、勤務先、電話番号、メールアドレス、会話の記録。それをシステム間で動かすことは、UK GDPR のもとでの取扱いにあたります。
最初の問いは、誰が管理者かです。ICO の 管理者と処理者 に関する手引きは、管理者を取扱いの目的と方法を決める当事者、処理者を管理者に代わって取り扱う当事者と定義しています。代理店があなたのために連携を構築し運用する場合、その代理店はたいてい処理者であり、第 28 条の要件を満たす書面契約は任意ではなく必須です。
二つめは国際移転です。Salesforce の組織も、あいだに入るミドルウェアも英国の外にあり得ますし、ICO の 国際移転に関する手引き は利用できる仕組みと、移転リスク評価が必要になる場合を示しています。署名の前に、データがどこに着地するかを確定してください。
ここから三つの帰結が出ます。必要のない項目は複製しないこと。最小化は法的な要件であると同時に、マッピングの手間も減らします。本番の個人データを、よく考えないままサンドボックスに置かないこと。そして削除が伝播するようにすること。Salesforce で消された連絡先が自社のデータウェアハウスに残っているのは、そのままコンプライアンス上の問題ですし、AI エージェント がそれらのレコードに触れる場合も同じです。
Salesforce 連携の費用
Salesforce はエディションとライセンスの価格を自社の価格ページで公開しており、ここではその数字を引きません。連携の設計を左右するのは定価ではなく、そのライセンスが生む API の割り当てだからです。
以下の数字は Mecanik 自身の英国でのプロフェッショナルサービスの目安であってベンダー価格ではなく、組織がすでに存在し、質問に答えられる管理者がいることを前提にしています。
単純な一方向の連携、つまり Web フォームが外部 ID 付きの Lead を作り、まともなエラー処理が付いたものは、通常 GBP 3,000 から GBP 7,000 です。一つか二つのオブジェクトの双方向同期に、競合解決と突合ジョブを付けたものは、たいてい GBP 15,000 から GBP 40,000 です。Pub/Sub 上のイベント駆動の連携に、再実行、デッドレター処理、監視を付けたものは、おおむね GBP 30,000 から GBP 80,000 に着地します。
成果物に入っているべきもの
推測ではなく事業側と合意した項目単位のマッピング文書。同期するすべてのオブジェクトの外部 ID。デッドレターの保管先と文書化された再送手順を備えたエラー処理。突合ジョブ。組織の割り当てに対する API 消費量の監視と、上限のかなり手前で鳴るアラート。トークン更新、証明書の期限、再実行のための手順書。更新を生き延びるようにスクリプト化されたサンドボックス設定。これらのない連携は、請求書に何と書いてあろうと試作品です。
継続的な費用
監視、年三回の Salesforce リリース、資格情報の更新、そして管理者が黙って行う項目変更のために、月額 GBP 400 から GBP 1,500 を確保してください。ここに予算を付けている組織が、連携が動き続けている組織です。
実際に作るには
ここでの失敗の型は退屈なほど一貫しています。割り当ての発見が遅い、誰も監査しなかったトリガー、Contact であるべきだった Lead、失敗したバッチを再実行する手段がない。四つとも設計時なら防ぐのは安く、本物のレコードが存在してから直すのは高くつきます。
Mecanik は ソフトウェア開発 の一環として Salesforce 連携を構築し保守しており、コードを書く前に組織の割り当て、トリガー、データモデルの監査から始めます。本格的な契約ではなく範囲の決まった連携作業をご希望なら、直接 Web 開発者を採用 することもできます。
よくある質問
Salesforce 連携は 1 日あたり何回の API 呼び出しを使えますか。 エディションとライセンス数によって決まり、割り当ては連携ごとではなく組織全体です。API アクセスのある Enterprise と Professional のエディションは 100,000 回に加えて Salesforce または Salesforce Platform ライセンス 1 件あたり 1,000 回、Unlimited と Performance は 100,000 回に加えてライセンス 1 件あたり 5,000 回、Developer Edition は移動する 24 時間で一律 15,000 回です。
Salesforce では REST API と Bulk API のどちらを使うべきですか。 対話的で量が少なくレコードの形をした処理には REST API を、量が多く非同期の答えで構わない読み込みと書き出しには Bulk API 2.0 を使ってください。その中間にあるものは、1 リクエストあたり 200 件の sObject Collections と 1 リクエストあたり 25 個のサブリクエストを持つ Composite が、どちらも割り当てに対して一回の呼び出しとして数えられ、圧力の大半を取り除きます。
サーバー間の Salesforce 連携ではどの OAuth フローを使うべきですか。 JWT ベアラーフローかクライアントクレデンシャルフローを、API 専用の専用統合ユーザーで動かしてください。ユーザー名とパスワードのフローは新しい組織では既定で遮断され、廃止も予定されているので、新規の実装で使うべきではありません。あわせて、Spring ‘26 以降は接続アプリケーションの作成が制限され、Salesforce は外部クライアントアプリケーションを推奨しています。
Salesforce 連携が大きなバッチのときだけ失敗するのはなぜですか。 ほぼ必ず、一括化されていない Apex トリガーです。Salesforce はトリガーにレコードのコレクションを渡すので、一度に一件受け取る前提で書かれたトリガーはレコードごとにクエリを走らせ、バッチが届いた時点で 100 件の SOQL クエリ上限を超えます。画面から一件ずつ保存する利用者には問題なく動くため、発覚しないまま生き延びます。
Salesforce と連携するのにミドルウェアは必要ですか。 源が一つ、宛先が一つ、一方向で量も控えめなら不要で、直接作るほうが安くて単純です。ミドルウェアが費用に見合うのは、複数のシステムがデータを交換する、業務側の担当者がリリースなしでマッピングを変える必要がある、あるいは調整と再試行を中央に集める必要が出てからです。費用は無くならず移るだけで、API の割り当ても増えません。
コメント