こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp 今回は、私が作った「PdMタイプ診断」という取り組みについてご紹介します。 この診断は、既存の性格診断をそのまま用いたものではなく、 PdMとしての思考や行動の傾向を整理するために、認知スタイルに関する考え方をヒントに独自に設計したもの です。 診断の仕組みと、ラクスの開発組織で実施して見えてきたことをレポートします。 なぜ作ったのか 診断の仕組み：3つの軸、8つのタイプ 軸① コミュニケーション 軸② 価値の方向性 軸③ 志向性 ラクス社内で試してみた 開発組織全体の傾向：「Logic × UX × Discovery」が最多 プロダクト部の特徴：「Discovery」が際立って高く、2つのタイプが拮抗 この結果をどう受け取るか まとめ おわりに なぜ作ったのか きっかけは、小さな課題感からでした。 PdMのイベントや社外の方と話すとき、「どんなPdMですか？」という問いにうまく答えるのが難しいと感じることがありました。 職種名だけでは伝わらないですし、スキルセットを並べても、その人らしさまではなかなか見えてきません。 もう一つ感じていたのが、チームづくりの場面で、 このメンバーはどんな場面で力を発揮しやすいのか を共通言語で話しにくいことでした。 もちろん、人の適性や可能性は診断だけで決まるものではありません。 ただ、対話のきっかけになる整理軸があるだけでも、お互いの理解は進めやすくなります。 そこで、PdMとしての思考・行動スタイルを3つの軸で整理し、8つのタイプに分類する診断を作ってみました。 初対面のPdM同士で話すきっかけにしたり、チーム内で自分や他者の強みを言語化したりするための、 参考情報の一つ として使えることを期待しています。また今回の整理にあたっては、設問やタイプ説明のたたき台を考える過程で、生成AIも補助的に活用しました。 人が考えるべき軸や解釈を前提にしつつ、表現の幅を広げたり、説明文を磨いたりするうえで、AIは良い壁打ち相手になると感じています。 診断の仕組み：3つの軸、8つのタイプ 診断は、3つの軸の組み合わせでPdMのタイプを分類します。 軸① コミュニケーション Logic（理詰め型）／ Emotion（共感型） チームや関係者をどう巻き込むかを見る軸です。 データや論理で動かす傾向が強いのか、共感や関係性を起点に動かす傾向が強いのかを見ます。 軸② 価値の方向性 UX（ユーザー価値重視）／ BV（ビジネス価値重視） どの成果をより重視しやすいかを見る軸です。 顧客体験を起点に考えるのか、事業成長や収益性を起点に考えるのか、その傾向を整理します。 軸③ 志向性 Discovery（探索志向）／ Delivery（実行志向） どのフェーズでモチベーションを感じやすいかを見る軸です。 まだ見ぬ課題を発見することに惹かれるのか、価値を着実に届けることに手応えを感じるのかを見ます。 この3軸の組み合わせで、8つのタイプになります。 ※本記事では、診断の詳細な設問内容や公開方法そのものの案内は割愛します。 ラクス社内で試してみた せっかく作ったので、ラクスの開発組織でも試してみました。 プロダクト部のメンバーだけでなく、楽楽シリーズの開発に携わるエンジニア、QA、インフラ、管理職まで、幅広く参加してもらいました。 ここで紹介するのは、個人を評価したり決めつけたりするためのものではなく、 組織の傾向を俯瞰して見るための集計結果 です。 「どのタイプが優れているか」を見るものではなく、「どんな視点が集まっているか」を知るための材料として扱っています。 そのうえで、いくつか興味深い傾向が見えてきました。 開発組織全体の傾向：「Logic × UX × Discovery」が最多 開発組織全体を見ると、もっとも多かったのは サイエンティスト（Logic × UX × Discovery）タイプ でした。 各軸の全体比率は次のとおりです。 論理的に考え、ユーザー価値を重視し、探索や発見にモチベーションを感じる人が多い。 これが、開発組織全体の大まかな傾向でした。 実際、日々のプロダクト開発でも、 「顧客課題をより深く理解したい」 「仮説を立てて検証したい」 という姿勢を持つメンバーが多いと感じています。この傾向は、顧客にとって本当に価値のある機能や体験を考えるうえで、ラクスの開発組織らしさの一つかもしれません。 プロダクト部の特徴：「Discovery」が際立って高く、2つのタイプが拮抗 プロダクト部に絞ると、また少し違った顔が見えてきました。 プロダクト部の各軸比率は次のとおりです。 特に目を引いたのは、志向性です。 全体でも67%がDiscovery型でしたが、プロダクト部では 79% とさらに高くなっていました。まだ答えのない問いを探索することが好きな人、発見のフェーズにエネルギーが湧く人が多い組織だと言えそうです。 さらに興味深かったのが、タイプの分布です。 プロダクト部で最多だったのは、 ビジョナリー（Emotion × UX × Discovery） と ストラテジスト（Logic × BV × Discovery） の同率首位でした。 一方は、共感から未来の体験を描くタイプ。 もう一方は、構造から勝ち筋を見出すタイプです。 アプローチは対照的ですが、どちらも「Discovery（探索）」に強く向いているという共通点があります。 感性寄りの人と論理寄りの人、ユーザー価値を強く見る人とビジネス価値を強く見る人が混在している。 その多様さが、ラクスのプロダクト部の特徴の一つなのかもしれません。 この結果をどう受け取るか 「タイプが違うと、摩擦が生まれるのでは」と感じる方もいるかもしれません。 私は、むしろ逆だと思っています。 たとえばビジョナリーとストラテジストは、それぞれ異なる強みを持っています。 共感から体験を描く力と、構造から事業の勝ち筋を考える力は、どちらもプロダクトづくりに欠かせません。 大切なのは、「あなたはこのタイプだからこうあるべき」と決めることではなく、 このチームにはどんな視点が集まっているのか を知ることだと思っています。 その視点の違いを理解できると、 顧客課題の見立てに偏りがないか 意思決定の観点が足りているか 誰がどの場面で力を発揮しやすいか といったことを、より建設的に話しやすくなります。 実際、この診断をきっかけに、ラクスのプロダクト部でも 「自分はどういう場面で力を出しやすいか」 「チームとして見ると、どの視点が強くて、どの視点が薄いか」 を話題にしやすくなった感覚があります。 その結果として、顧客にとっての価値の捉え方や、プロダクトづくりにおける役割分担の解像度が少し上がったように感じています。 まとめ 「PdMタイプ診断」は、まだ発展途上のツールです。 型にはめることが目的ではなく、 共通言語を通じて、自分やチームの傾向を理解するための出発点 として使ってもらえたらと思っています。 PdMとして、あるいはプロダクトづくりに関わる一人として、 「自分はどんな場面で力を発揮しやすいのか」 「チームの中でどんな視点を持ち込みやすいのか」 を考えるきっかけになれば、作った甲斐があります。 そして、こうした相互理解は、よりよいチームづくりだけでなく、 顧客課題を多面的に捉え、より価値あるクラウドサービスを届けることにもつながるはずです。 興味を持っていただけたら、ぜひ一度試してみてください。 おわりに ラクスのプロダクト部では、さまざまなタイプのPdMやデザイナーが一緒に働いています。 違いを面白がりながら、顧客にとってよりよい価値を考え続けたい方と、ご一緒できたらうれしいです。 採用情報は、ぜひこちらからご覧ください。 career-recruit.rakus.co.jp speakerdeck.com

