1. はじめに

こんにちは！IT戦略部の森嶋です。

先日、当社では 「DeNA × AI Day 2026」 が開催され、そこで「AI Workspace」プロジェクトについての発表をしました。

もちろん、AI に「解決策」を提示させること自体は簡単です。しかし、AI が描く理想論をすべて受け入れることは、リソースの限られた現場では現実的ではありません。

本ブログでは、AI の提案を鵜吞みにせず、何を信じて「採用しない判断」を下したのか、その意思決定プロセスと精度向上効果のあった「最後の一押し」として構築した仕組みを公開します。

また、AI をフル活用した更新提案機能とあえて AI を使わないシンプルな仕組みをどう組み合わせて、精度90%という大台を掴み取ったのか。その試行錯誤の道のりを紹介します。

特に以下のような方に届いてほしい内容です。

• RAG の精度が停滞し、次の一手に悩んでいる開発者
• AI の「もっともらしい提案」と、現場の「限られた工数」の板挟みになっているリーダー
• AI時代において、人間が持つべき「判断軸」の正体を知りたい方

AI時代だからこそ試される、私たちの「取捨選択」の記録をぜひご覧ください。

2. 「ナレッジ不足」を解剖する：2つの正体

AI の回答精度向上を阻む原因の70%は「ナレッジ不足」にありました。

この「不足」という言葉の裏側をさらに掘り下げると、精度が上がらない要因を2つに分けることができます。

①純粋な不足（ナレッジが存在しない）

ナレッジは日々、作成・更新されるべきですが、多忙なヘルプデスク現場でそれを実行し続けるには限界があります。ナレッジが一度作成されたとしても忙しさの中で放置され、情報が陳腐化していくのを止められずにいました。

結果としてこの 「情報の欠落」と「鮮度の低下」 が二重のボトルネックとなり、回答精度を向上させる足かせとなっていました。

②実質的な不足（ナレッジはあるのに AI が使えない）

ナレッジ自体は存在するものの、AI が正しく参照・活用できていない状態です。

具体的にはAI の学習対象ナレッジ内に貼られているリンクが切れている、もしくはAI にドキュメントの参照権限を付与していないことが原因で発生する不足です。

3. AI提案を取捨選択する：判断基準と決断

「ナレッジ不足」という課題を解消するにあたり、私たちは自社でナレッジ管理ツール 「Ledge（レッジ）」 を開発することにしました。

設計にあたってはAI（Gemini）を相談相手とし、必要な機能案を網羅的に洗い出しました。そして提示された機能は一見すると必要性を感じさせるものばかりでした。

しかし、実際に設計や開発を進めていく中で、「この機能は本当に必要なのか？」「工数に見合う費用対効果があるのか？」 という疑問を抱くようになりました。

そこで、私たちは改めてプロジェクトの「目的」と「目標」に立ち返り、機能を選別することにしました。

• 目的：ヘルプデスクの工数削減、およびユーザーの待ち時間短縮につながるか？
• 目標：AI の回答精度向上（IT領域の質問の回答率100%）に寄与するか？

「精度向上に直結しないもの」や「現場の工数を増やしてしまうもの」は、たとえ開発途中であっても中止を決断しました。 この判断基準による結果は以下の通りです。

4. 精度向上を実現する：「Ledge」の3つの機能

選別を経て実装した Ledge は、「ナレッジを拡充する」と「ナレッジの品質を維持する」という2つの役割に特化した構成にしました。

① 【ナレッジの拡充】AI による「更新提案機能」

2章で挙げた「純粋な不足（ナレッジが存在しない）」、「ドキュメントを更新する余裕がない」という課題を解消するための機能です。

「問い合わせのやりとり」という非構造化データをAI をフル活用して分析し、ナレッジの更新提案を実現しています。

1. 【仕組み】AI による「不足」の特定

AIヘルプデスク「Findout」が回答できなかった問い合わせを、AI が日次で分析します。

• 原因の切り分け： Findout の AI が「ナレッジ不足で答えられなかったもの」を抽出します。
• 提案の分岐： 関連する既存ナレッジがあれば「更新案」を、全く新しいトピックであれば「新規作成案」を、それぞれAI が判断します。
• 下書きの作成： 更新提案の場合、更新対象のナレッジをコピーし、そこに更新提案内容を下書きします。

2. 【アウトプット】レビュー用 Wiki への自動下書き

分析・更新提案結果は、Ledge の「更新提案レビュー用 Wiki」へ即座に出力されます。ここでは単に「情報が足りません」と通知するのではなく、AI が「どのナレッジに、何を追記すべきか」という具体的な下書きまでを自動生成します。

