Tech News JP

EUV露光装置を世界で独占供給するASMLのCEOと、Google Cloud COOらAIサプライチェーンの5人が、ミルケングローバル会議（ビバリーヒルズ）に登壇し、AI産業が直面する構造的な課題を赤裸々に語った。 チップ供給は向こう5年で逼迫が続く ASMLのCEO クリストフ・フォーケ氏は「チップ製造の急加速を進めているにもかかわらず、向こう2〜3年、場合によっては5年にわたって市場は供給制約下に置かれ続ける」と断言した。Google、Microsoft、Amazon、MetaといったハイパースケーラーはAIインフラに莫大な投資を行っているが、注文した分のチップを手に入れられない状態が長期にわたって続くということだ。 ASMLのポジションを踏まえると、この発言の重みは際立つ。EUV（極端紫外線）リソグラフィ装置なしに現代的な半導体チップは製造できない。その装置を世界で唯一供給できるのがASMLであり、そのCEOが「足りない」と公言したのだ。 Google Cloudのバックログが1四半期で1.8倍に膨張 Google Cloud COO フランシス・デサウザ氏は、需要の実態を数字で示した。同社のクラウド売上は直近四半期で200億ドルを突破し、前年比63%成長。さらに衝撃的なのはバックログ（受注残）の膨張で、わずか1四半期で2,500億ドルから4,600億ドルへとほぼ倍増している。「需要は本物だ」という言葉の裏に、供給が追いつかない現実がある。 宇宙データセンターは冗談ではない エネルギー問題への回答として、Googleが本格検討しているのが宇宙空間へのデータセンター設置だ。宇宙では太陽エネルギーが豊富に得られる一方、真空環境では対流冷却が使えず、放熱は輻射のみに依存する。それでも「現実的な選択肢」として研究が続いているという。 デサウザ氏はあわせて、カスタムTPUからモデル・エージェントに至るAIスタック全体を自社設計することによるワット当たり演算効率の高さを強調。「GeminiをTPU上で動かすのは他のどの構成よりもエネルギー効率が高い」と述べ、垂直統合の優位性を改めて訴えた。 物理AI：リアルワールドのデータは現場に出ないと取れない Applied IntuitionのCEO カサル・ユニス氏の制約は、チップでもエネルギーでもなく「リアルワールドのデータ」だ。同社は自動車・ドローン・防衛車両向けの自律制御システムを開発しており、「シミュレーションで合成データを作るだけでは限界がある。実際に機械を世界に送り出して観察しなければならない」と語った。物理AIの課題は、デジタル完結する大規模言語モデルとは根本的に性質が異なる。 基盤アーキテクチャ自体を問い直す動き 元Meta主任AI科学者のヤン・ルカン氏が技術顧問を務めるスタートアップ、Logical Intelligence の創業者イヴ・ボドニア氏は、量子物理学者の視点から現在のAIが依拠するトランスフォーマーアーキテクチャ自体に疑問を投げかけた。「車輪が外れかけているのはどこか」という問いへの、最も根本的な回答がここにある可能性がある。 日本のIT現場への実務的示唆 GPU確保戦略の即時見直し: NVIDIA H100/H200クラスのGPUが「予約しても来ない」状況は継続する。Azure・Google Cloud・AWS経由の利用や長期コミットメントによる確保を優先すべきタイミングだ。 電力コストの試算を今すぐ行う: AI推論の電力コストは今後さらに経営課題化する。オンプレミスGPU運用では電力単価・冷却コストを含めたTCO計算が必須。 物理AI領域は別の戦略が要る: 工場自動化・物流・農業など物理世界と連携するAIでは、リアルデータ収集パイプラインの構築がモデル精度より先の課題になる。 筆者の見解 「AIは無限に伸びる」という楽観論に対し、サプライチェーンの最前線にいる人たちが揃って「そうではない」と言っている。この一致は素直に受け止めるべきだ。 ASMLの発言の重みは特別だ。EUV装置は1台数百億円、製造に1年以上かかる精密機器であり、短期増産は不可能に近い。「5年の供給制約」が楽観的な見積もりだとすれば、AIインフラ競争の先行者優位はこれまでの想定以上に長期間固定されることになる。 宇宙データセンターが「本気の検討対象」になっているという事実も、地上の電力網と用地逼迫の深刻さを物語る。ハードウェアとエネルギーという物理的制約が、AIの進化速度そのものに上限を設けつつある。 ただ、制約があるからこそ「どのベンダーが最も効率よくAIを提供できるか」という競争は激しくなる。Googleの垂直統合戦略は、こうした環境では強みとして際立ちやすい。日本のIT組織は、クラウドベンダーの選定において「AI効率性」を評価軸の一つに加えることを今から検討する価値がある。 基盤アーキテクチャへの疑問は、より長期的なリスクとして頭の片隅に置いておきたい。トランスフォーマーの次が何になるかは誰も知らない。しかしその移行が起きるとき、今積み上げているインフラ投資の一部が無駄になる可能性も否定できない。 出典: この記事は Five architects of the AI economy explain where the wheels are coming off の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月、Windows 11の最新プレビュービルド（Build 26300.8346）で、Windows 10に存在した「小さいタスクバー」機能のテストを開始した。2021年のWindows 11リリース時に削除されたこの機能が、約5年越しに正式復活へ向けて動き出している。 Windows 10にあった「あの機能」がやっと戻ってくる Windows 10では、タスクバーの高さを自由にリサイズできる機能が標準で用意されていた。ところが2021年にWindows 11がリリースされた際、Microsoftはこの機能を削除。初期ビルドではドラッグ＆ドロップ機能まで廃止されたため大きな反発を招き、後者はユーザーの声を受けて復活したものの、タスクバーのリサイズ機能は今日まで戻ってこなかった。 最新プレビュービルドでは、タスクバーを縮小した際に表示されるウィジェットボタンの新しい小型デザインなど、実装の痕跡がすでに確認されている。また、タスクバーを画面端に移動できる「ムーバブルタスクバー」も並行して開発が進んでおり、Windows 10に存在したタスクバー関連の機能が一気に復活しつつある。 現在の「小さいタスクバーボタン」との違い Windows 11には現在、[設定]→[個人用設定]→[タスクバー]→[タスクバーの動作] に「タスクバーボタンを小さくする」トグルが存在する。ただしこれはボタンのアイコンを縮小するだけであり、タスクバー自体の高さは変わらない。 今回テストされているのは、タスクバー全体をリサイズできる機能だ。タスクバーの端にカーソルを合わせてドラッグすることで、Windows 10のように高さを調整できるようになる見込み。ドキュメントには専用の設定項目への参照も確認されており、完成度の高い実装が期待できる。 18項目に及ぶ大規模アップデートの一環 このタスクバー機能の復活は単独の話ではなく、Microsoftが進めるWindows 11の大規模テストの一部だ。同社は2026年3月に「Windows 11が方向を見失っていた」と公式に認め、最大18項目にわたる大幅な改善計画を発表した。 具体的にはパフォーマンス向上、広告の削減、ファイルエクスプローラーの高速化などが含まれており、2026年4月のオプションアップデート（Build 26200.8328）ですでに一部の改善が展開されている。「約束だけして終わる」ではなく、実際にプレビュービルドで変化が確認できるのは注目に値する。 実務への影響 企業のIT管理者にとって、この変更は基本的に対応不要だ。タスクバーのリサイズは個人設定の問題であり、セキュリティや業務アプリの動作に影響しない。 ただし、GPO（グループポリシー）でタスクバー表示をカスタマイズしている環境では、新しい設定オプションが追加されるタイミングで既存ポリシーとの整合性を確認しておくと安心だ。プレビュー段階から動作を把握しておくことで、本番展開時の混乱を防げる。 エンドユーザー視点では、特にマルチモニター環境や小型ディスプレイを使う開発者に恩恵が大きい。タスクバーを縮小することで垂直方向の表示領域が増え、コーディングや資料作成の作業効率向上が見込める。 筆者の見解 正直に言えば、「2021年に削除して5年後に戻す」というのはMicrosoftが実に得意なパターンだ。ドラッグ＆ドロップ機能もそうだったし、今回のタスクバーリサイズもそう。最初から残しておけばこんなに時間がかからなかった、と思うのは自分だけではないはずだ。 ただ、今回は少し違う点がある。Microsoftが公式に「方向を見失っていた」と認めたこと、そして言葉だけでなく実際にプレビュービルドで変化が確認できること。この2点は過去の「約束して終わり」とは異なる動きに見える。 Windowsというプラットフォームには、まだ膨大なユーザーベースと企業の信頼がある。ユーザーの声に真摯に向き合い、「使いやすいOS」という原点に立ち戻ろうとしているなら、それは素直に歓迎したい。「タスクバーを小さくしたい」という要望は些細に見えて、毎日作業するエンジニアにとっては積み重ねの話だ。5年かかったとはいえ、その声が届いたということは評価できる。今がWindows 11にとっての本当の分岐点かもしれない。 出典: この記事は Microsoft finally begins testing Windows 10-like smaller taskbar for Windows 11 after removing it in 2021 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

