AIでKindle本を作れたら、かなり面白いのではないか。
しかも、ただ1冊作って終わりではなく、企画、執筆、編集、出版準備までを流れとして再利用できるようになれば、次の本はもっと速く、もっと安定して作れるはず。そんな期待から、私はAntigravityを使って、実際にKindle本を制作してみることにしました。

結論から言うと、最終的にジャンルの違う2冊のKindle本を公開するところまでたどり着けました。
ただし、最初からうまくいったわけではありません。途中でテーマがズレたり、拡張したはずなのに「本文」ではなく「厚い目次」のような原稿が返ってきたり、修正するたびに別の誤字が混ざったりと、何度も引っかかりました。

そして最終的に分かったのは、AIエージェント運用で本当に大事なのは、「書く役を増やすこと」ではなかったということです。必要だったのは、完成条件を明確にすることと、基準を満たさない原稿を止める役を入れることでした。

この記事では、AntigravityでKindle本を実際に完成させるまでにやったことを、失敗も含めて全部まとめます。（実際に使ったプロンプトは有料で売ります✌時短になるはず。）
これからAIで本を作ってみたい人、エージェント設計で詰まっている人、そして「AIに任せたのに思ったより完成しない」と感じている人には、かなり参考になるはずです。

先に、今回実際に完成したKindle本です

今回、Antigravityを使って実際に完成したKindle本は、こちらの2冊です。

『量子力学×潜在意識で書き換える！どん底から100日で理想を叶える実践メソッド』

『感情の解像度：あなたの「モヤモヤ」に名前をつける技術』

実際にKDPで公開までできました。
しかも、1冊だけではなく、スピリチュアル系と実用書系という別ジャンルで2冊作れたのが大きなポイントでした。

もしKindle Unlimitedに入っている方なら、追加料金なしで読めます。
「AIで本を作るって、実際どんなものができるの？」と思う方は、先に商品ページを見てもらうと、この記事の内容がかなりイメージしやすいと思います。

ここから先では、この2冊ができるまでに何がうまくいかず、何をどう直したのかを、順番に整理していきます。

なぜAntigravityでKindle本を作ろうと思ったのか

最初に考えていたのは、単に「AIで本を書いてみたい」という軽い興味ではありませんでした。
本当にやりたかったのは、Kindle本を作る流れそのものを仕組み化することです。

本を1冊出すたびに、

テーマをどうするか悩む
構成で止まる
本文が浅い
どこまで直せば完成かわからない
KDP入稿が地味に面倒

こういったことを毎回ゼロからやるのは、かなり消耗します。
だからこそ、企画、執筆、編集、出版準備までを分業化し、ある程度再現できる型にしたかったんです。

1冊出すことももちろん大事です。
でも、それ以上に価値があるのは、2冊目、3冊目にも使い回せる制作フローを作ることでした。

最初に考えたエージェント構成

最初に考えた構成は、かなりシンプルでした。

researcher
planner
writer
editor
publisher

要するに、

調べる人
企画する人
書く人
直す人
出版準備する人

この5つがいれば、自然に回るだろうと思っていたんです。

人間である私は、最後に出来上がったものを確認するだけ。
そういうイメージでした。

でも、実際にやってみると、この考え方だけでは足りませんでした。

実際に動かしてみて起きた問題

一番大きかったのは、「それっぽいけど、そのままでは使えない」状態が何度も出てきたことです。

たとえば、

テーマやジャンルが途中でズレる
拡張したはずなのに本文ではなく詳細アウトラインが増える
完成と言われたのに文字数が足りない
修正するたびに新しい誤字が混ざる
奥付や付録に内部用語が残る

こういう問題が、かなりの頻度で起きました。

特に象徴的だったのは、「文字数を増やして」と指示しても、“本文の厚み”ではなく“厚い目次”が返ってくることでした。
見出しは立派。項目も増える。けれど、読者が読む本文としての密度は足りない。これはかなり大きな学びでした。

ここで分かったのは、AIに対して「長くして」「厚くして」と曖昧に頼むだけでは足りないということです。
何字を目標にするのか
各章に何を必ず入れるのか
足りない場合は誰が補うのか
ここまで決めないと、完成度は安定しません。

一番の問題は、エージェント数ではなく品質管理だった

途中までは、「役が足りないのかな」と思っていました。
でも本質はそこではありませんでした。

問題だったのは、
誰も“この状態では次へ進めない”と判断していなかったことです。

researcher は調べる。
planner は構成する。
writer は書く。
editor は整える。
publisher は準備する。

この流れはある。
でも、その原稿が本当に次工程へ進んでいいのかを見る役がいなかったんです。

つまり、

