Elvis SaraviaのタスクファーストAIエージェントが、デフォルトインターフェースとしてのプロンプトに挑む

Elvis Saraviaは、明確なインターフェースの転換を提案している。それは、単独のプロンプトを、完全なマルチモーダル・タスクパッケージに置き換えるというものだ。彼のタスクファースト提案では、AIエージェントが作業を開始する前に、音声、画面、テキスト、注釈を組み合わせる。

これは入力設計上の小さな変更のように聞こえる。しかし実際には、ChatGPTの登場以来、生成AIを特徴づけてきたチャットボックスへの挑戦である。Elvis SaraviaのタスクファーストAIエージェントの中心的な考え方は、ユーザーが関連するあらゆるシグナルを一度に用いて仕事を説明すべきだというものだ。

このアプローチは、Andrej Karpathyが長時間の音声会話を情報豊富なプロンプトとして活用したことから着想を得たとされる。Saraviaは、音声をインターフェース全体ではなく、構造化されたタスクの一要素として扱うことで、この概念をさらに発展させている。

対抗するのは、従来のプロンプトと修正のループだ。現在、ユーザーは不完全な指示を送信し、不十分な結果を確認し、不足しているコンテキストを追加して、このプロセスを繰り返す。タスクファーストのインターフェースは、その確認作業を最初に移そうとする。

この提案は、独立した評価を受けた製品リリースではなく、依然として一つの主張にとどまっている。どれだけ時間を節約できるのか、どのモデルが最適に対応するのか、追加のコンテキストがどの程度の頻度で新たなエラーを引き起こすのかを示す公開ベンチマークは、まだ存在しない。

それでも、このタイミングには意味がある。AIエージェントは現在、ソフトウェアを操作し、ツールを呼び出し、画面を確認し、より長時間の作業セッションを維持できる。その最も弱い部分は、ユーザーの意図と、実行のために構築されたコンテキストとの間にますます集中している。

プロンプトからタスクへ：Saraviaが提案しているもの

重要な変化は、プロンプトを長くすることではない。意図を伝えるための新しいコンテナを導入することだ。

従来のプロンプトは通常、テキストとしてモデルに入力される。たとえユーザーの本当の目的が、複数のアプリケーション、ファイル、過去の決定に依存していても同様だ。ユーザーは、その環境を言葉に置き換えなければならない。

Saraviaの提案は、その負担を逆転させる。インターフェースが周辺の証拠を取得し、実行開始前に一つのタスクパッケージとして提供すべきだという。

そのパッケージには、音声による説明、選択したテキスト、現在表示中の画面、視覚的な注釈、ドキュメント、そして明示的な完了条件を含められる。それぞれの入力が、ユーザーの意図の異なる部分を伝える。

音声は、入力時には省略されがちな物語的な詳細を伝える。画面は、議論の対象を示す。ハイライトや注釈は、注意が必要な正確な領域を特定する。

テキストは、正確な要件、名前、日付、数式、制約を示すうえで引き続き有用だ。添付資料は、エージェントが推測するのではなく参照すべき証拠を提供する。

週次報告を準備しているプロダクトマネージャーを考えてみよう。テキストプロンプトでは、「プロジェクトを要約し、リスクを特定してください」と指示するかもしれない。この指示だけでは、どのプロジェクトか、どの期間か、どのリスクが重要なのかをエージェントが確認しなければならない。

タスクファーストのインターフェースなら、現在のロードマップ、ハイライトされた分析チャート、遅延している統合についての音声説明、最新レビューのメモを一つにまとめられる。期待する出力形式も指定できる。

エージェントは、マネージャーが実際に持つメンタルモデルにより近いものを受け取る。マネージャーがすでに把握している情報を発見するために、何度もやり取りする必要はない。

このアプローチは、タスクとメッセージを区別する。メッセージは会話における一つの発言だが、タスクは、望ましい成果とそれを支えるコンテキストを体系化して表現したものだ。

システムがアクションを実行できる場合、この違いは重要になる。文章作成アシスタントなら、もう一度下書きを作ることで曖昧さから回復できる。ファイルを編集したりソフトウェアを更新したりするエージェントでは、曖昧さが操作上のミスにつながり得る。

この提案はまた、インターフェース設計をエージェントスタックの一部に位置づける。モデルの品質は依然として重要だが、どのシグナルをモデルに届け、どのように整理するかはアプリケーションが決定する。

