Heliconeは、ゲートウェイ機能を備えたオープンソースのLLMオブザーバビリティプラットフォームで、リクエストログ、トレーシング、コスト帰属、プロキシ機能を提供します。この検索が存在する理由は、特定の出来事です。Mintlifyが2026年3月にHeliconeを買収し、現在このプラットフォームはメンテナンスモードに入っています。セキュリティ更新、バグ修正、新しいモデルのサポートは継続していますが、積極的な機能開発は終了しています。これが判断を左右すべき事実であり、Helicone自身の発表には明記されています。一方、このクエリで上位に表示されるベンダー比較記事では、ほとんど触れられていません。
偏りについて明示します。ここでは当社に不利な内容です。Kunavoはオブザーバビリティをまったく提供しておらず、ログ記録も、トレーシングも、評価もありません。Heliconeが担っていた監視部分について、当社は選択肢ではなく、このページでそれを装うこともしません。Kunavoが関係するのは、Heliconeをゲートウェイとして使っていた場合だけで、その場合でも仕組みは異なります。
まず、実際にどちらの部分を使っていましたか？
「Heliconeの代替」を検索すると、互いに代用できない2種類の答えが返ります。Heliconeが2つの役割を担っていたためです。分けて考えると、リストの大半を除外できます。
- オブザーバビリティ — LLM呼び出しの状況を確認するためにHeliconeを追加していた場合です。対象は、リクエストログ、レイテンシ、トークン数、ユーザーまたは機能ごとのコスト、評価です。代替は別のオブザーバビリティツールであり、以下のゲートウェイのセクションは関係ありません。
- ゲートウェイ — Heliconeを経由して呼び出しをルーティングしていた場合です。1つのエンドポイント、キー管理、プロバイダー間のフェイルオーバーを利用します。代替はゲートウェイであり、オブザーバビリティツールでは対応できません。
- 両方 — その場合は2つのものを置き換えることになります。両方を十分にこなす1製品を探すより、通常は2つのツールで対応するほうがすっきりします。
オブザーバビリティに使っていた場合
Heliconeから移行する多くのチームがオープンソースの選択肢に行き着くのは、Heliconeを魅力的にしていた性質、つまりセルフホストしてリクエスト本文を自社インフラ内に保持できることを維持できるからです。Langfuseが最も一般的な移行先で、トレーシング、評価、コスト帰属に対応しています。Arize PhoenixはMLオブザーバビリティ側から生まれた製品で、評価に強みがあります。どちらもセルフホスト可能です。ここではカテゴリを示す候補として挙げているだけで、両者の比較を実施したわけではありません。また、ゲートウェイベンダーがオブザーバビリティツールを順位付けしても、価値は高くありません。
この検索結果には、ホスト型プラットフォームも複数存在し、自社製品を1位に掲載しています。それを理由に評価を下げる必要はありませんが、誰が比較記事を書いたのかを踏まえて読むべき理由にはなります。このページも同様です。
ゲートウェイとして使っていた場合
その場合、すべてのゲートウェイ選びが最初に問うのと同じ問題になります。プロバイダーの認証情報を誰が保有するのか？HeliconeはBYOキー、つまり利用者のアカウントとHeliconeのプロキシという構成です。同じ構成の代替は、LiteLLM self-hosted、またはホスト型のBYOキー制御プレーンです。なお、最も引用されるホスト型の選択肢であるPortkeyは、それ自体がPalo Alto Networksによる買収の対象になっています。買収されたベンダーから別の買収対象ベンダーへ移行するのは、明確な選択です。意図を持って決めてください。
Kunavoはもう一方の構成です。上流の認証情報を当社が保有するため、プロバイダーアカウントを管理する必要がなく、自分のアカウントへルーティングすることもできません。アカウントの保有自体が負担だったチームには適していますが、プロバイダーと料金を交渉済みなら不適切な選択です。KunavoとHeliconeの比較 · 4つのゲートウェイカテゴリ
多くのリストが省略する、使い続ける理由
メンテナンスモードはサービス終了ではありません。サービスは稼働し、セキュリティパッチと新しいモデルのサポートを受け、ソースコードはGitHubにあります。そのため、ホスト型製品に何が起きてもセルフホストへ移行できます。デプロイが安定しており、ロードマップ上の項目を待っていなかったなら、移行によって、存在しないかもしれない問題を解決するための実際のエンジニアリング時間が必要になります。移行の正直なきっかけは「買収された」よりも限定的です。今後決して提供されない機能が必要になった、契約の複数年更新時期を迎えた、またはホスト型の条件が変わった場合です。
このことが、このカテゴリのベンダー選びについて示すこと
Heliconeは2026年3月に買収されました。Palo Alto Networksは2026年4月にPortkeyを買収する意向を発表しました。このカテゴリの独立した2つのベンダーが、2か月以内により大きなプラットフォームへ統合されました。そのため、「この製品は2年後も独立しているか」が売り文句ではなく、実際の選定基準になります。
有効なヘッジは、誰も買収しないベンダーを選ぶことではありません。それは予測できず、またこのページはベンダーが書いているため、ここでの永続性に関する主張は相応の懐疑心を持って受け止めてください。ヘッジとは、信頼できる退出手段を備えたツールを優先することです。セルフホスト可能なオープンソース版、または離脱がベースURLの変更で済むほど標準的なワイヤプロトコルです。Heliconeには前者があり、だからこそ買収後も利用を継続できます。ほとんどのゲートウェイには後者があります。このページの各製品はOpenAIまたはAnthropicのワイヤを話すため、機能比較が示すよりも切り替えコストははるかに低くなります。
よくある質問
Heliconeはどうなりましたか？
Mintlifyは2026年3月にHeliconeを買収しました。Helicone自身の発表とMintlifyの発表によると、創業者のJustin TorreとCole GottdankはサンフランシスコでMintlifyに加わり、約16,000の組織に利用されていたこのプラットフォームは、セキュリティ更新、バグ修正、新しいモデルのサポートを行うメンテナンスモードで継続しています。積極的な機能開発は終了しました。現在もオープンソースであるため、ホスト型製品のロードマップにかかわらずセルフホスティングは引き続き利用できます。
最適なHelicone代替は何ですか？
LLMのオブザーバビリティ、具体的にはログ記録、トレーシング、コスト帰属、評価に限って言えば、最も多くのチームが移行するオープンソースの選択肢は、どちらもセルフホスト可能なLangfuseとArize Phoenixです。この検索結果には、ホスト型プラットフォームも複数存在します。Heliconeを主に監視ではなくゲートウェイとして使っていた場合、必要なのはオブザーバビリティツールではなくゲートウェイであり、候補は別のリストになります。
買収後もHeliconeは使えますか？
はい。メンテナンスモードとは、サービスが稼働し、セキュリティパッチ、バグ修正、新しいモデルのサポートを受ける状態を意味し、サービス終了を意味するものではありません。デプロイが安定しており、ロードマップ上の項目を待っていなかったのであれば、使い続けるのは妥当な判断です。また、オープンソースリポジトリがあるため、ホスト型製品が変わってもセルフホストへ移行できます。ただし、機能開発が停止していることを織り込まずに、新たに複数年契約を結ぶべきではありません。
KunavoはHeliconeの代替ですか？
オブザーバビリティについては違います。Kunavoはログ記録、トレーシング、評価を行わず、「LLM監視を置き換えたい」という問いに対する答えになるこのページの版もありません。Kunavoが関係するのはHeliconeが担っていたゲートウェイ部分だけで、そこでも仕組みは異なります。Heliconeは利用者が保有するプロバイダーアカウントを通じてリクエストをプロキシしますが、Kunavoは上流の認証情報を保有し、利用量に応じて請求します。
LLMオブザーバビリティツールとLLMゲートウェイの違いは何ですか？
オブザーバビリティツールは、リクエスト、レスポンス、レイテンシ、トークン数、ユーザーまたは機能ごとのコストなど、何が起きたかを記録します。呼び出しのルーティング方法を変更せずに追加できます。ゲートウェイはリクエスト経路に入り、認証、ルーティング、フェイルオーバー、支出制限を処理しながら、リクエストの送信先を決定します。両方を行う製品も複数あるため、カテゴリが混同されやすく、「Heliconeの代替」を検索すると2種類の異なる答えが返ります。代替製品を選ぶ前に、自分が実際に使っていたのがどちらの部分かを確認してください。
買収によってゲートウェイベンダーの選び方を変えるべきですか？
このカテゴリでは、ベンダーの独立性が単なる売り文句ではなく、実際の選定基準だと考える十分な根拠になります。Heliconeは2026年3月にMintlifyに買収され、Palo Alto Networksは2026年4月にPortkeyを買収する意向を発表しました。2か月間に2件の統合が起きたことは、ひとつのパターンです。実際的なヘッジは、誰にも買収されないベンダーを選ぶことではありません。セルフホスト可能なオープンソース版、または切り替えがベースURLの変更で済むほど標準的なワイヤプロトコルなど、信頼できる退出手段を備えたツールを優先することです。