Simile AI が $2B 調達しシミュレーションが新たなスケーリング則に、Qwen3-TTS で p95 応答 50ms 未満・1M 文字約 $2、パフォーマンス最適化のコストが桁で下がったほか7件

今日の3行

Simile AI が $2B の Series B を調達しました。GreenOaks と Index Ventures が主導し、Andrej Karpathy・Fei-Fei Li も出資します。人間のデジタルツインで意思決定を検証する「シミュレーション」が新たなスケーリング則になりつつあり、フォーカスグループに代わる市場検証の手段として SaaS のユーザー検証にも波及します。
Qwen3-TTS 1.7B の自前実装で p95 応答 50ms 未満を実現した事例が公開されました。1M 文字あたり約 $2（ElevenLabs V3 は $100）で、TTS のコストが約 1/50 になります。音声機能付き SaaS の採算ラインが一変します。
LLM によりパフォーマンス最適化のコストが桁で下がり、JIT コンパイラのような高度な最適化も個人で作れる時代になったという分析が公開されました。これまでコストが見合わなかった最適化が個人開発でも実行可能になります。

深掘り: Simile AI が $2B 調達——人間のデジタルツインで市場検証する「シミュレーション」が新たなスケーリング則に

要点 Simile AI が $2B の Series B を調達しました。GreenOaks と Index Ventures が主導し、Fei-Fei Li と Andrej Karpathy が著名な出資者として名を連ねます。同社は Fortune 100 のクライアント（CVS など）向けに数千万回のシミュレーションを実行しており、人間のフォーカスグループと比較して 85–99% の精度を達成しています。

創業者で CEO の Joon Sung Park は、2023 年のランドマーク論文 Generative Agents（Smallville）で、AI キャラクターが記憶し、計画し、社交し、創発的行動を発達させることを示しました。現在は人間の行動のファウンデーションモデルを構築し、いずれ地球上の全 80 億人をシミュレートすることを目指しています。「決定を下す前に世界をシミュレートできたらどうか」という問いです。

なぜ重要か Karpathy と Fei-Fei Li が出資する Simile が、フォーカスグループの代わりに人間のデジタルツインで意思決定を検証する流れを牽引しています。2024 年の「Summer of Simulative AI」は短い夏で終わると見られていましたが、4 月の SimGym に続くこの調達で「シミュレーションの第2の夏」が本格化しました。

個人開発者にとっても、SaaS のユーザー検証をシミュレーションで代替する選択肢が現実味を帯びてきます。高額な人間パネルを合成人口で置き換える動きは、市場リサーチのコスト構造を変えます。そして市場リサーチはシミュレーションの出発点にすぎず、製品やポリシーを展開する前にテストする使い方が主戦場になります。

仕組み Simile のアプローチは複数のデータ源を組み合わせます。長期インタビュー、観察・トランザクションデータ、ランダム化比較試験、人口レベルと個人レベルのモデル、そして人々が意思決定する因果メカニズムへのポストトレーニングです。

注目すべきは再現精度です。研究で作られたデジタルツインは、人間が自分の回答を再現する精度と同等の 85% の精度で、人間の行動と態度を再現しました。実在の 1,000 人からデジタルツインを作り、85% の行動精度を達成しています。

現在のフロンティアモデルは人間の実際の行動を捉えられないと Park は指摘します。合理的になるよう最適化されたモデルは、非合理的な人間のシミュレーションとしては不適切です。ウェブデータは人々が実際にやることより「言うこと」を捉えるため、インタビュー・トランザクション・観察データが必要になります。さらに「社会物理学」の理解には、フロンティア LLM へのプロンプトではなくモデルの重みの変更が必要だと主張します。ランダム化比較試験でのポストトレーニングにより、人間のバイアスや失敗まで再現するシミュレーションを作ります。

シミュレーションにはスケーリング則があり、将来はデータセンター規模のシミュレートされた世界の経済が論点になります。人口レベルのシミュレーションは、気候変動、民主主義の不安定化、UBI のような社会全体の問題を扱う可能性を秘め、マルチエージェントでシミュレートされた人々が相互作用するとどうなるかも研究対象です。

導入するなら

