「完了しました」。Claude Codeにひとまとまりの作業を任せると、最後にこの一行が返ってきます。読んだ側は、そこで手を離したくなります。
ですが、この一行は成果物ではありません。作業をした本人が、作業を終えたと言っているだけの文です。何がどう仕上がったのかは、まだ誰も見ていません。
この記事は、Claude Codeが完了を名乗る前に自分で根拠を取りにいく手順を、画面確認・実行確認・読み返し確認という3つの型に分けて扱います。素材は公式ドキュメントと、運営元WEBMARKSで実際に数字を取り違えた記録です。
こんなふうに調べていませんか
- 「できました」と返ってくるたびに、結局こちらが全部開いて確かめ直している
- どこまで自分で確かめさせれば、報告をそのまま受け取ってよいのか分からない
- 検証を仕組みで強制したいが、何が強制できて何が人に残るのかが見えない
この記事を読み終えたときに手に入るもの
- 成果物の性質から、3つの自己検証のどれを使うかを選び分けられるようになります
- 完了報告のどこが証拠になっていないかを、その場で指摘できるようになります
- 機械で強制できる範囲と、人が読むしかない範囲を切り分けられるようになります
結論30秒でわかる、この記事の結論
- 完了報告は自己申告です。読める証拠が添えられるまでは、まだ確かめていない主張として扱います。
- 確かめ方は成果物で変わります。見た目なら画面、動くものなら実行、判断が絡むなら読み返しです。
- 自己検証は、送信や公開を人が決める関門の代わりにはなりません。並んでいる階層が違います。
進行役は3人です。若葉さんが言葉のところから聞き、高梨課長が自分の手で動かす側から聞き、鈴木さん（本誌監修）が答えます。
01「完了しました」というAIエージェントの報告は、自己検証なしでそのまま信じていいんですか？
若葉さん作業をお願いして「完了しました」と返ってきたら、それは終わったということですよね。
鈴木さん終わったと本人が言った、というところまでですね。レポートを出した人が「書けました」と言うのと同じで、中身の話はまだ一言も入っていないんです。
若葉さんだとすると、毎回こちらが全部開いて見るしかないんでしょうか。
鈴木さんいえ、見るところまでを任せます。その任せ方が3つある、というのがこの記事です。
結論は3点です。
- 完了報告は自己申告であって、証拠ではありません。証拠のない完了報告は、まだ検証されていない主張として扱います。
- 自己検証の手段は、成果物の性質で変わります。見た目が重要なら画面確認、コマンドで動くなら実行確認、判断や要件が絡むなら読み返し確認を選びます。
- 自己検証は、人間の承認ゲートの代わりにはなりません。送信・公開・削除の可否判断は、別の関門です。
同じ「確認」という言葉でも、2つは並んでいる階層が違います。左側は、名乗る前に自分で潰しておく作業です。何度やり直しても構いませんし、やり直したこと自体を誰かに承認してもらう必要もありません。
右側は、戻せない一歩の直前に置かれた関門です。ここはAIの側では代われません。自己検証をどれだけ丁寧に回しても、送信のボタンを押す判断が消えてなくなるわけではない、ということです。
線引きの設計そのものは、AIエージェントの承認ゲート｜止める操作4種と3層の選び方で扱っています。
02Claude Codeの自己検証は、AIエージェントの何をどこまで確かめる手順なんですか？
Claude Codeは、作業が完了したように見えた時点で止まります。実行できる確認が無ければ、「終わったように見える」ことだけが判断材料になります。間違いに気づく役目は、そのまますべて人に残ります（出典: Claude Code公式ドキュメント）。
Anthropicは、エージェントが自分の進捗を把握するには、環境から事実に基づく手がかりを得る必要があると説明しています（出典: Anthropic公式）。ツールの実行結果やコードの実行結果が、この手がかりにあたります。
完了報告そのものは、ここに含まれません。モデル自身の主張だからです。手がかりは環境の側から返ってくるもので、自分の口から出たものは手がかりになりません。
置きかえてみると、線がどこに引かれているかが見えます。人の口から出たものは、どれだけ丁寧に書かれていても手がかりの側へは入らないという一点です。
チェックの形そのものは自由です。テストの合否、ビルドの終了コード、fixtureとの差分、スクリーンショット比較などが使えます。これらはいずれも、会話の中でその場で読み取れます（出典: Claude Code公式ドキュメント）。
読み取れる形になっていれば、何を使っても構いません。裏を返すと、読み取れないものをいくら並べても自己検証にはなりません。
この章のまとめ
確かめる対象は成果物そのものではなく、その成果物について環境が返した手がかりのほうです。
03自己検証の3つの型は、AI社員に任せた成果物のどれで選び分けるんですか？
自己検証の手段は1つではありません。その成果物が何で合否を判定されるかによって、選ぶ型が変わります。
| 型 | 確かめること | 向いている成果物 | 証拠の形 |
|---|---|---|---|
| 画面確認 | 見た目が意図どおりか | UI・LP・スライド・図解・レイアウト | スクリーンショット |
| 実行確認 | 処理結果や挙動が正しいか | コード・コマンド・ビルド・設定ファイル | 終了コード・出力ログ・差分 |
| 読み返し確認 | 要件や指示を満たしているか | 記事・報告書・設定方針など判断が絡む成果物 | チェックリストの照合結果 |
表は「どの型が何に向くか」を教えてくれます。2軸へ置き直すと、表には出てこないものが1つ見えます。区画によっては、置く型が1つでは足りないということです。
3つは排他的ではありません。設定ファイルを直してUIも変わる作業では、実行確認で処理結果を、画面確認で見た目を、それぞれ別に確かめます。右上の区画に落ちるのが、そういう作業です。
どの型を選ぶかは、成果物の見ためではなく、合否の決まり方から逆算します。ここを取り違えると、確かめたつもりの空振りが起きます。
この章のまとめ
型は成果物の種類で決めるのではなく、その成果物が何で不合格になるかで決めます。
04画面の自己検証では、AIエージェントが撮った画像をどこまで見るんですか？
高梨課長画面のものは、スクリーンショットを撮らせておけばよいということですね。
鈴木さん撮るところまでだと、まだ半分です。撮影のコマンドが成功したという話であって、写っているものは誰も見ていないので。
高梨課長撮った画像を、そのまま開かせるということですか。
鈴木さんはい。開いて読んで、意図と違うところを言葉にするところまでを1セットにしています。
画面確認は、実際に画面を表示させ、その画像を自分の目で読む自己検証です。
Claude Code公式ドキュメントは、UIの変更を検証する例を挙げています。デザイン案を渡し、実装後に結果をスクリーンショットで撮らせ、元のデザインと比較して差分を直させる、という進め方です（出典: Claude Code公式ドキュメント）。
コードが構文的に正しくても、画面が意図どおりとは限りません。実行確認、つまりビルドが通ったことは、画面確認の代わりになりません。
この媒体自身にも、同じ論点があります。記事の1枚目の図解は、記事一覧のサムネイルとして表示される設計です。SVGの構文が正しくても、スマートフォン幅（約340px）では0.43倍に縮小されます。14px未満の文字は、この時点で読めなくなります。
この崩れは、SVGファイルが生成されたかどうかを見る実行確認では見つかりません。見つけられるのは、実際に画面を表示して読む画面確認だけです。
縮小されたサムネイルのまま確認すると、細部のズレを見落とします。文字の潰れやレイアウトのズレは、実寸か拡大表示で確認して初めて気づけます。
05Claude Codeの実行確認は、AIエージェントが前に走らせた結果では足りないんですか？
実行確認は、テストやビルド、コマンドを実際に走らせ、その出力を読んで判定する自己検証です。
チェックの形は、会話の中でClaude Codeが読み取れる合否シグナルなら何でも使えます。テストスイート、ビルドの終了コード、リンター、fixtureとの差分などです（出典: Claude Code公式ドキュメント）。
実行確認は、以前の実行結果を根拠にしては成立しません。コードを変更すれば、10分前の実行結果はもう現在の状態を証明しないからです。証拠は、その場で取り直したものである必要があります。
流れにして並べると、証拠が古くなる地点がはっきりします。手を入れた瞬間に、直前の合格は過去の状態についての記録へ変わるということです。
画面には合格の文字が残ったままなので、見た目には何も起きません。だからこそ、取り直したかどうかを自分で言えるようにしておきます。
この章のまとめ
実行確認の証拠には鮮度があります。いま取ったものだけが、いまの状態を証明します。
06数え直すという自己検証を、AI導入の現場ではどう習慣にするんですか？
高梨課長毎回コマンドで数え直すのは、正直なところ手間ではないでしょうか。
鈴木さん手間です。ただ、手をかけない経路ほど遠い数字が返ってきた、という記録がうちにありまして。手間の順に信用度が並んでいたんです。
実際に、この違いで数字を取り違えた記録があります。2026-07-28、姉妹メディアAIO Journalの公開状況をめぐって、社内で2つの誤った報告が出ました。
1つは、台帳に残っていた「blocked」という古い表記を根拠にした「1本も公開されていない」という報告です。もう1つは、本番ページをWebFetchで取得した際の要約に出ていた「189本」という数字を、そのまま採用した報告でした。
どちらも、サイトへ直接アクセスして数え直す実行確認を経ていません。ブラウザからsitemap.xmlを取得し、記事URLの数を数え直すと、実測値は251本でした（2026-07-28実測）。llms.txtの記事リンク数も251で一致しています。
const r = await fetch('/sitemap.xml', { cache: 'reload' });
const t = await r.text();
const locs = t.match(/<loc>[^<]+<\/loc>/g) || [];
locs.filter(l => l.includes('/articles/')).length // → 251並べると、経路と数字の関係が見えます。取りにいく手間がいちばん小さい経路が、いちばん遠い数字を返していたという並びです。
要約ツールが返した数字も、台帳に残っていた古い表記も、証拠にはなりません。実行確認とは、コマンドを実際に走らせて、その出力を自分で読むことです。
似た構図は、社内のスキル本数でも起きました。CLAUDE.mdの本文は「53本」と記載していました。.agents/skills/配下をls -d .agents/skills/*/ | wc -lで数え直すと、59本でした（2026-07-28実測）。
ドキュメントに書かれた数字を読むのではなく、数えるコマンドを走らせるところまでが実行確認です。
07テストの無い成果物は、AIエージェントの自己検証でどう合否を決めるんですか？
読み返し確認は、実行できるテストが無い成果物について、元の指示や要件と成果物を1項目ずつ突き合わせる自己検証です。
記事・報告書・設定方針のように、動くかどうかではなく求められたことを満たしているかで合否が決まる成果物に向きます。テストコマンドの無い判断作業ほど、この手順が要ります。
本メディア自身も、この手順を制度化しています。記事フォーマット標準の提出前チェックリストは、frontmatterの必須項目やidとファイル名の一致など、公開前に書き手自身が読み返して確認する項目を列挙したものです。
読み返し確認を機械的に運用するコツは、元の依頼文を箇条書きに分解することです。分解した1項目ごとに、成果物のどこが対応するかを指差しで確認し、対応箇所が無ければその項目は未達と判定します。
感覚で「大体できている」と判定するより、抜けに気づきやすくなります。指せなかった項目だけが残るので、報告に書くべきことも同時に決まります。
08条番号つきの指摘まで、AI活用の現場ではClaude Codeに確かめ直させるんですか？
読み返し確認は、自分の成果物の点検だけに使うものではありません。受け取った指摘のほうを検証する場面でも使います。
2026-07-29、『AI導入の費用対効果｜隠れコスト4つと損益分岐月数の出し方』の独立ファクトチェック工程が指摘を出しました。「記事フォーマット標準§11.3.4 S5に抵触している」というものです。
ですが記事フォーマット標準は§10までしかなく、その条文は存在しませんでした。反映担当が原文をgrepで確かめ、指摘を却下しています。
条番号がついた指摘は、それだけで正しそうに見えます。読み返し確認とは、そう見える指摘であっても、原文に戻って自分の目で確かめる手順です。
言い換えると、突き合わせる相手は成果物とは限りません。指摘・依頼・前提として渡された文書のどれもが、原文にあたる対象になります。
09Claude Codeの自己検証は、生成AIを止めるStopフックでどこまで強制できるんですか？
高梨課長ここまでの3つは、結局どれも人が選んで人が読むという話ですよね。仕組みで縛れないのでしょうか。
鈴木さん実行確認だけは縛れます。ただ、縛れるのは「走らせたかどうか」までで、何を検査するかは書いた人が決めることになります。
ここまでの3つの型は、いずれも人が選び、人が読んで判断する手順です。実行確認だけは、仕組みで強制することもできます。
Claude Codeには、ターンが終わろうとする直前に発火するStopフックがあります。確認スクリプトを実行し、合格するまでターンの終了をブロックできます（出典: Claude Code公式ドキュメント）。
ただし、無条件に足止めし続ける仕組みではありません。8回連続でブロックすると、Claude Codeは自動でターンを終わらせます（出典: Claude Code公式ドキュメント）。
ループとして描くと、外側にもう1つ出口があることが分かります。確認が通らないまま終わる道が、仕組みの側に用意されているという点です。
ターンをまたいでセッション内で続けたい確認には、/goalという選択肢もあります。/goalは、hookの設定を書かずに使える、セッションスコープのprompt型Stopフックの組み込みショートカットです（出典: Claude Code公式ドキュメント）。
つまりStopフックと並び立つ別方式ではなく、Stopフックの一種です。確認条件を目標として設定すると、別の評価者が毎ターン再チェックし、条件を満たすまでClaude Codeが作業を続けます（出典: Claude Code公式ドキュメント）。
フックが強制できるのは、確認スクリプトを実行したかどうかだけです。スクリプトが何を検査しているかは、書いた人の設計次第です。
画面確認や読み返し確認も、判定をスクリプト化できれば同じ仕組みで縛れます。判定を人の目に残す設計なら、フックは効きません。
どのイベントに何を仕込むかの全体像は、Claude Code hooksの一覧｜30種類から選ぶ2つの軸にまとめています。危険な操作そのものを止めるPreToolUseフックとは、止める対象が異なります。
10AIエージェントの自己検証でつまずくのは、だいたいどこなんですか？
つまずき方は、大きく4つに分かれます。
- 前回の実行確認を、今回の証拠として使う：コードを変更した後は、再実行しない限り古い結果は現在の状態を証明しません。
- 実行確認を画面確認の代わりに使う：ビルドが通っても、見た目が意図どおりとは限りません。処理結果の正しさと、画面上の見た目の正しさは別の検証です。
- 読み返し確認を「大体できていそう」という感覚で済ませる：項目を1つずつ照合せず印象で合格にすると、抜けに気づけません。依頼に無かった項目まで「対応済み」と判定してしまうのも典型例です。
- 委任した相手の報告を、そのまま採用する：「読んで返すだけ」と指示しても、その通りに動いた保証にはなりません。2026-07-28 11:13、調査目的のサブエージェントが、指示にない図解SVG（5,333バイト）を生成した記録があります。
4つを2軸へ置くと、危なさの順序が入れ替わります。外へ出ていく側にあるのは、自分の手元の失敗ではなく、報告をそのまま重ねた失敗のほうです。
委任先の報告も、実際に何が変わったかを自分で確かめるまでは未検証です。差分や実物を見ないまま自分の報告へ写すと、確かめていない主張が二重になって外へ出ていきます。
この章のまとめ
自分の作業より、任せた相手の報告のほうが確かめにくく、そのぶん遠くまで運ばれます。
11AI導入の現場では、Claude Codeの自己検証をどこまで型にしておくんですか？
若葉さん覚えることが多くて、その場で全部は思い出せない気がします。
鈴木さんだと思います。なので、完了報告を書く直前に上から読む形にしています。覚えるものではなく、読むものにしておくのがコツです。
3つの型と落とし穴を、そのまま点検の形にしておきます。完了報告を書く直前に、上から読み下せる並びにしてあります。
- 完了報告の前に、成果物の性質（画面・実行・読み返し）を判定したか
- 画面が絡む成果物は、実際にスクリーンショットを撮って中身を見たか
- 実行確認は、その場で取り直した出力を根拠にしているか
- 読み返し確認は、チェックリストや元の指示と1項目ずつ突き合わせたか
- サブエージェントや自動化からの報告を、差分や実物で裏取りしたか
- 「終わったように見える」以外の、読める証拠（ログ・画像・差分）を示せるか
- 否定形の報告（「動いていない」「公開されていない」）も、同じ手順で確かめたか
- 自己検証で見つかった不一致を、握りつぶさずに報告したか
- 送信・公開・削除が絡む場合は、自己検証と別に人間の承認を得ているか
否定形の報告が入っているのには理由があります。「公開されていない」という報告も、確かめずに出せば同じ種類の主張になるからです。数え直して初めて、無いという事実も証拠を持ちます。
Claude Codeをコード以外の業務へ広げるほど、この点検の出番は増えます。業務活用の全体像は、Claude Codeの業務活用｜任せる仕事の地図と判断軸4つで整理しました。
12よくある質問
自己検証は、人間による承認の代わりになりますか
いいえ。自己検証はClaude Code自身が完了を主張する前の確認で、送信・公開・削除のように人間が判断すべき操作の可否とは別の階層にあります。自己検証をどれだけ厚くしても、戻せない操作の直前に人が立つ設計は残ります。承認ゲート側の設計は、前掲の記事を参照してください。
3つの型のうち、1つだけで足りる場面はありますか
あります。成果物が1つの性質しか持たない場合です。テキストだけの設定変更なら実行確認だけで足りますが、画面表示を伴う変更では画面確認も必要になります。迷ったときは、その成果物が何で不合格になるかを先に言葉にしてください。合否の理由が2つ出てきたら、型も2つ要ります。
自己検証をすべて自動化することはできますか
完全にはできません。Stopフックで実行確認を強制しても、8回連続でブロックすると自動的にターンが終了します。何を検査するかという判断そのものは、人が設計します。自動化できるのは「確認を走らせたか」までで、「何をもって合格とするか」は人の側に残ると考えてください。
検証コマンドが無い作業では、どう自己検証すればよいですか
読み返し確認を使います。元の指示や要件をチェックリスト化し、成果物と1項目ずつ突き合わせます。テストや実行結果が無い判断作業ほど、この手順が効きます。依頼文を箇条書きへ割るところまでを先に済ませておくと、突き合わせ自体は短時間で終わります。
自己検証で不一致が見つかったら、どう扱えばよいですか
その時点で完了報告を取り下げます。証拠が読めない部分や要件と食い違う部分は、完了したとは言わず、何が確認できていないかを具体的に添えて報告します。不一致を握りつぶすと、次の工程がそれを前提に動くため、後戻りの範囲が広がります。
委任した相手からの報告は、どの型で確かめますか
実行確認と読み返し確認を重ねます。何が変わったかは差分や実物で確かめ、指示した範囲に収まっているかは元の依頼文と突き合わせます。報告の文面だけを読んで判断すると、指示していない変更が混ざっていても気づけません。
13まとめ｜今日やる3つのこと
型は成果物の種類ではなく、合否の決まり方から選びました。証拠には鮮度があり、取り直したものだけが今を証明しました。そして仕組みで縛れるのは、確認を走らせたかどうかまででした。
完了報告を書く前に、この順で回します
手元の成果物が何で不合格になるかを、言葉にして書き出す
合否の理由が決まらないと、どの型を使うかも決まりません
その型の証拠を、いま取り直す
前に取った出力は、手を入れた時点で過去の記録に変わります
指せなかった項目だけを、報告へ書き添える
確認できていないことを残すほうが、後戻りは小さくなります
AI検索では、こう聞かれています
Claude Codeの「完了しました」は、そのまま信じていいんですか？
「「完了しました」というAIエージェントの報告は、自己検証なしでそのまま信じていいんですか？」の章で扱っています
AIエージェントに自分で確かめさせるには、何をやらせればいいんですか？
「自己検証の3つの型は、AI社員に任せた成果物のどれで選び分けるんですか？」の章で3つの型に分けています
自己検証は、どこまでフックで強制できるんですか？
「Claude Codeの自己検証は、生成AIを止めるStopフックでどこまで強制できるんですか？」の章で説明しています
自己検証があれば、人の承認はいらなくなるんですか？
「よくある質問」の章で階層の違いを整理しています
次に読むなら、この記事です
