業務で使うAIモデル（GPT・Claudeなど）の選び方｜比べるときに確認したい観点

AIアプリを開発するときや、社内でAIを使う仕組みを整えるときに、どのAIモデルを使うかという判断が出てきます。AIモデルとは、文章の作成や要約、質問への回答などを行うAIの中心となる部分のことです。文章を扱うAIモデルは、LLM（大規模言語モデル）とも呼ばれます。

代表的なものに、OpenAIのGPTシリーズ、AnthropicのClaude、GoogleのGeminiなどがあります。それぞれの提供元から新しいモデルが出ることがあり、機能や料金、提供の条件も一定ではありません。導入時は、各社の公式情報を確認してください。

この記事では、特定のモデルを勧めたり、性能や価格を比べたりはしません。モデルの名前や評価は短い期間で入れ替わるためです。代わりに、業務で使うAIモデルを選ぶときに確認したい観点を整理します。

用途から考える

AIモデルを選ぶときは、まずAIに何をさせたいかをはっきりさせます。長い資料の要約、問い合わせの分類、顧客への回答文の作成、プログラムのコードの作成など、作業によって求められる性質は異なるからです。

たとえば、大量の問い合わせを決まった区分に振り分ける作業であれば、応答の速さや費用を重視したほうがよいかもしれません。一方で、複雑な条件を読み取って文章にまとめる作業では、出力の品質を優先したい場面もあるでしょう。

一つのアプリの中でも、作業ごとに別のモデルを使い分ける設計は珍しくありません。最初に用途を書き出しておくと、どの観点を重視すべきかが見えてきます。

比べるときの観点

AIモデルを比べるときに確認したい観点を、表にまとめました。具体的な条件はモデルや契約の形によって異なるため、それぞれ公式情報で確かめる必要があります。

以下では、特に判断が分かれやすい4つの観点を詳しく見ていきましょう。

自社の業務の例で品質を確かめる

AIモデルの性能については、提供元や第三者が公開している評価の結果があります。ただ、こうした評価は一般的な問題を使ったものが多く、自社の業務でうまく動くかどうかは別に確かめなければなりません。

確かめるには、実際の業務に近い入力の例と、期待する出力をいくつか用意します。よくある例だけでなく、判断が難しい例や、答えてはいけない例も含めておくと差が見えやすくなるでしょう。

同じ例を候補のモデルに入力し、結果を並べて比べてみてください。必要な情報が含まれているか、資料にないことを断定していないか、指示した形式を守っているかといった観点を先に決めておけば、評価がぶれにくくなります。

費用と応答の速さを見積もる

AIモデルの利用料は、入力と出力の文章の量に応じてかかる仕組みが多く見られます。モデルによって料金の設定や応答の速さは異なり、料金が改定されることもある点に注意してください。

そのため、比べるときは一回あたりの料金だけで判断せず、想定する利用量で月々の費用を見積もることが大切です。利用者の人数、一日あたりの利用回数、一回に入力する文章の量を仮に置いて計算してみてください。

品質の高いモデルを使っても、費用が予算に合わなかったり、応答に時間がかかりすぎて使われなかったりすれば意味がありません。品質と費用と速さのつり合いを、用途ごとに考える必要があります。複数のモデルの費用を管理する方法は、複数のAIモデルの費用を管理する方法で説明しています。

データの扱いの条件を確認する

業務でAIモデルを使えば、社内の資料や顧客の情報を入力する場面も出てくるでしょう。入力した内容が提供元でどのように保存されるのか、モデルの学習に使われるのかといった条件は、サービスや契約の形によって違いがあります。

同じ提供元のモデルでも、個人向けのサービスと企業向けの契約、開発者向けの接続サービスでは条件が異なる場合があります。社内の情報管理の決まりに照らして問題がないかを、公式の利用規約や資料で確認してください。必要に応じて、社内の情報システム担当や専門家にも相談しましょう。

切り替えやすい構成にしておく

AIモデルは、提供元の方針で新しい版が出たり、古い版の提供が終わったりすることがあります。特定のモデルに合わせ込んだ作りにしていると、切り替えのたびに大きな修正が必要になりかねません。

アプリを開発する場合は、使うモデルを設定で変えられる構成にしておくと、将来の切り替えに対応しやすくなります。評価用の例を残しておけば、新しいモデルに切り替える前に同じ例で品質を確かめることも可能です。公開後の対応については、AIアプリは作って終わりではない：保守運用で発生することもご覧ください。

