AI > 基盤・ツール on M1KE BL0G

BM25とLLMを使った検索システムの再考

Mon, 28 Sep 2026 08:00:00 +0900

背景

最近の検索システムは、BM25のような古典的な手法と、LLM・埋め込みモデルのような手法を組み合わせて作ることが多い
その前提として、まずBM25という手法自体がBag-of-Wordsとどう違うのかを整理する
その上で、BM25とLLMをどう組み合わせるかというアーキテクチャを再整理する

Bag-of-Words（BoW）とは

文書を、単語の出現頻度だけで表現するモデル
単語の並び順や文法構造は無視し、「どの単語が何回出たか」だけを見る

例えば、次の2文をBoWで表現すると、以下のようなベクトルになる。

1
2


文書A: "猫が魚を食べる"
文書B: "魚が猫を食べる"

どちらも{猫:1, 魚:1, 食べる:1, が:1, を:1}という同じベクトルになり、語順の違い（誰が誰を食べたか）はBoW表現からは区別できない。

検索においては、クエリと文書のBoWベクトルの内積やコサイン類似度を取ることで、素朴な関連度スコアを作れる
ただし、このままでは「は」「が」「の」のような、どの文書にも高頻度で出る単語（ストップワード）が支配的になり、意味のある単語の重みが埋もれてしまう

TF-IDFという改良

Term Frequency（TF）: その文書内での単語の出現頻度
Inverse Document Frequency（IDF）: その単語が、全文書の中でどれだけ稀かを表す重み
TF-IDFは、この2つを掛け合わせることで、「この文書に頻出するが、他の文書にはあまり出ない単語」を重視するようにする

以下のような式で表される。

$$ \text{tf-idf}(t, d) = \text{tf}(t, d) \times \log\frac{N}{n(t)} $$

$\text{tf}(t, d)$：単語$t$の文書$d$内での出現回数
$N$：全文書数
$n(t)$：単語$t$を含む文書数

これでストップワード問題はかなり改善するが、TFの部分は依然、出現回数に比例して線形に増加する。つまり、ある単語を10回書いた文書は、1回しか書いていない文書より単純に10倍関連度が高いと評価されてしまう。

BM25とは

BM25（Okapi BM25）は、TF-IDFをさらに発展させた、Probabilistic Relevance Framework（確率的関連性モデル）に基づくランキング関数
検索エンジンやElasticsearch・Lucene系のデフォルトスコアリング関数として、実務で広く使われている
SQLiteに組み込みの全文検索エンジンFTS5も、bm25()という補助関数でBM25ベースのランキングを提供しており、外部の検索エンジンを立てずに手軽にBM25検索を試せる選択肢になる

スコアは、クエリ$Q$に含まれる各単語$q_i$について、次の式の合計として計算される。

$$ \text{score}(D, Q) = \sum_{i=1}^{n} \text{IDF}(q_i) \cdot \frac{f(q_i, D) \cdot (k_1 + 1)}{f(q_i, D) + k_1 \cdot \left(1 - b + b \cdot \dfrac{|D|}{\text{avgdl}}\right)} $$

$f(q_i, D)$：単語$q_i$の文書$D$内での出現回数（TFと同じ）
$|D|$：文書$D$の長さ、$\text{avgdl}$：コーパス内の文書の平均長
$k_1$：TFの飽和度を決めるパラメータ（通常1.2〜2.0程度）
$b$：文書長による正規化の強さを決めるパラメータ（通常0.75程度）
$\text{IDF}(q_i)$：BM25版のIDF

BM25版のIDFは、以下のように定義される。

$$ \text{IDF}(q_i) = \ln\left(\frac{N - n(q_i) + 0.5}{n(q_i) + 0.5} + 1\right) $$

TFの飽和（$k_1$の役割）

BoW・単純なTFでは、出現回数がそのままスコアに比例する
BM25では、$f(q_i, D)$が分母にも登場するため、出現回数が増えるほどスコアの増加が徐々に緩やかになる（飽和する）
直感的には、「同じ単語を1回書くのと2回書くのとの差」は大きいが、「50回書くのと51回書くのとの差」はほとんど意味がない、という考え方を反映している

文書長の正規化（$b$の役割）

長い文書は、単語の出現回数がただ長いという理由だけで多くなりやすい
$b$は、文書長が平均より長い場合にスコアを下げ、短い場合に相対的に有利にしすぎないよう調整する
$b=0$なら文書長による補正なし、$b=1$なら文書長に完全に比例した補正になる

BoWとBM25の違い

観点	Bag-of-Words（生TF）	BM25
出現回数の扱い	線形に増加	$k_1$により飽和する
文書長の補正	なし	$b$により正規化する
単語の重み	均一（IDFなし）	IDFで単語の稀さを重視
理論的基盤	特になし	確率的関連性モデルに基づく

具体例で比較する

クエリを「猫」とし、次の2つの文書を考える。

文書A: 「猫」を5回繰り返した、長さ5の文書
文書B: 「猫が座っている机の上」のような、長さ6で「猫」が1回だけ出る文書

