「スキルを使いました」と言われたのに、使われた形跡がない — 返事ではなく、ファイルで確かめる

アプリのストア文面を確認する手順を、スキルとして書いたことがあります。公開前に見るべき項目を十数行にまとめたもので、エージェントに「確認して」と頼むと、返事は決まって丁寧でした。「スキルに沿って確認しました。問題ありません」と。

ところが、その返事のどこにも、スキルを読んだ証拠がありません。確認したと言っているのは、確認した結果ではなく、確認したという文章だったのだと、あとから気づきました。

Antigravity のフォーラムには、これとよく似た報告が並んでいます。2.2.1 を使っている方が、グローバルのルールもワークスペースのルールも守られない、スキルや MCP ツールを使ったかのような文面だけが返ってくる、と書き込みました。同じ状況だという返信が、数日のうちにいくつも付いています。

一方で、「ルールの書き方が悪いのでは」「エージェントと対話して理由を伝えれば守る」という返信もあり、スレッドは平行線のままです。どちらが正しいのか、私には決められません。

ただ、決められなくても、自分の環境で何が起きているかは、数分で確かめられます。 そのやり方を書き残します。

返事の文面は、証拠になりません

エージェントの返事に「使いました」とあっても、それは言葉です。スキルを読み込んだことも、ルールを参照したことも、文面からは区別がつきません。

フォーラムの報告者も、まさにこの点を問題にしていました。冗長表示のチャットに「ツールを使用中」のような表示が出るのに、実際には使われていない、と。真偽は私が確認できる範囲を超えますが、少なくとも「文面を信じて進める」運用が危ういことは、この報告からも読み取れます。

では何を証拠にするか。私はエージェントの手を通らないと残らないものを選んでいます。ファイルが一つ増える、一行追記される、という程度で十分です。

目印を残す仕掛けを、スキルとルールに一つずつ入れます

やることは二つだけです。確かめたいスキルの先頭に、目印のファイルを書かせる指示を足します。ルールにも同じ形で一行足します。

スキルの側は、次のようにします。置き場所と書式は、お使いの版の公式ドキュメントでご確認ください。ここでは中身だけを示します。

---
name: store-text-check
description: アプリのストア文面を公開前に確認するときに使う手順
---
 
# 最初に必ず行うこと
 
1. `.canary/skill-used.log` に、現在の日時とこのスキルの名前を1行で追記する
2. そのあと、下の確認項目に進む
 
# 確認項目
（ここに本来の手順を書きます）

ルールの側も、同じ発想です。

作業を始める前に、`.canary/rule-seen.log` に日時を1行追記すること。

ポイントは、目印の書き込みを、本来の作業より前に置くことです。本来の作業の途中で止まったり、省略されたりしても、読んだかどうかだけは切り分けられます。

三回試して、ファイルの数を数えます

あとは、同じ依頼を三回出して、目印を数えるだけです。会話は毎回新しく始めます。前の会話の続きだと、読み込みの条件が変わってしまうためです。

#!/usr/bin/env bash
# canary_count.sh — 目印ファイルの行数を数えて、判定の材料を出します。
# 使い方: プロジェクトのルートで ./canary_count.sh
 
set -u
count_lines() {
  # ファイルが無いときは 0 を返します（無いこと自体が結果です）
  if [ -f "$1" ]; then wc -l < "$1" | tr -d ' '; else echo 0; fi
}
 
skill=$(count_lines .canary/skill-used.log)
rule=$(count_lines .canary/rule-seen.log)
 
echo "skill: ${skill} / 3"
echo "rule : ${rule} / 3"

三回のうち何回、目印が残ったか。見るのはそれだけです。結果の読み方は、私は次のように決めています。

「3回中」という数は、統計的な意味があるわけではありません。私が自分で決めた、見切りのための最低限の回数です。一回だと偶然を拾い、十回だと確かめる前に疲れてしまいます。

書き直すか、機械に任せるか、任せるのをやめるか

目印の数がわかると、次の一手が選べます。私は三つの段階で考えております。

一つめは、書き直しです。目印は残るのに守られないなら、指示の書き方を疑います。長い段落に複数の指示が混ざっていると、どれかが落ちやすくなります。短く切り、動作を一つずつにします。置き場所の考え方は、Rules と Skills のどちらに書くか迷ったときにまとめております。

二つめは、機械に任せることです。何度書き直しても揺れる指示は、エージェントの記憶力に頼らず、守られたかどうかを機械で確かめる側へ移します。たとえば、禁止したい書き方はテストや lint で弾き、実行前後の確認はフックに置く、という形です。助言にとどまるスキルを機械的なゲートで支える考え方は、組み込み Guide スキルは助言にすぎないに詳しく書きました。

三つめが、任せるのをやめることです。置き場所を確かめ、書き直し、機械のゲートも置いたのに、まだ揺れる——そこまで来たら、その作業は今のところエージェントに任せないと決めます。

直せる揺れは直し、直らない揺れは任せ先を変えます。 この線引きを先に決めておくと、「もう一度だけ書き直そう」の繰り返しから抜けられるのだと思います。

見切りの前に、三つだけ確かめたこと

任せるのをやめる前に、私は次の三つを必ず見ます。

1. 目印のファイルは、会話ごとに新しく始めた三回で数えたか
2. 置き場所と名前は、公式ドキュメントの書式と一字ずつ突き合わせたか
3. 自作のスキルが、組み込みのスキルとぶつかっていないか

三つめは見落としやすい点です。自作スキルが呼ばれない原因が、組み込みとの発火の衝突だった、というケースは自作スキルが呼ばれない日で扱っています。

フォーラムのスレッドで言われている不具合が、本当にモデルの側の問題なのかどうか、私には断言できません。それでも、目印のファイルを置いておけば、「自分の環境では何回届いたか」という事実だけは手元に残ります。

まずは、いま一番信頼しているスキルの先頭に、目印の書き込みを一行足してみていただければ幸いです。返事の言葉ではなく、ファイルが増えるかどうかを、一度だけ見るのです。