Claude Code と向き合って半年、僕の開発スタイルがガラリと変わった話
深夜 2 時、画面に向かって「この実装、どう書けば綺麗かな」と独り言を呟いていたあの頃。隣に先輩が座ってくれているような、でも気を遣わなくていい相棒ができた感覚。AI アシスタントを導入してから、コードを書く「速度」よりも「思考の深さ」が変わったと実感している。同じように「AI を使いこなせていないかも」「なんとなく便利だけど、どこまで任せていいのかわからない」とモヤモヤしている駆け出しの君に、僕の半年間の試行錯誤をそのままシェアしたい。
最初は「魔法の杖」だと思い込んで痛い目を見た
導入直前、Twitter や技術ブログで「生産性が 10 倍になった」「コードを書かなくてよくなった」という声をたくさん見かけた。正直、僕も「これで残業ゼロだ」「難しいアーキテクチャも一瞬で解決する」と浮かれていた。だが、いざ実務のリポジトリで「この機能、ベストプラクティスで実装して」と投げてみると、返ってきたのは一見動きそうだが、プロジェクトの規約や既存の設計思想を完全に無視した「それっぽいコード」だった。
なぜそうなるのか。AI は僕たちの頭の中にある「暗黙知」──このプロジェクトではなぜこのライブラリを使っているのか、なぜこの命名規則なのか、チームが大事にしているトレードオフは何か──を知らないからだ。僕が「認証周りをリファクタリングして」とだけ伝えて、既存のミドルウェアの仕様やエラーハンドリングの方針を伝えなければ、AI は一般的な教科書通りの実装を吐き出すだけになる。
ある時、認可ロジックの修正を依頼したら、ロールベースのアクセス制御（RBAC）を前提にしたコードを出してきた。でも僕たちのプロジェクトは属性ベース（ABAC）で、かつ特定の条件下だけ権限を緩和する独自の拡張を入れていた。AI の提案をそのままマージしていたら、本番で権限昇格のバグを生んでいたところだった。コードレビューで同僚に指摘されて冷や汗をかいたあの瞬間、「AI は優秀なジュニアエンジニアだ。でもコンテキストを与えないと、危険なコードを自信満々で書く」と肚に落ちた。
それ以来、プロンプトには「このファイルは○○という役割で、○○という制約がある」「既存の○○パターンに合わせてほしい」と、ドキュメントや関連ファイルへのパスを貼り付けるようになった。最初は面倒くさかったが、この「コンテキスト投げ」の質で出力の精度が劇的に変わることを体感してからは、当たり前の儀式になった。
✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨
最新ツール・トレンド情報をずんだもん×めたんが解説するYouTubeチャンネルを運営しています！
いいね、チャンネル登録してもらえると嬉しいです🙇♂️
ハジメル.dev: https://hajimeru-dev.vercel.app/
「ひとりで続けるのは難しい」「何から学べばいいか分からない」という方向けに、
プログラミングのマンツーマンレッスンサービス「ハジメル.dev」も運営しています。
未経験OK・オンライン完結・月額制/違約金なしなので、気軽に無料相談してみてください🙇♂️
海外テックニュースを追いたいけど、英語や情報量の多さで大変…という方向けに、
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/
言いたいことがうまく伝わらない…という方向けに、会話の言い方を添削する「伝え方ラボ」を開発中です。
場面を選んで自分の言葉で返すと、何が伝わっていないかの指摘と、そのまま使える言い換えが返ってきます。
ChatGPT に相談すると褒めから入って直すべきところが残りがちなので、指摘側に振り切りました。
現在は公開時にお知らせするメール登録のみ受付中です🙇♂️
→ 伝え方ラボ: https://tsutaekata-lab.pages.dev/
✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨
「書かせる」から「壁打ち相手」にシフトしたら世界が広がった
ある程度プロンプトエンジニアリングに慣れてくると、次に陥ったのが「全部 AI に書かせようとして、自分で考えるのをやめる」罠だ。複雑なドメインロジックを「要件定義書を渡すから実装して」と丸投げすると、動くコードは返ってくる。でも、いざバグが出た時や仕様変更が入った時に「なぜこの設計にしたのか」を自分で説明できない。コードのオーナーシップが自分にない状態、つまり「ブラックボックスを抱えたまま」になる恐怖を感じた。
転機になったのは、あるパフォーマンス改善タスクだ。N+1 問題の解消で、単純に includes や joins を入れればいい話ではなかった。キャッシュ戦略、データベースのインデックス、API のレスポンス形式の互換性、フロントエンドの描画タイミング……複数のレイヤーにまたがるトレードオフがあった。最初は AI に「最適化して」と投げて、出てきた SQL とコードを眺めていた。でも「これで本当に正しいのか？ ここでキャッシュを入れると、別のエンドポイントで整合性が取れなくならないか？」という疑問が湧いてきて、自分で手を動かしてクエリプランを見たり、既存コードを追ったりし始めた。
その時、AI には「今、こういう仮説で検証しているんだけど、このアプローチのリスクって何があると思う？」「このクエリプランの読み方、合ってる？」と問いかける形で使い始めた。すると、AI は「その仮説だと、ここがボトルネックになりそう」「そのキャッシュ無効化のタイミング、レースコンディションのリスクありますよ」と、僕が気づけていなかった視点を返してくれるようになった。
「書かせる」のではなく「思考の壁打ち相手」として使う。自分で仮説を立て、調査し、設計案を複数用意して「どっちがマシ？ なぜ？」と聞く。このスタイルに変えてから、コードの品質は上がったし、何より**「自分が設計した」という納得感と自信**が持てるようになった。AI は答えをくれる先生ではなく、優秀すぎて時々暴走するペアプロ相手だ。ハンドルは常に自分が握る。そう決めてから、精神的な余裕が生まれた。
レビュー負債を減らす「事前チェックリスト」を AI と作った
チーム開発で一番時間を食うのが、プルリクエストのレビュー往復だ。「変数名が規約と違う」「このロジック、共通化できるよ」「テストケースが足りない」──指摘される内容の 8 割は、自分で気づけていたはずの「凡ミス」や「定型的なチェック」だ。でも締め切り前になると、つい git push して「レビューお願いします！」と投げてしまう。
そこで、AI に「僕たちのチームのコーディング規約と、過去のレビュー指摘傾向を学習させて、セルフレビュー用のチェックリストを作ってほしい」と頼んだ。過去の PR コメントをいくつか貼り付け、ESLint/Prettier の設定、チームの README に書かれている設計指針を渡す。すると、AI は以下のようなリストを吐き出してくれた。
- 命名規則（ケース、接頭辞、略語の可否）に準拠しているか
- 既存のユーティリティ関数・カスタムフックで代替可能でないか
- エラーハンドリングは統一されたパターン（Result 型 or 例外）で書かれているか
- 境界値・異常系のテストケースが網羅されているか（最低 3 パターン）
- パフォーマンス影響（N+1、重い計算のメモ化、バンドルサイズ）を考慮しているか
- ドキュメント（JSDoc、README、CHANGELOG）の更新漏れはないか
- セキュリティ観点（XSS、CSRF、インジェクション、認可バイパス）で懸念点はないか
このリストを PR テンプレートに組み込み、自分でチェックしてから「セルフレビュー完了」ラベルを付けて出すようにした。最初は「こんなにチェックするの面倒くさい」と思ったが、慣れると 5 分もかからない。そして驚いたことに、レビューアーからの指摘コメントが激減した。「LGTM です」「細かいけどここだけ直して」程度でマージされるようになり、レビュー待ちの時間が圧倒的に減った。
AI に「この PR、チェックリストに漏れがないか見て」と投げてダブルチェックさせるのもアリだ。ただし、最終判断は人間がする。AI が「問題なし」と言っても、ビジネスロジックの妥当性までは判断できないからだ。この「機械的なチェックは AI に任せ、本質的な設計判断は人間がやる」という役割分担が、チーム全体の心理的安全感にもつながっている気がする。レビューアーも「細かい指摘をする罪悪感」から解放され、アーキテクチャや UX への深い議論に時間を使えるようになった。
学習の「伴走者」として、未知の技術に飛び込むハードルを下げた
6 年目になっても、触ったことのない技術スタックにアサインされることはある。先月、突然「来月から Next.js の App Router で新規プロジェクト立ち上げるから、キャッチアップ頼む」と言われた時、正直「また一から勉強か……」と重い腰が上がらなかった。公式ドキュメントを読んでも、Server Components と Client Components の境界線、Suspense と Streaming の挙動、Server Actions のセキュリティモデル……概念が多すぎて、どこから手を付ければいいかわからない。
そこで、AI に「Next.js App Router の全体像を、従来の Pages Router 経験者向けに、概念図とコード例付きで 30 分で理解できるチュートリアルを作って」と依頼した。すると、AI は「マインドセットの変化」「データフェッチのパラダイムシフト」「レンダリングライフサイクルの違い」といった章立てで、比較表と最小限の動くサンプルコードをまとめてくれた。「use client を書く基準」「generateStaticParams の使いどころ」「フォーム送信の Server Action 移行パターン」など、まさに「現場で即戦力になる知識」だけを抽出してくれていた。
さらに、「このコード、なぜ Client Component にしなきゃいけないの？」「Server Component で useState 使うとどう壊れるの？」といった「なぜ？」をその場で質問できるのがでかい。ドキュメントを読んで「ふーん」で終わるのではなく、自分の言葉で疑問を投げ、AI の回答を自分の言葉で要約してメモする。この「問い→答え→自分の言葉で再構築」のサイクルを高速で回せるのが、AI 伴走学習の強みだ。
実際、キャッチアップ 1 週間でチーム内勉強会を開いて「App Router 移行の勘所」を発表できた。資料作りも AI に「この内容でスライドの構成案出して」「図解の Mermaid 記法書いて」と頼んで時短した。もちろん、公式ドキュメントや RFC を一次情報として当たることは欠かさない。だが、「何から読めばいいか」「どこがハマりどころか」を AI に教えてもらうだけで、学習コストは体感で 1/3 になった。未知の領域への恐怖心「またゼロからか」が「まず AI に全体像聞こう」に変わった瞬間、技術キャッチアップが苦痛ではなく「探検」になった。
それでも「自分の頭で考えること」を手放さない理由
ここまで便利だと、つい「考えるのを AI に委譲しちゃえばよくね？」という誘惑に駆られる。実際、僕も疲れている時は「このバグ直しといて」と丸投げして、出てきた修正をテストもろくにせずコミットしそうになったことがある。だが、そこでブレーキをかけるルールを自分に課している。
- 「なぜこの修正で直るのか」を自分の言葉で説明できないコードはマージしない
- AI が提案した複数の選択肢から「なぜこっちを選んだか」をコミットメッセージや PR 説明に残す
- 週に 1 回は「AI なしで 1 時間コードを書く時間」を確保する（筋トレと同じ）
3 つ目は特に効いている。AI なしで書くと、補完もリファクタリング提案もない。変数名を悩み、型定義を行き来し、テストを手書きする。めちゃくちゃ遅いしストレスだ。でも、その「遅くて苦しい時間」こそが、自分のエンジニアとしての基礎体力＝「コードの臭いを嗅ぎ分ける嗅覚」「設計の勘所」「デバッグの仮説立て力」を維持する唯一のトレーニングだと気づいた。
AI はプロテインやサプリメントだ。トレーニング（自分の頭で考え、手を動かすこと）なしに摂取しても、筋肉（エンジニアリング力）はつかない。逆に、トレーニングをちゃんとやった上で AI を補助的に使えば、信じられない速さで成長できる。駆け出しの君には特に伝えたい。「AI に書かせる練習」より「AI と議論して、自分の設計を磨く練習」を積んでほしい。その方が、5 年後、10 年後、「あの時 AI に全部任せなくてよかった」と心から思えるキャリアになるはずだ。
まとめ
Claude Code を含む AI アシスタントと半年向き合って、僕の開発スタイルは「コードを書く人」から「設計し、判断し、AI を使いこなす人」へシフトした。魔法の杖でも、自分を置き換える脅威でもなく、**「文脈を与えれば優秀に働く、ちょっとお節介なジュニアエンジニア」**として向き合うのが、今のところ一番しっくりきている。
コンテキストを厚く渡すこと、壁打ち相手として問いかけること、機械的なチェックを自動化して本質に集中すること、未知の技術の地図を描いてもらうこと。そして何より、ハンドルを自分で握り続けること。これらを意識し始めてから、コードを書くのが「作業」から「知的ゲーム」に変わった気がする。
君も今夜、エディタを開く前に一度だけ AI に「今のタスク、こういう背景でこういう制約があるんだけど、どう切り崩すと思う？」と聞いてみてほしい。返ってきた答えに納得いかなければ、自分の案をぶつけてみればいい。そのやり取りの積み重ねが、きっと君だけの「最強の相棒」の作り方になるはずだ。明日からも、一緒に楽しくコードを書いていこう。