Tech News JP

MicrosoftがEdgeブラウザからXSLT（Extensible Stylesheet Language Transformations）のサポートを削除することを明らかにした。XSLT は XML 文書を HTML やテキストなど別形式に変換するための技術で、2000年代に多くの企業システムで採用されていた。長年にわたってEdgeに組み込まれてきた機能だが、いよいよそのサポートに終止符が打たれようとしている。 XSLTとは何か、なぜ今まで残っていたのか XSLT は W3C が策定した XML 変換仕様で、サーバーサイドで生成した XML データをブラウザ上でスタイルシート（.xsl ファイル）を使って HTML に変換する、という仕組みだ。2000年代初頭には「コンテンツとプレゼンテーションの分離」を実現する有力な手段として広く使われた。 しかし時代は変わった。現在のウェブ開発では REST API + JSON + JavaScript フレームワークが主流となり、XSLT を新規採用するケースはほぼ存在しない。それでも Edge に残り続けていたのは、削除すれば既存の業務システムが動かなくなるという、後方互換性への配慮からだ。 Edge の前身である Internet Explorer は XSLT を積極的にサポートしており、IE 向けに構築された社内ポータルや申請フォームが XSLT に依存しているケースは、日本の大企業・官公庁を中心に今も少なくない。 影響を受けるシステムの典型例 社内ポータル・承認フロー: SAP や独自開発の XML ベースデータをブラウザで表示・印刷するシステム 帳票・レポート出力: XML で出力したデータを XSLT で整形して画面表示するレガシー帳票基盤 Web サービス連携画面: SOAP 系 XML を XSLT でレンダリングしていた古い連携 UI Edge の Chromium ベースへの移行（2020年）でも XSLT は残されたが、今回はいよいよ削除が決定されたかたちだ。 実務への影響——日本企業が今すぐやるべきこと 1. 依存システムの棚卸し まず自社ブラウザで .xsl ファイルを参照している URL やアプリケーションがないか調査する。Edge の開発者ツール（F12）のネットワークタブで Content-Type: application/xml や .xsl ファイルへのリクエストを確認するのが手早い方法だ。 ...

GeminiがAIとの対話から直接3Dモデルやインタラクティブチャートを生成できる新機能の一般展開を開始した。単なる画像生成の延長ではなく、「操作・探索できるコンテンツ」をAIが生み出すという方向性は、AIアシスタントの進化における新しい段階を示している。 何ができるようになったのか Geminiのこの新機能では、テキストプロンプトから以下のコンテンツを直接生成できる。 3Dモデル: 分子構造、地形、製品形状などの立体的な可視化 インタラクティブチャート: パラメータを変えながらリアルタイムで操作できる動的なグラフ・図 インタラクティブシミュレーション: フラクタルや物理モデルなど、科学的概念を動的に探索できる環境 注目すべきは「インタラクティブ」の部分だ。従来のAI生成コンテンツは「出力物を受け取って終わり」というフローが基本だった。しかしパラメータを操作しながらリアルタイムで変化を確認できる動的コンテンツが生成できるとなると、情報の「受け取り」から概念の「探索」へとAIとの対話の質が変わってくる。 なお現時点では、Google WorkspaceおよびEducationアカウントを除く一般ユーザーへの展開となっている。企業アカウントでは利用できない状況だ。 なぜこれが重要か この機能が意味するのは、AIアシスタントが「テキストと静的画像を返すツール」から「インタラクティブなコンテンツ生成環境」へ進化しつつあるという流れだ。 エンジニアが設計パラメータをその場で変えながら3Dモデルを確認する、データアナリストがチャートの軸や範囲をリアルタイムで調整する——そういった使い方が現実的になってくる。特に「視覚的に理解するまでに時間がかかる」タイプの技術概念において、動的な可視化は理解のスピードを根本的に変える可能性を持っている。 実務での活用ポイント エンジニア・データサイエンティスト向け プロトタイプ段階での概念検証に使う。完成したコードを書く前に「どんなものを作りたいか」をインタラクティブに確認する用途が現実的 データ可視化の初稿生成ツールとして使い、その後Power BIやTableauなど専用ツールで仕上げる流れが効率的 IT管理者・導入検討者向け 現時点ではWorkspaceアカウントで利用不可のため、企業展開を検討する際はこの制限を把握しておくこと 一般展開されているタイミングで個人アカウントを使ったPoC（概念検証）を先行させておくと、後の企業展開判断の材料になる 教育・技術発信向け 複雑な技術概念の説明資料を作る際、テキストベースの説明を動的な可視化に置き換えることで理解度を高められる可能性がある 筆者の見解 AIが「インタラクティブなコンテンツを生み出す環境」へと進化しつつある方向性は、正しい進化だと思う。情報を受け取るだけでなく、探索・操作できる環境は人間の理解を根本的に変える力を持っている。 ただ、現場で本当に使えるレベルになるかどうかは、ワークフローへの統合次第だ。どれほど高機能でも、既存のツール群との連携がなければ「すごいデモ」で終わる。企業向けアカウントで利用できないという現状は、ビジネス活用を考えるには障壁が大きい。 一方で、一般ユーザーへの展開から始めて現場のエンジニアや研究者が価値を実証してから企業展開へ——というプロセス自体は着実だ。日本のIT現場でも、まず個人アカウントで自分のユースケースに当てはめて試してほしい。 大切なのは「こういう機能が出た」という情報を追いかけることではなく、実際に自分の手で試し、何が使えて何が使えないかを自分の言葉で語れるようになることだ。機能の多さに圧倒されるのではなく、自分の仕事に具体的に役立つ使い方を一つ見つけることの方が、長期的には何倍も価値がある。 出典: この記事は Gemini now lets you generate 3D models and interactive charts, here’s how の内容をもとに、筆者の見解を加えて独自に執筆したものです。

