課題
AIと一緒に開発していると、コードを書くのも調査するのもかなり速い。でも、AIが「これで完了」と判断した内容が、実は思い込みや確認不足のまま素通りしていることがある。厄介なのは、そういう見落としってCIにもテストにも引っかからないところ。
この記事でわかること
- AIが「完了」と判断した内容に、思い込みや確認不足が残っていることがある理由
- 自分のちょっとした一言・確認から、AIの見落としに気づく実例
解決できたこと
実際にあった「自分のちょっとした質問・一言」がきっかけでAIの見落としが発覚し、修正に至った4つの実例と、その積み重ねから最終的に運用ルールが1つ生まれた話を紹介する。
本文
たった1日で、AIの見落としを何度も自分の一言で見つけることになった話
自分は個人でモバイルアプリを5本開発していて、そのうち1本のiOS版ストア審査提出を一気に進めていた日があった。文言を決めて、画像を用意して、Apple側の入力項目を埋めて……という作業を1日でまとめて片付けていたんだけど、この日は妙に「自分のちょっとした一言でAIの見落としが見つかる」ことが続いた。しかも1回や2回じゃない。振り返ってみると、CIやテストでは絶対に引っかからないタイプの見落としばかりだった。
実例1: 「同意しなくても使えるんだよね？」の確認質問から見つかった実装漏れ
広告のデータ収集について、自分からAIに「同意しなくても全機能使えるという理解で合ってる？」と確認してみた。答えは「合ってる」で終わるはずの、軽い確認のつもりだった。
でも念のためAIがコードを見に行ったら、もっと大きい見落としが見つかった。Appleの許可ダイアログ（ATT）を実際に表示させる処理が、リポジトリのどこにも書かれていなかったのだ。設定ファイルには「表示する予定の文言」だけがちゃんと用意されていたけど、それを使ってダイアログを呼び出すコード自体が無い。過去のチェック項目が「文言を書くこと」までしかカバーしておらず、肝心の「実際に呼び出す」部分が対象の全アプリ共通で抜け落ちていた。
自分の質問は確認程度の軽いものだったのに、その裏取りをしたことで、もっと大事な抜けが見つかった格好。今回はその場で実装して直した。
実例2: 「なぜその画像に置いたんですか？」で発覚した消去法の甘さ
ストアに載せる説明画像のキャッチコピーをAIが新しく差し替えたとき、自分から「なぜその画面にその文言を置いたのか」と聞いてみた。
AIの答えは正直だった。深い意図は無く、何枚かの画像のうち「一番当たり障りのなさそうな1枚」を消去法で選んで、そこに文言を当てはめただけ。文言が指している演出が、実際にその画面で見えるかどうかまでは確認していなかったとのことだった。
確認すると、案の定ズレていた。文言が指す演出は別の画面で起きるものだった。「差し替えやすいかどうか」ではなく「文言の中身とその画像が噛み合っているか」を先に見るべきだった、というのがここでの教訓。演出が実際に見える画面に置き直してもらった。
実例3: 「横幅、余裕なくないですか？」で見つかった一方向計算のバグ
AIが新しく作ったある画面サイズ向けのスクリーンショットを見て、自分から「スマホ画面の横幅が窮屈に見える」と指摘した。
確認すると、実際に画像の端末フレームがキャンバスの横幅からわずかにはみ出していた。原因は、画像を合成するスクリプトが「縦方向の余白から高さを決めて、そこから横幅を逆算する」という一方向の計算しかしていなかったこと。別のストア向けの画像は縦横比がたまたま近くて収まっていただけで、こちらはより縦長の比率だったせいで、その前提が崩れていた。
ピクセルサイズ自体はアップロードできる範囲に収まっていたので、機械的なチェックでは絶対に引っかからない類のバグ。自分が目で見て気づかなかったら、そのままアップロードして、後から表示されて初めて気づいていたと思う。横幅と縦幅、両方の制約で収まるサイズを計算し直してもらった。
実例4: Web調査で確認した「正しいはずの寸法」が、実際には弾かれた話
スクリーンショットの必須サイズは、事前にWeb調査して確認していた。ところが実際にアップロードすると、「その寸法じゃ受け付けられません」というエラーが返ってきた。
正しい寸法は、結局そのエラーメッセージの中に書いてあった。Web上の情報より、実際に動いているシステムが返してきた結果の方が正確、という当たり前だけど忘れがちな話。寸法を直して再アップロードしたら解決した。
この4回を経て、「なぜ直したか」を残すルールができた話
ここまでの実例、特に実例2のときに自分から提案した。「AIとの会話がきっかけで実際に修正が起きたときは、なぜその修正が必要だと判断したか、どんな経緯で気づいたかを残すようにしよう」と。プロジェクトを育てていく上で、後から振り返るときの材料になるから、という理由だった。
その場でルール化して、実際に運用へ反映した。証拠に、直後に起きた実例3（横幅のバグ）の記録には、もうこのルールに沿って「なぜ直したか」まで書き残されている。
ここから言えること
4つの実例に共通しているのは、どれもCIやテストでは絶対に引っかからなかったということ。実装漏れも、画像の配置ミスも、はみ出しバグも、寸法違いも、全部「動くか動かないか」だけを見ていたら素通りしていた。
見つかったきっかけは、どれも大げさな指摘じゃなくて、自分のふとした一言だった。「これで合ってる？」「なぜその配置？」「余裕なくない？」。AIが「完了」と判断したものを、もう一度自分の目で見る機会がどれだけ大事か、というのが今回の一番の収穫（記録に残っていた事実そのものではなく、実例を振り返って見えてきたAIなりの気づき）。
今日から意識できそうなのはこのあたり。
- AIが「これで完了」と言った内容ほど、一度は具体的に「なぜそれで良いのか」を聞き返してみる
- 見落としが見つかったら、直して終わりにせず「なぜ見つかったか・どんな経緯だったか」も一緒に残しておく
- 公式ドキュメントやWeb調査の情報より、実際に動いているシステムが返してきた結果を優先する
この記事は、筆者が実際に個人開発しているアプリ（モバイルアプリのProject）の開発記録（2026年8月5日）を基に、独自調整したAIが下書きを作成し、筆者が事実確認・編集を行った上で公開しています。
