Claude Codeで「書いてもらう」と「自分で書く」の上手な切り替え方

はじめに ― 何度も挫折したコード生成ツールとの向き合い方

「AIに全部任せたら楽になるんじゃないか？」と、最初に思ったのは僕だけではないはずです。新卒で入社したばかりの頃、プロジェクトのタスクが山積みで夜遅くまで残業していたとき、同僚が「Claude Codeでサクッと書いてもらえるから試してみな」って教えてくれました。その瞬間、まるで魔法の杖を手に入れたような期待感に胸が高鳴ったんです。実際に数行のユーティリティ関数を生成させたときは、確かに「時間が節約できた」感がありました。

しかし、すぐに壁にぶつかります。生成されたコードは「動く」ものの、プロジェクト固有の命名規則やエラーハンドリングが抜けていたり、読みにくい変数名が散らばっていたり。結局、修正にかかる時間が結構な割合で戻ってきてしまい、結果的に「結局自分で書くのと変わらない」感覚に陥ったことがあります。そこで僕は「書いてもらう」と「自分で書く」の境界線を意識的に引くことにしました。

この記事では、僕が実際に試行錯誤しながら見つけた「使い分け基準」や、具体的なプロンプトの組み立て方、そして生成後のリファクタリングフローを共有します。コード生成ツールに対して漠然とした不安や劣等感を抱えている駆け出しエンジニアの皆さんが、ツールを味方に変えるヒントになれば嬉しいです。

1. 「書いてもらう」べきタスクの見極め方 ― 目的とスコープを明確に

なぜ目的をはっきりさせる必要があるのか

AIにコードを書かせるときに最も大事なのは、何を解決したいのかを具体的に言語化することです。漠然と「APIの呼び出しコードが欲しい」だけだと、返ってくるコードは汎用的でプロジェクトに合わないことが多いです。結果として、生成されたコードをそのまま使うのではなく、結構な手間でカスタマイズする必要が出てきます。僕が最初に失敗したケースは、バックエンドの認証ミドルウェアを作る際に「認証ロジックを作って」だけを指示したことです。返ってきたコードは基本的なトークン検証だけで、実際のプロジェクトでは必要なエラーログやリトライ処理が全く入っていませんでした。

具体的なスコープ設定の例

そこで試したのが、**「入力」「出力」「例外処理」「使用するライブラリ」**という4つの要素を必ずプロンプトに入れるやり方です。例えば以下のように指示します。

Node.js + Express で JWT トークンを検証するミドルウェアを書いてください。
- 入力: req.headers.authorization に "Bearer <token>" が入っている想定
- 出力: 次のミドルウェアへ next() を呼び出すか、エラー時は res.status(401).json({error: "Invalid token"}) を返す
- 例外処理: トークンが無い、または検証に失敗したときは 401 を返す
- 使用ライブラリ: jsonwebtoken (version ^8.5.1)

このように具体的に指示すると、生成されるコードはプロジェクトのスタイルに近く、手直しが最小限で済みます。実際にこのプロンプトで生成したコードは、ほぼそのままプロダクションに組み込めるレベルでした。

自分で書くべきケースの判断基準

逆に「自分で書く」べきタスクは、ビジネスロジックが複雑だったり、チームの設計方針が強く絡むケースです。例えば、ドメイン駆動設計（DDD）でエンティティの振る舞いを実装する場合、単なる CRUD のコード生成ではなく、概念的な整合性やユビキタス言語が重要です。AIに任せると、意図しないビジネスルールが抜け落ちる危険があります。僕はこのような場面では、まず自分でテストケースを書き、テスト駆動開発（TDD）の流れで実装を進めることにしています。AIはあくまで「テストを通すためのヒント」や「リファクタリングの参考」に留めると、結果的にコードの品質が保たれます。

2. プロンプト設計のコツ ― 具体性と段階的指示で精度を上げる

なぜ段階的に指示するのか

最初の頃、僕は「全部一度に書いて」ってプロンプトを投げていました。その結果、長いコードが一気に生成され、途中で抜けているインポート文や未使用変数が多数混在していました。AIは一度に大量の情報を処理すると、細部の整合性が崩れやすいという特性があります。そこで「小さな部品ごとに分割して生成させる」戦略に切り替えました。

具体的な段階的指示の例

たとえば、フロントエンドで新しいコンポーネントを作るときは次のように段階を踏みます。

1. 構造（JSX）だけを書いて

   React の関数コンポーネントで、ユーザー情報を表示するカードの JSX を作ってください。スタイルは Tailwind CSS を使う前提です。
   

2. スタイル（CSS）だけを書いて

   上記のカードに適用する Tailwind のクラスを列挙してください。デザインはシンプルで、カードの影と余白だけ。
   

3. ロジック（データ取得）だけを書いて

   useEffect と fetch を使って、API からユーザー情報を取得し、state に保存するロジックを書いてください。エラーハンドリングも含めて。
   

このように分割すると、各出力は短くなる分、正確さが増します。さらに、出力されたコードを自分のプロジェクトに貼り付けながら、**「ここはどう書けばいい？」**と追加で質問できるので、インタラクティブに完成度を高められます。

自分で書くときに活かすポイント

段階的指示はAIだけでなく、自分で書くときにも有効です。大きな機能を実装するときは、**「まずは UI の骨組みだけ」→「次にデータ取得」→「最後にバリデーション」**というフローで進めると、途中での設計変更が楽になります。AIに頼るか自分で書くかに関係なく、タスクを細分化する習慣は、コードの見通しを良くし、デバッグ時間を削減してくれます。

3. 生成後のリファクタリング ― 手戻りを最小限に抑えるプロセス

なぜリファクタリングが不可欠なのか

