ブロックやProcやLambdaの違いが難しくてわからない！Ruby特有のクロージャの概念をマスターする解説

Rubyを学び始めてしばらく経つと、必ず立ちはまる壁がある。
ブロック、Proc、Lambda。
これらはどれも「コードのかたまりを変数に入れておく」という似たような役割を果たすのに、なぜか違う名前がついている。
さらに厄介なのは、それぞれに微妙に異なる挙動が存在し、特に引数の扱いやreturnの振る舞いが異なる点だ。
初学者にとっては「なんでこんなに複雑な仕組みが必要なのか」と、正直言って面食らうこともあるだろう。

しかし、これらは単なる煩雑な文法ではない。
コンピュータサイエンスの文脈でいえば、クロージャ（closure）という強力な概念の具体例にほかならない。
Rubyにおけるブロック・Proc・Lambdaは、関数型プログラミングのエッセンスをオブジェクト指向言語に巧みに取り入れた設計であり、理解すればコードの表現力と再利用性を飛躍的に高められる。

この記事では、まずそれぞれの基本構文を整理し、次に以下の観点から違いを体系的に解説する。

• 文法上の違い（do...endと{}、メソッド引数としての受け渡し）
• returnやbreakのスコープの違い
• 引数チェックの厳密さ（Lambdaの厳格さとProcの寛容さ）
• オブジェクトとしての扱いの違い

最終的には、「どの場面で何を使えばいいのか」という実践的な指針を示す。
理論と実践の両輪で、このRuby特有のクロージャの世界をしっかりとマスターしていこう。

Rubyのクロージャとは？ブロック・Proc・Lambdaの基礎概念を理解する

プログラミング言語を学ぶ上で、クロージャ（closure）は避けて通れない重要な概念の一つである。
コンピュータサイエンスの文脈でいえば、クロージャとは「関数と、その関数が参照する外部の変数環境をセットにしたもの」と定義される。
つまり、関数が定義された時点のスコープを「閉じ込めて」持ち歩く仕組みであり、これがクロージャという名前の由来となっている。

Rubyにおいては、このクロージャの概念がブロック（block）、Proc、Lambdaという三つの形で実装されている。
いずれも「コードのかたまりを変数に格納し、後から呼び出す」という共通の性質を持つが、文法や挙動に微妙な違いが存在する。
この違いを理解することが、Rubyの高度なプログラミング技法を身につける第一歩となる。

なぜRubyには三つの形態が存在するのか

Rubyの設計者であるまつもとゆきひろ氏は、言語設計において「プログラマの幸福を最大化する」という理念を掲げている。
その結果、Rubyは「同じことを複数の方法で書ける」という特徴を持つ。
ブロック・Proc・Lambdaの三形態も、この設計思想の表れと言える。

ブロックはRubyで最も頻繁に使われるクロージャの形態である。
eachやmapといったイテレーターメソッドに渡す「do...end」や「{}」で囲まれたコードのかたまりが、まさにブロックに該当する。
ブロック自体はオブジェクトではなく、メソッドに紐づく一時的なコード片として振る舞う。

一方、ProcとLambdaは、ブロックをオブジェクト化したものである。
これにより、変数に代入したり、メソッドの引数として渡したり、他のメソッドから返したりといった、オブジェクトとしての操作が可能になる。
ProcとLambdaの違いは後ほど詳しく解説するが、大まかには「Procは寛容で、Lambdaは厳格」という性質の違いがある。

クロージャの本質：変数の束縛

クロージャの核心は、外部スコープの変数を「覚えておく」能力にある。
以下のコードでこの性質を確認してみよう。

def create_multiplier(n)
  ->(x) { x * n }
end

double = create_multiplier(2)
triple = create_multiplier(3)

puts double.call(5)  # => 10
puts triple.call(5)  # => 15

この例では、create_multiplierメソッドの引数nは、メソッドの実行が完了した後もdoubleやtripleというLambdaの内部に「閉じ込められて」保持されている。
これがまさにクロージャの動作であり、関数型プログラミングにおいて高階関数を実現する基盤技術である。

Rubyのブロック・Proc・Lambdaは、このクロージャの性質を共有しながらも、それぞれ異なる文脈で最適な選択肢として設計されている。
次章以降では、それぞれの具体的な構文と挙動の違いを、実際のコードを交えながら解説していく。

ブロックの基本構文と使い方

