この記事の勘どころ
AIへの依頼では、答えだけでなく、どの範囲まで考えるかも人間が渡す。
よくあるつまずき
AIに小さな修正を頼んだだけなのに、関係ありそうなファイルを次々に読み始めることがあります。丁寧なのはありがたい一方で、こちらの気持ちとしては「そこまで大きな調査ではないんだけどな」と少し疲れます。
今回の研究は、その違和感に名前をつけてくれます。問題は、AIが賢くないことではなく、作業がどれくらい小さいかを先に見積もれていないことにあります。小さな置換と、全体設計に触る変更では、最初に集める文脈の量が違うはずです。
日常で生かせる点
研究で提案されている E3 は、Estimate、Execute、Expand の順で進みます。まず作業の広さを見積もり、小さく実行し、検証で足りなかったときだけ範囲を広げる流れです。これは開発だけでなく、文章の添削、資料整理、予定の見直しにも読み替えられます。
たとえば文章の添削なら、「この段落だけ見てください。前後と矛盾しそうなら、そのときだけ前の見出しも見てください」と渡せます。最初から全部を読ませるより、AIも人間も、何を見れば十分かを共有しやすくなります。
手軽にできる第一アクション
今日AIに頼む作業を一つ選び、依頼文の前に三行だけ足してみます。作業の大きさ、最初に見る範囲、広げる条件の三つです。
たとえば「作業の大きさ: 小」「最初に見る範囲: このファイルの該当メソッドだけ」「広げる条件: テストが落ちる、呼び出し元が不明、同じ名前が複数ある場合」と書きます。これだけで、AIに丸ごと調べてもらう依頼から、必要な範囲を一緒に決める依頼へ変わります。
続けるときの見方
返ってきた答えを見るときは、正解かどうかだけでなく、範囲の決め方が合っていたかも残しておきます。狭すぎて漏れたなら、次は広げる条件を足す。広すぎて時間がかかったなら、次は最初に見る範囲を小さくする。
AIに任せるほど、人間の役割は消えるのではなく、入口の設計に寄っていくのだと思います。どこまで見れば十分かを一行で残すことは、未来の自分とAIの両方に渡せる小さな設計メモになります。
暮らしに置き換える
小さく試すなら
次にAIへ依頼する前に、作業の大きさ、最初に見る範囲、広げる条件を三行で書く。返答後に、範囲が狭すぎたか広すぎたかを一言だけ残す。所要時間は5分程度。
役に立つ場面
AIの調査量を減らすだけでなく、どこまで人間が意図を持って任せるかを明確にできる。小さな依頼を小さく済ませたい場面で役立つ。
読むときの余白
深めるなら
- 今日のAI依頼を一つ選び、依頼文の冒頭に「作業の大きさ」を書く。
- 最初に見てほしいファイル、段落、表、メモを一つだけ指定する。
- 足りなかったときに広げる条件を一つ書く。
- 返答後に、範囲指定が狭すぎたか広すぎたかをメモする。
そのまま信じないところ
- 主な結果は capability-controlled simulator と固定したコストモデルでの評価であり、実際のサービス上のすべての agent にそのまま当てはまるとは限らない。
- MSE-Bench は121件の制御された編集課題で構成され、実務にある動的な依存、設定の絡み、曖昧な要件をすべて含むわけではない。
- 実モデル検証は gpt-4o と小規模な real-code harness に限られ、モデルやプロバイダを広げた検証は今後の課題として残る。
- 範囲を狭くしすぎると必要な文脈を見落とすため、検証と広げる条件を一緒に置く必要がある。