Linux EPIPE (32) 対策：Broken pipe エラーの原因解析と再接続対策編

【注意書き】本記事は、Linuxにおける EPIPE(32) / Broken pipe エラーの一般的な原因整理と設計・運用上の対策方針を解説するものです。実際の最適解は、ネットワーク構成（LB/Proxy/Firewall）、アプリ実装、タイムアウト値、トラフィック特性、運用体制、セキュリティ要件などで大きく変わります。障害の切り分けや再接続設計を誤ると、データ不整合や二重処理、性能劣化につながる恐れがあります。個別案件の判断が必要な場合は、株式会社情報工学研究所のような専門家へご相談ください。

　

「またBroken pipeか…」現場がハマる“突然死”のつらさから始めよう

深夜のアラートで起きて、ログを開いた瞬間に目に入るのが Broken pipe。原因を追い始めたのに、結局「どこで切れたのか」が曖昧なまま、リトライ設定だけ増えていく——このパターン、SRE/情シス/サーバサイドの現場では珍しくありません。

「ネットワークが不安定だったのかな」「相手が落ちた？」「でも再現しないし、たまにしか出ない」……そう考えて、タイムアウトを伸ばす、リトライ回数を増やす、ログレベルを上げる。やっていることは正しいのに、根っこが分からないまま運用負荷だけ上がっていく。正直しんどいですよね。

ここで一度、心の会話をそのまま書きます。

「また新しい対策？それ、誰がメンテするの？」

「“切れたら再接続”って言うけど、データが二重送信されない？」

「どうせ原因は“相手都合”で終わるんじゃないの…」

こう感じるのは自然です。むしろ健全な疑いです。EPIPE/Broken pipeは、単に“回線が弱い”ではなく、OSとプロセス間の契約（I/Oの前提）が破れたサインであることが多いからです。

---

まず結論の方向性を先に共有すると、Broken pipe対策は「切れないように祈る」ではなく、切れても壊れないように設計することに収束します。そのために必要なのは、次の3点です。

• 何が“パイプ”で、どこが“相手”なのか（プロセスか、ソケットか、Proxyか）を特定する
• 切断時の挙動（SIGPIPEで死ぬのか、EPIPEで戻るのか）を理解して実装を決める
• 再接続と再送を、冪等性・重複排除・観測性とセットで設計する

この記事は、この順番で腹落ちさせる構成にします。導入で共感し、次にOSの挙動を正確に押さえ、最後に「現場が破綻しない再接続設計」へ着地させます。

ここまで読んで「分かる。結局、運用が増えるのが嫌なんだよ」と思ったなら、この記事はたぶん役に立ちます。運用が増えない形に落とすために、技術として何を押さえるべきかを、順に整理していきます。

　

EPIPE(32)の正体：書き込み先が消えた瞬間にカーネルで起きていること

EPIPE は、Linuxで errno=32 として表現されるエラーで、一般に Broken pipe と表示されます。ざっくり言えば、「書き込み先（読み手）がもう存在しないのに書こうとした」ときに発生します。

「パイプ」の意味は、必ずしも “|” だけではない

“pipe” という単語が付くので、シェルのパイプ cmdA | cmdB を連想しがちですが、現場でEPIPEが出る経路は複数あります。代表例は次の2系統です。

• プロセス間通信：シェルのパイプ、FIFO、標準出力/標準エラーのリダイレクト先が切れるケース
• ソケット通信：TCPソケットへ書き込もうとしたが、相手が既にクローズしているケース（Proxy/LB含む）

共通しているのは、「こちらは書けるつもりだった」のに、「相手が受け取る前提が崩れていた」という点です。OSはその事実を、エラー（EPIPE）やシグナル（SIGPIPE）で突き付けます。

“相手がいない” とは具体的に何が起きた状態か

EPIPEに至る「相手がいない」は、原因の粒度で見ると次のように分解できます。

分類	起きていること	現場での例
プロセス側の終了	読み手プロセスが終了し、パイプの読み端が閉じられた	yes | head -n 1 で head が先に終了
ソケットのクローズ	接続先プロセスが close し、以後の書き込みが成立しない	アプリ再起動、Pod再スケジュール
中間装置による切断	Proxy/LB/Firewall がアイドルや制限で接続を切断	LBの idle timeout、NATテーブル枯渇

---

ここで大事なのは、EPIPEは「原因」ではなく結果だということです。原因は、プロセスの寿命・タイムアウト・負荷・ネットワーク機器・実装の前提など、別の層にあります。

