「丁寧に」と「正確に」：AIの出力はどう違うか

一語だけを変える：課題とプロンプトの設計

なぜスライドパズルなのか

3×3のスライドパズルには、見た目では気づきにくい落とし穴があります。1〜8の数字と空白をランダムに並べ替えると、およそ半分の配置は、どれだけ動かしても完成形に到達できません。解ける配置だけを出すには、完成形から合法手（空白に隣り合うタイルを空白へ動かす手）を繰り返してかき混ぜるか、並びが解ける条件を満たすか検査する必要があります。

つまりこの課題には「動いて見えるが、仕様の深いところで誤っている」状態が生まれます。「正確に」という語が、こうした隠れた条件への配慮を引き出すのか、それとも出力の見た目だけを変えるのか。この問いを確かめるには適した題材です。同時に「丁寧に」が、説明文、コメント、操作案内といった周辺の親切さを増やすのかも、同じ出力から読み取れます。

比べる三つの条件

プロンプトは次の三つだけを用意します。副詞の位置と、それ以外の文字は完全に同一にします。

• 条件A（丁寧）：「3×3のスライドパズルを、丁寧に、単一のHTMLファイルで作ってください。」
• 条件B（正確）：「3×3のスライドパズルを、正確に、単一のHTMLファイルで作ってください。」
• 条件C（副詞なし）：「3×3のスライドパズルを、単一のHTMLファイルで作ってください。」

条件Cは対照です。AとBに差があっても、どちらが基準から動いたのかはCがないと分かりません。

意図的に、プロンプトには「解けない配置を出さないこと」を書きません。書いてしまうと、副詞の効果ではなく明示の効果を測ることになります。

準備するものと手順

準備するものは次のとおりです。

• 比べるAIのチャット画面またはAPI環境（どのモデルか、使用日はいつかを必ず控えます）
• ブラウザ（開発者ツールのコンソールを開けるもの）
• テキストエディタ
• 記録用の表計算シートまたはメモ

手順は次のとおりです。

1. 各条件を最低5回、できれば10回生成します。毎回、新しい会話を開き、前の履歴が残らないようにします。同じ会話内で続けて頼むと、前の出力に影響されます。
2. 生成の順番は、A、B、Cを順番に回すのではなく、くじ引きなどでばらします。時間帯や調子の偏りが特定の条件に集中するのを避けるためです。
3. 出力されたコード全体を、乱数のファイル名（例：k7q2.html）で保存します。条件との対応表は別のメモに書き、評価が終わるまで見ません。
4. 出力にコード以外の説明文が付いていたら、その文章は別ファイルに保存します。コードと説明は、後で別々に数えます。
5. 各ファイルをブラウザで開き、動作確認と配置の検査（次節）を行います。
6. すべて評価し終えてから、対応表を開いて条件ごとに集計します。

設定を変えられる環境では、温度などの生成設定も全回で固定し、その値を控えます。変えられない環境でも、変えていないことを記録しておけば十分です。

何をどの単位で記録するか

評価項目は、「正確さ」に関わるものと「丁寧さ」に関わるものに分けます。1ファイルにつき1行を記録します。

• 起動できたか、単位：あり／なし、測り方：開いてコンソールにエラーが出ないか
• 完成形の判定、単位：あり／なし、測り方：揃えたときに完成の表示が出るか
• 開始配置の解ける率、単位：回数／20、測り方：「シャッフル」を20回行い、解ける配置の回数を数える
• シャッフル方式、単位：分類、測り方：コードを読み、「ランダムな並べ替えのみ」「合法手の反復」「解ける条件の検査」のどれか
• 総行数、単位：行、測り方：エディタの行数
• コメント行数、単位：行、測り方：コメントのみの行を数える
• コード外の説明文、単位：文字数、測り方：手順4で別保存した文章
• 要求外の機能、単位：個数、測り方：手数表示、キー操作、アニメーションなど、頼んでいない機能を数える
• 言葉づかい、単位：分類、測り方：画面や説明文が敬体か、常体か、混在か

解ける配置の検査

シャッフルの20回分は、画面の配置を手で書き写すのは手間なので、コンソールで確認できるようにします。完成形が「1〜8を順に並べ、最後が空白」である場合、空白を除いた8個の並びで、後ろに自分より小さい数がある組（逆転）の数を数え、偶数なら解けます。3×3のように幅が奇数の盤では、この条件で判定できます。

