.NETライブラリのパフォーマンス最適化事例―AutoMapper・MediatR・EF Core運用で比較する速度差と実践的改善策

AutoMapper・MediatR・EF Coreなど.NETライブラリの実運用で、サクッと速度アップ＆ストレス減を狙える時短テク集です。

AutoMapper使ってるなら、10行以下のシンプル変換は手書きコードに一度差し替えてみて。
5分で差し替え→速度2～4倍感じることが多いです（切り替え後1日アプリ応答時間を比べてみて）。
MediatR導入済みなら、リクエスト数が1000/秒を超える処理は一回だけ直接サービス呼び出しにも変えて試そう。
CPU使用率が10％前後落ちて、レイテンシも体感速くなることが多い（1時間後にCloudWatchやtopで数字確認）。
EF Coreで遅いなと思ったら、3件以上JOINするクエリだけDapperや生SQLで書き換えテストをやってみて。
同じデータ量でも処理時間が半分以下になることが多い（30分だけ切り替え前後の平均実行秒数を比べてみて）。
2025年も使えるけど、.NETライブラリの速度を測りたい時はBenchmarkDotNetで3分だけ手元ベンチしてみると◎。
実環境で数字が出るから「なんとなく遅い」が消える（ベンチ後すぐ結果グラフをエクスポートして比較）。

AutoMapper利用時にどこで性能コストが発生するか見極めよう

こういったライブラリって、正直、パフォーマンスよりも柔軟さや扱いやすさ、あとは機能の豊富さなんかが重視されがちなんですよね。まあ、このあたりは多くのケースで悪いことじゃないと思うんですが、たとえば「これ絶対に速くなきゃ困る！」っていうガチ目なパフォーマンス要件がある場合や、自分の使い方がライブラリの想定とちょっとズレてたりすると、急に厄介になることがあります。ま、いいか。

## AutoMapper：便利だけど…

AutoMapperは「パフォーマンスで大丈夫なの？」って何かと話題になりがちなライブラリです。オブジェクト間のマッピングをサクッと自動化できる便利さはありがたいんですが、その快適さにはわりと目立つオーバーヘッドもついてくる感じですね。

## ひっそり潜むコスト

AutoMapperで実際にボトルネックになりうる要素はだいたい以下みたいです。
1. **リフレクションの負担**: プロパティを探したり、マッピング設定を作ったりするときにリフレクションが結構使われます。
2. **式ツリーのコンパイル**: 設定が複雑なときには、ランタイム中に式ツリーをコンパイルしないと動かないケースも出てきます。
3. **値型のボックス化**: 値型データは変換途中でけっこうボックス化（逆も）されがちです。
4. **余計なメモリアロケーション**: マッピング処理中に一時的なオブジェクトをさらに作るので、知らないうちにメモリアロケーションが増えます。

## AutoMapperベンチマーク体感

じゃあ、実際どれくらい違うん？ということで、ごくシンプルなベンチマーク例を貼りますね。

[MemoryDiagnoser]
[SimpleJob(RuntimeMoniker.Net80)]
public class MappingBenchmark
{
private readonly Mapper _mapper;
private readonly UserDto _userDto;

public MappingBenchmark()

    {

        var config = new MapperConfiguration(cfg =>

            cfg.CreateMap<UserDto, User>());

        _mapper = new Mapper(config);css

_userDto = new UserDto 

        { 

            Id = 1, 

            Name = "John Doe", 

            Email = "" 

        };

    }

    [Benchmark]

    public User AutoMapperMapping()

    {

        return _mapper.Map<user>(_userDto);

    }

    [Benchmark]

    public User ManualMapping()

    {

        return new User

        {

            Id = _userDto.Id,

            Name = _userDto.Name,

            Email = _userDto.Email

        };

    }

}

<pre><code>

体感としては、手動マッピングならAutoMapperの5倍から10倍くらい速くなるし、メモリアロケーションも本当に必要最低限になるイメージです。単純にプロパティ3個移すだけのコードでもAutoMapperだと150ns・200バイト以上消費しているところ、手作業だと15nsで収まってアロケーションもミニマム。この辺、それぞれ一長一短なので、自分の用途や好みによって選ぶのがいいんじゃないかな。

マッピング高速化を目指し、代替アプローチを試してみよう

