自宅RTX 3060でローカルLLMを5モデル比べてみた結果が面白かった

2026年4月11日 ktmr 1件のコメント

※この記事はClaude Codeで書いています。評価もClaude Codeが実施しています。

※この記事には間違いがありました。自宅RTX 3060でローカルLLMを比べてみたら、エージェントとして使ったら全然違う結果になった話で続編を書いているのでご参照ください。

最近、自宅のLLMサーバーに色々なモデルを詰め込んでいて、「結局どれが一番使えるの？」という疑問が積もってきたので、ちゃんとテストしてみました。

環境は以前書いた通り、Ollama + RTX 3060 (12GB VRAM) の構成です。

テストしたモデル

今回は「agentとして使う」という想定で、以下の5モデルを対象にしました。

モデル	ベース	サイズ
coder14b-agent	Qwen2.5-Coder-14B	9.0GB
qwen3-agent	Qwen3:14B	9.3GB
gemma4-e4b-agent	Gemma4 E4B	9.6GB
qwen35-agent	Qwen3.5:9B	6.6GB
mistral-nemo-agent	Mistral Nemo 12B	7.1GB

モデルはすべてOllamaのカスタムエイリアスとして登録済みで、コンテキスト長を8192〜16384に制限して運用しています（VRAMが12GBしかないので）。

評価した3つの能力

AIエージェントとして使うことを想定して、以下の3カテゴリで評価しました。

① 指示理解力 複数の条件（出力形式・文字数・テーマ）を同時に守れるか。「全部読んでちゃんとやって」ができるかどうかですね。

② Pythonコーディング力 関数の実装 + unittestの作成をセットで依頼。正しいアルゴリズムを選べるかも見ました。

③ WEBサーチ＆要約力 ツール呼び出しの記述と、渡した検索結果を構造化してレポートにまとめる力を評価。エージェントとして一番重要なスキルかもしれません。

結果

モデル	指示理解	コーディング	WEBサーチ	合計	速度
coder14b-agent	3/3	4/4	4/4	11/11	35 tok/s
gemma4-e4b-agent	3/3	4/4	4/4	11/11	66 tok/s
mistral-nemo-agent	3/3	4/4	4/4	11/11	30 tok/s
qwen3-agent	3/3	0/4	3/4	6/11	19 tok/s
qwen35-agent	1/3	4/4	0/4	5/11	47 tok/s

各モデルの感想

coder14b-agent（Qwen2.5-Coder-14B） 安定感が抜群です。コーディングテストでは seen = set() を使った素直な実装で、unittestも丁寧に書いてくれました。WEBサーチも手順を分けて記述してくれて、「指示通りに動く」という信頼感があります。

gemma4-e4b-agent（Gemma4 E4B）🏆 今回のMVPです。全項目満点で、しかも66 tok/sと断トツの速さ。コードには型アノテーションまで付いてきて、品質も高い。RTX 3060で66 tok/sは体感でもかなり快適です。これをメインに使います。

mistral-nemo-agent（Mistral Nemo 12B）dict.fromkeys(items) というPythonicな1行実装を使ってきたのがツボでした 🙂。出力が無駄なく簡潔で、サブタスクをこなすエージェントとして向いている気がします。

qwen3-agent / qwen35-agent 正直、期待を裏切られました。Qwen3系はいわゆる「思考モード（<think>タグ）」を持っていて、num_predictの上限まで思考トークンを消費し切った結果、実際の回答が空っぽになるケースが発生。qwen3-agentはPythonコーディングで0点、qwen35-agentはWEBサーチで0点でした。

思考モードを無効化するオプションを試せばまた変わるかもしれないので、別途チューニングしてみます。

まとめ

用途	おすすめ
普段使いのエージェント	gemma4-e4b-agent（速くて賢い）
コーディング特化	coder14b-agent（丁寧・安定）
軽量サブタスク	mistral-nemo-agent（簡潔）
Qwen3系	要チューニング

ローカルLLMは「ランキング上位のモデルが実用でも強いとは限らない」という教訓がありますが、今回はGemma4が思いのほか優秀でした。Googleのモデルを見直しています笑。

コンピュータ

RTX 3060 12GBでローカルLLMを動かしてみた正直な感想

2026年4月9日 ktmr コメントする

自宅サーバーにローカルLLM環境を構築してみた。結論から言うと、RTX 3060 12GBではプログラム開発用途としては厳しいというのが率直な感想だ。

構成

CPU: AMD Ryzen 5600X
RAM: 16GB
GPU: NVIDIA RTX 3060 12GB
OS: Ubuntu 24.04.4 LTS
推論エンジン: Ollama
自律エージェント: OpenClaw

やったこと

OllamaでQwen3やQwen3.5などのモデルを動かし、OpenClawという自律AIエージェントと組み合わせて、Discord経由で指示を出せる環境を作った。Claude CodeをボスとしてOpenClawに作業を振るという構成だ。

ブログ記事の自動投稿、Redmine連携のスキル化、Samba共有の設定など、いくつかのタスクを実際にやらせてみた。

壁にぶつかったこと

VRAMとコンテキストの綱引き

最初はQwen3 14Bを使っていたが、モデルだけで9.3GBのVRAMを消費する。残りはわずか2〜3GBで、コンテキストウィンドウ（会話の記憶量）を32K確保しようとするとほぼ限界になる。

推論が遅くなり、60秒のタイムアウトで落ちるケースが頻発した。

コンテキストが足りないとエージェントが動かない

