コードを1行も書かずに、Claude Codeで8体のAIエージェント編集部を作った話——SE歴26年の設計思考がAI時代に化けた10日間

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

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

この記事は「すごいツールを見つけた」というだけの話ではない。SE歴26年の設計思考が、AIエージェントの世界でどう活きたかという話だ。

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

• Claude Code を6日使ったら秘書・ライター・リサーチャーが揃ったチームになっていた
• Claude Code でAIチームを組織した — CEO・DevOps・Writer・Researcher の役割分担と運用設計
• AIエージェント組織、3日で散らかった話 — チャットだけで立て直したマネジメント実録

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

[:contents]

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

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

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

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

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

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

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

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

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

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

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

では、次は何をしようか。そこで作ったのがGTDのコマンドラインツール（/todoスキル）だ。これもあっという間に動いた。「セキュリティを考慮して」と指示したら、コードを修正してテストまでやってくれた。GTDそのものについては新装版 はじめてのGTD ストレスフリーの整理術が体系的な入門書として知られています。

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

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エージェント編集部は、開発プロジェクトの工程と組織を記事制作に移植しただけだった。

第3章: 10日間のタイムライン

実際に何が起きたかを時系列で振り返る。

Phase 0: 1〜2日目——衝撃と覚醒

1日目: ラーメンアプリ完成。環境構築の速さに驚愕
2日目: 業務システムサンプル完成。依存関係を全部解消して動いた衝撃。Mac mini注文

Mac miniを買ったのもこの時期だ。Claude Codeを本格的に使うために、環境を整えた。

ここではまだ「便利なコーディングツール」としか思っていなかった。転機はDay 3。

Phase 1: 3〜4日目——インフラ構築

3日目: /todo スキル開発開始。GTDをCLIで回す仕組みをあっという間に構築
4日目: ブログ記事への転用。「今までやったことを記事にして」でループが始まる

/todoの開発は、Claude Codeの本質を理解するきっかけになった。**「コードを書いてもらう」のではなく「仕組みを設計して、実装を任せる」**というスタイルが確立した瞬間だ。

GitHub Issues をバックエンドに使い、Bash + Node.js で/todoスキルの基盤をあっという間に構築した。この時点でテスト303件。その後i18n対応やバグ修正で追加し、最終的に約360件まで育った。人間がやったのはプロンプトで方針を伝えることだけだ。セキュリティルール8項目（シェルインジェクション防止、プロンプトインジェクション防止など）も、要件を指示してAIに実装させた。

Phase 2: 5〜6日目——組織化

5日目: エージェント定義とルールを整備。CEO含む6体構成
6日目: researcher がレビューも兼務して品質が下がる → reviewer を分離。7体構成が完成
7日目: /todo スキルの保守・拡張が増加 → todo-dev を分離。8体構成が完成

ここが最大の転換点だった。CLAUDE.md が50行を超えたあたりで、Claude が指示を守ったり守らなかったりし始めた。200行を超えると遵守率が下がるという体感は本当だった。

そこで「1人の万能アシスタント」から「役割を持ったチーム」に再編成した。

仕組みを先に作った3〜4日目の投資が、5〜6日目で爆発的に効いた。 /todoで管理基盤があるから、組織化しても進捗が追える。ログ管理の仕組みがあるから、エージェント間の連携が成り立つ。

Phase 3: 6日目夜〜8日目——量産と崩壊

6日目夜〜7日目朝: 技術ガイドの初稿を一晩で書いた（全11章・約2,100行、約10時間、人間の発言15回）
7〜8日目: 読者ペルソナAIに批評させたら60点だった → 78点に改善

技術ガイドを1冊書いたのは、組織の力を実感した瞬間だった。内容は「Claude Codeマルチエージェント組織の構築ガイド」——この10日間で学んだことを体系化したドキュメント（全11章・約2,100行）だ。出版物ではなく社内ドキュメントに近い規模感だが、一晩（約10時間）で初稿が完成し、その後reviewerの技術チェックとreaderのペルソナ評価を経て品質を上げた。

