小規模言語モデルで小さな面倒をなくそう

こんにちは、プラットフォームエンジニアの takai です。今回は、小規模言語モデルを利用した自作ツールをどのようにつくったのかについて、紹介いたします。

本記事は、IVRy Advent Calender「IVRy AIブログリレー Part2」14日目の記事です。昨日は高柳さんが「『御用聞き』で終わらせない。エンタープライズへAIを届けるための『CAB』という挑戦」という記事を投稿しています。こちらもぜひご覧ください！

ファイル名は面倒くさい

仕事をしていると、メモを素早く残したい場面が多くあります。そういったとき、みなさんはどのようにしていますか。仕事のための情報管理の方法は人それぞれで、Obsidian のようなツールを利用する人もいれば、紙のノートがよいという人もいます。

私は Markdown 形式でメモを書くことが多く、まずはデスクトップの tmp.md というファイルに書き始め、内容が固まってきたらふさわしい名前に変えるという方法を続けています。長年 Emacs を使っているので、専用のメモ管理ツールを使うよりも、それがしっくりくるスタイルなのです。

ただ、このやり方にはひとつ問題があります。それは、ファイル名をつけるたびに適切なファイル名を考えるという作業が発生することです。これは階層型ファイルシステムの宿命ともいえる点です。私が大学生の頃に読んだ増井俊之先生の『インタフェースの街角』でも、以下のような指摘がありました。

増井先生が提案するようにファイル名をつけない、全文検索で探せるようにするというユニークなアプローチもあるでしょう。ただ、テキストファイルを階層型のファイルシステムに保存するやり方は、とてもシンプルで互換性が高いという強みがあります。特別なツールに依存せず、どんな環境でもそのまま利用できるという点は、やはり大きな魅力です。

このファイル名をつけるという、ちょっとした面倒くささを解決したい──それが今回のテーマです。どうすれば楽にできるのでしょうか。文章の内容から名前を推測してくれるような仕組みが必要です。

小規模言語モデルという選択肢

最近では、文章の意味を理解し、新しい文をつくることができる大規模言語モデル（LLM）が身近になっています。LLM は文章の要点をつかむのが得意で、それをもとにファイル名のような短い語句を返すこともできます。LLM であれば、簡単な Web API 呼び出しをするだけでこれを解決することができます。

一方で、ファイル名を考える作業そのものはとても軽いタスクです。これだけのために、毎回クラウド上の巨大なモデルを呼び出すのは少し大げさに感じます。API には呼び出すたびに料金が発生しますし、そもそも個人的なメモのために職場の API キーを使うことをためらう場面もあるでしょう。さらに、メモの内容によってはクラウドに送信できない情報が含まれることもあり、セキュリティや社内ポリシーに抵触してしまう場合もあります。

クラウドに情報を送信するのではなく、手元のローカルマシンだけで処理を完結させたいという要求は多くあります。そうしたときに役に立つのが小規模言語モデル（SLM）です。SLM はパラメータ数が少なく、巨大な LLM と比べて必要な計算量やメモリが大幅に小さいため、ラップトップのような一般的な環境でも十分に動作します。内容を外部に送らずに利用できるという安心感もあり、今回のような軽いタスクにはとても向いています。

最近では Ollama のようなツールが整ってきており、ローカルで言語モデルを手軽に扱えるようになりました。Ollama はモデルのインストールや管理をひとつのコマンドで行える仕組みで、必要なモデルを pull するだけで使い始めることができます。また、自動で localhost 向けの Web API を立ち上げてくれるため、プログラムからモデルを呼び出す処理も簡単になります。

naduke：内容から自然なファイル名をつける

naduke は、ファイルの内容を読み取り、その内容に合ったファイル名をローカルの SLM に生成させ、そのままリネームまで行う小さなコマンドラインツールです。テキストファイルの内容をモデルに渡し、返ってきた名前をルールに沿って整形し、拡張子だけは元のまま保持します。dry-run で名前だけ確認したり、複数ファイルをまとめて処理したりすることもでき、普段の作業フローに自然に組み込めるように設計しています。

Mac であれば、Ollama は Homebrew で簡単にインストールできます。ここでは granite4:3b-h を使っていますが、これは IBM が開発した Granite-4.0-H-Micro の 3B モデルで、ローカルでも十分に動くサイズのものです。

$ brew install ollama
$ ollama serve
$ ollama pull granite4:3b-h

naduke のセットアップもシンプルで、Go が入っていればすぐに使い始められます。コマンドラインから名前をつけたいファイルを渡すだけで、内容に合ったファイル名へとリネームしてくれます。

