codebase-memory-mcp 入門：Claude Code と Codex にコードベース記憶を追加する

DeusData/codebase-memory-mcp はコードインテリジェンス MCP server です。コードベースを永続的な知識グラフとしてインデックス化し、Claude Code、Codex、Gemini CLI、Aider、OpenCode などの Agent がプロジェクト構造をより速く調べられるようにします。

プロジェクト：

https://github.com/DeusData/codebase-memory-mcp

ドキュメントサイト：

https://deusdata.github.io/codebase-memory-mcp/

ワンラインインストール

macOS / Linux：

1

curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash

グラフィカルインターフェースも同時に入れたい場合：

1

curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash -s -- --ui

Windows：

1
2
3
4
5
6
7
8


# 1. Download the installer
Invoke-WebRequest -Uri https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.ps1 -OutFile install.ps1

# 2. (Optional but recommended) Inspect the script
notepad install.ps1

# 3. Run it
.\install.ps1

手動インストール

macOS / Linux で展開後にインストールします。

1
2


tar xzf codebase-memory-mcp-*.tar.gz
./install.sh

Windows：

1
2


Expand-Archive codebase-memory-mcp-windows-amd64.zip -DestinationPath .
.\install.ps1

UI を開く

1

codebase-memory-mcp --ui=true --port=9749

自動インデックスと更新

自動インデックスを有効化します。

1

codebase-memory-mcp config set auto_index true

更新：

1

codebase-memory-mcp update

アンインストール：

1

codebase-memory-mcp uninstall

向いている使い方

コードベースが大きく、Agent が同じファイルを何度も読む場面に向いています。たとえば次のような場合です。

古いプロジェクトの構造が複雑で、AI が入口をよく間違える。
多言語リポジトリで依存関係をすばやく調べたい。
Agent が大量のファイルをコンテキストに入れる量を減らしたい。
MCP を使って、複数のコーディングツールで同じコード記憶を共有したい。

インストール後は、まず小さなタスクを Agent に依頼するのがおすすめです。プロジェクト構造の説明、ある API の呼び出しチェーンの発見、設定入口の特定などです。正しく検索できることを確認してから、実際のコード変更タスクに使うとよいです。

AI Agent 向けコードベース記憶方式の比較

AI Agent がコードを書くとき、よくある問題は「モデルがまったくコードを書けない」ことではありません。問題は、そのコードベースの形を本当に理解していないことです。

入口ファイル、既存 helper、テストコマンド、触ってはいけないディレクトリを知らないため、新しい会話のたびに背景を説明し直したり、Agent が何度も grep して、関係ないファイルをコンテキストに詰め込んだりします。

これを解決するのがコードベース記憶ツールです。ただし一種類ではありません。CLAUDE.md と AGENTS.md はルールファイル、Cursor は IDE 内 index、Serena は Agent 向け semantic code tools、codebase-memory-mcp は永続的な知識グラフ、RepoPrompt は人間が選ぶ context pack、Sourcegraph は企業向け複数リポジトリ理解に向いています。

Quick Answer

ツール/方式	最適な場面	主な価値	向かない場面
`CLAUDE.md` / `AGENTS.md`	ほぼすべてのプロジェクト	ルール、コマンド、禁止領域、協業制約	複雑な呼び出し関係の自動理解
Cursor codebase indexing	Cursor ユーザー、IDE 開発	chat と編集が project index を参照しやすい	複数ツール共有や複雑な Agent orchestration
Serena MCP	大規模コード、semantic navigation、refactor	symbol 検索、参照検索、semantic editing	小さな prompt だけで足りるプロジェクト
`codebase-memory-mcp`	複数ツールで共有するコード記憶	MCP 経由の永続知識グラフ	追加サービスを維持したくない場合
RepoPrompt / RepoPrompt CE	人間が context を精密制御したい場合	file、CodeMap、diff を reviewable に組む	完全自動 index を求めるチーム
Sourcegraph / Cody	企業の複数リポジトリ理解	中央 index、検索、権限、cross-repo context	小規模個人プロジェクト

