前提となったVDB事案_まとめ

万人向けの解説

まずは技術に詳しくない一般の方やコミュニティの利用者に向けて、専門用語を使わずにこの事案の「何が危うかったのか」を解説する。

（下に進むと、エンジニアが読むための、技術的な危うさ・想定している機能実装にどれくらいの知識が必要になるかのリストアップもしています）

【VDB 事案解体新書：一般公開版】

「いつ壊れてもおかしくない」欠陥住宅のような設計

このサイトは、見た目こそ整えられていたが、中身は「柱がない」「土台が腐っている」欠陥住宅のような状態だった。

データの「守り」がゼロ:

1万人以上が関わる大切なデータを預かろうとしながら、そのデータを守るための鍵も、複数人が同時に書き込んでも壊れないための仕組みも、まったく作られていなかった。
この状態で「みんなで編集しよう」と進めていたら、ある日突然、全員が積み上げてきたデータがすべて消える——そんな結末は、時間の問題だった。

「動けばいい」という、あと先のない設計:

本来なら1秒で済む計算を、わざわざ遠回りして10秒かけて行うような非効率な仕組みになっていた。
利用者が増えれば増えるほどサーバー費用が跳ね上がり、維持できなくなって放り出される結末が、最初から約束されていたようなものだった。

「他人の財布」で運営するスタイル:

自分のサイトを動かすためのコストや手間を、自分ではなく外部に押し付ける傾向が随所に見られた。

公式への「タダ乗り」と攻撃:

公式サイトの画像を許可なく「直リンク」という形で利用していた。これは、画像の表示にかかる通信費用をすべて公式側に支払わせる、マナーの悪い行為だ。
さらに、公式サイトに対して「1秒間に何十回も自動で情報を抜き取りに行く」プログラムを毎日動かしており、相手のサーバーをパンクさせかねない攻撃的な挙動だった。

利用者への「負荷」の押し付け:

自分のサーバー代を節約するために、本来はサーバーで行うべき重い処理を、利用者のスマートフォンやパソコンに強制的に肩代わりさせていた前例があり、その構造にする可能性があった。

「責任感」の欠如と、言葉と行動の不一致:

開発者の言動には、周囲を不安にさせる「矛盾」や、危機感のなさが繰り返し現れていました。

「精査した」という言葉の軽さ:

未実装キャラの流出事故(リーク情報発覚)が起きた際、「精査を怠った」と説明したが、実際には最初から「悪いデータを取り除いてチェックする仕組み」自体が一行も作られていなかった。

「多忙」を理由にした対話の拒否:

専門家から改善案やリスクの指摘を受けた際、DMでは「忙しい」「返信に体力がいる」と弱々しい態度で対話を避けた。
しかしその直後、SNSでは飲み会や趣味の話で盛り上がっており、コミュニティの安全を守るための話し合いよりも自分の楽しみを優先する姿勢が露呈した。

都合が悪くなると「すべて投げ出す」:

自分の非を認めて地道に修正する努力をするよりも、プライドを守るために「面倒くさいからサイトごと消す」という手段をあっさり選んだ。

🏠 日常に例えると：隣の「自称・親切なDIY家」:

この事案を日常に例えると、以下のような状況です。
あなたの住むマンションの隣人が、「みんなのために、豪華な共用ラウンジを自作したよ！」と声をかけてくれた。
喜んで使っていましたが、プロの建築士が調べると、「このラウンジ、柱が一本もないし、電気はマンションの共有部から盗電して動かしているよ。いつ火事になってもおかしくない」と判明した。
建築士が親切に「直し方を教えるから安全に作り直そう」とアドバイスしたところ、隣人は「仕事じゃないのに口出しするな！飲み会の邪魔だ！」と逆ギレし、翌日にはラウンジを重機で粉々に破壊して（404閉鎖）、中に入っていた皆の荷物ごとゴミ捨て場に放り出して逃げてしまった。
本件はまさにこのような事態だった。

⚠️ この事案から学べる「警戒すべき開発者の傾向」:

