Apache Maka（Incubating）とは｜ログを権威にするローカルファーストAIエージェント基盤

Apache Maka（Incubating）は、実行記録を追記ログに残すローカルファーストの AI エージェント基盤です。apache/maka は実在し、Apache Software Foundation（ASF）の Incubator に 2026-08-13 に受け入れられたばかりのプロジェクトです。ただし「Apache 名義だから安心してそのまま使える」かというと、そこは分けて考える必要があります。この記事では公式リポジトリと実際の実行結果だけを使って、Maka が何をするものなのか、いま入れて動くのか、そして (incubating) という語が何を意味するのかを順に確かめます。

AI エージェントの実行基盤そのものを比較検討している段階なら、先にAIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証で全体の地図を掴んでから戻ってくると、Maka がどの空白を埋めようとしているのかが掴みやすくなります。

Apache Maka（Incubating）とは——ASF入り直後のAIエージェント基盤

Maka は「ローカルファーストのエージェント・ワークスペース」を名乗る OSS です。リポジトリの説明文はこう書かれています——モデルの発話、ツール呼び出し、ツール結果、権限判断、終了イベントを追記専用ログに記録する、と。つまり「賢く答える」ことよりも、エージェントが実際に何をしたかを事実として残すことに重心を置いた設計です。

まず、実在確認と現況を数字で押さえます。以下はすべて 2026-08-21 時点で GitHub API と ASF の公開データから取得した実測値です。

「Apache 傘下」がどこまで確かなのか

「Apache」を名乗るリポジトリは紛らわしいものが多いので、ここは複数の独立した一次ソースで裏を取りました。

・GitHub の組織 ID が 47359——これは ASF 本体の組織 ID で、似た名前の別組織ではない
・ASF の podling レジストリに登録済み——公開されている podling 一覧（375 件）に maka のエントリがあり、status: current、startdate: 2026-08-13、sponsor: Incubator と記録されている
・Incubator の公式ステータスページが存在する——incubator.apache.org/projects/maka.html が生きている
・リポジトリに DISCLAIMER-WIP がある——ASF の podling に義務づけられた免責文書が実際に置かれている

メンターは xuanwo、benjobs、psiace、tanxinyu、tison の 5 名で、champion（Incubator への持ち込み役）は tison です。提案書は ASF の cwiki 上の「Maka Proposal」に置かれています。ここまで揃っていれば、apache/maka が ASF の正式な podling であることは確定と見てよいでしょう。

旧リポジトリとの関係——フォークではなく「改名」

リリースノートや CLI の README には github.com/maka-agent/maka-agent という別のリポジトリ URL が残っています。これを見て「本家とフォークが並存しているのでは」と考えたくなりますが、実際に叩くと 301 リダイレクトで apache/maka に転送されます。GitHub API 側も 301 を返し、追跡すると full_name は apache/maka、fork: false、parent: null です。

つまり maka-agent/maka-agent は同一リポジトリの旧アドレスであって、別リポジトリでもフォークでもありません。ASF への寄贈にあわせて組織ごと移管・改名され、旧 URL はリダイレクトとして生き続けている、というのが実際の状態です。ドキュメント内のリンクが旧 URL のまま残っているのは、寄贈直後によくある取りこぼしです。

4つの入口——Desktop / TUI・CLI / Eval

Maka は単一のアプリではなく、同じ実行基盤に対する複数の入口として設計されています。README が挙げる 3 つの入口を整理すると次のようになります。

重要なのは、この 3 つが別々の実装を持つのではなく、すべて Runtime Host という単一の実行権威を経由するという点です。README の言い方では「One execution authority」。Eval は実験の意味論と結果だけを担当し、実行そのものは Runtime Host に委ねます。だから「Desktop で試したときと CLI で流したときで挙動が違う」という類の食い違いが原理的に起きにくい構造になっています。

「Log is the Runtime」——実行記録を権威に置く設計

