この記事はAIエージェントと一緒に執筆しています

こんにちは！yasunaです！

AIコーディングエージェントに「エラーが出る」「期待通りに動かない」と伝え続けても、同じ問題が形を変えて戻ってくる——そういう体験、ありませんか？

エンジニアとして日常的にAIツールを使うようになって、このモヤモヤに名前をつけた論文を読みました。

論文：The Observability Gap: Why Output-Level Human Feedback Fails for LLM Coding Agents（arXiv:2603.26942, CHI 2026 Workshop on Human-Agent Collaboration）

論文の要約

何を調べたか

LLMマルチエージェントコーディングシステムでは、通常エージェントの能力は設計時に固定されます。この論文は代わりに**「獲得された自律性（earned autonomy）」**という設定を研究しました。

ルールは：

エージェントは最初ゼロの事前定義済み関数から始まる
人間はビジュアル出力だけを見てフィードバックを与える
フィードバックをもとにエージェントが再利用可能な関数ライブラリを自分で積み上げていく

タスクはBlenderを使った3Dシーン生成。空間的な推論とプログラム的な幾何学制御が両方必要な、かなり複雑な課題です。

何が起きたか

結果は衝撃的でした：複数の指示粒度で試しても、出力のみのフィードバックでは完全シーン成功率0%。

「完全な成功」の定義は：

オブジェクトの完全性（必要なものが全部ある）
地面との接触（物体がちゃんと床に乗っている）
衝突回避（物体が重ならない）
スケールの妥当性（大きさがおかしくない）

これを全部同時に満たす必要があります。エージェントは人間の実装と同等のユーティリティ関数を自力で再発見したにもかかわらず、完全成功はゼロ。

なぜ直らないのか：観測可能性ギャップ

論文が提示する説明がこれです：

バグの発生源：コードロジック・実行状態（内部）
人間の評価場所：ビジュアル出力（外部）

この二層の間に**「観測可能性ギャップ（observability gap）」**があります。

問題の核心は「多対一写像」です。内部状態の組み合わせは無数にあるが、見える出力は一つ。同じように見える失敗が、全く異なる原因から来ている可能性があります。

これが何を起こすか：

「床に物体が接していない」という症状を見る
← でも原因は座標計算のバグかもしれないし、スケール設定のバグかもしれないし、関数の呼び出し順序のバグかもしれない
症状レベルのフィードバックでは根本原因を特定できない
エージェントは対処を繰り返すが、収束せず失敗モードが振動する

介入実験で確かめた

重要なのが「診断的介入」の実験です。

最小限のコードレベルの知識を注入したところ——収束が回復した。

これが示すこと：問題はエージェントのプログラミング能力ではなく、フィードバックの観測可能性がボトルネックだということです。

論文の結論：フィードバックパラドックス

論文はこれを「フィードバックパラドックス」として定式化します：

コードロジックと知覚的結果の間に深い因果連鎖がある領域では、出力のみの評価では効果的な人間-エージェント協調ができない。

解決策として論文が提案するのは：出力評価を超えた中間的な観測可能性（intermediate observability）。

ソフトウェアエンジニアとして感じること

「動かない」は根本原因じゃない

エンジニアとして普段のデバッグを考えると、この論文の指摘は当たり前のことを言っているように聞こえます。症状と原因は別物——これはソフトウェア開発の基本です。

でも、AIコーディングエージェントを使うとき、自分はこの基本を忘れています。

× 「このコードは動かない」
× 「テストが落ちてる」
× 「エラーメッセージが出る」

これは全部症状です。原因ではない。

通常のバグ調査なら、スタックトレースを読んで、変数の状態を確認して、どの処理がどういう入力でどういう状態になったから失敗したか——を特定してから直します。エージェントへのフィードバックは、この「根本原因の特定」をすっ飛ばした状態で渡していることが多い。

「再現手順」なしに直せるデバッガーはいない

論文で言う「多対一写像」の問題は、エンジニアの言葉で言い換えると再現条件の特定不能です。

同じように見える実行結果の失敗が：

型変換のバグから来ているのか
ロジックの前提条件が満たされていないのか
外部依存の状態が想定外なのか

