git-aiとは？入れ方・使い方を実際に動かして調べてみた動いた

配布元: https://github.com/feder-cr/git-ai 　／　2026-10-20 時点で確認

この日に実際に動かした結果です。内容の誤りに気づかれた場合はお問い合わせください。確認のうえ訂正します。

使う前に分かること

複数のAIエージェントに同じリポジトリを同時に触らせると、誰かの変更がコンフリクト（同じ場所への食い違った変更）で止まったり、順番待ちの行列ができたりします。gitai（開発したFederico Eliaさんは内部では「graft」という拡張部分として呼んでいます）は、Anthropicがブログ記事「Redesigning source control」で紹介した社内システム「Scion」の考え方を、誰でも動かせるオープンソースの形で作り直したGitサーバーです。普通にクローンして使うだけのGitとは違い、専用のサーバーに全員が繋ぎ、複数のエージェントが同時に変更を「着地」させても、サーバー側が順番に処理して弾かれにくくしてくれます。今回は、公式の案内どおりソースからビルドし、同梱の実演スクリプトで「サーバーを1つ立てる→2体のエージェント役が同時に変更をコミットして着地させる→片方だけ許可されていない枝への着地を拒否される→履歴やキャッシュ経由の読み取りを試す」という、公式が最初に見せる使い方をひと通り動かしました。実際のAIエージェント（Claude CodeやCursorなど）を本当に繋いでの運用や、本番向けのデータベース・オブジェクトストレージを使った複数サーバー構成、AIによる自動コンフリクト解決は試していません。

入れる

gitaiはGUI（画面を見てクリックする操作）が無く、ターミナル（文字でコマンドを打つ画面）から全部打って入れます。公式の「Quick start」に書いてある前提はこの4つです。Linux または macOS、Go 1.26、Cツールチェーン（gcc/clangなど）、Meson と Ninja。gitaiは中でGit本体まで自前でビルドするので、これらが全部要ります。このサンドボックスにはMesonが無かったので、ターミナルで pip install meson と打って入れました。

まずターミナルで、クローンします。

git clone https://github.com/feder-cr/git-ai.git

Cloning into '/tmp/verify_git-ai/git-ai'...

公式の案内どおり cd git-ai && make build を打つと、gitaiサーバー本体（内部名はgitaly）・CLIの graft・キャッシュデーモンの graft-cache、そして同梱のGitを3バージョン分、ソースからビルドします。手元の環境では453個のCファイルをコンパイルする規模で、数分かかりました。

make build

[453/453] Linking target git

ここで2つ、公式の説明には書かれていない壁に当たりました。1つ目は、同梱Gitのビルドが libcurl を要求してきて止まったことです。

Run-time dependency libcurl found: NO  (tried pkg-config and cmake)
_build/deps/git-master/meson.build:1164:7: ERROR: Dependency 'libcurl' is required but not found.

Ubuntu系なら、apt-getで開発用パッケージを入れれば直ります（他のLinuxなら、それぞれのパッケージ管理ツールで同じ「libcurlの開発用ファイル」を探して入れてください）。

apt-get install -y libcurl4-openssl-dev

Setting up libcurl4-openssl-dev:amd64 (8.5.0-2ubuntu10.16) ...

2つ目は、Goのバージョンです。このサンドボックスに元から入っていたGoは1.24.7で、gitaiが要求する1.26に足りていませんでした。読者の手元でここに当たったら、Go公式サイトから1.26以上を入れ直すのが一番簡単です。

go: go.mod requires go >= 1.26.0 (running go 1.24.7; GOTOOLCHAIN=local)

このサンドボックスでは入れ直す代わりに、make を経由しない素の go build を一度叩いてみました。すると、Go自身が「このプログラムには1.26が要る」と気づいて、自動でダウンロードしてくれました。

go build ./cmd/...

go: downloading go1.26.0 (linux/amd64)

このダウンロードされた1.26.0を、普段使っている go コマンドの代わりに使うよう切り替えてから make build をやり直すと、最後まで通りました。

動かしてみる

ビルドが終わると _build/bin に gitaly・graft・graft-cache などの実行ファイルが並びます。公式は、ここから先を一度に試せる examples/graft/quickstart.sh というスクリプトを用意しています。作業用フォルダを渡すだけで、サーバーの起動から後片付けまで全部自動でやってくれます。

examples/graft/quickstart.sh /tmp/verify_git-ai/work

実行すると、まずGitaly（gitaiのサーバー部分）がそのフォルダの中だけで起動し、サンプルのリポジトリ demo.git が作られます。

==> Starting Gitaly in standalone mode

