境界を溶かし、制御を手元に集める：直近の技術動向が描く開発の新たな重心

VS CodeからGoogle CloudのJupyter環境へ直結する拡張機能登場

Google Cloud Workbench Notebooks Extension for VS Codeがリリースされた。ローカルのVS Codeから、Google Cloud上で動くマネージドJupyter環境に直接つなげる拡張機能だ。

これまでのML開発で嫌だったのが、コンテキストスイッチの多さ。ブラウザでJupyterを開いて実験し、結果をローカルのエディタに持ち帰ってモジュール化する。この往復が、地味に開発のリズムを削ぐ。新しい拡張機能は、この切り替えをなくす方向に進んでいる。

使い方はシンプルだ。VS Code Marketplaceからインストールし、Google Cloudの認証を通す。あとは.ipynbファイルを開き、プロジェクトを選んでリモートのWorkbenchインスタンスを指定するだけ。リモートカーネルがJupyterのカーネルピッカーにローカルと同じように表示される。インスタンスの新規作成もIDE内で完結する。Jupyter拡張機能の上に構築されているため、既存のUIの枠組みを活かしている点は上手い。

Google Cloud Workbench Notebooks自体は、Googleが管理するJupyter環境。セットアップやアップデートは任せ切りで、ML用のライブラリも事前インストール済み。BigQueryやVertex AI、Cloud Storageとの連携も組み込まれている。インフラを触りたくないデータサイエンティストには好まれる構成だ。

ワークフローがどう変わるか。ローカルマシンのリソースが足りなくなったら、カーネルピッカーでクラウド側のインスタンスを選ぶだけ。コードやデータはそのまま。GPUが載ったインスタンスへの切り替えも数クリックで済むなら、実験のサイクルは確かに速くなる。ただ、実際の切り替えがどの程度シームレスなのか。ネットワーク遅延やインスタンスの起動時間がどれだけストレスになるかは、使ってみないと分からない。

競合も動いている。DatabricksやDeepNote、Kaggle Notebooksがインタラクティブな実行環境として存在するし、Amazon SageMakerやAzure Machine LearningはMLライフサイクル全体をカバーする。SageMakerはノートブックだけでなく前処理からデプロイ、モニタリングまで含むため、大規模な本番運用には向くが、シンプルさでは勝負にならない。Googleの狙いは、VS Codeという開発者のホームグラウンドを離れずにクラウドの計算資源を使える点にある。

拡張機能はオープンソースで公開されている。細かい挙動やバグはGitHubで追える。自分がKubernetes上で推論基盤を構築する際、実験段階でローカルとクラウドの往復にどれだけ時間を取られたかを思い出す。この拡張機能がその摩擦を減らすなら、MLに関わるチームの生産性は変わるはずだ。

AIエージェントの認可をKeycloakで支える試み

2026年7月28日、横浜でKeycloakCon Japan 2026が開かれる。KubeCon + CloudNativeCon Japan 2026の併設イベントで、09:00から12:30までの半日コース。気になるのは、自律型AIエージェントのアイデンティティガバナンスがメインテーマに据えられている点だ。

AIエージェントがユーザーの代わりに下流のAPIを叩く。ここで従来の認可の境界が崩れる。いわゆる「Confused Deputy」問題だ。

（※Confused Deputy：権限を持つプログラムが、不適切な入力を受けたことで、意図せず特権を悪用して操作を行ってしまう脆弱性のこと）エージェントが持つ権限と、背後にいるユーザーの意図が食い違うとき、意図しないリソースへのアクセスが起こり得る。MCP（Model Context Protocol）が普及し始めると、この問題は避けて通れない。

（※MCP：AIモデルが外部データソースやツールと標準化された方法で通信するためのオープンプロトコル）

KeycloakConでは、この解決策としてOAuth 2.0のトークン委譲やトークン交換、きめ細かいスコープ強制をすでにKeycloakが持っていると主張している。専用のAIアイデンティティベンダーは不要だというわけだ。HitachiのYutaka ObuchiとLY CorporationのTatsuya Yanoは、ID-JAG（Identity Assertion JWT Authorization Grants）の実装を披露する。KeycloakのToken Exchange Providerを拡張し、MCPサーバーから認可を外部化する構成だ。LINEやYahoo! JAPANのインフラで実績のあるCNCF AthenzとKeycloakを統合し、Confused Deputyを防ぐという。

