ロジレスAPIをPHPで連携する方法｜OAuth2とデータ取得の実装

ロジレス連携をPHPで行う場合、公式の汎用PHP SDKやプラグインは提供されておらず、OAuth2認証とREST APIをGuzzleなどのHTTPクライアントで自前実装する必要があります。Shopifyや主要モール向けの標準連携で足りる荷主もいますが、自社WMS・BI・会計基盤へ倉庫データを抽出したい場合はPHPによるカスタム連携が現実的な選択肢になります。本記事では、認証フロー、トークン更新（30日有効）、レート制限（1秒1リクエスト目安）、429エラー処理、シークレット管理、標準連携との使い分けまで、2026年7月時点の実装観点で整理します。

EC担当者や社内システム担当のなかには、「ロジレスとPHPをつなぐ公式部品があるはず」と想定している方も多いはずです。一方で、LOGILESS Developersが公開しているのはREST API仕様とOAuth2手順であり、言語別SDKは公式には配布されていません。本記事を読めば、ロジレス（LOGILESS）の全体像とAPI連携の基礎を踏まえたうえで、PHP連携の設計判断と実装の要点を把握できます。最終更新: 2026年7月7日。

ロジレス連携にPHPを使うとは何か（公式SDKは存在しない）

ロジレスのPHP連携は「公式プラグインを入れる」作業ではなく、OAuth2＋REST APIのカスタム開発です。理由としては、LOGILESSが提供するのは開発者向けAPIドキュメントとアプリケーション登録フローであり、PHP専用の公式SDKを配布していないからです。EC-CUBE向けのロジレス連携プラグインは存在しますが、これはEC-CUBEの受注・在庫フローに特化したもので、自社基盤やBIへデータを抽出する汎用連携とは別物です。ここがポイントです。検索で「ロジレス PHP」と調べても、公式の一行インストール型ソリューションは見つかりません。

具体的には、PHP 8.x環境にGuzzle（またはcURL）を組み込み、認可コード取得→トークン交換→API呼び出し→リフレッシュの一連を実装します。ロジレスAPI連携の解説記事で触れているエンドポイント設計とあわせて読むと、PHP側で担うべきレイヤーが明確になります。標準のShopify連携やモールコネクタで要件が満たせる場合は、わざわざPHP連携を新規開発する必要はありません。

なぜ2026年はロジレスAPIのPHP連携が必要になるのか

ECのチャネルが増え、倉庫データを社内の会計・分析・自社WMSへ横断連携したい荷主が増えているため、API経由のカスタム連携需要が高まっています。背景には、モール標準連携だけでは「自社の受注基盤」「既存のPHP製バッチ」「BIダッシュボード」へロジレス上の在庫・出荷実績をそのまま流せないケースがあることがあります。なぜ今この論点が表面化するのかというと、物流DXの推進により、倉庫WMSと社内システムのデータ統合が経営判断のボトルネックになりやすいからです。

• OAuth2LOGILESS APIの認証方式（開発者登録・審査が前提）
  出典: LOGILESS ヘルプセンター
• 30日access_token・refresh_tokenの有効期限（秒数はexpires_inで取得）
  出典: LOGILESS Developers — 認証
• 1 req/秒API設計時の目安アクセス頻度（動的なRate Limitあり）
  出典: LOGILESS ヘルプセンター — Rate Limit

数字で見ると、状況はより明確になります。経済産業省の物流政策でも、荷主・事業者間のデータ連携と可視化が課題として繰り返し言及されています。一方で、ロジレスはShopifyやAmazonなど主要モール向けの標準連携を提供しており、単一チャネル運用ならPHP開発は不要なことも多いです。では、荷主は何から判断すべきでしょうか。まず「標準連携で足りるデータ範囲か」「社内PHPシステムへの抽出が必須か」を整理することが第一歩です。

LOGILESS Developers APIの全体像とPHPの役割

LOGILESS Developers APIは、在庫・出荷・受注など倉庫業務データをHTTPで取得・操作するREST API群であり、PHPはそのクライアント層を担います。利用開始にはLOGILESSアカウント上でアプリケーション登録と審査（おおむね3〜5営業日）が必要で、承認後にクライアントIDとクライアントシークレットが発行されます。PHPアプリはこの認証情報を使い、ユーザーの認可を経てアクセストークンを取得します。

公式SDKはないため、認証・HTTP・リトライはすべてPHPアプリ側で実装する。

1. 社内PHP
   バッチ/アプリ
2. OAuth2
   トークン管理
3. LOGILESS
   REST API
4. 自社DB
   BI/WMS

