このドキュメントでは、ベスト プラクティスのガイドラインについて説明します。詳細については、パフォーマンスに関するヒントをご覧ください。
API を使用するケース
リクエストをプログラムで送信する
ワークフローのすべての部分を自動化する場合でも、ERP（エンタープライズ リソース プランニング）システムへのフックを作成する場合でも、Content API を使用すると、在庫が変更されるとすぐに更新を送信できます。
フィードバックを迅速に入手
Content API では、データフィードが処理された後にメールの概要が送信されるのではなく、すべてのリクエストに対して即座にレスポンスが返されます。大規模なバッチ リクエストの場合、5 ～ 10 秒のレイテンシが予想されます。
商品データを頻繁に変更する場合
Content API を使用すると、急速に動く商品在庫を 1 日に何度も増分更新できますが、データフィードを毎回送信することは現実的ではありません。アップデートが個別に利用可能になった場合は、複数のアップデートが利用可能になってから一括送信するのではなく、個別に送信してください。同様に、更新を一括で利用できる場合は、一括で送信し、個別のリクエストに分割しないでください。
複数のサブアカウントを管理する
新しく作成された Merchant Center アカウントは単一アカウントであり、独自の商品データセットを保持します。ほとんどの場合、この方法で問題ありませんが、アカウントの規模が大きくなるにつれて、商品の管理システムをより複雑にする必要が生じることがあります。このような場合は、マルチクライアント アカウント（MCA）の使用を検討してください。MCA アカウントの API レベルの管理は、Accounts サービスを使用して行うことができます。これにより、サブアカウントのプログラマティックな追加と管理が可能になります。MCA アカウントを取得する方法について詳しくは、こちらをご覧ください。
API の使用にあたっての注意事項
データフィードのように API を使用しないでください
products リソースを使用する場合は、商品フィードの全体を毎日更新しないでください。代わりに、データが実際に変更された商品のみを更新してください。products リソース経由でデータフィードの全体を送信すると、Google とお客様の両方で時間とリソースの消費量が増加します。
API を使用してアップロードした商品情報を定期的に取得しない
特定の Merchant Center アカウントの商品情報を管理する責任がある場合は、products.get メソッドまたは products.list メソッドを使用して Content API から商品情報を定期的にリクエストしないでください。情報をアップロードするクライアントの場合、これらのメソッドは、Content API を使用するソリューションを設計する際に問題をデバッグするのに役立ちます。ただし、このようなクライアントによる商品情報の定期的な取得を目的としたものではありません。ローカル商品データベースなど、商品情報の別のソースが必要です。また、Merchant Center の商品には、そのソースの内容が反映されている必要があります。
データフィードと Content API の両方を使用して商品アイテムを登録しないでください
アイテムの送信に API への切り替えを検討している場合は、商品アイテムの送信にデータフィードを使用していないことを確認してください。両方のメディアでアイテムを送信し続けると、予期しない結果が生じる可能性があります。
API とデータフィードを安全に併用する方法はありますか？
データフィードの操作は、API のデータフィード サービスを使用して行えます。これにより、大規模なデータフィード管理が大幅に容易になりますが、API を使用してフィードと同時に商品を挿入または更新しないでください。予期しない結果が生じる可能性があります。
フィードと API を併用して使用できる方法の例を次に示します。
API からの読み取り専用リクエスト（get または list）の実行: 一部の販売者は、API を使用して商品に関する情報やステータスの更新を取得したいと考えています。これは、商品情報はフィードによってのみ更新されるため許容されます。
API を使用して、サブアカウント（Accounts Service）やアカウント レベルの税金と送料の設定（Accounttax Service と Shippingsettings Service）を管理する。これらはデータフィードで提供できる機能ではないため、API を使用してこれらの機能を管理しても競合は発生しません。
データフィードから API のみを使用するように移行したり、その逆を行ったりするにはどうすればよいですか？
現在データフィードを使用しており、商品の更新に API のみを使用するように切り替える場合は、API を使用して商品データを再アップロードする必要があります。商品サービスを使用して特定の商品を更新すると、API が商品情報を管理するようになります。データフィードから商品を削除したり、データフィード自体を削除したりしても、Merchant Center アカウントから商品情報が削除されることはありません。データフィードまたはデータフィード自体から商品を削除する場合は、データフィードに更新がないことを確認してください。更新がある場合、データフィードが所有権を再取得し、データフィードから商品を削除すると商品が削除されます。
現在、商品情報に API のみを使用していて、商品情報のメインソースとしてデータフィードを使用したい場合は、新しいデータフィードを Merchant Center アカウントに追加するだけで、リストに登録されている商品の所有権が移行されます。API からのみアップロードされた商品で、有効期限が切れる前に削除する必要がある場合は、Merchant Center または API のいずれかを使用して削除する必要があります。
Content API for Shopping を使用して、複数の国を対象に商品をターゲティングするにはどうすればよいですか？
Content API 経由で送信された商品の広告と無料リスティングで複数の国をターゲットにするには、Merchant Center の Content API メインフィードで追加の国を設定するか、products リソースの shipping フィールドを使用して追加の国を追加します。
Content API のプライマリ フィードの設定を変更する方法の例を以下に示します。
詳しくは、複数の国でショッピング広告と無料リスティングをターゲティングするをご覧ください。
クライアント ライブラリが最新の状態であることを確認する
Google クライアント ライブラリを使用して Content API を操作する場合は、選択したプログラミング言語のパッケージ マネージャーを使用して、ライブラリのバージョンが最新であることを確認してください。詳細については、サンプルとライブラリで、選択した言語のデベロッパー ガイドをご覧ください。
ショッピング プログラムごとに表示する商品を管理するには、destinations 属性を使用します。
Content API は、Merchant Center で設定された Content API フィードのデフォルト設定を自動的に採用します。includedDestinations または excludedDestinations 商品属性を使用すると、フィード内または Content API 経由で商品レベルでプログラムへの参加を制御できます。
API フィードで「Google で購入」（旧称: Shopping Actions）などのプログラムに登録されているが、特定の商品を除外する場合は、excludedDestinations 属性を使用して値として Shopping Actions を指定します。エラーがなければ、Merchant Center のデフォルトのフィード設定が上書きされ、その特定の商品アイテムは「Google で購入」（旧称: ショッピング アクション）に表示されなくなります。逆に、フィードがショッピングなどのプログラムに登録されていない場合は、includedDestinations 属性と Shopping_ads を値として使用して個々の商品アイテムを含めることができます。その商品アイテムはショッピング広告に表示されます。
includedDestinations と excludedDestinations の商品属性について詳しくは、ヘルプセンターをご覧ください。
アイテムは期限切れになる前に更新してください
アイテムが有効期限切れになる前に変更されていない場合は、最後の更新から 30 日後、または指定された有効期限がそれより早い場合はその日付に、アイテムを更新して無効化を回避してください。アイテムが変更されていないか、最後に更新された日時を追跡できないために、多くのアイテムを更新する必要がある場合は、すべてのアイテムを同時に更新するのではなく、負荷を複数の日に均等に分散します。
Content API フィードは削除しない（削除すると、商品が表示されなくなる可能性あり）
Content API 経由で channel:online を使用して商品を初めてアップロードすると、Merchant Center に [Content API] という名前の新しいフィードが表示されます。Content API 経由で channel:local を使用して商品を初めてアップロードすると、Merchant Center に新しいフィード（タイトルは [Content API]、サブヘッダーは [ローカル商品]）が表示されます。オンラインまたはローカルの Content API フィードを誤って削除しないようにしてください。削除するフィードに応じて、Content API 経由で Merchant Center に追加したオンライン商品またはローカル商品が削除されます。
custombatch メソッドを使用して、同じサービスに対する複数のリクエストを一括処理する
同じサービスに対して複数の連続リクエストまたは並列リクエストを行うのではなく、必要なすべてのリクエストを含む単一のカスタムバッチ リクエストを作成します。これにより、API エンドポイントへのリクエストのレイテンシは、個々のリクエストではなく、カスタムバッチ呼び出しで 1 回だけ発生します。これは、連続してリクエストを行う場合に特に重要です。
1 つのバッチで 1 つのアイテムに複数の更新を送信しない
これにより、更新の順序が不明確になり、予期しない結果が得られ、競合エラーが発生する可能性があります。
変更のないアイテムの更新を送信しない
商品アイテムが期限切れになる場合を除き、新しい商品アイテム、変更された商品アイテム、削除された商品アイテムのリクエストのみを送信してください。
価格や在庫状況が急速に変化する場合は補足フィードを使用する
商品の価格、在庫状況、セール情報を最新の状態に保つことが難しい場合は、products リソースの補足フィードを使用して、これらの属性のみの更新を送信することを検討してください。補助フィード更新は小規模であるため、特定の期間に商品全体の更新よりも多くの補助フィード更新を行うことができます。これにより、商品の価格と在庫状況をランディング ページと一致させることができます。
商品の価格と在庫状況を更新するもう 1 つの方法は、商品アイテムの自動更新を使用することです。これは、API の更新に加えて使用することで、Merchant Center の情報と商品のランディング ページの情報の不一致を回避できます。ただし、これは商品の価格と在庫状況の正確性に関連する小さな問題を修正することを目的としています。商品アイテムの自動更新は、API を介して正しい情報を提供することの代わりになるものではありません。
リフレッシュ トークンを使用する場合
更新トークンは、認可リクエストの HTTP ヘッダーで返されます。認証に関連する他の情報も多数含まれていますが、アクセス トークンの有効期間は 60 分間しか持続しないため、ユーザーに認証を繰り返し求める手間を省くことができるリフレッシュ トークンが、デベロッパーが取得したい情報であることが多いです。