続けてキャッシュを担当する graft-cache デーモンも立ち上がります。ここまでで、普段使っているGitHubやGitLabのような「サーバーに繋いで使うGit」が、自分のパソコンの中だけで動く状態になりました。

2体のエージェントが同時に変更を着地させる

ここがgitaiの売りです。実演スクリプト（quickstart.sh）が自動で「planner」「builder」という2つの名前を作り、それぞれ別人としてアクセスできる合言葉（トークン）を発行します。読者が別途何かアカウントを作る必要はありません。この2つを使って、同時に同じリポジトリへ変更を送り込みます。

まずplannerが、demoリポジトリの中にある説明文用のファイルを書き換えてmainブランチに「着地」させます。

committed 8b7548e9fd87 (1 changes) and landed it on main

次にbuilderが、別のファイルをfeature/demoブランチに着地させます。これはルール上許可されているので、同じようにすぐ通ります。

committed 1e96c2f0928f (1 changes) and landed it on feature/demo

ここからが肝心な場面です。同じbuilderが、今度は許可されていないmainブランチに向けて着地を試みます。gitai側に設定したポリシー（どのエージェントがどの枝を更新できるかのルール）が、これをその場で拒否します。

graft commit: committed becd03369062d242eb70e6771d2dc89b5e055638 on graft/builder/7a0fb18247a2b1ba but landing failed (run graft land to retry, or graft land --abort to drop it): rpc error: code = PermissionDenied desc = policy denies "builder" to update "refs/heads/main" (rule 2)

スクリプト自身も、この拒否が狙った通りに起きたことを確認しています。

denied as expected

つまり、人が間に入って揉めるのではなく、サーバー側のルールだけで「このエージェントはこの枝を触ってはいけない」をその場で止められるわけです。変更自体は消えずに、やり直すための名前（ここでは graft/builder/7a0fb18247a2b1ba）として残っています。

履歴とキャッシュを覗く

着地が終わったリポジトリの履歴は、graft コマンドから直接読めます。例えば、どの行を誰が書いたかを見る「blame」を試すと、plannerが入れた一行だと分かります。

8b7548e9fd87     1) hello graft

最後に、同じmainブランチをさらに2回クローンしてみました。1回目はサーバーに新しく問い合わせが行きますが、2回目は直前に取得したものと同じ内容なので、graft-cache のメモリ上のキャッシュからそのまま返ってきます。実際にキャッシュの統計を見ると、object_hits（キャッシュ命中、2回目のクローンがキャッシュから返ってきた回数）が0より増えて1件になっていました。細かい項目の意味は分からなくても、この数字が0より大きければ「キャッシュが実際に使われた」ということだけ分かれば十分です。

{"tier":"daemon","max_bytes":268435456,"memory_bytes":273,"memory_entries":2,"object_hits":1,"object_misses":2,"disk_hits":0,"coalesced":0,"tree_hits":0,"tree_misses":0,"evictions":0,"verify_failures":0,"proxied_calls":26,"hit_rate":0.3333333333333333,"object_hit_rate":0.3333333333333333,"tree_hit_rate":0,"seeded_objects":0,"seeded_bytes":0,"seed_corrupt":0}

まとめ

gitaiは、複数のAIエージェントが同じリポジトリに同時に変更を送り込む、という今どきの困りごとに正面から向き合ったGitサーバーです。今回試した範囲では、実際に2体の「エージェント」が同時に変更を着地させ、片方だけがポリシーで拒否される場面まで、公式の案内どおりに最後まで動きました。ビルドには少し手間がかかります（Go 1.26・Cツールチェーン・Meson・Ninjaに加えて、今回はlibcurlの開発パッケージも必要でした）が、一度通ってしまえば、同梱の実演スクリプトで仕組みの全体像をすぐに体験できます。まだバージョン0.2.0台で、本番向けのデータベース・オブジェクトストレージを使った複数サーバー構成や、実際のAIエージェントを繋いでの運用、AIによる自動コンフリクト解決までは今回試せていません。何体もの自動エージェントに同じリポジトリを並行して触らせたいチームにとっては、人がコンフリクトを手でさばく前提そのものを見直すきっかけになりそうなツールです。

確認した環境

Linux（Ubuntu 24.04、x86_64）、Go 1.26.0（ローカルの1.24.7では要求バージョンに足りず、取得し直した）、Meson 1.12.1・Ninja 1.11.1・libcurl4-openssl-devでソースからビルド。AIエージェントは使っていません。同梱の実演スクリプトが、2体の「エージェント」をアクセストークンだけで再現する形になっており、Claude CodeなどのAIを実際に接続しての検証は今回行っていません。