Claude Codeスキルの更新を教材に同期する「skill-to-lesson」を初実運用した

スキルを直したら教材も直る——そういう仕組みを作ってあったのを、今日初めて本番で回した。svg-diagram スキル側の追補をSVG図解講座のレッスンコンテンツに同期させ、図が抜けていたセクションはNG/OK対比図つきに格上げして公開まで持っていった。

積み残しの棚卸しから開始

朝一番に「積み残しがいくつかあると思うので調べて」と Claude Code に棚卸しさせた。出てきたのは3系統。

7/2 に立てた次セッション実装計画（品質チェックスクリプト＋大物選定）が丸ごと未着手
SVG図解講座（draft）の公開前の仕上げが残り
git の未整理ファイル

このうち2番目、SVG図解講座の仕上げに着手することにした。本体は 7/3 にコミット済みで、ESLint・テスト2,631件・表示確認まで通っている。残っていたのは原典スキルとの対応表 mappings/svg-diagram.md の同期まわりだった。

公開前仕上げ — CRLFに足を取られつつ draft 解除まで

仕上げは配布物側の同期から進めさせた。途中、改行コード（CRLF）が ID 比較を壊して照合が全滅し、tr -d '\r' を挟んで再実行する場面があった。Windows 環境で文字列比較をやるときの定番の罠に、またかかった。

そこからは一気通貫で流れた。

本文反映 → toc と millerSlideCounts の更新
draft 解除 → content JSON 再生成（69ファイル）
ESLint 指摘ゼロ → テスト2,631件全PASS
dev サーバーで表示確認 → コミット＋デプロイ

表示確認では、講座一覧に「ドラフト」表示が7件残っているように見えて一瞬ひやりとしたが、当該カード周辺を確認させたら他講座のものだった。SVG図解講座側はすべて反映済み。

ひとつだけ本番で引っかかった。トップの講座一覧カードの画像が404を返す。原因は、検証で叩いた素のURLに404が4時間キャッシュされていたことだった。講座の全ページ・全画像・配布zipはすでに正常配信されていて、残っていたのはこのカード画像1枚だけ。講座画像一式を R2 にアップロードし、?v=1 を付与して再デプロイしたら直った。公開作業はこれで完了。

skill-to-lesson の初実運用

ここからが今日の本題。SVG図解講座には「原典スキルが更新されたらコンテンツにも反映できる」仕組みを仕込んであった。svg-diagram スキル側の内容は実際に変えてあるので、これを試すことにした。

まずスキル側の変更履歴を git で管理し始めたいので、現時点でコミットさせた。そのうえで skill-to-lesson スキルを使い、原典スキルの変更内容を確認して講座へ同期させた。

結果は意外なもので、スキル側の追補（「フロー図は縦に流す」など新セクション2つ＋禁止事項の改稿）は、今朝の公開仕上げで mappings 経由の同期が走った時点ですでに講座・配布物・本番のすべてに反映済みだった。今回新たに同期するものはゼロ。仕組みが先回りして仕事を終えていた形になる。

とはいえ「反映済みです」だけでは信用しない。「表示確認してもらってますか」と聞いてみると、実画面の確認は生成JSONとHTTP応答のチェックまでだと分かった。そこで本番URLで3箇所をスクリーンショットで目視させた。

「フロー図は縦に流す」（レイアウトの章）— チャプター列の5番目に表示、スライドカウントも「5/16」に更新
もう1つの新セクション — 本文・コード例・右側目次まで正常
改稿した禁止事項 — 更新後の文面で表示

「URLっていうか、どこですか？パス」と聞いて、本番とローカルホストのURLを並べて出させ、自分の目でも場所を押さえた。

「どのSVGがビフォアか分からない」往復

表示を眺めていて気づいた。「フロー図は縦に流す」のセクションに、ビフォア・アフターの図が具体的にない。修正したSVGは手元にあるはずなのに、それがどれか分からないのか？と聞いてみた。

返ってきた説明はこうだった。原典スキルの追補にはNG/OK画像が無く本文＋コード例だけだったので、講座側もそれに合わせて文章のみのB型で反映した。スキルの手順上「NG/OK例が変わったルールだけSVGを再作成する」なので、図なしはルール通り——と。

