ガイド

著者 Matt Connor 2026-08-22 ・更新日 2026-08-25

unlazy skillのDepth Treeとは？導入方法と深さのコスト

Q: unlazy をインストールしても agent が早期に停止するのはなぜですか？

4 点を確認してください。まず ls ~/.claude/skills/unlazy/SKILL.md でスキルがディスク上にあることを確認します。存在しないディレクトリに clone したことが、よくある見落としです。次に、作業開始前に gates file が作成されたことを確認します。hook は gates file をスキャンするため、GATES.md が存在しなければブロックする対象がありません。3 つ目に、hook のインストール先を確認します。通常の install-hooks.mjs 実行では、このプロジェクトの settings.local.json にだけ書き込みます。別のプロジェクトでは --global が必要です。4 つ目に、release valve は仕様どおりに動作していることを覚えておいてください。gate の進展がないまま 6 回連続で停止をブロックすると、agent は警告を出して続行できます。また、ABANDON: 行があると、意図したとおり試行を終了します。

unlazy skillがエージェントの早期完了を防ぐ仕組みを解説します。Depth Tree、gatesファイル、PLAN.md契約、version 2.0.0の導入手順と深さごとのコストを確認できます。

unlazy skill の機能

unlazy skill は、コーディングエージェントが作業完了前に完了したと報告する問題を防ぐために作られたエージェント skill です。中核となるのは Depth Tree です。これはタスクを複数の層に分け、最下層だけを実作業として扱う手法です。Version 2 では、強制の仕組みを文章からファイルへ移しました。これにより、エージェントは完了したと主張するのではなく、実行可能なコマンドの一覧に対して完了を証明する必要があります。

これは Leonxlnx が github.com/Leonxlnx/unlazy で MIT license の下で公開しています。このガイドは、2026-08-10 にリリースされた version 2.0.0 を前提にしています。この分野の skill は短期間で変わるため、運用を継続する setup に導入する前に、リポジトリの CHANGELOG を確認してください。

ここでいう skill は、一般的な意味での skill です。タスクが説明に一致すると、ハーネスがモデルのコンテキストに読み込む SKILL.md ファイルを指します。この仕組みが初めての場合は、エージェント skill とは何か、ハーネスがどのように読み込むかから始めてください。unlazy は通常の markdown といくつかの Node scripts だけで構成されているため、独自のサーバーや API key は必要ありません。

エージェントが 80 パーセントで停止し、3 つ目の指示を落とす理由

この動作には、見分けやすいパターンがあります。4 つの作業を依頼すると、応答は 1 つ目、2 つ目、4 つ目を扱います。最後の要約では、4 つすべてを完了済みとして列挙します。エラーは発生していないため、問題も検出されません。1 週間後に抜けが見つかります。

unlazy の README は、モデルの怠慢に関する公開研究を根拠として挙げ、「応答の早期切り上げと、複数部分からなる依頼への部分的な遵守」と説明しています。引用元は arXiv 2512.20662 です。同じ README では、設計上の前提も明確に示されています。文章で文章を強制することはできません。エージェントにもっと努力するよう指示しても、短縮を生んだのと同じコンテキストに文章を追加するだけです。

そのため、version 2 では状態をファイルに保持します。GATES.md にあるチェックボックスは、モデルの判断対象外に置かれます。チェックボックスの下に証拠行があるかどうかだけが問題です。スクリプトなら、エージェントに確認しなくてもその状態を判定できます。

深さの木を層ごとに見る

深さの木は、作業をどこで実行してよいかという規則に基づく分解です。手法のリファレンスには、次のようにあります。

自然な継ぎ目で分割する。自然な継ぎ目で可能な場合は二分し、N 層まで深くする。

実際の作業を行う場所はリーフだけである。リーフより上の各層は、すべて分解と統合である。

リーフは箇条書きの項目より大きな単位です。リファレンスでは、次のように最小サイズを定めています。

リーフは実際の作業単位である。10 分以上の集中作業、1 つの一貫した成果物、1 つの gates ファイルを含む。

この下限があることで、深い木が単なる作業の細分化になるのを防げます。リーフが「変数名を変更する」だけなら、この基準を満たしません。その上の分割は、1 層深くしすぎています。

各リーフでは、4 つのパスを順に実行します。まずプレースホルダーを残さず完全に実装し、次にドメインの専門家の視点で読み直し、欠陥を探し、最後に低コストで可能な範囲を仕上げます。リーフに最小サイズが必要な理由は、これらのパスにもあります。2 分で終わる変更に 4 つのパスを適用しても、形式的な作業にしかなりません。

