Claude Codeによる開発とプロトタイピング

Anthropic・Claude・ダリオアモデイ
この記事は約11分で読めます。

この動画はAnthropic社のClaude Codeについて、製品マネージャーのCatとClaude Relations担当のAlexが詳しく解説したものである。Claude Codeの高速な機能開発プロセス、社内でのドッグフーディング文化、そして開発者による多様な使用パターンについて語られている。小規模企業では自動受諾モードや「多重Claude」と呼ばれる複数セッション同時利用が好まれ、大企業ではプランモードがよく使われるなど、企業規模による使い分けも紹介されている。さらに、CLAUDE.mdファイルによるカスタマイズ、カスタムスラッシュコマンド、フック機能などの拡張方法、そして汎用エージェント構築のためのClaude Code SDKの可能性についても詳しく説明されている。

Building and prototyping with Claude Code
Anthropic's Cat Wu (Claude Code) and Alex Albert (Claude Relations) discuss how the Claude Code team prototypes new feat...

Claude Codeの高速開発サイクルについて

こういう開発者たちは複数のClaudeセッションを同時に動かすんを好む傾向があってな、これを「多重Claude」って呼び始めとるんや。せやから6つのClaudeを同時にパソコンで開いとる人のセッションとかも見かけることがあるで。

やあ、僕はAlexや。ここAnthropic社でClaude Relations担当しとるんや。今日はClaude Codeについて話していくで、同僚のCatも一緒に参加してくれとる。

やあ、僕はCatや。Claude Codeのプロダクトマネージャーやっとるで。

Cat、まずはClaude Codeのとんでもない出荷スピードについて話したいんやけど。文字通り、ターミナルで開くたびに新しい製品とか新機能とか、使えるもんが出てきとる感じやねん。チームがアイデアから実際にエンドユーザーに出荷するまでのプロセスってどんな感じなん?

そやな、Claude Codeチームはプロダクト思考を持ったエンジニアがいっぱいおってな、これらの機能の多くはボトムアップで作られとるんや。開発者として「これがほしいなあ」って思ったら、自分で作ってまうんや。うちらのプロセスはドキュメント書く代わりに、Claude Codeで機能をプロトタイプするのがめちゃくちゃ早いから、ほとんどの場合、みんなただ機能をプロトタイプして、それを社内の「アンツ」に出荷するんや。

そんで反応がめっちゃポジティブやったら、それは外部の世界でも受けるって強いシグナルになるんや。それが外部出荷の基準になっとるで。もちろん、完璧やない機能でちょっと調整が必要なもんもある。「アンツ」があんまり使ってへんかったら、また最初に戻って「よし、これについて他に何を変えられるやろか」って考えるんや。

「アンツ」って言うのはAnthropic社員のことやな?

そうそう、そやで。

なるほどな。これはほんまに興味深いわ。Claude Codeほど強い「ドッグフーディング」ループを持った製品は見たことないで。これは意図的にやったことなんか、それとも製品から自然に生まれたもんなんか?

かなり意図的なもんやし、Claude Codeがうまくいってる重要な理由でもあるんや。

Claude Codeで機能をプロトタイプするのがめっちゃ簡単やから、できるだけプロトタイプするように背中を押すんやけど、開発者がツールをどう使うかを正確に理解するのは難しいんや。開発者のワークフローってめっちゃ多様やからな。せやから、理論的に何かをやりたいって分かってても、たとえばIDE統合を作りたいって理論的に分かってても、それでもいろんなやり方の幅があるんや。

そんでプロトタイピングが、製品が実際のワークフローでどうなるかを本当に感じる唯一の方法やったりするんや。そうや、「ドッグフーディング」のプロセスを通して、どのバージョンの機能を出荷するか決めとるんや。

なるほどな。ターミナルの柔軟性と制約が新機能を簡単に追加できる理由もあるってことに気づいたんや。スラッシュコマンドとかのプリミティブが構築されてるから、その上に別のものを追加するのが簡単なんやな。

そやそや、完全にカスタマイズできるように設計されとるんや。そんでたくさんの開発者がターミナルに慣れ親しんでるから、新機能のオンボーディングがめっちゃスムーズになるんや。例えばフック機能とか、Claude Codeのイベント周りに決定論を少し追加できる機能があるんやけど、すべての開発者がスクリプトの書き方を知ってるし、結局のところフックってのはスクリプトなんや。

せやからClaude Codeをカスタマイズするのに新しい技術を学ぶ必要がないんや。既に知ってるスクリプトを書いて、それをClaude Codeのイベントの一つに追加するだけで、決定論が手に入るんや。

このツールで顧客や開発者がいる場所で会おうとしてるんやな。

間違いないわ。

急速な成長とユーザーパターン

話題を少し変えるけど、このとんでもない出荷スピードと並んで、世界中の開発者でのClaude Codeのとんでもない成長率もあるやんか。このロケット船に乗ってる感じってどんなもんか教えて。スタートアップの人でも個人でも大企業でも、いろんな開発者がClaudeをどう使ってるか見えとる?

