エージェント型デザインは制御インターフェースのデザインです

多くの AI インターフェースは、いまだにエージェントを「少し賢いテキストボックス」として扱っています。エージェント型デザインは、まったく別の前提から始まります。ソフトウェアが時間をかけて動き、ツールを呼び出し、ファイルに触れ、費用を使い、本番環境の状態を変えられるようになった時点で、デザイン上の問題は制御インターフェースの問題になります。

エージェント型デザインとは、自律的に動くソフトウェアを可視化し、中断可能にし、検査でき、元に戻せ、信頼に値するものにするための規律です。 プロダクトの中心はチャットの履歴ではありません。人間が、エージェントが今何をしているのかを理解し、次に何を許可するかを決め、すでに行ったことを検証できる画面こそがプロダクトです。

この見方が重要なのは、エージェントの失敗が通常のフォーム、ダッシュボード、コパイロットとは違う形で起きるからです。フォームは送信時に失敗します。ダッシュボードは古いデータを表示して失敗します。コパイロットはよくない文章を提案して失敗します。エージェントは動きの中で失敗します。間違った分岐を選ぶ、間違ったツールを選ぶ、必要な証拠を見落とす、文脈を失う、権限を使いすぎる、早く止まりすぎる、あるいは局所的には成功してもプロダクト全体を弱くしてしまうのです。

デザインは、プロンプトの磨き込みから運用上の制御へ移らなければなりません。

要約

エージェント型デザインは、抽象的な「AI の UX」ではありません。動作するシステムのための制御インターフェースを設計することです。Microsoft は、現在のコーディングエージェントが登場する何年も前から、人間と AI のやり取りを独立したインターフェースデザイン上の問題として位置づけていました。Google PAIR も、AI デザインのガイドで同じ人間中心の流れを保っています。¹² 現代のエージェントプロダクトは、その必要性をさらに明確にしています。OpenAI は Codex を隔離環境で動くクラウドエージェントと説明しており、Claude Code は実行前にツール呼び出しへ割り込めるフックを公開しています。⁵⁴

実務上の結論は明快です。エージェントプロダクトには、状態、権限、実行記録、メモリ、証拠、ロールバック、監督のための画面が必要です。チャットは入力として残せます。しかし、インターフェース全体をチャットだけにしておくことはできません。

重要なポイント

プロダクトデザイナーへ: - プロンプト入力をデザインする前に、エージェントの状態をデザインしましょう。ユーザーは、エージェントが計画中なのか、実行中なのか、行き詰まっているのか、待機中なのか、検証中なのか、完了したのかを知る必要があります。 - 権限確認を主要なワークフローとして扱いましょう。危険なツール呼び出しを、気軽なチャットの割り込みのように見せるべきではありません。

エージェント開発者へ: - 実行記録の画面を成立させるだけの詳細を記録しましょう。ツール名だけでは足りません。引数、出力、終了状態、ファイルパス、副作用が必要です。 - 中断と復旧を一級の機能にしましょう。ユーザーは、すべての履歴を読まなくても、エージェントを一時停止し、検査し、方向修正し、ロールバックし、分岐できるべきです。

エージェントを導入するチームへ: - インターフェースの品質を、チャットがどれほど流暢に感じられるかで測らないでください。運用者が「何が起きたのか、なぜ起きたのか、どの権限で行われたのか、どんな証拠があるのか」に答えられるかで測りましょう。 - 判断の質をループの中に残してください。正しいエージェントの動作であっても、整合性、尊厳、プロダクト品質を損なうことがあります。

ユーザーは変わりました

エージェントプロダクトのユーザーは、単なるプロンプト入力者ではありません。ユーザーは運用者になります。

プロンプト入力者は答えを求めます。運用者はプロセスを監督します。プロンプト入力者は文章が正しく聞こえるかを気にします。運用者は、システムが正しいファイルに触れたか、正しい情報源を使ったか、必要な制約を守ったか、適切なタイミングで止まったかを気にします。

この違いはインターフェースを変えます。プロンプトボックスは表現に最適化されます。制御インターフェースは、状態、リスク、タイミング、証明に最適化されます。

