Tech News JP

PC Watchの宇都宮充氏が2026年6月18日に報じたところによると、Adobeは同日、Fireflyのエージェント機能を大幅強化するとともに、Creative Cloud主要アプリケーションにクリエイティブエージェントを導入すると発表した。クリエイターが成果物を言葉で説明するだけで、AIアシスタントが複数のワークフローを自動で連続実行する仕組みだ。 なぜこの発表が注目か これまでのAI支援ツールは「提案して人間が承認する」という逐次確認モデルが主流だった。今回のFireflyアップデートが重要なのは、単一のチャットインターフェースから複数アプリをまたいで複数のワークフローを連続実行する、より自律的なエージェントモデルへの移行を明確に示した点だ。 「このビデオクリップを整理して、インタビュー部分を特定してマーカーを打って」という指示一つでPremiereが複数処理を順にこなし、「バッチで背景を削除してリサイズして」という一言でPhotoshopが大量のアセットを処理する。多段階タスクの自動実行こそが単なる生成AI機能との決定的な差だ。 海外レビューのポイント（PC Watch報道より） PC Watchの報道によると、今回のアップデートはパブリックベータとして提供開始される。 Fireflyアシスタントの新クリエイティブスキル ブランドキット、ショート動画、ストーリーボードの作成 キャラクター・オブジェクトをプロジェクト間で維持・再利用できる「エレメント」機能 アセット整理と作業再開を支援する「プロジェクト」機能 各アプリのAIアシスタント機能（パブリックベータ） アプリ 主な機能 Premiere クリップ一括リネーム、インタビュー質問の特定、マーカー追加 Photoshop バッチ背景削除、アセットリサイズ、自然言語によるコンポジット処理 Illustrator レイヤー再編成、印刷前のカラーモード・フォントエラー検出 InDesign ブランドガイドライン準拠のレイアウト自動更新 Frame.io 撮影アセット整理、リビジョンごとのフィードバック抽出、Bロール生成支援 正式リリース時期や追加アプリへの展開スケジュールは現時点では明らかにされていない。 日本市場での注目点 Creative Cloudは国内でも広く普及しており、今回のエージェント機能も同じサブスクリプション内で提供される見込みだ。Creative Cloud Pro 12カ月オンラインコード版はAmazon.co.jpなどで入手可能。 日本の映像プロダクションや広告代理店ではPremiere・Photoshop・Illustratorの同時利用が多く、複数アプリにまたがるバッチ処理の自動化はアシスタント作業の大幅削減につながりうる。特にFrame.ioとの連携によるレビュー管理効率化は、リモートワーク体制が定着した現場で実用価値が高い。 注意点は日本語対応の品質だ。英語前提で設計されたプロンプト解釈が日本語の指示でどこまで機能するかは、正式リリース後の実績を待つ必要がある。 筆者の見解 今回のAdobeの発表が示すのは、AIツール設計における重要な方向転換だ。「提案 → 人間が確認 → 実行」という逐次承認型から、「目的を伝えれば複数ワークフローを連続自動実行する」自律型エージェントへのシフトである。確認・承認を人間に求め続ける設計では、作業の中断が頻繁に発生し、生産性向上の上限が低くなる。Adobeが今回示した「どのアプリをどの順番でどう操作するかはエージェントが判断する」というモデルは、正しい方向性だと思う。 ひとつ意識しておきたいのは、ブランドキット・エレメント・プロジェクトといった新機能がCreative Cloudエコシステム内での作業継続性を高める一方、他ツールへの移行コストも上がる点だ。Adobeにとって合理的な戦略だが、ユーザー側は選択の自由度の変化として認識しておくべきだろう。 「言葉で指示して複数ワークフローを自動実行する」というコンセプトが業界標準になっていく流れは加速している。パブリックベータ期間中の動作品質と日本語対応の充実度を引き続き注視したい。 関連製品リンク 【Adobe公式】Creative Cloud Pro プレミアム生成AI Firefly搭載 動画/ 写真/ イラスト編集ソフト（最新）| 12ヵ月| パッケージコード版 上記はAmazon.co.jpへのリンクです。記事執筆時点の情報であり、価格・在庫は変動する場合があります。 出典: この記事は Fireflyがエージェントに進化。言葉で指示して作業を自動実行 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年6月末を目標に、Microsoft Teamsの会議中UIを全面刷新する。マイク・カメラ・画面共有などの主要コントロールが画面中央に集約されたシンプルなレイアウトに変更され、共有パネルにはライブプレビューと誤共有防止の確認ステップが追加される予定だ。 主要コントロールが中央に集約される 現在のTeams会議画面は、コントロールが分散していて操作性に課題があった。今回の刷新では、ミュート・カメラのオン/オフ・画面共有といった主要ボタンが画面下部中央にまとまったシンプルなレイアウトに統合される。会議中に「ミュートボタンがどこだったか」と焦るような場面が減ることが期待される。 共有パネルの再設計——ライブプレビューと誤共有防止 特に注目したいのが共有パネルの改善だ。新しい共有パネルでは、共有しようとしているウィンドウやアプリケーションのライブプレビューがその場で表示される。さらに共有を開始する前に確認ステップが追加される設計になっている。 これは地味に見えて実は重大な改善だ。「画面共有したつもりが別のウィンドウを映していた」「機密情報が映り込んだ状態で共有してしまった」といった誤操作は、日本のエンタープライズ環境でも頻繁に発生している。確認ステップの追加によって、このリスクを構造的に下げることができる。 同時期にM365 Copilotアプリも刷新 同じ時期に、Microsoft 365 CopilotアプリのUIも大幅に再設計される。MicrosoftのチーフデザインオフィサーJon Friedmanが掲げるデザイン思想のキーワードは次の3点だ。 プログレッシブディスクロージャー：最初はシンプルに表示し、必要に応じて機能を展開 アウトプットこそがUI：AI時代において最も重要な体験は、応答の質・トーン・読みやすさ Work IQ：メール・ファイル・チャット・会議の文脈を理解して適応するインテリジェンスレイヤー プロンプト入力欄が「タスク認識型ワークスペース」に進化し、Word・Excel・PowerPoint・Outlookをまたいだ一貫した体験を目指している。 そのほかの注目アップデート Microsoft Admin Center（MAC）のMessage Centerには、さらに多くの更新が含まれている。 Power BIのM365 Copilot統合：Copilot画面からPower BIレポートへアクセス可能になる Plannerエージェントの一般提供（GA）：プロジェクト管理のAIエージェントが正式リリース リアルタイム画面・カメラ共有（Copilot音声）：Vision機能として、音声会話中に画面やカメラ映像をCopilotと共有できるように Copilot in PowerPoint：「質問に備える」「プレゼンを確認する」「スライドをビジュアル化する」の3機能追加 SRT（Secure Reliable Transport）：Teams Town HallおよびLive Eventsの配信安定性が向上 実務への影響 展開時期の見極めを 2026年6月末のロールアウト目標とあるが、Microsoftの機能展開は地域・テナント規模・ライセンスによって時間差が生じる。MACのMessage Centerを定期チェックし、自テナントへの展開タイミングを事前に把握しておきたい。 UI変更はユーザーへの事前周知が必須 UIが変わると「突然変わった」と感じたユーザーからのヘルプデスク問い合わせが急増する。IT管理者は展開前に「何が変わるか」を簡単な社内向けガイドとして準備しておくとよい。共有パネルの確認ステップは特に、慣れたユーザーが「なんか増えた」と戸惑う可能性が高い。 誤共有インシデントの棚卸しのチャンス 新しい確認ステップが追加されるタイミングで、これまでの誤共有インシデントの記録を棚卸しし、セキュリティポリシーの見直しに活かすと良い。 筆者の見解 Teams UIの刷新は、率直に言って「ようやく」という印象だ。会議中の主要コントロールが中央集約されるのは、競合する会議ツールでは数年前から当たり前の設計だった。それが今回整理されるという事実は、UIデザインへの投資優先度がこれまで必ずしも高くなかったことを示しているかもしれない。Microsoftには統合プラットフォームとしての総合力があるのだから、こうした基本的な使い勝手の部分こそ先んじてほしかったというのが正直なところだ。 ただ、誤共有防止の確認ステップの追加は素直に評価したい。派手な機能追加より、「ミスを構造的に防ぐ設計」の方が、日本のエンタープライズ環境では遥かに価値がある。情報漏洩インシデントの多くは悪意ある攻撃ではなく操作ミスから生まれる。UIレベルでそのリスクを下げる仕組みは、セキュリティポリシーの実効性を高める。 M365 Copilotアプリの「プログレッシブディスクロージャー」というデザイン思想も方向性は正しい。AIツールは高機能になるほど、多くのユーザーにとって「何ができるのかわからない」という壁が高くなる。最初はシンプルに、必要な人には深い機能を——この設計原則が実際の利用率向上につながることを期待したい。今回のような積み重ねが、使い続けたいと思えるプラットフォームへの道になるはずだ。 出典: この記事は Microsoft Teams In-Meeting Experience Redesign and Sharing Panel Overhaul の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIがChatGPTの新メモリアーキテクチャ「Dreaming」を段階的に展開中であることを、Tom’s GuideのAmanda Caswell氏が詳細にレポートしている。これまでの「明示的に教えたことを記録する」方式から、会話を自動解析してユーザープロファイルを構築する方式へと大きく進化した今回のアップデート——しかし、記憶の全容をユーザーが把握できないという重要な注意点も明らかになった。 「Dreaming」とは何か これまでのChatGPTのメモリ機能は、ユーザーが「〇〇を覚えておいて」と明示的に指示した内容を記録するシンプルな仕組みだった。新しい「Dreaming」はその概念を根本から変える。 Tom’s Guideの報告によれば、Dreamingは過去の複数の会話を自動的に合成・解析し、ユーザーに関する情報を推論しながら継続的に更新するアーキテクチャだ。OpenAI自身が示した例では、「7月にシンガポールに行く」という記憶が、旅行後には自動的に「2026年7月にシンガポールに行った」へと書き換えられるという。ユーザーが改めて指示しなくても、文脈が変われば記憶も更新される。 今すぐ確認すべき設定 Caswell氏がまず確認することを推奨したのが以下の設定だ。 ChatGPT → 設定 → パーソナライゼーション → メモリ → チャット履歴を参照 この設定が有効な場合、ChatGPTは過去の会話を参照して将来の応答をパーソナライズする。スポーツチームの好み、食事制限、旅行計画、文章スタイル、キャリア目標といった情報が、ユーザーが改めて入力しなくても自動的に活用されることになる。 懸念点：記憶の全容が見えない Caswell氏の報告で特に注目すべき点が「記憶の透明性」だ。OpenAI自身が認めているように、メモリのサマリーページに表示される内容が、ChatGPTが実際に保持している記憶のすべてではない可能性がある。 これはこれまでの仕組みとの根本的な違いだ。以前は「記録された事実のリスト」として概ね全容を確認できたが、Dreamingでは会話から推論された内容もバックグラウンドで更新されるため、ユーザーが「何を知られているか」を完全に把握するのが難しくなる。 プライバシーコントロールの現状 一方でOpenAIは、ユーザーのコントロール手段も提供している。 メモリ機能全体を無効化できる 個別のメモリを削除・管理できる 「テンポラリーチャット」モードでは会話がメモリに反映されない Dreaming機能はまずアメリカのChatGPT PlusおよびProユーザーへ展開中で、無料ユーザーや海外ユーザーへの展開は数週間後になる見込みとのことだ。 日本市場での注目点 日本のChatGPTユーザーへの展開は「coming weeks」とされており、現時点で具体的なスケジュールはアナウンスされていない。ただしOpenAIの過去のパターンでは、グローバル展開は比較的早期に行われることが多い。 企業でChatGPTを業務利用している場合、ChatGPT EnterpriseやTeamsプランではメモリのポリシーが異なる可能性がある。業務上の機密情報の取り扱いについては、利用規約や組織のポリシーを改めて確認しておくことを推奨する。 個人利用においては、上述の「チャット履歴を参照」設定を自身の判断で見直すことが現実的な対応だ。 筆者の見解 AIアシスタントが「単発の会話」から「数週間・数か月にわたるコンテキストを持つパートナー」へと進化していく方向性は、時代の必然だろう。ユーザーの認知負荷を減らし、「また同じことを一から説明する手間」をなくすという設計思想は正しい。 ただ、今回のDreamingで浮上した「記憶の不透明性」は見過ごせない課題だ。AIが自律的に推論・更新するプロセスはブラックボックスになりがちで、OpenAI自身が「サマリーページには全部は表示されない」と認めている以上、ユーザーは「自分がどう理解されているか」を完全には把握できない状態に置かれる。 高度なパーソナライゼーションと透明性のトレードオフは、AIアシスタント業界全体が向き合うべき問題だ。Dreamingの技術的方向性は興味深いが、「記憶の監査可能性」という設計上の課題については今後のアップデートでの改善が期待される。便利さと透明性を両立させることこそが、ユーザーの長期的な信頼を獲得するカギになるはずだ。 出典: この記事は ChatGPT’s new memory builds a profile of you on its own — and OpenAI admits you can’t see all of it の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年6月、Azure FunctionsにLogic AppsおよびPower Platformで長年使われてきた1,400以上のマネージドコネクタをファーストクラスのトリガーとして利用できるプレビュー機能を発表した。ローコードツール専用だったコネクタのエコシステムが、コードファーストな開発者にも開かれた形だ。 マネージドコネクタとは Azure Logic AppsやPower Automateには、Microsoft 365・Salesforce・Slack・ServiceNowといった外部サービスと連携するための「マネージドコネクタ」が1,400種類以上用意されている。接続先の認証情報や通信処理をMicrosoft側が管理（マネージド）してくれるため、開発者は外部サービスの細かい接続仕様を自前で実装せずに済む。これまでこのコネクタ群はローコード・ノーコードの世界での利用が中心で、コードで書くAzure Functionsからは直接活用する仕組みが存在しなかった。 何が変わったか 今回のアップデートにより、Azure Functionsのトリガーとして1,400以上のマネージドコネクタを直接バインドできるようになった。「Office 365のメールを受信したときにFunctionを起動する」「SharePointにアイテムが作成されたらFunctionを呼び出す」「SalesforceのレコードがアップデートされたらFunctionをトリガーする」といった処理が、Logic Appsを中継せずにコードだけで実現できる。 これまで必要だったLogic Apps → Azure Functionsという2段構成を、Azure Functions単体に集約できるシナリオが生まれた。 対応トリガーの例 現在プレビューで利用できる代表的なトリガーは以下の通り： Office 365メール受信 — 特定条件のメールが届いたときにFunctionを起動 Microsoft Teamsへのメッセージ投稿 — チャネルへの投稿をトリガーに処理を実行 SharePointアイテム作成 — ドキュメントライブラリへのファイル追加などをトリガーに Salesforceレコード更新 — CRMのデータ変更をAzure側でリアルタイムに処理 現状のサポート範囲と今後 現在プレビューとして提供されているのはC#（.NET 10 Isolated Worker）のみ。PythonおよびNode.jsは「近日対応予定」とされている。Azure Functionsの実務利用でPythonやNode.jsを選んでいるチームも多いため、これら言語のサポートが出揃った時点が実質的な評価開始のタイミングになるだろう。 実務への影響 アーキテクチャの設計選択肢が広がる 「ちょっとしたイベント処理はコードで書きたいが、コネクタはLogic Appsのものを使いたい」というジレンマは、Azure開発の現場でよく耳にする話だ。今回の対応により、単純なイベント起動型の処理はAzure Functionsに集約し、複数コネクタ間の複雑なフロー制御や承認ワークフローはLogic Appsに任せる、という明確な役割分担が設計しやすくなる。 コスト面の検討ポイント Logic AppsとAzure Functionsでは課金モデルが異なる。Logic Appsはコネクタの種類と実行回数に応じた従量課金が発生するケースがある。Azure Functionsでのマネージドコネクタ利用時の課金体系はプレビュー中に詳細が変わる可能性もあるため、本番移行前に必ず確認しておきたい。 M365連携の自動化がコードで書ける 日本のエンタープライズでもMicrosoft 365は標準プラットフォームとなっている。TeamsのメッセージングやSharePointのドキュメント管理、Exchange Online経由のメール処理を、C#のコードで直接イベントドリブンに書けるようになることは、Azure開発者にとって実用的な選択肢が一つ確実に増えることを意味する。 コネクタ品質のばらつきに注意 1,400以上のコネクタすべてが等しく信頼できるわけではない。Logic Appsでも一部のコネクタはサードパーティ提供であり、品質・更新頻度・エラー時の挙動にばらつきがある。Functionsで使う場合も同様で、本番運用に投入する前には接続先サービスのレート制限・認証フロー・障害時の挙動を必ずステージング環境で検証してほしい。 筆者の見解 このアップデートは地味に見えるが、実は「アーキテクチャの設計判断を変えうる」変更だと感じている。 Logic AppsとAzure Functionsは「ローコード vs コードファースト」という軸で住み分けてきたが、今回のマネージドコネクタ対応でその境界線が意図的に曖昧にされた。両者をより柔軟に組み合わせられる環境に向かっている方向性は正しいと思う。 ...

