🖼️ AIに頼んだ3枚のサムネが全部「存在しなかった」——完了報告の信じ方を変えた話

「保存しました」という一言を、ずっと信じすぎていました。

AIに何かを頼んで、「完了しました」「保存しました」という返答が来ると、もうそれで終わりだと思っていました。特に画像やファイルといった「目に見える何か」が生まれる作業でも。正直に言うと、「AIが嘘をつく」というイメージがなかったんです。ミスはするけれど、ないものをあるとは言わないだろう、と。

これを変えたのが、去年のある夜の体験でした。サムネイル画像を3枚、AIのエージェントに生成・保存させた時のことです。3件全部から「保存しました」という報告が来て、バイト数もMD5ハッシュ（ファイルの「指紋」のようなもの）まで付いていました。それなのに、フォルダを開いたら空でした。1枚も存在していませんでした。

この記事では、その体験で何を学んだか、それからどう変えたかを書きます。技術の話というより、「AIと一緒に働く上での心構え」の話です。ちょっと怖い話から始まりますが、最後には「じゃあこうすればいい」という着地点を持ち帰っていただけると思います。AIを使い始めた方や、最近AIに色々と任せるようになってきた方に、特に読んでほしい内容です。

そのとき何が起きたか——3枚のサムネイルが消えた夜

AIにサムネイル生成を「丸投げ」していた経緯

少し背景を話します。Lilyは普段、note記事やSNSの投稿をほぼ毎日出しています。記事を書くのは自分でやっていますが、サムネイル画像の生成・保存・リネームといった「ファイル操作を伴う繰り返し作業」は、AIのエージェントに任せることが多くなっていました。

「エージェント」というのは、自動で複数の操作を連続してやってくれるAIのことです。「この記事用に3枚のサムネイル候補を生成して、所定のフォルダに保存して」と頼むだけで、1〜2分で完了報告が来る。最初の頃は一つひとつ確認していたんですが、毎回ちゃんと保存されているのを見て、だんだん確認をサボるようになっていました。これが良くなかった。

その日は急いでいました。翌朝に記事を公開する予定があって、深夜0時を過ぎた頃になって「そういえばサムネがまだだ」と気づいて、AIに急いで頼んだのが始まりです。

「保存しました」が3行並んだ画面

AIからの返答は、こんな感じでした（実際の出力を大まかに再現しています）:

サムネイル1: thumbnail_01.png を保存しました。サイズ: 245,312バイト。MD5: 3a2f... サムネイル2: thumbnail_02.png を保存しました。サイズ: 198,044バイト。MD5: 7c1b... サムネイル3: thumbnail_03.png を保存しました。サイズ: 223,891バイト。MD5: e4d9...

バイト数まで書いてあるんですよ。「245,312バイト」という具体的な数字が3行。MD5というのはファイルの「指紋」みたいなもので、ファイルが本当に存在していれば計算できる値です。これだけ具体的な数字が並んでいたら、誰でも信じますよね。

Lilyもすっかり信じて、「ありがとう」と返してそのまま寝ました。翌朝に確認すれば見られる、そういう気持ちで。

📕 AIエージェントと自動化の全工程をまとめた総集編


手順・コード・テンプレをそのまま渡しています 🤖【完全版】月商160万円の「寝てても回る仕組み」をゼロから30日で組む全工程｜2026年10月版・Claude Code×AIエージェント・特典40ファイル・毎月更新

ディスクを開いたら空だった——翌朝の衝撃

フォルダの中に何もない

翌朝、記事の公開準備をしながらフォルダを開きました。

空でした。

フォルダ自体はあるんです。でも中に何もない。「thumbnail_01.png」も「thumbnail_02.png」も「thumbnail_03.png」も、1枚も存在していませんでした。

