小さなAIを現場で活かす。白書が示すSLMと領域特化

小規模という言葉には、資料ごとの定義がある

白書は、SLMのパラメータ数に統一された境界がないことを示し、この節ではおおよそ百億程度までを扱うと定めている。研究によって70億以下、140億以下などの区切りが使われるため、数字を比較するときには、その資料の定義を確かめる必要がある。

パラメータ数は、モデルの学習された値の規模を示す指標になる。ただし、それだけで使用時のメモリー、速度、電力、品質が決まるわけではない。数値の精度、文脈の長さ、実行する機器、同時に処理する件数も関わる。同じ「小型」という呼び方でも、手元の機器で動く条件は別途確認したい。

また、ウェブ上の説明は更新される。白書が参照した時点の定義と、現在の提供企業のページで違いがあっても、まず参照日を確かめるべきである。過去の資料の引用を、現在の共通規格と受け取らないことが大切だ。

導入を検討する企業にとっては、SLMに分類されるかより、必要な作業を求める条件で実行できるかが重要になる。大きさの区分は比較の入口として使い、製品の採用判断は業務と機器の試験で行いたい。

端末で動く価値は、通信と情報管理にもある

白書は、計算量を抑えたモデルがエッジデバイスやオンプレミスで動く利点を挙げる。完全にローカルで推論する構成なら、処理のたびに入力をクラウドへ送る必要がない。通信が不安定な現場や、外へ持ち出しにくい情報を扱う用途で意味がある。

ただし、「エッジAI」という呼称だけで、すべてのデータが外に出ないとは判断できない。モデルの更新、ライセンス認証、外部検索、ログ収集、複数の機器の連携で通信するシステムも考えられる。推論を行う場所と、システム全体のデータの流れを別々に確認する必要がある。

電力や費用の評価も同様だ。小型化による利点は期待できるが、個別のシステムで、常時稼働する機器、更新、保守、必要な台数を含む費用まで安くなるとは限らない。比較するなら、同じ入力と品質条件で、応答時間や消費電力、運用の負担を測る方がよい。

一方、知識の範囲や複雑な推論には限界がある。白書はRAGによる外部知識の活用や、大型モデルとの組み合わせを挙げている。検索で情報を補えることと、その情報を正しく使えることも別の評価になる。検索結果の誤り、古い文書、閲覧権限の違いを含めて設計したい。

PLaMo Liteの比較は、2024年の条件で読む

Preferred Networksの2024年8月28日の発表は、10億パラメータのPLaMo Liteを案内している。1000億パラメータのPLaMo-100Bの開発成果を活用し、生成した日本語・英語を含む合計4兆トークンを学習したとする。小型モデルが、大型モデルの開発と無関係に生まれるわけではないことが分かる。

白書が掲載する比較では、日本語質問応答のJSQuAD F1が0.86、日英翻訳のWMT20・4-shotが0.20、Jaster・0-shotが58.0%とされる。比較対象のモデルや条件も同じ図表に示される。これらは提供開始時の特定のベンチマークであり、現在の全用途で大型モデル以上だという意味にはならない。

とくにJasterについて、提供元はNLI、QA、RC、MC、MR、FAの六つのカテゴリーを用いたGENIACの評価セットと説明している。名前が同じ評価基盤でも、どの項目、どの入力例、どのショット数で測ったかを確認したい。単一の値だけを抜き出して、別の評価表と順位をつなぐのは適切ではない。

この事例の意味は、古い比較相手に勝ったという宣伝を現在へ持ち越すことより、限られた規模でも日本語の特定の課題で有用な結果を狙えるという開発の方向にある。白書の図表を使うときも、モデルの版と発表年を付ける必要がある。

自社の採用試験では、一般の質問応答だけでなく、略語、固有名詞、表形式の文書、回答してはいけない問いを用意したい。平均スコアが良くても、重要な業務の一つで誤りが多ければ、任せる範囲を狭める判断になる。

製薬向けモデルは、評価の道具も一緒に作る

EQUESのJPharmatron-7Bのモデルカードは、日本語と英語を扱う製薬分野向けモデルとして、開発方法と評価を説明する。JPharmaBenchのほか既存の評価も使い、近い規模のオープンモデルと比較したとされる。

JPharmaBenchには、薬剤師国家試験に基づく問題、言語をまたいだ用語の対応、文書間の整合性を扱う課題が含まれる。専門用語を知っているかだけでなく、同じ内容を異なる表記で扱えるか、複数の文書の間の矛盾を見つけられるかを測ろうとする設計だ。

ここで重要なのは、国家試験の問題で良い成績が出たことを、医療行為に使える証明へ置き換えないことである。モデルカードは、医療用途やリスクに敏感な用途で検証されたものではないと明記している。研究や製薬文書での利用と、個人の診断・治療判断は同じ評価対象ではない。

モデルを社内で動かせる場合も、入力文書の権限、出力の確認、利用条件を設計する必要がある。ローカル実行が情報管理の一つの条件を満たしても、回答の品質や利用目的への適合性まで自動で満たすわけではない。

