OpenAI API「ChatCompletion廃止」|openai>=1.0.0の破壊的変更と移行手順【2026年版】
TL;DR
- OpenAI Python SDK バージョン 1.0.0 以降、
openai.ChatCompletionは廃止されAttributeErrorでエラーになります - レスポンスがオブジェクト形式に変更されたため、辞書のようなブラケット記法(
response['choices']など)でアクセスすると「'ChatCompletion' object is not subscriptable」エラーが発生します - OpenAI APIの古いエンドポイント「v1/completions」も廃止予定。チャットモデル(GPT-4、GPT-3.5 Turbo)はこのエンドポイントに対応していません
- 全ての既存コードは新しい
Clientベースの API に書き換え必須。ドット記法(response.choices[0].message.content)での操作が必須です - 段階的な移行ロードマップと後方互換性確保の方法があり、計画的な対応で運用を継続できます
- パッケージ更新時に必ず公式マイグレーションガイドを確認してください
背景:OpenAI SDK の大規模リファクタリング
OpenAI の Python SDK は大きな進化を遂げました。バージョン 1.0.0 より前は、旧形式のシンプルな関数形 API が提供されていました。
# 旧形式(0.x系)
import openai
openai.api_key = "your-key"
response = openai.ChatCompletion.create(
model="gpt-4",
messages=[{"role": "user", "content": "Hello"}]
)
しかし 1.0.0 から大きく変わり、新しい Client インスタンスを経由するオブジェクト指向スタイルへ統一されました。OpenAI は現在 v1.3.x 以降を推奨しており、古いバージョンへのダウングレードはセキュリティリスクもあるため、アップグレード+コード修正が必須です。
なぜこのような変更が入ったか
OpenAI は、以下の理由で API パッケージを再設計しました。
- 型安全性の強化:辞書形式では、存在しないキーにアクセスしてもキーエラーが発生するまで気づきにくい。オブジェクト形式なら IDE の自動補完が機能し、開発時に誤りを検出できます
- API スキーマとの一貫性:OpenAI の REST API 仕様と Python パッケージの実装ギャップを縮小するため
- 保守性:パッケージ内部の構造が明確になり、将来の拡張が容易になります
- 非同期処理の統一化:asyncio を用いた非同期呼び出しが標準化されました
発生するエラーの詳細
バージョン 1.0.0 以降を導入した環境で古いコードを実行すると、以下のようなエラーが発生します:
AttributeError: module 'openai' has no attribute 'ChatCompletion'
また、別の場面では:
You tried to access openai.ChatCompletion, but this is no longer supported in openai>=1.0.0
というメッセージが表示される場合もあります。このエラーは、SDK のレイヤーが明示的に古い API へのアクセスを遮断していることを示しています。
さらに、旧形式のパラメータを渡している場合には次のエラーも発生します:
openai.error.InvalidRequestError: Unrecognized request argument supplied: messages
パターン1: ChatCompletion object is not subscriptable
# ❌ 古いコード(失敗する例)
import openai
response = openai.ChatCompletion.create(
model="gpt-3.5-turbo",
messages=[{"role": "user", "content": "こんにちは"}]
)
# subscriptableでない(インデックスでアクセスできない)
print(response[0]) # TypeError: 'ChatCompletion' object is not subscriptable
原因:OpenAI Python SDK のバージョン 1.0.0 以降、レスポンスオブジェクトの構造が変更されました。辞書キーでのアクセス(response['choices'][0])ではなく、属性アクセス(response.choices[0])に変更する必要があります。
Python では「subscriptable(添え字操作可能)」とは、オブジェクトが [] 記法をサポートしている状態を指します。辞書やリストは subscriptable ですが、通常のクラスインスタンスは subscriptable ではありません。新形式ではレスポンスが強い型付けのデータクラス形式の構造化オブジェクトになったため、ブラケット記法を使うとこのエラーが発生します。
パターン2: This is a chat model and not supported in the v1/completions endpoint
# ❌ 古いエンドポイントを使用している場合
import requests
import os
headers = {
"Authorization": f"Bearer {os.environ['OPENAI_API_KEY']}"
}
data = {
"model": "gpt-3.5-turbo", # チャットモデルをv1/completionsで使用
"prompt": "こんにちは"
}
# POST https://api.openai.com/v1/completions
# → エラー: This is a chat model and not supported in the v1/completions endpoint
response = requests.post("https://api.openai.com/v1/completions", json=data, headers=headers)
原因:gpt-3.5-turbo や gpt-4 はチャットモデル設計です。これらのモデルは v1/chat/completions エンドポイントのみで動作します。v1/completions エンドポイントは旧世代モデル(text-davinci-003 など)用であり、チャットモデルを指定するとエラーになります。
何が変わったのか:新しい API 形式
新形式の基本構造
新バージョンでは、まず Client インスタンスを生成し、そこから各機能にアクセスします:
from openai import OpenAI
# Client インスタンスを作成
client = OpenAI(api_key="your-api-key")
# チャットを実行
response = client.chat.completions.create(
model="gpt-4",
messages=[
{"role": "user", "content": "Hello"}
]
)
# レスポンスは属性アクセスで取得
print(response.choices[0].message.content)
構造の解説:
response.choices:メッセージ候補のリスト。create()のnパラメータで複数の候補を要求できますresponse.choices[0]:最初の選択肢(通常は唯一)response.choices[0].message:メッセージオブジェクトresponse.choices[0].message.content:テキスト本体
主な変更点
| 項目 | 旧形式(0.x) | 新形式(1.0.0+) |
|---|---|---|
| モジュール導入 | import openai | from openai import OpenAI |
| API キー設定 | openai.api_key = "..." | client = OpenAI(api_key="...") |
| ベースURL設定 | openai.api_base = "..." | base_url="..." をコンストラクタに指定 |
| API 呼び出し | openai.ChatCompletion.create() | client.chat.completions.create() |
| レスポンス | 辞書形式(['key']アクセス) | オブジェクト形式(.keyアクセス) |
レスポンス形式の詳細な変更点
v1/completions のレスポンス(廃止予定)
{
"id": "cmpl-xxx",
"object": "text_completion",
"choices": [
{
"text": "東京です",
"index": 0,
"finish_reason": "stop"
}
]
}
v1/chat/completions のレスポンス(推奨)
{
"id": "chatcmpl-xxx",
"object": "chat.completion",
"choices": [
{
"index": 0,
"message": {
"role": "assistant",
"content": "東京です"
},
"finish_reason": "stop"
}
]
}
| 取得内容 | 廃止予定 | 推奨 |
|---|---|---|
| レスポンステキスト | response["choices"][0]["text"] | response.choices[0].message.content |
| トークン使用数 | response["usage"]["total_tokens"] | response.usage.total_tokens |
| 終了理由 | response["choices"][0]["finish_reason"] | response.choices[0].finish_reason |
既存ユーザーへの影響
どのバージョンから影響を受けるか
- OpenAI SDK 0.28.1以前: 影響なし。従来の
openai.ChatCompletion.create()が動作 - OpenAI SDK 1.0.0以降: 修正が必須。新しいクライアント形式への移行が必要
pip show openai でインストール済みのバージョンを確認できます。
$ pip show openai
Name: openai
Version: 1.3.0
どのコードが影響を受けるか
以下の形式を使っているすべての Python スクリプトが影響を受けます:
openai.ChatCompletion.create()openai.Completion.create()openai.Embedding.create()openai.Image.generate()- その他、直接モジュール属性にアクセスするパターン
- レスポンスにブラケット記法(
response['choices']など)でアクセスしているコード - REST API で
https://api.openai.com/v1/completionsを直接呼び出しているコード
影響を受けるケース
-
新規インストール環境:最新のOpenAI SDKをインストールすると、デフォルトで1.0.0以降がインストールされるため、古いコードは動作しません
-
既存の商用アプリケーション:バージョン管理が曖昧(
pip install openaiで最新版が入る環境)の場合、更新後に本番障害が発生する可能性があります -
バッチ処理・スケジュール実行スクリプト:エラーで処理が停止し、気づかないまま障害が継続するリスクがあります
-
ウェブアプリケーション:Flask、Django、FastAPI などのフレームワークを使うアプリケーションで OpenAI 連携が機能しなくなります
-
チームプロジェクト:ドキュメント、テストコード、CI/CD パイプラインまで、一括更新の手間が発生します。CI/CD パイプラインで無条件に最新版をインストールしている場合、デプロイ時に本番障害を引き起こす可能性があります
-
企業内のLLMチャットbot・SaaS製品:社内ヘルプデスク、Q&A自動応答、コンテンツ生成機能、API経由でChatGPTを活用しているサービスなど、幅広いシステムが対象となります
-
旧世代モデルに依存している場合:text-davinci-003、text-davinci-002、text-curie-001 などを使用中の場合、これらモデルの提供終了に伴い、コード修正が避けられません
-
他人が書いた古いチュートリアルを参考にしている場合:インターネット上に多く存在するv0.x形式のコード例が動かない点に注意が必要です
必要な対応と移行手順
ステップ 1:現在の SDK バージョンを確認
pip show openai
v1.0 以降であれば、以下の修正が必要です。本番環境で障害が起きている場合は、まず旧バージョンを固定します:
pip install 'openai<1.0.0'
これで即座に動作を復旧できます。ただし、古いバージョンへのダウングレードは以下の理由から長期運用には非推奨です:
- セキュリティアップデート:新バージョンで脆弱性が修正されても、旧バージョンには反映されない可能性があります
- API 廃止予定:OpenAI が古い SDK のサポート終了を公表する可能性があります
- 新機能の利用不可:最新の OpenAI API(Vision、Fine-tuning 等)に対応していない可能性があります
ステップ 2:開発環境で新バージョンをインストール
pip install --upgrade openai
最新の 1.0.0 以降が入ります。
ステップ 3:コード移行の具体例
旧形式のコード例:
import openai
openai.api_key = "sk-..."
def chat_with_gpt(user_message):
response = openai.ChatCompletion.create(
model="gpt-4",
messages=[
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": user_message}
],
temperature=0.7
)
return response["choices"][0]["message"]["content"]
print(chat_with_gpt("What is the capital of France?"))
新形式への移行後:
from openai import OpenAI
client = OpenAI(api_key="sk-...")
def chat_with_gpt(user_message):
response = client.chat.completions.create(
model="gpt-4",
messages=[
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": user_message}
],
temperature=0.7
)
return response.choices[0].message.content
print(chat_with_gpt("What is the capital of France?"))
変更のポイント:
from openai import OpenAIで Client クラスをインポートclient = OpenAI(api_key="sk-...")でインスタンス生成openai.ChatCompletion.create()→client.chat.completions.create()- レスポンス取得:
response["choices"][0]["message"]["content"]→response.choices[0].message.content(属性アクセス)
複数のエンドポイントを使い分けている場合
カスタムベースURLを指定する場合の修正方法です。
修正前:
import openai
openai.api_key = "sk-..."
openai.api_base = "https://custom-endpoint.example.com/v1"
response = openai.ChatCompletion.create(
model="gpt-3.5-turbo",
messages=[{"role": "user", "content": "テスト"}]
)
修正後:
from openai import OpenAI
client = OpenAI(
api_key="sk-...",
base_url="https://custom-endpoint.example.com/v1"
)
response = client.chat.completions.create(
model="gpt-3.5-turbo",
messages=[{"role": "user", "content": "テスト"}]
)
ステップ 4:環境変数からの API キー読み込み(推奨)
ハードコードされた API キーはセキュリティリスクです。環境変数から読み込むことを推奨します。
from openai import OpenAI
# API キーを環境変数から自動読み込み
client = OpenAI()
response = client.chat.completions.create(
model="gpt-4",
messages=[{"role": "user", "content": "Hello"}]
)
環境変数の設定:
# Linux/Mac
export OPENAI_API_KEY="sk-..."
# Windows (PowerShell)
$env:OPENAI_API_KEY="sk-..."
ステップ 5:エラーハンドリングの追加(本番環境向け)
from openai import OpenAI
from openai import APIError, APIConnectionError, RateLimitError
client = OpenAI()
try:
response = client.chat.completions.create(
model="gpt-3.5-turbo",
messages=[{"role": "user", "content": "Hello"}]
)
print(response.choices[0].message.content)
except RateLimitError:
print("API rate limit に達しました。しばらく待ってから再試行してください。")
except APIConnectionError as e:
print(f"API 接続エラー: {e}")
except APIError as e:
print(f"API エラー: {e}")
ステップ 6:REST API を直接使用している場合
廃止対象の古いエンドポイント:
# ❌ 廃止予定
curl https://api.openai.com/v1/completions \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-d '{"model":"gpt-3.5-turbo","prompt":"こんにちは"}'
推奨される新しいエンドポイント:
# ✅ 推奨
curl https://api.openai.com/v1/chat/completions \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-3.5-turbo",
"messages": [
{"role": "user", "content": "こんにちは"}
]
}'
主な違い:
- エンドポイントが
/completionsから/chat/completionsに変更 - リクエスト形式が
promptからmessages配列に変更 - レスポンス形式も
textからchoices[0].message.contentに変更
ステップ 7:他のエンドポイントの対応
ChatCompletion 以外の API も同じ方針で移行します:
埋め込みベクトル化(Embedding):
# 旧形式
embedding = openai.Embedding.create(
model="text-embedding-3-small",
input="Hello world"
)
# 新形式
embedding = client.embeddings.create(
model="text-embedding-3-small",
input="Hello world"
)
画像生成(Image):
# 旧形式
image = openai.Image.create(
prompt="A cat on a chair",
n=1,
size="1024x1024"
)
# 新形式
image = client.images.generate(
prompt="A cat on a chair",
n=1,
size="1024x1024"
)
ステップ 8:影響範囲の確認
コードベース全体で以下の検索を実行し、変更が必要な箇所を洗い出します:
# v1/completions への直接参照
grep -r "v1/completions" .
# ChatCompletion.create の使用箇所
grep -r "ChatCompletion.create" .
# Completion.create の使用箇所(テキスト補完)
grep -r "Completion.create" .
# ブラケット記法(古いレスポンス形式)
grep -r 'response\["choices"\]' .
grep -r "response\['choices'\]" .
grep -r 'response\[0\]' .
ステップ 9:依存関係ファイルの更新
requirements.txt やプロジェクト設定ファイルを更新します。
requirements.txt の場合:
openai>=1.0.0
または、マイナーバージョンの更新のみ許可する場合:
openai>=1.0,<2.0
pyproject.toml の場合(Poetry使用時):
[tool.poetry.dependencies]
openai = "^1.0.0"
setup.py の場合:
install_requires=[
"openai>=1.0.0",
]
ステップ 10:テストと段階的ロールアウト
修正後、ステージング環境で動作確認を実施します。サンプルテスト例:
from openai import OpenAI
def test_chat_completion():
client = OpenAI(api_key="sk-...")
response = client.chat.completions.create(
model="gpt-3.5-turbo",
messages=[{"role": "user", "content": "hello"}]
)
assert response.choices[0].message.content is not None
assert len(response.choices) > 0
print("✓ Test passed")
if __name__ == "__main__":
test_chat_completion()
- ユニットテストを実行:新形式で動作確認
- ステージング環境でテスト:実際の API 呼び出しで検証
- 段階的なロールアウト:小規模ユーザーから本番展開
- 監視:エラーログを監視し、問題が生じないか確認
後方互換性確保のための戦略
大規模なシステムでは、一度に全コードを書き換えるのが難しい場合があります。以下の方針を組み合わせて計画的に移行してください。
方針1:従来バージョンの保持(短期緊急対応)
既存システムが安定稼働している場合、バージョンを固定したまま並行運用することが可能です:
pip install openai==0.28.0
ただし、セキュリティ脆弱性の修正が提供されなくなる可能性があるため、長期的には推奨されません。
方針2:仮想環境の分離
複数のプロジェクトが異なるバージョンに依存している場合、Pythonの仮想環境(venv)で分離管理します:
# プロジェクトA(新しいバージョン)
python -m venv env_new
source env_new/bin/activate
pip install openai>=1.0.0
# プロジェクトB(従来バージョン)
python -m venv env_old
source env_old/bin/activate
pip install openai==0.28.0
方針3:段階的な機能単位での移行
大規模なアプリケーションでは、ChatGPT連携機能を複数のモジュールに分割し、機能ごとに移行タイミングをずらす戦略が有効です:
- 第1段階:検索補助機能を新バージョンへ移行
- 第2段階:テスト運用環境で検証
- 第3段階:本番環境への段階的なデプロイ
- 第4段階:残りの機能を順次移行
既存プロジェクトでの一括対応
複数のファイルで旧形式を使っている場合、以下のアプローチが効率的です:
方法 1:検索と置換(エディタの機能を活用)
テキストエディタ(VS Code など)の正規表現検索で Find and Replace 機能を使い、複数ファイルを同時置換できます:
- 検索:
openai\.ChatCompletion\.create\(→ 置換:client.chat.completions.create( - 検索:
response\['choices'\]\[0\]\['message'\]\['content'\]→ 置換:response.choices[0].message.content
方法 2:コード生成ツール
LLM を使った自動リファクタリングの活用も考えられます。ただし、完全な自動変換は困難なため、手動テストは必須です。
方法 3:ラッパー関数を用意(短期対応)
移行期間の間、互換性レイヤーを作成することもできます:
from openai import OpenAI
_client = OpenAI()
class CompatOpenAI:
class ChatCompletion:
@staticmethod
def create(**kwargs):
return _client.chat.completions.create(**kwargs)
openai.ChatCompletion = CompatOpenAI.ChatCompletion
ただし、これは一時的な対応であり、根本的な移行を遅延させるだけです。最終的には正式な新形式への移行を完了させてください。
移行時のチェックリスト
- OpenAI Python SDK をバージョン 1.0 以上にアップグレード
- 全プロジェクトの現在のopenaiバージョンを把握
- 依存する他のライブラリとの互換性を確認
-
from openai import OpenAIでインポートしている - グローバルの
openai.api_key設定を削除している -
client = OpenAI()でインスタンスを作成している -
client.chat.completions.create()メソッドを使用している - 返却値へのアクセスをドット記法(
.choices[0].message.content)に変更している(ブラケット記法を使用していない) - REST API 直接呼び出しの場合、エンドポイントを
/v1/completionsから/v1/chat/completionsに変更 - テストケースを実行し、新しい形式でのレスポンス処理が正常に動作することを確認
- API キーの管理方法を環境変数に統一
- エラーハンドリングが実装されている
-
requirements.txtやpyproject.tomlのバージョン指定を更新している - 本番環境へのデプロイ前に、ステージング環境で十分な検証を実施
- 本番環境でのロールバック計画の策定
- チーム全体への周知と教育
実装サンプル:本番環境への適用例
シンプルな会話実装
from openai import OpenAI
class ChatBot:
def __init__(self, api_key: str):
self.client = OpenAI(api_key=api_key)
def ask(self, message: str) -> str:
response = self.client.chat.completions.create(
model="gpt-3.5-turbo",
messages=[
{"role": "user", "content": message}
],
temperature=0.7,
max_tokens=150
)
return response.choices[0].message.content
# 使用例
bot = ChatBot(api_key="sk-...")
answer = bot.ask("OpenAIのAPIについて教えてください")
print(answer)
複数のキーにアクセスする場合
レスポンスには、コンテンツ以外にも以下の情報が含まれます。
from openai import OpenAI
client = OpenAI(api_key="your-api-key")
response = client.chat.completions.create(
model="gpt-3.5-turbo",
messages=[{"role": "user", "content": "Say 'hello' in Spanish"}]
)
# 各種情報をアクセス
print(
---
## 参考:Claude APIへの移行を見据えたバージョン固定
OpenAI SDKの破壊的変更を教訓に、Claude API利用時もバージョンを固定管理する例です。
```txt
# requirements.txt — バージョンを固定して破壊的変更を予防
anthropic==0.68.0
openai==1.55.0
import anthropic
import warnings
# バージョン確認を起動時に組み込む
EXPECTED_VERSION = "0.68.0"
def verify_sdk_version():
"""想定と異なるSDKバージョンで動いていないか起動時にチェック"""
actual_version = anthropic.__version__
if actual_version != EXPECTED_VERSION:
warnings.warn(
f"想定バージョン({EXPECTED_VERSION})と異なるSDK({actual_version})で動作中。"
"破壊的変更の可能性があるため、変更ログを確認してください。"
)
verify_sdk_version()
client = anthropic.Anthropic()
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
messages=[{"role": "user", "content": "こんにちは"}]
)
print(response.content[0].text)
requirements.txtでバージョンを固定し、CI環境でSDKバージョンの想定外の変化を検知する仕組みを組み込んでおけば、OpenAI ChatCompletion廃止のような突然の破壊的変更にも早期に気づけます。
あわせて読みたい
- Anthropic SDK v0.98・v0.93リリース【破壊的変更・移行手順】
- OpenAI CLIツール完全ガイド|インストール・使い方・API料金・実装ユースケース【2026年版】
- OpenAI互換API「429エラー」多発時の対処法|リトライ戦略と移行前チェックリスト【2026年版】