全操作をログに残すAIエージェント「Apache Maka」の仕組み

AI エージェントに実装やリファクタリングを任せたとき、失敗の原因を後から特定できずに困ったことはないでしょうか。どのツールをどの順で呼び、どこで権限を許可し、どのモデル出力を根拠に次の手を打ったのか。その連鎖が残っていなければ、失敗の再現も、成功の再利用もできません。

この不透明さは、ツールごとに履歴の持ち方が違うことから生まれます。画面に表示されている会話と、モデルへ送られたコンテキストが一致しているとは限りません。コンテキスト圧縮が走れば過去のやり取りは静かに削られ、クラッシュすれば途中の状態は失われます。結果として「エージェントが何をしたか」はツールの UI が見せてくれる範囲でしか分からず、監査にも検証にも耐えません。

この問題に対して「実行の記録そのものをランタイムの中心に据える」という設計で応えているのが、Apache Software Foundation（ASF）のインキュベーションプロジェクトである Apache Maka (Incubating) です。モデルメッセージ・ツール呼び出し・ツール結果・権限判断・終了イベントを追記専用（append-only）のログに書き、UI もコンテキストも復旧処理も、すべてそのログの射影（projection）として扱います。

本記事では、Apache Maka の設計思想、Runtime Host を中心としたアーキテクチャ、ローカルデータの取り扱い、入手方法と動作要件、リポジトリに同梱された公開ベンチマークの読み方、OpenCode・Cline・goose といった類似 OSS との違い、そしてインキュベーション中というステータスを採用判断でどう扱うべきかを整理します。

なお本記事の記述は、公式サイト・GitHub リポジトリの README / ARCHITECTURE.md / 同梱ドキュメント、および Apache Incubator のステータスページに基づくものです。インストールや実行による動作検証は行っておらず、すべて公開ドキュメントの内容を整理したものである点をあらかじめお断りしておきます。

Apache Makaとは｜全操作を記録するAIエージェントワークスペース

Apache Maka は、公式リポジトリの説明文で「a high-performance agent workspace that keeps a complete record of everything it did」（実行したすべてを完全な記録として保持する高性能なエージェントワークスペース）と自己定義されている OSS です。Apache Incubator のステータスページでは「local-first AI agent runtime and workspace」と表現され、モデルメッセージ・ツール呼び出し・ツール結果・権限判断・終了イベントを追記専用ログに記録すると説明されています（Apache Maka Incubation Status）。

リポジトリの基本情報

まず、採用可否を判断する際の一次材料となるメタ情報を整理します。以下は GitHub API から取得した apache/maka の値です。

（出典: gh api /repos/apache/maka 取得値、2026年9月15日時点）

メンテナンス状況の観点では、archived=false / fork=false / disabled=false であり、他リポジトリのフォークでもアーカイブ済みでもない本流のプロジェクトとして稼働しています。最終 push も取得日当日であり、更新は活発です。ライセンスは ASF プロジェクトらしく Apache-2.0 で明示されています。

一方で、ASF のインキュベーションに入ったのは 2026年8月13日と日が浅く、正式リリースはまだ存在しません。この点は採用判断に直結するため、「採用判断のチェックポイント」の項であらためて整理します。

「agent harness」としての立ち位置

Apache Maka は自らを agent harness（エージェントを動かすための外枠）と位置づけ、README の「What Maka is」節で「An agent harness exists to finish tasks. We hold it to one measure: how many it completes and at what cost.」（エージェントハーネスはタスクを完了させるために存在する。我々はそれを一つの尺度で評価する。いくつ完了したか、そしていくらかかったか）と述べています。

この「完了数とコストで測る」という宣言は、後述する公開ベンチマークの同梱という実装に直結しています。機能の多さやモデルの新しさではなく、測定可能な成果で評価される前提に立っているという点が、プロジェクトの性格をよく表しています。

「ログがランタイム」というAIエージェント設計の考え方

