SLMとは?LLMとの違いと、用途に合うモデルの選び方

SLMとは何か、LLMとの違いや用途別の選び方を解説します。Phi、Gemma、Qwen、Llamaと効率重視のAPIモデルを比較し、パラメータ数、コンテキスト、ローカル実行の制約を整理。分類・抽出は小規模モデル、曖昧な推論はフロンティアモデルという出発点と、品質・費用・応答時間を検証して振り分ける方法がわかります。

公開日

SLMとは?LLMとの違いと、用途に合うモデルの選び方

SLMとは何か、LLMとどう使い分けるべきか。判断の出発点は、モデルに任せる仕事です。結果を検証できる限定的な処理には小規模言語モデルを、曖昧さを含む複数段階の仕事には最先端の大規模言語モデルを選びます。Microsoft Phi-4-mini-instructのパラメータ数は3.8Bですが、その規模だけで、開発する機能の品質基準を満たせるかはわかりません。さまざまな処理が混在するワークフローでは、工程ごとにSLMとLLMを使い分けましょう。

LLMとSLMの違いを踏まえ、どちらを選ぶべきですか?

分類、情報抽出、短い文章の書き換えを実装するなら、まず小規模モデルから試します。 入力の範囲を絞り、許容する出力を定め、現在の基準となる手法とエラーを比較してください。最初の候補として適しているのは、あらゆる顧客トラブルの解決を任せるエージェントより、問い合わせにラベルを付ける処理です。

調査、計画立案、自由度の高い文章作成を実装するなら、まずフロンティアモデルを使います。 フロンティアモデルとは、各開発元が提供する最も高性能な汎用モデルを指します。小規模モデルで再現しようとする前に、良い出力の基準を確立しましょう。

オフライン動作やデータの機密性が求められる機能では、最初に実行環境の制約を確認します。 効率の良いクラウドAPIでも、端末内で実行するという要件は満たせません。ダウンロード可能な小規模モデルが役立つのは、アプリケーション、ツール、ログも含めて、データを許可された場所にとどめられる場合です。

判断軸フロンティアLLM小規模モデル・効率重視のモデル最初に選ぶ候補
範囲が限定され、結果を検証できる処理その工程に必要な能力を超えている可能性がありますラベル付け、フィールド抽出、制約付きの書き換えに有力です評価を経た小規模モデル
曖昧な判断や文章作成幅広い判断が必要な処理の出発点に適していますタスクの厳密な絞り込みや特化が必要ですフロンティアモデル
応答時間と呼び出し単価失敗が減るなら、計算量の多さが合理的な場合もあります再試行によって効率面の優位性が失われることがあります実績のある定型処理には小規模モデル
オフライン・端末内での実行ホスト型のフロンティアAPIでは要件を満たせません対応するローカルモデルの重みがあれば可能ですローカルモデル
採用を見送る条件禁止されたリモートエンドポイントは利用できませんタスクの合格基準を満たせません別の処理先へ振り分けるか、人が対応します

これらは検討を始める際の推奨であり、モデル同士を競わせたテスト結果ではありません。開発元のページを確認した日は2026年10月26日です。 比較の根拠は、公開された機能、実行環境の制約、タスクごとの合格基準です。本記事のためのモデル性能テストは実施していません。

SLMとは?「小規模」の意味を正しく理解する

「小規模」はモデルの相対的な規模を表す言葉で、知能の種類が別という意味ではありません。パラメータとは学習によって得られた数値の重みで、Bは十億を表します。区分は厳密ではなく、Metaは1Bと3BのLlama 3.2も大規模言語モデルと呼んでいます。

小規模モデルでも、幅広い内容を学習している場合があります。ただし、必要なリソースが少ないからといって、自社の返金ポリシーを最初から知っているわけではありません。指示、提示する根拠、許容する出力を通じて仕事の範囲を絞り、必要性が認められる場合は追加学習も行います。

SLMのサイズ表記は、何を表していますか?

重みが全部でいくつあるか、トークンごとにどれだけ計算するか、どこでモデルを動かすか。この点は分けて考えます。トークンは、モデルが処理するテキストの単位です。

