2025年6月18日、KAGのLT会 #6で「Claude Codeどこまでも」というタイトルで登壇させていただきました。今回は、Claude Codeを実際に使い込んでみて感じた、エンジニアリングの本質的な変化について、登壇では時間の関係で話せなかった内容も含めて深掘りしていきたいと思います。
この記事では、Claude Codeの3週間の使用体験から得た気づき、開発手法の根本的な変化とその対応策、そして実践的な導入方法と具体的なテクニックについてお話しします。客観的な話はまた、これから出てくると思うのでとりあえず主観的に作りました。
登壇資料
Claude Codeについて技術的な議論やデバッグしている結果の話をしようと思ったのですが、気がつくとこんなポエムになってしまいました。
当初は実装詳細や利用方法について体系的に解説する予定でした。しかし実際に使ってみると、技術仕様よりもこの新しい開発体験がもたらす心境の変化について語りたくなってしまったのです。エンジニアらしくパフォーマンス指標や比較分析を中心に据えるべきだったのでしょうが、機械学習の専門的な知見を持ち合わせていないので無理そう…。
結果として、個人的な体験に偏った内省的な資料になってしまいました。それでも、この主観的すぎる資料に懇親会では予想以上に温かい反応をいただけたことに驚いています。技術者としてはもっと客観的な内容を提供すべきだったかもしれませんが、時には感情に素直になることも悪くないのかもしれません。最近は感情的な文章を書きすぎかもですが…。
Xでのポストでも多くの反響をいただきました。
このブログが良ければ読者になったり、nwiizoのXやGithubをフォロワーしてくれると嬉しいです。では、早速はじめていきます。
はじめに
Claude Codeを使い始めて3週間。最初は「便利なコード生成ツール」程度の認識でした。しかし、使い込むうちに、これは単なるツールではなく、エンジニアリングという職業の本質を見つめ直すきっかけだと気づきました。
この体験と考察について、最初にブログ記事として投稿していた内容もありますが、今回はより深く掘り下げていきます。
Claude Codeの進化が示すもの
2025年6月時点のClaude Codeは、もはや単なるコード補完ツールではありません。7時間以上の連続作業を可能にする持続的な集中力を持ち、複雑なオープンソースプロジェクトのリファクタリングを人間の介入なしに完遂できます。
新たに搭載されたGitHub Actions統合により、コードの作成から、プルリクエストの生成、CIエラーの自動修正、レビューフィードバックへの対応まで、開発ワークフロー全体をカバーするようになりました。これらの進化は、開発という仕事の本質に大きな問題提起をしています。
体験から見えてきた「新しい真実」
私個人の限られた体験ではありますが、以下のような発見がありました。Claude Codeが実装作業を大幅に効率化してくれる一方で、実装スキルの重要性は全く失われていないという事実です。
むしろ、ソフトウェアの実装スキルと設計スキルは密接に関わっているため、高度な実装スキルは依然として必要だと感じています。変わったのは「実働が不要になった」ということであり、スキル自体の価値が下がったわけではありません。実装の良し悪しが分からないと、AIが生成した美しく見えるコードに騙されて、豚に口紅を塗る羽目になるのではないでしょうか。
この発見は確かに古くて新しい議論です。フレッド・ブルックスの『銀の弾丸はない』から、最近のClean ArchitectureやDDDまで、一貫して「設計の優位性」が語られてきました。Claude Codeのような現代のAI支援ツールが、この議論をより現実的なものにしています。
しかし、実装を軽視しているわけではありません。むしろ、私たちが本当に価値を提供すべき領域がどこにあるのか、そしてその価値を適切に判断するためにはどのようなスキルが必要なのかを明確にしてくれたのです。
Claude Codeが変えたもの、変えなかったもの
設計と実装の関係について考えてみると、これは結局のところ分割統治法の話なんですよね。複雑な問題を単純な部品に分解して、それぞれを理解しやすくする。ただ、各部品の品質を判断し、全体の整合性を保つためには、やっぱり深い実装スキルが欠かせません。
例えば、Webアプリケーションのエンドポイント実装を考えてみてください。表面的には「リクエストを受け取って、サービス層を呼び出して、レスポンスを返す」という単純な処理に見えます。でも、そのコードが本当に適切かどうかを判断するには、HTTPステータスコードの使い方、例外処理のベストプラクティス、セキュリティの考慮事項など、かなり深い知識が必要になってきます。
Claude Codeが確実に変えたのは、実装作業の効率です。反復的なコーディング作業から解放されて、複数のアプローチを短時間で試せるようになりました。これは本当に大きな変化です。でも、変わらなかったものもあります。良いコードと悪いコードを見分ける判断力は相変わらず重要ですし、システム全体のアーキテクチャを設計する能力の価値も変わりません。パフォーマンス、セキュリティ、保守性といった品質要件への深い理解も、依然として必要です。
つまり、Claude Codeは「実装労働者」としての側面を軽減してくれました。でも「実装の目利き」としてのスキルは、むしろより重要になったんじゃないでしょうか。AIが生成したコードの品質を瞬時に判断して、問題点を特定して、改善方向を示す。これこそが、現代のエンジニアに求められる核心的なスキルなのかもしれません。
知識は個人の認知的リソースと環境から提供される情報を結合させて創発されるものです。Claude Codeが提供する情報を、私たちの経験や判断力と組み合わせることで、新しい価値を生み出していく。これこそが、AI時代のエンジニアリングの本質なのかもしれません。
規模と複雑性
そして、プロジェクトの規模が大きくなると、もう一つの重要な観察が浮かび上がりました。「規模が大きくなると実装の手数が線形以上に増えるので、短期間で手数を多く打てる体力が生産性に大きく影響する」ということです。
ここで言う「体力」とは、従来の物理的な持久力ではありません。むしろ、AIとの協働を持続可能にする能力としての新しい体力概念です。Claude Codeは確かに「無限体力」を提供してくれますが、それを活用するためには人間側にも特殊な体力が必要なのです。
システムの構成要素が増えると、その関係性は組み合わせ的に増加します。n個のモジュールがあると、n(n-1)/2の潜在的相互作用が生まれ、インターフェースの整合性維持が指数関数的に困難になります。変更の影響範囲の予測が困難になり、回帰テストの工数が増大し、デプロイメントの複雑性が増してロールバック戦略が複雑化します。
従来のエンジニアにとって、この複雑性の増大は「疲労」という形で立ちはだかりました。しかし、Claude Code時代では、AIの「無限体力」を活用できるかどうかが、新たなボトルネックとなっています。
『イシューからはじめよ』からはじめよ
Claude Codeのような生成AI支援ツールは、確かに「実装から設計へ」のシフトを加速させています。コード生成能力により、「何を作るか」「どう設計するか」という思考により多くの時間を割けるようになりました。
ここで改めて注目したいのが、安宅和人氏の『イシューからはじめよ』です。この本が提唱する「真に価値のあるアウトプットを生み出すためには、どのような問題に取り組むかが決定的に重要である」という考えは、AI時代において、その重要性を失うどころか、むしろ中心的な指針となってきています。
つまり、私たちはまず『イシューからはじめよ』からはじめる必要があるのです。
「どのようなイシューを選びとるか？」の重要性
従来のエンジニアリングでは、実装能力が制約条件として立ちはだかっていました。「こんな機能があったらいいけれど、実装が大変すぎる」という理由で諦めていた課題が数多くありました。
しかし、Claude Codeが実装の制約を大幅に軽減した今、私たちは本当に重要な問いに向き合わざるを得なくなりました。「そもそも、なぜこれを作るのか？」「本当に解決すべき問題は何か？」「誰のためのソリューションなのか？」
実装が簡単になったからこそ、イシュー選定における考え方、スタンス、覚悟がより重要になっています。なぜなら、技術的実現可能性が制約でなくなったとき、私たちが向き合うべきは価値創造の本質だからです。
AI時代のイシュー選定に求められる覚悟
『イシューからはじめよ』が説く「イシュードリブン」なアプローチは、AI時代においてより深い意味を持つようになりました。
本質的な問題への集中： 実装の壁が低くなった分、「やりたいこと」と「やるべきこと」の区別がより重要になります。技術的に可能だからといって、それが価値のあるソリューションとは限りません。
顧客価値への原点回帰： AIツールにより開発速度が向上した結果、より多くの仮説を検証できるようになりました。しかし、だからこそ「誰の何の問題を解決するのか」という根本的な問いに真剣に向き合う必要があります。
限られた時間の戦略的配分： 実装にかかる時間が短縮された分、問題発見と課題設定により多くの時間を投じることができます。『イシューからはじめよ』が説くように、「どの問題に取り組むか」という判断に時間をかけることの価値が相対的に高まっています。
Claude Codeは確かに実装面での「無限体力」を提供してくれますが、それは同時に私たちに「本当に解決すべき問題は何か」という根本的な問いを突きつけているのです。
道を知っていることと実際に歩くことは違います。理論から実践への移行は知識の本質的な価値を明らかにします。Claude Codeによって実装の実働は軽減されましたが、適切な実装の判断ができなければ、どんなに美しいコードが生成されても、豚に口紅を塗る羽目になってしまいます。
能力を発揮する環境の変化とエンジニアに求められる能力の変化
能力の文脈依存性とAI時代の新しい文脈
日常生活において、私たちは「コミュニケーション能力」、「問題解決能力」、「技術力」などの様々な「能力」について語ります。しかし、これらの「能力」が具体的に指すものは何か、どう解釈すべきかを深く考えると疑問が生じます。能力という概念は抽象的であるがゆえに、その実態を把握するには具体的な文脈における観察と分析が欠かせません。
人間の能力は、状況に応じて異なる形で表れます。ある特定の文脈において顕著な能力が発揮される一方で、他の状況ではまったく異なる影響を持つかもしれません。例えば、プレゼンテーションの場で優れたコミュニケーション能力を発揮する人物が、親密な人間関係の中では十分にその能力を活かせないということもあり得ます。
Claude Code時代において、私が調べた範囲では、エンジニアが能力を発揮する環境が根本的に変化しているようです。従来は手作業での実装が主体だった開発環境が、AIとの協働を前提とした環境に変わりつつあります。この文脈の変化により、求められる能力も大きく変化していると感じています。ただし、これは私の限られた経験と調査に基づく考察であることをお断りしておきます。
環境変化に伴う能力の再定義
「技術力」という能力を例に考えてみましょう。従来の文脈では、「技術力」とは特定のプログラミング言語に精通し、複雑なアルゴリズムを実装できる能力として理解されていました。しかし、Claude Code時代の新しい文脈では、「技術力」の意味が変化しています。
新しい文脈で求められる「技術力」は、私の体験から言うと、AIが生成したコードの品質を適切に評価し、問題点を見抜き、改善方向を示す能力のようです。また、複雑な要件を明確に言語化し、AIに適切な指示を出す能力も重要になってきたと感じています。さらに、AIとの協働において効果的なワークフローを設計する能力も求められているのではないでしょうか。
文脈に応じた問いの形成
問いは、私たちが直面する特定の文脈における能力の発揮や理解を深めるのに重要な役割を果たします。そのため、問いは文脈に応じて形成される必要があります。
従来の開発文脈では、「どのようにしてこの機能を実装するか」「パフォーマンスを最適化するにはどうすれば良いか」といった問いが中心でした。しかし、Claude Code時代の新しい文脈では、「なぜこの機能が必要なのか」「本当に解決すべき問題は何か」「AIとの役割分担をどう設計するか」といった問いがより重要になっています。
知識の構成主義とAI協働
知識は個人の認知的リソースと環境から提供される情報を結合させて創発されます。Claude Code時代において、この「環境から提供される情報」にAIが生成したコードや提案が含まれるようになりました。
しかし、知識は伝達されるのではなく、各個人が自身の経験や環境から創発するものです。AIが提供する情報を、私たちの経験や判断力と組み合わせることで、新しい知識を構築していく必要があります。この過程では、実際にAIと協働し、試行錯誤を重ねることで、真に生きた知識が身につくのです。
プログラミング言語の文法や設計パターンを学んだだけでは、実際のソフトウェア開発で成功することは難しいのと同様に、AIツールの使い方を学んだだけでは不十分です。実際にAIと協働し、その過程で発生する問題を観測し、解決していくことで、AI時代に適応した新しい能力が身につくのです。
問題解決のアプローチが変わる
従来の価値観 vs 新しい価値観
昔から、優秀なエンジニアといえば高度な実装技術を持つ人だと思われてきました。複雑なアルゴリズムをスラスラ実装できて、特定の言語やフレームワークに精通している。そういう人がエンジニアとして価値が高いとされてきたんです。
でも、Claude Code時代になって、この価値観に変化が起きています。もちろん実装スキルは相変わらず重要なんですが、それに加えて問題を適切に分解・定義・設計できる能力がより重視されるようになってきました。実装能力から、抽象化能力と言語化能力へのシフトとでも言うんでしょうか。
ただし、これは単純な二者択一の話ではありません。現実のプロジェクトでは様々なトレードオフが存在し、チームの状況、プロダクトのフェーズ、技術的制約によって最適なバランスは変わります。今回の資料では時間の関係で対比的に表現しましたが、実際には両方のスキルが補完的に機能することが多いのです。
人間とAIの新しい役割分担
この変化に伴って、人間とAIの役割分担も見えてきました。
人間が担うのは、「なぜ作るのか」を問うこと、メタ視点で問題を捉えること、抽象的な設計を行うこと、そして価値判断と優先順位の決定です。一方、Claude Codeが得意なのは、「どう作るか」を実装すること、具体的なコード生成、反復作業の自動化、高速な試行錯誤です。
もちろん、この役割分担も絶対的なものではありません。プロジェクトの性質や開発者の経験によって、人間が実装に深く関わる場面もあれば、AIに設計の一部を委ねる場面もあります。SNSの短い投稿とは違って、現実の開発現場では多様な要因が絡み合い、状況に応じた柔軟な判断が求められるのです。
この分業によって、開発の本質が変わりました。実装の詳細から解放されて、より高次の思考に集中できるようになったんです。といっても、実装への理解が不要になったわけじゃありません。むしろ、より深い理解が求められるようになったのかもしれません。
重要な非対称性
ここで重要な非対称性があります。抽象の世界が見える人は具体の世界も見えますが、具体の世界しか見えない人は抽象の世界が見えない場合があります。
つまり、適切な設計ができる人は、Claude Codeに適切な指示を出せます。しかし、実装しか見えていない場合、Claude Codeを活用しきれない可能性があります。
なぜClaude Codeが「使いにくい」と感じられるのか
正直なところ、私が観察している限りでは、「Claude Code使えない」と感じる場合の多くは、設計の言語化に課題があるんじゃないかと思います。「自分でやった方が早い」と感じる場合も、プロセスとして設計段階をちょっと軽視しすぎているのかもしれません。ただし、これはあくまで私個人の観察に基づく仮説であり、他の方の状況は異なるかもしれません。
とはいえ、この問題はそう単純じゃありません。なぜ多くの優秀なエンジニアがAIツールに苦戦するのか。これは能力の問題というより、思考パラダイムの違いなんでしょうね。
従来の開発って、具体的なコードから始めるボトムアップアプローチが主流でした。実装の詳細を通じて設計を洗練させて、暗黙知に依存した判断と個人の経験とパターン認識で問題を解決していく。これに対してAI協働では、抽象的な設計から始めるトップダウンアプローチが必要になります。明示的な要件定義と言語化、文脈の完全な説明、システマティックな問題分解。
このギャップは、単なるスキルの問題じゃなくて、長年培ってきた思考習慣の転換を要求するんです。
設計の言語化が難しいのにも理由があります。専門家ほど、初心者には理解できない省略や前提を無意識に行ってしまいます。「いい感じに」という表現には、膨大な暗黙の前提が含まれているし、自然言語はプログラミング言語のような厳密性を持ちません。
「自分でやった方が早い」という感覚にも、認知的な要因が働いています。新しい方法を学ぶコストを過大評価して、既存の方法の非効率性を過小評価してしまう。長年培ってきたスキルへの投資を無駄にしたくないという心理もあります。自分で書いたコードの方が「制御できている」と感じる心理的安心感も無視できません。
より建設的な視点へ
でも、「使えない」と感じることを単に批判するんじゃなくて、なぜそう感じるのかを理解することが大事だと思います。新しいパラダイムへの適応には時間がかかるのは当然です。小さなタスクから始めて、徐々に複雑な作業へと移行していく。AIとの協働も一つのスキルなので、練習が必要なんです。失敗から学ぶ文化を育てることも重要でしょう。
「具体→抽象→具体」のサイクル
優れたエンジニアって、表面的な問題から本質的な課題を見出して、新たな解決策を生み出すサイクルを効果的に回せる人なんじゃないでしょうか。
このサイクルを回せない場合、Claude Codeは確かに「使いにくいツール」になってしまうかもしれません。でも、それはツールの問題というより、新しい開発パラダイムへの適応過程なんだと思います。慣れの問題、と言ってしまうと身も蓋もないですが、要は練習次第ということです。
Claude Codeとの効果的な付き合い方
「仕事のことをすぐに忘れる天才新人」モデル
Claude Codeを使い始めて3週間で私なりに到達した理解は、これを「仕事のことをすぐに忘れる天才新人」として扱うことでした。もちろん、これは私個人の比喩的な理解であり、他の方は異なる捉え方をされるかもしれません。
Claude Codeって、人間に例えると面白い特徴があるんです。天才的なプログラミング能力を持っていて、手の速さが異常です。同僚としていたら本当に心強い存在でしょう。でも、完全な記憶喪失状態で、長期記憶も短期記憶も全くありません。毎回指示待ちで、丁寧に状況説明が必要ですが、理解すれば驚異的な成果を出してくれます。「暗黙の了解」が通じないので、すべてを明示的に伝える必要があります。
この理解に至ってから、Claude Codeとの協働が劇的に改善しました。
なぜこのような特性なのか
この設計には合理的な理由があります。状態を持たないことで、並列処理が容易になってスケーラビリティが確保できます。ユーザー間での情報漏洩リスクも排除できるので、セキュリティとプライバシーの観点でも優れています。同じ入力に対して同じ出力を保証できるという予測可能性の向上も重要な利点です。
効果的なコミュニケーションの3つのポイント
まず、明示的な指示により曖昧さを排除することが重要です。「バグを直して」みたいな曖昧な指示じゃなくて、「src/auth.rsの認証処理でpanic!が発生しています。エラーログを確認し、thiserrorを使って適切なエラー型に変換し、テストも追加してください」みたいな明示的な指示が効果的です。
次に、タスク管理としてTodoWriteで状態を保存することも大切です。複雑なタスクは必ずTodoに記録して、進捗を可視化します。「TodoWriteツールで'リファクタリング'を低優先度タスクとして追加してください」みたいな感じで。
最後に、コンテキスト制御として定期的な/clearで最適化を行います。コンテキストが大きくなりすぎたら/clearでリセットして、パフォーマンス維持のために定期的なクリアが効果的です。
開発哲学の転換
価値観の再考が必要
Claude Codeを使い始めて気づいたのは、従来「良い」とされてきたコードが、AI開発では必ずしも最適ではないという事実でした。
従来の価値観では、美しいコードとは抽象化、DRY原則、デザインパターンを活用し、複雑性の隠蔽として高度な抽象化による簡潔性を追求してきました。
しかし、AI協働での新しい価値観では、AIは複雑な抽象化より、明示的で愚直な実装を理解しやすい場合があります。これは、人間の認知と機械の認知の根本的な違いに起因します。
「美しさ」の再定義
従来の美しさは人間の認知効率を最大化することを目指していました。重複を排除し、変更箇所を最小化し、概念的な整合性と対称性を保ち、将来の拡張性を考慮した設計でした。
AI時代の美しさは人間とAIの協働効率を最大化することを目指します。局所的な完結性と自己説明性、明示的な意図の表現、段階的な複雑性（progressive disclosure）が重要になります。
これは進化であって退化ではない
重要なのは、「美しいコード」と「AIが理解しやすいコード」は、二項対立ではないということです。状況に応じて適切なバランスを取ることが重要です。コアロジックでは人間が設計し、美しさを追求し、周辺実装ではAIが生成しやすい明示的なスタイルを採用し、インターフェースでは両者の架橋となる明確な契約を定義します。
AI協業時代における体力の再定義
重要な前提： 本分類は学術的研究に基づくものではなく、AI協業の実践経験から得られた観察と仮説に基づく経験的フレームワークです。個人差や環境差が大きく、一般化には注意が必要です。
なぜ体力の再定義が必要か
Claude CodeやChatGPTなどの「無限体力」AIツールとの協働が日常化した現在、従来の「体力＝筋力＋持久力」という定義では現実を捉えきれません。私たちは物理的な作業量ではなく、AIとの協働を持続可能にする能力として体力を再考する必要があります。
体力の構造的分類
基盤層：エネルギーの器（従来の体力に近い概念）
許容量（キャパシティ）について考えてみます。
物理的許容量では、長時間の座業に耐える身体能力、画面作業による眼精疲労への耐性、脳の情報処理における基礎体力が重要です。
精神的許容量では、バグ地獄でもメンタルが崩れない耐久力、AIの期待外れな出力への耐性、不確実性の中での判断継続能力が求められます。
認知的許容量では、複数のコンテキストを同時に保持する能力、抽象と具象を行き来する思考体力、AI出力の品質を瞬時に判定する処理能力が必要になります。
運用層：エネルギーの流れ（AI協業で重要性が増した領域）
消耗パターン（燃費設計）について
能動的消耗として、意識的なタスク実行では、AIへの指示設計時の集中力消費、コードレビューや品質チェック時の消耗、創造的思考や問題解決での消費があります。
特に重要なのが受動的消耗、つまり無意識下での継続消費です。警戒状態維持コストとして、AIの動作を常時監視する心理的負荷があります。判断疲れとして、「AIに任せるか自分でやるか」の微細な選択の積み重ねがあります。情報処理負荷として、通知、更新、変化への無意識対応があります。完璧主義税として、「もっと効率化できるはず」のプレッシャーがあります。AI依存不安として、「これで本当に大丈夫か」の心理的負荷があります。
瞬発的消耗として、急激な負荷への対応では、AIエラーの緊急対応、予期しない仕様変更への適応、急な割り込みタスクへの切り替えが挙げられます。
回復パターン（充電設計）について
積極的回復として、意図的な回復活動では、質の高い睡眠の確保、AI抜きの時間の意図的な設定、創造性を刺激する趣味や活動が効果的です。
消極的回復として、単純な活動停止では、画面から離れる時間、通知をオフにした時間、何も考えない時間の確保が重要です。
補償的回復として、代替エネルギー源の活用では、達成感の小さな積み重ね、他者との対話によるエネルギー補給、学習による成長実感が有効です。
時間軸層：持続可能性の設計
瞬間レベル（秒〜分）では、集中立ち上がり速度としてタスク開始時の集中力展開能力、コンテキスト復帰速度として割り込み後の作業復帰能力、瞬発判断力としてAIの出力を見た瞬間の品質判定能力が重要です。
セッションレベル（時間〜半日）では、持続集中能力としてAIとの長時間協働を維持する能力、タスク切り替え効率として異なる種類の作業間の移行コスト、午後の集中力管理として一日の後半での生産性維持が求められます。
日常レベル（日〜週）では、基礎消耗管理として日々の無意識消耗をコントロールする能力、週末回復効率として短期間での効果的なエネルギー回復、ルーティン最適化として習慣化による燃費改善が必要です。
長期レベル（月〜年）では、慢性疲労予防として持続可能な働き方の設計能力、技術変化適応力として新しいAIツールへの学習コスト管理、キャリア持続力として長期的な成長と体力維持のバランスが重要になります。
AI協業特有の体力要素
人間固有領域（AIで代替困難）として、創造的思考体力では、ゼロから新しいアイデアを生み出す能力、問題の本質を見抜く洞察力の持続、直感的判断を論理的に説明する能力が求められます。
対人コミュニケーション体力では、複雑な利害関係者との調整能力、チーム内での合意形成を導く能力、感情的なやり取りを処理する能力が必要です。
AI協働固有領域（新しく求められる能力）として、指示設計体力では、適切な抽象度でAIに指示する能力、期待と現実のギャップを管理する忍耐力、段階的に指示を洗練していく持続力が重要です。
品質判定体力では、AIの出力を適切に評価し続ける集中力、エラーパターンを学習・記憶する能力、「良し悪し」を瞬時に判断する直感力が求められます。
協働設計体力では、人間とAIの役割分担を設計する能力、ワークフローを継続的に改善する能力、新しいAIツールを組み込む適応力が必要になります。
この体力の再定義は現在進行形で進化しており、AI技術の発展と協働経験の蓄積により継続的にアップデートされることを前提としています。試行回数と成果に関してはかつてブログにまとめました。
開発プロセスの根本的な変化
「正解」から「最適解」へ
従来の開発では、動作する実装を作ることが目標でした。しかし、Claude Code時代では、複数の動作する実装から最適なものを選ぶことが仕事になります。
この変化は失敗学の観点から見ると非常に興味深いものです。従来のプロセスでは、要件から設計、実装、テスト、リリースという一直線の流れで、エラーがあれば設計に戻るという構造でした。この流れでは、「失敗」は避けるべきものとして扱われがちでした。
しかし、Claude Code時代のプロセスでは、要件から複数の設計案を生成し、並列実装を行い、比較評価して最適解を選択してリリースするという流れで、継続的に改善案を試行する構造になります。これは失敗学でいう「良い失敗」を積極的に活用するアプローチと言えるでしょう。
失敗の再定義
価値創出の源泉が実装能力から抽象化能力と言語化能力へシフトしている背景には、失敗に対する認識の変化があります。Why（抽象）を人間が担当し、How（具体）をClaude Codeが担当するという分業により、人間は未知の問題領域への挑戦により多くの時間を割けるようになりました。
ここで重要なのは、「悪い失敗」から「良い失敗」への転換です。従来の開発では、実装での失敗は多くの場合「悪い失敗」として扱われていました。無知や不注意、誤判断による失敗が繰り返されることも多かったのです。しかし、Claude Codeとの協働により、人間は実装の詳細から解放され、より本質的な問題解決に集中できるようになりました。
必要なスキルセットの変化
相対的に価値が下がったスキルとして、特定言語の深い知識、複雑な実装テクニック、手動でのコード最適化があります。これらは「悪い失敗」を避けるためのスキルと言えるかもしれません。
一方、価値が上がったスキルとして、Whyを問う力、メタ認知能力、言語化能力、システム設計思考、AI協働スキルがあります。これらは「良い失敗」から学び、成長につなげる能力と密接に関連しています。
特に重要なのは、失敗情報を適切に処理する能力です。失敗学では、失敗情報が「伝わりにくく、隠れたがり、単純化したがる」という性質を持つことが指摘されています。AI時代のエンジニアには、これらの性質を理解し、失敗から適切に学ぶ能力が求められます。
品質の新しい定義
従来の品質は、バグが少ない、パフォーマンスが良い、コードが読みやすいというものでした。これは「失敗を避ける」ことに重点を置いた定義と言えるでしょう。
AI時代の品質は、意図が明確で「なぜそう実装したかがわかる」こと、変更に強く「要件変更時にAIが適切に修正できる」こと、検証可能で「品質を自動的に測定できる」こと、再現可能で「同じ意図から同じ品質のコードを生成できる」ことが求められます。
これらの新しい品質基準は、失敗を隠さず、共有し、学習につなげるという失敗学の原則と一致しています。失敗情報のローカル化を防ぎ、組織全体での学習を促進する設計になっているのです。
エンジニアリングの新たな地平
創造的破壊がもたらした機会
Claude Codeは確かに従来のエンジニアリングの一部を変化させました。しかし、それ以上に「良い失敗」を積極的に生み出せる環境を創造しています。
変化したものとして、実装速度での差別化、暗記型の知識優位性、手作業による最適化があります。これらは主に「悪い失敗」を避けるためのスキルでした。
創造されたものとして、設計思想での差別化によりより良いアーキテクチャを考える時間が生まれ、概念理解の優位性により本質を理解していることの価値が向上し、試行錯誤による最適化により多様なアプローチを試せる自由が得られ、ビジネス価値への集中により技術的詳細から解放された創造性が発揮できるようになりました。
これらの変化により、エンジニアは未知への挑戦により多くの時間を投じることができるようになったのです。
新しいエンジニアの価値
これからのエンジニアの価値は、失敗学の実践者としての能力によって決まります。
問題発見力として、顧客が気づいていない課題を見つけ、技術で解決できる領域を特定し、本質的な問題と表面的な症状を区別する能力が求められます。これは失敗の本質を見抜く力と言い換えることができるでしょう。
アーキテクチャ設計力として、システム全体を俯瞰する視点、トレードオフを適切に判断する能力、将来の変化を見据えた設計が重要になります。これは失敗を予見し、リスクを管理する能力です。
意図の言語化力として、複雑な要件を明確な指示に変換し、AIとの効果的な対話を行い、チームメンバーへの設計思想を伝達する能力が必要です。これは失敗情報を適切に共有し、組織の学習を促進する能力に他なりません。
品質基準の設定力として、何を「良い」とするかの定義、測定可能な品質指標の設計、継続的改善プロセスの構築が求められます。これは「良い失敗」と「悪い失敗」を適切に分類し、学習につなげる仕組みを作る能力です。
失敗を恐れない開発文化の構築
重要なのは、Claude Code時代のエンジニアリングでは、失敗を恐れず、積極的に挑戦できる組織文化が不可欠だということです。AIツールの活用により、従来よりも安全に「良い失敗」を経験できる環境が整いました。
この環境を最大限に活用するためには、失敗学の原則に従い、失敗してもその経験を生かして改善につなげた場合には評価されるような組織文化を醸成する必要があります。また、評価や報酬制度も見直すことが重要です。
Claude Code時代のエンジニアリングは、単なる技術的進化ではなく、失敗から学び、成長し続ける新しい職業観の確立なのかもしれません。
まとめ
プロジェクトへの段階的導入
Claude Codeを既存プロジェクトに導入する際の推奨順序について説明します。
環境整備として、まずCLAUDE.mdを作成し、プロジェクト規約・エラーハンドリングパターンを文書化し、階層的な設定で段階的に詳細化します。次に開発ツールを最適化し、高速フィードバック環境を構築し、エラーメッセージを明確化します。
安全性の確保として、ガードレールを設置し、自動化されたチェック、コミット前の検証、安全な実行環境を整備します。
プロセスの最適化として、段階的タスク分解により複雑な実装を小さなステップに構造化し、各ステップでの明確な成功基準を設定します。並列開発を活用し、複数アプローチの同時検証と最適解の選択を行います。
パラダイムシフトを受け入れる
Claude Codeの登場は、単なるツールの進化ではありません。これはエンジニアリングという職業の再定義の機会です。
私たちに残された特権と責任
実装という「労働」から部分的に解放された今、私たちに残されたのは「思考」という特権です。しかし、それは同時に大きな責任でもあります。
「何を作るか」を考える責任、「なぜ作るか」を明確にする責任、「どうあるべきか」を定義する責任が私たちに課せられています。
最後に
昨日の自分より、ちょっと良い今日の自分になろう
Claude Codeを「使えない」と諦めるのは一つの選択です。「自分でやった方が早い」と現状維持するのも一つの道です。
しかし、この「仕事のことをすぐに忘れる天才新人」と上手く付き合い、新しい働き方を模索し、新しい価値を生み出すことで、私たちはより良いエンジニアになれるのではないでしょうか。
エンジニアリングとは、問題を解決することであって、コードを書くことではない。
Claude Codeは、この本質を私たちに思い出させてくれる、貴重なパートナーです。そして私たちは今、エンジニアリングの新たな地平に立っています。
共生的な未来への道筋
Claude Code時代のエンジニアリングは、AIが人間を置き換えるのではなく、強力な共生関係を構築することにあります。成功する開発者は、AIの計算能力と人間固有の創造性、共感、戦略的思考、倫理的推論を組み合わせます。
この変革を成功させるための重要な要素として、AIを脅威ではなく協力的パートナーとして受け入れ、効率性のためにAIを活用しながら人間固有のスキルに焦点を当て、急速に進化する環境で好奇心と適応性を維持し、技術的進歩と倫理的責任のバランスを取ることが求められます。
最も成功するエンジニアは、複雑な問題を解決するためにAIツールを巧みに活用しながら、技術を意味のあるソリューションに変える人間の洞察力を維持できる人々です。
この変化を受け入れ、自身のスキルセットを再定義することが、次世代の開発において成功する方法となるでしょう。
本記事は、2025年6月18日のKAGのLT会 #6での登壇内容を大幅に加筆・再構成したものです。スライドでは時間の関係で話せなかった内容も含め、あくまで一人のソフトウェアエンジニアとしてClaude Codeと向き合った3週間の個人的な体験と調査結果を基に執筆しました。
特に「仕事のことをすぐに忘れる天才新人」という理解に至るまでの試行錯誤、「美しいコード」から「AIが理解しやすいコード」への価値観の転換、そして『イシューからはじめよ』的思考の重要性の再発見は、私個人の限られた体験から得られた知見です。これらの観察や考察が、すべてのエンジニアに当てはまるとは限らないことをご理解ください。
【「実装」から「設計」へのパラダイムシフト というより無限に体力が必要という話をした】がイマイチ伝わらなかったし資料にも体力が必要って書いてなかった。元々、資料がすごい量になってて削るときに削ってしまった。が喋ってて削っている事に気づいて「あー」って音が出た
ご意見・ご感想は @nwiizo までお寄せください。また、株式会社スリーシェイクでは、このような新しい技術にチャレンジしたいエンジニアを募集しています。ご興味のある方は、ぜひカジュアル面談でお話ししましょう。
参考資料
書籍・論文
- イシューからはじめよ─知的生産の「シンプルな本質」
- 学びとは何か――〈探究人〉になるために (岩波新書)
- 達人プログラマー(第2版): 熟達に向けたあなたの旅
- プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ
