Yyatmita

Claude Code に技術書 1 冊書かせて、人間がやった仕事だけ残った

AI 画像生成の逆引き本 28 章 + 付録 2 章を Claude Code に書かせた記録。構造変更・実装乖離の自己検出・横串校正・別 AI への評価委託——分業の輪郭が見えた

Claude Codeサブエージェント検証#claude-code#writing#workflow#agent#tech-book

技術書を 1 冊書こうとしている。AI 画像生成・編集の逆引きレシピ本で、Gemini API・OpenAI gpt-image-2・ComfyUI・PIL の knob 集。手を動かしているのはほとんど Claude Code で、私はディレクションと赤入れに回っている。

書き終わってみて、面白いことに気づいた。人間がやった仕事のリストを取り出すと、それが「Claude Code に書かせるときの分業の輪郭」になっていた。

今回はその輪郭を、実際に踏んだ作業のスナップショットで残す。本の中身ではなく「本を書く工程の中で、人間と AI のどちらが何をやったか」の話。

何を書いていたか

AI 画像生成・編集の逆引きレシピ ─ Gemini API・OpenAI gpt-image-2・ComfyUI・PIL でやれること全部

28 章 + 付録 2 章。30 話以上の漫画を AI で量産する中で組み上げた knob 集を、「キャラの顔がコマごとに変わる」「既存コマだけ部分修正したい」「月コストを ¥500 以下に抑えたい」みたいな逆引き構造にまとめたもの。

執筆者の本番運用プロジェクト（manginus というオレオレ漫画エディタ）の実コードと実プロンプトを根拠にしている。「実体験ベース」を売り物にする以上、嘘は書けない。この制約が、後で効いてくる。

1. 構造変更：「page 1 で 9 割脱落する」を直した

最初に Claude が書いた §0 は「API リクエストの基礎」だった。料金表、SDK セットアップ、表記凡例、ディレクトリ構成。技術書として真っ当なオープニングだ。

でも私はこれを見て言った。「1 ページ目で 9 割脱落すると思うんだけど」

これは執筆者の直感の話で、データではない。技術書を買った人間が最初に開いて「料金表」を見せられたら、本のテンションが伝わる前に閉じる。買う前のサンプル表示でこの章が出るなら、買わない。Zenn の本は最初の章を free に設定する慣習があるから、特にそうだ。

Claude はこの指摘を受けて、§0 を「本書で何ができるようになるか」に書き換えた。

  • 巻末ショーケース（§97）から証拠の品 4 つを先出し
  • 演出例 4 つの完成画像をいきなり見せる（回想コラージュ・表紙合成・LINE スタンプ・縦リール）
  • 「読み終えたら何ができるか」の約束 7 個（¥25/話、キャラ顔固定、コスト管理、etc.）
  • 6 パートの構成マップ

そして元の「API リクエストの基礎」は §0b に分離して free: true のまま残した。買う前の読者にも、買った後の読者にも、両方に正しい順序で見せる構造になった。

ここで起きたことを整理する。

  • 直感を出したのは人間。「page 1 で 9 割脱落」は数字ではなく、自分が読者だったらどう感じるかの話。
  • 判断を裏付ける構造に変えたのは Claude。hook 章と setup 章の分離、Zenn の free: true 慣習との整合、ショーケースの先出しという具体策。
  • 私は「変だ」と言うだけで、Claude が「ならこう変える」と返してくる。指摘は短く、変更は大きい——これが構造変更の分業の感触だ。

2. 実装乖離：「嘘書くわけにはいかないだろ」

§4 は本の中核章で、フルリクエストの統合例。プロンプトの書き方、ref 画像の渡し方、Python コードでの組み立てを示す。

Claude が書いた §4 は、英語の散文プロンプトをメインに据えていた。

A young woman with black hair, wearing a school uniform,
standing in a Western-style salon, holding a magic wand...

読みやすいし、技術書らしい。でも私には引っかかった。

なんかプロンプト例にアートスタイルとか出てないけどほんとに正しいのこれ

Claude は「manginus 実装と整合させてます」と返してきた。私は重ねて言った。

そんなプロンプトだっけ？／ ちょっとどこか仮にプロンプト dry-run してみて

Claude が GET /api/nemu/prompt/1/1 で実際のプロンプトを引いてみた結果、全然違うものが出てきた。

  • 構造化された日本語プロンプト
  • 【ルール】 【場面の指示】 【制約】 のヘッダで区切られた Jinja2 テンプレート
  • 英語の labeled refs（Reference images for X — SOURCE OF TRUTH...）が後段に並ぶ
  • アートスタイル文字列が「スタイル」フィールドに差し込まれる

§4 に書いてあったものと、本番のプロンプトは別物だった。Claude は「本書は実コードに基づく」と謳う章で、実コードと違う例を書いていた。

私が言ったのはこれだけだ。