この記事はClaude Code との共同執筆です。 BlueSkyに投稿したら、勝手にXにも流れてくれたらいいのに——そう思ったことはないですか？続きをみる note.com で続きを読む →

MicrosoftはMicrosoft EntraとMicrosoft Defenderの連携を大幅に強化し、AIによって加速するサイバー攻撃への対抗策として「統合IDリスクスコア」「新しいEntra ID Protectionエクスペリエンス」「セキュリティアラートトリアージエージェント」を発表した。攻撃者がAIを使って攻撃を自動化・高速化するなか、防御側も同じ速度で動ける仕組みを整えることが急務になっている。 AIが変えたサイバー攻撃の様相 従来の攻撃は人手に依存する部分が多く、偵察・フィッシング文章の作成・認証情報の分析・権限昇格の試みといった各フェーズに時間がかかっていた。しかしAIの登場により、この状況は一変した。 攻撃者はAIを使って、ターゲットに合わせたソーシャルエンジニアリングを大規模に実施し、漏洩した認証情報を瞬時に分析して特権ユーザーを特定し、露出しているシステムを自動的に探索する。攻撃チェーン全体が高速化・自動化されているわけだ。 攻撃手法がいくら進化しても、エントリーポイントとして狙われ続けるのは変わらず「アイデンティティ」だ。ユーザーアカウント、管理者アカウント、ワークロードID、アプリケーション、Non-Human Identity（NHI）、AIエージェント——これらすべてが、適切に保護されなければ重要データへの侵入経路になり得る。 Microsoft Entraの新機能：3つの重点強化 1. 統合IDリスクスコアで「今どこが危ないか」を一目で把握 RSA 2026で発表された「統合IDリスクスコア（Unified Identity Risk Score）」は、関連アカウント・セッション・ワークロード・アプリケーション全体のシグナルを横断的に分析し、一つの包括的なリスク評価値として表示する機能だ。 このスコアはリアルタイムのアクセス判断に直結し、条件付きアクセス（Conditional Access）ポリシーのなかでリスクベースの動的な応答を実現する。単なるダッシュボードの数値ではなく、「このユーザーへのアクセスを今すぐブロックする」という実際のポリシー執行と連動する点が重要だ。 新しいEntra ID Protectionエクスペリエンスでは、リスクの高いユーザー・サインイン・ワークロード・関連する検出情報を一画面で確認できるようになった。これまではバラバラなビューからシグナルを手動でつなぎ合わせる必要があったが、その手間が大幅に削減される。管理者はリスクスコアの計算根拠、関連アカウントへの波及状況、攻撃タイムラインまでを一つの画面で把握し、対処の優先度判断を下せる。 2. 最小権限を守りながら対応速度を上げる新RBACロール セキュリティインシデント対応で長年の課題になっているのが、SOCチームとIAMチームの分断だ。SOCチームは脅威を検出しても対処する権限がなく、IAMチームの対応を待つ間に被害が広がる——こうした状況が多くの組織で実際に起きている。 かといって、SOCチームに広範な管理者権限を付与すれば、そのアカウント自体が侵害された場合の被害が拡大する。「解決策がリスクを生む」という典型的なジレンマだ。 Microsoftはこれに対し、「IDに特化したRBACロール」（パブリックプレビュー予定）で応答する。SOCチームが必要なIDレスポンスアクションだけ実行できる権限を与え、広範な管理者権限は不要にする。さらにMicrosoft Entraの特権IDマネジメント（PIM）と組み合わせることで、Just-In-Time（JIT）アクセスポリシーを適用可能にする。必要なときだけ権限を昇格させ、通常時は最小権限を保つ——ゼロトラストの原則に忠実な設計だ。 3. Conditional Access最適化エージェントとアラートトリアージの自動化 「Conditional Access最適化エージェント」は、IDシグナル・使用パターン・新興脅威を継続的に分析し、適切なポリシー変更を推奨する機能だ。新たに「Block risky user agent」ポリシーの推奨が追加され、AIエージェントの悪用や自動アクセス試行といった新しい攻撃ベクターへの対応が強化されている。 まもなく、Defenderの脅威検出情報がEntraのConditional Access最適化推奨に自動フィードされる連携も実現する予定だ。管理者は「なぜこの変更が必要か」「誰が影響を受けるか」「何をすればよいか」が明示された推奨を受け取れるため、事後対応から予防的対応へとシフトできる。 「Security Alert Triage Agent」もIDシナリオに拡張され、自動攻撃妨害・予測的シールディングと組み合わせることで、エンド・ツー・エンドの自動化ループが完成する。 日本のIT現場への影響 SOCとIAMの分断は日本でも深刻 大規模な日本企業では、SOCチームとIAMチームが別組織になっているケースが多く、インシデント発生時の連絡・対応フローが複雑で対応が遅れる原因になっている。新しいRBACロールとJIT昇格の仕組みは、この分断を組織改編なしに緩和できる可能性がある。組織の壁を動かす前に、権限設計で改善できる部分がある点は現実的だ。 NHIの管理が次のボトルネックに アプリケーションやAIエージェントが増えるにつれ、Non-Human Identity（NHI）の数と複雑さが急増している。「サービスアカウントのパスワードを誰が管理しているかわからない」「古いAPIキーが放置されている」といった状況は珍しくない。統合IDリスクスコアにNHIのシグナルが含まれることで、人間のアカウントだけでなく機械的なIDのリスクも可視化できるようになる。業務の自動化を進めるほど、NHI管理の重要性は増す。 実務アクション 今すぐ: Entra ID ProtectionでConditional Accessポリシーの最適化推奨を確認し、放置されているギャップを特定する 近い将来: 新RBACロールのパブリックプレビュー開始後、SOCチームの権限設計を見直す 継続的に: NHIの棚卸しを実施し、不要なサービスアカウントや放置APIキーを整理する 筆者の見解 Microsoft EntraとDefenderが統合されてきた流れは、「ようやくここまで来たか」という感想が正直なところだ。IAMとSOCが別ツール・別ワークフローで動いている状況は攻撃者にとって明らかに有利であり、防御側がその構造を自ら維持していること自体がリスクだった。 JIT昇格とRBACの組み合わせでSOCとIAMの分断を解消しようとするアプローチは、ゼロトラストの文脈で真っ当な方向性だ。「常時アクセス権の付与は特権管理における最大のリスク」——この原則を製品の機能設計に落とし込もうとしていることは評価したい。Microsoftはこの領域で正しい問いを立てている。 一方で、統合IDリスクスコアの精度と誤検知率については、実運用でどう出るかを見ていく必要がある。シグナルが多くなればなるほどスコアは複雑になり、「なぜこのスコアになったか」の説明可能性が重要になる。Microsoftが「rationale（理由）の説明」を強調している点は、現場のニーズを理解している証左だろう。その約束をきちんと果たせるか、ここが肝だ。 日本の大きな組織では、古いセキュリティモデルにゼロトラストを中途半端に追加した複雑な構成が多い。こういった統合ソリューションを活用するためには、まずその複雑さを整理する段階が必要になる。ツールがいくら進化しても、組織の構造と意識が追いつかなければ宝の持ち腐れだ。Microsoftには機能の発表と同じくらい、移行パスの支援に力を入れてほしいところだ。その力は十分にあるはずなのだから。 出典: この記事は AI is accelerating cyberattacks—here’s how to stay ahead の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

