MakeShop API できることと転記を減らす活用例

MakeShop の API って、結局どの仕事が楽になるんでしょうか。
商品や注文の情報を、別の管理表にも写す。
そんな作業があると、もう少し何とかしたくなりますよね。

「API で連携できます」と言われても、知りたいのはその先です。
運営や制作を担当するなかで、こんなふうに思うことはないでしょうか。

同じ情報を何度も写している。
この作業、そろそろ減らせない？
今の管理表や受注処理を、全部変えないと使えないの？
API が便利なのは分かるけど、うちの業務だと何に使える？

正直、機能の名前だけ並んでいても、使いどころはピンときません。
まず知りたいのは、「いつもの作業の、どの部分を任せられるか」だと思っています。

そこで、毎日の転記と API の話をつなげたくて、この記事を書きました。
運営担当者や制作者の方に向けて、できることを業務の例と一緒に整理しています。
利用の手続きも載せたので、まずは一つ、減らしたい作業を思い浮かべて読んでみてください。

商品・注文・会員の情報を、いつもの業務へ

商品名を別の管理表に写す。
注文を見ながら、配送先を別の画面に入力する。
こうした作業が重なると、入力より確認に時間がかかりませんか。

API 連携を考えるなら、まずはその転記作業が候補になります。
公式の API 一覧で、何を取得・更新できるか見てみます。

対象	できる操作	活用の例
商品	商品情報の取得	商品コードや販売価格を別の一覧へ渡す
注文	注文情報の取得	注文番号や配送情報を受注処理へ渡す
会員	会員情報の取得	会員IDや氏名を顧客管理へ渡す
在庫	在庫情報の更新	外部で管理する在庫数をショップへ反映する

右列は、取得・更新機能から考えられる活用例です。実際の受け渡しには、連携先に合わせた処理が必要です。API の利用登録だけで、転記が自動になるわけではありません。

MakeShopから連携処理へ商品・注文・会員情報を取得し、連携処理からMakeShopへ在庫数を更新する流れ — 情報の取得と在庫の更新では、データが流れる向きが変わります。

注文情報を取り込めれば、受注処理で同じ内容を打ち直す手間を減らせます。渡す情報は、今使っている管理表の列から考えると具体的になります。全部まとめて楽にしたくなりますが、欲張ると話が広がりますね。

利用登録と認証は、入口を間違えやすい

ここは名前で迷いやすいところです。「ショップ構築 / 設定 / API」は旧API用です。GraphQL を使う次世代APIでは、この画面を使いません。

独自に開発する場合と、既存の外部サービスを使う場合では手続きが違います。

独自のシステムを開発する場合は、API自社利用申請が必要です。
既存の外部サービスと連携する場合は、その提供元の案内を確認します。
API自社利用申請は不要です。

次世代APIの対象画面は「ホーム / アプリ管理 / アプリ一覧」です。
対象アプリのインストールで連携が有効になります。

公式マガジンでは、自社のみでのAPI利用は無料と案内されています。
登録後の手順は、手続き完了メールで確認します。

開発担当者が確認する認証情報

ここからは、開発を担当する方向けです。
通常のJSONリクエストでは、次のヘッダーを付けます。送信先は、アプリ開発・公開申請の手続き完了メールで通知されます。

ヘッダー	設定する値
`content-type`	`application/json`
`authorization`	`Bearer` に続けて永続または一時トークン
`x-api-key`	申請後に通知されるAPIキー
`x-timestamp`	Unix時刻。有効期限は1時間で、未来の日時は指定不可

永続トークンは、アプリのインストール時に指定のWebhook URLへ通知されます。
「永続」という名前だと、つい安心したくなりますよね。

アプリをアンインストールすると、永続トークンは失効します。名前だけで「ずっと使える」と考えないようにします。

GraphQL で商品コードと名前を取得する

商品情報には多くの項目がありますが、全部を受け取る必要はありません。欲しい項目をクエリに書くのが GraphQL の特徴です。

商品一覧との照合なら、使う項目に合わせて商品コードや商品名を選びます。
次は、認証を設定したGraphQLクライアントのクエリ欄に貼る例です。

query searchProduct($input: SearchProductRequest!) {
  searchProduct(input: $input) {
    products {
      systemCode
      productName
    }
    page
    limit
  }
}

変数欄には、次のJSONを入れます。

{
  "input": {
    "page": 1,
    "limit": 10
  }
}

page と limit は必須です。この例では1ページ目を最大10件取得します。
全商品を扱うときは、次のページも取得する処理を組みます。

返る商品名は products の中にあります。
画面に並べたいのか、別のデータと照合したいのか。用途を先に決めると、追加で必要な項目も選びやすくなります。

在庫更新は、通知の動きまで決めておく

商品在庫を更新するAPIは updateProductQuantity です。
取得の次は更新も、と進めたくなりますが、在庫数だけでなく、更新に伴う通知も確認します。

「在庫数をそろえたい」という依頼でも、通知まで含めると決めることが増えます。
数字だけの話で済んでほしいところなんですけどね。更新する対象と、更新後に起きてほしい動きをセットで開発担当者に伝えます。

最初の連携は、「毎日写している一覧を一つ減らす」くらいでよいと思っています。
目標が具体的なら、導入後に手間が減ったかも確かめやすくなります。

連携で渡したい情報は、普段使っている管理表から拾えます。
商品コードや注文番号など、転記している列を挙げて開発担当者に渡すと、APIで取得する項目の相談が具体的になります。

この記事の内容は、2026年10月20日時点の公式ドキュメントをもとにしています。

出典

ネットショップのカスタマイズや、カートの乗り換えのご相談は、ネットショップ構築で承ります。