前段
実際にOpenAI APIをプロダクトに組み込もうとしていろいろやってみて分かったことのまとめ
OpenAI APIとは
OpenAI APIは、LLM（大規模言語モデル）をWeb APIとして利用できるサービス
特徴は以下の通り
- 従量課金モデル：入力トークン数と出力トークン数に応じて課金される
- モデルごとに単価が異なる：GPT-4.1はGPT-4 Turboより高い
- 言語差はほぼなし：日本語・英語でもトークン計算方法は同じ
-
Function Calling：自社APIを組み込み可能
- 例：「商品をリストアップして」と聞かれたら自社の商品検索のAPIを呼び出し、最新データを返す
- Structured Outputs：スキーマ定義されたJSONを返せる
OpenAI APIの特徴
- 渡すコンテキストが増えるほど精度は上がるが、無関係な情報を増やしても効果はない
- 精度向上やハルシネーション抑制には、RAG（検索拡張生成）で適切な文脈を補う工夫が必要
- コンテキストを増やすとトークン消費が増加し、レスポンス時間も長くなる
- Function Callingの定義や候補はプロンプトに含まれるため、設計次第で効率が変わる
例えば「すべてのビジネスロジックを丸ごとLLMに置き換える」ことは不可能ではないが、コストや体験を大きく損なうリスクがある点に注意が必要。
コスト例
例として「渋谷区でソファを処分する方法教えて」というシンプルな質問を投げた場合：
- 入力 230トークン（system 200 + 質問 30）
- 出力 250トークン
- モデル：GPT-4o
これを基準に、RAGや関数呼び出しを組み合わせると以下のようにコストが変化します。
| 条件 | 入力トークン | 出力トークン | コスト合計 |
|---|---|---|---|
| RAGなし | 230 | 250 | 約0.91円 |
| RAGあり | 1,530 | 400 | 約2.31円 |
| RAGあり＋関数定義＋JSONスキーマ | 2,730 | 500 | 約3.45円 |
RAGや構造化出力を組み込むほどコストは上がるため、ROIを意識した設計が重要っす
採用すべきでない場面
-
ユーザー数 × 実行数が膨大になる処理
（全件比較や毎回の重い計算など）には不向きです。
→ 実行回数が増えるほどコストが急激に膨らみ、ROIが悪化するため。
採用してよい場面
-
データ整備や更新時の処理
- サマライズ、解析、ラベル付けなど、コストが一定で多少時間がかかっても問題ない処理。
- 例：Amazonでの商品レビューのサマライズ。
-
既存UIでカバーできないユーザー層の補完
- 曖昧な質問や横断的なニーズに対応するAIチャットボットを設ける。
- 結果として ユーザー体験の向上 や サポートコスト削減 が期待できる。
というわけで
「高頻度・大量処理には不向き」「補完的な役割には有効」
費用に対して明確なリターンが見込めるかが導入判断のポイント。
事例：Amazonアプリ
Amazonアプリでは下タブの1つをAIチャットにしており、Rufusという自社LLMを活用。
多種多様な商品・サービスを既存UIだけで受け止めるのは難しいため、曖昧なニーズや横断的な質問をAIチャットで吸収していると考えられる。
今後の展望
-
オンデバイスLLM
- 端末で直接LLMが動くようになれば、コスト削減とレスポンス高速化が期待できる
-
クラウド＋ローカルのハイブリッド
- 今後は標準構成になる可能性がある
-
API連携による拡張
- パブリック寄りのサービスであれば、自社プロダクトにAIを組み込むのではなく、ChatGPTのようなAIチャットボットに自社API連携を提供する選択肢もある（認証とかの連携も必要だけど）
まとめ
- やってはいけないのは「大量処理の丸投げ」
- やるべきなのは「データ整備や補完的なUI」
- サービスへのAI組み込み検討に重要なのは、コストとROIを見極めたユースケース設計！
Discussion