ハクソク

世界を動かす技術を、日本語で。

Show HN: Axe – AIフレームワークを置き換える12MBのバイナリ

48日前原文(github.com)

概要

Axeは、LLMエージェントをUnixプログラムのように扱うCLIツール。
エージェントはTOMLで定義し、小さく、集中し、組み合わせ可能。
標準入力パイプやcron、CIなど既存ツールと連携可能。
DockerやMCPサーバーにも対応し、多様な運用が可能。
PythonやGUI不要、Go製の軽量バイナリで完結。

Axeとは何か

  • LLMエージェントをCLIから管理・実行できるツール
  • TOMLファイルでエージェントを定義し、各エージェントは特定の役割に集中
  • Unixの哲学を継承し、「1つのことをうまくやる」エージェント設計
  • 標準入力パイプやcron, git hooks, CIなど、既存の開発フローとの統合
  • デーモン不要、GUI不要、フレームワーク依存なしの設計
  • 12MBバイナリ、Go製、最小限の依存関係のみ

主な特徴

  • マルチプロバイダー対応：Anthropic, OpenAI, Ollama（ローカルモデル）
  • TOMLベースの宣言的エージェント定義：バージョン管理も容易
  • サブエージェント呼び出し：エージェント同士の連携、深さ制限・並列実行
  • 永続メモリ：Markdownログによる過去コンテキストの保持
  • メモリGC：LLMによるパターン解析とトリミング
  • スキルシステム：SKILL.mdによる再利用可能な指示セット
  • 標準入力パイプ対応：他ツールからの出力を直接エージェントに渡す
  • ドライランモード：LLM呼び出し前のコンテキスト確認
  • JSON出力：スクリプト連携用の構造化データ
  • 組み込みツール：ファイル操作やシェルコマンド実行
  • MCPツール対応：外部MCPサーバーと連携可能
  • 最小依存：cobra, toml, mcp-go-sdk, x/netのみ

インストール方法

  • Go 1.24+ 必須
  • go install github.com/jrswab/axe@latest でインストール
  • ソースビルドも可能（git clone & go build）

クイックスタート

  • 設定ディレクトリ初期化
    axe config init
  • 新規エージェント作成
    axe agents init my-agent
  • 設定編集
    axe agents edit my-agent
  • エージェント実行
    axe run my-agent
  • 他ツールからパイプで入力
    git diff --cached | axe run pr-reviewer
    cat error.log | axe run log-analyzer

例とサンプル

  • examples/ ディレクトリに即利用可能なエージェント例を収録
    • コードレビュアー、コミットメッセージ生成、要約など
  • APIキー設定後、サンプルエージェントをコピーして即利用可能

Dockerでの利用

  • Dockerイメージ提供、隔離環境での実行が可能
  • 設定・データディレクトリをマウントし、APIキーを環境変数で渡す
  • 標準入力パイプも -i フラグで利用可
  • docker-compose.yml も用意されており、Ollama連携やクラウドプロバイダー利用も容易
  • セキュリティ強化設定（非root, 読み取り専用rootfs, cap_drop, privilege escalation無効）

エージェント設定（TOML）

  • agents/ ディレクトリにTOMLファイルで定義
  • name, modelは必須。他は任意
  • system_prompt, skill, files, workdir, tools, sub_agents, memory, mcp_servers, paramsなど細かな設定が可能

組み込みツール一覧

  • list_directory：作業ディレクトリ内のディレクトリ内容一覧
  • read_file：ファイル内容を行番号付きで取得
  • write_file：ファイル新規作成・上書き
  • edit_file：ファイル内テキスト置換
  • run_command：シェルコマンド実行（sh -c）
  • call_agent：サブエージェント呼び出し（sub_agents設定時）

パス・セキュリティ

  • ファイル操作は作業ディレクトリ内にサンドボックス化
  • 絶対パス、..トラバーサル、シンボリックリンク逃避は拒否

MCPツール連携

  • [[mcp_servers]]でMCPサーバーを宣言
  • サーバー起動時に利用可能なツールを自動検出し、LLMから利用可能に
  • 名前が被った場合は組み込みツールが優先

スキル（SKILL.md）

  • エージェントにドメイン知識やワークフローを与える再利用可能な指示セット
  • community SKILL.md形式に準拠

