C#でQRコードを生成・読み取りする方法｜ライブラリ選定からサンプルコードまで徹底解説

はじめに

C#でQRコードを扱いたい場面は、業務システムやWebサービス、社内ツール、スマホ連携アプリなど幅広くあります。たとえば、会員証やチケットの発行、URLの共有、在庫管理、受付処理、本人確認の補助など、QRコードは今や多くの業務で欠かせない仕組みです。

ただし、C#でQRコードを扱う場合は「生成」と「読み取り」で必要な技術が異なります。さらに、.NETのバージョンや実行環境によっても選ぶべきライブラリや実装方法が変わるため、最初に全体像を押さえておくことが重要です。

この記事では、C#でQRコードを生成・読み取りする方法を、基礎知識からライブラリ選定、サンプルコード、実務での注意点まで順番に整理して解説します。

1. C#でQRコードを扱う前に知っておきたい基礎知識

1-1. QRコード生成・読み取りでC#が使われる主なシーン

C#でQRコードを扱うケースは、主に次のような場面です。

まず、Webアプリや業務システムでQRコード画像を生成する用途があります。たとえば、注文番号や予約情報、ログイン用URL、決済用リンクなどをQRコードにして画面表示したり、PDFや印刷物に埋め込んだりするケースです。

次に、画像やカメラ映像からQRコードを読み取る用途があります。Windowsアプリでのスキャナー連携、スマホやWebカメラ入力、アップロード画像の解析などが代表例です。

また、C#はASP.NET Core、Windows Forms、WPF、MAUI、コンソールアプリなど対応範囲が広いため、QRコード機能を既存システムに組み込みやすい点も大きなメリットです。

1-2. QRコードに格納できるデータの種類

QRコードには、単なる文字列だけでなく、URL、電話番号、メールアドレス、住所、トークン文字列、JSON形式のデータなどを格納できます。もっとも一般的なのはURLですが、実務では「識別子のみを格納して、詳細情報はサーバー側で参照する」設計も多く使われます。

これは、QRコードに大量の情報を詰め込みすぎるとサイズが大きくなり、印刷時や読み取り時の精度が下がるためです。特に、個人情報や機密情報をそのまま埋め込むと、漏えいリスクも高くなります。

そのため、C#でQRコードを生成する際は、何を直接埋め込むのか、何をURLやIDに置き換えるのかを最初に決めることが重要です。

1-3. 生成と読み取りで必要になる処理の違い

QRコードの「生成」は、文字列やURLなどのデータをもとに、規格に沿った2次元コード画像を作る処理です。重要なのは、誤り訂正レベル、サイズ、余白、出力形式、文字コードの扱いです。

一方、「読み取り」は、画像やカメラ映像の中からQRコード部分を見つけて、傾きやノイズを補正しながら元データを復元する処理です。生成よりも、画像品質や撮影条件の影響を強く受けます。

つまり、生成は「正しいQRコードを作ること」、読み取りは「不完全な画像から正しく復元すること」が中心になります。C#でQRコードを扱う場合は、この違いを理解したうえでライブラリを選ぶことが大切です。

1-4. .NET Framework／.NET 6以降／ASP.NETでの注意点

C#のQRコード実装では、実行環境によって注意点が変わります。特に、.NET Framework、.NET 6以降、ASP.NET Coreでは、画像処理や依存ライブラリの扱いが異なります。

.NET Frameworkでは古いライブラリでも動作しやすい一方、最新のライブラリやクロスプラットフォーム対応では制約が出ることがあります。逆に、.NET 6以降ではモダンな開発がしやすい反面、System.Drawing.Commonの利用に制限があり、Linux環境では注意が必要です。

ASP.NET Coreでは、リクエストごとにQRコード画像を生成して返すケースが多いため、メモリ効率やスレッド安全性、キャッシュ設計も重要になります。Webサーバー上で動くことを前提に、ファイル保存だけでなくバイナリレスポンスで返す実装もよく使われます。

2. C#でQRコードを生成・読み取りする方法は主にライブラリ利用が現実的

2-1. 標準ライブラリだけでQRコード処理が難しい理由