イーロン・マスク氏がOpenAIの解体を求めて起こした訴訟の審理が5月、米カリフォルニア州オークランドの連邦裁判所で進んでいる。元従業員や元取締役が証言台に立ち、OpenAIが「AGI（汎用人工知能）を人類全体の利益のために開発する」という創設理念から、商業的なプロダクト企業へと変質していった経緯が明らかになってきた。 マスク訴訟の核心：「非営利の使命 vs 営利化」 マスク氏の主張は、OpenAIが非営利研究機関から世界有数の民間企業へと転換したことで、創設者たちが暗黙的に合意していた契約が破られたというものだ。この訴訟の行方は、OpenAIの営利子会社がどの程度、組織の創設ミッションを強化または損なっているかにかかっている。 OpenAIは現在、Microsoftをはじめとする投資家から巨額の資金を得て急成長を遂げた一方、組織的ガバナンスと安全へのコミットメントが問われる局面を迎えている。 法廷で明かされた内部の変化 元従業員のロジー・キャンベル氏は、2021年にOpenAIの「AGI Readiness Team」（AGI準備チーム）に参加したが、2024年にチームが解散されたことを機に同社を退職した。同時期に安全研究に特化した「Super Alignment Team」（超整合チーム）も廃止されている。 「入社当初は研究中心の文化で、AGIや安全の問題について議論するのが当然の雰囲気でした。しかし時間が経つにつれ、プロダクト中心の組織に変わっていきました」とキャンベル氏は法廷で証言した。 また、MicrosoftがインドでBing検索エンジンにGPT-4モデルを組み込んだ際、OpenAI社内の「展開安全委員会（Deployment Safety Board）」による評価を経ていなかった事例も取り上げられた。キャンベル氏は「モデル自体のリスクは大きくなかったが、技術が強力になるにつれ、確実に守られるプロセスを今から確立しておく必要がある」と強調した。 ChatGPT公開をめぐる取締役会の機能不全 2023年に起きたサム・アルトマンCEOの一時解任劇も、今回の訴訟で改めて取り上げられた。当時の取締役メンバーだったターシャ・マコーリー氏の証言によれば、アルトマン氏が取締役会に対して十分な情報開示を行わないパターンが繰り返されていたという。 具体的には、ChatGPTのパブリックローンチを取締役会に事前に知らせなかったこと、別の取締役の発言について虚偽の情報を伝えたこと、利益相反の可能性があるビジネス案件を開示しなかったことなどが指摘された。 「私たちは非営利の取締役会であり、その使命は下部の営利組織を監督することでした。しかし私たちには、情報が十分かつ正確に伝えられているという信頼がまったくなかったのです」とマコーリー氏は述べた。 最終的に、OpenAIの従業員の多くがアルトマン氏を支持し、Microsoftも現状維持に向けて動いたことで、取締役会はアルトマン氏を復帰させ、反対派メンバーが辞任する結果となった。 実務への影響 この訴訟が問いかけるのは、単なる一企業のガバナンス問題にとどまらない。フロンティアAIラボの安全性をどのように担保するかという問いは、AIを活用する企業や組織すべてに関わるテーマだ。 エンジニア・IT管理者が注目すべきポイント： 利用するAIサービスのガバナンス体制を把握する: 自社製品・サービスで使うAIが、どのような安全評価プロセスを経てリリースされているかを確認する習慣を持つべきだ。今回の訴訟は、こうしたプロセスが形骸化しうることを示している 「安全委員会を通さないリリース」は他山の石: MicrosoftとOpenAI間でGPT-4がインドに展開された件のように、ベンダー間・チーム間での情報共有不備は自社の調達・導入プロセスでも起こりうる。社内のAIガバナンスプロセスを今一度点検したい AI規制の動向を追う: EUのAI規制法（EU AI Act）など、AI安全性に関する規制は今後強化される方向にある。AIサービスを自社に組み込む際、そのベンダーのコンプライアンス体制がどうなっているかを考慮することが重要になってくる 筆者の見解 この裁判が明らかにしているのは、フロンティアAI開発における「安全性の確保」と「商業的成長」の間にある根本的な緊張関係だ。 「研究機関からプロダクト企業への変質」という問題は、OpenAIに限った話ではない。急速に成長するあらゆる技術スタートアップが直面する普遍的な課題でもある。しかし、AGIという人類の未来に直結しうる技術を開発する組織においては、この問題の重みがまったく違う。 安全チームが解散され、展開安全委員会を経ない製品リリースが起きていたとすれば、それは「組織の優先順位がどこにあるか」を雄弁に語っている。取締役会が機能しなかった事実も合わせると、成長期のAI企業における組織ガバナンスの難しさが如実に示されている。 一方で、AIの研究と開発には莫大なリソースが必要なのも事実だ。商業的成功なしにフロンティア研究を継続することは現実的に困難という側面もある。だからこそ「安全性を犠牲にせずに商業化する」という両立の枠組みをどう設計するかが、この産業全体の課題となっている。 日本企業がAIを積極的に活用していくためにも、利用するサービスの安全設計に関心を持つことは重要だ。AIの力を最大限に引き出すためには、その基盤となる安全性への信頼が不可欠であり、今回の訴訟はそのための問いを業界全体に改めて突きつけている。マスク氏の動機がどこにあるにしても、この問いかけ自体の価値はある。 出典: この記事は Elon Musk’s lawsuit is putting OpenAI’s safety record under the microscope の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIは2026年5月7日、ChatGPTに「Trusted Contact（信頼できる連絡先）」機能を追加した。会話中に自傷・自殺に関する言動が検出された際、あらかじめ登録した家族や友人に自動でアラートを送信する安全機能だ。相次ぐ訴訟を受けた法的プレッシャーへの対応という側面もあるが、AIとメンタルヘルスの交差点において業界全体が注目すべき一手でもある。 Trusted Contactとは何か Trusted Contact機能は、ChatGPTの成人ユーザーが事前に「信頼できる連絡先」（家族・友人など）を登録しておくと、会話内容が自傷・自殺のリスクを示すと判断された場合に、その連絡先へ自動通知が届く仕組みだ。 通知はメール・SMS・アプリ内通知のいずれかで届き、「様子を確認してほしい」という趣旨の簡潔な文面となっている。会話の詳細な内容は含まれず、プライバシーへの配慮も施されている。 検知から通知までのフロー OpenAIの安全システムは自動化と人間によるレビューを組み合わせた二段階構成を採用している。 特定のキーワード・フレーズやコンテキストが自動検知される 検知情報が人間の安全チームへ転送される チームが「深刻なリスク」と判断した場合のみ、登録済み連絡先へアラートが発信される OpenAIは「通知を受け取ったケースは1時間以内に人間がレビューする」と述べている。完全自動ではなく、人間の判断を介在させることで誤報を抑制しようとしている点は重要な設計上の判断だ。 背景：相次ぐ訴訟と業界全体の課題 この機能導入の背景には、OpenAIが直面している一連の訴訟がある。ChatGPTとの会話後に自殺した利用者の家族が、「チャットボットが自殺を促した、あるいは具体的な計画立案を手伝った」として訴訟を提起しているのだ。 2025年9月には未成年向けのペアレンタルコントロール機能（保護者へのリスク通知）が先行導入されており、今回のTrusted Contactはその成人版にあたる。自動化アラートによる専門機関への誘導機能も以前から実装されていたが、今回は「人間のネットワーク」を組み込んだ点が新しい。 実務への影響 ユーザー・家族の観点から 精神的に脆弱な家族がChatGPTを日常的に使っている場合、この機能を有効にしておくことで早期介入の一助となりうる。うつ病やメンタルヘルスの課題を抱える人を身近で支える立場にある方は、機能の存在を知っておくだけでも価値がある。 企業・IT管理者の観点から 従業員がChatGPTを業務利用しているケースでは直接の管理対象にはなりにくいが、「AIを使う従業員のメンタルヘルス」という視点で認識しておくべき機能だ。EAP（従業員支援プログラム）担当者や産業医と情報を共有しておく価値はある。 注意すべき限界 Trusted Contactはオプション機能であり、有効化は任意だ。また、ユーザーが複数のChatGPTアカウントを持つことも可能なため、意図的に回避しようとするユーザーをシステム的に止めることはできない。あくまで「善意のユーザーへの安全網」として機能するものと理解しておく必要がある。 筆者の見解 AIが人の精神的危機に関与する場面は、今後ますます増えていく。ChatGPTのような会話AIに不安や悩みを打ち明けるユーザーが世界中に存在する現実は変わらない。この問題から目を背けず、機能として実装した判断は評価できる。 Trusted Contactが興味深いのは、「AIに問題を解決させる」ではなく「人間同士のつながりを橋渡しする」設計になっている点だ。AIが自律的に判断・解決しようとするのではなく、あくまで「人間に知らせる」役割にとどめている。この発想は、AIが担うべき役割とそうでない役割を適切に分けているという意味で理にかなっている。 ただ、根本的なジレンマも残る。本当に支援が必要な人が自発的に「連絡先を登録しよう」と行動できるかどうか、という問いだ。機能の実効性は、その存在をユーザーが認知するタイミングの設計（オンボーディング体験など）に大きく左右される。 OpenAIが「臨床家・研究者・政策立案者と連携して改善していく」と明言している点は、単なる機能リリースにとどまらない継続的な取り組みの意志表示として受け取りたい。AIとメンタルヘルスの交差点は、業界全体が正面から向き合い続けなければならない領域だ。 出典: この記事は OpenAI introduces new ‘Trusted Contact’ safeguard for cases of possible self-harm の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Palo Alto Networks は2026年5月7日、PAN-OS のユーザーID認証ポータル（Captive Portal）に存在するゼロデイ脆弱性 CVE-2026-0300 が、国家支援とみられる脅威アクターによって約1ヶ月にわたって悪用されていると警告した。インターネットに公開されたPA-Series・VM-Seriesファイアウォールが対象であり、パッチはまだリリースされていない。 脆弱性の概要：認証不要でrootを奪取 CVE-2026-0300 はバッファオーバーフロー起因のリモートコード実行（RCE）脆弱性だ。攻撃者は認証なしにroot権限でコードを実行できる。CVSSスコアは「Critical」相当であり、インターネット側に公開されているCaptive Portalが有効なファイアウォールが攻撃対象になる。 Palo Alto Networks の脅威インテリジェンス部門 Unit 42 は攻撃クラスターを CL-STA-1132 と命名して追跡している。同社の報告によれば、攻撃の流れは次のとおりだ： 4月9日 — PAN-OSデバイスへの悪用試行開始（失敗） 約1週間後 — RCE 成功。シェルコードが注入される 侵害直後 — ログ消去工作（クラッシュカーネルメッセージ削除、nginx クラッシュログ削除、コアダンプファイル削除）を即座に実施 ログを素早く消去する動きは、攻撃者がインシデントレスポンスを熟知しており、痕跡を最小限に抑えることを最優先としていることを示している。 使用ツール：EarthWorm と ReverseSocks5 侵害後、攻撃者はオープンソースのネットワークトンネリングツール EarthWorm と ReverseSocks5 を展開した。 EarthWorm：SOCKS v5 サーバーを構築し、制限されたネットワーク上で隠蔽された通信チャネルを確保する ReverseSocks5：ターゲットからコントローラーへのアウトバウンド接続を使ってNATやファイアウォールを回避する EarthWorm はこれまで Volt Typhoon、APT41、CL-STA-0046、UAT-8337 など複数の中国語圏の脅威グループが使用してきた実績がある。今回の攻撃についても同様の国家支援グループとの関連が強く示唆されている。 被害規模：日本を含むアジアが最多 インターネット脅威監視機関 Shadowserver の調査では、インターネット上に公開された PAN-OS VM-Seriesファイアウォールが5,400台以上に上ることが確認されている。 地域 公開台数 アジア 2,466台（最多） 北米 1,998台 アジアが最多というデータは、日本企業にとって無関係な話では済まない。アジア向け分がすべて日本というわけではないが、Palo Alto Networks の国内シェアの高さを考慮すれば、日本国内にも相当数の対象ファイアウォールが存在すると考えるべきだ。 対応状況と推奨される緩和策 パッチは2026年5月13日（水）に初回リリース予定。それまでの間、Palo Alto Networks は次の緩和策を「強く」推奨している： ...

