OpenAIが発表したChatGPTのWorkspace agentsは、単なるカスタムGPTの拡張ではなく、チーム内の反復業務を自動化する新しい業務基盤である。本動画では、Workspace agentsがどのような製品なのか、従来のカスタムGPTやProjectsと何が違うのか、どの業務に向き、どの業務には向かないのか、企業導入で重要となるガバナンス、そして最初に作るべきエージェントの具体例までを解説している。特に、Slack、Google Drive、SharePoint、カレンダーなど複数ツールをまたぐ定型業務に対して、これまでZapierやMake、n8nなどが担ってきた軽量な自動化レイヤーをOpenAIが取り込み始めている点が重要である。
OpenAIのWorkspace agentsが意味するもの
OpenAIがChatGPT Workspace agentsを発表しました。そして私はこの1週間、実際にそれを使おうとしているチームと一緒にリサーチプレビューを見てきました。その結果、このニュースの見出しはかなり控えめに扱われていると思います。
これは単に、より優れたコネクターを備えたカスタムGPTではありません。これは単に、特定の種類の作業向けにスケジュールボタンが付いたProjectsでもありません。
Workspace agentsは、企業がZapier、Make、Warcado、n8n、Copilot Studio、そして大量の社内のつなぎ込みによって組み立ててきた軽量な自動化レイヤーに対する、直接的な競合です。
これが重要な理由は単純です。最初に役に立つものを作るのに、6か月かかる変革プロジェクトは必要ありません。おそらく午後の数時間で済みます。
そこでこの動画では、6つのことを順に見ていきます。
製品には実際に何が入っているのか。カスタムGPTやProjectsのような以前のバージョンと何が違うのか。うまく機能する作業パターンは何か。逆にうまく機能しないパターンは何か。企業にとってこれを現実的なものにするガバナンスの部分。そして、私なら最初にどのエージェントを作るか、です。
要するにこういうことです。
あなたのチームに、毎週繰り返され、2つか3つのツールをまたぎ、すでに良いアウトプットと悪いアウトプットの違いがはっきりしている仕事があるなら、これは今すぐ試せる最も安価なエージェント実験かもしれません。
ただし、この一文の中には多くの含意が隠れています。では、実際に箱の中に何が入っているのかを見ていきましょう。
製品の中身と基本的な使い方
4月22日、OpenAIはWorkspace agentsをChatGPTに導入しました。これはBusiness、Enterprise、Education、Teachersプラン向けのリサーチプレビューです。展開は段階的で、Enterpriseの管理者が有効化する必要があります。つまり、今日すべての人が使えるという状況ではありません。しかし方向性は明確です。
サイドバーでAgentsをクリックします。チームが頻繁に行っているワークフローを説明します。するとChatGPTが、その説明をエージェントに変えるのを手伝ってくれます。
ビルダーは、プロフィールの下書きを作成し、ツールや接続アプリの選択を支援し、スキルを生成または添付し、指示を書き出し、公開前にプレビューできる画面を提供します。
ゼロから始めることもできますし、製品フィードバックの振り分け、週次メトリクスレポート、リードへのアウトリーチ、ソフトウェアレビュー、そのほか似たような反復的なチームワークフロー向けのテンプレートや例から始めることもできます。
この構築体験こそが、まずカテゴリを変える最初のポイントです。
3週間前であれば、Slackの中に存在し、SharePointやGoogle Driveを横断的に見て、カレンダーを理解し、スケジュールに沿って実行され、定期的なアウトプットを出す共有チームエージェントが欲しいと思った場合、基本的には2つの選択肢しかありませんでした。
エンジニアに関わってもらうか、チームとしてローコード自動化プラットフォームに取り組むかです。
今では、対象となるワークスペースであれば、ワークフローを自然な英語で説明し、それをGoogle Calendar、Google Drive、Slack、SharePointのようなアプリにつなぎ込めます。組み込みツールの範囲を超えるものが必要なら、カスタムMCPサーバーを追加することもできます。そして実際にそれを必要としている人たちに公開できます。
もちろんこれは、技術に詳しくない人が突然みんな優れた自動化アーキテクトになる、という意味ではありません。ここははっきりさせておきたいところです。
しかし、自動化の最初の下書きを作るために、もはやまったく別のソフトウェアプロジェクトを立ち上げる必要はなくなった、という意味ではあります。これが製品としての変化です。
Workspace agentsはChatGPTの中で動作します。ワークスペース内で共有できます。スケジュール実行できます。そしてChatGPT agentアプリを通じてSlack内でも実行できます。つまり、チームを別の画面に押し込むのではなく、すでに仕事が起きている場所に現れるのです。
このSlackの点は、使ってみるまでは小さなことに聞こえるかもしれません。
社内AIツールの多くは、本当に退屈な理由で失敗します。人々がそれを開くことを覚えていないのです。ワークフローが実際の仕事が起きる場所の隣に存在しているだけだと、隣にあるものは最終的には任意のものになります。私たちは怠け者です。
リクエストが出るSlackチャンネル、エスカレーションが発生する場所、案件について議論される場所にエージェントがいるなら、それは別タブに存在するものではなく、仕事の一部になります。
社内でこれを売り込もうとする前に知っておくべき環境面の詳細もいくつかあります。
Workspace agentsはChatGPT Plusでは利用できません。ワークスペースプラン向けです。Enterpriseワークスペースではローンチ時点でデフォルトではオフです。また、Enterprise Key Managementを利用しているEnterprise顧客には提供されていません。
さらに、5月6日までは無料ですが、その後はOpenAIによればクレジットベースの価格設定が始まります。ですから、アクセス権があり、実際の手応えを得たいなら、料金のことをあまり考えずに試せる期間はかなり短いです。
ここまでが6つのうちの1つ目です。
この製品は単なるチャットボットではありません。反復的なチームワークフローのためのクラウド型エージェントビルダーです。
次に、それがなぜ重要なのかに入っていきます。なぜなら、これはカスタムGPTやProjectsが目指していたものの、実際にはたどり着けなかったものだからです。
カスタムGPTやProjectsとの違い
先に少し文脈を置いておきます。これは驚きではないと思いますが、私は企業そのものではありません。ですから、ここで話している本格的な構築例は、私個人の社内ワークフローではありません。
それらは、私とつながっている小規模および大規模なチームのものであり、彼らが非公開で、何がうまくいっていて何がうまくいっていないかを私に話してくれているものです。
今週私がやっていたのは、そうしたチームが最初のWorkspace agentsを立ち上げる横に座り、わずか1か月前に同じチームがカスタムGPTやProjectsから得ていたアウトプットと比較することでした。
そしてこの違いは重要です。なぜならWorkspace agentsは、本質的には個人の生産性向けには作られていないからです。共有される仕事のために作られています。
複数の人、複数のシステム、たくさんの繰り返される判断が絡む、厄介な中間領域のために作られています。その文脈では、比較はかなり明確です。
カスタムGPTは、基本的にはスーツを着たプロンプトです。指示を書き、ファイルをアップロードし、場合によってはアクションを付けて、それを公開し、人々が使ってくれることを願います。
それでうまくいく場合もあります。しかし私の経験では、品質はプロンプトを書いた人のスキルに大きく依存します。
私は、助言していたチーム内で、カスタマーサービスのチケット振り分けや他の用途にカスタムGPTを何度も試しました。あまり良い結果ではありませんでした。少し悪い程度ではありません。
チームが数週間で使うのをやめるような悪さです。なぜなら、アウトプットを疑って確認する時間まで含めると、担当者が自分でチケットを読む場合に比べて限界的な改善がマイナスだったからです。
同じ形のタスクをWorkspace agentに移すと、チケット担当者が実際に送ってもよいと思える下書きが出てきています。
違いは、誰かが魔法のプロンプトを書いたことではありません。違いは、エージェントが周囲のワークフローに対して動けることです。ツールを使えます。複数ステップをたどれます。ファイルを扱えます。チケット担当者がすでに作業している場所で動けます。そして、管理者が顧客データの近くで使うことを実際に許可できるような形でガバナンスを効かせられます。
Projectsは、カスタムGPTの次のステップでした。そしてProjectsはより優れていました。
共有ワークスペースを提供しました。ファイルを提供しました。指示を提供しました。メモリを提供しました。継続性を提供しました。
カスタムGPTがプロンプト優先だったとすれば、Projectsはコンテキスト優先でした。それは本当の改善でした。
しかしProjectsは、それでも人間側の大きな負担を前提にしています。誰かがファイルを整理し、コンテキストの整合性を保ち、セッションを開始し、何が重要かを判断し、作業を前に進めなければなりません。
私は、RFPへの回答作業でProjectsを使ったことがあります。営業チームが同じことを試すのも見てきました。Projectsは役に立ちます。カスタムGPTよりは圧倒的に優れています。しかし、仕事を自律化するものではありません。
新しいRFPが来たら、やはり人がそれを進める必要があります。
私が話していたチームの1つは、今週、そのようなRFPワークフローをWorkspace agentに移しました。
エージェントは届いたRFPを読み、SharePointから似た過去の回答を引き出し、会社のプレイブックに照らして最初のドラフトを作成し、答えられない項目に印を付け、ドラフトと不足部分をAEのSlack DMに投稿します。
これにより、数時間かかっていた組み立て作業が、20分程度の編集に変わります。これは大きな飛躍です。
これは、このツールが私の作業を助けてくれる、というものではありません。このツールが作業の最初の下書きを作り、私はそれを確認する、というものです。そしてその最初の下書きが十分に良いので、本当に時間を節約してくれるのです。
ここからカテゴリが変わり始めます。
私が見てきたチーム全体で言うと、カスタムGPTでは失敗したワークフローの多くが、今では機能し始めているワークフローとほぼ同じです。
チケット振り分け、RFP回答、インバウンドリードの選別、定期レポート、製品フィードバックの要約、営業準備です。
その理由は、別に不思議なものではありません。これらの仕事は、もともと単に文章を生成することではなかったのです。そうでしょう。
それらは調整の仕事でした。適切なコンテキストを見つけ、システム間を移動し、既知の評価基準を適用し、チームが必要としている場所にアウトプットを戻す必要がありました。
カスタムGPTでは、チームが製品を背負わされました。Projectsでは、チームがコンテキストを背負わされました。Workspace agentsは、少なくとも適合するワークフローにおいては、実際に負荷を持ち上げます。より多くのプロセスを担います。
これは重要です。なぜなら、プロンプトの画面が視界の外に移動し、それについて考えなくてよくなり、反復的な仕事を管理することに集中し始められるからです。
ここまでが、この動画の6つのうち2つ目です。
次のポイントは、何を作るべきかを決めるうえで最も重要です。Workspace agentsは、何でも得意なわけではないからです。
うまくいくワークフローの形
うまくいくユースケースには、似たような形があります。
仕事が繰り返されます。たいていは週次です。もっと頻繁な場合も多く、日次や時間単位の場合もあります。
アウトプットには、明確な良いものと明確な悪いものがあります。手順はおおよそ1段落で説明できます。そして作業は、これまで人が手動で調整しなければならなかった2つか3つ以上のツールをまたぎます。
これがパターンです。頻繁に繰り返される。明確なアウトプットがある。説明できる程度に単純である。ツールをまたぐ。
あなたの仕事がこの形に合っているなら、Workspace agentsは面白いです。合っていないなら、役に立つ可能性はありますが、そこから始めることは私なら勧めません。
私が何度も戻ってくる公開の参考事例は、OpenAIがローンチ時に強調していたRipplingの例です。
ある営業コンサルタントが、エンジニアリングチームなしで営業機会エージェントを作りました。これはアカウントを調査し、Gongの通話を要約し、進行中の商談についてチームのSlackルームに案件ブリーフを投稿します。
引用された成果としては、すべての案件について、営業担当者の週5〜6時間分の作業がバックグラウンドに移ったということでした。
これこそ、コピーしたい形です。理由は営業という文脈ではなく、構造にあります。
反復される作業対象があります。営業機会です。既知の入力があります。アカウント調査、通話メモ、案件コンテキストです。役に立つアウトプットがあります。案件ブリーフです。そしてそれを届ける場所があります。Slackです。
もちろん、明確なレビュアーもいます。その案件を所有している営業担当者です。これは良いエージェントワークフローです。
営業にいるなら、最初に作るものはかなり明白です。インバウンドリード選別エージェント、パイプライン健全性エージェント、通話後のCRM更新エージェント、あるいはターゲットアカウントを監視して有用な文脈をSlackに投稿する競合インテリジェンスエージェントです。
これらが機能するのは、営業にはすでに強い業務リズムがあるからです。リードが入ってきます。通話が発生します。案件は進むか停滞します。営業担当者は有用な要約がどのようなものかを知っています。マネージャーは悪いパイプライン管理がどのようなものかを知っています。
それにより、エージェントには狭い仕事と非常に明確な評価基準が与えられます。
もしあなたが調整作業の多い役割にいるなら、コピーすべき構築例は少し違います。
夜間に動くフィードバック統合エージェントです。
関連するチームチャンネルの直近1日分を読ませます。そこから、浮上しているテーマ、未解決の質問、障害、形成されつつある意思決定を抽出させます。そして、朝のブリーフをチーフ・オブ・スタッフ、エグゼクティブアシスタント、または散らばった会話を使えるコンテキストに変える仕事をすでに日々行っているオペレーションリードに届けさせます。
これが機能する理由は、可視性です。
アウトプットは毎朝現れます。そして失敗の形が非常に分かりやすいのです。最も重要なスレッドを見落としたなら、すぐに分かります。ノイズをシグナルとして要約したなら、すぐに分かります。最初の会議前に1時間節約できたなら、それも実感できます。
これは良い最初のエージェントです。なぜなら、それが機能したかどうかを知るのに四半期を待つ必要がないからです。
プロダクト、またはプロダクトオペレーションにいるなら、参考となる構築例は、製品フィードバックの振り分けエージェントのようなものです。
Slackを監視します。サポートチケットを見ます。公開フィードバックチャンネルを見ます。そしてノイズの中から製品フィードバックを抽出します。
繰り返し寄せられている要望を重複排除します。シグナルを製品領域ごとにグループ化します。そして、元のチケットやスレッドへのリンク付きで週次ダイジェストを公開します。
これは、要約があれば便利というものではなく、要約そのものが実際の仕事である領域の1つです。
どのプロダクトチームも、顧客に近くありたいと言います。しかしフィードバックは18か所くらいから届き、重複した報告があり、ロードマップの会話にきれいにつながる経路はなく、誰もそれを掘り返す時間がありません。
ここでエージェントはPMの判断を置き換えるわけではありません。PMが正しい対象に判断を使えるように、山を片付けるのです。
そしてこの区別は重要です。なぜなら、最良のエージェントワークフローは、高価値な判断を自動化しようとはしないからです。その判断の周囲にある調整レイヤーを自動化するのです。
カスタマーサクセスやサポートの役割にいるなら、最もレバレッジの高い最初の構築は、おそらくサポートチケット振り分けエージェントです。
届いたチケットを既存キューと照合して重複排除し、製品領域ごとにタグ付けし、既知の問題と照合し、初回返信のドラフトを作成するか、コンテキスト付きでエスカレーションします。
隣接する構築例も簡単に想像できます。週次の顧客ヘルスダイジェストや、更新日の60日前から開始し、利用傾向、サポート履歴、未解決の問題をもとにリテンションブリーフを作る更新準備エージェントです。
カスタマーサクセスには、すでに構造化データと文章によるアウトプットを持つワークフローがたくさんあります。だからエージェントはそこですばやく役立つのです。
これらすべてをつなぐ結合組織は同じです。
エージェントは戦略を発明するよう求められているのではありません。既知のシステムをまたいで、既知のプロセスを、既知の頻度で実行し、人間がすでに判断方法を知っているものを届けるよう求められているのです。
次のパートで扱う重要な逆の話は、多くの人がWorkspace agentsを試し、間違った仕事に向けて使い、製品に問題があると結論づけてしまう理由です。これがパート4です。
向かない仕事と間違った評価方法
Workspace agentsは、まず自動化と調整のプラットフォームです。
新規性のあるリサーチをしたい場合、私なら最初に手を伸ばすツールではありません。単発の磨き込まれた成果物を作りたい場合も、私ならここから始めません。そして少なくともこれまで見た限りでは、数日間にわたって進路が変わっていくような長期的な自律作業を任せる製品としては信頼しません。
私は以前、そうした仕事を行う複雑なエージェントハーネスについて話したことがあります。Workspace agentsはそのためのものではありません。
そうした仕事には、深さ、成果物の品質、長時間動作する自律性のために作られたツールを使うでしょう。
Workspace agentsが最も強いのは、道筋が分かっているときです。このフレーズを頭に置いておくとよいと思います。
道筋が分かっているなら、非常に面白くなります。道筋が分かっていないなら、注意すべきです。
今の新しいエージェント製品すべてに共通する誘惑は、想像できる最も難しいことをテストさせてしまうことです。
第3四半期の戦略全体を考えられるのか。このまだ理解していないカテゴリの市場マップを作れるのか。このオープンエンドな部門横断イニシアチブを、来月まで独立して管理できるのか。
これは間違った評価です。
ごちゃごちゃした答えが返ってきます。そして失敗の原因が、モデルなのか、ワークフローなのか、プロンプトなのか、コンテキストなのか、権限なのか、それとも完了の定義が安定していないことなのか、分からなくなります。
より良い評価はもっと狭いものです。
毎週すでに発生している1つの仕事を選びます。すでに存在する1つのアウトプットを選びます。そのアウトプットをレビューする1人の人を選びます。そして1週間、エージェントにその最初のドラフトを作らせます。
これでシグナルが得られます。人間のベースラインと比較できます。どこで時間を節約するかが見えます。どこでレビュー負担を生むかも見えます。そして、それに価値があるかどうかを判断できます。これがテストです。
かなりはっきり言うなら、仕事が新規性の高いものである場合、単発である場合、判断の比重が大きい場合、おそらくこれはあなた向けの製品ではありません。
仕事が繰り返され、ツールをまたぎ、1段落で説明できるなら、そこでようやく話が始まります。
そしてここから、企業の購買担当者がエージェントのデモ以上に気にするであろう部分に入ります。
次のパート、パート5はガバナンスについてです。
企業導入で決定的に重要なガバナンス
企業がこのようなエージェントを複数のツールにまたがって利用できるようにするには、ガバナンスに真剣な製品が必要です。
そしてガバナンスのストーリーこそが、Workspace agentsがこの四半期にEnterpriseの席を勝ち取るだろうと私が考える理由です。
管理者は、誰がエージェントを使えるか、誰が作れるか、誰が公開できるか、どのアプリやツールが許可されるか、どの種類のアクションに承認が必要かを制御できます。
バージョン履歴、実行とユーザーに関する分析、Compliance APIの対応、必要に応じてエージェントを停止する機能もあります。
コンシューマーAIの文脈で考えているなら、これはとても退屈なリストに聞こえるかもしれません。しかし、本物の会社の中でエージェントの承認を取ろうとしたことがあるなら、まったく退屈ではありません。
ほとんどのエージェント製品は、デモが悪いから失敗するのではありません。触る必要のある記録システムに対して、セキュリティとガバナンスの説明が薄く、信頼されないから失敗するのです。
CIOが欲しいのはデモではありません。CIOが知りたいのは、誰がそれを作れるのか、何にアクセスできるのか、何に書き込めるのか、ログはどこにあるのか、承認はどう機能するのか、何か問題が起きたときに会社がどれくらい早く止められるのかです。
OpenAIは、そのチェックリストに沿って構築しています。
1つ、特に注意すべき設定があります。これは、チームが急ぎすぎるとまさに間違えそうな種類のものです。
個人接続を持つエージェントの公開に対する、ロールベースの制御があります。
平易に言えば、エージェントを作った人は、自分自身の認証済みアプリ接続を使うことがあり、そのエージェントを実行する他の人たちが、作成者としてその接続を通じてデータにアクセスしたり、アクションを実行したりできる可能性があるということです。
これは強力です。同時にリスクもあります。
あなたの最高の営業コンサルタントが有用なエージェントを作り、機密性の高いシステムに接続された個人アカウント付きで公開した場合、他の全員がその接続を通じて何をできるようになるのかを理解する必要があります。
ここで正しい姿勢は最小権限だと思います。可能な限りサービスアカウントを使うこと。アクセス範囲をエージェントが実際に必要とするものに絞ること。対象者を限定すること。
ワークフローがテストされるまでは、機密性の高いコネクターや影響の大きいコネクターは避けること。そしてその設定を定期的に監査することです。
逆に間違った姿勢は、デモが動くからチームごと、ユースケースごと、アクセスごとに確認することなく全員に展開すべきだ、と仮定することです。
これは、すべての会社がSaaS自動化で学んだ苦い教訓です。ただし今回は、もちろん爆発範囲がさらに大きくなります。なぜならエージェントは、単にあるアプリから別のアプリへフィールドを移動しているだけではないからです。
内部では、Workspace agentsはクラウド上のCodexによって動いています。したがって、ツールを使い、ファイルを扱い、コードを実行し、学んだことを記憶し、複数ステップにわたって継続できます。
それが役に立つ理由です。しかしそれは同時に、プロンプトテンプレートと実行システムの違いでもあります。そして、レビューのワークフローは、エージェントが物事を実行できるという前提に立たなければならないという意味でもあります。
これは本当に当然に聞こえますよね。それでも多くの会社は、AIのアウトプットを画面上のテキストであるかのように扱っています。
しかしエージェントにおいて、テキストは目に見える部分にすぎません。重要なのは、そのシステムが以前よりはるかに多くのものに触れられるということです。
だからここでガバナンスは、企業向けの後付け要素ではありません。それ自体が製品なのです。
価値は、エージェントがCRMを更新できるというだけではありません。価値は、会社が受け入れられる権限モデルの中で、エージェントがCRMを更新できることにあります。
ここまでが5つ目のパートです。
最後のポイントは戦略的な読み解きです。何を置き換えるものなのかを理解すると、AIエージェント市場の競争図はかなり違って見えてくると思います。
競合はClaudeではなく軽量自動化レイヤーである
このローンチによって主に圧迫される会社はClaudeではありません。そう思った人もいるかもしれません。
Perplexityでもありません。ChatGPTの以前のカスタムGPT製品ですら、主な相手ではありません。
Workspace agentsが最も直接的に競合するのは、軽量自動化レイヤーです。
つまり、Zapier、Make、n8n、Copilot Studioの一部、Retoolの一部、そして企業がここ5年ほどつなぎ合わせてきた社内オペレーションワークフローです。
もちろん、これらの企業が消えるという意味ではありません。彼らにはより深い機能があります。より幅広い統合があります。成熟した顧客や、Workspace agentsがしばらく触れないユースケースがあります。
しかし、最初に問う質問が変わります。
チームが、Slackから始まり、共有ドキュメントに触れ、カレンダーを確認し、通話を要約し、チケットを更新する、またはレポートを下書きするような反復ワークフローを自動化したい場合、デフォルトの答えは、もはや明らかにZapを作りに行く、あるいはOpsに頼んでつないでもらう、ではありません。
デフォルトの答えは、まずWorkspace agentを作り、エージェントが壁にぶつかった場合にだけ専用の自動化プラットフォームへ移る、になるかもしれません。これは大きな変化です。
それはまた、Ops担当者の仕事も変えます。
もしあなたの会社が、壊れやすい自動化の山を管理したり構築したりする人を採用しようとしていたなら、今後は壊れやすい自動化自体が少なくて済むかもしれません。
すでにその人を採用しているなら、その人の仕事はおそらく、より良く、より複雑になります。会社のためにエージェントを設計し、テストし、統制し、改善する人になるからです。
これは本物の役割であり、非常に急速に成長しています。そして古いOps職よりも、はるかにレバレッジの高い役割です。
このすべての下には、さらに大きな業界パターンもあります。
2026年2月、OpenClawの作成者であるPeter Steinbergerが、パーソナルエージェントに取り組むためにOpenAIに加わりました。そしてOpenClawは、OpenAIの支援を受けたオープンソース基盤モデルへ向かいました。
OpenClawそのものに関心があるかどうかにかかわらず、このパターンは重要です。
独立系のエージェントフレームワーク構築者たちは、大手AIプラットフォームに取り込まれつつあります。
6か月前には実験的に見えたものが、標準的な製品の基本要素になりつつあります。持続的な実行、プロアクティブな実行、深いツール統合、スキル、メモリ、共有画面、そして仕事がすでに行われている場所で動くエージェントなどです。
Workspace agentsは、そのパターンがEnterprise向けChatGPT製品に到着したもののように見えます。
だから私は、このローンチは少し過小評価されやすいと思っています。
チャットボット機能として評価すると、単なるアップグレードに見えます。自動化レイヤーとして評価すると、くさびの薄い先端のように見えます。そしてEnterprise AIがどこへ向かっているのかを示すサインとして評価すると、モデルに質問する段階から、プロセスをエージェントに委任する段階へ移る、さらにもう一歩に見えます。
こちらの方が、より思慮深い読み方です。
なぜなら、注視すべき戦略は、LLMツールソリューションとしてのChatGPTが、企業ワークフローをますます多く飲み込んでいくという全体像だからです。
OpenAIのビジョンは本当に明確で、この時点では非常に明白です。
彼らはCodexと、Workspace agentsのようにCodexによって動くエージェントを、企業全体の仕事のためのデフォルトOSに変えたいのです。
そして、既存のツール群全体をまたいでシームレスにその仕事を行えるようにするコンテキストレイヤーへ、すべてを結び付けたいのです。
これはClaudeの戦略とは少し違います。Claudeが新しいものを出すとき、その多くはより垂直的です。
今、彼らはClaude Designを出しています。これはFigmaキラーとして位置づけられていました。実際にそうであるかどうかは別として、位置づけとしてはそのようになっています。そして彼らの採用傾向を見ると、金融、人事、テックなど、他のアプリケーションも狙っていることが分かります。
つまり彼らは仕事を一連の機能として見ています。
一方でOpenAIは、製品リリースを見る限り、今は仕事を部門横断ワークフローの連なりとして見ており、それをCodexやWorkspace agentsなどで飲み込み、取り込もうとしています。
こう読むのが情勢の読み方です。そしてこの競争は次にそこへ向かっていきます。
最初に作るべきエージェント
最後に、あなたが最初に何を作るべきかを残しておきたいと思います。
もしWorkspace agentsにアクセスできるなら、5月6日の無料期間が終わる前に、私ならこうします。
チームが毎週行っている仕事を1つ選びます。会社で最も重要な仕事にしてはいけません。複雑なワークフローでもありません。エージェントが完璧にできたら素晴らしい、という類のものでもありません。
5時間か6時間を食っている仕事を選びます。明確なアウトプットがあります。2つか3つのツールをまたぎます。人間のレビュアーがいます。そしてそのワークフローを非常に明確に書き出します。自分たちがそれを理解していることを確認してください。
たとえば、毎週月曜の朝、先週分のカスタマーサポートチケットを読み、製品領域ごとに分類し、繰り返し発生している問題を重複排除し、高価値アカウントに関係するものにフラグを付け、リンク付きの要約をカスタマーサクセスのSlackチャンネルに投稿する、というものです。
または、新しい営業機会があるステージに入るたびに、アカウント調査を行い、最新のGong通話を要約し、CRMに次のステップがあるかを確認し、AEとマネージャーに案件ブリーフを投稿する、というものです。
あるいは、毎週金曜の午後に、その週の製品フィードバックをSlackとサポートから取得し、テーマごとに分類し、浮上している上位5つの問題を特定し、プロダクトリード向けのダイジェストを下書きする、というものです。
この1段落が重要です。
なぜなら、ワークフローを本当に単純に説明できないなら、エージェントはあなたを救ってくれないからです。おそらくあなたは、チームとしてまだ解決していない曖昧さをエージェントに解かせようとしているのです。
その1段落ができたら、ビルダーを開き、ChatGPTに足場を下書きさせます。エージェントに必要なツールだけを接続します。
指示を整えるために1時間使います。プレビューします。そして仕事がすでに行われているSlackチャンネルに出荷します。
1週間動かしてみます。
その週の終わりに、曖昧に、それは印象的だったか、と聞いてはいけません。代わりに次の質問をしてください。
以前のワークフローに比べて時間を節約できたか。レビュー負担は、節約された時間を下回っていたか。1回か2回の反復後にアウトプットが十分に改善し、オフにしたらチームが惜しむようになったか。
これは良い評価です。
答えがイエスなら、本物のエージェントができたということです。おめでとうございます。次のものを作りましょう。
答えがノーなら、安く学べたということです。ワークフローが曖昧だったのかもしれません。コネクターが間違っていたのかもしれません。アウトプットの評価基準が明確ではなかったのかもしれません。
それでもすべて有用な情報です。
重要な習慣は、エージェントの仕事を実際の仕事と照らして測定することです。
これが、AI関連のものから複利的な価値を得ているチームと、数週間後に使うのをやめて苛立つチームとの違いです。
正直なところ、最初のドラフトは60%くらいまでしか到達しないかもしれません。それで構いません。
問題は、あなたが作る2回目、3回目のドラフトが、より大きな業務リズムへ向かって進ませてくれるかどうかです。
5月6日に無料期間が終わることを忘れないでください。利用できるうちに活用しましょう。トークン単位の価格設定がオンになる前に、自分たちが何に取り組んでいるのかを把握してください。
そして、チームのためにプロセスを構築しているなら、そのプロセスがチームの負荷を意図的に持ち上げるように作られていることを確認してください。
AI導入における最大の障壁の1つは、リーダーや経営陣が、新しいAIエージェント型ワークフローによって物事が簡単になると約束したにもかかわらず、チームが実際に試してみると、むしろ重くなっていると気づくときです。
やることが増えます。その結果、ストレスも増えます。
ですから、このプロセスを進める中では、チームの負荷を軽くすることに徹底的に集中してください。
そうすれば、はるかに高い熱意と、エージェントを導入しようとするはるかに高い意欲が得られます。
最後にそれをお伝えして終わります。幸運を祈ります。
コメント