GrokBotプロダクト責任者の振り返り：1か月でGrokBotを作る、チャット欄から「自分のPCを持つAI同僚」へ
Roman Ugarteが語るGrokBotの誕生：なぜCursorを離れてゼロから再出発したのか、なぜAgentにクラウドPCを与えたのか、そして少数精鋭チームがどのように4週間でプロトタイプを作り上げ、クローズドベータ、機能削減、信頼性の修正を経て一般公開へと漕ぎ着けたのか。
ある仕事をAIに任せると、すぐに90%を終わらせてくれる。一見すると非常に強力に思える。しかし、最も手間がかかるのは往々にして残りの10%だ。事実関係の確認、度重なる軌道修正、漏れの補完、そして成果物を実際に使用するオフィスソフトへと移し替える作業である。常に手元を離れられない限り、タスクは本当に引き渡されたとは言えず、AIは形を変えて仕事を人間に突き返しているに過ぎない。
これこそが、GrokBotが解決しようとしている課題である。Roman Ugarteは、「90%完了すること」と「仕事全体を完了すること」の差を質的変化と捉えている。前者は依然として人間が最初から最後まで監視する必要があるのに対し、後者になって初めて、同僚に責任を委ねたという実感が得られるからだ。そこでチームは、より強力なチャット欄を作り続けるのではなく、GrokBotを常時オンラインのナレッジワーク向けAgentとして設計した。コンテキストを記憶し、クラウド上で稼働し続け、自分専用のPCを使って複数のソフトウェアにまたがるタスクをこなすことができる。
RomanはかつてCursorのグロースを担当し、後にGrokBotのインキュベーションに参画してプロダクトの方向性を統括した。Lenny's Podcastにおける今回の振り返りの中で彼は、数人のチームがコードの最初の1行からスタートし、約4週間で社内利用可能なプロトタイプを作り上げ、さらに約3週間の社内テストを経て一般公開（Public Launch）に至った経緯を語った。いわゆる「1か月で作られたGrokBot」とは、成熟した完成品が突如誕生したことを意味するのではなく、チームがごく短期間で最も重要なプロダクト仮説を実際に動く形で確かめたことを指している。
真に追究すべき問いはこうだ。彼らはなぜ汎用Agentを直接Cursorに組み込まなかったのか？ なぜ各Botに専用のクラウドPCを持たせることにこだわったのか？ 動くプロトタイプは、実際の業務、機能の削ぎ落とし、そして信頼性の修復を経て、いかにしてタスクを完遂できる「AIの同僚」へと進化していったのか？ これらの選択こそが、GrokBotの誕生プロセスにおいて最も再現性の高い価値を持つ部分である。
Agentを「プラグイン付きチャット欄」ではなく「PCを持つ同僚」と捉える
Romanによれば、多くの人々はいまだにAgentを「チャットボット ＋ いくつかの外部接続（API/MCP）」と理解している。人間が質問を投げかけると、検索や特定のエンタープライズソフトウェアのインターフェースを呼び出し、最終的に一通りの回答を返す、というものだ。
GrokBotチームは当初から、「同僚を基準とする（Colleague-pilled）」と呼ばれる思考のアンカーを確立していた。「もしAIを、現実世界で採用した新しい同僚と見なすなら、私たちは一体どのように協働するだろうか？」
この視点に沿って、彼らは2つの重要な基盤アーキテクチャ上の意思決定を下した。
1. 徹底したクラウド化と状態の永続保持
初期の探索において、OpenClawはチームに重要な示唆を与えた。Romanは、OpenClawが極めて重要な2つの点で正しかったと明確に述べている。第一に、強力なモデルに対してよりリアルなシステムツール能力を提供したこと。第二に、AIのメンタルモデルを「チャット対話」から「協働する同僚」へと真っ先に押し進めたことだ。GrokBotはそこから多くのインスピレーションを得て、設定のハードルを下げるべく、これらのプリミティブをプロダクト化しようと試みた。Romanが挙げた利用上のフリクションには、Agentがローカルとクラウドのどちらで動作するのか、PCを常にスリープ解除状態にしておく必要があるのか、そしてスマートフォンから指示したタスクが自宅のPCに依存し続けるのか、といった点が含まれていた。
GrokBotは、すべてのAgentを一元的にクラウド上で稼働させる道を選んだ。すべてのBotは長期的に存続するエンティティであり、連続した対話メモリを保持し、「新しいセッションを開くたびに記憶喪失になる」ような一時的なセッションではない。ユーザーがスマートフォンからメッセージを送信しても、PC上で長期的なタスクを割り振っても、Botはバックグラウンドで同一の状態を保ちながら静かに稼働し続ける。
2. 各Botが自分専用のクラウドPCを使えるようにする（Computer Use）
これはプロダクト全体において最も中核的であり、かつ最も議論を呼んだ技術的決断である。多くの技術チームはAPIやモデルコンテキストプロトコル（MCP）を介して外部ツールと接続する傾向にあるが、実際の業務現場には2つの巨大な現実的障害が存在する。
- 現実世界において重要な業務ツールの多くには、使い勝手の良いAPIが存在しない：Romanは営業チームが使うツールやSalesforceのダッシュボードを例に挙げている。仮に一部のインターフェースが存在していたとしても、実際のワークフローをカバーするには不十分であることが少なくない。
- 画面共有の不合理さ：Romanはわかりやすい例えを挙げた。もし会社に新しい人間の同僚が入社してきたら、「あなた用のPCはないから私の隣に座って、2人でこのノートPCを共用し、1組のアカウントとパスワードを使い回し、画面のクリック操作を取り合おう」などと言うはずがない。
チームはインタビューの中で具体的な実行インスタンスのトポロジーを公表していないが、Romanはこれら長期存続するBotが自分専用のクラウドPCを使用できる（access to its own computer）ことを明言している。これは、人間と同じようにピクセル認識、カーソル移動、文字入力を通じて、さまざまなウェブページやデスクトップアプリケーションと対話することを試みられるということを意味する。APIのないレガシーシステムや複雑なウェブページに直面した際にも、Botはインターフェースの欠落に完全に制約されることなく、GUI（グラフィカルユーザーインターフェース）を通じてプロセスを推進するという選択肢を確保できるのだ。
さらに重要なのは、GrokBotチームが、こうしたクラウドPCの基底レイヤーの操作は将来的にユーザーから完全に意識されないものであるべきだと考えている点だ。ユーザーがリモートデスクトップのように画面を直接操作する必要はなく、AIは作業の進捗を報告するだけでよく、基底の「PC操作」はAIが作業をこなすための実装メカニズムに過ぎない。
インタビューでは、各Botの具体的なリソース分離方式、コスト、アイドル時のポリシーなどは明かされなかった。したがって、確認できるのは「Botが自分専用のPCを使用できる」というプロダクト上の抽象化までであり、そこからインフラ構成を推定することはできない。
委任方式の比較
同じタスクでも、チャット欄と「デジタル同僚」では何が違うのか？
2つのモードを切り替えて、人間の作業負担がどの段階で再び発生するかを確認できます。本図はインタビューに基づく概念図であり、実測完了率を示すものではありません。
回答を終着点とする
- 人間が質問を提示背景情報を1つのプロンプトに詰め込む。
- AIがコンテンツを生成回答や中間成果物を出力する。
- 作業が人間に戻る確認、コピー、システムへのログイン、後続の操作を実行。
人間の負担依然としてラストワンマイルを自ら完走する必要がある
タスクの完結をゴールとする
- 人間が目標と境界を指示コンテキスト、権限、検収条件を提示する。
- Botが継続的に推進APIを呼び出し、必要に応じて自身のクラウドPCを操作する。
- 必要に応じた報告と確認高リスクな操作や異常が発生した際に人間の介入を求める。
- 検収可能な成果物を引き渡す人間はすべての手順を見張るのではなく、成果物のチェックに注力する。
人間の負担実行者から権限付与者・検収者へシフト
なぜCursorを離れてゼロから再出発し、いかにして1か月で作り上げたのか？
GrokBotのインキュベーション以前、チームの中核をなすプロダクトは、大勢のプログラマーの間で確固たる評判を築いていたAIコードエディタのCursorだった。RomanがCursorに加わった当時のチームは約15人だったが、その後チームは1,000人以上に拡大し、続いてCursorはSpaceXに買収された。インタビューの司会者は、GrokBotの選択を別のアプローチ——多様なAgentの形態を単一のインターフェースに詰め込み、タスクの形態が広がるたびにタブを追加していくことで、最終的に画面が窮屈になりがちなアプローチ——と対比させた。
Cursorのチーム内でもかつて激しい議論があった。プログラマーもCursor内でコード以外のコンテンツを書くことがよくあるのだから、既存のプロダクト上でそのままイテレーションを回す方が最も抵抗が少ないのではないか、と。
しかし彼らは最終的に、完全にゼロから独立したプロダクトを作る道を選んだ。その理由は、「自社の社内組織構造をプロダクトの形態としてユーザーに届けてしまう（Shipping your org chart）」のを避けるためであった。
- 認知的ハードルとメンタル面の負担：コードツールのUIにはターミナル、ファイルツリー、デバッグパネルが密集しており、非エンジニアにとっては自然と敬遠したくなる要素に満ちている。コードツールに無理やり「非コード向けワークスペース」を押し込んだところで、画面が乱雑かつ肥大化するだけでなく、異なる複数のプロダクトビジョンが1つの画面を無理やり共有していることがユーザーにもはっきりと伝わってしまう。
- ライフサイクル全体にわたるプロダクトのコントロール力：一般的なオフィスワークに適した「同僚感」を生み出すには、画面上のすべてのピクセル、あらゆるインタラクションのフローに対して、完全にゼロから設計できるコントロール力を保持していなければならない。
大企業にありがちな長期にわたる計画サイクルに陥るのを防ぐため、チームはごく少数の閉じた小グループ（わずか数人）を結成し、オフィスの独立した物理的エリアへ移動し、専用の非公開Slackチャンネルを用い、外部から比較的隔離された状態で膨大な数のミクロな意思決定（micro decisions）を迅速に下していった。Romanは、もし当時大きなチームで6〜12か月の壮大なビジョンに沿って進めていたとしたら、最終的な成果にたどり着くことすらできなかった可能性が高いと見ている。
このことは、開発ペースに関する重要な事実をも示している。プロジェクト全体は、実際には明確な3段階のタイムラインによって構成されていた（インタビュー中の数字はいずれも概数）。
- 第1フェーズ（約1か月）：チームが最初の1行のコードを書いてから、社内で実際に利用可能な最初のプロトタイプ（functional, useful prototype）を作り上げるまで。ここでの「1か月」とは、社内で重要な一連の処理が通る最小限の利用可能バージョンを指しており、対外的に公開できる成熟した完成品では決してない。
- 第2フェーズ（約3週間）：社内テスト（Internal Beta）から一般公開（Public Launch）へと進み、システムの重要課題を集中的に克服した期間。
- 第3フェーズ（約3週間）：インタビュー収録時点で一般公開からさらに約3週間が経過しており、プロダクトは依然として極めて初期の進化の過程にある。
「1か月」を分解して見る
最初のコードからインタビュー収録まで、実際には3つのフェーズを経ている
フェーズをクリックして、当時何が達成され、何がまだ不足していたかを確認できます。所要時間はいずれもインタビュー中の概数です。
達成：主要フローが社内利用可能
少人数チームによるプロトタイプの迅速な構築
独立した執務エリア、非公開 Slack、そして多数のミクロな意思決定によって調整コストを削減しました。ここでの終着点は functional, useful prototype であり、成熟した公開プロダクトではありません。
重点：機能削減 ＋ 信頼性の改善
Internal Beta から Public Launch へ
チームはデバッグ情報を非表示にし、インターフェースを簡素化しました。さらに、実際のタスクから失敗パターンを収集し、約 5 つの主要なバックエンド問題を定量的に改善しました。
状態：依然として very early innings
一般公開は作業の完了を意味しない
インタビュー収録時点で、プロダクトの一般公開から約3週間が経過していました。GUIクリック、ログイン、組織の記憶、複数Botの連携には依然として明確な境界が存在します。
チームはまず全社ミーティングでGrokBotを展開し、それを現実のストレステストとして活用した。第1週目には、予想外の部門に所属する同僚たちが、元々ChatGPTや他のチャットツール上で行っていた日常的なAgentタスクをGrokBotへと移行させた。こうした部門横断的な実際の業務移行を目の当たりにしたチームは、直ちに一般公開の準備へと舵を切った。
組織的バックボーン：なぜ少数精鋭チームは4週間でプロトタイプを作れたのか？
Romanの目には、1か月でプロトタイプを提示できたのは開発上の隔離の成果であるだけでなく、チーム内部の独特なスピード感の文化に依拠していたと映っている。
- 高い信頼と合意：チームメンバーは共通の前進方向について明確な共通認識を持っており、同僚が自律的に実行して結果を出せることを互いに深く信頼していた。
- スタートアップ感の維持：会社全体の規模が徐々に拡大しても、チームは「多少の混沌を伴いつつも極めて迅速に実質的なインパクトを生み出す」というスタートアップ特有の空気感（startup feeling）をあえて維持し続けた。
- 2つの基本原則：1つは、不要な機能を果敢に提供終了・削除する「プロダクトの削減（deleting the product）」。もう1つは「とにかくやり遂げる（just do the thing）」である。チームメンバーが業務の中でやるべきことや直すべきことを見つけた際、何段階もの承認伺いを立てるのではなく、自発的に引き受け、迅速に修正し、必要なリソースをすり合わせる。Romanはこれらを、少数精鋭チームが初期に桁外れの俊敏性を保つための組織的土壌として説明しており、普遍的なマネジメントの一般法則ではないとしている。
社内プロトタイプから一般公開へ：続く3週間はなぜ「削除」が中心だったのか？
プロダクトが社内に浸透し、段階的に外部の限定テストを開始した際、チームが直面した最大の課題は「機能が足りないこと」ではなく、「機能を作りすぎてしまったこと」だった。
正式リリースを控えた約3週間の間、プロダクトは集中的な機能の提供終了（Unshipping）のプロセスを経た。
1. エンジニア的発想による「透明性ツール」の撤廃
クローズドベータの初期、問題の調査をしやすくするために、UI上にはモデルの内部思考、記憶、ツール呼び出しといったデバッグ情報が表示されていた。
これらの詳細は開発者の目には強いコントロール感を与えるが、一般的なオフィスワークにおいては深刻な認知過負荷を引き起こした。現実の同僚に対して3秒ごとに「今どのボタンをクリックしたか、頭の中でどんな言葉を考えたか」の報告を求めないのと同様に、人間は操作UIの中で流れるテキストストリームを見つめ続ける必要はない。チームには、BotのToDoリストや大まかな優先順位を見たいというユーザーからのフィードバックも寄せられていたが、長いテキストストリームや思考連鎖（chain-of-thought）を求める声は誰からも上がらなかった。最終的にチームはUIを大幅に削ぎ落とした。Botがタスクを受け取った後、ユーザーに主に見えるのはSlack風の「入力中…」の表示と緑色のオンラインステータスランプであり、Botは必要に応じて段階的な進捗を送信し、完了時に成果物を提示する形となった。
2. 「どんなボタンを追加したか」から「Botが何を完了できるか」への転換
従来のSaaSソフトウェアは、UI上に「機能（feature）」を誇示することに強く執着していた（例えばサイドバーの各種設定項目、フローチャートビルダー、複数選択プルダウンなど）。しかしAgentの時代において、複雑なUIコントロールを1つ増やすことは、往々にして本来AIが処理すべき負担を人間に押し付けることを意味する。
典型的な例が、自動化ワークフロー（Automation）の設定である。
- 多くのツールのやり方は、画面の左側に複雑なフローキャンバスを用意し、新規作成をクリックし、トリガー条件を選び、アクションを選択し、タイマーを設定するというものだ。インタラクションが極めて煩雑であるため、一般ユーザーが自動化を設定することは滅多になかった。
- GrokBotは自動化設定ページを完全に廃止し、「毎朝8時にリマインドして」といった自然言語での定義を直接サポートするアプローチを選んだ。スケジューリングのロジックはすべてBotがバックグラウンドで自律的に管理する。Romanによると、プラットフォーム上の自動化の99%はこうした自然言語の対話を通じて構築されているという（これは回答者の口述によるプラットフォームの数値であり、独立した第三者機関による監査結果ではない）。 余計なコントロールに対するこうした抑制は、徐々にチーム内部で再利用可能な2つの判断基準（問い）として定着していった。
- 「この作業のリリース告知文（launch post）はどうなるか」：チームは「この作業のリリース告知文はどう書けるか」と問いかける。ユーザーが直接実感できる十分に魅力的な価値を言語化できないのであれば、その作業はおそらくやるべきではない。
- 「Grok Bot now has ...（〜が追加された）」を「Grok Bot can now ...（〜ができるようになった）」に書き換えられるか？：検討の焦点を「UI上に特定のボタン、プルダウン、連携導線が追加されたこと」から「Botに直接実行可能なタスク能力が新たに備わったこと」へと引き戻し、それによってUI上の不要なピクセルを極力削ぎ落とすようチームを追い込んだ。
クローズドベータ3週間の真の総力戦：機能削減にとどまらない、システム欠陥の定量的な修復
一般公開前の約3週間にわたるクローズドベータにおいて、チームが行った作業は視覚的な引き算や実験的機能の削除にとどまらなかった。Romanの明かすところでは、当時のBotには依然として、目標のボタンをうまくクリックできない、システムのログイン画面でスタックして先へ進めないといった初歩的な失敗が多発していた。チームは実ユーザーの具体的なタスクを注視し、タスクと失敗の類型を収集し、週単位で定量的に改善を進めた。その3週間の間に、エンジニアリングチームは約5つの最も重要なバックエンドの問題を集中的に処理した。それでもなお、システムがあらゆる複雑なプロセスを安定して引き継げるようになったわけではなく、その基底には人手によるフォールバックや継続的なブラッシュアップを要する境界が依然として数多く存在していた。
プロダクトを実際の業務に投入する：チームは何を検証したのか？
プロダクトの一般公開を控えた約2週間の間、チームは極めて負荷の高い取り組みを実施した。コアチーム自らが現場に立ち、数百名の初期ユーザー（司会者の推計では約200〜300人）に対して1対1で手動のオンボーディング（Onboarding）を完遂したのである。これは単なる数字のアピールではなく、緊密で高頻度なフィードバックループを形成した。初期の20分間のガイダンス通話では、クラウドPCが起動しなかったり、ユーザーが画面を前にして何から始めればよいか途方に暮れたりする場面が頻発した。チームは「今日発見した問題は、明日次のユーザーを案内する前に必ず修正する」という原則を打ち立てた。同時にチームは、個人のカフェ経営者など、シリコンバレーの技術界隈とは完全に無縁な非技術系ユーザーを意図的に招待した。その中核的な目的は、一部のギーク向けのおもちゃではなく、真に汎用的なナレッジワーク向けプロダクトと呼べるものになっているかを検証することにあった。
この高密度なぶつかり合いの中で、最も生命力のあるいくつかの利用形態が自然発生的に現れてきた。
1. 「参謀長（Chief of Staff）」協働モデル
社内展開後の最初の1〜2週間によく見られたパターンは、各自が5〜10体のBotを作成し、それぞれに異なる業務領域を担当させるというものだった。
第2週末になると、一部のユーザーがひときわ優秀なBotを「参謀長（Chief of Staff）」として選び出し、主にそのBotと対話して他のBotへタスクを割り振らせている様子が観察された。これは一部のユーザーが自発的に生み出した使い方であり、多数派の一般的な状態ではなく、後戻りできない固定的な階層構造でもない。チームはこのパターンに対して軽度のガイダンスを行うにとどめている。
2. 人材採用における能動的な発掘
人材採用の現場において、同社の採用チームは、トップクラスの人材とは積極的に履歴書を送ってくる層ではなく、能動的に発掘すべき対象であることが多いと考えていた。
社内で設定された採用Botは、ある探索的なフローを実証した。先端的な学術会議のウェブサイトにアクセスし、Google Scholarにまだインデックスされていない最新のPDF論文をダウンロードする。論文から著者リストを抽出し、新しい名前をスプレッドシート（Spreadsheet）に追加する。続いて社内にその人物と直接のつながりを持つ者がいるかを確認し、もし該当者がいれば、担当の同僚に直接Slackメッセージを送信して紹介を依頼する。この一連のフローは、クラウドPCと長時間の処理を行うAgentの組み合わせが、非標準的なウェブページ、ドキュメント抽出、社内コラボレーションを連携させる上で持つ探索的なポテンシャルを示した。
3. 営業および非標準エンタープライズ管理画面の探索
営業担当者は、使い勝手の良いAPIを持たないツールや社内ダッシュボードと日常的に向き合う必要がある。クローズドベータ中、BotはSalesforceのダッシュボード上の目標位置をマウスで正確にクリックできなかったり、システムへのログインに失敗したりすることがあった。チームはブラウザの可視性、画面ピクセル、マウス制御といった基礎能力を改善することで、Botがこの種のUIを徐々に操作できるように試みた。しかしRomanは同時に、当時こうしたインタラクションは依然として失敗することがあり、継続的な最適化が必要であって、いかなるシステムでも安定して引き継げる状態には達していなかったことも指摘している。
4. 個人的な探索事例：再帰テスト（Bot in Bot）
社内テストでは、ギーク的な個人利用も生まれた。例えばRoman個人は、自身のクラウドPC環境内でデスクトップ版のGrokBot自身をダウンロードしてインストールした。彼はQAテスターBot（QA tester bot）を構築し、改善し続けていることを継続的に確認すべき10個の重要ワークフローを専らテストさせ、その結果をNotionに書き出して過去のクライアントバージョンと比較させた。留意すべき点として、これはRoman個人の利用試行に属するものであり、チームが全面的に制度化して運用している確定したQAプロセスではない。
5. 「受動的な待機」から境界線を設定した能動的リマインドへ
初心者のユーザーは通常、Agentを受動的な情報整理ツールとして捉え、定期的に要約を報告させる。しかしさらに進んだ探索の方向性は、Botにメールやチャットなどの情報ストリームを接続させた上で、明確なトリガーの境界を設定することだ。大半の時間は静かに待機し、ユーザーがあらかじめ定義したごく少数の緊急事態においてのみ、能動的な呼び出し（Page）や人間へのリマインドを発動させる。この使い方が成立する前提条件は、Botが頻繁に誤報を出さないとユーザーが十分に信頼できていることである。
高度な協働：統合アウトプットとデイリーダイジェスト
単一のタスクにとどまらず、Romanは上級ユーザーによる第2階層の協働手法についても言及した。複数のBot間の連携を設計し、異なる専門領域を担当するBotたちがそれぞれの成果物を人間が読める統一されたデータベースやストレージ（Notionや統合スプレッドシートなど）に集約して書き込む。人間のユーザーは各Botのセッションを個別に確認する必要はなく、統合されたデイリーダイジェスト（Daily Digest）を通じて集中的に目を通し、意思決定を下すことができる。
ワークフローの分解
真の Agent は、単に答えを出すだけでなく、一連の業務チェーンをやり遂げる
インタビュー事例を選択して、Bot への入力、連続アクション、人間のチェックポイント、および当時の能力の境界を確認できます。
それが証明するもの：定期実行、非定型なWebページ、ドキュメント処理、社内コラボレーションを一連のチェーンとして連携できること。
当時の境界：クリック精度やログインが原因で依然としてタスク失敗が発生し、Computer Use は万能の手段ではない。
証拠の境界：これは Roman の個人的な試みであり、制度化されたチームの QA プロセスではない。
それが変えたこと：ユーザーが各 Bot の会話履歴を1つずつ確認する必要がなくなったこと。
進化の道筋：個人情報の完結からエンタープライズ浸透への未解決課題
情報ループの探索において、Romanは利用者の段階に応じたパターンを区別している。V1は多くのユーザーが採用する一般的なパターンで、BotがSlackとメールをカバーし、優先度に応じて即時リマインドするかデイリーまとめに格納する。Roman自身の個人的な設定は約V3またはV4に位置しており、BotがX上のGrokBotへの言及を取り込み、社内のコンテキストと結合させ、QAテスターと連携してバグの再現を試み、自身のメッセージチャネルを通じてフィードバックに迅速に対応する。この探索がもたらす新たな価値は、「外部シグナル → 社内コンテキスト → QA再現 → フィードバック対応」という一連のチェーンに集約されている。
個人の探索から企業への導入に至るプロセスについて、RomanはAIプログラミングツールの普及プロセスを振り返った。初期のAIプログラミングツール利用者は、まず夜間や週末の個人プロジェクトで価値を体験し、職場に戻った後に業務での利用を要求した。Romanは、ナレッジワーク向けAgentも同様に、まず個人のシナリオで「アハ体験（aha moment）」を生み出し、その後にチームへと浸透して経済的価値のある業務に貢献するようになると予想している。
ただしRomanは同時に、Agentが現実の複雑なエンタープライズ環境に入り込もうとする際には、依然として多くの未解決の課題（unanswered questions）に直面していることを強調した。Botはいかにして複雑な社内システムに入り込み、会社のコンテキストや歴史を理解するのか、より大きなチームの中でどのように協働するのか、そして組織レベルの記憶とはどのようなものであるべきなのか、といった点である。
競争優位（モート）はどう築くか：まず今後3〜6か月の能力を作り出す
現在のAIスタートアップ環境において、創業者や投資家が最も不安視する問いは往々にしてこうだ。「もし基盤大規模モデルベンダー（OpenAIやAnthropicなど）が、次世代の基底モデルにこうした機能を直接統合してきた場合、上位プロダクトの競争優位（Moat）は一体どこにあるのか？」
こうした戦略的不安に対し、Romanは、12〜24か月先の戦略図からプロダクトを逆算するのではなく、今日真に役に立つものにまず集中すべきだと強調した。Lennyはその後、この見解を次のように要約した。「まずは人々を夢中にさせる（Obsessed）プロダクトを作ることだ。競争優位は往々にしてそのプロセスの中で発見されるものであり、あらかじめ計画できるものではない」。
チームは過去数年間のイテレーションの中で、「タイムマシン」に似た開発のリズムを模索してきた。
- トレンドを予測する：今後3〜6か月の間にモデルの能力が向上することで、今日は不可能な何が可能になるかを大まかに見極める。
- 未来を先取りして引き寄せる：基底モデルの成熟をただ待つのではなく、既存のモデルの上にエンジニアリングによる足場（Scaffolding）を組み、そうした未来の体験を可能な限り前倒しでユーザーの手元に届ける。
- 足場を果断に撤去する：下層のモデルがネイティブに能力を補完した段階で、もはや不要となった足場を削除し、それをプロダクトのデフォルトの能力に変える。そして、依然として困難な次のフロンティアへと再び照準を合わせる。
このことは、チームがおよそ6か月ごと、最近ではさらに短いスパンで、プロダクトの優先順位やコアとなる形態を大幅に再定義する必要があるとRomanが考える理由をも説明している。モデルの能力とユーザーの行動の双方が急速に変化しているとき、今日成り立っているプロダクトの境界線が長期にわたって維持できるとは限らないからだ。
Romanは、このように「自己破壊を続け、果敢にコードを削除する」高速のサイクルにおける核心的な論理は、基盤モデルのアップグレードを受動的に待つのではなく、エンジニアリングの手法を通じて未来の能力をユーザーに先回りして届けることにあると考えている。このプロセスを通じて、チームは静的な戦略図に頼って揺るぎない競争優位を空論するのではなく、実際のユーザーの日常的な利用習慣、データフィードバック、流通チャネルにおいて先行者優位を築ける可能性があるのだ。
一般の人はどう始めるべきか：まずは境界が明確な1つの仕事を引き渡す
単発の対話モデルを脱却し、長期的なAgentアシスタントの構築に初めて挑戦しようとする読者に向けて、インタビューでは具体的な実践の切り口と探索のアドバイスが提示された。
-
新入社員に接するように実際のコンテキストを提供する。ただしセキュリティの境界は死守する 真空の中に浮かんでいるようなモデルが何もないところから負担を軽減してくれると期待してはならない。第一歩は往々にして、日々の業務に関わる主要なチャネル（業務用メール、チームコラボレーション用のチャットツール、ナレッジベースなど）にBotを接続させることだ。Romanは、多くの人々が個人業務と会社業務の分離を求めていると述べており、組織レベルの記憶や複数のBotが実際の複雑なチームでいかに協働するかには依然として多くの未解決の課題（unanswered questions）があることを認めている。Lennyはその後さらに、個人データと業務データの混在（cross-contamination）および業務データの外部流出（exfiltration）のリスクを提起した。 これらのリスクを踏まえ、本稿では実際に権限を開放する際、最小特権と個人/業務データの分離から着手し、いつでも取り消し可能な認証を優先し、外部送信や高リスク操作を伴うアクションには人間による承認を設定することを推奨する。
-
「逆質問」でコールドスタートを打破する 真新しいAgentのUIを前にしたとき、多くの人が抱く戸惑いは「何をさせればいいのかわからない」ということだ。Romanは実際の利用において、Botに自身のメールやSlackを読み込ませた上で、次のようなプロンプトを与える手法を挙げた。「私の負担を減らすことができる5つのことと、それを実行するためにそれぞれ何が必要かを提案してほしい（Suggest like five things that you can take off of my plate and what it would take for you to do that）」。
実際の試みにおいては、この発想に沿って、より実践しやすいプロンプトへと書き換えることができる。
「私の直近のメールと日常のコミュニケーション履歴を通読し、私の業務上の役割を踏まえて、あなたが直接私の代わりに引き受けることができる具体的なタスクの塊を5つ能動的にリストアップしてください。また、それらのタスクをこなすために、それぞれどのようなシステム権限を新たに取得する必要があるかも教えてください。」
Roman自身の試行では、5つのうち2つが実際に有用だったため、彼はその2つのためにそれぞれBotを1体ずつ作成した。読者にとっても、いきなりすべての仕事を一括して引き渡すのではなく、まずは境界が明確で結果を検証可能な1〜2個のタスクを選ぶことが、より手堅いスタートラインとなる。
チャット欄でのテキスト生成から、クラウドPC上に常駐するデジタル協働ネットワークへ——AI Agentは今、「技術デモの披露」から「実用性」へと重心の移行を遂げつつある。しかし冷静に見つめなければならないのは、Romanがインタビューの終盤で強調したように、今回のAgent探索の波は依然として「極めて初期の段階（very early innings）」にあるという事実だ。人間が完全に目を閉じて権限を委譲し、全面的に背中を預けられるほどの成熟度には到底達していない。より現実的な道筋は、境界を明確にし、検証を怠らない前提のもとで、反復性が高くプロセスの明確な作業を段階的に引き渡し、人と機械の継続的な協働とすり合わせの中で新たな働き方を模索していくことである。