Maka の設計思想でいちばん特徴的なのが、README が掲げる “Log is the Runtime” です。これは単なるロギング機能の話ではありません。「ログが実行時そのものである」と言い切っています。

画面も文脈も「射影」にすぎない

一般的なチャット型のエージェントでは、会話履歴という配列が事実上の本体で、画面はそれを描画したものです。履歴を削れば事実も消えます。Maka はここを逆にしています。

モデルの発話、ツール呼び出し、ツール結果、そして終了に関する事実は、すべて Runtime Event Log に入ります。そのうえで、セッション、UI、モデルに渡す文脈、そして障害からの復旧は、いずれもこのログに対する projection（射影） として組み立てられます。表示のために作った要約や、コンテキスト長を節約するために削った中間結果は、あくまで射影の側の都合であって、記録された事実そのものには手を触れません。

「文脈は履歴ではない」

この考え方をもっとも端的に表しているのが、README のもう一つの見出し “Context is not history” です。

エージェントを長く走らせると、ツールの実行結果が積み上がってコンテキスト長を圧迫します。多くの実装はここで古い履歴を捨てます。Maka は、ツール結果の刈り込み（Tool Result pruning）と LLM による圧縮（LLM Compaction）を、「次の推論が何を見るか」を変える操作と定義し、記録された証拠を消耗品として扱わない、と明言しています。

実務的な意味は分かりやすいです。「なぜエージェントはこの判断をしたのか」を後から追うとき、モデルに渡した縮約版ではなく、実際に起きたことの記録に当たれる。権限の許可・拒否がイベントとして残るので、「何を承認したか」も後追いできます。

実行系の骨格を図にすると次のようになります。

復旧はまだ道半ば

ただし、この「ログから復旧できる」という性質は、現時点では全面的には完成していません。README は自ら段階を切って説明しています。

・継続実行はオプトイン——中断したターンの再開（Desktop の Safe resume、CLI/TUI の /resume、起動時の自動再開）は環境変数 MAKA_RUNTIME_SAFE_BOUNDARY_RESUME=1 を立てたときだけ有効になる
・再開はトークンを消費しうる——README は「これらの経路は設定済みのモデルプロバイダを呼ぶ可能性があり、トークンを消費する」と明記しており、意図してその挙動を望むときだけ有効化せよと注意している
・Phase 3 は未実装——ツールの副作用が成功したのか失敗したのか判別できないケースの突合（reconciliation）はまだ実装されておらず、曖昧な結果は再試行されずに保留される

「落ちても勝手に賢く再開してくれる」わけではなく、「危険な再試行はしない代わりに、判断がつかないものは止めて置いておく」という保守的な作りです。エージェントに Bash を渡している以上、この方向の慎重さは妥当だと思います。

インストールと起動——npmの3分岐とNodeの起動ゲートを実測する

ここからが実務的な話です。冒頭の GIF で流したとおり、Maka の CLI は「入れて動かす」までに二段階の落とし穴があります。順に分解します。

検証環境は macOS（Apple Silicon）、npm 11.1.0、Node.js は v22.13.1 と v25.2.1 の 2 系統。すべて 2026-08-21 に実行した結果です。

第一の分岐：同じ「インストール」が3通りに割れる

まず現在公開されている dist-tag を確認します。

npm view maka-agent dist-tags
# => { next: '0.1.0-beta.1', latest: '0.0.0-alpha.0' }

latest が 0.0.0-alpha.0 を指しています。ここが起点です。この状態で 3 通りのインストールを試すと、結果が 3 通りに割れます。

バージョン指定なしの npm install maka-agent はこう落ちます。

npm error code ETARGET
npm error notarget No matching version found for maka-agent@*.

理由は semver の仕様です。バージョンを省いた指定は * として解決され、* は prerelease バージョンに一致しません。公開済みの 2 つがどちらも prerelease（0.0.0-alpha.0 と 0.1.0-beta.1）なので、一致する候補が無く ETARGET になります。

