APMで見えない「謎の遅延」を、strace × Claude Codeで瞬殺する

この記事はトラストバンクAdventCalendar 1日目になります

SREグループで活動している@tb_furutaです。
AdventCalendar初参加です。1日目ということもありライトに行きたいと思います。

はじめに

「APM（DatadogやNew Relic）上では処理時間が正常に見えるのに、なぜかレスポンスが遅い」
「特定の条件下でだけ、謎のレイテンシスパイクが発生する」

SREやバックエンドエンジニアであれば、こうした 「APMの死角」 にあるボトルネックに悩まされた経験があるはずです。アプリケーションコードの外側、つまり ミドルウェアの挙動、カーネルレベルのロック、ファイルI/Oの詰まり などは、通常のAPM計測では「その他」や「待機時間」として丸められがちです。

そんな時、我々には古の武器 「strace」 があります。しかし、straceが吐き出す数万行のシステムコールログを目視で解析するのは苦行でしかありません。

そこで提案したいのが、　「straceで事実を集め、Claude Codeで解析する」　というアプローチです。この組み合わせにより、従来数時間かかっていた低レイヤーのトラブルシューティングが数分で完結する可能性があります。

なぜ strace × Claude Code なのか？

straceの課題：情報量が多すぎる

straceはプロセスが発行するシステムコールを全て記録するため、原因を突き止めるには有用なツールです。しかし、数秒のアタッチで数万行のログが出力されることもザラで、人間が読むにはノイズが多すぎます。

Claude Codeの強み：圧倒的なコンテキスト処理

AnthropicのCLIツール「Claude Code」は、巨大なテキストデータを飲み込み、以下の処理を行うのが得意です。

• 集計: 実行時間が長いシステムコールをランキング化
• 要約:「何をしていて詰まっているか」を自然言語で解説
• 異常検知: 一般的な挙動と異なるパターン（N+1的なシステムコール呼び出しなど）の発見

つまり、 「熟練のカーネルエンジニアが隣にいて、ログを代わりに読んでくれる」 状態を再現できます。

実践フロー

ここからは、実際に謎の遅延が発生しているプロセスを解析する手順を紹介します。

前提環境

• Linux環境（検証用サーバー推奨）
• strace コマンドがインストールされていること
• Claude Code (CLI) のセットアップが完了していること

Step 1: ボトルネックの再現とstraceの取得

まず、対象のプロセスID（PID）を特定し、straceを実行します。

本番環境での実行について straceはシステムコールごとにコンテキストスイッチが発生するため、アプリケーションのパフォーマンスを著しく低下させる（オーバーヘッドが大きい）可能性があります。 本番環境で実行する場合は、トラフィックが少ない時間帯を選ぶか、-p で特定のワーカープロセス1つだけに絞るなど、細心の注意を払ってください。可能な限り別の環境（検証環境等）で行うようにしてください。

# 対象のPIDを確認
ps aux | grep <process_name>

# straceを実行してファイルに出力
# -p: PID指定
# -f: 子プロセス(スレッド)も追跡
# -T: システムコールの所要時間を記録
# -tt: マイクロ秒単位のタイムスタンプ
# -o: 出力先ファイル
sudo strace -p 12345 -f -T -tt -o trace.log

この状態で、遅延が発生する操作（APIリクエストなど）を実行し、完了したら Ctrl+C でstraceを停止します。

Step 2: Claude Code への解析依頼

取得した trace.log は膨大です。これをClaude Codeに解析させます。 単純に「解析して」と投げるのではなく、 「遅延の原因特定」 にフォーカスしたプロンプトを渡すのがコツです。

# Claude Codeに解析を依頼するプロンプト例
あなたはLinuxカーネルとパフォーマンスチューニングの専門家です。
trace.logは、Webアプリケーションのレスポンス遅延調査のためにstraceで取得したものです。

以下の観点で分析を行い、ボトルネックの原因を特定してください。

1. 実行時間の集計: 最も時間がかかっているシステムコールTop 5と、その具体的な引数、所要時間を挙げてください。
2. ブロッキングの検出: ファイルディスクリプタ（FD）に対する操作で、長時間のwaitが発生している箇所はありますか？
3. 異常なパターン: 同じファイルの open/close が繰り返されている、あるいは無駄なシステムコールがループしているなどの非効率な処理はありますか？

結論として、アプリケーションコードや設定のどこを見直すべきかアドバイスをください。

ケーススタディ：実際に何が見つかるのか？

私が実際にこの手法を使って特定できた事例をいくつか紹介します。

事例A：ロック競合

特定のFDに対する排他ロック(F_WRLCK)の取得に時間がかかっています。
キャッシュミスや再検証時に排他ロック競合が発生しています。

原因: cacheの設定ミスで都度アクセスするようになっていました。

事例B：外部API通信のIPv4フォールバック

特定の通信先に対してIPv6で通信しようとして接続できず、IPv4で接続するということを繰り返しています。

原因: 環境の問題でIPv6の接続は行えない状況となっていました。

Tips: 解析精度を上げるコツ

• ノイズを除去する：ログが数十MBを超える場合、Claudeのコンテキスト上限に引っかかる可能性があります。grep などでエラー発生時刻付近を切り出すか、明らかに無関係な行を除外してから渡すと精度が上がります。
• セキュリティへの配慮：write システムコールの引数には、パスワードや個人情報が含まれる可能性があります。機微なデータが含まれる可能性がある場合は、事前に sed 等でマスキングを行うか、Claudeの設定（Privacy設定）を確認してください。

まとめ

性能改善において最も難しいのは「修正すること」ではなく 「原因を特定すること」 です。

低レイヤーの調査は「泥臭い」「職人芸」と思われがちですが、AIを活用することでそのハードルは劇的に下がります。「APMで見つからないから手詰まり」と諦める前に、ぜひ strace × Claude Code の組み合わせを試してみてください。

5分後には、犯人が特定できているかもしれません。

さいごに

トラストバンクでは、一緒に働く仲間を絶賛募集しています。

トラストバンクAdventCalendar 2025を見て、少しでも気になった方は、是非ご連絡ください。