私はこれまで、ありがたいことに複数の商業技術書を出版させてもらう機会に恵まれました。
長年ライターをやっていたりするわけではなく、エンジニア業務の傍ら、半分趣味で2年ほど執筆を行なっています。
元々Qiitaを書き慣れていて筆が速いというのもありますが、特にここ半年ほどは、Claude CodeやCodexなどのコーディングAIエージェントの進化がめざましく、あらゆる業務の爆速化に使えるようになりました。
今回は「商業書籍の出版（特にIT技術書）」にフォーカスを当てて、AIで爆速化するテクニックを紹介します。
この記事はすべて手書きしました。安心してお読みください。
基本的な考え方
「え、書籍の本文をAIに生成させるの？」と思われがちですが、そうではありません。
あくまで執筆以外の周辺作業をすべてAIで半自動化して、著者は執筆に、編集者はレビューに集中できる環境を整えるというコンセプトです。
なお、出版業務に限らず、非開発業務をAIエージェントで加速する方法全般については、以下の記事をご覧ください。
企画フェーズ
「xxについての書籍を執筆してもらえないか」という依頼を、出版社の編集さんから著者が受ける形からスタートする企画が多いのではないかなと思います。
フォルダ作って音声入力からスタート
最初に執筆リポジトリを作りましょう。ここからAI化は始まっています。
空のフォルダを作って、そこでVS CodeでCodex（もしくはClaude Code）を開き、音声入力で最初のプロンプトを大量にぶち込みます。以下、例：
SBクリエイティブさんからAWSのAgentCoreに関する書籍の執筆依頼が来たので、これからこのディレクトリを使って企画から執筆、構成、そして出版、マーケティングなどの活動をすべて行っていきます。これはGitHubのプライベートリポジトリにプッシュして運用する予定で、後から共著者や編集者など、必要に応じて追加していく予定です。今後、君が作業しやすいように、必要なコーデックスの初期設定であったり、agents.md、スキル、ルール、サブエージェントなど、ディレクトリ構造を今後作業しやすい形に整えてください。必要に応じてマークダウンファイルを作成し、情報を整備して使いやすく、初期化作業を進めてください。以下は共有された企画書なので、原本をコピーして整理したうえで、内容を読み取ってmdに別途整理しておいて。/Users/minorun365/Desktop/企画書.pptx
上記はサンプルですが、5分ぐらい喋って、これの10倍ぐらいのコンテキストを大量に与えます。
コーディングエージェントはCodexやClaude Codeなど、一定人気のある最新のものなら何でもOKです。私の場合は、執筆中にClaude Codeの性能劣化が酷くなったため、Codexに乗り換えました。
Claude Codeを使う場合、今はOpus 4.6を使うとマシですね。
以下「Codex」と代表して記述します。
構成検討
やさしい編集者の方であれば、目次案の叩きなども出してくれると思いますが、あくまで技術書はその道のプロである著者が構成検討をリードすべきでしょう。
どんな方向性のテーマで、どんな人をターゲットにして、どういった章立てにするか。競合となる既刊は出ているか。類似テーマの書籍の人気度合いはどの程度かなど、Codexに調査させてレポートをまとめさせながら、一緒に壁打ちして案を検討します。
ここでも大事なのは、著者自身が頭の中をしっかり音声入力でダンプしながら、骨格となるプロットをCodexに与えることです。コンテンツ系は、そのテーマの実経験の薄い人がAIに丸投げして作ると、それっぽいけど中身の薄いペラペラな作品になってしまいます。
プロジェクト推進
編集者や共著者と打ち合わせをした場合は、議事をCodexに読み込ませて整理させて、一緒に検討に参加してもらいましょう。
例えばオフラインでの打ち合わせ中、iPhone標準の録音アプリで撮った音をそのまま文字起こしコピーできるので、それをSlackに貼り付けて、議論の途中経過をサクッとマークダウンにまとめさせて、それを引き続きみんなで議論しながらCodexにブラッシュアップさせる、というインタラクティブな会議進行もできます。
作業ディレクトリはGitHubのプライベートリポジトリとして同期し、編集者や共著者も最初から参加してもらいましょう。
原稿執筆
原稿はマークダウンで書くのがおすすめです。途中までGoogleドキュメントなどで書いていた人も、Codexに頼めばMCP（もしくはApps）を使って読み取って、いい感じにGitHub & mdに変換してくれるので移行も簡単です。
見出しのレベル感や執筆ルールなど、DTP上の制約がある場合はrulesに書いておきましょう。（もちろんCodex自身に作成させます）
私の場合は過去の自分の著作のページを何枚かiPhoneで撮影して、その画像をCodexに読ませて「これと同じフォーマットで書けるようにrules作っといて」と伝えます。
人間が唯一がんばる部分「執筆」
中身の執筆は人間が頑張りましょう。商業誌のように高いクオリティを求める場合、まだまだ100%手書きが有利です。
ただし、多少殴り書きでも細かい修正はrulesを使って後でCodexがやってくれます。
さらに、執筆を始める前にはCodexと一緒に壁打ちして、目次案や章ごとの内容構成などをブラッシュアップした上で、それを見ながら書き始めるとスムーズです。
最近、明らかにAIに生成させたな〜みたいな商業書籍増えましたよね。。
貴重な日本の出版業界が読者から見放されないように、著者は手を抜かず頑張りたいものです。
AgentCore本では、最初に考えていた目次案だとAgentCoreの章がヘビーになってきたので、4部構成にして見出しの組み替えなどを大幅に行いました。
こんな作業も従来は超大変でしたが、Codexを使えば楽ちんです。
MCPやスキルを活用する
技術面はWeb SearchやMCPなどで最新のドキュメントを参照させ続けるのは言うまでもありません。
AgentCoreの場合は、ドキュメントの更新すら追いついていなかったり、ドキュメントに誤りがあるケースもたまにあったので、執筆内容に誤りがないか、常にCLIとGUIコンソール（MCPでブラウザ操作）の両方をCodexに自動検証させて裏取りをしていました。
編集者の方がありがたがっていたのが、ページ数の予測スキルです。原稿の超初期の段階で、既刊のフォーマットに照らすと何ページぐらいになる見込み、というのをかなり正確に計算してくれるので、出版前の価格調整などがやりやすかったようです。
原稿に埋め込む画像案も、パワポにスライドを足していき、それをCodexに画像化させてマークダウンに挿入させます。一度成功したら、一連の流れをスキル化させておきます。
レビュー
以前は私もGoogle Docsで原稿を書いて、編集者さんに編集提案やコメントの形でレビューを行ってもらっていました。
Codexと作業する場合はGitHubに集約できると効率がいいので、まずはGitHubの使い方（特にIssueとPRの作成方法）をCodexに手順作成してもらい、編集者の方に共有しました。
各章のレビュー内容は、ざっくりした指示はIssueに、細かいてにおはレベルの書き換え指示などはPRを作成いただくようにしました。
コンビニ行きながらスマホでレビュー対応
レビューに対しての著者対応は非常に楽になります。Codexに「編集さんから新しいレビューが来てるか確認して、レビュー内容と当該章の原稿をすべて読んでから、対応案をBefore/Afterが分かりやすいように一つずつ私に提案して」と伝えます。
そうすれば一問一答形式でレビュー対応が進められるので、移動中にモバイルアプリからでもレビュー対応が進められます。PCでじっくり書き直したい重いものは「後でやるからTo Doとしてメモしといて」と言えばOKです。
サンプルコード
技術書ではサンプルコードやハンズオンも多数作成します。
まずは最新ドキュメントをベースに、読者が理解しやすい最小限のサンプルコードを書いて、それの動作確認まで行うのをCodexにやらせます。コメントの粒度や、コーディングルールなどもrulesを育てながら著者好みにしていきます。
特にハンズオンは要注意で、動作環境とライブラリバージョンを固定しないと初学者が詰まりうるので、私の場合はGitHub Codespacesを使い、ライブラリ系は校了直前の最新バージョンに固定しています。
毎晩Codexに自動テストさせる
バージョンリストはもちろんCodexにまとめさせて、それを著者間で共有して各章に反映チェックをします。
執筆中は日々ライブラリが更新されていくので、毎晩寝ている間に自動でCodexを走らせて、全章のサンプルコードとハンズオンを自動でE2Eテストさせて、朝起きたら問題点のレポートが出ているようにします。
何度もやりたくない初期設定とか、どうしても再現させづらいGUI操作とか、一部は自動テスト用にアレンジしたくなる部分もあるので、この辺はSkillsとして育てていきます。
あと、サンプルコード類はまとめておき、出版直前に読者向けの公開リポジトリとして別途切り出します。
校正
原稿レビューが終わり、マークダウンをDTPへ入稿すると、ゲラ（校正刷り）と呼ばれる紙面デザインに沿ったPDFが上がってきます。
これを見て編集者・著者が「赤字」と呼ばれる修正依頼を入れていきますが、従来はPDFへAcrobatなどのコメント機能を使って、ハイライトを付けたりして修正指示を記入することが多かったと思います。
ゲラPDFへの赤字入れもCodexにやってもらう
Codexを使う場合は、常に原稿マークダウンを最新化する運用にします。
編集者さんは従来どおりPDFに赤字を入れてくれるので、それをCodexにパースさせて、修正指示を原稿mdに反映します。その後、著者が見て気になった点はすべて原稿に反映しておき、最後に原稿とPDFの差分を検出させて、差分をすべてPDFに赤字コメントとして挿入させます。
これもCodexで自動化できます。（Pythonライブラリを使います）
あと、各章のゲラはもちろんCodexに何度もチェックさせて、最新情報との齟齬や、誤植がないかなど確認してもらいました。人間だと絶対気づかないミスも99%摘出してくれます。
面倒ですが章ごとに分けてレビューさせた方が精度が上がります。
閑話休題ですが、校正フェーズ中にClaude Codeの /insights コマンドで私の作業スタイルを分析させたものが以下です。
販促
出版が近づくと、色んな方へ献本をお渡ししたり、Xでキャンペーンを打って特製Tシャツを配ったりなど、プロモーション活動を著者自身も行います。
献本先の管理やヒアリングフォームの作成、Tシャツの発注（配送先ごとに別注文が必要）などもすべてCodexにやってもらいました。個人情報の取り扱いには最新の注意を払うよう、rulesなどでルール化するのはもちろん、1Password CLIを使って一時的に扱う情報もデータとして露出しないように気を付けました。人間が手動でExcel使って管理するよりよっぽど安全に作業できたと思います。
出版後のメンテナンス
技術書の大変なところは、出版後も読者からの問い合わせをいただいたり、技術のアップデートによって急に書籍の内容が古くなったり、サンプルコードが動かなくなったりするところです。
私はCodexのオートメーション（Claude Codeならルーチン）機能を使って、関連ライブラリやドキュメントの更新を毎朝チェックして、問題があればIssueを作成して著者に通知するようにしています。
dependabotが毎日作っていくPRも、読者のハンズオン動線上問題がないものは、自動でマージする作業もオートメーション化しています。
おわりに
こんな感じで2冊並行で本書いてたんですが、普通に死ぬほど大変でしたｗ
私も共著者も、本業はIT企業のエンジニアで、深夜や週末を使って書いているので仕方ないですね。
最高の書籍に仕上げたので、ぜひお手に取ってください！！
上記のノウハウはあくまで一部をざっと書き出したものですが、詳細は機会があれば随時アウトプットしていきます。