PHP 8.5 と pipe 演算子 |> : 頭を悩ませない読みやすいパイプライン

2025年9月26日。カレンダーに赤で丸を付けておけ。PHP 8.5 がようやく着地し、嫌でも付き合うことになる。目玉のひとつは pipe 演算子 |>。マトリョーシカみたいな括弧の入れ子と決別して、薬いらずで読めるパイプラインに乗り換える時間だ。

この記事では演算子を分解し、限界も冷静に眺めつつ、即投入できるユースケースをかっさらっていく。震えている暇はない。

なぜ PHP に pipe が必要だったのか

ほぼすべてのアプリで、きみは変換の行列を組む。入力を掃除し、ペイロードを検証し、オブジェクトを組み立て、レスポンスをシリアライズする。これまでは二択の地獄だった：

• 呼び出しを入れ子にしまくる（foo(bar(baz($input)))）→ 月曜朝の同僚が実行順を読み解けるよう祈るのみ；
• 一時変数を乱立させる（$step1, $step2, $step3）→ ファイルが落書きノートみたいになる。

pipe |> は第三の抜け道だ。左辺の値を右辺の式へ 暗黙の引数 として渡す。結果として、上から下へ読めるコードになり、頭の中の思考とようやく歩調が合う。

構文：覚えるのはこの一点だけ

ルールは簡単。左の値が右の式の 第1引数 に突っ込まれる。別の場所に差し込みたいなら、その位置に ... を落とせばいい。呪文はいらない、三点リーダだけだ。

php
1$result = $data
2    |> trim(...)
3    |> htmlspecialchars(..., ENT_QUOTES, 'UTF-8')
4    |> mb_strtoupper(..., 'UTF-8');

ここでは trim が $data を受け取り、出力が htmlspecialchars、最後に mb_strtoupper へ流れる。余計な括弧も、一次変数のゴミもない。

ℹ️ ターゲットの式が複数引数を取るなら、... が「ここに突っ込め」という旗印になる。忘れれば PHP が勝手に第1引数へ押し込み、きみは「予期せぬ挙動」を追う羽目になる。

事例1：フォーム入力を躾ける

記事タイトルを受け取る API を想像してみろ。やるべきことはこうだ：

1. 余計な空白を削る；
2. 80 文字で切る；
3. 空っぽではないと確認する；
4. こけたら分かりやすいエラーを投げる。

php
1$title = $payload['title'] ?? '';
2
3$normalizedTitle = $title
4    |> trim(...)
5    |> fn(string $value) => mb_substr($value, 0, 80)
6    |> fn(string $value) => match (true) {
7        $value === '' => throw new InvalidArgumentException('タイトルは必須だ。'),
8        default => $value,
9    };

各ステップは孤立していてテストしやすく、読み返しても迷子にならない。無名関数がガードレールになり、心配性のアーキテクトのためにクラスを増やす必要もない。

事例2：HTTP レスポンスを磨き上げる

天気サービスが JSON を返す状況を思い描いてみろ。pipe を使えば、意図を混在させずに変換を積み上げられる。

php
1$responseBody = $weatherProvider->fetchForCity('Lyon')
2    |> fn(array $data) => array_merge($data, [
3        'updatedAt' => (new DateTimeImmutable('now', new DateTimeZone('Europe/Paris')))->format(DateTimeInterface::ATOM),
4    ])
5    |> array_map(fn($value) => is_float($value) ? round($value, 1) : $value, ...)
6    |> fn(array $data) => array_intersect_key($data, array_flip(['temperature', 'humidity', 'windSpeed', 'updatedAt']))
7    |> json_encode(..., JSON_THROW_ON_ERROR | JSON_PRETTY_PRINT);

変換がきれいに縦に並び、ログやメトリクスが欲しければ途中にラムダを挟めばいい。それだけだ。

事例3：ドメインオブジェクトをハイドレートする