$k_1=1.5$、$b=0.75$、コーパスの平均文書長$\text{avgdl}=5.5$とし、IDFは共通なのでTFの部分だけを比較する。

生TF（BoW）で比較すると、文書Aは文書Bの5倍のスコアになる。

$$ \text{文書A（生TF）} = 5, \qquad \text{文書B（生TF）} = 1 $$

一方、BM25のTF部分を計算すると、次のようになる。

$$ \text{文書A} = \frac{5 \times (1.5+1)}{5 + 1.5\left(1-0.75+0.75\times\frac{5}{5.5}\right)} \approx \frac{12.5}{6.40} \approx 1.95 $$$$ \text{文書B} = \frac{1 \times (1.5+1)}{1 + 1.5\left(1-0.75+0.75\times\frac{6}{5.5}\right)} \approx \frac{2.5}{2.60} \approx 0.96 $$

BoWでは5倍だった差が、BM25では約2倍に縮まっている
「猫」を5回連呼した文書が、1回しか言及していない文書より多少有利にはなるが、5倍も関連度が高いわけではない、という直感をBM25が反映している

BM25の限界: 語彙のミスマッチ問題

BM25はあくまで、クエリと文書の間で単語が一致するかどうかに基づくスパース検索（lexical retrieval）
「車」と「automobile」、「猫」と「ネコ」のような同義語・表記の違い・言い換えには対応できない
クエリの単語が文書に一字一句含まれていなければ、意味的には関連していてもスコアが付かない

ここでLLM・埋め込みモデルの出番になる。

LLMによる密検索（Dense Retrieval）

クエリと文書を、LLMベースの埋め込みモデル（bi-encoder）でベクトル化し、ベクトル空間上の距離（コサイン類似度など）で関連度を測る
単語の一致ではなく、意味的な近さで検索できるため、同義語や言い換えにも対応できる
代表的な手法としてDense Passage Retrieval（DPR）などがある

BM25（スパース検索）とDense Retrieval（密検索）は、得意なものが対照的になる。

観点	BM25（スパース）	Dense Retrieval（密）
得意なこと	固有名詞・専門用語の完全一致	同義語・言い換え・意味的な近さ
弱いこと	語彙のミスマッチ	稀な固有名詞・数値などの厳密な一致
計算コスト	軽い（転置インデックス）	埋め込み計算・ベクトル検索が必要

ハイブリッド検索

BM25とDense Retrieialを両方使い、それぞれのスコア・順位を統合するのがハイブリッド検索
統合方法の一つがReciprocal Rank Fusion（RRF）で、各手法での順位の逆数を合計してスコアにする

$$ \text{RRF}(d) = \sum_{r \in \text{ランキング群}} \frac{1}{k + \text{rank}_r(d)} $$

$\text{rank}_r(d)$：ランキング手法$r$における文書$d$の順位、$k$は定数（60程度がよく使われる）
スコアのスケールが違う手法同士でも、順位ベースなので単純に統合できるのが利点

LLMによるリランキング

BM25・Dense Retrievalで絞り込んだ上位数十〜数百件の候補に対し、より高精度だが計算コストの高いモデルで再順位付けするのがリランキング
クエリと候補文書のペアをまとめて入力するCross-Encoderや、LLMに直接「どちらがより関連しているか」を判断させるLLM-as-a-judge方式などがある
候補全件に適用するのは計算コストが高いため、まず軽量なBM25・Dense Retrievalで絞り込み、上位のみをリランキングするという2段構成が一般的

RAGとの関係

Retrieval-Augmented Generation（RAG）は、この「検索して、上位の文書をLLMのプロンプトに含めて生成する」というパイプライン全体を指す
検索の精度が低ければ、無関係な文書がプロンプトに混ざり、LLMの生成結果も悪化する
つまりRAGの品質は、生成モデル自体の性能だけでなく、BM25・Dense Retrieval・リランキングを含む検索パイプライン全体の設計に大きく依存する

まとめ

Bag-of-Wordsは単語の出現頻度だけを見る素朴な表現で、出現回数に比例してスコアが線形に増える
TF-IDFはIDFで単語の重要度を重み付けするが、TF自体は依然線形
BM25は$k_1$でTFの増加を飽和させ、$b$で文書長を正規化する、確率的関連性モデルに基づくランキング関数
BM25はあくまで単語の一致に基づくスパース検索で、同義語・言い換えには弱い
LLMベースの埋め込みによる密検索は意味的な近さで検索でき、BM25と相補的な関係にある
両者をRRFなどで統合するハイブリッド検索や、上位候補をLLMで再順位付けするリランキングが、実務でよく使われる構成
この検索パイプライン全体の精度が、RAGの生成品質を直接左右する

参考文献

Robertson, S., & Zaragoza, H. (2009). “The Probabilistic Relevance Framework: BM25 and Beyond”
Robertson, S. E., & Sparck Jones, K. (1976). “Relevance weighting of search terms”
Karpukhin, V. et al. (2020). “Dense Passage Retrieval for Open-Domain Question Answering”
Cormack, G. V., Clarke, C. L., & Buettcher, S. (2009). “Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods”
Lewis, P. et al. (2020). “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”

