指示の自由度とは何ですか？なぜ同じタスクを常に同じ書き方で指示できないのですか？
指示の自由度とは、指示（1回限りのプロンプトであれ、Skillに書き込む説明であれ）を書く際に、Claudeにどれだけ明確で厳格な指示を与えるか、それとも大まかな方向性だけを与えて細部は自分で判断させるかを決めることを指す。これは直感で決めるものではなく、タスク自体の性質に対応させる必要がある。あるタスクには正しいやり方が1つしかなく、間違えると実際の悪影響が生じる（データベースの移行が特定の正確な順序で実行されなければならない場合など）。一方、あるタスクには同じように有効なやり方が多数あり、成功は異なる角度からもたらされうる（コードレビューでは、異なる視点からの精査がそれぞれ有効な問題を発見しうる）。
すべてのタスクを「詳細であればあるほど良い」という同じアプローチで指示すると、かえって問題が生じる。許容度の高いタスクを過度に厳格に書いてしまうと、Claudeがその場の状況に応じて柔軟に対応できなくなり、結果としてClaudeの判断に任せた場合よりも悪い結果になることが多い。許容度の低いタスクに漠然とした方向性しか与えなければ、ステップの見落としや順序の誤りによって実際の損害が生じるリスクがある。
指示の自由度はなぜ必要とされ、どんな問題を解決するのですか？
この概念を明確に意識していない場合、多くの人が指示やSkillを書く際に2つの極端に陥りやすい。1つは、どんなタスクであれ極めて詳細に書いてしまうことであり、結果として多大な労力をかけて書いた指示が、許容度の高いタスクに適用されるとかえってClaudeの手足を縛り、Claudeがもともと持っている判断能力を無駄にしてしまう。もう1つは、どんなタスクであれ簡潔な方向性しか与えないことであり、結果として本当に正確な手順が必要なタスクに適用されると、重要な段階が見落とされたり順序を誤ったりして、実際の損害を引き起こしてしまう。
指示の自由度という概念が解決するのは、まさに「どれくらい詳しく書くべきかをどう決めるか」という問題である。この概念は判断のための枠組みを提供する。書き手は書き始める前に、まず自分自身に「このタスクは複数のやり方がすべて成功とみなされる許容度を持つのか、それとも正しい道筋が1つしかないのか」を問いかけ、その答えに基づいて指示の具体性を決める。これにより、「どれくらい詳しく書くべきか」が直感による選択から、明確な判断基準に従える意思決定へと変わる。
指示の自由度は実際にどのように機能し、具体的にどんな段階に分かれるのですか？
この概念は通常3つの段階に分かれる。高い自由度は「複数のやり方がすべて有効で、判断が文脈に応じて調整される必要がある」タスクに適しており、書き方としては大まかな方向性を文章で説明するだけでよい。例えば「コードの構造を分析し、潜在的なバグをチェックし、可読性の改善案を出す」といった指示であり、チェックの順序を細かく指定する必要はない。中程度の自由度は「好ましいやり方はあるが、ある程度の変化は許容される」タスクに適しており、書き方としてはパラメータ付きのサンプルコードやプロセスを示し、ユーザーが状況に応じてパラメータを調整できるようにし、そのまま丸写しさせるものではない。低い自由度は「操作を誤りやすく、一貫性を維持しなければならない」タスクに適しており、書き方としては変更してはならないほど正確な具体的指示を与える必要がある。例えば「この正確なスクリプトを実行すること：python scripts/migrate.py --verify --backup、コマンドを変更したり、他のパラメータを追加したりしないこと」といった具合である。
どの段階を使うべきかを判断するには、次のような比喩が使える。Claudeが道を歩いていると想像してみるとよい。もしその道が崖沿いで通れる道が1つしかない狭い橋であれば、正確な手すりと指示を与える必要がある（低い自由度）。もしその道が開けて平坦で、どの方向に進んでも目的地にたどり着ける野原であれば、大まかな方向性だけを与え、自分で道を見つけさせる（高い自由度）。
指示の自由度は私にとって実際どんな意味があり、指示やSkillを書く際にどう実際に適用すればよいですか？
次に指示やSkillを書く前に、まず自分自身に1つの問いを投げかけてみるとよい。「もし2人がそれぞれこの説明に従って作業し、結果が異なった場合、どちらも合格と言えるか？」答えが「言える、要点さえ押さえていればよく、異なる切り口でも有効な場合がある」であれば、それは高い自由度のタスクであり、大まかな方向性だけを示せばよく、各ステップを固定して書き込む必要はない。答えが「言えない、正しいやり方は1つしかなく、ステップを間違えると実際に問題が生じる」であれば、それは低い自由度のタスクであり、各ステップを正確に、曖昧さを残さずに書くべきである。
実務上、1つのSkillの中に異なる自由度の内容が同時に含まれることはよくある。例えば全体のワークフローは高い自由度（Claudeに順序の判断を任せる）でよいが、その中のデータベース操作に関わる特定のステップは、低い自由度の正確な指示で書く必要がある、といった具合である。Skill全体を一律に同じ自由度で統一する必要はなく、それぞれの小さなタスクごとに個別に判断する方が、一律に同じスタイルを適用するよりも実際のニーズに近い指示を書けることが多い。
Anthropic公式のSkill作成ベストプラクティス文書では、データベースの移行を低い自由度の例として挙げている。「この正確なスクリプトを実行すること：python scripts/migrate.py --verify --backup。コマンドを変更したり、他のパラメータを追加したりしないこと」。そしてコードレビューを高い自由度の対照例として挙げ、前者は誤りへの許容度が低く正確な一貫性を維持しなければならないのに対し、後者は有効な切り口が複数あり、大まかな方向性だけを与えるのに適していることを強調している。
The advantage is that instruction specificity can precisely match a task's actual risk — error-tolerant tasks keep flexibility, error-prone tasks maintain consistency, avoiding the problems both extremes cause; the drawback is that it requires the author to spend time upfront judging which freedom level each task or sub-task falls into, adding a judgment step compared to the thoughtless approach of "always write it as detailed as possible."