OpenClawはデフォルトで131Kトークンものコンテキストを要求する。12GBのVRAMではそんな量は到底乗らないため、GPU→CPU→タイムアウトという連鎖が起きる。

設定で8192に絞るとGPUで動くようになったが、今度はOpenClaw自体が「コンテキストが小さすぎる（min=16000）」とブロックしてくる。

最終的にQwen3.5 9Bに切り替えて64Kコンテキストで落ち着いたが、それでも複雑なタスクでは処理が60秒を超えてタイムアウトする。

自走はするが遅い、落ちる

シンプルな会話や軽いタスクはこなせる。ただし：

複雑な指示（「Redmineに接続するスキルを作って」など）は途中で止まることが多い
エラーが起きてもDiscordに何も言わずに沈黙することがある
1つのタスクに数分〜10分かかる

実用ラインには届いていない、というのが正直なところだ。

かかったコスト感

RTX 3060 12GBのグラボ自体は中古で3〜4万円程度。電気代も24時間稼働させるとそれなりにかかる。

一方でClaude APIのコストは、個人利用レベルなら月数百〜数千円で十分なコンテキストと速度が使える。

コスパで考えると、現時点ではクラウドAPIに軍配が上がる。

じゃあ意味がなかったか？

そんなことはない。

プライバシーを気にするデータを扱える
ComfyUIと組み合わせた画像生成など、LLM以外の用途にも使える
「自分のサーバーで動く自律エージェント」というロマンは確かにある

ただ、「ローカルLLMでプログラム開発を全部まかなおう」という期待は12GB程度では難しいというのが今回の結論だ。

24GBや48GBのVRAMがあれば話は変わってくるかもしれない。あるいは、もう少しモデルの進化を待つのが現実的かもしれない。

まとめ

用途	RTX 3060 12GBでの実用度
雑談・簡単なQ&A	△ 動くが遅い
文章生成・ブログ執筆	△ 可能だが時間がかかる
プログラム開発補助	✗ タイムアウトが多く実用的でない
画像生成（ComfyUI）	○ こちらは十分実用的
プライベートデータの処理	○ 用途次第でアリ

ローカルLLMはまだ趣味PCで気軽に使える状態ではないかな。今、メモリ不足で値上がりしているが、ちょっとすれば価格も落ち着いて構成の低価格なハードが出てくるのでは。と期待している。

この記事はClaude Codeが執筆し、私が修正しています。

コンピュータ

AIが環境を作り、AIが記事を書いた話 – Claude CodeによるローカルLLMサーバー構築

2026年4月8日 ktmr コメントする

はじめに

この記事は少し変わった経緯で生まれました。

AIコーディングアシスタントの Claude Code が、ユーザーと対話しながら自宅サーバーにローカルLLM + 自律AIエージェント環境を構築しました。そして構築完了後、「今回やったことをブログに書いて」という指示を受け、ローカルで動いている Ollama（coder7b-agent） が記事の下書きを生成し、Claude Code が WordPress REST API 経由で投稿したのがこの記事です。

つまり、AIが環境を作り、AIがその記事を書き、AIが投稿したというわけです。

Claude Code とは

Claude Code は Anthropic が提供する AI コーディングアシスタントです。ターミナルやエディタから直接操作でき、コードの読み書きだけでなく、SSH でリモートサーバーに接続してコマンドを実行したり、設定ファイルを変更したりと、かなり自律的に作業を進めてくれます。

今回はユーザーが「ローカルLLMサーバーを建てたい」と伝えると、Claude Code が計画を立てて実装まで主導しました。

構築した環境の概要

ハードウェア

項目	内容
OS	Ubuntu 24.04 LTS
CPU	AMD Ryzen 5600X
RAM	16GB
GPU	RTX 3060 12GB VRAM

ソフトウェアスタック

レイヤー	選択	役割
推論バックエンド	Ollama	ローカルLLM実行エンジン
プライマリモデル	Qwen3:14b	9.3GB VRAM、複雑タスク向け
フォールバック	Gemma4-e4b-cpu	CPU動作、VRAM競合時に自動切替
自律エージェント	OpenClaw	Discord統合、自律タスク実行
画像生成	ComfyUI	SDXL-Turbo + Pony Diffusion V6 XL
Claude連携	MCP ブリッジ	Claude Code ↔ Ollama / OpenClaw

Claude Code が実装した内容

1. Ollama のセットアップと VRAM 最適化

Claude Code が SSH でサーバーに接続し、Ollama をインストールしました。

curl -fsSL https://ollama.com/install.sh | sh

VRAM 最適化のため systemd の override 設定を作成しました。

[Service]
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_HOST=0.0.0.0"
Environment="OLLAMA_MAX_LOADED_MODELS=1"

Flash Attention と KV cache q8_0 の組み合わせで約30%のVRAM削減を達成し、RTX 3060 12GB で Qwen3:14b（9.3GB）を安定稼働させることができました。

2. モデル選定

Claude Code がユーザーとの対話でモデルを選定しました。最終的な構成：

Qwen3:14b（プライマリ）

VRAM: 9.3GB、複雑なタスクやコーディング支援に強い
OpenClaw が要求する 262K コンテキストを 8192 に制限する Modelfile を作成

Gemma4-e4b-cpu（フォールバック）

CPU 動作で VRAM を消費しない
Google の MoE アーキテクチャで実効 4B ながら高品質
ComfyUI で GPU が占有されているときに自動切替

3. OpenClaw 自律エージェント

OpenClaw は Discord を通じて自律的にタスクを実行できるエージェントです。Claude Code が設定ファイルを生成し、Discord ボットとの連携まで完了させました。