Rubyにおけるブロック（block）は、最も身近なクロージャの形態である。
メソッド呼び出しの際に、「この処理を一緒に実行してほしい」という意図で渡すコードのかたまりと捉えると分かりやすい。
ブロックはオブジェクトではないため、変数に代入することはできないが、その分軽量で直感的な記述が可能である。

do…endと{}の違いと使い分け

Rubyのブロックには、do...end と {} という二つの構文が存在する。
両者は機能的には同等だが、結合の強弱に違いがあり、慣習的な使い分けが推奨されている。

まず結合の強さについて。
{} は do...end よりも強く結合するため、以下のような違いが生じる。

# {} を使った場合、ブロックが p に結合する
p [1, 2, 3].map { |n| n * 2 }  # => [2, 4, 6]

# do...end を使った場合、ブロックが p ではなく map に結合する
p [1, 2, 3].map do |n| n * 2 end  # => #<Enumerator: ...>

この違いは、メソッドチェーンを組む際に特に注意が必要である。
一般には、以下のような使い分けが業界で広く受け入れられている。

• 一行で書くブロックには {} を使う
• 複数行にわたるブロックには do...end を使う

# 一行の場合
numbers.each { |n| puts n }

# 複数行の場合
numbers.each do |n|
  squared = n ** 2
  puts squared
end

この使い分けは必須のルールではなく、可読性を重視した慣習である。
ただし、チーム開発では統一性のため、この慣習に従うことが推奨される。

yieldによるブロックの呼び出し方

ブロックを受け取ったメソッド側は、yield キーワードを使ってブロックの中身を実行できる。
これはRubyのメソッド定義において極めて重要な仕組みである。

yield を使うと、メソッドの実行中にブロックに制御を一時的に渡し、ブロックの処理が完了すると元のメソッドに戻ってくる。
この動作は、コンピュータサイエンスでいうコルーチン（coroutine）の一種と見なすこともできる。

def with_timing
  start = Time.now
  yield
  elapsed = Time.now - start
  puts "処理時間: #{elapsed}秒"
end

with_timing do
  sleep(1)
  puts "処理を実行中..."
end

この例では、with_timing メソッドがブロックの前後で時間計測を行い、ブロック自体には純粋に「計測したい処理」を記述するだけでよい。
これが関心の分離（separation of concerns）の典型例である。

yield は引数を渡すこともできる。
ブロック側で受け取るには、パイプ | | で囲んだ引数を指定する。

def repeat_three_times
  yield "最初"
  yield "二回目"
  yield "最後"
end

repeat_three_times do |message|
  puts "[#{message}] 実行しました"
end

さらに、メソッドがブロックを受け取ったかどうかを確認するには block_given? を使う。
これにより、ブロックの有無で挙動を分岐させる柔軟なメソッド設計が可能になる。

def greet(name)
  if block_given?
    yield(name)
  else
    "こんにちは、#{name}さん"
  end
end

puts greet("田中")                    # => こんにちは、田中さん
puts greet("田中") { |n| "Hello, #{n}" }  # => Hello, 田中

ブロックはRubyのイテレーターの基盤であり、each や map といった組み込みメソッドの裏側でも yield が使われている。
ブロックの仕組みを理解することは、Rubyの設計思想を深く理解する上で欠かせないステップである。

Procとは？ブロックをオブジェクト化する仕組み

ブロックは軽量で便利だが、一つの制約がある。
ブロック自体はオブジェクトではないため、変数に代入したり、メソッドの戻り値として返したり、データ構造に格納したりといった操作ができない。
ここで登場するのが Proc である。
Procはブロックをオブジェクト化したものであり、Rubyにおいてクロージャを第一級オブジェクトとして扱うための仕組みである。

Procオブジェクトを生成する最も基本的な方法は Proc.new にブロックを渡すことである。

greet = Proc.new { |name| "こんにちは、#{name}さん" }
puts greet.call("佐藤")  # => こんにちは、佐藤さん

生成したProcオブジェクトは call メソッドで実行できるほか、[] や () といった構文でも呼び出し可能である。

multiply = Proc.new { |a, b| a * b }
puts multiply.call(3, 4)   # => 12
puts multiply[3, 4]        # => 12
puts multiply.(3, 4)       # => 12

Procの真価は、メソッドの戻り値として返したり、他のメソッドに引数として渡したりできる点にある。
これにより、高階関数（higher-order function）のパターンをRubyで実現できる。