これは、プロンプトエンジニアリングからコンテキストエンジニアリングへの、より広範な移行と一致している。Anthropicはコンテキストエンジニアリングを、推論中にモデルが利用できる情報を選定・構成することと定義している。

この定義では、プロンプトは入力の一つにすぎない。ツールの説明、取得されたドキュメント、メッセージ履歴、現在の状態、外部データのすべてが、限られた注意を奪い合う。

Elvis SaraviaのタスクファーストAIエージェントは、この原則をユーザーインターフェースに適用する。フロントエンドは、モデルが推論ループを開始する前に、有用なコンテキストを収集する役割を担う。

そこに、この提案の本当の意義がある。コミュニケーションの質を、完璧な一文を書く競争ではなく、システム上の問題として扱っているのだ。

AIエージェントの効率がコンテキストに左右される理由

エージェントが失敗する原因は、さらに巧妙な指示が不足していることではなく、仕事を不完全な形でしか伝えられていないことにますます集中している。

モデルが主に質問に回答したり、範囲の限定された文章を生成したりしていた頃、チャットインターフェースはうまく機能していた。ユーザーは、次に何をするか決める前に各回答を確認できた。

エージェントの動作は異なる。複数のステップにまたがって計画し、ツールを使用し、状態を変更し、中間結果に反応する。そのため、初期段階の曖昧さがシーケンス全体に波及する可能性がある。

エージェントが顧客からのフィードバックと製品ロードマップを照合しなければならないとしよう。必要なのは、関連するフィードバック、ロードマップのバージョン、会社の優先事項、担当範囲、そして実行可能な発見の定義だ。

短いプロンプトに、この5つすべてが含まれることはほとんどない。その結果、ユーザーはコンテキストの運び役となり、アプリケーション間で情報を移動し、エージェントが意図しない解釈に従うたびに修正することになる。

この繰り返しの修復には、見えにくいコストがある。確認のたびにユーザーの注意力を消費し、会話を長くし、矛盾する指示が加わる新たな可能性を生む。

コンテキストウィンドウを大きくしても、問題が自動的に解決するわけではない。容量が示すのは、モデルがどれだけの情報を受け取れるかであり、アプリケーションが適切な情報を選択したかどうかではない。

Anthropicのコンテキストに関するガイダンスでは、コンテキストは有限であり、価値の高いトークンを選択することが重視されている。この警告は、画像、文字起こし、ツールの出力が多くの容量を消費し得るマルチモーダルタスクに直接当てはまる。

したがって、新たに浮上しているインターフェース上の課題は、選択的な完全性である。エージェントにはタスクを理解するのに十分なコンテキストが必要だが、ユーザーのワークスペースにあるすべての成果物が必要なわけではない。

画面を認識するアシスタンスに関する研究は、その根底にある仕組みを裏づけている。以前の画面コンテキスト研究では、視覚的なインターフェース情報によって、画面上のオブジェクトを指す音声表現の曖昧さを解消できることが示された。

この発見は現在の生成AIエージェントより前のものだが、インタラクション上の問題には今も共通点がある。システムがユーザーと同じ画面を見られれば、「このセクションをあのチャートの下に移動して」という指示を理解できる。

より新しい証拠は、より広範な意図認識がいかに難しいかを浮き彫りにしている。GoogleのGUIDEベンチマークでは、10種類の複雑なアプリケーションを操作する120人の初心者ユーザーから収集した、67.5時間の画面録画を使用している。

8つのマルチモーダルモデルのうち、報告された最高結果でも、行動状態の検出は44.6%、支援予測は55.0%にとどまった。構造化されたユーザーコンテキストを提供すると、支援予測は最大50.2%向上した。

これらの結果が、Saraviaの提案を直接検証しているわけではない。GUIDEが評価するのはインターフェース上のワークフロー中の支援であり、ソーシャルメディアへの投稿で説明された具体的なタスクパッケージではない。

ただし、このベンチマークは、より限定的な結論を裏づけている。ユーザーの行動と意図に関する明示的な情報を受け取るとモデルの性能は向上するものの、その詳細を確実に推測することには依然として苦戦している。

これは、コンピューター操作エージェントを構築するすべての企業に圧力をかける。OpenAI、Anthropic、Google、Microsoft、独立系開発者はモデルを改善できるが、ユーザーの意図を捉えるためのより良い方法も必要としている。