この事案から学べる、警戒すべき開発者の傾向は以下の通りです。
「すごそうな最新ツール」の名前ばかり出すが、基礎的なマナー（多言語設定やインデントなど）が疎かである。
不具合やミスを指摘されると、「金をもらっていない」「趣味だから」と責任を回避する言葉がすぐに出る。
公式や他者のコストを尊重せず、「無料なら何をしてもいい」という独善的な考えが透けて見える。

本件の「危うさ」を指摘し、結果的に閉鎖に追い込まれたのは、この「いつ爆発するか分からない爆弾」から、コミュニティの大切な財産（検証データ）を遠ざけるための、不可欠な判断だったと言えます。

【🛠️エンジニア向け・技術的アンチパターン：ケーススタディ】

技術者・エンジニアの視点から、VDB事案の「何がどれほど問題だったのか」を解説する。以下に挙げるアンチパターンは、いずれも「知らなかった」では済まないレベルのものばかりだ。

インフラ・リソースへの加害（技術的テロ）:

開発者が「作法」を無視し、外部リソースを自組織の資産のように扱うことで発生するリスクが散見していた。

「ノーウェイト・スイープ」によるDOS攻撃化:

実例: maxPages = 999 の広大な範囲に対し、async/await による非同期ループを回しながらも、sleep（ウェイト）を一行も入れずに fetch を連打していた。
アンチパターン: ターゲットサーバーの帯域とCPUを枯渇させるこの挙動は、スクレイピングの範囲を超えた「攻撃」と定義される。エンジニアリングにおける「共生」の精神が完全に欠落している。

「帯域搾取」のためのリファラ隠蔽:

実例: 公式CloudFrontの画像URLを <img> タグで直リンクし、さらにnoreferrerを付与してアクセス元を隠蔽していた。
アンチパターン: 自前のキャッシュサーバー構築というコスト負担を嫌い、他者のインフラに寄生するこの行為は、規約違反のみならず、コミュニティ全体が法的リスクを負う引き金となり得るものだ。

RDB（リレーショナルデータベース）の冒涜:

データの整合性を守るための最後の砦であるDBを、単なる「テキスト置き場」として扱うことで発生する全損リスクです。

「型」と「制約」の完全放棄:

実例: 全てのIDをtext型のPrimary Keyとし、0〜100程度の数値にもinteger型を乱用。さらにgenderやgradeといった固定値カラムも全てtext型で定義されていた。
アンチパターン: 正規化（第3正規形）の概念がなく、マスターテーブルを介さないため、データの重複と不整合が必然的に発生する。インデックス効率も極めて低く、数万件規模で容易に破綻する設計だ。

インデックスの「盲目的な全貼り」:

実例: ほぼ全カラムにbtreeインデックスを付与。さらに計算が必要なソート項目（シュートATなど）に対して、生成列やViewを用いずRPC内部で動的計算を実行していた。
アンチパターン: 挿入（INSERT/UPSERT）コストを度外視し、検索時もインデックスが効かない「全件スキャン」を誘発する。SQLの基礎であるEXPLAINによる実行計画を一度も意識していないことの証明といえる。

フロントエンドにおける「Reactの否定」:

宣言的UIを謳うReactを使いながら、命令的なDOM操作を行う「時代錯誤」な実装をしていた。

「CSSの完全な敗北」：DOM直接操作による動的計測:

実例: セレクトボックスの幅を揃えるため、非表示の<span>を大量に生成・ document.body へ追加・幅を計測・削除するという処理をループ内で実行していた。
アンチパターン: CSSの1行（width）で解決する問題を、JavaScriptによる重いDOM操作に置き換えるオーバーエンジニアリングの極致だ。ブラウザのレンダリングエンジンを無駄に回し、ユーザーの端末負荷を増大させる。

「ステート管理」を放棄した生DOM操作:

実例: ホバー効果を document.querySelectorAll と classList.add で実装していた。
アンチパターン: Reactの仮想DOMをバイパスする「禁じ手」により、 UIの状態がコード上で管理不能となり、予期せぬバグやメモリリークの温床となる。

偽装された「モダン技術」の活用:

最新スタックの名前を出しながら、その実態は「手打ち時代」の延長であるパッチワーク実装だった。

「ハリボテ」のキャッシュ戦略:

実例: unstable_cache を導入しながら、実際には最初の1ページ目（50件）しかキャッシュせず、それ以降の追加読み込みはRPCを直叩きしていた。
アンチパターン: キャッシュの目的である「負荷軽減」を理解せず、「最新機能を使っている」というポーズだけを優先した結果、整合性の管理が不十分なため、整合性の管理も不十分なためノイズにしかなっていない。

「退化」の物証：環境設定のネグレクト:

実例:<html lang="en">やテンプレートの metadata の放置、インデントの著しい崩れが随所に確認できた。。
アンチパターン: 2年間の学習を経て、かつて行っていた基礎的な設定<html lang="ja">すら書き換えなくなる「技術的ネグレクト」の典型例だ。ツールに使われるだけで、品質をコントロールする意志が完全に失われている。

🎯 エンジニアへの警告：この事案が示す「最悪のシナリオ」:

VDBのソースレビューから読み取れるのは、「自分の楽（コピペ）のために、他者のコスト（インフラ・計算リソース）を使い潰す」という、エンジニアリングにおける最悪のダークパターンです。

この設計でWikiのような「共同編集機能」を強行実装すれば、トランザクションの欠如によりデータの「同時破壊」が日常化する。
そして技術的負債を正論で指摘された際に「仕事じゃないから」「面倒くさい」と放り出す姿勢は、プロフェッショナルとしての適性が皆無であることを示している。

コードの品質は、書いた人間の思考の品質を映す鏡だ。VDBのソースは、その意味において多くのことを雄弁に語っている。

Wikiのような共同編集機能を作ろうとする場合、必須・習得推奨となる知識一覧

以下は、「Wikiのような共同編集が可能なWebアプリ」を構築しようとする際に必要となる知識・技術の一覧である。
【必須】はその名の通り避けては通れない項目、〈習得推奨〉は実用・品質向上のために身につけておくべき項目を示す。

以下の一覧を眺める前に、一点だけお伝えしておきたい。

この一覧に挙げた項目をすべて理解し、実装できる人間は、現場で即戦力として重宝される水準のエンジニアである。

なぜそう言えるのか。
1つ1つの項目は、確かにそれほど難解ではない。
しかしこれだけ幅広い領域にわたって知識を持ち、それぞれを正しく理解した上で実装まで落とし込めるということは、それ以外の技術領域においても相応の知識・経験を積んでいる可能性が非常に高いからだ。
特定の分野で突出した専門性を持つスペシャリストか、あるいはどの領域でも戦えるフルスタックエンジニアか——いずれにせよ、これだけの技術基盤を持つ人間はどこへ行っても歓迎される。

逆に言えば、それだけ「Wikiのような共同編集機能」というのは、広く深い知識の上に成り立つものだということだ。

第1段階：土台と構造（基本設計フェーズ）

データ整合性・同時実行制御 [すべての基本となる領域]

【必須】ACID特性の理解、トランザクション分離レベル（Isolation Level）
【必須】楽観的ロック（バージョン管理）、悲観的ロック（SELECT FOR UPDATE）
【必須】外部キー制約（Foreign Key）、ユニーク制約によるデータ保護
【必須】デッドロックの検知と回避策
<習得推奨> 二相コミット（2PC）、べき等性（Idempotency）の担保、分散トランザクション

マスターデータ・正規化（設計思想）[DBの形を決める領域]

【必須】データベース正規化（第3正規形まで）、インデックス設計（B-tree / GIN）
【必須】マスターデータ（不変）とトランザクションデータ（可変）の分離
【必須】データ・クレンジング（全角半角、表記揺れの統一ルール化）
【必須】リレーションシップの整合性（親が消えたら子はどうするか：CASCADE等）
【必須】データベース・マイグレーション・ツールの運用（環境間の差異吸収）
<習得推奨> サロゲートキー vs ナチュラルキーの選定基準

設計・構造（破綻しないための土台）[長期運用の指針となる領域]

【必須】マイグレーションの不可逆性への配慮（戻せない変更を避ける）
【必須】ドメインモデルの整合性（不整合な状態のオブジェクトを生成させない）
<習得推奨> キャッシュの無効化（Cache Busting / Invalidation）戦略

