2026/06/08

Claude CodeをローカルLLMで動かす

4ヶ月前のOpenHands実験から時間も経ったので、コーティングエージェントで使えるローカルLLMでそれなりに使えるものがないかなと探してみたところ、 今日の時点ではQwen3.6-27Bが良いらしいということわかったので、試してみました。

利用するのは

  • llama.cpp
  • Claude Code
の2つです。

llama.cppの準備


https://github.com/ggml-org/llama.cpp からコードを取得します。今回は rev. f71af352a52b8efe824c7a698d0632afa4794c01 を使いました。cloneしたときの最新版です。

今回は https://github.com/ggml-org/llama.cpp/blob/master/docs/build.md を読んで、GPU対応のllama.cppをビルドしました。

ビルド環境にCUDA関連のツールが必要なので、NVidiaの「CUDA Toolkit 13.3 Downloads」ページから「deb (network)」を選んで、記載されている方法でインストールしました。

OpenBLASもUbuntu24.04の標準パッケージをインストールした上で、以下のコマンドでビルドしました。

cmake -B build -DGGML_BLAS=ON -DGGML_BLAS_VENDOR=OpenBLAS -DGGML_CUDA=ON  -DCMAKE_CUDA_COMPILER=/usr/local/cuda/bin/nvcc -DCMAKE_CUDA_ARCHITECTURES="120" -DCUDAToolkit_ROOT=usr/local/cuda
cmake --build build --config Release -j 8
その後、実行すればLLMの準備は完了です。
export LLAMA_CACHE="model-cache/unsloth/Qwen3.6-27B-MTP-GGUF"
build/bin/llama-server \
    -hf unsloth/Qwen3.6-27B-MTP-GGUF:UD-Q2_K_XL \
    -ngl 99 --fit on -c 65536 -fa on -np 1 \
    --spec-type draft-mtp --spec-draft-n-max 2 \
    --host 0.0.0.0 \
    --cache-type-k q4_0 \
    --cache-type-v q4_0
GPUのメモリは16GBあるのですが、Q2にして、かつ、cache-typeをq4_0にしないと、コンテキスト長を65536まで伸ばせませんでした。131072だとメモリ不足で落ちます。 98304でもギリギリ動くようです。

Claude Codeの準備


