3ヶ月前、私はバックエンドデベロッパーをもう一人雇おうとしていました。バックログが酷かった――クライアントに約束した機能が14個、2人で手一杯、私自身が営業電話とプルリクエストの間を行ったり来たり、完全なアホみたいでした。その後、Claude Code を本当に正しく使い始めました。チャットウィンドウに関数を貼り付けるだけじゃなく、本当の日々のフローに統合したんです。6週間でそのバックログを片付けました。二番目のデベロッパーは雇いませんでした。using Claude Code properly. Not just pasting functions into a chat window. I mean integrating it into the real daily flow. We cleared that backlog in six weeks. I didn't hire the second developer.
これはピッチじゃないです。起こったことです。
「正しく」というのは実際には何か
ミートアップで話す人の多くは、AI コーディングツールを同じ怠けた方法で使っています。関数を貼り付けて、何か返されて、エディタに貼り付けて、壊れて、諦める。これはワークフローじゃない。これは絶望です。
「正しく」というのは私にとって、Claude Code が Claude Code CLI 経由でターミナルに内在して、実際のレポジトリに直接作用し、実際のファイルを読む、消毒されたスニペットではなく、という意味です。その違いは莫大です。昨年米国のヘルスケアクライアント向けに作った4,000行の WordPress プラグイン全体の文脈を持てば、アウトプットは使える。40行の貼り付けを盲目的にやってれば、当てずっぽうです。Claude Code CLI, working directly on my actual repo, reading real files, not sanitised snippets. The difference is enormous. When it has full context of a 4,000-line WordPress plugin we built for a US healthcare client last year, the output is usable. When it's working blind off a 40-line paste, it's guessing.
MacBook Pro M3 で実行しています。エディタは相変わらず VS Code に Prettier、ESLint、GitLens といった常連たちです。Claude Code はそのどれも置き換えません。横に座っています。alongside it.
実際に使ってるセットアップ
- Claude Code CLIをnpm経由でグローバルインストール
- 各プロジェクトルートの .claude ディレクトリ、CLAUDE.md ファイル――これは基本的に Claude 向けに書くブリーフです。スタック、規約、触るなという部分とか。
.claudedirectory in each project root with aCLAUDE.mdfile -- this is basically a brief I write for Claude about the project: stack, conventions, what not to touch - iTerm2の分割ペイン。左にコード、右にClaudeセッション
- Claude生成の変更があるたびにGitコミット、例外なし。何度も痛い目に遭ってます
その最後の点。2022年、クライアントプロジェクト――マンチェスター拠点の家具小売業者の Shopify マイグレーション――私は AI 支援の編集を3時間分コミットしないで積み重ねました。セッション全体が破損しました。6時間の仕事が消えました。今は強迫的に、ほぼ神経症的にコミットします。Claude Code だろうとなかろうと。
朝のルーチン（敢えてつまらないほど具体的です）
8時半には会社にいます。Exmouth Marketのコーヒーショップでコーヒーを買う。Notionを開いて、その日のボードを確認してから、ターミナルを開く。
毎朝Claude Codeで最初にやることは、私が「コンテキストダンプ」と呼び始めたもの。プロジェクトを開いて、claudeを実行して、前日どこまでやったかについて1段落説明する。最近のgit diffを自動的に読む。これに約3分かかるが、自分のコードを20分も再読して何をしていたか思い出すことがない。それだけで十分に価値がある。claude and give it a paragraph of where I left off the previous day. It reads the recent git diff automatically. This takes about three minutes and means I'm not spending twenty minutes re-reading my own code to remember what I was doing. That alone is worth the subscription.
それから作業します。Claude に機能をゼロから書かせることは要求していません――時々はやりますが。たいていは、遅くさせるけどゼロの創造性も要求しないものをやらせています。
例えば：
- すでに書いた関数のPHPUnitテストケースを書く
- 貼り付けたJSON レスポンスからTypeScript インターフェースを生成する
- 分割する必要があるとわかっているけど、考えたくない300行のコンポーネントをリファクタリング。know needs splitting but don't want to think about
- 内部APIの初版ドキュメンテーション
これらのどれも面白くない。全部で私が持っていない1時間を食っていた。
実際に時間が節約できる場所（数字付き）
Seahawk はこれまでに 12,000 以上のサイトを構築しました。大きな塊は WordPress です――テーマ、プラグイン、WooCommerce カスタマイズ。WordPress 開発に単調だが技術的に正確なタスクのカテゴリーがあります。カスタムフック書き、REST API エンドポイント登録、Settings API を使った設定ページビルディング。
先月計時しました。WooCommerce カスタム配送方法クラスをゼロから書く――歴史的には約45分かかります、テスト含めて。Claude Code にスキャフォルドをやらせて、ビジネスロジックを平文で説明する間に――12分。スキャフォルドは良いです――CLAUDE.md で言ったから WordPress コーディング標準に従っています。good -- it follows WordPress coding standards because I told it to in my CLAUDE.md.
これは10%改善ではない。別次元の速度だ。
より大きな効果は、コンテキストスイッチングのコストの削減だ。機能実装の途中でクライアントから全く別のプロジェクトのバグについてメッセージが来た時、以前は無視するか（よくない）、頭がごっちゃになるか（これもよくない）のどちらかだった。今はClaudeに現在のタスクがどこまで進んでいるかを詳細にまとめたコメントブロックを書かせて、バグ修正に切り替えて、直して、戻ってきてコメントを読んで、約4分で戻ってこられる。以前は、その復帰に20分かかっていた。
限界が露出する場面
正直に言おう。この部分が勝利以上に重要だ。
Claude Code は、歴史的な背景を理由に、ある決定がなされた理由を理解する必要があるもの――何でも本当に苦手です。Seahawk では fintech プロジェクトがありました。ロンドンを拠点とする決済スタートアップ向けのダッシュボードです。特に厄介な状態管理が存在していて、それは私たちが関わる前から存在していた理由がありました。レガシー API がレスポンスをバッチ処理する方法での微妙なエッジケースです。Claude は何度も「修正」しようとしていました。提案はどれも技術的にはきれいでしたが、完全に間違っていました。知らないことを知らなかったのです。why a decision was made historically. We had a fintech project at Seahawk -- a dashboard for a London-based payments startup -- where a particularly gnarly bit of state management existed for a reason that predated our involvement. Some edge case in how their legacy API batched responses. Claude kept "fixing" it. Every suggestion was technically cleaner and completely wrong. It didn't know what it didn't know.
これは誰も十分に話さない障害モード。出力は正しく見える。基本的なレビューに合格する。そして本番環境で木曜日の夜に、ユーザーがその端的なケースに当たるとき、壊れる。looks correct. It passes basic review. And then it breaks in production on a Thursday evening when a user hits that edge case.
今の私のルール：Claude Codeは「Raviに聞かずに変更しないこと」というコメントがある部分には触れない。（Raviは我々のシニアバックエンド開発者だ。）完全にこれに従う。
他にも苦手な場面がある：
- 依存関係が3段階以上のマルチファイルリファクタリング
- 2年未満の比較的新しいサードパーティ SDK を使う何かに関しては――メソッド名を自信を持って幻想します
- デザイナーのピクセルパーフェクトなコンプに合わせる必要があるCSS（ほぼ合致するが、細かいエラーで頭を抱える）
- ボトルネックが明白でないパフォーマンス最適化――間違ったものを最適化します
2番目のポイント特に。私は1月にResendのAPIをNext.jsプロジェクトに統合していた。Claudeはa.send() メソッドを参照し続けてたが、Resend Node SDKに存在しない。Claudeの確信に満ちた間違いをデバッグするのに、単にドキュメントを自分で読むより長くかかった。教訓を得た。あらゆるSDKについて、実際のREADMEをコンテキストウィンドウに先に貼り付ける。Next.js project in January. Claude kept referencing a.send()method that doesn't exist in the Resend Node SDK. Took me longer to debug Claude's confident wrongness than it would've taken to just read the docs myself. Lesson learned. For any SDK, I paste the actual README into the context window first.
実際に機能するプロンプトパターン
何ヶ月も反復してきた。悪いプロンプトは悪い出力を生む。ここにたどり着いたのが俺の現在地だ。
インターンではなく、シニア開発者になれ。「Xをする関数を書いてくれ」と聞くな。「Xを実装する必要がある。制約はYだ。既に除外した選択肢がZだ。まず何をするか考えてくれ。その後で書くなら」と言え。考えさせろ。その後の出力は劇的に良くなる。Don't ask "write me a function that does X." Ask "I need to implement X. Here's the constraint: Y. Here's what I've already ruled out: Z. What's your approach before you write anything?" Make it think first. The output after that conversation is dramatically better.
ペルソナとスタークを与えろ。俺は文字通りこう書く：「あなたはセキュリティの脆弱性を導入しないことを深く気にかけるシニアWordPress開発者だ。クライアントはヘルスケア企業だ。サニタイゼーションとノンス検証を他の何より優先しろ」。これはバカバカしく感じるか？ああ。機能するか？同じくああ。I literally write: "You're a senior WordPress developer who cares deeply about not introducing security vulnerabilities. The client is a healthcare company. Prioritise sanitisation and nonce verification above everything." Does this feel silly? Yes. Does it work? Also yes.
出力のフォーマットを指定しろ。「関数だけくれ、説明なし」または「関数をくれ、その後に俺が手動で検証すべきことの箇条書き」。構造化されていない出力は時間を無駄にする。"Give me just the function, no explanation" or "Give me the function, then a bullet list of what I should manually verify." Unstructured output wastes time.
常に手を伸ばすパターンが一つある：
- 目標を1文で述べる
- 関連する既存コードを貼り付け、その目的を説明するコメントを追加する
- 制約を明記する（「PHP 7.4 との後方互換性が必須」）
- まずアプローチを尋ねる。コードはその後
- アプローチをレビューして、必要なら異議を唱えてから、コードを求めるthen ask for the code
5 ステップ。オーバーヘッドに聞こえるかもしれない。毎回、不正なコードを 15 分短縮してくれる
これが委譲を変えた方法
これが最も驚いたところです。Claude Codeは単に僕を速くしたのではなく、ジュニア開発者に手渡すものを根本的に変えました。me faster. It changed what I hand off to junior developers.
以前は、Seahawk のジュニア開発者は最初の2週間を、私たちの慣例とスタックに慣れるだけで終えていました。今は、よく書かれた CLAUDE.md ファイル付きのプロジェクトを彼らに渡して、Claude Code を使ってスキャフォルドコードを生成し、慣例に照らし合わせてレビューするよう伝えます。彼らは3週間ではなく3日で実際の仕事に貢献できています。CLAUDE.md and tell them to use Claude Code to generate scaffold code, then review it against the conventions. They're contributing real work in three days instead of three weeks.
CLAUDE.md ファイルは、私が時間単位のウォークスルーで行っていたメンターシップを担っています。これは意味のある転換です。メンターシップをしたくないからではなく――実際にやりたいです――むしろ、メンターシップの会話が「すべてのフォームで wp_nonce_field() を使用することを忘れずに」ではなく、決定とトレードオフについてになったからです。CLAUDE.md file is doing the mentoring I used to do in hourly walkthroughs. That's a meaningful shift. Not because I don't want to mentor -- I do -- but because now the mentoring conversations are about decisions and trade-offs, not "remember to use wp_nonce_field()in every form."
Anthropic のモデル仕様ドキュメントは、Claude が動作する中での保護機構に興味がある場合に読む価値があります――それらを理解することで、傾向に対して逆らうのではなく協力できます。Anthropic model spec documentation is worth a read if you're curious about the guardrails Claude operates within -- understanding them helps you work with its tendencies rather than against them.
創業者向けの視点
AI コーディングツールについての記事のほとんどは開発者向けに書かれている。それは構わない。だが Claude Code が対処する創業者特有の問題があり、それが十分に言語化されているのを見たことがない。
エージェンシーを運営していてコードも出荷しているとき、最大の敵はスキルギャップではありません。再進入コストです。価格設定の電話で40分引っ張られて、その次は CSS の回帰を修正する必要があり、その後チームメンバーとの1対1があります。構築していた機能に戻る頃には、スレッドをあまりにも完全に失ってしまい、再開するより最初からやり直す方が簡単に感じます。re-entry cost. You get pulled into a pricing call for forty minutes, then you need to go fix a CSS regression, then you have a 1-on-1 with a team member. By the time you get back to the feature you were building, you've lost the thread so completely that starting again feels easier than picking up.
Claude Code を適切に使えば、再参入コストを劇的に削減できる。前に触れたサマリーコメントブロックのトリックもそうだ。さらに私は、完了したことと次にやることとブロックされていることの箇条書きで、自分あてに Slack メッセージを素早く生成するのに使っている。10 秒で済む。10 分の再構築を節約できる。
あなたをより良いマネージャーにはしません。あなたのカレンダーをクリアもしません。しかし、まだシップしている創業者であれば――そして私たちの多くがそうであるべきだと思います――コーディング時間の特定の、辛い税金を取り除きます。
FAQ
フルタイム開発者でなければ Claude Code は価値があるか？
正直なところ、おそらくそうではないでしょう。毎日ツールを使用していて、良いコンテキストファイル（CLAUDE.md、明確なプロジェクトブリーフなど）を構築するために時間を投資すると、価値は増します。週に1回だけ使用しているのであれば、コンテキストを再確立するのに使っている時間より多く費やすことになるでしょう。GitHub Copilot は時々のユーザーに向いているかもしれません――より環境的で、意図的なセットアップが少なくて済みます。CLAUDE.md, clear project briefs, etc.). If you're dipping in once a week, you'll spend more time re-establishing context than you save. GitHub Copilot might suit occasional users better -- it's more ambient and requires less deliberate setup.
コード品質をどう処理しますか――生成されたものを信頼するだけですか？
盲目的にではなく。Claude が生成したすべてのファイルは ESLint と Prettier 設定を自動的に通します。認証、支払い、データ処理に関わるものについては、手動で1行ずつレビューします。ユーティリティ関数とテストについては、もっとリラックスしています。リスクに基づいてキャリブレートします。OWASP Top Ten は、ユーザー入力を処理する AI 生成コードをレビューするときに役立つ心的チェックリストです。OWASP Top Ten is a useful mental checklist when reviewing AI-generated code that handles user input.
WordPress特に対応していますか？
予想以上に良い結果になりました。ただし注意点があります。WordPress を深く理解しています――フック、フィルタ、Settings API、WooCommerce の内部です。しかし、より新しい Gutenberg ブロック開発（特に Interactivity API）についての知識は不十分です。ブロック関連のものについては常に Block Editor Handbook に照らして検証します。Block Editor Handbook for anything block-related.
コストはどうですか？
Claude Pro に月20ドル払っています。私の使用レベルでは、時間の節約は週4～6時間程度です。自分の時給で計算してみてください。私にとっては考える価値もない問題です。
---
私はまだたくさんコードを書きます。プロンプトジョッキーになって実際の関数に一度も触れない人になることには興味がありません。しかし、AI コーディングツールが技術を変えていないふりをする創業者は、自分たちをだましています。使うかどうかではなく、使う問題です。十分な厳密さで実際の価値を得ているのか――それとも実際の問題を引き起こすだけの十分な不注意なのか。
私にとって、その両者の違いは Claude Code を有能だが経験の浅い開発者として扱うことで決まりました。頭が良い。処理が速い。適切なブリーフが必要。レビューが必要。ミッションクリティカルなものの近くに放置するのは厳禁です。
そのフレーミングがすべてを変えました。