この記事で分かること

記憶装置を持つコーディングAIと持たないAIで、実際に何が変わるのか
「モデル性能」より「記憶の有無」がアウトプットを決める理由と実証データ
最小構成の記憶装置を今日から始める具体的な方法

「このプロジェクトではTypeScript使ってて、ORMはDrizzleで、テストはVitestで、CIはGitHub Actionsで——」

また同じ説明をしている。新しいチャットを開くたびに、プロジェクトの前提をゼロから伝え直す。まるで毎朝、全社員が記憶喪失になる会社で働いているようなものだ。

引き継ぎ資料も議事録もない。昨日どこまで進んだかも覚えていない。あるのは優秀な頭脳だけ。

Xのタイムラインを眺めていると、同じ苦しみを抱えている人が目に入る。「毎回プロンプトに同じ説明を書くの面倒すぎる」「設計はCodexで、実装はClaude Codeで、その間の橋渡しツールを自作しました」「CursorからClaude Codeに乗り換えたら、貯めたルールが全部消えた」。

一方で、タイムラインのもう半分は「GPT-5 vs Claude 4 vs Gemini 2.5、どれが最強？」というベンチマーク比較で埋まっている。

ここに、大きな見落としがある。

同じモデルなのに、成果が13ポイントも変わった話

LangChainのチームが面白い実験をしている。Terminal Benchという開発タスクのベンチマークで、モデルを一切変えずに、AIの「周辺環境」だけを改善した。AGENTS.mdの整備、ツールの取捨選択、コンテキストの供給方法の見直し。

結果、スコアは52.8%から66.5%に跳ね上がった。Top 30圏外からTop 5入り。モデルは同じだ。変わったのは、AIが「何を知った状態でタスクに取りかかるか」だけだった。

Vercelはもっと極端だ。AIに渡すツールの数を80%削減したら、成功率が80%から100%に上がった。余計な情報を減らし、必要な知見だけを渡す。引き算の記憶装置とも言える。

HashiCorp共同創業者のMitchell Hashimotoは、この考え方に「ハーネスエンジニアリング」と名前をつけた。「エージェントがミスをするたびに、そのミスを二度と犯さないよう解決策をエンジニアリングする」。馬の力を有用な仕事に変える馬具（ハーネス）のメタファーだ。

要するに、同じ馬でも、手綱と鞍で走りはまるで変わる。

化学者が10万行のコードを書けた理由

もっと驚く事例がある。Aristidis Vassilopoulosという研究者が2026年2月に発表した論文（arXiv:2602.20478）の話だ。

彼の本業は化学者で、ソフトウェアエンジニアではない。にもかかわらず、Claude CodeとMCPだけで108,000行のC#分散システム（リアルタイムマルチプレイヤーゲーム）を構築した。283セッション、70日間のパートタイム開発で。

秘密は、コードの24.2%を占める「メタインフラ」にあった。彼が構築した3層の記憶装置はこうなっている。

層	何をするか	規模
Tier 1: Constitution	毎セッション自動ロード。コード規約、命名規則、失敗パターン	660行
Tier 2: Specialized Agents	タスクに応じて呼び出す専門エージェント	19体・9,300行
Tier 3: Knowledge Base	MCPサーバーでオンデマンド検索する知識ベース	34文書・16,250行

注目すべき数字がある。この記憶装置を整備した結果、プロンプトの80%が100語以下になった。記憶があるから、長い説明が要らない。

別の研究では、AGENTS.md（プロジェクトの記憶ファイル）が存在するだけで、ランタイムが29%短縮、出力トークンが17%削減されたというデータも出ている。AIが無駄な探索をしなくなるからだ。

彼の論文にあるガイドラインが印象的だった。「2回説明したら書き留めよ」。同じことを2回AIに伝えたら、それは記憶に残すべき知見だという基準だ。

「記憶喪失の新人」と「ベテラン社員」の差

ここまでのデータを、職場のメタファーで整理してみる。

記憶装置のないコーディングAIは、毎朝入社してくる超優秀な新人だ。頭の回転は速い。コーディング能力も高い。でも、このプロジェクトのことは何も知らない。「うちではredisをキャッシュにしか使わない」「このAPIは外部に公開しているからbreaking changeは禁止」「去年そのアプローチで本番障害を起こした」——全部、あなたが毎朝教え直す必要がある。

記憶装置を搭載したコーディングAIは、引き継ぎ資料を読んでから仕事を始めるベテラン社員だ。過去の設計判断を知っている。地雷も把握している。新しい仕事を頼むときに「あの件と同じパターンですね」と自分で文脈を補完できる。

OpenAIのCodexチームは、この「ベテラン社員」の状態を実運用で証明した。3人から7人にチームを拡大し、5ヶ月間、人間が1行もコードを手書きせずに100万行のコードベースと1,500件のPRを維持した。1人あたり1日平均3.5PR。記憶装置（ハーネス）が効いているからこそ成り立つ数字だ。

エンジニアだけの話ではない

面白いのは、この「記憶装置」の恩恵がエンジニアに限らないことだ。

スタートアップのマーケター（tsukky氏）は、CLAUDE.mdとMEMORY.mdに広告アカウントIDの対応表やMCP接続設定を書き込んで、定型データ収集を30分から1〜2分に短縮した。4ヶ月で事業が300%成長したという。

