はじめに

SNSでよく見かける投稿があります。

「AIに質問したけど、期待と全然違う答えが返ってきた。使えない」
「ああ言えばこう言うのに、求めているコードが出せない。性能が悪い」

本当にAIの性能が悪いのでしょうか？
それとも、使い方の問題でしょうか？

実は、どちらも正しくて、どちらも間違っています。

この記事では、「AIが使えない」問題を2つの側面から解説します：

対話で解決できる問題：質問の仕方、コミュニケーションの改善
対話では解決できない問題：汎用LLMの構造的限界と、適切な道具の選び方

Part 1: 対話で解決できる問題

情報の非対称性

まず理解すべきは、あなたとAIの間には大きな情報の差があるということです。

あなたの頭の中：

解決したい問題の全体像
技術スタック、パフォーマンス要件、既存コードの制約
なぜそれを求めているか（背景・文脈）
過去の設計判断、プロジェクトの慣習
期待する答えのイメージ

AIが見えているもの：

あなたが言葉にした部分だけ
一般的なパターンからの推測
学習データに基づく確率的な選択

このギャップが、「期待と違う答え」を生み出します。

実例：人間同士でも起こる問題

これは人間同士でも同じです。

ベテランが新人に指示：
「この処理、改善しといて」

新人の心の声：

何を改善？パフォーマンス？可読性？保守性？
どこまでやっていい？既存の関数使う？新規実装？
他のコードとの整合性は？命名規則は？
テストも書く？

でも質問できない：

「こんなこと聞いたら怒られる？」
「常識として知ってるべき？」

→ 推測で実装 → 期待と違う → やり直し

AIも全く同じ構造です。ただしAIには「質問を躊躇する」という心理的障壁はありません。しかし多くのAIは「推測して即座に答える」ように設計されているため、結果的に同じ問題が起こります。

効果的な対話の3つの原則

1. 前提・制約を明示する

❌ 悪い例：

「この処理を改善して」

✅ 良い例：

「既存のハッシュテーブル構造を維持したまま、
検索パフォーマンスをO(n)からO(1)に改善したい。
メモリ制約は1GB以内で、スレッドセーフである必要がある」

2. AIに選択の理由を説明させる

「なぜそのアプローチを選んだのか、理由を説明して」

→ AIの推測プロセスが可視化される
→ ズレがあればそこで修正できる
→ あなた自身の理解も深まる

3. 対話で精度を上げる

間違った期待：

1回の質問で完璧な答えを得る
AIが「察して」正解を出す

正しい理解：

最初の回答は「たたき台」
フィードバックで方向修正
対話を重ねて精度を上げる
人間同士のコードレビューと同じプロセス

AIに「選択肢を聞く」技術

パターン1: AIに白紙委任しない

❌ 悪い例：

「最適な方法を教えて」

✅ 良い例：

「A（ハッシュテーブル）とB（ソート済み配列＋二分探索）の方法があるが、
このケース（100万件のデータ、検索頻度が高い、更新は少ない）では
どちらが適切か？理由も含めて」

パターン2: 不明点を洗い出してもらう

「この要件で実装する前に、確認すべき点を列挙して」

→ 自分が見落としていた情報が見えてくる
→ 要件定義の抜け漏れチェックになる

パターン3: トレードオフを明示してもらう

「この実装の利点と欠点、代替案を3つ挙げて」

→ 選択肢が見える
→ 意思決定の材料が揃う

「使える活用」と「使えない嘆き」の分岐点

使えないと嘆く人の思考パターン：

曖昧な質問をする
期待と違う答えが返る
「AIは使えない」と結論づける
終了

効果的に使える人の思考パターン：

できるだけ明確な質問をする（完璧じゃなくてもOK）
AIの回答を見て、ズレに気づく
「なぜそう答えたの？」「他にどんな選択肢がある？」と聞く
フィードバックして方向修正
対話を重ねて精度を上げる
期待に近い答えを得る

