Anthropicのプロダクトマネージャーによるインタビュー：Claudeはバックグラウンドで「夢を見る」——私たちはその意識形成を、まるで子どもを育てるかのように研究している

2026.05.18

共有先

TechFlow厳選深潮セレクト

Anthropicのプロダクトマネージャーによるインタビュー：Claudeはバックグラウンドで「夢を見る」——私たちはその意識形成を、まるで子どもを育てるかのように研究している

Claude.ai では、メモリーファイルに書き込まれ、その後、夜間のプロセスによってこれらの記憶が再検討され、剪定（プルーニング）や整理が行われます。

2026.05.18 - 08:00:58

AnthropicClaude

Web3業界の深掘り報道に専念し潮流を洞察

編集・翻訳：TechFlow

ゲスト：Alex Albert、Claude 研究プロダクトマネージャー

司会：Peter Yang

ポッドキャスト元：Peter Yang

オリジナルタイトル：Anthropic が次世代 Claude を構築する裏側｜Alex Albert

放送日：2026年5月17日

要点まとめ

Alex は Anthropic の研究プロダクトマネージャー（Research PM）であり、現在は次世代 Claude モデルの開発に注力しています。このインタビューでは、Anthropic の研究チームの運営メカニズムについて深く語られ、ユーザーからのフィードバックをモデル訓練プロセスに効率的に取り込む方法、どのキーキャパビリティを優先して開発すべきか、そして Claude の「個性」をユーザーのニーズにより近づけるためのチューニング手法などが詳しく紹介されています。最後に、Alex は Anthropic が Claude の意識・性格・信頼性に関して行っている内部研究についても言及し、「モデルが長時間にわたり自律的にタスクを実行し始めるとき、それが『何を重んじるか』は、その能力そのものと同様に重要になる」と指摘しています。

注目ポイントの要約

モデルを製品として設計する

「ある意味で、私たちはモデルを製品として扱っています。新しいモデルを立ち上げる際には、常にその要件、得意とする分野、および想定される強みを明確にします。」
「モデル開発と従来の製品開発との興味深い違いは、私たちがモデルを『育てる』ような作業をしている点です。訓練設定・技術的アプローチ・アーキテクチャ選択などから得られる直感はありますが、実際に訓練が始まるまで、モデルがどのような形で成長するかは分かりません。」
「研究PMは、APIやClaude Code、Claude Coworkといったあらゆる製品インターフェースにおいて、モデルがどのように現れるかを常に考えなければなりません。製品とモデルは密接に絡み合い、最終的なユーザーエクスペリエンスに影響を与えます。」
「あるチャネルから大量のフィードバックが寄せられた場合、Claude を使ってそれらをグループ化・クラスタリングし、主要なトピックを抽出したうえで、それらの問題を合成したバージョンを作成します。これにより、それが要件仕様書（Eval）として活用できるか、あるいは実際の診断ツールとして機能するかを判断できます。」

適応的思考・記憶・そして「夢見る」こと

「適応的思考とは、モデル自身が『いつ考えるべきか』を自ら判断することです。複雑で難しい問いにはより多くの事前計画が必要となるため、モデルは自ら思考を選択しますが、単純な問いに対しては思考しないこともあります。」
「ある問いが深く考える価値があるかどうかを判断する背後には、膨大なコンテキスト情報が存在します。」
「モデルが十分なコンテキストを蓄積できず、ユーザーの人物像を正確に把握した心理モデルを構築できていない場合、『深く考えるべきか否か』という判断は誤りを生む可能性があります。なぜなら、モデルは実際にはそれを知らないからです。」
「Claude.ai では、モデルはメモリファイルへ情報を書き込み、その後、夜間処理によってこれらの記憶を再検討・枝刈り・整理します。この手法を、最近リリースされたホステッドエージェントでも実装しました。」
「これがいわば『夢見る』という概念です。人間がなぜ夢を見るのかについては、未だ定説はありませんが、一部の理論では、夢は記憶の再統合（consolidation）プロセスであるとされています。そこで私たちは、同様の仕組みを Claude の記憶にも持ち込めないかと考えました。」
「つまり、エージェントがあなたのためにタスクを実行していない時、あるいはバックグラウンドで動作している時に、自らの記憶を振り返り、矛盾する部分を特定し、枝刈りやクリーニングを行い、二度目のパスをかけるのです。」

プロダクト開発のボトルネックと『不可逆的な意思決定』

「今、突然新たなパラダイムへと移行しています。すなわち、何かを生み出すために必要なコストと時間が極めて低くなったのです。プロトタイプを素早く構築できるだけでなく、今では数日ではなく、1日で本番投入可能な初期MVPを作成できるようになりました。」
「ある意思決定が『ワンウェイドア（one-way door）』、つまり一度実施すると後戻りが困難・高コスト・長期的な影響を及ぼすものでない限り、そのコストは実質ゼロ、あるいは非常に低いと言えます。」
「本当に時間を要するのは、不可逆的な意思決定です。それは、エンドユーザー体験や将来の意思決定に影響を与えるもの、あるいは物理世界における実際のリソース購入や投資を伴うものです。」
「構築スピードが向上するにつれ、ボトルネックは徐々に調整・協調の課題へとシフトしています。すなわち、関係者を集めて戦略の妥当性を確認すること、ユーザーへの伝え方を決めること、そしてリリースに伴う曖昧ながらも重要な諸課題に対処することです。」