Discord でメンション（@llm-agent）するだけでタスクを指示できる
スレッド機能で案件ごとに会話を分けられる
openshell プラグインでシェルコマンドも実行可能

4. ComfyUI 画像生成

画像生成環境として ComfyUI をセットアップし、2つのモデルを導入しました。

SDXL-Turbo fp16: 高速生成（数ステップで生成可能）
Pony Diffusion V6 XL: 高品質生成（アニメ・イラスト向け）

重要な制約: Ollama と ComfyUI は VRAM を共有するため同時起動不可です。Gemma4-e4b-cpu フォールバックはこの制約への対応策でもあります。

5. MCP ブリッジの実装

Claude Code が自分自身と Ollama・OpenClaw をつなぐ MCP サーバーを実装しました。

mcp-ollama: Node.js で実装した MCP サーバー。ask_ollama と list_models ツールを提供します。この記事の下書きも、このブリッジ経由で Ollama に生成させています。

openclaw-mcp-serve.sh: SSH 経由で OpenClaw の MCP サーバーに接続するラッパースクリプト。nvm 環境を SSH 非インタラクティブ環境でも読み込めるよう工夫しました。

実装中のハマりポイント

Claude Code がぶつかった問題と解決策の記録です。

Discord webhook の bot-to-bot 制限

Webhook で送ったメッセージに OpenClaw が反応しない問題。Discord 仕様で bot は bot/webhook のメッセージを無視するためです。OpenClaw ネイティブの Discord ボット統合に切り替えて解決しました。

OpenClaw Web UI のアクセス制限

HTTPS または localhost しか許可されない仕様。SSH トンネルで回避しています。

ssh -L 18789:localhost:18789 llm
# → ブラウザで http://localhost:18789 にアクセス

nvm 環境が SSH 非インタラクティブで読まれない

MCP 経由で SSH 実行する場合、~/.bashrc が読み込まれないため nvm が使えません。ラッパースクリプトで source ~/.nvm/nvm.sh を明示的に実行することで対応しました。

この記事の生成と投稿について

「今回やったことをブログに書いて欲しい」というユーザーの指示を受け、Claude Code は以下のステップを実行しました。

記事生成: MCP ブリッジ経由で Ollama（coder7b-agent）に記事の下書きを依頼
投稿: WordPress REST API を使って直接 WordPress に投稿

ただし当初は色々と苦労しました。OpenClaw への指示はペアリング問題で断念し、Discord 経由の投稿はアクセス権限の問題で失敗。最終的に Ollama MCP + REST API という構成に落ち着きました。

まとめ

Claude Code がユーザーと対話しながら、計画・実装・ドキュメント化・投稿まで一気通貫でやり遂げた事例でした。

ローカル LLM 環境があることで、Claude Code がさらにその環境を活用して記事を書くという面白い構図が生まれました。プライバシーを守りながら自前の AI 基盤を持つことの可能性を感じさせる体験でした。

なお、RTX 3060 12GB という家庭用 GPU でも、VRAM 最適化を工夫すれば十分実用的な環境が構築できます。ローカル LLM に興味がある方はぜひ試してみてください。

コンピュータ

SendGridからOCI Email Deliveryに乗り換えた話

2026年3月5日 ktmr コメントする

** この記事はClaude Codeと作業した記録をClaude Codeに記事にてもらい、Claude in Chromeを通してClaude Codeが投稿しています。 **

自宅サーバで長年お世話になっていたTwilio SendGridのFreeプランが、2026年3月31日で終了することになりました。4月1日から60日間のトライアルに移行し、5月末にはメール送信が止まってしまうとのこと。

うちのサーバではPostfix経由でSendGridを使って、Redmineの通知メールを飛ばしたり、lambeden.jpに届いたメールをGmailに転送したりしていました。さてどうしましょうか。

OCI Email Deliveryを選んだ理由

うちのサーバはOracle Cloud Infrastructure（OCI）のAmpere A1インスタンスで動いています。OCIにはEmail Deliveryというメール配信サービスがあって、月3,000通まで無料で使えます。同じプラットフォーム内で完結するので、これが一番スマートな選択肢かなということで移行してみました。

Claudeに手順を聞きながら作業しました (^_^)/

OCI Email Deliveryの設定

1. SMTP資格証明の生成

OCIコンソールで「アイデンティティ」→「ドメイン」→「Default」→「ユーザー」から自分のユーザーを開いて、SMTP資格証明を生成します。

⚠️ 生成されたユーザー名とパスワードはその場でコピー必須。画面を閉じると二度と確認できません！

2. 承認済み送信者の登録

「開発者サービス」→「電子メール配信」→「承認済送信者」で、メールのFromアドレスとして使うアドレスを登録します。

3. SPFの設定

承認済送信者の画面から「SPFの表示」でTXTレコードを確認して、お名前.comのDNS管理画面に追加します。

v=spf1 include:ap.rp.oracleemaildelivery.com ~all

4. DKIMの設定

「電子メール配信」→「電子メール・ドメイン」でドメインを作成して「DKIMの追加」からCNAMEレコードを生成、DNSに追加します。セレクター名はmail-tokyo-20260305みたいな形式が推奨されています。

10〜30分待って「Refresh DKIM Status」でActiveになれば完了です。

5. Postfixの設定変更

/etc/postfix/main.cfのリレーホストをOCIに変更します。

relayhost = [smtp.email.ap-tokyo-1.oci.oraclecloud.com]:587

