Static Embedding は Transformer を使っておらず、トークンごとに決まったベクトルを持ち、文章のベクトルはその平均を取るだけです。GPU も不要で、multilingual-e5-small などのモデルと比べて CPU で100〜400倍高速に動かせます。

bekko-static-embedding-v1 では独自に学習した20万語彙の tokenizer を使い、40言語、約8.1億組のテキストペアを16,384のバッチサイズで対照学習しました。

Transformer モデルにもタスクによっては競争力がある性能です。MMTEB の検索タスクでは、12層の Transformer モデルである multilingual-e5-small との差が約1ポイントでした。

性能比較

他の Static Embedding との比較

bekko-static-embedding-v1 は、多言語検索と英語検索のどちらでも、比較した公開 Static Embedding をすべて上回りました。

• 多言語検索：MNanoBEIR（14言語×13タスク、nDCG@10 × 100）は43.76で、static-similarity-mrl-multilingual-v1（32.29）と potion-multilingual-128M（32.23）を約11ポイント上回りました。
• 英語検索：NanoBEIR-en（13タスク）は53.71で、英語専用の stable-static-embedding-fast-retrieval-mrl-en-v2（以下 SST-v2、51.57）と static-retrieval-mrl-en-v1（50.35）を上回り、512次元に切り詰めても（52.82）両モデルより高いスコアです。
• MMTEB：131タスクの平均は50.18で、2つの多言語 Static Embedding より約3ポイント高く、Retrieval カテゴリでは8.75ポイントと12.10ポイントの差がつきました。
• マトリョーシカ次元：512次元に切り詰めても、検索スコア平均の低下は約0.9ポイントです。

表1：既存の Static Embedding との比較。 NanoBEIR-en は英語検索13タスク、MNanoBEIR は14言語の検索182タスク、MMTEB は分類なども含む131タスクの平均です。 検索列は上位10件の順位と関連度を測る nDCG@10 × 100、MMTEB は各タスクの主指標を100倍した値です。

文脈ありモデルとの比較

Transformer の層をまったく持たないモデルは、Transformer のエンコーダにどこまで近づけるのでしょうか。 比較対象には、小型の多言語検索モデルとしてよく使われる multilingual-e5-small（12層、アクティブパラメータ2,160万）を選びました。

表2：文脈ありモデルとの比較。 NanoBEIR-en と MNanoBEIR は HAKARI-Bench の nDCG@10 × 100 です。 multilingual-e5-small と bekko-embedding-v1-a8m の MMTEB は、同じ131タスクと集計方法による bekko-embedding-v1-a8m のモデルカードの値です。 アクティブパラメータはトークン埋め込み表を除いた数です。

MMTEB の Retrieval では、Transformer の層を1つも動かさずに、multilingual-e5-small との差が約1ポイント（49.96と50.9）でした。 Nano dataset の検索や MMTEB 全体の平均ではまだ multilingual-e5-small の方が高く、MMTEB 平均の差の多くは BitextMining、Reranking、STS によるものです。

小さな Transformer を動かせる環境なら、自分が公開している bekko-embedding-v1-a8m は、アクティブパラメータ770万で表のすべての列で multilingual-e5-small を上回り、CPU でも動きます。 また検索では BM25 も強力なベースラインなので、後半で詳しく比較します。

自分は bekko-static-embedding-v1 の作者で、評価に使った HAKARI-Bench の開発者でもあります。

Static Embedding の仕組み

静的埋め込み（Static Embedding） は、文章を tokenizer でトークンに分け、トークンごとに決まったベクトルを割り当てるモデルです。 文章のベクトル化は、表から各トークンのベクトルを引いて平均を取るだけです。 Transformer の層を通す計算がないので、ベクトルを高速に作れます。

Sentence Transformers での使い方

モデルは Sentence Transformers からそのまま読み込めます。 次の例では、「寿司はおいしい」を英語、フランス語、スペイン語、中国語でベクトル化しています。

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("hotchpotch/bekko-static-embedding-v1", device="cpu")
vectors = model.encode(
    [
        "Sushi is delicious.",
        "Les sushis sont délicieux.",
        "El sushi es delicioso.",
        "寿司很好吃。",
    ],
    normalize_embeddings=True,
)
print(vectors.shape)  # (4, 1024)
print(model.similarity(vectors, vectors))

クエリと文書は同じ方法でベクトル化でき、query: や passage: のような接頭辞は不要です。 短いベクトルを使いたいときは、truncate_dim（32、64、128、256、512、1024）を指定します。

compact = model.encode(["A short query"], truncate_dim=512, normalize_embeddings=True)

MMTEB での評価

多言語での埋め込み性能を測る MMTEB（Massive Multilingual Text Embedding Benchmark） は、検索、文章分類、クラスタリング、文同士の意味的な近さを測る STS（Semantic Textual Similarity） などを含むベンチマークです。 今回は、その中の MTEB(Multilingual, v2) に含まれる131タスクで、出力を切り詰めない1024次元を評価しました。

比較対象は、Sentence Transformers の static-similarity-mrl-multilingual-v1 と、Model2Vec 系の potion-multilingual-128M です。 比較モデルは公開されている評価結果を使い、同じ131タスクで平均を取りました。

表3：MMTEB の各タスクの主指標 × 100 を、カテゴリごとに平均した値です。 「差」は bekko-static-embedding-v1 − static-similarity-mrl-multilingual-v1 です。

全タスク平均は bekko-static-embedding-v1 が50.18で、static-similarity-mrl-multilingual-v1 の47.24、potion-multilingual-128M の47.23を約3ポイント上回りました。

比較した2モデルとの差がそろって大きいのは Retrieval です。 bekko-static-embedding-v1 は49.96で、static-similarity-mrl-multilingual-v1 を8.75ポイント、potion-multilingual-128M を12.10ポイント上回っています。 多言語の検索は、このモデルの強みです。

static-similarity-mrl-multilingual-v1 に対しては、9カテゴリ中6カテゴリで上回りました。 カテゴリ別の差が最も大きいのは Clustering の+9.36ポイントで、STS は+0.47ポイントとほぼ同等です。

一方、対訳文を探す BitextMining、文のペアを分類する PairClassification、指示付きの InstructionReranking では、static-similarity-mrl-multilingual-v1 の方が高くなりました。 特に BitextMining は43.68と50.62で、6.94ポイントの差があります。 対訳文の抽出や文ペアの分類が主な用途なら、static-similarity-mrl-multilingual-v1 も並べて試すとよいでしょう。

HAKARI-Bench による英語検索の評価

検索性能は、HAKARI-Bench の Nano dataset で評価しました。 Nano dataset は、既存の検索ベンチマークを小さくした評価セットです。 以下の HAKARI-Bench の表は、nDCG@10 を100倍し、各タスクを等しい重みで平均した値です。

英語検索には、13タスクと合計649クエリからなる NanoBEIR-en を使いました。 比較する静的モデルは、英語検索用の static-retrieval-mrl-en-v1 と SST-v2 です。 文脈を使う multilingual-e5-small と、自分が公開している文脈ありの小型モデル bekko-embedding-v1-a8m、単語の一致や出現頻度から順位を付ける BM25 も、検索方式を選ぶための参考として並べます。