ユーザー検証のシミュレーション代替を検討します。フォーカスグループ対比 85–99% の精度が現実に達成されている以上、高額な人間パネルへの依存を減らす選択肢として無視できません。
市場リサーチはシミュレーションの出発点にすぎません。製品を展開する前にテストし、望ましい成果への直感に反する経路を発見する使い方が価値の中心です。
予測よりも「未来をどう形作るか」の理解に重点を置きます。シミュレーションは未来を予測するためではなく、形作るために使います。
既存の LLM をプロンプトで誘導するだけでは人間の行動を再現できません。意思決定の因果メカニズムを学ばせるポストトレーニングが必要になる点を踏まえ、自前で作る場合もコストと精度の見積もりを行います。

原典 Simulation: the new Scaling Law — Joon Sung Park, Simile AI

2. Qwen3-TTS 1.7B で p95 応答 50ms 未満、1M 文字あたり約 $2

要点 Nari Labs が Qwen3-TTS 1.7B CustomVoice の実装で、10 リクエスト/秒（RPS）と p95 の time-to-first-audio（TTFA）50ms 未満を実現しました。単一の NVIDIA H100 SXM 上でリアルタイム再生を維持しながら達成しています。

5 つの実装（自社、vLLM-Omni、SGLang-Omni△、VoxServe、M*）を Poisson オープンループトラフィックで比較し、低レイテンシストリーミング向けに各実装をチューニングした結果、p95 TTFA 50ms 未満を達成できたのは自社実装のみでした。10 RPS まで p95 TTFA 50ms 未満を維持し、20 RPS でも 100ms 未満を保ちます。

コスト面では、10 RPS で毎秒約 630 文字を生成します。1× H100 SXM インスタンスの $4.29/時間に対して、フル稼働時で 1M 文字あたり約 $2 になります。比較として ElevenLabs V3 は $100 / 1M、Cartesia Sonic 3.5 は $49 / 1M（より高い TTFA）です。実装とベンチマークはオープンソースで公開されています。

「リアルタイム」TTS の定義として、可聴 TTFA の低さ、再生開始後のバッファ枯渇なし（underrun ゼロ）、RPS 増加時の容量維持、出力の明瞭さ（非破損）の 4 点を挙げています。Qwen3-TTS CustomVoice 1.7B は許可の緩いライセンスを持つ最も人気のある TTS モデルの一つであるため選定されました。ベンチマークは Fireworks AI の LLM ベンチマークに従い、Poisson オープンループトラフィックで 5 分間実行され、各エンジンはテキスト全体を単一の HTTP リクエストで受け取り、音声出力はストリーミングされます。

なぜ重要か TTS を製品に組み込むコストが約 1/50 になります。オープンウェイトモデル + 自前実装で音声機能付き SaaS の採算ラインが一変するため、コスト計算の前提を見直す必要があります。

原典 How we made a text-to-speech model respond in sub-50 ms

3. 自己ホストのサンドボックス型エージェント工場——1 つのプロンプトでリポジトリ作成からデプロイまで自律実行

要点 1 つのプロンプトを与えるだけで、リポジトリの作成、アプリとテストの実装、CI のグリーン化、Postgres のプロビジョニング、HTTPS での本番デプロイまで、追加のメッセージなしに自律実行させる実験が成功しました。自宅サーバー上で完結し、実験固有の継続コストは £20/月の Codex サブスクリプションのみです。

きっかけは、ジム用のウェイトトラッカーが欲しかったのにアプリストア版は £12/月だったため、Claude で一度に作り上げたことです。ただ、オートモードで LLM にマシンへの root アクセスを与えるのは不安が残るため、「LLM を信頼するのではなく構造的に隔離する」完全リモートのエージェント開発環境を構築しました。スタックとパッケージの調査、コードとテストの計画・実装、Git へのコミットと CI の実行、データベース・o11y・ドメイン・SSL を備えた本番サーバーへのデプロイまで自律的に進みます。

構成ハードウェアは 2 台構成です。5 年間ホームラボとして稼働する 2014 年製デュアルコア i3（このブログと Pi-hole から Prometheus / Loki / Grafana まで約 45 個の Docker コンテナをホスト、ポート 443 をルーターから転送）と、eBay で購入した 2021 年製第 10 世代 i7・32GB RAM の何も入っていないサーバーです。LLM に壊されたくない既存サーバーではなく、新品のサーバーを使います。