CLIコマンド一覧

  • axe run <agent>：エージェント実行
  • axe agents list：エージェント一覧表示
  • axe agents show <agent>：エージェント設定詳細表示
  • axe agents init <agent>：新規エージェントTOML作成
  • axe agents edit <agent>：TOML編集
  • axe config path：設定ディレクトリパス表示
  • axe config init：設定ディレクトリ初期化
  • axe gc <agent>：エージェントのメモリGC
  • axe gc --all：全エージェントGC
  • axe version：バージョン表示

よく使うフラグ

  • --model <provider/model>：モデル上書き
  • --skill <path>：スキルファイル上書き
  • --workdir <path>：作業ディレクトリ上書き
  • --timeout <秒数>：タイムアウト設定
  • --dry-run：LLM呼び出しせずにコンテキスト確認
  • --verbose/-v：デバッグ情報出力
  • --json：JSONラップ出力

環境変数

  • ANTHROPIC_API_KEY：Anthropic利用時必須
  • OPENAI_API_KEY：OpenAI利用時必須
  • AXE_OLLAMA_BASE_URL：Ollama利用時必須
  • AXE_ANTHROPIC_BASE_URL, AXE_OPENAI_BASE_URL：各APIエンドポイント上書き用

まとめ

  • Axeは「小さく・集中・組み合わせ可能」なLLMエージェント実行環境
  • CLI/Unixツールとの親和性が高く、既存の開発フローに簡単統合
  • Python不要、GUI不要、Go製の高速・軽量バイナリ
  • DockerやMCPサーバーとの連携もサポートし、柔軟な運用が可能
  • AIエージェントを活用した自動化やワークフロー改善に最適

Hackerたちの意見

