返品FAQで、生成だけの構成と検索を加える構成を比べる
「開封した商品を返品できますか？」という問い合わせを考えます。本稿では、次の二つを自作の架空FAQ（よくある質問）として用意します。
| 文書 | 本稿が設定する条件 |
|---|---|
| FAQ-A：通常返品 | 自己都合による返品は未開封の商品に限り受け付ける |
| FAQ-B：初期不良 | 初期不良による返品は開封後も受け付ける |
これは実企業の規則や法定の権利を説明する例ではありません。質問には返品理由が含まれていないため、両方の条件を残し、初期不良か自己都合かを追加確認する回答を設計します。
以下は、この合成FAQを使う未実行の構成・評価案です。自作データで検証する手順を整理します。
本稿では、SarashinaのAPI（外部プログラムから機能を呼び出す窓口）を題材にします。
この例では、FAQ全文を文章生成モデルのminiへ渡す案を出発点にします。文書が増えた場合は、文章の特徴を数値の配列で表すembeddingを使い、アプリの検索とrerank（候補の並べ替え）を加えます。1
FAQが短く、全文を毎回渡せるなら、質問と二つのFAQを生成モデルにまとめて渡す構成から比較できます。検証担当者は、検索を加える判断材料として、文書量、更新頻度、回答に必要な条件を記録します。同担当者が、全文を収める条件と回答での条件の扱いを別々に確認します。
文書が増えた場合には、関連文書を検索して生成モデルに渡すRAG（検索拡張生成）が選択肢になります。候補検索、候補の並べ替え、回答生成を分け、どの段階で必要なFAQが落ちたかを記録する案です。
自前の環境でも、この構成を作れます。例えば、公開モデルのruri-v3-310mで文章を数値化し、ruri-v3-reranker-310mで候補を並べ替える方法があります。これらは自前環境に配備する公開モデルです。SarashinaのAPIを使う案とは、運用範囲を分けて比較します。
後輩この二つのFAQなら、検索も並べ替えも最初から必要ですか？
先輩まず全文を渡す構成を比較できるよ。文書が増えたら、必要な条件を検索候補に残せるかを記録して、構成を選ぶんだ。
10月13日公開：6モデルを4系統のAPIで使う
SB Intuitionsは2026年10月13日、「Sarashinaサービス」の無償βを一般公開しました。βは試用段階のサービスを指します。mini、nano、embedding、rerank、guard、translateの6モデルを、APIで利用できます。2
6月30日のCloud PF Type Aでは、共有型（計算資源を共用する形態）にtranslateを除く5モデルの提供が発表されました。専有型（計算資源を専用利用する形態）はminiとnanoが対象です。3
translateも、7月14日付の公式技術解説で紹介されています。10月13日は、これらのモデルを利用できる無償βサービスの一般公開日です。2
無償βでは、用途の異なるモデルをAPIで組み合わせて試せます。自前で各モデルの計算環境を配備する構成と、外部APIを使う構成では、運用範囲や利用条件が変わります。費用や精度の比較結果は、用途に合わせた検証で確かめます。
利用者はGoogleアカウントでログインできます。事前申し込みは不要です。
APIを呼び出す利用者は、管理コンソールでキー（認証用の秘密の文字列）を発行します。そのキーを認証ヘッダーへ送るBearer認証という方法を使います。4 公式発表では、無償βの料金は無料、終了時期は未定とされています。5
モデルの数とAPIの系統は異なります。Chat Completions（対話）ではmini・nano・guardを呼び出します。Embeddings（ベクトル化）、Rerank（並べ替え）、Translate（翻訳）を加え、計4系統で6モデルを扱います。公式API文書とモデル一覧を参照できます。1
ベクトル化、候補検索、並べ替え、生成をつなぐ
ここからは、FAQ-AとFAQ-Bの条件を回答まで残す、本稿の構成案を説明します。各処理をアプリケーション側で連携させる案です。
embedding：文章を比較できる数値にする
Sarashina3 embeddingは、文章を1,536次元（1,536個の数値）からなるベクトルに変換します。ベクトルは文章の特徴を表す数値の配列です。1リクエストで入力するテキストは1件、上限は8,000トークンです。トークンは、モデルが文章を処理する際の区切りの単位です。6
実装担当者は、質問用と文書用のtask_typeを対にして指定します。task_typeは用途に合う数値表現を選ぶ設定です。文書側にはRETRIEVAL_DOCUMENTを使います。Embeddings仕様で、質問側に合う設定と対応を確認します。実装担当者は、後段の生成モデルへ回答作成を任せるよう、処理を設計します。
出力ベクトルは未正規化（長さが1にそろっていない状態）です。比較には、長さの違いを除いて向きを比べるコサイン類似度を使うか、先に長さを1へ揃えてから内積（対応する要素の積を足し合わせる計算）を求めます。未正規化のまま内積を使う構成とは、検索の評価条件を分けます。6
embeddingのAPIが返すのはベクトルです。FAQを分割し、索引（検索用のデータ）へ登録し、質問と照合して候補を取り出す処理はアプリケーション側に置きます。文書の閲覧権限や更新も、検索に渡す前に管理する設計です。
文書分割の設計例は、関連記事「JetBrainsのコード検索RAG：構文分割と圧縮の制約」も参照できます。
rerank：取り出した候補の順序を見直す
Sarashina3 rerankは、質問と候補文書を受け取り、関連度のスコア順に返します。1回に渡せる文書は1〜20件、質問と各文書のペアは8,000トークン以下です。7
APIを呼び出す実装担当者は、用途別のtask_typeを選びます。CUSTOMIZEでは、同担当者が独自の指示を指定できます。Rerank仕様で、入力と戻り値の形式を照合します。
スコアは候補間の順位を比べる値です。確率への校正（値と確率が対応するように調整すること）は行われていません。採用した件数と、回答に必要な条件が残ったかを記録します。7
最初の検索候補にFAQ-Bが入っていなければ、並べ替えにはFAQ-Bを渡せません。そこで初期検索の候補集合と、並べ替え後に残した集合を別々に評価します。順位が高い文書にも、内容の確認と条件の照合が必要です。
mini・nano：渡された条件から回答を作る
本稿の例ではminiを生成に使う構成を考えます。miniは文章生成や対話、nanoは定型的なタスク向けの高速・軽量モデルとして案内されています。1
本稿の案では、nanoは短い定型処理の比較候補とします。translateは、日英翻訳を要する入力・出力を扱う際の別の評価対象として考えます。
質問とFAQ-A・FAQ-Bを渡し、根拠のIDと条件を回答へ反映する指示を設計します。期待する応答の方向は「初期不良か自己都合かを確認する」です。どちらかのFAQを失った場合や、両方を渡しても条件を取り違えた場合を区別して記録する案です。
この図は本稿の未実行の設計案です。索引へのFAQ登録や権限確認もアプリケーション側で用意します。
guard：最後の発話の有害性を分類する
Sarashina3 guardは、対話の最後の発話を対象に、安全・有害の判定と有害カテゴリT1〜T12を返します。8 判定を受けて保留や遮断へ進める分岐は、呼び出し側で実装します。
有害性の分類と、回答がFAQの条件を正しく説明したかは別の評価です。引用の対応、機密情報、業務上の権限、プロンプト注入（入力文へ指示を紛れ込ませる攻撃）への対処も、それぞれの確認項目として扱います。
自作FAQで、段階別に何を記録するか
検証担当者が同じ質問集合とFAQ版を使い、生成だけの構成と検索を加えた構成を比較する案を示します。実行条件を揃え、文書数、検索候補数、採用件数、渡した文書IDを記録します。
| 段階 | この例で確認するもの | 見直す箇所の例 |
|---|---|---|
| 初期検索 | 必要なFAQ-A・Bが候補に入った割合 | task_type、文書分割、索引方式 |
| 並べ替え | 採用する上位文書に両方の条件が残るか | 指示、候補数、採用件数 |
| 回答生成 | 条件漏れ、追加確認、引用IDと原文の対応 | 根拠の渡し方、生成への指示 |
| guard | 通常問い合わせの誤遮断と対象ケースの見逃し | 別の正解ラベルとアプリの対処 |
この記録を材料にして、担当者が失敗の起点を調べます。必要な文書が検索で漏れたケースと、文書を渡しても回答が条件を省いたケースを分けて読みます。
guardの評価案も、規約に適合する入力の範囲で扱います。有害な入力や注入攻撃を実サービスへ投げるテストは行っていません。実行前に、予定する評価方法が利用条件に合うかを確認します。
guardの公式技術解説は、提供者内で有害性の正解判定を付ける担当者（アノテーター）が作成した日本語テストセットを用いています。この評価は、分類結果とモデルの処理時間を比較しています。対象データと評価条件を確認し、自作FAQで記録する候補や根拠の対応とは分けて読みます。8
後輩回答を間違えたとき、最初に何を見ればよいですか？
先輩必要なFAQが検索候補に入ったか、その条件が生成に渡ったかを順に見るんだ。guardの分類は、回答の根拠の確認と別に記録するよ。
毎分の呼び出し枠と、データ利用条件を確認する
呼び出し回数の上限（レート制限）は、契約主体とモデルの組み合わせごとに適用されます。mini・guard・translateは各6 RPM、nano・embedding・rerankは各60 RPMです。RPMは1分当たりのリクエスト数です。9
60秒の累計を期間ごとにリセットする方式で、一時的な呼び出し枠の上乗せ（バースト）は許可されていません。制限超過時は、リクエスト過多を示すHTTP 429エラーとなり、再試行待ち時間を示すRetry-Afterや残り枠、リセット時刻のヘッダーは返りません。公式のレート制限文書は再試行の待ち時間を一定倍ずつ延ばす指数バックオフを案内しています。
索引作成と質問のベクトル化は、同じembedding枠を使います。この例でminiとguardをそれぞれ1問い合わせに1回使い、枠を他用途と共有しなければ、各6 RPMが呼び出し枠の上限になります。実際の処理件数は、遅延、失敗、再試行、guardの複数回呼び出しでも変わります。レート制限と、実測の処理速度やサービス水準の保証を分けて確認します。
利用規約第3条では、日本国内に居住する個人と国内に本店所在地を持つ法人が対象です。18歳未満には親権者または法定後見人の同意が必要です。10
第10条には、特定の個人を識別できる情報の入力禁止が定められています。11 同条には、自動的な出力抽出、出力データを用いた競合・類似サービスの開発目的での利用、医療・法律・金融等の専門的助言としての利用にも制限があります。11 本稿の案は自作の合成FAQを前提とし、実顧客データ、機密情報、第三者の権利に関わる入力は用意していません。
第11条は、有償・無償の入力と出力を、サービスの提供・維持、法令遵守、学習、新サービス開発等に利用できると定めています。有償向けの所定の手続きでは、その後の入力を学習利用の対象から外せます（オプトアウト）。
学習済みパラメータは、学習によって調整されたモデル内部の数値です。このオプトアウトの規定は、提供者に設定前のデータや学習済みパラメータを遡って削除する義務を負わせません。12
無料βでの取り扱いは、有償向けの規定と分けて提供者へ確認します。商用の製品・サービスへ組み込む際は、再許諾（第三者への利用許可）に関する利用規約第16条の事前同意と手続きを確認します。
予定する第三者提供や自動処理にどの条件が該当するかは、実行前に提供者へ確認します。保存や削除、提供地域、継続運用の条件も、実際の導入要件として確認する項目です。
検証を始める前に、利用条件に合う自作データと評価方法を用意します。その上で生成だけの構成と検索を加える構成を比べ、必要な条件が回答まで残るかを記録します。
