400文字だけ残したはずのツール出力が、1MB を握り続けていた

「新しい文字列を作っている」ように見えて、作っていない書き方

では、どう書けば親を切り離せるのか。思いつく限りの書き方を並べて、同じ条件で測りました。4MB を20回、プレビュー長200文字です。

// exp2b.mjs — 平坦化の効き目を1手法ずつ別プロセスで測る
const F = {
  'slice':        s => s.slice(0, KEEP),
  'substring':    s => s.substring(0, KEEP),
  'template':     s => `${s.slice(0, KEEP)}`,
  'String()':     s => String(s.slice(0, KEEP)),
  'concat-empty': s => '' + s.slice(0, KEEP),
  'space-slice1': s => (' ' + s.slice(0, KEEP)).slice(1),
  'split-join':   s => s.slice(0, KEEP).split('').join(''),
  'buffer':       s => Buffer.from(s.slice(0, KEEP), 'utf8').toString('utf8'),
  'json':         s => JSON.parse(JSON.stringify(s.slice(0, KEEP))),
  'array-join':   s => Array.from(s.slice(0, KEEP)).join(''),
  'repeat1':      s => s.slice(0, KEEP).repeat(1),
  'padEnd':       s => s.slice(0, KEEP).padEnd(KEEP),
  'normalize':    s => s.slice(0, KEEP).normalize(),
};

手法ごとに別プロセスで走らせています。同一プロセスで順に測ると、前の手法が残したごみが次の計測に混ざるためです。

結果です。

私が事前に効くだろうと踏んでいたのは、テンプレートリテラルと String() でした。どちらも「新しい文字列を作る」書き方に見えるからです。実際にはどちらも素通りでした。

'' + s も、repeat(1) も、padEnd を元の長さちょうどで呼んだ場合も同じです。エンジンから見れば、返す内容が入力と同一なら入力をそのまま返すのが正しい最適化です。私たちが期待していた「コピーの副作用」は、最適化の対象そのものでした。

効いたのは、内部表現を必ず一度崩す書き方だけです。一文字足してから外す、配列に分解して繋ぎ直す、バイト列や JSON を経由します。いずれも「無駄なことをしている」ように見えるコードで、レビューで真っ先に消されそうな見た目をしています。

速いのは、いちばん無駄に見える書き方だった

平坦化のコストも測りました。256KB の元文字列から200文字を1万回切り出し、7回計測した中央値です。

いちばん場当たり的に見える (' ' + x).slice(1) が、平坦化する手法のなかで最速でした。Buffer 往復の約2.4倍の速さです。

そして、直感的に「確実そう」に見える split('').join('') と Array.from(...).join('') が最も遅く、10倍以上の開きがあります。文字ごとの配列を経由するぶん当然ではあるのですが、確実さと速さが逆向きに並ぶとは思っていませんでした。

ただし (' ' + x).slice(1) は、なぜそう書いてあるのかがコードから読み取れません。私は速度差が効かない場所では Buffer 往復を選び、ホットパスに限って (' ' + x).slice(1) を使い、必ずコメントを添えることにしました。

シリアライズ境界を越えるとき、親は付いてこない

比較表を作り終えたあとで、試し忘れていた書き方にひとつ気づきました。structuredClone です。ディープコピーのための標準 API ですから、これで親が残るならかなり嫌な話になります。

kept.push(structuredClone(full.slice(0, KEEP)));

結果は 4.00 MB でした。slice のままの 80.00 MB に対して、親はきれいに切り離されています。プレビューをオブジェクトに包んで structuredClone({ preview: p }) の形で通しても、同じ 4.00 MB でした。

理由は実装を考えれば腑に落ちます。structuredClone は値をシリアライズして復元する API なので、文字列は必ず一度バイト列に書き出されます。復元された側は平坦な新しい文字列で、親への参照を持ちようがありません。

同じ理屈なら worker_threads の postMessage にも当てはまるはずです。こちらも測りました。4MB の親から切り出した200文字のプレビュー20本を、sliced string のままワーカーへ送ります。

// 送る側 — sliced string のまま渡す
const w = new Worker(new URL(import.meta.url));
w.postMessage(previews);
 
// ワーカー側 — 受信した配列を保持したまま増分を測る
parentPort.on('message', (previews) => {
  held = previews;
  global.gc();
  parentPort.postMessage(
    `heapDelta = ${((process.memoryUsage().heapUsed - base) / 1048576).toFixed(2)} MB`);
});