C#や.NETの標準機能には、QRコードを生成・読み取りする専用APIは基本的に含まれていません。画像を扱うための基盤機能はありますが、QRコード規格に沿ってモジュール配置を計算したり、読み取り時に歪み補正やデコード処理を行ったりする機能は標準だけでは不足します。

そのため、ゼロから実装しようとすると、QRコードの仕様理解だけでなく、画像処理やエラー補正、デコーダーの実装まで必要になります。実務では現実的ではないため、通常は専用ライブラリを使います。

2-2. NuGetライブラリを使うメリット

C#でQRコード機能を実装する場合、NuGetライブラリを使うのが最も一般的です。導入が簡単で、生成・読み取り・画像出力・カメラ対応などの機能を短時間で実装できます。

NuGetを使うメリットは、実装コストを大きく下げられることです。たとえば、数行のコードでQRコード画像を生成できたり、画像ファイルから読み取り結果を取得できたりします。さらに、ライブラリによっては日本語対応、ロゴ合成、複数コード検出、PDFやバーコードとの併用なども可能です。

保守面でも、広く使われているライブラリを選べば、コミュニティの情報やサンプルが見つかりやすく、トラブルシューティングもしやすくなります。

2-3. 無料ライブラリと商用ライブラリの違い

無料ライブラリは、導入しやすくコストを抑えられるのが魅力です。個人開発、小規模システム、社内ツールなどでは十分なことが多く、特に生成だけなら無料ライブラリで問題ないケースが多くあります。

一方、商用ライブラリは、サポート体制がある、機能が豊富、業務用途での安定性が高い、といった強みがあります。画像品質が悪い場合の読み取り精度、複数ページや大量データ処理、特殊な出力形式などで有利なことがあります。

ただし、商用ライブラリはライセンス費用が発生することがあるため、利用規模や予算、サポートの必要性を踏まえて選ぶことが大切です。

2-4. 生成だけ必要な場合と読み取りも必要な場合の選び方

QRコードを「生成だけ」使う場合は、軽量で扱いやすいライブラリが向いています。画面表示、印刷、PDF出力、メール添付用の画像など、出力中心の用途なら、生成機能に特化したものでも十分です。

一方、画像認識やカメラ入力を含む「読み取り」まで必要な場合は、生成と読み取りの両方に対応したライブラリを選ぶと管理が楽です。別々のライブラリを組み合わせることもできますが、画像形式の変換や依存関係が増えやすくなります。

開発初期は生成だけで足りても、後から読み取り機能が必要になることは多いため、将来の拡張性も考えて選定するのが賢い進め方です。

3. C#向けQRコードライブラリの比較

3-1. ZXing.Net：生成・読み取りの両方に対応した定番ライブラリ

ZXing.Netは、C#でQRコードを扱う際によく使われる定番ライブラリの一つです。生成と読み取りの両方に対応しており、バーコード全般も扱えるため、汎用性が高いのが特徴です。

読み取り機能を含めて幅広く使いたい場合、まず候補に上がることが多いライブラリです。サンプルも多く、基本的な実装を学ぶには適しています。業務システムで「まずは堅実に動くものを使いたい」という場面に向いています。

3-2. QRCoder：QRコード生成に特化した軽量ライブラリ

QRCoderは、名前の通りQRコード生成に特化したライブラリです。比較的シンプルで軽く、生成処理を中心に使いたい場合に扱いやすいのが魅力です。

WebアプリやコンソールアプリでQRコード画像を作りたい、ロゴ付きのQRコードを簡単に作成したい、という用途に向いています。読み取り機能は別ライブラリに任せ、生成だけを効率よく行いたい場合に適した選択肢です。

3-3. IronBarcode／IronQR：業務利用向けの高機能ライブラリ

IronBarcodeやIronQRは、業務用途を意識した高機能ライブラリとして検討されることが多いです。読み取り精度や実務向け機能、サポートの充実度を重視する場合に選ばれやすいです。

特に、複雑な画像からの読み取りや、安定した運用が必要なシステムでは、商用ライブラリの安心感がメリットになります。開発工数を減らしたい場合や、サポートを重視したい場合に有力です。