職場向けエージェントにとって、この圧力は差し迫っている。エージェントは、異なる時期に作成された会議、ドキュメント、メッセージ、ダッシュボード、意思決定の間で動作しなければならない。

有用なタスクインターフェースは、ユーザーに履歴全体を手作業で再構築させることなく、それらの情報源を結びつけなければならない。パーソナルナレッジベースは過去の資料の取得に役立つが、情報検索には依然としてタスクレベルの方向づけが必要だ。

だからこそ、タスクファースト設計は単なる音声機能ではない。コンテキストの構築を、仕事を委任する際の目に見える、管理可能な要素にしようとする試みなのだ。

Elvis SaraviaのタスクファーストAIエージェントが修正ループに挑む

この提案が成功するのは、より充実した準備によって、準備そのものが生む作業量以上の作業を削減できる場合に限られる。

従来のエージェントワークフローは、すぐに始められる。ユーザーが一つの指示を入力して出力を受け取り、その後でエージェントが何を誤解したかに気づく。

この初期負担の低さが、プロンプトが長く使われ続けている理由だ。汎用的で、馴染みがあり、実装しやすい。また、単純な依頼を効率的に処理できる。

弱点は複雑な作業で現れる。ユーザーは、最初の結果によって自分でも明確に表現していなかった前提に気づくため、誤った出力を見た後で初めて要件を提示することが多い。

これにより修正ループが生まれる。エージェントが生成し、ユーザーが問題を診断し、コンテキストを追加して、エージェントが再試行する。

Saraviaのタスクファーストモデルは、この診断作業を前倒しする。インターフェースは、最初の結果を生成する前に、複数種類のコンテキストを収集する。

その仕組みは、同僚同士のブリーフィングに似ている。マネージャーはアナリストに単に「数字を確認して」と伝えるだけではない。関連するダッシュボードを示し、意思決定について説明し、議論になっている前提を特定する。

マルチモーダルな入力取得によって、そのブリーフィングを圧縮できる。ユーザーはドキュメントを見ながら話し、矛盾する2つの箇所をハイライトし、その決定の発端となった会議を添付できる。

文字起こしだけでは、発言と画面上のオブジェクトとのつながりが失われる。スクリーンショットだけでは、ユーザーの推論が抜け落ちる。入力を組み合わせれば、両方を保持できる。

注釈は、さらに別のグラウンディング層を加える。チャートを囲む枠、2つのセクションを結ぶ矢印、取り消し線が引かれた段落は、言葉では表現しにくい空間的な関係を伝えられる。

これは、最初の試行にかかるコストの構造を変える。タスクの構築により多くの労力を費やす代わりに、エージェントが実用的な成果を返す可能性が高まる。

それでも、効率性に関する主張は慎重に測定する必要がある。特に、タスクが小規模で簡単に元に戻せる場合、セットアップが長ければ自動的に優れているとは限らない。

定義を尋ねるだけなら、プロンプトのままでよい。ファイルを一つ改名するだけなら、直接コマンドのままでよい。タスクのパッケージ化が有益になるのは、誤解によるコストがコンテキスト構築のコストを上回る場合だ。

このアプローチは、インターフェースが同期をどのように処理するかにも左右される。音声、ポインターの移動、画面の変化、注釈には、タイムスタンプまたは別の共通参照構造が必要になる。

整合が取れていなければ、「この数字を使って」という指示は依然として曖昧になり得る。ユーザーが「これ」と言ったときに、どの画面領域が表示されていたのかをシステムが把握しなければならない。

成熟した実装では、生のシグナルを構造化されたタスク記録に変換することになるだろう。その記録には、目的、関連する成果物、制約、権限、期待される出力、完了条件などを含められる。

そのうえでモデルは、無差別な記録ではなく、選定・整理された表現を受け取る。この違いは重要だ。生のマルチモーダルデータには、ノイズ、重複、個人情報が含まれているからだ。

同じ記録は、可観測性の向上にも役立つ可能性があります。ユーザーと開発者は、エージェントが行動する前にどのようなコンテキストを受け取ったかを確認できます。

この確認レイヤーによって、失敗の診断が容易になります。チームは、コンテキストの不足と、推論の誤り、不適切なツールの使用、信頼性の低い外部システムを区別できます。

