AIが作った「動くけれど読めない」コードを、一か月後の自分は直せるか

題材として使う「読みにくいコード」の例

実験にはAIに作らせた自作のコードを使うのが一番ですが、形を揃えるために、読みにくさを模した最小の例を置きます。一つのHTMLファイルで動き、青い的をクリックして点を数えるだけのゲームです。

<!doctype html><meta charset="utf-8"><canvas id="c" width="320" height="200"></canvas><script>
let a=0,b=1200,c=document.getElementById("c"),d=c.getContext("2d"),e={x:60,y:80};
function f(){d.clearRect(0,0,320,200);d.fillStyle="#36c";d.beginPath();
d.arc(e.x,e.y,18,0,6.28);d.fill();d.fillStyle="#000";
d.fillText(a+" / "+(b/60|0),8,12);}
c.onclick=function(g){var h=c.getBoundingClientRect(),
i=g.clientX-h.left,j=g.clientY-h.top;
if(b>0&&(i-e.x)**2+(j-e.y)**2<324){a++;e.x=20+Math.random()*280;e.y=20+Math.random()*160}};
setInterval(function(){if(b>0)b--;f()},16);
</script>

このコードは動きます。ただし、b が何か、324 や 1200 や 60 がどこから来た数字かは、書いた本人でも一か月後には思い出せないかもしれません。読者のコードがこれより長くても、考え方は同じです。

ここで一点、読む練習を兼ねた確認です。b は16ミリ秒ごとに1ずつ減り、画面には b/60 を整数にした値が出ます。「画面の数字が1減る間隔」と「実際に流れる時間」が一致しているかを、計算で確かめてみてください。この食い違いに実験中に気づけるかどうかが、記録の一項目になります。

準備：読まないまま保管する

実験は保管の日に決まります。やることは次の五つです。

1. ゲームを二本用意します。同じ仕様の小さなゲームをAIに二回作らせ、それぞれ別のフォルダーに入れる方法が扱いやすいです。同じコードを二つコピーすると、片方を直した経験がもう片方に影響するため避けます。
2. 一本には「保管メモ」を付け、もう一本には何も付けません。メモは五行以内にし、次の内容を書きます。

• 何を作ったか
• 状態（点数・残り時間・的の位置）がどの変数にあるか
• 時間の単位は何か
• 変えてはいけない場所はどこか
• AIに最初に出した依頼文

1. 変更依頼を三つ決め、紙か別ファイルに書いて封をします。例は次の通りです。

• 制限時間を30秒にする。
• 的を同時に二つ出す。
• 最高点を画面に表示する。

1. 予想を書きます。「それぞれ何分で終わるか」「どの行を触るか」を、コードを読まずに書き留めます。
2. 保管日を決めます。ファイルを日付つきでコピーし、一か月間は触らないことにします。

メモをつけた側と、つけなかった側の差を見るのが、この実験の比較軸です。ただし二本のゲームは細部が違うので、難しさの差が混ざります。一人が一回行う実験では「差の傾向」までしか言えず、厳密な優劣は決められません。この限界は先に認めておきます。

最高点の保存を試す場合は、公開先の仕様も確認してください。アソバースでは、アップロードした作品内のlocalStorageは一時メモリーの互換処理です。端末やクラウドに記録を残したいときは、作品用のSDKとクラウドセーブ（作品ごとにJSONで128KiBまで）を使う設計になります。

一か月後の手順

保管日から一か月たったら、次の順で進めます。途中で順序を入れ替えないでください。記録がぶれます。

1. 封をした変更依頼を開く前に、まずゲームを遊びます。動作を思い出す時間も記録に含めます。
2. 保管メモがない側から始めます。メモがある側から始めると、そこで得た知識が無い側に流れ込むためです。
3. 変更依頼を一つずつ行います。一つ終えたら、動作確認をして記録を取り、次へ進みます。
4. 各依頼の前に、必ずファイルのコピーを取ります。壊れたら戻せる状態にしてから触ります。
5. AIに相談するのは構いません。ただし相談の内容と回数を残します。「読まずに全文を貼る」「読んだうえで該当箇所を貼る」のどちらかに分けて記録します。
6. 一つの依頼に30分かけても終わらなければ、そこで中断して「未完了」と記録します。粘り続けると、残りの記録が崩れます。

