Zenn
🔎

ClaudeのMaxプランによって変わった個人開発のスタイル

に公開
AI
個人開発
LLM
Claude
Claude Code
idea

はじめに

Claude Code Maxプランが5月2日に発表されてすぐに飛びつき、100$のプランをサブスクして使うようになりました。
以前からClineやGitHub CopilotなどLLMのサポートを受けた開発を試してきましたが、定額かつ高性能なOpusとSonnet4によって開発に対する価値観とスタイルが大きく変えられてしまいました。
Claude CodeのTipsとかはよく技術記事やXで見かけますが、個人プロジェクトにおいてガッツリ利用されている記事は少ないかと思い書き始めてみようと思います。

開発環境

Claudeとは関係ないですが、1月に転職し開発マシンをWindowsからMacbookに変えました。それ以降作業する時にはMacを使用するようになり、Windowsのデスクトップは置物となりました。Claude Codeが定額利用できるようになって以降、2つの使い道ができたため後述します。

Ghosttyをターミナルエミュレータとして使用し、Fishシェルを利用します。
シンタックスハイライトやコマンド履歴からの補完が効く点が効率的で気に入っています。

利用する技術は、Typescript, Hono, React Router, Nextjs, Drizzle, Cloudflareがほとんどです。

Claude Codeを使用する時に効率がいいからという理由で基本的にはモノレポ構成を取ります。
機能別にプロジェクトルートのディレクトリを切っていて、api, mcp, ui ... みたいに分けています。（個人レベルでこれを超える規模のサービスを作ったことがまだなく、この分け方で課題を感じていません）

前提

  • 個人でやっているプロジェクトはWebアプリケーションとして動くものが中心で外部公開せず、自分や知り合いの中だけで使うようなツールが大半です。
  • 6つのプロジェクトを並行して開発・運用しています
  • どれも規模の小さいプロジェクトのため、コードベースが小さいからこそできているような取り組みがあると思います。
  • 個人開発はかなり適当にやっていますが、本業ではもっと真面目に活動しています。
  • ClaudeのMaxプランの100$の方を利用しています。本当は200$のプランでOpusをガンガン使いたいですが、収益を目指していないプロジェクトが多い現状では手が出せませんでした。(100$も個人的には結構負担でかい)
  • 個人用のツールの開発ではセキュリティのことを一切意識していません。

本題：開発スタイルで変わったこと

ClaudeのLimitへの対策のためにいつでも、どこからでもコーディングをできるようにした

5時間おきのLimitをしっかり使い込むためにスマホ・ミニPC（Windows）・IpadにTailscaleを入れてどこからでもSSHできるようにしました。
ミニPCを常時起動させておき、Claude CodeやNodejs等のセットアップを済ませてあります。開発中のプロジェクトをミニPCのWSL内でにCloneしておきいつでもコーディングできるようにしています。
これにより、電車での移動中でもプロジェクトを進められるようになりました。
MacBookを使うことになって置物と化していたミニPCの用途の1つとなっています。

個人のプロジェクトでもIssueを細かく切って進めるようになった

Claude Codeで作業をさせるために毎回細かくプロンプトを書くのが苦痛だったこととGitHub CLI(gh)とClaude Codeの相性が良いと感じているため、Issueを細かく切って渡すようになりました。
Issueの番号だけを受け取って決められた手順で調査・修正を行うように指示したClaudeのカスタムコマンドを作って、タスクの初回は必ずそれを利用するように決めています。
Issueの作成自体も初回の企画的な内容のみ自分で考えて、Claudeに分割した案を出してもらったのちghコマンドを利用してIssueを起票させることで省エネでやらせることができています。

定型的な指示をカスタムコマンドにするようになった

例えば、CIが失敗した時の修正の指示やPRのマージした後にmainブランチに戻ってPullさせたりといった作業を個別でカスタムコマンドにしています。
これを行うことによって毎回指示を入力する必要がなくなり、/を入力したらコマンドが補完されるので楽に開発ができます。
特に、スマホのターミナルからSSHしてミニPC上でClaudeに指示を出す時に楽になります。（スマホのターミナルは入力しにくいため）

CIが失敗した時の修正を指示する例：

GitHub ActionsのCIを確認します。

以下STEPに従ってください。

1. ghコマンドを利用して現在のブランチに紐づいているPRのCIを確認します。
2. コマンドが実行中の場合には`sleep 60`で1分間待機してください。
3. CIが成功している場合には特にやることがありません
4. CIが失敗している場合は失敗した内容を確認します
5. ローカル環境で失敗原因を再現し、ソースコードの問題を特定します。
6. 修正をプランし、更新後Pushします。

作業ブランチをマージ後mainに戻ってPullする例：

IssueとIssueの対応間に実行するコマンドです。

以下のステップに従います。

1. git statusを実行し更新漏れがないことを確認します。
2. git switch mainを実行しmainブランチに移動します
3. git pullを実行しmainブランチを更新します
4. 更新内容や現状を簡単に報告します。

音声入力を使うようになった

定型以外の細かい修正を行う時の指示やIssueの起票時など、タイピングによる入力が多くなって非常に疲れるのでSuperwisperを入れる用になりました。精度が甘い時や「ご視聴ありがとうございました。」みたいな喋っていない文章が紛れることもありますが、それを加味しても作業効率が上がったと感じています。
より肌感に合うツールを求めてまだ試せていない他の音声入力のツールも試していくことになると思います。Aqua Voiceとかが気になっています。