理屈は通っているが、実物があるなら図にしたい。コード例の文言を手がかりに探させかけたところで、こちらから apps/web/public/images/genai-idea-after-filing/figure-02.svg のパスを渡した。「今がアフターで、ビフォアは git の履歴から見て」と伝えると、履歴から旧版を掘り出してNG/OKのSVG2枚を作成、XMLチェックを通し、講座データをB型からA型（対比図つき）に書き換えてくれた。テストは2,631件PASS。

書き換え後も「NG対比図はどこに入れたのか」とパスを確認する往復を挟んだ。SVGファイルの場所と表示されるページを出させ、自分で確認してからコミット（05eae56e、SVG2枚＋データ＋slideCounts＋mappings の5ファイル）。新画像2枚は R2 アップロード済みだったので、デプロイは自分側でやることにして午前を締めた。

夕方 — 次にコンテンツ化するスキルを洗い出す

夕方、完成したレッスンコンテンツを改めて開いた。章立てとスライド送りの構成を眺めて、素直によくできていると思った。それなら、他の自作スキルも同じ型でコンテンツ化できるはずだ。「どのスキルをコンテンツにすればいいか、優先度をつけて列挙して」と頼んだ。

SVG図解講座がなぜ成立したかを4つの評価軸に分解したうえで全スキルを仕分けさせたところ、最有力は excel-html-mock、次点が visual-design-essentials と japanese-tech-writing という結果になった。

ただ、チャット上の一覧は文字の壁で、目が上下に往復するばかりだった。そこで .html でドキュメント化させ、Chrome DevTools 経由で表示させた。memo/2026-07-04/skill-lesson-candidates.html に候補マトリックスとしてまとまり、格段に見通しが良くなった。

「スキルってこれだけ？」— 走査漏れの指摘

マトリックスを見て違和感が湧いた。スキルの数が少なすぎる。mdx-playground のプロジェクトレベルのスキル、スラッシュコマンド、ユーザーレベルのスキルとコマンド——これも全部スキルと同等のはずだが、見てくれているのか？

案の定、見落としだった。最初の走査は「ユーザーレベルのスキル」と「eurekapu のプロジェクトスキル」の2箇所だけ。漏れていたのは以下だった。

ユーザーレベルのスラッシュコマンド 12件
mdx-playground のプロジェクトスキル 10件
mdx-playground のスラッシュコマンド 23件
eurekapu のスラッシュコマンド 4件

全6箇所を走査し直させ、HTMLをv2に更新、Chromeのタブも再読み込みして網羅を確認した。スキル10件・コマンド計39件が候補の母集団に加わったので、明日見るマトリックスは景色が変わっているはずだ。

進捗を残して明日へ

v2の確認は明日やることにして、進捗を残させた。memo/2026-07-04/skill-lesson-progress.md に今日やったこと・選定結果・明日やることをチェックボックス形式で記録し、Googleタスクにも明日期日で登録。進捗は3箇所に残った状態で終了。

学び

スキル→教材の同期は「仕組みが先回りする」形で動いた。skill-to-lesson を明示的に回す前に、公開仕上げの mappings 同期がスキル追補を取り込んでいた。差分ゼロの確認自体が初実運用の成果
「反映済み」と「表示確認済み」は別物。生成JSONとHTTP応答が通っていても、実画面のスクショ目視までやらせないと安心できない
原典に図が無ければ教材も図なし、はルール通りだが最善ではない。実物のSVGがあるならパスを渡してA型に格上げする、という人間側の一手で教材の質が上がった
候補の洗い出しは走査範囲を先に確認する。プロジェクトレベル・ユーザーレベル・スラッシュコマンドまで含めて6箇所、と指摘するまで2箇所しか見ていなかった
CRLF は今日も文字列比較を壊す。tr -d '\r' を反射で挟めるようにしておく

明日やること

候補マトリックスv2を開いて、最有力 excel-html-mock のコンテンツ化に着手するか判断する
7/2 の次セッション実装計画（品質チェックスクリプト＋大物選定）の扱いを決める