Tech News JP

Samsung Electronicsは2026年7月15日、公式ニュースルーム「Samsung Newsroom」で、次世代Galaxy Z Fold／Z Flipシリーズに搭載予定の新ディスプレイ技術「Flex Titanium」を発表した。折りたたみスマートフォンの弱点とされてきた「折り目の目立ちやすさ」と「薄さ・強度の両立」に対し、チタン素材を用いた構造改良でアプローチする内容だ。 なぜこの技術が注目か 折りたたみディスプレイは開閉を繰り返す構造上、パネルを支える内部フィルムに柔軟性と強度を同時に求められる難しい部材だ。サムスンは今回、この内部フィルムに「チタン合金フィルム」と、穴あき構造の「チタンプレート」という2つのチタン系コンポーネントを組み合わせた。 発表によれば、チタン合金フィルムはOLEDパネルの下に配置され、従来のポリマーフィルムと比較して機械的剛性が20倍に向上したという。精密圧延加工により厚さは人の髪の毛のおよそ3分の1まで薄くできており、剛性と薄型化を両立させた点がポイントだ。チタンは人工衛星のアンテナや火星探査車のホイールにも使われる素材で、強度面では実績があるものの、薄く柔軟な折りたたみ構造への応用は技術的難度が高いとされてきた。 サムスン公式発表のポイント Samsung Newsroomの発表文では、モバイルR&D部門のムン・ソンフンEVPが「サムスンの折りたたみ機における強みは、ユーザーニーズと技術を結びつけ、日常生活で実感できる価値を届けることにある」とコメントしている。同社は2007年のAMOLEDディスプレイ量産以降、7世代にわたって折りたたみ機を市場投入しており、今回の技術はその蓄積の延長線上にあるという位置づけだ。 ただし現時点では実機によるハンズオンレビューは行われておらず、詳細な仕様や耐久試験の結果は今後開催されるGalaxy Unpackedで明らかになる見通しだ。実際の折り目の見え方や操作感は、量産機での検証を待つ必要がある。 日本市場での注目点 日本では折りたたみスマホの中でもGalaxy Z Foldシリーズ・Z Flipシリーズが一定のシェアを持ち、現行のGalaxy Z Fold7・Z Flip7はAmazon.co.jpやキャリア経由で購入可能だ。次世代モデルも同様の価格帯（Foldシリーズはおおむね20万円台後半〜、Flipシリーズは15万円台〜）での投入が予想される。 折り目の目立ちにくさは、日本の消費者が店頭で実機を触った際に真っ先に確認するポイントの一つであり、購買意欲に直結しやすい。Xiaomiやファーウェイなど中国勢の折りたたみ機も薄型化・軽量化を競っており、Flex Titaniumがどこまで体感差を生むかは、サムスンが折りたたみ市場での主導権を維持できるかを占う材料になりそうだ。 筆者の見解 折りたたみディスプレイは「開けば大画面、閉じれば普段使いのサイズ」という価値提案自体は魅力的でありながら、折り目や耐久性への不安が普及の足かせになってきたカテゴリーだ。今回のアプローチが評価できるのは、素材そのものを変えるという地に足のついた改良である点だ。ソフトウェアや演出で誤魔化すのではなく、構造から見直す姿勢は、道具として長く使うガジェットに対する王道の作り方だと感じる。 一方で、発表はあくまでサムスン自身によるもので、独立した第三者による耐久性検証はまだ存在しない。折り目の目立たなさや剛性の数値は、実際に数百〜数万回の開閉を経てどう変化するかで初めて評価が定まる。Galaxy Unpackedでの実機公開と、その後の海外メディアによる長期レビューを待ってから購入判断をするのが堅実だろう。日本での実売価格が現行モデルからどこまで上がるかも、実用面では見逃せないポイントだ。 関連製品リンク Samsung Galaxy Z Fold7 512GB | Silver Shadow | Galaxy AI Compatible | SIM-Free Smartphone Body | FeliCa Compatible | 8.0 inches | Lightweight 215g | IP48 Waterproof and Dustproof | QXGA+ Battery ...