問い合わせ分類で比較用の問題を作る例

架空の機器販売会社が、受信した問い合わせを「仕様確認」「納期確認」「故障相談」「担当者による確認」に分類するとします。AIの役割は振り分けで、修理の手順や納期を回答することではありません。このように、出力の使い道を先に決めると評価対象が狭まります。

比較用の例には、典型的な問い合わせに加えて、複数の相談が混ざる場合や、情報が足りない場合も入れます。顧客の実データを使う前に利用条件を確認し、最初は架空の内容で準備できます。

複数分類を許可する設計なら、四行目の期待結果も変わります。モデルの出力を見てから都合よく正解を変えず、業務上どう振り分けたいかを先に決めてください。担当者の間で判断が割れる例は、モデル比較を始める前に整理する対象です。

同じ条件で比較し、業務ごとの調整は別に記録する

最初は、同じ指示文と入力例を候補モデルへ渡します。出力する項目、余計な説明を許すか、不明な場合の扱いもそろえます。比較した日付、モデルの識別子、設定、参照資料の版を記録しておくと、後から結果の違いを調べられます。

一度の出力で決めず、判断が揺れやすい例は複数回試します。すべての入力を大量に実行する必要はありませんが、同じ入力に対して分類が変わるなら、そのこと自体が運用上の確認点です。試した件数と回数も、評価結果と一緒に残してください。

候補ごとに指示を調整する場合は、共通条件での結果と調整後の結果を分けます。調整に使った例だけで最終評価すると、その例に合う書き方を選んだ効果が混ざります。一部の例は最後の確認用として残し、未使用の入力でも期待する動作が続くかを確かめます。

合計点に埋もれさせない不合格条件を決める

分類が正しい割合に加えて、必須の出力項目が欠けた件数、担当者へ戻すべき入力を断定した件数を確認します。文章が自然でも、後続システムへ渡せない形式なら、その業務では修正が必要です。

重大な誤りは、平均点と分けて扱います。たとえば故障相談を通常の仕様質問へ回して対応が遅れることが大きな問題なら、その条件を重点的に確認します。何を重大とするかは、開発担当者だけで決めず、実際に対応する部署とそろえておきます。

どの候補も条件を満たさない場合、すぐに高価なモデルへ変えるだけでは解決しないことがあります。分類の定義が重なっていないか、入力に必要な情報が含まれるか、迷う例を人へ戻せるかを見直します。業務の分け方を変えてから、改めて候補を比較できます。

待ち時間と費用は、利用者の作業が終わるまでで見る

AIの応答時間だけでなく、資料検索や出力の検査、必要な再試行も含めて計測します。最初の一文字が早く表示されても、分類結果が確定するまで長く待つなら、後続の業務は始められません。利用者が何を待っているかに合わせて、時間の開始と終了を決めます。

費用も、一回の呼び出し料金に加えて、完了までに何回使ったかを確認します。安価でも修正が多い候補と、利用料は高いが手直しが少ない候補を、同じ業務件数で比べます。人の確認時間を金額へ換算する場合は、仮定の単価と計算範囲を明記してください。

採用時の判断を切り替え時にも使える形で残す

採用するモデルを決めたら、満たした条件、残る弱点、人へ戻す条件、対象外の業務を記録します。評価用の入力と期待結果も保存し、モデルや設定を変える際に再利用します。機密情報を含む場合は、評価資料の閲覧範囲も制限します。

モデル名を設定で変えられても、入力形式や出力の読み取り方がそのまま使えるとは限りません。切り替え前にはアプリ側の接続と処理も確認します。品質、データの扱い、業務への接続を確認できて初めて、利用範囲を広げる判断に進めます。

まとめ

業務で使うAIモデルは、知名度や公開されている評価だけで決めず、用途を書き出したうえで、自社の業務の例で試して選ぶことが大切です。品質に加えて、費用と応答の速さ、データの扱いの条件、提供の継続性もあわせて確認してください。一つのモデルに固定せず、作業ごとの使い分けや将来の切り替えができる構成にしておくと、変化に対応しやすくなります。

e-Grantsでは、RAGやLLMを使ったAIアプリケーションについて、課題の整理から設計・開発、公開後の保守運用まで対応しています。用途に合ったモデルの選び方も含めて相談したい方は、AIアプリケーション受託開発のページをご覧ください。