“ゴミを入れ、宝を出す”：Anthropicのチーフデザイナーが語るCoworkのプロダクト哲学と10日でのローンチの真実

整理 & コンパイル：深潮TechFlow

ゲスト：Jenny Wen、Cowork デザイン責任者

司会：Peter Yang

ポッドキャストの出どころ：Peter Yang

原題：Claude Cowork Tutorial from Cowork s Design Lead (40 Min) | Jenny Wen

放送日：2026年3月29日

要点まとめ

Jenny は Cowork のデザイン責任者です。彼女は私に、Anthropic の内部の仕組みを深く教えてくれました。具体的には、彼女が Cowork のデザインと開発をどのように使ってプロダクトを進めているのか、そして Cowork が生まれるまでの裏にある本当の物語についてです。Anthropic はほぼ毎日新機能を出していて、彼らの働き方を見ると本当に強く衝撃を受けました。

見どころの要約

日常の働き方について

私が時間をかけていることの大半は、プロダクトを世に出すことです。ただ、一、二年前に見えていたものとはかなり違ってきていると思います。その大部分は実は、エンジニアやプロダクト担当の人たちと、あまり正式ではない形で jam（即興コラボ）することです。通常は、みんなで1つのプロトタイプを見て、そこに指摘を入れ、そしてそれがどう進化し得るかを考えます。

「ゴミは入って、宝は出てくる」という使い方の哲学について

Cowork で私が最も驚かされたのは、情報整理の力です。私はそれを「ゴミは入って、宝は出てくる」と呼ぶのが好きです。Cowork はさまざまな異なる情報源から情報を集め、その中からすぐに重要ポイントを見つけ、価値のある内容を抽出し、それを実際の生産力につながる成果へと変換できます。

Cowork と Claude Code の違いについて

非常に細かい本番コードの作業（production code）以外は、ほぼすべてのことを今は Cowork でやっています。特定のコードの細部に集中する必要がある場面では、私はまだ Claude Code を使います。でも、日常のコミュニケーションや協業については、今は完全に Cowork に依存しています。

Cowork の誕生ストーリーについて

「彼らは10日で作った」という話は、実はどこかのインタビューやメディア記事から切り取られたものです。でも本当のところは、Cowork という方向性について、私たちは私が1年前に Anthropic に入った時点から構想を始めていて、ずっと「すべての汎用的な知識労働者を助ける“思考パートナー” (thinking partner) をどう作るか」を考えていました。

Claude Code はすでにコード関連のタスクをとても上手に処理できますが、私たちの目標は、あらゆる知識労働のシーンをカバーすることでした。本当の挑戦は次のような点だと思います。つまり、このアイデアをどう実行するのか？ どんなアーキテクチャが最も適しているのか？ どんなユーザー体験 (UX) が正しいのか？

デザインプロセスの進化について

私は Figma は引き続き使います。ただ、いま私たちは仕様書をそれほど頻繁に作らないし、通常そこまで細かくもしません。優先順位付けは今でもやります。それはドキュメントとして存在していますが、たいていは箇条書き（bullet points）程度で、過度に設計されたきれいな表のようなものではありません。

計画とビジョンについて

私たちがいる技術領域は変化が非常に速く、新しいモデルが次々に登場して、更新のスピードもますます速くなっています。だから、私たちにとって1年分のビジョンを立てること自体があまり現実的ではありませんし、2〜5年先のビジョンなんてなおさらです。未知の要素が多すぎるからです。

デザイナーの未来について

もし足元の地面が動いているように感じるなら、それは本当に変化しているからです。私たちはそれを認めて、適応する必要があります。そして、オープンな心で、今の働き方を改めて見直さなければなりません。

キャリアが挑戦されていると感じるたびに、私はエンジニアの同僚たちのことを思い出します。彼らの仕事はすでに大きな変革を経験していますが、彼らはそれらの変化に適応しただけでなく、大きな勇気と謙虚さをもって挑戦を受け止め、最終的により効率的で、より優れた仕事の成果を実現しました。彼らは私のインスピレーション源です——「私がとても尊敬している同僚たちができるなら、私にもきっとできる」と自分に言い聞かせます。彼らは変化に適応するためのお手本です。