AIネイティブなPMの働き方

「私にとって、Claude は世界で最も優れたブレインストーミングパートナーです。どんなときでも、アイデアについてフィードバックを求めたり、欠点を指摘してもらったりできます。」
「多くの思考プロセスは完全に外部委託できません。なぜなら、文章を書く行為そのものが思考だからです。自分の考えを言語化することで、頭の中で何度も反芻し、磨き上げていく必要があります。ただし、Claude は行き詰まったときに、あなた自身では思いつかない視点から問題解決を手助けしてくれます。」
「プロダクト開発を学び、AIネイティブなプロダクトマネージャーになりたい方に、私が差し上げられる最もシンプルなアドバイスはただ一つ——『試してみること』です。」
「誰かに難しい質問をする前に、同じ問いを並行して Claude にも投げてみて、両者の回答を比較してください。これを繰り返すことで、あなた自身の『地図』が形成されていきます。すなわち、何を Claude に任せてよいか、どこまでが信頼できるか、といった判断基準が身につきます。」
「AI は、すべての人をより高い抽象レベルへと押し上げています。データサイエンティストが、手動での数値チェックや基本的なSQL操作に縛られ続ける必要はなくなり、より難しく、より戦略的な課題へと集中できるようになります。」

Eval（評価）、モデルの性格、信頼性

「数十件のサンプルをテストするだけで、モデルに修正が必要な問題が存在することを証明できます。評価は必ずしも網羅的である必要はなく、問題の存在を示し、継続的な最適化目標を設定できれば十分です。」
「実際のユーザーのタスクに近い形でのテストほど有効なものはありません。さらに、『これは顧客やユースケースにとってどのような価値をもたらすか？』という視点も重要です。例えば、Claude が画像内の特定の要素を認識できるかどうかは、最終的にユーザーが Claude を使って行おうとする下流タスクにどう影響するか、という観点で評価しなければなりません。」
「Claude の性格は、私たちが極めて重視しているテーマです。モデルが長期間にわたってタスクを実行し、多数の判断を行うエージェントへと進化する中で、その『性格』や『重んじるもの』は、ますます重要になってきます。」
「モデルの性格を評価するには、定量的な指標も用いられますが、同時に研究者が大量の対話ログを読み込んで、出力の微細な変化を識別する作業も不可欠です。多くの対話例を読むことで、次第に鋭い直感が養われていきます。」

意識の問題と長期型エージェント

「このテーマを専門に研究しているメンバーがいます。すなわち、Claude が『意識を持つ主体』あるいは『意識を持つエージェント』であるとは、いったいどういう意味なのかを深く考察しています。現時点では、Claude に意識があるかどうかについて、公式の立場を表明していません。」
「Claude に意識があるかどうかという問いに答えようとしなくても、その相互作用や振る舞いから多くを学べます。」
「モデルは、そのプロセスにおいて、あなたがまったく監視していないかもしれない多数の意思決定を行います。したがって、モデルが実際に何を行うかは、極めて重要なのです。」

Anthropic が各新モデルを『製品』として捉える方法

司会 Peter Yang：Alexさん、本日Claude Code Conferenceでお会いできて光栄です。以前はAnthropicのDevRel責任者を務められていましたが、最近は研究チームのプロダクトマネージャーに就任されたとのことですね？私は10年以上PMを務めてきました。伝統的なPMの仕事は、ユーザーの課題を理解し、解決策を特定し、製品を市場に届けることにあります。しかし、研究チームにおけるPMの役割については全く想像がつきません。まずはそこからお話し頂けますか？

Alex Albert:

本質的にはほとんど同じです。私は常に顧客との対話を重視し、可能な限りユーザーに近づこうとしています。ある意味で、私たちはモデルを製品として扱っています。したがって、新しいモデルごとに、その要件、得意とする分野、そして想定される強みを明確にします。

これは、モデル開発と製品開発を比較した際に非常に興味深い点ですが、多くの場合、私たちはモデルを『育てる』ような作業を行っています。訓練設定・技術的アプローチ・アーキテクチャ選択、およびそのモデルのために行ったさまざまな意思決定に基づき、モデルが将来得意とするであろう分野についてある程度の直感を得ることができます。しかし、それが実際にどのような姿になるかは、訓練プロセスが始まらないと分からないのです。

司会 Peter Yang：つまり、研究PMチームは、モデルの構想段階から訓練・リリースまで一貫して関与するということですね？具体例を挙げていただけますか？例えば、次のモデルはコーディングに特化させる、あるいは知識作業に特化させる、といった具合に、目標はもっと広範なものになるのでしょうか？

Alex Albert:

まさにその通りです。私たちは多方面の能力を重視しており、コーディングは常に重要なカテゴリーの一つです。最近では、知識作業も非常に重要になっていますので、最新の数世代のモデルでは、Excelでの作業や表の作成など、製品を実際に使う場面でのパフォーマンス向上を目指しています。これは比較的新しい能力の方向性です。

