MENU

LINQ（EF/SQL）で取得したdecimal金額を3桁区切り（カンマ）表示する方法｜ToString(N2)とEF変換の注意点

C#

ASP.NET（C#）で、LINQ（EF/SQL）から取得した decimal? の金額を一覧表示するとき、「1000.00 → 1,000.00」のように3桁区切りで見やすくしたい場面はよくあります。ただし、LINQで返ってくるのは“数値”なので、そのままでは区切り記号は付きません。この記事では、EFの変換制約や実務でハマりやすい点も含めて、いちばん安全で保守しやすい整形方法を整理します。

目次

なぜLINQで取得したdecimalに「カンマ」が付かないのか

結論から言うと、3桁区切りは「表示形式」であり、decimal（数値型）の値そのものに付与される情報ではありません。DBから取ってきた 1000.00 は、あくまで 1000.00 という数値で、カンマ付きの「1,000.00」は文字列としての表現です。

そのため、基本方針は次のどちらかになります。

  • データはdecimalのまま保持し、画面表示（View/UI）でフォーマットする（推奨）
  • 取得後に C# 側で文字列に変換して返す（APIの仕様上どうしても文字列で返したい等）

代表的なフォーマット指定（N2 と #,##0.00）

まずはよく使う書式の違いを押さえると、迷いが減ります。

書式例（1000）特徴向いている場面
"N2"1,000.003桁区切り＋小数2桁。区切り記号はカルチャ依存通常の日本語環境/ユーザー設定に合わせたい
"#,##0.00"1,000.00カスタム数値書式。桁区切りと小数桁の表現を細かく固定できるUIの見た目を明確に固定したい
"#,##0"1,000整数表示（小数なし）請求書の「数量」や「円」表示など
"N0"1,0003桁区切りのみ。カルチャ依存小数不要の金額（円）

最優先のおすすめ：decimalのまま保持して、View/UIで整形する

実務で一番トラブルが少ないのは、DB→アプリ内部では数値のまま扱い、最後に表示する瞬間だけ整形する方法です。理由はシンプルで、並び替え・集計・再利用が圧倒的に楽になるからです。

LINQのselectはdecimal?のまま返す

まずはクエリでは数値を返します。join＋select new の形でもOKです。

public class ReportRow
{
    public decimal? Debited { get; set; }
    public decimal? Credited { get; set; }
    public string AccountName { get; set; } = "";
}

var rows = (
    from a in context.Journals
    join b in context.Accounts on a.AccountId equals b.Id
    select new ReportRow
    {
        AccountName = b.Name,
        Debited = a.Debited,
        Credited = a.Credited
    }
).ToList();

Razorで表示時にToString（N2）する

表示側（View）で整形します。null の扱いは要件に合わせて「空」「0.00」を選びます。

@foreach (var item in Model.Rows)
{
    <tr>
        <td>@item.AccountName</td>
        <td class="text-end">@(item.Debited?.ToString("N2") ?? "")</td>
        <td class="text-end">@(item.Credited?.ToString("N2") ?? "")</td>
    </tr>
}

「null は 0 として出したい」なら次のようにします。

@( (item.Debited ?? 0m).ToString("N2") )

このやり方の強みは、ソートや合計をdecimalのまま正確に処理できることです。たとえば一覧下部に合計行を出す場合、文字列にしてしまうと再パースが必要になり、バグも増えます。

ViewModelに「表示用プロパティ」を用意する（さらに実務向き）

View側にToStringが散らばるのが嫌なら、ViewModelに表示用プロパティを作るのが定番です。

public class ReportRowVm
{
    public string AccountName { get; set; } = "";
    public decimal? Debited { get; set; }
    public decimal? Credited { get; set; }

    public string DebitedText => (Debited ?? 0m).ToString("N2");
    public string CreditedText => (Credited ?? 0m).ToString("N2");
}

Viewはこうなります。

<td class="text-end">@item.DebitedText</td>

この形なら、表示変更（小数0桁にする、マイナス表示を会計形式にする等）が入っても、修正箇所を集約できます。

「クエリ内でToStringしたい」場合に起きること（EF/SQL変換の壁）

