Zenn
🐩

Claude Codeで回す個人開発 〜ChatGPT・GitHub Copilotを添えて〜

に公開
GitHub Copilot
ChatGPT
Claude Code
idea

Claude Codeにすぐに飛び移ったように、今の生成AIツール選定・運用は一時的な最適化に過ぎず、またkiroのようなノウハウを凝集して使いやすくしたサービスに乗り換えていくのだろうと思う。
kiroだとまだ賢いモデル（AnthropicでいうとOpus4）が使えないのでまだしばらくは今のスタイルが続くかな、と思い今の自分の個人開発スタイルを記事にする。
使用量（プレイ時間）これくらいの習熟度。

使っているサービス

生成AIツールを使ったコーディング

生成AIツールでコードを書かせると初めの0→1だけは感動するくらいうまくいくことがあるが、作業タスクの難易度が上がったり、コードベースが大きくなったりで既存のコードを破壊しないように作業する事がすぐに難しくなってくる。
Claude CodeのBest Practicesにもあるように、すぐにコードを書かせず計画を最初に建てて、納得するまで練ってから実装させるのがよいとされ、Claude CodeにPlanモードが実装されたことで、プロンプトで「まだ書かないで」などと言わずともモードの切り替えで計画フェイズを続けることが出来るようになった。
これによってタスクの精度が少し向上し、任せることが出来るタスクの複雑度も向上した。
しかし、Claude Codeで計画を立ててそのままGoだけではうまくいかないことも多い。

2025/07/17時点の開発スタイル

自分で書くなりChatAIと相談して決めたプロダクトの大枠の実装計画（要件定義）があるとする。
これを使ってそのまま実装に入るとすぐに暴走して破綻するので、以下のステップを回している。

CIを整える

GitHub Actionsでのformat, lint, testなど。
リリースする場合はCDの設定も入れる。
コード品質を保つためにはCIは必ず最初に整えるのがいい（個人開発に限らず業務でもそうだとは思うが）。

実装計画をドキュメント化する

作りたい機能をプロンプトに入れて、Claude CodeのPlanモードを使う。
ここでは計画を立てるのに集中する。別のセッションでコンテキストをリセットしてから作業させるので、全てファイルに出させる。
ここで作ったドキュメントは開発用のClaudeに指示するための一時ドキュメントであり、Git管理し続けるのも違うかなと思っていて、実装が完成したときにこれをPull Request本文に使う（この辺はどうしたもんか試行錯誤中）。

プロンプト（Planモード）

〇〇の機能を実装します。
// 何かしらの公式ドキュメントなど参考ドキュメントがあれば読ませる
// リンクを貼って検索させるよりはMarkdownなどファイルに落として読ませる方がいい
// OSSをgit cloneしてきて特定ファイルを読ませるのも手
参考としてpath_to_document を読んで。
実装計画を立ててドキュメントを作って。
方針に迷う項目は選択肢をすべて挙げて。

実装計画をレビューする

自分が詳しいものは自分でレビューする。
詳しくないものは頑張って知識をいれてレビューする......のは個人開発をサクサクすすめたいモチベーションからするとテンポが悪いので、ChatGPT o3にレビューをさせる。

タスクを細分化する（任意）、実装する

完成した実装計画が明らかに大きなスコープである場合は手動でタスクをピックアップする。
そして実装計画のドキュメント化からやり直す。
タスクのドキュメントを読ませるとClaude CodeがToDo管理を始めるので、ToDoのリストを見て粒度が荒いと思ったらここで止めて、また細分化する。

プロンプト（Planモード）

path_to_document を読んで実装しましょう。

→ToDoリストが作られる
細分化が十分になされたタスクである、もしくは簡単なタスクで自走できると期待できる（この辺は自分で感触をつかむもの）場合はそのままauto-accept edits で最後まで作業させる。
実装計画はこの粒度でいいがチェックポイントは設けたほうがいいと思う場合はgitのcommit単位を意識して作業を区切らせる。
タスクの区切りは基本的にtestを書くところまでとしたい。

プロンプト

