Category: LLM

概念 一番わかりやすい比喩
LLM 予測変換の超強化版
RAG 賢い友人に資料を渡す
LoRA 専門家パッチを貼る
プロンプト 優秀な部下への指示書
hallucination 知ったかぶり
マルチモーダル 五感を持ったAI
エージェント AI秘書

🟦 1. LLM とは何か？
■ 比喩：LLM は「超巨大な辞書付きの予測文章マシン」

「LLM は “知識を持った予測変換” です。
スマホの予測変換が “次の1語” を出すのに対し、
LLM は “次の1000語” を意味の通る形で生成できます。」

🟧 2. LLM の仕組み
■ 比喩：LLM は「圧縮された世界知識 ZIP ファイル」

「インターネットの大量テキストを読み込んで、
知識を“圧縮”した巨大ZIPファイルみたいなものです。
解凍（推論）すると回答が出ます。」

図：

Web情報 ──→ 「圧縮」学習 ──→ LLMモデル（圧縮知識）
↓ 解凍
回答を生成する

🟩 3. RAG（検索拡張生成）
■ 比喩：LLM は「物知りだけど記憶力が曖昧な友人」
「LLM は賢いけど“最新情報や社内情報は知らない”。
そこで RAG を使うと、
『友人に社内の資料を渡して、読んだ上で答えてもらう』
ような動きになります。」
図：
質問 → まず資料検索 → LLM に渡す → 正確な回答

🟥 4. ファインチューニング（LoRA / PEFT）
■ 比喩：LLM に「専門家の名刺を貼り付ける」
「LoRAは大規模な脳を作り直すのではなく、
小規模な“専門性パッチ”を貼り付けて性能を変える技術です。」
図：
[巨大モデル] + [小さな追加レイヤー（専門性）] = カスタムLLM

🟦 5. プロンプトエンジニアリング
■ 比喩：LLM は「高性能な部下」
「優秀だけど指示があいまいだと迷う部下」。
だから prompt（指示）を丁寧に書くほど結果が良くなる。
例）
NG：『資料まとめて』
OK：『3点に要約して、最後に要改善ポイントを出して』

🟨 6. LLM の hallucination（幻覚）
■ 比喩：自信満々で間違ったことを言う「知ったかぶり」

「LLM は時々“もっともらしい嘘”を作ります。
理由は『文章の続きを予測する仕組み』だから。」

図：
❌：事実を理解しているわけではない
⭕：もっともらしい文章を生成する

🟧 7. モデルデプロイ（運用）
■ 比喩：料理の“厨房”
「レストランで料理を出すように、
モデルもお客さん（ユーザー）のリクエストを処理する厨房が必要。」
厨房 = inference server
ウェイター = API
客 = ユーザーアプリ

🟪 8. 推論コスト
■ 比喩：文章生成の“電気代”
「長い文章を生成すると、その分だけ電気（GPU）が必要。
つまり『よくしゃべるほど高い』。」
例：
入力1,000 tokens → 数円
長文生成5,000 tokens → 数十円になることも

🟩 9. マルチモーダル LLM
■ 比喩：人間の「五感」を持ち始めたAI
「文字だけでなく、画像・音声・動画など
いろんな感覚を“読める・理解できる”モデルです。」
図：
画像 → 説明
音声 → 文字起こし
ファイル → 要約

🟦 10. エージェント型 LLM
■ 比喩：自律的に動く「AI秘書」
「LLM がツール操作（検索・計算・翻訳）を組み合わせて、
自動で目的を達成します。」

例：
Slack メッセージを読んで → 要約して → カレンダー調整
Web検索して → レポート作成

LLM の モニタリング（監視） & 評価基盤 は、LLM アプリを安定運用するうえで必須です。
しかし「何を測ればよいか？どう設計するか？」が分かりにくいので、ここでは 基本概念 → 監視すべき指標 → 評価方法 → 実装例 → 最低限の構成 を、プロダクション経験ベースでまとめます。