再利用にも対応できる可能性があります。適切に構造化されたタスクは、週次レポート、顧客調査、文書レビュー、エンジニアリング上のトリアージのための反復可能なワークフローになり得ます。

ただし、再利用可能なタスクを、添付ファイルが増えただけの硬直したプロンプトテンプレートにしてはなりません。その利点は、特定の業務に関連する状態を保持することから生まれます。

ナレッジワーカーにとって、これは実用的な役割分担を示唆します。永続的なシステムが文書、メモ、会議、過去の意思決定を保持し、タスクインターフェースが現在必要な部分を選択します。

knowledge blending のようなツールは、明確な目的に基づいて個人の情報源を組み合わせる場合、このモデルに適合します。それでもタスクには、境界、権限、求める成果が必要です。

OpenAIのコンピューター操作エージェントは、有用な比較対象です。そのcomputer-use modelはスクリーンショットを処理し、次のステップを推論して、仮想マウスとキーボードを通じて操作します。

OpenAIは、OSWorldで人間の72.4パーセントに対して38.1パーセントの成功率を報告しました。WebArenaでは58.1パーセント、WebVoyagerでは87.0パーセントに達しました。

これらの数値はOpenAI自身の評価によるものであり、それぞれ異なる環境を反映しています。タスクファースト型インターフェースの直接的な尺度として扱うべきではありません。

一方で、印象的なデモンストレーションと信頼できる実務との隔たりは明らかになります。エージェントは画面を理解して操作できても、完全なタスクの多くに失敗する可能性があります。

初期コンテキストを改善すれば、失敗要因の一つを減らせます。しかし、視覚認識の弱さ、不安定なウェブサイト、不十分な計画、実行中の誤操作までは修復できません。

したがって、修正ループがなくなることはありません。より現実的な目標は、開始時の意図不足によって生じる回避可能な修正を減らすことです。

コンテキストの増加は失敗の可能性も増やす

マルチモーダルなタスクは意図を明確にできますが、ノイズ、プライバシーの露出、誤った確信を増幅させる可能性もあります。

最初のリスクはコンテキスト過多です。画面録画、長い音声説明、複数の文書、注釈には、タスクに必要な量を超える情報が含まれる可能性があります。

モデルは、すべてのトークンや視覚的詳細を同等に扱うわけではありません。重要な制約が、繰り返される会話や無関係な画面内容に囲まれることで目立たなくなる可能性があります。

エージェントは強調表示されたグラフに注目する一方、音声で伝えられた締め切りを見落とすかもしれません。また、現在の計画よりも古い決定事項を取得する可能性があります。その文書の方が、テキスト上の一致度が高いためです。

したがって、タスクファースト型システムには優先順位付けが必要です。ユーザーは、必須の指示、背景情報、任意の参考資料を区別できる必要があります。

また、システムにはプロベナンス、つまり各事実がどこから得られたかを示す記録も必要です。正式に確定したポリシーによる主張と、会議の文字起こしに含まれる非公式な発言とでは、重み付けを変えるべきです。

鮮度も別の問題を生みます。月曜日に作成されたタスクパッケージは、火曜日にロードマップが変更されると誤解を招く可能性があります。

永続的なコンテキストを、時間の影響を受けない記憶として扱うべきではありません。アプリケーションには、日付、バージョン情報、重要な操作の前に資料を更新するためのルールが必要です。

画面と音声のキャプチャは、入力されたプロンプトよりも多くの情報を観察するため、プライバシーの問題はさらに深刻です。画面には、非公開メッセージ、アカウント情報、顧客記録、無関係なブラウザータブが映り込む可能性があります。

音声録音には、AIタスクへの参加を意図していない他者の声が含まれる可能性があります。また、背景の会話が指示として誤認される可能性もあります。

最も安全なインターフェースは、キャプチャした内容を正確に表示し、送信前に削除できるようにするものです。デフォルトでデータを最小限に抑え、適切な場合にはローカル処理を維持すべきです。

権限はタスクとともに引き継がれなければなりません。文書へのアクセス権があるからといって、エージェントがそれを外部向けに要約したり、編集したり、別のプロジェクトで使用したりする権限が自動的に与えられるわけではありません。

マルチモーダル入力は、攻撃対象領域も拡大します。悪意のある指示が、ウェブページ、文書、画像、または画面上に表示されたメッセージの中に含まれる可能性があります。

