想定キーワード
- AI 開発 バグ
- Codex バグ チェック
- AI コーディング 注意点
- AI 開発 検収
- 生成AI 実装 バグ
- アプリ開発 バグチェックリスト
ここでいう道具は、依頼した文章やプログラムを作ってくれるソフトのことです。
道具に頼んでアプリを作る時に一番危ないのは、コードが速く書けることではありません。
危ないのは、作れた気になることです。
CodexやClaude Codeのような依頼するとプログラム作りを手伝う道具は、実装速度がかなり速いです。
画面を作る。
外部に処理を頼むための接続を作る。
フォームを追加する。
エラー表示を整える。
テストコードを書く。
ここまでは、人間だけでやるより圧倒的に速いことがあります。
ただし、道具には弱点があります。
それが 自分で不具合を発見する力の弱さ です。
道具は「それっぽく動くもの」を作るのが得意
道具は、指示された機能をそれっぽく実装するのが得意です。
たとえば、
登録した本人として入る機能を追加して
ファイルアップロードを作って
課金後だけ生成できるようにして
エラー時にメッセージを表示して
と依頼すると、かなりの速度で形にします。
しかし、実際のサービスでは「動く」だけでは足りません。
- 登録した本人として入っていないユーザーが別のサービスへ処理を頼めないか
- 課金前に生成処理が走らないか
- 決済失敗時に状態が壊れないか
- ウェブで前のページへ戻った時に二重送信されないか
- 同じ内容を複数のページで同時に開いた時に不整合が起きないか
- 無料枠を何度も使われないか
- 別のサービスへ処理を頼んで失敗した時に課金だけ発生しないか
- スマホ表示でボタンが隠れないか
こういう部分は、道具が自動で完璧に見つけてくれるとは限りません。
速く作る道具と確かめ方
道具に頼んでアプリを作る時には、人間の役割が変わります。
昔は、人間が実装者でした。
これからは、人間は 設計者・できたものを確かめる人・いつもと違うことに気づく人 になります。
道具に速く作ってもらうなら、人間は、正しくできたか確かめる項目と手順を決める必要があります。
速く作る道具:
速く作る
人間:
何が正しい状態か決める
壊れてはいけない条件を定義する
いつもと違う入力や操作をした場合を確認する
課金・権限・情報や操作を不正に使われないことを確かめる
この役割分担がないと、道具が作ったものをそのまま信じてしまいます。
道具が見逃しやすい不具合
道具が特に見逃しやすいのは、次のような不具合です。
1. 画面と保存された記録で、途中や完了の状態が食い違う問題
画面上では完了に見えるが、保存された記録では未完了。
支払いは完了したが、利用権限が付与されない。
エラー後に「処理中」のまま戻らない。
画面と記録などで状態が食い違わないか、人間が利用者の一連の操作を試して確かめる必要があります。
2. 課金・権限の不具合
別のサービスへ料金を払って文章や画像を作ってもらう仕組みでは、支払いの処理や使える範囲の不具合が致命傷になります。
- 無料ユーザーが有料機能を使える
- 決済前に生成処理が走る
- 複数アカウントで無料枠を無限利用できる
- 使用量上限が効いていない
- 外部へ払う費用が売上を超える
これは「少しの不具合」ではなく、赤字リスクです。
3. いつもと違う入力や操作をした場合の不具合
正常な入力では動く。
でも、空欄、長文、絵文字、巨大ファイル、通信断、ページの読み直し、戻るボタンで壊れる。
道具は通常ケースをきれいに作りますが、いつもと違う入力や操作をした場合は人間がかなり細かく洗う必要があります。
4. 画面の見た目や操作と、次に進むまでの案内の不具合
機能はある。
でも、ユーザーが気づけない。
ボタンが押しにくい。
スマホで崩れる。
エラー文が分かりにくい。
次へ進む案内やボタンが記事の最後にしかない。
道具は実装完了と言っても、ユーザー体験としては未完成なことがあります。
作ったアプリを確かめるチェックリスト
道具に実装を任せるなら、最低限こういうできたものを確かめる項目を持つべきです。
□ 想定した普通の入力や操作をした場合は動くか
□ 登録した本人として入っていない時の挙動は正しいか
□ 無料ユーザーと有料ユーザーの権限差は正しいか
□ 決済前に有料処理が走らないか
□ 決済失敗時に権限が付与されないか
□ 別のサービスへ頼む処理の量の上限は効いているか
□ 異常利用時に停止できるか
□ 空欄・長文・特殊文字で壊れないか
□ ページの読み直し・戻る・二重クリックで壊れないか
□ スマホ表示で主要ボタンが見えるか
□ エラー文はユーザーに分かるか
□ 動作や出来事の記録は残るか
□ 実際に使う場所の設定が正しいか
道具に「不具合を探して」と言うだけでは弱いです。
人間が完成条件を渡す必要があります。
まとめ
道具はコードを書くのが速いです。
でも、道具は自分で致命的な不具合を見つけるのが得意とは限りません。
道具に頼んでアプリを作る時に重要なのは、実装速度ではなく、できたものが正しいか確かめる力です。
作るのは道具。
壊れてはいけない条件を決めるのは人間。
実際に使い始めてからサービスを止めてしまう不具合を見つけるのも人間。
道具に頼んでアプリを作ることの本当の勝ち筋は、道具に丸投げすることではありません。
速く作る道具を使いながら、人間が確かめ方を持つことです。
次にできること
道具で作ったネット上のサービスや業務ツールは、作る前に完成条件を決めることが重要です。
手順書作成・チェックリスト化・できたものを確かめる手順の整理には、道具で手順を文書化する仕組みも活用できます。