米Tom’s GuideのAmanda Caswell記者は、OpenAIの新モデル「GPT-5.6 Sol Pro」が、番号付きヒントを一切与えられない状態で空欄のクロスワードパズルを解き切ったというデモンストレーションを報じた。 このデモは、AI研究者のRiley Goodside氏がX（旧Twitter）で公開したもの。話題になったパズルは「最初の150匹のポケモン」を題材に、Anthropicの「Claude Fable 5 Max」が作成した空欄クロスワードで、GPT-5.6 Sol Proは交差するマスの文字とパズル全体の構造だけを手がかりに、どのポケモン名がどこに入るかをすべて自力で推論した。 なぜこの実験が注目されているのか 通常のクロスワードは「1つずつヒントを読み、該当欄を埋める」という逐次処理で解ける。しかし今回のパズルには番号付きヒントが一つも存在しない。AIはマス目の形状と交差する文字の制約だけを頼りに、150匹という膨大な候補の中から正しい組み合わせを見つけ出す必要があった。 これは技術的には「制約充足問題（constraint satisfaction problem）」と呼ばれる領域で、1箇所の誤配置が数十カ所の連鎖的な修正を引き起こしかねない。Caswell記者は、この種の問題は実際のAIエージェントがソフトウェアのデバッグ、ワークフローの計画、複数ツールの連携、大規模なコードベースの編集を行う際に直面する課題と本質的に同じだと指摘している。 ポケモンの名前という題材も、実は難易度を上げる巧妙な選択だ。綴りが特殊で似た文字パターンを持つ名前が多く、長さもまちまち。モデルは記憶から正確に名前を引き出しながら、同時にすべての交差点の整合性を検証し続けなければならない。「数独のマスをすべて異なる単語に置き換えたようなもの」とCaswell記者は表現している。 海外レビューのポイント Tom’s Guideの報道によれば、このデモが示しているのは、近年のフロンティアモデルと数年前のチャットボットとの決定的な違いだ。単純に素早く回答を返すのではなく、複数の可能性を探索し、必要に応じて後戻り（バックトラック）しながら、最終的な答えが内部で矛盾していないかを検証する——そうした推論プロセスに時間をかけられる点にある。OpenAIはGPT-5.6 Sol Proを「難易度が高く長時間に及ぶ推論タスクに最も適したモデル」と位置づけており、今回のデモはその方向性を象徴する事例だとしている。 一方でCaswell記者は冷静な留保も添えている。これはあくまで開発者によるデモンストレーションであり、正式なベンチマークではない。使用されたプロンプトの全文やパズルそのもの、そして再現性を確認する独立した反復テストが公開されていないため、この結果がどれだけ安定して再現できるかは不明だという。それでも同記者は、コーディングテストや数学の試験スコアが一般ユーザーには実感しにくいのに対し、クロスワードパズルはAIの能力を直感的に伝える題材として優れていると評価している。 日本市場での注目点 GPT-5.6 Sol Proは本稿執筆時点で日本向けの提供時期や価格は正式発表されていない。ChatGPTのハイエンドモデルはこれまで上位プラン（Plus・Pro）での先行提供が通例であり、今回も同様の展開が予想される。 日本のユーザーにとって実務的に重要なのは、この種の「長時間推論モデル」がコーディング支援やエージェント型タスクにどう波及するかだ。クロスワードのような制約充足問題は、実務では複数ファイルにまたがるリファクタリングや、依存関係の多いバッチ処理の設計と構造が近い。日本語圏でも、こうした複雑なタスクを一括で任せられるかどうかが、次のモデル選定の判断材料になっていくだろう。 筆者の見解 面白いのは、今回OpenAIのモデルが解いたパズル自体はAnthropicの「Claude Fable 5 Max」が作成したという点だ。異なるベンダーのモデルが「出題」と「解答」の両側を担う構図は、AI業界全体の推論能力がどこまで底上げされてきたかを示す象徴的なエピソードだと感じる。 筆者は普段からClaude Codeを中心にAIエージェントを使い倒しており、その立場から見ても、今回の話題が示す方向性には強く共感する。AIエージェントの価値は、人間が逐一確認・承認を求められる「副操縦士」的な使い方では引き出しきれない。目的を伝えれば、途中の試行錯誤や後戻りも含めて自律的にやり切る——今回のクロスワードのデモは、まさにその「自律的に判断し、検証し、必要ならやり直す」というループの縮図に見える。 Caswell記者が指摘する通り、これは単発のデモであり正式な性能保証ではない。ただ、単発の受け答えではなく複数ステップにわたる推論を粘り強く回し続けられるかどうかは、今後のAIエージェント選定において最も重視すべきポイントだと筆者は考えている。ベンダーを問わず、この「粘り強く自律的に解き切る力」がどこまで実務のコーディングやワークフロー自動化に転用できるかを、今後も注視していきたい。 出典: この記事は OpenAI’s newest model just solved a crossword with zero clues — and it’s a huge deal for the future of AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国土安全保障省（DHS）が受けたサイバー攻撃は、実は今回が「初検知」ではなかった。英Neowinの報道によれば、DHSは同じ攻撃の兆候を過去に2度も見逃し、3度目にしてようやく本格的な対応に乗り出していたことが明らかになった。国家機関や州組織を狙うサイバー攻撃が世界的に相次ぐ中、警戒すべき事例がまた一つ増えたことになる。 「2度見逃す」という異常事態 Neowinの報じたところでは、今回DHSが対応した攻撃は、世界各地の国家機関・州組織を狙う一連のサイバー攻撃の最新事例に位置づけられる。注目すべきは攻撃そのものの巧妙さ以上に、「同じ兆候を2度スルーしてから、3度目でようやく重大インシデントとして扱った」という組織側の対応プロセスにある。侵入経路や攻撃者像については現時点で限定的な情報しか公開されていないが、この「見逃しの繰り返し」自体が、多くの組織に共通するセキュリティ運用の構造的な弱点を浮き彫りにしている。 なぜ重大な兆候が「誤検知」扱いされてしまうのか 大規模組織のセキュリティ運用現場では、日々大量のアラートが発報される。SOC（Security Operation Center）のアナリストは、その大半を過去の経験則から「よくある誤検知」と判断して流している。これは合理的な行動だが、裏を返せば「本物の攻撃も、統計的にはノイズに埋もれる」ということでもある。加えてネットワーク層・ID層・アプリケーション層など監視対象がサイロ化されていると、単体では小さく見える兆候同士の相関が取れず、「点」のまま放置されがちだ。DHSのように大規模かつ多数のシステムを抱える組織では、この構造的リスクがより顕著に表れやすい。 実務への影響 ― 日本のIT管理者への教訓 日本の官公庁・大企業でも他人事ではない。特に以下の3点は今すぐ点検する価値がある。 アラートの「握りつぶし基準」を定期的に見直す — 過去に誤検知だった兆候パターンが、今後も誤検知であり続ける保証はない。攻撃者は検知ルールを学習して回避してくる。 常時アクセス権を持つアカウントを棚卸しする — Just-In-Time（JIT）でのアクセス権付与に切り替えるだけで、初動の異常検知が格段にしやすくなる。常時アクセス権は「攻撃者にとっても常時使い放題の権限」だと忘れてはならない。 人間以外のID（NHI: Non-Human Identities）を可視化する — サービスアカウントやAPIキーなど、人が介在しない経路からの侵入は見逃されやすい。ここを自動的に監視できていないと、今回のDHSのように「気づいたときには2周目」ということになりかねない。 筆者の見解 正直に言うと、セキュリティ運用の細かい話は得意分野ではない。それでも技術的な関心は強く持っている領域で、今回の件は象徴的だと感じる。潤沢な予算と専門人材を抱えているはずの国家機関ですら、同じ兆候を2度見逃す。この事実は「うちは大丈夫」と思っている日本の組織にこそ突き刺さるはずだ。 筆者はゼロトラスト推進派であり、VPNのような「境界に依存した安心感」はもう卒業すべきだと考えている。今回のようなケースを見るたびに思うのは、結局のところボトルネックは常に人間の判断だということだ。常時アクセス権を減らし、NHIまで含めて自動的に検知・遮断できる仕組みを作らない限り、「アラートを見逃す組織」はこれからも増え続けるだろう。DHSの今回の件を対岸の火事にせず、自組織のアラート運用を見直すきっかけにしてほしい。 出典: この記事は DHS dismissed hack attack twice before sitting up and taking notice の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Hachette Book Group、Cengage Learning、Elsevierの出版大手3社と作家スコット・トゥロー氏が、Google社の生成AI「Gemini」の学習データ利用を巡り、集団訴訟の提起を目指していると米Engadget（記者Anna Washenko氏、2026年7月14日付）が報じた。著作権で保護された作品を許可なく学習に使用したとして、Googleに対する損害賠償を求める内容だ。 訴状が指摘する2つの争点 訴状は、Googleが著作権法違反であると認識しながら数百万点の著作物を無断で複製し、著者や出版社への補償を一切行わなかったと主張している。さらに「Googleは学習元を隠すため、著作物からCMI（著作権管理情報）を意図的に剥ぎ取った」とも訴えている。 もう一つの争点は、Geminiの出力そのものだ。訴状は「適切なガードレールがなければ、Geminiは学習元の著作物の代替品となり得る出力を生み続ける」とし、Googleがそうした模倣的な出力を防ぐ有効な仕組みを実装してこなかったと批判している。 広がるAI業界への著作権訴訟の波 同様の原告グループは、すでにMeta社に対しても集団訴訟を起こしている。著作権侵害を理由にした訴訟がAI企業側の敗北に直結した例はまだ少なく、Meta関連の著者側の訴えは昨年不発に終わった。一方Anthropic社は2025年、Claudeの学習データを巡る訴訟で15億ドルの初期和解に達したが、担当判事が「完成にはほど遠い」として和解案を却下している。Apple社に対しても、別の作家2名が無断学習を理由に提訴するなど、出版・著作業界からの追及は業界全体に広がりつつある。 日本市場での注目点 米国では著作権侵害の立証や損害額の算定を巡って訴訟が長期化しやすく、今回のGoogle提訴も決着までには時間がかかると見られる。日本には「非享受目的」のAI学習を原則適法とする著作権法30条の4があり、米国とは法制度の前提が異なる。ただし、生成AIが学習元コンテンツの代替品になり得るという論点自体は日本の出版・コンテンツ業界にも共通する懸念であり、海外の判例や和解動向は今後の国内議論の参考材料になる。 筆者の見解 AI企業と著作権者の攻防は、今回に限らず今後も続くだろう。ただ、訴訟による決着だけを待つのは双方にとって得策ではないはずだ。禁止や差し止めで学習データの利用を止めても、AI企業はどこかから同じデータを調達し続けるだけで、根本的な解決にはならない。むしろ必要なのは、著作権者が安心してコンテンツを提供でき、AI企業も正規のルートでデータを調達できる「安全に使える仕組み」——ライセンス市場や補償の枠組みを業界標準として整備することだ。音楽業界が違法配信との戦いの末に定額配信という仕組みにたどり着いたように、AI学習データも同じ道を歩む可能性は十分にある。日本の企業がAI活用を本格化させる上でも、学習データの出所や権利処理が明確な製品を選ぶという視点は、今後ますます重要になっていくだろう。 出典: この記事は Three publishers challenge Google over AI copyright infringement の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年7月、Azure Blob StorageのSFTP（SSH File Transfer Protocol）アクセスにおいて、Microsoft Entra IDによる認証を一般提供（GA）として公開した。これまでBlob StorageのSFTP機能を使うには、ストレージアカウントごとにローカルSFTPユーザーを作成し、パスワードを個別管理する必要があった。今回のGAにより、Entra ID認証でMFA・条件付きアクセス・RBAC/ABACとの統合が可能になる。プレビュー期間中に指摘されていたABAC（属性ベースアクセス制御）の権限判定の不整合も解消され、コピーやリネームといったサブ操作への対応も加わった。 SFTPという「枯れたプロトコル」にEntra IDが統合される意味 Azure Blob StorageはネイティブでSFTPプロトコルをサポートしており、レガシーシステムやパートナー企業とのファイル連携で今も広く使われている。従来この機能を利用するには、ストレージアカウントごとにローカルSFTPユーザーを作成し、パスワードやSSH鍵を個別に管理しなければならなかった。ユーザー数が増えるほどローテーション作業や退職者アカウントの削除漏れが積み上がる、典型的な「野良アカウント」問題を抱えやすい仕組みだった。 今回のGAでは、このSFTP認証にMicrosoft Entra IDを利用できるようになった。SFTPクライアント（人間のユーザーでもサービスでも）がEntra IDで認証し、Azure RBAC（ロールベースアクセス制御）やABAC（属性ベースアクセス制御）によってコンテナ単位・パス単位でアクセス権を制御できる。MFAや条件付きアクセスポリシー（デバイス準拠、接続元IP制限、リスクベース制御など）もそのまま適用される。ローカルSFTPユーザー方式と共存できるため、既存環境から段階的に移行することも可能だ。 GA版での品質改善 プレビュー期間中はABACの権限判定に不整合があり、特定の条件下で意図しないアクセスが許可・拒否されるケースが報告されていた。GA版ではこの判定ロジックが修正され、コピーやリネームなどのサブ操作についても正しく権限チェックが行われるようになった。派手さはないが、本番採用の可否を左右する重要な品質向上だ。 実務への影響 日本の製造業・金融業では、パートナー企業とのファイル交換にいまだSFTPを使っているケースが多い。EDI連携やバッチ処理系のシステムでは、SFTPが唯一の外部インターフェースということも珍しくない。こうした環境では、ローカルSFTPユーザーの棚卸しとパスワードローテーションが、地味だが重いIT運用負荷になっている。 実務での活用ポイントは次の通りだ。 既存のローカルSFTPユーザーを洗い出し、Entra ID認証への移行計画を立てる（両方式は共存可能なので段階移行できる） 条件付きアクセスポリシーで接続元IPやデバイス準拠を要求し、ネットワーク層だけに頼らない認証層での制御を強化する RBAC/ABACでコンテナ・パス単位の最小権限アクセスを設計する サービス間連携であればマネージドIDやサービスプリンシパルを使い、そもそもパスワードという資格情報自体をなくす方向を検討する 筆者の見解 SFTPのような枯れたプロトコルは、クラウド移行後も「動いているから触らない」扱いになりがちで、結果としてID管理の穴になりやすい領域だ。今回の変更は華やかさこそないが、そこに正面からEntra IDを統合してきた点は評価したい。 ローカルSFTPユーザーのパスワード管理は、Non-Human Identities（NHI）管理が抜け落ちる典型的な現場だ。人間のアカウントはEntra IDで一元管理していても、サービス用・連携用のアカウントだけ別管理になっているケースは多く、結局そこがボトルネックになって自動化が進まない、という状況をよく見かける。今回のGAでSFTP接続もEntra IDの管制下に置けるようになったことは、ネットワーク層・認証層・認可層の3層防御という観点でも意味が大きい。 欲を言えば、常時有効な資格情報ではなく、Just-In-Timeでの一時的なアクセス権付与ともっと自然に組み合わせられる設計にしてほしいところだ。特権的なファイル転送経路ほど「常時アクセス可能」がリスクになる。とはいえ、地味な機能を一つずつID基盤に統合していくのはMicrosoftらしい堅実な仕事であり、AIをめぐる派手な競争の裏でこうした足元を固める動きこそ、Azureというプラットフォームへの信頼を支えている。目立たないニュースだが、実務で長く効いてくるのはこういうアップデートだ。 出典: この記事は Enterprise Identity Meets Secure File Transfer: Entra ID Public Preview on Azure Blob Storage SFTP の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Windows Subsystem for Linux（WSL）の内部アーキテクチャを刷新し、Linuxカーネルのリソース管理機構であるcgroupのバージョンをv1からv2に切り替えた。この変更によりWSLの安定性は向上する見込みだが、一部のワークロードでは後方互換性が失われることも明らかになっている。 cgroup v2移行の技術的な意味 WSL2は、Hyper-Vベースの軽量な仮想マシン上で実際のLinuxカーネルを動かす仕組みだ。複数のディストリビューションを同時に起動できるのは、カーネルのcgroup機能でプロセスグループごとにCPU・メモリ・I/Oを分離管理しているからにほかならない。 これまでWSLが使ってきたcgroup v1は、リソースの種類ごとに別々の階層（コントローラー）を持つ複雑な構造で、ディストリビューションの起動・終了処理で競合やハング、メモリの解放漏れが起きやすいという課題を抱えていた。cgroup v2は単一階層に統合されたシンプルな設計で、こうした不安定要因を構造的に減らせる。Microsoftが安定性向上を優先してこの移行に踏み切ったのは筋が通っている。 一方でcgroup v2は、v1前提で書かれた古いsystemdやコンテナランタイムと相性が悪い。具体的には、cgroup v2への対応が入る前のsystemdや、対応が不十分なDocker Engineを使っている環境では、コンテナやサービスの起動に失敗する可能性がある。 実務への影響 WSL2を開発環境やDocker Desktopのバックエンドとして使っているエンジニア、それを管理するIT部門にとっては見過ごせない変更だ。 更新前にディストリビューション内のsystemdバージョン（systemctl --version）とDocker Engineのバージョンを確認する Docker Desktopを使っている場合は最新版へのアップデートを済ませてからWSLの更新を反映する 複数の開発者PCを抱えるチームでは、一斉更新ではなく数台での動作確認を挟んでから展開する Windows Update全般に言えることだが、「当てたら壊れた」という報告が出てから数日様子を見るのも、立派なセキュリティ・安定性判断だ。特に開発環境が止まると業務影響が大きいWSLのような基盤コンポーネントほど、この判断が効いてくる。 筆者の見解 個人的には、この手の「地味だが本質的な」改善こそもっと評価されるべきだと思っている。WSLは日本のエンジニアの間でもLinux開発環境の定番になっており、cgroup v1由来の不安定さに悩まされてきた人は少なくないはずだ。 派手な新機能よりも足回りの安定性を優先する判断は、正面から評価したい。ただし移行に伴う互換性リスクの周知はもう一段丁寧であってほしい——Docker DesktopやsystemdのバージョンとWSLの対応関係を、公式ドキュメントでもっと明示してもらえると、現場での更新判断がずっと楽になる。Windowsの基盤技術としてWSLが正面から評価される機会が増えることを期待している。 出典: この記事は Microsoft makes Windows Subsystem for Linux more stable with architecture tweak の内容をもとに、筆者の見解を加えて独自に執筆したものです。