本記事は 2026 年 5 月 7 日に公開された “ Announcing aggregations on Amazon ElastiCache ” を翻訳したものです。 Amazon ElastiCache が集計クエリをサポートするようになり、単一のクエリでキャッシュ内のデータを直接フィルタリング、グループ化、変換、集計することがより簡単になりました。集計クエリを使用することで、テラバイト規模のデータに対してマイクロ秒単位の低レイテンシーで、最新の書き込みが反映された結果を返す、リアルタイムなアプリケーション体験を構築できます。データがすでに存在する場所で、アプリケーションが要求する速度で分析を行うことができ、別途分析レイヤーを用意する必要はありません。集計機能を使用すると、ElastiCache に保存済みのデータに対して、リアルタイムのリーダーボード、ファセット検索によるカタログブラウジング、運用レポート、探索的な分析クエリなどを構築できます。 ElastiCache 内のメモリ上で集約処理を直接実行することで、アーキテクチャの複雑さを軽減し、応答時間を改善できます。集約クエリはサーバー側で計算を実行するため、アプリケーションはデータをその場で分析し、最終的なサマリーのみを返すことができます。例えば、1 つの集約クエリで、製品カタログをフィルタリングして特定のカテゴリのデータを取得し、結果をブランドごとにグループ化し、各ブランドの平均評価を計算し、パフォーマンス上位 10 件のみを返すといったことが可能です。これらのクエリは、GROUPBY、REDUCE、APPLY、FILTER、SORTBY、LIMIT などのステージをパイプラインに連結することで構築でき、各ステージの出力が次のステージへの入力になります。これらのステージを任意の順序で組み合わせ、繰り返し使用することで、1 つのコマンドで複数ステップの分析ワークフローを構築できます。集約はプライマリ上で Read-after-Write 整合性 (書き込み後読み取り整合性) を提供するため、結果には最新の書き込みが反映され、クライアントコードを変更することなくシャード間でスケールします。本投稿では、集約によって実現できるユースケースを紹介し、ElastiCache for Valkey を使ってファセットブラウジングエンジンを構築しながら、その仕組みを解説します。 これらの集約機能は、ElastiCache version 9.0 for Valkey で、全文検索、完全一致検索、範囲検索、ベクトル検索機能 ( Amazon ElastiCache での全文検索、完全一致検索、範囲検索、ハイブリッド検索 を参照) と並んで利用可能です。ElastiCache version 9.0 for Valkey ではまた、個々のフィールドに対するきめ細やかな TTL 制御を可能にするハッシュフィールドの有効期限機能や、最大 40% 向上したパイプラインスループットも導入されています。リリースの詳細については、 Amazon ElastiCache 向け Valkey 9.0 のお知らせ をご覧ください。 集約の使用が適している場面 アプリケーションは、リアルタイムでフィルタリング、グループ化、集計する必要があるデータを ElastiCache に保存することがよくあります。例えば、E コマースプラットフォームでは、カタログ全体にわたってカテゴリ別の平均評価や商品数を計算します。ストリーミングサービスでは、ジャンル別の総視聴数、平均視聴時間、再生数上位の作品を算出し、トレンドフィードやレコメンデーションランキングを構築します。金融サービスでは、ユーザーや時間枠ごとに取引をグループ化して合計を計算し、しきい値違反を検出し、コンプライアンスレポートを生成します。アプリケーションは、ユーザー向けのエクスペリエンス、ライブ分析、運用レポートを支えるためにこのデータをリアルタイムに分析する必要があり、古いデータや遅い結果はユーザーエクスペリエンスを低下させます。デバッグや単発の調査のためにアドホックなクエリが必要な開発者は、別の分析レイヤーを設定したり、データをアプリケーションレイヤーにエクスポートしたりすることなく、ライブデータに対して直接集計を実行することもできます。集計は、次の 3 つの一般的なユースケースをサポートします。 カタログフィルタリングのためのファセット検索: E コマースプラットフォームでは、買い物客がブラウジングする際に、各フィルタの組み合わせに一致する商品数を表示します。買い物客がカテゴリや価格帯を選択すると、UI は残りのすべてのフィルタ値のカウントを即座に更新します。1 つの集計クエリで、一致するカタログをブランド、色、または評価ごとにグループ化し、グループごとのカウントを返すため、アプリケーションは事前計算や古いカウントのキャッシュなしに正確なファセット数を表示できます。集計はインメモリで直接実行されるため、数百万の商品にまたがる場合でも、これらのカウントはマイクロ秒のレイテンシで返されます。 リアルタイムのトレンドとランキング: ゲームプラットフォーム、ストリーミングサービス、マーケットプレイスでは、ライブのエンゲージメント指標に基づいてトレンドコンテンツや上位ランカーを表示します。従来、これにはスケジュールに従ってランキングを再計算するバックグラウンドジョブが必要で、データの陳腐化を招いていました。あるいは、大量の結果セットに対するアプリケーション側でのソートが必要で、レイテンシーが増加していました。単一の集計クエリで、コンテンツをカテゴリーごとにグループ化し、総視聴回数、エンゲージメントスコア、プレイヤーランクを計算して、上位の結果を返すことができます。インデックスは書き込み時に同期的に更新されるため、集計クエリはポーリング、キャッシュ無効化、定期的な再計算を行うことなく最新のデータを反映します。 運用レポートと分析: ElastiCache を高速アクセスのために利用するアプリケーションでは、同じデータに対する運用分析やレポートが必要になることがよくあります。例えば、セッションストアではデバイスごとの平均セッション時間を計算し、E コマースプラットフォームではステータスやフルフィルメント段階ごとの注文量を計算します。Aggregations は、別途の分析用クラスターをプロビジョニングしたり ETL パイプラインを維持したりすることなく、スケジュールに基づいて、またはオンデマンドで、これらのクエリをインメモリデータに対して直接実行します。 ElastiCache を使ったファセット検索とリアルタイム分析の構築 これらの機能を組み合わせて実演するために、メディアストリーミングプラットフォームである AnyOrganization 向けに、ファセットブラウジングと分析エンジンを構築します。AnyOrganization はコンテンツカタログを ElastiCache にハッシュキーとして保存しており、各映画タイトルにはジャンル、言語、スタジオ、評価、リアルタイムの視聴回数といったメタデータが含まれています。以下のコードでは、このデータに対して 3 つのクエリパターンを構築します。ファセットフィルタリング、ライブトレンドアイテム、そしてスタジオレベルのエンゲージメントレポートです。 前提条件 この記事の例では、Python と valkey-py クライアントライブラリを使用します。手順を実行するには、以下が必要です (所要時間の目安: 30 分): AWS アカウント および AWS Command Line Interface (AWS CLI) ElastiCache レプリケーショングループを作成する権限を持つ AWS IAM ロール Amazon ElastiCache クラスターと同じ VPC 内にある Amazon EC2 インスタンス (または Amazon ElastiCache に接続可能な 任意のアプリケーション) Python 3.9 以降、および valkey-py バージョン 6.1.1 以降 (pip install valkey) この投稿の完全なサンプルコードは、 Amazon ElastiCache samples GitHub リポジトリで入手できます。 git clone https://github.com/aws-samples/amazon-elasticache-samples.git cd amazon-elasticache-samples/blogs/aggregations-blog ElastiCache for Valkey クラスターのセットアップ 集計機能を利用するための ElastiCache クラスターは、 AWS Management Console または AWS CLI で作成できます。集計機能は ElastiCache version 9.0 for Valkey 以降で利用可能です。以下の例では CLI を使用しています。 aws elasticache create-replication-group \ --replication-group-id AnyOrganization-cache \ --replication-group-description "AnyOrganization Valkey cluster" \ --engine valkey \ --engine-version 9.0 \ --transit-encryption-enabled \ --cache-node-type cache.r7g.large \ --num-node-groups 2 \ --replicas-per-node-group 1 \ --multi-az-enabled \ --automatic-failover-enabled # --transit-encryption-enabled が設定されている場合、Python クライアント接続に # ssl=True を追加します: # client = valkey.ValkeyCluster(..., ssl=True) データへのインデックス作成 ElastiCache に保存されているデータに対して、 catalog_index というインデックスを作成します。 Genre 、 language 、 studio は、ファセットフィルタリング用の完全一致タグとしてインデックス化されます。 Release_year 、 rating 、 views_24h は、範囲フィルタやソート用の数値フィールドとしてインデックス化されます。タイトルは、キーワード、プレフィックス、あいまい一致をサポートする全文検索可能なフィールドとしてインデックス化されます。 以下のコードは、valkey-py の search モジュールを使用して Valkey Search コマンドを構築し送信します。各 Python メソッド呼び出しは、ネットワーク越しに送信される Valkey コマンドに直接対応しています。例えば、 client.ft("catalog_index").create_index(...) は FT.CREATE コマンドを送信し、 client.ft("catalog_index").aggregate(req) は FT.AGGREGATE コマンドを送信します。各コードブロックの横に、対応する Valkey コマンドを示しています。 import valkey from valkey.commands.search.field import TextField, TagField, NumericField from valkey.commands.search.indexDefinition import IndexDefinition, IndexType # : Insert your ElastiCache cluster's discovery endpoint VALKEY_CLUSTER_ENDPOINT = "placeholder_cluster.cnxa6h.clustercfg.use1.cache.amazonaws.com" client = valkey.ValkeyCluster( host=VALKEY_CLUSTER_ENDPOINT, port=6379, decode_responses=True, ssl=True) client.ft("catalog_index").create_index(fields=[ TextField("title"), TagField("genre"), TagField("language"), TagField("studio"), NumericField("release_year"), NumericField("rating"), NumericField("views_24h")], definition=IndexDefinition(prefix=["title:"],index_type=IndexType.HASH)) 同等の Valkey コマンド: FT.CREATE catalog_index ON HASH PREFIX 1 title: SCHEMA title TEXT genre TAG language TAG studio TAG release_year NUMERIC rating NUMERIC views_24h NUMERIC ElastiCache for Valkey ストアにカタログデータを投入します。本記事では、ElastiCache GitHub リポジトリのサンプルデータを使用しますが、他のデータソースを使用することもできます。 import csv import urllib.request import io import time response = urllib.request.urlopen( "https://raw.githubusercontent.com/aws-samples/amazon-elasticache-samples/main/blogs/aggregations-blog/catalog_data.csv") reader = csv.DictReader(io.TextIOWrapper(response)) count = 0 for row in reader: key = row.pop("id") client.hset(key, mapping=row) count += 1 print(f"Loaded {count} records") インデックスはデータをロードする前でも後でも作成できます。プレフィックスに一致するキーが既に存在する場合、Valkey Search はそれらを自動的にインデックスにバックフィルします。 ファセットフィルター 以下の集計は、ユーザーが選択したフィルターを受け取り、一致する結果をジャンル、言語、評価、公開年でグループ化し、各グループのタイトル数を返します。これにより、UI は結果と並べてファセットの件数を表示できます。 from valkey.commands.search.aggregation import AggregateRequest, Desc from valkey.commands.search import reducers def get_facet_counts(filters): # Build query string from user-selected filters clauses = [] if "genre" in filters: clauses.append(f"@genre:{{{filters['genre']}}}") if "language" in filters: clauses.append(f"@language:{{{filters['language']}}}") if "min_rating" in filters: clauses.append(f"@rating:[{filters['min_rating']} + inf]") query = " ".join(clauses) if clauses else "@rating:[-inf + inf]" # Run an aggregation for each facet dimension dimensions = ["genre", "language", "rating"] facets = {} for dim in dimensions: req = AggregateRequest(query) \ .load(f"@{dim}") \ .group_by(f"@{dim}", reducers.count().alias("count")) facets[dim] = client.ft("catalog_index").aggregate(req).rows return facets # Example: user filters for dramas in english, get counts for each dimension facets = get_facet_counts({"genre": "drama", "language": "english"}) # Example output: # {'genre': [{'genre': 'drama', 'count': '6'}], # 'language': [{'language': 'english', 'count': '6'}], # 'rating': [{'rating': '4', 'count': '4'}, # {'rating': '5', 'count': '2'}]} 同等の Valkey コマンド (1 つのファセットディメンション、英語のドラマでフィルタリングする場合): FT.AGGREGATE catalog_index "@genre:{drama} @language:{english}" LOAD 1 @genre GROUPBY 1 @genre REDUCE COUNT 0 AS count リアルタイムで急上昇中のアイテム 以下のコードは、ジャンルごとのトップトレンドタイトルを取得します。これは、ユーザーがコンテンツを視聴するとリアルタイムで更新される views_24h フィールドに対する集計によって実現されています。 def get_trending_by_genre(limit=10): # Get the highest view count per genre # sorted by most popular genre first req = AggregateRequest("@rating:[-inf + inf]") \ .load("@genre", "@views_24h") \ .group_by("@genre", reducers.max("@views_24h").alias("max_views")) \ .sort_by(Desc("@max_views"), max=limit) return client.ft("catalog_index").aggregate(req).rows trending_by_genre = get_trending_by_genre() # Example output: # [{'genre': 'action', 'max_views': '4500'}, # {'genre': 'comedy', 'max_views': '3800'}, # {'genre': 'thriller', 'max_views': '3600'}, # {'genre': 'sci-fi', 'max_views': '3400'}, # {'genre': 'drama', 'max_views': '3200'}, # {'genre': 'animation', 'max_views': '3100'}, # {'genre': 'romance', 'max_views': '2800'}, # {'genre': 'horror', 'max_views': '2600'}, # {'genre': 'documentary', 'max_views': '1900'}] 同等の Valkey コマンド (1 つのファセットディメンションで、英語のドラマをフィルタリングする場合): FT.AGGREGATE catalog_index "@rating:[-inf + inf]" LOAD 2 @genre @views_24h GROUPBY 1 @genre REDUCE MAX 1 @views_24h AS max_views SORTBY 2 @max_views DESC MAX 10 リアルタイムトレンドアイテム 以下のコードは、ジャンルごとにトレンドの上位タイトルを取得するもので、ユーザーがコンテンツを視聴するとリアルタイムに更新される views_24h フィールドに対する集計によって実現されています。 def get_trending_by_genre(limit=10): # Get the highest view count per genre # sorted by most popular genre first req = AggregateRequest("@rating:[-inf + inf]") \ .load("@genre", "@views_24h") \ .group_by("@genre", reducers.max("@views_24h").alias("max_views")) \ .sort_by(Desc("@max_views"), max=limit) return client.ft("catalog_index").aggregate(req).rows trending_by_genre = get_trending_by_genre() # Example output: # [{'genre': 'action', 'max_views': '4500'}, # {'genre': 'comedy', 'max_views': '3800'}, # {'genre': 'thriller', 'max_views': '3600'}, # {'genre': 'sci-fi', 'max_views': '3400'}, # {'genre': 'drama', 'max_views': '3200'}, # {'genre': 'animation', 'max_views': '3100'}, # {'genre': 'romance', 'max_views': '2800'}, # {'genre': 'horror', 'max_views': '2600'}, # {'genre': 'documentary', 'max_views': '1900'}] 同等の Valkey コマンド: FT.AGGREGATE catalog_index "@rating:[-inf + inf]" LOAD 2 @genre @views_24h GROUPBY 1 @genre REDUCE MAX 1 @views_24h AS max_views SORTBY 2 @max_views DESC MAX 10 オンデマンドエンゲージメントレポート AnyOrganization は、制作スタジオ別のコンテンツパフォーマンスを測定するために、日次のレポートジョブを実行しています。次のコードは、同じインデックスに対する集計を使用して、タイトル数、平均評価、総エンゲージメントなどのスタジオレベルのメトリクスを計算します。 def get_studio_report(): # Studio performance: title count, average rating, total 24h views req = AggregateRequest("@rating:[-inf + inf]") \ .load("@studio", "@rating", "@views_24h") \ .group_by("@studio", reducers.count().alias("title_count"), reducers.avg("@rating").alias("avg_rating"), reducers.sum("@views_24h").alias("total_views")) \ .sort_by(Desc("@total_views")) return client.ft("catalog_index").aggregate(req).rows studio_report = get_studio_report() # Example output: # [{'studio': 'StreamFlix Originals', 'title_count': '18', # 'avg_rating': '4.3333333333', 'total_views': '46200'}, # {'studio': 'Summit Pictures', 'title_count': '13', # 'avg_rating': '3.8461538462', 'total_views': '30000'}, # {'studio': 'Crimson Studios', 'title_count': '11', # 'avg_rating': '4.4545454545', 'total_views': '23100'}, # {'studio': 'Emerald Films', 'title_count': '8', # 'avg_rating': '4', 'total_views': '13600'}] 同等の Valkey コマンド: FT.AGGREGATE catalog_index "@rating:[-inf + inf]" LOAD 3 @studio @rating @views_24h GROUPBY 1 @studio REDUCE COUNT 0 AS title_count REDUCE AVG 1 @rating AS avg_rating REDUCE SUM 1 @views_24h AS total_views SORTBY 2 @total_views DESC ベストプラクティス 集計クエリのレイテンシーとスループットを改善するには、各パイプラインステージを通過するドキュメント数を減らすために早い段階でフィルタリングします。マッチする範囲が広いクエリは、パイプラインに入るキーの数が増え、初期スキャンと初期ステージのコストが増加します。例えば、上記のファセットフィルタリングの例では、ユーザーのアクティブなフィルターをクエリ文字列で渡すことで、マッチするドキュメントのみが GROUPBY ステージに入ります。また、しきい値を満たさないグループを削除するために GROUPBY ステージの後に FILTER を追加することもできます。例えば、結果を返す前にタイトル数が 5 未満のジャンルを除外する場合などです。さらに、上位の結果のみが必要な場合は、 SORTBY に MAX を追加することで、トレンドアイテムの例で示すように、エンジンはワーキングセット全体をソートするのではなく、上位の結果のみを追跡します。 LOAD を使うと、インデックスに含まれていないフィールドであっても、基となるハッシュデータから直接フィールドを取得して集約パイプラインに取り込むことができます。例えば、ハッシュに actors フィールドを保存しているがインデックス化していない場合、クエリ実行時に LOAD で読み込み、それを使ってグループ化やソートを行うことができます。ただし、 LOAD は一致するドキュメントごとに基となるキーから生データを取得する必要があるため、結果セットのサイズに応じてレイテンシーが増加します。このオーバーヘッドを避けるため、ロードするフィールドの数は最小限に抑えてください。 クリーンアップ このウォークスルーのために ElastiCache クラスターを作成し、不要になった場合は、今後の課金を避けるために、次の AWS CLI コマンドを使用してクラスターを削除してください。 aws elasticache delete-replication-group --replication-group-id AnyOrganization-cache はじめに この記事では、ElastiCache のアグリゲーションについて、ファセットフィルタリング、ライブトレンドのレコメンデーション、オンデマンドのエンゲージメントレポートを取り上げ、これらすべてを単一の Valkey Search インデックス上に構築する方法を解説しました。アグリゲーションは、すべての商用 AWS リージョン、AWS GovCloud (US) リージョン、および中国リージョンにおいて、ElastiCache for Valkey バージョン 9.0 を実行するノードベースのクラスターで追加費用なしでご利用いただけます。Valkey は、Redis に代わる最も寛容なライセンスのオープンソースかつベンダー中立な選択肢であり、ElastiCache で推奨されるエンジンです。使い始めるには、AWS Management Console、AWS SDK、または AWS CLI を使用して、Valkey 9.0 以降の新しいクラスターを作成するか、 既存のクラスターをアップグレード してください。詳細については、 ElastiCache のドキュメント をご覧ください。質問やフィードバックがある場合は、 AWS re:Post for ElastiCache をご覧ください。 著者について Chaitanya Nuthalapati Chaitanya は AWS インメモリデータベースサービスのシニアテクニカルプロダクトマネージャーで、Amazon ElastiCache for Valkey に注力しています。以前は、生成 AI、機械学習、グラフネットワークを活用したソリューションを構築していました。仕事以外の時間では、Chaitanya は趣味を集めるのに忙しく、現在はテニス、スケートボード、パドルボードを楽しんでいます。 Karthik Subbarao Karthik は Amazon ElastiCache のシニアソフトウェアエンジニアであり、オープンソースの Valkey プロジェクトに積極的に貢献しています。分散システム、データベース、Rust、そして全般的にソフトウェア開発／テクノロジーを通じたイノベーションに情熱を注いでいます。 Allen Samuels Allen は AWS のプリンシパルエンジニアです。分散型で高性能なシステムに情熱を注いでいます。世界中を旅したりデュプリケートブリッジをプレイしたりしていない時は、カリフォルニア州サンノゼで過ごしています。 Siva Subramaniam Siva は AWS のシニアソリューションアーキテクトで、技術リーダーシップとデータベースアーキテクチャにおいて 20 年の経験を持っています。お客様が AWS の専用データベースを使用して移行とイノベーションを実現できるよう支援しています。仕事以外では、Siva はクリケット、農作業、そして妻から料理を学ぶことを楽しんでいます。 ご指導いただいた Ian Childress 氏、そしてプロジェクト全体を通じて実装面で貢献いただいた Miles Song 氏に特に感謝いたします。 本記事は、 Announcing aggregations on Amazon ElastiCache を翻訳したものです。翻訳は Solutions Architect の Hayato Tsutsumi が担当しました。

