強気

コンフルーエント

強気

弊社のDCFモデルに基づくと、同社の1株当たりの本質的価値は33.23ドルとなっており、現在の株価は約21ドル程度となっていることから、弊社のDCFモデルに基づく目標株価対比では約50％程度割安となっています。

すべて表示

Part 3：コンフルエント（CFLT：Confluent）の将来性：KafkaとFlinkのマネージドサービスとその強みとは？

• 本稿では、コンフルエント（CFLT：Confluent）のKafkaとFlinkのマネージドサービスと同社のテクノロジー上の強み（競争優位性）を深掘りすることで、同社の将来性を詳しく解説していきます。
• ストリーム処理は、コンフルエント（CFLT）にとってTAM（総アドレス可能市場）を大幅に拡大する要素となるでしょう。
• Flinkを利用したKafkaの階層型ストレージと組み合わせたストリーム処理は、リアルタイムアプリケーションや分析市場で大きなシェアを獲得できる強力なコンビネーションです。
  
• これが成功すれば、コンフルエントはストリーミング・レイクハウス分野で主要なプレイヤーになる可能性があります。
  
• さらに、HTAP（ハイブリッドトランザクションと分析処理）やデータアプリケーションの分野でも大きな可能性を秘めています。
  
• Kafkaと同様に、Flinkにも技術的負債の問題がありますが、コンフルエントがKafkaで達成した成功をFlinkにも適用し、最終的にはFlinkをサービスとして提供できると確信しています。
  
• Icebergを基盤にストレージを一元化するのは、コンフルエントにとって非常に賢明な戦略です。Icebergによる階層型ストレージとConfluentのガバナンスの組み合わせは、多くの顧客に強く響くことでしょう。
  
• ただし、DatabricksによるTabularの買収やスノーフレーク（SNOW）のPolaris Catalogのリリースは、将来的にコンフルエントが乗り越えるべき課題となるかもしれません。
  

※「Part 2：コンフルエント（CFLT）オープンコアとConfluent Cloudの成功、Kafka再定義による競争優位性と成長戦略」の続き

コンフルエント（CFLT）とイベントストリーミングとストリーム処理の概要

イベントストリーミングは、プロデューサー（例: ユーザーのクリックやIoTセンサー）から発生したイベントを収集し、コンシューマー（例: ダッシュボードやライドシェアアプリ）に配信する仕組みです。一方、ストリーム処理は、これらの生データをリアルタイムで変換・分析し、より深い洞察を提供します。これは、リアルタイムデータウェアハウスに似ています。イベントストリーミングの分野ではKafkaがリーダーであり、ストリーム処理ではFlinkが優れています。コンフルエント（CFLT）は、KafkaとFlinkのマネージドサービスを提供しており、2023年1月にはFlinkの商用エンティティであるImmerokを買収しました。

関連用語

Kafka: 分散型メッセージングシステムで、イベントストリーミングに利用されるプラットフォーム。リアルタイムで大量のデータを処理・配信する。

Flink: リアルタイムデータストリーム処理を行うオープンソースの分散コンピューティングエンジン。ストリームデータを処理し、分析をリアルタイムで行うことができる。

マネージドサービス: クラウドプロバイダーが提供するサービスで、インフラ管理をクラウド側に任せ、ユーザーは運用やメンテナンスをせずに利用できるもの。

Immerok: Flinkの商用エンティティで、2023年にコンフルエントによって買収され、Flink関連のサービス提供に力を入れている。

コンフルエント（CFLT）のストリーム処理分野への拡大に関して

Kafkaの普及状況を踏まえると、次のような点が注目されます。

・Fortune 500企業の80%が使用

・Pub-Sub、ストリーミング、イベント駆動型アーキテクチャ（EDA）の標準となっている

・Redpandaなどの競合も、Kafka APIの進展に追随している

Kafkaはイベントストリーミング市場での普及がほぼピークに達しつつありますが、コンフルエント（CFLT）はその高い評価を維持するために新しい成長戦略が求められています。ひとつのアプローチとしては、Kafkaをリアルタイムデータ共有の基盤としてさらに統合を深める方法が考えられます。また、別の選択肢としては、垂直統合によってシナジー効果を活かし、顧客の投資利益率（ROI）を高めることです。

