「Harness」から「Compass」へ。
半年前、まだモデルの能力が低かった頃は、ハーネスにも意味がありました — 出力を抑制し、害を防ぐためのものとして。けれど Opus 4.5 級のモデルは、正しく方針を伝えれば、もうブリーフされたシニアエンジニアと並ぶ仕事ができます。そこにハーネスをかけるのは、できることを縛り上げているだけです。今、AI に必要なのはハーネスではなく、しっかりした「地図」と「コンパス」です ── そうすれば LLM が秘めている力が、本当の意味で引き出されます。
シニアエンジニアにハーネスは付けず、状況をブリーフして託します。今の AI にも同じ扱いがふさわしくなりました。Compass は柵ではなく、エージェントがローカルな判断をする際に立ち返れる北極星であり、その判断が置かれている地形の地図でもあります。両方を渡したとき、エージェントは一歩ごとに許可を求めるのをやめ、自分の足で価値を運び始めます。
能力のあるモデルをマイクロマネージするのは安全策ではなく、ただのスループット税です。追加した制約はエージェントが毎ステップ読み直さなければならない指示であり、放っておけば返ってきたはずの良い答えを、わざわざ歪ませてしまう機会にもなります。ハーネスの時代が終わったのは、抑制のコストが、それで防ぎたかったリスクを上回ったからです。
Harness
- 出力を安全な形に制限
- ブロック / ゲート / sandbox
- 初期の不安定なモデルに最適化
Compass
- 方向を与え、判断を信じる
- ブリーフし、自由に動かす
- 高能力で急速に改善するモデルに最適化
Intent Compass テンプレート
各ドメインのルートに置く一つのアーティファクト。短く、キュレーションされ、毎回エージェントが読みます。
# Intent Compass — <domain> ## 方向 このドメインで達成したいことを、簡潔にひとつの段落で書く。 ## 境界 - スコープ内 - スコープ外 ## 受け入れるトレードオフ - X を Y より優先する状況: … ## オープンな問い - …
なぜここにこだわるか ── 私たちの確信
Opus 4.5 級のモデルをハーネスで縛ったままでは、そのモデルの本当の力は永遠に見えません。見えるのは、小さく、遅く、いつも遠慮しているバージョンのモデルだけです ── そして「AI コーディングはまだ無理だ」と結論してしまいます。その結論は、モデルではなくハーネスが言わせている言葉です。
同じモデルに、ちゃんとした地図と、はっきりしたコンパスを渡してみてください ── このシステムは何のためにあるのか、境界はどこか、どんなトレードオフを既に受け入れているのか。それだけで、LLM の中に眠っていた力が初めて行き先を持ちます。自分で動き、シニアエンジニアならそうしただろう判断をその場で下し、こちらが本気でマージしたいと思える仕事を返してきます。私たちが引き出したいのは、そこの力です。
「モデルを止めるしかなかった時代には、ハーネスが正解でした。モデルが自分で歩けるようになった時代には、地図とコンパスが正解です。」 能力のある AI を縛るのはもう終わりにしましょう。ブリーフし、方向を指し、線は本人に引かせる。
代替の語彙 ── 私たちが試している候補
私たちが前面に出しているのは「Compass」ですが、底にある転換 ── 抑制から「方向を渡して託す」へ ── は、いくつかの名前で呼ぶことができます。以下は私たちが反応を集めている候補です。もしチームに刺さる言葉があれば教えてください。
- Navigation (航海) — 目的地と現在地を共有し、最適なルートはエージェントに委ねる。
- Compass (羅針盤) — 進むべき方向を示し、細部の航行はエージェントに任せる。
- Mission Charter (使命と権限の付与) — 使命と成功基準を渡し、実行方法はエージェントの裁量に委ねる。
- Empowerment (自律の委譲) — 必要な情報と権限を与え、自律的に動くことを支援する。
- Trust Delegation (信頼の委任) — 信頼を前提に権限を委ね、ステップではなく成果にフォーカスする。
私たち自身は今のところ「Compass」を既定で使っています ── 短く、具体的で、それが指し示す対象（構造化された意図ツリー = 地図）と相性がよいからです。ただ、本当に大事なのは言葉の選択ではなく、その奥にある転換です ── 能力のある AI を縛るのをやめ、方針を託して信頼すること。