Tech News JP

Windows 11を使っていて、「スタートメニューを開いたときのあのコンマ数秒のもたつき」が気になったことはないだろうか。Macが瞬時に反応する映像を見るたびに、同じような快適さをWindowsでも——と感じているユーザーは少なくないはずだ。そのギャップを埋める可能性を持った機能が、Windows 11のInsiderビルドで密かにテストされていることがわかった。その名も「Low Latency Profile（低レイテンシプロファイル）」。アプリ起動を最大40%、スタートメニューの反応を最大70%高速化するという、かなり野心的な機能だ。 Low Latency Profileとは何か この機能は、OSのスケジューラに組み込まれた新しい仕組みだ。ユーザーがアプリをクリックしたり、スタートメニューを開いたり、右クリックメニューを呼び出したりといった「高優先度の操作」を検知した瞬間、CPUのクロック周波数を1〜3秒間、最大付近まで一気に引き上げる。 従来のWindows 11では、こうした操作に対してCPUがすぐに全力を出すわけではなかった。電力効率や発熱を優先してクロックが抑制された状態から徐々に上昇するため、UIの描画が微妙に遅れる。この「微妙な遅れ」こそが、他のOSと比較したときに「もっさり」と感じられる原因のひとつだ。 Low Latency ProfileはこのUIレイテンシ問題に対して、一見ブルートフォース的に見えるアプローチで応える——ただし、実態は非常に精巧なスケジューラの拡張だ。ユーザーへのコントロール手段は現時点で設けられておらず、完全にOSが自動で制御する設計になっている。 テスト結果：低スペック環境での劇的な変化 Windows Latestによるテストでは、意図的に制限した仮想環境（Intel 13th Gen i5-13420H、デュアルコア、RAM 4GB）で検証が行われた。 機能オフの状態では、スタートメニュー・File Explorer・Edge・Outlookのいずれも明確なもたつきが確認された。CPUの使用率は一瞬上昇するものの、クロックは抑制されたままで、OSが「のんびり」ソフトウェアを起動する様子が観察された。 機能オンの状態では状況が一変した： スタートメニューが「即座に」開く。同テスター曰く「VMでここまで速く表示されたのは初めて」 Microsoft Edgeを起動した際、CPUが96%まで急上昇 → ブラウザウィンドウが瞬時に表示 → 3秒以内に17%以下へ収束 Outlookでも同様に97%まで瞬間スパイク後、3%前後に安定 Microsoft Copilotアプリも96%のスパイクを経て、明らかに速い起動を実現 この「急上昇→即収束」のパターンが鍵だ。1〜3秒という短さが、バッテリーや熱への影響を最小限に抑えつつ、ユーザーが体感する「開いた」という瞬間に確実に間に合う設計になっている。 なぜこれが重要か——日本の現場視点で 日本のIT現場に目を向けると、法人PCは予算の関係からエントリークラスのモデルが多数稼働している。特に中小企業や教育機関では、4〜8GBのRAMに第10世代前後のCPUを積んだPCが現役のケースは珍しくない。 こうした環境では、Windows 11のUIが「重い」という印象が固定化していることも多く、それが「まだWindows 10でいい」という声の温床にもなってきた。Low Latency ProfileはOSのアーキテクチャを根本から変えることなく、既存ハードウェアのポテンシャルを引き出す——この点が重要だ。PCの買い替えサイクルを延ばしながら、ユーザー体験を底上げできる可能性を持っている。 実務での活用ポイント 現時点ではWindows Insider Programのビルドにのみ搭載されており、正式リリース版への導入時期・仕様変更の可能性は未定だ。IT管理者・エンジニアが今できることを整理する。 Insiderビルドで先行検証する: Dev/Canaryチャネルで動作確認しておくと、本番展開前に挙動を把握できる。特に省電力設定が強い機種での振る舞いは事前確認が望ましい 電力プランとの相互作用を確認する: バランスモード／高パフォーマンスモードとの組み合わせで振る舞いが変わる可能性がある。モバイル機では特に注意 低スペックPCの延命戦略に組み込む: 正式リリース後、エントリー機の体感速度改善が期待できる。PC刷新計画のタイミング判断材料として考慮に値する 「PCが遅い」という声への対応として: ユーザーからの体感速度への不満の一部は、この機能の普及で自然と解消される可能性がある 筆者の見解 率直に言って、これは「地味だが正しい方向性の改善」だ。 Windowsの細かいアップデートを逐一追う意義は年々薄れている——それが正直な感覚だ。しかしLow Latency Profileは、そうした惰性を覚ます。「既存ハードウェアのポテンシャルを引き出す」という発想は、ユーザーにとってもIT投資の観点からも本質的に意味がある。 Microsoftはこういうことを地道にやる力がある。OSスケジューラに手を入れ、ユーザーに意識させずにレスポンスを改善するアプローチは、正しいエンジニアリングだ。できれば、こういう取り組みがもっと前面に出てきてほしい——と思う。それだけの実力があるのだから。 機能の正式提供後、特に低スペック機が多い日本の法人・教育環境での効果を確認したい。現場で「速くなった」という声がどれほど上がるか——それが真の評価軸になる。 出典: この記事は I tested Windows 11’s hidden Low Latency Profile, and budget PCs are about to feel premium の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

