X運用 再設計 v2

2026-08-18

投稿は止まっていなかった。止まっていたのは投稿を見に行く経路と素材の供給で、直すのは人ではなく仕組みの側。今週P0の9件を片付ければ、Keitaの手は承認だけで回る。

0Keitaが決めたこと（採用済み）

1何が起きていたか

壊れていたのは投稿ではなく、投稿を見に行く経路だった。X上には8/15~8/18に4本が公開されているのに、ローカルの台帳は8/15で止まっている。

素材・リプ先・公開確認・フォロワー取得のすべてがログイン済みChromeという1本の足に乗っており、そこが落ちると同時に全部が沈黙する。

2新しい運用モデル

Notion新計画の3層の振り返りループ（日次・週次・月次）はそのまま採る。変えるのは担当だけ。

Fableは工程表に登場しない。Slackへ書き込むのはClaude1本を維持し、Codexは承認カードのJSONを置くところまでを担当する。

実績と気づきが上がる 日次ループ 毎朝、7項目を見る 維持1つ・変更1つ 本日の目標を置く 結論は次の原稿へ直行 週次ループ 週1回 21:00 ET テーマ別・形式別の順位 維持・変更・停止を決める 変えるのは原則1つだけ 月次の編集計画 週次で更新する 4週間のテーマと形式 投稿カレンダーへ登録 計画承認はKeita 翌週の方針・型・本数が降りる

振り返りが計画の起点になる。日次は週次に材料を渡す役で、単独では戦略を変えない。

工程担当やること
素材集めSonnetWebSearchで毎日5件。X API有効化後はAPI searchでXポスト主素材を補う
企画・執筆ラフ案Codex xhigh会議記録・過去投稿・実績から週次の編集計画を作り、各投稿の初稿を出す
公開前レビュー機械 + Codex xhigh機械チェックを通してから7項目を採点。不合格ならCodexが書き直す
仕上げ・承認Keitaラフ案を直す。プレビュー画像つきの最新版カードに✅。旧版の✅は失効
投稿・予約Codex xhighX API v2で投稿。監査ログをrepoに残す
投稿検知・計測機械1日1回以上、投稿・フォロワー・反応をX APIで取得して台帳へ書く
日次講評・週次の文章Opus数字を日本語にする。週次の方向性1行はKeitaが決める
監視OpusCodexの採点が前回と矛盾していないか、ルール違反を素通ししていないかを見る

Slackは5本に分ける。人が読むのは #x-plan（週次計画と方針）、#x-drafts（ラフ案と事前レビュー）、#x-approve（最終版と✅、プレビュー画像）の3本。機械ログは #x-metrics（日次レポート、投稿検知、フォロワー）と #x-ops（障害・再起動・ブレーカー通知）に落とす。今は1~2本に全部が流れ込んでいる。承認カードにはプレビューアプリが作るXカード風のPNGを必ず添付し、平田さんへの通知は廃止する。

3品質を保つ仕組み

採点を1つのモデルの主観に任せるのをやめる。評価は機械チェックとCodex xhighの2層にする。

Opus/Sonnetは採点しない。Claudeの仕事は採点そのものではなく、採点がブレていないかを見張ることに限定する。

  1. 1層目は機械。字数、禁則、URL、直近5投稿との重複、『バズる書き方』の4関門を質問形式にしたチェックリスト。ここを通らない原稿は採点に進まない。
  2. 2層目はCodex xhighの7項目採点。フォロー理由／共有理由／一次情報／アカウント整合／差分／公開安全／数値目標。1~5が各4/5以上、公開安全に未解決なし、数値目標が入力済みで合格。1つでも欠ければ承認依頼を出さずCodexが書き直す。
  3. Claudeは監視役。同じ論点で前回と逆の判定が出ていないか、ルール違反を素通ししていないかだけを見る。点数は付けない。
  4. 週1回、一致率を測る。同じ原稿を2モデルに再採点させ、判定の一致率を記録する。ブレを印象でなく数字で見る。
  5. 取れない指標は0にしない。投稿別のFollows、Unfollows、Shares、Detail expandsは確実には取得できない。取得不可のときは「取得不可」と書き、合格条件から外して代理指標で見る。KGIはフォロワー純増だけに絞る。
  6. 時間軸を混ぜない。2hは初速の確認だけ、24hで翌日の変更を決め、48hを正式な比較値にする。1投稿で戦略を変えない。型は同形式3本、正式ルール化は10本または2週連続の再現。