🧭 1. なぜ LLM のモニタリングが必要か
LLM アプリは従来のAPIと違い、確率的で、コストが高く、品質が揺れるため、以下が発生します：
品質劣化（アップデートで回答が変わる）
幻覚（hallucination）増加
レイテンシが不安定（ピーク時間、高負荷バッチ）
API コストの急増（ユーザ増加、不必要なリクエスト）
ユーザ行動による prompt の悪化
モデル変更による regressions（品質後退）
→ つまり「品質 × コスト × 安定性」を可視化して、
問題を自動で発見できる状態にすることが目的です。

🎯 2. モニタリングすべき指標（必須 + 追加）
🔥 必須（LLM の “健康状態”）
① レイテンシ
p50 / p90 / p95 / p99
prefill（入力処理）/ decode（生成処理）の分離計測
（vLLM などでは prefill がボトルネック）

② トークン使用量
入力トークン（prompt_tokens）
出力トークン（completion_tokens）
合計 tokens/request
→ コスト最適化に直結

③ コスト
cost_per_request
daily_cost
model別コスト
→ アラート設定（例：1日$20超えたら通知）

④ エラー率
API エラー
タイムアウト
リトライ状況
→ レイテンシ異常の早期発見に必要

🧠 品質指標（最重要）
⑤ ユーザ満足度（explicit / implicit）
👍👎 のフィードバック
返答内容の採用率 (“answer accepted”)
再質問率（re-ask rate）

⑥ LLM-as-a-judge による自動品質評価
モデル自身で評価する手法。
例：「この回答はユーザ質問に正確に答えているか？ 1〜5で採点せよ。」

評価軸例：
usefulness
correctness
harm / safety
hallucination score
style consistency

⑦ 目標タスク特化の自動評価（RAG/QA など）
RAG：groundedness（出典との整合性）
QA：exact match / F1
要約：faithfulness / conciseness
会議議事録：情報欠落率

🧩 RAG 特有の指標（RAG を使うなら必須）
Retrieval hit-rate（正しいドキュメントが取得されたか）
コサイン類似度分布
chunk 取得数の分布
recall@k
hallucination index（回答に出典が含まれる率）

🏗️ 3. 評価基盤の構成（4層）
[1] ログ収集層
　LLM 呼び出しログ、tokens、latency、prompt、response

[2] データレイク層
　Athena, BigQuery, S3, PostgreSQL など

[3] 評価層
　・LLM-as-a-judge（自動評価）
　・ユーザフィードバック分析
　・品質テスト（regression test）
　・RAG の retrieval 評価

[4] 可視化/アラート層
　Grafana / Kibana / Metabase / Looker

🛠️ 4. 具体的なログフォーマット例（おすすめ）
{
“timestamp”: 1712345678,
“user_id”: “abc123”,
“model”: “gpt-4o-mini”,
“prompt”: “会議の議事録を要約してください”,
“response”: “要約：…”,
“prompt_tokens”: 243,
“completion_tokens”: 89,
“latency_ms”: 1130,
“error”: null,
“rating_user”: null,
“rating_llm”: {
“usefulness”: 4,
“correctness”: 5,
“groundedness”: 3
}
}

→ prompt / response は別ストレージに分離保存する（情報漏洩リスク対策）。

📊 5. 可視化ダッシュボードの例（Grafana）
最低限以下のメトリクスを表示：

◆ 時系列
cost/day
tokens/day
latency (p95)
error rate
user satisfaction

◆ ヒートマップ
RAG の類似度分布
ユーザ行動（どの prompt が最もコストを増やしているか）

◆ テーブル
リクエスト上位の prompt
コストの高いプロンプト
評価低スコアの回答

🔍 6. 自動評価（LLM-as-a-judge）の例
例：回答品質を自動採点
judge_prompt = f”””
以下のユーザ質問とAI回答の品質を評価してください。

[質問]
{question}

[AI回答]
{answer}

以下の項目を1〜5で採点し、JSONで返してください。
– correctness（正確性）
– helpfulness（有用性）
– logical_consistency（論理的一貫性）
– hallucination（幻覚の少なさ）※少ないほど高得点
“””

→ モデルに評価を返させる。
→ 毎日/毎週のモデルの品質変動を数値化できる。

🧪 7. 回帰テスト（Regression Test）
「モデル変更で品質が下がってないか？」を自動チェックする仕組み。