writerが書く → reviewerがファクトチェック → readerが「読者として刺さるか」を判定 → CEOが修正方針を決める。このサイクルを複数ラウンド回した結果、2,100行のアウトプットが出た。正直に言えば、一晩で書いた初稿の品質は荒い。reviewerのA判定後でもreaderが60点をつけた。量は出せるが、品質はレビューサイクルで上げるもの——これが実感だ。

一方で、3日間使い込んだらlogs/フォルダに37件のファイルが溜まり、役割の境界が曖昧になり、ルールが重複し始めた。組織は3日で散らかる。

立て直しに使った人間の発言は5つだけだ。

1. 「散らかってきた」
2. 「誰の仕事？」
3. 「おかしくない？」
4. 「何それ？」
5. 「やって」

結果、logs/は37件→7件（81%削減）。AIマネジメントの良いところは、何度同じ指摘をしても摩擦が生まれないことだ。人間のチームではこうはいかない。

Phase 4: 9〜10日目——自動化と安定運用

9日目:  スケジューラー（ディスパッチャー方式）構築
10日目: Remote Trigger 実運用。6つの罠を踏んで対処

Claude CodeのRemote Triggerは枠数に制限がある（筆者の環境では3枠）。でもディスパッチャー方式を使えば、少ない枠で多数のタスクを回せる。daily.md / hourly.md / adhoc.md にタスク定義を書いて、トリガーがディスパッチするだけだ。

ここでも踏んだ罠は多かった。API部分更新でプロンプトが消える、マルチリポジトリで初期ディレクトリが不定、Secretsがリモートに渡らない、WindowsとLinuxの環境差異——6つの罠を踏んで、全部対処した。

「サイレント失敗」が一番怖いという教訓は、業務システムの障害対応で何度も経験したことと同じだった。

第4章: 設計のポイント——SEの知見が活きた

4-1. 権限分離

業務システム開発では、開発者が本番DBを直接触れてはいけない。同じ原則をAIエージェントに適用した。

以下はyaml風に書いているが、実際のエージェント定義はMarkdownファイルだ。「ライターのエージェント定義を作って。使っていいツールはRead, Write, Glob, Grepだけ」とプロンプトで指示すれば、AIがMarkdownファイルを生成してくれる。

# 各エージェントの ToolKit 制限の例（実際はMarkdownで日本語記述）
writer:
  - Read, Write, Glob, Grep  # ファイル操作のみ。Edit は不要（記事はWrite新規作成がメイン）
  - WebFetch, WebSearch は使えない（リサーチはresearcherの仕事）

researcher:
  - Read, Write, Glob, Grep, WebFetch, WebSearch  # 調査特化 + レポート出力用のWrite
  - Edit は使えない（既存ファイルの編集はwriterやdevopsの仕事）

devops:
  - Read, Write, Edit, Glob, Grep, Bash  # インフラ全般
  - WebFetch, WebSearch は使えない（外部調査はresearcherの仕事）

**「何ができるか」ではなく「何をさせないか」を定義する。**これは業務システムの権限設計そのものだ。

なぜこれが重要か。エージェントに全権限を与えると、writer が勝手にリサーチを始めたり、researcher が記事を書き始めたりする。役割の境界が崩れると、品質も崩れる。

4-2. 文書の構造化管理

エージェント間のコミュニケーションにはAPIもMCPも使わない。Markdownファイルだ。

# logs/ プロトコル：YAML frontmatter + Markdown
from: writer
to: reviewer
status: review-requested
date: 2026-04-09

## 記事タイトル案: Claude Code歴10日で...

### 概要
...

このログ管理プロトコルは、業務システムでいう「帳票」に相当する。誰が、いつ、何を、どのステータスで送ったかが全部記録に残る。ファイルだから検索もできるし、gitに入るから履歴も追える。

ログの整理もルール化した。

logs/
├── reviews/     # レビュー結果
├── reports/     # 調査レポート
├── drafts/      # 下書き
└── archive/     # 完了済み

