連載Index（読む順・公開済リンクが最新）: S00_門前の誓い_総合Index

x => ... が出てくると、意味が取れずに手が止まる。
レビューでも「このラムダ、何受けて何返してるの？」の確認から先に進みにくい。

止まる理由の多くは単純で、ラムダ単体だと 引数型と戻り値型が省略されるため。
読み解き方さえ固定できれば、ラムダは怖くない。

このページで伝えたいことは2つだけ。

x => ... は 受け取る側の型 で形が決まる（＝読み方の本体）
現場で死ぬのは クロージャ失敗パターン（ループ変数 / イベント購読 / async void 化）

30秒で結論（ここだけで現場が止まらない）

ラムダが読めない -> 「代入先 / 渡し先の型」を見る（Func / Action / イベント型）
ループ内で作ったラムダが、全部同じ値を表示する
例: 0,1,2 のつもりが 3,3,3 になる -> ループ変数を ローカルへ退避して捕捉する（ -> 5-1）
イベントが解除できない（-= が効かない） -> ラムダを 変数に保持して -=（またはメソッドへ戻す）（ -> 5-2）
Action に async を付けると危険（async void） -> Func<Task> に合わせる（待てる/合成できる/例外が扱える）（ -> 5-3）

まず逆引き（症状 -> 原因 -> 最短対策）

症状（現場で見るやつ）	だいたいの原因	最短対策
`x => ...` で止まる	受け取る側の型が見えていない	代入先/引数/イベント型を見る（ -> 「2」）
引数の型が分からない	推論元が見えていない	`(string s) => ...` と型を一瞬だけ出す（ -> 「2-5」）
戻り値が分からない	`Func/Action` ルールが曖昧	`Func` は最後が戻り値、`Action` は戻り値なし（ -> 「3-1」）
ループ内で作った処理が全部同じ値	変数そのものを捕捉している	`var index = i;` で退避（ -> 「5-1」）
`-=` でイベント解除できない	追加したハンドラと同一でない	参照保持して `-=` / メソッド名へ戻す（ -> 「5-2」）
`Action` + `async` が地雷	`async void` になり待てない/合成できない/例外が扱いづらい	`Func<Task>` に合わせる（ -> 「5-3」）
`Expression` で急に難しい	実行ではなく“構造”を渡してる	`IQueryable` か確認（ -> 「4」）

チートシート（受け取る側 -> ラムダの形が決まる）

注:

TSource は列（シーケンス）の要素型
TResult は戻り値の型

受け取る側（要求される形）	ラムダの形	意図（何を渡しているか）
`Func<T, TResult>`	`(T x) => TResult`	「Tを受けてTResultに変換する」
`Func<T, bool>`	`(T x) => bool`	「条件（フィルタ）を返す」
`Action<T>`	`(T x) => void`	「Tに対して副作用（表示/保存）だけする」
`EventHandler`	`(object? sender, EventArgs e) => void`	「イベント通知を受けて処理する」
`Expression<Func<T, bool>>`	`(T x) => bool` の“構造”	「実行ではなく解析（SQL化など）される」

1. ラムダ式は2種類だけ（式ラムダ / 文ラムダ）

ラムダ式は 引数 => 本体 の形で「その場で小さい処理（関数）を作って渡す」記法。

式ラムダ: => の右が1つの式（値を返す）
文ラムダ: => { ... } のブロック（複数行、戻り値があるなら return）

// 意図: LINQ の中で「条件」と「変換」を短く渡したい
var names = new[] { "A", "", "BB" };

var lengths = names
    .Where((text) => text != "")        // 意図: 空文字は除外したい（条件）
    .Select((text) => text.Length)      // 意図: 文字列 -> 長さへ変換したい（変換）
    .ToArray();

// 意図: 比較ロジックが複数行になるなら「文ラムダ」で書く
var values = new List<int> { -3, 2, -1, 10 };

values.Sort((x, y) =>
{
    // 意図: 絶対値の大小で並べ替えたい
    return Math.Abs(x).CompareTo(Math.Abs(y));
});

2. `x => ...` の解読は「受け取る側」を見る（ここが本体）

