吉田真吾（@yoshidashingo）です。
咋年末に発売した『実践Claude Code入門』の売れ行きが好調です。発売前から増刷も決定し、がんばって執筆した甲斐があったといったん胸を撫で下ろしてる今日この頃です。冬休みの間に写経実践していただいた人たちからもフィードバックをいただき大変光栄です。
いただいた感想・書評など
ありがとうございます。
他にもわたしも感想を書いたぞという方がいればぜひトラックバックしてください。
テトリスばかり作ってる場合じゃない
さて、Claude Codeの実践活用方法を書籍化したことで、多くの人に基礎的な使い方からスペック駆動開発の基礎が理解してもらえている状況に思えます。そのうえで2026年はどんな年になるかというと、Claude Codeを既存のコードベースになめらかに（＝安全に、効率よく）オンボーディングし、AIフレンドリーかつ人間フレンドリーな構造に改善し、チーム開発のリズムを止めずに開発を加速させるための試行錯誤が大きな関心事になるエンジニアが増えるはずです。
新規プロダクトであればはじめからリポジトリ内にシステム企画ドキュメント、こまかい機能の動作仕様やアーキテクチャ、処理シーケンスを定義し、つねにそれらを参照しながら開発が進められます。ここまではすでに達成済みの人も多いでしょう。
それに比べて既存のコードベースには以下のような課題がある場合があります。
- [ドキュメント不足]ドキュメントがいっさいない、あるいは外部ストレージにある
- [ドキュメントと実装のズレ]ドキュメントはあるがすでに腐っている（実装が先行している）
- [システムとコードベースのマッピング不明]どのリポジトリが何をやってるのかさえわからない
Claude Codeの知見「1」vs ソフトウェアアーキテクトの知見「9」
実践Claude Code入門の書籍第4章でスペック駆動開発の基礎をやりましたが、そこでも重要なのはどんなリポジトリ構造や設計書の構成が今から作るシステムにおいて十分なものかを見越して作成する必要があることを意識してもらえたと思います。
簡単な2DテトリスをReactとVercelで作るときと、基幹系システムをJavaとJBossとOracle DBで作るときに、同じドキュメント構成やリポジトリ構造なわけがないことは想像に難くないですね。
これらに加えて業種・業界によって当然の仕様とされるべき内容、たとえば「有給申請があっても同月内に休出実績がある場合は振休として処理をする」などのドメイン知識の可視化まで考慮すると、ただClaude Codeを上手に扱える人だけ集まればすべてのシステムがきれいなコードベースで爆速に開発が進んでいくわけはないだろうと理解してもらえると思います。
力仕事とインテリ活動を分けてはじめの一歩を踏み出しやすく
すでに最近は上記のような既存のコードベースにコーディングエージェントを統合して開発生産性を向上する相談が多いのですが、話せる範囲で個人的に受けた相談のひとつが「リポジトリが数百あるが、ドキュメントがなくそれぞれが何をしているか調べるところから始めるので大変」といった内容でした。Claude Codeを使い始めるにしても、古参のエンジニアにひとつひとつリポジトリを使ってるか使ってないか、使ってる場合はどのサービスのどのサブシステムで動いているか仕分けをまずしてもらう必要があるという認識だったのですが、当該エンジニアが忙しいので活動にアサインしづらいという話でした。
ひとつの解決策として提案したのは、すべてのリポジトリのBitbucketパイプラインにClaude Codeを仕込んで、リポジトリを解析してドキュメントを整備するイシューからPRまで作成するエージェントを仕込むといった内容です。力仕事中心なので、手順化してしまえば仕込むこと自体は難しくないうえに、実際にどのサービスのどのサブシステムとして稼働してるかどうかまでリポジトリ横断的な調査まで含めてある程度Claude Codeで実現できそうなアイデアです。
この提案自体がその先どうなったかまでは、仕事ではなかったため追跡はしていないのですが、こういったはじめの一歩さえ踏み出せば、次の課題への対策、次の課題への対策と回り出す現場はきっと少なくないのではないかというのが現在の実感です。
ちなみに上記のClaude Code Actionについては実践Claude Code入門の第5章で解説しています。
まずはClaude Codeを自由自在に扱えるようになりましょう
ということで再度PRになりますが、まずはなによりこの本で素早くClaude Codeを使いこなせるようになってもらえればと思います。