どうしますか／ って嘘書くわけにはいかないだろ

そこから先は Claude が prompt_builder.py と nanobanana-color.j2 を読み直して §4 を全面書き直した。さらに §0 / §23 / §98 / §99 にも同じ整合性チェックをかけて波及させ、art_style の説明文を「プロンプト末尾に追加」から「『スタイル』フィールドに差し込む」に修正した。

ここでの分業はもっと不思議な形をしている。

  • 嘘の検出は人間がやった。ただし「これ嘘じゃない?」と聞いただけで、根拠を示したわけじゃない。
  • 嘘の検証は Claude がやった。GET /api/nemu/prompt/1/1 を叩いて実プロンプトを取り出し、自分が書いた例と比較して「違いますね」と認めた。
  • 修正と波及も Claude がやった。一度直したら、同じ嘘が他の章に染み出していないか全章スキャンするのは Claude の方が速い。

人間がやったのは「何かおかしい気がする」を声に出すこと。それだけで、Claude が自分の嘘を自力で潰しに行った。これは技術書の品質保証として、思っていたより重要な仕事だった。

「Claude は嘘をつく」という話はよく出る。でも今回の発見は逆方向で、Claude は人間が「嘘じゃない?」と一言かけるだけで、自分の嘘を自分で検出して直せるということ。検出自体は人間でないとできないけれど、検出から修正までの距離は短い。

3. 横串校正：156 件の参照と 34 件の TODO

本文中に §4 §22 のような章間参照が 156 件あった。これは執筆中に手書きで打ったもので、Markdown のリンクにはなっていない。

執筆が進んだあるタイミングで私が言った。「そういうのってリンクにすべきじゃないの」

Claude は regex スクリプトを書いて、156 件全部を一括変換した。

SLUG_MAP = {0: "00-foundation", 1: "01-character", ..., 99: "99-appendix-b-checklist"}
REF_PATTERN = re.compile(r"(?<![\[\d])§(\d+)(?!\d)")
# §4 → [§4](04-rich-prompt)

スクリプト自体は単純だが、156 件を手で直すのは現実的じゃない。Claude は数秒で全章スキャンして書き換え、その後リンクが正しく解決するか別の章に飛べるか目視確認まで自動でやる。

似たような作業がもう一つあった。本文中に「ここに動画を入れたい」「ここに比較画像を入れたい」みたいな TODO ブロックが 34 件あった。最初は Zenn の :::message ブロックで書いていたが、これだと読者にも見えてしまう。

私「じゃあコメントにして」

Claude は別の regex スクリプトを書いて、34 件を <!-- MEDIA-TODO ... --> HTML コメントに変換した。読者には見えず、エディタからは grep で拾える状態。

PATTERN = re.compile(r":::message\s*\n((?:.*\n)*?.*MEDIA-TODO.*\n(?:.*\n)*?):::\s*\n", re.MULTILINE)

このとき副作用として TODO の ID が [m-§04-01] から [m-[§4](04-rich-prompt)-01] に二重リンクされて壊れた。Claude が気づいて fix_media_todo_ids.py を書いて元に戻した。

横串校正の分業はこうなっていた。

  • 「気持ち悪いところ」を指すのは人間。リンクになってない参照、見えてしまう TODO、形式の不揃い。
  • 横断スキャンと一括変換は Claude。regex を書いて、走らせて、副作用を検出して直す。
  • 人間は数秒で「変だ」と言える。Claude は数分で 156 件直せる。この非対称性を分業の単位として使う。

4. 図版生成：PIL で 9 枚の証拠の品

§0 のショーケース 4 演出を書くにあたって、画像が必要になった。回想コラージュ・表紙合成 2x2・LINE スタンプ 3x3・縦リール before-after。本書のレシピで作れることを示すための図版。

私はこう言った。「画像は？」

Claude は /tmp/build_book_images.py を書いた。PIL で:

  • 既存漫画ページから過去コマをシャッフル循環で配置 + セピア化（コラージュ）
  • 表紙テンプレートに 4 巻分の rembg 済みキャラ + タイトル文字 + シャドウブラー（表紙グリッド）
  • LINE スタンプ規格 370×320 にフィットさせて白縁 4px + 黒縁 1px の二重縁（スタンプグリッド）
  • 16:9 元コマを 9:16 に PIL pad → 元画像貼り戻し（リール before-after）

これに加えて 3 面図のサンプル、flashback 4 段階、outline 4 variants、usage-summary terminal screenshot、cover.png の 5 枚も。合計 9 枚を 1 ファイルのスクリプトで生成した。

図版生成の分業も少し変わっていた。

  • 必要な絵を指定するのは人間。「ショーケースに 4 つ要る」「reel は before-after で見せて」。
  • 絵を作るのは Claude。素材集めから合成スクリプトまで全部。手が動かない私は、出てきた画像に赤入れするだけ。
  • 1 枚目で「この演出は実装できる」と Claude が証明する。絵を出す側のハードルが、人間には高すぎるから、ここの分業は完全に AI 側に振った方がいい。