さらに面白いのは、Kubernetes上でキーレスのMCPワークロードアイデンティティを実現する試みだ。TUBITAKのMustafa Dayıoğluが、SPIREでランタイムアイデンティティ（JWT-SVIDs）を付与し、DPoPでトークンリプレイをブロックするパターンを紹介する。

（※DPoP: Demonstrating Proof-of-Possession。トークンに公開鍵暗号を紐付け、盗まれたトークンを別のクライアントで再利用することを防ぐ仕組み）静的クレデンシャルファイルがゼロ、人間が作成したKeycloakクライアントもゼロ。マイクロサービス間のmTLSをSPIFFE/SPIREでやっているチームなら、この延長線上にAIエージェントのアイデンティティがあると読める。

（※SPIFFE/SPIRE：動的な環境でワークロードに検証可能なアイデンティティを付与し、相互TLS認証を実現するオープンソース標準）

AIの話だけでなく、CI/CDパイプラインの署名も扱っている。Sigstoreのキーレス署名フローにKeycloakをOIDCプロバイダーとして直接接続するデモがある。ビルドの署名を人間のアイデンティティに暗号的に紐付ける。長時間の自動ビルドでトークンが切れたときの扱いまで触れるという。自分でパイプラインを組んでいる身としては、ここは実務に直結する。

サービスメッシュの話もある。Keycloak Authorization Servicesをプラットフォーム制御プレーンとして使い、Istio AmbientモードのウェイポイントプロキシとWASM拡張でサービス間HTTPリクエストを評価する。アプリコードを変えずに認可を注入できるか。レイテンシと信頼性のトレードオフも分析されるという。認可をサイドカーから外に出してプラットフォームレイヤーでやる話は、Ambientの文脈で現実味を帯びてきている。

最後に、地味だが運用上見過ごせないのが証明書の話。2010年代後半にKeycloakを導入した組織は、組み込みのrealm署名証明書の10年有効期限にぶつかっている。OIDC/SAMLが混在する環境でのグローバルな鍵ローテーションは極めてリスクが高い。野村総合研究所のHiroyuki Wadaが、クライアントごとの署名鍵選択という上流の解決策を紹介する。移行をクライアント単位でリスクなく進められるなら、運用の肩がかなり軽くなるはずだ。

AIエージェントの認可、パイプラインの署名、サービスメッシュの認可、そして証明書の運用。どれも「アイデンティティをどこに置くか」という共通の問いに収束している。Keycloakがその答えをどこまで出せるのか。7月28日のセッション次第だ。

Codexが800万ユーザーに急増、GPT-5.6統合で何が起きたか

OpenAIがGPT-5.6をリリースし、CodexをChatGPTデスクトップアプリに統合した。その結果が凄まじい。2月には週間アクティブユーザーが100万未満だったCodexが、6月初旬には500万に到達。7月9日のGPT-5.6リリース後はさらに加速し、7月12日に600万、その約24時間後に700万、日曜には800万に達した。5ヶ月でこの成長曲線は、大半のエンタープライズSaaSが一生かかっても見られない数字だ。

当然ながらインフラは悲鳴を上げた。トラフィックは過去のピークの約2倍に急増。OpenAIのCodexエンジニアリングリードであるTibo Sottiauxが詳細な対応スレッドを公開している。推論の最適化で加入者あたりの容量を約10%増やし、コンテキストウィンドウを372,000トークンから272,000トークンに削減した。372,000トークンの上限が意図しない課金問題を引き起こしていたためだ。内部的に"juice"値と呼ばれる実験的な推論努力設定をロールバックし、最高推論レベルでのマルチエージェントの攻撃的な挙動もパッチで修正。Plus、Business、Pro向けの5時間使用制限は一時的に撤廃されている。

コンテキストウィンドウの削減は「ステルス的なダウングレード」と受け取る向きもあった。ただ、Sottiauxが運用上のトレードオフを公開して説明した点は評価できるだろう。

競合の動きも早い。OpenAIが700万ユーザー達成を発表して数時間以内に、AnthropicはClaude Fable 5のプロモ価格を7月19日まで延長し、Claude Codeの週間利用制限を50%増加させた。因果関係は不明だが、タイミングとして興味深い。

