コンテンツ自動化実験日誌：Openclawでスレッド、ブログまで
作者
- 팀제이커브팀
成功かどうか
成功
トピック
- 自動化
スレッドを着実に運営したいという考え、一度くらいやってみたはずです。ところがいざやってみると文字検索、書く、上げるこの3つがずっと足首をつかみます。
私も同様の悩みをしていました。それからふとこんな気がしました。
「すでに毎日分けているAIとの会話をコンテンツとして使うとどうだろうか？」
そのように始まったのが、オープンクロベースのAIを活用したコンテンツ自動化実験でした。
結論から申し上げれば、思ったよりずっと簡単にスレッド運営からブログOSMU（One-Source-Multi-Use）まで続く仕組みを作ることができました。一つずつ解いてみましょう。
なぜコンテンツの自動化を試みたのか
スレッドを着実に運営してみたいという考えは古くなっています。ところがいざやってみるといつも同じ地点で詰まったんですよ。
文字を選ぶのも仕事で、書くのも仕事であり、上げるのも仕事です。結局、数日間、混雑することが多かったです。
それから反対側からヒントを得ました。
普段、私はテレグラムに貼っておいたAIアシスタント、別名「石」と会話を頻繁に分けます。
この石石は、オープンクロー（OpenClaw）を基に個人化して作られたAIチャットボットです。
チームジェイカーブクルーレックの個人用オープンクロー(OpenClaw)、石
アイデアを整理する時も書いて、思考を拡張する時も書いて、ほぼ毎日会話を積んでいましたね。ところがある瞬間こんな気がしました。
「これらの会話、ただ吹き飛ばすにはもったいないのか？」
実際に会話を振り返ってみると、そのまま使ってもいいほどいいインサイトや文章がかなり多かったです。では、あえて新たに書く必要がないと思いました。それで、方向をこうして握りました。
•
新しく書かないで、すでにある会話を活用しよう
•
AIに文章作成を無作為にさせるのではなく、文章から抜かせよう
•
そして、可能であればアップロードまで自動化しましょう。
こうして、会話→コンテンツ→発行→リサイクル（OSMU）まで続く仕組みを実験してみました。
オープンクローで作成したコンテンツ自動化構造
構造はできるだけ単純につかまえた。複雑にすると結局使わないことになりますよね。
全体の流れはこのように続きます。
•
石石といつものように会話→文章おすすめ→ボタンクリック→自動発行
会話→文章おすすめ→ボタンクリック→スレッド自動発行フロー
一つずつ見ると難しくありません。
1.会話→文章→投稿まで続く流れ
まず、石の石が一日の会話の一部をスレッドの手紙としてお勧めします。
ここで重要なのは、「文章を書いて」ではなく「使える素材を選んでほしい」という点です。
1.会話→文章→投稿まで続くフロー図化
完成した文を受け取るより、私の考えが込められた会話に基づいてまとめられた草案がはるかに自然です。そして、これらの文字は決まった形式ではなく、前に設計したコンテンツカテゴリ（視点、ケース、ヒントなど）に合わせてランダムに生成されます。
そう少ないボットのように見え（？）、実際の人が運営する感じが出ますから。もちろん、最も重要な「文に建てた私の考えが明らかになるのか」なので、これをよくろ過するのが今回の実験の核心でもあります。
テレグラムボタン+ Human-in-the-loop構造
ここに一度「人がしなければならないこと」を入れました。テレグラムメッセージに「公開する」ボタンを貼り付けて、手紙を受け取った後に直接読んでみて、まともなものだけを選択します。
石石との会話内容の例
このプロセスは思ったより重要です。完全自動化をしてしまうと楽ですが、コンテンツのトーンが微妙にずれ始めます。
それで、役割をこう分けました。
•
AI：文字推薦+ドラフト作成
•
人：最終選択（ボタンをクリック）
AIがすることと人がすることの区分に対する図式化
その結果、人は「書く人」ではなく「選別する人」になるのです。
Make + Webhook + Bufferで接続した自動化スタック
迅速な実行のために、このプロセスは自動化ツールであるMakeを利用しました。
難しくなく、とても単純な2つのモジュールだけを活用しました。ボタンを押すと、次はすべて自動です。
自動化ワークフローに使用されたツール、Makeのシナリオ（Wenhook + Buffer） - コンテンツ発行
構造はかなり単純です。
ストーン（オープンクロー）→Make Webhook→Buffer→Threads自動アップロードが終了します。少し難しく見える語彙がいくつかありますが、チャットボットに聞いてみるとすぐに分かるレベルです。
自動化プロセスの中でHuman-in-the-loopを溶かす
•
テレグラムで人が「公開」ボタンをクリック
•
石がWebhookを呼び出す
•
Make シナリオの実行
•
Buffer経由でスレッドを自動アップロード
ただ.. 最初はThreadsを直接付けようとしましたが、Makeにネイティブモジュールがなくて詰まっていました。ここでBufferを中間に挟む方法で解決しましたが、Meta認証問題まで一緒に迂回され、むしろより安定的に動作しました。
こうして、結局残った作業は「カチッ」で可能になりました。
実際に振り返ると変わった点
構造を作るのと、実際に転がって行くのはまた別の話です。いざ振り返ってみると仕事の仕方自体がかなり変わりました。
書き込み0秒、発行1分、変わった作業方法
テストでスレッドの5つの記事を投稿しました。かかった時間は待ち時間を含めて合計1分程度でした。当然、文章を書く時間は0秒でした。
もちろん完全に何もしないのではありません。上げる前に一度読んでみて、まともなものだけ選びます。ところでこれが思ったより大きいです。
Before&After - 書き込み0秒、発行1分に変わった作業方法
従来は「いつ書く…」→先延ばし→しないこの流れだったら、
今は「大丈夫？」 →ボタンクリック→終了に変わりました。
どんな業務でも発展がない理由は「慣性」が半分ですが、この慣性がなくなった感じでした。
完全自動化の代わりに「選別」に集中した理由
最初は完全自動化に悩んでいました。ところで、直接使ってみると考えが少し変わりました。 AIが作った文が間違っているわけではありませんが、微妙に「私の言葉のようではない瞬間」があります。
だから今はむしろこの構造がもっと好きです。 AIはずっと文章を作ってくれて、私はその中で書くだけ選んでいますから。
さらに、Openclawの特性上、作成した記事へのリアルタイムフィードバックが可能なので、
一日が違うように文のクオリティまで上がるのが見えました。
スレッドからブログまで、OSMUを拡張する
ここでは、1つのわらを越える部分があります。今見ているこの文も、実は新しく書いたものではありません。以前まで石石との会話の内容を元に始まったんです。
このコンテンツは別に最初から企画して書いた文ではありません。石石と分かれた「スレッドオートメーション どう作ったのか」についての会話がありました。その会話をもとに、 「これをブログコンテンツにしてみよう」という流れにつながりました。
実際にはこんな感じでした。
1.
石とスレッドの自動化プロセスを継続的に会話に整理
2.
その会話に基づいてコンテンツ制作依頼
3.
構造化+コンテキスト強化→ブログドラフト完成
だから、この記事自体もAIとの会話内容をもとにコンテンツに変換された結果です。
AIとの会話内容をもとにコンテンツに変換される過程図式化
OSMUは「再加工」ではなく「フロー設計」です。普通OSMUといえば「一つ作って、いろんなチャンネルに腹付く」という感じが強いんですけど。今回のケースは少し異なります。スレッドを先に作ってブログに移したのではなく、会話→スレッド→ブログに自然につながった流れです。
この頃はよく分かるでしょうが、重要なのは結果物ではなくむしろその先端の「どこでコンテンツが作られ始めるのか」です。今回の場合は考え→会話→整理→発行→再加工という全体的な流れがひとつにつながります。
コンテンツを「作る人」から、コンテンツを「流れるようにする人」に役割が変わること。
これが今回の実験で最も大きく変わった点でした。