AIに実装を丸ごと任せたら、テストは通ったが画面は誰も見ていなかった

LINEスタンプ用の画像編集アプリを自分で作っている。2026年8月の初め、そこに縦書き機能を足すことにして、初めて「実装を丸ごとAIに任せる」形を試した。設計と計画は Claude Code に書かせ、実装は GPT-5.6 に渡した。私が渡したのは計画書1本だけ。

先に断っておくと、これはAI製品の優劣を比べる話ではない。任せ方と確かめ方の話だ。

きっかけ

それまでは、AIに書かせたコードを私がその場で確認しながら進めていた。それを一段進めて、「計画書だけ渡して、実装は見ずに待つ」をやってみたかった。任せられる範囲が分かれば、副業に使える時間の使い方が変わる。

最初に考えていたこと

計画書に完了条件まで書いておけば、任せきれると考えていた。だから計画書はかなり丁寧に作った。

• 作業を8項目に分割
• 項目ごとに、対象ファイル・変更内容のコードスケッチ・完了と判断してよい条件(実行するコマンド)・失敗時の戻し方・依存する項目を記載
• やらないことリスト(勝手に機能を足さない、などの禁止事項)
• 残してほしい説明コメントの内容(「この処理はこういう理由でこう書く」)。半年後の自分が読むためのもの
• 末尾に、実行するAIへそのまま渡せるプロンプト

実際にやったこと・起きたこと

計画書を渡して、実装が返ってきた。報告は「全項目完了、テスト通過」。コミットは計画の分割に沿って9本。テストは174件から180件に増えて、全部通っていた。報告に嘘はない。

ただ、縦書きは見た目の機能だ。文字の並びが正しく描画されているかを確かめるテストは、増えた6件の中にも、元の174件の中にも、1件もなかった。

つまり「全項目完了・テスト通過」の報告を受け取った時点で、縦書きが実際に縦書きに見えるかどうかは、誰も見ていなかった。私がブラウザを開いて画面を確認するまで、動いているところを見た者がいない状態だった。

もう1つ、抜けが見つかった。計画書に書いておいた説明コメントのうち1件が、コードに残っていなかった。コードそのものは計画どおりで、動きも合っていた。説明コメントは、無くても動く。だから抜けても「完了」になっていた。

最終的に、私の側で調整を1件足して取り込んだ。

原因を調べる

実装したAIの手抜きと言いたくなるが、原因は計画書側にあったと考えている。

1. 完了条件を「テストが通ること」に置いていた。 テストが何を保証していて何を保証していないかを、計画の時点で確認していなかった。描画はもともと自動テストの対象外だったので、「テスト通過」は縦書きの正しさを最初から保証していなかった
2. 「動くこと」だけが完成の定義になっていた。 説明コメントのような、無くても動くものは、その定義の外にある。外にあるものは抜けても完了と報告される

分かったこと

事実: テストは全部通ったが、機能の見た目は未検証だった。指示した説明コメントが1件落ちた。

そこからの解釈:

• テスト通過と正しく動くことは、同じではない。 テストは「テストが検査している範囲」しか保証しない。委任するなら、その範囲を先に把握しておく必要がある
• UIの変更は、視覚的な確認までが受入条件。 「ブラウザで見て確認する」ことを人間側の作業として計画に入れておくべきだった
• 保守性のような非機能の要件は、明示的に受入条件へ入れないと抜ける。 「書いておいて」と本文に書くだけでは、完了判定に含まれない

次からどうするか

計画書の「完了条件」の書き方を変える。

• 自動で確認できる条件(コマンド)と、人間が確認する条件(画面を見る・コメントの有無を確認する)を分けて両方書く
• テストが保証する範囲を計画時に一度確認し、保証されない部分は人間の確認項目へ回す

同じことをする人へのポイント

• AIへの依頼は、指示文の上手さより受入条件の設計で結果が決まる。何をもって完了とするかを先に固定する
• 「テストが通りました」という報告は信じていい。ただしそれは「テストの範囲では正しい」以上の意味を持たない
• 動くことと関係ない指示(コメント・文書・命名)は抜けやすい。受入条件のチェックリストに1行ずつ入れる
• 委任する前に整えるものとして、AIへの常設の指示書を整理した話も書いた(AIへの指示書を72%削った記録)

今回の「確認するまで正しさは分からない」は、この後、運用ルールのチェックを自作したときにも同じ形で現れた。その話は次の記事に書いた。

この記事は、運営者自身の実践記録に基づいています。