ChatGPT Work／Codex責任者 Tara Seshan氏：常時稼働するAI同僚との働き方

常時稼働するAI同僚と、チャットや単発エージェントの違い

Tara氏は、仕事上の関係性を、一回の質疑応答、一度きりのタスク、そして継続的なプロジェクトという三つの段階で区別します。これらは同時に存在し得ますが、その違いは、AIが時間を超えて文脈を保持できるか、実行を継続できるか、人間のチェックや軌道修正を受け入れられるか、そして複数人が関わる作業空間に入れるかどうかにあります。以下のインタラクティブ図は、これら三つの関係を同じ一連の軸で比較したものです。各段階をクリックすると、時間単位、文脈、人間の介入方法、コラボレーションの範囲を比較できます。

したがって、「永続的」であるためには、少なくとも次の五つの条件が必要です。

1. 持続可能な実行環境。 タスクはローカルまたはクラウドで継続でき、一度のチャットが終わっても停止しない。
2. 利用可能なプロジェクト文脈。 ファイル、過去の決定、データ、必要なビジネス背景を読み取れる。
3. 制御された権限。 メール、ドキュメント、コードベース、財務システムごとに明確なアクセス境界がある。
4. 十分な信頼性。 長時間のタスクが失敗しても復旧でき、重要なアクションは検証可能で、結果は遡って確認できる。
5. コラボレーション用インターフェース。 人間が進捗を確認し、途中で介入し、別の同僚を同じ作業に招待できる。

Tara氏は、こうした「質素な」インフラストラクチャの重要性を特に強調します。モデルの知能だけを高めても、賢いけれどもコンピューターも資料もなく、安定した成果物を納品できない一時的なヘルパーができるだけです。OpenAIのChatGPT Workというプロダクトの位置づけも、アプリやファイルをまたいだ作業、数時間にわたる継続的な実行、目標から完成品までの導線を含んでおり、その基盤技術としてCodexが使われていると説明されています。OpenAIプロダクト発表

ChatGPT WorkとCodex：同じ実行能力、異なる作業エントリーポイント

インタビュー収録時の時点では、ユーザーはChatGPTのChat、Work、そして独立したCodexという複数の名前を目にします。Tara氏の説明は非常に直接的です。これらのエントリーポイントは、まず異なるユーザーの習熟度に応じて用意されています。

Workはその基盤としてCodexの実行能力を使っています。Tara氏によれば、Codexに財務モデルを作らせても、Workに劣るということは本質的にはありません。違いは主に、プロダクトがユーザーに見せる詳細の度合いにあります。OpenAIのヘルプセンターでも、Chat、Work、Codexは異なる作業方法として説明されており、長期的な方向性としては、ユーザーが選択する負担を減らすことです。OpenAIヘルプセンター

最終的なゴールは、何十億人ものユーザーにモデルやハーネス、ワークツリーとは何かを理解してもらうことではありません。ユーザーが目標を記述すれば、システムが適切なモデル、ツール、実行環境を選択し、タスクに応じて適切なコントロールパネルを表示します。複数のエントリーポイントは移行期のプロダクト上の取り決めであり、理想的な状態で恒久的に認知負荷を増やすものではありません。

漕ぐことから舵を取ることへ：人間とAIの役割分担

Tara氏はプロダクトマネージャーの変化を「漕ぐことから舵を取ることへ」と表現します。漕ぐことは、すべての実行アクションを自分で推し進めることです。舵を取ることは、どこへ行くのか、なぜ行くのか、どうずれを判断するのか、そしていつルートを変えるべきかを決めることです。

エージェントがコードを書き、リサーチをし、モデルを生成し、ページを構築できるようになると、エンジニアリング、プロダクト、デザインの境界線は薄くなります。一人の人間が、かつての専門的な分業を越えて、より多くの工程を完結できるようになります。しかし、境界線が薄くなることは、責任がなくなることを意味しません。チームは依然として、次の三つの問いに明確に答えられる人が必要です。このプロダクトを必要とする人がいるか。品質は要求を満たしているか。最終的な結果に誰が責任を負うのか。