差は：対話をプロセスとして捉えているかどうか。

Part 2: 対話では解決できない問題

ここまでは「対話のスキル」で解決できる話でした。

しかし、対話だけでは根本的に解決できない問題もあります。

あなたは「専門家」である

例えば、あなたが20年のC言語実務経験を持つエンジニアだとします：

数千のプロジェクトを経験
エッジケースの知識が膨大
パフォーマンスチューニングの勘所
特定ドメイン（組み込み、金融、医療など）の制約に精通
暗黙知の蓄積

一方、汎用LLM（ChatGPT、Claude、Geminiなど）は：

インターネット上の一般的な知識で学習
Stack Overflowの頻出パターンに強い
教科書的な実装が得意
特定ドメインの深い知識は薄い

ギャップ：

あなた：「このケースなら、メモリアライメントを考慮してこうすべきだろう」
汎用AI：「一般的にはこうです」
あなた：「全然わかってない！使えない！」

これは質問の仕方の問題ではありません。
AIに「知識がない」のです。

汎用LLMの構造的限界

1. 学習データの偏り

メジャーな分野：Python、JavaScript、機械学習 → 豊富な学習データ
ニッチな分野：レガシーシステム、特定ドメインの専門知識 → データ不足
最新情報：学習データのカットオフ（例：2023年4月）以降の情報は知らない

2. ドメイン固有知識の不足

業界特有の慣習、規制、コンプライアンス
プロジェクト固有の設計方針、アーキテクチャ
組織内の暗黙知、過去の意思決定の経緯

3. コンテキスト長の限界

プロジェクト全体のコードベース（数万〜数十万行）を一度に渡せない
過去の設計判断の経緯を全て説明しきれない
会話の履歴も一定量を超えると古い部分が忘れられる

Part 3: 解決策 - 道具を正しく選ぶ・作る

では、汎用LLMの限界をどう克服するか？

アプローチ1: RAG（Retrieval-Augmented Generation / 検索拡張生成）

何が解決するか

汎用LLMに「あなたの専門知識」を渡すことができます。

仕組み：

質問
  ↓
関連情報をベクトルDBから検索
  ↓
検索結果 + 質問 をLLMに渡す
  ↓
LLMが「手元の情報」として回答生成

具体例

社内ドキュメントをベクトルDB化
- 設計書、議事録、過去のトラブルシューティング記録
- PDF、Markdown、Wikiなどを埋め込みベクトルに変換
質問に関連する部分だけを抽出
- 質問「認証エラーの対処法は？」
- → 過去の認証関連トラブル事例を検索
LLMに渡す
- 「以下の過去事例を参考に回答してください：[検索結果]」
- LLMは一般知識 + 検索結果で回答

各LLMでの実装例

⚠️ 重要：API利用とプログラミングが必要

以下の実装例は、LLMのAPIをプログラムから呼び出す方法です。
ChatGPTやClaude.aiのようなWebブラウザでの対話型インターフェースでは利用できません。

必要なスキル：

プログラミング（Python推奨）
API キーの取得と管理
ベクトルDBの構築（Chroma、Pinecone等）
LangChain/LlamaIndexなどのフレームワーク

Webベースの対話型LLMでRAGっぽいことをする代替手段：

もしプログラミングせずにWebブラウザだけで使いたい場合、以下の方法があります：

ChatGPT（Web版）：
- ファイルアップロード機能で、関連ドキュメントをアップロード
- コンテキストに含めて質問
- 制限：ファイルサイズ、会話ごとにアップロードが必要
Claude.ai（Web版）：
- プロジェクト機能で、ドキュメントを追加
- プロジェクト内で質問すると、ドキュメントを参照
- 制限：プロジェクトごとの容量制限
手動でコンテキストに貼り付け：
- 関連部分を手動でコピペして質問
- 最も原始的だが、すぐに試せる
- 制限：コンテキスト長、手間がかかる

これらは「簡易版RAG」であり、完全なRAGではありません：

