社内文書をAIに渡しても「判断の感覚」は届かない——知識と判断を分けて設計する

「情報を渡している」のに出力がずれる理由

社内文書をAIに参照させたのに、返ってくる内容が「どこか違う」と感じた経験はないだろうか。

情報は渡してある。業務マニュアルも、対応フローも、ガイドラインも読み込ませている。それでもAIの提案は自社らしくない、あるいは判断の軸がどこかぼやけている——そう感じるとき、原因の多くは「渡している情報の種類」にある。

社内文書に記されているのは、事実とルールが中心だ。「この申請には〇〇が必要」「対応期限は◇日以内」「この案件は部長承認が必要」——こうした記述は文書に書きやすく、AIも参照しやすい。

一方、「この提案のトーンは自社らしくない」「この優先順位の付け方は違う」「この表現では顧客に刺さらない」といった感覚は、文書にはほとんど書かれていない。書いたとしても「誠実な対応を心がける」「顧客視点を大切に」といった抽象表現にとどまり、AIが使える形にはなっていない。

事実とルールは検索参照（RAG）で渡せる。しかし判断の感覚は、別の渡し方が必要だ。

「判断」はルールの記述より例示で伝わる

AIに判断基準を伝えるとき、ルールを言葉で説明するよりも効果的なのは「例示」を渡すことだ。

具体的には、次のようなセットを用意する。

• 採用したアウトプット＋「なぜ良かったか」の理由（1〜2文）
• 却下したアウトプット＋「なぜ却下したか」の理由（1〜2文）
• 採用・却下の境界線になった条件があれば、それも一言添える

たとえばAIに企画案のドラフトを作らせる場合、「顧客視点で書くこと」と指示するだけでは届かないことがある。実際に採用した企画と却下した企画を並べて示す方が、AIは判断の感覚を早く掴む。

AIが「ずれた答え」を返すとき、自社の評価基準が浮かびあがるでも指摘したとおり、出力のずれは自社の判断基準が言語化されていないサインでもある。ずれを感じたとき、文書を増やすより先に「例示を作る」という発想が助けになる。

設計を「知識層」と「判断層」の二つに分ける

実用的な整理として、AIへの情報の渡し方を二層に分けることを勧めたい。

知識層：事実・ルール・業務フローを記述した文書。RAGやドキュメント参照として渡し、更新は文書の改訂タイミングに合わせる。

判断層：採否の例示と、その理由の記述。システムプロンプトや評価データとして渡し、業務の中で発生した判断を継続的に追加していく。

この二層を混在させると、AIはどちらを優先すべきか判断できなくなる。結果として「文書に書いてある正解を返すだけ」の動きになりやすい。

「何を知ってほしいか」と「どう判断してほしいか」を別々に設計する。この分離が、意図した出力に近づくための最も直接的な方法だ。

AIの精度を育てるには、却下の記録が欠かせないでは採否ログを組織の資産にするアプローチを紹介している。そのログを「判断層」として位置づけることで、知識と判断が補完し合う設計が生まれる。

判断の例示を、業務の中から小さく作る手順

判断層の整備は、大規模な準備を待つ必要はない。次の手順で始められる。

1. AIに任せたい作業を一つ選ぶ——過去に「これは違う」と感じた出力があれば、その業務が候補になる。
2. 良い例と悪い例を各2〜3件集める——社内の実際のアウトプットから選ぶ。新たに作る必要はない。
3. それぞれに理由を1〜2文で添える——長い説明より、端的な一言の方がAIには伝わりやすい。
4. システムプロンプトに組み込んで変化を確認する——例示の前後で出力を比べ、効果を確かめる。

この繰り返しが、自社の判断基準をAIに少しずつ移していくプロセスになる。文書が整うのを待つより、小さな例示から動かす方が現実的だ。

どこから手をつけるべきか整理が必要な場合は、しぼるのDX伴走支援として相談を受け付けている。