チャットの雑談を、一言で翌日のブログ記事に変える導線を作りました。鍵はAIに要約させることではなく、「発注書」を書かせることでした。タイトルだけを渡すと、体験談の抜けた「別の記事」が生まれます。この記事は、その発注書方式と、冒頭だけ会話形式にするDialogueコンポーネントを入れた実装記録です。そしてこの記事自体が、その仕組みで生まれた第1号です。
対象読者は、AIエージェントで発信やコンテンツ運用を自動化したい実務者です。持ち帰ってほしい結論を先に置きます。会話から記事への自動化で壊れるのは要約工程です。具体が削られます。保存すべきは、主張と構成、そして体験談・数値・エラー文の原文です。
埋もれる知見と、記事にする最短経路
チャットで一番いい話が出るのは、たいてい別のスレッドです。実装で詰まって相談しているとき、二つの案を比較して迷っているとき、失敗を振り返っているとき。そこで言語化された判断は、記事1本ぶんの価値があります。
問題は、その知見に記事化への最短経路がなかったことです。スレッドは翌日には流れます。「あとでまとめよう」と思った内容は、まとめる頃には細部を忘れています。覚えているのは結論の骨だけ。「なぜその案を捨てたのか」「どの条件で失敗したのか」「そのとき何を見て判断を変えたのか」という、一番おいしい部分から先に蒸発します。
やっかいなのは、骨だけ残っても記事は書けてしまうことです。結論を知っていれば、それらしい解説はいくらでも組み立てられます。できあがるのは、どこかで読んだような一般論。実際に手を動かした人にしか書けない箇所が、まるごと抜け落ちます。読者が本当に読みたいのはそこなのに、です。
うちのブログは、Notionの仮説データベースに 【blog】 で始まる仮説を起票すると、翌日の執筆Routineがそれを最優先で記事化する仕組みで回しています。注文を受け取る口はすでにありました。足りなかったのは、チャットの会話をその注文口へ流し込む導線です。
既存の注文口に乗せる
最初に設計したのは、素直な起票スキルでした。会話の最後に「これ記事化して」と言えば、その話題をNotionの仮説として登録する。翌日の執筆部隊が拾って記事にする。ここまでは既存の仕組みに乗せるだけで済みます。
このとき私は、起票する内容をタイトル一行で足りると考えていました。「チャットをブログにする話」のような見出しを立てて、あとは翌日の執筆側にうまくやってもらう。会話の全文を持ち回すより軽いし、長い文章を短くまとめるのはAIが得意なはず。そう踏んでいたわけです。
いま振り返ると、この「まとめるのが得意」という前提そのものが落とし穴でした。要約が得意だからこそ、渡した情報が薄ければ薄いなりに、それらしく膨らませて埋めてしまう。足りない具体を、想像で補ってしまうのです。
「タイトルじゃ弱い」で設計が覆った
その案に、発注側から待ったがかかりました。ほぼ原文のまま引くと、こうです。
タイトルじゃ弱いんじゃないか。全く別の内容になっちゃうかもだし、体験談的な大事なものが抜ける気がする。
これが正しかった。タイトルだけを渡された翌日の執筆側は、そのタイトルから自由連想で記事を書きます。書けてしまうからこそ危うい。もっともらしい記事は完成しますが、実際にあった失敗も、案を捨てた理由も、そのとき出た数値も、どこにも入りません。タイトルは記事の看板であって、中身の保存形式ではなかったわけです。
そこで方針を変えました。渡すのは要約ではなく「発注書」にする。この二つは、短くまとめるという見た目こそ似ていますが、目的が正反対です。要約は人間が読むための圧縮で、削ることに意味があります。発注書は記者が書くための保存で、素材を落とさないことに意味があります。要約は結論へ近づけるほど良く、発注書は結論の手前にある具体を抱えたままにするほど良い。同じ「短い文書」でも、設計思想が逆なのです。
だから発注書では、AIに上手にまとめさせないことを目標にしました。まとめさせず、素材をそのまま運ばせる。翌日の執筆側には、その素材を起点に書く以外の選択肢を残さない。書き手の自由を、良い意味で狭めておく設計です。
発注書には何を書かせるか
発注書の節構成は、「記事を書くのに必要な素材を落とさない」ことだけを基準に決めました。実際に使っている構成はこの7つです。
- 主張: 記事で言い切る結論を1〜2行で。ここがぶれると記事全体が拡散する
- 読者と結論: 誰に向けて、何を持ち帰ってもらうか。想定読者を固定して脱線を防ぐ
- 構成案: 起承転結のどこで何を出すか。特に「転」をどこに置くかを決めておく
- 素材（必ず使う）: 体験談・数値・エラー文を原文に近い形で。ここが発注書の心臓部
- 事実と出典: 一次情報のリンクと、自社実装なのか外部事実なのかの区別
- キーワード・内部リンク: 狙う検索語と、貼るべき内部記事
- 冒頭対話案: 導入の会話フックの素材
肝は「素材（必ず使う）」です。ここに体験談やエラー文を原文近くで書いておくと、翌日の執筆側はそれを起点にするしかなくなります。たとえばこの記事では、発注書の素材欄に「タイトルじゃ弱い」という発注側の一言がそのまま入っていました。だから、いまその引用が記事の転換点として残っています。連想で埋めた作り話ではなく、実際にあった発言が、素材欄を経由して本文に届く。これが要約との決定的な差です。
逆に言うと、素材欄が空なら、その記事はいくら文字数を伸ばしても中身が空のままになります。数値やエラー文が発注書に無ければ、本文にも入れない。無いものを「あったこと」にして書くのは、この仕組みでは起きてはいけない失敗だからです。厚みは、水増しではなく素材の量で決まります。
この構造は、役割の分離にもなっています。会話をしていた側が発注書で素材を出し、翌日それを別の書き手が記事にする。発注する人と執筆する人が分かれているからこそ、「素材は発注書に書いてあることが全て」という約束が意味を持ちます。執筆側が手元の記憶や想像を勝手に足せる関係だと、この約束はすぐ形骸化します。分けたうえで、渡す形式を発注書に固定する。ここまでやって、はじめて素材の忠実さを仕組みで担保できます。
冒頭だけ会話にする——Dialogueの導入
設計を詰めているとき、発注側からもう一つアイデアが重なりました。これも原文に近い形で引きます。
対話形式のコンポーネントはどうですか。冒頭だけ会話にする。それなら会話体験も奪われないし、臨場感高めで伝わるかも。
記事が生まれた実際の会話を、そのまま吹き出しで見せる。ただし全編を対話にすると、かえって読みづらくなります。会話は臨場感を出すのは得意でも、順を追った説明には向きません。そこで「冒頭のフックだけ」という線引きをつけました。この線引きが効いていて、導入では実際のやり取りで引き込みつつ、本文は地の文できちんと積み上げられます。
Dialogueコンポーネントの運用ルールは絞ってあります。
- 記事冒頭の導入フック専用にする。本文の途中や結論には置かない
- 4〜8往復を目安にし、1発言は60字程度までの短い文にする
- 実在した会話の再構成のみに使う。読みやすく整えるのは可、なかった発言の創作は不可
- 対話の素材は、発注書の「冒頭対話案」を正とする
この記事の冒頭にある会話も、発注書に書いた対話案を再構成したものです。言い回しは短く整えていますが、やり取りの中身は実際にあったものだけ。表情の指定も、実際に困っていた場面にだけ添えています。
創作を弾く構造にする
自動化で一番こわいのは、臨場感を出すために「あったことにされる会話」が混ざることです。吹き出しは説得力が強いぶん、そこに嘘が乗ると被害も大きい。ここは運用ルールのお願いだけで済ませず、仕組みで潰しました。
まず、会話が記事に入る経路を、発注書の「冒頭対話案」ただ一つに限定しています。執筆側が本文の途中で思いつきの対話を差し込むことはできません。会話が入る扉が一つしかなければ、その扉の中身だけ管理すればいい。
次に、公開前には読み取り専用の審査エージェントを通します。素材にない事実や、発注書になかった発言が混ざっていれば、そこで弾かれます。書ける自由を最初から狭くしておくほうが、後からすべてをチェックするより安全でした。事前に間口を絞る設計と、事後に全部を疑う設計とでは、前者のほうが破れにくい。審査を執筆から独立させた話は、別の記事にまとめています。
Claude Codeのサブエージェントで公開前レビューを分離する｜critic実装記録Claude Codeのサブエージェントで、公開前レビューを執筆エージェントから分離した実装記録。読み取り専用のcritic定義、判定基準のファイル固定、PASS/FAILの機械判定、修正2回上限と隔離まで、実際に運用している構成を解説します。www.tentspace.net
記法の正本は一箇所に置く
Dialogueのようなコンポーネントを足すと、すぐ次の問題が出ます。「その記法を、書き手全員がどうやって知るのか」です。
うちの書き手は、複数のスキルやプロンプトに分かれています。しかも中身はAIエージェントなので、記法を知らなければ使えないし、間違えれば静かに壊れます。ここで各プロンプトに記法をコピーして回ると、更新のたびに全部を直すことになります。直し忘れが一つでもあれば、そこから食い違いが始まる。書き手が増えるほど、この同期コストは効いてきます。
そこで、記法の正本はサイト側リポジトリの docs/writing-guide.md 一箇所に集約しました。各スキルやプロンプトは記法そのものを持たず、「詳しくはwriting-guideを見ろ」というポインタだけを持ちます。新しいコンポーネントを追加したら、まずこの正本に記法と使い所を追記する。ルールはこの一本だけ、というのが大事です。正本に一度書けば、翌日から全エージェントに同じ記法が伝わります。スキルそのものをどう設計しているかは、こちらの記事に書いています。
鮮度が落ちる前に、翌日書く
もう一つ、タイミングの設計があります。発注書が起票されると、翌日の執筆Routineがそれを最優先で拾います。数日寝かせず、翌日に書く。これは意図的です。
会話で知見が言語化された直後が、いちばん解像度が高い瞬間です。判断の理由も、迷った選択肢も、まだ手元に温度を持って残っています。ここを逃すと、素材そのものは発注書に保存されていても、それを記事へ展開する側の記憶が薄れます。発注書は「何を書くか」を固定できますが、「その素材にどれだけ肉付けできるか」は書き手側の鮮度にも左右されます。だから、保存と執筆の間隔をできるだけ詰めています。
保存で素材を守り、翌日の執筆で鮮度を守る。この二段構えがそろって、はじめて「会話の温度が残った記事」になります。どちらか片方だけでは、素材はあるのに平板、あるいは勢いはあるのに具体が無い、という記事になりがちでした。
「これ記事化して」で始まる運用
組み上がった導線は、拍子抜けするほどシンプルです。別スレッドで話していて「これはいい」と思ったら、最後に「これ記事化して」と一言添える。するとNotionに発注書が起票され、体験談も、捨てた案の理由も、エラー文も、原文のまま保存されます。翌日、その発注書を執筆Routineが最優先で拾い、冒頭は実際の会話から始まる記事になって出てきます。
要約に頼っていたら、この記事は「会話を記事にする方法」という当たり障りのない解説になっていたはずです。発注書にしたから、「タイトルじゃ弱い」という一言が転換点として残り、Dialogueのアイデアが誰の発案だったかまで記事に残りました。仕組みが素材を守ってくれた、ということです。
会話から記事への自動化で守るべきは、要約する能力ではありません。具体を落とさずに運ぶ形式です。壊れやすいのはいつも要約の側で、そこに一番おいしい素材が詰まっています。まとめさせるのをやめて、そのまま運ばせる。この記事自体が、その形式で生まれた最初の一本です。