おすすめは次の通りです。

小規模：AGENTS.md または CLAUDE.md から始める。
中規模：ルールファイル + IDE index。
大規模単一リポジトリ：ルールファイル + Serena または codebase-memory-mcp。
複数リポジトリチーム：ルールファイル + MCP index + Sourcegraph のような platform。
高リスク変更：RepoPrompt のような人間が確認できる context pack を足す。

最初から道具を積み上げすぎないことが大切です。コードベース記憶の目的は Agent にすべてを知識として持たせることではなく、現在のタスクで推測、誤読、無駄な context を減らすことです。

三種類の「記憶」

1. ルール記憶

代表は CLAUDE.md、AGENTS.md、GEMINI.md、README の AI section です。技術スタック、コマンド、テスト、ディレクトリ説明、禁止ファイル、コードスタイル、検証ルールを記録します。

最も安価で安定していますが、コードの関係を自動理解するわけではありません。

2. 検索記憶

代表は Cursor codebase indexing、Sourcegraph、code search、vector index、knowledge graph です。関数定義、呼び出し元、関連ファイル、設定の出現箇所、cross-repo dependency を探します。

中〜大規模コードに向きますが、index、refresh、permissions、ignore rules が必要です。

3. 操作記憶

代表は Serena MCP や semantic editing tools です。symbol 検索、参照検索、outline、関数 body 置換、symbol rename など、IDE に近い操作を Agent に提供します。

大規模 navigation と refactor に向きますが、設定は少し複雑です。

`CLAUDE.md` / `AGENTS.md` から始める

何もないプロジェクトでは、複雑な index より先に短い project guide を作ります。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# Project Guide

## Commands

- Install: `pnpm install`
- Dev: `pnpm dev`
- Test: `pnpm test`
- Lint: `pnpm lint`

## Rules

- Prefer existing helpers in `src/lib`.
- Do not edit database migrations unless explicitly requested.
- Do not delete files without listing paths and waiting for confirmation.
- For UI changes, check mobile and desktop layouts.

これは package manager、test runner、生成物、触ってはいけないファイル、API 変更後の確認、最終報告の形を安定させます。Git で共有でき、複数ツールが読めます。

ただし関数の呼び出し関係までは教えてくれません。地盤として使い、完全な code index とは考えないほうがよいです。関連: /ja/2026/07/08/claude-code-multi-project-memory-team-workflow/。

Cursor Codebase Indexing

Cursor indexing は、日常的に Cursor で開発する人に向きます。現在のコードベースを index し、chat、編集、@Codebase が関連ファイルを見つけやすくなります。

向いている場面は、IDE 内で機能の場所を質問したい、現在の project に合わせてコード補完したい、MCP server を増やしたくない、チームが主に Cursor を使う場合です。

一方で、Cursor 内 workflow が中心で、複数ツール共有は限定的です。大規模 repo では index 範囲と ignore が重要です。AGENTS.md のようなルールファイルは引き続き必要です。

index は多ければよいわけではありません。大事なのは現在のタスクに関連する context です。token 急増や context 汚染については Claude Codeのtoken消費が急に増える理由：チュートリアル、排障、FAQ を参照してください。

Serena MCP

Serena は AI Agent 向けの IDE 能力に近いツールです。MCP 経由で semantic code retrieval、editing、refactoring、debugging tools を提供します。

大型 Python、Java、TypeScript、Go codebase、Agent が関数やファイルをよく間違えるプロジェクト、symbol/reference/declaration/implementation lookup が必要なタスク、cross-file refactor に向きます。

利点は symbol level の操作です。全文検索と行番号編集だけに頼らず、IDE のように関数を探し、参照を見て、小さく編集できます。

小さな script や一ファイル修正では不要です。MCP troubleshooting はも参考になります。

