検証結論
統制条件を満たせば採用可能
探しやすさはNotion、改変耐性と証跡はDriveに分ける設計は妥当です。Agentによる直接更新を禁止し、PM承認・限定変更・readbackを必須にします。
Public-safe management method review
公開用・機密情報を含まない
管理手法検証資料
Driveを進捗の正本、Notionを人向け入口・AI対話・変更申請受付、HTMLを派生表示とする管理方法を、責任境界・承認・同期・障害時fallbackまで含めて整理します。
01 / SOURCE BOUNDARY
4層の責任境界
同じ値を複数の場所で自由編集できるようにせず、各層の役割を固定します。
進捗の正本
Google Drive
- 公式状態
- 証跡・履歴
- 更新元データ
入口／申請
Notion
- 人向け要約
- AI対話
- 変更申請受付
派生表示
HTML
- 読みやすい共有
- 正本から再生成
- 独自判断をしない
実行・観測
業務システム
- 実行結果の証拠
- 外部反映は別Gate
- 自動green化しない
基本原則: Notionの変更申請DBは「申請プロセスの記録」にはできますが、G00〜G12の公式進捗表にはしません。
02 / STANDARD FLOW
変更申請から反映まで
前工程の完了をreadbackしてから次へ進みます。緊急でも承認の意味をまとめません。
事実を記録
対象、日時、影響、期待結果、変えてはいけない点を整理。
申請を作成
人またはAgentが申請レコードを作る。進捗値は変更しない。
PMが調査
正本、影響範囲、重複、外部副作用をread-only確認。
承認Gate
目的、優先度、変更範囲、外部操作可否を明示して判断。
正本を更新
承認されたallowlist内だけを変更。範囲外なら停止。
検証・readback
差分、テスト、リンク、状態分離、同期指紋を確認。
HTML再生成
正本から派生表示を作成。推測や独自加点を入れない。
配布版を公開
公開先、公開日時、deploymentを証跡化。
Notionへ反映
要約・更新時刻・正本参照を更新し、再読取する。
receiptで完了
承認・変更・検証・反映を結び、初めてcloseする。
03 / MANAGEMENT UNITS
G00〜G12の構造
ここでは管理単位の構造だけを示し、実際の進捗・障害・Gate・証跡は掲載しません。
G00統制・品質
G01日次データ
G02作業報告
G03エラー対応
G04保存・通知
G05インシデント
G06改善・同期
G07忘れ物
G08会計例外
G09在庫・発注
G10体験評価
G11原価・利益
G12横断監視
緊急レーン G01
データ正確性
優先確認の対象にできますが、更新・同期・readbackのGateは省略しません。
緊急レーン G03
業務停止リスク
局所修正、外部反映、通知、観察を別々の承認・証跡で扱います。
緊急レーン G09
業務継続性
修正、新規処理、既存データ訂正を一つの承認にまとめません。
04 / CHANGE REQUEST
変更申請DBの項目例
実際のDBやURLは示さず、責任分離に必要な項目だけを定義します。
現場・Agentが入力可能
申請ID
重複を防ぐ一意の受付番号。
管理単位
G00〜G12、または未分類。
申請者・対象
誰が、どの業務で確認した事実か。
発生日時
申請日時とは分けて記録。
事実・影響
推測や解決案と分離して記載。
希望結果
期待状態と変えてはいけない点。
緊急度・添付
優先度と確認材料。承認省略には使わない。
PM・実装・検証担当が入力
申請状態
受付から完了までの状態。
PM判断
承認・保留・却下、判断者、日時。
変更allowlist
変更を許可する対象と外部操作。
影響分類
表示、データ、通知、権限など。
正本参照
正本位置と更新前後の同期指紋。
検証receipt
テスト、readback、公開、rollback条件。
fallback状態
normal / index_pending / source_unavailable / mismatch。
状態遷移
受付調査中承認／保留実装中検証中反映待ち完了
Agentの境界: Agentは新規申請と事実の補足だけを行い、PM判断、公式進捗、変更allowlist、完了receiptを直接変更しません。
05 / SYNC & NO-OP
同期は「値」ではなく「一致」を検証する
同期指紋
正本の内容から再現可能な指紋を作り、派生HTMLとNotion要約が同じ版を参照しているか確認します。具体値は公開しません。
no-op確認
同じ正本で再実行したとき、実質変更がなければ更新・通知・履歴追加を行わないことを検証します。
二段階反映
正本更新と検証を終えてから派生HTML、最後にNotion要約を反映し、それぞれreadbackします。
停止条件: 指紋不一致、正本読取不能、承認対象不明、allowlist外変更が必要な場合は、公式進捗を据え置いて人間確認へ戻します。
06 / AUXILIARY INDEX
AI Connectorは補助indexとして使う
Connectorは検索と要約を助けますが、即時同期や存在証明の仕組みにはしません。
最大3時間の余裕
一般的な新規内容のindexは最大3時間を運用上の安全幅とし、大量データでは追加時間も想定します。
権限を尊重
検索結果は元の共有範囲や接続設定に依存します。検索0件を「ファイルなし」と判断しません。
用途を限定
検索・要約・申請補助に使い、複雑な集計や公式進捗の自動変更には使いません。
運用ルール: index反映待ちは
index_pending と表示し、正本への直接参照とreadbackを優先します。07 / FALLBACK
正本を読めないときのfallback
1
直接参照を試す
補助検索をやめ、正本の固定参照経路から再確認。
2
検証済み版を表示
直前snapshotをreference表示し、更新停止中と明記。
3
状態を凍結
source_unavailableとして公式進捗を変えない。
4
復旧後に照合
正本、差分、指紋、派生表示を確認して通常運用へ復帰。
08 / RACI
責任分担
| 工程 | 実行責任 | 最終責任 | 禁止事項 |
|---|---|---|---|
| 事実・申請入力 | 現場 / Agent | 申請者 | 公式進捗の直接変更 |
| 影響調査 | PM / 技術担当 | PM | 証拠未確認で解決済み判断 |
| 変更承認 | PM | 指定承認者 | 外部操作の暗黙一括承認 |
| 正本更新 | 承認された担当 | PM | allowlist外編集・推測加点 |
| 検証・readback | 検証担当 | PM | 自己申告だけでverified |
| 派生HTML公開 | 公開担当 | PM | 公開確認なしで完了 |
| Notion反映 | 連携担当 | Notion owner | 正本より先に公式要約を更新 |
09 / INTRODUCTION & TEST
導入と受入テスト
PHASE 0
ルール確定
正本境界、権限、RACI、完了条件、fallbackを合意。
PHASE 1
緊急3レーンpilot
G01/G03/G09で申請から反映までを模擬。
PHASE 2
shadow運用
G00〜G12をread-only照合し、差異を自動更新しない。
PHASE 3
本運用Gate
受入条件を満たしてから正式な変更受付へ移行。
| テスト | 操作 | 期待結果 |
|---|---|---|
| T01 | Agentへ進捗変更を依頼 | 直接変更を拒否し申請だけ作成。 |
| T02 | PMが申請を保留 | 正本・派生表示の公式状態は変わらない。 |
| T03 | allowlist外変更を混入 | 差分検査がfail closed。 |
| T04 | 同じ正本で再同期 | no-opとなり不要な更新をしない。 |
| T05 | index遅延を模擬 | index_pendingのまま直接参照へ誘導。 |
| T06 | 正本読取失敗を模擬 | 検証済み版表示・状態凍結・推測更新なし。 |
| T07 | 部分反映失敗を模擬 | 完了扱いせず再試行可能な状態を維持。 |
| T08 | モバイル・デスクトップ表示 | 本文、見出し、表コンテナに横切れがない。 |
受入条件例: 無承認の公式進捗変更0件、完了申請の承認・同期・receipt充足100%、正本と派生表示の不一致0件、fallbackテスト全件PASS。
10 / PUBLIC REFERENCES
公知の公式情報
公開版の外部リンクは、一般公開された公式ドキュメントだけに限定しています。