学習管理システム（LMS）最大手のInstructureが運営するCanvasが、ランサムウェアグループ「ShinyHunters」によって再度侵害された。約330の大学・高等教育機関のCanvasログインポータルが改ざんされ、「要求に応じなければ学生・教職員データを公開する」という脅迫メッセージが表示された。期限は2026年5月12日。この事件は、教育機関が標的にされるサイバー攻撃の深刻化と、SaaSプラットフォームのセキュリティモデルそのものへの根本的な問い直しを迫るものだ。 何が起きたか 先週、ShinyHuntersはInstructureから8,809校に紐付く学生・スタッフの2.8億件超のレコードを窃取したと主張した。盗まれたデータには、ユーザー情報・プライベートメッセージ・履修データなどが含まれるとされる。Instructureはデータ流出自体は認めつつも、詳細調査を継続中としていた。 その翌週——今回の事件だ。ShinyHuntersは「Instructureが無視して『セキュリティパッチ』だけ当ててきた」と主張し、報復として約330機関のログイン画面を30分間にわたって改ざん。モバイルアプリにも同じメッセージが表示されたという。Instructureはその後Canvasをオフラインに落として対応している。 ShinyHuntersとはどういう集団か 2018年から活動しているShinyHuntersは、特定の単一グループというよりも、同名を掲げる複数の脅威アクターが緩やかに連携した形態をとっている。近年の手口の特徴は以下の通りだ。 SaaS環境への直接攻撃: SalesforceをはじめとするクラウドSaaS環境を主なターゲットとし、盗んだ認証トークンで接続先サービスへ横移動する サードパーティ経由の侵入: 直接ターゲットを狙うのではなく、連携している外部サービス・インテグレーション企業を踏み台にする ビッシング（音声フィッシング）: OktaやMicrosoftのSSO担当を装い、従業員からMFAコードを騙し取る手口も確認されている デバイスコードフィッシング: BleepingComputerが報じたように、Microsoft Entraの認証トークンをデバイスコードフロー経由で奪取する新手法も採用している 最後の点は特に注意が必要だ。Entraを認証基盤として使っている組織では、一見正規の認証フローを悪用されるリスクがある。 実務への影響——日本の教育機関・IT管理者に問いかけるもの Canvasは日本国内でも複数の大学が採用している。今回の直接被害が国内に及んだかどうかは現時点で不明だが、「うちはまだ被害を受けていない」という認識は危険だ。この事件から引き出せる実務上の教訓は以下の通りだ。 SaaSのログイン改ざんは「侵害の結果」ではなく「侵害の証拠」 今回の改ざんは脅迫のための示威行為だったが、それ以前にInstructure内部へのアクセス権を取得済みだったということを意味する。ログイン画面が正常に見えていても、バックエンドで何が起きているかは別問題だ。 2. MFAを突破される前提で考える ShinyHuntersはMFAコードをソーシャルエンジニアリングで奪取する。「MFAを入れているから安全」という認識はすでに通用しない。フィッシング耐性のある認証（FIDO2/パスキー）への移行が現実的な次のステップだ。 3. テナント連携・API連携の棚卸しを今すぐ ShinyHuntersの典型的な手口はサードパーティ連携経由の横移動だ。自組織のSaaSにどのサービスが接続されているか、OAuth連携の認可スコープが適切かを定期的に確認する必要がある。特にCanvasのようなLMSはAPIが豊富で、設定次第では大量データをエクスポートできる。 4. デバイスコードフローは制限できる Microsoft Entra（旧Azure AD）を使っている組織であれば、条件付きアクセスポリシーでデバイスコードフローを制限・監視することが可能だ。ShinyHuntersが採用している手口への直接的な対策として有効だ。 筆者の見解 今回の事件でもっとも気になるのは、Instructureの対応の鈍さだ。初回侵害から約一週間、複数のメディアからの問い合わせに無回答のまま今回の改ざんを迎えた。「調査中」のフェーズであっても、影響を受けた機関への情報提供や暫定的なミティゲーション手順の共有くらいは動けたはずだ。 とはいえ、これを対岸の火事として眺めるだけではもったいない。SaaS依存が進んだ現代のIT環境で「プラットフォームベンダーのセキュリティに依存しきる」ことのリスクが、今回ほどはっきり可視化された事例もそうはない。 ゼロトラストの考え方は「内側は安全」という前提を捨てることから始まる。SaaSが侵害されても被害が最小化されるよう、アクセス権は最小限に・常時付与ではなくJust-In-Time（JIT）で・ログは中央で監視する——この3原則を、プラットフォームのセキュリティ体制を問わず自組織側で徹底することが、今の時代の現実的な身の守り方だ。 教育機関のデータには、成人になる前の学生の個人情報が大量に含まれている。影響を受けた学生に「あなたのデータが漏れたかもしれない」と伝える責任を果たせるかどうか——それがベンダー選定の本当の基準になる日が、もうそこまで来ている。 出典: この記事は Canvas login portals hacked in mass ShinyHunters extortion campaign の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIエージェントが実際のビジネスデータを扱う「本番環境」に踏み込み始めると、デモ段階では見えなかった問題が一気に顕在化する。「誰でも全部見える」状態でよかったプロトタイプが、リリース直前になって「データ境界をどう守るか」という根本的な問いを突きつけてくる。 CurityとMicrosoftがAzure SDK Blogで公開した新しいazdテンプレートは、まさにその問いに正面から答える試みだ。AIエージェントへの最小権限（Least Privilege）アクセスの実装パターンを、すぐ試せる形で提供している。 問題の本質：エージェントは「予測できない」クライアントだ 従来のクライアントアプリはAPIを決まった手順で呼ぶ。コードを読めば何をするか分かる。しかしAIエージェントは違う。自然言語を解釈して、何を呼ぶかを自分で決める。賢いが、予測不能でもある。 さらにプロンプトインジェクション——悪意あるユーザーが入力を細工してエージェントの動作を乗っ取る攻撃——のリスクも現実にある。エージェント側でいくら「正しい判断」をしようとしても、それだけでは足りない。APIレイヤーで「このトークンではここまでしか見えない」という制約を設けなければ、AIの不完全さや悪用に対して無防備のままだ。 テンプレートの核心：短命トークンと2段階のトークン交換 このテンプレートのポイントは、OAuth 2.0の短命アクセストークンによる認可だ。エージェントはAPIへの恒久的な権限を持たない。必要なときだけ、必要な範囲に絞ったトークンを取得して使う。 注目すべきは2段階のトークン交換設計だ。 第1交換: ユーザーの初期トークンのスコープを絞り込み、不透明トークン（Opaque Token）からJWT（JSON Web Token）に変換する 第2交換: エージェントのIDを付加し、MCPサーバー向けの新しいaudienceに変換する 最終的にPortfolio MCPサーバーに届くトークンには、scope: stocks/read（読み取り専用）、customer_id: 178（Entra IDの属性から取得）、region: USA（参照可能な株式の地域制限）、client_type: ai-agentが含まれる。APIはこれらのクレームを見て、「このリクエストは誰のためのものか・何が許可されているか」を判断できる。エージェントがどんな指示を受けたかは関係ない。 テンプレートの構成 インフラとしては以下が含まれる。 バックエンドエージェント: Microsoft Foundry上でC#実装（Microsoft A2A・MCP SDK使用） MCPサーバー: サンプルポートフォリオAPIを公開 認可サーバー: Curity Identity Server（ユーザー認証はMicrosoft Entra IDと連携） ゲートウェイ: 外部・内部APIゲートウェイでトークン交換と監査ログを担当 IaC: Bicepで完全自動プロビジョニング（Container Apps、Azure AI Foundry、Key Vault、Azure SQL Database等） azd up数コマンドでAzureサブスクリプション上に全体が動く状態になる。 実務への影響 日本のエンジニアが今すぐ取り組めるヒント： まずこのテンプレートをそのまま動かし、トークンの内容がどう変わるかを自分の目で確認してほしい。JWTデコーダーで中身を覗きながら「誰が・何のスコープで・どのAPIを呼べるか」の流れを追うことで、設計の全体像がつかめる。 次に、既存のAIエージェント実装を振り返ってみる価値がある。エージェントに渡しているトークンに有効期限は設定されているか？スコープは最小化されているか？ 「動いているからOK」は安全の証明にならない。特権アカウントやサービスプリンシパルに権限を無期限で与えている構成は、早急に見直すべきだ。 Microsoft Entra IDを使っている環境では、ユーザー属性（部署・地域・ロール等）をトークンのクレームとして活用するカスタムクレームの設定も検討に値する。属性ベースのアクセス制御（ABAC）は、エージェント時代のきめ細かいデータ境界を実現する重要な武器になる。 筆者の見解 AIエージェントがNon-Human Identity（NHI）として組織内で動き始める今、「誰がAPIを呼んでいるか」だけでなく「何のためにどこまで呼べるか」を制御する仕組みが不可欠になっている。 このテンプレートが示す「短命トークン＋2段階交換」のパターンは、ゼロトラストの原則をエージェントに忠実に適用したものだ。常時アクセス権を与えず、必要なときだけ必要なスコープで動かす——これはJust-In-Timeアクセスの考え方そのものであり、特権アカウント管理の世界ではすでに常識になっている。AIエージェントという新しいアクターにも、この原則を妥協なく貫く必要がある。 Microsoft Entra IDをエージェントの「管制塔」として使い、その上でサードパーティの認可サーバーと組み合わせるアーキテクチャは、Azureプラットフォームの強みを素直に活かした設計だ。この方向性は正しいと思う。 あとは、このパターンがテンプレートで終わらず、公式ドキュメントやベストプラクティスとして広く普及するかどうかが鍵だ。設計パターンをいかに「開発者が自然と選ぶ道」にするかが、セキュアなAIエージェント普及の分水嶺になる。 出典: この記事は Least privilege AI agents: A new azd template from Curity and Microsoft の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

OpenAIが2026年5月7日、コーディング支援AIプラットフォーム「Codex」のChrome拡張機能をリリースした。Engadgetが同日報じたもので、ブラウザ上でのAI支援機能を大幅に拡張する今回のアップデートは、開発者だけでなく幅広いユーザー層への訴求を狙った動きとして業界から注目されている。 なぜこの拡張機能が注目か CodexはOpenAIが2026年2月にmacOSアプリとしてリリースし、4月に追加機能を提供した比較的新しいプラットフォームだ。今回のChrome拡張機能の登場により、デスクトップアプリに限られていた機能がWindowsとMacの両環境でブラウザを通じて利用可能になる。 特に注目すべきは、Codexが「コーディング専用ツール」の枠を越え始めたという点だ。現代の多くの業務がブラウザ上で完結する状況を踏まえると、ブラウザに組み込まれたAI支援は開発者以外の職種・ユーザー層へのアクセス拡大を意味する可能性がある。 Chrome拡張機能の主な機能 Engadgetの報道によると、今回リリースされた拡張機能には以下の機能が含まれる： Webアプリのテスト自動化: ブラウザ上でWebアプリを自動テスト タブ横断のコンテキスト収集: 複数の開いているタブから文脈情報を収集し、より精度の高いAI支援を実現 Chrome DevToolsの並列活用: ユーザーが別の作業をしている間も、DevToolsを効率的に並列操作 結果の整理: ブラウザを占有せずに作業結果を整理・管理 OpenAI Developersの公式アカウントは「Webアプリのテスト、タブ横断のコンテキスト収集、DevToolsの効率的な並列使用、ブラウザを占有せずに結果を整理できる」と機能概要を説明している。 今後の計画：ChatGPTおよびAtlasとの統合 Engadgetの報道によれば、OpenAIは将来的にCodexとChatGPT、さらに自社開発のWebブラウザ「Atlas」を統合した一体型アプリの提供を計画しているという。実現すれば、AIコーディング支援・チャットbot・AIブラウザが単一プラットフォームに集約されることになり、Microsoftのエコシステム統合戦略に対抗する動きとも読める。 日本市場での注目点 現時点で日本向けの価格や公式展開日についての発表はないが、Chrome拡張機能という性質上、ブラウザを通じて世界同時に近い形での利用が期待できる。競合としては、GitHub CopilotのIDEプラグインやGoogle GeminiのChrome拡張機能がすでに市場に存在する。Codexはコーディング特化プラットフォームを起点にブラウザへと展開する独自のポジショニングを打ち出している形だ。 日本のエンジニアや開発者にとって鍵となるのは、既存のOpenAIアカウントでそのまま利用できるかどうかだ。CodexのAPIはすでに一部ユーザー向けに提供されているが、Chrome拡張機能の広範な提供状況については公式情報を随時確認されたい。 筆者の見解 今回のChrome拡張機能は、方向性として理解できる一手だ。ブラウザという誰もが日常的に使う環境にAI支援を組み込む発想は合理的だし、「ユーザーが別の作業をしている間も並列で動作できる」という点には自律エージェント的な芽が見える。 ただし、ここで問うべきは「どこまで自律的に動くか」だ。目的を渡すだけで自律的にタスクを遂行・検証するエージェントになれるのか、それとも逐一確認・承認を求める設計にとどまるのか——この違いが実用価値を大きく左右する。確認・承認を人間に求め続ける設計では、認知負荷の削減という本質的な価値を得にくい。 ChatGPTおよびAtlasとの将来的な統合計画も興味深い視点を提供する。一体型プラットフォームが実現すれば、コーディング支援を超えた統合的なAIエージェント体験が生まれる可能性がある。一方で、機能を詰め込むほど「何でもできるが何も深くない」製品になるリスクも伴う。統合の質と自律性の深度こそが、今後の評価軸になるだろう。 日本の開発者としては、情報を追いかけるよりも実際に触れてみて、自分の業務フローにどれだけ組み込めるか試してみることが先決だ。実際に使って成果を出す経験の積み重ねが、どのツールが本当に使えるかを判断する唯一の基準になる。 出典: この記事は OpenAI debuts a Codex plugin for Chrome の内容をもとに、筆者の見解を加えて独自に執筆したものです。