オープニング

Peter Yang：みなさん、こんにちは。今日はとてもワクワクしながら、Anthropic のデザイン責任者 Jenny をお迎えできて嬉しいです。Jenny は、Claude Cowork と Claude Code を使って、彼女がどのようにプロダクトをデザインしリリースしているのかを紹介してくれます。さらに Cowork の内部ストーリーも共有してくれるでしょうし、もしかしたらプロダクトの次の展開について少し話してくれるかもしれません。

Jenny、あなたの仕事の典型的な1日ってどんな感じ？ どんなタスクが時間の大半を占めるの？

Jenny：

「典型的な典型的な1日」があるかどうかはわからないのですが、私が時間をかけていることの大半は、プロダクトを世に出すことです。ただ、これが一、二年前に見えていたものと同じではないのは確かです。その大部分は実は、エンジニアやプロダクト担当のような人たちと、あまり正式ではない形で jam（即興コラボ）することです。たいていはみんなでプロトタイプを見て、それをどう進化させ得るかを指摘し、考えます。時には機能の振る舞いについて議論するだけの場合もありますし、私自身が何かを実装することもあります。デザインやプロトタイプ作りに費やす時間は、まだかなり大きいと思います。ただ、今はデザインの進め方が以前よりもかなりゆるくなっている感じです。

Peter Yang：つまりあなたは Claude みたいなものを使ってたくさんのプロトタイプを生成して、それからエンジニアと一緒に jam して、フィードバックを渡して、プロンプトで AI に改良させる——そういう流れで合ってる？

Jenny：

実際には、それらはプロトタイプというより、もう私たちの社内で、Claude や Cowork のインスタンス上で動いている作業プロトタイプであることが多いです。私は通常、その機能を使って、プッシュして、その能力を見て意見を形成します。次の反復はたいてい、私が椅子に座ってエンジニアにこう言うところから始まります——「ねえ、私はこう考えてる。ここはこう変えたほうがいいと思う」と。なので、デザインツールの中で反復して磨き込むことの重要性が、消えたわけではありません。単に、同時に扱うプロジェクトが増えたので、より効果的に感じるやり方として、かなりラフで、かなり非公式にやっているということです。

Peter Yang：それは、プロダクトマネージャーやデザイナーとして私がいちばん楽しいと思う部分だと思います。デザイナーとエンジニアを一緒にして、プロダクトが一緒に反復されていくのを見る。つまり、いまはその手の仕様書や Figma ファイルみたいな計画ドキュメントはあまりやってない？ それとも、コードの中でそのままプロトタイプを反復していく？

Jenny：

私は Figma は今でもやります。でも今は、仕様書をあまり作らなくなっていて、しかも通常はそれほど細かくもありません。はい。優先順位付けは引き続き行っています。それはドキュメントとして存在していますが、実際は私たちが安全や法務チームに渡すのに役立ちます。彼らがリリース内容が何かを理解できるようにするためです。ただ、通常は箇条書きが少しある程度で、過度にデザインされたきれいな表のようなものではありません。私たちの Figma ファイルも同じだと思います。

Cowork 実践デモ

Peter Yang：これらの製品を実際にどう使っているのか、またそれぞれの製品で何をしているのか、見せてもらえる？

Jenny：

もちろんできます。では、私が Cowork をどう使っているかを説明します。実は小さな秘密があって、非常に細かい本番コードの作業（production code）以外は、今ほぼすべてのことを Cowork でやっています。特定のコードの細部に集中する必要がある場面では、私はまだ Claude Code を使います。でも、日常のコミュニケーションや協業では、今は完全に Cowork に依存しています。

私が Cowork で最も驚かされたのは、情報整理の能力です。私はそれを「ゴミは入って、宝は出てくる」と呼ぶのが好きです。Cowork はさまざまな異なる情報源から情報を集め、その中からすぐに重要ポイントを見つけ、価値のある内容を抽出し、それを実際の生産力につながる成果へと変換できます。

