試作品を本番にする前に：AIが作った一枚のコードのどこを残し、どこを作り直すか

残す部分と作り直す部分を分ける基準

判断の軸は「壊れたとき、誰が困るか」の一つだけです。

• 自分だけが困る(色が好みでない、余白が狭い):残して、公開後に直せます。
• 訪問者が困る(ボタンが押せない、失敗しても何も表示されない):公開前に直します。
• 訪問者や第三者が被害を受ける(他人のデータが見える、秘密の鍵が見える):直るまで公開しません。

AIが書いたコードは、一つのファイルにすべてが詰まっていることが多く、この3種類が混ざっています。そこで、コードを上から読む代わりに、観点ごとに「ここは見た目の話か、信用の話か」を仕分けていきます。

見直し表:画面・データ・入力・エラー表示

下の表をそのまま使えます。右端の列は、人が自分の目で確かめる方法です。

• 画面、残してよい目安：配色、余白、文言、レイアウトの骨格、作り直す目安：スマホ幅で横にはみ出す/入力欄にラベルがない/ボタンが小さすぎる、人が確認する方法：自分のスマホで開く。ブラウザの幅を狭めて確認する
• データ、残してよい目安：表示用の固定データ、画面内だけの一時的な状態、作り直す目安：保存先が誰でも読み書きできる設定/APIキーや合言葉がコードに直書き、人が確認する方法：公開するファイルを開いて、キーや合言葉の文字列を検索する。保存先の権限設定を画面で確認する
• 入力、残してよい目安：必須・形式を確認する画面側のチェック、作り直す目安：チェックが画面側だけで、受け取る側(サーバー)に確認がない、人が確認する方法：画面のチェックを通さない入力(空、極端に長い文字、記号)を想定して、受け取る側のコードを読む
• エラー表示、残してよい目安：失敗時に出す文言の言い回し、作り直す目安：失敗しても何も出ない/英語の技術メッセージがそのまま出る/入力内容が消える、人が確認する方法：機内モードやネットワーク切断で保存し、画面に何が出るか見る

表の使い方

各行に「残す」「直す」「判断保留」のどれかを付けます。「直す」が一つでもあるのは普通です。大事なのは、データと入力の行で「直す」を放置したまま公開しないことです。画面とエラー表示の「直す」は、公開後に順に直す計画でも成り立ちます。

データの行で必ず見ること

データは、見た目では分からないぶん、AIの出力でいちばん見落としやすい部分です。

秘密の値がコードに入っていないか。 ブラウザに送られるコードに書いた値は、訪問者が見られる前提で考える必要があります。秘密にしたい鍵は、ソースコードの外に置く方法が一般的です。たとえばVercelでは、環境変数をソースコードの外側で設定し、環境ごとに値を変えられます。Vercelのドキュメントによると、値を保存後に読み取れなくなるSecretという種類があり、変更は既存のデプロイには反映されず、新しいデプロイから適用されます。鍵を差し替えたのに古い公開版が古い鍵のまま動く、という状況に注意してください。環境変数に入れるだけでは、ブラウザへ送るコードに値が混ざる場合の問題は解決しない点も、AIに確認させる価値があります。

保存先が誰でも読み書きできないか。 Firestoreなどを使うなら、動作確認用に開けた権限が残っていないかを見ます。Firebaseの「Avoid insecure rules」は、誰でも読める、誰でも書ける、認証を確認しないルールを危険な例として扱い、ログイン確認やユーザーIDに基づく制限、Emulator Suiteでのルールの検証を対策に挙げています。試作中は便利でも、公開した時点で他人がデータを読み書きできる状態になり得ます。

この行は「残す」にできる場合が少なく、判断保留なら公開を止める、と決めておくと迷いません。

入力とエラー表示:画面側のチェックは「親切」であって「防御」ではない

入力の確認には2層あります。MDNのクライアント側フォーム検証は、required、type、minlength/maxlength、patternなどのHTML属性で基本的な確認ができ、不備を訪問者がすぐ直せると説明しています。一方で、クライアントから届くデータを信用せず、サーバー側でも確認するよう警告しています。通信内容は書き換えられるためです。

つまり、AIが作ったフォームにrequiredが付いていたら「画面側のチェックは残す」でよいのですが、受け取る側にも同じ確認があるかは別に見直します。受け取る側が無い(ブラウザ内だけで完結する)ツールなら、この行は「該当なし」と書いて構いません。

直し方の短い例(説明用・未実行)

エラー表示の行を直す例です。失敗しても入力内容を消さず、次の行動を伝えます。保存先/api/memosは仮のものです。

