Antigravity CLI が Gemini CLI の後継として一本化されたとき、公式の説明で一つ気になった点があります。Antigravity CLI はデスクトップ版と同じエージェントハーネスを共有するため、コアエージェントの改善がどの利用面にも自動で反映される、という記述です。
これは便利な一方で、設計者の側からは新しい注意が要る変化でもあります。私自身、デスクトップで対話的に試したワークフローを CLI の定期実行に載せ替えることが多いので、「どこまで同じ挙動を期待してよいのか」を整理しておく必要がありました。ここでは、共有ハーネス時代に CLI・デスクトップ・SDK の挙動を揃えるための考え方をまとめます。
「同じハーネスを共有する」が意味すること
エージェントハーネスとは、ざっくり言えば「エージェントがどう考え、ツールをどう呼び、結果をどう判断するか」という中核の振る舞いです。これが CLI・デスクトップ・SDK で共通になる、というのが今回の変化の核心です。
つまり、デスクトップで観察したエージェントの判断の癖は、原則として CLI でも同じように現れます。逆に言えば、デスクトップで確認できた挙動を、ある程度は CLI の自動実行に持ち込めるということです。
ただし「原則として」が曲者です。共有されているのは中核の振る舞いであって、それを取り巻く環境までは同じではありません。ここを混同すると、デスクトップで動いたのに CLI では落ちる、という事態を招きます。
利点は「一箇所の改善が全面に効く」こと
共有ハーネスの最大の利点は、コアの改善がどの利用面にも自動で届くことです。以前のように「CLI だけ古い挙動のまま取り残される」という分岐が起きにくくなります。
私の運用でこれが効くのは、対話で詰めたプロンプトの組み立て方を、そのまま定期実行へ移すときです。デスクトップでエージェントの応答傾向を確かめ、その学びを CLI のスケジュールタスクに反映する。中核が共通なら、この移し替えの目減りが小さくなります。
学習と本番運用の面が違っても、土台が同じなら知見が無駄になりにくい。これは個人開発のように、試行と運用を一人で行き来する立場にはありがたい性質です。
注意は「どの面でも同じ前提でテストすると外す」こと
一方で、共有ハーネスを過信すると足をすくわれます。揃うのは中核の振る舞いだけで、入出力の経路・認証・実行環境は面ごとに異なるからです。
私が実際に踏んだ落とし穴を挙げます。デスクトップでは対話的に承認を求めてくる操作が、CLI の非対話実行では承認待ちのまま固まる。デスクトップではログイン済みのセッションが、CLI では認証トークンの期限切れで弾かれる。エージェントの判断は同じでも、それを動かす土台が違うために本番で止まる、という形です。
ですから「中核が同じだからどの面でも同じはず」というテストの省略は危険です。揃う部分は信頼し、揃わない部分は面ごとに確かめる対処を取る。この切り分けが、共有ハーネス時代のテスト設計の要になります。
面ごとに違うのは「環境」であって「エージェント」ではない
何が揃い、何が揃わないのかを整理しておくと、テストの的が絞れます。
この表の右側、つまり「面で異なる」行が、テストで重点的に見るべきところです。中核は共通という前提があるからこそ、検証の労力を環境差のある箇所に集中できます。
挙動を揃えるための設計
具体的な揃え方は2つです。一つは暗黙のデフォルトに頼らず明示的に指定すること。もう一つは面をまたいだスモークテストを持つことです。
明示指定は単純です。モデル名、対話モードの有無、出力形式といった、面によって既定値が違いそうな項目を、すべてコマンドや設定で明示します。デフォルトに任せると、面が変わった瞬間に既定値も変わり、挙動がずれます。
スモークテストは、同じ入力を各面に流して、最小限の同一性を確かめるものです。
# CLI とデスクトップ(ヘッドレス)で同じ最小タスクを流し、結果の骨格を比べる
TASK="content/_fixtures/smoke_task.json"
# 非対話・無人を明示して固まりを検出
agy run --non-interactive --no-prompt --task "$TASK" --out /tmp/smoke_cli.json
agy desktop --headless --task "$TASK" --out /tmp/smoke_desktop.json
# 成功フラグと生成キーの有無だけを比較(本文の完全一致は求めない)
for f in /tmp/smoke_cli.json /tmp/smoke_desktop.json; do
python3 -c "import json; d=json.load(open('$f')); print('ok' if d.get('status')=='success' and d.get('artifact') else 'FAIL', '$f')"
done
ここでも全文一致は求めません。見るのは、非対話で固まらずに完了したか、成果物の骨格が両面で同じ形かの2点だけです。中核は共有されているので、この最小限の確認が通れば、残りの細部は信頼してよいと判断しています。
バージョン追従を3手順で習慣化する
共有ハーネスでは、コアの改善が自動で全面に届きます。これは利点ですが、裏を返せば「自分が何も変えていないのに挙動が変わる」瞬間があるということです。私はこれに対して、次の3手順を運用に組み込むことを推奨します。
- スモークテストをスケジュール実行の前段に必ず挟む。コア更新で挙動が変わっても、本番の前に異常を検出できる
- 更新の節目で設定ファイルとデフォルトの差分を確認する。暗黙の既定値が変わっていないかを見る
- 挙動がずれたら、まず明示指定の漏れを疑う。デフォルト任せの項目が残っていないかを点検する
この3手順は、いずれも数分で終わる軽いものです。けれど自動で更新が降りてくる環境では、この小さな前段があるかないかで、朝に異常へ気づくか深夜に静かに失敗するかが分かれます。
更新そのものを止める必要はありません。共有ハーネスの利点はコアが新しくなり続けることなので、追従しない選択は機会損失です。止めるのではなく、変化を本番の前で受け止める仕組みを置く。これが、自動で更新が降りてくる時代の安全な付き合い方だと考えています。
CLI・デスクトップ・SDK が同じ土台を共有する流れは、おそらく今後さらに進みます。揃う中核を信頼して知見を行き来させ、揃わない環境差は面ごとに確かめ、変化はスモークテストで本番の手前で受け止める。この三つを習慣にしておけば、共有ハーネスは負担ではなく、一人で試行と運用を回す個人開発の心強い土台になります。同じように複数の利用面を行き来している方の参考になれば幸いです。