実機の描画不具合をリビルドなしで検証し、1時間弱で回避策を発見。「RenderDoc」「Claude Code」の連携手法をサイバーエージェント「コアテク」が解説

サイバーエージェント ゲーム・エンターテイメント事業部 コア技術本部（以下、コアテク）は2026年10月20日（火）、「AIとRender Docの連携による描画不具合の調査」と題した記事を技術ブログで公開しました。

グラフィックスデバッガー「RenderDoc」のPython APIとプログラミング支援AIツール「Claude Code」を組み合わせ、Android実機でのみ起きる描画不具合の原因をアプリのリビルドなしで調査し、対処を施した事例を紹介しています。

（画像はブログ記事より引用）

Unityで開発したアプリの実機で描画不具合を調べるとき、従来のフローでは多くの場合、シェーダーを書き換えるたびにアプリをビルドし、書き換え前後の結果を見比べることになるといいます。大規模なプロジェクトではビルドに数時間かかることも珍しくなく、原因の絞り込みに数日〜数週間を要する場合もあります。

記事で紹介された手法では、RenderDocのPython APIを使い、キャプチャしたフレームの上でシェーダーの差し替えと結果の確認を繰り返します。

解析用スクリプトの作成や、仮説に基づく検証の実行においてはClaude Codeの支援を受けつつ、調査方針を定めたり、結果を踏まえて次に検証する内容を判断したり、採用する修正を選んだりといった意思決定は人間が行いました。

記事では、シェーダーを差し替えて実機でリプレイし、描画結果を検出・確認する流れを、Pythonスクリプトのサンプル（※）を添えつつ解説しています。
※　「RenderDoc 1.42」および「Vulkan SDK 1.3.296.0」を実行環境として実際に使用したPythonスクリプトを、記事での説明用に簡略化したものを掲載している

シェーダーの差し替えにあたっては、キャプチャデータからシェーダーの中間表現であるSPIR-Vを抽出し、Vulkan SDKの一部として提供される「SPIR-V Tools」に含まれるツールで逆アセンブルして書き換えた後、再アセンブルします。

書き換えたSPIR-VをRenderDoc APIでリプレイ時のシェーダーと差し替えるため、アプリをビルドし直す必要はありません。

SPIR-Vを逆アセンブルして書き換え、再アセンブルし、シェーダーを差し替える流れ（画像はブログ記事より引用）

シェーダーを差し替えた後、Androidの実機でキャプチャデータをリプレイし、描画結果を検証します。

従来は目視で描画結果を確かめていたところ、今回の手法ではRenderDoc APIで各パスのレンダーターゲットやバッファの値を検出することで、不具合の有無を数値で判別できます。チェック対象はキャプチャした1フレームに限られますが、記事中の検証環境では、シェーダーの差し替えから実機リプレイによる確認までを数分程度で完了できたとのこと。

（画像はブログ記事より引用）

記事では、Androidの実機でのみ画面が真っ黒になる不具合について、今回の手法をもとに調査を実施。シェーダーの差し替え回数は約30回に上りましたが、原因特定から有効な回避策の選定まで調査開始から1時間弱で完了でき、検証サイクルを大きく短縮できたとしています。

詳細はブログ記事をご確認ください。