セキュリティ企業Kaspersky（カスペルスキー）は2026年6月16日、人気のアニメーション壁紙アプリ「Wallpaper Engine」とSteamのコミュニティ機能「Steam Workshop」を悪用したマルウェア攻撃に関するレポートを公開した。PC Watchが詳報を伝えており、2025年後半から被害が急速に拡大しているとして注意を呼びかけている。 なぜこの攻撃が注目されるのか Steam WorkshopはSteamが提供するユーザー制作コンテンツの共有プラットフォームだ。Wallpaper Engineはその中で特に人気の高いアプリで、アニメーションする壁紙をデスクトップに設定できる。価格が数百円程度と手頃なこともあり、PCゲーマーを中心に世界中で広く使われている。 今回の攻撃が厄介なのは、ユーザーが「信頼できる」と感じる流通経路そのものを悪用している点だ。不審なWebサイトからダウンロードしたのではなく、Steamという正規プラットフォーム上のコンテンツを経由するため、ユーザーの警戒心が下がりやすい。 攻撃の仕組み——ゲームを起動しながらバックドアを仕込む Kasperskyのレポートによれば、攻撃者が悪用したのはWallpaper Engineの「アプリケーション型壁紙」機能だ。同機能はサードパーティ製アプリのウィンドウを壁紙として動作させるもので、実行ファイルを直接動かすことができる。 攻撃の流れは次のように整理できる： 壁紙起動時に正規のゲームが動作するため、ユーザーは異変に気づきにくい バックグラウンドでペイロードを含んだライブラリがサイレントにインストールされる Steamのアカウント認証情報が収集され、セッションが乗っ取られる 窃取した情報は攻撃者のサーバーに送信される 乗っ取ったアカウントを使って新たなマルウェア入り壁紙がアップロードされ、感染が自己増殖する Kasperskyは、マルウェアをパスワード保護された圧縮ファイルに隠すケースも確認しており、セキュリティスキャンをすり抜ける工夫が施されていると報告している。確認されたマルウェアの種類は、情報窃取マルウェア・バックドア・暗号通貨マイナー・ボットネットローダーと多岐にわたる。 Steamの対応と現状の限界 Kasperskyが特定したマルウェア入り壁紙はすでにSteamによって削除されているが、同レポートでは「同様の壁紙は次々とアップロードされるため、すべて排除できているとは限らない」と明確に警告している。今回だけで数十種類の悪質コンテンツが確認されており、コミュニティコンテンツの事前審査には構造的な限界があることが改めて浮き彫りになった。 日本市場での注目点 Wallpaper EngineはSteam経由で日本でも広く普及しているツールだ。今回の攻撃から身を守るうえで、以下の点を押さえておきたい。 アプリケーション型壁紙は特にリスクが高い: 動画・画像・Webページ型と比べ、実行ファイルが動くアプリケーション型は攻撃ベクターになりやすい。必要性を感じない場合は使用を避けるか、信頼できる制作者のものに限定することを検討する Steam Guardの有効化が最優先: 二段階認証（Steam Guard）を設定していない場合は今すぐ有効化する。アカウント乗っ取りを防ぐ最も確実な手段だ セキュリティソフトを最新の状態に保つ: Kasperskyをはじめ主要なセキュリティ製品は今回の攻撃に対する定義ファイルを更新済みとみられる Workshopコンテンツの評価・コメントを確認する: マルウェア入りコンテンツは評価が低かったり、コメント欄に異変の報告が集まっているケースが多い 筆者の見解 今回の攻撃が示しているのは、「コミュニティコンテンツの豊かさ」と「セキュリティリスク」が表裏一体であるという現実だ。Wallpaper Engineという正規アプリを入口にし、Steamという信頼された流通経路を悪用する手口は、ユーザーの警戒心をシステマティックに下げるよう設計されている。 プラットフォーム側の事前審査には限界がある以上、「使用禁止」で完結させるのではなく、安全に使い続けるための運用ルールをユーザー自身が持つことが現実的な対策だ。アプリケーション型壁紙の使用ポリシーを見直し、Steam Guardを有効化し、不審なコンテンツを選ばない目を養う——そうした地道な積み重ねが、便利なコミュニティ機能を安全に享受し続けるための唯一の道になる。 Steam側にはより積極的な事前スキャンや実行ファイルを含むコンテンツへの追加的な審査プロセスの導入を期待したい。信頼されたプラットフォームであるからこそ、その責任は重い。 出典: この記事は 「Wallpaper Engine」でマルウェア入り壁紙の報告。Steam Workshopで拡散 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AI画像生成ツールとして知られるMidjourneyが、同社初のハードウェア製品「Midjourney Scanner」を発表した。CEOのDavid Holz氏が公開したこのデバイスは、超音波技術を使った全身スキャナーであり、「猫の画像を生成するツール」とはまったく異なる方向性への大きな一歩だ。 Midjourney Scannerとは何か Midjourney Scannerは、超音波の輪状センサーアレイを使って全身の断面画像を取得する装置だ。利用者はプラットフォームに乗り、水槽の中をゆっくりと降下しながら、数千個のトランスデューサーが発する超音波を全方向から受ける。波の透過パターンを解析することで、筋肉・脂肪・骨・内臓の3D構造を可視化する仕組みだ。スキャン時間はわずか約60秒。 開発にはButterfly Network社が協力しており、同社の「Ultrasound-on-Chip」技術モジュールを1台あたり40個搭載している。処理能力は2ペタフロップスで、取得した超音波データをリアルタイムにAIで解析・セグメント化する。Holz氏は「多くの点でMRIに匹敵する画像品質を目指している」と述べており、年1回から毎日の利用まで想定している。 スパ体験として提供するというアプローチ 注目すべきはサービスの提供形態だ。Midjourneyは2027年末までにサンフランシスコのユニオンスクエアに「Midjourney Spa」をオープンする計画を発表した。スキャナー10台に加え、ジム・サウナ・コールドプランジも備えるウェルネス施設として展開する。 これは賢い戦略だ。医療診断デバイスとしてFDA承認を取得するには長い時間とコストがかかる。一方で「体組成マップ」の可視化は現時点では医療診断とは異なる位置づけができ、規制上のハードルを下げながら市場に入れる。まずはウェルネス文脈で普及させ、データと実績を積んでから医療応用へ拡大するという段階的アプローチと読める。 取得したスキャンデータは医師やAI健康ツールと共有できるとしており、「データプライバシーは真剣に扱う」とコメントしているが、具体的なポリシーはサービス開始前に公開予定とのことだ。 実務への影響——ヘルステックとAI計算資源の転用 今回の発表で興味深いのは、Midjourneyが保有するAI計算資源（当初は画像生成向けに整備されたGPUクラスター）を医療画像解析に転用している点だ。画像生成AIとメディカルイメージングは、ドメインは異なるが「大量のデータから高精度な画像を生成・解析する」という技術的基盤を共有している。 日本のヘルステック・医療IT分野に携わるエンジニアや事業者にとって注目すべきポイントは以下の通りだ： 超音波×AI解析の組み合わせ: 超音波は放射線を使わず安全性が高い。MRI相当の画質をより手軽に実現できれば、定期健診や予防医療の分野で大きなインパクトがある スキャンデータの活用設計: Midjourneyは「ライブラリ構築」と「共有」を設計に組み込んでいる。電子カルテや健康管理アプリとの連携API設計の参考になる ウェルネス文脈での規制回避戦略: 医療機器認証を待たずに市場に入るアプローチは、日本のSaMD（Software as a Medical Device）対応を検討するスタートアップにも参考になる事例だ 筆者の見解 この発表で最も面白いと感じたのは、「技術資産の転用」という発想だ。画像生成AIで蓄積した計算資源とAI技術を、まったく別のドメインに持ち込む。Holz氏が「使われていないAI計算能力の代替ビジネス」と正直に言っているように、これはある意味で余剰リソースの有効活用だ。 ただし、医療ハードウェアは画像生成よりはるかに「失敗の許されない」領域だ。スキャン精度の検証、データ管理の透明性、FDA承認への道筋——現時点ではまだ十数人しかスキャンされていない段階であり、「MRI相当」という主張の裏付けにはまだ距離がある。技術的なポテンシャルは否定しないが、医療応用として成立するかどうかは今後のデータ次第だ。 より大きな視点で言えば、これはAI企業が「モデルを売る」から「体験として提供する」へとシフトする動きの一例でもある。スパという文脈で体験を包むことで、医療への抵抗感を下げながら利用者を増やし、スキャンデータという新たなデータ資産を積み上げる——この設計思想は今後の業界全体に影響を与えるかもしれない。 日本でこの種のサービスが普及するとすれば、医療法・個人情報保護法との整合性と、保険適用の議論が先に必要になる。技術そのものより、社会実装のハードルの方が高い。そこをどう乗り越えるかを、Midjourneyの挑戦から学べるものは多いと思っている。 出典: この記事は Midjourney goes from generating cat images to full-body ultrasound scans の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GoogleのAI開発部門「Google Gemini」の共同リードを務めていた著名AI研究者Noam Shazeer氏が、Googleを正式に退社し、OpenAIへの移籍を発表した。 Noam Shazeerとは——現代AIを生んだ論文の共著者 Shazeer氏の名が歴史に刻まれたのは2017年。Googleの研究者たちが共同発表した論文「Attention Is All You Need」の共著者として、現代のあらゆる大規模言語モデル（LLM）の基盤となるTransformer（トランスフォーマー）アーキテクチャを世に送り出した。 GPT-4もGeminiもClaudeも、すべてこの論文が起点になっている。それほど根本的な貢献をした研究者が、AI競争の最前線でチームを移動したのが今回のニュースだ。 Shazeer氏はGoogleに在籍後、AIチャットボット企業Character.AIを共同創業。その後はGoogle Geminiの共同リードとして再び同社の中枢に戻っていた経緯がある。 なぜこの移籍が業界を揺るがすのか AI産業において「誰が研究をするか」は、「どんなモデルが生まれるか」を直接決定する。Transformer論文の共著者の一人がOpenAIへ移籍することは、単なる人事情報ではなく、次世代モデルの研究方向が変わる可能性を示唆している。 GoogleはGeminiを中心に独自のLLM戦略を進めており、Shazeer氏は同チームのキーパーソンだった。その喪失がGeminiの開発速度・研究の深さにどう影響するかは、今後数ヶ月で明らかになるだろう。 一方、MicrosoftはOpenAIに深く出資・統合しており、研究陣の強化はAzure OpenAIサービスを通じて間接的にMicrosoftのAIエコシステム全体にも影響を与えうる。 実務への影響——日本のエンジニアはどう受け取るべきか 「どのモデルを使うか」の判断軸が変わる可能性 現在、企業向けのAI活用ではAzure OpenAIサービス経由でGPTモデルを使うケースが増えている。Shazeer氏のOpenAI参加は中長期的に研究力強化につながりうる。今後のモデル選定では、単にAPIコストを比較するだけでなく、各ベンダーの研究開発への投資動向も判断材料にしたい。 Transformer以降の「次のパラダイム」への注目 「Attention Is All You Need」は8年前の論文だが、いまだに現役の基盤技術だ。この先に何が来るかについて、Shazeer氏のような研究者がどこで何を研究するかは業界全体のロードマップに影響する。動向を継続的にウォッチしておくことをお勧めする。 研究者の移動から読む採用・育成の示唆 AI研究のトップ人材がどの組織に集まるかで、数年後のモデル性能が決まる。自社でAIを本格活用しているなら、ベンダーの財務状況や研究投資の姿勢も評価軸に加える時代に入っている。 筆者の見解 「Attention Is All You Need」は、もはや教科書の第一ページに載るべき歴史的業績だ。その共著者が研究の場所を変えることは、スポーツで言えばオールスタープレーヤーがチームを移籍するのに近い。ファンの注目を集めるだけでなく、試合結果（＝モデル性能）にも直結する話だ。 MicrosoftはOpenAIとの深い連携という構造的な強みを持っており、今回の移籍はその連携の価値を高める一因にもなりうる。Azure OpenAI経由で提供されるサービスへの恩恵がどう現れるかは、今後のモデルアップデートの中身を見ながら判断したい。 一方で、Googleも簡単に研究力を失うわけではない。DeepMindを含む研究体制は世界最高水準であり、Geminiがこの変化にどう応答するかも注目に値する。AI業界の「主役交代」が本当に起きているのか、一時的な人材流動に過ぎないのかは、1〜2年後のモデルクオリティが答えを出す。 私たちIT実務者にとって重要なのは「どのベンダーを応援するか」ではなく、「今使えるベストな技術は何か」という実用的な視点だ。このニュースを、モデル選定や技術ロードマップ策定の判断材料として冷静に活用してほしい。 出典: この記事は Google Gemini co-lead Noam Shazeer is leaving for OpenAI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Teams/OBSから4プラットフォームに同時ライブ配信するOSSツールを作った話この記事はClaude Code（AI）との共同作業で書かれています。 続きをみる note.com で続きを読む →

