OSS AIを採用する前に読む：リポジトリ、重み、依存関係、運用

星は信頼の証明ではない

GitHubのスターは発見の入口にはなる。しかし、スターが多いから今も保守されている、脆弱性が少ない、モデル重みを商用利用できる、特定のGPUで動く、といった結論は出ない。OSSを採用する時は、コード、リリース成果物、依存パッケージ、モデル重み、ホスティング、運用者を別々に観察する。これを混ぜると、MITのランタイムを使うからモデルも自由だ、という誤読が生まれる。

1. 1候補発見
2. 2READMEと目的
3. 3LICENSEと配布物
4. 4release/tagを固定

1. 1依存関係
2. 2脆弱性・更新経路
3. 3小さな再現試験
4. 4採用判断

1. 1モデル重み
2. 2別のライセンス/カード
3. 3用途と再配布を確認

最初に確認するのは、誰が何を配布しているかである。GitHubのreleasesの説明が示すように、releaseは特定のtagに紐づく配布単位になり得る。main branchの最新コミットは、テスト済みの安定版を意味しない。再現したいならtagまたはcommit SHA、lockfile、コンテナdigest、モデルrevisionを記録する。latestを記録しても、明日の同じ実行を説明できない。

ライセンスは一枚では終わらない

OSIのライセンス一覧はコードのライセンスを読む入口になる。ただし、リポジトリのLICENSEだけでは依存ライブラリ、学習データ、モデル重み、フォント、サンプル、生成出力の条件を覆わない。各成果物の配布元と契約を追う。特にAIでは、コードがOSSでも重みは別途契約、研究用途限定、または未配布ということがある。

ライセンスの文言を自分で都合よく要約しない。使い方が商用・再配布・組込み・SaaSのいずれに近いかを整理し、疑義が重要なら権利担当者へ原文と用途を渡す。これは法的助言ではなく、技術者が採用前に残すべき事実である。LICENSEがない、重みの条件が見つからない、第三者配布だけがある場合は「採用しない」か「調査中」にする。

保守性は更新頻度だけでは測れない

直近のcommitが多くても、issueが解決されるとは限らない。逆に安定した小さなライブラリは更新が少なくても問題ない場合がある。見るべきは、目的に対して必要な変更が追えるか、security advisoryやissueの受付経路があるか、依存の更新が可能か、壊れる変更がrelease notesに記録されるかである。OpenSSF Scorecardの項目は、ブランチ保護、レビュー、依存更新などを観察する補助になる。ただしスコアだけで安全性を証明しない。

実行するコードは、READMEのコマンドをそのまま権限の強い環境で走らせない。まず隔離した開発環境で、依存をlockし、ネットワークアクセスと秘密情報を最小にする。インストールスクリプト、postinstall、ダウンロードURL、コンテナのroot実行を読む。AI agentやMCPサーバーなら、読めるファイル、渡すトークン、呼べる外部操作を最小権限にする。

評価はforkの数ではなく自分の仕事で行う

例えばRAGライブラリなら、検索精度だけでなく権限フィルタ、索引の更新、削除、引用位置、障害時の回復を見る。推論runtimeなら、対応モデル、量子化、メモリ、ストリーミング、同時利用、ログを測る。agent frameworkなら、tool引数の検査、途中停止、監査、プロンプト注入への境界を測る。各候補に同じ小さなシナリオを通し、通らない理由を「モデル」「ライブラリ」「自分の設定」に分ける。

1. 1仕事の代表例
2. 2受け入れ条件
3. 3候補A/Bを同条件で試す

1. 1成功
2. 2version固定
3. 3更新通知を登録

1. 1失敗
2. 2issue/仕様/設定を確認
3. 3回避策か不採用を記録

実習：採用カードを一枚作る

1. リポジトリURL、owner、目的、tag/SHA、release URL、LICENSE URLを記録する。
2. 実行する成果物とモデル重みを分け、各々のライセンス、ハッシュ、取得元を記録する。
3. 依存一覧とネットワーク・ファイル・secretへのアクセスを調べ、最小のsandboxで動かす。
4. 三つの代表タスク、失敗時の期待動作、計測方法を決める。性能数値はマシンと入力を併記する。
5. 更新担当、更新頻度、ロールバック方法、脆弱性連絡先を空欄にせず、決められないなら本番採用を保留する。

OSSは無料の部品置き場ではなく、関係を結ぶ相手である。公開性は自分で確かめ、固定し、更新できる自由を与える。その自由を運用へ変えるのが、この小さなカードである。

更新を受け入れる練習

採用後に最も危険なのは、更新を恐れて何年も止めることと、変更内容を読まずに追随することの両方である。依存を一つだけ上げる検証用branchを作り、lockfile差分、release notes、脆弱性修正、実行時の変更を確認する。代表タスクと起動・停止の試験が通れば段階的に出し、問題があれば前の固定版へ戻す。更新作業を月次の儀式にせず、通知を入口にして小さく判断する。

プロジェクトが停止したら、forkする前に代替、保守引継ぎ、依存の除去を比較する。forkは自由を与えるが、以後のsecurity patchと互換性の責任も引き受ける。自分が保守できる範囲を超える部品を核へ置かないことが、OSSを長く使うための現実的な設計になる。

利用者に見えるAI機能では、依存の更新を事前に知らせる運用も要る。出力形式、モデル対応、検索結果、認証方式が変わる更新は、内部のpatchとして扱わない。変更前後のサンプルを保存し、問題があれば固定版へ戻す判断者を決める。OSSの更新速度をそのまま利用者の変更速度にしないことが、長く安全に使う条件になる。

2024〜2026年の変化: AIサプライチェーンはソースコード以外のartifactを増やした

2024年のadoption cardには2026年の拡張が必要です。コード、container、model weights、prompt／skill package、リモートサービス契約を別artifactとして記録します。タグ付きリポジトリが再現可能でも、ダウンロードしたweightやpluginは変わることがあります。SLSAの仕様はprovenanceの語彙を提供しますが、attestationのないartifactを安全にしたり、licenseを解決したりはしません。

最初の本番ゲートを機械的にします。全実行物とweightのSHA／digestを解決し、可変tagを拒否し、依存・license inventoryを作り、ネットワークegressを制限し、空のsecret集合を持つ非特権IDで実行します。MCP serverやskillにはcapability inventoryを加えます。読めるdirectory、許可host、tool verb、書込みtarget、promptがそれらを変えられるかです。保守可能なプロジェクトには更新経路 と 削除経路が必要です。実データを付与する前に、隔離環境で両方を試験します。

GitHubはllama.cpp b11379を2026-10-03、vLLM v0.30.0を2026-09-22、ComfyUI v0.38.0を2026-09-29のreleaseとして記録している。release日は試験候補を示すだけで、信頼できるartifactを示さない。2026-09-20 のFP4推論についての r/LocalLLaMA 議論は未検証の経験報告であり、品質低下とthroughputを問う試験を作るためだけに使う。

Hugging Faceの2024年8月のLeRobot記事は、video storageとloadingを装飾的な実装詳細ではなくrobotics dataの制約として扱った。これはOSS運用に有用な教訓である。実行codeだけでなく、代表的なdata readerとfixtureもpinする。更新を承認する前にversioned episodeをreplayし、frame timestamp、observation、action rowを比べる。import成功だけでは互換なdata semanticsの証拠にならない。