理由としては、APIの責務が「データ提供」と「認可」に分離されているからです。PHP側では、(1) 認証・トークン保管モジュール、(2) APIクライアント（ページネーション・レート制御付き）、(3) 自社DBやCSVへの変換・投入ロジック、の3層に分けると保守しやすくなります。ロジレスのサービス概要と併せて、自社が触るべきデータドメイン（在庫スナップショット、出荷実績、入荷予定など）を先に決めてからエンドポイントを選ぶのが安全です。

PHPでのOAuth2認証フローの実装手順

PHPでのロジレスOAuth2は、認可URLへリダイレクト→認可コード受取→トークンエンドポイントで交換、の3段階が基本です。認可コードの有効期限は10分と短いため、コールバック受信後は遅延なくトークン交換を行う必要があります。初回セットアップは管理者がブラウザで認可する運用が一般的で、以降は保存したリフレッシュトークンでバッチから更新します。

具体的には、次の疑似コードが実装の骨格になります（エンドポイント名・パラメータはLOGILESS Developers公式ドキュメントに従ってください）。

// 1) 認可URLへリダイレクト（初回または再認可時）
$authUrl = $oauthBase . '/oauth/v2/auth?' . http_build_query([
    'client_id'     => getenv('LOGILESS_CLIENT_ID'),
    'redirect_uri'  => $redirectUri,
    'response_type' => 'code',
    'scope'         => $requiredScopes, // 必要なスコープを公式仕様に合わせる
]);

// 2) コールバックで受け取った認可コードをトークンに交換
$response = $httpClient->request('POST', $oauthBase . '/oauth2/token', [
    'form_params' => [
        'grant_type'    => 'authorization_code',
        'client_id'     => getenv('LOGILESS_CLIENT_ID'),
        'client_secret' => getenv('LOGILESS_CLIENT_SECRET'),
        'redirect_uri'  => $redirectUri,
        'code'          => $authorizationCode,
    ],
]);
$tokens = json_decode($response->getBody(), true);
// $tokens['access_token'], $tokens['refresh_token'], $tokens['expires_in']

一方で、認可時にマーチャントや店舗を指定すると、アクセストークンで参照できるデータ範囲を制限できます。倉庫データ抽出だけを目的とする場合は、必要最小限のスコープと店舗範囲に絞るとセキュリティリスクを下げられます。では、具体的な次の一手は次のとおりです。まずステージング用アプリケーションを登録し、コールバックURLが本番・開発で衝突しないよう分離してください。

組織ID・merchant_id・店舗IDはどこで確認するか

PHPでロジレスAPIを実装する際、組織ID（organization_id）、merchant_id、店舗ID（store_id）はLOGILESS管理画面の開発者コンソールまたは組織設定から確認し、環境変数としてPHPアプリに渡します。理由としては、APIリクエストのパスやクエリにこれらのIDが含まれ、誤ったIDを指定すると別テナントのデータにアクセスしようとして認可エラーになるからです。EC-CUBE向けロジレス連携プラグインでも、同様に組織IDとAPI認証情報の設定が前提になっています。ここがポイントです。複数ブランド・複数Shopify店舗を運用する荷主は、店舗IDごとにトークンまたはスコープを分離する設計を検討してください。

PHPの.envに置くべき設定項目の例

まとめると、ID類をハードコードせず環境ごとに分離することが、ステージングと本番の取り違え事故を防ぐ第一歩です。APIエンドポイントの詳細はLOGILESS Developersを参照してください。

アクセストークンとリフレッシュトークンの保存・更新（30日有効）

ロジレスのaccess_tokenとrefresh_tokenはいずれも有効期限が30日であり、PHP連携では期限前の自動更新と安全な永続化が必須です。expires_in（秒）を受け取った時点から逆算し、有効期限の数時間前にリフレッシュするバッチをcronで回す設計が一般的です。トークンを平文でソースコードやGitリポジトリに置かないことは、後述のセキュリティ章でも改めて述べます。

// リフレッシュトークンによる更新（バッチから定期実行）
function refreshAccessToken(HttpClientInterface $client, array $stored): array
{
    $response = $client->request('POST', $oauthBase . '/oauth2/token', [
        'form_params' => [
            'grant_type'    => 'refresh_token',
            'client_id'     => getenv('LOGILESS_CLIENT_ID'),
            'client_secret' => getenv('LOGILESS_CLIENT_SECRET'),
            'refresh_token' => $stored['refresh_token'],
        ],
    ]);

    $new = json_decode($response->getBody(), true);
    // DBやシークレットストアへ暗号化保存。expires_at = now + expires_in
    return $new;
}

