Cloud AI エンジニア入門ガイド
Go back

10. ChatGPTとAPIの違い

ChatGPTでうまくいったから、そのまま自社サービスに組み込めるはず。そう考えると、前提の違いで転びます。製品としてのChatGPTと、開発者向けのAPIがどう違うのかを見ていきます。プログラミングに馴染みがなければ、最後の使い分けの節だけ読んで構いません。

この章の全体像として、何が違うのか、APIの最小構成、会話状態の管理、料金の考え方の4つを番号順に並べ、読み終えるとAPIへ移るべき場面を判断できるようになることを示した図

シリーズ目次 ／ 前章: 09. ChatGPTカスタムGPTとエージェント ／ 次章: 11. ChatGPTの限界とリスク

Table of contents

Open Table of contents

この章のねらい

何が違うのか

API（Application Programming Interface） は、プログラムから別のプログラムの機能を呼び出すための窓口です。OpenAI APIを使えば、自作のアプリやスクリプトからモデルを直接呼び出せます。

ChatGPTは製品としてUIと機能を提供し、APIは会話状態やツールを選択して使える開発者向けの窓口であることを示した対比図

観点ChatGPTOpenAI API
使う人誰でも（画面を操作）開発者（コードから呼び出す）
提供されるもの完成した製品（UI・機能・履歴管理）モデルへのアクセスと、APIから使える機能・ツール
課金月額のプラントークンやツールなど、利用量に応じた従量課金
会話の記憶サービス側が管理するエンドポイントにより異なる。手動管理または状態保持を選べる
検索・ファイル解析機能として組み込み済みResponses APIなどの組み込みツール、または自作ツールを使う
データの既定の扱いプランと設定による既定では学習に使われない扱いが基本（規約要確認）
応答の制御画面上の選択肢の範囲パラメータで細かく制御できる

第1章で書いたとおり、ChatGPTのAPIという表現は正確ではありません。同じモデルに対する2つの入口です。

APIの最小構成

会話履歴を自分で渡すChat Completions APIの最小例です。APIへ送るのはモデル名とメッセージの配列。メッセージには役割（role）が付きます。

role意味
system（または developer）全体の方針・役割の指定。ChatGPTのカスタム指示に相当
user利用者の発言
assistantモデルの過去の応答

1回の送信に何が入るのかを図にすると、構造が見えてきます。

1回のリクエストがモデル名と、system・user・assistantという役割が付いたメッセージの配列で構成されることを示した図

コマンドラインからの最小例です。<YOUR_API_KEY> と <MODEL_NAME> は自分の値に置き換えてください。

curl https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer <YOUR_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "<MODEL_NAME>",
    "messages": [
      {"role": "system", "content": "簡潔な日本語で答えてください。"},
      {"role": "user", "content": "APIとは何ですか。3行で説明してください。"}
    ]
  }'

Pythonの公式ライブラリを使う場合は次のようになります。

from openai import OpenAI

# APIキーは環境変数などから読み込み、コードに直接書かない
client = OpenAI()

response = client.chat.completions.create(
    model="<MODEL_NAME>",
    messages=[
        {"role": "system", "content": "簡潔な日本語で答えてください。"},
        {"role": "user", "content": "APIとは何ですか。3行で説明してください。"},
    ],
)

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

APIキーはパスワードと同じです。ソースコードに直接書かない。リポジトリにコミットしない。クライアント側（ブラウザやスマホアプリ）に埋め込まない。ここが最低ラインです。漏れたら第三者に使われて、利用料はこちらに来ます。

会話状態の管理方法

APIの会話状態は、使うエンドポイントによって管理方法が異なります。Chat Completionsでは各リクエストが独立しているため、会話を続けたければ過去のメッセージを自分で含めて送る必要があります。一方、Responses APIではprevious_response_id、Conversations APIでは会話IDを使って状態を継続できます。

1ターン目に送るもの: system + user1
2ターン目に送るもの: system + user1 + assistant1 + user2
3ターン目に送るもの: system + user1 + assistant1 + user2 + assistant2 + user3

2つの方式では、ターンが進んだときに送るものの量が変わります。

過去のメッセージを毎回含めて送る手動方式ではターンごとに送信量が増えるのに対し、会話IDで継続する方式では送信量が増えにくいことを左右に並べて示した図

Chat Completionsで履歴を毎回送ると、会話が長くなるほど送信量、つまり料金が増えます。古い発言を要約して圧縮する、必要な部分だけ残す、といった工夫が要ります。Responses APIやConversations APIを使う場合も、会話状態の保持方法とコンテキスト上限は確認してください。

料金の考え方

APIの料金は利用量に応じた従量課金です。モデルの入出力は、第2章で説明したトークンが主な課金単位。使う機能によっては別の課金単位も乗ります。

コストを抑える手はこのあたりです。

  1. 用途に対して過剰に高性能なモデルを使わない
  2. 不要に長いプロンプトを送らない（会話履歴の圧縮）
  3. 繰り返し送る共通部分にキャッシュの仕組みを使う
  4. 出力の上限トークン数を設定する

何が積み上がって総額になるのか、抑える手段と並べて見ておきます。

入力トークン、出力トークン、ツール呼び出し、保存とコンテナという4つの料金項目と、モデル選択・履歴の圧縮・キャッシュ・出力上限という4つの抑える手段を左右に並べた図

制御できること

画面ではいじれない設定が、APIでは明示的に指定できます。

項目内容
temperature など出力のばらつき具合。低くすると安定し、高くすると多様になる
最大出力トークン数生成の長さの上限
構造化出力JSONなど決まった形式での出力を強制する
ツール（組み込み・関数）呼び出し組み込みツールを使う、またはモデルに関数を選ばせてアプリ側で実行し、結果を返す
ストリーミング生成中の文字を逐次受け取る

業務システムに組み込むなら、構造化出力が効きます。自由文の応答は解析が難しく壊れやすいのに対し、決まった形式で受け取れれば後続処理が安定します。

関数呼び出しは、第9章のエージェントの土台です。モデルは関数を直接実行しません。この関数をこの引数で呼びたい、という要求を返すだけです。実際に実行するのはアプリ側で、だからこそそこに権限の制御を入れられます。なお、Web検索やファイル検索などの組み込みツールは、API側が実行する方式もあります。

どちらを使うべきか

状況選択
自分や同僚が手作業で使うChatGPT
定型作業を共有したいChatGPTのカスタムGPT
自社サービスの機能として組み込むAPI
大量のデータを一括処理するAPI
出力を決まった形式で受け取り後続処理へ渡したいAPI
社内システムの権限管理下で動かしたいAPI

分かれ目は、人が画面で結果を読むのか、プログラムが結果を処理するのか。前者ならChatGPT、後者ならAPIです。

要点

参考資料

シリーズ目次 ／ 前章: 09. ChatGPTカスタムGPTとエージェント ／ 次章: 11. ChatGPTの限界とリスク

Share this post:
Share this post on FacebookShare this post on Xはてなブックマークに追加LINEでこの記事を共有する
Previous Post
11. ChatGPTの限界とリスク
Next Post
09. ChatGPTカスタムGPTとエージェント