# しぶいSRE: サーバから見えない障害にどう向き合うか。ラストワンマイルのデバッグ実践 > [!info] Talk metadata > - **会議:** [[SRE NEXT 2026 参加録]]、Day 2（2026年7月11日）、Track B、13:00-13:40 > - **登壇者:** 星北斗（株式会社LayerX 執行役員 CISO 兼 バクラク事業 VPoE、ハンドル: kani_bkanny）。2024年1月にLayerXへ入社し、コーポレートエンジニアリング室室長、バクラク事業部PlatformEngineering部SREグループマネージャーを歴任。2024年7月より部門執行役員CISO、2025年10月より現職。 > - **URL:** https://sre-next.dev/2026/schedule/#slot097 > - **スライド:** https://speakerdeck.com/kanny/shibui-sre（本ノート執筆時点ではスライド未読込。文字起こしのみを出典として作成している） > - **出典:** [[しぶいSRE - transcript|一次ソース（公式アブストラクト、登壇者略歴、逐語文字起こし）]] > [!note] 日付に関する注記 > `event_date`・会場・時間は公式スケジュールページ（https://sre-next.dev/2026/schedule/#slot097 ）で確認済みの値である。 > スライドも存在しないため、他トークのスライドで裏付けられた「Day 1 = 2026-07-10、Day 2 = 2026-07-11」という会期の事実のみが分かっている。 > どちらの日のどのセッションだったかを特定する材料がないため、frontmatterに `date` / `event_date` は記載していない。 > [!abstract] 概要（公式アブストラクト） > サーバは正常、メトリクスも問題なし、アラートもない。 > それでもお客様からは「使えない」という声が……このような「観測できない障害」に遭遇したことはないだろうか。 > 本セッションでは、企業向けプロダクトの運用に携わるエンジニアを主な対象として、ユーザー環境に起因する問題に対して実践的に切り分け・調査を行うための具体的なアプローチを解説する。 > > プロダクトとユーザーの間には、ブラウザ、メーラー、プリンター、ネットワーク機器といった無数のソフトウェアとデバイスが存在する。 > とりわけ企業ネットワークにおいては、環境の差異やセキュリティへの取り組みによって「サーバサイドから見ているだけでは気づかない」問題が起こりやすい傾向がある。 > こうした問題が起こると、どこに原因があろうとユーザーから見れば「使えないプロダクト」と感じられてしまう。 > サービスの信頼性に責任を持つSREとしては、こうした問題にも踏み込んでいくことが求められる。 > > 本セッションでは、発表者が企業向けプロダクトの運用において実際に遭遇した「ページが表示されない」「表示が遅い」「メールが届かない」といったトラブルを題材に、調査から解消に至るまでのプロセスを具体的に紹介する。 > 業務効率化AIエージェントサービス「バクラク」の事例をもとに、HARファイルの読み解きによるパフォーマンス問題の特定、SMTPやメール仕様に起因する配送トラブル、DNSリゾルバと長大なレコードによる問題など、現代でも発生する「ラストワンマイル」の障害に対する実践的なデバッグ手法を解説する。 > > これらの知見を通じて、サーバサイドの観測だけでは捉えきれない問題に対して、再現性のある調査・切り分けを行い、ユーザー環境に踏み込んで解決できるようになるための視点と具体的な手法を提供する。 ## サーバサイドメトリクスが映さないユーザー環境の複雑さ - お客様から「機能が使えない」「表示が遅い」「メールが届かない」といった問い合わせが来て調査を始めても、サーバのログやメトリクスは普段どおりで異常が見当たらない、という状況はよくある。サーバに問題がないという理由で「お客様側の環境の問題ではないか」と伝えて再起動を促しても直らず、そのままチケットの返信が途絶えたり、お客様に落胆されたりする経験は珍しくない、と切り出した。 - ここで問い直すべきなのは、普段見ているログやメトリクスがそもそもどの範囲のデータなのか、という点である。クライアント、インターネット、サーバの関係を示す図を使い、サーバサイドのメトリクスはこの図の右端、サーバ自身が観測できる領域だけを示すデータだと説明した。実際に問題が起きているのは、多くの場合サーバではなくクライアント側や、そこに至るまでの通信環境である。 - 具体例としてNginxのレスポンスタイムを挙げた。リクエストの最初のバイトを読み込んだ時点で計測を始め、レスポンスの最後のバイトをソケットに書き込んだ時点で計測を終えるため、あくまでNginxから見た始点と終点でしかなく、お客様の手元にデータが届くまでの時間を示しているわけではない。その間には、リバースプロキシ、ロードバランサー、クライアント側のプロキシやゲートウェイなど多くの要素が挟まっている。 - ユーザー環境は200種類以上あると言われる。OSやブラウザだけでなく、企業ネットワークではスイッチ、ルーター、ファイアウォール、メーラー、メールサーバ、セキュリティゲートウェイ、EDR、プリンターなど無数のソフトウェアとハードウェアが組み合わさって使用環境を構成している。サーバサイドのメトリクスは、この構成全体のうち右端だけを見ているにすぎない。 - モニタリングダッシュボードは便利だが、サーバサイドのメトリクスだけを見ている限り観測できる範囲は限られる。ボトルネックの発生箇所自体を観測できないこともあれば、プロトコルが同じでもクライアントによって挙動が異なることもある。結果として原因不明のまま再現もできず、お客様を落胆させてしまう。 - 責任の所在も一様ではない。システム管理者が必ずしもその環境の管理者とは限らず、バクラクのお客様の場合、プロダクトを管理しているのは経理や財務の担当者であることが多い一方、他のシステム管理は情報システム部門が担っている。管理者であっても構築や運用を外部委託しているケースもあり、EDRをはじめとするセキュリティソフトも製品ごとに挙動が異なるため、実態を把握するのは容易ではない。 - それでも「再起動で直ってくれないか」で済ませてよいのか、というのが本セッションの問いである。サービスの信頼性はユーザーが実際に使うことで初めて成立するものであり、SREとしてお客様の手に届く瞬間である「ラストワンマイル」のトラブルにもできる限り向き合いたい、と述べた。ただしお客様環境を直接コントロールすることはできず、問題の発生箇所すべてに出向いて直すことも非現実的であるため、現実的な打ち手はツールで情報を集め、仮説を立てて検証し原因を特定するという、通常のトラブルシューティングと変わらない手順になる。 ## 一次情報にアクセスするための調査の型 - お客様環境の調査で最も重視しているのは、カスタマーサポートや営業などお客様と直接やり取りする担当者と密に連携できる体制を作ることである。そこを通じて、受け取ったチケット、メール、添付ファイル、会話といった一次情報にできる限り直接触れることが重要であり、また聞きで推測しようとすると問題がかえって複雑になる。 - ヒアリング項目もパターンとして自分の中に持っておくとよい。OS、ブラウザ、メールクライアントのバージョン、ハードウェアの性能、そして問題を引き起こすことが多いセキュリティ関連の環境などを聞く。お客様との往復（聞いて返してもらうやり取り）をできるだけ減らすことも重要であり、システムが期待どおり動かない状況でお客様に協力してもらっている以上、そのサポート体験自体がプロダクト体験の一部だと捉えている。可能な限り生データやログをもらうことも欠かせない。 - バクラクでは、利用環境をまとめて収集できるよう、ブラウザで実行できる環境情報収集の仕組みを用意している。トラブルのあったお客様には専用の画面を送って実行してもらい、クライアント側のJavaScriptでデータ転送の帯域幅、プロダクトのエンドポイントへのレイテンシー、ネットワークの所在地などを測定する。結果はBase64でエンコードされてメールで送られてくるため、それをデコードするだけでも多くの情報が得られる。 - 調査の進め方としては、まず自社システム側に問題がないかをサーバサイドで確認し、そのうえでお客様へのヒアリングを行う。メトリクスとヒアリングで得た情報を突き合わせて問題が起こり得る場所を整理し、場所ごとに仮説を立てて検証する。ヒアリングした環境に近いものを自社で再現できると効果的であり、たとえばネットワーク帯域やパケットドロップが疑われる場合は、それに近い状態を意図的に作って検証する。自社で検証しきれないものについては、追加のヒアリングを重ねていく。 ## ケース1: HARファイルとウォーターフォールチャートで切り分けたブラウザの表示遅延 - 最初の事例は、オフィスネットワークで特定のシステムだけ読み込みに時間がかかるが、他のシステムには問題がない、というものだった。インターネット環境の障害はなく、マシンスペックも十分で、サーバ側のログを見てもレスポンスタイムは正常だった。確認できる範囲がすべて正常ということは、サーバがレスポンスを返してからクライアントに届くまで、あるいはクライアント側で最終的に処理されるまでの間に問題があると判断できる。この調査のために、**HARファイル**を提供してもらうことにした。 - HARファイルは、ブラウザとウェブサイトとのやり取りにおける処理時間などのパフォーマンスデータを保持するフォーマットで、実体はJSONである。ブラウザ自体やHARビューワーで閲覧できる。POSTパラメータやクッキーなど機微な情報を含むため受け渡しや取り扱いには注意が必要であり、クッキー情報などを除去する「HARサニタイザー」を通してから扱うとよい、と述べた。 - HARの利点は、お客様のブラウザで起きている事実を高い解像度で把握できることにある。DNSの解決結果やヘッダーなどの情報も含まれ、取得のためにお客様へ大きな負荷をかける必要もない。より踏み込んだヒアリングをする前の段階で、一定の洞察を得られる。同様にリモートで情報を集める仕組みとして**RUM（リアルユーザーモニタリング）**もあるが、リクエストごとにログを収集するためボリュームが大きくなりがちであり、コストを抑えるためにサンプリングすると個別のトラブル調査には向かなくなる。個別ケースに向き合う際は、直接HARをもらう方が近道になる。 - HARからは、ブラウザからのリクエストがキューに入れられている時間、ユーザー側プロキシへの接続時間、DNSルックアップの時間、TCPとTLSのハンドシェイクの時間、リクエスト送信にかかる時間、サーバの応答を待つ時間、コンテンツのダウンロード時間までを観察できる。これらのアセットごとの時間を並べた**ウォーターフォールチャート**を見ることも有用な手立てである。 - 今回のケースのウォーターフォールチャートからは、サーバへのTCP接続自体に時間がかかり、リクエストの送受信にも時間がかかっていて、日本国内のはずが米国程度のレイテンシーになっていることが読み取れた。サーバサイドのレスポンスタイムは50ミリ秒台であり、この数字と矛盾する。一方でデータの転送自体はグラフの一番右側（青色の部分）が示すとおり一瞬で終わっており、複数の応答待ちが同時に始まり同時に終わるという挙動を示していた。 - ここから、クライアントとサーバの間でTCP接続を中継する何かが存在すると推測できる。HTTPプロキシのコネクション記録が見当たらないことから、TCPレイヤーでの中継、具体的には**ファイアウォールによるTLS検査**だと判断した。今回の接続はHTTP/2が使われており、HTTP/2は1つのTCPセッションの中で複数のリクエストを多重化して送受信するため、ファイアウォールがTCPセッションないしHTTP/2ストリーム単位でデータをバッファリングし、復号して検査したうえでクライアントに渡している、つまり一定時間ためてからまとめて送り出すという挙動をしていると想像がついた。 - 結論として、お客様側のセキュリティ製品がボトルネックになっている、企業ネットワークでよくある問題の一つであり、事業者側でできることは多くない。HTTP/2を無効にすることで体感速度が改善する場合や、アセットをまとめたりミニファイしたりするチューニングが有効な場合もあるが、大きな解決の糸口になるのはお客様側の情報システム部門に問い合わせ、ファイアウォールのチューニングルールを見直してもらうことだった。 ## ケース2: SMTPUTF8のMTA間対応不整合が招いたメールのサイレントロスト - メールは特定の企業やプラットフォームに依存せず、異なるサービス間でも通信でき、非同期でやり取りでき、組織の境界を越えて公式な記録として扱われることもある（訴訟でメールのログが使われる例もある）、グローバルでオープンなメッセージ基盤だ、と紹介した。バクラクでも通知手段として広く使われており、お客様のワークフロー通知や取引先への送付、請求書メールの受信からシステムによる自動ダウンロードとパースまで、システム同士やシステムと人をつなぐ重要な手段になっている。 - メールを支えるSMTPは歴史の長いプロトコルであり、SMTPサーバはメーラーやウェブアプリケーションからメールを受け取って相手先に転送するほか、あるSMTPサーバから別のSMTPサーバへとリレー（中継転送）することもある。メール環境はサーバとクライアントの種類、検査ゲートウェイ、対応言語（MIMEによる文字エンコーディング）など非常に多様であり、自前でSMTPサーバを運用する難易度は高い。そのため、到達性を上げつつ複雑性を下げる目的で、多くの場合クラウドサービスを使う。バクラクでも外部サービスを利用しており、送信はそのまま行い、受信は外部サービスからのWebhookを受け取ってAmazon S3に保存し連携している。 - 今回の事例は、バクラクからメールを送っても届かないというもので、利用している送信サービスのログは正常だった。エラーが出ないため、かえって調査しづらい。送信先のドメイン担当者にヒアリングを進めると、送付先から「**SMTPUTF8**に対応していない」というエラーが出ていたこと、MXレコードがメール転送サービスのホストを指していたことが判明した。つまり構成は送信元、リレーサーバ、転送先の三者からなり、真ん中のリレーサーバのところでメールが失われていた。 - SMTPUTF8は、メールアドレスに日本語などマルチバイト文字を使う国際化メールアドレスに対応するための規格である（例として自身の保有ドメインを使ったsushi@だんげ.jpを挙げた）。対応していれば、本来MIMEエンコードが必要なメールヘッダーをUTF-8のまま送信できる。対応可否は、送受信双方のMTAが最初に交わすSMTPグリーティング（HELO/EHLO）で判別され、EHLOへの応答にSMTPUTF8対応の有無が含まれる。対応していればUTF-8のまま送り、対応していなければMIMEエンコードして送るという切り替えが行われる。Postfixをはじめ対応するMTAは増えており、今回使っていた外部サービスも対応していた。 - 問題は、送信元、中継リレー、最終的な転送先という3ホップの構成で、送信元とリレーはSMTPUTF8に対応しているが最終的な転送先が対応していない場合に起きる。送信元はリレー（直接の受信相手）がSMTPUTF8に対応していると判断してメールを送るが、これはエンドツーエンド、つまり最終的な転送先までを確認したものではない。リレーはSMTPUTF8対応のメールをそのまま転送先に転送し、転送先が対応していないためエラーになるが、そこから先はリレーの実装依存であり、送信元にエラーを直接通知する仕組みを備えていない場合、メールはサイレントに失われる。今回検証したケースは、まさにこのサイレントロストの仕様になっていた。対応していない転送先に対してメールをダウングレード（MIMEエンコードへ変換）して中継する実装も存在するが、現時点でこれを備えたMTAはほとんどないという。この挙動は、Amazon EC2上に検証環境を構築して確認した。 - 自前のMTAを持たないため、SMTPUTF8そのものを無効にすることはできない。外部サービスの仕様を調べたところ、添付ファイル名に日本語が使われているとSMTPUTF8が有効になることが判明し、それを避けることでお客様に回避してもらう方法を見つけた。リレーサービス側がすべてSMTPUTF8に対応してほしい、と述べた。 ## ケース3: message/partial分割とプリンター設定によるメール添付欠落 - 次の事例は、添付ファイル付きのメールをバクラクに送ったのに添付ファイルがない、という問い合わせだった。ヒアリングすると、プリンターから直接送信したという。領収書などをスキャンしてそのままメール送付するケースは多い。 - 確認すると、添付ファイルがまったく到達しておらず、実質的に空のメールが届いていた。ただし、Content-Typeには「**message/partial**」が含まれていた。 - message/partialは、メール本体を分割して送信できる古い仕様である（検索すると2000年代前半の記事が多く出てくる、と紹介した）。分割された各パートはそれぞれ1通の独立したメールとして送信され、受信側で組み立てる必要がある。使用している外部サービスにはmessage/partialを組み立てる機能がなく、個々の分割メールがそれぞれボディを考慮しない空メールとして着信していたため、添付ファイルが消えていた。 - 回避は不可能に見えたが、ヒアリングでプリンターの型番を聞き、そのドキュメントを調べたところ、「スキャンファイルをメール送付する際の分割形式」という設定項目が見つかった。設定名としては明記されていないマニアックな項目だったが、message/partial形式で送るか、ファイルのページ自体を分割して送るかを選べるようになっており、ページ分割形式に変更してもらうことで問題を回避できた。 ## ケース4: 36行のAレコードが招いたDNSのTCPフォールバック失敗 - 最後の事例は、通知メールに含まれるクリックトラッキング用リンクを複数のお客様が急に開けなくなった、というものだった。通知状況の追跡には外部のクリックトラッキングサービスを使っており、お客様から届いたエラーは「**NXDOMAIN**」（ドメインが引けない）というものだったが、自社側でDNSレコードを確認する限りは正常に参照できているように見えた。よく見ると、該当エンドポイントの**Aレコード**が36行にわたって返されていた。 - ここで起きていたのが、DNSの**TCPフォールバック**問題である。DNSは既定でUDPを使い、応答全体は512バイトに収める必要があるが、今回はAレコードが36行あり、応答は600バイトを超えていた。512バイトを超える場合は、**EDNS0**というDNSの拡張機能を使うか、TCPにフォールバックする必要がある。しかし企業ネットワークでは、ネットワーク内に置かれたDNSキャッシュサーバがこれらに対応していない場合や、TCP53番ポートの外向き通信（イーグレス）がファイアウォールで塞がれていてTCPフォールバックできない場合が多々ある。この結果、DNS応答自体が返らず、クライアント側でエラーになる。 - この問題は、サービス提供者側からは観測できない。DNSの正引きテストは普通に成功するため、サービス提供者側には特にエラーが返ってくるわけではなく、問題はもっぱらお客様側のクライアントで起きる。解決には、Aレコードを大量に返している当該サービスプロバイダーに直接連絡し、事情を説明して対応してもらう必要があった。 ## サーバサイドの成功とユーザー体験の成功は別の話 - SREの業務内容は変わりつつある。アプリケーション開発やTerraformの記述、ログ分析、サーバサイドの障害分析といった開発や運用の仕事はAIエージェントなどによって素早くこなせるようになってきているが、実際に動いているもの、すなわちアプリケーション、API、コンテナ、OS、ネットワークといった仕組み自体はさほど変わっていない。将来的にAIによって制御の方法は変わっていくとしても、TCP/IPのようなプロトコルが急速に置き換わるわけではなく、こうした仕組みがどう動いているかを把握し、広い視野で問題を解決することは今後も人間に求められる、と述べた。 - まとめとして、システムはサーバサイドだけで完結しておらず、ユーザー環境はサーバサイド以上の複雑さと多様性を持つ。ログやメトリクス上の成功は、必ずしも最終的なユーザー体験としての成功を意味しない。「ラストワンマイル」の配送がうまくいっているかどうかは別の話であり、そこもSREとして信頼性の一部として捉え、最終的なユーザー体験にも寄与したい、と述べた。同じプロトコルでも実装や環境によって挙動が異なるためデバッグは難しくなるが、問題の再現が難しい状況でも、適切なコミュニケーションと仮説検証によって原因を特定できる、とまとめた。 - 最後に、LayerXは各事業でSREを積極的に採用しており、特にバクラク事業のSREを募集していると述べ、ビジネス、AI、ソフトウェア、インフラのすべてに向き合いたい人材を歓迎すると呼びかけて講演を締めくくった。