過剰になった実装計画を4つに分類する
AIへ依頼した機能は動くものの、将来向けの設定や共通基盤まで増えてしまうことがあります。yagni-reviewは、現在の目的に照らして各要素を「維持・簡素化・削除・確認」に分類し、必要な最小構成を提案するCodex Skillです。
「高品質に」とだけ依頼し、利用者・規模・対象外を伝えないと、AIが一般的な拡張性や可用性まで計画へ加えることがあります。それぞれに理由が付いていても、現在の成功条件が必要としているかを照合します。
この記事では、5人で使う社内PoCの計画を例に、何を残し、何を減らすかを紹介します。目的・要件そのものから範囲を見直す考え方は、minimalistとconformistも参照してください。
yagni-reviewとは
yagni-reviewは、レビュー対象を「現在の目的を達成する最小のスコープと複雑性」へ近づけるためのSkillです。
対象は次の成果物です。
- PRDや要求仕様
- 設計書
- Implementation Brief（実装指示書）
- 実装計画
- ソースコード
レビュー結果は推奨事項として返します。明示的に依頼されない限り、対象ファイルの編集、要件変更、簡略化の実装は行いません。レビューと変更を分離することで、必要性の判断を確認してから実装へ進められます。
Skill本体はGitHub上のSKILL.mdで確認できます。
現在の目的をレビューの基準にする
過剰実装かどうかは、構成要素だけを見ても決められません。たとえば、キューは常に不要でも、常に必要でもありません。現在の処理量、応答時間、失敗時の要件によって判断が変わります。
yagni-reviewは、レビューの前に次の基準を確認します。
- 現在の目的
- 観測できる成功条件
- 利用者または利用するシステム
- 現在想定する規模
- 対象とする期間
- 法令、契約、セキュリティ、互換性などの拘束条件
基準には、ユーザーが提示した事実または確認できた事実だけを使います。リスクを推測できることと、そのリスクへ対応する仕組みを今すぐ追加してよいことは別です。
Keep・Simplify・Remove・Verifyの違い
yagni-reviewは、対象の各要素を4つのいずれかに分類します。
表は横にスクロールできます
| 判定 | 使う条件 | レビュー後の扱い |
|---|---|---|
Keep | 削除すると、現在の成果、利用者、拘束条件、必要な安全性や正しさが損なわれる | 必要性の根拠とともに維持する |
Simplify | 成果は必要だが、より小さな仕組みで満たせる | 現在の成果を保つ最小の方法へ置き換える |
Remove | 仮想的な将来、未使用の汎用性、根拠のない規模、好み、重複だけに対応している | 現在の対象から外す |
Verify | 現在の義務は確認できているが、安全に判断するための具体的な事実が不足している | 判断を変え得る事実だけを確認する |
Verifyは、判断を避けるための弱いKeepではありません。「将来必要になるかもしれませんか」のような仮想的な質問を増やすためにも使いません。
たとえば、契約上ログ保存が必要だと確認できているものの、保存期間が資料から分からない場合はVerifyです。ログ保存の義務自体が確認できず、単に将来監査があるかもしれないだけなら、その可能性を新たな要件にはしません。
5人の社内PoCをレビューする例
次の条件で、申請・承認機能を作るとします。
- 利用者は1組織の5人
- 3か月のPoC
- 成功条件は、申請者が申請し、承認者が承認できること
- 承認依頼はメールで通知する
- 申請には個人情報が含まれる
- 契約上、監査記録の保存が必要だが、保存期間は資料にない
AIが作った計画に、汎用Plugin SDK、マルチテナント対応、20種類の通知アダプター、Redisキャッシュ、アクセス制御、設定可能な監査ログ保存期間が含まれていたとします。
yagni-reviewでは、たとえば次のように整理します。
表は横にスクロールできます
| 計画の要素 | 判定 | 理由と最小構成 |
|---|---|---|
| 汎用Plugin SDK | Remove | 現在の利用者も受け入れ条件もPlugin追加を求めていない |
| マルチテナント対応 | Remove | 対象は1組織であり、別組織の利用予定は現在の範囲にない |
| 20種類の通知アダプター | Simplify | 通知は必要だが、現在必要なメール通知だけで成功条件を満たせる |
| Redisキャッシュ | Remove | 5人規模で応答時間の問題を示す計測結果も要件もない |
| アクセス制御 | Keep | 申請に個人情報が含まれ、申請者と承認者の操作を分ける必要がある |
| 監査記録の保存期間 | Verify | 保存義務は確認済みだが、契約上必要な期間が分からない |
最小版は、申請と承認、メール通知、必要なアクセス制御、契約に基づく監査記録です。Plugin基盤や複数組織対応を「あとで使えるように」残しません。監査記録は削除せず、確認が必要な保存期間だけを切り分けます。
YAGNIは安全性を削る考え方ではない
行数が少なければ、常に単純になるわけではありません。認証、権限確認、入力検証、エラー処理、データ整合性の保護を削ると、コードは短くなっても、利用者と運用者が負うリスクは増えます。
yagni-reviewが重視するKISSは、コードの短さではなく、システム全体の複雑性を小さくすることです。
次のような要素は、現在の挙動と根拠を確認せずに削除しません。
- 個人情報や機密情報を守るアクセス制御
- データ破損を防ぐ整合性チェック
- 対応対象としている入力に必要な検証
- 外部サービスとの境界で必要な失敗処理
- 契約や法令で求められる監査記録
一方、運用上起こり得ない条件へのガードや、対応対象外の入力に対する複雑な復旧処理は、現在の事実を確認できれば削減候補になります。
インストール方法
yagni-reviewは、株式会社織翔が公開するCodex Plugin Marketplaceからインストールできます。
最初にMarketplaceを追加します。
codex plugin marketplace add orito-inc/codex-plugins
次にyagni-review Pluginを追加します。
codex plugin add yagni-review@orito
インストール後は、新しいCodexセッションを開始してください。
OpenAIの公式ドキュメントでは、SkillはSKILL.mdを中心に構成し、Pluginへskills/を同梱できます。構成の詳細はBuild skillsとPackage your pluginで確認できます。
2026年9月3日時点で確認したローカルのCodex CLI 0.152.1では、codex plugin marketplace addとcodex plugin addを利用できます。コマンドやPlugin仕様は更新される可能性があるため、導入時には利用中のcodex plugin --helpと公式ドキュメントも確認してください。
この公開は、GitHubでホストするOrito Codex Plugins Marketplaceへの掲載です。OpenAI公式のUniversal Plugins Directoryへの申請・掲載とは別です。
実際の使い方
レビュー対象と、現在の目的が分かる情報を渡して明示的に呼び出します。
$yagni-review を使って、この実装計画を現在の目的に必要な最小構成へ見直してください。
現在の目的:
- 既存の受注一覧から、表示中の条件でCSVを出力できるようにする
利用者:
- 社内の管理者3人
対象外:
- 定期出力
- メール送信
- 複数形式への対応
yagni-reviewは自動呼び出しを無効にしています。通常のコードレビューへ暗黙に介入させず、スコープを見直したいときに$yagni-reviewで明示的に開始します。
出力では、削減による影響と必要性の根拠を確認します。現在の義務は分かっていても、保存期間などの判断に必要な事実が不足していれば、確認事項として残します。レビュー対象に不要な要素がなければ、無理に削減しません。
要件を変更する場合は、影響を確認して合意した範囲だけを反映します。確定した内容を別の担当者へ渡す方法は、implementation-briefの紹介を参照してください。