止まる理由はだいたい「型が省略されている」だけ。
ラムダの引数型 / 戻り値型は、ラムダを受け取る側（代入先、メソッド引数、LINQ、イベント）で決まる。

2-1. 代入先で読む（型が見えれば止まらない）

// 意図: 「文字列が空か？」の判定を関数として持ち回りたい
Func<string?, bool> isEmpty = (text) => string.IsNullOrEmpty(text);

var input = "";
if (isEmpty(input))
{
    Console.WriteLine("empty");
}

型を書きたくないなら、ローカル関数へ戻す手もある（名前が意図になる）。

// 意図: 呼び出し側を読みやすくする（名前に意図を込める）
static bool IsEmpty(string? text) => string.IsNullOrEmpty(text);

2-2. メソッド引数で読む（渡し先が答え）

// 意図: 「変換処理」を外から差し替えられるようにする
static void Apply(Func<int, int> transform)
{
    Console.WriteLine(transform(10));
}

// transform が Func<int,int> なので、(x) は int で戻り値も int
Apply((x) => x * 2); // 意図: 10を2倍して出したい

2-3. LINQで読む（Where/Selectが要求する形）

// 意図: フィルタ（bool）と変換（TResult）を渡しているだけ
var filtered = names
    .Where((text) => !string.IsNullOrEmpty(text)) // 意図: 残すものだけ True を返す
    .Select((text) => text.Length)                // 意図: 残った要素を別の値に変換する
    .ToArray();

2-4. イベントで読む（イベント型が答え）

// 意図: クリック通知を受けたら処理したい（副作用）
button.Click += (sender, e) =>
{
    Console.WriteLine("clicked");
};

2-5. それでも読みづらい時の手当て（現場の速度を上げる）

状態	手当て	何が良くなるか
引数型が見えない	引数型を明示	一瞬で読みが確定する
省略が多くて追えない	一時変数へ逃がす	右側の塊が分割される
引数名が意味不明	役割に合わせて改名	読む人の脳内変換が減る
ラムダが長い	メソッド名へ戻す	意図が名前に乗る

// 意図: 「この条件の意味」を名前にして、レビューを速くする
Func<string, bool> isNonEmpty = (text) => !string.IsNullOrEmpty(text);

var result = names.Where(isNonEmpty).ToArray();

3. delegate / Action / Func は「シグネチャ」で読む

現場で多く見るのは「Func/Action を書いて代入」より、
LINQ / イベント / メソッド引数の中に出てくるラムダ。

3-1. `Func` / `Action` の最小ルール（これだけ）

Func は 最後の型引数が戻り値（それ以外は引数）
Action は 戻り値なし（引数だけ）

// 意図: 2引数を受けて int を返す（計算結果を返したい）
Func<int, int, int> add = (a, b) => a + b;

// 意図: 文字列を受けて、表示するだけ（戻り値は要らない）
Action<string> log = (message) => Console.WriteLine(message);

4. Expression（式ツリー）は「実行」ではなく「構造」

ここは DB/ORM（EFなど）や外部クエリ を触っている人向け。
使っていないなら「IEnumerable は実行、IQueryable は式（構造）」だけ押さえて先へ進んでOK。

Expression<Func<...>> は、処理を実行するためではなく「式の構造」を渡すために使う。
典型は IQueryable 系で、式ツリーを解析して SQL などへ変換する。

using System.Linq.Expressions;

// 意図: 「x > 10」という条件“そのもの”をデータとして持ち回りたい
Expression<Func<int, bool>> expr = (x) => x > 10;

// 意図: 構造を眺められる（解析される世界）
Console.WriteLine(expr.Body); // x > 10

// 意図: 必要なら実行用の関数に変換できる
Func<int, bool> f = expr.Compile();
Console.WriteLine(f(11)); // True

// 意図: IEnumerable は「その場で実行する関数(Func)」を受け取る
IEnumerable<int> xs = new[] { 1, 2, 3 };
var a = xs.Where((x) => x > 1); // Func<int,bool>

