#oauth

このエラーが出るのは、Claude Code が OAuth 認証で進もうとして、所属組織側でそれが許可されていないときです。少なくとも issue の報告では、`Your organization has disabled Claude subscription access for Claude Code` という案内とあわせて `OAuth authentication is currently not allowed for this organization.` が返っています。該当する報告は [#63685](https://github.com/anthropics/claude-code/issues/63685) と [#63886](https://github.com/anthropics/claude-code/issues/63886) です。 まず見分けたいのは、自分が「個人の Pro 契約を持っているのに弾かれている」のか、それとも本当に組織管理下のアカウントとして扱われているのか、です。[#63886](https://github.com/anthro

Claude Code を使っていて `401` の `authentication_error` が急に出るなら、少なくとも今回集まっている報告では「認証が壊れた」というより、セッション中に OAuth token の期限切れや再認証が必要になっているケースが中心でした。 ただし、同じ `authentication_error` でも issue は 2 系統あります。 ひとつは、[#18225](https://github.com/anthropics/claude-code/issues/18225) のように、長く使っていたセッションで突然 401 が出始め、`/login` を何度も求められるパターンです。報告者は「months 使っていて、today から始まった」と書いています。エラーメッセージは次のとおりです。 ```text API Error: 401 {"type":"error","error":{"type":"authentication_error","message":"OAuth token has expired. Please

MCP（Model Context Protocol）は、AIエージェントが外部のツールやファイル、サービスにアクセスするための共通ルールだ。ざっくり言うと、「AIに何をどう頼むか」を標準化するための通信規格である。 今回の元記事が面白いのは、単なる機能追加の話ではなく、MCPの骨格そのものが変わったと指摘しているところだ。いちばん大きいのは、これまで前提だった「セッションを持ち続ける」方式をやめたこと。これでMCPは、かなりHTTPらしい、軽くて扱いやすい形に寄ってきた。 2026-07-28仕様で、MCPはセッション前提の stateful な設計をやめた これにより、sticky session や共有Redisのような面倒な運用が減る OAuth / OIDC の安全性が強化された tool list や prompt list などにキャッシュ期限を持たせられるようになった Tasks は正式な extension として整理され、長い処理を扱いやすくなった 主要SDKはすでに対応しており、MCPはかなり大規模に使われている 元記事の中心はここ

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

For Claude and Claude Code developers, this is a big deal because it tackles one of the least glamorous but most painful parts of real-world AI tooling: auth. If you’ve ever watched an enterprise deployment get bogged down by repeated consent prompts, inconsistent access rules, or awkward personal-vs-work account boundaries, this announcement is aimed straight at that mess. The Model Context Protocol’s Enterprise-Managed Authorization (EMA) extension is now stable. EMA lets organizations central

「送信」を押したのにメールが送信トレイ（Outbox）に居座ったまま動かない——この古典的なトラブルは、2026年現在も現場で最も多いメール障害のひとつだ。ただし原因の比重は1年前から大きく変わった。従来の「オフライン設定」「大容量添付」「ポートブロック」に加えて、2025〜2026年はプラットフォーム側の構造変化が新たな送信不能要因として浮上している。 本稿はエンジニア／情シス担当者の視点で、(1) まず切り分けるべき診断フロー、(2) 2026年特有の2大変化、(3) 恒久対策、の順に整理する。 --- 2026年のトラブルシュートで最初に確認すべきはどのOutlookを使っているかだ。両者は送信処理のアーキテクチャがまったく異なる。 classic Outlook（従来のデスクトップ版） — ローカルに `.ost`/`.pst` を持ち、送信トレイ → 送信処理 → 送信済みという明示的なキューを経由する。「送信トレイに残る」のはこちら特有の症状。 新しいOutlook（new Outlook for Windows） — 実体は