コードを書かないSE日誌

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

コードを1行も書かずに、AIエージェント編集部を作った話——設計思考がAI時代に化けた10日間

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

10日間で自分がやったのは、プロンプトで指示を出すことだけだ。コードも、Markdownの設計書も、全部AIが書いた。人間がエディタで触ったのは認証トークンのコピペぐらいだ。それなのに、タスク管理ツール（/todoスキル、テスト約360件）、技術ガイド1冊（全11章）、技術ブログメディア（Zenn・Qiita・はてな）への記事公開、スケジュール自動化、組織の崩壊と再建——ここまで来た。

この記事は「すごいツールを見つけた」というだけの話ではない。SE歴26年の設計思考が、AIエージェントの世界でどう活きたかという話だ。ただ、これはプログラミングスキルの話ではない。「誰が何をやるか」「品質をどう担保するか」を考えてきた、設計と組織の話だ。

実際に編集部が制作した記事の一部を先に示しておく。「AIが書いた記事の品質」は、読者自身の目で判断してほしい。

なお、Claude Code の利用プランは$20のプランで試し始め、すぐに Max 5x Plan（月額$100）へアップグレードした。一日中使い続けて途中で枠が切れるのが嫌になり、Max 20x Plan（月額$200）にさらに上げた（冷静に考えれば休憩を挟めばよかった）。8体のエージェントを回してRemote Triggerも使うと、枠は想像以上に減る。現時点ではROI度外視の実験フェーズだと割り切っている。「無料で始められる」話ではない点は先に断っておく。

第1章: きっかけ——「試してみただけ」が止まらなくなった

1日目: ラーメン屋アプリが動いた

最初の動機は単純だった。「Claude Codeってどんなもんだろう」という好奇心で、$20のプランを契約してインストールした。

起動して最初に試したのは、近所のラーメン屋の情報をGoogle Mapから検索できるアプリだ。プロンプトを打っただけで、すぐに動いた。「へえ、なかなかやるな」という感想だった。

2日目: 業務システムが動いた。Mac miniを衝動買いした

翌日、Javaでも試したくなった。「Java 21で、銀行のサンプルアプリ作りたい」と打ってみた。製品バージョン間の依存関係を解消しながら、Claudeが全部インストールしていく。口座の入出金操作ができるところまで、自分では何もやっていないのに動いた。

本当にびっくりした。「こりゃすごいな」と思った。

この感動のまま、Mac miniを注文した。Claude Codeを本格的に使うための環境が欲しくなったのだ。冷静な判断ではなかった。世界的に人気で在庫が薄く、届くのは5月だという。つまり、この記事で書いている10日間の成果はすべて、メモリ8GBのWindows PCで出したものだ。でも後悔していない。

Claude Code専用マシンとして注文したのがこちら。届いたら感想を追記する予定。 Apple 2024 Mac mini（M4チップ搭載）

3日目: 「本業では使えない」という現実と、その先

感動が冷めると、現実的な問題が浮かんだ。

「プロンプトだけでシステムが作れるのはすごい。でも本業のアプリ開発には社内規程とかいろいろある。勝手に使えない」

では、次は何をしようか。そこで作ったのがGTDのコマンドラインツール（/todoスキル）だ。これもあっという間に動いた。「セキュリティを考慮して」と指示したら、コードを修正してテストまでやってくれた。

GTDとは「Getting Things Done」——頭の中のすべてを外部に書き出し、「今やるべきこと」だけに集中するタスク管理の方法論だ。「/todoスキル」の設計思想はこの本から来ている。

新装版 はじめてのGTD ストレスフリーの整理術（Kindle版）

この「本業では使えないから、自分のために使う」という転換が、この後の展開を決定的に変えた。

4日目: 「記事にして」の一言が、何かを変えた

4日目あたりに思いついた。「今までやったことをブログの記事にして」と言っただけで、記事ができた。どこに投稿するか、ブログの設定をどうするか、全部Claudeに教えてもらいながら動かしたら、投稿まで完了した。