スキルを呼び出すときに、深さを指定します。

/unlazy tree 5 refactor the payment module

スキルの説明はスラッシュコマンドではなく意図に基づいて照合するため、通常の言葉でも指定できます。

tree 3 build the landing page and do not stop until every gate is checked

リファレンスでは、深さを次の範囲に分けています。tree 2 または 3 は、機能、バグ調査、ドキュメントに相当します。1 回のセッションで 1 人が作業し、リーフ数は 2 から 4 です。tree 4 または 5 は、サブシステム、リファクタリング、詳細なレビューに相当します。リーフ数は 8 から 16 で、「1 つのコンテキストで適切に保持できる範囲を超える」規模です。tree 6 または 7 は、プロジェクト全体に相当します。オーケストレーションモードで実行し、リーフを互いに重複しない作業単位に割り当てます。

深さを指定しない場合、スキルには「タスクの自然な構成要素にリーフが一致する、最小の N を選ぶ」と指示されます。また、デフォルトで 1 層深くしないことも明示されます。深さは作業の内容を表すため、数値を大きくしても品質は向上しません。

gates ファイルの形式

作業を開始する前に、agent は受け入れ基準を gates ファイルに記述します。各 gate はチェックボックスで、その下にコマンドを置きます。

# Gates: pricing section

- [ ] G1: three tiers render with real copy
  CHECK: node check.js pricing --tiers
  EXPECT: 3/3 tiers ok
  EVIDENCE: pending

- [ ] G2: annual toggle changes both price and label
  CHECK: node check.js pricing --toggle
  EXPECT: toggle ok
  EVIDENCE: pending

CHECK はコマンドです。EXPECT は合格とみなす出力です。EVIDENCE は pending から始まり、コマンドが実際に出力した内容に置き換える必要があります。skill には、これらのファイルをスキャンして未完了の gate を報告する scripts/gate-check.mjs が含まれています。そのため、トランスクリプトを読まなくても実行結果を監査できます。

この考え方は1行で表せます。SKILL.md でも1行で記述しています。

レポートは台帳に裏付けられた主張の集合であり、完了したという感覚ではない。

続くルールは「台帳が埋まるまでレポートを出さない」です。さらに、最終サマリーに含めるすべての数値はレポート時点で再測定するか、未検証と明記します。agent が完了したと感じたからといって gate を閉じることはできません。gate を閉じるとは、EXPECT に一致する出力、または一致しない出力を貼り付けることだからです。

第三者が実行できる gates を記述します。「問題なさそう」はチェックになりません。空のファイルや存在しないファイルでは明確に失敗するため、test -s dist/index.html && echo ok が ok を出力することはチェックになります。

並列作業を始める前に、PLAN.md の契約を定義する

ツリーが十分に広がり、リーフが別々のコンテキストで実行されると、リーフ間で前提を共有できなくなります。メソッドリファレンスでは、ファンアウトの前に契約を置きます。

ファンアウトの前に契約を定義します。インターフェース、データの所有権、命名規則、エラー規約を、リーフの開始前に PLAN.md に記載します。

理由は明確です。「エラーハンドリングを追加する」と指示された 2 つのサブエージェントは、それぞれ異なるエラー形式を考案します。各リーフはローカルでは正しいため、それぞれのゲートを通過します。問題が発生するのは、両者を統合したときだけです。ブランチゲートは、その時点を検証するために存在します。ブランチゲートでは、「子の変更がマージされ、インターフェースが一致し、エンドツーエンドの動作が機能し、兄弟リーフに回帰がない」ことを確認します。

オーケストレーションモードでは、ドライバーは PLAN.md の契約セクションを各サブエージェントに渡します。ファイル全体や、ドライバー自身の履歴は渡しません。さらに、そのリーフの gates ファイルをそのまま渡します。サブエージェントが戻ると、ドライバー自身がチェックを再実行します。「証拠を示さずに自分のチェック項目を完了した」サブエージェントには、未達成のゲートを具体的に示して差し戻します。

オーケストレーションには下限があります。実作業が約 30 分未満の場合は、リファレンスでは単独で作業を続けるよう求めています。各サブエージェントはタスクの理解を最初から構築し直す必要があり、その準備コストが、新たに得られる注意力の利点を上回るためです。