重要な機能である「ティアードストレージ」は、データをローカルディスクではなくオブジェクトストレージに保存することで、スケーラビリティとコスト効率を大幅に向上させます。これにより、Kafkaは運用データベースやレイクハウスとしても活用できるようになり、Databricksやスノーフレーク（SNOW）などのプラットフォームへのデータ移行が不要になります。

コンフルエントは、イベントストリーミングからストリーム処理への拡大を進めている唯一のリーダーです。一方で、Databricksやスノーフレークはバッチ処理からストリーム処理へと移行し、リアルタイム分析を加速させています。この動きにより、レイクハウス（Databricksやスノーフレークの領域）とリアルタイムストリーム処理の役割が融合しつつあり、コンフルエントは進化するデータ分析市場において、これらの企業に対抗する存在としてさらに強力な競争力を持つようになっています。

関連用語

Pub-Sub: パブリッシュ・サブスクライブモデルの略で、発行者（パブリッシャー）と購読者（サブスクライバー）がメッセージをやり取りする通信モデル。

イベント駆動型アーキテクチャ（EDA）: イベントをトリガーにシステムの動作を制御するアーキテクチャ。リアルタイムでのデータ処理に適している。

Redpanda: Kafka互換の分散型ストリーミングデータプラットフォームで、Kafkaの代替として利用されることもあります。

ティアードストレージ: ストレージを階層化し、頻繁にアクセスされるデータを高速ストレージに、あまり使われないデータを低コストなストレージに保存することでコスト効率を高める技術。

レイクハウス: データレイクとデータウェアハウスの機能を組み合わせたアーキテクチャ。構造化・非構造化データの両方を扱うことができ、分析が可能。

データレイク: 構造化データや非構造化データをそのままの形式で大量に保存するリポジトリ。さまざまな種類のデータを一元管理し、後から分析や処理に利用することができる。

バッチ処理: 大量のデータを一括して処理する方法で、リアルタイムではなく、定期的な処理に使われる。

データ管理の大きなトレンドは、統合に向かっています。ここでは、構造化データ、非構造化データ、リアルタイムデータの管理に関する主要な概念がどのように進化してきたかを簡単にまとめます。

データマート（1990年代）

特定のビジネス分野向けに構築されたデータウェアハウスのサブセットで、通常は社内で構築されていました。

データウェアハウス（1990年代後半〜2000年代）

複数のデータソースから集められた構造化データの集中リポジトリ。主要なベンダーはテラデータ（TDC）、オラクル（ORCL）、IBM（IBM）、マイクロソフト（MSFT）です。

データレイク（2000年代後半〜2010年代）

構造化・非構造化データをそのままの形式で保存するもの。代表的なベンダーにはHadoop、Cloudera、Hortonworksがあります。

ストリーム処理（2010年代）

リアルタイムデータストリームを処理し、分析に活用する技術。Apache Storm、Spark、Kafkaが主な例です。

クラウドデータウェアハウス（2010年代中頃）

クラウドベースのデータウェアハウスで、スケーラビリティと柔軟性を提供。Amazon Redshift（AMZN）、Google BigQuery（GOOG/GOOGL）、スノーフレーク（SNOW）が代表的なベンダーです。

レイクハウス（2010年代後半）

データレイクとデータウェアハウスを統合し、BI（ビジネスインテリジェンス）とデータサイエンスの両方に対応するアーキテクチャ。AWS（AMZN）やGoogle Cloud（GOOG/GOOGL）が主要ベンダーです。

ストリーミングレイクハウス（2020年代）

リアルタイムのストリーミングデータを扱うレイクハウス。Kafka、Flink、Hudi、Icebergが主要な技術です。

全体的な流れとしては、データウェアハウスとデータレイクが統合されてレイクハウスへ進化してきました。同時に、レイクハウスがストリーム処理とも融合しつつあります。コンフルエントのKafkaは、イベントストリーミングにおいてリーダー的存在であり、スノーフレークやDatabricksなどのバッチ処理ベンダーとストリーム処理を統合する中で重要な役割を果たしています。

Flink

Flinkは、Apacheによるオープンソースのストリーム処理プロジェクトで、ドイツで開発され、2014年にリブランドされました。2019年にはアリババ（BABA）がFlinkの開発元であるVervericaを買収しましたが、後にその開発チームは新会社Immerokを設立し、最終的にコンフルエントに買収されました。

