Minato とは
Minato は、git worktree ごとに独立した実行環境を用意し、それぞれに URL を 割り当てるツールです。
$ minato 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 が解決しています。 Minato が受け持つのは、それを実際に動かす部分です。
- worktree ごとに URL が割り当てられます。 ブランチ名から生成されるため、
feature/user-authであればweb.feature-user-auth.myapp.localhostとなり、 再起動しても変わりません。 - 使われていない環境は自動的に停止し、次のリクエストで 1〜2 秒で復帰します。 worktree が 10 個あっても、常時 10 個の環境が動くわけではありません。
- 環境同士は衝突しません。 コンテナも URL も分離されており、データベースの ように共有したいものは設定で明示できます。
エージェントによる操作を前提とした設計
この前提が設計の大部分を決めています。コードを変更する AI エージェントは、 その変更が正しく動作したかを確認する必要があります。しかし一般的な方法、 つまり docker を直接操作し、ポート番号を推測して curl するというやり方は、 気づきにくい形で失敗します。
そこで Minato では、すべてのコマンドが --json に対応し、失敗時には種類の 分かる終了コードを返します。また minato skill install を実行すると、 どのコマンドを使い何を避けるべきかを記述した Skill ファイルが配置されます。 これに従うエージェントは docker を直接操作せず、ポート番号も推測せず、 問題が起きたときに空の応答ではなく具体的なエラーを受け取ります。
これらは人間にとって使いにくくなる変更ではありません。同じコマンドを人間が 実行すれば、JSON ではなく読みやすい形式で同じ情報が得られます。
Minato の対象外
- 本番環境向けのデプロイツールではありません。 開発マシン上で、その 所有者が操作することを前提としています。
- コンテナランタイムではありません。 実際にコンテナを動かすのは Docker や Apple Container であり、Minato はそれらを制御する層に位置します。
- Docker Compose の代替でもありません。 1 つのブランチで 1 つの環境を 動かせば足りるのであれば、Compose のほうが単純です。Minato が有効なのは、 ブランチが増えてからです。