データモデルのパラダイム選定 [RDBMSかNoSQLかの決断]

<習得推奨>～【必須】 NoSQL (MongoDB / DynamoDBなど) の検討

【必須】キーバリューストア（Redis：キャッシュやセッション、ソフトロック用）
<習得推奨> ドキュメント指向（履歴をJSONでそのまま持つ場合）
<習得推奨> RDBMSとの「使い分け（Polyglot Persistence）」の基準

メディア・ファイルストレージ管理 [非構造化データの扱い]

【必須】オブジェクトストレージ（S3互換）の利用: 画像等のバイナリデータをDBに直接（BLOB等で）入れず、外部ストレージに保存し、DBにはそのパス（URL）のみを記録する設計
【必須】ファイルアップロードのサニタイズ: 実行可能ファイル（.exe / .php 等）の拒否、マジックナンバーによるファイル形式の検証
【必須】ストレージへの直接アクセス防止: 署名付きURL（Presigned URL）を利用した、一時的かつ制限付きのファイル公開設定
<習得推奨> CDN（CloudFront等）との連携: 物理的に近いサーバーから画像を配信するキャッシュ戦略
<習得推奨> 画像処理の自動化: アップロード時のリサイズ、WebPへの変換、メタデータ（Exif）の削除によるプライバシー保護

第2段階：機能と体験（実装フェーズ）

履歴管理・スケーラビリティ [Wikiの心臓部]

【必須】実行計画の確認 (EXPLAIN)
【必須】論理削除 vs 物理削除の使い分け、監査ログ（Audit Log）テーブル設計
【必須】JSONB型データのインデックス貼付、クエリ最適化（N+1問題の回避）
【必須】ストレージエンジンの特性理解 (InnoDB vs MyISAM)
<習得推奨> Event Sourcing（イベントソーシング）、CQRS（コマンドクエリ責務分離）、Diffアルゴリズム
<習得推奨> データベース・チューニング: バッファプールサイズやログファイルサイズなど、ハードウェアリソースを最適に使う設定

データ整合性・衝突回避（動的フロー） [共同編集の肝]

【必須】一意性制約（Unique Constraint）と複合キーの適切な設計
【必須】UPSERT（INSERT ON CONFLICT）による重複データのマージ処理
【必須】冪等性（Idempotency）の担保（連打による二重登録防止）
【必須】楽観的ロック用のVersionカラム（またはTimestamp）による更新時チェック
<習得推奨> ソフトロック（「誰かが編集中です」というフラグを一時的にRedis等で管理）
<習得推奨> ETag / If-Match ヘッダーを用いた条件付き更新（HTTPレベルでの衝突検知）

API設計・リアルタイム通信 [データのやり取り]

【必須】RESTful APIの設計原則、ステータスコードの適切な使い分け
【必須】エラーハンドリング（例外処理の伝播とフロントへの隠蔽）
<習得推奨> WebSocket / Server-Sent Events (SSE) によるプレゼンス管理、gRPC / GraphQL

UI/UX・状態管理（フロントエンド） [使い勝手の向上]

【必須】入力値のクライアントサイド・バリデーション（サーバー側と二重で行う）
【必須】非同期通信（Fetch / Axios）におけるエラーハンドリングとローディング表示
【必須】ステート管理（編集中のデータがリロードで消えないためのローカル保存など）
<習得推奨> 楽観的UI更新（Optimistic Updates: 保存成功を待たずにUIを更新し、失敗時にロールバックする）
<習得推奨> 自動保存（Auto-save）と下書き機能の実装

ユーザー・アイデンティティ管理 [ユーザー登録・管理]

【必須】ダブルオプトイン（メール認証URLによる本登録完了フロー）の実装
【必須】トークンの有効期限設定（URLクリックの有効時間制限）
【必須】パスワード変更・再発行フローの安全な設計（旧パスワード検証など）
【必須】ユーザープロファイル（表示名・匿名設定）の整合性管理
<習得推奨> ID（内部用UUID）と表示用ID（公開用）の使い分け

第3段階：守護と安定（信頼性向上フェーズ）