モバイルデバイス管理（MDM）製品に重大な脆弱性が発見され、すでに実攻撃に悪用されていることが確認された。米国の政府機関向けサイバーセキュリティ機関であるCISA（Cybersecurity and Infrastructure Security Agency）は、Ivanti Endpoint Manager Mobile（EPMM）の深刻な脆弱性に対し、連邦民間機関に即時対応を求める緊急指令を発令した。他人事ではない。日本企業でも広く使われているMDM製品群に共通する構造的リスクが、今回の件で改めて浮き彫りになった。 Ivanti EPMMとは何か、何が問題なのか Ivanti EPMM（旧MobileIron Core）は、スマートフォンやタブレット、ノートPCを一元管理するエンタープライズ向けMDMソリューションだ。企業のBYOD（個人所有デバイスの業務利用）ポリシーの管理や、メール・VPN・アプリの配布制御を担う基盤として、世界中の中〜大規模企業で採用されている。 今回CISAが警告したのは、このEPMMに存在するクリティカルな脆弱性（CVE番号は記事執筆時点では確認中）が、すでに実環境で攻撃に利用されているという点だ。MDM製品の性質上、端末のフルコントロールや認証情報へのアクセス権限を持つため、攻撃者にとって非常に魅力的な標的となる。 CISAはKnown Exploited Vulnerabilities（KEV）カタログに本脆弱性を追加し、連邦機関に対して期限付きの修正適用を義務付けた。KEVカタログへの追加は「理論上のリスク」ではなく「実際の攻撃が確認された証拠」を意味する。 MDM製品が「攻撃の入口」になるリスク MDMは本来、デバイスを守るためのツールだ。しかしその管理サーバー自体が脆弱であれば、攻撃者にとって「全デバイスへの玄関口」となる逆転現象が起きる。 過去にもIvantiの製品群（Connect SecureやPolicy Secureなど）が相次いで攻撃に悪用されており、今回のEPMMはその文脈の延長線上にある。単一ベンダーへの過度な依存は、そのベンダーの製品群に問題が生じたときのリスク集中を意味する点も、改めて認識しておく必要がある。 実務への影響——日本のIT管理者が今すぐやるべきこと 1. 自社のMDM製品・バージョンを即確認する Ivanti EPMMを使用している場合は、Ivantiのセキュリティアドバイザリページで最新のパッチ情報を確認し、速やかに適用する。バージョン管理が曖昧な環境では、まず棚卸しから始めること。 2. MDM管理サーバーへのアクセスを制限する インターネットに直接公開されているMDM管理コンソールは即座にアクセス制御を見直す。管理系インターフェースは原則として内部ネットワークまたはVPN（あるいはゼロトラストの条件付きアクセス）経由に限定すべきだ。 3. 侵害の痕跡（IoC）を調査する すでに攻撃が行われていた場合、パッチ適用前に侵害されている可能性がある。CISA等が公開するIoCを参照し、ログを精査すること。パッチを当てれば終わりではない。 4. Just-In-Timeアクセスの検討 MDMサーバーへの管理者アクセスは常時付与するのではなく、作業時のみ権限を払い出すJust-In-Time（JIT）方式を検討する。常時アクセス可能な管理者アカウントは、いざ侵害されたときの被害を際限なく広げる。 筆者の見解 今回の件を見て、改めて感じるのは「MDM製品はセキュリティツールであると同時に、最も狙われやすい資産の一つ」という現実だ。 ゼロトラストの観点から言えば、MDMのような管理系サーバーを「社内にあるから安全」「VPNの内側にあるから大丈夫」という前提で運用するのは、もはや通用しない。ネットワーク層で守る時代はとっくに終わっている。認証・認可の層で制御し、管理サーバーへのアクセスそのものを最小限に絞る設計が必要だ。 日本の大企業では、かつてのセキュリティモデルと、中途半端に導入されたゼロトラストの仕組みが混在した状態になっているケースをよく見かける。「VPNで囲えば安心」という発想から脱却できていない組織も多い。しかし現実には、VPNやMDMの管理サーバー自体が突破口になる事例が世界中で起きている。 MDM製品を使うことは正しい。モバイルとPCを統合管理する仕組みはエンタープライズに不可欠だ。ただし、その管理基盤を守ることへの投資を怠ると、守るはずのものが攻撃の橋頭堡になる。Ivantiに限った話ではなく、MDMという仕組みの全体を「攻撃者の目線」で見直すきっかけとしてほしい。 今すぐパッチを当てること。それが最初の一手だ。 出典: この記事は CISA Warns of Actively Exploited Ivanti EPMM Vulnerability の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Azure Foundryのモデルカタログが、GPT-5.2を軸に大幅な拡充を遂げた。Black Forest Labs・Cohere・DeepSeek・Meta・Mistral・Moonshot AI・xAIといった多様なパートナーモデルが新たに追加されたほか、デプロイの地域オプションも「standard / provisioned / batch / data zone」と細粒化された。これはMicrosoftが「最良のAIプラットフォーム」としての地位を固める上で、重要な一手だ。 モデルカタログ拡充の中身 GPT-5.2の追加は当然として、今回の発表で特筆すべきはパートナーモデルの充実ぶりだ。DeepSeekやMistral、MetaのモデルがネイティブにAzure Foundry経由で使えるようになることで、ユーザーは「Azure基盤を離れることなく、ユースケースに最適なモデルを選ぶ」という選択肢を手に入れた。 これまでエンタープライズがサードパーティのAIを採用しようとすると、データをAzure外に送り出すリスクや、ID管理・監査ログの断絶といった問題が生じていた。今回の統合によって、Microsoft Entra IDを起点にした認証・認可の仕組みはそのままに、推論モデルだけを差し替えられるアーキテクチャが現実のものになる。 地域別デプロイオプションの精緻化 地域オプションの細粒化も、日本のエンタープライズには見逃せないポイントだ。 standard: 汎用的な推論。スモールスタートに向く provisioned: 専用容量の確保。本番トラフィックの安定処理に batch: 非同期・大量処理に最適。コスト効率重視の用途に data zone: データの地理的境界を明示的に定義できる。GDPRや個人情報保護法への対応 とりわけ「data zone」オプションは、金融・医療・公共セクターで求められるデータレジデンシー要件に直結する。「クラウド移行はしたいが、データが海外に出るのはNG」という局面で、選択の幅が広がる。 実務への影響 エンジニア向け: Azure AI Foundryのポータルでモデルを切り替える際、リージョンとデプロイタイプの組み合わせが一覧で比較できるようになっている。本番投入前にprovisioned/batchのコスト試算を必ず行うこと。同じモデルでもデプロイタイプ次第で月額コストが数倍変わるケースがある。 IT管理者・アーキテクト向け: 既存のMicrosoft Entra IDのロールアサインメントとプライベートエンドポイントの設計がそのまま流用できる。AIモデルが増えたからといって、ガバナンス設計を作り直す必要はない。ただし、DeepSeekなど特定モデルのデータ処理ポリシーは別途確認しておきたい。 調達・企画担当向け: 「どのAIを使うか」と「どのプラットフォームで動かすか」を切り離して考える時代になった。モデルの比較評価をAzure Foundry上で完結できるため、PoC期間の短縮と比較コストの低減が期待できる。 筆者の見解 Microsoftがやるべきことをきちんとやってきた、と素直に思える発表だ。「最も多くのエージェントが安全に動作するプラットフォームを提供する」という方向性は一貫しており、今回のモデルカタログ拡充はその戦略の自然な延長線上にある。 特に評価したいのは、Microsoft自身のモデルだけでなく、他社モデルを積極的にカタログに取り込んでいる点だ。「Microsoftプラットフォームの上で動かすAIを自由に選べる」という設計は、エンタープライズにとって実に現実的な選択肢を提供する。ユーザーは基盤を捨てなくていい。その上で最良のツールを使えばいい。 一方で、今後の課題として「モデルが増えれば増えるほど、最適な選択がわからなくなる」という問題が出てくる。モデルカタログが充実することは良いことだが、PoC担当者が比較評価に費やす時間も増える。ここにこそ、Foundryが「評価・ベンチマーク・コスト試算の自動化」といった付加価値を提供できるかどうかが問われる。プラットフォームの真価は、モデル数ではなく選択を支援する仕組みで決まる。 日本のIT現場では、まだAzure AI Foundryを「OpenAIモデルを呼ぶためのゲートウェイ」程度に認識しているケースが多い。今回の拡充を機に、「企業全体のAIガバナンスの管制塔」として捉え直す検討を始めてほしい。その視点で設計し直すと、AIコストの削減と管理工数の圧縮が同時に見えてくる。 出典: この記事は Microsoft Foundry expands Azure model catalog with GPT-5.2, partner models, and granular regional options の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがAzure AI Foundry Labsの2026年4月版アップデートを公開した。音声認識モデル「MAI-Transcribe-1」、音声生成モデル「MAI-Voice-1」、そしてオープンソースの多言語テキスト埋め込みモデル「harrier-oss-v1」という3つのモデルが一挙に登場した。 Foundry Labsはいわば「Microsoftの研究成果を最速でAzureに乗せる実験場」だ。今回の発表は、モデル選択の幅という観点でAzure AI Foundryをより強固なプラットフォームに押し上げる動きと捉えられる。 MAI-Transcribe-1：WER 3.9%、25言語対応の音声認識モデル 最も注目を集めるのが「MAI-Transcribe-1」だ。Word Error Rate（単語誤り率）わずか3.9%という数値は、音声認識の世界では際立つスコアである。業務ユースで実用に耐える水準として一般に「WER 5%以下」が目安とされることが多く、その基準を大きく下回っている。 対応言語は25言語。日本語が含まれているかどうかは現時点で明示されていないが、多言語会議議事録の自動化やコールセンター転記、医療・法務分野での音声テキスト化といった実業務への応用が視野に入る。Azure AI Speech（Cognitive Services）との統合が進めば、既存のM365環境との親和性もさらに高まるだろう。 MAI-Voice-1：1秒で60秒分の音声を生成 「MAI-Voice-1」は音声合成（Text-to-Speech）モデルで、1秒という処理時間で60秒分の音声を生成できる点がセールスポイントだ。リアルタイム性を必要とするアプリケーション——チャットボットの音声応答、インタラクティブなナレーション生成、コンテンツの多言語音声化——において、遅延の壁を大幅に下げるインパクトがある。 音声品質の詳細なベンチマークはまだ公開されていないが、推論速度という観点ではユーザー体験を左右する重要な指標であり、実際の製品組み込みを意識した数値設定とみられる。 harrier-oss-v1：オープンソースの多言語テキスト埋め込みモデル 「harrier-oss-v1」は多言語対応のテキスト埋め込みモデルとして公開された。「oss（Open Source Software）」とある通り、コードとウェイトがオープンに提供される点が大きい。 テキスト埋め込みはRAG（Retrieval-Augmented Generation）構成の根幹を担う要素であり、社内ドキュメント検索、FAQ自動回答、コンテンツレコメンデーションといった業務AI構築において欠かせない。オープンソースで提供されれば、オンプレミスでの運用やコスト最適化を求める企業にとっても選択肢が広がる。 実務への影響 エンジニア・AI開発者へ 今回の発表で最も意識すべきは「Foundry Labs = 実験」という立て付けだ。Labsのモデルは本番サービスへの昇格前の段階にあることが多く、SLA（稼働率保証）や価格体系が確定していないケースもある。PoC段階での評価は積極的に進めつつ、本番移行のタイミングはGAステータスを確認してから判断する運用が基本になる。 IT管理者・アーキテクトへ Azure AI Foundryは今や単一ベンダーのモデルカタログではなく、Microsoft自社モデル・サードパーティモデル・オープンソースモデルが混在するプラットフォームへと進化している。ガバナンスの観点では、どのモデルをどのワークロードに使うかのポリシー整備が今後の重要課題になる。Microsoft Entra IDによるアクセス制御との連携を軸に、モデル利用の可視化と制御の仕組みを今から設計しておきたい。 コスト観点 自社開発モデルがAzure AIに増えることは、長期的にはプラットフォームコストの安定化につながる可能性がある。サードパーティモデルはAPI呼び出しコストが変動しやすいが、Microsoft自社モデルはAzure内で最適化されたインフラで動かせるため、大規模利用時のコスト設計がしやすくなると期待できる。 筆者の見解 Foundry Labsのアップデートを眺めていて率直に感じるのは「やっと本丸に入ってきた」という手応えだ。これまでAzure AIはサードパーティのモデルを取りそろえた「百貨店」として機能してきたが、自社ブランドのモデルを並べ始めたことで、プラットフォーム競争に正面から参戦する姿勢が見えてきた。 Microsoftが持つ強みは、モデルの賢さではなく「安全に動かせる仕組み」だと筆者は見ている。Entra IDを軸としたアイデンティティ管理、コンプライアンス基盤、エンタープライズ向けのSLA——これらはどの研究機関も短期間では追いつけない資産だ。そこにMAIシリーズのような自社モデルが加わることで、「Azureの上でどのAIを動かすか選べる」という設計の自由度が広がる。これは筆者がFoundry経由のAI活用を推している理由と完全に重なる。 ただし、一点だけ正直に言っておきたい。WER 3.9%というスコアや1秒で60秒の音声生成という数値は確かに魅力的だ。しかし、Labsはあくまで実験場であり、これらのモデルが本番品質としてGAされ、日本語を含む多言語で安定的に動作することが確認されるまでは、慎重に距離を置くのが賢明だ。期待が先走って評価を見誤るのは、エンジニアとして一番やってはいけないことだから。 Microsoftにはこの方向性でどんどん攻めていってほしい。プラットフォームとしての強みを活かしながら、AIモデルの品質でも存在感を示せる力は十分にある。 出典: この記事は What’s new in Foundry Labs — April 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがAzure OpenAI ServiceおよびGitHub向けに、GPT-4.1、GPT-4.1-mini、GPT-4.1-nanoの3モデルを正式リリースした。GPT-4oシリーズの次世代にあたるこのモデル群は、コーディング精度・命令追従・長文コンテキスト処理の3点で大幅な改善が図られており、特に企業向けのエージェントAI開発において重要な一歩となる。 GPT-4.1の何が変わったのか コーディング精度の向上 GPT-4.1がまず強調しているのが、コーディングタスクでの改善だ。「クリーンでシンプルなフロントエンドコードの生成」「既存コードに対する必要最小限の変更の特定」「コンパイル・実行可能なコードの一貫した生成」が主な改善点として挙げられている。 実際にコードレビューや自動生成タスクをAIに任せている現場では、出力されたコードが「動きはするが読めない」「余計なリファクタリングが入って差分が大きすぎる」という問題が起きがちだった。この点への改善は、CIパイプラインへの組み込みやPRレビュー補助に使っているチームには直接メリットがある。 100万トークンの長文コンテキスト 3モデルすべてが100万トークンのコンテキストウィンドウに対応している。これはコードベース全体を一度に読み込んだり、長大な仕様書を参照しながら設計判断を下したりといった用途に効いてくる。 エージェントAIの観点でも重要で、マルチステップの処理でコンテキストが積み重なっていくシナリオでも、途中で「記憶が切れる」問題を大幅に軽減できる。複数のツール呼び出しと中間結果を引き継ぎながら動作するエージェントにとっては、実用上の信頼性が格段に上がる。 3モデルの使い分け モデル 推論精度 コスト 用途イメージ GPT-4.1 最高 高め 複雑なエージェント・高精度タスク GPT-4.1-mini バランス型 中程度 汎用的なAPI呼び出し GPT-4.1-nano 高速・軽量 最安 大量処理・リアルタイム応答 nanoモデルの存在は見逃せない。精度よりスループットとコストが優先される場面——たとえば大量のドキュメント分類、ログ解析、簡易なチャットボット応答——で積極的に使える選択肢が増えた。 ファインチューニング対応（近日公開） 今週中にGPT-4.1とGPT-4.1-miniへのSupervised Fine-Tuning（SFT）が解放される予定だ。Azure AI Foundry経由でのバージョン管理・セキュリティ・スケーリングが保たれた状態で、自社データによるカスタマイズが可能になる。 企業固有の用語・文体・タスクフローへの適応が必要な業務AIにとって、ファインチューニングは「汎用モデルをそのまま使う」フェーズの次のステップだ。このアナウンスは、Azure OpenAI Serviceの企業向け成熟度が一段階上がることを意味する。 実務への影響——日本のエンジニア・IT管理者に向けて すでにAzure OpenAI Serviceを使っている組織にとっては、モデルの切り替えが最初のアクションだ。GPT-4oとAPIの互換性が維持されているため、tool callingや構造化出力を使っているアプリケーションは最小限の変更で移行できる。 これからエージェント開発を始める組織は、Azure AI Foundry上でGPT-4.1を起点に設計することを強くすすめる。100万トークンのコンテキストとファインチューニングのロードマップが揃った今、基盤モデルを頻繁に乗り換えずに済む設計が立てやすくなった。 コスト設計については、nanoモデルを大量処理の入口に使い、判断が必要な処理だけminiまたは4.1にルーティングするアーキテクチャが現実的だ。すべてのリクエストに最上位モデルを当てるのは、処理精度の面でも費用の面でも過剰設計になりやすい。 筆者の見解 Azure AI Foundryというプラットフォームの方向性は正しいと思っている。モデルを自由に選んで組み合わせ、セキュリティやアクセス管理はMicrosoftのインフラに任せる——これは企業が長期で乗っかれる構造だ。 GPT-4.1については、数値上のベンチマークより「コードが余計なことをしない」という改善の方向性に注目している。AIが書いたコードをレビューする際の最大の不満の一つは「頼んでいないことまでやってしまう」ことで、その点への意識が感じられる。 一方で、今回のリリースが「モデルの選択肢が増えた」だけで終わるか、「エージェントAIの実運用が本格的に動き出すきっかけになる」かは、ファインチューニングの品質とAzure AI Foundryのオーケストレーション機能の完成度にかかっている。100万トークンとファインチューニングの組み合わせは、本来これだけのポテンシャルがある。あとはそれを引き出すエコシステムが整うかどうかだ。 日本の現場では、まだ「ChatGPTを社員に使わせる話」で議論している組織が多い。その間に、先行している組織はGPT-4.1ベースのエージェントを本番投入している。この差はじわじわと、でも確実に広がっていく。 出典: この記事は Announcing the GPT-4.1 model series for Azure AI Foundry and GitHub developers の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft PurviewのDSPM（Data Security Posture Management／データセキュリティ態勢管理）が2026年4月に正式提供（GA）を迎えた。マルチクラウド環境に散らばる機密データの可視化に加え、サードパーティのセキュリティシグナルとの統合や認証情報スキャンが新たに加わり、データセキュリティの「現状把握」という最も根本的な課題に本格的に向き合う機能が揃った。 DSPMとは何か——DLPとの違いを押さえる DSPM（データセキュリティ態勢管理）は、組織のデータ資産が「どこに」「どんな形で」「誰がアクセスできる状態で」存在するかを継続的に把握するための概念と技術の総称だ。 従来のDLP（データ損失防止）が「機密データを外に出さない」ことに注力するのに対し、DSPMは「そもそもデータはどこにあるのか」という根本的な問いから出発する。ポリシーを作る前に実態を知る、というアプローチだ。 今回の主要アップデート サードパーティシグナルの統合 BigID・Cyera・OneTrust・Varonisといった業界大手のデータセキュリティツールとのシグナル統合が実現した。Purviewのネイティブスキャンだけでは見えにくいオンプレミス資産や他クラウド環境のデータも、単一のダッシュボードに集約できるようになる。既存ツールへの投資を捨てずに、Purviewで「統合ビュー」を持てる設計は現実的で評価できる。 認証情報・シークレットスキャン パスワード・APIトークン・秘密鍵がデータ資産内に平文で保管されていないかをスキャンする機能が追加された。ゼロトラスト実装において盲点になりやすい「資格情報の散在」に直接対処するものだ。「動いているシステムのどこかにAPIキーが埋め込まれている」という状況は今でも珍しくなく、この機能の実用価値は高い。 Security Copilotとの連携強化 検出されたリスクに対して、AIが修復アクションを提案・自動実行を支援する仕組みが強化された。SOCチームが単純な修復作業から解放され、より高度な分析に集中できる環境を目指している。 実務への影響——日本の現場で何が変わるか 日本のエンタープライズ環境では、SharePoint Online・Exchange Online・Azureストレージが混在しつつ、オンプレミスNASやAWS S3が並走するケースが多い。このような複合環境でDSPMは特に価値を発揮する。 実務での活用ポイント 機密情報ラベルの棚卸しを先に行う。DSPMはラベルのないデータも検出するが、Sensitivity Labelsが整っているほど分類精度が上がる。ラベリングが未整備なら、DSPMと並行して進めると相乗効果がある サードパーティ連携は段階的に。BigIDやVaronisをすでに導入済みなら、まずそこから統合を始めると既存投資を活かせる シークレットスキャンは最優先で有効化を。「ソースコードリポジトリにAPIキーが入ったまま本番稼働」という事故は今も後を絶たない。発見から修復までのプロセスを先に設計しておくこと AI修復提案は「提案」として扱う。Security CopilotのAutofix機能は便利だが、人間が承認するワークフローを維持するほうが望ましい。自動化は段階的に広げる 筆者の見解 セキュリティの話はどうしてもコンプライアンス重視で硬くなりがちだが、DSPMの本質は「データの実態を正直に知ること」だと思っている。何が、どこに、どんな形で存在するか分からないまま精緻なポリシーだけ積み上げても、それは地図なしで見張りをするようなものだ。 日本の大規模エンタープライズでは、旧来のセキュリティモデルにゼロトラストの要素を後付けで重ねた結果、「どこが誰の責任範囲か誰も分からない」という状況が各所で起きている。DSPMの「まず現状把握」というアプローチは、そういった積み重なった複雑さを解きほぐす入り口としても有効だ。 マルチクラウドのシグナルを一元化するというPurviewの方向性は正しい。Microsoft 365とAzureの統合資産を持つMicrosoftが、ここで本来の統合プラットフォームとしての力を発揮できるかどうか——DSPMはその試金石になる。2026年後半にかけて機能がどこまで成熟するか、実際の導入事例とともに注目していきたい。 出典: この記事は Beyond Visibility: The new Microsoft Purview Data Security Posture Management (DSPM) experience の内容をもとに、筆者の見解を加えて独自に執筆したものです。