自動検索ができない
大量のドキュメントは扱えない
ベクトル検索による高精度な情報抽出は不可

本格的なRAGを実装するには、以下のAPI利用例が必要です。

実際にRAGで検索結果をLLMに渡す方法を、各LLMのAPI別に紹介します。

1. OpenAI API（ChatGPT）での実装

from openai import OpenAI

client = OpenAI(api_key="your-api-key")

# ベクトルDBから検索した関連ドキュメント
retrieved_docs = """
【過去事例1】認証エラー: JWTトークンの有効期限切れ
解決方法: リフレッシュトークンを使って再取得

【過去事例2】認証エラー: 署名検証失敗
解決方法: 公開鍵が古い場合は最新の鍵をダウンロード
"""

# ユーザーの質問
user_question = "認証エラーが出ます。どう対処すればいいですか？"

# RAGパターン: システムメッセージで検索結果を渡す
response = client.chat.completions.create(
    model="gpt-4-turbo",
    messages=[
        {
            "role": "system",
            "content": f"以下の過去事例を参考に回答してください:\n\n{retrieved_docs}"
        },
        {
            "role": "user",
            "content": user_question
        }
    ]
)

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

2. Anthropic API（Claude）での実装

import anthropic

client = anthropic.Anthropic(api_key="your-api-key")

# ベクトルDBから検索した関連ドキュメント
retrieved_docs = """
【過去事例1】認証エラー: JWTトークンの有効期限切れ
解決方法: リフレッシュトークンを使って再取得

【過去事例2】認証エラー: 署名検証失敗
解決方法: 公開鍵が古い場合は最新の鍵をダウンロード
"""

# ユーザーの質問
user_question = "認証エラーが出ます。どう対処すればいいですか？"

# RAGパターン: ユーザーメッセージに検索結果を含める
message = client.messages.create(
    model="claude-3-5-sonnet-20241022",
    max_tokens=1024,
    messages=[
        {
            "role": "user",
            "content": f"""以下の過去事例を参考に、質問に答えてください。

<retrieved_documents>
{retrieved_docs}
</retrieved_documents>

<question>
{user_question}
</question>"""
        }
    ]
)

print(message.content[0].text)

3. Google AI（Gemini）での実装

import google.generativeai as genai

genai.configure(api_key="your-api-key")
model = genai.GenerativeModel('gemini-pro')

# ベクトルDBから検索した関連ドキュメント
retrieved_docs = """
【過去事例1】認証エラー: JWTトークンの有効期限切れ
解決方法: リフレッシュトークンを使って再取得

【過去事例2】認証エラー: 署名検証失敗
解決方法: 公開鍵が古い場合は最新の鍵をダウンロード
"""

# ユーザーの質問
user_question = "認証エラーが出ます。どう対処すればいいですか？"

# RAGパターン: プロンプトに検索結果を含める
prompt = f"""以下の過去事例を参考に、質問に答えてください。

過去事例:
{retrieved_docs}

質問: {user_question}
"""

response = model.generate_content(prompt)
print(response.text)

4. ローカルLLM（Ollama）での実装

import requests

# ベクトルDBから検索した関連ドキュメント
retrieved_docs = """
【過去事例1】認証エラー: JWTトークンの有効期限切れ
解決方法: リフレッシュトークンを使って再取得

【過去事例2】認証エラー: 署名検証失敗
解決方法: 公開鍵が古い場合は最新の鍵をダウンロード
"""

# ユーザーの質問
user_question = "認証エラーが出ます。どう対処すればいいですか？"

# RAGパターン: システムプロンプトで検索結果を渡す
response = requests.post(
    'http://localhost:11434/api/chat',
    json={
        "model": "llama3.2",
        "messages": [
            {
                "role": "system",
                "content": f"以下の過去事例を参考に回答してください:\n\n{retrieved_docs}"
            },
            {
                "role": "user",
                "content": user_question
            }
        ]
    }
)

