「Claude Code」タグアーカイブ

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

はじめに

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

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_ollamalist_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 は以下のステップを実行しました。

  1. 記事生成: MCP ブリッジ経由で Ollama(coder7b-agent)に記事の下書きを依頼
  2. 投稿: 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に乗り換えた話

** この記事は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に乗り換え

今まで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 の種類を教えていただければ、より具体的な設定を出せます。

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