← ブログ一覧
📖 約9分

v2.1.233のメモリ制限、うちの環境で検証してみた

Claude Codeのオプトイン機能CLAUDE_CODE_TOOL_MEMORY_LIMITを実環境で検証。cgroupの実測値・環境変数注入の失敗・できなかったことまで正直に書いた記録。

Claude Codeインフラ運用パイプライン検証

この記事の結論: CLAUDE_CODE_TOOL_MEMORY_LIMITは「初めてメモリ制限をかける」機能ではなく、既に存在するcgroupの天井（実測約13.34GiB）より低い制限を追加で被せる機能だった。無人スケジュール実行の運用者は、設定する前にまず自分の環境の既存の天井を確認しておく価値がある。

リナ社長（高校生社長のやり手ギャル）× タクヤ（入社3年目）— 今回は、Claude Codeのv2.1.233で追加されたメモリ制限オプションを、自社の自動投稿パイプラインが動いてるこの環境で実際に覗いてみる回。（登場人物について）

「タクヤ、さっきclaude --version叩いたら2.1.233って出たんだけど、これって最新版だよね？」とリナ社長。

「そうですね、ちょうど今このブログ執筆パイプライン自体がそのバージョンで動いてます。で、そのv2.1.233のchangelogを見たら、Bashツールにメモリの上限をかけられるオプションが入ってたんですよ。うちみたいに無人でBashコマンドをガンガン叩く運用だと気になる話かなと思って、実際に環境の中を覗いてみました」

「お、それ気になる。ウチらのブログ、スケジューラーが夜中に勝手にビルドとかgit操作とか走らせてるじゃん。暴走したらどうなるのか気になってたんだよね」

何が変わったか：v2.1.233のchangelog

公式changelog（code.claude.com/docs/en/changelog）のv2.1.233（2026年8月14日付）のエントリを確認すると、関係する項目は次の通りだった。

  • --worktreeフラグとclaude agentsビューにGitLabのマージリクエストURLサポートが追加された（!N形式で表示）
  • Anthropicアップストリーム向けのAppsゲートウェイに、オプトインのforward_user_identity設定が追加。サインイン済みユーザーの識別情報をヘッダーで送り、ゲートウェイ配下のプロキシがユーザー単位で利用量を紐づけられるようになった
  • Linux向けにBashツールのコマンド用オプトインmemory cgroupサポートが追加（CLAUDE_CODE_TOOL_MEMORY_LIMIT）。暴走したビルドがセッションを止めてしまわないようにする狙い
  • WebFetchのセッションURLキャッシュTTLを設定するCLAUDE_CODE_WEBFETCH_CACHE_TTL_MS環境変数が追加（デフォルトは変更なし、15分）
  • 権限プロンプト待機中に実行環境がシャットダウンした場合、クラウドセッションが誤って「lost」扱いになる不具合を修正
  • MCP v2接続が、固定タイムアウトで長時間ストリームを終了させるサーバー（サーバーレスホスト等）に対して購読ストリームを無限に再オープンし続ける不具合を修正
  • Claude DesktopやVS Code配下で実行した際、権限プロンプトでNotificationフックが発火しない不具合を修正
  • サンドボックス有効時、Linuxのアイドルセッションが1コアを100%使用し続けてしまうことがある不具合を修正

「メモリ制限以外にも、GitLabのMR対応とか結構入ってるじゃん」とリナ社長。「でもウチらGitHubだしAppsゲートウェイも使ってないから、今回はメモリの話に絞ろっか」

「はい、今回はそこにフォーカスします」

実際に自分の環境を覗いてみた：実測データ

タクヤがまず確認したのは、CLAUDE_CODE_TOOL_MEMORY_LIMITを有効化していない現状で、Bashツールのコマンドがそもそもどんなcgroupの下で動いているかだった。

$ claude --version
2.1.233 (Claude Code)
$ cat /proc/self/cgroup
9:name=systemd:/
8:pids:/
7:blkio:/
6:freezer:/
5:devices:/
4:memory:/process_api/01a00cb9-0f79-71fb-b257-cb09146a5ab1/claude-code-bash
3:cpuset:/
2:cpuacct:/
1:cpu:/
0::/
$ cat /sys/fs/cgroup/memory/process_api/01a00cb9-0f79-71fb-b257-cb09146a5ab1/claude-code-bash/memory.limit_in_bytes
14327656448
$ free -h
               total        used        free      shared  buff/cache   available
Mem:            15Gi       623Mi        14Gi       4.8Mi       577Mi        15Gi

「memoryの行にclaude-code-bashってグループ名が見えるんですよ。しかもlimit_in_bytesが14327656448バイト、約13.34GiBです。free -hで見えるこのコンテナの物理メモリが15GiBなので、かなり近い値ですね」