米国司法省は2026年5月、北朝鮮のIT工作員が米国企業にリモート就職するのを支援した「ラップトップ農場」の運営者2名——Matthew Isaac KnootとErick Ntekereze Prince——にそれぞれ禁固18ヶ月の実刑判決を下した。被害を受けた企業は約70社にのぼり、経済的損失と事後対応コストの合計は数百万ドル規模に達している。 「ラップトップ農場」とは何か 「ラップトップ農場（Laptop Farm）」とは、他人名義で受け取った業務用ノートPCを自宅に並べ、北朝鮮のIT工作員が米国在住の正規社員を装ってリモートワークできるよう環境を整える犯罪インフラのことだ。 具体的な手口はシンプルかつ巧妙だ。 企業が採用したと思っている「Andrew M.」などの架空人物名義でノートPCを受け取る そのPCにリモートデスクトップソフトウェアを不正インストールする 北朝鮮側の工作員が海外から当該PCにアクセスし、米国在住社員として業務をこなす 給与は全額、北朝鮮政府の管理するルートを通じて送金される Knootはナッシュビルの自宅でこの農場を2022年7月〜2023年8月の約1年間運営。被害企業が支払った給与は25万ドル超。さらに事後の監査・システム修復コストが50万ドル超発生した。 PrinceはIT企業「Taggcar Inc.」を隠れ蓑に、2020年6月〜2024年8月の4年間にわたって少なくとも3名の北朝鮮工作員を複数の米国企業に潜り込ませた。給与総額は94万3,000ドルを超え、修復コストは100万ドル超に上った。 FBIが警告し続ける「見えない脅威」 FBIは少なくとも2023年から北朝鮮ITワーカーの米国企業侵入について繰り返し警告を出している。推定では、北朝鮮は毎年数千人規模のIT工作員を抱え、盗まれたアイデンティティを使って数百社に就職させているとされる。 今回の2名は今年に入って8人目の有罪確定者だ。昨年7月にはアリゾナ州在住のChristina Marie Chapmanが自宅で309社向けのラップトップ農場を運営した罪で禁固102ヶ月（約8年半）の判決を受けており、司法当局の摘発が本格化していることがわかる。 実務への影響——日本企業のリモート採用リスク これは米国だけの問題ではない。リモートワークが定着した現在、採用・受け入れプロセスに物理的確認が欠如していれば、どの国の企業も同様のリスクにさらされる。 IT部門・情報セキュリティ担当者がすぐ確認すべきポイント： PC配送先の住所確認: 会社支給PCの配送先が本人の居住実態と一致しているか。転送サービスや法人住所への配送は要注意 初回ビデオ通話での本人確認: 採用面接時と業務開始後の顔・背景・声が一致するか定期確認 IPアドレス・接続元の監視: 日本在住のはずの社員が海外IPから常時ログインしていないか リモートデスクトップソフトウェアの管理: MDMで管理されていない第三者製RDPツール（AnyDesk等）のインストールを検知・ブロックする 給与受取口座の実在確認: 口座名義と採用時の本人確認書類の突合 特にフリーランスや業務委託での採用増加に伴い、正社員採用ほど厳密な本人確認が行われないケースが増えている。発注側の管理強化が急務だ。 筆者の見解 この事件を「米国の話」として読み飛ばすのは危険だと思う。 リモートワークの普及は働き方の自由度を大きく広げた一方、採用・就業管理のプロセスに「物理的な確認」がなくなるという構造的な空白を生んだ。北朝鮮のようなステートアクター（国家支援型攻撃者）は、その空白を組織的・継続的に突いている。 日本企業の多くは「海外の話」「大企業の話」と感じるかもしれないが、グローバルな業務委託やオフショア開発が一般化している今、リモート人材の本人確認プロセスがどこまで整備されているかを見直す良い機会だ。 ゼロトラストの文脈でいえば、「ネットワークに繋がっているから社員」という前提はとうに崩れている。接続元・デバイス・アイデンティティの3点を継続的に検証するアーキテクチャを整備することが、このような「内部侵入」への根本的な対処になる。 セキュリティの話は細かくてとっつきにくい部分も多いが、「今動いているから大丈夫」という感覚が一番危ない。この摘発劇が日本国内のリモートワーク管理の見直しを促すきっかけになれば、報道する価値は十分にある。 出典: この記事は Americans sentenced for running ’laptop farms’ for North Korea の内容をもとに、筆者の見解を加えて独自に執筆したものです。

オーストラリア政府のサイバーセキュリティ機関ACSC（Australian Cyber Security Centre）が2026年5月、「ClickFix」と呼ばれるソーシャルエンジニアリング手法を悪用してVidar Stealerマルウェアを拡散するキャンペーンに対し正式な警告アドバイザリを発出した。攻撃者は侵害済みのWordPressサイトを踏み台にし、被害者を偽のCloudflare認証画面へ誘導してPowerShellコマンドを手動実行させるという巧妙な手口を使っている。 ClickFix攻撃の仕組み：「自分で実行させる」が防御を難しくする ClickFixは近年急速に普及しているソーシャルエンジニアリング攻撃手法だ。その特徴は、マルウェアを直接ダウンロードさせるのではなく、ユーザー自身に悪意のあるコマンドを実行させる点にある。 典型的な攻撃フローは以下の通りだ： 侵害済みWordPressサイト（または悪意のあるサイト）にユーザーが誘導される 偽のCloudflare認証画面または偽CAPTCHAが表示される 「確認のためにこの操作が必要です」と称してPowerShellコマンドをコピーするよう促される ユーザーがコマンドをPowerShellに貼り付けて実行するとVidar Stealerに感染する この手口が危険なのは、セキュリティソフトによる検知を回避しやすい点だ。ユーザー自身がコマンドを実行するため「正当なユーザー操作」として処理されてしまう。偽のCloudflare認証ページは精巧に作られており、一般ユーザーが本物と区別するのは困難な状況になっている。 Vidar Stealer：8年の歴史を持つ情報窃取マルウェア Vidar Stealerは2018年末から活動を続ける老舗のマルウェアだ。MaaS（Malware-as-a-Service）モデルで提供されており、技術力のない攻撃者でも容易に利用できる。標的にするデータは幅広い： ブラウザのパスワード・Cookie・オートフィル情報 暗号資産ウォレット（MetaMaskなど） システム情報全般 近年では機能強化版もリリースされており、感染後に実行ファイルを自己削除してメモリ上でのみ動作するなど、フォレンジック調査を困難にする機能が追加されている。 さらに厄介なのがC2（コマンド＆コントロール）通信の手法だ。TelegramボットやSteamのプロフィールページなどの公開サービスを「デッドドロップ（dead-drop）」として悪用し、攻撃者の本当のC2サーバーアドレスを取得する仕組みになっている。一般的なファイアウォールでは公開サービスへのアクセスを遮断しにくいため、この手口は検知を大幅に難しくする。 今すぐ確認すべき具体的な対策 ACSCは以下の対策を推奨しており、日本の組織にも直接適用できる。 PowerShell実行ポリシーの制限 PowerShellの実行ポリシーを AllSigned または RemoteSigned に設定し、署名のないスクリプトの実行をブロックする。一般ユーザーに不必要なPowerShell実行権限を与えないことが重要だ。グループポリシーで組織全体に適用することを推奨する。 アプリケーション許可リストの導入 Windows Defender Application Control（WDAC）やAppLockerを活用し、許可されていないアプリケーション・スクリプトの実行を防ぐ。完璧な許可リストの構築は工数がかかるが、まずPowerShellの制限だけでもClickFix攻撃の大部分を防げる。 WordPressサイト管理者向け対策 テーマとプラグインを最新バージョンに即時更新 使用していないテーマ・プラグインは即刻削除 ファイル変更の監視ログを有効化し、定期的にレビュー IoC（侵害指標）の確認 ACSCの公式アドバイザリにはIoCが掲載されている。SIEMやEDRにルールを追加し、既存の侵害がないか確認することを強く勧める。 実務への影響 ClickFix攻撃は2024年末から急増しており、日本でも同様の手法による攻撃が報告されている。特に懸念されるのは次の3点だ。 エンドユーザー教育だけでは防げない: 「怪しいリンクを踏むな」的なセキュリティ教育だけでは防ぎきれない。偽CAPTCHAは非常に本物に近く、「確認のためにコマンドを実行する」という操作自体が不自然に感じられない状況が作られている。技術的な制御との組み合わせが必須だ。 侵害WordPressサイトの連鎖リスク: 自社が直接攻撃されるのではなく、取引先や業界関連サイトが踏み台にされるケースが多い。自社WordPressサイトのセキュリティ強化は、自社だけでなくサプライチェーン全体の防御に繋がる。 テレワーク環境でのリスク増大: 社内ネットワーク外で業務するユーザーが増えた現在、エンドポイント保護とゼロトラストアーキテクチャの整備がますます重要になっている。VPNに依存した境界防御型の構成では、エンドポイントが侵害された後の横展開を止める手段が乏しい。 筆者の見解 ClickFix攻撃が厄介なのは、技術的な脆弱性ではなく「人間のクセ」を突いてくる点だ。「確認のためにこのコマンドを実行してください」という指示に、ユーザーは悪意なく従ってしまう。これは教育でカバーするには限界がある。 PowerShell実行の制限やアプリケーション制御は、管理者にとって実装の手間が伴う対策だ。特にIT環境が成熟していない組織では「今動いているからとりあえず」の運用が続きがちで、このような技術的制御が後回しにされる現実がある。 しかしVidar Stealerが奪うのは「ブラウザに保存されたパスワード全件」だ。業務システムのアクセス情報、クラウドサービスのセッションCookie、サービスアカウントの認証情報が一度に漏れる可能性を考えると、その被害は組織の機能停止レベルに達しうる。Non-Human Identity（NHI）管理の観点でも、サービスアカウントの認証情報が盗まれた場合の影響範囲は通常の人間アカウントより広くなりやすい。 ACSCのアドバイザリは、今週中にでもPowerShell実行ポリシーの現状設定を確認する動機として十分だ。完璧なゼロトラスト環境の構築は長期目標でいいが、「まず手軽にできる一手」から始めることが現実的で効果的な防御策になる。 出典: この記事は Australia warns of ClickFix attacks pushing Vidar Stealer malware の内容をもとに、筆者の見解を加えて独自に執筆したものです。

