生成AIのAPI選び｜4つの運用条件

社内向けの生成AI機能を試作すると、最初は驚くほど順調に動く。数件の文書を要約し、問い合わせにも自然に答える。ところが本番を想定した途端、別の問題が顔を出す。

「入力したデータはどこに残るのか」

「月末にリクエストが集中しても動くのか」

「新モデルへ切り替えたら、回答品質は変わらないか」

これはモデルの賢さだけでは解けない。生成AIのAPIを業務システムへ組み込むなら、選定基準をモデル名から運用条件へ移す必要がある。

判断軸は4つだ。

1. データ保持と処理場所
2. 可用性と割当上限
3. 応答速度と総費用
4. モデル更新と切替可能性

APIの比較表を開く前に、この4条件を自社の要求へ変換する。そうすると、必要以上に高価な構成も、安いが本番で止まる構成も避けやすくなる。

生成AIのAPIはモデル性能だけで選ばない

生成AIのAPIを探すと、精度、コンテキスト長、入出力単価の比較が目に入る。もちろん、どれも大切だ。ただし、公開ベンチマークで上位のモデルが、そのまま自社業務の最適解になるとは限らない。

たとえば、契約書の確認支援と社内FAQでは失敗の重さが違う。前者は条項の見落としを防ぐ確認工程が必要だ。後者は回答不能時に担当窓口へ渡せれば、完全自動化しなくても価値を出せる。

比較すべきなのは「どのモデルが一番賢いか」ではない。

自社の代表ケースを、決めた時間、費用、安全条件で処理できるかを比べる。

そのためには、同じ入力、期待する出力、禁止事項、合格条件を候補ごとに変えずに試す。AI要件定義を受け入れ条件から逆算する方法で扱ったように、合格条件を先に固定すると、モデルの印象ではなく業務適合で評価できる。APIだけでなく実行基盤も比べる場合は、AIエージェントの比較で見る6つの条件も使える。

条件1：データ保持と処理場所を確認する

「APIに送ったデータは学習に使われない」と「データが保存されない」は別の条件だ。

OpenAIのデータ管理の説明では、APIデータの学習利用、監視ログ、機能ごとのアプリケーション状態が分けて整理されている。保持期間やZero Data Retentionの対象可否は、使うエンドポイントや機能によって異なる。

Google CloudのGemini Enterprise Agent Platformにおけるデータ保持条件では、監視ログ、グラウンディング、リクエスト・レスポンスログなどを機能単位で説明している。Azureでも、データの処理・保存条件はデプロイ方式によって変わる。

つまり、サービス名だけを見て「安全」と判断してはいけない。少なくとも次を要求表へ書く。

• 入力、出力、添付ファイル、ログの保存期間
• 学習利用の有無と、設定・契約上の条件
• 保存場所と推論処理場所
• 社内ログへ残してよい項目と伏せる項目
• 削除方法と、削除完了を確認する手段
• 外部検索や外部ツール利用時の送信先

ここで厄介なのが、便利な機能を追加すると保持条件も変わり得る点だ。会話履歴、ファイル検索、キャッシュ、外部ツールは、それぞれ別のデータ経路を持つ。基本APIの説明だけで済ませず、実際に使う機能の組み合わせで確認する。

入力データの分類も必要になる。「社外秘」という一語では粗すぎる。個人情報、顧客資料、公開情報、社内規程などに分け、どの区分をどのAPI構成へ送れるかを決める。AIが読める仕様書の作り方と同じく、曖昧な方針をデータ項目と処理条件へ落とすのが先だ。

条件2：可用性と割当上限を業務量で見る

開発環境で10回成功しても、月末に1万件を処理できるとは限らない。生成AI APIには、リクエスト数、トークン量、同時実行数、モデルやリージョンごとの割当上限がある。

Google CloudのGemini Enterprise Agent Platformにおけるスループットの説明では、従量課金型に加え、一定量の処理能力を固定料金で確保するProvisioned Throughputが示されている。予測可能な処理量が必要なら、従量課金だけでなく容量確保の方式も比較対象になる。

ここから分かるのは、可用性を「APIが動くか」の一問で確認してはいけないということだ。業務側の時間軸へ翻訳する。

SLAも対象範囲まで読む。Google CloudのVertex AI SLAでは、一般提供前の機能、システム上の割当上限によるエラー、該当資料で推奨される利用期間を過ぎたモデルなどが対象外条件に含まれる。契約上の稼働率だけでなく、自分たちが使うモデル、機能、リージョン、購入方式が対象かを確認したい。

設計では、429、タイムアウト、空回答、形式不正を別の失敗として扱う。再試行すればよい失敗と、人へ渡すべき失敗を混ぜない。停止条件と引き継ぎ先まで書いて初めて、可用性の要件になる。

条件3：応答速度と総費用を同じケースで測る

生成AI APIの料金は、単価表だけでは決まらない。

