AIエージェントが本番で失速する理由とメモリ設計の3つの罠

なぜ本番でAIが遅くなるか

俺はこの半年で、Claude Codeを使ったAIエージェント自動化に取り組んできた。最初は調子よかった。Slackから質問が飛んでくると、数秒でメッセージが返ってくる。「これはいける」と思ってた。

でも現実は違った。

週1くらいは遅延が起きるようになった。同じプロンプトで、ある時は3秒、ある時は45秒。エラーが出ないから原因がわからない。データベースのレスポンスも遅くないし、n8nのワークフローも変わってない。

しばらく悩んでから気づいた。メモリだ。

Claude Codeは1セッション内で、すべてのファイル読み込み履歴・エージェント実行ログ・プロンプトキャッシュを積み重ねていく。セッションが長くなるほど、コンテキストウィンドウが圧迫される。一度圧迫されると、キャッシュが効かなくなって、同じプロンプトを処理するのに毎回フルコンテキストを読み直さないといけない。その結果、レスポンスが遅くなる。

さらに悪いことに、データソースそのものを毎回スクラップしてた。n8nワークフローが実行されるたびに、Supabaseから生データを引っ張ってきて、Claude Codeのプロンプトに埋め込む。データが増えるほど、読み込みが重くなる。100件から1000件に増えると、顕著に遅くなった。

本番で遅くなる理由は、ほぼこの3つだ。

セッションメモリの膨張 — Claude Code内のコンテキストウィンドウが圧迫される
生データの毎回読み込み — スクラップしたデータそのものがプロンプトに入ってる
キャッシュの無効化 — メモリが満杯になるとプロンプトキャッシュが効かなくなる

最悪なのは、ローカル開発環境では起きない。データが少ないからだ。本番で初めて顔を出す。これが最高にダサい。

Claude Code MEMORY.mdパターン

最初に試したのが、Claude Codeの MEMORY.md を使う方法だ。これは .claude/ ディレクトリ内に MEMORY.md を置いて、重要な情報を構造化して保存する仕組み。

実装は単純だ。セッションの初期化時に、大量データを1回だけメモリに読み込む。その後は、必要な時だけメモリから参照する。

# MEMORY.md
 
## ユーザーリスト（更新: 2026-04-15）
| user_id | email | status |
|---------|-------|--------|
| 001 | user1@example.com | active |
| 002 | user2@example.com | inactive |
...（以下100件）

俺の場合、顧客リスト50名・過去3ヶ月の問い合わせ100件をMEMORY.mdに入れた。ファイルは1.2MB になった。

メリット:

セットアップが簡単。ファイルをコミットするだけ
ローカル開発で動作確認できる
Claude Codeのプロンプトキャッシュが効く。2回目以降、MEMORY.md の読み込みが高速

デメリット:

ファイルサイズが大きくなると、セッション起動時に毎回読む
データが更新されたら、手動でMEMORY.mdを編集・コミットが必要。自動更新できない
チーム複数人で使う場合、マージコンフリクトが起きやすい
100件までなら問題なかったけど、データが1000件を超えると、セッション起動が遅くなる

結論として、俺は 静的で頻繁に変わらないデータ（顧客リスト、カテゴリマスタ等）向け だと判断した。

n8n static dataパターン

次に試したのが、n8n の Set Data ノードで静的データを埋め込む方法。

n8n ワークフロー内に Set Data ノードを配置して、ワークフロー内で固定データを管理する。Claude Codeは、そのデータだけをプロンプトに含める。

実装例:

{
  "nodes": [
    {
      "name": "Set Customer Data",
      "type": "n8n-nodes-base.set",
      "typeVersion": 1,
      "position": [400, 200],
      "parameters": {
        "assignments": {
          "assignments": [
            {
              "name": "customers",
              "value": "[{\"id\": 1, \"name\": \"Acme Inc\", \"tier\": \"gold\"}, ...]"
            }
          ]
        }
      }
    },
    {
      "name": "Claude Code Agent",
      "type": "n8n-nodes-base.openai",
      "inputs": ["Set Customer Data"]
    }
  ]
}

n8n ワークフロー実行時に、このデータがすでに変数 customers として存在している。Claude Codeは「$customers を参照しろ」というシンプルな指示で済む。

メリット:

n8n内でデータ管理が完結。GitHub と疎結合になる
ワークフロー UI で視覚的に確認できる
データをJSON形式で直接埋め込める。自動更新ロジック（SQLクエリ等）も組める -複数のワークフロー間でデータ再利用できる

デメリット:

n8n UI 内のテキストエディタで大量データを編集するのは地獄。1000件越えるとほぼ不可能
プロンプトキャッシュは効かない（毎回データが同じでも、n8n実行時に再計算される）
n8n ワークフローのバージョン管理が複雑になる。データ変更のたびにバージョン番号を上げないと、どの実行でどのデータを使ったか追跡できない

俺の場合、顧客が30名規模なら、この方法で十分だった。ただデータが増え始めると、UI 操作が重くなって効率が悪い。

Supabaseパターン

最後に試したのが、Supabase を使う方法。これが現在の本命だ。

