第1章 LLMアプリケーション概論
更新日:2025年12月16日
1. LLMの基礎
LLM(Large Language Model:大規模言語モデル)は、大量のテキストデータで学習されたニューラルネットワークモデルである。与えられた入力テキストに対して、次に続く可能性の高いテキストを生成する能力を持つ。2022年11月のChatGPT公開以降、LLMは急速に普及し、様々な業務アプリケーションに組み込まれるようになった。
1.1 LLMとは
LLMは、Transformerアーキテクチャに基づく言語モデルである。数十億から数千億のパラメータを持ち、インターネット上の大量のテキストデータで事前学習(Pre-training)されている。代表的なLLMとして、OpenAIのGPTシリーズ、AnthropicのClaude、GoogleのGemini、MetaのLlamaなどがある。
Table 1. 主要なLLMの比較
| モデル | 提供元 | 特徴 | アクセス方法 |
|---|---|---|---|
| GPT-4o | OpenAI | マルチモーダル、高速 | API |
| Claude 3.5 | Anthropic | 長文コンテキスト、安全性 | API |
| Gemini | マルチモーダル、検索統合 | API | |
| Llama 3 | Meta | オープンソース | ローカル実行可 |
LLMの能力は、テキスト生成、要約、翻訳、質問応答、コード生成など多岐にわたる。ただし、LLM単体では学習データに含まれない最新情報や企業固有の知識を扱えないという制約がある。この制約を克服するために、RAG(検索拡張生成)やエージェントといった手法が用いられる。
1.2 トークンと推論
LLMはテキストを「トークン」という単位で処理する。トークンは単語または単語の一部であり、英語では概ね1単語が1〜2トークン、日本語では1文字が1〜3トークン程度に相当する。
Table 2. トークン数の目安
| テキスト | 概算トークン数 |
|---|---|
| 英語100単語 | 約130トークン |
| 日本語100文字 | 約50〜150トークン |
| A4文書1ページ | 約500〜1000トークン |
LLMの推論(Inference)は、入力トークン列に対して次のトークンを予測し、それを繰り返すことで応答を生成する自己回帰的なプロセスである。このため、生成されるテキストが長いほど処理時間とコストが増加する。APIの料金体系も入力トークン数と出力トークン数に基づいて計算される。
コンテキストウィンドウ(Context Window)は、LLMが一度に処理できるトークン数の上限を指す。GPT-4oは128Kトークン、Claude 3.5は200Kトークンのコンテキストウィンドウを持つ。長いドキュメントを処理する際は、この制約を考慮した設計が必要となる。
2. OpenAI API
OpenAI APIは、GPTシリーズのモデルにプログラムからアクセスするためのインターフェースである。REST APIとして提供されており、Python、Node.js、その他の言語から利用可能である。LangChainを使用する前に、まずOpenAI APIの基本的な使い方を理解しておくことが重要である。
2.1 Chat Completions
Chat Completions APIは、対話形式でLLMとやり取りするための主要なエンドポイントである。メッセージの配列を入力として受け取り、アシスタントの応答を返す。
Fig 1. Chat Completions APIの基本構造
from openai import OpenAI
client = OpenAI()
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "system", "content": "あなたは親切なアシスタントです。"},
{"role": "user", "content": "Pythonでフィボナッチ数列を生成するコードを書いてください。"}
],
temperature=0.7,
max_tokens=1000
)
print(response.choices[0].message.content)
messagesパラメータには、3種類のロールを指定できる。
Table 3. メッセージロールの種類
| ロール | 説明 | 用途 |
|---|---|---|
| system | システムプロンプト | モデルの振る舞いを設定 |
| user | ユーザーの入力 | 質問や指示 |
| assistant | アシスタントの応答 | 過去の応答履歴 |
temperatureパラメータは出力のランダム性を制御する。0に近いほど決定論的(同じ入力に対して同じ出力)、1に近いほど多様な出力が得られる。コード生成やJSON出力など正確性が求められる場合は低い値(0〜0.3)、創作やブレインストーミングでは高い値(0.7〜1.0)が適している。
2.2 ストリーミング
ストリーミングは、LLMの応答をトークン単位で逐次受信する機能である。ユーザー体験の観点から、応答全体の生成を待つよりも、生成されたテキストを順次表示する方が望ましい場合が多い。
Fig 2. ストリーミングの実装例
from openai import OpenAI
client = OpenAI()
stream = client.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "user", "content": "日本の四季について説明してください。"}
],
stream=True
)
for chunk in stream:
if chunk.choices[0].delta.content is not None:
print(chunk.choices[0].delta.content, end="", flush=True)
stream=Trueを指定すると、応答はイテレータとして返される。各チャンクには生成されたテキストの断片が含まれており、これを順次処理することでリアルタイムな出力表示が実現できる。Webアプリケーションでは、Server-Sent Events(SSE)やWebSocketを使ってクライアントにストリーミング配信することが一般的である。
3. プロンプトエンジニアリング
プロンプトエンジニアリングは、LLMから望ましい出力を得るための入力(プロンプト)を設計する技術である。適切なプロンプト設計により、LLMの性能を大幅に向上させることができる。
3.1 基本原則
効果的なプロンプトを作成するための基本原則は以下の通りである。
Table 4. プロンプト設計の基本原則
| 原則 | 説明 | 例 |
|---|---|---|
| 明確性 | 曖昧さを排除し具体的に指示 | 「短く」→「100文字以内で」 |
| 構造化 | 複雑なタスクを分解 | ステップ1、ステップ2と明示 |
| 出力形式指定 | 期待する形式を明示 | 「JSON形式で出力してください」 |
| コンテキスト提供 | 必要な背景情報を与える | 対象読者、目的を明記 |
Fig 3. 構造化されたプロンプトの例
あなたはシニアソフトウェアエンジニアです。
## タスク
以下のPythonコードをレビューし、改善点を指摘してください。
## 評価観点
1. 可読性
2. パフォーマンス
3. エラーハンドリング
## コード
```python
def calc(x):
return x*x
```
## 出力形式
各観点について、問題点と改善案をJSON形式で出力してください。
3.2 Few-shot / CoT
Few-shot prompting(少数例プロンプティング)は、プロンプト内に入出力の例を含めることで、LLMに期待する振る舞いを示す手法である。例がない場合をZero-shot、1つの場合をOne-shot、複数の場合をFew-shotと呼ぶ。
Fig 4. Few-shot promptingの例
以下の形式で感情分析を行ってください。
入力: この映画は最高でした!
出力: positive
入力: サービスが悪くて残念でした。
出力: negative
入力: 普通の味でした。
出力: neutral
入力: 今日のランチはとても美味しかったです。
出力:
Chain of Thought(CoT:思考の連鎖)は、LLMに段階的な推論プロセスを促す手法である。複雑な問題を解く際に、いきなり答えを出すのではなく、思考過程を明示させることで精度が向上する。
Fig 5. Chain of Thoughtの例
問題: 太郎は1000円持っています。250円のパンを2つ買いました。残りはいくらですか?
ステップバイステップで考えてください。
回答:
1. 太郎の所持金: 1000円
2. パン1つの値段: 250円
3. パン2つの合計: 250円 × 2 = 500円
4. 残りの金額: 1000円 - 500円 = 500円
答え: 500円
「ステップバイステップで考えてください」「段階的に説明してください」といったフレーズを追加するだけでも、CoTの効果が得られる場合がある。これをZero-shot CoTと呼ぶ。
4. LLMアプリの設計パターン
LLMを業務アプリケーションに組み込む際には、いくつかの典型的な設計パターンがある。それぞれのパターンは異なるユースケースに適している。
Table 5. LLMアプリケーションの設計パターン
| パターン | 概要 | ユースケース |
|---|---|---|
| 単純呼び出し | 1回のAPI呼び出しで完結 | 翻訳、要約、分類 |
| チャット | 会話履歴を保持した対話 | カスタマーサポート、FAQ |
| RAG | 外部知識を検索して回答生成 | 社内文書検索、ナレッジベース |
| エージェント | ツールを使って自律的にタスク実行 | データ分析、自動処理 |
| パイプライン | 複数のLLM呼び出しを連鎖 | 複雑な文書処理 |
単純なAPI呼び出しであれば、OpenAI APIを直接使用するだけで十分である。しかし、会話履歴の管理、外部データソースとの連携、複数のLLM呼び出しの連鎖、エージェントの実装といった複雑な要件が生じると、コードの複雑性が急激に増加する。LangChainは、これらの複雑なパターンを実装するための抽象化とツールを提供するフレームワークである。次章以降で、LangChainの各コンポーネントについて詳しく解説する。
本コンテンツは2025年12月時点の情報に基づいて作成されています。OpenAI APIの仕様やモデルは頻繁に更新されるため、最新情報は公式ドキュメントをご確認ください。