AIモデル選択ガイド：タスクに最適なモデルを選ぶ実践的方法

2026年10月8日に、OpenAIの現行モデル選択ガイドを再読しました。ページはAstra、GPT-6.1 Sol、Lunaのモデル群を案内し、利用できるツール、推論設定、利用上限がモデルや提供環境で異なることを示しています。品質・費用・待ち時間を業務の評価条件に合わせて選ぶ案内であり、ここにあるモデル名や推奨を自社の合格条件、順位、全提供環境の保証として扱いません。

AIモデル選択では、業務で許容できる回答と運用条件を先に決めます。例えば問い合わせの下書きなら「正しい文章」だけでなく、参照資料にない回答を作らないこと、権限が必要な処理を勝手に進めないこと、人が確認できることも要件です。

その上で、同じ入力を候補に渡して比較します。モデル名や一般ベンチマークは候補を探す材料ですが、自社での採用判断には自社の評価が必要です。OpenAIのモデル選択ガイドも、要求品質、費用、頻度や待ち時間を踏まえた選定を説明しています。本稿は現行ページを2026年10月8日に再確認し、固定のモデルランキングは掲載しません。

30秒で要点

• 業務の入力・出力、扱うデータ、失敗の影響を整理してから候補を絞る。
• 品質と重大な失敗を別々の合格条件にし、満たす候補の速度と総費用を比べる。
• 調整用と評価用の入力を分け、設定と結果を残す。少数の成功を将来の保証にしない。
• 採用後も監視と再評価を続け、切替・停止・元の構成へ戻す条件を決める。

1. 業務の要件を、評価できる言葉にする

「精度が高い」「速い」「安い」だけでは、候補を同じ尺度で比べられません。誰が何を入力し、出力をどこで使い、間違うと何が起きるかを一枚にまとめます。

表が収まらない場合は、横にスクロールできます

画像の読み取りが必要なら、その画像形式や機能を候補が扱えるか確認します。「言語モデルだから画像は扱えない」と一括りにはできません。対応していても、読み取り品質や入力上限、料金、データ条件は別に調べます。ツールを呼ぶ場合も、出力形式が合うことと、その処理を実行してよい権限があることを分けます。

重大な失敗は業務ごとに定義します。例えば社内下書きの言い回し違いと、他人の情報を出す回答を同じ点数の減点で処理すると、平均点が深刻な問題を隠します。医療や法務など影響の大きい用途を「上位モデルなら使える」と判断せず、利用可否、専門家の確認、契約や必要な条件を別に検討します。

2. APIと自社運用は、データ条件と担当まで比較する

商用APIは提供側のサービスを使い、自社運用はモデルと基盤を自社側で管理する構成です。オープンウェイトを取得できることから、運用が無料、商用利用が無条件、データが必ず安全とは判断できません。ライセンス、利用条件、機器、更新、監視、保管、障害対応まで確認します。

データ条件は少なくとも「学習への利用」「監視ログ」「アプリケーション状態」「利用機能と地域・課金区分」に分けます。

• OpenAIのAPIデータ制御では、明示的に共有へ同意しない限りAPIデータを学習に使わない説明と、標準の不正利用監視ログが最長30日保持される説明が別にあります。法令などによる長期保持の例外もあります。アプリケーション状態はエンドポイントごとの扱いです。承認が必要な特別な制御にも適用条件や例外があるため、全機能で一律に保存がなくなるとは扱いません。これはAPIの説明で、ChatGPTのすべてのプランへの説明ではありません。
• Gemini APIの英語追加利用規約では、無償サービスと有償サービスの利用条件が分かれます。無償側には改善利用や人による確認の説明があり、機密・個人情報の入力を避ける注意があります。有償側の改善利用不使用にも限定的な監視・記録などの説明があります。EEA・スイス・英国の扱い、AI StudioとAPIでの有償サービスの定義、追加機能の条件を確認し、「課金したからすべて保存なし」と短縮しません。

利用予定のサービス、プロジェクト、機能に該当する条件を担当者が確認し、評価入力に使ってよい情報を決めます。初期比較では架空・公開・利用許可済みの資料を使う方法を選べます。データ条件を満たさない候補は、性能の比較に進む前に見送ります。

3. 調整用と評価用の入力を分ける

Anthropicの評価基準ガイドは、タスクに合う具体的で測れる基準、複数の評価軸、評価用の入力や例外的な入力を扱っています。ここでいうgolden入力は、期待する条件を人が確認した評価用の入力です。「正解文一つと同じなら合格」だけに限定しません。

通常の依頼に加え、曖昧な依頼、資料が足りない依頼、長い入力、誤った前提、対象外の依頼などを整理します。それぞれに期待する回答、回答を控える条件、人へ戻す条件、許されない動作を記入します。個人情報を消しただけで利用許可済みと扱わず、評価資料の利用権限も確認します。

調整に使った入力だけで再評価すると、その例に合わせた改善を全体の改善と見誤る可能性があります。評価用入力を分け、プロンプトを変えた後も条件を固定して確認します。必要な件数は業務の幅、失敗の影響、観測したい誤りに合わせて決めます。全社共通で「何件あれば十分」という数は置きません。

以下は評価条件の考え方を示す架空の例です。実際のモデル測定ではありません。 未使用の評価入力20件に対し、必須条件を満たすものが19件以上、重大な失敗が0件という教材上の基準を置きます。