さらに厄介なのが 2 番目です。@latest は成功しますが、入ってくるのは実体ではありません。展開すると LICENSE、bin/maka.js、package.json、README.md の 4 ファイル・展開後 15.6KB・依存関係ゼロ。中身の bin/maka.js は 60 行ほどで、実装されているのは --help、--version、そして doctor（Node のバージョンと platform/arch を表示するだけ）の 3 つだけです。エージェントは動きません。そのスタブ自身の README も「npm install --global maka-agent@next で入れてください」と書いています。

なお、maka という名前の npm パッケージは無関係の別物です。2022 年に公開された liyinfeng25/maka-cli 由来の v0.0.3 が居座っているので、npm install maka と打っても Maka は入りません。パッケージ名は maka-agent です。

第二の分岐：Node のバージョンで起動が止まる

@next を入れたら動くかというと、まだです。ここに二段目のゲートがあります。

インストールしたパッケージの engines はこう宣言されています。

npm install maka-agent@next
# npm warn EBADENGINE Unsupported engine {
# npm warn EBADENGINE   package: '[email protected]',
# npm warn EBADENGINE   required: { node: '>=22.19.0' },
# npm warn EBADENGINE   current: { node: 'v22.13.1', npm: '11.1.0' }
# npm warn EBADENGINE }
#
# added 1 package, and audited 248 packages in 3s
# found 0 vulnerabilities

注目すべきは、警告は出るがインストールは成功することです。engines フィールドは npm の既定では強制ではなく助言にすぎません。終了コードは 0 で、248 パッケージが監査され、脆弱性 0 と報告されます。ここだけ見れば正常に見えます。

ところが、この状態でコマンドを叩くと落ちます。

$ maka --version        # Node v22.13.1
SyntaxError: The requested module 'node:zlib' does not provide
  an export named 'createZstdCompress'
    at ModuleJob._instantiate (node:internal/modules/esm/module_job:180:21)
Node.js v22.13.1
# exit 1

--version ですら落ちる点が実務上いちばん厄介です。多くの CLI は --version や --help を早期に処理して終わりますが、ここでは ESM の依存グラフが解決される段階で失敗するため、コマンドの振り分けに到達する前に死にます。しかも出るのは「Node のバージョンが足りません」という親切なメッセージではなく、内部モジュールの生の SyntaxError です。

原因は Node.js の API 追加時期です。@maka/storage が node:zlib から createZstdCompress を import していますが、この API が追加されたのは Node v22.15.0 と v23.8.0（Node 公式 API ドキュメントの “Added in” 表記。Stability は 1 - Experimental）。手元の 2 系統で存在を確認すると、v22.13.1 では undefined、v25.2.1 では function でした。宣言された最低要件 22.19.0 はこの追加時期より後なので、engines の指定自体は正しく、問題は「満たさないときの落ち方が不親切」という点に尽きます。

要件を満たす Node に切り替えると、素直に動きます。

$ maka --version        # Node v25.2.1
0.1.0-beta.1

$ maka --help
Usage: maka
Launches the Maka terminal UI in the current working directory.

Commands:
  maka              Start the TUI
  maka run ...      Run one non-interactive model turn
  maka activate ... Run one Cloud Session activation and emit JSONL
  maka -p ...       Alias for maka run
  maka eval ...     Run one declarative multi-arm experiment
  maka runtime-host serve [options]  Run a Runtime Host service

皮肉なことに、実体の入っていないスタブ（0.0.0-alpha.0）のほうには doctor という親切なバージョン判定コマンドが実装されていて、要件を満たさなければ「Maka Agent requires Node.js 22.19.0 or newer.」と明示して終了コード 1 を返します。実体側にその案内が無い、という状態です。

node --version                     # 22.19.0 以上か
npm view maka-agent dist-tags      # いま next / latest がどこを指しているか
npm ls maka-agent                  # 実際に入ったバージョン

なお、筆者が確認できたのは「要件を下回る v22.13.1 では落ちる」「v25.2.1 では動く」の 2 点です。宣言された最低要件ちょうど（22.19.0）での挙動は試していないので、そこは各自の環境で確認してください。

