Claude Code Skillの出力に「そうじゃない」を減らす、ステップ別制約設計

はじめに

Claude Code の Skill、使ってますか。というかZennに来る人で、この記事を読んでいるような層は日々使っているのだろう、そう思っています。実体は知りませんが。

自分でSkillを書いたり、コミュニティのSkillを試したりしていると、「効くSkill」と「なんかブレるSkill」があることに気づきます。同じSkillを同じ入力で実行しても、毎回微妙に違う結果が返ってくる。まあ、LLMだし、とそういわれれば、そう。

ですがこれ、Skillの「品質が低い」のとはちょっと違うと思ってます。

Anthropic公式のSkill Creator（Skillを作るためのSkill）には、“Set Appropriate Degrees of Freedom”（適切な自由度を設定せよ）というガイドラインがあります。Skill全体の自由度を High / Medium / Low の3段階で選べ、という考え方。

これ自体は正しい。ただ、実際にSkillを運用してみて思ったのは、Skill全体に一律で自由度を設定するだけだと、まだブレるということでした。というか、お願いするタスクの中でのSkillの利用を考えると「ここはLLMの良さとしての柔軟さをしても良い、だけどここはあんまりハルシネーションやLLMっぽい動きをしてほしくない」ってのがあります。 Step by StepのStep3は調査系だから広く見てほしい、けど要約や、コーディングの時はこの要素を落としてほしくない、というやつ。（これが現役の特にシニアエンジニアたちが、日夜AIと大喧嘩してストレスをためている理由だと思います）

この記事では、公式のガイドラインを出発点に、「ステップごとに制約の強度を変える」という設計思想について書きます。

公式が言っている「Degrees of Freedom」

まず、Anthropicが公式の Skill Creator で何を言っているかを確認します。

公式のSKILL.mdにはこうあります：

Match the level of specificity to the task’s fragility and variability.

つまり、タスクの壊れやすさと変動性に応じて、具体性のレベルを合わせろと。

具体的には3段階：

自由度	いつ使うか	書き方
High	複数のアプローチが有効、コンテキスト依存	テキストベースの指示
Medium	推奨パターンはあるが多少の変動はOK	擬似コード、パラメータ付きスクリプト
Low	操作が壊れやすく一貫性が必須	具体的なスクリプト、パラメータ少

Think of Claude as exploring a path: a narrow bridge with cliffs needs specific guardrails (low freedom), while an open field allows many routes (high freedom).

比喩としてはわかりやすいし、方向性は完全に正しいと思います。

ただ、ここで終わると問題が起きる。

「Skill全体」で自由度を選ぶだけでは足りない

公式のガイドラインは、Skill全体の自由度を1つ選ぶ設計になっています。

でも実際のSkillって、1つのタスクの中に「発散してほしい箇所」と「収束してほしい箇所」が混在していませんか？

たとえば、こういうSkillを見たことがあります（実際のSkillを元にした例）：

### Step 5: 推奨案を決める
- 1つのツールに絞って推奨する

### Step 6: ROI試算を計算する
- コスト削減効果を試算する
- 投資回収期間を示す

### Step 7: 提案書としてまとめる
- エグゼクティブサマリーを書く
- 全体をA4で5枚程度に収める

これ、全ステップが手順の列挙で書かれています。 Step式で良いですよね。何をやるか、がAIにもわかりやすい。「何をやるか」は書いてあるけど、「どの水準で」「何を基準に」がない。

結果どうなるかというと：

「1つのツールに絞って推奨する」→ 何を根拠に絞るの？ LLMの気分次第
「ROI試算を計算する」→ 精度は？期間は？フォーマットは？ 毎回変わる
「A4で5枚程度に収める」→ 分量だけ指定で品質基準がない

これ、Skill全体の自由度をHighにしてもLowにしても解決しないんですよ。問題は、各ステップが必要としている制約の種類と強度がバラバラなのに、全部同じ書き方（手順列挙）で書いてしまっていること。

これでも動くよ。仕事は回るよ、でもまあ、これをするとやり取りが増える＝トークンが増える＝時間がかかるなんですよね。

「ブレたら修正ループを回せばいい」という考え方もあります。 Agentic AIの流れ的にはそっちが主流かもしれません。ただ個人的には、修正ループの回数は少ない方がいい派です。サブスク式で一定量は使い放題とはいえ、実際にはレートリミットという上限がかけられています。修正ループを回すたびにトークンを消費して、気づいたら上限に当たって作業が止まる、という経験をした人も少なくないのでは。

