Tech News JP

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 コードファースト」という軸で住み分けてきたが、今回のマネージドコネクタ対応でその境界線が意図的に曖昧にされた。両者をより柔軟に組み合わせられる環境に向かっている方向性は正しいと思う。 ...

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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

中国の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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Sony Xperia 1 VIIIのほぼ全スペックが、Amazon UKとAmazon Germanyへの誤掲載というかたちで明らかになった。NotebookCheckのMartin Filipov氏が2026年5月5日付けで報じたところによると、発売日は6月26日、英国での価格は**£1,728**と、前モデルXperia 1 VIIから大幅な値上がりとなっている。 なぜ注目か——Xperia 1シリーズの立ち位置 Xperia 1シリーズは、Sonyが「妥協なきフラッグシップ」として毎年投入するラインナップだ。19.5:9という縦長ディスプレイ、3.5mmオーディオジャック、Alphaシリーズと同系統のカメラエンジンなど、他社にない独自性で根強いファンを持つ。今回のXperia 1 VIIIでは、チップセットにSnapdragon 8 Elite Gen 5、ストレージは最大1TB、OSはAndroid 16をプリインストールと、ハードウェア面での世代交代が確認されている。 Amazonリーク情報から判明した主なスペック 項目 仕様 ディスプレイ 6.5型 19.5:9 FHD+ HDR OLED / 120Hz チップセット Snapdragon 8 Elite Gen 5 カメラ トリプルレンズ（新型望遠レンズ搭載、48MP望遠と推定） OS Android 16（5メジャーアップデート保証） ストレージ 最大1TB オーディオ 3.5mmジャック搭載 SIM デュアルSIM対応 バッテリー 「2日間」駆動をうたう カラー Graphite Black / Iolite Silver / Garnet Red 発売日 2026年6月26日 カメラ部のデザインは、従来の「カメラストリップ」からスクエアカメラアイランドへと変更された。また「Xperia AI」と呼ばれるAI機能が写真撮影やバッテリー管理を最適化するとされている。 NotebookCheckは、microSDカードスロットの記載がリストに存在しない点を指摘しつつ、「廃止については慎重に楽観視している」と述べている。 価格の衝撃——WH-1000XM6同梱が鍵か 最も注目を集めているのが価格だ。 英国: £1,728（前モデルXperia 1 VIIは約£1,399） ドイツ: €1,858〜€1,868（前モデルは約€1,599） 約20〜30%の値上げとなるが、NotebookCheckの分析によると以下の3つの可能性が挙げられている。 ...

