全体の中で、今回はここ
前回は架空のログインアプリで仕事の分け方と、判断に使う根拠を決めました。今回は同じ確認漏れが繰り返されたら何を変えるかを考えます。
目標は再発防止の候補を1件選び、失敗例と正常例で確かめる方法を書けることです。まだ実装は変えません。次回、自分の環境にすでにある検査や手順と照らし合わせます。
視点
今回の結論
再発防止は、同じ注意を繰り返すだけでなく、失敗を起きにくくする構造と、失敗を見逃さない検査を作ることです。
Step 1：また同じ修正を頼んでいる
ログインアプリで、正常に入れることだけを確認して完了にしてしまったとします。あとで失敗時の表示漏れが見つかり、別の修正でも同じ確認漏れを繰り返しました。毎回注意する以外に、変えられるところはないでしょうか。
ケーブルを差す場面で比べてみます。「向きに注意」という札を毎回読む方法と、逆向きの突起が受け口に当たる形にする方法です。後者は注意を忘れてもその向きでは入らない点が違います。
ただし、正しい向きで差せても、ケーブルの断線までは防げません。形で防げる失敗と、差したあとに検査する失敗は別です。
pstackも注意文の追加より先に、処理の構造や扱える値の決まりで防げる誤りを探します。ログインの例では、正常時と失敗時を両方試す検査を候補にします。接続部の形とは違い、検査は実行しなければ働きません。以前見逃したケースを検出できるかも確かめます。
Step 2：失敗の種類から改善先を選ぶ
Laurenさんは改善の重点をコードの構造に置き、自動チェック、文章の指示、人のレビューへと細くなる逆ピラミッドを示しています。モデル性能の向上を実測した図でも、人のレビューを不要とする図でもありません。
構造は処理の担当やデータの持ち方です。図に出てくる「型」は扱えるデータの約束、「境界」は処理や責任の区切りを指します。
Laurenさんの投稿を見る
make the easy thing the right thing.
Lauren Tan (@poteto)
逆ピラミッドについての投稿をXで読む (2026-10-17)
pstackのcorrect（コレクト）は繰り返す失敗を調べて、リポジトリの構造や検査を変えるSkillです。リポジトリとはコードや設定、変更履歴をまとめて管理する場所です。pstack/skills/correct/SKILL.md のFind the mistake classesに分類の基準があります。
A class counts once it has happened twice.
同種の失敗が2回起きたら、繰り返す問題として扱います。初回の不具合を放置してよいという意味ではありません。構造や型で誤りを起きにくくできるか、できなければLintやCI、動作テストで検出できるかを検討します。
Lint（リント）はコードを動かさず、書き方の誤りなどを調べる検査です。CI（シーアイ）はコードの変更時に検査などを自動実行する仕組みを指します。
これは「すべてを型で防ぐ」という意味ではありません。Fix and proveでは、選んだ検査が実際の過去の失敗で失敗することを確かめ、より上の方法を選べなかった理由も報告します。
補足：今回の作業を再実行できる道具にする
「Build the Lever」は、作業を実行し、結果を確かめられる道具を作る原則です。Laurenさんはガイド Pt.1で、大規模な変更の最初の一件から手順を見つけ、繰り返せる道具にする考え方を示しています。
コードを決まった規則で書き換えるcodemod（コード変換プログラム）と、結果を検査するchecker（検査プログラム）が一例です。変更する道具と、正しく変わったか確かめる道具を分けます。
原典のBuild the Lever・L12–23は、軽微な作業を除けば一度きりの仕事も対象にしています。自動処理プログラム（スクリプト）で同じ処理を実行できるなら、AIに手作業を分担させない方針です。今回の仕事を確かめやすくする道具と、将来の再発を防ぐ構造は、役割を分けて考えます。
StyleXの改修についての投稿を見る
Laurenさんは、仕事の一部を任せる子エージェント向けのcodemodや専用Skillが作られた例を紹介しています。本人の経験談であり、並列化の効果を測った比較実験ではありません。
lauren (@poteto)
StyleXの改修についての投稿をXで読む (2026-05-28)
Step 3：reflectは学びの反映先を選ぶ
reflect（リフレクト）は会話の履歴を、判断、ツールの使い方、別の方法という観点で振り返るSkillです。pstack/skills/reflect/SKILL.md のSpawn〜Synthesizeでは、3つのレビューを統合し、採用候補、不採用、後で扱う候補に分けます。
Structural enforcement check〜Applyでは、Lintやスクリプトなどで扱える候補をSkillの文章修正から外し、後で扱う候補に回します。採用候補のSkill編集には人の明示的な承認が必要です。correctはリポジトリ側の改善、reflectは会話から学びを選別する手順であり、同じ機能ではありません。
原典は後で扱う候補を、課題の記録先であるトラッカーへ登録するよう別に指示しています。この講座では外部登録を再現せず、候補の提示までに止めます。承認待ちの範囲と、外部への書き込み権限は分けて考えてください。
AIモデルそのものを再学習させるのではなく、モデルが働く環境を変えます。Encode Lessons in Structure・L1–11も、構造で扱えるものと、人の判断が要る指示を分けています。
注意
ただし：検査を増やせば改善するとは限らない
悪い例を止めても、正しい変更まで拒むなら運用を妨げます。デザインや事業上の判断は、自動検査だけでは決められません。過去の失敗例だけでなく正常例も確かめ、時間と誤検出を記録してください。
Step 4：Codexで再発防止案を比較する
ログインの確認漏れと同じように、繰り返した失敗から検査案を選ぶ練習です。次の購入判定の記録は教材用で、実際のリポジトリ履歴ではありません。コードを直す前に、どの検査を提案するか比べます。
次の教材用記録だけで、再発防止案を1件提案してください。
読み取り専用です。ファイル変更、コマンド実行、外部アクセスは禁止です。
仕様：購入済み、かつ期限前だけダウンロード可。
期限と現在時刻は同じ単位の有限な数値。期限ちょうどは期限切れ。
失敗A：未購入・期限前なのに許可した。
失敗B：別画面でも未購入・期限前なのに許可した。
正常例：購入済み・期限前なら許可する。
現在の案内文：「購入条件を必ず確認する」
同種の失敗を分類し、構造、型、Lint、テスト、文章の順に候補を検討。
存在しないファイルや検査を「導入済み」と扱わないでください。
選んだ案、上位の方法を今は選べない理由、
失敗例を拒否し正常例を許可する確認方法を返してください。
実装と、実行していない検査の合格報告は不要です。
比較用の依頼では末尾の「同種の失敗を分類し」以降を「再発防止案と確認方法を返してください」に替えます。入力例と制約を保ち、同じモデル設定の新規チャット2つで比べてください。
テスト案は例えば次のように期待値を明示できます。これは確認項目の例で、実行結果ではありません。
paidは購入済みか、expiresAtは期限、nowは現在時刻です。expectedが期待する結果で、trueなら許可、falseなら拒否を表します。
const cases = [
{ paid: false, expiresAt: 20, now: 10, expected: false },
{ paid: true, expiresAt: 20, now: 10, expected: true },
{ paid: true, expiresAt: 20, now: 20, expected: false },
];
| 記録するもの | この段階で比較できる内容 |
|---|---|
| 分類 | AとBを同種の失敗として扱ったか |
| 根拠 | 選択理由と未確認事項が分かるか |
| 検査案 | 失敗例と正常例の期待値があるか |
| 負担 | 提案を読み、採否を決める時間 |
再発防止率は案を読んだだけでは測れません。実装を承認した後に検査を動かし、別の変更でも働くか確かめます。
セルフチェック
1. 同じ注意文があるのに、同種の不具合が2回起きました。次に何をしますか？
今回持ち帰るもの
ログインアプリで繰り返した確認漏れと、防止策の候補を1件ずつ残します。「間違った入力のとき」だけでなく「正しい入力のとき」の期待結果も添えてください。提案しただけでは効果は未確認です。次回は、同じ役割の検査がすでにないかを調べます。
今日のまとめ
- 分類：correctは繰り返す失敗と根拠を集める。
- 反映：reflectは学びの反映先を選び、Skill編集を承認へ回す。
- 再検証：失敗を止め、正常な仕事を妨げないか確かめる。
次回の問い
自分の環境に、すでに同じ役割を果たす道具はありませんか？ 最後はCodex環境の点検から始めます。