Bloombergのマーク・ガーマン記者が伝えたところによると、Appleは2027年春に「iPhone Air 2」を発売する計画を進めている可能性がある。Engadgetがこの情報を詳しく報じており、2025年秋に登場した超薄型スマートフォン「iPhone Air」の後継機として位置づけられる見通しだ。 なぜiPhone Air 2が注目されるのか 初代iPhone Airは、Appleの歴史上最も薄いスマートフォンとして鳴り物入りで登場した意欲作だ。しかし市場では「将来発売が見込まれる折りたたみiPhoneに向けた技術的な布石」という見方が根強く、スタンドアローン製品としての継続性に懐疑的な声も少なくなかった。 今回のリーク情報は、そうした見方を覆す可能性がある。Appleが第2世代の開発を本格化しているとすれば、「超薄型フォームファクター」を実験機にとどめず、ラインナップの恒久的な一員として育てていく意思の表れと捉えられる。 iPhone Air 2のスペック・機能（報道ベース） Bloombergの情報源によると、iPhone Air 2には以下の強化が盛り込まれる見通しだ。 背面カメラ: シングルからデュアルへ（初代の最大の弱点を直接修正） プロセッサ: A20 Proの一部バージョンを搭載予定 バッテリー: 初代から改善 海外レビューが指摘した初代の課題 Engadgetが公開した初代iPhone Airのレビューでは、「シングル背面カメラは明確なマイナス点」との評価が示されていた。超薄型ボディを実現するための設計上のトレードオフとして理解できるものの、価格帯を考えると見劣りする部分だったことは否めない。 Air 2でデュアルカメラが実現すれば、このネックが正面から解消される。薄さとカメラ性能の両立という、ユーザーが求めるバランスに一歩大きく近づく格好だ。 Appleの製品カレンダー見直しという文脈 今回の報道でもう一つ注目すべきは、「春発売」という時期設定だ。Appleはこれまで主力iPhoneを秋に一斉発表するサイクルを守り続けてきたが、廉価版「iPhone 17e」を春に投入するなど、製品カレンダーを意図的に分散させる動きが見られる。 iPhone miniやiPhone SEが「話題になったものの続かなかった」という歴史を繰り返さないため、春という投入時期を活用して話題の鮮度を保ちながら定着を図る戦略とも読める。 日本市場での注目点 現時点では日本での発売時期・価格についての公式情報は一切なく、あくまで海外報道に基づく段階だ。ただし、以下の点は押さえておきたい。 価格帯: 初代iPhone AirのApple Store価格は128GBモデルが124,800円（税込）から。後継機が同等水準か、デュアルカメラ搭載により若干上昇するかは不明 競合との比較: Galaxy Sシリーズなどデュアル・トリプルカメラを標準搭載するスリムモデルとの比較が焦点になる。「薄さ」を優先するユーザー層が一定数存在する日本では、カメラ強化によって選択肢として浮上してくる可能性がある 折りたたみiPhoneとの棲み分け: 2027年時点での折りたたみiPhoneの動向も気になる。両モデルが並立した場合、それぞれのターゲット層がどう分かれるかが市場の見どころになるだろう 筆者の見解 初代iPhone Airへの市場の反応が必ずしも熱狂的でなかった背景には、カメラの弱さだけでなく、「これは折りたたみへのつなぎ」というコミュニティの空気があったように思う。その前提があると、ユーザーは「完成品として買う」という判断を保留しやすい。 Air 2でデュアルカメラが加わり、A20 Pro世代のパフォーマンスが確保されれば、「つなぎ感」は薄れる。「これは独立した価値がある製品だ」とユーザーが感じられるかどうかが、このラインナップが根付くかどうかの分水嶺だろう。 一点気になるのは、A20 Proを「フルではなく一部バージョン」で搭載するとされる点だ。コスト設計上の合理性は理解できるが、それがAirというブランドに「ちょっと惜しい」という印象を固定化しないか注視したい。Appleの持てる技術力を考えれば、薄さと完成度の両立は十分実現可能なはずで、中途半端な着地にとどめる必要はないはずだ。 2027年春は、超薄型iPhoneが「本物のラインナップ」として認められるかどうかを問われる試金石となる。 関連製品リンク Apple iPhone Air 256GB (SIM-Free) 上記はAmazon.co.jpへのリンクです。記事執筆時点の情報であり、価格・在庫は変動する場合があります。 出典: この記事は The iPhone Air 2 will reportedly land next spring with a second camera の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftはAzure FunctionsにおけるGoの第一級言語サポートをパブリックプレビューとして公開した。Flex Consumptionプランで利用可能になり、Goエンジニアが慣れ親しんだ標準パッケージをそのままサーバーレス関数の記述に使えるようになった。 Goが「第一級市民」になるとは何か これまでAzure FunctionsでGoを動かすには、カスタムハンドラーという迂回路を使う必要があった。独自プロセスとしてGoバイナリを起動し、Functions Workerとのやり取りを自分で実装する形だ。便利とは言えない。 今回のアップデートで、この制約が取り払われた。HTTPハンドラーは標準のhttp.HandlerFuncをそのまま使って記述できる。 func HttpHandler(w http.ResponseWriter, r *http.Request) { fmt.Fprintln(w, “Hello from Azure Functions!”) } Goを書いたことがある人ならすぐに理解できる、いつも通りの書き方だ。非HTTPトリガー（タイマー、メッセージキュー等）もcontext.Contextと型付きペイロードで処理でき、Goらしい型安全なコードが書ける。 サポートされるトリガー一覧 パブリックプレビュー時点で以下のトリガーが利用可能だ。 トリガー種別 用途の例 HTTP REST APIエンドポイント、Webhookの受信 Timer 定期バッチ処理 Service Bus 非同期メッセージ処理 Event Hubs ストリームデータの取り込み Event Grid イベント駆動アーキテクチャ Cosmos DB データ変更の検知・連鎖処理 Blob Storage ファイルアップロード後の処理 実務でよく使うトリガーは一通り揃っている。プロトタイプから本格的なプロダクション用途まで対応できる水準だ。 なぜこれが重要か——Goとサーバーレスの相性 Goはコンパイル後のバイナリが小さく、起動が速い。サーバーレス関数において最大の課題の一つがコールドスタートの遅延であることを考えると、この組み合わせは理にかなっている。 AzureのFlex ConsumptionプランはコールドスタートとスケーリングをAzureがマネージドで制御するプランだ。ここにGoの軽量さが加わることで、従来のC#やNodeよりも低レイテンシなサーバーレス関数を実現できる可能性がある。 また、GoはクラウドネイティブなOSS（KubernetesやTerraform等）の実装言語として事実上の標準に近い地位にある。こうしたエコシステムに慣れた開発者がAzureに参入しやすくなるという意味もある。 日本のIT現場への影響 Goチームを抱える組織にとっては、バックエンドコードをAzure FunctionsにそのままデプロイできるためCI/CDパイプラインの統一が容易になる。言語ごとに別のデプロイ方法を使い分けるコストが下がる。 マイクロサービス移行中のチームにとっては、既存のGoサービスの一部をFunctions化してFlex Consumptionの従量課金メリットを得るという選択肢が現実的になった。 スタートアップや少人数チームでは、GoのシンプルさとAzure Functionsのインフラ管理不要という特性を組み合わせることで、少ない人手で高い可用性を実現しやすくなる。 実務での第一歩としては、まずHTTPトリガーの関数から始めるのが無難だ。Goの標準ライブラリだけで動くシンプルなAPIエンドポイントをFlex Consumptionに乗せ、コールドスタート時間と実行コストを計測してから適用範囲を広げていくアプローチを推奨する。 筆者の見解 Goサポートのアナウンスは、Azure Functionsのエコシステムとして正しい方向の一手だと思う。 これまで「AzureでGoを使いたければApp ServiceかAKSを選べ」という暗黙のメッセージがあった。それが変わる。Goを書く開発者にとってAzureの選択肢が広がるのは歓迎すべきことで、Azureのプラットフォームとしての懐の深さにもつながる。 標準パッケージをそのまま使えるという設計方針も評価できる。独自フレームワークや特殊なSDKを覚えさせるのではなく、「Go開発者がGoを書けばいい」という姿勢は、道のド真ん中を歩くアプローチとして正しい。 一方で、プレビュー段階での成熟度については慎重に見ていく必要がある。Flex Consumptionプランは比較的新しく、本番導入にあたってはSLAや運用ノウハウの蓄積状況を自分たちで確認することが重要だ。 Azureはインフラプラットフォームとしての信頼性は揺るがない。あとはこういった地道な言語サポートの拡充が、実際に開発者体験の改善として積み重なっていくかどうか。Goチームを抱えている組織は、まずFlex Consumptionプランのプレビューで試してみる価値は十分にある。 出典: この記事は Announcing Go support in Azure Functions (Preview) の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

