# Boundary Check

> 設計・実装・施策のスコープの境界を確認し、やること・やらないこと・後回しにすることを明確にする。スコープクリープを防ぎ、責任境界を明確にする場面で使う。

- Skill: `thinkyou0714/boundary-check` (Agent Skill)
- Install (CLI): `npx skillmds@latest add thinkyou0714/boundary-check`
- Raw SKILL.md: https://api.skillmd.com/api/skills/thinkyou0714/boundary-check/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: thinkyou0714 (https://skillmd.com/u/thinkyou0714)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/thinkyou0714/boundary-check

---


## Purpose

「気づいたらスコープが広がっていた」「どこまでが自分の責任か」が曖昧なまま進むリスクを防ぐ。
スコープの内側・外側・境界を明示し、今何に集中すべきかを確定する。

## Use When

- 設計・実装の開始前にスコープを確定したい場合
- 「これもやった方がいいか」という追加要求が出てきた場合
- 複数のシステム・チームにまたがる機能を設計する場合
- assumption-audit の後にスコープの境界を明確にしたい場合
- 施工AIへ渡す前に「やること」「やらないこと」を確定したい場合

## Inputs

以下を準備すること。不足している場合は推測せず、不足を明示する。

- **対象**: スコープを確認する設計・機能・施策
- **目的**: これを実現する本来の目的
- **現時点の想定スコープ**: 何をやると思っているか（箇条書きで）
- **フェーズ**: 現在どのフェーズか（優先度・段階）
- **関係する他システム**: 隣接するシステム・機能・チーム

## Output Contract

以下の順で出力すること。順序を変えない。

1. **論点**: このスコープで最も曖昧な境界はどこか
2. **根拠**: その論点をそう判断した理由
3. **境界マップ**: やること / やらないこと / 後回し（後述フォーマット）
4. **含意**: 境界の引き方が示す中長期の意味（何を後回しにするコストか）
5. **改善案**: 境界を引き直すことで品質・コストが改善できる観点
6. **代替案**: 別のスコープの切り方（縮小案・拡大案）
7. **判断材料**: 境界の確定に必要な人間の意思決定事項

### 境界マップ フォーマット

```text
## スコープ境界マップ

### やること（In Scope）
- （具体的な機能・処理・責任）

### やらないこと（Out of Scope）
- （明示的に除外するもの・理由）

### 後回し（Deferred）
- （将来フェーズで対応するもの・条件）

### 境界が曖昧な箇所（要確認）
- （どちらに入るか確定できていない項目）
```

## Review Lens

- **目的妥当性**: 引いた境界が本来の目的と整合しているか
- **範囲の過不足**: 必要なものを削りすぎていないか。不要なものを含んでいないか
- **中長期リスク**: 「後回し」にしたものが後で大きなコストにならないか
- **LAB全体との整合性**: LMS / 自動化 / B2B 展開のフェーズ分けと矛盾しないか
- **非エンジニア理解可能性**: 境界マップが非技術者にも説明できる形か
- **他LLM移植耐性**: 境界の判断基準が Claude 固有の解釈に依存していないか

## Instructions

1. 現時点の想定スコープを読み、各項目を「In / Out / Deferred / 要確認」に分類する
2. 分類の根拠を各項目に1行添える
3. 「要確認」は推測で解決しない。人間が決めるべき境界として明示する
4. 「やらないこと」は「なぜやらないか」の理由を必ず添える
5. 「後回し」は「どの条件が満たされたら着手するか」を明示する
6. スコープクリープの兆候（「これもついでに」という追加）を指摘する
7. 境界確定後は Handoff Notes を使って施工AI へ渡す準備をする

## Guardrails

- スコープを自分で決定しない。「要確認」は人間が判断する
- 「ついでにやっておく」を提案しない（スコープクリープの原因）
- 「後回し」にするものは消えるのではなく記録に残す（Deferred として明示）
- コスト（追加スコープの工数）を省略しない
- 施工AIへの handoff 前にスコープが曖昧な状態で進めない

## LAB Cross-Check

| 観点 | 状態 | 備考 |
|---|---|---|
| 自動化フロー | — | 自動化スコープの境界が明確か |
| データ / 認証 / ログ | — | DB・Auth・ログのスコープが確定しているか |
| 実装 / 運用フロー | — | 実装範囲と運用責任の境界が明確か |
| 非エンジニア理解可能性 | — | 境界マップが非技術者に説明できる形か |
| 会員共有 / 再利用耐性 | — | この境界設計が他ケースにも転用できるか |
| 他LLM移植耐性 | — | 境界判断が Claude 固有の解釈に依存していないか |

状態は OK / 注意 / NG / 対象外 で記入すること。

## Handoff Notes

- **要件**: 確定した In Scope の一覧
- **成功条件**: スコープ内の全項目が完了した状態の定義
- **失敗条件**: スコープ外の作業が発生した場合の検知方法
- **実行範囲**: 触ってよいファイル・機能・DB（スコープ内のみ）
- **影響範囲**: スコープ内の変更が波及するシステム・機能
- **ロールバック方針**: スコープ内の変更が失敗した場合の戻し方
- **コスト比較**: 現在のスコープ vs 縮小案 / 拡大案のコスト差

## Further Reading

- `issue-framing` — スコープ確認前の論点整理
- `assumption-audit` — スコープの前提を洗い出す
- `scope-design` skill（lab-strategy-design）— 戦略的なスコープ設計
- `implementation-gate` skill（lab-implementation-flow）— 実装前の最終スコープ確認
- [docs/DECISIONS.md](../../../docs/DECISIONS.md) — フェーズ分けの過去決定