今回は、Claude Codeを使ってソースコードを解析し、ソースの問題点や改善ポイントを評価してみます。
前回Claude Codeについて記事を書いた後、有償プランに加入したまま十分に活用できていなかったため、せっかくなのでいろいろ試してみることにしました。
生成AIの活用方法としては、コードの自動生成がよく話題になります。
しかし実際の開発現場では、生成結果の信頼性や企業ごとのセキュリティポリシー、運用ルールなどの制約から、積極的な導入が難しいケースも少なくありません。
また、新規開発や大規模な改修の機会はそれほど多くないため、生成AIを活用できる場面は意外と限られます。
そこで今回は、現在稼働しているシステムのソースコードを生成AIで分析し、保守性や設計上の課題を評価するという使い方を試してみました。
Claude Codeとは
Claude Codeは、Anthropicが提供するAIコーディング支援ツールです。
ソースコードの理解や説明、リファクタリングの提案だけでなく、コード生成やテストコードの作成、コマンド実行の支援など、開発作業を幅広くサポートします。
特に大規模なソースコードの解析や構造把握を得意としており、既存システムの理解や保守作業を効率化するツールとして活用できます。
なお、Claude Codeを利用するには、Claudeの対応プランへの加入が必要です。
本記事では、有償プランを利用した環境で動作を確認しています。
注意事項
ソースコードをAIツールで解析する際には、Claude Codeに限らず、利用規約やデータの取り扱い方針を事前に確認することが重要です。
業務で扱うソースコードは、企業や顧客の知的財産であり、その内容によっては機密情報や業務上重要な情報を含んでいる場合もあります。また、契約内容や社内規定によっては、外部サービスへの投入や持ち出しが制限されていることもあります。
そのため、工数削減や品質向上など明確な目的がある場合でも、利用するAIツールの安全性やデータ管理方針を確認したうえで、ソースコードの所有者である企業や顧客に事前相談し、必要な承認を得てから利用するようにしてください。
これらを確認せずに利用した場合、情報管理上の問題や契約違反とみなされ、後々トラブルや法的な問題に発展する可能性があります。
なお、本記事で紹介する手順の利用により生じたいかなる結果についても、当方は一切の責任を負いません。
実施に当たっては、ご自身の判断と責任のもとでご利用ください。
また、今回使用しているClaudeでも、画面下部に「Claude は AI のため、誤りを含む可能性があります。回答内容は必ずご確認ください。」と表示されています。
生成AIは非常に便利なツールですが、出力内容が常に正しいとは限りません。解析結果や提案内容については参考情報として活用し、最終的な判断は人が行うようにしてください。
事前準備
Claude Codeの導入手順やソースコードの読み込み方法については、ブログ記事「【AI】Claude Codeでソースを解析する」に記載していますので、必要に応じてご参照ください。
どう評価するのか？
今回は、現在のソースコードについて、現状の構造や問題点を整理し、理想的な状態との差分を把握することを目的として分析を行います。
評価は以下の流れで進めます。
1. 評価観点を整理する
2. ソースコードを分析する
3. ソースコードを評価する
事前に用意するもの
分析を行う前に、以下の情報を用意します。
- 現行ソース
- 直近で発生した不具合情報
- 開発者・保守担当者などが日頃感じている問題点
- このシステムに求められること
直近で発生した不具合情報
不具合の内容が分かるタイトルレベルの情報を用意します。
今回は約200件の不具合情報を用意してみました。
開発者・保守担当者などが日頃感じている問題点
開発を行う中で、「ここは分かりにくい」「修正しづらい」と感じた点や、日頃から抱えている疑問・課題を整理します。
また、保守担当者など開発者以外の立場から見た不満や改善要望についても洗い出します。
例えば、以下のような内容です。
- 修正影響範囲を把握しにくい
- どこを修正すればよいか分かりにくい
- 同じような処理が複数箇所に存在する
- メソッドが長く理解しづらい
このシステムに求められること
このシステムを提供する企業やプロダクトの観点から、「どのようなシステムであるべきか」を整理します。
例えば、以下のような内容が考えられます。
- 保守性
- 長期保守しやすいこと
- 新規メンバーでも理解しやすいこと
- 安全に改修できること
- 影響範囲を把握しやすいこと
- 安定性
- 障害発生時でも停止しにくいこと
- 一部で異常が発生しても全体停止しないこと
- リソース逼迫時でも劣化運転できること
- 長時間運転で不安定化しないこと
実際にやってみる
評価観点を整理する
まずは、どのような観点でソースコードを評価するべきか整理します。
以下のプロンプトに、事前に用意した情報を追記してClaudeへ入力します。
あなたは熟練のソフトウェアアーキテクトです。
あるJavaコードベースについて、保守性・運用性・障害発生リスク・将来拡張性の観点から課題を分析したいと考えています。
単なる一般論ではなく、実際の運用・保守現場で発生している問題を踏まえ、
「どのような観点でコードベースを評価すべきか」を整理してください。
以下の情報を参考にしてください。
■ 直近で発生した不具合対応
【直近で発生した不具合情報】
■ 開発者・保守担当が日頃感じている問題
【開発者・保守担当などが日頃感じている問題点】
■ このシステムに求められること
【このシステムに求められること】
出力形式は以下としてください。
* 大分類
* 中分類
* 具体的に確認すべきポイント
* なぜその観点が重要なのか
また、以下についても補足してください。
* 発生している不具合と関連が深そうな観点
* 技術的負債になりやすい箇所
* 優先的に確認すべき観点
Claudeにプロンプトを入力すると、評価観点が整理された結果が出力されます。
出力内容は後続の分析で利用するため、コピーボタンなどを利用してテキストエディタへ保存し、必要に応じて編集します。
ソースコードを分析する
次に、整理した評価観点をもとに、Claude Codeでソースコードを分析します。
以下のプロンプトに、「評価観点を整理する」で出力された評価観点を追記してClaude Codeへ入力します。
あなたは熟練のソフトウェアアーキテクトです。
以下のJavaコードベースを徹底的に分析し、
「analysis.md」として保存できるMarkdown形式で出力してください。
# 目的
コードの問題点・構造的課題・技術的負債を可能な限り洗い出すこと。
# 出力形式（重要）
- 出力はMarkdown形式とすること
- この出力をそのまま「analysis.md」として保存できる品質にすること
- 見出し（#, ##, ###）を適切に使用すること
- 箇条書きを活用すること
- 情報の網羅性を最優先とすること（多少冗長でもOK）
---
# 分析ルール
- 出力の整理は不要（網羅性を最優先）
- 重複OK、とにかく多く挙げる
- 抽象論は禁止（必ず具体的に）
- 厳しめに評価する
---
# 分析観点
【「評価観点を整理する」の結果】
---
# 出力構成
# コード分析結果
## 概要
- コードベース全体の特徴（推定可）
- 第一印象（率直に）
---
## 問題点一覧（網羅）
※とにかく多く列挙すること
- 問題1：
- 内容：
- 該当箇所（推定可）：
- 影響：
- 問題2：
- 内容：
- 該当箇所：
- 影響：
---
## 分類別問題
### 分類1
-
### 分類2
-
---
## 構造的な問題（アーキテクチャ）
-
---
## 特に深刻な問題（Top10）
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
---
## 改善アイデア（ラフ・網羅）
※重複OK、とにかく列挙
-
-
-
---
## 将来的リスク
- どのような状況で破綻するか
- どこから崩れるか
---
以上の条件で、analysis.mdとして完成された形式で出力してください。
Claude Codeでソースフォルダを選択し、プロンプトを入力します。
ソースフォルダの選択方法については、ブログ記事「【AI】Claude Codeでソースを解析する」で紹介しています。
実行中にフォルダへの書き込みやコマンド実行の許可を求められる場合があります。内容に問題がなければ「常に許可」または「一度だけ許可」を選択します。
処理が完了すると、指定されたフォルダ配下にanalysis.mdが作成されます。
analysis.mdには、クラス構成の特徴や設計上の問題点、例外処理やログ設計の課題、将来的なリスクなどがMarkdown形式で出力されます。
ソースコードを評価する
最後に、出力されたanalysis.mdをもとに、ソースコード全体を評価します。
以下のプロンプトをClaude Codeへ入力します。
```
analysis.md の内容を入力データとして読み込み、技術的負債アセスメントレポートをMarkdown形式で作成してください。
# 目的
分析結果を整理し、読みやすく・実務で使えるレポートにすること。
# 重要
- Markdown形式で出力すること
- 見出し・表・箇条書きを適切に使う
- 重複は整理する
- 不足している視点があれば補完する
- 抽象論ではなく具体的に書く
---
# 出力構成
# レガシーJavaコード 技術的負債アセスメントレポート
## 概要
- 全体の印象
- 問題の傾向
---
## 総合評価
- 総合スコア（0〜100）
- 技術的負債レベル
### スコア一覧（表形式）
---
## 各評価項目
### 保守性
- スコア
- 総評
- 主な問題点（整理して）
- 改善案
- リスク
### 可読性
（同様）
### 複雑度
（同様）
### 設計の健全性
（同様）
### 技術的負債
（同様）
---
## 持続可能性診断
- 現状維持可能期間の見通し
- 根拠（複数観点）
- 放置した場合のリスクシナリオ
---
## 改善による継続運用可能性
### 優先改善Top5
### 小規模改修ポイント
### 大規模改修領域
### 改善項目一覧（網羅）
- カテゴリ別に整理
- 設計
- コード
- テスト
- 運用
---
# 追加指示
- 分析結果に不足があれば補完すること
- 読み手が「次に何をすべきか分かる」内容にすること
- 専門家として厳しめに評価すること
```
Claude Codeでソースフォルダを選択し、プロンプトを入力します。
こちらも実行中にフォルダへの書き込みやコマンド実行の許可を求められる場合がありますので、内容を確認したうえで問題なければ許可します。
私が試した際には、指定されたフォルダ配下にtechnical_debt_report.mdファイルが作成されました。
レポートには、プロンプトで指定した評価項目に加え、以下のような内容が含まれていました。
- 問題箇所に関する具体的な指摘 (ソースコードの箇所など)
- ソースコードの良い点
- 改修時のおおよその作業工数
- 次回レビューの推奨時期
特に、改善すべき点だけでなく良い点も挙げられていたため、ソースコード全体を俯瞰する資料として活用しやすい印象でした。
まとめ
今回作成したレポートは、単に問題点を列挙するための資料ではありません。
重要なのは、分析結果をもとに現在のソースコードの状態を客観的に把握し、今後の開発や保守計画に活用することです。
どの問題が大きなリスクとなっているのか、どこから改善に着手するべきなのか、どの部分が技術的負債として蓄積しているのか、そして将来的にどのようなリスクが想定されるのかを整理できたことは大きな成果でした。
また、分析結果をレポートとして可視化することで、開発者個人の感覚や経験だけではなく、チーム内で共通認識を持ちながら改善方針を検討しやすくなると感じました。
今後は、この分析結果を実際の開発や保守作業にどのように活用できるのかについても試していきたいと思います。
ライセンスおよび著作権について
本記事では公開されているOSSを解析対象として使用しています。
著作権およびライセンスへの配慮のため、実際のコード・クラス名・ディレクトリ構成など、解析対象のプロジェクトを特定できる情報は掲載していません。