コンフルエントは2023年1月にImmerokを1億ドルで買収しましたが、すでにKafka StreamsやksqlDBを持っていました。それにもかかわらず、コンフルエントの独自のストリーム処理技術は発展途上で、成熟度や実績に欠けていたため、真剣なユーザーはFlinkを選ぶ傾向がありました。リソースの割り当ても限られていたため、開発が遅れました。

関連用語

Apache: オープンソースソフトウェアのプロジェクト群を提供するApache Software Foundation（ASF）のこと。多くの有名なソフトウェア（例: Apache Hadoop、Apache Kafka、Apache Flinkなど）が含まれ、オープンソースコミュニティによって開発・運営されている。

Kafka Streams: Apache Kafkaに組み込まれたストリーム処理ライブラリで、リアルタイムのデータストリームを分散処理するためのツール。Kafka内で直接データを処理でき、外部の処理フレームワークを必要としない。

ksqlDB: Kafka上で動作するSQLベースのストリーム処理プラットフォーム。SQLクエリを使用してリアルタイムでデータストリームを処理、フィルタリング、変換できるため、開発者が複雑なプログラムを書くことなくストリーム処理を行える。

コンフルエント（CFLT）を取り巻くストリーム処理における競合とFlinkのメリット・デメリット

ストリーム処理自体は新しい概念ではありませんが、消費者向けインターネットの成長に伴い、その需要が増加しています。アリババ（BABA）やウーバー・テクノロジーズ（UBER）のような企業は、大量のデータをリアルタイムで処理する必要があります。例えば、ウーバー・テクノロジーズの到着予定時刻（ETA）の機能は即座に更新され、リアルタイムで素早い応答が求められます。このため、ウーバー・テクノロジーズはKafka、Flink、Hudiなどを活用したモダンデータスタックを使用していますが、これはエンジニアリングの負担が大きいです。従来は、企業はOLTPシステムでトランザクションデータを処理し、OLAPシステムで分析を行ってきました。しかし、リアルタイムのニーズが高まるにつれて、バッチ処理とリアルタイム分析層を組み合わせたLambdaアーキテクチャが導入され、より迅速にインサイトを得るようになっています。

2020年から2023年にかけて、データレイクとデータウェアハウスが統合されました。次のステップとして、ストリーミング処理とバッチ処理が統合され、「ストリーミングレイクハウス」という新しい形態が登場します。ウーバー・テクノロジーズはこの技術を早くから取り入れ、Hudiというストリーミングレイクハウスエンジンを導入しました。Hudiは、データレイク、データウェアハウス、バッチ処理、ストリーム処理を1つのアーキテクチャに統合しています。コンフルエント（CFLT）も同様の高度な技術を製品として提供しており、企業は独自の研究開発コストを削減することができます。そのため、Flinkは、コンフルエントの戦略において重要なストリーム処理ツールであり、Spark StreamingやRisingWaveと競合しています。

関連用語

OLTPシステム: オンライン取引処理（Online Transaction Processing）の略で、リアルタイムで大量のトランザクション（取引データ）を処理するシステム。主に銀行、ECサイトなどで利用される。

Lambdaアーキテクチャ: リアルタイムデータとバッチ処理を組み合わせたデータ処理アーキテクチャ。リアルタイムの高速処理と、バッチ処理による正確なデータ分析の両方を実現する。

Hudi: Apache Hudiは、データレイク上でリアルタイムにデータを処理・管理するためのオープンソースツール。バッチ処理とストリーム処理を統合する機能を持ち、データレイクの効率的な更新やクエリを可能にする。

Spark Streaming: Apache Sparkに組み込まれたストリーム処理フレームワーク。リアルタイムのデータストリームを処理・分析するために使われ、分散処理をサポートする。

RisingWave: 分散型のストリーミングデータベースで、リアルタイムデータ処理を効率的に行うために設計されている。ストリームデータをSQLクエリで簡単に処理できるのが特徴。

Google Dataflowはクローズドソースのツールですが、オープンソースコミュニティによって開発されたApache Beamはその設計を模倣しています。

しかし、Beamは主流にならず、リリース後すぐにFlinkに取って代わられました。