薄くても進む
整合が甘くても進む
誤字が残っていても進む
内部用語があっても進む

という状態になっていました。

ここで初めて気づきました。
必要なのは「もっと書くAI」ではなく、「止めるAI」 だったんです。

改善後に採用したエージェント構成

最終的には、次のような構成に変えました。

controller
researcher
planner
writer
expander
editor
proofreader_qa
publisher

ここで大きかったのは、次の3つです。

controller を入れた

進行管理と品質ゲート管理をする監督役です。
文字数不足や要素不足、テーマ未確定のまま先へ進むことを防ぎます。

expander を入れた

writer だけだと薄い章が出るので、
具体例、失敗例、FAQ、ワーク、補足説明 を足して厚みを出す役を用意しました。

proofreader_qa を入れた

誤字脱字、表記揺れ、数字整合、見出しと本文のズレ、内部用語の残りを見て、
人間に見せる前に止める役です。

ここまで入れて、ようやく「制作ライン」として機能し始めました。

うまく回すために決めた「完了条件」

ここが一番大事でした。
AIは「一通り埋まった」だけで完成と言いやすい。だから、最初から完了条件を決めておく必要がありました。

企画完了条件

読者像が1文で言える
何の悩みを解決する本か明確
本の約束が1文で言える
章構成がある
各章の目標文字数がある
各章に入れる必須要素がある

執筆完了条件

各章が目標文字数の90%以上
導入がある
概念説明がある
具体例がある
ワークや実践要素がある
章末まとめがある

編集完了条件

冗長表現が整理されている
文体が揃っている
重複説明が減っている
見出しと本文の流れが自然
Kindle本として読みやすい

QA完了条件

誤字脱字なし
表記揺れなし
数字整合あり
タイトルと本文のズレなし
著者名、奥付、付録の整合あり
仮置き表現なし
内部用語なし

この条件を入れてから、かなり安定しました。

実際の制作フローはこう変わった

最初から本文を書かせるのをやめて、必ずテーマ確認から始めるようにしました。

流れとしては、こうです。

テーマは決まっていますか？と聞く
未定なら researcher が候補を出す
ユーザーがテーマを選ぶ
planner が企画と文字数設計を作る
writer が各章を書く
expander が足りない部分を厚くする
editor が読みやすく整える
proofreader_qa が止める
QA通過後にだけ human review
publisher がKDP用の準備物を作る

この順番に固定したことで、かなりズレにくくなりました。

実際に使ったプロンプト

今回、最終的に使った親プロンプトはかなり長いです。
でも、要点はシンプルでした。

最初から勝手に本文を書かない
必ずテーマ確認から始める
テーマ未定なら候補提案で止める
文字数と必須要素を先に決める
QA通過前は人間に見せない

実際のプロンプトには、これらをかなり細かく書いています。
特に効いたのは、次の部分でした。

補足ルール:
ユーザーがテーマ未定の場合、最初の返答では本文や構成を出さず、必ずテーマ候補提案に止めてください。
「どのテーマで進めますか？」と確認してから次へ進んでください。

この補足ルールが入る前は、テーマ未定でも構成や本文に寄っていくことがありました。
逆に、これを入れてからは、最初の返答がかなり安定して「テーマ提案モード」になりました。

実際のやり取りを一部抜粋すると、こう動きました

最初にちゃんとテーマ確認から始まった

まず、環境構築が終わったあと、いきなり本文へ進まず、テーマ確認から入りました。

Kindle本のテーマは決まっていますか？決まっている場合：そのテーマを教えてください。未定の場合：「researcher（リサーチ担当）に候補を5つ出してもらう」形で進めてよろしいでしょうか？

ここは、最初に入れたルールがちゃんと効いていた部分です。

researcher がちゃんと候補提案を出した

私が「テーマ：スピリチュアル系の本」と返すと、researcher が市場傾向を踏まえたテーマ案を5つ提案してきました。
しかも、「こんなテーマはどうでしょう？」という形で、想定読者、悩み、差別化まで整理して提案しています。特におすすめとして「量子力学×潜在意識」の案を推してきました。

40,000文字にしたいと言ったら、章配分を再設計した

私が途中で「40,000文字にしてください」と言ったところ、planner は総文字数を再設定し、各章に対して再配分を出してきました。
しかも、「具体例を倍増する」「ワークを厚くする」といった方針まで示してきました。ここは、ただ文字数を増やすのではなく、中身ごと増やす設計に変わった瞬間でした。

章ごとに執筆 → 確認 → 次へ進む流れになった

実際の運用では、いきなり全文ではなく、

序章を書いて確認
第1章を書いて確認
第2章を書いて確認