unlazy skill はどのようにインストールしますか？

対応している方法は skills CLI を使用することです。

npx skills add Leonxlnx/unlazy

手動でインストールする場合は、agent の skills ディレクトリに clone します。

git clone https://github.com/Leonxlnx/unlazy ~/.claude/skills/unlazy

git clone https://github.com/Leonxlnx/unlazy ~/.codex/skills/unlazy

その後、配置されたことを確認します。

ls ~/.claude/skills/unlazy/SKILL.md

パスが表示されれば、ファイルがディスク上に存在します。No such file or directory と表示された場合は、通常、想定した名前の skills ディレクトリが存在せず、git が新しいディレクトリを作成したため、別の場所に clone されています。agent の申告だけで判断しないでください。README にあるインストール手順の最後にも、同じ警告があります。「ファイルが実際にディスク上にあることを確認するまで、インストール済みだとは言わないでください。」

skill loader がない harness では、SKILL.md の内容を system prompt または rules file に貼り付けます。これは文書化されているフォールバック方法です。そのため、通常の markdown 命令ファイルを読み込む Claude Code、Codex、Cursor などで利用できます。SKILL.md を最初から確実に読み込ませる方法を確認したい場合は、独自の agent skill の作成で、発動するかどうかを決める frontmatter と description の照合について説明しています。

Claude Code 以外でも Stop hook は動作しますか？

いいえ。この点は正確に理解してください。上記はすべて指示であり、指示は無視される可能性があります。構造的に強制できる唯一の要素は Stop hook であり、Stop hook は Claude Code の機能です。

node <path-to-skill>/scripts/install-hooks.mjs            # this project only (settings.local.json)
node <path-to-skill>/scripts/install-hooks.mjs --global   # every project
node <path-to-skill>/scripts/install-hooks.mjs --uninstall

Stop hook は、エージェントがターンを終了しようとした瞬間に実行されます。この Stop hook は gates ファイルをスキャンし、未達成の gate がある間は停止をブロックします。そのため、未確認のチェックボックスを残したままターンを終了できません。ファイルを読み取るだけで、model call は実行しません。README に「トークンを 0 消費する」と記載されているのはこのためです。仕組み全般と、関連付けられるその他のイベントについては、ターン中に Claude Code hooks が実行される仕組みを参照してください。

この Stop hook には解除機構もあります。これは見た目以上に重要です。エージェントが 6 回連続してブロックされた停止の間に gate を 1 つも進めなかった場合、Stop hook は警告を出して停止を許可します。また、ABANDON: <gate> <reason> の行は常に正当な終了として扱われます。この 2 つの逃げ道がなければ、環境上達成不可能な gate によって、ユーザーが自分でセッションを終了するまでトークンを消費し続けます。

Codex、Cursor、その他の harness では、install-hooks.mjs をインストールする対象がありません。gates ファイルと実行可能なチェックは引き続き利用できますが、model がターンを早期終了するのを構造的に阻止する仕組みはありません。その場合、gates ファイルはユーザー自身が読む必要のあるドキュメントです。

unlazy と ponytail: どちらを選びますか？

この 2 つのスキルは同じ時期に注目を集め、作業量に対して正反対の方向に働くため、混同しやすくなっています。

ponytail を使うと、エージェントは、そもそもそのコードが必要かどうかを最初に確認するシニア開発者のように動作します。スコープを絞り、標準ライブラリを優先し、変更差分を小さくします。unlazy はスコープがすでに合意済みであることを前提にし、その範囲のすべてを完了し、検証できる状態になるまで作業を徹底します。

そのため、実際に発生している失敗に応じて選んでください。エージェントが小さな機能をフレームワークにまで膨らませる場合は、ponytail スキルと、その怠惰なシニア開発者のペルソナが適しています。4 つの項目を含む依頼の 3 つ目を未完了のままにし、成功したと報告する場合は、unlazy が適しています。

両方を実行することもできますが、順序が重要です。まず ponytail の質問でスコープを確定し、合意したスコープを unlazy のゲートに渡してください。逆の順序にすると、ponytail なら削除していた作業のために葉のツリーを構築し、そのすべてに深さの乗数分のコストを支払うことになります。この順序は私の推奨であり、2 つのプロジェクト間で文書化された統合方法ではありません。

VPS 上で動作するエージェントにおいて、depth のコストはどの程度ですか？

