この連載「うちのSkill」では、社内で実際に運用しているSkillを紹介しています。今回取り上げる/loop-designは、記事や日報のように成果物を生成するSkillではなく、依頼そのものの設計を支援するSkillです。
「良い感じに」を完了条件にした時点で、ループは終わらない
SKILL.mdの最初のステップは、タスクがループ向きかどうかの判定です。判定基準は3つ、「合格基準を機械的に書けるか」「一発で正解が出にくく、手戻りのたびに人が指示し直すコストが高いか」「品質が外部に影響するため、レビューと修正を最低1周は回したいか」で、これらを満たさない場合は「単発を推奨」という理由付きの結論を出してそこで終える設計になっています。本文には「『良い感じに』を完了条件にした時点でループは永久に回るか、評価者の甘さで偽合格する」という一文があり、曖昧な完了条件のままループを組んでしまう失敗を、最初の判定段階で塞いでいます。
8つの部品が埋まらないうちは、ループにしない
判定を通過したタスクには、起動方法、入力、実行範囲、検証（完了条件）、停止規則、状態の置き場、予算、評価者という8つの部品を埋めさせます。特徴的なのは検証の項目で、「量と質の複合で書く。禁止事項（抜け道を塞ぐ制約）も必ず付ける」と指定されている点です。件数や数値だけの完了条件は、数を満たしつつ質を落とすという抜け道を生みやすいため、量の基準と質の基準、さらに抜け道を封じる禁止事項をセットで要求する設計です。停止規則についても「合格、無進捗N回（既定2回）、予算切れ、エスカレーションの4種を明示」と定められており、いつまでも止まらないループを避ける条件が具体的に決められています。
評価者は必ず生成者と別の実体にする
8部品のうち評価者の項目には「生成者と別の実体」という条件が明記されています。SKILL.mdの末尾にある禁止事項にも「生成者に自己採点させる設計にしない」という一文があり、成果物を作った本人が同じ流れで合否を判定する構成を最初から排除しています。あわせて「反復上限をエージェントの自制（プロンプト内の指示）だけに任せない。依頼書と評価者の側で数える」という禁止事項もあり、上限を守るかどうかを実行者の裁量に委ねず、外側の仕組みで数える設計になっています。
タスクの形に応じて、起動手段を使い分ける
判定と部品設計が終わると、タスクの形に応じた起動手段の選び方が示されます。完了条件が文章で書ける確定的なタスクには軽量な仕組みを、複数の評価者を立てて多視点で検証したいタスクにはより大掛かりな仕組みを、というように起動手段を段階的に使い分ける設計です。あわせて、定期タスクをループ化する場合は「報告のみ」の段階から始め、無人での自動運用へ進む段階には別途承認を要するという、成熟度を踏まえた段階的な運用方針も示されています。
自分の組織で真似るには
このSkillが有効なのは、「ループにすれば楽になりそう」という発想が先行し、完了条件や評価者の設計を後回しにしがちだからです。真似る場合のポイントは3つです。まず、ループを組む前に「合格基準を機械的に書けるか」を最初の関門にすること。書けないタスクは、いくら反復させても評価者の主観に頼った偽合格が起きやすくなります。次に、評価者を生成者と別の実体に固定するルールを最初から明文化すること。同じ流れの中で作って採点する設計は、どれだけ手順を整えても客観性を担保できません。そして、反復回数の上限を実行者の自制に頼らず、依頼書と評価者の双方で機械的に数える仕組みにしておくことです。この3点を設計段階で先に決めておけば、ループが止まらなくなる、あるいは質を落として数だけこなすといった失敗の多くを防げます。