AI開発の提案書を受け取った発注担当者の多くが、「GPT-5.5を採用」「Claude Opus 4.7を併用」といった記載を前にして手が止まります。モデル名は読めても、なぜそのモデルが自社の業務に最適なのか、根拠を社内で説明できないという状況です。
そのまま承認印を押すのは不安が残りますが、かといってベンチマークスコアや推論アーキテクチャまで踏み込む時間も知識もありません。発注者として「最低限ここまでは理解しておきたい」というラインがどこにあるのか、はっきり言語化されている情報は意外と少ないのが現状です。
実は、モデル選定の技術詳細まで踏み込む必要はありません。発注者の責任は「自社の業務要件とモデル特性が噛み合っているか」「コストやリスクの想定が妥当か」を質問し、開発会社の判断を検証することです。エンジニアになる必要はなく、確認すべきポイントを知っていれば十分です。
本記事では、AI開発を外注する発注者がGPT・Claude・Gemini・Llamaを比較するための5つの判断軸と、開発会社の提案書を承認する前のチェックリストを整理します。LLMそのものの基礎から押さえたい方はLLMとは何か発注者向けに解説も併せてご覧ください。
はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ
この資料でわかること
AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。
こんな方におすすめです
- AI導入を検討しているが、何から始めればよいか分からない
- ベンダーの選び方や費用感がつかめず、判断できない
- 社内でAI導入の稟議を通すための資料が必要
入力いただいたメールアドレスにPDFをお送りします。
なぜ発注者がLLMモデルを理解する必要があるのか
「モデル選定は開発会社の仕事」と考えがちですが、これは半分正解で半分間違いです。技術評価は開発会社の役割ですが、業務要件との適合性とコスト責任の最終判断は発注者側にあります。判断軸を持たないまま承認すると、後から発生する想定外コスト・モデル廃止・要件不一致といった問題に対応できません。
モデル選定の責任はベンダーと発注者のどちらにあるか
開発会社は「技術的な評価・推奨」を担い、発注者は「業務要件との適合性確認・最終承認」を担います。具体的には、開発会社がベンチマーク評価・実装難易度・API仕様を整理し、発注者は「業務課題が解決するか」「予算と合うか」「セキュリティ要件を満たすか」を確認する形です。
発注者が「お任せします」と判断を委ねると、後で「そう聞いていない」というすれ違いが発生しやすくなります。最低限の判断軸を持ち、対話を成立させることが発注者の責任です。
最低限の判断軸を持つことで防げる3つの失敗
判断軸を持たないまま承認すると、以下のような失敗が典型的に発生します。
- コスト膨張: 想定よりトラフィックが増え、API課金が予算を大きく超える
- モデル廃止リスク: 契約後に採用モデルが提供終了になり、再開発コストが発生する
- 要件不一致: 長文処理が必要な業務に短文向けモデルを採用してしまう
これらは事前に「コスト試算」「廃止時の切替条項」「業務要件とのフィット確認」を提案書段階で確認していれば、ほぼ防げます。
技術詳細を深掘りせず承認できるラインの引き方
発注者が踏み込むべきライン・踏み込まなくてよいラインを整理すると以下のようになります。
- 踏み込む: 採用モデル名とバージョンが提案書に明記されているか
- 踏み込む: 選定理由が業務要件と紐づいて説明されているか（「最新だから」「人気だから」だけでは不十分）
- 踏み込む: 月間想定コストと根拠（想定トークン数・単価）が示されているか
- 踏み込む: モデル廃止・バージョンアップ時の対応方針が記載されているか
- 踏み込まない: ベンチマークスコアの細部や推論アーキテクチャの議論
- 踏み込まない: モデルのパラメータ数・学習データの内訳
「業務に紐づく説明」と「金額・リスクの根拠」が明示されていれば承認可能、技術的な内部構造の議論は開発会社に任せてよい、というのが実務的な引き方です。
主要LLMモデルの業務観点比較（GPT・Claude・Gemini・Llama）
2026年5月時点の主要LLMを、業務観点（得意領域・コスト水準・利用シーン）に絞って整理します。性能ベンチマークの詳細は省き、提案書を読む際に必要な「業務でどう違うか」のみに焦点を当てます。モデルは半年〜1年単位で世代交代するため、執筆時点の情報として参照してください。
モデル | 提供元 | 得意領域 | 入力単価（参考） | 主な利用シーン |
|---|---|---|---|---|
GPT-5.5 | OpenAI | 汎用性・エージェント業務 | $5/1Mトークン | 幅広い業務の標準的選択肢 |
Claude Opus 4.7 | Anthropic | 長文処理・コード生成 | $5/1Mトークン | 契約書解析・開発支援 |
Gemini 3.1 Pro | マルチモーダル・コスト効率 | $2/1Mトークン | Workspace連携・大量処理 | |
Llama 4系 | Meta（OSS） | 自社環境への展開 | サーバー費用のみ | 機密データ・オンプレ要件 |
※ 単価は2026年5月時点の概算（出典: 主要LLMプロバイダーのAPI料金表 - Qualiteg）。出力単価は入力の数倍となるのが一般的で、実コストは利用パターンで大きく変動します。
GPT-5.5（OpenAI）── 汎用性・エコシステムの強み
GPT-5.5は2026年4月リリースのOpenAIフラッグシップで、最大の強みは「汎用性」と「エコシステムの広さ」です。エージェント機能（複数ステップの自動処理）やcomputer use（画面操作）にも強く、業務自動化との相性がよい点が特徴です。「特に強い得意領域を求めない」「複数業務で汎用的に使いたい」場合の第一候補になります。
Claude Opus 4.7（Anthropic）── 長文処理・コーディング・低ハルシネーション
Claude Opus 4.7は2026年4月リリースで、200K以上のコンテキスト長（一度に扱える文章量）を持ちます。コード生成のベンチマークで高評価を得ており、ハルシネーション（事実誤認）の発生率が低い点も評価されています。「契約書・仕様書など長文を一度に解析させたい」「コード生成や開発支援が主目的」「医療・法務など事実誤認リスクが大きい業務」に向きます。
Gemini 3.1 Pro（Google）── マルチモーダル・Workspace連携・コスト優位
Gemini 3.1 ProはGoogleのフラッグシップで、画像・PDF・音声を統合処理するマルチモーダル能力と、Google Workspace（Gmail・Drive・Docs）連携が強みです。トークン単価が3強の中で最も低く、1Mトークン規模の長文処理にも対応します。「画像やPDFを含む処理が中心」「Workspaceが業務基盤」「大量トラフィックでコスト最適化を重視」というケースで第一候補です。
Llama系（Meta、オープンソース）── 自社環境への展開オプション
LlamaはMetaのオープンソースモデルで、APIではなく自社サーバーにデプロイして使う選択肢です。クラウドAPIを使えない、または使いたくない業務（医療・金融・防衛など機密性が極めて高い領域）で採用されます。運用には専門知識とインフラ投資が必要で、開発会社側のスキル要件と発注者側の運用負荷が大きく変わる点を理解しておきましょう。
発注者が押さえるべき5つの判断軸
ここからが本記事の核となる、提案書を承認/差し戻し判断する5つの軸です。各軸ごとに「確認すること」と「開発会社への質問例」をセットで示します。
判断軸1: 用途とのフィット感
自社の業務要件と採用モデルの得意領域が一致しているかを確認します。「長文契約書の要約にGPT-5.5」「マルチモーダル処理が中心なのにClaude」といった選定がされていないかチェックします。
開発会社への質問例:
- なぜこのモデルを選んだのか、業務要件のどの部分とフィットするか教えてください
- 他のモデル（Claude・Gemini等）と比較して、決め手は何ですか
- 業務要件の中で、このモデルが不得意な領域はありますか
判断軸2: コスト構造
月間想定コストとその根拠が示されているかです。LLMの課金は「入力トークン数 × 単価 + 出力トークン数 × 単価」で計算され、想定トラフィックが甘いと実運用で予算が数倍に膨らむことがあります。AI開発全体の費用構造はAI開発の費用相場も参考になりますが、モデル選定では特に「単価変動」と「想定外利用」のリスクを確認します。
開発会社への質問例:
- 月間想定コストの算出根拠（1リクエストあたりの想定トークン数・月間リクエスト数）を教えてください
- 想定の2倍のトラフィックが来た場合、コストはどう変動しますか
- コストが予算を超えそうになった場合、どのようなアラートや制御の仕組みがありますか
判断軸3: セキュリティ・データ取扱い
業務データをLLMに送る以上、セキュリティ要件の確認は避けられません。特に「学習に利用されないか」「データ保管地域」「契約上の責任範囲」の3点は必須です。
開発会社への質問例:
- このAPIに送信したデータは、学習用途に利用されますか
- データの保管地域はどこですか（国内サーバーが必要な場合は明示）
- ログ・履歴の保持期間はどのくらいで、削除はどう行いますか
判断軸4: レスポンス速度・スループット
業務利用では「精度」だけでなく「速度」も重要です。リアルタイム応答では2〜3秒の遅延が致命的になり、夜間バッチなら多少遅くても問題ない、と業務シーンで要件が変わります。
開発会社への質問例:
- 想定業務シーンでの実測レスポンス速度はどのくらいですか
- ピーク時の同時アクセス数に耐えられるスループットですか
- 速度を優先する場合、軽量モデル（mini系・Flash系）への切替は可能ですか
判断軸5: モデル廃止・バージョンアップ対応
最後に、最も見落とされやすい軸です。LLMモデルは1〜2年単位で世代交代し、旧モデルは段階的に提供終了します。実際にOpenAIは2026年2月にGPT-4oをChatGPTから引退させており、契約段階でこのリスクへの対応方針が明示されているかを確認します。詳細はのちほど整理します。
開発会社への質問例:
- 採用モデルが提供終了になった場合、どのモデルへの移行を想定していますか
- モデル切替時の再評価・再開発コストは見積もりに含まれていますか
- 廃止のアナウンスはどのように検知し、発注者にどう共有されますか
用途別のモデル選定パターン
業務シーンごとの第一候補と、業務要件を開発会社に伝える際のコツを整理します。
文書要約・カスタマーサポート対応
社内文書の要約や問い合わせの一次返信ではGPT-5.5またはGemini Flash系の軽量モデルが候補です。長文契約書の解析中心ならClaude Opus 4.7が有力です。開発会社への伝え方の例: 「1リクエスト平均5,000トークン、月間1万件、応答5秒以内、コスト優先」のように具体化すると、適切な提案が出やすくなります。
コード生成・開発支援
開発者向けコード生成ツールや社内ツール自動生成では、Claude Opus 4.7が第一候補になることが多いです。GPT-5.5も汎用的に使えますが、長文コードの一貫した修正やリファクタリングではClaude系の評価が高い傾向です。「対象言語・フレームワーク」「コード長」「品質要件（テストパス率など）」を伝えると、複数モデルでの比較検証が依頼しやすくなります。
マルチモーダル（画像・PDF・音声）処理
請求書OCR、画像からの情報抽出、音声議事録の要約などはGemini 3.1 Proが第一候補です。GPT-5.5も画像に対応しますが、コスト効率と長コンテキストを組み合わせるとGemini優位の場面が多くなります。「メディア形式」「ファイル平均サイズ」「精度要件」を伝えましょう。
社内データ検索・RAG
社内ナレッジ検索・FAQ自動応答などのRAG（検索拡張生成、社内データを検索したうえでLLMに回答させる仕組み）では、長コンテキストのClaude Opus 4.7またはGemini 3.1 Proが優位です。「対象データ総量と更新頻度」「アクセス権限制御」「想定検索パターン」を伝えてください。RAGはモデル以上に前処理品質が結果を左右するため、開発会社の前処理プロセスも質問対象に加えましょう。
はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ
この資料でわかること
AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。
こんな方におすすめです
- AI導入を検討しているが、何から始めればよいか分からない
- ベンダーの選び方や費用感がつかめず、判断できない
- 社内でAI導入の稟議を通すための資料が必要
入力いただいたメールアドレスにPDFをお送りします。
クラウドAPI vs オープンソース（Llama等）の選択
提案書で「Llamaを採用」「自社環境にデプロイ」が提示された際、何を確認すればよいかを整理します。なお、より軽量な選択肢としてSLM（小規模言語モデル）とは何かも別記事で解説しており、用途次第ではこちらも候補に入ります。
クラウドAPIが向く業務シナリオ
クラウドAPIは「初期投資を抑えたい」「最新モデルを継続的に使いたい」「業務開始までの期間を短くしたい」場合に向きます。インフラ管理は提供元（OpenAI・Anthropic・Google）が担うため、責任範囲はAPIの利用設計に限定されます。多くの業務システムではこちらが標準的な選択肢です。
オープンソースが向く業務シナリオ
オープンソースモデルは「データを外部に出せない厳格な規制要件がある」「特定業務向けにカスタマイズしたい」「長期的にAPI課金を回避したい」場合に向きます。医療・金融・防衛分野や、機密性の高い社内データを扱う場面で検討されます。
運用負荷・コスト・カスタマイズ性の比較
両者の違いを発注者目線で整理すると以下の通りです。
観点 | クラウドAPI | オープンソース（Llama等） |
|---|---|---|
初期投資 | 小（API契約のみ） | 大（GPU等インフラ） |
月額コスト構造 | 従量課金 | サーバー固定費中心 |
運用負荷 | 低（提供元任せ） | 高（自社で更新・監視） |
データの外部送信 | あり（API経由） | なし（自社内で完結） |
カスタマイズ性 | 限定的 | 高い（ファインチューニング可） |
モデル更新 | 自動（廃止リスクあり） | 自社判断（旧モデル維持可能） |
オープンソース採用時は、サーバーコスト・運用人員・モデル更新の自社判断責任を発注者側で負います。「機密データだから」という単一理由ではなく、運用体制まで含めて判断することが重要です。
モデル廃止・バージョンアップへの対応
LLMモデルは1〜2年単位で新世代が登場し、旧モデルは段階的に廃止されます。発注者が承認段階で必ず想定しておくべきリスクで、競合記事ではあまり触れられない論点です。
モデルライフサイクルの基礎理解
主要モデルの提供元は、新モデルリリースから旧モデル廃止までのタイムラインを公表しています。OpenAIは2026年2月にGPT-4o・GPT-4.1・GPT-4.1 mini・o4-miniをChatGPTから引退させ、API提供も段階的に終了する方針です（出典: Retiring GPT-4o, GPT-4.1, GPT-4.1 mini, and OpenAI o4-mini in ChatGPT - OpenAI）。一般的な廃止予告期間は3〜12ヶ月程度ですが、2週間程度の短い予告で廃止された事例も報告されています。
発注者として理解すべきは、「採用モデルが半年後・1年後にも同じように使える保証はない」という事実です。新モデルへの移行コスト、業務影響、移行期間中の二重運用を契約段階で織り込んでおく必要があります。
契約時に決めておくべきモデル切替条項
提案書・契約書に以下が含まれているかを確認しましょう。
- 採用モデルが廃止された場合の代替モデルへの移行手順
- 移行時の検証範囲（出力品質の再評価・テストケースの再実行）
- 移行作業の費用負担（追加費用の有無と範囲）
- 廃止アナウンスを検知する仕組みと、発注者への共有方法
- 移行期間中の業務影響を最小化する戦略（並行運用・段階移行など）
これらが含まれていない場合は「モデル廃止時の対応を明示してほしい」とリクエストしてください。明示できない開発会社は、リスク管理の観点で再検討が必要です。
発注後に発注者が行うべきモニタリング
契約後も、発注者として最低限のモニタリングは行いましょう。提供元の公式アナウンス（OpenAIのモデル廃止ページ、Anthropicの発表、Googleのリリースノート）を四半期に1度確認する、開発会社から月次でモデル提供状況のレポートを受ける、といった運用が現実的です。アナウンスから対応着手までの時間ロスを最小化することが、実害を防ぐ鍵になります。
開発会社の提案書チェックリスト
ここまでの判断軸を踏まえ、提案書を受け取った発注者が承認前に確認するチェックリストを整理します。Noが3つ以上ある場合は、追加質問や提案差し戻しを検討してください。
提案書で必ず確認すべき5項目
- 採用モデル名とバージョンが具体的に明記されている（「GPTを採用」ではなく「GPT-5.5を採用」）
- 選定理由が業務要件と紐づいて説明されている（「最新だから」「人気だから」のみは不可）
- 月間想定コストと算出根拠（想定トークン数・想定リクエスト数）が示されている
- データ取扱い方針（学習利用の可否・保管地域・ログ保持期間）が明記されている
- モデル廃止・バージョンアップ時の対応方針が記載されている
開発会社への質問テンプレート
不足がある場合、以下の質問テンプレートをそのまま開発会社に投げてみてください。
- 採用モデル名とバージョンを明記してください。半年〜1年以内の廃止可能性をどう見ていますか
- このモデルを選定した理由を、業務要件のどこにフィットするかも含めて教えてください。他モデルとの比較検討結果も知りたいです
- 月間想定コストの算出根拠と、想定の2倍トラフィック時のコスト変動を示してください
- データの学習利用可否・保管地域・ログ保持期間を契約書面に明記できますか
- モデル廃止時の代替モデル移行手順と、移行時の費用負担範囲を提案書に追記してください
これらに明確に答えられる開発会社は、リスクを織り込んだ提案ができるパートナーです。回答が曖昧な場合、契約後にも同じ曖昧さが繰り返される可能性があるため慎重な判断が必要です。
まとめ｜発注者の判断軸を整える3ステップ
LLMモデルを発注者として承認する準備を、3ステップに整理します。
1つ目は「主要モデルの業務観点での違いを社内で説明できる状態にする」ことです。GPT-5.5・Claude Opus 4.7・Gemini 3.1 Pro・Llama系の得意領域とコスト水準を、技術詳細抜きで自分の言葉で説明できれば、社内承認の場で根拠を示せます。
2つ目は「開発会社への質問リストを準備する」ことです。本記事の5つの判断軸に対応する質問テンプレートを使い、提案書の曖昧な部分を埋めていきましょう。質問できる発注者は、開発会社にとってもリスクを共有できる良いパートナーです。
3つ目は「モデル廃止・バージョンアップへの備えを契約段階で確認する」ことです。半年〜1年後の世代交代を見越し、移行手順・費用負担・モニタリング体制を提案書に明記してもらいましょう。
モデル選定の判断軸を理解したうえで、AI開発全体の発注プロセス（要件定義・体制づくり・運用開始後の評価）には別の準備が必要です。発注の具体的な確認ポイントはLLMシステム発注ガイドで詳しく整理しています。
また、AI開発を発注する前段階として「自社で AI が成果を出せる体制か」を確認したい方には、AI導入を7ステップで整理した無料ガイドも参考になります。モデル選定の前提となる業務整理・推進体制・効果測定の考え方をまとめており、本記事の判断軸を社内で適用する際の土台として活用できます。
はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ
この資料でわかること
AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。
こんな方におすすめです
- AI導入を検討しているが、何から始めればよいか分からない
- ベンダーの選び方や費用感がつかめず、判断できない
- 社内でAI導入の稟議を通すための資料が必要
入力いただいたメールアドレスにPDFをお送りします。
