速いはずのモデルが遅いとき、疑うのはモデルではなく推論強度です

壁紙アプリの設定画面にある一文を書き換えたくて、エージェントに頼んだ日のことです。

置き換えるのは数語だけでした。それなのに返答が始まるまでに妙な間があり、開いてほしくないファイルの構造まで読み直している様子が見えました。

速いモデルに切り替えれば済む話だと思って、その場でモデルを変えました。手触りは、ほとんど変わりませんでした。

効いたのは、モデルではなく推論強度を一段下げたことでした。

最初にお伝えしたいのは、遅さの原因を探す順番です。推論強度、設定が効いている場所、推論とは関係のない重さ——この三つを順に切り分ければ、たいていはモデルを変える前に答えが出ます。後半には、判断を記録で直すための小さなシェル関数を載せています。8月に載せた最初の版には macOS の標準シェルで動かない穴がありましたので、11月に手元で確かめ直した版へ差し替えました。

推論強度が動かしているのは、答えの質ではなく考える量

Antigravity では、モデルごとに推論強度を選べます。エディタではモデルの選択と並べて、CLI では /effort というスラッシュコマンドで切り替えます。設定画面に並んでいるとつい「High にしておけば賢くなる」と読みたくなりますが、この項目が動かしているのは、答えを出す前にどれだけ検討に時間と資源を使うかです。

選べる段階の名前と、どのモデルで選べるかは版によって変わります。ここでは Low / Medium / High の三段階で書きますが、2026年11月時点の正確な一覧は、公式ドキュメントの Choose a model と /effort コマンド のページで、お使いの版と照らし合わせていただければ幸いです。

検討が要る作業では、その時間は投資になります。検討が要らない作業では、待ち時間とクレジットがそのまま目減りします。

先ほどの文言差し替えは後者でした。数語の置換に対して、エージェントは律儀に周辺の構造を確かめ直していたわけです。悪いのは設定であって、モデルでもエージェントでもありませんでした。

よくある誤解を三つ

一つ目は「High にすれば答えが正しくなる」という読み方です。推論強度が増やすのは検討の量で、渡された前提の正しさではありません。前提が間違っていれば、間違った前提の上で丁寧に考えた答えが返ってきます。

二つ目は「遅いならモデルが重い」という読み方です。冒頭の私がまさにそうでした。軽いモデルでも推論強度が高ければ待たされますし、切り替えた先のモデルに高い段階が設定されていれば、手触りは変わりません。

三つ目は「一度決めれば全部に効く」という読み方です。推論強度はモデルごとに、さらにエディタと CLI で別々に持たれています。どこか一か所を変えても、いま動いている作業に届いているとは限りません。この点は後半の切り分け表で扱います。

作業の性質で三段階を割り当てる

私は「難しさ」ではなく「答えが一意に決まるかどうか」で分けています。難しさで分けようとすると、自分が難しいと感じたかどうかという曖昧な基準になってしまうためです。

ふだんの依頼の多くは、実は一行目に入ります。ファイル内の変数名をそろえる、import の塊を整える、同じ文字列を三か所で差し替える——午後のうちに私が手放す作業の大半はこの種類です。既定が High のままなら、その一つひとつが使われない検討を抱えて走ることになります。

この表で迷うのは、たいてい真ん中の行です。「原因の見当がついている」と自分で言えるかどうかが分かれ目になります。言えないなら、それは実質的に三行目の作業です。

段階を選ぶ前に、ほかの手と比べておく

遅い、あるいは結果が物足りないと感じたとき、触れる場所は推論強度だけではありません。私が手元で使い分けている四つの手を並べます。

私の判断の一文はこうです。待たされているなら段階を下げ、外れているなら指示を直し、段階を上げるのはそれでも外れるときだけです。 モデルを変えるのは、この三つを試したあとにしています。

CLI でモデルを切り替えたときに既定まで変わってしまう点は、/model で一手になったモデル切り替えの注意点に書き残しました。