3-4. Spire.Barcode：生成・読み取りに対応した商用系ライブラリ

Spire.Barcodeも、バーコードやQRコードの生成・読み取りに対応した商用系ライブラリです。複数のバーコード形式を扱う必要があるケースでは便利です。

既存の文書出力や帳票システムと組み合わせる場面でも使いやすく、業務での利用を想定した機能が揃っています。ライセンス条件と必要機能のバランスを見て検討するとよいでしょう。

3-5. SkiaSharp.QrCode：クロスプラットフォーム対応を重視する場合の選択肢

SkiaSharp.QrCodeは、クロスプラットフォーム環境との相性を重視する場合に候補になるライブラリです。LinuxやDockerを含む環境で画像生成を行いたいとき、System.Drawing.Commonへの依存を避けたいケースで注目されます。

.NETの実行環境が多様化している今、Windows専用ではなく、サーバーやコンテナ上でも動かしやすい構成は大きな利点です。ASP.NET Coreやバックエンド処理で使う場合にも検討しやすい選択肢です。

3-6. 用途別おすすめライブラリ早見表

用途に応じて、ライブラリの選び方は変わります。

生成だけを手軽に行いたいならQRCoder、生成と読み取りの両方を広く扱いたいならZXing.Net、業務向けの高機能性やサポートを重視するならIronBarcodeやIronQR、クロスプラットフォーム重視ならSkiaSharp.QrCodeが候補になります。

最終的には、対応環境、ライセンス、必要機能、学習コストの4点で比較するのが失敗しにくい選び方です。

4. C#でQRコードを生成するサンプルコード

4-1. NuGetでライブラリをインストールする

C#でQRコードを生成する最初の手順は、使うライブラリをNuGetから追加することです。Visual StudioのNuGetパッケージマネージャーから検索して追加するか、CLIでインストールします。

たとえば、生成専用のライブラリを使う場合はQRCoder、生成と読み取りの両方を扱いたい場合はZXing.Netを選ぶケースが一般的です。まずはプロジェクトの種類に合ったものを導入しましょう。

4-2. 文字列・URLからQRコードを生成する基本コード

QRコード生成の基本は、文字列をエンコードして画像化することです。以下はイメージしやすい基本的な考え方です。

C#
using System;
using QRCoder;

class Program
{
    static void Main()
    {
        string text = "https://example.com";

        using var generator = new QRCodeGenerator();
        using QRCodeData data = generator.CreateQrCode(text, QRCodeGenerator.ECCLevel.Q);

        using var qrCode = new PngByteQRCode(data);
        byte[] png = qrCode.GetGraphic(20);

        File.WriteAllBytes("qrcode.png", png);

        Console.WriteLine("QRコードを生成しました。");
    }
}

この例では、URL文字列をQRコード化してPNGファイルとして保存しています。実際には、保存先パスやサイズ、誤り訂正レベルを用途に応じて調整します。

4-3. 生成したQRコードをPNG画像として保存する

QRコードは、画面表示だけでなくPNG画像として保存することがよくあります。保存しておけば、Webページや帳票、メール、PDFなどに再利用しやすくなります。

PNGは可逆圧縮で画質が劣化しにくいため、QRコード画像の保存形式として相性がよいです。JPGよりも輪郭が崩れにくく、読み取り精度を保ちやすい点も重要です。

4-4. QRコードのサイズ・余白・誤り訂正レベルを設定する

QRコードは、サイズが大きければ見やすくなるとは限りません。小さすぎると読めず、大きすぎると印刷レイアウトに収まりません。そのため、出力サイズは用途に応じて決める必要があります。

余白も重要です。QRコードの周囲に十分な空白がないと、スマホカメラやスキャナーが認識しにくくなります。また、誤り訂正レベルを上げると、多少の汚れや欠損に強くなりますが、同じデータでもコードがやや複雑になります。

一般的には、印刷物や外部環境で使うなら、ある程度余裕のあるサイズと誤り訂正レベルを選ぶのが安全です。

4-5. 日本語を含むQRコードを生成する際の文字コード対策

日本語を含むQRコードでは、文字化け対策がとても重要です。原因の多くは、エンコード時の文字コードの扱いにあります。

