ポッドキャスト世界の声を聴き、思考の刻みを見る。
チャンネルを探す
効果的なサブエージェントの設計方法
Anthropic の Claude Code シリーズによるチュートリアル。サブエージェントが脱線・停止・ファイルの誤操作を起こさず安定して動くための4つの具体的なパターンを解説する。コードレビューと Web 検索のサブエージェントを例に、各設定項目の意味と調整方法を順に示す。 ## [00:03] 名前と説明でサブエージェントの動作を制御する メイン・コンテキストウィンドウ・エージェントが受け取るすべてのメッセージには、登録済みサブエージェントの名前と説明がシステムプロンプトに含まれる。つまり説明文は二重の役割を担う——オーケストレーターにサブエージェントを*いつ*起動するかを伝え、入力プロンプトを書く際のテンプレートを提供する。 チュートリアルはコードレビューのサブエージェントを使って実演する。元の設定ではオーケストレーターが汎用プロンプトを書き、サブエージェント自身が `git diff` を呼ぶよう指示するだけだった。説明文を「どのファイルをレビューするか正確に伝えなければならない」という内容に変えると、ファイル選択の責任がオーケストレーター側に移り、次の実行では入力プロンプトが明らかに具体的になる。同じレバーは Web 検索サブエージェントにも有効で、説明文に「引用可能なソースを返すこと」と加えるだけで、委任時にメインスレッドが自動でその指示を含めるようになる。 > *"If you want to better control when the main agent launches a sub agent automatically, you should modify the name and description."* ## [01:41] 出力形式を定義する 出力形式の定義は、単一の改善策の中で最もインパクトが大きいと解説者は指摘する。形式がなければ、サブエージェントには作業完了の明確なシグナルがなく、動き続けてコンテキストを積み上げ、トークンを消費し続ける。 構造化された出力形式は自然な停止点を生む——必須フィールドがすべて埋まれば、サブエージェントは完了を認識できる。実践的には、サマリーブロック・発見事項リスト・ステータスフィールドなどの明示的なスキーマをサブエージェントのシステムプロンプトに直接追加する。 > *"Without a defined output format, sub agents struggle to decide when enough research has been done and they tend to run much much longer than sub agents that are given an output format."* ## [02:04] サマリーで障害を報告する サブエージェントが問題を解決した場合——依存関係の競合、予期しないフラグが必要なコマンド、環境の癖など——メインスレッドがその情報を受け取れなければ、次のステップで同じ壁にぶつかる。解決策は、出力形式そのものに障害の報告を組み込むことだ。 解説者が必ず浮上させるべき内容として挙げるのは、遭遇した障害・セットアップの問題・発見した回避策・特別なフラグや設定が必要だったコマンド・問題を引き起こした依存関係や import の各カテゴリ。これらを必須スキーマに組み込めば、メインスレッドはサブエージェントが苦労して得た知見を引き継ぎ、同じ試行錯誤を繰り返さずに済む。 > *"Otherwise, the main thread has to rediscover the same solutions, obstacles encountered, any setup issues, workarounds discovered or environment quirks, commands that needed special flags or configuration, dependencies or imports that cause problems."* ## [02:42] 役割に応じてツールアクセスを制限する ツールアクセスはセキュリティ制御であるだけでなく、役割を明確にするための手段でもある。`glob`・`grep`・`read` だけを持つ読み取り専用サブエージェントはファイルを誤って変更できないため、設定を見ればその役割が一目でわかる。 解説者は3つのアクセス層を3つのサブエージェントの役割に対応づける。調査用サブエージェントは読み取り専用——コードベースの探索に書き込みは不要だ。レビュー用サブエージェントは `git diff` のために `bash` を使えるが、ファイル編集ツールは持たない。CSS 更新を適用するスタイリングエージェントのように、コードを実際に変更するタスクを担うサブエージェントにのみ `edit` と `write` を付与する。複数のサブエージェントが動く環境では、ツールリストがそれぞれの役割を示す機械可読なサマリーになる。 > *"Only give edit and write to sub agents that should actually change your code, like a styling agent applying CSS updates."* ## [03:27] 効果的なサブエージェントの4つのパターン チュートリアルは4つのパターン全体を一文でまとめて締めくくる——構造化出力・障害報告・的確な説明文・ツールアクセスの制限。各パターンは互いを補強する。的確な説明文は入力プロンプトの曖昧さを減らし、出力形式は停止点を作り、障害報告はエージェント境界をまたいでコンテキストを引き継ぎ、最小限のツールアクセスは残った曖昧さを増幅させる副作用を防ぐ。 > *"So effective sub agents use structured output report obstacles have specific descriptions and limit tool access."* ## 登場人物 - **Anthropic Tutorial Narrator**(人物):Anthropic を代表して Claude Code サブエージェントチュートリアルシリーズを担当する解説者 - **Claude Code**(ソフトウェア):Anthropic のエージェント型コーディングツール。サブエージェントをオーケストレーションして多段階のエンジニアリングタスクを完遂する - **Subagent**(概念):オーケストレーターエージェントが起動する専用 Claude インスタンス。独自のシステムプロンプト・ツールアクセス・入力プロンプトを持つ - **出力形式**(概念):サブエージェントのシステムプロンプトで定義する必須スキーマ。停止条件を作り、メインスレッドへ返す情報を構造化する - **障害報告**(概念):回避策・依存関係の問題・環境の癖をサブエージェントの出力に含めることを義務付けるパターン。オーケストレーターが同じ問題を再調査しなくて済む - **ツールアクセスのスコープ限定**(概念):各サブエージェントに役割上必要なツールだけを与えること——調査は読み取り専用、レビューは bash、ファイル変更が必要なエージェントにのみ edit/write を付与 - **Anthropic**(組織):Claude および Claude Code エージェント型コーディングプラットフォームの開発元
サブエージェントとは何か?
サブエージェントは Claude Code がタスクを委譲できる専門アシスタントだ。それぞれが独立したコンテキストウィンドウで動作し、自律的に作業を完了させたうえで要点だけを返す。中間の処理トレースはすべて破棄される。この2分間のチュートリアルでは、その分離設計がメインのコンテキストウィンドウを維持するうえでなぜ重要かを解説し、具体的なコード探索シナリオでトレードオフを示したあと、Claude Code に標準搭載されているサブエージェントを紹介する。 ## [00:03] サブエージェントとは サブエージェントは独立した会話コンテキストウィンドウで動作し、任意のカスタムシステムプロンプトで初期化される。親エージェント(メインスレッドの Claude Code)がユーザーの指示をもとにサブエージェントへタスク内容を渡す。サブエージェントは自律的に作業を進め、結果の要約だけをメインスレッドへ返す。途中の作業はすべて隔離されたままだ。 > *「サブエージェントは、Claude がタスクを委譲できる専門アシスタントです。」* 設計上の重要なポイント:サブエージェントが完了すると、その会話スレッド全体が完全に破棄される。メインの会話に戻ってくるのは返された要約だけだ。 ## [00:24] コンテキストウィンドウの管理 メインスレッドで Claude が行うツール呼び出し、ファイル読み込み、検索、関数トレースはすべてメインのコンテキストウィンドウに積み上がる。長いセッションではあっという間に満杯になる。サブエージェントは、こうした個別の調査や操作タスクをオフロードして、その負荷をメインウィンドウに持ち込まないためにある。 > *「各サブエージェントは独自の会話コンテキストウィンドウで動作し、自分で定義したカスタムシステムプロンプトで初期化されます。」* トレードオフははっきりしている。メインウィンドウはきれいなコンテキストを保てるが、サブエージェントがどう結論に至ったか、途中で何を見つけたかは見えなくなる。手に入るのは答えであって、推論の経緯ではない。 ## [01:13] 具体例:決済システム たとえば Claude Code を使って、未知のコードベースの中でどのサービスが返金を処理しているかを調べるとする。サブエージェントなしの場合、Claude は15個のファイルを読み込み、複数の検索を実行し、関数呼び出しをたどるかもしれない。必要だったのは1つの事実だけなのに、そのすべてがメインのコンテキストウィンドウを埋めてしまう。 > *「サブエージェントを使えば、道のりではなく答えだけが手に入ります。」* サブエージェントがコードベースを探索して答えを見つけ、要約だけを返す。メインのコンテキストはきれいなままだ。失われるのは可視性だ。どのファイルを読んだか、どのトレースをたどったかは見えなくなる。 ## [02:00] Claude Code 組み込みのサブエージェント Claude Code には3つのサブエージェントが標準搭載されており、すぐに使える。 - **汎用サブエージェント** — 探索と操作の両方を必要とするマルチステップタスク向け。 - **Explore サブエージェント** — フルタスクループのオーバーヘッドなしにコードベースを高速検索する。 - **Plan サブエージェント** — プランモード中にコードベースを調査・分析してから計画を提示する。 > *「カスタムシステムプロンプトとツールアクセスを設定した独自のサブエージェントを作ることもできます。」* この3つに加えて、独自のシステムプロンプトとツールアクセスリストを持つカスタムサブエージェントを定義し、特定のワークフローに合わせて使うこともできる。 ## [02:30] サブエージェントを使うタイミング サブエージェントが効果を発揮するのは、独立した完結型の問いやタスクがあるときだ。そのまま実行すれば大量の中間コンテキストがメインウィンドウに流れ込む類のものが対象になる。 > *「Claude Code のサブエージェントは作業を集中した単位に分割し、メインのコンテキストウィンドウをきれいに保ち、必要なものだけを返してくれます。標準搭載のものを使っても、独自に作っても同じです。」* コンテキストウィンドウの圧迫が蓄積する長時間の Claude Code セッションで特に価値を発揮する。サブタスクをサブエージェントに委ねることで、セッションの有効稼働時間が実質的に延びる。 ## エンティティ - **Anthropic チュートリアルナレーター** (人物): Anthropic が制作する「Claude Code subagents」チュートリアルシリーズのナレーター - **Claude Code** (ソフトウェア): Anthropic のエージェント型コーディングアシスタント。サブエージェントが動作するホスト環境 - **Claude** (ソフトウェア): Claude Code とそのサブエージェントを動かす基盤 AI モデル - **サブエージェント** (概念): Claude Code がタスクを委譲する専門アシスタント。独自のシステムプロンプトを持ち、隔離されたコンテキストウィンドウで動作する - **コンテキストウィンドウ** (概念): 会話履歴、ツール呼び出し、結果をすべて保持する有限のトークンバッファ。サブエージェントにより中間作業が蓄積するのを防ぐ - **汎用サブエージェント** (ソフトウェア): 探索と操作を組み合わせたマルチステップタスク向けの Claude Code 組み込みサブエージェント - **Explore サブエージェント** (ソフトウェア): コードベースの高速検索に最適化された Claude Code 組み込みサブエージェント - **Plan サブエージェント** (ソフトウェア): プランモード中にコードベースを調査してから計画を提示する Claude Code 組み込みサブエージェント - **Anthropic** (組織): Claude および Claude Code の開発元。このチュートリアルシリーズの制作者