Claude CodeはDockerコンテナ内で動かします。
FROM ubuntu:24.04
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y \
    curl \
    ca-certificates \
    gnupg \
    nodejs \
    npm \
    && rm -rf /var/lib/apt/lists/*
WORKDIR /workspace
RUN npm install -g @anthropic-ai/claude-code
ビルドは
docker build -f Dockerfile -t claude-code .
で行い、起動は
touch .bash_history # 不要かも?
docker run -it --rm \
  --name claude-code \
  -v "$(pwd)/workspace:/workspace" \
  -v "$(pwd)/.claude-home:/root/.claude" \
  -v "$(pwd)/.bash_history:/root/.bash_history" \
  -e ANTHROPIC_API_KEY=llamacpp \
  -e ANTHROPIC_AUTH_TOKEN=llamacpp \
  -e ANTHROPIC_BASE_URL=http://xxx.xxx.xxx.xxx:8080 \
  -e ANTHROPIC_MODEL=qwen3.6-27b \
  -w /workspace \
  --gpus all \
  claude-code
で行います。ANTHROPIC_BASE_URLの部分は実行環境のホストのIPアドレスを指定します。たぶん 127.0.0.1では動きません。

Dockerコンテナ内に入るので、そこで、claudeとタイプすればあとは普通に使えます。

ただし、Claude CodeがWebサーチできないので、なにか設定が抜けているかもしれません。

実験したときのClaude Codeはv2.1.168でした。

使ってみると?


思ってたより普通に動きます。難しいことはできないかもしれませんが、
  • マンデルブロ集合を計算してASCIIで描画する。C++で書いて、cmakeでビルド環境まで作成
  • Pytorchを使ってMNISTのモデルを作って学習し、評価する。Pytorchの環境だけは通常のpip installでは適切なバージョンをインストールできなかったので、手動で作成
くらいは問題なく動きました。gitの操作も簡単なものであればできました。コードは長いので省略します。

このレベルならコーディングのお手伝いくらいならできそうです。 有料の強力なモデルとローカルLLMを適宜切り替えて使うのがコスト的には良いのかもしれません。

2026/02/14

OpenHandsをローカルLLMで動かす(その2)

1年くらい前にOpenHandsをローカルLLMで動かしてみましたが、ローカルLLMの能力が低くて今ひとつでした。

ローカルLLMの能力も少し上がってきたようですので、再度試してみることにしました。

ollmaの準備


前回と基本的には同じです。

今回はモデルにdevstral-small-2:latestを使ってみることにしました。

気をつける点は、コンテキスト長をデフォルトから変更するというところです。

まずollamaのdockerコンテナ内で /root/.ollama/models/DevstralSmall2Ctx16k というファイルを作ります。中身は
FROM devstral-small-2:latest
PARAMETER num_ctx 16384
です。作成後、
$ ollama create devstral-small-2-16k -f /root/.ollama/models/DevstralSmall2Ctx16k.Modelfile
にて、ollamaにモデルを認識させます。すると
$ ollama list
NAME                                           ID              SIZE      MODIFIED      
devstral-small-2-16k:latest                    3360cd1e87b5    15 GB     5 hours ago
のような行が追加されるはずです。

これでollamaの準備は完了です。

OpenHandsの準備


https://docs.openhands.dev/openhands/usage/run-openhands/local-setup に従って進めるだけです。 具体的には
$ uv tool install openhands --python 3.12
$ openhands serve
だけで完了です。事前にuvの準備は必要です。

次に、 http://localhost:3000/settings にアクセスして、AdvancedをONにしたうえで、以下のように設定します。 https://docs.openhands.dev/openhands/usage/llms/local-llmsを参考にしています。

設定名設定値
Custom Modelopenai/devstral-small-2-16k:latest
Base URLhttp://192.168.xxx.yyy:11434/v1
API Keyollamaで動いているので何でも良い
以上が設定できると、会話画面にて
hello
と入力すると、
Hello! How can I assist you today?
のように出力されます。

注意するところは、Custom Modelの設定値の最初をollama/ではなくopenai/とする点と、Base URLの最後を:11434ではなく:11434/v1にする点です。 もし間違うと、中途半端に動きます。指示を出す画面で例えば

hello
と入力すると、
{"name": "finish", "message": "Hello! How can I assist you today?"}
のようにjsonの文字列がそのまま画面上に出力されてしまいます。

以上でとりあえずは動くようになりました。しかし、なかなか言うことを聞いてくれません。コマンドを特定できているのに実行しなかった場合に「実行して!」と頼んでも

I cannot execute commands without a specific task or context. Please provide me with a clear instruction or task so I can assist you effectively. 
とか言われるので、コンテキスト長が16k程度では全然足りていないのかもしれません。

2026/02/11

RTX 5060 TiをUbuntu24.04で動かす

GeForce RTX 5060 Ti を Ubuntu24.04 のPCで動かそうとしたら、とても手間がかかったので、メモとして残しておきます。

ブート


CSM (Compatibility Support Module) ブートでは動かないです。UEFIによるブートにする必要があります。

確かデフォルト設定でUbuntu24.04をインストールしていたのですが、UEFIによるブートになっていませんでした。

そのため、どうにかしてUEFI用として550MiBのパーティションを作る必要があります。今回は運良く空き領域が残っていましたので、gpartedでパーティションを作りました。 フォーマットはfat32で、ESPフラグを付けます。

その後、マウントしてgrubのインストールをします。

$ sudo mkdir -p /boot/efi
$ sudo mount /dev/your-partition-name /boot/efi 
$ sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu
そして
$ ls -la /boot/efi/EFI/ubuntu/
にてgrubx64.efiがあればうまくインストールできていることが確認できます。

$ sudo update-grub
にて更新して、/etc/fstabに以下のような内容を追記します。
UUID=XXXX-XXXX /boot/efi vfat umask=0077 0 1 
UUIDは8桁のもので良いようです。

カーネルとドライバ


これでブートはするものの、5060Tiを5060Tiとして認識してくれません。動くドライバと動かないドライバがあるようです。 ただ、このあたりの情報が2025年6月あたりの情報ばかりで、最近の情報があまりネット上では見つかりませんでした。

そこで、試したパターンのうち記録に残していたものについて、ここに残しておきます。筆者の環境ではこうなるというだけで他の環境でもこうなるとは限りませんのでご注意ください。

nvidia-driver-linux-image-結果
画面マウスカーソルネットワークnvidia-smi
5906.17.0-1004-nvidia真っ黒で左上の
キャレットも表示されない
---
5906.17.0-14-generic真っ黒で左上の
キャレットも表示されない
---
5906.14.0-1015-nvidiaGUI付きで起動する動く記録なし失敗
5906.14.0-37-genericGUI付きで起動する動かない記録なし失敗
5906.11.0-1016-nvidiaGUI付きで起動する動かない動かない失敗
5906.11.0-29-genericGUI付きで起動する動く動く失敗
5906.8.0-1045-nvidiaGUI付きで起動する動く動く失敗
5906.8.0-100-genericGUI付きで起動した動かない動く失敗
590-open6.17.0-1004-nvidiaGUI付きで起動する動く動く失敗
590-open6.17.0-14-genericGUI付きで起動する動く動く失敗
590-open6.14.0-1015-nvidiaGUI付きで起動する動く動く失敗
590-open6.14.0-37-genericGUI付きで起動する動かない動かない失敗
590-open6.11.0-1016-nvidiaGUI付きで起動する動かない動かない失敗
590-open6.11.0-29-genericGUI付きで起動する動く動く失敗
590-open6.8.0-1045-nvidiaGUI付きで起動する動く動く失敗
590-open6.8.0-100-genericGUI付きで起動する動かない動かない失敗
575-open6.17.0-1004-nvidiaGUI付きで起動する動く動く正常に動作
575-open6.17.0-14-genericGUI付きで起動する動く動く正常に動作
575-open6.14.0-37-genericGUI付きで起動する動かない動かない失敗
575-open6.11.0-29-genericGUI付きで起動する動く動く失敗

以上より、筆者の環境では nvidia-driver-575-openと6.17.0 の組み合わせで正常に動作することが分かりました。

なお、nvidia-driver-575-openをインストールすると何故かnvidia-driver-580-openもインストールされます。 そして、nvidia-smiを実行すると

Driver Version: 580.126.09
と表示されるので、結局、nvidia-driver-580-openが使われているようです。

2026/01/24

マイクのプラグインパワー

マイクのプラグインパワーが実際のところマイクにどういう電圧をかけているのか調べてみました。

プラグの端子の名称はここでは下図のように呼んでいます(Nano Banana Proに描いてもらいました)。

なお、テスターは古ーーいアナログテスターなので測定誤差が大きいです。電圧の絶対値は間違っている可能性が高いですし、個体差もあるでしょうから、正しい値が必要な方はこんな個人メモを参考にせず、必ずご自身で測定してください。

測定結果


測定結果です。T=Tip、R1=Ring1、R2=Ring2、S=Sleeveです。

ELECOM USB-AADC02BK のマイク用3極ジャック

テスターの-極テスターの+極電圧
ST2.6V
SR12.6V
SR20.0V
R2R12.6V
R2T2.6V
R1T0.0V
SleeveとR2は両方ともジャック内のグランドの接点に接触しているようです。

ELECOM USB-AADC02BK のマイク付きイヤホン用4極ジャック

テスターの-極テスターの+極電圧
ST-2.6V
SR1-2.6V
SR2-2.6V
R2R10.0V
R2T0.0V
R1T0.0V
CTIA規格と思われます。CTIAの場合、R2がグランドでSがマイクになるので(参考)、 Sに電圧がかかっている状態になります。音声出力側(TまたはR1)は電圧がかからないし、R2はグランドなので、それらとSとの間で電位差が発生します。

Arvel製のHAMU02BKのマイク用ジャック

テスターの-極テスターの+極電圧
ST0.0V
SR10.0V
SR20.0V
R2R14.2V (稀に8.8Vのときもある)
R2T一瞬プラス側に振れるがすぐに0Vになる
R1T一瞬マイナス側に振れるがすぐに0Vになる
接点の接触状況に応じて内部回路で出力を制御しているっぽくみえます。 手持ちのコンデンサマイクでは動作しましたが、Tipに電圧がかかってないので2極プラグのマイクだと動かなさそうです。 テスターの-極をR1とR2に当ててショートさせている状態で+極をTに当ててみましたが、0.0Vでした。

audio-technica AT-MA2

テスターの-極テスターの+極電圧
ST2.4V
SR12.4V
SR20.0V
R2R10.0V
R2T0.0V
R1T0.0V
MONOとSTEREO設定でどちらも同じ結果でした。R2はジャック内でどの接点とも接触していないようです。

まとめ


デバイスごとに供給される電圧が違っていることは分かりました。規格がないのでそのとおりの結果ですね。

4極プラグで試したので、プラグのどの位置がジャック内で接触しているのかもばらばらであることも分かりました。 ばらばらということは3極対応のジャックをつなげるために4極プラグのコードを使うと、接続できないこともありそうです。