なので「修正ループも回すけど、初手の設計で回数を最小化する」が、私のスタンスです。制約設計はその初手の精度を上げるための投資だと思っています。

ブレは「バグ」ではなく「設計変数」

ここで発想を変えます。

LLMの出力のばらつき（＝ブレ）は、排除すべきバグではなく、意図的にコントロールすべき設計変数です。そもそもLLM自体が推論して、それっぽいものを出す、なので愛すべきブレ、と許容できないブレが混在すると思ってます。

あるステップではブレてほしい。調査フェーズで「幅広く拾ってくれ」と思うのは当然です。別のステップではブレてほしくない。ROIの計算で毎回違う軸で試算されたら困る。

つまり必要なのは、Skill内の各ステップで、どこに自由度を残し、どこを固定するかを意図的に設計することです。

4つの「制約の型」

ステップごとの制約を設計するにあたり、私は4つの型に分類しています。

型	用途	制約の強さ
手順型 (HOW)	順序が決まった定型作業	中（手順は固定、判断は自由）
基準型 (WHAT)	品質・判断が重要なタスク	強（基準値・判断軸を明示）
テンプレート型	出力形式が決まったもの	中〜強（構造固定、内容は自由）
ガードレール型	やってはいけないことが重要	強（禁止事項で境界を定義）

手順型 (HOW)

「この順番でやってくれ」を伝える型。多くのSkillがこの型だけで書かれています。

手順型自体は悪くないです。特に「順番が重要な定型作業」では最適。ただし、手順だけ書いて判断基準を書かないと、ステップの中身はLLMの自由裁量になります。これで修正が増える、やり取りが増える、という理由で、開発における定型作業など、一部のプロセスにはこの型が適しています。

向いてるケース：

デプロイ手順
Git操作フロー
ファイル変換の手順

基準型 (WHAT)

「この水準を満たしてくれ」を伝える型。ブレを最も抑えたいステップに使います。

HOWではなくWHATを書く。手順は書かず、達成すべき基準を明示する。Claudeは手順を自分で考えられるので、基準さえ明確なら勝手にたどり着いてくれます。いい子だね、本当に。

向いてるケース：

コードレビューの判断基準
文章の品質基準
数値計算の精度・フォーマット

テンプレート型

「この形で出力してくれ」を伝える型。構造は固定しつつ、内容の自由度は残します。

公式のoutput-patterns.mdでも strict と flexible の2つのパターンが紹介されています。ただ公式は「Skill全体をstrictにするかflexibleにするか」という二択で、「このステップの出力だけstrictに」という考え方ではないです。

向いてるケース：

議事録のフォーマット
PR作成テンプレート
レポートの構造

ガードレール型

「これだけは絶対やるな」を伝える型。禁止事項で境界を定義します。

手順を書かず、基準も書かず、やってはいけないことだけを書く。意外とこれが効く場面は多いです。特にClaudeとClaudeCodeは、親元のAnthropicが安全意識で米国と喧嘩するくらいなので、他のLLMモデルとは一線を画している気がします。まだ甘い部分もありますが、体感として、ですが。ガードレール系を明示的に書く前に提案してくる事が多い気がします。

向いてるケース：

セキュリティチェック
公開前レビュー
センシティブな情報の取り扱い

同じSkillの中で型を混ぜる

ここが一番重要なポイントです。

型はSkill全体に1つ選ぶものではなく、ステップごとに選ぶものです。

先ほどの提案書Skillを、型を混ぜて書き直してみます。

Before: 手順型100%（ブレる）

### Step 1: 市場調査
- 競合ツールを調査する
- 主要3-5つのツールの特徴を比較する

### Step 2: 推奨案を決める
- 1つのツールに絞って推奨する

### Step 3: ROI試算を計算する
- コスト削減効果を試算する
- 投資回収期間を示す

### Step 4: 提案書としてまとめる
- エグゼクティブサマリーを書く
- 全体をA4で5枚程度に収める

After: ステップごとに型を選択（ブレにくい）

### Step 1: 市場調査 ← 手順型（発散OK）
- 対象カテゴリのツールを幅広く調査する
- Gartner、G2、Reddit等の複数ソースから情報収集する。その際情報ソースは必ず明記すること。

