2025年8月上旬から9月上旬にかけて、AnthropicのAI「Claude」の応答品質が低下したという報告が相次ぎました。Anthropicが調査したところ、3つのインフラストラクチャー上のバグが原因だったことが明らかになりました。
⇧ まぁ、「ソフトウェア開発」の特性上、バグが発生するのは致し方ないとは思うのだが、
Anthropicは、こうしたバグの検出が困難だった理由として、自社のプライバシー対策が理由の1つだったと指摘しています。
プライバシー対策により、エンジニアはユーザーとClaudeのやり取りを見る方法が限られており、特にフィードバックとして報告されていないやり取りへのアクセスは制限されるからです。
また、Claudeは複数のハードウェアプラットフォームに分散して配置しているため、インフラが複雑で、あるユーザーには不具合が生じているのに別のユーザーには生じていないといった状況も混乱を招きました。
今後の対策として、Anthropicは正常な動作と不具合のある動作をもっと正確に区別できる評価手法を開発したほか、ユーザーのプライバシーを損なうことなく効率的にデバッグするインフラとツールを開発すると報告しています。
⇧ 何と言うか、「サーバーサイド」側にユーザーからのリクエストが届いているのなら、ログが残るようにしておけば良い気はする。
何となくだが、
- エラーハンドリングの設計
- エラーメッセージの設計
- ログの設計
- 監視・アラートの設計
のような「横断的関心事」に関する要件や、「保守・運用」面が考慮されていない気がしますかね...
Auth0で1つのApplicationに複数のDatabaseを紐付けるマルチテナント方式を実現できるっぽい
前回、
⇧ 上記の記事の時に、
Making Sense of Single-Tenancy vs. Multi-Tenancy
⇧ という公式のブログ記事の図があったので、てっきり、
という関係しか実現できないものと思っていたのだが、
Why Use Organizations?
When you use Auth0 to secure your application, you set up an Auth0 tenant to isolate the resources and the users dedicated to it. That's pretty fine when your userbase does not need any further structuring. Assume you need to further isolate groups of users, i.e., you want to create groups of users that can access your application with different authentication options, different sets of roles, or different branding.
https://auth0.com/blog/auth0-organizations-for-b2b-saas-blazor-web-apps/
This is a typical scenario for B2B SaaS, where you provide access to your application to your business customers. Your business customers have their own users, which need to be isolated for security and customization reasons while still using the same application.
https://auth0.com/blog/auth0-organizations-for-b2b-saas-blazor-web-apps/
This is where Auth0 Organizations can help you!
https://auth0.com/blog/auth0-organizations-for-b2b-saas-blazor-web-apps/
At a high level, see Auth0 Organizations a way to structure groups of users within an Auth0 tenant, as illustrated by the following diagram:
https://auth0.com/blog/auth0-organizations-for-b2b-saas-blazor-web-apps/
⇧ とあるように、「Auth0 Organizations」という機能を利用すれば、
が実現できて、「顧客」毎に「Auth0」の「Database」が分離できる、所謂「マルチテナント」方式を、「Auth0」の「Application」が1つの状態で実現できるらしい。
厳密には、「顧客」の「組織」毎の分離を想定しているようなので、「顧客」毎ではないと思われるので「マルチテナント」とは言わないのかもしれないが...
しかしながら、一般的な基盤システムとかだと、「顧客」毎に「データベース」を分離する「マルチテナント」方式がメジャーな気がするので、「Auth0」の設計に違和感を感じてしまうのよな...
とりあえず、「Auth0」の公式のブログ記事ではなく、公式のドキュメントで整理して欲しいのだが...
「ファインダビリティ（Findability）」が酷過ぎるんだが...
ちなみに、
ユニバーサルログインを使う場合はOrganizationsを使うのが自然だと思います。
また、Organizationsは契約しているSubscription次第では使えません。
[Auth0] 1つのApplicationから2つの異なるDatabaseに繋いで認証させる方法 | DevelopersIO
⇧ 上記サイト様によりますと「Auth0」のプラン次第では、「Organizations」が利用できないらしい...
「ユニバーサルログイン」はというと、
Auth0には、2種類のホストされたログインエクスペリエンスが用意されています。
-
ユニバーサルログインでは、ユーザー向けに効率化されたエクスペリエンスを受けることができ、カスタマイズにJavaScriptを使用する必要はありません。
-
クラシックログインでは、ログインフローの各ページにJavaScript制御を使用します。
現時点では、Auth0の開発作業は主にユニバーサルログインに焦点を当てており、クラシックログインは更新されなくなりました。特定のユースケースでクラシックエクスペリエンスが必要でない限り、ユニバーサルログインの実装をお勧めします。
https://auth0.com/docs/ja-jp/authenticate/login/auth0-universal-login
これら2つのエクスペリエンスの比較方法については、「ユニバーサルログインとクラシックログイン」をお読みください。
https://auth0.com/docs/ja-jp/authenticate/login/auth0-universal-login
⇧ とあり、「Auth0」としては、「ユニバーサルログイン」の利用を推奨しているらしい。
で、
⇧ 上記によると、「ACUL（Advanced Customization for Universal Login）」なるものが用意されているっぽいので、
『ユニバーサルログインでは、ユーザー向けに効率化されたエクスペリエンスを受けることができ、カスタマイズにJavaScriptを使用する必要はありません。』
の説明は何だったのか、というお気持ち...
兎にも角にも、「Auth0」の設計の思想が「ブラックボックス」過ぎるのよね...
開発している「ソフトウェア」で「Auth0」が導入されているケースで、他チームが「Auth0」の環境を構築している場合、設計が存在しないと、「Auth0」のどの機能を利用しているのかの見極めが困難なのですな...
他「サービス」を導入することで、開発している「ソフトウェア」の「機能」の一部を他「サービス」に委譲するのは問題ないのだが、設計は残しておいて欲しいお気持ち...
つまり、開発している「ソフトウェア」としての「アーキテクチャ意思決定記録（ADR：Architecture Decision Record）」で、他「サービス」（今回だと「Auth0」）で提供されている様々な「機能」内のどれを採用したのかについてを残しておいて欲しい...
一次情報のドキュメントの該当のURLを載せておいてくれるだけでも、膨大なドキュメントの中から該当のページを検索する不毛な作業をしなくても済むのでね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