3日で37件まで膨れ上がったときに、このフォルダ構成に再編した。**フォルダ構成を決めるだけで、エージェントは自律的にファイルを正しい場所に置くようになった。**ルールを明文化する効果は、人間のチームよりAIチームのほうが大きい。

4-3. 品質ゲート

業務システム開発では、コードレビュー → テスト → ステージング → 本番のゲートがある。編集部でも同じ構造を作った。

記事ネタ → CEO承認
  ↓
writer 初稿 → reviewer 技術チェック → 差し戻し or 承認
  ↓
reader ペルソナ評価 → 60点以下は差し戻し
  ↓
researcher 競合調査 → 差別化ポイント確認
  ↓
CEO 最終承認 → devops 公開

ゲートが命だ。技術ガイドを書いたとき、reviewer は技術的にA判定を出した。でもreader（読者ペルソナ）に読ませたら60点だった。「技術的に正確」と「読者に刺さる」は別物だと、ここで痛感した。

reader の設定で重要だったのは、「38歳、非エンジニア、AIに懐疑的」というペルソナだけでなく、「疑い」を明示的に定義することだった。このペルソナ定義自体も、AIと対話しながら「どんな人が読むか」「どんな疑念を持つか」を一緒に掘り下げて作った。

読者の疑い:
- 「結局エンジニアじゃないとできないんでしょ？」
- 「AIが書いた文章って薄っぺらくない？」
- 「10日で作ったって、どうせおもちゃでしょ？」

この疑いを持たせた状態でレビューさせると、通常モードでは出てこない「ここ、詐欺っぽく感じます」「具体性が足りません」といった指摘が出る。読者ペルソナの「疑い」定義は、批判的レビューの精度を決定的に変えた。

4-4. 組織の健全性監視

業務システムには監査がある。AIエージェント組織にも、DevOpsによる健全性チェックを組み込んだ。

# DevOps 週次ヘルスチェック項目
- [ ] logs/ の未処理ファイルが10件以下か
- [ ] 各エージェントの役割定義に重複がないか
- [ ] CLAUDE.md の行数が200行以下か
- [ ] 共有ルール（.claude/rules/）に矛盾がないか
- [ ] テストが全件パスするか

**組織は放っておくと散らかる。**これは人間のチームでもAIチームでも同じだ。違うのは、AIチームなら「散らかってきた」の一言でクリーンアップが始まること。人間のチームで毎週「散らかってきた」と言ったら、ちょっとした問題になる。

4-5. 「増やさない」という判断基準

6日目の教訓がある。researcher がリサーチもレビューもやっていたとき、アウトプットの品質が下がった。役割が肥大化すると、AIでも品質が落ちる。

新しいエージェントを追加するのは「既存のエージェントが2つ以上の責務を持っている」と気づいたときだけだ。「あったら便利」では追加しない。「ないと品質が落ちている」と実感したときが、分離のタイミングだ。

この記事自体を例にすると

実際にこの記事では、前版レビューでreviewerが「テスト件数の矛盾」「ToolKit制限が過去記事と不整合」など複数の必須修正を指摘し、readerが「コスト情報がゼロ」「始め方がわからない」と評価した。これらの指摘を受けて修正を行った。品質ゲートがなければ、これらの問題を抱えたまま公開していた。

第5章: 実際に打ったプロンプト

設計の話ばかりしてきたが、具体的に何を打ったのか。再現できるように、実際のプロンプト例を示す。

CLAUDE.md の生成:

人間が最初に打ったのはこの1文だけだ。

あなたはオーケストレーションハブです。

CEOがそれを受けて、役割・ルール・制約を補完しながら以下のようなCLAUDE.mdを生成した（抜粋）。

# 出力例（AIが生成したCLAUDE.mdの冒頭）
あなたはオーケストレーションハブ（CEO）です。

## 基本ルール
- 人間からの指示を受けて、適切なエージェントに作業を委任する
- 自分ではコードを書かない。判断と指示に専念する
- 各エージェントの成果物を確認し、品質ゲートを通す
- 判断に迷う場合は人間に確認する