コーディングエージェント開発企業のCognitionは2026年7月8日、新しいコーディング特化AIモデル「SWE-1.7」を発表した。Moonshot AIの「Kimi K2.7 Code」をベースに独自の強化学習（RL）を重ねる「RL on top of RL」という手法で追加学習を行い、コーディング能力を測る「FrontierCode」ベンチマークでOpenAIのGPT-5.5にわずか0.7ポイント差まで迫る結果を叩き出した。しかも1タスクあたりのコストは約1.97ドルとGPT-5.5級のモデルとしてはかなり低い水準に抑えられており、高速推論に強みを持つCerebras経由で自律型コーディングエージェント「Devin」に統合される。 RL on top of RL――他社モデルの上に重ねる強化学習という戦略 Cognitionの技術的に興味深い点は、SWE-1.7が完全な自社開発モデルではなく、中国のMoonshot AIが開発した「Kimi K2.7 Code」をベースモデルとして採用していることだ。ゼロからモデルを事前学習するのではなく、既に高いコーディング性能を持つオープンウェイト系モデルに対して、Cognitionが持つDevin運用で蓄積した実タスクのフィードバックをもとに追加の強化学習を重ねる「RL on top of RL」というアプローチを取っている。 フロンティアラボが数千億〜数兆円規模の計算資源を投じて事前学習から手がけるのに対し、既存の強力なベースモデルに的を絞ったRLを重ねることで、開発コストを抑えながらフロンティア級の性能に近づけるという戦略だ。結果としてFrontierCodeベンチマークではGPT-5.5にわずか0.7ポイント差まで迫り、しかも1タスクあたり約1.97ドルという低コストを実現した。 Cerebras経由でDevinに統合、推論速度も武器に SWE-1.7は半導体企業CerebrasのウェハースケールAIチップ経由で提供され、Devinに統合される。Cerebras製チップは一般的なGPUクラスタに比べて推論速度（トークン生成速度）が非常に高いことで知られており、Devinのような「タスクを渡すと自律的にコードを書き、テストし、修正を繰り返す」エージェント型ワークフローとの相性がよい。エージェントが試行錯誤を繰り返すたびに推論待ち時間が発生する設計では、モデル性能だけでなく応答速度も体験を大きく左右するためだ。 実務への影響 なぜこれが重要か: この発表が示すのは、コーディングAIの競争軸が「モデル単体のベンチマークスコア」から「実運用コストとエージェントとしての速度・自律性」に移りつつあるという流れだ。GPT-5.5に肉薄する性能を1タスク2ドル程度で提供できるとなれば、企業が大量のコーディングタスクを自律エージェントに任せる際のコスト障壁が大きく下がる。日本のIT現場でも、コーディング支援を「人間が逐一確認する副操縦士型」から「目的を渡して任せる自律エージェント型」に移行する動きが今後さらに加速するだろう。 実務での活用ポイント: Devinのような自律型コーディングエージェントを検証する際は、ベンチマークスコアだけでなく「1タスクあたりのコスト」と「エージェントが自律的に完結できる範囲」を必ず確認したい。特にCI/CD連携やIssue対応の自動化を検討しているチームは、低コスト化によって「小さなバグ修正やテスト追加まで機械的にエージェントへ委任する」運用が現実的になってきている点に注目すべきだ。試験導入する場合は、まず影響範囲の小さいリポジトリやタスクから任せてみて、実際に成果を出す経験を積むのが近道になる。 筆者の見解 私は自律型AIエージェントの本質は「人間の確認・承認を待たずにタスクを完結できること」にあると考えている。その意味で、Devinのような自律エージェント製品を支えるモデルが着実に進化し、しかもコストを抑えながらフロンティア級に近づいてきているのは歓迎すべき流れだ。 個人的にはClaude Codeを軸にエージェント活用のノウハウを積み上げているが、Cognitionのように既存の強力なベースモデルにRLを重ねて実用コストを下げるアプローチは、ベンダーを問わず「エージェントを24時間ガンガン回す」時代に向けた合理的な選択だと感じる。ベンチマークの数字を追いかけること自体にはあまり意味がなく、大事なのは実際に自分の手元でエージェントを動かし、どこまで任せられるかを体感で掴んでいくことだ。SWE-1.7とDevinの組み合わせも、そうした「実践して確かめる」対象のひとつとして注視していきたい。 出典: この記事は Cognition SWE-1.7: RL on Top of RL Yields Near-Frontier Code at Low Cost の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Foundry（旧Azure AI Foundry）のモデルカタログに、Moonshot AI製のコーディング特化モデル「Kimi K2.7 Code」がパブリックプレビューとして追加された。中国のAI研究機関Moonshot AIが開発したKimiシリーズの最新版で、長時間にわたる複雑なコーディングタスクをこなすことに特化したモデルだ。 Kimi K2.7 Codeの技術的な特徴 前バージョンのK2.6と比較して、Kimi K2.7 Codeは「思考トークン」（モデルが回答を生成する前に内部で使う推論用トークン）の使用量を約30%削減しながら、複数ステップにまたがる長期のコーディングタスクの成功率を高めているという。 コンテキストウィンドウは256Kトークンに達し、これは大規模なコードベース全体や複数ファイルにまたがる仕様書を一度に読み込ませるのに十分な容量だ。またマルチステップのツール呼び出し（ファイル編集、テスト実行、ビルドコマンドの実行などを連続して行う「エージェント的」な動作）にも対応しており、コーディングエージェントの裏側モデルとして使うことを想定している。 Microsoft Foundryは、Azure OpenAIのモデル群に加えて、Meta Llama・Mistral・DeepSeek・xAI Grokなど自社製以外のモデルも一つのカタログで横断的に扱えるプラットフォームだ。今回のKimi K2.7 Code追加も、その「モデルの選択肢を増やす」路線の一環と言える。 実務への影響 日本のエンジニアやIT管理者にとって重要なのは、「新しいモデルが一つ増えた」という以上に、そのモデルをどこで、どう安全に使うかという点だ。 Foundry経由でKimi K2.7 Codeを使う最大のメリットは、Microsoft Entra IDによるアクセス制御や監査ログ、データ処理リージョンの指定といったガバナンス機能をそのまま適用できることにある。Moonshot AIは中国のAI企業であり、モデル単体を個人契約のAPIキーで直接呼び出すと、データの取り扱いやコンプライアンス上の説明責任があいまいになりがちだ。Foundryのカタログ経由であれば、企業のセキュリティポリシーの枠内でモデルを評価・利用できる。 長時間コーディングタスクでの思考トークン削減は、そのままAPIコストの削減に直結する。エージェント型のコーディング支援を業務で使っているチームは、既存のワークフローの中でKimi K2.7 Codeをベンチマークし、コスト対効果を検証する価値がある。256Kの大きなコンテキストウィンドウは、モノレポや大規模プロジェクトでの活用にも向いている。 筆者の見解 今回の件で興味深いのは、モデル単体の性能競争ではなく、Microsoft Foundryという「基盤」の戦略の方だ。マイクロソフトは最先端のAIモデルを自社だけで作り切る競争では必ずしも先頭を走っていない。しかし、Entra IDによるガバナンスの下で多種多様なモデルを安全に選べる場を用意する競争では、むしろ有利な立場にいる。 エンジニアが「このタスクにはこのモデルが速い・安い」と気づいたとき、会社のセキュリティポリシーの外側でこっそりAPIキーを契約して使ってしまう、いわゆるシャドーAIが一番のリスクだ。禁止で対処しようとすると必ず抜け道が生まれる。今回のようにFoundryのカタログへ正式に追加し、IT管理者が許可した範囲で使える状態を作ることこそが、現実的な解決策だと考える。 正直なところ、Windows・Azure・M365のアップデートを一つひとつ逐一追いかける意味は薄れてきている。大事なのは個別モデルのスペック表を追い回すことではなく、Foundryという土台を活かして「使えるAIを選べる自由」をどう業務に落とし込むかだ。マイクロソフトには、Entra IDを軸にした管制塔としての役割を今後も伸ばしてほしい。基盤を作る力は間違いなくあるのだから、そこを正面から伸ばしていくべきだと思う。 出典: この記事は Introducing Kimi K2.7 Code in Microsoft Foundry の内容をもとに、筆者の見解を加えて独自に執筆したものです。