Apache Maka を他のエージェントと分ける最大の特徴が「The log is the runtime」という原則です。設計の詳細は ARCHITECTURE.md に記載されています。

RuntimeEvent に何が記録されるか

Apache Maka では、エージェントの実行中に発生する以下の事実がすべて追記専用の RuntimeEvent として書き込まれます。

• モデルが生成したメッセージ
• ツールの呼び出し
• ツールの実行結果
• 権限の判断（何を許可し、何を拒否したか）
• 終了イベント

重要なのは、この Runtime Event Log が「記録のコピー」ではなく canonical source（正典となる出所）として定義されている点です。エージェントが何をしたかという事実は、この一本のログにのみ存在します。

UI・コンテキスト・復旧が「ログの射影」であることの意味

ARCHITECTURE.md では、UI に表示される会話・次にモデルへ渡すプロンプト・クラッシュからの復旧処理を、いずれもこのログから導出される projection（射影）として扱うと説明されています。つまり、画面表示もモデル入力も復旧状態も、独立した状態を持たず、同じログから計算されるということです。

この構造が実務にもたらす効果は 2 つあります。

1 つは監査可能性です。「UI にはこう見えていたが、モデルへ渡っていたのは別物だった」という食い違いが、原理的に発生しにくくなります。表示と入力が同じ出所から作られるためです。

もう 1 つは再現性です。失敗したセッションについて、どのツール呼び出しがどの結果を返し、どの権限判断を経て次の手に進んだのかをログから辿れます。エージェントの挙動を「たまたまそうなった」で終わらせず、原因を特定できる形にするための土台になります。

記録が残ることと、モデルに渡す文脈を削ることの分離

長時間のエージェント実行では、コンテキストウィンドウの制約からどこかで文脈の剪定や圧縮（compaction）が必要になります。多くのツールではこの圧縮によって過去のやり取りが実質的に失われ、後から追えなくなります。

Apache Maka はこの 2 つを明確に分離しています。ARCHITECTURE.md は、コンテキストの剪定や compaction が変えるのは「プロバイダへの入力という projection」であって履歴そのものではない、と述べています。README でも、古いツール出力は「ログから消えるのではなく、次のプロンプトから外れる」ことがあると説明されています。

つまり、モデルに渡す情報を軽くすることと、実行事実を残すことが両立します。設計解説は docs/blogs/log-is-the-runtime.md としてリポジトリのドキュメントにも同梱されており、興味があれば原典を確認できます。

Runtime Hostを単一の実行権威に置くアーキテクチャ

「ログがランタイム」という原則を実装で支えているのが、Runtime Host を単一の実行権威として置く構造です。

実行経路とコンポーネントの責務

ARCHITECTURE.md はバックボーンを次の流れで示しています。

Desktop / TUI / CLI / Bot → Runtime Host → SessionManager → AgentRun + RuntimeKernel → Tool Runtime / Runtime Event Log → Context / Session / UI / Recovery projections

各レイヤの責務は以下のように定義されています。

• Runtime Event Log: モデルメッセージ・ツール呼び出し・結果・終了事実の canonical source
• SessionManager / AgentRun: 実行のライフサイクル管理
• Runtime Host: クライアントの受け入れ（admission）、クライアント能力の判定、公開プロトコルの所有
• Agent Graph: 子 Session を使って依存関係のある作業をスケジュールします。その起動も同じ Runtime を通ります
• Storage: 対話 Runtime の状態のみを保持し、評価（Eval）専用のルートや実験結果の権威は持ちません

注目すべきは「Each State Root has its own Runtime Host as execution and write authority.」という記述です。State Root ごとに Runtime Host が実行と書き込みの唯一の権威を持ち、同一の state に対して 2 つ目の Runtime を作らない設計になっています。

この制約により、Desktop（Electron アプリ）・TUI・CLI・Bot といった複数の入口が、それぞれ独立した状態を持つのではなく、同じ実行系の薄いクライアントとして振る舞います。GUI で始めた作業を CLI から確認する、といった運用が状態の食い違いなく成立する根拠がここにあります。

