X投稿と技術メディアへの転載を自動化した自社事例｜人の承認が詰まった工程を、まとめ確認と機械の検査に置き換えた経緯

制作内容

「投稿のたびに手作業で複数媒体へ転載」を続けている方へ

「SNSに投稿したあと、別のメディアにも内容を貼り直している」「気づいたら未転載が何十本も溜まっている」。コンテンツ運用を自分で回している事業者にとって、投稿そのものより『展開作業』のほうに時間を取られているケースは珍しくありません。

この記事では、自社のX（旧Twitter）投稿を作り、note・Qiita・Zennへ転載するまでを自動化した仕組みを紹介します。

作った当初は、展開する投稿の選定・AIが書いた案の採否・最終公開の3か所に人の承認を残す設計でした。ところが一人で運用すると、その承認待ちが投稿全体の詰まりどころになりました。今は、X投稿は週1回まとめて確認し、出したくないものだけを外す形に、媒体への転載は人の承認を外し、公開直前の機械の検査で止める形に変えています。この記事では、その経緯と、変えたことで見つかった穴への対処をお話しします。

クライアント概要

運用主体: BENTEN Web Works（自社運用、個人事業）
対象: X投稿の作成と、note・Qiita・Zennへの転載
目的: 展開作業の負担を下げつつ、品質とアカウントの健全性を損なわない仕組み

自社運用ですが、コンテンツを複数メディアに展開したい個人事業者・小規模事業者全般に応用できる構成です。

課題・依頼背景（Before）

媒体ごとに合う文体が違う: 同じ原稿を貼り付けるだけでは読まれず、書き直しが要ります
転載漏れの追跡が手間: どの投稿をどこに出したかを人が覚えておくのは無理があります
完全自動化の副作用が心配: アカウントの凍結、ブランドのトーンが崩れること、出してはいけない固有名詞が混ざること
「自動化したつもり」になる罠: 自動だと思っていた工程が実は人の操作待ちで、転載が止まったまま放置された期間がありました

提案・解決アプローチ（思考プロセスを見せる）

当初の設計: 人の承認を3か所に残した半自動化

完全自動化と全工程手動を比べ、その間を取る構成にしました。

1. どの投稿を展開するか（人）: 未展開の一覧から展開する価値のあるものを選ぶ 2. AIが書いた案を採用するか（人）: トーンや誤情報が気になる案は破棄するか書き直す 3. 最終公開の承認（人）: Discordでプレビューを1本ずつ確認し、承認したものだけを投稿する

その間の検出・通知・下書き作成をシステムに任せる、という分担です。

運用で分かったこと: 承認待ちが律速になった

運用を続けると、詰まるのはいつも人の承認でした。

X投稿: 承認待ちが76件まで溜まりました。調べると、直近13日で作られた8本のうち承認されたのは2本で、承認さえ通れば翌日には確実に投稿されていました。原因は品質ではなく、1本ずつリンクを開いて承認する手間と、一度見逃した投稿が二度と通知されない作りでした
媒体転載: 毎日深夜の自動処理に切り替えた時点で、展開する投稿の選定は関連度順の自動選定に、QiitaとZennは自動投稿にしました。noteだけは承認を残しましたが、承認の返信が処理に拾われず、承認待ちのまま止まる状態が続きました

変えたこと: 媒体ごとに承認の置き方を変えた

X投稿は人の確認を残し、まとめて見る形にした: 未処理の投稿を毎回全件1枚に並べ、出したくないものの番号だけを選びます。残りは日付を分散させて予約投稿に回します。毎週日曜にリマインダーが届き、週1回の確認で回ります
媒体転載は人の承認を外した: 2026年5月に、noteも含めて全媒体を自動投稿に切り替えました。転載の素材は、すでにX投稿として確認を通った自分の投稿だからです

あえて採用しなかった選択肢

1本ずつの承認を続ける: 承認待ちが溜まり続け、仕組みを作った意味がなくなります
X投稿の人の確認まで外す: アカウントとブランドに直接響く工程なので、まとめ確認の形で人の目を残しました
大型ワークフローツールへの全面依存: 障害で全体が止まるため、工程ごとに独立したスクリプトに分けています

実装内容

構成の考え方

生成層（X）: ネタ帳から1日最大1本の投稿案をAI（DeepSeek）で作ります。生成後に、決まり文句の検出とAIによる自己評価で基準に届かない案を外し、NGワードと文字数の検査を通したものだけを確認待ちに回します
確認層（X）: 週1回のまとめ確認。不採用の番号だけを入力し、書き込みは確認用の試し実行を経てから行います
転載層: 毎日深夜に未展開の投稿を検出し、媒体ごとの文体と文字数に合わせてAIで書き直します。noteは文章の評価と修正のループを通します
公開直前の検査（転載）: タイトルと本文の長さの検査、NGワード（企業名・人名など）の検査、二重投稿の再確認を通ったものだけを公開します。NGワードに当たったものは公開しません
実行層: 媒体ごとに投稿手段を分けています（API、GitHubへのプッシュ、noteはブラウザの自動操作）

