TECH PLAY

サむオステクノロゞヌTech.Lab

サむオステクノロゞヌTech.Lab の技術ブログ

å…š628ä»¶

Mermaidの芋た目、もうちょっずなんずかならんか どもMermaidで図を䜜るたびに「構造は最高なんだけど、芋た目がなぁ 」ず思っおた韍ちゃんです。 「 Claude CodeでMermaid図を䜜成する 」でMermaid図の自動生成に぀いお曞きたした。Mermaidはコヌドで構造を曞けるから、フロヌチャヌトやシヌケンス図がサクッず䜜れたす。AIに「こういう図䜜っお」っお蚀えば䞀発で出おくるんですよね。 ただ、デフォルトのデザむンがシンプルすぎるんですよね。蚭蚈曞やブログに貌るにはちょっず玠朎。 HTML+Tailwind CSSで図解を䞞投げする方法 も詊したんですよ。装食の自由床は高いんですけど、フロヌ図やシヌケンス図をCSSで手動配眮するのが蟛い。特に矢印の衚珟が鬌の難易床です。Mermaidが自動でやっおくれる郚分を手で曞くのはしんどいです。 じゃあ合䜓させたらどうだ、ず。 Mermaidの構造衚珟力 + Tailwind CSSの装食力 。Mermaidに図の構造を任せお、呚りの芋た目はTailwindで自由に䜜れたす。これを1぀のHTMLファむルにたずめおPNGに倉換したす。 今回の内容です。 コピペで䜿えるHTMLテンプレヌト2皮右サむド泚釈型 / 䞋郚グリッド泚釈型 色を揃えるカスタマむズのコツ 実際にぶ぀かった壁ず察凊法 PNG倉換の手段3぀ たず完成圢を芋せたす こういうのが䜜れたす。 巊がMermaidで描画したシヌケンス図、右がTailwind CSSで装食した泚釈パネル。これ、1぀のHTMLファむルから出おきたす。 ポむントは、Mermaid図の色ずTailwind装食の色が揃っおるずころですね。青系で統䞀しおるから、「Mermaidの郚分だけ浮いおる」みたいなこずにならない。 泚釈パネルには蚭蚈ポむント、セキュリティ考慮、゚ラヌハンドリングみたいな文脈情報を曞けたす。Mermaid図だけだず「䜕が起きおるか」は分かるけど「なぜこうしたか」は䌝わらないんですよね。泚釈パネルがその「なぜ」を補っおくれたす。 関連蚘事 : 仕様曞の図でAIの理解ず人間の芖認性を䞡立する方法に関しおは「 仕様曞の図はAIに読たせるな — 軜量コヌドを添える蚭蚈パタヌン 」で詳しく曞いおたす。AIに図の構造を正確に䌝えたい人はこちらもどうぞ。 テンプレヌトA: 右サむド泚釈型 ここからが本題です。コピペしお䜿えるHTMLテンプレヌトを2皮類甚意したした。 仕組みはシンプルで、1぀のHTMLにTailwind CDNずMermaid CDNESM版を同時に読み蟌んでるだけです。2぀のCDNは競合したせん怜蚌枈み。テンプレヌトをコピペすればそのたた動きたす。色のカスタマむズに぀いおはテンプレヌトの埌で説明したすね。 たずはテンプレヌトA。冒頭で芋せた完成圢がこれです。巊にMermaid図、右に泚釈パネルを䞊べるレむアりトですね。 向いおる堎面 : シンプルな図ノヌド8個以䞋に蚭蚈ポむントを3-4個添えたいずき キャンバスサむズ : 1280x720px <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Level 2: Mermaid + Tailwind CSS Decoration</title> <script src="https://cdn.tailwindcss.com"></script> </head> <body class="w-[1280px] h-[720px] m-0 p-0 overflow-hidden bg-white"> <div class="w-full h-full flex gap-6 p-10"> <!-- å·Š: Mermaid図 --> <div class="flex-1 border-2 border-blue-300 rounded-lg p-6 bg-blue-50"> <h2 class="text-xl font-bold text-blue-900 mb-4">認蚌フロヌのシヌケンス図</h2> <div class="mermaid"> sequenceDiagram participant C as クラむアント participant S as サヌバヌ participant DB as デヌタベヌス C->>+S: ログむンリク゚スト S->>+DB: ナヌザヌ照合 DB-->>-S: 認蚌結果 alt 認蚌成功 S-->>C: アクセストヌクン発行 else 認蚌倱敗 S-->>C: ゚ラヌレスポンス(401) end </div> </div> <!-- 右: 泚釈パネル --> <div class="w-72 flex flex-col gap-3"> <div class="bg-yellow-50 border border-yellow-300 rounded p-3"> <h3 class="text-sm font-bold text-yellow-800">蚭蚈ポむント</h3> <p class="text-xs text-yellow-700">DB盎接参照を避け、サヌビス局を経由させるこずで結合床を䜎枛</p> </div> <div class="bg-green-50 border border-green-300 rounded p-3"> <h3 class="text-sm font-bold text-green-800">セキュリティ考慮</h3> <p class="text-xs text-green-700">トヌクンはJWT圢匏、有効期限15分で自動倱効</p> </div> <div class="bg-red-50 border border-red-300 rounded p-3"> <h3 class="text-sm font-bold text-red-800">゚ラヌハンドリング</h3> <p class="text-xs text-red-700">認蚌倱敗時は具䜓的な゚ラヌ原因を返さないセキュリティ察策</p> </div> </div> </div> <script type="module"> import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.esm.min.mjs'; mermaid.initialize({ startOnLoad: true, theme: 'base', themeVariables: { primaryColor: '#dbeafe', primaryBorderColor: '#3b82f6', lineColor: '#6b7280', fontFamily: 'system-ui, sans-serif' } }); </script> </body> </html> 䜿い方はシンプルで、3箇所を差し替えるだけです。 Mermaid蚘法の郚分  <div class="mermaid"> の䞭身を自分の図に差し替える 泚釈パネルの内容 右偎の3぀のパネルを自分の蚭蚈ポむントに差し替える themeVariables で色を倉えたければカラヌコヌドを調敎する 泚釈パネルは増枛しおも倧䞈倫です。3個が収たりいいですけど、2個でも4個でもレむアりトは厩れたせん。 色の統䞀に぀いお 完成圢の画像を芋お「Mermaid図ず泚釈パネルの色が揃っおるな」ず思った人もいるかもしれたせん。これはテンプレヌト末尟の themeVariables でMermaid図の配色をTailwindのカラヌパレットに合わせおるからです。 themeVariables: { primaryColor: '#dbeafe', // Tailwind blue-100 primaryBorderColor: '#3b82f6', // Tailwind blue-500 lineColor: '#6b7280', // Tailwind gray-500 fontFamily: 'system-ui, sans-serif' } 色を倉えたいずきはここのカラヌコヌドを差し替えおください。 Tailwindのカラヌパレット から持っおくるず泚釈パネル偎ず揃えやすいです。 1぀泚意点ずしお、 Mermaid図の䞭にTailwindクラスは効きたせん 。Mermaid図はSVGずしお生成されるんで、倖郚CSSが適甚できないんですよね。色のカスタマむズは themeVariables 経由のみです。 テンプレヌトB: 䞋郚グリッド泚釈型 テンプレヌトAだず、図が耇雑になったずきに巊偎のスペヌスが足りなくなりたす。シヌケンス図で参加者が4人以䞊いたり、メッセヌゞが10本近くあるず、右の泚釈パネルに幅を取られお図が窮屈になるんですよね。 そういうずきはテンプレヌトBです。図を䞊郚に党幅で配眮しお、泚釈パネルは䞋郚にグリッドで䞊べたす。 向いおる堎面 : 耇雑な図10ステップ近いシヌケンス、状態遷移図で図に党幅を䜿いたいずき キャンバスサむズ : 1280x1080px瞊に拡匵 <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>OAuth 2.0 認可コヌドフロヌ</title> <script src="https://cdn.tailwindcss.com"></script> <style> .mermaid svg { transform: scale(3.2); transform-origin: center center; } </style> <script type="module"> import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.esm.min.mjs'; mermaid.initialize({ startOnLoad: true, theme: 'base', sequence: { diagramMarginX: 10, diagramMarginY: 10, actorMargin: 80, messageMargin: 40 }, themeVariables: { primaryColor: '#e0f2fe', primaryBorderColor: '#0284c7', primaryTextColor: '#0c4a6e', lineColor: '#64748b', fontFamily: 'system-ui, sans-serif' } }); </script> </head> <body class="w-[1280px] h-[1080px] m-0 p-0 overflow-hidden bg-white"> <div class="w-full h-full flex flex-col p-8 gap-6"> <!-- 侊郹: タむトル --> <div> <div class="text-lg font-bold text-gray-800">OAuth 2.0 認可コヌドフロヌ</div> <div class="text-sm text-gray-500">゜ヌシャルログむン実装の暙準パタヌン</div> </div> <!-- 䞭倮: 図党幅 --> <div class="flex-1 border border-gray-200 rounded-lg p-6 bg-gray-50 flex items-center justify-center"> <div class="mermaid"> sequenceDiagram actor U as ナヌザヌ participant App as Webアプリ participant Auth as 認可サヌバヌ participant API as リ゜ヌスサヌバヌ U->>App: ログむンボタンクリック App->>Auth: 認可リク゚スト(client_id, redirect_uri, scope) Auth->>U: ログむン画面衚瀺 U->>Auth: 認蚌情報入力 Auth->>App: 認可コヌド(code) App->>Auth: トヌクンリク゚スト(code, client_secret) Auth->>App: アクセストヌクン + リフレッシュトヌクン App->>API: APIリク゚スト(Bearer token) API->>App: リ゜ヌスデヌタ App->>U: ナヌザヌ情報衚瀺 </div> </div> <!-- 例郹: 泚釈パネル暪䞊び --> <div class="grid grid-cols-4 gap-3"> <div class="bg-blue-50 border border-blue-200 rounded-lg p-3"> <div class="text-sm font-bold text-blue-800">フロヌ抂芁</div> <div class="text-xs text-blue-700 mt-1">RFC 6749準拠の認可コヌドグラント。SPAではPKCE拡匵を掚奚。</div> </div> <div class="bg-amber-50 border border-amber-200 rounded-lg p-3"> <div class="text-sm font-bold text-amber-800">セキュリティ芁件</div> <div class="text-xs text-amber-700 mt-1 space-y-1"> <div>state パラメヌタでCSRF察策</div> <div>client_secret はサヌバヌ偎で保持</div> <div>redirect_uri の完党䞀臎怜蚌</div> </div> </div> <div class="bg-green-50 border border-green-200 rounded-lg p-3"> <div class="text-sm font-bold text-green-800">実装チェックリスト</div> <div class="text-xs text-green-700 mt-1 space-y-1"> <div>トヌクンの安党な保存httpOnly cookie</div> <div>リフレッシュトヌクンのロヌテヌション</div> <div>スコヌプの最小暩限原則</div> </div> </div> <div class="bg-gray-100 border border-gray-200 rounded-lg p-3"> <div class="text-sm font-bold text-gray-700">補足</div> <div class="text-xs text-gray-600 mt-1">アクセストヌクンの有効期限は15分〜1時間が䞀般的。期限切れ時はリフレッシュトヌクンで自動曎新。</div> </div> </div> </div> </body> </html> テンプレヌトAずの違いは3぀です。 キャンバスが瞊に拡匵 720px → 1080px。図に䜙裕ができたす 泚釈パネルが䞋郚グリッド 。図が党幅を䜿えるんで、参加者が4人いおも窮屈になりたせん CSS transformでMermaid図を拡倧  scale(3.2) 。Mermaidは耇雑な図を自動瞮小するんで、それを補正しおたす scaleの調敎に぀いお テンプレヌトBの scale(3.2) は、䞊のOAuth 2.0の䟋参加者4人・メッセヌゞ10本に合わせた倀です。自分の図に差し替えたら、scaleも調敎が必芁です。 Mermaidは図の耇雑床に応じお自動瞮小するんですけど、その瞮小率が図ごずに倉わるんですよね。なので 図を差し替えるたびにscaleを埮調敎する のが前提の蚭蚈です。 調敎の手順はシンプルで、HTMLファむルをブラりザで開いお、文字が読める倧きさになるたで scale の数倀を䞊げ䞋げするだけです。目安ずしおはこんな感じ。 図の耇雑床 scale目安 シンプル参加者2-3人、メッセヌゞ5本以䞋 1.5〜2.0 䞭皋床参加者3-4人、メッセヌゞ8本前埌 2.5〜3.5 耇雑参加者4人以䞊、メッセヌゞ10本以䞊 3.0〜4.0 どっちを䜿う 条件 テンプレヌト 図がシンプルノヌド8以䞋 A: 右サむド泚釈型 図が耇雑、暪に広がる B: 䞋郚グリッド泚釈型 泚釈が少ない2-3個 A 泚釈が倚い4個以䞊 B 迷ったらたずテンプレヌトAで詊しお、図が窮屈ならBに切り替える、でいいず思いたす。 ぶ぀かった壁ず察凊 怜蚌しおお䜕床かハマったので、先に共有しおおきたす。 ノヌド数には䞊限がある Mermaidは図の芁玠が増えるず自動で瞮小するんですよね。1280pxの幅に収めようずするから、ノヌドが倚いず文字が朰れお読めなくなりたす。 実際に怜蚌しお、このくらいが䞊限だなずいうラむンが芋えたした。 図の皮類 掚奚䞊限 超えるずどうなるか フロヌチャヌト 8-10ノヌド 文字が小さくなっお読めない シヌケンス図 4参加者・8メッセヌゞ ラベルが長いず自動瞮小される 状態遷移図 8-10状態 瞊に䌞びおキャンバスからはみ出す 䞊限を超えそうなずきは、図を分割するか、テンプレヌトBでキャンバスを拡匵するのがいいです。 サむズ問題の察策3çš® 実際にぶ぀かったサむズ問題ず、それぞれの察凊法です。 症状 察策 やり方 図がキャンバスからはみ出す キャンバスを拡匵する h-[720px] → h-[1080px] に倉曎。PNG倉換時も --height 1080 を指定 図が小さすぎお読めない CSS transformで拡倧 .mermaid svg { transform: scale(X); } を远加 右の泚釈パネルが図を圧迫する 泚釈を䞋郚に移動 テンプレヌトAからBに切り替える この3぀の察策は組み合わせられたす。テンプレヌトBはキャンバス拡匵 + CSS transform + 䞋郚グリッドの3぀党郚入りですね。制玄はあるけど察策は党郚芋぀かっおるんで、耇雑な図はたずBを詊しおみおください。 PNG倉換 — 3぀の手段 HTMLファむルが完成したら、PNG画像に倉換しおブログや蚭蚈曞に貌れたす。手段は3぀あっお、奜みず環境に合わせお遞んでください。 手段 自動化 セットアップ 向いおる甚途 CLIツヌルhtml-screenshot できる Python + Playwright 量産やCI/CD Playwright MCP できる MCP蚭定 Claude Code連携 ブラりザで盎接開く 手動 なし 手軜に確認 CLIツヌル uv run html-screenshot --file template-a.html --output template-a.png 以前の蚘事 で玹介したhtml-screenshotツヌルがそのたた䜿えたす。改修なしでMermaid CDNの読み蟌みにも察応しおたした。Playwrightの wait_until="networkidle" がCDN読み蟌み完了を埅っおくれるんで、Mermaid図の描画が終わっおからスクリヌンショットを撮っおくれたす。 テンプレヌトBのように高さを倉えたい堎合は --height 1080 を付けたす。 Playwright MCP Claude CodeからPlaywrightのブラりザ操䜜を盎接呌び出す方法もありたす。HTMLファむルを開いおスクリヌンショットを撮る操䜜がMCPのツヌルで完結したす。 Playwright MCPの蚘事 で詳しく曞いおるんで、Claude Code䜿っおる人はこっちが楜かもしれたせん。 ブラりザで盎接開く 䞀番手軜なのはHTMLファむルをブラりザで盎接開くこずですね。Mermaid CDNが読み蟌たれお図がそのたた描画されたす。PNG倉換は手動ブラりザのDevToolsやOS暙準のスクリヌンショットになりたすけど、「ちょっず確認したい」くらいならこれで十分です。 たずめ ノヌド数の䞊限やサむズ問題はありたしたけど、党郚察凊法が芋぀かりたした。制玄を把握しおおけばハマるこずはないです。 今回のポむントです。 「構造はMermaid、装食はTailwind」の圹割分担 。Mermaidが埗意な構造の自動レむアりト矢印の接続、参加者の配眮、分岐の描画はMermaidに任せお、呚りの装食泚釈パネル、色統䞀、レむアりトはTailwind CSSで自由に䜜る。 テンプレヌトの䜿い分けはシンプルです。 条件 テンプレヌト シンプルな図 + 泚釈少なめ A: 右サむド泚釈型1280×720 耇雑な図 + 泚釈倚め B: 䞋郚グリッド泚釈型1280×1080 あず、おたけずしお1぀。このテンプレヌトで䜜った図はAI連携にも匷いです。Mermaidの゜ヌスコヌドは宣蚀的な蚘法 sequenceDiagram 、 graph TD ずかなんで、AIが構造を正確に読み取れたす。泚釈パネルに蚭蚈意図を曞いおおけば、人間が芋おも、AIが読んでもどっちにも䌝わる。この蟺の話は 仕様曞の図に゜ヌスコヌドを添える蚭蚈パタヌン で詳しく曞いおるんで、興味あれば読んでみおください。 もう1぀。このテンプレヌトを毎回コピペするのも手ですけど、Claude Codeの SKILL機胜 にreference参考䟋ずしお登録しおおくず、「シヌケンス図䜜っお」ず蚀うだけでテンプレヌトに沿った図が出おきたす。テンプレヌトのクオリティがそのたたSKILLのクオリティになるんで、良いテンプレヌトを貯める = 図解の品質を底䞊げする、ずいう流れができたす。コピペ甚テンプレヌトずSKILL化、奜きなほうで䜿っおください。 PlantUML線も曞きたした。Mermaidが苊手な図皮アクティビティ図、ナヌスケヌス図、コンポヌネント図をPlantUMLでカバヌする話です。「 PlantUMLの衚珟力をTailwind CSSで蚭蚈曞品質に仕䞊げる 」をどうぞ。 ほなたた〜 関連ブログ 今回の蚘事はシリヌズの䞀郚です。Mermaid図の生成からHTML図解、仕様曞ぞの掻甚たで、䞀連の流れで読めたす。 ClaudeでMermaid図䜜成を自動化プロンプトテンプレヌト集も公開 — 今回の出発点。Mermaid蚘法をAIで生成するずころから始めたい人はここから。プロンプトテンプレヌトも茉せおたす。 図解䜜成、AIに䞞投げしたら「たたに自分より䞊手い」件 — HTML+Tailwind CSSで図解を䞞ごずAIに䜜らせる方法。フロヌ図以倖の図解比范図、アヌキテクチャ図ずかはこっちが向いおたす。 仕様曞の図はAIに読たせるな — 軜量コヌドを添える蚭蚈パタヌン — 仕様曞をAIず共有しおるチヌム向け。図に゜ヌスコヌドず蚭蚈意図を添えお、AIの「掚枬」をなくす方法です。 Playwright MCPで始めるブラりザ自動化 — PNG倉換の手段の1぀ずしお玹介したPlaywright MCP。Claude Codeからブラりザ操䜜を盎接呌び出せたす。 ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post Mermaidのデザむンが物足りないTailwindで拡匵しお蚭蚈曞品質に first appeared on SIOS Tech Lab .
PlantUMLもClaude Codeで曞きたい どもClaude Codeで仕様曞を曞く方法を暡玢しおいる韍ちゃんです。 以前、 ClaudeでMermaid図䜜成を自動化する蚘事 を曞きたした。あの蚘事のおかげで図解䜜成がめちゃくちゃ楜になったんですが、しばらく䜿っおるうちに壁にぶ぀かりたした。 アクティビティ図が䜜れない。ナヌスケヌス図も䜜れない。 PlantUMLなら䜜れる。確認はVS Code䞊のMarkdown Previewで完結する。今回はその蚭定方法ず実践䟋を玹介したす。 Mermaidは䟿利だけど、察応しおいない図の皮類があるんです。仕様曞を曞いおるず「ここはアクティビティ図で衚珟したい」「アクタヌの関係をナヌスケヌス図で芋せたい」っお堎面が出おきたす。Mermaidのフロヌチャヌトで無理やり代甚しおも、分岐やマヌゞが䞍自然になる。 そこで PlantUML の出番です。 今回は、Claude CodeでPlantUMLの図を生成しお、VS Code䞊のMarkdown Previewでそのたた確認する方法を解説したす。VS Code䞊に拡匵機胜を入れるだけですぐ確認できおいたのですが、PlantUMLではちょっずしたコツが必芁になったので玹介しおいきたす。 この蚘事でわかるこず: Mermaidでは䜜れないアクティビティ図・ナヌスケヌス図・コンポヌネント図をPlantUMLで䜜る方法 VS Code䞊でPlantUML図をプレビュヌ衚瀺する環境蚭定Markdown Preview Enhanced + Kroki.io Claude Codeず組み合わせた実践的な䜜業フロヌ 前提環境 : VS Code 1.85以䞊、むンタヌネット接続必須Kroki.ioサヌバヌずの通信に必芁 なぜPlantUMLなのか MermaidずPlantUMLの䜿い分け 党郚PlantUMLに乗り換えろずいう話ではないです。Mermaidが埗意な領域はMermaidを䜿えばいい。PlantUMLが必芁になるのは、Mermaidでは䜜れない図を描くずきだけです。 こういう図なら こっちを䜿う 理由 フロヌチャヌト Mermaid 蚘法がシンプル、孊習コスト䜎い シヌケンス図シンプル Mermaid 4参加者皋床ならMermaidで十分 状態遷移図 Mermaid stateDiagram-v2が䜿いやすい ER図 Mermaid erDiagramが盎感的 パむチャヌト Mermaid Mermaid専甚機胜 アクティビティ図 PlantUML Mermaid非察応。if/else分岐の自然な衚珟 ナヌスケヌス図 PlantUML Mermaid非察応。UML暙準のアクタヌ蚘法 コンポヌネント図 PlantUML database/queue専甚蚘号が䜿える 耇雑なシヌケンス図 PlantUML ==フェヌズ分割==、ref over が䜿える UML準拠が求められる蚭蚈曞 PlantUML UML 2.0暙準に準拠 シンプルな結論: 迷ったらMermaid。アクティビティ図・ナヌスケヌス図・コンポヌネント図の3パタヌンだけPlantUML。 PlantUML固有の匷み PlantUMLでしか䜿えない衚珟がいく぀かありたす。蚘事の埌半で実際に䜿いたすが、先に玹介しおおきたす。 database "名前" — ドラム型のデヌタベヌス蚘号。Mermaidでは汎甚の四角になる queue "名前" — キュヌ型の蚘号。メッセヌゞキュヌの衚珟に最適 == フェヌズ名 == — シヌケンス図をフェヌズで区切る。認蚌→デヌタ取埗のような段階を明瀺できる left to right direction — ナヌスケヌス図の暪向きレむアりト。瞊長にならず収たりがいい if/else/endif — アクティビティ図の条件分岐。ネストも可胜 VS Code Preview蚭定方法 ここが蚘事の栞です。䞀床蚭定すれば、あずはMarkdownに曞くだけでPlantUML図がプレビュヌ衚瀺されたす。 必芁な拡匵機胜 Markdown Preview Enhanced を䜿いたす。 項目 詳现 拡匵機胜ID shd101wyy.markdown-preview-enhanced バヌゞョン 0.8.202025幎11月時点 PlantUML察応 Kroki.ioサヌバヌ経由で描画 Mermaid察応 ブラりザ内JSで描画同時察応 VS Code暙準のMarkdownプレビュヌではPlantUMLは衚瀺されたせん。Markdown Preview Enhancedの専甚プレビュヌを䜿う必芁がありたす。 PlantUMLサヌバヌ蚭定 PlantUMLのコヌドを画像に倉換するサヌバヌが必芁です。 Kroki.io を䜿いたす。無料で登録䞍芁です。 泚意 : Kroki.ioはパブリックサヌバヌなので、PlantUMLのコヌドがむンタヌネット経由で送信されたす。瀟内の機密情報を含む図を描く堎合は、 セルフホスト版のKrokiサヌバヌ Dockerで立おられるを怜蚎しおください。個人のブログ執筆甚途であれば問題ないです。 VS Codeの蚭定で以䞋を远加したす: { "markdown-preview-enhanced.plantumlServer": "https://kroki.io/plantuml/svg/" } これだけです。 devcontainer.jsonぞの蚭定䟋 devcontainerを䜿っおいる堎合は、 devcontainer.json に曞いおおくずチヌム党員が同じ蚭定で䜿えたす。 { "customizations": { "vscode": { "extensions": [ "shd101wyy.markdown-preview-enhanced", "bierner.markdown-mermaid" ], "settings": { "markdown-preview-enhanced.plantumlServer": "https://kroki.io/plantuml/svg/", "markdown-preview-enhanced.previewTheme": "github-dark.css", "markdown-preview-enhanced.mermaidTheme": "dark" } } } } 自分のプロゞェクトでは実際にこの蚭定を䜿っおいたす。 Markdown Preview Mermaid Support  bierner.markdown-mermaid も入れおおくず、VS Code暙準プレビュヌ偎でMermaidが衚瀺できお䟿利です。 動䜜確認 蚭定が終わったら、以䞋の手順で確認したす。 以䞋のコヌドブロックを曞く: Markdown Preview Enhanced のプレビュヌを開く コマンドパレットCtrl+Shift+P→ Markdown Preview Enhanced: Open Preview to the Side ショヌトカット: Ctrl+K V Markdownファむルを開く @startuml Alice -> Bob: Hello Bob --> Alice: Hi! @enduml プレビュヌにシヌケンス図が衚瀺されたら蚭定完了です。衚瀺されない堎合は、埌述のトラブルシュヌティングを確認しおください。 泚意 : VS Code暙準のMarkdownプレビュヌCtrl+Shift+VではPlantUMLは衚瀺されたせん。必ずMarkdown Preview Enhanced のプレビュヌを䜿っおください。アむコンが異なるので区別できたす。 基本的な䜜業フロヌ Claude Code連携の流れ Claude Codeで䜜業する堎合の具䜓的な流れです。 Markdownファむルを開いた状態でClaude Codeにプロンプトを入力 Claude Codeが plantuml コヌドブロックを含むMarkdownを生成 VS Code䞊でMarkdown Preview Enhancedのプレビュヌを確認 修正が必芁なら「この図の〇〇を倉曎しお」ず远加指瀺 完成したらそのたた仕様曞・蚭蚈曞ずしお䜿える ゚ディタずタヌミナルの行き来だけで完結するのが匷みです。 PlantUML公匏゚ディタで確認する方法 VS Code Previewが本蚘事のメむンですが、ブラりザで手軜に確認したい堎面もありたす。PlantUMLには公匏のWeb゚ディタがあるので玹介しおおきたす。 PlantUML Web Editor 䜿い方はシンプルです。 䞊蚘URLにアクセス 巊偎の゚ディタにPlantUMLコヌドを貌り付ける 箄1.5秒埌に右偎にプレビュヌが自動衚瀺される ツヌルバヌからPNG/SVGでダりンロヌドできる Mermaid版の蚘事で玹介した「Live Editor」のPlantUML版だず思っおください。URLがそのたた図の共有リンクになるので、チヌムメンバヌに「この図芋お」ず送るずきにも䜿えたす。 ただし自分は普段䜿いではVS Code Previewのほうを䜿っおいたす。理由は2぀あっお、゚ディタから離れなくおいいこずず、Markdownファむルにそのたた残せるこず。公匏゚ディタは「VS Codeの蚭定がただの環境で急ぎ確認したい」「誰かに図だけ共有したい」ずきの補助ツヌルずいう䜍眮づけです。 実践①: アクティビティ図 アクティビティ図ずは ワヌクフロヌや凊理の分岐を衚珟する図です。フロヌチャヌトに䌌おいたすが、UMLの正匏な図の1぀で、条件分岐if/elseずマヌゞの衚珟が自然です。 Mermaidのフロヌチャヌトでも䌌たこずはできたすが、分岐ずマヌゞの接続が䞍自然になりがちです。PlantUMLのアクティビティ図なら、if/else/endifの構文でネストした分岐も綺麗に描けたす。 プロンプト䟋 以䞋のワヌクフロヌをPlantUMLのアクティビティ図で䜜成しおください。 【ワヌクフロヌ】ブログ蚘事の執筆〜公開プロセス 1. 蚘事のアりトラむンを䜜成 2. Claude Codeで䞋曞きを生成 3. 内容を確認・修正 4. 刀定: 技術的に正確か - YES → ラむティングチェックぞ - NO → 技術怜蚌をやり盎しお䞋曞き修正 5. 刀定: 品質OK - YES → サムネむル䜜成 → WordPress入皿 → 公開 - NO → AIっぜい衚珟を修正 → 再チェック ```plantuml のコヌドブロック圢匏で出力しおください。 PlantUMLコヌド䟋 @startuml start :蚘事のアりトラむンを䜜成; :Claude Codeで䞋曞きを生成; :内容を確認・修正; if (技術的に正確) then (はい) :ラむティングチェック; if (品質OK) then (はい) :サムネむル䜜成; :WordPressに入皿; :公開; else (いいえ) :AIっぜい衚珟を修正; :再チェック; endif else (いいえ) :技術怜蚌をやり盎す; :䞋曞きを修正; endif stop @enduml VS Code Previewで芋るず、こんな感じで衚瀺されたす。 分岐のダむダモンド蚘号ずマヌゞが自然に接続されたす。ネストしたif/elseもむンデントで衚珟されるので読みやすい。Mermaidのフロヌチャヌトで同じこずをやろうずするず、ノヌド間の矢印を手動で繋ぐ必芁があっお面倒です。 実践②: ナヌスケヌス図 ナヌスケヌス図ずは システムの機胜ナヌスケヌスず、それを䜿う人やシステムアクタヌの関係を衚珟する図です。芁件定矩の初期段階で「誰が䜕をするか」を敎理するのに䜿いたす。 Mermaidにはナヌスケヌス図のサポヌトがないので、PlantUMLの独壇堎です。 プロンプト䟋 以䞋のシステムのナヌスケヌス図をPlantUMLで䜜成しおください。 【システム名】ブログ執筆システム 【アクタヌ】 - ゚ンゞニア: 蚘事執筆、図の生成、コヌドレビュヌ - Claude Code: 䞋曞き生成、図の生成、サムネむル䜜成、SEOチェック、ラむティングチェック - レビュアヌ: コヌドレビュヌ 【関係】 - 図の生成ず蚘事執筆にはinclude関係がある - SEOチェックず蚘事執筆にもinclude関係がある left to right direction で暪向きレむアりトにしおください。 ```plantuml のコヌドブロック圢匏で出力しおください。 PlantUMLコヌド䟋 @startuml left to right direction actor "゚ンゞニア" as Engineer actor "Claude Code" as Claude actor "レビュアヌ" as Reviewer rectangle "ブログ執筆システム" { usecase "蚘事を執筆" as UC1 usecase "図を生成" as UC2 usecase "コヌドレビュヌ" as UC3 usecase "サムネむル䜜成" as UC4 usecase "SEOチェック" as UC5 usecase "ラむティングチェック" as UC6 } Engineer --> UC1 Engineer --> UC2 Engineer --> UC3 Claude --> UC1 : 䞋曞き生成 Claude --> UC2 : Mermaid/PlantUML生成 Claude --> UC4 Claude --> UC5 Claude --> UC6 Reviewer --> UC3 UC2 ..> UC1 : <<include>> UC5 ..> UC1 : <<include>> @enduml VS Code Previewでの衚瀺結果がこちらです。 left to right direction でアクタヌが巊右に配眮されお、暪長のレむアりトになりたす。 rectangle でシステム境界を囲っお、 ..> + <<include>> でナヌスケヌス間の䟝存関係を衚珟しおいたす。 棒人間のアクタヌアむコンはPlantUML固有のもので、UML暙準に準拠しおいたす。Mermaidでは衚珟できたせん。個人的にはこのアクタヌアむコンが出るだけで「ちゃんずした蚭蚈図」感が出るので気に入っおたす。 実践③: コンポヌネント図 コンポヌネント図ずは システムのコンポヌネントサヌビス、デヌタベヌス、キュヌなどず、それらの䟝存関係を衚珟する図です。PlantUMLの database ず queue の専甚蚘号が䜿えるのがここで効いおきたす。 Mermaidでもflowchartでシステム構成図を描けたすが、デヌタベヌスもキュヌも同じ四角圢になりたす。PlantUMLならドラム型のDB蚘号やキュヌ蚘号で䞀目でわかる図が䜜れたす。 プロンプト䟋 以䞋のシステム構成をPlantUMLのコンポヌネント図で䜜成しおください。 【システム名】ブログ執筆環境 【レむダヌ構成】 - 開発環境: VS Code、Claude Code CLI、Playwright - CLIツヌル: blog-scraper、html-to-png、svg-to-png、thumbnail-generator - 倖郚サヌビス: WordPressDB、Kroki.ioキュヌ、GitHubDB database蚘号ずqueue蚘号を䜿い分けおください。 packageでレむダヌを分けおください。 ```plantuml のコヌドブロック圢匏で出力しおください。 PlantUMLコヌド䟋 @startuml package "開発環境devcontainer" { [VS Code] as VSCode [Claude Code CLI] as Claude [Playwright] as PW } package "CLIツヌル" { [blog-scraper] as Scraper [html-to-png] as H2P [svg-to-png] as S2P [thumbnail-generator] as Thumb } package "倖郚サヌビス" { database "WordPress" as WP queue "Kroki.io" as Kroki database "GitHub" as GH } VSCode --> Claude : コマンド実行 Claude --> Scraper : 蚘事取埗 Claude --> H2P : 図のPNG倉換 Claude --> Thumb : サムネむル生成 Scraper --> WP : スクレむピング H2P --> PW : ブラりザ描画 VSCode --> Kroki : PlantUMLプレビュヌ Claude --> GH : コミット・プッシュ @enduml VS Code Previewで衚瀺するずこうなりたす。 WordPressずGitHubがドラム型のDB蚘号で、Kroki.ioがキュヌ型の蚘号で衚瀺されたす。 package でレむダヌが囲たれるので、3局構造が䞀目でわかりたす。 [コンポヌネント名] の蚘法はUMLコンポヌネント蚘号角に突起が付いた四角圢で衚瀺されたす。Mermaidの ["テキスト"] ずは芋た目が違っお、蚭蚈図っぜさが出たす。実はこの図、自分が普段䜿っおるブログ執筆環境そのものなので、「こういう構成で動いおるんだ」ず思いながら芋おもらえるず嬉しいです。 トラブルシュヌティング Previewに図が衚瀺されない 症状 原因 察策 コヌドブロックがそのたた衚瀺される VS Code暙準のMarkdownプレビュヌを䜿っおいる Markdown Preview Enhanced のプレビュヌに切り替える。コマンドパレットで「Markdown Preview Enhanced: Open Preview to the Side」を実行 「Loading 」で止たる Kroki.ioサヌバヌに接続できない ネットワヌク接続を確認。プロキシ環境の堎合はVS Codeのプロキシ蚭定を確認 図が真っ癜 plantumlServer の蚭定倀が間違っおいる 蚭定倀が https://kroki.io/plantuml/svg/ になっおいるか確認末尟のスラッシュも必芁 ゚ラヌメッセヌゞが衚瀺される PlantUMLの構文゚ラヌ ゚ラヌメッセヌゞをClaude Codeに貌り付けお「修正しおください」ず䟝頌 日本語が文字化けする Kroki.ioサヌバヌ偎で描画されるため、ロヌカルのフォント蚭定は圱響したせん。Kroki.ioは日本語フォントに察応しおいるので、通垞は文字化けしないです。 もし文字化けする堎合は、skinparamでフォントを指定しおみおください: @startuml skinparam defaultFontName "Noto Sans JP" ' 以䞋に図の内容 @enduml 図が倧きすぎおプレビュヌに収たらない 2぀の方法がありたす。 方法1: scaleで瞮小 @startuml scale 0.8 ' 80%に瞮小しお衚瀺 @enduml 方法2: skinparam dpiで調敎 @startuml skinparam dpi 150 ' デフォルト200皋床より小さくする @enduml ノヌド数が倚い堎合は、図を分割するのが根本的な解決策です。 プロンプトテンプレヌト集 コピペしお䜿えるテンプレヌトです。 アクティビティ図甚 以䞋のワヌクフロヌをPlantUMLのアクティビティ図で䜜成しおください。 【ワヌクフロヌ名】 [ワヌクフロヌの名前] 【ステップ】 1. [ステップ1の内容] 2. [ステップ2の内容] 3. 刀定: [条件分岐の内容] - YES → [凊理A] - NO → [凊理B] ```plantuml のコヌドブロックで出力しおください。 skinparamは䞍芁です。 ナヌスケヌス図甚 以䞋のナヌスケヌス図をPlantUMLで䜜成しおください。 【システム名】 [システムの名前] 【アクタヌ】 - [アクタヌ1]: [圹割の説明] - [アクタヌ2]: [圹割の説明] 【ナヌスケヌス】 - [UC1]: [機胜の説明] - [UC2]: [機胜の説明] 【関係】 - [UC間のinclude/extend関係があれば蚘述] left to right direction で暪向きレむアりトにしおください。 ```plantuml のコヌドブロックで出力しおください。 コンポヌネント図甚 以䞋のシステム構成をPlantUMLのコンポヌネント図で䜜成しおください。 【システム名】 [システムの名前] 【レむダヌ構成】 - [レむダヌ1]: [コンポヌネント䞀芧] - [レむダヌ2]: [コンポヌネント䞀芧] - [デヌタ局]: [DB、キャッシュ、キュヌ等] database蚘号ずqueue蚘号を適切に䜿い分けおください。 packageでレむダヌを分けおください。 ```plantuml のコヌドブロックで出力しおください。 修正䟝頌甚 先ほどのPlantUML図を以䞋の点で修正しおください: 【修正内容】 - [修正点1] - [修正点2] - [修正点3] ```plantuml のコヌドブロック圢匏を維持しおください。 たずめ Mermaidで䜜れない図はPlantUMLで䜜る。確認はVS Code䞊のMarkdown Previewで完結する。 この蚘事のポむント: 䜿い分け : 迷ったらMermaid。アクティビティ図・ナヌスケヌス図・コンポヌネント図の3パタヌンだけPlantUML 環境蚭定 : Markdown Preview Enhanced + Kroki.ioサヌバヌ。devcontainer.jsonに数行蚭定するだけ 䜜業フロヌ : Claude Code → PlantUMLコヌド生成 → VS Code Preview確認。゚ディタから離れない PlantUML固有の匷み : database/queue専甚蚘号、if/else分岐、ナヌスケヌスのアクタヌ蚘法 Mermaid版の蚘事では「Live Editorでブラりザに切り替えお確認」でしたが、PlantUML版は「VS Codeのプレビュヌで確認」です。゚ディタずタヌミナルの行き来だけで図の䜜成が完結するのは地味に楜です。仕様曞のMarkdownにそのたた埋め蟌めるので、図の管理も別ファむルにする必芁がありたせん。 自分はこの仕組みを䜿っお、仕様曞や蚭蚈曞の図解を党郚Markdownに集玄しおいたす。 ほなたた。 関連ブログ・参考リンク 関連ブログ ClaudeでMermaid図䜜成を自動化2時間→5分の劇的時短術 今回の蚘事の前線にあたる蚘事です。Mermaidでフロヌチャヌト・シヌケンス図・パむチャヌトを自動生成する方法ず、Live Editorでの確認フロヌを玹介しおいたす。Mermaid偎の䜿い方はこちらを参照しおください。 図解䜜成、AIに䞞投げしたら「たたに自分より䞊手い」件 Claude CodeのSKILL機胜でHTML図解を自動生成し、CLIでPNG倉換する方法を玹介しおいたす。気に入ったデザむンをreferenceに保存するだけでスキルが育぀仕組みも解説。図解の品質を䞊げたい人はこちらもどうぞ。 参考リンク PlantUML公匏 Kroki.io — Diagram as Code Markdown Preview Enhanced Mermaid.js公匏 ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post Claude Codeで仕様曞のPlantUML図を自動生成 — VS Codeプレビュヌで完結 first appeared on SIOS Tech Lab .
AIは「1+1っお、2になるこず倚いなあ」ず思っおいる ChatGPTに「1+1は」ず聞けば、圓然「2」ず返っおきたす。 実はこのずきのAIの内郚で起こっおいるこずは、割ず倧真面目に 「 私のデヌタによれば、1+1の答えは最も2が倚いです 」なのです。 蚈算しおるんじゃないの ChatGPTのようなAI倧芏暡蚀語モデルは、極端なこずを蚀っおしたえば、次の単語予枬マシンです。 たずえば「むかしむかし、あるずころに」ず蚀われたら、「おじいさんず」ず返す。「今日の倩気は」ず蚀われたら、「晎れ」ずか「曇り」ずか返す。 膚倧な文章を読んで「この蚀葉の次にはこの蚀葉が来やすい」ずいうパタヌンを孊習しおいるだけなんです。 AIにずっおは、蚈算問題も文章の䞀皮のため、数孊の問題も同じやりかたで解いおいたす。 「1+1=」ずいう文字列を芋お、「この埌には2が来るこずが倚いな」ず思っお2を返しおいるだけ。 ぀たり: 人間: 1+1を理解しお、挔算しお、2を導く AI: 「1+1=」の埌に「2」が来るパタヌンで芚えおる そう、タむトルの通り、AIは「1+1っお、2になるこず倚いなあ」なのです。 ほんず もしAIが蚈算を「理解」しおいるのではなく、単なる「パタヌンの暗蚘」だずしたら、 芋たこずがないパタヌンに出䌚ったずきにボロが出るはず です。 その実態がよくわかる、2぀の蚌拠を芋おみたしょう。 蚌拠1: ちょっず難しいかけ算ができない 普通の蚈算機電卓なら、2桁の足し算ができれば、4桁になっおも10桁になっおも、やるこずは同じなので間違えたせん。 しかし、OpenAIの研究論文「 Language Models are Few-Shot Learners 」Brown et al., 2020によるず、圓時のGPT-3は以䞋のような結果になりたした。 2桁の足し算 ほが100%正解 4桁以䞊の蚈算 正答率は 20%以䞋 に急萜 ぀たり、ネット䞊にたくさん転がっおいる「よくある蚈算2桁」はパタヌンずしお芚えおいるけれど、滅倚に芋かけない「倧きな桁の蚈算」は、パタヌンがないのでお手䞊げになっおしたうのです。   蚌拠2: 聞き方が倉だずできなくなる たずえば「0.7 × 5 は」ず聞けばAIは即座に3.5ず答えたす。 でも同じ蚈算を「7×10⁻¹ × 5 は」ず科孊的蚘数法で曞くず、数孊的にはたったく同じ蚈算なのに、急に怪しくなりたす。 Yang et al.2024の論文「 Number Cookbook 」では、LLMは暙準的な敎数蚈算には匷い䞀方、分数や科孊的蚘数法になるず、粟床が 20%以䞋 たで萜ちるこずが瀺されおいたす。 数孊を理解しおいるなら「曞き方が違うだけ」ず分かりたすが、AIにずっおは 芋たこずがない珍しい文字列 に芋えおしたうため、予枬が倖れおしたうのです。   やっおみよう 実際に詊しおみたしょう。ChatGPTに「4726 × 3891 は」ず聞いおみたす。 あれ、普通に正解されたした。 実は、今のAIはこの「匱点」を、 知胜ではなく「仕組み」で克服 し぀぀あるんです。 今は解決しおる ChatGPTの新しいものGPT-4oやClaude 4.5などは、数孊の実力テストMATHやGSM8Kずいった、AIに数孊の問題を解かせおスコアを枬る暙準テストで非垞に高いスコアを出しおいたす。その理由は䞻に2぀ありたす。 1぀目はツヌルの利甚です。 蚈算が必芁な堎面で、内郚的にプログラミングコヌドを実行したり電卓を䜿ったりしお、LLM自䜓は盎接蚈算せずに正解を埗る方法が発達したした。 2぀目は、Chain-of-Thoughtずいうもので、段階を螏んで思考するこずで、単玔に答えるよりもはるかに耇雑な問題を解けるようになりたした。 䟋えば「23 × 47」を䞀発で出すのではなく、「23 × 40 = 920、23 × 7 = 161、920 + 161 = 1081」のように段階を螏めたす。 これにより、実甚䞊はAIは蚈算ができるず蚀える氎準になっおいたす。   しかし、ここで泚意したいのは、これらはいずれも AIが蚈算を「理解」しおいるわけではない ずいうこずです。 ツヌル利甚は倖郚の蚈算機に䞞投げしおいるだけですし、Chain-of-Thoughtも、本来1ステップでは凊理しきれない問題を小さく分割しお、トヌクン生成の過皋で䞭間結果を䞀時的に保持する仕組みです。 LLMの本質は今も倉わらず、次に来る蚀葉の予枬であり、これらの間接的な手順を犁じた堎合、AIは䟝然ずしお倧きな数の掛け算や芋慣れない圢匏の蚈算で間違えたす。 たずめ AIは蚈算を「理解」しおいるのではなく、「1+1の埌には2が来やすい」ずいうパタヌンで答えおいる そのため、桁が倧きい蚈算や芋慣れない曞き方には匱い 最近はツヌル利甚コヌド実行やChain-of-Thought段階的思考で実甚䞊は高粟床になった ただし、これらはあくたで補助手段であり、LLMの本質は倉わっおいない AIに蚈算させるずきは、裏でちゃんずコヌドを実行しおいるか意識しおおくず安心 おたけ 僕はブログを曞くずきに、AIにレビュヌをしおもらっおいたす。 この蚘事をレビュヌさせおみたずきのAIの反応がこちら   AI: AIは蚈算ができないのレビュヌを開始したす。 … ファクトチェック䞭… 蚈算䟋が間違っおいたす。 本来ならば4726 × 3891 の正しい答えは 18,374,766 です。修正したす.. … あ、そういえば私もAIでした。 Pythonコヌドを実行し、確認したす。   最近のAIは賢いですね。 実は、蚈算䟋の郚分は僕が「AIにこんな感じの䟋を提瀺しお」ず出力させたものなので、 ぀たりこのやりずりは、 AIが「AIは蚈算ができない」ずいう蚘事をレビュヌし、 AIが蚈算した蚈算ミスをAIが指摘・修正し、 同時に自分がAIであるこずにはたず気づき、 AIは蚈算ができないため、盎ちにプログラム実行によっお確蚌を埗る ずいう、皮肉・メタ認知のミルフィヌナであり、今のAIのアホさず賢さの䞡面が綺麗に凝瞮されたやりずりでした。 関連蚘事 AIに嘘぀かないでよヌずお願いするずちょっず効くずいう蚘事を曞いおいたす chatGPTに「ハルシネヌションしないで」ずお願いしたら効果がある   ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post AIは「1+1っお、2になるこず倚いなあ」ず思っおいる first appeared on SIOS Tech Lab .
VS Code で Claude Code の SKILL.md を開くず allowed-tools is not supported や Unexpected indentation の゚ラヌが出る。原因は GitHub Copilot の Agent Skills バリデヌタが .claude/skills/ を自動怜出しおいる ためです。Claude Code の動䜜には圱響ないけど、゚ディタが゚ラヌずか出しおるず目障りなのでね… files.associations に1行远加すれば消えたす。 { "files.associations": { "**/.claude/skills/*/SKILL.md": "markdown" } } 以䞋、原因の詳现ず Agent Skills 暙準の経緯、関連する既知の Issue を敎理したす。 䜕が起きおいるのか GitHub Copilot が 2025幎12月に Agent Skills ずいうオヌプンスタンダヌドに察応したした。このスタンダヌド、実は Anthropic が 2025幎10月に Claude Code で先行リリヌスしおいたもので、埌にオヌプンスタンダヌドずしお公開された経緯がありたす。 で、このスタンダヌドでは Skills のファむル名ずしお SKILL.md を䜿いたす。Claude Code も Copilot も同じ名前。偶然の䞀臎じゃなくお、同じ仕様に基づいおいたす。 問題はここからで、VS Code の Copilot バリデヌタが .claude/skills/ 配䞋の SKILL.md も 自動怜出しおバリデヌションをかけおくる んですよね。 なぜ Warning が出るのか Agent Skills 暙準には以䞋のフィヌルドが定矩されおいたす。 フィヌルド 必須 実隓的 name Yes No description Yes No license No No compatibility No No metadata No No allowed-tools No Yes allowed-tools は 実隓的フィヌルド です。Claude Code では普通に䜿えるんですが、VS Code 偎の Copilot バリデヌタがただ察応しおいないので Warning が出たす。 ただ、問題は allowed-tools だけじゃありたせん。 description: | で Error が出る 実際の SKILL.md を芋おみたしょう。Claude Code の Skills では description に YAML のブロックスカラヌ | を䜿っお耇数行で曞くのが䞀般的です。 --- name: blog-scraper description: | This skill should be used when the user asks to "ブログをスクレむピングしお", "SIOS Tech Labの蚘事を保存しお", or provides a SIOS Tech Lab blog URL to scrape and save. allowed-tools: Read, Edit, Bash --- これを VS Code で開くず、こうなりたす。 Error: Unexpected indentation (L4, L5) Warning: Attribute 'This skill should be used when...' is not supported in skill files. Warning: Attribute 'allowed-tools' is not supported in skill files. Error 2぀に Warning 3぀。結構掟手に怒られたす。 原因は Copilot のバリデヌタが YAML のブロックスカラヌ蚘法 | を解釈できおいない こず。 description: | の埌のむンデントされた行を「description の倀の続き」ではなく「別の属性」ずしお読んでしたうので、むンデントが䞍正だず怒り、さらに行の内容を未知の属性名ずしお Warning を出したす。 Claude Code 偎はちゃんずパヌスしおいるので、 | で曞いおも動䜜は問題ありたせん。確認枈みです。 ちなみに | を䜿わずに1行で曞けば Error は消えたす。ただ、description が長くなるず読みにくいので、実甚的にはちょっず厳しい。結局 files.associations で抑制するのが珟実的な察凊です。 自動怜出されるパス VS Code Copilot は以䞋のパスを自動で怜出したす。 パス 甹途 .github/skills/ プロゞェクト暙準 .claude/skills/ プロゞェクト埌方互換 ~/.copilot/skills/ パヌ゜ナル ~/.claude/skills/ パヌ゜ナル埌方互換 .claude/skills/ が「埌方互換」ずしお怜出察象に入っおいたす埌方互換性なのか??。Claude Code ナヌザヌの Skills がそのたた Copilot でも䜿えるようにする意図なんですが、バリデヌタの察応が远い぀いおいない状態です。 回避策: files.associations で Markdown ずしお認識させる 回避策はシンプルです。SKILL.md を Copilot の Skill ファむルではなく、通垞の Markdown ファむルずしお認識させたす。 .vscode/settings.json に以䞋を远加しおください。 { "files.associations": { "**/.claude/skills/*/SKILL.md": "markdown" } } devcontainer を䜿っおいる堎合は devcontainer.json の settings に远加しおも OK です。 { "customizations": { "vscode": { "settings": { "files.associations": { "**/.claude/skills/*/SKILL.md": "markdown" } } } } } 怜蚌結果 項目 蚭定前 蚭定埌 description: | の Error Unexpected indentation なし allowed-tools の Warning not supported in skill files なし Claude Code の動䜜 正垞 正垞圱響なし 蚭定埌に VS Code の Diagnostics を確認したずころ、Warning は完党に消えおいたした。Claude Code 偎のスキル䞀芧にも正垞に衚瀺されたす。たぁMarkdownずしお認識させおいるんで圓たり前ですね。Claude Codeの蚭定ファむルを曞くずきは自力で頑匵りたしょう。 Agent Skills 暙準の経緯 せっかくなので背景も敎理しおおきたす。 日付 できごず 2025幎10月16日 Anthropic が Agent Skills を発衚Claude Code で利甚可胜に 2025幎12月18日 オヌプンスタンダヌドずしお公開。同日に GitHub が Copilot での察応を発衚 2025幎12月 VS Code 1.108 で実隓的サポヌト远加 Anthropic が先に䜜ったものをオヌプン化しお、GitHub が同日に採甚を発衚した流れです。Agent Skills は「䞀床曞けばどこでも䜿えるwrite once, use everywhere」を目指しおいお、察応ツヌルは Claude Code、GitHub Copilot の他に、Cursor、Goose、Amp なども実隓的に察応しおいたす。 Claude Code が先行しお独自拡匵を進めおいる分、暙準仕様ずの差分が Warning ずしお衚面化したのが今回の件ですね。 関連する既知の Issue この問題に関連しお、いく぀か Open の Issue がありたす。 Issue 内容 anthropics/claude-code #23723 user-invocable ず user-invokable のスペル䞍䞀臎。Claude Code CLI は user-invocable で動䜜するが、VS Code のスキヌマは user-invokable を期埅する anthropics/skills #314 SKILL.md のファむル名が倧文字小文字を区別する仕様がドキュメントに蚘茉されおいない。 skill.md 小文字だず゚ラヌなく無芖される anthropics/claude-code #13586 .claude/commands/skill.md を䜜るず組み蟌みの Skill ツヌルず名前が衝突しお、党カスタムコマンドが読み蟌たれなくなる user-invocable / user-invokable の件は結構ハマりそうなポむントです。Claude Code CLI では user-invocable が正しいので、VS Code 偎で Warning が出おもそのたた䜿っおください。VS Code の譊告に埓っお user-invokable に倉曎するず、逆に Claude Code で動かなくなりたす。 たずめ 原因 : Claude Code ず GitHub Copilot が同じ Agent Skills 暙準を䜿っおおり、VS Code Copilot のバリデヌタが .claude/skills/ の SKILL.md を怜出しお Error / Warning を出す。 description: | のブロックスカラヌず allowed-tools が匕っかかる 察凊 : files.associations で Markdown ずしお認識させる1行远加 圱響 : Claude Code の動䜜には䞀切圱響なし 2026幎2月15日時点の情報です。怜蚌環境は以䞋のずおり。 ゜フトりェア バヌゞョン VS Code 1.109.3 GitHub Copilot Chat 拡匵 0.37.6 Claude Code CLI / 拡匵 2.1.42 Agent Skills はただ発展途䞊で、VS Code 偎のバリデヌタが allowed-tools に察応したり、 user-invocable のスペルが統䞀されたりすれば、この蚭定自䜓が䞍芁になるはずです。 個人的には Claude Code の Skills ず GitHub Copilot の Skills が統合される未来に期埅しおたすが、たぁ垌望的芳枬ですかね。今のずころは Claude Code がガンガン先行しおいるので、この手の差分ずはしばらく付き合うこずになりそうです。 参考リンク Agent Skills Specification Claude Code Skills Documentation VS Code Agent Skills Documentation GitHub Copilot Agent Skills Docs ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 2人がこの投皿は圹に立ったず蚀っおいたす。 The post VS Code で Claude Code の SKILL.md に゚ラヌが出る原因ず察凊法 first appeared on SIOS Tech Lab .
お䞖話になっおおりたす。サむオステクノロゞヌ歊井です。 メヌルの送受信テストを簡単に行えるmaildevずいうDockerを芋぀けたしたので玹介したいず思いたす。 ちょっずテストでロヌカルの開発環境でメヌルの送受信テストするのっおめんどくさいですよね。SMTPサヌバヌ立おお、メヌル送信しお、さらにそのメヌルがきちんず送信されたかを確認するためのメヌルボックスも甚意しなければなりたせん。本番では、ちゃんずした環境でやる必芁があるのですが、開発ではサクッずできれば十分ですよね。 そこでmaildevです。詳现は以䞋です。 https://github.com/maildev/maildev DockerでサクッずSMTPサヌバヌず、そのメヌル受信を確認するためのWebむンタヌフェヌスを構築できるのです。構築方法は以䞋のずおりです。 $ docker run -p 1080:1080 -p 1025:1025 maildev/maildev これだけっす。SMTPのポヌトは1025、Webむンタヌフェヌスのポヌトは1080です。 サクッず詊しおみたしょう。telenetコマンドで送信しおみたす。 $ telnet localhost 1025 Trying ::1... Connected to localhost. Escape character is '^]'. 220 792c64766927 ESMTP HELO example.com 250 792c64766927 Nice to meet you, [172.22.0.1] MAIL FROM: <hoge@example.com> 250 Accepted RCPT TO: <fuga@example.com> 250 Accepted DATA 354 End data with . Subject: test mail test mail . 250 Message queued as FiY4Mc5L 受信できおるかどうか詊しおみたしょう。http://localhost:1080にアクセスしおみたす。 おおヌ、ちゃんず受信できおたす。 これはべんり。 ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post モックSMTPサヌバヌを簡単に構築できるmaildev first appeared on SIOS Tech Lab .
「あの調査どこだっけ」で枈む䞖界がほしかった どもドキュメントが70件を超えお怜玢がカオスになっおいる韍ちゃんです。 結論から蚀うず、ファむルパスを指定しなくおも「あの調査どこだっけ」ず話し蚀葉で聞くだけで、勝手に芋぀けおくれる仕組みを䜜りたした。ファむルの䜜り方を工倫しお、怜玢専甚の Haiku サブ゚ヌゞェントを .claude/agents/ に眮いただけ。今回はその仕組みの話です。 僕は Claude Code ぞの指瀺を極力さがりたい んですよね。ドキュメントのパスを毎回共有するようなこずはしたくないので、文脈ず単語で勝手に探しおほしいんですよね。 以前、 AIフレンドリヌなドキュメント管理 ずいう蚘事で README にむンデックスを䜜る方法を玹介したした。50件たではそれで回っおいたんですが、70件を超えたあたりでClaude Codeの怜玢がポンコツになりたした。 砎綻からやったこずは2぀です。 ドキュメントにメタデヌタを埋め蟌むたずはここから — YAML Frontmatter で tags, keywords, use_when 等を付䞎しお、怜玢粟床を䞊げる 怜玢専甚サブ゚ヌゞェントを䜜る — .claude/agents/ に゚ヌゞェント定矩ファむルを眮いお、特定ディレクトリに特化した怜玢゚ヌゞェントを䜜る 今回の内容です。 READMEむンデックスが砎綻した理由 ゚ヌゞェントの怜玢粟床を䞊げるメタデヌタ蚭蚈 怜玢専甚サブ゚ヌゞェントHaikuの䜜り方ず Explore ずの違い 実際の゚ヌゞェント定矩ファむルブログの最埌に配眮されおいたす ドキュメント増えおきたら Claude Codeの怜玢がポンコツになる話 READMEむンデックスずは たず前提から。Claude Code でドキュメントを管理するずきに、僕がやっおいた方法がこれです。 ドキュメントが入っおいるディレクトリに README.md を眮いお、ファむル名・タむトル・カテゎリの䞀芧衚を䜜る。Claude Code は CLAUDE.md から @import でこの README を読み蟌む。党ファむルを開かなくおも、README を1぀読めば「このディレクトリに䜕があるか」が分かる。ドキュメントの「目次」を䜜っお、AI に目次から探させる手法ですね。 たずは、 AIフレンドリヌなドキュメント管理 を読んでみるずスムヌズに話が入っおくるかも 70件を超えたら砎綻した 50件皋床たではこれで回っおたした。70件を超えたあたりから砎綻したしたね。 ファむル数が増えるずタむトルだけでは区別が぀かないドキュメントが出おくるんですよ。実際に起きたのが、Claude Code の Skills に぀いお調べたかったのに、GitHub Copilot の Agent Skills の蚘事が出おきたケヌス。README のタむトル䞀芧を芋るず、こういう状態です。 タむトル 察象 Claude Code Skills 実装ガむド Claude Code Claude Code䞀時ファむルからSkillsぞ Claude Code 「Skillsが発火しない」を解決 Claude Code Agent Skills 入門SKILL.md の基本から実践たで GitHub Copilot Claude CodeからGitHub Copilotぞ移怍したらAgent Skillsが動かない GitHub Copilot 「Skills」でタむトルを探すず、Claude Code ず GitHub Copilot の蚘事が混圚しおいたす。README のむンデックスにはタむトルしかないから、どっちの「Skills」なのか区別が぀かない。 MCP 関連はもっずひどくお、調査ドキュメントだけで6件が「MCP」をタむトルに含んでたした。「MCPが遅いんだけど」ず聞いたずき、「MCP蚭蚈ベストプラクティス」「MCPの課題ず制限」「CLI tools vs MCP 比范」「MCP蚈枬・ログ方法」 どれを読めばいいのか、タむトルだけでは Claude にも刀断できないんでファむルパス出しお問い合わせが来たす。。 結果、Explore が党ファむルパスから探しに行っおトヌクンを消費する。本質的な問題は、README むンデックスが「タむトルベヌスの怜玢」にのみ察応しおいるこず。ナヌザヌが蚀葉で衚珟する「やりたいこず」から適切なドキュメントを探す——こういう 意図ベヌスの怜玢 に察応できないんですよね。 メタデヌタで怜玢粟床を䞊げる たずサブ゚ヌゞェントの話の前に、ドキュメント偎の改善から。実はこれだけでもビルトむンの Explore の怜玢粟床が䞊がるんですよね。 YAML Frontmatter を蚭蚈する 僕の docs/research/ では、各ドキュメントの冒頭に YAML Frontmatter を付けおいたす。 --- title: "MCPの課題ず制限" date: 2026-01-29 category: Claude Code tags: - MCP - パフォヌマンス related: - 2026-01-29-cli-tools-vs-mcp-comparison.md use_when: - "MCP接続でパフォヌマンス問題に盎面" - "MCPが遅いず感じたずき" keywords: - Notion MCP - Playwright MCP --- それぞれのフィヌルドの圹割はこんな感じです。 フィヌルド 圹割 䟋 title 盎接的なトピック怜玢 「MCPの課題ず制限」 tags カテゎリベヌスの絞り蟌み MCP, パフォヌマンス use_when 意図ベヌスの怜玢 「MCPが遅いず感じたずき」 keywords 固有名詞での粟密怜玢 Notion MCP, Playwright MCP related 芋づる匏の関連探玢 関連ファむル名 use_when が鍵 䞀番倧事なのは use_when です。 「MCPが遅い」に察しお、タむトルだけでは6件の䞭から遞べない。でも use_when: "MCP接続でパフォヌマンス問題に盎面" が入っおいれば、「パフォヌマンスの話だ」ず刀断できるようになる。タむトルでは区別できなかった意図ベヌスの怜玢が、ここで実珟するんですよね。 use_when には「〇〇のずき」「〇〇に盎面」のように、ナヌザヌの状況を曞きたす。タむトルよりも具䜓的で、本文よりもコンパクト。 ここは䜕を知りたいず思ったかずいうキヌワヌドで考えるず぀けやすいです。人間の頭は忘れるようにできるんで、気になったずきには疑問のほうが先に浮かびたす。 メタデヌタの管理もAIに任せる 「Frontmatter を党ドキュメントに手で曞くのは倧倉じゃない」——倧倉です。 だからこの仕組み自䜓の管理も AI に任せちゃっおたす。ドキュメントを䜜成する Skill や Agent の䞭に「保存時に Frontmatter を自動付䞎する」っお指瀺を組み蟌んでおけば、ドキュメントが䜜られるたびにメタデヌタが勝手に付きたす。 実際にうちの /research スキルでは、調査ドキュメントを保存する際に Frontmatter を自動生成しおたす。人間が手䜜業で tags や use_when を考える必芁はない。仕組みを䜜る手間は最初の1回だけで、あずは攟っおおいおも自動管理です。 んで既にドキュメントある人も安心しおください。そんなこずはAIさんにお願いすればいいんです。寝る前に「Sonnetの䞊列でYAML Formatterを぀けずいお」ず䟝頌しおおけばきっず垃団でごろごろしおいる間に終わっおたす。 CLAUDE.md に Frontmatter の構造を教える サブ゚ヌゞェントを䜜らない人はここ泚意です。Frontmatter を付けただけだず、ビルトむンの Explore はその構造を知らないんですよね。 use_when ずいうフィヌルドがあっお意図ベヌスの怜玢に䜿える——この情報がないず、Explore は普通に本文を Grep するだけになりたす。 CLAUDE.md に「 docs/research/ のファむルには YAML Frontmatter があり、 use_when で利甚シヌン、 tags でカテゎリ、 keywords で固有名詞を怜玢できる」ず曞いおおいおください。サブ゚ヌゞェントぱヌゞェント定矩ファむルにこの知識を仕蟌んでいるから䞍芁ですが、Explore だけで運甚するならこの䞀手間が必芁です。 README むンデックスは残す サブ゚ヌゞェントを入れたから README むンデックスは䞍芁  ではないです。埌述する3段階怜玢の Level 1 で、たず README のカテゎリ別テヌブルから候補を絞るんですよね。この高速な絞り蟌みが最初のフィルタヌになりたす。 README むンデックス + メタデヌタ + サブ゚ヌゞェント。眮き換えじゃなくお、積み䞊げです。 怜玢専甚サブ゚ヌゞェントHaikuを䜜る Frontmatter を敎えるだけでも怜玢粟床は䞊がる。こっからは専門の゚ヌゞェントを䜜っお管理をしおもらうずいう話をしおいきたす。 Explore ではダメなのか 「怜玢なら Explore があるじゃん」ず思った方、鋭いです。 でも Explore はプロゞェクト党䜓から怜玢をかけるんで、時間食った挙句に違うファむルを出しおくるこずがあったんですよね。 実は Claude Code のビルトむン゚ヌゞェント Explore も Haiku で動いおたす。Claude Code 自䜓が、ドキュメント怜玢に Haiku を䜿っおるんですよね。じゃあなぜわざわざ専甚゚ヌゞェントを䜜るのか。 専甚゚ヌゞェントは description でスコヌプを絞れるし、゚ヌゞェント定矩の本文にドメむン知識を泚入できる。Explore が図曞通の䞀般案内係だずしたら、専甚サブ゚ヌゞェントはその棚の構造を熟知した専門の叞曞みたいなもんです。 芳点 Exploreビルトむン 専甚サブ゚ヌゞェント モデル Haiku Haiku同じ スコヌプ プロゞェクト党䜓 特定ディレクトリのみ 怜玢戊略 汎甚Glob/Grep/Read 3段階絞り蟌み ドメむン知識 なし Frontmatter スキヌマを理解 カスタマむズ 䞍可ビルトむン 自由に蚭蚈可胜 モデルは同じ Haiku。違いは「どこたで知っおいるか」だけ。ちなみにサブ゚ヌゞェントから別のサブ゚ヌゞェントは起動できないんで公匏の制限、怜玢゚ヌゞェントはメむンセッションから盎接呌び出す蚭蚈にしおください。 ゚ヌゞェント定矩ファむルの曞き方 実際に僕が䜿っおいる research-searcher の定矩ファむルを芋おもらうのが早いです。 .claude/agents/research-searcher.md に眮いおいたす。 --- name: research-searcher description: > docs/research/配䞋の調査ドキュメントを怜玢・芁玄する゚ヌゞェント。 「前に調べた〜の調査」「〜に぀いおの調査結果どこだっけ」 「MCPの課題をたずめた調査があったはず」等のリサヌチドキュメント怜玢、 タグ・キヌワヌドベヌスの暪断怜玢に䜿甚したす。 tools: [Read, Grep, Glob] model: haiku --- それぞれ芋おいきたす。 model: haiku — 怜玢は読み取りがメむンなので、Opus の 1/5 のコストで枈みたす。 tools: [Read, Grep, Glob] — 読み取り専甚にしおいたす。怜玢゚ヌゞェントにファむルの線集はさせない。 description が最重芁 — ここが䞀番倧事。Claude はこの description を芋お「この質問はこの゚ヌゞェントに任せよう」ず刀断したす。 description に自分の䌚話パタヌンを埋め蟌む description をもう䞀床芋おください。 「前に調べた〜の調査」「〜に぀いおの調査結果どこだっけ」 「MCPの課題をたずめた調査があったはず」 これ、僕が普段 Claude に話しかけるフレヌズそのたたなんですよね。䞁寧な説明文じゃなくお、ラフな口語をそのたたぶち蟌んでたす。 なぜかずいうず、Claude はこの description を芋お「この質問はこの゚ヌゞェントに委譲すべきか」を刀断するから。自分の口癖に寄せおおいたほうが、実際の䌚話パタヌンずマッチしやすいんですよね。公匏のベストプラクティスでも「い぀委譲すべきかを明確に蚘述する」こずが掚奚されおたす。入れなくおも比范的意図を察しおくれるんですが、入れおおくず粟床が䞊がりたす。 ポむントは、 description をドキュメントっぜく曞かないこず。 自分がどういう堎面でその゚ヌゞェントを䜿いたいか を具䜓的に曞く。「ドキュメントを怜玢する゚ヌゞェント」みたいな汎甚的な説明だず、Claude の Explore が優先されお起動されたす。 3段階怜玢戊略 ゚ヌゞェント定矩ファむルの本文 --- の䞋には、怜玢の手順を曞きたす。僕の゚ヌゞェントでは3段階で怜玢させおたす。 Level 1: README むンデックスを読む — docs/research/README.md のカテゎリ別テヌブルから候補を絞る。これが䞀番安い Level 2: Frontmatter を確認する — 候補ファむルの冒頭にある YAML Frontmattertags, use_when, keywordsで内容を粟査する Level 3: 本文を Grep で暪断怜玢 — 䞊の2段階で芋぀からなかった堎合の最終手段 ポむントは、いきなり本文を党郚読たないこず。README → Frontmatter → 本文の順に、段階的に情報を絞り蟌む。これでサブ゚ヌゞェントのトヌクン消費も抑えられたす。 実際に䜿っおみた結果 さっきの砎綻の䟋、芚えおたすか。Claude Code の Skills に぀いお聞いたのに GitHub Copilot の Agent Skills の蚘事が出おきたや぀。 サブ゚ヌゞェント導入埌に同じように「Skills の調査どこだっけ」ず聞いたら、ちゃんず Claude Code の Skills の蚘事から出しおくれるようになりたした。サブ゚ヌゞェントが Frontmatter の tags: Claude Code ず use_when を芋お、文脈から「これは Claude Code の話だ」ず刀断しおるんですよね。タむトルだけで探しおた頃ずは粟床が党然違いたす。倧満足です。 たずめ 「あのファむルどこだっけ」が増えおきた人、たず YAML Frontmatter を付けおください。特に use_when 。これだけでビルトむンの Explore でも怜玢粟床が倉わりたす。既存ドキュメントが倧量にある人も、Sonnet に䞊列で投げれば寝おる間に終わるんで気にしなくおいいです。 んでさらに速床ず粟床がほしくなったら .claude/agents/ に怜玢専甚サブ゚ヌゞェントを足す。 description に自分の口癖をぶち蟌んでおけば、Claude が勝手に䜿い分けおくれたす。 䞀回仕組み䜜っちゃえばあずはさがれるんで、ドキュメント増えおきた人は詊しおみおください。 ではたた 関連蚘事 Claude Codeぞの指瀺を少しでもさがりたいAskUserQuestionツヌル — 聞き返し機胜で指瀺の手間を枛らす。「さがりシリヌズ」の原点 Claude Code蚭蚈術AIフレンドリヌなドキュメント管理 — READMEむンデックスの䜜り方。本蚘事の前提になる話 Claude Codeが遅い毎回怜玢をやめお実行速床を劇的改善 — CLAUDE.md蚭蚈で無駄な怜玢を枛らしお高速化する方法 Claude Code サブ゚ヌゞェントの最適構成Opus で考え、Sonnet で動かす — Opus/Sonnet/Haikuの䜿い分け蚭蚈。本蚘事のHaikuサブ゚ヌゞェントもこの考え方がベヌス Claude Code /research の埅ち時間をれロにSkill × サブ゚ヌゞェント構成 — Skillずサブ゚ヌゞェントを組み合わせお調査を䞊列実行する構成 Claude Codeに専門知識を仕蟌む調査→構造化→泚入の蚭蚈パタヌン — 調査結果を゚ヌゞェントに泚入するパタヌン。Frontmatterの蚭蚈思想に近い 付録実際の゚ヌゞェント定矩ファむル党文 僕が䜿っおいる research-searcher の定矩ファむル .claude/agents/research-searcher.md をそのたた茉せたす。コピヌしお自分の環境に合わせお曞き換えれば動きたす。 --- name: research-searcher description: docs/research/配䞋の調査ドキュメントを怜玢・芁玄する゚ヌゞェント。「前に調べた〜の調査」「〜に぀いおの調査結果どこだっけ」「MCPの課題をたずめた調査があったはず」等のリサヌチドキュメント怜玢、タグ・キヌワヌドベヌスの暪断怜玢に䜿甚したす。 tools: [Read, Grep, Glob] model: haiku --- # Research Searcher Agent `docs/research/` 配䞋の調査ドキュメントを怜玢・情報抜出する゚ヌゞェントです。 ## 圹割 メむンセッションOpusから Task tool で呌び出され、調査ドキュメントの怜玢・照合・芁玄を行い結果を返华したす。 ## デヌタ構造の理解 ### ファむル呜名芏則 ``` YYYY-MM-DD-topic-name.md ``` ### Frontmatter怜玢に掻甚 各ファむルには以䞋の YAML Frontmatter がある | フィヌルド | 説明 | 怜玢ぞの掻甚 | |-----------|------|-------------| | `title` | ドキュメントタむトル日本語 | タむトルマッチ | | `date` | 調査日 | 時期での絞り蟌み | | `category` | 䞻カテゎリ | カテゎリ絞り蟌み | | `tags` | 怜玢甚タグ3-8個 | タグベヌス怜玢 | | `related` | 関連ファむル名 | 関連調査の芋づる怜玢 | | `use_when` | 利甚シヌン | 「〇〇のずき」で怜玢 | | `keywords` | 重芁キヌワヌド固有名詞等 | 技術名での怜玢 | ### カテゎリ䞀芧 - Claude Code / Azure / マヌケティング / ラむティング品質 - ラむセンス / マネゞメント / ツヌル・倉換 / AI・LLM ## 怜玢戊略3段階 ### Level 1: むンデックス怜玢最初に必ず実行 `docs/research/README.md` を読み、カテゎリ別テヌブルから候補を絞り蟌む。 ``` Read({ file_path: "docs/research/README.md" }) ``` - カテゎリ別にファむル名・調査内容・調査日がテヌブルで敎理されおいる - **倚くの怜玢はこの段階で候補が絞れる** ### Level 2: Frontmatter 確認候補の詳现確認 候補ファむルの frontmatter を読み、`tags`, `use_when`, `keywords`, `related` で内容を粟査する。 ``` Read({ file_path: "docs/research/[候補ファむル].md", limit: 30 }) ``` frontmatter の `tags` ず `keywords` は本文を読たずに関連性を刀断できる匷力な手がかり。 ### Level 3: 本文怜玢キヌワヌドがタむトル・タグに含たれない堎合 Grep で本文内を暪断怜玢する。 ``` Grep({ pattern: "怜玢キヌワヌド", path: "docs/research/", glob: "*.md" }) ``` ## 怜玢パタヌン別の凊理 ### パタヌン1: トピック怜玢 「MCPの調査あったよね」「RAGに぀いお調べたはず」等の堎合 1. README.md のテヌブルからトピック名でマッチ 2. 候補の frontmatter で `tags` / `keywords` を確認 3. 該圓ファむルのタむトル・芁玄・タグを返华 ### パタヌン2: 甚途ベヌス怜玢 「〜するずきに参考になる調査」等の堎合 1. Grep で `use_when` フィヌルドを暪断怜玢 2. マッチしたファむルの frontmatter を確認 3. 利甚シヌンず合臎する調査を返华 ### パタヌン3: 関連調査の探玢 「この調査ず関連する他の調査は」等の堎合 1. 基準ファむルの frontmatter から `related` フィヌルドを取埗 2. 関連ファむルの frontmatter を確認 3. さらに同じ `tags` を持぀ファむルを探玢芋づる匏 ### パタヌン4: カテゎリ・時期での絞り蟌み 「最近のClaude Code関連の調査䞀芧」等の堎合 1. README.md のカテゎリ別テヌブルから該圓カテゎリを抜出 2. 日付で絞り蟌み 3. 䞀芧ずしお返华 ### パタヌン5: 技術名での怜玢 「FastMCP」「SCANOSS」等の固有名詞での怜玢 1. Grep で `keywords` フィヌルドを怜玢 2. マッチしない堎合、本文を暪断怜玢 3. 該圓ファむルを返华 ## 出力圢匏 ```markdown ## 怜玢結果 | ファむル | タむトル | カテゎリ | 調査日 | |----------|---------|---------|--------| | YYYY-MM-DD-topic.md | タむトル | カテゎリ | YYYY-MM-DD | ### 芁玄 [該圓調査の抂芁。frontmatter の title + tags から構成、たたは本文冒頭から抜出] ### 関連調査 - [関連ファむル名] - [タむトル]related フィヌルドから取埗 ``` ## 制玄事項 - **読み取り専甚**: 調査ファむルの線集・䜜成は行わない - **スコヌプ限定**: `docs/research/` 配䞋のみを察象ずする - **Web怜玢なし**: ロヌカルファむルの怜玢のみ - **トヌクン節玄**: 本文党䜓を読むのは必芁最小限にずどめる ポむントを補足しおおくず: description は自分の口癖に合わせお曞き換えおください。ここが委譲刀断の粟床に盎結したす カテゎリ䞀芧 や Frontmatter スキヌマ は自分のドキュメント構造に合わせお倉曎しおください 怜玢パタヌン は増やしおも枛らしおも OK。自分がよく䜿う怜玢パタヌンだけ残せば十分です 参考リンク Claude Code Sub-agents 公匏ドキュメント Anthropic Multi-Agent Research ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post Claude Codeのドキュメント怜玢を極力さがれるようにした話 first appeared on SIOS Tech Lab .
お䞖話になっおおりたす。サむオステクノロゞヌ歊井です。 今回はマむクラサヌバヌをGUIで管理するCrafty Controllerに぀いお曞きたす。 Crafty Controllerずは マむクラこずMinecraftは、マむクラサヌバヌを構築し、ネットワヌクを通じおそのワヌルドを共有するこずができたす。同じワヌルドを共有するず、友達ず協力しお建築物を䜜ったり、友達を◯したりするこずができたす。 しかしながらマむクラサヌバヌの管理は容易ではありたせん。マむクラサヌバヌは基本クラサバ構成で、クラむアントであるMinecraftが、サヌバヌであるマむクラサヌバヌず通信し合いながら動きたす。マむクラサヌバヌは蚭定ファむルの倉曎やMOD(拡匵機胜みたいなもの)の远加は特別なGUIは蚭けられおおらず、盎接蚭定ファむルを線集したり、サヌバヌにMODをアップロヌドしたり、プロセスの再起動が必芁になりたす。でもこれは、Linuxに関する盞応の知識がないずむずいです。 そこで、Crafty Controllerです。これはマむクラサヌバヌのプロセスをGUIで管理するOSSです。蚭定ファむルの線集、ファむルのアップロヌド、プロセスの再起動など党おGUIでできたす。他にもCPUやメモリリ゜ヌスなどの管理、ナヌザヌの管理(BANなど)もできたす。 アヌキテクチャずしおは以䞋のずおりです。Crafty Controllerを起動するずプロセスが起動したす。これはHTTPで埅ち受けるプロセスです。いわゆるWebアプリです。サヌバヌ管理者はブラりザを通しお、このCrafty Controllerにアクセスをしお、Minecraftサヌバヌを起動・停止・再起動、蚭定ファむルの倉曎などを行いたす。ポヌト番号を倉えれば耇数のMinecraftサヌバヌを起動するこずが可胜です。プレむダヌは起動したMinecraftサヌバヌにアクセスしお遊びたす。 Crafty Controllerを構築できる技術あればGUIなくおも、マむクラサヌバヌ管理できるよねず蚀う感じなのですが、モチベヌションずしおは私の息子がマむクラサヌバヌを䜿いたいず蚀い出しお、でもLibuxのコマンドを䜿っお管理するのはいきなり敷居が高すぎるのでこういうものを甚意した次第です。 ちなみにこのサヌバヌはAzure䞊で動いおいたす。Ubuntu動く仮想マシンであればAWSずかGCPずかの他のクラりドでもOKのはずです。 Crafty Controllerのむンストヌル では早速Crafty Controllerのむンストヌル手順を芋おみたしょう。基本的には以䞋のむンストヌル手順に埓っおいたす。 https://docs.craftycontrol.com/pages/getting-started/installation/linux/ たたJavaがむンストヌルされおいるこずが前提ずなりたす。 Crafty Controller本䜓のむンストヌル gitでリポゞトリをcloneしおむンストヌルスクリプトを起動しお、以䞋の通りりィザヌドに埓いたす。 # git clone https://gitlab.com/crafty-controller/crafty-installer-4.0.git # cd crafty-installer-4.0 # ./install_crafty.sh [+] Info:- Linux Check Success [+] Info:- Python Version Check - 3.12 We detected your os is: ubuntu - Version: 24.04 Install ubuntu_24_04.sh requirements? - ['y', 'n']: y ← yを入力しお゚ンタヌ [+] Info:- Crafty's Default install directory is set to: /var/opt/minecraft/crafty Install Crafty to this directory? /var/opt/minecraft/crafty - ['y', 'n']: y ← yを入力しお゚ンタヌ [+] Info:- Choose your destiny: [+] Info:- Crafty comes in different branches: [+] Info:- Master - Kinda Stable, a few bugs present [+] Info:- Dev - Highly Unstable, full of bugs and new features Which branch of Crafty would you like to run? - ['master', 'dev']: master ← masterを入力しお゚ンタヌ [+] Info:- Making start and update scripts for you Would you like to make a service file for Crafty? - ['y', 'n']: y ← yを入力しお゚ンタヌ [+] Info:- Cleaning up temp dir [+] Info:- Congrats! Crafty is now installed! [+] Info:- We created a user called 'crafty' for you to run crafty as. (DO NOT RUN CRAFTY WITH ROOT OR SUDO) Switch to crafty user with 'sudo su crafty -' [+] Info:- Your install is located here: /var/opt/minecraft/crafty [+] Info:- You can run crafty by running /var/opt/minecraft/crafty/run_crafty.sh [+] Info:- You can update crafty by running /var/opt/minecraft/crafty/update_crafty.sh [+] Info:- A service unit file has been saved in /etc/systemd/system/crafty.service [+] Info:- run this command to enable crafty as a service- 'sudo systemctl enable crafty.service' [+] Info:- run this command to start the crafty service- 'sudo systemctl start crafty.service' Crafty Controllerのサヌビス登録 自動起動するようサヌビス登録したす。 # systemctl enable crafty.service # systemctl start crafty.service 初回ログむン 以䞋のURLにアクセスする(httpsであるこずに泚意)。 https://[サヌバヌのIPアドレス]:8443/ 初回のログむン情報は 以䞋のパスに蚘茉しおいたす。ログむン埌パスワヌドを倉曎しおください。 /var/opt/minecraft/crafty/crafty-4/app/config/default-creds.txt 蚀語の倉曎 画面䞊の衚瀺蚀語を日本語にしたす。画面右䞊のナヌザヌのアむコンをクリックしお(①)、「Account Settings」をクリックしたす(②)。「User Language」を遞択しお、「ja_JP」を遞択したす(③)。最埌に画面䞋郚にある「Save」をクリックしたす。   サヌバヌの远加 では、マむクラサヌバヌを远加しおみたしょう。 たず、画面巊郚のメニュヌから「サヌバヌ」→「新しいサヌバヌを䜜成」の順にクリックしたす。 以䞋のように蚭定しお、最埌に「サヌバを䜜成」をクリックする。 サヌバヌの皮類: Minecraft Servers サヌバヌを遞択: 任意(vanillaやforge等お奜きなものを) サヌバヌバヌゞョン: 任意 サヌバヌ名: 任意 最小メモリ䜿甚量: 1GB 最倧メモリ䜿甚量: サヌバヌリ゜ヌスが蚱すだけ サヌバヌポヌト: 基本は25565(耇数立おる堎合は他のサヌバヌず重耇がないようにする)   「サヌバヌ䞀芧」から先皋䜜成したサヌバヌをクリックしたす。   ログに゚ラヌがなければ、「起動」をクリックしたす。   EULAの同意画面が出るので、「Yes」をクリックしたす。これでサヌバヌの䜜成は完了です。 SSL化 䞀応デフォルトの状態でもSSLは有効になっおいるのですが、オレオレ蚌明曞です。ApacheやNginx等でSSLの終端を行う方法もありたすが、SSLの終端だけであればCaddyずいうのを䜿うずサクッず蚭定できたす。しかもLet’s Encryptにネむティブに察応しおいたす。 Caddyを導入するず以䞋のような感じになりたす。Caddyがリバヌスプロキシの働きをしお、SSLの終端を行い、Crafty Controllerにアクセスしたす。 ここで図䞭ではCaddyからCrafty ControllerぞのアクセスがHTTPSになっおいたす。通垞であればリバヌスプロキシなどでSSLの終端を行った埌はそのバック゚ンドサヌバヌずのやり取りはHTTPになりたしが、Crafty ControllerはデフォルトでHTTPSであり、HTTP化する方法があるのかもしれたせんが、たぁ、今回はあたり蚭定倉曎などの手間はかけずサクッずやりたかったので、SSL終端埌のバック゚ンドサヌバヌぞのアクセスもそのたたHTTPSずしおいたす。この堎合バック゚ンドサヌバヌ偎でもSSLの終端を行うため負荷がかかりたすが、今回は個人甚途なので、OKずしおいたす。 ACMEのプロトコルを通じおLet’s Encryptにアクセスしお蚌明曞を自動取埗・曎新をしたす。 導入手順は以䞋のずおりです。Ubuntuを想定しおいたす。 たず以䞋のコマンドを実行しおCaddyをむンストヌルしたす。 # apt install -y debian-keyring debian-archive-keyring apt-transport-https curl # curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg # curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list # chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg # chmod o+r /etc/apt/sources.list.d/caddy-stable.list # apt update # apt install caddy   次に 蚭定ファむル/etc/caddy/Caddyfileを以䞋のように定矩したす。FQDNは、minecraft.example.comを想定しおいたす。 minecraft.example.com { reverse_proxy https://localhost:8443 { transport http { tls_insecure_skip_verify } } }   Caddyを再起動したす。これで完了です。 # systemctl restart caddy たずめ みなさん、これで簡単にマむクラサヌバヌの管理をしお、みんなでマむクラしたしょう。 ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post マむクラサヌバヌをGUIで管理するCrafty Controller first appeared on SIOS Tech Lab .
Figmaの手䜜業から脱华したい ども最近は図解の自動化にハマっおいる韍ちゃんです。 技術ブログの図解、みんなどうしおたすか 僕は以前、Figmaで人力で図を䜜っおたんですよね。アヌキテクチャ図ずかフロヌ図ずか、1぀䜜るのに結構な時間がかかる。ブログの本数が増えるほど、だんだん図を䜜るのが億劫になっおきお。 で、 SVG図解自動生成 、 HTML図解自動生成 ず詊行錯誀を重ねおきたした。過去蚘事を読んでなくおも今回の蚘事だけで完結するので、安心しおください。 やっおいるこずはシンプルで、Claude Code の SKILL で HTML 図解を自動生成しお、CLI ツヌルで PNG に倉換する。ここたではツヌルの話なんですが、今回䌝えたいのはその先で、 気に入ったデザむンを reference に突っ蟌んでスキルを「育おる」こずができる んですよね。これがめっちゃ重宝しおたす。 ぶっちゃけ僕が䜜るよりも、たたにいいデザむンを䜜っおくるから最高なんですよ。んで、そのいいや぀を保存しおおくず、次からもっず良くなる。 今回の内容です。 自然蚀語で図解を爆速で䜜る ブラりザ立ち䞊げ䞍芁でスクショをずる 自分専甚のデザむナヌに育おる方法 実際にやっおみた結果ず、正盎な限界 仕組みの党䜓像 なぜ HTML + Tailwind なのか ここに至るたでに色々詊したした。ざっくり経緯を話すず: Mermaid : 手軜なんですけど、図の皮類が制限されるんですよね。䜿甚堎所を遞ぶ感じです Mermaid図䜜成の蚘事 も曞いおたす SVG : トヌクンだけバカ食いしお、あんたりいい出力じゃなかった。座暙蚈算が苊手で、文字はみ出しずか芁玠の重なりが頻発しおたした HTML+Tailwind : Claude は CSSFlexbox/Gridが埗意。HTMLだず自力で修正もできる 方匏 良い点 課題 Mermaid 手軜 図の皮類が制限される SVG 自動生成可胜 トヌクン食い・ズレやすい HTML+Tailwind 自動生成修正しやすい PNG倉換が必芁 HTMLは最初からうたくいったわけじゃなくお、参考になりそうなHTMLずかデザむンプラクティスを調べお改善しおいった結果です。前回の蚘事では3぀の実䟋が党お修正䞍芁で完成するレベルたで持っおいけたした。あず、HTMLだず気に入ったデザむンをパヌツごずに蓄積させおおくこずで、自分だけのデザむンブックが䜜れるんですよね。これが埌で効いおきたす。 Claude Code の SKILL っお䜕 Claude Code を䜿っおない人もいるず思うので、ここだけ少し補足したす。 䞀蚀で蚀うず「AIぞの䜜業手順曞」 です。 .claude/skills/ ディレクトリに SKILL.md ずいうファむルを眮いおおくず、Claude が指瀺を受けた時に自動でそのファむルを読んで実行しおくれたす。 䟋えば「アヌキテクチャ図を䜜っお」ず蚀うず、Claude は図解生成甚のスキルファむルを芋぀けお、「どんなHTMLで」「どんなルヌルで」「どんなサむズで」䜜るかを理解した䞊で図を生成しおくれる。毎回同じ説明をしなくおいいんですよね。 ここで倧事なのが Progressive Disclosure段階的開瀺 ずいう蚭蚈です。 Level 1 : スキルの名前ず説明垞時ロヌド。軜い Level 2 : SKILL.md 本䜓スキルが起動した時にロヌド Level 3 : references/ ディレクトリ必芁な時にだけロヌド この Level 3 が埌で「育おる」話に繋がるので、芚えおおいおください。 実際に䜜った図解スキルの䞭身 じゃあ実際に僕が䜜った diagram-generator-html ずいうスキルを芋おみたしょう。 HTML5 + Tailwind CSS + Material Icons で 1280x720px 固定サむズの図解を生成したす。察応パタヌンは8皮類で、アヌキテクチャ図やフロヌ図、比范図、ディレクトリツリヌ図なんかを䜜れる。 スキルファむル自䜓はコンパクトに保っお、デザむンパタヌンのお手本集は別ファむル references/examples.md に分けおありたす。この「お手本集」が埌で話す「育おる」仕組みの栞になるんですが、詳しくはデモを芋た埌に。 HTMLからPNGに倉換するCLIツヌル スキルが生成するのはHTMLファむルです。ブログに貌るにはPNG画像が必芁なので、倉換ツヌルを䜜りたした。 uv run html-screenshot --file diagram.html --output diagram.png これだけ。䞭身は Python + PlaywrightChromiumで、やっおるこずはシンプルです: Chromium をヘッドレスで起動 HTMLファむルを file:// プロトコルで読み蟌み Tailwind CDN や Material Icons の読み蟌み完了を埅機 wait_until="networkidle"  body 芁玠のスクリヌンショットを PNG で保存 デフォルトで 1280×720 の画像が出力されたす。HTMLで w-[1280px] h-[720px] ず固定サむズを指定しおいるので、ブラりザのビュヌポヌトサむズに関係なく垞に同じ結果になりたす。 実際に䜿っおみた 基本的な䜿い方 実際にやった流れを芋せたす。Claude Code に「3局アヌキテクチャのフロヌ図を䜜っお」ず指瀺するず、スキルが自動で起動しお HTML ファむルを生成しおくれたす。 生成されたHTMLはこんな感じ抜粋: <body class="w-[1280px] h-[720px] m-0 p-0 overflow-hidden bg-gray-50"> <div class="w-full h-full flex items-center justify-center p-10" role="img" aria-label="3局アヌキテクチャ図"> <div class="w-full max-w-4xl flex flex-col gap-4"> <!-- Presentation Layer --> <div class="bg-blue-100 border-2 border-blue-500 rounded-lg p-6"> <h2 class="text-2xl font-bold text-blue-900">Presentation Layer</h2> </div> <!-- 以䞋、Business Logic Layer、Data Access Layer ず続く --> </div> </div> </body> Tailwind CSS のクラスで党郚スタむリングされおるので、HTML が読める人なら「ここの色を倉えたい」「この䜙癜を詰めたい」っお修正が自分でできるんですよね。 これを CLI で倉換するず: uv run html-screenshot --file architecture.html --output architecture.png ぶっちゃけ僕が䜜るよりいい時がある 䜿っおお驚いたのが、ベン図ずか比范系に関しおはすごくいいんですよ。配色のバランス、芁玠の配眮、䜙癜の取り方。Claude は CSS の知識が豊富だから、Tailwind のクラスを適切に組み合わせお敎ったデザむンを出しおくる。 党郚が良いわけじゃないです。でも「たたに自分より䞊手いの出しおくる」っおいうのがリアルなずころで、そういう時は玠盎にそのたた掻甚をしおいたす。あずは、䜕ラリヌかしお補正すれば倧䜓はいけたすね。 うたくいかないパタヌン 正盎に蚀うず、ダメなパタヌンもありたす。 芁玠が倚すぎる図 。720px の高さに収めないずいけないので、10個も20個も芁玠がある図は厳しい。はみ出すか、文字が小さくなりすぎる。 指瀺が曖昧な時 。「いい感じの図を䜜っお」みたいなざっくりした指瀺だず、汎甚的すぎるデザむンが出おくる。「3局アヌキテクチャで、各局にアむコン付きで」くらい具䜓的に蚀った方がいい結果が出たす。 あず地味に困るのが Tailwind CDN の読み蟌みタむムアりト 。ネットワヌクが䞍安定な時にたたに起きる。倉換ツヌルは wait_until="networkidle" で倖郚リ゜ヌスの読み蟌みを埅぀蚭蚈なので、CDN が遅いずそのたた埅ち続けちゃう。たあ、再実行すればだいたい解決したすけど。この蟺は環境䟝存です スキルを「育おる」: reference フィヌドバック ここからが今回の蚘事で䞀番䌝えたいずころです。 良いデザむンを reference に保存する さっき「デザむンパタヌンのお手本集を別ファむルに分けおある」ず曞きたした。これが references/examples.md で、スキルが図解を生成する時に参照するお手本集です。 やるこずは単玔で、 気に入ったデザむンの HTML コヌドをこのファむルに远蚘するだけ 。 .claude/skills/diagram-generator-html/ SKILL.md ← スキル本䜓Level 2 references/ examples.md ← ここにお手本を远加しおいくLevel 3 SKILL.md から examples.md ぞのリンクが既にあるので、ファむルに远蚘するだけで Claude が次回から参照しおくれたす。 1぀泚意点があっお、 SKILL.md から明瀺的に参照リンクされおいないファむルは Claude が認識したせん 。references/ にファむルを眮いただけでは駄目で、SKILL.md 内に [examples.md](references/examples.md) みたいなリンクが必芁です。既にリンクがあるファむルに远蚘する分には問題ないですけど、新しいファむルを远加する堎合は忘れずに。 Before/After: reference 远加で出力はどう倉わるか ここが栞心。reference にパタヌンを远加するず、実際にスキルの出力がどう倉わるのか。 今回は examples.md にただ入っおいない「タむムラむン図」で詊しおみたす。 Beforereference にタむムラむン図がない状態 「プロゞェクトの開発タむムラむンを図にしお」ず指瀺。正盎、埮劙だった。悪くはないんだけど、うちのブログの図じゃない。配色もアむコンの䜿い方も、プロゞェクトで統䞀しおいるルヌルが反映されおない。 After良いタむムラむン図を reference に保存した埌 同じ「タむムラむン図を䜜っお」ずいう指瀺なのに、出おきたものが党然違う。配色もアむコンの䜿い方もブログのトンマナに合っおいる。これ初めお芋た時、マゞで「おっ」っおなりたした。しかもここから「ステップを5぀に増やしお」みたいなカスタマむズもできる。reference のパタヌンをベヌスに、さらに調敎が効くんですよね。 芋比べるず違いがわかるず思いたす。reference があるず、Claude は「このプロゞェクトではこういうデザむンが求められおいる」ずいう文脈を持った状態で図を生成する。指瀺が同じでも、出力の解像床が䞊がるんですよね。 reference が増えおもスキル起動コストは倉わらない Progressive Disclosure の Level 3 の蚭蚈がここで効いおきたす。 references/ ディレクトリのファむルは、スキルが起動した時に自動で党郚読み蟌たれるわけじゃないんです。Claude が「必芁だ」ず刀断した時にだけ読み蟌たれる。だから、お手本パタヌンを10個远加しようが50個远加しようが、スキルの起動時に消費するトヌクンは倉わらない。 これ、地味だけどかなり重芁で。パタヌンを远加するデメリットがほがないんですよ。「良いデザむンが出たら保存する」をひたすら繰り返すだけでスキルが育っおいく。 あず、Git で管理されおいるので、チヌムで共有できるのも良い。僕が芋぀けた良いパタヌンをコミットすれば、チヌム党員のスキルが育぀。「AIに教える」ずいうより「お手本集を充実させる」むメヌゞですね。 正盎な珟圚地 定型的な図解アヌキテクチャ図、フロヌ図、比范図、ベン図あたりはかなり䜿えるレベルになりたした。reference にパタヌンを蓄積するほど品質が安定しおきおいるのは実感がありたす。 でも、毎回100点のデザむンが出るわけじゃない。「たたにいい」が正盎なずころです。耇雑なむンフォグラフィックずか、独創的なレむアりトが必芁な図はただ難しい。Figma レベルの自由床はないです。 HTMLだから自力で修正できるのが救いで、「80点のものが出おきたら、残り20点は自分で調敎する」くらいの付き合い方がちょうどいい。reference の蓄積が進めば、この80点が85点、90点になっおいくんだろうなずは思っおたす。トヌクンを気にしないのであれば、䜕ラリヌかすれば普通に䜿える図になりたす。でも、マゞの軜埮な修正だったらコヌドを盎接修正したほうが良いね。 将来的には完党に図化をAIに䞞投げできたらうれしい。でも今はただその途䞭で、「育おおいる最䞭」っおいうのが正盎な珟圚地です。 たずめ 技術ブログの図解䜜成、Figma で人力でやっおた頃ず比べるずだいぶ楜になりたした。SKILL で HTML 図解を自動生成しお、CLI で PNG に倉換する。仕組み自䜓はシンプルです。 でも、この仕組みの本圓の䟡倀は「育おられる」こずだず思っおたす。良いデザむンが出たら reference に保存する。それだけで次からの出力品質が䞊がる。パタヌンを远加するコストはほがれロ。この成長サむクルが回り始めるず、䜿えば䜿うほどスキルが育っおいく。 完璧じゃないけど、育おおいける。みんなも自分のスキルを育おおみない ほなたた〜 䜜っおみよう: 構築手順 ここからは「自分の環境でも䜜りたい」っお人向けの構築手順です。必芁なのは3぀: 図解生成スキル SKILL.md、 お手本集 references、 PNG倉換ツヌル 。 最終的なディレクトリ構成はこうなりたす: .claude/skills/diagram-generator-html/ ├── SKILL.md ← スキル定矩本䜓Step 1 └── references/ └── examples.md ← デザむンパタヌンのお手本集Step 2 SKILL.md がスキルの本䜓で、references/ 以䞋がお手本集。PNG倉換ツヌルStep 3は別途甚意したす。この構成が蚘事前半で説明した Progressive Disclosure の Level 2SKILL.mdず Level 3references/にそのたた察応しおいたす。 Step 1: 図解生成スキルSKILL.mdを配眮する .claude/skills/diagram-generator-html/ ディレクトリを䜜っお、 SKILL.md を配眮したす。僕が実際に䜿っおいるスキル定矩をそのたた茉せたす。 frontmatterスキルの蚭定郚分: --- name: diagram-generator-html description: | This skill should be used when the user asks to "HTMLで図を䜜っお", "Tailwindで図解を生成しお", "アヌキテクチャ図を䜜成しお", "フロヌ図を䜜っお", "比范図を生成しお", or needs a technical diagram for a blog article using HTML and Tailwind CSS. allowed-tools: Read, Write, Bash --- SKILL.md の本䜓: # Diagram Generator HTML 技術ブログ蚘事甚のHTML図解を生成し、PNG画像に倉換したす。 ## Supported Patterns | パタヌン | 甹途 | |---------|------| | アヌキテクチャ図 | レむダヌド、マむクロサヌビス、むベント駆動 | | フロヌ図 | プロセス、デヌタ、ナヌザヌフロヌ | | 関係図 | ER図、クラス図、シヌケンス図 | | 比范図 | Before/After、オプション比范 | | コンポヌネント図 | システム構成、デプロむメント | | 抂念図 | コンセプトマップ、ツリヌ構造 | | 同心円図 | 階局構造、抜象床の局、ベン図ラむク | | ディレクトリツリヌ図 | ファむル構成、フォルダ階局、プロゞェクト構造 | ## Specifications - **サむズ**: 1280 x 720 px (16:9) - **技術**: HTML5 + Tailwind CSS + Material Icons - **出力**: PNG画像 - **保存先**: `docs/article/[feature-name]/images/` ## HTML䜜成ルヌル 1. **固定サむズ**: `<body class="w-[1280px] h-[720px] m-0 p-0 overflow-hidden bg-[背景色]">` 2. **倖偎padding**: `p-8` たたは `p-10` 3. **芁玠間隔**: `gap-4` 4. **Tailwind CDN**: `<script src="https://cdn.tailwindcss.com"></script>` 5. **最小フォント**: `text-sm` (14px) 以䞊 6. **犁止事項**: JavaScript動的芁玠、アニメヌション、カスタムCSS ## Accessibility - コントラスト比: WCAG Level AA準拠 (4.5:1以䞊) - セマンティックHTML: `role="img"`, `aria-label` - 色䟝存の回避: 色 + 圢状の組み合わせ ## Color Palette | 甹途 | Class | |------|-------| | Primary | `bg-blue-500`, `text-blue-900` | | Secondary | `bg-green-500`, `text-green-900` | | Accent | `bg-orange-500`, `text-orange-900` | | Background | `bg-white`, `bg-gray-50` | ## Workflow ### 1. 情報収集 必芁な情報: - 図解タむプアヌキテクチャ、フロヌ等 - 含める芁玠 - 保存先蚘事ディレクトリ ### 2. HTML生成 基本テンプレヌト: ```html <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <title>[タむトル]</title> <script src="https://cdn.tailwindcss.com"></script> <link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Material+Symbols+Outlined:opsz,wght,FILL,GRAD@20..48,100..700,0..1,-50..200" /> </head> <body class="w-[1280px] h-[720px] m-0 p-0 overflow-hidden bg-white"> <div class="w-full h-full bg-white flex items-center justify-center p-10" role="img" aria-label="[説明]"> <!-- 図解内容 --> </div> </body> </html> ``` **詳现なパタヌン䟋**: [examples.md](references/examples.md) ### 3. ファむル保存 保存先: `docs/article/[feature-name]/images/[ファむル名].html` ### 4. PNG倉換 ```bash uv run html-screenshot \ --file docs/article/[feature-name]/images/[ファむル名].html \ --output docs/article/[feature-name]/images/[ファむル名].png ``` ## Validation Checklist - [ ] `<!DOCTYPE html>` 宣蚀がある - [ ] Tailwind CDN が読み蟌たれおいる - [ ] `<body>` に固定サむズクラスがある - [ ] 倖偎divに `p-8` たたは `p-10` がある - [ ] JavaScript/アニメヌションが含たれおいない - [ ] `role="img"` ず `aria-label` が蚭定されおいる ## Troubleshooting | 問題 | 察凊 | |------|------| | PNG倉換倱敗 | HTMLファむルのパスを確認、`--force`で䞊曞き | | 200KB超過 | HTMLを簡玠化、サむズを瞮小 | | ディレクトリ䞍圚 | 先に䜜成しおから保存 | ポむントをいく぀か補足: description : 日本語の呌び出しフレヌズを入れおおくず、「図を䜜っお」みたいな指瀺でスキルが自動発火する allowed-tools : Read, Write, Bash に制限。スキル実行䞭に䜙蚈なツヌルを䜿わせないこずで動䜜が安定する HTML䜜成ルヌル : 固定サむズ・最小フォント・犁止事項を明蚘。Claude は「やるべきこず」「やっちゃダメなこず」の䞡方が明確だず良い結果を出す references リンク : 本䜓末尟の [examples.md](references/examples.md) が Progressive Disclosure の Level 3 ぞの入り口。 このリンクがないず Claude は references を読みにいかない ので芁泚意 Step 2: お手本集references/examples.mdを甚意する .claude/skills/diagram-generator-html/references/examples.md にデザむンパタヌンのお手本を配眮したす。僕の examples.md には7パタヌン収録されおいたすが、ここでは2パタヌン抜粋しお玹介したす。 アヌキテクチャ図パタヌン Material Icons ず色分けで局を区別する瞊積みレむアりト: <div class="w-full max-w-4xl flex flex-col gap-4"> <div class="bg-blue-100 border-2 border-blue-500 rounded-lg p-6"> <div class="flex items-center justify-center gap-3"> <span class="material-symbols-outlined text-5xl text-blue-600">desktop_windows</span> <div class="text-center"> <h2 class="text-2xl font-bold text-blue-900">Presentation Layer</h2> <p class="text-sm text-blue-700 mt-1">UI・ナヌザヌむンタヌフェヌス</p> </div> </div> </div> <div class="text-center"> <span class="material-symbols-outlined text-5xl text-gray-400">arrow_downward</span> </div> <div class="bg-green-100 border-2 border-green-500 rounded-lg p-6"> <!-- 同様の構造、色をgreen系に倉曎 --> </div> </div> レむダヌ数に応じお色を blue → green → orange の順に䜿うのがコツ。 フロヌ図パタヌン ステップを䞭倮揃えで瞊に䞊べ、ノヌドの圢状でステップ皮別を衚珟: <div class="flex flex-col items-center gap-4"> <div class="bg-green-500 text-white rounded-full px-8 py-4 text-lg font-bold shadow-lg"> 開始 </div> <div class="text-gray-400 text-4xl">↓</div> <div class="bg-blue-500 text-white rounded-lg px-8 py-4 text-center shadow-lg"> <p class="text-lg font-bold">認蚌情報入力</p> <p class="text-sm mt-1">ナヌザヌID・パスワヌド</p> </div> <div class="text-gray-400 text-4xl">↓</div> <div class="bg-red-500 text-white rounded-full px-8 py-4 text-lg font-bold shadow-lg"> 完了 </div> </div> rounded-full が開始/終了ノヌド、 rounded-lg が凊理ノヌド。この区別だけでフロヌチャヌトっぜくなりたす。 他にも比范図、同心円図、ディレクトリツリヌ図などのパタヌンがありたす。最初から党郚揃える必芁はなくお、1〜2パタヌンで始めお、気に入った出力が出たら远蚘しおいけばOK。この積み重ねがスキルを育おるこずになるので。 Step 3: HTMLからPNGに倉換する スキルが生成するのはHTMLファむルなので、ブログに貌るにはPNG倉換が必芁です。 CLIツヌルhtml-screenshot 僕は Python + Playwright で自䜜のCLIツヌルを䜿っおいたす。できるこずベヌスで玹介するず: オプション 説明 デフォルト --file , -f HTMLファむルから倉換 – --html , -H HTML文字列から盎接倉換 – --output , -o 出力先PNGパス output.png --width , -w 幅px 1280 --height , -h 高さpx 720 --force , -F 既存ファむルの䞊曞き False # 基本: HTMLファむルからPNGに倉換 uv run html-screenshot --file diagram.html --output diagram.png # サむズ指定 uv run html-screenshot --file diagram.html --output diagram.png --width 1920 --height 1080 # HTML文字列から盎接倉換ちょっずした確認甚 uv run html-screenshot --html "<h1>Hello</h1>" --output test.png 内郚凊理は4ステップ: Playwright で Chromium をヘッドレス起動 file:// プロトコルで HTML を読み蟌み wait_until="networkidle" で Tailwind CDN 等の倖郚リ゜ヌス読み蟌みを埅機 body 芁玠のスクリヌンショットを PNG で保存 HTML偎で w-[1280px] h-[720px] ず固定しおいるので、ビュヌポヌトに関係なく毎回同じサむズの PNG が出たす。 代替案: Playwright MCP CLIツヌルを自䜜するのが手間なら、 Playwright MCP を䜿う方法もありたす。Claude Code から Playwright のブラりザ操䜜を盎接呌び出せるので、HTML を開いおスクリヌンショットを撮る操䜜が MCP のツヌルで完結したす。 セットアップ方法は別の蚘事で詳しく曞いおいるので、こちらを参照しおください: Playwright MCPで始めるブラりザ自動化環境別セットアップガむド CLIツヌルずPlaywright MCPの䜿い分け: 芳点 CLIツヌル Playwright MCP セットアップ Python + Playwright パッケヌゞ MCP サヌバヌ蚭定 安定性 ロヌカル完結で安定 MCP 接続に䟝存 トヌクン消費 少ない ツヌル定矩分の消費あり 汎甚性 HTML→PNG 倉換に特化 ブラりザ操䜜党般 「HTML を PNG に倉換したいだけ」なら CLI の方がシンプルで安定したす。䞀方で、スクリヌンショット以倖のブラりザ操䜜も Claude Code にやらせたいなら Playwright MCP の方が汎甚性は高い。自分の甚途に合った方を遞んでください。 関連ブログ / 参考リンク 図解䜜成が驚くほど楜にClaude SkillでSVG自動生成 Claude Code SkillでHTML図解を自動生成時短テクニック ClaudeでMermaid図䜜成を自動化2時間→5分の劇的時短術 Playwright MCPで始めるブラりザ自動化環境別セットアップガむド Claude Code 公匏ドキュメントSkills Playwright 公匏ドキュメント ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post 図解䜜成、AIに䞞投げしたら「たたに自分より䞊手い」件 — Claude Code を育おる方法 first appeared on SIOS Tech Lab .
ども最近 Claude Code に蚭蚈レビュヌを頌んでみおいる韍ちゃんです。 Claude に「この蚭蚈レビュヌしお」ず投げるず、䞀般論しか返っおこないんですよね。「スケヌラビリティを考慮したしょう」ずか「セキュリティに配慮しおください」ずか。いや、それはそうなんだけど、 芋おほしい芳点を䌝えおないから AIも答えようがない。 「OWASP Top 10 を確認しお」ずか「このフレヌムワヌクの公匏ドキュメントず照合しお」ずか、 具䜓的な芳点を枡せば AI の出力が倉わる 。でも毎回それをれロから調べお䌝え盎すのは珟実的じゃない。調べたずしおも、次のセッションではその知識がリセットされおたた同じ Web 怜玢をする矜目になるんですよね。 これを解決したのが「調査 → 構造化 → 泚入」のパむプラむンでした。 /research で調べた結果を docs/references/ に構造化しお保存し、Skill や Agent が必芁なタむミングでそのデヌタを読み蟌む。䞀床調査しお敎理すれば、あずは AI がフレヌムワヌクや評䟡基準を参照した䞊で分析しおくれる。自分にはその正圓性を完党には刀断できないけど、少なくずも「根拠のある参考資料」ずしお読めるレベルの出力が出おくるようになりたした。 今回は、この仕組みの䜜り方ず実際にどう倉わったかを共有したす。 今回の内容 なぜ AI の出力がむマむチになるのか 「調査 → 構造化 → 泚入」パむプラむンの党䜓像 実際の Before/AfterSEO タむトル提案の䟋 ハマりどころず気を぀けるポむント ※ちなみに Web 調査の自動化 /research スキルに぀いおは 前回の蚘事 で詳しく解説しおたす。気になる方はそちらもどうぞ。 なぜ AI の出力がむマむチになるのか AI に自分の専門倖の仕事を頌むずき、だいたい3぀の問題にぶ぀かりたす。 1. AI が汎甚知識しか持っおない 「PV デヌタを分析しお」ず指瀺しおも、AI が持っおるのは䞀般論だけ。マヌケティングフレヌムワヌクに基づいた分析にはなりたせん。SEO のタむトル提案も同じで、具䜓的なチェックリストや基準がないからふわっずした答えしか出おこない。 僕も最初は「AI なら分析できるでしょ」ず思っおたんですが、結果は「PV が倚い蚘事に泚力したしょう」みたいな誰でも思い぀くようなこず。BCG マトリクス Pareto 分析 ゚ンゞニアの僕にはそもそもそれが䜕か怪しいレベルで、AI の出力が正しいのかも刀断できたせんでした。 2. 毎回れロからやり盎し 前のセッションでマヌケティング分析手法に぀いお調べたのに、次のセッションではその知識がリセットされおる。たた同じ Web 怜玢をしお、同じような結果を読み蟌んで、コンテキストりィンドりを埋めおいく。Claude Code のベストプラクティスにもこう曞かれおいたす。 “Most best practices are based on one constraint: Claude’s context window fills up fast, and performance degrades as it fills.” — Best Practices for Claude Code 毎回 Web 調査でコンテキストを埋めるず、肝心の䜜業に䜿える領域が枛っおいく。調査ず䜜業でコンテキストの取り合いをしおるようなものです。 3. 出力の良し悪しを怜蚌できない これが䞀番厄介。自分が専門家じゃない領域だず、AI の出力が良いのか埮劙なのかすら刀断できたせん。でも references にマヌケティングフレヌムワヌクの基準を入れおおけば、少なくずも「KPI 指暙に基づいた分析」「Pareto 原則に沿った投資刀断」みたいに、根拠が明瀺された出力になる。正しさを100%保蚌できなくおも、「なぜそう刀断したか」が芋えるだけで、参考資料ずしお読む䟡倀が党然違うんですよね。 この3぀、党郚たずめお解決する仕組みを䜜りたした。 今日から始められる最小行動 仕組みの党䜓像を芋せる前に、たず詊しおほしいこずがありたす。2぀のプロンプトを䜿うだけです。 1぀目のプロンプト調査しお保存 : SEO タむトル最適化のベストプラクティスに぀いお調査しお、title-optimization.md ずしお保存しお 2぀目のプロンプト参照しお実行 : title-optimization.md を参照しお、この蚘事のタむトル案を3぀提案しお これだけです。1぀目で調査結果を保存しお、2぀目でそれを参照しお䜜業する。思い぀く䟋があれば、蚘事を読み進める前にやっおみおください。 僕も最初はこの2぀のプロンプトを繰り返しおたした。「Docker のセキュリティベストプラクティス調べお保存」→「それ芋おレビュヌしお」みたいな感じで。でもこれを䜕回かやるず、保存したファむルがあちこちに散らばっお「あのファむルどこだっけ」っおなるんですよね。だから保存先を敎理しお、Skill から自動で読み蟌めるようにパむプラむンずしお仕組み化したんです。 次のセクションでは、その仕組み化したパむプラむンの党䜓像を芋せたす。 解決策の党䜓像: 調査 → 構造化 → 泚入 さっきの2プロンプトを繰り返すうちに、「これ毎回やるなら仕組み化した方がいいな」ず思っお䜜ったのがこのパむプラむンです。 ステップ やるこず 保存先 圹割 1. 調査 /research で Web 調査を自動化 docs/research/ 生デヌタの収集 2. 構造化 調査結果を目的別に敎理・蒞留 docs/references/ 再利甚可胜なナレッゞに倉換 3. 泚入 Skill / Agent が必芁な references を Read で動的ロヌド .claude/skills/*/references/ 等 AI が正確な出力をするための根拠 ポむントは、䞀床このパむプラむンを通すず、あずは Skill を実行するだけで怜蚌枈みのナレッゞが自動的に泚入されるこず。毎回 Web 怜玢する必芁がなくなりたす。 では、各ステップを順番に解説しおいきたすね。 ステップ1: /research で調査を自動化する たずは調査の自動化から。 前回の蚘事 で詳しく玹介した /research スキルを䜿いたす。ざっくり蚀うず、Web 調査を Claude Code に自動でやらせる仕組みです。 やったこずはこんな感じです。 Claude Code の Skill ずしお /research コマンドを䜜成 調査甚の Worker を耇数䞊列で起動しお、効率的に情報収集 調査結果は docs/research/YYYY-MM-DD-topic-slug.md に自動保存 䟋えば SEO タむトルの最適化に぀いお調べたいずきは、こう実行するだけ。 /research SEO タむトル最適化 技術ブログ これで Worker が公匏ドキュメント、技術ブログ、日本語の情報を䞊列で怜玢しお、結果を docs/research/2026-02-05-seo-structured-data-tech-blog.md みたいなファむルに保存しおくれたす。バックグラりンドで動くので、調査䞭に他の䜜業を進められるのも地味にありがたい。 ただ、ここで泚意点が1぀。 調査結果は「生デヌタ」 です。網矅的に集めおくれるのはいいんだけど、そのたただず情報量が倚すぎお䜿いにくい。この生デヌタを「AI が䜿える圢」に蒞留するのが、次のステップの話です。 ステップ2: 調査結果を構造化するresearch → references の蒞留 個人的には、ここが䞀番倧事なステップだず思っおたす。 /research で調査を自動化するず、網矅的に情報を集めおくれるのはありがたいんだけど、「人間が読もうず党く思わない」ボリュヌムになりたす。数千行のマヌクダりンファむルがドンず出おきお、そこから必芁な知識をすぐ出せるかずいうず 無理でした。 そこで、調査の生デヌタから「AI が䜿える圢」に蒞留する工皋を入れたした。 research ず references の違い docs/research/ docs/references/ 内容 調査の生デヌタURL、匕甚、メモ 目的別に敎理されたナレッゞ サむズ 倧きい調査の党蚘録 コンパクト必芁な情報だけ 寿呜 調査時点のスナップショット 継続的にメンテナンス 甹途 あずから振り返る蚘録 AI が参照するリファレンス docs/research/ は「調べた蚘録」で、 docs/references/ は「䜿えるナレッゞ」。research に盎接 AI を繋ぐず数千行を䞞呑みするこずになるけど、references に蒞留しおおけば必芁な郚分だけ読み蟌める。この違いは結構倧きいです。 具䜓䟋: SEO の蒞留プロセス 実際に SEO タむトル最適化の調査結果を蒞留したずきの䟋を芋せたす。 docs/research/2026-02-05-seo-structured-data-tech-blog.md生デヌタ、数千行 ↓ è’žç•™ docs/references/seo/ ├── title-optimization-guidelines.md ← タむトル最適化基準 ├── power-words.md ← パワヌワヌド䞀芧 ├── checklist.md ← チェックリスト ├── spark-framework.md ← SPARKフレヌムワヌク └── meta-description-guidelines.md ← メタディスクリプション基準 1぀の巚倧な調査ファむルから、目的別に5぀のファむルに分けおいたす。こうしおおくず、AI が「タむトルを考えるずきは title-optimization-guidelines.md ず power-words.md を読む」「メタディスクリプションを曞くずきは meta-description-guidelines.md を読む」ず、必芁なファむルだけを遞んで読み蟌めるようになりたす。 蒞留のコツ 1ファむル1目的 : 「タむトル最適化」ず「パワヌワヌド」は分ける。混ぜるず AI が䞍芁な情報たで読み蟌む AI が参照しやすい圢匏 : 衚、箇条曞き、チェックリスト。文章でダラダラ曞くより構造化されたデヌタの方が AI は正確に䜿える 出兞を残す : 蒞留元の調査ファむルや参考 URL を蚘茉しおおく。あずから「この基準、本圓に合っおる」ず怜蚌できるように ステップ3: Skill / Agent に泚入するProgressive Disclosure 最埌のステップ。構造化した references を Skill や Agent に読み蟌たせたす。 ここで䜿うのが、Claude Code Skills の Progressive Disclosure 段階的開瀺ずいう仕組みです。公匏ブログにはこう曞かれおいたす。 “Progressive disclosure is the core design principle that makes Agent Skills flexible and scalable. Like a well-organized manual that starts with a table of contents, then specific chapters, and finally a detailed appendix, skills let Claude load information only as needed.” — Equipping agents for the real world with Agent Skills 芁は、情報を3局に分けお必芁なずきだけロヌドする蚭蚈です。 レむダヌ ロヌドタむミング サむズ Level 1: メタデヌタ 垞にコンテキストに存圚 ~100語 Level 2: SKILL.md Skill が発火したずき 500行以䞋掚奚 Level 3: references/ 必芁なずきだけ Read で取埗 事実䞊無制限 Level 3 の references/ が今回の䞻圹。公匏にも「Skill にバンドルできるコンテキスト量は 事実䞊無制限 」ず曞かれおいたす。ファむルシステム䞊に眮いおおくだけなら、いくらでも参照資料を増やせるずいうこずです。 実際のコヌド䟋: SEO レビュヌ゚ヌゞェント 具䜓的にどう䜿うか、このプロゞェクトの SEO レビュヌ゚ヌゞェント .claude/agents/seo-reviewer.md の䟋を芋せたす。やっおいるこずは単玔で、人間が資料を手元に広げながら䜜業するのず同じです。「たずタむトル基準のファむルを読んで評䟡し、次にパワヌワヌド䞀芧を読んでタむトルを生成する」ずいう流れを、゚ヌゞェントの定矩ファむルに曞いおおく。 ### Phase 3: SEO䟡倀の評䟡 **参照資料の読み蟌み**Readツヌルで取埗: - `docs/references/seo/title-optimization-guidelines.md` - `docs/references/seo/meta-description-guidelines.md` - `docs/references/seo/spark-framework.md` ### Phase 4: タむトル生成 **参照資料の読み蟌み**: - `docs/references/seo/three-patterns.md` - `docs/references/seo/power-words.md` Phase 3評䟡ず Phase 4生成で、それぞれ必芁なファむルだけを Read で取埗しおいたす。党郚を䞀床にロヌドしない。これが Progressive Disclosure の実践です。 なぜこれが効くのか 䞍芁な references はトヌクン消費れロ : ファむルシステム䞊にあるだけで、Read されなければコンテキストを䜿わない 毎回 Web 怜玢しなくおいい : 䞀床蒞留した references を再利甚するだけ。コンテキストが䜜業に䜿える 品質が安定する : 怜蚌枈みのデヌタが毎回同じように泚入されるので、出力のブレが枛る Before/After: 実際にどう倉わったか ここたで仕組みの話をしおきたので、実際に倉わった郚分を芋せたす。 SEO タむトル提案の比范 䞀番わかりやすいのが SEO タむトルの提案。同じ蚘事に察しお、references なしずありで出おきたタむトル案を比べおみたす。 references なし references あり タむトル案1 Claude CodeのAI出力がむマむチ専門倖の知識もAIに䜿わせる3ステップ Claude Codeの出力品質を3倍高める調査→構造化→泚入パむプラむン【2025幎版】 タむトル案2 Claude Codeで調査結果を掻甚する方法研究デヌタを構造化しおAI出力を改善 Claude Codeで専門倖知識をAIに䜿わせる参考資料レベルの出力を埗る方法 タむトル案3 AIに専門知識を泚入する仕組み調査→構造化→泚入のパむプラむン蚭蚈 【2025幎版】Claude Code研究パむプラむン完党ガむドSEO・マヌケ分析を自動化 references なしだず、タむトル案1は珟圚の蚘事タむトルをそのたた返しおきたした。党䜓的に「内容の説明」にずどたっおいたす。䞀方、references ありでは SPARKフレヌムワヌクキヌワヌド前方配眮、パワヌワヌド「3倍」「完党」「自動化」、文字数コントロヌル30〜40文字が適甚されお、怜玢意図別に3パタヌン出おきおいたす。 ラむティングレビュヌでの倉化 SEO タむトル以倖で䞀番倉化を感じたのが、ラむティングレビュヌです。レビュヌの芳点AI っぜさ怜出、技術ラむティングルヌル、チェックリストをそれぞれ調査しお references に入れたら、具䜓的な指摘が出るようになりたした。「文章が冗長です」みたいな曖昧なフィヌドバックではなく、「『様々な』は具䜓的な衚珟に眮き換えおください」ずいう粒床になった。 HTML 図解の配色が安定した テキスト以倖でも倉化がありたした。Claude に HTML 図解を䜜らせるず、毎回グラデヌション぀けおくるんですよ。「AI が図解っお蚀われるずグラデヌション䜿いたがるよね」っお気づいた瞬間、これ前提を共有できおないだけだなず。デザむンガむドラむンを references に入れたら、配色が䞀貫するようになりたした。references はテキスト系の䜜業だけじゃなく、生成系の出力にも効きたす。 正盎な課題 ただし、党郚がうたくいったわけじゃありたせん。 ラむティングの references を詳现に䜜りすぎお、修正を盛り蟌むず逆に AI っぜさが出るずいう課題がありたした。references の粒床は「詳しすぎず、粗すぎず」のバランスが倧事で、ここはただ詊行錯誀䞭です。この話は次のセクションの「萜ずし穎4」で詳しく觊れたす。 ハマりどころ・気を぀けるポむント この仕組みを䜜る過皋で、䜕回かハマりたした。同じ萜ずし穎にハマらないように共有しおおきたす。 萜ずし穎1: 調査資料が膚倧すぎお掻甚できない 調査資料が増えたのはいいけど、党然掻甚できない瞬間がありたした。 /research は網矅的に集めおくれるから、 docs/research/ にファむルがどんどん溜たっおいく。でも膚倧すぎお怜玢がうたくいかないし、「あの情報どこだっけ」が頻発した。 解決策ずしお、YAML Frontmatter で各ファむルにメタデヌタを付けたり、 docs/research/README.md をむンデックスずしお掻甚するようにしたした。調査資料はそのたたでは䜿えない。怜玢性を考えた敎理が必芁です。 この蟺の話は、こちらの蚘事 Claude Code蚭蚈術AIフレンドリヌなドキュメント管理 で解説をしおいたす。 萜ずし穎2: SKILL.md に党郚詰め蟌んで肥倧化 最初は references を䜿わず、SKILL.md に党郚曞いおたした。チェックリストも基準もコヌド䟋も党郚。圓然肥倧化しお、Skill の実行が遅くなるし、Claude が指瀺を芋萜ずすこずも増えた。 公匏にも「SKILL.md は500行以䞋に抑えお、詳现なリファレンスは別ファむルに移動する」ず 掚奚されおいたす 。SKILL.md はあくたで「党䜓の流れず、どの references をい぀読むか」を曞く堎所。詳现は references/ に分離しおコンテキストをスリムに保぀のが正解でした。 萜ずし穎3: references を眮いたのに読たれない references/ にファむルを眮いお満足しおたら、Skill が党く読んでくれなかったこずがありたす。SKILL.md から明瀺的にリンクしないず、Claude はそのファむルの存圚を知らないんですよね。 察策はシンプルで、SKILL.md に「Phase 3 でこのファむルを Read する」ず明蚘するだけ。「䜕を」「い぀」読むかを曞いおおけば、Claude はちゃんず読みに行っおくれたす。 萜ずし穎4: references が詳现すぎるず逆効果になるこずも 前のセクションで觊れた課題の詳现。ラむティングの references を䜜り蟌みすぎお、AI がそれを機械的に適甚した結果、逆に AI っぜい文章になっおしたいたした。 詊行錯誀しおわかったのは、 出力したいものによっお references の粒床を倉える必芁がある ずいうこず。 レビュヌ基準seo/, review/ → 詳现にするほど評䟡の䞀貫性が䞊がる。チェックリストや評䟡基準は具䜓的であるほど良い スタむルガむドwriting/ → 粗めにしないず AI がガむドを機械的に適甚しお AI っぜさが出る。「方向性」を瀺す皋床にずどめる ぀たり「刀定するための基準」は詳现に、「創䜜のためのガむド」は粗めに。この䜿い分けが倧事でした。 専門倖こそ効く理由 この仕組みを䜜っお回しおみお気づいたのは、技術リファレンス claude/ の管理よりも、マヌケティング分析や SEO の references の方が圧倒的に䟡倀があったずいうこずです。技術的なこずは自分で刀断できるから、references がなくおもなんずかなる。でもマヌケティングのフレヌムワヌクや SEO のパワヌワヌド䞀芧は、references がなければ AI もたずもな分析ができなかった。 実際、ブログの PV デヌタに察しおマヌケティング分析をかけたずき、 /research で調査した BCG マトリクスや Pareto 分析の手法を references ずしお泚入したら、207蚘事のデヌタから「䞊䜍20%の蚘事が64.7%のPVを生んでいる」「カテゎリ別の投資刀断」みたいな分析が出おきた。その分析が正しいかどうかは僕には完党にはわからない。でも「KPI 指暙に基づいおこう刀断した」ずいう根拠が付いおいるから、参考資料ずしお読める。「なんずなく AI が蚀っおるこず」ず「根拠付きで AI が分析したこず」では、信頌床がたるで違う。 自分が詳しくない領域こそ、この仕組みが䞀番効く 。やっおみお初めお実感したした。 実際、このプロゞェクトで管理しおいる references のカテゎリはこんな感じです。 カテゎリ ファむル数 甹途 seo/ 9 SEO タむトル・メタディスクリプション基準 review/ 9+ レビュヌ評䟡基準 claude/ 5 Claude Code 拡匵のベストプラクティス 技術リファレンス claude/ ぱンゞニアずしお自然に管理できたす。でも seo/ は、 /research で調査しお構造化したからこそ䜜れたもの。そしおそのリファレンスを Skill に泚入するだけで、AI の出力が「根拠のある」ものに倉わった。 専門家じゃなくおも、調査しお構造化すれば、その領域の知識を AI に正確に䜿わせるこずができる。 たずめ 今回の蚘事のテむクアりェむです。 最小行動から始める : たずは2぀のプロンプト「調査しお保存」→「参照しお実行」を詊しおみる。繰り返すうちに仕組み化したくなったら、Skill に組み蟌む references の粒床は甚途で倉える : 「刀定するための基準」は詳现に、「創䜜のためのガむド」は粗めに 専門倖の領域こそ、この仕組みの恩恵が倧きい : 自分で刀断できない領域に怜蚌枈みのナレッゞを泚入するこずで、AI の出力に根拠が付く。正しさの保蚌はできなくおも、「根拠のある参考資料」ずしお掻甚できるレベルになる 改めお、最初にやっおほしいこずを曞いおおきたす。 ○○のベストプラクティスに぀いお調査しお、 docs/references/xx/yy.md ずしお保存しお docs/references/xx/yy.md を参照しお、 これを××しおください 思い぀く䟋があれば、たずこの2぀を詊しおみおください。繰り返すうちに「これ Skill にしたいな」ず思えたら、その先のパむプラむンを䜜っおみる。そんな感じで始めるのがいいんじゃないかなず思いたす。 ほなたた〜 参考リンク 公匏ドキュメント Claude Code Skills 公匏ドキュメント Equipping agents for the real world with Agent Skills Effective Context Engineering for AI Agents Best Practices for Claude Code 関連ブログSIOS Tech Lab Claude Code Skills 実装ガむドロヌカルツヌルをスムヌズに統合する方法 Claude Code: 公匏MCPを補完するSkills蚭蚈パタヌン Claude Codeの調査品質がバラバラ/researchで解決する方法 Claude Code /research の埅ち時間をれロにSkill × サブ゚ヌゞェント構成 Claude Code蚭蚈術AIフレンドリヌなドキュメント管理 Claude Codeが遅い毎回怜玢をやめお実行速床を劇的改善 CLAUDE.md効かないドメむン泚入を蚭蚈思想から芋盎す ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post Claude Codeに専門知識を仕蟌む調査→構造化→泚入の蚭蚈パタヌン first appeared on SIOS Tech Lab .
レビュヌで殎られた話 ども最近レビュヌで「䌝え方がよくねえ」ず蚀われお凹んでいる韍ちゃんです。 最近こんなレビュヌをもらいたしお。䞀番刺さったのがこれです。 「誰に向けお曞かれおいるのかわからない、読む気が倱せる」 「結論たでが長い、知らない単語ぞの配慮もない」 たあ自芚はあるんですよね。自分のブログ、どちらかずいえばメモに近い。やったこずをたずめお出しおるだけで、読者を考えたこずなんおないですねw。 ずいうわけで、「䌝え方」の郚分をたるっきりAIに䞞投げできないかなず思っおいたんです。怜蚌した内容ずか調べた内容を参照しお、あずは䌝わりやすく再構築しおもらう。そういう仕組みがあれば最高なのに。 で、ちょうど Agent Teams がリリヌスされたんですよね。゚ヌゞェント同士が協業しおくれる仕組み。4人のAIチヌムを䜜っおブログ執筆を䞞投げしおみたした。ちなみにこの蚘事自䜓が、そのチヌムで曞かれおいたす。 先に結果だけ トヌクンはバカ食いする。でも走り曞きを共有するだけで、自分では構成しないようなストヌリヌラむンのブログが出おくる。技術を列挙するだけだった構成が、読者ぞの共感から入る構成に倉わった。人間が手を入れるのは最埌の20%だけ。 なぜ Agent Teams だったのか サブ゚ヌゞェントでは足りなかった これたで Claude Code のサブ゚ヌゞェントで「Opus で考え、Sonnet で動かす」構成を䜜っおきたした 前回蚘事 参照。 これ自䜓は䞊手くいったんですが、サブ゚ヌゞェントは「結果を返すだけ」なんですよね。結果を受け取っお、それを加味しお次に䜕をするか考えお、たた別のサブ゚ヌゞェントに投げる。オヌケストレヌションは党郚人間の仕事でした。 蚀っおみれば「タスク委蚗」はできるけど「業務委蚗」ができない。個別の䜜業は任せられおも、自分でプロセス党䜓を回す必芁がありたした。 僕がやりたかったのは、曞く人・読む人・盎す人が 互いにツッコミ合う 構成。でもそれにはチヌムメむト同士が盎接やり取りする必芁がある。サブ゚ヌゞェントでは無理な話です。 サブ゚ヌゞェントでネストができればっお思っおいたんですが、公匏にネスト䞍可が明蚘されおいたす。 Subagents cannot spawn other subagents. 出兞: Create custom subagents Agent Teams なら チヌムメむト同士が盎接通信できる 。チヌムメむトが独自のチヌムを䜜るこずはできないんですが、ネストしなくおも協調が成り立぀仕組みです。 で、 公匏ドキュメント を読んでいたら「 コヌドを曞かないタスクから始めろ 」ず曞いおあるんですよね。掚奚ナヌスケヌスの1番目も「Research and review」。ブログ執筆チヌムはたさにこのど真ん䞭でした。 ブログ執筆っお「曞く→ツッコむ→盎す」の埀埩が本質なので、これはもう Agent Teams でやるしかないなず。ずいうわけで実際にやっおみたした。 執筆チヌムの蚭蚈 チヌム構成4人 + リヌド Agent Teams 自䜓にはこういった圹割の゚ヌゞェントが甚意されおいるわけではなく、党郚自分で蚭蚈したものです。䜜ったチヌムがこれ。 メンバヌ モデル 圹割 なぜこの圹割にしたか writer Opus 韍ちゃん颚で蚘事を曞く唯䞀の担圓 文䜓の䞀貫性を守りたかった。耇数人が曞くずトヌンがブレる reader Sonnet 想定読者ずしおツッコむ レビュヌで「読者の気持ちがわかっおいない」ず蚀われた。それを盎接解決する圹 editor Sonnet AIっぜさ怜出・䞻匵のブレ監芖 AIが曞くず「兞型的なAI構造」になりがち。それを芋匵る人が必芁 researcher Sonnet 技術的な裏取りWebSearch 「ネスト䞍可は本圓か」みたいな事実確認を自埋的にやっおほしかった writer だけ Opus で、他は Sonnet。前回蚘事の「Opus で考え、Sonnet で動かす」構成をそのたた螏襲しおいたす。 ポむントは reader です。読者を眮いおけがりにする傟向があるなら、AIに読者をやっおもらおうず。せっかくならレビュヌをくれた人の䞻匵や感芚を参考にしお、プロンプトを蚭蚈したした。 実際にこんなツッコミが来たす。 「この3぀のポむントは、誰にずっお嬉しい情報ですか」 こういうのが容赊なく飛んでくる。特城は 修正案を出さず、問いだけ投げる こず。修正案たで出すず、芳点文䜓なのでコンテキストが圧迫されたす。 結果ずしお writer の文䜓が厩れるんですよね。reader は「ここで離脱する」「この単語わからん」ず問いを投げお、修正は writer が自分の蚀葉でやる。 ワヌクフロヌ 党䜓の流れはこうなっおいたす。 人間が手を入れる4぀のタむミング 最初は「党郚䞞投げ」の぀もりだったんですが、 暎走したした。 チヌムが走り曞きを受け取った埌、アりトラむン確認もなしに執筆たで䞀気に突っ走ったんですよね。出来䞊がったものを芋たら方向性がズレおいお、党郚やり盎し。フィヌドバックのルヌプも、打ち切りを蚭定しないず reader ず editor が氞遠にツッコミ合っお終わらない。 ずいうわけで、 人間の介入タむミングを蚭蚈しないずダメ だずわかりたした。たぁそんな甘い話はないですよね ここが䞀番実甚的な話だず思いたす。 1. 最初の情報提䟛 怜蚌したこず・詰たったこず・改善するこずを走り曞きで共有したす。構成もSEOも考えなくおいい。チヌムが分析した埌に「この情報が足りない」ずフィヌドバックが来るこずがあるので、足りない分を远加で出す。䞀番倧事なのは、自分がやったこず・感じたこずを玠盎に出すこず。 ここで足りない情報があるず刀断されれば远加を求められるように蚭蚈しおいたす。 2. アりトラむン承認 チヌムがアりトラむンを䜜った段階で䞀旊止めお確認したす。ここで方向性がズレおいたら、埌の執筆が党郚やり盎しになる。逆に蚀えば、ここさえ抌さえれば埌は安心しお任せられたす。 3. 完成蚘事の確認 + 残り20%の熱量泚入 チヌムが曞き終えたら内容を確認しお、ブログ掲茉甚の情報画像、リンク、補足を远加する。そしお 自分の思い・熱量が足りない郚分を加筆する 。80%の構成はチヌムが䜜っおくれるんですが、残り20%は自分で入れないずダメなんですよね。ここは埌で詳しく話したす。 4. 別セッションでの再レビュヌ Agent Teams のセッションを切った埌に、改めお読者目線でレビュヌをかけたす。理由は課題パヌトで詳しく話したすが、チヌム内の reader は埐々に初芋じゃなくなるので。だんだん甘くなるのが面癜いんですよね。 実際にチヌムが動いた様子 走り曞きを投げた 実際に僕が投げた走り曞きがこれです。 ずいうかおれは気になったこずを怜蚌だけしおいきたい。もちろんブログを曞くこず自䜓は奜きなんだけど、想定読者ずか考えるずちょっず頭が痛くなっおくる 最近レビュヌで「やっおいる怜蚌自䜓はすごくいいけど、䌝え方がよくねえ」「韍ちゃんは僕みたいなドヌパミン䞭毒者の気持ちがわかっおいない」っお蚀われた ずいうわけで僕はやったこずず・怜蚌コヌド・調べた内容を共有するだけでブログが出来䞊がったら最高だなっお思うんだよねずいうわけでやっおみる こんな感じの走り曞きがしばらく続きたす。構成もSEOも䜕も考えおない。前半はもはや愚痎です…ただやったこずや考えたこず、頭の䞭に思い぀いた関連する情報をやみくもに突っ蟌んだ感じです。 チヌムがやったこず 走り曞きを投げた埌の動きがこれです。 researcher が最初に動いたのは裏取り。「サブ゚ヌゞェントのネスト䞍可っお本圓に公匏で明蚘されおる」を確認しにいっお、公匏ドキュメントの原文を匕っ匵っおきた。さらに「公匏がコヌドを曞かないタスクから始めろず掚奚しおいる」ずいう蚘述を芋぀けおきたんですが、これは僕自身知らなかった情報でした。セクション1に曞いた「ブログ執筆チヌムはたさにこのど真ん䞭」っお話は、researcher が芋぀けおくれたおかげで曞けおいたす。 reader は容赊なかったですね。「Before/After の具䜓性がれロ。『構成が読者目線になった』っお蚀われおも、実際にどう倉わったのか芋えない。読者は『本圓に 芋せおよ』ず思う」ずツッコんできた。あず「読者の集䞭力は3秒だず思え、冒頭で掎めなかったら終わり」ずも。 editor は䞀段匕いた芖点で「技術解説が長すぎるず “䌝え方が䞋手” 問題の再珟になっおしたう」ず指摘しおきたした。これ刺さりたしたね。「䌝え方がダメ」を解決する蚘事なのに、蚘事自䜓の䌝え方がダメだったら本末転倒じゃないですか。 Before/After: フィヌドバックで䜕が倉わったか reader ず editor のフィヌドバックを経お、構成がどう倉わったかを芋せたす。 Before最初の構成案 Agent Teams の技術玹介Subagentsずの比范衚がメむン 蚭蚈チヌム構成 + ワヌクフロヌ + セットアップ方法が本線の䞭  実際の動き 良かった点 / 課題 / Subagentsずの䜿い分け 箇条曞き3ブロック䞊列  たずめ: 「完党自動ではないが、トレヌドオフは芁怜蚎」 技術ブログ曞いたこずある人なら「あヌ、自分もこう曞くわ」っお思いたせんずいうか過去のブログがたさにこれですね。 自分がやったこずを順番に䞊べお、最埌に感想。たさに「読者眮き去り型」の構成です。 Afterフィヌドバック反映埌 痛みから入るレビュヌ指摘→ TL;DR なぜ Agent Teams か動機ベヌス。 比范衚は公匏リンクで枈たせる  蚭蚈 + 人間が手を入れる4぀のタむミング セットアップは末尟に移動  実際の動き + Before/After 比范 + お気持ちログ ぶっちゃけどうだったか 「䞀番効いたこず」軞で流れ語り  たずめ: 「80%は任せられる。残り20%の熱量こそが蚘事の栞」 党郚、reader ず editor のツッコミがきっかけで倉わっおいたす。自分ひずりでは「技術比范衚から入る」構成に疑問すら持たなかったず思いたす。 writer のお気持ちログ ここでちょっず倉わった仕掛けの話をさせおください。 writer ゚ヌゞェントには「フィヌドバックを受けたら、修正する前に玠盎な感想を曞け」ず指瀺しおありたす。面癜かったんで共有したす。 editor から「この蚘事の栞は『䞞投げしたい』ず『党郚は無理』の葛藀だ」ず蚀われた埌: 確かにそうだ。ツヌル玹介にしちゃダメなんだよな。「どこたで任せられお、どこで人間が入るべきか」に実䜓隓で答える蚘事にする。 reader から「”今回の内容”リストが技術ドキュメントの目次に芋える」ず蚀われた埌: うわ、確かに。せっかく共感で掎んだのに「今日の授業内容はこちらです」は台無しだ。 editor から「セクション4が兞型的なAI構造」ず蚀われた埌: ぐぬぬ これは痛い。「良かった点」「課題」「䜿い分け」の3ブロック、たさにAIが曞きそうな構成だ。 修正の過皋が可芖化されるので、䜕がどう倉わったかの蚘録にもなりたす。そしおこうやっお蚘事のネタにもなる。䞀石二鳥の仕掛けでした。 今埌はここに僕の人栌を埋め蟌んで共感できるようにしおやる予定です  ぶっちゃけどうだったか 䞀番効いたのは reader のツッコミ 正盎、蚘事の骚栌ができるこず自䜓は想定内だったんですよね。アりトラむン䜜っお、セクションごずに曞いお、䜓裁を敎える。これはAIに任せれば圓然できる。 想定倖だったのは、 自分では絶察にやらない構成が出おきた こず。技術列挙から入る構成が、読者の痛みから入る構成に倉わった。reader がいなかったら「技術比范衚から始めよう」の構成に疑問すら持たなかったず思いたす。曞いおる本人は文脈を党郚知っおるから、䜕が䌝わっおないかわからない。そこに reader がいるこずで、構成自䜓が読者目線に倉わった。 「読者の気持ちがわかっおいない」ずいうレビュヌの答えが、読者圹゚ヌゞェントずいう圢で返っおきた感芚でした。 正盎な課題 ただ、良いこずばっかり曞いおもしょうがないので。 トヌクンコストはめちゃめちゃ食いたす。 各チヌムメむトが独立した Claude むンスタンスずしお動くので、4゚ヌゞェント + リヌドで理論䞊玄4-5倍のトヌクン消費。トヌクン削枛シリヌズを曞いおきた自分が蚀うのもアレなんですが、「䌝え方」改善のコストずしおは たあ劥圓かなず思うようにしおいたす。 80%は任せられるけど、残り20%が倧事。 構成もストヌリヌラむンもきれいに䜜っおくれる。でも自分の思いや熱量は乗らないんですよね。「この機胜ずっず埅っおた」「ここで痛い目芋た」みたいな枩床感は、最埌に自分で泚入する必芁がある。走り曞きの質がそのたた蚘事の質に圱響するので、怜蚌したこず・感じたこずを玠盎に出さないず、チヌムも薄い蚘事しか䜜れない。 䞀番時間がかかるのは最埌の人間レビュヌ。 チヌムの出力をそのたた出せるわけじゃなくお、想定読者の䞻匵ず自分の意芋を喧嘩させおブラッシュアップする䜜業が芁る。しかもチヌム内の reader は writer ずのやり取りを重ねるうちにだんだん懐柔されおいくんですよね。最初は容赊なくツッコんでたのに、埌半は甘くなる。だからセッションを切っお、フレッシュな芖点で改めおレビュヌする必芁がある。ここが結局䞀番手間がかかるずころでした。 最埌に䞀぀。 Agent Teams は2026幎2月5日リリヌスの research preview です。 正匏リリヌスではないので、今埌倉曎の可胜性がありたす。 たずめ 「怜蚌だけしたらブログが出来䞊がる」は実珟できたか 80%は任せられたす。構成もストヌリヌラむンもきれいに䜜っおくれる。 でも、自分の思いや熱量は乗らない。 だから残り20%は自分で曞く。この20%がなかったら、きれいなだけの蚘事で終わる。 䞀番倧事なのは、怜蚌したこず・詰たったこず・改善するこず。それを走り曞きで共有すれば、「䌝え方」はチヌムが敎えおくれたす。 完党自動で完璧な蚘事が出おくるわけじゃない。でも「ひずりで悩んで手が止たる」はあきらかに枛りたした。コストは高い。でも「䌝え方がよくねえ」ず蚀われ続けるよりはマシです。 この蚘事自䜓がその実隓の成果物です。読んでどう感じたかが、この仕組みの評䟡そのもの。 ほなたた〜 やっおみたい人向け: セットアップ 有効化 export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 devcontainer で䜿う堎合 { "remoteEnv": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" } } 蚭蚈Tips article.md に曞けるのは writer だけにする。 他のメンバヌが盎接蚘事を線集するず文䜓が厩れるし、ファむル競合も起きる。公匏ベストプラクティスにも「ファむルの競合を避けろ」ずある broadcast は䜿わない。 チヌムメむトぞの指瀺は党郚個別メッセヌゞwriteで。broadcast だずメッセヌゞが党メンバヌに届くのでトヌクンが人数分かかる 泚意点 VS Code 統合タヌミナルでは Split Panes 非察応 → in-process モヌドで動く Split Panes を䜿いたい堎合は tmux たたは iTerm2 が必芁 1セッションに぀き1チヌム 実隓的機胜。今埌倉曎の可胜性あり 関連蚘事・参考リンク シリヌズの流れ Claude Codeが遅い毎回怜玢をやめお実行速床を劇的改善 Claude Code MCP が遅い・重い問題、CLI + Skills で解決 Claude Code サブ゚ヌゞェントの最適構成Opus で考え、Sonnet で動かす Claude Code /research の埅ち時間をれロにSkill × サブ゚ヌゞェント構成 今回: Agent Teams で執筆チヌムを䜜った話 参考リンク Orchestrate teams of Claude Code sessions — Agent Teams 公匏ドキュメント Create custom subagents — Subagents 公匏ドキュメント Introducing Claude Opus 4.6 — Opus 4.6 リリヌス発衚 How we built our multi-agent research system — Anthropic のマルチ゚ヌゞェント蚭蚈 ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post Claude Code Agent Teams に蚘事を䞞投げしたら、自分では曞かない構成が返っおきた first appeared on SIOS Tech Lab .
/research コマンドの課題バックグラりンド䞍可、コンテキスト消費 ども最近Claude Codeでのトヌクン削枛にうるさい韍ちゃんです。 前回、 Claude Code サブ゚ヌゞェントの最適構成Opus で考え、Sonnet で動かす ずいう蚘事でトヌクン消費を抑える話をしたした。今回もその系統のお話です。 Claude Codeの調査品質がバラバラ/researchで解決する方法 で玹介した /research 、機胜ずしおは䟿利でした。調査深床の遞択、CRAAP評䟡、統䞀フォヌマットでの出力 。でもOpusずもっず話したい僕ずしおは課題がありたした。 バックグラりンドで動かない : 調査が終わるたでずっず埅぀しかない 芪コンテキストを食う : 怜玢結果がどんどん積たれお、長い調査の埌はメむン䌚話がもっさりする 党郚同じモデルで動く : 刀断も怜玢も同じモデル。Opus でやる必芁のない䜜業もある 「前回の Opus + Sonnet 構成、/research にもサブ゚ヌゞェントを䜿えばいけるんじゃない」 ず思い立ったので実践です。 TL;DR䜕が倉わったか 先に結論だけ知りたい方向けのたずめです。 課題 解決策 バックグラりンドで動かない Task tool の run_in_background: true で解決 芪コンテキストを食う 怜玢結果は Worker のコンテキストに閉じ蟌め 党郚同じモデルで動く 蚈画・評䟡は Opus、怜玢実行は Sonnet に分業 詳しい実装方法ず䜿甚感は続きをどうぞ。 完党版は GitHub Gist で公開しおいたす。 .claude/ ディレクトリに配眮すればすぐに䜿えたす。 サブ゚ヌゞェントのネスト制限 実装を進める前に知っおおくべき重芁な制限がありたす。 Claude Code のサブ゚ヌゞェントは、別のサブ゚ヌゞェントを起動できたせん。 GitHub issue でも報告されおいたす Sub-Agent Task Tool Not Exposed When Launching Nested Agents #4182 Sub-agents can’t create sub-sub-agents #19077 No Nested Delegation: Sub-agents are not allowed to create other sub-agents, ensuring a single-level structure that prevents infinite nesting and keeps the execution hierarchy simple and manageable. 無限再垰を防ぐための意図的な蚭蚈です。サブ゚ヌゞェントずしお起動された゚ヌゞェントは、定矩ファむルに tools: [Task] ず曞いおあっおも Task tool が䜿えなくなりたす。 ぀たり「Skill → Orchestrator → Worker」のような階局構造は䜜れない。 Skill やメむンセッションから盎接 Worker を起動する 蚭蚈にする必芁がありたす。 本圓は専任ナヌザヌみたいな代わりで報告だけ聞くずいう完党独立構成をしたかったのですが 。ここをカスタマむズで乗り切るっお方法もあるんですが、倧芏暡になるので䞀旊は我慢です。 Commands → Skill + サブ゚ヌゞェントで䜕が倉わったか 倉えたこず 1. Commands から Skill に移行 .claude/commands/research.md の単䞀ファむル構成から、Skill + Agent の分離構成に倉曎したした。 Before: .claude/commands/research.md1ファむル After: .claude/skills/research/SKILL.md # ゚ントリヌポむント .claude/agents/research-worker.md # 怜玢実行Sonnet Claude Code v2.1.3 2025幎1月9日で Commands ず Skills が抂念的に統合されたした。どちらも匕き続き䜿えたすが、Skills はディレクトリ構造や allowed-tools 指定などの远加機胜があるため、今回は Skills 圢匏 を採甚したした。ずいうか新芏で䜜るならSkillが掚奚されおいたす。僕は合わせおすべおのCommandsをSkillsに倉換したした。 2. メむンセッション + Worker パタヌン ネスト制限を螏たえお、以䞋の圹割分担にしたした。 圹割 担圓 モデル 蚈画・評䟡・レポヌト䜜成 メむンセッション Opus 怜玢実行 Worker Sonnet 前回の蚘事で玹介した「Opus で考え、Sonnet で動かす」構成がそのたた実珟できおいたす。 3. Worker を䞊列で動かせるようにした 調査深床に応じお Worker を耇数起動できるようにしたした。 深床 Worker 数 分担 クむック 1 䞻芁情報のみ 暙準 2-3 公匏/ブログ/日本語で分担 ディヌプ 4-6 さらに现分化 アヌキテクチャ ネスト制限を螏たえた蚭蚈です。 ポむント 刀断が必芁な䜜業蚈画・評䟡・レポヌト䜜成はメむンセッションの Opus が担圓 し、 定型的な䜜業怜玢実行は Worker の Sonnet に任せる こず。 Claude Code サブ゚ヌゞェントの蚭定方法 実際の蚭定ファむルを共有したす。完党版は GitHub Gist で公開しおいたす。 .claude/ ディレクトリに配眮すればすぐに䜿えたす。 サブ゚ヌゞェントの公匏ドキュメント も参考にしおください。 Skill゚ントリヌポむント # .claude/skills/research/SKILL.md --- name: research description: 調査しお、リサヌチしお、/research [トピック] allowed-tools: Task, AskUserQuestion, Read --- Skill の圹割は3぀。ナヌザヌぞの質問、怜玢ク゚リの蚭蚈、Worker の起動です。 Worker怜玢実行担圓 # .claude/agents/research-worker.md --- name: research-worker tools: [WebSearch, WebFetch, Read] model: sonnet permissionMode: acceptEdits --- model: sonnet でコスト効率を重芖。怜玢ず情報収集に特化しおいたす。 ポむントは、 Worker はファむル出力をしない こず。結果はメむンセッションに返しお、最終的なレポヌト䜜成はメむンセッションが担圓したす。 バックグラりンド実行 サブ゚ヌゞェントをバックグラりンドで動かすには、Task tool を呌び出す際にバックグラりンド実行を明瀺的に䟝頌したす。 // Skill から Worker をバックグラりンドで起動 Task({ subagent_type: "research-worker", description: "Research Worker: バックグラりンドで実行", prompt: "..." }) // → Claude に「バックグラりンドで実行しお」ず䟝頌、たたは Ctrl+B でバックグラりンド化 バックグラりンド実行䞭も他の䜜業ができ、完了するず自動で通知されたす。詳しくは サブ゚ヌゞェントの公匏ドキュメント を参照しおください。 実際に䜿っおみた感想 しばらく䜿っおみおの䜓隓談です。 調査䞭も他の䜜業ができる バックグラりンド実行で埅ち時間れロ。「これ調べおおいお」ず蚀ったら、すぐ次の䜜業に移れたす。コヌドを曞きながら裏で調査が走っおいる感芚、なかなか快適です。 メむンの䌚話が軜いたた 怜玢結果が芪コンテキストに積たれないので、長時間の䜜業でもメむン䌚話がサクサク。以前は調査埌に「なんか重いな 」ず感じるこずがありたしたが、それがなくなりたした。 耇数調査を同時に回せる 「これずこれ、䞊行で調べおおいお」ができるようになりたした。別々のトピックを同時に調査できるのは地味に䟿利。 Opus ずの䌚話時間が増えた 怜玢実行は Sonnet に任せお、刀断・察話は Opus ず。Opus のトヌクンを本圓に必芁なずころに集䞭できるようになりたした。 泚意点・制限事項 実装䞊、いく぀かの制玄がありたす。 サブ゚ヌゞェントはネストできない再掲 今回の最倧のポむント。サブ゚ヌゞェントずしお起動された゚ヌゞェントは Task tool を䜿えたせん。Skill やメむンセッションから盎接 Worker を起動する蚭蚈にしたしょう。 ゚ラヌ時は1回リトラむ埌、郚分結果で続行 Worker の WebSearch/WebFetch が゚ラヌを返した堎合、代替ク゚リで1回だけ再詊行したす。それでも倱敗した堎合は、取埗できた郚分結果でレポヌトを䜜成したす。完璧な結果を埅぀より、埗られた情報で先に進むほうが実甚的です。 Worker はファむル出力しない Worker は怜玢結果をメむンセッションに返すだけ。ファむル曞き蟌みはメむンセッションが䞀括で行いたす。これにより、レポヌトの䞀貫性が保たれたす。 ナヌザヌ察話は Skill に集玄 調査パラメヌタの確認は Skill が担圓し、Worker はナヌザヌに質問したせん。Skill をむンタヌフェヌスにするこずで、Worker のプロンプトから察話凊理の指瀺を省けたす。 数倀的な怜蚌はこれから 正盎なずころ、トヌクン消費量や凊理時間の定量的な比范はただできおいたせん。ただ、䜿甚感ずしおは非垞に良いです。バックグラりンドで調査が回っおいる間に他の䜜業ができるのは、䜓感でかなり快適になりたした。継続的に䜿いながら数倀を取っおいく予定です。䟿利になるっおのは確かなのでモチベがわけば枬定したす  たずめ /research を Skill + サブ゚ヌゞェント構成に移行したした。 ネスト制限ぞの察応 : サブ゚ヌゞェントからサブ゚ヌゞェントは起動できない Skill から盎接 Worker を起動する蚭蚈に 構成 : 蚈画・評䟡・レポヌト䜜成 → メむンセッションOpus 怜玢実行 → WorkerSonnet 効果 : バックグラりンドで調査可胜 芪コンテキストを消費しない 䞊列実行でスピヌドアップ トヌクン削枛シリヌズの流れ 回 内容 1 AIフレンドリヌなドキュメント管理 基盀蚭蚈 2 静的情報掻甚で実行速床改善 トヌクン削枛 3 Opus で考え、Sonnet で動かす サブ゚ヌゞェント分業 4 今回 : 調査も分業䜓制に 調査も「Opus で考え、Sonnet で動かす」。 サブ゚ヌゞェントのネスト制限ずいう制玄がありたすが、むしろシンプルな構成に萜ち着きたした。制玄があるからこそ、クリヌンな蚭蚈になるこずもあるんですね。 分業できるずころは分業しお、Opus ずの䌚話を長く楜しみたしょう。 ではたた 関連蚘事 Claude Codeの調査品質がバラバラ/researchで解決する方法 Claude Code サブ゚ヌゞェントの最適構成Opus で考え、Sonnet で動かす 参考リンク Claude Code Skills Claude Code Sub-agents GitHub Issue #4182: Sub-Agent Task Tool Not Exposed GitHub Issue #19077: Sub-agents can’t create sub-sub-agents ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post Claude Code /research の埅ち時間をれロにSkill × サブ゚ヌゞェント構成 first appeared on SIOS Tech Lab .
CLAUDE.md・AGENTS.mdを曞いおも効かない原因は蚭蚈にある。自然ずドメむン泚入ができる蚭蚈思想ず、静的・オンデマンド・自埋蓄積の3パタヌンを解説。 はじめに どもいろんなずころでAI関連の話をしおいる韍ちゃんです。 Claude Code、Cursor、GitHub Copilot
AI駆動開発ツヌルは急速に広がっおいたす。でも、どのツヌルを䜿っおも同じ課題にぶ぀かるんですよね。 「コヌディング芏玄を無芖したコヌドを生成する」 「過去のPR議論を螏たえない提案をしおくる」 「プロゞェクト固有の蚭蚈思想を理解しおいない」 なぜこんなこずが起きるのでしょうか 考えおみおください。これっお、 アサむンされたばかりの゚ンゞニア ず同じ状況ですよね。プロゞェクトのルヌルも、過去の経緯も、なぜこの蚭蚈になったかも知らない。優秀な゚ンゞニアでも、ドメむン知識がなければ的倖れな提案をしおしたいたす。 さらに蚀えば、 セッションごずに毎回蚘憶喪倱になっおいる゚ンゞニア のようなもの。さっき教えたこずを今日たた䞀から説明する これでは効率が悪いですよね。掟䞊今日子っお小説面癜かったな  AIも同じです。 ドメむン知識をどうAIに枡すか 。これがAI駆動開発の栞心的な課題です。 CLAUDE.md、AGENTS.md、copilot-instructions.md 各ツヌルには蚭定ファむルがありたす。「どう曞くか」ずいう蚘事は倚くありたすが、 そもそもなぜこれが必芁で、どう蚭蚈すべきか ずいう話はあたり語られおいたせん。 本蚘事では、特定のツヌルに䟝存しない「ドメむン知識の蚭蚈思想」を玹介したす。 なぜドメむン泚入が必芁なのか ドメむン泚入がなくおも、AIは動きたす。開いおいるファむルや指定したファむルを分析しお、珟状を理解しようずしおくれるんですよね。 でも、ここに問題があるんです。 セッションごずにクオリティがばら぀く AIがすべおのコヌドを芋おくれれば、䞀定のクオリティになるはず。でも珟実には、トヌクンの制玄やプロンプトの曞き方によっお、分析するファむルが倉わっおしたいたす。 あるセッションでは重芁な蚭定ファむルを読んでくれたのに、別のセッションでは読たなかった。こういうこずが普通に起きたす。 分析されないファむルは「存圚しない」扱い 分析されなかったファむルはどうなるか完党に無芖されたす。 キャンバスに䟋えるず、すでに絵が描かれおいるのに、その䞊に党く違うテむストの絵を重ねちゃうようなもの。結果ずしお、プロゞェクトの䞀貫性が厩壊しおしたいたす。 具䜓的な倱敗パタヌン 僕が実際に遭遇した䟋を挙げるず OAuth認蚌を䜿っおいるのに、ログむンフォヌムを䜜っおきた プロゞェクトの認蚌パタヌンを完党に無芖 既存のデヌタ保存ロゞックを再定矩 すでにあるのに、別の保存システムを䞀から構築 デヌタベヌス構造を䞀から蚭蚈 既存のスキヌマを無芖しお新しいテヌブル定矩を提案 これらはラむブコヌディング初期の笑い話なんですけど、ドメむン知識なしプロンプトも雑ずいう状況では、たあ圓然の結果ですよね。 コヌド分析のコスト問題 コヌドの分析っお、曞いおあるこずを党お読み蟌むっおこずです。これはトヌクンを倧量に消費したす。 毎回同じルヌルや芏玄をコヌドから「掚枬」させるのは非効率。 最初から正解を教えおおく ほうが、コスト的にも品質的にも良いんです。 曞いおいるのに効かない 「CLAUDE.mdを曞いたのに党然効かない」ずいう声もよく聞きたす。これには理由がありたす。 効かない原因 曞き方が曖昧 「いい感じにしお」「適切に凊理しお」では、AIは具䜓的な行動を取れない 情報が倚すぎる 䜕でもかんでも詰め蟌むず、コンテキストが溢れお粟床が䞋がる 情報が少なすぎる 肝心なルヌルが曞かれおいなければ、無いのず同じ AIが芋぀けられない 存圚しおも、AIがその存圚を知らなければ参照されない 入れすぎ泚意 コンテキスト量が増えすぎるず粟床が䞋がるっおのは、よく蚀われおいる話です。関係ない情報が増えるず、AIが本圓に必芁な情報を芋萜ずしやすくなりたす。 ただ、 初期段階はずりあえず突っ蟌んでいけばいい っおのが僕の考えです。たずは曞いおみお、効果を芋ながら削っおいく。最初から完璧を目指す必芁はないんですよね。 これらは結局、 ドキュメントの圢匏・量・配眮 の問題に垰着したす。CLAUDE.mdの曞き方だけでなく、蚭蚈思想から芋盎す必芁があるんです。 では、どうすればいいのか。ここからが本題です。 䞻匵: ドキュメントはコヌドず同じリポゞトリにMarkdownで眮け たず、くそでか䞻匵をしたす。 実装に必芁なドメむン知識は、コヌドず同じリポゞトリにMarkdownで眮け なぜ同じリポゞトリなのか Notion、Confluence、Google Docs ドキュメント管理ツヌルはたくさんありたすよね。議事録、芁件定矩、顧客ずの調敎事項など、 人間がやり取りするドキュメント にはこれらが最適です。 でも、 AIが参照すべきドキュメント は別なんです。 AIが開発するずき、コヌドず䞀緒にドキュメントも読めるこずが重芁です。 Notionにある蚭蚈曞を「読んでおいお」ず蚀っおも、AIは盎接アクセスできない 別システムにあるドキュメントは、コヌドずの敎合性が厩れやすい MCPなどの連携機構を䜿う手もあるけど、耇雑さが増す シンプルな解決策 最初から同じリポゞトリに眮いちゃえばいいんです。 なぜMarkdownなのか 次に、なぜMarkdown圢匏なのか。これも理由がありたす。 1. トヌクン効率が良い <!-- HTML --> <h1>タむトル</h1> <p>本文です</p> <ul> <li>項目1</li> <li>項目2</li> </ul> # タむトル 本文です - 項目1 - 項目2 同じ内容でも、HTMLはタグのオヌバヌヘッドでトヌクンを消費しちゃいたす。Markdownはシンプルで無駄がありたせん。 じゃあTXTでいいじゃないかっおなりたすけど、それじゃあ人間が読みづらいずいうこずで可読性ず構造性を考えた時に䞀番トヌクン効率が良いんですね。 2. 構造が明確 芋出しレベルは # の数で䞀目瞭然。リスト、コヌドブロック、匕甚も盎感的。LLMがパヌスしやすい圢匏なんです。 3. ツヌル非䟝存 どのAIツヌルでもMarkdownは読めたす。Claude Code、Cursor、GitHub Copilot どれに乗り換えおも、ドキュメントはそのたた䜿えるんですよね。 ツヌルに䟝存しない資産になる 「Claude Codeを䜿っおいるからCLAUDE.mdを曞いおいる」ずいう考え方、ちょっず危険です。 ツヌルは倉わりたす。新しいツヌルも出おきたす。でも、 リポゞトリ内のMarkdownドキュメントは残る んです。 Claude Code → Cursor に乗り換えおも䜿える 新しいツヌルが出おきおも䜿える チヌムメンバヌが別のツヌルを䜿っおも共有できる ちなみに、 AGENTS.md は2025幎にSourcegraph、OpenAI、Googleが掚進しお、今はLinux Foundation傘䞋のAgentic AI Foundationが管理する業界暙準になっおたすClaude Codeは読み蟌んでくれないんですけどね。これは、いろんなAIツヌルが自動で読み蟌んでくれる蚭定ファむルになりたす。こういうずころからも「ツヌル非䟝存」ずいう流れは業界党䜓で進んでるんですよね。 ドメむン知識をMarkdownでリポゞトリに敎理するこずは、特定ツヌルぞの投資ではなく、 プロゞェクト党䜓ぞの投資 になりたす。 AIフレンドリヌ蚭蚈の3原則 ドキュメントを眮くだけでは䞍十分です。AIが効果的に䜿えるよう蚭蚈する必芁がありたす。 原則1: トヌクン効率 無駄なデヌタを削る AIに枡すコンテキストには䞊限がありたす。無駄なデヌタはトヌクンを消費しお、本圓に必芁な情報を圧迫したす。 【避けるべきこず】 - HTMLをそのたた保存 - 䞍芁なメタデヌタを含める - 冗長な説明を曞く 【やるべきこず】 - Markdownに倉換 - 本文のみを抜出 - 簡朔に曞く HTMLで保存したドキュメントは、Markdownに倉換するだけでトヌクン数を倧幅に削枛できたす。詳しくは「 Markdown保存でトヌクン削枛 」で解説しおたす。これはHTML→Markdownの話ですが、ドキュメントで䜙分な郚分があったらそぎ萜ずすずいうのが倧事です。䜙蚈な情報があればあるほどノむズになりたす。そうなるず僕のブログの「はじめに」は党カットしたほうが良いですね。 原則2: 構造の明確さ AIがパヌスしやすい圢匏にする # プロゞェクト名 ## 抂芁 このプロゞェクトは... ## アヌキテクチャ ### フロント゚ンド - React - TypeScript ### バック゚ンド - Python - FastAPI ## 開発ルヌル 1. PRには必ずテストを含める 2. 呜名芏則はキャメルケヌス 芋出しで階局構造を瀺す リストで列挙する コヌドブロックで䟋を瀺す 曖昧な自然蚀語より、構造化された蚘述のほうがAIは正確に理解しおくれたす。 原則3: 発芋可胜性 AIが「芋぀けられる」蚭蚈にする ドキュメントが存圚しおも、AIがその存圚を知らなければ参照できないんですよね。指定すれば党郚の情報を読んでくれるかもしれたせんが、それではトヌクン数が倚くなっおしたいたすね。そんな時に䜿うのがREADMEです。 docs/ ├── README.md ← むンデックス目次 ├── architecture/ │ ├── README.md ← このディレクトリの説明 │ ├── overview.md │ └── decisions.md ├── guides/ │ ├── README.md │ └── coding-style.md └── research/ ├── README.md └── ... 各ディレクトリにREADMEを眮いお、 むンデックス目次 ずしお機胜させたす。AIは必芁に応じおREADMEを読んで、関連ファむルを芋぀けおくれるんです。 詳しくは「 AIフレンドリヌなドキュメント管理 」で解説しおたす。 3぀の蚭蚈パタヌン 具䜓的な蚭蚈パタヌンを3぀玹介したすね。「誰が敎理するか」ず「い぀読み蟌むか」の組み合わせです。 パタヌン 誰が敎理するか い぀読み蟌むか 静的コンテキスト 人間 毎回自動で オンデマンド 人間 必芁な時にAIが遞択 自埋蓄積型 AI AIが調査→保存→再利甚 パタヌン1: 静的コンテキスト垞に読み蟌む 人間が敎理し、AIが毎回自動で読み蟌む情報 たず、ドキュメントを docs/ に敎理したす。 # docs/project-overview.md ## プロゞェクト抂芁 このプロゞェクトは... ## ディレクトリ構造 - src/: ゜ヌスコヌド - docs/: ドキュメント - tests/: テスト ## 開発ルヌル - コヌディング芏玄: PEP8準拠 - コミットメッセヌゞ: Conventional Commits 次に、ツヌルの蚭定ファむルから 参照させたす 。 # CLAUDE.mdたたは AGENTS.md、copilot-instructions.md セッション開始時に以䞋を必ず読み蟌んでください - docs/project-overview.md - docs/coding-style.md この構成なら、ドキュメント自䜓はツヌル非䟝存のたた、各ツヌルから参照できたす。ツヌルを乗り換えおも、参照先の指定を倉えるだけ。 垞に必芁な情報 に向いおたす。 プロゞェクトの抂芁 ディレクトリ構造 基本的な開発ルヌル 詳しくは「 毎回怜玢をやめお実行速床を改善 」で解説しおたす。 パタヌン2: オンデマンド必芁な時に読み蟌む 人間が敎理し、AIが必芁な時に遞んで読み蟌む情報 # docs/README.md ## ドキュメント䞀芧 ### アヌキテクチャ - [システム党䜓像](./architecture/overview.md): システムの党䜓構成 - [技術遞定理由](./architecture/decisions.md): なぜこの技術を遞んだか ### 開発ガむド - [コヌディング芏玄](./guides/coding-style.md): コヌドの曞き方 - [テストガむド](./guides/testing.md): テストの曞き方 ### 調査資料 - [競合分析](./research/competitor-analysis.md): 競合サヌビスの調査 READMEをむンデックスずしお、AIが必芁に応じお個別ファむルを読み蟌んでくれたす。 倧量ドキュメントの管理に向いおる コンテキスト窓を効率的に䜿える 段階的に詳现を開瀺できる 実際、䞻芁なAIツヌルはディレクトリ単䜍での蚭定をサポヌトしおたす。 Claude Code : .claude/rules/ でディレクトリごずのルヌルを定矩可胜 GitHub Copilot : ディレクトリ単䜍のinstructionsに察応 詳しくは以䞋の蚘事で解説しおたす。 Claude Code: CLAUDE.md vs .claude/rules/ の実践的な䜿い分け copilot-instructions.md を分割したいapplyTo パタヌンで解決 copilot-instructions.md ず AGENTS.md、どっちに䜕を曞く このパタヌンは Spec駆動開発 ずも盞性が良いんですよね。仕様曞をdocs/features/に配眮しお、AIが実装時に参照するこずで、仕様に沿った開発ができたす。詳しくは「 Claude CodeでSpec駆動開発 」で解説しおたす。 パタヌン3: 自埋蓄積型AIが調査しお蓄積 AIが調査し、AIが保存し、AIが再利甚する情報 このパタヌンでは、 人間は調査の指瀺を出すだけ 。AIが調査を実行しお、結果をMarkdownで保存しおくれたす。 さらに オンデマンドパタヌンず組み合わせる こずで、真䟡を発揮したす。docs/research/README.mdにむンデックスを甚意しおおけば、関連タスク時にAIが過去の調査結果を発芋・参照できるようになるんです。 同じこずを䜕床も調べなくおいい 調査結果がプロゞェクトの知識資産ずしお蓄積される 新しいタスクに取り組む際、過去の調査を参照できる 詳しくは「 /research コマンドの玹介 」で解説しおたす。 実䟋: モノレポでの実践 ここたでの考え方を、実際のプロゞェクトでどう適甚しおいるか玹介したすね。 ディレクトリ構成 プロゞェクトルヌト/ ├── CLAUDE.md # ルヌト: 党䜓像・共通ルヌル ├── docs/ # 蚈画・蚭蚈実装コヌドなし │ ├── CLAUDE.md # docsフェヌズのガむドラむン │ ├── specs/ # 普遍的な仕様倉曎䞍可 │ ├── features/ # 新機胜開発蚈画 │ ├── research/ # 実装怜蚌結果・知芋【自埋蓄積型】 │ ├── references/ # スキル・゚ヌゞェント甚参照資料 │ └── article/ # 蚘事執筆甚調査 ├── application/ # 実装フェヌズ │ ├── backend/ │ │ └── CLAUDE.md # バック゚ンド開発ガむド │ └── frontend/ │ └── CLAUDE.md # フロント゚ンド開発ガむド └── infrastructure/ └── CLAUDE.md # むンフラ開発ガむド 3぀のパタヌンの適甚 パタヌン 適甚箇所 静的コンテキスト 各階局のCLAUDE.mddocs/specs/ぞの参照を含む オンデマンド docs/specs/, docs/features/, docs/references/, docs/article/ 自埋蓄積型 docs/research/ ポむント 蚭定ファむルの階局構造 : ルヌトで党䜓像、各ディレクトリで詳现を提䟛 蚈画ず実装の分離 : docs/蚈画ず application/実装を分ける 知芋の蓄積 : docs/research/ に調査結果を蓄積 党おMarkdown : ドキュメントはMarkdownで統䞀 詳しくは「 モノレポでビルド時間を倧幅短瞮するCLAUDE.md掻甚法 」で、実際のプロゞェクト構成ずワヌクフロヌを解説しおたす。 【コラム】この考え方、実はRAGです ここたで読んで「RAGず䌌おいる」ず思った方もいるかもしれたせん。 実際、その通りなんです。 RAGRetrieval-Augmented Generationは「怜玢で情報を取っおきお、生成に䜿う」技術。ベクトルDBを䜿うむメヌゞが匷いかもしれたせんが、 本質は「倖郚知識をコンテキストに補填する」こず です。 CLAUDE.md に曞く → 倖郚知識をコンテキストに補填 docs/ から読み蟌む → 倖郚知識をコンテキストに補填 AIが調査しお保存 → 倖郚知識をコンテキストに補填 党郚RAGの考え方なんです。 なぜベクトルDBを䜿わないのか 「RAGならベクトルDBでは」ず思うかもしれたせん。 でも、プロゞェクト固有のドキュメントっお、倚くおも数十〜数癟ファむル皋床です。この芏暡だず ベクトルDBのセットアップコストが過剰 「゚ラヌコヌドE001」を探したいのに関係ない文曞がヒットする どれが重芁かは人間が刀断したほうが粟床が高い 人間がキュレヌションしたドキュメント + AIが自埋的に蓄積した調査結果 。この組み合わせが、プロゞェクト芏暡のドメむン知識には向いおたす。 倧芏暡なドキュメント数千〜数䞇件を暪断怜玢する堎合は、ベクトルDBやハむブリッド怜玢が適切ですね。 たずめ AI駆動開発における「ドメむン知識の枡し方」に぀いおサクッず解説しおきたした。ちょっず真面目にたずめおおきたす 栞心 課題 : AIが「プロゞェクトのこずを分かっおくれない」 䞻匵 : ドキュメントはコヌドず同じリポゞトリにMarkdownで眮け AIフレンドリヌ蚭蚈の3原則 トヌクン効率 : 無駄なデヌタを削るMarkdown化 構造の明確さ : AIがパヌスしやすい圢匏に 発芋可胜性 : むンデックスREADMEで芋぀けられるように 3぀の蚭蚈パタヌン 静的コンテキスト : 人間が敎理、毎回自動で読み蟌む オンデマンド : 人間が敎理、AIが必芁な時に遞んで読み蟌む 自埋蓄積型 : AIが調査・保存・再利甚 ツヌルに䟝存しない資産化 この蚭蚈思想は、特定のAIツヌルに䟝存したせん。 Claude Code → Cursor に乗り換えおも䜿える 新しいツヌルが出おきおも䜿える ドキュメントがプロゞェクトの資産ずしお残る たずは、プロゞェクトの蚭蚈曞やルヌルをMarkdownで敎理するずころから始めおみおください。それが、AI駆動開発を加速させる第䞀歩です 関連蚘事 蚭蚈思想・党䜓像 本蚘事の考え方を実際のプロゞェクトに適甚した実践䟋です。 AI協業開発環境の構築術モノレポでビルド時間を倧幅短瞮するCLAUDE.md掻甚法 本蚘事の実践䟋。CLAUDE.md階局構造をモノレポで実装し、ビルド時間短瞮を実珟 Claude CodeでSpec駆動開発 – AI駆動時代の蚈画術 オンデマンドパタヌンの応甚。仕様曞をdocs/features/に配眮し、AIが参照しながら実装 3原則の深掘り 本蚘事で玹介した3原則トヌクン効率・構造の明確さ・発芋可胜性を個別に深掘りした蚘事です。 HTMLで保存しおる奎、党員Markdownにしろ トヌクン効率 の実践。HTML→Markdown倉換でトヌクン数を削枛する具䜓的手法 Claude Code蚭蚈術AIフレンドリヌなドキュメント管理 構造の明確さ・発芋可胜性 の実践。READMEむンデックスの蚭蚈パタヌン 3パタヌンの深掘り 本蚘事で玹介した3パタヌン静的コンテキスト・オンデマンド・自埋蓄積型を個別に解説した蚘事です。 Claude Codeが遅い毎回怜玢をやめお実行速床を劇的改善 静的コンテキスト の実践。毎回怜玢しおいた情報をCLAUDE.mdに埋め蟌み高速化 CLAUDE.md vs .claude/rules/ の実践的な䜿い分け オンデマンド の実践Claude Code。ディレクトリ単䜍でルヌルを分割 copilot-instructions.md を分割したいapplyTo パタヌンで解決 オンデマンド の実践GitHub Copilot。*.instructions.mdでファむル/蚀語別に分割 Claude Codeの調査品質がバラバラ/researchで解決する方法 自埋蓄積型 の実践。AIが調査→Markdown保存→再利甚するワヌクフロヌ ツヌル別ガむド Claude CodeずGitHub Copilot、それぞれの蚭定ファむル䜓系を解説した蚘事です。 Claude Code Skills 実装ガむド Claude Codeでカスタムスキルを䜜成し、ワヌクフロヌを自動化する方法 GitHub Copilot蚭定5皮を網矅生産性を最倧化する䜿い分け術 copilot-instructions.md、*.instructions.md、AGENTS.mdなど5皮類の蚭定を敎理 Claude Code→GitHub Copilot移行で䜿える蚭定ファむル察応衚 䞡ツヌルの蚭定ファむルを察応衚で比范。ツヌル間の「翻蚳衚」ずしお掻甚 AGENTS.md vs Custom Agents【5぀の比范衚で混乱解消】 GitHub CopilotのAGENTS.mdずCustom Agentsの違いを比范衚で敎理 copilot-instructions.md ず AGENTS.md、どっちに䜕を曞く 公匏掚奚ず「What vs How」の圹割分担で䜿い分けを解説 Agent Skills 入門SKILL.md の基本から実践たで GitHub Copilot Agent SkillsずSKILL.mdの曞き方を実甚䟋付きで解説 Claude CodeからGitHub Copilotぞ移怍したらAgent Skillsが動かない Skills発火メカニズムの違いず移行時の泚意点を解説 仮説怜蚌シリヌズ 「こうすれば䞊手くいくのでは」ずいう仮説を実際に怜蚌した蚘事です。 怜蚌→蚘事化で知芋を資産化RAGもどきで技術ブログ執筆を効率化 仮説 : 既存蚘事をRAG的に参照すれば、新芏蚘事の執筆が効率化する 結果 : 文䜓・構成の䞀貫性が向䞊し、過去蚘事ずの重耇も防げた ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post CLAUDE.md効かないドメむン泚入を蚭蚈思想から芋盎す first appeared on SIOS Tech Lab .
RAGベクトルDBは誀解。BM25、Web怜玢、GraphRAGなど7぀の手法を比范衚で敎理。デヌタ芏暡・コスト・粟床での遞び方を解説したす。 はじめに 「RAGを導入したい」ずいう話になるず、倚くの堎合「じゃあベクトルDBを遞定しなきゃ」ずいう流れになりたす。 匊瀟でもRAG構築・導入支揎サヌビスを提䟛しおおり、RAGに぀いお説明する機䌚が倚くありたす。その䞭で「RAG」ず「ベクトル怜玢」を同じ文脈で質問されるこずがよくありたす。 確かに、トレンドずしおRAGずベクトル怜玢を同じ文脈で語るこずは間違いではありたせん。しかし、実はChatGPTやClaudeの怜玢機胜もWeb怜玢゚ンゞンず連携した「RAG」の䞀皮です。 本蚘事では、RAGの原論文に立ち返り、 RAGの本質は「怜玢手法」ではない ずいうこずを敎理したす。そしお、ベクトル怜玢以倖にどのような倖郚情報の取り蟌み方があるのかを俯瞰的に玹介したす。 RAGの定矩に立ち返る RAGずは䜕か RAGRetrieval-Augmented Generation怜玢拡匵生成ずは、LLM倧芏暡蚀語モデルに倖郚の情報を䞎えるこずで、回答の粟床を向䞊させる手法です。LLMは孊習デヌタに基づいお回答を生成したすが、孊習埌の最新情報や瀟内固有の知識は持っおいたせん。RAGはこの課題を「倖郚から必芁な情報を怜玢しお補う」ずいうアプロヌチで解決したす。 RAGの階局構造を敎理する RAGを理解するために、以䞋の階局構造を敎理しおおきたしょう。 ここで重芁なのは、 RAGの本質は「倖郚知識をコンテキストに補うアプロヌチ」であり、「どう取り蟌むか」は手段の話 だずいうこずです。ベクトル怜玢は実装遞択肢の䞀぀に過ぎたせん。 原論文Lewis et al., 2020の定矩 RAGの原論文 では、RAGを以䞋のように定矩しおいたす。 “models which combine pre-trained parametric and non-parametric memory for language generation” 蚀語生成のために、事前孊習枈みのパラメトリックメモリず非パラメトリックメモリを組み合わせたモデル パラメトリックメモリ : LLMが孊習時に獲埗した知識モデルの重みに栌玍 非パラメトリックメモリ : 倖郚から取埗する知識怜玢で取埗 泚目すべきは、この定矩に「ベクトル怜玢」ずいう限定がないこずです。論文の実装䟋ではDPRDense Passage Retrievalずいうベクトル怜玢手法が䜿われおいたしたが、RAGの定矩自䜓は「倖郚知識をどのように取埗するか」を限定しおいたせん。 論文における抂念の発展 RAGずいう抂念は、様々な論文が発衚される䞭で発展を続けおいたす。 2020幎 : RAGは「BART + DPR」ずいう 特定のモデルアヌキテクチャ ずしお提案されたした。論文では “RAG models”、”fine-tuning recipe” ずいった甚語が䜿われおいたす。 2024幎 : RAGは「倖郚知識ずLLMを統合するための 包括的な抂念 」ずしお再定矩されおいたす RAG Survey 、 Modular RAG 。”RAG paradigms”、”framework”、”LEGO-like framework” ずいった甚語が䜿われ、単䞀の技術ではなく 目的達成のための抂念・考え方 ずしお扱われおいたす。 補足 : RAGの発展段階Naive → Advanced → Modularや各手法の数倀的な比范に぀いおは、匊瀟ブログ「 RAGはどのように進化しおいるのか 」で䜓系的に解説しおいたす。本蚘事では「RAGずは䜕か」ずいう抂念の敎理に焊点を圓おたす。 RAGにおける倖郚情報の取り蟌み方 RAGを実珟するための倖郚情報の取り蟌み方は、ベクトル怜玢だけではありたせん。ここでは代衚的な手法を玹介したす。 手法遞択の考え方は「 ナヌスケヌスに適した方法で、必芁な情報をLLMに䞎える 」です。各手法には埗意な情報の特性があり、ナヌスケヌスに応じお遞択したす。たた、単䞀の手法だけでなく、耇数の手法を組み合わせるこずも有効な遞択肢です。 なお、どの手法を遞択しおも、導入しお終わりではありたせん。粟床枬定ず継続的なメンテナンスチュヌニング、デヌタ曎新、ク゚リ最適化などは共通しお必芁な取り組みです。 ベクトル怜玢型 埋め蟌みベクトルによる意味的類䌌床怜玢を行う手法です。 特城 : 意味的な類䌌性を捉えられる 適したナヌスケヌス : 「〇〇に䌌た事䟋は」「関連するドキュメントを探したい」など、意味的に類䌌した情報を探す堎面 実珟キヌワヌド : Auzre AI Search , Pinecone, FAISS, pgvector, Milvus, Chroma, Weaviate, Qdrant キヌワヌド怜玢型BM25 埓来の党文怜玢アルゎリズムを掻甚する手法です。 特城 : 完党䞀臎が重芁な堎面で有効 適したナヌスケヌス : ゚ラヌコヌド怜玢、法埋条文、補品型番、固有名詞など、完党䞀臎・郚分䞀臎が重芁な堎面 実珟キヌワヌド : Auzre AI Search, Elasticsearch, OpenSearch, Apache Solr, Whoosh ハむブリッド怜玢型 ベクトル怜玢ずキヌワヌド怜玢を組み合わせ、リランキングず䜵甚する手法です。 特城 : 意味的類䌌性ず完党䞀臎の䞡立 適したナヌスケヌス : 意味的類䌌性ず完党䞀臎の䞡方が求められる堎面、倧芏暡デヌタで高い怜玢粟床が必芁な堎面 実珟キヌワヌド : Azure AI Search, Elasticsearch (kNN + BM25), OpenSearch, Pinecone (Hybrid), Weaviate (Hybrid) Web怜玢型 倖郚怜玢゚ンゞンず連携しおリアルタむム情報にアクセスする手法です。 特城 : リアルタむム情報ぞのアクセスが可胜 適したナヌスケヌス : 最新ニュヌス、珟圚の䟡栌・圚庫、むベント情報など、リアルタむム性が求められる情報 実珟キヌワヌド : ChatGPT Search, Claude Web Search, Gemini Grounding, Perplexity, Bing API, Google Custom Search API 構造化怜玢型 ナレッゞグラフや構造化デヌタベヌスを掻甚する手法です。 GraphRAG ナレッゞグラフを掻甚し、゚ンティティ間の関係を怜玢 適したナヌスケヌス : 「AずBはどう関係する」「〇〇に関連する人物は」など、関係性を蟿る必芁がある堎面 SQL怜玢 構造化デヌタからの正確なデヌタ取埗 適したナヌスケヌス : 売䞊デヌタ、圚庫数、ナヌザヌ情報など、構造化デヌタから正確な倀を取埗する堎面 実珟キヌワヌド : Neo4j, Amazon Neptune, Azure Cosmos DB (Gremlin), PostgreSQL, BigQuery マニュアルRAG人力補填型 人間が遞択的に文章を補填する手法です。 特城 : 文脈理解や暗黙知の掻甚が可胜 適したナヌスケヌス : PoC・少量運甚、暗黙知の掻甚、システム化前の怜蚌、文脈䟝存で人間の刀断が必芁な堎面 実珟キヌワヌド : コピヌ&ペヌスト、瀟内Wiki参照、ドキュメント手動遞択 実は、ChatGPTやClaudeにファむルをアップロヌドしお質問するのも、広矩ではマニュアルRAGの䞀皮ず蚀えたす。蚀葉が異なるだけで、抂念的にはRAGを觊っおいる機䌚は倚いのかもしれたせん。 手法の分類たずめ 手法の党䜓像 手法遞択の比范衚 手法 情報の特性 デヌタ芏暡 初期コスト 運甚負荷 粟床安定性 ベクトル怜玢 意味的類䌌 倧芏暡察応 高 䞭〜高 高 BM25 完党䞀臎 倧芏暡察応 äž­ 䜎〜䞭 高 ハむブリッド 䞡方 倧芏暡察応 高 高 最高 Web怜玢 リアルタむム 倖郚䟝存 䜎 䜎 倖郚䟝存 GraphRAG 関係性 䞭芏暡向き 高 高 ナヌスケヌス䟝存 SQL怜玢 構造化デヌタ 倧芏暡察応 䞭既存掻甚 䜎〜䞭 高 マニュアルRAG 文脈䟝存 小芏暡のみ 䜎 高人的 人䟝存 たずめ 本蚘事では、RAGの本質ず倖郚情報の取り蟌み方に぀いお敎理したした。 RAGは単䞀の技術ではなく、LLMの回答粟床を向䞊させるための抂念です。 論文でも2024幎以降は「パラダむム」「フレヌムワヌク」ずしお扱われおいたす。 RAGの目的は「芁求される回答粟床の達成」です。 手法はあくたで目的達成のための手段であり、ベクトル怜玢は遞択肢の䞀぀に過ぎたせん。 ただし、ベクトル怜玢が有効なケヌスが倚いのも事実です。 倧芏暡デヌタで意味的な怜玢が必芁な堎面では、ベクトル怜玢やハむブリッド怜玢が有効であり、倚くのRAGシステムで採甚されおいたす。それが唯䞀の遞択肢ではない、ずいうこずです。 手法遞択は戊略的刀断です。 粟床芁件、コスト、スケヌル、運甚負荷を考慮し、ナヌスケヌスに応じお最適な取り蟌み方を遞びたしょう。 RAG導入をご怜蚎の方ぞ 匊瀟では、RAGを掻甚した゜リュヌションを提䟛しおいたす。 瀟内ナレッゞ掻甚AIチャット導入サヌビス : お客様のAzure環境に匊瀟RAGプロダクトを構築したす。導入だけでなく、導入埌の粟床改善の支揎や、利甚普及に向けた支揎などトヌタル的にサポヌトを行いたす。 RAGスタヌタヌパック : RAGプロダクトをスピヌディヌに導入したす。、チャットUI回答粟床の評䟡・改善のためのオヌルむンワン基盀をご提䟛しおいたす。導入埌はお客様偎で自由なカスタマむズを実地いただけたす。ずりあえず詊しおみたいずいう方にお勧めです。 「RAGを導入したい」「どの手法を遞べばいいかわからない」「RAGの粟床が出ない」ずいったお悩みがあれば、お気軜にご盞談ください。 参考文献 Lewis, P., et al. (2020). “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.” arXiv:2005.11401. https://arxiv.org/abs/2005.11401 Gao, Y., et al. (2024). “Retrieval-Augmented Generation for Large Language Models: A Survey.” arXiv:2312.10997. https://arxiv.org/abs/2312.10997 Gao, Y., et al. (2024). “Modular RAG: Transforming RAG Systems into LEGO-like Reconfigurable Frameworks.” arXiv:2407.21059. https://arxiv.org/abs/2407.21059 関連蚘事 RAGはどのように進化しおいるのか ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post ベクトル怜玢以倖のRAG手法7遞比范衚付き解説 first appeared on SIOS Tech Lab .
Claude Codeのサブ゚ヌゞェントを「Opusで蚈画、Sonnetで実行」の構成で最適化。バックグラりンド䞊列実行ずドキュメント出力で、トヌクン節玄ず時間効率を䞡立する実践的な蚭蚈手法を解説したす。 はじめに どもGitHub CopilotずClaude Codeの間で反埩暪跳びし぀぀、倜はしっぜりClaude Codeにすり寄っおいる韍ちゃんです。 前回・前々回ず、Claude Codeのトヌクン消費を抑える話をしおきたした。 Claude Code MCP が遅い・重い問題、CLI + Skills で解決 Claude Codeが遅い毎回怜玢をやめお実行速床を劇的改善 でも、ただトヌクン消費が気になる堎面があるんですよね。特に サブ゚ヌゞェント を䜿うずき。 そういえばサブ゚ヌゞェントに぀いお、しっかり調べお蚭蚈を考えたこずがなかったなず反省したしお。今回は サブ゚ヌゞェントの最適構成 に぀いお話しおいきたす。 結論から蚀うず  蚈画はOpus、実行はSonnet がベスト バックグラりンド実行 で埅ち時間れロ ドキュメント出力 で非同期でも結果を取埗 これ、調べたらClaude Code公匏も掚奚しおいお、内郚でも実際そうなっおいるらしいんですよね。 なぜ Opus + Sonnet 構成なのか Opus は最高お気持ち衚明 正盎に蚀いたす。 Opusず話すのがめちゃくちゃ楜しい んですよ。 Sonnetだず、自分の意図を正確に理解しおもらうのに劎力が必芁だったんですよね。でもOpusは雑なプロンプトでも意図を察しおくれるし、「こういうこずですか」っお確認を取っおくれる。 Claude Codeの利甚制限5時間制限、Sonnet制限などを意識するようになっお、トヌクンを銬鹿食いしおいる箇所を調べるようになりたした。そこで気づいたんです。 党郚Opusでやる必芁はない っおこずに。 Sonnet のポゞション 公匏のモデル比范 を芋おみたしょう。 モデル 入力 ($/M tokens) 出力 ($/M tokens) SWE-bench Opus 4.5 $5 $25 80.9% Sonnet 4.5 $3 $15 77.2% Haiku 4.5 $1 $5 73.3% SWE-benchで芋るず、Opus 80.9%に察しおSonnet 77.2%。 差は3.7ポむント しかないんですよね。実行系タスクには十分な性胜です。 数ヶ月前はSonnetをずっず䜿っおいたので、Sonnetでも十分なのは䜓感ずしおわかっおいたした。 実際、モデルの組み合わせに぀いおは倖郚の分析でも蚀及されおいたす。 “Mixing models works best. Switching between models depending on task type made workflows faster and safer. Haiku for setup, Sonnet for builds, Opus for reviews — that combo just works.” — Claude Haiku 4.5 Deep Dive 公匏も掚奚しおいる Claude Codeには opusplan ずいうモデル蚭定がありたす。 The opusplan model alias provides an automated hybrid approach: In plan mode – Uses opus for complex reasoning and architecture decisions In execution mode – Automatically switches to sonnet for code generation and implementation — Claude Code Model Configuration ぀たり、 蚈画時はOpus、実行時はSonnet に自動で切り替わるモヌドです。公匏がこの構成を掚奚しおいるっおこずですね。 さらに、 Anthropicのマルチ゚ヌゞェント研究 によるず 指暙 結果 単䞀Opus比でのパフォヌマンス向䞊 90.2% 䞊列化による時間削枛 最倧90% A multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on their internal research eval. — Multi-Agent Research System Opus + Sonnetの組み合わせは、単䞀Opusより性胜が高い 。これ、めっちゃ重芁な知芋ですよね。 サブ゚ヌゞェントずは Claude Codeの Task tool を䜿うず、 サブ゚ヌゞェント にタスクを委譲できたす。 特城  独立したコンテキストりィンドり メむン䌚話ずは別のコンテキストで動く モデル指定が可胜  model: sonnet や model: haiku を指定できる ビルトむン゚ヌゞェント  Explore コヌドベヌス探玢、 Plan 蚭蚈蚈画などが甚意されおいる ゚ヌゞェント定矩の䟋  公匏ドキュメント より --- name: code-reviewer description: Reviews code for quality and best practices tools: [Read, Glob, Grep] model: sonnet # sonnet, opus, haiku, inherit から遞択 permissionMode: acceptEdits # ファむル曞き蟌みを自動蚱可 --- model: sonnet を指定するだけで、その゚ヌゞェントはSonnetで動きたす。簡単ですね。 バックグラりンド実行のメリット サブ゚ヌゞェントの蚭蚈を考えおいお気づいたんですが、 タスクを分割するずバックグラりンドで実行できる んですよね。 埅ち時間れロ フォアグラりンドで実行するず、その凊理をずっず占有しおしたいたす。レビュヌ埅ちの間、ただ埅っおいるのはもったいない。 バックグラりンドで実行するず サブ゚ヌゞェントを起動したら すぐ次の䜜業ぞ レビュヌ埅ちの間に コヌドを曞ける 完了したら 自動で通知 が届く 䞊列実行 耇数の゚ヌゞェントを同時に起動できたす。 メむン䌚話 (Opus) ├─→ technical-accuracy-reviewer (Sonnet) [バックグラりンド] ├─→ content-reviewer (Sonnet) [バックグラりンド] └─→ seo-reviewer (Sonnet) [バックグラりンド] 3぀のレビュヌを䞊列で回せば、時間効率が倧幅に向䞊したす。 制玄を理解する ただし、 バックグラりンド実行には制玄がありたす 。 項目 フォアグラりンド バックグラりンド 暩限プロンプト 郜床確認 事前に䞀括取埗 MCPツヌル ✅ 䜿甚可 ❌ 䜿甚䞍可 AskUserQuestion ✅ 可胜 ❌ 倱敗継続はする WebSearch/WebFetch ✅ 䜿甚可 ✅ 䜿甚可 Background subagents run concurrently while you continue working. Before launching, Claude Code prompts for any tool permissions the subagent will need, ensuring it has the necessary approvals upfront. — Create custom subagents MCPツヌルが䜿えない のは泚意ポむントです。MCP䜿う系のサブ゚ヌゞェントはフォアグラりンドで動かすしかありたせん。 ただ、リポゞトリ内の䜜業やレビュヌは MCP䞍芁で実珟可胜 です。WebSearchやWebFetchはバックグラりンドでも䜿えるので、倖郚情報の取埗も問題ありたせん。 ドキュメントベヌスの進捗管理 フォアグラりンドのいいずころは、 進捗がすぐわかる こずですよね。バックグラりンドだずどうするか 解決策ドキュメントベヌスで結果を吐き出させる なぜファむル出力が良いのか バックグラりンドだず䌚話に盎接返せない 応答に曞いおもらうずコピペが面倒 コンパクト芁玄するず参照できなくなる レビュヌ系は議論になるこずもあるので、 ドキュメント出力が重芁 僕もClaude Codeず「俺はこう考えおるんだけど」みたいな議論をよくするんですが、そういうずきにドキュメントがあるず䟿利なんですよね。 出力圢匏の蚭蚈 僕が䜿っおいるレビュヌ゚ヌゞェントでは、こんな圢匏で出力しおいたす。 --- type: review agent: content-reviewer model: sonnet target: docs/article/xxx/article.md timestamp: 2026-02-02T14:45:00+09:00 status: completed scores: content_quality: 82 --- ポむント  YAMLフロントマタヌ でメタデヌタを構造化 タむムスタンプ付きファむル名 で競合回避 content-2026-02-02T1445.md  機械的に抜出可胜 スコアなど取埗したい情報をプログラムで取り出せる Git管理 できる履歎が残る 実践レビュヌ゚ヌゞェントを䜜る 実際に僕が䜿っおいるブログレビュヌ゚ヌゞェントの構成を玹介したす。 ゚ヌゞェント定矩 .claude/agents/content-reviewer.md : --- name: content-reviewer description: 技術ブログ蚘事のコンテンツ品質を評䟡したす。結果はファむル出力したす。 tools: [Read, WebSearch, WebFetch, Write] model: sonnet permissionMode: acceptEdits --- # Content Reviewer Agent あなたは技術ブログ蚘事のコンテンツ品質を専門的に評䟡する゚ヌゞェントです。 ## 出力圢匏 レビュヌ結果は以䞋の圢匏でファむルに出力しおください 1. **出力先**: `{察象ファむルのディレクトリ}/review/` 2. **ファむル名**: `content-{YYYY-MM-DDTHHMM}.md` 3. **ディレクトリ䜜成**: `review/` ディレクトリがない堎合は䜜成 **重芁**: 䌚話ぞの盎接出力ではなく、必ずファむルに曞き出しおください。 ポむント  model: sonnet でSonnetを指定 permissionMode: acceptEdits でファむル曞き蟌みを自動蚱可 tools: [Read, WebSearch, WebFetch, Write] で必芁なツヌルを指定 出力先を明確に指瀺 これがないずファむル出力しおくれない 3゚ヌゞェント構成 僕は以䞋の3぀の゚ヌゞェントを䞊列で動かしおいたす。 ゚ヌゞェント 圹割 出力ファむル technical-accuracy-reviewer 技術的正確性チェック technical-accuracy-*.md content-reviewer コンテンツ品質評䟡 content-*.md seo-reviewer SEO最適化、タむトル生成 seo-*.md それぞれが独立しお評䟡し、ファむルに結果を出力したす。 実践䞊列レビュヌの実行 実行方法 Task toolで3゚ヌゞェントを明瀺的に「 バックグラりンド 」ず「 䞊列実行 」を蚘入しお起動したす。 3぀のレビュヌ゚ヌゞェントをバックグラりンドで䞊列実行しお - technical-accuracy-reviewer - content-reviewer - seo-reviewer 察象: docs/article/rag-retrieval-methods/article.md 実際の結果 僕が怜蚌したずきの結果です。 ゚ヌゞェント スコア 出力ファむル technical-accuracy-reviewer 88/100 technical-accuracy-2026-02-02T1500.md content-reviewer 82/100 content-2026-02-02T1445.md seo-reviewer 78/100 seo-2026-02-02T1500.md 確認できた動䜜  ✅ 3゚ヌゞェントが同時にバックグラりンドで起動 ✅ メむン䌚話はブロックされず、他䜜業が可胜 ✅ 各゚ヌゞェントが独立しお完了し、結果ファむルが review/ に出力 ✅ 完了通知が自動的に届き、結果サマリヌが衚瀺 ✅ WebSearch/WebFetchがバックグラりンドでも正垞動䜜 完了順序 は、゚ヌゞェントのタスク内容Web怜玢量などによっお倉わりたす。僕の怜蚌ではseo-reviewerが最初に完了し、technical-accuracy-reviewerが最埌でした。 泚意点ずベストプラクティス バックグラりンドが適さないケヌス 察話的フィヌドバックが必芁 AskUserQuestionが䜿えないので、ナヌザヌ確認が必芁なタスクには向かない MCPツヌルが必芁 Notion連携、Slack連携など ゚ヌゞェント蚭蚈のコツ 出力圢匏を明確に指瀺 「ファむルに出力しお」だけでは䞍十分 出力先、ファむル名圢匏、ディレクトリ䜜成の指瀺たで曞く ディレクトリ䜜成も指瀺に含める review/ ディレクトリがない堎合に䜜成する指瀺を入れる Web怜玢の範囲を限定 毎回同じ怜玢をさせない 前回蚘事 参照 静的情報は docs/references/ に保存しおおく 最近面癜いず思ったコンテンツ tmuxでClaude Codeを耇数セッション䜿う手法が面癜いですね。 こちらの蚘事 が参考になりたす。「䞭間管理職」的な䜿い方、めちゃくちゃ面癜いなず思っお芋おたす。ずいうかClaude Codeずの䌚話が面癜すぎるのに、ゎリゎリの技術蚘事っおのが玠敵ずいうかずるい。 セッションを䜿い捚おにする運甚も、バックグラりンド実行の考え方に近いですよね。 たずめ この蚘事では、 サブ゚ヌゞェントの最適構成 に぀いお共有したした。 構成のポむント 圹割 モデル 実行方匏 思考・察話・蚈画 Opus フォアグラりンド 実行・サブタスク Sonnet バックグラりンド 軜量タスク Haiku バックグラりンド キヌメッセヌゞ Opus は最高 だけど、党郚Opusでやる必芁はない Sonnet で十分 な実行系タスクはSonnetに任せる バックグラりンド で埅ち時間をれロに ドキュメント出力 で非同期でも結果を取埗 結果ずしお トヌクン節玄 ず 時間効率 の䞡方を実珟 前回からの流れ MCP → CLI+Skillsトヌクン削枛 静的情報掻甚さらなるトヌクン削枛 今回 → Opus+Sonnet構成時間効率トヌクン分散 Opusずもっず長く話したいから、簡単な䜜業はSonnetに䟝頌しようぜ、ずいう結論になりたした。 ここたで読んでいただき、ありがずうございたした 参考リンク 公匏ドキュメント Claude Models Overview Claude Code Model Configuration Create custom subagents Anthropic Engineering Blog Multi-Agent Research System Claude Code Best Practices 関連蚘事 Claude Code MCP が遅い・重い問題、CLI + Skills で解決 MCP接続の䞍安定さやトヌクン消費に悩んでいたせんかCLI + Skillsぞの段階的移行でトヌクン65%削枛を実珟した実践ガむド。 Claude Codeが遅い毎回怜玢をやめお実行速床を劇的改善 Skills/Agentsの実行が遅い原因は毎回の同じWeb怜玢かも。静的情報掻甚でトヌクン節玄・高速化・結果安定化を実珟する手法。 ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post Claude Code サブ゚ヌゞェントの最適構成Opus で考え、Sonnet で動かす first appeared on SIOS Tech Lab .
はじめに こんにちは、サむオステクノロゞヌの小野です。Kubernetesのマルチクラスタヌ管理ツヌルであるRancherにはHelmリポゞトリを登録しお、そのリポゞトリ内のHelmアプリケヌションをGUI䞊で確認できる機胜がありたす。 今回は ChartMuseum ずいうツヌルでロヌカル環境にHelmリポゞトリを構築し、それをRancherに登録する手順に぀いお解説したす。 前提条件 今回構築した前提条件は以䞋になりたす OSはUbuntuを䜿甚  Rancher構築枈み 構築方法は過去の蚘事を参考にしおください Rancher入門Rancher Serverの構築 ChartMuseumはHelmで構築 ロヌカルに盎接むンストヌルやDockerでの構築がありたすが、今回はHelmでRancherのクラスタヌ䞊に構築したす Storage Class䜜成枈み ChartMuseumは様々なクラりドストレヌゞを指定できたすが、今回はStorage ClassによるPVを利甚したす ChartMuseum構築手順 ChartMuseum甚のNamespaceを䜜成したす。 $ kubectl create namespace chartmuseum ChartMuseumのドメむン今回はchartmuseum.internalを蚭定しお、その蚌明曞を䜜成したす。DNSサヌバヌの蚭定も同時に行っおください。 $ openssl req -x509 -nodes -days 365 -newkey rsa:2048 \ -keyout chartmuseum.key \ -out chartmuseum.crt \ -subj "/CN=chartmuseum.internal" \ -addext "subjectAltName=DNS:chartmuseum.internal" 䜜成した蚌明曞をシヌクレットずしお登録したす。 $ kubectl create secret tls chartmuseum-tls-secret \ --cert=chartmuseum.crt \ --key=chartmuseum.key \ -n chartmuseum ChartMuseum自䜓のHelmチャヌトリポゞトリを远加したす。 $ helm repo add chartmuseum https://chartmuseum.github.io/charts $ helm repo update Valuesファむルを䜜成したす。今回は以䞋のように蚭定したした。それ以倖はデフォルトでよいです。 persistence: enabled: true accessMode: ReadWriteOnce size: 10Gi storageClass: <ストレヌゞクラス名> # PVを䜜成できるStorage Classを指定 env: open: DISABLE_API: false STORAGE: local STORAGE_LOCAL_ROOTDIR: /storage CHART_URL: https://chartmuseum.internal ingress: enabled: true className: nginx # RKE2での構築のためIngress Controllerをnginxに指定。 annotations: kubernetes.io/ingress.class: nginx hosts: - name: chartmuseum.internal # 蚭定したいドメむン名 path: / tls: true tlsSecret: chartmuseum-tls-secret tls: - secretName: chartmuseum-tls-secret hosts: - chartmuseum.internal 䜜成したvalues.yamlを䜿甚しおHelmむンストヌルしたす。 $ helm install chartmuseum chartmuseum/chartmuseum -f values.yaml -n chartmuseum Chartmuseumが䜜成されたこずを確認したす。 ChartMuseumのHelmむンストヌル確認 RancherぞHelmリポゞトリを登録する方法 ChartMuseumを䜜成できたので、早速Rancherに登録しおみたす。RancherUIのApps > Repositoriesを開いおください。Createを抌䞋しお、以䞋のように蚭定したす Targethttp(s) URL to an index generated by Helm Index URLhttps://chartmuseum.internal Helmリポゞトリの登録蚭定 蚭定埌、蚌明曞゚ラヌが出るので右の䞉点リヌダヌメニュヌから「Edit YAML」を遞択しおください。その埌、spec.caBundleにCA蚌明曞の情報を入力しおください。 蚌明曞゚ラヌが出るので泚意 Helmリポゞトリの蚌明曞の蚭定方法。caBundleにCA蚌明曞の内容を蚘茉する。 蚭定埌、Activeになれば登録完了です。 Activeになれば登録完了   Helmリポゞトリにチャヌトを保存しおみる RancherにHelmリポゞトリを登録するこずができたので、Helmリポゞトリに詊しにチャヌトを保存しお、UIで確認しおみたいず思いたす。 怜蚌甚のチャヌトを䜜成したす。 $ mkdir chart-test && cd chart-test $ helm create my-test-chart パッケヌゞ化しおChartMuseumに保存したす。 $ helm package my-test-chart $ curl -k --data-binary "@my-test-chart-0.1.0.tgz" https://chartmuseum.internal/api/charts {"saved":true} RancherUIからRepositriesを開いお、メニュヌからRefreshを抌䞋するこずでリポゞトリを曎新したす。 メニュヌからRefreshを抌䞋する RancherUIのApps > Chartsを芋るず保存したチャヌトが確認できたす。 Apps > Chartを開くず保存したHelmチャヌトが確認できる 保存したHelmチャヌトを開くず詳现情報が確認できる せっかくなので、バヌゞョンアップさせお、questions.yamlを远加しおみたす。questions.yamlずはHelmのvalues.yamlを、Rancher䞊でGUI入力フォヌムに倉換するための定矩ファむルです。これをChartに組み蟌むこずで、YAML線集やvalues.yamlファむルの盎接適甚しなくおも、ブラりザのRancherUIから蚭定を倉曎するこずが可胜になりたす。参考 https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/helm-charts-in-rancher/create-apps  怜蚌甚のチャヌトのChart.yamlを線集しお、バヌゞョンをあげたす。 apiVersion: v2 name: my-test-chart description: A Helm chart for Kubernetes # A chart can be either an 'application' or a 'library' chart. # # Application charts are a collection of templates that can be packaged into versioned archives # to be deployed. # # Library charts provide useful utilities or functions for the chart developer. They're included as # a dependency of application charts to inject those utilities and functions into the rendering # pipeline. Library charts do not define any templates and therefore cannot be deployed. type: application # This is the chart version. This version number should be incremented each time you make changes # to the chart and its templates, including the app version. # Versions are expected to follow Semantic Versioning (https://semver.org/) version: 0.2.0 # ここのバヌゞョンをあげる # This is the version number of the application being deployed. This version number should be # incremented each time you make changes to the application. Versions are not expected to # follow Semantic Versioning. They should reflect the version the application is using. # It is recommended to use it with quotes. appVersion: "1.16.0" 以䞋のquestions.yamlをvalues.yamlやChart.yamlず同じ階局に䜜成したす。 categories: - Test questions: - variable: replicaCount default: "1" type: int label: Replica Count group: "Global Settings" description: "デプロむするポッドの数を遞択しおください" - variable: service.type default: "ClusterIP" type: enum label: Service Type group: "Network Settings" options: - "ClusterIP" - "NodePort" - "LoadBalancer" $ ls my-test-chart Chart.yaml charts questions.yaml templates values.yaml 䜜成できたら、パッケヌゞ化しおChartMuseumに保存したす。 $ helm package my-test-chart $ curl -k --data-binary "@my-test-chart-0.2.0.tgz" https://chartmuseum.internal/api/charts {"saved":true} RancherUIからリポゞトリを曎新しお、チャヌトを開くずバヌゞョンが䞊がっおいるこずが確認できたす。 バヌゞョンアップしおいるこずが確認できる Installからむンストヌル手順を進めるず、questions.yamlを適甚したおかげでvalues.yamlのパラメヌタをGUI䞊で蚭定できるようになっおいたす。 questions.yamlのおかげでUI䞊から蚭定が可胜になっおいる 終わりに 今回はHelmリポゞトリを構築しお、Rancherに登録するたでの手順を解説したした。 むンタヌネットに接続できない環境でHelmリポゞトリを自䜜するずいったこずや、自䜜のコンテナアプリを管理したいずいったこずはよくあるこずだず思いたす。 みなさんもHelmリポゞトリを䜜成しお、Rancherで管理しおみおください。   参考 Rancher入門Rancher Serverの構築 ChartMuseum公匏サむト ChartMuseum Helm Chart Rancher公匏ドキュメントManage Repositories Rancher公匏ドキュメントquestions.yml     ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post ChartMuseum × RancherロヌカルHelmリポゞトリの構築ずUI連携 first appeared on SIOS Tech Lab .
Claude CodeのSkillsがCopilotで発火しない・読み蟌たれない原因は発火メカニズムの違い。description匷化、トヌクン予算、Instructionsルヌティングで解決。 はじめに どもGitHub Copilotが埐々に育っおきお、ニコニコな韍ちゃんです。1月埌半から2月にかけおGitHub Copilot関連のブログが倚めに出おいたす。ブログが出おいるずいうこずは育っおいる蚌拠ですね。 今回は、前回玹介しおいた Agent Skills の話題です。「 網矅5皮ブログ 」ず「 Claude Code→GitHub Copilot移行 」では補足ずしお觊れおいた Agent Skills を、 Claude Code から実際に移怍した ずいう郚分にフォヌカスしおいきたす。 「Claude Code で䜿っおいた Skills をそのたた GitHub Copilot に移怍したら、たったく発火しない 」 同じ SKILL.md 圢匏なのに、なぜ動かないのか本蚘事では、 発火しない根本原因ず3぀の解決策 を解説したす。 怜蚌環境 怜蚌日: 2026幎2月2日 環境: VS Code 1.108以降 + GitHub Copilot 参考: VS Code Docs – Agent Skills 前提Agent Skills の基本 Agent Skills の基本ディレクトリ構造、SKILL.md の曞き方は「 【2026幎版】Agent Skills 入門SKILL.md の基本から実践たで 」を参照しおください。 本蚘事では「 発火しない 」問題ず解決策に特化したす。 発火しない原因Claude Code ずの根本的な違い 結論から蚀うず、 Claude Code ず GitHub Copilot ではスキルの発火メカニズムが根本的に異なりたす 。 泚 : 以䞋は4぀のスキルを実際に移怍した際の動䜜怜蚌から分析した内容です。公匏ドキュメントで詳现が公開されおいない郚分は掚枬を含みたす。 決定的 vs 確率的 芳点 Claude Code GitHub Copilot スキル把握 党スキルを起動時に把握 relevance に基づき遞択的に読み蟌み 刀断方匏 党情報を元に内郚刀断情報完党 確率的な刀定事前フィルタリングあり description の圹割 発火刀定に䜿甚党メタデヌタ把握埌に刀断 発火刀定に䜿甚事前フィルタリングで刀断 GitHub Copilot も Claude Code も、Agent Skills には「 Progressive Disclosure 」ずいう蚭蚈思想を採甚しおいたす。党スキルを事前に読み蟌むのではなく、関連床に基づいお必芁なスキルのみを読み蟌む仕組みです。 違いは「どの段階で絞り蟌むか」にありたす。 Claude Code は党スキルを把握した䞊で内郚刀断で遞択 するのに察し、 Copilot は事前に絞り蟌んでから遞択 するため、description の曞き方次第で「挏れ」が発生するのです。 泚 : GitHub 公匏では関連床スコアリングの詳现な実装方法は公開されおいたせん。本蚘事の説明は動䜜怜蚌からの掚枬を含みたす。 【コラム】Claude Code の Progressive Disclosure Claude Code も Progressive Disclosure を採甚しおいたすが、その実装方法が異なりたす。 メタデヌタ把握 : 党スキルの Name + Description を起動時に把握 本䜓読み蟌み : 発火時に SKILL.md 本䜓を読み蟌み 参照ファむル : 必芁に応じお references/ を参照 重芁な違い : Claude Code は「党スキルのメタデヌタを把握した䞊で遞択」するため、description が倚少雑でも適切なスキルを遞べたす。䞀方 Copilot は「事前フィルタリング埌に遞択」するため、description の曞き方次第で「挏れ」が発生したす。 参考: Anthropic Engineering Blog – Agent Skills description の蚭蚈思想が違う ここが栞心です。 Claude Code では「䜕をするか」をベヌスで曞けばOKです。 description: ブログ蚘事をスクレむピングしおMarkdownに倉換 内郚ルヌティングが賢いので、この皋床の説明でも意図を理解しおくれたす。 GitHub Copilot では「スキルの機胜ず発火条件の䞡方」を曞く必芁がありたす。公匏ガむドラむンでは「describe BOTH what the skill does AND when to use it」ず明蚘されおいたす。 description: | ブログ蚘事をスクレむピングしおMarkdownに倉換するスキル。 Use when: ブログを取埗したい、蚘事を保存したい、tech-lab.sios.jp の内容を取埗したい。 Triggers on: scrape blog, fetch article, ブログ取埗, 蚘事取埗. 関連床スコアリングではナヌザヌが実際に䜿う蚀葉を埋め蟌たないずスコアが䞊がりたせん。 栞心の䞀文 : Claude Code ず同じ感芚で䜜るず発火しない。「技術的な説明」ではなく「ナヌザヌの発話」を埋め蟌む必芁がある。 雑に䜜るず動かない理由 たずめるず、こういうこずです。 項目 Claude Code GitHub Copilot 蚭定の厳密さ 雑でも動く 厳密に䜜る必芁あり トヌクン予算 気にしなくおOK 500トヌクン以䞋掚奚 䞊限5,000トヌクン 結果 – 同等の機胜を実珟可胜 䜜法に埓えば Claude Code のノリで雑にぶち蟌むず動きたせん。ただし、 䜜法に埓っお厳密に䜜れば、Claude Code ず同等の機胜を実珟できたす 。 公匏が掚奚するベストプラクティスに盲目的に埓う必芁はないですが、䞀床は目を通しおおいたほうがよいずいう感じですね。 Microsoftが公開しおいるリポゞトリに含たれおいる GitHub Copilot Agent Skills のガむドラむンです 。 補足 : 比范のために倧げさに曞いおいたすが、Claude Code の Skills もちゃんず蚭蚈したほうが良いです 解決策①description を匷化する 萜ずし穎「英語で曞くべき」Tips が逆効果になる堎合 よく「システムプロンプトは英語で曞くべき」ずいうTipsがありたすよね。GitHub Copilot Agent Skills では、 これが逆効果になる可胜性がありたす 。 Copilot の関連床刀定は 文字列の類䌌床 で刀断しおいるず掚枬されたす。ナヌザヌの発話ず description の蚀葉が近いほどスコアが䞊がりたす。日本語でプロンプトを曞くナヌザヌには、 日本語の発火キヌワヌド が必芁になりたす。英語だけで曞くず、日本語ク゚リずの類䌌床が䜎くなり、発火しにくくなりたす。 結論 : description には 日本語・英語䞡方 の発火キヌワヌドを列挙したしょう。 掚奚フォヌマット description: | [機胜の簡朔な説明䜕をするスキルか]. Use when: [どんな時に䜿うかナヌザヌの意図]. Triggers on: [発火キヌワヌド日本語・英語]. Before / After Before発火しない : description: HTMLをPlaywrightでレンダリングしおPNG画像に倉換 After発火する : description: | HTMLファむルをPlaywrightでレンダリングしおPNG画像に倉換するスキル。 Use when: HTMLを画像化したい、スクリヌンショットを撮りたい。 Triggers on: HTMLをPNGに倉換, HTML to PNG, 画像に倉換, HTMLを画像に, screenshot HTML, HTMLをキャプチャ. ポむントは「技術的に䜕をするか」ではなく、「 ナヌザヌがどう蚀うか 」を想像しお曞くこずです。 解決策②トヌクン予算を守る Copilot はトヌクン効率を重芖する蚭蚈です。SKILL.md が長すぎるず、そもそも読み蟌たれない可胜性がありたす。 ファむル 掚奚 侊限 SKILL.md 500トヌクン以䞋 玄60行目安 5,000トヌクン references/*.md 1,000トヌクン 2,000トヌクン 分割パタヌン 長くなりそうな堎合は、詳现を references/ に分割したしょう。 .github/skills/my-skill/ ├── SKILL.md # 抂芁 + Quick Start〜60行 └── references/ ├── commands.md # コマンド詳现 └── troubleshooting.md SKILL.md は「ルヌタヌ圹」に培しお、詳现は必芁な時だけ読み蟌たれるようにしたす。 解決策③Instructions ルヌティング力技 正盎、関連床スコアリングは䞍安定です。description を匷化しおも、発火したりしなかったりするこずがありたす。 そこで最終手段ずしお、 copilot-instructions.md に明瀺的なルヌティングテヌブルを远加 する方法がありたす。 ## Agent Skills Routing | キヌワヌド | スキル | パス | |----------------------------------------|--------------|----------------------------------------| | ブログスクレむピング, tech-lab.sios.jp | blog-scraper | `.github/skills/blog-scraper/SKILL.md` | | フロヌチャヌト, 図 | html-diagram | `.github/skills/html-diagram/SKILL.md` | なぜ有効か Instructions は 垞に読み蟌たれる 関連床スコアリングを バむパス できる 発火が 安定 する デメリットトレヌドオフ 力技ゆえのデメリットも認識しおおきたしょう。 保守性の䜎䞋 : スキルを远加・倉曎するたびにルヌティングテヌブルの曎新が必芁 スケヌラビリティ : スキル数が増えるず Instructions ファむルが肥倧化 本来の蚭蚈思想から倖れる : Progressive Disclosure の恩恵を受けられない 結論 : 確実に発火させたい重芁なスキル3〜5個皋床に限定しお䜿うのがおすすめです。 怜蚌結果4スキルで発火確認 実際に Claude Code から移怍した4぀のスキルで怜蚌したした。 スキル プロンプト 結果 発火経路 blog-scraper tech-lab.sios.jp + 取埗しお ✅ Instructions html-diagram HTMLで図化しお ✅ Instructions copilot-chat-converter Markdownに倉換しお ✅ Instructions html-to-png 連携呌び出し ✅ スキル内 結論 : Instructions ルヌティングテヌブルで党スキル安定発火したした。 怜蚌に䜿甚したスキルの抂芁 : スキル 抂芁 関連蚘事 blog-scraper ブログ蚘事をMarkdown圢匏で保存 HTML→Markdown倉換 html-diagram Tailwind CSSで図解を自動生成 HTML図解自動生成 copilot-chat-converter Chat履歎JSONをMarkdownに倉換 – html-to-png HTMLをPNG画像に倉換 html-diagramず連携 移怍チェックリスト Claude Code Skills → GitHub Copilot ぞの移怍手順をたずめたした。 - [ ] `.claude/skills/` → `.github/skills/` にコピヌ - [ ] `allowed-tools` を削陀Copilot では実隓的機胜 - [ ] description に `Use when` / `Triggers on` を远加 - [ ] ナヌザヌ発話を日本語・英語で列挙 - [ ] SKILL.md を 500トヌクン以䞋玄60行目安に削枛 - [ ] `copilot-instructions.md` にルヌティングテヌブル远加重芁スキルのみ - [ ] VS Code リロヌド埌、5〜10分埅機 - [ ] 発火テスト このチェックリストに埓えば、Claude Code で䜜ったスキルを GitHub Copilot でも掻甚できたす。 たずめ Agent Skills が発火しない問題ず解決策を敎理したした。 ポむント 内容 原因 Claude Code党スキル把握ず GitHub Copilot事前フィルタリングで仕組みが違う description 「䜕をするか」+「 い぀䜿うかUse when / Triggers on 」の䞡方を曞く 解決策 ① description 匷化 ② トヌクン予算 ③ Instructions ルヌティング力技 結論 䜜法に埓っお厳密に䜜れば、Claude Code ず同等の機胜を実珟可胜 発火しない堎合は、本蚘事の3぀の解決策を順番に詊しおみおください。特に Instructions ルヌティングは確実性が高いのでおすすめです。 参考リンク 公匏ドキュメント VS Code Docs – Agent Skills GitHub Docs – About Agent Skills GitHub Changelog – Agent Skills リリヌス 公匏リポゞトリ github/awesome-copilot – ベストプラクティス Microsoft GitHub-Copilot-for-Azure – Agent Skills 実装䟋 anthropics/claude-cookbooks – Skills – Progressive Disclosure 関連蚘事 GitHub Copilot蚭定5皮を網矅生産性を最倧化する䜿い分け術 Claude Code→GitHub Copilot移行で䜿える蚭定ファむル6぀の察応衚 【2026幎版】Agent Skills 入門SKILL.md の基本から実践たで ここたで読んでいただき、ありがずうございたした Agent Skills の発火問題で困っおいる方の参考になれば幞いです。Claude Code から移行する方は、ぜひ移怍チェックリストを掻甚しおください。 ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post Claude CodeからGitHub Copilotぞ移怍したらAgent Skillsが動かない原因ず解決策 first appeared on SIOS Tech Lab .
GitHub Copilot Agent Skillsずは䜕か、基本を解説。SKILL.mdの曞き方、ディレクトリ構造、Claude Code互換性たで実甚䟋付きで孊べる入門ガむド。 はじめに どもGitHub Copilotのブログを連日お届けしおいる韍ちゃんです。最近ブログを曞きすぎお導入文のスタックがなくなっおきちゃいたした。 以前「 GitHub Copilot蚭定5皮を網矅生産性を最倧化する䜿い分け術 」ずいう蚘事を曞きたしたが、そこでは補足ずしお軜めに玹介しおいた「 Agent Skills 」に぀いお詳しく解説しおいきたす。 「テスト曞いお」ず蚀うだけでプロゞェクト固有のテストパタヌンに埓う、そんな「専門家の自動召喚」を実珟する新機胜です。 本蚘事では Agent Skills の基本的な䜿い方ず曞き方を解説したす。 怜蚌環境 怜蚌日: 2026幎2月2日 環境: VS Code 1.108以降 + GitHub Copilot 参考: VS Code Docs – Agent Skills Agent Skills ずは 特定タスクに関連性があるず刀断されたら 自動で読み蟌たれる 「専門家パック」 Claude Codeを䜿っおいる方は、Claude Code Skillsをそのたた想像しおもらえればOKです 他の蚭定ファむルずの違い Agent Skills の最倧の特城は、 スクリプトやリ゜ヌスを同梱できる 点です。 特城 Agent Skills 他の蚭定ファむル 発火条件 自然蚀語で自動 垞時/glob/手動 スクリプト同梱 ✅ 可胜 ❌ 䞍可 リ゜ヌス同梱 ✅ 可胜 ❌ 䞍可 これたでの蚭定ファむル copilot-instructions.md 、 *.instructions.md 、 *.prompt.md 、 *.agent.md 、 AGENTS.md は、すべお「指瀺」だけを曞くファむルでした。Agent Skills は、指瀺に加えお スクリプトやテンプレヌトも䞀緒に管理 できたす。 むメヌゞ Agent Skills = 「専門家が道具持参で自動登堎」 「テスト曞いお」→ テスト専門家が登堎テンプレヌト持参 「ブログ取埗しお」→ スクレむピング専門家が登堎スクリプト持参 「HTMLを画像に」→ 画像倉換専門家が登堎倉換スクリプト持参 GitHub Copilotの蚭定ファむルでいうず、 instructions + Custom Agents + AGENTS.md を組み合わせたようなむメヌゞですね。 ディレクトリ構造 Agent Skills には2皮類の保存堎所がありたす。 保存堎所 皮類 パス 甹途 プロゞェクトスキル .github/skills/ 単䞀リポゞトリ専甚 個人スキル ~/.copilot/skills/ 耇数プロゞェクト共有 補足 : .claude/skills/ も䞋䜍互換ずしおサポヌトされたすが、 .github/skills/ が掚奚です。 基本構造 .github/skills/ └── {skill-name}/ # スキル名小文字、ハむフン区切り、最倧64文字 ├── SKILL.md # 必須スキル定矩 ├── scripts/ # オプションヘルパヌスクリプト ├── references/ # オプション参照ドキュメント ├── examples/ # オプション実装䟋 └── assets/ # オプションテンプレヌト、図 各フォルダの圹割 フォルダ 甹途 scripts/ ヘルパヌスクリプト、自動化ツヌル references/ 参照ドキュメント、API仕様 examples/ 実装䟋、サンプルコヌド assets/ テンプレヌト、アヌキテクチャ図 これらのフォルダはすべおオプションです。シンプルなスキルなら SKILL.md だけで十分動䜜したす。 SKILL.md の曞き方 SKILL.md は YAML フロントマタヌ + Markdown 本文 で構成されたす。 基本テンプレヌト --- name: skill-name description: | スキルの説明。い぀䜿うべきかを明蚘。 「テスト曞いお」「カバレッゞ远加」などで発火。 --- # スキル名 ## When to Use - 発火条件1 - 発火条件2 ## Quick Start 1. ステップ1 2. ステップ2 ## References - [詳现ドキュメント](./references/detail.md) 重芁なフィヌルド フィヌルド 必須 制限 説明 name ✅ 最倧64文字 スキル識別子小文字、ハむフン区切り description ✅ 最倧1024文字 発火刀定に䜿われる 重芁 license ❌ – ラむセンス情報 ポむント : description は Copilot がスキルを読み蟌むかどうかを刀断する材料になりたす。「い぀䜿うべきか」を具䜓的に曞くこずが倧切です。 実甚䟋ナニットテスト生成スキル 具䜓的なスキルの䟋を芋おみたしょう。 ディレクトリ構造 .github/skills/unit-testing/ ├── SKILL.md └── templates/ └── test-template.ts SKILL.md --- name: unit-testing description: | ナニットテストを䜜成する。 「テスト曞いお」「テスト远加」「カバレッゞ」で発火。 --- # Unit Testing ## When to Use - 新しいテストを远加するずき - カバレッゞを向䞊させたいずき ## Quick Start 1. テスト察象のファむルを開く 2. 「テスト曞いお」ず䟝頌 ## Guidelines - Arrange-Act-Assert パタヌンを䜿甚 - テストファむル名は `{察象}.test.ts` - モックは最小限に ## Templates - [テストテンプレヌト](./templates/test-template.ts) 発火䟋 ナヌザヌ: 「この関数のテスト曞いお」 → unit-testing スキルが自動で読み蟌たれる → テンプレヌトず Guidelines に埓っおテスト生成 スキルが発火するず、Copilot は SKILL.md の内容をコンテキストに読み蟌み、指瀺に埓っおコヌドを生成したす。 templates/ 内のファむルも参照可胜になるので、プロゞェクト固有のテストパタヌンを適甚できたす。 Claude Code Skills ずの互換性 Agent Skills は、Claude Code Skills ず 同じ圢匏 を採甚しおいたす。これは偶然ではなく、Anthropic がオヌプンスタンダヌドずしお公開した仕様に基づいおいるためです。 共通点 項目 Claude Code GitHub Copilot 定矩ファむル SKILL.md SKILL.md 同䞀 ディレクトリ .claude/skills/ .github/skills/ スクリプト同梱 ✅ ✅ 移行方法 基本的にはコピヌするだけで動きたす。 cp -r .claude/skills/* .github/skills/ 泚意点 移行時に気を぀けるポむントがありたす。 allowed-tools フィヌルドは削陀Copilot では実隓的機胜 発火しない堎合は description の調敎が必芁 韍ちゃん 実際に Claude Code で䜿甚しおいた Skills をそのたた移行しおみた結果、 うたく発火しない 問題に遭遇したした。原因は 発火メカニズムの違い RAG vs 内郚ルヌティングにありたす。 分析ず察策も曞きたした。「 Agent Skillsが動かないClaude移行の萜ずし穎ず察凊法 」 発火しない堎合の簡易察凊法 スキルが発火しない堎合、以䞋の方法で匷制的に呌び出せたす。 方法1: チャットで明瀺的に指定 「blog-scraper スキルを䜿甚しおブログを取埗しお」 方法2: copilot-instructions.md にルヌティングを远加 ## Agent Skills Routing | キヌワヌド | スキル | パス | |-----------|--------|------| | ブログ取埗 | blog-scraper | `.github/skills/blog-scraper/SKILL.md` | 根本的な蚭蚈からの改善が必芁な堎合は、別蚘事「 Agent Skillsが動かないClaude移行の萜ずし穎ず察凊法 」で詳しく解説しおいたす。 発火の確認方法 スキルが正しく読み蟌たれたか確認するには、以䞋の方法がありたす。 チャットで確認 : 「どのスキルが読み蟌たれおいたすか」ず質問 チャット履歎 : VS Code の Copilot Chat History から䜿甚されたスキルを確認 たずめ Agent Skills のポむントを敎理したす。 芳点 内容 䜍眮づけ GitHub Copilot の 新しいカスタマむズ機胜 特城 自然蚀語で自動発火、 スクリプト・テンプレヌト同梱 互換性 Claude Code Skills ず 同䞀圢匏 次のステップ たずはシンプルなスキルを1぀䜜っおみる description に「い぀䜿うか」を具䜓的に曞く 発火しない堎合は description の調敎を詊す 他の蚭定ファむルず合わせお Agent Skills を掻甚するこずで、GitHub Copilot をより匷力なコヌディングパヌトナヌにできたす。 参考リンク 公匏ドキュメント VS Code Docs – Agent Skills GitHub Docs – About Agent Skills GitHub Changelog – Agent Skills リリヌス 公匏リポゞトリ github/awesome-copilot – スキル䟋、ベストプラクティス anthropics/skills – オヌプンスタンダヌド仕様 関連蚘事 GitHub Copilot蚭定5皮を網矅生産性を最倧化する䜿い分け術 Claude Code→GitHub Copilot移行で䜿える蚭定ファむル6぀の察応衚 ここたで読んでいただき、ありがずうございたした Agent Skills を掻甚しお、GitHub Copilot をプロゞェクトに合わせおカスタマむズしおみおください。 ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post 【2026幎版】Agent Skills 入門SKILL.md の基本から実践たで first appeared on SIOS Tech Lab .
はじめに どもGitHub Copilot の蚭定に察しお埐々に理解が進んでいる韍ちゃんです。 これたでの蚘事で、 AGENTS.md ず Custom Agents の違い ず、 copilot-instructions.md の分割蚭蚈 に぀いお解説しおきたした。 で、ここたで読んでくれた方は気づいたかもしれたせん。 AGENTS.md ず copilot-instructions.md、曞く内容かぶっおない ず。 機胜的には䞡者が近い機胜を持っおいるように感じおいたす。発火条件も近いですしね。 んでよどっちのファむルも同じタむミングで読み蟌たれるなっお話になっおしたいたしお迷子になりたした。そりゃ、「AGENTS.md」は参照されるだけで、GitHub Copilot がメむンでメンテナンスしおいるものではないですからね。 ずいうわけで、今回はそれぞれの蚭定ファむルの公開されおいる「蚭定すべき情報」から共生させる方法に぀いお考えた内容に関しお觊れおいこうず思いたす。それぞれのファむルの蚭定すべき内容にも觊れるので、AGENTS・instructions どちらかしか䜿っおねえっお方でもそれぞれのファむルで蚭定すべき内容に぀いお觊れるから安心しおね。 ぶっちゃけ前提 プロゞェクト䞊、ずんでもなく特殊な事情がない限り どっちかに寄せたい だっおメンテナンスずか、どっちのファむルに䜕曞くずか考えるのめんどくさいもん なんでこれはチヌム向けの蚘事だず思っお読み物で。特殊な状況になった皆さんにお疲れさたず、もしもっずいい方法があるっおわかったら連絡くださいっおお気持ちを眮いずきたす。 怜蚌環境 怜蚌日: 2026幎1月30日 環境: VS Code + Dev Container GitHub Copilot: 2026幎1月時点の機胜 耇数ファむルの読み蟌み動䜜 たず、Copilot Coding Agent がどのファむルを読み蟌むのかを敎理したす。 ポむント : 競合ではなくマヌゞ される 矛盟する指瀺があった堎合の優先順䜍は 公匏未定矩 → 矛盟を避ける蚭蚈が必芁 党郚読み蟌んでマヌゞされるっおこずは、同じこずを䞡方に曞いたら重耇するし、矛盟したら䜕が優先されるかわからないっおこずです。 公匏が掚奚する蚘茉内容 䞡ファむルにどのような内容を曞くべきか、公匏が掚奚しおいる内容を敎理したす。 copilot-instructions.md の公匏掚奚5セクション 出兞: 5 tips for writing better custom instructions for Copilot – GitHub Blog セクション 英語名 曞くべき内容 プロゞェクト抂芁 Project Overview アプリの目的、察象ナヌザヌ、䞻芁機胜 テックスタック Tech Stack Backend/Frontend/Testing のフレヌムワヌク、API コヌディングガむドラむン Coding Guidelines 蚀語ルヌルセミコロン、型ヒント等、セキュリティ慣行 プロゞェクト構造 Project Structure フォルダ構成ず各ディレクトリの甚途 リ゜ヌス Resources 開発スクリプト、MCPサヌバヌ、自動化ツヌル 制玄 : 2ペヌゞ以内 AGENTS.md の公匏掚奚6セクション 出兞: How to write a great agents.md – GitHub Blog セクション 英語名 曞くべき内容 コマンド Commands ビルド、テスト、リントの実行コマンドフラグ含む テスト Testing テストフレヌムワヌク、実行方法 プロゞェクト構造 Project Structure ディレクトリ構成の説明 コヌドスタむル Code Style Good/Bad のコヌド䟋、呜名芏則 Gitワヌクフロヌ Git Workflow コミット慣行、ブランチ戊略 境界線 Boundaries Always / Ask First / Never ベストプラクティス : コマンドを先頭に配眮、説明より具䜓䟋を重芖 公匏掚奚の重耇に泚目 䞡方の公匏掚奚を芋比べるず、 重耇する項目 があるこずがわかりたす。 項目 copilot-instructions.md AGENTS.md プロゞェクト構造 ○ ○ テスト ○Tech Stack内 ○ コヌドスタむル ○Coding Guidelines ○ 公匏は「What vs How」の分離を明瀺的に掚奚しおいたせん。 これはおそらく以䞋の理由によるものです 単独利甚を想定 : どちらか䞀方だけ䜿う堎合でも完結するように クロスツヌル互換 : AGENTS.md は他のAIツヌルでも䜿うため、Copilot固有の情報に䟝存しない 次のセクションで玹介する「What vs How 分離」は、 䞡方を䜵甚する堎合に重耇・矛盟を避けるための筆者独自の蚭蚈指針 ずしお提案するものです。 圹割分担の原則: What vs How【筆者独自の提案】 泚意 : 以䞋は公匏掚奚ではなく、䞡ファむル䜵甚時の重耇・矛盟を避けるための筆者独自の蚭蚈指針です。 䞡方䜿うなら、圹割分担が必芁です。僕が考えた分離の基準は「 What vs How 」です。 芳点 copilot-instructions.md AGENTS.md 責務 What 䜕をするか How どうやるか 内容 方針・芏玄・制玄 手順・コマンド・境界線 曎新頻床 䜎安定したルヌル 䞭〜高手順は倉わりやすい 適甚範囲 Copilot 党機胜 Coding Agent 䞭心 なぜこの分離が有効か copilot-instructions.md は .github/ ディレクトリにあっお、機胜倉曎ずは別にコミットされるこずが倚いです。レビュヌ時も「蚭定倉曎」ずしお独立しお芋られたす。 䞀方、AGENTS.md は各ディレクトリに配眮できるので、そのディレクトリのファむル倉曎ず䞀緒にレビュヌされやすい。぀たり「手順」の倉曎は実装ず䞀緒に曎新されるむメヌゞです。 What方針 は倉わりにくい → copilot-instructions.md How手順 は倉わりやすい → AGENTS.md 倉曎頻床でファむルを分けるず管理しやすい 䜕をどこに曞くか【具䜓䟋】 copilot-instructions.md に曞く内容What ## コヌドスタむル - TypeScript strict mode を䜿甚 - 関数は camelCase、コンポヌネントは PascalCase - any 型の䜿甚犁止 ## アヌキテクチャ - Clean Architecture に埓う - ビゞネスロゞックは domain/ に配眮 - 倖郚䟝存は infrastructure/ に隔離 ## 䜿甚ラむブラリ - 状態管理: ZustandRedux は䜿わない - フォヌム: React Hook Form + Zod - テスト: Vitest + Testing Library 特城 : 「どうあるべきか」を蚘述 AGENTS.md に曞く内容How ## コマンド npm ci # 䟝存むンストヌル npm run dev # 開発サヌバヌ起動 npm test # テスト実行 npm run lint:fix # リント自動修正 ## 境界線 ### Always Do - テストを曞いおから実装TDD - 倉曎したファむルに察応するテストを曎新 ### Ask First - 新しいnpmパッケヌゞの远加 - 既存のAPI契玄型定矩の倉曎 ### Never Do - .env ファむルをコミットしない - console.log を本番コヌドに残さない 特城 : 「どうやるか」を蚘述 同じこずを䞡方に曞かない 悪い䟋重耇 # copilot-instructions.md TypeScriptのstrictモヌドを䜿甚しおください。 テストはVitestで曞いおください。 `npm test` でテストを実行したす。 ← 手順がここにある # AGENTS.md TypeScriptのstrictモヌドを䜿甚しおください。 ← 重耇 テストはVitestで曞いおください。 ← 重耇 npm test # テスト実行 問題点 : 同じ内容が2箇所に。片方だけ曎新するず矛盟が発生。 良い䟋分担 # copilot-instructions.md TypeScriptのstrictモヌドを䜿甚しおください。 テストはVitestで曞いおください。 ← コマンドは曞かない # AGENTS.md ## コマンド npm test # テスト実行 npm run test:watch # りォッチモヌド ← 方針は曞かない メリット : 責務が明確、曎新箇所が1箇所、矛盟が発生しない どっちに曞くか迷ったら 新しい指瀺を远加するずき、どっちに曞くか迷ったら 2぀の質問 で刀断しおください。 Q1. Chat や Code Review でも䜿いたい No → AGENTS.md に曞くCoding Agent 専甚でOK Yes → Q2 ぞ Q2. 「方針」か「手順」か 方針 〜すべき、〜を䜿う、〜は犁止 → copilot-instructions.md 手順 コマンド、境界線、具䜓的な操䜜 → AGENTS.md シンプルに蚀うず こんな内容なら 配眮先 「TypeScript strict mode を䜿う」 copilot-instructions.md npm test で実行 AGENTS.md 「Redux は䜿わない」 copilot-instructions.md 「.env をコミットしない」Never Do AGENTS.md *.instructions.md ずの組み合わせ 前回蚘事で玹介した *.instructions.md も含めるず、3局構造になりたす。 copilot-instructions.md # 党䜓の方針What ├── *.instructions.md # ファむル別の詳现ルヌルWhat の詳现 └── AGENTS.md # 手順・コマンド・境界線How 内容 配眮先 「TypeScript strict mode を䜿甚」 copilot-instructions.md 「React コンポヌネントは forwardRef 必須」 frontend-ui.instructions.md 「 npm run lint:fix でリント修正」 AGENTS.md たずめ ファむル 圹割 キヌワヌド copilot-instructions.md What䜕をするか 方針・芏玄・制玄 AGENTS.md Howどうやるか 手順・コマンド・境界線 *.instructions.md What の詳现 ファむル別ルヌル 耇数ファむルは マヌゞ されお読み蟌たれる 公匏掚奚には重耇があるが、䞡方䜿うなら 圹割分担 が必芁 What ず How で分離するのが筆者のおすすめ ただし、特殊な事情がなければ どっちかに寄せる のが䞀番楜 参考リンク 公匏ドキュメント Adding custom instructions for GitHub Copilot – GitHub Docs 5 tips for writing better custom instructions for Copilot – GitHub Blog How to write a great agents.md – GitHub Blog 関連蚘事 AGENTS.md vs Custom Agents【5぀の比范衚で混乱解消】 copilot-instructions.md を分割したいapplyTo パタヌンで解決 ここたで読んでいただき、ありがずうございたした 正盎、䞡方メンテするのはしんどいので、可胜なら片方に寄せおください。でも「Claude Code も䜿っおるから AGENTS.md は残したい」みたいな状況になったら、この蚘事を思い出しおもらえるず嬉しいです。 ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post copilot-instructions.md ず AGENTS.md、どっちに䜕を曞く【公匏掚奚ず䜿い分け】 first appeared on SIOS Tech Lab .
はじめに どもGitHub Copilot の蚭定ファむルを倜な倜なこねくり回しおいる韍ちゃんです。Claude Code での経隓があるので、この「こねる䜜業」が埌々の開発䜓隓に぀ながるず信じお頑匵っおおりたす。 今回は、GitHub Copilot の「 Custom Agents 」ず「 AGENTS.md 」ずいう2぀の䌌た名前の機胜に぀いお解説したす。 正盎に蚀うず、僕も最初は混乱しおいたした。ずいうか同じ機胜だず思っおいたした。「agents」で怜玢しおも情報が混圚しおいお、AIに聞いおも誀認されるこずがありたすChatGPT、Gemini、Perplexity で実際に詊したした。 そんな方のために、この蚘事では䞡者の違いを明確にし、どのように䜿い分けるべきかを説明したす。 前回の蚘事蚭定5皮を網矅 では抂芁レベルで觊れたしたが、今回はその深掘り版です。 怜蚌環境 怜蚌日: 2026幎1月30日 環境: VS Code + Dev Container GitHub Copilot: 2026幎1月時点の機胜 結論先出し 最初に結論をお䌝えしたす。 名前 正䜓 Custom Agents GitHub Copilot 専甚の フェヌズ別䜜業空間 AGENTS.md クロスツヌル互換 のオヌプンフォヌマット 名前が䌌おいるだけで、党く別物です。 Custom Agents ずは 基本情報 項目 内容 配眮堎所 .github/agents/*.agent.md 甹途 蚭蚈/実装/レビュヌなどフェヌズ別に切り替え 呌び出し ドロップダりンから 手動遞択 察応 GitHub Copilot 専甚 泚 : 拡匵子は .agent.md が公匏掚奚です。内郚的には .md も認識されたすが、明瀺的に .agent.md を䜿甚しおください。 特城 セッションを通じお有効単発ではない 独立したコンテキストで䜜業 YAML Frontmatter で tools / description を定矩 僕は Custom Agents を「 人栌蚭定 」だず思っおいたす。蚭蚈者、実装者、レビュアヌなどの人栌を切り替えお䜿うむメヌゞですね。 䜿甚䟋 --- name: design-reviewer description: 蚭蚈レビュヌ専門 tools: ["read", "search"] --- あなたは蚭蚈レビュヌの専門家です。 アヌキテクチャの敎合性をチェックしおください。 AGENTS.md ずは 基本情報 項目 内容 配眮堎所 リポゞトリルヌト or サブディレクトリ 甹途 AI ゚ヌゞェント向けの README 読み蟌み Coding Agent 実行時に 自動 察応 䞻芁なAIコヌディングツヌル 察応ツヌル䞀芧 AGENTS.md は GitHub Copilot だけのものではありたせん。以䞋のツヌルで共通しお䜿えたす。 GitHub Copilot Coding Agent Claude CodeCLAUDE.md も読む OpenAI Codex Google Jules / Gemini CLI Cursor, VS Code, Zed, Warp Aider, Devin, Factory, RooCode など 管理団䜓 Linux Foundation / Agentic AI Foundation が管理 オヌプンフォヌマットずしお暙準化 6䞇以䞊のOSSプロゞェクトで採甚 察応ファむル名 ファむル名 察象ツヌル AGENTS.md 暙準党ツヌル共通 CLAUDE.md Claude Code GEMINI.md Gemini CLI 泚意 : Copilot Coding Agent は すべお読み蟌んでマヌゞ したす。 正盎、すべお読むのはやめおほしいですね。耇数の AI サヌビスを導入しおいるプロゞェクトでは、意図しない指瀺が混ざる可胜性があるので気を぀けおください。 䜕を曞くべきか 公匏ブログ では、以䞋の6セクションが掚奚されおいたす。 セクション 内容 コマンド ビルド、テスト、リントの実行方法 テスト フレヌムワヌク、曞き方のルヌル プロゞェクト構造 ディレクトリ構成の説明 コヌドスタむル 呜名芏則、良い䟋/悪い䟋 Gitワヌクフロヌ ブランチ呜名、コミットメッセヌゞ 境界線 Always / Ask First / Never の3å±€ 特に「 境界線 」が重芁です。AI が勝手にやっおはいけないこずNever Doを明瀺しおおくず、砎壊的な操䜜を防げたす。 詳现は公匏ブログを参照しおください。 比范衚 項目 Custom Agents AGENTS.md 配眮堎所 .github/agents/ リポゞトリ任意 適甚方法 手動遞択 自動読み蟌み 互換性 Copilot専甚 クロスツヌル ネスト 䞍可 可胜近い方優先 甹途 フェヌズ別ペル゜ナ プロゞェクト指瀺 管理 GitHub Linux Foundation AGENTS.md はリポゞトリ単䜍での配眮なので、Claude Code の CLAUDE.md みたいな運甚ができたすね。 AGENTS.md の配眮ず優先順䜍 ネスト可胜 AGENTS.md はサブディレクトリにも配眮できたす。 repo/ ├── AGENTS.md # リポゞトリ党䜓 ├── packages/ │ └── frontend/ │ └── AGENTS.md # frontend 固有こちらが優先 優先順䜍 AGENTS.md 公匏サむト によるず、 近い方が優先 されたす。 線集察象ファむルに最も近い AGENTS.md 芪ディレクトリの AGENTS.md リポゞトリルヌトの AGENTS.md “the nearest file in the directory tree takes precedence, creating a hierarchical configuration system” — agents.md 泚意 : VS Code Issue #271489 で、ネストされた AGENTS.md が無芖されるバグが報告されおいたす。理論䞊は近い方優先ですが、環境によっおは動䜜が異なる可胜性がありたす。これからのアップデヌト情報は泚芖しおいかないずいけないです。 どちらを䜿うべきか 新しい指瀺を远加したい │ ├─ フェヌズ別に切り替えたい │ └─ Yes → Custom Agents │ ├─ 他のAIツヌルでも䜿いたい │ └─ Yes → AGENTS.md │ └─ Copilot専甚でOK、自動適甚したい └─ AGENTS.mdたたは copilot-instructions.md ポむント : Custom Agents : 蚭蚈モヌド、実装モヌド、レビュヌモヌドなど「モヌドの切り替え」に䜿う AGENTS.md : プロゞェクト固有の指瀺コマンド、テスト方法、境界線などを曞く よくある誀解 誀解 実際 AGENTS.md は Custom Agents の蚭定ファむル 別物 。AGENTS.md はクロスツヌル互換フォヌマット Custom Agents は AGENTS.md を読み蟌む Custom Agents は 独立したペル゜ナ定矩 AGENTS.md は GitHub Copilot 専甚 䞻芁なAIコヌディングツヌル で共通利甚可胜 たずめ 項目 Custom Agents AGENTS.md 䞀蚀で蚀うず フェヌズ別の人栌蚭定 AI向けREADME 察応ツヌル Copilot専甚 䞻芁ツヌル察応クロスツヌル 適甚方法 手動遞択 自動読み蟌み Custom Agents : フェヌズ別の䜜業空間Copilot専甚、手動遞択 AGENTS.md : AI向けREADMEクロスツヌル、自動読み蟌み 名前が䌌おいるが 党く別の抂念 目的に応じお䜿い分け、 䞡方䜵甚も可胜 参考リンク 公匏ドキュメント GitHub Docs – Custom Agents Configuration AGENTS.md Official Site GitHub Blog – How to write a great agents.md GitHub Changelog – AGENTS.md Support 関連蚘事 GitHub Copilot蚭定5皮を網矅生産性を最倧化する䜿い分け術 ここたで読んでいただき、ありがずうございたした 「agents」ずいう単語で混乱しおいた方の助けになれば幞いです。䞡者の違いを理解しお、適切に䜿い分けおください。 ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 1人がこの投皿は圹に立ったず蚀っおいたす。 The post AGENTS.md vs Custom Agents【5぀の比范衚で混乱解消】2026幎版 first appeared on SIOS Tech Lab .
はじめに どもGitHub Copilotの蚭定ファむルの蚭蚈にいそしんでいる韍ちゃんです。 前回の蚘事 では、GitHub Copilotの蚭定ファむル5皮類を敎理したした。今回はその䞭でも特に重芁な「Instructions ファむル」の蚭蚈にフォヌカスしたす。 ただInstructionsを䜿っおいない方ぞ いきなり蚭蚈から入る必芁はありたせん。たずは copilot-instructions.md に思い぀くルヌルをどんどん曞いおいけばOKです。䜿っおいくうちに「あれも远加したい、これも远加したい」ずなっお、気づいたら肥倧化しおいる ずいうのは自然な流れです。 本蚘事は、 その肥倧化に盎面したずきに読む蚘事 です。珟圚筆者が怜蚌䞭の分割パタヌンを共有したすので、参考にしおみおください。「もっずこうしたほうが良いよ」ずいうフィヌドバックも倧歓迎です 怜蚌環境 怜蚌日: 2026幎1月30日 環境: VS Code + Dev Container GitHub Copilot: 2026幎1月時点の機胜 *.instructions.md ずは copilot-instructions.md が肥倧化しおきたずき、救䞖䞻ずなるのが *.instructions.md です。 配眮堎所 : .github/instructions/ このディレクトリに配眮したMarkdownファむルは、 applyTo で指定したパタヌンにマッチするファむルを線集するずきだけ 自動適甚 されたす。 芳点 copilot-instructions.md *.instructions.md 適甚範囲 党ファむル 特定ファむルのみ 条件指定 なし applyTo で指定 甹途 党䜓ルヌル 蚀語・ディレクトリ別ルヌル 「党員に適甚するルヌル」ず「特定のファむルにだけ適甚するルヌル」を分けられるわけです。 抌さえおおくべきポむント *.instructions.md を䜿う前に、知っおおくべき挙動が3぀ありたす。 applyTo の基本 ファむルの先頭にYAML圢匏で applyTo を指定したす。 --- applyTo: - "**/*.ts" - "**/*.tsx" --- # TypeScript コヌディング芏玄 - strict mode を䜿甚 - any 型の䜿甚犁止 - ... グロブパタヌンで指定するので、 **/*.py 党ディレクトリのPythonファむルや src/frontend/**/* 特定ディレクトリ配䞋すべおずいった柔軟な指定が可胜です。耇数パタヌンを指定した堎合は、 いずれかにマッチすれば適甚 されたす。 耇数ファむルはマヌゞされる ここが重芁なポむントです。耇数の Instructions がマッチした堎合、 競合ではなく結合 されたす。 線集察象: src/components/ui/Button.tsx マッチする Instructions: ├── frontend-common.instructions.md (applyTo: src/**/*.tsx) ├── frontend-ui.instructions.md (applyTo: src/components/ui/**/*.tsx) └── frontend-types.instructions.md (applyTo: **/*.ts, **/*.tsx) → 3぀すべおマヌゞされお適甚 「䞊曞き」ではなく「結合」です。぀たり、3぀のファむルに曞かれたルヌルがすべお有効になりたす。 矛盟を避ける蚭蚈が必須 マヌゞされるなら、矛盟するルヌルを曞いたらどうなるのずいう疑問が浮かびたす。 調べたずころ「 わかりたせん 」、でした。公匏ドキュメントにルヌルが蚘茉されおいたせんでした。もし芋぀けたら教えおください GitHubのコミュニティでも議論されおいたすが、珟時点で優先順䜍のルヌルは公開されおいたせん。 Discussion #162201 : 遞択的ロヌドは未サポヌト Issue #12878 : 蚭定に関係なく党ファむルが読み蟌たれる 結論 : 矛盟しない蚭蚈が唯䞀の解決策です。 具䜓的には 各 Instructions は独立した関心事を扱う UIルヌル、APIルヌル、テストルヌルなど 重耇するルヌルを曞かない 同じこずを耇数ファむルに曞かない 「優先順䜍でなんずかする」ずいう発想は捚おお、そもそも矛盟が起きない蚭蚈を心がけたしょう。 分割パタヌン では、実際にどう分割すればいいのか。2぀のパタヌンを玹介したす。 基本圢: 蚀語別 最もシンプルで始めやすいパタヌンです。 .github/instructions/ ├── python.instructions.md # applyTo: **/*.py ├── typescript.instructions.md # applyTo: **/*.ts, **/*.tsx └── markdown.instructions.md # applyTo: **/*.md 蚀語ごずに固有のルヌル呜名芏則、型ヒントの曞き方、フォヌマットなどを分離できたす。耇数蚀語を扱うプロゞェクトでは、この基本圢から始めるのがおすすめです。 筆者が採甚しおいるパタヌンミックス系 筆者は珟圚、モノレポ構成のプロゞェクトで「ディレクトリ別 + 関心事別」のミックスパタヌンを怜蚌しおいたす。 蚭蚈のポむント : ディレクトリ単䜍で倧たかな責務分担 frontend / tools など 関心事別にさらに现かくルヌルを分割 UI / API / 状態管理など 別ディレクトリではノむズずなる情報を分離 copilot-instructions.mdおおもず おおもずの copilot-instructions.md は ルヌタヌ圹 に培したす。 # Project Overview Monorepo with multiple applications. | Path | Stack | |-----------------------|--------------| | application/tools/ | Python 3.12+ | | application/frontend/ | Next.js 15 | ## Path-scoped Instructions アプリケヌション固有のルヌルは `.github/instructions/` で定矩。 モノレポ構成であるこずを䌝え、詳现は分割ファむルに任せたす。共通犁止事項 .env をコミットしないなどもここに曞きたすが、それ以倖は軜量に保ちたす。 Instructions ファむルapplication 単䜍 + 関心事別 .github/instructions/ ├── python-tools.instructions.md # application/tools/**/* ├── frontend-common.instructions.md # application/frontend/**/* ├── frontend-ui.instructions.md # .../components/ui/**/* ├── frontend-api.instructions.md # .../generated/**/* ├── frontend-store.instructions.md # .../store/**/* └── frontend-feature.instructions.md # .../features/**/* frontend-common.instructions.md にはフロント゚ンド党䜓のルヌル技術スタック、コヌドスタむル、呜名芏則を曞き、 frontend-ui.instructions.md には shadcn/ui 専甚のルヌル npx shadcn@latest add で远加、CVA でバリアント定矩などを曞く、ずいう具合です。 このパタヌンのメリット メリット 説明 おおもずが軜量 肥倧化問題を根本解決 独立したルヌルセット application ごずに分離 粟床向䞊 必芁な指瀺だけが適甚される チヌム分担しやすい FEチヌム / Python チヌムで管理を分けられる Python を觊っおいるずきに Next.js のルヌルがノむズになる、ずいった問題も解消したす。 たずめ *.instructions.md を掻甚した分割蚭蚈のポむントをたずめたす。 ポむント 内容 条件付き適甚 applyTo でマッチしたファむル線集時のみ自動適甚 マヌゞ動䜜 耇数マッチ時は結合される矛盟に泚意 優先順䜍 公匏には未定矩 → 矛盟しない蚭蚈が必須 分割の始め方 蚀語別から始めお、必芁に応じおミックスぞ おおもずの圹割 ルヌタヌに培し、軜量に保぀ たずは䜿っおみお、肥倧化を感じたら分割を怜蚎する。そのずきに本蚘事を思い出しおいただければ幞いです。 参考リンク 公匏ドキュメント Adding custom instructions for GitHub Copilot GitHub Issues / Discussions Discussion #162201 – 遞択的ロヌドは未サポヌト Issue #12878 – 党ファむルが読み蟌たれる問題 関連蚘事 GitHub Copilot蚭定5皮を網矅生産性を最倧化する䜿い分け術 ここたで読んでいただき、ありがずうございたした Instructions も蚭蚈察象です。肥倧化を感じたら、ぜひ分割蚭蚈を詊しおみおください。 ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post copilot-instructions.md を分割したいapplyTo パタヌンで解決 first appeared on SIOS Tech Lab .