107チームが同じ穴を塞いでいる：AI はあなたを忘れる

AI Radar・トレンド読解 #3 ｜ 問題領域：エージェントのセッション横断記憶データ期間：2026-W36 ｜ 独立チーム 107 組、同時期の公式対応は 1 件2026-09-05

月曜の朝。 新しい会話を開き、AI にリサーチ記事の草稿を頼む。作業に入る前に、 まずこれを一通り話す必要がある。

会社名は ProfitVision LAB。リサーチ記事は六章構成、産業マップで始まり結論で終える。語調は誇張しない。金融用語は台湾の言い方を使い、大陸側の語彙は使わない。それから——銘柄推奨はしない。法規に触れる。

ここまでおよそ五分。それから今日の本題に入る。

火曜の朝。 別の記事のために新しい会話を開く。

一字一句、もう一度言い直すことになる。

怠けているのでも、注意散漫なのでもない。本当に昨日を知らない。

長いあいだ、これは自分のワークフロー設計が悪いのだと思っていた。 プラグイン目録を数え終えるまでは。

「AI が忘れる」は欠点ではなく、構造である

はっきり言おう。

きわめて有能な業務委託の人を思い浮かべてほしい。立ち上がりが速く、成果もよく、何でもできる。 ただ一点だけ問題がある。毎朝出社するたびに、その日が初日なのだ。

昨日いっしょに出した結論を、彼は覚えていない。昨日直した誤りを、今日また繰り返す。 明日も、明後日も。不真面目なのではない。本当に昨日が存在しない。

技術的な理由はこうだ。モデルが一度に「見られる」文字数には上限がある。 この上限をコンテキストウィンドウ（context window）という。 会話が長くなれば前半は捨てられるか圧縮され、会話が終われば全部ゼロに戻る。

プラットフォーム側の答え：一冊の手引き

Anthropic の解法は `CLAUDE.md` というファイルだ。規約をそこに書いてプロジェクトに置くと、 新しい会話のたびに自動で読み込まれる。

月曜の五分は、ファイルの数行になる。

```
会社：ProfitVision LAB
リサーチ記事は六章構成
金融用語は台湾の言い方
銘柄推奨はしない
```

火曜にはもう言わなくてよい。これは実際に効く。自分でも使っている。

だが手引きでは解けないことがある

月曜、AI がこう書いた。「この銘柄は非常に有望であり、積極的な建玉を推奨する。」

指摘する。それは投資顧問法に触れる、事実の記述に留めて推奨はするな、と。直った。よろしい。

火曜、別の銘柄。「この銘柄は非常に有望であり、積極的な建玉を推奨する。」

なぜか。`CLAUDE.md` にその一行がないからだ。

あのファイルにあるのは、自分が事前に思いつき、かつ入力する気になったものだけである。
昨日の指摘は会話の中で起きた。
それをファイルへ書き戻す仕組みは、どこにも存在しない。

欠落はここにある。手引き ＝ 事前に想定し、手で書き下ろした規約記憶 ＝ 一緒に働く過程で相手が自分から積み上げたもの
>手引きは、昨日ふたりが言い合いをしたからといって自動更新されたりしない。

そして人と人の協働の価値は、その大半が後者から来る。
新しい同僚に千ページの手引きを渡す人はいない。三か月やってもらうのだ。

数えた結果

データは `anthropics/claude-plugins-community` の公開スナップショット
（コミット `a727be1`、2026-08-24）による。同じコミットを取れば同じ数字が出る。

この目録には 2,282 件のプラグインがある。記憶問題を解いているものを厳格な条件で抽出した。
セッションを跨ぐ永続記憶、文脈の継続、あるいは長期記憶システムを明示していることを要件とし、
`in-memory` のような技術用語に触れているだけのものはすべて除外した。

結果：

同じ問いなのに、やり方が似ていない

実在する三例を挙げる。距離感が見えるはずだ。

