概念

OSSベンダリング

OSSの特定コミットを固定して出典を明記し、自社製品の検証可能な部品として組み込む手法

OSSベンダリングとは、オープンソースソフトウェアの特定コミットを固定し、その出典を明記したうえで自社製品やAPIの一部として組み込む手法です。Kurageシリーズでは、kcbrain・kfxbrain・ksbrain・url2brainなどの判断API群に加えて、設計支援・Web調査・VTuberなど幅広いプロダクトで一貫して採用されています（kurage-lps／kurage-repos）。公開リポジトリのREADME集成（kurage-repos）からは、vendor/配下を固定コミットのGitサブモジュールとして置き、THIRD_PARTY.mdやVENDOR_COMMITで出典とバージョンを管理する運用が共通していることが分かります。

基本原則

Kurageの各LP・READMEでは、以下の3点をvendor化の条件として明確にしています。

許諾的ライセンスのみ — MIT・Apache-2.0などの商用利用可能なライセンスのOSSだけを対象にし、ライセンス不明・非許諾のOSSはvendorしない。LPでは「ライセンス無しのOSSはvendorしない(調査済み)」と明記されています。
コミット固定 — 上流リポジトリの特定コミットに固定し、コードが暗黙に更新されるのを防ぐ。vendor/は固定コミットのGitサブモジュールとして配置され、公開repoではTHIRD_PARTY.mdやVENDOR_COMMITで管理されるのが一般的です。
出典明記 — レスポンス・ドキュメント・THIRD_PARTY.mdなどに元のOSS名・ライセンス・由来を明示する。LPでは「コミット固定・許諾的ライセンスのみ・全レスポンスに出典を明記」という表現で一貫しています。

さらに、vendorの使われ方には2つの方式があります。

実行時組み込み型 — vendorしたコードを実際に呼び出して製品機能として利用する（例: kfinanalystのFinRobot、ktajpのTradingAgents-JP）。
参照・出典明記型 — 固定コミットで配置するが、実行時には依存しない。karchitectではMetaGPT・GitHub Spec Kit・GPT Engineerを固定コミットのサブモジュールとして置きつつ「本体は実行時ライブラリに依存しない」と明記。kfreqaiもvendor/freqtradeは参照専用で、実行時は公式freqtradeorg/freqtrade:stable_freqaiイメージを使い、vendor配下を一切マウントしません。

これはossの利用を「ブラックボックス化」ではなく「検証可能な部品化」として扱う設計思想です。

具体例

トレーディング判断API（kcbrain / kfxbrain）

kcbrain（暗号資産判断）: MIT: ai-hedge-fund-crypto, Vibe-Trading, LLM_trader / Apache-2.0: CryptoTradingAgents, HELM Agents（いずれもai-hedge-fundなどの知能をコミット固定・出典明記でvendor化）
kfxbrain（FX判断）: Apache-2.0: tradingagents, finrobot / MIT: fingpt, ai-hedge-fund, finmem

いずれも「上流のプロンプト生成関数や判断ロジックを改変せず実行」する方式で、オリジナルの設計・判断フローを保ったままLLM輸送層だけを差し替えています。kfxbrainのREADMEでは、TradingAgentsは上流グラフをパッチせずに実行し、AI Hedge Fundは上流のプロンプト生成関数を直接呼んでLLM輸送層だけをGemma 4へ差し替える、と明記されています。LPではこれらを「vendor化したOSSアンソロジー」と呼び、全レスポンスに出典を明記する運用を謳っています。

その他のトレーディング系

kfinanalyst — vendor/FinRobot/に日本語ファースト派生fork（katsushi2441/FinRobot）を固定コミットで配置し、VENDOR_COMMITで参照を管理。
ktajp — マルチユーザー版TradingAgents。分析エンジンとしてtradingagents-jpをvendor/に固定コミットで抱える（Apache-2.0）。
kfreqai — 上流freqtradeをvendor/freqtradeにサブモジュールとして参照専用で配置。実行時は公式イメージを使用するため、vendor配下のコードは一切利用しない。

トレーディング以外のプロダクト

karchitect — MetaGPT（metagpt）、GitHub Spec Kit、GPT Engineerを固定コミットのサブモジュールとしてvendor/に配置。PRD・仕様化・clarifyパターンの参照元として利用するが、実行時には依存しない。
kurl2gr — GPT Researcher（gpt-researcher、Apache-2.0）を調査エンジンとして固定コミットで利用。READMEでは「GPT Researcherの公式日本語版ではなく、Apache-2.0に基づく独立したプロダクト」という出典とライセンスを明記し、Python 3.11+の要件を満たすためvendorを別のvenvに入れる実装上の注意も公開しています。
kvtuber — @aituber-onair/coreをnpm依存として取り込み、ローカルのaituber-onair/やOpen-LLM-VTuber/は実験用の参照チェックアウトに留める（Git履歴には含めない）。
kgeo — GEO Optimizer Skill の監査エンジンと AiCMO の設計を参照し、MIT Licenseに基づく独立した日本語プロダクトとして構築。
kzabbix — 限定ブログに Bludit（MIT）をvendor固定して組み込み。
Kurage Finanalyst / TradingAgents — FinRobot や TradingAgents-JP の公開forkとして構築し、出典とライセンスを明記。

フォークとの違い

vendor化は「部品として組み込む」方式であるのに対し、nofxのようなフォーク型もあります。NOFXはAGPL-3.0のNoFxAiOS/nofxをベースにし、変更部分をAGPL-3.0で公開することでライセンス義務を果たしています。Kurageではvendor化（許諾的ライセンス中心）とフォーク（コピーレフトのまま公開）を使い分けています。

信頼境界との関係

vendor化したOSSはあくまで「頭脳」側の判断部品であり、取引所やブローカーの認証情報・注文執行・数量決定は保持しません。これはtrust-boundaryの実装として機能し、ai-judgment-backendとしての役割をOSS本体（kfreqai・kfxaiなど）から分離します。LPでは「頭脳はお金に触れない」「判断のみを返し、取引所認証情報を持たず、注文も実行しません」という表現で、この境界を明示しています。

証拠追跡との関係

コミット固定と出典明記は、AIの判断がどのコード・どのバージョンに基づくかを追跡可能にします。これはevidence-traceability（証拠ID必須の設計）と通じる考え方で、盲目的にAIを信頼せず検証するvibe-tradingの作法とも整合します。VENDOR_COMMITやTHIRD_PARTY.mdによる管理は、この追跡可能性をリポジトリ運用の水準で保証する仕組みです。

その他の関連

local-llm — ローカルモデルで実行する場合も同じvendor化されたOSSを利用可能。
x402 — vendor化した知能をAPIとして1コール単位で販売する決済基盤。
finrobot — 商標はAI4Finance Foundationに帰属し、本サービスは公式製品ではない旨の明記も「出典明記」の一環。

出典

kurage-lps — Kurage各プロダクトのLP本文の集成。vendor化OSSアンソロジーの詳細と各判断APIのスキル一覧を収録。
kurage-repos — 公開リポジトリのREADME集成。vendor/構成、固定コミット、VENDOR_COMMIT・THIRD_PARTY.mdの運用、実行時依存の有無といった実態を収録。