キャプチャされたすべての要素を信頼できるコンテキストとして扱うエージェントは、ユーザーの本来の目的と矛盾する指示に従う可能性があります。タスクのパッケージ化には、ユーザーの指示と信頼できないコンテンツとの明確な境界が必要です。

自律性は、それぞれの弱点を増幅します。チャットボットは誤った回答を返すだけかもしれませんが、コンピューター操作エージェントはメッセージを送信し、文書を変更し、フォームを送信できます。

OpenAIのcomputer-useに関する説明では、エージェントが機密性の高い操作について確認を求めるとされています。初期タスクが完全に見える場合でも、このパターンは不可欠です。

タスクパッケージには、求める成果だけでなく、操作の制限も明記すべきです。「返信を準備する」と「返信を送信する」では、与えられる権限が異なります。

次のリスクは誤った確信です。豊富なコンテキストは、出力をより個別化されたものに見せることはできても、正確性を高めるとは限りません。

洗練されたレポートが正しい会議や文書を引用していても、根拠のない結論を導いている可能性があります。重大な影響を伴う業務では、ユーザーは引き続き証拠へのリンクと確認ポイントを必要とします。

ここでは、GoogleのGUIDEの結果が特に重要です。マルチモーダルなワークフローの証拠があっても、現在のモデルは行動を特定し、支援すべきタイミングを判断することに苦戦しました。

構造化されたコンテキストは性能を改善しましたが、根本的な不確実性を解消したわけではありません。ここから得られる教訓は、入力を増やせばエージェンシーの問題が解決するということではありません。

より重要な教訓は、明示的なコンテキストが根拠のない推測に勝るということです。インターフェースは、すべてのジェスチャーや間を理解したふりをするのではなく、不確かな意図をユーザーに確認すべきです。

コストとレイテンシーも重要です。音声、複数の画面、OCR、注釈、検索結果、ツールの状態を処理するには、短いメッセージを読むよりも多くの計算が必要です。

システムには、タスクに関連する情報を抽出する前処理段階が必要になる場合があります。その段階は、主要なエージェントが処理を始める前に独自のエラーを持ち込みます。

評価では、パイプライン全体を測定しなければなりません。研究者が整理済みのコンテキストを与えた場合にはモデルが良好に機能しても、一般消費者向けインターフェースでは、キャプチャ層が情報を省略したり誤って分類したりして性能が低下する可能性があります。

Saraviaの投稿には、ベンチマーク結果、リファレンス実装、プライバシーアーキテクチャが提示されていません。したがって、効率性に関する主張は信頼に足る仮説ではありますが、確立された成果ではありません。

この提案は、タスク完了率、修正回数、ユーザーの経過時間、エラーの重大度によって評価すべきです。出力品質だけでは、タスクを準備するコストを捉えられません。

また、強力なテキストベースラインとも比較すべきです。目的、情報源、制約、完了条件を記載した短いフォームで同等の性能が得られるなら、マルチモーダルインターフェースの利点はほとんどありません。

これらの制約は、Elvis Saraviaのタスクファースト型AIエージェントを否定するものではありません。インターフェース上の洞察を信頼できるシステムへ変えるために必要なエンジニアリング作業を明確にするものです。

タスクがプロンプトに取って代わるかを示す3つの兆候

タスクファーストという考え方が重要になるのは、それによって総合的な対話負担が軽減されることを、製品、評価、ユーザーが確認した場合に限られます。

最初の兆候は、音声、画面状態、テキスト、注釈を、確認可能な一つのタスクオブジェクトにまとめる実用的なインターフェースです。

すでに複数種類の入力を受け付ける製品はいくつか存在します。しかし、それだけではこの提案を満たしません。

重要なテストは、キャプチャ後も関係性が保持されるかどうかです。エージェントは、どの発話がどの画面上のオブジェクト、文書の一節、注釈を指しているかを把握できる必要があります。

ユーザーは、実行前に組み立てられたタスクを編集できる必要もあります。アプリケーションが自身の解釈を隠すなら、誤りの防止は依然として困難です。

可視化されたタスク記録があれば、Saraviaの主張は強まります。添付ボタンが付いただけの不透明なチャット入力欄では、その主張は弱まります。

2つ目の兆候は、個別のモデル能力ではなく、業務全体に基づく評価です。