QRコードに日本語を入れる場合は、ライブラリがどの文字コードを前提にしているかを確認し、必要に応じてUTF-8対応や適切な設定を行います。特に、Webシステムや外部システムとデータをやり取りする場合は、送信側と受信側で文字コードの認識を合わせる必要があります。

実務では、日本語を直接詰め込むより、UTF-8で文字列を保持しながら、読み取り側でも同じルールで復元できるようにしておくのが重要です。

4-6. ロゴ入り・色付きQRコードを作成する方法

デザイン性を高めるために、ロゴを中央に配置したり、色付きのQRコードにしたりすることもあります。ブランドサイトやキャンペーン用のQRコードではよく使われる表現です。

ただし、装飾を増やしすぎると読み取り精度が下がるため注意が必要です。特に、ロゴを大きくしすぎると、中央部分のモジュールが欠けて読み取り不能になることがあります。誤り訂正レベルを高め、ロゴサイズを控えめにするのが基本です。

色付きにする場合も、背景と前景のコントラストを十分に確保することが重要です。見た目よりも、カメラで確実に読めるかを優先しましょう。

5. C#でQRコードを読み取るサンプルコード

5-1. 画像ファイルからQRコードを読み取る基本コード

QRコードの読み取りは、画像ファイルを入力としてデコードするのが基本です。ZXing.Netのようなライブラリを使えば、画像から内容を取得できます。

C#
using System;
using System.Drawing;
using ZXing;

class Program
{
    static void Main()
    {
        var reader = new BarcodeReader();
        using var bitmap = (Bitmap)Image.FromFile("qrcode.png");

        var result = reader.Decode(bitmap);

        if (result != null)
        {
            Console.WriteLine(result.Text);
        }
        else
        {
            Console.WriteLine("QRコードを読み取れませんでした。");
        }
    }
}

このように、画像を読み込んでデコード結果を取得します。実際には、画像形式や実行環境に応じて、Bitmapの扱い方を調整する必要があります。

5-2. 複数のQRコードを一括で読み取る方法

1枚の画像内に複数のQRコードが含まれている場合は、それぞれを個別に検出して読み取る必要があります。複数コード対応の機能を使うことで、一括解析が可能です。

たとえば、商品棚の写真、掲示板の画像、一覧表のキャプチャなどでは、複数のQRコードが並ぶことがあります。このようなケースでは、単一コード前提の処理では不十分です。

複数読み取りでは、検出範囲の精度や画像サイズの影響がさらに大きくなるため、入力画像の品質を高めることが成功率向上につながります。

5-3. カメラ映像・スキャン画像から読み取る場合の考え方

カメラ映像からQRコードを読み取る場合は、静止画像よりも処理が複雑になります。連続フレームの中から安定してコードを検出し、ピントや明るさ、動きの影響を受けにくくする必要があります。

Windows FormsやWPFではWebカメラ連携、MAUIではモバイルカメラ連携、ASP.NETでは画像アップロード後の解析など、実装形態によって処理方法が変わります。

重要なのは、リアルタイムで読むのか、撮影済み画像を読むのかを最初に決めることです。リアルタイム性が必要なほど、画像処理やUI制御の設計が重要になります。

5-4. 読み取り精度を上げる画像処理のポイント

QRコードの読み取り精度を上げるには、入力画像をできるだけ見やすい状態に整えることが大切です。たとえば、明るさの補正、コントラストの調整、回転補正、ノイズ除去、解像度の確保などが有効です。

また、余白が少ない画像や極端に小さいQRコードは、読み取り率が下がります。撮影段階で、コードが画面いっぱいに映るようにするだけでも精度は大きく改善します。

印刷物を撮影する場合は、影や反射、傾きにも注意が必要です。スマホカメラで安定して読めるかどうかを、事前に実機テストしておくと安心です。

5-5. 読み取りに失敗したときの原因と対処法

読み取りが失敗した場合は、まず画像品質を確認します。ピンぼけ、解像度不足、傾き、暗さ、ノイズ、余白不足などが原因になりやすいです。

