止まる基準

開発中の失敗は、完全にはなくせません。入力を間違える、設定が合わない、公開後に想定外の表示が出ることはあります。

大きな事故につながるのは、最初の失敗そのものより、理由が分からないまま修正を重ねる場面です。焦って操作を増やすと、どの変更が原因か分からなくなります。

安全性は、失敗しない能力だけでなく、影響が小さいうちに止まる能力で決まります。 止まる基準は、問題が起きてから考えるのではなく、操作前に書きます。

このレッスンの目的

このレッスンを終えると、変更ごとに停止条件、観測方法、連絡先、戻し方を決められます。

また、異常が起きたときに「何か直す」より先に、追加操作を止め、事実を保存し、安全だった状態へ戻す判断ができます。

停止は失敗ではありません。 判断材料を守るための積極的な操作です。

所要時間の目安は、読了7分 + 実習13分です。

実習13分では、4成果物を読み合わせ、検証計画と期待結果が揃っているかを判定します。認可テスト、復元テスト、外部操作そのものは実行しません。

概念：停止条件を操作前に決める

停止条件は、「この状態になったら、自動でも手動でも次へ進まない」と決める境界です。感覚的な不安だけでなく、観測できる変化へ結びつけます。

たとえば次のように書きます。

• 予定していない外部送信の確認画面が出たら止まる
• ダミーデータ以外が表示されたら止まる
• テストが一件でも失敗したら公開へ進まない
• 変更対象ではないファイルに差分が出たら止まる
• 戻し方を説明できない本番変更は始めない

停止条件は、危険の名前ではなく、止まるきっかけを観測可能にした文です。

停止条件は、変更の種類ごとに具体化します。画面の並び替えなら、対象外ファイルの差分、重複表示、既存データの消失を観測点にできます。公開操作なら、テスト失敗、想定外の環境、復旧点の欠如、確認者の不在を開始前の停止条件にします。外部送信なら、宛先、件数、本文、再実行時の重複防止が一つでも不明なら進みません。条件へ触れたら、原因を推測して直し始める前に操作を止めます。時刻、対象、直前の操作、観測結果を秘密の値なしで残し、誰が次を判断するか確認します。こうして操作前に境界を言語化すると、焦っている最中でも同じ基準を使え、最初の異常を連続した変更で大きくするのを防げます。

止まる文を先に書くと、異常時の判断をその場の勢いから切り離せます。

停止後の四段階

1. 止める：追加の変更、再実行、共有を止める
2. 保つ：エラー、時刻、対象、直前の操作を値を漏らさず記録する
3. 判断する：自分で戻せる範囲か、責任者へ連絡する範囲かを分ける
4. 戻す：事前に確認した手順で、安全だった版へ戻す

ロールバックは、以前の安全な版へ戻す操作です。何となくコードを削ることではありません。変更の種類によって、復旧点と検証方法は変わります。

変更種類ごとの復旧マトリクス

復元未テストのbackupは確認済み復旧点ではない。 ファイルが存在することと、必要な時間内に正しい対象へ戻せることは別です。schemaやdataの変更は、検証環境で復元し、件数、関係、読み書きを確かめてから復旧点として扱います。メール送信や課金のようなexternal-side-effectsは、技術的なロールバックで相手側の状態まで消せません。取消、返金、訂正、連絡を含む補償手順を先に決めます。

監視は「止まる目」を増やす

公開後は、すべてを画面の前で見続けられません。エラー件数、応答の失敗、重要な操作の成功率などを監視し、停止条件へつなげます。

ただし、計測しているだけでは止まりません。誰が通知を受け、何を見て、どの条件で戻すかまで決めて初めて役立ちます。

実習：ストップカードを作る

架空の「まちの読書メモ」で、ダミーの登録画面を変更する想定です。実際の公開、送信、削除は行いません。

ストップカードは、変更を許可するための形式ではなく、始めない判断にも使う記録です。最初に目的と対象外を書き、今回触れてよい範囲を固定します。次に、変更前の画面、Gitの状態、テスト結果など、安全だった状態の証拠を一つ選びます。正常結果と停止条件は対にし、どちらも実際に観測できる言葉で書きます。復旧欄では「元に戻す」で済ませず、どの履歴や版を使い、誰の権限で戻すかを確認します。連絡先が不明、復旧点がない、対象範囲を説明できない場合は、カードを未完成のまま保留にします。開始後に想定外の影響が見えた場合も、カードを書き換えて正当化せず、いったん停止して新しい判断として扱います。

