0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AsciiDocとAIエージェントで、6週間に28冊を出版した話

0
Last updated at Posted at 2026-08-14

kindle-publishing-with-ai-agents-01.jpg

2026年7月から8月にかけて、Kindleダイレクト・パブリッシング(KDP)[1] で28冊の技術書・実用書を出版しました。この数ヶ月OSSの開発やブログの更新が止まっていたのは、ずっとこれを書いていたためです。近況報告を兼ねて、「何を、どうやって作ったのか」を書き残しておきます。

出版の全体像

出版した内容は「技術系」と「QOL(Quality of Life)系」の2領域です。読者層がほとんど重ならないため、著作は2つのレーベル(名義)に分けています。

  • CyberGarage[2] — 技術書(AI、実践プログラミング、NewSQL、IoT)
  • WellBeing Lab[3] — QOL系(運動・健康・スポーツ)

数字で見る6週間

出版完了日ベースで、2026年7月2日から8月14日までの43日間に28冊をリリースしました。内訳は7月に19冊、8月に9冊です。合計で354章、3,259項目にのぼります。

名義 冊数 章数 項目数
CyberGarage 17 252 927
WellBeing Lab 11 102 2,332
合計 28 354 3,259

冊数ではCyberGarageが多い一方、項目数ではWellBeing Labが2倍以上あります。1冊あたりの構造が全く異なるためで、この差は執筆の粒度設計に由来します。

一番古い企画は3月6日の着手でしたが、前半は手探りで進捗が停滞していました。本格的にシステムが動き出したのは6月下旬からで、28冊のうち13冊はそれ以降に着手・完成させたものです。

技術的な舞台裏(パイプライン設計)

ここからは「どうやって作っているか」のパイプラインの話です。

現在は単一のリポジトリで全体を管理しています。共通処理を行うスクリプトやプロンプトを整理し、書籍カテゴリーごとの固有モジュールを共有化するリファクタリングが完了してから、一気に執筆が加速しました。

1. AsciiDocを一次ソースにする

原稿はすべて、元々OSSプロジェクトで慣れていた、AsciiDoc[4]で書き、Asciidoctor[5]でEPUBに変換しています。採用理由は3つです。

  1. プレーンテキストであること
    git で明確に差分を追えます。「昨日エージェントに書かせた章が、今日どう変わったか」が git diff でわかる環境は、執筆においてもソフトウエア開発と全く同じメリットをもたらします。
  2. AIコーディングエージェントが直接編集できること
    これが決定打でした。専用エディタやバイナリ形式を挟むとエージェントが原稿を直接扱えなくなります。テキストファイルの集合であれば、コードベースを扱うツールチェーンがそのまま転用できます。
  3. EPUB変換の柔軟性
    変換自体はAsciidoctorのEPUB出力[6]を利用していますが、Asciidoctorの仕様補正用スクリプト(約20個)と、KDP特有の仕様に合わせた補正スクリプト(約20個)を挟んで自作補正しています。

2. エージェントの使い分け

WellBeing Lab(QOL系):Codexに一本化

本文も図版もCodex(OpenAI)で統一しています。
当初は工程に応じてCodex、Claude Code、Geminiを使い分けていましたが、現在は全工程がCodexで閉じるように構築しました。章と項目の粒度さえ定義してしまえば、あとは11冊分同じ型の作業が続きます。ツールを増やさず一元化したほうが、手順も出力のトーン&マナーも揃いやすくなりました。

もちろんCodex以外が不可というわけではありません。レスポンスの差分吸収を行えばClaude Code等でも同様に動作します。手順とプロンプトがテキストとして抽象化されていれば、実行エンジン側の差し替えは容易です。

CyberGarage(技術書系):Codex / ChatGPT / Claude Codeの併用

こちらは実際のコードやリポジトリをコンテキストに読み込ませて執筆する場面が多く、対象に応じて適材適所で使い分けています。

なお図版生成については、現時点のCodex経由リクエストでは複雑な画像生成の試行錯誤が難しいため、プロンプト生成バッチを連携させてChatGPT側で生成・取得しています。

3. 1冊が出来上がるまでのオートメーションフロー

上記を踏まえた実際のビルドフローです。型が最も強固に固まっている「WellBeing Lab」を例とします(技術書側も辞典系はこの簡略版で動きます)。

Step 手順 実行主体 判断の所在
1 カテゴリーを決め、設計の2ファイルを生成 コマンド
2 骨組みを生成し、空のままEPUBビルドを通す コマンド
3 章ごとの検索クエリで論文候補を集める コマンド
4 候補論文の採否を決める コマンド プロンプト
5 採用分を本文側に取り込み、重複を判定 コマンド
6 本文を生成する(画像なし) コマンド
7 重複チェックと文体・表記のlintを実行 コマンド
8 レビュー用の監査表を出力 コマンド
9 代表の選定、章移動、並び順を調整 コマンド プロンプト
10 画像生成、余白・アスペクト比の正規化 コマンド
11 章内の要素を並べ替える コマンド
12 EPUBを生成する コマンド
13 通し読みを行い、残った重複を整理する コマンド プロンプト

全13工程の実行はすべてコマンド経由です。
人が手動で決定するのは「最初にカテゴリーを決める部分」のみ。あとはエージェントの利用制限を確認しながらコマンドを順次叩いていくだけです。人が実行する判断プロセス自体をプロンプト化したことで、エージェントによる自動判断が非常に安定しています。

制作期間が「141日」から「5日」に短縮

判断基準の言語化(プロンプト化)が完了した6月下旬を境界に、リードタイムには圧倒的な差が現れました。

  • 3月着手の初期5冊 — 平均 141日
  • 6月下旬以降に着手した13冊 — 平均 19日
  • 最短記録

最初に執筆した『毎日を整えるエビデンス習慣』は手作業の修正が多く難航しましたが、最終的にはこの新フローで全文章を再生成して出版にこぎつけました。

なお、WellBeing Lab側ではCodexの推論オプションをHigh(model_reasoning_effort="high")に設定して生成しています。各巻250アイテムほどを生成するとChatGPT Proの2週間分のレート制限枠を使い切るほどの計算リソースを消費します。制限や頻繁なリセットタイミングを見越し、バッチを効率よく回す運用を行いました。

おわりに

CyberGarage側では、現在C言語、Go言語、そしてNewSQLに関するプロフェッショナル向け書籍を執筆中です。初心者向けではなく、実務で高度に扱うエンジニアに向けた骨太な内容を目指しています。WellBeing Lab側は執筆フォーマットが完全に定型化できたため、今後は関心のあるテーマから順次書籍化していく予定です。

ここ半年ほどは出版プロセスに注力していたため、オープンソース(OSS)活動の手が止まっていました。ビルドパイプラインが完成し1冊あたりのコストが劇的に下がったので、これからは書籍の運用ペースを調整しつつ、再びプログラミングとOSS開発に軸足を戻していきたいと考えています。


0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?