Uber Direct 接続：見積・配送手配・ステータス確認
direct.uber.com → Developer → API credentials でアプリの Client ID と Client Secret をコピーし、Developer ページで別の Customer ID をコピーします。Integration に集荷住所を JSON 文字列で入力し、トークン交換をテストすれば、Uber Direct の配送を依頼できます。
Uber Direct コネクタは、このシステムから Uber Direct の地域配送を依頼するためのものです。配送見積の取得、その見積からの配送作成、配送ステータスの確認、配送のキャンセルができます。ラストマイル配送専用の接続です。Uber Eats マーケットプレイスの注文をこのシステムに取り込むことはせず、メニューや店舗カタログの同期もしません。見積と配送は、ご自身の Uber Direct カスタマーアカウントと集荷住所で実行されます。
前提条件#
- Uber Direct アカウントと、direct.uber.com → Developer へのアクセス。アプリとその API 認証情報はそこにあります。
- direct.uber.com → Developer → ご自身のアプリ → API credentials を開くことができ、そこに Client ID と Client Secret が表示されます。Client Secret は一度しか表示されないため、その場で接続にコピーし、安全な場所に保管する計画を立ててください。
- さらに、direct.uber.com → Developer → Customer ID にある別の Customer ID も必要です。これは Client ID とは異なる値で、接続は両方を異なる用途に使用します。
- 店舗または倉庫の集荷住所を構成要素（番地、市、州、郵便番号、国）で把握していること。接続では個別フィールドではなく、1 つの JSON 文字列として入力するためです。
認証情報の取得#
- direct.uber.com → Developer → ご自身のアプリ → API credentials を開きます。
- その API credentials ページに表示される Client ID をコピーします。
- 同じ API credentials ページに表示される Client Secret をコピーします。一度しか表示されません。今すぐ全文をコピーし、安全な場所に保管してください。接続はこのペア（Client ID と Client Secret）を、スコープ eats.deliveries でアクセストークンと交換します。
- 別途、direct.uber.com → Developer → Customer ID を開き、Customer ID をコピーします。アプリページの Client ID と混同しないでください。Customer ID は Uber Direct のカスタマーアカウントを指し、配送リクエストはそのアカウントで行われます。API パス自体にも含まれます：/v1/customers/{customer_id}/deliveries。
Integration への入力#
- Integration → コネクタマーケットプレイス → Uber Direct → 新規接続 を開きます。
- client_id、必須、Client ID：direct.uber.com → Developer → ご自身のアプリ → API credentials の Client ID を貼り付けます。
- client_secret、必須、Client Secret：同じ API credentials ページの Client Secret を全文貼り付けます。パスワード型のフィールドで、秘密情報として保存されます。一度しか表示されていない点に注意し、記憶ではなく保存したコピーから入力してください。
- customer_id、必須、Customer ID：direct.uber.com → Developer → Customer ID の Customer ID を貼り付けます。これは Client ID ではありません。配送はこのカスタマーアカウントで依頼されます。
- pickup_address、必須、集荷住所（JSON）：集荷住所を 1 つの JSON 文字列として、正確にこの形式で入力します：{"street_address":["20 W 34th St"],"city":"New York","state":"NY","zip_code":"10001","country":"US"}。例の値はご自身の店舗または倉庫の値に置き換えてください。street_address は角かっこの配列であり、引用符はすべて半角の英語引用符である点に注意してください。この住所は配送を依頼する際に必須です。接続テストでは不要です。
- pickup_name、任意、集荷先名称：集荷用に表示される名称。たとえば Merchant や店舗名です。pickup_phone_number、任意、集荷先電話番号：集荷先につながる番号。たとえば +15551234567 です。
接続テスト#
接続テストをクリックします。このテストはトークン交換そのものです。接続は client_id と client_secret を Uber のサインインサービスに送り（付与タイプ client_credentials、スコープ eats.deliveries）、アクセストークンが返れば合格です。トークン交換には副作用がありません。配送を作成せず、何も変更しないため、テストとして使えます。応答にアクセストークンが含まれていない場合、テストは BAD_JSON で失敗します。交換が接続に必要なものを返さなかったということで、ほとんどの場合、Client ID または Client Secret が一致していません。テストは pickup_address を使用せず、customer_id が実際に配送を依頼できるかも確認しません。そのため、住所や Customer ID が間違っていてもテストが合格することがあり、それらの誤りは見積や配送作成の段階で初めて現れます。認証情報を保存する前にテストを実行すると、結果はシミュレーションによる確認のみとなります。実際の認証情報を保存して再テストしてください。
Mapping / テンプレート選択#
Uber Direct は注文 Mapping 不要です。配送を扱い、注文は扱いません。ここで確認するのは、すべてのリクエストが従う配送フローです。まず見積があり、次にその見積から配送を作成します。配送の作成には常に元の見積が伴うため、見積なしの直接作成はありません。集荷は接続の pickup_address JSON から取得され、各リクエストはこのシステムの出荷から配送先住所、連絡先、品目を取得します。有効化前に、実際の見積を 1 件と、ご自身の住所宛てのテスト配送を 1 件実行し、見積価格、JSON から解析された集荷住所、配送先の詳細を出荷と照合してください。
有効化#
有効化後、このシステムの出荷から Uber Direct の配送を依頼できます。接続は必要に応じてトークンを交換し、Customer ID の下で配送を見積もり、承認された見積から配送を作成し、配送ステータスを出荷に保持し、まだ集荷されていない配送をキャンセルできます。無人で任せる前に、最初の実際の配送を Runs / Logs で確認してください。特に最初の見積は重要です。テストでは集荷住所も Customer ID も確認しないためです。
この接続が行わないこと：Uber Eats マーケットプレイスの注文をこのシステムに取り込まず、メニューや店舗カタログを同期せず、配達員の報酬や Uber の請求を代わりに精算しません。この接続経由で送る出荷について、Uber Direct の配送の見積、作成、追跡、キャンセルのみを行います。
よくある質問#
テストが失敗し、アクセストークンが返らない — BAD_JSON
トークン交換でアクセストークンが返らず、接続に使えるものがなかったため BAD_JSON が報告されました。よくある原因は、Client ID または Client Secret が一致していないことです。どちらかのコピーミス、シークレットの切り捨て、または別のアプリの認証情報を使ったことが考えられます。
direct.uber.com → Developer → ご自身のアプリ → API credentials に戻り、同じページからペアをコピーし直してください。Client ID を client_id に、Client Secret を全文、同じアプリのものを client_secret に入力し、再テストします。
テストは合格するが、見積や配送がすぐに失敗する
テストが証明するのは、client_id と client_secret によるトークン交換だけです。pickup_address を使用せず、customer_id も確認しないため、Customer ID の誤りや集荷住所の不備があってもテストは合格し、実際の見積や配送がそのカスタマーアカウントで、その集荷住所から実行されようとした段階で初めて失敗します。
テストでカバーされない 2 つの値を確認してください。customer_id は direct.uber.com → Developer → Customer ID と照合し、pickup_address は入力手順の JSON 形式と 1 文字ずつ照合します。間違っている方を修正し、保存して再度見積してください。
Customer ID を Client ID の欄に入れた、またはその逆をした
2 つの ID は似ていますが、役割が異なり、取得ページも異なります。Client ID はアプリに属し、Client Secret と一緒にトークン交換に使われます。Customer ID は Uber Direct のカスタマーアカウントを指し、配送パス自体に含まれます：/v1/customers/{customer_id}/deliveries。入れ替えると、両フィールドが入力されていてもトークン交換や配送リクエストが失敗します。
各 ID を、それぞれのページから、それぞれの欄に戻してください。Client ID は direct.uber.com → Developer → ご自身のアプリ → API credentials から client_id に、Customer ID は direct.uber.com → Developer → Customer ID から customer_id に入力します。保存して再テストしてください。
テストは合格したのに、集荷住所が原因で配送が失敗する
住所に不備がある場合、これは想定どおりの動作です。接続テストは pickup_address をまったく見ないため、住所の問題を検出できません。住所が使われるのは実際に配送を依頼するときだけであり、そのときに JSON 文字列の形式が崩れていると（street_address が配列ではなく通常テキストになっている、文書から曲がった引用符が貼り付けられているなど）リクエストが止まります。
入力手順の正確な形式で pickup_address を手入力し直してください：{"street_address":["20 W 34th St"],"city":"New York","state":"NY","zip_code":"10001","country":"US"}。値はご自身のものに置き換え、street_address は角かっこの配列にし、全体を通して半角の英語引用符を使い、JSON の前後に余分なテキストを入れないでください。保存して配送を再度依頼します。
Client Secret を失くした — もう表示されない
API credentials ページはそのように動作します。Client Secret は作成された瞬間に一度だけ表示されます。その瞬間を過ぎるとページには値が表示されなくなるため、保存しなかったシークレットをページから読み戻すことはできません。
direct.uber.com → Developer → ご自身のアプリ → API credentials で、同じアプリ用に新しい Client Secret を作成し、今度はすぐにコピーして、接続の client_secret に貼り付け、安全な場所にコピーを保管してください。その後再テストします。接続は新しいシークレットでトークンを交換します。
配送を作成すると、まず見積が必要と言われる
これは Uber Direct の通常フローであり、入力値のエラーではありません。配送は常に見積から作成されます。見積で配送の詳細と価格がまず確定し、作成ステップはその見積を引き継ぎます。見積を省略する別の直接作成の方法はありません。
フローを順番に進めてください。まず出荷の見積を依頼し、見積価格と詳細を確認し、承認してから、その見積から配送を作成します。見積の有効期限が切れている場合は、新しい見積を依頼し、古いものを使い回さず新しいものから作成してください。