JWTを使った認証・認可の仕組みから実装まで理解する
本記事では「JWTベースの認証・認可」という表現を使用しています。 認証（Authentication）：ユーザーの本人確認（ログイン時のID/パスワード検証） 認可（Authorization）：リソースへのアクセス権限の確認（JWTによる権限検証） JWTは主に認可の仕組みとして機能しますが、認証から認可までの一連のシステムを指して「JWTベースの認証・認可」と表現しています。 1.1 JWTの登場背景と従来の認証方式の課題 従来のWebアプリケーションでは、「セッション・Cookie認証」が認証方式の主流でした。これは、サーバー側でユーザーの認証状態をセッションとして管理する方式です。 セッション・Cookie認証の基本的な流れ ユーザーがログインすると、サーバーはセッションIDを発行します。 サーバーは、そのセッションIDとユーザー情報を紐付けて自身のストレージ（セッションストレー
SREの仕事をAI Agentに任せてみてお手なみ拝見
こうした領域の相当部分は「観察 → 判断 → アクション」であり、人間が実施すると非常に技術力と経験が求められ、各社 SRE を担当する方に業務が属人化するという現象が発生します。 ここで考えられているのが、AI Agent による支援・自動化と親和性が極めて高いということです。 AI Agent 活用の潮流と SRE 昨今の AI エージェントは、運用データ（メトリック／ログ／イベント）を LLM ベースで要約・推論し、自然言語で対話しながら修復アクションを提案・実行する方向に急速進化しています。Microsoft は Build 2025 で Azure SRE Agent を発表し、インシデント検出から診断、協働復旧に至るプロセスの高速化を狙うソリューションを提示しました。 この発表を見た筆者は、「これでトイルが減る」「SRE の仕事が変わる」「AI が SRE を全部やる時代？」と
LLM推論に関する技術メモ
はじめに BentoMLによるLLM Inference Handbookという、LLMの推論をまとめたハンドブックがある。本記事ではハンドブックや他の情報も参照しつつ、自分のメモ用としてLM推論に関する技術をまとめていく。 LLMの推論と内部理解の必要性 LLM推論とは、GPT-4、Llama 4、DeepSeek-V3などの学習済みLLMを使用して、ユーザーの入力から意味のある出力を生成することを指している。その推論には、たくさんの技術が抽象化・隠蔽されている。APIを利用している場合は、ほぼ意識せず活用できる。しかし、APIを何らかの理由で利用できない場合や、Open WeightなLLMを利用したい場合はこれらの技術を理解する必要がある。 実際、最適化されていない設定では、GPU時間で10倍のコストがかかることもある。ユーザー面であっても、最適化がされていなければ、応答速度が遅くな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