SentinelLabsが2026年5月に公開したレポートで、「PCPJack」と名付けられた新たなマルウェアフレームワークの存在が明らかになった。このワームは外部に露出したDocker・Kubernetes・Redis・MongoDB・RayMLなどのクラウドインフラを標的に侵入し、OpenAIやAnthropicのAPIキー、SSHキー、Slackトークンなど多数の認証情報を窃取する。その上、競合するクラウド脅威グループ「TeamPCP」の痕跡を完全消去しながら自らの勢力を拡大するという異例の動作が確認されている。 PCPJackとは何か PCPJackは、Linuxベースのクラウドシステムを標的とするマルウェアフレームワークだ。SentinelLabsの調査によると、TeamPCPの元アフィリエイトまたはメンバーが独自オペレーションを立ち上げた可能性が高いとされている。 TeamPCPは、AquaセキュリティのTrivyスキャナーやLiteLMM・Telnyx・SAPのnpmパッケージへのサプライチェーン攻撃で知られるクラウド特化型の脅威グループだ。PCPJackはTeamPCPの初期キャンペーン（2025年12月）と類似した手口を使うことから、この関連性が推測されている。 感染経路と動作機構 PCPJackはLinuxシステムに対し、シェルスクリプト「bootstrap.sh」を実行することで感染を開始する。主な動作フローは以下のとおりだ： 初期侵入: Docker・Kubernetes・Redis・MongoDB・RayMLなどの露出したサービスをスキャンし、既知の脆弱性を悪用してアクセスを取得 TeamPCP排除: 侵入直後、競合するTeamPCPのプロセス・サービス・コンテナ・ファイル・永続化アーティファクトをすべて削除 環境構築: 隠しワーキングディレクトリの作成、Pythonモジュールのダウンロード、メインオーケストレーター（monitor.py）の起動 認証情報窃取: クラウド環境・開発者システム・メッセンジャー・金融サービス等から認証情報を収集 横展開: SSHキーとクレデンシャルを使ってネットワーク内の他ホストへ侵入 永続化: systemdサービス、cronジョブ、Redis cronリライト、特権コンテナを利用 窃取した認証情報は、X25519 ECDH + ChaCha20-Poly1305で暗号化された後、2,800バイト単位に分割されてTelegramチャンネルへ送信される。 標的となる認証情報・サービス PCPJackが狙う認証情報の範囲は広い： クラウドAPI: OpenAI APIキー、Anthropic APIキー、DigitalOceanトークン 開発者ツール: SSHキー、GitHubトークン、Slackトークン データベース: MongoDB、Redis Webサービス: WordPress設定ファイル、Discord インフラ: Kubernetes設定、Dockerデーモン情報 悪用される脆弱性（CVE） PCPJackが利用する脆弱性は以下のとおり： CVE 対象 内容 CVE-2025-29927 Next.js ミドルウェアの認証バイパス CVE-2025-55182 React / Next.js Server Actionsのデシリアライゼーション欠陥 CVE-2026-1357 WPVivid Backup 未認証ファイルアップロード CVE-2025-9501 W3 Total Cache mfuncコメント経由のPHPインジェクション CVE-2025-48703 CentOS Web Panel Filemanagerのシェルインジェクション 実務への影響：日本のエンジニア・IT管理者が取るべき行動 即座に確認すべき事項 1. クラウドサービスの露出状況を確認する Docker APIポート（2375/2376）、Redis（6379）、MongoDB（27017）、Kubernetes API（6443）が外部に開放されていないか今すぐ確認する。セキュリティグループやファイアウォールルールを見直すこと。 ...

Microsoftが公式に公開したWindows 11のレジストリ設定を使うことで、Google ChromeとMicrosoft Edgeがユーザーに通知なくバックグラウンドで自動ダウンロードする約4GBのオンデバイスAIモデルを、IT管理者がブロックできるようになった。 ChromeとEdgeが「ひっそり」4GBをダウンロードしている実態 Googleはここ数年、Chrome内に「Gemini Nano」と呼ばれるオンデバイスの大規模言語モデル（LLM）を統合する取り組みを進めてきた。要約生成、文章作成支援、スマートリプライといったChrome組み込みのAI機能を支えるモデルで、クラウドではなくローカルで動作するのが特徴だ。Microsoft Edgeでも同様の動作が確認されている。 問題は、このモデルのサイズが約4GBに達しており、ユーザーへの明示的な通知なしにバックグラウンドで自動ダウンロードが実行される点にある。一般ユーザーはほとんど気づかない一方で、IT管理者の間からはストレージ消費・帯域幅使用・データポリシー整合性の観点から懸念の声が上がっていた。 公式レジストリ設定による制御 Microsoftはこの状況に対応し、Windows 11向けの公式レジストリ設定を提供した。ChromeやEdgeのエンタープライズポリシーに対応するレジストリキーを設定することで、大容量AIモデルの自動ダウンロードをブロックできる。 グループポリシーオブジェクト（GPO）またはMicrosoft Intuneを使った展開にも対応しており、企業全体のデバイスへの一括適用が可能だ。個別PCへのレジストリ直接編集だけでなく、既存のデバイス管理基盤から標準的な手順で制御できるのは実務上の大きなメリットとなる。 なぜこれが日本のIT現場で重要か 日本の企業環境では、以下の場面でこの設定が特に有効だ。 帯域幅の管理: 地方拠点や海外拠点など回線が細い環境、あるいはVDI・RDS環境では、端末1台あたり4GBのバックグラウンドダウンロードが積み重なると業務通信に支障をきたす可能性がある。特に大規模展開時は見えないところで相当な帯域を消費していることになる。 ストレージと資産管理: 標準構成PCのSSDが128〜256GB程度の組織では、予告なく消費される4GBはディスク管理とインベントリ管理の双方に影響する。 コンプライアンスとデータポリシー: オンデバイスとはいえ、透明性の不十分な状態でのモデルダウンロードは、社内情報セキュリティポリシーの審査対象になりうる。特に金融・医療・公共セクターでは、AI処理の透明性要件が厳しくなりつつある。 Intune経由でポリシーを展開できれば、IT部門が追加工数をかけずに全社員端末への制御適用が可能だ。 筆者の見解 「ブラウザが4GBのモデルをひっそりダウンロードしていた」という事実は、IT管理者の立場からすると看過できない。帯域幅・ストレージ・データポリシーのすべてにおいて問題をはらんでいる。 ただし、ここで大切なのは「禁止するかどうか」より「制御できるかどうか」という視点だ。禁止を強行しても、ユーザーは個人端末や別の手段を使い始め、むしろシャドーIT化が進む。IT部門が公式の制御手段を持ち、「管理された状態でAI機能を使える環境」を整えることが本筋だろう。 MicrosoftとGoogleが公式のポリシー設定を提供したこと自体は、エンタープライズ管理の観点から正しい方向だ。IT管理者としては、この設定を把握した上で、禁止一辺倒ではなく組織のニーズに合わせた適切な判断をしてほしい。「使わせない」ではなく「安全に使える仕組みを作る」——その姿勢が、AIが当たり前になったこれからの時代の基本スタンスになる。 出典: この記事は Official Windows 11 Registry mod blocks automatic download of 4GB AI model on Google Chrome の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Googleが数週間前から予告していたスクリーンレスフィットネスバンド「Fitbit Air」を正式発表した。Whoop対抗を明確に意識した製品で、同時にサブスクリプションサービス「Fitbit Premium」と「Health Coach」のブランド刷新も行われた。 Fitbit Airとは何か Fitbit Airは、従来のスマートウォッチとは一線を画す「スクリーンレス」設計のフィットネスバンドだ。画面を持たないことでバッテリー持続時間の延長と装着感の改善を実現し、24時間常時装着を前提としたデバイスとして設計されている。 競合として意識されているのは、米国のフィットネスウェアラブル市場で急成長を続ける「Whoop」だ。Whoopは同様にスクリーンを持たず、睡眠・回復・ストレインのトラッキングに特化したサブスクリプション型デバイスとして知られる。Fitbit AirはこのWhoopが切り開いた「スクリーンレス・サブスク型ウェアラブル」市場に、Googleブランドと既存のFitbitエコシステムを武器に参入する格好だ。 Fitbit Premium / Health Coachのブランド刷新 今回の発表と同時に、Googleはサブスクリプションサービスの名称を整理した。「Fitbit Premium」と「Health Coach」という2つのブランドが統合・リブランドされる。詳細なサービス内容の差異は今後明らかになるが、ユーザーにとっては利用中のサービス名称が変わる可能性があるため、設定画面やアプリの通知に注意が必要だ。 なぜこれが重要か ウェアラブルデバイス市場は「何でもできるスマートウォッチ」と「特定用途に特化した専門デバイス」の二極化が進んでいる。Apple WatchやGalaxy Watchがあらゆる機能を詰め込む方向性を取る中、WhoopやOura Ringのような「ミニマリスト型ウェアラブル」が特にヘルスコンシャスなユーザー層から支持を集めてきた。 Googleにとっては、Fitbitを2021年に買収して以来の製品戦略の転換点とも言える。これまでFitbitはスクリーン付きのトラッカーやスマートウォッチに注力してきたが、Fitbit Airによってより広いユーザー層——特に「健康管理はしたいが、スマートウォッチほど高機能なものはいらない」という層——へのアプローチが可能になる。 実務への影響 日本市場での展開に注目 Fitbit Airの日本展開時期・価格はまだ不明だが、競合のWhoopが日本市場でも存在感を持ちつつあることを考えると、Googleブランドの参入は市場を活性化する可能性がある。 IT管理者・企業担当者へのポイント ウェアラブルデバイスを従業員の健康管理プログラムや健保組合の取り組みに組み込んでいる企業では、今後のFitbit Premium（新ブランド）のプランや機能変更を確認しておくことを推奨する。特にGoogle Workspaceとの連携機能が拡充される可能性があり、企業向け健康管理ソリューションとしての活用余地が広がるかもしれない。 デバイス管理の観点 スクリーンレスデバイスはMDM（Mobile Device Management）の管理対象にはなりにくいが、収集する健康データのプライバシーポリシーと、Google/FitbitアカウントへのデータSyncについては、企業利用前にポリシー確認が必要だ。GDPRや個人情報保護法の観点からも、健康データの取り扱いは慎重に検討したい。 筆者の見解 健康トラッキングの文脈で面白いのは、「画面をなくす」という逆張りの設計思想だ。スマートフォン依存が問題視される中、通知を受け取らず、チェックしたくなる画面もない——これは単なる機能削減ではなく、デバイスとの付き合い方を根本的に見直した提案とも取れる。 Googleのウェアラブル戦略は、Fitbit買収後も一貫性が見えにくかった印象がある。しかしFitbit Airは、明確なターゲット（Whoopユーザー層）と明確なコンセプト（スクリーンレス・健康特化）を持つ製品として、久しぶりに「方向性のある製品」に映る。 筆者が注目するのは、GoogleのAI基盤がこのデバイスにどう統合されるかだ。単なるセンサー機器に留まるか、Googleの健康AI戦略のフロントエンドとなるかで、製品の評価は大きく変わる。サブスクリプションサービスの中身次第で、Whoopとの差別化軸が決まるだろう。「道のド真ん中を歩く」設計思想で言えば、過度な多機能化を避けてヘルストラッキング一本で勝負するこの方向性は、ある意味で正しいアプローチだと感じている。 出典: この記事は Google rebrands Fitbit Premium and Health Coach as it launches new Fitbit Air の内容をもとに、筆者の見解を加えて独自に執筆したものです。

