このドキュメントでは、ベスト プラクティスのガイドラインについて説明します。詳細については、パフォーマンスに関するヒントをご覧ください。
API を使用するケース
プログラムでリクエストを送信するには
ワークフローのあらゆる部分を自動化する場合でも、ERP（企業資源計画）システムと連携する場合でも、Content API を使用すると在庫の変更と同時に更新を送信できます。
フィードバックをすぐに受け取るため
Content API では、データフィードの処理後に概要説明メールではなく、すべてのリクエストに対するレスポンスが即座に届きます。大規模なバッチ リクエストでは、5 ～ 10 秒のレイテンシが予想されます。
商品データを頻繁に変更するため
Content API を使用すると、変化の激しい商品在庫に対して 1 日に何度も増分更新を行うことができますが、データフィード全体を毎回送信するのは現実的ではありません。更新が個別に利用可能になった場合は、それらを個別に送信し、複数の更新がバッチアップされるまで待たないでください。同様に、更新がバッチで利用できる場合は、バッチで送信し、個々のリクエストに分割しないでください。
複数のサブアカウントを管理するため
新しく作成された Merchant Center アカウントは、独自の商品データのセットを保持する単一のアカウントです。ほとんどの場合はこれで問題ありませんが、アカウントの規模が大きくなるにつれて、商品用のより複雑な管理システムが必要になることがあります。この場合は、マルチクライアント アカウント（MCA）の使用を検討してください。MCA アカウントの API レベルの管理は、アカウント サービスを通じて行うことができ、これによってプログラムによるサブアカウントの追加と管理が可能になります。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 を使用してサブアカウント（アカウント サービス）やアカウント単位の税金と送料の設定（Accounttax Service と Shippingsettings Service）を管理する。これらはデータフィードで提供できる関数ではないため、API を使用してこれらの関数を管理しても競合にはなりません。
データ フィードの使用から API のみの使用（またはその逆）に移行するには、どうすればよいですか？
現在データフィードを使用していて、商品の更新に API のみを使用するように切り替える場合は、API を使用して商品データを再アップロードする必要があります。商品サービスを使用して特定の商品を更新すると、API が商品情報を管理します。データフィードから商品を削除したり、データフィード自体を削除しても、Merchant Center アカウントから商品情報は削除されません。データフィードまたはデータフィード自体から商品を削除する場合は、データフィードが更新されていないことを確認してください。そうしないと、データフィードが再び所有権を得て、データフィードから商品を削除すると、その商品は削除されます。
現在、商品情報には API のみを使用しており、データフィードを商品情報の主要なソースとして使用したい場合、新しいデータフィードを Merchant Center アカウントに追加するだけで、Merchant Center がリストされた商品のオーナー権限を取得します。API のみからアップロードされた商品のうち、期限切れになる前に削除したい商品がある場合は、Merchant Center または API を使用して削除する必要があります。
Content API for Shopping を使用して複数の国に商品をターゲティングするにはどうすればよいですか？
Content API で送信する商品の広告と無料リスティングで複数の国をターゲットに設定するには、Merchant Center の Content API メインフィードで別の国を設定するか、products リソースの shipping フィールドを使用してそれらの国を追加します。
Content API のメインフィードの設定を変更する方法の例を以下に示します。
詳しくは、複数の国のショッピング広告と無料リスティングのターゲット設定をご覧ください。
クライアント ライブラリが最新であることを確認する
Google クライアント ライブラリを使用して Content API を操作する場合は、選択したプログラミング言語のパッケージ マネージャーを使用し、ライブラリのバージョンが最新であることを確認してください。詳しくは、サンプルとライブラリで、選択した言語のデベロッパー ガイドをご覧ください。
掲載先の属性を使用して、さまざまなショッピング プログラムに表示される商品を制御してください
Content API では、Merchant Center で設定された Content API フィードのデフォルト設定が自動的に使用されます。includedDestinations または excludedDestinations 商品属性を使用すると、フィード内で、または Content API を通じて、商品単位でプログラムへの参加を制御できます。
API フィードが「Google で購入」（旧「ショッピング アクション」）などのプログラムにオプトインされていて、特定の商品を除外する場合は、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 エンドポイントにリクエストを行うレイテンシは、個々のリクエストではなく、custombatch 呼び出しで 1 回だけ発生します。これは、連続したリクエストを行う場合に特に重要です。
1 つのバッチで 1 つのアイテムに複数の更新を送信しない
更新の順序が不確実であるため、予期しない結果が生じ、競合エラーが発生する可能性があります。
変更されていない商品アイテムの更新を送信しない
商品アイテムの有効期限が切れない限り、新規、変更、削除された商品アイテムのリクエストのみを送信してください。
価格や在庫状況が急速に変化する場合は補助フィードを使用します
商品の価格、在庫状況、セール情報を最新の状態に保つことが難しい場合は、products リソースの補助フィードを使用して、これらの属性の更新のみを送信することをご検討ください。補助フィードの更新は小規模なため、特定の期間に完全な商品更新よりも多くの補助フィード更新を行うことで、商品の価格と在庫状況をランディング ページと一致させることができます。
商品の価格と在庫状況を更新するもう 1 つの方法は、商品アイテムの自動更新を使用することです。これは、API の更新に加えて、Merchant Center の情報と商品のランディング ページの情報の不一致を回避するために使用できます。ただし、これは商品価格と在庫状況の精度に関する小さな問題を解決することを目的としています。そのため、商品アイテムの自動更新は、API を介して正しい情報を提供する代わりになるものではありません。
更新トークンを使用する場合
更新トークンは認可リクエストの HTTP ヘッダーで返されます。他にも多くの認証情報が含まれていますが、更新トークンを使用すると、アクセス トークンが期限切れになるまで 60 分しか持続しないため、ユーザーに認証を繰り返し要求する必要がなくなります。