$ go install github.com/takai/naduke/cmd/naduke@latest
$ naduke tmp.md
tmp.md -> epson_new_ep_905a_model.md

ここまでが naduke の紹介です。実際の作業フローの中で「名前をつける」という小さな面倒を減らせればと思い作ったツールなので、ぜひ手元で試してみてください。使ってみた感想や改善点などがあれば、とても参考になりますので、ぜひフィードバックをいただければと思います。

どうSLMを評価するか

ツールの実装よりも難しかったのは、どのモデルがもっとも自然な名前を返してくれるのかを評価する部分でした。SLM とひとことで言っても種類は多く、性能とスピードには明確なトレードオフがあります。私としては、個人所有の MacBook M2 Air でも快適に動くことを最初の条件にしたかったため、まずはモデルサイズから絞り込みました。いくつか試したところ、だいたい 4B 前後のモデルであれば速度と精度のバランスが取れそうだと分かり、ここを中心に比較することにしました。

その結果、Google の Gemma 3 4B（gemma3:4b）、IBM の Granite 4.0 3b-h（granite4:3b-h）、そして Microsoft の Phi-4-mini（phi4-mini:3.8b）といったモデルが候補に残りました。どれもローカルで実用的に動きつつ、文章理解にも強いモデルです。この三つを実際に評価し、今回の「ファイル名生成」というタスクにもっとも向いているものを見つけようとした、というのが流れになります。

文章生成タスクの評価指標としては BLEU や ROUGE がよく知られています。しかし、これらは基本的に同じ言語どうしの文章を比較することを前提に作られており、日本語の文書に対して英語の短い語句を生成する今回のタスクではうまく働きません。単語の一致度で評価するため、そもそも言語が違えば一致のしようがなく、スコアは意味とは無関係に低くなってしまいます。

意味ベースの評価方法として BERTScore が候補に上がります。これは日本語と英語のような異なる言語間でも比較ができる点が大きな強みです。ところが、ファイル名のように短い語句では、生成される意味ベクトルに含まれる情報が非常に少なく、安定した比較ができません。数語だけの短い表現を、文章レベルの意味ベース指標で評価すること自体が難しいのです。

LLM-as-a-Judge による評価方法

そこで利用したのが、近年広く使われるようになってきた LLM-as-a-Judge という評価手法です。名前の通り、「LLM を審査員として使い、他のモデルの出力を評価してもらう」というものです。本来であれば人間が行うような「内容を理解して良し悪しを判断する」という作業を、別の LLM に肩代わりしてもらう仕組みです。

この方法の優れている点は、BLEU や ROUGE のような単語一致ベースの評価とは異なり、意味の近さや内容の適切さを柔軟に判断できることです。今回扱うファイル名生成のような「日本語の記事を読んで、数個の英単語から構成されるファイル名を返す」という極端な要約タスクでは、従来の評価指標がうまく機能しません。単語一致は本質を捉えられず、BERTScore のような意味ベースの指標でもベクトル情報が不足してしまいます。

こうした状況でも、LLM-as-a-Judge であれば、「ルールを守っているか」「内容を表しているか」「簡潔かどうか」を総合的に判断してもらうことができます。

一方で、LLM-as-a-Judge には注意点もあります。最近の研究では、候補の並び順に引きずられる位置バイアスや、冗長な表現を好む長さバイアスなど、LLM が評価時に持ちやすい偏りが指摘されています。こうしたバイアスがそのまま残ってしまうと、評価結果の信頼性が下がってしまいます。

今回の実験では、livedoor ニュースコーパスの記事を 500 件ほど用い、各記事に対して複数の SLM（gemma3:4b、granite4:3b-h、phi4-mini:3.8b）が生成したファイル名候補をまとめて Judge LLM（gpt5-mini） に評価してもらいました。

評価の流れは次のようになります。まず、記事本文を抜き出し、それを SLM に渡してファイル名候補を生成します。どのモデルにもまったく同じ本文を入力することで、公平に比較できるようにしました。1 つの記事につき三つの SLM から候補が出そろうので、それらを A、B、C といったラベルを付けて Judge LLM に渡します。

ここで重要なのがバイアス対策です。候補にラベルを付けるとき、常に同じ順番で並べてしまうと、Judge LLM が「最初の候補を高く評価しがち」といった位置バイアスを引き起こす可能性があります。そこで、候補の並び順は毎回シャッフルし、Judge モデルにはどれがどのモデルの生成物なのか分からない状態で評価してもらいました。

Judge LLM には、以下の項目を JSON 形式で返すように指示しました。スコアだけでなく順位を出してもらうのは、モデル間の相対的な強さを比較するために有効です。