役割の境界線が薄くなることは、古い専門的な技能の一部が抽象化されることも意味します。Tara氏は簡単な答えを示してはいません。プロダクトマネージャーは従来の仕事の一部を自ら手掛けなくなるかもしれませんし、エンジニアは手でコードを書くときのフロー体験を懐かしく思うでしょう。新しい専門性は、特定のアクションを完了することから、問題の選択、ツールのオーケストレーション、品質の判断、結果への責任へと移行します。クロスファンクショナルな効率性と、自らの専門性を磨き続けることのバランスをどう取るかは、依然として未解決の問いです。

同じチームの全員が同等のモデルとツールを利用できるようになると、差は主に以下の能力から生まれます。

• 方向性。 どの問題を解決する価値があるかを選び、できそうだが価値のないタスクを断る。
• センス。 どのような体験、表現、ディテールが完全な作品を構成するかを判断する。Tara氏はソフトウェアを映画に例えます。予算が大きいからといって自動的により良い映画が生まれるわけではありません。
• 表現。 漠然とした感覚を明確な主張に変え、他の人が理解し、疑問を呈し、一緒に修正できるようにする。
• 説明責任。 結果の正確さ、影響、その後のアクションに責任を持ち、失敗をモデルのせいにしない。
• 人間関係。 チームメンバーが互いに信頼し、共に学び、目標を引き上げようとする意欲を育む。

最後の点は、Tara氏が繰り返し言及するambition（野心）です。多くのチームはAIを古いタスクの自動化に使います。週報をより速く書く、以前から行っていた分析をより速く行うといったことです。彼女が観察するハイレベルなユーザーは、プロジェクトの規模を再評価します。一人で、以前は小さなチームが必要だったプロダクトを完成させられるか。チームは数ヶ月の探求を数週間に圧縮し、省いた実行力をより大きな問題に投入できるか。

これはすべての作業に無限のスピードアップを求めるものではありません。新しい制約を示しています。実行コストが下がると、組織の上限はますます「自分たちが何ができると思うか」に影響されます。PMの仕事の一部も、進捗を急かすことから、チームが達成可能な目標に対する判断力を高めることへと移行しています。

急速に進化するモデルに直面して、OpenAIはどうプロダクトを先取りして設計するか

従来のソフトウェアは、基盤となる能力を比較的安定した制約と見なします。チームはデータベース、ブラウザ、デバイスがおおむね何ができるかを把握し、その境界内で機能を最適化します。一方、最先端のAIプロダクトは、絶えず動く地面の上にあります。今日は信頼できないアクションが、数週間後には使えるようになるかもしれません。今日の限界に合わせて設計されたパッチが、プロダクトがリリースされる頃には、むしろ足かせになっているかもしれません。

Tara氏が挙げる社内の作業時間枠は二〜三ヶ月です。

• 現在のモデルだけに合わせて設計すると、チームは「ちょうどできる」位置に多大なエンジニアリング投資をすることになります。プロダクトがリリースされる頃には、より強力なモデルがその難題を解決してしまっているでしょう。
• 一年後の能力に向けて設計する場合、想定が遠すぎて、実際のモデルとユーザーの行動で検証できず、ビジョンを事実と混同しがちです。
• 二〜三ヶ月という期間は、プロダクトチームが研究ロードマップを参考に、新しいインタラクションや実行の枠組みを事前に準備しつつ、観測可能なフィードバックを迅速に得ることを可能にします。

この時間枠は、すべての企業に機械的に適用できるものではありません。OpenAIはモデル研究のロードマップに直接アクセスでき、社内バージョンを高頻度で使うこともできます。外部のチームには同等の情報はありません。移転可能な方法は、プロダクト上の判断を反証可能な仮説として書き出し、できるだけ早く証拠を積み上げることです。

Tara氏は、Codaの共同創業者であるShishir Mehrotra氏の「eigenquestion」という概念を引用します。それは、多くの後続の問いを同時に明確にするような問いをまず見つけることです。次にプロトタイプを作り、実際に人に使わせ、行動を観察し、仮説を修正します。プロダクトマネージャーは以前、完全な提案書を書くのに数週間かけるかもしれませんでした。今では、より効果的なコミュニケーションツールは、試せるモックアップ、動くプロトタイプ、あるいはすでに得られた実験結果のセットであることが多いです。