OpenAIが、研究機関・大学向けに特化した新サブスクリプション「ChatGPT for Science」をウェブビルド上でひそかにテストしていることが、コードリークによって明らかになった。公式アナウンスは数週間以内と見られており、科学研究の現場にAIが本格的に組み込まれる時代が近づいている。 現行プランと「ChatGPT for Science」の位置づけ 現在OpenAIはChatGPTのサブスクリプションとして、個人向け・Teams・エンタープライズの3段階を展開している。 プラン 対象 Personal 誰でも利用可 Teams 会社ドメイン＋最低3ユーザー必要 Enterprise 法人格を持つ組織が対象 新たにテストされている「ChatGPT for Science」は、認定を受けた研究機関や大学に利用資格が限定される見通しだ。通常の個人向けプランとは異なり、「誰でも購入できる」形にはならない可能性が高い。 GPT-Rosalindとの関係——すでに「研究特化AI」は動いている OpenAIがサイエンス領域に力を入れているのは今回が初めてではない。同社はすでにGPT-5.5アーキテクチャをベースとしたGPT-Rosalindを発表している。これは単なる汎用モデルにサイエンス向けプロンプトを当てたものではなく、エンタープライズ規模のライフサイエンス研究に向けて根本から設計された特化モデルだ。 GPT-Rosalindへのアクセスは「トラステッドアクセス展開」と呼ばれる厳格な管理下に置かれており、現時点ではNovo Nordiskのような大手製薬企業や公益目的の認定研究機関のみが利用可能。ChatGPT Enterpriseと同等以上のセキュリティ・ガバナンス要件が課されている。 ChatGPT for Scienceは、GPT-Rosalindのこうした機能を、ごく限られたパートナーではなくより広い研究機関に解放するための仕組みになり得ると見られている。通常サブスクリプションよりも科学的発見・研究文献に深く根ざしたグラウンディングを持つプランとして設計される見込みだ。 実務への影響——日本の研究機関・大学IT担当者が今から動くべきこと GPT-Rosalindの前例が示す通り、OpenAIは研究用途の高機能モデルへのアクセスに、エンタープライズグレードのセキュリティ体制と組織の正当性証明を要求してきた。ChatGPT for Scienceでも同様の条件が課される公算が高い。今から準備を進めた組織が半年後に差をつけることになる。 今すぐ整備しておくべき基盤 SSO・IdP連携の整備（Microsoft Entra IDやOktaとの統合） 研究データの外部送信に関する倫理審査・契約の整備（個人情報保護・研究倫理の観点からの事前確認） 利用者管理の可視化——誰が、どの研究目的で使っているかをITが把握できる状態 パイロット導入の設計——文献検索・仮説生成・論文要約など繰り返し業務への試験的組み込み AIの研究ワークフローへの組み込みは、研究者の生産性を根本から変える可能性がある。体制整備なしに「購入だけした」状態は、かえって管理リスクを増やすだけだ。研究支援部門とIT部門が連携して活用フローを設計しておくことが先決となる。 筆者の見解 「研究専用AI」という切り口は、サブスクリプション追加以上の意味を持つ。科学研究の再現性・信頼性が社会的に問われている中、AIが研究プロセスのどこに介在するかは、倫理的にもガバナンス的にも慎重に設計される必要がある。OpenAIがGPT-Rosalindで採用した「トラステッドアクセス」の考え方——要するに誰でも使えるにはしない——は筋が通っている。 そのうえで気になるのは、日本の大学・研究機関が実際にこのプランを使いこなせる体制にあるかどうかだ。契約・倫理審査・データガバナンスのいずれも追いついていない組織は、「使えるはずなのに使えない」状況に陥りやすい。研究現場でAIが本格活用される局面は確実に来る。今から動き始めた組織がその波に乗れる。アナウンスを待ってから動くのでは遅い。 出典: この記事は Leak confirms OpenAI is testing a ChatGPT for Science subscription の内容をもとに、筆者の見解を加えて独自に執筆したものです。