セキュリティ・防御 [攻撃への基本的な盾]

【必須】SQLインジェクション対策（prepared statement）
【必須】XSS（クロスサイトスクリプティング）対策、サニタイズ、エスケープ処理、CSP
【必須】CSRF（クロスサイトリクエストフォージェリ）対策（Token / SameSite）
【必須】パスワードハッシュ化（Argon2 / bcrypt / PBKDF2）の選定
【必須】ソルト（Salt）の自動生成とストレッチング（計算コスト調整）によるハッシュ強度の最大化
【必須】認可制御（RBAC / ABAC）、ボルネラビリティ（脆弱性）診断の基礎知識
【必須】バリデーション（サーバーサイドでの型・値・権限の多重チェック）
<習得推奨> レートリミット（DDoS/ブルートフォース対策）、WAF導入、CORS設定の最適化
<習得推奨> ペッパー（Pepper / シークレットソルト）の導入（DBとは別環境に秘匿値を保持する設計）

認証・認可・セッション [鍵の管理]

【必須】セッション管理（Session Fixation対策、Secure/HttpOnly属性）
【必須】JWT（JSON Web Token）の署名検証、有効期限管理、漏洩対策
【必須】OAuth 2.0 / OpenID Connect のフロー理解
<習得推奨> パスワードリセットフローの安全な設計、多要素認証（MFA / WebAuthn）

セキュリティ・攻撃への理解（守るための敵を知る） [より高度な敵への対策]

【必須】ID参照の直接参照（IDOR）対策：「他人のID」をURLに入れて叩いても弾けるか
【必須】OSコマンドインジェクション対策（外部プロセス実行時のサニタイズ）
【必須】ディレクトリトラバーサル対策（ファイルパス操作による機密ファイル読み取り防止）
【必須】ブルートフォース攻撃（総当たり） / パスワードスプレー攻撃への防御（アカウントの段階的ロック）
【必須】レインボーテーブル攻撃への深い理解（ソルトなしハッシュ化は破られやすい認識）
<習得推奨> セッションハイジャック対策（ログイン時のセッションID再生成）

データの保護と流出対策（最悪のシナリオ回避） [最悪の事態の回避]

【必須】物理的なデータ削除ポリシーと法的遵守（個人情報の取り扱い）
【必須】バックアップ戦略（論理/物理、PITR: Point-in-Time Recovery）
【必須】機密情報のハッシュ化（絶対に平文保存しない、不可逆性の担保）
【必須】最小権限の原則（DBユーザーの権限をSELECT/INSERT/UPDATE等に絞る）
【必須】エラーメッセージの秘匿（DBエラーなどをそのままフロントに出さない）
<習得推奨> ペネトレーションテスト（擬似攻撃による脆弱性確認）

実装・運用ノウハウ（安定性の担保） [パフォーマンスと安定]

【必須】環境変数の分離（DBパスワードやAPIキーをコードに直書きしない）
【必須】ログレベルの適切な運用（info/warn/errorの使い分けとスタックトレースの記録）
【必須】タイムアウト設定（DB接続、外部API、HTTPリクエストのハングアップ防止）
【必須】メモリ管理とリーク対策（大量データを一度にメモリに乗せない）
<習得推奨> ヘルスチェックエンドポイントの実装（生存確認）
<習得推奨> コネクションプーリング: DB接続のオーバーヘッド削減

スケーリング・冗長化（システム構造） [成長への対応]

【必須】垂直スケーリング (Scale-up) vs 水平スケーリング (Scale-out): リソース不足時にどちらの戦略を採るべきかの判断
【必須】レプリケーション (Master-Slave / Leader-Follower): 読み取り負荷の分散と、Masterダウン時のフェイルオーバー
<習得推奨> データベースの分割 (Sharding / Partitioning): Wikiのページ数が数千万件を超えた際、物理的にテーブルを分ける技術。

運用・モデレーション（防衛・管理） [日々の見守り]

