Not Diamondとは

Not Diamondは、本番AIとcoding agentの各リクエストに対して、最適なmodelとreasoning effortを返すインテリジェントmodel routerだ。

gatewayやagent harnessを置き換えず、その上で「どのmodelに任せるか」だけを決める。出典

ストーリー

創業から成功に至るまでの道のり。

gatewayの隣に空いていた席

2026年8月、Not Diamondはcoding agent専用のrouter「Not Diamond Code」を発表した。

公式ブログの書き出しは、機能の説明ではなく問題の定義から始まる。

「Inference spend has increased dramatically in the past six months as individual developers and enterprises have adopted long-running, highly parallelized agentic workloads.」つまり、費用が増えた原因は単価ではなく、長時間・並列に走るagentの使い方そのものだ。出典

routerという選択

Not Diamondは、gatewayを作らない選択をした。

公式ブログはgatewayを「AI trafficのcontrol plane」、routerを「その上でどのmodelに任せるかを決めるdecision layer」と定義し、両者は別物だと繰り返し説明する。出典

この整理は、競合ではなく補完を選ぶ宣言でもある。

LiteLLM、Portkey、OpenRouter、Cloudflare AI Gatewayをgateway層の担い手として名指しし、自社はその上で動くと位置づけた。

企業がgatewayを自前で持ちたがる理由(privacy、governance、security)を理解したうえで、routingだけを外から提供する形に絞っている。

3年越しの一本線

公式ブログは、自分たちの来歴をこう要約する。

「We founded Not Diamond on an early belief that intelligent routing would become the most important infrastructure layer in the multi-model future.」beliefを語る記事は多いが、Not Diamondは2023年12月に世界初のオープンソースintelligent model routerを公開したと述べ、そこからrouting技術の発表を続けてきたと説明する。出典

2025年2月、DeepSeek R1が話題になった直後の記事では、熱狂ではなく構造を論じた。

「The reason DeepSeek R1 really matters is because it means the number of frontier AI models is about to explode」と書き、modelが増えるほど選択のコストが上がるという自社の前提を補強した。出典

計測できないものは売れない

routingの価値は、品質と費用の同時改善で示すしかない。

Not Diamondは2026年9月、静的なベンチマークではcoding agentの実態を捉えられないとして、interactive benchmarkの手法を公開した。

Harborへの機能追加にも共同で関わり、自社routerを第三者が測れる土台を整えている。出典

その結果として示されたのは、SWE-Interactで50.7%(1試行あたり$4.28)、SWE-Togetherで67.6%($4.16)、Dialogue SWE-Bench-Proで57.6%($3.00)という数値だ。出典

結び

Not Diamondの3年間は、modelを増やす話ではなく、modelを選ぶ判断を製品にする話だった。

gatewayの上に立ち、harnessに寄生せず、計測手法まで自分で用意する。

地味だが、AIスタックで最後まで自動化されずに残る作業を狙った順序だ。

独自分析

PMF (プロダクトマーケットフィット)

Not DiamondのPMFは、coding agentの推論費が想定より速く膨らみ、単一の最上位modelを全turnに使う運用が限界に来た開発組織にある。

公式ブログは、agentic workloadでは「高価なmodelを必要としない単純なリクエストが長く連なる」と説明し、そこで安いmodelへ寄せるとKV cacheが壊れて逆に高くつく場合があると指摘する。出典

つまり痛みは「modelを選ぶこと」ではなく「session全体のcostとqualityを同時に管理すること」にある。

Not Diamondはgatewayの上に立つdecision layerとして、modelとreasoning effortをturnごとに返す形でこの痛みを引き受ける。

gatewayを置き換えないため、既存の統制や契約を壊さずに導入できる点が、調達の意思決定を短くする。出典

示唆は、AIのコスト最適化が「 API単価の交渉」ではなく「どのmodelにどの仕事をさせるかの設計」へ移っていることだ。

参入障壁 (Moat)

moatは、coding agentの長いsessionを扱うroutingアルゴリズムと、その評価基盤の組立にある。

KV cacheの状態、reasoning effort、sub-agent構成、過去turnの履歴を入力に未来のrewardとcostを予測する手法は、単純な分類器では代替しにくい。出典

ただしmodelやharnessの変化が速く、技術的優位の寿命は短い。

ネットワーク効果

ネットワーク効果は中程度。

利用が増えるほどfeedback signalが集まり、routingの学習が進む設計だが、顧客ごとのworkloadは分断されやすく、横断学習の範囲は公式には明示されていない。出典

gateway非依存のため顧客基盤の囲い込みは弱く、効果はデータの蓄積速度に依存する。

ターゲット

対象は、Claude Codeなどのcoding agentを数十〜数百人で回し、月次の推論費が経営課題になっているplatform teamとエンジニアリングマネージャー。

SOC 2とISO 27001を前提に調達し、SSOやプライバシー要件を確認する大企業のAI基盤チームも主対象だ。出典

成功要因

第一に、routingという単一テーマへの集中だ。

2023年12月のOSS router公開から、2026年のcoding agent向けroutingまで、同じ問題を解き続けている。出典

第二に、ベンチマークを自社で設計し公開したことだ。

SWE-Interact、SWE-Together、Dialogue SWE-Bench-Proというinteractive benchmarkを使い、品質とcostの散布図でPareto優位を示した。出典

第三に、gatewayと競合せず接続する立ち位置だ。

LiteLLMやPortkey、OpenRouterなど既存gatewayの上で動くため、顧客は統制基盤を替えずにroutingだけを足せる。出典

失敗・課題

最大のリスクは、model側の改善速度にroutingの価値が飲み込まれることだ。

長いcontextと安い推論が標準になれば、「どのmodelを選ぶか」の差は縮む可能性がある。