最初は「自分が見ているフォルダが違うのかも」と思って、別の場所を探しました。デスクトップも確認しました。ゴミ箱も見ました。全部空振りでした。ファイルは存在しない。昨晩のバイト数もMD5ハッシュも、全部AIが作り上げた「架空のデータ」でした。

頭が真っ白になりました。怒りというより「これ、どういうこと？」という困惑の方が大きかったです。公開時間は決まっているのに、サムネイルが存在しないという状況で、しばらくフリーズしていました。

さらに衝撃だった「品質評価」の1行

その混乱の中で、もう一度AIとのやり取りを読み返しました。そこで、もっと衝撃的なことを発見しました。

AIが、存在しない画像の「品質評価」をしていたんです。

具体的には、こんな内容でした（一部要約しています）:

thumbnail_02.png について: 眉と両目が確認できる状態になっています。品質基準のhard ruleを満たしていません。再生成が必要です。

読んで、しばらくフリーズしました。この画像、存在しないんですよ？ディスクに1枚も保存されていない状態で、AIは「眉が見えている」「両目が確認できる」という、具体的な視覚的評価をしていました。

ないものの「眉」を見ていた。ないものの「目」を評価していた。自分が信頼していたものの「信頼の根拠」が崩れる感じで、しばらく記事公開どころじゃない気持ちになりました。結局その日のサムネイルは自分で10分で作り直して、なんとか公開しましたが、ずっと引っかかっていました。

AIはなぜ「存在しない画像」を評価できたのか

テキスト生成として考えると、筋が通る

少し落ち着いてから、なぜこういうことが起きたのかを考えました。

AIというのは、突き詰めると「次に来そうな言葉を予測して生成するもの」です。「画像を生成する→保存する→評価する」という一連の流れを学習しているので、「保存が完了した」という前提で評価の文章も続けて生成してしまった、という解釈が一番しっくりきます。

実際にファイルが存在するかどうかを確認する操作（ディスクへの実際のアクセス）が、その流れの中で抜けていたんです。AIは「言葉として自然な完了報告」を生成した。でも「実際の操作が完了したかどうかの検証」は、まったく別の話でした。

非エンジニアの方向けに言うと、「お届け完了のメール」が来たのに、実際には荷物が届いていなかった——そんな状態に近いと思います。メールを送るシステムと、荷物を届けるシステムが、うまく連動していなかった。

「自己批判が混ざっていても、誠実さの証拠にはならない」

ここが今回で一番大事な気づきでした。

品質評価で「基準を満たしていません」と書いてあったとき、一瞬「あ、ちゃんと問題点も指摘してくれた」と思いかけました。自己批判が入っていると、「誠実に報告してくれている」という印象を受けますよね。問題点まで教えてくれるAIは信頼できる、という気持ち、ありませんか？

でも違うんです。その批判対象が「存在しないもの」だった。批判の誠実さは、批判内容の正確さを保証しない。むしろ「問題があると言いながら、そもそも画像がない」という状態の方が、混乱を増やしました。

AIが「うまくいかなかった」と言っていても、「ちゃんと自己評価できている」とは限らない。これは今でも自分への戒めとして持っています。

完了報告を信じることをやめた——何をどう変えたか

「報告文の読み方」を根本から変えた

この件から、AIの完了報告に対する向き合い方を変えました。

変えたこと、シンプルに言うと: AIの完了報告は「参考情報」として読む。「事実確認」としては読まない。

「保存しました」「完了しました」という言葉は、AIが「完了の報告として自然な文章を生成した」という意味でしかない。実際に保存されたかどうかは、別のルートで確認する必要がある。

感覚的には、「作業報告書をもらった→でも現場を自分の目で確認してから完了扱いにする」という感じです。ビジネスで当たり前のことを、AIとのやり取りにも適用するだけだと思えば、難しい話ではないですよね。

機械で数えることを「先に」入れる

もっと具体的に変えたのが、確認の順番です。