だからこそ、EPIPEを見たときにやるべきは「リトライを増やす」より先に、“書き込み先は誰で、どの層で消えたのか”を同定することです。ここを飛ばすと、再接続ロジックが増殖し、二重送信や負荷スパイクで、別の事故が起きます。

Broken pipeが“たまに”しか出ない理由

現場がつらいのは、EPIPEが再現しづらいことです。なぜなら、切断は「相手の都合」「ネットワークの瞬断」「タイムアウト」「デプロイの瞬間」など、時刻依存・負荷依存で起きやすいからです。

「テスト環境では出ない」のも自然です。テストでは、LBのタイムアウトも、実トラフィックのバーストも、運用上の再起動も、しばしば再現されません。ここを責めても意味はなく、観測と設計で“出ても壊れない”方向へ寄せるのが現実的です。

　

SIGPIPEという落とし穴：デフォルト挙動で“プロセスが死ぬ”理由

Broken pipeを語る上で避けて通れないのが SIGPIPE です。EPIPEは「エラーとして返る」イメージが強いのですが、実際にはシグナルでプロセスが終了するケースがあり、これが現場の混乱ポイントになります。

何が起きるとSIGPIPEが飛ぶのか

典型は、読み手がいないパイプや既にクローズされたソケットに対して write/send を行ったときです。デフォルト設定では、カーネルはプロセスへ SIGPIPE を送ります。これをハンドルしていないと、プロセスは終了します。

つまり、ログに Broken pipe が残る前に、プロセスが落ちていることがあります。現場目線ではこう見えます。

• アプリが突然落ちた（終了コードだけ残る）
• 落ちた原因が分からない（例外ログが無い）
• たまにだけ発生し、再現しない

「え、Broken pipeって“通信エラー”じゃないの？」と思うのは自然です。しかし現実には、“書き込みの前提が崩れたので、プロセスを止める”という古典的なデフォルトがある、という話です。

最低限、現場で押さえるべき選択肢

対策は「SIGPIPEを無視すればOK」と単純化しがちですが、判断軸を分けると事故りにくいです。

方針	メリット	注意点
SIGPIPEを無視する	プロセスが“突然死”しにくい	以後は write/send の戻り値（EPIPE等）を確実に処理する必要がある
シグナルは維持し、設計で回避	異常を即座に検出しやすい	落ちる設計は運用と相性が悪い場合がある（監視/再起動前提が必須）
送信APIでシグナル抑止を使う	局所的に制御できる	言語・ライブラリ依存。全経路で統一できないと取りこぼす

“心の会話”にロジックで答える

ここで、さっきの本音に技術で答えます。

「再接続すればいいって言うけど、二重送信が怖い」

これは正しい懸念です。SIGPIPE/EPIPE対策で“とりあえず再送”を入れると、次に起きるのは重複処理や順序崩れです。だから、SIGPIPEの扱いは再接続設計と切り離せません。この記事の後半では、冪等性・重複排除まで含めて「戻れる」設計に落とし込む話をします。

---

例：パイプでSIGPIPEが見える最小例（概念理解）

シェルの世界だと、読み手が先に終わる代表例はこれです（概念としての例です）。

yes | head -n 1 # head は 1 行で終了し、yes は書き込み先を失って SIGPIPE を受けることがある

この“書き込み先を失う”が、アプリケーションでも起きています。相手プロセス、LB、Proxy、コンテナの再起動など、形が違うだけで本質は同じです。

ここまでで押さえたいのは一点だけです。Broken pipeは「通信が切れた」だけでなく、デフォルトだとプロセスが終了し得るI/Oイベントであり、対策は“例外処理”ではなく“設計”として扱う必要がある、ということです。

　

ネットワーク断だけじゃない：プロセス終了・タイムアウト・負荷とバックプレッシャ

Broken pipeを見ると、まず「回線が切れた」と考えがちです。もちろんそれもあります。ただ、現場で厄介なのは、“ネットワーク断以外”で同じ結果（EPIPE/SIGPIPE）に到達することです。

よくある原因の上位パターン（現場の体感ベースで整理）

比率は環境で変わりますが、「どの層で起きやすいか」という意味で、よくあるパターンを並べます。

• 相手プロセスが落ちた／再起動した：デプロイ、OOM、クラッシュ、Pod再スケジュールなど
• 中間装置が切った：LB/Proxy/NAT/Firewall の idle timeout、セッション制限
• アプリのタイムアウト設計が噛み合っていない：片側だけ短い、KeepAlive無し、再利用ソケットの寿命管理が無い
• 負荷由来のバックプレッシャ：相手が詰まり、結果的に切断・RSTやアプリ側closeにつながる