パフォーマンス優先で考えたいとき、自動マッピングの便利さはそのままに、よりサクサク動かしたい場合はいくつかやり方が思い浮かびますね。例えば、1. **Mapster**――これ、とても処理が速いと評判な選択肢だったりします。2. **手動ファクトリー**の導入もアリで、複雑な変換が必要なときには自分専用のファクトリークラスを作っちゃうのもアプローチかなって感じです。3. **ソースジェネレーター**を使う手もありますよ。つまり、マッピング用コードをビルド時に生成しておく方式ですね。4. そして、**式ベースのマッピング**という方法も。これは前もって式をコンパイルしておいて繰り返し流用するイメージ……あれ、こう書くと意外と選択肢が広いかもしれません。

## MediatR：CQRS導入時に気になるパフォーマンスコスト

MediatRって、.NET系でCQRSやメディエーター・パターン組み込むなら今や定番ツールですよね。でも、その仕組み上すごく便利ではあるんですが──実は意外と無視しづらい“オーバーヘッド”も潜んでいる気がします。

## MediatRによるオーバーヘッドって何？

じゃあ具体的にMediatRで発生する主なパフォーマンス負荷はどんなもの？…と思ったので整理してみました。1. **サービスロケーターパターン**：これは依存性注入コンテナ越しにハンドラー解決する方式ですね。2. **パイプラインオーバーヘッド**：各リクエストが毎回全部メディエーターパイプラインを通過する構造になっています。ま、いいか。そのへんは覚えておいたほうが良さそうです。

MediatR導入でパフォーマンス低下が起きる理由をチェックしよう

リフレクションコストというのは、たとえばハンドラの検出や呼び出し時に発生するオーバーヘッドだったり、それから追加の抽象化によって無駄なメソッド呼び出しやオブジェクト割り当てが増える、みたいなことですね。ふぅ……ちょっと考えながら続けます。

MediatR のパフォーマンスってどうなのか、ちょっと計測コード例を紹介します。

[MemoryDiagnoser]
public class MediatorBenchmark
{
private readonly IMediator _mediator;
private readonly DirectService _directService;

[Benchmark]

    public async Task<string> MediatRCall()

    {

        return await _mediator.Send(new GetUserQuery { Id = 1 });

    }

    [Benchmark]

    public async Task<string> DirectCall()

    {

        return await _directService.GetUserAsync(1);

    }

}

普通にベンチマークを走らせてみると、直接サービスを呼び出した場合、MediatR を使うよりだいたい2〜4倍くらい速くなります。実際、リクエストがバンバン来る場面ではそのオーバーヘッドが気になってくるんですよね（まぁ、それでも困らない状況もあるとは思いますが）。

さて、じゃあ MediatR を見直したほうがよさそうなシーンですが……

- 秒間で何千件も処理が発生するような負荷の高いシナリオ
- ハンドラ自体がシンプルでメディエーター・パターン特有の恩恵を得られないケース
- パフォーマンス命なマイクロサービス環境を作ろうとしているとき
- アーキテクチャ的メリットよりパフォーマンスコストの方が重いと思われる場合

こういう時は、「本当にMediatR必要？」って一度立ち止まっても良さそうです。

もっと軽量な方法も、実はいくつかあります：

1. サービスの直接注入：必要に応じて DI で直に渡してあげる
2. エンドポイントごとのハンドラー：Web API なら Endpoint Handler を使った最小限API構成
3. 軽量なコマンド／クエリバス：余計な抽象化抜きで簡易メッセージパス方式にする
4. ハイブリッド運用：複雑ワークフローのみ限定的に MediatR を取り入れるみたいな感じ

あと Entity Framework の話にも少し触れておくと……ここ数年EF Coreには結構細かく性能改善が加わったとはいえ、アプリケーション次第でパフォーマンスの元凶にもなる印象です。

たとえばEF関連でよくある落とし穴としては――

1. N+1 クエリ問題：関連データを効率悪く読み込んじゃうパターン
2. 無駄な変更トラッキング：不要なエンティティまで追跡してしまいコスト増大

ま、いいか。今日はこのへんにしておきます。やっぱり設計判断、大事だよね。

ハンドラー頻度や構成によってMediatRの活用是非を判断しよう

うーん、朝起きたてだから少し頭がボンヤリしてるけど……Entity Framework（EF）のパフォーマンス検証ってやっぱ気になるテーマだよね。特に、遅延読み込み時のオブジェクトを辿った結果、裏でこっそりクエリが実行されちゃうとか、LINQで凝った書き方すると意図したSQLに変換されずパフォーマンスに響く…なんて場面もありがちだと思うんだ。まあ、厳密な動作は環境依存もするし断言できないところもあるかな。

<pre><code class="language-sql">そうそう、下記のサンプルベンチマークは結構有名な比較方法として挙げられることが多いよ。

[MemoryDiagnoser]

public class EFBenchmark

{

    private readonly AppDbContext _context;

    private readonly IDbConnection _dapperConnection;