当サイトの考察として、領域特化では、モデルの微調整だけでなく、仕事に沿った評価問題を整えることが重要になる。日常の作業から確認すべき誤りを定め、出力を採用する人が判断できる記録を残す。その評価基準がなければ、モデルを変えるたびに見栄えのよい例だけで判断することになりかねない。

スタジアム実証は、送る情報の粒度を変える構成

AWLの2025年6月25日の発表は、楽天モバイル、楽天ヴィッセル神戸との共同実証を説明する。ノエビアスタジアム神戸で、通信負荷の最適化と警備業務の省力化を検証する計画だった。発表された実施予定期間は2025年6月から2026年1月である。本記事で完了後の成果数値を新たに確認したわけではない。

構成では、カメラの近くのファーエッジが画像を分析し、リスクと通信の混雑状況に応じて、テキスト、静止画像、動画クリップへ送信する情報を変える。エッジサーバー側で複数の監視情報をSLMが統合・要約し、警備担当へレポートする。

この例で、SLMがすべての画像を直接見て警備を完結していると読むのは適切ではない。画像認識、通信の制御、情報の統合、現場の判断が別々の役割を持つ。小型言語モデルの価値も、その組み合わせの中で評価される。

当サイトの考察としては、要約が短くなるほど重要な情報が抜けていないかを確認したい。リスクの高い場面で元の映像へ戻れるか、通信が混雑したときに何を優先するか、担当者が誤った指示を見分けられるかが、実際の利用条件になる。

公式発表は通信量削減、汎用性、可搬性などを検証項目としている。計画の説明と、効果を実測して社会実装が完了したという状態は区別しなければならない。白書の事例紹介も、その時点の出典に戻って読む必要がある。

フィジカルAIでは、言葉の出力の先に実物がある

白書はSLMとともに、センサーやアクチュエーターを通じて環境と関わるフィジカルAIを取り上げている。ここでも、すべてを一つの汎用モデルへ任せるだけでなく、現場の目的と制約に合わせる視点が示される。

国立情報学研究所の佐藤一郎教授へのヒアリングでは、日本の強みとして、製造などの業務の方法をAIで高める方向が語られている。例に挙げられた指さし確認は、確認を忘れた場面をAIが指摘するような考え方だ。これは白書に収められた見解であり、すべての現場で安全性の効果が実証された導入例ではない。

人が長年使ってきた手順には、例外への対応や暗黙の前提が含まれる。それをデータやルールにする際には、通常の手順だけでなく、作業を止める条件、人へ返す条件も言語化する必要がある。熟練者の動きを集めることだけで、業務の知識がすべて学習できるとは限らない。

また、言語モデルが作った手順が妥当に見えても、機械の可動域、周囲の人、接触する物の性質を別に確認する必要がある。文章の正しさと物理動作の安全性は、それぞれ試験の対象になる。

政策の支援と、継続運用の条件を合わせて見る

白書の事例にはGENIACの支援を受けた開発が複数含まれる。公的支援を通じてモデルや評価基盤、実証が進むことは、技術を現場へ持ち込む機会になる。一方、支援を受けたという事実だけで、事業としての収益や長期の保守が確立したとは言えない。

導入側は、モデルの配布条件、更新方法、依存するライブラリー、問い合わせ先、担当者が変わった後の運用を確認したい。端末へ一度入れれば終わりではなく、データや仕事の変化に合わせて評価を続ける必要がある。

白書にあるPCとスマートフォンの差別化に関する予測も、将来の市場を確定した数字ではない。機器を買う場合には、予測だけでなく、現在必要なモデルが動くか、必要なメモリーや電力の条件を満たすかを確かめるべきである。

評価の点数と、現場の失敗を対応づける

質問応答、翻訳、文書間の整合性では、正解の定義も異なる。文字列が正解例に近いこと、意味が合っていること、重要な条件を落とさないことを、同じ点数だけで表せるとは限らない。公開されたスコアを入口にしながら、自社の失敗例がその評価へ含まれているかを確かめたい。

また、小型モデルが答えられないときに、無理にもっともらしい文章を出すのか、分からないと返すのかも重要になる。人へ引き継ぐ条件を先に定めれば、モデルが得意な部分を使いながら、判断を保留できる。これも、本記事で既存モデルの性能として実測した結果ではなく、導入時に確認する評価項目の提案である。

自社で測るのは、小ささより仕事への適合性

当サイトの提案は、最初に対象業務を一つ選び、入力、正解の基準、失敗時の対応を定めることだ。例えば社内文書の検索なら、正しい文書を見つけたか、回答の根拠へ戻れるか、閲覧権限を守るかを評価する。速度だけで採用しない方が、実務の負担を把握しやすい。

大型モデルと比較する場合も、同じ入力、同じ情報の参照範囲、同じ出力条件を使う。ローカルで動かす利点と、外部の高性能モデルへ問い合わせる必要がある場面を分ければ、組み合わせの費用と情報の流れを設計できる。

運営会社のRO合同会社の情報も参照し、現場のAI活用では、規模の競争だけでなく、業務の方法、データ、評価、確認する人を整えたい。参考資料：情報通信白書、PFN、EQUESのモデルカード、AWL、イノベトピア。事例の観測と当サイトの導入上の考察を区別した。