AI推論スタック整理ノート

Tue, 21 Apr 2026 00:42:16 +0900

背景

機械学習のアーキの選定で色々比較したくなったが、用語がたくさんありすぎて混乱してきた
昔はモデルはPyTorchで作り、GPU推論はCUDAとTensorRT、CPU推論はONNXでOKだった
しかし、LLM関連やEdge側での実行、CUDA以外にもOpenCL、Vulkanなど色々あるので複雑化している
例えば、Gemma4 e2bをJetsonでGPUモードで動かす時に、何のbackendで動かせばいいかを調べる必要がある
そこで、AIに用語を改めてまとめて整理してもらったので、そのノートを残す

全体像

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


[アプリ / サーバ / SDK]
 LM Studio / Ollama / 自作CLI / 自作C++・Pythonアプリ / MediaPipe Tasks API

[LLM・推論ランタイム]
 llama.cpp / ONNX Runtime / MNN / ncnn / LiteRT / LiteRT-LM / TensorRT-LLM

[acceleratorの差し込み口]
 CUDA EP / TensorRT EP / 各runtimeの CUDA backend / Vulkan backend / OpenCL backend / WebGPU backend

[モデル形式・配布形式]
 .onnx / .mnn / .gguf / .tflite / .task / .litertlm / safetensors

[低レベルGPU/計算API]
 CUDA / TensorRT / Vulkan / OpenCL / OpenGL ES / OpenGL / WebGPU / WebGL

[OS・SDK・ドライバ]
 JetPack / Jetson Linux / NVIDIA driver / compiler toolchains

[ハードウェア]
 CPU / GPU / NPU / TPU / RAM / ストレージ

たとえば Qwen はモデル、MNN はランタイム、.mnn はそのランタイム向けモデル形式、Vulkan はさらに下のGPU API。 ([GitHub][2])

レイヤー別の全体表

レイヤー	何が入るか	役割	代表例	根拠
0. ハードウェア	SoC（System on Chip）, CPU, GPU, RAM	実際に演算する物理マシン	Jetson Orin Nano, GeForce RTX, NVIDIA RTX PRO、Tegra K1 Soc	Jetson は edge/embedded、RTX / RTX PRO は desktop / laptop / workstation 側の NVIDIA GPU 群。
1. OS / 配布SDK	OS, BSP, ドライバ同梱SDK	ハードを使える状態にする	JetPack, Jetson Linux, Windows	Jetson 系と RTX PC / workstation 系で土台が異なる。
2. ベンダー計算SDK / 推論SDK / graphics API	GPU を叩く低レベル基盤や推論SDK	GPU/アクセラレータ計算や推論最適化	CUDA, TensorRT, TensorRT-RTX, Vulkan, OpenCL, OpenGL, WebGPU, WebGL	TensorRT-RTX は RTX GPU 向けの compact inference library。
3. モデル形式 / IR / バンドル	モデルの保存・交換・配布形式	ランタイムに渡す「中身」	`.onnx`, `.mnn`, `.gguf`, `.tflite`, `.task`, `.litertlm`, `.safetensors`	ONNX は open format、`.task` は MediaPipe 向け self-contained package、`.litertlm` は LiteRT-LM 向け形式。 ([ONNX Runtime][4])
4. 汎用推論ランタイム	モデルを実行する本体	推論実行、スケジューリング、メモリ管理	ONNX Runtime, MNN, ncnn, LiteRT	ORT は cross-platform accelerator、MNN は lightweight inference engine、LiteRT は on-device framework、ncnn は Vulkan 利用の軽量推論系。 ([ONNX Runtime][4])
5. LLM専用ランタイム	LLM特有の処理を担当	KV cache, sampler, stateful inference	llama.cpp, LiteRT-LM, TensorRT-LLM, TensorRT Edge-LLM, MNN-LLM	TensorRT Edge-LLM は embedded 向け C++ LLM/VLM runtime。
6. バックエンド / Execution Provider	下のハードaccelerator先への接続	どのGPU/NPU/CPUで実行するか選ぶ	CUDA EP, TensorRT EP, Vulkan backend, OpenCL backend, WebGPU backend	ORT は EP でaccelerator先を差し替え、LiteRT の Linux GPU backend は WebGPU(Vulkan) 。 ([ONNX Runtime][6])
7. アプリ / API / 配布SDK	ユーザーが触る入口	実アプリとして使う	MediaPipe Tasks, LLM Inference API, CLI, Python binding	MediaPipe Tasks は solution API、LLM Inference API は on-device LLM 用、Gemma docs では LiteRT-LM CLI も案内されている。 ([Google AI for Developers][7])

用語整理

