Xの運用を少し楽にしたくて、半自動のAI投稿botを作っていた。
RSSやスクレイピングで、自転車ロードレース、3DGS、Photogrammetry関連の情報を集める。AIで要約して、投稿文の候補を作る。それをLINEやDiscordに流し、よさそうなものを選んで投稿する。
仕組みとしては、ちゃんと動いたけれど、しばらく使ってみると、少しずつ違和感が大きくなっていった。
便利ではある。たしかに情報収集が早くて軽い。しかも投稿文のたたき台も出てくる。だが、運用しているうちに「これは本当に自分の発信として投稿していることになるのか」と思う場面が増えてきた。
そこで、いったん半自動投稿botの流れを止めた。
そして、投稿まで進めるbotではなく、自分専用の「編集支援」WebUIとして作り直すことにした。
今回は、その作り替えの記録である。
投稿候補をカード形式で一覧できるWebUIのイメージ。実データやURLは載せず、管理したい状態だけを図にした。
チャット通知は、投稿候補の管理には向かなかった
最初に気になったのは、LINEやDiscordのようなチャットに投稿候補を流す運用だった。
チャットは、情報を素早く受け取るにはとても便利だ。通知が来ればすぐ気づけるし、スマホからも確認しやすい。RSSで拾った記事やAIの要約を流すだけなら、かなり相性がいい。
ただ、投稿候補の管理となると話が変わる。
候補がどんどん流れていく。あとから見返しにくい。どれを確認済みにしたのか、どれを却下したのか、どれをあとで直したいのかが残りにくい。
つまり、チャットは「流れてくる情報を見る」場所としてはよいけれど、「候補を並べて比較し、状態を管理し、編集してから判断する」場所としては少し弱かった。
これはLINEやDiscordが悪いという話ではない。用途の違いだ。
ニュースの通知として情報を受け取るだけならフローでいい。しかし、そこから発信の候補へ移行するためにはストックとして扱いたい。あとから比較したいし、却下した理由も残したい。投稿前に本文を直し、文字数を見て、似た内容の連投になっていないかも確認したい。
そう考えると、チャットの中で番号を選ぶ運用には限界があった。
常駐botとWebhookは、自分一人には少し重かった
もうひとつの理由は、構成の重さだった。
半自動投稿botとして作ると、どうしても常駐botやWebhookサーバのような部品が増えていく。通知を受ける。番号を選ぶ。承認を拾う。投稿処理へ渡す。エラーを返す。
個人開発としては面白い。
ただ、自分一人のX運用のために、そこまで常時動かす必要があるのかと言われると、だんだん微妙になってきた。
一度動かして終わりではない。トークン、認証、ログ、エラー、再起動、ネットワーク、外部公開の経路。気にすることが増える。
もちろん、仕組みをきちんと作れば運用できる。けれど、自分が欲しかったのは「すべてを自動化するシステム」ではなく、「毎日の発信の入口を少し軽くする道具」だった。
そこを間違えると、楽をするための道具のはずが、道具の面倒を見る時間を増やしてしまう。
自動投稿経路があること自体が、少し怖かった
いちばん大きかったのは、心理的な不安だった。
「気づいたら勝手に投稿されていた」
「AIが怪しい情報を含んだ投稿文を作っていた」
この状態だけは避けたい。
それは、親しいフォロワーも同じだったようだ。
「アカウントが乗っ取られたかと思って心配した」
…完全に失敗である。
AIは便利だ。要約も速いし、論点も出してくれる。自分が見落としていた角度を拾ってくれることもある。
でも、AIは記事にない情報をもっともらしく補うことがある。日付、数字、背景、因果関係。人間が読むと自然に見えてしまう文章ほど、確認をすり抜けやすい。そして、私の文体を学習しているとはいえ、機械的な文章なのだ。
特にSNSは、ブログよりも投稿までの距離が短い。また、短文なので言葉の重みがある。少しの違和感が大きな不協和音として響く。
とどめを刺したのは、X上で印象に残った投稿だ。
あるサービス系アカウントのポストが、元の情報をうまく拾えておらず、読者に違う受け取り方をさせる内容になっていた。私が見た範囲では、その投稿に対してかなり強い反応が集まっていた。
参考：該当ポスト
もちろん、そのアカウントを責めたいわけではない。ここで気にしたいのは、AI要約や自動投稿の仕組みでは「要約としてはそれっぽいが、文脈としては危うい」文章が出てしまうことだ。
元記事に書かれていない因果関係を足す。数字の意味を取り違える。強い言い切りにしてしまう。誰かを批判しているように見える角度へ寄せてしまう。
こういうズレは、技術的なエラーとしては見つけにくい。だからこそ、投稿前に人間が「これはミスリードにならないか」を見る場所が必要になる。
でも、自分のアカウントで出す言葉は、自分の言葉として読まれる。
AIが作った文章であっても、投稿した瞬間に、それは自分の発信になる。
だからこそ、最後の判断をAIに渡してはいけないと思った。
要約、重要点、投稿本文、自分の追記、最終プレビューを一括で確認するUIイメージ。
botではなく、編集支援システムにする
そこで、考え方を変えた。
作るものを「投稿bot」ではなく、「編集支援システム」にする。
AIに任せる範囲は、次のところまで。
- 情報源を集める
- 記事を要約する
- 重要そうなポイントを抜き出す
- 投稿文のたたき台を作る
- コメントの角度を提案する
一方で、AIには任せないことも明確にした。
- 投稿可否を決めない
- 承認済み状態を勝手に付けない
- 自動で返信しない
- 自動で引用しない
- 自動でメンションしない
- 記事にない事実を書かせない
人間がUIで操作したときだけ、候補が承認済みになる。
初期状態はドライラン。いきなり投稿される経路にはしない。投稿経路も一本化する。
ここで大事なのは、AIを信用しないという話ではない。むしろ、AIを使い続けるために、役割を分けるという話だ。
AIは素材を出す。自分が編む。
この距離感のほうが、今の自分の発信には合っている。
WebUIにした理由
WebUIにしたのは、投稿候補を「編集対象」として扱いたかったからだ。
チャットに流れてくる候補は、どうしてもその場で反応するものになりやすい。けれどWebUIなら、候補を一覧で並べられる。状態を持たせられる。あとから戻れる。
今回の状態遷移は、ざっくり次のように考えている。
new -> AI分析 -> drafted -> レビュー -> 承認 -> 投稿
AIが進める場所と、人間が判断する場所を分ける。編集支援WebUIとして設計した。
候補を集め、AI分析を通し、人間が確認する。止められる場所を設計の中心に置いた。
一覧画面では、候補をカード形式で表示する。
カードには、元記事のタイトル、情報源、AI要約、状態、投稿前チェックの結果を出す。詳細画面では、AIが作った投稿本文をその場で編集できるようにする。自分の追記欄も用意し、最後に実際の投稿イメージをプレビューする。
文字数も見たい。
URLが入っているか。重複ではないか。似た文を連投していないか。NG語が入っていないか。そういう投稿前チェックも、画面上で見えるようにしたい。
Xの投稿は短い。短いから簡単、ではない。
短いからこそ、確認すべきことを画面に出しておく必要がある。
スマホで承認できることも大事だった
このWebUIは、モバイルファーストで作っている。
Xを見るのは、机の前だけではない。移動中、休憩中、ちょっとした空き時間にニュースを見ることも多い。だから、投稿候補の確認もスマホからできるようにしたかった。
ただし、スマホで操作できることと、雑に承認できることは違う。
承認ボタンは押しやすい位置に置く。でも、画面の流れとしては、要約、投稿文、チェック結果、プレビューを見てから押せるようにする。
状態も色で見分けられるようにした。
new、drafted、レビュー中、承認済み、投稿済み。ぱっと見て、今どこにある候補なのか分かるようにする。
却下するときは、理由タグとメモを残せるようにした。
これは、単に記録を残すためではない。却下理由をためていくことで、あとからAI側の改善に使えると思っている。
「要約が弱い」
「元記事の情報が薄い」
「自分の関心とズレている」
「似た投稿が続いている」
こういう理由がたまれば、情報源の選び方や、要約プロンプトや、チェック条件を見直せる。
投稿しなかった候補も、次の改善材料になる。
却下理由は、AI改善のためのフィードバックとして扱う。
セキュリティは、細部よりも考え方を書く
今回のWebUIは、自宅PCのローカルで動かしている。外から確認するために、トンネル経由でアクセスできるようにもしている。
ただ、この記事では具体的なドメイン名やログインURL、トンネル設定、APIキー管理の詳細は書かない。
公開する必要がないからだ。
考え方としては、次のようにしている。
- 初期状態はドライランにする
- 投稿経路は一本化する
- 承認済み状態は人間の操作でしか付かない
- 自動返信、自動引用、自動メンションは作らない
- 認証は複数段で考える
- ログインURLや内部設定は公開しない
- 公開画像には機密情報を写さない
もちろん、これで「完全に安全」と言うつもりはない。
個人開発のローカルツールを外から触れるようにする以上、慎重に扱う必要がある。だからこそ、記事では実装手順や設定値の紹介ではなく、どこに境界線を引いたかを書くにとどめる。
速く投稿できることより、間違って投稿されないこと。
ここを優先した。
半自動の幻想より、人間中心の編集支援
自動化を進めていると、つい「最後まで自動で行けるのでは」と考えたくなる。
情報を集める。要約する。投稿文を作る。承認する。投稿する。
この流れを全部つなげると、たしかに気持ちはいい。システムとしても美しい。
でも、自分の発信に必要だったのは、そこではなかった。
必要だったのは、投稿を自動で増やす仕組みではなく、発信する前に考える余白を残す仕組みだった。
AIが素材を集める。AIが下書きを作る。そこまでは大いに助けてもらう。
ただし、最後に「これは自分が言いたいことか」「この表現で読者に届いてよいか」「元記事にないことを言っていないか」を見るのは自分だ。
この一手間を残すことで、むしろ運用は軽くなる気がしている。
自動投稿の不安を抱えたまま速くするより、自分が納得して押せる画面を作ったほうが、結果的に続けやすい。
スマホの承認ボタンは押しやすく。ただし確認の後に置く。
自分専用の編集部として育てる
このWebUIは、まだ完成形ではない。
実運用しながら、却下理由をためていく。AIの要約を見直す。情報源を入れ替える。投稿前チェックの条件も調整する。
たぶん、最初から正解の形にはならない。
でも、それでいいと思っている。
これは、誰にでもそのまま勧められる万能のSNS運用ツールではない。自分の関心、自分の発信の温度、自分が許容できるリスクに合わせて作っている、自分専用の編集支援システムだ。
AIに発信を置き換えるのではなく、発信の入口を軽くする。
AIに投稿させるのではなく、自分が編集するための素材を出してもらう。
半自動投稿botをやめたことで、むしろAIとの付き合い方ははっきりした。
最後に押すボタンは、自分で押す。
そのための画面を、これから少しずつ育てていく。
主要リンク
- X API Overview
- X API Pricing
- X Developer Guidelines
- X's automation development rules
- More about restricted uses of the X APIs
- ミスリードの怖さを考えるきっかけになった投稿
※X APIや自動化ルールは変更される可能性があるため、この記事では具体的な運用手順ではなく、個人運用でどこに判断の境界線を置いたかを中心に書いています。
