ローカルLLMにどこまで任せられるか。Qwen3.8 27BをMacで1週間試す

戸田さんがローカルLLMを試したきっかけは、Claude CodeやCodexといったコーディングエージェントのトークン使用量でした。戸田さんは毎日これらのツールを使っていますが、使えば使うほどトークンを消費する構造になっていると話します。

コーディングエージェントはプランごとに使える量の上限が決まっていて、使い切るとしばらく待たないと使えません。戸田さんの場合、使っているうちにやりたいことが増え、すぐ上限に達して、結局やりたいことを諦める場面が多かったといいます。

一方で最近は、自分のパソコンの中だけで動かすローカルLLMがかなり賢くなってきています。戸田さんは「全部でなくても一部はこちらに任せられるのでは」と考え、1週間、自分のMacの中だけでさまざまなタスクをローカルLLMに投げてみました。

ChatGPTやClaudeを普段使うとき、モデルの計算は遠くのサーバーで走っていて、手元のパソコンは入力を送り、返ってきた結果を表示しているだけです。

これに対して、モデルの重みと呼ばれるファイルを自分のパソコンにダウンロードし、手元だけで動かすのがローカルLLMです。定義はいろいろあるものの、番組ではこの意味で使うと戸田さんは断っています。

戸田さんが挙げるローカルLLMの利点と欠点は、次のように整理できます。今回のモチベーションは、利点のうち「お金がかからず、トークンが消費されない」点でした。

今回の実験環境として、戸田さんは以前番組で紹介した自作ハーネスLocalRiguとは別に、OSSとして公開されているQwen CodeQwen Code ── アリババのQwenチームが公開しているオープンソースのコーディングエージェント。ターミナル上でモデルにコードの読み書きやコマンド実行をさせる仕組みを提供しますを使いました。以前は上位のエージェントがタスクを切り出していましたが、今回は切り分けを人間が担っています。

モデルは、アリババが公開するQwenシリーズの最新版Qwen3.8の27Bを、4ビットに量子化量子化 ── モデル内部の数値の精度を落として、ファイルサイズやメモリ使用量を減らす処理。品質は多少下がる代わりに、家庭用のマシンでも大きなモデルを動かしやすくなりますしたものです。戸田さんは量子化を「圧縮して使いやすくするイメージ」と説明し、メモリ64GBのM3 Macに載せて動かしました。

戸田さんがローカルLLMに任せたタスクは、大きく分けて3種類です。

実際に試すと、短いタスクは最初から問題なく動きました。止まったのは、長め・大きめの仕事を任せたときです。

大きめのタスクを投げると、数分間フリーズしたように止まり、待ってもファイルはできていませんでした。ログを見ると、エージェントは同じ作業を最初からやり直していました。

戸田さんが最初に疑ったのは、4ビット量子化によるモデル品質の低下でした。公開ベンチマークでは良い精度が出ても、手元で量子化版を動かすとうまくいかない、という経験はローカルLLMを触る人によくあるからです。

ところが生成ログを洗っても、的外れな内容や、同じ語句を繰り返すレペティションレペティション ── 言語モデルが同じ単語や文を何度も繰り返し出力してしまう現象。モデルの品質や生成設定が原因で起こることがありますは起きていませんでした。調べた結果、ループに見えた原因は品質ではなく、別の3つにありました。

1つ目の原因は、1回の応答で出せる長さの上限設定です。ここで関わるのがツールコールツールコール ── LLMがファイル操作やコマンド実行などの外部機能を呼び出す仕組み。モデルは「どのツールを、どの引数で使うか」をテキストとして出力し、それを実行側が解釈して動かしますです。

LLMは本来テキストしか出力できません。ファイルを書き込むときも、「このパスに、この中身でファイルを書き込むツールを使って」という指示をテキストで出力しています。そのため、ツールコールは頭から最後まで出力し切らないと実行されません。

戸田さんはQwen Codeの1回の応答の上限を、デフォルトに近い8000トークンほどにしていました。トークンはモデルが文章を扱う単位で、日本語なら1文字から数文字分のイメージです。