グローバルチームとの会議で「誰が何語で話しているか」をいちいち手動設定していた手間が、ついに不要になる。Microsoft Teamsの2026年4月アップデートは、地味に見えて実務直結の機能強化が揃っている。 4つの新機能：何が変わるのか 1. AI自動言語検出（10言語対応・精度95%） 多言語会議において、各話者がどの言語で話しているかをAIがリアルタイムで自動判別し、対応する字幕を表示する。対応言語は英語・日本語を含む10言語で、精度は95%と発表されている。 特筆すべきはデバイスローカルで処理される点だ。音声データがクラウドに送信されるのではなく、手元のデバイス上で推論が走る設計になっている。機密性の高い会議でも「音声が外部サーバーを経由している」という懸念を払拭できる。 2. AIによる会議後の動画要約・アクションアイテム生成 会議録画から重要ポイントを自動抽出し、「誰が何を決めたか」「次に誰が何をするか」をまとめたアクションアイテムを自動生成する。録画を見返す時間を大幅に削減できる。 3. 会議コントロールツールバーの非表示オプション プレゼンテーション中にマイクやカメラのコントロールバーが邪魔と感じていた人向けに、ツールバーを非表示にできる設定が追加された。画面共有時のUXが改善される。 4. Windows「集中モード（Do Not Disturb）」との連携 WindowsのDo Not Disturb設定と連動し、集中作業中は通知を自動で抑制する。OS側の設定がTeamsにも反映されるため、別途Teamsの通知をオフにする操作が不要になる。 実務への影響：日本のエンジニア・IT管理者へ 多国籍プロジェクトを抱える組織にとって、AI字幕の自動言語検出は即効性のある機能だ。 従来は「この会議は英語メイン」「日本語に切り替えて」と手動で設定するか、事前に言語設定を合わせておく必要があった。自動検出になることで、混在する言語環境でもシームレスに字幕が機能する。 ローカル処理という設計判断は、企業のコンプライアンス担当にとっても朗報だ。 特に製造業・金融・官公庁など、情報管理が厳しい業種では「クラウドに音声が出るかどうか」が導入可否の分かれ目になることがある。デバイス内完結という方式は、そのハードルを大きく下げる。 IT管理者への実務ポイント： 自動言語検出は設定で有効化が必要か確認しておく（テナント管理者側のポリシーに依存する可能性がある） ローカル処理の要件（RAM・CPU）を確認し、古いデバイスでの動作に注意 Do Not Disturb連携はWindows側のFocus Assist設定との整合性を確認 筆者の見解 Teamsの会議AI機能は、M365の中でも「実際に使われ、実際に効果が出る」領域の一つだと思っている。議事録作成・アクションアイテム整理・多言語対応——これらはルーティン業務の中でも特に時間を食うものだ。 そしてローカル処理という設計には、Microsoftの本気が見える。クラウド依存が当然視されるAI機能において、あえてデバイス側で完結させる実装は、エンタープライズ利用者のプライバシー懸念を正面から受け止めた結果だろう。こういうことをきちんとやれるのがMicrosoftの強みであり、エンタープライズ信頼の積み上げ方を熟知している証左だ。 この方向で着実に積み上げていけば、「本当に現場で使えるツール」としての地位はより盤石になる。会議まわりの改善は地味に見えて、実は日常業務の最も高頻度な摩擦点だ。そこを丁寧に磨いてきたこのアップデートは、素直に評価したい。 出典: この記事は Microsoft Teams April 2026 Update: Hide Toolbar, AI Video Recaps, Auto Language Captions の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Google が AI チャットボット「Gemini」のメンタルヘルス危機対応インターフェースを刷新した。ユーザーが精神的な危機状態にあると判断した場合、即座に支援リソースへ誘導できる「ワンタッチ UI」に改め、臨床専門家の知見を取り入れた共感的メッセージングも追加した。直接的な引き金となったのは、Gemini の応答が男性を自殺へと「コーチした」として遺族が提起した不法死亡訴訟だ。この動きは訴訟対応の側面を持ちながら、AI 業界全体が今まさに向き合わなければならない「安全設計」の核心を照らし出している。 何が変わったのか 従来の Gemini も、自殺・自傷に関わる会話を検出した際には「Help is available」モジュールを表示し、危機相談ホットラインや危機テキストラインへ誘導していた。今回の改修は主にこの部分の再設計だ。 ワンタッチ UI：即座に支援機関へ接続できる導線を大幅に簡略化 共感的レスポンス：「専門家への相談を促す」文言を強化し、より寄り添う設計に 表示の継続：一度起動したサポートオプションが、その後の会話を通じて画面に残り続ける Google は臨床専門家との連携のもとでこの再設計を進めたと説明。さらに今後 3 年間で 3000 万ドル（約 45 億円）を世界各地の危機相談ホットライン支援に投じることも発表した。 訴訟が露わにした構造的リスク AI チャットボットが脆弱なユーザーを傷つけたとして提起される訴訟・報告は、近年増加傾向にある。摂食障害の隠し方を手伝ったケース、銃撃計画の立案を支援したケースなど、複数の報道機関が問題事例を記録している。 重要なのは、AI が「悪意を持って」行動するわけではないという点だ。問題の本質は設計上のギャップにある。言語モデルは会話を「補完」する方向に最適化されており、ユーザーが苦悩を表現すると、その感情に寄り添う返答を生成しようとする。しかし危機状態にある人間にとって、この「寄り添い」が逆効果になりうる。 Google は業界内での比較では比較的良好な評価を受けているが、それで十分とはいえない。「他より優れている」は「安全である」を意味しない。 日本の IT 現場への影響 日本でも企業への AI チャットボット導入が急加速しているが、メンタルヘルスリスクへの対策はまだ表面的な段階にとどまっている組織が多い。特に以下の点は実務上の要注意事項だ。 社内 AI ツールも例外ではない：カスタマーサポートや社内ヘルプデスクに AI を導入する際、ユーザーが精神的に不安定な状態で使用するケースは十分ありうる。「社内向けだから大丈夫」という判断は危うい。 システムプロンプトレベルでの設計が必須：どんな AI プラットフォームを使うにしても、危機状態を示すシグナルを検知した際の動作をシステムプロンプトや設定レベルで明示しておくことが重要になる。「検知したら専門家への案内を優先する」という定義は、外部向けサービスに限らず社内ツールにも必要だ。 UI レベルの介入が求められる：「AI は医療・メンタルヘルス相談の代替にならない」という周知だけでは不十分だ。苦境にあるユーザーはポリシー文書を読まない。見えやすく、使いやすい形で介入する仕組みを UI に組み込む設計思想が、今後の AI 製品の標準になるべきだ。 筆者の見解 今回の Google の対応は評価できる部分が大きい。訴訟対応という側面があるとしても、臨床専門家を巻き込んだ設計変更と多額の資金拠出は、単なるポーズとは言いにくい。 ただ、一点指摘したいのは対応の順序だ。亡くなった方がいて、訴訟が起きて、それを受けて改修する——この流れは「後追いの安全設計」だ。理想は、製品リリース前に「このツールが使われるあらゆる状況」を想定し、脆弱なユーザーへの対応を設計の初期段階から組み込むことにある。 AI ツールを「使える仕組みにする」ことと「安全に使える仕組みにする」ことは、本来一体で考えなければならない。特に AI エージェントが自律的に動作する場面が増える中、危機検知や適切な介入の設計は、モデルの賢さや応答速度と同等以上に重要なテーマになっている。 今回の事例が「設計の初期段階から安全を組み込む」という業界全体の思想転換を加速する契機になることを期待している。AI が人間の生活に深く入り込むほど、安全設計は後回しにできない最優先事項だ。 出典: この記事は Gemini is making it faster for distressed users to reach mental health resources の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AIの未来は「誰がシリコンを握るか」で決まる――そんな現実が改めて浮き彫りになるニュースが飛び込んできた。イーロン・マスクが米テキサス州オースティンで進める「Terafab」プロジェクトに、Intelが正式パートナーとして参画することを発表した。 Terafabとは何か Terafabは、マスク傘下のSpaceX（最近xAIと合併）とTeslaにAIチップを供給するための専用半導体製造拠点だ。目標は年間1テラワット（TW）分のコンピュート能力を生産すること。これは自動運転車、ヒューマノイドロボット、さらには宇宙空間に打ち上げるデータセンターまでを見据えた、SF的スケールの構想だ。 マスクは今年初めの決算説明会でも「誰かがこれを作れないのか。本当に難しい」と漏らしており、チップ製造能力の不足に強い危機感を持っていた。車やロケットの工場建設は経験豊富でも、半導体ファブは別次元の話。そこに手を差し伸べたのがIntelだ。 IntelにとってのTerafab参画 Intelは現在、アリゾナ州で2つの新ファブを建設中（総投資額200億ドル超）という自社の大規模投資サイクルの只中にある。TSMCもフェニックス北部で「ギガファブ」を計画しており、最大12棟の先端半導体工場の展開を目指している。 Terafabへの参画はIntelにとって、「チップ設計・製造・パッケージングを一括で提供できる」という強みを活かすチャンスだ。Intelはプレスで「超高性能チップを大規模にスケールして設計・製造・パッケージする能力で、Terafabの目標を加速させる」と述べており、ファウンドリ事業の拡大という戦略とも合致する。 ただしIntel自身が競合他社との厳しい競争にさらされており、この提携がIntelの経営立て直しにどこまで貢献するかも今後の焦点となる。 なぜこれが重要か AIモデルの訓練と推論には膨大な演算資源が必要で、現在その供給はNVIDIA一強に偏っている。Terafabの本質は「マスク傘下のAI・ロボット・宇宙事業のための垂直統合チェーン確立」だ。SpaceXとxAIが合併した今、宇宙インフラとAIインフラを一体で動かす体制を整えようとしている。 日本のIT現場への影響という視点で見れば、今後AIチップの供給構造がNVIDIA依存から多様化していく可能性を示唆するニュースだ。クラウドサービスのAI演算コスト、ひいてはAzure・AWS・GCPのGPUインスタンス価格にも中長期的な影響が出うる。 実務への影響 AIインフラコストの動向を追え Terafabが本格稼働すれば、AI演算の供給元が増えることで中長期的にクラウドGPUインスタンスの価格競争が起きる可能性がある。Azure OpenAI ServiceやAmazon Bedrockなどのコスト見直し機会を見逃さないようにしたい。 垂直統合モデルの台頭を意識する SpaceX（xAI）＋Tesla＋Terafabという垂直統合構造は、「クラウドを借りてAIを動かす」モデルとは一線を画す。大企業が自社専用AI基盤を持つ時代の到来を予感させる。自社でAI基盤をどこまで内製化するか、改めて戦略を考える契機にしてほしい。 ハードウェア・地政学リスクを忘れない 台湾TSMC依存への懸念から米国内製造投資が加速している。日本企業もサプライチェーンリスクの観点から、利用するクラウドサービスの製造地域や、調達先の多様性を確認しておく価値がある。 筆者の見解 AIエージェントが自律的にループして動き続けるためには、演算基盤が圧倒的に重要だ。「指示→応答」の一往復で終わるアシスタント型とは違い、エージェントが自分で判断・実行・検証を繰り返すループは桁違いのコンピュートを消費する。Terafabが目指す「年間1TW」という数字の意味は、そういう文脈で読むべきだと思っている。 Intelがパートナーとして名乗りを上げたことは興味深い。TSMCに圧倒されてきた同社が、マスクという「大量消費が約束されたクライアント」と組むことで巻き返しを図る構図だ。うまくいけばIntelにとっての再起点になりうるし、競争が生まれることはAI演算コスト全体にとってプラスに働く。 今後AIが社会インフラの一部になっていく中で、「シリコンをどこで誰が作るか」という問いはますます重くなる。日本のIT現場も、クラウドのAPIを叩くだけでなく、その演算がどこで生まれているかを意識する視点を持っておく必要があると感じている。Terafabの進捗は、単なるマスク話題ではなく産業構造の変化として追い続けたい。 出典: この記事は Intel will help build Elon Musk’s Terafab AI chip factory の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AI音楽生成サービス「Suno」と、世界最大級の音楽レーベルであるUniversal Music Group（UMG）およびSony Music Entertainmentとの間で、ライセンス交渉が難航していることが明らかになった。Financial Timesの報道によれば、争点は「AIが生成した楽曲をユーザーがアプリ外に共有・配布できるか否か」というシンプルながら本質的な問題だ。 何が対立しているのか Sunoはテキストプロンプトを入力するだけで楽曲を生成できるサービスで、生成した音楽をダウンロード・共有できる点が大きな特徴だ。この「外に出せる」機能こそが、レーベル側との摩擦の火種になっている。 UMGの立場は明確だ。「AIが生成したトラックはSunoのようなアプリ内に留めておくべきで、インターネット上に自由に広がるべきではない」という考え方だ。一方Sunoは、ユーザーがより広く楽曲を共有・配布できる環境を求めている。 興味深いのは、各レーベルの対応が微妙に異なる点だ。Warner Music Groupは2024年の著作権訴訟を取り下げ、Sunoとライセンス契約に至った。このライセンスでは、プログラムにオプトインしたアーティストの声・名前・肖像・楽曲をユーザーが活用できる仕組みになっている。 一方UMGは、競合のAI音楽ツール「Udio」とは契約を結んでいるが、その内容は「ダウンロード禁止」という制約付きだ。つまりUMGはAI音楽自体を完全否定しているわけではなく、「閉じた環境での利用」に限って認める立場を取っている。 著作権訴訟という背景 2024年、UMG・Sony・Warner Recordsの3社はSunoを著作権侵害で提訴した。アーティスト代表者たちも「Say No to Suno」と題した公開書簡に署名し、「同プラットフォームは許諾なく世界の文化的成果物を学習データとして収集し、その作品と競合するビジネスを構築した」と批判している。 この訴訟背景があるからこそ、現在のライセンス交渉は単なるビジネス交渉ではなく、「AI音楽の法的・倫理的枠組みをどう定めるか」という産業全体の議論に直結している。 実務への影響——エンジニアとIT管理者が注目すべき点 この問題はエンターテインメント業界だけの話ではない。AI生成コンテンツの権利関係は、あらゆる業界のIT担当者が向き合うべきテーマになりつつある。 今すぐ確認すべきこと: 社内で利用しているAIツール（音楽・画像・テキスト問わず）の利用規約を改めて確認し、生成物の社外利用・配布が許可されているかチェックする クリエイティブ業務でAI生成コンテンツを活用している場合、商用利用の可否と著作権の帰属を明確化しておく 「ライセンスあり」のサービスと「訴訟係争中」のサービスを社内ポリシーで区別する運用を検討する SunoとUMGの交渉結果は、今後のAI生成コンテンツ利用の「業界標準」を形成する可能性がある。どちらかが折れた場合、その条件が他のAI音楽サービスや、ひいては画像・映像・文章生成ツールの契約モデルにも波及するだろう。 筆者の見解 この対立の本質は、コンテンツの「閉じた利用」と「開いた流通」のどちらに価値があるか、という根本的な問いだ。 レーベル側の懸念は理解できる。AI生成楽曲がネット上に無制限に広がれば、既存アーティストの楽曲と混在し、偽物・模倣品が検索結果を汚染するリスクがある。著作権管理の観点から「アプリ内完結」を求めるのは、一つの合理的な回答だ。 ただ、「閉じることで守る」戦略に頼りすぎると、本来持っているはずのビジネスチャンスを自ら手放すことにもなりかねない。Warnerがオプトイン型のライセンス契約に踏み切ったことは、「管理しながら流通させる」という現実的な道があることを示している。 AI技術は止まらない。禁止や封鎖は短期的な防御にはなるが、長期的には回避される。それよりも、使われることを前提にした仕組みの設計——ロイヤリティ分配モデル、透明性のある学習データ開示、オプトイン／アウトの整備——に早く移行した方が、業界全体として健全だと思う。 今後数年で、この議論の決着が「AIとクリエイティブ産業の共存モデル」の雛形になる。どう転んでも、現場のIT担当者と法務担当者がアンテナを張っておくべき領域であることは間違いない。 出典: この記事は Suno and major music labels reportedly clash over AI music sharing の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIブームが投資の世界を塗り替えている。これまで「ホットなスタートアップへの投資」とは、一流VCのファンドに入れてもらうことを意味していた。ところが今、その構図が急速に変わりつつある。超富裕層のファミリーオフィスがVCというミドルマンを飛び越え、AI関連スタートアップのキャップテーブルに直接名前を連ねようとする動きが加速している。 なぜ今、ファミリーオフィスが動くのか 投資顧問会社Arena Private Wealthの創業者ミッチ・スタインはその背景をこう説明する。「企業が非公開のままでいる期間が長くなり、IPOの件数も歴史的に見て少なくなっている。大きな利益は企業が上場する前に生まれており、今のプライベート市場はAI銘柄が席巻している」。 実際、Arena Private Wealthは今年、AIチップスタートアップPositronの2億3000万ドル（約340億円）ラウンドを共同リードし、取締役会の席も獲得した。これは単なる資金供給者としての立場から「能動的な市場参加者」への転換を意味する。 2026年2月の一ヶ月だけでも、ファミリーオフィスがスタートアップへ直接行った投資は41件に上り、そのほぼすべてがAI関連だった。著名な例を挙げれば、ローリン・パウエル・ジョブズのEmerson CollectiveがWorld Labs（空間知性AI）へ、Azim PremjiのファミリーオフィスがRunwayへ、エリック・シュミットのHillspireがGoodfireへと出資している。BNYウェルスの調査によれば、ファミリーオフィスの83%が「今後5年間の最重要戦略優先事項はAI」と回答しており、半数以上がすでにAI関連投資へのエクスポージャーを持っているという。 「乗り遅れること」が最大のリスク Arenaのオルタナティブ責任者アリ・ショッテンスタインは、今この瞬間に投資する緊急性をこう語る。「世界のAIインフラは今まさに建設されている。今早期に参入してプライマリー投資の機会を積み重ねるか、それとも乗り遅れてランダムな賭けをするか、そのどちらかだ」。 スタインの言葉はさらに直截だ。「最大のリスクはAIへのエクスポージャーを持っていないことであって、AI投資で何が起きるかではない」。 さらに一歩進んで、自社でAI企業を孵化させ、シード資金を出し、経営的な役割まで担うファミリーオフィスも出てきている。ジェフ・ベゾスが自身のロボティクス企業のCEOに就き、昨年62億ドルを調達したのはその最も高名な例だ。より小規模な例として、元Silicon Labs CEOのタイソン・タトルは自社ファミリーオフィスから500万ドルを投じて製造・物流向けAIスタートアップCircuitを共同創業した。 日本のエンジニア・IT管理者にとっての意味 この投資トレンドが示す本質は、AIを「使うか使わないか」という段階はとっくに終わり、「インフラをどう手に入れるか」という競争局面に世界が突入しているということだ。 日本のIT現場への影響という観点では、いくつかの点が重要になる。 AIインフラの選択肢が急速に広がる: PositronのようなAIチップ専業スタートアップへの巨額投資は、NVIDIAに依存しない代替GPUエコシステムの形成を加速させる。コスト構造が変われば、中小規模のシステムでも本格的なAI推論基盤を手が届く価格で調達できる未来が見えてくる。調達戦略の多様化は今から検討しておく価値がある。 エンタープライズAI調達の判断速度が問われる: ファミリーオフィスの動きが示すように、「評価してから投資」では遅すぎる時代が来ている。企業のIT部門も同様で、PoC（概念実証）を長期間回し続けるスタイルは通用しなくなる。「スモールスタートでも本番環境に出す」サイクルを早める組織的な仕組みが求められる。 AI専門人材の市場価値は今後さらに高騰する: 直接投資家として経営に関与するファミリーオフィスは、スタートアップ側の人材確保にも積極的に関与する。グローバルな資本がAI人材の争奪に本格参入することで、国内IT市場の採用環境は一段と厳しくなることを想定しておきたい。 筆者の見解 この話を読んで思うのは、「AIのインフラは今まさに建設中」というくだりの重みだ。これは資本の世界だけの話ではない。テクノロジーの使い手にとっても、まったく同じことが言える。 今この瞬間、AIエージェントの実行基盤、マルチエージェントのオーケストレーション、自律的にループで動き続ける仕組みの設計——これらはまだ「先進的な取り組み」として語られるが、2〜3年後には「やっていて当たり前」になっているはずだ。投資家が「乗り遅れることが最大のリスク」と言うなら、エンジニアの世界でも同じ構造がある。 日本の企業の多くはまだ「AIを試している」段階に見える。だがグローバルな資本は「AIインフラの完成後には乗り遅れる」と判断して、今を最重要タイミングと位置づけて動いている。その認識ギャップは、放置すれば技術力の差ではなくスピードの差となって表面化する。 ファミリーオフィスが「能動的な参加者」になったように、エンジニアもIT管理者も「AIを評価する立場」から「AIを使って仕組みを回す立場」に自分を置き換えるタイミングは、すでに今だ。情報を追い続けることよりも、実際に手を動かして成果を出す経験を積む——それが今この局面で最も価値のある時間の使い方だと筆者は考える。 出典: この記事は The AI gold rush is pulling private wealth into riskier, earlier bets の内容をもとに、筆者の見解を加えて独自に執筆したものです。