例）
代表質問セット（100〜300問）
様々な prompt パターン
正解または期待動作があるケース
評価方法：
EM（Exact Match）
similarity（回答文の埋め込み類似度）
LLM-as-a-judge スコア差分

🧰 8. 最低限これだけあれば OK（スターター構成）
✔ ① 呼び出しログ（DBに保存）
prompt_tokens, completion_tokens
latency
model
error
✔ ② 可視化（Metabase / Grafana）
日次トークン量、日次コスト
p95 latency
error 率

✔ ③ ユーザの thumbs up/down
回答の直接品質

✔ ④ 代表質問セット（回帰テスト）
モデル更新時の品質チェック

🌟 さらに進めると…
LLM Guardrails（安全性検査）
異常検知（急激なコスト増・hallucination spike）
prompt 最適化の自動探索（prompt tuning ops）
retriever の self-monitoring（RAG で重要）

LLM（大規模言語モデル）の推論コスト最適化は、モデルの選択・技術的最適化・利用方法の工夫という複数の側面からアプローチできます。推論コストは主に使用するトークン数と計算リソース（GPUなど）の使用量に依存します。

主な最適化の手法は以下の通りです。
💡 モデルとアーキテクチャの最適化
1. 軽量なモデルの活用
モデルサイズの最適化:
より軽量なオープンソースLLMや、特定のタスクに特化した小規模なモデルを選択することで、必要な計算リソースとメモリ使用量を削減し、推論コストを大幅に抑えることができます。
蒸留（Knowledge Distillation）:

**高性能な大規模モデル（教師モデル）の知識を、より小さなモデル（生徒モデル）**に転移させることで、高い性能を保ちつつ、推論コストを削減します。

2. 量子化（Quantization）
モデルのパラメータを表現するのに必要なビット数を減らす（例：32ビット浮動小数点数から8ビット整数へ）ことで、モデルのサイズを縮小し、メモリ帯域幅の要求を下げます。これにより、GPUメモリの使用量を削減し、推論の高速化とコスト削減につながります。

⚙️ 技術的な推論処理の最適化
3. KVキャッシュの最適化
トランスフォーマーモデルは、新しいトークンを生成するたびに、過去のトークンのKeyとValueを再計算する必要があります。これをメモリにキャッシュし再利用することで、計算コストを削減します。

Paged Attentionなどの技術でKVキャッシュのメモリ管理を効率化し、より大きなバッチサイズでの処理（スループット向上）を可能にします。

4. 推論インフラ・リソースの効率化
バッチ処理（Batching）: 複数のリクエストをまとめて同時に処理することで、GPUの使用率を最大化し、全体のスループットを向上させます。

投機的デコーディング（Speculative Decoding）: 小さくて高速なモデルで次のトークン候補を予測し、それを大規模モデルでまとめて検証することで、デコードのレイテンシ（応答時間）を大幅に短縮します。

GPUリソースの管理:

オンプレミスまたはクラウド（AWS, GCPなど）のGPUリソースについて、利用しない時間帯はインスタンスを停止するなど、使用状況に応じた適切なスケーリングを行うことで無駄なコストを削減します。

📝 利用方法・プロンプトの最適化
5. プロンプトの最適化
トークン使用量の削減:

LLM APIを利用する場合、入力・出力のトークン数が課金対象となるため、プロンプトを簡潔に保つことが直接的なコスト削減につながります。

短いプロンプトで適切な回答が得られるよう、プロンプトの設計を工夫します。

キャッシングの活用:
同じ質問や計算結果に対する過去の回答をキャッシュし、再利用することで、LLMへの不要なAPIリクエストや再計算を防ぎます。

6. RAG（検索拡張生成）の活用
RAGは、質問に関連する情報（ナレッジベースなど）を検索し、その情報をプロンプトに含めてLLMに入力する手法です。

これにより、LLMが大量の知識を記憶する必要がなくなり、軽量なモデルでも特定のタスクで高い精度を達成しやすくなります。

LLMの計算負荷を検索システムに分散させることで、結果的に推論コストを削減できます。

– 教師ありデータを作成する(gptで生成)
– Llama 3.1（8Bパラメータ版でも）をLoRAでファインチューニング
(GPUでも異常に時間がかかる)