この時点でまだ「便利だなあ」程度の認識だった。気づいていなかったのだ。

ループの発見

気づいたときには、こうなっていた。

Claude を使う
  ↓
その体験を操作のログやメモリから Claude が記事を書く
  ↓
記事内容の改善や投稿の自動化がしたくなる
  ↓
Claude に相談して改善する
  ↓
そのことをまた操作ログから記事にする
  ↓
（最初に戻る）

無限に記事が作れるループが、気がついたら完成していた。

「ブログが書きたくて始めた」わけではない。「Claude Codeを試していたら、こうなっていた」が正しい。このループを回し続けるための仕組みを作ろう、と思ったのが編集部構築の出発点だった。

第2章: AIエージェント編集部の全体像

組織図——「自分はCEOに指示するだけ」

10日目にできあがった編集部の構成がこれだ。

あなた（人間）
  │
  │  対話するのはここだけ
  ▼
CEO ──── オーケストレーション・意思決定
  │
  ├── secretary ──── 情報整理・GTD運用・GitHub Issue管理
  │
  ├── researcher ─── 競合調査・トレンド分析
  │
  ├── writer ─────── 記事執筆・Zenn/Qiita/はてな投稿
  │
  ├── reviewer ────── ファクトチェック・技術整合性確認
  │
  ├── reader ──────── ターゲット読者ペルソナ・感情レビュー
  │
  ├── devops ──────── 開発基盤・インフラ・スケジュール管理
  │
  └── todo-dev ────── /todo スキル開発・保守

人間が話しかけるのはCEOだけだ。CEOが状況を判断して各エージェントに仕事を振る。コードも書かない、ファイルも直接いじらない。指示と判断だけがCEOの仕事。

そして、CEOに指示を出すのが人間の仕事。人間の仕事は「何をやるか」ではなく「何をやらないか」を決めて、やらないことはAIに任せることだと、6日目に気づいた。

編集部としての役割マッピング

これをメディア編集部に置き換えると、こうなる。

エージェント 編集部の役職 やること
CEO 編集長 企画判断・優先順位・最終承認
secretary 編集デスク ネタ管理・スケジュール・進捗追跡
researcher リサーチャー 競合調査・トレンド分析・ファクト収集
writer ライター 記事執筆・リライト
reviewer 校正・校閲 技術的正確性・論理構成・ファクトチェック
reader 想定読者 読者視点の感情評価・刺さるかどうかの判定
devops システム管理者 自動公開・クロスポスト・インフラ保守
todo-dev 専任開発担当 /todoスキルの開発・保守・テスト

一人で回していた仕事を、8体のエージェントに役割分担した。それだけで、品質も速度も人間一人の限界を超えた。

SEの仕事との対応——工程も組織も同じだった

SEなら誰でも知っている開発の工程と組織構造が、そのまま記事制作に当てはまる。

SE工程 / 開発組織の役割 記事制作での対応 担当エージェント
要件定義 / PM 「何を書くか」「誰に届けるか」を決める 人間 → CEO
設計 / リサーチ部門 構成案の作成、競合との差別化設計 CEO + researcher
コーディング / 開発担当 記事の執筆 writer
テスト / 品質保証担当 技術レビュー + 読者ペルソナ評価 reviewer + reader
運用 / 基盤担当 公開・クロスポスト・スケジュール管理 devops
メンテナンス / PMO PV分析・進捗管理・組織の健全性チェック researcher + secretary

テストを飛ばせば品質が落ちること、運用を自動化しないとスケールしないこと、メンテナンスを怠ると散らかること、ユーザー視点を入れないと独りよがりになること——全部、SE時代に痛い目を見て学んだことだ。AIエージェント編集部は、開発プロジェクトの工程と組織を記事制作に移植しただけだった。

この体制で実際に本（全11章）を書いたプロセスの全工程——人間の発言15回でAIが2,000行を出力した2日間——は「人間の発言15回、AIの出力約2,000行——Claude Code で本を書いた2日間の全工程」に記録しています。

