AI genuinely saved me when releasing my book on KDP
Last time I ended on a harsh note: “editing in Japanese was, in the end, just a bit easier.”
This time, the pendulum swings properly back. In the practical work of getting the book onto Kindle (KDP), generative AI genuinely saved me.
Same AI, so why did it land so differently? That’s what this post is about.
Actually, this was my “second” time with KDP
I’ll confess: publishing on KDP wasn’t my first time. I’d already done it once, a long time ago.
But that experience turned out to be completely useless. I’d long since forgotten the procedures, and more importantly, the specs and standards had changed completely in the meantime. EPUB conventions, paperback submission requirements, tax matters — all of it was a different world from back then. My “experienced” past knowledge, as it turned out, was almost entirely useless.
…Thinking about it, this is a bit like my protagonist, who gets thrown into the past with future knowledge but can’t fight as-is with it — I wryly noted this as I wrote. In the end, there’s no choice but to re-access the correct answer for this exact moment, each time. And that’s exactly where AI showed its true strength.
AI’s “effectiveness” was reversed between editing and publishing work
What didn’t work in the editing phase last time was judgment that ultimately depends on human sense — “is this Japanese acceptable or not”. The KDP release work, on the other hand, is an entirely different kind of task. The procedures are fixed, there’s a lot to research, and there are pitfalls — in other words, it’s mostly about “the steps and research needed to arrive at the correct answer.” This was AI’s home turf.
Specific things AI helped with
① Building the EPUB conversion pipeline The manuscript was in Markdown. I converted it to EPUB using Pandoc, and having AI work through the settings and command structure with me made a huge difference.
② Troubleshooting validation The entry point for this phase was actually a casual question: “Can EPUB checking be done with a smartphone app?” The answer that came back: smartphones are fine for viewing, but validation is strict, so a PC is safer before publishing. When I followed up with “I’m on a Mac, what should I use?”, the tools got organized by purpose right there.
- Use pagina EPUB-Checker / EPUBCheck (via Homebrew) to eliminate spec errors
- Use Kindle Previewer 3 to check how it looks on an actual device
- For Japanese-specific checks (characters outside the JIS range, tate-chu-yoko, etc.), use the Denshi Lab Checker
Being able to distill this into a three-stage flow — “①spec check → ②device preview → ③KDP submission” — made a big difference. Every time an error came up, AI helped me sort out “what this is and how to fix it,” and the time I would’ve spent wandering official documentation alone disappeared almost entirely.
③ KDP-related administrative work – Understanding W-8BEN (a US tax document) – Designing the product description (up to 4,000 characters), keywords, and category – Sorting out KDP Select (exclusive) vs. non-exclusive → Ultimately landed on a hybrid of KDP plus partial free serialization on Narou/Kakuyomu
④ Cover production workflow I created a base with AI image generation (Nano Banana), then layered typography on top with Canva. This included working through prompt construction and creative direction together with AI. That said, when it comes to this cover, it wasn’t simply a matter of being “helped” by AI — I wrestled with it quite a bit, and thought seriously about copyright too. I’ll write about that in depth next time.
What actually helped me most was the “physical book”
I’d only planned to do the ebook, but greed got the better of me and I made a paperback version too. And this turned out to be the area where I would have absolutely broken down if I’d been alone.
- Cover submission data: KDP demands, down to the millimeter, a “wraparound cover” where the front, back, and spine are joined into a single sheet. I built this from scratch using Python (PIL).
- Trim size odyssey: I initially tried a shinsho-size format, gave up because it didn’t suit horizontal writing, tried B6, and finally settled on A5. I learned that KDP’s printing cost is determined by page count and ink, so A5, which let me fit more characters per page, ended up being the cheapest option.
- Battling mysterious errors: When I typeset the body text with Pandoc + LuaLaTeX, long strings of alphabetic characters like player names and club names caused lines to overflow (overfull
\emergencystretch). I fixed these one by one, by stretching\emergencystretchand enabling English hyphenation. - This extended to designing the spine text and handling line-start prohibition rules (preventing punctuation from appearing at the start of a line) in the back-cover description.
This kind of work — unglamorous, technical, the kind where getting stuck can eat a whole night — is exactly where running alongside AI paid off on a completely different scale. You know what you want to do, but you can’t proceed because you don’t know the conventions — AI closed that gap in an instant. This is an entirely different kind of effectiveness from the “quality of Japanese” I talked about last time.
The final boss was “page count = cost”
Once I’d stamped out the typesetting glitches, the last thing standing in my way was printing cost. Roughly speaking, KDP paperback pricing goes up as page count increases. If I could just cut another dozen-odd pages, the cost would drop a notch, and I found myself in a final battle over mere yen.
The line spacing was already at its limit. Tightening it further would ruin the reading experience. That’s when I noticed the “airiness” of web-novel style. That style of breaking into a new paragraph at every line of dialogue or description turns, on paper, into nearly 10,000 “gaps between paragraphs” — and each one of those gaps quietly ate away at the page count.
What worked here was, instead of having AI calculate it on paper, repeatedly doing “actually typeset it, and count” over and over. The conclusion I arrived at through testing was a bit shocking: without touching the line spacing by even a millimeter, just by tightening the spacing between paragraphs, the page count dropped by more than 30%. In short, it amounted to shifting toward the kind of typesetting Japanese bunko paperbacks have long used — indentation only, no blank lines. Combined with reconsidering the trim size, the physical book, which had originally run to nearly 550 pages, was ultimately compressed down to the 210-page range — less than half.
One thing that quietly mattered a lot was keeping the typesetting builds for the ebook (EPUB) and the print version (PDF) separate from the start. Thanks to that, the typesetting I packed tightly for the sake of print costs didn’t ruin the reading experience of the ebook at all. The optimal typesetting changes depending on the medium. This was a lesson that sank into my bones after putting out just one book.
So where does AI actually work, and where doesn’t it?
Having written this across posts 3 and 4, here’s my own conclusion:
- The core of the work (quality of Japanese, creative judgment) … In the end, this comes down to the human. AI only makes it “a bit easier.”
- The hassle surrounding that core (logistics, research, conversion, troubleshooting) … Here, AI is overwhelmingly fast.
In other words, AI showed its true strength less in “the story itself” than in “the road to getting the story out into the world.” That’s the feeling that clicked into place for me most, after putting out one book.
Next time: the story of how that cover came to be. I’ll write about the conflicts unique to an AI-generated cover, and the unavoidable copyright considerations.
Originally published in Japanese at https://clazytech.com/2026/06/1648/. Translated with LLM assistance and reviewed before publication.