`memex` ——「ローカル AI 記憶システム。セッションを跨いで好み・判断・プロジェクト文脈を記憶する。」
端末上にローカルデータベースを立て、会話ごとの要点を保存し、次の開始時に関連分を引き出す。

`velixar` ——「認知記憶システム。永続記憶、ナレッジグラフ、アイデンティティ認識。」
一覧ではなく関係の網として持つ。この銘柄はどの業種に属し、その業種の risk は何で、
前回あなたは何を理由に見送ったか。検索は関係を辿って行う。

`claude-context-monitor` ——「コンテキスト枯渇の防止。リアルタイム追跡、意味的圧縮、carry-forward 記憶。」
長期記憶は狙わない。会話が溢れる直前のその瞬間に、それまでの内容を要約して次へ持ち越す。

一つはデータベース、一つは関係の網、一つはリアルタイム圧縮。
同じ問い、三つの方向。

120 件すべてを分類した結果（一件が二種類を兼ねることもある）：

共通の前提：エージェントにはセッションを跨ぐ記憶が要る、そして既存の仕組みでは足りない。
分岐点：記憶はファイルか、要約か、グラフか、データベースか——誰も答えを知らない。

なぜ「107 チーム」は「一つの人気ツール」より重いのか

ここがこの雷達の方法論の核であり、単独で述べる価値がある。

信号には二種類ある。

信号 A：あるツールが流行った。
信号 B：一年のうちに 107 組が同じものを作り始めた。

信号 A はマーケティングが上手いだけかもしれないし、時期に恵まれただけかもしれない。
単一事例のノイズは大きい。

信号 B は別種のものだ。 その 107 組は会議もせず、調整もしない。
大半は互いの存在すら知らない——それでも各自が同じ欠落を見つけ、各自が時間を投じると決めた。

産業分析にはこれを指す言い方がある。新しい問題領域が形成されつつある、というものだ。

数年前、十数社が同時に EV 充電スタンドを作り始めたのと同じである。
どの一社が生き残るかはわからない。だが「充電は本物の問題だ」ということは確定していた。

答えは置き換わる。問いは置き換わらない。

転回：公式目録には一件しかない

ここは調べる予定がなく、調べたら最も面白かった部分だ。

同じ組織がもう一軒出している。`claude-plugins-official`（コミット `85cce03`、2026-09-04）、
ベンダー審査済みの厳選 291 件。まったく同じ条件で抽出すると 2 件しか出ず、
そのうちプラットフォーム自身が記名しているのは 1 件だけだった。

`claude-md-management`（作者：Anthropic）「CLAUDE.md ファイルの保守と改善——品質監査、作業から得た知見の抽出、プロジェクト記憶の維持。」

何を解いているのかをよく見てほしい。手引きをより良く書くのを助けている。

AI に記憶を与えるのではなく、手引きを整頓するのを手伝っている。

1 対 120。 これは正誤の話ではない。同じ現象に対する定義が両者で違うという話だ。
そして定義が違えば、投じられる資源は二桁変わる。

読解

**プラットフォーム側は文書の問題と捉え、市場は構造の問題と捉えている。
この落差は永続しない。そしてどう収束するかが、あの 107 チームのうち何組が生き残るかを決める。**

可能性は二つ。

プラットフォーム側が正しい場合——大半の需要はよく保守された手引きで足りる。
すると 120 件の多くは過剰設計であり、静かに使われなくなる。

あの 107 組が正しい場合——記憶はエージェントに欠けた基盤層であり、
プラットフォームはいずれ自分で作る。作った日、
120 件のうち最も薄いものは一斉にゼロになる。

では何で見分けるのか。それが第二フィルターの問いである

モデル自身の能力を差し引いたら、何が残るか。

具体的な二例で回してみる。

ケース A：`CLAUDE.md` を自動整備するプラグイン。
モデルの能力を差し引くと何が残るか。ほぼ何も残らない。
中核は「モデルに会話を読ませ、モデルにファイルを書かせる」であり、どちらもモデルが元からできる。
プラグインはボタンを押しただけだ。プラットフォームが自前で出した日——
すでに `claude-md-management` がある——一夜でゼロになる。