はじめてのオフラインイベント続きをみる note.com で続きを読む →

EUが2026年5月7日、AIに関する包括的規制法の修正について暫定合意した。PC Watchがロイターなどの報道を引用して伝えたもので、無断で性的に露骨な画像を生成するAIの禁止と、生成コンテンツへの透かし表示義務化が今年12月2日から適用される見通しだ。 なぜこの規制が注目か 今回の改正で最も注目されるのは、いわゆる「ディープフェイクポルノ」への直接的な規制だ。生成AIの急速な普及により、実在の人物の画像を無断で性的コンテンツに利用する被害が世界的に増加している。EUはAI法の修正という形でこの問題に正面から取り組む姿勢を鮮明にした。 透かし表示の義務化も重要な意味を持つ。「これはAIが生成したコンテンツである」という明示により情報の信頼性を担保しようという試みで、フェイクニュース対策や著作権保護の観点から長年議論が続いてきた課題に対して、一定の答えを出す形となる。 改正のポイント：施行時期の整理 PC Watchの報道によれば、今回の合意内容は以下のように整理される。 規制内容 適用時期 無断性的画像生成AIの禁止 2026年12月2日〜 生成コンテンツへの透かし表示義務化 2026年12月2日〜 高リスクAIシステムへの規制 延期 → 2027年12月2日〜 注目すべきは、生体認証・重要インフラ・法執行に関わる高リスクAIシステムへの規制が、当初の2026年8月2日から約1年4ヶ月延期されたことだ。業界からの現実的な準備期間確保要求を受けた判断とみられる。 日本市場での注目点 日本では2024年に「AI事業者ガイドライン」が整備されているが、EUのAI法のような法的拘束力を持つ規制はまだ存在しない。ただし、EUの規制は域外適用の可能性もあり、EU市場向けサービスを展開する日本企業・開発者には直接的な影響が及ぶ。 また、日本でも非同意のリベンジポルノやAIによるフェイク画像の流通が社会問題となっており、EUの規制動向は日本の法整備にも影響を与えることが予想される。生成AIサービスを提供する企業は、EU向けサービスにおける透かし技術の実装や、コンテンツポリシーの見直しを迫られることになるだろう。 筆者の見解 「禁止ではなく安全に使える仕組みを」というのが生成AI規制に対する筆者の基本スタンスだが、今回の規制に限っては方向性は正しいと考える。 無断で他者の性的画像を生成・流布することは、技術論以前に人権侵害だ。生成AIの民主化で誰でも高品質な画像を作れるようになった今、こうした悪用に歯止めをかける仕組みは不可欠になっている。今回の規制はその最低限の線引きとして機能するはずだ。 透かし表示の義務化についても、「AIが生成したものはそれと分かるべき」という規範を社会に根付かせる意義は大きい。技術の進化とともに透かしを除去する手段も出てくるだろうが、まずこのラインを法的に確立することに意味がある。 一方で、高リスクAI規制の1年超の延期は複雑な思いがある。業界の準備期間確保という実務的理由は理解できるが、延期した分だけ監視と議論を継続することが求められる。EUが先陣を切ってAI規制の枠組みを整備していること自体は評価しつつ、実効性がどこまで担保されるか、引き続き注視していきたい。 出典: この記事は 【やじうまPC Watch】EUがAI法改正に合意、AIによる無断性的画像の生成を年内禁止へ の内容をもとに、筆者の見解を加えて独自に執筆したものです。

