AIエージェントへ開発を任せると、二つの不満が交互に現れる。
止まらずに進みすぎると、意図と違う変更が積み上がる。
確認を増やすと、今度は一つひとつの操作で作業が止まる。
自走か確認かを一律に決めても、この問題は解けない。
モデルの能力、実行環境、作業の危険度がそれぞれ違うからである。
Hikizanは、途中の進め方ではなく、越えてはいけない下限と最後に残す成果物を揃えるために作った。
詳細な手順が能力を抑える
Agent Skillへ番号付きの手順を書けば、タスクの回し方が強くないモデルでも一定の順序で作業できる。
調査してから設計し、承認後に実装し、検証してPRを出す。
この順序は足場として機能する。
しかし、同じ手順をすべてのモデルへ強制すると、能力の高いモデルまで細かな儀式に付き合わせることになる。
すでに必要な調査を終えているのに探索をやり直したり、事実から決まる分岐を利用者へ質問したりする。
手順を増やせば安全になるとは限らない。
かといって、手順をすべて消せばよいわけでもない。
弱いモデルには足場が必要であり、強いモデルにも任せられない操作がある。
そこでHikizanは、制御を三つに分けた。
レール、opt-out、floors
一つ目は、Agent Skillに書いたレールである。
弱いモデルを基準に、番号付きの手順、停止条件、報告の型を用意する。
上から実行すれば、調査、設計、実装、レビュー、提出まで進められる。
二つ目は、能力の高いモデルに与えるopt-outである。
Hikizanのstandard tierでは、「手順は守らなくてよい。ただし出口は固定する」という前文をセッション開始時に渡す。
モデルは必要な手順だけを選び、状況に応じて順序を変えられる。
三つ目は、hooksによるfloorsである。
保護ブランチへのforce push、不可逆な削除、条件を満たさないPR作成など、入力から機械的に判定できる危険操作を止める。
floorsは、モデルがSkillを使わない経路にも作用する。
この三つは、モデルをどれだけ信頼するかという一本の目盛りではない。
レールは進み方を助け、opt-outは不要な手順を外し、floorsは能力に関係なく下限を守る。
hooksへ判断を移しすぎない
hooksで多くの操作を止めれば、安全性が上がるように見える。
実際には、判断を増やすほど誤検知も増え、エージェントは確認待ちになる。
Hikizanがfloorsへ置くのは、コマンド入力から決定論的に判定できる条件だけである。
設計案が妥当か、テストが十分か、文章が読みやすいかは、同じ方法では判定できない。
これらはSkillが判断材料と手順を渡し、モデルが文脈を読んで決める。
つまり、Skillは正常な経路を案内し、hooksは経路を外れたときにも越えてほしくない床を作る。
すべての判断をhooksへ移さないことが、自律性を残す条件になった。
最後に揃える六つの項目
途中の手順を自由にすると、何をしてきたのか追えなくなる懸念が残る。
そこでHikizanは、PR本文を六つの項目へ収束させる。
- 課題
- DoD
- 実装の流れとレビュー順
- 実装中に分かったこと
- 検証
- Workflow
Workflowには、探索、設計、実装、レビューで実際に行ったことと、自分で決めたことの根拠を残す。
どのモデルがどの順番で進めても、読む側は同じ場所から変更の経緯を追える。
これをHikizanでは出口契約と呼んでいる。
出口契約は、実装方法を統一する規則ではない。
レビューに必要な情報が、モデルの進め方によって欠落しないための成果物形式である。
commitはcheckpoint、PRは過程の正本
作業の経緯を残すなら、commit messageだけで十分にも思える。
しかし、commitは後からsquashされることがあり、細かく分けすぎると変更の意図より作業手順が前面に出る。
Hikizanでは、commitを独立して説明、検証、revertできる変更のcheckpointとして扱う。
ファイル単位や計画の一手順ごとには分けず、関連する検証が通った状態で保存する。
一方、実装中の判断とその根拠は、PRのWorkflow節へ残す。
途中のcommitが整理されても、なぜその変更になったのかはPRから読める。
commitには検証可能な変更単位を、PRには判断過程を残す。
この二つを合わせると、リポジトリは最新のコードだけでなく、変更をどう収束させたかも次のエージェントへ渡せる。
floorsは完全な境界ではない
Hikizanは、エージェントの判断が正しいことを保証しない。
hooksも完全なsecurity boundaryではなく、各ハーネスが渡すイベントと権限モデルに依存する補助guardrailである。
実際、Claude Code、Codex、Cursorでは、同じ危険操作でも確認要求と拒否の扱いが異なる。
そのため、Hikizanは「安全だから自由にしてよい」とは考えない。
決定論的に止められる操作はfloorsへ置き、実装の妥当性はテストとレビューで確かめ、最後に経緯を読める形で残す。
役割の違う仕組みを重ねることで、途中の自由度を上げても変更を追跡しやすくする。
自律か確認かを、セッション全体で一度だけ決める必要はない。
モデルが進め方を選び、危険な操作では仕組みが止め、最後は同じ出口へ戻る。
Hikizanが揃えたいのは作業手順ではなく、任せた仕事を後から理解し、必要なら戻せる状態である。