Claude Code Skillsのブレを設計で減らしたい

同内容で詳細化されたものはZennにあります。
https://zenn.dev/akari1106/articles/dfd7e3650e15ff

Transcript

1. Claude Code Skillsのブレを設計で減らしたい ステップ別制約設計
2. ©Algomatic ©Algomatic 2 ファシリテーター 自己紹介 経歴 • 経歴を3行で書けと言われて無理だった人。 • webマ→CRM→AI/DXと渡り歩いて9年。 • 道中でセキュリティ畑に居て今は元ISMSだった 知見を活かしつつ。 • 今はAI関連の研修設計とエージェント開発。 • ずっと「なんとかしてほしい」をなんとかする 係。 • Zennとdev(日/英)で趣味の技術発信。 Tw:灯里
3. 3 Agenda Content 01 Skillsのブレ、なぜ起きる？ 手順書文化とLLMの相性問題 02 ステップ別に"型"を選ぶ 4つの制約の型と実践 03 なぜ型を使うのかと限界とか 作業指示の原則がそのまま効く
4. ©Algomatic Skillsのブレ、なぜ起きる？ 4
5. ©Algomatic ©Algomatic 5 Skillは便利だが、毎回微妙に違う結果が返る 公式の Degrees of Freedom は方向性は正しい Skill全体の自由度をHigh/Medium/Lowで選ぶ指針がある。 でも実運用では「効くSkilsl」と「ブレるSkilsl」が出る。 ▼書き方 テキストベースの指示 High 複数のアプローチが有効 コンテキスト依存 ▼書き方 擬似コード パラメータ付きスクリプト Medium 推奨パターンはあるが 多少の変動はOK ▼書き方 具体的なスクリプト パラメータ少 Low 操作が壊れやすく 一貫性が必須
6. 6 「Skills全体」で自由度を選ぶだけでは足りない 初期のそれっぽいものを作ってくれるSkills 初期に作ってくれるSkills 困るポイント 何を根拠に絞るの？ → LLMの気分次第 「1つのツールに 絞って推奨する」 精度は？期間は？ フォーマットは？ → 毎回変わる 「ROI試算を計算 する」 分量だけ指定で 品質基準がない 「A4で5枚程度に 収める」 やり取りが増える＝トークンが増える＝時間がかかる
7. 7 日本人が使うと手順書文化がそのままSkillsに持ち込まれがち 「水槽温度の適正を確認する」 「水槽Aは60°Cより低くない」 • 現場が「適正」を知ってる前提。暗黙知への 信頼。LLMにはこの暗黙知がない。日本はこれ が多い。 • 誰がやっても同じ判断ができる。基準の明文 化。LLMとの相性が良い。人種のるつぼと言わ れるくらいなのもある。 日本式 (HOW) 英語圏式 (WHAT) 出典：飯野謙次「仕事が速いのにミスしない人は、何をしているのか？」 具体的な品質基準を知らないのでAIがHOWで埋めるしかない
8. ©Algomatic ©Algomatic 8 手順型100%は、LLMの気分次第になる テスト仕様書と同じ。基準なし = 思考コスト発生 = ブレ 「ログイン機能を確認する」→ 何をもってOK？ → 担当者の判断次第。 「正しいID/PWで200が返る」→ 誰がやっても同じ判定。Skillも同じ。 ログイン機能を確認する 正しいID/PWで200が返る
9. ©Algomatic ステップ別に "型"を選ぶ 9
10. 10 4つの「制約の型」 ⼿順型 (HOW) デプロイ⼿順 Git操作フロー 「この順番でやってくれ」を伝える型。 ⼿順だけ書いて判断基準を書かないと、ステップの中⾝は LLMの⾃由裁量。修正が増える、やり取りが増える、という 理由で、開発における定型作業など、⼀部のプロセス向き。 基準型 (WHAT) コードレビューの判断基準 ⽂章の品質基準 「この⽔準を満たしてくれ」を伝える型。 HOWではなくWHATを書く。達成すべき基準を明⽰する。 Claudeは基準さえ明確なら勝⼿にたどり着いてくれます。 まだやんちゃする時もあるので、⼿順も場合によって記載。 テンプレート型 PR作成テンプレート レポートの構造 「この形で出⼒してくれ」を伝える型。 構造は固定しつつ、内容の⾃由度は残す。 公式は「Skill全体をstrictにするかflexibleにするか」という ⼆択。「このステップの出⼒だけstrictに」ではない。 ガードレール型 セキュリティの⼀次 チェック 公開前の⼀次レビュー 「これだけは絶対やるな」を伝える型。 禁⽌事項で境界を定義します。envなんかもですがあわせ て。他のLLMモデルとは一線を画している気がします。 まだ甘い部分もありますが、体感として 。 ステップごとの制約を設計するにあたり、4つの型に分類 ファイル変換の⼿順 数値計算の精度/ フォーマット 資料作成の⾃動化 センシティブな情報の 取り扱い
11. ©Algomatic ©Algomatic 11 同じSkillの中で型を混ぜる 型はSkill全体に1つ選ばず、ステップごとに選ぶ ⼿順型100％ ステップごとに型を選択
12. ©Algomatic なぜ型を使うのかと限界とか 12
13. ©Algomatic ©Algomatic 13 AgentTeamsや並列も視野にいれる Agent Teamsや並列で使うなら、なおさら 手順型100%のSkillを5体のエージェントに渡すと、5通りの解釈が返ってきます。基準型で判断軸を固定し、テンプ レート型で出力形式を揃えておけば、人間が見なくても「だいたい同じ水準」に着地してくれる。 複数の解釈も視点が欲しいが、この観点で見てほしい、そして人間が見やすい形でという人間側のわがままです。 何匹くらい動かしてる？ • タスクや個々⼈の管理可能量によります が、この下にAgent Teamsを起動でさら に何匹かという感じ。 • 並列派とAgent Teams中⼼型と結構分か れている印象があります。
14. ©Algomatic ©Algomatic 14 何を縛って何を任せるかを意図的に設計する 制約 + エスカレーション設計で品質安定を目指す Skillの品質を安定させるための3つのポイント。 ブレは「設計変数」 ゆらぎではなく、コントロール する対象。排除ではなく意図的 に設計する。 制約の型は4つ 手順型・基準型・テンプレート 型・ガードレール型。タスクの 性質で選ぶ。 人間と同じエスカレーション式 Agent Teamsの場合は、該当の エージェントまたはリーダーに 判断を仰ぐことに。 confidential
15. ©Algomatic ©Algomatic 制約は「絶対に守れ」ではなく 「デフォルトはこれ、外れるなら 相談しろ」という設計にしてお く。人間のチームでも同じ。 15 メリットもあればデメリットもある 考え方の限界と補足 Skillsの品質を安定させるための3つのポイント。 過剰制約で柔軟性を失うリスク 基準型で「3軸で評価しろ」と ガチガチにすると、明らかに4 軸目が重要な案件が来たときに 破綻する。 制約の精度は書き手の腕次第 基準型で「3年間のTCOベー ス」と書いても、その基準自体 が的外れだったら、的外れな方 向に一直線に収束する LLMのためではなく人間のため LLMに見えているのは「指示の 具体性」だけというのを理解す る。 confidential Skillsの定義は要件定義と同じ。 時代が進んでツールが進化して も、「何を・どの水準で・何を基 準に」を設計する力は人間側に求 められる。語彙力と知識力大事。 「このステップ、どう書こう？」 と迷ったとき、「ここは基準型で 書くべきだな」と判断するための メンタルモデル。LLMの内部処理 を変えるものではないです。
16. ©Algomatic ©Algomatic 16 本当にいいの？ /insightsの記録で見せられるところの一部ですが タスクによりますが、初期よりかなSkills起動したあとのブレや品質という観点でのフラストレーションは減った体 感です。特に並列やAgent Teams起動しての人間側の確認の時の「うーん…」が減った印象です。 ちょっと試してみるか、でぜひぜひ。 /insightsコマンドって何？ 何がわかる？ ・プロジェクト領域：よく作業している分野 ・インタラクションパターン：どんな作業が多いか ・摩擦点：改善の余地がある箇所
17. ©Algomatic ©Algomatic 17 一緒に働きませんか AIと人の接点を設計しています 人とAIの関係性を良好にするために奮闘している部署にいます。興味があればぜひ。 今やっていること 企業向けAI研修の設計と登壇、AIエー ジェントのPoC開発、顧客の開発チーム 立ち上げ支援。セキュリティ設計込みで 伴走しています。 これから作りたいもの 「人がよりよい形で向き合えるAI」設計 で事業を作っていくフェーズです。プロ ダクトや研修など「人」中心の観点で す。 こういう人を求めてます AIを楽しみつつも、技術とリスクを考え て、完璧じゃなくていいので、一緒に走 れる方を探しています。セキュリティの 話が出来る人は個人的でも大歓迎です。 本当に。 confidential