記事を書く記事

まとめ

本記事では、LLMエージェントによる記事執筆ワークフローの設計過程で得た教訓と、筆者が採用したアプローチを紹介します。

1. 人間の執筆プロセスをLLMにそのまま適用しても機能しなかった経験 — 能力の非対称性
2. 筆者が採用した反復パスアプローチの設計思想 — 粗い全体像から段階的に詳細化
3. 収束制御の設計判断 — 別エージェントによる監査とコンテキスト分離

はじめに

技術記事の執筆は、現状のLLMにとって比較的難しいタスクだと筆者は考えています。失敗しがちなタスクをあえてLLMに委せて、LLMの能力傾向を把握し、ワークフロー設計のテクニックを習得することを目指しました。

本記事では、Claude Codeのスキルとして記事執筆ワークフローを実装した経験をもとに、2つの失敗から教訓を抽出し、拡散モデルに着想を得た反復パスアプローチと収束制御メカニズムの設計判断を紹介します。

本記事は設計思想の解説です。具体的なプロンプト例や実装コードは含みません。

検証環境: Claude Code v2.1.92（2026-04-07時点）
本記事の内容は検証時点での動作を記録したものです。将来のバージョンで挙動が変更される可能性があります。

失敗例1: ナイーブアプローチ

最初に試したのは、LLMへの丸投げです。失敗することを前提に、どのような傾向で失敗するかを観察する目的で、記事のアイデアとおおまかな構成を渡し、「この内容で記事を書いて」と指示します。

LLMは指示にしたがって記事全体を1回で生成します。しかし、結果には特徴的なパターンが現れます。どのセクションも冗長な説明や装飾的な表現で膨れあがってしまうのです。補足的なセクションも核心的なセクションも同じように詳しく書かれ、記事全体のメリハリが失われます。

この過剰な密度は、LLMの生成プロセスに起因する構造的な傾向です。1回の生成で記事全体を書かせるアプローチでは、セクションごとの情報量をユーザーが制御できません。

失敗例2: 段落逐次承認アプローチ

情報密度を制御するため、次に試したのは段落単位の逐次承認ワークフローです。

まず、いままで執筆した記事をLLMに渡し、いくつかの類型に分類させました。これをもとに、類型ごとの記事スケルトンを作成しました。この記事スケルトンに肉付けを行っていくことで、構成が制限なく肥大化していく問題を防ぎます。

LLMが1段落を生成し、人間が内容を確認・修正してから次の段落に進みます。人間が各段落の品質を担保するため、情報密度の問題は軽減されました。しかし、このアプローチには2つの問題があります。

情報密度の制御を人間に依存している

段落逐次承認は、各段落の情報密度を人間が確認することで品質を担保します。しかし、これはLLMの密度過剰という根本問題を解決しておらず、人間の判断力に転嫁しているだけです。LLMが生成するたびに人間が密度を調整するのは、問題の抑制であって解消ではありません。

細切れのレビューが集中力を削る

人間が各段落を承認するたびにワークフローが停止します。1つの記事を書くために大量の承認が必要になり、執筆の大部分が人間の応答待ちで占められます。また、一度の承認ごとに数十秒の待ち時間が発生し、集中力を途切れさせます。

この問題は、エージェントの自律性と人間の介入頻度のトレードオフとして一般化できます。詳細な分析は「エージェントのログは安く、人間の介入は高い」で扱っています。

ここまでのまとめ: LLM最適化 ≠ 人間の作業プロセス

2つの失敗例から見えてきたのは、人間とLLMの能力の非対称性です：

• LLM

  • 強み： 大きな論理構造の理解と維持、大量のテキストの一括処理
  • 弱み： デフォルトでは緩急の判断が働かない — 指示しなければ、重要でない部分も同じ密度で語る

• 人間

  • 強み： 全体と細部の両方に対して、一貫した文脈で理解を維持できる
  • 弱み： 入出力の速度、集中力の維持

逐次的に書いて各段落を確認するプロセスは、人間の入出力の遅さと、長時間にわたって集中力を維持できないという弱みによって律速されます。ワークフローを両者の特性に合わせて再設計する必要があります。

転換: 拡散モデルからの着想

画像生成の拡散モデルは、ノイズから始めて段階的にディテールを追加していくプロセスで画像を生成します。1回で完成画像を出力するのではなく、粗い全体像から段階的に詳細化します。

