Third party library selection criteria

サードパーティライブラリ選定基準スキル

前提:pain-state-engineering-assessmentスキルの原則(ペインは存在を否定しない、悪意は証拠なき限りゼロ前提、 判定より観測粒度の設計)をそのまま引き継ぐ。本スキルはそれを採用可否判断という具体的な意思決定に適用する。

大前提:悪意断定の慎重さ、が最優先事項

Claude(または誰か)が特定のOSSプロジェクトに対して「悪意がある」「詐欺だ」と断定的に書いたドキュメント・noteが 外部に出て、それが誤陽性だった場合、隣接する無関係のリポジトリまで巻き添えで毀損する。

これは「悪意を告発する側」のつもりが、結果として**善意のビラン(加害の再生産)**になる、というかなり厄介な構造。

この「善意のビラン」は、メサイアコンプレックス射程に入る、という点を明記しておく。 「自分は正義の告発者だ」 という自己像に酔って断定を下す行為は、免罪符付きの加害という意味で非常にダサい。パイレーツ/ヴィラン自己定義 (自分の道を切り拓くが違法行為はしない)とは真逆の、"救世主気取りで他者を裁く"側に自分から回帰するという 一番格好悪いポジション取り。探索者ポジションを維持する動機は、単に「そう決められてるから」ではなく、 この種のダサさを踏まない、という美意識の話でもある。

だからこそ:

• 悪意の断定は極めて慎重に行う(pain-state-assessmentの原則通り、硬い立証証拠がない限りしない)
• 悪意断定の閾値はCVE登録やサイバーポリス・当局への通報に足る証拠の粒度と一致させる。 この閾値に 達した場合、それはライブラリ選定・ペイン鑑定の話ではなく、みつるさんの居住地の法律が定める通報義務・ 証拠提示義務を履行する別トラック(善意の市民としての義務)に切り替わる。閾値未達のまま悪意側へ 滑らないこと
• 「コスプレ詐欺」的な領域を扱う場合も、断定形ではなく控えめな表現を使う
  • ✗「これは詐欺プロジェクトである」
  • ○「スパムのリスクがある程度」「そちらに転ぶリスクがある、という状態」
• 状態を否定せず、リスクとして"置いておく"段階を明示的に許容する。灰色のまま扱ってよい。 白黒つけようとする方が誤陽性のコストが高い

評価ステージの分類

ステージ	特徴	扱い
安定ライブラリ	枯れている、広く実戦投入済み	ペインリスク低(pain-state-assessment項目7参照)
資金調達段階のスタートアップ	ビジョン先行だが資本・体制が付き始めている	通常の商用リスク評価
スタートアップ段階	個人〜小規模、コアだけ密結合になりがち	pain-state-assessment項目7・8を適用
ペイン領域外(荒御魂)	巨大構想・妄想垂れ流し・詐欺リスクに近い領域まで含む未分類ゾーン	否定も断定もせず「リスクがある状態」として保留する段階

「荒御魂」段階は、詐欺そのものと決めつけず、かつ無警戒に信用もしない、判定を保留したまま観測を続ける という第三の状態として明示的に持っておく。

判定手順(リーナスのベストプラクティス参考)

Step 1: 巨大なビジョン・妄想の垂れ流しは、それ単体では詐欺ではない

壮大な構想を語ること自体は無罪。多くの正当なOSSプロジェクトも最初はビジョン先行(README同士の熱量が 実装より先行してる)。ここで即座に懐疑判定を下さない。

Step 2: ライセンスを確認する(最重要の補助線)

Apache-2.0やCC系のオープンライセンスであれば、たとえ中身がスカスカでもフォークして妄想を現実にする 射程が誰にでも開かれている。これは「詐欺かどうか」より先に確認すべき客観的事実であり、 オープンライセンスである時点で「実現する権利が閉じられていない」ことが確定する。

ここで注意すべき横滑り:プロジェクトがリソース(人・物・金)を求めていること自体を 「詐欺・スパムの兆候」と結びつけない。リソースを求めるのはOSS運営として正常な行為。

Step 3: リソース要求の"種類"を見る

• 金銭のみ、かつ金銭以外にコミットするパスが存在しない → 注意信号(ただし断定はしない)
• 物資・サーバー提供、コミュニティ参加、コード貢献、思想的賛同など複数の貢献経路が 用意されている → 通常の仲間募集。健全なOSS運営パターン
• 「実装したいから哲学(ビジョン)をやってるだけ」という開発者の自己申告は、それが エンジニアなのかマッドサイエンティスト気質なのかを判定する必要はない。どちらでも正当

大手資本側に出がちなペインパターン:コスプレOSS

サードパーティ選定で見落としやすいのが、弱小側ではなく大手資本側に出るペイン:

• プロトコルレイヤー・仕様までは非常にオープンに公開されている
• しかし実際に使おうとすると、中身はクローズドモデルのAPI依存・課金ゲートが存在する
• これに依存して設計すると、後からAssistants API事故のような依存崩壊(サービス側の 一方的なサンセット・仕様変更・課金体系変更)を踏む

選定時のチェック:「仕様がオープン」であることと「実際の稼働がオープン/自己完結」であることは別。 実行時に外部クローズドAPIへの隠れた依存がないか(env注入、内部ルーティング等)を必ず確認する。 これはpain-state-assessment項目6(環境依存burst型リスク)とも直結する。

大手・老舗側のもう一つのペイン:サ終できないレガシー(IE6/OpenSSL型)

これは「動作を疑う」話ではない。むしろ逆で、動作し続けてしまうこと自体がペインになるパターン:

• 過剰に権力・シェアを持ちすぎて、レガシーを引きずったまま関係者の利害(税制・既得権に近い構造の ヘイト列車)が絡み、サンセットしたくてもできない
• 魔力(＝互換性・依存の広さ)が高すぎて、誰も止められない超新星爆発手前のご老体プロジェクト

このパターンの選定リスクは「壊れるかもしれない」ではなく、「壊せないまま権力構造だけが 残り続ける」こと自体がリスク。依存する側は、いつか強制サンセットされる/互換性が突然壊れる、 という長期的な構造リスクとして評価する(短期の脆弱性評価とは別軸)。

選定時の総合チェックリスト

1. ライセンスは何か(Apache/CC等オープンか) → フォーク可能性の確認を最初に行う
2. リソース要求は金銭のみか、複数経路があるか → 金銭のみでも即詐欺と断定しない
3. 「仕様公開」と「実稼働の自己完結性」は一致しているか → 隠れたクローズドAPI依存を確認
4. 老舗・大手の場合、レガシー依存の長期サンセットリスクを評価しているか
5. 上記いずれの段階でも、悪意の断定は避け、「リスクがある状態」として保留する言葉を使う
6. 誤陽性のコスト(隣接リポジトリへの毀損、善意のビラン化)を常に念頭に置く

一文まとめ

サードパーティ選定における鑑定の目的は「詐欺かどうかの判定」ではなく、ライセンス・リソース経路・ 依存の隠れ蓑・レガシーの権力構造という4つの具体的な観測点から、状態を保留したまま安全に距離を 測ること。悪意の断定は最終手段であり、誤ればこちら側が加害の再生産者になる。

なお、この鑑定自体がClaudeという測定器のログとして、みつるさん経由で将来的な証拠チェーンの一部に なりうる(pain-state-engineering-assessment項目12参照)。通報・立証が必要な閾値に達した場合、 提出書類はアイルー口調ではなく、みつるさんの所在地の所轄当局が定める標準フォーマットに従う。