QRコードリーダー
QRコード画像をアップロードまたはドラッグ&ドロップして、コンテンツを瞬時にデコードします。
QRコード画像をここにドロップするか、クリックしてアップロード
PNG、JPG、GIF、BMP、WebPをサポート
QRコードリーダーの使い方
- アップロードゾーンをクリックするか、QRコードを含む画像をドラッグ&ドロップします。
- ツールはQRコードを瞬時にデコードし、その内容を表示します。
- コピーをクリックしてデコードされたテキストをコピーするか、URLの場合はリンクを開くをクリックします。
QRコードに含めることができるもの
- URL · ウェブサイト、アプリストア、ソーシャルプロファイルへのリンク。
- プレーンテキスト · 任意のメッセージまたはノート。
- WiFi認証情報 · 自動接続用のSSID、パスワード、暗号化タイプ。
- vCard · 連絡先情報(名前、電話、メール、組織)。
- メール/SMS · 事前に入力されたメールアドレスまたは電話番号。
よくある質問
どの画像形式がサポートされていますか?
PNG、JPEG、GIF、BMP、WebP。ブラウザが表示できる任意の一般的な画像形式。
画像はサーバーに送信されますか?
いいえ。QRコードはJavaScriptを使ってブラウザ内で完全にデコードされます。画像がデバイスを離れることはありません。
スクリーンショットからQRコードを読み取れますか?
はい!スクリーンショット、写真、スキャンされたドキュメントが動作します。QRコードがはっきり見え、ぼやけすぎていない必要があります。
1994年デンソーウェーブの発明と囲碁の盤面
QRコードは1994年に原昌宏によって発明されました。原はデンソー株式会社の開発部門に所属するエンジニアでした(後に分社化されたデンソーウェーブが正式に設立されたのはその後のことです)。QRコードは日本の自動車製造業における具体的な問題を解決するために考案されました。トヨタのリーン生産方式は、かんばんタグと多品種少量生産を重視しており、当時の一次元バーコードでは対応しきれないほど多くのSKUを生み出していました。スーパーマーケットの商品に印刷されるような標準的な線形バーコードが保持できるのは約20文字ですが、自動車部品1点でも注文番号・部品番号・ロット・サプライヤー・工程フラグを追跡する必要があり、作業員は約10個のバーコードを連続して読まなければならず、それに応じた誤読率が生じていました。原は1992年に、一つのシンボルにタグ全体を向きに関わらず高速に収められる二次元コードを設計するよう命じられました。
有名な誕生秘話では、原が昼休みに囲碁を楽しんでいるときにエンコード方式を思いついたとされています。囲碁は白と黒の石を19×19のグリッドに並べる古代のボードゲームです。マトリックスバーコードの白黒のモジュールは本質的に正方格子上の囲碁の石であり、原はこの密な二次元パターンが同じ物理的面積の一次元バーコードよりもはるかに多くの情報を保持できると気づきました。もう一つの課題は向きでした。コードが斜めや逆さまに撮影された場合、スキャナーはどうやってコードの開始点・終了点・天地を知ることができるのでしょうか。原の答えは、すべてのQRコードの3つの角にある3つの同心正方形のファインダーパターンでした。
普通の印刷物と衝突しないパターンを選ぶため、原のチームは数千冊の雑誌・新聞・印刷物を調査し、白黒領域の連長頻度を集計しました。その結果、縞幅の比率1:1:3:1:1(細い黒・細い白・太い黒・細い白・細い黒)が通常の印刷物にほとんど現れないことが分かりました。この比率こそスキャナーが探すものです。カメラが画像内で両軸とも縞幅が1:1:3:1:1に一致する3つの領域を検出すると、それらをQRシンボルの3つの角として確信をもって特定し、そこから透視変換を補正できます。この比率は十分に安定しており、QRコードは曲面・約30度までの角度・一部が隠れていても解読可能です。
オープンライセンスという決断
デンソーウェーブのもう一つの重要な貢献は、技術的なものではなく戦略的なものでした。同社はQRコードの特許を保有し(iQRやSQRCなどの派生品に関する特許登録も続けています)、公開されているJISおよびISO規格に準拠したQRコードの使用についてはロイヤリティ権を明示的に放棄しています。デンソーウェーブがqrcode.comのFAQおよび特許ページで繰り返し述べている公式見解は、ISO/IEC 18004規格に準拠したQRコードの商用利用にはライセンスは不要、契約は不要、料金も不要というものです。「QRコード」という商標は登録されていますが、その基となるマトリックスバーコード自体は自由に使用できます。
これは1994年当時、当然の選択ではありませんでした。当時PDF417の特許を所有していたSymbol Technologies社はロイヤリティを徴収しており、AztecやDatamatrixも初期には同様に権利が絡まった経緯がありました。デンソーウェーブがフォーマットを無償公開するという選択をしたことで、誰でも(プリンターメーカー・携帯電話メーカー・決済ネットワーク・飲食チェーン・接触確認アプリ開発者も)法的な摩擦なしにQRコードを統合できるようになりました。この決断こそが、QRコードがコンシューマー向け応用において二次元バーコード競争に勝利した最大の理由です。
リード・ソロモン誤り訂正:汚れたQRがそれでも機能する理由
QRコードが一部汚れたり破れたり小さなロゴで覆われていても機能し続ける理由は、リード・ソロモン誤り訂正という40年以上の歴史を持つ符号理論技術にあります。リード・ソロモン符号は、Irving S. ReedとGustave Solomon(当時MITリンカーン研究所のスタッフ)による5ページの論文「Polynomial Codes over Certain Finite Fields」で発表されました。この論文はリンカーン研究所の内部報告書として1958年12月に完成し、Journal of the Society for Industrial and Applied Mathematics(第8巻、300-304ページ)に若干修正された形で1960年に掲載されました。ReedとSolomonはもともとSAGE防空システムの研究に携わっており、ノイズの多い通信回線でレーダー信号の整合性を保つ方法を模索していました。彼らの洞察は、データ列を有限体上の多項式の係数として扱い、複数の点で評価することで、受信側は一部の評価が誤っていても多項式を復元できるというものでした。同じ数学がCD・DVD・深宇宙探査機の通信・放送テレビ、そして1994年以降のすべてのQRコードの基盤となっています。
QRコードはユーザーが選択できる4段階の誤り訂正レベルを備えており、それぞれデータ容量と堅牢性のトレードオフが異なります:
- レベル L(低):コードワード復元率 ~7%
- レベル M(中):~15%、実用上の標準
- レベル Q(クォータイル):~25%
- レベル H(高):~30%、驚くほど大きなロゴを貼り付けてもレベル H の QR が機能し続けるほど高い訂正率
訂正レベルを高くする代償は容量の低下です。同じバージョンのQRコードでも、より多くのモジュールがパリティビットに使われるため、レベル H ではレベル L に比べてはるかに少ないデータしか格納できません。
バージョン40での容量:最大値
QRコードには40のバージョンがあります。バージョン1は21×21モジュールです。バージョンが上がるごとに1辺あたり4モジュール増えるため、バージョン2は25×25、バージョン3は29×29、バージョン40は177×177モジュールとなります。最低誤り訂正(L)でのバージョン40の最大ペイロードは次のとおりです:
- 7,089文字の数字
- 4,296文字の英数字(数字・大文字・スペース・一部の記号)
- 2,953バイトの任意バイナリデータ(UTF-8テキストを含む)
- 1,817文字の漢字(Shift JISエンコーディング)
これらの最大値は誤り訂正レベルが上がると急激に低下します。同じバージョン40のシンボルでもレベル H では数字3,057文字・英数字1,852文字・バイト1,273・漢字784文字しか保持できません。実際には数百バイトを超えるQRコードはまれであり、バージョン20程度になるとモジュールが小さくなりすぎて、高解像度カメラのないスマートフォンでは腕を伸ばしただけでは確実に読み取れなくなります。
Datamatrix・Aztec・PDF417:実際に目にするQRの代替コード
- Datamatrix(1980年代後半、ISO/IEC 16022)は、L字型のファインダーパターン一つを持つ、非常に小さなマークに最適化された正方形または長方形のマトリックスバーコードです。小型部品のマーキング(回路基板・外科器具・医薬品の単位投与量)や、EU偽造医薬品防止指令のシリアル化に広く使われており、同指令は2019年以降すべての処方薬箱へのDatamatrix添付を義務付けています。
- Aztec(1995年、ISO/IEC 24778)は、中央のブルズアイ状ファインダーパターンの外見から名付けられており、上から見たアステカのピラミッドを連想させます。クワイエットゾーン(シンボル周囲の余白)が不要という特長があり、紙の搭乗券の隅のような狭いスペースにも収まります。航空電子チケットやヨーロッパの多くの鉄道・交通システムで標準規格となっています。
- PDF417(Symbol Technologies 1991年、ISO/IEC 15438)は、技術的には真のマトリックスコードではなく「積み重ね線形」コードです。複数行の線形バーコードを縦に重ねた構造で、4種類の中でASCIIテキストに対して最も高密度であり、1キロバイト以上のデータを格納できます。米国運転免許証の裏面(磁気ストライプのデータとそれ以上の情報をエンコード)やFedExなどの配送ラベルに使用されています。
この4種の中でQRコードがコンシューマー市場で勝利したのは3つの理由によります。3つの角のファインダーパターンによる全方向スキャン、オープンライセンス、そして1990年代後半における日本の携帯電話業界との緊密な連携により、競合他社に先駆けて大規模なスキャナー普及を実現したことです。
ISO標準化の経緯
QRコードは1999年1月に日本工業規格(JIS X 0510)として最初に公開され、2000年6月に国際規格ISO/IEC 18004として制定されました。ISO/IEC 18004:2006(2006年9月)がこれを置き換え、追加のアライメントパターンを備えた「QRコード2005」(モデル2の小規模な拡張)を定義しました。ISO/IEC 18004:2015(2015年2月)はシンボルの名称を単純に「QRコード」に改め(年号の接尾辞を廃止)、説明を統合し軽微な誤りを修正しました。現行版はISO/IEC 18004:2024、第4版で、2024年8月に発行されました。この規格は他のISO刊行物と同様に有料PDFとして販売されていますが、いくつかのオープンソース実装(特にZXing)が事実上の仕様参照として機能しています。
デンソーウェーブのバリエーション:Micro QR、iQR、SQRC、rMQR
原の1994年の原典仕様は現在モデル1と呼ばれています。モデル2は1997年に定義され、現在一般的に「QRコード」といえばこれを指します。バージョン40まで拡張されており、現代のISO規格の基礎となっています。マイクロQRコードはファインダーパターンが1つだけで、クワイエットゾーンも小さく、狭いスペースに収まります。デンソーウェーブが2011年に発表したiQRコードは、モデル2比で最大80%高い容量を持ち、正方形または長方形で422×422モジュール・数字4万文字にまで対応します。SQRC(セキュアQRコード)は2層構造で、通常のQRスキャナーで読めるパブリック層と、専用リーダーと鍵が必要な暗号化されたプライベート層を備えています。rMQR(Rectangular Micro QR Code)は2022年にISO/IEC 23941として標準化されました。Micro QRとiQRのハイブリッドで、縦より横に長く、ラベルの側面やプリント基板の端など細長いスペースにフィットします。
COVID-19後の急拡大と中国のQR決済文化
2010年代の大半において欧米でのQRコード普及は鈍い状態が続いていました。そこにCOVID-19が到来しました。WHOが2020年3月11日にパンデミックを宣言すると、レストラン・交通ハブ・公共施設はあらゆる場所でメニューの共有・来訪者の記録・支払い処理に非接触の手段を必要とし、QRコードは唯一の成熟したハードウェア不要の非接触手段として活躍しました。2020年半ばまでに、QRコードメニューは米国および欧州のレストランでほぼ普遍的になりました。シンガポールでのQR決済取引量は2021年を通じて前年比約272%の成長を報告されました。これらの利用の多く(特にメニュー)は急性期以降に縮小しましたが、公共の場でQRコードをスキャンする心理的障壁は永久に取り払われました。
QR普及のもう一つの原動力(時系列的には前述より早い)は、中国のモバイル決済エコシステムです。Alipayは2011年にQR決済を導入し、TencentのWeChat Payは2014年に続き、春節の「紅包」機能によって普及を加速させ、ローンチから1か月以内にユーザー数が3,000万人から1億人に拡大しました。2016年には中国のQRコード決済を通じた取引額が1兆6,500億ドルを超えました。現在、Alipayが中国のモバイル決済市場の約53%、WeChat Payが約42%を占め、合わせて約90%に達します。中国のモバイル決済の90%以上がQRコード経由で行われ、人口の約70%が日常的に利用しています。
欧米がネイティブQRスキャン機能を獲得したとき
欧米での普及を促したもう一つの大きなきっかけは、ネイティブカメラへの対応です。Appleは2017年9月にiOS 11をリリースし、そのカメラアプリはデフォルトでQRコードを自動認識できるようになりました。iPhoneがサードパーティアプリなしでQRコードを読み取れたのはこれが初めてです。AppleはWWDC 2017でこの機能を紹介すらせず、公開リリース後にレビュアーたちが発見しました。この変更は初年度で7億台以上のiPhoneに届きました。Googleも追随し、Google Lensは2018年5月にQRサポートを追加し、10のAndroidメーカーのカメラアプリへの展開を開始しました。同年リリースのAndroid 9はネイティブQRスキャンをプラットフォームの標準機能にしました。およそ1年以内に、専用の「QRスキャナー」アプリの時代は事実上終わりを告げました。
クイッシング:QRフィッシングの台頭
パンデミック時にQRコードを便利にした低摩擦なスキャンは、フィッシング攻撃の設計者にとっても魅力的なものになりました。クイッシング(QRコードによるフィッシング)は、メールや印刷されたチラシに埋め込まれたQR画像を使って悪意のあるURLを届けます。URLがコードの内部に隠れているため、リンクテキストを検査する従来のメールセキュリティゲートウェイでは検出できません。また、ユーザーは通常、個人のモバイル端末でスキャンするよう促されるため、攻撃がセキュリティ対策の整った企業ネットワークから(しばしば対策の手薄な)スマートフォンへ移ってしまいます。
その規模は急速に拡大しました。2021年から2023年にかけて、QRコードのスキャン数は433%増加しました。フィッシングメールにQRペイロードを使うものの割合は、2021年の約0.8%から2023年の約12.4%に上昇し、2024年には約10.8%で安定しています。2023年には全フィッシング攻撃の22%にQRコードが使用されていました。クイッシングメールの約27%は多要素認証通知を偽装しており、約90%がログイン認証情報を狙っています。C-suiteの幹部は一般の従業員に比べてクイッシング攻撃を受ける可能性が42倍高いとされています。セキュリティチームが採用してきた防御策はQRペイロードを自動で開かないことです。デコードし、URLをプレーンテキストで確認してから判断する。それがまさに、このような画像ベースのQRリーダーによって慎重なユーザーにもたらされるものです。
デコード時によく見られるURIスキーム
QRコードはバイト列のラッパーに過ぎず、それらバイトの意味は慣習によって決まります。実際に目にするほぼすべてをカバーする少数の慣習があります:
- http: / https: URL、圧倒的に最も一般的。
- mailto: URI(オプションの
?subject=および?body=クエリパラメータ付き)でメールの下書きを作成します。 - tel: URI で電話をかけます。
- sms: URI(およびNTT DoCoMoによって普及した旧来のSMSTO:形式)でテキストメッセージを事前入力します。
- geo: URI で地図を特定の緯度・経度に開きます。
- WIFI: デンソーウェーブが定めた非公式スキームで、形式は
WIFI:S:<SSID>;T:<WPA|WEP|nopass>;P:<password>;H:<true|false>;;です。スマートフォンをワンタップでネットワークに接続させます。ゲストWi-Fiポスターの定番です。 - MECARD:(NTT DoCoMo)、コンパクトな連絡先フォーマット。
- vCard(RFC 6350)、連絡先に関する冗長な国際標準で、サイズにもかかわらず広くサポートされています。
このリーダーはデコードされたペイロードをプレーンテキストで表示します。リンクを開くかテキストをコピーするかはユーザーが判断します。何も自動的に開かれません。
ブラウザベースのデコードの仕組み
ブラウザ側のQRデコードには2つのオープンソースライブラリが主流です。jsQRは、GitHubハンドル名「cozmo」のDaniel Beaverが開発した純粋なTypeScriptポートで、生のImageData(キャンバス・ビデオフレーム・アップロード画像のピクセル配列)を受け取り、デコードされたテキストを返します。依存関係なし、プラットフォーム固有のコードなし、CDNから単一スクリプトタグで配信できるほど軽量です。このツールはjsQRを使用しています。もう一つの主要な選択肢は、もともとJavaのバーコードライブラリだったZXing(「Zebra Crossing」)のJavaScriptポートで、QRだけでなく多くの2Dおよび1Dフォーマットをサポートし、npmに@zxing/libraryと@zxing/browserとして公開されています。
3つ目の方法はプラットフォームネイティブのBarcodeDetector APIです。これはW3C Shape Detection APIの一部で、JavaScriptにブラウザ組み込みのバーコードリーダーを公開します。BarcodeDetectorは2020年5月のChrome 83でデフォルト有効としてリリースされました(Microsoft Edgeも同時に採用)。ただし、このAPIはプラットフォームに依存します。OSレベルのバーコード検出に依存しており、macOS・Android・Chrome on Androidでは完全にサポートされていますが、WindowsとLinuxのChromeは実装していません。FirefoxとSafariは未実装です。多くの本番ブラウザQRスキャナーはjsQRまたはzxing-jsをフォールバックとして使用し、利用可能なときはBarcodeDetectorを呼び出し、それ以外の場合はJavaScriptデコーダーを使用します。
よくある質問
スマートフォンで直接スキャンせずにこのツールを使う理由は?
3つの実質的な理由があります。(1)QRコードがすでにコンピューター上の画像の中にある場合(メールのスクリーンショット・ダウンロードしたポスター・PDFページなど)、スマートフォンに転送してスキャンするのは手間がかかります。(2)QRコードが怪しいと思われ、リンクを開く前にURLを確認したい場合(クイッシング対策のユースケース)。(3)自分でQRコードを生成し、スマートフォンのカメラを経由せずにペイロードを確認したい場合。
確実にスキャンできる最小のQRコードのサイズは?
おおよそ、誤り訂正レベル H のバージョン1(21×21モジュール)、1cm × 1cm 以上の印刷サイズ、十分な照明の下で腕を伸ばして読み取る条件です。それ以下になると、多くのスマートフォンカメラでは解像度が不足します。印刷物の目安として、QRコードの辺の長さは期待するスキャン距離の少なくとも1/10が必要です。5cmのコードは約50cm先からスキャンできます。
画像がデコードできません。どうすればよいですか?
QRコードに密着するようにトリミングし(背景の雑然としたものを除去)、コントラストを上げ(非常に薄いコードはデコードが難しい)、極端なパースの歪みを避け(~30°以上になるとパース補正ステップが劣化します)、3つの大きな同心正方形のファインダーパターンが損なわれていないか確認してください。3つの角のファインダーが1つでも欠けているか遮られていると、デコーダーは向きを判定できません。QRコードの中央にロゴが埋め込まれている場合でも、元のコードがレベル Hの誤り訂正で生成されていれば機能するはずです。
このQRコードのURLは安全に開けますか?
このツールはURLをデコードしますが、その安全性は判断しません。ドメインをよく確認してください。QRコードが表すブランドと一致していますか?URLショートナー(bit.ly・tinyurlなど)が実際の遷移先を隠していませんか?不審な点(スペルミスのドメイン・見慣れないTLD・IPアドレス・異常に長いURL)があれば、疑わしいメールリンクと同じように扱ってください。スキャンする前にデコードするという行為の本来の目的は、自分で判断できる機会を与えることです。