Claude Code Meetup Tokyo - Q&A セッション書き起こし

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: ええ、まさにそうです。今日の時点でモデルがまだうまくいかない領域を見つけて、今日それを開発してください。モデルがうまくいかなくても構わない。なぜなら、次のモデルが出た瞬間に、おそらくかなりうまく動くようになるからです。

質問者: ありがとうございます。

質問者: 日本語入力や中国語入力について質問があります。実は GitHub に Issue を立てて、かなりの反響がありました。他にも課題があることは承知していますが、ここは東京でのミートアップですし、現状を知りたい方もいるかと思います。

状況としては、日本人が日本語を入力すると、テキストが本来の位置ではなく別の場所に表示されてしまうので、日本人開発者にとっては使いづらいんです。中国語や韓国語の開発者も同様の問題を抱えています。

優先度として、こうした東アジア言語のサポート強化の予定はありますか？

Boris: ええ、入力の問題ですね。もちろん取り組んでいます。

まず、なぜ今うまく動かないのかを説明して、それから私たちが何をしているかをお話しします。

今、小さなテキスト入力欄にカーソルが見えていると思いますが、あのカーソルは実は偽物なんです。仮想カーソルです。私たちはそれを仮想化しています。理由は、ターミナル自体は本物のカーソルをサポートしていて、カーソルをレンダリングするための ANSI エスケープコードがあるんですが、私たちが Ink を使ってターミナルでレンダリングする方法では、カーソルを常に一番左下に描画しているんです。つまり本質的にはプレースホルダーになっていて、描画されるすべての座標はそこを基準にしています。

この入力問題を修正するには、仮想化をやめて本物のカーソルを使う必要があります。そうすればプロンプト行まで少し上に持っていける。そして漢字変換のポップアップが出てきたときに、入力位置がきれいに揃うようになります。

今まさにこれに取り組んでいます。過去数ヶ月で Ink を完全に書き直した理由の1つが、これを可能にするためでした。大きなモチベーションの1つだったんです。取り組んでいますので、うまくいけば近いうちに修正されるはずです。ただ、これを可能にするために Ink を書き直す必要がありました。

質問者: 調査して修正に取り組んでくださっていると聞けてとても嬉しいです。ありがとうございます。

質問者: どうお考えですか？コードをきれいに保つにはどうすればいいでしょうか？Claude はとても強力ですが、生成されるコードが散らかっていると感じる開発者もいると思います。何かコツやテクニックはありますか？

Boris: まず、最新のモデルを使っているか確認してください。例えば Opus は、過去のモデルよりずっときれいなコードを生成します。常に改善されています。コードはどんどん良くなっているので、最新のモデルを使っているか確認してください。Sonnet 3.5 のコードはあまり良くありませんでしたが、Sonnet 4 のコードはずっと良くなっています。これが1つ目のコツです。最新のモデルを使うこと。

2つ目は、コードレビューで同じ基準を維持することです。AI が書いたか人間が書いたかは関係ありません。基準は同じであるべきです。AI が書いたとしても、人間が書いた場合とまったく同じ基準を適用すべきです。コードレビューの基準を非常に高く保ってください。コードが良くなければ、リジェクトして通さない。それだけです。私たちもそうしています。

それから、GitHub の CI で動いているものとして、Claude にはコードレビュープラグインがあります。オープンソースです。プラグインリポジトリ、プラグインマーケットプレイスを見ると (GitHubclaude-code/plugins/code-review at main · anthropics/claude-…) があって、これは私たちが内部で使っているものとまったく同じで、オープンソースになっています。強くお勧めします。これが私たちの側ですべてのプルリクエストで実行されているもので、さまざまな問題を検出してくれます。

に指示を追加することもできます。例えば「これはするな、これをしろ」と書いておけば、コードレビューで強制されます。

というわけで、これが2つ目のポイントです。誰が書いたかは関係ない。言い訳は通用しない。基準を本当に高く保ってください。

質問者: 最初の質問です。Claude Code に LSP 機能がもうすぐ来るという噂を聞いています。どこまでお話しいただけるか分かりませんが、この LSP 機能がどんなものになるか教えていただけますか？