リポジトリは apps/desktop/（Electron + React）、packages/core/（Session・Event・Permission・Connection の契約）、packages/storage/（SQLite の状態・設定・ペイロード）、packages/runtime/（AgentRun・モデルアダプタ・ツール・コンテキスト・リカバリ）、packages/runtime-host/（Runtime Host のライフサイクルとプロトコル）、packages/cli/（TUI と非対話 CLI）などに分割されており、コード境界は ARCHITECTURE.md に表として定義されています。

Evalを Runtime から切り離す境界

Apache Maka は評価基盤を packages/eval/ として内製しており、その境界も明示されています。

• Experiment = benchmark + executor + subjects + tasks + repetitions
• Cell = task × repetition × subject

そして、同じセルに複数の attempt（試行）が存在する場合は最初の有効な attempt が権威である、と定義されています。運用者が後から良い結果を選び直すことができない仕組みです。ベンチマーク結果を自ら公開するプロジェクトとして、数値の選択的な提示を設計で封じている点は、評価の読み方を考えるうえで押さえておく価値があります。

Storage 層が Eval 専用のルートや実験結果の権威を持たないという境界も同じ文脈にあります。対話 Runtime と評価基盤を混ぜないことで、評価結果が対話の状態に影響されない構造になっています。

ローカルファースト運用で確認すべきデータの置き場所と権限

Apache Maka は「Your machine, your model.」を原則の 1 つに掲げ、セッション・設定・実行記録をローカルに留め、モデルはユーザーが持ち込む（クラウド API・ローカルモデル・互換ゲートウェイのいずれでも可）方針を取っています。README には「Maka does not bundle a shared model account.」と明記されており、共有のモデルアカウントは同梱されません。

業務環境に入れる前に確認しておくべき点を、README の「Local data and recovery」節の記述から整理します。

データの保存場所: 既定では <Electron userData>/workspaces/default/ 配下に、runtime.sqlite（ライブの記録）、connection-catalog.json、credential-vault.json、settings.json、artifacts/ が置かれます。

資格情報は平文ファイル: API キー等のシークレットは credential-vault.json にローカルの平文ファイルとして保存されます。OS アカウントのみが読める状態であり、renderer プロセスからは見えないと説明されていますが、ディスク上は平文です。共有マシンやバックアップ対象に含まれるディレクトリで運用する場合は、この点を前提に扱う必要があります。

ツール実行とサンドボックス境界: ファイル書き込みやシェル実行を伴うツールは、sandbox boundary を越える必要があると明記されています。エージェントに何をどこまで許可するかは、この境界の設定を通じて管理することになります。

アップグレード時の非互換: runtime.sqlite がライブの記録であり、旧来の JSONL トランスクリプトや Electron の safeStorage に保存されていた資格情報はインポートされません。アップグレード後にスレッドが空に見えることがあり、資格情報の再入力が必要になる場合があります。

中断ターンの再開は既定オフ: 中断したターンの再開は既定で無効です。環境変数 MAKA_RUNTIME_SAFE_BOUNDARY_RESUME=1 を設定した場合にのみ、Desktop の Safe resume、CLI の /resume、起動時の自動再開が有効になります。これらはモデルを呼び出すためトークンを消費する点も README に明記されています。意図しないコスト発生を避けるための既定値であり、有効化する際はコストへの影響を織り込んでおく必要があります。

これらの詳細は SECURITY.md や docs/workspace-privacy-context.md、docs/architecture/runtime-resume-architecture.md で補足されています。

Apache Makaの導入方法と動作要件（nightly CLIとソースビルド）

ここが初見のエンジニアにとって最も迷いやすいところです。配布形態が 3 種類あり、それぞれ位置づけが異なります。

3つの配布形態と、それぞれの位置づけ

