はじめに こんにちは、レバレジーズ株式会社で普段はエンジニアをしているスガノです。 今回、 「テックフェス2026冬」運営委員長 を務めさせていただきました。 本記事では、レバレジーズグループ全体のエンジニアが一堂に会した 「テックフェス 2026 冬」 の様子を紹介します。 今回のテックフェスは「 セキュリティ 」 を軸に、 基調講演、総勢100名以上が参加したテックバトル、セキュリティにまつわるハンズオンやセッションなど、さまざまなコンテンツを実施しました。 特にテックバトルやハンズオンは、セキュリティ専門チームが主導し、テックフェス用のオリジナルコンテンツとして作成しました。 この一日を通し、セキュリティへの学び・楽しさはもちろん、横との繋がりを実感できる場となりました！ テックフェスとは テックフェスは、レバレジーズグループに所属するエンジニアを対象に、半年に一度開催される社内最大級の技術イベントです。 エンジニアが新しい技術に興味を持ち、みんなで学び合うことを目的に、 組織全体の技術力と交流を高める “社内の技術祭” として続いています。 このイベントの特徴は、 事業部の垣根を超えて “有志のエンジニアたち” が自ら運営していること 。 普段は異なる開発チームに所属するメンバーが全部署から横断的に集まり、テーマ設計から企画・広報・当日の運営までを自分たちの手で作り上げています。 2026年2月に開催された 「 テックフェス2026 冬 」 のテーマは、 「 急成長のその先へ。セキュリティで信頼と未来を創る 」。 このテーマの背景には、会社として掲げている “1兆円規模の企業を目指す” という大きな目標があります。 その未来を支えるエンジニア組織として、攻めと守りを両軸に、次の2つの側面から進化していく必要があると考えました。 ① 学ぶ機会の創出 なんとなく苦手意識があったり、学ぶ機会が乏しいことのあるセキュリティ。昨今、ニュースでも大規模なインシデントが複数報道されました。 これからのレバレジーズは1兆円規模の企業を目指します。セキュリティの文脈で、狙われる機会も増えてくるでしょう。 今だからこそ、学ぶことが不可欠と捉えました。 ② 楽しみながら学ぶ 「そうは言っても知らないこと多そうだな...」と思う方もいるでしょう。 そこで、守りだけでなく、攻めたり壊したりすることで、攻撃者の目線も学びつつ、アクティビティとしてのめり込める楽しさも必要条件だと考えました。 やらされる学びより、やりたくなる学びを。こんな思いでコンテンツを作ってまいりました。 セキュリティを専門とするエンジニアが中心となった今回のテックフェスは、どのようなものになったのか？ 早速、コンテンツの様子を見ていきましょう！ CTFをモチーフにしたテックバトル テックフェスの目玉コンテンツである テックバトル 。今年は1回戦、2回戦に分けて実施しました。 1回戦 1回戦は 「セキュリティ×謎解き」と呼ばれるCTF を元にした、Webアプリの脆弱性を突く「攻撃者の視点」を体験できるテックバトルをしました。セキュリティを専門とするエンジニア社員らが作ったこのバトルでは、 セキュリティ未経験者を含む約100名が参加し、システムに隠された脆弱性を特定し、制限時間内にどれだけ多くのFlag（答え）を獲得できるかを最終的な合計得点を競うクイズ（Jeopardy）形式で実施しました。 採点には、正解者数に応じて問題の配点がリアルタイムに変動する「ダイナミックスコアリング」を採用。多くの人が解いた問題は価値が下がり、誰も解けない難問は高得点を維持し続ける仕組みにより、どの問題から着手すべきかという戦略性と、刻一刻と順位が入れ替わる緊張感を演出しました。 また、あえて「AIによる自動解答の禁止」をルールとし、代わりにヒント機能を充実させることで、安易な解決ではなく参加者自身の「閃き」と「調査能力」を問う設計にもしました。 この1回戦は、参加者が「攻撃者の視点」を安全な環境で体験できるよう企画・開発を進めました。実際に手を動かしてシステムを攻略する快感を通じ、教科書だけでは学べない「なぜそのコードが危険なのか」という防御の勘所を、楽しみながら肌感覚で習得できる場を目指しました。 2回戦 2回戦のテーマは ハードニング競技会をモチーフにした「システムをぶちこわしてバトル」！ 1回戦の結果を踏まえて分けられたチームに、ECサイトを模したWebサイトのソースコードが配布されます。各チームをスタートアップ企業に見立て、セキュリティインシデントが株価に影響するという緊張感のある設定です。 制限時間内に自チームのECサイトのセキュリティ対策をしたり、他チームのECサイトの脆弱性をつくような攻撃をしたりして、自チームのスコアを稼ぎます。 採点は株価だけでなく、ソーシャルエンジニアリングの考え方を加味した方法で実施しました。具体的には、開始前に配布されたパスワードの紙を、競技中に会場内を歩き回る運営に撮影されたら減点という形です。 このように2回戦は、獲得点数を株価と定義することで、参加者のセキュリティ意識が会社の信用度に直結することを、楽しみながら意識できるルールにしました。 テックバトルの内容は好評で、フェス翌日も、 「セキュリティ面白い！解けていない問題があるし、楽しかったから続きをやらせて！」という問い合わせが相次ぎ、急遽コンテンツの閉鎖を1週間延長するほど でした。 ペネトレーションテストのハンズオン 今回のテックフェスでは、 完全内製の「ペネトレーションテスト・ハンズオン」 を90分の枠で開催しました！ このハンズオンは、今回のために セキュリティ専門チームが作った特製のハンズオン です。 「セキュリティを身近に」をコンセプトに、自社サービスを模した“やられサイト”を用意。セキュリティチームも使用しているテストツール（Burp Suite）を用い、社内事例をベースにした脆弱性攻撃を初心者でも迷わず体験できるよう難易度設計に極限までこだわりました。 ハンズオンが始まるとSlackのスレッドは質問や実況で大変賑わい、「ハッキング体験が楽しい」「リスクを肌で感じた」との声も多く、アンケートでもほとんどの参加者から「大変満足」という回答を頂きました。準備は大変でしたが挑戦して本当に良かったです。 ご参加いただいた皆様、ありがとうございました！ セッション セッションには、セキュリティを専門とするエンジニア社員を中心に、5名の方に登壇いただきました。 ハイレベルな専門的内容もありましたが、とてもわかりやすくお話しいただき、セキュリティ未経験者・経験者に関わらず学びの多い時間となりました。 発表者の社員の皆さん、お忙しい中ありがとうございました！ 「ただの訓練」で終わらせない。標的型攻撃の実態と脅威 （レバレジーズ 情報セキュリティ室 杉本） この if 文を突破できる？TypeScriptで学ぶコードの脆弱性 （レバレジーズ レバテック開発部 松浪） “いくら損する？“を計算する。EDC手法による定量的なリスク評価と対策効果の可視化 （レバレジーズ テクノロジー戦略室 原田） AWSセキュリティインシデント対応実録と教訓 （レバレジーズ ソリューション開発部 橘） 退職者アカウントを削除しても要注意！人的脅威からは簡単に逃れられない… （レバレジーズ 情報システム室 高田） 懇親会 テックフェス終了後は、お待ちかねの懇親会を開催！ 今年は「縦と横との繋がりを作る」を裏テーマに、コミュニケーションを促進させる話しかけやすい雰囲気の場を設計しました。 会場のメインコンテンツは、参加者全員を巻き込んだ「スタンプラリー」。 「出身地が同じのメンバーを探す」「Slackアイコンしか知らない人と交流する」といったミッションをきっかけに、 初対面同士でも自然と会話が弾む仕掛け を用意しました。 結果、アンケートでは参加者の85%が「他事業部の人と交流できた」と回答するなど、まさに事業部の垣根を越えたコラボレーションの種があちこちで芽吹いていました。 もちろん、尽きない会話に華を添えるのは、 寿司やピザなどの豪華な食事たち 。 そこで生まれた、人とのつながりによる化学反応が、組織の結束をより強固なものにし、熱気冷めやらぬまま幕を閉じました。 最後に 今回のテックフェス2026冬は、「 急成長のその先へ。セキュリティで信頼と未来を創る 」というテーマのもと、学びやつながりが各所で萌芽する特別な1日となりました。 セキュリティは難しい、発表機会が少ない分野の1つと言われることも多いですが、今回のフェスではセキュリティ専門チームが中心となり、ハイレベルかつワクワクするような時間を作ることができました。 加えて、この1日は運営・参加者全員の笑顔と熱意があったからこそ成り立ったのだと思っています。 いつの時代も、 “人と人がつながる力” こそが最大のエンジニアリングではないでしょうか。 最後までお読みいただきありがとうございます！ それでは、次回のテックフェスでまたお会いしましょう！ P.S. 今回のテックフェスも、朝から会場がいい香りに包まれていました。 実は 社内エンジニア有志の「コーヒー事業部」 がまたまたコーヒーを提供してくれてました！ コードも書けて、豆も挽ける。そんな “フルスタックな男たち” の奮闘記は こちら ！ レバレジーズでは、社内で技術ノウハウの共有を行うイベントはもちろん、外部から著名な方をお呼びして貴重なお話を聞く機会を積極的に設けております。 レバレジーズに少しでも興味を持っていただけた方は、 こちらからエントリー をお願いします。 ■関連リンク 会社説明資料 ~ 過去のテックフェスレポート ~ - 【1日密着】AIと共に次世代のエンジニアへ/レバレジーズテックフェス/AIハッカソン - テックフェス2025 夏レポート - テックフェス2025 冬レポート - テックフェス2024 夏レポート - テックフェス2024 冬レポート - テックフェス2023 春レポート - テックフェス2022 秋レポート