開発スタックは Coolify（Docker ベースのセルフホスト PaaS）で自己ホストし、Forgejo（セルフホストの Git と CI）、Hermes（Codex を推論に使う OpenClaw 風の仮想アシスタント）、Firecrawl（エージェントと Web の間のスクレイピング層）、Telegram、Porkbun と Let’s Encrypt、Pi-hole、Tailscale を組み合わせます。推論や Tailscale・Telegram・DNS・ACME などの統合はボックス外に出ます。

ネットワークは外部イングレスなしの構成です。ポート 443 の転送があるのは古いサーバーのみで、新サーバーには外部からの入口がなく攻撃面を大きく削ります。外出時は古いサーバーを出口ノードとする Tailscale 経由でアクセスし、Pi-hole の dnsmasq ルール（address=/internal.jakeshomelab.me/192.168.1.201）で内部ドメインを Coolify のリバースプロキシに解決します。

SSL 証明書には DNS-01 チャレンジを使います。Porkbun の API キーを Coolify の環境に設定し、新しい URL を登録すると Traefik が Porkbun API で _acme-challenge の TXT レコードを作成し、Let’s Encrypt が検証して証明書を発行し、Traefik が削除します。パブリックな A/AAAA レコードを一切作らずに、テールネット内だけで到達可能な有効な HTTPS URL がその場で発行されます（ホスト名は公開の証明書透過性ログに残る可能性がありますが、サービスはテールネットからしか到達できません）。

GitHub を選ばなかった理由は、GitHub トークンをボックスに渡すと隔離が損なわれること、API と CI の分単位の制限が合わないこと、最近はダウンすることが多いことです。Hermes の特徴は、ワークスペースを Docker ホストからマウントして Samba で共有するファイルシステム、ログイン情報不要で 2 分でセットアップできる Telegram 連携、ドキュメントと MCP を読んで Coolify 用スキルを自作する自己構築スキルなどです。

なぜ重要か エージェントに root を渡さず構造的に隔離する実装パターンが実例つきで示されています。専用マシンへの隔離、外部イングレスの排除、DNS-01 によるゴーストサービスへの SSL 発行という組み合わせは、自動化と安全性を両立したい個人開発者がすぐ真似できる設計です。

原典 Building an (almost) fully self-hosted, sandboxed, agentic software factory

4. エージェントハーネスの進化——モデルが吸収し続け、残るのは人間の注意を導くハーネス

要点 2025 年のクリスマス頃、AI エンジニアはエージェントの変化に気づきました。「動くようになった」という変化です。原因の特定は難しいですが、本稿の主張は、モデルとハーネスが共に改善し、その改善曲線がちょうど交差したことの合流点だというものです。そして次に来るのは、モデルがハーネスを重みへ吸収し続け、エンジニアが吸収されたものを削除し続け、残るのはモデルではなく人間の注意を導くハーネスになる、という展望です。

Transformer の発明者の一人である Lukasz Kaiser は、6 月の “Unsupervised Learning” で「去年の冬・クリスマスの変化は特定しにくい。ハーネスが変わり、少しポストトレーニングが変わり、新しい事前学習モデルが出てきて…何が原因か特定しにくい大きなジャンプのように感じた」と語っています。答えはモデル重みだけではなく、重みの周りに育ったシステム、つまりエージェントハーネスにあります。

エージェントハーネスとは、モデル重み以外でエージェントを機能させるすべて、環境・ツール・文脈・ガードレールです。ハーネスはモデルの心に身体を与えます。文脈で知覚し、ツールで行動し、メモリとコンパクションで情報を永続化し、権限とガードレールで境界を強制します。2022 年 11 月の ChatGPT は次トークン予測と RLHF だけで、ツール・検索・推論を持たず、トレーニングデータとプロンプトに閉じ込められた「壺の中の脳」でした。

進化は 2 つの曲線の関係として整理されます。ハーネスがモデルに要求することと、モデルが実際に提供できること。このギャップがエージェントの有効性であり、その縮小がエージェントの飛躍的な改善をもたらしました。

