Gini Agent は「ランタイムが gateway」という設計を選んだ個人エージェント
The agent that remembers and learns.
ひと目でわかる
- これは何？
- Bun プロセス1つが状態と実行を所有し、Next.js・CLI・Expo・MCP が同じ /api/* 契約のクライアントになる。会話ログではなくランタイムを記録の主体に据えた構成を、導入判断の観点から読む。
- 誰に向いている？
- 自分専用のマシン上で、ファイル・ターミナル・ブラウザ操作を伴うエージェントを常駐させ、承認と秘密情報の扱いを制御したい個人に向く。逆に、複数人で共有するサーバや、監査ログを外部 SIEM に集約する前提の組織には、localhost gateway と per-instance 状態という前提が噛み合いにくい。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 60 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
会話ログではなくランタイムを記録の主体にする
多くの個人エージェントは、チャットのやり取りを保存し、その上にツール呼び出しを重ねる。Gini Agent はそこを逆に置く。README は「The runtime is the system of record for conversations, runs, tasks, approvals, memory, skills, jobs, tools, traces, audit events, and runtime health」と述べており、会話はランタイムが持つ複数の記録対象のひとつにすぎない。対象は runs、tasks、approvals、traces、audit events、jobs、memories、skills と列挙されている。
この設計が効くのは、エージェントが自分でジョブを回し、複数ステップの作業を進める場合だ。単発の質問応答なら会話ログ中心でも足りるが、スケジュール実行と承認待ちが混ざると、どの実行がどの承認で止まっているのかを追う必要が出る。ランタイムを一次記録にすれば、UI を差し替えても実行履歴の意味が変わらない。
対象読者は、自分のマシンに常駐させて使う個人、およびエージェントの実行系そのものを差し替えたい開発者だ。マネージドサービスとして誰かに運用してもらう用途は想定されていない。
1インスタンス1 Bun プロセス、クライアントは /api/* に集約
README のアーキテクチャ図は、GATEWAY を「Bun runtime, one per instance」とし、その下に Next.js BFF、CLI/scripts、その他クライアント（モバイル、MCP、メッセージング）がぶら下がる形を示している。ゲートウェイが状態、エージェントループ、ツール、メモリ、ジョブを持ち、クライアントは認証済みの /api/* 契約を共有する。
注目点はブラウザ側の扱いだ。図の注記によれば Next.js BFF は「no browser token」、つまりブラウザはトークンを保持せず、BFF がゲートウェイとの認証を引き受ける。CLI やスクリプトは bearer token を直接使う。同じ契約に別々の認証経路で入る構成なので、クライアントを追加するときはどちらの経路に乗るかを決める必要がある。
インスタンスは並列に立てられ、状態、ポート、ログが分離される。1つのプロセスが全部を持つため、プロセスを落とすとそのインスタンスの実行も止まる。可用性を分散で担保する作りではない。
承認ゲートと、モデルに渡らない秘密情報
同梱物として README が挙げるのは、認証付き localhost ゲートウェイ、Next.js + Tailwind + shadcn/ui のコントロールプレーン、永続化される chat/runs/tasks/approvals/traces/audit/jobs/memories/skills、そして承認ゲート付きのファイル・ターミナル・コードツールだ。ツールは既定で自由に走るのではなく、承認を挟む。
秘密情報の扱いがこのプロジェクトの特徴的な部分である。README によれば、key、password、OTP、payment の入力は secure card に直接入力され、gateway へ流れる。モデル、トランスクリプト、audit trail には到達しないと明記されている。「add a connector first」のような迂回や、チャットへの資格情報の貼り付けを避ける設計だ。
もうひとつがブラウザのハンドオフである。サインインの壁や本人しかできない手順に当たったとき、エージェントは自分のブラウザのライブビューをユーザーに渡し、完了後に作業を再開する。gateway が動いているマシンの前に座っていなくてもよい、というのが README の主張である。
これらの設計意図は docs/adr/ 配下の ADR に分けて置かれている。user-choice-prompt.md、user-confirmation-primitive.md、browser-fill-secret.md、chat-credential-provisioning.md、browser-connect-handoff.md の5本が README から名前で挙げられている。判断の根拠を後から辿れる形にしてある点は、後述する保守コストの見積もりにも効く。
インストールは1行、その後に /setup と autostart
Quick Start として README が示すのは次の1行だけだ。
curl -fsSL https://raw.githubusercontent.com/Open-Curiosity/gini-agent/main/scripts/install.sh | bash
macOS ではインストーラが autostart を有効にする。per-user LaunchAgents として runtime と webapp が登録され、webapp の起動を待ってからブラウザで /setup ページを開く。このフォームに provider のカタログが並ぶ、というのが README の説明である。
provider 側の資料は docs/providers/README.md に分かれ、OpenAI、Anthropic、Bedrock、Azure、OpenRouter、DeepSeek、Codex、Local のセットアップ（資格情報、前提条件、CLI/web 設定）が個別に扱われている。Codex は OAuth、OpenAI 系と DeepSeek、OpenRouter は API key、Bedrock は AWS SigV4 の Converse 経由でモデル非依存、Local は OpenAI 互換サーバなら何でも、という整理になっている。
運用面は docs/operations.md に install、start、stop、smoke、diagnostics、cleanup がまとまっている。コンテナで headless に動かす場合は docs/deployment-docker.md が Xvfb 下の実ブラウザ前提の手順を示す。リモートから触る場合は tunnel モードと確認手順があり、Gini Relay、Tailscale、ngrok、Cloudflare の各ページがアプリ内からも開ける形で用意されている。
ローカル埋め込みを既定にしたメモリと、スキル学習の人間ゲート
メモリは docs/memory.md で retain、recall、embeddings、reranking、review、storage として整理されている。埋め込み、リランキング、音声メッセージの speech-to-text は既定でローカル処理だと README は述べる。つまり、検索や並べ替えのたびに外部 API へ本文を送る構成を既定にはしていない。
スキル学習は docs/skill-learning.md が担当し、タスク結果からの改善を two-tier reward、attribution、daily review、human gate という4つの要素で説明している。日次のレビューがあり、その結果を反映する前に人間のゲートを置く。自動で自己書き換えを続けるのではなく、改善案を人が承認する位置づけだ。
ここは評価が分かれる。日次レビューと人間ゲートは、放置したまま勝手に振る舞いが変わることを防ぐが、その分ユーザーが定期的にレビュー結果を見る必要がある。エージェントを完全に手放しで走らせたい人にとっては、このゲート自体が摩擦になる。
なお、two-tier reward や attribution の具体的な計算方法、レビューの頻度設定、ゲートを省略できるかどうかは、与えられた README からは読み取れない。docs/skill-learning.md の本文を確認する必要がある。
MCP サーフェスはクライアント側であって、ランタイムの外にある
topics には mcp が含まれ、アーキテクチャ図でも MCP はクライアント側に置かれている。つまり Gini は MCP サーバの集合体ではなく、MCP を含む複数のクライアントから同じ /api/* 契約に到達する構造だ。
この違いは導入時に効く。MCP サーバを足すたびに権限と状態が別プロセスへ散る構成と比べ、状態は gateway に集まる。承認、トレース、監査イベントも同じ場所に残る。一方で、MCP 経由で何ができるかは gateway 側のツール実装に依存し、外部の MCP サーバをそのまま差し込めば同じ保証が得られるわけではない。
メッセージングブリッジも同じ扱いだ。README は messaging bridges をクライアントの一覧に含めているが、どのサービスに対応するかの記載は与えられていない。
向かない場面と、代替になる構成
第一の制約は localhost gateway という前提である。認証はあるが、ゲートウェイは各インスタンスのローカルに立つ。複数人で1つのインスタンスを共有する使い方は README に想定が見当たらない。並列インスタンスは状態・ポート・ログを分離すると説明されており、これは共有ではなく分離の話だ。
第二に、Bun プロセスが単一障害点になる。1インスタンス1プロセスという設計は、プロセスが落ちればそのインスタンスのジョブもメモリ書き込みも止まることを意味する。図から読み取れる範囲では、冗長化やフェイルオーバーの仕組みは示されていない。
第三に、ランタイムを一次記録に置くという判断は、既存の可観測性スタックへの接続を前提にしていない。audit events や traces はランタイム内に溜まる。外部の SIEM や APM に流す前提で運用を組んでいる組織は、独自の橋渡しを書くことになる。
代替として挙げられるのは、MCP サーバを並べてホスト側のエージェントから呼ぶ構成だ。違いは状態の所在にある。MCP 中心の構成では、各サーバが自分の状態と権限を持ち、ホストがそれらを束ねる。Gini は逆で、gateway が状態と承認を持ち、MCP はそのクライアントのひとつにすぎない。ツールを足すたびに権限を個別に設計したいなら前者、承認とトレースを一箇所に集めたいなら後者が噛み合う。どちらが優れているという話ではない。
もうひとつの現実的な選択は、Gini を導入せず、既存のチャット UI とシェルスクリプトで済ませる方法だ。スケジュール実行、承認待ち、ブラウザハンドオフのいずれも必要としないなら、ランタイムを常駐させる理由は薄い。
MIT ライセンスと、更新時に見るべきファイル
ライセンスは MIT である。ソースの改変、再配布、商用利用のいずれも許容される条項であり、同梱のライセンス全文に従う限りにおいて、という条件が付く。ここから先は法的助言ではない。自組織のポリシーに照らした判断は別途必要になる。
更新のコストを見積もる材料はリポジトリ内にある。docs/releases.md が versioning、CHANGELOG の規約、リリース手順を説明しており、リリースは v0.1.0（2026年5月22日）、v0.2.0（6月3日）、v0.3.0（6月8日）と、約3週間で3本が出ている。0.x 系である以上、マイナー番号の間で設定や保存形式が動く可能性は残る。
実際に差分を追うときは、CHANGELOG に加えて docs/implementation-notes.md のモジュール境界ルールを見ておくと、どの変更が自分の改変と衝突するかを判断しやすい。ADR は docs/adr/README.md に索引があり、新しい ADR の追加方法もそこに書かれている。設計判断が変わった場合は ADR が増える形で残るため、アップグレード前に索引の差分を確認するのが早い。
もうひとつ、openclaw からの移行を検討している場合は docs/migration-from-openclaw.md が既存インストールの取り込みを扱っている。この資料の内容は与えられた README からは確認できないため、移行を前提にするなら本文を読んでから決めるべきだ。
編集部の結論
自分専用のマシン上で、ファイル・ターミナル・ブラウザ操作を伴うエージェントを常駐させ、承認と秘密情報の扱いを制御したい個人に向く。逆に、複数人で共有するサーバや、監査ログを外部 SIEM に集約する前提の組織には、localhost gateway と per-instance 状態という前提が噛み合いにくい。導入前に docs/runtime-capabilities.md の検証コマンドを実際に走らせ、自分の環境でツール呼び出しと承認フローが通ることを確認してから、autostart を有効にするか決めるのが順当だ。
コミュニティノート