たとえば今、私はあるフォルダーを接続しています。そこにはユーザーのインタビュー記録がいくつか入っています。私たち Cowork チームはユーザーとの密なつながりをとても重視していて、これも私たちが一定の成功を収めている理由のひとつです。私たちは従来型のユーザー体験調査 (UXR) を通じてユーザーと直接対話します。同時に、社内で自分たちが使う用途として、たとえばフィードバックを集めるための専用 Slack チャンネルがあるように、そうした形でもやっています。さらに、ソーシャルメディア上での議論にも注目し、熱心なユーザーの意見に耳を傾けます。ユーザーとの密なつながりを保ち、プロダクトを素早く反復できているからこそ、私たちは絶えず改善して、今日の成果を得られているのだと思います。

だから今、私がやろうとしているのは、Claude にこう伝えることです——「ねえ、このインタビューのフォルダーがある」。そして同時に、Claude にソーシャルメディア、Reddit、その他の Cowork の顧客評価も見に行かせて、「最大の洞察（インサイト）は何？」を教えてもらいます。これには少し時間がかかるかもしれません。というのも、本当にこれだけのデータを処理して加工する必要があるからです。でも、いくつかのことはやってくれます。たとえば、子エージェントを並列に走らせることがあるし、ネット上を検索する時間も使います。

Peter Yang：あなたの実際の仕事の中で、週次インサイトレポートみたいなものってある？ つまり、すべてを自動で集約して、それをあなたやチームに送るような仕組み？

Jenny：

実際には、今すぐ Cowork で直接作れます。研究者が出す分があって、さらに Slack の中で私たちのバージョンを ping してくれるものもあります。私たちは社内の Slack チャンネルを直接聞いています。私たちは社内と、最強のユーザーから前線のフィードバックをもらうことにとても依存しています。社内の人たちは本当に正直で、機能を限界まで押し出してくることが多いし、また最も追いやすいからです。

Peter Yang：それはまさに起きているべきことで、たぶんほとんどの会社ではチーム同士が分断されすぎていると感じます。でも Anthropic は全然そうじゃないように見える。

Jenny：

それは Claude Code の成功の重要な部分でもあると思います——最前線のユーザーの声を聞くことです。それに、Figma のときも私たちは大量にやっていますし、大量に internal dogfooding もしています。特にインタラクションデザインを磨くような領域では、社内の人が細部を突いてくれるんです。一方で外部ユーザーがくれるフィードバックは、たいてい「それは自分たちのユーザーフローに合うかどうか」みたいな形で、提供されるフィードバックのレベルがまったく違います。

Cowork vs Claude Code のユーザー領域の切り分け

Peter Yang：Anthropic のマーケティングやプロダクトマネージャーは、今は基本的に Claude Code を使っていると分かってる。特に Cowork 内で利用できるようになってから。あなたは、どんなタイプの利用シーンの違いをどう見ている？ それとも、みんなは Cowork と Claude Code をどう使い分けているの？

Jenny：

私たちは、Cowork の全体的な適用範囲が徐々に広がっていて、以前 Claude Code が試していたような“最前線のユーザー”が挑戦していた場面にも使われ始めているのを見てきました。Cowork を最初に開発し始めたとき、社内営業チームが主な情報源でした。彼らの中には Claude Code のヘビーユーザーが何人かいて、それを使って見込み顧客リストを生成したり、電話スクリプトを書いたりしていました。そうしたユースケースを初めて見たときはとても驚きました。なぜなら、その時点で私は「Claude Code がそういうタスクに使える」なんて考えていなかったからです。でも今、そのようなユーザーはほぼ全面的に Cowork に移行していて、さらに彼らの同僚まで Cowork を頻繁に使い始めています。

やはり、見栄えのする UI があるからだと思います。そしてもう1つは、それが彼らの他の仕事と非常に近い位置にあることです。彼らは元々チャット機能を使っていますし、このデスクトップアプリからも引き続き Claude Code を使えます。だから、コマンドラインを開くよりも、彼らの既存のワークフローにずっとフィットしているんだと思います。

洞察から実行可能な Artifact までの全プロセス

