第28章LLMをアプリに組み込む

LLMをアプリケーションに組み込むときの、実際のやり取りを見ていきます。この章では、APIを通じたLLMの 呼び出しの基本と、応答の受け取り方、そして費用に直結するトークンとの関係を扱います。第7部の 締めくくりとして、開発の全体像を整理します。ここまでの知識が、一つのつながりとして見えてきます。

28.1API経由でLLMを呼び出す

クラウドのLLMをプログラムから使うときは、APIと呼ばれる窓口を通すのが一般的です。APIとは、あるサービスの 機能を、決められた手順で外部から呼び出せるようにした窓口のことです。LLMのAPIでは、プログラムから プロンプトや会話履歴を送ると、モデルの応答が返ってきます。人がチャット画面で操作する代わりに、プログラム から同じことを頼む、と考えると分かりやすいでしょう。

利用にあたっては、本人であることを示すための鍵（APIキーなど）が必要になるのが通常です。この鍵は、 料金の請求先とも結びつくため、他人に知られないよう厳重に管理します。うっかりコードに直接書き込んで 共有してしまう、といった事故は避けなければなりません。鍵の扱いは、第9部で見るセキュリティの観点とも つながります。

28.2リクエストとレスポンスの基本

APIを通じたやり取りは、送信（リクエスト）と応答（レスポンス）の往復として捉えられます。リクエストには、 これまで見てきた会話履歴や、使用するモデルの指定、第23章で扱った温度などの設定を含めます。レスポンス には、モデルの応答本文に加えて、使ったトークン数などの情報が含まれるのが一般的です。次のコードは、 この往復のイメージです。会話履歴と設定を渡し、応答を受け取ります。

response = llm_api(
    model="使用するモデル名",
    messages=history,      # これまでの会話履歴
    temperature=0.7,       # 出力のばらつきの設定
)

print(response.text)          # 応答の本文
print(response.used_tokens)   # 使ったトークン数

ここで、第26章で見た会話履歴の管理が効いてきます。messages にこれまでの履歴を入れて渡す ことで、ステートレスなモデルにも文脈を踏まえた応答をさせられるのです。第7部で見てきた話が、この一つの 呼び出しの中でつながっているのが分かります。

28.3ストリーミング出力

第15章で見たとおり、LLMは文章を一トークンずつ生成します。この性質を活かし、応答が全部でき上がるのを 待つのではなく、生成されたそばから少しずつ受け取る方式があります。これをストリーミングと呼びます。 チャットで、応答が少しずつ画面に流れて表示されるのは、この方式によるものです。

長い応答でも、最初の部分をすぐ見せられるため、利用者の待ち時間の体感を大きく減らせます。全部でき 上がるまで真っ白な画面で待たされるより、少しずつでも出てくるほうが、はるかに快適です。対話的な アプリケーションでは、よく使われる方式です。中身の計算は変わりませんが、見せ方を工夫することで、 使い心地が大きく変わる好例だといえます。

28.4コストとトークンの関係

クラウドLLMの利用費用は、多くの場合、やり取りするトークンの量に応じて決まります。ここで注意したいのは、 費用の対象になるのは出力だけではない、という点です。送信する入力、すなわちプロンプトや会話履歴も トークンとして数えられます。第26章で見たとおり、会話が長くなるほど毎回渡す履歴も長くなるため、 やり取りを重ねるほど一回あたりのトークンが増え、費用もかさみます。

第7部で見てきた、ステートレスであること、会話をプログラム側で管理すること、動かす場所を選べること、 そしてトークンが費用に直結すること。これらは、LLMを使ったアプリケーションを作るうえでの土台になります。 一つの呼び出しの裏側で、これだけのことが関わっているのです。次の第8部では、LLMに外部の知識やツールを 組み合わせて、その力を広げる方法を見ていきます。