ReAct「紙の上のハーネス」(2022 年 10 月) — 推論→行動→観察→繰り返しのエージェントループをプロンプティングで定義。ChatGPT より 1 か月先行します。同年 2 月の Toolformer（Meta）は、ツール使用がプロンプトではなく学習できることを示唆しました。
AutoGPT/BabyAGI「時期尚早な自律」(2023 年春) — ハーネス曲線がモデル能力曲線を大きく先行。ループは能力を増幅するだけで、閾値以下ではエラーを増幅します。1 ステップ 95% の信頼性でも、20 ステップのタスクの成功率は約 36% です。
Cursor/Copilot「人間をループに戻す」(2023–2024) — モデルにループを与えず、人間にループを与えてオーケストレーションさせる戦略です。Devin の初版は自律をモデルに戻そうとしましたが、Answer.AI のテストで成功率約 15% と時期尚早でした。
o1（2024 年末） — 初の推論モデルの登場で初めてギャップが逆転し、モデル能力のオーバーハングの兆しが見えました。
Claude Code「曲線の交差」(2025 年 2 月) — モデルがハーネスより先行した以上、ブレーキをかけるハーネスは能力を無駄にしていると判断。IDE を捨ててターミナルに移り、bash とファイル読み書きアクセスを与え、変更ごとの人間承認を権限ルールで置き換えました。Boris Cherny とチームは現在のモデルではなく次世代モデルの能力を見据えて構築し、約 6 か月で約 $1B ARR に成長しました。

現在、2 つの曲線は交差するだけでなく編み合わさり始めています。Harness-Bench は同じモデルを同じ 106 タスクで異なるハーネスで実行し、スコアは 52.4 から 76.2 まで 23.8 ポイントの開きが出ました。モデルはゼロ変更です。「エージェントの半分はハーネス」ということになります。OpenAI も ARC-AGI-3 で同様の結果を得ており、retained reasoning とコンパクションを追加しただけで GPT-5.6 Sol のスコアは 13.3% から 38.3% に 3 倍になりました。

RL はハーネスの内部に移動しています。OpenAI の codex-1（2025 年 5 月発表）は「さまざまな環境での実世界のコーディングタスクで強化学習を用いて訓練」されました。モデルがハーネスの環境で訓練されると、ハーネス能力を重みに吸収し始めます。GPT-5.1-Codex-Max は「コンパクションによる複数コンテキストウィンドウにまたがって動作するようネイティブに訓練された最初のモデル」と発表されました。モデルがハーネス能力を吸収すると、ハーネスは足場を外せます。Anthropic の Thariq Shihipar は、Claude Code のシステムプロンプトの 80% を削除したと語っています。

なぜ重要か エージェントが「いつ・なぜ動くようになったか」の構造理解が得られます。ハーネス曲線とモデル能力曲線のギャップがエージェントの有効性だという枠組みは、ツール選定やアーキテクチャ判断の共通言語として使えます。エージェントの成果の半分がハーネスに帰属するという測定結果は、モデル選びと同じ重みでハーネス設計を検討すべきことを示しています。

原典 The Evolution of the Agent Harness

5. LLM によりパフォーマンス最適化のコストが桁で下がり、JIT コンパイラのような高度な最適化も個人で作れる時代に

要点 Dan Luu が、かつて専門的なスキルを持った人物やチームを必要としたパフォーマンス最適化のコストが桁違いに下がり、数文を入力できる人なら誰でも実行できるようになったと論じています。これまで最大規模・最も収益性の高いプロジェクト以外では割に合わなかった最適化が、今では何でも行えます。

Marc Brooker は、特定のワークロード群ではなく個別のワークロードにフィットした動的カスタムソフトウェアが非常にありそうな帰結だと同意します。FFTW や、特定の問題・特定のハードウェアに特化して超高速・超小型を追求したデモシーン技法（コードをテクスチャとして再利用して優れたキャッシュ局所性を得るデモなど）を連想させます。Michael Malis は、JIT コンパイラは「コードを書くこと自体が難しかった」分野の代表例であり、その希少性から実装が困難すぎて割に合わなかったと指摘し、LLM が参入障壁を下げて JIT コンパイラを書きやすくしたと述べます。データベースも歴史的に最も難しいソフトウェアとされて制約を受けていましたが、AI によりより野心的なソフトウェアを構築できるようになります。