この「全体を粗く作ってから均等に解像度を上げる」という構造が、密度の過剰を制御する手段として応用できると考えました。失敗例2で導入したスケルトンに情報量の重み付けを加え、パスを重ねるたびに全セクションを重みにしたがって詳細化すれば、特定のセクションだけが詳しくなる偏りを構造的に防げます。

ただし、拡散モデルとの対応関係は着想の経緯にすぎません。ノイズ除去プロセスと記事の段階的詳細化は、技術的なメカニズムとしては異なります。

失敗例との対応

反復パスアプローチは、失敗例2の問題に対して異なる設計で対処しています。

• 情報密度: セクション重みによる分配で構造的に制御し、人間は文脈と表現のレビューに集中できる
• レビュー配置: 執筆パスの後にまとめてレビューを配置し、集中力の消耗を防ぐ

反復パスアプローチの設計

失敗例の教訓と拡散モデルからの着想を組み合わせ、以下の設計方針で記事執筆ワークフローを構築しました：

• 記事全体を1回で完成させるのではなく、複数パスで段階的に詳細化する
• 各パスでは全セクションを一括で書き、セクション間の整合性を保つ
• セクションごとの情報量配分を事前に定義し、偏りを構造的に防ぐ

スケルトンとセクション重み

スケルトンによる構成定義は失敗例2で導入した手法です。反復パスアプローチでは、これにセクション重みを加えました。セクション重みとは、記事全体に対する各セクションの情報量比率です。

たとえば本記事の場合、「反復パスアプローチの設計」に25%、「収束制御」に20%のセクション重みが割り当てられています。一方、「まとめ」や「転換」は5%です。書き手エージェントはこの比率を参照し、主要セクションには段落レベルの詳細な記述を、補助セクションには簡潔な記述を配分します。

セクション重みがない場合、書き手エージェントはセクションの順序にしたがって情報量を配分するため、失敗例1で観察した偏りが再現されます。重みを明示することで、記事の核心部分に意図的に情報量を集中させます。

パス構成: 粗→精の段階的展開

パスは段階的な詳細度を持ちます：

パス	詳細度	各セクションの目安
Pass 1	スケルトン	1文（核心アイデアのみ）
Pass 2	拡張	2〜3文（文脈追加）
Pass 3+	精緻化	段落レベル（例示・コード・詳細説明）

Pass 1はセクションごとに1文だけを書き、記事全体の流れを確立します。この段階では詳細は一切書きません。1文スケルトンによって記事の骨格が明確になり、セクション間の論理的なつながりを検証できます。

Pass 2では各セクションを2〜3文に拡張し、文脈と根拠を追加します。Pass 3以降では段落レベルの本格的な記述に詳細化し、具体例やコードブロック、詳細な説明を加えていきます。

各パスは前パスの出力を参照しながら記事全体を書き直すため、新しい段落を追加するたびにセクション間の整合性を確認できます。

全文書き直しの意図

各パスで記事全体を書き直す設計には、明確な意図があります。

段落単位で個別に拡張するアプローチでは、セクション間の接続が不自然になる、内容が重複する、前半と後半でトーンが変わるといった問題が生じます。記事はセクションの集合ではなく、一貫した議論の流れを持つ文書です。全体を一度に書き直すことで、あるセクションに加えた変更が他のセクションに与える影響を反映できます。

また、全文書き直しは前述の非対称性を活かす設計でもあります。LLMの強みは大量のテキストを一度に処理し、全体の論理構造を維持できる点です。人間が1段落ずつ確認するプロセスでは、この能力を活用できません。全文を一度に渡して書き直させる設計は、このLLMの特性にワークフローを寄せた結果です。

収束制御: 監査エージェントによる自動停止

反復パスアプローチには、「いつ停止するか」という課題があります。パスを繰り返すほど記事は詳細化しますが、ある時点で追加パスが有意義な改善をもたらさなくなります。

この飽和点を検出し、自動停止する仕組みが収束制御エージェントです。

なぜ別エージェントか

収束制御を書き手エージェントとは別のエージェントに委ねている理由は、自己評価バイアスの排除です。

書き手エージェントが自分の出力を評価すると、「改善した」と判断するバイアスが生じます。自分が意図して加えた変更を「価値がない」と判断するのは、人間にとってもLLMにとっても困難です。書き手は変更の意図を知っているため、その意図に引きずられた評価をしてしまいます。