迷ったら Medium に置いて、動かす理由を探す

最初から High に固定するのは、上げる余地を自分で捨てる選び方です。私は Medium を既定にして、そこから動かす理由が見つかったときだけ変えるようにしています。

個人開発では、待たされた時間はそのまま自分の作業時間から引かれます。レビューしてくれる同僚がいない分、手が空いた瞬間に次の判断を置けるかどうかが、その日の進み方を決めてしまいます。

下げる理由として分かりやすいのは、待ち時間が作業のリズムを壊しているときです。依頼が一文で書き切れてしまう作業は、たいてい Low で足ります。

上げる理由は、差し戻しが二回続いたときです。一度目は指示の書き方が悪かった可能性がありますが、二度続いたなら、こちらの説明ではなく検討の量が足りていない見込みが高くなります。

判断の順序として、私は「指示を書き直す」を先に置いています。推論強度を上げれば曖昧な指示が通るわけではないからです。

変えても速くならないときの切り分け表

段階を下げたのに手触りが変わらない場合、原因は別のところにあります。私が確かめている順に並べました。

二行目のエディタと CLI の違いについては、タスク種別ごとに /effort を振り分けた記録に実運用の集計を載せています。三行目の推論以外の重さは、動作が遅いときの切り分けの手順が使えます。

表のどれにも当てはまらないときは、推測をやめて比べ方を決めます。固定の文字列を差し替えるような小さな依頼を一つ選び、段階だけを変えて二回続けて流します。ほかの条件が動かない分、別々の作業から集めた一週間分の印象より、続けて流した二回のほうが多くを教えてくれます。

自分の判断を、記憶ではなく記録で直す

「この作業は Medium で足りた」という感覚は、翌週にはきれいに消えています。私は判断の材料を残すために、コマンドを包む小さな関数を使っています。

最初の版で踏んだ二つの穴

8月にここへ載せた最初の版は、bash で書き、bash でしか試していませんでした。11月に zsh で読み込み直したところ、一度も記録されないまま止まりました。macOS の標準シェルは zsh ですので、多くの方の手元で同じことが起きていたかもしれません。

前者は致命的でした。関数が途中で止まるので記録が残らないだけでなく、包んだ agy 自体が動きません。bash で試しただけで「動きます」と書いていた、私の確認不足です。

それ以来、載せるシェル関数は、読んでくださる方がいちばん使っていそうなシェルで一度読み込んでから出すことにしています。

確かめ直した版

段階の書き間違い（hgih など）を入口で弾き、大文字の Medium は小文字にそろえ、ラベルのタブと改行は空白に置き換えるようにしました。終了コードを受ける変数は rc に変えています。

# ~/.zshrc または ~/.bashrc に置きます（zsh と bash の両方で動きます）
agy_run() {
  if [ "$#" -lt 3 ]; then
    echo "usage: agy_run <low|medium|high> <label> <command...>" >&2
    return 2
  fi
  local effort label t0 t1 rc
  effort=$(printf '%s' "$1" | tr '[:upper:]' '[:lower:]')
  case "$effort" in
    low|medium|high) ;;
    *) echo "agy_run: 段階は low / medium / high のどれかにしてください（受け取った値: $1）" >&2
       return 2 ;;
  esac
  label=$(printf '%s' "$2" | tr '\t\n' '  ')
  shift 2
  t0=$(date +%s)
  "$@"; rc=$?
  t1=$(date +%s)
  printf '%s\t%s\t%s\t%s\t%s\n' \
    "$(date +%Y-%m-%dT%H:%M:%S)" "$effort" "$label" "$((t1 - t0))" "$rc" \
    >> "${AGY_EFFORT_LOG:-$HOME/effort-log.tsv}"
  return "$rc"
}

使うときは、段階と作業のラベルを添えて包みます。例では、非対話で依頼を一回だけ流す -p を使っています。

agy_run medium "typo-fix" agy -p "設定画面の文言を差し替える"