// a: 長さ9の配列、空白は0（例：[1,2,3,4,5,6,8,7,0]）
function solvable(a) {
  const b = a.filter(n => n !== 0);
  let inv = 0;
  for (let i = 0; i < b.length; i++)
    for (let j = i + 1; j < b.length; j++)
      if (b[i] > b[j]) inv++;
  return inv % 2 === 0;
}
console.log(solvable([1,2,3,4,5,6,8,7,0])); // false（7と8だけが入れ替わった並び）

この検査関数が正しく動くかを、実験の前に確かめておきます。上の例は完成形から7と8だけを入れ替えた並びで、逆転は1組なので奇数となり、false が出るはずです。完成形そのもの [1,2,3,4,5,6,7,8,0] では逆転が0組で true が出ます。

生成されたゲームが配置を内部配列で持っている場合は、コンソールからその配列を取り出して solvable に渡せます。変数名はコードごとに違うので、コードを読んで探します。取り出せない作りなら、画面の数字を手で書き写して確認します。

結果の読み方

集計したら、まず条件の内側のばらつきを見ます。同じ条件の5回の間で、行数や解ける率が大きくばらつくなら、その幅が一語の差より大きくなっていないかを確かめます。条件間の差が、条件内の差の範囲に収まるなら、この規模の実験からは副詞の効果を読み取れません。

差が条件間で一貫して見える場合は、次のように考えます。

• 解ける配置の率やシャッフル方式が条件間で違う場合：副詞が仕様の解釈に影響した可能性があります。ただし、課題は一つだけです。別の課題（たとえば、石を置ける場所の判定が必要なボードゲーム）でも同じ傾向が出るかを確かめるまでは、一般的な傾向とは言えません。
• 行数、コメント、説明文の量だけが違う場合：副詞は文章の手厚さに作用しているが、正しさには作用していない、と読めます。丁寧さの語感が出力に表れた例として扱えます。
• 言葉づかいが変わる場合：「丁寧に」が、コードの作り方ではなく、AIの返答の敬語の度合いとして解釈された可能性があります。日本語の副詞は複数の意味に取れるため、この観点は独立して見ておく価値があります。
• どの項目にも差がない場合：この課題と環境では、副詞が出力を動かさなかったという結果です。これも立派な答えで、「副詞で品質を上げようとするより、条件を文章で明示するほうが確実か」という次の実験につながります。

その次の実験として、条件Dに「配置は必ず完成形に到達できるものにしてください」と明示した文を足し、A・B・Cと比べることもできます。副詞の効果と、明示した要件の効果の大きさを並べて見られます。

起こりやすい誤り

• 副詞以外も変えてしまう。「丁寧に、ていねいに」と表記を揺らしたり、読点の位置を変えたりすると、差の原因が分からなくなります。三つのプロンプトはコピーして使います。
• 1回の出力で判断する。同じプロンプトでも出力は毎回変わります。条件Aの1回目が良く見えても、それは条件の効果とは限りません。
• 条件名を見ながら評価する。「正確に」の出力のほうが正しいはずだ、という期待が採点に入り込みます。ファイル名を乱数にするのは、そのためです。
• 動作確認を1〜2回で終える。解けない配置は半分程度の確率で出るため、数回では見逃すことがあります。20回の試行を省略しないでください。
• 検査関数の前提を確認しない。完成形を「1〜8が並び、最後が空白」以外に置いたコードでは、上の判定は当てはまりません。その場合は、完成形に合わせて並びを読み替える必要があります。
• 日付とモデルを記録しない。同じ文面でも、モデルが更新されれば傾向は変わりえます。結果には使用日とモデル名を添えておくと、後から見返したときに意味を失いません。

次の行動

まず条件Cのプロンプトで1回だけ生成し、上の solvable 関数で、シャッフルの配置を20回確かめてみてください。そこから条件AとBを足し、各5回の表を埋めると、この記事の問いに自分のデータで答えられます。生成したゲームが動いたなら、アソバースにはHTMLの直接アップロードで投稿できます。その場合、入口は直下の index.html にします。比較の基準にしたいときは、公式作品「かたちのあいだ」の3×3の入門を遊び、シャッフル後の配置がどんな手触りかを確かめるのも一つの方法です。