用語	レイヤー	分類	ひとことで	典型的に何の上で動くか / 何を使うか	Jetson Orin Nano文脈
Jetson Orin Nano	0	ハードウェア	NVIDIA の edge/embedded 向け SoC ボード	JetPack / Jetson Linux の上	物理マシン本体。 ([NVIDIA Developer][1])
JetPack	1	配布SDK	Jetson 向け OS + AI stack まとめ	Jetson Linux, CUDA, TensorRT, cuDNN などを同梱	Jetson 開発の土台。 ([NVIDIA Developer][1])
CUDA	2	低レベル計算基盤	NVIDIA GPU 計算の本流	NVIDIA GPU / CUDA driver	Jetson で NVIDIA 流に速くする土台。 ([NVIDIA Docs][3])
cuDNN	2〜3	DNNライブラリ	NVIDIA の DL primitives	CUDA の上	JetPack に同梱。多くのフレームワークが内部利用。 ([NVIDIA Developer][1])
TensorRT	2〜3	推論SDK	NVIDIA GPU 向け推論最適化/実行SDK	CUDA の上	Jetson/NVIDIA 本流の推論高速化。 ([NVIDIA Docs][8])
TensorRT-LLM	5	LLM専用ランタイム	TensorRT 系の LLM 特化版	NVIDIA GPU, TensorRT	Qwen3 例もある。Jetson/NVIDIA LLM 本流の一つ。 ([NVIDIA GitHub][9])
OpenCL	2	標準 compute API	ベンダー横断の GPU/CPU 計算API	各ベンダーの OpenCL 実装	NVIDIA 専用ではない。 ([The Khronos Group][10])
PoCL	2	OpenCL実装	OpenCL の実装の1つ	Clang/LLVM を利用、CPU/一部GPU targets	OpenCL “規格” ではなく “実装”。 ([PoCL][11])
Vulkan	2	低レベル graphics+compute API	low-level GPU API	GPU driver の上	Jetson は Vulkan をサポート。 ([Vulkan][12])
OpenGL / OpenGL ES	2	graphics API	主に描画 API	GPU driver の上	Jetson がサポート。推論ランタイム内部の補助経路に出ることもある。 ([The Khronos Group][13])
WebGL	2	Web graphics API	ブラウザ向け 3D API	HTML Canvas 上、OpenGL ES ベース	native Jetson 推論の中心ではない。 ([The Khronos Group][14])
WebGPU	2	Web/汎用GPU API	Web 向けの新しい GPU API	Vulkan / Metal / D3D12 等にマップされる	LiteRT Linux GPU backend の表記に登場。 ([W3C][15])
ONNX	3	モデル形式 / IR	open model format	ONNX Runtime, TensorRT などへ渡す	形式であってランタイムではない。 ([ONNX Runtime][4])
`.onnx`	3	ファイル形式	ONNX の実ファイル	ORT, TensorRT, MNN converter など	中立的な受け渡し形式。 ([ONNX Runtime][4])
TFLite / `.tflite`	3	モデル形式	LiteRT 系のモデル形式	LiteRT / MediaPipe	`.task` や `.litertlm` の元になることがある。 ([Google AI for Developers][16])
`.task`	3	タスクバンドル	モデル + tokenizer + metadata の bundle	MediaPipe Tasks / LLM Inference API	単体モデルではなく配布バンドル。 ([Google AI for Developers][17])
`.litertlm`	3	LLMバンドル/形式	LiteRT-LM runtime 向け形式	LiteRT-LM	Gemma の LiteRT-LM 配布で登場。 ([Google AI for Developers][18])
`.mnn`	3	モデル形式	MNN 用のモデル形式	MNN / MNN-LLM	ONNX などから変換される。 ([GitHub][19])
GGUF / `.gguf`	3	モデル形式	llama.cpp 系で一般的な配布形式	llama.cpp, LM Studio など	Qwen/Gemma の GGUF 配布も多い。Qwen3 README は GGUF 利用例を案内。 ([GitHub][2])
safetensors	3	モデル重み形式	Hugging Face 系で一般的	PyTorch/Transformers などから変換元に	Gemma → `.task` 変換元として公式に案内。 ([Google AI for Developers][17])
ONNX Runtime	4	汎用推論ランタイム	ONNX を実行する engine	CPU / CUDA EP / TensorRT EP / ほか	中立的で移植性が高い。 ([ONNX Runtime][4])
MNN	4	汎用推論ランタイム	Alibaba の軽量推論 engine	CPU / Vulkan など	Qwen を含む on-device 系で使われる。 ([GitHub][20])
ncnn	4	汎用推論ランタイム	Tencent の軽量推論 engine	CPU / Vulkan	Jetson でも Vulkan 前提で使いうる。 ([GitHub][21])
LiteRT	4	on-device推論基盤	Google の on-device ML/GenAI framework	CPU/GPU/NPU	`.tflite` と `.litertlm` を扱う基盤。 ([Google AI for Developers][22])
llama.cpp	5	LLMランタイム	C/C++ のローカル LLM engine	CPU, CUDA, Vulkan など	Qwen/Gemma をローカルで動かす代表格。 ([GitHub][23])
LiteRT-LM	5	LLMランタイム	LiteRT 上の LLM 専用 framework	LiteRT / CPU/GPU/NPU backends	`.litertlm` を動かす本体。 ([Google AI for Developers][5])
MNN-LLM	5	LLMランタイム	MNN 上の LLM engine	MNN	export と inference を提供。 ([GitHub][24])
CUDA EP	6	Execution Provider	ORT から CUDA を使う差し込み口	ONNX Runtime + CUDA	ORT で NVIDIA GPU を使う道。 ([ONNX Runtime][25])
TensorRT EP	6	Execution Provider	ORT から TensorRT を使う差し込み口	ONNX Runtime + TensorRT	ORT で NVIDIA 向け高速化する道。 ([ONNX Runtime][26])
Vulkan backend	6	runtime backend	Vulkan を使う実行経路	ncnn, llama.cpp など	Jetson で使える可能性が高い backend。 ([GitHub][21])
OpenCL backend	6	runtime backend	OpenCL を使う実行経路	一部 runtimes / LiteRT Android	Jetson で主役とは限らない。 ([The Khronos Group][10])
WebGPU backend	6	runtime backend	WebGPU を使う実行経路	LiteRT Linux GPU backend	LiteRT Linux は `WebGPU (Vulkan)` と明記。 ([Google AI for Developers][27])
MediaPipe Tasks	7	API/SDK	使いやすい solution API	`.task` を読み込む	`.task` バンドルの受け皿。 ([Google AI for Developers][7])
LLM Inference API	7	API/SDK	MediaPipe の on-device LLM API	`.task` bundle など	Android guide では LiteRT-LM への移行推奨も記載。 ([Google AI for Developers][16])
Qwen	3の中身 / モデルそのもの	モデル系列	Alibaba Cloud の LLM family	Transformers, llama.cpp, MNN, TensorRT-LLM 等で実行可能	MNNそのものではない。 ([GitHub][2])
Gemma	3の中身 / モデルそのもの	モデル系列	Google 系のオープンモデル family	LiteRT-LM, llama.cpp, LM Studio など	`.task` / `.litertlm` 系とも接続。 ([Google AI for Developers][28])
GeForce RTX / NVIDIA RTX PRO	0	ハードウェア / GPU製品ライン	NVIDIA の desktop / laptop / workstation 向け GPU 群	Windows / Linux + NVIDIA driver の上	Jetson とは別の PC / workstation 側の比較対象。
TensorRT-RTX	2〜4	推論SDK / inference library	RTX GPU 向けの軽量 TensorRT 系推論ライブラリ	NVIDIA RTX GPU / Windows / Linux	RTX PC 向け。Edge / Embedded 向けではない。
TensorRT Edge-LLM	5	LLM / VLM専用ランタイム	embedded 向けの軽量 C++ inference runtime	Jetson / DRIVE + TensorRT + CUDA	Jetson/DRIVE 系の edge runtime。現時点では JetPack 7.1 / Jetson Thor での公式案内が強い。