表4：NanoBEIR-en のタスク平均。 bekko-static-embedding-v1 は1024次元と512次元、比較する埋め込みモデルは各モデルの標準出力次元です。

bekko-static-embedding-v1 の1024次元は53.71で、英語検索用の SST-v2（51.57）と static-retrieval-mrl-en-v1（50.35）を上回りました。 512次元でも、同じ出力次元の SST-v2 より1.25ポイント高く、13タスク中10タスクで上回っています。

ただし埋め込み表の大きさは異なり、bekko-static-embedding-v1 の約2.05億パラメータに対して、SST-v2 は約1,560万パラメータです。

英語検索だけで見れば、bekko-embedding-v1-a8m（60.34）、multilingual-e5-small（58.37）、BM25（57.15）の方が高いスコアで、Static Embedding との差はまだ残っています。

多言語検索と BM25 の比較

多言語検索では、static-similarity-mrl-multilingual-v1、potion-multilingual-128M、multilingual-e5-small、bekko-embedding-v1-a8m、BM25 と比較しました。 MNanoBEIR は14言語×13タスクの計182件です。 HAKARI-Bench ではこのほかにコード検索、長文検索、日本語検索なども含めた37ベンチマーク、550タスクを評価しており、ここではそのうち10ベンチマークを示します。

表5：各ベンチマーク内のタスク平均、nDCG@10 × 100。 static-similarity-mrl-multilingual-v1 は1024次元、potion-multilingual-128M は256次元、multilingual-e5-small と bekko-embedding-v1-a8m は384次元です。 NanoMMTEB-v2 は HAKARI-Bench の検索用セットで、前述の分類なども含む MMTEB とは別の評価です。

static-similarity-mrl-multilingual-v1 に対して、bekko-static-embedding-v1 の1024次元は37ベンチマークすべての平均で上回りました。 タスク単位でも、550件中523件で上回り、27件で下回っています。

potion-multilingual-128M に対しては、37ベンチマーク中36の平均で上回り、タスク単位では550件中520件で上回りました。 例外は NanoIndicQA で、potion-multilingual-128M が53.69、bekko-static-embedding-v1 が35.35でした。

一方、文脈を使うモデルとの差はまだ残っています。 multilingual-e5-small は37ベンチマーク中28、bekko-embedding-v1-a8m は36の平均で bekko-static-embedding-v1 を上回り、MNanoBEIR ではそれぞれ51.17と52.65です。

長文検索の NanoMLDR と NanoLongEmbed では multilingual-e5-small を上回りましたが、これには multilingual-e5-small の入力上限が512トークンであることも影響しています。 入力上限が8192トークンの bekko-embedding-v1-a8m と比べると、NanoLongEmbed では bekko-embedding-v1-a8m が68.19と高く、NanoMLDR では bekko-static-embedding-v1 が55.72と54.48でわずかに上回りました。

検索に Static Embedding を使うべきか

検索だけが目的なら、BM25 で十分なことも多いでしょう。 今回の評価でも、BM25 は37ベンチマーク中21の平均で bekko-static-embedding-v1 を上回り、タスク単位では550件中342件で上回りました。 長文検索の NanoMLDR と NanoLongEmbed、日本語の NanoJMTEB-v2 では、BM25 が大きく上回っています。

一方、自然言語の質問から文書を探す NanoMIRACL では、bekko-static-embedding-v1 が68.03、BM25 が57.15で、Static Embedding の方が10.88ポイント高くなりました。 検索タスクによっては、Static Embedding の方が適しています。

BM25 は単語の一致で文書を探すため、質問と文書で言い回しが異なる場合には埋め込み検索が役立ちます。 どちらが適しているかは、実際の検索対象で両方を試してみるのが確実です。

マトリョーシカ次元と INT8 の選択

1024、512、256、128、64、32次元は、Matryoshka Representation Learning（MRL） でまとめて学習しました。 MRL は、ベクトルの先頭側に有用な情報を集め、先頭の一部だけを取り出しても使えるようにする学習方法です。 用途に合わせてベクトルの長さを選び、保存容量や検索時の計算量を減らせます。

重みの保存精度は、FP16 に加えて INT8 も用意しています。 ここでの INT8 はモデルの重みを8 bit整数にしたもので、出力ベクトルを整数にする操作とは別です。

表6：マトリョーシカ次元と重みの保存精度による検索スコア。 Overall は550タスク平均で、すべて nDCG@10 × 100です。 INT8 は ONNX の結果です。

1024次元から512次元にすると、ベクトルの長さは半分になり、検索スコアの低下は NanoBEIR-en と MNanoBEIR のどちらも約0.9ポイントでした。 256次元では、低下が2.88と2.72ポイントに広がります。 それでも MNanoBEIR では、128次元の38.03が1024次元の static-similarity-mrl-multilingual-v1（32.29）を上回ります。 INT8 と FP16 の差は、どの次元でも0.15ポイント未満でした。

自分なら、まず512次元から試し、メモリを抑えたいときは INT8 の512次元か256次元を選びます。

使う次元の重みだけを読み込む

Sentence Transformers の truncate_dim は出力ベクトルを切り詰めますが、読み込むのは全1024次元分の表です。 512次元や256次元しか使わないなら、そのぶんのメモリは無駄になります。

そこで、1つの次元の重みだけを持つ ONNX と OpenVINO のファイルもリポジトリに置いています。 モデルカードには、形式、次元数、保存精度を選んで読み込む小さな get_model() ヘルパーを載せています。

from transformers.dynamic_module_utils import get_class_from_dynamic_module

def get_model(backend="onnx", dim=512, precision="int8", revision="main"):
    repo = "hotchpotch/bekko-static-embedding-v1"
    ext = {"onnx": "onnx", "openvino": "xml"}[backend]
    return get_class_from_dynamic_module(
        "bekko_static_backend.BekkoStaticBackend", repo, revision=revision,
    ).load_sentence_transformer(
        repo, revision=revision, backend=backend,
        file_name=f"{backend}/model_{precision}_dim{dim}.{ext}",
    )

model = get_model(backend="onnx", dim=512, precision="int8")

表7：次元別に配布するモデルファイルのサイズ（10進の MB）。 ONNX と OpenVINO は同じサイズで、tokenizer（約5.1 MB）は含みません。

たとえば INT8 の512次元は103.2 MBで、FP16 の1024次元（409.6 MB）の約4分の1です。 256次元なら52.0 MBまで小さくなります。

どのモデルを選ぶか

今回の結果から、自分なら次のように選びます。

• 多言語の埋め込みを軽い計算で作りたい場合は、bekko-static-embedding-v1 の512次元から試す。
• 検索だけが目的なら、対象言語に合った BM25 と並べて比較する。
• 対訳文の抽出や文ペアの分類が中心なら、static-similarity-mrl-multilingual-v1 も比較する。
• 検索精度を優先し、Transformer の計算を許容できるなら、multilingual-e5-small や bekko-embedding も候補に入れる。