途中で素材選定のミスもあった。コラージュの素材を最初は別シリーズの漫画から探したが、ページ画像の構成が合わなかった。「ブッダイズム ep01 の方を使おう」と私が指定し直して、Claude が素材ディレクトリを切り替えた。素材選定は人間の仕事として残った。

5. 別 AI への評価委託：NotebookLM

書き終わって章間参照もリンク化して図版も入った段階で、私は Claude にこう言った。

内容がいまいちだからもう少し詰める

これは Claude には判断できない問題だ。Claude は自分が書いた本の「全体としての凡庸さ」を検出できない。書きながら章ごとに整合性チェックは効くが、「読み終えた後に印象に残るか」「30 話量産の重みが伝わるか」「他の AI 画像生成記事と比べて差別化されてるか」は、書いてる本人には見えない。

そこで NotebookLM に投げた。

NotebookLM は Google の AI 駆動研究ツールで、ドキュメントをアップロードすると要約・批評・横断分析をやってくれる。28 章 + 付録 2 章を全部投入して、別の AI に「この本の弱いところはどこか」を出させる。

評価委託の分業は明確だった。

  • 執筆と内部整合性チェックは Claude（書く側）。
  • マクロ視点の批評は NotebookLM（読む側）。
  • 批評を取り入れて書き直すのは Claude（書く側）。
  • 人間は「別の AI に見せた方がいい」と判断するだけ。

書く AI と読む AI を分けるのは、人間の校正ループでも同じことをやる（書いた人と編集者は別人）。AI でも同じ構造が成立する。Claude は自分が書いたものを Claude として読むことしかできないから、別 context・別モデルに通すと違う指摘が出る。

まとめ：人間がやった仕事のリスト

通しで振り返ると、私が実際にやったのはこれだけだった。

  1. 「page 1 で 9 割脱落する」と言った（構造変更のトリガー）
  2. 「嘘書くわけにはいかない」と言った（実装乖離検出のトリガー）
  3. 「リンクにすべき」「コメントにして」と言った（横串校正のトリガー）
  4. 「画像は？」と聞いた（図版生成のトリガー）
  5. 「内容がいまいちだから詰める」と言った（評価委託のトリガー）
  6. 素材ディレクトリを指定し直した（素材選定の一部）
  7. 書かれた本文と図版に赤入れした（最終チェック）

これらは全部「Claude には判断できないこと」だ。読者がどう感じるか、嘘になっていないか、形式が揃っているか、絵が必要か、別 AI に見せるべきか——どれも、本を書いている本人（Claude）からは見えない。

逆に Claude がやった仕事のリストを取り出すと、**「人間がやると数時間〜数日かかること」**で埋まっている。

  • 28 章 + 付録 2 章のドラフト執筆
  • 156 件の章間参照のリンク化
  • 34 件の TODO ブロックの HTML コメント化
  • 9 枚の合成画像の生成スクリプト
  • 全章を横断する整合性チェックと波及修正
  • regex スクリプトの即書きと走行

人間 1 人で全部やったら、書き始めから NotebookLM 投入までで数週間は飛ぶ。今回は 1 セッションで終わった（実時間でも数時間程度）。

学び

技術書を Claude Code に書かせる、という言い方は実は不正確で、正しくは 「人間が Claude Code に方向を与え続けると、本が出てくる」 だった。方向は数文字の指摘で出せる。「嘘」「リンク」「画像」「いまいち」。

エージェント活用の観点で重要だったのは:

  1. 指摘の語彙を切り詰める——「変だと思う」「嘘だと思う」「足りない」だけで、Claude が根拠を取りに行ってくれる。長い説明は要らない
  2. 横断作業は全部 Claude に振る——156 件のリンク化、全章スキャン、副作用検出。1 件あたり数秒の作業を Claude が並列処理する
  3. 検出は人間、検証は Claude——「嘘じゃない?」と聞くだけで、自分の嘘を自分で潰しに行く。検出ハードルが極端に低い
  4. 書く AI と読む AI を分ける——マクロ視点の批評は別モデルに通す。同じ AI で書いて読んでも盲点は埋まらない
  5. 絵と素材は完全に AI 側に振る——人間に手を動かす能力がない領域は、最初から委任する方が早い

人間がやるべき仕事のリストは、思っていたよりずっと短い。けれど、そのリストに乗らないと本が出てこない。短い指摘 5-7 個が、本 1 冊を出すための原動力だった。

本そのものは、まだ手元保管。Kindle で集客が育ったタイミングで note に出す予定。記事のレシピは note 用に再構成して 3 分冊（PIL 編 無料 / ComfyUI 編 / API 編）に組み直す。それまで、執筆フェーズで踏んだ分業の輪郭だけ先に置いておく。