違いを理解するには、GoogleのGemmaの命名が参考になります。E2BとE4Bは実効パラメータ数を表しますが、それとは別に埋め込みの重みもメモリを必要とします。26B A4Bは、トークンごとにネットワークの一部を選んで使うMixture of Expertsモデルです。Googleによると、動作するパラメータは4Bでも、高速な推論のために26Bすべてを読み込みます。つまり、メモリ使用量が4B相当になるわけではありません。この違いはGoogleのメモリに関するガイドで説明されています。

全重み、実際に動作する計算部分、コンテキスト、ランタイムの領域を比較する建築断面図。
ローカル実行では、実際に動作する計算部分以外にもリソースが必要です。各空間は異なる要件を示しており、実測したメモリ比率ではありません。

重みを低い数値精度で保存する量子化によって、必要なリソースを減らせることがあります。ただし、コンテキスト用のメモリや、実行を支えるソフトウェアは引き続き必要です。KVキャッシュは、生成中にコンテキストの中間情報を保存します。リクエストや応答が長くなると、キャッシュも増える可能性があります。実際に使うチェックポイントとランタイムの要件から計画を立て、対象端末で測定してください。

一方、「高速」「効率的」とされるAPIモデルは、別の観点から評価する必要があります。パラメータ数が公開されていなかったり、重みをダウンロードできなかったりしても、応答時間や運用費の改善には役立つ場合があります。

SLMの比較:評価候補となるモデルファミリー

以下は、開発元が公開している具体的なチェックポイントです。任せたい仕事に合わせて候補を選んでください。ファミリー名だけでは、対応する入力形式、必要なメモリ、信頼性はわかりません。

Microsoft Phi:範囲を絞ったテキスト処理に。知識量には限界

Microsoft Phi-4-mini-instructは、3.8Bパラメータと128Kトークンのコンテキストウィンドウを持つオープンなテキストモデルです。モデルカードには、指示への追従、関数呼び出しの形式、ローカルでの提供方法が記載されています。与えた文章からのフィールド抽出や、短い応答を指定形式に書き換える処理の候補になります。Microsoftのモデルカード。

主な制約は、事実に関する知識の容量です。Microsoftは、膨大な事実知識を保持できず、誤った事実を生成する可能性があると注意を促しています。サポートアシスタントには、重みの中に自社の業務ルールが入っていると期待せず、関連するポリシーを渡してください。

想定用途と制約を掲載したMicrosoftのPhi-4-mini-instructモデルカード。
Microsoft Phi:使用するチェックポイントの対応範囲を確認します

関連モデルのPhi-4-mini-reasoningも3.8Bですが、Microsoftによると、数学的推論のために設計・検証されています。数学への特化は、自由度の高いカスタマーサービスエージェントを任せられる根拠にはなりません。Phi-4-mini-reasoningのモデルカード。

Google Gemma:モバイル向け候補はサイズ表記の意味を確認

Google Gemma 4には、モバイルやエッジでの実行に向けた、実効パラメータ数2Bと4BのE2BとE4Bがあります。Googleのドキュメントでは、このサイズについてテキスト・画像・ネイティブ音声入力、128Kのコンテキストウィンドウ、設定可能な思考機能、関数呼び出しが記載されています。テキスト以外も扱うマルチモーダル入力をローカルで処理したい場合に、最初に検討する候補です。Gemma 4の概要。

ただし、実行環境との適合性は別途確認が必要です。実効パラメータ数は重みの総数と同じではなく、コンテキストウィンドウを最大限使うには追加のメモリも必要になります。スマートフォンで動かせるモデルでも、対応するランタイムと、実機で継続して使える性能が必要です。

モデルサイズと実行環境のガイドを掲載したGoogleのGemma 4概要ページ。
Google Gemma:実効サイズと必要メモリは別の指標です

Alibaba Qwen:幅広いサイズから選べる一方、最小モデルには注意