従来のソフトウェアは、ユーザーがほとんどの状態変更を直接起こすため、プロセスを隠せました。ボタンには「送信」と書かれています。ユーザーがクリックします。アプリが送信します。エージェント型ソフトウェアでは、意図と行動の間に意思決定を行う実行環境が入ります。ユーザーは結果を求め、システムが経路を選びます。だからこそインターフェースは、その結果にユーザーが責任を持ち続けられるだけの経路を見せる必要があります。

Microsoft の人間と AI のインタラクションに関するガイドラインは、この方向を示しています。そこでは、期待値の設定、社会的文脈との整合、状態表示、修正の支援、失敗時の対応など、やり取りの時間軸全体にわたる AI システムの振る舞いが扱われています。¹ この古い教訓はエージェントにもそのまま当てはまります。ただし、エージェントでは AI の振る舞いが提案で終わらず、ツール呼び出しになり得るため、重要度がさらに高まります。

エージェント型デザインは状態から始まります

よいエージェント型デザインは、信頼を求める前に状態を見せます。

エージェントの状態は、「考え中」と「完了」だけではありません。

多くのチャットプロダクトは、これらの状態をひとつのアニメーション付きスピナーに潰してしまいます。スピナーが伝えるのは、システムがまだ止まっていないということだけです。エージェントが読んでいるのか、書いているのか、待っているのか、再試行しているのか、行き詰まっているのかは分かりません。

エージェントの状態には、より豊かな語彙が必要です。画面には、現在の段階、直近の意味ある行動、次に予定している行動、まだ終わっていない理由を表示するべきです。よい状態表示は、謎を検査可能な動きに置き換えるため、ユーザーの不安を減らします。

難しいのは密度です。本格的なエージェントは、長い実行中に何千ものイベントを生成します。すべてを見せればノイズになります。すべてを隠せば盲目的な信頼になります。制御インターフェースは、標準では要約し、必要に応じて展開できなければなりません。

権限はデザイン素材です

権限は設定ページではありません。権限は、エージェント型デザインの中心的な素材のひとつです。

エージェントは、ユーザーが与えた権限を通じて行動します。ファイル書き込み、シェルコマンド、ブラウザ操作、API 呼び出し、デプロイ手順、決済操作、顧客に影響する操作は、それぞれリスクが異なります。インターフェースは、判断の瞬間にそのリスクを読み取れるようにする必要があります。

Claude Code のフック参照は、この考え方の原始的な形を示しています。PreToolUse フックは Bash コマンドを検査し、ツール呼び出しが実行される前に破壊的な操作を拒否する判断を返せます。⁴ この仕組みは、デザインの形を証明しています。制御インターフェースは、保留中の操作をリスク順に並べ、完全なコマンドやツールのペイロードを表示し、その呼び出しの理由を説明し、承認、拒否、延期、書き換えを可能にできます。

重要な転換は、権限確認を割り込みではなくキューにすることです。

割り込みは、1つか2つの判断には機能します。しかし、長いタスクの中でエージェントが40件の操作を行う場合には破綻します。権限キューがあれば、ユーザーは低リスクの承認をまとめて処理し、高リスクの操作を一時停止し、全体のリスクプロファイルをひとつの場所で確認できます。エージェントの文章を読むこととコマンドを評価することの間で、ユーザーが何度も引っ張られずに済みます。

リスクの見せ方にも判断の質が必要です。赤い枠、警告アイコン、モーダルによる摩擦は役に立つことがあります。一方で、すべてが緊急に見えると、ユーザーに警告を機械的に承認する習慣を植え付けてしまいます。視覚的な警告は、元に戻せない操作や外部から見える操作に限るべきです。読み取り専用の検索が、本番データベース移行と同じ装いである必要はありません。

実行記録が新しい情報設計です

エージェント型デザインには、実行記録の設計が必要です。

