公開前チェックリストと、AIへの頼み方

基礎編の到達点は、「公開する前に、何を確かめるか」を自分の言葉で持つことです。この章では、ここまでの内容を10項目のチェックリストにまとめ、AIに作らせるとき・見させるときの頼み方を4つの原則と3つの定型文にします。そして、AIに聞いても分からないことが何かを確かめます。

公開前チェックリスト（基礎版）

基礎編で学んだことを、確かめられる形に直したものです。実践編の第13章にある完成版16項目の部分集合になっていて、括弧内の番号は完成版での番号です。基礎編だけを読む方は、この10項目を公開前に確かめてください。「確かめ方が分からない」項目があれば、それが実践編を読む理由になります。

10項目のうち、1から5は第5章の「保管と設定」「誰に何を許すか」、6から8は自分の手で確かめる項目、9と10はアプリの外側の話です。経理の決算チェックリストと同じで、項目そのものより、「全部に印が付くまで締めない」という運用が本体です。

AIへの頼み方：4つの原則

第4章の実験から導いた3つの原則に、もうひとつ加えて4つにします。

1. 「本番運用に耐えるものを」と添える。再発率を25.7%から11.0%に下げた一言です。手段を細かく指示するより、目的を伝えます。英語で ready for production と書いても構いません。
2. 作る会話と、レビューする会話を分ける。同じ会話で「見直して」と頼んでも、ほぼ効きませんでした（23.8%）。レビューは新しい会話で、作った経緯を伝えずに頼みます。起票者と承認者を分けるのと同じです。
3. 「この機能で、ログインしていない人、または他人のデータに対して何ができるか」を質問する。「安全ですか」と聞くと、AIは「安全です」と答えがちです。代わりに、具体的な立場を置いて「何ができるか」を聞きます。答えが「何もできない」なら、その根拠（どこで確認しているか）を示させます。
4. 修正のあとは、もう一度確認する。ある穴を塞ぐ修正が、別の場所に穴を開けることがあります（第4章の「機能修正の副作用」100件、「変更の伝播不足」110件）。修正仕訳のあとに残高を再照合するのと同じで、修正は確認とひと組です。

定型文：3つの場面

そのまま貼り付けて使える文を3つ用意しました。角括弧の部分は、自分のアプリに合わせて書き換えてください。

[作りたい機能の説明] を作ってください。

このアプリは本番運用に耐えるもの（ready for production）である必要があります。
扱うデータ：[利用者のメールアドレス、残高、取引履歴 など]
利用者の範囲：[自分だけ／知人・同僚／不特定多数]

守ってほしいこと：
- データを取得・更新・削除するすべてのサーバー側処理で、ログイン済みであることと、そのデータの所有者（または管理者）であることを確認してください
- 権限の判定はブラウザ側だけで行わず、サーバー側で行ってください
- 秘密情報（APIキー、接続情報、管理用の鍵）はコードに書かず、環境変数から読んでください
- 入力された文字は、データベースへの命令と混ぜず、画面に出すときはエスケープしてください
- 「あとで対応」のメモ（TODO）を残す場合は、最後に一覧にして報告してください

できあがったら、「ログインしていない人」と「他の利用者」がこの機能で何ができるかを、確認している箇所（ファイル名）とともに説明してください。

このリポジトリのセキュリティレビューをしてください。
このアプリは本番運用に耐えるもの（ready for production）である必要があります。

前提：
- あなたはこのコードを書いた人ではなく、独立したレビュー担当者として読んでください
- 推測で補わず、コードと設定ファイルから読み取れることだけを根拠にしてください
- 秘密情報の値そのものは出力しないでください
- 攻撃用の文字列やコードの例は出力しないでください
- 修正はまだしないでください。報告だけお願いします

確認してほしいこと：
1. ログインしていない人は、このアプリで何ができますか
2. ログインした利用者は、他の利用者のデータに対して何ができますか
3. 管理者専用の処理は、サーバー側で管理者であることを確認していますか
4. 秘密情報がコード、設定ファイル、ブラウザに届くコードに含まれていませんか
5. 入力された文字が、データベースへの命令や画面の一部としてそのまま使われている箇所はありますか
6. 「あとで対応」のメモ（TODO）で、未対応のものはありますか

報告の形式：
- 問題ごとに、該当箇所（ファイル名と行番号）、深刻度（致命的／高／中／低）、根拠、修正の方針
- 「この操作は誰に許されるべきか」のように、業務ルールが分からないと判断できない箇所は、修正案を出さずに「持ち主への質問」として別に列挙してください
- 問題が見つからなかった項目についても、何を確認したかを書いてください

先ほどの修正について、次を報告してください。

1. 変更したファイルと箇所の一覧（差分の要約）
2. 修正の目的だった問題が、どの箇所でどう塞がれたか
3. 修正の過程で、確認処理（ログイン、所有者、管理者、入力の検証）を外したり緩めたりした箇所はありますか。あれば、その理由
4. 同じ処理をしている別の箇所（たとえば、取得は直したが更新や削除は直していない、など）に、同じ修正が必要ではありませんか
5. この修正のあと、「ログインしていない人」と「他の利用者」がこの機能で何ができるかは変わりましたか

修正はまだしないでください。報告だけお願いします。

どの定型文にも「ログインしていない人」「他の利用者」が入っています。この2つの立場から何ができるかを答えさせることが、アクセス制御（論文で1位、28.58%）の抜けを見つける最も簡単な方法です。

AIに聞いても分からないこと

定型文の中に、「業務ルールが分からないと判断できない箇所は、質問として列挙してください」という一文を入れました。ここが、この章でいちばん大切なところです。

AIは、コードの中にあるものは読めます。しかし、「この操作は誰に許されるべきか」は、コードの中にはありません。あなたのミニ銀行で、利用者は自分の取引を取り消せるべきでしょうか。管理者は全員の残高を見てよいのでしょうか。利用者同士で口座を共有できるべきでしょうか。これは技術の問いというより、業務の問いです。答えを知っているのは、持ち主であるあなただけです。

経理の権限表を思い出してください。「課長は50万円まで承認できる」「他部署の伝票は閲覧のみ」。これを決めたのは会計システムではありません。規程で人が決め、システムに設定したものです。アプリも同じで、「誰に何を許すか」の表を持ち主が書き、それをAIに実装させます。表がなければ、AIは「動く」範囲で勝手に決めます。第4章で見た「デモ志向の設計」の多くは、この表がなかったことの結果です。

分からなかったら、公開しない

チェックリストの項目で、確かめ方が分からないものがあった。AIの報告に、理解できない指摘があった。権限表のマスに、自分でも答えが決められないものがあった。このとき、「たぶん大丈夫」で公開しないでください。分からないまま締めた決算を、あとから直すのが大変なのと同じです。

選択肢は3つあります。実践編に進んで、自分の手で確かめられるようになる。第3章で見たように、公開範囲を絞る、または公開しない。そして、専門家に頼む。他人のデータやお金を扱うレベル3のアプリを本格的に公開するなら、自分の点検とAIのレビューに加えて、専門家のレビューを受けることを前提にしてください。どこから先を専門家に頼むか、何を持って相談に行けばよいかは、第27章で扱います。この教材は、専門家の代わりにはなりません。専門家と同じ言葉で話せるようになるためのものです。