QRコードAPIガイド：プログラムで生成・管理する方法（2026年版）

QRコードの多くの用途（メニュー用、名刺用、マーケティング用に数十枚）は、QRコード作成ツール各社のダッシュボードでまかなえます。クリックして、URLを貼り付けて、画像をダウンロードする。それで十分です。

QR APIの出番は、ダッシュボードを人がクリックして処理できる範囲を超える量を扱うときです。顧客ごとのコード、注文ごとのコード、他システムとの連携、データベース連動の一括生成などがその典型です。うまく組めば、QR APIは「コードをインフラとして扱う」ことを可能にしてくれます。自社ソフトウェアの中で生成し、管理し、追跡できるようになるのです。

本ガイドでは、QR APIの導入に開発工数をかける価値がある場面、APIが一般的にサポートする操作、動くコード例、各社のAPIを比較する観点を扱います。

30秒でわかる要点

QRコードAPIに投資する価値があるのは、こんなときです。

1. 顧客ごと・注文ごとのコードをプログラムから生成する必要がある（イベントチケット、会員カード、偽造防止用シリアル等）。
2. QRコード生成をより大きなシステムに組み込みたい（CRM、在庫管理、ECプラットフォームなど）。
3. ダッシュボードでの手作業では負担が大きい量を扱う：目安として月に数十枚以上。
4. リンク先を在庫・時間帯・ユーザー行動に応じてプログラムから更新したい。

逆に、APIまでは要らないのは次のような場合です。

1. マーケティング用に数枚あれば十分。ダッシュボードのほうが速いです。
2. コードの中身が変わらず、量も少ない。静的生成ツールで十分です。
3. API連携を実装・保守・監視するエンジニアリング体制がない。

QR APIでよくある操作

ほとんどのQR APIは5〜6個の基本操作を提供します。エンドポイント名はプロバイダーごとに違いますが、基本的な構成は共通しています。

1. 新しいQRコードを生成する。

リンク先のURL（と任意のメタデータ）をプロバイダーへPOSTすると、コードIDとダウンロード可能なQR画像URLが返ってきます。

2. 既存の動的コードのリンク先を編集する。

コードのエンドポイントにPUTまたはPATCHでリダイレクト先を変更します。在庫連動のリンク先、時間帯別の振り分け、A/Bテストなどに有効です。

3. コードの分析データを取得する。

スキャン数、時系列、地域別内訳、デバイス別比率をGETで取得します。ダッシュボード連携やレポーティングに便利です。

4. 既存コードの一覧取得・検索。

アカウント内のコードをページネーション付きで取得し、日付・タグ・リンク先などでフィルタできます。管理UIの実装に役立ちます。

5. コードの削除またはアーカイブ。

DELETEはコードを完全に削除します（コードからリンク先を開けなくなります）。一部のプロバイダーは、削除せず一時停止できる「アーカイブ」という代替手段を用意しています。

6. 一括操作。

多くのプロバイダーがバッチ用エンドポイントを提供しています。一度にN個のコードを作成する、フィルタ条件に一致するコードを一括更新する、多数のコードの分析データをまとめてエクスポートする、といった用途です。これらには独自のレート制限と料金体系が関わります。

認証パターン

QR APIは、概ね次の3種類の認証モデルのいずれかを採用しています。

ヘッダーにAPIキーを指定。 最もシンプルな方式です。すべてのリクエストに Authorization Bearer トークンを付けます。実装は簡単ですが、キーのローテーションと失効管理が課題です。

OAuth 2.0。 やや複雑ですが、複数ユーザーやパートナー連携には適しています。トークンベースで、スコープ管理と有効期限があります。

HMAC署名付きリクエスト。 一部プロバイダーが高セキュリティ用途で採用しています。クライアント側でシークレットとタイムスタンプを使って各リクエストに署名し、リプレイ攻撃を防ぎます。

多くのケースで実際に扱うのはAPIキー方式でしょう。キーは環境変数に保存し、ソース管理には絶対にコミットせず、定期的にローテーションしてください。

コード例

以下の例は、汎用的なQR APIのパターンを使っています。ベースURLは実際にお使いのプロバイダーのエンドポイントに置き換え、フィールド名も合わせて調整してください。

JavaScript（Node.js）でコードを生成：

