熟練者の判断をAIに実装する作業の最大の障壁は、モデルの性能ではなく、熟練者自身が「なぜそう判断したか」を言語化できない点にあります。これを正面から解決しなければ、どれほど優れたモデルを使っても精度は上がりません。
専門家の判断を記録しようとしても、「これはカン」「経験でわかる」という言葉が返ってくる場面は少なくありません。形式知化とは、そのカンを分解する作業です。
ヒアリング設計で最初に行うのは、熟練者の判断を三つの要素に分解することです。第一は「判断の入力」——その判断を下す際に、何を見ているか。画面上のどの数値か、メールのどの表現か、過去のどの事例か。第二は「判断の基準」——その入力に対して、何を根拠に「良い」「悪い」「要確認」と分けているか。第三は「例外」——通常の基準が当てはまらないのはどういう場合か、その例外はどう処理するか。
この三要素の分解は、一度のヒアリングでは完成しません。熟練者の説明を聞いた後、具体的な事例(実際の入力データ)を見せながら「このケースはどう判断しますか、なぜですか」と問い返します。この往復を繰り返すことで、言語化されていなかった判断基準が少しずつ浮かび上がってきます。
ヒアリングで得た内容は、評価セット(テストケース集)に落とします。評価セットとは、「この入力に対してはこの判断が正解」というペアの集合です。熟練者が実際に処理した事例から、典型的なケース・境界線上のケース・例外ケースをバランスよく抽出します。Anthropicのevals設計ガイドは失敗事例から引いた20〜50件のテストケースで始めることを推奨していますが、熟練者の判断実装においても、小さな評価セットから始めて段階的に拡張する方針は有効です。
評価セットが揃ったら、AIへの実装形式を選びます。主な選択肢は三つです。第一は「ルール」——判断基準が明確に言語化できる場合は、条件分岐としてコードで実装します。第二は「検索(RAG)」——過去の判断事例が大量にあり、類似事例を参照することで判断できる場合は、事例検索を使います。第三は「モデルへの委譲」——入力と判断基準の関係が複雑で、ルールや検索では対応しきれない場合に、LLMに判断を委ねます。この選択は「AIにすべて任せる」ではなく、判断の性質に応じた適切な手段の組み合わせです。
実装後は必ず評価セットで精度を確認し、熟練者にサンプルを見てもらいます。このとき重要なのは「AIが間違えたケース」ではなく「AIが正しく判断できたケース」も含めてフィードバックをもらうことです。予想外に正解しているケースには、ヒアリングで拾えなかった判断基準が隠れていることがあります。
暗黙知の形式知化は、一度作れば終わりではありません。業務の変化・熟練者の異動・例外の蓄積によって、基準は更新され続けます。定期的に評価セットを見直し、ヒアリングを追加する運用サイクルが、AIへの実装を実務で使い続けるための条件です。
参考
- Anthropic: "Demystifying evals for AI agents" (2026-01-09) https://anthropic.com/engineering/demystifying-evals-for-ai-agents

ORGANIZATION / 2026.09.04
ADOPTION / 2026.09.01
REPORT / 2026.06.30
AGENTS / 2026.08.25
CONNECT / 2026.08.18
ROADMAP / 2026.08.04
NEWS / 2026.07.23
EVALUATION / 2026.07.07
AGENTS / 2026.06.02
OPERATIONS / 2026.05.19
CONNECT / 2026.04.28