出力だけを見ても区別できません。

人間のエンジニアだって、再現手順・入力・期待値・実際の挙動のセットがなければデバッグできません。AIエージェントも同じです。「動かない」という情報だけでは、根本原因を特定するための情報が足りていない。

エージェントに渡す情報の質が、解決の質を決める

この論文の「診断的介入でコードレベルの知識を注入したら収束した」という実験結果は、実用的に重要な示唆を含んでいます。

エージェントへのフィードバックを、より「上流」の情報に切り替えると収束する。

具体的には：

フィードバックの層	例
出力層（論文が問題にする）	「表示がおかしい」「テストが落ちてる」
実行状態層	「この変数がnullになっている」「この関数がこの入力を受け取っている」
ロジック層	「この処理はXという前提で書かれているがYが渡されてくる」
設計層	「この処理はAとBの整合性を保つ責任を持つべきだが持っていない」

下から上に情報を渡すほど、エージェントは正確な修正を生成しやすい。

AIツールを使いこなすということの意味

AI coding assistantが普及してから、「エンジニアの仕事は自然言語で指示を出すことになる」という話をよく聞きます。でもこの論文はそれに対する反論になっています。

自然言語で指示を出す能力は、問題の根本原因を言語化できる能力に依存する。

「バグを直して」という指示は簡単です。でも「この関数はXという仮定のもとで書かれているが、呼び出し元がその仮定を壊している。直すべきは呼び出し元の入力処理か、この関数の前処理か」という指示は、コードを理解していないと出せません。

エージェントのコーディング能力が上がるほど、人間に求められるのはコードを書く能力よりも問題の構造を観察し言語化する能力になっていく——そういう方向に変化しているように感じます。

observabilityはシステムだけでなく開発プロセスにも必要

ソフトウェアエンジニアリングで「observability（観測可能性）」というと、プロダクションのシステム監視を指すことが多いです。ログ・トレース・メトリクスで内部状態を可視化して、異常を検知し原因を特定する。

この論文は、開発プロセス自体にもobservabilityが必要だと言っています。

エージェントへの指示と出力の記録だけでなく、途中のコード状態・実行状態・エラーの詳細を「観測できる状態」にしておくことが、収束を可能にする。

CI/CDパイプラインでテスト結果だけを見るのではなく、カバレッジ・実行時間・依存関係の変化も追うのと同じ発想です。

マルチエージェント自己組織化論文との接続

以前読んだ自己組織化論文では「強力なモデルはミッションだけ与えれば自己組織化する」という話でした。

この論文はその続きにあたる問いを立てています：モデルがどれだけ能力を持っていても、人間のフィードバックが内部状態を観測できていなければ協調は収束しない。

エージェントの自律性を高めることと、人間側の観測能力を高めることは、別々に解くべき問題です。

おわりに

「出力を見てフィードバックする」という自然な行為が構造的に限界を持つ——この論文はその理由をはっきり言語化してくれました。

エンジニアとして感じるのは、これはAIエージェント固有の話ではなく、デバッグの基本原則がそのままここにも適用されるということです。症状を渡すのではなく、原因に近い層の情報を渡す。再現条件を絞り込む。内部状態を可視化する。

AIツールがどれだけ賢くなっても、問題の構造を観察し言語化する能力はエンジニア側に求められ続けます。むしろそこがより重要になっていく。

個人的な話をすると、私はエンジニアになってまだ半年です。この記事で書いた「ロジック層」「設計層」のフィードバックを出せるようになるためには、まだまだ自分がその層を理解していく必要があります。

観測可能性ギャップは、モデルの問題だけでなく自分自身の知識の深さの問題でもある——それを実感しています。

ただ、少し前向きに考えると、その「深い層の理解」をAIと一緒に学んでいけるようになれば面白いなとも思います。コードを書いてもらうだけじゃなく、「なぜこの設計なのか」「この失敗の根本原因はどの層にあるのか」を一緒に掘り下げていく——そういうAIとの付き合い方が、エンジニアとしての成長とAIの活用を同時に進める道になるかもしれない。

AIに「動かない」と伝え続けても直らないのはなぜか