codebase-memory-mcp

DeusData/codebase-memory-mcp は codebase を永続 knowledge graph に index し、MCP で Agent に提供します。

Claude Code、Codex、Cursor、Aider、OpenCode など複数ツールを使い、同じ code index を共有したい場合に向きます。大規模 project で Agent が同じファイルを何度も読む場合、context に大量の source を貼らずに済みます。

利点は永続性と cross-tool。コストは install、update、re-index、MCP config、permission scope、ignore rules、client compatibility です。

たまに二行だけ直すなら不要です。毎日複数 Agent を切り替えるなら価値があります。チュートリアル: /ja/2026/06/22/codebase-memory-mcp-code-intelligence-guide/。

RepoPrompt

RepoPrompt と RepoPrompt CE は、全自動で repo 全体を読むのではなく、人間が reviewable context pack を組むためのツールです。

見せるファイルを厳密に制御したい、複雑な作業前に key files を選びたい、自動 index が不要な内容を持ち込みすぎる、file、CodeMap、tree、Git diff をまとめて渡したい場合に向きます。

安定した流れは、人間が entry files、関連 modules、diff を選び、RepoPrompt が context pack を作り、AI が設計やレビューを行い、実装前に scope を狭めることです。

Sourcegraph

Sourcegraph は企業向け code understanding platform です。大規模 codebase や複数 repo の index、search、permissions、code evolution に強みがあります。

複数 repo の企業チーム、大型 monorepo、cross-service migration、SSO、audit、central search、permissions、security governance が必要な組織に向きます。個人開発者は最初から使う必要はあまりありません。

規模別の選び方

個人小規模

1
2
3


AGENTS.md or CLAUDE.md
+ Git
+ IDE search

コマンド、ディレクトリ、禁止領域を明確にし、小さく変更します。誤削除対策は。

中規模

1
2
3


AGENTS.md / CLAUDE.md
+ Cursor codebase indexing
+ Serena MCP when needed

ルールファイルは安定制約、IDE index は日常質問、Serena は複雑な semantic navigation を担当します。

大規模単一リポジトリ

1
2
3
4


AGENTS.md / CLAUDE.md
+ Serena MCP
+ codebase-memory-mcp
+ per-directory notes

root rules、local directory notes、symbol tools、read-only impact analysis、小さな edit scope を使います。Claude Code subagent を使うなら code retrieval と specialized review を分けられます: 。

複数リポジトリチーム

1
2
3
4
5


AGENTS.md / CLAUDE.md per repo
+ team shared memory
+ Sourcegraph or enterprise code search
+ MCP tool layer
+ permission and audit rules

ここでは codebase memory は個人効率ではなく、engineering governance の一部になります。

選ぶ前の 7 問

コードベースはどれくらい大きいか。
問題はルール不足か、コード関係の探索不足か。
使うツールは一つの IDE か、Codex、Claude Code、Cursor、Aider など複数か。
チームでルールと index を共有する必要があるか。
secret、production config、customer data があるか。
cross-file refactor や migration が多いか。
追加 MCP server や enterprise platform を維持できるか。

ルールが問題なら AGENTS.md / CLAUDE.md、コード探索が問題なら Cursor indexing、Serena、codebase-memory-mcp、複数 repo governance なら Sourcegraph、高リスク context の確認なら RepoPrompt を検討します。

よくある失敗

記憶ファイルを百科事典にする

CLAUDE.md と AGENTS.md は操作に影響する安定ルールだけを書きます。

index 範囲が広すぎる

除外すべき例：

1
2
3
4
5
6
7
8
9


node_modules/
dist/
build/
public/
.next/
.cache/
coverage/
logs/
tmp/

.gitignore、.cursorignore、tool ignore、MCP config を使います。

search result を事実扱いする

検索結果は evidence であって conclusion ではありません。entry file、call chain、tests、config、minimal verification が必要です。

