6.17MiB・起動10μs——"組み込み用"コーディングエージェントという発想

「6MB・10マイクロ秒」を看板にしたエージェントが出てきた

fxは、コーディングエージェントのハーネス＋CLIをZig言語で実装したオープンソースプロジェクトだ。公式サイト（fx.sh）とGitHubリポジトリ（vercel-labs/fx）によれば、ネイティブバイナリは約6.17MiB、コールドスタートは10マイクロ秒。Apache-2.0ライセンスで公開され、この記事を書いている時点でGitHubスター3,000超と、Hacker News掲載直後としては大きな反響を得ている。

この記事の題材は、当初「個人開発者の投稿」として拾ったものだった。だが公式サイトとGitHub READMEを実際に確認すると、開発元はVercel Labs——Vercel社内で元々使っていたツールを、研究・大規模システムへの組み込み向けに最適化した上で公開したものだと分かった。個人の趣味プロジェクトと大手ベンダーの内製ツール放出では、読み方が変わる。出典の裏取りを先にやってよかった一例として、まず訂正しておく。

Fast / Light / Open——3つの原則

公式サイトはfxの設計思想を3つの原則で説明している。いずれも「日常使いを快適にする」ためではなく、「エージェントを別のシステムやサンドボックスの中に埋め込む」ことを前提にした原則だ。

Hacker Newsは「軽さ」ではなく別の点で割れた

掲載スレッド（318ポイント・137コメント、2026年8月中旬）を読むと、称賛と懐疑がはっきり分かれていた。称賛の中心は「軽さそのもの」よりも、Unixシェルに近いCLI出力や最小限のシステムプロンプトといった組み込みやすさの設計、そしてWebAssemblyターゲットへの関心だった。数字の軽さは注目を集めるフックだが、コメント欄が本当に評価していたのはそこではない、という読み方だ。

一方で懐疑論も具体的だった。要点は3つに整理できる。

• 差別化不足への指摘——「既にある100以上のコーディングエージェントと本質的に違うのか」という声。軽量・高速という切り口自体は新しくない。
• 「ミニマル」との矛盾——公式は最小限の設計を謳う一方で、標準搭載のツール数が26個ある点を指摘され、「それはミニマルと呼べるのか」という突っ込みが入っていた。
• Vercelへの依存と継続性への不安——公開初期は対応プロバイダがVercel AI Gateway中心で「Vercel色が強い」と見られたこと、そして大手ベンダーの実験的プロジェクトが後に放置される例が過去にあった、という懸念。

バイナリサイズについても「Zigでこの規模なら、もっと絞れるのではないか」という最適化余地を指摘するコメントがあった。看板の数字自体が、コミュニティの目には「まだ伸びしろがある値」として映っていたことになる。

「乗り換え」ではなく「埋め込み」という別カテゴリ

FLOWでこれまで扱ってきたハーネスの固定費実測（起動時に何トークン消費するか）とfxは、同じ「軽さ」というテーマでも向いている方向が逆だ。固定費実測は「今使っているハーネスの重さを正確に知る」話だったのに対し、fxは「そもそも重さそのものを設計目標として極限まで削る」話になる。

fxが想定する使い道は、個人開発者が毎日ターミナルで対話するメインのコーディングエージェントを乗り換えることではない。むしろ、ブラウザ上のツールに組み込む・大量のサンドボックスを並列起動する・研究用に何百回も起動と終了を繰り返す、といった「起動コストそのものが積み重なって効いてくる」場面向けの部品として設計されている。日常のコーディング作業をfxだけで完結させる記事ではなく、「自分のツールに小さなエージェントを埋め込みたくなったら選択肢に入る」くらいの距離感で捉えるのが実態に近い。

実機検証はしていない、という前提で読んでほしい

この記事はfx.shの公開情報・GitHub README・Hacker Newsの議論を一次情報として整理したもので、実際にfxをインストールして起動速度やバイナリサイズを自分の環境で再現検証したわけではない。素性の分からない実行ファイルを無条件に動かす判断はしていないため、10マイクロ秒やメモリ使用量といった数値は「公式の主張・第三者の観測」としてそのまま紹介している。自分の環境で追試する場合も、実行前に配布元と署名を確認するところから始めてほしい。