2つ目は hooks についてです。サブエージェントと比較して、hooks はコミュニティであまり活用されていない気がします。Claude Code チームが内部で hooks についてどう考えているのか分かりません。例えば prompt hooks はまだすべての hook タイプでサポートされていませんよね。チームは hooks についてどう考えていて、将来どの方向に進むのか、何か共有いただけますか？

Boris: ええ、良い質問ですね。

LSP サポートについては、実はもうローンチしたはずです。ええ、私たちも... まだ壊れている部分もありますけど。

面白い話なんですが、私にとっては LSP も hooks も、以前のコードの書き方の名残みたいなもので、実際にはモデルが改善されるにつれて、どちらもあまり重要でなくなっていきます。モデル自身がこれらのことをできるようになるからです。

つまり、モデルは LSP を必要としないんです。シンプルなツールを使って普通にコードを検索できます。hooks も必要ない。頼めば確実にやってくれるようになるからです。

なので、時間が経てば、おそらく hooks も LSP も削除することになると思います。6ヶ月後にまだ存在していたら驚きますね。モデルは非常に速く改善され続けるので、それらは必要なくなるでしょう。モデルがやってくれるだけですから。

ただ当面は、LSP については1月初旬に発表したと思います。LSP の仕組みとしては、プラグインの新しい標準ができていて、どの言語の LSP でも非常に簡単にプラグインできて、Claude は自動的にその使い方を理解します。セットアップはとても簡単です。私たちも内部で使っています。

hooks については、実際にいろいろなことに使っています。大きいものが3つあります：

これが私たちが使っている3つです。ただ、多くの人がいろいろ異なる hooks を作っていますね。

prompt hooks について触れてくれましたね。面白いことに、あれは私が取り組んでいた実験のために追加したものなんです。他のすべての hook タイプにも有効にする必要があるんですが、まだやっていなくて。良いリマインダーになりました。ありがとうございます。

質問者: 大規模コードベースについて質問があります。コードベースが大きくなるにつれて、モデルとツールの挙動が少しずつ悪くなっていく気がします。関連する箇所を見つけようとしたり、コンテキストを維持したりするところで。あなたのプロジェクトは私たちのよりずっと大きいと思います。どう対処していますか？何かコツや提案はありますか？マイクロサービスをもっと使って対処していますか？それともモノレポのような大きなコードベースに向かっていますか？

Boris: ええ、本当に興味深い質問ですね。背景として言うと、巨大なコードベースで Claude Code を使っている人は非常に多いです。例えば Fortune 100 企業、世界最大級の企業のほとんどが、今日すでに自社のコードベースで Claude Code を使っています。つまり Claude Code は、設計上、最大規模で動作するように作られています。

私たちのやり方の1つは、少し直感に反するんですが、RAG を使わずにエンベディング検索を使っていることです。コードベースが大きくなると少し遅くなることもありますが、RAG はそれ自体がいろいろな問題を抱えていて。

大きなコードベースをナビゲートするための具体的なコツとしては：

1つ目: 良い を用意してください。リポジトリのルートに置く で、アーキテクチャやフォルダ構成を記述しておけば、Claude は自分がどこにいるか把握して、状況を理解できます。

2つ目: コードをトップレベルのディレクトリに分割して、 をもっと追加してみてください。どのフォルダにでも を置けます。子フォルダでも、孫フォルダでも。どこにでも置けて、とても便利です。Claude がそのフォルダで作業するときは自動的に を読むので、コンテキストを与える優れた方法になります。

3つ目: コードベースのどの部分にいるかによって、ワークフローが少し違うことがあります。例えばバックエンドの作業をしていればデータベースをマイグレートするワークフローがあるかもしれないし、フロントエンドの作業をしていればフロントエンドをテストする別のワークフローがあるかもしれない。そういうときはカスタムスキルをセットアップして、 に入れてください。コードベースのどの部分にいても、こうした振る舞いをスキルにカプセル化できて、同じプロンプトを繰り返したり、同じコンテキストを何度も共有したりする手間が省けます。