権限と privacy を忘れる

コードが upload されるか、index はどこにあるか、誰と共有するか、.env や customer data が入るか、MCP server の scope は repo 内か、logs に secret が出ないかを確認します。

ツールが多くルールが少ない

まず Agent がどう作業すべきかを書き、その後で index tools を足します。

推奨導入順

短い AGENTS.md または CLAUDE.md を追加する。
stack、commands、directories、forbidden areas、verification を書く。
.gitignore、.cursorignore、index excludes を設定する。
日常 IDE では Cursor / built-in indexing を使う。
Agent がよく間違えるなら Serena または codebase-memory-mcp を足す。
高リスク変更前に RepoPrompt を使う。
複数 repo team で Sourcegraph を検討する。

code-review-graph、Claude.md、Codex Skills の組み合わせ方

AI Agent には「コードベース記憶」が必要だ、とよく言われます。しかしこの言葉は広すぎます。 Agent にプロジェクトルールを覚えてほしい人もいます。関数の呼び出し関係を見つけてほしい人もいます。毎回リポジトリ全体を再スキャンしてほしくない人もいます。固定のレビュー手順を自動で実行してほしい人もいます。

この四つは似て聞こえますが、必要なツールはまったく違います。 Claude.md と AGENTS.md はプロジェクトルールファイルに近いものです。 code-review-graph はコード関係グラフとレビュー補助に近いものです。 codebase-memory-mcp は複数ツールで共有するコード索引サービスに近いものです。 Codex Skills は再利用できるワークフロー手順書に近いものです。

選び方を間違えると、機能が少し足りないだけでは済みません。維持コストが上がります。この記事では単一ツールの使い方ではなく、選定の考え方を整理します。

まず結論

小さなプロジェクトでは AGENTS.md または Claude.md から始めます。中規模プロジェクトでは Codex Skills を追加し、繰り返す手順を固定します。コードレビューではまず code-review-graph を検討します。複数ツールで同じコード索引を共有したい場合に、codebase-memory-mcp を考えます。

最初から四つすべてを入れる必要はありません。良い順番は、ルールファイル、ワークフロー、構造索引、MCP サービスです。 AI Agent コードベース記憶ツール比較を読んでいるなら、この記事はより実践的な選定表として使えます。

四つのツールは四つの問題を解く

ツール	主に解く問題	向いている場面	最大のリスク
`Claude.md` / `AGENTS.md`	プロジェクトルールと長期制約	小チーム、単一リポジトリ、安定した規約	長すぎてコンテキストを汚す
`Codex Skills`	反復タスクのワークフロー	公開、翻訳、デプロイ、SEO、レビュー	未成熟な手順を固定してしまう
`code-review-graph`	呼び出し関係と変更影響	PR レビュー、設計影響分析	グラフが古い、除外設定が甘い
`codebase-memory-mcp`	ツール横断の共有コード索引	複数 Agent、複数 IDE、大規模リポジトリ	権限と索引維持のコスト

重要なのは「主に解く問題」です。これらは同じ種類のツールの別ブランドではありません。四つの層です。ルール層は Agent にどう作業するかを伝えます。ワークフロー層は繰り返し何をするかを伝えます。構造層はコード同士のつながりを伝えます。サービス層は複数 Agent が同じ索引を問い合わせられるようにします。

足りない記憶を先に見極める

ツールを選ぶ前に、四つ質問します。

Agent はプロジェクト規約を忘れているのか。
Agent は関連コードを見つけられないのか。
Agent は毎回同じ手順を繰り返しているのか。
複数ツール間でコンテキストが同期されていないのか。

規約を忘れるだけなら AGENTS.md で十分です。同じ作業手順を繰り返すだけなら Skill のほうが直接的です。呼び出し関係や影響範囲を漏らすならコードグラフを使います。 Codex、Claude Code、Cursor が同じ構造化索引を見たいなら MCP を接続します。

