API課金ゼロで「24時間返信し続けるX上のロースト bot」が成立した話

API課金ゼロで「24時間返信し続けるX上のロースト bot」が成立した話

2026年4月2日、Xユーザーの@yodaaa氏が「Hermes Agent + 月額100ドル相当のチャットUIだけで、APIキーを一切使わずに自律返信・煽り生成を回し続けるロースト bot」を公開し、海外コミュニティで話題になりました。株式会社Fyveは中小企業向けにAI業務効率化を提供している立場から、この事例の本質を「コスト構造の組み替え」として読み解き、自社の発信や顧客への提案にどう応用できるかを整理しました。本稿はその要点をまとめたケーススタディです。

事例の概要 ― 「API課金ゼロ」のコスト構造

事例のキモは、技術的な派手さではなくコスト設計です。一般的にX上で常時返信するボットを組もうとすると、X APIの有料プラン（Basic以上）と、生成側のLLM APIの両方が必要になり、毎月数百ドル単位の固定費が発生します。@yodaaa氏の構成はここを真っ向から外しています。月額100ドル前後のチャットUIサブスクリプション1本で、APIキー課金は発生しません。Hermes Agentを常駐させ、ブラウザ越しにXのタイムラインとUIを読み書きさせることで、API契約なしで自律返信ループを24時間回しています。

私たちが注目したのは、ここで節約しているのは「お金」だけではないという点です。API契約を持たない設計は、X側のAPIポリシー変更やレート制限改定といった外部要因に振り回されにくく、副業的に回す個人開発者にとっては「契約管理の煩雑さそのものを消す」効果があります。後述する規約面のリスクと表裏一体ではあるものの、コスト構造の組み替えとしては鋭い設計です。

仕組みの解説 ― なぜAPI不要で成立するのか

技術的な核は3点に集約されます。1点目は、Hermes Agent自体が「ブラウザを含むGUIをツールとして扱える」ランタイムである点です。Nous Researchが2026年2月に公開したHermes Agentは、ファイル操作・ターミナル実行・Web取得に加えてブラウザ操作の組み込みツールを持ち、人間が画面を見て操作する手順をそのまま自動化できます。X APIに頼らずにタイムラインの読み取り、リプライ欄への投稿、引用ポストの選定までを一気通貫で実行できる前提が、ここで揃います。

2点目は、メモリと常駐性です。Hermes Agentは短期・中期・永続の3層メモリと専属マシンへの常時アクセスを持ち、「過去にどのアカウントを煽ったか」「同じネタを連投していないか」をエージェント側に記憶させられます。返信のトーン・キャラ設定をスキルとして固定し、自己改善ループで磨いていけるため、bot臭さを抑えながらキャラクターを維持できる構造です。

3点目はスケジューラとサブエージェントです。常駐したMac mini等の専用マシンに対して、cronで「30分おきにXタイムラインを巡回し、引っかかったポストにロースト返信を生成する」というジョブを差し込めば、深夜帯も含めて24時間稼働します。生成パートだけをサブエージェントに切り出すことで、本体のコンテキストを汚さずに大量処理を回せます。

裏返すと、この構成は「ブラウザを開きっぱなしにできる物理マシン」と「電源・ネットワークの安定」が前提です。クラウド上のステートレスな関数で組もうとすると、ログインセッション維持・CAPTCHA・二要素認証の壁にすぐぶつかります。常駐エージェントという発想自体が、サーバーレス全盛のここ数年とは逆を行く設計思想であることも、本事例の面白さです。

私たちの解釈 ― 「APIを買わない」という選択肢

私たちが本事例から得た学びは、「自動化＝API契約」という前提を疑うべきタイミングに来ている、という点です。エージェントがブラウザを操作できるようになったことで、これまでAPIに払っていた月額が、エージェント本体のサブスクと電気代に置き換わります。Hermes Agentに限らず、ブラウザ操作型エージェント全般に共通する構造変化です。

中小企業の業務改善の現場でも、この変化は無視できません。私たちが顧問先と話す中でも「SaaSのAPI連携が高い」「契約と運用の人手が足りない」という相談は増えています。今回のX Roast botは尖った事例ですが、コアにあるのは「APIの代わりに既存のブラウザログインを再利用する」という発想であり、社内の業務SaaS連携（経費精算・営業管理・採用ATSなど）にもそのまま応用可能な設計です。

