この記事は、3-shake Advent Calendar 2025 3日目のエントリ記事です。
上巻の振り返り
上巻では、Commandsを使ったブログレビュー環境の基礎を説明しました。
/deep-thinking-promptで書く前に深く考える/blog-quality-reviewで6つの観点からレビューする/ai-humanity-checkでAIっぽさを検出する/full-reviewで全自動レビューする
これらのCommandsは、レビュー観点を構造化し、一貫性を担保してくれます。
下巻では、より高度なSubagentsの活用へ入る前に、いくつかの話題を深掘りします。
AIに記事を書かせるとは何か
「AIに記事を書かせる」という言葉をめぐって、しばしば議論が起きます。「それは本当にあなたの記事なのか」「AIが書いたものに価値があるのか」。
私の答えは明確です。記事はほとんどAIに書かせています。しかし、価値の源泉は私にあります。
手書きで書いているという人も別に紙に直接書いている訳ではないでしょう。既に、予測変換やLSP（Language Server Protocol）による補完など、さまざまなレベルで「AIやコンピュータの支援」を受けながら文章を書いています。その延長線上に、生成AIによる執筆があるに過ぎません。
では、私は何を担っているのでしょうか。
「身体性」を供給しています。
ここで言う身体性とは、知識が「情報」から「経験」へと変容する過程で生じる、一人称的な認知の軌跡です。
知識と経験の断絶
たとえば、あるエンジニアがRustの所有権システムを学んでいるとします。The Bookを読み、概念は「理解した」つもりでいました。しかしいざコードを書くと、コンパイラからcannot borrow as mutable...というエラーを食らいます。「ルールは知っているはずなのに、なぜ」——この「知っている」と「書ける」の間にある断絶こそが、身体性が欠落している状態です。
そして、その断絶を越えた瞬間の記録があります。「なぜエラーになったのか格闘し、イテレータの内部構造に気づき、腹落ちした瞬間」——これこそが身体性を伴った学習の言語化です。それは他者に伝達可能な「生きた知見」となります。
この「苦闘から理解への遷移（プロセス）」だけは、AIには生成できません。AIは私の代わりに試行錯誤できませんし、私の代わりとしてコンパイラに叱られて悔しがることもできないからです。
AIの役割は、私が供給した「生の体験（身体性）」を、他者が読める文章として整えることにあります。混沌とした思考を構造化し、読者にとって消化しやすい形に変換します。それは編集者の仕事に近いです。
私が素材（身体性）を提供し、AIが構造化し、私がレビューして調整します。この協働のプロセス全体が、現代における「執筆」なのです。
「流暢な嘘」という罠
一方で、「AIで書いた記事には価値がない」という批判も、ある意味では正しいです。問題の本質は「AIを使ったこと」ではなく、「検証というプロセスが抜け落ちていること」にあります。
AIに丸投げして出力された文章には、不正確な情報の垂れ流しという致命的なリスクが潜みます。
厄介なのは、AIの生成する文章が文法的に完璧で、論理の構成も美しすぎることです。人間が書いた拙い文章なら「この人、理解していないな」と直感的に警戒できます。しかし、AIの出力は「もっともらしさ（Plausibility）」に特化しているため、嘘であってもスルスルと頭に入ってきてしまいます。
これを検証せずに公開するのは、ブレーキの効かない車を公道に放つようなものです。
LLMは確率的に「次の単語」を選んでいるに過ぎません。そこに真偽への誠実さは存在しません。だからこそ、その確率の波を制御し、事実という地面に杭を打つのは、人間にしかできない仕事です。
私たちは、AIというエンジンの出力に酔うのではなく、冷静な「監修者」であり続けなければなりません。しかし、この監修作業を人間の力だけで行うには限界があります。
だからこそ、「AIを監視するAI」が必要になるのです。
それがこれから紹介する「Sub-agents」によるレビュー体制です。
Commandsの限界とSub-agentsの登場
上巻で紹介したCommands（/blog-quality-reviewなど）は便利ですが、長く使っていると2つの困難にぶつかります。
- コンテキストの枯渇: 長文記事に対し、複数の観点で深いレビューを繰り返すと、メインの会話履歴（コンテキストウィンドウ）がすぐに溢れてしまう。
- 専門性の欠如: 1つのプロンプトにあらゆる指示を詰め込むと、焦点がぼやけ、鋭い指摘ができなくなる。
そこで導入したのが、Claude Codeの強力な機能、Sub-agentsです。
Sub-agentsとは何か
https://code.claude.com/docs/en/sub-agents:embed:cite
Sub-agentsは、特定のタスクに特化した自律的なAIワーカーです。これまでの「Commands（定型文の挿入）」とは、根本的にアーキテクチャが異なります。
1. コンテキストの分離（Context Isolation）
これが最大にして最強のメリットです。通常、長い記事をレビューさせると、「思考過程」や「中間生成物」でメインの会話履歴が埋め尽くされてしまいます。しかしSub-agentsは、メインとは独立した別のコンテキストウィンドウで作業します。完全にレビュワーに徹することができます。もちろんデメリットもあるので使い分けが必要です。
User │ ▼ Main Agent │ [Delegate] 記事テキストを渡し、レビューを依頼 ▼ Sub-Agent (Reviewer) ┃ ★独自のコンテキストで思考★ ┃ 1. 全文読み込み ┃ 2. 批判的検討 ┃ 3. 推敲（ここのトークンはメインには見えない） ┃ ▼ Main Agent (レビュー結果の要約のみを受取) │ ▼ User (修正案の提示)
メインエージェントが受け取るのは、Sub-agentが導き出した「結論」だけです。これにより、メインのコンテキストを汚染することなく、大量のトークンを使った深い推論が可能になります。
2. 自律的な委譲（Delegation）
Commandsはユーザーが手動で呼び出すものですが、Sub-agentsはメインのエージェント（Orchestrator）が必要だと判断した時に自動的に呼び出されます。
「この記事、なんか読みづらいから直して」と指示するだけで、メインエージェントが「これは『文章校正エージェント』と『構成作家エージェント』の出番だ」と判断し、仕事を割り振ります。
私が実際に配備しているSub-agents
私は現在、ブログ執筆チームとして以下のSub-agentsを .claude/agents/ に配備しています。実際にはもっといますが、今回は3つだけ実際に使っているものを紹介します。
1. narrative-architect.md （物語構造の専門家）
技術記事であっても、読者の感情を動かす「物語」が必要です。このエージェントは、技術的な正しさには口を出しません。その代わり、「読者の感情の旅路（Emotional Journey）」だけを見ます。
- 役割: 導入で共感を得られているか。解決策の提示でカタルシスがあるか。
- 指摘例: 「機能の説明は正確だが、読者が抱えている『辛さ』への共感が不足しており、解決策の価値が伝わりにくい」
2. fresh-eye-reviewer.md （永遠の初学者）
私の「書き手の呪い」を解くためのエージェントです。ペルソナとして「実務未経験のジュニアエンジニア」が埋め込まれています。
- 役割: 専門用語の困難、論理の飛躍、「なぜ」という素朴な疑問の発見。
- 特徴: 文脈をあえて読まない。「ここまでの説明では、この単語の意味がわからない」と冷徹に指摘する。
3. ai-police.md （AI警察）
「AIっぽさ」を検知し、排除する専門官です。AIが生成した文章特有の「過剰な接続詞」「中身のない美しいまとめ」「冗長な言い回し」を検挙します。
- 役割: テキストの人間らしさ（Humanity Score）の判定。
- 指摘例: 「『〜ということができる』は冗長だ。『〜できる』と言い切るべき。また、この段落の『いかがでしたか』はAI臭いので削除を推奨する」
実践：レビュー体制の構築
これらのSub-agentsを連携させることで、私のブログ執筆フローは完全に変わりました。
ディレクトリ構造
.claude/
├── commands/ # ユーザーが叩くショートカット
│ └── full-review.md # 全体を統括する指示書
└── agents/ # 自律的に動く専門家たち
├── narrative-architect.md
├── fresh-eye-reviewer.md
└── ai-police.md
レビューの流れ
Step 1: 執筆（協働） 私とメインエージェントで対話しながら、記事のドラフトを作成します。私は身体性（エピソード）を話し、エージェントがそれを整えます。
Step 2: 全自動レビュー（委譲）
書き上がったドラフトに対し、私は一言こう告げるだけです。
「/full-review を実行して」
すると、メインエージェントが裏側で複数のSub-agentsを起動します。
- Fresh Eye が「ここがわからない」と文句を言う。
- Narrative Architect が「構成が退屈だ」と指摘する。
- AI Police が「AIっぽい表現がある」と警告する。
Step 3: 統合と修正 メインエージェントは、これらのバラバラな意見を統合し、優先順位をつけて私に提示します。「初学者にとって難解な部分があり、かつAI特有の冗長な表現が残っています。まずは第2章の具体例を修正しましょう」
私はその統合されたレポートを見て、最後に修正します。
まとめ
上巻から下巻を通じて、生成AIエージェントを用いたブログレビュー環境の構築について解説してきました。
- 上巻: ブログの評価基準をCommandsで構造化し、手動レビューの面倒臭さを解消する方法。
- 下巻: Sub-agentsを用いてコンテキストを分離し、専門特化した「編集チーム」を作る方法。
この環境を構築して気づいたのは、私の仕事が「執筆者（Writer）」から「編集長（Editor in Chief）」へとシフトしたということです。
実際に手を動かして書く（Generate）のはAIでしょう。しかし、「何を書くか（企画）」「なぜ書くか（熱量）」「品質は十分か（承認）」を判断するのは、人間にしかできません。
AIエージェントは、我々から仕事を奪うものではありません。我々を、より高次な意思決定を行う「マネージャー」へと押し上げてくれる存在です。
もしあなたが「記事を書くのが面倒だ」「自分の文章に自信がない」と感じているなら、まずは小さなCommandを1つ作ることから始めてみてください。そこには、孤独な執筆作業とは違う、頼れるバディとの協働が待っているはずです。
