インターフェースがAIの使い方を形作っている
AIを開き、難しい仕事を任せようとする。入力欄に「ホームページを作り直して」と書いて送信する。すると、すぐに質問が返ってくる。どんな雰囲気にしたいのか。どのページを変更するのか。モバイル対応はどうするのか。参考サイトはあるか。先にコードを読んだほうがよいか。
どれも筋の通った質問だ。厄介なのは、私たちが一つずつ答え始めることにある。配色について答えた直後に、今度はフォントを聞かれる。ホームページの説明を終えると、次はナビゲーションの確認が来る。画面はいつまでもスクロールし続け、人もその前を離れられない。任せるつもりだった仕事が、最初から最後まで付き添いを要する遠隔操作に変わってしまう。
多くの人がAgentを使うときにぶつかる問題について、モデルに責任があるのは一部だけだと、私は考えるようになった。あの細長いチャットボックスもまた、私たちの振る舞い方を教えている。
チャットボックスは仕事を細切れにする
チャットボックスは質疑応答に向いている。一方が一言送れば、相手が一言返す。返事が速いほど、たいてい体験はよく感じられる。小さな入力欄、常に明るく表示された送信ボタン、画面に一文字ずつ現れる回答。こうしたデザインは、早く何かを書き、返事を待ち、また続きを書くよう人を促す。
複雑な仕事には別のリズムが必要だ。コードの作業を引き受ける人は、少なくとも変更する理由、どこまで変更するのか、触れてはいけない箇所を知る必要がある。何をもって完了とするかも把握しなければならない。関連するコード、デザイン案、過去の議論、テストコマンドを置く場所も要る。資料を読み終えたら、変更し、実行し、失敗を経て、また修正するためのまとまった時間が必要になる。
チャットボックスは、まず不完全な一言を送り、足りない内容を後から補うよう促す。その結果、仕事は何度ものやり取りに分断される。Agentは数歩進むたびに質問しに戻り、人はしばらくするたびにウィンドウへ戻って様子を見る。モデルはずっと働いているのかもしれないが、人の注意は小さな質問のたびに引き裂かれる。
結果がよくないと、プロンプトに原因を求め、役割設定や制約の書き方、さまざまなプロンプトの技法を学ぶ人は多い。こうした技法は確かに役に立つ。同じ人でも、メールに切り替えると、たいてい自然に詳しく書くようになる。相手がすぐには返信しないとわかっているため、背景をあらかじめ説明し、ファイルを添付し、期限を明記する。どのような成果を受け取りたいかも、その場で伝える。
文章力が急に上がったわけではない。インターフェースがその人の予想を変えたのだ。
仕事を一通の手紙として書く
いまでは、チャットボックスの中でも意識してメールのように書く人がいる。最初に完全な作業説明を用意し、リポジトリとファイルのパスを示す。参考資料を添え、変更してはいけない範囲を列挙し、検収方法まで明記する。送信したらウィンドウを閉じ、Agent自身にコードを読ませ、ファイルを変更させ、テストを実行させる。人の判断が必要な選択にぶつかったときだけ、Agentは作業を止めて質問する。
この使い方には、いくらか不自然さが残る。仕事を実行できるAgentを手に入れたのに、製品のインターフェースが発する合図に逆らい、チャットのように半端な一言だけを書かないよう自分に言い聞かせなければならない。
Agentに渡せる作業説明に、複雑な書式を研究する必要はない。いくつかの実務的な問いに答えればよい。
まず、今回の作業が必要な理由を明確にする。次に、最終的な成果物と、変更の対象外となる範囲を伝える。コード、文書、参考資料の場所を示し、実行できる確認方法を書く。一般的な細部については、リポジトリにすでにあるやり方に従って最後まで進めてよいと伝える。答えによって製品の方向性が大きく変わる場合、セキュリティ上のリスクが生じる場合、取り消せない操作が必要な場合に限り、人へ確認を戻せばよい。
これは日常の仕事における委任によく似ている。上司は、一行変更するたびに報告するよう同僚に求めたりしない。最初に目標と権限を明確にし、どんな状況では必ず報告するかを決め、最後に結果を確認する。Agentにも独立した作業環境があり、資料を読み、ファイルを変更し、テストを実行できるのなら、同じリズムで働くべきだ。
よいAgentのインターフェースは、人が席を離れられるようにする
私が望むAgentのインターフェースは、タスクの受信箱と作業台を組み合わせたものに近い。
タスクの受信箱では、説明、添付資料、検収条件を受け取る。作業台には、実行状況、コードの変更、テスト結果、重要な判断を保存する。人はタスクを送ったら、その場を離れられる。Agentは静かに働き、完了したら結果を返す。行き詰まったときにも、すでに調べた資料と十分に具体的な質問を携えて戻るべきだ。そうすれば、人が文脈全体を一からたどり直さずに済む。
このような製品でも、作業の過程を隠す必要はない。ログ、ファイルの変更、中間成果物は引き続き確認できる。ただし、人に見続けることを求めない。状態表示も複雑でなくてよい。「実行中」「判断待ち」「検収可能」の三つで、たいていは足りる。方向性、選択、最終的な検収は人が担い、常時監視する役目はなくせる。
これは製品の良し悪しを測る基準も変える。チャット製品では、返答の速さ、会話の往復回数、ユーザーの滞在時間が重視されやすい。タスク型のAgentが目指すべきなのは、中断を減らし、人が操作する時間を短くし、一度の依頼で完了まで届けられる割合を高めることだ。タスクを送った人が別のことをし、しばらくしてから戻って検収する。それはまさに、ツールがその人に代わって仕事を引き受けた証拠になる。
一人が複数のAgentを同時に使うようになると、チャットボックスの問題はいっそう明らかになる。十数個のウィンドウから代わる代わる質問が飛び出せば、ユーザーはたちまち誰よりも忙しい伝言係になる。そのとき必要なのは、統一されたタスクリストと例外を報告する仕組みだ。通常の選択は、取り決めに従ってAgentが処理する。予算超過、権限不足、意図が不明確な場合にだけ、人へ通知すればよい。
チャットには今も役割がある
アイデアについて議論する、一つの説明をさらに尋ねる、まだ形になっていない問題を一緒に整理する。そうした場面ではチャットがよく機能する。タスクの開始時にも、人とAgentが方向性を定めるために数回やり取りすることはあるだろう。方向が明確になったら、仕事は実行段階に移るべきだ。チャットはその中の一工程であり、すべての過程を引き受ける必要はない。
私たちは長い時間をかけて、AIとの話し方を学んできた。次は、一度で十分に伝える練習ができる。必要な資料を渡し、範囲と検収方法を決めたら、自分が画面を離れることを許せばよい。
こうしたインターフェースは、タスクを一度で送信できるか、ページを離れられるか、本当に判断が必要なときだけ戻ればよいかで評価できる。この三つを満たして初めて、チャットボックスは仕事全体のリズムを決める存在ではなくなる。
本稿は、Yage氏の記事「チャットボックスの幻想」から着想を得た。
https://yage.ai/share/chat-box-illusion-agent-interface-20260710.html