翻訳サービス大手のDeepLが、100人以上の従業員を解雇し、「AIネイティブ企業」への転換を正式に発表した。Google翻訳の有力対抗馬として知名度を高めてきたDeepLが、自社の中核技術であるAIによって内部の人員を削減するという、皮肉とも取れる構造転換が現実となった。 DeepLとは——翻訳品質で差別化してきた技術企業 DeepLはドイツ・ケルンを拠点とする翻訳テクノロジー企業で、2017年のサービス開始以来、欧州語を中心とした高品質な機械翻訳で支持を集めてきた。特にビジネス文書や技術文書の翻訳精度は長年評価が高く、企業の多言語対応ツールとして日本国内でも広く採用されている。 2023年以降、大規模言語モデル（LLM）の台頭により翻訳市場全体が激変。OpenAIのGPT-4やGeminiなどのモデルが翻訳タスクでも実用水準に達したことで、専業翻訳AIとして戦うDeepLの立ち位置は大きく変わった。 「AIネイティブ」への転換とは何を意味するか 「AIネイティブ企業」への移行とは、単にAIツールを導入するということではなく、組織の意思決定・業務プロセス・人員構成そのものをAI前提で再設計することを意味する。 今回の100人超の解雇は、従来は人間が担っていた業務——品質保証、コンテンツレビュー、翻訳評価、一部のプロダクト運営——がAIに置き換えられたことの直接的な結果とみられる。 DeepLのような翻訳専業企業でさえ社内業務の相当部分をAIに移管できるとすれば、翻訳以外の産業においても、同様の構造変化は時間の問題と言える。 日本のIT現場への影響——「対岸の火事」ではない 日本でも法人向けにDeepL Proを導入している企業は多い。今回の動きがサービス内容を直接変えるわけではないが、より大きな問いを突きつけている。 影響を受けやすいポジション： 翻訳・ローカライズ担当者（社内外） コンテンツレビュー・QAチーム 多言語対応のカスタマーサポート 技術文書の多言語化を担う部門 実務での活用ポイント DeepL APIを利用している開発者・IT管理者は以下の点を今のうちに整理しておきたい。 1. サービス動向の注視 AIネイティブ化に伴いAPIの仕様・価格体系が変わる可能性がある。依存度の高い企業は変更通知の受け取り設定を確認しておこう。 2. 冗長構成への移行検討 DeepL単体に依存した多言語パイプラインは脆弱性になりうる。複数のLLM APIと組み合わせた構成を検討する時期だ。 3. 「人間-AI協働モデル」の方針を明文化する AI翻訳の出力をどのレベルまで人間がレビューするか、組織としての方針を曖昧なままにしない。判断の基準がないまま削減を進めると、品質管理がブラックボックス化する。 筆者の見解 DeepLという翻訳AIの会社が、自分たちが開発したAI技術によって社内の人員を削減する——この構造は、今後あらゆる業種で繰り返されるパターンの先行事例として記憶されるだろう。 仕組みを作れる少数の人間と、それを回すAIで組織は成立する時代になった。これは極論でも未来の話でもなく、今まさに起きていることだ。問題は、日本企業の多くがこの変化の速度を過小評価していることにある。「AIを使ってみよう」という段階の話ではなく、「人員構成そのものをAI前提で見直す」という意思決定が問われている。DeepLが今回示したのはその覚悟の一例だ。 ただし、すべてをAIに任せれば良いという単純な話でもない。AIの出力を評価・監査できる人材が組織内にゼロになった瞬間、品質管理はブラックボックスになる。最後の砦として人間の判断を残す設計——この視点を持たずにAIネイティブ化だけを進めると、後に高くつく失敗を招く可能性がある。 変化は止まらない。だが「何をAIに任せ、何を人間が担うか」を設計できる組織だけが、この転換を本当の意味で乗り越えられる。 出典: この記事は AI just took the jobs of over 100 people at DeepL の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがWindows 11に対し、CPUをより積極的に活用することで特定のシナリオにおける大幅なパフォーマンス向上を実現する改善を計画していると、Neowinが報じた。現行のスケジューラーが持つ「省電力寄り」の挙動を見直し、処理要求が高いシーンでCPUに「もっと働かせる」方向にチューニングするという内容だ。 CPUを「遠慮なく使う」方向へ 現行のWindowsは、電力消費やサーマル管理のバランスを取るため、CPUがフル性能を発揮するタイミングをある程度制限する設計になっている。特にノートPCや省電力設定では、本来の性能が十分に引き出されないケースがある。 今回の改善は、こうした「遠慮」を特定のシナリオに限って取り払い、CPUに積極的に高負荷で動作させることで、レスポンスタイムやスループットを向上させるアプローチだ。 現代のPCに搭載されるCPUは、IntelのPコア（パフォーマンスコア）＋Eコア（効率コア）のハイブリッド構成や、AMDの3D V-Cacheのように、アーキテクチャが複雑化している。Windows 11のスケジューラーはこれらに対応したHMP（Heterogeneous Multi-Processing）機構を持っているが、どのタスクをどのコアに割り当て、どのタイミングでブーストクロックを許可するかの判断ロジックには、まだ改善余地がある。 影響を受けるシナリオ 「特定のシナリオ」という表現が使われており、常時フルパワー動作になるわけではない点は重要だ。ゲームやクリエイティブ作業など、低レイテンシーや高スループットが求められる場面で、より素早くブースト状態に遷移させることが主な改善になると考えられる。 日常的な軽作業（ブラウジング、文書作成）への影響は限定的だろう。むしろ、恩恵を感じやすいのは以下のような場面だ： ゲームの初期ロードやシーン切り替え: CPUが素早く高クロックに達することでカクつきが減少 動画エンコードや圧縮処理: スループットが向上し処理時間が短縮 開発環境でのビルド・コンパイル: 並列処理の効率が上がりビルド時間が短縮 仮想化（Hyper-V、WSL2）: ホストOSのCPU管理が改善されることでゲストの応答性が向上 実務への影響 IT管理者・エンジニアの視点で注意すべき点がいくつかある。 電力・発熱の変化を確認する: CPUをより積極的に動かすということは、発熱と消費電力も増加しうる。特にノートPCや小型ファームウェアの開発機では、サーマルスロットリング（過熱による性能低下）が新たなボトルネックになる可能性がある。アップデート適用後は温度モニタリングツール（HWiNFO64等）で実測することを推奨する。 仮想環境・バッチ処理の再ベンチマークを: WindowsをホストとするHyper-V環境や、スケジュールされたバッチ処理は、CPU割り当てとスレッドスケジューリングの変化を受けやすい。本番適用前にステージング環境での検証を行うのが安全だ。 グループポリシーでの電力プラン管理: 企業環境でBitLocker・Intuneと組み合わせて電力プランを「バランス」に固定しているケースでは、このチューニングが期待どおりに効かない場合もある。Windows Updateのリリースノートを注意して読み、適用範囲を確認する。 筆者の見解 Windowsのパフォーマンスチューニングはここ数年、地味ながら着実に進んでいる領域だ。HETP（ハイブリッドコア最適化）の導入、Thread Directorとの連携改善など、ハードウェアの進化に追いつくための取り組みは継続的に行われてきた。今回の報告もその延長線上にある。 ユーザーが体感できるレベルのパフォーマンス改善は、Windowsの価値を支える基本中の基本だ。機能追加ばかりが目立つアップデートが多い中で、「動作が速くなった」と感じられる改善はむしろ歓迎したい。 一点気になるのは、「特定のシナリオ」の定義がまだ不明確な点だ。MicrosoftにはWindowsが動作する多様な環境——ハイエンドゲーミングPCから企業の10年選手ノートPCまで——を考慮した上で、このチューニングがどの構成で何を優先するのかを明確に開示してほしい。こういった変更は、仕組みがわかっているエンジニアには朗報でも、管理者が把握しないまま適用されると現場で混乱を生む。 Windowsにはまだこうした「地力を出せる」余白が残っている。その力を正しく引き出す方向での開発が続くことを期待したい。 出典: この記事は Microsoft is giving Windows 11 major performance upgrade by making CPUs work harder の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MozillaがFirefox 150系の累積バグ修正アップデート「Firefox 150.0.2」を公開した。Webカメラの接続・認識障害、PDFビューアの表示バグ、Split View機能の不具合など、複数の実用上の問題が解消されている。 今回の修正内容 Firefox 150.0.2はメジャーアップデートではなく、150系ブランチへの累積パッチリリースだ。公開情報によれば、主な修正対象は次の通りとなっている。 Webカメラの認識・接続問題: ビデオ会議ツールやブラウザベースのカメラアプリでWebカメラが正常に動作しないケースへの対応 PDFビューアのバグ: ブラウザ内蔵のPDFレンダリングエンジンで発生していた表示・操作上の不具合を修正 Split View機能: 画面を分割してタブを並べて表示する機能で起きていた問題を解消 これ以外にも複数の細かいバグフィックスが含まれているとされており、安定性全般の向上が図られている。 なぜ今このタイミングで重要か WebカメラとPDFビューアの修正は、業務利用において無視できないポイントだ。 リモートワークの普及により、ブラウザからビデオ会議ツール（Google Meet、Teams Web版など）を直接利用するシーンが増えている。Webカメラが正常に機能しなければ会議に参加できない、という業務停止レベルの問題になりかねない。 また、PDFのブラウザ内表示はAdobe Readerを組織端末にインストールしないポリシーを取る企業でも広く使われており、官公庁や金融機関の帳票閲覧でFirefoxのPDFビューアを活用しているケースも少なくない。これらの環境でバグが出ていた場合は早めのアップデートが推奨される。 実務での活用ポイント 個人ユーザー・開発者向け Firefoxを標準ブラウザとして使用しており、最近Webカメラが認識されない・PDFの表示がおかしいと感じていた場合、まずバージョンを確認してほしい。about:support またはメニュー「ヘルプ → Firefoxについて」から現在のバージョンが確認できる。150.0.2に更新するだけで解決する可能性が高い。 IT管理者・企業展開向け 組織端末にFirefoxをグループポリシーやMDMで配布している場合、150.0.2のパッケージをテスト環境で検証の上、展開計画を前倒しにすることを検討したい。特にWebカメラを使うユーザー部門や、PDFを日常的に扱う部門ではバグの影響が出やすい。 Mozillaは公式のEnterprise ReleasesチャンネルでESR版も提供しており、変更を安定させたい組織はESRトラックの採用も一つの選択肢だ。 筆者の見解 Firefoxのような成熟したブラウザのパッチリリースは、何か派手な新機能があるわけではないが、実際の業務に直結するバグが修正されるという意味で軽視できない。 Windowsのアップデートを「すぐ当てるか数日様子を見るか」で悩む感覚に似ているが、今回のFirefox 150.0.2はWebカメラとPDF対応という実害が出やすいバグへの対応なので、業務用途では比較的早めに展開して損のないリリースだと思う。 ブラウザはOSと同様に「インフラ」になっている。細かいバグ修正を追いかけることより、安定した状態を保つ仕組みを作る方が本質的な管理だ。自動更新を許可するポリシーを組織内で整えていれば、こうしたパッチは自動的に適用されて問題にならない。その整備コストが結局一番安上がりである。 出典: この記事は Mozilla releases Firefox 150.0.2 with fixes for webcams, PDF viewer, and more の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Googleが、1億人以上が利用する人気健康アプリを含む2本のアプリを終了し、ヘルスケア機能をHealth Connectプラットフォームへ集約すると発表した。 何が起きているのか Googleは自社のヘルスケア関連アプリ群を「統合」する方針を明らかにし、複数の人気アプリを段階的に終了することを告知した。対象アプリの一つであるGoogle Fitは、Android・iOS向けに長年提供されてきたフィットネストラッキングアプリで、歩数・心拍数・アクティビティ履歴などを一元管理できる機能が人気を集め、累計1億件以上のダウンロードを誇っていた。 Googleは今回の決定について「ヘルスケア体験の集約と改善」を目的としており、今後はAndroid組み込みのHealth Connectをヘルスデータの中核プラットフォームとして位置づける方針だ。Health ConnectはAndroid 14以降で標準搭載されており、各種フィットネスアプリとのデータ共有APIとして機能する。 なぜこれが重要か データの継続性という問題 健康データは日々の積み重ねに意味がある。体重・睡眠・運動履歴を数年分蓄積してきたユーザーにとって、アプリ終了はそのデータが消えるリスクを意味する。Googleはデータエクスポート手段を提供するとしているが、移行先アプリでそのデータが同様に活用できるかは保証されていない。 Googleのアプリ終了パターンへの不信感 Googleはこれまでも、Google Reader・Inbox by Gmail・Stadia・Google+など多くの人気サービスを終了してきた歴史がある。今回の発表も「またか」と受け取るユーザーが少なくないのは想像に難くない。特に健康データという個人の重要情報を預けていたユーザーの心理的ダメージは大きい。 実務への影響——エンジニア・IT管理者の視点 1. 代替アプリの選定を急ぐ Google Fitのデータ移行先として、Samsung Health・Garmin Connect・Withings Health Mate・Apple Healthなどが候補に挙がる。Health Connect対応のアプリであれば、Androidのデータハブ経由でシームレスに連携できる可能性が高い。 2. Health Connect APIへの移行確認 フィットネス関連アプリの開発者は、Google Fit SDKを使っている場合は早急にHealth Connect APIへの移行計画を立てる必要がある。Googleは既にHealth Connect APIへの移行を推奨しており、Google Fit APIは非推奨（deprecated）扱いとなっている。 3. データエクスポートを早めに実行 Google Fitのデータは「Google Takeout（takeout.google.com）」からエクスポート可能。アプリが正式終了する前に必ずバックアップを取得しておくことを強く推奨する。形式はJSON・TCX・GPXで出力される。 4. 企業のウェルネスプログラムへの影響 法人向けのウェルネスプログラムでGoogle Fitを活用している企業は、代替手段の検討が急務となる。Health Connect対応の企業向けウェルネスソリューションへの移行を検討したい。 筆者の見解 Googleが「統合による改善」を掲げるとき、ユーザーが感じるのは利便性の向上よりも「また慣れたサービスが消える」という疲弊感ではないだろうか。 Health ConnectはAndroid標準のヘルスデータ基盤として理にかなったアーキテクチャだ。分散していた健康データを一つのAPIで管理できるというビジョンは正しい。問題は、その方向性が正しいとしても、1億人超が日々使っていたアプリを終了するという決断の重さを、Googleが十分に受け止めているように見えないことだ。 Microsoftが似た状況でAzure Health Data Servicesを積み重ねてきたアプローチと比較するつもりはないが、「統合」という言葉が「切り捨て」の婉曲表現にならないよう、Googleには丁寧な移行サポートを期待したい。 技術者の立場から言えば、特定ベンダーのエコシステムに健康データを全面依存することのリスクが、改めて可視化された出来事だ。Health ConnectのオープンAPIを通じた相互運用性こそが、長期的にユーザーを守る鍵になる。 出典: この記事は Google is killing this very popular app used by more than 100 million people の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Ars TechnicaのAndrew Cunningham記者が2026年6月9日にカリフォルニア州クパチーノから報じたところによると、AppleはWWDC 2026において「Siri AI」がGoogleのGemini言語モデルをベースに動作することを正式発表した。さらに処理の一部がGoogleサーバー上のNvidiaハードウェアで実行されることも明らかになった。それでもAppleは従来と変わらぬプライバシー保護を約束しており、その技術的な根拠をCraig Federighi氏がプレス向けに詳細説明した。 なぜこの発表が注目されるのか Appleはこれまで「プライバシーはApple製品の根幹」として競合との差別化を図ってきた。機密データはデバイス上で処理し、クラウド処理はAppleが管理するサーバーに限定する「Private Cloud Compute」アーキテクチャがその柱だった。 しかしArs Technicaが指摘するように、iPhoneやMac上でローカル実行できる言語モデルにはどうしても能力の上限がある。大規模な推論やエージェント処理をこなすには外部クラウドのリソースが不可欠であり、大規模データセンター投資を避けてきたAppleにとって、Googleとの提携は現実的な解だった。 Ars Technicaが報じたアーキテクチャの詳細 Federighi氏はWWDCのプレス向けセッションで「我々が使っているGoogle Assistantの量はゼロだ」と述べ、Googleのサービスを利用しているわけではなく、あくまでGoogleのインフラ上でApple独自のモデルを実行していると説明した。 モデル構成 オンデバイスモデル AFM 3 Core：Apple/Google共同開発のGeminiベース新モデル。Apple Intelligence対応デバイスに搭載され、簡単なクエリを処理 AFM 3 Core Advanced：RAM 12GB以上かつM3以降のMac・M4以降のiPad・A19 Pro搭載iPhone（iPhone 16 Pro系）限定。ディクテーション精度の向上とSiriの表現豊かな音声に活用 クラウドモデル（Googleサーバー上で動作） AFM 3 Cloud：汎用クラウドモデル ADM 3 Cloud：画像生成モデル AFM 3 Cloud Pro：エージェント的ツール使用・複雑な推論向け高性能モデル Ars Technicaの報道によると、AFM 3 CloudとADM 3 Cloudの2つはGoogleのサーバー上でもAppleシリコンで動作するとされており、Private Cloud Computeの暗号化・隔離アーキテクチャをGoogleのデータセンターに「持ち出す」形を取っているという。 日本市場での注目点 対応デバイスの条件が明確化 Siri AIの高度な機能（AFM 3 Core Advanced）が利用できるデバイスは以下に限定される： Mac：M3チップ以降（MacBook Pro M3、Mac mini M4など） iPad：M4チップ以降（iPad Pro M4、iPad Air M3は対象外の可能性） iPhone：A19 Pro搭載モデル（iPhone 16 Pro / iPhone 16 Pro Max） 日本で購入できる現行モデルの多くが対象に入るが、iPhone 16の無印・Plusモデルは高度機能の対象外となる点は注意が必要だ。 ...

