GPT、LoRA、SFT、DPO……ChatGPTの裏側にある技術を「読む」だけでなく「実際に動かして理解したい」と思い、2026年に出たばかりの書籍『作ってわかる大規模言語モデルの仕組み』（日経BP）に挑戦しました。

環境はRaspberry Pi 5にRTX 5060 Ti（VRAM 16GB）を接続したローカルGPUマシンです。結論から言うと、全9ノートブックがエラーなく動作しました。その中で特に「おっ」と思った場面を3つ紹介します。

■ 夏目漱石を学習させたGPTが明治っぽい文章を生成した

第3章では青空文庫の「吾輩は猫である」（32万文字）を使って、GPTをゼロから学習させます。パラメータ数はわずか13Mという小さなモデルです。

学習は5000ステップ、時間にして約15分で完了しました。Loss（誤差）の変化はこんな感じです。

ステップ0：Loss 8.07 ステップ1000：Loss 2.25 ステップ3000：Loss 0.37 ステップ5000：Loss 0.20

きれいに収束していきます。そして「吾輩は」というプロンプトを与えると、こんなテキストが出てきました。

--- 吾輩は「それで朗読会さ。せんだってトチメンボーを御馳走した時にね。その話しが出たよ。何でも第二回には知名の文士を招待して大会をやるつもりだから、先生にも是非御臨席を願いたいって。それから僕が今度も近松の世話物をやるつもりかいと聞くと… ---

単語の選び方や文体が明治時代の小説らしい雰囲気になっています。13Mパラメータの小さなモデルがこれだけ再現できるというのが驚きでした。

■ 全パラメータの0.64%だけ学習するLoRAの不思議

第4章ではLoRA（Low-Rank Adaptation）というファインチューニング手法を試します。

使ったモデルはrinna/japanese-gpt2-medium（336Mパラメータ）ですが、LoRAでは全パラメータのうち学習するのは2.16M、つまりたったの0.64%です。残りの99.36%は一切変更しません。

データは青空文庫5000サンプル、学習時間は約5分。それで「吾輩は猫である。名前はまだ無い。」というプロンプトに対してこんな文章が出てきます。

--- 猫と申します。私は先日、ある人から、ある本を貸してもらったのですが、そこに書いてあった事を読んだ時にとても気になったので質問します。一つ一つの事柄について、自分が理解していなくては話にならないのでしょうか？ ---

0.64%しか触っていないのに流暢な日本語が出てくる。「これがLoRAが流行っている理由か」と実感できる場面でした。

■ SFTのビフォーアフターが一番わかりやすかった

第5章のSFT（教師ありファインチューニング）は、AIの振る舞いがガラッと変わる様子が一番わかりやすかったです。

チューニング前のモデルに「What is the capital of Japan?」と聞くとこう返ってきます。

--- The Japanese government has a long history of using money to finance its own military. The first major example was in 1848 when it used $1,000 for an army unit... ---

全然答えていません。ところがSFTで指示応答データを1回学習させると、こう変わります。

--- The capital, Tokyo ---

たった1回のトレーニングで「質問に答える」という振る舞いが身につく。ChatGPTが普通に質問に答えてくれる裏側に、こういう工程があるんだと腑に落ちました。

■ 環境構築について

書籍はGoogle Colab前提で書かれているため、ローカルで動かすにはいくつか変更が必要でした。主な作業は以下の3点です。

・Google Driveマウント部分を削除してローカルパスに変更 ・chapter02のTransformerはVRAMに合わせてモデルを軽量化（embedding_dim 512→256、layer 6→3） ・chapter05はtrlのバージョン（0.9.6）に合わせてAPIを調整

RTX 5060 Ti（16GB）があれば、deepspeedなしで全章動かせます。

■ まとめ

この本はTransformerの実装から始まり、GPT学習、LoRA、SFT、DPOまでを段階的に手を動かしながら学べる構成になっています。「読んで理解する」と「動かして理解する」は全然違うと改めて感じました。

特にSFTのビフォーアフターとLoRAの0.64%という数字は、実際に動かさないと実感しにくいと思います。LLMの仕組みを体で理解したい方にはおすすめの一冊です。

書籍：作ってわかる大規模言語モデルの仕組み（日経BP、2026年） Amazon：https://www.amazon.co.jp/dp/4296205250/

結論：ファイルを置くだけでOK

• memory/ ディレクトリにMarkdownファイルを置くと自動で監視・インデックス化される
• ファイルを変更してから1.5秒後に自動で再インデックスが走る
• Embeddingプロバイダーを指定しなくても、フォールバック順に自動選択してくれる
• インデックスは ~/.openclaw/memory/.sqlite にSQLiteとして保存