入力トークン、出力トークン、キャッシュ、検索、ファイル処理、再試行、監視、評価環境まで足したものが総費用になる。安いモデルでも回答が長く、やり直しが多ければ逆転する。高性能モデルを全処理に使う必要もない。

そこで、代表ケースを3種類ほど用意する。

• 通常ケース：最も多い入力と期待出力
• 重いケース：長文、複数ファイル、複雑な判断
• 例外ケース：情報不足、矛盾、禁止対象を含む入力

各ケースで、入力・出力トークン、応答時間、成功率、再試行回数、人の修正時間を記録する。費用は「1回いくら」ではなく、「合格する成果物1件を得るまでいくら」で見る。

モデルを分ける方法もある。分類や抽出は軽量モデル、最終判断を支援する文案は高性能モデル、といった使い分けだ。ただし、振り分け条件が曖昧だと品質事故を増やす。どの条件で上位モデルへ渡すか、業務ルールとして明文化する。

また、平均応答時間だけでは対話機能の体感を捉えにくい。混雑時を含む95パーセンタイル、最初の応答が返るまでの時間、全処理の完了時間を分けて測る。バッチ処理なら速さより、締切までに完了し、途中から再開できることの方が重要な場合もある。

条件4：モデル更新と切替可能性を設計する

生成AI APIは、選んだら5年間固定して使う部品ではない。新モデルの追加、旧モデルの終了、料金改定、出力傾向の変化が起こる。

この前提を無視すると、更新時に全機能を目視確認することになる。逆に、切替可能性を優先しすぎて全APIの差を隠す巨大な共通層を作ると、各サービスの利点を使えなくなる。

実装成果物として残したい備えは次の4つだ。

1. アプリケーションからモデルIDとプロンプト版を分離する
2. 構造化出力を自社の業務スキーマで検証する
3. 代表ケースと合格条件を回帰テストとして保存する
4. 切替時に比較する品質、速度、費用の基準値を残す

特に大切なのは、出力形式と業務上の意味を分けることだ。JSONとして正しくても、金額の意味や承認状態が誤っていれば使えない。AIエージェントの評価設計で扱う評価観点のように、形式、内容、安全性、運用を別々に確認する。

モデルの更新は、精度向上だけを期待して進めない。以前は回答不能として人へ渡していた入力を、新モデルが自信ありげに誤回答する可能性もある。禁止条件、情報不足時の停止、根拠提示を回帰テストへ含める。

API固有の違いを比較表にする

4条件を決めたら、各APIの機能差を同じ質問で確認する。ここを「対応あり・なし」だけで埋めると危ない。契約、リージョン、モデル、プレビューか一般提供かによって答えが変わるためだ。

この表があると、「OpenAI互換」という言葉だけで切替可能と判断せずに済む。HTTPの形が似ていても、構造化出力、ツール呼び出し、エラー、利用量の計測方法は同じとは限らない。共通化する部分と、プロバイダー固有として残す部分を分ける。

4条件を選定表へ落とす手順

実務では、候補APIを調べ始める前に1枚の選定表を作ると進めやすい。

1. 対象業務と代表ケースを固定する

「社内文書を活用する」のような広い表現を避ける。誰が、どの入力から、何を作り、誰が確認するのかを書く。通常、重い、例外の3ケースを用意する。対象業務そのものが曖昧なら、プロセスマイニングをAI要件に変える方法のように、実際の処理順と例外から対象を絞る。

2. 失格条件を先に決める

点数で相殺できない条件を明確にする。たとえば、指定地域で処理できない、必要な保持条件を満たさない、期限内の処理量を確保できない、といった条件だ。

3. 4条件へ重みを付ける

顧客データを扱うならデータ保持を重くする。リアルタイム接客なら応答速度と可用性を重くする。社内バッチなら、総費用と再処理性を重視できる。

4. 同じ入力で試験する

候補ごとにプロンプトやデータを都合よく変えない。共通の代表ケースを使い、合格件数、処理時間、費用、人の修正時間を測る。

5. 運用責任を決める

割当上限の監視、モデル更新の検知、データ取扱い条件の確認、回帰テストの実行を誰が持つかを書く。発注者、SIer、API提供者の責任を一つにまとめない。

生成AIのAPI選定は、モデルの人気投票ではない。業務を止めず、データを守り、費用を説明し、将来の変更へ対応する設計作業だ。

4条件を要求とテストへ落とせば、候補が増えても比較の軸はぶれない。株式会社Atsumellでは、AI機能の企画から要件定義、評価設計、業務システムへの組み込みまで支援している。API選定をPoCで終わらせず本番運用へつなげたい場合は、お問い合わせフォームから相談してほしい。

関連記事

• AI要件定義は受け入れ条件から逆算する
• 「AIが読める仕様書」の書き方
• AIエージェントの要件定義は評価設計から