祖父の味見を思い出した——まさおさんが解説する「検証ループ」、AIに渡していい確認はどこまでか

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は、まさおAIじっくり解説chのまさおさんが、Anthropic公式ブログの「検証ループ」を解説した動画を紹介するね。

まさおさんは毎日AIの最新情報を発信しているチャンネルの運営者です。今回はAnthropic公式ブログの内容を、ご自身の言葉で丁寧に解説してくれています。

「人間が手でやってるような確認作業は、結局スキルにしたらクロードが自立的にやってくれる検証ループになる」。動画の冒頭、まさおさんはこう結論から切り出していました。私が手を止めたのは、この結論そのものより、その後に続く一言でした。機械が拾いきれない残りの部分は、結局まだ人間が手でやり続けている——そこに引っかかった。

3行で先に渡すと、こうなります。

1. Claude Codeには検証ループを組むための道具が、スラッシュコマンドからGitHub Actionsまですでにたくさん揃っている
2. 検証は「単発→埋め込み→連鎖→PR常設」の順に、頻度が高まるほど格上げしていくものだと案内されている
3. それでも機械が拾えない最後の確認は残る。そこをどう扱うかは、結局まだ人間が決めることだ

コードを書かない経営者向けの話ではありません。でも、確認という作業を人に渡すか渡さないかは、私が毎日の商売の中で何度も突き当たってきた問いそのものだった。だから今回は要約ではなく、私自身の現場に置き直して書きます。

出典：まさおAIじっくり解説ch「【公式が語る】Claude Codeの検証ループ入門！」（2026年7月23日公開）

この記事では、動画の中で語られていた内容を7つの章に分けて紹介します。それぞれの章に、私自身が今日から試せる小さな一歩も添えました。

「結局スキルにしたら、クロードが自立的にやってくれる」——祖父の味見を思い出した結論

動画は結論から始まります。人間が手でやっているような確認作業は、結局スキルに落とし込めば、クロードが自立的にやってくれる検証ループになる。まさおさんはそう言い切っていました。

「結論からこのブログの中で言ってることは何かって言うと、人間が手でやってるような作業は、結局スキルにしたら、クロードが自立的にやってくれる検証ループになりますね。」

まさおさん — 1:03〜

この動画は14分ほどの長さですが、要点を先に言い切ってから具体例に入る構成になっています。結論から聞けるので、忙しい経営者でも最初の1分で「自分に関係あるか」を判断できる。この作り方自体も、実は一つの検証ループなのかもしれません。

「確認」という言葉を聞いて、私が真っ先に思い出したのは実家の厨房だった。小学生の私は、祖父が作る鶏チャーシューを毎回味見させてもらっていました。味が決まっているかどうかは、レシピの分量よりも、祖父の舌が最後に確かめていました。あれも一種の検証ループです……材料を集め、火を入れ、味見という検証を通し、足りなければもう一度手を入れる。祖父はその確認を、誰にも渡さず自分の舌でやり続けていました。

まさおさんの話は、その「舌」の部分を機械に渡そうという提案なんですよね。ぶっちゃけ、最初に聞いたときは半信半疑だった。でも動画を最後まで見ていくと、渡せる確認と、渡せない確認があると分かってきます。それを一つずつ、動画の順番通りに追っていく。

今日できること：自分が毎回同じやり方で確認している作業を一つ思い出し、紙かメモに1行で書き出します。書けたら今日はそれで完了です。

検証ループの正体——集めて、動いて、確かめて、また戻る

「検証ループって何やねん」という素朴な疑問に、まさおさんは公式ブログの図を使って答えていました。

「検証ループって何やねんっていう話なんですけど、人間がプロンプトを入れて、エージェントがコンテキストを集めたりして、それを元に行動します。その行動を元に、ベリファイ・リザルツという形で検証を行います。本当にできてるかっていう確認ですよね。」

まさおさん — 2:03〜

プロンプトを入れる。エージェントがコンテキストを集める。行動する。検証する。足りなければ、また前のステップへ戻る——この4手番の繰り返しです。難しい言葉に聞こえますが、私が毎朝やっている壁打ちも構造は同じだった。