---

「タイムアウトの不一致」は、最も地味で強い地雷

“心の会話”をそのまま言うとこうです。

「タイムアウト伸ばせって言うけど、伸ばしたら障害検知が遅くなるじゃん…」

はい、その通りです。タイムアウトは長ければ良いわけではありません。ポイントは「どこが」「何の理由で」切っているかです。特に多いのは、アプリがKeepAlive前提でソケットを使い回しているのに、LBがアイドルを一定時間で切るケースです。アプリ側は“まだ生きてるつもり”で送信し、そこで EPIPE が出ます。

観点を揃えるためのチェック表

観点	見る場所	ありがちな落とし穴
接続の寿命	LB/Proxy設定、クライアントKeepAlive	アイドルで切られたソケットを再利用してEPIPE
読み手の健全性	相手プロセスの再起動履歴、OOM、Pod移動	送信側は正常でも受信側が落ちている
負荷と詰まり	キュー長、CPU/メモリ、スレッド数、GC	遅延が増え、結果的に上流がタイムアウト→切断
再送の安全性	リクエストID、冪等性、重複排除	Broken pipe後に“とりあえず再送”で二重処理

---

バックプレッシャを「通信エラー」と誤認すると事故る

負荷が高いとき、相手が読み切れず詰まります。送信側はバッファに溜め、やがて遅延が増える。すると、上流のタイムアウトが先に発動して接続が切れる。現場では「ネットワークのせい」に見えますが、実態は処理能力不足・流量制御不足です。

このタイプで“リトライ増やす”をやると、さらに流量が増え、詰まりが悪化し、切断が増えます。つまり、Broken pipe対策はネットワークだけを見ても解けません。処理の詰まりと接続の寿命も同時に見ないと、同じ場所で転びます。

次章では、ここまでの「層のどこで起きたか」を、再現性が低い状況でもなるべく確定させるための観測方法（strace/tcpdump/ログ設計）に進みます。

　

まず再現して確定する：最小コード＋strace/tcpdumpで原因を切り分ける

Broken pipeの対策が進まない最大の理由は、「原因の確定ができない」ことです。だからこそ、現場で効くのは“完璧な再現”ではなく、どの層で切れたかを特定するための観測です。

最初にやるべきは「誰に書いていたか」を確定する

同じ“送信”でも、書き込み先はさまざまです。

• 標準出力（ログパイプ、journald、収集エージェント）
• UNIXドメインソケット（ローカルIPC）
• TCPソケット（HTTP/gRPC、DB、メッセージング）

「どのFD（ファイルディスクリプタ）で落ちたか」が分かるだけで、調査の難易度が大きく下がります。

---

strace：EPIPEが出た“瞬間”をFD単位で掴む

Linuxでは、プロセスがどのシステムコールで失敗したかを追うのに strace が有効です。例えば、対象プロセスにアタッチして write/send 系だけ追うと、EPIPEの発生箇所（FD番号、返り値）が見えます。

# 例：write/send/close 付近を追う（概念例） strace -ff -p <PID> -e trace=write,sendto,sendmsg,close -s 200 -tt

ここで得たいのは「いつ」「どのFD」「どのsyscall」で EPIPE が返ったか、です。ログに出ている“Broken pipe”だけだと、例外処理のどこで出たか曖昧なことが多いからです。

tcpdump：RST/FINの方向とタイミングを見る

TCP通信が絡むなら、切断の形（FINなのかRSTなのか）を見るとヒントになります。RSTが多いなら「中間装置が切っている」「相手が異常終了している」など、絞り込みが進みます。

# 例：特定ポートの通信をキャプチャ（概念例） tcpdump -i any -nn host <DEST_IP> and port <PORT> -vv

ただし、暗号化（TLS）だと中身は見えません。ここで重要なのは“中身”ではなく、セッションの生死（SYN/ACK/FIN/RST）です。

---

アプリログの設計：EPIPEを「一行ログ」に落とさない

現場が苦しむログの典型はこうです。

「Broken pipe」

これだけだと、何も分かりません。最低限、次を一緒に残すだけで、調査の速度が変わります。

• 相手（host:port / endpoint / queue名）
• 操作（write/send/flush など）
• リクエストID/メッセージID（後で二重送信を追える）
• 接続の世代（コネクションプールの何番目か、再接続回数）