検索の仕組み：ハイブリッド方式

Embeddingプロバイダーのフォールバック順

local → OpenAI → Gemini → Voyage → Mistral

実際に試す順序

Step 1：まずゼロコンフィグで試す

memory/ディレクトリにMarkdownを置くだけ
状態確認
memory status --deep

検索テスト
docker compose run --rm openclaw-cli memory search --query "テストクエリ"

Step 2：精度を上げたいなら明示的に設定

agents:
  defaults:
    memorySearch:
      provider: "openai"
      model: "text-embedding-3-small"
      sync: { watch: true }

Step 3：APIキーを使いたくないならローカル

agents:
  defaults:
    memorySearch:
      provider: "local"
      local:
        modelPath: "all-MiniLM-L6-v2"

Step 4：大量ファイル（1万以上）になったら

各AIの独自観点

まとめ

テスト環境

• マシン: Raspberry Pi 5 16GB + RTX-5060Ti 16GB
• Ollama: ローカルGPU実行

テスト項目

結果サマリー

| モデル | サイズ | 平均速度 | 合計時間 | 推論精度 | 創作 | 安定性 | |--------|--------|----------|----------|----------|------|--------| | qwen3:8b | ~5.2GB | 最速 | — | ★★ (誤答あり) | ★★★ | ★★ | | qwen3.5:9b | ~6.6GB | 49.9 tok/s | 477秒 | ★★★ | ★★ | ★★ | | gemma3:12b | ~8.1GB | 41.1 tok/s | 626秒 | ★★★ | ★★★ | ★★★ |

詳細結果

qwen3.5:9b vs gemma3:12b

| タスク | qwen3.5:9b | gemma3:12b | |--------|-----------|-----------| | 日本語会話 | 50.9 tok/s (23.9s) | 41.3 tok/s (45.5s) | | 論理推論 | 49.6 tok/s (145.2s) | 41.3 tok/s (192.5s) | | コーディング | 49.6 tok/s (123.4s) | 40.5 tok/s (206.0s) | | 創作・表現 | 49.4 tok/s (184.1s) | 41.3 tok/s (182.2s) | | 平均 | 49.9 tok/s | 41.1 tok/s |

qwen3.5:9b の注意点

• thinkingモードにより創作タスクで空回答になることがある
• /no_think プレフィックスで解決可能（速度: 35.5 tok/s）
• 推論精度は高い

gemma3:12b の特徴

• 全タスク安定完走
• コード中の関数名まで日本語化するユニークな挙動
• 説明が非常に丁寧・詳細
• RPi5での速度は実用十分

総合推薦

| 用途 | 推薦モデル | 理由 | |------|-----------|------| | 総合 | gemma3:12b | 品質・安定性・完走率が最高 | | バランス | qwen3.5:9b | 速度と精度のバランスが良い | | 速度重視 | qwen3:8b | 最速だが推論誤答リスクあり |

第2回テスト: 高速モデル評価（~100 tok/s 狙い）

結果サマリー

| モデル | サイズ | 平均速度 | 日本語品質 | コーディング | 創作 | 総合評価 | |--------|--------|----------|------------|--------------|------|----------| | qwen3:1.7b | 1.4GB | 87.1 tok/s | ★★★ | ★★★ | ★★★ | ★★★ | | smollm2:1.7b | 1.8GB | ~108 tok/s* | ★ (支離滅裂) | ★★ | タイムアウト | ★ | | llama3.2:3b | 2.0GB | 82.4 tok/s | ★★ (英単語混入) | ★★ (範囲固定) | ★★ | ★★ | | gemma3:4b | 3.3GB | 41.1 tok/s | ★★★ | ★★★ | ★★★ | ★★★ | | phi4-mini:3.8b | 2.5GB | 32.8 tok/s | ★★★ | ★★★ | ★★★ | ★★ |

詳細

| タスク | qwen3:1.7b | smollm2:1.7b | llama3.2:3b | gemma3:4b | phi4-mini:3.8b | |--------|-----------|-------------|------------|----------|--------------| | 日本語会話 | 43.9 tok/s | 60.9 tok/s | 33.3 tok/s | 8.7 tok/s | 2.9 tok/s | | 論理推論 | 108.9 tok/s | 156.2 tok/s | 105.1 tok/s | 59.9 tok/s | 15.5 tok/s | | 創作・表現 | 108.4 tok/s | タイムアウト | 108.7 tok/s | 54.7 tok/s | 80.1 tok/s |