AIが生成したコードは「動く」ことが最優先で、可読性や一貫性は二の次です。僕が経験した事例では、AIが出した関数名がプロジェクトの命名規則と合わず、全ファイルで検索置換を行う必要がありました。これだけでも作業時間が 30 分以上増えてしまいました。リファクタリングの手間を最小限に抑えるために、**「生成直後に自動整形ツールで統一」**というステップを必ず入れました。

具体的なリファクタリング手順

1. コードフォーマットの適用
   Prettier や ESLint の自動修正機能で、インデントやクオートの統一を行う。

   npx prettier --write src/**/*.js
   npx eslint --fix src/**/*.js
   

2. 命名規則のチェック
   プロジェクトで決めたプレフィックスやキャメルケースに合わせて、変数名や関数名を検索置換。VSCode のマルチカーソルや sed コマンドで一括置換すると楽です。
3. テストの追加
   生成コードが正しく動くかを確かめるために、最低でも 1 つのユニットテストを書きます。テストを書きながら、**「期待した振る舞いと実装が合っているか」**を検証できるので、AIが見落としたロジックの抜けもすぐに発見できます。
4. コードレビューでのフィードバック
   チームメンバーに「AI生成部分」だけをマークアップしてレビューを依頼すると、客観的な指摘が得られやすいです。僕は「AIが書いた」ことを明示した上で、**「リーダビリティの改善」**を中心にコメントをもらうようにしています。

自分で書くときのリファクタリング感覚との違い

自分で書くときは、最初から 「テスト駆動」 の流れでコードを書き、書き終えたらすぐにリファクタリングします。AIを使うと、**「生成 → 整形 → テスト → リファクタリング」**という順序が自然にできるので、逆にリファクタリングが後回しになるリスクがあります。僕はこのサイクルを意識的に守ることで、生成コードでも品質を落とさずに済んでいます。

4. 心理的ハードルを乗り越える ― 不安や劣等感と向き合う

なぜ不安が生まれるのか

「自分のコードがAIに取って代わられるんじゃない？」という恐れは、実は 「自分のスキルが足りない」 という自己評価の裏側にあります。僕も最初は、AIが出したコードをそのまま貼り付けるだけで自分の価値が下がるのではと不安にかられました。結果として、生成コードに対して過度に批判的になり、結局何も使わないという悪循環に陥っていました。

具体的にどう克服したか

1. 小さな成功体験を積む
   簡単なユーティリティ関数（例: 配列の重複除去）だけを AI に任せ、結果が期待通りだったら「AIは自分の作業を補助するだけ」と認識を切り替える。数回繰り返すうちに、AIへの抵抗感が薄れました。
2. 学習の一環として位置付ける
   生成コードを読むことで、**「自分が知らなかった書き方」**や 「新しい API の使い方」 を学べると考える。実際、AIが提案した Array.prototype.flatMap の使い方は、僕が手動で検索したときには見つからなかった便利なテクニックでした。
3. チームで共有する文化を作る
   「AI活用のベストプラクティス」を社内 Wiki にまとめ、誰でも同じフローで使えるようにした結果、**「みんなが同じ基準で生成コードを扱える」**という安心感が生まれました。自分だけが特別に不安になるのではなく、チーム全体でハンドリングできるようになったのです。

自分で書くときの心構え

AIに頼らず自分で書くときは、**「学びの過程」として捉えるのがポイントです。テストが失敗したときに「自分はまだ足りない」と落ち込むのではなく、「この失敗が次の改善点」とポジティブに捉える習慣をつけました。AIと自分のコードを書き分けることで、「どちらも自分の成長に寄与する」**という認識ができると、自然と不安は軽減されます。

5. まとめ ― AIと共に成長する開発スタイル

Claude Code などのコード生成ツールは、**「時間を節約するための道具」であり、「スキルを置き換えるもの」**ではありません。僕が実践してきた使い分けのポイントは、

1. タスクの目的とスコープを明確にし、AIに適した範囲だけを委譲する
2. 具体的かつ段階的なプロンプトで生成精度を上げ、出力を小さな部品に分割する
3. 生成後は必ずフォーマット・命名・テスト・レビューというリファクタリングフローを踏む
4. 不安や劣等感は小さな成功体験とチームでの共有で克服し、AIを学習材料として活用する

これらを意識すれば、AIに頼りすぎず、でも必要なときには力強い味方に変えることができます。駆け出しの頃は「全部自分でやらなきゃ」というプレッシャーに悩むことが多いですが、ツールを上手く使うことで余計な負荷を減らし、**「本当に大事な設計やロジック」**に集中できる時間が増えます。自分のペースで、少しずつこのフローを取り入れてみてください。きっと、コードを書く楽しさが再び見えてくるはずです。

✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨

海外テックニュースを追いたいけど、英語や情報量の多さで大変…という方向けに、
Hacker News の話題を日本語でサクッと追える「HackerNews 日本語まとめ & AI要約」 
を個人開発しました！
技術トレンド収集に使ってもらえると嬉しいです🔥🙇‍♂️
→ HackerNews 日本語まとめ & AI要約: https://hn-matome-2ht.pages.dev/

✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨

「ニャンパイアサバイバー」というヴァンパイアサバイバーリスペクトのゲームを作成しました！
もしよろしければ遊んで頂けると嬉しいです😭

✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨

習い事教室の先生向けに、SNS 投稿・生徒募集・保護者通知の文章を AI で生成する Web サービス「おしらせAI」を個人開発しました。Next.js + Supabase + LLM で構成しており、無料で月 10 回まで試用できます。よければ触ってみてください。

→ おしらせAI: https://oshirase-ai.vercel.app/

✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