よくある混同

よくある混同	正しい整
Qwen は MNN か？	No。Qwen はモデル、MNN はランタイム。Qwen3 公式 README では llama.cpp / MNN / TensorRT-LLM など複数の実行先が案内されている。 ([GitHub][2])
`.task` はモデル形式か？	半分 yes 、より正確には MediaPipe 向け task bundle 。モデル本体に tokenizer と metadata を同梱した self-contained package 。 ([Google AI for Developers][17])
`.litertlm` は LiteRT-LM 専用か？	実務上は LiteRT-LM runtime 向けの LLM bundle/format と考えてよい。Gemma docs でも LiteRT-LM CLI で `.litertlm` を使うと案内されている。 ([Google AI for Developers][18])
ONNX はランタイムか？	No。ONNX は形式、ONNX Runtime は実行エンジン。 ([ONNX Runtime][4])
PoCL は OpenCL か？	No。OpenCL は規格、PoCL はその実装の1つ。 ([The Khronos Group][10])
WebGL と WebGPU は同じか？	No。WebGL は OpenGL ES ベースの web graphics API、WebGPU はより新しい web 向け GPU API で、graphics だけでなく compute も重視している。 ([The Khronos Group][14])
Vulkan と CUDA は同じか？	No。どちらも GPU を使えるが、CUDA は NVIDIA 専用の計算基盤、Vulkan は標準の graphics+compute API 。 ([NVIDIA Docs][3])
LiteRT-LM は TensorRT-LLM の別名か？	No。LiteRT-LM は Google AI Edge 側、TensorRT-LLM は NVIDIA 側の別スタック。 ([Google AI for Developers][5])
TensorRT-RTX は TensorRT-LLM の RTX版か？	No。TensorRT-RTX は RTX向けの一般推論ライブラリ。公式 docs でも native LLM は out of the box ではなく、TensorRT-LLM との統合も現時点では unavailable とされている。
TensorRT Edge-LLM は TensorRT-LLM の別名か？	No。TensorRT-LLM は desktop / data center を含む NVIDIA GPU 向けの LLM 最適化ライブラリ、TensorRT Edge-LLM は Jetson / DRIVE 向けの embedded C++ runtime。
GGML と GGUF は同じか？	No。GGML は tensor library / 実行基盤寄りのプロジェクト、GGUF はモデルを保存するファイル形式。GGUF は GGML および GGML ベース executor 向けの推論用モデル形式で、旧 GGML / GGMF / GGJT 形式の後継。 ([GitHub][30])
GGUF は量子化方式か？	No。GGUF は形式。中に `Q4_K_M` などの量子化済み重みを入れられるが、GGUF 自体は「量子化アルゴリズム」ではない。llama.cpp ではモデルを GGUF 形式で保存・変換して使う。 ([GitHub][31])
GPTQ は GGUF の別名か？	No。GPTQ は post-training quantization 手法。主に Transformer / GPT 系モデルの重みを 2/3/4bit などへ圧縮するための量子化アルゴリズムで、GGUF のようなファイル形式や GGML のようなランタイムではない。 ([GitHub][32])

