Kobune とは
Kobune は、git worktree ごとに独立した実行環境を用意し、それぞれに URL を 割り当てるツールです。
$ kobune new feature/user-auth
✓ creating worktree feature/user-auth
✓ starting web
✓ waiting for web
╭ myapp / feature-user-auth ──────────────────────────────────╮
│ feature/user-auth /path/to/myapp.wt/feature-user-auth │
│ │
│ ● web ready https://web.feature-user-auth.myapp.localhost │
╰─────────────────────────────────────────────────────────────╯基本となる考え方は「worktree 1 つにつき環境 1 つ」だけです。worktree を作れば 環境ができ、削除すれば環境も消えます。
解決する課題
レビューのためにブランチを切り替えるたびに、動かしていたものを止め、 チェックアウトし直し、起動し終わるのを待ち、それまでの作業の流れを 見失います。かといって複数のブランチを同時に動かせば、今度は空いている ポートを探し、どの環境がどのブランチのものかを覚え、共有状態の衝突に 対処することになります。
ソースコードを並行して扱う部分は、すでに git worktree が解決しています。 Kobune が受け持つのは、それを実際に動かす部分です。
- worktree ごとに URL が割り当てられます。 ブランチ名から生成されるため、
feature/user-authであればweb.feature-user-auth.myapp.localhostとなり、 再起動しても変わりません。 - 使われていない環境は自動的に停止し、次のリクエストで 1〜2 秒で復帰します。 worktree が 10 個あっても、常時 10 個の環境が動くわけではありません。
- 環境同士は衝突しません。 コンテナも URL も分離されており、データベースの ように共有したいものは設定で明示できます。
エージェントによる操作を前提とした設計
この前提が設計の大部分を決めています。コードを変更する AI エージェントは、 その変更が正しく動作したかを確認する必要があります。しかし一般的な方法、 つまり docker を直接操作し、ポート番号を推測して curl するというやり方は、 気づきにくい形で失敗します。
そこで Kobune では、すべてのコマンドが --json に対応し、失敗時には種類の 分かる終了コードを返します。kobune skill install は、どのコマンドを使い、 どれを避けるべきかを書いた Skill ファイルを書き出します。これに従う エージェントは docker を直接操作せず、ポート番号も推測せず、問題が 起きたときに空の応答ではなく具体的なエラーを受け取ります。
どれも人が使う分を犠牲にしていません。同じコマンドを人が実行すれば、 JSON ではなく読むための形で、同じ情報が返ります。
Kobune の対象外
- 本番環境向けのデプロイツールではありません。 開発マシン上で、その 所有者が操作することを前提としています。
- コンテナランタイムではありません。 実際にコンテナを動かすのは Docker や Apple Container です。Kobune はその手配をするだけです。
- Docker Compose の代替でもありません。 1 つのブランチで 1 つの環境を 動かせば足りるのであれば、Compose のほうが単純です。Kobune が有効なのは、 ブランチが増えてからです。