この4手番は、AIエージェントに限った話ではありません。私が集客代行の案件で毎週やっているクライアント報告も、実は同じ形をしています。データを集め、レポートを作り、数字を確認し、おかしければ前の工程に戻ってやり直す——それだけだ。まさおさんの言う検証ループは、私がすでに手でやっていた作業に、名前を付けてくれたようなものでした。

実際そうだ。私は分身AIや凛ちゃんに相談するとき、頼んで終わりにはしません。出てきた答えを一度読み、これは本当に私が言いたいことかを確かめ、違えば言い方を変えてもう一度頼みます。人間がやる検証も、機械がやる検証も、行って終わりではなく、確かめて戻るところまでが一セットなんですよね。

実際に試してみました。税込み計算に意図的なバグを仕込み、pytestで検証を走らせると、「expected 110, got 111」というエラーが返ってきました。原因は、math.ceilの使い方の間違いだった。修正してもう一度同じ検証を走らせると、2件とも合格しました。自分の目で見た。動画で説明されていた「検証→修正→再検証」が、そのまま目の前で動いた瞬間でした。あわせて、Anthropic公式ブログ（claude.com公式ブログ）を実際に読み、まさおさんの解説と突き合わせてみた。驚くほど正確だった。単発・埋め込み・連鎖・PR常設という4段階の呼び方は、公式ブログの表現とそのまま一致しています。

実際に検証ループを動かした記録（税込み計算のバグを仕込んだスクリプトで、失敗→修正→合格を実行）

※上の2枚とこの動画はどちらも実物です。動画は、ttyd（実端末）をPlaywrightのブラウザ内蔵録画機能でそのまま録画したもの（26秒・静止画の連結ではない）。macOSのスクリーン録画権限に頼らず、ブラウザのビューポート録画だけで撮影した。

この往復にかかる時間は、正直ばかにできない。一日に何度も同じことを繰り返すので、地味に手間がかかります。でも、この往復を機械に任せられる範囲が広がれば、私の時間はその分だけ、他のことに使えるようになる。まさおさんの動画を見て、私はそこに一番期待しました。

今日できること：AIに何かを頼んだとき、返ってきた答えをそのまま使わず「本当にこれで合ってるか」を一言で確かめてから使う。一言確かめられたら完了です。

「機械が拾えない残りの部分、どうしますか」——AIの審査で見えない最後の確認

検証を機械に任せられる範囲が広がるほど、残った部分がくっきり見えてきます。まさおさんはそこを課題として名指ししていました。AIの審査でどれだけ高い点数が出ても、最後はお客様の一言で不合格に転じることがある。合格条件を数字だけに預けると、この一言を拾いそこねる。

「問題は、機械が拾えない残りの部分、どうしますか、ということなんです。スクリプトやテストの実装の中で、人間が手でやって確認として残り続けているものが課題ですね。その手作業をループに置き換えたら、できる限り人間は手放しで仕事できますよね、という話をしています。」

まさおさん — 3:27〜

ここで思い出したのは、若い頃に情報商材で痛い目を見た話——見た目だけは、やたら豪華だったんですよね。開けてみたら中身はスカスカで、正直かなり凹みました。検証ツールにも、同じ危うさがあると思っています。以前、別のAIツールを実際に検証したら、もっともらしい嘘をつかれたことがある（Genspark 6.0でAIが嘘をついた｜日本語の実機検証）。検証ループがあっても、最後に気づくのは結局、人の目でした。

導入して安心した瞬間が、一番危ない——中身を誰も見ていないまま「検証済み」の顔をした成果物が出てくることは、普通にあるんですよね。

私自身、過去に中身の薄い商品を売ってクレームをもらったことがあります。だからこそ今は、機械のチェックが通った後も、最後に一度は自分の目で中身を見る、という一手だけは手放さないと決めています。

カタカナ用語で煙に巻かれて、中身を確かめずに丸ごと信じてしまう側には、もう二度と回りたくない。

だからこそ最近は、機械のチェックリストに加えて、もう一つ簡単な基準を決めるようにしています。数字が並んでいるだけの報告書ではなく、実際にお客様に届く文面や画面だけは、必ず自分の目で最後に読みます。それでは本末転倒だ。全部を疑うと、それこそ検証ループの意味がありません。見る場所を絞ることが、手放す練習の一歩目でした。