Claude Codeの魔法的なところの一つは、オンボーディングがめっちゃスムーズなことなんや。NPMインストールした後、Claude Codeは設定なしで箱から出してそのまま動くんや。これは独立系開発者からフォーチュン500の企業のエンジニアまで同じやで。これがClaude Codeの魔法やと思う。持ってるローカルツールとファイルすべてにアクセスできるから、Claude Codeが何ができるかについてめっちゃクリアなメンタルモデルが持てるんや。

ただ、小さい会社と大きい会社では使用パターンが違うのが見えとるで。小さい会社のエンジニアは、「自動受諾モード」みたいなもんを使ってClaudeをもっと自律的に動かす傾向があるんや。これは一つ一つの承認なしにClaude自身に編集させる機能やな。それに、こういう開発者たちは複数のClaudeセッションを同時に動かすんを好む傾向があってな、これを「多重Claude」って呼び始めとるんや。

せやから6つのClaudeを同時にパソコンで開いとる人のセッションとかも見かけることがあるで。それぞれが違うGitワークスペースにあったり、Gitリポジトリの違うコピーにあったりして、それぞれを管理しとるんや。誰かが止まってフィードバックを求めてきたら、そこに飛び込んで送り出して、また動き続けさせるんや。

そんで反対側の大きい会社では、エンジニアが「プランモード」を使うのを好む傾向があるんや。「プランモード」は開発者がClaude Codeに「ちょっと待て、コードベースを探索して、アーキテクチャを理解して、実際にコード自体に飛び込む前にエンジニアリング計画を作れ」って言える方法なんや。

せやからこれは難しいタスクとか複雑な変更にめっちゃ有用やってことが分かっとる。

多重Claudeに戻るけど、これはほんまに魅力的な概念やと思うんや。みんながそういうことをしたがるやろうってのは想像してたけど、ちょっと意外でもあったんや。「わあ、これは本当に予想してへんかった使用パターンや」みたいなもんで、有機的に出てきてロードマップを少し変更したもんって他にある?

そやな、多重Claudeが一番大きいやつやな。これはパワーユーザー機能で何人かがやりたがるもんやって思ってたんやけど、実際はこれがClaudeを使う本当に一般的な方法なんや。例えば、質問だけするCloudeインスタンスを一つ持ってて、これはコードを編集せえへん。そうすれば同じリポジトリでコードを編集する別のClaudeインスタンスを持てて、この二つは干渉し合わへんのや。

他に見たもんは、特別なタスクを処理するためにClaude Codeをカスタマイズするのを本当に好むってことやな。SREエージェント、セキュリティエージェント、インシデント対応エージェントをClaude Codeで作ってる人らを見たことあるで。そんでそれで分かったんは、Claude Codeがうまく動くために統合がめっちゃ重要やってことなんや。

せやから、よく使うCLIツールについてClaude Codeに教えたり、ログとかチケット管理ソフトにアクセスするためにリモートMCPサーバーをセットアップすることにもっと時間をかけるように人らに勧めとるんや。

カスタマイズ方法とCLAUDE.mdファイル

こういうエンジニアがClaude Codeをカスタマイズする時、サブエージェントを作ってるってことなんか、それともCLAUDE.mdファイルみたいなマークダウンファイルを作ってるってことなんか?具体的にどうやってこういう違うタイプのエージェントを作ってるんや?

そやな、人らがカスタマイズしてるのを見た一番一般的な方法は、CLAUDE.mdファイルにめっちゃ投資することやな。CLAUDE.mdファイルはうちらのメモリの概念なんや。せやからチームのゴールが何か、コードがどう設計されてるか、コードベースのどんな落とし穴があるか、どんなベストプラクティスがあるかをClaude Codeに教える一番の場所なんや。

CLAUDE.mdに投資することで出力の品質が劇的に向上するって聞いとるで。人らがClaude Codeをカスタマイズするもう一つの方法は、カスタムスラッシュコマンドを追加することやな。いつもタイプしてるプロンプトがあったら、それをカスタムスラッシュコマンドに追加できるし、チェックインしてチームの他のメンバーと共有することもできるんや。

そんでカスタムフックも追加できるで。例えば、コミットする前にClaude Codeにリントを実行してほしかったら、これはフックにぴったりやな。Claude Codeが作業終了するたびにSlack通知を送ってほしかったら、これが実はフックを作る最初のインスピレーションやったんや。せやからこれらは今日人らが作ってるカスタマイズの全部やな。

Claude Code SDKについてもっと教えて。

Claude Code SDKは汎用エージェントを作る素晴らしい方法なんや。Claude Code SDKは、独自のシステムプロンプト、独自のカスタムツールを持ち込める、エージェントの核となる構成要素すべてにアクセスできるようにしてくれるんや。SDKから得られるのは、ユーザーターンを処理して、ツールコールの実行を処理してくれる核となるエージェンティックループなんや。

