Claude Code任せで実力は育つのか — 現役SaaSが実践する5つの設計筋トレ
「Claude Codeを使って実装しているけど、これが自分の実力として積み上がっているのか不安です」というインターン生の相談がXに投稿され、約4,600件のいいねを集めました（2026年5月17日, すたーまん氏 / @fujitech_ai）。同じ違和感を抱える現役エンジニアは多いはずです。手は速くなった、でも「自分が書けるようになった」感覚は薄い。引き渡したコードを自分の言葉で説明できるかと言われると、自信がない。
結論から言うと、コードを一行ずつ手で打って覚える時代は終わりつつあります。鍛えるべきは設計力と要件定義力で、それは Claude Code を使いながら毎日 rep を積めます。本記事では、Claude Code MAXプラン（月$100）を1年以上業務で回している現役SaaSエンジニアの僕が、現場で実際にやっている5つの設計筋トレを、/plan モード活用や壁打ちテンプレなどの具体手順で書きます。Claude Code（または Cursor / Codex 等のコーディングエージェント）を毎日使い始めて3〜12ヶ月くらいの現役エンジニア向け。読み終える頃には、明日から積める設計の型が手元に残っているはずです。
「Claude Codeに実装させると実力が育たない」不安はなぜXで爆発したか
まず、2026年5月にXで爆発した一連の議論を整理します。
起点はすたーまん氏（@fujitech_ai）の「インターン生からClaude Codeで自分の実力が積み上がっているか不安だと相談された」というポストです。2026年5月17日に投稿され、約4,600件のいいねと60万を超える表示数を記録しました。氏の回答は「コードを一行一行理解する時代は終わった。鍛えるべきは設計力と要件定義力だ」というもので、ここに同じ不安を抱えていた若手・中堅が一気に反応しました。
派生して伸びた議論がいくつかあります。
- 手羽先氏（@Tebasaki_lab）の「AIによって要件定義などの上流だけが残り、それが全てになる、というのに反論できなかった」（5月18日, 約270いいね・32万閲覧）
- しまぶー氏（@shimabu_it）の「AIで超人化したエンジニアが、非エンジニアの仕事を無くしていく」（3月9日, 約1,200いいね）
- 27卒就活生のじゃむまる氏（@jammaru_lab）の「面接で『どんなコーディングエージェントを使っているのか・出力をどう検証しているのか』まで聞かれた」という報告（5月18日, 約120いいね）
- すたーまん氏のフォロー投稿「面接で差がつくのは『RAGのチャンク設計を自分で考えられるか』『コストと精度のトレードオフを説明できるか』」（約540いいね）
英語圏でも同じ温度感です。Anatoli Kopadze 氏が公開した「Claude Codeを作ったエンジニアの28分動画」要約は約24,000いいね・600万表示まで伸び、Claude Code の使いこなし論は世界的にトレンド化しています。
これらに共通するのは「AI時代のエンジニアの価値 = 何をどう作るかを定義する力」という論点です。コードはエージェントが書く前提に変わった以上、価値の重心は「書く力」から「設計を渡す力」と「出力を評価する力」へ移っている。これはバズった意見ではなく、現場で日々起きている事実だと感じます。
僕がClaude Codeを1年使って固まった「設計が9割」という感覚
ここで一次体験を挟みます。
僕は2026年1月〜3月の3ヶ月で、開発スタイルが大きく変わりました。元々はAIに補助で書かせる程度の使い方だったのが、いまは「まずClaude Codeにやらせてみよう」が口癖になっています。Cursor は PC のメモリ負荷が重すぎて2026年初頭に離脱、GitHub Copilot もやめて、いまは Claude Code MAXプラン（月$100）の一本に絞っています。コスパは正直、月$100が安く感じるレベルで良いです。
業務側ではもう、自分でゼロから関数を書く時間はかなり減りました。2026年4月以降は「生成AIを社内にどう浸透させるか」が役割の中心になってきていて、コードを書くより、設計判断と他部署との橋渡しに時間を使っています。
設計判断こそ価値だと痛感したのは、2025年3月に着手したOCR×LLMの請求書読み取り改善でした。請求書から金額・電気使用量・契約に紐づく排出係数を読み取る業務で、従来のラベリング型のOCRモデル改善では正解率が約1割で頭打ちでした。アプローチを変え、Azure の OCR で先に文字情報だけを抽出し、その結果を OpenAI のLLMに渡して項目ごとに解釈させる二段階構成に切り替えたところ、読み取り精度が劇的に改善しました。コードの巧拙ではなく「LLMにどこまで任せて、どこを既存OCRに残すか」という役割分担の設計判断が成果を決めた感覚です。
毎日 Claude Code に投げる中で確信したのは、ゴールが明確なほど出力精度が上がるという当たり前のことです。曖昧なときは実装に入る前に Claude と壁打ちしてゴールを言語化する。違和感がある部分を頑張って言葉にしようとすると、出力品質が一段変わります。逆に、自分が人に説明できないことは Claude にも伝わりません。この体感が、僕がいま設計力を最重要視している理由です。
現役SaaSが日常的に回している5つの設計筋トレ
ここから本丸です。読者が今日から rep を積めるレベルまで具体化します。
1. /plan モードで設計の壁打ちをしてから実装に入る
いきなりコードを書かせる癖を捨てるのが最初の一歩です。Claude Code には /plan のような設計フェーズ専用モードが用意されており、「実装の前にまず計画を立てる」フローを公式に組み込めます。詳細はAnthropic 公式の Claude Code ドキュメントを参照してください。
僕の使い分けはシンプルです。1ファイルで完結する小さな修正は普通に書かせる。複数ファイルにまたがる変更、データの流れに影響する変更、新規機能の追加は必ず plan モードから入る。plan の出力を読み、納得できないところに「ここのトレードオフをもう少し挙げて」と返す。OKになって初めて実装に入ります。
「先に動かしてみる」より「設計を固めてから走らせる」の方が、修正に費やす総時間は短くなります。
2. ゴールを言語化する「壁打ちテンプレ」を持つ
Claude Code に渡す情報を、毎回ゼロから書くのは効率が悪い。僕は4行の壁打ちテンプレを CLAUDE.md に書いて使い回しています。
- ゴール（何が達成できれば完了か）
- 制約（時間・予算・既存コードとの整合）
- 入出力（具体的なI/Oと型・サンプル）
- 完了条件（テスト・確認方法・受け入れ基準）
このフォーマットで埋まらないものは、自分の中で整理が足りていないサインです。書けない欄を Claude に投げて「この設計のどこに穴があるか3つ挙げて」と聞く。出てきた指摘が、自分の言語化のヒントになります。
3. フォルダ・ファイル粒度で「何が書かれているか説明できる」状態を維持する
実装は任せても、リポジトリの構造は自分の頭に持っておく。これが「実力が積み上がっている感覚」を取り戻す一番のレバーだと感じています。
週1回、tree -L 3 の出力を Claude Code に渡し、「このリポジトリを1分で説明して」と書かせます。返ってきた説明と、自分の理解のズレをチェックする。Claude の説明の方が正確だった部分は、自分の理解が遅れているサインなので、その箇所のファイルを30分だけ読み返します。
これを続けると、「自分はもう一行も書かなくても、このリポジトリは説明できる」という状態を維持できます。
4. AIに任せていい領域と、自分でやる領域を線引きする
5つの中で一番大事なのがこれです。Claude Code は強力ですが、任せていい領域と、自分が判断しないと事故る領域があります。比較表で整理しておきます。
| 領域 | 任せて良い | 自分でやる | 理由 | |---|---|---|---| | コード生成 | ◎ | | 仕様が固まっていれば速い | | 定型リファクタ | ◎ | | スコープが明確 | | テストひな形 | ◎ | | テスト観点は別途レビュー | | ドキュメント整形 | ◎ | | 内容のチェックは人間 | | 精度評価設計 | | ◎ | しきい値・正解データは人間が決める | | コスト/精度トレードオフ | | ◎ | 事業判断が必要 | | 技術選定の理由付け | | ◎ | 文脈と将来要件が要る | | セキュリティ境界設計 | | ◎ | 失敗の代償が大きい |
僕のOCR×LLM二段構成は、まさに「精度評価設計」と「役割分担」を人間側で設計したから精度が改善した事例です。AzureのOCRをどこまで信用するか、LLMに何を補わせるか、しきい値をどこに置くか。これらはコードを書く Claude の責務ではなく、エンジニアの責務です。
5. 業務で設計判断を入れにくいなら、業務外で「ゼロから設計する場」を週1で作る
現場が「言われたものを実装する受託モード」だと、設計判断の場が回ってきません。であれば、業務外に rep を積む場を作るしかない。
僕の場合は、社内で輪読会を半ば強制的に開催して学ぶ機会を作っています。同じ要領で、個人プロジェクトを1本立てて、設計から /plan モードで始める。週1で1時間、ゼロから書く設計の時間を確保するだけで、「設計判断ができるエンジニア」としての筋力は確実に育ちます。
5つ並べてきましたが、共通しているのは「コードを書く前と、書かせた後」に人間の判断を入れる作業です。Claude Code は中間の実装プロセスを高速化してくれる。だからこそ、両端の設計と評価を厚くする。これが現役エンジニアが日々やっていることです。
課題と限界 — 「設計力を鍛える」には3つの落とし穴がある
ここまで書いた設計筋トレは万能ではありません。現場で感じる難点を3つ書きます。
ひとつ目は、設計力の習得は時間がかかり、即効性のある成長実感がないことです。コードを書いて GitHub の草を生やすほうが、はるかに分かりやすい達成感があります。設計を考えた1時間は記録に残らず、本人にも「今日は何をした」と説明しづらい。短期的な成長感を諦める覚悟が要ります。
ふたつ目は、業務環境の制約です。要件もアーキテクチャも別の人が決めて、自分は実装だけを振られる現場では、設計判断の場が物理的に与えられません。この場合は前述の通り、業務外に rep を積む場を作るしかなく、それなりの可処分時間が必要になります。
みっつ目は、ツールの陳腐化です。僕自身、2025年初頭の Cline、2025年半ばの Cursor / Windsurf / Kiro、2026年の Claude Code、と1年で乗り換えてきました。半年前の Tips が陳腐化するのは、この領域では普通です。
それでも、「設計を考える時間を作る」「ゴールを言語化する」「任せていい領域を線引きする」という基本動作は、ツールが変わっても残ります。Tips ではなく動作を身につけることが、結果的に一番ツールに振り回されない投資になります。
まとめ
Claude Code 時代に積むべき rep を整理します。
- 価値の重心は「コードを書く」から「ゴールを定義して設計を渡す」に移っている
/planモードを起点に、設計を固めてから実装させる- 4行の壁打ちテンプレ（ゴール / 制約 / 入出力 / 完了条件）を
CLAUDE.mdに持つ - 任せていい領域と、自分でやる領域を比較表レベルで線引きする
- 業務に設計判断の場がないなら、業務外で週1の rep を作る
明日から取れる具体アクション3つで締めます。
- 今週の実装1本を、いきなり書かせず
/planモードから始める - 4行の壁打ちテンプレを
CLAUDE.mdに書き出して、次回の依頼で使う - 個人プロジェクトを1本立てて、設計から書く時間を週1で確保する
Claude Code を使い倒すほど、価値の重心は「書く」から「定義する」に移っていきます。手を動かしたい衝動を一度抑えて、設計の rep を積みに行く。これが、AI に任せても自分の実力として積み上げていくための、現役エンジニアの現実的な方法だと感じています。
