Sakana Namazuとは、日本語と日本の商習慣に適合させたLLMのAPIのことです。

海外のフロンティアモデルと日本語特化モデルのどちらを事務所に入れるかで、検証すべき論点が変わります。この記事では、2026年8月に提供が始まったSakana Namazuを士業事務所の実務に載せるとき、何を測り、何を有資格者が押さえるかを7つの確認軸に整理します。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、ベンダーの仕様は各社の公表資料で確認しています。Sakana AIの公表によれば、提供開始は2026年8月3日で、入力100万トークンあたり0.95ドル、出力100万トークンあたり4ドルという料金設定です（出典: Sakana AI「Sakana Namazu」提供開始、gihyo.jp）。

日本語特化LLMが2026年夏に士業の選択肢へ入った経緯

Sakana Namazuは、Sakana AIが自社のチャットサービスに搭載してきたモデル「Namazu」を更新し、APIとして開放したものです。ベースはMoonshot AIが公開するオープンモデルKimi K2.6で、そこへ日本語と日本の業務文脈に合わせた事後学習と、特定の話題での応答回避や出力の偏りを抑えるチューニングを重ねたと説明されています（出典: Sakana AI）。

士業事務所にとって重要なのは、モデルの素性が公開されている点です。ベースモデルが明示されていれば、そのモデル系統でどのような弱点が報告されているかを外部の情報から追えます。素性が不明なブラックボックスと比べ、採用理由を事務所の内部規程へ書き残しやすくなります。

性能面では、日本語での指示追従を測るJFBenchや、日英翻訳、回答の中立性を測る自社ベンチマークでベースモデルを上回ったと公表されています。とくに中立性の指標では34.10%から56.30%へ改善したと示されています（出典: Sakana AI）。JFBenchはPreferred Networksが公開しているベンチマークで、第三者が同じ条件で追試できる設計になっています。

一方で、これらのベンチマークは士業の文書を対象にしたものではありません。契約書の条項抽出、税務通達の読み解き、就業規則の整合チェックといった作業の精度は、ベンチマークの数字からは読み取れません。ここが、事務所側で検証を組む理由です。士業のチカラではAIツール選定でセキュリティ認証をどう読むかでも触れたとおり、ベンダーの公表値と自事務所の業務での再現性は別物として扱う運用が現実的です。

士業事務所でSakana Namazuを検証する7つの確認軸

検証は、いきなり本番業務へ入れず、過去案件を使った再現テストから始める流れが扱いやすくなります。以下は7つの軸と、その測り方です。

第一に、専門用語の取り違えです。士業の文書には、一般語と意味がずれる語が多く含まれます。「善意」「悪意」「相当の期間」「みなす」と「推定する」の区別などが典型です。過去の書面から20件ほど抜き出し、モデルが語義を一般用法で解釈していないかを確認します（出典: 検証件数は士業のチカラ編集部による設計例）。

第二に、条番号と通達番号の再現です。生成AIは条番号を作文する傾向が知られています。出力に条番号が含まれた場合、そのすべてをe-Gov法令検索または府省庁の原文で突き合わせる工程を、検証段階から手順に組み込みます。この工程は有資格者または実務経験のある担当者が受け持ちます。

第三に、敬語と定型文の質です。日本語特化を掲げるモデルの差が出やすい領域で、顧問先向けの案内文や督促文の下書きで比較すると差が見えます。

第四に、長文の保持力です。就業規則や賃貸借契約書のように条項が数十に及ぶ文書で、前半の定義と後半の運用条項の矛盾を拾えるかを見ます。長文契約書の読解についてはClaude Opus 5で長文契約書を読むならで検証軸を整理しています。

第五に、エージェント動作の安定性です。Sakana NamazuはWeb検索とコード実行のビルトインツールを備え、OpenAI互換のfunction callingに対応しています（出典: Sakana AI）。調査系の業務を任せる場合、途中でツール呼び出しが崩れないかを、10回程度の反復で見ます。

第六に、拒否率です。同社は特定の話題での応答回避を抑えるチューニングを施したと説明しています。士業の業務では、刑事事件、債務整理、労使紛争など、汎用モデルが回答を避けやすい題材が日常的に登場します。実際の相談メモを匿名化した題材で、下書き作成が止まらないかを確認します。

