1人でWeb制作会社をやっています。この夏、社内の顧客管理システム(Laravel 12、約3,500行)と、顧客に納品する店舗サイトの雛形(ブログ・予約・会員・LINE連携)を、Claude Codeにほぼ全部書いてもらいました。
一番効いたのは、モデルの性能でも、プロンプトの言い回しでもなく、「何を確認して、何を確認しないか」を最初に決めたことでした。この記事はその話だけを書きます。
最初は1.3倍にしかならなかった
使い始めの頃は「詰まったら聞く」使い方でした。エラーを貼って直し方を聞く、Bladeの書き方を聞く。便利でしたが、開発速度は1.3倍程度。
理由は、判断を全部自分がしていたからです。次に何を作るか決めるのも、どのファイルを開くか決めるのも、動作確認するのも、コミットするのも自分。Claude Codeがコードを書いている時間より、私が「次に何を頼むか」を考えている時間の方が長い。
権限の線引きを決めた
そこで、Claude Codeに次の表をそのまま伝えました。
| 区分 | 扱い |
|---|---|
| Phase設計(どの機能を、どの順で作るか) | 必ず人間が確認してから実装 |
| ファイル編集・マイグレーション・シーダー実行 | 確認なしで進める |
| git add / commit / push | 確認なしで進める |
| 外部の実サービス(Instagram等)への実アクセス | 実行前に目的を一言チャットで説明 |
| PC設定変更、メール送受信、金銭が絡む操作 | 対象外(人間がやる) |
これがないと、Claude Codeは「このファイルを編集していいですか」を数分おきに聞いてきます。逆にこの表を渡した後は、1回の指示で30分〜1時間、黙々と実装→テスト→コミットまで進みます。
「外部サービスへの実アクセスは一言説明してから」を入れたのは、Instagram Graph APIの動作確認中に、Claude Codeがcurlで本物の認可URLを叩こうとしたのが見えたからです。確認行為としては正しいのですが、何をしようとしているかが見えないまま外部に通信されるのは怖い。禁止ではなく「一言説明」にしたのは、確認のたびに止まると自動化の意味がなくなるためです。
確認は「1時間に1回まとめて」
もう1つ決めたのが報告頻度です。最初は機能を1つ作るたびに「動作確認してください」と止まっていました。これでは張り付いていなければなりません。
要点整理→実装→動作確認→コミット、を1サイクルとして、私への確認は1時間に1回程度にまとめてください。
動作確認はphp artisan testやcurlでClaude Code自身が行い、私は結果の要約だけを見ます。そのために整えたのは3つだけです。
- モジュールごとに
tests/Featureを置き、--filterで回せる状態 -
migrate:fresh --seedで管理者・料金プラン・メールテンプレートが入る状態 -
php artisan serveを立てておき、curlでステータスコードを見られる状態
この3つがあると、Claude Codeは実装のあとに自分でテストを書き、失敗したら直し、通ってからコミットします。私に来る報告は「Reservationモジュールを追加、テスト7件通過、コミット済み」の1行です。
「更新したファイルを毎回明記」
地味に効いたルールがもう1つあります。
ファイルを変更したら、毎回どのファイルを更新したかを報告に含めてください。変更がなければ「変更なし」と書いてください。
報告を読むだけで「触ってほしくないファイルに手が入っていないか」を10秒で確認できます。差分を全部読む必要がなくなりました。
結果
この運用にしてから、私が開発に使う時間は1日あたり15〜30分です。朝に指示を出し、昼に結果を見て次を指示し、夕方にコミットログを眺める。
規模感はこうです。
| 項目 | 社内CMS |
|---|---|
| フレームワーク | Laravel 12 / PHP 8.3 |
| PHPファイル数 | 74 |
| 行数 | 約3,500 |
| 主要機能 | 顧客/契約/プラン管理、Stripe Checkout・Webhook、Instagram OAuth・投稿・予約投稿、顧客サイト向けAPI |
| 期間 | 約6週間、本業の合間 |
書いたコードのほぼ全てはClaude Codeが生成し、私は「何を作るか」「どこで判断を分けるか」「動いたか」だけを見ました。
権限だけでは足りない、もう1つのこと
権限の線引きと同じくらい効いたのが、設計合意をREADMEに書かせることです。Claude Codeはセッションをまたぐと文脈を忘れますが、READMEは忘れません。「予約確定メールはプレーンテキスト。理由: 店側が自由に文面を編集したいため」のように、理由つきで残しておくと、別のセッションで「HTMLメールにして」と頼んだときに「READMEにプレーンテキストの方針と理由があります。変更しますか」と確認してきます。
過去の自分との合意を、AIが守ってくれる状態です。
もっと詳しく
Stripe Cashierで課金主体をUserからCustomerに変えた話、Instagram連携を「スタッフ代行」と「オーナー本人」の2経路で同居させた設計、LINE予約通知のためにメールアドレスとline_user_idを紐づけた方法、さくらのレンタルサーバーでスケジューラを回す制約など、実装の中身はZennの本にまとめました。
「はじめに」と第1章は無料で読めます。
本で解説している店舗サイトの雛形(予約・会員・LINE連携つき、Laravel 12)は、こちらで配布しています。
この記事はZennにも投稿しています。