空欄のあるカードは、開始してはいけない理由を示す成果物です。

変更内容は「登録後、架空のメモを一覧の先頭へ表示する」です。次のカードを埋めます。

変更の目的:
対象:
対象外:
開始前の安全な状態:
観測する結果:
停止条件:
停止後に保つ証拠:
連絡先または確認者:
戻し方:
再開条件:

記入例は次のとおりです。

変更の目的: 登録直後の架空メモを見つけやすくする
対象: 手元のダミー登録画面
対象外: 外部公開、実在データ、メール送信、削除
開始前の安全な状態: 変更前のGit差分がなく、現在の画面を確認済み
観測する結果: 登録したダミーメモが一覧先頭へ一件だけ出る
停止条件: 対象外ファイルの差分、重複登録、既存ダミーメモの消失
停止後に保つ証拠: エラー文、操作順、変更差分、テスト結果
連絡先または確認者: 練習では自分。外部影響がある環境では責任者を事前指定
戻し方: Git差分を確認し、対象変更だけを変更前へ戻す
再開条件: 原因を一つに絞り、同じ手順で再現できる

次に、三つの出来事を想定して判断します。

出来事A: 一覧先頭へ一件表示された
判断: 受入条件を確認し、次の検証へ進む

出来事B: 登録一回で二件増えた
判断: 停止。操作順と差分を保ち、追加登録しない

出来事C: 見覚えのない値が表示された
判断: 即時停止。共有や再実行をせず、値を転記せずに責任者へ連絡

異常を見たあとに直し方を競うのではなく、カードどおり止まれるかを練習します。

正常な結果

次の7項目を自己採点します。

• 変更の目的、対象、対象外が一文ずつある
• 正常結果と停止条件を観測できる言葉で書いた
• 変更をcode、config、schema、data、external-side-effectsへ分類した
• 変更種類に対応する復旧点と権限を確認した
• backupを復旧点にする場合の復元テストと期待結果を計画し、未実施なら確認済みと扱っていない
• 停止後の証拠、連絡先、再開条件を決めた
• 外部副作用には取消や訂正などの補償手順がある

7項目すべてにチェックが付くまで着手しないことが正常です。

よくある失敗

失敗1：同じ操作を何度も試す

外部送信やデータ変更を伴う操作では、重複を増やす可能性があります。再実行は、直前の結果と副作用を確認してから判断します。

失敗2：エラーを消すために変更を重ねる

複数の変更が混ざると、原因と効果を追えません。最後に分かっていた状態へ戻り、一つずつ試します。

失敗3：証拠として秘密の値をコピーする

エラー調査でも、APIキーや認証情報を記録へ貼りません。項目名、発生場所、時刻、伏せた状態のエラー種別だけを残します。

失敗4：戻し方を実行時に初めて探す

権限がない、復旧点がない、手順が古いことがその場で分かると、停止時間が長くなります。開始前に確かめます。

復旧：安全だった最後の状態へ戻る

異常を検知したら、まず新しい操作を止めます。ブラウザ更新や再実行も、状態を変える可能性があるなら行いません。

次に、観測した事実を短く残します。

発生時刻: 練習開始から5分後
対象: 手元のダミー登録画面
直前の操作: 登録ボタンを一回押した
観測結果: 架空メモが二件増えた
追加操作: なし
秘密情報の記録: なし

Gitを使っているなら、変更状態と差分を確認します。いきなり広い範囲を削除せず、対象を特定します。公開環境なら、承認されたロールバック手順と権限を確認します。

戻した後は、最初の受入条件を同じ手順で再確認します。表示が戻っただけでなく、問題を起こした操作が以前の結果へ戻ったかを見ます。

復旧完了は「エラーが見えない」ではなく、安全な状態を同じ確認方法で再検証できたときです。

安全メモ

削除、上書き、権限変更、公開、課金、外部送信は、取り返しがつきにくい操作です。対象、件数、環境、復旧点が一つでも不明なら始めません。

停止後に、より強い削除操作や広い権限でやり直してはいけません。権限不足やロックは安全装置として働いている可能性があります。

見覚えのない情報や秘密らしき値が現れた場合は、値をコピーせず、追加表示を試さず、定められた連絡先へ渡します。