はじめに NTT西日本の近藤です。 本記事では、Cloudflare が提供する Cloudflare One（Cloudflare Zero Trust） において、 Identity Provider（以下、IdP。ユーザー認証を担う外部認証基盤）として Okta を OpenID Connect（OIDC）で連携する方法 を紹介します。 Cloudflare One は、ゼロトラストの考え方を前提としたプラットフォームであり、 ユーザー認証を Cloudflare 側で実施するのではなく、 外部 IdP によって認証された結果をもとにアクセス制御を行う構成 が基本となります。 そのため、IdP 連携は Cloudflare One を利用する上で重要な初期設定の一つです。 なお、本記事で扱う IdP（Identity Provider） とは、 ユーザーが「本人であること」を確認する役割を担う外部認証基盤を指します。 ID・パスワード認証や MFA（多要素認証）などは IdP 側で実施され、 Cloudflare One は「認証結果」を受け取ってアクセス可否を判断します。 本記事では、 Okta 側で Cloudflare One 連携用アプリケーションを追加する流れ Cloudflare One 側で Okta を IdP として設定する流れ 各設定画面で「何をしているのか」「どの値が必要なのか」 を、 実際の管理画面スクリーンショットに沿って 解説します。 なお、本記事では OIDC を用いた連携構成 を対象とし、 SAML との機能比較や詳細な方式選定は行いません。 あくまで「Cloudflare One の管理画面上で何を設定しているのかを理解する」ことを目的としています。 本記事は 2026 年 4 月時点の情報 に基づいています。 対象読者 本記事が想定する対象読者は以下の通りです。 Cloudflare One（Cloudflare Zero Trust）を検証・導入している方 Okta を IdP として既に利用している、または検討している方 ゼロトラスト環境における IdP 連携の具体的な設定イメージを把握したい方 目次 はじめに 対象読者 目次 1. 背景・目的 2. Cloudflare One における IdP 連携の考え方 3. Okta 側の設定 3.1 アプリケーション一覧の表示 3.2 App Integration Catalog の検索 3.3 Cloudflare One 連携アプリの詳細表示 3.4 Cloudflare One アプリケーションの追加 3.5 一般設定（General Settings） 3.6 ユーザー／グループの割り当て 3.6.1 ユーザーへの割り当て 3.7 Sign On 設定（OIDC） 4. Cloudflare One 側の設定 4.1 Cloudflare One ダッシュボード 4.2 Identity Provider の一覧 4.3 IdP の追加 4.4 Okta 連携設定画面 5. 認証動作の確認 6. SSO設定後のユーザーエクスペリエンス 7. 技術的な補足 8. まとめ 執筆者 参考資料・出典 商標 免責事項 1. 背景・目的 Cloudflare One におけるアクセス制御は、「ネットワークの内外」ではなく ユーザーのアイデンティティを起点に制御する ことを前提としています。 Cloudflare One 自体はユーザー認証を行わず、 外部 IdP（Okta など）によって認証された結果をもとにアクセス可否を判断します。 Okta と Cloudflare One の連携方式には OIDC と SAML がありますが、 Cloudflare One の管理画面では OIDC がデフォルトとなっており、 設定項目も比較的シンプルです。 【Tips】OIDC を前提とする理由 Cloudflare One の管理画面は OIDC を前提とした構成になっており、 まずは OIDC を対象に設定内容を追うことで、 各項目がどの役割を持っているのかを理解しやすくなります。 本記事では、 OIDC を用いた Okta × Cloudflare One 連携 を対象に、 管理画面での設定内容を整理することを目的としています。 2. Cloudflare One における IdP 連携の考え方 Cloudflare Oneにおける認証の役割分担は次の通りです。 Cloudflare One： アプリケーションへのアクセス要求を受け付け、認証を要求する Okta（IdP）： ユーザー認証（ID・パスワード・MFA など）を実施する Cloudflare One： 認証結果を基にアクセスポリシーを評価し、許可または拒否 この構成により、 認証ポリシーは IdP 側に集約 Cloudflare 側はアクセス制御に専念 という疎結合な設計が実現されます。 【Tips】なぜ認証とアクセス制御を分離するのか IdP 側で MFA の追加や条件変更を行っても、 Cloudflare One 側の設定を変更せずに挙動を反映できる点は、 ゼロトラスト設計における重要な考え方です。 3. Okta 側の設定 ここからは、Okta 管理コンソールでの設定を順に確認します。 3.1 アプリケーション一覧の表示 Okta 管理コンソールで Applications を開きます。 この画面では、既存のアプリケーションと新規追加が行えます。 3.2 App Integration Catalog の検索 「Browse App Catalog」を選択し、検索欄に cloudflare と入力します。 検索結果から Cloudflare One を選択します。 3.3 Cloudflare One 連携アプリの詳細表示 Cloudflare One のアプリ詳細画面が表示されます。 ここでは、 対応しているシングルサインオン方式 アプリケーションの概要 が確認できます。OIDC に対応していることが分かります。 3.4 Cloudflare One アプリケーションの追加 「Add Integration」を選択します。 これにより、Okta テナント内に Cloudflare One 用のアプリケーションが作成されます。 3.5 一般設定（General Settings） アプリケーションの基本設定画面が表示されます。 この画面では、以下を設定します。 Application label ： Okta 管理画面やユーザー画面に表示されるアプリ名 Team Domain ： Cloudflare One 側のチームドメイン 【Tips】Team Domain を設定する意味 Team Domain は、 「この Okta アプリがどの Cloudflare One 環境向けの認証か」を Okta 側が識別するための情報です。 値が一致していない場合、後続の認証フローが正しく動作しません。 入力後、「Done」を選択します。 3.6 ユーザー／グループの割り当て 作成した Cloudflare One アプリケーションに対して、 認証を許可するユーザーやグループを割り当てます。 【Tips】割り当てが必要な理由 Okta では、アプリケーションごとに 「どのユーザーがサインイン可能か」を明示的に管理します。 ユーザーやグループを割り当てていない場合、 設定が正しくても認証は失敗します。 3.6.1 ユーザーへの割り当て 「Assign」→「Assign to People」を選択します。 対象ユーザーを選択し、「Assign」を押下します。 3.7 Sign On 設定（OIDC） 次に、「Sign On」タブを開きます。 ここで確認できる Client ID と Client Secret は、 後ほど Cloudflare One 側の設定で使用します。 【Tips】Client ID / Client Secret の役割 これらはユーザーの ID やパスワードではなく、 Cloudflare One が 「正規に登録されたアプリケーションである」ことを Okta に示すための識別情報です。 4. Cloudflare One 側の設定 続いて、Cloudflare One 側の設定を行います。 4.1 Cloudflare One ダッシュボード Cloudflare ダッシュボードから Cloudflare One を開きます。 4.2 Identity Provider の一覧 左メニューから以下を選択します。 Integrations Identity providers 初期状態では、One-time PIN のみが表示されている場合があります。 4.3 IdP の追加 「Add an identity provider」を選択します。 IdP の一覧から Okta を選択します。 4.4 Okta 連携設定画面 Okta の設定画面が表示されます。 ブログ掲載用のスクリーンショットでは入力値を黒塗りしています。 ここでは各項目の意味を整理します。 項目 内容 Name Cloudflare One のログイン画面に表示される IdP 名 App ID Okta 側で発行された Client ID Client secret Okta 側で発行された Client Secret Okta account URL Okta テナントの URL 【Tips】Okta account URL について この URL は、 Cloudflare One が認証リクエストを送信する先の Okta テナントを識別するための情報です。 本番・検証環境を使い分けている場合は特に注意が必要です。 5. 認証動作の確認 設定後、Cloudflare One のテスト画面を開きます。 「Your connection works!」と表示されていれば、 Okta と Cloudflare One の OIDC 連携は正常に動作しています。 【Tips】この画面が示していること Cloudflare One が Okta から ユーザー情報を OIDC（JWT）として 正しく取得できていることを示しています。 6. SSO設定後のユーザーエクスペリエンス SSOの設定が完了した後、実際にユーザーがアプリケーションへアクセスする際のログインフローは以下のようになります。 1 Cloudflare Oneのログイン画面 ユーザーがCloudflare Oneアプリケーションにアクセス(今回はWARPにアクセス)すると、認証画面が表示されます。ここで設定したIdP（Okta）でのログインを選択し、ボタンをクリックします。 2 Oktaへリダイレクトと認証実施 ボタンをクリックすると、Oktaのログイン画面に自動的にリダイレクトされます。ユーザーはここでOktaのID・パスワードの入力や、MFA（多要素認証）などの認証プロセスを実施します。 3 RP側に戻されてログイン完了 Oktaでの認証が成功すると、再びCloudflare One側にリダイレクトされます。認証情報が正しく評価され、目的のアプリケーションへのアクセスが可能になります。 7. 技術的な補足 本構成は RP Initiated OIDC のフローを採用しています。 認証の開始点は Cloudflare One Okta が認証結果を JWT として返却 Cloudflare Oneがアクセスポリシーを評価 【Tips】ゼロトラスト設計上の利点 IdP 側の認証ポリシーを変更しても、 Cloudflare One 側の設定を変更せずに反映できる点は、 ゼロトラスト構成における大きなメリットです。 8. まとめ 本記事では、Cloudflare One において IdP として Okta を OIDC で連携する設定内容 を、 実際の管理画面スクリーンショットに沿って紹介しました。 Cloudflare One 導入時の IdP 設定を検討する際の 参考情報として活用いただければ幸いです。 執筆者 近藤 隆太 （NTT西日本 エンタープライズビジネス営業部 N＆S部門 N＆S推進担当（福岡）） 九州・沖縄エリアのクラウド・セキュリティ案件推進に携わっています。 AWS Community Builder (AI Engineering) 2025 Japan AWS Top Engineers (Services) 2024 Japan AWS Jr. Champions 参考資料・出典 Cloudflare One ドキュメント https://developers.cloudflare.com/cloudflare-one/ Okta OpenID Connect 概要 https://developer.okta.com/docs/concepts/oauth-openid/ 商標 「Cloudflare」「Cloudflare One」は、Cloudflare, Inc. の商標または登録商標です。 「Okta」は、Okta, Inc. の商標または登録商標です。 免責事項 本記事は情報提供を目的としたものであり、 記載内容の正確性、完全性、将来的な動作を保証するものではありません。