「ログ増やすの嫌なんだけど…」という声も分かります。だからこそ、常時詳細ログではなく、EPIPE発生時だけ“調査に必要な構造化ログ”を出すのが現実解です。

ここでの帰結（次章への伏線）

原因を100%確定できなくても、「どの層で切れているか」が分かれば、対策の方向は決められます。そして対策は、例外処理の追加ではなく“再接続の設計”になります。

次章では、EPIPEを「例外」ではなく「起きる前提のイベント」として扱う、アプリ側の基本防御（SIGPIPE/EPIPEの扱い、送信ループ、接続の更新）へ進みます。

　

アプリ側の基本防御：write/send失敗を「例外」ではなく「仕様」として扱う

Broken pipe対策の第一歩は、「EPIPEが出たらログ出して終わり」から卒業することです。EPIPEは“想定外の事故”というより、分散システムでは必ず起きる前提のイベントです。だから実装も「例外ハンドリング」ではなく、「状態遷移」として扱う方が破綻しません。

基本の状態遷移：接続は“生”ではなく“世代”で管理する

実務で効く考え方は単純です。接続は永遠に使えるものではなく、壊れる（または壊される）。だから、次の状態を明確にします。

• Connected：送受信できる前提
• Suspect：遅延や失敗が増えて怪しい（再接続準備）
• Broken：EPIPE等で確定。直ちに破棄し、次の世代を作る
• Reconnecting：バックオフしながら再確立

この“世代管理”を入れると、EPIPEが出たときにやるべきことが定義できます。同じ接続に固執しないことが、結果的に障害を短くします。

---

「とりあえず再送」が危険な理由（次の章の核心への伏線）

心の会話で言うとこうです。

「再接続したなら、さっきの送信ももう一回投げればいい？」

ここが危険です。送信に失敗した瞬間、相手が“受け取っていない”とは限らないからです。ネットワークやバッファの都合で、相手側は受け取って処理を始めていたが、応答が返る前に切断された、という状況は現実に起きます。

だから、送信失敗＝未達と決め打つと、二重処理が起きます。逆に、送信失敗＝到達済みと決め打つと、今度は取りこぼしが起きます。ここを解くのが、後半で扱う冪等性・重複排除・ACK設計です。

実装上の最低ライン：戻り値とerrnoを“握りつぶさない”

どの言語でも共通して重要なのは、I/O失敗を「一度の例外」で終わらせず、次の判断材料にすることです。

• EPIPEが出た接続は必ず破棄し、プールへ戻さない（戻すと再発が増える）
• 再接続は即時連打しない（後続章で指数バックオフ＋ジッタを解説）
• 送信単位（メッセージ/リクエスト）にIDを付ける（重複排除の土台）

---

現場で破綻しないための「最小の約束」

Broken pipeが出る環境は、だいたい「止められないシステム」です。だから、最小の約束として次を決めておくと、チームの会話が前に進みます。

決めること	理由	決めないと起きること
再接続の責務（どの層が持つか）	実装の重複と抜けを防ぐ	アプリとミドルで二重再試行→雪だるま負荷
再送の可否（冪等性の前提）	二重処理事故を防ぐ	“たまに”金額二重請求、データ二重登録
観測項目（ID/世代/相手）	原因の層を切り分ける	Broken pipeの一行ログだけが増殖する

次章では、再接続を実装するなら避けて通れない「指数バックオフ＋ジッタ」「接続プール崩壊」「再試行の上限とサーキットブレーカ」といった、現場で事故りやすい論点をまとめて扱います。

　

再接続の設計：指数バックオフ＋ジッタ＋接続プール崩壊を避けるコツ

Broken pipeが発生したとき、「再接続すれば直る」は半分正しく、半分危険です。正しいのは、EPIPEが出た接続は継続利用できない（基本的に破棄すべき）という点です。危険なのは、再接続を“即時・無制限・全リクエスト”で行うと、リトライ嵐（retry storm）や接続プール崩壊を引き起こし、障害を拡大させる点です。

再接続は「速さ」より「秩序」が重要

現場でよくある失敗は、エラーが出た瞬間に全ワーカーが一斉に再接続し、相手（API/DB/キュー）が回復する前に同時接続が集中して再び落ちる、というパターンです。特にLB配下のマイクロサービスや、同一宛先へ多数クライアントがいる構成では起きやすいです。

---

指数バックオフ＋ジッタ（乱数）は“マナー”ではなく“必須条件”

