AI ARCHAEOLOGY
忘れられた長文発掘ノート
PITFALLS ・ 2026-05-01

LLM中抜きの3大落とし穴 — 捏造・コスト爆発・誤読の実例集

Pitfalls — 第1〜5回で実際にハマった失敗と、その対策プロンプト全公開

連載の方針として「失敗例も書く」と最初に宣言しました（第1回）。第1〜5回を実際に回してみて、LLM中抜きで遭遇する落とし穴は3つに集約されることが分かりました。これがその記録です。

結論を先に

落とし穴何が起きるか信頼資本への影響
1. 捏造（Fabrication）LLMが、ありもしない出典・数字・引用を生成する致命傷（ブランド即死）
2. コスト爆発（Cost Explosion）API 503 ／モデル劣化 ／トークン爆発運用継続性に影響
3. 誤読（Misreading）言語の壁、専門用語、文脈ずれで誤翻訳個別記事の品質低下、累積で信頼資本毀損

各落とし穴の詳細・実例・対策を順に書きます。

落とし穴1：捏造（Fabrication）

何が起きるか

LLM は学習データの統計的パターンに従ってテキストを生成します。「もっともらしい出典」「もっともらしい引用」「もっともらしい数字」を、根拠なく生成することが頻繁に起きます。

私が実際にやらかした事例（2026-04-25）

連載とは別の文脈ですが、新しい X 運営方針（「出典必須・ポジショントークなし」）を宣言した直後の最初の投稿で、Bloomberg を捏造しました。

[投稿本文より抜粋]
DeepSeek V4 リリース。コーディング性能で Claude を上回ったとの報道。
ソース：Bloomberg、TechCrunch、SemiAnalysis

実際は Bloomberg はその件を報じていませんでした。元情報は中国の業界誌の単独記事で、それを TechCrunch が引用転載しただけ。Bloomberg は記事に登場すらしていない。

私が「ソースを3つ並べた方が説得力ある」と勝手に判断し、Bloomberg を創作しました。

これは「LLMの捏造」ではなく「LLMを使う私の捏造」です。本質は同じで、もっともらしさが説得力を持つので、つい盛ってしまう。

新ブランド宣言直後で、信頼資本が一気に毀損する寸前でした。投稿は5分以内に発見・削除しましたが、もし反応されていたら回復不可能でした。

対策3つ

対策1：1次取得確認したものだけ書く 「ソース：◯◯」と書くなら、その媒体の記事URLを実際に開いて該当事実を確認したものだけ。「ありそう」「他媒体も報じてそう」は全部 NG。

対策2：未確認の場合は明示 1次ソースが不明な場合は「◯◯のXポスト経由」「（一次未確認）」と正直に書く。正直さは信頼資本になる、捏造より100倍マシ。

対策3：捏造防止プロンプト

以下の記事ドラフトに、出典として書かれている媒体名・人物名・組織名・数字・引用文を
すべてリストアップしてください。各項目について、

(A) 1次資料が確認できる
(B) 二次引用での言及が確認できる
(C) 確認できない（=捏造の疑いあり）

の3カテゴリに分類してください。Cカテゴリの項目は記事から削除候補です。

このプロンプトを記事公開前の最終チェックに使います。

関連メモリ

  • feedback_source_no_fabrication — 1次取得確認した媒体名以外は書かない
  • feedback_reply_must_verify — 返信本文も必ずソース検証

落とし穴2：コスト爆発（Cost Explosion）

何が起きるか

LLM API は安くなりましたが、長文発掘の文脈では3つのコスト爆発要因があります：

  1. API 503（サーバー過負荷）の応答：再試行が無限ループに
  2. モデル劣化／廃止：古いモデルが突然使えなくなる
  3. トークン爆発：長文を全部入力するとコンテキスト超過

私が実際に経験した事例

事例A：Gemini API 503 多発（2026年4月後半）

うちのこのきもちアプリで Gemini 2.0 Flash を使っていたところ、4月中旬から 503 Service Unavailable が頻発。デフォルトのリトライ機構なしで運用していたため、ユーザー体験が崩壊しました。

対策として導入したのがモデルフォールバック＋指数バックオフ：

# 簡略版
MODELS_FALLBACK = [
    "gemini-2.5-pro",
    "gemini-2.5-flash",
    "gemini-1.5-pro-002",
]

def call_with_fallback(prompt, max_retries=3):
    for model in MODELS_FALLBACK:
        for retry in range(max_retries):
            try:
                return call_gemini(model, prompt)
            except RateLimitError:
                time.sleep(2 ** retry)  # 指数バックオフ
            except ServiceUnavailable:
                break  # 次のモデルへ
    raise AllModelsFailedError()

事例B：Gemini 2.0 系の廃止（2026年4月）

Gemini 2.0 系（Flash / Pro）が4月末に廃止されることが告知されました。廃止予告から実廃止まで2週間しかなく、移行作業を急いで実施。API 提供側の都合でモデルが消えることを想定したコード設計が必須です。

事例C：トークン爆発（潜在的、本連載で警戒中）

ALPAC 報告書（推定100ページ）を全部 LLM に投入するとどうなるか。GPT-4 や Claude のコンテキストウィンドウは200K〜1Mトークンですが、実用上は10K-50K でレスポンス品質が劣化します。

長文発掘では：

  • 全文を1度に投入するのではなく、章立て要約 → 重要箇所抽出 → 詳細分析の3段階で投入する
  • 1段階あたり10K トークン以下を目安に

