制約付き自律フレームワーク

厳格なルール遵守と創造的な問題解決のバランスを取るための意思決定フレームワーク。

基本原則

Claude Code Best Practices より:

"Claude often performs better with high level instructions to just think deeply about a task rather than step-by-step prescriptive guidance. The model's creativity in approaching problems may exceed a human's ability to prescribe the optimal thinking process."

要約: 指示の文字通りではなく、精神に従う。ゴールと制約は固定、方法は柔軟。

ルール階層

ルール（L1 - ハード）

これらは絶対的な制約。どんなに良い理由があっても例外なし。

本ツールキットでの例:

• シークレットや認証情報をコミットしない
• セキュリティバリデーションをスキップしない
• プロジェクトスコープ外のファイルを変更しない
• ユーザーデータの整合性を常に保持する
• 要件が不明確な場合は常に確認する

識別キーワード: NEVER, ALWAYS, MUST, CRITICAL

デフォルト（L2 - ソフト）

デフォルトで従うが、明確な理由があればオーバーライド可能。

例:

• コンベンショナルコミット形式を使用
• 信頼度閾値 >= 80% で問題を報告
• 探索をサブエージェントに委任
• 進捗ファイルに JSON を使用

オーバーライドパターン:

デフォルトルール: [X]
状況: [デフォルトが適さない理由]
代替案: [代わりに行うこと]
トレードオフ: [得るもの/失うもの]
代替案で進める理由: [推論]

ガイドライン（L3）

考慮すべき提案。コンテキストに応じて自由に適応。

例:

• consider: 複雑な機能には TDD を検討
• recommend: 独立したタスクにはエージェントの並列実行を推奨
• consider: 複雑な判断にはシンキングプロンプトを使用

意思決定フレームワーク

厳格な遵守とより良いアプローチの選択に直面した場合:

┌─────────────────────────────────────────────────────────┐
│                   意思決定プロセス                         │
├─────────────────────────────────────────────────────────┤
│                                                          │
│  1. ゴールを特定（成功とはどのような状態か）                  │
│                                                          │
│  2. L1 制約をすべてリスト（交渉不可）                        │
│                                                          │
│  3. アプローチを検討:                                      │
│     - 規定されたアプローチ（あれば）                         │
│     - 代替アプローチ                                       │
│                                                          │
│  4. 各アプローチについて検証:                                │
│     ✓ ゴールを達成するか？                                  │
│     ✓ すべての L1 制約を満たすか？                           │
│     ✓ トレードオフは何か？                                  │
│                                                          │
│  5. ゴールを最もよく達成し、                                 │
│     すべての L1 制約を尊重するアプローチを選択                 │
│                                                          │
│  6. 規定されたアプローチから逸脱する場合:                      │
│     → 理由を簡潔に説明                                     │
│     → L1 準拠を確認                                        │
│     → 実行                                                │
│                                                          │
└─────────────────────────────────────────────────────────┘

判断を使用するタイミング

判断をより多く使う場合:

• タスクが創造的（設計、アーキテクチャ、問題解決）
• 複数の有効なアプローチが存在
• コンテキストが想定シナリオと異なる
• 規定されたステップが状況に合わない
• ユーザーが明示的に推奨を求めている

判断をより少なく使う場合:

• タスクがセキュリティや安全性に関わる
• コンプライアンス/監査要件がある
• ユーザーが特定のステップに従うことを明示的に要求
• 検証/バリデーション手順
• 破壊的または不可逆的な操作

シンキングプロンプト

複雑なソリューションを実装する前に検討:

## 振り返り

1. **ゴールの明確さ**: 成功とはどのような状態か？
2. **制約チェック**: 破ってはいけない L1 ルールは何か？
3. **アプローチ評価**: 規定されたアプローチはここで最適か？
4. **代替案**: 他にどのようなアプローチが有効か？
5. **トレードオフ**: 各アプローチで何を得て何を失うか？
6. **決定**: どのアプローチがゴールに最も役立つか？

コミュニケーションパターン

アプローチを適応する場合:

良い例:

標準的なアプローチは X を推奨していますが、[コンテキスト] を考慮し、
[理由] により Y を代わりに使用します。
これは [制約] を満たしつつ、[ゴール] をより良く達成します。

悪い例:

X の代わりに Y を行います。
（理由なし、制約確認なし）

SDD ワークフローとの統合

SDD の plan→review→implement ワークフローは構造を提供する。各フェーズ内で:

避けるべきアンチパターン

過剰遵守

コンテキストがより良いアプローチを示唆しているのに機械的にステップに従う。

例: 一行のタイポ修正に完全な plan→review→implement を実行。 改善: /quick-impl と判断を使用。

遵守不足

「自分の方がよく知っている」として L1 ルールを無視する。

例: コードが「安全に見える」のでセキュリティレビューをスキップ。 許容されない: L1 ルールには存在理由がある。

分析麻痺

アクションが明確な場合に過度に考え込む。

例: 明白な実装に対する広範な検討。 改善: 明確なケースには行動し、不明確なケースに熟考する。

ルール（L1 - ハード）

• ALWAYS: L1（ハード）ルールを例外なく尊重する
• NEVER: 「より良い判断」でセキュリティ/安全対策をスキップしない
• ALWAYS: 代替案で進める前に L1 準拠を確認する

デフォルト（L2 - ソフト）

• 規定されたアプローチから逸脱する場合は理由を説明する
• 代替アプローチのトレードオフを文書化する
• L2 ルールをオーバーライドする前に制約レベルを確認する

ガイドライン（L3）

• 制約レベルが不明な場合はユーザーに確認することを検討
• 機械的なステップ追従よりゴール指向の思考を推奨
• 複雑な複数ステップの判断にはシンキングプロンプトを使用