はじめに
普段VS Code上でClaudeを使って開発しています。
いろいろ試した結果、今は 「方針を整理するセッション」と「実装するセッション」を完全に分ける 運用に落ち着きました。
この記事では、その運用と分けている理由を紹介します。
運用の全体像
- 方針整理セッションで、課題の内容を伝えて実装方針を一緒に考える
- 自分が理解・納得できるまで質問する
- 確定した方針を Backlogの課題にコメントとして記録 する
- 新しいセッションを開き、MCP経由でBacklogの課題と方針を読み込んでもらう
- 現状のコードと方針に差分がないか確認してもらってから、実装に入る
ポイントは、方針を考えたチャットでそのまま「じゃあ実装して」と言わないことです。
そもそも私は、Claudeにいきなり実装させることはしていません。
必ず方針を出してもらい、自分が理解できてから実装に進むようにしています。
なぜセッションを分けるのか
1. 長いセッションでは、前半の内容が抜けてしまうことがあるため
やり取りが長くなると、直前の内容はしっかり反映されるのに、序盤に伝えた前提や決めたことが抜け落ちてしまうことがありました。
方針整理で長く話したあとに同じセッションで実装まで進めると、肝心の「最初に決めた前提」が守られないリスクがあります。
そこで、実装は新しいセッションで始め、確定した方針を最初に読み込んでもらうようにしています。
こうすると、守ってほしい内容が常に「直前の情報」として扱われるので、抜け漏れが起きにくくなりました。
2. 検討中の「ボツ案」を実装に持ち込まないため
方針を考える段階では、いくつかの案を出したり、途中で考えを変えたりします。
同じセッションで実装まで進めると、そうした採用しなかった案や途中の議論も前提として残ったままになります。
新しいセッションでは「確定した方針」だけを渡すので、前提がすっきりします。
3. 方針を「人に渡せる形」にまとめる必要が生まれる
別セッションに渡す以上、方針を文章として整理しなければなりません。
この作業自体が、自分の理解度のチェックになっています。
うまく書けないときは、まだ理解しきれていないサインです。
4. 実装がうまくいかなくても、方針から何度でもやり直せる
実装セッションで期待と違う結果になっても、方針は課題に残っているので、新しいセッションを開いて同じ方針から再スタートできます。
長いチャットの途中で軌道修正するより、気楽で確実です。
5. 方針が記録として残る
チャットは流れてしまいますが、Backlogの課題に残しておけば後から経緯を追えますし、チームにも共有できます。
方針として記録している内容
実装セッションで読み込んでもらうことを前提に、課題のコメントに次のような項目を書いています。
- 課題の目的
- 採用した方針（と、採用しなかった案があればその理由）
- 変更対象のファイル・範囲
- 注意点（変更してはいけない箇所、既存の呼び出し側への影響など）
実装セッションでの進め方
BacklogをMCPでつないで、課題と方針を直接読み込んでもらう
BacklogをMCPでVS Code上のClaudeとつないでいるので、方針をコピペして渡す必要はありません。
実装セッションでは、課題キーを伝えて課題内容と方針のコメントを確認してもらいます。
Backlog MCPの導入は、こちらの記事を参考にしています。
実装前に「現状のコード」と「方針」の差分を確認してもらう
方針を書いてから実装に入るまでの間に、他の課題の対応などでコードが変わっていることがあります。
そのため、いきなり実装には入らず、まず次の確認をしてもらいます。
- 方針に書かれている前提が、現状のコードでも成り立っているか
- 変更対象のファイルや関数が、方針を書いた時点から変わっていないか
差分があれば実装前に報告してもらい、必要に応じて方針を見直してから進めます。
実際の依頼文
依頼は2段階に分けています。
1回目：差分の確認
Backlogの課題【課題キー】の内容と、方針を記載したコメントを確認してください。
そのうえで、現状のコードと方針に差分や矛盾がないかを確認し、結果を報告してください。
2回目：報告内容を確認してから実装を指示
報告された内容を自分で確認し、問題がなければ改めて実装を依頼します。
差分や矛盾が見つかった場合は、方針を見直してから進めます。
方針に沿って実装してください。方針にない変更はしないでください。
その他、実装セッションで意識していること
- 課題単位で小さく頼む：Backlogの課題ごとにセッションを分けるので、自然と1回の依頼が小さくなります
- 差分は必ず自分で読む：方針を理解しているので、意図と違う変更があればすぐに気づけます
- エラーは全文貼る：「エラーが出た」ではなく、メッセージをそのまま渡したほうが原因特定が早いです
この運用で感じている効果
-
前提の抜け漏れによる手戻りが減った
実装セッションの最初に方針を読み込ませるので、決めたことが守られやすくなりました。 -
方針を書いた後のコード変更に、実装前に気づけるようになった
他の課題の対応で変わった箇所を、実装を始める前に把握できるようになりました。
まとめ
- 方針整理と実装はセッションを分ける
- 長いセッションでは前半の内容が抜けることがあるので、実装は新しいセッションで始める
- 方針はBacklogの課題に記録し、MCP経由で実装セッションに読み込んでもらう
- 実装前に、現状のコードと方針に差分がないかを確認してもらう
AIとの開発では「何を渡すか」で結果が大きく変わります。
セッションを分けるのは、その「渡すもの」を自分でコントロールするための工夫です。
同じようにClaudeで開発している方の参考になれば嬉しいです。
🔥 成長と挑戦を楽しむ仲間を募集中！
スピードリンクジャパンでは、一緒に技術を楽しめる仲間を探しています！
会社の雰囲気や働く環境などをまとめていますので、ご興味のある方はぜひサイトに遊びに来てください！