なぜ30日という期限が影響するのかというと、リフレッシュに失敗した状態で夜間バッチが走ると、在庫・出荷データの取り込みが丸ごと止まり、翌朝の業務判断に穴が開くからです。ここがポイントです。トークン更新の成功・失敗を監視アラートに載せ、失敗時は管理者への再認可フロー（ブラウザ認可）を手順書にしておくと復旧が速くなります。マーチャント単位でトークンを分ける場合は、テナントIDをキーにしたトークンテーブルを用意してください。

レート制限と1秒1リクエストの設計指針

LOGILESS APIには動的なRate Limitがあり、システム設計時はおおむね1秒に1リクエスト程度を目安にアクセス頻度を抑えるべきです。閾値は負荷状況により変動するため、固定値をコードにハードコードせず、レスポンスヘッダのX-RateLimit-Limit・X-RateLimit-Remaining・X-RateLimit-Resetを参照して制御するのが望ましいです。PHPバッチで数千件を一気に同期しようとすると、429や一時ブロックの原因になります。

// シンプルなスロットリング（1 req/sec 目安）
function throttle(): void
{
    static $lastCall = 0.0;
    $minInterval = 1.0; // 秒
    $elapsed = microtime(true) - $lastCall;
    if ($elapsed < $minInterval) {
        usleep((int)(($minInterval - $elapsed) * 1_000_000));
    }
    $lastCall = microtime(true);
}

// API呼び出しループ内で毎回 throttle() を実行

理由としては、倉庫データの全件同期はページネーションで分割取得が前提だからです。1リクエストあたりの件数とオフセットをログに残し、途中失敗から再開できるようチェックポイントを設計すると、レート制限下でも安定します。大量初回同期と日次差分同期でスケジュールを分けるのも有効です。具体的には、初回は夜間帯に分割実行、日中は差分のみ、という運用が現場では多いです。

HTTP 429エラーの検知とリトライ処理（PHP実装）

Rate Limit超過時、LOGILESS APIはHTTP 429 Too Many Requestsを返すため、PHPクライアントは指数バックオフ付きリトライを実装する必要があります。429受信後は即座に同一リクエストを連打せず、X-RateLimit-Resetが示す時刻まで待機するか、Retry-Afterヘッダがあればそれに従います。ジッター（ランダムな待機時間）を加えると、複数ワーカーが同時リトライして再び429になる「同期リトライ」を防げます。

function callLogilessApi(callable $request, int $maxAttempts = 5)
{
    $attempt = 0;
    while (true) {
        try {
            return $request();
        } catch (ClientException $e) {
            if ($e->getResponse()->getStatusCode() !== 429 || ++$attempt >= $maxAttempts) {
                throw $e;
            }
            $headers = $e->getResponse()->getHeaders();
            $waitSec = 60;
            if (!empty($headers['Retry-After'][0])) {
                $waitSec = (int)$headers['Retry-After'][0];
            } elseif (!empty($headers['X-RateLimit-Reset'][0])) {
                $waitSec = max(1, (int)$headers['X-RateLimit-Reset'][0] - time());
            }
            // フルジッター: 0〜waitSecの乱数待機
            usleep((int)(mt_rand(0, $waitSec * 1_000_000)));
        }
    }
}

まとめると、429は「障害」ではなく「流量調整のシグナル」として扱うべきです。ログに429発生回数・待機時間・エンドポイント名を記録し、週次で閾値に近いかを確認すると、バッチ設計の見直しタイミングが分かります。システム全体への影響が疑われる持続的な429は、LOGILESSサポートへの問い合わせが必要になる場合もあります。

倉庫データ抽出のPHP連携アーキテクチャ例（栃木県上三川町の実務）

ソネッティークの栃木県上三川町倉庫では、ロジレスAPIへPHPで接続し、在庫・出荷データを社内分析基盤へ抽出するカスタム連携を構築しています。標準のモール連携だけでは、荷主ごとに異なる社内PHPシステム（受注管理、原価計算、KPIダッシュボード）へロジレス上の実績を渡せないケースがあったためです。API連携の詳細なエンドポイント選定はロジレスAPIの解説記事を参照しつつ、本番PHPでは認証・スロットリング・リトライを共通化したサービスクラスにまとめています。

なぜこの5層に分けるのかというと、認証ロジックと業務ロジックを分離しないと、エンドポイント追加のたびにトークン処理がコピペされ、セキュリティとレート制御が破綻しやすいからです。一方で、BIツールがコネクタを持つ場合はPHPを介さず直接APIを叩く選択もあります。荷主の既存資産がPHP中心なら、上記構成が保守コストと相性がよいです。