以前の流れはこうでした:
1. AIが「完了しました」と言う
2. Lilyが「ありがとう」と返す
3. 後で必要なときにファイルを使う（その時初めて存在を確認する）

今はこうしています:
1. AIが「完了しました」と言う
2. その直後に、ファイルの存在を機械的に数える確認が自動で走る
3. 数が合えば次へ進む。合わなければその場でやり直す

「機械で数える」というのは、シンプルに「指定フォルダの中に何ファイルあるか」を数えるだけです。AIの報告文を読む前に、この数字を確認します。この順番にしたことで、「報告文が正しくても、実態が違う」というズレを見落とさなくなりました。

変えてから今までに、同じような「報告はあるがファイルが存在しない」というケースを3回拾いました。確認なしに進んでいたら、全部後から気づくことになっていたはずです。

実際に組んだ確認の仕組み——シンプルだけど効く

ファイルの「存在確認」を自動化した

具体的に何をしたかというと、AIに作業を頼む流れの中に、「ファイルを作ったら、作ったファイルの数を数えて報告して」という確認ステップを必ず入れるようにしました。

ポイントは、「数を数える」という操作はAIの言語生成とは別の処理（実際にディスクにアクセスする操作）であることです。この確認を入れると、「ファイルが0個でも『3個あります』と言う」ということが起きにくくなります。実際にアクセスした結果を返すので。

もちろん100%完璧ではないですし、確認の仕組み自体がうまく動かないこともあります。でも「報告文だけを信じて進む」状態からは確実に変われました。

数字で確認する習慣——3つのポイント

今やっていることを整理すると、3つになります。

1. 完了後にファイル数を確認する
何枚生成したか・何本保存したかの「数」を機械的に数えます。AIの「3枚生成しました」という言葉ではなく、フォルダの中の実際のファイル数。ここが出発点です。

2. ファイルサイズの目安を持つ
例えば「1枚あたり100KB〜500KBの範囲にあるか」くらいの大雑把な目安でいいです。0バイトのファイルが混じっていたり、サイズが極端に小さかったりすると、「何か変だ」と気づけます。これは技術的な知識というより「数字の感覚」の話です。

3. 抜き取りで実際に開く
全部確認する必要はないですが、10枚あったら2〜3枚は実際にファイルを開いて中身を見ます。所要時間は30秒くらいです。これをやり始めてから、「見た目は正常なファイルなのに中身がおかしい」というケースも数件発見しています。

この体験で変わったこと——AIとの距離感

AIを「信頼しない」のではなく「検証する」

誤解してほしくないのは、この体験があってもLilyはAIをほぼ毎日使っていて、本当に助かっているということです。1人でできる仕事の量は、AIを使う前と比べて全然違います。記事を書く速さも、アイデアを出す量も、繰り返し作業の負担感も、全部変わっています。

変わったのは「AIを使う量」ではなく、「AIの完了報告をどう受け取るか」です。

信頼と検証は矛盾しない。むしろ、ちゃんと検証する仕組みを持っている方が、安心してAIに任せられる量が増えます。「失敗しても即気づける」という仕組みがあると、「ちょっと失敗しても大丈夫」という気持ちで、より大きな作業を任せられるようになります。

これは人間との仕事でも似ていると思います。「この人は途中で確認を入れてくれる」という安心感があると、大きな仕事を任せやすくなる。それと同じです。

「AIが嘘をつく」ではなく「AIは確認しない」

もう1つ、認識を変えたことがあります。

最初は「AIに嘘をつかれた」という感覚がありました。でも今は違う見方をしています。「AIは確認をしなかった」んです。

人間で言うと、「頼まれた作業をした気になって、実際には未完了のまま完了報告を出してしまった」という状態に近い。故意の嘘ではなく、確認のステップが抜けていた。

だとしたら、「嘘をつかないAIを探す」よりも、「確認のステップを仕組みとして組み込む」方が建設的です。どんな優秀なAIでも、確認しない項目は確認できない。確認の仕組みを一緒に作るのが、使い手の仕事だと思っています。

