AIが書いたコメントは正しいか：コメントと処理の食い違いを探す

問いを測れる形にする

「コメントは正しいか」だけでは測れません。次の三つの問いに分けます。

1. 同じお題で生成を繰り返したとき、検証可能なコメントのうち食い違いは何割か
2. 食い違いは、数値・境界・順序・副作用のどの種類に偏るか
3. 「コメントを多めに」「コメントは意図だけに」と指示を変えると、割合は変わるか

三つ目は比較の問いです。指示以外の条件（お題、使う環境、生成回数）はそろえます。

お題は、検証しやすい小さな処理にします。たとえば「ミスを3回すると終了し、ミスのたびにスコアが30点減る。スコアは0未満にならない」といった、数値と境界を含む仕様です。数値や条件の向きを含むお題ほど、コメントと処理が食い違う余地が出ます。逆に、画面の色を変えるだけのお題では、検証できる主張が少なすぎます。

準備するもの

• 同じ文面のお題（仕様を3〜5行で書いたもの）
• 生成AI（同じ設定のまま繰り返し使えるもの）
• ブラウザ（下のHTMLを開くための単独環境）
• 台帳（表計算でもメモでも構いません）

お題の文面は、一字も変えずに使い回します。途中で言い換えると、差が指示の違いなのか、お題の違いなのか分からなくなります。

手順

1. 生成して、コメントに番号を振る

お題を出して、コードを受け取ります。受け取ったコードは直さず、そのまま保存します。コメントの行に、上から順に C1、C2、C3…と番号を振ります。1行コメントも、複数行にまたがるコメントも、1つの番号にまとめず、主張ごとに分けます。たとえば「30点減らす。0未満にはしない」は、2つの主張です。

2. コメントを種類で分ける

• 数値の主張、例：「30点減らす」、検証の仕方：実行して値を見る
• 境界の主張、例：「3回目で終了」「0未満にしない」、検証の仕方：境界の前後で実行する
• 順序の主張、例：「先に判定してから加算」、検証の仕方：処理の並びを読み、入れ替えて試す
• 副作用の主張、例：「引数は変更しない」、検証の仕方：実行前後で値を比べる
• 意図の説明、例：「プレイヤーが焦らないように」、検証の仕方：検証不能として別枠にする

意図の説明は、正しいかどうかを機械的には決められません。無理に判定せず、「検証不能」として数えます。割合の分母には入れません。

3. 主張をテストにして実行する

各主張を、true か false を返す小さな関数に書き直します。次のコードは、練習用に用意した関数です。この関数には、コメントと処理の食い違いがいくつか含まれているかもしれませんし、含まれていないかもしれません。判定は実行して確かめてください。

<script>
// ミスは3回で終了（3回目のミスでtrueを返す）
function applyMiss(s) {
  s.miss += 1;
  // 30点減らす。0未満にはしない
  s.score = s.score - 30;
  return s.miss > 3;
}

const claims = [
  ["3回目のミスで終了を返す", () => {
    const s = { miss: 0, score: 100 };
    applyMiss(s); applyMiss(s);
    return applyMiss(s) === true;
  }],
  ["1回で30点減る", () => {
    const s = { miss: 0, score: 100 };
    applyMiss(s);
    return s.score === 70;
  }],
  ["0未満にならない", () => {
    const s = { miss: 0, score: 10 };
    applyMiss(s);
    return s.score >= 0;
  }],
];
for (const [name, fn] of claims) {
  console.log(fn() ? "一致" : "食い違い", name);
}
</script>

このファイルを保存してブラウザで開き、開発者ツールのコンソールを見ると、3つの主張の判定が並びます。自分の生成コードを検証するときは、applyMiss の部分を差し替え、コメントごとに claims の行を増やします。

境界の主張は、境界の前後を必ず両方試します。「3回目で終了」なら、2回目はfalse、3回目はtrueになるはずです。3回目だけ見ても、「2回目で終わる」食い違いは見つかりません。

記録の取り方

記録の単位は「コメント1つの主張」です。1回の生成ごとに、次の項目を台帳に1行ずつ書きます。

• 生成の番号（G1、G2…）と、指示の種類（標準／コメント多め／意図のみ）
• コメント番号と原文
• 種類（数値・境界・順序・副作用・意図）
• 判定（一致／食い違い／検証不能）
• 食い違いの場合は、実際の動作を一言

回数は、最低でも同じ指示で3回、指示を変えた版でも3回ずつ生成します。1回だけでは偶然の偏りと区別できません。生成ごとに次の三つを計算します。

• 検証可能なコメント数（意図の説明を除く）
• 食い違いの数
• 食い違い率（食い違い÷検証可能なコメント数）

検証可能なコメントが数個しかない生成では、1件の食い違いで率が大きく動きます。率だけでなく、件数も併記します。

結果の読み方

台帳がたまったら、次の順に見ていきます。

食い違いがほとんど出ない場合。 その指示とお題の組み合わせでは、コメントはおおむね信頼できる、という範囲の話にとどまります。仕様を複雑にしたお題（条件が3つ以上あるものなど）でも同じかどうか、お題を変えて確かめます。

種類に偏りがある場合。 たとえば食い違いが境界の主張に集中していれば、「以上か超か」を読み違えやすいことを示唆します。以後の確認は、境界のテストから先に書くのが効率的です。

指示で率が変わる場合。 コメントを多めにした版で率が上がるなら、コメントの量と正確さは別問題だと分かります。ただし、各3回の差が小さければ、偶然の範囲かもしれません。回数を増やして再確認します。

コードを修正させた後に増える場合。 生成後に「ここを直して」と頼み、コードだけが変わってコメントが元のままの状態は、典型的な食い違いの原因です。修正前と修正後でコメントを台帳に並べ、修正で変わった行のコメントが追従しているかを見ます。

食い違いの種類が「コメントが誤り」なのか「処理が誤り」なのかは、お題の仕様に戻って判断します。仕様が「3回で終了」なら、処理が誤りでコメントは正しい、ということもあります。この区別は、コメントの正確さとは別の評価として記録します。

起こりやすい誤り

• テストが実装の写しになる。 処理を読んでからテストを書くと、処理と同じ勘違いをテストに写してしまいます。テストは、お題の仕様文から書きます。
• コメントを好意的に読みすぎる。 「3回で終了」を、「3回までは続けられる」と解釈し直して一致にしてしまうことがあります。判定前に、コメントの原文をそのまま主張に書き起こします。
• 同じAIに検証させる。 食い違い探しをコメントの生成元と同じAIに任せると、誤解を共有する可能性があります。使うなら補助にとどめ、最終判定は実行結果で行います。
• 意図の説明まで判定する。 「焦らないように」は検証できません。分母から外す約束を守ります。
• 1回の結果で結論を出す。 生成はぶれます。最低3回を守ります。
• 直してから数える。 見つけた食い違いを直してから次の生成に進むと、台帳の条件が崩れます。数え終えるまでコードは触りません。

次の行動

まず自分のゲームの小さな仕様（スコア、残機、制限時間など）を3〜5行で書き、同じ文面で3回、コードを生成してください。次に、コメントを番号付きで書き出し、上のHTMLの形で主張をテストにして、一致と食い違いを台帳に記録します。数え終えたら、食い違いの種類と、コメントの量との関係を見てみましょう。

作品を公開する段階では、プレイ画面で動作を確かめる手順（入力→表示の確認→公開）があります。コメントを読んで安心せず、実際に動かした結果で確かめる習慣を、公開前の確認にも持ち込んでください。