はじめに
ワークフローの概要
フェーズ1：ログ分析
フェーズ2：原因特定
フェーズ3：改善案の提案
フェーズ4：実装・レビュー
フェーズ5：改善効果の検証
Claude Code 活用のポイント
同じように試す場合の進め方
まとめ
テコテックの採用活動について

はじめに

システム開発第一事業部の大泉です。普段はエンジニアとして Python でバックエンドの開発を行っています。

この記事では、普段のエンジニアリング業務での Claude Code の活用方法について、実際の調査から効果検証までの流れを例に紹介します。なお、具体的な調査内容や分析結果、コードなどは省略・簡略化しています。

以前、バッチ処理の実行時間が想定より長くなっていることに気づきました。そこでログファイルを Claude Code に渡し、分析、原因の特定、改善案の提示、実装、改善前後の比較まで行いました。

従来であれば、ログの分析にはスプレッドシートで数式や関数を組んだり、分析スクリプトを書いたりする必要があり、それだけで数十分から数時間かかる作業でした。原因を特定するにはコードを一から追う必要があり、修正まで含めると非常に時間のかかる作業でした。

Claude Code を使うことで、これまでログ分析に数時間かかっていた作業を数分で進められるようになりました。加えて、原因の特定から改善案の比較、実装、効果検証までを一連の流れとして進めることができ、各工程の時間を短縮しながら全体をスムーズに進行できるようになりました。

今回ご紹介する例では、Claude Code と人間の役割は次のように分かれます。

作業	担当
ログファイル取得	人間
ログ分析	Claude Code
コードを読んで原因を特定	Claude Code
改善案を複数提示し、トレードオフを整理	Claude Code
どの改善案を採用するか判断	人間
改善案の実装	Claude Code
実装内容のレビュー	人間
改善前後の評価	Claude Code / 人間

人間が主に行ったことは「ログファイルを用意する」「改善案を選ぶ」「実装内容をレビューして取り込むか判断する」の3つです。

以降では、これらの作業を分析、特定、提案、実装・レビュー、検証の5つのフェーズに分けて、Claude Code との作業の流れを紹介します。

ワークフローの概要

5つのフェーズの詳細は以下のとおりです。

ログ分析：ログファイルを渡して、処理時間に影響しそうな異常を検出させる
原因特定：コードを読ませ、異常の原因を特定させる
改善案の提案：原因に対する改善案を複数挙げてもらい、トレードオフを比較させる
実装・レビュー：採用した改善案を実装させ、人間が差分を確認する
改善効果の検証：改善前後のログを渡して、効果を数値で比較させる

以降では、各フェーズでのプロンプトの例と Claude Code の出力例（要約）をご紹介します。

フェーズ1：ログ分析

ログファイルをプロジェクトディレクトリに置き、分析を依頼します。プロンプトは簡潔に伝えます。

プロンプト: バッチログ batch_metrics_before.csv を分析。

Claude Code の出力（要約）：

処理時間に影響していそうな異常値
異常が発生し始めたタイミング
詳しく見るべき指標
次に調査すべき観点

Claude Code からは、どの指標に異常が出ているか、その異常がいつ頃から始まっていたかが返ってきました。ログを渡すだけで異常値や傾向を整理し、確認すべきポイントを短時間で把握できました。

フェーズ2：原因特定

次に、ログで見つかった異常がなぜ発生しているのかをコードレベルで調べます。

プロンプト: 異常の原因分析。

Claude Code の出力（要約）：

問題が起きていそうな処理箇所
ログ上の異常とコード上の処理の関係
想定と異なる挙動になっている理由
確認すべき実装上のポイント

Claude Code は、ログ分析で見つかった異常と関連するコード上の処理を結びつけて説明してくれました。

Claude Code の回答はときにシンプルで、一度の回答だけでは「なぜそのコードではうまくいかないのか」を私が理解しきれないこともありました。

その場合は追加で質問し、自分が納得できるまで理由を確認しました。AI の回答を正しい前提で受け入れてしまうと、実装と仕様の認識が少しずつずれていく可能性があると感じています。

そのため、原因の特定を Claude Code に任せつつも最終的には人間が理解し、妥当性を確認することを重視しました。

フェーズ3：改善案の提案

原因を特定できたので、次は改善案を出してもらいます。

プロンプト: 修正案を提示。

Claude Code の出力（要約）：

案	内容	メリット	注意点
案A	影響範囲を絞って直接修正する	シンプルで実装コストが低い	根本対応として十分か確認が必要
案B	関連する処理にも防御的なチェックを追加する	同種の問題を防ぎやすい	変更箇所が増える
案C	既存データを整理する仕組みを追加する	根本的な整理ができる	実装コストが高い

ここで私が判断したのはどの案を採用するかです。今回は実装コストと効果のバランスを見て案Aと案Bを採用し、案Cは見送ることにしました。

フェーズ4：実装・レビュー

採用する改善案を決めたら Claude Code に実装を依頼します。

プロンプト: 案Aと案Bを採用、案Cはコストに見合わないため見送る。

Claude Code の出力（要約）：

案Aに相当する修正を実装
案Bに相当する防御的なチェックを追加
変更内容の概要と差分を提示

