Gemini CLIのセッション1つは、1つのディレクトリで動く1つのエージェントにすぎません。同時にもう1つタスクを進めたくなった瞬間——リファクタリングが走る横でバグを直し、機能が入る横でテストを書く——あなたはターミナルをもう1つ開きます。そして3つ目も。1時間もすれば、タブが4つ、作業ディレクトリが4つ、そしてこんな単純な問いにすっきり答えられなくなります。どのエージェントが何をしていて、自分がこれから編集しようとしていたファイルに触ったのはどれなのか。
Geminiのタスクを複数並行して走らせること自体は、始めるのは難しくありません。難しいのは、それを整理して把握し続けることです。個々のインスタンスはそれだけで速い。コストは調整にあり、そして調整こそターミナルが決して与えてくれない部分です。
この記事では、Gemini CLIエージェントを並列で動かすための手動セットアップを順を追って見ていき、各ステップに潜む失敗パターンを挙げ、どこからタスクボードに引き継がせるべきかを示します。そのタスクボードが、エージェントの指揮と管理をこれ一つでこなすプラットフォーム、Sharklyです。SharklyはGemini CLIの代替ではありません。チームがすでに使っているランタイムの周りに、タスク共有、Computer、コンテキスト、レビューのレイヤーを追加するものです。だから並列実行はタブに散らばるのではなく、割り当て可能で追跡可能なまま保たれます。
Gemini CLIにおける「並列エージェント」とは
Gemini CLIは1プロセスにつき1つのエージェントを動かします。カレントディレクトリを読み、GEMINI.mdコンテキストファイルがあれば読み込み、その1つの作業ツリーの中でプロンプトを処理します。1つのゴールを複数のサブエージェントに振り分け、その成果を自動でマージしてくれるようなディスパッチャは標準では備わっていません。
つまり実務上の「Gemini並列エージェント」とは、ただ1つのことです。すなわち、複数のgeminiプロセスを同時に走らせ、それぞれが独立した環境で、それぞれ別のタスクを担うという状態です。Gemini CLIはオープンソースで、個人のGoogleアカウントでも無料で動かせる。だからこそ、みんな一度に4つ立ち上げるわけです。ボトルネックは立ち上げる段階ではありません。同じリポジトリで4つの独立した実行が衝突しないようにすること、そして1時間後にそれぞれが何を生み出したかを把握すること、そこにあります。
これはClaude CodeでもCodexでもぶつかる、同じ調整の問題です。ランタイムが変わっても、混沌は変わりません。
手動セットアップを順を追って
ここからは、並列Gemini CLIの最小構成の動く形と、各ステップで壊れるポイントを紹介します。
ステップ1：エージェントごとに作業ツリーを分ける。2つのエージェントを同じフォルダで動かしてはいけません。タスクごとにgit worktreeを使い、チェックアウトを物理的に分離します。
git worktree add ../repo-auth feature/auth
git worktree add ../repo-tests chore/tests
git worktree add ../repo-bugfix fix/login-redirect
省略した場合の失敗パターン：1つのチェックアウトを2つのエージェントが編集し、実行中にお互いを上書きします。片方が別のエージェントの作業途中のファイルを整形し直し、結果としてどちらの意図でもない状態のツリーが残ります。worktreeは各エージェントにクリーンなブランチとクリーンなディレクトリを与えます。この点はAIコーディングエージェントのためのgit worktreeで詳しく掘り下げています。
ステップ2：worktreeごとにGemini CLIを1つ起動する。各ディレクトリでターミナルを開き、セッションを起動します。
cd ../repo-auth && gemini
無人で走らせる場合は、非対話モードを使えばエージェントは1つのプロンプトを受け取って終了します。
cd ../repo-tests && gemini -p "Add unit tests for the session module. Run the suite before finishing."
失敗パターン：対話セッションは最初の権限確認プロンプトで止まり、待ち続けます。20分後に戻ってみると、yesが欲しかっただけで何もしていないエージェントがいる。どの実行を対話型にし、どれをヘッドレスにするかを最初に決め、ヘッドレスには検証ステップを自前で含むプロンプトを渡しましょう。
ステップ3：タスクごとにコンテキストを分離する。各worktreeは、そのタスク用のルール（触れてよいもの、触れてはいけないもの、テストの実行方法）を書いたGEMINI.mdをそれぞれ持てます。
失敗パターン：すべてのエージェントで1つのコンテキストファイルを共有すると、認証タスク向けの指示がテストタスクに漏れ出します。コンテキストは、それが属するツリーにスコープを絞りましょう。
ステップ4：クォータを監視する。実行中のインスタンスはすべて同じアカウントの上限を消費します。4つのエージェントが大規模なリファクタリングで一気に走れば、1つのときより早くレート制限に達します。そして制限に引っかかったエージェントは、あなたが見ていないタブの中で静かに失敗します。
失敗パターン：クォータエラーで実行が止まっても、そのタブを確認するまで気づけません。エージェントが停止したことを知らせてくれる共有ビューが存在しないのです。重いタスクを適切なモデルに割り当てたいなら、どのコーディングタスクにどのモデルをでそのトレードオフを扱っています。
タスクが3つか4つまでなら、これで回ります。本物のブランチ、本物の分離、本物の並列実行。追加ツールは不要です。
DIYセットアップがスケールしなくなる地点
手動セットアップが壊れるのは、実行そのものではなく、その周辺のすべてです。タスク数が増えると何が起きるかを見てみましょう。
地図を失います。ターミナルが4つなら頭の中に置いておけます。8つ、しかも2つのリポジトリにまたがると、もう無理です。どのタブが認証エージェントだったか。テスト実行は終わったのか、それともクォータエラーで死んだのか。並列で動くコーディングエージェントの監視は、ターミナルがそもそも担うようには作られていない仕事です。
結果が散らばります。各エージェントは、ブランチ上のdiffと、いつか閉じるタブのスクロールバックの山として成果を残します。各実行が何を変えたのか、なぜ変えたのか、自分のテストに通ったのかを記録する共有の場所がありません。チームメイトに「ログイン修正は何をしたの？」と聞かれても、答えはもう存在しないターミナルの中にあります。
レビューに行き場がありません。並列エージェントは並列のdiffを生み、そのどれもが人間の承認を必要とします。要約も検証結果もコンテキストもない4つのブランチを読むのは、エージェントが速かった分よりも遅い。実行で稼いだスピードを、レビューで返上することになります。
ここで正直な判断基準を挙げます。たまにGeminiタスクを3つか4つ走らせる程度なら、上のworktreeセットアップを続けましょう。シンプルで、ちゃんと動きますし、タスクボードは不要なオーバーヘッドになります。タスクボードが必要になるのは、並列実行が当たり前になったときです。エージェントが複数、リポジトリが複数、進捗を見る必要のある人が複数、そしてレビューは記憶ではなく追跡可能でなければならない。その段階では並列エージェントを管理するツールの比較をしておく価値があります。
タスクボードが加えるもの
タスクボードは、作業の単位を「ターミナルのタブ」から「タスク」へと変えます。DIYセットアップに欠けているのは、この一点の転換です。
Sharklyでは、Gemini CLIを土台にしたエージェントにタスクを割り当てます。エージェントはタスクを引き受け、分離されたworktreeで作業し、実行状況、ブロッカー、結果、その後のやり取りは、プライベートなターミナルに消えるのではなくタスクのタイムラインに戻ってきます。複数を同時に走らせても、それぞれが目に見える1行であり、探し回るタブではありません。コーディングは引き続きGemini CLIが担い、Sharklyは割り当て、接続されたComputer、コンテキスト、そしてすべての実行にわたるレビューを管理します。
役割分担は明確なままです。エージェントは調査し、実行し、テストし、報告する。人が方向性を定め、権限を与え、結果を承認する。チームの判断が必要なところで自動化は止まり、各実行は変更サマリーと自前の検証結果を携えて戻ってくるので、diffを受け入れるか却下するかは、考古学の発掘ではなくひと目で済みます。コンテキスト、進捗、ブロッカー、結果、人間によるレビューは、依頼からリリースまで見えたままです。
すでに持っているものは手放さずに済みます。SharklyはGemini CLIを離れろとも、1つのランタイムに縛られろとも言いません。プロバイダーに依存しない設計なので、同じタスクボードでClaude CodeやCodexのエージェントをGeminiのエージェントと並べて動かせます。次に優れたエージェントが何であれ、ワークフローは生き残ります。この中立性こそが要点です。新しいものが出るたびにエコシステムを乗り換えるのではなく、1か所であなたのエージェントを管理するのです。
今日から使えるチェックリスト
次に並列Geminiタスクをまとめて走らせる前に、これを確認してください。
- [ ] タスクごとにgit worktreeを1つ。1つのチェックアウトで2つのエージェントを絶対に動かさない。
- [ ]
GEMINI.mdはタスクごとにスコープを絞る。全タスクで1つの共有ファイルにしない。 - [ ] ヘッドレス実行は
gemini -pを使い、検証ステップを組み込んでおく。プロンプトで止まらないように。 - [ ] 同時実行インスタンス数の上限を決めておく。共有クォータで、見えない実行が絞られないように。
- [ ] 「どのエージェントが何を担当していて、何が終わったか」に、すべてのタブを開かず答えられる場所を1つ用意する。
- [ ] 完了した実行はすべて、ブランチ上のdiffだけでなく、人間がレビューできる変更サマリーとテスト結果を残す。
最初の4つは、今夜にでもworktreeとターミナルで実行できます。最後の2つが、手動セットアップの限界です。すでに複数のGemini CLIエージェントを同時に走らせているなら、Sharklyはタスクを割り当て、進捗を見守り、結果をレビューする場所を1つにまとめてくれます。調整レイヤーは自分で作ることもできますし、既存のコーディングエージェントをSharkly経由で動かして、スケールする部分まで一気に進むこともできます。
