2026年9月8日に、『Claude Codeで作って学ぶ AI駆動アプリ開発入門』（技術評論社）が発売されます。
私にとって初めての商業出版で、打診をもらったのは2025年12月でした。
一冊分の原稿がどうやって形になったのか、書き終えたいま振り返ってみたくなりました。
この記事は、打診から初稿を渡すまでに何を考え、どこに時間をかけたかを著者の側から書いた記録です。
忙しい人のための要約
- 打診は2025年12月。年末年始に目次を作り、3月下旬に初稿を編集者の方へ渡すまで約4ヶ月
- 原稿はまず自分で書き、Claude Code には手直しの案出しと、章をまたいだ検査を任せた
- 一番時間をかけたのは目次の組み替えで、一番楽しかったのはレビューを仕組みにしていく作業です
打診から企画が固まるまで
きっかけは1通のメールでした。
平川知秀さんの『Claude CodeによるAI駆動開発入門』が完成形に近づいた時期に読者目線でのレビューをさせていただき、そのつながりで声をかけてもらいました。
社内で Claude Code の初心者向け企画が上がっているので一度打ち合わせを、という流れです。
本は一度出してみたいと前々から思っていたので、返事は即決でした。
扱うツールを Claude Code に決めるまで
最初の論点は、Claude Code を題材にするのが今ベストなのか。
Codex、GitHub Copilot、Cursor も候補で、どれも魅力的です。
それでも Claude Code に決めたのは、当時いちばんハマっていて、これからも伸びるツールだと思っていたからです。
パイオニアとして標準を作ってきた以上、1年後もまだ最先端を走っているはずだと確信できました。
（本書でもoikonさんの記事の言葉をお借りしてます）
技術評論社内では他ツールの候補もあったと聞いていたので、異論に納得してもらえるデータを自分で用意して編集部へ送っています。
挙げた論点は3つ。
- 競合は Cursor が最有力だが、すでに複数の書籍が出版済みであること
- Claude Code は AI駆動開発の火付け役として注目度が高く、スキルやサブエージェントによる差別化もあること
- ただし CLI 中心の操作は初心者には敷居が高いというデメリットもあること
裏付けは、その時点で私が数えた Zenn の記事数です。
並べると Claude Code が頭ひとつ抜けていました。
私が出しているUdemy講座でも Claude Code 系が特に人気で、判断を後押ししました。
先行2冊との違いと、固まった企画
技術評論社から直近で Claude Code 本が2冊出ていることには、自分でも気づいていました。
そのうえで進めたのは、毛色が違う本を出すことに意義があると思っていたからです。
同じ Claude Code 本でも、狙う場所は分けられます。
- すでに出ていた2冊: 機能を網羅的かつ細かく知り、使いこなしていく人のための実践的な本
- 私の本:「最初は」使いこなすことよりも、まず使ってみること、慣れること、とっつきやすさ
一冊で完結する分、マスターする上では前者のほうが間違いないでしょう。
それでも私が選んだのは後者で、ある意味、私の本は最終形態ではないと思ってます。
他の方の本に進んでもらう前提で考えています。
その企画に対して、編集者の方からの最初の草案が届いたのは12月中旬でした。
草案は、その時点でかなり完成度が高いと感じました。
変えたのはハンズオンの題材のほうで、技術的にハマりやすいポイントは避けています。
タイトルを含めブレなかった軸は「作って学ぶ」です。
ハンズオン形式で、「学ぶ」よりも「慣れていく」に近い体験にしたかったからです。
誰に向けて書いたか
一番頭を使ったのは、ターゲットをどこに置くか、どこまでを扱うかの線引きでした。
ペルソナは下限に置いた
公称のターゲットは「エンジニア1〜3年目」ですが、ペルソナはその中でも「1年目」に置いています。
1年目から3年目は幅が広いので、まだ慣れていない人を想定したほうが振り落とさずに済むと踏みました。
ただし正直に言えば、実務1年と本では謳っているものの、実務未経験の人が読むことをずっと想定しながら書いていました。
そのほうが広い範囲をカバーできますし、挫折する方も少なくなります。
そのため、Git と GitHub の説明、Node.js のインストール方法、さらに軽くターミナルや PowerShell の使い方なども組み込みました。
GitHub と Node.js は付録 A・B として独立させています。
対象読者、どこまで広げるか悩んだ
一方で React・TypeScript・Next.js を用語だけにしたのは、かなり葛藤がありました。
フレームワークやライブラリを知って自分で開発したい人も、一定数いるはずです。
線を引けたのは、Udemy の受講生や、自分が運営している Discord コミュニティで見てきた人たちがいたからです。
プログラミングを全く書けなくても、開発にチャレンジする人は今も増えています。
それでもいいんだ、正解だったんじゃないかと思えました。
ただし、それは対象読者を非エンジニアにまで広げていいという話ではありません。
非エンジニアまで広げるかどうかは、担当編集者の方と何度も話し合った唯一の大きな論点でした。
広げない方向に決めた理由は2つあります。
- エンジニアが知りたいこと、知っておいてほしいことを書きたかったこと
- ビジネス寄りの用途については、正確に伝える自信がなかったこと
どちらも、自分が責任を持って書ける範囲はどこかという話です。
文字だけで伝えるために足したもの
伝え方の面では、動画と紙の違いにずっと向き合っていました。
動画なら画面を見せながら時間軸の動きも伝えられますが、当然ながら文字だと説明（＋図解）が全てです。
文字だけでも分かるように、それぐらい丁寧な説明を心がけました。
丁寧の中身は、実例を見せることと、なぜそうしたほうがいいのかという理由まで書くことです。
説明の型も、例え話から具体例へ、そして対策へ、という順番に揃えています。
その型に何を流し込むかは、受講生の質問から決めました。
溜まっていた「必ずつまずく場所」は、本書にも盛り込ませてもらっています。
- インストールでつまずく
- どっちを選べばいいのか迷う
- どこに置けばいいのか迷う
受講生からいちばん多かったのは、エラーが起きたときの「まずはどうすればいいですか」という質問です。
この質問を何度も受けて答えてきたので、エラー対処だけは他よりも厚めに書きました。
入門書として諦めたもの
入門書なので、泣く泣く諦めたものもあります。
実務でいちばん使っているサブエージェント、それにフック（処理の合間に自動で走らせる仕組み）や worktree（複数の作業ディレクトリを並行して使う仕組み）での並列実行です。
たっぷりページを割いて学ぶほうがいいところなので、そこは他の本に譲ろう、と。
代わりに実務経験がそのまま出たのが、基本でありながら一番大事かもしれない、CLAUDE.md に何を書くか、何を書かないかという話でした。
目次を組み替え続けた年末年始
そのうえで本当に悩んだのが、目次でした。
年末年始のあいだに自分で目次を作り、年明けに編集者の方へぶつけています。
机上の並べ替えだけではありません。
ここではこういうことを言う、というのを試しに軽く書いてみて、不自然だなと気づいて直す、の繰り返しです。
体感で、再検討した回数は20〜30回ぐらい。
教える順序についての持論もあります。
全体に影響することを先に。
知らなくてもできることと、知らないとできないことは別物なので、CLAUDE.md を前に持ってきました。
崩すきっかけは様々です。
- 実際に書いてみたら違和感があった
- 1日置いて読み直したら不自然だった
- Claude Code に読んでもらったら、ここは不自然だと言われた
- ハンズオンを作り出すと「これは先に説明しておきたい」が出てくる
どれも机の上では見えないもので、書いてみて初めて分かることばかりでした。
しかもこの時期は、編集者の方も休みで相談できません。
世の中が休んでいる中で一人で作業を進めるのは、正直しんどかったです。
それでもここが一番大事だと分かっていたので、走り切れました。
題材の決め方
目次のほかにも詰めておくべきことがありました。
作るものを何にするか、です。
かなり悩みましたが、最終的にはメモアプリに落ち着きました。
選んだ背景・理由はいくつかあります。
- パッと見て何を作るのか想像できること
- Claude Code 以外のところでも学びが多いこと（CRUD、DB、UI が一通り出てくる）
- ユーザー認証を挟まないこと
パッと見て想像できることを最初に置いたのは、帯や表紙に書いてあったときに、これはどういうものかがすぐ伝わるからです。
判断が一番割れたのはユーザー認証でした。
標準的によく使われる機能の一つですが、Claude Code から話がそれる割に、説明を手厚くしないとハマる人が多くなります。
ページ数に対してコスパが悪いと判断しました。
1ヶ月の執筆と、その後の作り直し
実質のスタートは目次と構成が決まった1月下旬で、一旦書き終えて自分のチェックに入ったのが2月下旬です。
ここまでが約1ヶ月。
初稿を編集者の方に渡したのは3月下旬ごろでした。
目次の組み替えとは別に、一番大変だったのが書き上げたあとの構成やり直しです。
見直して入れ替えたり、セルフでやり直したりするのが、とにかくきつかったです。
順番を入れ替え、一章まるまる書いたものを消し、入れ替えたことで破綻した箇所を一つずつ直していきました。
レビューを仕組みにした
Claude Code にはそれまでも誤字・脱字、説明の自然さといった観点でレビューをさせていましたが、この時期から本気でレビュアーとして使い始めました。
とはいえ原稿そのものを書かせたわけではなく、まず自分で書き、手直しの案出しと章をまたいだ検査を任せる形です。
個人的に、一番楽しかったのがここです。
観点ごとに別々のエージェントへ読ませた
自分で読み返して「なんとなく良い」で通してしまうのを止めたくて、レビューを Claude Code のスキルに落とし込みました。
読みやすいかどうかを一括で判定させたわけではありません。
初学者目線で読みやすいか、説明が補完されているか、話が飛んでいないか、前後関係はどうか。
観点ごとにサブエージェントを立てて、別々に読ませます。
それぞれに重みを付けてスコアを出させ、客観指標を満たさないときは必ずエラーにして修正を繰り返しました。
うまくいかなかったこともあります。
点数に振り回された結果、あえて削ったはずの説明が復活してしまったりもしました。
これはループを回すうちに自分で気づいて、元に戻しています。
このあたりは調整の繰り返しでして、とにかく自分で再チェックしては Claude Code レビュー、そのループでした。
reflect と、地味な整合性チェック
一番効いたのは reflect と私が勝手に呼んでいる仕組みです。
たとえば、どんなに観点やチェックポイントを Claude Code のスキルに入れても、自分で見て「ここはやっぱり直したほうがいい」と思うところは出てきます。
だったら、その手直しのほうを教材にすればいい。
なぜその手直しが入ったかを分析させて、自分の目線をコピーしていく。
時には私に質問をさせて、答えをまた次の手直しに入れていく、といった考え方です。
その結果、自分でチェックした後に Claude Code でレビューさせたところ「言われてみれば確かに直すべき」という細かいところも見てくれるようになりました。
自分が見落とす細かさまで、常に新鮮な目線で拾ってくれる自分のコピーができたような感覚です。
特に助けられたのは、文章や解説の整合性でした。
- まとめ表のメッセージが揃っているか
- 表記が統一されているか
- 章をまたいだ言い回しや用語がぶれていないか
人間の目だと見逃しがちな点はもちろん、全体として見たときに統一が取れているか、前後で違うことを言っていないかなど、広い目線でチェックする際に特に役立ちます。
Claude Code が Claude Code を検証する
文章のレビューとは別に、ハンズオンが実際に動くかどうかの確認も必要でした。
ここだけは、最後まで自分の手が要ると思っていました。
やっぱり自分で手を動かさないと、ここは説明として飛んでいるな、という分かりにくい部分に気づけません。
とはいえ毎回の検証には時間がかかります。
そこで最終的には tmux を使いました。
ターミナルを分割して自動で操作できるツールで、その内部で Claude Code が別の Claude Code を動かして検証する形です。
原稿は直させずレポートだけを返させ、最大4並列で回しています。
ターミナルや CLI の見た目も検証対象にしたので、画面が変わっていないかまでチェックできました。
たとえば、 /model コマンドを実行したときの CLI 上の表示が原稿通りか、それとも実際の CLI 上は変わっているか、といった点です。
このあたりはかなり細かく変わるうえ、チェックも毎回大変でした。
半自動化できたのは大きな成果です。
まとめ
普段から記事はよく書いていましたが、書籍となると流石にボリュームが大きく、一箇所の変更が広く影響します。
最初の構成とターゲットを練りに練ることの大事さが、身に染みました。
レビューを仕組みにして読みやすさを保ち続けたことも、やってよかったことの一つです。
こんな経緯で書き上がった Claude Codeで作って学ぶ AI駆動アプリ開発入門 は2026年9月8日発売です。
読んだ感想は #ClaudeCodeで作って学ぶ を付けて投稿してもらえるとうれしいです。
本の中でここはどうなっているのか、といった質問があれば、X でも何でもいいので気軽に聞いてください！