同じエージェントハーネスを共有する時代 — CLI・デスクトップ・SDK で挙動を揃える設計

Antigravity の CLI・デスクトップ・SDK が同じエージェントハーネスを共有するようになった今、面ごとに挙動が揃う前提と揃わない要因を切り分け、スモークテストとバージョン追従の手順で挙動を一致させる設計をまとめました。

antigravity³⁸⁰ cli⁴ sdk⁵ testing¹¹ architecture¹¹

✦ プレミアム記事

Antigravity CLI が Gemini CLI の後継として一本化されたとき、公式の説明で一つ気になった点があります。Antigravity CLI はデスクトップ版と同じエージェントハーネスを共有するため、コアエージェントの改善がどの利用面にも自動で反映される、という記述です。

これは便利な一方で、設計者の側からは新しい注意が要る変化でもあります。私自身、デスクトップで対話的に試したワークフローを CLI の定期実行に載せ替えることが多いので、「どこまで同じ挙動を期待してよいのか」を整理しておく必要がありました。ここでは、共有ハーネス時代に CLI・デスクトップ・SDK の挙動を揃えるための考え方をまとめます。

「同じハーネスを共有する」が意味すること

エージェントハーネスとは、ざっくり言えば「エージェントがどう考え、ツールをどう呼び、結果をどう判断するか」という中核の振る舞いです。これが CLI・デスクトップ・SDK で共通になる、というのが今回の変化の核心です。

つまり、デスクトップで観察したエージェントの判断の癖は、原則として CLI でも同じように現れます。逆に言えば、デスクトップで確認できた挙動を、ある程度は CLI の自動実行に持ち込めるということです。

ただし「原則として」が曲者です。共有されているのは中核の振る舞いであって、それを取り巻く環境までは同じではありません。ここを混同すると、デスクトップで動いたのに CLI では落ちる、という事態を招きます。

利点は「一箇所の改善が全面に効く」こと

共有ハーネスの最大の利点は、コアの改善がどの利用面にも自動で届くことです。以前のように「CLI だけ古い挙動のまま取り残される」という分岐が起きにくくなります。

私の運用でこれが効くのは、対話で詰めたプロンプトの組み立て方を、そのまま定期実行へ移すときです。デスクトップでエージェントの応答傾向を確かめ、その学びを CLI のスケジュールタスクに反映する。中核が共通なら、この移し替えの目減りが小さくなります。

学習と本番運用の面が違っても、土台が同じなら知見が無駄になりにくい。これは個人開発のように、試行と運用を一人で行き来する立場にはありがたい性質です。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦共有ハーネスで「揃う部分」と環境差で「揃わない部分」を切り分ける考え方

✦面をまたいで挙動の同一性を確かめる軽量スモークテストの作り方

✦コア改善が全面に自動反映される時代のバージョン追従を習慣化する3手順

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

注意は「どの面でも同じ前提でテストすると外す」こと

一方で、共有ハーネスを過信すると足をすくわれます。揃うのは中核の振る舞いだけで、入出力の経路・認証・実行環境は面ごとに異なるからです。

私が実際に踏んだ落とし穴を挙げます。デスクトップでは対話的に承認を求めてくる操作が、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 が同じ土台を共有する流れは、おそらく今後さらに進みます。揃う中核を信頼して知見を行き来させ、揃わない環境差は面ごとに確かめ、変化はスモークテストで本番の手前で受け止める。この三つを習慣にしておけば、共有ハーネスは負担ではなく、一人で試行と運用を回す個人開発の心強い土台になります。同じように複数の利用面を行き来している方の参考になれば幸いです。