コンフルエントが開発したksqlDBは、機能が豊富なオープンソースのFlinkと比べると、依然として独自仕様で小規模なままです。2013年に登場したSpark Streamingは、Sparkにストリーミング機能を追加しましたが、Sparkのバッチ処理の制約を受けています。Spark Streamingは本格的なストリーム処理機能がなく、代わりにマイクロバッチ処理を行っています。そのため、サブセカンド（1秒未満）のレイテンシが求められるワークロードには適していますが、リアルタイム処理には対応できません。

関連用語

クローズドソース: ソフトウェアのソースコードが公開されておらず、開発者や特定の企業のみがアクセスできるもの。Google Dataflowのようなツールがその例。

Apache Beam: オープンソースのデータ処理フレームワークで、バッチ処理やストリーム処理を一貫したプログラミングモデルで行えるように設計されている。さまざまなデータ処理エンジン（Flink、Sparkなど）と互換性がある。

Spark: Apache Sparkは、分散データ処理のためのオープンソースフレームワークで、主に大規模なバッチ処理、ストリーム処理、機械学習、グラフ処理などに利用されます。高いパフォーマンスと使いやすさが特徴。

Flinkは、ストリーム処理システムにおいて最高レベルの正確さを提供します。その正確さは次の要素で定義されます：

・一貫性: 障害が発生しても、すべてのデータイベントが一度だけ確実に処理されること。

・完全性: データストリームの順序が乱れても、最終的に正しい順序で結果を得られること。

Flinkはバッチ処理とストリーム処理を統合した高度なアーキテクチャを備えており、強力なチェックポイント機能により信頼性の高いリアルタイム処理が可能です。また、Confluent Cloudでは、Flinkは「一度だけ処理される」という厳密な処理保証を提供しています。Flinkは低レベルのDataStream APIとFlinkSQLを提供し、分析に活用できますが、Trinoやスノーフレークほどの使いやすさはありません。

関連用語

DataStream API: Flinkが提供するストリーム処理のための低レベルAPIで、リアルタイムデータストリームを柔軟に操作・処理できるプログラミングインターフェース。

FlinkSQL: Flinkで使用できるSQLベースのインターフェースで、データストリームをSQLクエリを使って簡単に処理・分析できる機能。

コンフルエント（CFLT）を取り巻くストリーム処理における競合とFlinkのメリット・デメリット

Flinkはストリーム処理の標準的なツールですが、非常に複雑です。Sparkも難しいものの、Flinkはリアルタイムの分散コンピューティングにおける一貫性を保つことが難しく、さらに管理が厄介です。Flinkの導入には、特定の環境に合わせた調整やシステムの復旧を行うための専門チームが必要となります。

しかし、Flink-as-a-Serviceの提供により、この技術を企業がより簡単に利用できるようになる可能性があります。アリババ（BABA）もこれに挑戦しましたが、十分なフォーカスを欠いたため、Ververicaを買収してFlinkの強化に努めました。Immerockがコンフルエント（CFLT）の一部となった今、Flinkをサービスモデルとして簡素化することが目指されています。この新しいFlinkはクラウドネイティブで、保守が容易であり、さらに自動化が進んだものになるでしょう。

Flinkの複雑さは、その普及を制限しています。技術チームが必要で、JVMの使用やコンピュートとストレージのカップリング、大規模なデータ処理におけるパフォーマンスの問題など、レガシーな課題を抱えています。Flinkはもともとデータ処理向けに設計されており、リアルタイムのポートフォリオ更新のようなサービスには適していません。しかし、Icebergのサポートにより、処理とサービス両方のクエリに対応できるようになりました。

Flinkはコンピュートとストレージが結びついているため、リソースが不足した場合にはクラスターの再構成が必要で、継続的なメンテナンスが求められます。Kafka同様、FlinkはストリーミングETLに優れていますが、長期間のデータ保存には向いていません。しかし、Icebergのサポートにより、リアルタイムデータと履歴データの両方を扱える可能性が広がっています。

オープンソースのストリーム処理では競争が少ないですが、RisingWaveというオープンソースプラットフォームがFlinkに挑戦しており、性能が10倍から100倍向上すると主張しています。アリババのFlinkチームはこの主張に異議を唱えていますが、RisingWaveは高価なインフラではなく、安価なオブジェクトストレージを利用することで、コストと性能の両面で優位性を持っています。