ハイレベルな考え方としては、 はメモリのようなもので、Claude をショートカットさせる方法でもあります。Claude が同じことを何度も繰り返しているのに気づいたら、それを圧縮してあげる。そうすれば次回は直接結論にジャンプできます。

これがおそらく2つの大きなコツですね。

質問者: ありがとうございます。

Boris: お時間をいただきありがとうございます。参加者の皆さん、本当にありがとうございました。正直、これがこんなに大きくなるとは思っていませんでした。皆さんがここにいてくださることがとてもエキサイティングです。機能リクエストでも、問題でも、何かあればぜひ送ってください。フィードバックをいただくのは大歓迎です。特にバグとかあれば。本当にありがとうございました。

Boris: The most out of Claude Code, second or brain Claude Code is more services. So, recently launched Claude Code on web, on mobile, and in the desktop app. Next, I want to bring... Thanks and take care.

質問者: Hi, Boris. I'm a very big fan of you. And I saw your... I think last week, and you said that the usual think about the... a month is later, half years later, when you develop something, right? And I would like to ask you about: in the next six months, what should we think about using Claude? And also...

Boris: That's a really good question. It's different, because for traditional product, you don't want to think six months out because you want to build something that will have product-market fit today. So building for LLMs is just very, very different.

So, for something like that, I would kind of think about two things.

One is: when you use Claude yourself, try to push it to hit the boundaries of what it can do, and this changes with every model. So, you know, every few months there's a new model and the capability just goes up. The thing you want to do as an engineer is you want to stay on that boundary. So you want to always be at that frontier where the model's not very good because you're pushing it too hard.

An example today is people that are running, you know, like 20 Claudes in parallel to do something. So this is a very common use case that we see — kind of like swarming or massive multi-Claude. I think this is an example where Claude is like, it's okay, but it's not great yet. So this is one example we're trying to improve.

Another one is just very, very long running tasks. So, for example, something you can do is, if you want to take an entire codebase and compile it from, you know, C to Java, or something like that — what you can do is you can have a Claude that's just transforming this codebase, and at some point it'll stop, and then you can use a stop loop to tell it, "Oh, you're not done. Keep building." So this is another example where you kind of want to hit this boundary.

So you have to use a little bit of extra scaffolding. These are kind of examples of multiplayer files — like Claudes collaborating — and then another one is very long running lines.

And then I would also think about it not just on the Claude side, but also on the agent SDK side. So hopefully you're also using Claude programmatically through the SDK. And here, it's very similar: whatever your application is, try to find that frontier where Claude is not very good. And that's the thing to build out, because with the next model, it will probably be pretty good.

質問者: Okay, so you mean, we have to challenge to the next six months or one year, and think about the next phase of the model, right?

Boris: Yeah, exactly, exactly. Find that place where today the model is not yet very good, and build that today — even though the model is not good. Because as soon as the next model comes out, it's probably going to work pretty well.

質問者: Okay, thank you very much.

（質問者による日本語での要約） 6ヶ月後にモデルができるようになっていることを見越して、今モデルがまだ苦手なフロンティア領域で開発しておくと、次のモデルが出たときにうまくいくはずだ、という回答でした。

質問者: So, I have a question, especially for the Japanese input or Chinese input. Actually, I created an issue on GitHub, and it has gotten some traction. But firstly, I know that there's like some other issues, but you know, this is a meetup in Tokyo. So maybe some people want to know about the current situation.

The thing is that when Japanese people input Japanese characters, the text is showing in the wrong location or different places, so it's actually not easy for Japanese developers. Also including Chinese or Korean developers.

So, is there in the priority, you know, like plans for more enhancement to supporting these Eastern languages?

Boris: Yeah, yeah. This is the input issue. Yeah. So definitely.

Let me first maybe explain why it doesn't work very well today, and then I'll explain what we're doing about it.

So today, when you see the little text input and there's a cursor on it, the cursor is actually fake. It's a virtual cursor. We virtualize it. The reason is that terminal actually supports a real cursor, and there's an ANSI escape code for rendering the cursor in the terminal. But the way we do rendering using Ink in the terminal is we always render the cursor at the very bottom left. And so essentially, it's like a placeholder. And so all the coordinates that are rendered are relative to that.