Claude Code に実装まで依頼できるため、原因特定後にそのまま改善案の実装へ進めることができます。調査内容や採用した改善案を踏まえて修正してくれるため、原因分析から実装までの切り替えがスムーズでした。

実装されたコードをそのまま受け入れるのではなく、既存の仕様と矛盾していないか、想定外の箇所に影響が出ていないか、変更範囲が必要最小限になっているかなどを確認しました。

Claude Code によって実装までの速度は上がりますが、最終的にその変更を取り込む判断は人間が行う必要があります。ここを分けて考えることで、作業速度を上げつつ最終判断の責任を人間が持てるようになります。

フェーズ5：改善効果の検証

改善後のバッチを数日動かしてログを取得し、比較を依頼します。

プロンプト: batch_metrics_before.csv（改善前）と batch_metrics_after.csv（改善後）を比較・評価。マークダウンファイルに結果を保存。

Claude Code の出力（要約）：

観点	改善前	改善後
処理件数の偏り	大きい	解消
異常値	発生	正常範囲に回復
処理時間への影響	大きい	改善

一度の指示で改善前後の比較と考察をまとめてくれました。修正して終わりではなく、改善後のログを使って効果を確認し、短時間で整理できました。

「マークダウンファイルに保存」のように出力形式をファイルに指定することで、そのままドキュメントが生成され、報告・共有用にも使えて便利です。

Claude Code 活用のポイント

プロンプトは短くてよい

実際に使ったプロンプトは「バッチログ batch_metrics_before.csv を分析」のような端的なものです。「定量的に」「表形式で」「複数案を」といった言葉を指定しなくても、Claude Code は必要に応じて箇条書きや表形式で構造化された分析結果を返してくれました。

逆に人間側が細かく指定することで、本来、より適切な回答があるのに制限されてしまうことを懸念しました。そのため、プロンプトを端的にすることで Claude Code 側に自由度を持たせる意図があります。

ただし、出力の粒度や観点が明確に決まっている場合は、最初から条件を指定した方がよい場合もあります。または回答を見てから追加の指示を出すようにしています。今回はまず Claude Code に自由に分析させ、必要に応じて追加指示する進め方を取りました。

実装レビューは省略できない

Claude Code が実装したコードのレビューは人間が行う必要があります。実際にレビューしてみて容易ではないと感じました。

Claude Code によって各工程のスピードが上がった分、レビューが相対的にボトルネックになりやすくなります。一方で、システム全体の仕様を把握しているのは人間であり、最終的に成果物の責任を負うのも人間です。現時点では、意図しない影響がないかを確認するレビューは省略できないと感じています。

注意点

Claude Code はログ分析や原因特定、修正作業を高速化してくれます。将来的には人間の確認がボトルネックになる場面も増えるかもしれませんが、少なくとも現時点の私の使い方では、出力結果をそのまま正解として扱うのではなく、人間が妥当性を確認する必要があると感じています。

特に実装を依頼する場合は、次の点を人間が確認する必要があります。

原因分析が実際の仕様と矛盾していないか
変更範囲が必要最小限になっているか
既存機能に影響がないか

実装後はこれらを重点的に確認し、新規テスト・既存テストが通ることを確認しました。

同じように試す場合の進め方

同じような調査を行う場合は、次の順番で進めると取り組みやすいと思います。

処理時間や件数が分かるログを用意する
Claude Code に異常値や傾向を分析してもらう
気になる指標が見つかったら関連するコードを読ませる
原因の特定と改善案を出してもらう
採用する案を人間が判断する
実装してもらい、人間がレビューする
実装後、改善前後のログを比較する

最初から完璧なプロンプトを作る必要はなく、出力を見ながら追加で質問していく進め方で十分でした。

本記事ではログを取得できている前提で進めましたが、必要なログや指標がまだ揃っていない場合は、「どのようなログを出せば調査しやすいか」「どの統計情報を記録すべきか」を Claude Code に相談するところから始めるのもよいと思います。

まとめ

今回のワークフローでは分析、特定、提案、実装・レビュー、検証という5つのフェーズにおいて、Claude Code の活用方法をご紹介しました。

これら5フェーズの多くを Claude Code に任せることで、エンジニアは原因の妥当性確認や改善案の選定、実装レビューといった判断に集中できます。

Claude Code は、ログ分析やログとコードを突き合わせた問題箇所の特定、実装を非常に得意としていると感じました。また、改善案の提案も複数の観点から整理されるため、人間だけで考える場合の抜け漏れを減らせると思います。

実際に使ってみて特に強く感じたのは、調査から修正、検証までの各工程を進めるスピードが大きく上がったことです。Claude Code のような AI を活用したコーディングは、今後の開発現場では前提になっていくと感じました。Claude Code に限らず、今後さらに優れた AI が登場・進化していくことを考えると、AI に任せられる工程はさらに増え、開発のスピードもより向上していくと思います。

一方で、意思決定や判断の多くはまだ人間が担う領域だと感じています。プロジェクトチームや顧客とのコミュニケーション、信頼感や説明責任が伴う場面では、単に正しい・正しそうな答えを出すだけでは不十分です。そのため、Claude Code に作業を任せながらも、最終的な判断やそれに伴う責任は人間が持つことを意識しています。