Alibaba Qwen3.5には、0.8B、2B、4B、9Bという名前の小規模チェックポイントがあり、開発元のコレクションに掲載されています。Qwen3.5-4Bのモデルカードでは、言語モデル部分が4Bと記載され、それとは別に視覚エンコーダーも含まれます。名前の末尾だけで判断せず、全体に必要なリソースを見積もってください。

Qwen3.5-4Bは、テキスト・画像・動画の入力と、ネイティブで262,144トークンのコンテキストに対応すると記載されています。文書を扱う機能の評価候補にはなりますが、この数値は入力容量の仕様です。長い文書全体にわたって、信頼できる推論ができる証拠ではありません。

Qwen3.5のモデルチェックポイントを掲載したQwenの公式コレクション。
Alibaba Qwen:ファミリー名だけでなく、チェックポイントを選びます

特に注意が必要なのはQwen3.5-0.8Bです。開発元は、試作、タスクに特化したファインチューニング、研究・開発向けと位置付けています。また、思考機能を有効にするとループに陥りやすくなり、生成が終わらなくなる可能性があると警告しています。終了動作をテストし、上限を設けるまでは、無人で回す推論ループに組み込まないでください。Qwenの注意事項。

Meta Llama:小規模なテキストモデル。画像入力は対象外

Meta Llama 3.2には、テキストを入力し、テキストを出力する1Bと3Bのモデルがあります。Metaは、指示調整済みモデルの用途として、対話、検索、要約、モバイルでの文章作成支援を挙げています。画像の内容を読み取る必要がないアプリケーションでは、ローカルのテキスト機能に使う候補です。Metaのモデルカード。

これらの小規模チェックポイントはテキスト専用です。また、MetaのLlama 3.2 Community LicenseとAcceptable Use Policyが適用されるため、導入時はライセンスも個別に確認してください。

MetaのLlama 3.2モデルカードとライセンス情報。
Meta Llama:小規模なテキストモデルにも固有の利用条件があります

手元のマシンに合わせて候補を絞りたい場合は、2026年のおすすめローカルLLMも参照してください。この記事では、モデルにどの役割を任せるかを判断します。

効率重視のAPIモデルは、SLMとは分けて検討する

インフラの運用負担を減らしたいなら、ホスト型の効率重視モデルが手軽な候補です。以下のページではパラメータ数が公開されていないため、すべてをSLMと呼ぶと、確認できていない規模まで断定することになります。

OpenAI:範囲の明確な処理に向くGPT-6 Luna

OpenAI GPT-6 Lunaは、範囲を絞った大量のタスク向けに位置付けられています。OpenAIのモデル選定ガイドでは、Lunaは範囲の明確な仕事やトリアージに、GPT-6 Astraは曖昧な問題や深い分析に対応するモデルとされています。どちらの重みの数も推測せずに、限定的な工程と高度な工程の使い分けを考えられる比較です。

Lunaのツール利用には、エンドポイントによる制約があります。モデルのページによると、Chat Completionsで関数呼び出しを使うには、reasoning_effortをnoneに設定する必要があります。一方、Responses APIは組み込みツールと関数呼び出しに対応しています。エージェントのモデルを置き換える前に、使うエンドポイントの仕様を確認してください。

効率重視モデルと高性能モデルの役割を比較したOpenAIのモデル選定ガイド。
OpenAI:モデルと思考設定を合わせて選びます

Anthropic:エージェント内の反復処理に使うClaude Haiku 5.5

Anthropic Claude Haiku 5.5は、分類、情報抽出、ルーティング、サブエージェントの処理向けと記載されており、適応型の思考機能と1Mトークンのコンテキストウィンドウを備えています。大きなエージェントの中で繰り返す、範囲の限定された処理の候補です。Haiku 5.5のドキュメント。

移行前には、リクエストの互換性を確認してください。Anthropicは、temperature、top_p、top_kを指定しないよう求めています。共通のAPIラッパーを使う場合も、モデルごとの設定に対応する必要があります。また、コンテキストウィンドウが大きいからといって、長い入力を扱うすべての処理が効率重視モデルに適しているわけではありません。