戻せる根拠がない変更は、練習環境でも保留にする。 この基準をストップカードの最上部へ置いてください。

成果物

このレッスンの成果物は「ストップカード」です。最低限、次を一枚で確認できるようにします。

• 変更の目的、対象、対象外
• 開始前の安全な状態
• 観測する正常結果
• 具体的な停止条件
• 止めたあとに保つ証拠
• 連絡先または確認者
• 復旧点と戻し方
• 再開条件

作業中に条件が変わったら、先にカードを更新します。カードにない外部影響が見えた時点で停止です。

総合演習：着手判定パケット

最後に、必修4本で作った成果物を一つの「着手判定パケット」へ統合します。題材は引き続き架空の「まちの読書メモ」です。実装、公開、外部送信は行わず、着手してよい条件が揃っているかだけを判断します。

パケットへ次の4成果物を順に置きます。

1. 開発ルートカード：現在地、問い、確認済みの証拠、未確認、次の駅、安全線
2. 判断分担表：AIへ任せる生成、人間が決める事項、各判断に使う証拠
3. ダミーデータ一式：架空アカウントA・B、正常・境界データ、秘密情報の保管確認表
4. ストップカード：対象、停止条件、変更種類、復旧点、連絡先、再開条件

総合演習の手順

1. 開発ルートカードで「まだ需要検証前」と書く
2. 判断分担表で、AIが作る案と人間が行う合否判断を分ける
3. ダミーデータ一式で、認証、認可、直接URL、APIの検証計画と期待する拒否結果を示す
4. ストップカードで、想定変更をcode、config、schema、data、external-side-effectsへ分類する
5. 四つを読み合わせ、「いま実装へ着手する」「企画検証だけ行う」「停止して確認者へ渡す」のいずれかを選ぶ

PASS判定

• 4成果物が同じ架空企画と同じ現在地を参照している
• 証拠と未確認が分かれ、AIの自己報告だけを完了根拠にしていない
• 実在情報と秘密情報がなく、認可拒否の確認条件がある
• 変更種類ごとの復旧点があり、復元または補償を試す手順がある
• いまの判断が、着手、企画検証、停止のどれか一つに定まっている

FAIL判定

• 4成果物の対象や現在地が食い違う
• 「たぶん安全」「AIが完了と言った」のように証拠が曖昧
• backupの復元テストについて、検証計画または期待結果が書かれていない
• 直接URLやAPIの認可ケース、検証計画、期待結果が書かれていない
• 外部副作用の責任者、取消、訂正手順がない

FAILが一つでもあれば実装へ着手しません。 この架空企画では需要検証が未完了なので、パケットが整っても判定は「企画検証だけ行う」です。安全資料が揃うことと、作る価値が確認できることを混同しないでください。

用語集

• codeの変更前後を比べるときはGit、検証済みの版を反映するときはデプロイメントを使う
• 異常の発見は監視、安全な版への復旧はロールバックとして、検知と復旧を分ける

変更の証拠、異常の検知、反映、復旧を一つの「戻す」にまとめないことが重要です。

次の駅

企画上の次駅

架空企画の次駅は「需要検証駅」です。着手判定パケットが揃っても、誰のどんな不便を解くかは未確認なので、実装ではなく企画検証へ進みます。

教材上の次レッスン

これで「地図の読み方・安全線」駅の必修4本完了です。次の必修は「アイデア・課題発見駅」です。

安全線を持ったまま、自分の身近な不便を一つ選び、技術名を使わずに課題を説明します。まだ作り始めず、作る価値のある問いへ絞ります。

残る安全補講には、AIの得意不得意、コードを読めない場合の確認、患者情報・個人情報の個別取扱い、APIキーとパスワード、本番変更と破壊的操作、利用規約・ライセンス・著作権、AI生成物の検証責任があります。必修4本の修了は、これらの個別判断まで完了した意味ではありません。該当する操作へ進む前に、必要な補講と組織の正本を確認します。

今日のまとめ

3行で振り返ります。

• 停止条件は異常後ではなく操作前に、観測できる言葉で決める
• 異常時は追加操作を止め、事実を保ち、連絡と確認済みの復旧点へ進む
• 復旧完了はエラーが消えた時ではなく、安全な状態を同じ方法で再検証できた時