配布物の一覧は公式ダウンロードページで確認できます。「まず触ってみる」段階であれば Desktop Nightly かソースビルド、「本番導入の検証」であれば正式リリースを待つ、という切り分けになります。

ソースから起動する手順

ソースビルドの要件は README の「Requirements」節に記載されています。

• Node.js 22.19 以降（CI は Node.js 24）
• npm（lockfile と scripts が npm 前提。packageManager は npm 11）
• Git
• ripgrep（Runtime の Grep ツールが使用）
• Direct Peer / Peer Mesh の開発には追加で Rust stable 1.98 以降とプラットフォームのリンカ

起動手順は README に以下のように示されています。

git clone https://github.com/apache/maka.git
cd maka
npm ci
npm run dev

（出典: apache/maka README）

初回起動時は Settings → Models を開き、API 接続・ローカルモデル・対応アカウントのいずれかを追加してテストし、既定モデルを選んだうえでワークスペースに戻ってタスクを開始する、という流れが案内されています。

ターミナルからの実行については、README の「Terminal entry points」節に以下の例が示されています。

npm run cli:dev
npm run cli:dev -- run "Summarize this repository and identify its most important risk"
npm run cli:dev -- run --graph "Implement two independent slices, integrate them, then review the result"
npm run cli:dev -- --help

（出典: apache/maka README）

--graph を指定した非対話実行は、durable な Graph の完了を待ってから supervisor の最終出力を表示します。TUI 側では /graph on /graph off /graph <task> を受け付けます。なお Graph の implementation operator は隔離された Git worktree を使うため、ソースプロジェクトが clean な Git worktree である必要がある点は事前に確認しておくべき制約です。

CLI パッケージと dist-tag の注意点

CLI を単体で入れる場合、npm パッケージ名は maka-agent、公開されるコマンドは maka です。CLI の README には以下のインストール例が示されています。

npm install --global maka-agent@nightly
maka --version
maka --help

（出典: apache/maka packages/cli/README.md）

ここで見落とすと詰まるのが dist-tag の非互換です。CLI README によれば、nightly タグが完全な CLI であるのに対し、latest タグは 0.0.0-alpha.0 の早期アルファであり doctor / help / version しか持ちません。npm update --global maka-agent を素で実行すると latest 側に切り替わる恐れがあるため非推奨と明記されています。バージョン管理の自動更新設定に組み込む場合は、タグの指定を固定しておく必要があります。

CLI 側の要件は Node.js 22.19.0 以降、TUI には対話入力が可能な端末、エージェントターンにはモデル接続です。初回セットアップは API キー方式のプロバイダに対応しています。また CLI README には、npm 上の無関係な maka パッケージは本プロジェクトではないという注意書きもあります。

リリースゲートの検証マトリクスでは、Linux x64（Node 22.19 / 24）・Linux arm64（24）・macOS arm64（24）・Windows x64（24）で TUI / CLI / Runtime Host が Validated とされています。ただし Real Harbor / Pier Eval が Validated なのは Linux x64 / Node 24 のみです。評価基盤まで含めて完全に動かしたい場合は、この組み合わせが基準になります。

公開ベンチマーク（Terminal-Bench 2.1）の読み方

Apache Maka は「Measured, not claimed.（主張ではなく測定する）」を原則に掲げ、同一モデル・公式 verifier で他ハーネスと比較した結果を、per-task の CSV ごと docs/eval/ にリポジトリ同梱で公開しています。

代表的なのが nine-arm レポート（terminal-bench-2.1-deepseek-v4-flash-nine-arm.md）です。条件は以下のとおりです。

• ベンチマーク: Terminal-Bench 2.1（revision d49e28f1e4ddd13d289e85a5f312a66750951932）、全 89 タスク
• モデル: deepseek-v4-flash、reasoning effort は max
• 指標: 公式 verifier による end-to-end の pass@1

結果は以下のように示されています。

（出典: apache/maka docs/eval の nine-arm レポート）