def make_adder(n)
  Proc.new { |x| x + n }
end

add_five = make_adder(5)
add_ten = make_adder(10)

puts add_five.call(3)   # => 8
puts add_ten.call(3)    # => 13

この例では、make_adder メソッドの引数 n が、返されたProcオブジェクトの内部に閉じ込められている。
これがクロージャの本質的な動作である。

Proc.newとKernel#procの違い

Rubyには Proc.new と Kernel#proc という二つのProc生成方法が存在する。
実は、現代のRubyでは両者は完全に等価である。

# 以下の二つは同じ結果を生む
p1 = Proc.new { |x| x * 2 }
p2 = proc { |x| x * 2 }

歴史的な経緯として、Ruby 1.9以前では proc と Proc.new の間に挙動の違いが存在したが、現在では統一されている。
ただし、コードの可読性を考えると、proc の方が簡潔であり、特に一行で書く場合にはこちらを選ぶことが多い。
一方、Proc.new はクラス名を明示するため、オブジェクト指向的な文脈で意図を明確に示したい場合に適している。

Procの引数の取り扱いと寛容さ

Procの特筆すべき性質の一つが、引数に対する寛容さである。
Procは、定義時の引数の数と実際に渡された引数の数が一致しなくても、極力処理を継続しようとする。

greet = Proc.new { |first, second| "名前: #{first}, #{second}" }

# 引数が多い場合、余分な引数は無視される
puts greet.call("山田", "太郎", "三郎")  # => 名前: 山田, 太郎

# 引数が少ない場合、nilで埋められる
puts greet.call("山田")                   # => 名前: 山田,

この挙動は、柔軟なインターフェースを設計する際には便利だが、予期せぬバグの原因にもなりうる。
型安全性を重視する立場からは、引数の厳密なチェックが望ましい場面も多い。
そのような場合には、次章で解説する Lambda の使用を検討すべきである。

さらに、Procは引数を配列としてまとめて受け取ることもできる。

sum = Proc.new { |*args| args.sum }
puts sum.call(1, 2, 3, 4, 5)  # => 15

この可変長引数の扱いは、Rubyのメソッド定義における *args と同じ構文を使うため、直感的に理解できる。

Procはブロックをオブジェクト化する強力な仕組みであり、コールバックの登録や、遅延評価の実装、イベント駆動のプログラミングなど、幅広い場面で活躍する。
ただし、その寛容さを理解した上で使いこなすことが、堅牢なコードを書く上での鍵となる。

Lambdaとは？厳格なクロージャの実装

Procが寛容なクロージャであるのに対し、Lambda は厳格な性質を持つクロージャの実装である。
Lambdaという名前は、計算機科学の分野で関数を表すための形式体系として知られる ラムダ計算（lambda calculus） に由来する。
RubyのLambdaは、数学的な関数の性質により近い振る舞いを示し、引数の数や戻り値の扱いにおいて厳密なチェックを行う。

RubyではLambdaを生成する方法として、lambda メソッドと ラムダリテラル（->）の二つが存在する。
両者は機能的に等価だが、構文の簡潔さで使い分けられる。

# lambda メソッドを使う方法
add = lambda { |a, b| a + b }

# ラムダリテラルを使う方法
multiply = ->(a, b) { a * b }

puts add.call(2, 3)       # => 5
puts multiply.call(2, 3)  # => 6

LambdaはProcと同様に call メソッドで実行できるが、内部的には Proc クラスのサブクラスに属するオブジェクトである。
lambda? メソッドで確認できる。

p = proc { |x| x }
l = lambda { |x| x }

puts p.lambda?  # => false
puts l.lambda?  # => true

この lambda? メソッドの存在自体が、RubyがProcとLambdaを明確に区別していることを示している。

Lambdaの引数チェックと厳密性

Lambdaの最も大きな特徴は、引数の数に対する厳格さである。
Procが余分な引数を黙って無視したり、不足する引数を nil で埋めたりするのに対し、Lambdaは引数の数が一致しない場合に例外を発生させる。

strict = lambda { |a, b| a + b }

# 引数が多い場合
strict.call(1, 2, 3)  # => ArgumentError: wrong number of arguments

# 引数が少ない場合
strict.call(1)        # => ArgumentError: wrong number of arguments