Claude Code SDKの可能性

既存のパーミッションシステムを使えるから、ゼロから作る必要がないんや。そんで基盤のAPIとのやり取りも処理してくれる。APIエラーがあった時のバックオフを確実にしてくれるし、リクエストがトークン効率的になるようにめっちゃアグレッシブにプロンプトキャッシュしてくれるんや。エージェントをゼロからプロトタイピングしてるなら、Claude Code SDKを使えば30分ぐらいでかなりパワフルなもんを動かせるようになるで。

人らがこれで本当にクールなもんを作ってるのを見とるんや。GitHubとのClaude Code統合をオープンソース化したんやけど、これは完全にSDKで作られてるし、セキュリティエージェント、SREエージェント、インシデント対応エージェントを作ってる人らを見たことあるで。そんでこれらはコーディング領域内だけやな。コーディング外では、法務エージェント、コンプライアンスエージェントをプロトタイプしてる人らを見たことあるで。

これはエージェントのあらゆるニーズのための汎用SDKになることを強く意図しとるんや。

SDKは僕にとってめっちゃすごいと思うわ。長い間シングルリクエストAPIの世界にいたけど、今はもう一段上の抽象化レベルに移ってる感じやな。君が言った細かいことは全部処理してくれるんや。SDKはどこに向かってるん?次は何や?

次世代のエージェントをアンロックする次の方法としてSDKにめっちゃ興奮しとるんや。エージェント構築において最高クラスになるようにSDKに大きく投資しとる。Claude Codeにある素晴らしい機能すべてが箱から出してSDKで使えるようになって、どれを残すか選択できるんや。

例えば、エージェントにタスクリストを持たせたかったら、最高や。箱から出してタスクリストツールがあるんや。それがいらんかったら、そのツールを削除するのがめっちゃ簡単なんや。エージェントがファイルを編集する必要があったら、例えばメモリを更新するために、箱から出してそれが使えるんや。そんで「うちのは ファイル編集せえへんか、違う方法でファイル編集する」って決めたら、独自の実装を持ち込むだけでいいんや。

オーケー、つまりめっちゃカスタマイズ可能で、基本的にシステムプロンプトやツールを独自の実装に交換できるって意味で汎用目的なんやな。そんでコードとは全く違う領域のもんを作ってても、作ってるものに綺麗にスロットインするんやな?

そうそう、完全にそやで。

人らがこの上で何をハックするか見るのがめっちゃ楽しみやわ。特にエージェントをプロトタイプしようとしてる人らにとって、これは圧倒的に始める一番早い方法やと思う。このハーネスを完璧にするのにほぼ一年かけたし、これはClaude Codeが動いてる同じハーネスなんや。

せやからエージェントが必要とする特定の統合に飛び込んで、エージェントが直面する問題についてのコンテキストを共有するためにシステムプロンプト作業に飛び込みたくて、エージェントループを扱いたくないなら、これは汎用目的のハーネスを全部回避して、特別なソースだけを追加する最高の方法なんや。

開発者向けのベストプラクティス

なるほどな。まあ、ここで聞いた通りや。SDKで構築せなあかんで。ここで終わる前に、君自身のClaude Codeの使い方と、開発者と共有できるベストプラクティスについて聞かせてほしいんや。

Claude Codeやエージェンティックツールと作業する時、一番重要なんは自分のゴールをツールに明確に伝えることやと思う。

多くの人がプロンプティングは魔法的なもんやと思ってるけど、実際はそうやないんや。「自分の目的を明確に説明したか?このタスクでの目的、タスクの出力をどう評価してるか、デザインシステムでの制約は何か」ってことなんや。そんで普通、これらのことを明確に伝えることができたら、Claude Codeはそれらをできるか、「オーケー、これはA、B、Cの理由でできへんけど、代わりにD、E、Fを試してみたいか?」って教えてくれるんや。

つまり、別のエンジニアと働いてるのと同じようにコミュニケーションが全てってことやな。

そうそう、完全にそやで。もう一つは、Claude Codeが変なことをしたって気づいたら、なんでそうしたかったのか実際に聞けるってことなんや。そしたら「ああ、CLAUDE.mdにこれって書いてあったから」とか「このファイルで何かを読んで、こういう印象を受けた」とか教えてくれるかもしれん。そしたらClaudeと話すことをデバッグの方法として実際に使えるんや。いつもうまくいくわけやないけど、絶対に試してみる価値はあると思うし、うちらが使ってる一般的な手法やで。

Claude CodeでClaude Codeをデバッグするってことやな。

最高やわ。

そやそや。人間と働いてる時と同じで、期待してへんことを言われたら「ああ、面白いな。何がそんな印象を与えたん?なんでそう思ったん?」って感じるかもしれんやろ。エージェントとでも同じことができると思うで。

それはめっちゃ魅力的やな。Cat、これは素晴らしかったで。時間を取ってくれて本当にありがとう。

呼んでくれてありがとう。

コメント

タイトルとURLをコピーしました