次に、ライブラリ設定を見直します。複数コードを読んでいるつもりで単一コードAPIを使っていないか、文字コード設定が合っているか、対応フォーマットが正しいかを確認します。

それでも読めない場合は、QRコード自体の生成条件を見直す必要があります。誤り訂正レベル、サイズ、色のコントラスト、ロゴの大きさなどを調整すると改善することがあります。

6. アプリケーション別のQRコード実装例

6-1. コンソールアプリでQRコードを生成・読み取りする

コンソールアプリは、C#でQRコードの基本動作を試すのに最適です。生成してファイルに保存したり、画像を読み込んで結果を表示したりする流れをシンプルに確認できます。

ロジックを切り出しておけば、そのままWindowsアプリやASP.NET Coreへ移植しやすくなります。まずはコンソールで動作確認し、その後にUIやWeb APIへ展開するのが効率的です。

6-2. Windows FormsでQRコードを画面表示する

Windows Formsでは、生成したQRコードをPictureBoxに表示する実装がよく使われます。ボタンを押して文字列を入力し、その場でQRコードをプレビューするようなアプリに向いています。

社内ツールや簡易ユーティリティでは、画面上で確認しながらQRコードを生成できることが便利です。印刷前の確認にも使いやすい構成です。

6-3. WPFアプリでQRコードを表示・保存する

WPFでは、UIの見た目を柔軟に設計できるため、QRコードの表示領域や保存ボタン、入力フォームを洗練された形で作れます。データバインディングとの相性もよく、入力値の変更に合わせてQRコードを更新するような実装も自然です。

また、WPFは業務アプリとの親和性が高く、帳票や管理画面の一部としてQRコードを扱うケースにも向いています。

6-4. ASP.NET CoreでQRコード画像を動的に返す

ASP.NET Coreでは、HTTPリクエストに応じてQRコード画像を生成し、レスポンスとして返す実装がよく行われます。たとえば、/qrcode?text=... のようなエンドポイントを用意し、画像をそのままブラウザに表示できます。

この方法なら、ファイル保存を経由せずに動的生成できるため、Webサービスや管理画面との相性が良いです。キャッシュやレスポンス形式の設計を工夫すれば、パフォーマンスも保ちやすくなります。

6-5. Web APIでQRコード生成機能を提供する

Web APIとしてQRコード生成機能を切り出しておくと、フロントエンドや外部システムから再利用しやすくなります。JSONで入力を受け取り、PNGやBase64形式で返す構成が一般的です。

この方式は、マイクロサービス化やフロントエンド分離の構成にも適しています。複数の画面やシステムから同じQRコード生成ロジックを使いたい場合に便利です。

6-6. BlazorやMAUIでQRコードを扱う場合の注意点

BlazorやMAUIでは、画面構成や実行環境の違いに応じて、画像生成と表示の方法を考える必要があります。特に、MAUIではモバイルやクロスプラットフォーム対応が前提になるため、利用する画像ライブラリの互換性が重要です。

Blazorではブラウザ側とサーバー側の役割分担を意識し、画像をバイナリで返すのか、Base64で埋め込むのかを決めると実装しやすくなります。

7. QRコード生成時によくあるエラーと解決策

7-1. System.Drawing.Common関連のエラー

.NET 6以降では、System.Drawing.Commonの扱いに注意が必要です。特にLinux環境では、Windows前提の画像処理に依存しているとエラーになることがあります。

そのため、サーバーやコンテナで動かす前提なら、最初からクロスプラットフォーム対応の画像処理ライブラリを選ぶ方が安全です。Windows専用か、Linux対応かを早めに確認しておきましょう。

7-2. Linux・Docker環境で画像生成に失敗する

LinuxやDockerで画像生成に失敗する場合、フォントやネイティブ依存、画像ライブラリの互換性が原因になりやすいです。ローカルWindowsでは動いても、コンテナでは動かないことがあります。

この場合は、依存パッケージの見直し、ベースイメージの確認、描画ライブラリの変更が有効です。サーバー配備前に、実際の本番環境に近い条件でテストすることが重要です。

7-3. 日本語が文字化けする

日本語の文字化けは、エンコード設定不一致が最も多い原因です。生成側と読み取り側で文字コードの前提が違うと、正しく復元されません。