Llama 3.1 × LoRA の流れ
ベースモデル読み込み（4bit量子化）
LoRA 設定（r=16 など）
指示データを用意（chat形式）
学習（300ステップくらい）
LoRA アダプタ保存（数十MB）
Base + LoRA で推論

これで 社内特化 LLM・商品説明特化 LLM・カスタマーサポート LLM

. 準備（必要なライブラリ）

Google Colab なら下記だけで準備OK：

!pip install transformers accelerate peft bitsandbytes datasets

2. ベースモデルを決める（例：Llama 3.1 8B）

軽くて実用的な LLama の OSS モデル：

meta-llama/Meta-Llama-3.1-8B

3. 学習データの形式

LoRA は「教師データ」が **指示形式（instruction format）」だと最も効果が出ます。

例：JSONL（1行1サンプル）
{“instruction”: “社内VPNの再接続方法を教えて”, “response”: “設定→ネットワーク→VPN→再接続ボタンを押すだけです。”}
{“instruction”: “見積書を再発行するには？”, “response”: “営業管理システムで案件番号を検索し、PDFを再生成できます。”}

例：ChatML 形式（最近はこちらが主流）
{
“messages”: [
{“role”: “user”, “content”: “返品の受付方法を教えて”},
{“role”: “assistant”, “content”: “返品受付画面で注文番号を入力し、ステータスを「返品受付」に変更します。”}
]
}

4. LoRA 設定（PEFT）
from peft import LoraConfig

lora_config = LoraConfig(
r=16, # Rank（一般的に 8 / 16）
lora_alpha=32,
lora_dropout=0.05,
bias=”none”,
task_type=”CAUSAL_LM”
)

5. モデル読み込み（4bit 量子化＝QLoRA）

4bit QLoRA の標準書き方：

from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

model_name = “meta-llama/Meta-Llama-3.1-8B”

model = AutoModelForCausalLM.from_pretrained(
model_name,
torch_dtype=torch.bfloat16,
quantization_config={“load_in_4bit”: True},
device_map=”auto”
)

tokenizer = AutoTokenizer.from_pretrained(model_name)
tokenizer.pad_token = tokenizer.eos_token

これで GPU 8GB でも Llama3.1-8B を微調整できる状態になります。

6. データセット読み込み
from datasets import load_dataset
dataset = load_dataset(“json”, data_files=”train.jsonl”)

7. 学習データの前処理（プロンプト生成）
def format_chat(example):
messages = example[“messages”]

text = tokenizer.apply_chat_template(
messages,
add_generation_prompt=False
)
return {“text”: text}

dataset = dataset.map(format_chat)

8. Trainer で LoRA 学習開始
from transformers import TrainingArguments, Trainer
from peft import get_peft_model

peft_model = get_peft_model(model, lora_config)

args = TrainingArguments(
output_dir=”llama-lora”,
per_device_train_batch_size=1,
gradient_accumulation_steps=16,
warmup_steps=10,
max_steps=300, # 100～500 で充分効果出る
learning_rate=2e-4,
fp16=True,
logging_steps=10,
save_steps=100,
)

def collate(batch):
return tokenizer(batch[“text”], padding=True, truncation=True, return_tensors=”pt”)

trainer = Trainer(
model=peft_model,
args=args,
train_dataset=dataset,
data_collator=collate
)

trainer.train()

9. 結果の保存（LoRA のみ数十 MB）
peft_model.save_pretrained(“lora-out”)

出力されるのは adapter_config.json / adapter_model.bin
→ 30〜100MB 程度で Llama 3.1 がカスタムモデルになります。

10. 推論（本番利用）
from peft import PeftModel

base = AutoModelForCausalLM.from_pretrained(model_name, device_map=”auto”)
model = PeftModel.from_pretrained(base, “lora-out”)

prompt = “社内VPNに接続できない時の対処方法は？”
inputs = tokenizer(prompt, return_tensors=”pt”).to(“cuda”)

output = model.generate(**inputs, max_new_tokens=200)
print(tokenizer.decode(output[0], skip_special_tokens=True))

LLM の 合成データ生成（Synthetic Data Generation） と
自己学習（Self-learning / Self-Improvement） は、
近年の LLM 開発の中で最も重要な技術の一つ