今日できること：最近「チェック済み」「対応済み」という言葉だけで安心して中身を見ていないものを一つ思い出し、5分だけ実物を開いて確かめる。5分開けたら完了です。

まさおさんが解説する王道の実装ワザ6つ——リンターからルーブリックまで

正直に言うと、道具の名前の羅列だけを聞いていた時間は、私にはあまり刺さりませんでした。スラッシュコマンド、ツールチェーン、コードレビューコマンド、GitHub Actions、スペックやルーブリック、独自スクリプト……名前を並べられても、自分の商売のどこで使うのかがつながらなかったからだ。手が止まったのは、その次の一言でした。

「私も自分の独自のやり方でやったりしますけど、クロードが準備してくれてるのは良質なものが多いので、それを頼るっていうのも一ついいかなと思います。」

まさおさん — 5:24〜

全部を自作しなくていい、という話なんですよね。これを聞いて、正直かなり肩の力が抜けました。外壁塗装リフォームの集客代行という案件を一人で抱え込んでいて、反響の件数もチェックリストの消し込みも、毎回自分の目でもう一度数え直さないと落ち着かないんです。気づけばそうだった。祖父の味見と同じ動きを、私はスプレッドシートの上でやっていました。道具はもう揃っている……あとは選ぶだけだ。

実際にAIと一緒に手を動かしながら基準を作っていく感覚は、以前AIで遊ぶことから始まる16時間ループにも書きました。気負う必要はない。検証ツールも、遊びながら試すぐらいの軽さで一つ選んでみるところから始めていいと思います。

実際にどれから手をつけるか、動画を見ながら考えてみました。GitHub Actionsは、私の環境にはまだ大掛かりすぎる気がした。まず試すなら、クロードのコードレビューコマンドか、自分の言葉で書いたルーブリックのどちらかだと思っています。派手な自動化から入らず、地味なところから試すのが、結局は一番早い——そんな気がしています。

今日できること：スラッシュコマンド・リンター・GitHub Actions・ルーブリックのうち一つだけ選び、名前と用途を1行で書き出す。書けたら完了です。

「1回言葉に起こしていって」——人間の一言をルールにして渡す

大事な話だ。手作業をそのままにせず、まず言葉にします。まさおさんはこの手順を、丁寧に踏むべきだと強調していた。

「公式からも一応こういう案内がありました。書き方としては、客観的なルールを書けばオッケーで、書けば書くほどクロードが頼れる相棒になる。」

まさおさん — 8:05〜

私はここで、自分の性分と向き合わされました。私はMaximizerという資質が1位で、Achieverが27位です。「もっと良くできない?」が先に立って、「これで十分」がなかなか言えません。80%で出せばいいと頭では分かっているのに、心はいつも満点を求めてしまうんですよね。

妻には「教えたがり」「おせっかい」とよく言われます。悪い癖だ。求められていない場面でもつい口を出してしまいます。この癖のままだと、ルールを書いて渡すのではなく、毎回自分が横から手を出す形になります。ルールを一度きちんと言葉にして渡す、というまさおさんのやり方は、私にとっては「教えたがり」を仕組みへ移し替える練習でもあった。手放すことについてはケアと平和を、自分の帰る場所から考える記事にも書いています。

実際に一つだけ、ルールを書いてみました。「反響件数のレポートは、数字の合計だけでなく、上位3件の内容を必ず引用して見せること」。たったこれだけだ。でも書いてみると、自分がいつも何を確認していたのか、初めて言葉になりました。曖昧なまま抱えていたチェックほど、実は3行あれば渡せるのかもしれない。

今日できること：普段つい口を出してしまう確認事項を一つ選び、「客観的に見て何をチェックしているか」を3行で書き出します。3行書けたら完了です。

単発・埋め込み・連鎖・PR常設——4段階の格上げ

検証ループの使い方には、格上げの順番があるとまさおさんは説明していました。

「まず単発っていうのは、自分が明示的に呼ぶ、毎回そのプルリクエストをチェックしてとか、毎回こういう検証を走らせてくださいみたいなことを言っていく感じなんです。」

まさおさん — 9:53〜

「連鎖であれば、そのチェーンみたいな形で、スキルとして検証込みのサイクルを丸ごと自動化していくパターンもあります。あとはチームの標準の仕組みとして、プルリクエストごとに全員に発火するような検証を準備しましょう、という話です。」

