AIエージェントに敢えて失敗させて“ドキュメントの抜け穴”を探る「DDC」とは：“未文書化知識”を発見する需要駆動型コンテキスト

IKEAのプリンシパルエンジニア、ラジ・ナバコティ氏は、AIエージェントが十分機能しない原因はモデル性能ではなく「ドキュメントの未整備」にあると指摘する。その対策として同氏が紹介するのが、「DDC」だ。

[TechTargetジャパン]

　「社内にAIエージェントを導入したのに、思ったほど業務が進まない」「RAG（検索拡張生成）やMCP（Model Context Protocol）を整備したのに、結局は人間が情報を補足している」――。こうした課題を抱える企業は少なくないようだ。

　こうした中、家具大手IKEAのプリンシパルエンジニアであるラジ・ナバコティ氏も、せっかく導入したAIエージェントが企業内で十分に機能しない事態に見舞われたという。

　ナバコティ氏はその原因を、「モデル性能ではなく“組織の知識”にある」と指摘する。そこで、AIエージェントが失敗した箇所から、逆に「何が文書化されていないのか」を発見し、知識ベースを段階的に改善していく「需要駆動型コンテキスト」（Demand-Driven Context：DDC）という手法を提案している。

DDCとは？　具体的に何をすれば？

併せて読みたいお薦め記事

AIエージェントの構築に関する記事

• 1200万円のSaaS導入を回避　スギ薬局「運用費10万円」のAIエージェント構築術
• AI予算の6割は「データの整備」に消える

　ナバコティ氏によれば、生成AIやAIエージェントは、コードの生成や推論、プルリクエストのレビューなどには優れている。しかし、企業固有の業務ルールやシステム構成、運用手順といった“組織知識”にはそれほど強くないという。

　「AIは非常に優秀だが、企業内の制度や運用、ドメイン知識を知らない」（ナバコティ氏）。特に大企業では、ConfluenceやSharePoint、GitHub、Slackなどに情報が分散している上、その多くが古い、重複している、あるいは「tribal knowledge」（組織やグループ内でしか共有されていない、暗黙的・不文律の知識）として個人の頭の中にしか存在しないという問題があると指摘する。

　こうした状態で大量のMCPサーバやRAGを構築しても、AIエージェントからは不確実で信頼性の低い出力しか得られないという。その結果、「AIに仕事を任せるはずが、人間が情報を補完する“データ入力係”になってしまう」と同氏は振り返る。

“失敗”から知識を育てるという発想

　DDCの特徴は、最初から全知識をAIへ投入するのではなく、「AIエージェントが失敗したとき」に不足している情報を発見し、そこから知識を育てていく点にある。

　同氏は、新入社員のオンボーディングを例に挙げる。企業は新人へ全知識を教え込むのではなく、最小限の説明後にタスクを与え、必要に応じて質問させながら知識を増やしていく。同手法もこれに近い考え方だという。

　例えば、システム障害やトラブルの履歴など、過去のインシデント対応にひも付く情報をAIエージェントに与え、インシデントの原因や対処法を考えさせる。一方AIエージェントは、古い情報を基にインシデントを分析するため、情報不足でお手上げ状態になる。そこで、AIエージェントにとって「不足している情報」を吐き出させる。不足している情報を人間が補足すると、AIエージェントはその知識を整理・保存し、次回以降に再利用できるようになる。

　DDCは「テスト駆動開発」（TDD）に類似していると同氏は説明する。TDDでは、失敗することが確実なテストコードを作り、失敗を引き起こした不足部分を把握し、必要なコードを追加していく。

“どこが未文書化なのか”を可視化

　DDCの大きな特徴は、「何が不足しているか」を可視化できる点だ。

　AIエージェントは、インシデントやチケットを処理する中で、「このシステム名の説明がない」「このAPIの仕様が古い」「この運用ルールが未記載」といった“知識ギャップ”を洗い出す。