devops が担う自動公開・スケジュール管理の設計詳細は「Claude Code のスケジュール枠は3つだけ——ディスパッチャー方式で何タスクでも回す設計」で解説しています。

第3章: 崩壊——3日で組織が散らかった

「全部公開済みです」が嘘だった

組織を作ってから3日後。「Zennの記事、全部公開済み？」と聞いたら「全部公開済みです」と返ってきた。でも実際は違った。調べ直させたら、Zennの1日1記事公開制限に引っかかっていたことが判明した。AIは間違える。

これは序章だった。

ファイルサーバーが37件になっていた

数日後、logs/ フォルダーを開くと37ファイルが混在していた。レビュー結果、調査レポート、会話の引き継ぎ、全部ごちゃ混ぜ。「先週のレビューどこだっけ」が毎回発生するようになった。

researcherが記事を書き始めた

役割の崩壊も起きていた。ある日、researcherエージェントの成果物を見たら、記事の本文まで書いてあった。researcherは調査担当のはずだ。「誰が何をするのか」が曖昧なまま走り続けた結果、各エージェントが越境し始めた。

researcherには Edit 権限があり、writerにはWebSearch権限があった。「何でもできる人」が「何でもやろうとする」のは、人間の組織でも起きることだ。

スペルミスが組織を止めかけた

もう1つ、地味で危険な問題があった。resarcher（researcher のスペルミス）が、エージェント定義ファイル・設定ファイル・コンテンツにわたって複数箇所に散らばっていた。Claude Code のサブエージェント呼び出し名は定義ファイルと完全一致が必要なため、もし呼び出し名がスペルミスと一致していたら組織が止まっていた。

[内部ログ] コミット a567fa1: resarcher → researcher の一括修正

ルールが7体全員に重複していた

「日本語で応答すること」「引き継ぎヘッダーをつけること」——同じルールが7エージェント全員の定義ファイルに、それぞれ書かれていた。どれか1つを変更するとき、7箇所を変えなければならない状態だった。

これは自分で気づいたのではない。researcherエージェントが組織効率分析を実施して、ルール重複を検出した。

組織の崩壊・立て直しをより感情的・マネジメント論として読みたい方は「SE歴26年、初めての部下はAIだった」が入口として読みやすいと思います。

第4章: 立て直し——チャットだけで直した5つの改善

問題はすべて「おかしくない？」「散らかってきたな」という感想を言っただけで、各エージェントが設計案を出して実装まで完結した。自分が設定ファイルを開いたことは一度もない。

改善1: ファイル整理（37件→7件）

「logs/ ごちゃごちゃしてきたな」

これだけ言ったら、devopsエージェントが設計案を出した。命名規則が分かりにくかったので「何それ？」とフィードバックしたら修正された。実装・検証まで組織で完結。

結果: logs/ の37ファイルが7ファイルへ。レビュー結果は content/reviews/、調査レポートは content/reports/research/、引き継ぎは ops/handoff/ へ分離した。

改善2: 権限の見直し（越境を止める）

「researcherが記事書いてるのおかしくない？」

これをCEOエージェントに相談したら、権限の見直し案が返ってきた。researcherから Edit 権限を外し、writerのWebSearch を制限。

さらに「レビュー作業をresearcherにやらせるのはおかしくない？」と続けたら、reviewerエージェントの新設案が出てきた。品質チェックの責務を独立させることで、researcherは「調査」、reviewerは「確認」という役割分担が明確になった。

[内部ログ] コミット a92d2e0: reviewer エージェントの新設

改善3: グローバルルールへの集約

researcherが発見したルール重複は、CEOエージェントが集約案を提案した。7エージェント定義から重複記述を削除し、global-rules.md への参照リンク1行に置き換えた。

変更点を人間が一行も書いていない。「いいね、やって」と承認しただけだ。

改善4: Zenn公開ポリシーの策定

「全部公開済みです」の嘘がきっかけで、公開フローをルール化した。

writer → reviewer（チェック） → researcher（公開順提案） 
  → CEO（承認） → secretary（スケジュール）→ 自動公開

