Slide 1

Slide 1 text

© 2026 Classmethod, Inc. 2026/07/10 政岡慧 Claude Code公式skillで 自分の仕事を少しずつ手放そう! AI事業本部 生成AIインテグレーション部 西日本開発チーム

Slide 2

Slide 2 text

© 2026 Classmethod, Inc. ⾃⼰紹介 2 ● 2024年4⽉ ○ 新卒でベンチャー ○ ⽣成AI関連のコンサル ● 2025年8⽉ ○ クラスメソッド⼊社 ● 2025年10⽉〜 ○ ⽣成AI内製開発⽀援 ● 2026年5⽉ ○ CCA-F取得 ● 部署 ○ AI事業本部 ■ ⽣成AIインテグレーション部 ● ⻄⽇本開発チーム ● 名前 ○ 政岡 慧 ( Masaoka Kei ) ● 趣味 ○ 筋トレ

Slide 3

Slide 3 text

© 2026 Classmethod, Inc. 2 今⽇は3つの公式skillの使い所と、仕事の⼿放し⽅を話します ① /code-review レビューの⾒逃しを、独⽴したレビュアで潰す ② /verify 「直しました」を信じず、実物の画⾯で確かめる ③ /skill-creator ⾃分の基準をskillにして、効き⽬まで測る

Slide 4

Slide 4 text

© 2026 Classmethod, Inc. 3 そもそもskillとは…? skillの実体はフォルダに置いたMarkdownファイル1枚 .claude/skills/commit-message/SKILL.md >>- name: commit-message description: コミットメッセージを規 約に沿って書く >>- 1. 変更のスコープを特定 2. : で書く 3. 本文には理由(why)を書く 本⽂は使うときまで読まれない 「今の変更を コミットして」 ⾃動 descriptionに関連するかを Claudeが判定して読み込む /commit-message ⼿動 そのまま読み込む 公式skillは今も増え続けている /code-review /verify /simplify /batch /run /skill-creator /dataviz ほか多数 開発でよくある課題を交えながら、3つのskillを具体的に⾒ていきます。

Slide 5

Slide 5 text

© 2026 Classmethod, Inc. 4 あるある① レビューの⾒逃しが多い 書いた本⼈のバイアスがかかってしまう

Slide 6

Slide 6 text

© 2026 Classmethod, Inc. 5 同じコンテキスト内でレビューしたときに⾒逃しが発⽣ なぜ起こる? • 書いた本⼈は「正しく書けたはず」という 前提でコードを読む • Claudeも、⾃分が変更した⽂脈を引きずっ たまま⾒直すので、同じ思い込みを持ち込 んでしまう • ⾒直す回数を増やしても、視点が同じなら⾒ 逃しは残る /code-review • コンテキストが独⽴しているサブエージェ ントが差分をレビューする • 正当性バグに加えて、再利⽤‧簡素化‧効率 の観点でも指摘 • --fix を付ければ指摘の修正まで適⽤、ultra をつければ多エージェントレビュー コードを書いた記憶のない別のエージェントにレビューを依頼することができる

Slide 7

Slide 7 text

© 2026 Classmethod, Inc. 6 コードにバグを3つ仕込む ① ② ③ ① 型不⼀致のfillter seatCount は number、seats は input 由来の string。 3 === "3" は常に false で、しぼり込むと⼀覧が必ず空になる。 ② 破壊的なsort コピーせず state 由来の配列を .sort() で直接ミューテート。 正しくは [...filtered].sort()。 ③ APIフィールドの改名漏れ seats → seatCount にリネームしたのに描画は s.seats のまま。 常に undefined で「残り undefined 席」と表⽰される。

Slide 8

Slide 8 text

© 2026 Classmethod, Inc. 6 バグを3つ仕込んだコードに /code-review を実⾏した結果 勉強会の申し込み⼀覧に型不⼀致filter / 破壊的sort / 改名漏れを仕込む Phase1:複数のエージェントが立ち上がり、様々な観点からコードレビューを行う 実行コマンド : /code-review --fix

Slide 9

Slide 9 text

© 2026 Classmethod, Inc. 6 バグを3つ仕込んだコードに /code-review を実⾏した結果 9個の観点でレビューしていたことが判明 実際は10個あるみたいだが、 CLAUDE.mdがないため省略された 実行コマンド : /code-review --fix 勉強会の申し込み⼀覧に型不⼀致filter / 破壊的sort / 改名漏れを仕込む

Slide 10

Slide 10 text