実験結果 前回の記事で作った正規表現エンジン FRE は、エージェントが rebar ベンチマークスイートにアクセスして 1 か月間性能改善ループを回して作られ、rebar に過学習していました。ホールドアウトベンチマークがあると警告したところ、エージェントは最適化を汎化させました。ネイティブ AOT コンパイル版は長い検索で良好な結果を示しており、ripgrep が通常のマッチャで動作している間に別スレッドでネイティブコードコンパイラを実行し、コンパイル完了後に切り替える案が示されます。短いクエリではコンパイルにスレッドを失うため一般的には悪化しますが、数秒より数十秒・数分かかるケースを重視するなら許容できるトレードオフです。

人間時間で数分あればこの実験も試せます。実際に codex 履歴由来の ripgrep クエリでベンチマークを実行したところ、長いクエリではごく単純なクエリ数件で 2x–4x の性能改善、AOT を有効化すべき代表的なホールドアウトクエリでは約 7% の高速化でした。

テキストの繰り返し検索ならインデックスを作るのが明白な解ですが、ポイントはかつて時間と専門性を要した技術作業が今は簡単にできることです。Dan Luu は Bing の検索インデックス BitFunnel（定数時間の高速テキスト取り込みに特化し SIGIR で最優秀論文賞を受賞）に関わっており、オープンソース版はバイトコードインタープリタと JIT 1 つのみですが Bing 版は複数の JIT コンパイラを含みます。かつて大規模な事業だったレベルの最適化が「週末でできる」と真実になった一方、$200/月のアカウントでは高速化した ripgrep と既製インデックスで十分としています。

Azul AI の事例 最適化コストの激減は 2025 年 11 月頃まで遡ります。GPT-5.1 か 5.2 の時代、ゲーム AI の知識なしに作った Azul AI は、かなりの差で世界最強になりました。2 番目に強い AI を記述する論文から推定すると、自分の AI は「AI」の面では少し優れている程度ですが、最適化の面で勝っており、2 桁ほど少ない時間で、クラスタではなく主にラップトップ上で達成しています。相手はシングルスレッドですが自分の AI はマルチスレッドで、ネイティブコード版に加えて wasm 共有メモリ + JavaScript 版を持ち、小型で高速なネット用の minimax と大型ネット用の MCTS という 2 つの検索アーキテクチャを備えます。手作業ならかなりの大仕事ですが、LLM に誤った推論でマルチスレッドアルゴリズムを選ばせた後、30 分かけてゲーム AI のマルチスレッドアルゴリズムを自分で読んで、codex に複数回書き直させました。

なぜ重要か これまでコストが見合わなかった最適化が個人開発でも実行可能になります。速度・コストで差をつけたい場面での新たな選択肢です。

原典 There’s no reason for software to be slow anymore

6. Claude の BuzzFeed 口調を別モデル（Gemini / Antigravity CLI）で翻訳する Claude Code スキル「/debuzz」

要点「Anthropic が Claude を昔の BuzzFeed の記事だけで訓練したのはもはや共通認識」という前置きで始まる README が、Claude と共同で作った Claude Code スキル「/debuzz」を紹介しています。Claude の最後の応答を Antigravity CLI（agy）に通し、ミレニアル世代のクリックベイト口調から普通の英語に翻訳します。「Claudette」と呼ぼうと考えていますが、Cat Wu が訴訟好きで有名なため、絶対に「Claudette」とは呼ばれません（と書かれています）。

問題 Claude は優れたエンジニアですが、ひとつだけ治らない症状があります。自分のプルリクエストについて TED トークをしているような話し方です。テストがフレークする理由を尋ねると、「load-bearing assumption」と 3 つの番号付きの啓示、そして 3 つ目が最も教訓的だという厳粛な注記が返ってきます。何もかもが単なるバグではなく、必ず kicker（どんでん返し）があります。

このスキルは、どんなプロンプトでもこの口調を完全には治せないことを認め、正直なやり方を選びます。応答を別のモデル、Google の Antigravity CLI 経由の Gemini に渡し、「人間らしく話す」ことだけを仕事にさせます。Claudette は Antigravity の翻訳を逐語的に出力すると約束しています。Claude に翻訳を「きれいに整え」させると、まさに除去したい口調が再導入されるためです。