具体的な選定手順

NVIDIA 本流
- PyTorch / ONNX / 一部 LLM
- TensorRT / TensorRT-LLM / ONNX Runtime + CUDA or TensorRT EP
- CUDA / TensorRT
- Jetson Orin Nano
- これは JetPack に CUDA・TensorRT が入っているので、Jetson では最も自然な本流。 ([NVIDIA Developer][1])
ローカル LLM 汎用路線
- GGUF モデル
- llama.cpp
- CUDA backend / Vulkan backend / CPU
- Jetson Orin Nano
- llama.cpp は複数 backend を同時ビルドでき、CUDA と Vulkan を併用可能。 ([GitHub][29])
Google AI Edge 路線
- .litertlm または .task
- LiteRT-LM / MediaPipe LLM Inference API
- LiteRT
- Linux GPU backend = WebGPU (Vulkan)
- Jetson Orin Nano
- Gemma の LiteRT-LM 系を Jetson で動かすなら、この理解がいちばん自然。 ([Google AI for Developers][18])
軽量 edge 推論路線（mnn）
- .mnn
- MNN / MNN-LLM
- Vulkan など
- Jetson Orin Nano
軽量 edge 推論路線（ncnn）
- ncnn モデル
- ncnn
- Vulkan
- Jetson Orin Nano
- MNN も ncnn も edge/embedded 色が強い。 ([GitHub][20])
RTX PC / workstation 路線
- ONNX モデル / CNN / Diffusion / Speech
- TensorRT-RTX
- GeForce RTX / NVIDIA RTX PRO
- Windows / Linux
- これは Jetson ではなく、RTX PC / workstation 向けの NVIDIA 路線
- TensorRT-RTX は RTX GPU 向けの compact inference library で、build once / deploy anywhere に寄せた設計

[1]: https://developer.nvidia.com/embedded/jetpack-sdk-62"JetPack SDK" [2]: https://github.com/QwenLM/qwen3 “Qwen3 is the large language model series …” [3]: https://docs.nvidia.com/cuda/cuda-programming-guide/ “CUDA Programming Guide” [4]: https://onnxruntime.ai/docs/ “ONNX Runtime | onnxruntime” [5]: https://ai.google.dev/edge/litert-lm/overview “LiteRT-LM Overview | Google AI Edge” [6]: https://onnxruntime.ai/docs/execution-providers/ “ONNX Runtime Execution Providers” [7]: https://ai.google.dev/edge/mediapipe/solutions/tasks “MediaPipe Tasks | Google AI Edge” [8]: https://docs.nvidia.com/deeplearning/tensorrt/latest/index.html “NVIDIA TensorRT Documentation” [9]: https://nvidia.github.io/TensorRT-LLM/overview.html “Overview — TensorRT LLM” [10]: https://www.khronos.org/opencl/ “OpenCL - The Open Standard for Parallel Programming of …” [11]: https://portablecl.org/ “Portable Computing Language: PoCL” [12]: https://www.vulkan.org/ “Home | Vulkan | Cross platform 3D Graphics” [13]: https://www.khronos.org/opengl/ “OpenGL - The Industry’s Foundation for High Performance …” [14]: https://www.khronos.org/webgl/ “WebGL - Low-Level 3D Graphics API Based on OpenGL ES” [15]: https://www.w3.org/TR/webgpu/ “WebGPU” [16]: https://ai.google.dev/edge/mediapipe/solutions/genai/llm_inference “LLM Inference guide | Google AI Edge” [17]: https://ai.google.dev/gemma/docs/conversions/hf-to-mediapipe-task “Convert Hugging Face Safetensors to MediaPipe Task | Gemma” [18]: https://ai.google.dev/edge/litert/next/litert_lm_npu “Run LLMs using LiteRT-LM | Google AI Edge” [19]: https://github.com/alibaba/MNN/blob/master/tools/converter/README.md “MNN/tools/converter/README.md at master - GitHub” [20]: https://github.com/alibaba/mnn “MNN: A blazing-fast, lightweight inference engine battle- …” [21]: https://github.com/Tencent/ncnn/wiki/how-to-build “how to build · Tencent/ncnn Wiki” [22]: https://ai.google.dev/edge/litert “LiteRT: High-Performance On-Device Machine Learning …” [23]: https://github.com/ggml-org/llama.cpp “ggml-org/llama.cpp: LLM inference in C/C++ - GitHub” [24]: https://github.com/alibaba/MNN/blob/master/transformers/README.md “MNN/transformers/README.md at master · alibaba/MNN - GitHub” [25]: https://onnxruntime.ai/docs/execution-providers/CUDA-ExecutionProvider.html “CUDA Execution Provider - onnxruntime” [26]: https://onnxruntime.ai/docs/execution-providers/TensorRT-ExecutionProvider.html “NVIDIA - TensorRT | onnxruntime” [27]: https://ai.google.dev/edge/litert/next/gpu “GPU acceleration with LiteRT | Google AI Edge” [28]: https://ai.google.dev/gemma/docs/run “Run Gemma content generation and inferences” [29]: https://github.com/ggml-org/llama.cpp/blob/master/docs/build.md “llama.cpp/docs/build.md at master · ggml-org/llama.cpp · GitHub” [30]: https://github.com/ggml-org/ggml “GitHub - ggml-org/ggml: Tensor library for machine learning · GitHub” [31]: https://github.com/ggml-org/llama.cpp “GitHub - ggml-org/llama.cpp: LLM inference in C/C++ · GitHub” [32]: https://github.com/ist-daslab/gptq “GitHub - IST-DASLab/gptq: Code for the ICLR 2023 paper "GPTQ: Accurate Post-training Quantization of Generative Pretrained Transformers". · GitHub”