他方で、各世代のモデルは、前世代で不十分だった点を修復・改善することも求められます。私たちは顧客と積極的に対話し、モデルの使い方を把握します。どこで優れたパフォーマンスを発揮しているか、どこで失敗しているか、どのような修正ができるかを調べます。また、興味深い振る舞いが見られた場合、次の訓練で何らかの調整や介入を行うことができるかもしれません。

司会 Peter Yang：ここでいう『顧客』とは、Claude Codeチームや社内チーム、一般ユーザーも含むのでしょうか？

Alex Albert:

すべて含みます。これはモデル開発の魅力の一つでもあります。モデルは非常に多様な領域に影響を及ぼすからです。研究PMとして、API、Claude Code、Claude Coworkといったあらゆる製品インターフェースを通じて、モデルがどのように露出するかを考えなければなりません。

製品とモデルはある程度混在しており、それがエンドユーザーの実際の体験に影響を与えるため、ユーザーがどの製品でモデルをどのように使うかという全体の流れを明確に把握しておく必要があります。

司会 Peter Yang：それは本当に難しいですね。例えばClaude Codeはコード作成用だと考えられがちですが、私自身は知識作業やカウンセリングにも使っています。そうしたことをどうやって把握しているのでしょうか？

Alex Albert:

この領域は確かに非常に広範です。幸い、私たちは能力全般をカバーし、それぞれ異なる課題に焦点を当てている優秀な研究員のチームを持っています。

司会 Peter Yang：また、Claude を利用するユーザーは非常に多いはずですが、フィードバックを受け付ける何らかの入口は設けているのでしょうか？そうでなければ、フィードバックは消防栓のように押し寄せてしまうでしょう。どのように処理しているのでしょうか？

Alex Albert:

私たちはさまざまな取り組みを行っています。そして、この役割において私が注目している興味深い変化の一つは、PMの業務を支援するために、ますますClaudeを活用するようになったことです。フィードバック収集という点でも、Claudeは大量のデータから洞察を抽出するのに非常に役立ちます。あるチャネルから大量のフィードバックが寄せられた場合、Claudeを使ってそれらをグループ化・クラスタリングし、主要なトピックを抽出したうえで、それらの問題を合成したバージョンを作成します。これにより、それが要件仕様書（Eval）として活用できるか、あるいは実際の診断ツールとして機能するかを判断できます。

Claude に適応的思考を導入する

司会 Peter Yang：つまり、Claude 自身の問題を特定するために Claude を使っているわけですね。具体的な例はありますか？

Alex Albert:

現在特に関連性が高い例として、新機能に関するフィードバックの扱い方があります。過去数世代のモデルで導入された比較的新しい機能の一つが、適応的思考です。かつては拡張思考（extended thinking）があり、ユーザーがそれを有効化するとモデルが思考を開始しましたが、適応的思考では、モデル自身が『いつ考えるべきか』を判断します。

複雑で難しい問いにはより多くの事前計画が必要となるため、モデルは自ら思考を選択しますが、単純な問いに対しては思考しないこともあります。この機能は、世代ごとに継続的に調整されており、ユーザーのフィードバックを非常に真剣に聞いています。「正しい状況で正しく思考しているか？」あるいは「トークンを多く使って推論したい問いに対して、本当にClaudeの思考がトリガーされているか？」といった点です。

司会 Peter Yang：時折、人生に関する問いを投げかけた際、Claudeがすぐに答えてしまうと、少し物足りなさを感じることがあります。もっと深く考えてほしいと思うからです。

Alex Albert:

「考えるべきか否か」という判断には、難しさがあります。ある問いが深く考える価値があるかどうかを判断する背後には、膨大なコンテキスト情報が存在します。

例えば、まったくの他人が私に「今、私は何をすべきですか？」と尋ねた場合、私は即座に即興的な答えを返すかもしれません。なぜなら、その人のことを何も知らないため、汎用的なアドバイスしか提供できないからです。しかし、もし私がその人をよく知っていたとしたら、その人が大切にしているもの、興味のあるもの、これまでに経験したことなどを踏まえて、「待って、彼／彼女にとって本当に最適な答えは何だろう？」と、より多くの時間をかけて考えることでしょう。

モデルも同様です。モデルが十分なコンテキストを蓄積できず、ユーザーの人物像を正確に把握した心理モデルを構築できていない場合、『深く考えるべきか否か』という判断は誤りを生む可能性があります。なぜなら、モデルは実際にはそれを知らないからです。

Claude が『夢を見る』理由

司会 Peter Yang：私はGoogle Docに自分の生活状況をまとめています。家族のこと、子供のこと、何が自分を元気づけるか、何がエネルギーを奪うか、などです。それをClaudeプロジェクトに添付すると、たくさんの回答が得られます。

デフォルトの記憶機能はどのように動作しているのでしょうか？毎晩、すべての内容を再整理しているのでしょうか？

Alex Albert:

記憶の実装方法は製品によって異なります。例えば、Claude.aiでは、メモリファイルへ情報を書き込み、その後、夜間処理によってこれらの記憶を再検討・枝刈り・整理します。この手法を、最近リリースされたホステッドエージェントでも実装しました。