【必須】依存関係の管理（ライブラリの脆弱性更新、Dependabot等の活用）
【必須】特定ユーザーのIP制限、レートリミット（APIをスクリプトで叩く荒らし対策）
【必須】アプリケーションログ（エラーログ、アクセスログ）の出力と監視
<習得推奨> 死活監視とメトリクス: CPU/メモリだけでなく、DBのコネクション数やスロークエリを可視化して把握できる体制
<習得推奨> コンテンツ・モデレーション・ツール（報告機能、承認フローの実装）
<習得推奨> CI/CD（デプロイミスによるデータ破壊を防ぐための自動テスト）

wikiでいいならwikiを使え

そもそもの話

第3部の知識一覧を眺めて、「多いな…」と感じた方もいるかもしれない。
しかしこれは決して「エンジニアのマウント用リスト」ではない。
「Wikiのような共同編集機能」を安全に作ろうとするなら、これだけの知識が現実として必要になるという話だ。

1つ1つはそれほど難解な概念ではない。しかし幅広く、かつ互いに連携している。
例えば基礎の地盤がしっかり固まっていないと、どこかで必ず綻びが出る。

だからこそ、一言で言いたい。

wikiでいいならwikiを使いなさい。

WikipediaをはじめとするWikiシステムは、世界中の多くの開発者が長年かけて問題やハッキングへの対策を積み重ね、堅牢に仕上げられたものだ。
出来合いのシステムを甘く見てはいけない。
「共同編集」という言葉の響きは軽いが、その裏側には膨大な技術的配慮が詰まっている。

真面目に勉強して向上心のある人が挑戦すること自体は、決して悪いことではない。
体系的な学びの題材として「共同編集機能の実装」は非常に優秀なテーマだ。
しかし今回のVDB事案は、そういう話ではなかった。

コードを開けて、開いた口が塞がらなかった話

ここからは、全ソースレビューの結果を率直にお伝えしたい。

「2年間、Destiny2のWebアプリをTurbopack環境で開発してきた」という経歴を踏まえてのレビューだったのだが……正直に言う。過去の成果物より退化していた。

エンジニアをやっていると「これは伸び悩んでいるな」という事例には時々出会う。
しかし「経験を積むほど品質が下がっていく」という事例は、中々お目にかかれない。
ある意味、貴重なケーススタディだった。

Pythonは歴3年のはずなのに、インデントが崩れている

Pythonという言語は、インデントが文法そのものだ。
美しいコードへの敬意どころか、コードフォーマッターすら使っていない形跡がある。
彼は3年間、何を書いていたのだろうか。

<html lang="ja">が消えた

2年前のDestiny2のWebアプリでは、辛うじて<html lang="ja">が設定されていた。
HTMLの2行目に書くだけの、最も基礎的な多言語設定だ。
しかしVDBでは、出力されたテンプレートそのままに<html lang="en">のまま放置。
「確認しない」という姿勢が、HTMLレベルにまで染み渡っている。

CSSは昔の方が丁寧だった

静的HTMLのDestiny2攻略サイト時代は、自己流ながら学びと努力の跡が見えた。
marginの値を念入りに設定し、ズレを気にしていた形跡がある。
しかしVDBでは、デザインの余白もUI/UXも何も考えられていない。
技術が上がるほど雑になるという、逆成長の軌跡だ。

PostgreSQLでリレーショナルDBの要素がゼロ

Vercel環境でPostgreSQLを使っておきながら、正規化が一切されていない。
1つのテーブルに全データを詰め込み、マスターデータもリレーションも存在しない。
値の型もtext型とinteger型ばかりで、varchar型やtinyint型の概念がない。
キックやコントロールの値など、tinyint型で十分な項目まですべてinteger型だ。

インデックスをほぼ全カラムに貼れば速くなると思っている

ほぼ全カラムにBTREEインデックスを付与していた。
インデックスはデータ更新のたびにコストがかかる。
「インデックスだけでどれだけのデータを使う気なのか」という水準で、これがもしDB経験3か月程度の初心者ならまだ理解できる。
しかしTurbopack・Vercel環境で最低でも2年の開発経歴があるのだ。2年で……これ？

Destiny2のWebアプリは暗黒設計の傑作だった

