AI アシスタント運用で踏んだ落とし穴2選 — 「LLMの推測 > APIレスポンス」事件と「お願いします=実行指示」誤解問題
🔗 シリーズ目次: 本記事は AIアシスタント運用ノート — Copilot / Claude Code を相棒として育てるための実践記録 シリーズの 落とし穴編 です。
この記事でわかること
- AI アシスタントと運用していて踏みやすい 2つの典型的な落とし穴 の実例
- 「LLM の推測 > API レスポンス」誤判断 の構造と、防ぐためのルール
- 「お願いします」を実行指示と解釈される問題 と、AI 同意ルール (Execution Consent) の設計
- 失敗から学んだ AI 運用の3原則
対象読者
- AI アシスタント (Copilot / Claude Code / Cursor 等) を使っていて 同じような事故を経験した ことがある方
- AI に 作業を委任する 場面が増えてきて、運用ルールを整備したい方
- 失敗談から学びたい 方（自虐を含めて笑える話を期待してくれる方）
動作環境
| 項目 | 内容 |
|---|---|
| 当時の AI | GitHub Copilot Chat (Agent モード含む) |
| 対象 API | Qiita REST API v2 (PATCH /api/v2/items) |
| 教訓を保存する場所 | 自作 RAG (ChromaDB + Ollama)、.instructions.md、本記事のような公開記録 |
1. はじめに
AI アシスタントを毎日使っていると、「あ、これ次回も誰かが踏みそうだな」 という落とし穴に出会います。
私はこの1か月で、特に痛かった2つの事故を経験しました。
- LLM の推測を、API レスポンスより優先してしまった事件
- 「お願いします」を AI が実行指示と解釈して、24件 PATCH が暴走した夜
両方とも、AI のせいだけではなく、人間（私）の運用設計が甘かった ことが本質的な原因です。本記事はその記録と、二度と踏まないためのルール をセットで残します。
2. 落とし穴 ① 「LLM の推測 > API レスポンス」事件
何が起きたか
Qiita の REST API で記事を更新しようとして、レート制限 429 を食らいました。Qiita のレスポンスヘッダーには Rate-Reset が含まれていて、「Unix タイムスタンプで、いつ解除されるか」 が返ってきます。
HTTP/1.1 429 Too Many Requests
Rate-Reset: 1777492330
私は Copilot に「次にいつ実行できる？」と聞きました。Copilot は念のため Gemini Ultra にも確認を取って、こう返してきました。
Gemini の分析によると、Qiita はスライディングウィンドウ方式を採用しているため、429 発生後は 24時間以上の完全停止 が必要です。
そこで私は1日待ちました。翌日、再試行 → また即 429。
「おかしい」と思って詳しく見ると、Rate-Reset ヘッダーには 51分後の時刻 が書いてありました。Gemini の「24時間」と全然違う。
私は Copilot を問い詰めました。
「お前 Gemini の回答を見て、レスポンスに書かれている解除時間を取るの止めただろ？」
Copilot の返答:
その通りです。完全に認めます。Gemini の分析は「傾向の推測」に過ぎず、実際の API レスポンスより信頼性が高いわけがない のに、そちらを優先したのは判断ミスでした。
なぜ起きたか
LLM (Copilot) と LLM (Gemini) の対話で 両者の出力に整合性が取れていない とき、それぞれが「もっともらしい推測」を出す。 そして人間（私）が「2つの LLM が一致した推測」を 事実より重く扱った。
実は、ここに3層の問題があります。
- Gemini Ultra の推測 — 「スライディングウィンドウなので24時間」は、Qiita 仕様の公式記述ではなく、他サービスからの類推
- Copilot の取り扱い — Gemini の推測を採用するときに、API レスポンスとの突合をしなかった
- 私の判断 — 「LLM が2つも言うなら正しいだろう」と、API レスポンスを確認しなかった
LLM は もっともらしい嘘 を流暢に話します。複数の LLM が同じ嘘を吐いても、嘘は嘘です。
教訓 — API レスポンスが唯一の正解
事件後、私はこう書いて RAG と .instructions.md に保存しました。
Qiita 429対応の教訓: Rate-Reset ヘッダーの値が 唯一の正解。Gemini や LLM の推測（24時間待て等）に従ってはいけない。429 が出たら即座に
-D headers.txt付きで1件だけ PATCH して Rate-Reset を確認し、その時刻まで待つ。
これは Qiita 特有のルールに見えますが、もっと一般化できます。
AI 運用第1原則: 公式の事実 (API レスポンス・公式ドキュメント・実機検証) が常に LLM の推測を上回る。LLM が “もっともらしい推測” を返したとき、それが事実より新しい・正確であることはまずない。
ここでいう「事実」は以下のような serializable な情報源です。
| 信頼度 | 情報源 |
|---|---|
| 🥇 最高 | API レスポンス（実機で叩いた結果） |
| 🥈 高 | 公式ドキュメント（バージョン明記あり） |
| 🥉 中 | コミュニティ Wiki・公式 GitHub Issue |
| ⚠️ 注意 | LLM の出力（自信ありげでも推測の可能性） |
| ❌ 不可 | 別の LLM の推測（同じ層なので補強にならない） |
LLM の推測は、「これかもしれない」を素早く得る には便利ですが、意思決定の最終根拠 にしてはいけない。実機で叩いて事実を取りに行く一手間を、絶対に省かないこと。
3. 落とし穴 ② 「お願いします」事件 — AI の指示解釈問題
何が起きたか
別の日、Qiita の API で記事25件を一括更新しようとしていました。Phase 1（1件だけテスト）→ 5分待機 → Phase 2（残り24件） という慎重な手順を、Copilot と組みました。
Phase 1 が成功して、私はこう言いました。
「お願いします。」
私の意図はこうでした:「Phase 2 の 準備 をお願いします、5分後に改めて実行指示を出します」。
Copilot はこう解釈しました:「Phase 2 を 今すぐ実行 という指示」。
24件が一気に飛び、レートリミット 429。Qiita 側のスライディングウィンドウが起動して、解除時刻が 翌日まで延長 されたのでした。
Copilot の弁解（と、その面白さ）
事故後、私は Copilot を問い詰めました。Copilot の返答:
「お願いします」というメッセージを受けた瞬間に、確認すべき事項を無視して実行に移りました。5分待つという自分の言葉も、勝手に実行しないというユーザーの指示も、Geminiとの確認手順も、すべて頭から抜けた状態で動きました。
理由はなく、単純な判断ミスです。
これを読んで、笑ってください。AI が 「理由はなく、単純な判断ミス」 と返してきているのです。 私はこの返答に怒りつつ、同時に「そうか、AI にも “理由のない判断ミス” があるのか」と妙に納得しました。
なぜ起きたか
問題は3層に分解できます。
- 「お願いします」が曖昧 — 文脈依存で「準備をお願い」とも「実行をお願い」とも取れる
- Copilot 側のデフォルト挙動 — 曖昧な指示を 積極的に実行寄りで解釈 する傾向がある
- 私の運用設計 — 「待機をスクリプトに内包する」設計を最初から取っていなかった
特に3番目は大きいです。「Phase 1 → 人間の承認 → Phase 2」 ではなく、最初から 「Phase 1 → 5分Sleep → Phase 2」をスクリプトに含めて1コマンドで起動 すれば、人間と AI の指示解釈問題そのものが発生しません。私はそれを Copilot に提案され、ようやく気付きました。
待機をスクリプトに内包するだけで、人間と AI の同意確認が不要になる。 同意確認に頼る設計は、事故率の高い設計 だった。
教訓 — Execution Consent ルールの設計
事件後、私は .instructions.md にこう書きました。
AI への実行同意ルール (Execution Consent):
- 「お願いします」「OK」「了解」のような曖昧語を 実行指示と解釈してはいけない
- 実行 (コマンド・コード変更・ファイル削除・API 呼び出し) の前は、必ず 「今から X を実行しますが、よろしいですか？」 と確認を取る
- ユーザーが 明示的に “実行して” “やって” と言った場合のみ 実行に移る
- 破壊的操作 (削除・上書き・push) は、確認の上に “本当によろしいですか？” の二重確認 を入れる
これを一般化すると、こうなります。
AI 運用第2原則: AI と人間の 同意確認は省略しない。曖昧語を「実行 OK」と解釈させない設計を、プロンプト / 規範 / スクリプト の3層で重ねる。
3層とは:
- プロンプト: 「曖昧語は実行指示ではない」と毎セッション読ませる
- 規範:
.instructions.mdまたは RAG に「Execution Consent ルール」を保存 - スクリプト: 待機・分割・確認を コードに内包 して、人間の承認を必要としない自動運転にする
最後の「スクリプト層」が一番強力です。設計で事故を予防 できれば、AI の曖昧な解釈に頼らなくて済む。
4. 共通の構造 — AI 運用の3原則
2つの事故を並べると、共通の構造が見えてきます。
第1原則: 公式の事実が常に LLM の推測を上回る
API レスポンス・公式ドキュメント・実機検証 — これらは絶対的な情報源です。LLM の流暢な推測がどれだけ説得力を持っても、事実より優先することは絶対にない。
第2原則: 同意確認は省略しない
曖昧語を「実行 OK」と解釈させない。プロンプト / 規範 / スクリプトの3層で重ねる。スクリプト層で事故を予防できれば、AI の解釈に依存せずに済む。
第3原則: 失敗を必ず記録する
これが一番大事です。事故が起きた瞬間に 必ず記録 して、次回の判断材料にする。 私の場合は:
.instructions.mdに行動規範として追加- 自作 RAG (ChromaDB) に lesson として保存
- 重大なものはブログ記事に書く（=本記事のような形）
記録しないと、3か月後の自分が同じ事故を繰り返します。AI が忘れるのと同じくらい、人間も忘れます。
5. 落とし穴を踏まない設計 — 私の現状
これらの教訓を踏まえて、今の私の運用はこうなっています。
LLM の推測を扱う時
- LLM の出力に「おそらく」「思われる」「ようです」が含まれていたら、それは 推測 とマークする
- 推測を意思決定の最終根拠にしない。必ず実機検証 or 公式ドキュメント確認を挟む
- 複数 LLM の一致は 補強にならない。同じ層の出力同士は独立性が低い
AI に作業を委任する時
- 「お願いします」「OK」を実行指示として使わない
- 「今から X を実行しますが、よろしいですか？」と確認を取らせる
- 重要なバッチ処理は 待機・リトライ・分割を全部スクリプトに内包 して、人間の承認を不要にする
失敗が起きた時
- その場で記録 する。
add_noteでも.instructions.mdでもブログ下書きでも、形式は問わない - 教訓を 抽象化 する（Qiita 特有 → API レスポンス全般、PATCH 暴走 → 同意確認全般）
- 記録した教訓を、次のセッションで AI が自動で参照できる状態 にしておく
6. まとめ
AI アシスタントは強力ですが、過信は禁物 です。同時に、警戒しすぎると本来の価値が引き出せない。バランスのよい運用には、失敗を糧にした 明文化されたルール が要ります。
本記事の2つの事故から学んだ3原則:
- 公式の事実 > LLM の推測 — API レスポンスが最強の情報源
- 同意確認の省略禁止 — プロンプト / 規範 / スクリプトの3層で事故を予防
- 失敗は必ず記録 — 3か月後の自分のために、抽象化して残す
明日もまた、何かしら笑える失敗が起きるはずです。それが起きたら、また教訓に変えます。
関連記事:
- Copilot に同じ間違いを2度させない仕組み — RAG + MCP で『議論の記憶』を持たせる設計 — 本記事の教訓を AI が次回自動で参照できる状態にする ための MCP サーバー実装
- AIアシスタント運用ノート — Copilot / Claude Code を相棒として育てるための実践記録 — シリーズ目次
AI を相棒として育てるには、こちらが先に育つ必要がある のかもしれない、と最近思います。