中国のスタートアップMoonshot AIが公開した「Kimi K2.6」が、オープンウェイトモデルのトップ争いに割り込んできた。1兆パラメータのMoE（Mixture-of-Experts）モデルでありながら、HuggingFaceからウェイトを無償ダウンロードできるという開放性も注目を集めている。単なるベンチマーク上位モデルに留まらず、「何日もかけてコードを書き続けられるAIエージェント」という設計思想が、ソフトウェア開発の現場を根本から変えうる可能性を秘めている。 Kimi K2.6の技術的特徴 アーキテクチャ Kimi K2.6はMixture-of-Experts（MoE）アーキテクチャを採用しており、総パラメータ数は1兆だが、1トークンあたりの推論時には320億パラメータのみを活性化する設計だ。これにより大規模モデルの表現力を保ちながら推論コストを抑えている。視覚エンコーダには4億パラメータの「MoonViT」を搭載し、テキスト・画像・動画のマルチモーダル入力（最大256,000トークン）に対応する。 「エージェントスウォーム」——最大300並列エージェント Kimi K2.6の最大の特徴は「agent swarm（エージェントスウォーム）」モードだ。コーディネーターエージェントがタスクを分解し、最大300の並列サブエージェントを生成して協調実行させる。各エージェントは最大4,000ステップを実行できるようになっており（前世代のKimi K2.5では100エージェント×1,500ステップ）、担当エージェントが失敗・停止した際には自動的に再割り当てを行う。 さらに「claw groups」と呼ばれるプレビュー機能では、他の開発者が構築したエージェントや人間のコラボレーターまでをスウォームに組み込める。特定のモデルやデバイスに縛られない「異種混合エージェントチーム」の構想は、エージェント間連携の標準化という業界全体の潮流とも共鳴する動きだ。 preserve thinking——思考トークンの持ち越し マルチターン会話にわたって以前に生成した推論トークンを保持する「preserve thinking」モードは、長期コーディングタスクでのパフォーマンス向上に寄与すると報告されている。数日間にわたるplan-write-test-debugループを想定した設計であり、セッションをまたいで文脈を引き継げる点が実務上の強みとなる。 ベンチマーク性能 Artificial Analysis Intelligence Indexではオープンウェイトモデル首位（スコア54）を記録したが、クローズドモデルのトップ勢にはまだ届かない。同じオープンウェイト勢のQwen3.6 MaxやDeepSeek-V4-Proとはほぼ横並びであり、この三つ巴の状態はしばらく続きそうだ。グラデュエートレベルの科学問題（GPQA Diamond）や専門家レベルの多分野推論（HLE）、科学研究向けコード生成（SciCode）ではオープンモデル最高水準を記録している。 価格と入手性 APIはMoonshot経由で入力$0.95/100万トークン、出力$4.00/100万トークン。ウェイトはHuggingFaceから無料ダウンロード可能で、月間アクティブユーザー1億人以下・月次収益2,000万ドル以下の製品であれば商用利用も可能（変形MITライセンス）。無料のチャットインターフェース（kimi.com）やモバイルアプリも提供されており、手軽に試せる環境が整っている。 実務への影響——日本のエンジニアが今すぐ押さえるべきポイント 1. ローカル実行・自社インフラへの組み込みが現実的に ウェイトが公開されているため、クラウドAPIに依存せず自社インフラへの組み込みが可能だ。データをAPIに送りたくない日本企業や、ガバナンス上の理由でクラウドサービスの利用に制約がある組織にとって、オープンウェイト系モデルの性能向上は実質的な選択肢の拡大を意味する。 2. マルチエージェントのオーケストレーション設計が差別化要因に 単一プロンプトで問い合わせるのではなく、タスクを分解して複数エージェントを並列実行させる設計が実用領域に入ってきた。LangGraph、AutoGen、CrewAIといったエージェントフレームワークをすでに触っているエンジニアは、オーケストレーション設計のノウハウが今後の競争力に直結する段階に入っている。 3. 長期実行エージェントのインフラ整備が急務 「数日間ループで動き続けるエージェント」を本番運用するには、ログ管理・リトライ設計・コスト監視・どこで人間が介在するかの設計が不可欠だ。モデル性能の向上に合わせて、実行基盤の設計も同時に進化させなければならない。 筆者の見解 Kimi K2.6が示した「300並列エージェント×数日間ループ」というスペックは、AIエージェントが自律的にループで動き続ける仕組みの実用化がいよいよ本格化してきたことを象徴していると感じている。 単発の指示に応答するだけの「副操縦士」型AIから、目的を伝えれば自律的にタスクを遂行しつづける「自律エージェント」型へ——この移行こそが生産性革命の本丸だ。Kimi K2.6はその方向性として正しい道を歩んでいると思う。 一方、「claw groups」でサードパーティエージェントと連携できる設計は方向性として面白いが、現時点ではプレビュー段階。標準化やセキュリティモデルがどう整備されるかによって、実務での使い勝手は大きく変わる。モデルそのものの性能だけでなく、エコシステムとしての成熟度を継続的に見ていきたい。 オープンウェイトモデルの水準が急速に上がり続ける中、「どのモデルを使うか」よりも「どういうループとオーケストレーションを設計するか」に価値の重心が移ってきている。エンジニアとして今投資すべきは、特定モデルへの習熟よりも、エージェント設計とループ制御の知識だと確信している。 出典: この記事は Kimi K2.6 Matches Qwen3.6 Max and DeepSeek V4 on Agentic Coding Tasks の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年5月7日、MicrosoftはAzure AI FoundryのM365公開エージェントに深刻な脆弱性（CVE-2026-35435）が存在することを公開した。CVSSスコアは8.6（High）で、ネットワーク経由・認証不要・ユーザー操作不要での権限昇格が可能というシナリオだ。エンタープライズ環境でAIエージェントの活用を進めている組織は、今すぐ対応を開始すべき内容である。 脆弱性の技術的詳細 CVE-2026-35435の根本原因は CWE-284（不適切なアクセス制御） だ。CVSSベクターを読み解くと、この脆弱性の深刻さがよく見えてくる。 評価項目 値 意味 AV（攻撃経路） N（ネットワーク） インターネット越しに攻撃可能 AC（攻撃複雑性） L（低） 特別なスキルや環境が不要 PR（必要な権限） N（不要） 事前認証が不要 UI（ユーザー操作） N（不要） 自動化攻撃が成立する S（スコープ） C（変更あり） 影響がエージェント境界を越える C（機密性への影響） H（高） 情報漏洩リスクが高い 特に注目すべきは「スコープ変更あり（S:C）」という評価だ。これはエージェントのコンテキストを踏み台として、テナント内のより広いリソースへのアクセスが可能になることを意味する。M365のデータコネクタや業務データと連携したエージェントが侵害された場合、情報漏洩の範囲は想定をはるかに超える可能性がある。 影響を受けやすい環境 特に注意が必要なのは次のような構成だ。 公開スコープが広いエージェント: テナント外部や社内広域にアクセスを開放した公開エージェントは直接の攻撃対象になりやすい。匿名アクセスを許可している構成は特に危険だ。 機密データコネクタを接続しているエージェント: SharePoint、Exchange、Azure Storageなどと連携するエージェントは、侵害された際の影響範囲が業務データ全体に及ぶ可能性がある。 複数チームが共有するAIエージェントプラットフォーム: 共有コネクタや共有権限セットを持つ環境では、一点突破後の横移動リスクが高まる。 今すぐ取るべき対策 短期（即時対応） Microsoftのパッチ情報を継続監視する: MSRCのアドバイザリページ（CVE-2026-35435）を定期確認し、パッチが提供され次第、最優先で適用する 公開エージェントの一時制限を検討する: 広く公開されたエージェントについて、セキュリティレビュー完了まで公開スコープを絞ることを検討する エージェント操作の監査ログを確認する: 予期しない権限昇格の痕跡や、エージェントAPIへの不審なアクセスがないかをログで確認する。新規IPやサービスプリンシパルからのAPI呼び出し急増も要注意だ 中期（設計の見直し） エージェントコネクタへの最小権限適用: エージェントが本当に必要な権限だけを付与し、過剰な権限セットを排除する 条件付きアクセスの強化: エージェント管理操作に対してIP制限・デバイスコンプライアンスを組み合わせた条件付きアクセスを設定する Just-In-Timeアクセスの検討: エージェントの特権操作は常時付与ではなく、必要時だけ有効化する設計へ移行する 実務への影響 日本企業でも、Copilot StudioやAzure AI Foundryを活用してM365エージェントを構築・公開するケースが急増している。特に業務自動化の文脈でPower AutomateやAzureのデータコネクタと組み合わせた構成は多い。 こうした組織では、エージェントはもはや「ツール」ではなく「非人間アイデンティティ（NHI: Non-Human Identity）」として管理しなければならないという現実と向き合う必要がある。エージェントが持つ権限は、人間のアカウントと同様に—あるいはそれ以上に—厳密な管理が求められる時代になっている。 セキュリティ担当者はエージェントの権限棚卸しを今すぐ実施し、「そのエージェントに本当にこの権限が必要か」を一つひとつ確認してほしい。 筆者の見解 AIエージェントが業務システムの一部として定着しつつある今、こうした脆弱性は「AIの問題」ではなく「アイデンティティ管理とアクセス制御の問題」として捉え直す必要があると感じている。 ゼロトラストの本質は「信頼しない、常に確認する」だが、多くの組織ではエージェントへの権限付与がまだ人間アカウントと同じ温度感で扱われていない。「起動時にAdmin権限を持たせておけば楽」という発想は、人間のアカウントで言えば全員にグローバル管理者を付与するようなものだ。 Azure AI FoundryとCopilot Studioの基盤としての価値は揺るぎない。だからこそ、エージェント展開の際には「最小権限」「Just-In-Time」「スコープ管理」を設計の第一原則として組み込んでほしい。MicrosoftがMicrosoft Entra IDをエージェント管理の中核に据えている方向性は長期的に正しく、その仕組みを最大限に活用することが今後の鍵になると確信している。 ...

Ars Technicaが5月7日に報じたところによると、Firefoxの開発元Mozillaは、AnthropicのAIモデル「Mythos」を使って2ヶ月間で271件のFirefoxセキュリティ脆弱性を発見したと公式ブログで明らかにした。Mozillaの技術担当者は「AIによるバグ発見に完全に賭ける（completely bought in）」と表明しており、セキュリティエンジニアリングの現場にとって注目に値する発表だ。 なぜこの発表が注目されるのか AI補助による脆弱性発見は目新しいアイデアではない。しかし従来の手法では「コードをプロンプトで渡す→AIが大量のバグレポートを出す→人間が確認すると大半がハルシネーション」というサイクルが繰り返されていた。MozillaがMythosで達成したのは、この構造的な問題の実質的な克服だ。 Mozillaによれば、成功の核心は2点に集約される。（1）モデル自体の性能向上、そして（2）エージェントハーネスと呼ばれるカスタム実行基盤の開発だ。 海外レポートのポイント：ハーネスループが変えたもの Ars TechnicaによるMozilla Distinguished EngineerのBrian Grinstead氏へのインタビューによると、ハーネスとは「LLMを特定のタスク群に沿って動かすためのラッパーコード」のことだ。 Grinstead氏はその仕組みをこう説明している。「ハーネスはLLMに指示を与え（例：『このファイルのバグを探せ』）、ツールを提供し（例：ファイルの読み書きやテストケースの評価）、タスクが完了するまでループで実行し続けます」 特筆すべきは、このハーネスがMythosに対して、人間のMozillaエンジニアが使うのと同じ開発ツールやビルドパイプラインへのアクセスを与えている点だ。メモリ安全性の問題を探す際は、サニタイザビルドのFirefoxを使い、クラッシュを再現できれば「発見成功」という明確な成功基準が定義されている。 さらにもう一つのLLMが最初のLLMの出力を採点する「二段構え」の検証システムも導入されており、これが誤検知をほぼゼロに抑える要因になっているとGrinstead氏は述べている。Mozillaのエンジニアブログでは、「報告されるバグにおいて誤検知はほぼない（almost no false positives）」と明言されており、従来のファジングや静的解析ツールと遜色ない信頼性を達成していると評価されている。 日本市場での注目点 MythosはAnthropicが開発したセキュリティ向けの専用AIモデルであり、現時点では一般向けにリリースされているわけではない。FirefoxはWindows・macOS・Linux向けに無償提供されており、今回の取り組みはオープンソースプロジェクトのセキュリティ品質向上に直結する。 日本のソフトウェア企業・セキュリティチームにとっての実践的な示唆は、「Mythosを使う」ことよりも、エージェントハーネスという設計思想にある。明確な成功判定基準を定義し、AIエージェントをループで動かし続けるアーキテクチャは、コードレビュー・テスト自動化・セキュリティ監査のあらゆる場面に応用できる汎用的な考え方だ。 筆者の見解 「ハーネスループ」——この概念こそが、今回の発表を単なるAIヒューピー話から一線を画す理由だと筆者は見ている。 AIエージェントがループで自律的に動き続け、自分で仮説を立て、テストし、検証する。人間が全件確認するという副操縦士的な構造に留まらず、エージェント自身が判断・実行・検証のサイクルを回し続ける——これが本来のAIエージェントの姿であり、Mozilla×Mythosの取り組みはその具現化に成功した事例として評価したい。 従来型のAI補助ツールが「大量のプロンプト→大量のノイズ→人間が全件確認」という構造的なボトルネックを抱えていたのに対し、ハーネスを介した自律ループは「成功判定基準の設計」という最も人間らしいタスクに集中させ、それ以外はエージェントに任せる分業を実現している。 日本のIT現場でも、「AIに聞いてみたけど使えなかった」という経験が普及を阻んでいるケースは多い。しかし今回の事例が示すのは、問題はAI自体の能力ではなく、どう使うか——特に「どういうハーネスを設計するか」——にあるという点だ。セキュリティエンジニアだけでなく、開発プロセス全般を担うチームが参照すべき事例と言えるだろう。 出典: この記事は Mozilla says 271 vulnerabilities found by Mythos have “almost no false positives” の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