この挙動は、コンパイル時の型チェックに近い性質を持ち、早期失敗（fail-fast）の原則に則っている。
大規模なコードベースや、チーム開発においては、この厳密さが予期せぬバグを防ぐ上で極めて有効である。

また、Lambdaはキーワード引数との相性も良好である。

greet = ->(name:, greeting: "こんにちは") {
  "#{greeting}、#{name}さん"
}

puts greet.call(name: "田中")              # => こんにちは、田中さん
puts greet.call(name: "田中", greeting: "Hello")  # => Hello、田中さん

Lambdaリテラル（->）の構文

ラムダリテラル -> は、Ruby 1.9で導入された比較的新しい構文である。
従来の lambda メソッドに比べて記述が簡潔になり、特に引数の型ヒントやデフォルト値を含む複雑なシグネチャを書く際に可読性が高まる。

# 引数なしのLambda
no_args = -> { "引数はありません" }

# 引数ありのLambda
with_args = ->(x, y) { x + y }

# デフォルト値付きのLambda
with_default = ->(name = "ゲスト") { "ようこそ、#{name}さん" }

# ブロックを受け取るLambda
with_block = ->(list, &block) { list.map(&block) }

puts with_block.call([1, 2, 3]) { |n| n * 2 }  # => [2, 4, 6]

ラムダリテラルの構文は、他の言語におけるアロー関数（arrow function）と類似しており、JavaScriptの => やPythonの lambda キーワードと概念的に通じる部分がある。
これは、現代のプログラミング言語が関数型パラダイムの影響を受けていることを示す好例である。

Lambdaは、数学的な関数の厳密性を求める場面や、コールバックのインターフェースを明確に定義したい場面で最適な選択肢となる。
Procの寛容さとLambdaの厳密さを使い分けることで、状況に応じた適切な設計判断が可能になる。

ブロック・Proc・Lambdaの決定的な違いを比較する

これまで個別に解説してきたブロック、Proc、Lambdaだが、いよいよ三つの決定的な違いを明確に整理する時が来た。
これらの違いを理解することは、Rubyのクロージャを使いこなす上で最も重要なステップである。
特に return、break、next の振る舞いと、引数の厳密性の違いは、実際のコードで予期せぬ挙動を引き起こす原因となりうるため、しっかりと押さえておく必要がある。

returnの振る舞いの違い

三つの中で最も大きな違いの一つが、return のスコープである。
ブロック内やProc内で return を使った場合と、Lambda内で使った場合では、制御が戻る場所が異なる。

ブロック内の return は、ブロックを囲むメソッド全体から脱出しようとする。
これは、ブロックがメソッドの一部として扱われる性質に起因する。

def block_return_demo
  [1, 2, 3].each do |n|
    return "ブロック内でreturn: #{n}" if n == 2
  end
  "メソッドの最後"
end

puts block_return_demo  # => ブロック内でreturn: 2

Proc内の return も同様に、Procを定義したメソッド全体から脱出する。

def proc_return_demo
  p = Proc.new { return "Proc内でreturn" }
  p.call
  "メソッドの最後"
end

puts proc_return_demo  # => Proc内でreturn

一方、Lambda内の return は、Lambda自身からのみ戻り、呼び出し元のメソッドの実行は継続される。
これは通常のメソッド呼び出しと同じ振る舞いである。

def lambda_return_demo
  l = lambda { return "Lambda内でreturn" }
  result = l.call
  "#{result} → メソッドの最後"
end

puts lambda_return_demo  # => Lambda内でreturn → メソッドの最後

この違いは、ネストしたメソッド呼び出しやコールバックの設計において、深刻なバグを生む可能性がある。
特に、Procをメソッドの戻り値として使う場合は、return の挙動に十分注意が必要である。

breakとnextの挙動の違い

break と next は、イテレーションの制御フローを操作するキーワードであるが、ブロック・Proc・Lambdaの各文脈で異なる動作を示す。

ブロック内では、break はブロックを囲むイテレーターメソッド全体を抜け、next は現在の繰り返しをスキップして次の要素へ進む。

result = [1, 2, 3, 4, 5].map do |n|
  next 0 if n == 3
  break "中断" if n == 5
  n * 2
end

puts result  # => [2, 4, 0, 8, "中断"]

Proc内では、break は LocalJumpError を発生させる。
これは、Procがメソッドの一部ではなく独立したオブジェクトであるため、どこに「抜けるべきか」が曖昧になるためである。

p = Proc.new { break "Proc内のbreak" }
begin
  p.call
