リリースできても、利用開始と継続稼働の責任を人間へ移す工程がない

[takemi-ohama]

何を見つけたか

development-workflow は、要求・設計・実装・検証・配布・リリース後テスト・振り返りまでを
AI エージェントが自律的に進める。しかし、配布した成果物を定常状態で使い続ける人へ、
必要な知識・権限・未解決事項・責任を渡す工程が無い。

ここでいう「使い続ける」には、少なくとも次の異なる立場がある。

立場	目的	例
利用・業務	ツールやアプリを使って、本来の仕事や目的を達成する	受発注、査定、記事作成、社内手続き
サービス継続	システムの正常性を監視し、障害時に復旧する	監視、アラート、バックアップ、障害対応
利用支援	利用者の質問・権限不足・操作上の問題を解決する	問い合わせ、FAQ、アカウント発行
保守	不具合・依存関係・セキュリティ・将来の変更を扱う	Issue 対応、更新、脆弱性修正
責任受諾	残余リスクと未解決事項を理解し、以後の判断主体になる	業務責任者、サービス責任者、保守責任者

同じ人が複数を担うこともあれば、配布物によっては存在しない立場もある。
パッケージや個人用ツールへ、組織的な業務運用やオンコールを一律に要求してはいけない。

現在の Skill の境界は次のようになっている。

Skill	確かめること
release	利用者が成果物を受け取れる状態になった
release-verification	配布された成果物が利用者の環境で受け入れ条件を満たした
retrospective	今回の進め方から次に変えることを残した

ここまで通っても、次は確定しない。

• 利用者が本来の仕事で使い始められるか
• 業務手順・データ移行・権限・教育が揃っているか
• 問い合わせを誰が受け、どこへ残すか
• 何を見ればシステムの正常・異常を判断できるか
• 障害時に誰が何を実行するか
• バックアップから実際に戻せるか
• 不具合やセキュリティ更新を誰が引き取るか
• それぞれの責任者が、既知の制約と残余リスクを受諾したか

「成果物が動くこと」「利用者が仕事に使えること」「システムを継続稼働できること」
「人間が責任を引き受けたこと」は別である。

直さないと何が起きるか

正常にリリースできても、業務で利用を開始できない。 アカウント、初期データ、操作手順、
従来手順からの切り替え、問い合わせ先のいずれかが欠けると、受け入れ条件を満たすアプリでも
実際の仕事には使われない。

最初の障害で人間が対応できない。 AI が利用した調査経路や復旧手順がセッション内にしか
残らず、サービス継続を担う人はログの場所から調べ直すことになる。

問い合わせと不具合が宙に浮く。 利用者、利用支援、保守の境界が決まっていないと、
操作上の問題と製品の不具合が互いに押し戻される。

文書を作っただけで責任を渡したことになる。 手順が存在しても、受け取る人がアクセスできず、
内容と残余リスクを確認していなければ移管は完了していない。

この提案の位置づけ

この課題は、development-workflow を
PMBOK の標準と照合したことから始まった。
PMBOK の観点では、現在の Skill にガバナンス、スケジュール、財務、ステークホルダー、
資源、リスクなどのプロジェクト管理が不足しているように見える。

しかし、development-workflow の目的は、人間のプロジェクトチームを管理することではない。
絶対的な承認が必要な場面以外を AI エージェントが自律的に判断し、極力人の手を介さずに
開発プロジェクトを完了させることである。

そのため、PMBOK の項目をそのまま追加しない。人間同士の分担と進捗を管理する仕組みではなく、
AI の自律性を保ったまま必要になる統制へ読み替える。

PMBOK から得た観点	この Skill 群での読み替え
ガバナンス	AI が進めてよい範囲と、人間の承認が必要な不可逆な境界
リスク	移行前に機械で検証する項目と、各責任者が受諾する残余リスク
品質	文書の有無ではなく、利用手順・監視・復旧手順を実行した証拠
ステークホルダー	広い関係者管理ではなく、成果物を受け取る立場と責任の特定
説明責任	AI が行った判断、実行結果、未解決事項を人間へ渡せる形で残す
スケジュール・資源・財務	実行上限などが必要な場合だけ扱い、人間向けの進捗管理は持ち込まない