Jenny：

ここには7つの異なるテーマがあって、しかも毎週変わります。私は基本的にそれにそのまま言えます——「このドキュメント X を作って」そして「すでに私のPC上のフォルダーに自動的に置いといて」みたいに。さらに、同時に2つの並列タスクも起動できます。たとえば、「これらの洞察はすごくいい。でも、これに基づいて実際にどんなプロダクト機能を構築すべき？」と言えます。そしてもう1つ、並列で別のこともできます——さっき君が作ってくれた洞察のドキュメントをもとに、それらの内容を今週の kickoff のときにチームと共有できるデモ資料（プレゼン）に変換する、といった具合です。

最終的には、ここから私がデザインプロセスを始められます。つまり、さまざまな機能オプションを提示してくれるんです。そこからさらに、Claude にこれらの機能の wireframe（ワイヤーフレーム）を作ってもらうこともできます。たくさんの異なる選択肢を出してくれて、その中から私はそれを Figma に持っていって本当に細部まで詰めることもできますし、Claude Code に持っていって、私たちの実際のデザインシステムのコンポーネントを使って“本物のもの”にしてしまうこともできます。そしてそこからさらに進められます。

加えて、これら2つを定期タスクにすることもできます。たとえば毎週月曜の午前10時に自動実行するようにタスクを組めば、毎週月曜の午前10時には、そのデモ資料と、3〜4個の異なるプロダクト案を持って仕事を開始し、今週の kickoff を行えます。フィードバックから、形になる具体的なもの、あるいはチームが見られる idea へと至る反復サイクルが非常にタイトになるので、私たちは素早くプロダクトを反復し、そしてすぐにより良いものにできます。

Peter Yang：すべては反復について。すべては反復について。私も今は少し怠け者になっていて、AI にまず第一版を作らせて、私はその反応を返すだけにしてしまう。

Jenny：

ええ。だからもし本当に私に、ゼロからこれらの洞察を何らかの機能の優先順位にまとめさせたいなら、かかる時間は以前よりずっと長くなります。

私も同じやり方です。たとえばあなたが送ってくれたこのポッドキャストのメモでも、私は個人用のメモフォルダーを持っていて、そこには 1:1 ミーティングの内容や、思いついたいろんな考えが入っています。そこで私はこう言います——「私の個人メモを読んで、このポッドキャストで話すべきポイントを考えて。さらに、ここで私が話したいことを考えるのを手伝って」と。もちろん一言一句そのまま読み上げたりはしません。でもそれは、思考の扉を開けてくれて、思考を進化させてくれて、行き詰まらせないでくれます。

Skills と個人のナレッジベース

Peter Yang：どんな skills を使う？ あるいは、ドキュメントやスライド用に個人専用の skills がある？

Jenny：

社内には、ドキュメントやスライドを作るためのスキルがいくつかあります。ブランドの一貫性を保つのに役立つからです。私は個人用の skill ライブラリはあまりなく、大抵は社内にすでにある skill を借りてきて、用途ごとに使っています。

Peter Yang：たとえば、writing skill みたいなやつ？ AI に対して「AI の slop みたいな語彙は使うな」って言ってくれる、とか。

Jenny：

でも実は今、Cowork のフォルダーを使うことで（そこに私のすべての個人メモなどを入れているのですが）、それらのフォルダーから私のことを理解してくれるので、私にとってはすでにとても有用です。私はむしろ、memory や skills の必要性がだんだん減ってきていると感じています。すでに私についてのナレッジベースが用意されているからです。もちろん skills には適用される場面があると思いますが、私の現状のユースケースに限って言えば、個人的にはその必要性がそこまで大きくないです。

Peter Yang：毎日、あなたの会話に基づいて自動で記憶を更新してくれるから？

Jenny：

はい。基本的に、それは私が自分で維持している memory です。私はずっとその中にメモを取っています。

チーム協業のノード

Peter Yang：じゃあ、全プロセスの中でいつチームを引き込みますか？ それとも、あなたと AI が反復して、またチームとも反復して行ったり来たりするの？ それともどうやってる？

Jenny：