開発者は、同じ業務についてタスクファースト型入力と通常のプロンプトを比較すべきです。有用な指標には、完了率、修正のターン数、ユーザーが能動的に費やした時間、レイテンシー、重大なエラーが含まれます。

比較では、準備と実行を分ける必要があります。3回の修正を省けても、長い準備が必要なシステムでは、全体的な体験は改善されない可能性があります。

結果は、さまざまな規模のタスクを対象にすべきです。マルチモーダルなパッケージ化は、単純な質問にはほとんど価値がなく、複数のアプリケーションにまたがるプロジェクトではより大きな価値をもたらす可能性があります。

インターフェース評価は恣意的に調整しやすいため、独立した再現も重要です。デモンストレーションでは、視覚的コンテキストが特に有用なタスクを選ぶことができます。

GUIDEのようなベンチマークは、画面上の活動とユーザーの意図を結び付けるため、基盤として利用できます。今後のテストでは、操作を実行するエージェントも加え、構造化されたタスク入力が最終結果を改善するかどうかを測定すべきです。

現実的なワークフロー全体で大幅な向上が見られれば、タスクファーストの主張を裏付けます。厳選された事例に限られる小幅な向上であれば、新しい対話単位というより、有用な機能であることを示唆します。

3つ目の兆候は、目新しさが薄れた後のユーザー行動です。

人々は、業務を委任する前に、自然に話し、指し示し、強調表示し、証拠を添付するでしょうか。それとも、タスクの組み立てが負担に感じられ、短いメッセージに戻るでしょうか。

普及はキャプチャの速度に左右されます。インターフェースは、長いフォームへの入力を強いることなく、非形式的な説明を構造化されたコンテキストへ変換しなければなりません。

信頼も同様に重要です。無関係な画面内容や私的な会話が、知らないうちにタスクへ取り込まれないという確信をユーザーが持てる必要があります。

チームでは、まずコンテキスト量の多いワークフローでタスクファースト型の対話が採用される可能性があります。製品レビュー、調査の統合、インシデント分析、文書作成はいずれも、複数の情報源に証拠が分散しています。

これらの業務では、完了の定義を明示することも有効です。タスクでは、引用された証拠、未解決の質問、対象読者を含む意思決定メモを要求できます。

一般消費者への普及は、異なる経路をたどる可能性があります。人々は、旅行計画、フォーム入力、技術的なトラブルシューティング、個人記録の整理に音声と画面コンテキストを利用するかもしれません。

より広範な変化が起きても、プロンプトがなくなることはありません。テキストは、正確で低リスクな要求には依然として最速のインターフェースです。

代わりに、タスクはプロンプトの上位に位置付けられます。目的、コンテキスト、制約、ツール、権限、期待される出力を、エージェントが実行可能な一つの単位にまとめます。

この階層構造は、「音声対テキスト」よりも有用な枠組みを提供します。問題は、エージェントが一つの文を受け取るのか、それとも業務を実行可能な形で表現したものを受け取るのかということです。

開発者にとって、当面の優先事項は計測です。ユーザーが介入する理由、不足していたコンテキスト、誤操作の前後どちらで確認が行われたかを追跡してください。

企業の購入担当者にとって、優先事項はガバナンスです。システムが何をキャプチャし、そのデータがどこで処理され、権限がどのように維持され、どの操作で引き続き確認が必要になるかを確認してください。

ナレッジワーカーにとって、実践的な実験は簡単です。一つの複雑な業務を短いプロンプトで依頼した場合と、関連する証拠や完了条件を添えて同じ業務を依頼した場合を比較してください。

最初の応答の品質だけでなく、修正回数も数えてください。コンテキストの組み立てに費やした時間も数える必要があります。

これらの測定で、多様なタスクにおける総合的な負担の軽減が示されれば、Elvis Saraviaの提案は強化されます。ユーザーが会話による修正を煩雑な準備に置き換えただけなら、その提案は弱まります。

プロンプトが成功したのは、モデルへのアクセスを即時的なものにしたからです。タスクがプロンプトに取って代われるのは、即時性よりもコンテキスト、行動、説明責任が重要な場面に限られます。

それこそが、Elvis Saraviaのタスクファースト型AIエージェントに対する真の試金石です。より充実したブリーフィングによって、ユーザーの負担、権限、非公開コンテキストを管理しながら、エージェントがより多くの業務を完遂できるのでしょうか？