【AI×DevOps Study #14】Claude CodeのSkillで開発体験を変える話

■AI×DevOps Study #14 の概要
2026年5月22日に開催した「AI×DevOps Study」第14回の発表資料です。

「AI×DevOps Study」は、AI駆動開発やそこに関係するマイクロサービスについて理解を深める場になります。
株式会社ScalarではAIを使ったチーム開発を進めており、参画しているメンバーや協力会社の方から、具体的なAI駆動開発を実施する方法、その中で生まれたマイクロサービスアーキテクチャを使用したAI駆動開発の事例や実際に使えるエージェントについてお話頂き、参加者の皆様と知識の共有や交換を目的としています。
（弊社製品であるScalarDBも絡んだお話も一部出てきますが、汎用的な内容となっておりますのでフラットにお楽しみいいただけます）

■今回のテーマ
「Claude CodeのSkillで開発体験を変える話」

Claude Codeを日々の開発に活用していると、こんな課題が出てきます。

「AIが設計書を作ってくれたけど、動作確認の準備は結局手作業」
「何をどう頼めばいいかわからなくて、毎回試行錯誤している」
「会話の中で積み上がったノウハウが、次のセッションで消えてしまう」
今回は、これらの課題を自作のSkillで解消した体験をお伝えします。

紹介するTipsは以下の3つです：

- generate-http-file：AI生成の設計書をそのまま動作確認ファイルに変換する仕組み
- prompt-helper：「何から頼むか」を4段階で判断し、最適なプロンプトを1つだけ返すSkill
- suggest-claude-md × フック：会話終了時に自動でナレッジを抽出し、CLAUDE.mdへの更新提案を生成する仕組み

SkillはMarkdownファイル1つで定義でき、.claude/skills/に配置するだけで動作します。 今回の内容を通じて、「同じ作業を繰り返さないためのAI活用」のヒントをお伝えいたします。

■登壇者情報（敬称略）
橋本康平
株式会社NewWizのバックエンドエンジニア。
PHP/Laravelでの開発経験を経て、2025年4月よりAI駆動開発を開始。 Claude Codeに移行後は、チーム開発におけるAI活用の課題解決に取り組み、Claude CodeのSkillsを活用した開発支援テンプレートを作成・運用中。 「AIと一緒に働く」環境をいかに整備するかをテーマに、日々実践と改善を重ねている。

■関連コンテンツ
・Youtube（過去の勉強会動画も公開中！）
www.youtube.com/@scalar-labs

・Zenn ブログ
https://zenn.dev/p/scalar_sol_blog

・イベントページ（connpass）
https://scalar.connpass.com/

Transcript

