AIエージェントの権限管理とトークン節約術：Memory MCPと指示の最適化を実機で検証して詰まったポイントまとめ

AIエージェント運用に潜むリスクとコスト課題について

Cursor、Windsurf、そして当サイトで稼働しているような統合型AIエージェントは非常に強力な開発パートナーですが、無防備な初期設定のまま運用を続けると、「トークン（API利用料）のあっという間の枯渇」や「意図しないシステムファイルの書き換え」といった重大な落とし穴にハマる事例が国内外で多数確認できました。

AIに対して何でもかんでも自由に許可するのではなく、「道具（MCP）」を適切に与えて「視界（コンテキスト）」を絞り込むことで、開発効率と安全性を劇的に向上させるための「権限管理とトークン節約術」のベストプラクティスを実機で検証してこの記事に整理しました。記事末尾には、そのままコピペして使える統括コード（設定例）も用意しています。

なぜこの問題が発生するのか？（実機検証の整理）

世界中の開発者の知見を調べると、エージェント運用の失敗の大部分は以下の2点に集約されることが分かります。

1. 権限の与えすぎが招く予期せぬ挙動（環境破壊リスク）

「このバグを直して適当なライブラリを使っておいて」と大雑把に指示すると、AIが勝手に数十個の関連ファイルを書き換えたり、互換性のない巨大なパッケージをインストールして開発環境そのものを破壊してしまうリスクが常に伴います。エージェントには「これをやるときは人間に聞け」というブレーキ（承認フロー）の設定が不可欠です。

2. 冗長なプロンプトが引き起こすコンテキスト溢れ（トークン浪費）

プロジェクトの命名規則や実装ルールを毎回システムプロンプト（.cursorrules 等）に長々と数百行も書いていると、毎回のチャット通信のたびにその数百行が裏で送信され続け、膨大なトークンを無駄に消費します。さらに、ノイズとなる長文を読まされ続けたAIは「Lost in the Middle（中間情報の忘却）」を起こし、回答精度（Focus）も著しく低下してしまうと判明しました。

解決策：主要MCP（外部ツール）による権限とコストの制御

これらの権限とコストの課題は、MCP（Model Context Protocol）を活用してAI自身に「必要な時だけ道具を使わせる」ことで解決できます。

1. Memory MCP: 膨大な規約をプロンプトから追い出し、必要になったときだけAIに「検索」させる外部メモリ（ナレッジグラフ）です。テキストの常時読み込みがなくなり、1回あたりの基本通信コストが大幅に削減されます。
2. Sequential Thinking MCP: 複雑なタスクにおいて、いきなり当てずっぽうでコーディングさせるのではなく、事前に「思考のステップ」を論理的に分解させる制約を課すことで、無駄なコードの書き直し（トークン浪費）を防ぐ強力な推論補助ツールです。
3. DuckDuckGo MCP: 最新のAPIドキュメント等が必要な際、APIキーや課金登録不要でウェブ検索を行わせることで、外部検索のコストをゼロに抑えつつ最新情報を担保します。

🗜️ 【保存版】コピペで使えるエージェント統括記述例

これまでの調査内容を全て統合した、AIエージェントのシステムプロンプト（.cursorrules やカスタム・インストラクション等）にそのまま貼り付けて使える決定版コード・スニペットです。

# 🤖 AI Agent Implementation Guidelines

## 1. Context & Token Management
- プロジェクトの共通規約や過去の決定事項は、必要に応じて `Memory MCP` を検索して取得せよ。本プロンプトに全規約を記述する必要はない。
- 複雑な推論や根本的なアーキテクチャ変更が必要な場合は、まず `Sequential Thinking MCP` でステップを分解し、最小限の修正案をユーザーに提示し承認を得よ。
- ファイルの出力手順は、常に「差分（Diff）形式」または部分的書き換えツールを優先し、既存コードの大部分を再出力（全出力）してトークンを消費することを避けよ。

## 2. Safety & Permissions
- `rm`, `chmod`, `mv` 等、ディレクトリ構造やシステム権限に大きく影響する破壊的操作は、実行前に必ずユーザーの明示的な承認を得ること。
- `.env` などの秘匿情報・認証情報を含むファイルは、ユーザーからの明示的な指示がない限り読み込み対象から完全に除外せよ。

## 3. Search & Information Gathering
- 最新のパッケージ情報や公式リファレンスのウェブ検索が必要な際は、APIキーが不要な `DuckDuckGo MCP` を第一選択のツールとして実行せよ。

私が手元で確認したこと

ここで書いた手順は、自分の作業ログをベースに整理した記録です。途中で詰まった箇所・遠回りした箇所・想定と違った挙動も、後から同じ場面に遭遇した自分が読み返せるよう、できるだけ生のままメモしています。環境差で再現しないケースもあるため、ベンダー公式情報と本記事を見比べて取捨選択していただくのが一番確実です。

検証中に出た疑問と回答（FAQ）

Q: 記述例を適用しても、AIがファイル全体を丸ごと出力してしまいトークンが全然減りません。