想定タスクと設定を掲載したAnthropicのClaude Haiku 5.5ドキュメント。
Anthropic Claude:効率を重視する処理でも、固有のAPI仕様を確認します

Google:マルチモーダル入力の取り込みに使うGemini 3.5 Flash-Lite

Google Gemini 3.5 Flash-Liteは、高い処理量が求められるサブエージェントのタスクや文書解析向けと記載されています。テキスト、画像、動画、音声、PDFを受け取り、テキストを返します。構造化出力と関数呼び出しにも対応しています。受け取った資料を、決められた形式のレコードに変換する処理の候補です。Gemini 3.5 Flash-Liteのドキュメント。

音声機能では、入力形式と対話方法を区別してください。音声入力に対応していても、音声を生成できるとは限りません。このモデルはLive APIに対応していません。文書解析とリアルタイムの音声対話では、必要な機能が異なります。

対応する入力形式と機能を掲載したGoogleのGemini 3.5 Flash-Liteドキュメント。
Google Gemini:入力形式と併せて、対話方法も確認します

タスク別に見る、SLMとLLMの使い分け

検証すべき出力を基準に、最初のモデルを選びます。以下の推奨は、選んだチェックポイントが必要な入力と実行環境に対応していることを前提としています。

タスク最初に使うモデル切り替え・エスカレーションの条件
サポートへの問い合わせを分類するラベルを固定した小規模モデル複数の意図や例外によって、取るべき対応が変わる場合
定型的な文書からフィールドを抽出するスキーマと原文の照合を組み合わせた小規模モデルレイアウトが異なる場合や、複数文書をまたいだ解釈が必要な場合
承認済みの短いメッセージを書き換える小規模モデル文体、ニュアンス、相反する複数の指示が合否を左右する場合
検索で取得したポリシーの一節から回答する根拠の確認を組み合わせた小規模モデル記述が矛盾する場合や、提示した根拠を超える統合的な判断が必要な場合
不慣れな複数ツールのタスクを計画するフロンティアモデル小規模モデルには、範囲を限定して委任できる工程だけを任せます
長い案件履歴を突き合わせて整理するフロンティアモデル小規模な候補が同じ文書横断の検証に合格するまでは維持します
自由度の高い戦略文書やストーリーの草案を作るフロンティアモデル制約の明確な整形や書き換えを、後から小規模モデルに移します
完全にオフラインで動作させる実行環境に対応したローカルモデルリモートのフロンティアモデルには退避できないため、承認済みのローカル代替手段か人が対応します

**選択を変える判断基準:**小規模な候補を採用し続けるのは、同じ合格基準を満たし、重視する制約も改善できる場合です。頻繁に修正が必要なら、呼び出し単価が安くても、結果を得るまでの費用が安いとはいえません。

小規模モデルとフロンティアモデル、それぞれの強み

限定的な処理・応答時間・呼び出し単価:小規模モデル

範囲が決まった反復処理では、小規模モデルを最初に評価します。 短い分類や抽出なら、判定すべき出力が明確です。毎回、広範な推論に費用をかける理由はあまりありません。

ただし、モデルの規模は応答時間の測定値ではありません。ローカル実行ならリモート推論の通信往復はなくなりますが、端末の負荷が高ければ、ホスト型モデルより完了が遅くなる場合もあります。入力処理、生成、検証、再試行を含め、合格する結果が得られるまでの時間を測定してください。

費用も同様に、合格した結果あたりで比較します。小規模モデルを最初に試すカスケード構成では、最初の呼び出しと検証に費用がかかり、エスカレーションするたびに大規模モデルの費用も加わります。セルフホストでは、ハードウェア、遊休容量、運用の費用も必要です。実測で、単位時間あたりに得られる合格結果が増えるなら、小規模モデルの経路を残します。明らかに難しい処理は、最初から高性能なモデルに送ってください。

端末内実行・機密データの処理:ローカルの小規模モデル

リモートの推論サービスを使わずに機能を動かす必要があるなら、ローカルの小規模モデルが有力です。 たとえば、通信できない現場で作業員がメモを分類する場合や、元の文書を端末から出せないデスクトップ機能が該当します。

