# Observation Minimum Set

> 観測の最小セットを適用。6つの失敗モード（仕様誤解/境界条件/依存/セキュリティ/並行性/運用）を継続可能なコストで網羅。Use when: プロジェクト開始、リリース前チェック、品質改善振り返り、観測が足りているか確認したい。

- Skill: `majiayu000/observation-minimum-set` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/observation-minimum-set`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/observation-minimum-set/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/observation-minimum-set

---


# Observation Minimum Set（最小セット統合観測）

## 目的

観測は"バグを見つける手段"というより、**失敗モードごとに、間違いが露出する場所を作る技術**。
このスキルは、6つの失敗モードを**継続可能なコスト**で薄くカバーする。

## 観測の強さの評価基準

| 基準 | 説明 |
|------|------|
| 独立性 | 実装と同じ前提に依存しない観測 |
| 露出性 | 失敗時に確実に"壊れる形"で信号が出る |
| 再現性 | 問題が再現でき、修正効果が観測できる |
| コスト | 毎回回る（継続可能）こと |

## 6つの失敗モード

| # | 失敗モード | 典型的な症状 | 関連スキル |
|---|-----------|-------------|-----------|
| 1 | 仕様誤解 | 型もテストも通るのに"違うもの" | spec-observation |
| 2 | 境界条件漏れ | 例は通るが端で壊れる | boundary-observation |
| 3 | 依存取り違え | ローカルでは動くのに本番で死ぬ | dependency-observation |
| 4 | セキュリティ | 認可漏れ、機密漏えい | security-observation |
| 5 | 並行性 | 通常テストが通るのに本番で死ぬ | concurrency-observation |
| 6 | 運用不能 | 原因不明、ログがない、復旧できない | operability-observation |

## 最小セット（普遍：5つ）

継続可能な"最小セット"として、以下の5つを必須とする：

### 1. 実行可能仕様 ＋ 仮定ログ（仕様誤解対策）

```
[ ] 仕様の例（少数）＋否定例をテスト化
[ ] 仮定ログを成果物として残し、差分レビュー対象にする
```

### 2. クリーンビルド ＋ 型/コンパイル ＋ lint（基本品質）

```
[ ] lockfile固定＋CIで固定破り即fail
[ ] クリーン環境でのビルドがCIで回る
[ ] 型チェック/コンパイルが通る
[ ] lint（静的解析）がエラー0
```

### 3. 境界値テスト ＋ 性質テスト（境界条件対策）

```
[ ] 外部境界ごとに最小・最大・空・異常のテスト
[ ] 重要箇所に性質テスト1本
```

### 4. 依存固定 ＋ 脆弱性スキャン ＋ Secret scan（供給網対策）

```
[ ] lockfile固定
[ ] 依存脆弱性スキャン（npm audit / pip-audit等）
[ ] Secret scan（gitleaks等）
```

### 5. 運用観測性の最小（運用不能対策）

```
[ ] 起動時設定検証（fail fast）
[ ] ヘルスチェック（liveness/readiness）
[ ] 構造化ログ＋相関ID＋エラー分類
[ ] 最低限メトリクス（エラー率・レイテンシの2つでも）
```

## 最小セット（条件付き：+1）

### 6. 並行性観測（並行性がある領域のみ）

```
[ ] レース検出/サニタイザをCIで回す
[ ] ストレステスト1本
[ ] タイムアウト＋飽和メトリクス
```

## カバレッジ行列

各最小セットがどの失敗モードに効くか：

| 失敗モード | 1.仕様 | 2.ビルド | 3.境界 | 4.供給網 | 5.運用 | 6.並行 |
|-----------|--------|---------|--------|---------|--------|--------|
| 仕様誤解 | ◎ | △ | ○ | △ | ○ | - |
| 境界条件 | ○ | ○ | ◎ | △ | ○ | △ |
| 依存取違 | △ | ○ | △ | ◎ | ○ | - |
| セキュリティ | △ | ○ | ○ | ◎ | ○ | △ |
| 並行性 | - | △ | △ | - | ○ | ◎ |
| 運用不能 | ○ | △ | △ | ○ | ◎ | ○ |

凡例：◎強い ○中程度 △限定的 -効果なし

## Procedure

### Step 1: 現状診断

`assets/observation-checklist.md` を使って、現在の観測状況を診断する。

### Step 2: ギャップの特定

最小セットと現状の差分を特定し、優先順位を付ける。

**優先順位の基準**：
1. 仕様誤解（A1/A2）→ 最も早期に効果が出る
2. 供給網（C1/D1/D2）→ セキュリティに直結
3. 運用観測性（F1-F4）→ MTTRに直結
4. 境界条件（B1/B2）→ 品質向上
5. 並行性（E1-E3）→ 該当領域のみ

### Step 3: 段階的導入計画

一度にすべてを導入せず、段階的に進める：

```
Week 1: A1/A2（仮定ログ + 受入テスト）
Week 2: C1/D1/D2（lockfile + secret scan + 脆弱性スキャン）
Week 3: F1-F3（設定検証 + ヘルス + 構造化ログ）
Week 4: B1/B2（境界値テスト + 性質テスト）
以降: 必要に応じて E1-E3（並行性）、F4（メトリクス）
```

### Step 4: 継続的モニタリング

導入した観測が継続的に機能しているか定期的に確認する。

## 最小セットを強くするコツ

1. **テストのオラクル（期待値）の独立性を守る**
   - 実装と同じ誤解で生成したテストは危険
   - 受入テストの期待値は"仕様の例"から

2. **失敗時のログが"次の修正の入力"になるようにする**
   - 例外にID・分類・境界情報がないと改善に繋がらない

3. **重い観測は条件付きにするが、"条件"を観測で決める**
   - 並行性領域→race必須
   - 外部入力あり→fuzz検討

## Outputs

- `observation-checklist.md`: 現状診断チェックリスト
- `observation-gap-report.md`: ギャップレポート
- `observation-roadmap.md`: 段階的導入計画

## Examples

### 現状診断の例

```markdown
## 観測現状診断 (2024-01-15)

### 1. 実行可能仕様 ＋ 仮定ログ
- [x] 受入テストあり（ただし否定例が不足）
- [ ] 仮定ログなし

### 2. ビルド ＋ 型 ＋ lint
- [x] lockfile固定
- [x] 型チェック
- [x] lint

### 3. 境界値 ＋ 性質テスト
- [ ] 境界値テスト（API入力のみ、DB境界なし）
- [ ] 性質テストなし

### 4. 供給網
- [x] lockfile固定
- [ ] 脆弱性スキャンなし
- [ ] secret scanなし

### 5. 運用観測性
- [x] ヘルスチェックあり
- [ ] 設定検証なし（起動後にクラッシュする可能性）
- [ ] 構造化ログなし
- [ ] メトリクスなし

### 優先対応
1. secret scan導入（即日）
2. 仮定ログの運用開始（今週）
3. 設定検証の実装（来週）
```