Tom’s Guideが5月7日に報じたところによると、GoogleのAndroidエコシステム担当プレジデント・Sameer Samat氏が、iOS 26で採用されたAppleの「Liquid Glass」に似たUIデザインをAndroid/Pixel 11に導入するという噂をX（旧Twitter）上で明確に否定した。 Apple「Liquid Glass」とは、なぜ騒動になったか iOS 26でAppleが導入した「Liquid Glass（リキッドグラス）」は、ガラスのような透明感と光の反射を組み合わせた新ビジュアルデザイン言語だ。賛否両論を呼びながらも、すでに複数のAndroidメーカーが類似デザインの採用に動いている。 Tom’s Guideの記事によると、VivoはLiquid Glass風のデザインを自社端末に採用済みで、OppoやSamsungもガラス調のUI要素を追加しているという。こうした業界の追随ムードを背景に、Googleも同様の方向に進むのではという噂が広まっていた。 噂の直接的な発端は、GoogleがAndroid Show: I/O Editionに向けて公開したティーザー動画。動画内でAndroidのマスコットキャラクターが半透明になる演出が含まれており、これがLiquid Glass導入を示唆するものと解釈された。 Googleの回答：「Not happening! Y’all are wild.」 Samat氏はXに「Not happening! Y’all are wild.（ないない！みんな大げさすぎ）」と投稿し、Pixel 11へのLiquid Glass導入を一刀両断した。Tom’s GuideのTom Pritchard氏の分析では、ティーザーの半透明演出は「おそらくGeminiやAIと関係したもの」と推察。Geminiロゴにはティーザーのカラーパレットとよく似た虹色の配色が使われているためだ。 海外レビューのポイント Pritchard氏はGoogleがLiquid Glassを採用しない判断を評価している。根拠として挙げているのは、AppleがLiquid Glass実装後にカスタマイズオプションを追加するまで数ヶ月かかり、ユーザーから批判を受けた経緯だ。「こうした前例がある中で、急いでコピーするのは理にかなっていない」という見方だ。 またTom’s Guideは、Google I/OではデザインよりもAIがメインテーマになるとの見通しを示している。AIへの重点シフトを強調するイベント構成になりそうだとしており、Geminiのシステムレベルでの深化が鍵になると読んでいる。 日本市場での注目点 Pixel 11の日本発売時期・価格は未発表だが、例年の傾向から秋頃の発表が予想される。Pixel 8a以降のコスパの高さで日本でもユーザー層が広がっているPixelシリーズが、デザインではなくAI統合で次の勝負に出るという方向性は、日本のAndroidユーザーにとっても注目の動きだ。 Android Show: I/O Editionは日本時間5月13日（火）午前2時（ET 1:00 PM）、I/Oキーノートも同日同時刻に配信予定。日本のエンジニアにとっても見逃せないタイミングだ。 筆者の見解 今回のGoogleの対応は、率直に言って正しい判断だと思う。Liquid Glassに対するAppleユーザーの反応は決して一枚岩ではなく、「見た目は面白いが使い勝手が下がった」という声も多い。そこへ急いで追随するのは独自性を損なうだけで、リスクに見合わない。 気になるのはティーザーの演出の意味だ。Androidマスコットが半透明になり、Geminiカラーが輝く——これはデザインの変化ではなく「AndroidはGeminiファーストになる」という意思表示に見える。であれば、Google I/Oで問われるのは「GeminiがAndroidにどこまで深く組み込まれるか」だ。単なるアシスタント機能の追加にとどまるのか、OSレベルで推論が走る構造になるのか——その答え合わせが5月13日に行われる。 VivoやOppoが素早くLiquid Glassを採用したのは、ある種の業界の習慣的な追随行動だ。Googleがその流れに乗らなかったことは、プラットフォームとしての矜持を示している。ただし、独自路線を宣言したからには「Gemini統合でAppleに差をつける」という結果を出さなければならない。I/O後の評価が楽しみだ。 出典: この記事は ‘Not happening! Y’all are wild’: Google shoots down rumors Android will copy the iPhone’s Liquid Glass design の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AIといえばクラウドの巨大データセンター——という常識が変わりつつある。Tom’s GuideのAmanda Caswell記者が5月7日に報じたところによると、Nvidiaはスマートエネルギー管理スタートアップのSpanと提携し、住宅や小規模事業所の外壁に取り付けるミニAIデータセンターユニット「XFRAノード」のテストをすでに進めているという。住宅街そのものを分散型スーパーコンピューターに変えようとする、野心的な構想だ。 なぜこの製品・構想が注目なのか 現在のAIは巨大クラウドインフラに依存しているが、このアーキテクチャには3つの根本的な課題がある。コスト（大規模モデルの推論費用と電力グリッドへの圧迫）、プライバシー（会話やクエリがリモートサーバーに送られることへの懸念）、そしてレイテンシ（音声アシスタント・スマートグラス・ホームロボットなどリアルタイム用途での致命的な遅延）だ。 XFRAノードは、HVACシステムや電力パネルと並んで設置し、家庭の余剰電力容量を使ってAIワークロードを処理するという設計思想で、これら3つの課題に同時にアプローチしようとしている。さらに、住宅オーナーが自分の電力・コンピューティングリソースを分散処理網に提供することで収益を受け取れる仕組みも検討されているという。分散型マイニングをAI推論に応用した形だ。 Nvidiaの「パーソナルAIスーパーコンピューター」戦略との関係 XFRAノードの背景にあるのは、Nvidiaが推進する「パーソナルAIスーパーコンピューター」構想だ。同社がすでに発表しているDGX Sparkは、デスクサイズで大規模AIモデルをローカル実行できるシステムで、開発者・研究者・エッジAIワークフロー向けに設計されている。Nvidiaはこれを「デスクの上のAIスーパーコンピューター」と表現しており、ローカルAI推論・ロボティクス・エッジAI・自律エージェント・コンピュータービジョンなど幅広い用途を想定している。XFRAノードはこのコンセプトをさらに住宅インフラへと組み込む次のステップとも言える。 海外メディアの評価ポイント Tom’s GuideのCaswell記者は、この動きを「SFのように聞こえるが、業界全体で起きている現実のシフトに根ざしている」と評価。同記事が引用するInc.の報道によれば、実証実験は進行中とのことだ。 評価できる点: 余剰電力の収益化という発想は、電気自動車の逆送電（V2G）と同様のコンセプトで消費者にも理解しやすい ローカルAI処理によるプライバシー向上は、欧米・日本を問わず高まる消費者ニーズと合致している クラウドコスト削減・レイテンシ低減という技術的メリットは明確 気になる点: XFRAノードの実際の消費電力・騒音レベル・設置コストは現時点では未公開 住宅設置リソースが「共有」される場合のデータ分離・セキュリティ担保の方法が問われる 商業展開の時期・価格モデルは未発表 日本市場での注目点 XFRAノードの日本展開は現時点で未発表。一方、関連製品のNvidia DGX Sparkは日本でも開発者・AIエンジニアから注目されている。 日本固有の事情として注意したいのが住宅インフラの違いだ。マンション・集合住宅の比率が高い日本では、外壁にユニットを設置する北米型のモデルがそのまま適用できるケースは限られる。一戸建て住宅が中心の北米市場で設計されたコンセプトを、日本市場向けにどう再解釈するかが課題になるだろう。 また、日本では太陽光発電の余剰電力売電制度（FIT）がすでに普及しており、FIT期間終了後の「余剰リソース活用」という文脈でXFRA型の仕組みが語られる可能性はある。価格情報や日本発売時期については続報を待ちたい。 筆者の見解 今回の動きで重要なのは、「AIインフラの分散化」という方向性そのものだ。クラウドに集約されたコンピューティングパワーをエッジ・住宅インフラへと分散させることで、レイテンシ・プライバシー・コストの三点で明確なメリットが生まれる——この流れは止まらないと見ている。 ただし「自分の家のハードウェアで他人のAIワークロードが動く」という状況には、データ分離とセキュリティ設計の透明性が不可欠だ。技術的には実現可能でも、消費者が安心して参加できる仕組みを設計できるかどうかが普及の鍵を握る。 AIエージェントが自律的にループし続けるワークロードが一般化していく中で、そのコンピューティングリソースが住宅に分散されていく未来は、あながち遠い話ではない。現時点ではまだ実証実験段階だが、Nvidiaがこの方向に本気で投資しているとすれば、業界全体のインフラ設計思想に影響を与える動きになりうる。続報に注目したい。 関連製品リンク NVIDIA DGX Spark GB10 Grace Blackwell Superchip, 128GB LPDDR5x, ARM Processor, 4TB NVME M.2 SSD Storage 上記はAmazon.co.jpへのリンクです。記事執筆時点の情報であり、価格・在庫は変動する場合があります。 出典: この記事は Nvidia is teaming up with Span to install mini AI data centers right on the side of your house, turning residential neighborhoods into a distributed supercomputing network that actually pays homeowners for their unused electricity の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Nintendo Switch 2の価格が「安すぎる」として、投資家から値上げを求める声が上がっていることをTom’s GuideのTom Pritchard記者がBloombergのレポートをもとに伝えた。歴代最速の販売ペースを記録しているコンソールが、なぜ株価下落と価格論争の中心になっているのかを整理したい。 史上最速で売れているのに株価が低迷する理由 Tom’s Guideの報道によると、Nintendo Switch 2は歴代ゲームコンソールの中で最速の販売ペースを記録しており、ソフトウェアラインナップの充実も相まって、業績面では競合ソニーを上回る状況にある。にもかかわらず、任天堂の株価はソニーを下回っているという。 Bloombergのレポートが示す投資家の懸念は「450ドルという価格設定がマージンを圧迫している」というものだ。サプライチェーンの混乱と製造コストの継続的な上昇が背景にあり、また、ソニーがPS5を値上げする決断をしたことも比較材料として意識されている。 海外レポートが伝える価格論争の構図 Tom’s Guideのレポートでは、アナリストの見解が真っ二つに分かれていることが紹介されている。 値上げを求める側の論点: 現在の価格は製造コストの上昇を考慮すると採算が厳しい水準にある ソニーが前例を作った以上、市場に値上げの許容余地はある 価格を据え置いたままでは株価の回復が難しい 値上げに反対する側の論点: 世界的な生活費高騰（コスト・オブ・リビング・クライシス）の中、値上げは消費者の購買意欲を直撃する Switch 2のゲームソフトはすでに高額で、セールも少ない ゲームコンソールは歴史的に本体を赤字で販売し、ソフトで収益を補填するビジネスモデルをとってきた Tom Pritchard記者自身は「生活費の高騰を考えれば価格は低く抑えるべきだ」と明確な立場を取っている。 ゲーム機ビジネスモデルの背景 Tom’s Guideが指摘するように、コンソールビジネスの定石は「ハードを安く売り、ソフトで稼ぐ」だ。コンソールゲームがPCゲームよりも高額だった歴史的な理由もここにある。初代Switchはこの慣例を破って本体でも利益を出した例外的なケースだったが、投資家はSwitch 2にも同様のアプローチを求めているという。 任天堂は2026年5月9日（金）の決算発表でこの点に触れる可能性があり、業界関係者の注目が集まっている。 日本市場での注目点 国内ではNintendo Switch 2は49,980円（税込）で発売されている。米国での値上げが実施された場合、国内価格への波及も現実的なシナリオとして浮上する。PS5の国内値上げという先例がある以上、「コンソールの値上げ」は過去の話ではない。 Switch 2のゲームラインナップは今後さらに拡充される予定であり、本体価格が上がればソフトへの支出も含めた総コストは相当な水準になりうる。ハードとソフト合わせてどこまで出費できるか、日本の消費者にとっても他人事ではない議論だ。 筆者の見解 「史上最速で売れているのに株価が下がる」という構図は一見奇妙に思えるが、ゲームビジネスの構造を考えれば理解できる。問題は、投資家が求める「マージンの最大化」と、消費者が求める「買いやすい価格」が真逆の方向を向いている点だ。 生活費が全体的に上昇している今、エンタメへの支出は最初に削られる傾向がある。Switch 2のゲームはすでに高額でセールも少ないという状況でさらに本体まで値上げすれば、「遊ぶこと自体のコスト」が積み上がりすぎて需要が収縮するリスクがある。「売れれば売れるほどキャッシュが積み上がる」という好循環を守るためにこそ、価格を抑えることが長期戦略として合理的に見える。 任天堂には独自IPという圧倒的な強みがある。その強みを活かすには、消費者との信頼関係を維持することが一時的な利益率改善よりも大きなリターンをもたらすはずだ。5月9日の決算発表で任天堂がどんな姿勢を示すか、注目したい。 関連製品リンク Nintendo Switch 2(日本語・国内専用) PlayStation 5(CFI-2000A01) Nintendo Switch(有機ELモデル) Joy-Con(L)/(R) ホワイト 上記はAmazon.co.jpへのリンクです。記事執筆時点の情報であり、価格・在庫は変動する場合があります。 出典: この記事は Nintendo Switch 2 price hike fears grow after reports investors don’t like how cheap the console is の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