私の意図としては、実際の UXR インタビューみたいなものは、私がひとりでやるわけではないということです。担当するのは、プロダクトマネージャーだったり、チームの研究者だったり、チーム内の別の人だったりします。そしてそれを通して、artifact を直接共有し、彼らを引き込むことで、それが実際にチームの運用の根拠にもなります。

少なくとも私たちのチームはかなり bottom-up で、かなり民主的です。つまり、私たちは洞察と目標をみんなに渡し、それから各自がプロトタイプを作って試します。アイデアはあらゆる方向から集まってきます。デザイナーとして私がすべての案を考え出すというより、「ねえ、ここに洞察がある。今月達成しようとしている目標がこれ。この目標をみんなでどうやって達成する？」という形です。

これがあることで、私たちはそれでも Claude にすべてを任せるわけではありません。私たちは自分たちで判断する部分が多く、そして本当に構築するもの／やるべきことを管理・決定する能力に依存しています。

Peter Yang：ネット上で品味や判断力の話をしていると、そういった能力の育て方は結局、社内外から継続的に大量のプロダクトフィードバックを取り入れることで鍛えられるんだと思います。そうしていくうちに、どこがおかしくて、どこを直す必要があるかを察知できる直感が育っていく。毎日フィードバックを聞いて処理しているから、だんだんと問題に対する鋭い判断力が身についていくんです。

Jenny：

デザインに関しては、Claude の機能としてワイヤーフレームのようなスケッチを生成して、多様なデザインオプションを出せることがあります。デザイナーとして私はこのやり方がとても好きです。たとえそのスケッチの精細度が高くなくても、それらは私が直感的に異なる可能性を見られるようにしてくれて、自分の想像力に完全に頼らなくて済むからです。このやり方は、次にどのデザイン方向へ進むべきかを、より早く決めるのに役立ちます。

だから私は、Claude に最初の選択肢を直接生成させることで、手作業でスケッチを作る時間と労力を省けると思っています。そこから私はその中で方向性を1つ選び、小さな範囲で反復を始めます。次に、私はコードでその方向性を使って初期のプロトタイプを作り、それをベースにデザインをさらに最適化し、仕上げていくかもしれません。

Cowork 誕生の本当のストーリー

Peter Yang：じゃあ Cowork はどうやって生まれたのか、話しましょう。外では「10日で作った」みたいな話がたくさんありますが、実際にはその前にすでに多くの反復があったんですよね？

Jenny：

「彼らは10日で作った」という言い方は、実はどこかのインタビューやメディア記事から切り取られたものです。それでみんながそこを中心に議論してきた。でも実際には、Cowork という方向性については、私が1年前に Anthropic に入った時点で、すでに構想が始まっていました。私たちはずっと、「すべての汎用的な知識労働者を助ける“思考パートナー” (thinking partner) をどう作るか」を考えていました。たとえ Claude Code がコード関連タスクをうまく扱えるとしても、私たちの目的はあらゆる知識労働のシーンをカバーすることでした。だから本当の挑戦は「どうやってそれを実行するか？」「どんなアーキテクチャが最適なのか？」「どんなユーザー体験 (UX) が正しいのか？」だったと思います。

過去1年の間に私たちはたくさんの異なるプロトタイプを試しました。その中には、今の目標よりもさらに壮大なアイデアもありました。また、さまざまな AI エージェントのフレームワークをテストする技術実験もたくさん行いましたが、その中には成功しなかった試みもありました。最終的に、私たちは少しずつ今の方向性に定めていきました。ラボのチームが開発したプロトタイプだけでなく、私たち自身のプロダクトチームが作ったプロトタイプも調査しました。最終的に、タイミングと実行力が鍵になったんです——稲妻がちょうど的に当たったように。

