スタートアップで認証機能を組み込むとき、AWS Cognitoを選んだらどうなるのか。元記事は、その答えをかなり辛辣に書いた体験記だ。筆者は「AWSの中にあるから便利そう」「最初の50,000 MAUは無料」という理由で採用したものの、実際にはドキュメントの分かりにくさ、Amplify v6の破壊的変更、ローカル開発のしづらさ、Hosted UIの自由度の低さに次々と悩まされたという。単なる愚痴ではなく、認証基盤を選ぶときに何を重く見るべきかまで踏み込んでいるのが、この文章の面白いところだ。
筆者は、スタートアップの認証をAWS Cognitoで実装し始めてから3日ほどで違和感を覚えた。手順通りに進めているのに、パスワード再設定の画面が期待と違う場所へ飛んでしまう。ドキュメントを十二のタブで開き、コード例を写し、解説動画まで見たのに直らない。すでにAuth0やFirebase Auth、さらには自前のJWT実装まで触った経験がある筆者ですら、Cognitoは別物だったという。
不満の中心は、まずドキュメントにある。AWSの説明は、エンタープライズ向けの設計思想、フロントエンド開発者向けのログインフォーム、モバイル向けのSDK説明が同居していて、誰に向けた文書なのかが曖昧だと筆者は言う。custom attribute validation を調べると、前提知識が山ほど必要な別ページに飛ばされる。加えて、コード例も旧JavaScript SDK、Amplify v1、raw AWS SDKが入り交じり、どの世代の話なのか判別するのに import 文まで読む羽目になる。
次に、JavaScriptライブラリの変更が大きな負担になった。開発開始時点ではAmplifyはv5だったが、数週間後に不具合修正のため戻ると、v6でCognitoとのつなぎ方自体が変わっていた。単なるメソッド名変更ではなく、画面のフローごと作り直しになるほどの再設計だったという。移行ガイドはあったが、足りない目印だらけの地図のようで、結局は「リファクタリング」ではなく「書き直し」になった。筆者はこれを、アップグレードではなく人質に取られたようなものだと表現している。
さらにローカル開発でも苦しんだ。Cognitoはクラウドサービスなので、ローカルに完全な実体を立ててオフライン検証するのが難しい。serverless-offlineのような補助ツールや、非公式のエミュレーターはあるが、どれも完成度にばらつきがある。結果として、ローカルでは見逃した問題がステージングで露呈しやすい。開発初期のスピードを落とし、実際のAWSエンドポイントに縛られる感覚が強いと筆者は批判する。
Hosted UIの話も厳しい。見た目を自社ブランドに寄せたいと思っても、できるのはロゴ変更や多少のCSS調整程度で、全体の構造はAWSのもののまま。凝ったカスタマイズをしたければSDKで自前UIを作るしかないが、それではHosted UIの利点が薄れる。筆者はこの「便利そうで中途半端」な感じにかなり苛立っている。
最後に、メールアドレスだけで認証したい構成でつまずく。Cognitoではemailが標準属性なのか、aliasなのか、custom attributeなのかで扱いが変わるうえ、設定画面が複数に分かれていて相互依存が分かりづらい。筆者は初期設定で本来は標準属性にすべきものをcustom attributeにしてしまい、あとから変更しようとした。しかし一度custom attributeとして作ると、もう戻せない。現実的な選択肢は、ユーザープールを削除して作り直すか、既存ユーザーを新しいプールへ移行する仕組みを組むかのどちらかだった。そこで筆者は、認証は「あとで直せる場所」ではないと痛感した、という話で締めている。
この文章でいちばん刺さるのは、Cognitoそのものの機能不足というより、「AWSの一部であること」が安心材料になりきらない、という指摘だと思う。クラウドサービスを選ぶとき、つい既存の契約や権限、他サービスとの近さで決めたくなる。でも実際には、毎日触るのは請求書ではなくコードと設定画面だ。そこでつまずくなら、インフラ上の近さはあまり意味を持たない。筆者が言いたいのはたぶんそこだろう。安い、既存基盤とつながる、といった利点はある。ただ、認証は一度組むと長く付き合う領域なので、日々の摩擦が小さいかどうかの方が効いてくる。
ここで面白いのは、筆者が「Cognitoは悪」と単純化していない点だ。むしろ、プロダクトとして成熟していないと言っているわけでもない。問題は、設計思想が複数の利用者に引っ張られすぎて、どこから入っても分かりにくくなっていることだと思う。エンタープライズ向けの概念を理解したい人、フロントエンドで早くログインを作りたい人、モバイルでSDKを使いたい人。全部を一冊の本に詰め込んだ結果、誰にも読みやすくなくなる。大きなプラットフォームでよくある失敗だが、Cognitoはその影響がかなり露骨に出ている。
Amplify v6のくだりは、単なる愚痴に見えて実はかなり重要だ。ライブラリのアップデートでUIフローごと作り直しになるのは、開発者にとって最悪のパターンだからだ。しかも認証は、ログイン、サインアップ、パスワード再設定、属性確認など、画面と状態遷移が多い。そこに破壊的変更が入ると、直す範囲は想像以上に広がる。筆者が「アップグレードではなくホールドアップだ」と言うのは大げさに聞こえるが、触る範囲の広さを思えば気持ちは分かる。
ここで見えてくるのは、クラウド基盤よりもSDKの安定性が実務で重い、という現実だ。バックエンドのサービスが多少強力でも、フロント側の接続層が頻繁に変わると、チームは常に追いかけ続けることになる。しかも認証はユーザー体験の入口なので、後回しにしづらい。移行ガイドがあっても、実際のコードベースに落とし込めなければ意味がない。つまり、仕様書の有無より「今の自分たちのコードが保守できるか」が問われる領域なのだと思う。
Hosted UIの不自由さも、かなり本質的な話を含んでいる。ブランドに合わせたい、独自の導線を作りたい、という要求はごく普通だ。それなのに許されるのがロゴ変更や軽いCSS調整だけなら、見た目の統一感はすぐ崩れる。結局、ちゃんとした体験を求めるならSDKを使って自前UIを組むことになる。そうなると、Hosted UIは「最低限すぐ動く」以上の価値をどこに置くのかが曖昧になる。
もちろん、すべてのプロダクトが凝った画面を必要とするわけではない。社内ツールや試作なら、Cognitoの既定UIで十分な場面もあるはずだ。けれど、スタートアップが認証を入れるときに欲しいのは、しばしば「今だけ動くもの」ではなく「あとで育てられるもの」だ。筆者の不満は、そこがうまく噛み合わなかった点にあるのだと思う。最初は速く見えても、結局は自前実装へ戻るなら、時間差で負債が来る。
筆者は最終的に、認証基盤を選ぶときは開発者体験を最優先にした方がいい、と言っている。無料枠やAWS内での統合しやすさは魅力だが、ドキュメントを読み解く時間、API変更への追従、ローカル検証のしにくさ、設定ミスを後から直せない苦しさまで含めると、かなり高くつく。これはCognitoに限らない話でもある。便利そうに見える基盤ほど、実際に手を入れる頻度が高い機能で摩擦が出たときの痛みは大きい。
筆者が面白いのは、結局Cognitoを捨てられていない点まで書いていることだ。すでに深く入り込んでいるので、今さら切り替えられない。だからこそ、これから選ぶ人には早めに試してほしい、と勧めている。特にカスタム属性、メール認証、パスワード再設定を含む小さなPoCを作れという助言は現実的だ。こういう機能は、デモではなく本番に近い形で触って初めて、相性の悪さが見える。認証は土台だからこそ後回しにされがちだが、後回しにしたぶんだけ、あとで一番高くつく。筆者の経験談は、そのことをかなり生々しく伝えていると思う。
参考: I Used AWS Cognito for a Startup. I Wouldn't Do It Again.