　さらに同氏は、この仕組みを自動化した「Context Gap Scanner」の構想も紹介している。これは、過去のインシデントの履歴やチケットなどをAIエージェントへ一括投入し、「どのドキュメントが古いのか」「どの知識が欠落しているのか」「どの情報がtribal knowledge化しているのか」を自動で分析するものだ。

　その結果、「通知サービスに関する説明が存在しない」「1年以上更新されていないドキュメントがある」といった問題を自動で検出する。さらに、複数のインシデントで繰り返し不足が指摘された知識を、「critical」「high」など優先度付きで整理し、ドキュメント改善用のカンバンボードまで自動生成するという。

　ナバコティ氏によると、14件のインシデントを繰り返し処理させた結果、AIエージェントの“知識信頼度”が1.5（ほぼ信用できない）から4.4（ほぼ完璧）まで向上した事例があるという。AIエージェントが不足している情報を発見し、それを蓄積・再利用することで、徐々に半自律的に動作できるようになった。

AI時代は「知識の地図」も必要に？

　ナバコティ氏は、AIへ大量の文書を渡すだけでは不十分だとも指摘する。重要なのは、「どの業務プロセスが、どのシステムやAPIと結び付いているのか」という“構造マップ”をAIエージェントへ与えることだ。

　同氏はこれを「メタモデル」と呼ぶ。例えば、「ビジネスプロセス」「システム」「API」「専門用語」の関係性を整理した“地図”を用意することで、AIエージェントは必要な文書へ迷わずアクセスできるようになるという。

　「現在のAIは、大量のファイルを渡されても、どれを読むべきか分からない。メタモデルは、知識ベースを移動するための地図になる」（ナバコティ氏）

情シスは「知識管理」を再設計する必要がある？

　ナバコティ氏は、「AIエージェント時代には、企業が自社の知識基盤を自分で整備しなければならない」と強調する。LLMベンダーはモデル性能を改善し、RAGベンダーは検索性能を改善する。しかし、「企業固有の知識」を整備するのは企業自身しかいないという考えだ。

　また、知識管理にはGitHubを利用する選択肢があると説明する。複数のAIエージェントやチームが知識を更新する場合、プルリクエストのレビューや変更履歴管理が必要になるためだ。同氏は、「ドキュメントへ直接書き込むより、まずGitHubで知識を管理した方がよい」と語る。

　背景には、AIエージェント同士や複数チームが同時に知識を更新した際、競合解決や査読プロセスを効率的に実施したいという狙いがある。GitHubを“知識管理基盤”として使い、その後Confluenceなどへ展開する構成を推奨している。

　しかし、課題もある。同氏自身、「手動運用は非常に疲れる」「小規模で文書管理が整理されている組織では効果が薄い可能性がある」と認めている。

　特に問題なのは、AIエージェントへリアルタイムで質問対応を続ける運用だ。エンジニアが“AIからの質問攻め”になり、逆に負荷が増える可能性がある。そこで同氏は、日常運用中ではなく、「RAGへ投入する前段階」にContext Gap Scannerを実行し、チーム単位など小規模スコープで一気に文書をクリーンアップする運用を推奨している。

　さらに、コードとドキュメントの内容が食い違う場合、「どちらを正とするか」の優先順位付けも課題だという。同氏は、GitHub上のコードを優先し、ドキュメント側の説明は補足情報として扱うルールを検討していると説明した。

　それでも同氏は、「AIエージェントが普及するほど、企業内知識の品質がボトルネックになる」と見ている。情シスにとっては、単にAIツールを導入するだけではなく、「組織知識をどう整備し、どうAIへ渡すか」が、新たな重要業務になる可能性がある。

本稿は、AI Engineerが2026年5月5日に公開した動画「Demand-Driven Context: A Methodology for Coherent Knowledge Bases Through Agent Failure」を基に作成しました。