Atomic Agent レビュー: llama.cpp 前提のローカルエージェントを導入前に読む
Atomic Agent is a local-first AI agent. Runs open-weight models on your own machine via llama.cpp.
ひと目でわかる
- これは何？
- AtomicBot-ai/atomic-agent は、制御ループと状態をすべて手元のマシンに置く TypeScript 製エージェントだ。llama.cpp を第一級に扱い、ブラウザ操作、ファイル編集、承認制シェル実行、MCP 経由の外部ツール呼び出しをまとめる。GAIA L1 の数値と、開発者プレビューという前提の両方を見て、採用判断の材料を整理する。
- 誰に向いている？
- ローカル推論でマルチステップ作業を回したいが、クラウド API の従量課金を避けたい個人や小規模チームには向く。逆に、安定した API 契約の上に自社製品を組み立てる用途や、Windows x64 以外の Windows 環境は現時点で対象外だ。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
クラウド API を挟まずにエージェントを回したい人向けの設計
Atomic Agent が解こうとしているのは、エージェントの制御ループと状態を外部サービスに預けずに済ませる問題だ。README は「local-first AI agent that runs the control loop and all state on your machine」と説明しており、ブラウザ操作、ファイルの読み書き、承認済みシェルコマンドの実行、文書の検査、セッションをまたぐ文脈の保持、フォローアップのスケジュール、MCP 経由の外部ツール呼び出しまでを一つの CLI から扱う。想定読者は、ローカルの量子化モデルで長いマルチステップ作業を回したい個人開発者や小規模チームだ。トークン課金を避けたい、入力を外部に送りたくない、といった動機が素直に当てはまる。逆に、モデル自体の品質を最優先するならローカル縛りは足かせになる。README 自身が「llama.cpp first」と書き、小型量子化モデルを長時間の作業で使えるようにすることを狙いとして掲げている。
TUI と HTTP、Tauri サイドカーという三つの入口
配布形態は単体の CLI で、起動すると TUI が立ち上がる。README によれば、制御ループと状態はすべてローカルに置かれ、外部からは HTTP 経由か Tauri のサイドカーとして自分のアプリに埋め込める。つまり Atomic Agent は対話用のツールであると同時に、他プロセスから呼ばれるエージェント実行基盤としても提示されている。TUI 内では Ctrl+N または /window で同じディレクトリの新しいウィンドウを開き、二つ目のエージェントを並行して走らせられる。状態はセッションをまたいで保持され、タスクのスケジュール機能も持つ。このあたりの構造は README の記述から読み取れる範囲で、内部のモジュール分割やプロトコル仕様までは示されていない。HTTP 埋め込みを当てにするなら、API の形は自分でリポジトリを確認する必要がある。
インストールとセルフアップデートの実際のコマンド
macOS と Linux は curl -fsSL https://atomicagent.io/install | sh、Windows は PowerShell で irm https://atomicagent.io/install.ps1 | iex を実行する。インストーラはリリースアーカイブを取得し、チェックサムを検証したうえで CLI とサポート資産(grammars/、ネイティブプレビルド、同梱の ripgrep)を配置する。短い別名も一緒に入るので、atomic-agent と atag は同じものを指す。更新は atomic-agent update、新しいリリースの確認だけなら atomic-agent update --check、特定バージョンに固定するなら --version <tag> を使う。README は「Only the installed binary can self-update; a dev checkout updates via git」と明記しており、開発チェックアウトでは自己更新が効かない。アンインストールは atomic-agent uninstall で、状態ディレクトリ(設定、メモリ、セッション、タスク、トレース、ダウンロード済みモデル)、バイナリと別名、資産ディレクトリ、シェル rc に追加した PATH 行までを削除する。削除対象とサイズを表示したうえで uninstall という単語の入力を求める。--dry-run で事前確認、--keep-data でデータ保持、--yes でプロンプト省略ができる。
GAIA L1 の数字は何を比較しているのか
README が示すベンチマークは、公開 GAIA validation Level 1 の 53 タスクを、同じローカルモデル qwen-3.6-35b-a3b(llama-server、UD-Q4_K_XL)、同じステップ上限とタイムアウトで走らせたものだ。変数はエージェントループだけに絞っていると説明されている。結果は Atomic Agent が 37/53 で 69.8%、比較対象の Hermes が 31/53 で 58.5%。タスクあたりの平均 wall time は約 217 秒対約 351 秒で、直接対決では atomic のみが勝ったタスクが 15、Hermes のみが 9 と記載されている。モデルを小さくした場合の数値もあり、qwen-3.5-9b(Q4_K_M)で 28/53 の 52.8%、gemma-4-12b(it-qat UD-Q4_K_XL)で 24/53 の 45.3% だ。9B でも半数を超えると README は述べている。ここで注意したいのは、これが単一モデル・単一データセットでの比較であり、自分の用途のタスク分布を代表する保証はないという点だ。また 12B のケースでは精度が下がるだけでなく平均時間が約 423 秒に伸びており、小型化が常に速度と引き換えにならないことも読み取れる。
Hermes や OpenClaw からの移行を前提にした import 経路
Atomic Agent は既存エージェントからの乗り換えを明示的に想定している。初回起動時に Hermes、OpenClaw、Claude Code、Codex からスキル、メモリ、MCP サーバー、セッション、cron ジョブ、そして任意でプロバイダキーを取り込む提案が出る。書き込み前にドライランで内容を確認できると README は説明する。後からでも TUI で /import、シェルから atomic-agent import <hermes|openclaw|claude-code|codex> を実行できる。この設計は、比較対象である Hermes と競合するというより、Hermes 利用者の移行先として自分を位置づけていることを示す。移行経路が用意されていること自体は採用の障壁を下げるが、取り込まれる資産の互換性がどの程度検証されているかは README からは分からない。dry-run の出力を実際に読んでから確定するのが妥当だ。
開発者プレビューであることの実務的な意味
README は自らを Developer preview と位置づけ、「APIs, commands, config, and behavior are still moving」と書いている。安定した統合点が必要ならリリースを固定せよ、という注記まで付いている。これは採用判断において最も重い制約だ。HTTP 埋め込みや Tauri サイドカーとして自社製品に組み込む場合、破壊的変更が来る前提でバージョンをピン留めし、アップグレードを能動的に管理する必要がある。対応ビルドも macOS Apple Silicon、Linux x64/arm64、Windows x64 に限られ、README の時点でそれ以外のプラットフォームは挙げられていない。Node.js は >=25.7 が要求される。またベンチマークはすべて GAIA という汎用タスクでの数値であり、業務固有のワークフロー、たとえば社内システムの操作や特殊なファイル形式の扱いで同じ精度が出るかは確認されていない。ここは自分で評価するしかない領域だ。
向くケースと向かないケース、そして最初に確かめること
向くのは、手元のマシンで完結させたい人、従量課金を避けたい人、そして多少の仕様変更を許容できる開発者だ。アンインストールが単一コマンドで完結し、削除対象とサイズを提示してから確認を求める設計は、試してやめるという判断をしやすくしている。向かないのは、長期サポートされた安定 API の上に製品を載せたい場合や、Windows x64 以外の Windows、README に挙がっていないアーキテクチャを使う場合だ。代替として README が名指しする Hermes は、同じ GAIA L1 で 31/53、平均約 351 秒という結果が示されている。違いは精度と速度に現れているが、より本質的には、Atomic Agent が llama.cpp と TurboQuant を前提にローカル推論のスループットを前面に出すのに対し、Hermes はその比較の相手側として置かれているという位置づけの差だ。乗り換えを検討するなら、まず atomic-agent import hermes の dry-run を走らせ、どのスキルとメモリが実際に移るかを目で確認する。次に自分の代表的なタスクを数件、手元のモデルで実行して、README の GAIA の数値が自分の環境でも意味を持つかを確かめる。ライセンスは MIT で、商用利用を含む条件は LICENSE ファイルの原文で確認できる。ただしこれは法的助言ではない。
編集部の結論
ローカル推論でマルチステップ作業を回したいが、クラウド API の従量課金を避けたい個人や小規模チームには向く。逆に、安定した API 契約の上に自社製品を組み立てる用途や、Windows x64 以外の Windows 環境は現時点で対象外だ。導入前に確認すべきは、README が挙げる対応ビルド(macOS Apple Silicon、Linux x64/arm64、Windows x64)に自分の環境が入るか、Node.js >=25.7 を用意できるか、そして GAIA L1 の 69.8% が単一モデル qwen-3.6-35b-a3b での数値であり自分の手元のモデルにそのまま移らないという点である。
コミュニティノート