デスクトップ版の配布物

CLI とは別に、デスクトップアプリが GitHub Releases で配布されています。v0.1.11（2026-08-18 公開、375 の PR と 24 名の貢献者を含むと記載）の配布物を実測すると次のとおりです。

Windows 版について README は踏み込んだ注意を書いています。未署名のため SmartScreen が「発行元不明」と表示するが、ダウンロードした SHA-256 がリリースに併記されたチェックサムと一致しない限り、その警告を回避してはならない、と。実際に各アセットには .sha256 が併置されています。この手の「警告が出ても気にせず実行してください」で終わらせない書き方は好感が持てます。

また、Computer Use（PC 操作）については、スキル自体はアプリに同梱されるが実行系（executor）は当リリースから除外されている、と明記されています。同梱されている＝使える、ではない点に注意が必要です。

「(incubating)」が意味すること——DISCLAIMER-WIPの3項目を自分で確かめる

ここが、この記事でいちばん誤解されやすい部分だと思います。

DISCLAIMER と DISCLAIMER-WIP の違い

ASF の podling には免責文書の設置が義務づけられていますが、2 種類あります。無印の DISCLAIMER は「まだ ASF に完全には承認されていない」という一般的な断り書きだけを含みます。対して DISCLAIMER-WIP（Work In Progress）は、それに加えて現在認識している未解決の課題を列挙します。

Maka のリポジトリには DISCLAIMER は存在せず（404）、DISCLAIMER-WIP が置かれています。挙げられている課題は 3 つです。

・ソースファイルにまだ Apache のライセンスヘッダが付いていない
・NOTICE がまだ ASF の形式へ書き直されていない
・ソフトウェア寄贈（software grant）と、コミッタの ICLA がまだ完了していない

そして文書はこう続けます——これを自分の製品やプロジェクトに組み込む予定なら、全体的な影響を判断するために徹底したライセンス審査を行う必要がある、と。

1つ目を実際に数えてみる

自己申告をそのまま引くだけでは記事にする意味が薄いので、1 つ目の項目を実際に測りました。main の HEAD（コミット 57e08d8）を取得し、apps/ と packages/ 配下の TypeScript ソースを対象に、Apache ライセンスヘッダの有無を数えます。

# .ts / .tsx の総数（node_modules と dist は除外）
find apps packages -type f \( -name '*.ts' -o -name '*.tsx' \) \
  ! -path '*/node_modules/*' ! -path '*/dist/*' | wc -l
# => 2234

# うち Apache ライセンスヘッダを持つファイル数
find apps packages -type f \( -name '*.ts' -o -name '*.tsx' \) \
  ! -path '*/node_modules/*' ! -path '*/dist/*' -print0 \
  | xargs -0 grep -l -i "Licensed to the Apache Software Foundation\|SPDX-License-Identifier: Apache-2.0" \
  | wc -l
# => 0

2,234 ファイル中 0 件、つまり 0.00% でした。対照として「Apache」という語をファイル内のどこかに含むものを数えても 2 件しかありません。DISCLAIMER-WIP の申告は正確だった、ということになります。

ここで強調しておきたいのは、これは欠陥の告発ではないという点です。ASF 受入（2026-08-13）から間もない時期で、ヘッダ付与・NOTICE 改稿・ICLA 回収はまさにこれから Incubator の中で片付けていく作業です。DISCLAIMER-WIP はそのために存在する仕組みで、宿題が終われば無印の DISCLAIMER に差し替わります。読者にとって意味があるのは「いま自分が採用判断をするなら、どの段階にいるプロジェクトを見ているのか」を数字で把握できることです。

採用判断への影響

整理すると、(incubating) が付いている間に注意すべきなのは次の点です。

評価・検証目的で個人の環境に入れて触るぶんには、ここは大きな障害になりません。一方で、社内のプロダクトに組み込む、あるいは再配布する、という段階なら法務確認が必要です。この差は「Apache という名前」からは読み取れないので、リポジトリの DISCLAIMER-WIP を実際に開いて確認する習慣をつけておくと安全です。

