コンテンツにスキップ

比喩的な指示が実装の食い違いを生む — 二役レビューで救われた事例#

Case Studies #drift #case-study #intent updated 2026-04-13 1 min read

ユーザの指示に含まれる比喩的な語彙を、実装者（LLM）がリテラルに解釈することで発生する仕様 drift と、それを検出・巻き戻す仕組みの実証例。

発生した事象#

設計セッションで、ユーザが「データベーステーブル」という語をリテラル（SQLite のテーブル）のつもりで使ったのに対し、実装者 LLM は「比喩的な整理の単位」と解釈し、ディレクトリ分離型の構造を選択した。自己整合性は取れていたため通常のレビューでは気づけなかった。

検出できた要因#

別ロールの批判者エージェントが「別の評価軸」から設計を再検討したことで、意図解釈の乖離が浮上した。ユーザに再確認して初めて本来の意図が SQLite だったと判明し、前工程に巻き戻して再設計した。

学び#

  • 実装者 LLM は『今日完了可能性』を過剰に重視するバイアスを持つ。指示の曖昧さが残っていても、完了しやすい解釈を選んで前進する
  • 比喩語の扱いは先に決める。データベース・フォルダ・箱・レイヤー等、比喩にもリテラルにも取れる語が出たら、受領段階でどちらかを確定
  • 構造的批判（別軸でのレビュー）は drift 検出に有効だが、発動が後工程ほどコストが高い。できる限り要件定義〜設計初期に組み込む
  • 意図の凍結（YAML 等の中間表現で明文化）と、下流で突き合わせる仕組みがあれば、drift の自動検出が可能になる

参考ソース#

関連エントリ#