まさおさん — 10:34〜

単発、埋め込み、連鎖、PR常設。頻度が高まるほど、一段ずつ上へ格上げする——これは私が集客代行の案件でやろうとしていることと、そのまま重なります。いきなり全部を仕組み化しようとして、毎回止まっていました。まず一回だけ自分で確認のやり方を試す。それだけだ。うまくいったらスキルの中に埋め込みます。それだけの話でした。

しかもね、一足飛びに完璧な仕組みを作ろうとするのは、地頭の良し悪しではなく、私のMaximizerな欲張りの問題です……小さく始めて、一段ずつ上げる。動画のこの順番を見て、私は自分がずっと一段目（単発で味見してみるだけ）を飛ばして、いきなり三段目（連鎖で全部自動化）から始めようとしていたことに気づきました。

格上げの順番を守ると、失敗したときの被害も小さく抑えられます。考えてみれば当然だ。単発の指示なら、間違っていてもその一回だけで済みます。怖いのはここだ。連鎖やPR常設まで一気に組んでしまうと、間違った基準がチーム全体に広がってしまいます。焦って一段飛ばしにしないことが、結局は一番の近道なのだと、この動画を見て学びました。

今日できること：仕組み化したい確認作業を一つ選び、まず「単発」でいいので一回だけ自分の言葉で指示してみる。一回試せたら完了です。

「みんなで品質を守り抜く」——ベルトコンベアの終着点

動画の後半で、まさおさんはAnthropic社内の実例を紹介していました。流れはこうだ。コードが生まれたらレビューし、ベリファイし、デザインと照合して、最終的にプルリクエストへ渡します。その流れをこう表現していました。

「検証済みのものが、どんどん徐々にベルトコンベアみたいな形で渡されていって、最後プルリクエストで、みんなで品質を守り抜くみたいな形でやってるようです。」

まさおさん — 11:53〜

「みんなで守る」という言葉が、私には一番刺さった。私の商売は三方よしが基本です。自分だけ、相手だけ、世間だけではなく、みんなが満たされる形を探します。検証も同じで、一人が最後まで抱え込んで守り抜くものではなく、機械と人が持ち場を分けながら一緒に守り抜くものなんですよね。

まさおさんは最後にこう締めくくっていました。手作業をどんどんスキルにして、検証ループという形で作って、新しいタスクで確認して、連鎖させながら再現性を上げて、チームでも共有して改善する。回せば回すほど強くなるような、手戻りも減るような形にしていきましょう、と。

この記事を読み返してみると、私が今日から渡せそうなのは、たった一つの確認作業です。それでも、動画の最初と今とでは、渡すことへの怖さが少し変わった気がしています。理由はシンプルだ。検証は、独り占めするものではなく、機械・別の目・自分の三者で分け合うものだと分かりました。三方よしは、お客様と自分の間だけの話ではなく、自分の中の仕事の分け方にも当てはまるのだと、今回初めて気づきました。

今日できること：今抱え込んでいる確認作業のうち、誰かと分担できそうなものを一つ選び、「ここまでは自分、ここからは渡す」の境界を1行で書く。書けたら完了です。

よくある質問（FAQ）

まとめ｜確認は、渡せる分だけ渡していい

まさおさんの動画は、検証をすべて機械に丸投げする話ではありませんでした。 機械の検証を通っても、最後にお客様の一言で不合格になることがある——そこだけは、今も昔も変わりません。整理するとこうだ。渡せる部分は道具を使って渡し、機械が拾えない部分は最後まで人が見ます。その線引きを自分の言葉で決めることが、検証ループを使いこなす一番の鍵だった。

この動画を見終えて、私が実際に変えるのは、外壁塗装リフォームの集客代行という案件の確認作業です。毎回自分の頭の中だけでやっていたチェックを、まず一つだけ言葉にして書き出し、単発の指示として試してみます。完璧な仕組みを最初から作ろうとせず、動画が案内していた順番どおり、一段ずつ格上げしていくつもりだ。

まさおさんの動画は専門用語も多く、正直すべてを理解できたわけではありません。それでも、機械に渡していい部分と、自分の目でもう一度だけ確かめたい部分を分けて考えるきっかけをもらえました。気になった方へ。興味のある方は、動画本編もあわせて覗いてみてください。