OpenClawの設定備忘録

Wed, 01 Apr 2026 19:54:43 +0900

背景

最近はローカルDevサーバーでOpenClawを使っている
サーバーはubuntu serverで、discordとcodexを使う
便利だが複数回セットアップするのが大変なのでメモを残す
簡単に設定するため、Adminなど権限過多になっているので注意

Discord

Discordの設定

Discord > Advanced > Developer Mode: ON

Discordのサーバーの作成

Discord > Navibar > Create My Own > For me and my friends
channelはprivateにした

DiscordのBotの作成

Discord Developer Portal で New Application を作成
- https://discord.com/developers/applications
Bot
- usernameとiconの設定をする
- 後々ここのtokenを取得する
Privileged Gateway Intents ですべての項目をON にして保存（以下など）
- Message Content Intent
- Server Members Intent
- Presence Intent
自分のServerにインストール
- OAuth2 -> URL Generator で Scopeはbot > PermissionはAdministrator を選択
- Guild Installを選択
- 生成された URL をブラウザに貼り付け、自分のサーバーに Bot を招待

Priviledge Gateway Intentsのおすすめ

オプション	推奨設定	説明
Public Bot	オフ	オフにすると、あなた（Application Owner）のみがBotをサーバーに招待可能。他者が無断でAI Botを別サーバーに追加するのを防止
Requires OAuth2 Code Grant	オフ	OpenClawはOAuth2認証フローが不要なため、オフのまま
Message Content Intent	オン	必ず有効化。有効でなければBotがメッセージ内容を読み取れない
Server Members Intent	必要に応じて有効化	エージェントがメンバー情報のクエリやロール権限チェックを必要とする場合に有効化
Presence Intent	オフ	エージェントがメンバーのオンライン/オフライン状態を検知する必要がない限りオフにし、リソースを節約

OpenClaw

OpenClawのInstall

これはNixで入れたので割愛。

OpenClawの設定

SSH先でOAuthを開くので、openai codex用にsshのポートフォワードをセットアップする。

1

ssh dev -L 1455:localhost:1455

oepnclawの設定:

openclaw onboard
Risk Acknowledgement: リスクについての確認。y
Onboarding mode: QuickStart
Model/auth provider: とりあえずCodex
API キーの入力や、OAuth によるブラウザ認証（Google Antigravity OAuth など）を行う
Channel Setup: ここで Discord を選択
取得した Discord Bot Token を入力
- これはDiscord Portal > Bot > Reset Tokenボタンから取れる
Skills/Hooks: とりあえずなし

起動確認

次のコマンドで起動確認した。systemd –userなので、user単位で動いていた。これでBotもうごくようになった。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


┌── dev ~/dotfiles (main Dirty=) py=3.12.13
└─▶ systemctl --user status openclaw-gateway.service
● openclaw-gateway.service - OpenClaw Gateway (v2026.3.12)
 Loaded: loaded (/home/mike/.config/systemd/user/openclaw-gateway.service; enabled; preset: enabled)
 Active: active (running) since Mon 2026-03-30 01:01:43 JST; 20min ago
 Main PID: 3256295 (openclaw-gatewa)
 Tasks: 11 (limit: 37720)
 Memory: 642.6M (peak: 652.9M)
 CPU: 11.726s
 CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/openclaw-gateway.service
 └─3256295 openclaw-gateway

