「AIが作ってくれたものをどう評価し、どう直させるか」。これが第4日目のテーマです。
AIのアウトプットをそのまま鵜呑みにするのではなく、人間が正しく「ダメ出し（レビュー）」をして磨き上げるプロセスこそが、AIをプロフェッショナルなパートナーに育てるための最も重要な行程となります。
「作っては直し、作っては直し」というプロセスを、短いサイクルで何度も繰り返す手法のことです。
一発で100点を目指そうとすると、プロンプト作りに何時間も悩み、結局ズレた回答が返ってきて絶望します。「60点のものでもまずは出させる」を合言葉に、対話を重ねるほうが圧倒的に早いです。
事務作業に例えると？
1週間徹夜して分厚い資料を出すより、まず手書きのメモ（MVP）を見せて「方向性は合ってますか？」とこまめに上司に確認を取りながら進める仕事術と同じです。
「一度に完成させず、イテレーション形式で進めます。まずは見出しの構成案だけを出してください。私がOKを出してから、第一章の執筆に入ってください。」
AIが受け取った瞬間に「次に具体的に何をどう直せばいいか」が明確に理解できる、ノイズのないダメ出しのことです。
AIは「なんか違う」「ダサい」といった感情的な不満を推測するのが苦手です。感情を抜きにした、純粋な「事実と現象の報告」を渡すことで、AIは迷わず修正に向かえます。
生活に例えると？
後輩の料理に「なんかオイシクない」と言うのではなく、「塩味が強すぎるから、次はお湯を50ml足して薄めてみて」と伝えることです。次にとるべき行動がはっきりしています。
「送信ボタンを押した瞬間に、画面が真っ白になりました。コンソールには『SyntaxError』と出ています。先ほど追加したカンマ（,）の位置が間違っているのではないでしょうか。確認してください。」
コードの理論に頼らず、実際の「見た目」や「動き」を人間の目で確かめる最終チェックのことです。
AIは文字の世界に住んでいるため、「スマホで見るとボタンが重なっている」といった空間的なミスに気づけません。この人間だけの「視覚と感覚」による検証が、AIには代行できない最重要の砦となります。
事務作業に例えると？
エクセルで計算式を組んだ後、「理論上は合っている」と信じるのではなく、試しに数字を入力してみて、合計金額が正しく切り替わるかを実際に目で見て確認する作業です。
「実際の画面で確認（Visual Validation）したところ、送信ボタンが右端からはみ出して半分見えなくなっています。スマホ画面でも中央に収まるようにCSSを修正してください。」
普段は滅多に起きないけれど、もし起きたらシステムが壊れてしまうような「想定外の操作パターン」のことです。
AIは特に指示がない限り、理想的な使い方しか想定しません。わざと変なボタンを押したり、異常な文字を入力したりするケースを潰しておくことで、アプリの壊れにくさが格段に向上します。
生活に例えると？
自動ドアを作るとき、「人が来たら開く」だけでなく、「停電になったら？」「透明なレインコートを着た人が来たらどうする？」まであらかじめ考えておくようなものです。
「通常機能は動くようになりました。では、以下のエッジケースでもエラーメッセージが出るように改修してください。1: パスワード欄に絵文字を入力された場合、2: ボタンを連打された場合。」
修正で迷走し始めた際、安全に動いていた状態まで「勇気を持って撤退」することです。
壊れた上からさらにパッチを当てようとすると、コードが複雑化して修復不能になります。迷走を感じたら、素直に「戻る」コマンドを押すことが、最大の防御策であり近道です。
事務作業に例えると？
Wordで文章をこねくり回して意味が分からなくなった時、慌てて続きを書くのではなく、一旦「元に戻す（Ctrl + Z）」を連打して、ロジックが通っていた時の状態にタイムスリップするのと同じです。
「今回の修正後、画面が起動しなくなりました。このエラーを深追いせず、昨日お願いした『ボタンのデザインを変える前』の安全に動いていた状態までリバート（巻き戻し）してください。」
導入としてAI、Gemini、Antigravityの難しい技術用語を慣れ親しんだ例で解説をする「概念の翻訳書」をご準備しました。Obsidian用に活用できるmdファイルを購入特典として活用いただけます。