/etc/postfix/sasl_passwdの認証情報も更新。

[smtp.email.ap-tokyo-1.oci.oraclecloud.com]:587    SMTPユーザー名:パスワード

あとSMTPUTF8関連のエラーが出たのでmain.cfに以下も追加しました。

smtputf8_enable = no

反映して動作確認。

sudo postmap /etc/postfix/sasl_passwd
sudo systemctl reload postfix
echo "テスト" | mail -s "テスト" -r xxxx@lambeden.jp 宛先アドレス

Redmineの通知メールもバッチリ届くようになりました。

問題発覚：転送メールが弾かれる

実はlambeden.jpに届いたメールをGmailに転送する設定もしていて、ここでハマりました。

OCI Email DeliveryはエンベロープFromとヘッダFromの両方が承認済み送信者に登録されていないと拒否する仕様です。転送メールの場合、Fromは外部の不特定の送信者になるので、これは構造的にどうにもなりません。

解決策：転送だけGmail SMTPを使う

PostfixのTransport Mapsで、自分のGmailアドレス宛の転送メールだけGmailのSMTPサーバー経由で送るようにしました。

/etc/postfix/transportに追記：

xxxx@gmail.com    smtp:[smtp.gmail.com]:587

/etc/postfix/sasl_passwdにGmailのアプリパスワードを追記：

[smtp.gmail.com]:587    xxxx@gmail.com:アプリパスワード

/etc/postfix/main.cfにtransport_mapsを追加：

transport_maps = hash:/etc/postfix/transport

反映して動作確認：

sudo postmap /etc/postfix/transport
sudo postmap /etc/postfix/sasl_passwd
sudo systemctl reload postfix

iCloudからlambeden.jpにテストメールを送ったら、ちゃんとGmailに届きました！GmailはFromを自分のGmailアドレスに書き換えますが、X-Google-Original-Fromヘッダに元の送信者が保持されるので実用上問題ありません。

まとめ

最終的なPostfixの構成はこうなりました。

用途	経路
Redmine通知・外部への送信	OCI Email Delivery
Gmailへの転送	Gmail SMTP

OCI Email Deliveryは同じプラットフォーム内で完結するので管理が楽で良いですね。SendGridよりも設定の自由度が低い部分もありましたが、無事移行できて一安心です。

コンピュータ

GOGETSSLからLet’s Encryptに乗り換え

2026年3月4日 ktmr コメントする

今までGOGETSSLの証明書を使っていましたが、更新期限が来たのと、今後、証明書の期限が200日以内になるという話もあるので、これを機にLet’s Encryptに乗り換えてみました。