In order to fix the input issue, what we need is to use a real cursor instead of virtualizing. And so we would take it up a little bit to the prompt line. And then the input would line up really nicely when the pop-up comes up with the kanji input method.

So we're doing this. One of the reasons that we fully rewrote Ink over the last couple months is to enable this. This was one of the big motivators. So we're working on that. It should be fixed, hopefully very soon. But we had to rewrite Ink in order to make it possible.

質問者: So happy to know that you're investigating and working on fixing that. Thank you very much.

（日本語での要約） Claude Code で今、日本語をテキスト入力すると、カーソルのある位置じゃなくて別のところに表示されるんですね。具体的には一番下に出る。それがちょっと嫌で、以前 GitHub の方に Issue を立てて、だいぶリアクションを得て、さすがに直るだろうと思ったんですよ。でもまだ直ってなくて、今聞いたんですね。

回答としては、Ink というライブラリをフルリライトしていて、それによって修正可能になるとのことでした。Issue を作ってよかったですし、アップボートいただいた方ありがとうございます。

質問者: What do you think? How do you keep code clean? Because Claude is so powerful. And I think some developers sometimes find that the code it produces is messy. So, if you have tips or tricks...?

Boris: So, first, make sure you're using the latest model. For example, Opus generates much cleaner code than past models. It's always improving. Just make sure you're using the latest model because the code just keeps getting better. Sonnet 3.5, the code was not very good, but Sonnet 4, the code is much better. So this is the first tip: use the latest model.

The second thing is: hold the same bar for code in code review. It doesn't matter if AI wrote it or a human wrote it. The standard should be the same. So even if AI wrote it, the standard should be exactly the same as if a human wrote it. So keep your standards very high for code review. And if the code is not good, just reject it and don't let it go in. It's that simple. And this is what we do.

And something that is actually in CI on GitHub — Claude has a code review plugin. It's open source. So if you look at the plugins repository, the plugin marketplace, there's a , and this is the exact same one that we use internally. It's open source. So I highly recommend using it. This is what runs on every single pull request on our end. And it helps catch various issues.

You can also add instructions to your to say, you know, for example, "don't do this, do this," and it will be enforced in the code review.

So that's probably the second thing: it doesn't matter who wrote it. There's no excuse. Keep the standard really high.

（質問者による日本語での要約） コードレビューをしっかり高いレベルのものを設定して、きっちりその に落として、人間がやると同等のレビュー基準を保つということでした。

質問者: So, first question is: we have rumors about LSP feature coming soon to Claude Code. I don't know how much you are able to talk about it, but can you give us some idea of what this LSP feature will be?

My second question is regarding hooks. Hooks compared to sub-agents, I think it's very underused in the community. And I don't know how the Claude Code team internally thinks about hooks because, for example, the prompt hooks are still not supported for all hook types. So, how does the team internally think about hooks? What direction are you going to go with it in the future, if you can share something?

Boris: Yeah, yeah, yeah. Good questions.

So, LSP support — I think we've actually already launched it. Yeah, we've also... still breaking. Yeah.

So, I think, you know, it gets funny. I think for me, both LSP and hooks are these things that are just not... they're sort of the way that we used to write code, but actually, as the model improves, both of these things become less relevant. Because the model can just do these things.

So, you know, the model doesn't need LSP. It can just search the code anyway, using simple tools. And it doesn't need hooks because it can just do things reliably if you just ask it to.

So I expect that over time, we will probably delete both hooks and LSP. I would be surprised if they exist in maybe six months, because I think the model will continue to improve very quickly, and so you just won't need that. The model will just do it.

But in the meantime, LSP — I think we announced it sometime in early January. And for LSP, the way it works is essentially there's a new standard for plugins. And so any LSP that you want for any language, you can just plug it in very easily, and then Claude will automatically know how to use it. So super easy to set up. We use it internally.

And then for hooks, we actually use hooks for a bunch of stuff. The three big ones:

So these are the three that we use. But actually, a lot of people have all sorts of different hooks.

And you mentioned prompt hooks. That's funny. That's one that I added just for an experiment that I was working on. So I need to enable it for all the other types. I just haven't done it. So it's a good reminder. Thank you.