Depth は作業量を増幅し、作業量はトークン数に直結します。自分の API key を使って VPS 上でエージェントを動かす場合、この増幅率がそのまま費用になります。

ChartEffort and cost multipliers reported by the unlazy authors, August 2026

label

low_multiplier

high_multiplier

Skill run vs no skill, output tokens

1.6

3.9

tree 6 vs tree 3, total cost

1.0

1.5

The data behind this chart

[
  {
    "label": "Skill run vs no skill, output tokens",
    "low_multiplier": 1.6,
    "high_multiplier": 3.9
  },
  {
    "label": "tree 6 vs tree 3, total cost",
    "low_multiplier": 1.0,
    "high_multiplier": 1.5
  }
]

これは著者が 2026-08-10 に自身のテストで得た数値です。こちらでは再現していないため、予測値ではなく傾向として読んでください。Solo の規律によって出力はベースラインの 1.6 倍から 3.9 倍程度まで増加しました。一方、1 つのコンテキスト内で tree 3 から tree 6 に移行しても、増加は 1.0 倍から 1.5 倍にとどまり、二分分割を 3 回追加した場合に予想される 8 倍には大きく届きませんでした。

Depth を深くしてもコストが比例して増えないのは、depth がコンテキストを追加するのではなく、作業量を再配分するためです。トークン経済の参考資料は、実際の増幅要因を明確に示しています。「コストを増幅するのはオーケストレーションです。各 leaf が新しいコンテキストを作成するため、コストも増幅する必要があります」。Solo モードでは、1 つのコンテキスト内の出力トークンが増えます。オーケストレーションモードではコンテキスト数が増えます。新しいコンテキストはそれぞれ、実際の作業を始める前に契約と gates ファイルを再度読み込みます。

見落としやすい 2 つ目のコストもあります。同じ参考資料では、この点も説明されています。テストでの 1 回のモノリシックな deep run は、1 つのコンテキストが内容を増やし続けながらすべてを保持したため、「約 58 million の cached input tokens を消費」しました。cached input はトークン単価が低いものの、この量になると請求額に影響します。

このことから、次の 4 つの設定が導かれます。

leaf が実際の作業単位になる最小の depth を選び、そこで停止します。不要な depth は、不要な支出です。
30 分未満の作業では solo モードを使います。この範囲では、新しいコンテキストから得られる効果よりも subagent のセットアップコストの方が大きくなります。
Claude Code を使っている場合は Stop hook を設定します。これは、この中で唯一無料で実行される部分です。
長時間の処理を始める前に、アカウントレベルで支出上限を設定します。

最後の点が重要です。早すぎる停止を拒否するよう設計された skill は、設計上、処理を継続します。予算設定とアラートはプロンプト作成とは別の作業です。VPS 上でエージェントのコストを制御する方法では、最初に設定しておくべき上限について説明しています。

著者が測定した内容と、そこから分かること

このリポジトリは独自のテスト結果を公開しています。このような例は、本来もっと多くてもよいものです。README から引用すると、構成は「ゼロから構築する2つのタスク（マーケティングサイトと three.js の太陽系）、各タスクで3つの条件（skill なし、tree 3、tree 6）、実行ごとに新しいフォルダーと新しいセッションを使用し、同じモデルと同じプロンプト本文を使用する」というものです。すべての出力は独立したエージェントによるコードレビュー、敵対的な再検証、ブラウザーでの実動テストを受けています。

ChartPer-run counts claimed in the unlazy README, August 2026

label

low_count

high_count

Self-found defects fixed, skill runs

Wrong numbers in report, skill runs

Wrong numbers in report, baseline runs

The data behind this chart

[
  {
    "label": "Self-found defects fixed, skill runs",
    "low_count": 4,
    "high_count": 10
  },
  {
    "label": "Wrong numbers in report, skill runs",
    "low_count": 1,
    "high_count": 3
  },
  {
    "label": "Wrong numbers in report, baseline runs",
    "low_count": 0,
    "high_count": 0
  }
]

中央の行を2回読んでください。著者自身のテストでは、skill を使った実行で、エージェントが納品前に自力で発見した欠陥は 4 から 10 件に固定されました。その一方で、skill を使った各実行の最終レポートには、1 から 3 個の誤った数値が含まれていました。ベースライン実行では 0 個でした。より多くの作業によってビルドは改善しましたが、要約は悪化しました。これが ledger ルールの根拠であり、レポート作成時にすべての数値を再測定するか、未検証として明記するよう指示する理由です。

