主要AIサービス・モデルの比較

比較表では決まらない

AIサービスの選定を始めると、まず機能比較表を作ることになります。しかし比較表で決まる部分は、実際の選定判断のごく一部です。

理由は3つあります。第一に、公開されている性能指標は自社の業務と一致しません(第1章)。第二に、料金体系が構造ごと違うため、単価の比較が総額の比較になりません。第三に、選定で本当に効くのはデータの取り扱い条件・サービス継続性・契約条項といった、比較表に載りにくい項目です。

本章では、比較表の作り方ではなく比較表に載らない項目の確認手順を中心に扱います。

主要プロバイダーの構図

個別の製品名と最新の性能を並べることは、この種の文書では有効性が短いため行いません。代わりに、構図として押さえておくべき類型を挙げます。

• 基盤モデルを自社開発している事業者 ― モデルそのものを開発し、APIとして提供する。性能の最前線はここから出ます。
• クラウド基盤事業者 ― 自社モデルに加えて、他社モデルも自社のクラウド上で提供する。既存の契約・権限管理・データ所在の枠組みに乗せられる点が利点になります。
• 業務ソフトウェア事業者 ― 既存の業務システムにAI機能を組み込んで提供する。導入の敷居が低い一方、モデルの選択肢は限られます。
• オープンウェイトのモデルを配布する主体 ― モデルの重みを公開し、利用者が自社環境で動かせる形にする。
• 国内・業界特化の事業者 ― 日本語や特定業界の文書に特化した調整、国内でのデータ保管、業界規制への対応を強みとする。

実務では、この5類型のどこから調達するかで、確認すべき項目が変わります。とくに既存のクラウド契約の枠内で使えるかは、社内の承認プロセスにかかる時間を大きく左右します。

オープンソースモデルと商用モデル

「オープンソース」と「オープンウェイト」の違い

この2語は混同されがちですが、意味が違います。

• オープンウェイト ― 学習済みのモデルの重み(パラメータ)が公開されており、自社環境で動かせる状態。学習に使ったデータや学習手順は公開されていないことが多い。
• オープンソース ― 本来は、ソースコードが公開され、利用・改変・再配布が広く認められている状態を指す語。

実際に「オープンソースのAIモデル」と紹介されるものの多くは、重みが公開されているだけで、ライセンスに利用制限が付いていることがあります。重みが手に入ることと、自由に使えることは別です。

ライセンスで確認すべき点

オープンウェイトのモデルを業務で使う場合、次の4点を必ず確認します。

1. 商用利用の可否と条件 ― 利用者数や売上規模による制限が付く場合があります。
2. 再配布と派生物の扱い ― 追加学習したモデルを配布できるか、その際の条件。
3. 出力の扱い ― モデルの出力を使って他のモデルを学習させることを禁じる条項があります。
4. 用途の制限 ― 特定分野での利用を禁じる条項が含まれる場合があります。

これらは法務の確認事項です。技術部門だけで判断せず、契約の確認プロセスに乗せてください(第17・19章)。

料金体系の理解

トークン課金

APIの標準的な形式です。入力と出力のトークン数に応じて課金され、通常は入力より出力の単価が高く設定されます。推論モデルでは内部の検討分も課金対象になるため、同じ質問でも費用が大きく変わります(第2章)。

見積もりの手順は次のとおりです。

1. 1件の処理で送る入力の長さと、返る出力の長さを実測する
2. 単価表から1件あたりの費用を計算する
3. 月間件数を掛ける
4. 再試行・エラー・検証用の実行を見込んで、1.2〜1.5倍する

4番目を忘れると、実際の請求額が見積もりを上回ります。開発中の試行、回帰テストの実行、失敗時の再試行はすべて課金対象です。

サブスクリプション課金

利用者1人あたりの月額で課金される形式です。個人の業務支援ツールとして使う場合はこちらが基本になります。

注意点は、利用の有無に関わらず課金されることです。全社導入したものの利用率が1割という状態は、費用面で最も不利な形になります。導入時に利用状況の測定方法を決めておく必要があります(第24章)。

従量課金・専有インスタンス課金

処理能力を確保する形の契約です。応答時間を安定させたい場合、大量処理を継続的に行う場合に選択されます。単価はトークン課金より有利になる場合がありますが、使わなくても費用が発生します。

費用の桁感