完全に個人用途な小さいアプリに対してもテストやLintを必ず書くようになった

Claude Codeで生成したコードをマージする基準としてテストやLintを利用しています。
単体テストを書くコストもあまり感じないですし、可能な限り高いカバレッジを出すようにCLAUDE.mdでルールを書いていたり、実装時にもフィードバックを入れています。
カバレッジを毎回PRのコメントに書き出すように単体テストのCIのステップに入れるようにし、分かりやすくしています。
機能が出来上がってきたら統合テストやE2Eテストを書くようにし、自分が目視や手作業で確認する工数を極力減らすように意識するようになりました。

同時に複数のプロジェクトを進めるようになった

少しでも欲しいとか作って見たくなったものはすぐにリポジトリを作成してIssueを書き散らしています。
Claude Codeを利用して1つのアプリを複数並列で開発するのももちろんいいですが、コンフリクトした時の解消が面倒で余計に時間を消費している感覚になります。
そのため1つのアプリは最大でも3つ程度の並列にとどめ、横で別のプロジェクトを並列させるのがストレスなく進められるように感じています。

GitHub セルフホストランナーを立てるようになった

商用ですらない個人用のツールのCIにはセルフホストランナーを立ててGitHub Actionsの無料枠を消費しないようにしています。
ミニPCのWSL内でsystemctlのサービスとして1つのプロジェクトに対して2つセルフホストランナーが待機するように設定しました。
Claude Codeを並列で利用していると体量のPRが上がって毎月2000分の無料枠程度では足りるわけがありません。
ミニPCのスペックがかつかつで大量のランナーを用意できないため、通常分割した方がいいジョブもまとめて実行するようにしたり、キャッシュを利用しないようにしたりなど、ベストプラクティスから外れていそうな運用になってしまっていますが、これでなんとか無料枠に収まるようになりました。
E2Eテストはスペックが足りずうまく動かないことが多く不安定だったため、全てGithubがホストする通常のランナーを利用するようにし、枠を使いすぎないように重要な正常系のテストのみに限定して実装するようにしています。（なるべく単体テストのカバレッジや統合テストでカバーする方針）

Issueを消化して開発させている間は基本的に動作確認などをせず、後からまとめてやるようになった

複数アプリを並列して進めているため、動作確認が困難なため、諦めました。
というより都度確認していると効率が悪いため、最低限の基準としてテストのカバレッジやLint、型チェックに任せて信じてマージし、まとめて動作確認して都度Issueにバグや意図と違う部分を書いていくようにしました。
とにかくスピードと効率だけを求めるようになっています。
ある程度カバレッジが取れたり、E2Eまで実装ができてくる段階まで進めば手戻りの量も減っていく感覚があります。

レビューをGitHub Copilotに依頼するようし、コードを読まなくなった

並列で作業しているため、レビューしている余裕も無くなり、GitHub Copilotにレビューを依頼し出しました。
これによって自分はIssueを書くか、カスタムコマンドを利用して指示するくらいしかやる余裕がなくなり、結果コードを読まなくなりました。
自分が考えて自分で作って運用しているはずのプロジェクトなのに中身がどうなっているのかよくわかっていない状態になることが多くなっています。

Claude.mdを育てるようになった

以下を全体に適用されるルートに書いてどのプロジェクトでも共通して利用されるようにしています。
各プロジェクトで必要だと思ったルールをエスカレーションする形でつぎたしています。

# 共通ルール

## 重要

- タスクが完了したら、`afplay /System/Library/Sounds/Hero.aiff`を実行して通知音を鳴らしてください。

## Core Development Rules

1. コード品質
   - すべてのコードに型定義を必須とする
   - 関数は集中して小さく保つこと
   - 既存のパターンを正確に踏襲すること
   - 行の最大長は100文字まで

2. テスト要件
   - 単体テストを網羅的に実装する。
   - DBや外部サービスのI/Oを検証するために統合テストを最低限で実装する
   - E2Eテストは正常系の最小限のテストを実装する
   - 新機能には必ずテストを追加すること
   - バグ修正にはユニットテストを追加すること

3. GitHubの利用ルール
    - commitメッセージには,chore, fix, feat, docsのいずれかのプレフィックスを利用する。
    - commitメッセージは日本語で何をなぜ変更したのか記載する
    - 非常に小さい粒度で定期的にコミットする
    - Lint, test, typecheckをCIで基本的に確認するためPushする前にローカルで成功することを確認する
    - CIにエラーがある限りPRがマージされることはない
    - ブランチはfeat, fix, docs, chore等のブランチから始まり、issue番号を明記する。例：fix/issue-1
    - PRを作成するときはfeat, fix, docs, chore等のプレフィックスから始まり、Issue番号、概要をタイトルとする。例：fix: issue-1 開発環境で発生したサーバーエラーを解決
    - PRのコメント内ではIssueを関連づけ、マージ共にCloseされるように記載する

最後に

Claude Codeが定額で利用できるおかげで個人開発のスタイルがガラッと代わりました。
コーディングがほぼ完全にLLMに代替され、目視・手動での動作確認は自動テストに置き換わり、私の役割は機能の企画と要件定義と調査、一部の設計、手動でのシナリオテスト程度になりました。
今はまだこの開発スタイルで個人開発を楽しめていますが、よりLLMの精度や速度が改善され、できることが広がっていく将来もこれが楽しめるかは疑問に思います。

また、記事として書いていて思いましたが、かなり極端な開発スタイルになってきているように感じます。
読んでいただいた方の参考になるかは怪しいですね...

Discussion