典型的にはNodeの fetch でJSONをPOSTし、リンク先URL、ラベル、コード種別などを送ります。レスポンスには code_id と image_url が含まれるので、これらを保存して以降の参照に使います。

Pythonでコードを生成：

同等の処理をPythonで書く場合は requests ライブラリで同じJSONペイロードをPOSTします。APIキーは環境変数で扱い、2xx以外のレスポンスでは例外を投げるようにしましょう。

コードのリンク先を更新：

コードのエンドポイントへ新しいリンク先URLを含めたPATCHリクエストを送れば、既に印刷済みのすべてのコードのリンク先が一斉に切り替わります。

スキャン分析を取得：

コードの分析エンドポイントへGETリクエストを送り、必要なら日付範囲をクエリパラメータで指定すると、スキャン数や内訳が返ってきます。

これらはあくまで操作の例です。実際のエンドポイントやリクエスト・レスポンス形式は、必ず各プロバイダーのドキュメントを参照してください。

よくあるAPI用途

実案件のQR API連携で繰り返し登場するパターンを紹介します。

注文単位・顧客単位のコード。

ECでは、注文ごとに固有のQRコードを発行し、その顧客専用のランディングページ（再注文、レビュー依頼、配送追跡など）にリンクさせます。コードはチェックアウト時にAPIで生成し、画像を梱包テンプレートに埋め込みます。

チケット単位・参加者単位のイベントコード。

イベントのチケット管理では、チケットごとに固有のQRコードを発行し、ゲートで認証します。同じAPIで返金・譲渡用のコードや、イベント後フォローアップ用のコードも発行できます。

製品単位のトレーサビリティコード。

製造業や消費財業では、バリアブル印刷で1個ごとに固有コードを付与し、そのロット、原産地、トレーサビリティ情報に紐づけます。FSMA 204やFDA UDIといった一部の規制では事実上の必須事項にもなっています。

店舗・地域単位のコード。

複数拠点を持つ事業者では、店舗ごとにAPIでコードを発行し、リンク先をその店舗のページやチェックインフローに設定します。店舗の開業、閉店、情報更新があれば、APIから一括で反映できます。

在庫連動のリンク先。

小売では、棚札のQRコードを商品ページに飛ばしつつ、セール開始、在庫切れ、新しい商品バリエーションへの切り替えのタイミングでリンク先を変更します。APIが在庫イベントに応じてリンク先を更新する仕組みです。

会員プログラム・特典用コード。

飲食・宿泊業や小売業では、顧客ごとの会員カードに固有のQRコードを載せ、その顧客の会員情報へリンクさせます。APIで新規登録時にコードを発行し、ルーティングのロジックを必要に応じて更新します。

偽造防止コード。

プレミアム商品では、1点ずつに固有のQRコードを付与します。APIがスキャンパターンを追跡し、本来1点しか存在しないはずの「同じ」コードが複数の地点からスキャンされたら、偽造の可能性を検知できます。

レート制限と一括操作

QR APIにはレート制限があります。1秒・1分・1時間あたりに送れるリクエスト数の上限です。

一般的なレート制限の目安：

• 無料・個人プラン：毎分60リクエスト程度。
• 中位の有料プラン：毎分1,000〜10,000リクエスト。
• エンタープライズ：カスタム（毎分10万リクエスト以上、もしくは公正利用ポリシーに基づく無制限が一般的）。

大量生成の選択肢は2つあります。

1. レート制限対応付きの逐次生成。 ループで個別にAPIを呼び出し、429（Too Many Requests）レスポンスが返ったらバックオフします。実装はシンプルで、数千件程度までなら対応できます。
2. 一括エンドポイント。 多くのプロバイダーは、1リクエストでコードの配列を受け付けるエンドポイントを提供しています。大量処理ではこちらが圧倒的に効率的です。

数百万単位のような超大量処理向けには、非同期の一括生成を提供するプロバイダーもあります。ジョブを送信し、完了をポーリングし、結果をCSVでダウンロードする、というフローです。エンタープライズプランでは常に利用でき、下位プランでも提供されることがあります。

Webhookとポーリング

QR APIは通常、スキャンイベントを受け取る方法を2つ提供しています。

ポーリング。 アプリケーションが定期的に分析エンドポイントを呼び出して、新しいスキャンがあるか確認します。実装は簡単ですが、リアルタイム性に欠け、新しいスキャンがないときに無駄な呼び出しが発生します。