rescue LocalJumpError => e
  puts "エラー: #{e.message}"
end

Lambda内では、break と next はどちらもLambda自身からの脱出として機能し、呼び出し元には戻り値として返される。

l = lambda {
  next "nextで戻る"
  "到達しない"
}
puts l.call  # => nextで戻る

引数の厳密さの比較表

三つの引数の扱いを表にまとめると、以下のようになる。

項目	ブロック	Proc	Lambda
引数が多い場合	余分を無視	余分を無視	ArgumentError
引数が少ない場合	nilで補完	nilで補完	ArgumentError
引数の厳密さ	寛容	寛容	厳密
オブジェクトとしての扱い	不可	可能	可能

この表からも分かるように、Lambdaは引数の検証において最も厳格であり、ブロックとProcは寛容な側面を共有している。
設計の観点からは、インターフェースの厳密性を重視するならLambdaを、柔軟性を優先するならProcを選ぶのが妥当な判断基準となる。

これらの違いを頭に入れた上で、次章ではクロージャの本質的な仕組みであるスコープと変数の束縛について掘り下げていく。

クロージャの本質：スコープと変数の束縛を理解する

これまでブロック・Proc・Lambdaの構文や挙動の違いを見てきたが、ここでは一歩踏み込んで、これらがなぜ「クロージャ」と呼ばれるのか、その本質的な仕組みを解説する。
コンピュータサイエンスの文脈でいえば、クロージャとは「関数と、その関数が定義された環境（スコープ）とのペア」である。
この環境には、関数の外部で宣言された変数が含まれており、関数はそれらの変数にアクセスし続けることができる。

Rubyにおけるブロック・Proc・Lambdaは、いずれもこのクロージャの性質を満たしている。
つまり、定義時のスコープにある変数を「閉じ込めて」保持し、後からその変数にアクセスできるのである。

ローカル変数のキャプチャ機構

クロージャの核心は、ローカル変数のキャプチャにある。
メソッドやブロックの内部で宣言された変数は、通常はそのスコープが終了するとともに破棄される。
しかし、クロージャがその変数を参照している場合、Rubyのガベージコレクタはその変数を解放せず、クロージャとともに存続させる。

def create_counter
  count = 0
  -> {
    count += 1
    count
  }
end

counter_a = create_counter
counter_b = create_counter

puts counter_a.call  # => 1
puts counter_a.call  # => 2
puts counter_b.call  # => 1
puts counter_a.call  # => 3

この例では、create_counter メソッドのローカル変数 count は、メソッドの実行が完了した後も counter_a と counter_b という二つのLambdaによってそれぞれ独立して保持されている。
counter_a と counter_b は別々の環境を持つため、互いの count に干渉することはない。
これがクロージャによるカプセル化の効果である。

さらに、クロージャは参照する変数を書き換えることもできる。
これは、単なる値のコピーではなく、変数そのものへの参照を保持していることを示している。

def multiplier_factory(factor)
  base = 10
  Proc.new { |n| n * factor + base }
end

triple = multiplier_factory(3)
puts triple.call(5)  # => 25

この例では、factor と base の両方がクロージャによってキャプチャされている。
factor は引数として渡された値、base はメソッド内で宣言されたローカル変数であるが、いずれもクロージャの外部環境として保持される。

メソッド内で定義したクロージャの動作

メソッドの内部でProcやLambdaを定義した場合、そのクロージャはメソッドのスコープにあるすべてのローカル変数、引数、さらには self への参照もキャプチャする。
これにより、オブジェクトの状態にアクセスするクロージャを作成できる。

class Greeter
  def initialize(name)
    @name = name
  end

  def formal_greeter
    ->(title) { "#{title} #{@name}様" }
  end

  def casual_greeter
    Proc.new { "やあ、#{@name}！" }
  end
end

greeter = Greeter.new("山田")
formal = greeter.formal_greeter
casual = greeter.casual_greeter

puts formal.call("尊敬する")  # => 尊敬する 山田様
puts casual.call              # => やあ、山田！

この例では、formal_greeter と casual_greeter はいずれも Greeter インスタンスの @name にアクセスしている。
インスタンスメソッド内で定義されたクロージャは、そのインスタンスのコンテキストを保持するため、オブジェクト指向プログラミングと関数型プログラミングの橋渡し的な役割を果たす。