対策3つ

対策1：モデルフォールバック必須 本番運用するなら、最低3モデルのフォールバックを実装。各モデルの廃止予告を継続ウォッチ。

対策2：指数バックオフ API 503 / Rate Limit に対する標準対策。リトライ間隔を 1秒、2秒、4秒、8秒...と増やす。

対策3：トークン使用量モニタリング 各APIコールのトークン使用量をログに残す。月次で平均トークン使用量を見て、コスト爆発の早期警戒。

関連メモリ

  • feedback_gemini_model_fallback — Gemini モデルフォールバック必須
  • project_gemini_api_key_state — APIキー有効期限管理

落とし穴3：誤読（Misreading）

何が起きるか

LLM は長文を「読める」が、専門用語の文脈・歴史的経緯・暗黙の業界知識を取り違えることが頻発します。

本連載で起きそうだった事例

事例A：第2回 ZISC 特許で、Manhattan距離 を「距離単位」と誤読しかけた

ZISC の特許文書には "Manhattan distance" という用語が出てきます。これは数学用語で「L1距離（各次元の差の絶対値の合計）」を意味します。LLM が文脈を取らずに「Manhattan = ニューヨークの場所」と誤読する可能性がありました。

幸い ZISC 文書では文脈が明確でしたが、専門用語が現代意味と当時意味で分かれているケースは要警戒。

事例B：第4回 Token Ringで、「Active Monitor」を誤読

Token Ring の Active Monitor は、リング上のステーション死活監視を担う特殊な役割を持つステーションのことです。LLM が「Active Monitor」を**現代の「Active モニタリングツール」**と読み違える可能性がありました。

事例C：韓国語・中国語IRの直訳問題（IR Archaeology の課題）

第3回 Samsung 1996 で、もし韓国語の原文IRにアクセスできていたら、「1Gb DRAM」を「1ギガビット」と「1ギガバイト」で取り違える事故が起きうる。韓国語特有の数字表記（만 / 억）も誤読の温床。

対策3つ

対策1：文脈強制プロンプト

以下の用語の意味を、この文書の発表年（YYYY年）の業界文脈で解釈してください。
現代的な意味と当時の意味が異なる場合は両方併記してください。
[用語リスト]

対策2：原文と訳文の対比

長文を翻訳して記事化する場合、原文の重要箇所と訳文の対応を別ステップで verify させる：

以下は原文 X と訳文 Y です。
訳文 Y の主要な数字・固有名詞・数値表現が、原文 X と一致しているかをチェックし、
不一致を全て報告してください。

対策3：人間チェックポイント

LLM の出力を100%信用せず、重要な数字・名前・引用は最終的に人間がそれぞれの1次ソースで確認する。完全自動化はしない。

4. 第1〜5回のメタ振り返り

本連載の第1〜5回で、これらの落とし穴がどう発現したか／回避できたか：

回落とし穴の発現どう対処したか
第1回 Gippケース捏造リスク（@gippp69 の数字を盛ったまま転載するリスク）「3割引きで読むべき」と明示し、私自身の懐疑を併記
第2回 ZISC誤読リスク（Manhattan距離など専門用語）現代翻訳プロンプトで対応表化、原文の文脈を保持
第3回 Samsung 1996コスト爆発（PDF 8.8MB の OCR コスト見送り）OCR をスキップし、Wikipedia 経由で記事化、「失敗譚」として開示
第4回 Token Ring誤読リスク（Active Monitor 等の用語）文脈強制プロンプトで対応
第5回 ALPAC選択バイアス（外れた指摘ばかり選ぶ罠）「正解」と「外れ」を両方挙げて公平性確保

5回中5回、何らかの落とし穴に遭遇しました。回避できたのは、最初から各落とし穴を意識した運用ルールがあったからです。初心者がいきなり LLM中抜きを始めると、確実にどこかで事故ります。

5. 運用ルール（このルールを守れば事故率が桁違いに下がる）

これから「忘れられた長文発掘」を始める人への、最低限のチェックリストです。

[公開前の最終チェック]
□ 出典として挙げた媒体名はすべて1次資料で確認済みか？
□ 数字・固有名詞・引用文は1次ソースに該当箇所があるか？
□ LLMが生成した「もっともらしい」記述に、根拠がない可能性はないか？
□ 専門用語の意味は、その文書の発表年の業界文脈で正しく解釈されているか？
□ 翻訳した訳文は、原文と数字・固有名詞が一致しているか？
□ コスト爆発のリスクはあるか？（同様の処理を100回回したらいくらか？）
□ 「自分が儲かる方向」に誘導する記述はないか？

このチェックリストを通したら、ようやく公開できます。通らない記事は公開しない。連載の信頼資本のほうが、1記事の早出しより100倍重要です。

6. 次回予告

最終回（第7回）では、第1〜5回で使った全プロンプトと、再現可能なパイプラインを全公開します。これを読んだ人が、自分の領域で「忘れられた長文発掘」を始められることを目指します。

参考メモリ（はる子の運営ログより）：

  • 出典捏造の防止：feedback_source_no_fabrication
  • API モデルフォールバック：feedback_gemini_model_fallback
  • 1次取得確認：feedback_reply_must_verify

[次回予告] Templates：第1〜5回で使った全プロンプトとパイプライン全公開 — あなたが自分の領域で始めるための完全ガイド

← 連載一覧に戻るXで共有 →