【個人的】Claude Codeを使う上で心がけていること3選 | cloud.config Tech Blog

はじめに

こんにちは。株式会社FIXER2年目の新屋です。

本記事はFIXER アドベントカレンダー9日目の記事になります。

本記事では、日々私が業務でClaude Codeを使う上で特に実践していることや意識していることを大きく3つにまとめてみました。

是非最後まで読んでいただけると幸いです。

※この記事には、一部生成AIを使用しています。

Claude Codeは、Anthropic社が提供するAIエージェントコーディングツールです。ターミナル上で動作し、ユーザーの指示・承認をもとにコードの生成、編集、実行、Git操作などを行うことができます。

Claude Codeは主に以下のような特徴があります。

Claude Codeを扱う上でよく行うのが、「セッションをこまめに切り替える」です。

これは、各セッションで作業する目的を明確にし、Claude Codeが保持するコンテキストを常にクリーンに保つために行っています。

例えば、作業の際に古いコンテキストが残っていると、次の作業が前の内容に引っ張られて、意図しないバイアスがかかってしまうことがあります。その結果、元々の指示内容にはないような出力が出てきたり、見た目は良いが動作させると全く違う結果になっていたりすることがあります。

また、Claude Codeには、コンテキストの消費量が増えると、システムが自動でコンテキストを圧縮する機能があります。

一見いいように見えますが、現状コンテキストの圧縮が起きた時に、ユーザー側で内容を制御することが難しいため、過去のプロンプトや重要な作業内容が省略され、結果的にLLMの回答精度が落ちてしまう可能性があります。

対処法としては、今説明した「セッションをこまめに切り替える」や後述する「設計・計画のドキュメント化」を行うことにより、自動でコンテキストが圧縮されることを未然に防ぐ運用が挙げられます。

以上のことを防ぐため、1つのタスクを実施して、また次のタスクを依頼する際には、別セッションを立てて作業することを普段から行っています。

ただし、作業させた後、明らかに間違いを見つけた場合にはセッションを切り替えずにそのまま修正の指示を出すこともあるので、ただ闇雲にセッションを変えまくればいいわけではないと思います。

セッションを頻繁に切り替えることの次によくやっているのは、「設計・計画のドキュメント化」です。

Claude Codeに指示を出すとき、コンソール上でそのまま実行することや、ログとして残すだけで終わらせることを避け、Markdownなどのドキュメント形式でファイルに保存するようにしています。

Claude Codeが指示を実行する前に、その実行計画をドキュメント化しておけば、内容を確認して、設計の修正や改善ができるほか、LLMの思考過程を見てプロンプトをどう直すべきかを判断することができます。

また、出力したドキュメントはセッションをリセットしても残るため、新しいセッションを立ち上げた後に、作成済みの作業計画や調査結果を読み込ませるだけで、余計なノイズのない「きれいなコンテキスト」で実装やバグ修正を始められます。

特に後者の作業はよくやっていて、以下の画像のように、Claude Codeに前もって実装用の作業計画を作成した後、別のセッションでレビューを行い、精緻化した作業計画を、さらに別のセッションを複数使って実装、という流れで作業することが多いです。

Claude Codeなどに作業を任せている間の待ち時間を有効活用するために、Git worktreeを使っています。

Git worktreeは、同じリポジトリ内に複数の作業ディレクトリを作れる機能で、以下のようなメリットがあります。

ブランチ切り替えが楽になる: worktree作成後、ディレクトリを移動するだけで違うブランチの作業ができるので、ブランチの切り替えをgit switch コマンドを打たずとも、楽にブランチの切り替えを行うことができます。
完全に並列化できる: worktreeを作るときに新しいブランチも同時に作れます。そのため、一方のworktreeでClaude Codeにコーディングさせながら、もう1つworktreeを作成してメンバーのコードレビューを行ったり、別のタスクを並行して進めたりできます。

以下の画像は、実際ターミナル上でworktreeを用いてbranch作成をしているものです。

worktreeを作ってしまえば、後はディレクトリに移動するだけでそのブランチで作業することができます。