11月6日、ZDNetが「I tried replacing Claude Code with a local AI stack that's completely free」と題した記事を公開した。Qwen・Ollama・OpenCodeを組み合わせた完全無料のローカルAIスタックでClaude Codeの代替を検証した内容で、128GB RAM搭載のM4 Max Mac Studioという潤沢なハードウェアを用意し2週間近く費やした結論は「小さなプロジェクトには使える。でも大きなプロジェクトには、引き続きClaude Codeを使う」というものだった。
結論から言う:デバッグで詰む
著者は数十年のコーディング経験と1年以上のAIエージェントコーディング経験を持つ。その人物が潤沢な環境を用意し、2週間近く費やした末の結論はこうだ。
「小さなプロジェクトには使える。でも大きなプロジェクトには、引き続きClaude Codeを使う」
ローカルAIコーディングの壁は「コンテキスト」にある。今回のスタックで確保できたのは64,000トークン。Claude Codeでは100万トークンのコンテキストを1晩に5〜6回使い切るという。反復的なデバッグには、途中経過・仮説・テスト結果を積み重ねながら「気づき」を得るプロセスが必要で、64Kトークンではその過程を維持できない。
この「コンテキスト格差」は、Claude Codeの料金体系とも表裏一体だ。Claude CodeはAnthropicのサブスクリプションまたはAPI従量課金で動作し、大規模コンテキストの維持にはそれなりのコストがかかる。ローカルスタックはランニングコストがゼロである反面、モデルサイズとメモリ容量の制約から逃れられない。「タダより高いものはない」をコンテキスト量で体現した検証と言える。
構成スタック
| コンポーネント | 役割 |
|---|---|
| Ollama | ローカルでLLMを動かすランタイム |
| OpenCode v2.2.5 | AIエージェントのコーディングハーネス |
| qwen3-coder-next:q4_K_M | メインのコーディングモデル(800億パラメータ、MoE) |
| gemma4:26b | マルチモーダル補助(スクリーンショット解析用) |
Qwen(正式名:Tongyi Qianwen=「千の問いから真実を」)はAlibaba製のモデルで、コーディングエージェント向けに設計されている。800億パラメータのMoE(Mixture of Experts)モデルだが、一度に使うアクティブパラメータは30億のみで動作が速い。MoEアーキテクチャは全パラメータを常時稼働させず、入力に応じて必要な「専門家」サブネットワークだけを呼び出す仕組みで、大規模モデルをローカルで動かす際のメモリ・速度のトレードオフを緩和する点でローカルAIブームを後押ししている技術でもある。ただし、テキスト応答に中国語が混入することがある。
Gemma4:26bはマルチモーダル対応でスクリーンショットを解釈できるが、コーディング能力はQwenより劣り、暴走しやすいため補助的な使用にとどめた。

OpenCode経由でQwenと対話している画面
失敗:PDF整理アプリに5日間溶かした
最初のプロジェクトは、macOS 26のオンデバイスAIを使ってPDFを自動分類するアプリの構築だった。このmacOSバージョンにはドキュメントの意味を解析するオンデバイスAI機能が含まれているが、APIが新しすぎてドキュメントがほぼ存在せず、AIの学習データにも含まれていない。
5日間費やして、1枚のPDFの内容を読み取ることには成功した。しかし100枚・1000枚を繰り返し処理するためのメモリ管理・セッション管理は、64Kコンテキストのローカルスタックには荷が重すぎた。デバッグを繰り返すたびにコンテキストが枯渇し、AIが状況を見失う。著者はここで5日間を「wasted and bummerific week」(無駄にしてしまった、最悪な1週間)と表現し、撤退を決めた。
成功:スクリーンショットのリネームアプリ
方針を転換し、枯れた技術だけを使うプロジェクトに絞った。ファイル一覧表示、ディレクトリ選択、画像表示、テキスト入力——いずれもmacOSの歴史的に安定したAPIだ。
作ったのは、スクリーンショットを1枚ずつ表示してリネームできるMacアプリ。著者は記事1本あたり20〜50枚のスクリーンショットを撮影しており、CleanShot Xが生成する「CleanShot 2026-10-27 at 3.26.15 PM@2x」という名前を整理することが長年の課題だった。7,000枚以上の画像フォルダが手つかずのまま残っていたという。

実際に動作したスクリーンショットリネームアプリ
完成まで約6日かかった。そのうち4日間は、左ペインにファイル一覧を表示するだけの機能で詰まった。最終的な解決策は「過去のコンテキストをすべて捨て、OpenCodeを新規セッションで起動し、ファイルリスト表示だけを単独で依頼する」だった。デバッグではなく、リセットによる解決だ。
ローカルAIコーディングで生き残るためのプラクティス
著者が2週間の試行錯誤から導いた実践的なルールを以下にまとめる。
- 新しい修正・機能・問題ごとにセッションをリスタートする。 コンテキストを小さく保つことが最重要
- モデルはOpenCodeに自動選択させない。 コマンドラインのショートカットで毎回1モデルだけを明示的に指定する
- 調査とコーディングは完全に分離する。 AIに調査させたら結果を
.mdファイルに書かせ、別セッションでそのファイルを読み込ませてコーディングを開始する AGENTS.mdは極限まで小さくする。 長い指示ファイルを読み込むだけでコンテキストが圧迫される- パーミッションを必ずすべて確認させる。 ローカルモデルはシェルコマンドを気軽に実行し、ファイルやディレクトリを削除することがある。面倒でも逐一承認を求める設定にする
- デバッグが必要になったら覚悟を決める。 デバッグはローカルAIの最大の弱点で、各テスト・観察のたびにセッションを再起動しながら手取り足取りで進める必要がある
これらのプラクティスは、いずれも「コンテキストをいかに節約するか」という一点に収束している。クラウドAIでは意識せずに済むコンテキスト管理が、ローカルAI運用の中心的な技術的課題になるという構造は、ローカルAIへの移行を検討する開発者が事前に把握しておくべき点だろう。
「Claude Codeを捨てられるか」への答え
著者は3つの問いに対してこう答えている。
シンプルなMacアプリは作れるか? → Yes。実際に今も使っているアプリができた。
高機能なアプリは作れるか? → No。大きなアプリには大きなコンテキストが必要で、64Kトークンでは到底足りない。
Claude Codeを捨てるか? → No。2週間かけて作れたのはリネームアプリ1本だけで、手書きなら数晩で書けたものだ。非プログラマーへの推奨も「絶対にNo」とした。
詳細はI tried replacing Claude Code with a local AI stack that's completely freeを参照していただきたい。