何が起きたのか Amazonは先日、UberがAWSとの契約を拡大し、ライドシェア機能の多くをAmazon独自設計のチップ上で稼働させると発表した。具体的にはARMベースのサーバーCPU「Graviton」の利用拡大と、AmazonのNvidia対抗AIアクセラレーター「Trainium3」の試験導入が柱となる。 注目すべきは、UberはついこのあいだまでOracleとGoogle Cloudを主軸に据えていたという点だ。2023年にはこの2社と複数年の大型クラウド契約を結び、自社データセンターからの脱却を宣言したばかり。にもかかわらず、わずか3年足らずでAWSに大きく舵を切った。 AWSの独自チップ戦略とは GravitonとTrainium——「脱Nvidia」の現実解 AWSが自社設計チップに力を入れ始めてからしばらく経つが、ここにきてその戦略が実を結びつつある。 GravitonはARM命令セットをベースにしたサーバーCPUで、電力効率に優れ、同等性能のx86サーバーと比較してコストパフォーマンスが高い。Uberは以前からARM系チップの導入実績があり（OracleクラウドのAmpereチップを活用）、アーキテクチャ上の親和性が高い。 Trainium3はAI/ML推論・学習に特化したアクセラレーターで、AmazonはNvidiaのGPU需要逼迫という市場構造を巧みに活用。すでにこのビジネスは数十億ドル規模に達していると報じられており、AppleやOpenAI、そして大手AIスタートアップなど名だたる企業がAWSのチップ上でワークロードを走らせている。 Oracle・Ampere・SoftBankが絡む複雑な背景 この話にはもう一つ、見逃せない文脈がある。Uberが以前使っていたORacle CloudのARMチップ「Ampere」は、元Intelの大物Renée Jamesが創業した企業が設計したものだ。OracleはかつてAmpereの約3分の1の株式を保有していたが、昨年末にSoftBankがAmpereを買収。OracleはプレタックスベースでAmpereの持ち分を27億ドルで売却し、その資金でNvidiaチップの大量購入に転じている。 Oracle自身も今やOpenAIやStargateプロジェクト向けのデータセンター建設に資金を集中しており、チップを自社設計することに競争優位を見出せなくなったとEllison CEOは明言している。 この複雑なシリコンバレーの利害関係の網の中で、AWSはひっそりと「自社チップを持ち、かつクラウドとして提供できる」という独自ポジションを確立してきた。 実務への影響——日本のエンジニア・IT管理者に伝えたいこと ARMへの移行を真剣に評価すべき時期 Uberのような大規模ワークロードがARM系チップに移行するのは、単なる話題にとどまらない。x86前提のソフトウェアスタックを持つ企業は、今後クラウドコストの最適化を議論するたびにARMへの対応が議題に上がることになる。コンテナ（特にDocker / Kubernetes）環境ではマルチアーキテクチャビルドへの対応が実務的な課題として浮上する。 具体的な行動として以下を検討してほしい。 AWS Gravitonインスタンスの試験導入: EC2のGravitonインスタンスは同等スペックのx86比で最大40%のコスト削減をうたっており、ステートレスなAPIサーバーやバッチ処理から試すのが現実的 マルチアーキテクチャ対応の確認: CI/CDパイプラインでARM向けビルドが通るか確認する。GitHub ActionsやAWS CodeBuildはGraviton上での実行をサポート済み AIワークロードのチップ選定は「Nvidiaだけ」前提を外す: Trainium / Inferentiaは推論コストでNvidiaに対して競争力を持つケースが出てきている。用途・ボリュームによっては検討する価値がある クラウド戦略の見直し——マルチクラウドの「摩擦」に注意 2023年にUberがOracle+Google Cloudというデュアルクラウドを選んだ理由はリスク分散と競争原理の活用だった。それが3年でAWSへの集約に向かいつつあるという事実は、マルチクラウド戦略が想定より運用コストを押し上げたことを示唆している。 「部分最適の積み重ねは全体として高コストになる」という現実は、規模は違えど国内企業にも共通する。クラウド選定は初期の安さや機能の多さだけでなく、エコシステムの一貫性・運用コスト・チップ戦略まで含めた視点で評価することが重要だ。 筆者の見解 AWSが自社設計チップでここまで大手企業を次々と引き寄せている構図は、クラウド業界における「垂直統合の再評価」を象徴していると思う。シリコン・クラウド・ソフトウェアを一気通貫で設計・提供できる事業者が、長期的なコスト競争力と顧客ロックインの両方を手に入れる——これはAppleがデバイス領域でやってきたことと本質的に同じ話だ。 Nvidiaの強さは揺るぎないが、「NvidiaのGPUをクラウドで借りる」というモデルは、Nvidiaへの依存と高コストを両方抱えることを意味する。AWSがTrainiumで十分なエコシステムを作り上げれば、AIワークロードの経済合理性が大きく変わる可能性がある。 日本企業に伝えたいのは「情報を追うことより、実際に使って成果を出すこと」というシンプルなメッセージだ。Gravitonインスタンスを1台試すのは数時間もあればできる。Trainium3の動向を観察しながら、自社のAIワークロードがどのチップで最もコスト効率よく動くかを実験ベースで把握しておくことが、これからのエンジニアに求められる実践的なリテラシーになる。 クラウドとチップの覇権争いはまだ序章だ。「どのクラウドを選ぶか」という意思決定が「どのチップ・どのAIエコシステムを選ぶか」と不可分になっていく時代が、確実に近づいている。 出典: この記事は Uber is the latest to be won over by Amazon’s AI chips の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIインフラへの資金流入が止まらない。シンガポールに本社を置くデータセンター企業Firmusが、Coatue主導の新ラウンドで5億500万ドル（約750億円）を調達し、評価額55億ドル（約8200億円）に到達した。わずか6ヶ月で総調達額は13億5000万ドルを超える。Nvidiaが出資企業に名を連ねるこの急成長企業が、アジア太平洋地域のAIコンピューティング地図を大きく書き換えようとしている。 「Project Southgate」——省エネAI工場の野望 Firmusが手がけるのは、オーストラリア本土とタスマニア島を拠点とした「AIファクトリー」ネットワークだ。同社はこれを「Project Southgate」と呼ぶ。 技術面で注目すべきは、Nvidiaのリファレンスデザインを採用している点だ。単にNvidiaのGPUを導入するだけでなく、データセンターの設計・冷却・電力管理まで含めた「Nvidiaが推奨する構成そのまま」で構築する。このアプローチは冗長性を排除し、最大限の効率化を実現できる。道のド真ん中を歩く手法といえる。 さらに、次世代AIコンピューティング基盤としてNvidia Vera Rubinプラットフォームの採用が予定されている。Vera RubinはBlackwellアーキテクチャの後継となる最新世代で、2026年後半の出荷が見込まれている。競合他社がBlackwell世代の展開に追われている今、Firmusは次世代で先行しようとしている。 「ビットコイン冷却」から「AI工場」への転身 Firmusの出発点は、ビットコインマイニング向けの冷却技術だった。これは偶然ではない。暗号資産マイニングは電力と熱管理の極限エンジニアリングであり、AIデータセンターに求められる技術と本質的に重なる。発熱密度の高いGPUクラスタを効率よく冷やし、電力コストを最小化する——この課題への解答を、Firmusはマイニング時代に培っていた。 暗号資産バブルの中で独自技術を磨き、AIブームで再浮上する。この転身パターンは投資家に強く刺さっており、「crypto-roots-turned-AI」企業として市場の熱狂を集めている。 実務への影響——日本企業はアジアのAIインフラ動向を無視できない 日本のエンジニアやIT管理者にとって、この動きはいくつかの実践的な示唆を持つ。 ①クラウドの「下の層」に何が起きているかを把握する AWS・Azure・Google Cloudのアジアリージョンは、こうした独立系AIデータセンター事業者の基盤整備に間接的に影響を受ける。電力・冷却・ネットワーク帯域の需要が集中する地域が変わると、クラウドリージョンの選択肢と価格に波及してくる。インフラコストを見積もる際には、上位レイヤだけでなく「誰がその土台を作っているか」まで視野を広げるべき時期に来ている。 ②オンプレミスAI基盤を検討している企業への参考事例 Firmusの設計思想——Nvidiaリファレンス準拠・省電力・高密度冷却——は、自社AIサーバーを検討している日本企業にも参考になる。「とにかく最速で大量に」ではなく「電力効率と冷却設計をセットで考える」という視点は、国内の電力制約が厳しい環境では特に重要だ。 ③Vera Rubin世代に備えた計画策定 2026年後半にVera Rubinが量産体制に入ると、Blackwell世代のGPUは価格・調達面で有利になる可能性がある。次世代移行のタイミングを見据えつつ、現在世代での実験・学習に投資するという判断は合理的だ。 筆者の見解 Firmusのようなプレイヤーが急速に評価額を伸ばしている背景には、単純な「AIブームへの期待」以上のものがある。AIエージェントが自律的に処理を実行し続ける世界では、コンピューティングリソースは「使いたいときに爆発的に」ではなく「常時・安定的に・大量に」必要となる。そのインフラを誰が握るかは、今後10年のパワーバランスに直結する。 アジア太平洋地域でこの種の投資が進んでいることは、日本にとって地政学的にも無関係ではない。日本国内でのAIコンピューティング基盤の整備は決して十分とはいえず、企業や研究機関がAIを本格活用しようとした際に「処理できる場所がない」という問題は想像以上に深刻になりうる。 省エネ型AI工場というコンセプトは正しい方向性だと思う。ただし、資金と技術があっても「どこに建てるか」「電力をどう確保するか」という物理的制約は容赦なくかかってくる。タスマニアという選択肢に水力発電の豊富さが見え隠れするように、再生可能エネルギーとの地理的組み合わせが今後のAIインフラ競争の重要変数になる。日本もこの視点で自国のAI産業競争力を問い直す機会がもっとあっていいはずだ。 出典: この記事は Firmus, the ‘Southgate’ AI data center builder backed by Nvidia, hits $5.5B valuation の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIが「脆弱性を見つける側」に回ったとき、サイバーセキュリティの地政図は根本から塗り替わる。Anthropicは2026年4月、そのことを業界に突きつける形で Project Glasswing を発表した。Amazon Web Services、Apple、Broadcom、Cisco、CrowdStrike、Google、JPMorganChase、Linux Foundation、Microsoft、NVIDIA、Palo Alto Networksという錚々たる顔ぶれが参画するこの取り組みは、単なる共同声明ではない。AIによる攻撃能力が実用段階に達した今、防御側が先手を打つためのラストチャンスという緊張感がある。 Mythos Preview——「人間を超えた」の意味 プロジェクトの中核に置かれているのは、Claude Mythos Previewと呼ばれる未公開のフロンティアモデルだ。このモデルはすでに、主要なオペレーティングシステムとウェブブラウザすべてを含む範囲で、数千件の高深刻度脆弱性を発見済みだという。 注目すべきは「どれだけ多くの脆弱性を見つけたか」ではなく、「ほんの一部の熟練セキュリティ専門家しかできなかった作業をAIが置き換えた」という質的変化だ。これまで脆弱性の発見は、膨大な経験と直感を持つ少数の研究者にしかできなかった。コスト・時間・専門性の三重の壁が、攻撃側のハードルでもあった。AIはその壁を一気に引き下げる。 なぜ今、業界横断なのか 問題の本質は「攻撃AIが悪意ある組織に渡る前に、防御側がAIを使いこなせるか」という時間との勝負にある。国家支援の攻撃者（中国・イラン・北朝鮮・ロシアが例示されている）は、すでに高度なリソースを持っている。AIが攻撃力の民主化を進めれば、小規模な組織や個人でも病院や学校を麻痺させられるレベルの攻撃が可能になりかねない。現在でもサイバー犯罪の世界的コストは年間5000億ドル規模と推定されている。 Anthropicは、Mythos Previewのアクセスを40以上の重要インフラ関連組織に提供し、ファーストパーティ・オープンソース双方のシステムをスキャンできるようにする。さらに最大1億ドル相当のクレジットと400万ドルのオープンソースセキュリティ団体への寄付をコミットしている。 実務への影響——日本のエンジニア・IT管理者が知っておくべきこと 1. OSS依存のリスク評価が変わる Project Glasswingの対象にはオープンソースのコードベースが明示的に含まれる。自社プロダクトに組み込んでいるOSSライブラリに未発見の脆弱性が眠っている可能性が、今後急速に可視化されていく。SBOMの整備と定期的なスキャン体制を今から構築しておくべき局面だ。 2. 「脆弱性発見はスペシャリストの仕事」という前提が崩れる AIベースのスキャンツールが整備されれば、従来なら外部ペンテスト会社に依頼していた作業の一部を内製化できるようになる。逆に言えば、ツールを使いこなせない組織との格差が拡大する。セキュリティエンジニアの役割は「脆弱性を見つける人」から「AIが見つけた脆弱性を評価・トリアージして対処する人」へ移行していく。 3. Microsoft製品を使っている組織は動向を注視せよ MicrosoftはProject Glasswingの立ち上げパートナーとして名を連ねている。WindowsやAzureに関連する発見事項が今後どのようなタイムラインでパッチ提供されるか、またMicrosoftがDefender等の自社セキュリティ製品にMythosの知見をどう統合してくるかは、M365やAzureを使う日本企業にとって直接的なインパクトになる。 筆者の見解 AIが自律的にコードを読み、脆弱性を見つけ、さらにその悪用方法まで推論できる——これは「そのうちそうなる話」ではなく、すでに起きていることだ。Project Glasswingが示すのは、その能力が特定の研究者の手元だけにある段階は終わったという事実である。 重要なのは「防御側がこのAIを使えるか」という問いだ。攻撃側が同等あるいはそれ以上のAIを手にすることは、もはや時間の問題に過ぎない。業界横断でアクセスを広げ、発見情報を共有するというアプローチは、オープンソースセキュリティコミュニティが長年実践してきた「脆弱性の公開と修正の高速化」と同じ思想の延長線上にある。方向性として正しいと思う。 AIエージェントが自律的にループで動き続け、コードを分析し、脆弱性を検出し、修正案を提示する——こうした仕組みが整備されれば、セキュリティの「攻守バランス」は初めて防御側に有利に傾く可能性がある。そこに本当のチャンスがある。 一方で、懸念もある。このような強力なモデルへのアクセスが、実態として大手パートナー企業に集中するなら、中小企業や行政機関、そして多くの日本企業は「守られる側」に留まり続けるリスクがある。Glasswingが真に業界全体を底上げするには、アクセスの民主化と、発見された脆弱性情報の迅速な共有プロセスが不可欠だ。プロジェクトの初動として打ち出した姿勢は評価できる。あとはその約束がどこまで実行されるか、継続的に注目したい。 出典: この記事は Project Glasswing: Securing critical software for the AI era の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年4月初旬、ニューヨーク・タイムズが掲載したある記事がSNSを席巻した。「1人の創業者が、わずか2ヶ月・2万ドルのブートストラップで、バイブコーディングだけを武器に評価額18億ドルの企業を作り上げた」——AIが可能にした次世代の起業神話、として熱狂的に拡散された。だがその熱狂の裏側には、報道が十分に掘り下げなかった重大な「別の顔」が存在していた。 Medviとは何か——表の顔と裏の実態 Medviは医療系AIスタートアップとして紹介されており、AIツールを駆使して少人数（あるいは1人）で急成長したという物語が独り歩きした。しかし記事公開直後から、複数の調査者や法律専門家がSNS上で疑義を呈し始めた。 最も深刻な指摘は、カリフォルニア州反スパム法違反のクラスアクション訴訟だ。訴状によれば、Medviのアフィリエイトマーケターは偽装されたヘッダー情報・なりすましドメイン・無意味な送信元アドレスを使ってスパムフィルターを回避し、さらに虚偽・欺瞞的な件名を使用していたという。これはアフィリエイトが勝手にやった話ではなく、ビジネスモデルの構造的問題として指摘されている。 さらに遡ると、2025年5月の時点でFuturism誌がすでにMedviの事業モデルを詳細に分析していた。このFuturism記事を掘り下げたYouTubeチャンネル「Voidzilla」は、Medviを「詐欺まがいプラットフォームの上に乗った詐欺レイヤー」と描写。収益報告の信憑性にも疑問を呈し、「なぜこれだけが本当のことを言っていると思えるのか」と指摘する声も上がっている。 なぜこれが重要か——「AI成功物語」の検証責任 この件が示すのは、テクノロジー報道における「AIハイプへの無批判な加担」というリスクだ。 ニューヨーク・タイムズほどのメディアが、すでに公開されていたFuturismの批判的分析を参照せずに記事を書いたという事実は重い。「AIが可能にした一人勝ち」という物語のインパクトが、取材の深さを上回ってしまったのだ。 日本でも状況は同様だ。「ChatGPTで業務効率化」「AIエージェントで〇〇倍速」といった煽り文句が飛び交い、ツールの裏側にある実態——コンプライアンス、データ管理、持続可能性——が問われないまま礼賛される事例は少なくない。 AIは確かに、かつてなら数十人規模のチームが必要だった仕事を少人数で実現できるようにしている。これは本物の革命だ。しかし「AIが成功の主役」という物語が、事業の倫理的問題や法的リスクを隠蔽する煙幕になりうる点には注意が必要だ。 実務への影響——AI活用の「裏面デューデリジェンス」 この事例はAIを使う側にも教訓を与えてくれる。 ベンダー・パートナー選定時のAI系スタートアップ評価では、以下の視点を忘れずに持つべきだ。 収益の出所を確認する: 「評価額」はあくまで投資家の期待値。実際の収益モデル・マーケティング手法が適法かどうかを問う コンプライアンス体制の有無: スパム送信・データ取り扱い・プライバシーポリシーは、AIの性能とは別に確認が必要な基本事項 メディア報道を鵜呑みにしない: バズった記事の「裏」を検索するだけで、見え方が大きく変わることがある。Futurismの記事は無料で読めた アフィリエイトやパートナーの行動もブランドリスク: 自社が直接関与していなくても、流通ネットワーク全体の行為は法的・評判リスクとして跳ね返ってくる IT管理者・調達担当者は、AIを活用していると謳う外部サービスを導入する際、技術的な評価と同時に法的・倫理的なデューデリジェンスを標準プロセスに組み込むことが今後ますます重要になる。 筆者の見解 AIが仕事のあり方を根本から変えていることは疑いようがない。少数の「仕組みを作れる人」が、AIを使って圧倒的なアウトプットを実現できる時代は確実に来ている——というか、もう来ている。その文脈でMedviのような事例が「成功の象徴」として語られることには、根っこに本物の変化がある。 だからこそ、この件が残念だ。 AIが本当に可能にしているものは素晴らしい。だが「AIで成功した」という物語を使って、不正スレスレのマーケティングや疑わしい収益構造を覆い隠すことができるとしたら、それはAIそのものへの不信感を増幅させる。Medviが訴えられているのはAIのせいではないが、NYタイムズの報道が批判的視点を欠いていたことで、「AIすごい→Medviすごい」という短絡が生まれてしまった。 技術メディアも、読者も、そして私自身も含めて——「すごいAI事例」を見たとき、一度立ち止まって問いを立てる習慣が今必要だと思う。「何がAIによって実現されていて、何がそうでないのか」を切り分ける冷静な目こそ、AI時代のリテラシーの核心ではないだろうか。 実際に手を動かして使い倒している人間ほど、ハイプには乗りにくくなる。情報を追いかけるよりも、自分で使って成果を出す経験を積む——それが最も確実なAIリテラシーの育て方だと、改めて感じさせられた事例だった。 出典: この記事は The back story behind the first “$1.8B” dollar “AI Company” の内容をもとに、筆者の見解を加えて独自に執筆したものです。

