前回は「テストは合格。元のログイン操作は未確認」と報告を分けました。では、AIにログイン操作まで確かめてもらうには、何が必要でしょうか。今回は、操作方法を知ることと、実際に操作できることを分けて考えます。
ゴールは、今ある手順と道具でどこまで確かめられるかを説明できることです。この回でも新しいSkillや検証ツールは作りません。
Step 1：確かめ方を知り、実物を動かす
AIがコードを書いても、動作確認を人間だけが引き受けると、そこに仕事がたまります。LaurenさんはPt. 1で、検証のための道具と知識を整える重要性を説明しています。
Feature Mapは「機能と確かめ方の対応表」、CLIは「文字で命令を入力する操作の窓口」です。この図ではCLIでアプリを操作しますが、操作手段の一例であり、既存のブラウザ操作やテストも使えます。知識を読むだけで終わらず、実物を動かして結果を観測するところまでをつなぎます。
たとえるなら、検証Skillは自転車店の点検手順書、操作する道具は整備用スタンドやブレーキを動かす手、証拠は点検の記録です。「どのブレーキをどう確かめるか」が書いてあっても、操作できなければ点検できません。操作できても、車輪が止まったかを見なければ結果は分かりません。
この比喩をアプリへ戻すと、ログインの操作方法を知り、練習用の環境で操作し、そのユーザーとして利用できたかを確かめる、という関係です。手順書は証拠の代わりにはなりません。
Step 2：既存の手段を調べてから手順を整える
pstack/skills/create-verification-skill/SKILL.md の L15–40 は、既存の起動・操作手段を調べ、専用の検証SkillとFeature Mapを作る手順です。作っただけでは完了せず、1機能を最後まで検証し、後片付け後も証拠が残ることを確かめます。
作者のverification-skill-exampleも構成の参考になります。ただし架空アプリの見本で、CLIの実装は含まれません。そのまま実行できる検証ツールではありません。
アプリが変われば対応表も更新が必要です。maintain-verification-skill・L29–37は、コードとの照合と実操作での確認を求めます。アプリの不具合を、手順書の書き換えだけで隠してはいけません。
注意
見本を置くだけでは動かない
アプリごとに起動方法、操作手段、必要な権限が違います。Cursor向けの手順がCodexでそのまま動くとも限りません。既存の手段を調べ、足りない部分を分けます。
Step 3：Codexで確認手順の下書きを作る
機密情報のない練習用リポジトリを対象に、次の指示を使います。今回は資料を読むだけです。アプリの起動、テスト、設定変更は行いません。
この練習用リポジトリの、既存の起動方法とテスト手順を調べてください。
機密情報を含むファイルは開かないでください。
資料の列挙・読み取りに必要なコマンドだけを使ってください。
アプリの起動、テスト実行、ファイル変更、外部アクセスはしないでください。
ログインを確かめる方法が資料にあるかを調べて、
「起動方法・確かめる操作・期待する結果・証拠の残し方」を整理してください。
書かれていない項目は不明とし、手順やツールを作り足さないでください。
各項目に根拠のファイルと該当箇所を添えてください。
既存手順があることと、実際に動いたことは分けて報告してください。
返ってきたメモで、実際の資料と合う箇所を一つ確認します。たとえば操作手順はあっても、結果をどこへ保存するか分からないなら、その点を未確認として残します。ログイン機能がないアプリなら、検索など既存の機能を一つ選んでください。
セルフチェック
1. ログインのFeature Mapと操作手順を読みましたが、まだ実行していません。何が言えますか？
今回持ち帰るもの
起動方法、操作、期待結果、証拠の残し方が書かれたメモと、まだ分からない項目です。手順が見つかっただけでは検証済みにしません。
次は確認する仕事を複数のAIに任せる方法へ進みます。人数を増やす前に、今回整理した確認方法を共有できるかが手がかりになります。