C# MVCでの二重登録を防ぐ実装パターン

フォームの「連打」による二重登録、あなたのアプリでも発生していませんか？

ASP.NET MVCで開発された業務アプリでは、ユーザーの意図しない再送信によって、同じデータが二重に登録されるトラブルがしばしば発生します。本記事では、C# MVC環境における代表的な二重登録防止手法を整理し、開発現場で実際に使える実装パターンとその考え方を紹介します。ユーザー体験を損なわずに、信頼性の高いフォーム処理を実現するためのヒントをお届けします。

二重登録が起こる原因と影響
防止手法①：PRGパターン（Post-Redirect-Get）
防止手法②：JavaScriptによるボタンの無効化
防止手法③：トークン（Anti-Forgery Token）の活用とサーバー側チェック
防止手法④：サーバー側での重複チェック（楽観ロックやハッシュ）
ケース別の実装選択（事例紹介）
まとめ

二重登録が起こる原因と影響

フォームの二重登録は、エンドユーザーにとっては些細な操作でも、システムには深刻な影響を与える要因となり得ます。この章では、なぜ二重登録が発生するのか、そしてその影響がどれほど重要かを明確にしておきましょう。

ユーザー操作やブラウザ挙動が主な原因

✅ ボタンの連打

ユーザーが「送信」ボタンを連続でクリックすることにより、同じリクエストが短時間に複数回送信されるケースです。これは特に処理が重く、レスポンスが遅い場合に起こりがちです。

✅ ページのリロードや戻るボタン

フォーム送信後、ユーザーがブラウザの「戻る」や「更新（F5）」ボタンを使用することで、同じPOSTリクエストが再送信される場合があります。これにより、サーバーが再び同じ処理を実行してしまう可能性があります。

✅ ネットワーク遅延による混乱

モバイル回線や不安定な通信環境では、送信処理中にユーザーが不安になって再度ボタンを押すといった行動が見られます。これも意図しない再送信の原因となります。

発生するとどうなるか？

データの二重登録は最も一般的な問題です。たとえば、同じ注文が複数登録されてしまい、在庫や請求に誤差が生じる事態につながります。また、ID採番方式によっては連番のギャップが生まれたり、ログの解析が困難になったりします。

業務フローの混乱も大きなリスクです。例えば、ワークフローの次工程が自動起動するようなシステムでは、誤って2回進行してしまうケースがあり、担当者の混乱やクレームに直結します。

ユーザー体験（UX）の低下も無視できません。ユーザーにとっては「送ったのに2回になった」「処理が遅いからもう一度押したら変になった」といったストレスが生じます。これはシステムの信頼性に対する印象にも悪影響を与える可能性があります。

防止手法①：PRGパターン（Post-Redirect-Get）

PRG（Post-Redirect-Get）パターンは、フォーム送信後の再送信防止策として最も基本的かつ効果的な手法です。この章ではその仕組みと実装例、そして注意点について解説します。

PRGパターンとは？

✅ POSTリクエストの後にリダイレクトを行うことで、同じフォームの再送信を防止するという設計パターンです。

通常、フォームを送信するとブラウザはPOSTリクエストをサーバーに送ります。そのまま結果を表示した場合、ユーザーがF5キーや更新ボタンを押すと同じPOSTが再送信され、二重登録が発生します。

PRGパターンでは、POST処理後に一度RedirectToAction()などでGETリクエストにリダイレクトします。これにより、ブラウザの更新操作で再送信が起こるのを防ぐことができます。

ASP.NET MVCの例

ASP.NET MVCの例：

[HttpPost]
public ActionResult SubmitForm(MyModel model)
{
    if (ModelState.IsValid)
    {
        db.MyTable.Add(model);
        db.SaveChanges();
        return RedirectToAction("Success");
    }

    return View(model); // 入力にエラーがある場合はそのまま表示
}

public ActionResult Success()
{
    return View();
}

このように、登録処理が完了した後にRedirectToActionを使って成功画面（Success）へ遷移させることで、同じPOSTデータが二度サーバーに送られることを防止できます。

メリットと注意点

メリット

二重登録を防止できる
ブラウザのリロードに強い
ユーザーが「戻る」「更新」をしても安全

注意点

入力エラー時はPOST→Redirect→GETを行わないため、PRGが適用されない点に留意する必要があります。
フォームデータの保持が難しくなるため、リダイレクト時にTempDataなどを使って状態を引き継ぐ工夫が必要な場面もあります。

防止手法②：JavaScriptによるボタンの無効化

ユーザーが「送信」ボタンを連打してしまうことによる二重登録を防ぐには、クライアントサイドでの対応が非常に有効です。特に、JavaScriptを活用してフォーム送信中にボタンを無効化する手法は、実装が簡単で即効性のある対策です。この章では、クリックだけでなくEnterキーによる送信にも対応した確実な実装パターンを紹介します。