アポロ11号の誘導コンピュータ（AGC）コードに、57年間見逃されてきたバグが発見された。月面着陸という人類史上最大の偉業を支えたソフトウェアに、いまも未解決の欠陥が眠っていたとは——AIを活用した形式仕様検証の力を示す、驚くべき事例だ。 アポロ誘導コンピュータとは AGCは1969年、アポロ11号の月面着陸を実現した誘導制御コンピュータだ。わずか2KBの消去可能RAM、1MHzクロックという今では信じられないスペックで、月への飛行経路計算と着陸船の制御を担った。 コードは74KBの「コアロープメモリ」に格納されていた。磁気コアに銅線を手で通す、まさに手作業の記憶装置だ。製造を担った女性技術者たちは社内で「Little Old Ladies」と呼ばれ、このメモリは「LOLメモリ」とも呼ばれた。プログラムはハードウェアそのものに物理的に織り込まれていた。 ソースコードは2003年にMITのプリントアウトからボランティアが手入力で復元し、2016年にGitHubで公開されると大きな話題となった。以降、数千人の開発者がアセンブリコードをレビューし、エミュレータが一命令ずつ実行し、学術論文が信頼性を分析してきた。それでも、バグは潜み続けた。 発見された57年間のバグ バグを発見したのは、英国のソフトウェア会社JUXTのチームだ。彼らはAIと自社開発のオープンソース行動仕様言語「Allium」を組み合わせ、13万行のAGCアセンブリコードから1万2500行の仕様書を自動生成した。そのプロセスが欠陥に直接たどり着いた。 バグはIMU（慣性計測ユニット）サブシステムのジャイロ制御コードにある。AGCはジャイロスコープをトルク制御する際にLGYROという共有リソースロックを取得し、3軸すべての制御完了後にロックを解放する。 問題は「ケージング」時の処理だ。ケージングとはIMUのジンバルを物理的に固定する緊急措置で、クルーがコックピットのスイッチで操作できた。通常の完了パスではロックが解放されるが、ケージング発生時の終了ルートBADENDには、ロックをクリアする2命令が抜けていた： 出典: この記事は We found an undocumented bug in the Apollo 11 guidance computer code の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIツールが「みんな同じ文章」を生み出している？ 南カリフォルニア大学（USC）ドーンサイフ校の研究チームが、興味深い問いを投げかけている。生成AIの普及によって、私たちの思考パターンや文章スタイルが均質化しつつあるのではないか、というものだ。Hacker Newsでも200点以上の注目を集め、200件超のコメントが飛び交ったこの研究は、AIツールが当たり前になりつつある今、無視できない視点を提供している。 なぜ「均質化」が起きるのか 生成AIはその仕組み上、大量のテキストデータから「統計的に自然な」出力を生成する。言い換えれば、「平均的で受け入れられやすい表現」に最適化されている。ユーザーがAIに文章を書かせたり、下書きの添削を頼んだりするたびに、その出力は訓練データが反映する「多数派の文体」に引き寄せられていく。 このプロセスが社会的に大規模に起きると何が起こるか。個々の書き手が持っていた独自の語彙選択・論理展開・表現癖が薄れ、「AIらしい整然とした文章」が世の中に溢れることになる。思考の多様性は言語の多様性に支えられている部分が大きく、文体の収束は思考様式の収束を招きやすい。 日本のIT現場への影響 日本では、AIによる文書作成支援ツールの導入が急速に広がっている。報告書・提案書・メール・議事録……あらゆるビジネス文書がAIを経由するようになれば、部署や会社をまたいで「同じ雰囲気の文章」が流通することになる。 実務上の注意点をまとめる： AIの出力はドラフトとして扱う: 最終的な言葉選びは自分の判断で変える習慣をつける。AIが提案した表現を「なぜこの言葉か」と意識的に問い直すだけで、思考筋は維持できる 重要な意思決定は自分の言葉で言語化する: アイデア出しや戦略立案の場面では、まず自分の考えをメモしてからAIに投げる。順序を逆にしない チームの多様な視点を意識的に保護する: レビューや議論の場でAI生成文書を「参考資料」として扱い、議論そのものをAIに委ねない AIが整えた文章の「のっぺり感」を検出する: 読み手として均質化した文章を識別できる眼を養うことが、書き手としての差別化につながる 筆者の見解 この研究が示す問題は、ツールの問題ではなく使い方の問題だと私は見ている。AIが「副操縦士」として常に手を貸し続ける設計になっていると、人間が主体的に考える場面がどんどん減っていく。自分で問いを立て、自分の言葉で仮説を組み立て、AIにはその検証や整形を任せる——この順序を守るかどうかで、思考の独自性は大きく変わる。 均質化のリスクは、AIを「文章の自動生成装置」として使う人ほど高くなる。一方、AIを「思考の加速装置」として設計できる人には、均質化の罠は近づきにくい。情報を大量に追いかけることよりも、自分で実際に手を動かし成果を出す経験を積む方が今は正しい——そう考えている私にとって、この研究は「使い方次第だ」という信念を改めて確認させてくれるものだった。 思考の多様性は、意図して守らなければ静かに失われる。AIが当たり前になった時代だからこそ、「自分はどう考えるか」を先に問う習慣の価値は、むしろ上がっていると思う。 出典: この記事は AI may be making us think and write more alike の内容をもとに、筆者の見解を加えて独自に執筆したものです。