WBS、要員のキャパシティ、日程ベースライン、実績対比、完了予測、定例報告は、
この目的では意味を持たないことが多い。一方で、開発を終えた AI から、成果物を利用・支援・
継続稼働・保守する人へ責任を戻す境界は省略できない。

この課題は PMBOK 準拠を目指すものではなく、PMBOK との比較で見つかった不足のうち、
自律開発にも必要な「定常状態へ移れることの証明」と「責任の移管」だけを取り込む提案である。

用語

「運用」は複数の意味を持つため、この課題では単独で使わない。

用語	この課題での意味
利用準備	想定した利用者が、成果物を本来の目的に使い始められる状態
サービス継続準備	正常性を観測し、異常を検知し、復旧できる状態
支援・保守準備	問い合わせ、不具合、更新を受け取り、次の行動へつなげられる状態
移行準備	上のうち、その成果物に該当するものを揃えて確かめること
責任移管	該当する人が、知識・権限・未解決事項・残余リスクを確認して責任を受け取ること
定常状態	開発を行った AI のセッションに依存せず、人と仕組みが成果物を使い続けられる状態

方針

Skill 名にも意味の広い operational を使わない。責務を次のように分ける。

flowchart TD
    V[検証への配布と確認] --> T[移行準備]
    T --> A[本番配布の承認]
    A --> P[本番への配布と確認]
    P --> H[責任移管]
    H --> S[移行支援または終了]

Loading

責務	担当	人間の介在
利用・継続稼働・支援保守のうち必要な準備を揃える	新しい transition-readiness	原則不要
本番へ出す不可逆な判断	既存の release	既存どおり承認必須
該当する立場へ知識・権限・責任を渡す	新しい responsibility-handover	受諾だけ必須
移行直後の利用とシステムを重点的に支える	任意の transition-support	判断が必要なときだけ

transition-readiness

目的

本番配布の承認を求める前に、AI エージェントが定常状態へ移るために必要なものを揃え、
実行結果を提示する。

最初に、成果物を受け取る立場を判定する。該当しない立場の準備を要求しない。

観点	該当する例	主に確かめること
利用準備	業務アプリ、社内ツール、利用者向けアプリ	利用手順、権限、初期データ、移行、教育、業務上の代替手段
サービス継続準備	Web サービス、API、常駐処理	監視、通知、障害対応、rollback、backup/restore、性能・コスト
支援・保守準備	複数利用者を持つ成果物、継続保守する製品	問い合わせ経路、FAQ、Issue 化、再現情報、更新・脆弱性対応
個人利用	個人用 CLI、局所的な自動化	導入、更新、取消、データの保存先。組織的な役割は要求しない

不足を列挙して人間へ返すだけにしない。AI が作成・設定・検証できるものは自律的に完了させる。
外部契約、権限付与、業務上の責任者など、人間にしか決められないものだけを質問する。

利用準備

• 誰が、何の目的で、どの入口から使うか
• 初回利用、日常利用、例外時の手順
• アカウント、権限、端末、初期設定
• 初期データ、データ移行、切り替え方法
• 従来手順へ戻す条件と方法
• 利用者向け説明、教育、FAQ
• 操作上の問題をどこへ問い合わせるか
• 業務上の成功を何で確認するか

可能であれば、想定利用者と同じ権限・導入経路・データで主要な手順を実行する。

サービス継続準備

• ログ、メトリクス、トレース、Dashboard
• 正常性の判定とアラート条件
• 通知先と、通知後の最初の行動
• rollback、機能停止、再実行
• backup、restore、データ整合性
• 想定する障害モードと Runbook
• 管理画面・ログ・環境への権限
• Secret、最小権限、監査可能性
• 本番負荷、容量、コスト急増の検知

存在を読むだけで合格にしない。 安全に実施できる範囲で、rollback、隔離環境への restore、
テスト通知、Runbook のコマンドを実行して確かめる。

支援・保守準備

• 問い合わせ窓口と対応範囲
• 操作上の問題と不具合の切り分け
• 不具合を再現するために集める情報
• Issue の起票先と優先度の判断基準
• 既知の制約、回避策、互換性
• 更新、downgrade、依存関係、脆弱性対応
• repository、build、test、release へ辿る手順
• 開発側に残る課題の扱い

issue-upkeep の結果を Known Issues の入力にする。
古い Issue を移行資料へそのまま写さない。

