ai-sdlc-framework/ai-sdlc

解決する課題

AIエージェントは小さなグリーンフィールドプロジェクトでは優秀ですが、成熟したコードベースでは失敗します。READMEで引用されている研究によると、AIツールを使用する開発者は成熟したコードベースでは実際に19%遅くなり、リファクタリングは減少し、安定性は低下し、開発者のわずか3%しかAIの出力を信頼していません。根本的な原因は、コードが成長するにつれてエージェントの働き方を誰も統制していないことです。すべての決定が最悪の瞬間に、最も文脈の少ないアクターによって行われることになります。AI-SDLCは、負荷のかかる決定を事前に人間のオペレーターに移し、AIが明確に仕様化された契約を決定論的に実行できるようにすることで、これを逆転させます。

仕組み

AI-SDLCは、AIエージェントを構造で包む「ディシジョンエンジン」です。5つの柱があります。

1. Definition-of-Ready (DoR) ゲート — オペレーターが実際に決定していないタスクのディスパッチを拒否します。ディシジョンカタログは、影響度でランク付けされた未解決の質問を、推奨事項と反対意見とともに表示します。
2. セッション階層 — cli-hierarchy up はプランナー、ディスパッチセッション、最大5つのエグゼキューターを開始します。それぞれが独自のtmux内のClaude Codeセッションです。ディスパッチは依存関係グラフをたどり、承認されたタスクを、ステップ0-13パイプライン（開発エージェント→レビュアー→証明→PR）を実行する分離されたgit worktree内のエグゼキューターに渡します。
3. クロスハーネスレビュー — 異なるハーネス（例：Claude vs Codex）のレビュアーが変更を並行して検証します。DSSE証明にはharnessフィールドがあり、独立性が強制されます：Claudeが実装した場合、Claudeはレビュアーになれません。レビュアー間の結託は機械的に不可能です。
4. オペレーターサーフェス — オペレーターはcli-hierarchy（status、attach、brief、down）とディシジョンカタログを通じて作業し、タイピングではなく監視を行います。
5. 宣言的ガバナンス — Pipeline、Decision、AgentRole、QualityGate、AutonomyPolicy、AdapterBindingなどのリソースはJSON Schemaリソースとして存在します。品質ゲートはアドバイザリー→ソフトマンデートリー→ハードマンデートリーで実行され、コンプライアンス体制はEU AI法、NIST AI RMF、ISO 42001からデフォルトを導出します。

インストールはClaude Codeプラグインを介して行い、その後ai-sdlc init、ai-sdlc doctor、そして/ai-sdlc execute AISDLC-42のようなディスパッチを行います。このフレームワークはエージェント非依存です（Claude Code、Codex、Cursor、Copilot、Aider、またはOpenAI互換API）。

対象者

ソフトウェア開発にAIエージェントを使用したいが、ガバナンス、信頼性、説明責任が必要なチーム向けです。これは、オペレーターが「ディシジョンスチュワード」になるためのものです。未解決の質問を組み立て、解決し、パイプラインを監視します。一方、フレームワークはタイピングとゴム印を処理します。統制のないAIが品質と安定性の低下を引き起こす成熟したコードベースを対象としています。

ハイライト

• コストの非対称性 — 完全なコンテキストで事前に行われるオペレーターの決定は安価でほとんど正しいです。実行中のAIの決定は高価で、しばしば間違っています。
• DoRゲート — オペレーターが実際に決定するまでディスパッチを防ぎます。
• クロスハーネスレビュー — 構造上レビュアーの独立性を強制し、結託を不可能にします。
• DSSE証明 — すべての変更を封印し、マージはgovernance.allowMergeルールに従います。
• KubernetesスタイルのAPI成熟度 — JSONスキーマ、RFCプロセス、適合テストスイートを備えたv1alpha1仕様。
• 複数のSDK — TypeScript、Python、Go、およびClaude CodeプラグインとMCPサーバー。
• 宣言的ガバナンス — 品質ゲートとコンプライアンス体制（EU AI法、NIST AI RMF、ISO 42001）をリソースとして。