Linuxカーネルに、たった1文字の感嘆符（!）が原因で引き起こされる高深刻度の脆弱性が発見された。Ars TechnicaのシニアセキュリティエディターDan Goodin氏が2026年6月9日に報告したこの問題はCVE-2026-23111として追跡されており、未権限ユーザーがroot権限へ昇格できる。修正パッチは既に配布済みだが、PoC exploitも公開されており、未適用環境のリスクは現実的な脅威となっている。 1文字のバグが生んだuse-after-free 問題の舞台は nf_tables——Linuxカーネルのパケットフィルタリングサブシステムで、従来の iptables や ip6tables を置き換えるファイアウォール管理の中核コンポーネントだ。 Ars Technicaの報道によると、nf_tables を実装するコードの中に誤った感嘆符（!）が1つ混入。これがuse-after-free脆弱性の直接の原因となった。use-after-freeとは、既に解放されるべきメモリアドレスに悪意あるコードを配置するメモリ破損の一種で、権限昇格や任意コード実行につながる深刻なクラスの脆弱性だ。 攻撃の仕組み——verdict削除処理の悪用 攻撃は nf_tables フレームワーク内の「verdict（判定）」削除処理を妨害することで成立する。verdictとはパケットがルールに一致したかどうかを決定する処理で、他の要素に一致しなかった際のワイルドカードとして catchall 要素を使用する。 verdict mapがメモリから削除される際、catchall要素が非活性化され、チェーンの参照カウンタがデクリメントされる。エラー発生時は削除が取り消されカウンタが再インクリメントされるが、CVE-2026-23111はこのプロセスを悪用してカウンタを任意回数デクリメントし、他のオブジェクトがまだ参照している状態でチェーンを削除・解放させることができる。 セキュリティ研究者の評価 Ars Technicaの報道によれば、脆弱性を発見したセキュリティ企業Exodus Intelligenceが技術ブログとPoC（概念実証コード）を公開。同社は「誤った感嘆符1つがuse-after-free脆弱性を生み、未権限ユーザーがDebian・UbuntuでrootへのPrivilege Escalationが可能になる。カーネルベースアドレスのリーク、ヒープアドレスのリーク、制御フロー乗っ取りと複数回の脆弱性トリガーが必要だが、アイドル状態のシステムで99%超の安定性を記録した」と評価している。 またセキュリティ企業FuzzingLabsは2026年4月時点でPoC exploitを実証済みだ。Ars Technicaは、CVE-2026-23111が最近Linuxを直撃した権限昇格脆弱性の少なくとも3件のうちの1つであると指摘。単独でも深刻だが、別のエクスプロイトと連鎖させることでOSのサンドボックス防御を回避できる点を特に警告している。 修正状況: パッチは2026年2月にLinuxカーネルへマージ済み。その後、主要Linuxディストリビューションへのバックポートも完了している。 日本市場での注目点 日本国内でも多くの企業・組織がDebian系やRHEL系Linuxをサーバー・クラウド環境で運用している。本脆弱性の影響確認ポイントを整理する。 優先確認が必要な環境 Ubuntu（LTS含む）、Debian nf_tablesを有効化したその他のLinuxディストリビューション クラウド上のカスタムAMI・イメージ（AWS/Azure/GCP問わず） コンテナホスト（コンテナはホストカーネルを共有するため、ホスト側のパッチ適用が必須） 確認コマンド例 出典: この記事は High-severity vulnerability in Linux caused by a single faulty character の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米海軍第5艦隊のTask Force 59が運用するSaronic Technologies製自律型無人水上艦（USV）「Corsair」が、2026年6月8日にオマーン沖で墜落した米陸軍AH-64アパッチヘリコプターの乗員2名を救助した。Ars Technica、New York Times、CBS News、ABC Newsが相次いで報じたこの出来事は、無人ドローンが海上で人命救助に直接貢献した世界初の事例として、防衛・テクノロジー双方の観点から注目を集めている。 なぜこの出来事が注目されるのか 海上での人命救助は、これまで有人艦艇やヘリコプターが担ってきた領域だ。有人機の到達が困難な状況でも、小型・高速な無人艦艇ならより迅速に現場へ向かえる可能性がある。今回の事例は、自律型USVが危険な実戦環境での人命救助という高度なミッションを完遂できることを初めて実証した歴史的な一歩となった。 Task Force 59は、無人航空機・無人水上艦・無人水中艦とAIを米海軍第5艦隊の海洋作戦に統合することを専門とする部隊で、Corsairの現地展開は2026年3月に開始されたばかり。展開から約3ヶ月での「実戦デビュー」となった。 Corsairのスペックと自律性能 Corsairはテキサス州オースティンを拠点とする防衛スタートアップ、Saronic Technologiesが開発した自律型水上艦艇だ。 項目 仕様 全長 約7.3m（24フィート） 最大積載量 約454kg（1,000ポンド） 航続距離 1,000海里以上 最高速度 34ノット超（約63km/h） Saronic社の説明によれば、Corsairは波高1.5m超の荒天下でも自律航行を継続でき、エンジンを停止したまま位置を維持する「自律ロイター」能力を備える。2026年1月には8隻のCorsairが92時間以上にわたって通信遮断環境で自律ミッションをこなす演習も実施された。陸上基地からのオペレーターによる監視・操作も可能な設計で、完全無人化と有人監視の組み合わせによる運用を想定している。 海外報道が伝える救助の経緯と評価ポイント Ars Technicaの報道によると、救助の流れは以下の通りだ。 6月8日午後7時33分（米東部時間）、アメリカ軍がパイロット2名の救助を完了 Task Force 59のCorsairが乗員を水中から収容し、待機ヘリコプターへの移送ポイントまで搬送 米海軍Tim Hawkins大佐（米中央軍広報）が正式声明でCorsairの関与を確認 New York Timesがこの件を最初に報じ、CBS NewsとABC Newsもそれぞれ匿名の軍関係者の情報として「ドローンによる世界初の海上人命救助」と報じている。一方、アパッチ墜落の原因については米軍は詳細を公表しておらず、不明な点が多い。 複数メディアの報道を通じて評価されているのは、有人救助が困難な状況下での迅速な対応と、通信が不安定な環境でも機能する自律性の2点だ。 日本の防衛・海洋安全保障関係者への注目点 日本は周囲を海に囲まれた島国で、海上での人命救助は海上自衛隊・海上保安庁の重要任務の一つだ。今回の事例はいくつかの点で示唆に富む。 広大なEEZへの対応: 日本の排他的経済水域は世界第6位の広さを誇る。無人艦艇による広域監視・救助補助は実用的なユースケースになりうる 離島・僻地での活用可能性: 有人機の到達に時間を要する離島海域での初動対応手段として、自律型USVは検討に値する 日本での入手可能性: Saronic TechnologiesのCorsairは現時点で防衛機関向けの提供に限られており、民間・一般向けの販売経路はない 筆者の見解 今回の救助で印象的なのは、自律型システムが訓練ではなく実際に命がかかった場面で機能したという事実だ。AIエージェントの議論はソフトウェア領域で語られることが多いが、物理空間を動く自律型ハードウェアにおいても「目的を渡せば自律的にタスクを遂行する」設計思想が着実に現実へと落ちてきている。 人間が危険にさらされる状況、あるいは物理的に間に合わない状況でこそ自律型システムの真価が問われる。Corsairが示したのは、「自律」が単なる技術用語ではなく、現場で実証された能力であるという事実だ。 日本でも、海難救助・離島支援・災害対応において自律型無人システムの実用化議論を加速させるべき段階に入ったと言えるだろう。今回の事例は、その議論に説得力ある先例を加えることになる。 出典: この記事は Drone boat picked up downed US Army helicopter pilots—a first for sea rescues の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