PHPカスタム開発が必要なケースと不要なケース

ロジレス連携でPHPカスタム開発が必要なのは、自社PHP基盤・レガシーバッチ・独自WMSへのデータ抽出が要件にあるときです。逆に、ShopifyやAmazon・楽天などロジレスが標準サポートするモール連携だけで受注〜出荷が完結する場合、PHPによるAPI連携は不要なことがほとんどです。EC-CUBE利用店が公式（EC-CUBE向け）プラグインで足りる場合も、汎用PHP SDKがなくても問題ありません。

比較軸	標準モール／Shopify連携	PHPカスタムAPI連携
主な用途	受注取込・在庫同期・出荷指示	社内システム・BI・会計へのデータ抽出
開発コスト	設定中心（低）	OAuth2・バッチ・監視の実装（高）
公式PHP SDK	該当なし（モール側連携）	なし（自前実装）
レート制限対応	ロジレス側が吸収しやすい	自社PHPで1 req/sec等を設計
向く荷主	単一〜複数モールの販売が中心	社内PHP資産・分析基盤が既にある

具体的には、次の条件に2つ以上当てはまるならPHP連携を検討してください。（1）社内にPHP製の受注・在庫バッチがある、（2）ロジレスデータを会計・原価システムへ日次連携したい、（3）モール非対応の独自販路がある、（4）標準連携では取得フィールドが不足する。当てはまらない場合は、まずロジレスの標準機能で足りるかを確認するのが費用対効果の高い進め方です。

クライアントシークレットとトークンの安全な管理方法

ロジレス PHP連携では、client_secret・access_token・refresh_tokenを環境変数またはシークレットマネージャに保管し、リポジトリやログに出力しないことが最低要件です。理由としては、これらの値が漏洩すると第三者が倉庫データへアクセスできるため、情報漏えい事故に直結するからです。本番と開発でアプリケーション登録を分け、開発用トークンが本番データに触れないようマーチャント範囲も分離します。

一方で、PHPのvar_dumpや例外スタックトレースにHTTPリクエスト全文が含まれるデバッグ設定は本番で無効化してください。監査のため「誰がいつAPIを叩いたか」は、トークン本体ではなくアプリケーションID・ジョブ名・件数で記録するのが安全です。

Shopify・モール標準連携とPHP API連携の使い分け

Shopifyや主要モール向けのロジレス標準連携は「販売チャネルと倉庫の同期」に最適化されており、社内PHPシステムへの任意データ抽出とは目的が異なります。標準連携を維持しつつ、分析だけPHP APIで行う併用も可能ですが、同一データの二重同期には注意が必要です。なぜなら、在庫数の更新経路が複数あると、どちらが正であるかの整合性管理が難しくなるからです。

具体的には、受注・出荷のマスターデータは標準連携に任せ、PHP API連携は読み取り専用（GET系）に限定するパターンがトラブルが少ないです。書き込み（在庫調整やマスタ登録）までPHPで行う場合は、モール側の更新と競合しないよう更新順序とロック設計が必要になります。EC-CUBE公式プラグインを使う店舗は、EC-CUBE内の更新を正とし、PHP APIは補助に留める判断も現実的です。

ロジレス PHP連携の実装チェックリスト（公開前）

ロジレス連携のPHP実装を本番投入する前に、認証・レート制限・監視・セキュリティの4領域をチェックリストで確認してください。審査済みアプリケーションか、トークンリフレッシュが自動化されているか、429時にバッチが自己修復するか、シークレットが安全な保管場所にあるかが要点です。

株式会社ソネッティークは栃木県上三川町を拠点に、ロジレスを含むEC物流の運用とAPI連携の設計支援を行っています。ECフルフィルメントの委託とあわせ、社内PHPとの連携要件の整理もお問い合わせからご相談いただけます。

まとめ：ロジレス連携PHPはOAuth2＋RESTの自前実装が前提

ロジレス連携をPHPで行う場合、公式の汎用SDKはなく、OAuth2認証・30日トークン管理・1秒1リクエスト目安のレート制御・429リトライを自社で実装する必要があります。Shopifyやモール標準連携で足りる範囲ならPHP開発は不要ですが、社内PHP基盤やBIへ倉庫データを抽出する場合はカスタム連携が有効です。全体像はロジレスの解説ページ、APIの詳細はAPI連携記事もあわせてご確認ください。

参考・出典

• 経済産業省 — 物流政策（データ連携・可視化の政策方針）
• 国土交通省ほか — 物流効率化法 理解促進ポータルサイト