出発点：ロボットがセッションをまたいで責任を持つなら、チャット履歴は主役ではなくなる

チャット履歴は、一度きりの質疑応答を保存するのには適していますが、継続的な責任を保存するのには適していません。一度の会話が終わると、その内容は新しいセッションによって下に押しやられます。一週間後に戻ってきたユーザーは、通常、新しいウィンドウを開き直します。その場限りの質問に答えるだけのモデルにとって、これはまったく合理的な行動です。しかし、ユーザーを認識し、以前の作業を覚えていて、責任を持ち続けるはずのエージェントにとっては、同じ作業が互いに繋がりのない履歴として切り刻まれてしまうことになります。

Grok Bot チームは、初期のプロトタイプで別の関係性を示しました。サイドバーに並ぶのは「昨日の会話」や「先週の会話」ではなく、Kenny、Justin、Luke、Tyler といった個々のボットです。それぞれの名前の横には、最新の進捗状況や、承認待ちの事項などが直接表示されます。例えば、全員向け会議の資料の承認待ち、営業紹介文の作成完了、受信トレイに残り二通の返信が必要などです。ユーザーが戻ってきたとき、最初に目にするのは「誰が何を担当しているか」であり、その後、その担当者との会話へと進みます。

この考え方が、その後の設計における判断基準となりました。ボットが数日にわたって作業を継続するのであれば、製品の主要な対象は安定して存在する必要があります。そうでなければ、いわゆる記憶や自動化、ツールはすべて、絶えず下へ沈んでいくセッションの集まりに依存することになってしまいます。

最初のステップ：製品の基本単位をチャットからボットへ

永続的なエージェントの背後には、モデル、コンテキストウィンドウ、システムプロンプト、サンドボックス、コネクタ、権限、自動化など、数多くの技術的なオブジェクトが存在します。これらをすべてユーザーに公開してしまうと、ユーザーは作業を依頼する前に、まずシステムのアーキテクチャを理解しなければならなくなります。そこでチームは、まず概念の圧縮を行い、ユーザーが理解すべき五つのオブジェクトだけに絞り込みました。

五つのオブジェクトの中から、チームは最終的にボットを製品の組織化の中心に選びました。ボットには名前、アバター、役割の呼称があり、ユーザーとの会話を記憶し、自分専用のコンピューターとツールを持ちます。翌日戻ってきたユーザーが再び直面するのは、同じ担当者です。チャットが消えたわけではありません。メインインターフェースの組織単位という立場から、ボットとコミュニケーションを取るための入り口へと役割を変えたのです。

この変更により、サイドバーが答える問いが変わりました。チャット履歴が答えるのは「これまでに何を話したか」であり、ボット名簿が答えるのは「誰が何を担当しているか」です。作業が複数回のセッションにまたがる可能性があるならば、ユーザーが最初に確認すべきは後者の問いとなります。

第二ステップ：それが誰で、何をしているのかを一目で分かるようにする

ボットが長期的なオブジェクトになると、名簿は一度に三つの問いに答える必要が出てきます。それは、「これは誰か」「それは何をしているか」「今、何を知っておく必要があるか」です。Grok Bot チームは、この三つの問いへの答えを、アバターとその周辺の小さなインターフェース領域に集約しました。

数十ものボットを、互いに区別しやすく、かつ同じシステムの一部であると感じさせるために、チームはイニシャル、絵文字、ピクセルアート、水彩、粘土、Noritake 風の線画、シルエット、identicon など、複数のビジュアルシステムを試しました。水彩と粘土は個性がありますが、サイドバーのサイズに縮小すると細部が過剰になります。よりシンプルなシステムはインターフェースに馴染みますが、ボット同士の区別がつきにくく、入れ替え可能に見えてしまいがちです。最終的な解決策は、統一されたシンプルな幾何学的構造と表情豊かな目を維持しつつ、管理されたバリエーションとアクセサリーによって差異を生み出すというものでした。

次に、アバターは二つ目の役割を担うことになりました。それは、ライフサイクルの表現です。チームは、待機、作業中、外部待ち、ブロック中、思考中、完了の六つの状態をリストアップしました。ボットは作業を受け取るとまず反応を示し、実行を開始するとより顕著な動きを見せます。外部の条件を待っているときや支援が必要なときは、また動作が変化します。そして完了すると、安定した状態に戻ります。ステータスを伝えるためのバッジを別途並べる必要はなく、ユーザーは同じ視覚オブジェクトを見るだけで、アイデンティティと進捗状況の両方を認識できます。

