EXECUTIVE SUMMARY

エグゼクティブサマリー

ナレッジワーカーは1日あたり平均2.5時間、週にして8.8時間を情報検索に費やしています ¹。開発・CS組織でも「あのIssueどうなってたっけ？」は日常茶飯事です。GitHub・Jira・Backlog・Zendesk に散らばったチケットを横断的に見つけるのは簡単ではありません。日本の開発者を対象とした Findy 調査でも、ドキュメント管理への満足度はわずか17.5%にとどまっています ²。

このホワイトペーパーでは、データパイプラインによる Issue 収集、データウェアハウスへの蓄積、AI チャットによる自然言語検索という3レイヤーのアーキテクチャを扱います。自社 CRE チームでの実践事例をもとに、メタデータを整備していない状態でも実用的に機能すること、段階的に整備すれば精度がさらに向上することを示します。全社展開ではなく、1チーム・1リポジトリからのスモールスタートを出発点とした導入ガイドもあわせて紹介します。

CHAPTER 1

開発・CS組織を蝕む「検索できない」問題

情報はあるのに見つからない

開発チームは毎日 Issue を起票し、コメントを追記し、ラベルを付け替えています。CS チームも問い合わせチケットを作成し、対応履歴を残しています。情報は確実に蓄積されているのに、「半年前に似たような障害対応をしたはずだけど、どの Issue だったか思い出せない」「あの機能の仕様変更、どのチケットで議論したんだっけ？」という場面が繰り返されます。

調査データもこの課題の深刻さを裏付けています。組織の54%が5つ以上のプラットフォームで情報を分散管理しており、非構造化情報が「容易にアクセス可能」と回答した組織はわずか6%です ³。GitHub、Jira、Backlog、Zendesk、Slack、Confluence——ツールが増えるほど検索対象が広がり、正しい情報にたどり着くコストが上がっていきます。

「あの人に聞く」が常態化する

検索で見つからないとき、人は検索をやめて「知っていそうな人」に聞きます。Zendesk 調査では、30.5%の組織が「特定の個人や担当者に依存している業務がある」ことをナレッジ活用の最大課題として挙げています ⁴。

属人化は2つの問題を引き起こします。1つは、聞かれる側のエンジニアやシニアメンバーの工数が圧迫されること。もう1つは、その人が異動・退職したときにナレッジが組織から失われることです。Issue 自体はツール上に残っていても、「どの Issue を見ればよいか」という索引は個人の記憶に依存しています。担当者が抜ければ、索引ごと失われます。

非エンジニアにとっての壁

属人化の問題は、非エンジニアにとってさらに深刻です。CS チームのメンバーやプロダクトマネージャーが「この機能の過去の不具合報告を確認したい」と思っても、GitHub の Issue 検索でラベルやマイルストーンを正しく指定できるとは限りません。JQL の構文や Backlog のフィルター操作に慣れている必要もあります。結果として、エンジニアに「調べてください」と依頼する構造が固定化します。

Gartner の調査でも、検索機能の不備がエンタープライズ環境におけるセルフサービス試行の約40%を失敗に導いていると報告されています ⁵。情報が「ある」ことと「見つかる」ことの間には、想像以上の距離があります。

CHAPTER 2

収集→蓄積→AI検索の3レイヤーアーキテクチャ

「検索対象の整備品質」という原則

アーキテクチャの詳細に入る前に、1つ原則を押さえておきます。Claude Code の開発者 Boris Cherny 氏は、初期バージョンで RAG（ベクトル検索）とローカルベクトルDBを採用したものの、Agentic Search（glob/grep ベースの検索）のほうが優れていることがすぐにわかったと述べています。理由はシンプルさに加え、セキュリティ・プライバシー・データの鮮度・信頼性の面で RAG に課題があったからです ^6 7。

この知見から得られる示唆は、「検索される側のデータがどれだけ構造化・整理されているかが、AI 検索の精度を左右する」という点です。LLM エージェントがコードベースを検索するケースと、人間が社内ナレッジを検索するケースでは最適な検索手法は異なります。しかし、検索対象の整備品質が成果を決めるという原則は共通です。本ホワイトペーパーのアーキテクチャも、この原則をベースに設計しています。

3つのレイヤー

Issue 検索基盤は、以下の3レイヤーで構成します。

GitHub Copilot Chatとの棲み分け

「GitHub Copilot Chat でも Issue 検索はできるのでは？」という疑問は当然あるでしょう。Copilot Chat はリポジトリ内のコード検索や Issue 検索に優れた機能を持っています。個人の開発作業中に「このファイルに関連する Issue は？」と聞く用途には Copilot Chat が適しています。

一方、全社横断での検索や非エンジニアの利用には、異なるアプローチが必要です。

これは「どちらが優れているか」という比較ではありません。Copilot Chat は開発者の個人生産性を高めるツールとして有効であり、COMETA AI チャットは組織横断のナレッジ検索基盤として有効です。両者は併用する前提で設計するのが現実的でしょう。

エンタープライズ AI 検索の市場規模は2025年時点で68.3億 USD に達しており、2030年には111.5億 USD（CAGR 10.30%）に成長すると予測されています ⁸。データカタログ市場も CAGR 14.52%で成長しており、AI 対応データカタログが最も速い成長セグメントです ⁹。検索とカタログの融合は、業界全体のトレンドでもあります。