壁紙アプリの設定画面にある一文を書き換えたくて、エージェントに頼んだ日のことです。
置き換えるのは数語だけでした。それなのに返答が始まるまでに妙な間があり、開いてほしくないファイルの構造まで読み直している様子が見えました。
速いモデルに切り替えれば済む話だと思って、その場でモデルを変えました。手触りは、ほとんど変わりませんでした。
効いたのは、モデルではなく推論強度を一段下げたことでした。
推論強度が動かしているのは、答えの質ではなく考える量
Antigravity では、モデルごとに推論強度を Low / Medium / High から選べます。設定画面に並んでいるとつい「High にしておけば賢くなる」と読みたくなりますが、この項目が動かしているのは、答えを出す前にどれだけ検討に時間と資源を使うかです。
検討が要る作業では、その時間は投資になります。検討が要らない作業では、待ち時間とクレジットがそのまま目減りします。
先ほどの文言差し替えは後者でした。数語の置換に対して、エージェントは律儀に周辺の構造を確かめ直していたわけです。悪いのは設定であって、モデルでもエージェントでもありませんでした。
作業の性質で三段階を割り当てる
私は「難しさ」ではなく「答えが一意に決まるかどうか」で分けています。難しさで分けようとすると、自分が難しいと感じたかどうかという曖昧な基準になってしまうためです。
| 作業の例 | 向いている段階 | 理由 |
|---|---|---|
| 文言・定数の置換、フォーマット整形、import の並べ替え | Low | 正解が一つに決まっており、検討の余地がありません |
| 既存関数への小さな変更、テストの追加、原因の見当がついている不具合の修正 | Medium | 選択肢は複数ありますが、範囲が閉じています |
| 設計の分かれ道、再現条件の分からない不具合、複数ファイルにまたがる移行 | High | 前提を組み立てるところから始まり、途中の検討が結果を左右します |
この表で迷うのは、たいてい真ん中の行です。「原因の見当がついている」と自分で言えるかどうかが分かれ目になります。言えないなら、それは実質的に三行目の作業です。
迷ったら Medium に置いて、動かす理由を探す
最初から High に固定するのは、上げる余地を自分で捨てる選び方です。私は Medium を既定にして、そこから動かす理由が見つかったときだけ変えるようにしています。
個人開発では、待たされた時間はそのまま自分の作業時間から引かれます。レビューしてくれる同僚がいない分、手が空いた瞬間に次の判断を置けるかどうかが、その日の進み方を決めてしまいます。
下げる理由として分かりやすいのは、待ち時間が作業のリズムを壊しているときです。依頼が一文で書き切れてしまう作業は、たいてい Low で足ります。
上げる理由は、差し戻しが二回続いたときです。一度目は指示の書き方が悪かった可能性がありますが、二度続いたなら、こちらの説明ではなく検討の量が足りていない見込みが高くなります。
判断の順序として、私は「指示を書き直す」を先に置いています。推論強度を上げれば曖昧な指示が通るわけではないからです。
変えても速くならないときに疑うこと
段階を下げたのに手触りが変わらない場合、原因は別のところにあります。私が順番に確かめているのは次の三つです。
一つ目は、設定がモデル単位であることです。作業の途中でモデルを切り替えると、そのモデルに紐づいた別の値が効きます。「さっき下げたはずなのに」と感じたときは、たいていこれでした。
二つ目は、エディタと CLI が別々に設定を持っていることです。ターミナルから走らせている作業には、エディタ側の設定は届きません。CLI 側での振り分けについては、タスク種別ごとに /effort を振り分けた記録に実運用の集計を載せています。
三つ目は、遅さの原因が推論ではない場合です。ワークスペースのインデックス作成中や、大きな出力を含む会話を開いた直後は、推論強度と無関係に重くなります。この線引きは動作が遅いときの切り分けの手順が使えます。
自分の判断を、記憶ではなく記録で直す
「この作業は Medium で足りた」という感覚は、翌週にはきれいに消えています。私は判断の材料を残すために、コマンドを包む小さな関数を使っています。
# ~/.bashrc などに置いておく
agy_run() {
local effort="$1"; local label="$2"; shift 2
local start end status
start=$(date +%s)
"$@"; status=$?
end=$(date +%s)
printf '%s\t%s\t%s\t%s\t%s\n' \
"$(date +%FT%T)" "$effort" "$label" "$((end - start))" "$status" \
>> "${HOME}/effort-log.tsv"
return $status
}使うときは、段階と作業のラベルを添えて包むだけです。
agy_run medium "typo-fix" agy run "設定画面の文言を差し替える"一週間分たまったら、段階ごとに眺めます。
awk -F'\t' '{n[$2]++; s[$2]+=$4; if ($5 != 0) f[$2]++}
END {for (k in n) printf "%-8s %3d件 平均 %5.1f 秒 失敗 %d\n", k, n[k], s[k]/n[k], f[k]+0}' \
~/effort-log.tsv | sort出力はこの形になります。
high 1件 平均 2.0 秒 失敗 0
low 1件 平均 0.0 秒 失敗 1
medium 2件 平均 1.0 秒 失敗 0
見たいのは平均時間そのものではなく、High にしていたのに失敗している行です。そこは推論強度で解決していない領域なので、指示の書き方か、渡している文脈のほうを直す番になります。
記録を取り始めてから、自分が「難しそうな作業」を High と読み替えていたことに気づきました。実際には、難しさよりも指示の曖昧さのほうが結果を左右していました。
なお、エディタではなく SDK からモデルを呼んでいる場合は、思考トークンの消費そのものを見に行けます。その計測と、消費を抑えたまま精度を落とさない配分についてはthinking_level をタスク別に切り替えた記録にまとめました。踏んだ落とし穴まで含めて残してあります。
いま私が使っている既定値
Medium を既定に置き、Low を使う場面を三つだけ決めています。文言の置換、フォーマット整形、依存の並べ替えです。High は週に数回、移行作業か再現条件の分からない不具合のときだけです。
この配分が正解だと言うつもりはありません。扱っているコードの性質で変わるはずですし、私自身、記録を見ながら少しずつ動かしています。
まず一つだけ試すなら、直近に頼んだ作業を思い出して、それが表のどの行に当たるかを確かめてみてください。一行目の作業を High で流していたなら、そこが最初に削れる待ち時間です。
お読みいただきありがとうございました。