タスクnまで実装が終わったら作業を区切りましょう
進めて

ToDoリストで新情報が出ていて、タスクnが終わるころにコンテキストウィンドウがあふれる可能性が場合

タスクnまで実装が終わったら作業を区切りましょう
タスクn+1以降について、実装計画ドキュメントを更新して

その後 auto-accept edits で作業をさせるとタスクnが終わったところで作業を止めてくれる。

作業スコープが大きいと、途中で実装を諦めてTODOを残して完成を主張したり、インターフェース部分は完成しているが中身が無い関数をおくようなこともあるが、タスクの細分化とcommit単位を意識した作業区切りをしておくと、これの発生確率が落とせる。
基本的にはContextの /compact が発生しない範囲でタスクが完了するのが望ましい。
作業区切りをつけて、 Context left until auto-compact: 8% のようにいっぱいになりそうになったら、「今後の作業に必要なコンテキストをドキュメントとしてファイル出力して」のように指示して、 /compact もしくは /clear を手動で実行してから生成したドキュメントを読ませて作業再開させる。

リアルタイムマネジメント

Claude Codeの作業ログを眺めながら少し怪しい挙動があったとき（計画通りではない何かがあり、確認作業を始めたときなど）に、そのログをChatGPT o3にはって方針相談をして、リアルタイムで差し込むというマネジメントをやっている。実装が終わってから直すよりは手直しが減ると思う。

作業をcommitする

必要なドキュメント（今後のプロンプトで使う、ユーザー向け、開発者向け）はcommitするが、先ほどまで使った実装計画は恒久的にメンテナンス・参照したいものでは無いのでcommitに入れない（長期のタスクの場合は一旦git管理することもある）。
formatter, linterが通過する状態にする。
CLAUDE.mdでの指示、もしくはHooksの設定で品質チェックを自動で行うようにしておくのもいい（CLAUDE.mdでの指示はときどき無視される）。
新規および既存のテストが通過することを確認する。
大きな破壊的変更を入れたいのでテストが壊れたまま無視して進んで最後に直すこともあるが、この進め方は難航することがある印象（そもそも破壊的変更を入れる行為自体が設計ミスなので難航するのは順当ではある）。
ここまでを繰り返す。

Pull Request作成、レビュー

2025/07/23 追記
タスクの細分化が上手くいっている（レビュー対象ファイルが絞られている）場合、ChatGPT o3のコードレビューが一番まともに感じる。
Claude Code Actions（Sonnet 4）はlocalでOpus 4と決めた計画と矛盾するレビューをしたり、的外れなパフォーマンス指摘をしてくることが多い。
Copilotも本質的にクリティカルな指摘よりは、軽微なコード品質アップにつながるものか、的外れな指摘が多い。
これはやっているタスクや言語によって得意不得意があるかもしれないので、実際のプロジェクトごとにどんなもんか感覚を掴んで運用するとよさそう。

ここで実装計画を本文に使い、localにある実装計画ドキュメントは削除する。
レビュアーに以下を使う。

  • Claude Code Actions
    CIで自動レビューが走る。全体を見て丁寧なコメントはするが的外れな事も言う（レビューにSonnet4を使うのがデフォルトなので、Opus4にした方がいい気もしているが、このPull Requestレビューはそこそこトークンを消費している体感があるので止めている）。
  • Copilot
    手動で依頼。直さなくてもクリティカルではないことや些細な指摘が多い。
  • ChatGPT o3
    Pull Request差分のファイルをChatGPTのUIにアップロード（10ファイルまでOK）してレビュー依頼。↑の2人のレビューが心もとないときや、念入りに進めたい場合に使う。
    これもあまりに差分（というよりはコード量）が大きいとレビューが大味になると思われるので代表2～3ファイルに絞るか、そもそもタスクが数ファイルの変更で済むように小さくできているとよい。

