バグの特定と修正

コーディングエージェントが書くコードが増えるにつれ、エンジニアはそのコードの確認やバグの特定に多くの時間を費やすようになります。コーディングエージェントの支援があっても、効果的なデバッグの基本を改めて確認し、プロセスの一部をエージェントに任せて作業を効率化する方法を探ることは重要です。

デバッグの基本

人間が行う場合でもエージェントが行う場合でも、優れたデバッグは同じ原則に従います。

1. 確実に再現できる手順を作る。 バグを再現できなければ、修正できたか確認できません。問題を引き起こす正確な手順、入力、条件を書き留めます。
2. 最小限のケースまで絞り込む。 バグに関係のないものをすべて取り除きます。再現ケースが小さいほど、根本原因を見つけやすくなります。
3. 変数を切り分ける。 一度に変更するのは1つだけにします。3つ変更してバグが解消しても、どの変更で修正されたのかはわかりません。
4. 具体的な仮説を立てる。 根本原因として考えられるものについて、いくつか仮説を立てます。「バグはおそらく決済コードにある」では曖昧すぎます。「calculateTotal() が負の割引を考慮していないため、バグが発生する」であれば、テストできるほど具体的です。
5. コードにログを追加する。 問題があると疑う箇所の入力と出力にログを追加します。期待値と実際の値を比較します。
6. テストでリグレッションを防ぐ。 バグを見つけて修正したら、そのバグを検出できたはずのテストを書きます。これにより、同じバグの再発を防げます。

デバッグの2つの方法

単純なエラーをすばやく解決する

エラーメッセージが明確なバグや原因が単純なバグは、エージェントが問題を直接見つけて修正できる場合が多くあります。エラーを貼り付け、発生時の状況に関するコンテキストを伝えたら、エージェントに任せましょう。

TypeError: Cannot read properties of undefined (reading 'profile')
at getProfile (src/services/UserService.ts:45)
at UserController.show (src/controllers/UserController.ts:23)

原因がエラーメッセージから明らかな場合は、この方法が有効です。エージェントはスタックトレースを読み、該当するコードを見つけて修正できます。ただし、常にうまくいくとは限らず、根本原因を特定するには、より体系的なアプローチが必要になる場合もあります。

デバッグモード: まず証拠を集める

より厄介なバグには、デバッグモードが異なるアプローチを取ります。修正を推測するのではなく、まず実行時の証拠を収集します。

デバッグモードは、デバッグの基本に沿った5つのステップで進みます。

1. 起こりうる原因について仮説を立てる
2. コードに対象を絞ったログ出力を追加する
3. データを収集しながら、バグを再現するよう求める
4. ログを分析して根本原因を特定する
5. 収集した証拠に基づいて的を絞った修正を行う

デバッグモードは、特に厄介なバグの発見と修正に役立ちます。先ほど説明した基本を活用し、本来は手動で行う調査を自動化することで、エージェントを効果的なデバッガーにします。

複数のモデルを並行して実行する

難しいバグでは、モデルごとに異なる点を見つけることがあります。Cherri Code では、同じデバッグプロンプトを複数のモデルで同時に実行できます。各エージェントは分離された環境で動作するため、互いに干渉しません。

ワークフロー:

1. 再現手順と仮説を含む、明確なデバッグ概要を作成する
2. エージェントのドロップダウンから複数のモデルを選択する
3. プロンプトを送信する。各モデルが独立して作業する
4. 各モデルが提案した修正を比較する
5. 最も根拠の強いアプローチを採用する

Cherri Code は最適と判断した解決策を提案しますが、最終的な解決策だけでなく、その推論も評価してください。修正が正しいことをさらに確認するには、モデルに作業内容を検証させ、正しい解決策かどうかを確認するよう依頼できます。

実行時データをエージェントループに取り込む

エージェントはコードを読むだけでも、パフォーマンスの問題や一般的なバグを見つけられます。しかし、実行時の証拠を多く与えるほど、より深く調査できます。

