マニュアルをAIに読ませるだけで終わらない｜手順を業務システムに組み込む

この記事の要点

社内資料を検索し出典付きで回答する仕組みは、探す時間を減らす候補になります。しかし回答を読んだ後に、別画面を開き、対象を探し、複数欄へ転記し、承認を依頼するなら、そこでの手間や間違いは残ります。回答の満足度と業務の完了率を分けて確認する必要があります。

いわゆるRAGは検索した情報を生成時の参照に使う構成です。それ自体が、登録や送信の安全性を保証するわけではありません。実行へつなぐ場合は、入力の検証、使える操作、承認、結果確認を別に設計します。

架空の備品申請では、利用者がマニュアルを読んで品目を選び、金額に応じた承認者へメールを送っているとします。新しい画面では、用途を入力するとAIが品目候補を提示し、承認済みカタログで品目と価格を確定します。購入金額による承認経路はルールで決めます。

カタログ外の品目は勝手に似た商品へ置き換えず、個別確認へ回します。承認後に登録を実行し、登録先から受付番号が返って初めて完了と表示します。AIが「申請しました」と文章を返すだけでは、処理の完了とは扱いません。

業務手順から、必要な入力、確認する条件、条件に応じた分岐、承認者、完了の証拠を取り出します。「適宜」「必要に応じて」と書かれた箇所は、誰が何を見て判断しているかを現場で確認します。ここをAIの推測に任せると、曖昧さを速く実行するだけになります。

例外が多すぎる場合は、例外を無理に自動化しません。通常処理の対象条件を明示し、それ以外を確認待ちへ回します。現場が何を直せば再開できるかまで画面に出すことで、エラーを説明する手間も減らせます。

対象の仕事、現在使っているシステム、確認や差し戻しが発生する場面をお聞かせください。個人情報や機密資料の原本は送らず、まず業務の流れから整理します。

マニュアルの新版が登録されても、実行中の処理が自動で切り替わるとは限りません。変更された条件と対象業務を整理し、責任者が確認したルールだけを公開します。検索の参照資料と実行ルールの版が一致しているかも確認します。

改定前の案件、承認途中の案件、改定後に開始した案件をどう扱うかを決めます。古い回答を見た利用者が新しい画面を操作することもあるため、重要な変更は画面上で確認できるようにします。

たまに参照する知識や、専門家が個別判断する内容は、検索支援で十分な場合があります。頻繁に繰り返し、入力と完了条件が明確で、誤りを検証できる処理は、ワークフローへの実装を検討しやすくなります。

試行では、回答の正しさに加えて、登録成功、保留からの再開、取消、権限外操作の拒否を確認します。問い合わせの多い手順を一つ選び、検索だけで負担が消える部分と、操作を組み込む必要がある部分を切り分けます。

社内チャットボットを作り直す必要がありますか？

必ずしもありません。既存の検索機能を残し、よく使う業務だけ入力画面と承認処理を追加する方法があります。

手順が曖昧でも試作できますか？

画面の試作はできますが、未確定な条件を区別する必要があります。実行は保留し、現場の判断を確認してから対象を広げます。

業務例・比較表は当社が提案する設計上の例であり、特定のお客様の実績やお問い合わせ内容を紹介するものではありません。効果や適合性を保証するものではなく、実際の範囲は業務・データ・管理体制を確認して決めます。