before / after 実際の例を示します。Before（Claude）は「ここからが面白いところです: リトライロジックは単なる nice-to-have ではありません——同期パイプライン全体の load-bearing assumption です。3 つのことが目に飛び込んできましたが、3 つ目が最も教訓的です。[…] そして 3 つ目——これが kicker です——dedupe キーにはタイムスタンプが含まれており、リトライが実際には決して重複排除されません」という調子です。

After（/debuzz、同僚モード）では「同期パイプラインのリトライロジックには 3 つのバグがあります。syncQueue.ts:142 は ETIMEDOUT を飲み込んでジョブを再キューに入れません。バックオフは 2 秒で上限に達し、モバイルネットワークには低すぎます。dedupe キーにはタイムスタンプが含まれており…」と、指摘がそのまま簡潔に並びます。

なぜ重要か Claude Code の出力を簡潔にするワークフローの実例です。エージェント出力の品質を上げる小技として今日から試せます。

原典 Claudette: Make Claude stop talking like a BuzzFeed article

7. Hugging Face が公開 ASR ベンチマークを丸暗記しているモデルを検出する 3 つのテストを開発、11 モデル中複数で「ベンチマックス」を確認

要点公開の音声 AI ベンチマークはモデルが人間レベルで動作していることを示唆するようになりましたが、そのスコアは実世界での動きを常に反映するとは限りません。公開ベンチマークはオープンで広く使われるため、モデルがテストそのものに最適化されることがあります。スコアが改善したのは基礎タスクに優れたからではなく、ベンチマーク固有のパターンを学習したためかもしれません。

この現象は「benchmark optimization」または「benchmaxxing」と呼ばれ、機械学習の文脈ではよく議論されますが、音声認識では測定が難しいとされてきました。今回の研究では 3 つのテストを導入して定量化し、広く使われるオープンソース ASR モデル 11 個を評価しました。最高スコアのシステムの複数が、音声が矛盾している場合や関連語が消音されている場合、音声が 2 つの書き方のどちらも同様に支持する場合でも、VoxPopuli English と LibriSpeech（clean, other）のベンチマーク転写を再現しました。一部のモデルは言われた内容だけでなく、どのベンチマークでテストされているかを示す微妙な音響的手がかりにも依存しており、その結果、スコアは一般的な音声転写能力を過大評価していました。

Hugging Face はこれに先立ち、Real World VoiceEQ・Open-ASR Leaderboard・Far-field ASR Leaderboard にホールドアウトセットを導入していますが、測定を広げるだけでは解決しないとしています。VoxPopuli は転写エラーが多いことで知られており（Artificial Analysis がクリーニング版を公開した理由です）、コンセンサス不一致プローブ（consensus disagreement probe）では、低い音素誤り率（PER）で選ばれた独立モデルのアンサンブルを使い、モデルがベンチマークの参照転写と全会一致で食い違うケースをフラグし、人間のアノテーションと比較して検証します。あるクリップでは音声に「Thank you, Mr. President」と明瞭に含まれているのに参照転写は「Thank you」を省略しており、テストした 11 モデル中 6 つが音声と矛盾する誤った転写を再現しました。「Thank you」を省略したモデルは「Mr」をピリオドなしで書くなどベンチマークの句読点スタイルも再現しました。同じ内容を新規収録の EU 議会録音や一般的な声で提示するとこの挙動は弱まるか消え、モデルがベンチマークの帰属を識別する音響的手がかりに反応していることを示唆します。

この問題は広範かつ重大です。方法論は分析した VoxPopuli テストクリップの 40% で潜在的な参照エラーをフラグし、全参照語のおよそ 3% に影響しました。ベンチマーク最適化の挙動を示すモデルは、誤った参照転写を 18–30% の頻度で再現しました。WER が最も低く、報告されるベンチマーク性能が最も強いモデルほど、こうしたエラーを再現する可能性が高いという結果です。もう 1 つのテスト（Masked Entity Retrieval）ではテストデータの音声サンプルの数字を意図的に消音し、音声に数字が文字どおり存在しないためモデルは数字を出力すべきではない状況を作りますが、比較的ランダムな年（2011）を消音されているにもかかわらず自動補完したモデルも確認されました。

なぜ重要か ASR モデル選定時にベンチマークスコアを鵜呑みにできない根拠が示されています。実利用での精度評価の重要性が裏付けられた情報です。

原典 Measuring benchmark optimization in speech recognition