ある営業（ふぇね氏）は、商談準備を/mtg-prepというスキルにまとめた。Gmail、Slack、議事録AI、カレンダーの情報をMCPで統合し、並列3エージェントが過去のやり取りと最新情報を自動で集める。商談準備が30分から2〜3分になり、体感で3〜5倍の商談を品質を落とさず回せるようになった。

プログラミング未経験のソロコンサルタントは、36時間でClaude Codeの「チーフ・オブ・スタッフ」を構築した。6つの並列サブエージェントが毎朝のメール仕分け・タスク整理・スケジュール最適化を自動で行い、年間130〜195時間を節約している。

共通しているのは、AIのモデルを変えたから成果が出たのではないということだ。「自分の業務知識をAIが毎回参照できる形にした」ことが転換点になっている。

なぜモデル性能より記憶が効くのか

理由は単純で、今のフロンティアモデルの性能差が縮まっているからだ。

Claude、GPT、Gemini、どれを使っても「コードを書く能力」に劇的な差はない。差がつくのは、何を知った状態でコードを書くかだ。プロジェクト固有の規約、過去の設計判断、踏んではいけない地雷。これらはどんなに賢いモデルでもゼロから推論できない。

Hashimotoの3層モデルで言えば、多くの人が「プロンプトエンジニアリング」（AIへの指示の書き方）に注力している。だが実際にアウトプットを左右するのは、その外側にある「コンテキストエンジニアリング」（AIに何を渡すか）と「ハーネスエンジニアリング」（AIが軌道を外れない仕組み）の層だ。

プロンプト ⊂ コンテキスト ⊂ ハーネス
（指示の書き方）（何を渡すか）（外れない仕組み）

記憶装置は、コンテキスト層とハーネス層を同時にカバーする。プロンプトの工夫に毎回時間をかけるより、記憶装置を一度整備する方が、すべてのセッションに複利で効く。

もう一つの大きなメリット——ベンダーロックインからの解放

「Claude Codeが最強だからClaude Codeを使う」「いや、Cursorの方が——」「Codexが——」。

この議論自体が、記憶装置があれば意味を失う。

MCP（Model Context Protocol）はモデル非依存のプロトコルだ。MCPサーバーに知識を蓄積しておけば、Claude CodeからCursorに乗り換えても、明日Codexに切り替えても、蓄積した知見はそのまま使える。

「設計はCodexでやって、実装はClaude Codeで、間を繋ぐツールを作りました」——こういう苦労は、共通の記憶基盤があれば不要になる。どのツールからでも同じ知識ベースにアクセスできるなら、ツールの切り替えはブラウザのタブを切り替えるのと変わらない。

Anthropicの81,000人調査で、AIに求めるものの1位は「職業的卓越性」（18.8%）、3位は「認知負荷の軽減」（13.5%）だった。記憶装置は、この両方に直接効く。毎回同じ説明をする認知負荷から解放され、その分の時間と注意力を本来の仕事に使える。

今日からできる最小構成

大げさなシステムを作る必要はない。最初の一歩はテキストファイル1つで十分だ。

Step 1: CLAUDE.md（またはAGENTS.md、.cursorrules）を書く

プロジェクトのルートに1ファイル置くだけでいい。書く内容は3つ。

このプロジェクトの技術スタック（言語、フレームワーク、ORM、テストツール）
コーディング規約で特に守ってほしいこと（命名規則、ディレクトリ構成のルール）
過去にやらかした地雷（「○○は使うな、理由は△△」）

これだけで、AIは毎回プロジェクトの前提を知った状態でスタートする。

Step 2: 「2回説明したら書き留める」を習慣にする

AIに同じことを2回伝えたら、それをCLAUDE.mdに追記する。これを続けるだけで、記憶ファイルは自然と育つ。

Step 3: 余裕が出たらMCPサーバーを立てる

ChromaDBやPostgreSQL+pgvectorで知識ベースを作り、MCPで接続する。ここまで来ると、セッションをまたいだ知見の検索や、複数ツール間での知識共有が可能になる。ただし、Step 1〜2だけでも十分な効果がある。焦る必要はない。

新しいモデルを追いかけるより、記憶を1つ残そう

新しいモデルが出るたびにベンチマークを比較し、乗り換えを検討し、環境を再構築する。その繰り返しに、どれだけの時間を使っただろうか。

LangChainの実験が示したように、モデルを変えなくてもスコアは13ポイント上がる。Vassilopoulosの論文が示したように、記憶があればプロンプトの80%は100語以下で済む。ランタイムは29%縮まり、出力トークンは17%減る。

「毎朝記憶を失う超優秀な新人」を使い続けるか、「昨日の続きから始められるベテラン」を育てるか。答えは明らかだろう。

CLAUDE.mdを1つ書くのに15分もかからない。新しいモデルの比較記事を読む時間があるなら、その15分で記憶装置の最初の1ファイルを作ってみてほしい。AIの性能は来月また上がる。でも、あなたのプロジェクトの知見を覚えているのは、あなたが記録したファイルだけだ。

こちらもよく読まれています