1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Claude Codeの本当の敵は性能不足じゃない。毎回「思い出し直し」が発生することだ

1
Posted at

アップロード容量が月の制限(100MB)を超えました。設定 -> アップロードしたファイル から、当月にアップロードされた不要なファイルの削除を行ってください。

正直、最初はただの便利プラグイン紹介かなと思った。

でも読み返して考えが変わった。これ、Claude Codeの弱点を直しているというより、AIコーディングのボトルネックがどこにあるかを可視化した話なんですよね。Xでは「48時間で46,000スター」と紹介され、GitHub上では4月11日時点で47k台まで伸びている。熱狂の理由は、単に星の数が多いからじゃない。みんな同じ痛みを抱えていたからだと思う。 ## みんな何に困っていたのか

Claude Codeって、コードを書く力そのものはかなり高いです。

でも実務でしんどいのは、昨日の続きに入るたびに「このリポジトリはこういう構成で、このファイルはこういう役割で、前回ここまで直して…」と文脈を再構築するコストが毎回発生することなんです。

これ、引っ越しのたびに段ボールへ荷物を詰め直す感じに近いです。

家の中身は同じなのに、毎回どこに何があるか説明していたら、作業そのものより準備で疲れる。AIコーディングでも同じで、モデルの賢さ以前に、毎回の思い出し直しがトークンと集中力を削っていく。ここが痛かった。これはClaude Codeが公式に持つ auto memory だけでは埋まりきらない領域だったんじゃないかと、個人的には思う。 > モデルが賢いかどうかより、毎回どれだけ思い出し直させるかの方が、体感の速さを決める。


claude-memがやっていることは、意外と地味で、でも効く

claude-memは、 Codeのプラグインとして入り、作業中の観測情報を保持し、次のセッションで必要そうな文脈を返してくれる仕組みです。READMEでは、セッション横断の継続性を保つこと、npx claude-mem install で導入できること、そして検索→タイムライン→詳細取得という段階的な読み出しで、必要な情報だけを後から展開する構成が説明されています。検索結果だけを先に見るので、詳細を全部読むよりトークンを節約しやすい。README上ではその流れで約10倍の節約設計が示されています。 GitHub

ここで大事なのは、「全部を毎回押し込む」のではなく、まず索引だけ見ることです。

本棚を丸ごと机に積むんじゃなくて、まず目録を見て、必要な本だけ引っ張る。claude-memの本質はこれで、記憶を増やしたというより、記憶の取り出し方をちゃんと設計したところにある。だから刺さったんだと思います。 GitHub


なぜ今これがここまで響いたのか

理由は単純で、 Code側の拡張基盤が整ってきたからです。公式ドキュメントでも、プラグインは skills・hooks・subagents・MCP servers を束ねる配布単位だと説明されています。hooks はClaude Codeのライフサイクルに応じて自動実行できる。つまり半年前より今の方が、こういう「記憶レイヤー」を後付けしやすい土台がある。 もう一つは、ユーザー側の使い方が変わったことです。

お試しの一問一答じゃなく、複数ファイルをまたぐ修正、長期のリファクタリング、数日単位の機能追加にClaude Codeを入れ始めると、痛いのは推論の質そのものより継続性の断絶なんですよね。だから今この話が伸びる。半年前なら「便利そう」で終わっていたものが、今は「それ欲しかった」に変わった。 > AIコーディングの次の競争軸は、モデル性能そのものより「記憶をどう残し、どう再利用するか」かもしれない。


ただし、魔法の杖ではない

ここは冷静に見た方がいいです。

まずClaude Code自体にも auto memory はあります。なので claude-mem は「ゼロから記憶を発明した」のではなく、その上に検索性と可搬性を足していると見る方が正確です。 それと、ローカルで動くWeb Viewerが localhost:37777 に立ち、保存対象から外したい内容には <private> タグを使う設計になっています。ライセンスは AGPL-3.0 です。個人開発だとかなり使いやすい一方で、企業導入では「何を保存するのか」「派生物の扱いはどうか」を雑にすると後で面倒になりやすい。実際、GitHubのissueでは「トークンを使いすぎる」という報告も出ていて、設定や使い方で体感差が出る余地もあります。 GitHub+3GitHub+3

余談だけど、この流れって「AIに全部任せる」方向じゃなくて、AIの記憶だけをインフラとして切り出す方向なんですよね。

ここが地味に大きい。モデルを乗り換えても、記憶層は残したい。実際、関連する議論や周辺ツールを見ると、 Code専用の記憶から、複数エージェントで共有する共通バックエンドへ広げたいという声や、Supermemory や OpenMemory のように別クライアントでも使える記憶基盤が伸びています。 GitHub+3GitHub+3

自分ならどう使うか

個人的には、いきなり会社の大きな案件に入れるより、まずは個人リポジトリで1週間だけ試すのがいいと思う。

新規機能を1つ決めて、導入前と導入後で「毎回の説明量」「セッション再開の速さ」「トークン消費の体感」を比べてみる。そこではじめて、自分の開発フローに効くかが見えてきます。

そのうえで、保存された内容を自分で眺める。

ここが大事です。AIメモリは便利さと引き換えに、どこまで記録するかの設計責任をこちらに返してくる。だから最初にやるべきことは、インストールより観察かもしれない。便利さに飛びつくより、「何が記憶されると自分は楽になるのか」を知る方が、長く効く。 3年後に振り返ると、たぶんこの話は「Claude Code用の人気ツールが出た」では終わらないはずです。

「あの頃から、AIエージェントはモデル単体で戦うんじゃなくて、記憶レイヤー込みで使いこなすものになっていったよね」と振り返る話になる。僕はたぶん、そっちの方が本題だと思っています。

1
1
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?