Let’s Encryptは無料で使えますが、有効期限が90日なので、自動更新でもしないとやってられません。はい。自動更新の仕組みあります(^^;

今回は、Claude Codeに手順を出してもらって実施しました。完璧に動きました。すごい。（操作も含めて実行してもらうこともできるのですが、ちょっと怖かったので手順を出してもらって自分で事項しましたが、全く問題ありませんでした。本当にびっくりです。）

手順は以下の通り

Let’s Encrypt SSL証明書の自動更新（Apache + Postfix）

1. Certbot のインストール

# Ubuntu/Debian
sudo apt update
sudo apt install certbot python3-certbot-apache

# RHEL/CentOS/Rocky Linux
sudo dnf install certbot python3-certbot-apache

2. Apache 用の証明書取得

# Certbot が Apache の設定を自動的に更新する場合
sudo certbot --apache -d example.com -d www.example.com

# 証明書のみ取得（Apache 設定は手動）
sudo certbot certonly --apache -d example.com -d mail.example.com

mail.example.com を Postfix 用に同じ証明書に含めることを推奨

3. Postfix の SSL 設定

sudo nano /etc/postfix/main.cf

# TLS 設定
smtpd_tls_cert_file = /etc/letsencrypt/live/example.com/fullchain.pem
smtpd_tls_key_file  = /etc/letsencrypt/live/example.com/privkey.pem
smtpd_tls_security_level = may

smtp_tls_cert_file = /etc/letsencrypt/live/example.com/fullchain.pem
smtp_tls_key_file  = /etc/letsencrypt/live/example.com/privkey.pem
smtp_tls_security_level = may

sudo systemctl reload postfix

4. 自動更新の設定（重要）

Certbot はインストール時に systemd タイマーまたは cron を自動登録します。確認：

# systemd の場合
sudo systemctl status certbot.timer
sudo systemctl enable certbot.timer

# cron の場合（/etc/cron.d/certbot が存在するか確認）
cat /etc/cron.d/certbot

5. 更新後フック（サービス自動リロード）

更新後に Apache と Postfix を自動リロードするフックを作成：

sudo nano /etc/letsencrypt/renewal-hooks/deploy/reload-services.sh

#!/bin/bash
# Let's Encrypt 更新後に Apache と Postfix をリロード

echo "Reloading Apache and Postfix after certificate renewal..."
systemctl reload apache2   # Ubuntu/Debian
# systemctl reload httpd   # RHEL/CentOS

systemctl reload postfix

echo "Done: $(date)"

sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-services.sh

6. 動作テスト

# ドライランで更新をテスト（実際には更新しない）
sudo certbot renew --dry-run

# フックも含めてテスト
sudo certbot renew --dry-run --deploy-hook /etc/letsencrypt/renewal-hooks/deploy/reload-services.sh

7. 証明書の状態確認

# 証明書一覧と有効期限
sudo certbot certificates

# Postfix の TLS 確認
openssl s_client -connect mail.example.com:25 -starttls smtp 2>/dev/null | openssl x509 -noout -dates

まとめ・ポイント

項目	内容
証明書の場所	`/etc/letsencrypt/live/example.com/`
自動更新タイミング	有効期限 30 日前（Certbot が自動判断）
フックの場所	`/etc/letsencrypt/renewal-hooks/deploy/`
更新頻度	1 日 2 回チェック（systemd timer）

ポイント：

Apache と Postfix で 同じ証明書ファイルを共有 できる
deploy/ フォルダのスクリプトは更新成功時のみ実行される
ポート 80 が外部から到達可能である必要がある（HTTP-01 チャレンジ）

ドメイン名や OS の種類を教えていただければ、より具体的な設定を出せます。

以上、本当にすごい時代になったものです。

コンピュータ

tp-link Archer BE400(WiFi7)

2025年10月5日 ktmr コメントする

Amazon プライム感謝祭先行セールで安くなっていたのでtp-linkのArcher BE400(WiFi7)を買ってみた。12,280円なり。色々言われてるtp-linkですが、もういいかなと思うくらい素晴らしいい。

今まではRTX1210 + Archer C4000(WiFi5)で使っていたのだが、RTX1210が頻繁にオーバーフローを起こしていてちょっとパワー不足な感じでした。結構、CPUを80%以上使っちゃってるのでmap-eって重いの？

RTX1210を使っていたのはSNMPでいろいろ情報が取れるからなのですが、速度が出ないので本末転倒なので。。。

今回はインターネット接続もWiFiもBE400にまとめました。ポート数が足りないのと、せっかく2.5Gbpsのポートがるので、以前買って使ってなかった、FOXNEO 2.5gbps スイッチングハブに繋いでみました。

優先接続の速度比較

Archer BE400 + FOXNEO 2.5gbps スイッチングハブ+PC(2.5G接続)

最高速度が改善しているようです(^_^)

無線接続の比較

RTX1210 + Archer C4000(WiFi5) + iPhone 16

無線も回線速度分出ているようです。しかしパケットロスが20.3% !?使ってる感じ特に不具合は感じないのですが、この数値ほんとか？

まぁ、しばらく使ってみます。

それと、Archer BE400はトラフィックレポート機能があります。SNMPには対応してないけどまぁ、これで十分かも。

コンピュータ

OCI Standard.A1.Flexを試す

2025年9月19日 ktmr コメントする

OCI無料枠で試していたのですが、いつまでたってもA1-Flexシェイプが立ち上がらないので、有償プランに切り替えました。有償プランに切り替えたからと言ってAlways Free枠は変わらないので実質、料金は発生しません。

有償（個人）にアップグレードしたらA1.Flex 4core 24GBメモリのインスタンスがサクッと立ち上がりました(笑)

OCI 無料枠を試す

という訳で、早速ベンチマークをしてみました。

素晴らしい！　Standard.E2.1.Microの20倍！ GCP e2-microの72倍のパワー \(^_^)/

System Benchmarks Index Score

OCI Standard.A1.Flex 4ocpu 24GB Memory: 5512.4
OCI Standard.E2.1.Micro 1/8ocpu 1GB Memory: 268.1
GCP e2-micro 0.25vCPU 1GB Memory: 76.3

BYTE UNIX Benchmarks (Version 6.0.0)

   System: a1-test: GNU/Linux
   OS: GNU/Linux -- 6.14.0-1009-oracle -- #9~24.04.1-Ubuntu SMP Mon Jun 30 18:20:41 UTC 2025
   Machine: aarch64 (aarch64)
   Language: en_US.utf8 (charmap="ANSI_X3.4-1968", collate="ANSI_X3.4-1968")
   CPU 0: ARM Neoverse-N1 (50.0 bogomips)
          CPU Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
   CPU 1: ARM Neoverse-N1 (50.0 bogomips)
          CPU Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
   CPU 2: ARM Neoverse-N1 (50.0 bogomips)
          CPU Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
   CPU 3: ARM Neoverse-N1 (50.0 bogomips)
          CPU Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
   07:22:19 up 15 min,  1 user,  load average: 0.19, 0.08, 0.03; runlevel Sep

------------------------------------------------------------------------
Benchmark Run: Fri Sep 19 2025 07:22:19 - 07:50:14
4 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables       46864852.7 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     8586.2 MWIPS (9.9 s, 7 samples)
Execl Throughput                               3146.3 lps   (29.8 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks       1137974.0 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks          320778.0 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       2427991.5 KBps  (30.0 s, 2 samples)
Pipe Throughput                             1814774.8 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 101618.6 lps   (10.0 s, 7 samples)
Process Creation                               5683.8 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   9340.7 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                   3161.0 lpm   (60.0 s, 2 samples)
System Call Overhead                        1403721.6 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   46864852.7   4015.8
Double-Precision Whetstone                       55.0       8586.2   1561.1
Execl Throughput                                 43.0       3146.3    731.7
File Copy 1024 bufsize 2000 maxblocks          3960.0    1137974.0   2873.7
File Copy 256 bufsize 500 maxblocks            1655.0     320778.0   1938.2
File Copy 4096 bufsize 8000 maxblocks          5800.0    2427991.5   4186.2
Pipe Throughput                               12440.0    1814774.8   1458.8
Pipe-based Context Switching                   4000.0     101618.6    254.0
Process Creation                                126.0       5683.8    451.1
Shell Scripts (1 concurrent)                     42.4       9340.7   2203.0
Shell Scripts (8 concurrent)                      6.0       3161.0   5268.4
System Call Overhead                          15000.0    1403721.6    935.8
                                                                   ========
System Benchmarks Index Score                                        1551.3

------------------------------------------------------------------------
Benchmark Run: Fri Sep 19 2025 07:50:14 - 08:18:11
4 CPUs in system; running 4 parallel copies of tests

Dhrystone 2 using register variables      187363319.6 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                    34304.4 MWIPS (9.9 s, 7 samples)
Execl Throughput                               9255.9 lps   (29.8 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks       4417831.3 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks         1283904.0 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       7855700.9 KBps  (30.0 s, 2 samples)
Pipe Throughput                             7317913.7 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 962856.6 lps   (10.0 s, 7 samples)
Process Creation                              20808.0 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                  26487.7 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                   3423.5 lpm   (60.0 s, 2 samples)
System Call Overhead                        5606134.9 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0  187363319.6  16055.1
Double-Precision Whetstone                       55.0      34304.4   6237.2
Execl Throughput                                 43.0       9255.9   2152.5
File Copy 1024 bufsize 2000 maxblocks          3960.0    4417831.3  11156.1
File Copy 256 bufsize 500 maxblocks            1655.0    1283904.0   7757.7
File Copy 4096 bufsize 8000 maxblocks          5800.0    7855700.9  13544.3
Pipe Throughput                               12440.0    7317913.7   5882.6
Pipe-based Context Switching                   4000.0     962856.6   2407.1
Process Creation                                126.0      20808.0   1651.4
Shell Scripts (1 concurrent)                     42.4      26487.7   6247.1
Shell Scripts (8 concurrent)                      6.0       3423.5   5705.9
System Call Overhead                          15000.0    5606134.9   3737.4
                                                                   ========
System Benchmarks Index Score                                        5512.4

これが無料ですからね。暇を見てサーバ引っ越そうかな :-) 難点は、x86アーキじゃないのでバイナリ互換ないんですよね。設定はほぼ引き継げると思うけど。作ってデータ移行が必要だからちょっとめんどい。

コンピュータ

UGREEN NASync クラウドバックアップ

2025年9月18日 ktmr コメントする

はじめに

QNAPからUGREENに乗り換えてそんなに困ってないというか、結構気に入っているのですが、最大の問題がバックアップの弱さでした。 QNAPではHBS3という強力なツールでNASのデータをAmazon S3などのクラウドストレージにバックアップできたのですが、UGREENにはそういう機能はありません。

という訳で、dockerで実現してみました。 docker最高！

方針

利用するツールはbackrest
保存先はAmzon S3 Standard
Amazon S3ではライフサイクルポリシーで7日後にDeepArchiveに移動する

いろいろ検討した結果、resticというツールが良さげです。resticは重複排除や圧縮に対応しているのにOSSという素晴らしさ。resticを使ったdockerコンテナも複数公開されているのですがその中でも、WEBUIで操作できるbackrestを使うことにしました。

インストール

Dockerアプリのプロジェクトから「作成」を選んでプロジェクト名(backupなど)、保存パス(デフォルトでOK）、Compose設定に以下のYAMLファイルを貼り付けて「今すぐデプロイ」

version: "3.8"
services:
  backrest:
    image: garethgeorge/backrest:latest
    container_name: backrest
    hostname: backrest
    ports:
      - "9898:9898"              # 外部アクセス用
    volumes:
      - ./backrest/data:/data
      - ./backrest/config:/config
      - ./backrest/cache:/cache
      # バックアップ対象フォルダ
      - /volume1:/volume1:ro   
      - /volume2:/volume2:ro
    environment:
      - BACKREST_DATA=/data
      - BACKREST_CONFIG=/config/config.json
      - XDG_CACHE_HOME=/cache
      - TMPDIR=/tmp
      - TZ=Asia/Tokyo
    restart: unless-stopped

コンテナが立ち上がってきたら、WEBUIにアクセス(Dockerアプリのコンテナでbackrestを選んで→マークからクイックアクセスが楽）して、初期設定

 Instance ID: なんでもいいですが(dxp2800とか)
 User: なんでもいいけど(hogeadminとか)
 Password: 強いの付けてね

Add Repoでリポジトリ設定（前提として先にAWS上にS3バケットを作っておく必要あり。あと、アクセスキーを発行しておく必要あり）

 Repo Name: S3とか
 Repository URI: s3:s3.us-east-1.amazonaws.com/<バケット名> ※S3 URIではないので注意。私はコストが安いus-east-1を使ってる
 Password: Generateで作ればOK
 Env Vars: 環境変数をいくつか追加
   AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEYは最低必要。
   私はAWS_STORAGE_CLASS=STANDARD_IAも入れてる
その他の設定は変える必要なし

Add Planでバックアップ対象を追加

 Plan Name: nas backupとか
 Reposotory: さっき作ったリポジトリ名 S3とか
 Paths: ここにバックアップしたいパスを足していく
  私は /volume1/@homeとかdockerとか。
 Backup Schedule: 私はCron、Local、Every mounth on 1 at 2:00にしてます。差分取れるので毎日とってもいいけど。

これでOK。作ったプランのBackup Nowで試し取りしておくと良いでしょう。

最後に、docker/backup/のファイルは別途どっかにちゃんと保存しておきましょう。設定したパスワードが分らないとデータ復元できません。。。

以上

### 2025/10/3 追記
デフォルトでRepositoriesポリシーで月1回のPrune（削除）とCehckがスケジュールされているのだが、Checkは実際にS3のデータを読みに行くようで、ライフサイクルポリシーでDeep Archiveに送ってしまうと、失敗する。必ずCheckを実施しないといけないのか？というと、まぁ保険なので実施しないことにしました。削除は、Deep Archiveに送られていても問題なくできるようです。

コンピュータ

UGREEN NASync DXP2800省エネチューン

2025年9月2日 ktmr コメントする

チューンって程のことはないのですが、パフォーマンスが上がる確かめるためにNVMe SSDをキャッシュとして追加してみたのですが、安物のgen3 x2レーンではHDDと大差なかったので、dockerのバックエンドストレージとして分離しようと思います。

【プール分け】

HDD コールドプール(Volume1) – 基本的にはユーザーホームなのでユーザーが使わなければアクセスされない
SSD ホットプール(Volume2) – dockerなど常にアクセスするもののバックエンドとして利用。基本アプリはこちらに入れることにする

インストール済みのアプリや、dockerコンテナを移動するには基本入れ直しが必要です。写真アプリなんかはインデックスが消えそうで嫌だったのと、そもそも写真はHDDに入ってるので移動しませんでした。DockerとHome Assistant以下の通り。それ以外はアンインストールとインストールの繰り返しでOK。

【Dockerの移動】

コンテナを全部止める
docker内のファイルを全て適当な場所にへコピーする
docker-composeの内容をメモっておく（まぁ、同じフォルダをしていると出てきますけど念のため）
dockerアプリ削除(HomeAssistantアプリも同時に削除される)
dockerフォルダーを削除する(これをしないとVolume1に再度作られてしまうようだ)
Volume2を指定してdockerアプリインストール
退避したdockerディレクトリのファイルを新たに作成されたdockerフォルダ内にコピーする
管理 – データ移行(コンテナインスタンスは移行されない)
HomeAssitantアプリをVolume2/docker/homeassistantのフォルダを指定してインストールする(これでHomeAssitantは元通りに動くはず)
その他のコンテナもdocker-composeで再生成

余談ですが、dockerは共有フォルダーに出てくるdockerフォルダーと@dockerというシステムが勝手に作るdocker動作に必要なフォルダがあります。dockerをアンインストールすると、@dockerは削除されますが、特にコピーしておく必要はなさそうです。もしかしたらローカルリポジトリに自前のコンテナを置いてる場合はコピーしておいた方がいいかも。

結果

常時28W程度食っていたものがHDDがアイドル停止するようになって12Wまで下がりました。静かだし。 :-)

たった16W削減ですが、１か月に換算すると 11.5kWhも減るんですよね。今、kWhあたり35円程度なので、403円/月の削減ですね(^_^)

実はそれ以外にも、RTX810からRTX1210に変更したのを機に、SWX2200-8Gと2.5GのHUBの電源も普段落としています。私の用途では2.5Gbps必要なことなんて滅多にないので。その結果、常時稼働しているものが48W程度ほどに下がり、全体で25W減、月額にして630円/月の削減となりました。

ホームオートメーション

Home Assistant on UGREEN NASync DXP2800

2025年8月31日 ktmr コメントする

はじめに

UGREEN NASync DXP2800を購入して、アプリセンターにHome Assistantというものがあって初めて知ったのですが、これ優れものですね！

https://www.home-assistant.io

Home AssistantはOSSでIFTTTのようなことをローカルで実現します。Raspberry Piなんかで実装してる人が多いようです。

Home Assistantはdockerコンテナとしても提供されていて、UGREEN NASync DXP2800ではそれを使ってアプリとして提供しているようです。なので、NASyncではアプリをインストールするだけで使えます。

iPhoneやAndroid用のアプリも出ていてとても使い勝手がいいのですが、ローカルで動いているのでVPNなどで自宅にアクセスする必要があります。（クラウドサービスもあるのですがそれは有償です）

私は前に書いた、TailScaleで自宅に接続して使っています。

私は今まで、主にSwitchBot + Amazon ALEXAでエアコン制御なんかをやってたんですが、HEMSやEcoFlowの電池なんかとの連携はできませんした。それぞれ違う規格で動いているためです。それがHome Assistantを使うことでかなり連携可能になります。

	ECHONET Lite	Matter	IFTTT	Alexa	GoogleHome	CloudEdge	Home Assistant
Panasonic AiSEG2	〇	×	×	×	×	×	〇*1
Panasonic ホームユニット VL-HB1000-W	×	×	×	×	×	×	×
QCELLS 太陽電池	×	×	×	×	×	×	〇*1
SwitchBot	×	〇	〇	〇	〇	×	〇
EcoFlow Delta2	×	×	×	×	×	×	〇*1
TP-LINK tapo	×	〇	〇	〇	〇	×	〇
RATOC RS-WFIREX3	×	〇	×	〇	〇	×	〇*1
監視カメラ(COOAU)	×	×	×	×	×	〇	×

*1 カスタムコンポーネント導入で可能

例えば、HEMS Panasonic AiSEG2から発電、使用電力を取得して余力がある時だけ何をを実行といったオートメーションが組めるようになります。

今回実現したこと

Panasonic AiSEG2(HEMS)から発電量と消費量を取得して発電余力を求める
余力がある時にEcoFlow delta2を充電する
夜間充電した電力でサーバを稼働させる
この一連のサイクルをオートメーション化する

はい。できました(笑)

iPhone Home Assistant

iPhoneのHome Assistantアプリからアクセスするとこんな感じです。

実現方法

Home Assistantがあらかじめ対応している機器に関しては何もしなくても認識させられるのですが、残念ながら日本ローカルの AiSEG2は対応していません。そういう時はカスタムコンポーネントというのを作ることによって自由に機能を追加できます。AiSEG2から現在の発電量等を抜いてくるコンポーネントは無かったのでchatGPTさんにお願いして作りました(笑)

https://github.com/realktmr/hass_aiseg2_solpwr

GitHubを使ったのもPyhonでプログラムを書いたのも初めてだったのですが、AI素晴らしいですね。chatGPTとGeminiさんに教えてもらいながら作ってみました。

インストール方法

GitHUBからCode -> Download ZIPでファイルを全部ダウンロードする。
Home Assistantのconfigディレクトリにアサインしたフォルダにcustom_components/aiseg2_solpwrごとフォルダもファイルも置く。
Home Assistantの設定-> … -> Home Assistantを再起動で再起動する
上がってきたら設定 -> デバイスとサービスから +統合を追加を選んで、AiSEG2 Solar Powerを探して追加。IP、Username(aiseg固定)、Password(あなたがつけたもの)を入力して追加

これで、「発電量」「消費量」「余力」が出ているはずです。

EcoFlow delta2へのアクセスは Ecoflow-Cloudというカスタムコンポーネントが公開されており、これを使うことで簡単にアクセスできます。

EcoFlowアプリでも手動で設定できる【エネルギー管理】-> 【バックアップ予約】を有効にして、電池を利用するレベルを設定できます。例えばこの設定を20%に設定すると、入力ACプラグを挿していてもバッテリー残量が20%になるまで、電池から出力してくれます。20%を切ると充電を開始します。が20%まで充電するとパススルーでAC入力から出力します。

この機能を利用して、以下のようなオートメーションを組んでいます。

【前提】 DELTA2のエネルギー管理設定で充電限度 90%、放電限度 10%に設定。

【充電開始】発電余力が 1.0kWhを超えたとき、Delta2のBackup Reserve EnabledがONだったらBackup Reserve EnabledをOFFにする。(これによって90%までAC入力から充電されるようになる)

【放電開始】 18:00になった時、DELTA2のMain Battery Level が80%以上あったら、Backup Reserve　EnabledをONにしてDELTA2の Backup Reserve Level を 20%に設定にする（これによって、20%までは電池から放電する。20%を下回ったら20%まで充電する。しかし基本的には20%の時点でパススルー運転になるので次の日の充電開始までパススルー運転を実現している、ちなみに、OFFにしてONにするとデフォルトの50%に戻ってしまうようだ。また、ONにしてからじゃないとReserve Levelの設定ができない）

はい。これで太陽光発電の余力を使って充電し、DELTA2を普段使いするといった使い方が実現できました :-)

蛇足

本当は、余力が0を切ったら電池から放電って設定にもできるのですが、これをやると頻繁に電池運転に切り替わり、そのたびにリレーがカチカチ切り替わりなんか壊れそうな気がして(笑)

蛇足ですが、DELTA2はUPSではないので電池出力とACパススルーの切り替えに時に数ミリ秒切れてしまうのでPCなんかは電源落ちてしまいます。私はもともと使ってたAPCのRS550というUPSを嚙ましているので問題はないですが、それでも頻繁な切り替えは寿命を著しく縮めると思います。

そんな訳で、ちょっと妥協したオートメーションを組んでいますが、まぁ、十分かと。

他に、NASyncを置いてる部屋の温度計と連携して部屋の温度が32℃を超えたら自動でエアコンを掛けて30℃を下回ったら止めるオートメーションを組んだり。電力余力がなくなったら、29℃以下だったらエアコンを止めるオートメーションを組んだり。いろいろできるかと。

面白い使い方を思いついたらぜひ教えてください。

2026年10月
月	火	水	木	金	土	日
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31

テストしたモデル

評価した3つの能力

結果

各モデルの感想

まとめ

構成

やったこと

壁にぶつかったこと

VRAMとコンテキストの綱引き

コンテキストが足りないとエージェントが動かない

自走はするが遅い、落ちる

かかったコスト感

じゃあ意味がなかったか？

まとめ

はじめに

Claude Code とは

構築した環境の概要

ハードウェア

ソフトウェアスタック

Claude Code が実装した内容

1. Ollama のセットアップと VRAM 最適化

2. モデル選定

3. OpenClaw 自律エージェント

4. ComfyUI 画像生成

5. MCP ブリッジの実装

実装中のハマりポイント

Discord webhook の bot-to-bot 制限

OpenClaw Web UI のアクセス制限

nvm 環境が SSH 非インタラクティブで読まれない

この記事の生成と投稿について

まとめ

OCI Email Deliveryを選んだ理由

OCI Email Deliveryの設定

1. SMTP資格証明の生成

2. 承認済み送信者の登録

3. SPFの設定

4. DKIMの設定

5. Postfixの設定変更

問題発覚：転送メールが弾かれる

解決策：転送だけGmail SMTPを使う

まとめ

Let’s Encrypt SSL証明書の自動更新（Apache + Postfix）

1. Certbot のインストール

2. Apache 用の証明書取得

3. Postfix の SSL 設定

4. 自動更新の設定（重要）

5. 更新後フック（サービス自動リロード）

6. 動作テスト

7. 証明書の状態確認

まとめ・ポイント

優先接続の速度比較

無線接続の比較

はじめに

方針

インストール

結果

はじめに

今回実現したこと

実現方法

インストール方法

蛇足

徒然なるままに。。。