予想時間と実際の時間を並べることも忘れないでください。ここで大きく食い違えば、読めないコードに対する自己評価が甘かった可能性があります。

記録の取り方

記録は変更依頼ごとに一行、次の項目を取ります。後から思い出して埋めるのではなく、作業しながら書きます。

• 着手から動作確認まで、単位：分、測り方：タイマーを使う
• 最初に触る場所が決まるまで、単位：分、測り方：「ここだ」と決めた時点で止める
• 触った行数・箇所数、単位：箇所、測り方：差分を見る
• AIに聞いた回数、単位：回、測り方：質問ごとに一回と数える
• AIの提案を採用した回数、単位：回、測り方：貼り付けた回数
• 壊れた回数、単位：回、測り方：動かない、または意図と違う状態
• 戻した回数、単位：回、測り方：コピーから復元した回数
• 数字を理由なく変えた回数、単位：回、測り方：意味を確認せず値を書き換えた場合

最後の項目が、この実験の核です。たとえば制限時間を30秒にするとき、画面に出る数字だけを見て 1200 を 1800 に変えた、という行動を数えます。この変更が正しいかどうかは、前の節の確認をした読者なら判断できるはずです。「合っていたか」ではなく「意味を確かめてから変えたか」を記録してください。

また、AIに聞いた質問文は、そのまま保存します。同じ意図の依頼を言い換えて繰り返していないかが、後で見えてくるからです。

結果の読み方

数字が揃ったら、次のように読みます。結論を一つに決めず、行動のパターンとして見ます。

• 場所を探す時間が長い場合。 動作確認までの時間より、最初に触る場所が決まるまでの時間が大半を占めるなら、問題は修正ではなく地図がないことです。変数名や定数の置き場所を整える対策が効きます。
• 数字を理由なく変えた回数が多い場合。 画面上の値と内部の値の関係を把握せずに触っています。時間の単位をコメントに残す、定数を一か所にまとめて名前をつける、といった対策が候補です。
• AIへの質問が言い換えの繰り返しになっている場合。 依頼の曖昧さが原因か、コードの現状をAIに伝えられていないことが原因です。「このコードを説明して」と先に頼み、理解してから変更を頼む順序に変えると、回数が変わるかを確かめます。
• 壊れた回数と戻した回数が多い場合。 変更が大きすぎる可能性があります。一回の変更を一つの目的に絞り、動かしてから次へ進む習慣が有効です。
• 保管メモありの側が明らかに速かった場合。 五行のメモでも効果がありそうです。ただし二本のゲームが違うので、傾向として受け止め、次回は課題や順番を入れ替えて再確認します。
• メモありとなしで差が小さい場合。 メモの書き方が合っていなかった可能性があります。「何を書けば役に立つか」を、実際に困った場所から見直します。

予想時間との差も見てください。予想より大幅に遅かったなら、読めないコードを抱えたまま作り続けるリスクを、これまでより高く見積もる材料になります。

起こりやすい誤り

実験そのものを歪めやすい点を挙げます。

• 一か月が待てずに途中で開いてしまう。 開いた時点で記憶が戻り、読めない状態ではなくなります。待てないなら、一週間に短縮して期間を明記します。期間が違っても、同じ条件で比較できます。
• 保管メモに答えを書きすぎる。 変更依頼の手順まで書くと、読まなくても直せるので差が出ません。構造の説明にとどめます。
• 変更依頼を先に見てしまう。 保管時に依頼を知っていると、無意識に読みやすい書き方を選んでしまいます。
• AIに作り直させる。 「最初から作り直して」と頼めば課題は消えます。この実験では既存コードを直すことが目的なので、作り直しは別の結果として記録するか、禁止にします。
• 動けば正解と考える。 表示と実際の時間がずれたまま「動いた」と判断するのが典型例です。変更ごとに、数字と体感を照合してください。
• 一回の結果を一般化する。 一人、二本のゲーム、一回の実施では、傾向以上のことは言えません。複数回、または別のゲームで繰り返すと、判断が安定します。

次の行動

今日、手元の小さなゲームを一つ選び、変更依頼を三つ書いて封をし、予想時間をメモしてください。保管日をカレンダーに入れておけば、実験は始まっています。一か月後に開くとき、最初に触る場所を決めるまでの時間を、ぜひ計ってみてください。