それぞれで間違った指摘や対応がいらない無駄な最適化を提案してくることがあるので、レビュアー同士のコメントを相互にレビューさせる。
大体はo3にレビューコメントのレビューをさせている。
軽微なものはlocal Claude Code内で妥当な指摘であるなら修正しましょう、として直している。
Pull Request内で @claude と呼べば Claude Code Actions で修正作業をしてくれるらしいが、修正内容の承認ステップ・commit前の目視での差分チェックを踏める、localでの作業の方が好み。
人間でもそうだが、大きなPull Requestを作るとここのレビューコストがとても上がるので、タスクを細分化しておくのがここでも効いてくる。
Claude Code Actionsのレビューはsetup時のデフォルトのワークフローファイルのものからdirect_promptだけ変更して日本語で出力させるようにだけして使っている。
Pull Request作成後、何かしらの修正commitを入れると2回目以降のレビューが走るが、コメントがほぼ同じでノイズになりがちなので、Claude Code Actionsのレビューは一回だけでいいと感じている。
もし大きな変更指摘があった場合はGitHub Issueに切り出して今やらない判断をするか、別ブランチ（別Pull Request）で対応する。

このサイクルの繰り返し。

その他

Claude Codeが苦手な作業

ディレクトリ構成を大きく見直すリファクタリングは不得意で、これは確実に人間がやった方がいいように感じた。
編集前のコードをそのままにcpで配置して後で片付けるみたいな作法で進めがち（これ自体はプロンプトの指示でコントロール出来るかもしれないが）。
また、importパスの変更追従も苦手で、buildエラーメッセージから後手後手で対応する挙動が見られる。IDEのような機能を持っていればスムーズにいくのだろうとは思う。
https://zenn.dev/mizchi/articles/introduce-typescript-mcp
が解決策ではありそうだけど、まだ上手く使いこなせて（Claude Codeに使わせられて）無い。
数ファイル程度ならbuildエラー時（Pythonなどであれば実行時）のエラーメッセージからの対処で何とか解決まで行ってくれるが、5ファイルを超えるなら人の手でやるのがいいかと思っている。

Claude Codeが路頭に迷ったとき

ビルドエラー、リントエラー、テストエラーなどがあったとき、局所的な変更だけを続けてハマり続けることがある。
auto-accept editsのままだとトークンとContextを食い続けて何も改善しないので、escなどで作業を止めて、現状の問題が何かを確認するプロンプトを送る。

現状の課題は何ですか。
確認すべきファイルも全て教えて。

問題が整理されているなら、コンテキストをリセットして再度作業させる。
ChatGPT o3に該当ファイルを渡してみてもらう。
など、ハマり方によって試行錯誤する。
上記プロンプトでファイルをピックアップしてもらうとo3にもレビューを投げやすい。
人間がちゃんと実装を読むのでもいい。
この時タスクが大きいとやっぱりコストが跳ね上がるので、タスクの細分化は全体に効いてくる。

Claude CodeのContext残量の意識

作業完了までにContextのauto compactが発生すると路頭に迷う可能性が跳ね上がる。
30%くらいから意識し始めて、適当な頃合いで作業を止めて、現状の理解・作業記録・次のタスクに向けての計画をドキュメントに吐かせるとよい。
/compactして or /clear してContextが十分な状態で作業を再開させる。
どちらがいいかはノリで決めているが、 /clear するとファイル全量を読み直す（良くも悪くも）、 /compact だとある程度はファイルの情報を覚えていてスムーズに再開する。
いずれにしても一度吐かせたドキュメントは必ず読ませるように指示して作業を再開させる。

GitHub Copilot

VSCode内ではあんまり使わなくなった。
UIのA form label must be associated with an input.biomelint/a11y/noLabelWithoutControl みたいなVSCodeで赤線が出る軽微なlint errorとかを Fix Using Copilot でさっと直させるのに使う。
あとはファイル全部を読ますには大掛かりな微調整をCopilot Chatで済ます。
ちょっとのトークン消費と待機時間を気にしないならClaude Codeでもいいとは思う。
が、Claude Codeは開いたセッションのContextをきれいに保ちたいのでGitHub Copilotで済みそうなものはこっちでやりたい（/clearすればいいという話ではあるが）。

Discussion