AIに重いビルドを任せたら、PCや共有サーバー全体が固まった。こうなると、速さの話ではありません。人が復旧に呼ばれ、ほかの仕事まで止まります。
2026年8月14日に公開されたClaude Code v2.1.233は、この地味だが厄介な事故に対して、Linux上のBashコマンドへメモリ上限を設ける機能を追加しました。環境変数 CLAUDE_CODE_TOOL_MEMORY_LIMIT で有効にする任意設定です。暴走したビルドがセッション全体を止める事態を抑える狙いがあります。
同じリリースには、組織運用で効く変更がもう一つあります。Apps Gateway経由で利用者の識別情報を上流プロキシへ渡す forward_user_identity 設定です。こちらも任意設定。誰が使ったかをプロキシ側で識別し、利用者別の支出を把握できるようにします。
今回の変更で何が変わったか
公式リリースノートで確認できる主な変更は、次の通りです。
- Linux上のBashコマンドに、cgroupを使ったメモリ上限を設定できる
- Apps Gatewayから上流プロキシへ、署名済み利用者の識別情報を送れる
- 許可待ちのまま環境が終了したクラウドセッションを、誤って「消失」と判定する問題を修正
- Linuxのサンドボックス有効時に、待機中のセッションがCPUコアを使い切る場合がある問題を修正
- Windowsの特殊なパス表記でUNC検証を回避できた問題を修正し、NTLM認証情報が漏れる経路を閉じた
派手な機能追加ではありません。ただ、AIに長時間の仕事を委譲する会社では、こうした制限と記録のほうが効きます。止まらないことより、止まっても被害を広げず、誰の実行だったか追えること。そこまで決めて初めて、夜間や無人の処理を任せられます。
メモリ上限は「安全装置」であって性能設定ではない
メモリ上限を低くすれば安全、という話ではありません。ビルドやテストが必要とする量を下回れば、処理は途中で失敗します。最初から本番値を決め打ちせず、普段のピークを測り、その少し上に上限を置くのが現実的です。
たとえば、通常4GB前後で終わる処理に対して、いきなり4GBを上限にすると余裕がありません。まず代表的な案件を数回流し、ピークと失敗時のログを残す。そのデータを見て上限を決めます。ここは自動化より先に、観測が要ります。
注意点もあります。この機能はLinux向けで、公式リリースノート上ではcgroupを使う任意設定として案内されています。macOSやWindowsへ同じ設定がそのまま効くとは読めません。対象OSと実行基盤を混ぜずに管理してください。
利用者情報を送る前に決めること
forward_user_identity は、利用者別の費用配賦や異常利用の確認に使えます。一方で、識別情報を受け取るプロキシのログ設計が雑なら、新しい漏えい面を増やします。
設定を有効にする前に、少なくとも次の4点を決めます。
- どの識別子を記録するか
- ログを誰が閲覧できるか
- 何日で削除するか
- 費用確認以外に流用しないことをどう担保するか
Claude Codeの公式セキュリティ文書は、既定では読み取り中心の権限設計を採り、ファイル変更やコマンド実行で許可を求めると説明しています。サンドボックスも、ファイルシステムとネットワークの境界を設ける仕組みです。メモリ制限や利用者別記録は、AIに任せるための境界線設計を「実行資源」と「費用」に広げるものだと考えると整理しやすいでしょう。
中小企業での導入手順
いきなり全員へ配る必要はありません。1台、1案件、1週間で十分です。
- Linuxの検証環境を1つ決める
- 普段のビルドとテストでメモリ使用量を測る
- 上限超過時に、処理が止まりログが残るか確認する
- Apps Gatewayを使う場合は、利用者別の記録と閲覧権限を検証する
- 異常終了後に、同じ仕事を二重実行しない再開手順を作る
合格条件は単純です。重い処理が失敗しても、同じマシンの別業務が継続する。実行者と費用を後から確認できる。再実行の判断材料が正本の保存先に残る。この3つを確認できたら、対象を広げます。
検証では成功したケースだけを残さないでください。上限を超えて終了した時刻、対象コマンド、再開の可否も記録します。AIの実行ログと人の判断を同じ案件記録へ置けば、翌朝の担当者が「続きから動かすか、最初からやり直すか」を決められます。エージェントの会話履歴だけに判断材料を閉じ込めないことが大切です。
リスクと限界
メモリ上限は、誤ったコマンドや外部送信を防ぐものではありません。利用者の識別も、承認そのものを代替しません。Claude Codeの権限設定、サンドボックス、作業ディレクトリの境界は引き続き必要です。
また、今回のリリースノートは機能の追加と修正内容を示していますが、あらゆるLinux環境での推奨値までは示していません。上限値を記事や他社事例からコピーするのは悪手です。自社の処理を測って決めてください。
最初の一手
まず、過去にPCやサーバーを重くしたビルドを1つ選び、検証環境でメモリのピークを測ります。設定変更はその後です。AIへ仕事を委譲するなら、「何をさせるか」と同じくらい「どこで止めるか」を先に決める。v2.1.233は、その境界を実装できる更新です。
一次情報
実装メモ：記事中の機能名と修正内容は、2026年8月16日に上記公式情報で確認しました。メモリ上限はLinux向けの任意設定です。具体的な上限値は、実環境の計測結果に合わせて決めてください。