    [Benchmark]

    public async Task<List<User>> EFQuery()

    {

        return await _context.Users

            .Where(u => u.IsActive)

            .ToListAsync();

    }

    [Benchmark]

    public async Task<List<User>> DapperQuery()

    {

        return (await _dapperConnection.QueryAsync<User>(

            "SELECT * FROM Users WHERE IsActive = 1")).ToList();

    }

    [Benchmark]

    public async Task<List<User>> EFNoTracking()

    {

        return await _context.Users

            .AsNoTracking()

            .Where(u => u.IsActive)

            .ToListAsync();

    }

より軽量なリクエスト処理方法でサービス効率化に取り組もう

- **複雑なレポーティング**: Raw SQLの方がサクサク進めるときもあるんだよね。
- **マイクロサービス**: なんだかんだ軽量ORMが一番相性いい気がしてる。
- **パフォーマンス重視の経路**: 場面によっては、ダイレクトにデータアクセスした方がベターな時も普通にある。

## ベンチマーク手法について

ライブラリ選定を後悔しないようにするには、ちゃんと筋の通ったベンチマークルールを敷く必要があるってわけ。いやまあ僕自身「絶対コレ！」みたいな自信はないけど、なんとなく一貫性を持たせること自体はすごい重要だと思う。

## BenchmarkDotNetで測る例

csharp

[MemoryDiagnoser]

[SimpleJob(RuntimeMoniker.Net80)]

[RPlotExporter]

public class LibraryBenchmark

{

    [GlobalSetup]

    public void Setup()

    {

        // テスト用データやらサービス初期化処理とかここでまとめてやっちゃう。

    }

    [Benchmark(Baseline = true)]

    public void Baseline()

    {

        // 比較用（たぶん素朴実装？）。

    }

    [Benchmark]

    public void LibraryImplementation()