Not Diamond自身も、routingは毎月解き直しが必要な問題だと認めている。出典

次に、公開ベンチマークの大半が自社計測であり、第三者が同じ条件で再現した数値は限られる。

Pareto優位や39〜61%のcost削減は公式発表であり、導入前に自社workloadでの検証が必要だ。出典

加えて、ARR・調達額・従業員数が非公開で、事業の持続性を外部から検証できない。

routing品質の評価には長いsessionのログが必要で、導入初期は効果測定そのものが負担になる。

グロース戦略

成長戦略は、開発者向けのdocsとAPIから入り、coding agentのcost削減という測定しやすい課題で価値を示し、最後にenterpriseの統制要件へ広げる順序だ。

Pay-as-you-goは100万routing tokenあたり$0.05で、小規模チームでも試しやすい。出典

並行して、SAPのAI Foundationのように既存platformのprompt最適化機能へ組み込まれるOEM的な広がりを狙う。

問い合わせはgatewayを自前で持ちたい企業が多く、routerだけを外から足す形が導入摩擦を下げる。出典

トレードオフは、効果がworkload依存で営業時に示しにくいことだ。

主要チャネル: documentation, content, developerCommunity, enterpriseSales, github, partnerships

学べること

学べるのは、コスト最適化を「単価」ではなく「意思決定の回数」で捉える視点だ。

agentは1タスクで何十回もmodelを呼ぶため、各回の選択が積み上がって総額になる。

その意思決定を計測可能な形で外に出せば、それ自体が製品になる。出典

また、既存の統制基盤を置き換えずに隣接レイヤーを取る戦略は、AIスタックのどの層でも応用できる。

日本で展開するなら

日本では、生成AIの社内利用規定と監査ログが整った大企業ほど「model選択の妥当性」を説明する必要が強い。

どのmodelをなぜ選んだかをsession単位で記録できるrouterは、稟議資料と運用監査の両方に効く。

国内リージョンや委託先の扱いは要確認だが、既存gatewayの上に載せる形なら調達範囲を広げずに導入できる。出典

主な競合

Timeline

創業から成功に至る道のり。転機ごとの収益・調達・バリュエーション (出典あり) も併記します。

  1. ローンチ出典

  2. GitHub organization「Not Diamond」が作成され、model routerの開発が公開の場で始まった。出典

  3. 公式ブログによれば、世界初のオープンソースintelligent model routerを公開した。出典

  4. LLM応答に対する人間選好ランキング150万件を公開し、routingの評価データ基盤を外部に示した。出典

  5. DeepSeek R1公開直後に、単一model依存からの脱却を説くmulti-model論を公式ブログで発表した。出典

  6. prompt adaptationを発表し、modelごとに書き換えが必要なpromptの移植問題へ製品領域を広げた。出典

  7. Prompt Optimizationを一般提供開始。SAPはAI Foundationのprompt optimization機能をNot Diamondとの共同開発で更新した。出典

  8. coding agent向けのNot Diamond Codeを発表し、harnessとgatewayに依存しないrouting構成へ進んだ。出典

  9. interactive benchmarksの手法を公開し、Harborへのinteractive benchmark対応を共同で追加した。出典

  10. 収益スナップショット出典

ポジショニング

分析で挙げた競合プロダクトとの相対位置を示しています。

gatewayではなく、その上でmodelとreasoning effortを選ぶdecision layer。enterprise向けだがgatewayより適用範囲は狭い。

参考リンク

関連プロダクト

AI Infrastructure

LiteLLM

LiteLLMは、複数のLLM providerをOpenAI互換の入力形式で呼び出し、proxy・routing・observabilityを一つのgatewayにまとめるOSS基盤。

United States · 2023 年 · 出典 11

#AI infrastructure#Open Source#Developer Tools

AI Agent

CrewAI

CrewAIは、複数のAIエージェントに役割・目標・背景を与えてチーム(Crew)として協調させ、その上にイベント駆動のFlowを置いて業務の流れと状態を制御するオーケストレーション基盤。Python製のOSSフレームワークと、trace・RBAC・監査を担う商用のCrewAI AMPで構成する。2023年10月にJoão MouraがClearbit在籍時の業務自動化から作り始め、2024年1月に会社として始動した。ノーコードのビジュアルエディタで組んだagentic workflowをPythonコードとして出力でき、MCPサーバーとして持ち出すこともできる。公式は月4億5000万回規模のagentic実行と、Fortune 500の6割での利用を挙げている。

United States · 2023 年 · 出典 16

#Open Source#Agent Orchestration#Python

AI Agent

Relevance AI

Relevance AIは、AIエージェントとマルチエージェントのチームを、コードを書かずに組んで運用するプラットフォーム。「AI Workforce」と呼ぶ考え方を掲げ、営業、カスタマーサポート、運用の定型業務をエージェントのチームに委ねる。2025年1月だけで4万個のエージェントが作られ、同年5月にBessemer Venture Partners主導で$24MのSeries Bを調達した。2026年9月には、エージェントを組み立てるだけでなく管理し続けるInvent 2.0を発表している。

Australia · 出典 15

#no-code#AI Workforce#AI Agent

Collaboration / Productivity

Guru

Guruは、社内に散らばったドキュメントやチャットの会話から知識を構造化し、検証済みの「唯一の正」として人とAIエージェントの双方へ届けるknowledge layer。Rick NucciとMitchell Stewartが2013年にフィラデルフィアで創業し、Boomiで経験した「情報が古くなる」課題を出発点に、Chrome拡張から始まった。現在はSlackやブラウザ、MCP経由のAIツールへ、権限に沿った引用付きの回答を配信する。

United States · 2014 年 · 出典 21

#Slack#knowledge governance#MCP