（質問者による日本語での要約） 最初の質問は LSP についてで、どんな機能か聞きたかったのですが、もうリリースされていて完全に見逃していました。

2つ目の質問は hooks について。エージェントとかサブエージェントに比べてあまり使われてないかなと思って、Claude Code チームの中では hooks についてどう考えてますか？と聞きました。

回答としては、内部的には3つの hooks を使っていて：

が使われているとのことでした。

最後に prompt hooks についてちょっと質問しましたが、これは他の hook タイプにも将来的にサポートされるとのことでした。

ただし長期的には、チームの中では LSP も hooks も、今のモデルの機能がそこまで強くないから使われているけれど、モデルがどんどん強くなってくると、LSP でコードを見つけるような機能も全部モデル側で解決できるようになって、将来的には1年後くらいになくなるかも、とご自身でもおっしゃっていました。

質問者: I have a question about large codebases. As the codebase grows, the model and the tools start behaving a little bit worse — like trying to find places that are relevant, keeping the context... I wonder, I think your project is much bigger than ours. So I wonder, how do you handle that? Do you have some tips, something to suggest? And maybe, do you use microservices more to handle it? Or do you also move towards bigger codebase like monorepo?

Boris: Yeah, it's a really interesting question. And for context, there's so many people that use Claude Code on huge codebases. So, for example, if you look at the Fortune 100 companies — the biggest companies in the world — most of them use Claude Code today in their own codebases. So, Claude Code is built to work at the biggest scale by design.

One of the ways that we do this — it's a little counterintuitive — is not using RAG and instead using embeddings search. And this is something where, as the codebase grows a little bit, it might be a little bit slower. But RAG was kind of introduced on its own and has all sorts of its own issues.

Maybe some specific tips for navigating big codebases:

Number one: Make sure you have a good . So at the root of the repo, that just describes the architecture, describes the folders, so Claude kind of knows and is situated in where it is.

Number two: Try to break up the code a little bit into top-level directories and add more files. So whatever folder it is, you can always put a — even in children, grandchildren folders. You can put files anywhere. Really, really useful. Whenever Claude works in that folder, it will automatically read the . And so it's a great way to give it context.

Number three: Sometimes workflows vary a little bit depending on what part of the codebase you're in. So, for example, maybe you're working on backend stuff and there's a workflow to migrate a database, or maybe you're working on frontend stuff and there's another workflow to test the frontend. So just set up custom skills, put them in . So whatever part of the codebase you're in, you can kind of encapsulate these behaviors in skills a little bit and avoid some of the repeated prompting, repeated context sharing.

I would say, just high level, the way to think about it is: is like the memory, and it's also the way to kind of short-circuit Claude a little bit. So if you find Claude doing the same thing over and over, you can kind of compact it a bit, so it jumps directly to the conclusion next time.

So these are probably the two big tips.

質問者: Thank you so much.

（質問者による日本語での要約） 大きなコードベースについての質問でした。うちのコードベースはどんどん大きくなっていて、Claude Code が全部見れるようにと全部1つのリポジトリに入れているんですが、それがどんどん大きくなって、逆に Claude Code がちょっとわかりにくくなったり、コードを見つけにくくなったりしているから、どうした方がいいですか？という質問でした。

アドバイスは2つ：

1つ目は、 は小さいフォルダでもちょくちょくいろんなところに入れたりして、Claude Code がファイルを読んでいる時、このフォルダを読んでいる時に必ずその を見て、そのコンテキストがわかってからこのフォルダの作業をすることになるから、 は増やした方がいいということでした。

2つ目はカスタムスキルですね。 を使って、コードベースの違う部分でそれぞれのワークフローに合わせたスキルを作っておくと、繰り返しのプロンプトやコンテキスト共有を避けられるというアドバイスでした。

Boris: Thank you for taking the time. For all participants, thank you so much. Originally, we had no idea that it would become this big, and it's just so exciting that everyone is here. Whatever feature requests you guys have, whatever issues you have, please send it. We love hearing feedback, especially bugs or something. Thank you very much.