#認証

1Passwordが、Claude向けの新しいブラウザー連携を出しました。これが何を変えるのかというと、AIエージェントがログイン作業を手伝えるのに、パスワードそのものは見なくて済むようになる点です。 地味に見えますが、これはかなり大きい。 AIに「このサイトに入って、あの作業をして」と頼むとき、いちばん怖いのは“中身を全部見せること”でした。パスワードや認証情報は、AIに渡した瞬間から扱いが難しくなる。そこを1Passwordは、端末上で復号し、作業ごとにユーザーの許可を挟むという形で解こうとしています。 ClaudeのAIエージェントが、1Passwordの認証情報を使ってWeb操作できる ただし、パスワード自体はAIに見せない設計 復号は端末側で行うため、認証情報がむやみに外へ出にくい 操作のたびにユーザー承認を求めるので、勝手に進む感じではない いわゆる「AIに権限を渡す」問題に対する、かなり実務寄りの答えに見える この記事で面白いのは、単なる便利機能の話ではなく、AI時代の「ログイン」をどう安全に扱うかという、かなり面倒で重要な問題に踏み込んで

MCP（Model Context Protocol）は、AIエージェントが外部ツールや社内システムにつながるための“共通のつなぎ方”みたいなものです。ローカルで試すだけなら、`python server.py` の一発で動くこともあります。でも、企業で本番運用するとなると話は別。元記事は、そのギャップをかなり実務的に埋めにいく内容でした。 正直、こういう記事は地味に見えて、あとで効いてくる話が多いです。認証が甘いと危ないし、止まったら困るし、アップデートで既存接続を切るのもまずい。AIまわりの話は派手なデモが目立ちますが、現場ではむしろこの“つまらないけど重要な部分”が本体だと思います。 ローカルで動くMCP Serverと、本番運用のMCP Serverでは考えるべきことがまるで違う 本番ではまず「認証」「監視と再起動」「安全なアップグレード」の3点が大事 認証は用途で使い分けるのが現実的 - 社内向けなら API Key - ユーザーごとの権限が必要なら OAuth 2.0 - 厳しい規制がある業界では mTLS Dockerでは `restart`、`internal: tru

Model Context Protocol（MCP）の世界で、かなり実務的で、しかも地味に効くアップデートが正式版になりました。 その名も Enterprise-Managed Authorization（EMA）。ざっくり言うと、「社内のID管理基盤でMCPサーバーへのアクセスをまとめて管理できる仕組み」です。 MCPは、AIアシスタントや開発ツールが外部サービスとつながるための共通規格として広がってきました。ただ、企業で使うとなると、思った以上に面倒が多い。サーバーごとにOAuthの許可画面が出て、社員が一人ずつポチポチ承認していく。これ、個人利用ならまだしも、組織運用だとかなりしんどいです。今回のEMAは、その“しんどさ”をかなり正面から潰しにいっています。 Enterprise-Managed Authorization（EMA）がstableになった 企業はIdP（Identity Provider）でMCPサーバーへのアクセスを一元管理できる ユーザーは初回ログイン時に自動で接続され、サーバーごとのOAuth許可が不要になる アクセス制御は

Cloudflareが、AIエージェント向けに Temporary Cloudflare Accounts を提供し始めました。ざっくり言うと、AIが「コードを書いたあと、すぐにデプロイまで進みたい」ときに、人間向けの面倒な登録作業を飛ばせる仕組みです。 これ、地味に見えてかなり大きいです。AIはコードを書くのは得意でも、そのあとに出てくる「ブラウザでログインして」「OAuthを通して」「API tokenをコピペして」「2段階認証を入れて」みたいな壁で止まりがちでした。Cloudflareはその壁を、かなり正面から壊しにきた、という印象です。 AIエージェントが、Cloudflareにすぐデプロイできるようになった `wrangler deploy --temporary` で、60分だけ使える仮アカウントを作れる その場でデプロイして、結果を確認し、何度でも修正できる 気に入ったら、あとからその仮アカウントを自分の正式なアカウントとして引き取れる 何もしなければ60分で自動削除される CloudflareはStripeやWorkOSとも組んで、エージェントの「登録の面倒」を

Cloudflareが、self-managed OAuth をすべての開発者に開放しました。 これ、地味に見えてかなり大きなニュースです。というのも、OAuthは「外部アプリに、どこまで何を許可するか」を安全に扱うための仕組みで、SaaS連携や社内ツール、いま流行りのagentic toolまで、あちこちで土台になっているからです。 Cloudflareは自社のAPIを使って自動化やCI/CD、各種連携を作れる強いプラットフォームですが、これまでは第三者向けのOAuthは一部の手動オンボーディング済み統合に限られていました。 つまり、誰でも自由に「Cloudflare用のOAuthアプリ」を作れる状態ではなかったわけです。 その制限が外れた。ここが本題です。 CloudflareのOAuthが、限られた提携先だけでなくすべての開発者に開放された API token中心の運用よりも、権限を細かく分けやすく、取り消しもしやすい その裏側では、OAuthエンジンの大規模アップグレードをかなり慎重にやっていた データベース移行は派手。1億件超の更新・挿入が走っ

VS Code を起動するたびに `The extension 'GitHub Pull Requests' wants you to sign in again using GitHub.` という通知が繰り返し出る——このループに悩まされているエンジニアは多い。結論から言うと、これは利用者側の設定ミスではなく GitHub 系拡張のトークン失効ハンドリングのバグ で、公式 issue でも認知されている挙動だ。本稿では症状の原理と、効果が高い順の回避策を整理する。 > ⚠️ 注記: 拡張側の修正で挙動が変わる可能性がある。下記はあくまで「再発したらその都度リセットする」対症療法。VS Code 本体・拡張ともに最新へ更新しておくのが前提。 症状: VS Code 起動のたびに GitHub への再サインインを延々と求められる 原因: 共有認証トークンが無効化された際、GitHub 系拡張がそれをうまく検知できず、古いトークンを掴み続ける（公式に確認済みのバグ挙動） 第一手: 左下アカウントから **サインアウト → `Cmd + Q` で完全