具体的なベンダー名や実価格は変動が早いため記載しませんが、桁の感覚は見積もりの妥当性判断に必要です。以下は構造から導かれる目安であり、実際の単価は必ず最新の料金表で確認してください(記述時点: 2026年9月)。

各行の幅そのものが1桁分あるので、検査に使うのは次の形です。提案された費用が、この桁から1桁以上離れていないかを確認する。離れている場合、想定件数の認識が違うか、含まれている作業が別にあります。どちらであっても、内訳を確認する理由になります。

なお上の表は、1件の入出力が「1件あたりの規模」の列にある量で、単価は各社の小型・汎用・検討量を増やした構成という3階層のうち中位を仮定した場合の桁です。自社が使う予定の単価表で置き換えて再計算してください。単価は変わっても、この桁の構造(用途によって2〜3桁違う)は変わりません。

API仕様・レート制限・SLA

技術的な確認事項のうち、運用開始後に問題になりやすいものを挙げます。

• レート制限 ― 単位時間あたりに送れる回数・トークン数の上限。月末の一括処理で上限に当たり、処理が完了しないという事故が起きます。想定するピーク時の処理量を先に計算してください。
• タイムアウトと再試行 ― 応答が返らない場合の待ち時間と、再試行の設計。推論モデルでは応答時間が長いため、既存システムのタイムアウト設定に当たることがあります。
• SLA(サービス品質保証) ― 稼働率の保証水準と、下回った場合の措置。多くの場合、措置は利用料の返金であり、業務停止による損害は補償されません(第17章)。
• モデルのバージョン指定 ― バージョンを固定できるか、いつまで使えるか。固定できない場合、モデル更新によって出力が変わるリスクを常に負います(第14章)。
• データの取り扱い ― 入力が学習に使われるか、保存期間、保存先の国。契約とプランで変わります(第16・19章)。

モデルカードと技術文書の読み方

提供元が公開するモデルの説明資料(モデルカード)には、選定に効く情報が含まれています。読むべき順序は次のとおりです。

1. 知識の時点 ― 学習データがいつまでのものか。これより後の情報は必ず外から渡す必要があります(第18章)。
2. 想定用途と非想定用途 ― 提供元が「この用途には使わないでください」と明記している領域があります。医療診断、法的助言、採用の自動判定などが挙げられることが多い項目です。
3. 既知の限界 ― 苦手な処理、偏りが出やすい領域。ここに自社の用途が含まれていないかを確認します。
4. 評価結果 ― どのベンチマークで測ったか。自社業務との距離を意識して読みます。
5. 安全性の対策 ― どのような有害出力の抑制が行われているか。

2番目が実務では特に重要です。提供元が非想定用途としている領域で使う設計は、事故が起きたときに説明が立ちません。

国内AI・特化型モデルの位置づけ

日本語処理や特定業界の文書に特化したモデル、および国内でのデータ保管を前提としたサービスがあります。選定理由になるのは次の場合です。

• データの国外移転が契約上または規制上できない場合
• 業界固有の用語・様式が多く、汎用モデルの精度が出ない場合
• 業界規制への対応(監査対応、証跡の保存)が要件になっている場合

逆に、汎用的な文章処理では、汎用の大規模モデルのほうが性能が高いことが多いです。「国内だから安心」「特化型だから精度が高い」という一般化はどちらも成り立ちません。要件から逆算して選ぶ必要があります。

選定の判断基準 ― 実行できる手順

ここまでを、実際に使える順序にまとめます。

1. 要件を確定する ― 用途、機密度、想定件数、許容できる応答時間、必要な精度水準。この5つが決まらないと比較できません。
2. 制約で候補を絞る ― データの所在、既存クラウド契約の枠内か、業界規制への対応。ここで候補は数個になります。
3. 自社データで試す ― 実データのサンプル(数十〜数百件)で、候補すべてに同じ処理をさせます。これが選定の中心工程です。
4. 費用を実測から計算する ― 3の実測で得たトークン数から月額を算出し、再試行分を見込みます。
5. 契約条項を確認する ― データ利用、保存期間、SLA、バージョン固定、終了時の措置。法務と共同で行います。
6. 切り替えの経路を確認しておく ― 別のモデルに移す場合の作業量を、選定時に把握しておきます(第10章)。

3が抜けた選定は、公開スコアと営業説明だけで決めたことになります。逆に3を行えば、他の項目の判断も具体的になります。