CyberAgentがKnowledge Catalog活用でAIエージェント向け知識基盤を設計

編集: グリットアーツ編集部

公開日：2026年11月7日

3行解説

ニュースの概要

CyberAgent Developers Blogは2026年11月6日、AI POSチームのミッション型インターン体験記を公開しました。記事では、2026年8月から約1.5カ月参加した学生が、AI POSのエージェントに社内知識や顧客企業の社内知識を参照させる基盤を考案・構築した経緯を説明しています。対象は小売向け分析ツールで、営業やコンサルタントがチャットで質問すると、AIエージェントがSQLを組み立てて購買データを集計する仕組みです。

今回の取り組みでは、知識をエンジニアでなくても書けること、書き方をそろえること、顧客企業ごとに分離できること、検索して引けることの4点を要件に置きました。そのうえで、知識の形式にOpen Knowledge Format（OKF）、保存先にGoogle CloudのKnowledge Catalogを選び、権限管理にはIAMを使う方針を示しています。

何が新しいのか

新しい点は、AIエージェントの回答精度を上げるために、プロンプトを都度書き換えるのではなく、知識そのものを管理する基盤に寄せたことです。記事では、知識を「特定の状況で使うべき解釈や判断を再利用できる形で言語化したもの」と定義し、事実データとは分けて扱っています。これにより、売上などの数値ではなく、指標の定義や解釈ルールを継続的に更新しやすくなります。

また、OKFはMarkdownベースで、出典、確認者、有効期限、下書きか確定かといった信頼性の情報を持てます。Knowledge Catalogにカスタムエントリとして登録し、BigQueryのテーブル情報と同じ場所で検索できる点も特徴です。つまり、「どのデータを見るか」と「どう解釈するか」を同じ導線で扱えるようにした設計です。

グリットアーツ編集部の分析

この事例で重要なのは、AIエージェントの性能をモデル単体ではなく、知識の更新運用で支える設計にしている点です。記事では、これまでSlackなどで共有された知見をエンジニアがプロンプトへ反映していたとあり、更新のたびに手作業が発生していました。Knowledge CatalogとOKFを使うことで、知識の追加・修正を文書管理に近い形へ寄せられる可能性があります。

一方で、導入の難しさは権限設計にあります。小売の知識とプロダクト全体の知識を分け、さらに顧客企業ごとに混ぜない前提なので、マルチテナント運用ではアクセス制御の設計が重要です。知識を増やすほど便利になる反面、レビューや承認の流れが曖昧だと、誤った定義がそのままAIの回答に反映されるリスクもあります。

日本の現場で考えると

日本の企業でこの方式を使うなら、向いているのは、顧客別・部門別に解釈ルールが異なる業務です。たとえば小売、営業支援、コールセンターのように、同じデータでも「何を正解とするか」が変わる現場では効果が出やすいでしょう。逆に、全社で同じ定義を一斉に使いたいだけなら、顧客別分離やIAM設計が過剰になる可能性があります。

また、AIエージェントが直接DBに触れず、Cloud Run上のワーカー経由で操作する前提は、監査や障害切り分けには有利です。ただし、実運用ではワーカーの失敗時にどこまで再実行できるか、検索した知識が古い場合にどう止めるかを決めておく必要があります。日本の現場では、権限と更新責任を曖昧にしたまま広げると運用が崩れやすい点に注意が必要です。

導入・検討時に確認したいこと

• 知識の更新者、承認者、公開条件をどう分けるか。
• 顧客企業ごとの分離を、どの粒度の権限で実現するか。
• Knowledge Catalogでの検索遅延や反映遅延が業務に影響しないか。
• Cloud Run上のワーカー障害時に、監査ログと切り分けができるか。
• OKFの知識を既存の文書管理やデータ基盤とどう連携するか。

現時点で分かっていないこと

記事からは、実際の検索性能、更新反映の所要時間、運用時の権限設定の細かい粒度は分かりません。また、どの程度の規模まで知識を増やせるか、既存の社内文書基盤とどこまで統合できるかも未記載です。

AIエージェントに渡す知識をどう管理するかは、運用設計と権限設計が要になります。既存のデータ基盤や社内文書の扱いを見直す際は、分離・検索・監査の観点で整理しておくと判断しやすくなります。

出典: CyberAgent Developers Blog