// 意図: IQueryable は「後で解析する式(Expression)」を受け取る
IQueryable<int> q = new[] { 1, 2, 3 }.AsQueryable();
var b = q.Where((x) => x > 1);  // Expression<Func<int,bool>>

5. クロージャ（キャプチャ）落とし穴3つ（ここで失敗パターンが止まる）

ラムダの中で外側の変数を参照すると、コンパイラは値を保持する仕組みを作る。
これがキャプチャ（closure）。

踏みやすいのは次の3つ。

ループ変数: 「その周回の値」のつもりが、後で全部同じ値になる
イベント購読: 解除できず参照が残り続ける
Action + async: async void になり、待てず・合成できず・例外が扱いづらい

5-1. ループ内で作ったラムダが、全部同じ値を表示する（0,1,2のつもりが3,3,3）

現場あるある
「ボタンを3つ作って、それぞれクリックで自分の番号を出したい」
…つもりが、全部が最後の番号を出してしまう。

再現（失敗パターンが出る形）

// 意図: 0,1,2 を表示するアクションを3つ作りたい（…つもり）
var actions = new List<Action>();

for (int i = 0; i < 3; i++)
{
    // 意図: i を表示する処理を“あとで”実行したい
    actions.Add(() => Console.WriteLine(i));
}

actions.ForEach((a) => a());

// 期待: 0,1,2
// 実際: 3,3,3（= i は「値」ではなく「変数」として捕捉され、実行時点の最終値を見る）

何が起きているか（要点だけ）

ラムダは i の「値」をコピーしているのではなく、i という変数そのものを参照する
「あとで実行」する時点では i はループが終わって 3 になっている
-> だから全部が 3 を表示する

回避（最小で効く策：退避して捕捉）

// 意図: 「その周回の値」を固定したい -> ローカルへ退避して捕捉する
var actions = new List<Action>();

for (int i = 0; i < 3; i++)
{
    var index = i; // 意図: 値を固定する（この変数を捕捉させる）
    actions.Add(() => Console.WriteLine(index));
}

actions.ForEach((a) => a());
// 0,1,2

5-2. イベント解除できない（`-=` が効かない）を設計で潰す

起きる現象
ラムダで += したイベントは、見た目が同じラムダを書いても -= で外れない。
解除できず、長寿命の発行元から参照され続ける形になりやすい。

// 意図: クリックでログを出したい（購読）
button.Click += (sender, e) => Console.WriteLine("tick");

// 意図: 後で解除したい（…つもり）
// しかしここで書いたラムダは「別インスタンス」なので一致せず外れない
button.Click -= (sender, e) => Console.WriteLine("tick");

回避A（参照を保持して外す：最小で堅い）

// 意図: 追加したハンドラと“同一の参照”を保持して、確実に外す
EventHandler? onClick;

public void Wire(Button button)
{
    onClick = (sender, e) => Console.WriteLine("tick");
    button.Click += onClick;
}

public void Unwire(Button button)
{
    if (onClick is null) return;
    button.Click -= onClick;
    onClick = null;
}

回避B（メソッド名へ戻す：読みやすさが強い）

// 意図: “同じメソッド”を登録/解除すれば一致する（読みやすい）
button.Click += OnClick;
button.Click -= OnClick;

static void OnClick(object? sender, EventArgs e)
{
    Console.WriteLine("tick");
}

5-3. `Action` に `async` を付けると `async void`：待てない/合成できない/例外が拾いづらい

Action は戻り値が void。
ここに async を付けると async void になる。
この形が怖いのは、次の3つが同時に起きるから。

5-3-1. 待てない（呼び出し側が“終わった”と勘違いする）

// 意図: 「終わるまで待ってから次に進みたい」（…つもり）
Action run = async () =>
{
    await Task.Delay(100);
    Console.WriteLine("done");
};

run();

// 意図: ここは本当は done の後に進んでほしい（…つもり）
// しかし async void なので待てない。先に進んでしまう。
Console.WriteLine("caller finished");

5-3-2. 合成できない（WhenAll / リトライ / タイムアウトに組み込めない）

Task を返さないので、Task.WhenAll に載せられない。
つまり「複数をまとめて待つ」「まとめて例外を見る」「タイムアウトを付ける」がやりにくくなる。