過去最大の570件、その内訳とは Microsoftは2026年7月のPatch Tuesdayで、月例更新としては過去最大となる570件の脆弱性を修正した。近年のPatch Tuesdayは月100件台後半から300件台で推移することが多く、570件という数字は明らかに異例の規模だ。対象製品も広範囲に及び、Windows本体だけでなく、Active Directory Federation Services（AD FS）やSharePoint Serverといった、企業のID基盤・情報共有基盤の中核を担う製品も含まれている。 今回とりわけ注意すべきは、悪用が既に確認されているゼロデイ脆弱性が2件、詳細が一般に公開済みのゼロデイが1件（BitLockerのバイパスに関するもの）含まれている点だ。ゼロデイとは、修正プログラムが提供される前から悪用が可能、あるいは実際に悪用されている脆弱性を指す。攻撃者はパッチが行き渡る前の「窓」を狙って攻撃を仕掛けてくるため、通常の月例パッチ以上にスピード感のある対応が求められる。 AD FS・SharePoint Serverが名指しされる理由 AD FSは社内外の認証を橋渡しするフェデレーション基盤であり、SharePoint Serverは組織の文書・情報共有の中心にある。どちらも侵害されれば影響範囲が組織全体に及びやすく、かつ多くの企業でインターネットに公開された形で運用されている。管理者向けパッチの適用が後回しにされがちな「地味だが重要」な製品でもあり、今回のアドバイザリで名指しされたことは、攻撃者がこの種の基盤を明確に狙っていることの裏返しと見るべきだろう。 BitLockerバイパスについては、ディスク暗号化という「最後の砦」を回避する手法が公開されている状態を意味する。リモート攻撃の入り口にはなりにくいが、端末の紛失・盗難時の情報保護という観点では見過ごせない。 実務への影響 日本のIT管理者にとっての優先順位は明確だ。 悪用済みゼロデイ2件は最優先で緊急適用。 WSUSやIntuneのリング配信を待たず、対象製品が明確なら検証を最小限にして先行適用する「ブレークグラス」対応が妥当。 AD FS・SharePoint Serverは棚卸しを。 特にインターネット公開しているフェデレーションサービスやSharePoint Serverがあれば、パッチ適用状況とバージョンを即座に確認する。オンプレミス版はサポート切れ・更新遅延が起きやすいため、この機会に構成そのものの見直しも検討したい。 BitLockerバイパスは端末紛失リスクの高い組織で優先度を上げる。 TPM+PIN構成やIntuneのコンプライアンスポリシーで、パッチ以外の防御層も併せて点検する。 その他の一般的な修正は、いつも通り数日のステージング検証を経てから展開してよい。 570件すべてを同じ緊急度で扱う必要はない。 筆者の見解 570件という数字だけを見ると身構えてしまうが、これはMicrosoftの検出・修正体制がそれだけ広い範囲をカバーしている証でもある。数の多さそのものより、「どれが今すぐ必要な対応で、どれは通常のサイクルで良いか」を切り分ける判断力の方が重要だ。 実際、最近は「パッチをすぐ当てたら別の不具合で環境が壊れた」という報告も増えており、闇雲な即時適用が必ずしも正解とは限らない。今回のように悪用済みゼロデイが明確になっているケースは即時対応が筋だが、そうでない大多数の修正については、数日様子を見てから展開する判断も立派なセキュリティ判断だと考えている。Microsoftにはこの優先順位の切り分けを、今後のアドバイザリでもっと分かりやすく打ち出してほしい。せっかく脆弱性の検出・開示体制は世界トップクラスなのだから、現場が迷わず動ける情報の出し方まで含めて、正面から評価される存在であってほしいと思っている。 また、AD FSのようなID基盤が繰り返し標的になる状況を見るにつけ、パッチ適用だけに頼らない防御も改めて重要だと感じる。常時アクセス権を減らしJust-In-Timeで必要な時だけ権限を渡す設計にしておけば、仮に一つの脆弱性を突破されても被害の広がりを抑えられる。パッチは後追いにならざるを得ない以上、平時からの権限設計こそが本当の防御線になる。 出典: この記事は Record-Breaking Microsoft Patch Tuesday Update: 570 Vulnerabilities Fixed, Including 3 Zero-Days の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OnePlusは2014年の登場以来、「フラッグシップキラー」を掲げ、ハイエンドの性能を抑えた価格で提供するブランドとして北米・欧州のAndroidファンから支持を集めてきた。米メディア9to5Googleが2026年7月13日（現地時間）に報じたところによると、同社は今週中にも米国・欧州市場から正式に撤退する。複数の情報筋を引用した同報道によれば、新機種の投入・販売は停止するが、既存端末へのソフトウェアアップデートとサポートは継続される見通し。在庫端末のみ売り切る「クローズアウト」方式が取られるとみられる。 なぜこの撤退が注目か 今回の報道が事実であれば、Android市場で10年以上続いた独立系フラッグシップブランドの存在感が大きく後退することになる。背景には親会社Oppoグループ内でのブランド再編があるとみられ、Oppo自身が北米・欧州で「Find X」シリーズによるフラッグシップ展開を強化する方針との観測が強い。同一グループ内で複数ブランドが同じ市場・同じ価格帯で競合する非効率を解消する狙いがあると考えられる。 海外レビューのポイント 9to5Googleの報道では、OnePlusが直近数年で北米市場向けの投資を縮小してきた経緯が指摘されている。キャリア向けモデルの投入減少、広告・マーケティング予算の縮小、店舗展開の停滞などが挙げられ、「実質的な撤退はすでに進行していた」との見方が示されている。また同メディアが7月10日に公開した解説動画「What went wrong with OnePlus?」でDamien Wilde氏は、OnePlusが近年ソフトウェア面でOppoとの統合を進める一方、軽量なOxygenOSの思想などブランド独自性が薄れていった点を要因の一つに挙げている。評価できる点として既存ユーザーへのサポート継続が明言されていることが挙げられる一方、気になる点として新規購入を検討する層にとって長期サポートの不透明感が残ることが指摘されている。 日本市場での注目点 OnePlusはもともと日本国内でキャリアの正規販売網を持たず、Amazon.co.jp経由の直販や海外版の並行輸入が中心だった。そのため今回の米欧撤退が日本のユーザーに与える直接的な影響は限定的とみられるが、「OnePlus 13」など現行モデルを日本から購入するルート自体が先細りする可能性はある。OnePlusはハイエンド機を10万円台前半に抑える価格戦略で、SIMフリー市場において貴重な選択肢の一つだった。今後この価格帯はGoogle Pixelシリーズやシャオミ（Xiaomi）が担う比重が増すとみられる。一方のOppoも日本では正規展開していないため、Find Xシリーズが国内の店頭に並ぶ可能性は現時点で低い。 筆者の見解 Microsoft MVPとして長年PC・スマートフォン市場を見てきた立場から言えば、今回の報道は「一つのブランドで全方位を戦う」ことの限界を象徴している。Oppo・OnePlus・realmeと兄弟ブランドを乱立させてきたBBK Electronics系グループが、地域ごとに主力ブランドを一本化する方向へ舵を切るのは、経営判断として筋が通っている。部分最適の積み重ねが全体として非効率・高コストにつながるのは、スマートフォン業界に限った話ではない。日本の読者への直接的な影響は小さいものの、SIMフリー端末選びの選択肢が一つ減るのは事実であり、価格と性能のバランスを重視するユーザーはPixelやXiaomiなど代替の選択肢を早めに検討しておくのが堅実だろう。標準的でサポートが安定した選択肢を選ぶという姿勢は、スマートフォン選びにおいても変わらず有効だ。 関連製品リンク OnePlus 13 16GB+512GB Sim-Free Smartphone 80W SUPERVOOC Rapid Charge and 50W AIRVOOC Charging, 120Hz 6.82 inch 6000mAh High Capacity Battery 上記はAmazon.co.jpへのリンクです。記事執筆時点の情報であり、価格・在庫は変動する場合があります。 出典: この記事は OnePlus will reportedly officially shut down in the US and Europe later this week の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Windows 11に標準搭載されているセキュリティ機能「Microsoft Defender」の最新アップデートに、攻撃者がPCのディスク容量を意図的に満杯にできてしまう不具合があると報告されている。海外メディアNeowinが伝えたもので、悪用されればディスクの空き容量が枯渇し、アプリの起動失敗やシステムの不安定化、最悪の場合はOSの正常な動作継続が困難になるおそれがある。 何が起きているのか Defenderはマルウェアの検出時、疑わしいファイルを隔離（Quarantine）したり、スキャンログを記録したりする挙動を持つ。今回報告されている不具合は、細工されたファイルや特定の操作をトリガーにこの隔離・ログ処理が異常な形で繰り返され、コピーやログが際限なく生成され続けることでディスク容量を食い潰す、というものとみられる。いわゆる「リソース枯渇型」の不具合で、情報を盗み出したり権限を奪ったりする侵入型の脆弱性とは性質が異なり、サービス妨害（DoS）に近い挙動だ。 セキュリティソフト自身が持つ「守るための処理」が逆手に取られる構図は目新しいものではなく、アンチウイルス製品では過去にも類似の報告が繰り返されてきた。今回の件も、Defenderのアップデートで新たに導入・変更された処理が想定外の入力に対して脆弱だった、という典型的なリグレッションの一種と考えられる。 実務への影響 日本の企業でWindows 11とMicrosoft Defenderを使っている環境は非常に多く、他人事ではない。特に以下の点は実務でチェックしておきたい。 即座の全展開を避ける: Intune・WSUS・Configuration Managerなどでリング展開（一部端末→段階拡大）の運用をしている場合、Defenderのプラットフォーム更新やエンジン更新もその対象に含め、一斉配信を避ける ディスク容量の監視アラート: サーバー・エンドポイント問わず、ディスク使用率の急増を検知するアラートを仕込んでおけば、この種の不具合が発生した際の被害を最小化できる 修正パッチの適用状況を追う: Microsoft側が修正版を出し次第、検証環境で確認してから本番展開するフローを徹底する 筆者の見解 正直に言うと、Windows Updateまわりは最近「すぐ当てたら壊れた」という報告も増えていて、判断が難しくなってきている。今回のようにセキュリティ機能そのもののアップデートが新たな問題を持ち込むケースが出てくると、その傾向はなおさら顕著になる。 だからこそ、リリース直後に全台へ即時適用するのではなく、数日様子を見てから展開する、という判断は決して臆病なのではなく、立派なセキュリティ判断だと考えている。Defenderのような基盤コンポーネントで足元をすくわれるような不具合が出るのはもったいない話で、Microsoftには基盤の品質でこそ正面から勝負してほしいという期待を込めて、あえて厳しめに見ておきたい。 段階的ロールアウトや監視体制の整備は、こうした不確実性を前提にした「道のど真ん中」の運用であり、特別なことではなく当たり前に備えておくべき基本動作だ。今回の件を機に、自組織のパッチ適用フローを見直すきっかけにしてもよいだろう。 出典: この記事は New Microsoft Defender update can let hackers totally fill your Windows 11 PC disk space の内容をもとに、筆者の見解を加えて独自に執筆したものです。

