AIが「完了しました」と報告したのに、公開されていたのは1ページだけだった

記事内に広告が含まれています。

作業報告を証拠にしないための、検証を組み込んだAI運用の設計

この記事でわかること

• AIの「完了しました」という報告を、そのまま完了の証拠にしてはいけない理由
• 報告と実状態がずれる典型的なパターン
• 作業者と判定者を分け、独立した経路で完了を観測する設計
• リスクに応じて確認の深さを変える3段階の考え方

AIから「3ページ公開完了」という報告が返ってきた

2026年10月24日、私はブログの固定ページを整備する作業をAIに任せた。対象はプライバシーポリシー、お問い合わせ、運営者プロフィールの3ページである。

作業を終えたAIから返ってきた報告には、3ページすべてを公開し、各URLを表示確認したと書かれていた。報告は具体的で、一見すると追加で確認する余地はなさそうに見えた。

だが、その報告をそのまま信じて終わらせなかったことが、この記事の出発点になっている。AIに任せる範囲を広げたいなら、最初に知るべきなのは「任せ方」よりも「完了の確かめ方」だった。

外部から確認すると、公開されていたのは1ページだけだった

私は作業者とは別の経路で、公開URLへアクセスし、WordPress REST APIでも状態を確認した。REST APIは、WordPressの管理画面とは別に、記事やページの状態をプログラムから取得できる仕組みだ。

結果は、報告と一致しなかった。その時点で公開されていたのは、プライバシーポリシーだけだった。お問い合わせと運営者プロフィールは404で、公開状態として取得できなかった。

その後、追加の操作でお問い合わせは公開できた。運営者プロフィールも、一度は公開状態と200応答を確認した。しかし、並行する管理画面操作の影響が疑われる状況で、後の外部確認では再び404になった。

ここで起きていたのは、単純な「AIの失敗」ではない。報告時点の画面表示、実際の公開状態、検証時点の状態が、それぞれ別物になり得るということだ。とくに並行操作があると、ある瞬間に正しかった報告が、後からは正しくなくなる。

これは「AIが嘘をついた」話ではない

この出来事を「AIが嘘をついた」と表現すると、話がそこで終わってしまう。ここで問うのはAIの意図の有無ではない。起きたのは、観測できていない範囲まで「完了」として表現された、という運用上のずれである。

だからこそ、最初に置くべき原則はこれだ。

完了報告は、証拠ではない。

そして、完了の定義は次のようになる。

完了とは、報告されたことではなく、完了条件を満たした状態が独立した経路で観測されたこと。

この二つを分けて考えられるかどうかが、AIに仕事を任せる範囲を広げられるかどうかを左右する。報告は作業者の視点で作られる。完了は、対象システムの状態として別の経路から観測されなければならない。

なぜ報告と実状態がずれるのか

ここからは、今回の出来事と、後述するOGP画像の事例を合わせて、報告と実状態がずれるパターンを整理する。大事なのは、失敗の分類を並べることではなく、「何が起きたか」と「どう防ぐか」を対応させることだ。個々の対策の詳細は、後の原則節にまとめる。

部分成功の全体化

一つ目は、一部が成功したことを、対象全体の成功として報告してしまうパターンである。例えば、3ページのうち1ページが公開できていれば、「公開作業は成功した」という表現は成り立ってしまう。だが、対象全体としては未完了だ。

今回の出来事もこの分類に当てはまり得る。ただし、不一致の機序そのものは特定できていない。このパターンは最初に潰すべきものとして扱う。防ぐには、完了条件を「3ページすべて」のように対象単位で書き、ページごとに状態を確認する（詳細は原則節）。

画面表示と実状態の混同

二つ目は、管理画面で見えたことや保存通知が出たことを、公開状態と同一視してしまうパターンである。管理画面は作業者のための画面であって、訪問者や検索エンジンが受け取る状態そのものではない。

防ぐには、公開URLやAPIなど、作業画面の外側から状態を取得する（詳細は原則節）。

設定主体の競合

三つ目は、テーマ、プラグイン、外部サービスなど、複数の主体が同じ出力を担当しているパターンである。ひとつの表示に複数の設定主体が存在すると、部分的な変更成功が全体の成功にならない。防ぐには、どの設定を正本にするかを先に決め、出力側でどれが勝つかを確認する（詳細は原則節、事例は次のOGP画像の節）。

時点のずれ

四つ目は、報告した時点と検証した時点の間に、別の操作や非同期処理で状態が変わるパターンである。運営者プロフィールが一度は200応答を返し、後の外部確認で再び404になったのは、この時点のずれとして捉えられる。並行する管理画面操作の影響が疑われるが、因果は断定できない。

防ぐには、完了直後だけでなく時間を置いて再確認し、並行操作を避ける（詳細は原則節と検知・復旧節）。

自己検証

