AIの「できました」を信じて失敗した3つの場面。中小企業に要るのは完了を確かめる仕組み

AIに仕事を任せるようになって、一番ひやりとしたのは、AIが間違えたときではありませんでした。動いていないのに「できた」として完了扱いになり、38日間誰も気付かなかったときです。

ハイデフでは、社内の仕組みの多くをAI（Claude Code）と一緒に組んでいます。その中で実際に踏んだ失敗を3つ、恥を承知で少しまとめてみます。AIを業務に入れ始めた経営者の方に、先に知っておいてほしい話です。

3つの失敗は、どれもエラーが出ないまま進んでいた

結論から言うと、3つとも、AIが下手だったから起きたのではありません。作った部分は正しく、エラーも出ず、ただ「結果が出ていない」ことに誰も気付かなかった。まず全体を表にします。

場面1：時刻の書き方が違うだけで、見張りは9時間黙った

2026年8月6日、画面が止まっても約9時間15分、「正常」と表示され続ける状態だったことが分かりました。対象は、ハイデフが店舗向けに作っている店頭の表示画面（サイネージ）の見張りです。画面が止まったら、管理画面に「異常」と出るはずの仕組みでした。

原因は時刻の書き方です。現地の機械は日本時間で時刻を送り、サーバー側は世界標準時で区切りを持っていた。その2つを、時刻としてではなく、文字の並びとして比べていたんです。

日本時間は世界標準時より9時間進んでいます。書き方が混ざったまま文字で比べると、判定がそのまま9時間ずれる。しかも、何のエラーも出ません。

厄介なのは、これが1回きりではなかったことです。社内のファイル共有の仕組みでも、データベース（データをためておく台帳）は世界標準時、アプリは日本時間で、同じ9時間のずれから自動削除が狂っていました。同じ穴に、別の場所で2回落ちています。

場面2：「登録済」と書いた自動処理は、38日間一度も動いていなかった

2026年7月27日、6月19日の公開から38日間、一度も動いていなかったことが分かりました。対象は、社内のファイル共有の仕組みで期限切れのファイルを毎日自動で消す処理です。サーバーの管理画面への登録が漏れていたんです。共有サーバーには、期限切れのファイルが30件、6.17GB残っていました。

当時の文書には「登録済」と書いてありました。同じ行には、動いたかどうかは「翌朝確認」とも書いてあった。その翌朝の確認が実行されないまま、完了扱いになっていたんですよね。

手元のMacでも似たことが起きていました。定期処理が半年ほど失敗を出し続けていて、その失敗通知が137通、誰も開かない場所に溜まっていた。失敗はどこにも出ていなかったのではありません。誰も読まない場所に出ていたのです。

場面3：「実装した」機能は、どこからも呼ばれていなかった

2026年8月5日、SNSなどの実績を毎月自動で集める仕組みを確かめると、5系統のうち1系統だけ、集計表に1行もデータが入っていなかった。取得の処理も、相手先サービスの利用許可も揃っていたのに、です。

ほかの4系統には毎月の自動実行の予定が組まれていたのに、その1系統だけ、予定のどこにも乗っていなかったんです。処理そのものは正しい。ただ、誰も呼んでいない。

似た形は、ある店舗向けアプリを初めて本番に公開したとき（2026年8月）にも起きました。公開前の自動検査はすべて合格。なのにお客様の画面には1行も表示されなかった。検査が見ていたのは「データベースにつながるか」だけで、中身が空でも合格になる作りでした。

自社サイトの移行でも、途中の工程が成功したのを見て「完了」とし、実は本番に一切反映されていなかったことがあります。

壊れても何も起きないから、誰も気付かない

振り返ると、共通点ははっきりしています。コードは正しく、エラーも出ていない。ただ、出てくるはずの結果が出ていなかった。

間違いなら、どこかで目に付きます。数字が合わない、画面が崩れる、お客様から連絡が来る。でも「動いていない」は違う。呼ばれない処理はエラーを出しません。結果が「無い」ことは、誰の目にも入らないんです。

だから、AIの腕前がいくら上がっても、この種の失敗は減らない気がしています。AIと一緒に「できた」と言うとき、その中身はたいてい「作った」であって、「動いている」ではないからです。

「作った」と「動いている」の間には4つの段がある

完了には段があります。そして「できた」の報告は、たいてい1段目か2段目で止まっています。

私たちは今、4段目まで見えて初めて「完了」と呼ぶようにしています。

経営者が決めるのは、AIの選び方より「完了の定義」

AIを入れる会社に要るのは、腕のいいAIより先に、「完了」を確かめる決まりごとです。技術の知識は要りません。社内で次の4つを決めるだけです。

• 完了の定義を「出力側の実物を見た」にする。「作りました」「登録しました」では完了にしない。届いたメール、集計表の行数、お客様の画面。結果そのものを見て、初めて完了です。
• 「翌日確認する」は、書いた瞬間に予定へ入れる。カレンダーに入っていない確認は、実行されません。
• 黙っている見張りは、見張りが無いより危ない。「異常のときだけ知らせる」仕組みは、見張り自身が壊れても黙ります。それは正常と見分けがつかない。うまく動いたときにも記録を残させ、それが途絶えたら異常とみなします。
• 「無い」ものを数える。エラーの数ではなく、本来あるはずの結果の数を見る。場面3は、集計表の行数を数えれば5秒で分かりました。

AIは、頼めば本当によく作ってくれます。だからこそ「できた」の一言で、人間の確認が丸ごと抜け落ちる。AIに任せる範囲が広がるほど、経営者の仕事は「作らせること」から「完了を確かめる仕組みを持つこと」へ移っていきます。「うちはまだ小さく使っているだけだから」と思っている会社ほど、気付いたときには何週間分もの「動いていなかった」が積み上がっているかもしれません…

よくある質問

AIの「できました」は信用しないほうがいいのですか？

信用しない、ではなく「何ができたのか」を確かめる、が正確です。AIの報告は多くの場合「作った」までを指しています。「どこで結果を確認しましたか」と一言聞き返すだけで、4つの段のどこまで来ているかが分かります。

技術が分からない経営者でも確認できますか？

できます。見るのはコードではなく結果です。届くはずのメールが届いたか、表に今月の行があるか、お客様の画面に表示されているか。結果の側に立てば、専門知識は要りません。

見張りの仕組みを入れれば、この失敗は防げますか？

入れ方次第です。異常のときだけ知らせる見張りは、見張りそのものが止まっても黙ります。正常に動いたときに記録を残させ、それが途絶えたら知らせる形にすると、黙ったまま壊れることを防げます。

小さな会社でも、ここまでやる必要がありますか？

小さな会社ほど必要です。確認する人が少ないぶん、「誰かが見ているだろう」が成り立ちません。まずは自動で動いているものを一覧にし、結果を週に1回見るだけでも十分です。

▶︎ 重い作業でも使用量が増えないClaude Codeの運用設計。スキル・フック・オーケストレーション・記憶の4層
▶︎ AIに渡すべきは、プロンプトではなく「なぜ」だ