© 2026 Classmethod, Inc. 6 バグを3つ仕込んだコードに /code-review を実⾏した結果 Phase2:複数のエージェントが立ち上がり検証を行う ここでは、報告されたバグが本当に正しいものなのか別エージェントに依頼 実行コマンド : /code-review --fix 勉強会の申し込み⼀覧に型不⼀致filter / 破壊的sort / 改名漏れを仕込む

Slide 11

Slide 11 text

© 2026 Classmethod, Inc. 6 バグを3つ仕込んだコードに /code-review を実⾏した結果 Phase3:報告されたバグ以外の欠陥を探す(スイープ) 実行コマンド : /code-review --fix 勉強会の申し込み⼀覧に型不⼀致filter / 破壊的sort / 改名漏れを仕込む

Slide 12

Slide 12 text

© 2026 Classmethod, Inc. 6 バグを3つ仕込んだコードに /code-review を実⾏した結果 実行コマンド : /code-review --fix 緑枠:Phase3で出てきたもの 最終的に8個のバグが検出 赤枠:Phase1,2で発見されたバグ 勉強会の申し込み⼀覧に型不⼀致filter / 破壊的sort / 改名漏れを仕込む

Slide 13

Slide 13 text

© 2026 Classmethod, Inc. 6 バグを3つ仕込んだコードに /code-review を実⾏した結果 実行コマンド : /code-review --fix CONFIRMED: どんな入力・状態でトリガーさ れ、どう間違った出力になるかを具体的に指摘 したり、該当行を引用できる。 PLAUSIBLE: バグはあるけど、実際に発火する かは条件次第で確信度が下がる。 REFUTED: 検証の結果、実は間違い (そのコー ドはそう書かれていない )か、どこか別の場所で 起きないようにされている。 (今回はなし ) 勉強会の申し込み⼀覧に型不⼀致filter / 破壊的sort / 改名漏れを仕込む

Slide 14

Slide 14 text

© 2026 Classmethod, Inc. 6 バグを3つ仕込んだコードに /code-review を実⾏した結果 仕込んでいたバグともう 1件が修正 --fixをつけていたからそのまま修正までされた 実行コマンド : /code-review --fix 変更をコミットする前に、見落としがないか /code-review で確かめましょう 勉強会の申し込み⼀覧に型不⼀致filter / 破壊的sort / 改名漏れを仕込む

Slide 15

Slide 15 text

© 2026 Classmethod, Inc. 7 あるある② 直しました!All Greenです → 動かない テストは通っているのに、画⾯は壊れている

Slide 16

Slide 16 text

© 2026 Classmethod, Inc. 8 想定外のバグにテストは反応しない なぜ起こる? • 思いつかなかったケースはテストにも書か れない • 「テスト全パス」は「アプリが動く」の証 明ではない • 型チェックもビルドも、実際に画⾯を開い た⼈の代わりにはならない /verify • 実アプリをビルド‧起動‧観察して、変更 が本当に動くかを確認する • テストや型チェックとは別レイヤの「実物 を⾒る」検証 • 画⾯のエラーやコンソールログまで実際に ⾒にいく • 起動⼿順をskillとして残す(こともある) 「直しました」という⾃⼰申告ではなく、動いている実物で判断することができる

Slide 17

Slide 17 text

© 2026 Classmethod, Inc. 9 テストは全部通るが、画⾯では完了トーストが被さっている状態 勉強会の申込フォーム。「申込む」を押すと完了トーストが画⾯下部に出る画⾯。 テストはpass。 しかし、テストに成功しても画⾯は壊れている。 ボタンの真上に黒いトーストが被さる。

Slide 18

Slide 18 text

© 2026 Classmethod, Inc. 9 実行コマンド : /verify ● git diff から検証対象の特定 ● 起動⼿順がないので、package.jsonを頼りに⾃ ⼒でdevサーバーを起動 ● ブラウザを⽴ち上げ、実際の画⾯を確認(コンソー ルも) テストは全部通るが、画⾯では完了トーストが被さっている状態 勉強会の申込フォーム。「申込む」を押すと完了トーストが画⾯下部に出る画⾯。

Slide 19

Slide 19 text

© 2026 Classmethod, Inc. 9 実行コマンド : /verify 判定結果は FAIL に 完了トーストが画⾯下部ではなくカード内に描画 され、申込ボタンを覆っていたことを読み取り、 修正案を提⽰ 「直しました」を信じる前に、 本当に動くか /verify で確かめましょう テストは全部通るが、画⾯では完了トーストが被さっている状態 勉強会の申込フォーム。「申込む」を押すと完了トーストが画⾯下部に出る画⾯。

Slide 20

Slide 20 text

© 2026 Classmethod, Inc. 10 あるある③ また同じことを説明している その指⽰をプロジェクト専⽤のskillにまとめてしまいたい でも、作り⽅もちゃんと効いているかの確かめ⽅も分からない