bekko-embedding は、bekko-static-embedding-v1 とは異なり、Transformer の attention で文脈を扱う埋め込みモデルです。 Transformer 部分の重みを小さくしており、たとえば bekko-embedding-v1-a8m は約770万のアクティブパラメータで、CPU でも推論できます。 今回の比較でも、bekko-embedding-v1-a8m は NanoBEIR-en が60.34、MNanoBEIR が52.65で、どちらも multilingual-e5-small より高いスコアでした。 検索性能と推論速度のバランスを重視したい場合は、bekko-embedding も検討するとよいでしょう。

学習の方法

独自 tokenizer の設計と比較

Static Embedding では、tokenizer が作る単位が、そのまま平均するベクトルの単位になります。 そこで、多言語 BERT や Gemma 2 の既存語彙に加えて、学習データに合わせた語彙を試しました。 多言語の静的モデル static-similarity-mrl-multilingual-v1 が使う bert-base-multilingual-uncased も比較対象にしています。

独自語彙の学習には、単語をさらに小さな断片に分けられる WordPiece を使いました。 まず、Wikipedia と FineWeb から同数ずつ文書を取り、英語の3万語彙を学習します。 次に、英語のトークンIDを保ったまま39言語分の語彙を追加し、全体を20万語彙にしました。

語彙の選択には、学習データの10%を使って各 tokenizer で学習した8モデルを比較しました。 評価は、多言語検索の MNanoBEIR（14言語×13タスク）と NanoMIRACL（18言語）の計200件です。 nDCG@10 を100倍し、200件を等しい重みで平均しています。

表の「uncased」は大文字と小文字を区別しない設定、「cased」は区別する設定です。 「script-balanced」は、文字体系ごとの偏りを調整した候補を指します。 語彙数の「k」は千を表し、たとえば「200k、英語30k」は全20万語彙のうち英語3万語彙を先に確保した構成です。

表8：tokenizer 別の検索スコア、nDCG@10 × 100。 8モデルは同じデータと学習設定で比較しました。 この10%実験では正式版とは異なる対照学習の損失を使っており、正式版モデルのスコアとは直接比較できません。

最も高かったのは、20万語彙、英語3万語彙の uncased 版でした。 1024次元の41.89は、多言語 BERT uncased の37.87、Gemma 2 の38.73を上回ります。 この結果から、正式版にも同じ tokenizer を採用しました。

学習データとハイパーパラメータ

モデルの学習には、bekko-embedding の unsupervised データセット を使いました。 元のデータは、Bekko Embedding 論文で説明した多言語データです。

そのうち40言語を対象とする265のデータ構成から、約8.1億件のテキストペアを学習に使いました。

対象の40言語は、英語、アラビア語、ブルガリア語、ベンガル語、カタルーニャ語、チェコ語、デンマーク語、ドイツ語、ギリシャ語、スペイン語、エストニア語、ペルシア語、フィンランド語、フランス語、ヘブライ語、ヒンディー語、クロアチア語、ハンガリー語、インドネシア語、イタリア語、日本語、韓国語、オランダ語、ノルウェー語、ポーランド語、ポルトガル語、ルーマニア語、ロシア語、スロバキア語、スロベニア語、セルビア語、スウェーデン語、スワヒリ語、テルグ語、タイ語、トルコ語、ウクライナ語、ベトナム語、ヨルバ語、中国語です。

学習する組には、文書のタイトルと本文、質問と回答、検索向けに生成したクエリ、対訳ペアなどが含まれます。 対訳データは NLLB English HQ を残し、ほかの対訳系列を選択から外しました。 MIRACL の train split や NLI に由来するデータも含みます。

埋め込み表はランダムに初期化し、対応するテキストの組が近くなるように学習します。 損失には、同じバッチ内のほかの候補と区別する Multiple Negatives Ranking Loss（MNRL） を使い、全1024次元と各マトリョーシカ次元に適用しました。 教師モデルの出力ベクトルを模倣する蒸留は行っていません。

表9：正式モデルの学習設定。

再現用スクリプト

モデルのリポジトリには、tokenizer 学習、モデル学習、FP16 書き出しのスクリプト を置いています。 学習設定とデータの選択設定も含めているので、データの選択から FP16 での書き出しまでを追えます。

HAKARI-Bench の結果

HAKARI-Bench の結果は、leaderboard で確認できます。 リンク先では、multilingual-e5-small、bekko-embedding-v1-a8m と、名前に static を含むモデルを比較できます。

参考文献と関連実装

• Yuichi Tateno, Bekko Embedding: Parameter-Efficient Multilingual Retrieval with Ultra-Compact Encoders, 2026。 学習データの背景となる、文脈付き Bekko Embedding の論文。
• Yuichi Tateno, HAKARI-Bench: A Lightweight Benchmark for Comparing Retrieval Architectures and Efficiency Settings under Unified Conditions, 2026。 検索方式や次元削減を比較する軽量評価の設計。
• Kenneth Enevoldsen et al., MMTEB: Massive Multilingual Text Embedding Benchmark, 2025。 多言語の分類、類似度、検索などを評価するベンチマーク。
• Aditya Kusupati et al., Matryoshka Representation Learning, 2022。 先頭の一部の次元でも使える表現を学習する方法。
• Nandan Thakur et al., BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models, 2021。 異なる検索タスクと検索方式の比較。
• Xinyu Zhang et al., Making a MIRACL: Multilingual Information Retrieval Across a Continuum of Languages, 2023。 18言語の自然言語質問と関連文書の評価データ。
• Stephan Tulkens and Thomas van Dongen, Model2Vec: Fast State-of-the-Art Static Embeddings, 2024。 Sentence Transformer から静的埋め込みを作るソフトウェアと技術解説。
• Minish Lab, potion-multilingual-128M。 Model2Vec 系の多言語モデルと学習方法。
• Tom Aarsen, Train 400x faster Static Embedding Models with Sentence Transformers。 静的モデルの学習方法と既存2モデルの解説。
• RikkaBotan, Stable Static Embedding 技術レポートとSSE Retrieval MRL v2 技術レポート。 静的な英語検索モデルの設計と評価。

• 森バジル: ノウイットオール
• 森バジル: なんで死体がスタジオに!?
• 夕木春央: 楽園

ノウイットオールは高校生がM-1に挑戦する話があって、成瀬は天下を取りにいくでもM-1を狙うくだりがあったよなぁ。どちらもアツく語られていて面白かった。自分は M-1 をみたことがないのだが…。

夕木春央氏の楽園は、最近の2文字シリーズの3作目なのかな。以前の話とは違い、殺害される人は凶悪犯で、主人公は狙われない、という設定なので、ハラハラ感がなかったのだよなぁ。

前作の探偵小石は恋しない、の続編は作るの難しそうだよなーと思っていたのだけど、期待を裏切る面白さだった。前作は今はKindle Unlimitedで配信中なので、未読の方はぜひ（前作も面白い）。

ちびっこ相撲(強そうだったが、負けた子がワンワン泣いてかわいかった)、アンパンマン列車、巨大な空気滑り台、ハムスターレース、等々、子供にとって楽しそうなイベント。ベコ氏もアンパンマン列車に見て乗って大はしゃぎ。乗ると、認知できなくなくなるから、見ている方が楽しそうではあった。家族でのタンデム自転車での一周も和やかな空間で最高だったなぁ。