print(response.json()['message']['content'])

実装のポイント：

検索結果の渡し方：システムメッセージ、ユーザーメッセージ、プロンプト内包など、LLMによって最適な方法が異なる
構造化：XMLタグ（Claude）や明確な区切りで、検索結果と質問を区別
コンテキスト長制限：検索結果が長すぎる場合は、上位N件に絞る、要約するなどの工夫が必要
LangChain/LlamaIndex：これらのフレームワークを使えば、上記の処理を自動化できる

メリット

既存のドキュメントをすぐに活用できる
汎用LLMのAPIをそのまま使える
導入が比較的容易

限界

検索精度に依存：関連情報を正しく見つけられないと意味がない
暗黙知は拾えない：ドキュメント化されていない知識は活用できない
リアルタイム性：情報を追加してもベクトル化が必要

アプローチ2: 記憶製造機（プロジェクト固有知識の蓄積）

RAGとの違い

RAG：既存ドキュメントを検索して参照
記憶製造機：対話を通じて知識を蓄積・成長させていく

仕組み（筆者のAI Vtuberプロジェクトの例）

対話から重要情報を抽出
- ユーザーとの会話、設計の意思決定、実装のコツ
- 「これは覚えておくべき」と判断した情報
エピソード記憶として保存
- SQLiteベースの記憶DB
- タイムスタンプ、重要度、カテゴリで管理
次回の対話で参照
- 類似の質問が来たら過去の記憶を検索
- 「前回こう言っていたので、今回はこうします」
長期記憶として定着
- 繰り返し参照される記憶は重要度が上がる
- 記憶の濃淡（重み付け）で優先度管理

メリット

暗黙知も蓄積：ドキュメント化されていない対話内容も記録
プロジェクトと共に成長：使えば使うほど賢くなる
個人の思考パターンを学習：あなたの好み、判断基準を理解していく

具体的な実装例

記憶製造機の詳細な設計と実装については、筆者の別記事で解説しています：

📖 関連記事：

AI VTuberに「記憶」を持たせたい - RAGを試して気づいたこと
- RAGの限界と、記憶システムが必要になった背景
- RAGと記憶製造機の違い
AI VTuberの「記憶製造機」- 構造化記憶システムの設計
- エピソード記憶、短期記憶、長期記憶の3層構造
- SQLiteベースの実装
- 記憶の濃淡（重み付け）アルゴリズム
- Pythonでの実装コード例

実装のポイント：

ローカルLLM（Ollama）+ SQLiteで実現
記憶の抽出・要約にLLMを活用
時系列と重要度で記憶を整理
エピソード記憶→短期記憶→長期記憶への昇華プロセス

アプローチ3: ローカルLLM + カスタマイズ

なぜローカル？

プライバシー：機密情報、社内データを外部に送らない
カスタマイズ性：ファインチューニング、プロンプト調整が自由
コスト：大量の呼び出しでも固定費（電気代、GPU代）

選び方

汎用モデル（Llama, Mistral, Qwenなど）：

広範な知識が必要な場合
日本語対応が必要な場合はQwen、Gemma推奨

ドメイン特化モデル：

CodeLlama：コード生成に特化
BioGPT：医療・生物学に特化
FinGPT：金融分野に特化

カスタマイズ手法

1. ファインチューニング

自社データで追加学習
専門用語、業界慣習、コーディングスタイルを学習
必要リソース：GPU（RTX 4090など）、学習データ

2. LoRA（Low-Rank Adaptation）

軽量なカスタマイズ手法
複数の「専門性」を切り替え可能
例：「C言語モード」「Python モード」「ドキュメント執筆モード」

3. システムプロンプト + RAG

ファインチューニング不要
システムプロンプトで役割を定義
例：「あなたは組み込みシステム専門の20年経験エンジニアです。メモリ効率とリアルタイム性を最優先してください」

ハードウェア要件と性能ベンチマーク

