AIに知識を入れても「育たない」理由

「AIに自社の知識を覚えさせて、社員のように育てたい」——そう考える会社は多い。一方で、実際にそこへ踏み込んでいる人は、まだ一部だ。

その先行者たちは、かなり凝ったことをしている。Obsidianのようなノートアプリに AI が自動でメモを書き、別の AI がそれを読んで質問に答える——数年前は人が手で書いていた知識ベースを、いまは AI が書き、AI が読む。いわば「AI の第二の脳（second brain）」だ。

ところが、そこまでやっている人たちからも「知識が積み上がって、使うほど賢くなっている実感がない」という声が上がる。手をかけているのに、育たない。もっとも進んだ人がぶつかる壁なら、これから始める会社こそ先に知っておくべきだ。なぜ育たないのか——その前に、そもそも「AIに記憶を持たせる」とは何をすることなのかを、手短に整理しておきたい。

そもそも、AIは「記憶」していない

「AIは何でも覚えている」と思っている人は少なくない。実際は逆だ。AIが一度に読めるのは「コンテキストウィンドウ」と呼ばれる限られた範囲——いわば作業机の広さ——だけで、そこからこぼれた内容や、別のチャット、昨日のやり取りは、基本的に覚えていない。素のAIは、毎回ほとんど白紙から始まる。

だから、自社の知識をAIに扱わせるには、外から持たせる必要がある。方法は大きく二つ。一つは、社内文書を外の棚に置いておき、質問のたびに関連する箇所を探して机に載せるやり方だ。これがRAG（検索して持ち込む仕組み）。AI自身が覚えているのではなく、その場で外部資料を参照している、と考えるとわかりやすい。

もう一つが、やり取りや判断そのものを貯めて次に活かす「エージェントメモリ（AIの長期記憶）」だ。この二つは対立するものではなく、重ねて使える。ここまでが「AIに記憶を持たせる」の基本形になる。

ところが——冒頭の先行者のように外から知識を持たせても、育たない。多くの仕組みが「ためる」だけで「まとめ直して」いないからだ。

「ためる」と「まとめ直す」は別のこと

情報を貯めて、必要なときに検索できるようにする。これは倉庫だ。検索は速いが、中身は入れたときのまま増えていくだけで、そこから新しい理解は生まれない。さきほどのRAGは、この倉庫から関連するものを探して持ち込む仕組みにあたる。便利だが、倉庫の中身そのものは育たない。

一方、書き込むたびに要点を抜き出して束ね、重複や矛盾をならし、古くなった事実を差し替え、要らないものは忘れる——この作業を「まとめ直す」（英語では consolidation＝統合）と呼ぶ。まとめ直す仕組みがあると、中身は使うほど整理され、上位の教訓が立ち上がり、育つ。つまり、倉庫と記憶を分けるのは、思い出すときの検索ではなく、書き込むときにまとめ直すかどうかだ。

分かりやすい失敗例がある。データベースを MySQL に移行したのに、AI がいつまでも「御社は Postgres をお使いですね」と答え続ける。これは多くの場合、検索の精度だけの問題ではない。新しい事実で古い事実を上書きする「まとめ直し」がなければ、検索をどれだけ磨いても古い答えが残り続ける。倉庫は、古い箱をいつまでも棚に残す。

AI が書いても、まとめ直さなければ倉庫のまま

ここで冒頭の Obsidian に戻る。2026 年、ノートを書くのは人とは限らない。AI が vault にメモを書き、AI がそれを読む実践が増えた（研究者アンドレイ・カルパシー氏が 2026 年春に示した「LLM wiki」というワークフローがその代表だ。製品でも正式な標準でもなく、進め方の型だ）。

だが、書き手が人から AI に変わっても、それだけでは記憶にならない。ファイル形式が Markdown でも、書いているのが AI でも、まとめ直す仕組みがなければ、それは「AI が書いた倉庫」にすぎない。逆に、倉庫にまとめ直しの仕組みを足せば、それは記憶になる。記憶かどうかを分けるのは、ファイル形式でも、人が書くか AI が書くかでもない。書き込むたびにまとめ直すかどうか——そこが効く。（正確には、古い情報の扱いや「誰の記憶か」の切り分けなど区別の軸はほかにもあるが、経営がまず確かめるべきはこの一点だ。）

ただし、入れれば育つわけではない

念のため付け加えると、「まとめ直す記憶」は万能ではない。「メモリ」をうたう仕組みの一部は、実際には会話履歴を検索しているだけだ、という批判も（提供側・研究者の双方から）ある。まとめ直しにも難所がある——雑に要約すると大事な細部が落ちるし、「何を忘れさせるか」の設計は簡単ではない。

だからこそ、経営として見るべきは製品の名前ではない。「この仕組みは、書き込むたびにまとめ直しているか」——それを問えるかどうかだ。

経営者が確かめる、一つの問い

技術の細部は現場に任せてよい。経営が握るべきは、もっと手前の設計にある。

• どの情報を、誰が参照できる形で、どこに置くか（データ構造と権限の設計）
• AI の判断・失敗・訂正を、次に活かす形で残しているか（運用のループ）

この二つが決まっていれば、モデルが新しくなっても土台は乗り換えるだけで済む。決まっていなければ、賢い AI を入れるたびにゼロからやり直しになる。

NAL 自身の使い方

私たち自身も、この考え方で自社の開発を回している。まとめ直す「記憶」そのものは agent memory（Hindsight）が担い、その中身を人が眺めて判断するための画面は、Hindsight 用に自前で作ったダッシュボードだ。機械が経験をまとめ直し、人はそれを一覧・検索して意思決定する。倉庫と記憶、AI と人の役割を混ぜないことが、育つ仕組みの条件だと考えている。

なお、本稿で軸にした「まとめ直し（consolidation）」を記憶の要とする見方は、オープンソースの agent memory「Hindsight」を公開する Vectorize 社が強く打ち出している枠組みでもある。記憶を分ける軸はほかにもあり、当事者の主張を含む点は断っておく。

自社の知識を、ためるだけでなく育つ形にしたい——そう考えたら、まず現状の棚卸しから一緒に始められます。お問い合わせは こちら から。