はじめに

普段VS Code上でClaudeを使って開発しています。
いろいろ試した結果、今は 「方針を整理するセッション」と「実装するセッション」を完全に分ける 運用に落ち着きました。
この記事では、その運用と分けている理由を紹介します。

運用の全体像

ポイントは、方針を考えたチャットでそのまま「じゃあ実装して」と言わないことです。
そもそも私は、Claudeにいきなり実装させることはしていません。
必ず方針を出してもらい、自分が理解できてから実装に進むようにしています。

やり取りが長くなると、直前の内容はしっかり反映されるのに、序盤に伝えた前提や決めたことが抜け落ちてしまうことがありました。

方針整理で長く話したあとに同じセッションで実装まで進めると、肝心の「最初に決めた前提」が守られないリスクがあります。

そこで、実装は新しいセッションで始め、確定した方針を最初に読み込んでもらうようにしています。
こうすると、守ってほしい内容が常に「直前の情報」として扱われるので、抜け漏れが起きにくくなりました。

方針を考える段階では、いくつかの案を出したり、途中で考えを変えたりします。
同じセッションで実装まで進めると、そうした採用しなかった案や途中の議論も前提として残ったままになります。

新しいセッションでは「確定した方針」だけを渡すので、前提がすっきりします。

別セッションに渡す以上、方針を文章として整理しなければなりません。
この作業自体が、自分の理解度のチェックになっています。
うまく書けないときは、まだ理解しきれていないサインです。

実装セッションで期待と違う結果になっても、方針は課題に残っているので、新しいセッションを開いて同じ方針から再スタートできます。
長いチャットの途中で軌道修正するより、気楽で確実です。

チャットは流れてしまいますが、Backlogの課題に残しておけば後から経緯を追えますし、チームにも共有できます。

実装セッションで読み込んでもらうことを前提に、課題のコメントに次のような項目を書いています。

BacklogをMCPでVS Code上のClaudeとつないでいるので、方針をコピペして渡す必要はありません。
実装セッションでは、課題キーを伝えて課題内容と方針のコメントを確認してもらいます。

Backlog MCPの導入は、こちらの記事を参考にしています。

方針を書いてから実装に入るまでの間に、他の課題の対応などでコードが変わっていることがあります。
そのため、いきなり実装には入らず、まず次の確認をしてもらいます。

差分があれば実装前に報告してもらい、必要に応じて方針を見直してから進めます。

依頼は2段階に分けています。

1回目：差分の確認

Backlogの課題【課題キー】の内容と、方針を記載したコメントを確認してください。
そのうえで、現状のコードと方針に差分や矛盾がないかを確認し、結果を報告してください。

2回目：報告内容を確認してから実装を指示
報告された内容を自分で確認し、問題がなければ改めて実装を依頼します。
差分や矛盾が見つかった場合は、方針を見直してから進めます。

方針に沿って実装してください。方針にない変更はしないでください。

AIとの開発では「何を渡すか」で結果が大きく変わります。
セッションを分けるのは、その「渡すもの」を自分でコントロールするための工夫です。
同じようにClaudeで開発している方の参考になれば嬉しいです。

🔥 成長と挑戦を楽しむ仲間を募集中！

スピードリンクジャパンでは、一緒に技術を楽しめる仲間を探しています！

会社の雰囲気や働く環境などをまとめていますので、ご興味のある方はぜひサイトに遊びに来てください！

👉 リクルートサイトを見る