第七に、切り替えコストです。OpenAI互換APIのため、既存コードはbase_urlの書き換えとAPIキーの設定で動くと案内されています（出典: Sakana AI）。事務所の既存ツールがOpenAI互換で組まれていれば、比較検証の工数は小さく収まります。

7つの軸のうち、事務所として先に決めておきたいのは合格ラインです。条番号の誤りが1件でも出たら不採用とするのか、誤りが出ても検出工程で拾えるなら採用とするのかで、必要な体制が変わります（出典: 合格ラインの設計例は士業のチカラ編集部による整理）。前者は運用が軽くなる代わりに導入できる業務が狭まり、後者は業務範囲が広がる代わりにレビュー工程を常設する必要が出ます。日本語特化モデルは単価が低い分、後者の設計と相性が良い面があります。

検証結果は、口頭ではなく記録として残します。残す項目は、検証日、対象業務、入力した文書の種類、モデル名とバージョン、出力の評価、誤りの内容と件数、確認した担当者名の7項目です。この記録があると、モデルを採用した理由を後から説明でき、事務所の内部規程やISMSの運用記録としても機能します。モデルは更新されるため、同じ検証を四半期ごとに回す運用を組んでおくと、性能の変化に気づけます。

検証用のプロンプトは、次のような形で用意します。

あなたは日本の士業事務所の下書き作成担当です。以下の条文テキストを読み、
争点になり得る箇所を列挙してください。

制約:
- 条番号は、与えられたテキストに書かれているものだけを引用すること
- テキストに無い条番号は、絶対に出力しないこと
- 判断や結論は書かず、「確認が必要な箇所」として列挙すること
- 各項目に、根拠となるテキスト内の該当箇所をそのまま引用すること

対象テキスト:
（ここに架空のA社との業務委託契約書の条文を貼る）

比較検証では、同じ入力を複数モデルへ流し、出力の差分を機械的に取ります。

以下は同一の入力に対する2つのモデルの出力です。
出力Aと出力Bを比較し、次の観点で差分表を作らず、箇条書きで整理してください。

1. 事実関係の食い違い（どちらかにしか無い記述）
2. 条番号・数値の食い違い
3. 敬語表現の適切さの差
4. 出力の長さと冗長さ

出力A:
（貼付）

出力B:
（貼付）

差分が出た箇所だけを有資格者が確認する流れにすると、レビュー工数を絞れます。5人規模の事務所で20件の再現テストを回す場合、担当者の作業が半日、有資格者の確認が2時間程度という配分が目安になります（出典: 士業のチカラ編集部による試算）。

顧問先資料をSakana Namazuに入れる前に決めておく3つのこと

生成AIの導入で最初に決めるのは、性能ではなく入力範囲です。士業の守秘義務は職種ごとに条文が置かれています。弁護士法第23条には、秘密保持の権利および義務を定めた規定が置かれています。税理士法第38条には、秘密を守る義務の規定が置かれています。司法書士法第24条と行政書士法第12条にも、同じ表題の規定が置かれています。条文の当てはめは有資格者の判断領域であり、ここでは条文の所在を示すにとどめます。

1つ目に決めるのは、入力データの取り扱いに関する事実確認です。2026年8月19日時点で、Sakana AIの提供開始告知および製品ページからは、APIへの入力データを学習に利用するか否かを明示した記述を確認できませんでした。この点はAPI Consoleの利用規約およびエンタープライズ向けの問い合わせ窓口で、事務所として文書で確認を取る対象になります。公表資料で確認できない事項を推測で規程に書くと、後から食い違いが生じます。

2つ目は、顧問先への説明です。個人データを外部サービスへ渡す場面については、個人情報の保護に関する法律第27条が第三者提供の制限を定め、同条第5項第1号で委託に伴う提供の扱いを規定しています。事務所によっては、業務委託契約書または個人情報の取扱いに関する覚書へ、利用するクラウドAIの類型を書き加える運用を採っています。個別の案件がどの類型に当たるかの判断は、有資格者が行う領域です。

3つ目は、入力してよい情報の粒度です。実務では、氏名・住所・法人名・取引先名を伏せた状態なら投入可、原本のPDFは投入不可で抜粋テキストのみ可、といった粒度で線を引く事務所が多く見られます。日本語特化モデルは日本語の固有名詞に強い分、伏せ字が不十分だと文脈から推定される可能性も想定しておく必要があります。守秘義務と規程の設計は士業事務所のAI費用対効果をどう測るかで扱った運用コストにも直結します。