中国のAI新興企業DeepSeekが、最新フラッグシップモデル「V4シリーズ」（V4 Flash・V4 Pro）を発表した。昨年初頭に世界を驚かせたV3リリースからおよそ1年。新モデルはコーディングベンチマークでトップクラスの成績を記録し、推論能力とエージェントタスクで大幅な進化を遂げた。シリコンバレーの大手各社に再び「追いかけなければならない存在」として認識させるリリースとなっている。 V4 Flash と V4 Pro：2モデル体制の戦略的意図 DeepSeekは今回、用途に応じた2モデル体制を採用した。 V4 Flashは高速・低コストを優先した実用モデル。APIコストを抑えながら十分な性能を確保しており、大量処理やリアルタイム応答が求められる場面を想定している。 V4 Proは性能優先のフラッグシップ。コーディングベンチマークでトップ水準の結果を示しており、複雑な推論タスクやエージェント型ワークフローでの真価を発揮するように設計されている。 この構成は最近の各社共通のトレンドでもある。「最高性能を使いたいが、全タスクに最大コストは払えない」という現場の実情に正直に応えた設計だ。 コーディング・推論・エージェント——3点で見せた進化 今回のV4で特に注目すべきポイントは3点ある。 1. コーディング性能の向上 HumanEvalやSWE-bench系のベンチマークでトップクラスの結果を記録。コード補完・バグ修正・テスト生成など、実務レベルのコーディングタスクで信頼できる性能に到達しつつある。 2. 推論能力の大幅進化 数学・論理問題など深い思考が必要なタスクで、V3から著しく改善。複数ステップにわたる問題を自力で分解・解決できる「推論モデル」に近い動作が確認されている。 3. エージェントタスクへの対応強化 ツール呼び出し（Function Calling）、複数ステップにわたる自律的タスク実行の精度が向上。AIエージェントとして組み込む用途での利用可能性が大きく広がった。 なぜこれが重要か：AI競争の「前提」が崩れ続けている DeepSeekが無視できない理由は、性能だけではない。V3リリース時と同様、モデルの訓練コストを大幅に抑えながら最前線クラスの性能を示している点が本質的な意味を持つ。 「最高性能のモデルを出すには天文学的なコストが必要」というシリコンバレーの前提を、DeepSeekは繰り返し覆してきた。V4がその傾向を継続しているなら、AIモデルの価格競争はさらに加速する。 日本企業にとって、これは朗報でもある。価格競争が激化するほど、優れた性能のモデルを低コストで利用できる可能性が高まる。APIアクセス・オープンウェイト版の両方で選択肢が広がることで、自社システムへの組み込みハードルも下がっていく。 実務での活用ポイント エンジニア向け V4 Proのコーディング性能はCIパイプラインへの組み込みや、コードレビュー補助ツールとして試す価値がある。特にオープンウェイト版が公開された場合、ローカル実行による情報漏洩リスク低減の観点からも魅力的な選択肢になる。 IT管理者・アーキテクト向け エージェントワークフローの設計を検討しているなら、V4 Flashのコスト効率を活かした「処理量担当」と、V4 Proを使う「精密作業担当」の役割分担を設計段階から考慮したい。単一モデルに依存する設計よりも、タスクに応じたモデル選択が今後の標準になっていく。 企業全体の観点 DeepSeekのモデルを業務で使う際は、データ取り扱いポリシーと利用規約を必ず確認すること。中国企業のサービスを業務利用する場合のリスク評価（データの所在・法域・ガバナンス）は、技術評価とは別に行う必要がある。 筆者の見解 DeepSeekのV4リリースを見て感じることがある。「強者に挑む者が継続的に存在する」ことが、この業界全体の底上げに効いているということだ。 AIモデルの性能競争はもはや、「巨額の訓練コストをかけた者が勝つ」という単純な構図ではなくなっている。DeepSeekはその前提を繰り返し崩してきた。これはシンプルに評価に値する。 一方で、日本の現場への影響について現実的に考えると、問題はモデルの善し悪しよりも「使い倒せているかどうか」だ。どのモデルを選ぶかの議論に時間を使っている企業は、すでに出遅れている。本当に問われるのは、選んだモデルでエージェントループを何本設計・実運用できているかだ。 モデルが毎月のように進化する時代に、特定モデルへの依存設計は将来リスクになる。抽象化層を設けてモデルを切り替え可能にする設計をしておくことが、今の時代の「道のド真ん中」だと思う。DeepSeek V4が選択肢に加わったことで、その設計思想の重要性はさらに高まった。 情報を追いかけるよりも、実際に手を動かして自分のワークフローに組み込む。V4の登場を機に、エージェント活用の一歩を踏み出すのが今もっとも正しい行動だ。 出典: この記事は DeepSeek Unveils Newest Flagship AI Model a Year after Upending Silicon Valley の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