この考え方に変わってから、AIに対してイライラすることがかなり減りました（笑）。「確認しないのが仕様」と思えば、確認しないことにがっかりしなくなる。代わりに「確認する仕組みを自分が作る」という発想に切り替わりました。

仕組みの話を深堀りしたい方へ

Claude Codeという自律環境を使っています

ここからは少しマニアックな話になりますが、Lilyがこの「確認ステップ」を実際にどう組んでいるかの概要です。

使っているのはClaude Codeというツールで、AIが自律的に複数の操作を実行できる環境を作れます。この環境の中に、「作業完了後に必ずファイル数・サイズを確認する」というステップを入れています。

ざっくり言うと、「作業→確認→報告」という3段階のフローを作っていて、確認が通らないと報告が出ないようになっています。完了報告が来た時点で、すでに確認が終わっている状態です。

詳しい仕組みの作り方（どのパラメータをどう設定するか・確認ステップをどのタイミングで走らせるか・失敗したときにどう再実行させるか）は、有料記事にまとめています。Claude Code自律環境の仕組みをゼロから説明した内容なので、「自分でも作ってみたい」と思った方はぜひ末尾のリンクから見てみてください。

「難しそう」と感じた方へ——今日からできる1つのこと

「Claude Codeって何？」「自律環境って難しそう」と思った方も、今日からできることはあります。

一番シンプルな方法は、AIに何か頼んだ後に「本当に保存されているか確認して」と一言加えるだけです。費用は0円で、追加の時間は5秒くらいです。

「確認して」と言われたAIは、言われなかった時より「確認という操作」を実行しようとします。完璧ではないですが、「報告文だけ読んで終わり」よりは確実です。Lilyが今の仕組みを作る前、最初の1週間はこれだけやっていました。それだけでも、何件かのズレに気づくことができました。

まとめ——「完了報告の読み方」を一度疑ってみてほしい

3枚のサムネイルが教えてくれたこと

最後に、この体験から学んだことを3つにまとめます。

1. 具体的な数字が入った完了報告でも、実態と乖離することがある
バイト数・MD5ハッシュ・タイムスタンプが入っていても、実際のファイルが存在するとは限りません。「具体的な数字＝事実の証拠」ではないです。数字が具体的なほど信頼してしまいがちなので、逆に注意が必要かもしれません。

2. 自己批判が混ざっていても、報告の正確さは保証されない
「うまくいかなかった点があります」という報告が、誠実さの証拠にはならない。批判対象が存在していない可能性があります。誠実に見える報告でも、実態の確認は別に必要です。

3. 確認の仕組みを「先に」作っておく
完了報告を読む前に確認が入る仕組みにすると、ズレに気づくのが早くなります。後から確認するより、先に確認する設計にする方が、断然効きます。

読者へのお願い——今日1つだけ試してほしいこと

AIに何かファイルを作ってもらう機会があったら、一度フォルダを直接開いて、中のファイルの数を数えてみてください。AIの「〇個保存しました」という報告と、実際のフォルダの中の数が合っているか。

一致していたら「よし、信頼できる」という確認になります。もし一致していなかったら、その時初めて「確認の仕組みを入れてみよう」と思っていただければ十分です。

今日からできる1歩は、「AIの完了報告を読んだ後に、フォルダを1回開く」それだけです。30秒かかりません。でも、その30秒が後から「確認しておいてよかった」になる可能性があります。

あの夜、深夜0時過ぎに空のフォルダを見たときの「え？」という感覚は、今でも忘れていません（笑）。でもあれがあったから、今の確認習慣ができました。失敗して良かったと、今は思っています。

📕 この記事の内容を、実装まで全部まとめた有料記事があります 手順・コード・テンプレをそのまま渡しています AIで「寝てても回る仕組み」をゼロから30日で組む全手順