日本語タスクに強い LLM はどれか — Claude / GPT / Gemini と国産モデルの実用比較

「日本語が得意」とは何のことか

「このモデルは日本語が得意」という言い回しは便利ですが、実務では曖昧すぎます。

JLPT N1 レベルの文法問題が解けることと、お客さまへの謝罪メールがちゃんと書けることは、別の能力です。Wikipedia 日本語記事の要約と、契約書からリスク条項を抽出する作業も別物です。「日本語が得意」と一括りにしてしまうと、自社のサービスにどのモデルを採用すべきかという判断ができなくなります。

私が手元のプロダクトでモデル選定をするときに見ている評価軸は、おおまかに以下の 5 つです。

敬語のレジスター調整 — カジュアル → ですます、ですます → 尊敬・謙譲、お客さま向け → 上長報告。同じ意味内容を、相手と場面に応じて書き直す能力。

漢字混じり長文の理解と要約 — 法律文書、医療レポート、IR 資料のような、和語・漢語・カタカナ語が密に交錯する長文を構造を保ったまま要約できるか。

ビジネスメール起草 — 謝罪、断り、依頼、督促、社外案内。日本語ビジネスメール特有の「クッション言葉」「結論を後ろに置く語順」「相手のメンツを潰さない含意の調整」を自然にこなせるか。

専門用語の精度 — 法律、医療、IT、金融、特許。ドメイン用語を正確に理解し、間違った訳語や似て非なる用語に置き換えてしまわないか。

助詞と語尾の一貫性 — 長い文章を生成したとき、助詞の選択（は/が、に/へ、で/にて）や語尾（です・ます・である）が首尾一貫するか。短いプロンプトでは破綻が見えにくく、長文生成で初めて差が出る項目です。

これらの軸で見ると、「日本語が得意か」は単一スカラーではなく、5 次元のベクトルで評価する話になります。

グローバル旗艦勢の日本語

2026 年 5 月時点で、現場で使われているグローバル旗艦モデルの日本語パフォーマンスを、上記の評価軸で観察した範囲でまとめます。

Claude Opus 4.7 — 敬語のレジスター調整は安定しています。長文要約も構造を保ちやすい。「お客さまに対する婉曲的な断り」のような文脈依存の高いタスクで、相手のメンツを潰さない言い回しを自然に選んでくれる印象です。専門用語の取り扱いも比較的慎重で、知らない用語をでっち上げにくい。コストは高めなので、品質が要求される文書生成や顧客対応に絞って使うのが現実的です。

Claude Sonnet 4.6 — Opus に近い日本語品質を、より低いコストで提供します。私の手元では、社内ナレッジ検索やレポート要約のようなボリュームのある日本語タスクは Sonnet で回しています。Opus と並べたときに差が見えるのは、長文での助詞や語尾の安定性、それから「読み手の感情を慮る」ような繊細な調整。多くの実務ユースケースでは Sonnet で十分です。

GPT-5.5 — 日本語は自然です。明示的にトーンや敬語レベルを指示すれば、その指示に対する追従性は高い。一方で、指示を曖昧にしたまま投げると、Claude 系列に比べてやや「翻訳調」「説明的すぎる」文章が出ることがあります。プロンプトを丁寧に書けば差は縮まります。

Gemini 3.1 Pro — 長コンテキスト処理と組み合わせたときの日本語要約は強力です。100 万トークン超のコンテキストに日本語の社内資料を全部突っ込んで質問する、といった使い方では旗艦勢の中でも目立つ性能を見せます。一方で短いビジネスメール起草のような繊細な敬語タスクでは、Claude のほうが好まれる場面もあります。

Gemini 3.1 Flash — 速度とコストが圧倒的に有利。日本語の品質は基本的なタスク（短い要約、分類、エンティティ抽出）なら問題ない水準です。お客さま向けの一次返答のような繊細な文章生成にメイン採用するのはおすすめしませんが、内部処理のコストセンシティブな部分で活躍します。

ここまでのまとめとして、2026 年時点での率直な観察は次のとおりです。

旗艦グローバルモデルの日本語性能は、ほとんどの実務タスクで「十分実用レベル」を超えている。「日本語特化モデルでないと話にならない」という認識は、もう古い。

ただし「特化モデルが意味を持つ場面」がなくなったわけではありません。次のセクションで国産モデルの立ち位置を見ます。

国産 LLM の立ち位置

2025-2026 年時点で言及される主要な国産 LLM を、率直に整理します。性能を断定する数値は出しません（ベンダーの公開数値は前提条件が揃っていないので、横並び比較が成立しないため）。代わりに、市場ポジションと実用上の強み・弱みに焦点を当てます。

Tsuzumi（NTT） — NTT が開発する軽量 LLM。「軽量」「国内データセンター完結」「業界特化チューニング」を旗印にしています。法人向けの非機能要件、特に「データを国外に出せない」「自社環境にホストしたい」といった要件を抱える業界で採用例が出ています。性能面では旗艦グローバル勢に対して全領域で勝てるとは公式にも主張しておらず、特定タスクでのチューニングと運用コストの低さで戦う路線です。

Sarashina（ソフトバンク） — ソフトバンクが進める日本語特化 LLM。通信事業者の顧客基盤と統合された運用が想定されており、エンタープライズ向けにパッケージとして提供される文脈で語られることが多いです。日本語の自然さは公開デモを見る限りまっとうですが、これも「グローバル旗艦に対する優位」を主張するというより、国内顧客基盤と運用基盤を含めた全体パッケージとして売り出されています。