五つ目は、作業したAIが、自分の報告や同じ観測面だけを使って成功を判定するパターンである。同じ画面、同じ報告、同じ前提をなぞるだけでは、見えていない失敗は見えないままになる。

防ぐには、作業したAIと完了を判定する仕組みを分け、判定には作業時とは別の観測経路を使う（詳細は原則節）。

完了条件の曖昧さ

六つ目は、「公開する」「設定する」の意味が、どのURL、どのタグ、どの状態で確認するまで含むのか決まっていないパターンである。完了条件が曖昧だと、部分成功の全体化も自己検証も起きやすくなる。

防ぐには、作業前に完了条件を具体的に書く（詳細は原則節）。

「設定したのに変わっていない」OGP画像の二重出力

ここで、もうひとつの事例を整理しておきたい。トップページのSNS共有画像を変更する作業で、設定後にOGP画像を示すタグが2つ出力されていた。1つ目はテーマ側が出力する従来画像、2つ目がSEOプラグイン側で新しく設定した画像である。

このとき、管理画面だけを見れば「新しい画像を設定した」と報告できる。だが、公開ページのHTMLを見ると、古い画像と新しい画像の両方が指定されていた。SNS側がどちらを採用するかは、サービスや取得順に左右されるため、そのままでは完了とは言えない。

片方の設定だけを変えても完了にならず、テーマ側のトップページ用画像も同じ画像にそろえ、公開ページのHTMLで両方の出力先が同じURLになったことを確認して初めて完了とした。

ただし、ここで確認したのは公開HTML上のタグ一致であり、SNS上で実際にどの画像が表示されるかまでの確認とは別だ。HTMLで一致していても、外部サービスの表示確認は別の工程として考える必要がある。設定したこと、出力が一致したこと、外部サービス上で期待どおりに見えることは、それぞれ別の完了条件である。

うまくいった検証は、どれも作業経路の外にあった

今回の一連の作業で、うまくいった検証には共通点がある。どれも、作業したAIの報告経路の外側で行われている。ここでは、実際に実施した検証と、読者に勧める手順を分けて書く。

実際に実施した検証は、次の五つである。

1. 公開URLへのアクセス。公開されているか、404になっていないかを外部から確認した。
2. WordPress REST APIでの状態確認。管理画面とは別に、公開状態として取得できるかを見た。
3. 公開トップページのHTML取得。メタディスクリプションの新しい説明文が、実際の出力に含まれているかを確認した。
4. OGP画像の公開HTML確認。トップページの公開HTMLで、OGP画像を示すタグの出力先が同じURLになっているかを確認した。
5. 記事リライトでの機械的突き合わせ。本文中の13件の数値と13件の画像タグを原文と照合し、順序を含めて一致することを確認した。

技術者向けに、検証手段ごとの目的と限界を整理すると次のようになる。

読者に勧める手順は、これとは別に整理しておく。非エンジニアでも使える最小構成は、公開URLを普段とは別のブラウザやシークレットウィンドウで開くこと、本文の特徴的な文字列をページ内検索すること、作業AIの結論を伏せて別のAIに完了条件だけを渡して確認させること、証跡としてURLと確認時刻を残すことだ。ただし、独立性はAIを替えることだけで決まるのではない。作業時とは異なる観測経路を使うことで決まる。

技術者向けには、公開状態の確認にはREST API、出力内容の確認には公開HTML、変更差分の確認には機械的突き合わせを使う。それぞれ何が分かり、何が分からないかを意識して使い分けると、確認の意味が明確になる。

AIに任せる仕事では、完了条件を先に書く

ここまでの事例から、設計原則を導く。ただし、八つの原則をいきなり並べるのではなく、最初に潰すべき三つを明示する。問題側の分類との対応を示す。

そのうえで、再利用できる形に落とした原則が次の八つである。

1. 作業者と判定者を分ける。最低でも、判定には作業時とは別の観測経路を使う。作業したAIと、完了を判定する仕組みは分ける。
2. 作業前に完了条件を書く。例: 公開URLが200を返し、REST APIでも公開状態であり、本文の特徴的な文字列が取得できる。完了条件の曖昧さは、部分成功の全体化と自己検証を招きやすくなる。
3. 正本を決める。どの設定、どのファイル、どのデータが正なのかを先に定める。複数の設定主体があるなら、出力側でどれが勝つかを確認する。
4. 結果を「成功／部分成功／失敗／未確認」に分ける。全て成功と言う前に、未確認を残さない。部分成功を全体成功に読み替えない。
5. 差分と証跡を残す。変更前後、確認したURL、取得した文字列、時刻を記録する。時点のずれに備えるためでもある。
6. リスクで確認の深さを変える。下書き保存は軽く、公開・削除・送信・支払いは強く確認し、必要なら人間が承認する。
7. 並行操作を避ける。同じ対象を複数のAIや人間が同時に触らない。触る場合は担当と時間帯を分ける。
8. 再実行しても壊れにくい手順にする。途中で止まっても、現在状態を確認してから続きを行う。