受信側の heapUsed の増分は 0.01 MB でした。送信側では 80MB を握っていたのと同じ20本が、境界を越えた先ではただの4,000文字です。

つまり、履歴をワーカーや別プロセスへ渡して集約する構成なら、受け取った側でこの問題は起きません。裏を返すと、「ワーカー側を測っても何も残っていないのに、送信側のプロセスだけが太る」という非対称な見え方をします。私は最初この非対称に思い至らず、ワーカー側のスナップショットばかり眺めて時間を溶かしました。

ならば平坦化そのものを structuredClone に任せればよいかというと、そうも言えません。前節と同じ条件（256KB から200文字を1万回・7回計測の中央値）で測ると、1回あたり 1.08 µs でした。同一実行内の基準値は slice 0.11 µs・Buffer 往復 0.63 µs です（前節の表とは別の実行なので、絶対値はわずかにずれます）。Buffer 往復の約1.7倍、slice 単体の約10倍にあたります。

シリアライズによる平坦化は「境界を越えるついでに手に入るもの」として扱い、平坦化それ自体が目的の場所では Buffer 往復か (' ' + x).slice(1) を選びます。これが私の線引きです。

ツールラッパーに入れて、常駐時のメモリを測り直す

ここまでは合成の実験です。実際のツールラッパーに近い形で確かめます。1MB の出力を返すツールを200回呼び、先頭400文字を履歴に積む構成です。

// exp10.mjs — node --expose-gc exp10.mjs [naive|flatten]
const FLATTEN = process.argv[2] === 'flatten';
const CALLS = 200;
const OUT = 1024 * 1024;
const KEEP = 400;
 
function truncatePreview(s, keep) {
  if (s.length <= keep) return s;
  const head = s.slice(0, keep);
  // head は親の全文への参照を握っている。Buffer 往復で切り離す。
  return FLATTEN ? Buffer.from(head, 'utf8').toString('utf8') : head;
}
 
async function callTool(i) {
  return 'L'.repeat(OUT) + '\n#' + i;   // 大きなログを返すツールを模擬
}
 
const history = [];
global.gc();
const t0 = Date.now();
 
for (let i = 0; i < CALLS; i++) {
  const out = await callTool(i);
  history.push({ tool: 'read_log', preview: truncatePreview(out, KEEP), fullBytes: out.length });
}
 
global.gc();
const m = process.memoryUsage();
console.log(FLATTEN ? 'flatten' : 'naive  ',
            'heapUsed =', (m.heapUsed / 1048576).toFixed(1), 'MB',
            '/ rss =', (m.rss / 1048576).toFixed(1), 'MB',
            '/ elapsed =', Date.now() - t0, 'ms');

4回ずつ走らせた結果です。ばらつきはほとんどありませんでした。

履歴に残っている情報量は完全に同じです。それでも heapUsed は約44分の1、RSS は約5.6分の1になりました。

代償は200呼び出しで16ミリ秒ほど、1回あたり 0.08 ミリ秒です。ツール本体の待ち時間に比べれば誤差の範囲でした。

fullBytes を別に持っている点も意図的です。全文を捨てても「元が何バイトだったか」は残しておくと、あとから切り詰めの妥当性を判断できます。プレビューだけを見て「これで全部だ」とモデルが誤解する事故も減ります。

疑いを確信に変える — ヒープスナップショットから親を数える

「メモリが増えている」だけでは、原因が sliced string だとは言い切れません。実際に握られている親を数えられれば、対処の前後を機械的に比べられます。

Node には v8.writeHeapSnapshot() があります。出力される .heapsnapshot は JSON なので、外部ツールなしで自前に解析できます。

ノードの種別に sliced string があり、そこから親文字列へ internal エッジが伸びています。これをたどって、一定サイズ以上の親だけを合計する監査スクリプトを書きました。

#!/usr/bin/env node
// sliced_audit.mjs
// ヒープスナップショット中の sliced string と、それが握り続けている親文字列を集計する。
// 使い方: node sliced_audit.mjs <snapshot> [親と見なす下限バイト] [許容合計MB]
import fs from 'node:fs';
 
const file = process.argv[2];
const PARENT_MIN_BYTES = Number(process.argv[3] || 262_144); // 256KB 以上の親だけ数える
const BUDGET_MB = Number(process.argv[4] || 8);
 