三つ目の役割は、実行の詳細に関する可視性を制御することです。標準的な「三つの跳ねる点」では情報が少なすぎて、ユーザーはボットがまだ作業中なのか、それとも行き詰まっているのかを判断できません。一方で、完全なアクティビティログを常時表示すると、ユーザーを監視者の立場に引き戻してしまいます。チームのユーザー調査によると、人々がより詳細な情報を求めるのは、主にボットがまだ作業中であり、方向性が間違っていないことを確認したいからだということが分かりました。最終的なインターフェースでは、まずアバターの動きによって最小限のコストで確認を提供し、さらに詳しく確認する必要がある場合にのみ、ホバーすることで現在のアクションを表示するようにしました。

ここに、最初の明確な設計パスが形成されました。安定したアバターが「誰なのか」を、動作状態が「まだ進行中かどうか」を、必要に応じて表示される現在のアクションが「方向性が正しいかどうか」を担います。情報量はユーザーの懸念の度合いに応じて段階的に増え、デフォルトのインターフェースは静かな状態を保ちます。

第三ステップ：コンピューターはボットが使い、人間は閲覧と引き継ぎの権限のみを持つ

各 Grok Bot は自分専用のコンピューターを持っており、ウェブの閲覧、ファイルの処理、ソフトウェアの実行が可能です。チームはすぐに、直感に反する問題に直面しました。それは、コンピューター画面を目立たせればするほど、製品がリモートデスクトップのようになり、ユーザーがその閲覧や操作に時間を費やしがちになるということです。

彼らは四つのレイアウトを比較しました。フローティングウィンドウは開きやすいですが、会話を遮ります。並列表示は実行プロセスを常時露出させ、ユーザーがじっと見つめることを促します。モーダルウィンドウは短時間の確認には適していますが、ボットのワークスペースを中断として扱うことになります。全画面表示はコンピューターに十分なスペースを与えますが、会話を完全に押しのけてしまいます。四つの選択肢はいずれも所有権の問題を解決していません。インターフェースは依然として、ユーザーが見守る必要のあるコンピューターを示唆しているのです。

最終的な解決策では、介入を三つの層に分けました。

• ステータス：コンピューターが実行中の場合、タイトルバーのアイコンが紫色になります。ユーザーはワークスペースが使用中であることだけを知ります。
• プレビュー：コンテキストが必要な場合、固定されたサイドバーを開いて作業を観察します。現在の会話から離れる必要はありません。
• 引き継ぎ：ボットが人間による処理を必要とする問題に直面した場合、ユーザーは全画面で引き継ぎ、操作が完了したら制御をボットに返します。

ステータスは、必要に応じてボットの現在のアクションを展開することもできます。これにより、三層の介入は、情報量に応じて、ステータス、現在のアクション、プレビュー、引き継ぎという四段階の確認パスとして整理されました。

この三層のアクセスにより、「いつでも確認できる」ことと「常に見守らなければならない」ことが分離されました。ボットのコンピューターには、時間帯によって変化する壁紙もあり、朝は明るく、夜は暗くなります。このディテールは単なる飾りではありません。ユーザーがワークスペースを、自分自身のデスクトップのリモートミラーではなく、ボット自身の環境として理解するのに役立ちます。

第四ステップ：回答を、そのまま使えるインターフェースへと育てる

初期の Grok Bot は、ほとんどすべてのリクエストに対して散文で回答していました。五日間の天気予報は文章で説明され、一連のタスクもテキストで項目ごとに説明されていました。情報自体は間違っていないかもしれませんが、日付、ステータス、担当者、次のアクションを整理し直す負担はユーザーにのしかかっていました。

そのためチームは、「情報の形状」を回答の一部と見なすことにしました。説明に適した内容は引き続きテキストで提供し、比較、スキャン、直接操作が必要な内容は、インラインカードやコンポーネントを使用します。メールコンポーネントは、宛先、件名、本文に加えて、送信ボタンと破棄ボタンを同時に表示します。ルーチンの作成、設定の変更、別のボットへのメッセージ送信などのアクションは、システムイベントとして会話のタイムラインに直接表示できます。

これにより、タイムラインは自然言語だけのものではなくなりました。会話、システムイベント、インタラクティブオブジェクト、ビジュアライゼーションが、同じコンテキストを共有します。ユーザーは双方が何を言ったかを確認できるだけでなく、アクションが実際に発生したかどうか、結果がどのような状態にあるか、次に自分が処理する必要があるかどうかを確認できます。したがって、成果物は単なる添付ファイルではなく、チャット内の約束事を確認可能な成果へと変えるインターフェース単位となります。

第五ステップ：複数のボットに対して、能力、記憶、コラボレーションの境界を明確にする