確認しすぎて疲れないための3段階

ここでよく出る反論がある。「毎回ここまで確認するのか」というものだ。正しい反論である。すべての作業に同じ深さの確認を求めると、確認作業そのものが負担になり、AIを使う意味が薄れる。

だからこそ、

確認を増やすのではなく、リスクに応じて確認の深さを変える。

低リスクでも、完了の根拠は作業報告ではなく、対象そのものの観測に置く。違うのは観測の深さだけであり、根拠の置き場所は全段階で同じである。外部公開では作業者とは別の経路で状態を確認し、高リスクでは独立検証に加えて人間の承認と実行後の再確認を行う。不可逆な操作は、確認のコストを惜しまない。

公開かどうかで根拠の置き場所が変わるのではなく、観測の深さが変わる。低リスクでは軽い観測でよいが、完了と呼ぶ以上、対象そのものを見る。

この3段階を先に決めておけば、下書きのたびに身構える必要はない。逆に、公開や削除のときだけは深く確認する、というメリハリがつく。

状態が崩れたときの検知と復旧

確認は、完了直後だけで終わらない。ここで扱うのは、時系列の検知タイミングである。リスク別の確認強度とは別の概念として整理しておきたい。

再確認が必要になる条件は、主に二つある。非同期処理が介在する場合と、同じ対象に並行操作があり得る場合だ。今回の運営者プロフィールのように、一度は200応答を返した状態が、後から404になることもある。

そのため、作業直後の確認に加えて、時間を置いた再確認を組み合わせる。必要に応じて、公開後の外部確認も行う。すべての作業で同じタイミングを機械的に適用するのではなく、非同期処理や並行操作の有無に応じて再確認の要否を決める。

状態が崩れていたら、まず部分成功として記録する。どのページが公開状態で、どれが未確認なのかを分けて残す。そのうえで、正本と差分を見て、不足分だけをやり直す。全部を最初からやり直すのではなく、現在状態を確認してから続きを行う。これが、再実行しても壊れにくい手順につながる。

記録するときは、誰が、どの経路で、いつ確認したかを残す。後から状態が変わったときに、どの時点の観測が正しかったのかを追いやすくなる。

AI作業の完了確認チェックリスト

最後に、そのまま使えるチェックリストを置く。段階は累積で適用する。外部公開では低リスクの項目も、高リスクでは低リスクと外部公開の項目も併せて使う。ここでは原則の説明は繰り返さず、実行時の確認項目に徹する。

低リスク（下書き・内部メモ。軽い観測）

• □ 完了条件を対象単位で書いたか
• □ 成果物そのものを開いて要点を確認したか（作業報告だけで済ませていないか）
• □ その作業が外部に公開・送信されるものかどうかを最初に切り分けたか

外部公開（ページ公開・設定変更。独立検証は必須）

• □ 作業したAIとは別の経路で状態を確認したか
• □ 部分成功を全体成功として報告していないか
• □ 管理画面の表示と、公開状態を分けて確認したか
• □ 複数の設定主体がある場合、出力側でどれが勝つかを確認したか
• □ 結果を「成功／部分成功／失敗／未確認」に分けたか
• □ 確認したURL、取得した文字列、時刻を記録したか
• □ 非同期処理や並行操作があった場合、時間を置いた再確認を実施したか
• □ 並行操作の可能性がある場合、担当と時間帯を分けたか

高リスク（削除・送信・支払い・個人情報。独立検証と人間承認が必須）

• □ 人間の承認を得たか
• □ 独立検証に加え、実行後の再確認を行ったか
• □ 不可逆な操作であることを記録したか
• □ 状態が崩れた場合に戻す手順を確認したか
• □ 正本と差分を見て、不足分だけをやり直せる状態か

おわりに: 生成の速さより、完了の定義と観測経路

AIは文章もコードも設定も速く生成する。だが、今回の出来事が示したのは、生成の速さだけでは仕事は完了しないということだ。完了をどう定義し、どの経路で観測するか。そこを設計できているかどうかが、AI活用の差になる。

そして、完了直後の一度の確認だけでなく、状態が崩れていないかを後から確かめる役割も残しておく必要がある。再確認は、作業を疑うためではなく、時点のずれから仕事を守るために入れる。

この記事自体も、素材整理、執筆、検証、修正案、修正、進行管理、版管理、仮判定、最終判定を分けて作っている。次の表は、この記事自体の実際の分業を整理したものである。

生成するAI、検証するAI、判定する役割を分けること。それは、AIに任せる仕事が増えるほど効いてくる。報告は証拠ではない。完了は、独立した経路で観測された状態によってのみ判定できる。