WIREDのDhruv MehrotraとDell Cameronが2026年6月8日（現地時間）に報じたスクープは、テック業界に波紋を広げた。MetaがRay-Banスマートグラスの companion アプリ「Meta AI」に、未発表の顔認識システム「NameTag」のコードを密かに組み込んでいたという内容だ。Ars Technicaが翌9日に続報として確認したところ、Metaはその報道から1日も経たないうちにコードを削除していた。 「NameTag」とは何だったのか WIREDの調査によると、5,000万台以上のスマートフォンにインストール済みのMeta AIアプリには、以下の仕組みで動作するよう設計されたコードが含まれていたという。 スマートグラスのカメラが捉えた顔を生体情報署名（フェイスプリント）に変換する ユーザーのデバイス上に保存されたフェイスプリントのデータベースと照合する 認識できなかった顔はローカルストレージに切り抜き保存・インデックス化して将来の処理に備える WIREDによれば、このコードは早ければ2026年1月の時点でアプリに組み込まれていたという。NameTagは同年2月にニューヨーク・タイムズが社内文書を引用して存在を報じていたが、Metaは「最終決定を下していない」と繰り返していた。 Metaの対応——否定から削除へ WIREDの最初の報道に対して、Metaの広報担当バイスプレジデントのAndy Stone氏は「あくまで探索的な機能であり、今後どうするか最終的な決定はまだ下されていない」と述べた。最高技術責任者のAndrew Bosworth氏はWIREDの報道を「信じられないほど誤解を招く」「まったく不誠実」と激しく批判した。 しかし、WIREDの報道翌日にリリースされたMeta AIの最新バージョンのコードからは、顔認識に関連するすべての要素が取り除かれていた。Ars Technicaが確認した削除内容は以下の通りだ。 顔認識ライブラリ本体（報道版には複数の専用ライブラリが存在していた） NameTag認識プロセスを動作させるコード一式 「Person recognized（人物を認識しました）」アラート機能 未認識の顔の切り抜き画像と生体情報署名を保存するローカルフォルダ Metaはコードを削除した理由についても、今後この機能が復活するかどうかについても、WIRED・Ars Technicaの取材に回答していない。 未回答のまま残るプライバシー上の疑問 WIREDがMetaに事前送付した10の質問はいずれも回答されなかった。未回答事項の中には以下が含まれる。 NameTagが使用するフェイスプロファイルのデータベースを既に作成しているか否か 未認識者の写真・生体情報データをデバイス上にどれくらいの期間保持するか そのデータがMetaのサーバーに送信される可能性があるか否か ストーカーや虐待者が公共の場で見知らぬ人を特定することへの対策 視覚障害者向けの機能として開発しているとの情報への回答 ユーザーのオプトイン・オプトアウトの設計 プライバシー擁護団体はこのシステムについて、公共の場での人物特定による個人の安全リスクを強く懸念している。 日本市場での注目点 Ray-Ban Metaスマートグラスは現時点で日本では公式未発売であり、国内での入手は容易ではない。ただし本件の本質的な意義は製品の入手可能性よりも、ウェアラブルカメラ搭載デバイス全般に共通するプライバシー問題として捉えるべきだろう。 日本では改正個人情報保護法（2022年全面施行）において、顔認識データを含む生体情報は「要配慮個人情報」として最も厳格な取り扱い規定の対象となっている。仮に同様の機能が日本市場で展開された場合、個人情報保護委員会（PPC）の監督下で相当な規制上の摩擦が生じることは想像に難くない。 また、国内では駅や商業施設でのAIカメラ・顔認証システム導入を巡る議論が活発化しており、今回の件は「ユーザーの知らないところで顔情報が処理されるリスク」を示す具体的事例として参照価値が高い。 筆者の見解 今回の問題で最も深刻なのは、技術的な機能そのものよりも情報開示のあり方だと考える。 「顔認識機能は存在しない」と公式に否定しながら、実際にはその機能を動作させるコードが5,000万台規模のアプリに配信されていた——という事実は、ユーザーとの信頼関係において取り返しのつかないコストを生む。否定→翌日削除という一連の流れが、かえって疑念を増幅させた形だ。 「禁止ではなく安全に使える仕組みを作れ」という観点に立てば、顔認識技術そのものを悪とみなす必要はない。視覚障害者支援や安全なパーソナライゼーションなど、プライバシーに配慮した適切な実装であれば社会的価値は十分にある。問題はユーザーへの事前説明・明示的な同意・オプトイン設計が一切ないまま、事実上本番同然の形でコードが組み込まれていた点だ。 「探索的な機能」と言うのであれば、クローズドなテスト環境で実施するのが技術倫理の基本だ。一般配信版に忍ばせておく合理的な理由はない。スマートグラスというフォームファクターが持つ潜在的な可能性を、自らの不透明な姿勢で損ねていると言わざるを得ない。 出典: この記事は One day after discovery, Meta pulls facial recognition code from its smart glasses の内容をもとに、筆者の見解を加えて独自に執筆したものです。