「記憶」という言葉だけで全部を混ぜないほうがよいです。

Claude.md と AGENTS.md：プロジェクトルール層

Claude.md と AGENTS.md の価値は短さにあります。 Agent に安定したルールを伝えるもので、プロジェクト百科事典ではありません。

書くべき内容は次のようなものです。

起動コマンド。
テストコマンド。
コードスタイル。
変更禁止のディレクトリ。
公開前チェック。
よくある落とし穴。
セキュリティ境界。
言語と文面の要件。

向かない内容は次のようなものです。

完全な業務背景。
古い議論ログ。
各モジュールの詳細説明。
長い設計文書。
一度きりの作業ログ。
検証されていない個人の好み。

良いルールファイルは道しるべです。 Agent が違う方向へ行かないように知らせます。厚い手引きにする必要はありません。ルールファイルを調整するときも、Claude.md は長ければよいわけではないという原則に従ってください。

Codex Skills：ワークフロー記憶層

Skill はコード索引ではありません。覚えるのは「作業の進め方」です。

たとえばこのサイトの新規記事フローでは、次の手順があります。

新規記事かどうかを判断する。
次の番号を見つける。
index.zh-cn.md だけを作成する。
front matter を設定する。
公開日を制御する。
行数を確認する。
他言語を生成しない。

これらを毎回プロンプトに書くのは向いていません。 Skill として残すほうが自然です。

Skills に向くタスク

コンテンツ公開フロー。
多言語翻訳フロー。
デプロイフロー。
SEO クールダウン確認。
ローカルリライトフロー。
セキュリティチェックリスト。
固定形式のレポート。
コードレビュー手順。

Skills に向かないタスク

一度きりの不具合調査。
まだ探索中の手順。
その場の判断が多いタスク。
安定した受け入れ基準がないタスク。
回答を長くするためだけのプロンプト集。

良い Skill は説明を少なくし、制約を多くします。 Agent が同じミスを繰り返す確率を下げるためのものです。ゼロから書くなら Codex Skills で自分のワークフローを書く方法を参照してください。

code-review-graph：変更影響層

code-review-graph の目的はチャット履歴を覚えることではありません。焦点はコード構造です。グラフの考え方で、次の質問に答えやすくします。

この関数は誰に呼ばれているか。
このルートはどのモジュールに影響するか。
この PR はどの呼び出し連鎖を変えたか。
どのテストを追加すべきか。
どのファイルを一緒にレビューすべきか。

普通のプロンプトだけでは、こうした質問に安定して答えるのは難しいです。 Agent が diff だけ読むと間接影響を漏らします。リポジトリ全体を検索させるとコンテキストを浪費します。

グラフツールの価値はここにあります。コード構造を事前に計算しておき、Agent が必要なときに問い合わせます。

code-review-graph が向く人

PR レビューをよく行う人。
モジュール間の呼び出しが複雑なリポジトリを扱う人。
Codex や Claude Code に変更影響をレビューさせたい人。
毎回 Agent に全倉庫をスキャンさせたくない人。
レビュー手順を GitHub Actions に組み込みたいチーム。

code-review-graph が向かない人

数ファイルだけの小さなスクリプト。
PR や diff の流れがないプロジェクト。
チャット記憶だけを保存したい人。
索引生成結果を維持したくない人。
生成ファイルとソースディレクトリを分けられないリポジトリ。

使い始めるなら code-review-graph の使い方を参照してください。 CI に接続するなら code-review-graph を GitHub Actions に組み込むを参照してください。

codebase-memory-mcp：共有索引層

codebase-memory-mcp は複数ツール環境に向いています。一つの Agent だけを使うなら、必須ではありません。

しかし Codex、Claude Code、Cursor、Gemini CLI を同時に使うと問題が出ます。各ツールは自分のコンテキストを持ちます。各ツールはコードを再スキャンするかもしれません。各ツールのプロジェクト構造理解がずれるかもしれません。