RisingWaveはクラウドネイティブかつ使いやすいアーキテクチャを採用しており、従来のFlinkが対象としていたエンジニア層よりも幅広いユーザーにアピールしています。スノーフレーク（SNOW）などの企業が推進するクラウドネイティブの流れは、よりシンプルでスケーラブル、柔軟なソリューションを提供し、ストリーム処理をより手軽でコスト効率の良いものにしています。

関連用語

JVM（Java Virtual Machine）: Javaで書かれたプログラムを実行するための仮想マシン。OSに依存せず、どの環境でもJavaプログラムを動かすことができる。

カップリング（Coupling）: システムやコンポーネント同士が強く結びついている状態を指す。Flinkの場合、コンピュート（計算）とストレージ（保存）が密接に関連していて、どちらかを変更すると他方にも影響を与えやすいという意味。

Iceberg: 大規模データを管理するためのテーブル形式で、特に分散処理システムでのデータ管理を効率化する。FlinkやSparkなどの分散処理システムと連携して、リアルタイムと履歴データの両方を処理できるようにする。

ストリーミングETL: データをリアルタイムで収集、処理、変換して目的の場所に送るプロセス。ETLはExtract（抽出）、Transform（変換）、Load（格納）の略で、ストリーミングETLはこれをリアルタイムに行う手法を指す。

要約すると、RisingWaveは以下の点に重点を置いています：

1. データの永続性: Flinkとは異なり、IcebergやHudiなどの追加ソリューションを使わずに、ストリーミングデータと履歴データの両方を一元的に保存してインサイトを得ることができます。

2. クエリの提供: Flinkがリアルタイムビューに別途データベースを必要とするのに対し、RisingWaveはビジネスアナリストを含む複数のユーザーがアドホッククエリを直接実行できるようにサポートしています。

※Lambdaアーキテクチャにおいて、RisingWaveはSpeed Layerとしてだけでなく、リアルタイムビューやバッチビュー（マテリアライズドビュー）も提供できます。一方、FlinkはSpeed Layerとしての役割のみを果たします。

3. PostgreSQL互換性：RisingWaveはクエリ言語にPostgreSQLを使用しており、学習のハードルが低くなっています。Fireboltなどの最新のMDS（Modern Data Stack）スタートアップでも、PostgreSQLが採用されています。

4.トランザクション処理：Flinkとは異なり、RisingWaveは統合されたコンピュートとストレージシステムにより、トランザクションを処理できます。ただし、一般的なIcebergフォーマットとは異なり、企業はRisingWave独自のフォーマットにデータを変換する必要があります。

RisingWaveはコネクタを通じてIcebergの読み取りが可能ですが、基本的には独自フォーマットを使用しています。コンフルエントがIcebergを採用することで、Flinkのオブジェクトストレージに関する制約が緩和される可能性があります。

RisingWaveは、PostgreSQL互換性、低コストなデプロイ、高いパフォーマンスを備えており、技術的なスキルがそれほど高くない企業にとっても、効率的なストリーミングデータベースとして有力な選択肢となっています。

関連用語

アドホッククエリ：特定の目的のために即時に作成され、実行される一時的なクエリのことです。事前に決められたレポートや定型的なクエリではなく、その場で必要な情報を取得するために作成されるクエリ。

Speed Layer: データをリアルタイムで処理する層で、最新の情報を迅速に提供。遅延のあるバッチ処理とは異なり、即時性を重視している。

バッチビュー: バッチ処理によって集計されたデータビューで、定期的に大量のデータをまとめて処理し、後から参照できるようにする。

マテリアライズドビュー: データベースにおいて、クエリ結果を事前に保存しておくビューで、頻繁に使用されるクエリのパフォーマンスを向上させるために使われる。

PostgreSQL: オープンソースのリレーショナルデータベース管理システムで、豊富な機能と柔軟性があり、信頼性の高いデータ管理が可能。

MDS (Modern Data Stack): データの収集、保存、処理を行うための最新のツールや技術の組み合わせを指す。データ分析や活用を効率的に行うためのスタック。

デプロイ: システムやソフトウェアを実際の運用環境に導入・配置すること。