テレンス・タオ – 世界トップ数学者はAIをどう使っているか
タオとドワーケシュは、ケプラーの惑星運動の発見をレンズとして、AIが科学に実際に何をもたらしているかを考察する。タオは、仮説の生成はほぼ無コストになったため、ボトルネックは評価・査読・時間の審判に移ったと主張する。現在のAIは広さで勝り(あらゆる問題にあらゆる標準技術を試す)、人間は深さで勝る(部分的な進捗を積み上げていく)ため、ハイブリッド構成が少なくともあと10年は数学を支配するだろう。 ## [00:00] ケプラーは高温のLLMだった タオはケプラーが惑星運動の三法則に至った経緯を語る。ケプラーは間違いだが美しい理論、惑星の軌道の間にプラトン立体を内接させるモデルから出発し、チコ・ブラーエの盗んだ肉眼観測データを何年もかけて検証して初めてそれを捨てた。楕円軌道、面積一定の法則、3乗2乗の法則は10年に及ぶデータ解析から生まれ、ニュートンの説明は1世紀後のことだった。 ドワーケシュの見立て:ケプラーは検証可能なデータセットに対してランダムな関係を巡り続ける高温のLLMに似ている。タオはメカニズムには同意しつつ、ボトルネックについては異を唱える。アイデア生成はすでに安かった——ケプラーに理論は不足していなかった。彼に必要だったのはブラーエの桁違いに優れたデータと、データが否定したアイデアを捨てる忍耐だった。 > *しかしあなたが言う通り、同量の検証が伴わなければ、それはスラップにすぎない。* ## [11:44] AIのスラップの山の中に新しい統一概念があるとどうやって気づくのか タオ:AIがアイデア生成のコストをほぼゼロに押し下げたなら、査読と時間の審判が新たな制約になる。学術誌はすでにAI生成の投稿であふれかえっている。どんなアイデアの地位も、後の科学がそれをどう扱うかにかかっている——コペルニクスはケプラーが全体像を完成させるまでプトレマイオスより精度が低かった——だから、その時点にいる人間が評価を自動化するのは難しい。 ドワーケシュは、何百万もの凡庸な論文に埋もれたベル研究所型の統一概念(シャノンのビット、トランスフォーマー)を科学がどう見つけるかを問う。タオの答えは、人間が担い続けるかもしれない部分を指し示す。科学者は理論を生み出すだけでなく、他の科学者が何年もかけて追究する気にさせるストーリーを語る。ダーウィンの散文が、ニュートンのラテン語の方程式ではできなかった仕事をやってのけた。 > *AIはアイデア生成のコストをほぼゼロに押し下げた。インターネットがコミュニケーションのコストをほぼゼロに押し下げたのと非常によく似た形で。* ## [26:10] 演繹的オーバーハング タオは既存データに眠る未開拓のシグナルについて語る。天文学は何世紀にもわたって最小限のデータから最大限の情報を引き出す学問だった——クオンツヘッジファンドが天文学の博士号取得者を優先採用するのもそのためだ。彼が好む例の一つ:研究者たちは、引用連鎖の中でどのタイポが伝播するかを追跡することで、科学者が引用論文を実際に読む頻度を測定した。 彼はAIの進歩自体にも同じ科学社会学的なアプローチを当てはめることを提案する——引用パターン、学会での言及、その他の足跡を採掘して、ある成果が実際に前進を構成したかどうかを、時間の審判をゆっくり待つのではなく検出するのだ。 > *ひとつの教訓は、多くの分野で演繹的オーバーハングが人々の想像よりはるかに大きい可能性があるということだった。* ## [30:31] AI発見の報告における選択バイアス AIはエルデシュ問題約1100題のうちおよそ50題を解いた後、頭打ちになった。タオは選択効果を説明する。その50題はほぼ文献がなかった——1つの無名な技術と1つの既知の結果を組み合わせれば十分で、AIツールは「あらゆる標準的な組み合わせを試す」のが得意だ。問題の80%が既存の手法で片付くなら、AIはそれをクリアできる。真に新しい技術が必要な場合はツールが止まり、系統的なスイープにおける問題ごとの成功率は1〜2%になる。 タオの比喩:AIツールは暗闇の中で山岳地帯に放たれたジャンプロボットだ。人間が届かない低い壁は越えられるが、手がかりをつかんでそこに留まり、部分的な進捗から引き上げていくことはできない。強気の解釈——AIがある水準に達すれば、1つの問題に100万のコピーを並列で走らせられ、どんな人間コミュニティにもできない——は、科学が広さを実際に活用する新しいパラダイムを必要とする構造的理由でもある。 > *広さではAIが優れ、深さでは人間が、少なくとも人間の専門家が優れている。* ## [46:43] AIは論文を豊かに広くするが、深くはしない タオ自身の作業パターンについて。論文にはより多くのコード、より多くの図、より深い文献調査が含まれるようになった。補助的な作業のコストがおよそ5分の1になったからだ。実際の核心——問題の最も難しい部分を解くこと——は今もペンと紙の上で行われる。補助的なタスクが変わっただけで、取り組んでいた問いに答える速度は変わっていないため、「2倍生産的になった」とは言いにくい。 巧妙さと知性の違いも同じ場所に着地する。2人の人間が数学の問題に取り組むとき、失敗したプロトタイプのそれぞれが次の足がかりになる。現在のAIでは、新しいセッションが前のセッションの成果を忘れてしまう。累積的に引き上げるステップが欠けており、あるのは純粋な試行錯誤と、最終的には次のトレーニングランへの吸収だけだ。 > *論文を豊かに広くしているが、必ずしも深くはしていない。* ## [53:00] AIが問題を解いたとき、人間はそこから理解を得られるか AIがLeanでリーマン予想を証明しても人間には何も分からないということはあり得るか。タオは心配していない。Leanには証明を原子レベルに分解できる特性がある——各補題を独立して検査し、除去し、テストできる。だから3000行の生成された証明でも生の素材になる。他のAIが洗練のために再構成し、他の人間が概念的な内容を抽出でき、元の導出が不透明であっても成果物は有用だ。 彼は、巨大なLean生成の証明を分解してその中のアイデアを見つけることを仕事とする数学者という職業全体を予測する。人間の判断とAIの除去ツールを組み合わせた証明考古学のようなものだ。 > *人間がこれらのツールと協業するインタープレーからはるかに多くのものが得られるだろう。* ## [59:20] 科学者が実際に互いに話す方法のための半形式言語が必要だ ドワーケシュは、数学的証明ではなく数学的戦略のための半形式言語はどのようなものかを問う。タオはガウスの素数定理——証明が存在する前に生のデータから導かれた数学初の主要な統計的予想——と、双子素数予想を通じてこの問いを辿る。数学者がそれを信じるのは、素数のランダムモデルがそれを予測するからだ。数学には厳密な証明と厳密なヒューリスティックの両方がある。しかしLeanが検証できる形に形式化されているのは証明の側だけだ。 ヒューリスティックの側が形式化されていない理由:RL検証可能な評価者はすべてエクスプロイトの標的になるし、「この論証は説得力がある」という主観的な部分はまだハック可能なフレームワークを認めない。タオはおもちゃの数学的宇宙で小さなAIを走らせてどんな戦略が生まれるかを観察するなど、大規模な予想生成と戦略選択のベンチマーク方法を望んでいる。 > *科学には、AIを何か有益な形で組み込む方法がまだ分からない主観的な側面がある。* ## [69:48] テリーの時間の使い方 タオが新しいサブフィールドをどう吸収するかについて。彼はバーリンの意味でのキツネとして自分を位置付ける——あらゆることについて少しずつ知り、必要に応じてハリネズミになる。原動力は完全主義的な強迫観念だ。別の数学者が自分の知らない技術で結果を証明できるなら、その技術が何だったかを追いかけなければならない。(同じ理由でビデオゲームをやめた。)他の数学者との協働が主な手段で、ブログに書き留めることは6ヶ月後に論証を忘れて繰り返し痛い目を見た後に開発した記憶の補助だ。 カレンダーの上では、タオは意図的に偶然性のための余地を残している。時間を最適化しすぎてコンフォートゾーン外の会議に出られなくなるのは嫌だ。高等研究所で過ごした1年がその罠を確認した——純粋な研究の2週間は素晴らしかったが、その後はインスピレーションが尽きた。次の書棚での偶然の発見、廊下でのなにげない会話、しぶしぶ出席した会議が、見かけよりはるかに大きな仕事をしていた。 > *そういった偶発的なやりとりは最適には見えないかもしれないが、実は本当に重要なのだ。* ## [77:05] 人間とAIのハイブリッドがずっと長く数学を支配するだろう AIが数学をやるだけになるのはいつか。タオはフレームを変える——AIはすでに人間にできない数学をやっている、電卓がそうであるように、ただ別のフロンティアで。おそらく10年以内に、大学院生が現在やっていることの多く——標準技術の適用、文献の整理——はAIに移行するだろうが、コンピュータ代数システムが記号積分を吸収したときのように、分野は一段上に移るだろう。ゲノム研究は塩基配列解析が安くなっても終わらなかった。生態系にまでスケールアップした。数学も同じことをするだろう。 今数学に入る学生へのアドバイス:変化を前提にしながらも、資格は昔ながらの方法で取れ——今のところ、数学を従来の道で学ぶことに代わるものはまだない。同時に、まだ存在しないものも含め、新しい研究モードが現れたときにそれを使えるくらい適応力を持て。特筆すべき事実として、AIツールとLeanがあれば高校生が今日本物の数学研究に貢献できる。5年前にはあり得なかったことだ。 > *人間プラスAIのハイブリッドが数学をずっと長く支配するだろうと、私は信じている。* ## 登場人物 - **テレンス・タオ** (人物): フィールズ賞受賞者(2006年)、UCLA数学者。数学研究におけるAIの役割についてブログで定期的に発信。 - **ドワーケシュ・パテル** (人物): Dwarkesh Podcastのホスト。AI、科学、技術をテーマに長時間インタビューを行う。 - **ヨハネス・ケプラー** (人物): 天文学者(1571-1630)。チコ・ブラーエの観測から惑星運動の三法則を導いた。 - **チコ・ブラーエ** (人物): 数十年にわたる惑星観測データを残したデンマークの肉眼天文学者。ケプラーが必要としたデータセット。 - **Lean** (ソフトウェア): 数学的証明を形式化して検証・分解・除去できる証明支援系。 - **エルデシュ問題** (概念): ポール・エルデシュが提起した約1100題の未解決問題。AIはほぼ文献のないものを中心におよそ50題を解いた。 - **演繹的オーバーハング** (概念): 既存データがすでに膨大な未導出の知識を内包しているという考え。天文学がモデルとなる。 - **リーマン予想** (概念): 素数分布に関する未解決の予想。AIによる証明が人間の数学的理解を前進させるかどうかの試金石。
スキルとは何か?
Claude Code スキルは、専門知識を一度書き込んでおける再利用可能な Markdown ファイルだ。リクエストが合致すれば Claude が自動的に起動するため、ユーザーが同じ説明を繰り返す必要も、スラッシュコマンドを手動で入力する必要もない。この3分のチュートリアルでは、スキルとは何か、どこに置くか、CLAUDE.md とどう違うか、そして書くべきタイミングのサインを説明する。 ## [00:03] スキルが解決する繰り返し問題 チームのコーディング規約を Claude に説明するたび、PR フィードバックの形式を再度伝えるたび、好みの commit メッセージ形式をリマインドするたびに——あなたは同じことを繰り返している。ナレーターは3つの例を続けて挙げ、スキルが狙い撃ちにするその摩擦点を明確にする。 > *"Every time you explain your team's coding standards to Claude, you're repeating yourself."* ## [00:20] スキルの正体とClaudeが選ぶ仕組み スキルとは、何かをやり遂げる方法を Claude に一度だけ教える Markdown ファイルだ。Claude はその指示を保持し、状況が合致すれば自動的に適用する。Claude Code ではこのファイルを SKILL.md と呼ぶ。ファイル内の description フィールドが鍵となる仕組みで、「この PR をレビューして」と頼むと、Claude はリクエストを全スキルの説明と照合し、一致するものを起動する。 > *"Claude reads your request, compares it to all available skill descriptions, and activates the ones that match."* ## [01:05] スキルの保存場所:個人用とプロジェクト用 スキルの保存場所は、誰が使うかによって2種類ある。個人スキルは `~/.claude/skills` に置き、すべてのプロジェクトに持ち運べる——commit メッセージのスタイル、ドキュメントの形式、コードの説明の好み。プロジェクトスキルはリポジトリのルート直下の `.claude/skills` に置き、リポジトリをクローンした人全員が自動的に手に入れる。チームの標準——ブランドガイドライン、Web デザインで使うフォントや色——はこちらに置く場所だ。 > *"Anyone who clones the repository gets these skills automatically."* ## [01:42] スキルとCLAUDE.md:自動化とコンテキスト効率 Claude Code にはいくつかのカスタマイズレイヤーがあり、スキルは独自のポジションを占めている。CLAUDE.md はすべての会話に無条件で読み込まれるため、「常に TypeScript の strict mode を使う」といったルールに向いている。スキルはオンデマンドで読み込まれ、現在のリクエストと一致したときだけ起動する。起動前にコンテキストに入るのは名前と説明だけで、スキル本体は実際にトリガーされて初めて読み込まれる。おかげで、デバッグ中は PR レビューチェックリストがコンテキストを占有せず、レビューを依頼したときだけ引き込まれる。スラッシュコマンドはタイプが必要だが、スキルは不要だ。 > *"Skills are unique because they're automatic and task-specific."* ## [02:27] スキルを書くべきタイミング スキルは特定のタスクに紐づいた専門知識に最も向いている——チームが従うコードレビュー基準、commit メッセージ形式、ブランドガイドライン。締めの言葉はシンプルで実用的だ:同じことを Claude に何度も説明していると気づいたら、それはスキルとして書く合図だ。 > *"If you find yourself explaining the same thing to Claude repeatedly, well, that's a skill waiting to be written."* ## 登場人物 - **Anthropic Tutorial Narrator**(人物):Claude Code skills チュートリアルシリーズのナレーターおよびホスト - **Claude Code**(ソフトウェア):Anthropic の AI コーディングアシスタント。スキルが発見・適用されるランタイム - **SKILL.md**(概念):スキルを定義する Markdown ファイル。名前、説明、Claude への指示を含む - **CLAUDE.md**(概念):プロジェクトレベルまたはグローバルの指示ファイル。すべての Claude Code 会話に無条件で読み込まれる。スキルと対比して語られる - **Anthropic**(組織):Claude および Claude Code の開発元
スキルを共有する
一人のエンジニアが使う PR レビュースキルは便利だが、同じスキルをチーム全体に展開すれば、コードレビューの基準が統一され、組織全体で一貫した体験が生まれる。このチュートリアルでは、リポジトリへのコミット、プラグイン、エンタープライズ管理設定、カスタムサブエージェントという4つの具体的な配布方法を取り上げ、それぞれの適切な使い所を解説する。サブエージェントのセクションには見落としやすい注意点がある——サブエージェントはスキルを自動的に継承せず、組み込みエージェントに至ってはスキルにまったくアクセスできない。 ## [00:01] 共有がスキルの価値を何倍にもする理由 スキルが一人の開発者の手元にとどまる間は、その効果も限定的だ。チームに広げた瞬間、標準が定着し、個人差がなくなり、レビューのスタイルと品質が揃う。冒頭では個人利用とチーム規模の対比を軸に、4つの共有メカニズムが紹介される。 > *"A PR review skill that only you use is helpful. The same skill shared across your team standardizes code review and provides a consistent experience amongst your organization which is much better."* ## [00:18] スキルをリポジトリにコミットする 最も手軽な方法は、スキルをプロジェクトリポジトリの `.claude/skills` に置くことだ。リポジトリをクローンするだけで誰でもすぐ使える——追加インストールも余分なツールも不要。更新は通常の `git pull` で届く。チームの開発規約、プロジェクト固有のワークフロー、コードベースの構造を参照するスキルに向いている。 > *"Anyone who clones the repository gets these skills automatically. No extra installation, it's just what you're doing already."* ## [00:45] プラグインでスキルを配布する プラグインは Claude Code にカスタム機能を追加しつつ、単一プロジェクトの枠を超えて広まる設計になっている。プラグインプロジェクト内の `skills/` ディレクトリは `.claude/` の構造を踏襲し、スキル名と `SKILL.md` を持つ。マーケットプレイスに公開すれば、どの Claude Code ユーザーもダウンロードして有効化できる。特定チームの慣習に縛られず、より広いコミュニティで使えるスキルに最適なチャネルだ。 > *"Think of plugins as ways to extend Claude Code with custom functionality, but designed to be shared across teams and projects."* ## [01:26] 管理設定によるエンタープライズ全体への展開 管理者は管理設定を通じて、組織内のすべての開発者にスキルを配布できる。エンタープライズスキルは最高優先度を持ち、同名の個人・プロジェクト・プラグインスキルを上書きする。セキュリティ要件、コンプライアンスフロー、統一必須のコーディング規約など、強制適用すべき標準に適している。チュートリアルでは「必須」という言葉が強調される——あくまで推奨ではなく義務だ。 > *"This is for mandatory standards, security requirements, compliance workflows, or coding practices that must be consistent across the organization."* ## [01:52] カスタムサブエージェントと明示的なスキル読み込み サブエージェントはメイン会話のスキルを引き継がない。組み込みエージェント(explorer、planner、verify)はスキルにまったくアクセスできない。`.claude/agents` 内の `agent.md` ファイルで定義したカスタムサブエージェントだけがスキルを使え、しかもそのファイルの `skills:` フィールドに明示的に列挙したものに限られる。スキルはサブエージェントの起動時に読み込まれ、オンデマンドではないため、リストはそのエージェントの目的に常に関連するスキルだけに絞るべきだ。チュートリアルでは、Claude Code のサブエージェント作成ツールで新しいサブエージェントを作り、既存の `agent.md` にスキルを追加する流れが実演される。 > *"Built-in agents like the explorer, planner, and verify can't access skills at all. Only custom sub-agents you define can use them, and only when you explicitly list them."* ## [03:18] まとめ:適切な配布方法の選び方 締めくくりでは各方法のシナリオが整理される。チームアクセスにはプロジェクトディレクトリ、リポジトリをまたぐ共有にはプラグイン、組織全体の必須標準にはエンタープライズ展開、そして隔離されたタスク委譲にはサブエージェントへの明示的なスキルリスト。サブエージェントへの注意喚起は最後にも繰り返される——スキルは起動時に読み込まれるのであり、遅延ロードではないから、常に関連するものだけをリストに入れること。 > *"Share skills through project directories for team access, plugins for cross-repository distribution, or enterprise deployment for organization-wide standards."* ## 登場人物・用語 - **Anthropic チュートリアルナレーター** (人物):Claude Code スキルチュートリアルシリーズの単独プレゼンター - **Claude Code** (ソフトウェア):Anthropic の AI コーディングアシスタント;スキルを作成・展開するランタイム環境 - **Skills(スキル)** (概念):`.claude/skills` に置く再利用可能な命令セット;Claude Code の動作を拡張する - **Plugins(プラグイン)** (概念):スキルをバンドルしてチームやマーケットプレイスユーザー間で共有できる配布可能パッケージ - **Managed settings(管理設定)** (概念):エンタープライズ管理者がスキルを最高優先度で組織全体に展開する仕組み - **Sub-agents(サブエージェント)** (概念):`.claude/agents` の `agent.md` で定義するカスタム Claude Code エージェント;スキルを読み込める唯一のエージェント種別で、明示的に列挙する必要がある - **Anthropic** (組織):Claude Code を開発した企業;Claude Code スキルチュートリアルシリーズを制作
設定と複数ファイルによる skill 構成
Claude Code skills シリーズの 4 分間チュートリアル。基本的な skill を信頼性が高くコンテキスト効率のよいツールへ仕上げるための高度な設定フィールドを取り上げる。agentskills.io が定義するフィールド全体——`name`、`description`、`allowed_tools`、`model`——をひとつずつ解説し、参照資料やスクリプトをユーザーのリクエストが実際に必要とする場合にのみ読み込むよう、段階的開示で大規模 skill を整理する方法を示す。 ## [00:02] 高度な skill フィールドの概要 agentskills.io オープン標準は、必須の `name` と `description` に加えていくつかのフィールドを定義している。`name` は小文字とハイフンのみで構成し、64 文字以内に収め、ディレクトリ名と一致させる必要がある。`description` は最大 1,024 文字で、Claude が skill をマッチングする際の主要シグナルとなる。任意フィールドとして `allowed_tools`(呼び出せるツールを制限)と `model`(特定の Claude バージョンに固定)の 2 つが用意されている。 > *"name と description だけで基本的な skill は動作しますが、Claude Code で skill をより効果的にするための高度なヒントをいくつか紹介します。"* ## [00:39] 効果的な description の書き方 「help with dogs」のような曖昧な description では、Claude は skill の適用範囲やトリガー条件を推測するしかない。良い description が答えるべき問いはふたつだけ——この skill は何をするのか、そしていつ使うべきなのか。キーワードをユーザーの自然な言い回しに合わせることが、トリガーされない skill を直す最も効果的な手段だ。 > *"良い description はふたつの問いに答えます。この skill は何をするのか?そして、いつ使うべきなのか?"* ## [01:20] allowed_tools によるツール制限 `allowed_tools` は、skill を特定の操作面に閉じ込めるための仕組みだ——セキュリティ上の機密を扱うワークフローでは読み取り専用アクセスに限定できる。このフィールドを設定すると、Claude は許可されたツールだけを許可申請なしに呼び出せる。編集・書き込み・Bash コマンドは一切使えなくなる。フィールドを省略した場合は Claude の通常の権限モデルがそのまま適用される。 > *"この skill がアクティブな間、Claude はこれらのツールだけを許可なしに使えます。編集も書き込みも bash コマンドもありません。"* ## [01:49] 複数ファイル skill の段階的開示 skill はライブの会話と Claude のコンテキストウィンドウを共有する。2 万行の `SKILL.md` にすべてを詰め込むと、呼び出すたびにコンテキストが膨れ上がり、メンテナンスも苦痛になる。解決策は、必須の指示を `SKILL.md` に置き、参照資料は別ファイルに移して、ユーザーのリクエストが実際に必要とするときだけ Claude が読み込む構成にすること。標準が推奨するサポートディレクトリは 3 種類——実行コード用の `scripts/`、ドキュメント用の `references/`、画像やテンプレート用の `assets/`。`SKILL.md` 内のリンクは目次の項目として機能し、そのトピックが話題に上らなければファイルは一切読み込まれない。 skill ディレクトリ内のスクリプトはソースをコンテキストに読み込まずに実行できるため、消費するのは出力のトークンだけ。`SKILL.md` は 500 行以内に収めるのが推奨で、それを超えたら skill を分割するサインだ。 > *"コンテキストウィンドウにドキュメント全体を詰め込むのではなく、目次を置くようなイメージです。"* ## [03:18] まとめ:skill メタデータとベストプラクティス チュートリアルの締めくくりとして設定の全体像を改めて整理する。`name` と `description` は必須、`allowed_tools` はツール操作面を制限、`model` は Claude バージョンを固定。description には具体的な動詞とトリガーフレーズを含めることで安定したマッチングが実現する。大規模な skill では段階的開示を用いて `SKILL.md` を 500 行以内に保ち、サポートファイルは実際に必要になるまで読み込みを遅らせる。スクリプトはソースを読み込まずに実行できるため、コンテキストをスリムに保てる。 > *"スクリプトはその内容を読み込まずに実行できるため、コンテキストを効率的に保てます。"* ## 登場人物・エンティティ - **Anthropic チュートリアルナレーター** (人物): このチュートリアルシリーズの単独ホスト。Claude Code skill の設定について解説する。 - **Claude Code** (ソフトウェア): agentskills.io 標準に基づく skill を読み込んで実行する Anthropic の CLI ツール。 - **agentskills.io** (組織): `name`、`description`、`allowed_tools`、`model`、ディレクトリ規約などを定義する skill マニフェストスキーマのオープン標準。 - **SKILL.md** (概念): Claude Code skill の主要マニフェストファイル。500 行以内に収め、サポートファイルへのリンクを置くことが推奨される。 - **allowed_tools** (概念): 特定の Claude ツールをホワイトリスト指定する任意 skill フィールド。読み取り専用またはサンドボックス化された skill モードを実現する。 - **段階的開示** (概念): 参照ファイルやスクリプトを、アクティブなリクエストが実際に必要とするときのみコンテキストに読み込む多ファイル skill の構成手法。 - **コンテキストウィンドウ** (概念): 会話と skill ファイルが共有するトークン予算。段階的開示が節約しようとする主要なリソース。
はじめてのスキルを作る
この 3 分間のチュートリアルでは、Claude Code の個人スキルをゼロから構築する手順を通しで示す。SKILL.md を含むディレクトリを作成し、スキルが起動時にロードされることを確認して、実際のリクエストに Claude が適用する様子を観察する。後半ではスキルのロードパイプラインを詳しく解説——4 か所のスキャン場所、名前のみを読み込む起動フェーズ、確認ゲート、そして名前の競合を解決する 4 段階の優先順位。 ## [00:03] このチュートリアルで作るもの まず具体的な目標を提示する。視覚的な図や類比を使ってコードを説明するよう Claude に教えるスキルを構築する。スキルが完成したら、Claude が内部でどのようにスキルを受け取り実行するかも追う。 > *"This skill will teach Claude how we would like it to explain code using visual diagrams and analogies."* ## [00:18] スキルファイルの作成 個人スキルはホームディレクトリ下(プロジェクト内ではない)に置く。最初のステップは `~/.claude/skills/` の中にスキル名のディレクトリを作り、その中に SKILL.md ファイルを一つ置くことだ。3 つのセクションが重要になる。`name`(起動時に Claude が保存する識別子)、`description`(スキルを発動するかどうかを Claude が判断する際の照合基準)、そして 2 番目の `---` 区切り文字以降のすべて(スキルが発動したときに Claude が従う実際の指示)。 > *"Take into consideration that we're creating a directory with the skill name inside of the skills directory."* ## [00:52] スキルのロードとテスト Claude Code はスキルを起動時にスキャンするため、ファイルを作成したらセッションの再起動が必要だ。`/skills` を実行すると、作成したスキル名が一覧に表示されるはずだ。テストするには、変更を加えたブランチに切り替え、「Write a PR description for my changes」と自然言語でリクエストを送る。Claude は PR description スキルを使用していることを表示し、diff を読み込んでテンプレートに合った説明を毎回同じフォーマットで書き出す。 > *"Claude will then show you that it's using the PR description skill."* ## [01:25] Claude がスキルをロードする仕組み 起動時、Claude Code は 4 か所をスキャンする。エンタープライズ管理設定、個人の `~/.claude/skills/`、プロジェクトの `.claude/` ディレクトリ、インストール済みのプラグイン。この段階では `name` と `description` だけをロードし、全コンテンツはロードしない。リクエストが届くと、Claude は保存された説明と照合する。「explain what this function does」は「explain code with visual diagrams」と重なるため、スキルが一致する。Claude は完全な SKILL.md を読み込む前に確認を求め、どのコンテキストが注入されているかをユーザーが常に把握できるようにする。 > *"It loads only the name and description of each skill, not the full content. This is important later."* ## [02:02] 優先順位ルールと名前の競合 スキルを同梱したリポジトリをクローンすると名前の競合が生じる可能性がある。Claude は固定の優先順位で解決する。エンタープライズ(最高位)→ 個人 → プロジェクト → プラグイン(最低位)。エンタープライズの `code-review` スキルは、同名の個人スキルを常に上書きする。実践的な対策は説明的な命名だ。汎用的な `review` の代わりに `security-review` や `frontend-pr-review` を使えば、そもそも競合が起きない。 > *"If your company has an enterprise code review skill and you create a personal code review skill, the enterprise version of that takes precedence."* ## [02:52] スキルの更新と削除 スキルの更新は SKILL.md を直接編集して保存するだけでよい。削除はディレクトリごと消す。どちらの操作も、変更を反映させるには Claude Code の再起動が必要だ。スキルのリストはセッション起動時に一度だけ構築され、ファイルの変更はリアルタイムで監視されない。 > *"Edit the skill.md file to update a skill and restart Claude Code for changes to take effect."* ## 登場人物・用語 - **Anthropic チュートリアルナレーター** (人物): Claude Code スキルシリーズのスキル作成チュートリアルを一人で進行するホスト - **Claude Code** (ソフトウェア): Anthropic が提供する Claude の CLI ツール。起動時にスキルをスキャンし、ユーザーのリクエストがスキルの説明と一致すると適用する - **SKILL.md** (概念): スキルを定義する唯一のファイル。YAML フロントマター(name、description)と、2 番目の `---` 区切り文字以降の自由記述の指示テキストで構成される - **スキル** (概念): Claude に一貫した動作パターンを教える、再利用可能な名前付き指示セット。SKILL.md を含むディレクトリとして保存される - **エンタープライズスキル** (概念): 組織が管理するスキルで、4 段階の優先順位の最上位に位置し、個人・プロジェクト・プラグインのスキルより優先される - **Anthropic** (組織): Claude および Claude Code の開発元。claude.com/resources/courses でこのチュートリアルシリーズを公開している
Skills と他の Claude Code 機能の違い
Claude Code には5つのカスタマイズ手段がある——Skills、CLAUDE.md、サブエージェント、Hooks、MCP サーバーだ。それぞれ異なる用途のために設計されている。この3分間のチュートリアルでは、各選択肢を正しいユースケースに対応させ、CLAUDE.md で十分な場面で Skills を作ってしまったり、サブエージェントが必要な場面で Hooks を設定してしまうミスを防ぐ。 ## [00:02] 5つのカスタマイズ手段、1つの選択問題 Claude Code には動作を制御する5つの手段がある:Skills、CLAUDE.md、サブエージェント、Hooks、MCP サーバー。解説者はこの5つを素早く挙げた後、「これらは何か?」という問いから「どれをここで使うべきか?」という問いへすぐに軸を移す。 > *"それぞれ異なる問題を解決します。いつどれを使うかを知ることで、間違ったものを作らずに済みます。"* その後の内容は、この一文への答えとして構成されている。 ## [00:18] CLAUDE.md vs Skills:常時適用 vs オンデマンド CLAUDE.md は Claude が会話の開始時に毎回読み込むファイルで、有効化の操作は不要だ。フレームワークの選択、コーディングスタイル、データベースのルールなど、忘れてはならないプロジェクト全体の制約を置く場所として適している。Skills は対照的にオンデマンドで読み込まれる——PR レビューのチェックリストは、実際にレビューを依頼したときだけコンテキストに入り、コードを書いているときには現れない。 > *"Use Claude MD for project-wise standards that always apply constraints like never modify the database schema, framework preferences, and coding style."* 判断基準は「常時性」と「関連性」だ。プロジェクト内のすべてのプロンプトに適用すべき指示なら CLAUDE.md へ。特定の場面でしか使わないなら Skills へ。 ## [01:03] Skills vs サブエージェント:共有コンテキスト vs 独立実行 Skills は現在の会話に知識を注入する——その指示は既存のコンテキストに加わる。サブエージェントは異なる動き方をする:タスクを受け取り、独立した実行コンテキストで処理し、メインの会話に触れることなく結果を返す。 > *"Use sub agents when you want to delegate a task to a separate execution context. You need different tool access that the main conversation does. You want isolation between delegated work and your main context."* 専門知識を会話全体を通じて Claude の推論に反映させたいなら Skills を使う。メインセッションと委託作業の間に明確な境界を設けたい場合——異なるツールアクセス、コンテキストの汚染なし——はサブエージェントを使う。 ## [01:42] Hooks vs Skills:イベント駆動 vs リクエスト駆動 Hooks はイベントに応じて自動的に実行される——Claude がファイルを保存するたびにリンターを走らせたり、特定のツール呼び出しの前に入力を検証したりする。トリガーは問いかけの内容ではなく、Claude の行動だ。Skills はその逆で、リクエスト駆動——クエリが一致したときに起動する。 > *"A hook might run a llinter every time Claude saves a file or validate input before certain tool calls. They're all event driven, while skills, they're request driven. They activate based on what you're asking."* システムイベントに対して無条件で発動させたい動作は Hooks へ。聞かれたときに Claude の思考を形作るものは Skills へ。 ## [02:15] 5つを組み合わせた包括的なカスタマイズ うまく設定された Claude Code では、各ツールがその本来の役割を担う:CLAUDE.md は常時有効なプロジェクト標準を持ち、Skills はすべてのプロンプトに混在させるべきでないタスク固有の知識を提供し、Hooks は自動化された副作用を処理し、サブエージェントは分離された委託作業を行い、MCP サーバーは外部ツールへのアクセスを提供する。これらは代替関係にあるのではなく、組み合わせて使うものだ。 > *"Don't force everything into skills when another option fits best. You can use multiple at a time."* Skills はトピックが関連したときに自動起動し、CLAUDE.md は常に存在し、サブエージェントは独立して動き、Hooks はイベントで発火し、MCP は外部ツールを提供する。各関心事に適したレイヤーを選び、自由に組み合わせよう。 ## 登場人物・概念 - **Anthropic チュートリアルナレーター** (人物):Anthropic を代表してこの Claude Code skills チュートリアルシリーズを進行する人物。 - **Claude Code** (ソフトウェア):Anthropic の AI 搭載コーディングアシスタント。本チュートリアルシリーズの主題。 - **Skills** (概念):ユーザーのリクエストと一致したときに起動するオンデマンドの知識パッケージ。指示を現在の会話コンテキストに注入する。 - **CLAUDE.md** (概念):Claude Code のすべての会話で自動的に読み込まれる設定ファイル。常時有効なプロジェクト全体の標準と制約に使用する。 - **サブエージェント** (概念):委託されたタスクをメインの会話から分離して処理するために独立起動される実行コンテキスト。 - **Hooks** (概念):ファイル保存やツール呼び出しなど、特定の Claude アクションに対してユーザーのリクエストとは無関係に自動発火するイベント駆動の自動化。 - **MCP サーバー** (ソフトウェア):Claude Code セッションに外部ツールを提供する Model Context Protocol サーバー。 - **Anthropic** (組織):Claude Code の開発元。Claude Code skills チュートリアルシリーズの制作・公開者。