AIにSNSの投稿作成を頼むと、どこかで見たような一般論や、過度な煽り文句(いわゆるバズ構文)が出力されがちです。また、毎回プロンプトを手入力していると、投稿ごとにトーンや構成がブレてしまい、過去に検証された反響の出やすい型を再現できません。
今回、SNS投稿の制作を担当するAIエージェントにおいて、「判断の手順(型)」と「発信者やアカウントの制約(設定)」を明確に切り離す設計を導入しました。
骨子の作成や構成パターンの適用はAIに任せられるようになりました。ただし、実体験に基づく具体的な数値の確認と、公開の最終判断は人間に残りました。
長期連載「1人法人1000馬力化計画」の第2回として、制作エージェントの指示書設計と、実際に任せた範囲・人に残った作業の境界を記録します(第1回の秘書エージェント設計については「Claude Codeのタスク管理:期日とPRの申し送りを1枚にする方法」を参照)。
課題:都度のプロンプト指示では、型が定まらず一般論に流れる
私の運営するマイクロ法人では、現在2つのSNSを運用しています。
| プラットフォーム | アカウントの性格 | 投稿の主な構成 | 目標頻度 |
|---|---|---|---|
| X | エンジニアリング・複業・FIRE・法人の実践記録 | 要約重視、結論先出し、本文単体で価値完結 | 1日5投稿 |
| Threads | 育児に特化した日常の気づきと試行錯誤 | 共感重視、ストーリーテリング、会話の余白 | 1日5投稿 |
文化も読者層も異なる2つの媒体で、毎日合計10本の投稿を手作業でゼロから考えたり、都度チャット欄に「この内容でX風に要約して」と指示していては、すきま時間がいくらあっても足りません。
さらに、プロンプトを都度手打ちすると、次のような問題が頻発しました。
- 一般論への逆戻り: 背景知識や立場を指定し忘れると、「〜することが大切です」といった当たり障りのない説教調になる。
- 検証済みパターンの喪失: 「落差型(Before/After)」や「結論先出し型」など、過去に反響が確認された構成を再現できず、思いつきの文章になる。
- 禁止事項の再発: 外部リンクへの誘導文や過度な煽り表現など、アカウントとして禁止している書式が混ざってしまう。
これを解決するために、「投稿作成の手順そのもの」と「アカウント固有のルール」を分離して管理することにしました。
解決策:型・設定・実績の3層構造でエージェントを定義する
社内で動かすエージェントの指示書は、次の3層に分けて管理しています。
agents/post-generate/
AGENT.md 型。何をするエージェントか、判断の手順。どの会社・媒体でも共通
config.schema.md 設定項目。動かすために埋める値の一覧(媒体制約、発信者、型、禁止事項)
examples/
sukima-keiei.md 自社での設定例=実績の証拠(X版・Threads版の実際の設定値)
最大の特徴は、型(AGENT.md)の中に自社固有の言葉(文字数上限、特定のアカウント名、テーマ名など)を一切書かない点です。
1. 型(手順)に書くこと:どの媒体でも変わらない制作の流れ
AGENT.md では、どのような素材からどのような手順で投稿文を組み立てるか、そのプロセスだけを規定します。
- 素材の整理と事実抽出: 題材から「具体的な出来事」「数値」「独自の判断基準」「手直しの経緯」を抜き出し、未確認の成果や架空の体験談を排除する。
- 構成パターン(型)の選定: 設定の
patterns(検証済みの型リスト)から、素材の性質に最も適した型を1つ選ぶ。 - 本文の作成: プラットフォームの文字数制約を守り、本文単体で読者が知見を持ち帰れる構造にする。設定された一人称やトーンを維持する。
- 禁止事項のセルフチェック: 設定の
forbidden(禁止ワード・禁止パターン)に抵触していないか自ら検査する。 - 補足情報の作成: 参照元記事のURLや追加解説が必要な場合は、メイン投稿とは別のリプライ・スレッド用テキストとして作成する。
この手順自体は、XでもThreadsでも、将来別の媒体や他社向けに展開する場合でも共通です。
2. 設定(config)に書くこと:アカウントごとの規律と検証済みの型
一方、アカウントごとの個性や制約は、設定ファイル(config)側で定義します。
例えば、X担当として稼働している「010 柏木 柱」と、Threads担当の「001 育田 案」では、同じ制作手順を使いながら、設定を次のように切り替えています。
| 項目 | X向け設定(柏木 柱) | Threads向け設定(育田 案) |
|---|---|---|
| プラットフォーム制約 | 280 weight以内(全角2カウント、目標200字前後) | 500文字以内 |
| トーン | 実践記録。結論先行で簡潔に要約、情報密度優先 | やさしい・共感重視。日常の試行錯誤を等身大で共有 |
| 採用している型 | ①結論先出し型、②落差(Before/After)型、③3点要約型 | ①共感・日常発見型、②試行と結果型 |
| 本文の完結性 | 本文単体で完結(リンクを踏まなくても理解できる) | 1本完結または分割型(コメント欄で会話を促進) |
| 禁止事項 | 本文中へのURL直書き、続きを隠すクリックベイト煽り | 実務専門用語(AI導入・法人化・FIRE等)、上から目線の説教調 |
型を共通化し、設定だけを差し替える構造にしたことで、「プロンプトをゼロから書き直す」無駄がなくなり、新しいプラットフォームや別ジャンルへの横展開も設定ファイルの追加だけで済むようになりました。
初仕事の記録:素材から投稿案ができるまで
実際に、ブログ記事の技術検証ログを素材として、X担当エージェントに投稿作成を依頼したときの入出力例です。
入力として渡した素材
題材: Claude Codeの実行前フック(Pre-tool hook)の導入記録
事実:
- Bashツール実行前にスクリプトを挟み、保護対象ブランチ(main)への直接pushを機械的にブロックした
- これまで「mainにはpushしない」という運用ルールに頼っていたが、別セッションの作業でヒヤリハットがあった
- 人的注意に頼るのをやめ、フックでexit 1を返すようにしたことで、事故を未然に防げるようになった
エージェントが出力した投稿案
【メイン投稿(218 weight)】
mainブランチへの直push禁止は、運用ルールで徹底しようとすると必ずすり抜ける。
直近の並行作業でヒヤリハットがあり、Bashツールの実行前フックを導入した。
Gitコマンドを監視し、対象ブランチへのpushを検知した瞬間にexit 1で強制終了する。
注意喚起より、物理的に通らない仕組みを先に置くのが確実。
【リプライ投稿】
具体的なフックの実装方法と、Claude Codeでの設定手順はこちらにまとめました👇
(公開済み記事のURL)
【選定した型】落差・Before/After型(ルール頼みの脆弱さ → フックによる物理制御への変化)
本文単体で「何が問題で、どう対策し、何が教訓か」が完結しており、外部リンクを開かなくても読者が学びを得られる構成になっています。また、文字数や禁止事項(本文中のURL直書き禁止)も正しく守られています。
任せられたこと、人間に残ったこと
このエージェントを日次運用に組み込んだ結果、任せられた領域と、どうしても人間に残る領域の境界がはっきりしました。
【AIエージェントに任せられたこと】
- 素材からの論点抽出と、検証済みパターン(型)への当てはめ
- 文字数カウントと改行密度の調整
- トーンの統一(一人称や結びの口調のブレ防止)
- 禁止ワード・禁止パターンの機械的なセルフチェック
【人間に残ったこと】
- 素材となる実体験・一次情報の提供
- 登場する数値や実績の事実確認(ファクトチェック)
- 投稿予約・公開の最終GO判断
特に注意が必要なのが、数値や実績の事実確認です。
AIは文章の座りを良くするために、「作業時間が30%削減された」「3分で導入できた」といった、素材に書かれていない具体的な数字を滑らかに補完してしまう傾向があります。しかし、実録を看板にしているアカウントで架空の数字を混ぜてしまうと、発信全体の信頼性が失われます。
そのため、「素材に明記されていない数字や期間は絶対に出力しない」「未確認の数値は必ず確認事項として人間に返す」という規律をプロンプト側に設けた上で、人間が元データ(コミットログ、帳簿、Googleスプレッドシート等)と突き合わせて確認する工程を必ず挟んでいます。
また、ボタンを押してSNS上に予約・公開する操作は、意図的に人間の手に残しています(絶対ルール「公開はユーザーの明示的なGOが必要」)。
読者が自分の仕事に持ち帰るための3つの要点
社内の業務でAIにテキスト作成や投稿作成を任せたい場合、次の3点を意識すると再現性が高まります。
- 「手順(型)」に固有の値を書かない: プロンプトに文字数やアカウント固有の事情をべた書きせず、設定項目として外部に切り出す。手順が汎用化されれば、別の部署や媒体にもそのまま転用できます。
- 「構成パターン」を選ばせる: 「自由に書いて」と頼むとAIは平均的な文章に収束します。「結論先出し型」「Before/After型」「3点要約型」のように、反響の出やすい骨子パターンを定義し、素材に応じて選択させます。
- 禁止事項には「理由」を添える: 「URLを貼るな」「煽るな」と書くだけでなく、「なぜ禁止なのか(役割分担が崩れるから、信頼性を損なうから)」を明記することで、AIの文脈理解が安定し、ルールのすり抜けを防げます。
次の検証:反響分析と制作のループをつなぐ
投稿を安定して量産できる体制は整いました。しかし、一度決めた構成パターン(型)が、現在も読者に受け入れられているかどうかは別問題です。
投稿制作エージェントが使う「検証済みの型」は、思いつきで増やすのではなく、公開後の実績データを分析し、実際にエンゲージメントが高かった投稿から逆算して抽出する必要があります。
次回は、公開済み投稿の反響データ(表示回数、いいね、返信、リポスト)を集計し、次の勝ちパターンを抽出する「反響分析エージェント(post-analyze)」の設計と運用について記録します。