■ 1. 概要
- スキル設計の本質は「AIへの仕事の任せ方の設計」である
- 「とりあえず動くスキル」と「安定して業務に組み込めるスキル」は別物
- 以下の4つのポイントを押さえることで、誰が実行しても期待した品質のアウトプットが安定して返りやすくなる
- 依頼内容を明確にする
- 誰に、どの単位で任せるかを決める
- 品質確認の仕組みを組み込む
- 仕事ぶりを評価して、次の任せ方に活かす
■ 2. ポイント1: 依頼内容を明確にする
- アウトプットの定義:
- フォーマット、粒度、含めるべき要素、含めてはいけない要素を具体化する
- AIが判断してよい範囲（責任の境界）を明確にする
- 意思決定（修正の採用可否、本番反映など）は人間が行う範囲として残す
- インプットの定義:
- アウトプット生成に必要な情報をすべて列挙する
- 業務知識やドメイン用語の補足、参照すべき既存ドキュメントやコード、過去事例と反例、守るべき制約やルールが含まれる
- 「人間に同じ仕事を頼むなら何を渡すか？」という問いで過不足を点検する
- 失敗パターンの兆候:
- AIが不足情報を推測で補完し始めた場合 → インプット定義の見直しが必要
- 実行ごとにアウトプットの構造や粒度が変わる場合 → アウトプット定義の曖昧さが原因の可能性がある
■ 3. ポイント2: 誰に、どの単位で任せるかを決める
- コンテキストウィンドウは有限であるため、情報量を見積もったうえで分担を設計する
- 判断軸は4つ:
- スクリプトへの切り出し:
- 日付計算、ファイルの存在チェック、フォーマット変換など決定的に実行できる処理はスクリプトに切り出す
- 曖昧さが入り込まないため結果が安定する
- 並列化（サブエージェント分業）:
- 情報量が多い場合や独立したサブタスクが複数ある場合はサブエージェントに分業させる
- 委譲プロンプトには「目的」「出力形式」「使用するツールと情報源の指針」「タスクの境界」の4要素を含める
- サブエージェントは毎回まっさらなコンテキストで起動するため、スキルの引き継ぎには skillsフィールドでの事前ロードか、委譲プロンプトへの明示が必要
- コンテキストの分割単位:
- 1回の呼び出しに入るインプットサイズを試算し、必要に応じて意味のある単位で分割する
- 分割の境界をサブエージェントの責任範囲と一致させると設計がシンプルになる
- ページ数ではなく機能単位で切ることで各サブエージェントがレビューを自身の担当範囲内で完結できる
- モデルの選択:
- 機械的な抽出や整形 → 軽量モデル（Haikuなど）
- 通常の設計や実装 → 標準モデル（Sonnetなど）
- 複雑な判断、横断的な統合 → 高性能モデル（Opusなど）
- 思い込みで固定せず、実際に複数モデルで試して決めることが確実
■ 4. ポイント3: 品質確認の仕組みを組み込む
- 一発生成では品質にばらつきが生まれるため、生成した成果物を確認・修正する仕組みをスキルに組み込む
- レビュー方法は2種類:
- セルフレビュー:
- 同じエージェントに続けてレビューを指示する方法
- 構成がシンプルでコストが低い
- 生成時と同じ文脈を引き継ぐため、見落としを見つけにくい場合がある
- クロスレビュー:
- 別のサブエージェント（別視点、別ペルソナ）にレビューさせる方法
- 多様な視点から確認できるため、品質重視のタスクに有効
- クロスレビューの実践例（並列レビュースキル）:
- チェックリスト検証担当: プロジェクトのレビューチェックリストと変更内容を項目単位で突き合わせる
- 実装検証担当: レイヤー構成、NULL安全性、コーディング規約に絞ってコードを確認する
- テスト観点検証担当: テストの網羅性、命名規則、ユビキタス言語の使用を検証する
- 既存コードとの一貫性検証担当: 既存の実装パターン・命名との整合性を確認する
- 不具合検出担当: diff内の情報のみから明らかなバグを検出する
- 委譲プロンプトには「役割（何を検証するか）」「参照するガイドライン」「タスクの手順」を明示する
- ペルソナと担当範囲を絞るほどレビューが深く掘り下げられる
■ 5. ポイント4: 仕事ぶりを評価して、次の任せ方に活かす
- 評価指標を決める:
- スキルごとに品質を測る評価指標を定義する
- 設計書生成スキルなら「観点の網羅率」「業務制約への準拠率」「再実行時のブレ幅」
- レビュー系スキルなら「指摘の真陽性率」「重大度判定の妥当性」
- Anthropicの公式ベストプラクティスも、スキルの中身を書く前にまず評価を作ること（evaluation-driven development）を推奨している
- 評価スキルを作る:
- 評価指標を機械的に評価するための評価スキルを別途用意する
- インプットは対象スキルのアウトプット、アウトプットは指標ごとのスコアと改善提案
- 人間によるレビューの代替ではなく、レビュー前のスクリーニングとして機能させる
- 改善の意思決定は人間に残す:
- 改善案を複数出させて人間が選ぶ
- AIに全自動でスキルを書き換えさせると改善の方向性が本来の目的からずれやすい
- Gotchasの蓄積:
- 改善ループや日々の運用で見つけた失敗パターンをスキルの注意書き（Gotchas）として蓄積する
- Claude Codeの開発チームもGotchasセクションが最もシグナルが高いと述べている
- 最初から完璧な指示を書くのではなく、運用しながら失敗を吸収してスキルを厚くする
■ 6. まとめ
- 4つのポイントはいずれも人に仕事を任せるときにも自然に行っていることと共通する
- AIを「仕事を任せる相手」と捉えて設計するだけで、スキルの再現性や改善のしやすさが大きく変わる
- AIに安心して任せられる仕事が増えるほど、人間は顧客の本質的な課題解決や高度な機能開発といった価値創造の仕事に集中できる