. 合成データ生成とは？（Synthetic Data）
簡単に言うと：

LLM が 自分自身で学習用データ（QA・文章・会話など）を作る 技術です。
🎯 なぜ重要なのか？
人間がデータを作ると コストが高い
高品質な人間教師データ（instruction data）が不足している
誤解や偏りがない、LLM学習に最適化されたデータが必要

そこで LLMが自分でデータを生成 → それをまた学習に使う
という循環が作られています。

自己学習（Self-learning / Self-Training）とは？
LLM が “自分で作ったデータ” を使って、さらに賢くなる仕組み

以下のようなプロセスです：

① 既存LLM（Teacher）がデータを生成（合成データ）
② 新しいLLM（Student）がそれを学習
③ Student が Teacher に近づいたり追い越したりする
④ Student を Teacher として活用 → また合成データ生成

これは Self-Play（自己対戦） や Self-Supervision（自己教師） とも呼ばれます。

合成データ生成の代表的な方法
① Self-Instruct（セルフ・インストラクト）

LLM が自分に「学習するタスク」を作り出す。

例：

「役立つ指示文を20個作って、それぞれ適切な回答を生成して」

→ 指示（instruction）と回答（output）のペアが大量にできる
→ これを学習すると ChatGPT のような「指示に強いモデル」が作れる
Google・Meta・Stability・OpenAI が使う一般的手法。

Reject Sampling（不良回答の排除）

LLM に複数回答を出させ、
「良い回答だけを採用し、悪い回答は捨てる」仕組み。

例：
Model → A案, B案, C案 を生成
Judge（別モデル or 同じモデル）が評価
AとCは不採用、Bだけ学習に使う
→ これにより合成データの品質が爆上がりする
最新の GPT-4o/DeepSeek にも使われている。

Self-Rewarding（自分で評価して学習）

モデル自身が回答の良し悪しを評価し、そのスコアを使って学習する。

OpenAI の研究
“Self-Rewarding Language Models”（2024）
で注目された方式。

Distillation（蒸留）

教師（Teacher）モデル → 弟子（Student）モデルへ知識を移す。
❶ Teacher で大量の合成データを生成
❷ Student がそれを学習
❸ 小型モデルでも高性能に！
例：
LLaMA → Mistral
GPT-4 → GPT-4o mini
Gemini Pro → Gemini Flash

from openai import OpenAI
client = OpenAI()

tasks = [
    "AI とは何か小学生にもわかるように説明してください。",
    "営業メールを丁寧な文体に書き直してください。",
    "Python のデコレーターを例付きで解説してください。"
]

synthetic_dataset = []

for task in tasks:
    res = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": task}]
    )
    answer = res.choices[0].message.content
    synthetic_dataset.append({"instruction": task, "output": answer})

print(synthetic_dataset)

. 合成データは実務でどう使われる？
✔ ① 社内チャットボットの学習データ生成

例：

社内規定の QA を権威ある文書から合成

人間が 1ヶ月かかる1000問データを数分で生成

✔ ② カスタマーサポートの学習データ

FAQ → 指示文化 → 例文生成 → 自動生成

✔ ③ 特定業界に特化した LLM の構築（金融・法律・医療）
✔ ④ 小型モデルの強化（LLM distillation）
⚠️ 6. 合成データの注意点
問題 説明
幻覚（hallucination） LLM が嘘を生成し、それを学習すると悪循環
バイアス 教師モデルの偏見や癖がそのままコピーされる
権利問題 合成データでも、元の学習データに依存する

→ 解決法：Reject Sampling、Human-in-the-loop、評価基準導入

🧠 7. 自己学習が今後どう進化する？

現在の最先端：

✔ Self-Play × 合成データ × Reasoning（推論強化）

OpenAI o1 モデル系（深い推論）

DeepSeek-R1（自己学習で強化）

Google Gemini 2.0（マルチステップ推論）

未来像は…

🧩 AI が 自分で作った問題 → 自分で解き → 自分で改善

という 完全自律型学習 に近づくこと。

エージェント型 LLM（LLM Agents）は、
「LLM に“考えさせて→行動させる”仕組みを加えたもの」 です。