Slide 21

Slide 21 text

© 2026 Classmethod, Inc. 11 /skill-creator — ⾃分の基準をskillにして育てるskill skillの新規作成をガイド / 既存skillの改善 / 効果のA/B測定までやってくれる いつも⼿でやっている確認 devサーバーを起動して画⾯を開く 変えた箇所を実際にクリックする コンソールにエラーが出ていないか⾒る おかしければ直して、もう⼀度⾒る /skill-creator が skillにまとめる verify-frontend-change/SKILL.md --- description: UI変更は画面まで確認 --- 2. devサーバーを起動して画面を開く 3. 変えた箇所を実際にクリックする 4. コンソールにエラーが出ていないか確認する 5. 問題があれば直して、もう一度確認する 変えた箇所のコードを読み返す 1. 変えた箇所のコードを読み返す ⼀度書いておけば、次からはClaudeが同じ⼿順で確認してくれる

Slide 22

Slide 22 text

© 2026 Classmethod, Inc. 12 書いたskillの効果はA/Bテストで測れる evals.json 現実的なプロンプト2〜3個 サブエージェント A skillあり サブエージェント B skillなし 同⼀ターンで並列実⾏ grader 独⽴採点‧根拠の引⽤が必須 benchmark.md 平均点±ばらつき PASS / FAIL evals.json テストケース集 現実のユーザーが実際に⾔いそうなプロンプトを2〜3個書く サブエージェント A/B 同じプロンプトを「skillあり」「skillなし」で並列実⾏ 出⼒を保存する grader 2つの出⼒を採点する独⽴エージェント 採点には根拠の引⽤が必須 benchmark.md 採点の集計結果 平均点(mean)とばらつき(stddev)で、skillあり/なしの差が数字で⾒える

Slide 23

Slide 23 text

© 2026 Classmethod, Inc. 13 /skill-creator で作成されたskillの効果 評価をお願いすると、skillあり/なしでの評価レポートが作成される 今回の場合、skillあり/なしどちらとも、同じ⼿順、同じ修正にたどり着いた skillありのほうが実⾏時間が短く、トークン消費が多いことがレポートからわかる

Slide 24

Slide 24 text

© 2026 Classmethod, Inc. 13 /skill-creator で作成されたSKILL.md 「code-reviewとverifyを順に呼ぶskillを作って」と指⽰ 以後、「レビューして動作確認までして」という指⽰で ①レビュー修正 → ②実機確認 → ③FAILなら繰り返し が毎回同じ順で⾛る 今まで⾃分が繰り返し⾏っている指⽰を skillにしてみましょう

Slide 25

Slide 25 text

© 2026 Classmethod, Inc. 14 渡せる仕事はレビューと動作確認だけじゃない 今⽇渡したもの レビュー /code-review ⾒逃しを独⽴した⽬で潰す 動作確認 /verify 実物の画⾯で確かめる skillを作り育てる /skill-creator ⾃分の基準を書いて測る さらに渡せるもの 「終わった」の判定 /goal 条件を満たすまで回り続ける。判定は別の⼩型モデル 動き出すきっかけ /loop・/schedule 定期実⾏‧⾃⼰ペースで勝⼿に動き出す ⼤きな変更の分担 /batch 変更を分解してworktree隔離で並列実⾏ コードの整理 /simplify クリーンアップ専⽤レビューを4観点並列で ⼈の仕事をひとつずつ道具に置き換えることができる

Slide 26

Slide 26 text

© 2026 Classmethod, Inc. skillは繰り返しを構成する道具の⼀部 Claudeは何回も繰り返して動いている 状況を評価する ツールを実⾏ 結果を受け取る 完了まで繰り返す 「状況を評価 → ツールを実⾏ → 結果を⾒る」を 終わるまでぐるぐる繰り返す。 道具を作成し 繰り返しの作業を設計する側に回ること = Loop Engineering

Slide 27

Slide 27 text

© 2026 Classmethod, Inc. 16 みなさんも、明⽇から仕事を⼿放してみませんか? ⼿放す仕事 使うskill Claudeに渡すもの ⽇々の開発のレビューと動作確認 /code-review・/verify 検証 チームの基準‧⾃分のチェックリスト /skill-creator で書いて測る 基準そのもの 完了条件が明確な作業 /goal 終了判定 定期作業‧外部システム待ち /loop・/schedule きっかけ “My job is to write loops.” — Boris Cherny(Claude Code開発責任者) ⾃分の仕事はloopを書くことだ

Slide 28

Slide 28 text

© 2026 Classmethod, Inc.