Claude CodeでオウンドメディアのAI編集部を立ち上げてみた

※ この記事は、誤字脱字、表現の冗長さ・曖昧さのチェックのためにClaude Codeを利用しています。

TL;DR

Claude Codeの SKILL と AGENTS を使い「マネーブログ　AI編集部」（オウンドメディアの編集部、うまくいけばアフィリエイトでお金儲けしようとした）を構築した。人間が事業計画・役割・ワークフローを定義し、Claude Codeがそれを実装するという役割分担で立ち上げた。
編集長AIに課した承認条件が厳しすぎ、編集者AIが指摘を受けては記事を修正するループが止まらず、コンテキストを食い潰した。これは承認条件を緩和し、完走できるようになった。
しかし、執筆された記事はいかにもAIが書いたような文体になってしまった。どのような文体で表現して欲しいのかを明確に定義しておく必要があったと考えている。
「事業計画を定義し、その評価基準でAIの成果物を評価する」という構造設計は成立した。ただし、今回はコンテキストの消費量が多く、セッションの中で何度もフィードバックループを回すと言うことができなかった。

なぜAI編集部を作ろうとしたのか

オウンドメディアで記事を継続的に発信するのは、手間がかかる。テーマ選定、調査、執筆、校正、ペルソナによるレビューなどを一人でやり続けることには限界がある。Claude Codeを日常的に使っていると、「この一連のワークフローをAIに任せられないか」と考えるのは自然な流れだった。

ただし、やみくもにAIに任せるだけでは成果物の品質が担保できない。AIに何かを評価させるためには、事前に評価基準を定義しておく必要がある。これは前回の『ローカルLLMでSpec Driven Developmentは、まだ難しかった』での経験とも重なる。人間が最初にゴールを定義し、AIがそれに基づいて実装する というSpec Drivenな構造がなければ、AIの出力物を評価し、修正を行うと言う一連のフィードバックループが成立しない。

`.claude`の構成

今回の .claude のディレクトリ構造は次のとおりである。

.claude
├── agents                  # 編集長・編集部員・ペルソナ等のエージェント定義
├── docs                    # オウンドメディアの設計ドキュメント
│   ├── 01_Business-Model
│   │   ├── 01_Concepts
│   │   ├── 02_Design
│   │   ├── 03_Personas
│   │   ├── 04_Value-Proposition-Canvas
│   │   ├── 05_Market-Analysis
│   │   ├── 06_Business-Model-Canvas
│   │   └── 07_RoadMap
│   └── 02_Roles-and-Workflow  # 組織構造・編集ルール等
└── skills
    └── article-workflow    # 記事作成〜品質保証〜最終承認のワークフロー定義

docs には、人間が定義した事業計画を置く。agents と skills には、その事業計画を元にAIが実装した編集部の構成要素を置く。

人間が定義するもの

まず、Claudeと議論しながら事業計画を立案・策定した。具体的には以下である。

ビジネスモデルの定義: エレベーターピッチを起点に、ペルソナ、バリュープロポジションキャンバス、市場分析などを一通り整備した。
ロールと役割の定義: チーム構成、各メンバーの役割と責任、ワークフロー、編集ルール、ペルソナを定義した。

これらがAIの成果物（今回でいうとオウンドメディアの記事）を評価する拠り所になる。評価基準が曖昧なままエージェントを動かしても、その成果物を正しく評価することはできない。

AIが実装したもの

Claude Codeに対して事業計画等の資料一式を渡したところ、Claude Codeは SKILL と AGENTS を自力で設計・実装した。

SKILLの決定: 記事作成から品質保証・最終承認までの一連のワークフローを article-workflow として定義した。実は、事業計画の中で記事の承認基準や差し戻し基準を明示的に定義していなかったが、私が渡した情報をもとにClaudeが適切に補完した。
AGENTSの決定: 編集長、編集部員、ペルソナ（4名）を定義した。エージェントが達成すべき役割だけでなく、エージェント間でどのような情報を受け渡しするかというインターフェースも、ここで定義されている。

実装自体はMarkdownを書くだけなので、手間は大きくない。ただし今回は、SKILL や AGENTS の分割や、どのように書いた方が効果的なのかはClaudeの方が理解しているだろうと判断し、すべてClaudeに任せた。

問題は、Claudeの成果物のレビューである。「編集部の作業内容」と言う一次情報を持ち合わせていなかったため、Claudeの成果物にハルシネーションが含まれているかどうかの判断が難しかった。今回は常識的な範囲で荒いレビューを行った。未知の分野でAIを使った場合、ハルシネーションを見抜くのは非常に難しいため、AI時代においても一次情報の重要性は変わらないか、より増すものと考えられる。

実際のところ、どうだったか

問題1: 編集長の承認条件が厳しすぎてコンテキストを食い潰した

最初に設定した承認条件はこうだった。

- [ ] ペルソナAI（4名中3名）が「推奨」している
- [ ] 編集長AIの「重要な」指摘事項が0件である
- [ ] ビジネスモデルとの整合性が星4つ以上
- [ ] 読者に与える価値が星4つ以上

良かれと思ってペルソナの属性や性格が被らないように設計した結果、3名全員の「推奨」を取り付けることはほぼ不可能だった。編集長AIの重要指摘事項0件もほとんど達成できない水準だった。これにより、編集者AIが修正 → 編集長AIとペルソナAI4名がレビュー → 指摘に基づいて編集者AIが修正 → …となってコンテキストを食い潰し、article-workflow がセッション内で完走できないケースが続いた。