ただし、注意すべき点もある。
クロージャが大きなオブジェクトや大量のデータをキャプチャした場合、メモリ使用量が増加し、メモリリークの原因となる可能性がある。
特に長時間動作するアプリケーションや、多数のクロージャを生成する処理では、キャプチャする変数の範囲を意識することが重要である。

# 注意：大きな配列をキャプチャするとメモリを圧迫する
def risky_closure
  large_data = Array.new(1_000_000) { "x" * 100 }
  -> { large_data.first }
end

# large_data全体がクロージャとともに保持される
leak = risky_closure

クロージャのスコープと変数の束縛を理解することは、Rubyのメモリ管理の仕組みを理解する上でも有益である。
次章では、この知識を前提として、実際の開発現場での使い分けについて考察していく。

実践的な使い分け：どの場面で何を選ぶべきか

これまでの章で、ブロック・Proc・Lambdaの構文、挙動の違い、そしてクロージャとしての本質的な仕組みを解説してきた。
ここからは、これらの知見を実践に活かし、具体的な開発場面でどれを選ぶべきかという指針を示す。
適切な選択は、コードの可読性と保守性を大きく左右する。

イテレーター処理ではブロックを使う

配列やハッシュなどのコレクションに対する繰り返し処理は、Rubyの最も基本的なイディオムである。
この場面では、ブロックが最も自然で簡潔な選択肢となる。

users = ["田中", "佐藤", "鈴木"]

# ブロックを使ったイテレーション
users.each { |name| puts name }

# 複数行の処理もブロックで簡潔に
active_users = users.select do |name|
  name.length >= 2
end.map do |name|
  name.upcase
end

ブロックを使う理由は明確である。
まず、ブロックはメソッド呼び出しに直接紐づくため、処理の意図が読み手に即座に伝わる。
each に続く do...end を見れば、「この配列の各要素に対して何かを行う」ということが直感的に理解できる。

また、ブロックはオブジェクト化のオーバーヘッドがないため、パフォーマンス面でも軽量である。
頻繁に実行されるイテレーション処理においては、この点も無視できない。
ProcやLambdaをわざわざ生成して渡す必要がない場面では、ブロックを使うのが最適解である。

コールバック処理にはProcを使う

コールバック（callback）とは、ある処理の完了時や特定のイベント発生時に呼び出される関数のことである。
Rubyでは、イベント駆動のプログラミングや、遅延実行のパターンを実装する際にProcが広く使われる。

class TaskRunner
  def initialize
    @callbacks = []
  end

  def on_complete(&callback)
    @callbacks << callback
  end

  def run
    puts "タスクを実行中..."
    @callbacks.each(&:call)
  end
end

runner = TaskRunner.new
runner.on_complete { puts "完了しました！" }
runner.on_complete { puts "ログを記録しました" }
runner.run

この例では、on_complete メソッドがブロックを受け取り、内部的にProcに変換して @callbacks 配列に格納している。
複数のコールバックを登録・管理する必要がある場面では、Procのオブジェクトとしての性質が不可欠である。

Procは引数の扱いが寛容であるため、コールバックのインターフェースを柔軟に設計できるという利点もある。
呼び出し側が必ずしもすべての引数を把握していない場面では、Procの寛容さが役立つ。

def with_retry(max_attempts, &callback)
  attempts = 0
  begin
    attempts += 1
    callback.call(attempts)
  rescue StandardError => e
    retry if attempts < max_attempts
    raise
  end
end

with_retry(3) { |n| puts "試行 #{n} 回目" }

関数型スタイルにはLambdaを使う

関数型プログラミングのパラダイムを取り入れたい場面では、Lambdaが最適な選択肢となる。
Lambdaは引数の厳密なチェックと、メソッドに近い return の振る舞いを持つため、純粋な関数のように扱いやすい。

# 関数の合成
add_one = ->(x) { x + 1 }
multiply_by_two = ->(x) { x * 2 }

compose = ->(f, g) {
  ->(x) { f.call(g.call(x)) }
}

composed = compose.call(multiply_by_two, add_one)
puts composed.call(5)  # => 12  (5 + 1 = 6, 6 * 2 = 12)

この例では、Lambdaを使って関数の合成（function composition）を実装している。
Lambdaは数学的な関数の性質を保ちやすく、高階関数を組み立てる際の部品として優れている。

また、APIのインターフェースを厳密に定義したい場面でもLambdaが有効である。

