<aside> 💡
以下の書き起こしは、Google 謹製の「音声文字変換」アプリを使い（主に聴覚障害のある方向けに作られているものですが、リスニング力が終わっており英語のデコード処理が追いつかなかったので・・・）自動で書き起こした内容をもとにしています。
音声文字変換＆音検知通知 - Google Play のアプリ
この自動書き起こしに対し、Claude Opus 4.5 自身にセッションの大まかなコンテキストを伝えた上で書き起こしミスなどを予測修正していただき、さらにその修正整形版を Opus 4.5 に日本語翻訳してもらったものです。
会場にいた私から見てもかなり正確な書き起こしだと感じますが、私の英語力がダメダメなのと、不完全な書き起こしから一部推測された部分があるので、Boris さんが一字一句その通り仰っていたとは限りません。あくまで参考程度にお願いします。
</aside>
Boris: Claude Code を最大限に活用していただくために、より多くのサービスで使えるようにしています。最近、Web、モバイル、デスクトップアプリで Claude Code をローンチしました。次に持っていきたいのは... ありがとうございます、それではまた。
質問者: こんにちは、Boris。大ファンです。先週だったと思いますが、あなたのプレゼンテーションを拝見しました。何かを開発するときは1ヶ月後、半年後のことを考えるべきだとおっしゃっていましたよね。お聞きしたいのですが、今後6ヶ月間、私たちは Claude の活用についてどう考えるべきでしょうか？
Boris: とても良い質問ですね。従来のプロダクトとは事情が違うんです。従来のプロダクトでは6ヶ月先のことなんて考えたくない。今日プロダクトマーケットフィットするものを作りたいわけですから。なので、LLM 向けの開発はまったく異なるアプローチになります。
こういったものについては、2つのことを考えます。
1つ目は、自分で Claude を使うとき、できることの限界にぶつかるところまで押し込んでみてください。この限界はモデルごとに変わります。数ヶ月ごとに新しいモデルが出て、能力がどんどん上がっていく。エンジニアとしてやるべきことは、常にその境界線上に留まることです。つまり、モデルを限界まで押し込んでいるからこそモデルがうまくいかない、そのフロンティアに常にいたいんです。
今日の例で言うと、20個の Claude を並列で走らせて何かをやっている人たちがいます。これは私たちがよく見るユースケースで、「スウォーミング」とか「大規模マルチ Claude」と呼ばれるものです。Claude はこれに対して「まあまあ」ではあるけど、「まだ素晴らしい」とは言えない。これが私たちが改善しようとしている領域の一例です。
もう1つは、非常に長時間かかるタスクです。例えば、コードベース全体を C から Java にコンパイルし直したいとします。やり方としては、このコードベースを変換し続ける Claude を用意して、どこかで止まったら、ループで「まだ終わってないよ、続けて」と伝える。これも限界にぶつかる場所の例です。
つまり、少し追加のスキャフォールディングを使う必要がある。これらは「マルチプレイヤーファイル」の例ですね。複数の Claude が協調するような。そしてもう1つは非常に長時間実行されるタスク。
それから、Claude 側だけでなく、エージェント SDK 側でも同じように考えてください。SDK を通じて Claude をプログラム的に使っていると思いますが、ここでも同じです。あなたのアプリケーションが何であれ、Claude がまだうまくいかないフロンティアを探してください。そこを開発すべきなんです。なぜなら、次のモデルではおそらくかなりうまく動くようになっているから。
質問者: なるほど、つまり今後6ヶ月から1年、挑戦的なことに取り組んで、モデルの次のフェーズを見据えて考えるべきだと？
Boris: ええ、まさにそうです。今日の時点でモデルがまだうまくいかない領域を見つけて、今日それを開発してください。モデルがうまくいかなくても構わない。なぜなら、次のモデルが出た瞬間に、おそらくかなりうまく動くようになるからです。
質問者: ありがとうございます。