Milos RusicがHaystackをOSSのpipelineから企業向けAI基盤へ広げた道のり

冒頭：AIをつなぐ前に、制御できる形へ

Milos RusicはdeepsetのCEO & Co-Founderとして、HaystackをRAGとAI agentを「一度動くdemo」から検証できるpipelineへ移すopen-source frameworkとして育てている。出典

Haystackは、RAGとAI agentを「一度動くdemo」から、検証できるpipelineへ移すためのopen-source frameworkだ。

deepsetの公式説明では、2018年にcustom language AIへ取り組み、2020年にはその経験をもとにHaystackを開発した。出典

創業：custom language AIの経験

deep­setは、AttentionとBERTが新しい言語AIの波を作った2018年から、企業向けのcustom language AIを手がけた。出典

この時点で見えていたのは、モデルを呼ぶだけでは業務の検索や知識利用にならないという問題だった。

転機：HaystackをOSS frameworkにする

2020年、deepsetは経験をHaystackへまとめた。

公式AboutはHaystackをopen-source Python frameworkと説明し、AI agentとapplicationの基盤へ位置づけている。出典

Malte PietschはCTO & Co-Founderとして、Milos RusicはCEO & Co-Founderとしてこの方向を率いる。出典

成長：pipelineを企業の現実へ近づける

Haystackはretrieval、routing、memory、generationをcomponentとして組み合わせる道を選んだ。

公式GitHubは、RAG、multimodal application、semantic search、agent workflowを対象に掲げる。出典

Airbusのcase studyでは、tableとtextを組み合わせたQAなど、企業データを扱う具体的な利用例が示されている。出典

現在：OSSからenterprise platformへ

現在のdeepsetは、Haystack Enterprise Platformでenterprise AI offeringを統合し、agentのtracesやmanaged MCP toolsまで扱う。出典

これはOSSを捨てる話ではない。

自由に組み立てたい開発者と、統制して本番運用したい企業を、同じpipelineの考え方でつなぐ試みだ。

LLMアプリケーションは、prototype段階では動いても、retrieval・routing・memory・generationの責務が混ざると本番運用で検証しにくい。

Haystackはcomponentとpipelineを明示し、RAGやagent workflowをコードとして組み立てられる点で、制御可能性を重視する開発チームに刺さる。出典

企業ではデータ所在、モデル選択、評価、監査の要求が同時に来る。

Haystackはopen-source基盤を入口にenterprise platformへ接続し、自由度と導入支援の間を埋めようとしている。出典

moatは単一モデルではなく、component設計、integrations、OSSの実装知、enterprise運用の組み合わせにある。

利用者が既存pipelineと評価手順を積み上げるほど、別frameworkへの移行コストが増す。出典

中程度。

利用者が増えるほどintegrations、examples、issue解決の知識は増えるが、pipelineの価値は単独でも成立する。

GitHubと周辺integrationが参加の接点になる。出典

PythonでRAG、semantic search、AI agentを本番化するdata / ML engineerと開発チーム。

promptだけで試す個人より、pipelineの可観測性・テスト・権限を必要とする組織向け。出典

第一に、retrievalからagentまでをmodular componentで表現し、ブラックボックス化を避けたこと。出典

第二に、GitHub・integrations・技術blogを通じて実装知を公開し、OSS利用の入口を広げたこと。出典

第三に、enterpriseのgovernanceとopen-sourceの拡張性を同じ系譜で扱う方針である。出典

OSSの柔軟性は、pipeline設計、評価、モデル選択、依存関係の管理責任を利用者に残す。

RAG品質はデータとevaluation設計に左右され、framework単体では解決しない。

また、Haystack Enterprise Platformの価格やARR、顧客構成は公開情報だけでは要確認で、商用化の進捗を外部から定量比較しにくい。

open-source frameworkをGitHubとcontentで広げ、RAG・agentの実装者を獲得する。

その後、監査・権限・運用・導入支援が必要な企業へHaystack Enterprise Platformを提案する二層構造だ。

OSSの自由度を損なわず、enterpriseの価値をどこに置くかが継続的なトレードオフになる。出典

主要チャネル: open_source_community, github, content, partners, sales

AI frameworkの差別化は、モデルAPIのラッパーよりも、責務を分解し、失敗箇所を追跡できる設計に宿る。

OSSで入口を広げるなら、enterprise機能は自由度を奪うのではなく、監査・運用という別の痛みに対応させるべきだ。

日本企業で導入するなら、まず社内検索やFAQの小さなRAG pipelineから始め、retrieval評価・個人情報の除外・回答根拠のログを先に定義したい。

モデルの精度競争だけでなく、誰がどのデータを使い、失敗時にどこを直すかをpipeline単位で管理する発想が、規制業界との相性を左右する。