1. Claude Code 活⽤ Tips 2026/5/22 株式会社NewWiz 橋本 康平
2. 本⽇のアジェンダ • Tips ① generate-http-file ― 動作確認の⾃動⽣成 • Tips ② prompt-helper ― 「何から頼めばいいか」問題 • Tips ③ suggest-claude-md × フック ― 会話をナレッジに • Skill 設計の共通原則
3. Tips ① generate-http-file ― 動作確認ファイルの自動生成
4. 課題：API の動作確認、どうやってますか？ ed it_ no te Postman / curl を毎回⼿書き 正常系‧異常系‧バリデーション‧権限… テストデータも別途⽤意が必要 up da te _d isa bl ed 後回しになりがちな「別タスク」 実装後に改めて着⼿するため、 開発フローから切り離されやすい rul e 網羅性にバラつきが出る 「⼿動でOKだったから良いか」という 主観による妥協が発⽣しやすい pe rs on _o ff 属⼈化と新メンバーの負担 ノウハウが個⼈の⼿元に溜まり、 新メンバーが参画する際の障壁になる
5. AI駆動開発が動作確認を⼿軽なものに AI駆動開発によって設計書が構造化され、テキストベースの動作確認方法の有用性が上がりました。 観点 従来の設計書 AI駆動開発の設計書 フォーマット プロジェクト・人ごとにバラバラ 統一フォーマット 構造 自然文中心 リクエスト/エラー/フローが構造化 自動変換 困難 AI が読んで .http に変換可能 設計書品質 担当者依存 AI生成で均一化
6. STEP 01 検証項⽬の全洗い出 し 設計書からバリデーショ ン、エラーコード、権限分 岐まで網羅的に抽出しま す。 STEP 02 OpenAPI 仕様書と照 合 仕様書との抜け漏れや差異 を確認し、必要に応じて⾃ 動補完を⾏います。 STEP 03 テストデータ⽣成 DB 投⼊⽤の JSON 形式テ ストデータを同ディレクト リに⾃動⽣成します。 STEP 04 .http ファイル出⼒ 各リクエストに確認意図の コメントが付与された実⾏ 可能ファイルを出⼒しま す。 /generate-http-file の処理フロー
7. ⽣成物のポイント co m m en t 確認ポイントの明確化 各リクエストに「何を確認するか」のコメントを⾃ 動付与。意図の汲み取りが容易になります。 su m m ari ze テストデータのサマリー ファイル冒頭にサマリーを集約。誰がどのリソース にアクセス可能か⼀⽬で把握できます。 ter mi na l 優れた可搬性と実⾏環境 Gitでのバージョン管理が可能。VS Code REST Clientを⽤いて即座に実⾏できます。 tra ck _c ha ng es トレーサビリティの確保 設計書の仕様と⽣成されたテストコードの対応関係 を厳密に追跡可能です。
8. デモ：generate-http-file の実⾏
9. 結局なにが嬉しいか 設計書が完成した時点で、動作確認の準備が 8割終わっている状態になります。 Before After 実装後に動作確認ファイルを手書き 設計書完成と同時に準備が8割完了 テストケースの網羅性が担当者依存 設計書ベースで仕様を全カバー 「手動確認でOK」で終わることも 「設計通りか」を明示的に検証
10. 「毎回⼿で書く」 × 「⼊⼒は構造化されている」 ＝ Skill 化候補 候補例： 設計書を読みながら マイグレーションを 書いている テーブル定義を⾒ながら モック⽤ JSON を 書いている OpenAPI 仕様書から クライアントコードを 書いている ⼊⼒と出⼒の形が決まっている「変換作業」がねらい⽬ ⼀般化：Skill 化のねらい⽬はどこか
11. Tips ② prompt-helper ― 「何から頼めばいいか」問題
12. 課題：Skill が増えすぎ問題 プロジェクトの Skill は 20 種類超 設計 / 実装計画 / 実装 / テスト / レビュー … 充実しているのは良いが「で、今何を使う？」と迷う 新メンバーが最初につまずくのがここ 「直接話しかけていい？ Skill を呼ぶべき？」 「実装したいんだけど、 どの Skill から？」
13. /prompt-helper という解決策 コンセプト AI への頼み⽅を AI が教えてくれる 使い⽅ /prompt-helper を呼んで「何をした いか」を話す 内部判断 4つの観点で分析: • タスク種別 / 変更規模 • 品質要件 / 所要時間 出⼒ コピペして実⾏できるプロンプトを 1 つだけ 返す
14. 提案は 1 つだけ なぜ「1つ」なのか 選択肢は「迷い」を再⽣産する • 複数提案 → 「どれを使えばいい？」へ逆戻り 直接対話でも丁寧なプロンプトを⽣成 • どのファイルを⾒、どのツールを使うかを明⽰ • IDE 診断‧ファイル検索ツールの指⽰も包含 曖昧さを排除し、AIが⾃律的に動ける具体的なコンテキストを提供します。
15. デモ：prompt-helper の実⾏
16. 「毎回同じ説明をしている」 × 「判断基準がある」 ＝ Skill 化候補 候補例： オンボーディング資料で 説明している判断フロー 「こういう時はどうする？」 と頻繁に聞かれる選択 README の 「ユースケース別の使い⽅」 判断ロジックをドキュメントに書いたら、そのまま Skill の指⽰書になる ⼀般化：判断ロジック⾃体を Skill 化する
17. Tips ③ suggest-claude-md × フック ― 会話がナレッジになる
18. 課題：ナレッジは会話に埋もれる Slack のやりとりに埋もれて発掘困難 「このプロジェクトではこうする」という判断が会話の中で⽣まれる (バグの原因究明、設計の決め事、命名の理由) セッションが終わると消える コンテキストはリセットされ、積み上がらないため共有されない CLAUDE.md や ルール に書けばよいが、⼿動更新は続かない
19. STEP 01 フック起動 SessionEnd / PreCompact フックでシェルスクリプト が起動 STEP 02 AI分析 Haiku が会話トランスクリ プトを分析 （3パターンに絞る） STEP 03 提案蓄積 指定されたディレクトリに 提案ファイルを蓄積 STEP 04 ⼈間が反映 ⼈間がレビューして /apply-suggestions で CLAUDE.md に反映 /suggest-claude-md × フックの処理フロー
20. 提案するのは 3 パターンだけ 何でも提案するわけではありません。 ノイズを出さないために、ルール化に値する 3条件だけに絞っています。 パターン トリガー条件 ナレッジ化する理由 独自ルール 「〜ではなくこっちを使って」という指摘 ルールとして文書化すべき内容が出た 繰り返し指摘 同じ修正指示が 2 回以上発生 ルールが書かれていない証拠 関連箇所の統一 「こことここは同じように」という指示 パターンとして横展開できる
21. モデル選択：⽤途で使い分ける このフックは Haiku を指定しています。 判断内容がシンプルなので高性能モデルは不要で、コストを抑えられます。 モデル 使う場面 コスト感 Haiku 定型処理・テンプレート生成・フォーマット整形 低 Sonnet 設計分析・ドキュメント生成・コードレビュー 中 Opus アーキテクチャ判断・複数選択肢からの最適解導出 高
22. 01. ⼈間中⼼のプロセス AIが提案し、⼈間がレビュー。 `/apply-suggestions` で初めて反映 される仕組みです。 02. 勝⼿な書き換え禁⽌ CLAUDE.md などの重要ファイルを AIが⾃動で書き換えることはありま せん。 03. 履歴の蓄積と可視化 ⽇付付きファイルとして蓄積される ため、後から意思決定の経緯を振り 返れます。 「あの時何決めたっけ？」を解消しま す。 「提案に留める」ことで、⼼理的な導⼊ハードルを劇的に下げます 提案は⾃動適⽤しない
23. デモ：フック動作と提案ファイル
24. 「やった⽅がいい」 × 「誰もやらない」 ＝ フック化候補 「⾯倒で誰もやらない」→「⾃動で動くから誰もやらなくていい」 ⼀般化：判断ロジック⾃体を Skill 化する 時間不⾜の解消 ふりかえりで「やりたいけど時間が ない」と毎回⾔う作業 曖昧タスクの定着 「気づいたら誰かが書いておく」な曖 昧タスク トリガーの創出 定期的にやれば効果があるが、トリ ガーがない作業
25. Skill 設計の共通原則 3つの事例から抽出するコツ
26. 理想的なプロセス：⼈間中⼼のサイクル AI の提案 → ⼈間の承認 → 反映 report_problem導⼊の最⼤の壁 AI が勝⼿に変なことをしないかという不安。 これが⾃動化への最⼤の⼼理的ハードルとなり ます。 trending_up段階的なアプローチ • 提案に留めることで導⼊ハードルを下げる • 信頼の蓄積に合わせて、徐々に⾃動化の範囲 を拡⼤する 原則① ⾃動適⽤しない、提案にとどめる
27. 出⼒だけでなく「なぜそうなのか」を⼀緒に出させる code 具体的な活⽤例 .http のコメント： 「処理の流れ / 期待レスポンス」 提案ファイル： 「理由：繰り返し指⽰（3回）」 verified_user 導⼊のメリット 根拠が⾒えるとレビューも信頼も成⽴する lightbulb 設計のポイント AIに「なぜそう判断したのか」の思考プロセスを⾔語化させることで、アウトプットの妥当性を⼈ 間が容易に検証可能になります。 原則② 出⼒の理由を含めさせる
28. ⼀気に答えを出させるより、段階的に絞り込む⽅が精度が向上します cancel避けるべき指⽰ 「最終出⼒を出して」 プロンプトが抽象的すぎると、AIは意図を汲み取れず精 度が落ちます。 check_circle推奨される指⽰ 「まず確認 → 次に抽出 → 最後にこの形式で出⼒」 思考のステップを明⽰することで、各⼯程の確実性を⾼めます。 psychologySkill 指⽰書への適⽤ 複雑なタスクは、常にステップを分解して記述することを意識しましょう。 原則③ 段階的に詳細化する
29. Skillはマークダウン1枚から。完成度より「まず動くこと」を最優先する description 始めやすさの理由 .claude/skills/ にmdファイルを1枚置くだけで即座 に動作します。 trending_up 改善のサイクル 最初から完璧を⽬指さず、まずは動かして実務の中 で改善を繰り返します。 edit_note 実践の第⼀歩 「3回以上やっている作業」を1つ選び、その⼿順をmdファイルに書き出してみましょう。 原則④ まずは⼩さく作る
30. 今⽇のまとめ 共通しているのは「AIを組み込む」発想。 一度仕組みを作れば、開発するたびに資産が増えていきます。 Tips 一言で言うと 持ち帰り generate-http-file 設計と動作確認は同時並行できる 動作確認の手書きをやめる prompt-helper 入口の迷いを構造的に消す 判断ロジック自体を Skill 化 suggest-claude-md × フック 意識せずドキュメントが育つ やらない作業をフックで自動化 共通原則 AI を「組み込む」という発想 まず md 1 枚で小さく始める