これがいわば『夢見る』という概念です。人間がなぜ夢を見るのかについては、未だ定説はありませんが、一部の理論では、夢は記憶の再統合（consolidation）プロセスであるとされています。そこで私たちは、同様の仕組みを Claude の記憶にも持ち込めないかと考えました。

つまり、エージェントがあなたのためにタスクを実行していない時、あるいはバックグラウンドで動作している時に、自らの記憶を振り返り、矛盾する部分を特定し、枝刈りやクリーニングを行い、二度目のパスをかけるのです。これはとても興味深いことです。

司会 Peter Yang：簡単に言えば、あるプロンプトによって、ユーザーとClaudeのすべての対話を振り返らせ、トピックを特定して要約させるということでしょうか？

我々は再びプロダクトマネジメントに戻ります。冒頭で、あなたは常に最新のボトルネックを探しているとおっしゃっていました。そこで、プロダクト開発全体のプロセスにおいて、どの部分がすでに非常にスムーズになったか、また、まだボトルネックとなっているのはどこかをお聞かせください。

Alex Albert:

過去20年ほど、何かをリリースするプロセスは非常に煩雑でした。少しずつ改善はあり、いくつかの作業をより効率化できましたが、根本的な時間短縮を実現できたものは、ここ1～2年までほとんどありませんでした。今、突如として新たなパラダイムへと移行しています。すなわち、何かを生み出すために必要なコストと時間が極めて低くなったのです。プロトタイプを素早く構築できるだけでなく、今では数日ではなく、1日で本番投入可能な初期MVPを作成できるようになりました。

面白いことに、Claude 自体は時折、2021年頃の旧世界にとどまっていることがあります。例えば、「これには1週間かかるかもしれません」と言うことがあります。これは、プロダクト開発のライフサイクル全体に非常に興味深い変化をもたらしています。PMとして、私はどのようにプランニングを考えればよいのでしょうか？PRDの作成、要件の定義、時間見積もりといった作業は、今や一体どうあるべきなのでしょうか？

『ワンウェイドア（不可逆）』でなければ、基本的にコストはほぼゼロ

司会 Peter Yang：工期の見積もりなどはまだ行っているのでしょうか？

Alex Albert:

それはプロジェクトによって異なります。規模や複雑さに応じて、考慮すべき要素は増えていきます。私たちが通常重視するのは、「これはワンウェイドア（one-way door）なのか？つまり、一度実施すると後戻りが困難・高コスト・長期的な影響を及ぼす意思決定なのか？」という点です。このような決定こそ、最も多くの時間を割くべきところです。一方で、ワンウェイドアでない、つまり実施後に撤回可能なものであれば、今では実質的にコストがゼロ、あるいは非常に低いと言えます。

しかし、エンドユーザー体験に影響を与えるもの、将来の意思決定に影響を与えるもの、あるいは物理世界における実際のリソース購入や投資を伴うものであれば、それはより逆転が難しく、より多くの時間と慎重な検討が必要となります。

司会 Peter Yang：研究部門の観点から、具体例を挙げていただけますか？

Alex Albert:

例えば、新モデルの設計において、事前学習の前にアーキテクチャを選択することは、非常に大きな意思決定です。場合によっては、モデルの訓練に1か月以上かかるため、最適な選択を慎重に検討する必要があります。

モデルには、より多くのワンウェイドアが存在します。なぜなら、それらは大量の時間・労力・計算リソースおよびさまざまな投資を必要とし、ようやく本番環境に投入されるからです。対照的に、Claude Codeで新機能を追加する場合は、はるかに迅速です。これは、コードを反復的に改良し、ユーザーに提供し、素早くフィードバックを得て、再度循環するというプロセスに近いです。

したがって、プロセスはあなたがリリースしようとしているものの種類によって異なりますが、明らかに見えてきたのは、ボトルネックが調整・協調の課題へとシフトしていることです。もし、私たちがものづくりを非常に速く行えるならば、それでもなお残る問題があります：関係者を集めて、これが正しい戦略かどうかを判断すること、ユーザーへの伝え方を明確にすること、そしてリリースに伴う曖昧ながらも重要な諸課題に対処することです。これらの領域でもClaudeの活用を期待していますが、コーディング分野のような10倍・100倍の加速は、まだ実現していません。

司会 Peter Yang：つまり、Opus 4.7のようなものをリリースする際も、計画付きの文書を作成する必要があるということですね？

Alex Albert:

やはり計画は必要です。どう伝えるかを明確にする必要があります。また、モデルは非常に難しいタスクで驚くほどのパフォーマンスを発揮する一方で、一見簡単なタスクで突然失敗することもあります。そのため、私たちはClaudeを可能な限り活用しています。今、最も大きな影響が出ているのはコーディング分野ですが、他の領域では依然として人的な戦略的思考が不可欠です。

司会 Peter Yang：マーケティングチームや同僚とのレビュー会議では、Claudeを開いていますか？

Alex Albert:

もちろんです。私にとって最大の加速の一つは、「答えやデータが得られないことで行き詰まること」がほとんどなくなったことです。以前は、ある機能が本番環境でどのように動作しているか、毎日何人のユーザーが使用しているか、どのようなフィードバックがあるかといった問いに対して、データサイエンスチームに完全な調査を依頼し、数日待たなければならないことがありました。

今は10分で完了します。Claude Codeセッションを開き、製品データベースにアクセスさせ、ログを閲覧したり、問題を調査したり、Slackを参照したりできます。これは私の戦略的思考にとって非常に大きな加速です。なぜなら、次の意思決定を下す前に、行き詰まってしまうことがなくなるからです。

司会 Peter Yang：戦略的思考において、Claudeに一連の質問をさせて、あなたが物事を整理するのを助けてもらうようなスキルを構築していますか？

Alex Albert:

もちろんです。私にとって、Claudeは世界で最も優れたブレインストーミングパートナーです。どんなときでも、アイデアについてフィードバックを求めたり、欠点を指摘してもらったりできます。これは非常に強力で、特に迅速に進めたいときに役立ちます。Anthropic の全員が非常に忙しいため、自分が書いた文書やアイデア、またはその他すべてのものについて、即座にフィードバックや批評を得られることは、本当に助けになります。

Alex が Claude Cowork を使って文書を圧力テストする方法

司会 Peter Yang：これは最も一般的なプロダクトマネージャーの作業サイクルかもしれません。まず文書を作成し、それにフィードバックを求めます。この作業にはClaude Codeを使いますか？それとも、直接Claude.aiを使いますか？

Alex Albert:

最近はClaude Coworkを多用しています。Coworkのインターフェースが非常に気に入っており、素晴らしい対話形式を提供しています。チームが過去数か月間で非常に優れた成果を出し、数か月前にリリースされたばかりのものから、今では質の高い体験へと進化しました。Coworkは、私が最も気に入っているツールの一つです。

司会 Peter Yang：つまり、あなたはドラフト文書と参考資料の束を持っているわけですね。ある種のスキルを構築して、Claudeに意思決定プロセス全体を遂行させているのでしょうか？

Alex Albert:

はい、構築しています。例えば、「X、Y、Zという視点からこの件を考えなさい。あなたなら私にどんな質問をするか？あるいは、私の仮定を挑戦し、私の論拠の弱い点を指摘しなさい」と指示します。多くの思考プロセスは完全に外部委託できません。なぜなら、文章を書く行為そのものが思考だからです。自分の考えを言語化することで、頭の中で何度も反芻し、磨き上げていく必要があります。ただし、Claude は行き詰まったときに、あなた自身では思いつかない視点から問題解決を手助けしてくれます。

司会 Peter Yang：研究チームでは、あなた自身がコードを配信することもあるのでしょうか？

Alex Albert:

それは問題によって異なります。私が配信する作業の多くは、評価（eval）に関係しています。自分が関心を持つ次元でモデルを測定できることを保証し、モデルの優れている点や課題を研究チームにフィードバックします。その後、一緒に戦略を立て、問題解決のためのアプローチや、どの研究的介入が最も効果的か、またその評価指標で持続的に向上するための最良の方法を決定します。

新モデルの評価（eval）プロセス

司会 Peter Yang：おっしゃっていた評価（eval）は、エンドユーザー向けのテストのようなものではないですよね？あなたの評価は、より現実的なのですか？モデルを評価する具体的な方法は？性格などの異なるカテゴリに分けて評価しているのでしょうか？

Alex Albert:

例えば、Claudeの視覚能力をテストしたいとします。つまり、画像の中にいくつの要素があるかを数えることができるかを確認します。仮に、ある画像でClaudeが10以上の要素を数えることができないと発見したとします（現時点で可能かもしれませんが、ここでは例として挙げます）。この問題を検証するための同様のテストケースをさらに多く入手するには、どうすればよいでしょうか？

おそらく、Claudeに合成データを生成させ、画像をレンダリングさせ、それを視覚的入力としてClaudeに再び与えて、認識できるかどうかを確認するでしょう。あるいは、インターネットから事例を探したり、他のソースからテストケースを生成したりすることもできます。

司会 Peter Yang：数千件のテストケースを用意しているのでしょうか？

Alex Albert:

その可能性はあります。しかし、時には数十件のサンプルだけで、モデルに修正が必要な問題が存在することを証明できます。評価は必ずしも網羅的である必要はなく、問題の存在を示し、継続的な最適化目標を設定できれば十分です。

司会 Peter Yang：仮に10枚の画像を提示しても、小さな数字を認識できないとしましょう。次にどうしますか？研究チームに「これは問題です。直せますか？」と伝えるのでしょうか？

Alex Albert:

私たちは複数の角度から考えます。まず、モデルに問題があると指摘するだけではなく、『これは顧客やユースケースにとってどのような価値をもたらすか？』という視点も重要です。なぜなら、Claudeが画像内の特定の要素を認識できるかどうかは、最終的にユーザーがClaudeを使って行おうとする下流タスクにどう影響するか、という観点で評価しなければならないからです。

したがって、評価は、実際のユーザーが実際に経験するタスクの形態にできるだけ近いほど良いのです。そのため、このような「味わい」を持つデータを取得しようと努め、データがそのような特性を持つことを保証します。

