7月30日、Atomic Objectが「Get Good Results from AI Tools: Define, Feed, Check」と題した記事を公開した。AIツールから確実に良質なアウトプットを得るための「定義・供給・検証」という3つの習慣について詳しく紹介している。
AIから期待通りの結果が出ないとき、多くの人はより高性能なモデルや巧みなプロンプトを求める。しかし研究が指し示す方向は別にある。Berkeleyの研究（MAST）でマルチエージェントの失敗事例を分析したところ、約42%の失敗が「仕様と設計の問題」——曖昧な指示、未定義の役割、終了条件の欠如——に起因していた。これは調整や検証の問題を上回る最大の失敗カテゴリだ。AIの失敗の多くはモデルの問題ではなく、マネジメントの問題である。
この前提に立って、記事では「Define（定義）」「Feed（供給）」「Check（検証）」という3つの習慣を提示する。コードは一切不要だ。
Define：「完成」の定義を明確にする
AIに要件を推測させると、正しく当てられる確率は**約41%**にとどまる（MAST）。厄介なのは、AIはリクエストが曖昧だと気づいていても、確認せずに回答してしまう点だ。「手を挙げられない緊張した新入社員」のような振る舞いをする。
最も費用対効果の高い対策は、プロンプトの末尾に「まず clarifying questions（確認事項）を聞いてください」と加えることだ。たった5語のこの一文が、FSE 2024のClarifyGPT研究では、動作するコードを生成する確率を**71%から81%**に引き上げた。
さらに効果を高めるには、AIに質問させた後、その回答を1つの簡潔な仕様書にまとめさせることだ。ある実践例では、1文のアイデアからAIに32の質問をさせ、最終的な仕様書を作成した。その質問の約3分の1は、本人が気づいていなかったギャップを突いていたという（VelvetShark）。
定義に関するもう2つの原則
形容詞ではなく具体例で定義する。 「我々らしいトーンで」という指示では不十分で、実際のサンプルと「これはNG」という具体的な否定例を組み合わせるのが効く。「良い文・やりすぎな文・無難すぎて死んでいる文」の3点セットを見せることで、モデルがトーンの境界を学習する（Search Engine Land）。
ルールは絞り込む。 指示が増えるほど遵守率は落ちる。経験豊富な実践者は常設の指示ファイルを60行以内に抑えている（HumanLayer）。「あると良い」20のルールより「必須」5つの方が強い。AWSの内部チームも、非構造化された指示が「まったく異なる結果」を生むと判明した後、短い標準作業手順書（SOP）の形式に落ち着いた（AWS）。
Feed：正しい素材だけを与える
Stanfordの研究者がフロンティアモデルに誤りを含む文書（誤った投薬量、誤った記録）を渡したところ、モデルは自身の正しい知識を捨てて、60%以上の確率で文書の誤りをそのまま繰り返した（ClashEval）。AIはモデル自身の知識よりも、与えられた資料を信頼する。インプットの質が直接アウトプットの質になる。
逆説的に聞こえるが、コンテキストは多ければ多いほど良いわけではない。 Chromaが18のフロンティアモデル、194,000回の呼び出しを対象にテストしたところ、入力が増えるにつれてすべてのモデルの性能が劣化した（Context Rot）。10万語のノイズに埋もれた情報より、300語の集中した概要の方が優れた結果を出す。Anthropicの内部チームは、目的に必要な「最小限の高品質トークン」を見つけることを目標として掲げている（Anthropic）。
素材の「鮮度管理」も重要だ。IntercomでAI解決率80%を達成したチームは、ナレッジベースの更新に週約25人時を費やしている（Intercom）。一方、Air Canadaは存在しなくなったポリシーをチャットボットが引用し続けたことで、損害賠償を命じられた（CBC）。AIが依存する文書には有効期限を設け、定期的に見直す必要がある。
Check：別の目でアウトプットを検証する
同じチャット内で「確認して」と頼んでも効果は薄い。 アウトプットを作成した推論経緯を知らない「新鮮な目」の方が、欠陥をより多く検出する。同じ内容を別のチャットセッションに貼り付けて確認させると、エラー検出率が有意に改善する。これはLLMの自己修正能力を対照実験で検証した研究（arxiv:2603.12123、2026年3月公開）で示された知見で、同一セッション内での自己レビューと、コンテキストをリセットした新規セッションでのレビューを比較したものだ。著者が自分の本をセルフレビューするようなものだ、と考えれば直感的に理解できる。モデルは自身の出力のエラーに対して既知の盲点を持つが、同じエラーが「他者の出力」として提示されると問題なく修正できる（Self-Correction Bench）。
高精度な検証には、評価軸を1つに絞り、合否を明確な基準で判定させるルーブリックが効果的だ（hamel.dev）。重要な判断には、あえて別ベンダーのモデルをレビュアーに加えることも有効だ——同一モデルの集合は、同一の盲点を共有するからだ。
そして最後のゲートは必ず人間が担う。 記事中で最も印象的な事例は、高圧洗浄会社の自動化システムだ。AIが住所を読み取り、Street Viewで確認し、見積もりを下書きする——しかし顧客に価格が見える前に、技術者が必ず「承認」をタップする（n8n）。記事が調査したあらゆる事例で、本番のAI業務に最後の承認を担う人間が置かれていない例は一つもなかった。
まとめ
Define・Feed・Checkの3つは、最新モデルを必要としない。仕事を明確に定義し、正しい素材を与え、新鮮な目と人間のゲートで検証する——この規律だけで、平凡なツールが安定した成果を出し始める。コンピュータをプログラムするよりも、才能があり熱意はあるが少し自信過剰な新しいチームメンバーをマネジメントする作業に近い。
3つの習慣を実践する際の優先順位としては、Defineから着手するのが最も費用対効果が高い。プロンプト末尾への一文追加や確認質問の要求といった変更は即日適用でき、コストもかからない。Feedの改善——特にナレッジベースの鮮度管理——は継続的な運用コストを伴うため、AIの活用頻度や業務への影響度が大きいユースケースから順に整備するのが現実的だ。Checkについては、まず「同じチャットで確認させない」という行動変容だけでも一定の効果があり、ルーブリックや別モデルの導入はその次のステップと捉えると取り組みやすい。
詳細はGet Good Results from AI Tools: Define, Feed, Checkを参照していただきたい。