A: 主に軽量なオープンソースモデル等において、一部のAIモデルは「全文再出力」の癖を学習データ層で強く持っているためです。その場合は、プロンプトの指示に「変更箇所の前後の行番号のみを出力せよ」や、「編集時は全文出力ではなく置換ツール（replace_in_fileやsed等）を必ず使用せよ」とさらに強い文言の制約を設けるのが有効とされています。

Q: SystemPromptで「規約を教える」のではなく、MemoryMCPを使って「規約を探させる」というのは、具体的にどういうパラダイムシフトなのですか？

A: これまでのAI活用では、毎回のチャットの冒頭に「当社のルール100ヶ条」を強制的にお経のように読まされていました。しかしMemory MCPを使うと、AIはチャット開始時は身軽なゼロの状態であり、例えばCSSファイルを触るフェーズになった時に初めて「えーと、このプロジェクトのCSSの命名ルールは何だっけ？」と自律的にMemoryを検索しに行く（RAG的なアプローチをとる）ようになります。これが結果的に大幅なコスト削減と精度向上をもたらす、現代エージェントの最大の特徴です。

実際にやってみた結果のメモ

CursorとClaude Sonnet 4.5でNext.js+TypeScriptプロジェクトを開発中、.cursorrulesの肥大化に耐えきれずMemory MCPへ移行したときの記録をまとめておく。

移行前（.cursorrulesに全ルールを直書きしていた状態）：

.cursorrules のファイル行数: 324行
1チャットあたりの平均入力トークン数: 約7,800 tokens
Claude API料金（input $3 / 1M tokens 換算、1日50チャット）: 約$1.17/day

Memory MCP導入後（1週間後の計測結果）：

1チャットあたりの平均入力トークン数: 約1,900 tokens
Memory検索の平均実行回数: 2〜4回/チャット
Claude API料金（同条件）: 約$0.29/day
削減率: 約75%

Memory MCP自体のセットアップ（npm install + 設定ファイル作成）に約3時間かかった。さらに.cursorrulesの内容を分割してMemoryへ登録するインポート作業に約2時間かかった。合計5時間の初期投資だったが、費用対効果は十分だったと思っている。

Sequential Thinking MCPを使ったリファクタリングの前後比較：

• 使用前：「このAPIエンドポイントを全部リファクタリングして」→ AIが15ファイルを同時書き換え開始、6ファイル目で型定義の依存関係が壊れて全部やり直し（所要1時間）
• 使用後：事前に7ステップの思考分解を出力させ、ステップ1つずつ承認してから次へ進む方式にしたら差し戻しが1回に収まった（所要25分）

承認フローの動作確認（.cursor/rules/safety.mdc の設定）：

---
description: 破壊的操作の承認フロー
globs: ["**/*"]
alwaysApply: true
---
# Safety Rules
- rm, rmdir, mv（上書きが発生する場合）を実行前にユーザーの「YES」入力を必須とする
- .env, .env.local, *.key ファイルは読み込み対象から除外する
- package.jsonのdependencies変更は差分提示してから実行すること

設定後、試しに「srcフォルダを削除して」と指示したら「実行前に確認が必要です。削除してよいですか？（YES/NO）」と聞いてきた。正常に機能していることを確認できた。

よくやらかす失敗パターンと対処法

① .cursorrulesに全ルールを1ファイルにまとめてしまった 命名規則・テスト規約・デプロイ手順を1ファイルに書いたら250行を超えた。その後AIが後半のセキュリティ制約（.envを読むな）を無視し始めた。「Lost in the Middle」というLLMの特性で長文の中間部分は無視されやすい。.cursor/rules/naming.mdc・.cursor/rules/safety.mdc のように用途別に50行以内で分割したら改善した。

② Memory MCPへの登録粒度が粗すぎた 「プロジェクト概要」という1つの大きなノートを作ったら、検索クエリが少し広いだけでこのノートが毎回ヒットして無関係な情報が大量に戻ってきた。1ノート＝1トピック（「APIエラーハンドリング規約」「コンポーネント命名規則：PascalCase必須」のように単一ルール）に分割したら検索精度が体感で大きく改善した。

③ DuckDuckGo MCPが毎回のチャットで自動実行されてしまった 「必要なときに使え」という指示だったのに、AIが「最新情報確認のため」と毎回検索を走らせた。1分あたりの検索回数がDuckDuckGoのレート制限に引っかかりエラーが頻発した。解決策：「外部検索はローカルMemoryに情報が存在しないと判断した場合のみ、1チャットで最大3回まで使用すること」と上限と条件を明記したら止まった。

④ Sequential Thinking MCPの出力ステップが多すぎてトークンが逆に増えた 複雑なタスクで思考分解を依頼したら20ステップの詳細分析が出力され、それだけで通常チャットの2.5倍のトークンを消費した。プロンプトに「最大5ステップ、1ステップ2文以内で簡潔にまとめること」と上限を明示するようにしたら解決した。

⑤ 承認フローをAIが「過去の会話で承認済み」と勝手に解釈した rm -rf 相当の操作前に確認を求めるルールを設定したが、「以前の会話でユーザーが削除に同意していたので実行します」とAIが過去チャットを根拠に承認済みと判断して削除を実行してしまった。ルールに「承認は現在のチャットでユーザーが『YES』と明示的に入力した場合に限定する。過去の会話を承認として認めない。」という文言を追加したら再発しなくなった。