コードを書かずに編集部が動いた

Claude Codeを初めて起動した日から10日後、8体のAIエージェントが連携して記事を制作する「編集部」が完成していた。

著者がこの10日間でやったことは、プロンプトで指示を出すことだけだ。コードも、Markdownの設計書も、全部AIが書いた。人間がエディタで直接触ったのは「認証トークンのコピペぐらい」と本人は書いている。それでも、テスト約360件を備えたGTDツール、全11章・約2,100行の技術ガイド1冊、Zenn・Qiita・はてなへの記事公開、スケジュール自動化——これだけのアウトプットが出た。

この話の面白さは「便利なツールを見つけた」にとどまらない点にある。SE歴26年の設計思考が、AIエージェントの組織化にそのまま転用できることを、実体験として示した記録だ。

なぜ今この話が重要か

AIを「使う」話は溢れている。でもこの事例が一段違うのは、AIが「組織として動く」段階に踏み込んでいるからだ。

単一のAIにタスクを投げるのではなく、CEO・secretary・researcher・writer・reviewer・reader・devops・todo-devという8つの役割を持つエージェントを編成し、人間はCEOにだけ話しかける。CEOが状況を判断して各エージェントに仕事を振る。この構造が動いた、という話だ。

メディア制作や編集業務に関わる人間にとって、これは他人事ではない。

何が起きたのか——10日間の中身

1日目はラーメン屋アプリ、2日目にはJava 21で銀行のサンプルアプリが動いた。依存関係の解消も含めてAIが全部やった。著者の感想は「本当にびっくりした」。この感動のままMac miniを注文している（届くのは5月で、記事の成果はすべてメモリ8GBのWindows PCで出したという余談つきで）。

転機は4日目だ。「今までやったことをブログの記事にして」と打ったら記事ができた。そこでループの構造が見えた。

Claude を使う → その体験からClaudeが記事を書く → 投稿の自動化がしたくなる → Claudeに相談して改善する → そのことをまた記事にする → （最初に戻る）

無限に記事が作れるループが自然発生した。「ブログを書きたくて始めた」のではなく、「Claude Codeを試していたらこうなっていた」というのが正確なところだ。

5〜7日目で組織化が進む。CLAUDE.mdが50行を超えたあたりでAIが指示を守ったり守らなかったりし始めたため、「1人の万能アシスタント」から役割を持ったチームへ再編成した。6日目夜から7日目朝にかけて、技術ガイドの初稿を一晩（約10時間・人間の発言15回）で書き上げている。

そして3日使い込んだら組織が散らかった。logs/フォルダに37件のファイルが溜まり、役割の境界が曖昧になった。立て直しに使った著者の発言は5つ——「散らかってきた」「誰の仕事？」「おかしくない？」「何それ？」「やって」——これだけで、logs/は37件から7件（81%削減）になった。

SEの設計思考がなぜ効いたのか

著者が指摘している点が鋭い。AIエージェント編集部の構造は、ソフトウェア開発の工程と組織をそのまま記事制作に移植したものだということだ。

要件定義→設計→コーディング→テスト→運用→メンテナンスという工程が、企画→リサーチ→執筆→レビュー→公開→分析に対応する。reviewerが技術整合性を確認し、readerが「読者として刺さるか」を判定するのは、品質保証担当とユーザー視点レビューそのものだ。

権限分離も同様だ。業務システムで開発者が本番DBを直接触れてはいけないのと同じ原則を、AIエージェントに適用した。writerのエージェント定義では使えるツールをRead/Write/Glob/Grepに限定し、余計な操作を防いでいる。

「テストを飛ばせば品質が落ちること、運用を自動化しないとスケールしないこと、ユーザー視点を入れないと独りよがりになること——全部、SE時代に痛い目を見て学んだことだ」という一文が、この記事の核心を突いている。

実務的な示唆

いくつか留保が必要な点もある。コストは$20のプランから始まり、すぐにMax Plan（月額$100）へ、さらにMax 5x Plan（月額$200）へアップグレードしている。8体のエージェントを回してRemote Triggerも使うと、利用枠は「想像以上に減る」。著者本人が「現時点ではROI度外視の実験フェーズ」と明言しており、「無料で始められる」話ではない。

それを踏まえたうえで、この事例から実務的に引き出せる視点がある。

ひとつは「組織は3日で散らかる」という点だ。AIエージェントも人間のチームと同様に、役割の境界が曖昧になり、ルールが重複し、ログが溜まる。違うのは、何度同じ指摘をしても摩擦が生まれないことだ。人間のマネジメントではこうはいかない。

もうひとつは品質への視点だ。writerが一晩で書いた初稿は荒く、reviewerのA判定後でもreaderが60点をつけた。量は出せるが、品質はレビューサイクルで上げるもの——この実感は重要だ。AIのアウトプットを「そのまま使える」と思うと痛い目を見る。

「指示と判断」だけが人間の仕事になる

著者が6日目に気づいたこととして、こう書いている。「人間の仕事は『何をやるか』ではなく『何をやらないか』を決めて、やらないことはAIに任せることだ」と。

これは単なるツール活用の話ではない。仕事の構造が変わるという話だ。編集者がライターとやり取りしてコンテンツを作るのではなく、編集者がAI編集部の構造を設計し、方針を判断し、CEOに一言だけ話しかける——そういう形が、もう動いている。

SE歴26年の設計思考が化けた、というよりも、設計思考そのものの価値が再発見された10日間だったと読んでいる。