そこで、承認条件を緩和した。

- [ ] ペルソナAI（4名中2名）が「推奨」している
- [ ] 編集長AIの「重要な」指摘事項が1件以下である
- [ ] ビジネスモデルとの整合性が星4つ以上
- [ ] 読者に与える価値が星4つ以上

ペルソナAIの推奨人数を4名中3名から4名中2名に下げ、また、編集長AIの重要な指摘事項を0件まで落としたことでワークフローが通せるようになった。ローカルLLMであれば seed や temperature 等のパラメータを設定できるので修正指示も一貫する可能性があるが、Claudeの場合はユーザが制御できないようになっており「発散する可能性」を制御できず、修正指示が収束しない可能性を考慮した結果である。つまり、AIの決定性・非決定性は、ワークフロー設計の前提条件になると言うことである。

また、星4つ以上の条件は据え置いた。オウンドメディアと事業戦略の整合性を維持しなければ、記事と記事の間に矛盾が生じるため、ここは緩めなかった。結果として、セッション内で3記事程度は作れるようになった。

エージェントを利用する際、チェックの基準を厳しくしすぎると修正ループが発生し、コンテキストを消耗する。実際の挙動を見ながら調整していく必要がある。

問題2: 執筆された記事が似非マーケターが書いたような内容になった

出力された記事は、如何にもAIが書いたような文体になってしまった。原因は明確だ。編集者AIがどのような文体で執筆すべきかを、最初に定義しなかったからだ。コンテキストの消費量を改善しても依然として大量のコンテキストを使うため、そのうちに面倒になり、この改善には手をつけなかった。

実際に出力された記事

「貯蓄分はないもの」を本気で実感するには、時間差が必要だった
「給料が入ったら、先に貯蓄分を別の口座に移しておく」
これは先取り貯蓄の基本として、よく言われることです。私も何度か試しました。けれど、正直に言うと、しばらくすると元に戻してしまうことが多かったんです。
なぜかというと、銀行口座から別の口座に振り込んでも、どちらも「自分の口座」であることに変わりはなく、心のどこかで「いざとなれば戻せる」と感じていたからだと思います。貯蓄口座に移したはずのお金が、結局「予備財布」のような感覚になっていました。
そんな私が、1年間で50万円を貯められるようになったのは、**自動引き落としの「時間差」**を使うようになってからです。
この記事では、なぜ手動の振込より自動引き落としの方が続きやすかったのか、その心理的な仕組みと、私が実際にやっている方法をお伝えします。あなたにとっての「続く仕組み」を考えるヒントになれば嬉しいです。

学んだこと

構造設計としての有効性: 「事業計画を定義し、その評価基準でAIがAIの成果物を評価する」という構造そのものは成立した。ルールとして明確に定義するものと、その範囲内で目的達成方法をAIに考えさせるという分業は機能した。
一次情報の重要性: 人間とAIの関係を構造設計する際、一次情報をどれだけ知っているかが重要になる。今回の場合、実際の編集部がどのように機能しているかを知らなければ、AIの成果物を厳密にレビューすることは難しい。「知らないことをAIに尋ねるのはよいが、それを評価するのは至難の業」という問題は今回も残った。未知の分野でAIを使った場合、ハルシネーションを見抜くのは非常に難しいため、AI時代においても一次情報の重要性は変わらないか、より増すものと考えられる。
コンテキスト管理の設計: コンテキストの消費量が多いと、改善のフィードバックループが回しにくくなる。今回は CLAUDE.md を活用せずに進めたが、コンテキストの使用効率を高める手段を積極的に取り入れるべきだった。
インデックスの必要性: ZettelkastenにおけるStructured Noteのようなインデックスが、AIのコンテキスト展開を段階的に制御するために重要だと気づいた。AIに何をどこまで読み込ませるかを決めるには、インデックス情報が必要になる。これは前回の『ZettelkastenをRAGの情報源として有効活用するには、ノート間のリンクに「意味ラベル」をつけ、型付きのエッジを持たなければならない』での考察とも合致する。今回利用した SKILL や AGENTS では、このインデックス情報はうまく活用しきれていない。そのため、CLAUDE.md を使うことはこの文脈において有効な手段であると考えている。

次にAIエージェントを立ち上げるときに考えておきたいこと

CLAUDE.md のように、コンテキストの使用効率を高める方法を最初から組み込む。
コンテキスト消費量とフィードバックループの速度はトレードオフになる。いかに効率を高めながらループを回すかが設計の肝になる。
文体や表現スタイルは、事業計画と同じタイミングで定義しておく。後からでは手遅れになる可能性が高い。

まとめ

Claude Codeの SKILL と AGENTS を使ったAI編集部は、形として動かすことはできた。人間が事業計画・役割・ワークフローを定義し、AIが実装するという構造設計は機能した。また、その定義が「AIエージェント間」での拠り所にもなっている様子が見てとれた。
承認条件の設計ミス（?）によるコンテキスト枯渇と、文体定義をしなかったことによる記事の品質低下という、二つの失敗が発生した。いずれも設計段階での考慮不足が原因であり、実装後に気づいても取り返しにくい。
コンテキストの消費量を管理しながらフィードバックループを回す設計が、AIエージェント活用の中心的な課題になる。