<form id="memo-form">
  <label for="title">タイトル</label>
  <input id="title" name="title" required maxlength="50">
  <p id="msg" role="alert"></p>
  <button type="submit">保存</button>
</form>
<script>
const form = document.getElementById("memo-form");
const input = document.getElementById("title");
const msg = document.getElementById("msg");

form.addEventListener("submit", async (e) => {
  e.preventDefault();
  if (input.validity.valueMissing) {
    msg.textContent = "タイトルを入力してください。";
    return;
  }
  try {
    const res = await fetch("/api/memos", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ title: input.value })
    });
    if (!res.ok) throw new Error(String(res.status));
    msg.textContent = "保存しました。";
  } catch {
    msg.textContent = "保存できませんでした。入力は残してあります。時間をおいてもう一度お試しください。";
  }
});
</script>

ポイントは3つです。ラベルを入力欄に結び付けている(画面)、空入力に具体的な文言を出す(入力)、通信失敗をcatchで受けて入力を消さない(エラー表示)。この例は/api/memos側の確認までは含みません。そちらは別途必要です。

AIに見直しを頼む依頼文

コードを貼り、次の依頼文を使います。貼る前に、本物のキー、個人名、メールアドレス、顧客データは必ず「ダミー」に置き換えてください。 学習に使われない設定にしたとしても、それは秘密を預けてよいという意味ではありません。

次のコードは、AIで作った試作品です。公開前の見直しをしたいので、
「画面」「データ」「入力」「エラー表示」の4観点で、
各項目を「残す」「直す」「判断保留」のどれかに分類した表を作ってください。

条件:
- 「直す」には、コードのどの部分か(関数名か行の説明)と、直す理由を1文で書く
- 推測で断定せず、コードから読み取れないこと(保存先の権限設定など)は
  「判断保留」とし、人が画面で確認すべき手順を書く
- 秘密の値(APIキー、合言葉)に見える文字列があれば、最初に指摘する
- 直したコードはまだ出さない。表だけ返す

このツールの用途: (例)友人5人でメモを共有するページ
保存先: (例)Firestore / 保存しない / 未定
個人情報: (例)ニックネームのみ / メールアドレスを集める

[ここにコードを貼る]

最後の3行(用途・保存先・個人情報)を書くと、AIの判定が具体的になります。書かずに頼むと、一般論の指摘が増えがちです。

返ってきた表の扱い方

AIの表は下書きです。次の順で、人が確かめます。

1. 「秘密の値」の指摘を最優先で、自分の目でコードを検索して確かめる。
2. 「判断保留」の項目を、AIが書いた手順で実際に画面で確認する(Firebaseの権限画面、スマホ表示など)。
3. 「直す」の項目は、一度に全部直させず、データ→入力→エラー表示→画面の順に一つずつ直し、そのたびに操作して確かめる。

AIが「問題ありません」と返した項目も、データ行だけは自分の目で確認してください。AIはコード外にある設定(保存先の権限など)を見られません。

説明用の例:メモ共有ページを表にするとこうなる

次は説明用の仮の例で、実在のプロジェクトの判定ではありません。「友人5人でメモを共有するページ。保存先はFirestore」と仮定します。

• 画面:配色・文言、判定：残す、理由・次の行動：好みの問題。公開後に調整
• 画面:スマホ表示、判定：直す、理由・次の行動：横にはみ出す想定。公開前に自分のスマホで確認
• データ:保存先の権限、判定：判断保留→公開停止、理由・次の行動：誰でも読み書きできる設定か不明。権限画面で確認するまで公開しない
• データ:鍵の置き場所、判定：直す、理由・次の行動：コードに直書きなら、ソースコードの外へ移して鍵を差し替える
• 入力:空・長すぎる、判定：残す(画面側)、理由・次の行動：受け取り側の確認は別途必要
• エラー表示:保存失敗、判定：直す、理由・次の行動：何も出ない想定。上の例のように入力を残して案内

こう並べると、「公開を止める行」と「公開後に直せる行」が分かれます。画面の行を全部直し終えるまで公開しない、といった必要以上の完璧主義を避けられます。

公開前に手を動かす順番

1. 依頼文でAIに表を作らせる(ダミーデータで)。
2. データ行の「秘密の値」「保存先の権限」を、自分の目で確かめる。
3. 「直す」を1項目ずつAIに直させ、ブラウザで操作して確認する。
4. 機内モードで保存を試し、エラー表示を見る。
5. データと入力の行に未解決がなければ公開する。残りは公開後の改善リストへ。

全部を直そうとせず、「訪問者や第三者に被害が出る行」を先に消す。これが試作品を本番にする最短の道です。