下記は実際に Confluence 上に作成された下書きに加筆された内容です。

3. 【設計思想】あえて「手動更新」を残した意図

ここでのポイントは、AI の提案をそのまま Wiki に自動反映させるのではなく、Ledge 上で人間が「判断」し、Wiki への反映は「手動」で行うというフローにあります。

Ledge による「意思決定」の可視化

更新提案レビュー用 Wiki に並ぶ大量の提案に対し、人間が Ledge 上で「承認（採用）」または「却下」を選択します。これにより、「どの提案を受け入れ、どれを見送ったか」という意思決定の履歴と、未着手の案件がどれくらい残っているかを一目で可視化できるようにしました。

なぜ Wiki への反映を自動化しなかったのか

理想を言えば「承認」ボタン一つで Wiki が書き換わるのが便利ですが、あえてそこは切り離し、人間が手動で Wiki を更新する運用にしています。理由は以下の2点です。

• 上書き事故の防止： 自動同期にしてしまうと、他の担当者が Wiki 上で修正していた内容を AI の提案で上書きしてしまうリスクがあります
• 「こだわり」の追求： AI の下書きをベースにしつつも、「この表現はこうしたい」「特定のユーザーの要望を汲み取りたい」といった細かな調整を人間が行うことで、ナレッジの品質を最終的に担保しています

下図は実際の更新提案の画面になります。

4. 【効果】最小工数でのナレッジ拡充と「即時反映」の維持

ヘルプデスク現場のナレッジ作成負荷が軽減された

担当者はゼロから文章を作る必要がなく、AI が生成した下書きを確認・修正して公開するだけで済みます。多忙な現場でも、運用の中で自然とナレッジが蓄積される仕組みを構築しました。

運用の「手詰まり」がなくなった

やるべきことが Ledge 上でリスト化・可視化されたことで、「何から手をつければいいか分からない」という状況が解消され、隙間時間でのメンテナンスが可能になりました。

「生きた情報」の即時反映が可能に

新システムの導入直後などは、ナレッジが不十分なために問い合わせが急増する期間が発生します。

日次で「問い合わせのやりとり」を分析し、下書きを自動生成するこの仕組みは、翌朝には解決策として公開され、混乱を最小限に抑えることが可能になりました。

② 【参照エラーの防止】リンク切れチェック

2章で挙げた「ナレッジはあるのに AI が使えない」状態を解消し、AI がすべてのナレッジを正しく参照できるようにするための機能です。

1. 【仕組み】システムによるリンク切れチェック

学習対象のナレッジ内に書かれているリンクを抽出し、API でリンク先の確認をすることで遷移先が存在するかを判別します。

このとき、AI の学習対象のナレッジ内に貼られているリンクが切れている、もしくはAI にドキュメントの参照権限を付与していない場合にエラーになります。

2. 【アウトプット】Ledge で一覧化

エラーが見つかった箇所は、Ledge 上の管理画面に「どのナレッジの、どのURL がアクセスできないのか」を一覧で表示します。

3. 【設計思想】あえて自動修正・削除はしない

リンクが切れた背景には「ページの刷新」や「ルールの廃止」があるかもしれません。単にリンクを消すのではなく、人間が「代わりの情報を載せるか、ページ自体を削除（アーカイブ）するか」を判断することで、ナレッジを正常な状態に保っています。

4. 【効果】手動チェックからの解放

数千件のナレッジを人間が手作業で確認するのは限界があります。システムが「修正が必要な箇所」だけを教えてくれるため、管理工数を最小限に抑えつつ、常に「生きたリンク」だけを維持できるようになりました。

③ 【メンテナンスの補完】鮮度チェック

「更新提案」は実際の問い合わせ履歴から作成されますが、それだけでは拾いきれない「長らく誰からも聞かれていないが、古くなっている情報」を整理するための機能です。

1. 【仕組み】1年以上更新されていないナレッジの抽出

AI の学習対象で最終更新から1年以上経過したナレッジをシステムが自動で抽出します。

更新が必要ない場合もあるため、その時はチェックのスキップも可能にする機能も実装しました。

下図は実際の鮮度チェックの画面になります。

2. 【アウトプット】「確認が必要なナレッジ」のリスト化

長期間メンテナンスされていないナレッジを Ledge 一覧で表示し、担当者に確認を促します。

3. 【設計思想】「情報の腐敗」を防ぎ、定期的な棚卸しを習慣化する