// 意図: 複数処理をまとめて終わるまで待ちたい（…つもり）
var actions = new List<Action>
{
    async () => await Task.Delay(10),
    async () => await Task.Delay(20),
};

// Action なので Task が取れない -> WhenAll に載せられない
// await Task.WhenAll(actions.Select(a => ???)); // できない

5-3-3. 例外が拾いづらい（try/catch で捕まらない）

// 意図: try/catch で例外を扱いたい（…つもり）
try
{
    Action bad = async () =>
    {
        await Task.Delay(10);
        throw new InvalidOperationException("boom");
    };

    bad();
}
catch (Exception ex)
{
    // 意図: ここで捕まえたい（…つもり）
    // しかし async void の例外は呼び出し元へ戻らず、ここで捕まらない
    Console.WriteLine(ex);
}

解決：`Func<Task>` に合わせる（待てる・合成できる・例外が扱える）

// 意図: await できる形にする（待てる・合成できる・例外が集約される）
Func<Task> job = async () =>
{
    await Task.Delay(100);
};

await job(); // 意図: 呼び出し側が「終わり」を正しく扱える

// 意図: 複数の非同期処理をまとめて待ちたい（WhenAll できる）
var jobs = new List<Func<Task>>
{
    async () => await Task.Delay(10),
    async () => await Task.Delay(20),
};

await Task.WhenAll(jobs.Select((j) => j()));

UIイベントはどうするか（現場の落としどころ）

UIイベントはシグネチャ都合で async void になりやすい。
だからこそ「例外を握り潰さず、必ずログに残す」型を用意しておくと失敗パターンが減る。

// 意図: async void を“必要悪”として使う場合でも、例外だけは必ず捕まえて残す
button.Click += async (s, e) =>
{
    try
    {
        await Task.Delay(10);
        // ...
    }
    catch (Exception ex)
    {
        // 意図: ここでログ（R05の方針へ）
        Console.WriteLine(ex);

        // 設計により：UIなら持つ/通知する、サーバなら上位へ投げる等（R04）
        // throw;
    }
};

6. ラムダとチェーンは別物（混ぜて考えると読めない）

チェーン: メソッド呼び出しを連ねた構造（Where(...).Select(...).ToList()）
ラムダ: その引数として渡す関数値（... の部分）

// 意図: 「残す」「変換する」「並べる」を順にチェーンで書く
var result = orders
    .Where((o) => o.IsActive)                 // 意図: 残す条件
    .Select((o) => new { o.Id, o.Total })     // 意図: 必要な形へ変換
    .OrderBy((x) => x.Total)                  // 意図: 並べ替えキーを返す
    .ToList();

見方はこの順番で安定する。

Where/Select/OrderBy は「何を要求するか」が決まっている
右側の (o) => ... は「要求された形」へ当てはまるだけ
型が見えない場合は、拡張メソッド定義へ戻る（Func<TSource,bool> など）

保存用チェックリスト（レビューで一発で潰す）

ラムダが読めない -> 受け取る側の型を見る（代入先/引数/イベント型）
ループ内ラムダが“あとで実行される” -> ループ変数は 必ず退避
イベント購読をラムダで書いた -> 解除できる形（参照保持 or メソッド）になっているか
Action に async を付けてないか -> Func<Task> に合わせる（WhenAllできるか）
IQueryable で Where(x => ...) を書いた -> Func ではなく Expression（= 解析される）

.NET Framework 4.8 補足（差分が出やすい点だけ）

.NET Framework 4.8 でもラムダ式 / Action / Func / Expression の基本は同じ。
差分が出やすいのは「nullable参照型」の有無と、利用するAPI群（.NET 8 側で追加された便利APIなど）。

string? のような nullable 注釈は、プロジェクト設定とコンパイラに依存する
ラムダの読み方（型は受け取る側で決まる）は変わらない

次に読む（1本だけ）

R05: ログ設計（証拠を残す / 構造化ログ）

連載Index（読む順・公開済リンクが最新）: S00_門前の誓い_総合Index