#開発者体験

スタートアップで認証機能を組み込むとき、AWS Cognitoを選んだらどうなるのか。元記事は、その答えをかなり辛辣に書いた体験記だ。筆者は「AWSの中にあるから便利そう」「最初の50,000 MAUは無料」という理由で採用したものの、実際にはドキュメントの分かりにくさ、Amplify v6の破壊的変更、ローカル開発のしづらさ、Hosted UIの自由度の低さに次々と悩まされたという。単なる愚痴ではなく、認証基盤を選ぶときに何を重く見るべきかまで踏み込んでいるのが、この文章の面白いところだ。 筆者は、スタートアップの認証をAWS Cognitoで実装し始めてから3日ほどで違和感を覚えた。手順通りに進めているのに、パスワード再設定の画面が期待と違う場所へ飛んでしまう。ドキュメントを十二のタブで開き、コード例を写し、解説動画まで見たのに直らない。すでにAuth0やFirebase Auth、さらには自前のJWT実装まで触った経験がある筆者ですら、Cognitoは別物だったという。 不満の中心は、まずドキュメントにある。AWSの説明は、エンタープライズ向けの設計思想、フロントエンド開発者向け

こういう「サーバー側でこっそり変わっていた」という話、読んでいていちばん胃が痛い。アプリを疑って、コードを疑って、最後に自分の確認ミスを疑って……その時間が丸ごと無駄になるからだ。しかも今回は、モデルの“effort scale”みたいな、挙動の解釈に直結する部分が変えられている。数字の見た目だけでなく、実際の出力の感じ方までずれるなら、現場ではかなり厄介だと思う。 気になったのは、これがA/B testっぽいことより、変更の説明が changelog に出ていないらしい点だ。実験自体はよくあるし、全部を事前に公開しない判断もあるのかもしれない。でも、少なくとも開発者向けのプロダクトで、モデルの“high”が突然“low”相当に見えるなら、そこは黙っていてほしくない。とくにコード補助みたいな用途だと、出力の強さや慎重さの変化は、バグというより体験そのものの崩れ方をするので、ユーザーはかなり振り回されるはずだ。 それにしても、こういう話を見ていると、LLMの「安定している」という感覚がいかに壊れやすいかを思い知らされる。モデル名が同じでも、中身は平気で揺れる。その前提で使え、ということな

この記事を読んでまず思ったのは、「GA まで来たのに、使いたい人がすぐ使えないのはもったいない」ということだった。しかも原因が Claude や ChatGPT 側ではなく、Microsoft の Entra 側にあるというのが少しややこしい。ユーザーから見ると“対応しているようで未対応”に見えるので、これはかなり印象が悪い。 ただ、引っかかるのはその不便さだけではない。むしろ面白いのは、MCP みたいな共通規格が広がっても、最後に残るのは identity の問題なんだな、という点だった。ツールの呼び出し方は揃えられても、「そのクライアントを誰として認証させるか」は別問題で、そこを各社が自前で抱えている。今回の話は、その分断がかなり露骨に出た例だと思う。 Microsoft の立場から見ると、Entra 経由で権限をそのまま渡せるのは確かに筋がいい。PAT を config に置くよりは事故りにくいし、開発者の権限だけを引き継ぐ、という説明にも納得感はある。けれど、その“安全な設計”が、結果として Claude Code や Cursor みたいな外部エージェントを締め出しているのは