ここで書く medium は記録のためのラベルで、関数が推論強度を切り替えるわけではありません。実際の段階は、CLI の /effort で先に合わせておきます。ラベルと実際の設定がずれると記録の意味がなくなりますので、段階を変えたらラベルも同じ語で書く、という一点だけは決めています。

なお、agy -p の出力をパイプやリダイレクトで受けると標準出力が空になる、という報告が公式リポジトリの issue #76 に上がっています。この関数は出力に手を加えませんが、agy_run ... | tee のように外側で受ける使い方をする場合は、お使いの版で一度確かめてください。

段階ごとに眺める

一週間分たまったら、段階ごとに集計します。High で失敗した作業のラベルも並べて出すようにしました。

awk -F'\t' '
  NF != 5 { bad++; next }
  { n[$2]++; s[$2] += $4
    if ($5 != 0) { f[$2]++; if ($2 == "high") hf[$3]++ } }
  END {
    split("low medium high", order, " ")
    for (i = 1; i <= 3; i++) { k = order[i]; if (!(k in n)) continue
      printf "%-7s %3d件  平均 %5.1f 秒  失敗 %d\n", k, n[k], s[k] / n[k], f[k] + 0 }
    for (l in hf) printf "  high で失敗: %s ×%d\n", l, hf[l]
    if (bad) printf "  列数が合わない行: %d（読み飛ばしました）\n", bad
  }' "${AGY_EFFORT_LOG:-$HOME/effort-log.tsv}"

Ubuntu 24.04 の上で、zsh 5.9 と bash 5.2 の両方から読み込んで確かめました。agy の代わりに sleep と false を包み、成功（ラベルにタブ入り・段階は大文字の Low）、成功、失敗、段階の書き間違い、引数不足の五通りを流したあと、最初の版で書いたような列数の合わない行を一行混ぜて集計した結果がこちらです。

low       1件  平均   1.0 秒  失敗 0
medium    1件  平均   2.0 秒  失敗 0
high      1件  平均   0.0 秒  失敗 1
  high で失敗: migrate-billing ×1
  列数が合わない行: 1（読み飛ばしました）

段階の書き間違いと引数不足は記録されず、終了コード 2 で返ります。タブ入りのラベルは空白に置き換わり、成功として数えられています。

見たいのは平均時間そのものではなく、High にしていたのに失敗している行です。そこは推論強度で解決していない領域なので、指示の書き方か、渡している文脈のほうを直す番になります。

自分が「難しそうな作業」を High と読み替えていたのだと気づいたのは、記録を取り始めて二週間ほど経ったころでした。実際には、難しさよりも指示の曖昧さのほうが結果を左右していました。

次に詰まる一歩

記録が二週間ほどたまると、次に気になるのは、毎回ラベルを手で書く面倒さだと思います。私も同じところで手が止まりました。依頼文の言葉から段階を決めて CLI に渡す仕組みと、6週間分の集計は、先に挙げた /effort の振り分けの記録にまとめています。

もう一つは費用です。推論強度を上げると、待ち時間だけでなく思考に使われるトークンも増えます。Gemini 4 Carbon を常用している場合は、1回の作業代を思考レベルとキャッシュ率から見積もる手順を Carbon の作業代の見積もりに書きました。段階を上げる前に一度だけ計算しておくと、上げる判断に重みが出ます。

いま私が使っている既定値

Medium を既定に置き、Low を使う場面を三つだけ決めています。文言の置換、フォーマット整形、依存の並べ替えです。High は週に数回、移行作業か再現条件の分からない不具合のときだけです。

この配分が正解だと言うつもりはありません。扱っているコードの性質で変わるはずですし、私自身、記録を見ながら少しずつ動かしています。

まず一つだけ試すなら、直近に頼んだ作業を思い出して、それが最初の表のどの行に当たるかを確かめてみてください。一行目の作業を High で流していたなら、そこが最初に削れる待ち時間です。

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