夜間にサイトの自動更新を回す前に、IDE 側で組み立てた変更を、チャット型エージェントのアプリを開いて最終確認に一本投げようとしました。ところがそのアプリには、先ほどまで IDE で交わしていたやり取りが何も残っていません。どのファイルをどういう意図で触ったのか、どの検証をまだ通していないのか。もう一度ゼロから説明し直すことになり、確認のはずが再説明で時間を溶かしてしまいました。
Antigravity 2.0 が VS Code 系の IDE と、チャット型のエージェント・インターフェースという2つのアプリに分かれたことで、この「片方で積み上げた文脈が、もう片方に無い」場面が日常的に起きるようになりました。2つのアプリはモデルもエージェントのハーネスも共有していますが、会話の履歴は別々です。個人開発で複数の作業を並行させていると、IDE で手を動かした流れをチャット側の使い捨てエージェントに検証だけ任せたい、という受け渡しが頻繁に発生します。そのたびに再説明していては、せっかくアプリを分けた意味が薄れてしまいます。
私自身がこの2週間ほど試して落ち着いたのは、会話履歴に引き継ぎを期待するのをやめて、リポジトリの中に1つの「引き継ぎブリーフ」ファイルを置き、両方のアプリにそれを読ませるという方針でした。地味ですが、アプリをまたいでも、翌朝に自分が見返しても、同じ1ファイルを見れば状況が分かる状態になります。
なぜ会話履歴に引き継ぎを期待してはいけないのか
2アプリ分離の設計そのものを責めるつもりはありません。IDE は「手を動かす場所」、チャット型エージェントは「タスクを投げて束ねる場所」と役割が違うので、履歴が独立しているのはむしろ自然です。問題は、私たちが無意識に「さっき話したこと」を前提に次の一手を投げてしまう癖のほうにあります。
会話履歴を引き継ぎの媒体にすると、3つの弱点が付いて回ります。第一に、履歴はアプリの内部にあり、リポジトリの外にあるので、レビューにも検証にも乗りません。第二に、履歴は時系列で長くなる一方なので、要点がノイズに埋もれます。第三に、翌日の自分やチャット側のエージェントにとって「今どこまで終わっていて、次に何をすべきか」が、長い履歴からは即座に読み取れません。
引き継ぎに必要なのは会話の全文ではなく、「現在地」と「次の一手」と「まだ通していない検証」の3点です。これを構造化して1ファイルに置けば、媒体がアプリの外に出て、両アプリから同じものを参照できます。
引き継ぎブリーフのスキーマ
私は .antigravity/handoff.md という決め打ちのパスに、機械可読な frontmatter と人間向けの本文を持つファイルを置いています。frontmatter は検証スクリプトが読み、本文はエージェントと自分が読む、という二層構造です。
---
task : "記事詳細ページのプレビュー切り出し位置を H2 数基準に変更"
updated_by : "ide" # ide | chat のどちらが最後に更新したか
updated_at : "2026-07-02T10:40:00+09:00"
status : "in_progress" # in_progress | ready_for_verify | done
branch : "feature/preview-cut"
touched :
- "src/app/[locale]/articles/[category]/[slug]/page.tsx"
- "src/lib/content.ts"
open_checks :
- "短い記事(H2 が 2 個)でも全文露出しないこと"
- "ペイウォール後に目次が 1 件に減らないこと"
handoff_to : "chat" # 次に作業を受け取る側
---
## 現在地
プレビューの切り出しを、固定の文字数スライスから H2 の出現位置基準に変えました。
2 番目以降の H2 の手前でカットする実装まで入っています。
## 次の一手
チャット側で、H2 が 2 個だけの短い記事を 1 本開き、
プレビューに本文全体が出ていないかを目視で確認してください。
## まだ渡していない前提
- ビルドは通していますが、実機の表示確認はまだです。
- content.ts の getArticleContent は変更していません。
ポイントは、open_checks と status を frontmatter 側(機械可読)にも置いていることです。本文だけだと、エージェントが親切に要約してしまって「未検証」が「検証済み」にすり替わることがあります。機械可読な配列にしておけば、後述のスクリプトが「未消化のチェックが残ったまま done になっていないか」を判定できます。
ブリーフの鮮度と整合を検証するスクリプト
ファイルを置くだけだと、必ず「更新し忘れたブリーフ」が生まれます。IDE でさらに手を入れたのに updated_at が古いまま、といった状態です。そこで、ブリーフが現在の作業と食い違っていないかを機械的に見るスクリプトを用意しました。Node で書いていますが、やっていることは単純です。
// scripts/check-handoff.mjs
import { readFileSync } from "node:fs" ;
import { execSync } from "node:child_process" ;
const raw = readFileSync ( ".antigravity/handoff.md" , "utf8" );
const fm = raw. match ( / ^ --- \n ( [\s\S] *? ) \n ---/ );
if ( ! fm) {
console. error ( "❌ handoff.md に frontmatter がありません" );
process. exit ( 1 );
}
// 最小限の YAML 読み取り(依存を増やさないため自前)
const meta = {};
let key = null ;
for ( const line of fm[ 1 ]. split ( " \n " )) {
const kv = line. match ( / ^ ( \w + ): \s * ( . * ) $ / );
const item = line. match ( / ^ \s * - \s * ( . * ) $ / );
if (kv) { key = kv[ 1 ]; meta[key] = kv[ 2 ] ? kv[ 2 ]. replace ( / ^ " | " $ / g , "" ) : []; }
else if (item && Array. isArray (meta[key])) meta[key]. push (item[ 1 ]. replace ( / ^ " | " $ / g , "" ));
}
const problems = [];
// (1) 鮮度: ブリーフの updated_at が、touched ファイルの最終変更より古くないか
const touched = Array. isArray (meta.touched) ? meta.touched : [];
const briefTime = new Date (meta.updated_at). getTime ();
for ( const f of touched) {
try {
const mtime = execSync ( `git log -1 --format=%cI -- "${ f }"` ). toString (). trim ();
if (mtime && new Date (mtime). getTime () > briefTime) {
problems. push ( `鮮度ずれ: ${ f } はブリーフ更新後に変更されています` );
}
} catch { /* 未コミットは別途 status で見る */ }
}
// (2) 整合: done なのに open_checks が残っていないか
const checks = Array. isArray (meta.open_checks) ? meta.open_checks : [];
if (meta.status === "done" && checks. length > 0 ) {
problems. push ( `未消化の検証が ${ checks . length } 件あるのに status が done です` );
}
// (3) 受け渡し先の明示
if (meta.status === "ready_for_verify" && ! meta.handoff_to) {
problems. push ( "検証待ちなのに handoff_to が空です" );
}
if (problems. length ) {
console. error ( "🛑 引き継ぎブリーフに問題があります:" );
for ( const p of problems) console. error ( " - " + p);
process. exit ( 1 );
}
console. log ( "✅ 引き継ぎブリーフは現在の作業と整合しています" );
このスクリプトは、touched に挙げたファイルの最後のコミット時刻とブリーフの updated_at を比べ、ブリーフが取り残されていないかを見ます。加えて、done なのに検証項目が残っている、という自己矛盾を弾きます。私はこれをコミット前フックとチャット側の受け取り時の両方で走らせています。実際に、content.ts を後から触ったのにブリーフを更新し忘れた、というズレを一度これに助けられました。
Guide スキルで「終わったらブリーフを更新する」を決定論に寄せる
6/26 の更新で入った組み込みの Guide スキルは、繰り返し発生する手順をエージェントに再現させるのに向いています。私はここに「作業を一区切りしたら handoff.md を更新し、check-handoff を通してから受け渡す」という手順を固定しました。エージェントの善意に任せず、毎回同じ順序を踏ませるための足場です。
# .antigravity/guides/handoff.md
name: handoff-brief
description: 作業を別のアプリ・別のエージェントに渡す前に必ず実行する引き継ぎ手順
steps:
- 変更したファイルを frontmatter の touched に反映する
- status を in_progress / ready_for_verify / done から選び直す
- まだ通していない検証を open_checks に列挙する(憶測で済ませない)
- updated_by と updated_at を現在の実行主体・時刻に更新する
- `node scripts/check-handoff.mjs` を実行し、✅ を確認してから受け渡す
Guide スキルはあくまで助言的に働くので、私はこれを「唯一のゲート」にはせず、最後の check-handoff.mjs を決定論的なバックストップとして必ず挟むようにしています。スキルが手順を促し、スクリプトが結果を保証する、という二段構えです。この分担にしてから、片側のアプリだけブリーフが進んで、もう片側が古いまま、という食い違いがほぼ消えました。
受け取る側で「鵜呑み」を避ける
チャット型エージェントにブリーフを読ませるときは、内容をそのまま信じさせない一言を添えています。ブリーフはあくまで「渡す側の主張」であって、事実の保証ではないからです。具体的には、受け取り時のプロンプトに次のような制約を置いています。
渡す側が書いた内容 受け取る側にさせる確認
touched に挙げたファイル 実際の diff を開き、ブリーフの意図と一致するか照合する
open_checks の各項目 1 項目ずつ再現し、結果を done か残すかで返す
status: ready_for_verify ビルド・型チェックを自分で走らせてから受理する
この「渡された前提を、受け取る側がもう一度足場から確かめる」形にしておくと、ブリーフが多少雑でも、検証の網で拾えます。逆に、ブリーフを完璧に書こうとして更新が重くなるより、要点だけ素早く書いて受け取り側で確かめるほうが、個人開発の速度には合っていました。私はこの場合、ブリーフの完成度を上げるよりも、受け取り側の検証を厚くすることをお勧めします。
運用で見えた落とし穴
2週間ほど回して、いくつか気づいたことがあります。いずれも本番運用に入ってから初めて表面化したもので、先に知っておくと回避のコストがほとんどかかりません。
ブリーフの粒度を欲張らない
1ファイルに複数タスクを詰めると、どの open_checks がどの作業のものか曖昧になります。私は1つの作業単位につき1ブリーフに割り切り、終わったら status: done にしてアーカイブ扱いにすることを推奨します。混在させたブリーフは、受け取り側のエージェントが検証対象を取り違える温床になります。
時刻はタイムゾーン付きで揃える
2つのアプリで時刻の基準がずれると updated_at の比較が狂い、鮮度チェックが本番で無言のまま素通りします。ブリーフの時刻は必ず ISO 8601 のタイムゾーン付き(+09:00)で書き、スクリプト側も git log のコミット時刻(%cI)と揃えました。素の時刻文字列で書くと、この鮮度チェックが無意味になります。
ブリーフは履歴の代わりではない
過去の全経緯を書き残そうとすると、結局のところ長い履歴を別の場所に作っているだけになります。今どこにいて次にどこへ行くか、という2点に絞ると、両アプリをまたぐ受け渡しがぐっと軽くなりました。ブリーフは「現在地の地図」だと割り切るのが、私の場合はいちばん続けやすい運用でした。
道具が IDE とチャットの2アプリに分かれたことを、私は「文脈を人間が明示的に置く場所ができた」と前向きに捉えています。まずは自分のリポジトリに .antigravity/handoff.md を1枚置き、check-handoff.mjs を1回通してみてください。アプリをまたぐ受け渡しが、再説明ではなく確認から始められるようになります。