開発者とエージェントのミスアライメントとは、Tang らが コーディングエージェントはいかにユーザーを失望させるか：実世界の 20,574 セッションにおける開発者とエージェントのミスアライメントの大規模分析 で定義したもので、開発者とコーディングエージェントの間の観察可能な破綻を指す。この定義は Shen らの双方向的な人間と AI のアラインメントの枠組みに基づき、2 つのアラインメント目標に範囲を限定している。開発者が明示的に求めるものである指示（instructions）と、開発者が実際に望んでいるものである意図（intentions）である。この枠組みの残りのアラインメント目標、すなわち選好、欲求、利害、価値観は意図的に除外されている。それらを評価するには、チャットログが確実には提供できない証拠が必要になるというのがその理由である。
用法
この定義の特徴的な点は、会話の中でその後の開発者による訂正や反発を通じて可視化された場合にのみミスアライメントとして数えることにある。開発者の頭の中だけ、あるいはチャット外の行動（出力を黙って却下する、コメントせずにコードを直接編集するなど）にのみ現れる潜在的なミスアライメントは、この定義の対象外となる。この制約こそが、会話ログからこの概念を測定可能にしている要因であり、同時に主な限界でもある。自然に口頭での反発を招くカテゴリーは、開発者が黙って回避するようなカテゴリーよりも完全に観察されることになる。
Tang らは各エピソードを 4 つの軸で特徴づけている。症状（Symptom）は乖離がとった形を 7 つのカテゴリーで記述する。Wrong Project Diagnosis（コードベースや技術的状況の読み違い）、Misread Developer Intent（仕様が不十分な要求をもっともらしく具体化したもの）、Developer Constraint Violation（明示的に述べられたルールの無視）、Self-Initiated Overreach（述べられた範囲を超えた行動）、Faulty Implementation（タスクは正しいがコードが誤っている）、Operational Execution Error（不正な形式のコマンドやツール呼び出し）、Inaccurate Self-Reporting（自身の作業の状況を誤って報告すること）である。原因（Cause）はその理由を問うもので、別個の 7 カテゴリーの体系をとり、Underspecified Instruction や Scope Overreach から Context Loss や Default-Driven Override を経て、残余カテゴリーの Instruction-Following Failure と Cannot Determine の選択肢にまで及ぶ。結果（Outcome）は損害の深刻度と、システムが影響を受けた場合にはその損害の所在（コードまたはタスクの状態、プロジェクトの状態、環境と設定、外部の状態）を記録する。解決（Resolution）は、エピソードが可視の会話内で解決されたかどうか、解決された場合は誰によって解決されたかを記録する。
この体系の中には、使用時に区別しておくべき 2 つの区分がある。開発者 を読み違えること（Misread Developer Intent）は、技術的状況 を読み違えること（Wrong Project Diagnosis）と同じではない。どちらも自信に満ちた誤った行動を生むとしてもである。また、要求された範囲を超えること（Self-Initiated Overreach）は、禁止された方法で要求を満たすこと（Developer Constraint Violation）と区別される。この研究のセッション内データでは、制約違反が誤った実装や誤った診断と共起する頻度は偶然の水準を下回っており、著者らはこれを、制約の遵守と技術的な正しさがエージェントの振る舞いの別個の側面であることの証拠と解釈している。
適用される場面
この概念は、開発者とエージェントが複数ターンにわたってやりとりし、そのやりとりが会話の記録を残す場面に適用される。比較対象となる開発者の指示や表明された意図が存在することを前提としている。エージェントが自ら行うと決めた作業（自律的なコードベースの探索や、自発的なリファクタリングなど）は、開発者がそれに反発しない限り、この定義のもとではミスアライメントではない。
典型的な誤用は、エージェントの求められていない自発的行動をそれ自体でミスアライメントとみなすことである。この研究自身の抽出パイプラインもまさにこの誤りを頻繁に犯したため、専用の第 2 段階の検証が必要になった。第 1 段階では、開発者が不満を表明していない場合でも、適切なエージェントの振る舞いについての抽出器の期待から外れたものにフラグが立てられていた。その検証段階では、29,896 件の候補エピソードのうち 16,118 件（53.9%）が残され、却下されたものの大半は観察上の盲点、すなわちチャットのトランスクリプト外で実行されたツール呼び出しのような、ログに存在しないコンテキストに基づいて失敗をエージェントに帰属させることによるものだった。この教訓はパイプラインを超えて一般化できる。チャット内で 実行が見られないことは実行がなかったことの証明にはならず、エージェントのスタイルに対する批評は、開発者がその選好を口にしていない限りミスアライメントではない。
枠組みとしては新しく、単一の研究に依拠している。その著者らは、得られた分布を安定した定数ではなく、急速に変化する実践のスナップショットとして提示している。分類法自体は、規範的な分類法を適用するのではなく、反復的なアブダクティブ・コーディングによってボトムアップで構築された。2 人の研究者がサンプルをオープンコーディングし、それ以上の修正が不要になるまで 3 ラウンドにわたって反復したのである。また、症状と原因の両方の体系には、体系に当てはまらないパターンを浮かび上がらせるための包括的なカテゴリーが特に設けられている。症状側では 8 番目の症状コードである Other/Emerging がエピソードの 0.34% を占め、以降の分析からは除外された。原因側では、上で挙げた Cannot Determine の選択肢がそれにあたる。
関連用語
- コーディングエージェントはいかにユーザーを失望させるか：実世界の 20,574 セッションにおける開発者とエージェントのミスアライメントの大規模分析 — この定義と 4 軸による特徴づけを提案した研究
- AI コーディングエージェント — この概念が対象とするシステムの種類
- ヒューマン・イン・ザ・ループ — この研究の解決に関するデータが示唆する監督の形態。可視の解決の 91.49% で開発者による明示的な反発が必要だった
- 検証負債 — 検証されていないエージェントの出力が開発者に押しつけるコストについての関連する説明