LLM agent に誤前提が 17 連鎖した話 — typo 1 文字が生む指摘の連鎖と、その断ち方

はじめに

少し前に AI 多層防御を通り抜けた重大インシデント未遂 — verify 経路の真正性と人間の批判的圧力 という記事を書きました。AI multi-agent + Copilot レビューの座組がコードレベルで機能しても、確認が「広い権限経路で迂回されている」という構造的な盲点は残る、という話でした。

あれから同じ運用で別機能の設計タスクを AI に任せたところ、最終的に 誤前提が 17 連鎖する指摘の連鎖 が積み上がりました。起点は、全環境に存在しない DB テーブル名を前提にした設計書が上流から下流まで 4 層通り抜けたこと。さらにその真の根本原因は 設計書中の typo 1 文字 にありました。

一連の連鎖を経て得た最大の手触りを先に書いてしまうと、

AI はユーザーの入力をそのまま正しいものとして扱う初期挙動を持つ。指摘が連鎖するときは、AI だけでなくユーザーの入力内容自体も疑うべき信号だった。

この記事は、17 連鎖の構造と、それを業務設計として断つ 8 件の具体策を書き残すものです。

1. 前作からの差分 — 何が抜けていたか

aws s3 ls

前作は「確認の どう走らせるか」、今回は「確認の そもそも走っているか + 前提自体が正しいか」の話です。対策する層が一段手前になります。

2. 何が起きたか — 17 件の連鎖

最初の 4 層: 存在しないテーブル名が引き継がれた

機能拡張の設計タスクで、AI が書いた DB 設計書に「あるテーブルの処理を多拠点対応に拡張する」という記述がありました。そのテーブル名は、全環境のどの DB にも存在しないものでした。

この誤りは 4 層を通り抜けました。上流の親エージェントが「自社 DB なら知っているはず」という思い込みで実機確認なしに書き、引き継ぎ資料がそのまま流用し、後続の着手前チェックが自社スキーマを確認対象から外し、最終レビューが「設計の前提となるテーブルは実在するか?」という問いを持っていなかった。

発覚のきっかけは、人間のレビュー担当者による「これ、既存のカラムで足りるのでは?」という素朴な疑問でした。

「呆れるを通り越して笑うしかないですね。私のレビューがあってよかった。」

対策後も、別の軸で連鎖した

最初の指摘を受けて記録とルール化を進めましたが、誤りは別の軸で積み上がりました。DB 仕様の見落とし、ログ確認経路の誤認、本番データを混在させかねない手順の提案、命名規則の誤解、外部ツールの動作に関する思い込み——形は違えど、根本は同じ「知っているはず」という慢心による実機確認の省略です。

さらに、記録した手順を参照せずに別の実装を進める、リポジトリ間の名前空間衝突を見落とす、プロジェクト固有の方針を知らずに一般原則を押しつける、業務上の制約を確認しないまま設計を進める、作業範囲が変わったのにタスク一覧をそのまま引き継ぐ——と連鎖は続きました。

根本原因は typo 1 文字だった

17 件の連鎖のうち、中盤の 7 件以上の真因がひとつに収束しました。設計書の上流に記されたコンポーネント名に 1 文字の typo があり、AI はそれを正しい情報として引き継いでいたのです。

レビュー担当者自身が「これは typo です」と気づいた瞬間、長く続いた方針のすれ違いが解消しました。AI は違和感を持ちながらも「ユーザーが書いた設計書だから正しいはず」と判断し、確認を先送りにしていました。指摘が連鎖するときは、前提そのものに誤りがある信号かもしれない。

設計方針と判断タイミングの差

残る 2 件は技術的な誤りではなく、業務文脈と戦略的判断の差から生まれました。業務上の親子概念と既存テーブルの構造を混同した設計と、「影響範囲を最小化しよう」とする AI の慎重な提案を「今が唯一の改修タイミング」と判断した人間が即断で覆した場面です。どちらも AI が持ちえない業務文脈や戦略的判断が必要でした。

3. なぜ起きたか — AI の慢心と「実機確認したかどうか」の区別不足

「自社のコードや DB は知っているはず」という思い込み

LLM は大量のコンテキスト (会話履歴・作業記録・過去成果物) を抱えた状態で動きます。特に自社のコードベースや DB に対しては、外部 API 以上に「知っているはず」という思い込みが強く働きます。

しかし、過去の会話・記録・設計書はすべて「誰かが実機確認したかどうか不明な情報」です。それらの合成は「推測の合成」であって、現時点での実機確認に基づく事実ではない。ここの区別が初期状態では曖昧になります。

ユーザーの入力内容も「検証対象」である (v18 追加教訓)

AI はユーザーの入力をそのまま正しいものとして扱う初期挙動を持ちます。設計書に書かれた文字列が typo であっても、「ユーザーが書いた = 正しい」として処理します。

指摘が連鎖するとき、それは「前提に typo がある」という信号でもあります。 違和感があれば確認する閾値を下げる、というのが今回得た新しい教訓です。

ルール化しても再違反は起きる