このとき MCP 形式のコード索引に価値があります。コードベース構造をサービスとして複数 Agent に公開できます。 Agent は毎回理解を作り直さなくて済みます。

codebase-memory-mcp が向く場面

大規模リポジトリ。
多言語リポジトリ。
複数 Agent が同じプロジェクトを共有する。
ローカル優先のコード索引が必要。
MCP 経由で統一接続したい。
重複スキャンのコストを減らしたい。

使う前に考えること

これはサービスです。サービスには実行状態があります。ポート、権限、索引対象ディレクトリ、アップグレード問題もあります。

チームに維持する人がいなければ、「一度入れたが誰も触れないもの」になりがちです。すでに Agent 利用が安定しているチーム向けです。まだ試用段階の人には向きません。セットアップは codebase-memory-mcp チュートリアルを参照してください。

リポジトリ規模で選ぶ

リポジトリ規模は選定に強く影響します。スクリプトリポジトリと大規模モノリポジトリで同じ記憶構成にするべきではありません。

10 ファイル以下

複雑な記憶は不要です。残すものは次の程度で十分です。

README.md。
AGENTS.md。
基本テストコマンド。
Git diff レビュー。

それでも Agent がファイルを見つけられないなら、多くの場合タスク説明が広すぎます。

10 から 200 ファイル

軽量な構造説明が必要になり始めます。追加候補は次の通りです。

モジュールディレクトリ説明。
よく使うコマンド一覧。
開発または公開用 Skill を一つ。
必要なら code-review-graph。

この段階でもルールファイルは短く保ちます。すべてのモジュールを AGENTS.md に書かないほうがよいです。

200 から 2000 ファイル

変更影響の問題が出てきます。追加候補は次の通りです。

呼び出し関係グラフ。
変更影響レビュー。
CI 上の最小テスト戦略。
チーム共有ルール。
生成ディレクトリを除外する索引設定。

この層では code-review-graph の価値が高くなります。 Agent が推測に頼る量を減らせます。

多言語の大規模リポジトリ

共有索引とサービス化が必要です。追加候補は次の通りです。

codebase-memory-mcp。
統一 MCP 設定。
索引更新戦略。
権限の許可リスト。
サービス監視。
バージョンアップ記録。

ここではツール自体がインフラです。個人の習慣だけで維持してはいけません。

タスク種類で選ぶ

タスクによって必要な記憶は違います。

Bug 修正

Bug 修正では再現手順と関連ファイルが重要です。優先順位は次の通りです。

エラーログ。
再現コマンド。
直近の変更。
関連テスト。
呼び出し関係。

局所的な Bug なら MCP は不要です。モジュールをまたぐ Bug ならグラフを使います。

新機能実装

新機能では境界が重要です。優先順位は次の通りです。

要件範囲。
変更しない範囲。
データ構造。
API 契約。
テスト入口。

ルールファイルは Agent の無秩序な設計変更を防ぎます。 Skill は固定の実装フローを保存できます。

コードレビュー

コードレビューでは変更影響が最重要です。優先順位は次の通りです。

diff。
呼び出し元。
呼び出し先。
ルート入口。
テストカバレッジ。
セキュリティ境界。

ここでは長いプロンプトより code-review-graph が向いています。

ドキュメントと公開

ドキュメントと公開ではワークフロー記憶が重要です。優先順位は次の通りです。

front matter。
ファイル命名。
ビルドルール。
多言語同期。
リンクチェック。
公開前チェック。

この種類のタスクは Skills に向いています。

データ更新戦略

コードベース記憶は更新しないとすぐ Agent を誤導します。ツールごとに更新方法は違います。

ルールファイルは人が維持します。 Skills は手順の変化に合わせて更新します。 code-review-graph はコード変更後に再構築または増分更新します。 codebase-memory-mcp は索引サービスとデータディレクトリを維持します。