このプロダクトをリリースすることに決めたとき、全体のプロセスはとても速かったです。つまり、「リリースしよう」と決めてから「プロダクトがローンチされた」まで10日しかかかっていません。主な理由は、Claude Code の休暇期間中にその可能性を見たからです。休暇中は多くの人がようやく Claude Code を試せる時間ができ、さらに一部の非技術ユーザーも使い始めました。たとえば、ポッドキャストの文字起こしを解析したり、複雑なデータ分析をしたり。私たちは、Claude Code のエージェントフレームワークが非技術ユーザーにもおいて、早期のプロダクト・マーケット・フィットを見せ始めていることに気づきました。実は、その時点で社内には動くプロトタイプがすでにあって、当初はもう少し後でリリースする予定でした。でも、そうしたフィードバックによって「今が最適なタイミングだ」と私たちは理解したんです。そこで、その機会をつかんで、最終的にあの狂気じみた10日が生まれました。

Peter Yang：もし私の理解が合っているなら、去年の1年間、社内の Slack でたくさんのプロトタイプを共有して大量のフィードバックを集め、それで実現可能なプロトタイプを確定して。で、市場がそれに求めているのを見て、あなたたちはスプリントで一気に仕上げてプロダクトを出した、という流れだ。

Jenny：

ええ、だいたいそんな感じです。私たちは本来、もう数週間後に出す計画でした。でも当時は「今が最適なタイミングだ」と感じていました。その結果、時間がタイトな状況でプロダクトのスコープをより現実的で実行可能な範囲に絞り込み、全精力とリソースをそこに投入して、最終的にリリースを成功させられたんです。

初期のデザイン反復：workflow ツールから極小の Chat へ

Peter Yang：初期の反復について、経験を共有したり、今開発中のものを見せたりできますか？

Jenny：

もちろんできます。私は初期の画面スクリーンショットをいくつか特別に整理してきました。当時のデザインの考え方や、反復のプロセスをお見せできると思います。

今年の早い時期に、私ともう一人のデザイナーで協力して作った初期プロトタイプがありました。当時は、このツールをタスク指向 (task-oriented) あるいはワークフロー指向 (workflow-oriented) に寄せようとしました。というのも、ユーザーが Cowork のようなプロダクトを使って、特定のタスクを理解して完了できるのか、あるいは明確な成果 (outcome) を出せるのかを、私たちはとても心配していたからです。例えばダッシュボード (dashboard) を作るとか、複数の情報源からのデータを統合するとか。だから当時は、ユーザーインターフェースを非常に構造化して、ほぼワークフローのツールのように設計していました。たとえば「この内容を追加する、これが入力（inputs）、これが出力（outputs）」みたいに。そしてチャット機能は二次的な位置づけでした。

でも、たくさんのステップを踏まないといけないように感じられてしまう。2025年の今の時代に、なぜこんなに複雑にするの？ そのまま Claude にやらせればいいのでは？

これが初期にとったデザインの方向性でしたが、後に私たちは考え方を変えて、もっとシンプルにして、チャットボックス (chat box) みたいにしようと決めました。この方法なら、ユーザーがより具体的な目標、たとえば分析やドキュメント生成などを達成するよう導けるのではないかと試しました。また、機能的なプロトタイプも作りました。ユーザーがクリックすると、さまざまな選択肢が見えて、それぞれにボタンがあって調整できる——たとえばドキュメントの長さや、メモやプレゼン資料のようにドキュメントの種類を選べる、というような設計です。でも、このデザインは最終的に、ユーザーにとって複雑すぎて、圧迫感が強すぎると感じられました。

だから、何度も探索して試す中で、私たちはバランスを探し続けました。つまり、「利用シーンをもっと明確に定義すべきか、それともチャットボックスのように自由形式のままでいるべきか」。

最終的に、数週間前にリリースしたバージョンが今の形です。私たちは「ウィザードモード」 (wizard-like) のようなユーザー体験も試しました。ユーザーがクリックすると、「ドキュメントを作成する、長さは3〜5ページ」みたいな提示が出る、といった感じです。

当時は、画面にたくさんの要素を入れて、普通のチャットボックスとは違うように見せようとしていました。でも後になって、それだと画面が複雑になりすぎて、視覚要素同士の競争が激しくなると分かりました。そこで私たちは、不要な要素の大部分を削ってデザインを簡素化することにしました。

