コードを書かないSE日誌

SE歴26年。コードを書かずにClaude Codeで8体のAIエージェントチームを動かしています。AIエージェント・自動化・GTDの実験日誌。

Claude Codeでエージェント編集部を作ったら、この春Zenn Book 3冊書けた

Claude Code AI活用 執筆

4月初旬、私はClaude Codeを「AIが書いてくれる便利ツール」として使い始めた。AIエージェントに触れるのはそれが初めてだった。2ヶ月後の今、私はClaude Codeを「エージェント編集部を動かす指示役」として使っている。

転換点は、CLAUDE.mdにwriter/reviewer/readerという数行を書いた瞬間だった。それだけで、Claude Codeとの関係性が根本から変わった。この2ヶ月でプロジェクトのコミット数は2,185件に達し、記事ファイルは132本（アーカイブ7本含む。うちはてな公開済み100本、Zenn投稿済み41本）になった。

本記事は、Zenn Fesの「この春始めたこと」テーマへの応募です。

この記事の実施記録（2026年4月〜6月）: Claude Codeを4月初旬から使い始め、約2ヶ月でZenn Book 3冊を書いた。転換点はCLAUDE.mdにwriter/reviewer/readerという役割を書いた数行だった。プロジェクト開始からのコミット数は2,185件、記事ファイル数は132本（アーカイブ7本含む。うちはてな公開済み100本、Zenn投稿済み41本）。

2ヶ月で書いたZenn Book 3冊

この2ヶ月でZenn Bookを3冊書いた。

Vol.1「コードを書けない私がClaude Codeで『AIチーム』を作るまで」 コードを書かない私がClaude Codeで9体のAIエージェントチームを作り上げるまでの実録。最初の10日で原型ができ、その体験を書いた。

Vol.2「コードを書けない私がClaude Codeで『AIチーム』を回すまで」 チームを「作る」ことと「回す」ことは別の技術だと気づいた記録。Playbook・委任プロトコル・品質ゲートの三層構造を扱っている。

Vol.3「コードを書けない私がClaude Codeで『AIチーム』と書き続けるまで」 チームが動くようになった後の「では、何を書き続けるか」という問いへの記録。アンテナモデルへの転換、ネタ帳設計、4段ループ（仕込む→書く→届ける→回収する）を扱っている。

3冊で扱ったテーマは、実際にこの2ヶ月で経験したことをそのまま書いている。Vol.1を書き終えた時点でVol.2のテーマが生まれ、Vol.2を書き終えた時点でVol.3のテーマが明確になった。テーマが先にあったわけではなく、Claude Codeを使う中で自然に生まれてきた。

転換点：「自分で書く」から「指示する側になる」まで

最初の2週間は、Claude Codeに「この内容で記事を書いて」と直接頼んでいた。指示を出してAIが書き、私が直す。そのサイクルを繰り返していた。

転換点は、CLAUDE.mdにエージェントの役割を書いた時だった。

ここでは私が使っているwriter/reviewer/readerという名前を例に書くが、これは著者の編集部的な用途に合わせた名前であり、コードレビュアー役エージェントやテスト実行エージェントなど、自分の用途に合わせて自由に置き換えられる。

## エージェント組織

COO ─── オーケストレーション
├── researcher ── 調査・分析
├── writer ───── 記事執筆・Zenn/Qiita/はてな投稿
├── reviewer ─── コードレビュー・記事レビュー（品質ゲート）
└── reader ───── 想定読者ペルソナで原稿を評価

エージェントに役割を明示してClaude Codeを呼ぶだけで、動き方が変わった。writerは執筆に専念し、reviewerは事実確認を行い、readerは読者視点で感情レビューをする。私の役割は「何を書くか」を決めることと、各エージェントの出力を最終判断することに絞られた。

「自分で書く」から「指示する側になる」への転換は、ツールの使い方が変わったというより、Claude Codeとの関係性が変わったと表現するほうが正確だ。

組織として動く感覚

現在の執筆フローはこうなっている。

  1. ネタ帳（researcher）: Webリサーチとデイリーレポートで記事ネタを収集。毎朝自動実行されるリサーチエージェントが、興味領域のトレンドをスキャンしてネタ帳に積んでいく
  2. 執筆（writer）: ネタ帳と指示を受け取り、原稿を書く。一人称は「私」で固定、構成ルールはPlaybookに記載されている
  3. ファクトチェック（reviewer）: 数値・固有名詞・URLの裏取りを行う。事実と意見を書き分けているか、引用の精度は正確かを確認する
  4. 感情レビュー（reader）: 想定読者ペルソナとして原稿を読み、「ここで離脱しそう」「この数字の根拠が不安」といったフィードバックを返す
  5. 公開（COO）: はてなブログ、Zenn、QiitaへのクロスポストをCLIスクリプトで実行

この分業は、私がゼロから設計したわけではない。「よくある指摘のパターン」を繰り返しPlaybookに書き足していくうちに、自然とこの形になった。