レポートでは、9 ハーネスすべてが通過したタスクが 28 件、すべて失敗したタスクが 5 件（extract-moves-from-video / filter-js-from-html / gcode-to-text / make-doom-for-mips / torch-pipeline-parallelism）、残り 56 件が mixed だったことも示されています。pass あたりコストは Pi の $0.019739 が最安で、DSH の $0.026230 と Maka の $0.026307 がほぼ同値です。

ここで読み方として押さえておきたい留保が 2 点あります。

1 つは、レポート自身が付けている留保です。DSH は同一コホートでの実行ではなく後から同条件で走らせたものであるため、「The nine-way ranking is therefore descriptive rather than a paired causal comparison.」（この 9 者ランキングは記述的なものであり、ペア比較による因果的な比較ではない）と明記されています。順位表を因果的な優劣として読むべきではない、とレポート自身が述べているわけです。

もう 1 つは、これらがすべて Apache Maka 側による自己公表データであるという点です。公式サイトでは maka-vs-opencode の別条件の比較として 68.5% 対 55.1%（+13.5pp、McNemar 検定）という結果も提示されていますが、いずれも第三者による独立検証ではありません。

とはいえ、条件（ベンチマークの revision・モデル・reasoning effort・タスク数・指標）が明示され、per-task の CSV まで同梱されている点は、宣伝文句だけのアピールとは性質が異なります。「数値そのものを信じる」のではなく、「検証可能な形で公開されているかどうか」を評価軸として読むのが妥当なところです。

OpenCode・Cline・gooseとの違い（類似OSSの比較）

AI コーディングエージェントの OSS はすでに複数の選択肢があります。Apache Maka を検討する際に比較対象となる代表的なプロジェクトを並べます。

比較表

（出典: gh api /repos/{owner}/{name} 取得値、2026年9月15日時点）

4つの差分軸

ガバナンス: Apache Maka のみが ASF のインキュベーション配下にあり、商標やライセンスの手続きが ASF のプロセスに乗ります。ベンダー中立性を重視する組織にとっては評価点ですが、後述するとおり software grant が未完了であるという裏返しの制約もあります。OpenCode・Cline・goose はいずれも企業ないしコミュニティ主導です。

提供形態: Apache Maka は Desktop（Electron）・TUI / CLI・Eval を単一の Runtime Host の薄いクライアントとして束ねます。OpenCode はターミナル中心、Cline は IDE 拡張 / SDK / CLI として既存の開発環境に組み込む形、goose は Desktop + CLI で MCP 拡張による機能追加が中心です。「GUI と CLI を同じ実行系で運用したい」という要件があるなら、Apache Maka の構造は素直に合います。

状態管理の思想: これが最も差が出る軸です。追記専用ログを唯一の正とし、UI・コンテキスト・復旧をその射影として扱う設計は、比較対象の 3 プロジェクトには見られません。実行の追跡可能性を要件として掲げるなら、この差は機能一覧の比較よりも重い判断材料になります。

評価基盤の内製: Apache Maka は packages/eval として Experiment / Cell / Attempt のモデルを持ち、比較レポートと per-task CSV をリポジトリに同梱しています。公開ドキュメントで確認できる範囲では、他 3 プロジェクトは同等の評価基盤をリポジトリに常設していません。

そして無視できないのが成熟度の差です。スター数で見れば OpenCode が Apache Maka の約 38 倍、Cline が約 12 倍、goose が約 10 倍です。エコシステムの厚みや事例の蓄積という点では、Apache Maka は明確に後発の立場にあります。

受託開発の文脈で OSS の AI コーディングエージェントを比較検討する場合の評価軸については、OSS AIコーディングエージェントは受託で使えるかも併せて参考にしてください。

採用判断のチェックポイント｜インキュベーション中であることの意味

Apache Maka は 2026年8月13日に Apache Incubator に入ったプロジェクトです。Champion は Zili Chen（tison）氏、Mentors には Hao Ding（xuanwo）氏、Huajie Wang（benjobs）氏、Zhuoran Shang（psiace）氏、Xinyu Tan（tanxinyu）氏が名を連ねています（Apache Maka Incubation Status）。