Anthropicは2026年6月16日（現地時間）、自動化ツール向けSDK「Claude Agent SDK」への新課金体系の適用を、実施直前に一時停止したと発表した。米メディアArs TechnicaのKyle Orland氏が報じた。 何が変わるはずだったのか Anthropicは5月13日、Agent SDKの利用（サードパーティアプリやclaude -pコマンドによるプログラム的な利用を含む）を、通常のClaudeチャット利用や公式CLIとは別枠で課金する計画を発表していた。 新体系ではAgent SDK経由の利用をAnthropicの通常API料金で課金し、サブスクリプション加入者にはサブスクリプション料金相当の月次利用クレジットが付与される仕組みとなる予定だった。 現行プランとの差は大きい 現在のサブスクリプションでは、Agent SDK利用はサブスクリプションティアに応じた週次上限内に収まる限り、追加費用なく利用できる。Ars Technicaが紹介したデベロッパー・Matthew Diakonov氏の分析によれば、Claude OpusをコーディングアシスタントとしてフルAPIで使うユーザーは1日わずか2〜3メッセージで損益分岐点を超えるほど、サブスクリプションの「価値」はAPI料金換算で大きいとされる。 コードエディタ「Zed」の開発チームも変更発表直後、ユーザーへの注意喚起として「エージェントを多用するユーザーには重大なコスト増になる」と警告を出していた。 一時停止の背景 Anthropicは課金サポートページを更新し、「Agent SDK使用に関する変更を一時停止する」と発表。「現時点では何も変わっておらず、Claudeサブスクリプションでのユーザーのビルド方法をより良くサポートするためにプランを更新中」とコメントしている。 このタイミングは注目に値する。GitHub CopilotがトークンベースのAPI課金に移行し、ユーザーの「請求額ショック」が問題となった数週間後であり、またAnthropicがIPO（新規株式公開）に向けてSECに機密書類を提出したとも報じられている文脈での決断だ。 なお、AnthropicのClaude Code責任者であるBoris Cherny氏は4月の時点で「我々のサブスクリプションはサードパーティツールの利用パターンを想定して設計されていない」と述べており、何らかの形での課金見直しは以前から示唆されていた。 日本市場での注目点 日本でもClaude Codeやclaude -pコマンドを使ったエージェントハーネスを構築しているエンジニアにとって、今回の一時停止は当面の安堵となる。ClaudeのProプランは月額20ドル（約3,000円）程度からクレジットカードで契約でき、日本からも利用可能だ。 ただし、今回はあくまで「一時停止」であって撤回ではない。自動化ツールや独自エージェントに依存する開発者は、Anthropicのブログやサポートページをウォッチしながenvoy、将来的な課金変更を前提とした利用量の把握と代替プランの検討を今のうちに始めておくのが現実的な備えとなる。 筆者の見解 今回の方針転換は、Anthropicが「サブスクリプションの想定外の使われ方」にどう向き合うかという課題の答えを、まだ出しきれていないまま走り続けていたことを示している。 Agent SDKを使い込んでいる開発者が、サブスクリプション料金でAPI換算の何倍ものリソースを消費できているという現実は、ビジネスとして長期的に維持できるものではない。何らかの形での課金モデル見直しは避けられないだろう。 とはいえ、GitHub Copilotが課金変更直後に「スティッカーショック」問題を起こした前例を踏まえれば、今回Anthropicが急いで設計を見直す判断をしたことは評価できる。ヘビーユーザーが多く存在する自律エージェント領域は、まさにAI活用の最前線でもある。サブスクリプション設計の難しさは承知の上で、開発者が積極的に試せる価格体系を丁寧に作り直してほしい——そこに期待を込めたい。 出典: この記事は Anthropic “pauses” token-based billing for its Claude Agent SDK の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Tom’s GuideのJohn Velasco記者が現地時間6月16日に報告したとおり、Googleは「Android 17」のPixelデバイスへの正式配信を開始した。一部はGoogle I/O 2026や「The Android Show: I/O Edition」では明かされていなかった新機能も含まれている。Pixelオーナーは同日、「2026年6月Pixel Feature Drop」とWear OS 7の最適化アップデートも受け取ることになる。 なぜAndroid 17が注目されるのか Android 17は単なるバージョンアップではなく、生産性・ゲーミング・セキュリティという3つの軸で大きな進化を打ち出したアップデートだ。マルチタスク支援機能の充実と、スマートフォン紛失・盗難を想定したセキュリティ強化は、コンシューマー・ビジネスどちらの文脈でも意義深い。 海外レビューのポイント：主要新機能 バブル機能（Bubbles） Tom’s Guideの報告によると、任意のアプリをフローティングウィンドウに変換して表示できる機能が追加された。大画面デバイスでは画面下部にコンパクトな形でアプリにアクセスでき、パワーユーザーのマルチタスクを大幅に効率化するという。 スクリーンリアクション（Screen Reactions） 画面録画ツールバーが刷新され、デバイスの画面とインカメラを同時録画できる機能が追加された。コンテンツ制作者やオンラインプレゼンテーションでの活用など、映像表現の幅が広がる改善だ。 折りたたみゲーミングモード（Foldable Gaming Mode） Pixel 10 Pro Foldなど折りたたみ端末向けに、バーチャルオンスクリーンゲームパッドが利用可能になった。画面上半分にゲーム、下半分にコントローラーという50/50レイアウトを実現する。 生体認証「紛失としてマーク」（Biometric “Mark as Lost”） Tom’s Guideによると、端末紛失時にFind Hubから生体認証でリモートロックができる機能が追加された。「泥棒がパスコードを知っていてもデータへのアクセスや追跡無効化を防ぐことができる」と説明されており、多層防御の考え方が実装されている。 プライバシー＆盗難対策の強化 アプリへの位置情報共有を「一時的・詳細位置」に限定したり、連絡先全体ではなく特定の連絡先のみを共有する細かい設定が追加。PIN試行回数の制限と待機時間延長によるブルートフォース対策も強化された。 2026年6月Pixel Feature Drop：AI・クリエイティブ機能も充実 同時配信のFeature Dropでは以下のAI機能が追加されている： Gemini Omni：テキストプロンプトから高品質な動画を生成（Gemini Proユーザー向け） Lyria 3：テキストや画像からオリジナル楽曲を作成するAI音楽生成機能 Conversational Editing：音声指示による写真の複合編集（ドイツ・英国・フランス・スペイン・イタリア向け） Android Quick Share拡張：Pixel 8aおよび9aユーザーのクロスプラットフォームファイル共有機能が拡大 なお、最も注目された「Gemini Intelligence」は今夏後半への配信となり、今回のリリースには含まれていない。 日本市場での注目点 日本向けPixelでも、Android 17の配信は同時期または近日中に展開されると見込まれる。折りたたみゲーミングモードはPixel 10 Pro Fold向けの特化機能だが、バブル機能はすべてのPixelユーザーが恩恵を受けられる汎用的なアップグレードだ。 プライバシー強化機能は個人情報保護への関心が高い日本市場でも実用的な価値が高い。特に位置情報の粒度設定と連絡先の選択共有は、ビジネスシーンでも有用な機能となる。Conversational Editingは現時点でヨーロッパ数か国のみの展開で、日本語対応の時期は未発表。続報に注目したい。 筆者の見解 今回のAndroid 17で特に評価したいのはセキュリティ機能の設計思想だ。「生体認証によるリモートロック」は、パスコード流出という最も現実的な脅威シナリオに対して、別の認証レイヤーで守るという多層防御アーキテクチャを正しく実装している。端末を物理的に失った後でも守れる仕組みは、スマートフォンを業務利用する場面でも心強い。 ...

Claude Code、最高なんだけど「記憶」の扱いが難しい続きをみる note.com で続きを読む →