AnthropicのFelix Riesebergが、AIを単なるチャット相手ではなく実際に仕事を実行する同僚としてどう位置づけているかを語る内容である。Claude Co-workの設計思想、ローカルコンピュータを重視する理由、skillsによる個人最適化、知的労働や初級職への影響、そして今後のAIエージェントが人間の働き方をどう変えていくのかまで、多面的に掘り下げている。
- AI同僚とローカルファーストの未来
- ユーザーフレンドリーなのに、むしろ上位版である理由
- なぜローカルコンピュータに価値を置くのか
- すべて作って試すという開発観
- MCPよりskills、そしてMarkdownの強さ
- なぜ何でもクラウド化しないのか
- planning UIは何を変えたのか
- evalとは何か
- 実際のco-work活用例とskills
- ask user questionと細かいUIの価値
- ブラウザ統合と既存ワークフローへの接続
- skillsの可搬性と個人化
- skillsはファイルなのか、共有知識なのか
- どの産業が消えるのか、そして若手雇用への影響
- 若手はAIネイティブになれるのか
- デスクトップ整理から税務まで、知的労働全般へ
- Claudeがあなたのコンピュータを使うとはどういうことか
- Windows 95から見る、仮想化とUIの発想
- VMとサンドボックス、そして安全性の設計
- co-workの未来
- 汎用性を守るということ
- ElectronとChromiumの意味
- マルチプレイヤーco-workの可能性
- Anthropic Labsは何をしているのか
AI同僚とローカルファーストの未来
これは、AIに関して多くの人とは少し違う見方かもしれません。私は、未来が極端にパーソナライズされたソフトウェアになって、全員がそれぞれ自分専用のバージョンを動かすようになるとは実は思っていません。むしろ、私たち一人ひとりが自分専用の内部チャットツールのようなものを持つのは、かなり難しいと思っています。
シリコンバレー全体として、ローカルコンピュータの価値を過小評価していると私は思っています。私がいつもする基本的な反論は、とても単純です。なぜ私たちはみんなMacBookを使っていて、iPadやChromebookではないのでしょうか。
そして今、Claudeのことを、あなたにとって非常に役立つ存在、途方もなく役に立つ存在として考えるなら、その存在は、あなたが使えるのと同じツールすべてにアクセスできる必要があると私は思います。そうでないと、複雑な形であちこち制約を受けてしまうからです。
みなさんこんにちは。Len Spaceポッドキャストへようこそ。新しいスタジオでの最初の収録です。私はColonel Labsの創業者、Alessioです。そして、Latent Spaceの編集者、Swyxと一緒にお届けします。
はい、ここに来られて本当にうれしいです。TJ、Alessio、そしてEllenにも、すべての準備を手伝ってくれてありがとうと言いたいです。すごくきれいですね。
ロゴまで外にありますからね。
そうなんです。ゲストとしてここに入ってくると、これは本格的な制作現場だなとすぐに感じます。その空気があります。
Felix、今あなたはco-workのプロダクトマネージャーをしているんですよね。それとも、かなり技術寄りの役割でしたっけ。
そうですね、リードでもあります。
肩書きはやや曖昧なんですよ。Member of Technical Staffです。
わかります。Member of Technical Staffって、ずっと持ち歩くことになる公式タイトルみたいなものですよね。
最近、私たちはかなり夢中になっていて、私自身もかなり使っています。Latent Spaceの運営でも使っていて、co-workが動画のアップロードを手伝ってくれたり、タイトルを付けてくれたり、編集まで手伝ってくれたりします。本当にすごいんです。
うれしいです。彼、グループチャットで何回もco-workをAGIだと言っていましたよ。
そうそう。私たちにはLatent Space TV用の2つ目のチャンネルがあるんですが、基本的にはDiscordのミートアップなんです。それで、Claude co-workersはAGIかもしれない、みたいな話もしていて。もうアップしたかどうかはわからないですが、そのセッションのひとつがまさにco-workについてのものでした。
ぜひ見てみたいです。本当に気になります。私の仕事の中でもすごく楽しい部分のひとつが、人々がco-workをどんな変わった用途に使っているかを絶えず見ることなんです。もちろん、私たちとしては特定のユースケース向けに設計するのはすごく難しいんですが、それでも、実際に最も驚いてくれる人たちは、たいてい私がco-workに向いているとすら予想していなかったことに一番驚いているんです。
新しいデザイナーが入ってきたんですが、最初の小さな仕事のひとつとして、社内のスタック用にco-workの新しい絵文字が必要だという話になったんです。かなり小さな作業だったので、これお願いできると言いました。すると彼はSVGを描いて、それをそのままco-workerに渡して、この絵文字をアニメーション化できますかと聞いたんです。そうしたら今では、きれいにループするアニメーションになっています。
もちろん、これは結局のところ、コードで思っていた以上のことができるという話でもあるんですが、私にとって面白いのはまさにそういうことなんです。
要するに、あなたがどんな使い方をしているのか、ぜひ見てみたいです。
あとで見せます。開いてみますよ。でもその前に、まずは大枠から入りたいです。co-workを聞いたことがない人、まだ試したことがない人向けに、Claude Co-workとは何なのかを説明してもらえますか。
はい、手短に言うと、Claude Co-workはClaude Codeのユーザーフレンドリー版です。
基本的な仕組みとしては、私たちにはClaude Codeがあります。そして、それにはかなり印象的なエージェント用のハーネスがあります。12月ごろ、技術者ではない人たちもそれを使うケースがどんどん増えていることに気づいたんです。ターミナルに慣れていない人も使っていましたし、逆にターミナルには慣れているけれど、Claude Codeをコーディング以外の仕事に使い始めた人もいました。たとえば経費管理、領収書の整理、ナレッジベースの整理などです。Obsidianまわりで大きな盛り上がりがあって、多くの人がそれを気に入っていました。私たちはそこに乗りたかったんです。ただ同時に、この能力を、ターミナルネイティブではない人たち、brew installのやり方を知らないかもしれない人たちにも届けたかったんです。
そこでco-workは、仮想マシン上で動くClaude Codeになりました。そこに少しクッションを入れ、少し多めのガードレールを入れ、少し安全に、少し便利にしたものです。仕事を始めるときに、まずターミナルを開きたくない人のためのものですね。
ユーザーフレンドリーなのに、むしろ上位版である理由
面白いですね。よりユーザーフレンドリーなものとして打ち出されているのが。というのも、私にとっては、むしろよりパワーユーザー向けのツールに感じるんです。Claude Codeにはもともと馴染みがあって、1年前にもClaude Codeの回をやりました。でもこちらは、ClaudeやChrome、そのほかのツールとの統合がかなりうまくできていて、さらに強力に感じるんです。もしかすると、それは認識の問題なんでしょうか。
いや、正直それは間違っていないと思います。ここ2週間くらい、まさにそのことをずっと考えていました。
人って、ユーザーフレンドリーと聞くと、簡略化された版だと思いがちですよね。でも実際には、これは上位集合なんです。
似たようなことが、10年か12年前にMicrosoftにいたころにもありました。Electronやブラウザベースの技術、クロスプラットフォームの取り組みを始めた頃です。その最初のユースケースのひとつがVisual Studio Codeで、もともとはWebサイトだったんです。初期の語られ方としては、Visual Studio CodeはVisual Studioのよりユーザーフレンドリーな版だ、というものでした。
でも同じように、これは本気の開発者向けじゃないとか、こんなので真面目な開発はしないといった声もありました。
最終的にVisual Studio Codeがなぜあれほど大きな存在になったかについては、人によっていろいろな説明があります。でも私個人としては、ハックしやすさと拡張しやすさがかなり大きな役割を果たしたと思っています。Visual Studio Codeはほとんどどんなワークロードにもつなげられるし、いじるのも簡単、拡張機能を作るのも簡単です。
co-workにも同じことが起きているのかもしれません。拡張が非常にしやすく、自分のワークフローに持ち込みやすいんです。利便性はもちろん、開発者として私たちが目指していることではありますが、人々が本当に価値を見いだすのは、それを自分の実際の仕事にちゃんと対応づけられたときなんです。
去年の終わりに、Claude Codeで非技術系の利用が急増したわけですよね。そこから、Claude Code workを作ろうという設計プロセスはどういうものだったんですか。しかも10日で作ったわけですよね。その前段階として、何が使いやすさを意味するのかという議論は当然あったはずです。デスクトップGUIを作るというのもひとつの方向ですが、製品の中にはかなり細かなニュアンスがありますよね。どんなきっかけで別のものを作るべきだとなったのか、そして逆に、あえて採らなかった設計判断にはどんなものがあったのか、そのあたりを聞かせてください。
Anthropicでは、Claudeを質問に答える存在として使うことに慣れている人たちに、もっとこの力を使ってもらいたいとずっと考えてきました。つまり、ただ答えるのではなく、実際にタスクを実行し、問題を解き、物を作る存在としてです。
今のところ、多くの人はチャットの中で質問して答えを得るという枠組みに最も慣れています。その人たちに、この能力をどう届けるか。それについては、少なくとも1年半前くらいからいろいろなプロトタイプがありましたし、多くの人が取り組んでいました。
Anthropicの社内文化は、かなりプロトタイプとデモを先に作る文化です。世に出ない内部プロトタイプが本当にたくさんあります。co-workが最終的に何になったのかというと、そうした数多くのプロトタイプの中から、ちょうどよい部品を選び出して組み合わせたものなんです。
だから、よく言われる10日で作ったという数字についても、大事なのは、ゼロから始めたわけではないということです。すでにいろいろなものが動いていたんです。たとえばWebサイトを作るときに、Reactやほかのいろいろなものを使うのと同じです。今回も同じで、すでに持っていた部品がたくさんあったわけです。
意思決定の道筋という意味では、今は実行コストが本当に安い新しい世界に生きていると思います。
うなりますね。
本当にそうですよね。昔は、アイデアは安くて実行が難しいと言われていました。
でも以前は、プロダクトマネージャーが潜在顧客のところへ行き、かなり低帯域なやり方で、その人たちが何に困っているのか、何ならお金を払うのかを探っていたと思うんです。その上で、そのニーズに応えるために何を作るかを考え、仕様書を書き、設計を考え、そして作る、という流れでした。
でもAnthropicの社内では、今はむしろ、メモなんて書かずに全部作ろうという地点にかなり近づいています。候補になりそうなものは全部すばやく作ってみて、その中からいちばんよいものを選ぶんです。
なぜローカルコンピュータに価値を置くのか
製品にもユーザーにも、今いちばん大きな影響を与えている意思決定は、ローカルコンピュータにどれだけ価値を置くかだと思います。これが大きな判断ポイントです。多くの人が考えてきたことですが、この種のものは、最終的にあなたのコンピュータで動くべきなのか、それともクラウドで動くべきなのか。そこには大きなトレードオフがあります。
もしOpenAI的な問題が解決していれば、クラウドでやるのは簡単だったかもしれません。でも、私はどこからでも好きなファイルをダウンロードして、それをco-workにその場で渡せる。このこと自体が、大きな解放なんです。
今の話、既存の部品を再利用することにもつながっていますよね。これはClaude Codeについて考えていても感じることなんですが、コードを書くコストはゼロに近づいている、と皆が言う一方で、何らかのプラットフォーム基盤を持っていることの価値はむしろ高まっているように見えます。新しいものを作るとき、それらを組み合わせてはめ込めるからです。
だから、多くのソフトウェアの価値はゼロに近づくと人々が言うのを聞くと、私には逆に思えるんです。既存のプラットフォームがあって、その上に構築できることのほうが、むしろ以前より価値があるんじゃないかと。あと、MCPもあるし、skillsもあるし、もちろんモデル自体も大きな要素です。こうしたものが全部つながってくる。だから、こういうプリミティブにさらに投資すべきだと考えるのは妥当でしょうか。それとも、変化が速いから毎回かなり作り直しているのでしょうか。再利用するより書き直すほうが簡単、みたいな。
その見方は正しいと思います。包括的なプラットフォームは本当に有用です。そしてこれは、AI界隈の多くの人にとっては少し逆張りに聞こえるかもしれませんが、私は未来が極端にパーソナライズされたソフトウェアになるとは思っていません。全員が自分専用の版を動かす世界ですね。私は実際には、私たち全員が自分専用の内部チャットツールを持つのは、かなり難しいと思っています。だって、たとえば私があなたと話したいとき、それはどう機能するんでしょうか。
co-workとその作り方に関して言えば、少し組み合わせです。安くなったのは、必ずしもプリミティブそのものを毎回作り直すことではありません。しかも、そこには大きな価値もあまりないんです。たとえば、私のチームはClaude Codeを作り直そうとは考えませんでした。出発点の中核にあったのは、これはClaude Codeであるべきだという考えです。そして、その上にいろいろなものを作っていこう、と。
少し安くなった実行の部分とは、たくさんあるレゴの部品をどう組み合わせて、ユーザーにとって意味があって、本当に価値のある形にするか、というところなんです。
今は、何をプリミティブとして昇格させるべきかについても、いろいろなアプローチがありますよね。すべての製品はプリミティブを組み合わせて作るべきだと強く信じるのか、それとも一部は内部専用にしておくのか。
これはまだ進化中だと思いますが、ひとつ消えていきそうなのは、ちゃんと人に試さずに優れた製品を頭の中だけで考えようとすることです。これは新しい概念ではありませんが、以前だったら、技術Aを選ぶかBを選ぶか、この方法で作るか別の方法で作るかというような高コストな判断が必要でした。でも今の私は、本当に強く、全部作って小さなフォーカスグループで試せばいいと信じています。そして、よりよいものを採用すればいい。これは、たぶん1年前の私たちの働き方から見てもかなり違うと思います。実際、この変化は本当に最近起きたものだと思います。
すべて作って試すという開発観
私もちょうどElectronで何かを作り始めたんですよ。あなたがここにいるのは偶然ですが。ところがElectronとSQLiteの組み合わせで、開発時とビルド時の間にいろいろ問題があって、それで、もう全部Swiftで作り直そうとなって、本当に全部Swiftで作り直したんです。もう終わりました。大した労力もかからなかった。私はSwiftなんて知らないのに。
まさにそういうことです。しかも、結局レビューなんてしないわけでしょう。どんな言語で書こうが構わない。でも大事だったのは、Electronのバインディングを書くことじゃなかった。重要なのは、アプリ内でどんなロジックが動くかだったんですよね。モデルに対して、これと同じものを作り直してと言えば、それで同じものができてしまう。
そうですね。もちろん、ハイパフォーマンスなソフトウェアやとても複雑なソフトウェアを作る人にとっては、なおさらアーキテクチャの見通しは必要です。でも、それはMarkdownで十分なんです。コードをもう一度読み返す必要はありません。
まだ定義の話に戻りたいんですが、Claude Co-workについてよいメンタルモデルを作れますか。今の私の理解では、土台はClaude Codeで、そこには手を入れたくない。Claude appがあり、ClaudeとChromeがあり、計画の部分で何か違うことをしているのではないかと思っています。私はClaude CodeチームのTariqとも話したんですが、彼は計画を単に露出させているだけだと言っていました。co-workを構成する主要な部品について、どんなものがあるのか説明してもらえますか。
はい、だいたいその理解で合っています。planningの部分は、ほぼ外して考えて大丈夫です。co-workの中で本当に価値があるものはいくつかあります。
まず、仮想マシンがたぶん最も強力な要素です。私たちは現在、軽量なVMを動かし、その中にClaude Codeを入れています。そうしている理由はいくつかありますが、大きいのは安全性とセキュリティです。ただ、仮に安全性とセキュリティをいったん脇に置いて、いいから何でもやらせたいと考えたとしても、Claudeに専用のコンピュータを与えるのはかなり強力なんです。一般論として、それはよい考えです。
アーキテクチャやUX、そのほかAnthropicで取り組んできたこと全体について言うと、Claudeをかなり積極的に擬人化して考えるのが実は有用なことが多いんです。つまり、これは人間だと思ってみるんです。もし相手が人間ならどうするか、と。
今朝、父にも説明したんですが、彼はいまだにコーディングのことでもかなり頑なにチャットを使おうとするんです。私はこう言いました。もしあなたが開発者で、雇用主からコンピュータはいらない、コードはメールで送るから、あなたもメールでコードを返してくれと言われたらどう思うか。それは、もしかしたら昔のPEファイルの時代には成り立ったかもしれませんが、全然効率的ではないですよね。
VMで何ができるかというと、Linuxシステムなので、Claude Codeは必要なものをかなり自由にインストールできます。Pythonも入れられるし、Node.jsも入れられる。
もちろん、ネットワークの入出力には厳格な制御をかけています。なので、ユーザーとして普通の人間の言葉で、システム全体に対して、ここまでは許可する、ここから先は嫌だということをはっきり伝えられます。でもこのやり方だと、たとえばマーケティングの人や弁護士のような人に、Homebrewをインストールしていいですかと聞く必要がありません。
そうですね。
そうなんです。質問の意味も、答えの影響も、複雑でニュアンスがあるし、簡単に判断できるものではありません。そこを抽象化することで、Claudeをとても強力にできるんです。
そのうえで、その周囲には、今もほぼ毎週増え続けている、co-workを単体のClaude Codeより特定のタスクで優れたものにする要素がいくつかあります。でもその大半は、実はシステムプロンプトの中にあります。あなたがどんな仕事をしているのか、そこから何を推測できるか、その推測をシステムプロンプトにどう入れれば、より効果的になるか。そういう話なんです。
それに加えて、ClaudeとChromeの密接な統合もあります。モデルがよくなるにつれて、多くの人がMCPコネクタに関してはもうお手上げになっているんですよね。25個もMCPコネクタを通して、全部でクリックして、半分は結局何もできない。そんなことはしたくない、と。だからClaudeとChromeはかなり強力です。ClaudeとChromeエージェントに話しかけるだけで、いろいろやってくれるからです。
MCPよりskills、そしてMarkdownの強さ
たしかに。正直、MCPの現状って統合がかなり大変ですよね。私も、使っているコーディングエージェントにFigma MCPを入れる必要がありました。でも自分ではドキュメントを読みたくなかったので、Claudeにやらせました。ドキュメントを読むのが得意ですから。同じように、あるプロジェクトでGoogle Cloudのアカウントを設定して、APIキーを取ってくる必要があったんですが、Google Cloudって有名なくらい分かりづらいじゃないですか。だから全部やりたくなくて、Clockworkを使ったんです。
co-workを開発し始めて最初の週のうちに、私はかなり早い段階で、co-workをコーディングタスクにも使い始めている自分に気づきました。本来は、そこが主目的ではなかったのにです。別にそのために作ったわけじゃないんですけど。
社内で使っている、クラッシュやデバッグ情報を集める内部ツールがあるんですが、そこで、簡単に直せそうなものと、カーネル破損とかOS側の問題っぽいものを見分けて、これは修正できそう、これは無理そう、と選り分けている自分がいたんです。そして、そのうえでClaudeにこのバグを直してと言っていた。そこで、自分はいったい何をしているんだろうと思ったんです。ひとつ上のレベルに上がればいい。co-workerに対して、毎朝チェックしているこのクラッシュツール全部を見に行って、直せそうなバグとそうでないものを分けて、それから別のClaudeに直せと伝えてくれ、と言えばいいわけです。
それって、別のClaudeを立ち上げているんですか。
今私がやっているのは、少しハック的ですが、Claude Remoteを使って自分自身に対して実行させる方法です。
なるほど。つまり、20個のバグが並んだダッシュボードがあるとして、それをリモート制御するわけですね。
そうです。正確に言うと、私の使い方はこうです。co-workに対して、私が毎朝最新のバグを見つけるために普段行く場所を教えます。バグ一覧を全部読んで、直せるものと直せないものに分けてください。そして直せるものについては、ほぼfor each bugのような形で、各バグごとにプロンプトを書いたMarkdownファイルを作ってください。さらに、そのMarkdownファイルごとにClaudeのセッションを開始してください、と。
つまり、Claude Codeにはsubagentsという概念がもともとあって、これは実質それと同じことをしているけれど、そのsubagents機能を直接使っているわけではないんですね。
そうです。subagents機能は使っていません。その理由は、Claude Code Remoteタスクとして発火しているからです。
それはけっこういいですね。そうすると投げっぱなしにできる。次の会議に行っている間に、Claude Code Remoteの中で作業が進んでいるわけですね。
そうです。
なぜ何でもクラウド化しないのか
でも、こうして話を聞いていると、もうローカルマシンではなくクラウドを使い始めているようにも見えます。だったら全部クラウドファーストでいいんじゃないか、という話になりませんか。
ああ、この質問は本当にいいですね。たくさん考えがあるんです。
私は全体として、シリコンバレーはローカルコンピュータを過小評価していると考えています。さっきの私の基本的な反論はいつも同じです。なぜ私たちはみんなMacBookを使っていて、iPadやChromebookではないのか。つまり、ローカルマシンにはやはり価値があるんです。
そして今、Claudeを、あなたにとって本当に役立つ存在として考えると、その存在は、あなたが使えるのと同じツールすべてにアクセスできる必要があると思います。そうでないと、いろいろな複雑な形で身動きが取れなくなってしまう。
ここには2つのアプローチがあります。ひとつは、あなたのコンピュータ上にあるものをひとつずつ削り出して、クラウドへ移していく方法です。それもひとつのやり方ですし、ほかの製品の中にはその道を取っているものもあります。
でも個人的には、これはかなり個人的な意見ですが、私が使っているツールの数を考えると、別のツールに対して、ありとあらゆるものへの権限を与え続け、それを常に最新に保つようなことをする忍耐がありません。
もうひとつ、まだ答えが出ていないことがあります。誰かの仕事全体を吸い上げてクラウドに置くことは、いったいどういう意味なのか、ということです。たとえば、ボタンをひとつ押したら、あなたのコンピュータ全体をそのままクラウドに複製できるとします。あなたはそれを本当に望むでしょうか。私は、誰もが望むとはまだ全然確信していません。
そうですね。
しかも、これはこれから出てくる技術的な問題よりもさらに上流の話なんです。そもそも世界のほうが、こういうことにまだ準備ができていないと思うんです。ひとつ分かりやすい例を出します。デスクトップアプリとしてなら、理論上は、あなたの許可があればコンピュータ上でかなり多くのことができます。たとえばその気になれば、Chromeのクッキーを読むこともできます。
理論上はできるわけですね。
そうです。クッキーを読み出し、それを復号してもらえれば、クラウドに持っていくことだってできる。それはかなり簡単な解決策です。すごく便利そうにも見える。全部クラウドでやれますと言えるわけです。
でも、多くのWebサイト、銀行を含めて、同じ認証情報が2つの場所から見えたら、即座にアカウントをロックします。そうすると支店まで行って、パスポートを見せて、本人ですと言わなければいけなくなる。
どうしてそんなことまで知っているんですか。すごいですね。
エージェントという言葉はみんなもう飽きていると思いますが、エージェント的な未来のためには、ゆっくり追いついてこなければならないものがたくさんあります。今のところ、Claudeを最も効果的にする方法は、私のようにClaudeに取り組んでいる人間にとっては、あなたが働いている場所にClaudeを置くことなんです。
このメンタルモデルについて、ほかにありますか。つまり、仕組みを理解すればするほど、自分はもっと上手に使える気がしているんです。
今あなたの話を聞いていて思うのは、planningの話は消していいということですよね。Claude Co-workにしかない特別なことを、planningでやっているわけではない。
多少の工夫はありますが、それも週ごとに変わります。co-workは、Claude Codeとは違うユースケースで評価しています。そこが重要です。Claude Codeは、かなりコーディングタスク向けに最適化されていて、私たちは典型的なSWEの仕事をうまくこなせるかどうかで、改善したか悪化したかを見ています。
一方、Claude Co-workは、もっと典型的な知的労働で評価します。金融や法律事務所にあるような仕事ですね。私個人の使い方で言えば、自分のことの管理です。たとえば住宅ローンの管理とか、家族との旅行計画とか。そういうユースケースでco-workを評価しています。
あなたが感じ取っているのは、おそらくシステムプロンプトの微妙な変更でしょう。何をシステムプロンプトに入れるのか、どのツールをどう与えてClaudeをどう誘導するのか。そうした違いの中に、ある方向にはよくなるけれど、別の方向ではトレードオフが出るということがよくあります。Claude Codeはコードにより強く、Claude Co-workは非コーディング作業により強い。
ただ、その差が今後数世代のモデルでも残るのかは、私にも少し不明です。今やっているこうした細かな最適化が、どれくらい長く意味を持つのか、私にはよくわかりません。
planning UIは何を変えたのか
私が言いたかったのは、定性的な違いも感じたんです。たぶん全部プロンプティングで、私が深読みしすぎているだけかもしれませんが。たとえば、9ステップの計画を出してきて、それを私が編集できて、フィードバックできて、その計画の実行も見られる。その感じが、Claude Codeより長期志向に思えたんです。でも、もしかするとそれはもともとClaude Codeにもあって、よりよいUIを作っただけなのかもしれませんね。
両方ですね。planning機能を作ったClaude Codeチームの人たちがここに座っていたら、Claude Codeにもそれらは全部ありますよと言うでしょうし、実際あります。
ただ、人々はco-workに対して、より長い時間軸のタスクを与えがちです。
確かに長いです。
そこがひとつあります。仕事の塊が少し大きくなりがちなんです。それに、作業が長くなると曖昧さも増します。だから私たちはco-workに対して、planningツールやask user questionツールをかなり積極的に使うよう伝えています。ユーザーが本当に何を望んでいるのかを引き出してから動くように、と。4時間も勝手に働いて、違うものを持ち帰ってくるようなことは避けたいんです。
たぶん、あなたが感じているのはそこですね。
魔法の秘密のソースを私が作った、と言えたらよかったんですが、そういう話ではないんです。
いや、明確なのはよいことですよ。エンジニアは知りたいんです。それが分かれば、その前提で計画できますから。あと私にとっては、自分の別のマシンに切り替えないといけないんですが、planningは本当に重要です。承認したり、方向性が合っているか確認したりするうえで。ask user questionの見せ方も本当にきれいです。cursorやClaude Codeにもありますが、これほど気持ちよく見えるのは珍しい。自分のやりたいことをちゃんと理解してくれていると感じられるんです。
そう言ってもらえてうれしいです。先行事例という意味ではありますからね。
evalとは何か
evalという話題に移りたいんですが、evalと言うと、人によって意味がかなり曖昧ですよね。単なる雰囲気テストなんでしょうか。それともClaude Co-workに対して、自動化されたプログラム的なevalをしているんでしょうか。
evalと言うとき、私たちが本当に意味しているのは、最終的にClaudeに到達する、ツールも含めたトランスクリプト全体を取り、それに対して、ある変更を加えたときに出力がどう変わるかを測るということです。これをかなり頻繁に実行しています。トレーニングにも使いますし、ポストトレーニングとその周辺のscaffoldingを分けて考えるなら、co-workはscaffolding側に属しますが、それでも少しはトレーニングにも使っています。
だから、evalというときは、あるトランスクリプトが与えられたときに、ファイル出力も含めて、あるいはチャットウィンドウに表示されるトークン出力も含めて、結果がどうなるかを見るという意味なんです。
気になるのは、失敗モードのどれくらいがモデルの知能の問題で、どれくらいがその知能をちゃんと発揮させるための周辺ツールの問題かということです。たとえばplanningはよい例ですよね。計画を立てることと、その計画をうまく見せるスプレッドシートを作ることは別です。そのあたりはどのように進化してきましたか。
私がよく悩むのは、どんなscaffoldingを考えたとしても、まだ私たちにはモデルオーバーハングのようなものがあると思うことです。モデルは、ユーザーが実際に使っている範囲よりもずっと高い能力を持っている。そしてその一因は、モデルが理論上できるはずのことをするために必要なツールを、こちらが全部渡せていないからだと思います。これはひとつの問題です。
ただ、scaffoldingを作り込むとき、ある時点でそれは不要になるのではないかとも思うんです。では、正しいscaffoldingを突き止めることにどれだけ投資すべきなのか。これはちょっとした賭けでもあります。
エンジニアとして私がAnthropicのようなフロンティアラボで働いていて楽しいのは、次のモデルで何が来るのか、それが何に強くて何に弱いのかについて、多少は人より見えていることです。そして最近ますます思うのは、モデルが本来はそこまでおかしく振る舞わないのに、やってほしいことをしないからといって、その補正のためのscaffoldingにこちらがあまりにも多く投資するのが正しいのかということです。それとも、できるだけ多くの能力を与え、悪いケースでもひどくなりすぎないよう安全にし、そのうえで次のモデルが出るのを少し待つほうが正しいのか。
私は今のところ、後者にかなり傾いています。
短期的には非常に効果的に見える、特定ユースケースに強く特化したAIアプリケーションや企業がたくさん出てくると思います。でもモデルが一般化にもっと強くなり、そこまで細かく導かれなくても特定ユースケースをこなせるようになると、それがどれだけ長く残るのかは正直わかりません。
これって、skillsやMCP serversの世界でもすでに少し見えてきていますよね。MCP serversからskillsへのゆっくりした移行のようなものです。いい例がBarryです。skillsを作った彼ですが、最初にいじっていたものは、正直、今のco-workにかなり似ていました。コードを書きたくない人向けのco-workみたいなものを考えていたんです。
しかも彼も、それをデスクトップアプリ内のプロトタイプとして作っていました。最初のユースケースのひとつは、GUIやコードから少し切り離された形で非常に役立つコーディング的ユースケースは何かというものでした。するとみんな同じ答えを出すんです。データ分析です。今のユーザー数はどうか、とか、そういう話ですね。
最終的にskillsへつながったのは、その小さなプロトタイプを社内のデータウェアハウスにつなぎたくなったからでした。チームはすぐに、データウェアハウスと会話するための専用ツールを作る代わりに、単にMarkdownファイルをひとつ作ったんです。Claudeへ、データが欲しいならこのエンドポイントがあります、APIはこういう形です、あとは自分で考えてください、と。
そのまま制御を渡す。
そうです。抽象レイヤーを一段上げたわけです。CLIがあるからこれを呼んでくださいとか、MCPがあるからこのインターフェース形状を使ってくださいではなく、ここにエンドポイントがあります、知りたいことがあればここへPOSTしてください、PostgreSQLかもしれませんが大丈夫でしょう、というくらいの感じです。
それが驚くほど効果的で、彼らは同じパターンを別のことにも試し始めました。つまり、モデルに必要なことを書いたMarkdownファイルを渡すだけ、というやり方です。それが最終的にskillsになった。これは製品化すべきよいアイデアだとなったんです。
Barry Maheshにはうちのカンファレンスにも出てもらいましたが、たしかに彼はいいところに目を付けていました。
実際のco-work活用例とskills
ぜひ見せたかったんですが、これが私のClaude Co-workの使い方なんです。ここがいちばん好きな部分でした。
これ、まさに私です。Discordの運営に使っています。最初はClaude Co-workをそこまで信用していなかったので、これが私の最初の使い方でした。
なるほど。
まずはZoomから録画を手動で全部ダウンロードして、それをYouTubeにアップロードするだけやらせてみたんです。これって本当に面倒な作業なんですよ。クリック、クリック、クリックで、しかもYouTubeはそこまで使いやすくない。でもちゃんとやってくれたんです。
それで、いや待てよ、Zoomからダウンロードする部分もClaude Co-workに入れてしまえばいいんじゃないかと思って、そうしました。こういう作業がたくさんあって、途中で圧縮も始めるんですが、動画の各フレームを見てタイトルを考えるみたいなことまでできるようになったんです。だから自動でアップロードもできて、これで私のYouTuberとしての仕事が置き換わるわけです。
あなたの創造性にはずっと感謝しますよ。
しかもあとで圧縮して、新しいものを作るんですよね。最初のものは残っていないんですが、そのあと私は、自分用のskillsを作ってくれと頼みました。そうすれば、反復的で、その都度人間が面倒を見る必要がある作業が、もっと自動化されるし、そのskillsを独立して再利用できます。もちろん、skillsも書けるわけです。それがコンテキストに入り、下のskillsのところに出てくる。それが本当に気持ちいいんです。
今では、毎週やる作業に対応するskillsがいろいろあります。scheduled co-worksがリリースされたのは知っているんですが、まだ試していません。
ぜひ試してください。
こういうのを見るのは、私にとって本当にすばらしくて楽しいことです。特にskillsのよいところは、とにかく簡単に作れることなんです。誰でも作れる。テキストメッセージだってskillになり得ます。そして、ものすごくその人向けに最適化できます。これこそ抽象化レイヤーなんです。
想像ですが、あなたは自分の仕事がとても上手なんでしょう。だからおそらく、この作業のやり方についていろいろ指示を与えてきたはずですよね。
私はただ、全部skillにまとめてくれと言っただけです。
そうなんですね。
そして、場合によっては分解したいこともあるなと思ったんです。一部の工程が失敗することもあるし、個別に使いたい部分もある。それでひとつのskillを3つに分けてくれと頼みました。skillを分割する感じです。そして必要なら、その全部をまとめてオーケストレーションする親skillもあります。
それは本当にいいですね。
あともうひとつは、さっき話したGoogle Chromeの件です。つまり、Claude Co-workを使ってYouTubeにアップロードするよりも、YouTubeにプログラム的にアップロードするためのドキュメントを実際に読ませて、それをskillにするほうがよいわけです。私はGoogle Cloudを触りたくなかったので、それもClaude Co-workがやってくれました。
それは本当にすごいですね。
私はもうどうでもいいんです。ただやらせるだけ。どう実現しても気にしない。
それはすごいです。そして、そのskillを生成したスクリプトと組み合わせたわけですよね。
そうです。そしてあとはskillを更新していく。
きれいですね。本当にすばらしいです。
結局、Claude Co-workに慣れていく人たちって、最初は普段クリックでやっている知的労働のタスクをひとつ取って、それをClaude Co-workに置き換えていくんですよね。それから、じゃあもう一歩進めたらどうだろう、その先はどうだろうと進んでいって、信頼が増すにつれてco-workの範囲も広がっていく。そして自分の置き換え方も教えていく。
そうですね。自分の人生に対するFactorioみたいな感じです。最初は小さく始めるんです。ごく小さいものを自動化する。そこがはまると、その上にどんどん自動化帝国を積み上げていく。どんどん人生が楽になっていく。
私のお気に入りのskillは、毎朝Cobbergが私のカレンダーを見て、競合がないかを確認してくれるものです。人って会議をたくさん入れますし、ときには直前だったり、既存予定を見落としていたりして、それが本当に面倒なんです。
そういう製品は以前からたくさんありますよね。
これはcustom promptに書いてあるだけで、まだskillにはしていません。正直、そろそろしたほうがいいですけど。
でもそこには、かなり明確な指示を書いてあります。たとえば、ある特定の人が既存の会議に重ねて予定を入れてきたら、そちらを優先する可能性が高いとか。たとえばDarioが会議を入れてきたら、その会議を動かそうとはしないとか。ほかにも、どの種類の会議をより重視するか、どの会議は後回しにしてよいか、働きたい時間帯、働きたくない時間帯。そういう細かいことです。
こういう本当に小さなことが、人にとって腑に落ちるポイントなんだと思います。co-workをローンチしたとき、TwitterやXでかなり拡散したフレーズのひとつが、デスクトップを片付けて、でした。もちろん、少し滑稽ですよね。モデルがなくてもデスクトップは片付けられますから。厳密には。
たしかに。デスクトップをきれいにしてくれ、という感じですよね。
そうです。
でも、それをやらせるにはデスクトップへのアクセスを与えないといけない。
その通りです。
なるほど。では、ちょっと怖いけどやってみて、という感じですね。
私はDownloadsフォルダでやりました。すると、お前、term sheetが多すぎるとか、オフィスの賃貸契約書のコピーが8個あるとか言われて。もうわかったから、そんなに責めないでくれ、と思いました。
そんな小さなタスクなんですが、普通なら、それを人に向かって、私はあなたの写真を整理してくれる製品を作りました、とはあまり言わないですよね。小さすぎる感じがするから。でも、あなたの言う通りなんです。
ask user questionと細かいUIの価値
ここがask user questionですね。
はい。
きれいでしょう。たとえば、これは明らかなゴミですか、と聞いてきて、たぶん不用意にクリックすべきではない。
まだ終わっていないなら、ですね。
元に戻せるなら、まあ。
そうですね。
私にも、なんでもぐちゃぐちゃに入れてある典型的なフォルダがあります。これはかなり助かります。単純なタスクですが、進行状況も見られます。これを見ると、これはClaude Codeとは別物に違いないと思ってしまうんです。
そこはシステムプロンプトでかなり誘導しています。このタスクは方法立てて考えるように、と。
しかも、ここにちょっとした提案も返せますよね。これをするな、それはやるな、といった指示を出せる。すばらしいです。
気に入ってもらえてうれしいです。逆に言えば、Claude Codeチームの一部でもあるので、Claude Codeにもこれが欲しければ、という話でもあります。
ええ、ええ、ぜひ。というか、本当にこれはかなりいいです。もちろん私はかなり褒めていますが、ほかにも、PG&Eの契約をしてとか、そういうのもあります。電話をかけてくれるなら最高なんですが。
それは他社のサービスと組み合わせて、すでにやっている人たちはいます。ネイティブではできませんが、いろいろなプロバイダーを使って実現している人はいます。
それから、Figma MCPへの登録もあります。私は本当にできるだけ何でもやらせようとしているんです。データ分析もありますし、設計からコード化する作業もかなりよい。たとえば、これはFigmaファイルだから、これを取ってコードにして、というようなことですね。ほかの多くのタスクは知的労働、つまり手でクリックしている作業の置き換えなんですが、これは違います。普通ならClaude CodeやClaude Code appを使う場面です。でも、あなたたちのほうがChrome統合が強いと感じたので、こっちのほうがうまくできると思ったんです。実際、これは私のカンファレンスサイトをワンショットで作りました。
それはかなりすごいですね。いずれ、デスクトップアプリ内でのコード作業についてどう感じているかも聞いてみたいです。私はほとんど使わないので。同じチームですけどね。
私はターミナルのClaude Codeを使っています。それがデフォルトの使い方だと思っているので。
ひとつ言えるのは、これは組み込みブラウザを持っているということです。こういう組み込みブラウザを持つ製品はたくさんありますが、Claudeに自分が実際にやっていることを見せられると、圧倒的に効果が上がるんです。たぶんco-workで感じたのはそれでしょう。Chromeが見えるし、DOMをデバッグできるし、画面の内容も見える。だからより強力なんです。
ブラウザ統合と既存ワークフローへの接続
なるほど。私のメンタルモデルは少し壊れていたんですね。私はco-workにブラウザ機能が入っていると思って、それだけの理由で使っていたんですが、Claude Code appにも組み込みブラウザがあるんですね。プレビュー機能は見たことがありました。
そうです。
でも結局、最後はハーネス次第で死ぬと。
そうですね。要するに、Claudeは自分が作業しているものを見られると、もっとよく働けるということです。Chromeを使っていようが、自前の小さなブラウザを立ち上げていようが、そこに大きな差はありません。どちらにせよ、自分が作業している対象を見られる。それだけでぐっとよくなる。そして、あなたがClaudeのためにQAをする必要もなくなるんです。
でも、なぜ既存のClaude Codeセッションを拾ってくれないんですか。私、明らかに使っているのに。
すばらしい質問ですね。
よい答えはありません。今のところ、そこは正直にそう言うしかないです。
なるほど。OpenAIチームがやることみたいな感じですね。
ほかにこれ以上はないですが、ただ人の発想を広げたいし、まだあまり試していない人に、こんな使い方もあると見せたいんです。実際、私はDiaも使っているし、ほかのエージェント系ブラウザもいろいろ使っています。でもAnthropicは、エージェントブラウザをわざわざ作らなくても、Claude Co-workがあれば十分だったんですよね。
今のところ私個人の優先順位では、ブラウザをゼロから作り直そうとするより、すでにある優れたブラウザ群と統合するほうが上です。
もちろん、絶対にやらないとは言いません。でも、さっきの、既存のあなたのワークフロー全体に接続したいという考えに戻ると、私たちの目標は、あなたのコンピュータ上にある既存アプリを置き換えることではなく、新しいワークフローとうまく共存することなんです。
なるほど。今のブラウザ界隈の革新って、とくにブラウザ上ではユーザー体験や人間工学的な部分が多くて、基盤のブラウザエンジンそのものではない感じがします。だからClaudeにとっては、VivaldiでもChromeでもArcでも、経路が何であるかはそんなに重要じゃない気がするんです。
ええ。私たちは、あなたがいる場所に会いに行きたいんです。もちろん、そう言うのは当然なんですが、本当にそうなんです。ブラウザを変える気のある人だけを対象に製品を作ろうと言って、潜在的なユーザーベースをわざわざ狭めたくないんです。
どのブラウザがデフォルトか、どの検索エンジンがブラウザ内でデフォルトかという問題には、いくつもの訴訟が絡み、大金も動いてきました。私はただ、Swixみたいな人のために作りたいんです。つまり、これはClaudeならやってくれるかもしれない、と感じる厄介なタスクをいくつも抱えている人たちのために作りたい。
skillsの可搬性と個人化
skillsの可搬性についてはどう考えていますか。私はZoという、クラウドコンピュータにエージェントがついたような別のものも使っていて、オフィスに来客を追加するskillを持っています。誰かが営業時間外に来るとき、下でチェックインしなければいけないので。でも、それってco-workではうまく動かない。そうすると、そのskillはZoのハーネスの中にあって、co-workにはないことになる。変更したら同期しなきゃいけない。今後どうなっていくと思いますか。memoryはClaude個人にひもづく感じでよくて、必ずしも製品横断でなくてもいいんですが、skillsは自分が使うエージェント間で横断してほしいんです。MCPでも、MCP gatewayとかMCP registryとか、みんな同じことを考えていましたが、それが本当にビジネスになるかはわからない。なので、このあたりについて考えがあるのか気になります。
私にとって、ここは本当に基本的なプリミティブの話に戻るところです。skillsは、どこかの得体の知れないブリスの中にあるような複雑なものではなく、ファイルベースなんです。すべては単なるファイルとフォルダだ、という考えに私はかなり寄っています。そのおかげで、それ自体としてかなり可搬性があります。
私たちは、skillsをpluginsというコンテナ形式の一部として持っています。pluginsはClaude CodeとClaude Co-workの両方で使える同じ形式ですし、pluginsをインストールすることもできます。これはCodeでも今すでに動いています。たとえば、GitHub repo全体をskills marketplaceあるいはplugin marketplaceとして追加できます。私たちが可搬性を実現しているのはそういう形です。
もちろん、まだ改善の余地はかなりあります。人々がskillsを書けること自体をどうやって気づけるようにするか。それをほかの人とどう簡単に共有できるようにするか。今私が言ったことの時点で、もう多くの知的労働者は置いてけぼりになっているわけです。GitHub repoにつなげられますと言った時点で、一般的な知的労働者が普段するやり方ではないですから。
ただ、そこには何かあると思っています。そして、まだ業界全体として十分に探れていないこともあります。どの部分が可搬性の高いskillなのか、そしてどの部分がその人に極めて個人的なskillなのか、という組み合わせです。そこは業界としてまだ解けていないと思います。
つまり、skillにもっと構造を持たせるのか、それとも常に公開用skillと個人用skillのペアを持つようにするのか、という話ですね。
そうですね。いちばん簡単なのは、文字列補間のようなものを使うことです。ここにユーザー名を入れる、ここに電話番号を入れる、ここに既知のフォルダ位置を入れる、そういうものですね。でもそれはたぶん少し不格好です。だからまだ作っていません。
ただ、誰かが、skillsのよさを全部残したうえで、面白い方法を思いつくはずだとは思っています。skillsはただのファイルで、ただのMarkdownで、正直ただのテキストです。構造がまったくないからこそ、skillを書くのに特別なチュートリアルはいらない。私に説明するみたいにClaudeに説明すればいい。おそらくClaudeのほうが私より先に理解してくれるでしょう。フライトの予約をするなら、フライトの予約方法をそのままClaudeに教えればいいんです。
ただ、それを非常に個人的なものと組み合わせる必要がある。さっきのフライト予約の例を続けるなら、私は実はAIがフライト予約をするべきだとは思っていません。私たちが持っているツールでは。
やっと言ってくれた人がいた。あれ、誰もがやる定番デモでしたけど、私はフライト予約デモが嫌いでした。よい見せ方じゃないと思っていました。
ですよね。私は自分のフライトは自分で取りたいんです。
でも多くのことには、個人的な要素と個人的でない要素の両方があります。だから人はフライト予約を例に出しがちなのかもしれません。たとえば、安い便のほうがよい、という部分はかなり普遍的です。いちばん高い便を好んで予約する人は少ないでしょう。一方で、どの時間帯が好みか、どの席がよいか、どの空港が好きかはかなり個人的です。そうしたものを、可搬性があり、互換性があり、人にも理解しやすいskillの形式でうまく組み合わせられたら、とても面白いと思います。まだ解けていないだけです。
テキストであるという部分は大きいと思います。今どき、DropboxにせよGoogle Driveにせよ、みんな何らかのクラウドファイルストレージを持っています。だから、ある意味では、skillsは全部のエージェントハーネスにsim linkされて、同期されるべきだと思うんです。社内でもvaluable tokens repoのようなものがあって、そこにコマンドやsubagentsがまとまっているんですが、私はTUIを作って、これをこのエージェントのこのフォルダにインストールする、みたいにできるようにしました。やっていることは実際には単にファイルをコピーしているだけですけど。でも、新しいものに入るたびに、ここがそのClaudeフォルダへのリンクで、ここからskillsを取り込める、というような仕組みがあるべきだと思うんです。今はまだそうなっていません。新しいエージェントを入れたら、毎回skillsをコピペしないといけないし、そもそもどこにあるのかわからない。それがいちばん大きい問題なんです。
skillsはファイルなのか、共有知識なのか
私は、エージェントやLLMを、もうひとりの同僚として考えるのがとても好きです。世の中にはドキュメンテーション会社を作ろうとする試みが本当にたくさんあって、私自身もNotionで少し仕事をしていました。つまり、みんなを同じページに乗せたい、という発想にはすごく慣れているんです。
今あなたが言っているのも、まさにそれですよね。自分の好みやskills、作業のやり方について、すべてのエージェントが同じページに立っていてほしいということです。
何が正しい解なのかはわかりません。独立した存在として、特定の製品に押し込もうとはせず、skillsの権威になる会社が現れるのかもしれません。Dropboxのskills版のように振る舞って、使いたい製品にsim linkできるようにする、といったものです。ビジネスとして成立するかはわかりませんが、発想としてはおもしろいですよね。
そうなんですよ。もうビジネスとして何が残るのかもわからなくなっている。誰かにそういう製品を作ってほしいというより、私は個人的にどうすればいいのか知りたいだけなんです。それに、あなたの言うように、skillを個人用と仕事用の間で補間したくなることもあります。仕事のためにフライトを予約するのと、個人で予約するのとでは違う。でも足場となる部分の多くは同じなんです。
エンジニアからエンジニアへの話として言うなら、私はただsim linkすればいいじゃないかと言いますね。
それが今、cloud.MDやagents.MDでやっていることです。同じ場所からみんなsim linkしている。だから一応は動きます。でも、なんというか。
もうひとつ上のレベルに行くこともできますよ。co-workに問題そのものを伝えれば、co-workが解決してくれます。sim linkも作ってくれる。そういうやり方もある。
たしかに。結局なんでもco-workなんですね。
どの産業が消えるのか、そして若手雇用への影響
少し刺激的な質問かもしれませんが、お二人に聞きたいです。どの業界がなくなっていくと思いますか。
うーん、Felixがさっき言っていたのは興味深いです。要するに、短期的な圧力として、トークンを価値あるものに変えなければならない。それは、モデルを活用して最後の一マイルの製品を作る、ということですよね。その一方で、長期的に何がなお価値を持ち続けるのかという問いがある。
今のコーディング分野でもそれが起きています。みんなスタックの上へ上へと移動している。単にトークンをコードに変えるだけでは足りないからです。検索分野も似た状況だと思います。企業内検索でも、Gleanのような会社も含めていろいろありますが、結局co-workが全部の仕事をしてくれるなら、検索そのものはごく小さな一部です。だから、検索だけのためにそこまで大きな金額を払うのかはわからない。ほとんどすべてがco-workの垂直統合のようになっていく。では、co-workがファーストパーティとしてどこまで支援できるのか、どこまでできないのか、という話になります。
それに、先ほど見せていたplanningのような部分。ああいうものは、エージェントが提供する価値の多くが、特定タスクに対してよりよい計画を立てたり、よりよいツールを持ったりするところにあります。でもモデル自体が今そちらに向かっていて、適切なハーネスがあり、しかも自分のコンピュータ上で動いているなら、結局のところ、そのスタートアップがそのタスク結果の提供者として信頼されるかどうかにかかってくると思うんです。
それは、私たちが今まさに取り組んでいる短期的な山場でもあります。
正直に言うと、どの産業がいちばん大きな打撃を受けるかを見積もるのに、私が最適な人間だとは思いません。でもAnthropicという集団として、私たちはこの種のツールが労働市場に与える影響、とりわけ若手社員への影響を非常に強く懸念しています。
というのも、私たちが、自分たちにとって煩わしい仕事や、自分の時間の最善の使い方ではないと思う仕事を大量に自動化しようと話すとき、その種の仕事は多くの業界で、これまでジュニアのエントリーレベル社員に任されていた仕事だからです。だからそれを心配するのは、ごく当然のことだと思います。特に、これから労働市場に入ってくる人たちに何が起きるのかという点で。
私なりの解決策があって、半分冗談で半分本気なんですが、疑似的な仕事を作ればいいと思うんです。
なるほど。
ソフトウェアエンジニアリングで考えてみてください。ジュニアエンジニアとして1年、2年、3年働くとして、その3年間の中で、本当に何かを学ぶ瞬間って、たぶん数えるほどしかない。その一方で、ほかの多くの日は、そこまで進歩していない。ならAIとこうしたモデルを使って、キャリア初期をショートカットできるんじゃないか。仕事の初期数年を疑似的に再現して、学びだけを超高密度に詰め込めるんじゃないかというわけです。
たとえば、今取り組んでいる機能は分散システムで、これを学ぶのに本来は会社で3か月かかる、とする。なら、ここではその3か月をまるごとシミュレートして、1週間で一気に駆け抜ける。そこから学びを得る。それを繰り返すことで、1年で3年分のプロジェクトと経験を積めるようにするわけです。
営業やマーケティングではもっと難しいと思います。フィードバックループをどう作るかが厳しいので。でもかなり多くのことは、少し滑稽に聞こえても、新しい偽の仕事を作るようなものなんです。でも大学だってそうですよね。人はお金を払って仕事の仕方を学ぶ。この発想もそれに近いかもしれない。Jane Street simulatorみたいなものです。Jane Streetで働きたいですか。では3か月シミュレータに入ってください。出てきたときには、準備ができている状態になっている。
ここには何かあると思うんです。もちろん私は、マーケティングや法務や金融に何が起きるかを断言できるほどの専門家ではありません。そういう仕事をしていませんし、そこについて語るべきではないと思っています。でも私はエンジニアで、エンジニアリングがどういうものかはかなりわかっています。そして私たちが見ていることのひとつは、会社としても世の中としてもエントリーレベルを非常に心配している一方で、シニアエンジニアの加速も見えているということです。彼らはより生産的になり、提供する価値も増えている。
そして私がよく考えるのは、このすべてが起きる前から、University of Waterlooと、そこから私のチームに来た新卒たちにはいつも敬意を持っていたということです。Waterloo出身の新卒は、大学にずっといたままの新卒よりも、たとえ優秀でも、実際の製品を出荷し、ユーザーに使われる環境で働いた経験がない人たちよりも、明らかに即戦力でした。
私はドイツ人で、最初はドイツの大学に行ったんですが、情報システム系のプログラムはかなり理論寄りなんです。私はよく、人にこういう例を出します。医者になろうとしているのに、最初の4年間は生物学だけをやらされるようなものです。その結果、新卒が来ると、実際に製品を作るとはどういうことか、会社で働くとはどういうことか、他人と一緒に働くとはどういうことかを一から教えなければならない。人によって意見も違うし、それをどう扱うのかも学ばなければいけない。
一方、University of Waterlooでは、半分くらいの時間を実際に働くことに使っているように見えます。本当に1年なのかはわかりませんが。
カリキュラムの一部として、かなりの期間をインターンに使っていますよね。
そうです。会社から会社へ渡り歩く。チームにやってくると、20社くらい経験したジュニアエンジニアみたいな顔をしている。実際そこまでではないですが、多くの新卒がApple、Google、Teslaにも短期間いたりする。
ありますよね。ロゴをインフィニティストーンみたいに集めるミーム。LinkedInに載せて、実際にはインターンだったかどうかがよくわからない。
そうそう。でも、ほかの新卒に比べて本当にかなり良いんです。もしかすると、将来的にはそれが有用なモデルになるのかもしれません。ジュニア社員として使える時間が短くなり、その価値が影響を受けるのだとしたら。
若手はAIネイティブになれるのか
私の若者擁護的な見方をすると、若い人は神経可塑性が高い。より多く学べるし、既存のバイアスも少ない。そしてこれはたぶんあなたにも当てはまると思うんですが、OpenAIがよく言うのは、実は新卒の若いエンジニアのほうが、codexやコーディング支援を、経験豊富なエンジニアより革新的に使うということです。経験者はすでに自分のやり方を持っているからです。
人と話していて、私も似た経験をしました。
だから、よりAIネイティブである分、適応しやすいかもしれない。でも問題は、それほど多くは必要ないということです。
Anthropicはすでに公式に、労働市場への影響は相当大きいと考えているし、世の中全体として準備ができているとは思っていないし、社会としてもっと真剣に話し合うべきだと言っています。
私個人がそこに何か有益なことを付け加えられるかはわかりませんが、経済学者や政府を含めた社会全体として、その問いに向き合う必要があるのは間違いなくて、今はまだ十分ではないと思います。
私たちも発信を通じて助けたいですね。
それに、みなさんがそうしているように、頻繁にリリースすることも、人々が徐々に慣れていく助けになると思います。大きな一発ではなく、緩やかな立ち上がりの中で、人々が実際にその変化を生きている。そうして目が覚めていくわけです。
そうですね。
ただ、多くの人が気にしているのは、ではいつ完全な立ち上がりになるのか、ということだと思います。私たちはみな、ある瞬間から加速が自己強化ループになって、一気に走り出すようなビッグバン的瞬間をどこかで予想しています。そこから先は、もうゆっくり追いつく時間はない。Claudeがありとあらゆることにうますぎる状態になるわけです。
たとえばco-workがモデルを訓練し始めるときですね。tensorboardやweights and biasesの値を見て、訓練を進めていくようなとき。
そして、その瞬間が何年先なのかについては人によって賭けが違います。10年先かもしれない、1年先かもしれない。私自身がどこに立っているかも完全には決まっていません。でも、4年後に起きるのか5年後に起きるのかが、最終的にそんなに重要なのかもよくわかりません。それがかなりの確度で起きると考えられるなら、私たちは今のうちから向き合うべきです。
デスクトップ整理から税務まで、知的労働全般へ
ところで、scheduled taskが完了して、デスクトップ整理タスクも終わりました。ファイルタイプごとに整理してくれたんですが、まあそれも悪くないけれど、本当はもっと主題ごとにやってほしかったんです。ファイルを読んで内容を理解して、ファイル形式ではなくトピックごとにまとめてほしかった。
そこはフォローアップでそうしてくれと言えばできますよ。
そうですね。実際、提案もしてきています。だからたぶん、もっとよくできる余地があります。たとえば動画ファイルを読むskillを与えれば、私がどう整理したいのかもっと理解できるかもしれない。
でも正直、あなたはOpenAI 4.6を使っていますよね。最近の私のおすすめは、細かい心配はしないで、ただやってほしいことを言えばいい、というものです。たいてい何とか方法を見つけます。
なるほど。
もちろん、それが必ずしもあなたの好きなやり方とは限らないし、あなた自身ならそうしないだろうというやり方かもしれませんが。
動画ももっと深く見られる余地がある。でも、整理全体はどんどん外注していく。そういう感じですね。
そうです。
私は正直、Claudeがどういうやり方を思いつくのかを見るのが本当に楽しくて、ますます興味が出ています。
vision for everythingがスーパーパワーなんですよね。コンピュータ利用の分野でも、Anthropicはcomputer useを最初にやりましたよね。あれが出たとき、私は正直あまり感心しませんでした。遅いし、信頼性も低かった。でも、この1年でどれだけ良くなったかを考えると、すごいですよね。
本当に。Anthropicのオフィスに、computer useのローンチイベントで行ったんです。ハッカソンみたいなものがあって。でも、誰もcomputer useでハックしていなかった。
それを言ってもいいのかわかりませんが、でも、あなたのコネクタの中にMac OSを自動化するMCP serverが入っているのをちらっと見たんです。あれは使っていますか。
え、どれですか。settingsの中ですか。
そうです。そこです。
ああ、これですね。たぶん一度設定しただけで、今は積極的には使っていません。
なるほど。Mac automatorですね。
私は本当に、自分の環境の何もかもを自動化したくてこれを入れたんです。でも、そこまで信頼性が高いとは感じませんでした。
なるほど。
質問しただけです。
Claudeは、そういうサードパーティツールに頼るより、自分でAppleScriptを書いて実行するほうがずっとうまいんです。最初はImageMCPだとか、ほかのいろいろなMCPを入れていましたが、今はもうほとんど使っていません。Claudeに自分で必要なものを書かせればいい。
上のレイヤーへどんどん上がっていく話ですが、computer useで実機を使うことにはかなり興味があります。しかも、理論上のコンピュータではなく、本当にあなたのコンピュータをClaudeがうまく使えるようになる日は、そんなに遠くないと思っています。
Claudeがあなたのコンピュータを使うとはどういうことか
ユーザーとコンピュータの関係ってどうなるんでしょうね。co-workが作るVMが12GBとか15GBもあるというツイートを見たことがあります。人はそれに文句を言います。でもある時点から、そのコンピュータは実際にあなたが行動している場なのだから、それはもうあなたのコンピュータなのではないか、とも思うんです。ただ自分が見ているだけで。だから、Mac miniの上でOpenClaudeみたいなものを動かすという発想が好まれるんだと思います。そこが自分の居場所で、自分は自分のことをし、向こうは向こうで動いている。ある種の競合状態ではないけれど、そういう awkwardさがありますよね。今タスクを走らせたら、もうそのコンピュータは使いづらい。co-workerがその上で作業しているから。
すごく面白い領域だと思います。私もいろいろ考えましたし、今ではこれはよくないアイデアだったなと思うものもあります。
co-workに最初に取り組んだとき、Claude専用のカーソルがあったらどうだろう、という夢を抱いたことがあります。コンピュータなんだから、コードも書けるし、すべてに触れられる。コンピュータにカーソルがひとつしかないなんて誰が決めたんだろう。2つ目のカーソルがあってもいいんじゃないか、と。
でも、それはかなり早い段階で破綻します。AppleやMicrosoftに行って、これ面白くないですかと言っても、結局ダメなんです。なぜなら、コンピュータ上の多くのモデルが、ひとつのものだけがそこで動いているという前提で作られているからです。フォアグラウンドアプリ、バックグラウンドアプリという概念もそうです。ClaudeとChromeなら、ひとつのアプリ内でバックグラウンド動作できますが、OSレイヤーではそれを実装するのはずっと難しい。
だから私はまだ悩んでいます。Claudeが本当にあなたのコンピュータ上で動くとはどういうことなのか。Claudeに専用コンピュータを与えて、それをセットアップして、時々そこにズームインして一緒に触るのが正しい形なのか。それとも、あなたが少し席を外したときにClaudeが乗っ取って働くのが正しいのか。あるいは、Claudeはクラウド上に自分専用のコンピュータを持っていて、Claudeにやってほしいことは全部あなたがそちらにセットアップする形が正しいのか。
いくつもの選択肢があります。このことはよく考えています。あなたとコンピュータの関係、そしてあなたとその中のデータの関係です。その親密さは、ツールや扱っているものによって違います。あるものはかなり平気で共有できる一方で、別のものはまったく共有したくない。
最終的に成功する製品は、そうした違いに向き合わなければならないと思います。でも、仮にClaudeに判断能力があったとしても、その判断をClaudeにさせたいでしょうか。難しいですよね。プライバシー以上に、ある種の親密さの問題なんです。みんなが安心できる形に落とし込むのはとても難しい。
VirtualBoxのような実際の仮想マシンアプリの形はあり得ると思います。VMを走らせて、その画面が画面の中にある。背景で動かしておいて、必要なときだけその中に飛び込む。悪くないですよね。
そうですね。
昔、Windows上でKali Linuxを仮想化して、その中に入ったり出たりする使い方がありましたよね。デュアルブートではなく、システムの中のシステムとして。ただ、RAMもストレージも倍くらい必要になって、マシンにはかなり負荷がかかる。
でも、Claudeの小さな画面があって、そのデスクトップが見えて、かわいく何かをクリックしているのが見える。それはちょっと面白いです。
Windows 95から見る、仮想化とUIの発想
彼はもともとmachine in the machineの人ですからね。Windows 95プロジェクトがありましたし。Windows 85プロジェクトは今どうなっていますか。
たぶんGitHubにありますよね。
いやいや、最初に出てくるのがこれなんですよ。
いいですね。
あれは本当に楽しいプロジェクトでした。ただ誤解されないように言っておくと、私は実際のWindows 95を作ったわけではありません。子どもでしたし、当然ですけど。それに、JavaScriptとWebAssemblyの中でx86プロセッサをシミュレートできる実際のエンジンを作ったのも私ではありません。それはV86というツールで、本当にすばらしいものなので、みなさんぜひ試してみてください。
このプロジェクトは、職場での議論から生まれました。Electronの利点や、JavaScriptでソフトウェアを作るべきかどうかについての議論です。私は今でも少し腹を立てているんですが、Windows 95全体をJavaScriptで動かし、その中でMicrosoft Excelを起動して何かをするという一連の流れを、従来型のSaaSアプリでいろいろやるよりも速く実現できたりするんです。
ある意味で、これはパフォーマンスへの怒りから始まったプロジェクトでした。ほとんど冗談みたいな感じで、当時のSlackの同僚たち向けに一晩で作ったんです。
えっ、一晩で。
そこまで難しくなかったんです。難しい仕事のほとんどはV86側にあります。repoを見れば、仕事の99％はCopyというハンドル名で活動しているFabianがやったと書いてあるはずです。
クールですね。あなたはまたWindows対応の開発でWindowsに戻ってきている感じもあります。技術的な話としてもかなり面白いですし、サンドボックスにどう投資するか、その重要さもよく分かる。だからここで少しそのディテールについて話すのはよい機会かもしれません。
VMとサンドボックス、そして安全性の設計
VMは本当にすごいんです。もちろん嫌いな部分もたくさんあります。トレードオフは現実にありますし、なぜそのトレードオフを取るのかは理解しておく必要があります。
たとえば多くの人が、Claudeが10GBも使っているのはなぜだと連絡してきます。その点について言うと、実際には10GB使っているわけではありません。Mac OSのバイト表示の仕方の問題で、表示がよくないんです。実際にディスクに書くときには、イメージ内の空き領域を潰しているので、本当には10GB使っていない。でもそういう技術的な説明は、長くはあまり意味を持たないかもしれません。
私にとって本当の問題は、起動に時間がかかることです。30秒くらいかかるように感じる。
そこまでではないはずです。もっと速いです。でも10秒でも30秒に感じる、というのはわかります。
どちらにせよ、あなたのコンピュータ上で直接コードを動かすよりは遅くなります。そのトレードオフは本物です。
Windowsでは、Windows Host Compute Systemを使っています。WSL2が動いているのと同じ基盤です。Windows Subsystem for Linuxですね。多くの開発者がかなり気に入っているものだと思います。かなりかっこいいです。私たちはその同じサブシステムに乗ることで、あなたのコンピュータがどれだけロックダウンされていても、あまり気にしなくて済むようにしています。たとえば会社の管理下にあって、何もインストールできないマシンかもしれない。でも、それって多くの環境では普通のことですよね。Anthropicですら、IT部門がどんなソフトウェアを入れてよいかを管理しています。
こういう構成にすると、IT部門にとってもかなり都合がよくなります。ユーザーのコンピュータとClaudeのコンピュータを分けられるからです。そしてClaudeのコンピュータ側で気にすべきなのは、データ損失や、敵対的なアクター、データの持ち出しといったことになります。ネットワークとファイルシステム層を制御してしまえば、Claudeが有用なPythonスクリプトを書いていること自体は、そこまで大きな問題ではなくなる。
本当に怖いのは、Pythonを一度インストールしたら、そのコンピュータ上で誰でも何でもできてしまうことです。でも、それをVMの中に閉じ込めると、そのリスクはかなり下がります。
だから、私たちはこんなに手間をかけているんです。
最初期のClaude Code CLIだと、すべてのコマンドに承認が必要でしたよね。結局、人は承認疲れを起こすんです。すべてのコマンドを承認し続けるなんて無理だし、かといってすべて危険なまま許可するのもまずい。この二択の中間が、サンドボックスなんですよね。
そうなんです。業界全体として、何もしなければ安全です、みたいな考え方を超えたものを考える責任があるのかもしれません。本当に役立つものにしたいなら、すべてのステップで承認を求めるわけにはいかない。
computer useはよい例です。ホスト上でcomputer useを本当に安全にする唯一の方法は、おそらくすべての動作を承認させることです。モデルが、今からLという文字を打ちます、と言って、あなたが、それは今どのカーソルがフォーカスされているのか分かっているから大丈夫、と判断する。そういうレベルになります。
でも、それでは委譲にならない。
その通りです。ちゃんと委譲できなければいけないし、席を外しても信頼して任せられる必要がある。しかも、完璧なシステムを作る必要はないし、モデルアラインメントが100％になるまで待つ必要もない。業界で長く使ってきたSwiss cheese modelのようなものに頼ることはできます。でも、業界全体として、おそらくもっと投資すべきなのは、逐一承認しなくても済むシステムです。私たちは今、まさにそこに投資しています。
Swiss cheese modelといえば、彼がちょうどそれについて書いたものがありますよ。
それは面白いですね。
はい、本当に面白いです。安全性とかセキュリティって、エンジニアにとっては退屈な言葉に聞こえがちです。危険でもいいじゃないか、セキュアじゃなくてもいいじゃないか、と。でも、あなたたちが狙っているのはconsumer/proの両方ですよね。
そうですね、両方です。Claude Codeを問題なく使えるような人、つまりあなたのような人も取り込みたいと思っています。ただ、単純にco-workのほうが便利で、使いやすく感じることもあるわけです。右にto-do listがあって、それを編集できる。そういうのはやはりやりやすいです。
でも、これは明らかに知的労働側ですね。Claude Codeは開発ワークフローを明確に取る。一方で、ここまで信頼してもらうには、安全性やセキュリティの細部にしっかり汗をかかないといけない。ClaudeとChromeも、バックグラウンドで動くためにある種のAPIを使っているわけですよね。私がそれを使うのは、そうでなければ別のマシンを用意しなければいけなくなるからなんです。
それ、すごく面倒ですからね。
今も実際にはそういうことをしてはいますが。
そして、開発者である私たちは、たぶんリスク許容度が高い。でもそれだけではなくて、何かひどいことが起きても自分たちなら直せるという、ある種の自信もあるんだと思います。
私はClaudeに、メール送信や恒久的な操作のような取り返しのつかない動作だけは、必ず確認してと言っているので、それで十分だと思っています。でも、Claudeだけの話じゃないですよね。npm installだって、私たちはみんなフルユーザー権限で走らせていて、その気になればSSHの中身も読めてしまう。
その状況が普通になっているのは、たしかに狂っていますよね。
ええ、そう思います。でも私は毎日それをやっていますけどね。もちろん。npmやGitHub 2は、ここ数か月でかなり整理して、より細かいトークンを導入したりして、よい仕事をしているとは思います。でも全体として、エンジニアは昔から少しだけリスクに寛容すぎたのかもしれません。そして、自分に問い直してみると、それが本当に正しいやり方なのか、必ずしも正解が出るとは限らない。
モデルについても同じです。いちばん安全なのは何もしないことです。でも私たちは、本当に能力のある製品を作りたい。その一方で、できる限り、これは安全なPythonスクリプトですか、とあなたに逐一聞きたくはないんです。いったんワークフローの一部になってしまえば、そもそもそのPythonスクリプトが安全かどうかを理解するスキルがないか、あるいはどうせ読まないかのどちらかだと思うからです。
co-workの未来
最後にいくつか聞かせてください。co-workの未来はどうなりますか。
まだ本当に初期段階です。これからもかなりのスピードで、どんどんリリースしていくと思います。毎週、小さな新機能、あるいは時には大きな新機能が出ると考えてもらっていいです。
私は引き続き、あなたのコンピュータ、そしてあなたのコンピュータ上であなたを効果的にすること、Claudeをあなたのコンピュータ上で効果的にすることに賭け続けると思います。
今日も話したように、あなたのコンピュータとは何なのか、という問いにももっと向き合い始めています。それは目の前の物理マシンなのか、ローカル上のVMなのか、あるいはどこか別の場所にあるコンピュータなのか。
そして3つ目として、私がかなり楽しみにしているのは、質問して答えを得ることに慣れているユーザーたちを、少しずつさらに上の丘へ連れていくことです。つまり、少しずつ自分の手を離して、より大きく、より長いタスクをClaudeに任せるようにしていくことです。時間的な長さでも、スコープの広さでも。おそらく、これからの機能リリースの多くは、その両方、つまりあなたのコンピュータ上でより多くのことができるようにすることと、それをより自律的に、より長くできるようにすることの両方に向けられるでしょう。
remote controlはco-workでももう動きますか。
まだです。
いい質問ですね。
近いうちに、ですね。
つまり、コンピュータに賭け続けるのなら、それは当然必要になってきますよね。でも私からすると、人々がまだ今年に準備できていないと言う一方で、壁のようなものはなく、ただ加速が続いている。年末には、年初には想像していなかったようなことを私たちは普通にやっているのではないか、と思うんです。機械学習研究者なら、AI scientistが機械学習を自動化する、みたいなイメージがあります。でも知的労働ではどうでしょう。私はもうGoogle Cloudの契約までやらせている。そこまで行くと、私にとってはもうAGIみたいなものです。Google Cloud相手にやってくれるなら。ではその先に何があるのか。
私はたぶん、あなたがまだスクリプトを作れと明示的に言っている、というところが答えだと思います。まだあなたはかなり関与しているんです。確かに魔法っぽく感じる部分もあるでしょうが、製品を作る側の私から見ると、まだかなり手作業に見える。こんなにプロセスが残っているなら、もっとそこも取り除きたい、と思ってしまうんです。
どうやってさらに上のレイヤーへ上がり続けて、あなたの人生をどんどん簡単にしていけるか。それが次の問いです。
たとえば、こんなのはどうでしょう。私は自分のプライバシーなんてそこまで気にしない、Anthropicを信頼している。では、私の普段の一日の行動を全部見ていて、終わりに、何をClaude Co-workに任せられそうか教えてくれ、と。
そういうことですね。わかります。
面白いのは、私はキャリアを通して、自分が取り組んでいることをあまり事前に匂わせるのが好きではなかったことです。作って、出して、それから話せばいいと思っているからです。何をやっているのか曖昧に匂わせ続けるのは好きではありません。
でもおもしろいのは、今日ここまでの間に、お二人とも何度も、こういうのが必要だよね、という話をしてきて、それが本当に明白なことばかりだったということです。そうだよね、それは当然だよね、誰かがそこはやるべきだよね、というものばかりでした。
だから、今後co-workが出していくものも、たぶんお二人にとってそんなに驚きではないと思います。ああ、それは価値があるよね、それに取り組んでいるのは当然だよね、それは便利だよね、と感じるはずです。そして、そういうカテゴリーに入る機能ほど、私たちにとってはよいのだと思います。あまりに特殊すぎたり、理解しにくすぎたりするものを作らずに済むので。
汎用性を守るということ
その特殊化しすぎないことは本当に大事だと思います。汎用性を保てるし、視野が狭くなりすぎない。うまく言えませんが。
そうですね。まさにそうです。たとえば、Node.jsとReactとTanStackだけを使うアプリ向けのClaude Code、みたいなものを出したことは一度もありません。もしそれ以外ならダメ、みたいな。
そういうスタートアップは何社か知っていますけどね。
私はVCでも投資家でもないので、市場がどう向かうかを予測するのは難しいです。でも、私が興味を持っているビルディングブロックという観点では、Electronは私がこれまで作った中でも圧倒的に人気の出たものです。そしてElectron自体は非常に抽象化しやすく、汎用化しやすい。実際、本当にたくさんのアプリが上で動いています。どれほど多くのアプリが最終的にElectronを使うことになるか、私にも予測できませんでした。もっと言えば、それらのアプリが何をするのかを予測することは、さらに不可能でした。
Bloomが出たときのことを今でもよく覚えています。画面の隅に小さな丸でカメラ映像が出てくる。あれは賢いなと思った。
あれもElectronアプリでしたよね。
そうです。少なくともしばらくはそうでした。あるいは1Passwordにも面白いことがたくさんあります。私はそのレイヤーのスタックにかなり馴染みがあるので、ほかのエンジニアに助言するときも、最も投資価値があるのはその層だと思っています。そのレイヤーのツールはまだそこまでよくない。でも将来的なレバレッジが最も大きいのはそこなんです。
ElectronとChromiumの意味
Electronつながりで、ちょっと気になっていたことがあります。Tauriは見ましたか。
見ました。
どう思いますか。私の感覚では、基本的にはTauriをデフォルトにすべきで、Electronの完全な力が本当に必要なときだけElectronにすべきだと思うんですが。
この件については大きな見解があります。なぜ私たちはChromiumの完全なコピーをアプリの中に同梱しているのか。これはかなり直感に反しますよね。OSのWebViewを使えばずっと簡単だし、自分で抱え込まなくてよいじゃないか、と。答えは、もちろんその通りです。かつて私もそうしました。実際にOSのWebViewだけを使ったSlackアプリの版があったんです。
え、Slack appを始めたんですか。
チームの努力ですが、私はそこにいました。Slack appを作っていました。
それはすごいですね。まあ、Electronの人ならそうなりますよね。
でもこれは面白い点です。私がSlackに入った時点で、すでにMacGapというもので作られたアプリがありました。モバイルでいうsame appのようなもので、OSのWebViewだけを使っていた。でも、それはたくさんの理由でうまくいきませんでした。それで、もっと大きな武器が必要だ、レンダリングスタックをもっとしっかり握らないといけない、となったんです。
ここでいつも言うことはいくつかあります。小さいアプリなら、OSのWebViewで十分です。ユーザーが壊れたら大騒ぎするほどではないアプリでも大丈夫でしょう。独自のレンダリングエンジンを持つ理由は、そしてこれは2026年でもまだ真実ですが、OSのレンダリングエンジンがあまりよくないからなんです。単純にあまりよくない。MicrosoftもAppleもそこから離れようとしてはいますが、まだ本当にうまくはできていない。しかも、それらを更新する唯一の方法は、OSをアップグレードすることです。
だから、たとえばSlackのような立場で、WKWebViewやその他のWebViewに重大なレンダリングバグがあったとすると、あなたにできることは、すみません、最新のMacBookを買っていないあなたが悪いですね、とユーザーに言うことしかなくなる。でもそれは許されません。
ユーザーにとっても受け入れられないし、開発者にとっても受け入れられない。
だから、もっと下のレイヤーに降りて、最良のレンダリングエンジンを探して、それを自分のアプリに入れる必要があるんです。ではなぜChromiumなのか。サイズは大きいですが、Chromiumは圧倒的にいちばんよい。私はよく、Unreal EngineですらテキストをレンダリングするときにChromiumを使っているんだと人に言います。同じ目的で、ChromiumはUnreal Engineの一部にも入っているんです。それくらい、Chromiumは本当に優れています。私は工学上の驚異のひとつだと思っています。
今ここはサンフランシスコですが、この街の大半の人はWeb開発者です。だから余計に強調したいんですが、Chromiumがどれだけ魔法じみているかは、本当に言葉にしづらい。YouTube動画を再生し、ビットレートを動的に交渉し、あなたの壊れ気味のハードウェアドライバにどう対応するかまで処理している。
実は面白いことがあって、Chromeでchrome://gpuと打つと、下にたくさんenabled workaroundsが出るんです。つまり、何かがおかしいから回避策が有効になっている。これをあまり一般的ではないGPUを積んだWindowsマシンで見ると、もっとずっと長い。そして、そのほとんどは、私が開発者としてここに赤いピクセルを出したいと言ったときに、それが本当に赤いピクセルとして出るようにするために存在しています。
Chromeがすごいのは、ユーザーがどんなマシンを持ってきても、かなりの信頼性で動くことです。もし動かなければ、たぶん24時間以内に直ります。
つまり、これがスーパーOSなんですね。どこでも動く。
そうです。
なるほど。
Electronの魔法の多くは、まさにそのChromiumを、あなたのユースケースにぴったり合う形で非常に簡単に同梱できることにあります。
次のインタビューはMaren Dreeですね。彼は、デスクトップOSSなんて実際のOS、つまりChromeの出来の悪い実装みたいなものだ、と言っていました。そこが実際にアプリを出荷するプラットフォームだ、と。
面白いのは、エンジニアはよく、自分たちの下のレイヤーはすごく安定していると勝手に思い込むことです。でも実際にその人たちと話してみると、彼らもまた手探りでやっているだけだったりする。Slackのとき、顧客のひとつがNvidiaでした。しばらくの間、私はGPU開発者を頭の中でかなり神格化していました。チップを作り、ドライバを作るハードウェアエンジニアは、自分よりずっと難しい仕事をしているし、圧倒的にすごいに違いない、と。
でも、SlackでYouTube動画がうまく描画されず、変なアーティファクトが出るバグがひとつありました。結果的にはChromiumのバグで、大きなスレッドを追うことになり、たくさんのソースコードを見ることができたんです。すると、彼らもまた、なぜかわからないけれどこのビットを反転すると動く、みたいなことを普通に言っている。これはもう、スタックのあらゆるレイヤーで起きていることなんです。
年末のAGI予測としては、ClaudeがChromiumを作れるようになったら、ということになるんでしょうか。
今は笑っていますけど、いつかそうなるかもしれませんよ。
かなりよくなってきています。以前は完全に役に立たなかった。でも、Chrome repoの中で使われているツールがあまりに専門特化していて、長い間Claudeはそういうツールを再発明しがちでした。none of them were capable of handling Chrome、みたいな状態だったので。
私が待っているAGIの瞬間は、Electronがもう不要だと言えるのはいつか、というところです。つまり、完全にネイティブなアプリをSwiftyに作れるようになるとき。
Swiftで、ではなくSwiftyに、ですね。
そうです。今のモデルでも、Electronアプリを取ってきてSwiftに再現するくらいはかなりできます。でも、本当により高性能で、メモリ使用量も少なく、そういうものを作れるのか。そこには、開発者が長年やってきたような細かい最適化が全部入ってきます。まだそこまでは行っていません。現時点の最良モデルに対して、これをネイティブコードで完全に再現して、ミスなく、ultra thinkでやって、と言える段階ではまだない。
Ultra Think、今日は復活しましたね。
そうですね。何日も考えるようなthing for daysみたいな。
それ、ただのプロンプトなんですか。
そこには、もう少しいろいろあります。
マルチプレイヤーco-workの可能性
もうひとつ聞きたかったことがあります。co-workのマルチプレイヤーモードみたいなものです。subagentsはシングルプレイヤーでコンテキストを分割する仕組みですよね。でもマルチプレイヤーco-workというと、たとえば同僚のマシンにあるファイルについて知りたいとか、その人のタスク結果が自分の仕事にどう反映されるのか知りたいとか、そういうことです。それって興味深いテーマですか。あなたたちが作る意味のあるものなんでしょうか。
すごく興味深いです。これも、ある時点で消えていくかもしれないscaffoldingを私たちが作ることになるのか、という問題に戻ります。たとえば、いつこの存在たちに専用のGmailアカウントを割り当てて、Slackハンドルを持たせて、人間と同じツールで相互にやりとりさせるようになるのか、という問いです。
あなたが言っていたfinanceチームですが、彼らはとてもよいOffice統合にかなり力を入れてきました。そして、しばらくの間、ClaudeがGoogle docの中に有用なコメントを残せるようにたくさん技術を作ってきたんですが、今ではもう普通にコメントを残します。それがやりとりの方法になっている。
同じように、ここでも私はまだ、最良のインタラクションモードが何なのかについて答えを持っていません。co-workエージェント同士が話すための専用の仕組みを私たちが作るべきなのか。それとも、もう最終形に飛んでしまって、たとえば仕事でSlackを使っているなら、この存在にもSlackハンドルを与えて、それがマルチプレイヤー化の方法になるのか。
彼ら同士が通信するわけですね。
そうです。楽しいプロジェクトとして、私はpi qというものを作ったんですが、どんなrepoでも取ってきて、それをPiというコーディングエージェントに渡し、VPS上に置くんです。すると、誰でもpublic webhookからコーディングタスクを投げ込めて、ダッシュボード上でタスクをレビューできる。未来の組織では、営業の人がエンジニアリングチームと話し、そのチームがマーケティングやプロダクトチームと話し、そういうco-workたちが順番待ちの承認タスクを人に投げていくようになる気がしています。
面白いですね。
私は、そのときどういう形になるのかが気になるんです。自分のco-workerに、いちいち私に聞かずに承認タスクを作る権限をどう与えるのか。そして、どれを私がレビューすべきかをどう決めるのか。たとえば、色を変えるようなものはブランド判断に近い。一方で、ただ壊れているから直してくれというものもある。Claudeは、どのプロンプトが自分のしようとしていることに合っているかまで判断できる。
今はまだ、すべてが単一プレイヤーの中のマルチプレイヤーなんです。いくらでもインスタンスは立ち上げられる。でも、複数の人が、それぞれのコンテキストを使いながら、どう互いにタスクを受け渡すのか。そのあたりがまだよく見えていません。
そして、あなたたちのco-workers同士も、互いに話す必要がありますよね。
そうなんです。今日エピソードがあるよ、とか、そっちは進んでる、とか。
時間がなくなってきていますが、skills共有の話ともつながりますよね。たとえば、自分のco-workが、ほかのco-workersにこのタスク用のskillを持っているか聞きに行くようになったらどうだろう、と私は思います。
それはskill transferですね。
そうです。とはいえ、強力なものを作ることと、不気味なものを作ることは紙一重なんですよね。実際、同僚のエンジニアたちの反応を見る限り、これはおそらく私たちがやることではないだろうと思っています。
でも、たとえばBluetooth LEがあります。このコンピュータは、隣にあるコンピュータがすぐ近くにあると認識できる。なら、たぶん同じ作業をしているんでしょう。co-workにそういうものが出るかというと、たぶん出ないでしょう。でも、まだ試していない、すごく創造的な解決策はたくさんあると思います。
Anthropic Labsは何をしているのか
最後に、Anthropic Labsについて聞きたいです。私の頭の中では、モデルラボとエージェントラボがあるイメージで、これはAnthropic内部のエージェントラボなんじゃないかと思っています。Claude Codeが今その配下にあるわけですよね。組織全体の一部として。
人って本当に動き回るものなので、その見方がどれだけ正確かはわかりません。
でも実在するチームではあるんですよね。
実在するチームです。ただ、Labs teamは主に、まだ公開されていないものに取り組んでいます。本当に突飛で、実現しそうにないような、とても変わったアイデアを試しています。いわばmad scienceです。
では、あなたは公式にはそこに属しているんですか。
いいえ。Claude Codeは今やかなり大きなグループで、何人いるのか私も把握していません。昨日weekly cohort meetingに入ったとき、人が多いなあと驚いたくらいです。
ただ、lab teamはまだありますし、むしろかなり大きくなりました。MikeもICとしてLabs teamに入ったばかりで、それはとてもクールだし面白いことだと思います。彼らは、まだみなさんが見ていないものに取り組んでいます。本当に突飛で、おそらく半分壊れているようなものです。Labs streamの発想は、ほかの誰にもやる意味がないくらいおかしなものだけを扱うことなんです。
なるほど。そこから面白いものが出てくるのを楽しみにしています。今日は時間が来てしまいましたが、本当にありがとうございました。来てくれて感謝しています。Claude Co-workにも感謝しています。みなさん、ぜひ使ってみてください。今年いちばん、これってもうAGIなのではと思わせてくれたものです。
そう言っていただけるのは本当にうれしいです。ありがとうございます。
お時間ありがとうございました。
こちらこそ、ありがとうございました。
コメント