• ルール遵守（0-5）

• 内容の代表性（0-5）

• 簡潔さ・説明性（0-5）

• 総合スコア（0-5）

• 候補間の順位

たとえば、シャープのスロージューサーを紹介する家電レビュー記事では、granite4:3b-hがもっとも高いスコアを獲得しました。生成した名前は「juice_making_low_speed_press.txt」です。記事の核心である「低速圧搾」と「ジュース作り」という要素を押さえており、内容の代表性は 5.0、総合スコアは 4.8 と高い評価となっています。gemma3:4b が返した「lowspeed_juicer_benefits.txt」も自然で、記事の方向性を捉えていますが、granite4:3b-hと比べると代表性は 4.0 という評価でした。一方、phi4-mini:3.8bは「slowpressjuicescruzer.txt」というルールに違反する名前を出しており、代表性 1.0、総合スコア 1.7 と厳しい結果になりました。

実験結果とモデル比較

それでは、それぞれのモデルがどんな特徴を持っていたのか、LLM-as-a-Judge による 500 記事分の評価スコアから見ていきます。数値は、各モデルが生成したファイル名に対して付けられた平均評価です。

まず、もっとも高い総合スコアを記録したのは gemma3:4b でした。命名ルールの遵守、簡潔さ、内容のまとまりのバランスが良く、「きれいにまとまった名前」を返すことが多い印象でした。平均順位も 1.81、トップを取った割合も 42.6% と高く、このタスクでは非常に安定した強さを見せています。

一方、granite4:3b-h は総合スコアで gemma:4b と大きく差はなく、特に「内容の代表性」の項目で高い点を取りました。記事の要点をうまくつかんで、それを短い言葉にまとめる力が強いモデルです。トップ獲得率は 40.2% と gemma:4b にわずかに及びませんでしたが、平均順位はむしろ granite:3b-h の方がわずかに良く、2 つのモデルの性能はほぼ並んでいると言ってよい結果でした。今回はローカルでの推論速度も加味して選びましたが、軽さとスコアのバランスがもっとも良かったのは granite4:3b-h でした。

対照的に、phi4-mini:3.8b は三つの中ではもっともスコアが低い結果になりました。内容の代表性や簡潔さの点で伸び悩み、総合スコアも 2.54 と他のモデルに比べて差が開いています。ただし、記事によっては鋭い名前を返す場面もあり、ばらつきはあるものの「当たると強い」タイプのモデルだと感じました。

このように、今回のタスクに限って言えば gemma3:4b と granite4:3b-h が頭ひとつ抜けて安定しており、特にローカル実行との相性を考えると granite4:3b-h が最適という判断になりました。もちろん、どのモデルも一長一短があり、タスクの性質や許容する速度・負荷によって最適解は変わりますが、今回の「ファイル名生成」に関しては、granite4:3b-h は精度と速度の両面で扱いやすい選択肢でした。この評価結果を踏まえ、naduke のデフォルトモデルとして granite4:3b-h を採用しました。

小さな面倒を技術でなくす

ファイル名を考えるという小さな作業でも、積み重なると意外と大きな負担になります。今回の取り組みは、この負担をローカル環境だけで解消できるかを探るものでした。SLM と Ollama を組み合わせることで、「内容を読む→短い名前を返す」という処理を安全かつ高速に実現でき、実際のワークフローに自然に組み込めることが分かりました。その結果として生まれたのが naduke であり、日常的なメモ管理のストレスを減らす小さなツールとしてうまく機能しています。

一方で、もっとも難しかったのは「どのモデルが最適なのか」を見極める評価でした。日本語の文書から英語の短い語句を生成するという特殊なタスクでは、BLEU や ROUGE などの従来の自動指標が使えず、BERTScore も情報量の不足で安定しません。そこで LLM-as-a-Judge を採用し、Judge モデルに意味理解にもとづく評価を行わせることで、モデル間の比較を可能にしました。位置バイアスを避けるために候補順序をランダム化するなど、信頼性の確保も工夫しています。

naduke は小さなプロジェクトですが、同じ課題を感じている方にとって少しでも役に立てば嬉しく思います。フィードバックや改善案も歓迎しますので、ぜひ試していただき、気づいた点があれば教えてください。

IVRyでは「イベントや最新ニュース、募集ポジションの情報を受け取りたい」「会社について詳しく話を聞いてみたい」といった方に向けて、キャリア登録やカジュアル面談の機会をご用意しています。ご興味をお持ちいただけた方は、ぜひ以下のページよりご登録・お申し込みください。

herp.careers O03.カジュアル面談

株式会社IVRy

募集要項をみる