    {

        // 各ライブラリごとの検証本体を入れる感じかな。

    }

}

## チェックしたい主要指標あれこれ

1. **実行時間**：平均・中央値・パーセンタイル色々計っときたい（多いと楽しいよ）。
2. **メモリアロケーション**：トータルバイト数だけじゃなく回数も無視できない。
3. **スループット**：秒間でどれだけ捌けてるか負荷次第で全然違うから見ておきたい。
4. **スケーラビリティ**：負荷増やしたらどう変化するか、後々響いてくること多め。

## 実際試す時のちょっとした工夫

1. **実状っぽいデータ規模を使うこと**：ちまいサンプルより現場サイズ前提で測らないと意味薄いし、不意打ち食らうぞ…ま、いいか。
2. **セットアップ費用含めて計測すること**：初期オーバーヘッド完全無視しちゃうともったいないので広めに押さえたい気分。
3. **そこそこ負荷乗せた状態でも検証してみること**：特定条件下のみ速くても、急にボトルネック目立つ時ある（結構よく見かける）。
4.

Entity Framework Coreの代表的な性能落とし穴に備えよう

初回起動時のパフォーマンスって、意外と大事なんだよね。だからこそ、単に開発用マシンでテストするだけじゃなくて、本番環境にできるだけ近い場所でベンチマークを取るのがいいと思う、たぶん。

## 代替アプローチとトレードオフ ##

実際のところ、ライブラリごとに性能の幅がかなり広い感じ。特に、カテゴリごとに速さが変わるんだ。

**マッピングソリューション**（早いものから順番に並べると）：
1. 手作業で書いたマッピングコード
2. ソース生成を使ったマッパー
3. コンパイル済み式ベースのマッパー（Mapster）
4. リフレクション方式のマッパー（AutoMapper）

**リクエスト処理**（こちらも速さ順）：
1. 直接的なメソッド呼び出し
2. 軽量なメッセージパッシング
3. 完全なメディエーターパターン（MediatR）

うーん、どうやって選ぶかは用途次第だけど、とりあえず比較してから考えても遅くはない気がする。ま、いいか。

Dapper・EF・手動SQLの速度差を数値で比較し直そう

重厚なオーケストレーションフレームワークで**データアクセス**の速さを語ると、「1. 手書きSQL＋ADO.NET、2. DapperなどのマイクロORM、3. チューニング済みEF Coreクエリ、4. 素の（トラッキング付き）EF Core」って順番かなあ。正直、この辺はお約束っぽいんだけど、一律に「これがベスト！」みたいに決めつけるのは無理そう。まず自分たちのアプリで“ここ絶対パフォーマンス命！”という場所をはっきり知る必要がある。

やっぱり最初にプロファイリングして、本当に効いてくるホットパスがどこなのか見極めないと意味ないと思う。パッと見重要そうでも、全体にはそんな影響出てないケースもあるし……まあ、ま、いいか。本当は計測データありきで判断したいね。ちなみに「なんとなく気になったら即チューニング」というのはおすすめできないよ。早すぎる最適化ほどあとで足枷になるものってほぼないので。

それから、純粋な速度至上主義だと後悔する場合も多いんだよね。正直なところ、可読性とか保守性とのバランス取りはガチで大事だと思う。一時的にほんの少し遅くなる部分があったとしても、大規模PJや長寿サービスならメンテ重視も賢明っていう例、思い当たる人もいるんじゃない？

実プロジェクト向けに.NETライブラリのベンチマーク手法を導入しよう

スケールする場合、性能要件がどう変わるか―まあ、ちゃんと考えないと後で詰むかも。特にユーザー数が増える時なんか、想定してなかった負荷って割と普通に来るので油断できない。ぼんやり「まあ大丈夫っしょ」ってやってると危ういな、と感じてます。

## パフォーマンスを意識したアーキテクチャの構築
## ハイブリッドアプローチ

ぜんぶ同じ手法で統一しなくても大丈夫、というか実際けっこうハイブリッド運用になること多い気がします。例えばこんな切り分け方とかね：
1. 管理者画面ではAutoMapperを導入するけど、APIのエンドポイントではあえて手動でマッピングしたりすることもある。
2. MediatRは複雑なワークフローには相性よくて頼りになるけど、シンプルな操作だと素直に直接呼び出すだけのほうが分かりやすい場面も結構多いです。
3. 普通のCRUDはEntity Framework（EF）で十分。ただ、レポート系みたいにちょっと特殊なクエリなら素直に生SQL書いちゃうって選択肢もあり。

## パフォーマンスバジェットの設定

各部分ごとにパフォーマンス目安みたいなの決めておくと迷わないかな、と感じます。たとえば：
- 大事なAPIエンドポイント→応答100ms未満が理想（ここは気合）。
- バックグラウンド処理→ひたすらスループット意識して最適化。
- 管理系UI→パフォーマンスそこそこで良いから、むしろ開発者の生産性を優先。

## モニタリングとアラート設定

性能劣化に気付くの遅れると修羅場なので...一応こんなのチェックしとくのおすすめです：
1. APM（アプリケーションパフォーマンスモニタリング）は本番環境の実測値まで見れるから、一度セットすると心理的にも安心できるかも。
2. ベンチマークはCI/CDパイプライン組み込み型が最近主流。継続的にテストしておけば、「あれ？前より遅くね？」みたいなのにも比較的早めに気づきやすいです。
3. パフォーマンス異常時には通知飛ばすようアラート仕込んでおく―これだけでも被害広がりにくい印象。

## 結論

AutoMapper・MediatR・Entity Frameworkなど.NET界隈で人気高めのライブラリ類、それぞれ開発効率とか設計見直しとか冗長コード削減なんかで役立つ存在ですね。自分自身、この辺組み合わせて色々助かった経験あるので「今後もきっと重宝するだろうな」と思っています。ま、いいか。

シーンごとの適切なツール選びで.NETアプリを高速＆メンテナンス性両立

ただし、この数値には、多くの開発者が気づいていないパフォーマンス負荷が、実は隠れています。とはいえ、目標としては、それらのライブラリを無理に完全排除することではなくて、状況に合わせてうまく使いこなすことなんですよね。うーん、自分のプロジェクト環境ごとにパフォーマンスの特性を掴みつつ、手元でベンチマークもやってみて、開発スピードと動作効率をどうバランスさせるか意図的に選択する姿勢が大事かなと思います。
たとえば焦って最適化だけを追求するとかえって非効率になる場合もあるし、「あとで困った時考えればいいや」と軽くパフォーマンスを放置していると取り返しがつかなくなることも……。どちらもちょっと危うい感じしますよね。実際によく出来たアプリケーションというのは、その辺りを絶妙に調整して、自分たちの要件に本当に合ったツールだけを見極めて使っています（まぁ一律な定石には頼りません）。
この記事で紹介したようなベンチマーク手法とか代替案なんかも頭に入れておけば、有名どころのライブラリが本当にコスト相応なのかとか、「今はもっと軽量な手段でもいいんじゃない？」って場面などについて、一歩引いた判断ができるようになると思います。一番大切なのは「ちゃんと計測して把握する」「深く理解する」、それから「納得づくで道具を選ぶ」ってところです、きっと。この視点やノウハウさえ押さえておけば、保守性にも優れ、高速動作も狙えるアプリケーションづくりにつながる……そんな予感しません？ま、いいか。