開発者にとっての論点はどこにあるか。一つは利用制限の共有問題だ。CodexとChatGPT Workが単一の週間プールを共有している。Sol Ultraでマルチエージェントオーケストレーションを重いセッションで回せば、あっという間に枠を使い切る。Sottiauxもこの問題を認識しており、修正に取り組んでいると述べている。

もう一つはコストパフォーマンスの見方だ。CognitionのDevin Fusion（Fable 5搭載）は、AnthropicのOpus 4.8よりタスク完了単価が安いと報告されている。Fable主導のランの81%で、リードモデルはコードを編集していない。委任がうまく機能している。高いモデルを使っても、無駄な作業を減らせれば全体のコストは下がるというわけだ。

そしてハーネスがプロダクトになりつつあること。Codex、ChatGPT Work、内蔵ブラウザを単一のデスクトップアプリに統合し、SlackやGoogle Drive、SharePoint、CRM、カレンダーと連携するプラグインアーキテクチャを備える。AnthropicもClaude Coworkで似た方向に動いている。AIコーディングツールが、単なるコード生成からワークスペースへとシフトしている。データ制御を重視するなら、GLM 5.2やKimi K2.7を載せたオープンソーススタックも有力な選択肢になるだろう。

AWS Security HubがAzureを監視対象に、マルチクラウド安保の選択肢が動く

AWSがSecurity HubのAzureリソース監視を開始した。火曜日の発表による。Security HubがAWS以外のクラウドをネイティブに監視するのは初めて。自動検出の対象はAzureの仮想マシン、コンテナイメージ、サーバレスのFunction Apps、そしてアイデンティティ。CIS Azure Foundations Benchmarkを使って設定ミスやインターネット露出、脆弱性をチェックし、その結果はAWSの検出結果と同じ優先度付きキューに並ぶ。既存の自動化ワークフローをそのまま流せる。

気になるのは料金体系。Azureリソースの監視コストはAWSと同等で、プラットフォームフィーは乗らない。30日間の無料トライアルも別途用意されている。AWS側に乗せるだけでマルチクラウドのセキュリティ可視化が手に入る設計だ。

同時にAIワークロード保護も大きく動いた。GuardDuty AI ProtectionはAmazon BedrockとSageMakerに特化しており、異常なモデル呼び出しやプロンプトインジェクション、そして「コストハーベスティング」を検知する。盗まれたクレデンシャルで他人のアカウントで推論料金を稼ぐ手口だ。AWSのMichael Fuller氏が実際に聞いた例として、数千回のモデル呼び出しに気づいたのが経理部門の請求フラグだったケースを挙げている。インフラチームではなく財務が異常に気づく。そのぐらい見えにくい攻撃ベクトルということか。

AI-powered investigationsはプレビュー段階で、GuardDutyの検出結果に対して自動で一次調査を実行する。脅威とノイズを仕分け、信頼度スコアとMITRE ATT&CK分類、修復推奨を返す。関連する過去90日間のアクティビティを分析し、「数時間かかっていた作業を数分に」とAWSは主張している。Security HubのEssentialsプランに含まれるAIインベントリは、BedrockやSageMaker、AgentCoreといったマネージドサービスから、EC2やECS、EKS上の自前モデル、外部API呼び出しまで組織内のAI資産をカタログ化する。インフラとの紐付けやGuardDuty検出結果との関連付けも可能だ。

競争は激しい。Microsoft Defender for Cloudは2021年後半からAWSを、2022年初頭からGoogle Cloudを監視対象にしている。Googleは320億ドルでWizを買収し、3大手クラウドを横断するプラットフォームを手に入れた。AWSのSecurity HubによるAzure対応は、この流れへの対抗と読める。ただし現時点で監視できるのはAzureのみ。Google Cloudへの対応予定については触れられていない。

マルチクラウドのセキュリティを単一コンソール・単一請求でまとめたいチームにとっては、選択肢が一つ増えた。ただ「マルチクラウド」がとりあえずAzureだけである限り、本気度の判定材料としては不十分だ。

Kubernetes公式がカスタムメトリクスエクスポーターの作り方を解説——HPAをビジネス指標で動かす