背景・経緯 MLチームの紹介 こんにちは、株式会社バンダイナムコネクサスのデータ戦略部でML（機械学習）チームに所属している山野です。弊社データ戦略部は、グループ最大のデータ戦略部門です。MLチームはMLプロダクト/プロジェクトマネジメント、モデリング、およびMLシステムの開発/運用にスペシャリティを持つメンバーで構成されています。私たちMLチームはこれまで、MLプロダクト開発を一気通貫で担当してきました。過去の案件事例の一つはこちら（レコメンドシステム導入事例）です。 MLチームのスコープ 青背景部分がMLチームのスコープであり、今回はその中の赤枠で示された部分の役割とし

金融IT本部 入社1年目の河岸歩希です。 会社の同期と個人開発に取り組んでいます。 その過程で「LINEのような個別チャット機能」を実装するにあたり、AWSのサーバーレス構成（Lambda ＋ DynamoDB）の採用を検討することになりました。 今回は実際に調査と設計を行う中で得られた気づきについて共有させていただきます。 はじめに 想定読者 本記事の目的 チャット機能の要件 DynamoDBの設計を理解する 基本的な仕組み プライマリキーとパーティション ホットパーティションに注意する データアクセスパターン RDBとの違い アクセスパターンを洗い出す チャット機能へのアクセスパターン テーブル設計 最初に考えた設計 問題「自分の参加ルーム一覧」が取れない GSIとは GSIで何が解決できるのか GSIの特徴 射影（Projection）という概念 LSI（ローカルセカンダリインデックス）との違い テーブル設計(完成) Messagesテーブル GSI（グローバルセカンダリインデックス） まとめ はじめに 想定読者 RDBは触ったことがあるけど、DynamoDBは初めての方 「DynamoDBって何が嬉しいの？」という疑問をお持ちの方 サーバーレス構成でチャット機能を作りたい方 本記事の目的 DynamoDBとRDBの設計思想の違いを理解する チャット機能の要件 今回調査したのは、LINEのような1対1の個別チャット機能です。 個別チャット機能はアプリケーション全体のコア機能ではありませんが、初めて実装する機能だったため、先行して調査を行いました。 チャット機能を実装するにあたり、以下のような要件を整理しました。 要件 理由 リアルタイム性 メッセージは送信後すぐに相手に届いてほしい 高頻度の書き込み チャットはメッセージの追加が頻繁に発生する スケーラビリティ 現状は30人規模だが、将来的な拡大も想定したい 高可用性 業務時間中はいつでも利用できる状態を維持したい DynamoDBの設計を理解する DynamoDBはNoSQL(Not Only SQL)データベースの一種で、キーバリュー型に分類されます。 キーバリュー型の特徴は、キーを指定して値を取得するシンプルな構造です。 DynamoDBでは、データは以下のような構造で格納されます。 テーブル └── 項目（Item）← 1件のデータ ├── パーティションキー: "UserA" ← キー（必須） ├── ソートキー: "2026-01-17" ← キー（任意） ├── Name: "鈴木一郎" ← 属性 ├── Email: "suzuki@example.com" ← 属性 └── Department: "営業部" ← 属性 項目（Item） : 1件のデータのまとまり(RDBでいう「行」) キー（プライマリキー） : 項目を一意に特定するもの 属性（Attribute） : 項目が持つ各フィールドのこと 基本的な仕組み DynamoDBのようなキーバリュー型のデータベースを理解するうえで、最も重要なのは「キー」の設計です。 はじめに「プライマリキー」の構成について説明します。 プライマリキーとパーティション プライマリキーは「パーティションキー」と「ソートキー」で構成されており、これらを適切に設計することで、効率的なデータアクセスが可能になります。パーティションキーは必須、ソートキーは任意です。 パーティションキーの役割はその名の通り「パーティション（区画）を決定する」ことです。 DynamoDBでのパーティションは、SSDによってバックアップされ、AWSリージョン内の複数のアベイラビリティゾーン間で自動的にレプリケートされる、テーブル用のストレージの割り当てのことを指します。 公式ドキュメントには以下のように記載されています。 DynamoDBは、パーティションキーの値を内部ハッシュ関数への入力として使用します。 ハッシュ関数からの出力により、項目が保存されるパーティション (DynamoDB内部の物理ストレージ) が決まります。 出典： パーティションとデータ分散 - Amazon DynamoDB デベロッパーガイド つまり、同じパーティションキーを持つデータは物理的に同じパーティションに格納され、異なるパーティションキーを持つデータは別のパーティションに格納されます。 以下の図は、同ドキュメントから引用したものです。 この図では、パーティションキー「AnimalType: Dog」を持つ項目が、ハッシュ関数を通過し、その出力値に基づいて特定のパーティションに格納される様子を示しています。 同様に「Fish」「Lizard」「Bird」「Cat」「Turtle」といった異なるパーティションキーを持つ項目は、それぞれ異なるパーティションに分散して格納されます。 これがパーティションキーのみを用いた場合の、DynamoDBにデータが格納される仕組みです。 この方法に加えて、パーティションキーとソートキーを組み合わせた 複合プライマリキー と呼ばれるタイプも存在します。 この図では、パーティションキー「AnimalType」とソートキー「Name」を組み合わせています。同じパーティションキー「Dog」を持つ項目（Bowser、Fido、Rover）は、同じパーティションに格納されます。 その中でソートキー「Name」によって項目が一意に識別され、ソートされた状態で格納されます。複合プライマリキーを使用することで、「同じパーティションキーを持つ複数の項目」を1つのパーティションにまとめて格納し、ソートキーを使って範囲検索やソートを行うことが可能になります。 なので効率的なデータ探索をするためにも、シンプルなプライマリキーにするのか、複合プライマリキーを利用するべきなのかは、アプリケーションのユースケースによって異なるため、事前にどのようなアクセスパターンでデータ操作するのかを検討することが重要です。公式のベストプラクティスでも、アクセスパターンを事前に把握したうえでのキー設計が推奨されています。 NoSQL の設計の違い 対照的に、DynamoDB の場合は答えが必要な質問が分かるまで、スキーマの設計を開始すべきではありません。 ビジネス上の問題とアプリケーションのユースケースを理解することが不可欠です。 出典： NoSQL 設計のベストプラクティス - Amazon DynamoDB デベロッパーガイド 「答えが必要な質問が分かるまで」という表現は少々わかりづらいですが、言い換えると 「どのようなクエリパターンでデータを取得するのかが明確になるまで、スキーマ設計を始めるべきではない」 ということだと解釈しています。 ホットパーティションに注意する ここまでのパーティションキーの説明を踏まえて、パーティションがキーごとに分散されるのなら、仮にユーザー数が増えたときにパーティションの上限が来るのではないかという疑問が浮かびました。 公式ドキュメントに以下のような記載がありました。 DynamoDB テーブルには、パーティションキーバリューごとに個別のソートキーバリューの数に上限はありません。何十億もの Dog 項目を Pets テーブルに保存する必要がある場合、DynamoDB はこの要件を自動的に処理するのに十分なストレージを割り当てます。 出典： パーティションとデータ分散 - Amazon DynamoDB デベロッパーガイド つまり、パーティションが増えること自体は問題ではないということです。 むしろ注意すべきは、特定のパーティションにアクセスが集中することです。これを「 ホットパーティション 」と呼びます。 例えば、パーティションキーを「日付」にした場合を考えます。今日のデータへのアクセスが集中し、過去の日付のパーティションはほとんど使われません。せっかくパーティションが分かれていても、1つに集中してしまっては意味がありません。 今回のチャット機能では、パーティションキーを RoomId にしています。1対1の個別チャットなので、全員が同じルームに集中することはなく、ルーム数が増えるにつれてアクセスは自然と分散されます。もしグループチャットや全社連絡用のルームを作る場合は、特定のルームにアクセスが集中する可能性があるため、別の設計を検討する必要があるかもしれません。 なので、ユーザーアクセスが特定のパーティションに集中することがないようにパーティションキーを設定する必要があります。 データアクセスパターン DynamoDBのデータを取得する方法は主に2パターンあります。 方法 説明 速度・コスト Query パーティションキーを指定して取得。ソートキーで範囲指定やソートも可能 高速・低コスト Scan テーブル全体を走査して条件に合うものを取得 低速・高コスト 基本的にはQueryを使い、Scanは避けるべきとされています。Queryが高速なのは、たった今説明したように、パーティションキーやソートキーによってパーティションが明確に分けられているからです。この分散したデータ管理によって、DynamoDBは大規模なデータに対しても高速なアクセスを実現することができます。 具体的には、一つのテーブルに対して同時にアクセスする際にも、パーティションが分かれていることによって、同時実行性が向上し、スループットを効率的にスケールさせることが可能となります。 またScanはテーブル全体をスキャンするオペレーションであるため、テーブルが大きくなるにつれて、処理速度は遅くなります。そのため応答時間短縮のためにも、なるべくQueryを使用できるように、テーブル設計段階で適切なパーティションキーとソートキーを検討することが大切です。 RDBとの違い ここまで理解したところで、ある疑問が浮かびました。 「RDBでもWHERE句を使えば、目的のデータを効率的に探索できるよね？DynamoDBのパーティションキーを指定するのと何が違うの？」 この時点では突出したDynamoDBの良さを感じることはできていませんでした。(初心者目線です...) ただ、調べていくうちに、 「1回のクエリの速度」ではなく「同時に大量のクエリが来たとき」 に違いが出ることがわかりました。 RDBの場合、1000人が同時にアクセスすると、すべてのリクエストが1台のDBサーバーに集中します。(リードレプリカやマルチAZ構成にした場合を除く) その結果、CPUやコネクションが逼迫し、全体的にレスポンスが遅くなります。 一方、先ほども説明したとおり、DynamoDBの場合、各リクエストはパーティションキーに基づいて別々のパーティションに分散されます。 そのため、同時接続数が増えても負荷が1箇所に集中せず、レスポンス速度を維持できます。 公式ドキュメントにも、以下のような記載があります。 RDBMSでは、データは柔軟にクエリできますが、クエリは比較的コストが高く、トラフィックが多い状況では スケールがうまくいかない場合があります。 出典： リレーショナルデータ設計と NoSQL の相違点 - Amazon DynamoDB デベロッパーガイド DynamoDBは、パーティションキーによるハッシュ分散があるからこそ、データ量やアクセス数が増えても性能を維持できます。これがRDBとの大きな違いの一つです。 なので大規模アプリケーションや人気イベント等などの、ユーザーからの大量なアクセスが予想される際は、こういったDynamoDBの分散管理の仕組みが輝くということがわかりました。 アクセスパターンを洗い出す 実際にここからテーブル設計の流れを共有します。 前述したNoSQLの設計のベストプラクティスの引用文の中でもあったように、DynamoDBでは「どのようなクエリパターンでデータを取得するのか」を明確にしてから設計を始める必要があります。 そこで、まずはチャット機能のアクセスパターンを洗い出しました。 チャット機能へのアクセスパターン ケース パターン 使用例 1 特定ルームのメッセージ一覧を取得 チャットルームを開いたとき 2 最新N件のメッセージを取得 初期表示・スクロール時 3 自分が参加しているルーム一覧を取得 チャット画面を開いたとき 4 新しいメッセージを追加 メッセージ送信時 5 新しいチャットルームを作成 初めてのDMを送るとき 6 チャットルームを削除 ユーザーがルームを消したとき このような形でアクセスパターンを洗い出しました。その後に、「何を起点にデータを探すか」を考えてみます。 ケース1, 2, 4： RoomId を起点にメッセージを操作 ケース3： UserId を起点にルームを検索 ケース5, 6：ルームの作成・削除 ここでケース3だけ他のケースとは起点となるデータが違ってしまうことに気づきました。 DynamoDBでは、パーティションキーとソートキーを指定することで効率的にクエリを実行できますが、パーティションキー以外の属性を検索条件にすることはできません。 テーブル設計 最初に考えた設計 メッセージを格納するテーブルとして、以下のような設計を考えました。 パーティションキー ：RoomId（チャットルームのID） ソートキー ：Timestamp#UserId（送信時刻と送信者ID） 属性 ：Message アクセスパターンを踏まえて、一番起点となるデータをパーティションキーに持ってきました。また、 ソートキーにはチャットの履歴の取得などを行いたいので、タイムスタンプとして、同じ時間に送信した場合にどちらのユーザーが送ったのかを判別するために UserId と結合させて ソートキーに格納します。 パーティションキーに RoomId を指定してQueryを実行すれば、そのルームのメッセージがソートキー（時刻順）でソートされて取得できるイメージです。 問題「自分の参加ルーム一覧」が取れない しかし、「自分が参加しているルーム一覧を取得（ケース3）」を実現しようとした際、壁にぶつかりました。 現在の設計では、パーティションキーは RoomId です。 DynamoDBのQueryは パーティションキーの完全一致 が必須なので、「 UserId を起点にルームを検索する」ということはできません。 これを解決するのが GSI（グローバルセカンダリインデックス） という仕組みです。 GSIとは GSIを一言で説明すると、 「元のテーブルとは別のプライマリキーでQueryできるようにするコピーテーブル」 です。 公式ドキュメントには以下のように記載されています。 グローバルセカンダリインデックスには、ベーステーブルとは異なるパーティションキーとソートキーがあります。 出典： グローバルセカンダリインデックス - Amazon DynamoDB デベロッパーガイド GSIで何が解決できるのか 公式ドキュメントのシナリオがとてもわかりやすかったので、具体的な使用例はそちらを参考にしていただければと思います。(上記のGSIの出典先と同じリンク) GSIを定義することで、元のテーブルに加えて、別の切り口で検索できるようになります。 【元のテーブル】 パーティションキー: RoomId ソートキー: Timestamp#UserId → 「特定ルームのメッセージ」を取得できる 【GSI】 GSI-パーティションキー: UserId GSI-ソートキー: RoomId → 「特定ユーザーの参加ルーム一覧」を取得できる GSIで新たに選ばれたパーティションキー UserId ごとに、異なるパーティションにデータが元のテーブルからコピーされます。 これによって、ケース3の「自分が参加しているルーム一覧を取得」も実現できそうです。 GSIの特徴 GSIについて調べる中で、以下のような特徴があることがわかりました。 特徴 説明 元テーブルとは別のプライマリキーを設定可能 柔軟な検索が可能になる データは自動で同期される 元テーブルに書き込むとGSIにも反映(結果整合性) 後から追加可能 設計を間違えても後からリカバリできる 追加コストがかかる 書き込み・ストレージ両方で課金 注意点として、結果整合性であるため、書き込み直後にGSIをクエリすると、最新のデータが反映されていない場合があります。 そのため、リアルタイム性が重要な場面では考慮が必要になります。今回はGSIを使うのが、自分が参加しているルーム一覧取得の場面のみなので、多少のデータ遅延は許容できると判断しました。(実際ルーム作成直後にそのままルームでチャットを始めると思うので...) これが金融の残高照会等のシビアな要件が絡むと、この結果整合性に伴う遅延が大きな影響をもたらすので、要件と照らし合わせて適切なアーキテクチャを選択する必要があります。 射影（Projection）という概念 GSIを学ぶ中で、 射影（Projection） という概念にも出会いました。 射影とは、「元テーブルのどの属性をGSIにコピーするか」を指定するものです。 今回は KEYS_ONLY （キーのみコピー）を選びました。 理由は、GSIで取得したいのは「どのルームに参加しているか」という RoomId の一覧だけで、メッセージ本文などの属性は不要だからです。 GSIにコピーされていない属性が必要な場合、元テーブルに対して追加のクエリが必要になります。 そのため、アクセス頻度が高い属性は射影に含めておくことで、クエリ回数を削減できます。 公式ドキュメントにも、以下のような記載がありました。 一部のアプリケーションでは、テーブルに対して多くのクエリを発行する必要があり、その結果、プロビジョニングされたスループットの多くを消費することがあります。これを軽減するために、すべてまたは一部のテーブル属性をグローバルセカンダリインデックスに射影できます。 出典： グローバルセカンダリインデックス - Amazon DynamoDB デベロッパーガイド ストレージ管理コストは増えますが、頻繁にアクセスする場合はクエリコストの削減で相殺されるという考え方です。 LSI（ローカルセカンダリインデックス）との違い GSIを調べる中で、 LSI（ローカルセカンダリインデックス） という似た概念があることも知りました。 LSIの「ローカル」とは、 同じパーティション内に存在する という意味です。 GSIは元テーブルとは別のパーティションにデータがコピーされますが、LSIは同じパーティション内でソートキーだけを変えたインデックスです。 今回の設計では GSI を使うのがよさそうだと判断しました。 理由は、LSIでは要件を満たせないからです。 今回のアクセスパターンの中で「ユーザーIDで、自分の参加ルーム一覧を検索する」部分があります。 メインテーブルのパーティションキーは RoomId なので、 UserId で検索するにはパーティションキーを変更する必要があります。 LSIではパーティションキーを変更できないため、そもそも今回の要件を満たせません。 そのため、GSIを採用しました。 さて、これらのプロセスを経て、実際にテーブル設計が完了しました。 今回設計したテーブルは以下のとおりです。 テーブル設計(完成) Messagesテーブル 項目 値 説明 パーティションキー RoomId チャットルームのID（例： suzuki_yamada ） ソートキー Timestamp#UserId 送信時刻とユーザーID（例： 2026-01-18T10:30:00Z#suzuki ） 属性 Message メッセージ本文 GSI（グローバルセカンダリインデックス） 項目 値 説明 GSI名 UserRoomsIndex GSI-パーティションキー UserId ユーザーID GSI-ソートキー RoomId チャットルームID 射影 KEYS_ONLY プライマリキーのみコピー これにより、以下の検索が可能になります。 アクセスパターン 使用するインデックス クエリ方法 特定ルームのメッセージ一覧 メインテーブル パーティションキー=RoomIdでQuery 自分の参加ルーム一覧 GSI（UserRoomsIndex） GSI-パーティションキー=UserIdでQuery ここまででテーブル設計が完了しました。 まとめ 今回、チャット機能のためのDynamoDBテーブル設計を行いました。 設計を通じて学んだポイントは以下の3つです。 アクセスパターンを先に考える DynamoDBでは「どんなクエリが必要か」を明確にしてからキー設計を行う。RDBのように後からインデックスを追加して柔軟に対応する発想ではうまくいかない。 パーティションキーの設計が最重要 パーティションキーによってパーティションが決まり、検索効率とスケーラビリティが大きく変わる。ホットパーティションを避け、アクセスが分散されるようなPKを選ぶ。 GSIで検索の柔軟性を確保 メインテーブルのパーティションキーでは対応できないアクセスパターンがある場合、GSIを活用する。ただし結果整合性やコストには注意が必要。 今回はここまでで、実装はこれからです。 あくまでも机上の設計なので、実装段階で想定外のエラーや設計の見直しが発生するかもしれません。そのときはまた調べて共有できればと思います。 初心者なりにまとめてみましたが、同じようにDynamoDBを学び始めた方の参考になれば幸いです。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @kawagishi.ibuki （ Shodo で執筆されました ）