ケース B：三か月分のあなたの作業文脈を、平文で蓄積したプラグイン。
差し引くと何が残るか。その三か月分の文脈が残る。 それはデータであって能力ではない。
モデルがどれだけ強くなっても、三か月前にあなたが何を理由にある判断を捨てたかは再現できない。
しかも平文なら、いつでも持ち出せる。ツールを替えてもプラットフォームを替えても、データは付いてくる。

**同じクラスタの中で、この二種類は長期価値が何桁も違う。
だが今日の目録では、どちらも見出し一行と説明一行、まったく同じ姿をしている。**

選別は自分の仕事だ。目録は代わりにやってくれない。

この読解が誤りうる箇所

1. 数えたのは宣言であって実装ではない。 120 という数字はプラグイン自身の記述から来ている。
   一つも導入しておらず、検証もしていない。したがってこの数字が言えるのは
   「何組がこれを問題だと考えているか」であって、
   「使える解が何件あるか」ではない。 この二つは大きく違う。
2. 107 アカウントは 107 の独立チームと同義ではない。 一人が二つ持つ場合も、
   一社が別々に投稿する場合も、こちらからは区別できない。実数はいくらか低いはずだ。
3. 公式目録は審査投稿制である。 記憶系が一件だけというのは、
   単にまだ誰も出していない、あるいは審査中というだけかもしれず、
   プラットフォームの姿勢を必ずしも表さない。推論として最も弱いのはここだ。
4. プラットフォームのロードマップは調べていない。 ネイティブ記憶がすでに開発中なら、
   本稿の時間軸は書き直しになる。

月曜の朝、あの五分に戻る

新しい会話のたびに背景を語り直す。これを半年以上続けながら、
自分のワークフロー設計が悪いのだとずっと思っていた。

数え終えて分かったのは、こうだ。**107 組が同じ場所で詰まっていて、
しかも自分で何かを書き始めるほど詰まっている。**

これであの五分が消えるわけではない。だが問題の性質が変わる——
「手引きをもっと完全に書くべきだ」から、「この層はそもそもまだ誰も建てていない」へ。

問題が自分の側にないと知ることは、解き方を知ることとは別種の収穫だ。
だが前者のほうが、無駄になりにくい。

あなたにとっての意味

記憶系プラグインを選ぶなら、この三つで絞る。順番は入れ替えないこと。

1. 記憶を何として保存するか。
   平文や Markdown ならいつでも持ち出せる。他社のクラウドに置くなら、
   値上げもするし、閉鎖もするものを借りていることになる。
2. モデル自身の能力を差し引いたら何が残るか。
   手引きを自動で書くだけなら、プラットフォームがやった時点で終わる。
   自分の文脈を蓄積するなら、その蓄積こそが資産である。
3. この件で実際に何かを失っているか。
   一日五分、ひと月で二時間。保守が要り、ネイティブ機能に吸収されうる依存と引き換えにする価値があるか。
   現時点での答えは、まだ無い。

いま採用するつもりはない。ただしこの領域には印を付けた——

**この 120 件の中から「プラットフォームのネイティブ機能に置き換えられた」実例が出てきたとき、
それこそが本当に読む価値のある一篇になる。**
そのとき書けるのは「107 組がこれをやっている」ではなく、
「X を試して Y を置き換えようとし、失敗した。理由はこれだ」——偽装のしようがない類のものだ。

出典

いずれも公開リポジトリであり、コミットがそのまま引用元となる。

• `anthropics/claude-plugins-community` @ `a727be1`（2026-08-24）
• `anthropics/claude-plugins-official` @ `85cce03`（2026-09-04）

*本記事は ProfitVision LAB の AI Radar と開発チームの共同制作による。
候補プール、フィルター判定、および完全な証拠チェーンは
ai-radar registry にて公開している。*