という形で進みました。
しかも各章ごとに、「writer が初稿を書き、expander が具体例を増やし、controller が Gate B を通過させる」という流れが見えていました。これはかなり安心感がありました。

実際に2冊出して感じたこと

ここまでやってみて、いちばん強く感じたのは、AIに丸投げして完成したわけではなかったということです。

むしろ、人間が違和感を拾いながら、

この役が足りない
ここにゲートが必要
ここは差し戻すべき
ここは人間が最後に見るべき

と、設計を直していったから完成しました。

つまり、今回の成功は「AIが万能だったから」ではなく、
人間が監督役として機能したからです。

そして、今回は1冊ではなく、別ジャンルで2冊公開できました。
これはかなり大きな意味があります。たまたま1冊だけうまくいったのではなく、制作フローとして再利用できる可能性が見えたからです。

これからAntigravityで本を作る人に伝えたいこと

もしこれからAntigravityで本を作るなら、私が最初に伝えたいのはこれです。

書くAIを増やす前に、止めるAIを作った方がいい。

そして、

最初から文字数を決める
各章に入れる要素を決める
不足時の加筆役を入れる
QAが通るまで人間に見せない

この4つを押さえた方がいいです。

AI活用というと、どうしても
「もっと賢いプロンプト」
「もっと書けるAI」
に意識が向きがちです。

でも実際には、完成に効くのはそっちよりも、
品質ゲートと差し戻しルールでした。

最後に

Antigravityは便利でした。
でも、便利だからといって、設計なしで勝手に本が完成するわけではありませんでした。むしろ、自由度が高いからこそ、完成条件と差し戻しルールをきちんと持っていないと、途中でかなりブレます。

一方で、ちゃんと設計すれば、ここまで一連の流れを回せることも分かりました。
次に同じことをやるなら、今回の改善版フローを最初から使います。そうすれば、もっと短時間で、もっと安定して次の本を作れるはずです。

AIに本を書かせること自体は、もう珍しくありません。
でも、完成まで持っていく設計は、まだまだ工夫の余地があります。今回の失敗と改善が、これから挑戦する人の近道になればうれしいです。

ここから先は有料です

ここまでで、

AntigravityでKindle本を作ろうとして、最初に何がうまくいかなかったのか
なぜ「書くAI」だけでは完成しなかったのか
どういう考え方で改善したのか
実際にどんな2冊が完成したのか
どんな流れで動いていったのか

までは、できるだけ具体的に書きました。

ここから先の有料パートでは、実際に私が最後まで使った完成版プロンプト全文と、Antigravityとの実際のやり取りログ全文を掲載します。

今回お渡しするのは、単なる短いプロンプトではありません。
実際に私がAntigravityに投入した、Kindle本制作専用ワークスペースを作るための親プロンプトです。中には、最初に必ずテーマ確認から始めるルール、8つのエージェント定義、品質ゲート、差し戻しルール、workflows設計、そして最後の補足ルールまで含まれています。

さらに今回は、そのプロンプトを入れたあと、Antigravityが実際にどう返答し、どう進み、どう本づくりが進行したのかが分かる実録ログ全文も付けています。ログを見ると、最初にテーマ確認から始まり、researcherが候補を提案し、40,000文字への再設計が行われ、章ごとに執筆と確認が進んでいることが分かります。

つまり有料部分では、
「これを入れればいい」という設計図と、
「実際にこう動いた」という運用例の両方を確認できます。

「自分でもAntigravityでKindle本を作ってみたい」
「でも、ゼロから試行錯誤する時間は減らしたい」
という方には、かなり役立つはずです。

価格は 1,980円 です。

有料部分でお渡しするもの

この有料パートには、次の3つを入れています。

実際に使った完成版プロンプト全文

親プロンプトとして、そのままAntigravityに入れられる形です。
内容には、テーマ確認、候補提案、エージェント定義、品質ゲート、差し戻しルール、workflows、補足ルールまで入っています。

Antigravityとの実際のやり取りログ全文

「本当にこう動いた」が分かる実録です。
最初のテーマ確認、researcherによる5案提案、40,000文字への再設計、章ごとの執筆進行まで、そのまま追えます。

ログの見どころと使い方メモ

どこを見れば再現しやすいか、どの場面が特に重要かを短く解説します。
単にログを眺めるのではなく、「ここを真似すると再現しやすい」 という観点で読めるようにしています。

有料部分｜実際に最後まで使った完成版プロンプト全文

ここからは、実際に私がAntigravityでKindle本制作を最後まで回すために使った、完成版プロンプト全文です。
単なる親プロンプトではなく、テーマ確認、候補提案、品質ゲート、差し戻し、QAまで含めた実戦用の一式です。コピペしてお使い下さい。