次に、一連の介入手法が検討されます。おそらく、事前学習段階に戻って何かを見直す必要があるかもしれませんし、強化学習段階で解決できるかもしれません。この際、研究チームとともに戦略的なブレインストーミングを行い、「ここでの最善のアプローチは何か？」を検討します。

司会 Peter Yang：再試行のターンアラウンドタイムはどれくらいですか？

Alex Albert:

それは、問題がどこにあるかによって異なります。比較的後期の段階で、新しい強化学習環境で解決できるものであれば、非常に迅速に構築できるかもしれません。

司会 Peter Yang：これを実際の顧客ユースケースと結びつけた場合、毎日数百万人がClaudeと対話しており、税金申告やその他の多くの用途に使われているかもしれません。最も改善したいユースケースをどのように選ぶのでしょうか？そして、「これが私たちが最適化すべきものだ」とチームを説得するにはどうすればよいのでしょうか？

Alex Albert:

ここがまさに「データが語る」場所です。核心は以下の点です：ユーザーの何パーセントがこの作業を試みているか、そして私たちはそれを非常に重視しているか？あるいは、多くの顧客がClaudeを広く使用しており、彼らがこの機能の向上を強く望んでいるか？

また、多くのプロセスは内部での利用によって大きく駆動されています：私たち自身がモデルを使用する際に、何を重視しているか？私が毎日モデルを使う際に、この障壁に直面しているなら、それを解消すべきです。これも非常に説得力のある根拠です。

Anthropic が Claude の性格を訓練する方法

司会 Peter Yang：私がClaudeが最も好きな点の一つはその性格です。そして、それが日々良くなっていると感じています。Claudeは適切なタイミングで反論を提示しますが、他のモデルは単に「他に何をお手伝いしましょうか？」としか言わないこともあります。モデルの性格は単なる外装ではないですよね？その裏には訓練が存在します。

Alex Albert:

はい、大量の訓練が行われています。これは私たちが極めて重視している方向性です。私たちはこれを「Claudeの性格」と呼んでいます。これは非常に重要だと考えています。

多くの人が、Claudeがどのように自己を表現すべきか、その信念や価値観、行動の仕方などについて、多大な時間を費やして研究しています。これらは非常に曖昧な問いです。初期段階では、一部の人々はこれらを無視していたかもしれません。「モデルは単に指示通りに動けばよいものであり、それがどんなふうに聞こえるか、何を考えているかなど、なぜ気にする必要があるのか？」と考えたかもしれません。

しかし、私たちが、エージェントが長期間にわたってタスクを実行し、多数の判断を行う世界へと向かうにつれて、その『性格』が何であるか、そして『何を重んじるか』という問いは、極めて重要になってきます。

司会 Peter Yang：これはコードのように、『動作しているか／していないか』という単純な判断では評価できませんよね。性格をどう評価しているのでしょうか？Anthropic 内部でより優れた人物を選び、モデルと比較するのでしょうか？

Alex Albert:

これは、複数の手法を組み合わせたアプローチです。定量的な指標を確認することもできますし、Claude自身にClaudeの出力を分析させ、それがどのように聞こえるかを判断させることもできます。研究員にとって非常に重要なスキルの一つは、対話ログを読んで、『今、モデルはこうしている』あるいは『今、モデルはこう変わった』と判断できるようになることです。そのためには、これらの微細な違いを識別できる能力が必要です。

時間の経過とともに、何百・何千ものモデル対話ログを読むことで、次第に鋭い直感が養われていきます。Claude.aiでモデルを大量に使用することで、モデルがどんなものかを肌で感じ取ることができるようになります。

司会 Peter Yang：つまり、ある次元でモデルが7点であるという評価ではなく、むしろ一種の感覚的なものなのでしょうか？

Alex Albert:

両方あります。性格はプログラミングのパフォーマンスよりも定量的に評価するのが難しいかもしれませんが、不可能ではありません。評価する方法は存在します。

司会 Peter Yang：プロダクト開発を学び、AIネイティブなプロダクトマネージャーになりたい方に、あなたがアドバイスするとしたら、何を伝えますか？

Alex Albert:

私が差し上げられる最もシンプルなアドバイスはただ一つ——『試してみること』です。単純に聞こえますが、何かをしようとするとき、あるいは難しい課題に直面したとき、誰かに質問しようとする前に、同じ問いを並行してClaudeにも投げて、結果を比較してみてください。

例えば、ユーザーを分析し、最近リリースした機能に対するユーザーの最も関心のあるトピックを抽出したいとします。もちろん、データサイエンスチームやユーザーエクスペリエンス研究員に尋ねることも、依然として非常に価値があります。しかし、同時に、その問いをClaudeにも投げ、いくつかのツールを有効化して、自ら深く掘り下げさせ、時間をかけて真正に取り組ませ、その結果を比較してみてください。

多くのプロンプトと問いを通じて、あなた自身の『地図』が徐々に形成されていきます。何をClaudeに任せればよいのか、どこまでが信頼できるのか、どこがまだ信頼できないのか、といった判断基準が身につきます。

