AI を業務システムに組み込むとき、最初に送られてくる資料はたいてい性能比較の表です。ベンチマーク（共通の問題集を解かせて点数を付けた評価）の数値が並び、どれが何点上か、応答がどれだけ速いかが書かれています。ところが、その表を見比べて選んだモデルが、半年後の運用で問題になることは珍しくありません。理由は単純で、性能表に載っていない部分が、業務システムでは先に効いてくるからです。
この記事では、製品名や型番の優劣ではなく、どのモデルを検討するときでも共通して確かめるべき3つの軸を整理します。料金がどう発生するか、止まったときに代わりがあるか、入力したデータがどう扱われるか。この3点を先に並べると、性能表の読み方そのものが変わります。
性能表が選定の決め手になりにくい理由
ベンチマークの数値は、比較のための共通条件で測られたものです。自社の業務文書、自社の言い回し、自社の例外処理で測った数値ではありません。つまり「自社の仕事で何点取れるか」は、公開された表からは分からないというのが出発点です。
加えて、モデルの性能差は時間とともに縮んだり入れ替わったりします。選定時点で上位だったものが、数か月後も上位である保証はありません。一方で、料金の課金方式、提供が止まったときの代替手段、データの取り扱い条件は、契約と設計に紐づくため、後から変えるコストが大きい項目です。変えにくいものから先に決める、という順序が合理的です。
性能を無視するという話ではありません。性能は自社データでの小さな試験で確かめるものであって、表を眺めて決めるものではない、という切り分けです。その試験の進め方については、AI の PoC が本番に乗るかどうかは、着手前に決める 3 つのことで ほぼ決まるで扱った観点が参考になります。
軸1：料金は「単価」ではなく「出方」で比べる
AI モデルの料金は、多くの場合トークン（文章を細かく区切った単位。おおまかには文字数に比例します）に応じた従量課金です。資料には単価が載りますが、実際の請求額を決めるのは単価ではなく、呼び出し回数と1回あたりに渡す文章量です。
確かめるべきは、次のような「出方」の部分です。
- 入力と出力で単価が分かれているか。長い資料を読ませる用途では入力側が支配的になります
- 同じ内容を繰り返し送る場合に、再利用の仕組み（キャッシュ）があるか。あるなら条件は何か
- 最低利用料、月額の基本料金、同時実行数の上限があるか
- 画像、音声、長文などを扱うときに単価体系が変わるか
- 請求の明細が、どの機能で使ったか分かる粒度で出るか
最後の項目は見落とされがちですが、運用に入ってから効きます。明細が「全社で1行」しか出ないと、コストが膨らんだときにどの機能が原因か追えません。設計段階で呼び出し元を識別できる形にしておく必要があります。料金設計そのものの考え方はLLMの料金は「安いモデルに替える」では下がらない — 呼び出し回数と文脈量から設計するコスト削減で詳しく整理しています。
軸2：止まったときの代わりを先に決める
AI モデルは、提供側の都合で仕様が変わったり、古い版の提供が終了したりします。障害で一時的に応答しないこともあります。業務システムに組み込む以上、止まった日に何が起きるかを、導入前に決めておく必要があります。
確認の観点を整理すると次のようになります。
| 確認項目 | 見るポイント |
|---|---|
| 提供終了の予告 | 古い版をいつまで使えるか。予告から終了までの期間が示されているか |
| 版の固定 | 「最新版を自動で使う」指定と「特定の版を指定する」指定を選べるか |
| 切り替えの手間 | 別のモデルに差し替えるとき、どこまで書き換えが必要か |
| 停止時の振る舞い | 応答がないとき、業務を止めるか、人手に回すか、後で再実行するか |
| 稼働実績の公開 | 障害情報や稼働状況が公開されているか |
特に重要なのは版を固定できるかどうかです。自動で最新版に切り替わる設定は便利に見えますが、ある朝いきなり出力の傾向が変わり、業務が合わなくなるという事態を招きます。業務システムでは版を固定し、切り替えは自社のタイミングで行うのが原則です。
切り替えの手間を下げる実装上の工夫としては、モデルを呼び出す処理を1か所にまとめ、アプリ側からは「AI に聞く」という共通の窓口だけを使う構造にしておくことが挙げられます。モデルごとの細かい作法が業務ロジックの中に散らばっていると、差し替えが大工事になります。この「壊れる前提で設計する」という考え方はAI機能の保守費は「モデルが変わる日」を先に見積もるでも触れています。
軸3：データの扱いは、設定ではなく契約で確かめる
入力した業務データがどう扱われるかは、画面の設定項目だけを見ても分かりません。利用規約、データ処理に関する付属文書、提供事業者が公開しているセキュリティ説明を併せて確認する必要があります。
最低限、次の点は文書で確認できる形にしておくことをおすすめします。
- 入力したデータがモデルの学習に使われるか。使われない設定がある場合、その適用条件
- データが保存される期間と、保存される目的（不正利用の検知など）
- 処理が行われる国または地域を選べるか
- 再委託先がある場合の範囲
- 第三者認証の取得状況
日本国内で個人情報を扱う場合は個人情報保護法の枠組みが関わります。国外の事業者に処理を委ねる場合、外国にある第三者への提供として扱われる可能性があり、本人への情報提供など追加の対応が必要になることがあります。また、国内では総務省と経済産業省によるAI事業者ガイドラインが公表されており、事業者が自主的に点検する際の参照点になります。具体的な適用の判断は、自社の取り扱うデータの内容に応じて専門家に確認してください。
なお、そもそも外部のクラウドに出せないデータがある場合は、モデル選定の前に設置形態の判断が必要です。この点はクラウドAIか、社内設置か — 中小企業が迷わず決めるための3つの判断軸で整理しています。
3つの軸を1枚にまとめて比較する
実際の検討では、候補ごとに次のような欄を埋めていくと、性能表とは違う差が見えてきます。たとえば次のような様式です。
| 軸 | 記入する内容 | 埋まらないときの扱い |
|---|---|---|
| 料金の出方 | 課金単位、明細の粒度、月額の下限 | 想定業務量で試算を依頼する |
| 代わりの確保 | 版の固定可否、提供終了の予告期間、切り替え先の候補 | 切り替え先が無いなら用途を限定する |
| データの扱い | 学習利用の有無、保存期間、処理地域 | 文書で示せないものは採用しない |
| 自社データでの精度 | 実際の業務サンプルでの試験結果 | 試験できないなら判断を保留する |
ポイントは、「埋まらない欄をどう扱うか」まで先に決めておくことです。情報が出てこない項目を空欄のまま進めると、運用開始後に同じ問題が形を変えて戻ってきます。
まとめ
AI モデルの選定で先に比べるべきは、性能表の数値ではなく、次の3点です。
- 料金の出方 — 単価ではなく、呼び出し回数と文章量、そして明細の粒度
- 止まったときの代わり — 版を固定できるか、切り替えの手間はどれだけか
- データの扱い — 設定画面ではなく、契約文書で確認できるか
この3つは後から変えにくく、変えようとすると設計のやり直しになります。一方、性能は自社データでの小さな試験で測ればよく、モデルの入れ替えが容易な構造にしておけば、将来の選択肢も残ります。変えにくいものから決め、変えやすいものは後で測る。この順序が、業務システムに AI を組み込むときの実務的な進め方です。
弊社では、こうした判断軸の整理から実装、運用設計までを一貫してご支援しています。候補の絞り込みでお困りの際はご相談ください。