Knowledge Work と Software Engineering、どちらのレイアウトで開くかを作業の中身で決める

ストアの説明文を五つの言語にそろえ直そうとしていた午後、Antigravity を再起動すると、見慣れない問いが画面に出ていました。「あなたの仕事に近いものはどれですか」——選択肢には Software Engineering や Knowledge Work が並んでいます。

翻訳の作業なのだから Knowledge Work だろうと、深く考えずに選びました。画面はすっきりし、エージェントの途中経過は一行に畳まれ、コマンドもふだんの言葉で説明されるようになりました。読みやすさは、はるかに上がったのです。

ところが作業の終わりに、エージェントが説明文の横にあった設定ファイルまで書き換えていたことに、私は気づくのが遅れました。差分の表示が隠れていたからです。壊れてはいませんでしたが、胃が少し痛くなる瞬間でした。

最初にお伝えしたいのは、どちらのレイアウトが優れているかではなく、その日の作業がファイルを書き換えるかどうかで選ぶという線引きです。

公式のリリースノートに書かれていること

Knowledge Work レイアウトは、2026年11月9日の v2.30.0 で入りました。公式の changelog には、次のように書かれています。

ここで覚えておきたいのは、隠れるのは「表示」であって、エージェントの権限ではない、という点です。レイアウトを変えても、エージェントがファイルを書き換えられることに変わりはありません。

なお、同じ v2.30.0 で、メッセージ欄で選ぶ権限プリセットは「その会話だけ」に効くようになりました（business と enterprise を除く）。レイアウトと権限は別々のつまみだと考えておくと、混乱が少なくなります。

二つのレイアウトを、作業の中身で比べる

私自身が個人開発の日々で Antigravity に頼む作業を棚卸しして、どちらで開くかを並べてみました。

表の真ん中の行が、私がつまずいた場所です。「翻訳」という言葉だけで Knowledge Work を選びましたが、実際には翻訳をファイルに書き込む作業でした。作業の名前ではなく、最後にファイルが変わるかどうかで選ぶべきだったのです。

隠れた変更を、自分の目で確かめる

それでも、調べ物のつもりで始めた会話が、途中でファイルの修正に変わることはあります。そのため私は、Knowledge Work で作業した日の終わりに、リポジトリの状態を一度だけ確かめるようにしております。

次のスクリプトは、作業を始める前の状態を記録し、終わったあとに「何が変わったか」だけを短く表示します。Git で管理しているフォルダであれば、そのまま使えます。

#!/usr/bin/env bash
# layout-check.sh — Knowledge Work で作業した前後の変化を確かめる
# 使い方: 作業前に「bash layout-check.sh start」、作業後に「bash layout-check.sh end」
set -euo pipefail
 
cd "$(git rev-parse --show-toplevel)"   # リポジトリの外で実行したらここで止まる
MARK=".git/layout-check-start"
 
case "${1:-}" in
  start)
    git rev-parse HEAD > "$MARK"
    git status --porcelain >> "$MARK"
    echo "開始時点を記録しました: $(head -1 "$MARK" | cut -c1-8)"
    ;;
  end)
    [ -f "$MARK" ] || { echo "先に start を実行してください"; exit 1; }
    START_HEAD=$(head -1 "$MARK")
    echo "== 開始後に増えたコミット =="
    git log --oneline "${START_HEAD}..HEAD" || true
    echo "== まだコミットされていない変更 =="
    git status --short
    echo "== 変更量（ファイルごと） =="
    git diff --stat "$START_HEAD"
    rm -f "$MARK"
    ;;
  *)
    echo "start か end を指定してください"; exit 1
    ;;
esac

git status --short だけでも足りそうに見えますが、エージェントが途中でコミットまで済ませていると、そこには何も出てきません。開始時点のコミットを控えておき、git log と git diff --stat で比べるのはそのためです。

記録用のファイルを .git の中に置いているのは、エージェントに見える作業ツリーを汚さないためです。ここに置いておけば、誤ってコミットされることもありません。

切り替えで迷ったときの三つの問い

レイアウトの切り替えは設定画面からいつでもできますので、迷ったら次の三つを順に考えます。

1. 今日の作業は、最後にファイルを書き換えますか。書き換えるなら Software Engineering です
2. 書き換えないつもりでも、途中で書き換えに変わりそうですか。変わりそうなら、作業の前に start を記録しておきます
3. 読みやすさのほうが大事な作業ですか。調べ物や文案づくりなら Knowledge Work のほうが、手が止まりにくくなります

一方で、business や enterprise のアカウントでは Knowledge Work レイアウト自体が使えません。お勤め先のアカウントと個人のアカウントを行き来している方は、画面の違いに驚かないよう、先に知っておくと安心です。

この「表示を減らす」設計が何を可能にするのかと考えると、エージェントに任せる範囲を、コードを読まない人にまで広げることなのだと思います。そのぶん、どこまで任せたかを確かめる手段を、自分の側に一つ持っておく必要が出てくるのでしょう。

結びに

読みやすさはレイアウトに、確かめる責任は自分に。 レイアウトを選ぶのは見た目の好みではなく、その日にどこまで目を配るかの宣言なのだと、いまは感じています。

まずは次に Knowledge Work で作業するとき、会話を始める前に start を一度だけ記録してみていただければと思います。終わったあとの数行が、何も変わっていないことを確かめさせてくれるはずです。