これはOpenAIのスピード感も説明します。インタビューでは、すべてを統括する「秘密の戦略ドキュメント」は登場しません。チームメンバーは創業者のように問題を発見し、自分たちの作ったプロダクトを使い続け、社内体験と公開市場からのフィードバックを短いループでつなぐことが求められています。このスピードは、不確かな判断をより早く検証可能な現実に変えつつ、品質管理を維持することから生まれます。

このスピードには明確なトレードオフが伴います。Tara氏は、かつてのソフトウェアチームはすべてのインタラクションが十分に磨かれてからリリースを待つことが多かったと述べます。モデルとユーザーの習慣が同時に急速に変化するとき、もしチームがプロダクトが質的な変化をもたらすと確信しているなら、ユーザーに先に使ってもらい、実際のフィードバックに基づいて修正する方が、完璧を待つよりも価値があることがよくあります。これはユーザビリティを放棄することではなく、「プロダクトが十分に大きな変化をもたらすか」を「すべての隅々が磨かれているか」より優先するということです。

AI同僚の受け入れは、最終結果だけを見て判断できない

コーディングエージェントをナレッジワークに移植する際に、最も見落とされがちなのが受け入れ方法の違いです。

コードには比較的明確な結果検証があります。コンパイルが通るか、テストがパスするか、UIが動作するか、パフォーマンスが基準を満たすか。テストはプロダクトが必ず正しいことを保証するわけではありませんが、大量の誤った結果を迅速にふるい落とすことができます。

一方、財務モデル、市場調査、経営陣向けの提案書には、これほど明確な合格ボタンはありません。表の数字は見た目が美しくても、参照が間違っているかもしれません。プレゼンテーションは論理的に流暢でも、結論を左右する反例を欠いているかもしれません。レポートの最後のページに「成功率90%」と書かれていても、読者はその数字だけから信頼性を判断することはできません。

ナレッジワークの受け入れには、より長い証拠の連鎖が必要です。

1. 背景が完全か。 エージェントはどのメール、ドキュメント、データ、既存の決定を見たのか？
2. 入力が信頼できるか。 一次資料、二次的な要約、それとも未検証のウェブページの断片を使っているのか？
3. プロセスに介入できるか。 人間は方向が間違っているときに中止したり、制約を追加したり、範囲を絞ったりできるか？
4. 中間成果物を監査できるか。 主要な仮定、引用、計算、除外された代替案が見えるか？
5. 最終結果を遡れるか。 すべての重要な数字と判断について、出典と責任者を見つけられるか？

これは、モデルのプライベートな思考連鎖を公開することを要求するものではありません。公開が必要なのは、作業の証拠です。何を引用したか、何を実行したか、成果物がどう変化したか、どこで人間の確認が必要か。常時稼働する同僚がより自律的に実行できるようになればなるほど、人間が低コストで情報を得て制御できるようにする必要があります。

文章作成から考える：AIに任せる仕事と、人間が判断すべきこと

Tara氏のAIを使った文章作成における線引きは、「使うか使わないか」よりも具体的です。

「報告のための文章作成」には、週報、ステータスサマリー、会議資料の整理、形式変換、既知の内容の再構成が含まれます。目的は既存の情報を正確に伝えることであり、モデルに大量の機械的な作業を任せるのに適しています。

「思考のための文章作成」は、見解がまだ形になっていないときに行われます。アウトラインを書く、初稿を書く、もろい文を削る、議論のギャップを見つける。これらの動作自体が思考を構成します。もし最初からモデルに完全な文章を生成させると、人間は流暢なテキストを得るかもしれませんが、判断を形成するプロセスをスキップしてしまいます。

彼女自身のルールは、思考のための文章作成は自分で始め、自分で終えることです。AIはその途中で、資料を探したり、データを集めたり、反例を挙げたり、仮説を攻撃したりできます。しかし、最終的な構成と文章は彼女自身が再判断します。彼女はまた、あるコラボレーションの方法を常に使っています。ドキュメントが約70%完成した時点で、参加すべき人に見せるのです。そうすることで、相手が疑問を呈し、一緒に形を整える余地が生まれます。完全に磨き上げられた成果物は、新しいアイデアを跳ね返してしまうことがあるからです。