どのように機能するか？

✅ フォームのsubmitイベント自体をフックして、送信ボタンを無効化するというのがポイントです。これにより、クリック操作だけでなく、テキストボックスでEnterキーを押しても、送信トリガーに対して一律に対応できます。

実装例（フォームsubmitイベント対応）

HTML + JavaScriptの例（Enterキー対応）：

<form id="myForm" method="post">
  <input type="text" name="username" placeholder="名前を入力" required />
  <button type="submit" id="submitBtn">送信</button>
</form>

<script>
document.getElementById("myForm").addEventListener("submit", function(e) {
  // すでに無効化済みなら何もしない
  const btn = document.getElementById("submitBtn");
  if (btn.disabled) {
    e.preventDefault();
    return;
  }

  // ボタンを無効化して送信（再送防止）
  btn.disabled = true;
});
</script>

この実装により、フォームが送信される前に必ずボタンが無効化されるため、クリック・Enterキーの両方の入力に対して二重送信を確実に防げます。

メリットと注意点

メリット

クライアントサイドだけで完結し、サーバー側への負担がない
PRGパターンと組み合わせることでより堅牢な防止策となる
JavaScriptの基本的な知識で簡単に実装可能

注意点

JavaScriptが無効なブラウザでは機能しないため、サーバー側の対策と併用すべき
複数の送信ボタンが存在する場合、それぞれに対応したロジックが必要
バリデーションエラー後の再表示時には、ボタンのdisabled状態が初期化されるよう考慮する必要あり

この方法は、操作頻度の高い業務アプリやエンドユーザー向けフォームに非常に適しています。ユーザー体験を損なわず、自然な動作のままリスクだけを排除できるため、まず導入すべき基本的な施策の一つといえるでしょう。

防止手法③：トークン（Anti-Forgery Token）の活用とサーバー側チェック

ASP.NET MVCには、クロスサイトリクエストフォージェリ（CSRF）攻撃を防止するための AntiForgeryToken 機能が組み込まれています。このトークンを二重送信の防止にも応用できることをご存知でしょうか？ここではその仕組みと実装方法を紹介します。

Anti-Forgery Tokenの基本と応用

✅ @Html.AntiForgeryToken() をフォームに埋め込むことで、ASP.NET MVCはユニークなトークンを生成し、サーバー側と一致するかどうかを検証します。これにより、外部サイトからの不正送信を防ぐことができます。

この仕組みを応用して、一度使われたトークンは再利用できないようにすることで、フォームの再送信も防止できます。

実装の考え方

ASP.NET MVCの例（カスタムでトークン再使用禁止）：