Claude Codeのサブエージェントは、親エージェントのコンテキストを引き継ぎません。書き手エージェントが監査エージェントを起動する際、前パスの記事全文と現パスの記事全文だけを渡します。記事プラン、セクション重み、書き手の思考過程は、サブエージェントの構造上そもそも共有されません。

この設計により、監査エージェントは「記事がどう変わったか」だけを評価します。書き手が何を意図したかに影響されず、差分に有意な情報が加わったかどうかを判断できます。

飽和検出と自動停止

監査エージェントは各パスの前後の記事を比較し、value_added: true/false を判定します。value_added: false が返された時点で、記事は飽和に達したと判断し、パスループを自動停止します。

この判定はセクション単位でも行われます。どのセクションに価値が追加され、どのセクションが飽和しているかの情報は、次パスの書き手エージェントに参考情報として提供できます。ただし、停止判断自体は記事全体に対する value_added の真偽値で行います。

安全策として、最大パス数の上限も設けています。監査エージェントが飽和を検出できない場合でも、上限に達した時点で停止します。

先行研究との位置づけ

本アプローチに関連する既存手法との差異を整理します。

Skeleton-of-Thought (SoT) は、まずスケルトンを生成し、各ポイントを並列に展開する手法です。スケルトンファーストという点では共通しますが、SoTの主目的はレイテンシ削減（並列展開による高速化）であり、反復パスによる段階的な詳細化は行いません。展開は1回で完了します。

Self-Refine は、同一モデルが生成・フィードバック・改善を反復する手法です。停止条件を持つ点では共通しますが、粗→精の段階的展開ではなく、自己改善を主目的に置いており、毎回同じ粒度で改善を繰り返します。

AgentWrite (LongWriter) は、セクション単位でワードカウント目標を指定し、長文を生成する手法です。セクションごとの情報量制御という点では共通しますが、シングルパスの逐次生成であり、反復パスとの組み合わせはありません。

本アプローチの特徴は、これらの要素を組み合わせた点にあります。密度過剰を主問題として設定し、セクション重みによる情報量配分、粗→精の段階的展開、そして別エージェント＋コンテキスト分離による収束制御を統合しています。

適用範囲の制約

このアプローチには適用範囲の制約があります。

セクション構造が事前に定義できる技術記事やドキュメントには適していますが、以下の用途には直接適用できません：

• 創作文： セクション構造が流動的であり、事前のスケルトン定義が創作の自由度を制約する
• 対話形式のコンテンツ： 発話の流れが事前に定義しにくい
• リアルタイム性が求められる用途： 複数パスの反復は処理時間を要する

実用して得た利点

制約がある一方で、このワークフローを実際に運用して見えてきた利点があります。

集約的なレビューが記事テーマへの理解を深める

反復パスアプローチでは、パス完了後にまとめてレビューします。細切れの段落承認とは異なり、記事全体を俯瞰しながらレビューするため、記事テーマに対する自分自身の理解が深まります。レビューの対象がセクション間の整合性や論理の流れになるので、テーマの構造を把握する機会になります。

エージェント出力との比較が執筆技術のフィードバックになる

書き手エージェントの出力と、レビュー後の完成記事を比較することで、自分がどこに手を入れたかが明確になります。エージェントが苦手とする箇所、自分が重視する表現の傾向が浮かび上がり、執筆技術へのフィードバックが得られます。

このフィードバックは人間だけに留まりません。発見した傾向を執筆ルールやエージェントの設定に反映すれば、次の記事から改善されます。記事を書くほどワークフロー自体が育っていく構造です。

プランからドラフトまでの工数がほぼゼロになる

プランファイルを作成すれば、記事ドラフトの生成はエージェントに委ねられます。ドラフトまでの工数がほぼゼロになることで、ドラフトを読んでからプランを練り直すという逆行が気軽にできます。従来の手書きでは、ドラフトを書いた後にプランに戻ることは心理的にも工数的にもコストが高い行為でした。この逆行の敷居が下がることで、プランの質を実際のドラフトで検証するサイクルが回ります。

おわりに

この記事自体が、ここで紹介したワークフローで書かれています。書いてみると、前節で挙げた利点は実感としてありました。レビューでテーマの理解が深まり、エージェントとの差分から自分の書き方の癖が見え、ドラフトを捨ててプランに戻る判断も軽くなります。