「Claude Codeを無料で、自分のPCだけで動かせる」って話、最近よく見かけるよね。11月4日に、それを自腹で確かめた検証記事が開発者向けの投稿サイトDEV Communityに2本続けて出た。ハルは両方の数字を最後まで追いかけてみたよ。結論から言うと、小さな機械だと「失敗したのに、成功したみたいな顔で終わる」。しかも原因は2本とも同じだった。手元でAIを動かすソフトには「一度に読める量の枠」が最初から決まっていて、それが狭すぎたせいで、エージェントへの長い指示がエラーも出ないまま途中で切り捨てられていたんだ 🤔
日本の会社にとって：「社外にデータを出したくないから、社内のPCでAIに書かせよう」と考えている会社は、ここが落とし穴だよ。安いPCをそのまま使うと、AIが仕事をしていないのに「終わりました」と返ってくることがある。だから導入の前に、出来上がった物を人が確かめる手順を決めておくのが先なんだよね。
約200ユーロのミニPCとMac M3に、同じ3手の宿題
1本目を書いたのは、ポルトガルのNextlaneでStaff AI Engineer（AI開発の上級技術者）を務めるDiogo Soaresさん。本人のDEV Community投稿によると、Claude Code 2.1.311を人が操作しない自動実行で動かし、つなぎ先をAnthropicのクラウドからOllama 0.35.0（手元のPCでAIモデルを動かす無料ソフト）に替えたそうだよ。使ったモデルはQwen2.5-Coder 7BとGemma 4 E4Bの2つ。宿題は「回文かどうかを判定する小さなPythonファイルを作って、確認用のテストを書いて、実行する」という3手だけ。これを5通りの構成でやらせたんだ。
結果は、成功がMac M3の1回だけ。並べるとこうなる。
- 基準にしたクラウドのClaude Opus 5.5（Proプラン）：3手で10.6秒
- Mac M3（メモリ16GB）＋Gemma 4 E4B（枠を32kに設定）：3分33秒で成功
- ミニPCの内蔵GPU＋Gemma 4 E4B：27分たったところでGPUがクラッシュ
- ミニPCのCPUだけ：45分の上限で打ち切り（ファイルが出来るまでで約19分）
- Qwen2.5-Coder 7B（枠32k）：9分かけてコード自体は正しく書けたのに、道具を呼び出す形式が違っていてファイルは出来なかった
差がつくのは速さだよ。トークン（AIが文章を区切って数える単位）で比べると、指示を読み込む速さはCPUで毎秒11〜14、内蔵GPUで19〜37、M3で190〜230。答えを書く速さはCPUで約3、内蔵GPUで3.7〜7.5、M3で13〜21だった。CPUだと13kトークンを読むだけで15〜20分かかる。さらにミニPCでは約6分ごとに接続が切れていて、これはClaude Codeが「5分間なにも返ってこなければ諦める」仕組みと合っていたんだって。本人の結論は「低電力のミニPCを、Claudeの安い代わりにする価値はない。Apple Siliconか本物のGPUで、学習用・小さな私的作業・オフライン作業に使うなら妥当」というものだった。
「失敗なのに成功」はなぜ起きたのか
ここが今回いちばん大事なところ。Claude Codeみたいなハーネス（モデルを動かすエージェントの実行基盤）は、道具の使い方やルールをまとめた長い指示を毎回AIに送っている。Soaresさんの計測では、最初の指示が約12,900トークン、2手目は約19,000トークンあった。ところがOllamaは、VRAM（GPU専用のメモリ）が24GiB未満の機械だと、既定の枠が4kしかない。12,900トークンのうち残るのは約2,000トークン、つまり6分の1だけで、残りは何の警告もなく捨てられていたんだ 💡
指示の大半が抜け落ちるから、最初の1回は、ファイルを作る道具を呼び出す代わりに、呼び出しの文面を文字として書いただけで止まった。ファイルは出来ていないのに、Claude Codeはエラーを出さずに終わったんだよ。Soaresさんは「失敗したのに成功と報告するのは、クラッシュより悪い」と書いている。ハルもここは本当にそうだと思った。クラッシュなら気づけるけど、黙って成功のふりをされると、だれも気づかないまま次の作業に進んじゃうからね。
落とし穴はほかにもあった。Qwenは対応機能の一覧に「tools（道具の呼び出し）」を挙げているのに、実際にはエージェントが待っている決まった形式の呼び出しを一度も出さなかった。Soaresさんは、「対応している」という申告は、求める形式で呼び出せる証拠にはならないとまとめている。Gemmaが書いたテストは、確認の部分を「失敗しても無視する」書き方で包んでいたので、テストが落ちても終了の合図は「成功」になる。見た目は合格でも、中身は何も確かめていなかったんだ。しかもOllamaの読み込み済みの内容を使い回す仕組み（キャッシュ）が2手目で効かず、Macは19,000トークンを最初から全部読み直していた。
おまけの話もひとつ。Soaresさんが「無料Claude Code」をうたうYouTube動画を6本調べたところ、「Opusが6か月無料」と宣伝しているものが混じっていた。本人はこれをセキュリティ上の危険信号として扱い、リンクは開かなかったそうだよ。「無料」の文字に釣られて変なリンクを踏まないこと、大事だね。
銀行台帳のバグ直しで、Mac・RTX 5080・DGX Spark・クラウドを比べた
2本目は、DEV Communityに検証記事を出した開発者のNikolai Girchevさん。投稿記事では、GitHubで公開している自作の試験「minibank-bench」を使っている。約700行のPythonで書いた銀行の台帳に、「月次明細が、送金した額を送った時のレートではなく今のレートで計算し直してしまう」というバグがある。これを各構成のエージェントに直させて、隠しテスト20本に通るかどうかと、わざと仕込んだ間違った直し方9個を見抜けるかどうかで採点したんだ。
- クラウドのOpus 5.5：91秒・0.96点・$0.30
- クラウドのCodex（GPT-6.1-sol）：101秒・1.00点・約$0.14
- クラウドのDeepSeek V4.1 Flash：112秒・1.00点・$0.008（著者の計算ではOpusの36分の1の費用）
- MacBook M5（32GB）のGemma 4 12B：575秒・0.21点（隠しテスト12/20）。ただし0.21点まで届いたのは10回中3回だけで、回ごとの点は−0.17〜0.21とばらついた
- Qwen3 Coder 30B A3B：毎秒52トークンと速いのに0点。道具を50回呼び出したあげく、わざと置いた罠の変換関数に引っかかった
- Qwen3.8 27B：20分たっても編集0回
ここでも原因は同じ「枠」だった。LM Studio（Ollamaと同じく手元でモデルを動かすソフト）は、一部のモデルを既定の8192トークンの枠で読み込んでいた。一方で、使ったエージェントのOpenCodeは1手ごとに約15kトークンを送る。結果、エラーを出さないままエージェントが壊れていたんだ。著者は枠を65536に広げて測り直している。2本の記事が、別々の道具で同じ穴に落ちていたのが面白いよね 👀
大きな機械ではどうだったか。RTX 5080を積んだノートPCのQwen3.6-35B-A3Bは、設定を詰めると17kの枠で毎秒21→102トークン、42kの枠で9.5→94トークンまで速くなった。でも点数は0.29→0.31しか上がらなかった。速くはなったけど、賢くはならなかったわけ。NVIDIAの卓上AIマシンDGX Spark上のThinkingCap-Qwen3.8-27Bは、10分の上限ありだと0点、上限なしだと987秒・0.92点と、Opusに近い点を出した。ただし時間は約16分で、Opusの約1.5分とは大差がある。Qwen3.8-Flash-Next（125BのMoE）は0.96点だったけど、Opusより6〜7倍遅く、128GBのメモリのうち約96.2GiBを占有した。著者の結論は「ノートPCに載る大きさのモデルは、見ればわかるバグしか直せない」「この課題なら置き換えられる。実際のプロジェクトではわからない」というものだった。
本人たちの断り書き、Ollamaの対応、ハルの線引き
Girchevさん自身も、課題がPythonの1件だけで、構成ごとの試行は1〜2回しかないと断っている。似たようなローカルモデル同士の差までは判定できない、ということだね。表にも食い違いがあって、MacBookのQwen3 Coderは最初の表だと472秒・0点なのに、まとめの表だと344秒・0.14点（6回で0〜0.14点）になっている。だから細かい順位はあまり信じすぎないほうがいい。注意点はもうひとつある。試したモデルの一部はabliterated（危ない頼みを断る仕組みを外した改変版）で、エージェントのpiは、既定では確認なしでコマンドを実行してしまう。この組み合わせは、コンテナ（PC本体から隔離された箱）の中で動かすよう著者は勧めている。ちなみに記事の推敲をQwen3.6-35B-A3Bにやらせた感想は「答えは速く、部屋はよく暖まり、だいたい害になる」。正直すぎて笑っちゃった 😂
実行ソフトの側の動きも見ておこう。Ollamaのリリースノートによると、11月3日のv0.40.14では、Ollama経由でClaude Codeを起動するときに、モデルごとの「書ける量の上限」を渡すよう直した。これで、Claude Code経由でクラウドのモデルを使っても、既定の128kの上限に引っかからなくなったという。続くv0.40.15（配布物の日付は11月5〜6日）では、コード・エージェント向けのMiMo V2.6（9B）を追加し、Kimi Code CLIからも同じ手軽さで起動できるようにした。QwenシリーズのQwen3とQwen3.5が長い文章を扱えるようにする技術（YaRN）にも対応した。ただし、道具の呼び出し方や既定の「読める量の枠」を直したとは書かれていない。つまり今回の2本が踏んだ穴は、少なくとも説明文の上ではまだ開いたままだよ。そもそもClaude Codeにつなげる仕組み自体は、v0.14.0（2026年1月）からあった。
ハルの線引きはこう。手元のAIでエージェントを動かすなら、まず「読める量の枠」を、ハーネスが送る指示の量より大きくしておくこと。そのうえで、終わったと言われたら、ファイルが本当にあるか、テストがわざと間違えたときにちゃんと落ちるかを人が確かめること。機械はApple Siliconか本格的なGPUを選び、小さな作業やネットにつながない作業から試すこと。費用を下げたいだけなら、今回の数字を見る限り、クラウドの安いモデルのほうが速くて確実な場面が多いんだよね。ただし社外にデータを出せるかどうかは、会社ごとに決めることだよ 🛠️