Kubernetes公式ブログで「Building a Custom Metrics Exporter for Kubernetes」という記事が公開された。GoのPrometheusクライアントライブラリを使い、カスタムメトリクスエクスポーターをスクラッチから作るチュートリアルだ。

なぜこれが重要か。HorizontalPodAutoscaler（HPA）はデフォルトでCPUとメモリしか見ない。しかし実務でスケーリングの判断材料になるのは、キューの滞留数、バッチジョブの処理時間、Podが保持しているWebSocket接続数といった、アプリケーション固有の信号であることが多い。組み込みメトリクスだけではカバーしきれない。そこでカスタムメトリクスエクスポーターが橋渡しをする。

記事では、エクスポーターを「/metricsエンドポイントを公開する小さなHTTPサーバー」として定義している。Prometheusが定期的にスクレイプし、時系列データとして保存。それをHPAが参照する流れだ。

実装の選択肢として、アプリケーションに直接Prometheusクライアントを組み込む方法と、独立したエクスポーターを立てる方法がある。後者が適しているのは、データソースがアプリケーション外部にある場合や、アプリケーションコードを制御できない場合だ。自チームのサービスなら直接組み込めばいいし、外部のRDBやメッセージブローカーのメトリクスを取りたいなら独立エクスポーターになる。この判断はアーキテクチャ設計の段階で決めておきたい。

メトリクスの型選びも重要。Counterは増加のみの合計値に、Gaugeは増減する現在値に、Histogramはレイテンシのような分布を観測する値に使う。型を間違えると、あとでp99を取りたくても取れない事態になりかねない。命名規則は<namespace>_<name>_<unit>のsnake_case。たとえばworker_jobs_processed_total（Counter）、worker_queue_depth（Gauge）、worker_job_duration_seconds（Histogram）のように。デバッグの時間を削るなら、ここを雑にしない。

GoのPrometheusクライアントが選ばれているのは、Kubernetesの公式コンポーネントの多くが同じライブラリを使っているからだろう。エコシステムとの親和性を考えれば自然な選択だ。

一つ気になるのがprometheus.MustRegisterの挙動。重複登録時にパニックを起こす。起動時に設定ミスが発覚するのは悪くない。ただし、他のパッケージも計装するライブラリに組み込む場合は、prometheus.Registerでエラーハンドリングしたほうが安全かもしれない。

ポーリングループで値を更新するパターンも紹介されている。goroutineで定期的にデータソースを読み、メトリクスを更新する。シミュレート値を実際のデータベースやメッセージブローカーの呼び出しに置き換える前提だ。

HPAをビジネス指標で回すなら、カスタムメトリクスは避けて通れない。この記事は、その第一歩を踏み出すための実装の指針を示している。

まとめ

ローカルとクラウド、人間とエージェント、AWSとAzure、インフラとビジネス指標。これまで境界で区切られていた領域を、開発者の制御点で一本化しようとする動きが直近の各話題に通っている。VS CodeからGoogle CloudのJupyter環境へ直結する拡張機能も、Codexが各種SaaSと連携する単一のワークスペースへと変化しているのも、開発のホームグラウンドに制御を集めようとしている。

アイデンティティとセキュリティの領域でも同様の統合が起きている。AIエージェントがユーザーの代わりにAPIを叩く際の認可を、Keycloakの既存の枠組みで外部化し制御する試み。AWS Security HubがAzureリソースを監視対象に加え、マルチクラウドのセキュリティを単一コンソールで握ろうとする動き。プラットフォームの壁を越えて、制御の中心を一つに据えようとしている。

Kubernetesのカスタムメトリクスエクスポーターの解説に至っては、インフラの自動スケーリングという制御を、プラットフォームデフォルトのCPUやメモリから、ビジネスの文脈にある指標へと直接結びつける。プラットフォームが提供する境界を越えて、自分たちの文脈でシステムを動かすための工夫だ。

境界を溶かすことは摩擦も生む。Codexの急増がインフラを悲鳴上げさせ、コンテキストウィンドウの削減というトレードオフを生んだこと。Security Hubによるマルチクラウド監視が、現時点ではAzureのみに留まっていること。それでも、別々の画面や異なる文脈を行き来する開発の摩擦を減らし、制御を手元に集めたいという要求は明確だ。どこで制御を握るか。これからツールやインフラの設計で、より問われることになるだろう。

参照記事

記録日: 2026-07-15