実行記録とは、エージェントが行ったことの順序立った記録です。プロンプト、ツール呼び出し、引数、読んだファイル、変更したファイル、実行したコマンド、開いた情報源、テスト出力、権限判断、再試行、最終的な証拠が含まれます。チャット履歴にはその一部が含まれることがありますが、履歴は情報設計ではありません。ただのスクロールです。

実行記録の画面は、次の4つの問いにすばやく答えられるべきです。

この画面は、証拠ゲートに直接つながります。「テストは通りました」という最終回答は、テストコマンドと終了ステータスを指すべきです。論文を引用する公開記事は、正確な情報源と主張の対応を示すべきです。同等性を主張する移行レポートは、今も動いている具体的なユーザー経路を指すべきです。

最近の実行記録に関する研究も同じ方向を示しています。エージェントの実行記録は実行環境の契約であるで述べたように、最終回答は信頼する単位として最も弱いものです。実行記録のほうが強いのは、意図から行動、証拠までの経路を保持しているからです。

メモリにはブラウザが必要です

エージェント型デザインには、メモリのデザインも必要です。

エージェントは時間をまたいで文脈を持ち運びます。一部の文脈はアクティブなウィンドウにあります。一部は圧縮された要約にあります。一部はファイル、メモ、ベクトルストア、データベース、プロジェクト指示にあります。そして一部は消えます。ユーザーがその境界を見ることはほとんどありません。

この見えなさは、デザイン上の失敗を生みます。エージェントが以前の判断と矛盾したとき、ユーザーには、エージェントが反対したのか、忘れたのか、要約が悪かったのか、そもそも関連するメモリを読み込んでいなかったのかが分かりません。実行環境がモデルに見えるものを変えていても、チャットはメモリが連続しているように感じさせます。

メモリブラウザは、3つの層を見せるべきです。

このブラウザは、非公開の思考過程を明かす必要はありません。明かすべきなのは運用上のメモリです。今後の行動を導くためにシステムが使う指示、制約、情報源のパス、判断、成果物、要約です。

検索も同じデザイン領域に属します。前の記事で見た grep/vector の結果は、検索品質が検索器だけでなく、実行環境、結果の渡し方、モデルがツールのループを閉じられるかに左右されることを示していました。⁶ 検索が実行環境にあるなら、検索の可視性はインターフェースに属します。ユーザーは、エージェントが何を検索し、何を見落とし、何を開き、なぜ次のクエリを変えたのかを知る必要があります。

監督は細かな管理ではありません

エージェントプロダクトでは、人間による監督が摩擦として扱われることがあります。強いエージェント型デザインは、監督そのものをプロダクトとして扱います。

NIST は AI Risk Management Framework を、AI システムの設計、開発、利用、評価に信頼性の考慮を組み込むための方法として説明しています。³ この言い方は重要です。信頼性は、モデルの学習時だけに入るものではありません。設計時、利用時、評価時にも入ります。

エージェントにおける監督とは、ユーザーが次のことをできるという意味です。

• エージェントが何をしているかを見る。
• 元に戻せない行動の前に中断する。
• 証拠までの経路を検査する。
• 失敗した分岐から復旧する。
• 別の分岐を比較する。
• 最終成果物を承認または却下する。
• 何が未検証のまま残っているかを理解する。

細かな管理は、すべてのキー入力をユーザーに承認させます。監督は、適切な高さで適切な制御を渡します。シニアエンジニアは、すべてのファイル読み取りを見張る必要はありません。しかし、提案されたデータベース移行、失敗したテストの再試行、変更された公開上の主張、本番状態に触れるコマンドは見る必要があります。

よい監督画面は、低リスクの詳細を主経路から外し、高リスクの瞬間を前面に出すことで流れを保ちます。デザイン上の課題は「もっと見えるようにすること」ではありません。課題は、調整された可視性です。

判断の質は今も重要です

エージェント型デザインは、運用上の要件をすべて満たしても、なお間違った感触になることがあります。

権限キューは正しい事実を示しながら、ユーザーに罰を受けているような感覚を与えるかもしれません。実行記録のタイムラインはすべてのイベントを含みながら、理解不能になるかもしれません。メモリブラウザは保存された項目をすべて表示しながら、散らかりによってユーザーの信頼を壊すかもしれません。状態メーターは真実を伝えながら、システムが壊れているように感じさせるかもしれません。