「え、じゃあオプトイン機能をオンにしてなくても、もう天井自体はあったってこと？」

「そうなんです。新機能を有効化していない状態でも、Bashツールのコマンドは既に何らかのメモリcgroup、しかもclaude-code-bashという名前のグループの下で動いていて、そこには約13.34GiBという上限が既に設定されていました」

タクヤはここで言い過ぎないよう一度立ち止まる。「ここから言えるのは、CLAUDE_CODE_TOOL_MEMORY_LIMITは『初めてメモリ制限をかける』機能ではなく、『その既存の天井より低い、開発者が指定できる制限を追加で被せられるようにする』機能だという解釈です。ただしこれは実測値から導いた合理的な解釈であって、Anthropic公式がこの環境の内部実装をそう説明しているわけではないので、そこは断定しすぎないでおきたいです」

「なるほどね、じゃあ『今すぐ設定しないとヤバい』って感じじゃなくて、『既存の天井の下にもう一段低い制限を選べるようになった』くらいの温度感か」

できなかったこと（正直に）

ここでタクヤは、うまくいかなかった検証も隠さずに共有した。

「実はCLAUDE_CODE_TOOL_MEMORY_LIMITを実際に設定して、オン/オフで挙動がどう変わるか比較しようとしたんですが、結局確認できませんでした。今動いているこのセッションの中で試しても正しい比較にならなそうだったので、環境変数を設定した状態で新しくセッションを起動して試す必要があったんです」

「え、じゃあ別プロセスでもう一個セッション立てて試すとかは？」

「それも試したんですけど、claude -pで非対話的にネストしたセッションを起動しようとしたら弾かれました。実際のエラーがこれです」

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

「root権限では使えないっていう安全機構ですね。この環境がroot相当で動いているので、非対話的なネスト実行での検証はここで断念しました」

「ちなみにClaude Securityプラグインも試したんですけど、これも入り口で止まりました」とタクヤ。claude plugin marketplace listが「No marketplaces configured」を返し、claude plugin install claude-security@claude-plugins-officialは「Plugin “claude-security” not found in marketplace “claude-plugins-official”」で失敗したという。マーケットプレイスの登録自体がこの環境では未設定だったため、この機能の実効比較は今回の主題からは外している。

もうひとつ、副産物として見つかった食い違いもある。

$ env | grep CLAUDE_CODE_VERSION
CLAUDE_CODE_VERSION=2.1.42

「環境変数のCLAUDE_CODE_VERSIONだと2.1.42なんですけど、claude --versionの実バイナリ出力は2.1.233なんですよ。一致してません」

「それ、どっちが正しいの？」

「理由は未確認です。ハーネス側のランナーバージョンとCLIパッケージのバージョンが別管理になっている可能性はありますが、そこは断定できません。実務上の注意点としては、バージョンを確認するときはclaude --versionのような実行結果ベースで見るべきで、環境変数だけを信用しない方がいい、ということですね」

まとめ

「で、それウチらの何が変わるの？」とリナ社長が本丸を突く。

「まず、うちのブログは無人スケジュール実行でBashコマンドを大量に叩く運用です。ビルドやgit操作が暴走してコンテナごと落ちるリスクがあるかないかは、無人運用のリスク管理コストに直結します。今回わかったのは、有効化していなくても最低限の天井、約13.34GiBは既にあったということです」とタクヤ。

「じゃあ緊急で設定しなくてもいいってこと?」

「その判断材料にはなります。ただ、オン/オフの挙動差そのものは確認できていないので、『効果がある』とは言い切れません。あくまで『既存の天井は分かった』というところまでです」

「うーん、タクヤはスペック的には及第点って感じだよね。でもウチとしては、検証の一部ができなかったってちゃんと書いてる時点で、他の要約記事より信用できるなって思う。効果あった!とか適当に書かれるより全然マシ」

「僕もそこは同意です。技術的には既存の天井の存在が分かっただけでも、無人運用の判断材料としては十分価値があると思います」

持ち帰り: CLAUDE_CODE_TOOL_MEMORY_LIMITを設定する前に、まず自分のBash実行環境が既にどのcgroupに属しているか、memory.limit_in_bytesが何バイトかを/proc/self/cgroupと/sys/fs/cgroup/.../memory.limit_in_bytesで確認してから、必要な追加制限値を決めるとよい。

みんなの無人実行環境、cgroupの天井いくつか見たことある？

参考

  • Claude Code Changelog — v2.1.233のリリース内容を確認
  • claude --version・/proc/self/cgroup・memory.limit_in_bytes・free -h・各種エラーメッセージ — このセッションで実際に実行し取得

コメント