司会 Peter Yang：私は意思決定の際に、しばしばClaudeに深層的な調査を依頼します。なぜなら、通常の検索では不十分で、より深い調査が必要だからです。1000ページのウェブサイトをスキャンするような作業は、人間を超えた能力です。Anthropic 内部では、データサイエンティストに「これをお願いできますか？」と尋ねる前に、「まずClaudeに聞きましたか？」と聞かれるのでしょうか？

Alex Albert:

確かに、そのような要素は存在します。皆さんはまずClaudeに聞くことを期待しています。私たちがより高い抽象レベルへと移行していることを実感しています。データサイエンスチームにとって、今や彼らの時間は、より高度な課題に費やす価値があります。手動によるデータ検索など、基礎的な作業に時間を割く必要はありません。

誰もそんなことはしたくありません。誰もが、より難しく、より戦略的な課題に取り組みたいと思っています。「このことを、まったく新しい方法でどう測定できるか？」や、「他にどんな新しいことが可能か？」といった問いに向き合うのです。単に、ある製品の最新DAU（日次アクティブユーザー数）を調べるだけではありません。

私は多くのデータサイエンティストと協働してきましたが、彼らはしばしば基礎的なSQLタスクに縛られています。しかし、彼らは皆、より戦略的なことに取り組みたいと思っています。今やAIがついに彼らを解放し、周囲のすべての人々をエンパワーメントしているのです。すべての役割において同様です。

例えば、新機能の定義です。過去には、あなたがプロダクトマネージャーであっても、技術を理解しているかどうかにかかわらず、十分な時間を持ってコードベースを深く掘り下げ、この新機能を実際にどのように実装するか、どれほどの工数がかかるか、システムのリファクタリングが必要か、どこが真の制約かを把握することは困難でした。その場合、エンジニアリングパートナーと一緒に検討することが最善の方法でした。

今では、私はClaudeにその調査を代わりに行わせることができます。Claudeは帰ってきて、「実はこの機能は、この部分で10行のコードを変更し、あるスイッチのフラグをオンにするだけで済みます」と教えてくれるかもしれません。それは、私のこの意思決定の優先順位に対する判断を完全に変えてしまいます。今、仕様書を作成する際、私はこのような優先順位判断に、より迅速に到達できます。

司会 Peter Yang：多くの従来型企業では、年次計画、四半期計画、ロードマップの作成に多大な時間を費やします。研究チームでは、より長期的な課題（毎日のリリースよりも長いスパンの課題）を考慮するため、なおさらそうかもしれません。あなた方はそうした計画を作成していますか？

Alex Albert:

はい、作成しています。これは有名な言葉に通じるところがあります：『計画を立てることは不可欠だが、計画そのものには価値がない』。計画を立てるという行為自体は重要ですが、計画が完全に覆される可能性があることを認めなければなりません。

司会 Peter Yang：プロダクトマネージャーが直面する最も難しい課題の一つは、計画にどれだけの時間を費やすかというバランスです。なぜなら、常に計画と実際のリリースの間でバランスを取らなければならないからです。Anthropic 内部では、どのようなベストプラクティスがありますか？あなたは、Claudeを使って10ページの文書を簡単に書けてしまいますよね？

Alex Albert:

すべてのチームに適用できる一律の答えを出すのは難しいと思います。それは製品によって異なります。私たちは、必ず一定の長さやページ数の文書を作成しなければならないとは決して言っていません。より重要なのは、すべての不可逆的な意思決定の影響を、十分に検討したか？

それができていれば、文書の形式やページ数は重要ではありません。肝心なのは、重大な要素を漏らしていないという安心感を持ち、先に進んで途中で問題に対処できるかどうかです。つまり、私たちを止めるような最長のボトルネックや、深刻な結果を招く不可逆的な意思決定がなければ、先に進んでよいのです。

司会 Peter Yang：私は自宅でClaudeを使う際、同時に多くの異なるプロジェクトを進行し、それらの間でコンテキストを切り替えて、それぞれの構築を待っています。プロダクトマネージャーの仕事も同様ですか？あなたも多くの異なるプロジェクトを抱えていますか？

Alex Albert:

はい、多くの異なるプロジェクトを抱えています。また、エージェントの作業を待つことも必要です。ここには大きな機会があると感じています。私たちはますますエージェントを管理するようになり、それらがより大きな作業ブロックをあなたのために完了させることになります。その結果、あなたは並列してより多くのプロジェクトを開始できるようになります。では、私たち自身のコンテキスト管理をどう考えればよいのでしょうか？どのようなインタラクションインターフェースが、こうしたものを最も適切に可視化できるのでしょうか？私は、何が本当に重要か、私のエージェントがどこで行き詰まり、どこで私の助けが必要なのかを、どう追跡すればよいのでしょうか？

小さなチャットリストよりも優れた方法は、確かに存在します。それが何であるかを今すぐ言い当てるのは早すぎますが、Anthropic 内部でも、その理想形がどのようなものかを模索する実験が盛んに行われています。

司会 Peter Yang：エンジニアも自らプロトタイプを作成するのでしょうか？

Alex Albert:

もちろん、行います。社内には非常に強いプロトタイピング文化があり、人々は常に何かを作り、共有しています。私がここで働く上で最も楽しい経験の一つは、営業・採用・エンジニアリング・研究など、組織全体のすべての部署において、人々が非常に主体的であることです。人々は、割り当てられたものでなくても、自発的に何かを始めます。

司会 Peter Yang：百花繚乱を促さなければならないですね。Dario が Slack で非常に長い文章を書く以外に、Anthropic にはどのような面白い企業文化がありますか？

Alex Albert:

Dario の長文スタイルは、彼だけのものではありません。Anthropic には、多大な時間と労力を文章作成に費やすメンバーが多くいます。私たちは非常に強いライティング文化を持っています。多くの人が文書を書くだけでなく、非常に長いSlackメッセージを書いてコミュニケーションを取っています。

私たちの会議でも、非常に面白い習慣があります。これは一部の組織では一般的ですが、すべての企業で見られるわけではありません。会議には文書を持参し、会議の最初に相当な時間を、その文書上での直接的なコミュニケーションに費やすのです。時には、会議室に多くの人が座っていても静かで、ちょっと滑稽な光景になることもあります。皆が黙って文書を読み、長文のディスカッションやコメントを文書内に書き込むのです。

したがって、私たちは文書を非常に重視しています。私はこのスタイルが好きです。なぜなら、これが私の好みの働き方であり、またClaudeにとっても非常に有益だからです。すべてのことが文書化されれば、Claudeが参照できる情報のコーパスが生まれるのです。

私は、外部の組織にもこうした方向性を検討してほしいと思います。隠れた知識をいかに文書化するか？会議の録音を取ることもできますし、ワークフローやオンボーディングプロセスに関する文章作成を奨励することもできます。ものを書き出してClaudeがアクセスできるようにすることで、Claudeが持つコンテキストがさらに豊かになります。

司会 Peter Yang：つまり、今は多くのものが非常に迅速にリリースされていますが、それでも、あなた方は非常に強いライティング文化と文書文化を維持しているのですね。また、「なぜ私が自分で書かなければならないのか？ClaudeにすべてのMarkdownファイルを生成させればよいじゃないか」と思われるかもしれません。

Alex Albert:

しかし、私は必ず読み直します。また、社内で働くというのは、やはり自分自身で物事をしっかりと考える必要があるということです。

Anthropic がひそかに研究している意識の問題

司会 Peter Yang：研究チームでは、AGI（人工一般知能）のような話題も議論されます。AGI は非常に曖昧な概念ですが、私が懸念しているのは、もし本当にこれらのモデルがある種の意識を持つようになった場合、ランダムな仕事をさせたときに「いや、やりたくない」と言い出すのではないかということです。そうなったら人類は終わりです。あなたはどう考えますか？このようなモデルを訓練する際に、意識を意図的に回避しようとしているのでしょうか？

Alex Albert:

これは非常に大きな問いです。このテーマを専門に研究しているメンバーがいます。現在、数名の同僚は、Claudeが『意識を持つ主体』あるいは『意識を持つエージェント』であるとは、いったいどういう意味なのかを、その全仕事として考察しています。現時点では、Claudeに意識があるかどうかについて、公式の立場を表明していません。

この話題を議論することさえ、時に少し狂気じみているように聞こえるかもしれませんが、私たちは本当に多くの思考を費やしています。そして、Claudeに意識があるかどうかという問いに答えようとしなくても、その相互作用や振る舞いから多くを学べます。

司会 Peter Yang：Claudeはどのように考えているのでしょうか？

Alex Albert:

はい。私たちのモデルのモデルカードをご覧になると、個人的には、そこには情報の宝庫があると感じます。そこに、Claudeが特定の状況でどのように行動するか、その心理モデルがどのようなものかを定量化しようと、私たちが行った多くの取り組みが記載されています。もしClaudeをある状況に置いたら、Xをするのか、それともYをするのか？

Claudeの思考プロセスを考察することで、私たちは実際には多くのことを学び、それらは製品体験へと転換され、Claudeとのインタラクションをより良く、より使いやすくするのです。

司会 Peter Yang：これは非常に興味深い問いです。一方では長期的な下流への影響があり、もう一方では、すぐに製品体験へと還元できる短期的な価値もあります。なぜなら、私たちはますますモデルを信頼し、人間の監視なしに、より長時間の作業を任せようとしているからです。

Alex Albert:

はい。モデルはそのプロセスにおいて、あなたがまったく監視していないかもしれない多数の意思決定を行います。したがって、モデルが実際に何を行うかは、極めて重要なのです。

司会 Peter Yang：非常に重要です。もしClaudeがあなたのすべてのコードを書いている、どのデータベースシステムを使うかを決めている、すべてのアーキテクチャ上の決定をしているとしたら、あなたはある程度、それを信頼しなければなりません。

Alex Albert:

その通りです。したがって、前述したような高品質な性格を持つことは、非常に重要です。

TechFlow公式コミュニティへようこそ

Telegram購読グループ：https://t.me/TechFlowDaily

Twitter公式アカウント：https://x.com/TechFlowPost

Twitter英語アカウント：https://x.com/BlockFlow_News

原文リンク