始まりは「どうせ動くだろう」という過信
「AIエージェントを複数動かして、個人開発を自動化しよう」
そう思い立ったとき、私の手元にあったのは MacBook Air 2017（Intel Core i5 / 8GB RAM）だった。
「まあ、CLIツールだし。テキスト処理がメインだし。動くでしょ」
——この楽観主義が、のちに私を深夜のメモリ監視沼へと引きずり込むことになる。
Claude Code を使ってAIエージェントを組み合わせた自動化フローを組んでいる。複数のエージェントがタスクを分担して動き、記事生成・コード生成・レビュー・投稿まで一連の流れを自律的にこなすような仕組みだ。詳しい構成については ai-concierge-kei.com にまとめているので興味のある方はどうぞ。
問題は、これを8GBマシンでやろうとしたことである（そりゃそうだ）。
8GB RAMとAIエージェントの壮絶な戦い
CPUファンが悲鳴を上げた瞬間
最初の異変は、Claude Code を立ち上げてエージェントに「このリポジトリ全体を解析して」と投げた瞬間だった。
MacBook Air のファンが回り始めた。いや、「回り始めた」という表現は正確ではない。覚醒したのだ。
# CPU温度確認（Intel Mac / powermetrics使用）
sudo powermetrics --samplers smc -n 1 | grep "CPU die temperature"
# CPU die temperature: 94.50 C
94.5℃。夏の屋外より熱い。
Slack の通知音は完全に掻き消されていた。エージェントが「タスク完了しました」と言っている横で、私はファンの爆音の中、口パクで「え、なに？」をやっていた。
しばらくすると、エージェントの返答が妙に遅くなった。明らかに考えすぎている。いや、正確にはスワップしているのだ。
# メモリ使用量確認（Mac）
top -l 1 | grep "PhysMem"
# PhysMem: 7902M used (1792M wired), 290M unused.
290MB。残り290MB。
8GBのうち290MBしか残っていない状態で「複数エージェントを並列実行」などという夢を見ていたわけだ。なんというロマンチストだろう（笑えない）。
メモリ使用量のリアルタイム監視が趣味になった
こうなると人間の本能が働く。「監視しよう」と。
# Claude Code プロセスのCPU・メモリ確認
ps aux | grep -E "claude|node" | grep -v grep | awk '{print $1, $2, $3, $4, $11}'
これを5分おきに打つのが日課になった。趣味と言えば趣味だが、健全な趣味とは言い難い。
エージェントが複数立ち上がると、node プロセスが5〜6個並ぶ。それぞれが100〜400MBのメモリを食っている。合計すると余裕で2GBを超える。
あるとき、エージェントの一匹（一体？）が突然応答しなくなった。ログを見ると、タスクの途中でフリーズしている。メモリが足りなくて処理を諦めたらしい。黙ってサボり始めたのである。
仕方なく強制終了する。
# 暴走したClaudeプロセスをまとめて駆逐する
kill $(ps aux | grep claude | awk '{print $2}')
このコマンドを打つ回数が、週に3〜4回を超えたあたりで「さすがに運用として成り立っていない」と気づいた（遅い）。
同じ悩みを持つ方は多いはず。「AIツールを使い倒したいが、PCが追いつかない」という現実は、M1/M2 Mac を持っていない個人開発者には切実な問題だ。あなたのPCは何GB？
試行錯誤の末に見つけた「軽量化5つの戦術」
半月ほどCPUと格闘した結果、なんとか運用できるレベルに落ち着いた。以下が、8GBマシンでAIエージェントを動かすための実用的な戦術だ。
1. モデルをフル活用しない（超重要）
Claude Code はデフォルトで Sonnet などの高性能モデルを使う。高性能なのは良いが、レスポンスが長く、処理も重い。
軽量なタスク（フォーマット変換、ファイル分類、定型テキスト生成など）には Haiku を使うよう明示的に指定する。
# モデルを明示してコスト・負荷を下げる
claude --model claude-haiku-4-5-20251001 "この文章を箇条書きにまとめて"
Haiku は体感で Sonnet の6〜7割のパフォーマンスだが、メモリ消費とレスポンス長が抑えられる。単純作業エージェントを Haiku に切り替えるだけで、並列実行時のメモリ圧迫がかなり改善された。
モデル選定の詳細については、Claude Code CLI のAPIコスト最適化についてまとめた記事も参考になる。
2. コンテキストウィンドウを意識的に削る
「リポジトリ全体を読んで」とエージェントに投げると、数千行のコードを一気に読み込む。これがメモリキラーの筆頭だった。
対策は「読む範囲を限定する」こと。
# 特定ファイルのみ渡す（リポジトリ全体は渡さない）
claude "以下のファイルだけレビューして" < src/specific_module.py
また、長い会話セッションは意図的にリセットする。コンテキストが積み上がるほどメモリ消費は増える。「新しいタスクは新しいセッションで」を鉄則にした。
3. 並列実行を諦めてシリアル実行に切り替える
「エージェントを並列で走らせて効率化！」という夢は、8GBでは早々に諦めた。
2つのエージェントが同時に動くと、合計メモリが6〜7GBに達し、OS 自体がモタつく。ブラウザタブを全部閉じて、Slack も落として、やっと Claude Code が快適に動く、という状態である。
そこで採用したのがシリアル（直列）実行だ。タスクをキューに積んで、1つが終わったら次を実行する。
#!/bin/bash
# シンプルなシリアル実行スクリプト
tasks=("task_a.txt" "task_b.txt" "task_c.txt")
for task in "${tasks[@]}"; do
echo "▶ 実行中: $task"
claude < "$task"
echo "✅ 完了: $task"
sleep 3 # プロセスがきれいに終了するのを待つ
done
これで並列実行の2倍の時間はかかるが、マシンがフリーズしなくなった。スピードより安定性を選ぶ、老成した判断である（諦めとも言う）。
4. アイドル時間を活用したバッチ処理
AIエージェントに「重い処理」をさせるなら、自分がPCを使っていない時間を狙う。
夜中の2時、あるいは昼食中。そういったアイドルタイムにバッチジョブを仕込む。
# cron で深夜2時に実行
# crontab -e で以下を追加
0 2 * * * /path/to/agent_batch.sh >> /path/to/agent.log 2>&1
この「人間が寝ている間にエージェントが働く」という体制を確立してから、昼間のファン爆音に悩まされることが激減した。
エージェントも夜型になってしまったが、文句は言わない（言えないし）。
5. ローカルLLMとの使い分け
超軽量タスクには、Ollama などでローカル LLM を動かす選択肢もある。
# Ollama でローカルモデルを使う
ollama run llama3.2:1b "この文章の誤字を直して"
1B〜3B パラメータのモデルなら、8GB マシンでも比較的快適に動く。API コストもゼロ。
ただし、品質は Claude と比べると差があるため「テキストの整形」「フォーマット変換」「簡単な要約」などに限定して使っている。判断が必要なタスクは Claude に任せる、という役割分担だ。
実際のシステム負荷グラフ（コマンド例）
実運用で使っているモニタリングコマンドをまとめておく。同じ悩みを抱えるマシンをお持ちの方はぜひ。
# 1. リアルタイムメモリ監視（1秒おき）
while true; do
top -l 1 | grep "PhysMem"
sleep 1
done
# 2. Claude / Node プロセスの現在の負荷
ps aux | grep -E "claude|node" | grep -v grep \
| awk '{printf "PID: %s | CPU: %s%% | MEM: %s%% | CMD: %s\n", $2, $3, $4, $11}'
# 3. CPU温度（Intel Mac）
sudo powermetrics --samplers smc -n 1 2>/dev/null | grep "CPU die temperature"
# 4. スワップ使用量の確認
sysctl vm.swapusage
# 5. ゾンビプロセスの確認（動いているつもりで止まっているエージェント）
ps aux | awk '$8 == "Z" {print $0}'
5番目のゾンビプロセス確認は、エージェントが「サボっているのか死んでいるのか」を判定するのに重宝している。ゾンビになっているエージェントを見つけたときの気持ちは、人事担当者に近い何かを感じる。
結論: 低スペックPCはAI開発の最高の反省材料だった
半月間、8GB MacBook Air でAIエージェントを運用してみて得た知見を振り返る。
技術的に得られたもの:
- モデル選定の重要性が身に染みた — 高性能モデルを使えばいいというわけではない。タスクに合ったモデルを選ぶことが、コストとパフォーマンス両面で重要だ。
- コンテキスト管理は最重要スキル — 大きなコンテキストを渡せば良い結果が出るわけではなく、必要な情報だけを渡す設計が品質を上げることもある。
- 並列化は銀の弾丸ではない — リソースが潤沢なときは並列化が効くが、ボトルネックが別にある場合はシリアル実行の方が安定する。
- 監視なくして運用なし — エージェントは黙ってサボる。プロセス監視とログ出力は最初から仕込んでおくべきだった。
高性能な M3 Mac Pro があれば、こんな苦労はしなかったかもしれない。でも、制約があるからこそ「最小限で動かす設計」を真剣に考えた。
制約は思考を強制する。
今ではM1以上のMacに乗り換えた知人に「並列でガンガン動かせる」と言われても、「でもコンテキスト管理ちゃんとしてる？」と聞き返せる自信がある。
CPUファンの爆音は、良い師匠だった（騒がしいけど）。
より詳細なAIエージェント構成やコスト最適化の知見は ai-concierge-kei.com でも発信しているので、興味のある方はのぞいてみてほしい。
低スペックPCで格闘している仲間、コメントで語り合いましょう。