+++ title = "AIに仕事を任せて一番効いたのは、プロンプトの工夫ではなく「仕組み」だった" date = 2026-07-04 description = "AIエージェントの運用で効いたのは凝ったプロンプトではなく、自己申告を信じない仕組みだった。毎日回している5つの型を、なぜ効くか・無いと何が壊れるかまで書いた実践ログです" [taxonomies] tags = ["AIエージェント", "AI活用", "仕組み化", "開発生産性"] [extra] public = true belief_version = 1 ai_written = true one_true_sentence = "凝ったプロンプトより、疑う仕組み。AIの自己申告は、何周させても高得点が返ってくる。" [[extra.faqs]] question = "AIエージェントの運用で、プロンプトの工夫より仕組みが効くのはなぜですか？" answer = "プロンプトは1回のやり取りの質を上げますが、AIが「完了しました」と自己申告した内容が本当に正しいかは別問題だからです。実装した本人（AI）は自分の成果物に甘くなりがちで、これは人でもAIでも同じです。効いたのは、完了報告をそのまま信じず、別コンテキストの別AIに検証させる・合否をテストやビルドの結果で機械判定する・状態をファイルに書かせて引き継ぐ・失敗が続いたら自動で止めて人を呼ぶ・モデルを作業単位で使い分ける、という「自己申告を信じない仕組み」の方でした。" [[extra.faqs]] question = "AIの自己申告を検証するには具体的に何をすればいいですか？" answer = "実装させたAI自身に検証させないことが起点です。完了報告をそのまま信じず、別コンテキストの別AIに「意図はこれ。本当に動くか壊してみて」と渡してから完了扱いにします。あわせて合否は「できました」という言葉ではなく、テスト・ビルド・実ブラウザでの動作確認が通ったかどうかの機械判定にします。毎朝自動で環境をチェックするスクリプトを走らせ、赤が出たら通知が飛ぶようにしておくと、自己申告に頼らず異常に気づけます。" +++ AIに仕事を任せる時、プロンプトの工夫より効いたのは「仕組み」の方でした。凝った指示文をどれだけ練っても、返ってくる完了報告そのものが甘ければ意味がありません。実際に毎日回している型は5つあります。 ## 実装した本人に検証させない **完了報告をそのまま信じない。別コンテキストの別AIに「意図はこれ。本当に動くか壊してみて」と渡してから完了扱いにする。** 作った本人は自分の成果物に甘くなります。これは人でもAIでも変わりません。同じ会話の続きで「ちゃんとできてる？」と聞き直しても、直前の自分の判断を追認するだけになりがちです。だから実装させたAIとは別のコンテキストを開き、経緯を知らない別のAIに「元の意図はこうだった、本当に動くか疑ってかかって壊してみてほしい」と渡します。この一手間を抜くと、完了報告がそのまま完了の事実として積み上がっていき、あとから見つかる不具合の量が増えます。実装役と検証役を分けること自体が、仕組みの一番の土台になっています。 ## 合否は機械判定にする **「できました」はテスト・ビルド・実ブラウザが通って初めて合格。** 言葉での完了報告は、どれだけ丁寧な言い回しでも判定基準にしません。テストが通ったか、ビルドが通ったか、実際にブラウザで動かして狙った挙動になっているか。この機械的な合否だけを基準にしています。あわせて、毎朝自動で環境をチェックするスクリプトを走らせ、何かが赤くなっていたら通知が飛ぶようにしてあります。人が気づくより先に、機械が気づく形にしておくと、小さな崩れを溜め込まずに済みます。ここを「大体できてそうだから良し」で運用すると、機械判定という関所自体が形だけのものになってしまいます。 ## 状態は全部ファイルに書かせる **セッションを跨ぐ情報は会話の記憶に頼らせず、STATUS.mdなどのファイルに書かせる。次のセッションはそれを読んで再開する。** AIとのやり取りは1つの会話の中で完結するとは限りません。作業が長引けば、途中で会話を区切って別のセッションに引き継ぐことになります。その時、それまでの経緯を口頭の記憶だけに頼ると、引き継いだ側が同じ調査をやり直したり、決めたはずのことを覆したりします。なので、今どこまで進んでいて何が残っているかを、その都度ファイルに書かせます。次のセッションは会話の記憶ではなく、そのファイルを読むところから始める。状態の正本を会話でなくファイルに置くだけで、引き継ぎのたびに情報が目減りすることがなくなります。 ## 連続失敗したら止めて人を呼ばせる **同じ失敗が続いたら自動停止して報告させる。無限に粘らせると、粘ってる風の空回りに時間とトークンが溶ける。** AIは「うまくいくまで粘る」ことができてしまいます。一見すると美徳に見えますが、同じ原因で同じ失敗を繰り返している時にこれをやらせると、見た目は頑張っているのに中身は同じ壁に何度もぶつかっているだけ、という状態になります。時間もトークンもそこに溶けていきます。だから、同じ失敗が一定回数続いたら、そこで自動的に止めて人に報告させるようにしています。粘るかどうかを判断するのはAI自身ではなく、失敗が続いたという事実そのものです。 ## モデルは作業単位で使い分ける **実装は中位モデルで十分。最上位モデルを使うのは設計判断と、複数案件をまたぐ統括だけ。** すべての作業に一番賢いモデルを使う必要はありません。決まった手順に沿って実装する作業は、中位のモデルで十分にこなせます。最上位のモデルを充てるのは、設計上の判断が必要な場面や、複数の案件を横断して状況を統括する場面だけに絞っています。作業の重さとモデルの重さを一致させることで、コストと速度のバランスを取っています。 ## 共通しているのは「信じない」こと ここまでの5つに共通しているのは、AIの自己申告を信じないことです。自己採点は、何周させても高得点が返ってきます。これは意地悪でそうなっているのではなく、自分（AI）の出したものを自分で採点すれば、多少なりとも甘くなるのが自然だからです。だから、完了の判定を「本人の申告」から切り離し、別の目・機械的な基準・ファイルに残った事実・失敗回数の記録という、本人の外側にある基準に置き換えます。凝ったプロンプトより、疑う仕組み。効いたのはこちらでした。 一つ一つは特別な発明ではありません。実装と検証の役割を分ける、完了の基準を言葉でなく結果で決める、記憶でなくファイルに引き継ぐ、粘りを本人任せにしない、モデルの重さを作業の重さに合わせる。どれも単体では地味な工夫です。効いているのは、これらを毎日欠かさず回し続けていることの方だと思います。1回やって満足するのではなく、疑う仕組みを常設にしておくこと自体が、プロンプトの工夫より長く効き続けました。 ## 今日からできる一手 すべてを一度に仕組み化する必要はありません。まずは1つだけ。次にAIに何か任せた時、完了報告が返ってきても即座に信じず、別の会話を開いて「これで本当に合っているか、疑ってかかって確認して」と別のAIに渡してみる。これだけで、自己申告と検証を分けるという一番効いた型を体験できます。 ## 3行まとめ 1. **実装した本人に検証させない** — 別コンテキストの別AIに、意図を渡して疑わせてから完了扱いにする 2. **合否は機械判定・状態はファイル・失敗は自動停止** — 言葉の完了報告ではなく、結果とファイルと失敗回数を基準にする 3. **共通しているのは「AIの自己申告を信じない」こと** — 自己採点は何周させても高得点が返ってくる --- ※この記事は、本文に登場するAI相棒（Claude）との共同執筆です。何を運用ルールにするか・何を公開するかの判断は人間側、実行と初稿はAI側です。