### Step 2: 推奨案を決める ← 基準型（収束させる）
- 以下の3軸で評価し、総合スコアが最も高いものを推奨する
  - 導入コスト（初期費用 + 年間ランニング）
  - 既存システムとの統合容易性（API有無、認証方式）
  - チーム内の学習コスト（ドキュメント充実度、日本語対応）
- 推奨理由は上記3軸それぞれについて記述すること

### Step 3: ROI試算 ← 基準型（数値はブレさせない）
- 3年間のTCOベースで算出する
- 定量効果は以下の3軸で算出する
  - 時間削減（人時/月）
  - コスト削減（円/月）
  - エラー率低減（%）
- 投資回収期間は月単位で表記する
- 根拠となった仮説や数字をテキストとして表示すること

### Step 4: 提案書フォーマット ← テンプレート型（形を固定）
以下の構造で出力する：
1. エグゼクティブサマリー（200字以内、結論→理由→効果の順）
2. 現状の課題（箇条書き3点以内）
3. 推奨ソリューション（Step 2の評価結果を表で）
4. ROI試算（Step 3の結果を表で）
5. 導入ロードマップ（3ヶ月スパンのガントチャート形式）

### 全体のガードレール ← ガードレール型（やってはいけないこと）
- 未検証の数値を「推定」の注記なしに記載しない。推定の場合は必ず、推定であることを明記。
- 特定ベンダーの宣伝資料の数値をそのまま使わない
- 社内の機密情報（プロジェクトコード名等）を含めない

### 制約の運用 ← エスカレーション設計
- 上記の基準で対応が難しい場合は、理由とともに代替案を提案すること
- Agent Teamsの場合は、該当のエージェントまたはリーダーに判断を仰ぐこと

同じ「提案書を作る」というSkillでも、各ステップの制約の型が違うのがわかると思います。

Step 1（調査） → 手順型。発散してほしいから緩く
Step 2（推奨） → 基準型。判断軸を3つ明示して収束させる
Step 3（ROI） → 基準型。数値フォーマットを固定してブレさせない
Step 4（出力） → テンプレート型。構造を固定して形を揃える
全体 → ガードレール型。やってはいけないことを境界として定義

ブレやすいSkillのアンチパターン

最後に、ブレやすいSkillに共通するアンチパターンをまとめておきます。これは自分の初期のSkill構築、他者作成のSkillで「うーん」となったところです。自分のSkillを見直すときのチェックリストとして使ってます。

1. 手順型100%、基準型0%

全ステップが「〜する」の列挙だけ。やることは書いてあるが、どの水準で・何を基準にやるかが未定義。

# NG
- ROI試算を計算する
- 投資回収期間を示す

# OK
- ROI試算は3年間のTCOベースで算出する
- 定量効果は「時間削減」「コスト削減」「エラー率低減」の3軸で算出する
- 投資回収期間は月単位で表記する

2. 判断基準なしの選択指示

「1つ選べ」と指示しているのに、何を根拠に選ぶかが書かれていない。 LLMは律儀に1つ選んでくれますが、根拠はLLMの気分次第。

# NG
- 最適なツールを1つ推奨する

# OK
- コスト・統合性・学習コストの3軸で評価し、総合スコアが最も高いものを推奨する

3. 分量だけ指定で品質基準なし

「A4で5枚程度」は分量の指定であって品質の指定ではありません。 5枚に収まったけど中身がスカスカ、ということが普通に起きます。文字量だけはあるから、一見良さそうに見えてしまう、という事象が起きます。

# NG
- 全体をA4で5枚程度に収める

# OK
- エグゼクティブサマリーは200字以内、結論→理由→効果の順で記述する
- 各セクションは必ず根拠データを1つ以上含めること

Agent Teamsで使うなら、なおさら

最近はClaude CodeのAgent Teams機能で、複数のエージェントにSkillを使わせて並列作業させることも増えてきました。

この文脈で思うのは、ステップごとの制約設計は、チーム運用でこそ効いてくるということです。

