このブログ、記事が2本しかない。

「ブログ始めました」と「ポートフォリオ」の2本だけ。始めたのが1月で、もう2月。このブログ自体がポートフォリオであり成長日記なのに、肝心の中身がスカスカという状態だった。

書きたい気持ちはある。でも「何を書くか」を考えるところで止まる。高校で教師をしながら個人開発をしていると、日々の授業準備や校務で忙しくて、ブログのアイデアを練る余裕がない。結局何も書かないまま時間が過ぎていく。

そんな状態が続いていた2月5日、AnthropicがClaude Opus 4.6をリリースした。

目玉機能はAgent Teams。複数のAIエージェントがチームとして協調動作する仕組みで、従来のように1つのエージェントが順番にタスクをこなすのではなく、それぞれが専門的な役割を持って並行して動ける。Claude Codeにもこのエージェントモードが追加された。

このニュースを見た瞬間、止まっていたブログへのモチベーションが一気に戻ってきた。

「これ、ブログの運営チームとして使えるんじゃないか？」

きっかけ：Opus 4.6のAgent Teamsに触発されて

もともとこのブログはAstro + Cloudflare Pagesで構築していて、Claude Codeにはかなりお世話になっていた。記事の構成を相談したり、コードのサポートを受けたり、技術的なメンテナンスも。

でも毎回「記事を書いて」とお願いするだけだと、単発の作業で終わってしまう。Opus 4.6でAgent Teamsが使えるようになったなら、もっと体系的に、組織的にブログを回せるんじゃないか。

Claude Codeには .claude/agents/ ディレクトリにMarkdownファイルを配置することで、カスタムサブエージェントを定義できる機能がある。各エージェントに専門的な役割を持たせて、チームとして連携させる仕組みだ。

Claude Codeに相談してみた。

「myblogを全般的にClaude Codeで運用したいのですが、おすすめの組織を考えてくれませんか？例えば、プロジェクトマネージャーを入れたり等。」

Claude Codeの最初の提案：6カスタムエージェント体制

Claude Codeが最初に提案してきたのは6エージェント体制だった。

ブログ運営に必要な役割がきれいに分かれていて、「お〜」と思った。

でも、自分の中で引っかかるものがあった。

最大のボトルネックは「何を書くか」

Writer（ライター）がいても、書く対象がなければ動けない。Translator（翻訳）も、元の記事がなければ仕事がない。

自分のブログの問題は「書く力」じゃなくて「書くネタを記事にする仕組みがない」ことだった。

日々の仕事や学習でネタ自体はあるはず。でもそれを「記事にしよう」と決めて、構成を考えて、書き始めるまでのハードルが高すぎた。

Claude Codeにそう伝えたら、面白い回答が返ってきた。

「あなたは既にネタの宝庫を持っています。」

そう言って、自分の既存プロジェクトを全部スキャンして、記事ネタを12本以上リストアップしてきた。

全部、自分が実際に作ったもの。ネタがないんじゃなくて、ネタを「掘り出す人」がいなかっただけだった。

7人目：Content Strategist

そこで追加されたのが Content Strategist（コンテンツ戦略家） だ。

単なる「アイデアマン」じゃなくて、戦略家。やることは明確で、

1. 既存プロジェクトをスキャンしてネタを発掘
2. SEO価値・執筆コスト・ポートフォリオ価値で優先順位付け
3. Writer に渡せるアウトラインまで作成

3つ目がポイント。「こんなネタどうですか？」だけだと、結局「いいね、でもいつか書こう」で終わる。見出し構成と各セクションの要点まで用意されていれば、Writer がすぐ動けるし、自分で書く場合でも腰が軽くなる。

8人目：Chronicle（これが面白い）

7人体制の設計が終わったとき、ふと思った。

「この設計過程自体が、ブログ記事になるじゃん。」

Claude Codeとブログ運営の組織を設計している、まさにこの会話。どんな課題があって、どう考えて、どういう結論に至ったか。これこそが自分のブログのコンテンツだ。

でも、こういう「過程」って記録しておかないと忘れる。

そこで8人目のエージェント、Chronicle（メタ記録係） を追加した。

Chronicleの仕事は、Claude Codeとの協働プロセスそのものを記録すること。設計の議論、技術選定の理由、失敗と修正のプロセス。これを構造化して蓄積し、Content Strategist が記事ネタとして活用できるようにする。

つまり、ブログを運営する過程が、そのままブログの記事になる という仕組みだ。

最終的な8人体制

Blog PM（プロジェクトマネージャー）
 ├── Content Strategist（ネタ発掘 + アウトライン）
 ├── Writer（日本語記事の執筆）
 ├── Translator（英語版の翻訳）
 ├── Reviewer（品質チェック）
 ├── SEO Analyst（検索最適化）
 ├── Tech Maintainer（技術メンテナンス）
 └── Chronicle（メタ記録）

記事作成の標準フローはこうなる。

Content Strategist がネタ提案 + アウトライン作成
  → Writer が日本語記事を執筆
    → Reviewer が校正
      → Translator が英訳
        → Reviewer が英語版を校正
          → SEO Analyst が最適化
            → Blog PM がビルド確認 → 公開

品質重視のフローにしたかったので、Reviewer のチェックは日本語版・英語版の両方で入れている。

.claude/agents/ での実装方法

カスタムサブエージェントの定義は .claude/agents/ ディレクトリにMarkdownファイルとして配置する。各ファイルにはエージェントの役割、ガイドライン、注意事項が書かれていて、呼び出されたときにそれに従って動く。

myblog/.claude/agents/
├── blog-pm.md
├── content-strategist.md
├── writer.md
├── translator.md
├── reviewer.md
├── seo-analyst.md
├── tech-maintainer.md
└── chronicle.md

例えば、Writer エージェントの定義はこんな感じだ。

# Writer（ライター）

## 役割
- Content Strategist のアウトラインを元に日本語記事を執筆する
- 一人称は「僕」、既存記事のトーンに合わせる

## 文体ガイドライン
- カジュアルすぎず、堅すぎない語り口
- 技術的に正確だが、初学者にも伝わる説明
- 実体験ベースの語り（「〜してみた」「〜だった」）

このように、各エージェントの役割と制約をMarkdownで定義しておくことで、呼び出すたびに一貫した動作が期待できる。Translator には「直訳ではなく意訳で」「日本語特有の表現は英語的に変換」といった翻訳方針を設定している。

CLAUDE.md（プロジェクト全体の説明ファイル）にもエージェント組織の情報を追記して、どのエージェントから見てもチーム全体の構成が分かるようにした。

Claude Codeエージェント運用で気づいたこと

正直、この体制がうまく回るかはまだ分からない。これから実際に記事を量産してみて、初めてフローの良し悪しが見えてくると思う。

でも、設計の過程で僕が気づいたことがある。

ネタは自分の中に既にあった。 足りなかったのは、それを掘り出して、構造化して、書く状態まで持っていく仕組みだった。

Content Strategist が既存プロジェクトをスキャンして12本以上のネタを出してきた時は本当に驚いた。全部自分が作ったものなのに、「それが記事になる」という発想がなかった。

そしてこの記事自体が、Chronicle が記録した「エージェント設計の過程」から生まれている。メタ記録の仕組みが早速機能した形だ。

次にやること

• この8人体制で実際に記事を書いてみる
• Content Strategist にネタリストを作ってもらう
• フローの改善点があれば調整する
• Chronicle にどんどん記録を蓄積していく

記事が2本しかないブログ、ここから変わっていくはず。

See ya!