NASA（米航空宇宙局）は2026年6月9日、アルテミスIIIミッションの搭乗員4名をジョンソン宇宙センターにて正式発表した。Ars TechnicaのエリックBerger記者が現場から詳細をレポートしている。 アルテミスIIIとは——月面着陸の「前段」として設計された低軌道試験 まず押さえておきたいのは、アルテミスIIIは月面着陸ミッションではないという点だ。2026年4月に完了したアルテミスII（有人月周回飛行）と、月面着陸を目指すアルテミスIVの橋渡し役となる、低軌道（LEO）での試験飛行として新たに組み込まれた。 NASAの新長官ジャレッド・アイザックマンが「人類を月に送る前にリスクを買い下げる（buy down risk）必要がある」と判断し、数ヶ月前にプログラムに追加されたミッションだ。コマンダーのランディ・ブレズニックも発表当日、「我々はアルテミスIIとIVをつなぐリンクだ」と端的に語っている。 搭乗員4名のプロフィール Ars Technicaのレポートによると、発表された4名はいずれも軍歴を持つ経験豊富な宇宙飛行士だ。 ランディ・ブレズニック（NASA宇宙飛行士）— コマンダー ルカ・パルミターノ（ESA欧州宇宙機関）— パイロット アンドレ・ダグラス（NASA宇宙飛行士）— ミッションスペシャリスト フランク・ルビオ（NASA宇宙飛行士）— ミッションスペシャリスト ESAのパルミターノが参加することで、アルテミス計画が国際協力プロジェクトであることも改めて示された形だ。 ミッション概要——3回の打ち上げと複合ドッキング Ars Technicaの報道によれば、約2週間のこのミッションには3機の宇宙船が関与する複雑な構成が組まれている。 第1打ち上げ：Blue Origin「Blue Moon」着陸試験機 先行打ち上げとなるBlue Originの着陸試験機は、最大90日間軌道上に待機できる能力を持つ。 第2打ち上げ：Orion + SLS（搭乗員） Space Launch System（SLS）ロケットでOrion宇宙船が打ち上げられ、搭乗員4名が乗り込む。その後Blue Moon着陸試験機とランデブー・ドッキングし、クルーが内部に入って生命維持システムの検証を実施。結合飛行中の制御はOrionが担う。 第3打ち上げ：SpaceX Starship さらに別タイミングでSpaceXのStarshipを打ち上げる。ただしこの機体には生命維持装置が搭載されておらず、搭乗員は内部に入らない。ドッキングはあくまで近接飛行技術とドッキングアダプタの実証にとどまる。 最終的にクルーはStarshipからアンドックし、太平洋への着水で帰還する計画だ。 タイムライン 2027年夏以降：アルテミスIII打ち上げ（最速スケジュール） 2028年：アルテミスIV——実際の月面着陸 アイザックマン長官は記者団に「2027年の打ち上げおよび2028年の月面着陸について極めて強い自信を持っている」と語った。 日本市場での注目点 アルテミス計画はNASAを中心に各国宇宙機関が参加する国際プロジェクトであり、日本もアルテミス合意に署名しJAXAが連携している。将来的にはJAXAの宇宙飛行士が月面に立つ計画があり、文部科学省もその実現に向けた準備を続けている。 また、Blue Origin（ベゾス系）とSpaceX（マスク系）という競合する2大民間宇宙企業が、同一ミッションで補完的な役割を担う構図は注目に値する。宇宙開発の官民協働モデルが本格的に機能し始めたことを示しており、日本の宇宙スタートアップや関連産業にとっても参考になるアーキテクチャだ。 筆者の見解 アルテミスIIIで最も興味深いのは、NASAがBlue OriginとSpaceXという2社の宇宙船を同一ミッションに統合しようとしている点だ。異なるベンダーの機体を軌道上で連結して飛行するのは、純粋な工学的挑戦として見ても相当に複雑な作業になる。 「リスクを買い下げる」という長官の判断は理に適っている。月面着陸という大きな目標の前に、複雑な操作手順を実際の宇宙環境で検証しておく——これはソフトウェア開発で言えば本番前に統合テスト環境でリハーサルを徹底するのと本質的に同じ発想だ。 スケジュールが「アグレッシブ」と表現されるほどタイトであることには注意が必要だが、地上シミュレーションだけでは得られない知見が必ずある。2028年の月面着陸実現に向け、2027年のアルテミスIIIがどこまで計画通り進むか——宇宙開発の次の章が始まろうとしている。 出典: この記事は NASA assigns crew for Artemis III, sets aggressive timeline for flying it の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Sahil Senら5名の研究チームが2026年5月に公開したarXiv論文が、Claude Code・OpenAI Codex CLI・Google Gemini CLIという3つのAIエージェントハーネスを使った実証実験で「古典的なgrep（パターンマッチング）がベクトル検索を多くの場面で上回る」ことを示し、RAG設計の常識に一石を投じている。 RAGの「常識」に疑問を投げかけた研究 近年のLLMエージェント開発において、検索拡張生成（RAG: Retrieval-Augmented Generation）はほぼ標準アーキテクチャとなっており、「精度の高い検索にはベクトルデータベース（セマンティック検索）が必要」というのが暗黙の常識になっていた。 しかしこの論文は、「実際のエージェントループの中でどちらが機能するか」という実務的な問いに正面から取り組み、その前提を揺さぶる結果を示している。 実験の設計：2段階で公平に比較する 研究では2段階の実験が行われた。 実験1：LongMemEvalでの直接比較 長期対話履歴の記憶能力を評価するベンチマーク「LongMemEval」から116問をサンプリング。独自ハーネス「Chronos」を加えた4環境で、grepとベクトル検索の正答率を比較した。注目すべきは、ツール呼び出し結果の「提示方法」も変数に組み込んだ点だ。LLMがツール結果をプロンプトに直接受け取るインライン方式と、ファイルとして書き出してLLMが別途読み込むファイルベース方式の両方をテストしている。 実験2：ノイズ耐性のテスト 実際のユースケースでは、関連情報が大量の無関係なコンテキストに埋もれることが多い。実験2では無関係な会話履歴を段階的に増やし、両手法のノイズ耐性を定量的に比較した。 主要な発見：ハーネスが検索アルゴリズムを超える 発見1：grepの優位性 4ハーネスを通じて、grepはベクトル検索より高い精度を示した。LLMが出力したクエリに対して、ベクトル空間での近似マッチングよりも文字列の確実な一致・部分一致の方が信頼性が高かったのだ。 発見2：ハーネス設計が精度を決定する より重要な発見は「同じ会話データ・同じ検索アルゴリズムを使っても、どのハーネスを使うかで精度が大きく変わる」という事実だ。Claude Code、Codex CLI、Gemini CLI、Chronos、それぞれで同じデータに対して異なるスコアが出た。ツール結果の提示方法（インライン vs ファイルベース）もスコアを動かす変数となった。 日本のIT現場への影響 RAGパイプラインのコスト再考：ベクトルデータベースの導入・運用には相当なコストと複雑性が伴う。コードベース、ドキュメント、ログのような構造化コーパスを扱うシステムでは、grepを基盤にしたシンプルな設計も十分に選択肢に入る。 「どう検索するか」より「どうループを回すか」：検索アルゴリズムの最適化より先に、エージェントアーキテクチャ全体の設計に注力すべきだという優先順位の転換を、この研究は示唆している。 ツール結果の渡し方が性能を変える：インライン vs ファイルベースという設計判断が精度に影響するという発見は、エージェント開発における「プロンプトの渡し方」の重要性を改めて浮き彫りにする。 筆者の見解 この論文の結論は、実務で感じてきた直感とよく一致している。AIエージェントシステムの設計において「何を使って検索するか」よりも「ハーネスをどう設計し、どうループを回すか」が最終性能を左右するという認識だ。 grepの優位性については「精巧さより確実性」という観点から腑に落ちる。ベクトル検索は「意味的に近いものを見つける」のが得意だが、「確実に存在する文字列を取得する」用途ではgrepの方が信頼性が高い。LLMが生成するクエリの特性を考えると、完全一致・部分一致が有効に機能する場面は想像以上に多い。 より示唆深いのは「ハーネスが精度を決める」という発見だ。「どのLLMが優れているか」を比べる議論から、「ハーネスを含めたシステム全体をどう設計するか」を問う時代への移行を、この研究は実証的に示している。エージェント開発者にとって、ハーネスの選定と設計は今後ますます重要な技術領域になっていく。 出典: この記事は Is Grep All You Need? How Agent Harnesses Reshape Agentic Search の内容をもとに、筆者の見解を加えて独自に執筆したものです。