const snap = JSON.parse(fs.readFileSync(file, 'utf8'));
const { node_fields: nf, node_types: nt, edge_fields: ef, edge_types: et } = snap.snapshot.meta;
const NS = nf.length, ES = ef.length;
const TYPE = nf.indexOf('type'), NAME = nf.indexOf('name'),
      SIZE = nf.indexOf('self_size'), ECOUNT = nf.indexOf('edge_count');
const ETYPE = ef.indexOf('type'), ETO = ef.indexOf('to_node');
const nodeTypes = nt[0], edgeTypes = et[0];
 
// ノード index → 先頭エッジ index を先に作る。毎回頭から数えると O(n^2) になる。
const edgeStart = new Uint32Array(snap.nodes.length / NS);
for (let i = 0, o = 0, e = 0; o < snap.nodes.length; o += NS, i++) {
  edgeStart[i] = e;
  e += snap.nodes[o + ECOUNT];
}
 
// 同じ親を複数の slice が指す場合の二重計上を Map で防ぐ
const parents = new Map();
let sliced = 0;
 
for (let i = 0, o = 0; o < snap.nodes.length; o += NS, i++) {
  if (nodeTypes[snap.nodes[o + TYPE]] !== 'sliced string') continue;
  sliced++;
  const base = edgeStart[i] * ES;
  for (let k = 0; k < snap.nodes[o + ECOUNT]; k++) {
    const eo = base + k * ES;
    if (edgeTypes[snap.edges[eo + ETYPE]] !== 'internal') continue;
    const po = snap.edges[eo + ETO];
    const bytes = snap.nodes[po + SIZE];
    if (bytes >= PARENT_MIN_BYTES) parents.set(po, bytes);
  }
}
 
let retained = 0;
const samples = [];
for (const [po, bytes] of parents) {
  retained += bytes;
  if (samples.length < 3) {
    samples.push({
      parentMB: +(bytes / 1048576).toFixed(2),
      head: (snap.strings[snap.nodes[po + NAME]] || '').slice(0, 32),
    });
  }
}
 
const retainedMB = +(retained / 1048576).toFixed(2);
console.log(JSON.stringify({
  slicedStrings: sliced, retainedParents: parents.size, retainedMB, budgetMB: BUDGET_MB, samples,
}));
 
process.exit(retainedMB > BUDGET_MB ? 1 : 0);

先に edgeStart を作っている部分が要点です。スナップショットのエッジは全ノード分が一本の配列に連結されているため、あるノードのエッジ位置を知るには、それ以前のノードのエッジ数を全部足す必要があります。素直に書くと二重ループになり、ノード数が数万を超えたところで監査自体が数十秒かかるようになります。

2MB の出力を50回積んだプロセスのスナップショットに対して走らせた結果です。

$ node sliced_audit.mjs naive.heapsnapshot
{"slicedStrings":54,"retainedParents":50,"retainedMB":100,"budgetMB":8,
 "samples":[{"parentMB":2,"head":"LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL"}, ...]}
exit=1

$ node sliced_audit.mjs flatten.heapsnapshot
{"slicedStrings":5,"retainedParents":1,"retainedMB":2,"budgetMB":8,"samples":[...]}
exit=0

親50本・合計100MB がそのまま出ました。平坦化した側は1本・2MB です。samples の head に親の先頭が出るので、どのツールの出力が残っているのかも見当がつきます。

5MB のスナップショットに対して監査の所要は 0.09〜0.10 秒でした。CI に入れても待たされません。

なお slicedStrings はゼロにはなりません。ライブラリの内部でも短い切り出しは日常的に起きます。判断材料になるのは本数ではなく、下限を超える親の合計サイズのほうです。

監査が赤を出しても、再起動はいらない

監査スクリプトが exit 1 を返したとき、最初に浮かぶ対処は再起動だと思います。ただ、常駐プロセスには進行中のセッションが載っていることが多く、そう気軽には落とせません。

そこで、積み上がった sliced string を稼働したまま手放させる方法を測りました。修復といっても特別なことはしません。履歴の各エントリについて、プレビューを平坦化したコピーで上書きするだけです。

for (const h of history) {
  h.preview = Buffer.from(h.preview, 'utf8').toString('utf8');
}

1MB × 200呼び出しを naive のまま積んだプロセスで、この置き換えを流した前後の実測です。