もう1つ、記録しておく価値のある結果があります。「実際に動作する環境で発生した唯一の重大な失敗はベースラインのビルドであり、そのレポートはそのケースを処理済みだと主張していた」というものです。壊れたビルドの上に自信ありげな要約が載ることこそ、これらのゲートが防ごうとしている事態です。

最後に限界を示します。実行は6回、構築タスクは2つ、モデルは1つで、実行と報告を担当したのは skill 自身の著者です。ここに独立した再現検証はありません。したがって、ここで引用しているのは2026-08-10時点の著者の主張です。代わりに、自分の作業で試してください。同じタスクを2回実行し、1回は通常どおり、もう1回は gates ファイルを使います。その後、自分で再実行できる証拠を添えて閉じられたゲートの数を数えてください。この分野で自分に属する唯一の数値は、その数です。

FAQ

unlazy スキルの Depth Tree とは何ですか？

分解方法です。タスクを自然な境界で N 層に分け、最下層のリーフだけを作業として扱います。このスキルでは、リーフを、1 つのまとまった成果物と 1 つの gates file を伴う、10 分以上の集中作業と定義しています。2 分で完了できるリーフがある場合、分解が 1 層深すぎます。リーフより上の各層は分解と統合を担い、各ブランチには、子要素が統合され、インターフェースが一致していることを証明する独自の gates が付きます。深さは実行時に指定します。たとえば tree 5 のように指定します。文書化されたデフォルト値は、リーフが実際の作業単位になる最小の深さです。

unlazy スキルは Claude Code 以外でも動作しますか？

一部は動作します。このスキルはプレーンな markdown で記述されているため、Codex、Cursor、または SKILL.md や system prompt を読み取るものなら、Depth Tree、gates file、実行可能なチェック、各リーフの 4 つのパスを利用できます。ただし、強制方法は異なります。gates が未達成の状態でターン終了をブロックする Stop hook は Claude Code の機能であり、node <path-to-skill>/scripts/install-hooks.mjs でインストールします。それ以外の環境では、モデルが早期にターンを終了することを構造的に防げません。そのため、gates file を読み、自分でモデルに送り返す必要があります。

unlazy スキルによって token bill はどの程度増えますか？

作成者の報告では、solo mode では、スキルを使わない実行の出力 token 数に対して 1.6 倍から 3.9 倍です。これに加えて、gates file 自体に数百 token 程度のオーバーヘッドがあります。1 つのコンテキスト内で深さを増す場合のコストは比較的小さく、tree 3 から tree 6 に移行すると約 1.0 倍から 1.5 倍です。コストが大きいのは orchestrated mode です。各リーフで新しいコンテキストが作成され、作業前に契約とその gates を再読み込みするためです。Stop hook はファイルをスキャンするだけなので、追加コストはありません。これらは 2026-08-10 時点での作成者の数値であり、こちらで再測定したものではありません。

unlazy と ponytail のどちらを使うべきですか？

目の前にある失敗に合わせてスキルを選びます。ponytail は、コードを書きすぎる agent 向けです。senior developer として振る舞い、そのコードが本当に必要かを確認して、まず standard library を使おうとします。unlazy は、依頼した作業を十分に完了しない agent 向けです。作業を強制的に分解し、証拠がない限り gate を完了扱いにしません。両方を使う場合は、まず ponytail でスコープを確定し、そのスコープを unlazy に渡します。削除すべき作業に effort multiplier を適用せずに済みます。

unlazy をインストールしても agent が早期に停止するのはなぜですか？

4 点を確認してください。まず ls ~/.claude/skills/unlazy/SKILL.md でスキルがディスク上にあることを確認します。存在しないディレクトリに clone したことが、よくある見落としです。次に、作業開始前に gates file が作成されたことを確認します。hook は gates file をスキャンするため、GATES.md が存在しなければブロックする対象がありません。3 つ目に、hook のインストール先を確認します。通常の install-hooks.mjs 実行では、このプロジェクトの settings.local.json にだけ書き込みます。別のプロジェクトでは --global が必要です。4 つ目に、release valve は仕様どおりに動作していることを覚えておいてください。gate の進展がないまま 6 回連続で停止をブロックすると、agent は警告を出して続行できます。また、ABANDON: <gate> <reason> 行があると、意図したとおり試行を終了します。

#agent-skills #claude-code#unlazy#prompting #token-cost