4/8 22:40 に開始して、4/9 08:33 に終わった。
全11章 + あとがき、約2,000行。人間（自分）の発言は合計約15回。内訳の大半は「次」「はい」「１」の1〜2文字だ。
「AIに本を書かせた」とき、人間は何をしたのか。その全工程を記録する。
今回使ったのは4体のエージェント構成だ。
CEO — 全体の指示・調整（人間が兼任してもOK）
writer — 執筆担当
reviewer — ファクトチェック・技術整合性の確認
reader — ターゲット読者のペルソナを設定して感情面をレビューする（後から追加した）
CEOが各エージェントに指示を出し、結果を受けて次の指示を出す。人間はCEOに方向性を伝えるだけだ。
第1節: まずネタ帳を作った
執筆を始める前に、CEOエージェントがネタ帳（187行）を作成した。10章分の構成案と、各エピソードの出典が明記されたマークダウンファイルだ。
実物を一部抜粋する。
### 第3章: 最初の成功体験
- [ユーザー発言] 「おはよう、今日のタスク見せて」から10分で朝のルーティンが完成
- [内部ログ] GTDの説明を「1分で分かる版」に圧縮
### 第4章: AIチームとの付き合い方
- [内部ログ] CEOエージェントが各担当エージェントに指示を渡す構成
- [エージェント提案] writerが「ここはエピソードより数字で示した方が刺さる」と提案
出典の種類は3つ: [ユーザー発言]（自分が実際に言ったこと）、[内部ログ]（git logやレポートから確認した事実）、[エージェント提案]（エージェントが提案したこと）。これを付けておくことで、後工程のファクトチェックが機能する。
ネタ帳が完成したあと、researcherエージェントに評価を依頼した。初期評価は B+。「タイトルが弱い」「Tips章を独立させる形式を検討せよ」という指摘を受け、修正後に A-（このプロジェクトでの執筆GO水準）まで上がった。書き始める前に構成の弱点を潰すのがこの手順の目的だ。
並行してresearcherに収益化プラットフォームの調査も依頼した。367行のレポートで5プラットフォームを比較した結果、noteが最適という結論が出た。この段階で自分が判断したのは1文: 「noteメインで行こう」。
第2節: 11章を一気に書いた
ネタ帳の承認後、執筆が始まった。時系列はこうだ。
| 時刻 | 内容 | コミットID |
|---|---|---|
| 23:59 | 第0〜1章完成 | 54bd4fe |
| 00:12 | reviewer指摘を反映 | 8973e20 |
| 01:10 | 第2〜3章完成 | 4dc58f8 |
| 01:19 | 第4章完成 | b03f0d2 |
| 04:29〜05:14 | 第5章〜あとがき（6章を45分で） | — |
各章の制作サイクルはこの6ステップで回した。
CEO: ネタ帳の該当章をwriterに渡す
→ writer: 執筆
→ reviewer: ファクトチェック
→ reader: 読者感情の評価
→ writer: 指摘を反映
→ コミット → 「次」で次章へ
自分が各章の間にやったことは「次」の1文字だ。
readerは品質向上のために追加したエージェントで、最初から必須ではない。
1章あたりの平均時間は7〜8分（執筆 + レビュー2回 + 修正込み）。第5章〜あとがきの6章を45分で書いた実績から逆算した数字で、コミットタイムスタンプに裏付けがある。なお、この数字はネタ帳が事前に完成している状態での執筆フェーズのみの時間だ。ネタ帳作成から含めた全工程は後述する。
第3節: 品質を上げた
全章が完成したあと、品質改善フェーズに入った。
まず、reviewerが全章を横断的にファクトチェックした。5件の事実誤りを発見した（コミット 171892d）。どれも執筆段階では見落とされていた、章をまたぐ記述の矛盾だ。
次に、読者ペルソナAIが評価した。初回スコアは 60点。60点は読者ペルソナ（38歳・非エンジニア）による主観評価だ。主な減点は「SE歴26年の人だからできたのでは（-15点）」「セットアップが重い（-8点）」「1週間で6本は嘘くさい（-5点）」。この指摘を受けて全章に失敗談を追加し、「SEスキル不使用」のフォロー文を各所に入れた。修正後に新しいセッションで再評価して、最終スコアは 78点 になった。
読者ペルソナによる批評がどのように機能するか（ペルソナ定義・批判的モード・指摘の粒度）については、AIにAIの書いた文章を批評させたら60点だった話で詳しく書いている。
そして自分が全章を通読して、20件のフィードバックを出した。
「CLAUDE.mdって読者に伝わらない。『AIへの指示メモ』に統一して」
「CEOって書いてあるけどマネージャーにして」
「フロントマター全章から削除して」
これらはどれも「判断」だ。用語をどう統一するか、読者に何を見せて何を隠すかを決めた。修正の実行はwriterエージェントが一括でやった。
reviewerの最終チェックはA判定（公開可）が出た。その後、この通読フィードバック20件をwriterが反映した後の再レビューでB判定に下がったため全件修正して、改めてA判定を取った。
第4節: タイトルを変えた
当初のタイトル案には「SE歴26年」が入っていた。researcherに市場調査を依頼し、10案以上の候補が出た。自分は「B2ベースで、SE歴は入れない」という方針と候補選択の2回の判断で確定させた。タイトル決定に使った自分の発言は3文だ。
方針は2つだった。「2日間で本を書いた」という事実を前面に出すこと、「SE歴26年」は入れないこと。後者はターゲットをエンジニアに絞らないための判断だ。
第5節: 人間は何をしたのか
全工程を振り返ると、自分がやったことは7つある。
- テーマの方向性（「noteで非エンジニア向けの本を書きたい」）
- プラットフォーム選定（「noteメインで行こう」）
- 事実確認（ネタ帳の出典が正しいか検証）
- 進行指示（「次」など）
- 通読フィードバック（20件の用語・表現指示）
- レビュー指摘の取捨選択（「１削除、２対応」「3－7対応」）
- タイトル選定（「B2ベースでSE歴は入れない」）
共通点がある。全て「判断」と「選択」だ。実行は1行もやっていない。
本の中に「何をやらないかを決めるのが人間の仕事」という一節を書いた。書きながらそれが体現されていた。
第6節: このプロセスを再現するには
ここからはClaude Codeを実際に使う人向けの再現手順です。仕組みの面白さだけ知りたい方はまとめへどうぞ。
まず3体から始めればいい。
- CEO（自分が兼任しても可）
- writer
- reviewer
readerは品質をさらに上げたくなったタイミングで追加すればいい。writerとreviewerの2体だけでも本は書ける。
Claude Code の動かし方をより体系的に学びたい場合は、技術評論社の実践Claude Code入門が参考になる。エージェント定義の設計からスペック駆動開発まで網羅されている。
ディレクトリ構成はシンプルだ。
.claude/
├── agents/
│ ├── writer.md # 執筆担当の定義
│ ├── reviewer.md # レビュー担当の定義
│ └── reader.md # 読者ペルソナ（後から追加）
└── CLAUDE.md # プロジェクト全体の指示
drafts/
└── ネタ帳.md # 出典付きで構成を書く
ネタ帳は出典付きで書くのがポイントだ。初期設定はCLAUDE.mdと.claude/agents/にファイルを数個置く程度で済む。コードは不要で、所要時間は30分〜1時間だ。
各エージェント定義の最小サンプルはこうだ。
# writer.md の最小サンプル（5行）
name: writer
description: 記事・ドキュメントの執筆担当
tools: Read, Grep, Glob, Write, Edit
ネタ帳に従って記事を執筆する。文体はターゲット読者に合わせる。
# reviewer.md の最小サンプル（5行）
name: reviewer
description: ファクトチェック・技術整合性の確認
tools: Read, Grep, Glob, WebSearch
記事のファクト・整合性・法的リスクをチェックする。指摘は必須/推奨/任意の3段階。
この2ファイルを .claude/agents/ に置くだけで、writerとreviewerが使えるようになる。CLAUDE.mdには次のように書けばいい。
# CLAUDE.md の最小サンプル
記事を書くときはwriterエージェントに依頼する。
完成したらreviewerエージェントにファクトチェックを依頼する。
コーディング知識は不要。日本語の指示だけで動く。
### 第1章: タイトル
- [ユーザー発言] 実際にあったこと・言ったこと
- [内部ログ] ファイルや履歴から確認できる事実
- [エージェント提案] エージェントが提案したこと
これがあると、reviewerのファクトチェックが機能する。出典なしで書くと、ファクトチェックは文体のチェックにしか使えない。
時間のROIはこうだ。
| 方法 | 1章あたり（執筆フェーズのみ） | 備考 |
|---|---|---|
| 手動（筆者の過去実績） | 2〜4時間 | 調査+構成+執筆+推敲（全工程） |
| このフロー（執筆フェーズのみ） | 7〜8分 | ネタ帳完成後の執筆+レビュー+修正のみ |
| このフロー（ネタ帳込み・全工程） | 約25分 | ネタ帳作成+評価+執筆+レビュー |
ネタ帳の作成と評価を含めると、1章あたり約25分（全11章を約5時間で完成）。「7〜8分」はネタ帳が揃った状態での執筆フェーズのみの数字だ。公正に比較するなら25分の方を使うべきだが、それでも手動の2〜4時間に対して大幅な短縮になる。手動なら数週間のスパンになる作業量だ。
うまくいかなかったことも書いておく。
readerの初期評価が60点だったのは予想外だった。reviewerがA判定を出した後でも、読者視点では60点だった。「技術的に正確」と「読者に刺さる」は別の軸だ、というのが身に染みた。
reviewerのA判定が覆ったケースもあった。reviewerがA判定（公開可）を出した後、ユーザーが再レビューを指示した。するとch01に「画像も作れます」というファクト誤りが見つかった。Claude Codeは単体で画像生成できないのに、「話しかけるだけで画像も作れます」と書いていた。reviewerが見逃し、再レビューで発見された。セクションごと削除して対応した。
ネタ帳の出典管理も最初は甘かった。ネタ帳に書いたエピソードの出典が曖昧で、執筆後のファクトチェックで5件の修正が必要になった。出典を3種類（ユーザー発言・内部ログ・エージェント提案）に分けたのはこの失敗から生まれた運用だ。
品質改善フェーズ全体で約2時間かかった。執筆5時間に対して4割近い時間を修正に費やした計算になる。品質は一度の評価で固定されない。
今後の改善候補は、readerペルソナを複数化すること（現在は1ペルソナ）と、ネタ帳段階でreaderにレビューさせること（構成の問題を執筆前に潰す）の2点だ。
実際にこのプロセスで出来上がった書籍については、コードを書けない私が、AIに「チーム」を持たせるまで——Zenn Books ローンチ告知で紹介している。
まとめ
2日間で本を書いた。数字をまとめる。
| 項目 | 数値 |
|---|---|
| 人間の発言回数 | 約15回 |
| AIの出力行数 | 約2,000行 |
| レビュー回数 | 30回以上 |
| 調査レポート | 3本（うちプラットフォーム比較367行） |
| タイトル候補 | 10案以上 |
| 人間の最長発言 | 20件のフィードバック（通読後） |
AIチームがやったこと: 執筆、レビュー、調査、候補生成。人間がやったこと: 方向性の判断、選択、事実確認。
「AIに仕事を任せる」の最も純粋な形は、判断と選択に集中することだと今は思っている。
同じ書籍制作の舞台裏を、36時間の時系列で語った姉妹記事もある。→ 9体のAIエージェントと電子書籍を2日で作った話
なお、この作業はClaude Code の Max Plan以上のプランで実施した。プラン別のコスト感は別記事（claude-code-ai-editorial-team）で触れている。
なお、このプロセスはSEのスキルや開発経験がなくても再現できる。実際に自分がClaude Codeを使うときはコードを1行も書いていない。エージェント定義ファイル（.claude/agents/*.md）はMarkdownで書いた日本語の指示書で、Pythonの知識もターミナル操作の習熟も不要だ。Claude Codeを日本語指示だけで使う入門ガイド（公開準備中）では、ゼロからのセットアップ手順を詳しく書いた。
Claude Code を本格的にプロジェクトへ導入したい場合は、実践Claude Code入門（技術評論社）の紙書籍版も参考になる。マルチエージェント運用の設計パターンが詳しく解説されている。
この記事の実践例を一冊にまとめました。
コードを書けない私が、AIに「チーム」を持たせるまで（Zenn Books）
この記事は はてなブログ からのクロスポストです。
はてなブログ版: https://saitoko.hatenablog.com/entry/2026/04/24/153331