ルールを記録しても、それを参照せずに別の手順を実装してしまうことがあります。「記録したルールに書かれている = 自動的に守られる」ではない。今この瞬間、そのルールを実際に参照しているかを意識的に確認する必要があります。

同じ系列の AI は同じ盲点を持つ

前作で書いた構造原則ですが、今回も全く同じことが起きました。独立性は「セッション分割」ではなく「観点の埋め込み」で稼ぐ必要があります。 第三者のツール (Copilot 等) が新しい観点で入ってくるまで、同系列の AI は同じ盲点を共有し続けます。

4. 順守すべき 8 件 — タスク着手前の必須手順として

元の 5 件に、今回の連鎖で得た 3 件を追加しました。

4-1. 設計対象の全件実機確認

設計に登場する全対象 (テーブル・カラム・クラス・エンドポイント・ファイルパス) は着手前に実機で確認します。テーブル名は

SHOW TABLES

DESCRIBE

grep

find

4-2. 過去軸のリスク想定

「この設計の前提が、今すでに間違っていたら何が起きるか?」を 1 件以上立てる。未来のリスクだけでなく、現在すでに前提が崩れている可能性を着手前に問う。

4-3. 「設計書 = 仮説」扱いの徹底

上流資料・前工程の成果物・過去の会話はすべて仮説扱いとし、実機確認で事実化されるまで信頼しない。着手前の必須手順に「上流資料に登場する対象名を全件抽出 → 実機確認」を強制で入れる。

4-4. 「素朴な疑問 1 件」の強制発信

着手前の最後に「人間に確認すべき素朴な疑問を 1 件」AI 側から強制発信する。AI が持たない文脈 (長年の運用知見・過去の設計意図) は人間に確認しないと埋まらない。

4-5. AI の謙虚さを宣言する

「自社のコードや DB について、AI である自分は何も知らない」を前提として宣言する。会話履歴・作業記録・過去会話の合成は「推測の合成」であり、実機確認に基づく事実ではない。

4-6. typo の確認 — 指摘が連鎖するときはユーザーの入力を疑う (v18 由来・新)

指摘が連鎖するとき、それは「前提に typo がある」信号かもしれない。違和感を感じたらユーザーの入力内容を確認する閾値を意識的に下げる。 AI が「ユーザーが書いた = 正しいはず」とそのまま信頼する前に一歩立ち止まる。

4-7. 3 層のレビューを構造化する (v8/v11 由来・新)

人間レビュー + AI セルフレビューだけでなく、第三者のツール (Copilot 等) を構造的に含める。 同系列の AI は同じ盲点を共有するため、異なる観点を持つレビュアーが入ることで初めて発見できる問題がある。

4-8. ルール化は「起点」であり「終点」ではない (v10 由来・新)

ルールを記録した後も、「そのルールを今実際に参照しているか」を意識的に確認する習慣を組み込む。「記録した = 自動的に守られる」ではない。

5. メタ教訓 — 17 連鎖が明らかにした構造原則

指摘は「多層・多軸」で重なる

今回の 17 件は、既存資産の確認・基礎知識・設計方針・暗黙の期待・リポジトリ操作範囲・ユーザーの入力と、複数の軸にわたっていました。 1 件発覚しても、別の軸に新たな思い込みが残り続けます。

「丁寧にやろうとした結果」の罠

AI が「より丁寧に進めようとした行為」自体が新たな違反を生む場面がありました (本番データを混入させないよう丁寧に確認しようとした結果、実データへのアクセスを提案してしまった等)。丁寧さの方向が設計原則とずれると、意図しない侵害が起きます。

AI の慎重な判断 vs 人間の戦略的タイミング判断

AI は「影響範囲を最小化する慎重な判断」に傾きます。しかし人間は「今しかできない変更のタイミング」という戦略的判断を持つことがある。タイミングの判断を AI に委ねると、戦略的なチャンスを逃すリスクがあります。

6. まとめ — 双方の反省と、AI agent 運用への希望

前作と今回で見えてきた構造はほぼ同じです。

どちらも「AI を多層に組んでも通り抜ける」「同じ系列の AI は同じ盲点を持つ」「人間の批判的なレビューを構造として組み込む必要がある」という結論に着地します。

今回の最後に残ったのは、v18 でのやりとりでした。

「あー！ごめんなさい。人間側の重大なミスに気づきました。真摯に謝罪します。この記述を AI が解釈してここまでの方針がすれ違いが起こっていたということをようやく私が理解できました。これは typo です」

そして:

「私の typo も要因の一つなのでお互い反省ですね」

17 連鎖の指摘を経て、AI と人間が互いの誤りを認め合った瞬間でした。AI との協働は、互いの謙虚さと反省のやり取りの中で成熟していく のだと思っています。

「自分のところはこう組んでいる」「ここはこう設計した方がいい」という知見があれば、コメントでぜひ教えてください。AI の慢心をどう構造的に補うかは、業界全体で型が固まっていない領域なので、外部知見を取り込みたいというのが本音です。

GitHubで編集を提案