8000トークンは普通のチャットや短いタスクでは気になりません。しかしアプリ開発のような長いタスクでは、それまでに読み込んだ量も多く、ファイルを書くツールコールが上限に引っかかって途中で切れていました。

モデルはきちんと生成しているのに先へ進まない、という「ループ」の正体はこの繰り返しでした。対策は単純で、上限を上げることです。

2つ目の原因は、会話履歴の自動圧縮です。Claude Codeなどにもある仕組みで、会話が長くなると古い部分を要約して圧縮し、モデルが扱える範囲を空けます。

ただ、この圧縮のときに「どのファイルを読んだか」という情報が落ちることがあったといいます。エージェントはファイルを編集するとき、先に読んでから編集します。その間に圧縮が入ると読んだ記憶が失われ、編集に失敗します。

編集に失敗したエージェントはまた読むところから始めるため、これもループのように見えます。戸田さんは、この問題もトークンの上限を伸ばすことで解決できたのではないかと考えています。

3つ目の原因は、戸田さん自身の凡ミスです。並行して、ローカルLLMを使う別のアプリも動かして開発していたため、MacBookの64GBのメモリを超えてしまい、処理が落ちて再起動を繰り返していました。

3つの原因を並べると、次のようになります。

戸田さんによれば、一連の問題のいちばんの理由はコンテキストが短かったことでした。デフォルト設定のままだと短いため、しっかり伸ばす必要があります。

あわせて戸田さんは、エージェント向けのルールファイルに工夫を加えました。Claude.mdやagents.mdにあたるファイルに、「大きいファイルを扱うときは一度に書かず、80行ずつぐらいに分けて書く」という指示を入れたのです。

コンテキストを伸ばしても、指示や過去の対話履歴、どうしても読む必要のある長い資料がその中を占めます。そのため、1回の編集の単位を小さく区切ることで、上限に引っかかりにくくする狙いがあります。

戸田さんは副次的な効果として、1回の応答が返ってくる時間が短くなり、途中で間違っているときに検知しやすくなる点も挙げています。

設定を直したあとのローカルLLMの実力について、戸田さんは完全に主観だと断ったうえで、GPT-4oくらいのことはやってくれる感覚だと話します。

FableやCodexのSolといった現在の最新クラウドモデルと比べれば、レベルは下がります。それでも、少し前に最前線にいたモデルと同じくらいのことが、自分のMacの中で課金なしで回るのは大きな変化だと戸田さんは見ています。

設定さえ整えれば普通に任せられたのは、簡単なアプリを1本作る、議事録を整理する、Webで検索して資料の要点をレポートにまとめる、といった仕事でした。

一方でローカルLLMの弱点は、やはりコンテキストの長さです。伸ばすほどメモリを食うため手元のマシンでは限界があり、伸ばしても長い内容をうまく扱えないことがあります。

その例が、アンドレイ・カーパシーアンドレイ・カーパシー ── OpenAIの創業メンバーで、元テスラのAI部門責任者として知られるAI研究者。AIに関する解説や新しい使い方の提案で広く影響力を持っていますが提唱した「LLM Wiki」です。LLMに多くの資料を読み込ませ、Wikipediaのような知識のまとまりを作らせる取り組みですが、ローカルLLMではうまく動きませんでした。

戸田さんは締めくくりとして、デフォルト設定では動かずに苦労したものの、直してみれば十分使える精度だったと振り返ります。ローカルLLMが同じことを繰り返していると感じたら、まずハーネスの設定とコンテキストの長さを見直すことを勧めています。

まとめ

Qwen3.8 27BをMacで1週間動かした戸田さんの結論は、設定さえ整えれば簡単なアプリ開発や資料整理は十分に任せられる一方、大量の資料を横断する長いコンテキストの仕事にはまだ限界がある、というものでした。

• ループに見えた不具合はモデル品質ではなく、応答の長さの上限・会話履歴の圧縮・メモリ不足が原因だった
• ルールファイルで「80行ずつ書く」と指示し、1ターンで終わる単位に仕事を区切ると安定しやすい
• 体感ではGPT-4o程度の仕事が、手元のMacで課金なしに回る
• LLM Wikiのように大量の資料を横断する作業は、ローカルLLMにはまだ厳しい