EC運営やバックオフィスの自動化を進めようとすると、最後に必ず「APIの利用申請」という壁が来ます。仕組みは作れるのに、キーが発行されない・審査が通らない・そもそも申請窓口が見つからない。私たちも自社ECとAI開発の両方をやってきて、この工程が一番読めないと感じています。この記事では、EC事業者と情報システム担当者が実際に使う主要APIについて、取得の前提・申請の流れ・つまずきやすい点 を一覧できる形でまとめます。
本記事の情報は2026年8月時点のものです。 APIの提供条件・審査基準・料金体系は各社が予告なく変更します（実際、直近1年でShopify・X・Metaは仕組みが変わりました）。実際に申請する際は、必ず各サービスの公式ドキュメントで最新の条件をご確認ください。
API取得は「開発の話」ではなく「事務手続きの話」
最初に押さえておきたいのは、API取得でかかる時間の大半はコードを書く時間ではない ということです。実務で発生するのは次のような作業です。
どのアカウント（管理者権限・契約名義）で申請するかを社内で決める
利用目的・取得するデータ・保管方法を文章で説明する
事業者確認（法人番号・登記情報・電話確認など）を通す
審査の結果を待ち、差し戻しに対応する
発行されたキーの有効期限を管理し、切れる前に更新する
つまり、スケジュールを引くときは「申請してから使えるまで」を工程として入れる 必要があります。ここを見積もらずに開発だけ先に進めると、完成しているのに動かせないという状態が生まれます。
ほぼすべてのAPIに共通する5ステップ
サービスごとに呼び方は違いますが、取得までの流れは概ね共通しています。個別の説明を読む前に、この型を頭に入れておくと迷いません。
開発者アカウントを作る ：通常のサービス利用アカウントとは別枠であることが多く、管理者・契約者本人でないと作れない場合があります。アプリ（連携単位）を登録する ：ここでクライアントID・クライアントシークレットが発行されます。1つの用途につき1アプリが原則です。権限（スコープ）を選ぶ ：読み取りだけか、書き込みも行うか。個人情報を含むかどうかで審査の重さが変わります。審査を受ける ：不要なサービスもありますが、SNS・広告系はほぼ必須です。利用目的の説明と動作の証明（画面録画など）を求められます。トークンを取得して呼び出す ：多くはOAuth 2.0。アクセストークンには寿命があり、リフレッシュトークンで更新し続ける設計が必要です。
難易度をおおまかに整理すると、次のようになります。
難易度 特徴 該当するAPIの例 低（即日〜数日） 管理画面から自分でキーを発行できる。審査なし 楽天RMS、au PAYマーケット、Shopify（自社ストア用）、ヤマトB2クラウド（既存ツール経由） 中（1〜3週間） 申請フォームまたは簡易審査がある Yahoo!ショッピング（注文API）、Qoo10、メルカリShops、Amazon Ads、Google Ads 高（1〜3か月） 事業者確認＋用途審査＋動作証明が必要 Amazon SP-API、Meta／Instagram、TikTok、Microsoft Graph（Teams）、Gmail等の制限付きスコープ
この見立てはあくまで目安で、扱うデータの内容（特に購入者の個人情報）によって重くなります。個人情報に触れる用途は、原則として一段階上の難易度になる と考えてください。
ECモール・カート系のAPI
Amazon SP-API（Selling Partner API）
Amazon出品者向けのAPIで、注文・在庫・出品情報・レポート・FBAなど出品業務のほぼ全域を扱えます。旧MWSの後継で、本記事で扱う中でも申請の重い部類です。
前提 ：Amazon出品アカウント（プロフェッショナルプラン）。申請はプライマリ（主）アカウントのユーザーで行う必要があります。窓口 ：Solution Provider Portal（SPP）。以前のようにセラーセントラル内で開発者登録をする形ではなく、開発者アカウント・アプリ・開発者プロフィールをこのポータルに集約する形に変わっています。流れ ：本人確認（新規開発者は必須。おおむね20分程度）→ 開発者プロフィールの提出（組織の連絡先、必要とするデータアクセス、セキュリティ統制、ユースケース、ポリシー順守の宣誓）→ 「Develop Apps」からアプリを登録 → LWA（Login with Amazon）のクライアントID／シークレットを取得 → 認可してリフレッシュトークンを得る。プライベートとパブリック ：自社の出品アカウントだけで使うならプライベート、他社に提供するならパブリック。パブリックはさらに要件が増えます。
つまずきやすい点 は、権限の単位である「ロール」の扱いです。購入者の氏名・住所といったPII（個人を特定できる情報）を含むロールを要求すると、セキュリティ体制についての説明が厳しく求められます。本当に必要なロールだけを申請する のが通過の近道で、「とりあえず全部」は差し戻しの原因になります。データ保護方針（保管場所・暗号化・アクセス制限・保持期間）を先に文章化してから申請してください。
公式情報：Selling Partner API ドキュメント ／Solution Provider Portal
Amazon Ads API（広告API）
スポンサープロダクト広告・スポンサーブランド広告などの入稿とレポート取得に使います。SP-APIとはまったく別の申請 で、ポータルも別です。ここを混同して時間を無駄にする例をよく見ます。
前提 ：Amazon広告アカウント。代理店として他社アカウントを扱う場合は、対象アカウント側での連携許可が必要です。流れ ：developer.amazon.com でLWAセキュリティプロファイルを作成（クライアントID／シークレットを取得）→ Amazon Ads のパートナーネットワーク側で「API Applications」からAPIアクセスを申請 → 承認後、セキュリティプロファイルとAPIアクセスを紐づける → 認可してリフレッシュトークンを取得。審査期間 ：公式には最大72時間程度と案内されています。SP-APIに比べれば軽い部類です。
つまずきやすい点 は認証情報の多さです。クライアントID、クライアントシークレット、アクセストークン、リフレッシュトークンに加えてプロファイルID （どの広告アカウント・どの国のマーケットプレイスを操作するかの指定）が必要で、これを取り違えると「認証は通るのにデータが空」という状態になります。最初にプロファイル一覧を取得して、扱う対象を確定させてください。
公式情報：Amazon Ads API ドキュメント
楽天 RMS WEB SERVICE
楽天市場の出店者向けAPIです。受注（注文情報）、商品登録、在庫更新、カテゴリ、店舗設定などを扱えます。審査がなく、管理画面の操作だけで即日発行できる 点で、モール系の中では最も導入しやすい部類です。
前提 ：楽天市場への出店とRMSのログイン権限。操作するアカウントにWEB API関連の権限が付いている必要があります。流れ ：RMSにログイン → 「店舗様向け情報・サービス」→「WEB APIサービス」→ 申込と利用規約への同意 → 「利用設定」の「WEB API」から利用機能一覧を開き、使う機能を「利用中」に変更して登録 → serviceSecret を控える → 「ライセンスキーの確認・変更」からライセンスキーを発行。認証 ：serviceSecret とライセンスキーを組み合わせた文字列をBase64エンコードし、Authorizationヘッダーに ESA 形式で付けて送ります。OAuthではありません。
最大のつまずきポイントはライセンスキーの有効期限です。 ライセンスキーは約3か月で失効し、その都度RMSで再発行して差し替える必要があります。自動更新の仕組みはありません。ここを運用に組み込んでおかないと、忘れた頃に受注取り込みが止まります。期限をカレンダーに登録し、担当者と代理担当者を決めておく ことを強くおすすめします。
もう一点、利用機能は使うものを個別に「利用中」にしないと呼び出せません 。「キーは取れたのに特定のAPIだけ権限エラーになる」場合、たいていここの設定漏れです。
公式情報：楽天 RMS WEB SERVICE デベロッパーポータル
Yahoo!ショッピング API
Yahoo!ショッピング出店者向けのAPIです。取得が2段階に分かれている のが特徴で、ここを理解していないと「申請したのに注文が取れない」となります。
第1段階（Client ID の取得） ：Yahoo! JAPAN ID があれば誰でもYahoo!デベロッパーネットワークからアプリケーションを登録し、Client ID（アプリケーションID）を発行できます。「本番環境用」を指定して申し込む 点に注意してください。商品API・在庫APIなどはこの段階で使えます。第2段階（利用申請） ：注文API、問い合わせ管理API、定期購入APIは別途「ショッピングAPI利用申請フォーム」からの申し込みが必要 です。取得済みのClient IDと対象ストアアカウントを指定して申請します。アカウントの紐づけ ：特定のストアでAPIを使うには、申請に使うYahoo! JAPAN IDに、ストアクリエイターProへ従業員として登録されているビジネスIDが紐づいている 必要があります。認証 ：Yahoo! ID連携（OAuth 2.0）。アクセストークンは短命なので、リフレッシュトークンによる更新処理を必ず実装します。
つまずきやすい点 は、まさにこのアカウントの紐づけです。制作会社や外部ベンダーの個人IDで申請してしまうと、後で担当者が変わったときに引き継げません。会社として管理できるIDで取得する ようにしてください。これはYahoo!に限らず、すべてのAPIに共通する原則です。
公式情報：ショッピングAPI導入までの流れ ／各種申請に関するヘルプ
au PAY マーケット API
au PAY マーケット（旧Wowma!）の出店者向けAPIです。出店者用管理画面「Wow! manager」から自分で申請・発行できます。
流れ ：Wow! manager にログイン → 左メニューの「各種お申し込み」→「API利用申請」→ APIキー利用規約に同意 → 「APIキーの発行はこちら」→「キー発行」でAPIキーが発行されます。接続元IPアドレスの登録が必要 ：APIキーだけでは接続できません。呼び出し元サーバーのグローバルIPアドレスを登録する必要があります。APIキーの有効期限は発行日から90日 。期限の10日前に、Wow! manager に登録されている基本メールアドレス宛に通知メールが届きます。
つまずきやすい点は2つ あります。1つはIPアドレス登録で、クラウド上で動かす場合は固定IP（NATゲートウェイ等）を用意しておかないと、IPが変わるたびに接続できなくなります 。もう1つは90日という短い有効期限です。楽天の3か月と並んで、更新運用が前提のAPIだと理解しておいてください。通知メールの宛先が退職者のアドレスになっていないかも確認しておくと安全です。
Qoo10 QSM API
Qoo10の販売者管理ツール「QSM（Qoo10 Sales Manager）」から発行するAPIです。商品登録・在庫・受注などを扱えます。
流れ ：QSMにログイン → 「API Keyの発行/照会」からリクエストを送信。あわせて問い合わせフォームから、カテゴリー「システム」→「API・FTP・QSM権限」を選んで必要事項を記入し、申請します。記入項目 ：販売店ID、商品カテゴリ、API利用目的、API連携する会社名など。利用目的が明確であることが条件 とされています。発行条件 ：出店審査が完了していること、サービスポイント・配送ポイントが全項目で0点以上であること、未処理の注文がないこと。有効期限は1年 。毎年の更新が必要です。
つまずきやすい点 は、店舗運営の状態が発行条件に含まれていることです。ペナルティでポイントがマイナスになっている、未処理の注文が残っている、といった状態だと申請が通りません。先に店舗の運営状態を整えてから申請する という順番になります。API取得のために日々の運用品質が問われるのは、モール系ではQoo10の特徴です。
メルカリShops API
メルカリShopsの出店者向けAPIです。他のモールAPIと違いGraphQL で提供されており、REST前提のツールをそのまま流用できない点に注意が必要です。
前提 ：メルカリShopsの開設。利用にはAPI連携の申請が必要 で、申請なしには使えません。実務での選択肢 ：自社開発せず、すでにAPI連携済みのEC一元管理システム（受注・在庫管理サービス）を経由する方法もあります。連携実績のあるサービスが複数あるため、自社で作るか既存ツールに乗るかを先に判断してください。
公式情報：メルカリShops API リファレンス
Shopify Admin API
Shopifyストアの商品・在庫・注文・顧客などを操作するAPIです。2026年に取得方法が大きく変わった ため、古い解説記事の手順は通用しません。ここは特に注意してください。
変更点 ：2026年1月1日以降、Shopify管理画面から新規のカスタムアプリを作成することはできなくなりました 。既存のカスタムアプリは引き続き動作しますが、新規は「Dev Dashboard」またはShopify CLIで作成します。流れ ：Shopify管理画面 →「設定」→「アプリと販売チャネル」→「アプリを開発」→「Dev Dashboardでアプリを構築」→ アプリを作成 → アクセススコープを設定 → バージョンを作成してリリース → ストアにインストール。自社ストア用の認証 ：Dev Dashboardの「Settings」からクライアントIDとクライアントシークレットを取得し、client credentials grant でアクセストークンをプログラム的に取得します。このトークンは24時間で失効する ため、都度取得する実装が前提です。API種別 ：REST Admin APIは2024年にレガシー扱いとなり、新規開発はGraphQL Admin API が推奨です。バージョン管理 ：APIバージョンは四半期ごとに更新され（2026-07 など）、旧バージョンは順次サポート終了します。年に一度はバージョン更新の作業が発生する 前提で設計してください。
つまずきやすい点 は、旧来の「管理画面でトークンをコピーして固定値で使う」やり方を前提に設計してしまうことです。24時間で失効する以上、トークンを設定ファイルに書いて終わりにはできません。取得・キャッシュ・再取得をひとまとめにした処理を最初から作る のが正解です。
公式情報：Create apps using the Dev Dashboard ／Using the client credentials grant
SNS・広告系のAPI
この分野は審査が本体 です。技術的な難しさより、「何のために・どのデータを・どう扱うのか」を説明しきれるかで通過が決まります。共通して、事業者確認（ビジネス認証）と、権限ごとの用途説明・動作証明が求められます。
Meta（Instagram／Facebook）API
Instagram・Facebookの投稿、インサイト取得、コメント管理、そして広告運用（Marketing API）を扱います。Metaは仕様変更の頻度が高く、記事や書籍の情報が古くなりやすい領域です。
前提 ：Instagramはプロアカウント（ビジネスまたはクリエイター）が必須 です。個人アカウント向けだったBasic Display APIは廃止されています。2つの経路 ：現在のInstagram連携には、Facebookページと紐づけずにInstagramで直接認証する「Instagram APIとInstagramログイン」と、従来どおりFacebookページ経由の「Facebookログイン」の2つがあります。自社1アカウントの運用なら前者が簡単 、複数アカウントをビジネスマネージャで一元管理するなら後者が向きます。流れ ：Meta for Developersでアプリを作成 → ビジネスポートフォリオに紐づけ → ビジネス認証（事業者確認） → 使用する製品（Instagram、Marketing APIなど）を追加 → 権限ごとにアプリレビューを申請 → 承認後に本番利用。アプリレビューで求められるもの ：権限ごとの利用目的の説明、実際に動作している画面の録画（スクリーンキャスト）、テスト用アカウント、プライバシーポリシーのURL。Marketing API ：2026年5月に旧「Ads Management Standard Access」がアクセス階層として再編され、Limited Access と Full Access の2段階になりました。上位のFull Accessには、直近15日間で一定回数以上のAPI呼び出し実績とエラー率の基準を満たすことが条件となります。
つまずきやすい点 は2つです。1つはビジネス認証に時間がかかること で、登記情報や公共料金の請求書などの提出を求められることがあり、数営業日〜それ以上を見込む必要があります。もう1つは「自社アカウントを自社で操作する」だけなら審査不要な範囲がある ことです。自分が管理者である広告アカウント・ページに対する操作は、開発モードのまま試せる範囲があります。まずそこで動くものを作り、外部提供する段階で初めてレビューに出すという順序が現実的です。
公式情報：Instagram Platform ドキュメント
X API（旧Twitter API）
投稿・検索・アカウント情報の取得に使います。この数年で最も条件が変わったAPI で、無料で自由に使えた時代の情報は完全に過去のものです。
流れ ：開発者コンソール（console.x.com）でアカウントを登録 → プロジェクトとアプリを作成 → 認証情報（Bearerトークン、OAuth 2.0のクライアントID／シークレット）を取得。登録時に利用目的の記述を求められます。料金体系 ：2026年に従量課金（pay-per-usage）へ移行 しました。サブスクリプション契約ではなく、クレジットを購入してリクエストごとに消費する方式です。使用状況は開発者コンソールでリアルタイムに確認できます。Enterprise ：大量取得や高度な用途は引き続き個別契約のEnterpriseプランになります。
つまずきやすい点 は、コストが読みにくくなったことです。従量課金では、実装のミス（無限ループ、不要なポーリング）がそのまま請求に跳ね返ります。開発中は必ず呼び出し回数の上限を自前で設ける こと、そして本番投入前に「1日あたり何回呼ぶ設計なのか」を数字で出しておくことをおすすめします。金額の水準は変動するため、投資判断の前に公式の料金ページで最新を確認してください。
公式情報：X API ドキュメント
TikTok API（Marketing API／Content Posting API）
TikTok広告の運用自動化（Marketing API）と、動画の自動投稿（Content Posting API）が主な用途です。主要SNSの中では最も審査が厳しい 部類に入ります。
流れ ：TikTok for Developers に登録 → アプリを作成 → 必要なスコープ（権限）を設定 → サンドボックス環境で実装 → 本番アクセスのレビューを申請。広告系はTikTok Business Center のオンボーディングも必要です。審査で見られる点 ：アプリの目的、セキュリティ、データの取り扱い方針。必要以上のスコープを要求すると差し戻しの原因 になります。高ボリューム用途では事業者確認とデータセキュリティに関する確認も加わります。期間 ：数営業日で済むこともありますが、条件付き承認や追加確認が入ると数週間かかることがあります。余裕を持ったスケジュール を組んでください。
特に注意したいのがContent Posting APIです。 審査を通っていない段階では、APIから投稿した動画が非公開扱いになる 制約があります。「投稿はできたのに公開されない」という現象はバグではなく仕様なので、公開投稿を前提にした企画は審査通過を前提条件として扱ってください。
LINE Messaging API
LINE公式アカウントからのメッセージ配信・自動応答・リッチメニュー操作などに使います。国内EC・店舗運営では利用頻度の高いAPIです。
重要な変更 ：2024年9月4日以降、LINE DevelopersコンソールからMessaging APIチャネルを直接作成することはできません。 LINE Official Account Manager（公式アカウント管理画面）の設定からMessaging APIを有効化することでチャネルが作られます。流れ ：LINE公式アカウントを開設 → LINE Official Account Manager にログイン →「設定」→「Messaging API」→ 利用する → プロバイダーを選択または新規作成 → チャネルが作成される → LINE Developersコンソールでチャネルアクセストークンとチャネルシークレットを取得。プロバイダー ：サービスを提供する事業者の単位です。一度決めると後から変更しづらい ため、部署名や担当者名ではなく法人名で作るのが無難です。費用 ：API自体の利用料はかかりませんが、メッセージ配信数はLINE公式アカウントの料金プランに従って課金されます。
つまずきやすい点 は、Messaging APIを有効化すると管理画面からの一部の手動操作と併用できなくなる機能がある ことです。既存の運用を止めずに移行できるか、事前に確認してから有効化してください。
公式情報：Messaging APIを始めよう
Google Ads API
Google広告のキャンペーン操作とレポート取得に使います。認証情報が2系統必要 という点が独特で、ここでつまずく人が多いAPIです。
開発者トークン ：Google広告のマネージャーアカウント（MCC）から、API Center（ads.google.com/aw/apicenter）で申請します。22文字の英数字で、これがAPIの利用権限そのものです。アクセスレベル ：申請直後はテストアカウントにしか使えません。本番アカウントを操作するには「基本アクセス」の申請が必要 で、さらに大量利用には「標準アクセス」を申請します。申請時には利用目的・ツールの内容・想定利用者を説明します。OAuthクライアント ：これとは別に、Google Cloudでプロジェクトを作り、OAuth 2.0クライアントID／シークレットを発行してリフレッシュトークンを取得します。
つまずきやすい点 は、「開発者トークンは取れたのに本番アカウントで動かない」という状態です。これはアクセスレベルがテスト用のままであることがほとんどで、基本アクセスの申請が別工程であることを知らないと原因にたどり着けません。開発者トークンの申請と基本アクセスの申請は別物 と覚えておいてください。
公式情報：開発者トークンを取得する
YouTube Data API
動画情報の取得、チャンネル管理、アップロードなどに使います。取得自体は簡単で、Google Cloudプロジェクトを作ってAPIを有効化するだけです。
つまずきやすいのはクォータ（利用枠）です。 既定では1日あたり10,000ユニットが上限で、動画のアップロードや検索は1回あたりの消費が大きいため、想像より早く枯渇します。増枠には監査を伴う申請が必要で、承認されるとは限りません。企画段階で「1日に何回・どの操作を行うか」を計算し、クォータに収まるかを確認する のが実務上の必須作業です。
業務基盤系のAPI
Microsoft Graph（Outlook／Teams／SharePointなど）
Microsoft 365の各サービスに横断的にアクセスするAPIです。メール（Outlook）、予定表、Teamsのチャット・チャネル、SharePoint／OneDriveのファイルなどを1つのAPIで扱えます。
流れ ：Microsoft Entra管理センター（旧Azure AD）で「アプリの登録」→ アプリケーション（クライアント）IDとリダイレクトURIを設定 → 「APIのアクセス許可」からMicrosoft Graphの権限を追加 → 必要に応じて管理者の同意 を付与 → クライアントシークレットまたは証明書を発行。2種類の権限 ：ログインしたユーザーの代わりにアクセスする「委任されたアクセス許可」 と、ユーザーのログインなしにバックグラウンドで動く「アプリケーションのアクセス許可」 があります。バッチ処理や常駐サービスは後者です。管理者の同意 ：Mail.Read などの多くの権限は、テナントの管理者による同意が必要です。情報システム部門の承認が事実上の申請工程になります。
つまずきやすい点 は権限の広さです。アプリケーションのアクセス許可で Mail.Read を付与すると、テナント内の全ユーザーのメールボックスにアクセスできてしまいます 。これは情報システム部門が最も懸念する点です。Exchange側のアプリケーションアクセスポリシーで対象メールボックスを限定できるので、申請時に「このポリシーで範囲を絞る」とセットで説明する と話が通りやすくなります。
Teamsについては追加の注意があります。チャットやチャネルのメッセージを取得する一部のAPIは保護されたAPI（protected API）に分類され、利用申請と、用途によっては別建ての課金モデルへの同意が必要 です。「Graphのアプリを作れば全部読める」わけではないので、Teams連携を企画する際は対象エンドポイントの条件を先に確認してください。
公式情報：Microsoft Graph の認証と承認の基本
Google Workspace系（Gmail／Drive／スプレッドシート／GA4）
Microsoft Graphに対応するのがこちらです。取得の入り口はどれも共通で、Google Cloudでプロジェクトを作り、使うAPIを有効化し、OAuth同意画面を設定してクライアントIDを発行します。
ここで決定的に重要なのがスコープの分類です。 Googleはスコープを3段階に分けており、どこに該当するかで必要な手続きがまったく変わります。
推奨スコープ ：審査不要。基本的なプロフィール情報など。機密スコープ（sensitive） ：Googleによる審査が必要。カレンダーやDriveの広い範囲など。制限付きスコープ（restricted） ：審査に加えて第三者機関によるセキュリティ評価 が必要。Gmailの本文読み取りなどが該当し、評価には相応の費用と期間がかかります。
ただし重要な例外があります。 アプリを一般公開せず、自社のGoogle Workspace内部でのみ使う（内部アプリとして構成する）場合、この審査は不要です。社内業務の自動化が目的なら、審査に怯える必要はありません。 逆に、顧客に提供するサービスとしてGmailを読む機能を作る場合は、セキュリティ評価の費用まで含めて事業計画に入れる必要があります。ここの線引きを最初に確認してください。
なお、社内利用ではサービスアカウントとドメイン全体の委任（Domain-Wide Delegation）を使う方法もあり、ユーザーごとの認可操作なしにバッチ処理を組めます。ただし権限が強いので、対象スコープを最小限に絞る運用が前提です。GA4のデータ取得は Google Analytics Data API を使い、こちらは対象プロパティに閲覧権限を付与するだけで動きます。
受注・物流・会計系のAPI
ネクストエンジン API
受注・在庫・商品を一元管理するネクストエンジンのAPIです。複数モールに出店している場合、各モールのAPIを個別に叩くよりネクストエンジンに集約してから1本のAPIで扱うほうが、結果的に工数が少なくなる ことが多くあります。
流れ ：ネクストエンジンID（無料発行フォームから取得可能）を作る → 自分のネクストエンジン環境内でアプリを登録 → クライアントIDとクライアントシークレットが発行される → OAuthで認可してアクセストークンを取得。特徴 ：開発用のIDは無料で発行でき、本契約前に開発を始められます 。Developer Network に開発ガイド・APIリファレンス・チュートリアルがまとまっています。
判断のポイント は、モール各社のAPIを自前で束ねるか、ネクストエンジンのような一元管理システムに寄せるかです。モールが3つ以上なら、集約したほうが安いことが多い というのが実感です。特に本記事で見てきたとおり、モールAPIはキーの有効期限管理だけでも運用負荷が生まれます。
公式情報：ネクストエンジン Developer Network
ヤマト運輸 B2クラウド API
送り状発行システム「B2クラウド」のAPIです。2024年6月から正式に公開され、自社システムから直接送り状を発行し、発行済みデータの連携も自動化できるようになりました。
認証キーの取得 ：ヤマトビジネスメンバーズのB2クラウドメニューから「外部システムとの連携」→「APIアクセス認証キー取得」で発行できます。自社で直接開発する場合 ：申し込みと商談を経て利用内容を確認したうえで、開発環境の提供から本番環境の提供まで3か月程度 を見込むよう案内されています。既存ツール経由 ：受注管理システムやカートシステムがB2クラウドAPI連携に対応していれば、認証キーの登録だけで済みます。
つまずきやすい点 は、「認証キーは自分で取れる」のと「APIを自社開発する」のが別の話であることです。前者は管理画面の操作で完了しますが、後者はヤマト側との調整を含む3か月規模のプロジェクトになります。まずは対応済みの受注管理システムを経由できないかを検討する ほうが、多くの事業者にとって現実的です。なお佐川急便など他社については、公開APIの整備状況が異なるため個別確認が必要です。
公式情報：B2クラウドAPI｜ヤマト運輸
freee API／マネーフォワード クラウド API
会計・請求・人事労務のデータ連携に使います。EC側の売上データを会計に流し込む用途が典型です。
freee ：freee Developers Community でアプリケーションを作成し、OAuth 2.0で認可します。自社利用の範囲なら審査は不要 ですが、連携できる事業所数に上限（20事業所）があります。freeeアプリストアに公開して一般提供する場合は、事前申請と審査が必要になり、上限が解除されます。申請時には利用するAPIとメソッドを権限設定で明示し、不要な権限を持たせない構成にすることが求められます。マネーフォワード クラウド ：提供範囲やプランによって条件が異なるため、契約中のプランで対象APIが使えるかを含め、公式のデベロッパー向け情報と窓口で確認するのが確実です。
公式情報：freee API クイックスタート
取得後に必ず問題になる4つのこと
キーが取れれば終わりではありません。運用に入ってから発生する問題は、だいたい次の4つに集約されます。
キーの有効期限切れ ：楽天は約3か月、au PAYマーケットは90日、Qoo10は1年、Shopifyのクライアント認証情報によるトークンは24時間。更新の期日と担当者を一覧にして管理してください。 止まってから気づくと、受注取り込みの欠落という形で被害が出ます。レート制限 ：多くのAPIには単位時間あたりの呼び出し上限があります。上限に当たったときにエラーで止まるのではなく、待って再試行する処理（指数バックオフ）を最初から入れておきます。仕様変更とバージョン終了 ：ShopifyやMetaのようにバージョンの寿命が明示されているAPIでは、定期的な改修が発生します。作って終わりではなく、年間の保守工数として見積もっておく 必要があります。シークレットの管理 ：クライアントシークレットやアクセストークンは、ソースコードに直接書かない・リポジトリに入れない・共有ファイルに置かないのが原則です。環境変数やシークレット管理サービスを使い、誰がアクセスできるかを決めておいてください。 退職者が持ち出せる状態になっていないかは、定期的に確認する価値があります。
4つ目に関連して、APIキーは必ず会社として管理できるアカウントで取得してください。 個人のアカウントで取得されたキーは、担当者の異動・退職時に引き継げず、最悪の場合は再取得のために審査からやり直しになります。これは技術の問題ではなく、体制の問題です。
実際に取得してみて分かったこと（2026年8月・自社での記録）
ここまでは各APIの申請の流れを整理してきましたが、実際に手を動かすと、ドキュメントに書かれていない場所でつまずきます。2026年8月に当社で Amazon SP-API と Yahoo!ショッピング API を取得した際に実際に詰まった箇所を、そのまま記録として残します。公式ドキュメントを読んでも分からなかった部分 だけを挙げているので、これから申請される方の時間短縮になれば幸いです。
Amazon SP-API：ポータル移行と「ログインできない」問題
最初の壁は、セラーセントラルの開発者向け画面にある「新しいアプリクライアントを追加」ボタンがグレーアウトして押せない ことでした。権限不足でもブラウザの不具合でもなく、これはSolution Provider Portal（SPP）への移行が済んでいない というサインです。旧デベロッパーセントラルは新規のアプリ作成を受け付けなくなっており、先にSPP側でアカウントを作る必要があります。
ログインは北米リージョンに紐づく ：SPPのサインインは北米（amazon.com）側の認証に接続されます。そのため amazon.co.jp の出品アカウントのメールアドレスとパスワードでは「パスワードが違います」と表示されて入れません。 日本の出品アカウントとは別に、開発者用のアカウントを用意する形になります。ここで「パスワードを何度も間違えている」と思い込んで再設定を繰り返すと、時間を大きく失います。「無認可」は権限エラーではない ：SPPに入ろうとすると「無認可 このEメールアドレスはどのアカウントにも関連付けられていません」と表示される場合があります。これは審査に落ちたわけではなく、単にそのメールアドレスでSPPのアカウントがまだ作られていない という意味です。案内どおりに新規作成すれば進めます。本人確認 → オンボーディング → 開発者登録フォーム の3段構えです。本人確認は20分程度。その後の登録フォームで、会社情報・ユースケース・第三者へのデータ提供の有無・外部データソースの利用有無・そしてセキュリティ統制に関する設問 を答えます。セキュリティの設問は「はい」と答える前に文書を用意する ：「役割が定義され、6か月ごとのレビューと24時間体制の通知手順を含むインシデント対応計画を維持していますか」「検出から24時間以内に Amazon のセキュリティ窓口へ報告する手順が含まれていますか」といった設問が並びます。はいと答えるなら、その裏づけとなる文書が社内に必要です。 当社は申請に合わせてインシデント対応計画（役割・検出経路・通知の時限・封じ込めと復旧・6か月レビュー）を1枚に整備しました。設問に合わせて文書を作るのは順序が逆のようですが、結果として運用に必要なものが揃います。要求するロールは最小限に ：在庫と注文の追跡だけであれば購入者の氏名・住所といった個人情報を要求しないため、説明の負担が大きく下がります。当社もこのロールのみで申請しました。
出品アカウントが複数ある場合の構成 も、事前に理解しておくと迷いません。開発者アカウントとアプリは1つで足ります。 そのアプリを出品アカウントごとに認可し、リフレッシュトークンを出品アカウントの数だけ取得する という構成になります。自己認可（自社アカウントでの認可）は1アプリあたり10件までなので、複数店舗でも問題なく収まります。
また、以前は必要だったAWSのIAMロールと署名（SigV4）は現在は不要 で、Login with Amazon のトークンだけでAPIを呼べます。古い記事を参考にするとここで無駄な作業が発生します。エンドポイントは地域別で、日本は極東リージョン（sellingpartnerapi-fe.amazon.com）です。審査は当社の場合、申請の翌日に完了しました。
Yahoo!ショッピング API：電話番号認証とグローバルIP
Yahoo!側で最も時間を取られたのは、APIの技術的な話ではなくYahoo! JAPAN IDの電話番号認証 でした。
ID連携を「利用する」にすると電話番号認証が必須になります。 アプリケーション登録の際、ID連携利用有無は必須項目で、これを利用する設定にすると認証済みの電話番号が求められます。電話番号は1つのIDにしか登録できません。 そのため過去に別のYahoo! JAPAN IDで登録した番号を使おうとすると「他のIDで使用されています」と出て、そこから進めなくなります。番号を持っているIDが分からないと完全に手が止まります。解決の手順 ：その電話番号でログインする（Yahoo! JAPANは電話番号でのログインに対応しています）→ ログインしたIDでSMS認証を設定する → そのうえで電話番号を削除する → 使いたいIDで改めて登録する。ポイントはSMS認証を設定しないと番号の削除ができない ことで、ここに気づくまでが長かった部分です。利用申請はClient IDごとに1件 ：注文API・問い合わせ管理API・定期購入APIを使うための利用申請は、ストアアカウントが複数あっても代表として1つを記入すれば足ります。 店舗ごとに申請する必要はありません。APIリクエスト元のグローバルIPアドレスが必須 ：申請フォームでは、APIを呼び出すサーバーのグローバルIPアドレスを求められます。範囲指定やプライベートIPは受け付けられません。 固定IPのない回線から実行する構成だと、IPが変わった時点でAPIが止まり、再申請が必要になります。固定IPの確保を申請より先に済ませておくべき項目です。 設定完了まで1週間〜10日 ：Client IDの発行自体は即時ですが、注文系・問い合わせ系が使えるようになるまでは日数がかかります。導入スケジュールを引くときはここを見込んでください。
実装で引っかかったのはAPIごとにHTTPメソッドが違う 点です。商品参照APIはGET、在庫参照APIはPOST で、在庫参照をGETで呼ぶと「Requested path is not exist」という404が返ります。エラーメッセージがパスの問題を示すため、URLを疑って原因を探し続けることになりがちです。404が返ったらメソッドを疑う 、と覚えておくと早く抜けられます。
なお、Client ID 1つとリフレッシュトークン1本で複数のストアを扱えます （呼び出し時のストアIDで切り替えます）。店舗ごとに認証をやり直す必要はありません。一方で、Yahoo!ショッピング内の広告（アイテムマッチ・PRオプション）にはAPIが提供されていません。 入札の調整やレポート取得を自動化したい場合は、管理画面の操作かCSVの入出力で組む前提になります。
両方に共通して効いたこと
会社として管理できるメールアドレスで取得する ：個人名のアドレスではなく、窓口用のアドレスで取得しておくと、担当者が変わっても引き継げます。Amazonのセキュリティ設問にも連絡窓口の記入欄があり、ここが個人アドレスだと体制として弱く見えます。申請の前に「データの流れ」と「保管・廃棄」を1枚に書く ：どのデータをどこから取得し、どこに保存し、誰がアクセスでき、いつ消すのか。この1枚があると、複数のAPIの申請フォームをほぼ転記で埋められます。逆にこれがないと、フォームごとに考え直すことになります。認証情報は取得した瞬間に環境変数へ移す ：申請完了画面にクライアントIDとシークレットが平文で表示されるサービスがあります。この画面のスクリーンショットを撮らない 、ファイルやチャットに貼らない、という運用を最初に決めておいてください。シークレットは再発行できますが、どこに残ったか分からない状態が一番厄介です。取得できたら必ず疎通確認スクリプトを1本書く ：認証（トークンが取れるか）・軽い参照（1件取れるか）・目的のAPI（本当に使いたい権限が通るか）の3段で確認します。当社はこの3段目で権限不足を検出できるようにしており、「認証は通るのに目的のデータが取れない」という状態を最初の1回で見つけられます。
申請を通りやすくする書き方
審査があるAPI（Amazon SP-API、Meta、TikTok、Google Ads、Googleの機密スコープなど）では、申請文の書き方で結果が変わります。共通して効くのは次の3点です。
「誰の、どのデータを、何のために」を具体的に書く 。「業務効率化のため」では通りません。「自社が出品する商品の注文情報を取得し、自社倉庫の出荷指示に変換するため」のように、データの流れが追える文章にします。必要最小限の権限だけを申請する 。将来使うかもしれない権限をまとめて要求すると、その分だけ説明責任が増え、通過率が下がります。後から追加申請できるサービスがほとんどです。データの保管と廃棄について書く 。どこに保存し、誰がアクセスでき、いつ消すのか。個人情報を扱う申請では、ここが書けているかどうかが分かれ目になります。
逆に避けたいのは、AIに申請文をそのまま書かせて提出すること です。もっともらしい文章にはなりますが、自社の実態と合っていない記述が混ざると、差し戻しどころか信頼を損ないます。下書きにAIを使うのは有効ですが、データの流れと保管方針は必ず自社の事実に基づいて書き直してください。 この線引きの考え方はECのAI活用と法務リスク｜薬機法・景表法・個人情報・著作権の実務ライン でも扱っています。
よくある質問
API取得は自社でやるべきですか、ベンダーに任せるべきですか
申請とアカウント名義は自社、実装はベンダー という切り分けをおすすめします。キーの名義がベンダー側になっていると、取引を終える際に連携ごと失われます。申請作業自体を手伝ってもらうのは問題ありませんが、アカウントの持ち主は自社であるようにしてください。
審査に落ちたらどうすればいいですか
多くの場合、理由が通知されます。よくあるのは「用途の説明が抽象的」「要求している権限が用途に対して広すぎる」「動作を示す資料が不十分」の3つです。権限を減らして再申請すると通ることが多い ので、まず範囲を絞ってみてください。再申請の回数制限は基本的にありませんが、同じ内容で出し直しても結果は変わりません。
API連携とCSV連携、どちらから始めるべきですか
効果を確かめる段階ではCSVで十分です。CSVの手作業で回してみて、削れる時間と精度が見えてから、その作業をAPIに置き換えるのが安全です。API連携は作るコストより維持するコストのほうが大きい ので、価値が確認できていないものを先に自動化すると負債になります。投資判断の考え方はAI導入の費用と投資判断｜EC企業が予算を決める前に整理すること にまとめています。
複数モールに出店しています。全部のAPIを取るべきですか
おすすめしません。モールが増えるほど、キーの更新・仕様変更対応・障害切り分けの負荷が線形に増えます。3モール以上なら、ネクストエンジンのような一元管理システムに集約してから連携する ほうが、総コストは下がることが多いです。判断の順序としては、まず「どのモールのどの作業に、どれだけ時間を取られているか」を洗い出してから、連携先を決めてください。作業の棚卸しの進め方はEC運営で「まず何にAIを使う？」AI活用の始め方｜現場で効いた最初の一歩 で扱っています。
取得したAPIをAIエージェントにつないでも大丈夫ですか
設計次第です。読み取りだけを任せるところから始め、書き込み・送信・決済に関わる操作は人の承認を挟む のが基本形です。AIが直接注文を確定させたり在庫を書き換えたりする構成は、誤動作したときの被害が大きく、モールの規約上も問題になり得ます。段階的な設計の考え方はECバックオフィスをAIエージェントで動かす｜在庫・受発注の自動化設計 で詳しく扱っています。
API連携の設計からご一緒します
私たちは自社ECをモールと自社サイトの両方で運営しながら、AI活用と業務システムの内製化を進めてきました。だからこそ、どのAPIが取得しやすく、どこで詰まり、取ったあとに何が起きるかを実務として把握しています。「どこから連携すべきか」「自社で取るべきか、既存ツールに乗るべきか」の判断からご相談いただけます。
運用設計と判断に継続的に関わるAI顧問 、担当者が自分で回せる状態を作るAI研修 、組織として定着させるAI組織内製化支援 をご用意しています。取り組み事例はAI活用事例 をご覧ください。ご相談はAI事業のお問い合わせ から承っています。