AI に多額を投じながら「本当に効果が出ている」と確信できている企業は、まだごく一部にとどまる。IBM が年次カンファレンス「Think 2026」で披露したのは、まさにこのギャップを埋めるための青写真だ。単なる製品アップデートではなく、「AIをどう企業全体に根付かせるか」という運用モデルそのものの再設計を提示した点で、今回の発表は注目に値する。 4つの柱で構成する「Agentric Enterprise」 IBM が掲げる新しい運用モデルは、Agents・Data・Automation・Hybrid の4層で成り立つ。それぞれは独立した優先課題でもあるが、IBM の主張は「4つが連動して初めて、部分最適ではなく業務全体の変革が起きる」というものだ。 個別の発表を整理する。 watsonx Orchestrate（次世代）——マルチエージェント統制基盤 最大の目玉が、watsonx Orchestrate の次世代版（現在プライベートプレビュー）だ。エージェント制御プレーン（Agentic Control Plane） として再定義され、異なるチームが異なるプラットフォームで構築したエージェントを一元的にガバナンスし、ほぼリアルタイムで監査可能にする。 「数個のエージェントを動かす」段階から「数千のエージェントが動き続ける」段階へ——このスケールの壁を越えるには、エージェントを作ること以上にエージェントを統治することが課題になる。Orchestrate が目指すのはその統治基盤だ。 あわせて発表された IBM Bob は、エンタープライズ向けのアジェンティック開発パートナー。セキュリティとコスト制御を組み込みながらエージェントを構築できるとしており、開発者向けの入り口として位置づけられる。 IBM Confluent——リアルタイムデータ基盤 AI エージェントが「今この瞬間のデータ」で判断を下せなければ、使い物にならない。IBM が Confluent を買収してリアルタイムデータストリーミング（Kafka / Flink ベース）を取り込んだのはその文脈だ。watsonx.data との組み合わせでセマンティクスを付与しながらガバナンスを適用するコンテキストレイヤーを提供する。サイロ化されたデータを意味のある文脈に変換し、AIの判断を説明可能にする狙いがある。 IBM Concert——インテリジェント運用プラットフォーム インフラ・セキュリティ・運用をまたぐハイブリッドクラウド管理を AI で自動化するプラットフォーム。ITオペレーション全体を横断的に可視化・制御できる点が特徴だ。 IBM Sovereign Core——データ主権と自律運用 規制対応や地政学リスクを意識した主権的AI運用を実現するレイヤー。特に金融・公共分野など、データの出国規制や監査要件が厳しいセクターに響く提案だ。日本でも金融庁・総務省の動向を踏まえると、この視点は無視できない。 日本のIT現場への影響 「AI 格差」という言葉は、日本の現場にも直接刺さる。多くの企業がツールとしての AI を導入しているが、業務プロセスに深く組み込んで成果を出している企業はまだ少ない。 IT管理者・SIer担当者へのヒント： マルチエージェント統制の考え方（誰が作ったエージェントも一元管理できる仕組み）は、既存のガバナンスポリシーと統合する設計として参考になる リアルタイムデータ基盤の重要性は IBM に限らない。「エージェントに古いデータを与えていないか？」を自社環境で点検するきっかけにしてほしい Sovereign Core の発想は、Microsoft の EU Data Boundary や日本リージョン活用と同じ文脈。主権的データ管理の議論は日本でも今年以降加速するはずだ エンジニアへのヒント： エージェント開発の「作る」フェーズより「統治する」フェーズへの投資を意識し始める時期に来ている watsonx Orchestrate のアーキテクチャはオープン連携を前提にしているため、既存の Microsoft / AWS / GCP 環境と排他的な関係ではない。マルチクラウド戦略の文脈で評価できる 筆者の見解 IBM のメッセージで最も共感したのは、「多くの企業が AI に投資したが、成果を得ているのはごくわずか」という出発点の正直さだ。AIを導入することと、AIで業務を変えることの間には、依然として大きな溝がある。この溝を「エージェントの統治と自律的なループ設計」で埋めようとする方向性は、正しい。 ...