Llama-3-Swallow（東工大） — Meta の Llama 系列をベースに、日本語データで継続学習された研究プロジェクト。オープンウェイトで提供されているため、研究用途や、自社で重みを保有してファインチューンしたい組織にとって貴重な選択肢です。研究コミュニティで一定の評価を得ており、日本語ベンチマークでも善戦しています。プロダクション運用にあたっては、自社で推論基盤を整える必要があるため、運用工数が前提コストとして乗ります。

CALM2（CyberAgent） — CyberAgent が公開した日本語 LLM。広告・コンテンツ生成のような、自社の事業ドメインに直結したユースケースで磨き込まれてきた経緯があります。一般公開モデルとしてオープンソースで使えるバージョンもあり、研究・実験用途でアクセスしやすい部類です。

PLaMo（Preferred Networks） — Preferred Networks が開発する大規模言語モデル。日本語と英語のバイリンガル設計を打ち出しており、研究実績の蓄積がある同社らしく技術的な完成度を訴求しています。商業利用にあたってはエンタープライズ契約のかたちが取られることが多く、特定の業界向けに特化されたバリエーションも開発されています。

国産モデル全体に共通する立ち位置を 1 文でまとめると、こうなります。

「グローバル旗艦と性能で正面から殴り合う」のではなく、「国内データガバナンス・特定ドメイン・国内運用パッケージ」で意味を持つ層。

これは決して否定的な評価ではありません。日本企業のうち、データを米国クラウドに渡すことに対して情シスの審査が通らない、という案件は実在します。そういった現場では、性能で 10% 劣っていても、国内インフラで完結することのほうが事業上クリティカルです。

用途別のおすすめ

ここからは「自社サービスでどう使い分けるか」という現場の話に絞ります。私が普段相談を受けて答えている内容を、用途別に整理します。

この表は絶対的なものではなく、「私ならこう薦める」という提案です。御社の実際のデータでテストすることが、最終的には最強の意思決定材料になります。

コストと運用の観点

技術的な性能と並んで、日本企業に固有のコスト・運用観点も整理しておきます。

JPY 建て請求 — グローバル旗艦勢は基本的に USD 建て請求です。為替レート換算と、月次決算でのレート確定処理は経理部の仕事を増やします。月数十万円の AI コストならノイズですが、月数百万円規模になると為替変動だけで月次予算がブレる現象が起きます。JPY 建てで請求書を発行できるプラットフォームを経由すると、ここの面倒は消えます。

適格請求書（インボイス制度）対応 — 2023 年 10 月開始の適格請求書等保存方式に対応した請求書が出るかどうか。これは仕入税額控除に直結するので、経理部から確実に質問されます。海外プロバイダ直契約だとインボイス番号が出ない場合があり、国内 SaaS や日本法人を持つプラットフォームを経由するほうが、月次処理が圧倒的に楽です。

国内データセンター稼働 — モデル推論が物理的にどこで実行されるか。お客さまデータを「越境して送らない」という要件は、特に金融・医療・公共領域で根強くあります。グローバル旗艦勢のうち、Anthropic は AWS 経由で東京リージョン提供、Google も日本リージョン展開、Microsoft 経由の OpenAI も日本リージョン提供と、選択肢は増えてきました。ただし契約形態と実際のデータ経路は別の話なので、案件ごとの確認が必要です。

国産モデルのコスト構造 — エンタープライズ年間契約が中心で、トークン単位の従量課金型 API として広く公開されているケースは少ない印象です。「月 X 円で X トークンまで、超過時は X 円/トークン」のような商業 API モデルでスケールに合わせて最適化したい開発チームには、グローバル旗艦勢の API のほうが運用しやすいでしょう。逆に、年間契約で予算を確定させたいエンタープライズ調達には、国産モデルの提供形態のほうが馴染みます。

ここの判断は、技術部門だけでなく経理・法務・調達部門との合意形成が要ります。「単価が安いモデル」を選ぶことが、組織全体での「総コストが安い」につながるとは限りません。

ハイブリッド戦略を推す

ここまで見てきた内容を踏まえて、私が日本市場のサービスにおすすめする戦略を 1 文で言うと、こうなります。

グローバル旗艦勢を主戦力に据え、特定ドメイン・特定要件で必要な部分だけ国産モデルや特化モデルを差し込む。

具体的には、

• 通常の日本語生成・要約・チャットは Claude / GPT / Gemini の中から用途に合わせて選ぶ
• 大量バッチや単価重視のジョブは Gemini Flash や小型モデルに分担させる
• 国内データ要件のあるプロダクトラインだけ国産モデルや国内ホスト対応モデルを使う
• すべてを 1 つの API キー・1 つの請求体系の上で切り替えられる構成にしておく

最後の点が、運用上たぶんいちばん効きます。

Ofox を使えば、https://api.ofox.ai/v1 という OpenAI 互換エンドポイントを通じて、Claude Opus 4.7、Claude Sonnet 4.6、GPT-5.5、Gemini 3.1 Pro/Flash、Qwen、DeepSeek など主要なモデルを 1 本の API キーで使い分けられます。model パラメータを書き換えるだけで、チャット用は Claude、要約バッチは Gemini Flash、実験中の比較検証は別のモデル、というルーティングが組めます。請求は JPY 建て、適格請求書対応。日本市場でモデル戦略を試行錯誤するチームにとって、構成を軽く保つための土台として機能します。

「どのモデルが日本語に強いか」という問いに対する 2026 年の現実的な答えは、「複数のモデルを実際の自社タスクで試してみて、強いものを使い分ける」です。完璧な単一回答は、たぶんもう存在しません。