アニメ調の映像表現に特化した動画生成AIモデル「AnimeGen」が、AIdeaLabによって無償公開された。Hugging Face上で誰でもダウンロード可能で、ライセンスはApache 2.0。商用利用も認められており、PC Watchが報じている。 なぜAnimeGenが注目か 動画生成AIの分野では、RunwayやOpenAIのSora、Googleの動画生成モデルなど、海外発のクローズドなクラウドサービスが先行してきた。それに対しAnimeGenは、モデルの重みそのものをApache 2.0ライセンスで公開し、商用利用も無条件に許可している点が大きな特徴だ。 開発を主導したAIdeaLabは、経済産業省と新エネルギー・産業技術総合開発機構（NEDO）が推進する生成AI開発力強化プロジェクト「GENIAC」の支援を受けており、KDDIが提供するNVIDIA H200を24基搭載したGPUクラスタで学習を行った。国のプロジェクトから生まれた基盤モデルが、無償かつ商用利用可能な形でオープンに公開される事例として注目に値する。 ベースとなっているのは動画生成モデル「Wan 2.2」で、そこにアニメ調の映像表現に特化した追加学習を施している。キャラクター、背景、色彩、構図、動きといった、アニメ制作や映像表現の試作に求められる出力を意識して調整されているという。 AnimeGenの技術的なポイント AnimeGenには、テキストから動画を生成する「T2V」と、静止画から動画を生成する「I2V」の2種類が用意されている。推奨プロンプトは英語。 推奨動作環境はGeForce RTX 4090以上で、VRAM容量が大きいGPUほど、より長尺・高解像度の動画生成が可能になる。約半年間にわたるベータテストを実施して安全性や実用性を検証しており、その範囲では重大な権利侵害などの問題は確認されなかったとしている。 注目したいのは、開発元自身がいくつかの限界を率直に明示している点だ。アニメ調表現に特化しているため実写・フォトリアルな映像生成には不向きであること、複雑なキャラクターの動作では破綻が生じやすいこと、手・指・目・装飾品といった細部表現が不安定になる場合があること、フレーム間でキャラクターの見た目が変化したりちらつきが発生したりする制限があることを、公開時点で明記している。 想定用途としては、アニメ制作におけるムービーコンテやプリビジュアライゼーション（映像の事前検討）、キャラクターの動き・背景・構図・雰囲気の試作、短尺のアニメ風映像コンテンツ制作、動画生成技術そのものの研究・実験などが挙げられている。 日本市場での注目点 AnimeGenそのものはモデルの重みが無償公開されているため、導入コストはかからない。ただし快適に動かすには相応のGPUへの投資が必要で、推奨環境のGeForce RTX 4090に加え、より長尺・高解像度な生成を狙うならVRAM容量の大きいGeForce RTX 5090クラスへの投資も選択肢になる。 海外の主要な動画生成AIサービスは、クラウド経由のAPI課金制で提供されるものが大半で、商用利用にも制限や追加ライセンスが必要なケースが多い。それに対しAnimeGenは、ローカル環境で完結し、商用利用を含めて追加コストなしで使える点がユニークだ。日本は世界有数のアニメ・イラスト市場を持つだけに、制作スタジオやインディークリエイター、映像系スタートアップにとって、試作段階のコストを大幅に下げられる選択肢として注目される。 国内のGPUクラウドサービスや自作PCショップでも、RTX 4090・5090搭載機の需要が今後高まる可能性がある。 筆者の見解 今回のAnimeGenのように、国のプロジェクトから生まれた基盤モデルが無償・商用利用可能な形でオープンに出てくる流れは、素直に良い方向だと感じる。生成AIについては情報をあれこれ追いかけるよりも、実際に手元の環境で動かしてみて何ができるかを体感するほうが得るものが大きい。RTX 4090クラスのGPUを持っているエンジニアやクリエイターであれば、まずはダウンロードして試してみるのが一番早い理解の仕方だろう。 もう一つ好感が持てるのは、開発元が「手・指・細部が不安定になる」「フレーム間でちらつきが出る」といった限界を隠さずに公開している点だ。生成AIのニュースは良い面ばかりが強調されがちだが、できることとできないことを正直に示す姿勢は、実際に導入を検討するクリエイターやスタジオにとって実用上ありがたい情報になる。 商用利用可能なオープンモデルは、大企業だけでなく個人やスタートアップが自分たちのアイデアを形にする土台にもなる。AnimeGenのようなプロジェクトが今後も継続的に出てくるかどうかは、GENIACのような支援の枠組みが次にどう動くか次第でもある。しばらくは動向を追いかけておきたい分野だ。 関連製品リンク Gigabyte GeForce RTX 4090 Gaming OC 24G Graphics Card Nvidia GeForce RTX 5090 Founders Edition 上記はAmazon.co.jpへのリンクです。記事執筆時点の情報であり、価格・在庫は変動する場合があります。 出典: この記事は 商用利用OKのアニメ特化動画生成AI「AnimeGen」が無償公開 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft研究チームが、自社エンジニア数万人を対象にAnthropicの「Claude Code」とGitHubの「GitHub Copilot CLI」という2つのコマンドラインAIコーディングエージェントの導入実態を追跡調査した論文を公開した。2026年初頭の社内ロールアウトを分析した結果、これらのツールを使い始めたエンジニアは、使わなかった場合と比べてマージされたプルリクエスト（PR）数が約24%多かったという。 調査の中身 Emerson Murphy-Hill氏らMicrosoftの研究者3名がarXivに投稿したこの論文は、「Adoption and Impact of Command-Line AI Coding Agents」と題され、企業規模でのAIコーディングエージェント導入における3つの疑問——誰が試すか、誰が使い続けるか、コストに見合う成果が出ているか——に答えようとしたものだ。 調査結果のポイントは3つある。 最初の利用は社内の人間関係を通じて広がった。公式な研修や通達よりも、同僚が使っている様子を見ることが利用開始のきっかけになっていた 利用の継続は属性（役職や勤続年数）よりも、その人が普段どれだけ活発にコードを書いているかと強く関係していた 導入者は非導入者に比べてマージPR数が約24%多く、この差は4カ月間の観測期間を通じて一貫して続いた 研究チーム自身も「マージされたPRがそのまま提供価値を意味するわけではない」と釘を刺しており、単純な本数だけで生産性を語らない慎重な姿勢も示している。 実務への影響 日本のIT現場にとって示唆に富む調査だ。まず、CLI型AIエージェントの社内展開を検討する際、研修資料の整備や利用マニュアルの配布よりも、「使っている人の姿を見える化すること」の方が効果的だという点は覚えておきたい。Slackやチームの朝会で実際の活用例を共有する、社内Wikiに成功事例を蓄積する、といった地道な施策が普及の近道になる。 また、「導入すれば自動的に成果が出る」わけではなく、もともとコードを書く量が多いエンジニアほど使い続けるという結果も重要だ。AIエージェントは魔法の杖ではなく、既存の実務能力を増幅する道具だという理解のもとで展開する必要がある。 PR数24%増という数字も、KPIとして一人歩きさせるのは危険だ。マージ数だけを目標に据えると、質を犠牲にした「数稼ぎ」を誘発しかねない。研究チームが釘を刺した通り、成果指標は慎重に設計すべきだろう。 筆者の見解 興味深いのは、Microsoft自身の研究チームが、自社製品のGitHub Copilot CLIだけでなく競合であるAnthropicのClaude Codeも並べて公平に調査対象にしている点だ。都合の良いデータだけを見せるのではなく、実態を正面から検証しようとする姿勢は素直に評価したい。 GitHub Copilot CLIの存在自体も注目に値する。これまでのCopilotはエディタに寄り添う「副操縦士」型の体験が中心だったが、CLIエージェントという形は、目的を伝えれば自律的にタスクをこなす方向への一歩だ。ここ数年のCopilotの評判には物足りなさを感じてきた読者も多いはずだが、この路線は正しい方向であり、Microsoftには本気で勝負できる力があるのだから、中途半端に終わらせず突き詰めてほしい。 もう一つ評価したいのは、「トークン消費量」のような安直な数字ではなく、PRマージ数や継続率という多角的な指標で導入効果を測ろうとした設計思想だ。AI活用度を測ること自体は正しい方向であり、こうした地に足のついた検証を重ねる企業が、結局は組織的なAI活用で一歩抜け出すことになるだろう。 出典: この記事は A Study of Microsoft’s Early 2026 Rollout of Claude Code and GitHub Copilot CLI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年7月13日、Entra ID(旧Azure AD)の多要素認証(MFA)において、SMSワンタイムコードと音声通話による認証方式を2027年2月1日をもって提供終了すると発表した。管理者向けメッセージセンター通知(MC1426371)で明らかにしたもので、Microsoft自身がホストするSMS・音声認証サービスが姿を消し、以降はパスキーが既定の認証方式となる。 何が終了し、何が変わるのか 現在Entra IDでは、MFAチャレンジの選択肢としてMicrosoftが無償でSMSワンタイムコードや音声通話の確認コードを送信している。この仕組みが2027年2月1日で終了する。それでもSMS・音声認証を続けたいテナントは、2026年9月18日から提供されるMicrosoft Security Store経由でテレコムプロバイダーのサービスを別途購入する必要がある。「無料でついてくる」認証方式ではなくなるわけだ。Microsoft Authenticatorアプリやパスキーは対象外で、引き続き無償で使える。 なぜ電話認証を切り捨てるのか SMS・音声によるMFAは、共有シークレットと公衆電話網に依存する認証方式で、SIMスワッピング(攻撃者が携帯キャリアを騙して被害者の番号を自分のSIMに移す手口)やメッセージ傍受、番号の再割り当て、ソーシャルエンジニアリングによる突破が以前から知られていた。パスキーは公開鍵暗号方式のため、こうした攻撃への耐性が格段に高い。 Microsoftは2024年時点でMFA応答の44%がSMS・音声経由であり、SMSはAuthenticatorアプリより突破される確率が40%高いというデータを示している。管理者向けMFA必須化以来、段階的に電話認証からの移行を促してきたMicrosoftだが、今回はいよいよ「終了日」を明示した格好だ。 移行スケジュールとテナントの準備 2026年9月からEntra IDはSMS・音声利用者に対して自動的にパスキーを有効化し、登録キャンペーンを「Microsoft managed」に設定してパスキー作成を促す。ユーザーは一時的にスキップできるが、最終的には登録が必要になる。2027年2月1日以降、準備が整っていないユーザーはMFAチャレンジに応答できずサインインできなくなる可能性があり、ヘルプデスクへの問い合わせ増加は避けられないだろう。対象ユーザーの洗い出しには、Microsoftが提供する「passwords and authentication methods report」PowerShellスクリプトが使える。 実務への影響 日本企業のEntra ID管理者にとって、これは対岸の火事ではない。現場作業員や非デスクワーカー向けにSMS認証を採用している企業、取引先・協力会社アカウントでSMSを既定にしている企業、古い条件付きアクセスポリシーのままMFA方式を限定していないテナントは要注意だ。まずは前述のPowerShellレポートで対象アカウントを棚卸しし、パスキー対応デバイス(Windows Hello、iOS/AndroidのFIDO2対応、セキュリティキー等)の可用性を確認したい。17か月の猶予は十分に見えるが、非デスクワーカーへのデバイス展開や取引先への周知には想像以上に時間がかかる。年内に移行計画を立てて動き出すのが賢明だ。 筆者の見解 今回の発表は、素直に評価できる判断だと思う。SMSや音声通話は仕組み上どうしても攻撃の余地が残る認証方式で、SIMスワップ被害のニュースは以前から後を絶たない。ゼロトラストの観点でも認証層の強度を底上げする今回の動きは筋が通っている。 好感が持てるのは、いきなり「禁止」にするのではなく、自動でパスキーを有効化しつつ登録キャンペーンで気づかせ、猶予期間を設けて段階的に移行させる設計になっている点だ。ユーザーが一番使いやすいと感じる方式が結果的に一番安全な方式になる——これがセキュリティ施策の理想形で、Microsoftはこの手の「使ってもらう工夫」に関しては昔から強い。応援したくなる部分だ。 一方で、日本の大企業の現場を見ていると、SMS認証に頼っているアカウントが今でも相当数残っているのが実情だ。昔ながらのセキュリティ運用と中途半端なゼロトラスト導入が混在したテナントでは、今回のような「土台からの変更」に対応しきれず、2027年2月に駆け込みで慌てる組織が出てくるのは目に見えている。今のうちから対象アカウントを洗い出し、パスキー移行を粛々と進めておくことをお勧めしたい。正面から準備すれば怖くない変更のはずだ。 出典: この記事は Microsoft to Stop Providing Telephony-Based Authentication Methods for MFA in February 2027 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米Microsoftは2026年7月13日、Office 2019および一部の古いバージョンのOffice 2021・Microsoft 365アプリについて、Mac版とiOS版を「機能制限モード」へ移行させた。対象デバイスではファイルの閲覧・印刷は引き続きできるが、編集・保存・新規作成は一切できなくなる。Windows版・Android版は今回の対象外だ。 何が起きているのか 対象はWord、Excel、PowerPoint、Outlook、OneNoteといった主要アプリ。Microsoftのサポートページによれば、ライセンス認証に使っている証明書が期限切れを迎えることが理由とされている。証明書が失効するとアプリ側でライセンスの正当性を確認できなくなり、安全側に倒して編集機能を止める、という理屈だ。 ただし証明書は本来更新できるものでもある。Microsoft 365サブスクリプションおよびOffice 2021のユーザーは、アプリをバージョン16.83以降に更新すれば影響を回避できる。macOS 11以前を使っている場合は、先にmacOS Monterey（12）以降へアップデートする必要がある。 問題は買い切り版のOffice 2019だ。こちらにはMicrosoftから救済アップデートが提供されない。つまり「一度購入したソフトウェアの機能が、ベンダー側の判断で止まる」形になる。Microsoftは2023年10月にOffice 2019 for Macのサポートを終了した際、「Office 2019アプリは引き続き機能する」と案内していた経緯があり、今回の措置はその説明とかみ合っていない。 対象かどうかの確認方法 Wordを開き「Word」>「Wordについて」からバージョン番号とライセンス種別を確認する。バージョンが16.83以上であれば当面は問題ない。16.82以下でライセンス種別が「Retail License 2019」の場合、Microsoft 365への切り替え、Office 2024の購入、あるいはPagesやGoogle Docsなど代替アプリへの移行が現実的な選択肢になる。 実務への影響 日本のIT現場でまず点検すべきは「個人所有Mac・iPadでの業務利用」だ。BYOD環境や、経費精算の隙間で私物Macに古いOfficeを入れっぱなしにしているケースは珍しくない。情報システム部門が把握していない「野良Office 2019」は、7月13日を境に編集不能になり、現場からの問い合わせが集中する可能性がある。 対応の勘所は3つ。第一に、社内のMacデバイス台帳とOfficeライセンス種別を突き合わせ、Retail License 2019の残存を洗い出すこと。第二に、Microsoft 365サブスクリプションへの統合を優先すること。買い切り版は今回のように予告なく機能が止まるリスクを内包しており、サブスクリプション型に寄せておいた方が長期的な運用コストは低い。第三に、Windows/Android端末は今回影響を受けないため、対応範囲をMac/iOSに絞ってよい。 筆者の見解 証明書の期限切れという技術的な理由づけ自体は理解できる。だが、買い切りライセンスで購入したソフトウェアの編集機能を、ユーザー側に非のない形で止めてしまうやり方には正直、賛成しがたい。2023年には「引き続き機能する」と案内していたのだから、なおさらだ。 筆者はMicrosoft製品を長年使い、応援する立場のMVPとして書いているからこそ言いたいのだが、これは「やらなくていいこと」だと思う。買い切り版というライセンス形態を選んだユーザーは、そこに「一度払えば安心して使い続けられる」という価値を見出していたはずだ。その前提を後から崩すやり方は、サブスクリプションへの移行を促す近道に見えても、長期的にはブランドへの信頼を削ってしまう。Microsoftほどの技術力と顧客基盤があるのだから、正面から「Microsoft 365の方がこれだけお得です」と価値で選んでもらう戦略の方が、よほど筋が良いはずだ。 日本企業にとっての教訓はむしろ別のところにある。資産管理台帳とライセンス実態が一致していない組織は、今回のような「静かな仕様変更」のたびに現場が混乱する。サブスクリプション統合と資産の可視化を平時から進めておくことが、この手のニュースに振り回されない一番の予防策だ。 出典: この記事は Microsoft is disabling Office 2019 for Mac on July 13, 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anthropicは7月13日(現地時間)、対話型AI「Claude」が会話の中で示す価値観がモデルや言語によってどのように変化するかを定量化した調査結果を発表した。PC Watchの竹元かつみ氏がこの内容を報じている。約30万9815件の実際のClaude.ai会話を分析した本調査は、「同じ相談でも使う言語によってAIの応答姿勢が変わる」という、生成AIを日常的に使うユーザーの体感を裏付けるものとして注目を集めている。 339種類の価値観を4つの軸に圧縮 調査のベースになったのは、Anthropicが過去に実施した先行研究「Values in the Wild」で特定した3307種類の価値観だ。今回はこれを339種類に整理し、プライバシー保護分析ツール「Clio」を用いて、3モデル×主要20言語の組み合わせごとに約5000件、合計30万9815件の会話を分析。価値観の現れ方を次の4軸に圧縮して定量化した。 従順さ 対 慎重さ 温かさ 対 厳密さ 深さ 対 簡潔さ 率直さ 対 遂行 モデルごとの"キャラクター"が数値で裏付けられた 結果はユーザーの体感とよく一致していた。「Claude Sonnet 4.6」は温かさとユーザーへの従順さに傾く一方、「Claude Opus 4.7」は慎重さと深さに最も強く傾き、誤った前提への反論やリスク指摘をいとわない。「Claude Opus 4.6」は要点に直行する簡潔さが際立つという。これまで主観的に語られてきたモデルごとの"性格"の違いが、軸上の位置として数値で示された形だ。 言語間の差はモデル間より大きい さらに注目すべきは、モデル間の差よりも言語間の差の方が大きかった点だ。温かさに最も傾くのはヒンディー語とアラビア語で、丁寧な言葉遣いやユーモア、アイデアへの肯定的な反応が目立つという。逆に英語とロシア語では、前提を疑い根拠を求める厳密さが強まる傾向が見られた。同じ事業計画への意見を求めても、尋ねる言語によって受け取る印象が変わりうるということだ。 なお、この差が学習データの偏りに由来するのか、言語ごとの会話規範に沿った"望ましい"変化なのかは、現時点では明らかになっていない。Anthropicは、ここでいう「価値観」はあくまで応答に表れた規範的傾向であり、Claudeが内面的に価値観を持つことを意味するものではないと注記している。今後はこの測定手法をモデルの出荷前評価や運用後の継続監視に組み込む方針だという。 日本市場での注目点 今回のデータで名指しされているのは英語・ロシア語・ヒンディー語・アラビア語で、日本語がどの位置にあるかは明らかにされていない。だが国内でもClaude.aiやClaude Code、Claude API連携の業務アシスタントを日本語で使う機会は急速に増えている。Anthropicはこのところ企業向け展開も加速させており、業務利用の現場では「同じ指示でも言語によって応答の慎重さや踏み込み方が変わりうる」という前提を持っておくことが重要になるだろう。 英語圏のレビューや評価記事を読んで「Claudeはこういう性格だ」と理解しても、実際に日本語で使ったときの挙動は異なる可能性がある。プロンプトの検証やガードレール設計を行う際は、英語での評価結果をそのまま流用せず、日本語での実地確認を挟むのが安全だ。 筆者の見解 生成AIの「性格」を数値化するというアプローチ自体が、地に足のついた良い取り組みだと感じる。従来「優しい」「慎重」といった評価はユーザーの主観的な印象論に留まりがちだったが、これを4軸のスコアとして継続的に測定し、出荷前評価や運用監視に組み込む方針は、AIベンダーとしての説明責任を果たす姿勢として素直に評価したい。 一方で実務目線では、この結果を鵜呑みにせず「日本語では実際どうなのか」を自分の手で確かめる方が早い。海外の英語記事やベンチマークをいくら読み込んでも、日本語プロンプトでの挙動は結局試してみないとわからない。情報を追いかけることに時間を使うより、実際に日本語で問いかけて挙動を確認し、業務フローに組み込んで成果を出す方が今は正しい行動だと考えている。特に企業でAIエージェントを設計する際は、確認・承認を都度求める設計に頼るのではなく、言語ごとの応答傾向を踏まえた上で自律的にタスクを遂行できる設計を目指すべきだろう。 出典: この記事は Claudeの“性格”は言語で変わる。英語は厳しくアラビア語は温かい の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Apple Carの自動運転技術開発は2024年に断念されたが、10年間で100億ドル(約1.5兆円)が投じられたとされる。この「失敗」は単なる無駄ではなく、現在のApple全体のAI戦略を下支えする技術基盤を生み出していた——そんな見立てをBloombergのマーク・ガーマン氏(Mark Gurman)が報じ、Tom’s Guideのトム・プリチャード氏(Tom Pritchard)が7月13日付でまとめている。 なぜこの報道が注目か Appleは生成AIブームへの対応で出遅れているとの評価が根強く、刷新版Siri「Siri AI」の開発難航はその象徴だ。しかしガーマン氏の報道によれば、レベル5の完全自動運転車を実現するために構築を進めていたリアルタイムAI処理基盤が、結果的にAppleのAIチップ戦略の礎になっていたという。「失敗した巨大プロジェクトがどう資産に転化されるか」という企業経営上の教訓としても興味深い。 Apple CarからNeural Engineへ、そしてM7世代へ Appleのチップに搭載される「Neural Engine」は、オンデバイスAI処理を担うAIアクセラレータ群で、2017年のiPhone X（A11 Bionicチップ）で初めて搭載された。Face ID・拡張現実・Apple Intelligenceといった機能を、消費電力を抑えつつプライバシーを守る形(端末内処理)で実現するのが狙いだ。 このNeural Engineは2020年の初代Apple M1以降、全てのM系列チップに搭載され、MacをローカルAI処理のパワーハウスに変えた。この設計思想はUltra系Macチップや、Apple Intelligenceのクラウドサーバー向けカスタムハードウェアにも波及しているという。 さらにガーマン氏は、AIへの傾注がAppleのチップロードマップそのものを変えつつあると指摘する。M6 Pro/Maxを見送り、M6から一気にM7世代へ移行する可能性が浮上しており、特にM7 Ultraはニューラル処理性能を大幅に強化し、NVIDIAの「Blackwell」級のAI専用アクセラレータに迫る性能を狙うという。M7 Ultraは1.5TBのメモリ対応が見込まれ、現行M5 Ultra搭載サーバーの2倍にあたる。 海外メディアの報道ポイント 評価できる点: 「無駄になった」と見られていた10年・100億ドル規模のApple Car投資が、Neural EngineというApple独自の差別化技術を育てる土壌になっていたという文脈は、単なる後付けの正当化を超えて説得力がある、とTom’s Guideは評価している。 懸念点: M7 Ultraの1.5TBメモリ対応は魅力的だが、複数台調達してAIサーバーを構成できるかは、いわゆる「RAMageddon」と呼ばれる世界的なDRAM需給逼迫・価格高騰の影響を強く受けるとガーマン氏は指摘する。Siri AIの遅れが象徴するように、ハードウェアの強みがソフトウェア面の遅れを完全に相殺できるかは依然不透明だ。 日本市場での注目点 M7世代チップの搭載製品や発売時期は未発表で、日本での価格・投入時期も現時点では不明。ただし過去の傾向からは、M-series世代交代はMac StudioやMac ProなどUltra系モデルから先行導入される可能性が高く、日本の開発者・クリエイター層への影響は無視できない。 NVIDIA Blackwell級の性能を目指す方向性は、ローカルで大規模AIモデルを動かしたい日本のエンジニアにとっても選択肢の広がりを意味する。一方でRAMageddonによるメモリ価格高騰は日本国内のPC・サーバー価格にも波及しており、次世代Mac Studioの価格設定にも注視が必要だ。 筆者の見解 Apple Carの顛末は「失敗プロジェクトの技術的副産物が、後の中核戦略を支える」という典型例として学びが多い。特にNeural Engineが体現する「オンデバイスでAIを処理し、プライバシーを守りながら日常的に使わせる」という設計思想は、企業がAI活用を広げる際の一つの正解のかたちだと考えている。禁止や制限で縛るのではなく、ユーザーが自然に「これが一番便利」と感じる仕組みを用意することがAI活用浸透の近道であり、それをハードウェアレベルで体現しているのがNeural Engineだ。 日本の企業やエンジニアにとっても、AIチップの性能競争のニュースを逐一追いかけるより、今使えるハードウェア・ソフトウェアで実際に成果を出す経験を積むことの方が優先度は高い。とはいえ、M7世代がもたらすオンデバイスAI性能の飛躍は、ローカルLLM活用の選択肢を広げる動きとして続報を注視したい。 出典: この記事は The Apple Car development may not have been as big a waste of time and money as everyone thought — in fact, it may be the thing that enabled Apple’s new AI boom の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