各モデルの特記事項

• qwen3:1.7b: 速度・品質のバランスが最良。thinkingモデルだが /no_think で安定。87 tok/s は実用十分
• smollm2:1.7b: 最速クラス(156 tok/s)だが日本語品質が壊滅的。日本語用途には不向き
• llama3.2:3b: 日本語文に英単語が混入、コードのrange固定など品質に難あり
• gemma3:4b: 品質は高いが日本語会話が8.7 tok/sと極端に遅い（初回ロード？要再テスト）
• phi4-mini:3.8b: 全体的に遅い（平均32.8 tok/s）。RPi5では実用的でない

総合推薦（全テスト統合）

| 用途 | 推薦モデル | 理由 | |------|-----------|------| | 高速・実用バランス | qwen3:1.7b | 87 tok/s、品質十分、1.4GBと軽量 | | 品質重視 | gemma3:12b (削除済) | 全タスク安定、41 tok/s | | 速度のみ重視 | smollm2:1.7b | 150+ tok/s だが日本語品質× |

結論

Quintとは？

インストール

npm install -g @informalsystems/quint

やってみた：銀行の送金システム

module bank {
  var alice: int
  var bob: int

action init = all {
    alice' = 100,
    bob'   = 100
  }

action aliceToBob = all {
    alice >= 10,
    alice' = alice - 10,
    bob'   = bob + 10
  }

action bobToAlice = all {
    bob >= 10,
    bob'   = bob - 10,
    alice' = alice + 10
  }

action step = any {
    aliceToBob,
    bobToAlice
  }

// 不変条件：お金の総量は常に200円
  val totalIsConserved = alice + bob == 200
}

バグを仕込んで検出させる

quint run bank.qnt --invariant=totalIsConserved

[State 0] { alice: 100, bob: 100 }
[State 1] { alice:  90, bob: 120 }

[violation] Found an issue

どんな用途に向いている？

以前の構成（自動返信）

新しい構成（Human in the Loop）

[cron 30分ごと]
  ↓
未読メール/Mastodon新着をチェック
  ↓
AIが返信案を作成
  ↓
承認待ちファイルに保存（IDを発行）
  ↓
Discordに通知
  「📧 返信案があります [ID: a1b2c3d4]
   From: ○○さん
   件名: ○○について
   ---
   （返信文）
   ---
   → 送信OKなら「メール送信 a1b2c3d4」と言ってください」
  ↓
自分がDiscordで「メール送信 a1b2c3d4」と返信
  ↓
AIが実際に送信

実装

[
  {
    "id": "a1b2c3d4",
    "type": "email",
    "draft": "お世話になっております...",
    "meta": {
      "thread_id": "xxxxx",
      "subject": "○○について",
      "from": "someone@example.com"
    },
    "created_at": "2026-03-12T22:00:00"
  }
]

感想

手順

1. 長期トークンを発行

claude setup-token

2. OpenClawに登録する場合

openclaw models auth paste-token --provider anthropic

通常トークンとの違い

• 通常のOAuthトークン：8〜12時間で失効、自動リフレッシュあり
• setup-tokenで発行したトークン：約1年間有効、リフレッシュ不要

注意点

やったこと

1. OpenClawのDiscord接続をRPi5に移行

2. RPi5にgogcliをセットアップ

GoでCross-compile or RPi上でビルド
git clone https://github.com/steipete/gogcli
cd gogcli
go build -o ~/bin/gog ./cmd/gog

ssh -L :127.0.0.1: masaka@rpi5

export GOG_KEYRING_BACKEND=file
export GOG_KEYRING_PASSWORD=

3. Gmail自動返信システムをRPi5で稼働

構成まとめ

Discord
  ↕
RPi5 (OpenClaw)
  ├── Discord Bot（24時間稼働）
  ├── Cronジョブ: gmail-checker（5分おき）
  │     └── gog gmail → 未読検知 → AI返信生成 → 自動送信 → Discord報告
  └── ~/bin/gog（gogcli, ファイルキーリング認証）

MacBook Air
  ├── Discord: 無効
  └── gmail-checker cron: 無効（RPiに移管済み）

ポイント

• ヘッドレスLinuxでのOAuth：D-Busなし環境ではGOG_KEYRING_BACKEND=fileを使う
• SSHポートフォワーディングでOAuth callback：RPiで起動したgog authのコールバックをMacブラウザで受け取る
• OpenClawのcron機能：エージェントを定期実行するのに便利。--session isolatedでセッション分離できる
• gog gmail send：--reply-to-message-idで返信スレッドに乗せて送信できる