表が収まらない場合は、横にスクロールできます

ここでは通常の必須条件と重大な失敗を別に採点しています。Bの20件中20件という結果も、将来の100%正答や事故の不発生を意味しません。20件ではまれな失敗を十分に調べられず、入力群が偏っていれば他の業務には広げられません。業務ごとに基準と追加評価の必要性を検討します。

4. 同じ設定で測り、人の確認を残す

比較表にはモデルとバージョン、プロンプト、参照資料、ツール、推論設定、再試行の条件、入力・出力の長さ、実行日時と負荷を残します。参照資料やツール込みの比較と、モデル単独の比較を混ぜません。同じ入力でも結果が変わる可能性を踏まえ、繰り返しとその回数を記録します。

短い試行で入力や形式が合うかを確かめてから、品質の評価へ進みます。数値を一つにまとめる前に、根拠、正確さ、形式、回答を控える判断などを個別に見ます。自動チェックは形式や必須項目の確認に使い、人が意味と失敗の影響を確認します。別のAIによる採点も補助であり、その採点の誤りや偏りを確認する対象です。

待ち時間は平均だけでなく分布を見ます。例えば教材として20回の応答完了時間を短い順に並べ、nearest-rank方式のP95を使うなら、順位は ceil(0.95 × 20) = 19 で、19番目の値です。これはその20回についての定義であり、別の分位点計算法と混ぜません。少数の観測から混雑時や本番のP95を保証しないでください。検索、ツール、再試行を含むか、最初の文字までか完了までかも統一します。

5. 推論費と、業務を終えるまでの費用を分ける

品質条件を満たす候補について、API料金だけでなく確認・修正・再試行・検索・保存・基盤・保守を比較します。入力と出力の量、機能、利用量によって費用は変わるため、固定の倍率でモデルの種類を比較しません。自社運用でも、機器や担当者の時間を含めます。

次の計算はすべて架空です。プロバイダーの価格や実際の時短を示しません。 二つの合格候補をXとYとし、人の確認時間を時給換算3,600円、つまり1秒当たり1円で評価します。

表が収まらない場合は、横にスクロールできます

この前提ではAPI費用が高いYの方が、確認時間込みの換算額は小さくなります。同じ1,000件ならXは15,800円、Yは8,000円ですが、差の7,800円はこの限られた条件での換算差です。検索・保管・基盤・固定費・再試行は含めていません。時間が空くことと現金支出が減ることも別です。実際の比較では、確認時間と修正量を測り、追加費用を足し、時間の価値と現金削減を二重計上しないようにします。

業務を難しさや必要な確認で分け、候補を使い分けることもできます。ただし、振り分けの誤り、複数構成の保守、キャッシュの更新や権限確認にも負担があります。まず単純な構成を基準にし、月間利用量と高費用の原因を記録して、分岐を増やす価値を確認します。

6. 三つの業務で、選び方を具体化する

次の三つは仮想の検討例です。特定の企業やモデルで成果を観測した事例ではありません。

カスタマーサポートの下書きなら、公開FAQで回答できる範囲と、本人確認や担当者判断が必要な範囲を分けます。根拠のない回答、情報の漏れ、引き継ぐべき依頼への断言を評価し、担当者が確認して送信するところまでの時間と費用を測ります。自然な会話だけで採用を決めません。

コンテンツ編集なら、表記、読みやすさ、事実と出典、引用や素材の利用条件を評価します。短い修正と長文の構成変更を同じ作業として平均せず、編集者の修正量と確認時間を記録します。公開の責任をモデルへ移さず、最終確認を残します。

データ分析の補助なら、計算やコードの再現性、欠測や対象外データへの扱い、結論の根拠を確かめます。文章がもっともらしくても、データと計算に照らして検証します。実データへの接続権限や変更権限を制限し、モデルの説明を因果の証明や分析結果そのものと扱いません。

7. 限定導入から、監視と切替へ進む

最初は対象業務と利用者を限定し、確認を受けた回答、失敗の内容、確認時間、待ち時間、費用を記録します。中断した処理の再開、重複実行の防止、障害時の担当者への移行、ログの保存範囲も試します。ログ自体に保存してはいけない情報が入らないよう、記録する項目を決めます。

モデル、プロンプト、参照資料、ツール、データ条件が変わった時は、同じ評価入力と必要な追加入力で再確認します。定期確認の時期に加え、重大な誤り、費用の超過、待ち時間の悪化で停止・切替・元の構成へ戻す条件を置きます。「選んだモデルを使い続ける」ことを目的にしません。

提供予定も運用の条件です。例えばOpenAIの廃止予定案内は、Evals platformについて2026年10月31日の読み取り専用化、11月30日の停止を公表しています。2026年10月4日の確認時点では予定であり、既に停止したとは扱いません。新たな評価基盤にこの廃止予定製品を選ぶ前提は置かず、入力、採点条件、結果、構成を移せる形で保存する方針を検討します。

選定記録には、採用理由だけでなく、見送った条件、未確認の項目、責任者、再評価のきっかけ、戻す構成を残します。品質、データ、運用の条件を満たす範囲で、速度と費用を調整していく手順です。

関連する検討はAIの得意・不得意、AIの費用最適化、First byteのAIへの考え方から確認できます。