記憶に頼るのではなく、Ledge から「そろそろ確認時期ですよ」と通知することで、担当者が「更新・継続・アーカイブ（削除）」の判断を定期的に行うきっかけを作ります。

4. 【効果】「古い回答」によるトラブルの未然防止

この機能を導入したことで、ナレッジの信頼性はさらに強固なものになりました。

誤情報の提供リスクを低減

「古い手順で操作してエラーになった」といった、情報の陳腐化によるユーザーとのトラブルを未然に防げるようになりました。

ナレッジの「スリム化」を実現

不要になった古い情報を適切に廃棄（アーカイブ）する判断ができるようになり、ナレッジベースがノイズの少ない状態に保たれています。

5. 導入結果と成果：精度80%の壁を突破

Ledge の導入後、AIヘルプデスク「Findout」の回答精度と運用面で大きな変化が現れました。

① 回答精度：80%から90%への到達

停滞していた回答精度は、Ledge 導入後の約1ヶ月で90%を突破しました。特に精度向上の足かせとなっていた「ナレッジ不足」に直接アプローチしたことで、以下の成果が得られました。

ナレッジの網羅率向上

AI による「更新提案」により、実際の問い合わせに基づいた不足しているナレッジが日次で補填され、回答不能な領域が着実に減少しました。

正解率の安定

「リンク切れチェック」により、社内にある情報をAI が100%参照できる状態になったことで、参照エラーによる回答できなかった問い合わせもカバーできるようになりました。

情報の信頼性

「鮮度チェック」によって古い情報がアーカイブされた結果、AI が新旧の情報で迷うことがなくなり、回答の正確性が向上しました。

② 運用負荷：ナレッジ作成工数の大幅削減

「精度を上げるためにナレッジを書く」という現場の負担を最小限に抑えることができました。

「ゼロから書く」からの脱却

更新提案機能により、担当者はAI が作成した下書きを「確認・修正」するだけになりました。これにより、ナレッジ1件あたりの作成時間は従来の約半分以下に短縮されました。

メンテナンスのルーチン化

更新提案と鮮度チェック結果一覧を定期的に確認する運用が定着し、「何を直せばいいかわからない」という迷いがなくなりました。

③ 定性的な変化：現場メンバーの声

運用を担うIT戦略部のメンバーからも、以下のようなフィードバックがありました。

• ナレッジをゼロから作るのは大変でしたが、更新提案のおかげで、内容を確認して必要に応じた「色付け」をするだけで済むようになり、格段に楽になった
• リンク切れや鮮度チェックによる自動抽出により、探す手間なくナレッジの正確性を効率的に維持できている
• 「記憶」や「経験」に頼らず、チーム全員が等しくナレッジ整備に貢献できるようになったことで、更新のハードルが下がった

6. まとめ：AI時代に問われる人間の判断力

精度80%の壁を突破したのは、AI のチューニングではなく「ナレッジを整える仕組み」の構築でした。

今回再認識したのは、AI の提案をそのまま受け入れるのではなく、「現場の工数」と「精度への寄与度」を天秤にかけ、優先順位を見極める重要性です。

私たちは、AI が回答できなかった問い合わせの分析や現場の声、そして最新の技術動向をふまえ、今回紹介した3つの機能が必要であると確信し、逆に不要な機能は潔く削ぎ落としました。

結果として要所を絞った改善だけで、精度を上げることができました。「何をやらないか」を決めることが、最短距離で成果を出すための鍵でした。

7. 次なる挑戦：この知見を全社へ

今回のプロジェクトを通して、AIヘルプデスク「Findout」の回答精度は、一定の成果を得ることができました。また、「Ledge」が業務フローに定着したことで、今後もドキュメントが拡充されるにつれて、精度が継続的に向上していく体制が整っています。

今後は保守フェーズとして、月次の実データを基に回答精度の推移を継続的に監視し、品質の維持とさらなる改善を図っていきます。

そして他部署への問い合わせ対応の効率化は、バックオフィス部門に限らず全社共通の課題です。実際に社内の各部署から、今回の仕組みを自部署でも活用したいという要望を多数いただいています。

今後は、この運用モデルを全社へ展開するために、システムのマルチテナント化を進めていきます。 特定の部署に限定せず、社内全体でナレッジの管理・活用を効率化できるよう、事例の横展開を加速させていく計画です。

これからも AI と伴走しながら「自社にとっての最善」を問い続け、改善を積み重ねていきます。

最後までお読みいただき、ありがとうございました。