彼女はまた、非常に重い個人的な説明責任のルールをドキュメントと会議に適用しています。もし数人に自分のドキュメントを読んでもらうなら、自分も少なくとも同じ回数は実際に読んでいます。もし会議を招集するなら、参加者全員の合計時間と同じだけの時間を事前準備に投じます。重要なのは機械的に時間を計算することではなく、AIで資料を生成した後、理解とレビューのコストを他人に転嫁しないことです。

同じ線引きは、他のタスクにも当てはまります。

Tara氏は、Sitesを使ってチームのゲームや旅行のルート、社内ダッシュボードを作成し、Visualizeを使ってデータをストーリーとして構成しています。これらの例は、ナレッジワークのデフォルトの成果物が、常にドキュメントやスライドである必要はないことを示しています。一時的なニーズは、実行可能で共有可能な、データベースを備えた小さなツールに直接変えることができます。AI同僚が表現の形式を広げ、人間は何を表現するかを決め続けます。

彼女は Sutter Hill で、さらに前段階の検証方法を学びました。それは「プロダクト・マーケティング・フィット」を先にテストするという方法です。チームは完全なプロダクトを作る前に、まず多くの潜在ユーザーに対して、それがどのような問題を解決し、なぜ現状を変えるのかを説明します。そして、どのようなポジショニングであれば相手に理解され、継続してもらえるのかを観察します。ここでのストーリーテリングは、プロダクト完成後の演出ではなく、低コストなプロダクト発見のためのツールです。モデルのおかげでプロトタイプが安価になれば、ポジショニング、プロトタイプ、実際のフィードバックを、より早く同じ検証サイクルに組み込むことができます。

常時稼働するAI同僚と働くための六つのプロトコル

個人やチームは、「第三段階」が完全に成熟するまで待ってから仕事の進め方を調整する必要はありません。まずは、複雑なタスクを一つ、以下の六つの明確な約束事に作り変えてみることができます。

1. アクションではなく、目標を書く。 「レポートを作る」だけでなく、そのレポートがどのような決定をサポートするのか、読者は誰か、何をもって完了とするのかを説明します。
2. 必要なコンテキストを提供する。 生データ、過去の決定事項、制約を同じプロジェクト内に置き、エージェントが推測で補完しなければならない状況を避けます。
3. 中間チェックポイントを設定する。 長いタスクでは、大規模な実行を続ける前に、調査範囲、構造、サンプルなどを先に確認します。
4. 作業の証拠を求める。 出典、計算、修正記録、確認できなかった事項を保存し、最終成果物を遡って検証できるようにします。
5. 最終的な責任者を一人に固定する。 エージェントが実行することはできますが、公開、支払い、外部とのコミュニケーション、またはリスクの高い決定を承認する責任者は、常に存在する必要があります。
6. 毎回、目標を高く設定する。 節約できた時間を記録する一方で、単に以前のタスクを速くしただけではないかも確認します。そして、新しく得た能力の一部を、これまで着手をためらっていたプロジェクトに使います。

インタビューの最後に、Tara さんは「持続性」を非常に具体的なモバイルのシナリオで説明してくれました。スマートフォンで仕事を依頼し、ネットワークの繋がらない地下鉄に乗り、出てきたときにはタスクがクラウド上で完了していて、人間はそれを確認して会話を続ける、というシナリオです。これは単にバックグラウンドで動いているように聞こえますが、実は仕事の関係性を根本から変えています。人間はすべてのステップの実行を見守る必要はなくなりますが、より明確に方向性を示し、境界線を設定し、証拠を確認し、結果に対して責任を負うことが求められます。

AI同僚がより自律的に働けるようになればなるほど、人間の仕事は、「より多くのコンテンツを生成する」だけでは解決できない問題に集中していきます。それは、私たちがどこへ向かうのか、どの程度の品質で十分なのか、どの証拠を信頼できるのか、そして、最終的な選択に誰が責任を持つのか、といった問題です。