静的メソッドもインスタンスメソッドも、第1引数で値を受け取れるなら pipeline に組み込める。EmailAddress の Value Object を例にしよう。肘でメールアドレスを打ったユーザーを止めるのにちょうどいい。

php
1$recipient = $input['email'] ?? '';
2
3$email = $recipient
4    |> trim(...)
5    |> mb_strtolower(..., 'UTF-8')
6    |> EmailAddress::fromString(...)
7    |> fn(EmailAddress $address) => ContactPreference::fromEmail($address);

EmailAddress::fromString(...) に ... を置けば、どこに差し込むか PHP に教えられる。その後はアグリゲートのコンストラクタでも CQRS コマンドでも好きに繋げ。スパゲッティ化せずに済む。

トラブルなく導入するための心得

• 一貫性を死守しろ：パイプラインは一つの物語を語れ。バリデーションと永続化と描画をごちゃ混ぜにするなら、レビューで怒られる前に分割しろ。
• 名前やコメントは必要なときだけ：fn($x) => $x なんて無意味だ。意図が曖昧なら sanitizeTitle みたいな関数名にしておけ。
• 縦の読みやすさを磨く：pipe を揃え、論理ブロックの間に空行を入れ、必要なら短いコメントを差し込む。グラフィティではないが、見た目は大事だ。
• テストのしやすさを忘れるな：limitLength のような純粋な処理は外へ引き抜き、個別にテストする。パイプラインはオーケストレーション役に徹させろ。
• 型を尊重しろ：各ステップが次のステップの期待する型を返すように。union types や readonly classes といった最近の武器は、この関数型っぽい書き味とよく合う。LinkedIn 自慢にだけ使うな。

pipe を封印すべき場面

キラキラして見えても万能ではない：

• 副作用だらけの処理（メール送信、HTTP コール、ディスク書き込み）は流れを濁らせる。専用メソッドに包んで最後に呼び出せ。そうすれば自分の意思でやったと胸を張れる。
• 値を第2引数で受け取りたい API：... で無理やり差し替えることはできるが、読みやすさは急降下する。素直にヘルパーを書いて現実と向き合え。
• ミュータント化したパイプライン：状態をいじるラムダを3つも4つも積んだら深呼吸しろ。切り分けるか、素直に命令型へ戻れ。読めないパイプラインに賞は出ない。

既存コードに pipe を馴染ませるステップ

1. ホットスポットを洗い出せ：array_map/array_filter の巣やフォーム検証、API レスポンス変換が密集している場所を探す。
2. 段階的にリファクタしろ：ネストの塊を短いパイプラインへ置き換える。夜ぐっすり眠りたいなら回帰テストを追加しておけ。
3. チームのルールを揃えろ：pipe をいつ使うか、ヘルパーの命名、例外処理をどうするかをガイドに刻め。
4. ツールを更新しろ：IDE スニペットやリント設定を新構文に対応させろ（php-cs-fixer, Psalm, PHPStan）。放置すれば無駄な警告で数週間イライラする羽目になる。
5. チームを巻き込め：コードレビュー会やライブコーディングで読みやすさの勝ちっぷりを見せつけろ。PHP 5 をまだ崇拝している連中にもだ。

まとめ

• PHP 8.5 の pipe |> は左辺の値を右辺の式へノータイムで渡し、一次変数を消し去る。
• ... を置いて値の着地点を明示しろ。忘れれば幽霊バグを狩る旅が始まる。
• 短くて筋の通ったパイプラインは読みやすさ・テスト容易性・表現力を底上げする。
• 副作用の塊は外へ追い出し、pipe は純粋（もしくは準純粋）な変換に専念させろ。
• リンター、標準、トレーニングを整備して、新しいおもちゃがプロジェクト全体を壊さないようにしろ。

pipe 演算子は PHP を純粋関数型言語に変える魔法ではないが、きみに 鋭いツール を渡してくれる。さあ、変換チェーンをきみのアイデアくらいクリアにしろ──少なくとも、いつもの霧よりはマシに。