Webhook。 スキャンが発生するたび（または設定したスケジュールで）、プロバイダーが自社サーバーのURLにPOSTします。リアルタイムで効率的ですが、サーバー側に公開エンドポイントを用意し、リクエストを検証する必要があります。

リアルタイム用途（イベントチケットの検証、不正検知、顧客への対応を即時に開始する処理）では Webhook が必須です。定期レポーティングが目的なら、ポーリングで十分です。

各プロバイダーのQR APIを比較する

主要なQRプロバイダーはたいていAPIを提供していますが、その成熟度には大きな差があります。

比較すべき観点：

• ドキュメントの質。 サンプル付きでよく書かれたドキュメントは、開発工数を大きく節約してくれます。実際にドキュメントを読み、もっとも単純なケースを実装するイメージが湧くか試してみましょう。
• レート制限。 想定リクエスト数に各社の制限が見合っているか確認します。
• 料金モデル。 コード単位、リクエスト単位、使用量枠付きの月額契約、もしくはこれらの組み合わせ。
• Webhook対応。 リアルタイム用途では必須です。
• 一括エンドポイントの有無。 大量処理を伴う連携の工数を大幅に削減できます。
• SDKの有無。 使用する言語の公式SDKがあれば、導入までの時間が大きく縮みます。
• コードの有効期間に関する方針。 ダッシュボード利用と同じく、課金を止めた場合にコードがどうなるか。

プロバイダー別メモ（執筆時点）：

• Uniqode と qr-code-generator.com（Bitly Inc.）は、機能の幅広さと大企業の要件を満たす品質を備えた成熟したAPIを持っています。価格はその分高めです。
• QR Tiger は、よりお手頃な価格帯でしっかりしたAPIを提供しています。
• QR Cake は有料プランでAPIアクセスを提供しており、ドキュメントとSDKの整備が進行中です。
• BitlyのQR API は、短縮リンクのBitlyを既に使っているなら非常に強力な選択肢です。

導入前に最新のドキュメントと料金を必ず比較してください。APIは変わります。プロバイダー全体像についてはQRコード作成ツールのおすすめ記事を参照してください。

セキュリティで気をつけたい点

QRコードAPIに特有のセキュリティの落とし穴をいくつか押さえておきましょう。

1. APIキーの保管。

キーは絶対にソース管理にコミットしないでください。環境変数、シークレットマネージャー（AWS Secrets Manager、HashiCorp Vault、Doppler）、プラットフォーム標準のシークレット機能を使いましょう。担当者の退職時や、キーが誤って公開されたときには、必ずキーを更新してください。

2. リンク先URLのバリデーション。

アプリのユーザーがQRコードのリンク先を指定できる仕組み（マルチテナントで顧客が自分でコードを作る、など）の場合は、URLを検証してください。任意のリンク先を許可するとオープンリダイレクト攻撃の温床になります。

3. Webhookの署名検証。

Webhookを使う場合、プロバイダーは通常、共有シークレットを使ってペイロードに署名します。受信のたびに署名を検証しなければ、攻撃者がスキャンイベントを偽装できます。

4. 自社側のレート制限。

QRコード生成をエンドユーザーに開放する（顧客向けアプリなど）場合は、自社側でもレート制限を実装しましょう。さもないと、悪意のあるユーザー一人にプロバイダー側のクォータを使い切られかねません。

5. リンク先変更の監査ログ。

パッケージや名刺など、長く使うコードについては、すべてのリンク先変更をログに残しましょう。仮にプロバイダーのアカウントが侵害されてフィッシングURLに書き換えられた場合、監査ログが調査の手がかりになります。

QR APIでよくある失敗

失敗1：QRコード生成を一度きりのセットアップと考えてしまう。 コードは継続的な管理が必要です：更新、アーカイブ、監視。初回の作成だけでなく、運用フェーズまで見据えて作りましょう。

失敗2：レート制限のテストをしない。 ブラックフライデーのキャンペーン中にプロバイダーのレート制限に当たって初めて気づく、というのは最悪のタイミングです。

失敗3：QR画像だけを保存してコードIDを保存しない。 プロバイダーのコードIDは必ず保存してください（後から更新・削除できるように）。画像は単なるキャッシュ済みのレンダリング結果にすぎません。