日本語を扱う場合は、UTF-8を中心に設計し、外部システムとの連携時にも文字コードを統一することが基本です。データをそのまま入れるのではなく、文字列の扱いを明示的に決めておくと安全です。

7-4. QRコードが小さすぎて読み取れない

QRコードが小さすぎると、スマホやスキャナーで認識しづらくなります。特に印刷物では、視認できても読み取れないことがあります。

解決策としては、コードサイズを大きくする、余白を確保する、誤り訂正レベルを上げる、印刷解像度を見直す、などが有効です。用途に応じて、最終出力サイズまで見越して設計することが大切です。

7-5. 余白不足でスマホカメラが認識しない

QRコードの周囲には、一定の余白が必要です。余白がないと、背景とコードの境界をうまく認識できず、読み取り失敗につながります。

デザイン上の都合で周囲に文字や画像を詰め込みすぎると、見た目は整っても実用性が落ちます。印刷物や画面表示では、見せたい情報と読み取りやすさのバランスが重要です。

7-6. NuGetパッケージのバージョン違いによる不具合

QRコード関連のライブラリは、バージョン差によってAPIや依存関係が変わることがあります。サンプルコードがそのまま動かない場合、バージョン違いが原因のことも少なくありません。

導入時には、READMEや公式ドキュメントを確認し、プロジェクトのターゲットフレームワークと互換性があるかを必ず見ておくと安心です。

8. QRコード読み取り時によくあるエラーと解決策

8-1. 画像はあるのに読み取り結果がnullになる

画像ファイルが存在していても、読み取り結果がnullになることがあります。これは、画像内にQRコードがあっても認識条件を満たしていない可能性があります。

たとえば、サイズ不足、傾き、ぼけ、背景ノイズ、コントラスト不足などです。まずは高解像度で、余白のある、まっすぐな画像を用意して再試行すると原因を切り分けやすくなります。

8-2. ピンぼけ・傾き・暗い画像で読み取れない

スマホやWebカメラで撮影したQRコードは、ピンぼけや傾き、暗さの影響を受けやすいです。読み取りライブラリが優秀でも、入力画像の品質が低いと失敗します。

撮影時点で対策するのが最善ですが、事後処理として回転補正や明るさ補正をかけることで改善することもあります。業務用途では、ユーザーに「読み取りやすい撮影方法」を案内する設計も重要です。

8-3. 解像度が低い画像を読み取る場合の対策

低解像度画像では、QRコードの細部がつぶれてしまい、デコードできないことがあります。特に、縮小された画像やスクリーンショットの再圧縮で品質が落ちている場合は要注意です。

可能であれば、元画像のまま読み取るのが理想です。どうしても低解像度しかない場合は、画像を拡大するよりも、ノイズ除去やコントラスト調整のほうが有効なことがあります。

8-4. Webアップロード画像を読み取る際の注意点

Webアプリでユーザーがアップロードした画像を読み取る場合は、ファイルサイズ、形式、回転情報、透過、圧縮率などを考慮する必要があります。

アップロード直後にそのままデコードするのではなく、画像を正規化してから処理すると安定しやすくなります。また、悪意のあるファイルや極端に大きな画像に備えて、サイズ制限やバリデーションも必要です。

8-5. 大量画像を処理するときのパフォーマンス対策

大量の画像を連続で読み取る場合、メモリ使用量と処理時間が問題になります。特に、画像を毎回フルサイズで読み込むと負荷が高くなりがちです。

対策としては、不要なコピーを減らす、並列処理の数を制御する、ファイルを逐次処理する、処理後に速やかに破棄する、といった工夫が有効です。バッチ処理では、読み取り精度とスループットの両方を意識した設計が必要です。

9. 実務で使うQRコード機能の設計ポイント

9-1. QRコードに直接入れる情報とURL化すべき情報

実務では、QRコードにすべての情報を直接入れるのではなく、URLやIDに置き換える設計がよく使われます。たとえば、会員番号そのものではなく、その番号を参照するURLやトークンを入れる方法です。