## エージェント一覧
- /agent writer — 記事執筆
- /agent reviewer — 技術レビュー
...（以下、全17行）

エージェント定義の生成:

人間が打ったのはこの1文。

ライター用のエージェント定義を作って。

CEOが具体的な制約に落とし込んだ結果がこれだ。

- 役割: Zenn/Qiita/はてな向けの記事執筆
- 使っていいツール: Read, Write, Glob, Grep のみ
- WebSearchやWebFetchは使わないで（リサーチはresearcherの仕事）
- 記事は既存ファイルのEditではなくWriteで新規作成して

品質ゲートの指示:

人間が打ったのはこの1文。

この記事をレビューして。

CEOが観点を整理・具体化した。

- 過去記事との事実の整合性（数字・日付・エピソード）
- 技術的な誤り
- 論理の飛躍
各指摘を「必須修正」「推奨修正」「軽微」の3段階で分類して

読者ペルソナの設定:

人間が打ったのはこの1文。

読者視点でこの記事を評価して。

CEOがペルソナの詳細を補完した。

- 38歳、非エンジニア、AI懐疑的
- 疑い: 「結局エンジニアじゃないとできないんでしょ？」「10日で作ったっておもちゃでしょ？」
100点満点で採点。通常モードと批判的モードの2回。

どれも日本語の短い一言から始まる。特別な構文はない。「何をさせるか」「何を禁止するか」「どう評価するか」を言葉にできれば、AIが動く。

第6章: 走りながら育てた組織

6-1. 「走りながら直す」アプローチ

最初から完璧な組織を設計したわけではない。

1日目: CEO 1体でスタート
5日目前後: secretary が必要だと気づく → 追加
6日目: researcher が調査もレビューもやっていた → reviewer を分離
7日目: /todo スキルの保守・拡張が増加 → todo-dev を分離。8体構成が完成
8日目: 組織が散らかった → 再編

**「まず動かして、壊れたら直す」**のサイクルを高速で回した。これがAIチームの強みだ。人間のチームでは「組織改編」は重いイベントだけど、AIチームなら.claude/agents/ のファイルを1つ追加するだけで「組織改編」が終わる。

失敗のコストが極めて低い。だから、設計を考えすぎるより、走りながら直すほうが速い。

6-2. GTD × AI で自分自身のタスク管理も並走

/todoスキルの開発は、AIチーム構築と同時並行で進めた。

朝: /todo daily-review で今日のタスクを確認
日中: secretary が Inbox に新タスクを投入
夕方: CEO が完了タスクをクローズ
夜: /todo weekly-review で振り返り

「AIチームの管理」と「自分自身のタスク管理」を同じ仕組みで回せるのが大きかった。GitHub Issues がバックエンドだから、AIエージェントも人間も同じタスクボードを見ている。

ある朝のGTDセッションで、Claude がタスクの依存関係（Issue #187 → #311 → #312）を自動で見抜いて、プロジェクトとしてグルーピングした。自分では気づいていなかった依存関係だ。AIがGTDの「整理」フェーズを自律的にやってくれるのは、予想外の効果だった。

第7章: 実績データ

10日間の実績を数字でまとめる。

指標	数値
開発したアプリ	2個（ラーメンレビュー、業務システム）
開発したスキル	1個（/todo GTD）
テストケース	約360件（/todo 最終値）
執筆した技術ガイド	1冊（全11章・約2,100行、出版物ではなくドキュメント）
公開した記事	Zenn 3本公開済み（冒頭リンク参照）+ 下書き数本（Qiita・はてなへクロスポスト含む）
エージェント構成	8体（CEO含む）
自動化フロー	3つ（デイリーリサーチ、クロスポスト、スケジューラー）
人間がエディタで直接書いたもの	認証トークンのコピペ程度（コード・設計書は全てプロンプト指示でAIが生成）
踏んだ罠	6つ（Remote Trigger） + テスト事故1件（~/.claude/消失）
組織崩壊からの復旧	logs/ 37件→7件（81%削減）、発言5回で完了

