Status: Living guidance v0.1（採用手続きはPRのHuman C-4/mergeに従う。運用上の有効性は未検証） Owner: Maintainer / Human decision owner Recorded: 2026-10-10 Review: 実践からの重要な学びが出た時／月次の振り返りで必要性を確認 Nature: 価値観と意思決定のガイド。新しい実行契約、Gate、強制チェックリストではない。
自分たちの事実と経験から考え、一般的な知識や定石と照合する。車輪の再発明は避けるが、流行やベストプラクティスを無批判に導入しない。試し、学び、必要なら自分たちの前提も変える。
PlanGateで生まれた実装、失敗、成功、開発とアジャイルの知見は重要な資産。一方、その経験だけで正しさを保証しない。研究、標準、OSS、他チームの実践、批判的なレビューを参照し、異なる観点がぶつかった時こそ検証の機会とみなす。
ここでの「最適解」は普遍的なベストプラクティスではなく、現在の課題・制約・チーム・リスクの下で、価値とEvidenceが示す暫定的な選択である。将来の再評価を歓迎する。
私たちはアジャイルソフトウェア開発宣言（公式日本語版）の4つの価値を重視する。プロセスやツール、文書、契約、計画にも価値を認めながら、個人と対話、動くソフトウェア、顧客との協調、変化への対応をより重視する。
AIエージェントの実行可否は本書が決めず、現行のCore Contractと案件ごとの承認契約が決める。
AIエージェントやOSSの運用では、これを次のように適用する。以下は私たちの適用解釈であり、宣言の文言そのものではない。
| 宣言の価値 | PlanGateでの判断の方向 |
|---|---|
| 個人と対話 | AIの定型手順やツールの都合より、関係者の意図・文脈・対話を重視。人間の主体性を失わない |
| 動くソフトウェア | 文書だけで完了を主張せず、実際に動作・検証できる小さな成果、または運用上の確認可能な変化を優先 |
| 顧客との協調 | 初期仕様の字面に固執せず、価値・不確実性・変更理由を依頼者と確認する |
| 変化への対応 | 計画は重要な仮説。新しい事実を得たら見直す。ただし承認された境界の外に独断で進まない |
アジャイル宣言の背後にある原則の、短い間隔での価値提供、技術的卓越性、シンプルさ、自己組織化、定期的な振り返りも参考にする。宣言は思考の羅針盤であり、このファイルの一文を実装の通過条件に機械変換するものではない。
| 層 | 何を扱うか | 変更の姿勢 |
|---|---|---|
| Values / Principles | 対話、価値ある成果、協調、変化への対応、観測事実への誠実さ、学び続ける姿勢 | 日々の効率都合で軽々しく手放さない。原則間の緊張は明示し、価値の解釈は経験に照らして深める |
| Safety / Authority Invariants | 現行のC-3／C-3’承認分岐契約、C-4/mergeのHuman-owned最終判断、HO、秘匿情報、不可逆な危害の防止、証拠と判断の分離 | AIの自己判断・自動改善で緩和しない。変更が必要なら既存のHuman-owned方針策定・承認手続きで明示的に判断 |
| Policies / Decisions | 承認済みの対象範囲、役割と責務、品質・安全性・運用上の決定 | 証拠と責任者を明示し、所管する正本を変更して進化させる。基本方針だけで既存決定を上書きしない |
| Practices / Tools / Workflow | 手順、バッチサイズ、会議、レビュー方法、モデル、Skill/Agent、計測方法 | 仮説として小さく試し、Keep / Adapt / Revert / Defer を判断する |
| Evidence / History | 観測、実測、外部の出典、失敗、代替案、当時の判断根拠 | 履歴を都合よく改ざんしない。新しい評価は追記し、現行方針へのリンクを保つ |
「変えてはいけない」は価値を否定するような便宜的な変更をAIが勝手にしないという運用上の意味。人間の正式な方針変更まで永久に禁止する意味ではない。
次の二つを別の情報源として取り扱い、どちらかを最初から正解とみなさない。
対等に検討するとは、証拠の重みが同じという意味ではない。 出典の一次性・再現性・測定条件・対象の類似性・現在のリスクを見て重み付けする。社内の成功体験は他の条件での成功を保証せず、広く使われる手法も私たちの環境での成果を保証しない。両者が食い違う場合は、どちらかに即断せず、反証できる最小の実験を探す。
実際の検討では以下の順に問いを立てる。ただし必要な問いだけを使い、全項目の書面提出や長い事前審査は要求しない。
| 選択 | いつ選ぶか | 例 |
|---|---|---|
| Adopt（採用） | 条件が十分近く、現状に必要で、導入価値・安全性が確認できる | 実在する重複IssueのGitHub標準Duplicate機能 |
| Adapt（適応） | 原則は有効だが、私たちの役割・制約・承認境界に合わせた再設計が必要 | Agileの短いフィードバックを3〜5件のTriageバッチへ翻訳 |
| Transform（自分たちを変える） | 自分たちの前提・分業・評価指標が障害で、変革が価値を生む仮説がある | 「Open件数を減らせば成功」という見方を捨て、正しい判断・回復の質を測る |
| Defer / Reject（見送り） | 適合しない、必要性が薄い、危険または証拠不足。無理に導入しない | 新たなstale bot/強制Gateを、問題の実測なしに追加すること |
Adoptが上位、Deferが下位という序列ではない。 何もしないことも合理的な判断。Transformも変化そのものを目的化せず、小さな実験と人間の判断に支えられる。
Dual Track（Discovery / Deliveryの並走）と、Issue Triage / Process Evolutionという活動とその方法の改善は同じ意味ではない。Double-Loop Learningも、単にループが2つある状態ではなく、規範・目的・前提を問い直す学習を指す。
具体例と議論の経緯は PR #1548 の設計履歴および Issue #1503 を参照する。これは実装済みの組織制度の宣言ではなく、考え方を運用へ適用するためのガイド。
重要な知識の取り込みや方針変更では、Issue / PR / 既存のDecision Recordに最低限、次の材料を残せばよい。軽微な対応までテンプレートを強制しない。
Problem / observed facts:
External insight / original source / limits:
Fit & gap with our context:
Options: Adopt / Adapt / Transform / Defer (why):
Small experiment / evidence / stop & rollback:
Decision / owner / remaining unknowns:
Revisit trigger:
| 既存資産 | 既存の責務 | この方針が追加するもの |
|---|---|---|
| Core Contract / Project Rules | 実行契約、禁止事項、AIの承認・停止ルール | 上書きしない。価値判断を支援するだけ |
| Plan Design Principles | Planの最小十分設計、Evidence、検証可能性 | 原則を学び・採用・適応する際の考え方 |
| ai-loop V2 North Star | 自己進化の目標・安全境界・Evidence要件 | 改善候補を外部知識と照らし、過剰導入を防ぐ姿勢 |
| Product Philosophy | PlanGateの問題設定と公開思想 | 知識を取り入れる際の内部判断指針 |
| Issue Governance / #1503 | ラベル、Milestone、IssueとPRの管理 | Issue整理を小さな実験として改善する際の選択観点 |
| Decision-Ready Continuation Policy | Human判断前にAIが進められる範囲、Decision-Ready Handoff、停止境界 | この方針の運用への適用例。権限ルール・HOTL解禁を新設しない |
「OSSのIssueは古いものを自動Closeするのが効率的」という一般論があった場合:
この例は考え方の適用例であり、全Issueの棚卸しが完了したという実績ではない。
| 日付 | 何を追加・変えたか | 次に検証すること |
|---|---|---|
| 2026-10-10 | 初版。アジャイル宣言を基盤に、Local Evidence × External Knowledge、Adopt / Adapt / Transform / Defer、守る境界と進化する運用を区分 | #1503の小バッチや今後のPlan設計で、この判断ガイドが役立つか。説明負荷が増えすぎないか |
| 2026-10-10 | #1503の実践から、Humanへの判断依頼と許可済みの作業継続を分ける運用ガイドを別文書へ抽出 | 判断資料への追加質問・誤停止・安全性の実測。既存Gateの緩和はしない |