既存コード調査をClaude Codeで進める方法｜機能の場所と処理の流れを見つける

May 29, 2026

既存コードの改修では、いきなり実装に入るのではなく、まず対象機能がどこにあり、どのような順番で処理が動いているのかを把握する必要があります。仕様書が古い、担当者が変わっている、ディレクトリ構成が複雑といった状況では、調査だけで多くの時間を使ってしまうことも少なくありません。

Claude Codeは、コードベースの読み取り、ファイル編集、コマンド実行、開発ツールとの連携に対応したコーディング支援ツールです。既存コード調査では、機能の場所を探す、処理の流れを追う、影響範囲を整理する作業の起点づくりに活用できます。

この記事では、Claude Codeを使って既存コード調査を進める方法を解説します。
機能の場所を見つける手順、処理フローを追う考え方、影響範囲を確認する際の注意点を整理し、改修前の調査を安全かつ効率的に進めるための考え方を紹介します。

既存コード調査で最初に確認すべきこと

既存コード調査では、最初から特定の関数やファイルだけを追うと、処理の前後関係を見落としやすくなります。まずはプロジェクト全体の構造を把握し、そのうえで対象機能に近づいていく進め方が重要です。

いきなり細部を読む前に全体像を把握する

Claude Codeを使う場合も、最初に聞くべきことは「この機能はどこですか」ではありません。まずは、プロジェクトの目的、利用している技術、主要なディレクトリ構成、エントリーポイントを確認します。

全体像を把握するためのプロンプト例

このプロジェクトの全体構成を確認し、主要なディレクトリ、画面表示、API処理、共通処理、テストコードがどこに分かれているか整理してください。

全体像を把握すると、フロントエンドの画面側を見ればよいのか、バックエンドのAPIを追うべきなのか、共通処理や設定ファイルを確認すべきなのかを判断しやすくなります。既存コード調査では、この最初の切り分けが後続の調査精度を左右します。

調査対象を「画面・機能・API・文言」に分解する

対象機能を探す際は、曖昧な言葉のままClaude Codeに質問しないことが大切です。「会員登録機能を調べてください」だけでは、関連ファイルが広くなりすぎる可能性があります。

そのため、画面名、URL、APIパス、ボタン名、フォーム項目、エラーメッセージ、表示文言など、コード内に残っている可能性が高い情報を使います。

調査対象を探すときのプロンプト例

管理画面の「承認する」という文言、関連するルーティング、API、ボタン押下時の処理を手掛かりに、実装箇所の候補を探してください。

このように具体的な手掛かりを渡すことで、Claude Codeがファイル探索やキーワード検索を行いやすくなります。質問の精度が、調査結果の精度に直結します。

Claude Codeで機能の場所を見つける手順

全体像を把握したら、次は目的の機能がどこに実装されているかを探します。ファイル構成、キーワード検索、候補ファイルの読み分けという順番で進めると、調査結果を整理しやすくなります。

ファイル構成とエントリーポイントから候補を絞る

まず、Claude Codeにプロジェクトのファイル構成を確認させます。フロントエンドとバックエンドが分かれているのか、画面ごとにディレクトリが分かれているのか、APIごとにファイルが分かれているのかを把握します。

候補を絞るためのプロンプト例

このプロジェクトで、画面表示、APIルーティング、業務ロジック、データベースアクセス、テストコードがそれぞれどこに配置されているか整理してください。

この段階では、まだ特定のファイルを正解と決めないことが重要です。
まずは、候補になりそうな領域を絞ります。
画面の表示に関する機能であれば、ページ、コンポーネント、状態管理、API呼び出しが候補になります。バックエンドの処理であれば、ルーティング、コントローラー、サービス層、モデル、リポジトリなどが候補になります。

キーワード検索で実装箇所の候補を探す

次に、画面名やURL、API名、表示文言、関数名、コンポーネント名などを手掛かりに検索します。Claude Codeはコード探索、バグ修正、リファクタリング、テストなどの日常的な開発作業に使えるため、関連ファイルを見つける調査とも相性があります。

実装箇所の候補を探すためのプロンプト例

「/users/approval」というAPIパスに関連するルーティング、コントローラー、サービス層、テストコードを探し、候補ファイルを一覧にしてください。

ここで得られる回答は、確定情報ではなく候補として扱います。候補ファイルを実際に読み、処理のつながりを確認していくことが重要です。

候補ファイルを「入口・本体・出口」に分けて読む

実装箇所の候補が見つかったら、ファイルを順番に読むのではなく、処理を「入口・本体・出口」に分けて整理します。

入口とは画面操作やAPIの受け口、本体とは入力チェックやデータ更新などの業務ロジック、出口とはレスポンスや画面反映、ログ出力などの処理結果が表れる場所です。

処理の流れを整理するためのプロンプト例

この機能について、処理の入口、本体、出口に分けて、関係するファイル名と関数名を整理してください。

この整理を行うことで、単に「ファイルの場所が分かった」という状態から、「どこから処理が始まり、どこで判断され、どこに結果が返るのか」を把握した状態に進めます。

処理の流れをClaude Codeで追う方法

機能の場所が分かっただけでは、既存コード調査としては不十分です。改修や不具合修正に進むには、呼び出し関係、条件分岐、エラー処理まで含めて、処理の流れを確認する必要があります。

呼び出し元と呼び出し先を順番に確認する

既存コードでは、ひとつの機能が複数のファイルに分かれていることがよくあります。画面側のイベント、API呼び出し、バックエンドのルーティング、サービス層、データベース処理が分かれている場合、ひとつのファイルだけを読んでも全体像は分かりません。