この3点を決めたら、事務所規程への落とし込みに進みます。規程に書く内容は、利用を認めるモデルの一覧、投入してよい情報の粒度、APIキーの管理者、利用ログの保存期間、顧問先への説明が必要になる場面、そして違反があったときの報告先の6項目が骨格になります。日本語特化モデルを新たに加える場合、既存の規程のうち利用を認めるモデルの行を1行足すだけで済むように、モデル名を列挙する形式で書いておくと更新が軽くなります（出典: 規程設計の例は士業のチカラ編集部による整理）。

顧問先への説明は、契約更新のタイミングにまとめるやり方と、AIを使う業務が発生した時点で個別に伝えるやり方があります。前者は事務負担が小さく、後者は説明の具体性が高くなります。どちらを採るにせよ、説明した事実と日付を案件ファイルに残しておくと、後の照会に耐えられます。士業の守秘義務は事務所としての管理体制が問われる場面が多いため、記録の有無が実務上の差になります。

導入で起きやすい3つの失敗と回避策

1つ目は、ベンチマークの数字をそのまま事務所の期待値にしてしまう失敗です。中立性指標が34.10%から56.30%へ改善したという公表値は、士業文書の精度を示すものではありません（出典: Sakana AI）。過去案件での再現テストを挟まずに本番へ載せると、最初の1件で信頼を失います。

2つ目は、料金の見積もり漏れです。ビルトインのWeb検索とコード実行は本体のトークン料金とは別建てで、Web検索が1,000回あたり7ドル、コード実行が1時間あたり0.12ドルと案内されています（出典: gihyo.jp）。調査系のワークフローを自動化すると、検索回数が想定を超えることがあります。試験運用の段階で、1タスクあたりの検索回数を記録しておく運用が有効です。

3つ目は、野良利用です。OpenAI互換で切り替えが容易な分、担当者が個人のAPIキーで独自に使い始める事態が起きやすくなります。誰が、どの案件で、どのモデルへ、何を入力したかを追えない状態は、守秘義務の管理上の弱点になります。APIキーの発行を事務所側で一元化し、利用ログを保存する設計を、検証段階から入れておく方法があります。

費用と工数をトークン単価から見積もる

料金は入力100万トークンあたり0.95ドル、出力100万トークンあたり4ドル、キャッシュ入力100万トークンあたり0.15ドルと公表されています（出典: gihyo.jp、料金の詳細はSakana AIの料金ページ）。

日本語の文書はおおよそ1文字が1トークン前後で換算されるため、1万字の契約書を読ませて3,000字の要約を返す作業は、入力1万トークン前後、出力3,000トークン前後になります。これを月200件処理すると、入力200万トークン、出力60万トークン程度です。上記の単価で計算すると、月あたり4ドル前後という水準になります。為替を1ドル150円とすれば、月600円程度です（出典: 士業のチカラ編集部による試算。単価はgihyo.jp）。

つまり、モデルの利用料そのものは、士業事務所の規模では判断の主因になりません。判断の主因になるのは、検証にかける人件費と、レビュー体制の設計です。初期検証に担当者1名で20時間、有資格者の確認に5時間を見込むと、そちらのほうが桁違いに大きいコストになります（出典: 士業のチカラ編集部による試算）。導入判断は、この人件費に見合う削減効果が出るかで組み立てる考え方があります。

日本語特化モデルの登場が士業に与える論点

日本語特化モデルの選択肢が増えたことで、士業事務所には業務ごとにモデルを使い分けるという構図が現実味を帯びてきました。定型的な日本語の下書き、顧問先向けの案内文、大量の和文書類の一次仕分けは、低単価の日本語特化モデルで足りる場面があります。一方、複雑な論点整理や長文の矛盾検出は、引き続きフロンティアモデルの領域が残ると考えられます。

ここで論点になるのは、モデルを増やすほど検証と規程の管理コストが増える点です。1つのモデルに絞れば管理は軽くなりますが、業務ごとの最適化は諦めることになります。事務所として、どこまでの数を管理できるかを先に決める考え方が、実務では扱いやすくなります。オープンウェイトモデルの扱いについてはQwen3.8がオープンウェイト公開、ライセンス2種と士業の3論点でも整理しています。