エージェントオーケストレーションのフォームファクターに関する実験がたくさん見られてワクワクするね！最初に思いつくのは、コスト管理についてどう考えてるのかってこと。巨大なコンテキストウィンドウにたくさん入れるのは高くつくけど、ちょっと小さいコンテキストウィンドウで10個のエージェントを無意識に展開するのはもっと高くつくよね。答えは「じゃあ、そんなことしないで」ってことかもしれないけど、それはUNIXのアナロジーに当てはまるよね。強力で時には破壊的なツールが与えられて、自分でワークフローを慎重に構築する必要がある。だけど、Axeを使うときの予算についてはどうアプローチするのか、ちょっと気になるな。
└
> Axeを使うときの予算についてどうアプローチするのか いい質問だね！まだ深く考えてないけど、コストを抑えるためにトークンでLLMを制限する方法を追加するのは全然問題ないと思うよ。
すごい作業だね！でも、12MBは...大きいな...。参考までに、ZigでLLM API呼び出しを含むHTTPスタック全体は、リリース時にバイナリが約400KBになるよ。別の500KB（それ以下でも！）で、言語、コンパイラ、VMを全部実装できる。12MBはここでは特に印象的なバッジじゃないと思うな。
└
これはGolangで書かれてるよ。12MBじゃ「Hello World」すらやっとって感じだね、だって全部静的にリンクされてるから。そう考えると、サイズはすごいね。
└
12MBは大きくないよ。YouTubeを3分見るのと同じくらいだし。実際のRAM消費はバイナリサイズとはほとんど相関がないから、そこが重要なんだよね。
これがナノボットにやらせようとしてたことなんだ、シェアしてくれてありがとう！ファイルシステムみたいなワークフロー定義に使うつもりだよ。RPGキャラを作るための既知のワークフローがあって、そのステップについての好みを次々とLLMに読ませて、各ステップに特有のデータを適用して、結果を次のサブディレクトリに出力することで、全体のプロセスをpub/subできるようにして、中間ファイルを編集して結果を調整できるようにしたいんだ。これ、めっちゃクールだね！
└
聞けて嬉しいよ！チェックしてくれてありがとう。改善案があったら、GitHubにイシューを立てて気軽に教えてね。
└
ナノボットのアプローチがうまくいってないのはどこですか？
こういう感じでうまくいったことがあるけど、もう少し生の感じかな：- claudeは-pオプションを取る - 小さなスクリプトがたくさんあって、それぞれがエージェントだけど、ほんの小さなタスクしかやらない - スクリプトはUNIXパイプラインで組み合わせられる 例えば：$ git diff --staged | ai-commit-msg | git commit -F - ここでai-commit-msgは小さなエージェント： #!/usr/bin/env bash # ai-commit-msg: stdin=git diff, stdout=従来のコミットメッセージ # 使用法: git diff --staged | ai-commit-msg set -euo pipefail source "${AGENTS_DIR:-$HOME/.agents}/lib/agent-lib.sh" SYSTEM=$(load_skills \ core/unix-output.md \ core/be-concise.md \ domain/git.md \ output/plain-text.md) SYSTEM+=$'\n\nTask: stdinのgit diffを与えられたら、1行の従来のコミットメッセージを出力する。' run_agent "$SYSTEM" そして、エージェント自体を小さく保つために、さまざまなスキルを読み込むための小さなライブラリに依存していて、オプションでガードや実行後のバリデーターを適用することができる。これらのバリデーターは、特定のディレクトリの外で書き込みがないことを確認するための単純なgrepなどが多いけど、時には出力の正確性を強制するためのものもある（今までの例では常にjqを使ってるけど）。理論的には、ガードは別のclaude -p呼び出しにすることもできるけど、意味的な指示が必要な場合はね。
└
似たようなことを考えてたんだけど、あなたの agent-lib.sh はどんな感じ？
└
そのコミットメッセージの例ってありますか？AIが良いコミットメッセージを書くのはまだ見たことがないんですよね。少なくとも、良いコミットメッセージと比べると、"wip" や "fix stuff" よりマシなだけじゃ、あんまりハードル高くないし。
私の悩みは、エージェントのシステムに対するメンタルモデルが時間とともに現実とずれていくことなんです。それについて何度も話し合って、覚えておいてくれって頼んでも、だんだんイライラしてきます。READMEにはエージェントの記憶は実行間で持続すると書いてありますが、それでその問題は解決しますか？それに、エージェントの構造を何度かリファクタリングしたら、そのうちの一つが重複する機能を作り出していたことがわかりました。例えば、DB接続プールが同時に4つもあったり。AXEはチェーンされたエージェント間で共有状態を必要としますか？必要ならそれができるんでしょうか？
HNがボットであふれているのか、今の人たちがシンプルさを欠いているのか、ちょっとわからないですね。面白いことをしたい人は、「持続的な記憶」とか言ってるプロジェクトは即座に無視すべきだと思います。スコープの拡大や複雑さの隠蔽を示唆してますから。ツールが「持続的な記憶」を含めたいなら、どうやってそのスクラッチやノートファイルが流れて、何を達成するのかを3文で説明する必要があります。ただ「持続的な記憶」と主張するだけじゃダメです。あえて言うなら、「メモリ」という用語を使っているプロジェクトは、機能しない抽象のために時間とトークンを無駄にする運命にあると思います。
└
>スキャフォールディング スキャフォールディングの目的は持続的な記憶を作ることです。 >「持続的な記憶」と主張する それをビルド製品として見てください。 >機能しない抽象 これをテストの問題として考えてみてください。
LLMを呼び出すアイデアは、オートメーションに優しいCLIツールとしていいですね！でも、すべてのエージェントを ~/.config に入れるのはちょっと反対です。私のBashスクリプトもそこにはなくて、別のスクリプトコレクションか、使う場所（例えばリポジトリ）に置いています。例えば、コミットメッセージ生成をリポジトリに追加したいとします（LLMの使い方としてはあまり良くないと思いますが、実用的な例です）。/.git に適切なフックを追加しますが、エージェントとその指示もリポジトリ内に置きたいです（たぶん `axe` や `agents` ディレクトリに）。Axeは現在のフォルダからエージェントを読み込めますか？それが追加できるんでしょうか？
LLMエージェントをUnixプログラムのように扱うアプローチ、いいですね。エージェントごとのTOML設定もスッキリしてます。請求書処理のために似たようなことに取り組んでいるんですが、小さくて集中したエージェントが一つのことをうまくやる感じです。上流のLLMプロバイダーがパイプラインの途中で断続的に失敗したとき、リトライはどう処理していますか？
これらのことがどう機能するのか正確にはわからないけど、DequeのAxeツールで著作権や商標の問題にぶつかるかもしれないよね。: https://www.deque.com/axe/devtools/
なるほど、面白いね。ガードレールやエージェントが暴走したり、意図しないことをしたりするのはどう対処してるの？