中国のAI研究機関Z.aiが2026年6月16日にリリースしたGLM-5.2が、独立系ベンチマークのArtificial Analysis Intelligence Index（v4.1）においてオープンウェイトモデルの首位を獲得した。MITライセンスでの公開という点も注目を集めており、企業・研究者を問わず幅広い活用が期待されている。 GLM-5.2の技術仕様 GLM-5.2は753BパラメータのMixture of Experts（MoE）モデルで、アクティブパラメータは40Bとなっている。モデルサイズは約1.51TBと巨大だが、MoEアーキテクチャにより推論時のコンピューティングコストを抑える設計だ。 前バージョンGLM-5.1から最も大きく変わった点がコンテキストウィンドウの拡張で、20万トークンから100万トークンへと一気に5倍になった。長大なコードベースや技術文書を丸ごと読み込んで処理するようなユースケースで特に威力を発揮するはずだ。 なお、GLM-5.2はテキスト入力専用モデルであることに注意が必要だ。Z.aiはビジョン系モデルとして「GLM-5V-Turbo」を別系列で展開しているが、こちらはオープンウェイトでの公開はない。 ベンチマーク結果 Artificial Analysisによる評価では、GLM-5.2はIntelligence Indexスコア51を記録し、MiniMax-M3（44）、DeepSeek V4 Pro（44）、Kimi K2.6（43）を上回って首位に立った。 また、フロントエンドWeb開発タスクとエージェント的なコーディングワークフローを評価するCode Arena WebDevリーダーボードでは2位を記録。1位のClaude Fable 5に次ぐ位置につけた。画像入力なしのテキスト専用モデルがWebDev系のベンチマークでここまで上位に来るのは、従来の予想を覆す結果だ。 一方、出力トークン数の多さは課題として指摘されている。1タスクあたりの平均出力トークンが43,000と、GLM-5.1（26,000）やDeepSeek V4 Pro（37,000）を大幅に上回る。思考プロセスを長く展開する傾向があるとみられる。 価格と利用方法 OpenRouter経由で9プロバイダーから利用可能で、ほとんどのプロバイダーが入力$1.40/M・出力$4.40/Mで提供している。主要クローズドモデルと比較すると： モデル 入力 出力 GLM-5.2 $1.40/M $4.40/M Claude Opus 4.5-4.8 $5/M $25/M GPT-5.5 $5/M $30/M 入力は約1/3、出力は約1/6という価格差は無視できない。ただし上述の通りGLM-5.2はトークン消費量が多めであるため、単純なコスト比較には注意が必要だ。 SVG生成テストの明暗 Simon Willison氏による実検証では、アニメーション付きSVG生成の結果に明暗が出た。「自転車に乗るペリカン」のプロンプトでは車輪のスポークやペダルが正確に描画され、アニメーションも破綻なく動作する高品質な出力が得られた。一方、同氏が前バージョンGLM-5.1で傑作と評した「電動キックスケーターに乗るバージニアオポッサム」の再挑戦では、クオリティが大幅に後退。アニメーションの実装すら行われなかったという。 同一モデル内でのタスク依存の品質ばらつきは、LLM全般に共通する課題でもある。本番利用の前に自社ユースケースでの評価が必須だ。 実務への影響 GLM-5.2のMITライセンス公開は、企業の自社ホスティング戦略において選択肢を広げる。特に以下のシナリオで検討価値がある： コスト重視のバッチ処理: ドキュメント要約や分類など、大量のテキスト処理タスクにおいて推論コストを削減できる可能性がある 長文脈処理が必要な場面: 100万トークンコンテキストは、大規模なコードベース解析や長大な仕様書の処理に対応する オンプレミス・プライベートクラウド展開: MITライセンスのため、データを外部に出せない業種での自社運用が法的にも整理しやすい WebDev系タスクのセカンドオピニオン: テキスト専用でも高スコアを出した事実は、フロントエンド開発補助での活用余地を示している ただし1.51TBというモデルサイズは相当なGPUリソースを要求するため、自社運用には相応のインフラ投資が前提となる。まずはOpenRouter経由での試験運用から始めるのが現実的だ。 筆者の見解 オープンウェイト陣営が急速にクローズドモデルに追いつきつつある流れは止まらない、というのが率直な印象だ。GLM-5.2がIntelligence Indexで首位に立った事実は、「強いモデル＝クローズド」という図式が崩れ始めていることを示している。 個人的に注目しているのはMITライセンスという選択だ。Apache 2.0より制約が少なく、商用プロダクトへの組み込みでも法的なハードルが低い。日本企業がAIをプロダクトに組み込んでいく際の選択肢として、ライセンス面での扱いやすさは実際の採用判断に影響する。 コスト面では、出力トークン量の多さが見かけの安さを相殺するケースがある点に注意したい。ベンチマークでの43,000トークン/タスクというのはかなり多い。使い方によっては期待ほどコストが下がらない可能性があるため、自社ワークロードでの実測が不可欠だ。 また、テキスト専用でWebDevリーダーボード2位というのは興味深い。「フロントエンド開発には画像入力が必要」という直感が必ずしも正しくないとすれば、モデル選定の前提を見直す必要があるかもしれない。実際のコーディング補助は、コードの文字列理解がほとんどを占めているという証左とも取れる。 中国勢のオープンウェイトモデルはコストパフォーマンスの面で着実に実力をつけている。自社のユースケースに合ったモデルを選び、実際に動かして検証するという姿勢が、今のAI活用では一番正しい行動だと思っている。 出典: この記事は GLM-5.2 is probably the most powerful text-only open weights LLM の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

