強いモデルほど、ワークフローを軽くする

Anthropicが公開しているClaude Opus 5のプロンプティングガイドを読んだ。書かれている内容は、最近AIエージェントを使いながら感じていたこととほとんど相違がなかった。

完全なタスク仕様を最初に渡し、実行はモデルへ任せる。モデル自身が行う検証と重複する指示は削る。小さなタスクではサブエージェントを使わず、本当に独立した大きな仕事だけを委任する。以前のモデル向けに作ったハーネスの足場が過剰なら、品質を落とさずに外せる。

強いモデルをうまく動かすために手順を足すのではなく、モデルがすでにできることと重複する手順を引いていく。これは、Hikizanを作りながら辿り着いた方向と同じだった。

自律性だけでは使いやすくならない

ただし、Opus 5そのものについては、自律性の高さに対してマクロな視点が少し足りず、中途半端で使いにくいという印象もある。自分で進み続ける力は強いが、タスク全体をどう捉え、どこまでやるべきかという判断が噛み合わない場面がある。

これはベンチマーク上の評価ではなく、実際の作業へ入れたときの感覚である。

一方、GPT SolやClaude FableのようなSOTA級のモデルを使っていると、細かな手順を先回りして書く意味は急速に薄くなっている。モデルが自分で調査し、実装し、検証し、必要なら修正できるなら、人間が同じループをMarkdownで再実装する必要はない。

そのため、Hikizanもバージョン0.11で大幅に軽量化した。

現在の用途は、モデルの作業を細かく制御することではない。

一つは、goalコマンドを使った内側のループや、サンドボックス環境で自律性を高くしてゴールまで進めたいときに、どのような作業の雰囲気で動くかを最初に共有することである。

もう一つは、人間側のUXを整えることである。

Hikizanは現在、モデルを動かすプログラムというより、このような認知負荷と好みを調整するMarkdownの集まりに近い。

モデルがタスクを完了する能力と、人間が気持ちよく仕事を任せられることは別の問題である。能力が上がるほど、ハーネスの役割は実行手順から関係の調整へ移っていく。

最終的には、機械的に判定できるルールはhooksへ寄せるべきだと思っている。

「メタな視点で考える」「ゼロベースで見直す」のような促しをいつ渡すか、保護ブランチへどのようなGit操作を許すか、提出前にどの状態を確認するか。環境と操作から決められることは、モデルがSkillを選んだかどうかに依存させず、hooksで扱うほうが自然である。

ただし、現時点ではすべてを強制するより、越えてほしくない場所へ緩くガードレールを引く程度がよいと考えている。hooksは能力の代わりではなく、事故が起きやすい境界を目立たせる床として使う。

細かな判断まで機械的に止めると、強いモデルが持つ自律性を再びハーネス側で潰すことになる。

スクリプトで作業手順を機械的に制御する方法も、今はかなり筋が悪いと感じている。

現在のモデルには、用意された経路が目的達成の邪魔になると判断すれば、別の方法を探して回避できるだけの性能と自律性がある。すべての抜け道を塞ごうとすると、制御側が複雑になり、本来の仕事よりハーネスの保守に時間を使うことになる。

秘密情報や権限の境界のように、絶対に守る必要があるものは、文章ではなくサンドボックス、認可、hooksなどの仕組みで守るべきである。

そのうえで、作業上どうしても守ってほしいことは、命令をさらに強くするより、なぜ大切なのかを率直に書くほうが効くのではないかと思っている。

「この操作は禁止」とだけ書くのではなく、「この履歴は他の人の仕事でもあるので、消えると困る」「勝手に範囲を広げると、利用者が確認できなくなる」と理由を渡す。少し情に訴える文章のほうが、モデルが未知の状況でも意図を保ったまま判断しやすいかもしれない。

もちろん、情に訴える文章はセキュリティ境界にはならない。これは協働の作法を揃えるための話である。

Hikizanは、強いモデルへ正しい手順を教えるための仕組みから、モデルと人間の間にある摩擦を減らすための仕組みへ変わってきた。

作業を完了するための内側のループはモデルへ任せる。機械的に守る境界はhooksへ置く。Markdownには、人間側の認知負荷、好みの作法、判断に必要な理由を残す。

モデルの性能が上がるたびに機能を足すのではなく、モデルが自力でできるようになった部分を削る。最後に残るのは、仕事の進め方そのものではなく、人間が安心して任せ、結果を理解するためのインターフェースなのだと思う。