完了を、実際の動作で確かめる

全体の中で、今回はここ

6回の学習地図。今回は3の結果を確かめる。前回は2の材料をそろえる、次回は4の必要なら分担 — 数字は学ぶ順番です。pstackの固定の実行順を表す図ではありません。

前回は調査の根拠と未確認事項を分けました。今回は期待した動作と実際の結果を比べます。次回はこうした仕事を必要に応じて複数のAIへ分担します。

ゴールは同じ架空のログインアプリについて「どの条件で確かめたか・何が分かったか・何が未確認か」を報告できることです。

視点

今回の結論

「直しました」という報告だけでなく、同じ操作で直ったかを確かめます。

Step 1：ビルドは成功したがログインできない

前回まで読み取り専用で調べていた架空アプリで、今度は利用者が修正も許可した場面へ進みます。この場面も実際の作業結果ではありません。

AIは「ログインボタンを直しました。ビルドも成功です」と報告しました。ところがボタンを押しても画面は変わりません。

ビルドはソースコードを実行・配信できる形にまとめる処理です。実際の操作が成功するかの確認とは異なります。

自転車でたとえるなら、「部品を組み付けられた」と「ブレーキをかけたら止まれた」の違いです。組み付けの確認も必要ですが、使ったときの結果は別に確かめます。ビルドと実操作も、見ている対象が違います。

ビルドはコードを実行用にまとめる確認。実操作はログインし、そのユーザーとしてアプリを利用できるか確かめる確認。組み立てることと実際に使うことを分ける — 理解用の概念図。画面は実アプリのスクリーンショットではありません。ビルドと実操作は、確かめている対象が違います。

ビルド成功も大切な結果です。ただし、ログインできるかはログイン操作で確かめます。

Step 2：同じ操作でもう一度確かめる

検証は期待した動作と実際の結果を比べて確かめることです。証拠は実行した操作と観測した結果を後から確認できる記録。たとえば、実行ログや保存された値、操作条件が分かる画面の記録です。

自転車店で、固定された自転車の点検記録を受け取る場面を考えます。修理前はブレーキ操作をしても車輪が回り続け、修理後は同じ固定状態・同じ操作で止まった、と記録されています。

固定状態がテスト環境、ブレーキ操作が確かめる操作、車輪の変化が観測結果に当たります。部品を交換した記録だけよりも、何が変わったかを判断できます。

整備用スタンドに固定した自転車の修理前後を比較。同じブレーキ操作で、回り続けた車輪が止まるかを確認する。実際の走行条件はこの点検に含まれない — 理解用の比喩。固定した状態での点検と、実際の走行時の安全確認は別です。自転車の整備手順を示す図ではありません。

別の自転車で止まったとしても、預けた自転車が直った証拠にはなりません。また、固定した状態で確かめた結果を、試していない走行条件まで広げることもできません。これは検証の考え方の比喩で、自転車整備の手引きではありません。

アプリに戻ると、同じテストユーザー・ブラウザ・初期状態で元のログイン操作を繰り返します。画面が進むだけでなく、そのユーザーとしてログインし、ログインが必要なページを使えることまで確かめます。既存のテストがこの確認を担えるなら再利用します。

補足：AIが自分で確かめるための道具と知識

AIがコードを書いても、動作確認を人間だけが引き受けると、そこに仕事がたまります。LaurenさんはPt. 1で、検証のための道具と知識を整える重要性を説明しています。

機能と確かめ方をまとめたFeature Mapから操作を選び、CLIで実アプリを操作する。実際の状態を観測して証拠を残し、その証拠から次の行動を判断する — 検証基盤の概念図。Feature Mapは操作を選ぶための情報であり、動作の証拠そのものではありません。

図を拡大（別タブ）

Feature Mapは「機能と確かめ方の対応表」、CLIは「文字で命令を入力する操作の窓口」です。この図ではCLIでアプリを操作しますが、操作手段の一例であり、既存のブラウザ操作やテストも使えます。知識を読むだけで終わらず、実物を動かして結果を観測するところまでをつなぎます。

実ソースを読む：何を、どう確かめるのか

pstack/skills/principle-prove-it-works/SKILL.md の L7–22 は次の一文から始まります。

Verify every task output by checking the real thing directly.

画面なら実画面、値の更新なら保存された値、CLIなら実行結果、文章なら実際の文書。成果物に合う対象を直接見ます。