再接続の基本は、失敗回数に応じて待ち時間を増やす指数バックオフです。ここにジッタ（待ち時間の乱数揺らぎ）を必ず足します。ジッタがないと、同一タイミングでリトライが同期し、回復直後に再び集中負荷が発生します。

実務では、次のような方針が一般的です。

• 初回は短く（例：100ms〜500ms）、回数に応じて指数的に増やす
• 上限（cap）を設ける（例：最大30秒〜数分）
• 待ち時間に乱数を混ぜる（Full Jitter等）
• 全体の締め切り（deadline）を持ち、無限に待ち続けない

「早く復旧したいから即リトライ」は気持ちは分かりますが、同時多発する障害では逆効果になりがちです。再接続を“秩序だてる”ことが、結果的に復旧を早めます。

「再試行していい失敗」と「即座に諦めるべき失敗」を分ける

Broken pipe自体は「接続が壊れている」サインで、同じ接続での継続は無意味です。ただし、再接続や再送を行うかは、エラー種別や文脈で判断が必要です。現場で整理しやすいように、よく使われる判断軸を表にします。

状況	例	基本方針
接続が壊れた	EPIPE, ECONNRESET	接続は破棄→バックオフ再接続（再送可否は別途）
相手が過負荷	HTTP 429/503 等	バックオフ＋ジッタ。上限回数やサーキットブレーカも検討
認証・入力が誤り	HTTP 401/403/400 等	再試行しても直らない。即エラーにして原因修正へ
タイムアウト	ETIMEDOUT	回線/負荷/タイムアウト不一致を疑う。無制限リトライは危険

---

接続プールの落とし穴：壊れた接続を“再利用”すると再発する

多くの言語・HTTPクライアント・DBクライアントは接続プールを持ちます。ここで重要なのは、EPIPEが出た接続をプールに戻すと、次の送信でまた失敗し、失敗率が上がることです。従って、Broken pipeを検出したら、その接続は明示的に破棄し、プールの健全性を保つ必要があります。

また、LBのアイドルタイムアウトで“気づかぬうちに切れている”タイプでは、再利用前に接続の健全性を確認する仕組み（ライブラリのヘルスチェック、アプリ側の接続寿命管理）が効く場合があります。ただし、TCP keepaliveやアプリレベルpingは万能ではなく、どこで切られるか（中間装置の挙動）に依存します。

サーキットブレーカ：再試行より先に「一旦止める」選択

失敗が一定以上続くなら、再接続を続けるより、一定時間リクエストを遮断し回復を待つサーキットブレーカが有効なケースがあります。これは“諦め”ではなく、全体を守るための制御です。再試行は負荷を増やし、回復を遅らせることがあるからです。

---

ここまでで、Broken pipe対策の「再接続」は、単なる例外処理ではなく、同時多発・過負荷・中間装置まで含めた設計問題だと分かります。そして次にぶつかる壁が、「再接続できても、再送して良いのか」です。次章では、二重処理や不整合を避けるための、冪等性と重複排除の考え方に進みます。

　

再送しても壊れない仕組み：冪等性・重複排除・キュー/ACKの考え方

Broken pipeの後に再接続できたとして、次に必ず出てくる問いがこれです。

「さっき失敗した送信、もう一回投げていい？」

この問いに雑に答えると、請求二重計上・注文二重登録・ジョブ二重実行など、取り返しのつかない事故になります。ここは一般論ではなく、“どの配送保証でシステムを作っているか”に依存します。

まず配送保証の前提を揃える：At-most-once / At-least-once

現実の分散システムでは、「相手が受け取ったか」を常に確実に知ることは困難です（ネットワーク分断、応答消失、途中切断があるため）。そのため、実装は多くの場合、次のどちらかに寄ります。

• At-most-once（高確率で重複しないが、取りこぼす可能性）：再送を極力しない
• At-least-once（取りこぼしにくいが、重複する可能性）：再送する前提で、重複を吸収する

「Exactly-once（厳密に一度だけ）」は、システム全体で強い制約やトランザクション境界を設けない限り、一般に実現が難しく、部分的にしか保証できません。したがって実務では、At-least-once＋重複排除に寄せることが多いです。

---

冪等性（idempotency）を“APIの性質”ではなく“設計要件”にする

HTTPのGETが冪等、POSTが非冪等……という教科書的分類は参考にはなりますが、現場では「更新系でも安全に再送できる」仕組みが必要になることが多いです。その代表が冪等キー（Idempotency Key）です。

