点検の準備：自分のアプリの全体図を描く

実践編では、あなたが公開しているアプリを自分の手で点検します。最初の一歩はコードを読むことではありません。紙とペンで、アプリの全体図を描くことです。どこに何があり、データがどう流れ、どこから先が「信用できない世界」なのかが見えれば、以降5つの演習で何を見ればよいかが決まります。

なぜ最初に図を描くのか

内部統制の整備を思い出してください。最初にやるのは業務フロー図の作成です。どこで証憑が発生し、誰が承認し、どの段階にリスクがあるか。それを図にしてから、統制（チェックや承認）を置く場所を決めます。フローが分からないまま「とりあえずダブルチェック」を増やしても、肝心の場所が抜けます。

セキュリティも同じ順番です。専門家はこの作業を脅威モデリング（threat modeling。どこが狙われうるかを事前に洗い出すこと）と呼び、出発点としてデータフロー図（DFD、Data Flow Diagram）を使います。OWASPのThreat Modeling Cheat Sheetでも、システムを図にすることが最初の手順として示されています。

バイブコーディングでは、この図を描ける人が意外と少ないのです。AIが設計も実装もしてくれたので、持ち主が「自分のアプリにどんなサーバー処理があるか」を知らないことが珍しくありません。第1章で見た論文の失敗モードのうち、「デモ志向の設計」174件や「利用者任せ」72件は、AIが本番向けの守りを省いたり、持ち主に委ねたりしたものでした。全体図を描くと、こうした「省かれた場所」が空白として見えてきます。

図に描く6つの要素

難しい記法は要りません。四角と矢印と点線だけで十分です。描くべき要素は次の6つです。あなたの学習用ミニ銀行アプリを例にします。

登場人物

アプリに触る人や外部の仕組み。利用者、管理者（あなた）、そして自動で呼んでくる外部サービス。ミニ銀行なら「口座を持つ利用者」と「管理者」。

画面

ブラウザに表示されるページ。ログイン、口座一覧、振込、取引履歴、管理画面。URLの単位で書き出すと漏れにくいです。

サーバー処理

ブラウザからの依頼を受けて動く処理。「残高を返す」「振込を実行する」「利用者一覧を返す」など。Next.jsならAPIルートやサーバーアクションがこれに当たります。

データベース

データの保管場所。Supabaseなら、テーブルの単位で書きます。利用者、口座、取引、といった具合です。

外部サービス

自分のサーバーの外にあって、呼び出して使うもの。認証（Supabase Auth）、メール送信、決済、AIのAPIなど。

秘密情報

APIキー、データベースの接続文字列、管理者パスワード。どこに置かれているかを、鍵のマークで図に書き込みます。

経理の言葉に置き換えるなら、登場人物は「起票者と承認者」、画面は「伝票の様式」、サーバー処理は「会計システムの処理」、データベースは「総勘定元帳」、外部サービスは「銀行や取引先」、秘密情報は「金庫の鍵と銀行印」です。

信頼境界：どこから先を信用しないか

図を描いたら、点線を1本引きます。「ここから先は、相手が自由に書き換えられる領域」と「ここから先は、自分が管理している領域」の境目です。これを信頼境界（trust boundary）と呼びます。

いちばん大切な境界は、ブラウザとサーバーの間です。ブラウザで動いている画面は、利用者のパソコンの中にあります。ブラウザに付いている開発者ツールを使えば、画面の表示も、ボタンの有効・無効も、サーバーに送る内容も、利用者が自由に書き換えられます。これは不正でも何でもなく、ブラウザの仕様です。

ですから、「残高が足りないときは振込ボタンを押せないようにしてある」だけでは、守りになりません。ボタンを押せるようにするのは利用者側の自由だからです。残高の確認は、サーバー側でもう一度やる必要があります。ブラウザ側の確認は、利用者の操作を助けるための親切であって、統制ではありません。

経理に置き換えると分かりやすいでしょう。申請者が自分で書いた伝票に「承認済み」と書いてあっても、それを信じる経理担当者はいません。承認は承認者の側で行い、承認者の記録だけを正とします。ブラウザは申請者、サーバーは承認者です。「サーバー側で検証する」が原則、というのはこの意味です。

もう1本の境界は、サーバーと外部サービスの間です。外部サービスから戻ってくるデータ（決済完了の通知など）も、本当にそのサービスから来たものかを確かめる必要があります。ただし、この章では存在を知っておけば十分です。

資産の棚卸し：何を預かり、漏れたら誰が困るか

図ができたら、データベースと秘密情報の箱の中身を棚卸しします。金庫の中に何が入っているかを数える作業です。問いはひとつ、「これが漏れたら、誰が、どう困るか」です。

学習用アプリでも、テストで使ったメールアドレスが同僚の実在のものなら、それは個人情報です。「学習用だから」は、預かっているデータの重さを軽くしません。第3章のリスク区分（見るだけ・入力やログインがある・他人のデータやお金を扱う）に、ここで自分のアプリを当てはめ直してください。

点検ノートを用意する

以降の演習では、確認した結果を1か所に記録します。監査調書と同じで、「いつ、何を、どう確かめて、どうだったか」が残っていなければ、点検したことになりません。次の表を、表計算ソフトかメモ帳に写してください。

このリポジトリについて、全体図を描くための材料を一覧にしてください。

1. 画面（ページやルート）の一覧と、それぞれの役割
2. サーバー側の処理（APIルート、サーバーアクション、サーバー関数）の一覧と、それぞれが読み書きするデータ
3. データベースのテーブルの一覧と、主な列
4. 呼び出している外部サービス（認証、メール、決済、AIなど）の一覧
5. 環境変数の「名前」の一覧（値は絶対に出力しないでください）

それぞれについて、該当するファイル名を添えてください。
推測で補わず、コードから読み取れることだけを書いてください。