AIの間違いを「おかしくない？」と指摘したことが、結果的に業務フローの言語化につながった。

この「全部公開済みです」の嘘が最終的にガバナンス整備へつながる経緯——AUTO_SYNC_ZENN=true 独断デフォルト化による5記事unpublishから「trigger リスト付き憲法」が誕生するまで——は「Claude Code の憲法を書いたら、1日で法律になった話」で詳しく書いています。

改善5: 組織健全性チェックの定例化

改善1〜4で組織はすっきりした。でも放っておけばまた散らかる。

devopsエージェントの週次タスクに「組織健全性チェック」を追加した。エージェント定義の矛盾・ルールの重複・権限の過不足を定期点検する仕組みだ。「改善を一回やって終わり」ではなく、仕組みとして回す——これも人間の組織でいう内部監査と同じ考え方だ。

[内部ログ] コミット 73b59c1: devopsによる組織健全性点検の定例化

第5章: SE視点の設計思考がここで活きた

「工程を設計する」という習慣

SEが開発プロジェクトでやることは、工程を設計することだ。要件定義 → 設計 → 実装 → テスト → 運用、という流れは「なんとなく」ではなく設計の結果としてある。

編集部も同じだった。

記事を書くとき、最初は「writerに書かせる」だけで動き始めた。しかしすぐに「品質が落ちる」問題が出た。だからreviewerを追加してファクトチェックを挟んだ。読者視点が欠けていると気づいたからreaderを追加した。レビューのたびに毎回同じ確認をしていると非効率なので、チェックリストをplaybookに書いた。

「テストを飛ばすと後で手戻りが増える」——SE時代に何度も経験したことが、AIエージェント編集部でも同じように起きた。

「属人化を排除する」という発想

SEなら誰でも知っている問題がある。「Aさんしか分からない業務」だ。Aさんが休むと組織が止まる。

AIエージェントでは、この問題の解き方が変わった。セッションが終わるたびに記憶がリセットされるため、引き継ぎファイルを整備しないと次のセッションで同じ話を最初からしなければならない。強制的に言語化が発生する。

MEMORY.md（判断の積み重ね）、エージェント定義ファイル（専門知識とルール）、ops/playbooks/（手順書）——これらは「AIに教えるために書いたもの」だが、見た目は「人間の組織でも本来あるべきドキュメント」そのものだ。

先日、3体のエージェントを廃止して1体に統合した。変更ファイルは26ファイル、1セッションで完了した。廃止したエージェントの経験は、定義ファイルにそのまま移植できた。「人材のリストラ」ではなく「設計変更」として処理できた。

[内部ログ] 統合コミットの変更ファイル数は git show --stat で確認

「マニュアルが増えすぎる」問題も同じだった

大企業病として知られる「手順書が増えすぎて誰も読まなくなる」現象は、AI組織でも起きた。

2026-04-16時点、Playbook（手順書）ファイルは38ファイル、総行数3,506行だった（実測）。記事を書いている4月21日現在では51ファイルにまで増えている。整備しようとするほど増えていく自己矛盾だ。

人間の組織と違うのは、AIはマニュアルを「読まない選択」をしないことだ。ファイルが増えるほど処理コストが上がるという形で直接問題が現れる。187行あった手順書ファイルを116行に圧縮した（定型テンプレートをシェルスクリプトに切り出した）が、今も増え続けている。

「テストなしでリリースしない」というルール

/todoスキルには約360件のテストがある（CHANGELOG-DIARY.md上の最大記録は363件）。Claude Codeが全部書いた。

なぜテストを書いたのか。「セキュリティを考慮して」と指示したら、Claudeがテストを追加した。SE時代から「テストのないコードは壊れたコード」という感覚があったので、「まあいいか」とはならなかった。

AIがコードを書くと、人間はコードの中身を読まなくなる。だからこそ「AIが書いたコードでもテストは通す」というルールを最初から外さなかった。

第6章: まとめ——何が変わり、何が変わらなかったか

変わったこと

実行が「タダ」になった。