[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult SubmitForm(MyModel model)
{
    if (!ModelState.IsValid)
        return View(model);

    if (IsTokenUsed())
    {
        ModelState.AddModelError("", "すでにこのフォームは送信されています。");
        return View(model);
    }

    MarkTokenAsUsed(); // セッションやDBにフラグを保存
    db.MyTable.Add(model);
    db.SaveChanges();

    return RedirectToAction("Success");
}

補足

IsTokenUsed() は、セッションやデータベースでトークンの使用履歴を確認するロジックです。
MarkTokenAsUsed() でトークンの使用状態を保存しておくことで、再送信時に検出できます。

このようなトークン管理は、CSRF対策の延長として設計でき、堅牢性を大きく向上させる方法です。

メリットと注意点

メリット

セキュリティ対策（CSRF）と二重登録防止を同時に実現できる
サーバー側で完全に制御でき、JavaScript非対応環境にも有効

注意点

トークンの再利用検出には、セッションやDBなどのストレージが必要
システム全体で一貫した管理設計が求められる（例：トークン有効期限やスレッドセーフな保存）

この手法は、重要な業務処理や申請系フォームなど、再送信が大きな影響を与える場面で特に有効です。

防止手法④：サーバー側での重複チェック（楽観ロックやハッシュ）

クライアントやリダイレクトに依存しない、より確実な方法として「サーバー側での重複チェック」があります。これは、フォームの内容そのものをサーバーで判定し、同一データが一定期間内に登録されていないかをチェックするというアプローチです。

重複チェックの代表的な手法

✅ 楽観ロック（タイムスタンプやバージョン番号の活用）

データベースレコードに「更新日時」や「バージョン番号」を持たせ、登録処理の前後でその値が変化していないかを確認します。競合があれば処理を中断し、重複や競合を検知します。

✅ ハッシュによるデータ比較

フォーム送信内容を基に一意のハッシュ値を生成し、直近の登録履歴と比較します。同一のハッシュが既に保存されていれば、処理をブロックする仕組みです。これにより、全項目一致の再送信を高精度で検出可能です。

実装例（ハッシュ方式）

ASP.NET MVC + SHA256による重複チェックの例：

[HttpPost]
public ActionResult SubmitForm(MyModel model)
{
    string hash = GenerateHash(model);

    if (db.SubmitLogs.Any(l => l.Hash == hash && l.SubmittedAt > DateTime.Now.AddMinutes(-5)))
    {
        ModelState.AddModelError("", "同じ内容のデータが既に登録されています。");
        return View(model);
    }

    db.SubmitLogs.Add(new SubmitLog { Hash = hash, SubmittedAt = DateTime.Now });
    db.MyTable.Add(model);
    db.SaveChanges();

    return RedirectToAction("Success");
}

private string GenerateHash(MyModel model)
{
    var input = model.Name + model.Email + model.Content;
    using (var sha = SHA256.Create())
    {
        var bytes = Encoding.UTF8.GetBytes(input);
        var hashBytes = sha.ComputeHash(bytes);
        return Convert.ToBase64String(hashBytes);
    }
}

このコードは、モデルのデータからSHA256でハッシュを生成し、直近の同一ハッシュデータが存在しないかをチェックしています。

メリットと注意点

メリット

サーバー側で確実にチェックできる
フロントエンドの依存がないため、安定性が高い
入力内容の完全一致が必要な場面に適している

注意点

モデルの変化（例えば空白や順番違い）でも別ハッシュになるため、緩やかな一致判定には不向き
ハッシュをDBに保存するテーブル設計が必要
チェック条件（時間制限など）の設計が必要

この手法は、公共系システムや重要なビジネスデータなど、より慎重な登録制御が求められる場面において非常に有効です。

ケース別の実装選択（事例紹介）

これまで紹介した各手法は、それぞれ単体でも効果を発揮しますが、実際の現場では「ユースケースに応じた組み合わせ」が求められることが多いです。この章では、典型的なシステムの例に応じて、どの手法を選ぶべきかを具体的に紹介します。

例1：業務アプリ（注文登録）

BtoB向けの受発注システムなど、操作頻度が高く、リアルタイム性と信頼性の両立が必要なケースでは、以下のような組み合わせが有効です。

推奨パターン：PRGパターン + JavaScriptのボタン無効化

PRGパターンにより、F5更新や戻るボタンによるPOST再送信をブロック
ボタンの無効化により、ユーザーの連打対策としてクライアントレベルで先回り
軽快なUXを維持しつつ、DBの二重登録リスクを低減できるため、日常的な利用に適しています

例2：公共サービスの申請フォーム

行政や教育機関などのフォームでは、一度限りの登録処理を厳密に制御したい場面が多く見られます。

推奨パターン：Anti-Forgery Token + サーバー側重複チェック

Anti-Forgery Tokenを用いて、一度使用したトークンの再使用を防止
登録内容に基づくハッシュ重複チェックにより、サーバー側での確実な制御を実現
信頼性と再現性を重視したシステムに向いており、訴訟リスクの高い公共系の処理にも適しています

例3：キャンペーン応募フォーム（個人ユーザー向け）

一時的にアクセスが集中するキャンペーンページでは、UXの損失を最小限にしながらも、簡易的な不正防止策が求められます。

推奨パターン：JavaScriptのボタン無効化のみ

クライアントレベルで簡単に導入可能で、通信量やサーバー負荷を軽減
高速かつスムーズな体験を維持しやすく、リソースの少ない小規模サイトにも最適

まとめ

ASP.NET MVCを利用したWebアプリケーションにおいて、フォームの二重登録は軽視できない重大な問題です。ユーザーの「連打」や「更新」操作といったごく自然な行動が、システムの整合性や業務の信頼性を脅かす原因になり得ます。

本記事では、この問題に対して有効な4つの防止手法を紹介しました。

✅ PRGパターン（Post-Redirect-Get）

ブラウザの再送信を根本的に防ぐ設計手法。基本的な防止策として推奨されます。

✅ JavaScriptによるボタンの無効化

ユーザー体験を損なわず、簡単に導入できるクライアント側の対策。PRGパターンと併用すると効果的です。

✅ Anti-Forgery Tokenを活用したサーバー側チェック

CSRF対策を拡張し、トークンの再利用を禁止することで二重送信を防止。セキュリティと整合性を両立できます。

✅ ハッシュや楽観ロックによる重複検出

データベースレベルで重複登録を検知。内容の一致判定によって、意図しない重複登録を防げます。

さらに、システムの性質に応じてこれらを適切に組み合わせることが重要です。たとえば業務系アプリではPRG＋ボタン無効化、公共申請システムではトークン＋ハッシュチェックなど、それぞれの場面に応じた対策を選択しましょう。

最後に一言。ユーザーの信頼を損なわず、堅牢なシステムを構築するには、こうした「小さな配慮」が大きな成果を生みます。日々の開発の中で、ぜひこれらの実装パターンを活用してみてください。