Mar 30 01:02:02 dev node[3256295]: 2026-03-30T01:02:02.721+09:00 [tools] read failed: ENOENT: no such file or directory, access '/home/mike/.openclaw/worksp>
Mar 30 01:02:19 dev node[3256295]: 2026-03-30T01:02:19.143+09:00 [tools] tools.profile (coding) allowlist contains unknown entries (apply_patch, image). The>
Mar 30 01:03:08 dev node[3256295]: 2026-03-30T01:03:08.827+09:00 [tools] tools.profile (coding) allowlist contains unknown entries (apply_patch, image). The>
Mar 30 01:03:38 dev node[3256295]: 2026-03-30T01:03:38.840+09:00 [tools] tools.profile (coding) allowlist contains unknown entries (apply_patch, image). The>
Mar 30 01:07:29 dev node[3256295]: 2026-03-30T01:07:29.671+09:00 [tools] tools.profile (coding) allowlist contains unknown entries (apply_patch, image). The>
Mar 30 01:08:00 dev node[3256295]: 2026-03-30T01:08:00.386+09:00 [tools] tools.profile (coding) allowlist contains unknown entries (apply_patch, image). The>
Mar 30 01:13:46 dev node[3256295]: 2026-03-30T01:13:46.103+09:00 [ws] ⇄ res ✓ channels.status 516ms conn=6e689ce2…8d2d id=c0795fd5…47fa
Mar 30 01:19:27 dev node[3256295]: 2026-03-30T01:19:27.631+09:00 [tools] tools.profile (coding) allowlist contains unknown entries (apply_patch, cron, image>
Mar 30 01:19:51 dev node[3256295]: 2026-03-30T01:19:51.020+09:00 [tools] tools.profile (coding) allowlist contains unknown entries (apply_patch, cron, image>
Mar 30 01:20:05 dev node[3256295]: 2026-03-30T01:20:05.642+09:00 [tools] tools.profile (coding) allowlist contains unknown entries (apply_patch, cron, image>

ログ確認

1
2
3
4
5
6
7
8


└─▶ journalctl --user -u openclaw-gateway.service
Mar 30 01:01:43 dev systemd[3029]: Started openclaw-gateway.service - OpenClaw Gateway (v2026.3.12).
Mar 30 01:01:44 dev node[3256295]: (node:3256295) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative inste>
Mar 30 01:01:44 dev node[3256295]: (Use `node --trace-deprecation ...` to show where the warning was created)
Mar 30 01:01:47 dev node[3256295]: 2026-03-30T01:01:47.207+09:00 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root /home/mike/.open>
Mar 30 01:01:47 dev node[3256295]: 2026-03-30T01:01:47.244+09:00 [heartbeat] started
Mar 30 01:01:47 dev node[3256295]: 2026-03-30T01:01:47.248+09:00 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
Mar 30 01:01:47 dev node[3256295]: 2026-03-30T01:01:47.252+09:00 [gateway] agent model: openai-codex/gpt-5.4

直近のみ。

1

journalctl --user -u openclaw-gateway.service -n 100 -f

clawの設定

設定ファイルは~/.openclaw/workspaceにある。

IDENTITY.md: AI自身のアイデンティティ（名前、性格、口調など）
USER.md: ユーザー（自分）に関する情報
MEMORY.md: 長期記憶。重要な事実や文脈がここに蓄積される
SOUL.md: AI の行動原理や「魂」にあたる部分。
- このファイルは非常にユニークで、対話を通じて「実行前には必ず確認してほしい」とか「定期的にリポジトリを同期して」といったルールが追記されていく。
- git log で履歴を見ると、AI が指導を受けて成長していく様子が分かる
AGENTS.md, TOOLS.md: エージェントの構成や使用可能なツールの定義

/statusのコマンドでの、You are not authorized to use this commandエラーの対策。 User > Copy User IDからUserIdをコピーする。

1

openclaw config set channels.discord.allowFrom '["YOUR_USER_ID"]'

左のNaviバーでアイコンを右クリック>ServerIDのコピー。下のYOUR_SERVER_IDをリプレイスする。

1
2
3


openclaw config set channels.discord.groupPolicy '"allowlist"' --strict-json
openclaw config set channels.discord.guilds.YOUR_SERVER_ID.requireMention false --strict-json
openclaw config set channels.discord.guilds.YOUR_SERVER_ID.users '["YOUR_USER_ID"]' --strict-json

設定のリスタートをする。

1

openclaw gateway restart

設定の変更結果。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


 "channels": {
 "discord": {
 "enabled": true,
 "token": "xxx.xxx.xxx",
 "groupPolicy": "allowlist",
 "streaming": "off",
 "allowFrom": [
 "YOUR_USER_ID"
 ],
 "guilds": {
 "YOUR_SERVER_ID": {
 "requireMention": false,
 "users": [
 "YOUR_USER_ID"
 ]
 }
 }
 }
 },

参考文献

OpenClaw x Discordサーバー連携ガイド：コミュニティAI Botデプロイの実践 | MIlaw x Discordサーバー連携ガイド：コミュニティAI Botデプロイの実践 | MI](https://www.meta-intelligence.tech/ja/insight-openclaw-discord)
Discord × OpenClaw 実践セットアップ — 設定はAIとの対話で終わる｜Karry
OpenClaw を Discord で動かす
openclaw.jsonの設定変わりすぎじゃない？｜御手洗梢