プライバシーを決めるのは「小規模」という呼び名ではなく、実際の処理経路です。テレメトリー、ログ、検索サービス、ツール、フォールバック先を確認してください。ローカルで試した後、自動的にクラウドで再試行すれば、最初からクラウドを呼ぶ場合と同じ境界を越えます。端末ごとの判断については、オンデバイスAIのガイドで解説しています。

複数段階の推論:フロンティアモデル

不慣れな計画や、判断の難しい例外への対応では、フロンティアモデルがより有力な出発点になります。 返金をめぐるトラブルでは、配送記録、ポリシーの例外、顧客との過去の合意を突き合わせる必要があるかもしれません。各フィールドを正しく抽出するだけでは、案件の解決には至りません。

小規模な推論モデルは、「小規模モデルには推論ができない」という見方への明確な反例です。問うべきなのは、その専門性が任せる工程に合うかどうかです。Phiの数学に重点を置いた評価だけでは、幅広いエージェント業務の信頼性は確認できません。個別に検証できる部分問題は小規模モデルに任せ、矛盾する根拠の解釈が結果を左右する部分では、フロンティアモデルを維持します。

長いコンテキストをまたぐ情報統合:実証されるまではフロンティアモデル

長い案件に散らばる根拠を突き合わせるなら、まずフロンティアモデルを使います。提示した一節からフィールドを探すなら、小規模モデルから評価します。 どちらもコンテキストを使いますが、求められる推論は異なります。

Qwen3.5-4Bの262,144トークン、Haiku 5.5の1Mトークンというウィンドウを見ると、小規模モデルや効率重視モデルは一律に短いコンテキストしか扱えない、とはいえません。ただし、関連するすべての記述を正しく結び付けられることまで証明する数値ではありません。Qwenのモデルカード、Haikuのドキュメント。

矛盾する条項、末尾近くの訂正、異なる節の根拠を組み合わせないと答えられない質問を使ってテストしてください。入力を受け付けられるだけでは、そのテストに合格したことにはなりません。生成前に関連する根拠を選ぶ検索処理は、どちらの規模のモデルでも負担軽減に役立ちます。

自由度の高い文章作成:フロンティアモデル

判断力、文体、一貫した構成が品質を左右するなら、最初はフロンティアモデルに任せます。 OpenAIのモデル選定ガイドも、範囲を絞った編集と、ニュアンスが求められる文章や難度の高い成果物を明確に区別しています。モデル選定ガイド。

承認済みのテンプレートに合わせた短い書き換えは、小規模モデルに向く候補です。一方、根拠が不完全な中で製品戦略を文章にまとめる仕事は、性質が異なります。どちらの出力も、必要な事実、留保すべき点、読者、文体に照らして確認してください。長さや流暢さだけでは品質を判断できません。どちらのモデル群も、事実の正確さや偏りがないことを保証するものではありません。

同じ機能の中で、SLMとLLMをどう振り分けますか?

すべてを判断するモデルを追加する前に、各工程に求める入力・出力や条件に基づいて振り分けます。ルーターはリクエストを処理するモデルを選びます。カスケードは、まず安価な経路を試し、検証に通らなければ上位の処理先へ引き継ぐ構成です。設計の詳細はモデルルーターのガイドで解説しています。