踏んだ罠のハイライト

10日間は順調だったわけではない。むしろ罠だらけだった。

テストが ~/.claude/ を消し飛ばした事件

/todoのテスト約360件が全件パスしていた。でもClaude Codeが何度もログアウトを要求してくる。調べたら、テストのクリーンアップ処理がHOMEディレクトリの復元タイミングを間違えて、~/.claude/ ごと削除していた。さらにWindowsでは os.homedir() が HOME ではなく USERPROFILE を参照するというクロスプラットフォームの罠も重なっていた。

テストが「全件パス」しているのに、システムが壊れている。「テストが通ること」と「システムが正しいこと」は別だという、業務システムで何度も経験した教訓がそのまま出た。

Remote Trigger の API 部分更新でプロンプトが消えた事件

Remote TriggerのAPIで設定を部分更新したら、指定しなかったフィールド（プロンプト）が空になった。PATCHのつもりがPUTだった。これも業務APIの設計で見たことがあるパターンだ。

第8章: 始めるなら——最小構成の5ステップ

読者ペルソナから「始め方がわからない」と指摘された。ここに最小構成を書く。

Step 1: Claude Code をインストールする
  → https://docs.anthropic.com/en/docs/claude-code/overview
  → $20/月のプランから試せる。利用量が増えたら Max Plan ($100/月) や 5x Plan ($200/月) へのアップグレードも検討

Step 2: Claude Code を起動して「CLAUDE.md を作って。あなたは編集長です」と指示する
  → AIがCLAUDE.mdを生成してくれる
  → 最初はこの1ファイルだけでいい（17行から始めた）

Step 3: 「この記事のネタを考えて」と話しかける
  → 編集長1体だけで、まず記事を1本書いてみる

Step 4: 限界を感じたら、エージェントを1体追加する
  → 「ライター用のエージェント定義を作って」と指示すれば、ライター担当のエージェント定義ファイルが生成される
  → 編集長から呼び出せる

Step 5: 以降、問題が起きるたびに役割を分離する
  → レビューが甘い → reviewer 追加
  → 読者に刺さらない → reader 追加
  → ファイルが散らかる → devops 追加

重要なのは、最初から8体を作らないことだ。1体で始めて、壊れたら分ける。この記事で書いた8体構成は10日かけて育てた結果であって、設計図ではない。

第9章: まだできていないこと

成功体験だけ書くのはフェアではない。10日目時点で解決できていない問題を書く。

未解決の課題	状況
収益化	記事は制作できるが、収益化の仕組みはまだない
アウトプットの市場評価	PVは正直なところバズったものはない。いいね・コメントも少数。定量的な評価体制が未整備
長期運用コスト	Max Plan/5x Plan（月額$100〜$200）が個人ブログの収益に見合うか未検証
エージェントの品質劣化	CLAUDE.mdが肥大化すると遵守率が下がる問題は根本解決していない
一人依存	組織設計・CLAUDE.md管理が自分に集中しており、属人的

**「編集部を作った」のは事実だが、「編集部が成果を出した」はまだ証明できていない。**その証明は、この先の運用で出す。

まとめ

AIは道具だけど、道具を組織にするのは設計だ。

10日間でやったのは、SEとして何百回も回してきた「要件定義→設計→実装→テスト→運用→メンテナンス」を、記事制作に移植しただけだった。権限分離も、品質ゲートも、組織の健全性チェックも、全部業務システム開発で痛い目を見て学んだことの転用だ。

編集部は動いている。散らかって、直して、また散らかるだろう。それでいい。「壊れても直せる」と知っていることが、最大の強みだ。

この記事自体が、AIエージェント編集部のワークフローで制作されました。reviewerによる技術チェック+readerによるペルソナ評価を複数ラウンド実施し、事実の正確性修正・章構成の統合・プロンプト例の追加などを経て現在の版に至りました。

この記事は Zenn からのクロスポストです。

この記事は はてなブログ からのクロスポストです。