最初の目的地の予定だった、玉川村の乙字ケ滝。阿武隈川唯一の滝らしい。高さはないが、広さはあって、そこそこの見所。横の「乙な駅 たまかわ」(隈研吾氏設計。ルーバーっぽい見た目）に立ち寄って帰る。

帰りは体調がすぐれず、妻に運転してもらったのだけど、途中でカメラがないことに気づいてあたふたしていたのだけど、家に着くとポケットからカメラが普通に出てきて呆れられる。ハハハ…。

ベコ氏の保育園の秋祭り。秋祭りの係りだったので妻は前日、当日と調理担当。私はベコ氏の見守り役。天然色素での染め物、フェルト加工、芋掘り、人形劇、とどれも楽しそう。ベコ氏はもうちょっと大きくなったらだね。

他にも 円形ディスプレイに Spotify カバーアートを表示するデバイスを作った話や、プロンプトだけでオレオレカスタムキーデバイスを作った話（後編・基板から作る）もPCBをエーアイ氏経由で作ったりして、自分の範疇じゃない部分をエーアイ氏にやってもらっていて、面白いのだよなぁ。

https://saqoo.sh/a/のフィード欲しい！

そろそろ朝は寒く、手が悴むので、机の上に敷く卓上ヒートカーペット(?)を出す。使っているのはLafuture ぽかぽかデスクマットヒーター レギュラーサイズ。小さいサイズがちょうどキーボードとマウス(うちのマウスパッドは小型)にフィットするんだよね。冬はこれがないとやってられないんだよなぁ。愛用品。

そして一番面倒なのが記事やドキュメントを書くことなんだけど、最近は開発中にやっていること(成功も失敗も)を全てまとめているので、結果のファクトや手順なども作り、エーアイ氏と雑談しながら草稿を書いて、最後に整えて完了。当初は GTP-6.1-Sol で全てをやっていたのだけど、日本語記事はどうやっても品質が悪く、Opus 5.5 氏に代わってもらったところ、十分な品質の文体になったのでよかったよかった。

ベコ氏の「はじめてトミカ」。床に投げつけてもプラスチックなのでほとんど傷つかない。摩擦抵抗が少ないのか、めちゃくちゃスムーズに走る。床なら10m以上走る感じですごいね。

• saihai-v1-8b
• saihai-v1-8b-gguf
• saihai-v1-310m (小型モデル)

saihai-8b は、オープンかつ日本語に強い大規模言語モデル llm-jp-4.1-8b-thinking を基盤モデルとし、Decision モデルとしてのファインチューニングを行った 8B サイズのモデルです。llm-jp のモデルを用いることで、日本のドメイン知識を最大限活かすことができそうですね。ライセンスも llm-jp と同じ Apache 2.0 です。

通常のモデル重みに加えて GGUF も公開しているので、各所で利用されている推論エンジン llama.cpp に最近追加された /v1/systemone API エンドポイントでも利用できるようにしています。

また、小型の saihai-310m も合わせて公開しました。こちらは decoder の LLM ではなく、bekko-system-one と同じアプローチで学習した encoder モデルで、日本語の reranker である ruri-v3-reranker-310m をベースにしています。ライセンスは ruri と同じ Apache 2.0 です。

なお、記事の後半にはテクニカルノートも書いているので、技術方面に興味がある方はご覧ください。

日本語 Decision モデルベンチマーク

日本語でのモデル性能を測るため、S1MB (System One Mosaic Benchmark) の日本語ベンチマークセット japanese-v1 を作成しました。すでに公開されている NLI などの日本語の特定タスクのデータセット 19 タスクと、今回 Decision モデル用に GPT-6.1-Sol を用いて作成した合成データセット 8 タスクを組み合わせたもので、27 タスクのベンチマークとなります。また、評価結果は S1MB の leaderboard で確認できます。

• https://huggingface.co/spaces/hotchpotch/S1MB-leaderboard?category=japanese-v1

タスクは回答の型によって次の 3 種類に分けています。

• Noul: はい / いいえの二択
• Choice: 複数の候補からの選択
• Score: 0, 1, 2, 3, ... といった段階でのスコア付け

結果は以下です。Jev には及ばないまでも、saihai-8b は 8B というモデルサイズながら、そこそこのパフォーマンスですね。

ここでは Jev・GPT-6 Luna の API モデルと、パラメータ数が 12B 以下のモデルから選んで掲載しています。27B クラスのモデルなどを含む全体の結果は、leaderboard をご覧ください。各列で Jev・GPT-6 Luna を除いた最良の値を太字にしています。

注意点として、saihai は日本語タスクを解きやすくするため、いくつかのベンチマークタスクの元データセットの train set を学習しているので、ベンチマークの点数は上がりやすくなっています (test set と重複するデータは、できる限り除いています)。その影響を調べた対照実験の結果は後半に載せています。

表の見方は次のとおりです。

• Noul・Choice・Score の 3 列は、既存データセット由来 19 タスクと合成 8 タスクの計 27 タスクを、それぞれ型ごとに平均した値です。「汎用」の 3 列は、そのうち合成 8 タスクだけを型ごとに平均した値です。
• Task Avg は、Noul・Choice・Score の 3 列を等重みで平均した総合値です。「汎用」の 3 列は Task Avg に別途加算されていません。
• 値は 0〜100 で、小数 2 桁に丸めています。どれも基準値から調整したスコアで、単純な正解率ではありません。

saihai-8b は、近いパラメータ数のモデルと比べても健闘していると感じます。評価対象と同じ元データセットの train を一部学習しているとはいえ、日本語の特定タスクを解くモデルとしては、よい結果になりました (後述の比較では、日本語で作られたタスクで特に強い結果でした)。一方、合成タスクの Noul では Winnow 12B や Jebadiah 9B v2 を、Choice では多くのモデルを下回り、Score にも差が見られます。特定タスクでの強さと、柔軟な入力への対応力には差があるようです。

OpenAI の Decision モデルである GPT-6 Luna (Decisions API) は、Task Avg 55.00 と Jev に迫る結果でした。Noul (62.10) と汎用 Noul (67.11) では Jev を上回っています。なお、GPT-6 Luna は API が回答を拒否した判断があり (日本語では 1 件)、その判断は不正解として採点しています。

小型の saihai-310m は、Task Avg 30.19 と、数 B クラスの decoder モデルとはまだ差があります。ただ、同じく encoder アーキテクチャで同程度のサイズの Laya multilingual (Task Avg 5.29) と比べると、かなり良い性能です。特に Choice は 40.99 で、JCommonsenseQA (89.58)・KUCI (82.67)・JNLI (79.00) などではそれなりの性能を示しています。Noul も CommonsenseMoralJA (74.67) や合成の Diverse (65.33) ではそこそこ解けています。一方、知識や数理を問う合成タスクはほぼ解けておらず、汎用 Score は 0.00 でした。また、saihai-310m は評価対象と同じ元データセットの train を、saihai-8b よりもずっと多く学習しているので (後述)、その分スコアは上がりやすくなっている点にご注意ください。

Decision モデルというと、decoder アーキテクチャの大きなモデルが目立ちますが、小型の encoder モデルでも、将来は Decision モデルとして十分な性能のものが現れるのでは、と期待しています。

既存の日本語データセットの活用

既存の日本語データセットは、タスクごとに Noul・Choice・Score のどの型が合うかを考えて割り振りました。データは原作者が用意した test set を基本とし、一部は validation や train、もともと分割されていない問題群も使っています (例外は後述)。各タスクは最大 300 件です。なお、この手法に興味がある方は、IVRy さんの「日本語ベンチマークで Jev の性能を検証する」に具体的な方法がわかりやすく書かれているので、参照ください。

これらのデータを、Decision モデルが回答しやすい instruction・state の構造に変換して評価用データセットを作成しました。同時に、train 用のデータが用意されているものは学習用データセットも作成し、saihai の学習にも使っています。なお、train 用のデータには、まれに test set と同じデータが含まれるため、できる限り削除しています。

以下、ベンチマークと同じ元データセットの train を「系列 train」と呼びます。利用したデータセットは以下で、「系列 train の投入」列は、評価問題ではなく、系列 train から学習に使った件数です。

以下は補足です。

• test set の例外: JCoLA は元の validation、JSeM はもともと train/test に分かれていない問題群、NanoJMTEB は評価用 split、JMMLU Japan は元の split 指定なし、SOBACO Culture は元の train を使っています。GPQA も元の評価用問題群です。すべてが「原作者が定義した test」というわけではありません。
• JSICK は学習側が Choice、評価側が Score ですが、同じ系列として扱っています。
• JMMLU Japan は日本史・慣用句・公民・地理を各 75 件、SOBACO Culture は日本文化の 300 件です。
• 検索タスク (NanoJMTEB) は、JMTEB の検索系ベンチマークを元にした、正例 1 件と非正例 3〜5 件から選ぶ Choice です。検索系のベンチマークを複合しているので、ライセンスは行ごとに異なります。
• ライセンスは素材ごとに条件があり、この表は要約です。JMMLU の科目別の利用制限や、検索素材の帰属・再配布条件は元資料をご確認ください。

合成データセット

ここまでのデータセットは、「特定タスクにフォーカスした」Decision モデルの性能を測るものです。そこで、既存タスクでは測れない「ある程度柔軟な入力に対して、適切な回答を選べるか」を見るタスクを、GPT-6.1-Sol で合成データセットとして生成しました。真の汎化性能を測れているとはいえませんが、便宜上「汎化性能指標」のタスクと呼んでいます。

合成データは 3 系列・8 タスク、合計 2,400 件です。

Diverse には Score タスクがありません。また、以前作った不確実性のタスクは、現在の評価対象から外しています。合成データのライセンスは、OpenAI のモデルを用いて作ったため、CC BY-NC 4.0 としています。また正答は人手による独立したブラインド検証をしていないので、この 8 タスクの点数だけで、あらゆる使い方に汎化できるとは言えません。

英語ベンチマークでの評価

saihai は日本語向けのモデルですが、学習データには英語のデータも多く含まれています。そこで、S1MB の英語ベンチマークセット english-v1 でも評価しました。english-v1 は 137 タスクで、「汎用」の 3 列は、Diverse と Contextual の合成タスク 6 タスク (各型 2 タスク) を型ごとに平均した値です。列の見方は日本語の表と同じですが、タスクの構成が違うので、日本語の表と数値を直接比べることはできません。

日本語の表と同じモデルに、英語の encoder モデルである bekko-system-one-v0-400m・Laya・Laya typed-decisions を加えています。各列で Jev・GPT-6 Luna を除いた最良の値を太字にしています。

英語では、saihai-8b は Task Avg 50.59 で、API モデルを除く decoder モデル 7 つの中では 3 番目でした。Noul は 59.96 と比較的高い一方、Score は 32.29 と低めです。汎用 Noul・Choice も 90 を超えており、日本語向けに学習したモデルながら、英語でも必要十分な性能を持っているといえそうですね。

なお、GPT-6 Luna は英語では Task Avg 49.21 と、日本語ほどの順位ではありませんでした。英語では API が回答を拒否した判断が 17 件あり、不正解として採点しているので、その分も多少影響しています。

saihai-310m は 40.59 で、英語の学習データを bekko-system-one のデータセットの約 10% に絞っていることもあり、bekko-system-one-v0-400m (50.60) より低くなりました。特に汎用 Noul・Score は大きく下がっています。

それでも、英語の encoder モデルである Laya (13.36) や Laya typed-decisions (15.00) と比べると、saihai-310m の Task Avg は 2.5 倍以上で、Noul・Choice・Score のいずれも大きく上回っています。一方、汎用の 3 列は Laya 系と同程度 (汎用 Score はやや下回る) で、柔軟な入力への対応は小型 encoder にとってまだ難しいところですね。

また、英語の汎用 Noul・Choice は、多くの decoder モデルが 90 前後に集まっていて差がつきにくくなっています。数値は直接比べられないものの、日本語の合成タスクでは Jev でも汎用 Noul が 64.67 なので、今回作った日本語の合成タスクは、差がつきやすい問題になっているようです。

saihai モデルの作成

saihai-8b と saihai-310m はアーキテクチャが異なるので、それぞれ分けて説明します。

saihai-8b

モデル作成に使った学習コードとデータセットは、それぞれ公開しています。

• 学習コード: hotchpotch/saihai
• 学習データ: hotchpotch/saihai-v1-dataset

モデルアーキテクチャ

saihai-8b は、いわゆる decoder アーキテクチャの LLM で、現在一般的な Decision モデルの学習方法を用いています。Decision モデルの構造は、まだ汎用的なものが定まっていないのが現状です。ただ、推論エンジンの一つである llama.cpp では、/v1/systemone という推論エンドポイントで Perplexity の pplx-decider-v1-27b の形式が使えるようだったので、それに合わせた構造になるように、学習しています。

学習から推論までの流れは以下です。

1. 学習データの候補と、教師の確率分布を対応付けます。正答や出典情報はモデルの入力に含めません。
2. 指示・状態・候補を JSON にし、基盤モデルの chat template に埋め込みます。候補には、tokenizer で 1 token になる A、B などのコードを割り当てます。
3. 回答を始める直前までを入力し、最後の有効 token の hidden state を取り出します。
4. bias のない FP32 の線形 head で候補の logits を計算し、その問題で使う候補の中で softmax を取ります。head は、元の LM head のうち候補コード token の行から初期化します。
5. 教師の確率分布との cross entropy を損失として、LoRA と候補 head を学習します。backbone は BF16 です。全パラメータを更新するとメモリに載らず、学習も遅くなるため、LoRA を用いています。
6. 配布時には LoRA を merge し、学習した head を元の LM head の候補コード token の行へ書き戻します。推論では 1 回の forward から候補の確率を読み取るだけで、文章や reasoning は生成しません。

候補コードは llama.cpp の pplx-decider と同じ規則で、A〜Z、AA〜ZZ のうち単一 token になるものだけを選び、最大 255 候補に対応させています。Noul の候補順は false → true、Score は 2〜10 段階です。pplx の学習方法を丸ごと再現したわけではなく、候補 token の確率を読み出す仕組みを合わせた形ですね。

学習データ

学習データには、以下の 3 つを使っています。

• 既存の英語 Decision モデルの学習に使われているデータセット。既存データセットから抽出したものや、合成データセットを含みます
• 日本語ベンチマークの元データセットのうち、train にあたるもの (系列 train)
• llm-jp-4.1-32b-a3b-thinking を用いて作成した、日本語の合成データセット

内訳は以下で、合計 33,532 件を学習させています。

学習は LoRA (rank 16 / alpha 32) を用い、RTX 5090 で約 3.62 時間でした (評価や量子化の時間は含みません)。そのほかの条件は、1 epoch、実効 batch size 16、最大入力長 8,192、seed 42 です。279 件の固定 validation を学習中に 10 回測定していますが、validation が最良の step ではなく、最後の checkpoint を使っています。

なお、モデル重みのライセンス (Apache 2.0) と、学習データの素材ごとのライセンスは別です。

saihai-310m

saihai-310m は、bekko-system-one のアプローチで学習した、小型の encoder モデルです。学習コードは bekko-system-one のものを使っています。

• 学習コード・手順: bekko-system-one の saihai-v1-310m 学習ドキュメント
• 学習データ: hotchpotch/saihai-v1-310m-dataset

モデルアーキテクチャ

アーキテクチャは bekko-system-one と同じです。簡単に書くと、instruction と state を共有の prefix として一度だけ処理し、その各層の Key/Value を、各候補 (criteria) の処理で再利用します。各候補は共有 prefix と自分自身だけを参照し、候補側の表現からスコアを計算します。長い state を候補の数だけ処理し直さずに済むので、小さなモデルで効率よく推論できます。詳しくは bekko-system-one の記事をご覧ください。

bekko-system-one では、素の encoder よりも、reranker として学習済みのモデルを初期値にした方が性能が上がりました (特に 68M のモデルで、損失 (CE) と各タスクの精度がともに改善しました)。それに倣い、saihai-310m では日本語の高性能 reranker である ruri-v3-reranker-310m をベースにしています。ruri-v3-reranker-310m は、modernbert-ja-310m を元にした ruri-v3-pt-310m を、reranker として学習したモデルです。パラメータ数は 315M (埋め込み層を除くと 236M) です。

なお、saihai-310m は llama.cpp の /v1/systemone には対応していません。Transformers の AutoModel (trust_remote_code=True) から読み込み、saihai-8b と同じような state・questions 形式の入力で使えます。ただし、入力が長すぎる場合、saihai-8b はエラーにしますが、saihai-310m は入力を切り詰めて推論する点が異なります。

学習データと学習条件

学習データは、以下の 3 つを混ぜて使っています。件数は、1 つの問題に含まれる個々の判断の数です。

日本語の系列 train は、CommonsenseMoralJA・JCommonsenseQA・JNLI・JSTS・KUCI・Mintaka・JaNLI の 7 データセットです。saihai-8b では各データセット 400 件以下に絞っていましたが、saihai-310m では採用した train をすべて使っているので、件数がずっと多くなっています (例えば KUCI は 69,527 判断)。そのため、対応するタスクのスコアは saihai-8b 以上に上がりやすくなっていると思われます。saihai-8b と同様、評価データの問題とその関連データは除いています。

学習は全パラメータを更新し (LoRA は使っていません)、batch size 512 で全データを 1 epoch、約 2 時間 45 分でした。encoder の学習率は 1e-5、head の学習率は 2e-4、入力長の上限は query 4,096 / 候補 2,048 tokens です。

S1MB の評価は、bekko-system-one と同じく、長い入力を切り詰めて入力長を配分する設定で行っています。

対照実験

さて、ベンチマークと同じ傾向のタスクを train に多く含んでいるので、そのせいで性能が高く出ているのでは？という疑問が出ると思います。そこで、saihai-8b について、2 つの対照実験を行いました。最後に、系列 train なしのモデルを外部の Decision モデルとも比べています。

系列 train を学習しなかった場合との比較

LLM-jp 4.1 8B を用いた saihai-8b に加え、Qwen3.5 の 3 サイズのモデルに対しても、系列 train を含めて学習したモデルと、除いて学習したモデルを作って比べました。以下は S1MB の Task Avg です。

多くのモデルでは系列 train を学習させた方が強い結果になっていますが、Qwen3.5 4B では除いた方が 0.43 点高くなりました。系列 train を入れればどのモデルでも総合値が上がる、というわけではないですが、基本的にはスコアが上がりやすくなりました。

では、どのタスクで差が出ているのでしょうか。系列 train を使った 10 タスクと、それ以外の 17 タスク (うち、系列 train を使っていない既存データ由来 9 タスク、合成 8 タスク) に分けて、差を見たのが以下です。タスク群の値は各タスクのスコアの単純平均で、差は「あり − なし」です。プラスなら、系列 train を学習した方が高いことを示します。

LLM-jp 8B では、系列 train を学習したことで、対応する 10 タスクは 8.02 点上がった一方、それ以外の 17 タスクは 0.15 点の上昇にとどまりました。どのモデルでも、対応する 10 タスクだけが大きく上がる同じ傾向で、やはり train を学習した系列のタスクが解きやすくなっている、ということですね。ただ、系列 train を除くと学習データが 33,532 件から 29,643 件に、重みの更新回数も 2,096 回から 1,853 回に減っているので、若干データが減ったことも影響しているかもしれません。

基盤モデルを変えた場合との比較

saihai-8b は llm-jp のモデルを使っているので、他のモデルに比べて日本のドメイン理解が強いと思われます。そこで、Qwen3.5 シリーズのいくつかのモデルも同じ学習データで学習させ、違いを見てみましょう。

ここでは、既存データセット由来の 19 タスクを、次の 2 つに分けています。

• 日本語オリジナル 12: 翻訳ではなく、日本語で一から作られたデータセットの 12 タスクです。日本の知識を問うタスク (後述の文化知識 4) だけでなく、推論や意味の類似度などの言語タスクも含みます。
  • CommonsenseMoralJA、JamC-QA、Jamp、JaNLI、JCoLA、JCommonsenseQA、JCulture-MCQ、JNLI、JSTS、KUCI、JMMLU Japan、SOBACO Culture
• 翻訳・混在 7: 英語などからの翻訳を元にしたものと、複数の元データが混ざったものの 7 タスクです。MMLU-ProX・MMMLU・GPQA のような一般知識の問題が多く含まれます。
  • MMLU-ProX、MMMLU、GPQA、Mintaka、JSICK、JSeM、NanoJMTEB

どちらも記事用に分けたタスク群で、日本語能力全体を定義したものではありません。Task Avg は S1MB の総合値、それ以外の列はそれぞれのタスク群の単純平均です。

全体ではサイズが少し大きい Qwen3.5 9B が上でしたが、日本語オリジナルの 12 タスクでは LLM-jp 8B が少し上でした。一方、翻訳・混在の 7 タスクでは Qwen3.5 9B が 6.83 点上で、日本語で作られた問題に LLM-jp 8B の強みが生かされているようです。また、Qwen3.5 4B・0.8B と比べると、全体スコアも LLM-jp 8B の方が高くなっています。ただし、タスクや型ごとに見ると例外もあります。また、LoRA の rank や学習率もモデルごとに違うので、純粋に基盤モデルだけの差とは言えません。

系列 train なしの saihai-8b と他モデルとの比較

最後に、系列 train を使わずに学習した LLM-jp 8B を、他の Decision モデルと比べてみました。ここでの「文化知識 4」は、JamC-QA、JCulture-MCQ、JMMLU Japan、SOBACO Culture の 4 タスクです。

文化知識 4 は日本語オリジナル 12 の一部です。

系列 train を除いた場合でも、この 8 モデルの中では日本語オリジナル 12 タスクで Jev に次ぐ 2 位で、Winnow 12B (gemma-4-12B-it が大元) より高い結果でした。合成 8 タスクも Jev・Winnow・Jebadiah に次ぐ 4 位です。一方、総合値では Winnow が上ですし、文化知識 4 タスクだけなら Clef が上です。翻訳・混在 7 タスクでは 8 モデル中 6 位で、一般知識の問題ではむしろ他のモデルに負けています。「日本について何でも一番詳しい」とまで強く言える結果にはなりませんでした。

なお、ここでの「系列 train なし」は、追加学習から系列 train を除いたという意味です。評価データと意味的に重複するデータがないことや、基盤モデルの事前学習で触れていないことまでは確認していません。

量子化と llama.cpp 対応

saihai-8b の GGUF は BF16・Q8_0・Q6_K・Q4_K_M・Q3_K_M・Q2_K の 6 形式を配布しています。この 6 形式で、S1MB japanese-v1 の全 27 タスク・8,067 件を llama.cpp の native /v1/systemone で評価しました。入力は S1MB 標準の llama.cpp adapter で変換し、4 並列、1 slot あたり 8,192 tokens、cache 再利用ありと、6 形式とも同じ条件です。

argmax 一致率は、最も確率が高い候補が GGUF の BF16 版と一致した割合で、正解率ではありません。また、Score は数値段階の期待値で採点するため、argmax が一致してもスコアが変わることがあります。

Q8_0 は BF16 との差が 0.03 点ほどで、総合値をほぼ維持しています。Q4_K_M でも低下は 0.66 点ほどですが、argmax 一致率は 92.10% でした。点数が近くても、確率をそのまま使う処理まで同じ挙動になるとは限らないですね。Q3_K_M は約 4.37 GB まで小さくなりますが低下は 2.56 点、Q2_K では 11.46 点と大きく下がりました。これを見ると、ほぼ同等の性能を維持できる Q8_0 や、ベンチマークレベルでは劣化がかなり少ない Q4_K_M あたりが、量子化モデルとしては使いやすそうですね。

速度と VRAM も測っています。RTX 5090 で、同じ 27 タスク・8,067 件を 4 並列で評価したときの処理速度と、GPU メモリ使用量の最大値です。

量子化すると BF16 より 1.1〜1.3 倍ほど速くなり、VRAM は Q8_0 で約 12 GiB、Q4_K_M なら 10 GiB を切ります。一方で、Q8_0 以下は速度にあまり差がなく、Q2_K はむしろ遅くなりました。速度面でも、Q8_0 か Q4_K_M あたりが選びやすそうです。

この速度は、HTTP 通信や採点・保存まで含めた評価全体の処理速度で、1 件あたりのレイテンシではありません。また、1 回だけの計測で、精度の評価とは別に実行しています (重みは配布版と同じですが、64K コンテキスト対応のメタデータ更新前の GGUF で計測しています)。VRAM はドライバなどを含めた観測値です。

なお、Transformers 版の Task Avg は 49.77、GGUF の BF16 版は 49.53 と少し差があります。これは、Transformers 版は saihai 独自の入力変換、GGUF 版は S1MB 標準 adapter の入力変換で評価していて、Score などの表現が異なるためで、量子化による差ではありません。

そのほかの補足です。

• コンテキスト長は 64K としていますが、今回の評価は短いタスクばかりなので、64K の長い入力での判断品質までは確認できていません。
• 計測には、llama.cpp の revision 3d65c90 に、LLM-jp tokenizer の修正 (PR #28864) のパッチを当てたものを使っています。この tokenizer の修正パッチを使わないと、若干 token のずれが発生します。将来的には llama.cpp に取り込まれると思います。

Decision モデルと、ベンチマークを作っての感想

S1MB の英語 leaderboard では、すでに 個人や企業が独自に作った 100 以上の Decision モデルが評価されており、ベンチマーク上は Jev よりも性能の高いモデルも出てきています。また、ちょっとした性能のモデルなら、雑にファインチューニングするだけでも作れてしまいます。実際、自分も今回作ってみたのですが、パッと見ある程度うまく機能していそうなモデルは、性能の良い基盤モデルを使えば簡単に作ることができました。saihai-8b も、RTX 5090 1 枚でファインチューニングにかかった時間は 4 時間弱と、短時間で作れています。

ただ Jev の素晴らしいところは、汎化性能が高く、ほとんどの問題に対して適切な回答を選べていることだと思います。そしてこれは、S1MB をはじめ、現在出ているベンチマークでは、まだまだうまく計測できているとは言い難い状況です。TypeSafe AI は、Jev のプレビューリリース時の利用規約で、性能の誤解を招くためなのか、ベンチマーク結果の公開を NG としていました (現在の規約ではその条項はなくなりました)。また、CEO の Diogo Almeida 氏も X で以下のように述べています。

there's a critical difference between benchmaxxed models and ones made by people who truly care about reliability that, by definition, doesn't show up on benchmarks

(we've somewhat learned this for string LLMs...)

https://x.com/CompleteSkeptic/status/2106883012856336539

ある側面だけを切り取ったベンチマークでは汎化性能が測れないので、そんなに意味がない、というのは私も同意見です。TypeSafe があらゆる質問に対する性能を測れるベンチマークを公開してくれれば良いのですが (社内にはあるのではないか、と私は勘繰っています)、そうすると「TypeSafe が考える Decision モデルのあらゆるユースケース」が露呈するわけで、先行者利益で走りたい今、わざわざそれを公開する選択はないのでしょう。

では S1MB japanese-v1 も意味がないのでは？という問いには、半分は yes、半分は no かなと思っています。特定の側面だけであっても、ある程度共通の指針で測れるベンチマークは有益です。ただ、それを鵜呑みにすると、本来とても重要な「汎化性能」を無視することになってしまうので、参考程度に見ていただけたらと思います。本当に必要な性能評価は、自分たちのユースケースでどれぐらいの性能が出るのかを測るベンチマークを、自前で用意することなのかなと。

また、Decision モデルの性能と推論コストのバランスを考えると、現在のスイートスポットは 4B あたりな気がしていますが、将来的には 1B 以下のモデルでも十分な性能が出るのではないか、と思っています。小さいモデル、とりわけエンコーダモデルが好きな身としては、小さなサイズで必要十分なモデルが作れると面白そうだなぁと感じています。今回の saihai-310m はまだその域には届いていませんが、その方向への一歩として公開しました。

参考 URL

• 日本語ベンチマークで Jev の性能を検証する
• 基盤モデル: llm-jp-4.1-8b-thinking
• 日本語合成データの生成モデル: llm-jp-4.1-32b-a3b-thinking
• saihai 学習コード
• saihai 学習データ
• bekko-system-one-v0 の公開記事
• saihai-310m の学習ドキュメント (bekko-system-one)
• saihai-310m 学習データ
• saihai-310m の基盤モデル: ruri-v3-reranker-310m
• S1MB 評価コード
• S1MB 日本語 leaderboard
• S1MB 英語 leaderboard
• S1MB 英語ベンチマークデータ (english-v1)
• GPT-6 Luna: OpenAI Decisions API
• S1MB 評価結果
• pplx-decider-v1-27b
• llama.cpp の Decision readout 実装

そよ風と木。

連休も三日目になると疲れが溜まっていて、遠出はせず、那珂川河畔公園へ。遊具には子供達がいっぱい。ベコ氏も遊べるようになってきて嬉しいね。

若干遠回りになるが、塩原を向けて南会津、西郷村というルート。山間のドライブがしたく、この道はお気に入りの道の一つ。快晴でとても良い天気、25度という温度、10月半ばの山間というのに、Tシャツでちょうど良い気候。夏を感じる。

そして初めて行く、養鱒公園は山々に囲まれ、水がとても綺麗。最高のロケーションじゃん！鱒の養殖をしていて、横では家族向けのニジマスの釣り堀。釣ったマスは持ち帰りもできるし、その場で塩焼きやフライにもしてくれる。ベコ氏がもうちょっと大きくなったらやりたいね。

Leafの里は、お馴染みのドモンパンやnepuriさんらが出店する、というので知ったので、それらのお店を巡ったり(初めてドモンさんにお会いした)、美味しいパンやコーヒーを飲んだり、以前してもらった短時間のマッサージをやってもらったりと最高。昭和チックなゴーカートもあって、乗るとベコ氏は大はしゃぎ。はー楽しかったね。

ほんと最高の天気、ロケーション、イベント。写真屋さんも来ており、最高だった思い出として、その場で家族写真も撮ってもらったりと、いたりしつくせり。最高の1日だったなぁ。語彙がないので最高を連発しまくるが、そんな1日であった。

とりわけ動物の餌やりで、キリンが柵の上から首を出してきて、長いベロで手に持った野菜を器用に食べる。大迫力。小さい子供は結構怖くて泣いていたりしたのだが、ベコ氏は最初はびっくりしつつも、餌を持った短い手を上に伸ばし、餌やりを楽しんでいた。

またモノレール遊具、古いアンパンマンの乗り物、その他ただの大きなリスの置物など、なんでも楽しんでいた。動物が楽しい！と言うより、知らないものはなんでも楽しめるんだよなぁ。

その後、道の駅である宇都宮ロマンチック村へ。以前来たときは閑散としていたが、さすが三連休でかなりの混み用。餃子関連などを買って帰る。

宇都宮動物園のGoogle Mapsのレビューに、海外からの★1評価が多く付いていて、なんだろうと思って調べてみた。どうやら、PETA（動物の権利擁護団体）が、象の宮子を解放してというキャンペーンを行っていることが背景にあるようだ。

これをきっかけにエーアイ氏と対話し、動物福祉や動物の権利について少し調べてみた。象の単独飼育には確かに福祉上の懸念がある。ただ、長年暮らした環境から別の施設へ移すことが、必ずしも宮子にとって良い結果になるとは限らない。

動物園側も、高齢になった宮子(現在53歳かな、野生の象は70歳ぐらいまで生きるらしい)の飼育環境を改善するためにクラウドファンディングで2,000万円以上を集め、プールを整備したりレントゲンを購入したりなどの取り組みを行っている。動物園そのものの是非も含め、なかなか簡単に答えの出る問題ではないな、と。

PETAへの賛否はともかく、動物福祉について少し考えるきっかけになったなぁ。

親が普段使っているものを、ママパパと呼ぶ。かわいい。母のiPhoneは「ママ」と呼ぶようになり、父の靴下（よくその辺に脱いである）は「パパ」である。

そろそろ sakura の VPS の一年契約の更新の時期、というわけで動いていた諸々(このサイトの更新とかね)を自宅サーバに移す。以前は、いちいちちゃんと確認するの、めんどくさいからなーというコストが発生していたのだが、エーアイ氏によろ、で済んで驚くほど楽に終わってしまった。

午前中寒く、暖かくなるものが食べたいと、森商店での味噌ラーメン。ただ、昼過ぎには気温も暖かくなってしまった。よりはまた寒くなる。寒暖差が激しく、季節の移り目を感じる。

庭の雑草、クローバーかなと思っていたら、カタバミであった。雑草、割と好きなんだけど、知識が全然ないんだよなぁ。

いい天気の日。またずっとエーアイ中毒だったしで、気分を変えに外に。今回は那須平成の森フィールドセンターから駒止の滝までの散歩。往復1.5時間ぐらいのちょうど良い散歩コースだ。那須平成の森フィールドセンターはフリーWiFi(150Mbsp 程度は出ていた)が使え、トイレもあるし野外に机もあるしで、意外と良い作業場所にもなるかもしれないなぁ。

茶臼岳も綺麗に見える。

駒止の滝までは、山林を歩く。小学生が遠足（フィールドワーク）できていて賑やか。「あーなんか辺な人(私)がいる〜〜〜」と言われる。たしかに、みんなと格好が違うもんね。

山を歩くと、すれ違う人と「こんにちわ」と声かけの挨拶。最近何かで読んだが、挨拶するだけで満たされるらしい。実際、それだけで気持ちが良いんだよね。山の中を歩けば満たされまくりなのでは！？

陽が当たる場所は暑いぐらいの天気。ところどころ、紅葉の赤も見えるように。

これは三本槍岳かなー。以前三本槍岳に登った時は那須ゴンドラで中腹までワープしたのだが、今は那須ゴンドラも閉業してしまったから、中腹まですら、1時間以上歩かなければならない。

駒止の滝、初めて来た。うおー青い！綺麗じゃん〜。紅葉の季節はもっと綺麗なんだろうなぁ。車なら滝の横の駐車場まで来れちゃうけど、1時間弱を歩いてきたので、より有り難さがますね。

ささっと戻って(帰りは下りで楽)、THE昭和なお店の大衆食堂さつきで遅めの昼食。思ったより賑わっていて（たまたまだったかもしれないが）、ご飯がなくなったので麺類のみ、とのことだったのタンメンを。お店の夫婦のお二人も良い人だったし、この辺は昼食場所がここしかないから、長く続くと良いな。

コロナ時に作ったのだと思うが、入り口に「老舗のため すきま風 換気良好」というプレートがあって、これまた味がある。

昼食はラーメンきまま。澄んだスープ！

更新するパスポートを受け取りに市役所へ。手続きはマイナアプリからサクッとでき、あとは受け取るだけで楽だった。こういう便利さ、徐々にデジダル化が進んでいるのだなぁ、と実感する。

ベコ氏の保育園の横にレストランができたぞ〜と、お迎えの帰りにお茶。デザートもハーブ茶も美味しかったなぁ。ベコ氏は枯れた大きな紫陽花の周りで大はしゃぎする。おお、それに興味を持つのか、というポイントが時々予想不能でかわいいね。