TPC-Hベンチマーク：大規模なデータベースシステムの性能を評価するための基準。特に、データウェアハウスや意思決定支援システムにおけるクエリ処理の速度や効率を測定。実際のビジネスシナリオに基づいた複雑なクエリを用いて、データベースの性能を総合的に評価。

最近、RisingWaveはTPC-Hベンチマークの結果を発表し、Flinkよりも15%高速であることが明らかになりました。中には、Flinkを大幅に上回るクエリもありました。

TPC-Hベンチマークは、データウェアハウスのような意思決定支援システムの性能を測定するもので、この15%のパフォーマンス向上は、時間やリソースの大幅な節約につながる可能性があります。特定のクエリで複数倍の性能向上が見られたことは、RisingWaveの強力なアーキテクチャを示していますが、実際の効果はデータセットやハードウェアなどの条件に依存します。

RisingWaveアーキテクチャの特徴

RisingWaveは、従来のJVMベースのシステムよりも高いパフォーマンスとコスト効率を実現するモダンなプログラミング言語Rustを採用している点で差別化されています。Rustは、C++のようにメモリやCPUの負担を抑えながら、より扱いやすい言語です。この傾向は、Databricksのようなスタートアップやクラウドフレア（NET）のような企業でも見られ、高性能なサービスの構築にRustが利用されています。

ストレージに関しては、HDFSではなくオブジェクトストレージを採用することで、技術的負担を軽減し、データ管理を簡素化しています。これは、スケーラブルなクラウドネイティブの運用に適しており、Grafanaなどのモニタリングツールと連携することで、パフォーマンスの分析やコストの最適化を容易にしています。

また、RisingWaveのステートレスなコンピュートモデルは、状態管理をコンピュート層から切り離すことで、スケーラビリティを大幅に向上させています。非同期チェックポイントや「厳密に一度だけ」のセマンティクスを活用することで、再試行や障害が発生した場合でも信頼性の高いデータ処理を保証し、クラウドネイティブでスケーラブルなデータ処理基盤を提供しています。

関連用語

Rust: 高速で安全なプログラミング言語で、メモリ管理が効率的で、C++に比べてバグが少なく、安全性が高いのが特徴。

C++: 高性能なシステムやアプリケーションの開発に使われるプログラミング言語で、ハードウェアに近いレベルでの制御が可能。

CPU（中央処理装置）: コンピュータの中枢部で、プログラムの命令を解釈し、実行する役割を担う。

HDFS（Hadoop Distributed File System）: 大規模データを分散して保存・管理するためのファイルシステムで、Hadoopというフレームワークで使われる。

Grafana: データの可視化ツールで、リアルタイムのモニタリングやダッシュボード作成に使用され、システムのパフォーマンス分析などに役立つ。

ステートレス: システムやアプリケーションが、状態（データ）を持たずに処理を行う仕組み。状態を持たないため、スケーラビリティや信頼性が向上する。

セマンティクス: プログラミングやシステムの動作において、「意味」や「意図」を指す言葉で、プログラムやプロセスがどのように機能すべきかを定義するもの。

コンフルエント（CFLT）に対する結論

FlinkはKafkaと同様に、ストリーム処理の標準であり、今後もその地位を保つ可能性があります。しかし、RisingWaveのような新技術がこの地位に挑戦する可能性もあり、Flinkは進化する必要があります。コンフルエント（CFLT）はKoraで用いている戦略をFlinkにも適用すべきでしょう。Icebergやサーバーレスコンピューティングのような技術を統合することで、Flinkは次世代のクラウドネイティブプラットフォームに変わるかもしれません。これにより、コストに敏感な企業だけが自前でFlinkを管理し、その他の企業はスケーラビリティや自動メンテナンス、事前に構築された機能を備えたコンフルエントのFlinkを選択するようになるでしょう。これが成功すれば、同社にとって次の成長曲線（Sカーブ）となり、イベント駆動型アーキテクチャ（EDA）戦略ともうまく合致します。企業はKoraにデータを集約し、Icebergストレージを活用する一方で、スノーフレーク（SNOW）やDatabricksのような競合エンジンを導入し、コンフルエントの将来性への信頼を高めることが期待されます。

コンフルエント（CFLT）に対する潜在的な課題

