TL;DR
- 自社プロダクト iknow.dev の案内役AI「iknow Navigator」を、製品の実コードから育てました。ナレッジ83件、壁打ち15問、ここまで2時間。
- でも本題はここから。実際、83件を作った4日後、機能をひとつ追加したら（★重要マーク）、その瞬間に書いたばかりのナレッジが古くなりました。プロダクトが変わり続ける限りナレッジは腐ります（docs drift）。この記事の肝は『速く作る』ではなく、コードを正本（Single Source of Truth）にして腐る速度に追いつく仕組みの方です。
- 作る時の鉄則はひとつ。「想像させず、実コードを根拠に書かせる」。LLMは非公開プロダクトを知らないが、コードという"正解"が手元にあるなら、当て推量ではなく裏取りされたナレッジにできます。
できたもの → iknow Navigator（ログイン不要、今すぐ触れます）
※ 筆者はナレッジライブラリー iknow.dev の開発に関わっています。本記事は開発者自身によるドッグフーディングの記録です。手放しの成功談ではなく、うまくいった所と、まだ人の手が必要な所 の両方を正直に書きます。
きっかけ：ドキュメントは、製品に追いつけない
先日、こちらの記事を読みました。
“育つ”ナレッジ基盤「LLM Wiki」とは？RAGとの違いをイラスト付きで整理してみた
Karpathy 氏が提唱する「LLM Wiki」——RAGのように毎回元資料を検索しに行くのではなく、LLMが編集・維持していく 生きたナレッジライブラリー を育てる、という考え方です。
読んでまっさきに思い浮かんだのが、自分たちの足元の課題でした。開発中のプロダクトは毎日のように変わるのに、ドキュメントとオンボーディングがそれに追いつかない。いわゆる docs drift です。READMEもFAQも、気づけば『昔の仕様』を平気で語り出す。書いた瞬間から少しずつ腐っていく感覚は、たぶん多くの人に覚えがあると思います。
なら、製品自身を説明する案内役を 生きたナレッジとして育て、製品の変化に同期させ続けたら どうなるか。本記事は、その小さな実験の記録です。
作るもの：製品の案内役AI「iknow Navigator」
育てるのは、iknow.dev というプロダクトの概要・用語・権限から、ナレッジの作成・運用、チャットでの質問、MCP連携（Cursor / Claude）、FAQ・トラブル対処までを、はじめての人に案内できる 公式の案内役 です。ログイン不要・匿名でも試せる、いわば製品の「顔」になります。
ちなみに iknow.dev では、専門家のドメイン知識（ナレッジ）を継承して答えるAIエージェントを アイノウ（iknow）と呼んでいます。iknow Navigator は、その仕組みを iknow.dev 自身の案内に向けたもの。要は 製品の「中のAIエージェント」 です。
ここで、ひとつ決定的な前提があります。
一般的な公開知識なら、LLMは事前学習で「知っている」。でも iknow.dev は非公開プロダクトなので、LLMは何も知らない。
だから「次に何を学ぶべきか提案して」と振っても、正しい製品仕様は返ってきません。返ってくるのは、それっぽい想像＝ハルシネーションです。ここで諦めると、よくある「だいたい合ってるけど、ところどころ嘘」のドキュメントができあがります。
ただ、今回は有利な条件がありました。自社プロダクトなので、最強の一次資料が手元にある——Gitリポジトリの実際のコードです。ルート定義・コントローラ・モデル ... これらが製品の「正解」そのもの。Cursor はこのリポジトリを MCP／エディタ経由でそのまま読めるので、想像で書かせるのではなく、実コードを根拠に書かせられる。しかも、書いたナレッジは後からいつでもコードと突き合わせて検証できます。
今回の主役が「実コードから作らせる」になるのは、この前提があるからです。逆に言えば、ここさえ押さえれば、特別なことはほとんどしていません。
使用ツールと全体構成
| 役割 | ツール |
|---|---|
| LLMエージェント（ナレッジの執筆・整理） | Cursor / Claude |
| ナレッジライブラリー（蓄積・検索・公開） | iknow.dev |
iknow.dev は、ナレッジを蓄積してキャラクター付きのエージェントとして公開できるサービスです。MCPに対応しているので、Cursor や Claude のようなLLMエージェントから、ナレッジを直接読み書きできます。LLM Wikiの3層アーキテクチャに当てはめると、今回はこうなりました。
| LLM Wikiの層 | 今回の構成 |
|---|---|
| Raw sources（一次資料） | Gitリポジトリの実コード・実際の画面／挙動 |
| The Wiki（編集された知識） | iknow.dev 上の iknow Navigator ナレッジ群 |
| The Schema（規約・ワークフロー） | LLMへの育成指示（後述のプロンプト） |
運用サイクルも、LLM Wikiでいう Ingest（取り込み）→ Query（質問）→ Lint（同期） をそのまま借りています。ただし今回の Lint は「内部矛盾の解消」だけでなく、「製品の実挙動との同期」 を含みます。ここが今回いちばんの学びでした。 詳しくは Step 3 で。
今回の前提
- 対象: 自社の非公開 Web プロダクト1つ（Laravel + Vue 構成）。社外秘なので「LLMが事前に知らない」典型例です。
- 一次資料: Gitリポジトリの実コード（ルート定義・コントローラ・モデル）と仕様書。
- 規模: 実コードから66件 ＋ AIの提案で17件 ＝ 計83ナレッジ（目次1枚を除く）。
- 所要: 初稿づくりは実働でおよそ2時間。仕上げ（Lint）はその後もずっと続きます。
- 前提スキル: 特になし。Cursor / Claude と MCP をつなげれば、あとは自然言語の指示だけです。
準備：iknow MCPをCursorに登録する
LLMにお任せするための準備として、iknow.dev のアカウント設定からCursorへインストールします。「Cursorへインストール」をクリックして、あとは指示通りに進むだけ。数分で終わります。
これで、LLMエージェントが iknow.dev のナレッジをMCP経由で読み書きできるようになりました。準備は以上です。
Step 1. 目次を作る
最初にやるのは、全体の地図＝目次づくりです。iknow.dev には「No.0 を目次（index.md）として運用する」という小さなルールを設けています。ここに前提・全体構成・読者別のクイックガイドを置くと、以降のページがこの地図にぶら下がっていきます。だから、いきなり個別ページを書き始めるより、まず骨格になる目次から作ります。
とはいえ、非公開プロダクトの構成をLLMは知りません。そこで Claude にリポジトリを読ませ、実在する画面・ルート・機能から逆算して目次を設計させました。実際に投げた指示はこれだけです。
iknow.devのナレッジを、目次に従って作成しようと思っています。
ソースコードを確認して、妥当な目次を作成して下さい。
出てきた骨子を人の目で直し、No.0（index.md）として登録します。トップに目次、その下に「画面とナレッジの逆引き」「役割別ガイド」「WebとMCPの使い分け」... と案内動線が枝分かれする地図ができました。目次が先にあると、このあとの執筆もLintも「どのページの話か」が一意に決まり、後でぶれません。
Step 2. ナレッジを作る
Step 1で作った目次（index.md）に従って、一次資料（ソースコード）を整理しながらナレッジを構築していきます。
iknow-navigatorの目次に従って、iknow.devのナレッジを作成したいです。
ソースコードを確認して、各項目のナレッジを作成して下さい。
このナレッジライブラリーはエンドユーザー向けです。
エンドユーザーが使える機能に関して正しくナレッジを整理して下さい。
関連ナレッジは本文に書くのではなく、関連ナレッジを指定して下さい。
ナレッジ構築は Cursor がおすすめです。ソースコードから 66件のナレッジ が作成されました。2時間で「製品の説明書」の初稿が一式そろう感覚です。
作成されたナレッジは iknow.dev でそのまま読めます。
もう少し育てたかったので、今度は提案させてみました。
iknow.devのサービスをナビゲーションするために
あった方が良いナレッジを提案してください。
Cursorの提案です。
「全部追加して」とお願いしたところ、新たに17件のナレッジが追加されました。最初の66件は実コードの“説明”、この17件は「初めての人がつまずく所」を埋める“気配り”。人間だと抜けがちな所を補ってくれた感覚です。これで計83件になりました。
変更履歴はすべて残ります。直しが間違っていたら、変更前に戻せます。AIに大胆に書かせても怖くないのは、この「いつでも戻せる」があるからでした。
Step 3. ナレッジを教育する（ここが本丸）
仕上げに、想定質問をぶつけて、ちゃんと良い回答が返ってくるかを確認します（壁打ち）。やり方はシンプルで、「初めての人が訊きそうな質問」を15問リスト化して順にぶつけるだけ。今回は 13問は文句なし、2問が“惜しい” という結果でした。「未ログインで何ができる？」「MCPでどう繋ぐ？」あたりは、根拠つきでしっかり返ってきます。
問題はその“惜しい2問”です。
内容は間違っていない。でも、言いたいことじゃない。こういう「事実は正しいのに、案内としては惜しい」が、いちばん厄介です。下はそのうちの1問を直したときの例。Cursorにお願いします。
アクセス権の設定が面倒な時は
アイノウ設定の構成の継承を使うといいことをナレッジに追加してください。
ここでも実コードが効きます。判断の「正解」がリポジトリにある以上、ナレッジをソースコードと突き合わせて裏取りできる。さらにコードが変わったら、その差分（変わったルート・仕様）を起点に、影響するナレッジだけを再点検すればいい。Cursor はソースコードを確認しながら、指示どおりにナレッジを更新してくれました。結果、想定どおりの回答が返るように。そうそう、それを案内してほしかった。
ここで正直に書いておきたいことがあります。Lintは2層あって、片方は自動化できても、もう片方は人の手が要ります。
- ①内部矛盾（ページ同士の食い違い・古い言い回し）→ これはLLMがかなり潰してくれる。
- ②実コード・実挙動とのズレ → これは「何が正解か」を知っている人が、コードと突き合わせて裏取りするしかない。内部のLintだけでは、外の世界（＝実装）とのズレは捕まえられないからです。
②の方が、実は厄介です。もう1問の“惜しい”が、ちょうど良い例でした。
Q. 1つのナレッジが80,000トークンを超えたらどうなりますか？
Navigator の回答は「トークン超過で分割されます」。一見もっともらしいのですが、実装を確認すると、これは 経路によって挙動が違う。インポート時は自動分割される一方で、ナレッジエディターやMCPからの保存では、超過エラーになって保存できない。「分割される」で一括りにするのは不正確でした。
このズレは、想像では絶対に気づけません。「分割される」も「エラーになる」も、どちらも自然な答えに見えるからです。正解はコードの中にしかない。 だから実装を確認し、ナレッジを「経路ごとの挙動」に直しました。①の言い回しの修正と違って、こちらは コードを開かないと正誤すら判定できない。これが、人の裏取りが要る②の正体です。
腐るのは、もっと速い — 83件は、4日で腐り始めた
83件のナレッジを育てたのが6/24。その4日後の6/28、ナレッジ一覧に「★重要マーク」機能を追加しました。特に大事なナレッジをワンクリックで目立たせる、それだけの小さな機能です。
その瞬間、書いたばかりの83件のうち、一覧画面の操作を説明するナレッジが腐り始めました。しかも厄介なのは、既存の「読み取り専用ロック」と役割が紛らわしいこと。★はただの目印で、編集・削除・MCPからの書き換えを一切制限しません。でもナレッジが古いままなら、Navigatorは「重要マークを付ければ保護される」と誤案内しかねない。些細なUI追加が、意味の取り違えを生む——これがdocs driftの怖さです。実装を確認して直した後のナレッジがこちらです。『読み取り専用との違い』の段は、実際に紛らわしかったからこそ生まれた記述です。
ちなみにこの記事の初稿は6/26に書き上がっていました。つまり「腐る」を看板に掲げたこの記事自体、公開前にすでに一度腐っています。
今回は追加した本人だから、その場で気づけました。でも普通のチームでは「機能を足した人」と「ドキュメントを書いた人」は別人です。このズレは誰にも報告されず、静かに放置される。だから属人的な「気づき」ではなく、コード差分を起点にナレッジへ同期する運用が要ります。
この修正の痕跡は Claude が書いた変更履歴に残っています（6/28 17:49）。履歴を見ると6/25にも修正が並んでいますが、これは作成時の裏取り漏れを実UIに合わせて直したもの。今回の★は、製品の側が変わってナレッジが置いていかれた——つまり正真正銘のdriftです。
LLM Wikiの記事は「Lintは定期的な健康チェック」と表現していましたが、自社プロダクトでは その基準値が“コード”という確かな形で手元にある のが強みでした。docs drift を倒すとは、つまり 「ソースコードを正本（Single Source of Truth）に、ナレッジを差分同期する運用を仕組みにする」 こと。Ingest（取り込み）は一度で終わっても、このLint（＝コードとの同期）は、プロダクトが生きているかぎり続きます。魔法ではなく、運用です。
完成：iknow Navigator
そうしてできたのが、製品の案内役 iknow Navigator です。iknow.dev では、育てたエージェントは URLやQRコードで共有 できます。
やってみての学び
| 学び | 詳細 |
|---|---|
| 非公開プロダクトは想像させない | LLMは製品を知らない。リポジトリの実コードを一次資料に渡し、未確認は未確認と書かせる |
| 自社プロダクトの強みは正解が手元にあること | 実コードを根拠に書かせ、コードと突き合わせて裏取りできるから、正確なナレッジにできる |
| Lintは2層ある | ①内部矛盾＝LLMで潰せる ②実挙動・コードとのズレ＝人の確認（裏取り）が要る |
| docs drift対策＝同期の仕組み化 | コードを正本に、変わった差分でナレッジを再点検する運用がないと、また古くなる |
派手な結論はありません。むしろ地味です。でも、「製品が変わったら、その差分でナレッジを直す」を運用として回せるようになったのが、今回いちばんの収穫でした。
あなたの現場でも：オンボーディングを“案内役を育てる”に置き換える
大事なのはツールよりも考え方です。お手元のLLM（Cursor / Claude など）と、説明したい対象のリポジトリさえあれば、「想像させず、一次資料を根拠に書かせて、変更差分で直し続ける」という型は同じように試せます。 ナレッジを貯めて公開・共有するところまで一気にやりたい場合の選択肢のひとつが、今回使った iknow.dev（エージェントを作って MCP 登録 → 一次資料を読ませて「○○についてまとめて」から）です。
そして、いちばん効くのは 自分のチームやプロダクトの“案内役” を育てることだと思います。社内Wikiが追いつかない、オンボーディングが毎回口頭、仕様が頭の中にしかない。そういう現場ほど、製品に同期し続ける案内役AIの効き目が大きいはずです。RAGで倉庫に放り込むより、図書館として編集して並べ、製品の更新に同期させる。
まだ始めたばかりの小さな実験なので、うまくいかない所も出てくると思います。それでも手応えはあったので、よければ自分のドメインでも試してみてください。感想や「うちはこうした」も、ぜひ聞かせてもらえると嬉しいです。