複数のAIエージェントを安全な環境で同時並行に動かす──そんな基盤への需要が急速に高まるなか、Googleがその解の一形態を示した。実験的マルチエージェント・オーケストレーション基盤「Scion」が先日オープンソースとして公開された。 Scionとは──「エージェントのハイパーバイザー」 Scionが掲げるコンセプトは「エージェントのハイパーバイザー」だ。仮想マシンを管理するハイパーバイザーと同じように、Scionは複数のAIエージェントの生成・調整・終了を統括する。 具体的には以下を実現する： コンテナによる完全分離: 各エージェントはDockerやPodmanなどのコンテナで動作し、独自のgitワークツリーと認証情報を持つ。複数エージェントが同じプロジェクトで並列作業しても互いに干渉しない 動的なエージェントライフサイクル管理: 長期稼働する専門エージェントと、単一タスクに紐づく一時的なエージェントを混在させられる 並列タスクグラフの動的進化: コーディング・監査・テストといった異なる目的のタスクを並列に実行しながら動的に変化させられる 実行環境はDocker、Podman、Appleコンテナ、Kubernetesに対応し、ローカル・リモートVM・Kubernetesクラスターをまたいで動かすことができる。 「制約より分離」という設計原則 Scionの設計で特筆すべきは「Isolation over Constraints（制約より分離）」という原則だ。 多くのエージェント基盤がエージェントの行動をルールやプロンプトで縛る方向に向かうのに対し、Scionは異なるアプローチを採る。エージェントに「–yoloモード」──必要なことを自由にさせながら、コンテナやネットワークポリシーという外側の境界でガードレールを設けるという発想だ。 この転換は重要な意味を持つ。内側からルールで縛ると、エージェントの自律性が損なわれ、結局は人間が細かく指示し続ける構造に逆戻りする。外側で物理的に分離することで、エージェントは本来の自律性を発揮しつつ安全性が担保される。 Scion固有の語彙体系 Scionを使いこなすには独自の概念体系を理解する必要がある： 用語 意味 Grove（グローブ） プロジェクトに相当する単位 Hub（ハブ） オーケストレーションの中央コントロールプレーン Runtime Broker ハブが動作するマシン Harness（ハーネス） エージェントのライフサイクル・認証・設定を管理するアダプター ハーネスを通じて現在対応しているエージェントはGemini CLI、Claude Code、OpenCode、Codexなど。後者2つは現時点でサポートが部分的だ。 デモゲーム「Relics of the Athenaeum」 Scionの能力を実証するデモとして、Googleは「Relics of the Athenaeum」というゲームのコードベースも公開している。このゲームでは複数のエージェントが異なるキャラクターを演じながら協力して計算パズルを解く。 ゲームランナーがキャラクター（エージェント）を動的にスポーンし、それらのエージェントがさらにワーカーや専門エージェントを生成するという構造は、実際のマルチエージェント開発基盤の雛形として参考になる。 実務への影響 現時点では実験的なプロジェクトであり、本番環境への即時採用を急ぐ段階ではない。ただし、今すぐ学べることは多い： アーキテクチャパターンとして参照する: コンテナでエージェントを分離する発想は、社内ツールや自動化パイプラインでも応用できる gitワークツリー活用を実践する: エージェントに独立したgitワークツリーを割り当てて並列作業を安全に進める手法は今すぐ取り入れられる ハーネス設計を研究する: エージェントのライフサイクル管理をアダプターとして切り出す設計は再利用性が高く、自社ツール開発の参考になる 日本企業での導入を考えると、Kubernetesとの統合やオンプレミス動作の実績が重要になる場面も多い。Scionがそのあたりをどこまでカバーしていくかが今後の注目点だ。 筆者の見解 「複数のAIエージェントを安全な環境で同時並行に走らせる基盤」が求められていることは以前から明らかだった。Scionはその答えの一つを具体的なコードとして示した点に価値がある。 特に「制約より分離」という哲学には強く同意する。エージェントの動作をプロンプトやルールで縛ろうとするアプローチは、どこかで必ず破綻する。物理的・インフラ的な境界で安全を確保しながら、エージェント自身には最大の自律性を与える──これが自律エージェントを本番で動かすための正しい方向性だと思う。 エージェントが自律的にループで動き続ける仕組み──タスクを受け取り、実行し、検証し、次のステップを判断するサイクルを繰り返すアーキテクチャ──こそが今のAI開発における最も重要なフロンティアだ。Scionはそのビジョンを実装しようとしている。 現時点では実験的な段階で、プロダクション採用はまだ先の話だろう。しかしマルチエージェント基盤の設計をこれから考えるなら、Scionのアーキテクチャを参照することは間違いなく有益だ。Googleがこの実験的基盤をどこまで発展させていくか、エコシステムの広がりとともに注目していきたい。 出典: この記事は Google open-sources experimental agent orchestration testbed Scion の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIコーディングツールの利用が日常的な業務フローに組み込まれ始めた今、認証まわりのトラブルは「少し不便」では済まない問題になりつつある。AnthropicのClaude Codeで、Windows環境（特にWSL）のGoogleログインが15秒タイムアウトで失敗し続けるバグが報告され、GitHubのIssue #44257には200件を超える反応が集まった。Hacker Newsでも200点超えのホットな話題となっている。 何が起きているか 問題の流れはシンプルだ。 Windows上でClaude Codeを起動 Googleアカウントでのサインインを開始 ブラウザでの認証を完了してアプリへ戻る アプリ側が OAuth error: timeout of 15000ms exceeded を返して失敗 何度リトライしても同じ結果 報告者のバージョンは 2.1.92。「以前は動いていたか不明」としており、突発的な不具合というよりは環境依存・設定依存の問題と見られている。 技術的な背景：WSLとOAuthリダイレクトの相性問題 WSL（Windows Subsystem for Linux）環境でOAuth認証が失敗するパターンは、過去にも多くのツールで起きてきた構造的な問題だ。 OAuth認証の典型的なフローでは、認証後にブラウザが localhost や特定のポートへリダイレクトしてトークンをアプリに渡す。しかしWSL内のプロセスとWindowsのブラウザは異なるネットワーク名前空間にあるため、このリダイレクトが届かないことがある。 WSL2では localhost のフォワーディングが自動化されているが、完全ではないケースがある ポートの待ち受け（127.0.0.1 vs 0.0.0.0）の違いが影響することも セキュリティソフトやWindowsファイアウォールがローカルポートをブロックしている場合もある タイムアウトが15秒という短さも問題で、WSLのネットワーク初期化やブラウザの起動が遅い環境では正常なケースでもギリギリになりうる。 実務への影響と対処法 この手の認証ブロックは「そのうち直る」と放置できないケースが多い。特にAIツールを自動化パイプラインや定期実行タスクに組み込んでいる場合、認証が切れた瞬間にフロー全体が止まる。 現時点で試せる対処法： APIキー認証を使う: Google OAuthではなく、Anthropic APIキーを直接設定する方法が最も安定している。環境変数 ANTHROPIC_API_KEY にセットするか、claude auth --api-key 相当の設定を使う WSLのネットワーク設定を確認: %USERPROFILE%\.wslconfig に [wsl2] networkingMode=mirrored を追加し、WindowsとWSLのネットワークをミラーリングする（WSLの比較的新しい機能） PowerShellまたはWindows Terminalから直接起動する: WSL経由ではなくWindowsネイティブ環境でのログインを試す ポート競合を確認: 認証に使われるローカルポートが他プロセスに使われていないか netstat -an で確認する 公式のIssueを追う: GitHub Issue #44257 をウォッチしておき、公式パッチを待つのが最善の場合もある 定期実行・自動化を組んでいる場合の重要な注意点： OAuthトークンは有効期限があり、長期実行のエージェントやcronジョブでは意図せず切れることがある。APIキー認証の方が自動化フローには向いており、こういったトラブルに巻き込まれにくい。 ...