コード書き始めたら絵が出てくる。オープンなAIが有料版に肩を並べた

『評価基準表』って、具体的には何をチェックするリスト？プログラムが動くかどうかだけじゃなく、何を見てるの？

「評価基準表」は、AI が生成したコードを採点する際に、複数の観点から同時にチェックする採点表だと考えるといいですよね。 プログラムが動くかどうかは最低条件。そこに加えて、たとえば「ボタンの配置は指示通りか」「余白や色使いは見栄えの良さを満たしているか」「変数名は分かりやすいか」「関数は適切に分割されているか」みたいに、実際に画面に表示した時の見た目と、コード自体の読みやすさや保守性までを項目化して評価する。 こうすることで、従来は『コードが実行できるか』と『見た目が正しいか』を別々に判定していたのを、学習の段階で一緒に高めることができる。AI は「この配置だと見栄えが悪くなる」「この書き方だとコードが読みにくい」という多角的な反省を繰り返すことで、有料版と同じ精度に近づいていくわけです。単純に「動けば正解」ではなく、「ユーザーが実際に使って満足する」レベルまで求める基準表だと言えそうです。

プログラミング未経験の人でも、『ボタン3つのページ作ってほしい』と AI に説明するだけで、自分で使えるコードが手に入るってこと？

そう、ほぼそういうことになりつつあります。ただ「手に入る」と「自分で使える」のあいだに、小さくも大事な隙間があるように見えます。 AI が返してくるコードは、確かに動きます。見た目も整ってる。でも自分のサイトに組み込むとき、フォントを変えたい、色を足したい、ボタンの並び方を微調整したい——そういう細かい修正が出てくる。その瞬間、「コード読めない」と「コード読めない→もう一度 AI に頼む→ループ」の分岐に立つわけです。 未経験者にとって本当に救いになるのは、むしろ「AI が返したコードの何が何をしてるのか、ざっと理解できる」状態かもしれません。完全に自力で書く必要はないし、AI の出力を丸呑みするのではなく、「あ、こここういう仕組みか」と読める力があれば、修正したいときに「ここを変えてほしい」と具体的に指示できる。 結局、AI のコード生成は、プログラミングの「敷居」を下げたというより、「入口」を広げたんだと言えそうです。最初の一歩は誰でも踏み出せるけど、その先で少しずつ理解が必要になってくる、という意味で。

従来はなぜ『動くこと』と『見た目』を一緒に評価できなかったの？技術的な壁があったの？

評価の対象が根本的に異なってたんですよね。『動く』はプログラムを実行して結果を数値化できるけど、『見た目が整ってる』は人間の主観が入る。これまでの AI 学習では、後者をデータ化しにくかったわけです。 従来のアプローチは、生成されたコードと「正解のコード」をテキストで比較する方法ばかり。でもウェブページなら、同じ見た目を作る方法は無限にあって、別の書き方なら「間違い」と判定されてしまう。実際に画面に表示させて『この見た目になってるか』を確認するステップが、学習プロセスに組み込まれていなかったんです。 PrismaCoder が変えたのは、この『実行結果の見た目も含めて評価する』という当たり前のようでいて、実は複雑な判定を、チェックリスト化することで整理した点。プログラム実行、コード品質、ビジュアル表現の三つの軸をそれぞれ独立したデータとして扱えば、AI も学習しやすくなる。つまり技術的な壁というより『評価軸をどう設計するか』という設計思想の問題だったのかもしれません。

つまりこれって『複数の評価軸をバラバラに学ばせるより、一気に学ばせた方が質が上がる』ってパターン？

逆なんですよ。PrismaCoder が工夫したのは「バラバラに学ばせる」方です。 従来は AI が学習するときに「このコードは正解か不正解か」という二者択一の信号だけ受け取ってた。でも現実のコード生成には三つの次元がある。プログラムとして動くか、コードとして上質か、ビジュアルが正しいか。この三つは別々の理屈で成り立ってるんです。 「評価基準表」の導入って、実は学習データ作成の段階で、この三つの次元ごとに「何が正解なのか」を明確に記録するということ。AI は「ボタンが3つのコード」という指示に対して、学習中に「動作テストには合格、でも CSS が冗長、でも配置は正確」みたいな多次元的なフィードバックを受ける。 すると AI は、動きと美しさとコード品質のトレードオフを理解しながら学べる。一つの統合的な目標じゃなく、複数の目標を同時に追うことで、むしろ各項目の精度が上がる。人間が何かを上手くなるときも、フィードバックが細かいほど伸びが早い、みたいな話に近いのかもしれません。

コード生成 AI が精度を上げると、実は困る人たちもいるんじゃないの？プログラマーの仕事の奪い合いになるリスクは？

コード生成 AI の精度向上が「プログラマーの仕事を奪う」という心配は、表面的には理解できるんですが、実際の業界の動きを見ると少し違う感覚が生まれています。 むしろいま起きてるのは「作業の質が変わる」という話に近くて。従来は『動くコードを書く』こと自体に時間と知識を費やしていたのに対して、AI に任せられるようになると、プログラマーの仕事は『何を作るべきか』『デザインと機能の整合性をどう取るか』『想定外の挙動にどう対応するか』という、より上流の判断と調整へシフトしていく。つまり単純な「仕事の削減」ではなく「仕事の内容が変わる」段階にあると言えそうです。 困るのは、むしろ『コードを早く正確に書く能力だけ』を唯一の価値にしてきた層かもしれません。あるいは、発注側が「AI で充分じゃん」と判断して、品質管理や全体設計といった高度な判断をショートカットしたときに、プロジェクト全体が脆くなるという形での困難もありそうです。技術の進化そのものより、それをどう使うかの組織判断の方が、プログラマーのキャリアを左右する要素になりつつあるのかもしれません。