ADR-0044: 自前実装の前に既存の部品を探す義務を課さないと決める

ステータス

採用(2026-08-14)

本標準は、依存を追加するときに必要性を人が確認する規定を持ちます(G-5 基準8、G-6 基準5)。一方で、自前で実装しようとしているものに既存の部品が無いかを探す義務がありません(#237)。

非対称があります。依存の追加は差分に現れて機械検出できますが、既存の部品があったのに自前で書いた事実は差分に現れません。検出できないほうを標準が見ていませんでした。

外部の一次情報は、既存部品の優先を規範としていません。

CMMI for Development V1.3 SP 1.3 subpractice 1 — 「Perform a literature search」。組織の内外で他者が何をしたかを明らかにする探索である
ただし同 SP 1.1 は、形式評価を掛ける対象を組織が指針で定めると規定する。全件強制ではない
Google の依存関係管理 — 内製難度を質問リストへ入れ、外部部品と対等に並べる
OpenSSF Concise Guide — 最初の問いが「Can you avoid adding it?」。「Every new dependency increases the attack surface」と続く

先例が支持するのは「既存を優先せよ」ではなく「両方を代替案として並べ、基準に照らして比べ、記録せよ」です。

EU Cyber Resilience Act 第13条 — 無償の OSS を含む第三者部品の統合に due diligence を課す。違反に最大1500万ユーロ
xz-utils(CVE-2024-3094) — レビュー・SBOM・ライセンス監査のいずれでも止まらず、偶然の性能観測で発覚
2025年の新規の悪意あるパッケージは 454,648件

slopsquatting(USENIX Security 2025)。16モデル・576,000超のサンプルで、推薦パッケージの 19.7% が実在せず、同一プロンプト10回で架空名の 43% が毎回再現します。

本標準は AI が実行(R)を担う前提に立ちます。探索を規範として置けば、実行するのは AI です。架空パッケージへの露出が直接増えます。

先例はすべて調達・プロジェクト着手・アーキテクチャ決定の単位です。FAR 10.001 は「新しい要求文書を作成する前」、OMB M-16-21 は「技術調達または独自コード開発に着手する前」。PR 単位・関数単位で判断せよという先例は、本調査の範囲で見つかりませんでした。

「探せ」を規範として書きません。設計者の裁量とします。

「探したが該当なし」を独立の記録項目として持ちません。理由はADR-0041と同じです。探索範囲の記録は、網羅性の主張として読まれます。

書かれていない状態と、課さないと決めた状態を区別します。本 ADR の存在が、その区別を与えます。第5章の本文には条文を足しません。

テンプレ2 の「比較した代替案(最低1つ)」に、既存部品の案を含める条件を足しません。R1 の判定そのものが自己申告であり、探索を避けたい者は R2 と申告できます。適用範囲を閾値で切る形は、閾値の判定を自己申告にすることで要求そのものを無効化します。

存在しないパッケージの参照は、依存関係の解決で失敗します。G-5 の既存の検査で捕まります。新しい条文を置きません。

案	却下の理由
ADR の比較表に「既存の部品を用いる案」を必ず含めさせる	決定4 のとおり。適用範囲を R1 で切ると、R1 の自己申告で回避できる
G-6 に「既存の部品を検討したか」の確認を足す	実装後に問うことになり、手戻りが最大化する。判断は設計時点に置くべきという先例と逆行する
探した範囲の記録を求める	記録が網羅性の主張として読まれる。かつ 5.7.4 が記述の質の判定を禁じており、質を確かめられない
「なるべく既存のものを使え」と書く	先例が支持しない。OpenSSF・CRA・xz-utils が逆向きの根拠を与える
何も書かない(現状)	「書かれていない」と「課さないと決めた」が読み手に区別できない