失敗4：リトライ処理がない。 APIはたまに失敗します。指数バックオフ付きのリトライがないと、一時的な障害がそのまま業務上の障害になってしまいます。

失敗5：Webhookの署名検証を省略する。 署名検証のないWebhookエンドポイントは、誰でも呼び出せる公開URLとなり、送信元を偽装されてしまいます。

失敗6：プロバイダーのドメインをコードにハードコーディングする。 カスタムドメイン（自社のサブドメインをプロバイダーのインフラに向ける）を使えば、印刷済みコードを変えずに将来プロバイダーを乗り換えられます。

失敗7：ステージングURLを指したコードを生成してしまう。 パッケージに印刷したり顧客に配送したコードがステージングURLを指していた、というのは現実的なリスクです。リンク先のバリデーションを必ず入れましょう。

失敗8：URLが変わったときにリンク先を更新し忘れる。 サイトリニューアルでURL構造が変わると、すべての動的コードのリンク先を更新する必要があります。見落としやすいポイントです。

よくある質問

動的QRコードを使うのにAPIは必要ですか？ 必要ありません。多くの動的QRプロバイダーには、API連携なしで多くの用途に対応できるダッシュボードがあります。APIは、プログラムから大量のコードを生成するために使います。

プロバイダーのAPIを使わずにQRコードを生成できますか？ 静的コードなら可能です。qrcode（PythonやJavaScript）、pyqrcode といったライブラリで、外部サービスなしにローカルで静的QR画像を生成できます。リンク先を編集でき、分析機能を備えた動的コードには、プロバイダーが必要です。

QRコードAPIは無料で使えますか？ リクエスト数に制限を設けた無料枠を提供するプロバイダーもあります。多くの有料プランには、APIアクセスが含まれます。コード単価だけでなく、リクエスト単価も併せて比較しましょう。

1つのアプリで複数のQR APIプロバイダーを併用できますか？ 技術的には可能です。各コードは生成元のプロバイダーに紐づくので、複数を併用すると管理が複雑になります。基本的には1社に統一するほうが楽です。

あるQR APIプロバイダーから別のプロバイダーへ移行するには？ 新しいプロバイダーで新規にコードを発行します。古いコードは、削除されるか旧プランの契約が切れるまで、引き続き旧プロバイダーのサーバーを指します。カスタムドメインを使っていた場合は、DNSを新プロバイダーのインフラに向け直すだけで、コードを再生成せずに乗り換えられます。将来の移行に備えられる方法です。

API経由で数百万枚のQRコードを生成できますか？ 可能です。適切なレート制限と一括エンドポイントが用意されたエンタープライズプランで対応します。契約前に、選んだプランが対応していることを必ず確認してください。

QR APIはWebhookに対応していますか？ エンタープライズ層や多くの中位プランでは対応しています。無料・エントリープランでは未対応のことがあります。本番でWebhookに依存する前に、必ず確認しましょう。

QR APIの統合にはどれくらい時間がかかりますか？ シンプルな用途（既存アプリ内でコードを発行する程度）なら数時間。エラー処理、リトライ、監視、Webhook処理まで含めた本番品質の統合には数日。一括処理、カスタムドメイン、SSOまで含むフル機能のエンタープライズ統合では数週間が目安です。

APIに障害が起きたとき、QRコードはまだ機能しますか？ 生成や編集はできなくなります。すでに発行済みのコードは、プロバイダーのリダイレクト基盤が稼働している限りリンク先を開けます。通常、リダイレクト基盤はAPI基盤とは別系統で運用されており、より高い可用性目標が設定されています。

QRコードのサービス基盤を完全に自社インフラだけで動かせますか？ 静的コードなら可能です。主要言語にライブラリがそろっています。リダイレクトと分析を備えた動的コードでも理屈上は自作できますが、実質的に小さなSaaSを自前で運営することになります。ほとんどのチームにとっては、プロバイダーに支払ったほうが安く済みます。

まとめ

QR APIは、人間がダッシュボードで管理できる範囲を超えてビジネスをスケールさせるためのインフラです。パターンはすでにかなり確立されています：生成、更新、分析取得、アーカイブ。自社のニーズに合った成熟度のプロバイダーを選び、ていねいに統合し、コードを継続的に管理するリソースとして扱いましょう。

QR Cakeの料金プランとAPIアクセスについて見る