手元に何が置かれるか——資格情報とデータ境界

ローカルファーストを名乗る以上、「では手元に何が置かれるのか」は使う前に知っておきたいところです。README にはかなり率直に書かれています。

保存場所と中身

既定では Electron の userData 配下、workspaces/default/ にワークスペースが作られます。中身の役割分担はこうです。

・runtime.sqlite — 運用上の唯一の権威。ランタイムイベント、セッションのメタデータとメッセージ履歴、Agent Graph の制御、実行状態、ワークフロー状態、使用量と価格、成果物のメタデータ、自動化、Daily Review、継続レコードを持つ
・credential-vault.json — Runtime Policy の資格情報。接続の API キーや OAuth の材料、リクエストヘッダ、Web 検索のキー、プロキシのパスワードが入る
・artifacts/ — 成果物の実体。バイト列は SQLite ではなく通常のファイルとして置かれる
・connection-catalog.json — モデル接続先のカタログ
・runtime-host-client/credentials.json — Runtime Host のクライアント側資格情報。上の vault とは別扱い

資格情報は平文で置かれる

ここは明確に書いておく必要があります。credential-vault.json は ローカルの平文です。README はそれを隠さず、守っているのは OS のアカウント境界と POSIX のパーミッション（ディレクトリ 0700 / ファイル 0600）である、と書いています。

つまり、同じ OS アカウントで動く他のプロセスからは読めます。エージェント自身に Bash や Read を渡している以上、これは無視できない性質です。README 側も、レンダラープロセスには平文の資格情報を渡さない、ファイル書き込みとシェル実行および危険なツール呼び出しは権限エンジンを通す、と対になる制約を明記しています。

資格情報の置き方をどう設計するかはエージェント基盤ごとに判断が分かれるところで、たとえばOpenSandboxとは｜AIエージェント用サンドボックスの使い方とCredential Vaultを実測解説では同じ「Credential Vault」という名前で別のアプローチを取っています。並べて読むと、どこまでをアプリの責任、どこからを OS の責任と見るかの線引きの違いが見えます。

アップグレード時にデータが消える境界

もう一つ、README が「意図的な data-loss boundary」と呼んで注意を促している点があります。

・旧世代の File / JSONL 由来の会話履歴は移行されない。セッションのタイトルは現行のメタデータから見つかることがあるが、転写ファイルにしか存在しない会話本文は session_messages にコピーされず、空のスレッドとして開く
・旧版や Electron の safeStorage で暗号化された資格情報・トークンファイルも移行されない。そのコピーしか持っていない利用者は再認証が必要
・現行の接続カタログは connection-catalog.json で、既存の llm-connections.json はディスク上に残るが読み込まれない

「意図的」と書かれているとおり、これはバグではなく設計判断です。ただしアップグレード前に知っていないと事故になるので、既存のワークスペースを持っている場合はバックアップを取ってから上げるべきです。

バックアップ自体は丁寧に作られていて、SQLite のオンラインバックアップ API を使い、成果物は writer ロックの下でコピーし、マニフェストがすべてのファイルをサイズと SHA-256 で束ねます。復元前の検証では、スナップショットの整合性、外部キー、スキーマレジストリと必須テーブル、セッションメッセージと成果物レコードのデコード、そして成果物のサイズと SQLite 側メタデータの一致まで確認する、と記載されています。

エージェントの状態をどこにどう持たせるかという設計課題は、この分野の共通の悩みどころです。メモリ常駐で持つ設計と比べたい場合はRivet Actorsとは｜AIエージェントの状態をメモリ常駐で永続化するactorランタイムを実測が対照的で、Maka の「ディスク上の追記ログが権威」という選択の意味が掴みやすくなります。

Apache Maka と既存のローカル志向エージェントは何が違うか

Maka のような「ローカル完結」を掲げる基盤は他にもあります。差が出るのは、何をローカルに置くかではなく何を権威として扱うかです。

