完成した作業マニュアルだけを見ると、最初から条件が整理されていたように見えます。しかし実際には、作業者から質問が出て、誤りが見つかり、例外が追記されながら仕様が完成します。

曖昧な指示を研究・改善するなら、最終版だけでなく、質問、回答、差し戻し、修正前後の履歴が重要なデータになります。

本記事は、業務履歴を研究・改善用データへ変える考え方を整理するものです。実際の利用時には、機密情報、個人情報、契約上の利用範囲を確認する必要があります。

最終版からは消えてしまう情報がある

仕様書へ「空欄は半角ハイフンで入力する」と追記されていても、なぜそのルールが必要になったのかは分かりません。

変更履歴をたどると、作業者ごとに空欄、全角ハイフン、NULLが混在し、納品形式に問題が起きたため追記されたことが分かるかもしれません。

一件の差し戻しを一組のデータにする

1. 修正前の指示
2. 作業者が行った処理
3. 依頼者または検品者の指摘
4. 作業者が迷った理由
5. 確認質問と回答
6. 修正後の指示
7. 正しい処理例

この構造にすると、曖昧さの発見、適切な確認質問、明確な指示への書き換えを別々の課題として利用できます。

差し戻しがすべて指示の曖昧さとは限らない

単純な見落とし、操作ミス、教育不足、ツールの不具合もあります。原因を分類せず、すべてを曖昧な仕様として扱うと、不要な説明が増えます。

• 指示に条件が書かれていなかった
• 複数の解釈が可能だった
• 例外事例が提示されていなかった
• 指示は明確だが見落とされた
• 画面やツールが誤操作を誘発した

質問が集中する箇所を優先して改善する

質問件数だけでなく、同じ質問をした作業者数、誤りの影響、回答に要した時間、再発率を集計します。多くの人が同じ場所で止まるなら、個人の理解不足より仕様や画面の問題である可能性があります。

変更理由を残す

文章の差分だけでは、なぜ変更したのか分かりません。「質問が5件発生」「検品で誤りが20件」「顧客判断により例外追加」のように、変更理由と根拠事例を記録します。

将来ルールを見直す際にも、古い記述を削除してよいか判断しやすくなります。

実データは匿名化・抽象化して利用する

問い合わせ履歴には、顧客名、個人情報、未公開仕様が含まれる場合があります。研究・学習用には固有名詞を置き換え、数値や業務内容を抽象化し、それでも曖昧性の構造が維持されるか確認します。

現場改善とAI評価を同じデータから進められる

変更履歴を整備すると、AIが曖昧な指示を検出できるかを評価するだけでなく、現在のマニュアル改善、研修問題、FAQ作成にも利用できます。

失敗を削除するのではなく、どの指示が、どのように誤解され、何を追加すれば解決したかを残すことが、業務データの価値になります。