仮想のサポートアシスタントを考えてみましょう。顧客は「届いた荷物が破損していたので、配送料を返金してほしい」と伝えています。必要な処理は、問題の分類、注文の検索、ポリシーの解釈、返信案の作成です。すべてに同じモデル能力が必要なわけではありません。

  1. 最初にデータの取り扱い制約を適用する

    問い合わせをモデルに送る前に、アプリケーションのアカウントポリシーと、許可された送信先を確認します。リモート処理が禁止されているなら、すべての分岐を承認済みのローカルサービスか、人が対応するキューに限定してください。タスクが難しいことを理由に、このルールを暗黙に破ってはいけません。

  2. 小規模モデルには範囲を絞った抽出を任せる

    問題のカテゴリ、記載があれば注文番号、それらの根拠となる問い合わせ原文の正確な引用を求めます。不明な情報は不明のままにしてください。アプリケーションのコードで、許可されたカテゴリ、必須フィールド、原文からの引用、注文番号の実在を検証します。これらの検証で特定の失敗は検出できますが、解釈全体が正しいと証明できるわけではありません。

  3. 曖昧な案件は、元の根拠とともに引き継ぐ

    判断が分かれるポリシーの解釈、複数の要望が混ざった問い合わせ、検証に通らなかった案件は、承認済みのフロンティアモデルか人へ引き継ぎます。小規模モデルの要約だけでなく、元の問い合わせ、取得したポリシー、失敗した検証の内容も渡してください。モデルが自己申告する確信度は、評価によって裏付けられた振り分け指標の代わりにはなりません。

  4. 操作の権限管理は、生成処理の外に置く

    モデルには、返信やツール呼び出しを提案させます。アカウント権限、許可された操作、必要な人の承認は、アプリケーションのコードで強制します。正しそうな応答が得られても、それだけで返金を実行する権限が生まれるわけではありません。

小規模モデルの処理経路が検証ゲートに進み、回答する経路と、エスカレーションしてレビューする経路に分かれる図。
許可された送信先を確認したうえで、小規模モデルの経路を検証し、例外を引き継ぎます。経路の長さは概念を示しており、応答時間の測定値ではありません。

リクエストごとに、エスカレーションした理由、最終回答の合否、処理全体の所要時間を記録します。検証器はもっともらしい誤りを見逃すため、合格した小規模モデルの出力も一部を抽出してレビューしてください。ほぼ毎回エスカレーションするタスクのカテゴリは、最初からフロンティアモデルへ振り分けます。

さまざまな処理が混在する本番環境で、両方のモデルを組み合わせる理由はここにあります。同じ機能の中に、安価で検証しやすい工程と、難しい判断を要する工程があるからです。振り分けによって、工程ごとに必要な品質と応答時間を満たせます。

SLMとLLMの切り替えには、どんな負担がありますか?

機能全体を入れ替える前に、まず一つの工程を切り替えます。入力、出力スキーマ、根拠への参照、失敗時の挙動は維持し、プロンプトとAPI設定を新しいモデルに合わせて調整してください。HTTPインターフェースが同じでも、ツール呼び出しや回答が同じになる保証はありません。

ローカルの重みへ移行すると、モデルの提供、メモリ管理、バージョン更新、容量計画も自分たちの責任になります。ホスト型モデル同士の切り替えでも、リクエストパラメータや利用できるツールが変わることがあります。違いを吸収するアダプターを用意し、評価に使ったチェックポイントやモデルのバージョンを正確に記録してください。

現在のモデルが要件を満たしており、応答時間、運用費、データの配置場所について、実測に基づく変更理由がないなら、切り替える必要はありません。小さなモデルを使うこと自体が、優れたアーキテクチャを意味するわけではありません。

範囲が狭く安定したタスクで、なお挙動の改善が必要なら、許可された学習方法を確認したうえで、教師モデルの例から生徒モデルを学習させるモデル蒸留を検討します。まずはプロンプトと提示する根拠を改善してください。モデルの重みを変えるには、処理経路の変更より大きな取り組みが必要です。

よくある質問

ChatGPTはLLMですか、SLMですか?

ChatGPTは言語モデルを利用するアプリケーションであり、パラメータ数が固定された単一のモデルではありません。OpenAIのchat-latestドキュメントも、アプリケーションで使うモデルと、固定されたモデルのスナップショットを区別しています。アプリ名ではなく、基盤となるモデルを比較してください。

DeepSeekはSLMですか、LLMですか?

チェックポイントを指定する必要があります。過去の具体例では、DeepSeek-R1の総パラメータ数は671Bで、DeepSeek-R1-Distill-Qwen-1.5Bは、それよりはるかに小さな蒸留モデルです。どちらもDeepSeekのR1モデルカードに掲載されています。ブランド名だけでは規模は決まりません。

LLMとSLM、どちらを使うべきですか?