「select new の中で ToString(“#,##0.00”) して返したい」という発想は自然ですが、EF Core（またはEF6）では、書式付きToStringがSQLに変換できず例外になることがあります。特に ToString("N2") のような書式指定付きToStringは、SQL側に同等機能がない/変換実装がないため、クエリの翻訳に失敗しがちです。

対処パターンは大きく2つです。

取得してから整形する（ToList後に変換）

まず数値で取り切ってから、C#側で整形します。レコード数が常識的な範囲ならこれが最も安全です。

var raw = (
    from a in context.Journals
    join b in context.Accounts on a.AccountId equals b.Id
    select new
    {
        b.Name,
        a.Debited,
        a.Credited
    }
).ToList();

var rows = raw.Select(x => new
{
    AccountName = x.Name,
    Debited = (x.Debited ?? 0m).ToString("#,##0.00"),
    Credited = (x.Credited ?? 0m).ToString("#,##0.00")
}).ToList();

ただしこの方法は、以降の処理が「文字列」になりやすいので、表示以外の用途（並び替え/集計）を後段でやる可能性があるなら避けるのが無難です。

AsEnumerableで「ここから先はC#側」へ切り替える

どうしてもクエリの流れで書きたい場合は、途中で AsEnumerable() を挟んでサーバー評価→クライアント評価に切り替えます。

var rows = (
    from a in context.Journals
    join b in context.Accounts on a.AccountId equals b.Id
    select new { b.Name, a.Debited, a.Credited }
)
.AsEnumerable() // ここでSQL実行後、以降はC#で処理
.Select(x => new
{
    AccountName = x.Name,
    Debited = (x.Debited ?? 0m).ToString("#,##0.00"),
    Credited = (x.Credited ?? 0m).ToString("#,##0.00")
})
.ToList();

この方法の注意点は、AsEnumerableより前に「絞り込み・並び替え・必要列選択」をできるだけ済ませることです。AsEnumerableを早い位置に置くと、必要以上のデータをDBから引っ張ってしまい、性能が落ちます。

やること推奨する場所理由
Where（絞り込み）SQL側（AsEnumerableより前）件数を減らして転送量・メモリを抑える
OrderBy（並び替え）SQL側（AsEnumerableより前）DBのインデックスやソート最適化を活かせる
ToStringで整形C#側（AsEnumerableより後 or View）SQL変換できない/カルチャ制御が必要

カルチャ（CultureInfo）で区切り記号が変わる点に注意

"N2" のような標準数値書式は、カルチャに依存します。日本語環境なら「,」と「.」で想定通りになりやすいですが、英語圏・欧州圏では区切りが逆になったり、スペースになったりします。

カルチャ書式例（1234.5）イメージ
ja-JPN21,234.50カンマ区切り＋ドット小数
en-USN21,234.50ほぼ同じ
de-DEN21.234,50ドット区切り＋カンマ小数

「必ずカンマ区切り＋ドット小数で固定したい」なら、IFormatProvider を明示します。

using System.Globalization;

var us = CultureInfo.GetCultureInfo("en-US");
var text = (amount ?? 0m).ToString("N2", us);

逆に、「ユーザーのOS設定に合わせたい（日本語でも海外でも自然に見せたい）」なら、カルチャを指定せず ToString("N2") に任せるのが良い選択です。

丸め（四捨五入/切り捨て）要件がある場合の現実的な実装

金額表示は、単に「2桁表示」だけでは済まないことがあります。たとえば業務要件で「端数は切り捨て」「四捨五入は必ず0.5を繰り上げ」などがある場合、表示時の自動丸めに頼ると揉めがちです。

要件が明確な場合は、表示前に丸めを決め打ちしてからフォーマットすると、監査・照合が楽になります。

var v = amount ?? 0m;

// 例：0.5は必ず繰り上げ（AwayFromZero）
v = Math.Round(v, 2, MidpointRounding.AwayFromZero);

var text = v.ToString("N2");

「表示だけ丸めた結果」と「内部計算の結果」がズレるのが一番危険なので、帳票や請求などの重要画面では、丸めはどこでやるか（DB/ドメイン層/UI）をチームで決めておくと事故が減ります。

SQL側でカンマ付き文字列を作るのはアリ？（結論：原則おすすめしない）

SQL Server などには文字列整形の手段（FORMAT等）がありますが、一般に次の理由でおすすめしません。

  • 並び替えが文字列基準になりやすい（”2,000″ < “100,000” のような罠）
  • 集計や計算がやりにくくなる（再パースが必要）
  • DB側で表示仕様を抱えると、UI変更の影響範囲が広がる
  • 関数によってはパフォーマンスやインデックス利用に影響が出ることがある

例外として、次のようなケースではSQL側整形が許容されることもあります。

  • アプリからではなく、DB直叩きの帳票/エクスポートで「見た目の文字列」が最優先
  • 互換性の関係でC#側を変えられず、DB側で出力仕様を固定せざるを得ない

ただし、その場合でも「元の数値列」も一緒に返しておくと、後から救われます。

よくある実装パターンまとめ（おすすめ順）

パターン実装場所おすすめ度ポイント
ViewでToString(“N2”)Razor/UI高データは数値、表示は表示。最も保守しやすい
ViewModelに表示用プロパティViewModel高表示変更に強い。ToString散乱を防げる
ToList後にSelectで文字列化C#（取得後）中APIの返却仕様が文字列なら便利。後段処理が増えると不利
AsEnumerableでクライアント評価に切替LINQ途中中便利だが置き場所を誤ると性能劣化。絞り込みは前で
SQL側で整形（FORMAT等）DB低表示都合でDBを汚しやすい。原則避ける

実務でのおすすめ構成（テンプレとして使える形）

「金額の3桁区切り」を安定運用したいなら、次の形が扱いやすいです。

  • DB/EFからは decimal? のまま受け取る（nullもそのまま）
  • Controller/Serviceで ViewModel に詰め替える（必要なら丸めや0扱いを統一）
  • ViewModelに 表示用Textプロパティを用意してViewはそれを表示する
  • カルチャ固定が必要なら CultureInfo を明示（どこで固定するかも統一）

最後に、金額表示でありがちな「いつの間にか仕様が増える」ポイントも押さえておくと安心です。

  • マイナスの見せ方（-1,000.00 / ▲1,000.00 / (1,000.00)）
  • null の扱い（空欄 / 0 / -）
  • 円・ドルなど通貨記号の付与（¥1,000 / 1,000円）
  • 小数桁（0桁固定、2桁固定、入力値に合わせる）

これらは後から必ず議題に上がるので、最初から「数値は数値」「表示は表示」という分離をしておくと、拡張が驚くほど楽になります。

C#
数値フォーマット DECIMAL C# LINQ EF Core

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次