ChatGPT のような「入力 → 出力」だけの LLM ではなく、
自分で計画を立て、情報を集め、ツールを使い、最終回答を作る“自律的なシステム” に近づきます。

1. LLM エージェントとは？（最も簡単な定義）
LLM エージェント = LLM + Tool + Memory + Reasoning
要素 役割
LLM（大規模言語モデル） 頭脳。計画・判断・生成をする
Tool（外部ツール） 検索、計算、API 呼び出し、データベースなど
Memory（記憶） 会話履歴やユーザ設定の保存（短期・長期）
Reasoning（推論） 目的を分解し、必要なステップを考える

人間と同じように「目的を達成する」仕組みを持つ LLM がエージェントです。

2. “エージェント型 LLM” でできること
① 自律タスク実行
例：メールを読み → 締切を見つけ → カレンダーに入れる

② 外部ツールの利用
Google検索
SQL 実行
Python 計算
API の呼び出し など

③ 情報収集 → 判断 → 行動
RAG（検索）
Web 操作（例：自動ログインして情報取得）
データ分析 → グラフ作成

④ 複雑タスクの分解
“旅行プランを作る”
→ ホテル検索 → 比較 → 予算計算 → プラン生成

🧩 3. 技術構造のイメージ（全体図）
┌───────────┐
│ LLM（頭脳） │
└─────┬─────┘
│ 推論（ReAct / o1 reasoning）
┌─────▼─────┐
│ Agent Policy │ ← どのツールを使うべきか判断
└─────┬─────┘
┌─────▼─────┐
│ Tools │ ← 検索 / 計算 / 実行
└─────┬─────┘
▼
メモリ / DB など

🔧 4. エージェントで使われる代表的な方式
■ ① ReAct（Reasoning + Acting）方式
LLM が「思考」と「行動」を交互に行う。
Thought: 情報が足りないので検索が必要
Action: search(“LLM エージェントとは”)
Observation: 検索結果が返ってきた
Thought: これを要約しよう
Final Answer: …
→ GPT-4 以降のエージェントフレームワークの定番。

■ ② Tool Calling（ツール呼び出し）方式
ChatGPT や OpenAI API の
function calling（tool calling） で、LLM が API を使い分ける。

{
  "tool": "search_google",
  "arguments": {
    "query": "東京駅 ランチ おすすめ"
  }
}

■ ③ Planning（計画生成）方式
大きなタスクを分割し、実行順序を決める。
例：
「YouTube の台本を作る」
↓
テーマ調査
競合動画の分析
構成案
台本作成
推奨サムネ案

🧪 5. Pythonでの“最小エージェント”サンプル
※ OpenAI gpt-4o を使用

from openai import OpenAI
client = OpenAI()

def search_google(query):
    return f"『{query}』を検索した結果（ダミー）"

tools = [
    {
        "type": "function",
        "function": {
            "name": "search_google",
            "description": "Google検索を実行",
            "parameters": {
                "type": "object",
                "properties": {
                    "query": {"type": "string"}
                },
                "required": ["query"]
            }
        }
    }
]

prompt = "LLMエージェントとは何か要点を調べて説明して"

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": prompt}],
    tools=tools,
)

# ツール呼び出しか確認
msg = response.choices[0].message
if msg.tool_calls:
    call = msg.tool_calls[0]
    if call.function.name == "search_google":
        result = search_google(call.function.arguments["query"])
        # LLM に戻す
        final = client.chat.completions.create(
            model="gpt-4o",
            messages=[
                {"role": "user", "content": prompt},
                {"role": "assistant", "tool_calls": msg.tool_calls},
                {"role": "tool", "tool_call_id": call.id, "content": result},
            ]
        )
        print(final.choices[0].message["content"])
else:
    print(msg["content"])

🚀 6. LLMエージェントの代表的なフレームワーク
フレームワーク特徴LangChain最も有名。ツール統合・エージェント実装が豊富LlamaIndexRAG 系に強い。データ接続が簡単OpenAI Assistants API超簡単にエージェント構築可能Microsoft AutoGenマルチエージェント（複数AIが協働）

🧠 7. エージェント型 LLM の強み
✔ 自動化
→ 情報収集、検索、分析、報告書生成まで自動でやる
✔ データ統合が得意
→ RAG + ツールで「会社のナレッジ → 即時回答」
✔ 高い拡張性
→ 必要に応じてツール追加が可能