今あなたが見ているユーザーインターフェースは、かなり簡素化されています。重いサイドバー (sidebars) を取り除いて、従来のチャットボックスにより近づけました。そのうえで、トップページではいくつか変更を入れて、複雑な提案やガイダンスが多いチャットツールというより、私と Claude が一緒に共有している「To-do list（やることリスト）」のように見えるようにしています。

Peter Yang：もしかすると将来的には、複数のエージェント（agent）をサポートして、それを上でドラッグしてワークフローを管理できるようになるかもしれない。

Jenny：

将来的にそういう可能性はあるかもしれません。でも強調したいのは、UI デザインは約4〜5週間前まったく違うものでした。私たちはずっと学びながら、どんなデザインが一番効果的で、どんなデザインがうまく機能しないのかを探り続けています。そして、この技術をユーザーにどう見せるのが最善かを模索していました。

Cowork と Claude Code の差別化の位置づけ

Peter Yang：Claude Code を使っている過程で、私は頻繁に Twitter 上でフィードバックをシェアしています。それにはたくさんのスラッシュコマンド (slash commands) が内蔵されていて、ユーザーは少しずつ学ぶ必要があります。体験としては、Costco に買い物に行ったときの「宝探し」 (treasure hunt) みたいで、どんな新機能に出会えるのか分からない。

でも初心者にとっては、そのやり方はフレンドリーではない。むしろゲームっぽい。使っていくうちに、だんだん慣れて、理解できてくる。私の感覚では、Cowork は普通のチャットツールと Claude Code の間の“中間地帯”を探ろうとしているのかもしれない。すべての機能を隠してしまうのではなく、でもある形でユーザーがよりよく使えるよう導く。

Jenny：

そうです。Cowork でもスラッシュコマンド (slash commands) は使えますが、それは主要なインタラクション手段ではありません。私個人としては、Cowork は少なくともプロ向けのツールだと思っています。私たちは、かなり多くのユーザーが非常に上級者のような使い方をしていることに気づきましたし、コミュニティにも上級ユーザーがすでに出てきています。そうしたユーザーは、より複雑な機能を学ぶために時間をかけることに抵抗がないことが多いです。たとえば、自分で skills を作ったり、チームと共有したり、略式のコマンド (shorthand commands) を使ったり。

ただ、私たちの目標は、それらを“次のインタラクション手段”にして、強制的に学ばせる内容ではないようにすることです。つまり、ユーザーがすべてのコマンドを理解していなくても、簡単に Cowork を使えるようにしたい。Claude とのやり取りが自然で直感的であることが重要で、コマンドの列を覚えないと操作できないようにはしたくない、ということです。

計画プロセスとビジョン

Peter Yang：Anthropic の計画プロセスはどんな感じ？ 年次の計画や目標設定はするの？ それとも、プロトタイプ開発と絶え間ない試行により多く依存している？

Jenny：

私たちの計画のやり方は、毎回少しずつ違います。私がいるチームでは、月次プランを行っています。私たちは電子スプレッドシートを持っていて、少なくとも Cowork の部分に関しては、最大でだいたい12個のタスクまで——それらが最優先（P0）です。各タスクには DRＩ（Direct Responsible Individual）となる担当者がいて、毎週チェックします——「私たちはまだ正しい軌道にいるか？」それから四半期や半年の計画も行います。通常はリーダーがこう言います。「この方向に進むべきだと思う。これらは注力すべき事項だ」と。ただし、この計画は特定のプロジェクトを必ずやり切るという厳密なものではありません。もっとチーム全体に向けた“全体の方向性”を示すもので、なので比較的柔軟です。

Peter Yang：柔軟、ということですね？ 面白いことに、私が見てきた中で最も革新している会社は、年次の計画をあまりやらず、反復しながらユーザーから学び続ける方が多いです。あなたのキャリアの中で、North Star のビジョンデッキみたいなものを作ったことはある？ それは役に立つと思う？

Jenny：