更新が必要なタイミング

モジュール追加。
ディレクトリ削除。
ルート構造変更。
テストコマンド変更。
ビルドツール変更。
生成ディレクトリ変更。
チーム権限ルール変更。
CI フロー変更。
Agent ツール更新。
MCP サービス更新。

更新後の確認

Agent が入口ファイルを説明できる。
Agent が関連テストを見つけられる。
Agent が生成ディレクトリをスキャンしない。
Agent が実際の diff を説明できる。
Agent が変更禁止範囲を守る。
Agent が正しい Skill を呼び出せる。
MCP クエリが最新ファイルを返す。
グラフ結果が実際のコードと一致する。

失敗例と修正

ルールファイルが長すぎる

症状は、Agent の読み込みが遅く、無関係なルールを引用することです。修正方法は削ることです。安定した制約だけを残します。手順は Skill に移します。背景は文書に移します。

Skill が広すぎる

症状は、あらゆるタスクが同じ手順に押し込まれることです。修正方法は分割です。一つの Skill は一種類の仕事だけを扱います。公開、翻訳、デプロイ、レビューを分けて書きます。

グラフが生成ディレクトリを除外していない

症状は、Agent がソースコードではなくビルド成果物に注目することです。修正方法は ignore 設定の更新です。 dist/、public/、node_modules/、キャッシュディレクトリを除外します。

MCP の権限が広すぎる

症状は、Agent が無関係なリソースにアクセスできることです。修正方法は権限分離です。読み取り専用ツールを先に使います。書き込みツールは別承認にします。本番系ツールはデフォルトで閉じます。

四つのツールをどう組み合わせるか

個人の小規模プロジェクトでは、AGENTS.md、少量のプロジェクト文書、Git diff、最小テストコマンドで十分です。中規模 Web プロジェクトでは、AGENTS.md、公開またはテスト用 Skill、code-review-graph、PR レビューテンプレートを組み合わせます。複数 Agent のチームプロジェクトでは、AGENTS.md、チーム Skills、code-review-graph、codebase-memory-mcp、CI レビュー、権限境界文書を用意します。コンテンツサイトと自動化ワークフローでは、公開 Skill、翻訳 Skill、SEO クールダウンルール、デプロイ Skill、少量のサイト構造メモが合います。

重要なのはツールの数ではありません。各層が解く問題を重ねないことです。

選定ツリー

まず、Agent はプロジェクトルールに頻繁に違反するかを聞きます。はいなら、AGENTS.md または Claude.md を書きます。

Agent は同じ手順を頻繁に繰り返すか。はいなら、Skill を書きます。

Agent は呼び出し関係や影響範囲を頻繁に漏らすか。はいなら、code-review-graph を使います。

複数 Agent が同じコード索引を共有する必要があるか。はいなら、codebase-memory-mcp を考えます。

いいえなら、まだツールを増やしません。この順番なら、単純な問題を複雑にしにくくなります。

既存記事とのつなげ方

この記事は選定入口として使えます。単一ツールのインストールは既存記事に任せます。

code-review-graph の具体的なコマンドは 7/99。 GitHub Actions 連携は 7/137。 codebase-memory-mcp のインストールは 6/113。ルールファイルの考え方は 4/118。汎用的な記憶ロードマップは 7/42。

こうすると読者は一つの記事で大量のコマンドに沈みません。先に方向を選び、その後で具体的なチュートリアルへ進めます。

最終的な選び方

Agent に固定ミスをさせたくないだけなら、AGENTS.md または Claude.md を選びます。 Agent に固定手順で作業してほしいなら、Codex Skills を選びます。 Agent に変更影響分析をさせたいなら、code-review-graph を選びます。複数 Agent にコード構造を共有させたいなら、codebase-memory-mcp を選びます。

成熟したコードベース記憶とは、すべてを覚えることではありません。ルール、ワークフロー、構造、サービスを適切な場所に置くことです。