開発者のためのLLM API：チャット補完入門

AI2026-09-22TryQuickToolBox

AIを活用した機能の素晴らしいアイデアがあっても、APIドキュメントを読み始めると、トークン、温度、ストリーミング、システムプロンプトといった専門用語の壁にぶつかります。メッセージを送るだけで第二の学位が必要な気分になります。良い知らせは、核となる概念はシンプルです：メッセージのリストを送信すると、モデルが返信を返します。それ以外はすべてチューニングです。この記事では、LLMチャット補完APIをアプリケーションに統合するための実践的な手順を、今日から適応できるコードとともに説明します。

チャット補完APIとは？

基本的に、チャット補完APIは会話履歴を入力として受け取り、会話の次のメッセージを返します。履歴はメッセージオブジェクトの配列で、各オブジェクトにはroleとcontentがあります。ロールは通常、system、user、assistantです。システムメッセージはアシスタントの動作を設定し、ユーザーメッセージは人が入力した内容で、アシスタントメッセージはモデルが以前に返信した内容です。履歴全体を送信することで、モデルに一貫した応答を生成するためのコンテキストを与えます。

ほとんどのプロバイダー（OpenAI、Anthropic、Google、オープンソースの代替品）は同様のパターンに従いますが、正確なエンドポイントやペイロードは異なる場合があります。1つを理解すれば、他のものにもすぐに適応できます。

ステップバイステップ：最初のAPI呼び出し

PythonとOpenAI SDKを使用した最小限の例を見てみましょう。pip install openaiでインストールできます。APIキーをコードから排除するために、環境変数として設定します。

import os
from openai import OpenAI

client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "Explain what an API is in one sentence."}
    ]
)

print(response.choices[0].message.content)

これだけです。レスポンスオブジェクトには選択肢のリストが含まれ、通常は最初のものを取得します。メッセージの内容はモデルの返信です。使用状況の統計にアクセスしてトークン消費を追跡することもできます。

チューニングすべき主要なパラメータ

メッセージ以外に、モデルの出力を制御するいくつかのパラメータがあります：

model：使用するモデル。小さいモデルは安価で高速、大きいモデルはより高性能です。
temperature：ランダム性を制御します。0は決定論的、1は創造的です。事実に基づくタスクには低い値、ブレインストーミングには高い値を使用します。
max_tokens：返信の長さを制限します。予期しない長い（そしてコストのかかる）応答を避けるために設定します。
top_p：多様性を制御するためのtemperatureの代替手段です。通常、どちらか一方を調整し、両方は調整しません。
stream：trueの場合、APIは生成され次第部分的な応答を送信し、体感遅延を改善します。

UXを向上させるストリーミング応答

完全な応答を待つと、特に長い回答では遅く感じられます。ストリーミングを使用すると、テキストが到着するにつれて表示できます。Pythonでストリームを処理する方法は次のとおりです：

stream = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "Tell me a story."}],
    stream=True
)

for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

各チャンクには応答の一部を含むデルタが含まれます。これらの部分を蓄積して完全なメッセージを構築します。Webアプリでは、Server-Sent Events（SSE）またはWebSocketsを使用してこれらのチャンクをブラウザに転送できます。

エラーとレート制限の処理

APIは失敗します。ネットワークは途切れます。レート制限が発生します。統合はこれらを適切に処理する必要があります。一般的なエラーには次のものがあります：

401 Unauthorized：無効なAPIキー。環境変数を確認してください。
429 Too Many Requests：レート制限に達しました。指数バックオフを実装して再試行してください。
500 Internal Server Error：プロバイダー側の問題。遅延を伴って再試行してください。

常にAPI呼び出しをtry/exceptブロックでラップし、失敗をログに記録します。本番環境では、再試行にtenacityのようなライブラリの使用を検討してください。

コストとトークンの管理

トークンはLLM APIの通貨です。入力トークンと出力トークンの両方が請求にカウントされます。コストを予測可能に保つには：

単純なタスクには小さいモデルを使用する。
完全なコンテキストが不要な場合は、会話履歴を最後の数メッセージにトリミングする。
出力長を制限するためにmax_tokensを設定する。
ユースケースが許せば、頻繁な応答をキャッシュする。

プロバイダーのダッシュボードを通じて、または各応答からトークン数をログに記録して使用状況を監視します。

セキュリティとプライバシーの考慮事項

ユーザーデータをLLM APIに送信する場合、そのデータを第三者に信頼することになります。プロバイダーのデータ保持ポリシーを確認してください。パスワードや個人識別情報などの機密情報を送信しないでください。送信する必要がある場合は、自己ホスト型モデルまたは強力なプライバシー保証を持つプロバイダーを検討してください。また、APIキーをクライアント側のコードに決して公開せず、常にバックエンドを通じてリクエストをプロキシしてください。

FAQ

チャット補完と通常の補完の違いは何ですか？

チャット補完は会話インターフェース用に設計されています。ロールを持つメッセージのリストを受け入れ、モデルがコンテキストを維持できるようにします。通常の補完は単一のプロンプト文字列を受け取り、マルチターンの対話にはあまり適していません。

適切なモデルを選ぶにはどうすればよいですか？

プロトタイピングには、より小さく安価なモデルから始めます。より良い推論や長いコンテキストが必要な場合は、より大きなモデルに移行します。特定のタスクで両方をテストし、最適なコストパフォーマンスのトレードオフを見つけます。

1つのアプリで複数のLLMプロバイダーを使用できますか？

はい。多くの開発者は、API呼び出しをインターフェースの背後で抽象化し、コスト、レイテンシ、または機能に基づいてプロバイダーを切り替えます。LiteLLMやLangChainなどのライブラリが、異なるAPIの統合に役立ちます。

次のステップ

基本的な呼び出しができるようになったので、システムプロンプトを試してモデルの動作を誘導しましょう。ストリーミングを試してユーザーエクスペリエンスを向上させましょう。そして常にトークン使用量に注意を払いましょう。構築を進める中で、モデルからのJSON応答をさらに処理するためにフォーマットする必要があるかもしれません。そのためには、JSONフォーマッタが出力を迅速に検証し、整形するのに役立ちます。