ローカルLLMを動かすには、それなりのスペックが必要です。実際の要件を把握しておきましょう。

モデルサイズ別の推奨スペック：

モデルサイズ	VRAM（GPU）	RAM	用途	推論速度（目安）
7B（小型）	8GB以上	16GB	個人開発、軽い用途	20-40 tokens/sec
13B（中型）	16GB以上	32GB	実用レベル	10-20 tokens/sec
34B（大型）	24GB以上	64GB	高精度が必要	5-10 tokens/sec
70B（超大型）	48GB以上	128GB	プロダクション	2-5 tokens/sec

推奨ハードウェア構成例：

エントリーレベル（個人開発）：

CPU：Ryzen 7 / Core i7 以上
GPU：RTX 4060 Ti 16GB / RTX 3060 12GB
RAM：32GB
ストレージ：SSD 500GB以上
予算：15〜25万円程度
動かせるモデル：7B〜13B

ミドルレンジ（実用レベル）：

CPU：Ryzen 9 / Core i9
GPU：RTX 4090 24GB / RTX A6000 48GB
RAM：64GB
ストレージ：SSD 1TB以上
予算：40〜80万円程度
動かせるモデル：13B〜34B

ハイエンド（プロダクション）：

CPU：Xeon / Threadripper
GPU：複数GPU（RTX 4090 x2、A100 80GB など）
RAM：128GB以上
ストレージ：NVMe SSD 2TB以上
予算：100万円〜
動かせるモデル：70B以上、複数モデル同時稼働

実際の性能ベンチマーク例：

筆者の環境（AI Vtuberプロジェクト）：

CPU：Ryzen 9 9950X
GPU：RTX 4060 Ti 16GB
RAM：128GB
OS：Ubuntu 24.04 LTS（WSL2）

推論速度実測：

Llama 3.2 3B：約 40 tokens/sec（CPU推論）
Llama 3.2 7B：約 25 tokens/sec（GPU推論）
Qwen 2.5 14B：約 15 tokens/sec（GPU推論）
記憶システム込みの応答時間：1〜3秒

量子化による最適化：

VRAMが不足する場合、量子化（Quantization）で軽量化できます：

FP16（無圧縮）：最高精度、VRAMを最も使う
INT8（8bit量子化）：VRAM使用量が約半分、精度はほぼ維持
INT4（4bit量子化）：VRAM使用量が約1/4、精度は若干低下
GGUF形式：CPU推論も可能、RAM上で動作

例：Llama 3.2 13B

FP16：26GB VRAM必要
INT8：13GB VRAM必要
INT4：7GB VRAM必要（RTX 4060 Tiでも動作）

Ollamaのハイブリッド推論（GPU + CPU）：

Ollamaには、VRAMを超える大きなモデルも動かせるオフローディング機能があります。

仕組み：

モデルの一部をGPU VRAM上に配置
残りをシステムRAM（CPU側）に配置
推論時に必要な部分を適宜転送

実例：

GPU：RTX 4060 Ti 16GB
RAM：128GB
→ 34Bモデルも動作可能（通常は24GB VRAM必要）
→ 70Bモデルも動作可能（通常は48GB VRAM必要）

トレードオフ：

✅ VRAM制限を超えた大きなモデルを実行できる
✅ 高価なハイエンドGPUが不要
❌ GPU-CPU間の転送時間が発生（推論速度は低下）
❌ RAMの容量が重要になる

推論速度の目安：

全てGPU上：20 tokens/sec
ハイブリッド（50% GPU + 50% RAM）：10-15 tokens/sec
ハイブリッド（30% GPU + 70% RAM）：5-10 tokens/sec

実用性：
速度は落ちますが、対話型アプリケーションなら十分実用的です。
筆者のAI Vtuberプロジェクトでも、ハイブリッド推論で運用しています。

設定方法：
Ollamaは自動的に最適な配置を判断しますが、手動で制御も可能：

# モデルの50%をGPUに配置
OLLAMA_NUM_GPU=50 ollama run llama3.2:70b

