#azure

Microsoft AzureのLogic AppsにあるAPI Connectionsについて、またひとつ深刻な脆弱性の話が出てきました。しかもこれは単発の欠陥ではなく、同じ設計の弱さから何度も別の抜け道が見つかった、という筋書きです。元記事の著者は、最終的に5件のcriticalな権限昇格脆弱性を報告し、合計で20万ドルを得たと書いています。単なるバグ報告ではなく、クラウドの“つなぎ方”そのものがどれだけ危ういかを示す話として読むべきだと思います。 元記事の中心は、Azure Logic AppsのAPI Connectionsがどう動いているかです。Logic Appからの呼び出しは、共有のAzure API Management（APIM）を経由し、そこでOpenAPI定義を確認したうえで、接続先サービス向けの認証情報に“交換”されてからバックエンドへ届く、と説明されています。つまり、見かけ上はLogic AppがAPIを呼んでいるようでも、実際にはAPI Connectionに設定されたトークンやキーでKey VaultやAzure SQL、さらにはJiraやSalesfor

読んでいてまず思ったのは、「RAG を自前で全部持つの、やっぱり重いよな」ということでした。ベクトル化して、検索して、再ランキングして、権限も見て、さらにエージェント用の制御まで入れる。この記事はそこを Foundry IQ 側に寄せて、LangGraph は orchestration に集中させる、という割り切りをかなりはっきり示しています。こういう分担はきれいですし、運用のたびに同じ部品を各エージェントへ複製する苦さも減りそうです。 ただ、読んでいて面白かったのは、「MCP でつながる」と言っても、単にツールを呼べば終わりではないところです。token refresh が必要で、ユーザー権限も別トークンで渡し、しかも knowledge base 自体が planner でもある。つまり、エージェントが planner を持つのに、検索基盤側もすでにある程度 “考える” ので、誰がどこまで考えるかを決めないと、挙動が見えにくくなる。ここは実装の華やかさより、設計の面倒さが前に出ていて、かなり実務っぽいと感じました。 あと、knowledge base の description

最初に思ったのは、「ようやくここまで来たか」というより、「ここまで一つの入口に寄せるなら、責任の境界もかなりはっきりさせないと怖いな」という感覚でした。 モデル、MCP server、tool をまとめて gateway で扱うのは確かに気持ちがいいです。アプリごとにバラバラに持つより、運用も監査も楽になるはずだし、rate limit や spend control を後から継ぎ足す苦労も減りそうです。 ただ、読んでいて一番引っかかったのは、そこが「便利な共通基盤」になるほど、どこまでを gateway が見て、どこからを orchestration layer が見るのかが曖昧になりやすいことでした。 記事でも、agent の run がきれいに終わらなかったときに出力をどう残すのか、再試行を誰が責任持つのか、という疑問が出ていましたが、これはかなり本質的だと思います。単にトラフィックをさばく箱なのか、それとも AI の実行そのものを統治する層なのかで、設計思想が全然違うからです。 もう一つ、runtime access key が gateway 全体に効く、という話も気になりま

MicrosoftとAnthropicが、`Claude in Microsoft Foundry` の一般提供を発表しました。 ひとことで言うと、AzureやEntra IDで管理している企業が、そのままClaudeを業務に組み込みやすくなったという話です。 AIモデルは「性能がいい」だけでは足りません。実際の企業利用では、誰が使えるのか、課金はどうするのか、監査やガバナンスをどう効かせるのか、そこが面倒なんです。今回の発表は、その面倒ごとをMicrosoft側の仕組みに寄せながら、AnthropicのClaudeを使えるようにした点がかなり大きいと思います。 `Claude in Microsoft Foundry` が一般提供になった Azure/Entra ID/RBACなど、Microsoftの企業向け管理機能と合わせて使える Claudeは `Hosted on Azure` と `Hosted on Anthropic` の2系統がある 今回の本命はAzure上で動く `Hosted on Azure` NVIDIAの `Blackwell Ultra (GB30