LLMのAPIと提供経路を選ぶ — OpenAI・Claude・Microsoft Foundryの連載まとめ

LLMを選ぶとき、モデル名だけでは決まらない

OpenAIとAnthropicのLLMを調べると、推論、ツール呼び出し、構造化出力、長いコンテキストなど、似た名前の機能が並びます。しかしAPIとして使うと、会話の保存方法も、必須の業務処理を実行させる方法も、利用できる機能の範囲も同じではありません。さらに、提供元のAPIを直接使う場合とMicrosoft Foundry（以下、Foundry）を使う場合で条件が変わります。

この連載は、筆者が事前に行った調査を基に、モデルやAPI、提供経路の仕様の違いをビジネス上の判断へつなげる視点でまとめたものです。モデルの性能評価に加え、実装費、運用責任、データの扱い、将来の移行費を含めて選ぶための読み物にしました。

連載の読み方

回	テーマ	読み終えたときに判断できること
第1回：性能以外の選定軸	モデル・API・提供経路を分ける	比較対象と必須条件を決める
第2回：ResponsesとMessagesの設計差（公開予定）	推論・会話状態・ツール・SDK	アプリが負う責任を見積もる
第3回：直接APIとFoundryの差（公開予定）	機能提供・ホスティング・認証・データ所在	提供経路を候補から絞る
第4回：OpenAIをFoundryで使う（公開予定）	Responses APIと2モデル構成	状態管理と更新方針を設計する
第5回：ClaudeをFoundryで使う（公開予定）	思考ブロックと追記専用の会話	履歴とルーティングを設計する
第6回：費用・評価・移行を決める（公開予定）	総費用、評価ゲート、採用記録	選定理由を説明し、導入を進める

企画・調達の担当者は第1・3・6回、実装の担当者は第2・4・5回から読むこともできます。各回は単独で読めますが、初めての方は順に読むと判断のつながりを追いやすくなります。

選定の要点

自社の条件	判断の出発点	見積もる負担
提供元の新機能が事業の中核	直接APIの対応機能を確認する	別の認証・請求・監視を運用する費用
Azureで運用を統一したい	Foundryで必須機能を満たすか確認する	非対応機能を補う開発費と運用費
国内処理などの所在地条件が必須	モデルとデプロイ種別を先に絞る	選べるモデル・容量・価格の制約
複数モデルを切り替えたい	可視履歴と推論状態の互換性を分ける	会話分岐・再評価・移行の費用
コストを最小化したい	成功した業務1件あたりで比較する	推論、再試行、ツール、監視、人手修正

これは仕様から導く設計上の判断です。回答精度や実際の速度について、この連載では独自ベンチマークを実施していません。

対象と確認日

事前調査は2026年10月1日に行い、主要仕様は2026年10月8日に再確認しています。直接APIの比較は GPT-5.6 SolとClaude Opus 5.5、Foundryの設計例は GPT-5.5／GPT-5.4-mini と Claude Opus 5.5／Sonnet 5.5 を対象とします。

特定世代の設計例として読めるよう、対象を一律に最新モデルへ置き換えてはいません。利用条件や料金は、モデル、リージョン、デプロイ種別、ベータ機能の組み合わせごとに変わります。採用時には、記事内の公式リンクと自社の実環境を照合してください。

連載では、公式文書で確認した事実と、筆者の設計提案・試算例を区別します。「使えるか」を文書で確認しただけでは、自社のアカウントでの利用可否や性能が実証されたことにはなりません。

この連載は「LLM・AIアプリ設計」カテゴリーにまとめています。カテゴリー紹介とドキュメント一覧からも探せます。