たとえば個人向けの AI をローカルに閉じる設計としてOpenHuman徹底解説｜118連携の個人AIをローカル完結させるMemory Tree + Obsidian設計がありますが、あちらは「記憶をどう構造化して持つか」に軸足があります。Maka の軸足は記憶ではなく実行の事実です。何を覚えているかではなく、何をしたかを残す。

観点ごとに整理すると次のようになります。

「Maka にしかできないこと」を一言でいえば、エージェントの実行を後から検証可能な事実として残したまま、文脈だけを自由に削れるという点です。長時間・多ツールのタスクを回すほど効いてくる性質で、逆に単発の質問応答しかしないなら恩恵はほとんどありません。

なお、初回起動時にモデルアカウントは同梱されません。Settings → Models で API・ローカルモデル・対応アカウントのいずれかの接続を追加し、テストして既定モデルを選ぶ、という手順を踏みます。README は接続状態を「設定済み」「送信可能」「実験的」に区別し、Runtime に配線されていないアカウント経路は使用可能なモデルとして提示しないと書いています。UI 上で選べるのに実際は動かない、という状態を避ける設計です。

導入判断——いま触るべき人、待つべき人

ここまでの実測を踏まえて、現時点での立ち位置を整理します。

触る価値がある人

・エージェントの実行監査に関心がある——ツール呼び出しと権限判断がイベントとして残る設計は、まだ実装例が多くない。「Log is the Runtime」を実物で確かめられる
・ローカルにデータを置きたい制約がある——セッション・設定・実行記録が既定で手元に残る。モデル接続先も自分で選ぶ
・エージェントのベンチマークを回したい——maka eval は宣言的に多腕の実験を定義し、タスク × 反復 × 被験体のセルに展開する。Maka 自身と外部エージェントを同じ枠組みで比較できる
・Apple Silicon の Mac を使っている——署名・公証済みのデスクトップビルドがあるのは現状ここだけ

まだ待ったほうがいい人

・本番の業務データを扱いたい——README 自身が active development でデータ形式が変わりうると明記。アップグレード時のデータ移行境界も存在する
・社内プロダクトへ組み込みたい——ICLA と software grant が未完了で、DISCLAIMER-WIP がライセンス審査を要求している
・Linux か Intel Mac のデスクトップが要る——配布物が無い。CLI/TUI なら Linux x64 も検証対象に含まれる
・Windows で安心して配布したい——現状は未署名プレビュー。SHA-256 の照合が前提
・PC 操作（Computer Use）が目的——スキルは同梱されるが実行系が除外されている

追いかけるべきシグナル

このプロジェクトは動きが速く、v0.1.0 から v0.1.11 まで 2026 年 8 月の約 3 週間で到達しています。判断を先送りするなら、次の変化を見ておくと状況が掴めます。

・DISCLAIMER-WIP が無印の DISCLAIMER に変わったか（宿題が片付いたサイン）
・ソースにライセンスヘッダが入ったか（0/2,234 が動いたか）
・npm の latest が prerelease でない版を指すようになったか
・Linux / Intel Mac のデスクトップ配布が追加されたか
・Computer Use の executor が同梱されたか

いずれも、この記事に書いたコマンドをそのまま実行すれば自分で確認できます。数字が古くなったら、記事ではなく実物を見てください。

参照ソース

• apache/maka — GitHub リポジトリ（README / ARCHITECTURE / DISCLAIMER-WIP / NOTICE、および 2026-08-21 時点のリポジトリ実測）
• Apache Maka Project Incubation Status — Apache Incubator
• ASF podling レジストリ（public_podlings.json）（受入日 2026-08-13・メンター・champion の一次データ）
• Maka CLI インストールガイド（packages/cli/README.md）
• maka-agent — npm レジストリ（dist-tags と公開バージョンの確認）
• Maka 0.1.11 リリース — GitHub Releases（配布物・サイズ・署名状態）
• Node.js zlib ドキュメント（createZstdCompress の追加バージョン）