配布の形による違い

release と同じく、配布の形によって該当する観点が変わる。形ごとの差は参照ファイルへ分ける。

形	主に必要な準備
パッケージ・プラグイン	導入、更新、downgrade、互換性、問い合わせ、保守
サービス	利用準備、監視、通知、復旧、backup、支援、保守
デスクトップ・モバイル	初回利用、データ移行、問い合わせ、crash 情報、公開停止、前版への復帰
手順・設定	実施者、業務手順、確認方法、取消、監査記録、権限

開始と終了

• 検証環境または開発版がある場合は、そこでの release-verification 後に行う
• 検証を挟めない場合は、本番配布の承認前に実施できる範囲を行う
• 本番固有の項目は、本番への配布後に再確認する
• 本番承認を求める時点で、立場ごとの結果と残余リスクを release へ渡す

responsibility-handover

目的

本番での検証が終わった成果物について、該当する立場ごとに知識・権限・未解決事項・責任を
人間へ移す。

「運用者」という一人の役割を仮定しない。最初に必要な受け取り手を決める。

受け取り手	受け取るもの
利用・業務の責任者	利用目的、業務手順、権限、移行結果、代替手段、業務上の未解決事項
サービス継続の責任者	正常性、監視、通知、障害対応、復旧、残余リスク
利用支援の責任者	問い合わせ経路、FAQ、切り分け、エスカレーション先
保守の責任者	repository、build/test/release、Known Issues、更新・脆弱性対応

存在しない役割を新設しない。同じ人が複数を受け取ってよい。個人利用では利用者本人への
利用手順と復旧方法の提示だけで完了できる。

AI が行うこと

• 成果物と配布形態から、必要な受け取り手を候補として示す
• transition-readiness の結果を立場ごとに分ける
• 対象の版・revision・環境を明記する
• アクセス先、手順、Known Issues、残余リスクを提示する
• 誰が何を受け取るかが重複・欠落していないか確かめる
• reject された不足のうち、AI が解決できるものを自律的に直す

人間の受諾

各受け取り手へ求める確認は、自分が受け取る範囲に限る。

• 必要な情報と環境へアクセスできる
• 最初に行う通常操作または異常時の行動が分かる
• 自分が引き取る未解決事項と残余リスクを確認した
• この時点から、その範囲の責任を引き受ける

AI が「理解したはず」と推測して完了させない。 必要な受け取り手すべての
accept / reject を新しい承認ゲートにする。

reject の場合は不足を具体的に記録し、AI が直せるものは transition-readiness へ戻す。
責任者の指定、業務上の判断、リスク許容度など人間にしか決められないものだけを質問する。

transition-support

必須工程にはしない。移行直後の不確実性が高い場合だけ有効にする。
システムの監視だけに寄せず、利用開始の問題も対象にする。

観点	見るもの
利用	利用開始率、主要手順の完了、問い合わせ、誤操作、業務上の失敗
サービス継続	エラー率、性能、アラート、障害、rollback の要否
支援・保守	問い合わせの滞留、再現不能な不具合、Known Issues の変化

期間だけで終わらせず、利用とシステムの両方に終了条件を置く。
異常を見つけた場合はその場で無計画に直さず、新しい変更として development-workflow へ戻す。

既存 Skill との境界

Skill	扱うもの
quality-gates	取り込み前の差分が品質条件を満たす
release	利用者が受け取れる状態にし、本番配布の承認を得る
release-verification	配布された成果物が受け入れ条件を満たす
retrospective	今回の進め方を見直す
issue-upkeep	次の作業と移行に使う Issue を現在の状態へ揃える
transition-readiness	定常状態へ移るための準備を立場ごとに揃えて確かめる
responsibility-handover	該当する人へ知識・権限・未解決事項・責任を渡す
transition-support	移行直後の利用とシステムを限定的に支える

完了条件を混ぜない。

• リリース後テスト: 成果物が受け入れ条件を満たす
• 利用準備: 想定した人が本来の目的に使い始められる
• サービス継続準備: 正常性を判断し、異常から復旧できる
• 支援・保守準備: 問い合わせ・不具合・更新を次の行動へつなげられる
• 責任移管: 必要な受け取り手が、それぞれの責任を引き受けた

最初の 4 つは AI が準備・検証できる。最後だけは人間の意思表示が必要である。