考え方は単純で、クライアントがリクエストに一意なIDを付け、サーバ側がそのIDを記録して、同じIDのリクエストを重複実行しないようにします。Broken pipeなどで「返事が消えた」ケースでも、再送は可能になります。

重複排除の実装パターン（代表例）

パターン	やること	注意点
DBユニーク制約	リクエストIDをキーに一意制約で弾く	保存期間・クリーンアップ設計が必要
冪等キー＋結果キャッシュ	同一キーなら“同じ結果”を返す	結果の保存コスト、返す結果の定義が必要
UPSERT/Compare-and-Swap	二重実行でも同じ状態に収束させる	業務要件（加算/減算など）によっては不向き

---

キュー/メッセージングの場合：ACKと再配送はセットで設計する

メッセージキューやストリーム処理では、一般に「処理が成功したらACK（確認応答）を返す」「ACKがなければ再配送される」というモデルが多いです。これは強い意味で At-least-once を作りやすい一方、重複処理を吸収できないと必ず事故になります。

例えば、ワーカーが処理を終えた直後にネットワーク断でACKが落ちれば、同じメッセージが再配送されます。ここで「二回処理されても最終状態が壊れない」か、「二回処理されたら致命的」かで、設計が変わります。

「再送していい単位」を定義する

冪等性は万能ではありません。次のような場合は、単純な再送が危険です。

• 外部決済や外部APIで“二重実行が許されない”操作を含む
• 「加算」「送金」「在庫引当」など、二重実行が業務的に致命的
• サーバ側で冪等キーを保持できない（または保持コストが大きい）

この場合は、冪等キーに加えて「実行前の予約」「実行後の確定」「補償トランザクション」など、業務手順を含む設計が必要になります。ここが一般論の限界で、業務とシステムの境界に踏み込むポイントです。

---

ここまでの帰結は明確です。Broken pipe対策で再接続・再送を行うなら、冪等性と重複排除が無い限り、安全にはできません。そして次章では、これらを“机上の設計”で終わらせず、現場で回すためのログ・メトリクス・アラート（観測性）に落とし込みます。

　

運用で勝つ：ログ/メトリクス/アラートで「いつ・どこで・なぜ」を掴む

ここまでで、Broken pipe（EPIPE/SIGPIPE）は「たまたまの通信エラー」ではなく、分散システムでは起こり得るI/Oイベントであり、設計で吸収すべきものだ、という整理をしてきました。ただ、設計だけでは勝てません。現場が本当に困るのは、“たまに起きて、再現しない”ことです。つまり、運用で勝てる仕組み（観測性）がないと、毎回「なんか切れた」で終わり、同じ夜間対応が繰り返されます。

まず“Broken pipe”を一行ログで終わらせない

一行ログの例はこうです。

「Broken pipe」

これでは原因が掴めません。最低限、次の情報をセットで残すと、調査が“推理”ではなく“確認”になります。

• 接続先（host:port、URL、queue名、DB名など）
• プロトコルと操作（HTTP/gRPC/TCP、write/send/flush、リクエスト種別）
• 相関ID（request_id / message_id / trace_id）
• 接続の世代（connection_generation、再接続回数、プールの識別子）
• エラー分類（EPIPE、ECONNRESET、タイムアウト、429/503等）

「ログ増えるのが嫌だ」という抵抗は正しいです。だからこそ、“常時詳細”ではなく、エラー発生時だけ構造化して出すのが現実解です。運用のノイズを増やさず、必要な瞬間だけ情報密度を上げます。

---

メトリクスは「失敗回数」より「再接続の形」を取る

Broken pipeは、数だけ見ても判断できません。「10回出た」より、「どういう形で再接続が走っているか」の方が重要です。実務で効くメトリクスの例を挙げます。

メトリクス	見る理由	異常時のサイン
EPIPE発生率（宛先別）	どの依存先が切断源か	特定宛先だけ急増（LB/Proxy/相手の不調）
再接続回数と失敗回数	回復できているか	再接続が増え続け、成功に収束しない
バックオフ待ち時間分布	リトライ嵐の兆候	待ちが上限に張り付き、全体が詰まっている
重複排除ヒット数	“再送”が現実に起きているか	急増＝回線断や応答消失が頻発、または実装ミス

アラートは「失敗しました」ではなく「設計が崩れた」を通知する

アラートが“ただ鳴る”だけだと、結局人間がログを掘るしかありません。Broken pipe系で現場を救うのは、次のような設計崩壊アラートです。