🧩 8. どんなアプリに使われている？
AI カスタマーサポート
社内ナレッジ検索（RAG）+ エージェント
自動メール返信
Web リサーチ bot
自動議事録 → 要約 → タスク化
データ分析 bot（SQL + プロット）
AI 事務アシスタント

🎉 最後に
エージェント型 LLM は 「ただのチャットボット」から “AIアシスタント” に進化させるための重要技術 です。

画像 → 理解 → テキスト回答 の最小構成

from openai import OpenAI
import base64

client = OpenAI()

# 画像ファイルを base64 化
with open("image.jpg", "rb") as f:
    img_base64 = base64.b64encode(f.read()).decode("utf-8")

# マルチモーダル（画像 + テキスト）問い合わせ
response = client.chat.completions.create(
    model="gpt-4o",   # または gpt-4o-mini
    messages=[
        {"role": "user", "content": [
            {"type": "text", "text": "この画像を説明してください。"},
            {
                "type": "image_url",
                "image_url": {
                    "url": f"data:image/jpeg;base64,{img_base64}"
                }
            }
        ]}
    ]
)

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

何が起きているか？
1. 画像を base64 でエンコード
OpenAI API ではファイルアップロードせず、そのまま Base64 で画像を送れる。

2. messages に「画像 + テキスト」を混在させる
{“type”: “image_url”, …} を入れることでマルチモーダルの入力が可能になる。

3. gpt-4o が画像を理解し、テキストで返す
画像認識モデル + 言語モデルが統合されているため、追加設定不要。

1. Models（モデル）
LLM や Embedding、画像モデルなど 外部AIモデル を扱うためのモジュール。

含まれる内容
Large Language Models（OpenAI, Anthropic, Azure, HuggingFace など）
ChatModels（チャット用インターフェース）
Embeddings（ベクトル化）
Text-to-Speech / Speech-to-Text
Vision Models

学べること
「複雑な API 呼び出しを、統一的なインターフェースで扱える」

例えば OpenAI と HuggingFace のモデルを同じコードスタイルで使えるようになる。

from langchain_community.llms import HuggingFaceHub
llm = HuggingFaceHub(repo_id=”mistralai/Mistral-7B-Instruct-v0.2″)

2. Prompts（プロンプト）
LLM に渡す指示文を構築・生成・管理する部分。
できること
Prompt Templates（テンプレート化）
Few-shot の自動選択
パラメータ差し込み
出力フォーマット強制（JSON化など）

学べること
「プロンプトをコードとして管理する仕組み」
from langchain.prompts import PromptTemplate

prompt = PromptTemplate.from_template(“要約して: {text}”)
prompt.format(text=”これはテスト文です”)

3. Chains（チェーン）
LLM・ツール・データ処理を パイプラインとしてつなぐ仕組み。
代表例
LLMChain
SequentialChain（複数ステップ実行）
SimpleSequentialChain
学べること

LLM → 加工 → LLM という流れを組み立てる。

from langchain.chains import LLMChain
chain = LLMChain(llm=llm, prompt=prompt)
chain.run(“こんにちは”)

4. Agents（エージェント）
LLM が “自分でツールを選んで使う” 仕組み。
LangChain の最も特徴的な部分。
エージェントでできること
ツール使用（検索、計算、API呼び出し）
思考の分岐（ReAct）
マルチステップ問題解決
学べること
AI に “行動する力” を与える方法。

agent = initialize_agent(
tools=[search_tool, calculator],
llm=llm,
agent=”zero-shot-react-description”,
)
agent.run(“東京の天気を調べて摂氏で教えて”)

5. Retrieval（RAG：検索 + LLM）
外部データを読み込んで検索させる仕組み。
企業で一番使われるのがこれ。
主な機能

VectorStores（Chroma, Pinecone, Qdrant, FAISS）
Document loader（PDF, HTML, Notion, URL）
Retriever（検索器）
RAG チェーン全般

学べること

大量の社内文書を元に答えるチャットボットの実装方法。

from langchain.vectorstores import Chroma
db = Chroma.from_texts(texts, embeddings)
retriever = db.as_retriever()