範囲が狭く検証可能なタスクなら、小規模モデルから始めます。不慣れな推論、矛盾する根拠、自由度の高い文章作成には、まずフロンティアモデルを使います。ローカル実行が必須なら、品質比較に入る前に候補となるモデルが絞られます。

AIにおけるSLMとは何ですか?

SLMは小規模言語モデルの略です。計算に必要なリソースが比較的少ない言語モデルを指す、相対的な呼び名です。それだけで、特化型、プライバシー保護、オフライン対応、正確さが備わるわけではありません。

SLMとLLMの違いは何ですか?

主な違いは相対的な規模で、それが実行環境や能力に影響します。共通のパラメータ数の境界はなく、呼び名には重なりもあります。Metaは小規模なLlama 3.2のチェックポイントもLLMと呼んでいます。実際に使うモデルとタスクを評価してください。

LLMの4つの種類とは何ですか?

普遍的な4分類があるわけではありません。アーキテクチャ、学習方法、入力モダリティ、パラメータ規模は、それぞれ異なる分類軸です。ある軸で作った一覧から、別のモデルが手元の端末で動くほど小さいかどうかは判断できません。

LLMの上位5モデルはどれですか?

固定の上位5モデルを挙げると、タスクや実行環境の制約が見えなくなります。この選択では、必要な入力とツールに対応する高性能な基準モデルと効率重視の候補を選び、代表的な仕事で比較してください。一般的なランキングでは、自分たちの機能に最適なモデルは決まりません。

LLMとGPTの違いは何ですか?

LLMは、より広いカテゴリを指します。GPTはGenerative Pre-trained Transformerの略で、そのカテゴリに含まれるOpenAIのモデルファミリーの名称です。Googleの言語モデル用語集で用語が説明されています。

AIの主要な5モデルとは何ですか?

普遍的な5モデルの一覧はありません。この表現は、学習方法、アーキテクチャ、商用モデルファミリーのいずれを指す場合もあります。言語を扱う機能では、モデル名を選ぶ前に、入力、出力、実行環境の制約、品質要件を明確にしてください。

「SLM vs LLM」は何を比較する言葉ですか?

小規模モデルと大規模モデルの比較を、逆の順番で表しただけです。タスクに合格する最も軽量な候補を選び、対応が認められた範囲を超える仕事には、より高性能なモデルか人に引き継ぐ経路を残します。

LLM・SLM・MLMは、どう違いますか?

MLMには複数の意味があります。隠されたテキストを予測するマスク言語モデルを指す場合もあれば、非公式にマルチモーダル言語モデルの意味で使われる場合もあります。どちらも、小規模と大規模の間にある別のパラメータ規模を定義するものではありません。Googleの用語集では、マスクを用いたモデリングとマルチモーダル入力を区別しています。

LLM・SLM・RAGは、どう違いますか?

RAG(検索拡張生成)は、検索で取得した根拠を生成モデルに渡す仕組みです。小規模言語モデルでも大規模言語モデルでも使えます。情報の不足には対応できますが、モデルが根拠を正しく解釈することまでは保証しません。

次に実装するなら、まず一つの工程から

来週、繰り返し発生する工程を一つ選び、モデルを比較する前に合格条件を書き出してください。プロンプトの調整に使わなかった評価用の事例を用意し、定型的な依頼、判断の曖昧なケース、根拠が欠けたケース、対象外の入力を含めます。

小規模な候補には本番のレコードを変更させず、現在の基準モデルと並行して動かします。正確さ、不合格となった出力、見逃した例外、処理全体の応答時間、運用負担を比較してください。合格したカテゴリだけを本番に採用し、フォールバックを残したうえで、合格した処理も継続して確認します。

最初に最適化する価値のある工程を選ぶ際は、AI業務ワークフロー監査チェックリストを活用してください。

公開日
カテゴリー
Build
AI蒸留の実践ガイド:小型LLMの学習から本番評価まで

AI蒸留の実践ガイド:小型LLMの学習から本番評価まで