工夫した点

見逃しが累積しない確認面: 未処理を毎回全件並べるので、一度見逃した投稿が埋もれません
番号のずれを防ぐ: 確認面の番号と投稿の対応を確認時点で固定し、後から並び順が変わっても別の投稿を指さないようにしています
転載の対象を絞る: X投稿から60日を過ぎたものと、お客様の事例に由来する投稿は自動転載の対象から外しています
障害時の復旧が容易: 1工程ごとに独立したスクリプトにしています

運用で見つかった問題と対処

媒体転載から人の承認を外したあと、自動処理の安全性を監査したところ、転載の経路だけ、固有名詞のNGワード検査が抜けていたことが分かりました。X投稿の生成やネタの登録には元からあった検査です。

転載用の書き直しでは、AIに「具体的な事例やデータを加える」よう指示していました。人の承認を外した時点で、元の投稿に無い固有名詞をAIが書き足しても、公開前に止める仕組みが無かったことになります。公開は取り消せません。

対処として、公開の直前にNGワード検査を置き、引っかかったものは公開しないようにしました。通知にも該当の語そのものは出しません。人の確認を外すなら、その確認が担っていた役割を機械側に移してから外す。この順番を守れていなかったことが、今回の反省です。

成果

承認待ちの見逃しが溜まらない形に: X投稿は週1回、全件を1枚で確認できるようになりました
転載が人の都合で止まらない: 媒体転載は承認待ちをなくし、毎日の自動処理で進みます
止める場所を明示: X投稿は人のまとめ確認、転載は公開直前の機械の検査、と媒体ごとに歯止めの位置を決めています
横展開できる考え方: 「どこに人を残し、どこを機械の検査に任せるか」を運用の記録で決め直す進め方は、他の発信業務にも使えます

この仕組みで守りたかったのは、出した本数よりも、運用が一人でも続くこと、ブランドを傷つけないことでした。

私の働き様

β：検討プロセス（一人称で振り返り）

エピソード1：人の確認を外す前に、代わりの検査を置く（→ ちゃんと動く／ビジネスに寄り添う）

転載の承認を外した判断そのものは、運用を続けるために必要だったと考えています。ただ、外した時点で、承認が担っていた「固有名詞が混ざっていないか」の確認を機械に移していませんでした。監査で見つかるまで、その穴は開いたままでした。外す前に、外したものの役割を書き出して機械側へ移す。今はこの順番で進めています。

エピソード2：「自動と思って実は手動」をなくす（→ 思考プロセス／ちゃんと動く）

noteの承認の返信が処理に拾われず、転載が止まったままになっていた時期があります。そこから、「定期実行／人の確認／手動起動」を設計図の上で区別するようにしました。この区別があいまいな自動化は、止まっていても気づけません。

エピソード3：承認の手間を減らすことも品質管理（→ ビジネスに寄り添う／思考プロセス）

X投稿の承認待ちが溜まったとき、原因は投稿の質ではなく確認の手間でした。人の確認を残すなら、一人で無理なく続けられる手間に設計するところまでが仕事です。1本ずつの承認を、週1回のまとめ確認に変えたのはそのためです。

α：コミュニケーション抜粋（自分の発言だけ）

自社運用のため、判断のときに残した記録から要旨を載せます（発言そのものではなく、記録の要約です）。

2026年5月の判断: noteも含めて全媒体を自動投稿にする。転載の素材は、すでに確認を通した自分のX投稿だから
2026年8月の判断: X投稿の確認は、出したくないものの番号だけを選ぶ形にする。全部よければ「なし」でよい
2026年9月の判断: 転載の人の承認は外したまま、公開直前にNGワードの検査を置く。引っかかったものは公開しない

「AIに任せて適当に量産している」のではなく、人の目を置く場所と機械の検査で止める場所を、運用の記録を見ながら決め直しているのが実態です。

学び・横展開

1. 承認は残すだけでは機能しない: 一人で回る手間に設計しないと、承認待ちが詰まりどころになります 2. 人の確認を外すなら、代わりの検査を先に置く: 外したものの役割を書き出してから外します 3. 設計図上で「自動／人の確認／手動」を色分けする: 区別があいまいな自動化は、止まっても気づけません 4. 媒体ごとに歯止めの位置を変えてよい: アカウントに直接響く投稿と、確認済みの素材を使う転載では、必要な確認が違います

SNS発信を二次展開している事業者であれば、本件の構成は応用できます。

Others

その他の制作実績