dev-agent-teamシリーズの11本目。 前回（判断を上流に集約する）で、 モデルとeffortの層別配分を型にした。 今回は、Anthropic公式のプロンプトガイドが、その型を外から追認していたという話。
- 公式Fable 5ガイドを取り込んだが、多くは既存の型の「裏打ち」だった
- 公式の「人間確認が要る3類型」は、キットのHuman Decision Pointの定義と一致
- ゲート（禁止・停止条件）は列挙を維持し、行動手順のマイクロ指示は簡潔化する
Anthropicから
Claude Fable 5のプロンプティングガイド
が出た。新しいモデル世代に向けた公式の指針だ。
この改善（PR #26）は、それを
docs/native-tooling-integration.md の §7 として取り込んだ記録になる。
ただし今回のトーンは、これまでの「新機能を選り分ける」とは少し違う。 読んでいて何度も感じたのは、「これ、うちの型ともう合っている」だった。 公式ガイドは新しい制約を持ち込むというより、 このシリーズで積み上げてきた設計を外から裏打ちしてくれるものが多かった。
1. 公式パターンがキットの型を裏打ちする
§7.1では、公式の推奨とキットの既存概念の対応表を作った。 綺麗に噛み合ったのが次の3つだ。
公式ガイドが言うこと
- 確認が要る3類型：破壊的・不可逆な操作／真のスコープ変更／本人にしか出せない入力
- 独立した検証サブエージェント ＞ 自己批評
- one-lesson-per-file のメモリ運用
キットが元々持っていたもの
- Human Decision Point の定義そのもの
- Phase 7 の多層レビュー（敵対的verify）の根拠
- Known Risks の振り返り運用と同型
特に「人間の確認が要る3類型」—— 破壊的・不可逆な操作、真のスコープ変更、本人にしか出せない入力——は、 このシリーズがずっと「ここは人間が判断する」と言い続けてきた Human Decision Pointの定義と、ほぼそのまま一致していた。
「独立した検証サブエージェント ＞ 自己批評」も大きい。 AIに自分の仕事を自分で批評させるより、別のエージェントに敵対的に検証させたほうが効く—— これはPhase 7の多層レビューでやってきたことで、 公式がその優劣を明言してくれたことになる。
外部の権威が型を追認してくれると、「自分の設計は独りよがりではなかった」と確認できる。新機能の取り込みが"足し算"なら、今回の取り込みは"答え合わせ"に近い。
2. 指示粒度の世代適合——ゲートは残し、手順は削る
一方で、新しい世代ならではの線引きも1つ持ち込んだ（§7.2）。 公式ガイドは、「従来モデル向けに細かく書いたスキルは、Fable 5には細かすぎて、 かえって品質を落としうる」と指摘している。
これは重要な示唆だ。モデルが賢くなると、手取り足取りのマイクロ指示は 邪魔になることがある。ただし「全部を簡潔にすればいい」わけではない。 そこでキットとしての線引きをこう定めた。
列挙を維持する
- Stop Condition（どこで止まるか）
- Human Decision Point
- 禁止事項
簡潔化の候補
- 行動手順のマイクロ指示
- 賢いモデルなら省ける段取り
ゲート（止める・確認する・禁じる）は、世代が進んでも列挙をやめない。 ここを曖昧にすると、賢いモデルほど器用にすり抜ける。 逆に、行動手順の細かい段取りは簡潔化の候補にする。 これを将来のagents/skills監査の基準として残した。
3. 委任・長時間実行のプロンプトパターン
§7.3では、長時間の委任で効くパターンを整理した。 そしてこれらを、前回書いたeffort:low実装の成立条件に接続した。
- 証拠つき報告 — 「やった」ではなく、ツール結果と突き合わせて報告させる。前回の報告義務に接続。
- why の伝達 — 何をだけでなく、なぜを渡す。前回の自己完結した指示に接続。
- interval 検証 — 長い実行の途中で定期的に確かめる（Phase 5に任意で追加）。
- 長寿命サブエージェント＋非同期 — 長い作業は投げっぱなしにせず、非同期で回して受け取る形にする。
公式が挙げた委任パターンが、前回の層別配分の条件と綺麗に噛み合った。 「why を渡す」「証拠で報告させる」は、 実装層に判断させずに機械的に回すための、まさに前提条件だった。
4. 禁止——内部推論をエコーさせる指示
唯一「やってはいけない」として明記したのが§7.4だ。
公式ガイドは、モデルに自分の内部推論をそのまま出力させる（エコーさせる）指示が、
reasoning_extraction のrefusal（拒否）を誘発しうると警告している。
そこでキット内のドキュメントを grep で監査した。
結果は該当ゼロ——内部推論をエコーさせる指示は書いていなかった。
ただし線引きは明記した。
禁じられるのは「内部推論をそのまま吐かせる」指示だけ。成果物としての比較・根拠・トレードオフの提示（＝実装案A/B/Cとその理由）は問題ない。judgeやverifyが判断材料を出すのは、内部推論のエコーではなく、正当なdeliverableだ。
5. まとめ——足し算ではなく、答え合わせ
今回は新しい仕組みを足した回ではなく、 外部の公式ガイドと自作の型を突き合わせた回だった。
- 公式の「確認3類型」「独立検証＞自己批評」は、既存の型をそのまま裏打ちしていた
- 世代が進んでも、ゲート（停止・確認・禁止）の列挙はやめない。手順の段取りだけ簡潔化する
- 委任パターン（why伝達・証拠つき報告）は、前回の層別配分の成立条件と噛み合う
- 内部推論のエコーは禁止。ただし成果物としての根拠提示は正当
自分で考えて積み上げた型が、後から出てきた公式ガイドと重なっていた—— これはこのシリーズを続けてきて、いちばん手応えのある瞬間だった。 原則から設計すると、権威が後から追いついてくる。 新機能を追いかけるだけでなく、 自分の型を持っておくと、外の指針を"答え合わせ"として使えるようになる。
リポジトリはこちら: fecot/dev-agent-team