「ASF のプロジェクトだから安心」と読むのは早計です。インキュベーション中であることの実務的な意味を、公式の記述から確認します。

Apache リリースがまだ存在しない: README の Apache Releases 節には「Maka has not made an Apache release yet.」と明記されています。将来的には署名済みソースアーカイブが正式リリースとなり、それ以外の場所で配布されるパッケージは convenience artifacts の扱いになります。

software grant と committer ICLA が未完了: リポジトリの DISCLAIMER-WIP には「The software grant and committer ICLAs are not yet complete.」と記載されています。さらに「releases may have incomplete or un-reviewed licensing conditions」（リリースには不完全またはレビュー未了のライセンス条件が含まれる可能性がある）とし、この成果物を取り込む場合は「you will need to conduct a thorough licensing review to determine the overall implications of including this work」（含めることの全体的な影響を判断するため、徹底的なライセンスレビューを各自で実施する必要がある）と案内しています。自社製品やクライアント納品物に組み込む検討をしている場合、この一文は無視できません。

nightly は仕様が動く: nightly ビルドはデータ形式や CLI コマンドが変わりうる前提の成果物です。前述のとおり旧 JSONL トランスクリプトや safeStorage の資格情報は引き継がれず、アップグレードで再設定が必要になる場合があります。

Windows / Linux ビルドは未署名プレビュー: 配布バイナリの署名状況は、社内の配布ポリシーによっては導入の可否を直接左右します。

Eval の完全検証は Linux x64 / Node 24 に限られる: 評価基盤まで含めて使うなら、動作が保証された環境は限定的です。

以上を踏まえると、判断の切り分けは次のようになります。

• 技術検証の段階: 進められます。ドキュメントは整備されており、ソースビルドと nightly の両方から着手できます
• チーム内の日常利用: 慎重な判断が必要です。データ形式の変更とアップグレード時の非互換を許容できるかが分かれ目になります
• 製品への組み込み・クライアント納品: 現時点では時期尚早です。少なくとも software grant の完了と正式リリースを待ち、ライセンスレビューを経てから判断することをおすすめします

まとめ｜Apache Makaが向いているチーム

Apache Maka は、「エージェントが何をしたか」を追記専用ログという単一の出所に集約し、UI もコンテキストも復旧もその射影として扱うという一貫した設計を持つ OSS です。この設計は、実行の監査可能性と再現性を要件として掲げるチームにとって、機能の多寡とは別次元の価値を持ちます。

向いているのは次のようなチームです。実行の追跡可能性を最優先し、失敗の原因を後から説明できる状態を必要とするチーム。GUI と CLI を同じ実行系で運用したいチーム。そして、特定ベンダーに依存しないガバナンスを重視し、ASF プロセスの下で育つプロジェクトに関与する余地を評価するチームです。

逆に、今日から本番運用の安定性を求めるチームには時期尚早です。正式リリースが未了で software grant も完了していない以上、組み込みにはライセンスレビューという追加コストが伴います。エコシステムの厚みや実績の蓄積を重視するのであれば、スター数で 10 倍以上の差がある既存プロジェクトの方が現実的な選択肢になります。

判断を進めるうえでの次の一歩としては、Apache Maka 公式サイトでプロジェクトの位置づけを確認し、設計思想に関心があれば ARCHITECTURE.md を、評価の妥当性を確かめたければ docs/eval の per-task CSV を、導入条件を詰めたければダウンロードページと CLI README を参照する、という順路が取れます。自チームが「実行記録の一次情報化」にどれだけの価値を置くかを起点に、成熟度とのトレードオフを検討してみてください。

関連情報

AI エージェントの開発フローへの導入や、実行記録・権限設計を含む開発基盤の整備をご検討中の方は、お問い合わせフォーム からご相談ください。要件の整理段階からご相談いただけます。