親200本が一度に手放され、置き換えの所要は200件で 0.85 ミリ秒でした。プロセスを止めずに、実質的に「漏れる前」の水準まで戻せています。

見落としやすいのは、親が解放されるのは最後の参照が消えたときだ、という当たり前の一点です。平坦化したコピーを作るだけでは足りず、sliced string を指していた変数やプロパティをそのコピーで確実に上書きする必要があります。履歴のほかにキャッシュやログバッファが同じプレビューを持っていれば、そちらを置き換えるまで親は残り続けます。

私はこの置き換えを、監査と同じシグナルハンドラに繋ぎました。SIGUSR2 を受けたらスナップショット→監査→予算超過なら置き換え→再監査、という流れです。修復後の再監査で retainedMB が落ちていれば、原因が sliced string だったことの裏付けにもなります。落ちなければ、別の何かがまだ握っています。

Python では、罠の位置がひとつずれる

同じ発想で Python も測りました。結論は逆で、str のスライスは素直にコピーを作ります。

import tracemalloc
SIZE, N, KEEP = 4 * 1024 * 1024, 20, 200
tracemalloc.start()
base = tracemalloc.get_traced_memory()[0]
kept = [( 'x' * SIZE + '#' + str(i))[:KEEP] for i in range(N)]
cur = tracemalloc.get_traced_memory()[0]
print(f"retained = {(cur - base) / 1048576:.2f} MB")

Python 3.10.12 での結果は retained = 4.00 MB でした。最後の1本ぶんだけで、積み上がりはありません。

ところが、バイト列を memoryview で切り出すと同じ罠が現れます。

kept.append(memoryview(full)[:KEEP])   # full は bytes

こちらは retained = 80.01 MB になりました。memoryview は定義上ゼロコピーのビューなので、当然といえば当然です。

言い換えると、この問題は Node 固有の欠陥ではありません。「切り出しはコピーか、それともビューか」という選択が言語ごとに違う場所に置かれているだけです。ツール出力を扱うコードを書くときは、使っている切り出し操作がどちらなのかを一度確かめておく価値があります。

Anthropic 側でも、切り詰めた MCP ツール出力について、切り詰め前の全文がセッション終了までメモリに残る問題が修正されています。同じ形の落とし穴が、公式の実装でも起きていたことになります。自作のツールラッパーで踏んでいないと考える理由はありません。

常駐させる前に、一度だけ測っておく

私がいま守っている運用は、次の三つだけです。

1. ツール出力を切り詰める関数は、ひとつに集約しています。 平坦化を各所の slice に散らすと、必ずどこかで漏れます。truncateForHistory() のような関数を1本だけ用意し、そこ以外では履歴に文字列を積まないようにしています。
2. 常駐プロセスには writeHeapSnapshot() を仕込んでおきます。 シグナルを受けたらスナップショットを書き出す程度で十分です。疑わしくなったときに現物を取れる状態にしておくと、原因の切り分けが推測から計測に変わるのだと実感しました。
3. 監査は予算つきで CI に置いています。 上のスクリプトは合計サイズが予算を超えると exit 1 を返します。閾値は本数ではなくバイト数で持つのが実用的でした。監査が予算超過を報告しても、再起動が唯一の選択肢ではありません。参照を平坦化コピーで置き換えれば稼働したまま回収できることは、先に測ったとおりです。

そして、すべての slice を平坦化する必要はありません。切り出した文字列がその場で使われて捨てられるなら、平坦化は純粋なコストです。効くのは、切り出した結果を長生きするデータ構造に積むときだけです。履歴・キャッシュ・メトリクスのラベル。 個人開発で書いたコードを見直したところ、該当したのはこの三つだけでした。思っていたより数は少なく、拍子抜けしたというのが正直なところです。

もし手元に常駐している MCP サーバーやエージェントのプロセスがあるなら、まず node --expose-gc で数百回ぶんの呼び出しを回して heapUsed を見てみてください。積み上がっていれば、切り詰めの一行から疑うと近道です。

私自身、原因にたどり着くまでにストリームと Buffer を何時間も眺めていました。いま思えば、疑うべきはいちばん短い一行のほうでした。

短く切ったから小さくなったはず、という思い込みは、測るまで手放しません。 この線引きだけは、急いでいる日にも崩さないようにしています。

同じ回り道を省けるなら嬉しく思います。お読みいただきありがとうございました。