ユーザーが複数のボットを作成すると、システムは二つの相反するニーズを解決する必要があります。ウェブ閲覧、文書処理、メール送信などの能力は再利用できるべきであり、法律、財務、デザインといったロールの長期的なコンテキストは、ひとまとまりの記憶として混ざり合うべきではありません。

Grok Bot は最終的に、能力とコンテキストが異なる境界に従うようにしました。

• ツールとスキルはアカウント層に属します。複数のボットが共通の能力を共有できます。
• メモリとルーチンはボット層に属します。長期的な知識と継続的な責務は、特定のロールに従います。
• グループチャットは共通のタスクに属します。部門横断プロジェクトでは、共同作業に必要なコンテキストだけを共有します。

また、ユーザーの中には、Chief of Staff のようなコーディネーターボットを設け、方向性を任せて、複数の専門ボットを調整・指揮させる人もいます。チームはダッシュボードやタスク割り当てボード、明示的な引き継ぎコントロールを検討しましたが、これらのインターフェースは、ルーティング作業を再びユーザーに課すことになります。最終的な方向性は、コーディネーターボットに日常的な割り当てを処理させ、判断が必要な場合にのみ人間を呼び戻すというものでした。

このステップによって、マルチエージェントが本当のチームになるのか、それとも個別に世話をする必要のある六つのチャットウィンドウになるのかが決まります。能力は広く共有でき、ロールの記憶は分離したまま、共通プロジェクト内では必要な事実だけを Bot 間で共有します。そうすることで、人の注意力は日常的な情報の受け渡しで消耗することはありません。

第六ステップ：作業が時間、イベント、または別のボットによって自発的に開始されるようにする

ボットが過去を記憶できるとしても、毎回ユーザーがプロンプトを送信するのを待っている限り、真に継続的な責任を負っているとは言えません。ルーチンを使用すると、ユーザーは長期にわたる作業を事前に定義でき、時間が来たときやイベントが発生したときにボットが自動的に起動します。

トリガーは、固定時刻、曜日、毎週、毎月の周期をカバーするだけでなく、GitHub の Issue、PR、Push、チェック失敗、ワークフローイベント、Slack の新しいメッセージや絵文字リアクション、そしてプロジェクト管理ツールのステータス変更も対象としています。別のボットが作業を開始することもできます。プロンプトは依然としてセッションを開始できますが、作業の開始方法を独占することはなくなりました。

チームは当初、ルーチンを二次的な設定の中に置いていましたが、後にそれをボットのメインインターフェースへと移しました。その理由は単純明快です。自発的な作業が中核的な能力であるならば、ユーザーはどのような継続的な責務が実行されているか、最近何が実行されたか、結果がどこにあるか、どの異常を処理する必要があるかを確認できなければなりません。会話のタイムラインは、人が開始したリクエストと、誰もオンラインでいないときに発生した作業の両方を記録する、責務の記録としても機能するようになりました。

記憶によってボットは翌日もその作業を認識し、ルーチンによって翌日には自分で続行できます。セッションをまたいだ継続的な作業には、この両方が成立している必要があります。

まとめ：ユーザーを再び管理者にしてしまうインターフェースを削除する

レビューの最後に、チームはプロジェクト後期の作業の多くが削除であったと記しています。ウィンドウとパネルのコントロール、コンピューターのビューオプション、エージェントのメタデータは、圧縮または撤去されました。また、彼らはアカウントあたり約 50 ボット、グループチャットあたり 6 ボットという事実上の上限を設定しました。すべての決定は、同じテストにかけられました。それは、ユーザーの委任を支援するものか、それとも単に管理すべきオブジェクトを増やすだけか、というテストです。

この基準に沿って振り返ると、前述の設計上の選択は、孤立した一連の機能ではありません。ボット名簿は安定した責任を確立し、アバターは進捗状況を見えるようにし、オンデマンドな開示はログの確認を減らし、独立したコンピューターは実行をボットに委ね、構造化されたコンポーネントは結果をすぐに使えるものにし、階層的な境界は複数ボットの調整コストを下げ、ルーチンは次のプロンプトを待たずに作業を進めます。これらはすべて、同じ一つの目的に貢献しています。それは、ユーザーが離れた後も、責任、コンテキスト、そして作業が継続できるようにすることです。

この公式レビューは、Grok Bot があらゆるシナリオで確実に長期タスクを処理できることを証明するものではありません。それが提供する価値は、具体的な製品判断のセットです。もしインターフェースが依然として一度きりのセッションを中心に構成され、ユーザーが進捗を絶えず尋ねたり、完全なログを閲覧したり、コンテキストを手作業で運んだり、次のステップを手動でトリガーしたりする必要があるならば、ロボットはより強力なモデル能力を持っていたとしても、製品レベルでセッションをまたいで作業する長期的な責任者にはなり得ないということです。