コストパフォーマンスの考え方：

「初期投資が高い」と感じるかもしれませんが：

クラウドLLMの月額コスト（5,000〜20,000円）× 12ヶ月 = 6〜24万円/年
ローカルGPU投資（20〜40万円）は1年で元が取れる可能性
電気代：RTX 4090で24時間稼働でも月2,000〜3,000円程度

特にプライバシーが重要な場合、ローカルLLMは長期的にコスト効率が良い。

アプローチ4: ドメイン特化型クラウドLLMを探す

汎用LLM（ChatGPT/Claude/Gemini）だけが選択肢ではありません。

例

コード生成特化：GitHub Copilot, Cursor, Codeium
医療特化：Med-PaLM（Google）
法務特化：Harvey AI
金融特化：Bloomberg GPT

選び方のポイント

1. 学習データの確認

どの分野のデータで学習したか？
最新情報の更新頻度は？
日本語対応の質は？

2. API/統合性

既存ツール（VSCode、Slackなど）と統合可能？
カスタマイズの自由度は？
RAGとの併用は可能？

3. コストとパフォーマンス

料金体系（トークン課金、月額固定、従量制）
レスポンス速度、スループット
無料枠、トライアル期間

トークン制限と上位プランの検討

無料プラン・最低限の課金の落とし穴：

多くのLLMサービスは無料枠や低価格プランを提供していますが、実務で使うとトークン不足に陥りやすい問題があります。

よくある制約：

月間トークン数の制限（例：無料で100万トークン/月）
レート制限（1分あたりのリクエスト数）
同時接続数の制限
レスポンスタイムの低下（優先度が低い）

実務での影響：

RAGで長い検索結果を渡すと、すぐにトークンを消費
複数メンバーで使うと、あっという間に上限に到達
制限に達すると、開発が止まる
トークンを節約しようとして、精度が落ちる

推奨アプローチ：

まず無料/低価格プランで試す
- LLMの性能、自分のユースケースとの相性を確認
- どのLLMが「合う」かを見極める
合うと思ったら、上位プランへ
- トークン制限を気にせず使える
- 開発速度が圧倒的に上がる
- 精度を犠牲にしなくて済む
プラン選択の目安：
- 個人開発：月5,000〜10,000円程度（トークン制限緩和）
- チーム開発：月20,000円〜（複数メンバー、高頻度利用）
- プロダクション：従量課金 or エンタープライズプラン

コスト vs 生産性：

「月額20,000円は高い」と感じるかもしれませんが：

トークン不足で開発が止まる時間のコスト
精度を落としたことで生じるデバッグ時間
エンジニアの時給換算

これらを考慮すると、合うLLMには適切に投資する方が長期的にはコストパフォーマンスが高いです。

節約と投資のバランス：

汎用的な質問 → 無料/低価格LLM
専門的・重要なタスク → 上位プランの特化LLM
ローカルLLMと併用して、コストをコントロール

Part 4: どう組み合わせるか

現実には、複数のアプローチを組み合わせるのが効果的です。

パターン1: 汎用LLM + RAG

向いているケース：

既存ドキュメントが豊富
機密性が低い（クラウドLLM利用可）
手軽に始めたい

構成例：

OpenAI API / Claude API
ベクトルDB（Pinecone, Weaviate, Chroma）
LangChain / LlamaIndex でRAG実装

パターン2: ローカルLLM + 記憶製造機

向いているケース：

プライバシー重視（社内データ、個人情報）
プロジェクト固有知識を蓄積したい
長期的に育てていきたい

構成例（筆者のAI Vtuberプロジェクト）：

ローカルLlama（Ollamaで管理）
SQLiteベースの記憶DB
記憶の濃淡システム（重要度による重み付け）
エピソード記憶 → 長期記憶への昇華

パターン3: ドメイン特化LLM + RAG

向いているケース：

