4. ハーネスを宣言的に管理する
ハーネスが増えると、ハーネス自体が問題になる
最初は、ルールやスクリプトを個別に追加しても問題ありません。
しかし、開発が進むと制御構造が増えます。
その結果、次の問題が起きます。
| 問題 | 例 |
|---|---|
| 形式がバラバラ | Markdown、YAML、Shell、JSONが散在する |
| 適用漏れ | エディタでは止まるがGitでは止まらない |
| 反映漏れ | ルールを書いたがHookに反映されていない |
| 不整合 | 同じルールの条件が場所によって違う |
| 横展開しにくい | 別プロジェクトへコピーすると壊れる |
| 検査しにくい | なぜそのルールがあるのかわからない |
つまり、AIを制御するためのハーネスが増えるほど、ハーネスそのものの統制が必要になります。
宣言的管理とは何か
宣言的管理とは、個別スクリプトを直接いじるのではなく、まず「あるべき状態」を定義し、そこから各環境向けの設定やHookを生成する考え方です。
DSLの役割
制御構造をまとめて定義するDSL（Domain Specific Language）は、AI駆動開発の「契約書」です。
| 関心事 | DSLで定義するもの |
|---|---|
| Who | どのエージェントが何をしてよいか |
| What | どの成果物があり、誰が所有するか |
| When | どの順番で作業するか |
| How | 何で検証するか |
| Guard | 何を守るか |
| Policy | どの強さで守るか |
| Where | どこで適用するか |
なぜ宣言的にするのか
1. 意図が見える
スクリプトのif文を読むより、YAMLで「何を守りたいか」が見えるほうがレビューしやすいです。
2. 一貫して生成できる
同じルールをエディタ HookとGit Hookに別々に手実装するとズレます。
DSLから生成すれば、同じ定義を複数の場所へ反映できます。
3. 段階導入できる
いきなりblockにすると開発が止まるルールは、まずshadowで記録だけします。
- shadow: ログだけ取る
- warn: 警告する
- block: 止める
4. ガバナンス対象になる
DSL自体をGit管理すれば、制御構造の変更もレビュー・差分確認・ロールバックできます。
結論
ハーネスエンジニアリングはAI開発の品質と安全性を上げます。
宣言的管理はハーネス自体のガバナンスを上げます。
この2つを組み合わせることで、AI駆動開発は個人芸から組織運用へ移行できます。