質問から始める

調査を始める際、必ずしもログやプロファイリングツールが必要とは限りません。エージェントに直接質問すれば、コードを分析してよくある問題を見つけてくれます。

上の例では、エージェントはコードを読み解いて遅いクエリを見つけました。ログやパフォーマンスプロファイリングは不要です。パフォーマンスの問題によっては、これだけで十分です。

実行時の証拠を与える

コード分析だけでは不十分な場合は、エージェントに実際のデータを渡しましょう。ターミナル出力、クエリログ、その他のデータを会話に貼り付けます。エージェントはこのデータを使って、根本原因をより効率的に見つけられます。

たとえば、遅いデータベースクエリを調査している場合は、遅い Postgres クエリに対して EXPLAIN ANALYZE を実行し、その出力を貼り付けます。すると、エージェントが問題をスキーマまでたどれます。

Seq Scan on orders  (cost=0.00..45892.00 rows=47 width=244) (actual time=0.423..1203.112 rows=47 loops=1)
Filter: (user_id = 'usr_abc123')
Rows Removed by Filter: 2341856
Planning Time: 0.089 ms
Execution Time: 1203.298 ms

このパターンは、アプリケーションログ、プロファイリングデータ、ビルドやテストの出力にも使えます。

フロントエンドのデバッグにブラウザを使用する

フロントエンドの問題では、Cherri Code の統合ブラウザを使うと、エージェントが Web アプリケーションに直接アクセスできます。何かをコピーしなくても、コンソールログの確認、ネットワークリクエストの調査、DOM の観察が可能です。

エージェントにページを開き、問題を再現して、コンソールでエラーを確認したり、ネットワークタブで遅いリクエストを確認したりするよう依頼してください。エージェントは DevTools で表示される内容を確認でき、問題をソースコードまでさかのぼって追跡できます。

MCP で監視ツールに接続する

MCP サーバーを使うと、エージェントに新たな機能を追加し、本番環境の可観測性ツールに接続できます。データを手動で貼り付ける代わりに、エージェントが必要な情報を必要なときに取得します。

上記の例では、エージェントが MCP を介して Sentry をクエリし、関連するエラーの詳細を取得します。エラーとログを照合し、問題のあるコードを見つけ、修正案を提示します。これらはすべて同じ会話内で行われます。

デバッグに役立つ MCP サーバー:

• Sentry: エラーの詳細、スタックトレース、ブレッドクラム
• Datadog: 本番環境のログと APM トレース
• データベース: 仮説の検証に本番データをクエリ
• Linear または GitHub Issues: バグレポートと再現手順を会話に取り込む

本番アプリケーションの監視アラートをトリガーに、エージェントが自動的に調査を開始するワークフローを設定できます。エラー率が急増すると Linear にチケットが作成され、人が確認する前にエージェントが問題の診断を始めます。これにより、顧客から報告されたエラーの解決時間を短縮したり、顧客が気づく前に問題を修正したりできます。

よくある失敗パターン: 理解していない修正を受け入れる

修正内容を理解していなければ、それが正しいかどうかを検証できません。エージェントはエラーを解消するために null チェックを追加するかもしれませんが、根本的なデータの不整合は残ったままです。

エージェントが修正を提案したら、理解できるまで質問してください。なぜその値は null なのですか？何が変わってこの問題が起きたのですか？これは根本原因ですか、それとも症状を隠しているだけですか？基礎で説明したように、エージェントはもっともらしい説明を作り出すことがあります。自分で理解を深め、調査で得たデータを使って、エージェントが本当の根本原因を特定していることを確認する必要があります。

次のステップ

デバッグと、コーディングエージェントを活用して調査を迅速に進める方法を理解したら、変更内容が正しく、リグレッションを引き起こさないことを確認しましょう。次の章では、コードを確認し、体系的にテストする方法を学びます。