• 再接続が一定回数以上連続失敗（依存先が落ちている、またはネットワーク経路が壊れている）
• 接続プールの健全性低下（壊れた接続が戻っている、あるいは同時接続が暴走している）
• 重複排除が急増（再送が増えている＝不安定化、二重処理リスク上昇）

---

運用の“腹落ち”ポイント：原因究明より、再発防止の型を作る

現場の本音として、「原因は分からないけど直った」が一番危険です。次に同じことが起きます。逆に言うと、毎回100%の原因特定を狙うより、再発時に迷わず動ける型を作る方が、運用負荷は確実に下がります。

ここまで整うと、Broken pipeは“恐怖”ではなく“イベント”になります。最後の章では、ここまでの伏線を回収し、設計の着地点（一般論の限界と、個別案件での判断ポイント）を明確にして締めます。

　

帰結：切れないより“戻れる”へ——Broken pipeを「起きても平気」にする再設計

ここまでの話を、現場エンジニアの感情に戻してまとめます。

「またBroken pipeか…」

このため息の正体は、“原因不明のまま夜間対応が繰り返される”ことへの疲弊です。だからこそ、ゴールは「絶対に切れない」ではありません。現実的なゴールは、切れても壊れず、戻れることです。

Broken pipeを“戻れる”に変える3つの柱

本記事の結論は、次の3本柱に収束します。

• 層の特定：どのFD/宛先/中間装置で「書き込み先が消えた」のかを掴む（strace・tcpdump・構造化ログ）
• 再接続の秩序：壊れた接続は破棄し、指数バックオフ＋ジッタで再接続を整流する（リトライ嵐を防ぐ）
• 再送の安全：冪等性・重複排除・ACK設計で「再送しても壊れない」ことを保証する

この3つが揃うと、Broken pipeは「運用の地雷」から「設計で吸収する前提条件」になります。逆に、どれかが欠けると、対策は増えても夜間対応は減りません。

---

一般論の限界：最適解は“どの層で責務を持つか”で変わる

ここで、あえて一般論の限界をはっきり書きます。Broken pipe対策は、アプリだけ頑張っても、ネットワークだけ頑張っても、ミドルだけ頑張っても、解けないことがあります。理由は、切断が複数層の相互作用で起きるからです。

例えば、LBのアイドルタイムアウト、アプリのKeepAlive、接続プールの再利用、バックエンドの負荷、タイムアウト不一致。これらが組み合わさると、“一見ネットワークに見える”けれど実態はバックプレッシャ、ということもあります。つまり、最適解は「あなたのシステムの現実」に依存します。

判断が難しいポイントほど、プロに相談すべき理由

特に終盤で読者が悩むのは、次のような局面です。

• 「再送したいが、二重処理が許されない業務が含まれる」
• 「LB/Proxy/Firewallが絡み、切断点が複数ある」
• 「レガシーで止められず、観測のための改修も最小限にしたい」
• 「一部だけ直すと別の障害（負荷スパイク、遅延悪化）が出そう」

これらは“正しい教科書”より、“現場の制約に合わせた設計判断”が必要です。しかも判断を誤ると、障害が短期的に悪化したり、データ不整合という高コスト事故に繋がります。ここが、一般論の限界です。

---

次の一歩：小さく始めて、壊れない方向へ寄せる

押しつけがましくならない形で提案します。最初の一歩は大改修ではありません。

• EPIPE発生時だけ、宛先・相関ID・接続世代を構造化ログで残す
• 壊れた接続をプールに戻さない（破棄）という運用事故の芽を潰す
• 再接続を指数バックオフ＋ジッタに統一し、リトライ嵐を防ぐ

この3点だけでも、夜間対応の“モヤモヤ”はかなり減ります。その上で、二重処理リスクがあるなら冪等性・重複排除へ進めばいい。段階的に、確実に「戻れる」側へ寄せていくのが現実的です。

もし、具体的な構成（LB/Proxy、アプリ言語、通信方式、タイムアウト値、再送要件、業務制約）まで含めて「どこで責務を持つべきか」「最小改修でどこまで安全にできるか」で悩んでいるなら、株式会社情報工学研究所のような専門家に相談する価値があります。現場を分かっている相手と一緒に、壊れない設計へ落とし込む方が、結果として早く・安く・安全に収束することが多いからです。

　

付録：主要プログラミング言語ごとの「Broken pipe / EPIPE」実装上の注意点