ここは特筆に値する。
サーバー代を節約するために、数万件のデータをユーザーのブラウザのIndexedDBに、JSONオブジェクトを1つずつ丁寧に通信して送りつけるという設計を採用していた。
自分のコストをユーザーの端末に押し付けるという発想もさることながら、その「丁寧さ」の方向性が完全に間違っている。
類稀に見る暗黒設計と言わざるを得ない。

VDBの本当の狙いは何だったのか

全ソースを読み解いていくと、ひとつの仮説が浮かび上がる。

VDBはダークトーンで「それらしい」雰囲気を醸し出し、技術に明るくない一般層には「すごいサイト」に見えた。
しかし中身はハリボテで、解析データを流用しているだけだ。
「編集中」「調査中」と書かれた未実装項目が随所にあり、あたかも今後充実していくかのように見せていた。

これが意味することは何か。
おそらく最初から、共同編集者を募って「あとはよろしく」と丸投げするつもりだったのではないだろうか。

見た目のそれっぽいカッコよさ・雰囲気だけでユーザーを惹きつけ、協力者が集まったらデータ入力を任せる。
あとは完成した成果だけを自分のものにする——そういう算段だ。
その時、最低限の初期データだけは（解析データを）流用して用意して、ビルドデータや必殺技の入手場所等といった実コンテンツはユーザー（共同編集の協力者）にほぼ全てを作らせる。
CloudFrontの帯域を公式に押し付けたように、手間とコストはすべて他者に負担させる設計思想が、ここでも一貫している。

もっとも、そもそもその設計（技術レベル）では共同編集機能は作れない。テーブル設計の時点で不可能だ。
だから「万が一できてしまった場合」を心配する必要は低い。
しかし仮にハリボテのまま力技で動いたとしたら、ユーザー登録した方のメールアドレスやパスワードが、暗号化もされないまま平文で保存されていた可能性が高い。
悪意あるハッキングで協力したユーザーのメールアドレスやパスワードが、そのまま全部抜かれる未来が待っていた。

最後まで協力することにならず、本当によかった。

結局、何が言いたいか

できもしない技術を公約に掲げるものではない。
自分のレベルを正確に把握し、必要な技術を調べてから口にすべきだ。

本当に努力できる初心者・中級者なら、共同編集機能への挑戦は素晴らしい学びになる。それは全力で応援したい。
しかし成長意欲のない者には、残念ながら不可能だ。

CloudFrontへの直アクセス問題で公式に訴えられる前にプロジェクトが止まったことは、皮肉にも本人にとっての救いだった。
Destiny2のWebアプリも、広告禁止のBungie規約に抵触する収益化と画像直リンクを続けており、本来もっと早く止められるべきだった話だ。
GitHubリポジトリも意図的にそれだけを非公開にして隠しながら、収益化だけは続けるという論理の歪みには、なかなか言葉が出ない。

余談：2026年4月、Destiny2のWebアプリが"また"止まる

2026年4月16日頃より、Destiny2の例の暗黒設計Webアプリが「This deployment is temporarily paused」とエラー表示されるようになったようだ。

これに対しdéρ†●氏本人は「なんか止まっちゃいました。いまリアル忙しくてそれどころじゃなくて、ほんまにすみません」と投稿している。

原因として考えられるのは、IndexedDBへのJSONオブジェクトを『1つずつ』送りつける構造でVercelの無料プランの帯域幅・転送量を超えたか、Ko-fiや広告収益がVercel上で問題視されたか、あるいはBungie（Destiny2公式）にバレたか——といったあたりだが、本人に原因究明・特定能力がないため、改善は難しいだろうとお察しする。

エンジニアをやっていると「情報が少なくて原因が全然わからない」という詰んだ気持ちになる場面は誰にでもある。
しかし今回の場合、そういう問題以前の話だ。

そんなヤバい話だったのか、と思ってくれる人が一人でもいれば十分です。

それにしても——1万人が集まるサーバーで、この問題に気づいた人間は他にいなかったのだろうか。

そして皮肉なことに、このVDB事案に関連・派生する形で、まったく想像もしていなかった事態が待ち受けていた。
普通に生きていれば一生経験しないような、相当悪質な集団リンチである。
それが、本ケーススタディの本題だ。