前提

親 #333 の「子 issue に共通の前提」に従う。この issue に固有の条件は次のとおり。

• 着手はマイルストーン「21 結果の契約と Skill の書き方の規約」と「23 配布の記録と課題系 Skill」の後
• 立場の判定・不足の列挙・受諾の記録はスクリプトにし、SKILL.md は判断だけを持つ（基盤: Skill の書き方の規約に「スクリプト主体」を足し、検査と本文の量の計測を入れる #855）
• release への受け渡しは、基盤: 配布の記録とリリース後テストのブロックを読み書きする部品（dist-record・record-pr） #850 の配布の記録ブロックと release / release-verification: 差分の判定・記録のブロック・公開の確認をスクリプトにし、照会の sleep ループをなくす #862 の release.py の形に合わせる
• 工程として足すなら、Skill の主体をスクリプトへ移し、LLM は呼び出し・結果の解釈・判断だけを持つ（全 Skill の改善の親） #845 の接点 1（工程 Skill の一覧と 設計: 待つ間の問い合わせを hook で止め、conductor の会話を工程の切れ目で切る（#829 #830） #843 の token-guard-stages.txt）を同じ PR で直す

実装の順序

最初からすべてを独立 Skill にしない。

1. transition-readiness と、立場・配布形態別の参照を追加する
2. release の本番承認へ readiness の結果と残余リスクを渡す
3. responsibility-handover と、受け取り手ごとの受諾ゲートを追加する
4. 実例が集まってから transition-support を独立 Skill にするか決める
5. 利用・サービス継続・支援保守のどれかが大きくなった場合だけ、readiness を別 Skill に分ける

受け入れ条件

• 「運用」を単独の役割・完了条件として使わない
• 利用、サービス継続、利用支援、保守、責任受諾の立場が区別されている
• 成果物ごとに該当する立場を選び、存在しない役割を要求しない
• transition-readiness が、必要な成果物の作成と実行可能な検証を自律的に行う
• 利用準備に、権限・初期データ・業務手順・移行・教育・問い合わせが含まれる
• サービス継続準備に、監視・通知・復旧・backup/restore・障害対応が含まれる
• 支援・保守準備に、問い合わせ・Issue・更新・脆弱性対応が含まれる
• 本番配布の承認時に、立場ごとの readiness と残余リスクが提示される
• responsibility-handover が、必要な受け取り手ごとに責任を分ける
• 必要な受け取り手の accept / reject なしに移管完了としない
• reject 時に、AI が解決できる不足は自律的に readiness へ戻す
• Known Issues が現在の実物と照合され、issue-upkeep の結果を利用する
• WBS、キャパシティ、日程・コストの予実管理を導入しない
• transition-support は任意で、利用面とシステム面の終了条件を持つ

未確定のまま残すこと

項目	内容
Skill 名	transition-readiness / responsibility-handover が NDF の命名規則に合うか
受け取り手の指定方法	リポジトリ設定、Issue、対話のどれを正とするか
記録の置き場所	起点 Issue、配布 PR、専用ファイルのどれへ残すか
対象モード	light / operation / legacy-refactor / standard / documentation の 5 つのモード別の要否
Skill の分割	利用・サービス継続・支援保守を将来別 Skill にするか
transition support	独立 Skill にするだけの実例が得られるか

関連

• development-workflow: 開発標準の品質統制を変更内容に応じて適用する #333 — 親（品質観点の一群。共通の前提を持つ）
• development-workflow: 変更の性質から適用する品質観点を判定し、既存の工程へ差し込む #338 — profile の共通の入口
• 基盤: Skill の書き方の規約に「スクリプト主体」を足し、検査と本文の量の計測を入れる #855 — Skill の書き方の規約（スクリプト主体）
• 基盤: 配布の記録とリリース後テストのブロックを読み書きする部品（dist-record・record-pr） #850 / release / release-verification: 差分の判定・記録のブロック・公開の確認をスクリプトにし、照会の sleep ループをなくす #862 — 配布の記録ブロックと release.py
• issue-upkeep — 既存 Issue を現在の状態へ揃える（課題の一覧を手入れする手順が無く、open 43 件中 24 件の本文が現状と食い違っていた #331、閉じた）
• development-workflow
• release
• release-verification
• retrospective