# Unconventional Simplification

> 定石外発想で実装をシンプルにする。現状の発展型ではなく、実装の裏にある暗黙の前提条件を1つずつ外し、よりシンプルな別解がないか検討する。 ユーザーが「定石外発想で」「前提を疑って」「もっとシンプルにできないか」と言った時に使用する。

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

---


# 定石外発想によるシンプル化手順書

このスキルは、採用済みの解をレビューしたり機能を足したりするものではない。解の裏にある暗黙の前提を列挙し、1つずつ外して、より少ない実装・説明で済む別解を探す。現状の発展型に流れず、要素の引き算で考える。

ゼロから案を作るのではなく、すでにある実装・方針・設計判断を再考対象にする。

## 手順1: 分析対象の特定

「いま再考すべき解（第一案）」を特定する。

1. **引数がある場合**: 指定されたファイル・モジュール・機能を対象とする
2. **会話コンテキストがある場合**: 直前に到達した方針・設計判断・実装アプローチを対象とする。これが主たる特定方法である
3. **コールドスタートの場合**: 会話コンテキストが薄く引数も無いときは、直近の変更を自動検出して対象とし、何を対象と推定したかを一言で明示する

対象を特定したら、その解を実装しているコードを以下の順で確認する:

1. 引数で対象ファイル・モジュールが指定されている場合は、まずそれを直接読む
2. 未commitの変更を `git diff` と `git diff --staged` で確認する
3. 未commitの変更が無ければ、base branchとの差分や直近のcommitを確認する。base branchは `git symbolic-ref refs/remotes/origin/HEAD` 等で判定し、例えば `git diff origin/main...HEAD` のように差分を取る。判定できなければ `git log -p -3` を見る

## 手順2: 前提条件の列挙

採用された解が暗黙に置いている前提を、コードと会話コンテキストから列挙する。コードと会話コンテキストに根拠のある前提だけを扱い、空想上の要件は持ち込まない。

例:

- このAPI・データ構造・状態を維持する必要がある
- この処理をこのタイミング・UI・場所で提供する必要がある
- 問題はこの層で解く必要がある

実装そのものだけでなく、問題設定への前提も含める。「そもそもどういうユーザー・状況か」「もっと手前の段階で対処すべきではないか」まで戻る。これを外さないと、単なる実装差分のレビューに戻る。

## 手順3: 前提を1つずつ外して再考

列挙した前提を1つずつ取り上げ、「この前提が無ければどういう解になるか」を考える。一度に複数の前提を外さない。

- シンプルにならないものは、理由を軽く記録してスキップする
- シンプルになるものは、その別解を具体化する

## 手順4: コスト比較

シンプルになった別解を、第一案と次の5観点で比較する。

1. **実装量**: コードがどれだけ減るか
2. **既存仕様との互換性**: 既存の動作・APIとの互換が壊れないか
3. **説明コスト**: 概念や挙動の説明が難しくならないか
4. **運用・移行コスト**: 既存データや運用フローの移行が要るか
5. **将来の保守性**: 長期的に保守しやすくなるか

加えて、前提解除を成立させるために必要な別の仕組みを計上する。前提を外せた裏で追加実装・ドキュメント・教育などが要るなら、簡潔さの代わりにどこへコストが移ったかを正直に見積もる。

## 手順5: 分類

各別解を3つに分類する。

- **今すぐ検討すべき**: シンプルさの利得が大きく、コストが見合う
- **将来の論点**: いまは第一案で妥当だが、状況が変われば再考に値する
- **現状の採用案で妥当**: 前提を外してもメリットが薄い、またはコストが上回る

## 手順6: 外部Agent相談（任意）

外部Agentへの相談は、ユーザーが明示的に求めた場合だけ行う。相談の進め方は `codex-consultation` / `subagent-consultation` の手順に任せ、このスキルは相談の中身だけを指定する。

外部Agentは放っておくと通常のレビューに流れるため、レビューではなく手順2〜5そのものを依頼すること。すなわち、外部Agent自身に根拠のある前提を列挙させ、各前提を「その前提が無い場合」に置き換えたとき、より少ない実装・説明で済む別解が出るかを検討させる。受け取った別解は鵜呑みにせず、自分でコードを読んで検証する。

## 手順7: 報告

結果を会話に出力する。ファイルには保存しない。提案・分類で停止し、コードの自動適用はしない。どの別解を採用するかは人間が判断する。

報告フォーマット:

```markdown
## 定石外発想によるシンプル化検討

### 対象

{再考対象の解の要約。コールドスタート時は推定した対象も明記}

### 各前提の再考結果

列挙した前提ごとに:

- **前提**: {内容}
- **前提を外した場合の別解**: {具体的な別解。シンプルにならない場合はその旨と理由}
- **5観点比較と前提解除に必要な別の仕組み**: {効くものだけ}
- **分類**: 今すぐ検討すべき / 将来の論点 / 現状の採用案で妥当

### 推奨アクション

{「今すぐ検討すべき」があれば何を検討すべきか。無ければ「現状の採用案で妥当」と結論する}
```