判断の質は、リスク、確信、不確実性、証明を画面がどう運ぶかを決めます。判断の質は技術システムである。制約、評価基準、パターン認識、整合性です。エージェント型デザインには、この4つすべてが必要です。

制約は、エージェントが確認なしに何をしてよいかを決めます。評価基準は、最終成果物が何を証明しなければならないかを決めます。パターン認識は、成功しているように見えても脆く感じるワークフローを捉えます。整合性は、エージェントの仕事がプロダクト全体を良くしたのか、それとも局所的なタスクを終えただけなのかを問います。

エージェントが安価になるほど、最後の問いは重要になります。AI は出力を豊富にします。豊富さは、拒否、編集、整合性、判断の価値を上げます。最良のエージェントインターフェースは、行動数を最大化しません。どの行動が実行に値するのかを、運用者が判断できるようにします。

最小限のエージェント型デザインチェックリスト

まずは7つの画面から始めます。

これらの画面に、SF 的なインターフェースは必要ありません。最初の版は、普通のテーブル、展開できる行、地味なフィルターで十分です。凝ったアニメーションより、正直な状態表示のほうが重要です。制御インターフェースは、すばやく真実を伝えるべきです。

すべてのエージェント機能に対するデザイン上の問いは、シンプルになります。

エージェントの次の行動が現実になる前に、人間は何を見て、何を決め、何を中断し、何を検証する必要があるのか？

インターフェースがこの問いに答えられないなら、そのプロダクトはまだ信頼の演出に依存しています。

短いまとめ

エージェント型デザインは、制御インターフェースのデザインです。チャットは入力の基本要素として有用ですが、自律的な作業には、見える状態、権限キュー、実行記録、メモリブラウザ、証拠画面、復旧操作、監督ビューが必要です。Microsoft、Google、NIST はいずれも、人間中心の AI デザインと信頼性を、モデルの性質だけでなくプロダクトの責任として示しています。¹²³ エージェントツールは、その点を具体化します。実行環境にはすでに、フック、コンテナ、実行記録、ファイル、コマンド、副作用があります。⁴⁵ インターフェースは、それらを読み取れる形にしなければなりません。

勝つエージェントプロダクトは、最も魅力的なチャットを持つものではありません。自律的な作業に対して、運用者に最も明快で鋭く、信頼できる画面を渡すものです。

FAQ

エージェント型デザインは AI UX と違いますか？

はい。AI UX は、機械学習や生成 AI を使うあらゆる体験を含みます。エージェント型デザインは、時間をかけて動作するシステムを扱います。違いは行為主体性です。ツール呼び出し、権限、状態変更、メモリ、副作用、復旧。これらの性質には、親切なコピーやプロンプト入力だけでなく、制御インターフェースが必要です。

すべてのエージェントプロダクトに7つの画面が必要ですか？

いいえ。必要な画面の範囲はリスクに合わせるべきです。低リスクの文章支援ツールなら、状態、証拠、改訂履歴で足りるかもしれません。コーディングや運用のエージェントには、権限、実行記録、復旧、メモリ、監督が必要です。顧客に影響するエージェントには、さらに強い監査と承認の制御が必要になります。

なぜすべてをチャットに残さないのですか？

チャットは逐次的で、追記型です。エージェントの監督には、ランダムアクセス、絞り込み、比較、一括確認、状態検査が必要です。折りたたみ可能なチャットブロックは読みやすさを改善できますが、権限キュー、実行記録のタイムライン、メモリブラウザ、復旧画面の代わりにはなりません。

最初に作るべき制御インターフェースは何ですか？

まず実行記録を作りましょう。実行記録がなければ、ほかの画面はすべて推測になります。実行記録は、証拠、権限、復旧、監査、監督のためのデータを供給します。プロダクトは、普通のイベントテーブルから始め、時間をかけてデザインを改善できます。

参考文献