Claude Code と Gemini CLI の協業を試してみた
Claude Code を使っていると、途中で完成しました!と報告を受けて見てみると全然できてないとか、終わりました!といって全然途中だったりすることがよくあり、つらい。
Claude が抜け道を通れないテストを用意することが必須となりつつあるが、人間がそれを確かめたり、マネジメントする代わりに、Gemini CLI にある程度の露払いはやってもらったらどうだろう、という実験をした。たいそうなものじゃなく、やってみたらこうなった、というだけ。
Gemini CLI で使えるモデルはコーディング性能が良くないが、有り余るコンテキストウィンドウがあり、マネジメント用途にはよさそうに見える。
もちろん Claude2Claude でやってもよいが、モデルの得意なところに違いがあるので意味がありそうに思えた。分業ではあるが直列で、AIに並列で仕事をさせる系の文脈ではない。
準備
tmux で Gemini CLI と Claude Code 用の Pane を用意して、それぞれ gemni-pane, claude-pane としよう。
まず作業ディレクトリに以下のような CLAUDE.md および GEMINI.md を用意する。
内容は適当です
CLAUDE.md
# Gemini からの指示を受けた場合
- Gemini CLI と協調作業すること
- tmux の send-keys でやりとりし、マネージャとして指示を仰ぐこと
- 結果レポート、作業内容を Gemini に必ず伝えること
- Gemini は tmux の gemini-pane で起動している
## tmux 操作
- メッセージを送信する前に、capture-pane でプロンプトが表示されていることを必ず確認すること:tmux capture-pane -t "gemini-pane" -p
- Gemini の作業を一旦キャンセルしたいときは esc を send-keys すべし
- tmux send-keys -t "gemini-pane" "内容" Enter
- tmux send-keys -t "gemini-pane" "" Enter
- Enterは10秒間をおいて2回送る必要がある
Gemini の場合は融通が利きづらいので、操作を順番に定義するように書く。
GEMINI.md
# Claude Code から依頼があった場合
- 細かい操作、調査、実際の作業は Claude に任せて、Gemini はマネジメントだけに徹せよ
- レポートと結果成果物についての Quality Assuarance を行なう
- 作業内容の動作確認を行う
- claudeが行ったコードのレビューを行なう
- テストがある場合は実行し、問題があるなら直させる
- テストコード自体もレビューする
- 指示は tmux の send-keys を通じて行う
- Claude は claude-pane で起動している
- tmux send-keys -t "claude-pane" "指示" Enter
- Enterは10秒間をおいて2回送る必要がある
- tmux send-keys -t "claude-pane" "" Enter
- 自分を Gemini であると名乗る
- send-keys を用いて結果レポートをgeminiに返す様に伝えるのを忘れぬこと
- 末尾に ultrathink をつけること
- 送信後は速やかにプロンプト入力画面に戻り、Claude からの send-keys を待つこと
例:
tmux send-keys -t "claude-pane" "指示 レポートを tmux send-keys を用いて gemini に返すこと。 ultrathink" Enter
そして、.claude/commands/withGemini.md
として, CLAUDE.md と同内容を定義しておく。
これは Claude Code 起点でタスクを実行したいためで、/withGemini
が使えると便利であるから。
# gemini as orchestrator
- Gemini CLI と協調作業すること
- tmux の send-keys でやりとりし、マネージャとして指示を仰ぐこと
- 結果レポート、作業内容を Gemini に必ず伝えること
- Gemini は tmux の gemini-harvest で起動している
## tmux 操作
- メッセージを送信する前に、capture-pane でプロンプトが表示されていることを必ず確認すること:tmux capture-pane -t "gemini-harvest" -p
- Gemini の作業を一旦キャンセルしたいときは esc を send-keys すべし
- tmux send-keys -t "gemini-harvest" "内容" Enter
- tmux send-keys -t "gemini-harvest" "" Enter
- Enterは10秒間をおいて2回送る必要がある
なぜ Claude Code 起点である必要があるのかというと、Gemini 起点だとマネジメントではなく自分でやろうとしてしまったり、あまり詳細なプロジェクトマネジメントをしてくれなかったり、GEMINI.md を無視したりとでうまくいかなかったため。今後改善するであろうとは思う。
あと gemini-2.5-flash
だとプロンプトをちゃんと汲み取ってくれなくて自分でやろうとする。
実行結果
Claude Code は claude --dangerously-skip-permissions
で起動した。 Gemini は gemini -s --yolo
として実行した。-s
はサンドボックスモードで勝手にコンテナの中で動いてくれるらしい。さらに中で docker を動かしたら、Docker outside Docker てやつで、ホスト側のサービスで動いた。--yolo
は --dangerously-skip-permissions
と等価っぽい。
手元の仮想通貨BOTの改善をタスクとして与えたところ、思ったより良い感じに協業してくれて、単体でやるより良い結果が得られた。定量的に表すことはできないが、いわゆる「体験がよい」。
Claude Code 単体なら途中で辞めてしまう長大なタスクも、定期的にGeminiへの報告がいき、それを Gemini が次のステップの指示出しをしたり本当にできてるか確かめてくれたりするので、人間が見なくてはならないステップがかなり減った。本当に良いのかはよくわからないけどいいかもしれない。しばらく使ってみようと思う。
補遺
Gemini から claude -p
呼び出したら良いのでは?とも思って試してみたけど、長いセッション待ってレスポンス来るまで諦めたりして安定しなかったので、やめた。
mcp サーバを用意して橋渡ししてあげれば(Agent 側が使ってくれさえすれば)安定するだろうけれど、まずはこの協業がどういうふうに動くか見てみたかっただけだったので、まだ作っていない。
本格的に良さそうならば作っても良いかも?
対照実験として Claude to Claude でやってみた。普通に良いが、コンテキストウィンドウが狭めだからやっぱり過去の前提を結構忘れたりする。やり直し指示もあまい。どっちかというと gemini のがプロジェクトマネージメントとしては良い指示を出す感じはする。でもあくまで主観。
(なかなかうまいシーンのスクリーンショットが撮れない)
Discussion