Apache Maka：追記専用イベントログをランタイムとする監査可能なエージェントワークスペース

Apache Maka（Incubating）は、エージェントが行ったすべての作業の完全な記録を残すことを約束する、高性能なエージェントワークスペースです。

単なるチャット画面ではなく、エージェントのランタイムと薄いクライアントで構成された設計です。本稿はプロジェクトの README と公開情報に基づき、アーキテクチャ、動作の仕組み、導入時の観点、制約を整理します。

解決しようとする課題

エージェントハーネスの存在理由はタスクを完了することです。評価軸は二つだけで、どれだけ完了したか、いくらかかったかです。Maka はこの二つを公開します。

同じモデルと同じ公式検証器（verifier）で他のハーネスと比較し、タスクごとの結果を各レポートとともにリポジトリの docs/eval に載せる、とプロジェクトは述べています。「当方が優れている」ではなく「各タスクの結果を自分で確認してほしい」という姿勢です。多くのプロジェクトは集計スコアしか出さないため、これは珍しい方針です。

中核設計：ログがランタイムである

最も重要な設計は「ログがランタイム」という考え方です。モデルのメッセージ、ツール呼び出し、権限の判断、終了は、すべて追記専用の RuntimeEvent として書き込まれます。画面表示、次のプロンプト、クラッシュ復旧は、このログの射影（projection）にすぎず、唯一の正本ではありません。

これはイベントソーシングの考え方に近く、利点が三つあります。第一に、状態をログから再生できるため、クラッシュ復旧が単純になります。第二に、画面とプロンプト生成がそれぞれ別の状態を持たないので、食い違いが起きにくくなります。第三に、エージェントにとって特に有用な点として、古いツール出力を次のプロンプトから外しても、ログからは消えません。長いタスクではツール出力がコンテキストウィンドウを埋めがちです。Maka はそれをプロンプトから削ってトークンを節約しつつ、監査用の完全な記録を保持できます。コンテキスト管理と監査可能性という、本来は衝突しやすい二つの要求を、別の層に分けて満たしています。

単一の Runtime Host

Maka には Runtime Host が一つだけあり、実行に関する唯一の権限を持ちます。デスクトップアプリ、TUI と CLI、Eval は、いずれもこのホストの薄いクライアントです。

Eval が持つのは実験とそのスコアだけです。この分離により、デスクトップで見る挙動と、ベンチマークで測った挙動が同じ実行経路から生まれます。評価用に別のコードパスがないため、「測ったもの」と「出荷するもの」のずれが入り込みにくくなります。

ローカル優先とモデル持ち込み

セッション、設定、実行記録はすべて手元のマシンに残ります。Maka は共有のモデルアカウントを同梱しません。初回起動時に「設定 → モデル」を開き、API、ローカルモデル、または対応するアカウント接続を追加し、テストして既定のモデルを選びます。

接続の状態は「設定済み」「送信可能」「実験的」の三つに区別されます。ランタイムに接続されていないアカウントのフローは、使えるモデルとして表示されません。互換性を誇張しない、堅実な選択です。モデルはクラウド API、ローカルモデル、互換ゲートウェイのいずれでもよいため、機密性の高いコードを扱うチームはローカルモデルに接続し、コードも記録も社内に留められます。

ビルドと使い方

ソースからのビルドには、Node.js 22.19 以上（CI は Node.js 24）、npm、Git、そしてランタイムの Grep ツールが使う ripgrep が必要です。npm ci の後に npm run dev を実行すると、ホットリロード付きのデスクトップ開発環境が起動します。ターミナルでは npm run cli:dev で TUI が開き、npm run cli:dev -- run で一回のターンを実行できます。

グラフ型のタスク向けに --graph オプションもあります。Direct Peer と Peer Mesh には Rust の安定版 1.98 以上とプラットフォームのリンカーが必要で、専用の dev:peer コマンドがあります。対応プラットフォームは macOS が中心で、Windows と Linux はプレビュー扱いです。

プロジェクトの現状とエコシステム上の意味

Maka は Apache Software Foundation のインキュベーティングプロジェクトです。最新の Apache リリースは 0.2.0（incubating）で、署名付きのソースアーカイブが公式リリースです。

他の場所で配布されるパッケージは利便性のための成果物であり、開発ビルドは承認された Apache リリースではありません。Apache 2.0 ライセンスと財団のガバナンスは企業導入の追い風になります。ライセンスが明確で、コミュニティの運営手順が文書化されているためです。

制約とリスク

第一に、README の抜粋には具体的なベンチマークスコアやコストの数値がありません。タスクごとの結果は docs/eval で確認する必要があり、本稿は確認できていない数値を引用していません。第二に、プロジェクトはインキュベーション中で、バージョンは 0.2.0、三つのうち二つのプラットフォームはプレビューです。

本番導入には検証期間が要ります。第三に、追記専用の完全なログはディスク使用量とプライバシーの問題を伴います。ログにはモデルのメッセージやツール出力が残り、秘密情報や非公開コードが含まれうるため、保持期間やマスキングの方針を各チームで決める必要があります。第四に、高性能という主張は自分のタスクで再現して確かめるべきで、公開ベンチマークは自社の作業負荷と同じではありません。

今後の方向

監査可能なエージェントは、今後ますます重要になります。エージェントがファイルを編集し、コマンドを実行できる以上、権限の判断と各ステップの因果の連鎖はたどれなければなりません。

Maka はこの連鎖を後付けのログ機能ではなく、ランタイムの第一級の要素として扱っています。ここがこのプロジェクトの最も注目すべき点です。評価の公開という姿勢がリリースを重ねても保たれれば、エージェントハーネス同士の比較がより透明になる流れも期待できます。