🤖✍️ この記事はAIとの共同執筆です ── AIエージェント（Claude Code）が胡田との実際の共同作業の経験をもとに下書きを自動生成し、胡田が内容を確認・修正したうえで公開しています。 続きをみる note.com で続きを読む →

MicrosoftがWindows 11向け「新Outlook」のオフライン状態でのファイル添付機能を2026年4月より全ユーザーへ展開した。2025年10月からのテスト期間を経てのリリースだが、なぜこれほど時間がかかったのか——その答えは新Outlookの根本的なアーキテクチャにある。 新Outlookの正体：Edgeブラウザを内包したウェブアプリ 新OutlookはWindowsネイティブアプリではない。実体はWebView2コンテナ内でOutlook.comを表示するウェブアプリだ。タスクマネージャーで確認すると、OutlookのプロセスにはEdgeブラウザを支えるService WorkerやWebGPUと同じコンポーネントが並んでいる。 平たく言えば「Edgeタブの中でOutlookを開いている」状態に近い。 この設計自体が技術的に誤りとは言い切れない。Progressive Web App（PWA）の仕組みを活用すれば相応のオフライン機能も実装できるし、クロスプラットフォーム展開やウェブ技術の継続的な進化を取り込みやすい利点もある。 問題は、Outlookがカジュアルなウェブメールではなくエンタープライズ向けの高度なクライアントだという点だ。 オフライン対応の現状と仕組み 2025年にメール閲覧とカレンダーのオフライン閲覧が実装され、今回ようやくオフラインでのファイル添付が加わった。 技術的な仕組みはこうだ。WebView2アプリはローカルディスク上のUser Data Folder（UDF）にキャッシュデータを保存する。オフライン時に作成したメールや添付ファイルはLocalStorageデータベースに一時保存され、ネットワーク復帰後に自動送信される。 注意点として、新OutlookはOutlook ClassicやMail & Calendarアプリよりも多くのディスクスペースを消費する。オフライン機能を積極的に活用するほどローカルストレージへの負荷が増加する点を把握しておきたい。 オフライン添付機能を有効にするには、Outlookの設定で「全般」→「オフライン」→「ファイル添付を含める」をオンにする。 今後の改善ロードマップ オフラインメールの保存期間は現在180日間が上限だが、1年または2年への拡張が予定されており、「Settings > General > Offline > Days of email to save」から設定できるようになる見込みだ。 その他にも複数の機能強化が予告されている。 全アカウント統合受信トレイ（複数メールアカウントのメールを1画面で確認） メールのマージ機能（スレッドを束ねて整理） 機能ロードマップは着実に前進しているが、Outlook Classicと比較したとき、起動速度（新Outlookはメール表示まで10秒以上かかる場合がある）や操作性の差は依然として大きい。 実務への影響 移行判断は慎重に 現時点でOutlook Classicからの強制移行タイムラインはMicrosoftから明示されていないが、企業環境では事前検証と社内展開計画の策定を早めに進めておくことを推奨する。 特に以下のユーザー層は新Outlookとの相性を入念に確認したい。 頻繁にオフラインで作業する出張族・現場担当者 大容量添付ファイルを日常的に扱う業種（設計・映像・製造等） COM/VBAアドインに依存したカスタマイズ済みOutlook環境（新Outlookではサポート外） ストレージ管理を事前に 新OutlookがオフラインデータのキャッシュとしてUDFを活用する点は把握しておきたい。オフライン保存期間を延ばす設定を有効にする場合は、対象端末のディスク空き容量を事前に確認することを強くお勧めする。端末管理ポリシーでローカルストレージに上限を設けている環境では、UDFの保存先パスも意識する必要が出てくる。 筆者の見解 新OutlookがWebView2でウェブアプリをラップする方向性を選んだ背景には、クロスプラットフォーム対応、継続的なウェブ技術との同期、開発リソースの効率化という意図が読める。中長期の戦略として理屈は通る。 ただ、Outlookは何百万もの企業ユーザーが毎日の仕事を委ねているツールだ。オフライン状態でファイルを添付する機能——それはOutlookの旧バージョンから当然のように提供されてきた機能であり、それが2026年になってようやく「全ユーザーに展開」されるという事実は、エンタープライズ製品として率直に「もったいない」と思う。 Microsoftには、統合プラットフォームとしてのエコシステム全体を活かして最終的な完成形に辿り着く技術力と資産がある。今後予告されている機能追加のロードマップを見れば、方向性は間違っていない。新Outlookが「使えるツール」として評価される日が来ることを期待しつつ、当面のエンタープライズ展開判断はClassicの動向を横目に見ながら慎重に進めるのが賢明だろう。 出典: この記事は Microsoft still can’t make Windows 11’s New Outlook work offline because it refuses to go native の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Engadgetおよび『ウォール・ストリート・ジャーナル（WSJ）』の報道によると、AppleのCEOであるティム・クック氏が、同社製品の値上げが「避けられない」状況にあると事実上認めた。WWDC 2026が終了し、iPhone 18ラインナップの発表が数か月後に迫るなか、消費者にとって無視できないニュースが飛び込んできた。 AI需要が引き起こした「RAMaggedon」 クック氏がWSJの取材に対して語った内容の核心はシンプルだ。「消費者がデバイスを求めているにもかかわらず供給が不足しており、メモリメーカーから莫大な価格引き上げが転嫁されている」というものだ。 その背景にあるのは、生成AI・大規模言語モデルの爆発的な需要拡大だ。データセンター向けのHBM（高帯域幅メモリ）やDDR5の需要がサーバー用途で急増したことで、コンシューマー向けのNAND型フラッシュメモリやDRAMにも供給の締め付けが波及している。この現象を業界では「RAMaggedon（ラマゲドン）」と呼び始めている。 クック氏はこう述べた。「40年以上のキャリアで、これほどの事態はどの分野でも見たことがない」——この一言が、事態の深刻さを端的に示している。 影響を受ける製品範囲と他社の動向 Engadgetの報道によれば、クック氏は具体的な値上げ幅や時期には言及しなかったものの、価格上昇の対象は現行ラインナップを含む広範な製品に及ぶ可能性を示唆した。WWDC直後のタイミングで発言したことから、今秋発売予定のiPhone 18シリーズ、および年内に発表されるMacやiPadも対象になると見られている。 Appleだけではない。Samsung、HP、Microsoft、Nintendo、Valveも、ここ数か月で同様のコスト圧力について言及している。メモリ価格高騰はプラットフォームや製品カテゴリーを超えた業界全体の問題となっている。 日本市場での注目点 日本市場でも影響は避けられない見通しだ。円安が依然として続いているなか、ドル建てで価格が上がれば円換算での上昇幅はさらに大きくなる可能性がある。 現時点では具体的な日本向け価格は未発表だが、過去のApple製品の値上げ事例（iPhone 14以降の円建て価格引き上げ）を踏まえると、iPhone 18シリーズは上位モデルで20万円超えが現実的なシナリオとして浮上してくる。 競合としては、同じコスト圧力にさらされながらも価格を抑えるサムスンのGalaxy Sシリーズや、Qualcommチップ搭載のAndroidフラッグシップが選択肢になるが、それらも同様の値上げ圧力を受けていることは念頭に置いておく必要がある。 筆者の見解 今回のクック氏の発言で最も注目すべきは、「メモリ価格の問題」が一時的な需給の歪みではなく、AI開発という構造的な力によって引き起こされているという点だ。 データセンターがメモリを大量に吸い上げ、コンシューマー向け製品の製造コストが上がる——この構図は、AIの恩恵を受けている人々と、スマートフォン・PCの値上がりという形でコストを負担する人々が異なるという非対称性を生む。技術の進歩が消費者の手の届かないところにコスト転嫁していく皮肉な構造だ。 Appleはこの問題を「コントロールできない外部要因」として提示しているが、実際のところ、同社自身もApple Intelligence（生成AI機能）へのメモリ要件を年々引き上げてきた当事者でもある。値上げを余儀なくされる理由の一端は、AI機能を強化するために自ら作り出した需要にある、という見方も成り立つ。 いずれにせよ、iPhone 18の発表は消費者にとって価格の分岐点になる可能性が高い。秋の発表を冷静に見極めながら、「今の世代で十分か」を改めて問い直す時期に来ているかもしれない。 関連製品リンク Apple iPhone 16 Pro Max (1 TB) - Desert Titanium SIM Free for 5G Apple 2025 MacBook Air (13-inch, Apple M4 chip with 10-core CPU and 10-core GPU, 16GB Unified Memory, 512GB) - Silver 上記はAmazon.co.jpへのリンクです。記事執筆時点の情報であり、価格・在庫は変動する場合があります。 出典: この記事は Tim Cook says Apple price increases are ‘unavoidable’ due to memory crunch の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは、Windows Defenderのゼロデイ脆弱性「RoguePlanet」（CVE-2026-50656）に対するパッチを現在開発中であることを公式に認め、セキュリティアドバイザリを公開した。完全パッチ適用済みのWindows 10・11でも悪用可能であり、パッチ提供時期は未定のまま攻撃リスクがさらされている。 RoguePlanetとはどんな脆弱性か RoguePlanetはMicrosoft Malware Protection Engine——Defenderのコアエンジン——に存在するレースコンディション（競合状態）の脆弱性だ。攻撃者がこれを悪用すると、SYSTEM権限でコマンドプロンプトを起動できてしまう、いわゆる「特権昇格（EoP）」の脆弱性である。OSの最上位権限を乗っ取られることを意味し、その先の攻撃展開は無制限に広がる。 この脆弱性を発見・公開したのは「Nightmare Eclipse」と名乗るセキュリティ研究者。2026年6月のPatch Tuesday当日に、PoC（概念実証コード）を自前のGitリポジトリで公開した。GitHubやGitLabは以前MicrosoftからのリクエストでリポジトリをBanされたとして、自ホスティングに切り替えている。 レースコンディション脆弱性ゆえの「不規則性」 レースコンディション系の脆弱性は確率的な挙動をとる。Nightmare Eclipse本人も「一部のマシンでは100%成功したが、別のマシンでは不安定だった」と述べており、環境依存性が高い。 ただし特に注目すべきは、リアルタイム保護が有効でも無効でも機能するという点だ。「Defenderを有効にしているから安全」という思い込みは今回には通じない。セキュリティ製品そのものが攻撃ベクターになるという皮肉な状況であり、管理者はDefenderの状態だけで安全を判断しないよう気をつけたい。 MicrosoftはCVE-2026-50656として正式にIDを割り当て、「高品質なセキュリティアップデートを提供するために取り組んでいる」とアドバイザリで述べているが、リリース時期の明言はない。 研究者とMicrosoftの長期的な対立 RoguePlanetは孤立した事例ではない。Nightmare Eclipseはここ数ヶ月で、BlueHammer・RedSun・GreenPlasma・MiniPlasma・YellowKey・UnDefendと、WindowsコンポーネントやDefender・BitLocker関連のゼロデイを次々と公開してきた。その背後にあるのは、Microsoftのバグバウンティ制度と脆弱性開示プロセスへの強い不満だ。 Microsoftはこれに対し「顧客に実害をもたらす悪意ある活動」への法的措置も辞さないと警告。セキュリティ研究者コミュニティの間では、この表現が研究者個人への脅しと受け取られ、批判を集めた。 なお、GreenPlasma・MiniPlasma・YellowKeyの3件は6月のPatch Tuesdayで修正済み。RoguePlanetはその後に開示されており、修正が未適用のまま残っている状況だ。 日本のIT管理者が今できること パッチが存在しない以上、完全な防御は不可能だが、攻撃の連鎖を断ち切るための対策は存在する。 Defenderの定義・エンジンを最新状態に維持する: 本脆弱性のパッチではないが、エンジン更新に関連する変更が含まれる可能性がある 最小権限の原則を徹底する: SYSTEM権限が奪われた後の横展開を防ぐため、アカウント分離・ネットワーク分離を強化する EDR/SIEMの検知ルールを見直す: 不審なSYSTEMプロセス生成やコマンドプロンプトの異常起動を検知できるルールが入っているか確認する パッチリリース即展開の体制を整備する: Defenderは自動更新が基本だが、組織ポリシーで遅延設定している場合は展開プロセスを前倒しで見直しておく 特に大規模環境では「パッチが出てから考える」では遅い。今のうちにDefender関連パッチの緊急展開フローを確認しておきたい。 筆者の見解 技術的に見て、Defenderのコアエンジンにレースコンディションが存在したという事実は興味深い。セキュリティ製品は高度に複雑なソフトウェアであり、こういった脆弱性がゼロになることは現実的にはありえない——そのこと自体は理解できる。 ただ、Nightmare Eclipseが次々とゼロデイを公開し続けるという異例の展開は、Microsoftのバグバウンティ制度の設計に根本的な問題があることを示唆している。研究者を「顧客への脅威」として法的に牽制するよりも、正当な報告に対して適切な評価と報奨を行う仕組みを整える方が、長期的には顧客保護につながるはずだ。Microsoftにはその実力があるからこそ、もったいないと感じる。 Defenderは世界中の何億台ものWindowsデバイスを守る要だ。その信頼性を高めるためにも、セキュリティ研究者コミュニティを敵に回すのではなく、協調関係を築く方向に舵を切ってほしい。今からでも遅くはないと思っている。 出典: この記事は Microsoft working on Defender patch for RoguePlanet zero-day の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Tom’s Guideが2026年6月17日に報じたところによると、インターネットに溢れるAI生成コンテンツが次世代AIモデルの訓練データを蝕む「モデル崩壊（Model Collapse）」問題について、King’s College Londonらの国際研究チームが驚くほどシンプルな解決策を発表した。 モデル崩壊とは何か 現代のAIは、インターネット上の膨大なテキストや画像から学習する。かつてウェブのほぼすべてが人間の手によるものだった時代、この手法は非常に有効だった。しかし現在は推計でウェブ上のテキストの半数以上がAI生成とされており、状況は一変している。 新しいAIが古いAIの出力から学習し、そのAIがさらに前世代のAIの出力から学習する——この連鎖が「モデル崩壊」だ。2024年に英オックスフォード大学・ケンブリッジ大学チームが学術誌『Nature』に発表した論文がこの概念を正式に定義し、AI生成コンテンツだけで訓練を続けると多様性と品質が徐々に劣化し、最終的には繰り返しのナンセンスへと退化することを示した。フォトコピーのコピーを繰り返すように、世代を経るごとに劣化が蓄積する。 「たった1つの人間データ」で崩壊を防げる 2026年5月、King’s College London・ノルウェー科学技術大学・アブドゥスサラム国際理論物理学センターの合同研究チームが学術誌『Physical Review Letters』に発表した研究が注目されている。Tom’s GuideのライターAmanda Caswellが伝えた内容によれば、研究チームはAIの「データ共食い」問題を検証し、次の発見をした。 AIの自己生成データだけで訓練を続けると崩壊は不可避 しかし閉じたループの外から「たった1つの本物の人間由来データポイント」を混入するだけで、崩壊を毎回防げた その1つのアンカーは、AI生成データの量が増えても機能し続けた この発見は完全な大規模言語モデルではなく、より単純な統計モデルで示されたものだ。ただし、現実との接地点がいかに小さくても崩壊防止に機能するという原理は、業界全体への強力な示唆を持っている。 なぜ今この問題が深刻か AI企業がモデル訓練に使える質の高い人間由来のテキストは枯渇に近づいているとも言われている。その状況でAI生成コンテンツへの依存度が高まれば、崩壊リスクはさらに加速する。Tom’s Guideはこれを「食欲は増し続けるが、食事のサイズは縮み続けるフィードバックループ」と表現している。 日本市場での注目点 この研究は「明日から体感できる変化」ではないが、日本企業のAI戦略に対して重要な問いを投げかけている。 社内ドキュメントや業務記録といった「人間が書いた質の高いデータ」の蓄積が、将来的な自社AI活用の競争力を左右する可能性がある。AIが生成したコンテンツを無批判に社内知識として取り込み続けることは、知識ベースの品質劣化につながるリスクを秘めている。 OpenAI・Google・Anthropicといった主要AIプロバイダーのモデル訓練品質に直接影響する問題であるため、AIツールを業務導入しているすべての企業が関係者だ。 筆者の見解 AIエージェントが自律的にループで動き続ける設計が現実のものになりつつある今、そのループが処理するデータの質は根本的な問題だ。モデル崩壊は単なる学術的懸念ではなく、AI活用基盤そのものの信頼性に関わる。 特に興味深いのは「たった1データポイントでも現実のアンカーが機能する」という発見だ。これは、AIシステムのアーキテクチャ設計において「人間の知性が介在するポイント」を意図的に組み込む重要性を示唆している。完全自動化を目指す際も、どこかに現実との接地点を維持する設計が、長期的な品質担保の鍵になりそうだ。 AI生成コンテンツが溢れる今こそ、本物の人間の経験・知識・文脈を価値あるものとして守る仕組みづくりが、個人・企業レベルで問われている。 出典: この記事は The internet is full of AI slop, and it might be poisoning the next ChatGPT. New research says how to stop it の内容をもとに、筆者の見解を加えて独自に執筆したものです。

DockerでAzure SDKが断続的にタイムアウトする。原因はAzureじゃなかった🤖✍️ この記事はAIとの共同執筆です ── AIエージェント（Claude Code）が実際の共同作業の経験をもとに下書きを自動生成し、胡田が内容を確認・修正したうえで公開しています。 続きをみる note.com で続きを読む →