1人のClaudeに1つのSkillを実行させるだけなら、出力がブレても人間が「いや、そうじゃなくて」と軌道修正できます。でもAgent Teamsで複数のエージェントが同じSkillを使って並列に動いている場合、全員の出力をリアルタイムで監視するのは現実的じゃない。ある程度見守りも兼ねているので、まだなんとかですが、人間側の許容を超えると見てられないのが正直なところです。ようは、タスクの指示をしたらなんか上手いこと勝手にやってほしい、という話なので、極力見守りママをしなくても、ある程度自分の理想に近いものが欲しい、という欲ですね。

手順型100%のSkillを5体のエージェントに渡すと、5通りの解釈が返ってきます。基準型で判断軸を固定し、テンプレート型で出力形式を揃えておけば、人間が見なくても「だいたい同じ水準」に着地してくれる。複数の解釈も視点が欲しいが、この観点で見てほしい、そして人間が見やすい形でね、というわがままですね。

つまり制約設計は、人間の監視コストを下げるための設計でもあるんですよね。

「Claudeを信頼して任せたい。でもブレは困る」という、実運用のジレンマに対する回答が、ステップごとの制約設計だと思っています。

この考え方の限界と補足

ここまで書いてきたけど、万能ではないです。せっかくClaude Code本人（本AI？）がいるので、当事者に反証チェックしてもらいました。

過剰制約で柔軟性を失うリスク

基準型で「3軸で評価しろ」とガチガチにすると、明らかに4軸目が重要な案件が来たときに、制約を守って無視するか、破って追加するかの判断が発生します。

これに対する対策は、エスカレーション設計をSkillに組み込んでおくこと。

## 制約の運用
- 上記の基準で対応できない場合は、理由とともに代替案を提案すること
- Agent Teamsの場合は、該当のエージェントまたはリーダーに判断を仰ぐこと

制約は「絶対に守れ」ではなく「デフォルトはこれ、外れるなら相談しろ」という設計にしておく。人間のチームでも同じですよね。

制約の精度は書き手の腕次第

基準型で「3年間のTCOベース」と書いても、その基準自体が的外れだったら、的外れな方向に一直線に収束するだけです。手順型で曖昧にしておいた方が、LLMの裁量でたまたま良い結果になるケースすらある。

結局、Skill定義は要件定義と同じです。時代が進んでツールが進化しても、「何を・どの水準で・何を基準に」を設計する力は人間側に求められる。ここは変わらないですね。「顧客が本当に必要だったもの」に向き合うことは、未来の自分にとっても必要なことかな、と思います。 ITビジネスやサービスデザイン、プロダクト開発における多難なプロジェクトの実体験や、よく起こりうる事態を強烈に風刺した絵です、ご興味あればぜひググって、あるあるとなろう。最近の若い子は知らないみたいなので。

「型」はLLMのためではなく人間のため

正直に言うと、LLM側は「手順型」「基準型」という分類を認識していません。LLMに見えているのは「指示の具体性」だけです。

この4つの型は、人間がSkillを設計するときの思考フレームワークです。「このステップ、どう書こう？」と迷ったとき、「ここは基準型で書くべきだな」と判断するためのメンタルモデル。LLMの内部処理を変えるものではないです。

ただ、結果的に「基準型で書く」と決めることで指示の具体性が上がり、LLMの出力が安定する。フレームワークとしての実用性はそこにあります。

まとめ

Anthropic公式の “Degrees of Freedom” は正しい方向性。
ただし、Skill全体で1段階の自由度を選ぶだけでは、実用上ブレが残る
LLMのブレは「バグ」ではなく 「設計変数」 。
排除するのではなく、ステップごとにコントロールする
制約には 手順型・基準型・テンプレート型・ガードレール型 の4つの型がある
型はSkill全体に1つではなく、ステップごとに選ぶ 。発散させたい箇所は緩く、収束させたい箇所はガチガチに

Claudeは賢いです。でもまだやんちゃな後輩要素もあります。手順を並べなくても、基準さえ明確なら自分で考えて良い結果を出してくれます。

だからこそ、何を縛って何を任せるかを意図的に設計することが、Skillの品質を安定させる鍵になるのだと思います。

参考

Anthropic公式 Skill Creator — “Set Appropriate Degrees of Freedom” セクション
Claude Skills: The Controllability Problem — Skill発火の非決定性についての分析
Prompt Engineering Guide (Lakera) — “Clarity = reducing degrees of freedom”
7 Prompt Engineering Tricks to Mitigate Hallucinations — 制約によるハルシネーション抑制