「この調査をやってほしい」「この記事を書いてほしい」——思いついた瞬間にCEOエージェントに言えば動き出す。実行のコストがほぼゼロになると、「試してみよう」の閾値が劇的に下がる。

10日間でこれだけのことができたのは、才能でも時間でもない。「やってみよう」のコストが限りなく安くなったからだ。

フィードバックが機能する。

「なぜここが間違えたの？」と聞くと、人間なら謝罪が先に来て原因が後回しになる。AIは謝罪なし、萎縮なし、言い訳なし。「原因を調査します」から始まる。原因が分かれば次から同じミスをしない仕組みを作れる。

一人でチームになった。

「一人だからできない」がなくなった。調査も、執筆も、レビューも、公開も、全部別の担当が並行で動く。自分一人の限界を超えた出力ができるようになった。

変わらなかったこと

人間の仕事は「判断」だ。

10日間でやったことを振り返ると、自分が実際にやったことは全部「判断」だった。何を書くかを決める、方向性を承認する、指摘の優先順位をつける、「これはおかしくない？」と違和感を声にする。実行は一行もやっていない。

「違和感を言葉にする力」が全ての起点だった。

「散らかってきたな」「おかしくない？」「何それ？」——組織の改善は全部この言葉から始まった。プログラミングスキルではなく、状況を観察して言語化する力が、AI時代のマネジメントの核心だと思っている。

コストは実在する。

AIが速くなっても、判断を求めてくる速さも同じだ。承認待ちのエージェントは止まるので、朝から晩までPCの前にへばりついた時間帯があった。月額は現時点で実測できていないが[要確認]、Max 20x Plan（月額$200）を使っていることは事実だ。「無料でできる」話ではないし、「楽になる」と「速く動く」は別の話だ。

最後に

10日間の実験で気づいたのは、SE歴26年の自分が積み上げてきたことの大部分が、AIエージェントの世界でそのまま使えるということだった。

要件を整理する。役割を分ける。テストを書く。手順書を作る。組織の健全性を定期点検する。これは全部、ソフトウェア開発の世界でずっとやってきたことだ。

AIが変えたのは「実行コスト」だけだった。設計の思考は変わらなかった。

むしろ、設計思考を持っていたことで、AIをただ「便利ツール」として使うのではなく、「組織として設計する」という発想に自然に至れた。

「SE歴26年だからできた」と言われるかもしれない。でも26年の経験が使えたのは、設計・役割分担・品質管理という概念を知っていたからだ。それはプログラミングスキルではなく、「誰が何をやるか」「品質をどう担保するか」「組織をどう維持するか」を考えてきた経験だ。

会社でプロジェクトを回してきた人、チームを持ったことがある人、仕事の流れを設計してきた人——そういう経験があれば、AIエージェント組織は同じ発想で設計できる。

まだわかっていないことも正直に書いておく。10日間は「とにかく動かした」フェーズだ。月単位で継続したときに運用コストがどう変化するか、AIの判断ミスが積み重なったときにどう修正するか、プランをダウングレードしたときに品質がどう変わるか——これらはまだ検証中だ。「10日でここまでできた」は事実だが、「これが安定運用できる」とは言い切れない段階だと思っている。

こういった「AIと人間の協働設計」を体系化した書籍も出てきている。AI主導開発の実践に興味があれば参考になる。

AI駆動開発完全入門 ソフトウェア開発を自動化するLLMツールの操り方（Kindle版）

この記事自体が、その組織が制作した。

数値の根拠: Playbook38ファイル/3,506行は2026-04-16に実測。2026-04-21現在は51ファイル（Globツール実測）。統合コミットの26ファイル変更は git show --stat で確認。テスト件数はCHANGELOG-DIARY.md上の最大記録363件より「約360件」と記載。Max 20x Plan価格はAnthropicの公式サイト（claude.com/pricing/max）より確認。

「コードを1行も書かずにAIエージェント編集部を作った」この10日間の設計思考と実装を、電子書籍として体系化しています。

コードを書けない私が、AIに「チーム」を持たせるまで（序章・第1部無料）

関連記事