安価なスマートフォンを束ね、1台のホストでローカルAIを回し、トレンド動画から台本生成・複数端末への自動投稿まで回す。中国の19歳2人が公開した事例は、エッジAIと自動化の具体像として注目を集めています。
この記事では、彼らが紹介したphone farmの構成と、Hermes Agent・Qwenが担う役割、ローカルモデルサーバー運用のポイントを整理します。
この記事でわかること
- marfin氏の投稿が示すphone farmの収益規模と処理フロー
- ホストマシン＋複数スマホ＋ローカルQwenの3層構成
- Hermes Agentが自動化の司令塔になる理由
- 同じ発想を安全に応用する際の注意点
月1万8,200ドルと報じられたphone farm
2026年6月7日、Xユーザーmarfin氏は次の内容を投稿しました。中国の19歳2人が、月1万8,200ドル（約270万円）規模の「Hermes Agent phone farm」を運用していると紹介しています。
投稿の要点は次のとおりです。
- 安価なスマートフォンをラック状に並べ、1台のホストマシンに接続している
- ホスト側でローカルモデルサーバーを動かしている
- トレンド動画を収集し、Qwenでローカライズされた台本を生成する
- 生成したクリップを複数端末へ自動投稿する
投稿本文は途中で切れており、配信先プラットフォーム名や端末台数は明記されていません。収益額も当事者の自己申告に基づく数字であり、第三者による検証は現時点で確認できていません。それでも、構成そのものは「収集→生成→配信」をローカルAIで閉じるという、実務的なワークフローとして読み取れます。
なぜphone farmとローカルLLMの組み合わせか
phone farm（スマホ農場）とは、複数のスマートフォンをまとめて運用し、マルチアカウントの投稿や広告視聴などを並列処理する仕組みです。物理端末を使う理由は、各端末が独立したIP・端末情報・SIMを持てる点にあります。API経由の一括投稿ツールは、プラットフォーム側の検知対象になりやすいという指摘が長く存在します。
一方、台本生成やトレンド分析にクラウドAPIを使い続けると、呼び出し回数に比例してコストが膨らみます。大量の短尺動画を毎日処理する運用では、この差が収益を圧迫します。ローカルでQwenを動かせば、推論コストを端末側に固定でき、データもホスト内に留めやすくなります。
この事例は「端末の多さ」と「推論のローカル化」を同時に取りにいく設計だと言えます。
システムの3層構成
marfin氏の説明と公開ドキュメントを照合すると、次の3層に分解できます。
1. 実行層（複数スマートフォン）
安価なAndroid端末が投稿の実行役です。各端末はアプリ上で実際に操作され、端末固有のネットワーク情報を維持します。Hermes AgentはAndroid向けにTermux（Android上のLinux環境）での動作が公式に案内されており、スマホ単体でもCLIエージェントとして動かせます。今回の構成では、端末群はホストから制御される実行ノードとして機能していると考えられます。
2. 推論層（ホスト上のローカルモデルサーバー）
ホストマシンがQwenを載せた推論サーバーを常時起動します。Hermes Agentの公式ドキュメントでは、OllamaやvLLMなどOpenAI互換APIを実装したローカルエンドポイントへの接続が案内されています。例えばOllamaなら http://localhost:11434/v1 を指定し、モデル名に qwen2.5-coder:32b のようなQwen系モデルを選ぶ流れです。
NVIDIAの技術ブログでも、Hermes AgentとQwen 3.6をllama.cpp・LM Studio・Ollamaで組み合わせる運用が紹介されています。クラウド課金なしで推論を回す前提が、エージェント基盤と相性よく噛み合います。
3. 司令塔（Hermes Agent）
Nous Researchが公開するHermes Agentは、オープンソースの自律型AIエージェントです。ターミナルCLIに加え、TelegramやDiscordなど複数チャネルから操作でき、内蔵のcronスケジューラで定時タスクを回せます。スキル（再利用可能なワークフロー定義）を自動生成・改善する学習ループも特徴です。
この事例では、Hermesが次の処理を束ねていると読めます。
- トレンド動画の収集
- Qwenへの台本生成リクエスト
- 各端末への投稿指示
投稿に「Hermes Agent phone farm」とあるのは、単なる端末の羅列ではなく、エージェントがパイプライン全体を指揮していることを示しています。
Qwenが担うローカライズ生成
Qwen（通義千問）はAlibaba Cloudが開発する大規模言語モデル系列です。200以上の言語を扱える設計が知られ、中国語・英語をはじめとする多言語コンテンツの生成に向いています。短尺動画の台本では、元ネタのトレンド性を保ちつつ、配信先の言語や文体に合わせた書き換えが必要になります。
ローカル推論では、Qwen 3.5 Smallのような小型モデル（0.8B〜9Bパラメータ）がエッジ端末向けに公開されています。ホストにGPUや十分なメモリがあれば、より大きなQwenモデルをvLLMやOllamaで常時稼働させ、Hermes AgentからOpenAI互換API経由で呼び出す形が現実的です。Hermesは alibaba プロバイダーでDashScope APIを使う設定も可能ですが、今回の「ローカルモデルサーバー」という記述から、オンプレ推論が主軸と見るのが自然です。
読者が持ち帰れる設計の示唆
この事例を一般化すると、次の設計原則が見えてきます。
推論と実行を分離する。 重いLLM推論はホストに集約し、軽い端末は投稿・操作だけに専念させる。GPUリソースの無駄遣いを防ぎ、端末台数の拡張もしやすくなります。
エージェントにパイプラインを任せる。 収集・生成・配信を個別スクリプトで繋ぐより、Hermesのようなスキル対応エージェントに一連の手順を覚えさせた方が、トレンドの変化に追従しやすい。DEV Communityの事例でも、Hermesのスキルで複数SNS向けに文体を変えたコンテンツ生成が紹介されています。
ローカル推論で変動費を抑える。 動画本数が増えるほどAPI従量課金は効いてきます。初期のハードウェア投資と引き換えに、月次の推論コストを平準化できる点が、phone farm規模の運用と相性がよいです。
注意すべきリスクと検証の限界
技術的に再現可能な構成であっても、運用上のリスクは別問題です。
多アカウントの自動投稿は、各プラットフォームの利用規約に抵触する可能性があります。phone farm自体がグレー・ブラック寄りの用途で語られることも多く、収益の持続性や法的リスクは投稿だけでは判断できません。
また、月1万8,200ドルという数字はmarfin氏の紹介に基づくもので、売上内訳や端末台数、人件費・電気代・端末償却を差し引いた純利益かは不明です。トレンド動画の台本生成には、元コンテンツの著作権や二次利用の可否も問われます。
学ぶべきは「いかに稼いだか」ではなく、「ローカルLLM・エージェント・端末群をどう配線したか」という設計思想です。自社のマーケティングや社内業務に応用する場合は、公式APIと規約に沿った正規の自動化から始めるのが現実的です。
エッジAI時代の運用基盤として
中国の19歳2人が示したのは、高価なクラウドインフラなしでも、安価な端末とローカルQwen、Hermes Agentを組み合わせれば、コンテンツの量産パイプラインを組めるということです。phone farmという言葉が話題性を持つのは、その規模感と収益のインパクトがあるからです。
本質はもっと地味で、推論をホストに集約し、実行を端末に分散し、エージェントがその間を繋ぐという3層分離です。この型は、広告運用に限らず、多言語の商品説明生成や社内レポートの一括配信など、別の現場にも転用できます。まずは小規模な1ホスト・2端末から検証し、スキルとcronで夜間バッチを回すところから始めるのが、再現の第一歩になります。