これらの変革は2025年以降に期待されています。コンフルエント（CFLT）はこれらのソリューションを単に開発するだけでなく、効果的に市場に展開する必要があります。最大の課題は、コンフルエントがPAM（特権アクセス管理）やIGA（アイデンティティガバナンス管理）のように、成長が限定されたニッチな企業にとどまることを回避できるかどうかです。

コンフルエント（CFLT）の競争環境

ストリーミングデータ分野は非常に技術的です。Flinkが進化する一方で、スノーフレーク（SNOW）やDatabricksなどの競合他社も機能を強化していますが、Kafkaの支配的地位は依然として強固であり、コンフルエント（CFLT）には独自の価値を提供する大きなチャンスが残されているように見えます。

関連用語

Kora: コンフルエントが提供するクラウドネイティブなデータプラットフォームで、データの収集、保存、処理を効率的に行い、他のデータ処理エンジンと連携できるよう設計されている。

PAM（特権アクセス管理）: システム内の特権ユーザー（管理者など）によるアクセスや操作を管理・制御するためのセキュリティソリューション。重要なシステムやデータへの不正アクセスを防ぐために使われる。

IGA（アイデンティティガバナンス管理）: ユーザーのアイデンティティ（身元）やアクセス権を管理するシステムで、誰がどのリソースにアクセスできるかを適切に制御し、コンプライアンスやセキュリティを強化する。

アナリスト紹介：コンヴェクィティ

2019年に設立されたコンヴェクィティは、AI、サイバーセキュリティ、SaaSを含むエンタープライズ（企業）向けテクノロジーを扱うテクノロジー企業に関する株式分析レポートを提供しています。セールス・チャネルや分析対象企業の経営陣との関係に依存する投資銀行や証券会社のアナリストとは異なり、対象企業のプロダクト、アーキテクチャー、ビジョンを深掘りすることで投資家に付加価値の高い、有益な情報の提供を実現しています。

当社のパートナーであるジョーダン・ランバート氏とサイモン・ヒー氏は、「最新のテクノロジーに対する深い洞察」、「ビジネス戦略」、「財務分析」といったハイテク業界におけるアルファの機会を引き出すために不可欠な要素を兼ね備えております。そして、特に、第一線で活躍する企業やイノベーションをリードするスタートアップ企業を含め、テクノロジー業界を幅広くカバーすることで、投資家のビジビリティと長期的なアルファの向上に努めています。

ジョーダン・ランバート氏 / CFA

ランバート氏は、テクノロジー関連銘柄、および、リサーチとバリュエーションのニュアンスに特別な関心を持つ長年のハイテク投資家です。ランバート氏は、CFA資格を取得した後、2019年10月にコンヴェクィティを共同設立しており、新たな技術トレンド、並びに、長期的に成功する可能性が高い企業を見極めることを得意としています。

サイモン・ヒー氏

ヒー氏は、10年以上にわたってテクノロジーのあらゆる側面をカバーしてきた経験を生かし、テクノロジー業界における勝者と敗者を見極める鋭い洞察力を持っています。彼のテクノロジーに関するノウハウは、ビジネス戦略や財務分析への理解と相まって、コンヴェクィティの投資リサーチに反映されています。コンヴェクィティを共同設立する以前は、オンラインITフォーラムでコミュニティ・マネージャーを務め、ネットワーク・セキュリティ業務に従事していました。ヒー氏は、ユニバーシティ・カレッジ・ダブリンを卒業し、商学士号を取得しております。

また、コンヴェクィティのその他のテクノロジー関連銘柄のレポートに関心がございましたら、是非、こちらのリンクより、コンヴェクィティのプロフィールページにアクセスしていただければと思います。

その他のテクノロジー銘柄関連レポート

1. ① Part 1：クラウドフレア / NET：サイバーセキュリティ銘柄のテクノロジー上の競争優位性（強み）分析と今後の将来性（前編）

2. ①ルーブリック / RBRK（IPO・新規上場）：サイバーセキュリティ銘柄の概要＆強み分析と今後の株価見通し（Rubrik）

3. クラウドストライク（CRWD）システム障害で世界中のPCがクラッシュ！原因と対策、今後の株価への影響と将来性を徹底解説！

その他のコンフルエント（CFLT）はに関するレポートに関心がございましたら、是非、こちらのリンクより、コンフルエントのページにアクセスしていただければと思います。