同時に、私たちはこの設計を顧客にそのまま勧めません。後述するとおりプラットフォーム規約・アカウント停止リスク・運用責任の問題が残るためです。本事例の価値は「24時間動くbotが100ドルで作れた」ことではなく、「コスト構造をどこに寄せるか」という設計の選択肢が増えたことにあると、私たちは整理しています。

実務への落とし込み ― 規約と運用の現実

事例を実務に持ち込む際に、私たちが必ず確認する論点は3つあります。1つ目はプラットフォーム規約です。Xの開発者規約および自動化に関するガイドラインでは、「APIを介さない大量の自動投稿」「他ユーザーを意図的に煽る・嫌がらせ目的の自動化」は明確に禁止行為に該当し、アカウント凍結のリスクがあります。今回の事例はXのコミュニティで話題になった一方で、公式に推奨されている使い方ではない、という前提を絶対に飛ばしてはいけません。

2つ目は運用上の責任分界です。自動でロースト返信を投げ続ける場合、相手アカウントとのトラブル・名誉毀損的なポストの生成・誤爆のすべてに、運用者本人が責任を持つことになります。私たちが法人顧客に同種の自動化を提案する場合は、まず「人間レビュー付きの下書きフロー」から始めることをほぼ例外なくお願いしています。下書きまでをエージェントに任せ、最終投稿は人間が押す形にするだけで、規約と倫理の論点はかなり整理されます。

3つ目は技術的な耐久性です。ブラウザ操作型の自動化は、対象サイトのDOM変更やレイアウト変更で簡単に壊れます。半年単位で見れば、APIを使った素直な実装の方が結果的に保守コストが安いケースは多いです。私たちが社内検証で組むPoCでも、「APIで組めるならAPIで組む。ブラウザ操作はAPIが存在しない領域に限定する」という原則を崩していません。本事例は「APIが選べる領域であえてブラウザ側に振り切ったケース」として、再現の判断は慎重に行うべきです。

関連事例 ― 同じ「常駐エージェント」発想の使い方

X Roast botと同じく、Hermes Agentの「常駐＋ブラウザ操作＋永続メモリ」を活かした海外事例は他にも蓄積されています。たとえば@Saboo_Shubham_氏は2026年4月29日、自分の過去LinkedIn投稿から文体を学習させ、Mac mini常駐で個人ボイスのLinkedIn投稿を量産する構成を公開しました。@codewithimanshu氏は2026年4月24日、商品URLを起点に競合広告ライブラリを巡回し、UGC広告のブリーフを約4分で生成するスタジオ的な構成を公開しています。「APIではなくブラウザログインを起点に、人間と同じUI操作を24時間回す」という発想が共通しています。

業務寄りの用途では、SlackやTeamsの受信トレイ要約・Obsidianの日次ジャーナル生成・Supabase上のCRMアシスタントなど、社内SaaSにブラウザ越しでアクセスして処理を回すパターンが増えています。私たちが中小企業に提案する際は、これら穏当な業務側の事例を入口にし、SNS自動化のような対外発信領域は「規約と運用責任の整理が済んでから」というスタンスです。

まとめ

@yodaaa氏のX Roast botは、月額100ドル前後のチャットUIサブスクとHermes Agent常駐だけで、X API課金ゼロのまま24時間自律返信を回し続ける構成として注目されました。技術的な核は、ブラウザ操作・3層メモリ・cronスケジューラ・サブエージェントの組み合わせであり、コスト構造をAPI契約からエージェントの常駐環境へ寄せ替えた点が新しい設計です。一方で、X規約上のリスク・運用責任・ブラウザ操作の脆弱性は、そのまま実務に持ち込むには無視できません。私たちは本事例を、「自動化＝API契約」という前提を疑い直すきっかけ、そして自社の業務SaaS自動化や対外発信の設計に応用していくための一次資料として扱っています。今後Hermes Agent系の事例が日本企業に降りてくる速度を考えると、規約・運用・技術耐久性の3点をセットで整理しておくことが、提案の質と速度の両方を上げる近道になるはずです。

出典: Nous Research – Hermes Agent User Stories / awesome-hermes-usecases / X (旧Twitter) 上の @yodaaa, @Saboo_Shubham_, @codewithimanshu 各氏の公開ポスト（2026年4月時点）