こうすることで、情報量を抑えられるだけでなく、後から内容を変更しやすくなります。QRコードが一度印刷された後でも、サーバー側の処理を変えることで挙動を更新できるのが大きな利点です。

9-2. 個人情報や認証情報をQRコードに含める際の注意点

個人情報や認証情報をQRコードに含めると、読み取られたときのリスクが高くなります。紙や画面上で見えてしまう以上、第三者に簡単に取得される可能性があります。

そのため、機密性の高い情報は直接入れず、短命なトークンやサーバー側参照に置き換えるのが基本です。必要最小限の情報だけを載せる設計にすることで、運用リスクを下げられます。

9-3. 有効期限付きURL・ワンタイムトークンの活用

セキュリティを考えるなら、有効期限付きURLやワンタイムトークンの活用が有効です。QRコードを見られても、期限切れや一度しか使えない仕組みになっていれば、悪用リスクを抑えられます。

予約確認、入退室管理、イベント受付などでは特に有効です。C#のサーバー側でトークン発行と検証を組み合わせると、実務に適した堅牢な仕組みを作りやすくなります。

9-4. 印刷用QRコードで気をつけるサイズと解像度

印刷用途では、画面表示以上にサイズと解像度が重要です。プリンタで出力したときにモジュールがつぶれないよう、十分なサイズと高解像度の画像を使う必要があります。

また、紙質や印刷機の品質によっても読みやすさは変わります。最終的には、実際の印刷物でスマホ読み取りテストを行うことが欠かせません。

9-5. 生成後に必ず読み取りテストを行うべき理由

QRコードは、生成できたからといって必ず読めるとは限りません。ライブラリが正しく動いていても、出力先のサイズ、色、印刷条件、撮影条件によって失敗することがあります。

そのため、生成後は必ず実機で読み取りテストを行うべきです。特に本番利用前は、複数端末・複数環境で確認しておくと安心です。

10. C# QRコード実装に関するよくある質問

10-1. C#でQRコードを無料で生成できますか？

はい、無料で生成できます。QRCoderやZXing.Netなど、無料で使えるライブラリがあり、基本的なQRコード生成には十分対応できます。

10-2. QRコードの読み取りまで無料で実装できますか？

はい、無料でも実装できます。ZXing.Netのように、読み取りに対応した無料ライブラリを使えば、画像ファイルやカメラ映像からのデコードが可能です。

10-3. ZXing.NetとQRCoderはどちらを選ぶべきですか？

読み取りも必要ならZXing.Net、生成だけで十分ならQRCoderが選びやすいです。どちらもよく使われますが、用途がはっきりしているほど選定しやすくなります。

10-4. ASP.NET CoreでもQRコード生成はできますか？

はい、ASP.NET Coreでも問題なく可能です。リクエストに応じてQRコード画像を生成し、レスポンスとして返す実装が一般的です。

10-5. LinuxサーバーやDocker環境でも動作しますか？

ライブラリの選び方次第で動作します。Windows専用の画像処理に依存する構成だと問題が出ることがあるため、クロスプラットフォーム対応のライブラリを選ぶのが安全です。

10-6. 商用利用する場合にライセンス確認は必要ですか？

はい、必要です。無料ライブラリでもライセンス条件は必ず確認し、商用利用の可否、配布条件、改変条件などを事前に把握しておくべきです。

まとめ

C#でQRコードを扱う場合は、まず「生成」と「読み取り」の違いを理解し、そのうえで用途に合ったライブラリを選ぶことが重要です。生成だけなら軽量なライブラリ、読み取りまで必要なら両対応のライブラリ、業務用途や高機能性を重視するなら商用ライブラリという考え方が基本になります。

また、実装そのものよりも、文字コード、余白、サイズ、画像品質、実行環境の違いが失敗の原因になりやすい点も押さえておく必要があります。特に日本語、Linux、Docker、ASP.NET Coreを扱う場合は、事前確認が成果を大きく左右します。

C#のQRコード実装は、適切なライブラリ選定とテストさえ行えば、比較的短期間で実用レベルに到達できます。生成・読み取りの両方を見据えて、保守しやすく、読み取りやすい設計を意識することが成功の近道です。