AI蒸留で小型LLMに特定のタスクを任せるには、何を学習させ、どう評価すればよいのでしょうか。教師モデルと生徒モデルの仕組み、OpenAI・Google Cloud・Amazon Bedrockの対応状況、出力の学習利用をめぐる規約、本番切り替え前の評価と段階的リリースの手順を解説します。2026年10月26日Build
VLM(視覚言語モデル)とは?開発で使える機能と見極め方

VLM(視覚言語モデル)とは?開発で使える機能と見極め方

VLM(視覚言語モデル)は何ができ、どこで読み間違えるのでしょうか。スクリーンショット、グラフ、スキャン文書、商品写真の活用例から、OCRとの使い分け、APIと自前運用の選び方、画像トークンと解像度の関係まで解説。手元の画像で精度を確かめ、誤答をアプリに取り込まないための評価手順も紹介します。2026年10月26日Build
AIエージェントは分けるべき?マルチエージェント設計の判断基準

AIエージェントは分けるべき?マルチエージェント設計の判断基準

AIエージェントは、増やせば成果が上がるとは限りません。単一エージェントを保つべき仕事と、マルチエージェントが有効な仕事を比較表で整理。スーパーバイザー、階層型、ハンドオフ、グループチャットの違いから、独立した調査やレビューの切り分け方、トークン消費・待ち時間・手戻りを含めた評価方法まで解説します。2026年10月26日Build
プロンプトインジェクションとは?直接型・間接型の攻撃例とAIエージェントの対策

プロンプトインジェクションとは?直接型・間接型の攻撃例とAIエージェントの対策

プロンプトインジェクションとは何か、直接型・間接型の違いを受信トレイやCRMの例で解説します。AIエージェントによる情報流出や無許可の変更を抑えるために、権限の制限、出力の検証、人による承認、監視をどう組み合わせるかを整理。ツール連携前のチェックリストと、実際の操作結果を確かめるテスト手順も紹介します。2026年10月26日Build
GraphRAGとは?仕組み・RAGとの違いと導入の判断基準

GraphRAGとは?仕組み・RAGとの違いと導入の判断基準

GraphRAGは、個々の事実を探すRAGと何が違うのでしょうか。Microsoftの実装を軸に、ナレッジグラフとコミュニティ要約の仕組み、検索モードの使い分け、インデックス作成と更新の負担を解説。Neo4jやLlamaIndexとの違いも整理し、実際の質問で導入効果を見極める評価手順を紹介します。2026年10月26日Build
LLMエージェントの設計図:本番運用に必要な構成と責任分担

LLMエージェントの設計図:本番運用に必要な構成と責任分担

LLMエージェントを本番運用するための設計を、サポート業務の具体例で解説します。モデル、ツール、メモリ、オーケストレーションの役割から、人による承認、ログ、評価までを整理。既存サービスに任せる部分と自分たちで担う責任を見極め、単一エージェントから専門エージェントへ分ける判断基準も示します。2026年10月25日Build
Cursor 料金とモデルの選び方:10月の変更後に使えるモデル

Cursor 料金とモデルの選び方:10月の変更後に使えるモデル

Cursorの10月の料金改定後、どのモデルを使えるのでしょうか。Grok・ComposerとClaude・GPT・Geminiの利用条件、新旧プランの課金の違いを整理。Autoの選択肢、サブエージェントのモデル設定、APIキーの制約も確認し、日常のコーディングから難しい作業まで、目的に合うモデルの選び方を解説します。2026年10月25日Build
LLM temperatureとは?温度設定とパラメータ数の違いを解説

LLM temperatureとは?温度設定とパラメータ数の違いを解説

LLM temperatureの仕組みと、モデルのパラメータ数との違いを解説します。70Bモデルのメモリ計算、MoEの総数とアクティブ数、top-pやトークン上限を整理。OpenAI・Anthropic・GoogleのAPIごとの制約を踏まえ、情報抽出・文章作成・コード生成で使う初期設定と検証の考え方を紹介します。2026年10月25日Build
ニュースレター

毎週日曜、一通の手紙。動くシステムの話。感想戦ではなく。

週刊。スパムなし。いつでも解除できます。