もう1つの論点は、国内事業者であることをどう評価するかです。日本法人が提供するサービスであることは、契約や紛争時の実務上の扱いやすさに影響し得ます。ただし、サーバの所在地やデータの保存先が国内であるかは別の論点であり、公表資料で確認できない部分は事業者への直接確認が必要になります。国内事業者という属性と、データが国内で処理されるという事実は、切り分けて確認する対象です。

3つ目の論点は、価格競争がどこまで続くかです。オープンモデルをベースに事後学習で差別化する手法が広がれば、日本語特化モデルの単価はさらに下がる可能性があります。単価が下がるほど、士業事務所にとっての判断軸はコストから精度と体制へ移ります。今のうちに検証の型と記録の型を作っておけば、モデルが入れ替わっても同じ手順で評価し直せます。逆に、型がないまま安いモデルへ飛びつく運用を続けると、そのたびに検証をゼロから組み直すことになります。

よくある質問

Sakana Namazuは士業の業務に使えますか

現時点で判断材料になるのは、公表されているベンチマークと料金、そしてOpenAI互換という仕様です。士業文書での精度は公表されていないため、事務所ごとに過去案件での再現テストを行い、その結果で判断する流れが現実的です。

入力したデータは学習に使われますか

2026年8月19日時点で、Sakana AIの提供開始告知および製品ページからは、この点を明示した記述を確認できませんでした。API Consoleの利用規約を確認し、不明な点は事業者へ直接照会する対応が考えられます。

既存のChatGPT向けのコードから乗り換えられますか

はい、OpenAI互換APIのため、base_urlの書き換えとAPIキーの設定で動くと案内されています（出典: Sakana AI）。ただし、ツール呼び出しの挙動やレスポンスの傾向は異なるため、切り替え後に同じ品質が出るかは検証が要ります。

フロンティアモデルと比べて何が違いますか

公表されているのは、日本語の指示追従や日本固有の文脈に関するベンチマークでベースモデルを上回ったという結果です（出典: Sakana AI）。フロンティアモデルとの直接比較は公表されていないため、事務所で同一入力を流して比較する方法が、判断材料として最も手堅くなります。

顧問先の資料をそのまま入れてよいですか

守秘義務の条文は職種ごとに置かれており、税理士法第38条などが該当します。個別の資料が投入可能かの判断は有資格者が行う領域であり、事務所としては入力可能な情報の粒度をあらかじめ定めておく運用が広く採られています。

検証にはどのくらいの期間がかかりますか

過去案件20件程度の再現テストであれば、担当者の作業で2〜3日、有資格者の確認を含めて1週間程度が目安になります（出典: 士業のチカラ編集部による試算）。対象業務を絞るほど期間は短くなります。

料金はどのくらいかかりますか

入力100万トークンあたり0.95ドル、出力100万トークンあたり4ドルです（出典: gihyo.jp）。ビルトインのWeb検索とコード実行は別料金のため、調査系の自動化を組む場合は回数の想定が要ります。

事務所規程には何を書けばよいですか

規程の骨格として挙げられるのは、利用を認めるモデルの一覧、投入してよい情報の粒度、APIキーの管理者、利用ログの保存期間、顧問先への説明が必要になる場面、違反時の報告先の6項目です。モデル名を列挙する形式にしておくと、新しいモデルを追加するときの改訂が軽くなります。

検証結果はどのように残せばよいですか

検証日、対象業務、入力文書の種類、モデル名とバージョン、出力の評価、誤りの内容と件数、確認した担当者名の7項目を記録として残す方法があります。モデルは更新されるため、四半期ごとに同じ検証を回して結果を追記する運用が扱いやすくなります。

参考文献

• Sakana AI「Sakana AI、日本語特化のLLM API「Sakana Namazu」を提供開始」
• gihyo.jp「Sakana AI、日本に特化したLLM「Namazu」をアップデート、APIサービス「Sakana Namazu」として提供開始」
• e-Gov法令検索 税理士法
• e-Gov法令検索 弁護士法
• e-Gov法令検索 司法書士法
• e-Gov法令検索 行政書士法
• e-Gov法令検索 個人情報の保護に関する法律
• Preferred Networks JFBench

※士業のチカラでは、生成AIの導入支援から運用最適化まで、貴事務所の業務に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://shigyonochikara.jp/contact/