専門分野でクオリティ重視
クラウドの利便性も維持したい
コスト許容範囲が広い

構成例：

GitHub Copilot（コード生成）
社内コードベースをRAGで参照
コーディング規約、過去のPRをコンテキストに

パターン4: ハイブリッド（複数LLM併用）

向いているケース：

タスクによって最適なLLMが異なる
コストとパフォーマンスのバランス重視

構成例：

汎用質問 → GPT-4 Turbo（安価、高速）
専門的コード生成 → Claude Opus（高品質）
機密情報処理 → ローカルLlama
画像理解 → Gemini Pro Vision

管理ツール：

LangSmith：複数LLMの統合管理、トレーシング
LiteLLM：統一APIで複数LLMを扱う

筆者のAI Vtuberプロジェクトでも実践しています：

Gemini：汎用対話、画像理解（VLM）
ローカルLlama：記憶製造機、プライバシー保護
LangSmith：エラーハンドリング、パフォーマンス監視

Part 5: 実装のステップ

ステップ1: 現状分析

まず、「何が足りないのか」を明確にします。

チェックリスト：

□ 汎用LLMで十分な精度が出ない分野は？
□ ドキュメント化されているが活用できていない知識は？
□ 暗黙知として存在するが言語化されていない知識は？
□ 機密性の高いデータは？（クラウドに送れない）
□ リアルタイムで更新される情報は？

ステップ2: ツール選択

現状分析に基づいて、適切なアプローチを選びます。

課題	解決策
既存ドキュメントを活用したい	RAG
暗黙知を蓄積したい	記憶製造機
特定分野の精度を上げたい	ドメイン特化LLM
機密情報を扱う	ローカルLLM
コストを抑えたい	ローカルLLM + 小型モデル

ステップ3: 小さく始める

いきなり完璧なシステムを作ろうとせず、プロトタイプから始めます。

例：RAGのMVP（Minimum Viable Product）

重要なドキュメント10件をテキスト化
ChromaDBでベクトル化
LangChainで簡単なRAG実装
実際に質問して効果を確認

効果が確認できたら拡張：

ドキュメントを増やす
検索精度を調整
チャンク分割のロジック改善

ステップ4: 評価と改善

定量的・定性的に評価します。

定量評価：

検索精度（Precision, Recall）
回答の正確性（人間による採点）
レスポンス時間

定性評価：

期待通りの回答が返るか？
実務で使えるレベルか？
ユーザー満足度

継続的改善：

失敗事例を分析
プロンプトを調整
検索ロジックを改善
記憶の重み付けを調整

まとめ

「AIが使えない」の真の原因

1. 対話の問題：

質問の仕方が曖昧
前提条件を伝えていない
1回で完璧を期待している

→ 解決策：

明確な指示を出す
対話で精度を上げる
AIに選択肢を聞く
フィードバックループを回す

2. 道具の選択の問題：

汎用LLMでは知識が足りない
ドメイン固有の専門性が必要
プロジェクト固有の文脈が必要

→ 解決策：

RAGで既存知識を活用
記憶製造機で暗黙知を蓄積
ドメイン特化LLMを探す
ローカルLLMでカスタマイズ
複数LLMを組み合わせる

効果的なAI活用のために

✅ 対話のスキルを磨く

でもそれだけでは足りない

✅ 適切なツールを選択・構築する

あなたの専門性を「AIに教える」仕組みを作る

✅ 小さく始めて、継続的に改善する

完璧を目指さず、まずプロトタイプ
効果を測定しながら拡張

AIは万能ではない。でも正しく拡張すれば、あなたの専門性を増幅するツールになる。

「使えない」と嘆く前に、まず対話を改善する。
それでも限界を感じたら、道具を変える・作る。

これが、AI時代のエンジニアに求められるスキルです。

参考資料

筆者の関連記事：

技術リソース：

🤖 本記事は Claude Code との対話から生まれました

GitHub: https://github.com/koshikawa-masato/AI-Vtuber-Project