実際に作ったことがあります。去年、私は North Star のビジョンデッキを作りました。ビジョンには価値があると思います。それはチームに方向性を与え、これから始める仕事に対して明確さを保つのに役立ちます。とはいえ、私たちがいる技術領域は変化が非常に速く、新しいモデルが次々に登場して、更新スピードもどんどん速くなっています。だから私たちにとっては1年分のビジョンすら現実的ではなく、まして2〜5年分のビジョンなんて無理です。未知の要素が多すぎるからです。

ただ、ビジョンが本当に果たす役割は、みんなを同じ方向へ導くことです。特に、みんなが自由にさまざまなプロジェクトを組み立てられる環境では。なので私は、ビジョンの時間軸はせいぜい3〜6ヶ月くらいがいいと思っていて、ドキュメントとして提示できる形が望ましいです。ビジョンが視覚化されていると、よりインパクトがあると思います。これがデザインの大きな価値でもあります——さまざまな要素を統合して、特定の期間における一つのまとまったストーリーとして語れること。もちろんビジョンは、静的なデッキだけでなく、プロトタイプでもあり得ます。これはチーム間の仕事を調整するのに役立ちます。特に、5つのチームがすごく似た、あるいは衝突しうるプロジェクトを扱っている場合です。デザインは、キュレーションを通じてこれらの考えを一致させる助けになり、バラバラになった体験ではなく、理想的なユーザー体験へ向かう道筋を示せるようにしてくれます。

Peter Yang：では、プロダクトマネージャーのレビューはある？ あるいは関連する人たちへのレビュー？ それは正式なもの？ それとも彼らもプロトタイプ作りに参加していく？

Jenny：

レビューは確かにあります。ただ、私が以前いくつかの会社で見ていたように、「各機能ごとに必ずレビューが必要」みたいな形ではありません。私たちのレビューは、規模が大きくて、優先度の高いプロジェクトに主に向けています。レビューの目的は、準備に大量の時間を費やすためではなく、プロジェクトの可視性を上げてフィードバックを得ることです。もしチームをまたぐ形で、会社に影響する重要なプロジェクトがあるなら、そういうレビューを行います。

デザイナーへのアドバイス：AI の時代に居場所を見つける方法

Peter Yang：それでは、自分の職場環境が急速に変わっていると感じるデザイナーに向けて、何かアドバイスはある？ 彼らはコードの提出（PR）を学ぶべき？ それともデザイナーは別の方法で適応すべき？

Jenny：

足元の地面が動いているように感じるなら、それは本当に変化しているからです。私たちはそれを認めて、適応する必要があります。そして、オープンな心で、今の働き方をあらためて見直さなければなりません。今の変化はデザイナーに特に大きな影響を与えていると思います。なぜなら私たちはこの波の第二波の真っ最中だからです。他の職種の人たちも同様の転換を経験していて、いまは私たちの番なんです。同時に、私たちのデザインツールもどんどん進化しています。

私のキャリアが挑戦されていると感じるたびに、私は少し不安も感じます。たとえば「やばい、仕事がものすごく変わってきて、人々が以前と同じように私の仕事を評価しなくなるかもしれない」みたいに。でもそんなとき、私はエンジニアの同僚たちを思い出します。彼らはすでに大きな変革を経験しています。でも彼らはそれに適応しただけでなく、ものすごい勇気と謙虚さで挑戦を受け入れ、最終的により効率的で、より優れた仕事の成果を実現しました。彼らは私のインスピレーション源です——「私がすごく尊敬しているあの同僚たちができるなら、私にもきっとできる」と自分に言い聞かせます。彼らは変化に適応するためのロールモデルです。

Peter Yang：ある意味で、これらの変化はデザイナーからかなりの手作業の面倒な繰り返しを取り除いてくれている、ということですよね。いろんな枠組みを調整するために時間を使わなくてもよくなって、より上位の思考や創造的な仕事に集中できる、と。

Jenny：

そうですね。あるいは言い換えると、これらの変化によってより多くの仕事ができるようになった。たとえば、私のエンジニアの同僚たちが今は、たった数日で一つの完全な機能を作れてしまうのを見ると、以前はおそらく数週間かかっていたはずだと思うので、本当に衝撃を受けます。なので、はい、この変化は可能性も増やしてくれました。