ここからは、同じBroken pipeでも“言語・ランタイム・標準ライブラリ”で見え方が違う点を、実務で困りやすいポイントに絞って整理します。以下は一般論であり、利用しているHTTP/DB/メッセージングライブラリや実行環境（コンテナ、LB、Proxy）で挙動は変わります。

C / C++

• 書き込み先が消えたとき、SIGPIPEでプロセス終了し得ます（デフォルト挙動）。EPIPEが返る前に落ちるケースがあるため、シグナルの扱いを明確にします。
• send/write の戻り値・errnoを必ず処理し、EPIPEが出たFDは再利用しない（クローズして作り直す）が基本です。
• “再送して良いか”は言語ではなく業務要件の問題です。再送するなら冪等性・重複排除が必須です。

Python

• Broken pipeは多くの場合 BrokenPipeError（OSError系）として表面化します。標準出力やパイプ先が閉じたケースでも出ます。
• 例外を握りつぶすと“成功したように見える”ログだけが残り、原因追跡が困難になります。宛先・相関ID・再接続回数を含めたログが重要です。
• 再接続・再試行はライブラリ側（HTTPクライアント等）に既に実装されていることが多く、アプリ側で二重に再試行するとリトライ嵐になり得ます（責務分担の明確化が必要）。

Go

• ネットワークI/Oは通常 error として返ります（例：write: broken pipe）。接続は使い回せない前提で、失敗時は破棄→再接続が基本です。
• ゴルーチンが多い構成で、失敗時に一斉再接続が走ると集中負荷になりやすいので、バックオフ＋ジッタ、上限、サーキットブレーカなどで秩序を作ります。
• コンテキスト（deadline/cancel）設計が曖昧だと、タイムアウトと再試行が衝突して、失敗が増えることがあります。

Java

• 多くの場合 IOException（例：Broken pipe）として見えます。どの層（HTTPクライアント、DBドライバ、gRPCなど）で出たかをログで区別しないと、対策が空回りします。
• コネクションプール（HTTP/DB）の挙動が重要で、壊れた接続がプールに戻らないようにする設定・実装が必須です。
• 再試行をフレームワーク/ミドル側に任せる場合、アプリ側で再試行を追加しない（責務の二重化を避ける）ことが安定運用に効きます。

Node.js（JavaScript）

• ストリームやソケットで EPIPE がイベント/例外として出ることがあります。未処理だとプロセスが落ちる、あるいはハンドラの外で落ちるケースがあり、エラーイベントの取り扱いが重要です。
• 再接続・再試行は“簡単に書ける”反面、並列が増えやすく、短時間にリトライが同期しやすいので、指数バックオフ＋ジッタを必ず入れます。
• ログに相関IDがないと、どのリクエストが失敗し、再送されたのかが追えず、二重処理の検知が難しくなります。

Ruby

• Broken pipeは Errno::EPIPE として出ることが多いです。例外処理で握りつぶすと、結果整合性（成功/失敗判定）が曖昧になります。
• HTTPクライアントやジョブ基盤（ワーカー/キュー）側の再試行と、アプリ側の再試行が二重化しやすいので注意が必要です。

PHP

• ソケット/ストリーム系でBroken pipe相当が warning/notice として扱われ、アプリが“処理継続してしまう”ケースがあります。エラーを例外化する方針やログ設計が重要です。
• CLIでパイプ先が閉じる（標準出力が切れる）ケースでも起きるため、Webだけの問題と決め打ちしないのがポイントです。

Rust

• std::io::ErrorKind::BrokenPipe 等で扱われます。型としては整理しやすい一方、どの層（HTTP、DB、IPC）で出たかの切り分けログは別途必要です。
• 再接続・再試行を手堅く作れる反面、並列性が高い構成で“同時再接続”が起きると負荷が集中するため、バックオフ＋ジッタの設計は必須です。

---

全言語共通の注意点（ここだけは外さない）

• Broken pipeが出た接続は再利用しない（破棄して作り直す）
• 再接続は即時連打しない（指数バックオフ＋ジッタ＋上限）
• 再送の前提を決める（冪等性・重複排除・ACK設計がない再送は危険）
• 観測できる形にする（宛先・相関ID・接続世代・再接続回数を残す）

もし「自社の構成だとどこで責務を持つべきか」「最小改修でどこまで安全にできるか」「二重処理が許されない業務をどう守るか」といった判断で詰まっているなら、一般論だけで決め切るのは危険です。具体的な案件・契約・システム構成に合わせて設計判断を行う必要があるため、株式会社情報工学研究所のような専門家への相談をご検討ください。