gists
12 Factor FASD の内容妥当性レポート
評価対象
対象文書:
index.md
（12 Factor FASD）
stakiran/12-factor-fasd: 12 Factor FASD(Fully Autonomous Software Development)
評価観点: 再現性、品質保証、スケーラビリティ、運用現実性、組織適合性
評価方法
ルートで codex を実行、gpt-5.3-codex で、以下プロンプト
12 factor fasd の内容の妥当性を論じて。report.md として出力して
総評
全体として、FASD の探索フェーズを加速するための思想としては有効。
とくに「要件の機械可読化」「ワークフロー明示」「コンテキスト管理」「高速フィードバック重視」は妥当性が高い。
一方で、いくつかの Factor は断定が強すぎ、一般化すると品質・安全性・組織運用で逆効果になる。
結論としては「探索段階向けの強い指針」として妥当だが、「本番適用の標準原則」としては修正が必要。
Factor 別評価
要件前提情報をプレーンテキスト化:
妥当
機械処理性と曖昧さ低減に有効。
ただし図表を完全否定せず、入力に使わないだけで補助資料としては許容が現実的。
要件を検証可能にする:
妥当
完了判定の客観化に必須。
BDD ライクな検証を要求する方向性は適切。
品質体系をプラガブル化:
妥当
文脈ごとに品質定義が異なる前提は正しい。
実装時は品質体系のバージョニングと監査証跡が必要。
コンポーネントをプラガブル化:
妥当
大規模一括生成の失敗率を下げる。
ただし過剰分割は統合コストを増やすため、境界定義ルールを先に固定すべき。
ワークフローを厳密設計可能にする:
妥当
再現性・デバッグ性・改善サイクルの基盤。
ステップ定義とデータ契約の明文化は必須。
エージェントを Composite 化:
条件付き妥当
インターフェース統一の利点は大きい。
ただし「オーケストレータ分離を否定」まで一般化すると責務分離や障害局所化が難しくなる。
LX 的解釈（人間が LLM 制約に適応）:
条件付き妥当
探索初期では有効。
ただし実運用ではユーザ価値（可用性・操作性・説明可能性）を下げない範囲で適用すべき。
ビジュアル排除:
要修正
「入力として機械可読化を優先」は妥当。
しかし図表の全面排除は設計レビュー効率を落とす。推奨は「内部表現は構造化テキスト、対人説明は図表可」。
コンテキスト超過前にアボート:
妥当
品質劣化の早期遮断として合理的。
併せて要約圧縮・階層化メモリ・リトリーバル併用を設計原則に含めるべき。
待ち時間をコーヒータイム未満にする:
条件付き妥当
反復速度重視は正しい。
ただし品質評価製品の一律否定は過剰。目的に応じて「高速ゲート」と「重厚ゲート」を段階分離する方が実務的。
オンボーディング自走化・ソロワーク重視:
要修正
自走性重視は有効。
ただしチームワークや Scrum の全面否定は再現性・属人性・責任分界でリスク。適切には「小規模自走 + 最小同期プロセス」。
非機能要件をベストエフォート扱い:
要修正
探索段階での割り切りとしては理解可能。
しかし本番を想定するなら性能・信頼性・セキュリティ検証は省略不可。負荷試験廃止の断定は不適切。
主要な論点（妥当性を分ける境界）
文書は「探索速度最適化」に極振りしており、その目的には整合している。
ただし「本番品質・法令順守・監査対応」を要求する文脈では、いくつかの断定が成立しない。
よって妥当性は二値ではなく、適用フェーズの明示で決まる。
改訂提案（実務適用しやすい形）
文書冒頭で適用範囲を明記する:
フェーズA: 探索（速度優先）
フェーズB: 準本番（速度と保証の均衡）
フェーズC: 本番（保証優先）
断定表現を段階化する:
「禁止」ではなく「探索では非推奨／本番では必須」などに分離。
最低限の安全ガードを追記する:
セキュリティ基準、監査ログ、重大障害時の人間介入条件（Kill Switch）。
最終結論
12 Factor FASD は、FASD 探索を駆動する戦略文書としては十分に妥当。
ただし現在の記述は探索特化であり、普遍原則として使うには 8/11/12 を中心に修正が必要。
推奨運用は「探索で強く使い、本番に近づくほどガバナンス要件を段階的に戻す」。