呼び出し元と呼び出し先の順番を確認するためのプロンプト例

この関数がどこから呼び出され、どの処理を経由して結果を返しているか、ファイル名と関数名を含めて順番に整理してください。

単なる関連ファイル一覧ではなく、処理順序として把握することで、改修時に触るべき箇所と触るべきでない箇所を判断しやすくなります。

条件分岐・エラー処理・例外ルートを確認する

処理フローを確認するときは、正常系だけを追ってはいけません。既存コードの改修で問題が起きやすいのは、通常処理よりも条件分岐や例外処理です。

権限がない場合、入力値が不足している場合、外部APIが失敗した場合、対象データが存在しない場合など、実務ではさまざまな分岐があります。これらを確認しないまま改修すると、一部の条件だけで不具合が起きる可能性があります。

条件分岐・エラー処理・例外ルートを確認するためのプロンプト例

この処理について、正常系、入力エラー、権限エラー、データ未存在、外部API失敗時の分岐を整理してください。確認できたファイル名と関数名も併記してください。

特に、バリデーション、認証、例外処理、ログ出力は見落としやすいため、明示的に確認することが重要です。

処理フローを調査メモとして整理する

既存コード調査の結果は、その場で理解するだけでは不十分です。後から見返せるように、調査メモとして残す必要があります。

調査結果メモを作成するプロンプト例

調査結果を、機能概要、処理の入口、主な処理、条件分岐、関連ファイル、未確認事項に分けて整理してください。

ただし、調査メモには「確認済みの事実」と「推測」を分けて書くべきです。たとえば、「この関数でDB更新を行っている」はコードで確認できた事実ですが、「この処理は管理者だけが使う想定」は、権限チェックやルーティングから読み取った推測かもしれません。

調査メモには、根拠となるファイル名、関数名、確認した処理内容を残します。これにより、レビューや引き継ぎの際にも使いやすくなります。

影響範囲を確認して安全に改修へ進む

機能の場所と処理の流れを把握したら、次に確認すべきなのは影響範囲です。既存コードでは、ひとつの変更が別の画面、API、共通処理、テストに影響することがあります。

変更候補の周辺ファイルを確認する

改修対象のファイルが分かっても、そのファイルだけを見て判断するのは危険です。呼び出し元、呼び出し先、共通関数、型定義、設定ファイル、テストコードなど、周辺ファイルも確認します。

周辺ファイルを確認するためのプロンプト例

このファイルを変更した場合に影響しそうな呼び出し元、呼び出し先、共通関数、テストコードを整理してください。

Claude Codeが挙げる影響範囲は、あくまで調査上の候補です。実際に影響があるかどうかは、参照関係、テスト結果、実行ログ、画面動作などで確認します。

既存コード調査では、いきなり編集させるのではなく、まず読み取りと整理を中心に進める方が安全です。改修に入る前に、変更候補と確認対象を分けておくことで、不要な変更や見落としを防ぎやすくなります。

テストコード・Git差分・ログで確認する

Claude Codeの回答だけで、実装箇所や影響範囲を確定してはいけません。調査結果は、テストコード、Git差分、ログ、実行結果と合わせて確認します。

テストコードがある場合は、対象機能に関するテストがどこにあるかを確認します。テストがない場合でも、既存のテスト構成を見ることで、どの粒度で動作確認すべきかを考えやすくなります。

改修に進んだ後は、Git差分を確認し、意図しないファイルが変更されていないかを見ます。ログや実行結果も確認し、Claude Codeの説明と実際の動作に矛盾がないかをチェックします。

調査結果を改修方針に落とし込む

影響範囲まで確認できたら、調査結果を改修方針に落とし込みます。整理すべきなのは、変更対象、確認のみの対象、実行すべきテスト、重点的に確認する条件分岐、レビュー時の確認ポイントです。

改修方針を整理するためのプロンプト例

ここまでの調査結果をもとに、変更対象、確認のみの対象、実行すべきテスト、レビュー時の確認ポイントを整理してください。

既存コード調査の目的は、コードを読むこと自体ではありません。安全に改修へ進むために、必要な情報を集め、判断できる状態にすることです。

Claude Codeで既存コード調査を行う際の注意点

Claude Codeは既存コード調査に役立ちますが、使い方を誤ると、誤った理解のまま改修に進んでしまう可能性があります。特に、回答の扱い方と機密情報の管理には注意が必要です。

回答をそのまま仕様として扱わない

Claude Codeの説明は、コードを読む入口として役立ちます。しかし、AIの回答には推測が混ざる可能性があります。
したがって、回答をそのまま仕様として扱うのではなく、必ず根拠となるファイル、関数、テスト、実行結果を確認します。

機密情報や権限設定にも注意する

既存コード調査では、認証情報、APIキー、接続情報、個人情報、社内固有の仕様に触れる可能性があります。
Claude Codeを業務で使う場合は、プロジェクトのルール、権限設定、扱ってよい情報の範囲を事前に確認する必要があります。

CLAUDE.mdを使うと、プロジェクト固有のルールや開発方針をClaude Codeに伝えやすくなります。たとえば、「編集前に必ず計画を提示する」「調査結果には根拠ファイルを含める」「テスト実行前に対象範囲を確認する」といった調査・開発の進め方を明文化しておくと、チーム内で使い方をそろえやすくなります。

ただし、CLAUDE.mdは強制的な制御設定ではなく、Claudeに与えるコンテキストです。
機密情報の扱いや本番接続の制限など、確実に守る必要がある内容は、権限設定やhooksなどの仕組みと併用して管理する必要があります。