ポーラ・オルビスHDが内製した社内マニュアル検索AI、RAGで精度を検証

同社の総合企画室でグループのDXを進めるチームが向き合っていたのは、社内で参照する機会の多いマニュアルやドキュメントの検索性の低さでした。とりわけポーラ化成工業の包装設計部門では、ISOの標準規格から製造ライン向けのルールまで参照すべき文書が数多くあり、まだ業務に慣れていない新入社員や中途入社の社員が「どのマニュアルのどの部分を参考にすればいいのか分からない」という状態に置かれていました。

ここで見落としたくないのは、文書そのものは適切に作成・更新されていたという点です。困りごとの本質は、情報が不足していたことでも整備が滞っていたことでもなく、必要な一節にたどり着く経路が個人の記憶と経験に握られていたことだったのではないでしょうか。経験の浅い人ほど、探すための手がかりになる用語自体を持っていません。検索性の低さという言葉の下にあったのは、この非対称だと編集部は見ています。

開発の座組みを「委託」ではなく「伴走」に置いた選び方が、この取り組みの土台になっています。社内にAWSの知見を持つ従業員はいてもAzureの知見は少ないという現状を踏まえたうえで、環境一式を発注するのではなく、自分たちで手を動かせるよう助けるアドバイザリー型のパートナーを探しました。支援側は相談をそのまま受け入れるのではなく、リスクがある場合は説明したうえで止め、代案をメリット・デメリットとともに提示する形で関与しています。開発の途中でMicrosoft TeamsだけでなくSlackとの連携を足したときも、セキュリティ面を考慮した検討を挟んで対応が進みました。

精度を押し上げたのは、回答生成を一つの大きなタスクとして処理せず、細かい単位に分割した設計です。質問から回答までを一息に任せてしまうと、どこで判断を誤ったのかが見えないまま出力だけが返ってきます。工程を刻んでおけば、検索と生成のどちらに問題があるのかを切り分けながら手を入れられる。あわせて回答には必ず参照元の資料URLを添える作りとし、利用者が原典に当たって確かめられる状態を保っています。

検証の場に包装設計部門を選んだ判断も見逃せません。ここは参照文書が多く経験の浅い従業員が最も困っていた領域であると同時に、文書が適切に作成・更新されていた領域でもありました。RAG（社内の文書を検索してAIの回答に活用する仕組み）は元になる文書の状態をそのまま結果に映すため、整った文書が揃う場所を最初の検証先に据えたことは、手法の実力を正しく測るうえで理にかなった置き方だったと考えられます。

包装設計部門でのPoCでは、ユーザーが質問した内容に対して正しいドキュメントを提示する確率が高いという結果が得られています。定量的な数値までは示されていないものの、この手応えを受けてポーラ化成工業では対象部門を段階的に広げる方針を取り、ホールディングス側もグループ全体での生成AI活用を進める予定です。検証段階の結果がそのまま次の展開の判断材料になっている点に、この取り組みの現在地が表れています。