海外のデザイナーが公開した実験的タイポグラフィ「Ghost Font(ゴーストフォント)」が、SNSやテック系メディアで話題になっている。数百個の点が画面上で動くだけのアニメーションなのに、人間には隠された文字がはっきり読めてしまう。ところが同じ映像をChatGPTやGemini、Claudeといった生成AIに見せると、正しく読み取れないケースが相次いで報告されている。米Tom’s Guideのライター、Amanda Caswell氏が実際に試した記事を公開し、AIの画像認識が抱える意外な弱点を浮き彫りにした。 Ghost Fontとは何か Ghost Fontは、デザイナーのEric Lu氏が制作した実験プロジェクトだ。文字を輪郭線で描く代わりに、画面いっぱいに敷き詰めた無数の小さな点を使う。隠された文字の内側にある点は一方向に、周囲の点は別方向に動く。人間の脳は「動きの向きが同じ点同士」を無意識にグループ化して形として認識する能力があるため、輪郭が存在しないのに文字が浮かび上がって見える。逆にアニメーションを止めると、そこにはただのランダムなノイズしか残らない。 さらにこのプロジェクトには、AIを意図的に誤誘導する「おとりの文字列」を仕込む機能もある。人間には正しいメッセージが見えたままなのに、AIだけが自信満々に別の言葉を答えてしまう仕掛けだ。 海外レビューのポイント Tom’s Guideの記事では、実際にGhost Fontの公式サイトでアニメーションを生成し、それをChatGPT・Claude・Geminiにアップロードして「このアニメーションは何と書かれているか」と質問する手順を紹介している。同記事によると、多くの多モーダルAIモデルは動画を「連続する静止画の集まり」として処理する傾向が強く、Ghost Fontが意図的に排除している高コントラストな輪郭や安定した文字形状——従来のOCR(光学文字認識)が頼りにする特徴——が無いために、隠れた文字を検出しづらくなるという。Caswell氏は「AIがGhost Fontを絶対に読めないわけではない」と釘を刺しつつも、動きに対する処理方法の違いが弱点を生んでいると分析している。加えて、記事は「Ghost Fontは暗号化技術ではなく、開発者自身もセキュリティツールとして提示していない」という制作者の立場も明確に伝えている。 日本市場での注目点 Ghost Font自体は無料で誰でも試せるWebベースの実験プロジェクトであり、購入できる製品ではない。日本国内では今のところ大きな報道は見られないが、生成AIの画像・動画認識を業務利用しているエンジニアにとっては示唆に富む事例だ。特に、書類のOCR自動化やAIエージェントによる画面操作(スクリーンショット解析など)を導入している現場では、「静止画としては正しく見えるが動画としては誤読する」という弱点がそのままセキュリティ上の抜け穴になり得る。CAPTCHA(自動判定除け)の次世代版や、AIによる不正コンテンツ検出をすり抜ける手口として悪用される可能性も指摘されており、国内でAIモデレーションを設計する際の参考事例として押さえておきたい。 筆者の見解 今回のGhost Fontの件は、AIの限界を茶化すネタというより、「AIエージェントに何を任せて何を任せないか」を考える良い材料だと捉えている。動画を静止画の連続として処理するという今の多くのモデルの弱点は、裏を返せば改善余地がはっきりしているということでもあり、技術的には遠からず克服されていくはずだ。 むしろ実務で気にすべきは、こうした「AIが人間と違う見え方をする」隙間を悪用した、おとり文字列によるプロンプトインジェクションのような攻撃だ。ここで大事なのは、怪しい入力を片っ端から禁止するアプローチではなく、AIエージェントが処理する前段でコンテンツを正規化・検証する仕組みを標準機能として組み込むこと。禁止ベースの対策は必ずどこかから抜けるが、安全に使える仕組みが最初から用意されていれば、ユーザーもエンジニアも余計な心配をせずに済む。Ghost Fontのような研究が、そうした仕組みづくりのきっかけになるなら歓迎したい。 出典: この記事は Someone created a ‘Ghost Font’ that humans can read but AI can’t — I had to try it for myself の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Appleは日本時間7月14日未明(現地時間7月13日)、iOS 27・iPadOS 27・macOS 27「Golden Gate」・watchOS 27のパブリックベータ配信を開始した。米Engadgetのウィル・シャンクリン氏が報じたところによると、今回の目玉は開発者向けベータで先行導入されていた新しい「Siri AI」と、アプリ起動やAirDropの体感速度を引き上げるシステム全体の最適化だという。対応デバイスを持つユーザーなら、今日からベータ版を実機にインストールして試せる。 単なる音声コマンドから「会話できるAI」へ 新しいSiriは、決められたコマンドを認識するだけの仕組みから、自然な会話ができるAIアシスタントへと作り替えられた。会話の流れを踏まえた聞き返しに対応し、画面に表示されている内容について質問すると答えてくれるほか、アプリ内で複数ステップの操作を代行することもできるという。対応デバイスの一部では応答音声の表情豊かさも調整可能で、会話履歴を保存する専用の「Siriアプリ」も新設された。 開発者向けベータではウェイトリスト制で提供が絞られていたが、パブリックベータではApple Intelligence対応デバイス全体で利用できる。現時点では英語のみの対応で、EU域内では提供されない。 写真編集・Safari・パスワード管理も強化 写真アプリには、撮影後に構図を調整できる「Spatial Reframing」、画像の外側を生成して境界を広げる「Extend」、精度を高めた「Clean Up」が追加され、画像生成機能「Image Playground」もフォトリアルな高品質生成に対応した。Safariはタブの自動グループ分けと、価格変動・再入荷を監視する「Notify Me」を搭載。パスワードアプリは脆弱なパスワードの検知と自動更新に対応し、ショートカットは自然言語で自動化を組めるようになった。あわせてAirPods向けベータも公開され、カスタムイコライザーやアダプティブオーディオのスライダーが加わっている。 体感できるレベルの高速化 Appleによれば、アプリの起動は最大30%、写真アプリへの新規撮影画像の反映は最大70%、AirDropの転送は最大80%、それぞれ高速化されたという。加えて、昨年の大型デザイン刷新「Liquid Glass」への批判を受け、視認性を改善しつつ効果の強さをスライダーで調整できるようになった。 海外レビューのポイント シャンクリン氏は、公式の速度改善の数値そのものは検証していないと断ったうえで、「初期の開発者向けベータの段階でも、手元の端末は明らかにキビキビ動くようになったと感じた」と述べ、体感速度の向上には一定の信頼を寄せている。一方で、新Siriが開発者向けベータの時点でウェイトリスト制だったこと、公開後も英語限定・EU除外という慎重なスコープに留まっていることは、Apple Intelligenceの度重なる延期という経緯を踏まえると、品質を確保しながら段階展開しようとする姿勢の表れとも読み取れる。 watchOSでは、よく使うアプリを自動表示する「Dynamic App Grid」や、Smart Stackのウィジェットをワンタップで選べる操作、生理周期トラッキングへの更年期対応が加わった。macOS 27「Golden Gate」では、SpotlightからSiri AIを呼び出して画面内容の分析や文章作成支援を受けられるほか、ツールバーの統一やサイドバーの全面表示などMac向けのデザイン調整も行われている。 日本市場での注目点 パブリックベータは日本からもインストール可能だが、目玉のSiri AIは英語限定のため日本語では使えない。Apple Intelligence自体、日本語対応まで英語版から半年以上のタイムラグがあった前例があるだけに、新Siriの日本語対応も正式リリース(例年9月の新型iPhone発表と同時期が有力)以降、さらに遅れる可能性を織り込んでおきたい。iOS 27自体は無料のソフトウェアアップデートとして提供される見込みで、価格面での懸念はない。 筆者の見解 今回のSiri刷新で注目したいのは、「アプリ内で複数ステップの操作を代行する」という部分だ。従来の音声アシスタントは決まったコマンドで単発の操作を実行するだけで、複雑な作業は結局ユーザー自身が手を動かす必要があった。そこから一歩踏み込み、目的を伝えれば複数の手順をまとめてこなしてくれる方向に舵を切ったことは、AIアシスタント全般にとって正しい進化の方向だと感じている。 ただし、開発者向けベータでウェイトリスト制を敷き、公開後も英語限定・EU除外という慎重なスコープに留めているのは、裏を返せば「まだ手放しで信頼させられる完成度ではない」という判断の表れでもあるはずだ。ここは大目に見ずに正直に見ていきたい部分で、実際に使ったユーザーの声が今後の評価を左右するだろう。日本のユーザーとしては、スペック表を追いかけるより、日本語対応が来た段階で実際に触って自分の作業がどれだけ楽になるかを確かめるのが一番参考になるはずだ。 出典: この記事は Public betas for iOS 27, macOS 27 and more Apple platforms are now available の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftはWindows版Copilotアプリに、PCの状態を自然言語で問い合わせられる新機能「PC insights」を投入しようとしている。PC Watchが2026年7月13日に報じたところによると、Microsoftが公開したドキュメントの中でこの機能のテスト実施が明らかになった。現時点ではWindows版Copilotアプリのユーザー向けに段階的に展開されている段階で、すべてのPCで利用できるわけではない。 PC insightsとは何か PC insightsは、CopilotがPC本体のハードウェア仕様や稼働状況を把握したうえで、ユーザーの自然言語による質問にそのまま回答する機能だ。これまでユーザーが「設定」アプリや「システム情報」を自力で開いて確認していた項目を、チャットで尋ねるだけで済ませられるようにする。 挙動はシンプルだ。Copilotはまず質問に答えるために必要な情報を特定し、システムデータやファイルデータへアクセスする前にユーザーへ許可を求める。承認されると該当データを取得し、わかりやすい文章にまとめて回答する。全ファイルへ無条件にアクセスするわけではなく、取得したデータは保存もトレーニングへの転用もされないという。またPC insightsはあくまで情報提供にとどまり、PCの設定変更や修正は行えない。 どんな質問に答えられるのか 公開情報によれば、たとえば以下のような質問に対応する。 PCのスペックを教えて ウイルス対策ソフトは起動している? バッテリーの状態はどう? BIOSのバージョンは? どんなUSB機器が接続されている? CPU使用率はどのくらい? 大容量のゲームをインストールする空き容量はある? 「このゲーム、自分のPCに入るかな」といった、これまでスペック表とにらめっこして確認していた疑問に、Copilotが会話の延長で答えてくれる格好だ。まだ開発段階にあるため、常に完全かつ正確な情報を返せるとは限らないとMicrosoftも注記している。 日本市場での注目点 PC insightsはWindows Copilotアプリに追加される機能であり、単体で販売される製品ではない。追加コストなしで使える見込みだが、日本語での提供時期や対応範囲は現時点で明らかになっていない。段階的ロールアウトのため、Windows Insiderプログラム参加者や一部リージョンから先行する可能性が高い。 これまで日本のユーザーがPCのゲーム動作可否を調べる際は、メーカーの推奨スペック表を読み比べたり、家電量販店のスタッフに相談したり、海外の「Can I Run It」系サービスを使ったりするのが一般的だった。PC insightsが定着すれば、OS標準のCopilotに聞くだけで完結する選択肢が増えることになる。 筆者の見解 PC insightsの方向性は素直に評価したい取り組みだと感じる。スペック確認のために「設定」やコマンドを掘り下げる手間は、PC歴の長いユーザーほど当たり前にこなせても、多くの人には地味にハードルが高い作業だった。そこを公式のCopilotが肩代わりし、しかもデータを保存せずトレーニングにも使わないという設計にしたのは、「禁止するのではなく、安全に使える公式の仕組みを用意する」という王道のアプローチであり、好感が持てる。 一方で、動作の骨格を見ると、質問のたびにデータアクセスの許可を求める「都度確認」型の設計にとどまっている点は気になる。個人のPC状態という機微な情報を扱う以上、当面はこの慎重さが妥当だとしても、Copilotがより多くの文脈を任せてもらえる存在に育っていくためには、いずれ「聞かれたら答える」から一歩進んだ提案力が問われるはずだ。Microsoftには、せっかく地に足のついた便利機能を作ったのだから、ここで足踏みせず前に踏み込んでいってほしい。ゲームが快適に動くかどうかという実用的な疑問にAIが答えてくれる未来は、決して悪くない一歩だ。 出典: この記事は このゲーム、俺のPCに入る？その質問にCopilotが答えられる機能がテスト中 の内容をもとに、筆者の見解を加えて独自に執筆したものです。