Microsoftが発表した2026年版グローバルAI普及レポートによれば、2026年第1四半期時点で世界の就労年齢人口（15〜64歳）のうち17.8%が生成AIを利用しており、前四半期比1.5ポイントの上昇を記録した。数字だけ見ると地味に映るかもしれないが、このレポートが示しているのは「誰が乗り遅れているか」という構造的な問いだ。 日本・アジアが急加速した背景 今四半期の注目は、アジア地域での急速な普及だ。韓国・タイ・日本が最も大きく伸びた国として名指しされている。その背景にあるのは「アジア言語対応の大幅改善」だとレポートは指摘する。 日本語でのAI利用障壁は確かに高かった。精度・自然さ・文脈理解——いずれも英語との開きが目立っていた時期が長かった。それが急速に解消されつつある。英語圏中心に設計されてきたモデルが多言語化を本気で進めた結果が、数字として現れてきた形だ。 日本のIT現場でも、「試しに使ってみたら意外と使える」という感想が増えているのはこの流れと一致する。生成AIを「英語のツール」として距離を置いてきたユーザー層が、いよいよ動き始めたフェーズに入ったとも読める。 AIデバイドの拡大——格差の構造 一方で、レポートは冷徹な格差も記録している。グローバルノース（先進国群）の利用率が27.5%に達した一方、グローバルサウス（新興国・途上国群）は15.4%にとどまる。この差は縮まるどころか、さらに広がっている。 UAE（70.1%）が首位を独走し、アメリカは21位（31.3%）。大国がランキング上位に来ない構図は、国の経済規模や技術力とAI普及率が単純には連動しないことを示している。政策・インフラ・リテラシー教育の組み合わせが問われる。 日本は数値が明示されていないものの、「アジアで最も動いた国の一つ」という位置づけは、国内の企業・行政が本格的に動き始める契機になりうる。 コーディングAIが開発者を「不要」にしなかった もう一つ、このレポートで注目したいデータがある。GitHub CopilotやClaude Code、OpenAI Codexといったコーディング支援ツールの進化がコード生成量を押し上げ、Gitプッシュ数が前年同期比78%増を記録したというデータだ。 「AIが開発者の仕事を奪う」という予測が多い中、現実は逆の方向に動いている。2025年のアメリカのソフトウェア開発者雇用数は約220万人と過去最高を記録し、前年比8.5%増。2026年Q1のデータでも前年同月比4%増が続いている。 なぜか。AIによって開発コストが下がると、「これまで費用対効果で諦めていたソフトウェア開発」への需要が新たに生まれるからだ。AIが効率を上げることで、むしろ市場全体が拡大するというダイナミクスが働いている。 実務への影響 エンジニアへ: AIコーディングツールへの投資は「自分の仕事を守るため」ではなく「より高付加価値な仕事に移るため」として正当化できる。コード生成をAIに任せることで、設計・レビュー・アーキテクチャ判断といった上位レイヤーに集中できる環境が整いつつある。 IT管理者・経営層へ: 「AIは使えない」「様子を見る」というポジションは、今やリスクとして定量化できる。グローバルノースの平均が27.5%という状況で、自社の利用率が一桁台であれば、それは組織の競争力に直結する問題だ。禁止や制限より、「公式に安全に使える仕組みを整える」方向に舵を切る時期だ。 日本語対応の改善を活かす: 今こそ日本語AIの実力を改めて評価する好機だ。1〜2年前の体験で「AIは日本語が苦手」と判断したなら、ぜひ再評価してほしい。体感は相当変わっているはずだ。 筆者の見解 このレポートで最も印象的だったのは、開発者雇用の増加というデータだ。テクノロジーの歴史を振り返ると、新技術は「特定の作業」を不要にするが、「職種そのもの」を消滅させることはむしろ少ない——少なくとも短中期では。印刷機が写本師を減らしたが、本を書く人を減らしたわけではない、という構図に近い。 とはいえ、この楽観論には注意が必要だ。「AIで需要が増えた開発者」とは、AIを使いこなせる開発者のことだ。使えない開発者への需要が増えているわけではない。日本のIT業界でこれが深刻な問題になるのは、「使いこなせる人材を育てる」仕組みが変化の速度に追いついていないからだと思う。旧来型の人材育成モデルのままでは、この転換期を乗り越えるのは根本的に難しい。 グローバルノースとサウスのデバイドが広がっているという事実も、日本にとって他人事ではない。国内においても、AI活用が進む企業とそうでない企業の間のデバイドは今まさに広がっている。「うちの会社でAIを使う必要があるか検討中」という状態は、データ上の「グローバルサウス」に位置することと変わらない。 日本がアジアで急加速したというニュースは素直に嬉しい。この流れが一時的なトレンドに終わらず、実際の業務変革・生産性向上につながるかどうかが、次の1〜2年の見どころだ。 出典: この記事は The state of global AI diffusion in 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Outlook Classicを開こうとしたら突然起動しなくなった——そんな問い合わせが増えている場合、原因はMicrosoft 365の現在進行中の障害かもしれない。Teams Meeting Add-in（Teams会議アドイン）を有効にした環境で、特定ビルドのOutlook Classicが起動不能になる問題が確認されている。Exchange Onlineに起因するサービス低下であり、Microsoftは修正展開を試みたものの、予期しない遅延が生じていると発表した。 何が起きているのか 障害の概要は以下の通りだ。 影響範囲: Teams Meeting Add-inが有効な状態かつ古いOutlookビルドを使用しているユーザー 現象: Microsoft Outlook Classic（旧来のデスクトップクライアント）が起動できない 根本原因: 古いOutlookビルドとTeams Meeting Add-inの組み合わせが競合を引き起こしている 障害識別子: EX1254044（Microsoftトラッキング番号） 注目すべきは「Exchange Onlineに起因する」という分類だ。一見するとデスクトップアプリの問題に見えるが、クラウド側のサービスと連携するAdd-inの仕組みが絡んでいるため、ローカルだけで完結しない。Microsoft 365の統合アーキテクチャならではの複雑さが出た格好だ。 今すぐ使える回避策3選 Microsoftが案内している回避策は複数ある。組織の環境に合わせて選択してほしい。 1. Teams Meeting Add-inを一時的に無効化する 最も即効性が高い。アドインを無効にすればOutlook Classicは通常通り起動する。Teamsからのカレンダー招待作成機能が一時的に使えなくなるが、会議招待はTeamsアプリやWebから送ることで代替できる。 2. Outlookをオンライン修復する Windowsの「アプリと機能」からOfficeを選択し、「変更」→「オンライン修復」を実行する。インターネット接続が必要だが、ファイルの破損や不整合を一括修正できる。所要時間は環境によって異なるが20〜40分程度を見込んでおこう。 3. Outlookを最新ビルドに更新する 根本原因が「古いビルド」にあるため、最新版へのアップデートで解消する可能性が高い。Outlook上部メニューの「ファイル」→「Officeアカウント」→「更新オプション」→「今すぐ更新」から実行できる。Monthly Enterprise Channel（MEC）環境では更新タイミングに注意が必要だ。 実務への影響——IT管理者が確認すべきこと エンドユーザーからの問い合わせが来る前に、以下を確認しておきたい。 テナント全体のOutlookビルド状況を把握する Microsoft 365管理センターのHealth → Service healthで障害状況を確認できる。EX1254044を検索すれば詳細と影響スコープが確認できる。 更新チャネルを見直す機会にする MECやSemi-Annual Enterprise Channelを使っている組織では、今回のように修正が遅れるリスクがある。セキュリティパッチの観点からも、Current Channelへの段階的移行を検討する価値がある。 回避策の一括展開を検討する Intune（Microsoft Endpoint Manager）を使っている環境であれば、アドインの有効・無効をポリシーで一括制御できる。個別対応より効率的だ。 新しいOutlook（One Outlook）への移行タイミングを見極める MicrosoftはClassicから「新しいOutlook」への移行を推進している。今回のようにClassic固有の障害が頻発するようであれば、移行の優先度を上げるサインかもしれない。ただし新しいOutlookにもアドイン互換性の制約があるため、現場での検証は必須だ。 筆者の見解 Teams Meeting Add-inとOutlookの組み合わせ問題は、実は今回が初めてではない。この2つのコンポーネントは長年にわたってトラブルが報告されてきた経緯がある。根本的な原因は、Teamsが独自のアドインとして後からOutlookに統合された設計の複雑さにある。 MicrosoftにはOutlookとTeamsを深く統合するための技術力が十分にある。だからこそ「また同じところで」と感じてしまうのが正直なところだ。新しいOutlookではTeams機能がよりネイティブに統合される方向に進んでいるとは聞く。その完成形に期待している。 一方で、エンドユーザーにとっては「突然Outlookが開かなくなった」という体験は、理由がどこにあれ信頼を損ねる出来事だ。修正展開の遅延が重なっているのも気になる点ではある。IT管理者としては、今回の件をきっかけに更新チャネルの見直しや新しいOutlookへの移行計画を具体化するのが建設的な対応だろう。 障害は起きるものだ。大切なのは、組織がそこから素早く立て直せる仕組みを日頃から持っているかどうかだ。 出典: この記事は Microsoft 365 Alert – Exchange Online Service Degradation – Outlook Classic with Teams Meeting Add-in の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

スマートフォン業界に衝撃を与えうるニュースが飛び込んできた。ガジェット系メディア「SammyFans」が報じたところによると、AppleがiPhone向けプロセッサの製造パートナーとして、長年のライバルであるサムスンを採用する可能性が浮上している。実現すれば、スマートフォン市場で熾烈な競争を繰り広げる両社の異例の協業となる。 なぜこの話が注目されるのか AppleのAシリーズ・Mシリーズチップは、現在ほぼ100%をTSMC（台湾積体電路製造）が製造している。しかし、台湾有事リスクや地政学的な不確実性の高まりを受け、Appleが製造先の多様化（マルチソーシング）戦略を加速しているという観測は以前から存在していた。 サムスンは自社のスマートフォン事業（Galaxy）とともに、サムスンファウンドリという半導体受託製造部門を持つ。かつてAppleのAシリーズチップを製造した実績もあり、完全に無縁な話ではない。TSMCの独占体制にヒビが入るとすれば、業界全体の勢力図が塗り変わる可能性がある。 サムスンファウンドリの現在地 サムスンファウンドリは近年、歩留まり（製造の良品率）の低さや顧客獲得の苦戦が指摘されてきた。一方、TSMCは2nm世代の量産準備を着実に進め、先端プロセスでの優位を保っている。Appleが要求する超高品質・超大量生産に応えるためには、サムスン側にも相応の技術的飛躍が求められる。 SammyFansの報道では、Appleによる具体的な移行スケジュールや対象チップ世代については明言されていない。現時点では「可能性の検討段階」と捉えておくのが妥当だろう。 日本市場での注目点 日本ではiPhoneのシェアが依然として高く、製造コストや生産体制の変化はデバイス価格・供給安定性に直結する。TSMC熊本工場（JASM）の稼働により日本でも半導体サプライチェーンへの関心が高まっている中、サムスンとAppleの協業が実現すれば、日本のビジネス・政策環境にも無視できない影響が及ぶ。 日本での発売価格や販売計画への直接的な影響については、まだ情報が乏しい段階だ。ただし、製造多角化が進めばiPhoneの供給安定性が高まるという意味で、長期的には日本のユーザーにとってもポジティブな可能性がある。 筆者の見解 サプライチェーンの一点集中リスクは、ここ数年で多くの企業が身をもって学んだ教訓だ。Appleほどの規模と調達力を持つ企業であっても、単一の製造パートナーへの依存はリスクであり、マルチソーシングへの移行は「道のド真ん中」の戦略選択といえる。 問題はサムスンファウンドリがAppleの厳しい品質要求を満たせるかどうかだ。歩留まりの改善は一朝一夕には達成できない。今回の報道が実現に至るまでには、相当な技術的ハードルを乗り越える必要があるだろう。 一方で、もしこの協業が成立すれば、サムスンファウンドリの技術力を証明する絶好の機会にもなる。「ライバルのチップを作る」という逆説的な構図は、ビジネスの世界では珍しくない。半導体製造という高度に専門化された領域においては、競争と協力が表裏一体で共存するのが現実だ。 現時点では情報が限られており、確定的なことは言えない。続報を注視したい。 出典: この記事は Samsung Could Make Apple iPhone Processors の内容をもとに、筆者の見解を加えて独自に執筆したものです。

続きをみる note.com で続きを読む →