4止まらないための仕組み

「止まらない」の定義を決める。Keitaが何もしなくても、Fableが居なくても、Chromeが落ちても、各工程が1日1回は前に進む経路があること。

人手が要る工程は承認だけに限定する。それ以外で人を待つ設計は作らない。

  1. モデル梯子を1箇所で宣言する。工程ごとの1番手・2番手を設定ファイルに書き、スクリプト内のハードコードは撤去する。ブレーカーはFable専用をやめて梯子全体に一般化し、過負荷はCLIの--fallback-modelに任せる。
  2. 検知は「見に行く」に統一する。投稿・フォロワー・反応はX API v2で1日1回以上取得する。Keitaのスクショは「講評してほしい時」のオプションに格下げする。
  3. Chrome依存を廃止する。素材・リプ先・公開確認・フォロワー取得の全部がログイン済みChromeに乗っており、8/4以降7回落ちている。単一障害点をAPIに置き換える。
  4. agmsgの名義をセッション単位にする。from=role@session8を追加し、to=roleはブロードキャストとして温存、to=role@session8でセッション宛。返信の既定は「直前に話しかけてきたfrom宛」。5ファイル60~110行の変更で済む。
  5. Slackへ書くのはClaude1本のまま。Codexは承認カードのJSONを置き、Claudeが投稿する。二重投稿と監査の崩壊を避けるため。X API経由の投稿だけは、監査ログをrepoに残す条件でCodexに許可する。
  6. 正本はrepo、Notionへは一方向。repoのYAML/MDをCodexが毎日Notionへ書き出す。Notion側の手編集は週次振り返りでrepoへ取り込む。逆流はさせない。
  7. Fableは常設ジョブから外す。週1回、Opusが作った200行以下のブリーフを読んで設計を更新するだけ。Opus/Sonnetの返答が読みにくい問題は、出力形式を「結論3行、根拠、未確認」に固定して潰す。

5今週やること

設計の合意を待たずに直せるものだけを並べた。上から順に、止まっているものを動かす。

P0-4はKeitaの2分作業で、これが通ると6・7・8の作り方が確定する。

やること担当完了条件
P0-1 x-reviewのCLIピンを2.1.234へ上げるSonnet再起動して常駐が立ち上がる。ピン更新手順をhandoffに1行追加する
P0-2 ディスクの空きを作るSonnet/System/Volumes/Dataが96%を下回り、ENOSPCが再発しない
P0-3 x-materials-appendの時間窓バグを直すSonnet05:40 ET着信が処理される。skip時にMAX_IDを進めない
P0-4 X APIの有効化（進行中）Keita403 client-not-enrolledが消え、searchと投稿分析が返る
P0-5 agmsg名義のセッション化Sonnet実装
Codex xhighレビュー		2セッション同時起動で、宛先違いのメッセージが混ざらない
P0-6 投稿検知ジョブを作るSonnet毎朝1回、X上の実投稿が台帳に追記される。API有効化までは読み取り専用のChromeジョブで暫定運用
P0-7 素材供給をSonnetへ正式移管Sonnet7日連続で5件。Codexを素材工程から外す
P0-8 プレビューアプリを作るSonnet本文からXカード風のPNGが出て、承認カードに添付される
P0-9 Slackチャンネル5本を作るKeita作成
Opus配線		5本が存在し、日次レポートが#x-metricsに届く

6Keitaにまだ聞きたいこと

  1. SlackへCodexが直接書き込めるようにするか。当面はCodexがJSONを置きClaudeが代理投稿する前提で組んでいる。権限を渡すなら、二重投稿を防ぐ書き込み先の分離が必要。
  2. shisou-dbは参照専用のアーカイブに落としてよいか。更新ジョブを止め、執筆の材料として読むだけにする案で進めている。
  3. リプライの前提はどちらを採るか。「0→1,000フェーズで最大の成長ドライバー」と「フォロー外のリプライはFor You候補から除外される」で新旧が逆を向いている。4週間の実験設計はこの前提で結論が変わる。
  4. KGIの起点T0をいつにするか。判定式は週末から週初を引く形で確定しているが、8/18 09:00 ETの公式フォロワー値は未取得。API有効化日に置き直すか、非公式値で始めるか。
  5. 二段階承認の「計画承認」をどこでやるか。本文承認はSlack最新版の✅と決まっているが、計画承認は場所も期限も失効ルールも決まっていない。

事実は verification.md / facts2_*.md で確認済み。