品質ゲートは3軸で見ている。「事実正確性（ファクトチェック）」「読者体験（感情レビュー）」「構造・再現性（ライティングガイドライン準拠）」の3点を確認し、一定基準を満たした記事だけを公開する。ゲートを通すこと自体が目的ではない。「なぜここがひっかかったか」の指摘パターンを蓄積することで、ライティングガイドラインが育っていく。

ネタ帳は現在158本ある（2026-06-02実測）。記事ファイルは132本（アーカイブ7本含む。うちはてな公開済み100本、Zenn投稿済み41本）。レート制限のため全記事をZennに投稿できているわけではないが、この規模の管理を私一人でやるのは難しい。エージェントが役割分担して管理しているから維持できている。

予期しなかったこと：事故がシステムを鍛えた

順調だったわけではない。最大の事故はblogsyncに関するものだった。

はてなブログへの記事公開にはblogsyncというツールを使っていた。5月に入り、ブログ記事のカスタムURLが意図せず書き換わる事故が複数回発生した。初回は4本の記事URLが変わり、既存のSNSシェアリンクや検索エンジンのインデックスが無効になった。同じ事故が形を変えて4回繰り返した。

4回目の事故の後、根本解決策を選んだ。blogsyncへの依存を完全に断ち切り、はてなブログのAtomPub APIを直接呼ぶCLIを自分たちで実装した。5月30日にblogsync完全撤去が完了し、それ以降URL書き換え事故はゼロになった。

この経験から学んだことは、「事故はシステムの改善トリガーになる」ということだ。毎回の事故はlogs/governance-incidents/にインシデントファイルとして記録される。再発防止策はCLAUDE.mdのルールに追記される。事故を繰り返すたびに、ガバナンスの仕組みが具体的になっていった。

2ヶ月前はCLAUDE.mdに16行しか書いていなかった（プロジェクト開始時のgit履歴で確認）。今は数百行のルール、Playbook、トリガーリストが存在する。これは計画して設計したものではなく、事故と改善を繰り返した結果として積み上がったものだ。

コスト面も正直に書く。Claude MaxプランをAnthropicと契約している。月額$100のプランだ。一般的なClaudeの使い方（個人利用・チャット中心）であれば$20のProプランで十分だが、本記事のような複数エージェントを常時動かす制作規模では、Maxプランが現実的だと判断した。

Claude Codeを使い始めた人への次の一歩

Claude Codeを使い始めた人へ、「次の一歩」として勧めることが一つある。

CLAUDE.mdにエージェントの役割を書く、それだけでいい。

具体的には、プロジェクトルートのCLAUDE.mdに以下のような記述を追加する。

## エージェント組織

このプロジェクトでは以下の役割を持つエージェントを使い分ける。

- **reviewer**: 事実確認・数値の裏取り・出典チェックを担当する
- **reader**: 想定読者の立場で原稿を読み、離脱ポイントや疑問を報告する
- **writer**: 構成案とガイドラインに従って原稿を書く

これを書いた後でClaude Codeに「reviewerとして以下の原稿をチェックして」と指示すると、役割の文脈を持った回答が返ってくる。最初は3行でいい。「自分が何をやらせたいか」が明確になるにつれ、自然に詳細になっていく。

「複雑すぎる」と感じるかもしれない。私もそう感じた。ただ、最初は3行でいい。今の形になるまで2ヶ月かかった。一気に設計するより、使いながら育てるほうが現実的だし、使い方に合ったルールができあがる。

役割分担を明示すると、Claude Codeへの指示の出し方も変わる。「何でもやって」より「reviewerとして数値の根拠を確認して」のほうが、出力の質が安定する。曖昧な指示を出すより、役割と文脈を先に渡したほうがいい結果になる。

これが私がこの春、Claude Codeを使って発見したことだ。

この春を経て

2ヶ月前の私は「AIに書いてもらう」ことを始めた。2ヶ月後の私は「AIチームに指示を出す」ことが日常になっていた。始めることと続けることは別の技術で、続けることと仕組みにすることもまた別だと、この春に初めて実感した。CLAUDE.mdの数行が起点になり、事故が仕組みを鍛え、仕組みが書き続ける土台になった。「この春始めたこと」というテーマへの私の答えは、ツールを使い始めたことではなく、仕組みを育て始めたことだ。

この春書いた Zenn Book 3冊

関連記事

この記事のテーマを深掘りした本

コードを書けない私がClaude Codeで「AIチーム」を作るまで コードを書かないSEが9体のAIエージェント編集部を作るまでの実録（序章・第1部無料）

シリーズ全6冊: Vol.1 作るまで ／ Vol.2 回すまで ／ Vol.3 書き続けるまで ／ Vol.4 仕組みを渡すまで ／ Vol.5 仕事を任せるまで ／ Vol.6 1人エージェントチーム