SpaceXAIが実際に発表したこと
5つのプリミティブ、そしてBotが勝利した
エッセイは、用語の氾濫に対する疲弊から始まります。これは妥当な診断です。「チャット、セッション、モデル、コンテキストウィンドウ、記憶、システムプロンプト、プロジェクト、スキル、コネクタ、エージェント、ツール、サンドボックス、権限、自動化はすべて、これらのシステムの実際の構成要素を表しています。」彼らの結論はこうです。「これらすべてを個別の製品コンセプトとしてユーザーに提示することは、必要以上の理解を強いることになる。」
彼らは5つだけを残しました。原文のまま引用します：
- 「Botsは、独自のアイデンティティ、記憶、ランタイム、ツールを持つ永続的なエージェントです。」
- 「Chatsは、Botと連携するための会話型インターフェースです。」
- 「Promptsは、Botにコンテキストや指示を与えます。これらは1回限り使用することも、Skillsとして保存することも、Routinesとして自動的にトリガーすることもできます。」
- 「Toolsは、ソフトウェア、API、コネクタ、シェル、またはコンピューター操作を通じて、Botsが情報にアクセスし、アクションを実行できるようにします。」
- 「Artifactsは、Botsが作成または修正するドキュメント、デザイン、コード、データ、その他の永続的な成果物です。」
このリストの中で、記憶がどこに位置しているかに注目してください。それはアイデンティティやランタイムと並んで、Botの属性となっています。あなた（ユーザー）の属性ではありません。
チャット履歴はBotの名簿になった
インターフェースにおける結果は明白に述べられています。「そのため、Grok Botにおける主要なオブジェクトは会話ではなくBotsです。Botには名前があります。アバターとタイトルがあります。あなたとの会話を記憶しています。独自のコンピューターとツールを持っています。明日戻ってきたとき、あなたは同じBotの元に戻ってくることになります。」
サイドバーにはスレッドではなくBotsがリストされ、アバターはアイデンティティを示すと同時に、ステータスインジケーターとしても機能します。「Botは、アイドル、思考中、作業中、待機中、ブロック、または完了のいずれかの状態になります。」
各Botには専用のマシンも割り当てられます。「各Botは独自のコンピューターを持っており、それを使ってウェブを閲覧し、ファイルを操作し、ソフトウェアを実行できます。」アクセス権限には3つのレベルがあり、最後は「Takeover（乗っ取り）：Botが助けを必要とするとき、ユーザーはコンピューターをフルスクリーンで開き、制御を奪ってから、再びBotに返すことができます」となっています。
重要な分割：機能は共有され、コンテキストは共有されない
以下は、2回読む価値のある段落であり、この記事が存在する理由でもあります。
「したがって、Grok Botでは機能（capabilities）とコンテキスト（context）は異なる境界に従います。ToolsとSkillsはアカウントレベルに存在します。なぜなら、多くのBotsがウェブの閲覧、ドキュメントの操作、メールの送信を必要とする可能性があるからです。記憶（Memory）とRoutinesはBotに属します。なぜなら、それらはその特定の役割が時間をかけて学習し、実行することを示すからです。言い換えれば、機能は広く共有できる一方で、コンテキストはそれを必要とする役割に留まります。」
意図的に2つの異なるスコープが設定されています。そして、彼らはその理由を説明しています：
「法務Botは進行中の紛争の履歴を必要とするかもしれませんが、財務Botは何年分もの財務記録を必要とするかもしれません。これらの履歴を1つの大きな記憶に統合すると、各Botにその業務に関連する情報を与えることが難しくなります。」
これは、永続性を中心に製品を再構築したばかりのベンダーによる、記憶のプール化に対する明確な反対論です。単に聞き流すのではなく、真剣に受け止める価値があります。
プロンプトなしで始まる作業
もう1つ、起動なしの永続性だけではアイデアの半分に過ぎません。「ほとんどのエージェントセッションは、ユーザーがプロンプトを送信したときに始まります。これでは、永続的なBotであっても、誰かが起動するのを待つことになります。」Routinesがその答えです。「スケジュールに従って、またはイベントに応じて実行される継続的な責任」であり、設計の途中で格上げされました。「私たちは当初、Routinesを二次的な設定として扱っていました。しかし、自律的な作業においてそれらがより重要になるにつれ、Botのメインインターフェースに移動させました。」
Routinesは記憶と同様にBotにスコープされています。SkillsとToolsはそうではありません。
同日公開されたエンタープライズ向けページ
エッセイと同時に、SpaceXAIはGrok Botを企業向けに提供開始し、Botを労働者の言葉で説明しました。「Botは、特定の仕事のためにGrok Bot内に作成するワーカーです。各Botはクラウド上の独自のコンピューターで動作し、あなたと同じようにすべてのアプリやウェブサイトを使用できます。」分離について：「Grok Botにおける各ユーザーの作業は、他のすべてのユーザーから分離された、独自の安全な環境で実行されます。Botはデフォルトでアクセス権を持たず、あなたがサインインしたアカウントにのみアクセスします。」
ロールアウトの注意点として、GrokおよびCursor Enterpriseの顧客は「今後2週間」無料で利用でき、組織全体を招待できるとされています。「既存のシートを持っていない人も含めて」です。
これが変えること、変えないこと
永続性の単位をセッションから移行させます。 これは本質的であり、正しい方向性です。独自のステート、ツール、継続的な責任を持つ名前付きのオブジェクトは、過去にスクロールして戻る会話よりも、蓄積された知識のコンテナとして優れています。
記憶のポータビリティ（移植性）は実現しません。 Bot의 記憶はその製品内のそのBotの属性です。エッセイの中には、それが移動可能であることを示唆するものは何もありません。そして、役割ごとのスコープ設定は、知識がベンダーだけでなく役割によっても区分されるため、移動を容易にするどころか難しくします。
マージは行われません。そしてそれは意図的なものです。 法務Botと財務Botを実行している場合、どちらも他方が学んだことを知りません。SpaceXAIはこれを機能（メリット）と考えており、1つの製品内での検索クオリティという点では、一理あります。
彼らは共有コンテキストの問題を認めています。 エッセイでは、役割が重複しないふりをしているわけではありません。「グループチャットは、プロジェクトやチームに共有コンテキストを提供する一方で、各Botがそれぞれの専門的な記憶を保持することを可能にします。」したがって、彼らのモデルにも共有レイヤーは存在します。それはストア（保存庫）ではなく、プロジェクトにスコープされた会話です。
調整の問題を排除するのではなく、場所を移動させます。 彼らの答えは使用実績から生まれました。「一部のユーザーは、複数のスペシャリストを調整する責任を持つChief of Staff Botを作成しました。」Bot間で作業をルーティングするBotは合理的なパターンですが、それはルーティングに関する独自の個別記憶を持つBotでもあります。
人々がここから誤解しがちなこと
「Botごとの記憶によって、記憶の問題は解決された」 1つの製品内、1つの役割においては解決されています。しかし、ツールを切り替えるときに自分のルールや慣習を認識させるという、以前から困難だった問題は手つかずのままです。これは、永続的な記憶とは実際に何であるかで説明されているのと同じ区別です。
「では、1つの大きな記憶を持つことは間違いなのか」 これは慎重に正すべき誤解です。なぜなら、SpaceXAI'sの主張は見た目よりも限定的だからです。彼らは、役割の履歴を1つの塊にマージすること（何年分もの財務記録とアクティブな法務紛争を単一のストアに放り込み、検索機能がそれをうまく処理してくれることを期待すること）に反対しているのです。これは本質的な検索の問題であり、彼らの指摘は正しいです。
彼らが反対していないのは、永続的な事実の共有ソース（アーキテクチャの決定、ドメイン用語、慣習など）です。これらは1つの役割の履歴ではなく、すべての役割に共通するものです。すべてのBotがそれらを個別に再学習することは、健全な管理ではなく無駄です。履歴のスコープ設定と事実の共有は異なるアプローチであり、エッセイが擁護しているのは前者のみです。
「では、すべてのBotに同じ指示を与えればいい」 5つのBotに同じコンテキストをコピーすることは、1ヶ月ほどは解決策のように見える回避策です。しかし、1つのコピーに修正が加えられ、他には適用されないと、5人のスペシャリストがあなたの慣習について自信満々に異なる意見を述べることになります。これは、マルチエージェントの記憶で説明されている失敗パターンです。
「Routinesが自律的にしてくれるので、コンテキストについて考えるのをやめられる」 RoutinesはBotがいつ行動するかを決定します。Botが何を知っているかを決定するわけではありません。古いコンテキストで毎朝実行されるRoutineは、毎朝間違った実行を繰り返します。
「Takeover（乗っ取り）があるから、すべてを監視できる」 3つのアクセスレベルは、まさにそれを避けるために設計されました。「コンピューターを目立たせれば立たせるほど、製品はユーザーに監視を促すことになります。」Takeoverは例外的な経路であり、通常のワークフローではありません。
解決策：履歴をスコープし、事実を共有する
ステップ 1：コンテキストを履歴と事実に分類する
実際に使用しているBotを1つ選び、そこに蓄積された内容を読んでみてください。すべての項目を2つの山に分類します。
履歴（History）。 この役割が順次実行し、決定し、指示されたこと。紛争のタイムライン。収集された領収書。ソーシングされた候補者。これらはBotに属するものであり、役割間でマージすると検索精度が低下するというSpaceXAIの指摘は正しいです。
事実（Facts）。 誰が尋ねるかに関係なく、組織について真実であること。APIのバージョン管理方法とその理由。社内用語の意味。どのチームが何を所有しているか。執筆の慣習。コンプライアンス上の制約。
2つ目の山は、気づかないうちに複製されてしまうものです。作成するすべてのBotがその一部を必要としますが、役割ごとの記憶では、すべてのBotがそれをゼロから再学習するか、あるいは学習せずに間違えることになります。
ステップ 2：5つ目のBotを作成する前に、各Botの共有コンテキストがどこから来るかを決定する
2つのBotであれば手動で管理できます。5つになると、コピー間でズレ（ドリフト）が生じ始めます。
SpaceXAIがすでにアカウントレベルにスコープしているものを見てみましょう。ToolsとSkillsです。なぜなら「多くのBotsがウェブの閲覧、ドキュメントの操作、メールの送信を必要とする可能性があるから」です。これはまさに、事実に適用されるべき論理です。機能の境界は「多くのBotsがこれを必要とする」という点に引かれています。同じテストを知識に適用すれば、同じ答えが得られます。
実務的には、各Botについて、どの共有事実が必要で、現在それをどこから取得しているかを書き出します。もし答えが「最初の会話に入力した内容」であるなら、それは将来的にズレが生じるコピーです。
ここでは、グループチャットを意図的に活用する価値があります。グループチャットは「プロジェクトやチームに共有コンテキストを提供する一方で、各Botがそれぞれの専門的な記憶を保持することを可能にします」。これはプロジェクト固有の重複には適していますが、永続的な慣習には適していません。グループチャットは会話であり、慣習は会話よりも長生きすべきだからです。
ステップ 3：どのBotも所有しないレイヤーに事実を置く
構造的な解決策は、アカウントレベルのToolsの境界がすでに示唆しているものです。多くのBotが必要とするものは、特定のBotの内部に存在すべきではありません。
製品の外部にある記憶レイヤーは、知識に対してそれを実現します。各Botは、SpaceXAIが設計した通りに、スコープされ専門化された独自の履歴を保持し、共有された事実はどのBotの所有物でもないストアから読み込みます。6つ目のスペシャリストを作成しても、慣習を6回説明する必要はなくなり、修正は5回ではなく1回で済みます。
また、これはBotごとの記憶では対応できないこと、つまり「次に使うツール」にも対応できます。MemoryLakeは3つのステップでセットアップできます。
ステップ 1：APIキーを作成する
サインインし、ダッシュボードからAPIキーを生成します。これはBotやアカウント、特定の製品ではなく、あなたに属します。これは、役割が複数のベンダーにまたがっている場合に極めて重要な特性です。
ステップ 2：最初の記憶をアップロードする
ステップ1の「2つ目の山」を投入します。アーキテクチャの決定とその理由、ドメイン用語、サービスの所有権、永続的な好み、すべての役割が尊重すべき制約などです。
履歴はそのままにしておきます。Bot自身の作業記録は、まさにそのBotにスコープされたままにしておくべきものです。
ステップ 3：AIとエージェントを接続する
エージェントをストアに向けます。新しいスペシャリストは、ゼロからではなく組織の事実から開始でき、事実は1つの場所で正確に保たれます。これこそが、製品ごとではなくツール間で記憶を同期することの意義です。
実務においてこれが変えること
最初の変化は、スペシャリストの作成コストが安くなることです。現在、新しいBotを作成するコストには、一般的な内容をすべて再学習させることが含まれており、これが設計の前提であるきめ細かな役割分担を無意識のうちに阻害しています。
2つ目は、修正がN通り（複数箇所）でなくなることです。慣習を一度修正すれば、すべての役割が修正されたバージョンを読み込むため、たまたま教えられたバージョンに依存することがなくなります。
3つ目は、役割のスコープ設定が、回避すべき制約ではなく、真のデザイン上の選択肢になることです。共有された事実が共有レイヤーから提供される場合、各Botの履歴を狭く保つことにコストはかかりません。これこそがSpaceXAIがそもそも望んでいたことであり、エージェントの記憶に多くを保持しすぎないという主張の背後にある論理と同じです。
役割ごとのエージェント記憶に関するベストプラクティス
- スケールする前に、履歴と事実を分離する。 履歴は役割に属し、事実は全員に属します。
- 知識に「Toolsテスト」を適用する。 多くのBotがそれを必要とするなら、特定のBotの内部に置くべきではありません。
- 共有コンテキストを各Botにコピーしない。 それはズレ（ドリフト）の原因となり、気づかないうちに破綻します。
- プロジェクトの重複にはグループチャットを使用し、永続的な慣習には使用しない。 会話は、それを超えて存続すべきものを置く場所としては不適切です。
- 調整役のBotはメモリではなくルーターとして扱う。 そのBot自身の記憶はルーティングに関するものであり、あなたのドメインに関するものではありません。
- Routineをスケジュールする前に、Botが何を知っているかを確認する。 自律性は、間違ったコンテキストも含め、Botが持つコンテキストを増幅させます。
- Takeover（乗っ取り）は例外として維持する。 設計上、意図的に監視を抑制しています。常にそれを使用しているということは、Botの情報が不足していることを意味します。
- 変化に応じて再確認する。 Grok Botは新しく、エンタープライズ向けのオファーには期限があります。このような新しいデザイン上の決定は変化しやすい傾向があります。
結論
これは、今年AIベンダーから発表された製品に関する文章の中で、最も思慮深いものの1つであり、その中心的な主張には私たちも同意します。セッションは、残しておきたいものにとって、決して適切な単位ではありませんでした。
彼らが私たちよりも一歩踏み込んでいるのは、コンテキストは役割に紐付けるべきだと結論づけている点です。履歴に関しては、それは正しく、十分に議論されています。しかし、すべての役割が必要とする事実に関しては、1つの共有された問題をBotごとの問題に変えてしまいます。履歴はSpaceXAIが設計した通りにスコープを設定しましょう。そして、事実はどのBotも所有しない場所に置きましょう。