業務の現場で何年も経験を積むと、対応しにくい顧客、曖昧なケース、簡単に見えて実は難しい質問にも直感的に対処できるようになります。やがて、その仕事の質を支えてきた判断力を失わずに、チーム全体へ広げたいと考えるようになります。
そこで、知識を文章にします。SOPを整備し、社内Wikiを作り、ときには付き添いながら直接教えます。現在なら、それらの文書をAIエージェントへまとめて登録し、優秀な担当者のデジタル版をすぐに作ろうとするかもしれません。
ところが、AIは期待から外れた対応をします。存在しないポリシーを作ったり、微妙な判断が必要な質問に、教科書を読むロボットのように答えたりします。
なぜでしょうか。文書は拡張できても、判断は拡張できていないからです。
静的な資料は役立ちますが、こちらに問い返してはくれません。新しいケースを生み出すことも、実際の顧客との会話を集めて社内の方法がどこで破綻するかを示すこともありません。書いた時点の知識は保存できますが、現実とともに知識を育てることはできません。
専門知識は、文書にしただけでは信頼できる仕組みになりません。新しい状況を継続的に表面化し、専門家の判断を集め、方法の改善を促すシステムの中で使われて初めて、信頼性が高まります。
静的な知識だけでは判断を伝えられない
ハンドブックや研修では、考え方を説明し、いくつかの事例を見せられます。しかし、担当者はそれを自分の状況に適用しなければなりません。現実には、どのWikiでも網羅できないほど多くの変化があります。
SOPは手順を記録できますが、仕事の良し悪しを判断する基準までは伝えきれません。すべての手順を終えても、本来の目的を外すことがあります。指示は一方向に流れ、専門家からの判断は戻ってきません。
具体的な仕事をレビューする直接指導なら、より効果的です。専門家が個別のケースを見て、間違いを直し、違いを説明できます。しかし、この方法は拡張しにくく、一人の専門家が確認できる件数には限界があります。
従来は、次のようなトレードオフがありました。
| 形式 | チームを超えて拡張できる | 専門家の判断を保持できる |
|---|---|---|
| 書籍／研修 | ✓ | ✗ |
| SOP／Wiki | ✓ | ✗ |
| 直接指導 | ✗ | ✓ |
| エージェント＋判断基準 | ✓ | ✓ |
現在よく使われる近道は、ハンドブックを整える代わりに、会話記録、メール、文書、過去の回答をすべてAIへ入れる方法です。
しかし、それだけでは問題は解決しません。AIがその資料の山をまねるようになるだけです。
過去の回答には、優れたものもあれば、急いで作ったものや古くなったものもあります。AIは、どの回答を現在の基準として採用すべきか自然には判断できません。また、AIがコピーするのは発言された内容であって、そのとき何を考えたかではありません。私たちの専門性は、考慮した状況、選ばなかった選択肢、対応を止めて担当者へ引き継ぐと判断した境界にあります。
中心的な問題は、単に規模を広げることではありません。欠けているのは、新しい状況を継続的に示し、現在の方法が破綻する場所を明らかにし、専門家の判断を再び運用手順へ戻すフィードバックの仕組みです。この循環がなければ、知識は静的なままです。保存はできても、扱うべき現実の変化に合わせて進化できません。
必要な二つの要素は、すでにある
多くの業務チームには、信頼できる仕組みに必要な二つの要素がすでにあります。
一つは原則です。時間をかければ説明できるルール、区別、基準です。何が重要か、何を避けるべきか、どこが境界なのかを私たちは知っています。
もう一つは、判断を実際に適用した瞬間です。特定のケースを見て、良い回答が何かを明確に判断できた場面です。難しい顧客へ適切に対応したとき、ポリシーに対して妥当な例外を認めたとき、回答案を見てすぐに「これは私たちの言い方ではない」と分かったときなどが該当します。
問題は、この二つがなかなか結びつかないことです。原則が仕事の現場まで届くとは限らず、優れた個別判断が仕組みに戻されるとも限りません。知識は存在していても、積み重なっていきません。
専門知識の単位：シナリオ＋判断基準
二つの要素を結びつけるには、知識の定義を変える必要があります。ルールを書くことに加えて、状況と基準が交わる具体的なケースを記録します。
- シナリオは、チームやエージェントが直面する可能性のある現実的な状況です。
- 判断基準は、その状況で良い回答が満たすべき基準です。
実務では、次のようになります。
- シナリオ（テスト）： フライトが欠航したため、顧客が返金ポリシーの例外を求めている。
- 現在の手順： 「申し訳ありませんが、当社のポリシーでは30日を過ぎた返金はできません」
- 私たちの判断（基準）： 不合格。 エージェントは欠航に触れ、不可抗力に関する例外手続きの存在を示し、一律に拒否するのではなく担当者へ引き継がなければならない。
問い合わせの振り分けを行うボットなら、次のようになります。
- シナリオ： 利用者が、二通りに解釈できる曖昧な技術質問をしている。
- 現在の手順： エージェントが最もありそうな意図を推測し、自信を持って5段落の技術回答を返す。
- 私たちの判断： 不合格。 技術的な手順を示す前に、意図を絞り込む確認質問を一つだけしなければならない。
ここで、専門知識がシステムで使える形になります。シナリオは複雑な現実を記録し、判断基準は「良い対応」の意味を記録します。この二つを組み合わせることで、一度きりの専門家による修正が、再利用可能で自動検証できる基準に変わります。
エージェントが手順書で、判断基準が現実との照合になる
この方法で作る知的な仕組みには、役割の異なる二つの要素があります。
手順書（エージェント設定）： 指示、システムプロンプト、ナレッジベースです。仕事の進め方について、現時点で最善だと考える方法をまとめます。
現実との照合（シナリオと判断基準）： 具体的で現実的な状況と、良い回答が満たすべき基準の組み合わせです。手順書が実際に機能するかを証明します。
力を発揮するのは、どちらか一方ではなく、二つを結ぶ循環です。エージェントは現在の手順書に沿って回答し、シナリオと判断基準がその回答を検証します。基準を満たさなかった場合、それは単なるエラーではありません。方法を変えるべき場所を正確に示す信号になります。
この仕組みによって、業務の専門家の役割は大きく変わります。すべての会話を自分で品質確認したり、SOPが守られていることをただ期待したりする必要はありません。日常的な実行はシステムに任せ、専門家は弱点の確認、新しい判断基準の追加、手順書の改善に時間を使えます。
本当の資産は判断ライブラリ
判断基準があればエージェントを再構築できます。しかし、エージェントだけから判断基準を復元することはできません。
多くのサービスは、エージェント設定を主な成果物として扱い、評価を後回しにします。私たちは、その順序は逆だと考えています。
チームが本当に大切にする基準は、判断の中にあります。エージェント設定は、その基準を満たすための現時点での最善案にすぎません。
エージェントは変わります。新しいことを学び、事業環境が変わり、より優れた基盤モデルが登場します。プロンプトを書き直し、文書を更新し、業務フローも変えていきます。そのすべてを通じて、判断ライブラリは、新しいバージョンが以前より本当に良くなったかを示す安定した基準になります。
十分なシナリオと判断基準があれば、エージェントをゼロから再構築できます。判断ライブラリが「良い対応」の意味を具体的に定義しているからです。一方、エージェントだけがあっても、判断基準は復元できません。どの行動が重要か、どの間違いが許されないか、プロンプトを変えたときに何が壊れるかが分かりません。
この方法は、専門家が実際に判断するときの性質にも合っています。チームの仕事すべてを網羅する完璧な理論を、最初から書くのは非常に困難です。それよりも、具体的な入力と出力を見て「これは違う。理由はこうだ」と説明する方が簡単です。
シナリオと判断基準は、その自然な強みを生かします。最初から完璧な手順書を書く必要はありません。システムが自分たちの基準を満たしているか、判断し続ければよいのです。
システムが改善する仕組み
AIの回答失敗は行き止まりではありません。明文化した指示に、暗黙の専門知識が足りない場所を正確に示す診断材料です。
シナリオを実行すると、エージェントは指示に忠実に従います。伝えたとおりに対応したのに、それでも回答が基準に届かないことがあります。
その失敗には大きな価値があります。文章にした方法と、本当に意図していた方法の差が明らかになるからです。そこで、*「意図していたのに、まだ言葉にできていなかったことは何か」*と具体的に問い直せます。
不足している文書を追加すれば解決する場合もあれば、Wiki内の矛盾した指示を直す必要がある場合もあります。チームが頭の中だけで共有していた細かな区別を、初めて明文化することもあります。その違いを手順書へ加えると、同時に数十件のシナリオが改善する可能性があります。
実際の業務は、この改善ループをさらに強くします。予想していなかった質問を顧客がする。エージェントが担当者へ引き継ぐ、うまく答えられない、または社内手続きの分かりにくさが見つかる。その複雑な現実が新しいシナリオになり、人が行った修正が新しい判断基準になります。現実が新しいケースを与え続けるため、システムは改善していきます。
判断ライブラリを先に作る
Codeerも、この仕事の進め方も、まだ初期段階です。しかし、チームの仕事を自動化したい、または社内の専門知識を活用する仕組みを作りたいなら、次にすべきことは明確です。システムプロンプトを際限なく調整するのではなく、シナリオと判断基準を蓄積してください。
これらを後付けの品質確認として扱わないでください。判断ライブラリは、業務上の競争力になります。品質基準を定義し、基盤モデルが変わったときにチームを守り、複雑な現実の会話を仕組み全体の改善につなげます。
静的なエージェントを作る段階から、専門家の判断を拡張する段階へ進むなら、Codeerを無料で始めるか、デモを予約するからお試しください。