Claude Codeは「検索の革命」を証明した。Plan Stackが担うのは「記憶の革命」だ。

Claude CodeやCursorを真剣に使い込んでいる人なら、きっとこんな瞬間に心当たりがあるはずです。

「あれ……これ、昨日も解決しなかったっけ？」

同じファイルを何度もgrepする。同じ制約を何度も再発見する。同じ設計判断の理由を、何度もモデルに説明し直す。

Claudeは「見つけること」には長けていますが、「なぜそうなっているのか」という理由は忘れてしまいます。なぜなら、私たちがそれを許しているからです。

この記事では、その問題について掘り下げます。

---

課題：AI開発は、毎回「ゼロからのスタート」に感じられる

エージェント型のコーディングツールは、最初は魔法のように感じられます。「リポジトリを検索して」「関連コードを見つけて」「これがどう動くか説明して」

しかし、しばらくするとあるパターンが見えてきます。同じ調査が何度も繰り返される。同じ推論が何度も再計算される。セッションを跨ぐと、コンテキスト（文脈）が消滅する。

これはUXのバグではなく、設計上の選択です。

---

RAGからエージェント型検索へ

Claude Code以前の主流はRAG（検索拡張生成）でした。ドキュメントを事前にインデックス化し、すべてをベクトル化（埋め込み）し、ベクトル検索で情報を取得する。

そこに現れたのがエージェント型検索です。事前のインデックス化は不要。モデルが実行時に探索する。ベクトルの代わりに grep、glob、read を使う。

Claude Codeはこの手法に全振りしました。

開発者のBoris Cherny氏は、2025年5月のLatent Spaceインタビューでこう述べています。

「初期のClaude CodeはRAGとローカルのベクトルDBを使っていましたが、エージェント型検索の方が全般的にうまくいくことがすぐに分かりました。また、セキュリティ、プライバシー、情報の鮮度、信頼性の面でも問題が少なくてシンプルです。」

Anthropic自身が、自社の機密性の高いコードをサードパーティのインデックスにアップロードすることを信頼しなかったという点も示唆的です。

一方で、ベクトルDBのMilvusは「grepだけの検索には反対」という反論を公開しています。grepはトークンを消費しすぎるし、意味論的な理解に欠けるという主張です。トークン消費を40%以上削減できるとしています。

彼らは間違ってはいないのですが、最適化の対象が違うだけの話です。

---

なぜClaude Codeの「シンプルさ」が勝ったのか

Claude Codeは、ベクトルデータベース、キャッシュ、永続的なメモリシステムを意図的に避けました。代わりに、モデル自身の生の能力、（将来的な）トークンの低価格化、シンプルで透明性の高いツールに賭けたのです。

そして、その賭けは当たりました。grep + glob + read という単純な組み合わせが、精緻に設計されたRAGパイプラインを打ち負かしました。

市場はこの結果を決定的に支持しました。Claude Codeは2025年5月の一般公開からわずか6ヶ月で、年換算売上（ARR）10億ドルを達成しました。これはChatGPTをも上回るスピードです。Netflix、Spotify、KPMG、L'Oreal、Salesforceがエンタープライズユーザーに名を連ねています。

Claude Codeが勝ったのは、賢かったからではありません。スコープ（範囲）に対して誠実だったからです。

Boris氏が広く議論されたワークフロースレッドで述べたように、哲学は「まずシンプルなことから始める」。メモリ実装（自動読み込みされるMarkdownファイル）にせよ、プロンプト要約（Claudeに要約を頼む）にせよ、チームは常に「有用で、理解でき、拡張可能な最小の構成要素」を選んできました。

これが、次の話の重要な伏線です。

---

意図的な「欠落」：ここが転換点

Claude Codeが得意なこと — その場限りの探索、アドホック（一時的）な理解、「今、何が起きているのか？」の把握。

しかし、以下のことは意図的に最適化されていません。

• セッションを跨いだトークンの効率化
• 推論結果の再利用
• チームレベルでの知識の蓄積

これは欠陥ではなく、境界線です。

Claude Codeは「今のこの瞬間」の体験を最高にすることに特化しています。

そこで、単純な疑問が浮かびます。

---

Plan Stack：一度学んだことをやり直さない

Plan Stackは、エージェント型検索を否定しません。むしろそれを前提としています。

唯一の違いはこうです。「探索に価値があったなら、それを蒸発させるな。」

それだけです。

ベクトルDBは不要。メモリサービスも不要。特別なインフラも不要。

ただ、docs/ や plans/ というディレクトリを Git で管理するだけです。

Claude Codeと同じ哲学 — 「賢いシステムを作るな。退屈なツール（MarkdownやGit）を使いこなせ」に基づいています。

エージェント型検索は一度だけ行い、その結果を「揮発しない形」で残すのです。

---

実践：「コンテキスト・エンジニアリング」とは何か

検索の後にすべき重要な質問はこれです。「この推論は再利用可能か？」

もしYesなら — 決定事項を抽出する。「何をしたか」だけでなく「なぜしたか」を書く。それを「プラン」または「ドキュメント」としてコミットする。

具体例

Railsアプリで複雑な決済機能を実装しているとします。最初の探索で、Claude Codeは app/models/ や app/services/、lib/ など14ファイルを調査します。決済ゲートウェイが稀に5xxエラーを返すため、独自のカスタムリトライ処理が使われていることを突き止めます。6ヶ月前の障害対応により、タイムアウトが15秒から30秒に変更されていることを発見します。

この探索には3,000〜5,000トークンかかります。そして、この「理由」は現在のセッションが終われば消えてしまいます。

2週間後、別のメンバーがリファクタリングを依頼すれば、また同じ探索、同じコスト、同じ再発見が繰り返されます。

Plan Stackがある場合、最初の探索の後、コンテキストをコミットします。

docs/plans/payment-gateway-error-handling.md

中身には、PaymentRetryService によるカスタムリトライの実装、タイムアウトは30秒（デフォルト15秒は不可）、理由（ゲートウェイが負荷時に一時的な5xxを返すため、15秒設定では障害時に連鎖失敗を引き起こしたため）、リトライロジック（指数バックオフ、最大3回）、そして関連ファイルが記録されます。

次の開発はここから始まります。再探索は不要。「何が変わったか」だけに集中できるのです。

---

これは「RAG vs エージェント型検索」ではない

その議論は本質を外しています。

Claude Codeは、実行時の検索が事前のインデックス化より優れていることを証明しました。Plan Stackは別の問いを投げかけます — なぜ学んだことを忘れてしまうのか？

両者は対立ではなく、継続的な関係にあります。

原則	Claude Code	Plan Stack
複雑なインフラを避ける	grep/glob（ベクトルDBなし）	docs/Git（専用ストレージなし）
モデルの進化に賭ける	検索能力の向上	プランの読み取り能力の向上
シンプルに始める	「シンプルなことから」	リポジトリ内のMarkdown

違いはスコープだけです。Claude Codeは今このセッションにおける最高の体験。Plan Stackはセッションやチームメンバーを跨いで積み重なる価値。

---

結びに

さらに詳しく知りたい方は、plan-stack.ai または GitHub リポジトリ planstack-ai/planstack をご覧ください。

特に、大規模リポジトリで多人数開発をしている方や、CLAUDE.md で限界を感じている方の意見を聞きたいです。「これって、手間をかけてドキュメントを書いてるだけじゃないか？」というツッコミも歓迎です。その通り、それが本質なのですから。