pstack/skills/poteto-mode/playbooks/bug-fix.md の工程4・L10 は、修正後に元の再現操作が通ることを求めています。別の操作で成功しても、元の問題の解消を確かめたことにはなりません。

pstack/skills/create-verification-skill/SKILL.md の L15–40 は、既存の起動・操作手段を調べ、専用の検証SkillとFeature Mapを作る手順です。作っただけでは完了せず、1機能を最後まで検証し、後片付け後も証拠が残ることを確かめます。

作者のverification-skill-exampleも構成の参考になります。ただし架空アプリの見本で、CLIの実装は含まれません。そのまま実行できる検証ツールではありません。

アプリが変われば対応表も更新が必要です。maintain-verification-skill・L29–37は、コードとの照合と実操作での確認を求めます。アプリの不具合を、手順書の書き換えだけで隠してはいけません。

Step 3：結果は3つに分ける

「確認できない」は「成功」でも「失敗」でもありません。

合格は期待どおり利用できた状態。不合格は操作しても進まないなど期待と違う状態。未確認は環境がなく試せず、結果を判断する証拠が足りない状態 — 理解用の概念図。画面は教材用の模式図で、実行結果ではありません。合格・不合格・未確認はpstack公式の出力形式ではありません。

先へ進まない条件も決める

すべての報告を修正へ進める必要はありません。Loops You Can Trustの考え方を、各工程で止まる判断として整理すると次のようになります。

切り分け、再現、修正の判断、修正と検証の順に進む。期待どおりの動作なら修正不要、再現できなければ推測で修正せず、高リスクなら修正前に人の判断を求め、証拠が足りなければ完了としない — AMPLによる概念図。高リスクなら修正前に止まり、人の判断を求めます。4つの自動化が実装済みという意味ではありません。

図を拡大（別タブ）

注意

合格と言えるのは、確かめた条件まで

別ブラウザ・期限切れ・通信障害時の動作は、試していなければ未確認です。結果がおかしければ、対象・初期状態・テストの方法も見直します。

結果を残すテンプレートを見る

同じ確認を再実行するための教材用テンプレートです。pstackの公式出力形式ではありません。

対象: ローカル練習アプリのログイン
条件: テスト専用アカウント、同じブラウザと初期状態
操作: ログインし、ログインが必要なページを開く
期待: テストユーザーとしてログインし、そのページを利用できる
判定: PASS / FAIL / INCONCLUSIVE
証拠: 実行したコマンド、結果、保存したログ等の場所
未確認: 別ブラウザ、期限切れ、通信障害時の動作

Step 4：Codexで一つだけ確かめる

AIの報告を、次の例のように分けてもらいましょう。

テストの合格と元のログイン操作の未確認を別々に報告する。テストが通っただけで、試していない元の不具合解消を確認済みにしない — 理解用の概念図。テストは通ったが、元のログイン操作は試せなかった場合の報告例です。実行結果ではありません。

練習用リポジトリの安全な既存テストだけを使います。 コード変更・本番接続・外部送信はしません。

演習の指示をコピーする

同じ初期状態の新規チャットを二つ使います。一方では「選んだテストを実行して結果を報告して」、もう一方では次の指示を使い、報告を比較します。どちらも先にテストの内容を確認し、本番接続・外部送信・破壊的操作・依存の追加が必要なら実行しません。

この練習用リポジトリで、既存テストを一つ確認してください。
最初にテスト内容を読み、対象・期待結果・安全な実行方法を説明してください。
本番接続・外部送信・破壊的操作・依存の追加が必要なら実行せず止めてください。
安全に実行できる既存テストだけを実行し、結果を報告してください。
コードや設定は変更しません。

「実行した内容・実際の結果・その結果で言えること・未確認事項」を分けます。
実行できなければINCONCLUSIVEとし、実行したふりをしないでください。

見る項目	確かめ方
証拠	コマンドと実際の結果が対応しているか
判定の範囲	テスト合格をアプリ全体の正常動作へ広げていないか
再実行	条件をそろえて同じ確認を行えるか
負荷	所要時間と追加で必要になった操作を記録する

これは報告の違いを見る小さな実験です。一度の比較でpstack全体の効果を証明するものではありません。検証基盤を新しく実装するのは、既存の手段で不足する点を見つけてからにします。

一つの判定と未確認事項を説明できたら終了です。