Supabase は PostgreSQL + リアルタイム API。データを Supabase テーブルに保存して、Claude Code は HTTP リクエストで必要なデータだけを引っ張ってくる。

実装:

-- Supabase テーブル
CREATE TABLE public.customers (
  id BIGINT PRIMARY KEY,
  name TEXT NOT NULL,
  email TEXT,
  tier TEXT,
  created_at TIMESTAMP
);

Claude Code は n8n 経由で、こんな感じで問い合わせる:

const response = await fetch('https://xxxx.supabase.co/rest/v1/customers?select=id,name,tier&tier=eq.gold', {
  headers: {
    'apikey': process.env.SUPABASE_KEY,
    'Content-Type': 'application/json'
  }
});
const customers = await response.json();

必要なデータだけを、フィルタ条件付きで取得できる。

メリット:

スケーラブル。1000件でも10000件でも、必要なデータだけ引ける
リアルタイム。データ更新が即座に反映される
プロンプト内のデータ量を最小化できる。1000件中「gold tier のみ」なら30件だけ引く
SQL で複雑な条件検索ができる
チーム複数人で同じデータソースを共有できる
セッションメモリに圧力をかけない

デメリット:

セットアップが複雑。テーブル設計・認証・API キー管理が必要
外部サービスへの依存。Supabase ダウンしたら、エージェントも動かない
API リクエストのレイテンシ。ローカルホストと違い、数百ミリ秒かかる
データベース行数が多いと、クエリ性能が課題になる可能性（インデックス設計が重要）

俺は顧客情報・問い合わせ履歴・カテゴリマスタを Supabase に入れた。毎日のクローン処理で自動更新されるようにした。

本番で遅延が起きなくなった。同じクエリなら平均3秒で返ってくるようになった。

どれを選ぶか（判断基準）

経験上、データ規模と更新頻度で決まる。

MEMORY.md を選ぶ:

データが 100 件以下で、月1回以下の更新
GitHub コミット履歴として記録したい（コンプライアンス要件等）
セットアップを最小化したい（チュートリアル向け）

例: 部門別カテゴリ10種類、ブランド6つ等のマスタデータ。

n8n Set Data を選ぶ:

データが 100 〜 500 件で、週1回程度の更新
n8n ワークフロー内で完結させたい
複数ワークフロー間でデータ共有したい

例: キャンペーン一覧50件、スタッフリスト30名。

Supabase を選ぶ:

データが 1000 件以上、日次以上の更新
リアルタイム性が必要
チームで複数のエージェントを運用
本番環境で遅延が許されない

例: ユーザー顧客情報・問い合わせ履歴・トランザクションログ。

俺の場合、本番環境では Supabase + n8n + Claude Code の組み合わせ で落ち着いた。

静的マスタデータは MEMORY.md で管理して、セッションキャッシュを効かせる。動的な顧客情報は Supabase から毎回取得。n8n は、その2つのデータを整理してから Claude Code に渡す橋役として機能させてる。

この組み合わせで、本番環境での遅延はほぼゼロになった。

数字は嘘をつかない。同じ問い合わせで、47秒かかってたのが、3秒になった。積み上がる。

俺の経験が、君の AIエージェント本番化に役立つなら嬉しい。ただこれは、俺が実装して分かったことであって、全員の正解ではない。自分のデータ規模・チーム人数・更新頻度で判断してほしい。

より詳しい実装パターン・テンプレート・セットアップ手順は、THINK YOU LAB の公式LINE で配信中です。月額会員向けには、Supabase テーブル設計から n8n ワークフロー統合まで、ステップバイステップのロードマップも用意してます。気になったら、下のボタンから登録して、まずは無料で情報受け取ってみてください。

なぜ本番でAIが遅くなるか

でも現実は違った。

しばらく悩んでから気づいた。メモリだ。

本番で遅くなる理由は、ほぼこの3つだ。

セッションメモリの膨張 — Claude Code内のコンテキストウィンドウが圧迫される
生データの毎回読み込み — スクラップしたデータそのものがプロンプトに入ってる
キャッシュの無効化 — メモリが満杯になるとプロンプトキャッシュが効かなくなる

最悪なのは、ローカル開発環境では起きない。データが少ないからだ。本番で初めて顔を出す。これが最高にダサい。

Claude Code MEMORY.mdパターン

実装は単純だ。セッションの初期化時に、大量データを1回だけメモリに読み込む。その後は、必要な時だけメモリから参照する。

# MEMORY.md
 
## ユーザーリスト（更新: 2026-04-15）
| user_id | email | status |
|---------|-------|--------|
| 001 | user1@example.com | active |
| 002 | user2@example.com | inactive |
...（以下100件）

俺の場合、顧客リスト50名・過去3ヶ月の問い合わせ100件をMEMORY.mdに入れた。ファイルは1.2MB になった。

メリット:

セットアップが簡単。ファイルをコミットするだけ
ローカル開発で動作確認できる
Claude Codeのプロンプトキャッシュが効く。2回目以降、MEMORY.md の読み込みが高速

デメリット:

ファイルサイズが大きくなると、セッション起動時に毎回読む
データが更新されたら、手動でMEMORY.mdを編集・コミットが必要。自動更新できない
チーム複数人で使う場合、マージコンフリクトが起きやすい
100件までなら問題なかったけど、データが1000件を超えると、セッション起動が遅くなる

結論として、俺は 静的で頻繁に変わらないデータ（顧客リスト、カテゴリマスタ等）向け だと判断した。

n8n static dataパターン

次に試したのが、n8n の Set Data ノードで静的データを埋め込む方法。

n8n ワークフロー内に Set Data ノードを配置して、ワークフロー内で固定データを管理する。Claude Codeは、そのデータだけをプロンプトに含める。

実装例:

{
  "nodes": [
    {
      "name": "Set Customer Data",
      "type": "n8n-nodes-base.set",
      "typeVersion": 1,
      "position": [400, 200],
      "parameters": {
        "assignments": {
          "assignments": [
            {
              "name": "customers",
              "value": "[{\"id\": 1, \"name\": \"Acme Inc\", \"tier\": \"gold\"}, ...]"
            }
          ]
        }
      }
    },
    {
      "name": "Claude Code Agent",
      "type": "n8n-nodes-base.openai",
      "inputs": ["Set Customer Data"]
    }
  ]
}

メリット:

n8n内でデータ管理が完結。GitHub と疎結合になる
ワークフロー UI で視覚的に確認できる
データをJSON形式で直接埋め込める。自動更新ロジック（SQLクエリ等）も組める -複数のワークフロー間でデータ再利用できる

デメリット:

n8n UI 内のテキストエディタで大量データを編集するのは地獄。1000件越えるとほぼ不可能
プロンプトキャッシュは効かない（毎回データが同じでも、n8n実行時に再計算される）
n8n ワークフローのバージョン管理が複雑になる。データ変更のたびにバージョン番号を上げないと、どの実行でどのデータを使ったか追跡できない

俺の場合、顧客が30名規模なら、この方法で十分だった。ただデータが増え始めると、UI 操作が重くなって効率が悪い。

Supabaseパターン

最後に試したのが、Supabase を使う方法。これが現在の本命だ。

Supabase は PostgreSQL + リアルタイム API。データを Supabase テーブルに保存して、Claude Code は HTTP リクエストで必要なデータだけを引っ張ってくる。

実装:

-- Supabase テーブル
CREATE TABLE public.customers (
  id BIGINT PRIMARY KEY,
  name TEXT NOT NULL,
  email TEXT,
  tier TEXT,
  created_at TIMESTAMP
);

Claude Code は n8n 経由で、こんな感じで問い合わせる:

const response = await fetch('https://xxxx.supabase.co/rest/v1/customers?select=id,name,tier&tier=eq.gold', {
  headers: {
    'apikey': process.env.SUPABASE_KEY,
    'Content-Type': 'application/json'
  }
});
const customers = await response.json();

必要なデータだけを、フィルタ条件付きで取得できる。

メリット:

スケーラブル。1000件でも10000件でも、必要なデータだけ引ける
リアルタイム。データ更新が即座に反映される
プロンプト内のデータ量を最小化できる。1000件中「gold tier のみ」なら30件だけ引く
SQL で複雑な条件検索ができる
チーム複数人で同じデータソースを共有できる
セッションメモリに圧力をかけない

デメリット:

セットアップが複雑。テーブル設計・認証・API キー管理が必要
外部サービスへの依存。Supabase ダウンしたら、エージェントも動かない
API リクエストのレイテンシ。ローカルホストと違い、数百ミリ秒かかる
データベース行数が多いと、クエリ性能が課題になる可能性（インデックス設計が重要）

俺は顧客情報・問い合わせ履歴・カテゴリマスタを Supabase に入れた。毎日のクローン処理で自動更新されるようにした。

本番で遅延が起きなくなった。同じクエリなら平均3秒で返ってくるようになった。

どれを選ぶか（判断基準）

経験上、データ規模と更新頻度で決まる。

MEMORY.md を選ぶ:

データが 100 件以下で、月1回以下の更新
GitHub コミット履歴として記録したい（コンプライアンス要件等）
セットアップを最小化したい（チュートリアル向け）

例: 部門別カテゴリ10種類、ブランド6つ等のマスタデータ。

n8n Set Data を選ぶ:

データが 100 〜 500 件で、週1回程度の更新
n8n ワークフロー内で完結させたい
複数ワークフロー間でデータ共有したい

例: キャンペーン一覧50件、スタッフリスト30名。

Supabase を選ぶ:

データが 1000 件以上、日次以上の更新
リアルタイム性が必要
チームで複数のエージェントを運用
本番環境で遅延が許されない

例: ユーザー顧客情報・問い合わせ履歴・トランザクションログ。

俺の場合、本番環境では Supabase + n8n + Claude Code の組み合わせ で落ち着いた。

この組み合わせで、本番環境での遅延はほぼゼロになった。

数字は嘘をつかない。同じ問い合わせで、47秒かかってたのが、3秒になった。積み上がる。