class Calculator
  OPERATIONS = {
    add: ->(a, b) { a + b },
    subtract: ->(a, b) { a - b },
    multiply: ->(a, b) { a * b }
  }

  def self.calculate(op, x, y)
    operation = OPERATIONS[op]
    raise ArgumentError, "未定義の演算です" unless operation
    operation.call(x, y)
  end
end

puts Calculator.calculate(:add, 10, 5)       # => 15
puts Calculator.calculate(:multiply, 4, 7)   # => 28

このように、Lambdaをハッシュの値として格納することで、戦略パターン（Strategy Pattern）を簡潔に実現できる。
引数の数が厳密に管理されるため、意図しない呼び出しを防ぐことができる。

以上の三つの指針を頭に入れておけば、開発現場で迷うことは少なくなる。
最終章では、これらの知識を総括し、Rubyのクロージャをマスターするための最終的なアドバイスを述べる。

Rubyのクロージャをマスターして、より表現力豊かなコードを書こう

この記事を通じて、Rubyにおけるブロック・Proc・Lambdaの三つのクロージャの形態を、構文から挙動の違い、そしてスコープと変数の束縛という本質的な仕組みまで、体系的に解説してきた。
これらを理解することは、単なる文法の暗記ではなく、Rubyという言語の設計思想に触れる体験でもある。

改めて、三つの形態の違いを整理すると、以下のようになる。

項目	ブロック	Proc	Lambda
オブジェクト化	不可	可能	可能
引数の厳密さ	寛容	寛容	厳密
returnの挙動	メソッドから脱出	メソッドから脱出	Lambdaから戻る
主な用途	イテレーション	コールバック	関数型スタイル

この表を見れば分かるように、三つは互いに代替可能な関係ではなく、それぞれが得意とする領域を持っている。
ブロックは軽量で直感的なイテレーションに、Procは柔軟なコールバックの登録に、Lambdaは厳密な関数型プログラミングのパターンに適している。

クロージャをマスターすることの最大のメリットは、コードの抽象度を高め、重複を減らすことにある。
同じような処理パターンが複数の場所に散在している場合、それをクロージャとして切り出すことで、一箇所の修正が全体に波及する。
これは、ソフトウェア工学でいう DRY原則（Don’t Repeat Yourself） の実践に直結する。

# 重複したコードをクロージャで抽象化する例
def with_timing(label)
  start = Time.now
  yield
  puts "[#{label}] 処理時間: #{Time.now - start}秒"
end

with_timing("データ読み込み") { load_data }
with_timing("レポート生成") { generate_report }
with_timing("メール送信") { send_emails }

このように、処理の前後に共通の処理を挟みたい場面では、ブロックを受け取るメソッドを定義することで、横断的関心事（cross-cutting concern）をきれいに分離できる。
これは、Ruby on Railsにおける around_filter や、RSpecにおける around フックなど、実際のフレームワークでも広く使われているパターンである。

また、クロージャはテスト容易性の向上にも貢献する。
外部依存をクロージャとして注入することで、テスト時にモックに差し替えることができる。

class PaymentProcessor
  def initialize(charge_service:)
    @charge_service = charge_service
  end

  def process(amount)
    @charge_service.call(amount)
  end
end

# 本番環境
processor = PaymentProcessor.new(charge_service: ->(amount) { Stripe::Charge.create(amount: amount) })

# テスト環境
processor = PaymentProcessor.new(charge_service: ->(amount) { { success: true, amount: amount } })

この例では、Lambdaを使って決済サービスのインターフェースを抽象化し、実行環境に応じて異なる実装を注入している。
これが 依存性の注入（Dependency Injection） の基本的な形態である。

最後に一つ、注意点を述べておく。
クロージャは強力な道具であるが、使いすぎるとコードの追跡が困難になり、コールバック地獄と呼ばれる可読性の低下を招くことがある。
深くネストしたクロージャの連鎖は、デバッグを困難にする。
適切な抽象化のレベルを見極め、必要に応じてメソッドやクラスに切り出す判断も忘れないようにしたい。

Rubyのクロージャは、オブジェクト指向と関数型の両方のパラダイムを橋渡しする優れた設計である。
ブロック・Proc・Lambdaを使いこなせるようになれば、Rubyのコードは一段と表現力豊かで、かつ堅牢なものになる。
ぜひ、日々のコーディングの中で意識的に使い分けを実践し、この言語の真の力を引き出していただきたい。