Claude・GPT・Geminiが揃って見逃したPHPのわなを、全盲クリエイターが見つけた話
🔎 「画面に変な文字が出てる」と気づいた日のこと
先日、日本語点字Web変換ツールを公開した記事を書きました。
その中で、「コメントの一行が原因で、画面に変な文字が出てしまった」と少しだけ触れました。
今回は、その話をもう少し詳しく書きます。
公開前の最終チェックを、ローカルのWAMP環境でしていたときのことです。
WAMPというのは、自分のパソコンの中でPHPを動かすための環境です。
ブラウザで確認していると、スクリーンリーダーが、本来なら読み上げないはずの文字列を読み上げました。
「でPHPモードを抜けて直接出力される」
そんな音声が、耳に届きました。
最初は、何か聞き間違えたのかと思いました。
コメントアウトと呼ばれる、本来は画面に表示されないはずの説明書きが、なぜか読み上げられている。
しかも、このベースコードを書いたのは、コーディングにかなり強いモデルとして使っていたClaude Opus 4.7でした。
私はこのモデルと一緒に、かなり難しいコードも形にしてきました。
だからこそ、まさかと思いました。
でも、コードを確認すると、コメントの中に、PHPでは入れてはいけない文字がはっきり混ざっていました。
最新のAIで、これはいただけないな。
その場で、率直にそう思いました。
これが、今回の話の始まりです。
🛠️ 小さなWebアプリと、AIの相棒
冒頭で触れたWebアプリは、Claude Codeと一緒に作った日本語点字Web変換ツールです。
開発の経緯はこちらの記事にまとめています。
私はプロのプログラマーではありません。
コードを5年以上見てきましたが、隅から隅まで自力で書ける人間でもありません。
それでも、結果がおかしいことだけは分かりました。
画面に出るはずのないものが出ている。
それは、私にもはっきり分かりました。
🤖 4つのAI環境に聞いてみた
私は自分で原因の見当をつけて、問題のコメント行を削除しました。
そのうえで、Claude Codeに「ここのPHPの仕様が原因では？」と聞きました。
すると、原因の見立ては合っていると返ってきました。
直し方も間違っていませんでした。
ここまでなら、ただのバグ修正の話です。
でも、私の中には小さな引っかかりが残りました。
「これ、ほかのAIなら気づくのかな」
試してみました。
ChatGPTのGPT-5.5 Thinkingに、同じコードを見せました。
気づかない。
Codex上のGPT-5.5にも見せました。
気づかない。
GoogleのGemini 3.1 Pro（プレビュー版）にも見せました。
気づかない。
そして、最初にこの行を書いたClaude Opus 4.7も、生成の時点ではそこを指摘できていませんでした。
私が試した範囲では、4つのAI環境が同じわなを見落としたことになります。
その事実を、しばらく考え込んでしまいました。
🧠 なぜ、AIは揃って気づかないのか
たぶん、こういうことだと思います。
AIは、世界中のプログラムを学習して育っています。
正しく動くコード。
エラーを直したコード。
便利な書き方。
よく使われるパターン。
そういうものは、たくさん見ているはずです。
でも、ベテランが無意識に避けていることは、わざわざ文章にしません。
最初から書かれないものは、失敗例としても残りにくい。
だからAIも、そこを学びにくいのだと思います。
今回のことで、AIの盲点は、人間の暗黙知のまわりに出やすいのでは？ と思いました。
ここから先は、少し技術寄りの話に切り替えます。
中身を知りたい方は、もう少しお付き合いください。
📜 PHPの仕様と、何が起きていたか
PHPは、Webサイトの裏側でよく使われる言語です。
たとえば、世界中のブログで動いているWordPressは、裏側がPHPで作られています。
日本の大手Webサービスでも、長くPHPが採用されてきました。
ファイルの中で、PHPのプログラムを書く場所は「<?php」で始まります。
そして、「?>」でPHPの場所が終わります。
ざっくり言うと、その間がプログラムです。
その外側は、ブラウザに見せるHTMLとして扱われます。
プログラムの中には、人間用のメモを書けるコメントという機能があります。
「//」を行の途中に書くと、そこから先は説明書きとして読み飛ばされます。
書き方は違えど、これは多くの言語で見かける、かなり基本的な書き方です。
ところがPHPでは、ここに落とし穴がありました。
「//」コメントの中に「?>」が出てきたら、そこでPHPのブロックが終わります。
行末まで待ってくれません。
「?>」を見た瞬間に、PHPから抜けてHTML側に戻ります。
問題のコメントは、Claude Codeがこんな書き方をしていました。
「以下のHTMLは ?> でPHPモードを抜けて直接出力される。」
要するに「ここから先はHTMLですよ」と、開発者向けに親切に説明する一文です。
説明文の中に、「?>」という文字が入っていました。
PHPはこれを「プログラムの終わり」と解釈し、それ以降をHTMLとして画面に流してしまいました。
その結果、本来なら画面に出ないはずの説明書きの一部が、ユーザーから丸見えになりました。
スクリーンリーダーが私の耳に届けたのは、まさにその音声でした。
👨💻 エンジニアならかなり早い段階で避けるミス
ここで一度、立ち止まらせてください。
私はプロのプログラマーではありません。
それでもコードを5年以上見続けてきました。
その私から見ても、これはかなり危ない書き方です。
PHPに慣れている人なら、書いた瞬間に違和感を持つタイプのミスだと思います。
というか、コードを書く以前の問題です。
🚨 危険①: 重要な情報が漏れる
ここからは、今回の小さな表示ミスが、条件によってはどんな危険につながるのかを、少し大きめに考えてみます。
仮に、こんなコードがあったとします。
<?php
// 開発メモ?> 管理者の連絡先: admin@example.com
$user = getUserById($id);
?>開発者は、自分用のメモのつもりで書いたとします。
でも、途中の「?>」でPHPが終了してしまいます。
すると、その後ろの文字はHTMLとして扱われます。
画面には、こんなものが出てしまいます。
管理者の連絡先: admin@example.com
$user = getUserById($id);
?>連絡先も、その下のコードらしき文字も、外に見えてしまいます。
「PHPはサーバー側で動くから、中身は外から見えない」
その常識が、たった一行の書き方で崩れます。
もちろん、普通はコメントにパスワードや個人情報を書くべきではありません。
でも、開発中のメモには、つい人間の油断が出ます。
だからこそ、この手の書き方は、コメントであっても残さないほうが安全です。
⚠️ 危険②: 設計によってはコードインジェクションの入口になる
もう一段だけ、深い話をします。
ユーザーの投稿を、PHPファイルの中に何らかの形で保存する仕組みを想像してください。
普通なら、コメントの中に入れているから安全に見えるかもしれません。
でも、そこにPHPの終了タグが混ざると、話が変わります。
たとえば、こういう文字列です。
こんにちは ?> <?php echo "ここはPHPとして動きます"; ?>「?>」でPHPブロックが終わります。
その直後に、また新しいPHPブロックが始まります。
この例では、ただ文字を出すだけです。
でも、もしここに危険な命令が入っていたら、設計によってはサーバー側で意図しない処理が動く可能性があります。
これが、コードインジェクションにつながる考え方です。
コメントは安全地帯ではありません。
今回の件で、私はそこをかなり強く意識しました。
🛡️ 防御は意外とシンプル
今回の問題だけに限れば、防ぎ方はかなりシンプルです。
「//」コメントの中に「?>」を書かない。
説明として「?>」に触れたいなら、コード内にそのまま残すのではなく、表現を変える。
PHPだけのファイルなら、最後の終了タグを書かない運用もあります。
そして、もっと大事なのは、ユーザー入力をPHPファイルの中に混ぜないことです。
とくに、あとから実行される可能性のある場所に、ユーザー入力をそのまま入れない。
慣れているエンジニアは、このあたりをルールとして体に染み込ませているのだと思います。
でも、体に染み込んだルールほど、わざわざ文章にはなりません。
文章にならないものは、AIも拾いにくい。
ここに、今回の見落としの根っこがあるように感じました。
💭 もうひとつ、気になっていること
今回のわなに気づけたのは、PHPという言語の性質も関係していたと思います。
PHPは、動かすまでに少し手間があります。
ローカルで確認するには、WAMPやXAMPPのような環境を用意します。
サーバーを起動する。
ファイルを置く。
ブラウザでアクセスする。
そこでようやく確認できます。
この手間は、正直めんどうです。
でも、そのめんどうさが、今回は最後の安全網になりました。
公開前に必ず動作確認をします。
その場でスクリーンリーダーが違和感を拾ってくれました。
だから、私は止まれました。
一方で、HTMLやJavaScriptには、この摩擦があまりありません。
ファイルを開けば、ブラウザがそのまま動かしてしまうことも多いです。
AIエージェントがHTMLやJavaScriptをどんどん書いていく時代に、これは何を意味するのか。
「動いた」と「正しい」の境目が、かなり曖昧になるということだと思います。
書いた瞬間に動くコードは、人間が立ち止まる時間を減らします。
今回のわなに気づけたのは、たまたまPHPだったからかもしれません。
もしこれがJavaScriptだったら、私は同じように止まれたでしょうか。
✋ 技術の話はここまでです
私は、プロのエンジニアではありません。
それでも今回、4つのAI環境が見逃したものを、最初に見つけて直したのは私でした。
なぜ気づけたのか。
スクリーンリーダーが、画面に出たものをそのまま読み上げてくれたからです。
そして、「これはおかしい」と止まる感覚が、自分の中で働いたからです。
AIに任せる仕事が増えるほど、人間の役割は減っていく。
そう言われることがあります。
でも私は、たぶん逆だと思っています。
AIが書いたものを、最後に「これでいいのか」と判断するのは人間です。
その判断には、コードを全部読める力だけでなく、違和感に気づく感覚が必要です。
ベテランエンジニアの暗黙知は、AIの中に完全には残らないのかもしれません。
でも、人間の中には残ります。
そして、私のような全盲のクリエイターでも、AIと組めば、AIが見落としたものを見つけられることがある。
そんな時代になってきたのだなと、しみじみ思った夜でした。
🎬 見えない映像クリエイターが作った動画
AIを「生み出すツール」ではなく「できないを取り去るパートナー」として語る、全盲クリエイターの映像制作論です。AIが見逃したPHPのわなを全盲の視点が拾い上げた今回の話と同じく、見える側と見えない側がたがいに補い合う関係を描いた一本になっています。
https://www.youtube.com/watch?v=IH1r1bG4ypM
📎 お時間があればこちらの記事もぜひ
AIに任せきりにせず、人間の目（耳）で最後を確かめる――今回の記事と同じ姿勢で書いた一本です。全盲クリエイター二人がAIを使って記事を書いた裏側です。
AIは本当に万能なのか？「騙される」AIを実際に検証した記事です。今回のPHPのわなと同じく、AIの限界に踏み込んで確かめてみた回です。
OpenAIが白旗を上げた日――AIは本当に「騙される」のか、検証してみた
コードが読めなくてもAIと一緒にスクリプトを作れる、という入り口の記事です。今回のPHPデバッグ話と合わせて読むと、AIとコードを書く距離感が見えてくると思います。
コードが読めなくても大丈夫。AIと作るブックマーク整理スクリプト
