Tech News JP

プリンストン大学のArvind Narayananと共同研究者Sayash Kappurが発表したエッセイ「Why AI hasn’t replaced software engineers, and won’t」が、AI業界で注目を集めている。「AIがエンジニアを置き換える」という言説に対し、実際の雇用データと定性調査を組み合わせて反証した内容だ。 NYの法定データが「AI解雇ゼロ」を示す 注目すべき出発点は、米国ニューヨーク州が2025年3月に導入した制度だ。同州はWARN Act（大規模解雇事前通知法）の申告書に「AIを理由とした解雇か否か」を記載するチェックボックスを追加した。初年度で160社以上が申告を行ったが、AIボックスにチェックを入れた企業は1社もなかった。 WARN ActはAI規制がほぼ存在しない米国において、バイアスの少ない雇用統計の一つだ。テクノロジー業界ですらAIを直接的な解雇理由に挙げた企業がゼロという結果は、「AI＝大量失業」という言説の根拠の薄さをデータで示している。 コードを書く速度は、そもそもボトルネックではなかった AIコーディングツールが最も得意とするのは「コードを素早く生成すること」だ。しかし研究者らは複数の業務時間調査を引用し、コーディングそのものがエンジニア業務のボトルネックではないと指摘する。 実際、エンジニアの多くは会議・デバッグ・仕様調整・コードレビューに時間を費やしており、タイピングの高速化で解決できる問題は限定的だ。では、本当のボトルネックはどこにあるのか。研究チームはエンジニア自身への定性調査から3つの要素を特定した。 何を作るかを決定し、仕様化すること（Deciding and specifying what to build） 成果物を検証し、責任を持つこと（Verifying and being accountable） コードベース・ビジネス・環境への深い人間的理解（Deep human understanding） この3点が、現時点のAIに代替しにくい領域だ。自然言語で指示を出せば即座にコードを生成するAIが普及しても、「何を作るべきか」「これで正しいか」「この判断の責任は誰が持つか」という問いへの答えは、依然として人間が担う必要がある。 日本のエンジニアへの実務的示唆 この研究が示す知見は、日本のIT現場にも直接当てはまる。AIツールを積極的に活用することは今後の必須スキルだが、エンジニアとしての価値の源泉はコードを速く書ける能力ではなく、上流工程の判断力にシフトしていく。 具体的なアクションとして以下を提案する： 要件定義力を磨く: システムの目的・スコープ・優先度を明文化し、AIに対してもステークホルダーに対しても説明できる言語化能力が重要になる AIの出力を検証できる能力を維持する: AIが生成したコードの品質・セキュリティ・パフォーマンスを評価できる技術的素養は必須。「動いているように見える」ではなく「なぜ動くのか」を理解していることが求められる ドメイン知識への投資を怠らない: ビジネスロジック・業界固有の制約・既存コードベースへの深い理解こそが、AI時代のエンジニアの差別化要因となる 筆者の見解 この分析には強く同意できる。 高度なAIエージェントを日常的に活用している立場から実感するのは、コーディングのスピードが数倍になっても、「何を作るべきか」「このアーキテクチャで本当にいいのか」という問いの質は、人間の理解の深さに比例したまま変わらないということだ。 とりわけ、AIエージェントが自律的に判断・実行・検証を繰り返す「ハーネスループ」が実用化されても同じことが言える。ループを回すエージェントに正しいゴールを与え、その出力を評価する能力は人間側にしか宿らない。AIが自律的に動けるほど、最初の「目標設定」と最後の「成果の受け取り方」が、人間のバリューとして際立ってくる。 「AIを使えばエンジニアはいらない」という言説に不安を感じるエンジニアは多い。しかし現実はむしろ逆方向の変化が起きている——AIを使いこなせるエンジニアとそうでないエンジニアの間の生産性格差が、急速に広がり続けているのだ。今必要なのは「置き換えを恐れること」ではなく、「深い理解を武器にAIを正しく使いこなすこと」だ。この研究が示す「3つのボトルネック」は、まさにその深い理解が宿る場所を指し示している。 出典: この記事は Why AI hasn’t replaced software engineers, and won’t の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIは、企業のAI導入・展開・変革を組織的に支援する「OpenAI Partner Network」を正式に発足させた。総額1.5億ドル（約225億円）を投資し、世界各地のパートナー企業を通じたエンタープライズ向けAI普及を本格化させる。 パートナーネットワークとは何か OpenAI Partner Networkは、コンサルティングファーム・システムインテグレーター・テクノロジーベンダーといった外部パートナーを通じ、企業顧客がChatGPT EnterpriseやAPIをより効果的に導入・活用できるよう支援するエコシステムだ。 OpenAI単体では対応しきれない「業種固有の要件」「各国の規制対応」「既存システムとの統合」「導入後の定着支援」といった課題を、信頼できるパートナー企業が担う構造である。Microsoftが長年築いてきたパートナーエコシステムや、SalesforceのAppExchangeと同様のモデルを、OpenAIが独自に構築しはじめたとみることができる。 投資の使途としては、パートナー向けのトレーニングプログラム・技術認定制度・共同マーケティング・専任サポートなどが想定される。 なぜ今、パートナーネットワークなのか 背景には「AIの普及段階の変化」がある。2022〜2023年のChatGPTブームは「試してみる」フェーズだった。2024年以降は「業務に組み込む」フェーズに移行しており、企業が求めるのは「使えるかどうか」ではなく「どう使いこなすか」という実装知識になっている。 この実装知識を大規模に届けるには、直販だけでは限界がある。パートナーネットワークはその突破口だ。OpenAIが「頭脳」を提供し、パートナーが「手足と文脈」を提供する役割分担により、導入のスピードと深度を同時に高める狙いがある。 実務への影響——日本のIT現場でどう読むか SIerや導入支援企業への影響が大きい 日本ではNTTデータ・富士通・日立・アクセンチュアJapanといった大手SIerや、中堅のクラウドインテグレーターがパートナー候補として浮かび上がる。認定パートナーになることで差別化と商機を得られる可能性がある。 企業の意思決定が変わる OpenAIとのダイレクト契約に踏み切れなかった企業が、信頼するSIer経由で安心して導入を進めやすくなる。「AI導入の敷居を下げる仕組み」として機能すれば、中堅・中小企業への波及効果も期待できる。 エンジニアに求められるスキルが変わる OpenAI APIやChatGPT Enterpriseの実装経験を持つエンジニアの市場価値が上がる。特に「OpenAI認定」がパートナー要件になれば、個人レベルの認定取得も実質的な武器になりうる。 筆者の見解 パートナーネットワークという戦略そのものは、実にオーソドックスで正しい判断だと思う。エンタープライズのAI導入で本当に難しいのは「技術を使えるかどうか」ではなく「現場の業務フローに溶け込ませられるか」だ。それはどの企業固有の文脈や、現場担当者との信頼関係があって初めて実現できる。直販だけでスケールしようとすることには無理がある。 一方で、1.5億ドルという数字が「実質的なパートナー支援」にどこまで使われるかは注視が必要だ。認定プログラムの名目でパートナーに費用負担を求めるような構造になれば、エコシステムは腐敗する。Microsoftが長年かけてパートナーとの信頼を積み上げてきた歴史を、OpenAIがどれだけ真剣に学んでいるかが問われる。 エンタープライズAI市場は「誰がより賢いモデルを持っているか」の勝負から、「誰がより深く企業に食い込んでいるか」の勝負に移行しつつある。OpenAIがその転換を正面から認識してパートナーに賭けた判断は、長期的なシェア争いにおいて無視できない一手だ。 出典: この記事は Introducing the OpenAI Partner Network の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米テック企業が2026年に入って約15万人を解雇しながら「理由はAIだ」と説明する一方、Cerebras SystemsやSpaceXのIPOを機にAI関係者たちが想像を絶する富を手にしており、この格差が社会的「火薬庫」になりつつある。 「AIが原因」は本当か？ 削減ペースは前年比44%増 テック求人プラットフォームTrueUpの集計によると、2026年に入ってからわずか半年で米テック企業では363件の人員削減が発表され、約15万人が職を失った。前年比で約44%速いペースであり、1日あたり約974人が解雇されている計算になる。 直近ではさらに加速しており、先月は2年間で最多となる約4万人が1ヶ月で削減された。人材紹介会社Challenger, Grey & Christmasによると、「AI」が業界を問わず3ヶ月連続で人員削減の最多理由として挙げられている。 しかしここに「AIが本当の原因か」という疑問が浮上している。 象徴的なのがジャック・ドーシー氏率いる決済企業ブロック（Block）だ。今年初め、同社の人員を約半数削減した際「AIツールが新しい働き方を可能にしている」と説明したが、SNS上での追及を受けてドーシー氏自身が「パンデミック期に過剰採用していた」という事実を認めた。 著名VCのマーク・アンドリーセン氏はより直接的に「AIは不正管理のための銀の弾丸の言い訳だ」と表現した。「大企業の多くは少なくとも25%、場合によっては75%以上の過剰人員を抱えている。そこに都合のいい口実ができた」という指摘は業界に波紋を広げた。 同じ時期に「AI長者」が続々誕生 この大量解雇が進む一方、AIインサイダーたちは歴史的な富を獲得している。 AIチップメーカーCerebras Systemsが先月ナスダックに上場し、初日に公開価格（185ドル）から68%上昇。時価総額は約670億ドル（約10兆円）に達し、共同創業者のアンドリュー・フェルドマン氏とショーン・リー氏がいずれも億万長者の仲間入りを果たした。 SpaceXも先週上場し、執筆時点で時価総額2.1兆ドル（約310兆円）。イーロン・マスク氏の資産は紙の上では兆ドル規模に達し、社員約4,400人がミリオネアに、約400人がセンチミリオネア（1億ドル以上の資産家）になる見通しだ。AnthropicとOpenAIも上場に向けた動きを加速させており、両社とも評価額は1兆ドル超を視野に入れている。 SNSのプラットフォーム企業メタ（Meta）では、マーク・ザッカーバーグ氏が今年3月にマイアミの邸宅を1億7,000万ドル（約250億円）で購入——マイアミ・デイド郡史上最高額の住宅売買を記録——し、その2ヶ月後にAI投資加速を理由に8,000人規模の削減を発表した。 一般労働者は生活コスト上昇に直面 一方で一般の労働者は厳しい経済的圧迫に置かれている。雇用主提供の健康保険料は今年6〜7%上昇（インフレ率の2倍以上）、2008年以降の民間健康保険料はほぼ倍増、2020年初頭からの住宅中央値価格は28%上昇、住宅ローン金利もほぼ倍増している。 日本のIT現場への影響と実務のヒント この「AIを理由にした人員削減」の流れが日本に波及するリスクは現実的だ。 「AI導入＝削減の口実」にしないための組織設計 AIによる生産性向上の成果を、コスト削減ではなく付加価値の拡大に向けることが持続可能な戦略だ。「AIを入れたから人を減らす」という論理は、短期の数字を改善しても中長期では組織の競争力を損なうリスクがある。 本当の「過剰採用」問題を直視する アンドリーセン氏の指摘が正しければ、多くの組織で「AI関係なく」人員規模が適正でなかった可能性がある。日本では逆に慢性的な人員不足の企業が多いが、AI導入後の業務設計と人員配置の見直しは今から着手しておくべき課題だ。 AIスキルの格差を縮める環境づくり AIを活用して価値を生み出せる人材とそうでない人材の格差は急速に拡大している。IT管理者・エンジニアとしては、チームメンバー全員が実際にAIツールを使いこなせる環境を整備することが急務だ。「使うことを義務化する」のではなく、「使った方が明らかに楽で速い」という体験を積ませることが鍵になる。 筆者の見解 「AIが本当に雇用を奪っているのか、それとも過剰採用の後処理にAIが使われているだけなのか」——この問いにはおそらく両方の答えが混在している。実際にAIツールを使い倒している立場からすると、AIが「本物の生産性革命」をもたらしていることは疑いようがない。問題はその恩恵がどこに向かうかだ。 私が注目するのは、この「格差の可視化」が持つ社会的インパクトだ。数万人が職を失う一方でIPOで一晩にして億万長者が続々と誕生するというコントラストが鮮明になればなるほど、AI推進に対するカウンターフォースが強くなる。規制・税制・雇用保護の観点で政府が動き出すのは時間の問題だろう。 AI活用によって仕事のあり方が根本的に変わることは不可避だ。ただしそれは「人間をAIに置き換える」話ではなく、「AIを使いこなせる人間が10倍・100倍の仕事をこなす」という構造変化だと私は見ている。企業がこの違いを理解せず単なるコスト削減ツールとしてAIを位置づけるなら、短期の利益改善はあっても中長期では競争力を失う。 今、日本のIT現場でやるべきことはシンプルだ。削減の波を恐れるより、AIをしっかり使いこなせる自分・チームを作ることに集中する。それが最大の防衛策になる。 出典: この記事は The AI layoff wave is becoming a powder keg の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Claude CodeやCodex、GitHub Copilot CLIなど主要AIコーディングエージェントに対応したプラグイン「Ponytail」が、「怠惰なシニア開発者の哲学」をエージェントに注入することで、生成コード量を最大94%削減・処理速度3〜6倍・APIコスト最大77%削減を達成したと報告している。 「過剰実装」はAIエージェントの本能的な罠 AIエージェントにコードを書かせると、しばしば過剰な実装が生まれる。日付ピッカーを頼んだだけなのに、flatpickrをインストールし、ラッパーコンポーネントを書き、スタイルシートを追加し、タイムゾーン対応の議論まで始める。ブラウザには最初から <input type="date"> があるのに、だ。 Ponytailはこの問題に正面から向き合うプラグインだ。コードを書く前に、以下の順序でチェックを強制する： そもそも必要か？ → 不要なら作らない（YAGNI） 標準ライブラリで解決できるか？ → 使う プラットフォームのネイティブ機能で解決できるか？ → 使う インストール済みの依存関係で解決できるか？ → 使う 1行で書けるか？ → 1行にする それでもダメなら：動く最小限を書く このルールセットをセッションごとに自動注入することで、「経験あるエンジニアなら一瞬で見抜く不要なコード」を事前に刈り取る設計だ。 計測結果：3モデル・5タスク・各10回の中央値 計測はHaiku・Sonnet・Opusの3モデルで実施。「メールバリデーター」「デバウンス」「CSV集計」「カウントダウンタイマー」「レートリミッター」の5タスク、各10回の中央値を報告している。 指標 削減効果 コード行数 80〜94%削減 レスポンス速度 3〜6倍高速化 APIコスト 47〜77%削減 重要な設計方針として「怠惰であって、杜撰ではない（Lazy, not negligent）」が掲げられている。信頼境界のバリデーション・データロス対応・セキュリティ・アクセシビリティはショートカットの対象外だ。また、各ショートカット箇所にはコード内に ponytail: コメントでアップグレードパスが明示されるため、後から本番対応へ拡張する際の道筋も残される。 ベンチマークは npx promptfoo eval -c benchmarks/promptfooconfig.yaml で自分でも再現できるよう公開されている。 対応AIエージェント・ツール Ponytailは以下に対応している： ツール インストール方法 Claude Code /plugin marketplace add DietrichGebert/ponytail OpenAI Codex codex plugin marketplace add DietrichGebert/ponytail GitHub Copilot CLI copilot plugin marketplace add DietrichGebert/ponytail Gemini CLI gemini extensions install https://github.com/DietrichGebert/ponytail Pi agent harness pi install git:github.com/DietrichGebert/ponytail Cursor / Windsurf / Cline / Aider / Kiro ルールファイルを手動コピー Claude CodeとCodexのプラグインはNode.jsのライフサイクルフックで動作するため、node がPATHに入っている必要がある（Nix/nvm環境では非対話シェルのPATHに注意）。 ...

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

Linuxカーネル開発チームが安定版「Linux 7.1」を正式リリースした。本バージョンでは、NTFSドライバーの完全な書き直し、次世代IntelおよびAMDプロセッサー向けの大規模パフォーマンス最適化、そして重要なハードウェアバグ修正が一括して取り込まれている。 NTFSドライバー全面刷新：Windows連携が本格強化 最大の注目点はNTFSドライバーの完全再設計だ。NTFSはWindowsが標準採用するファイルシステムであり、Linuxからの利用シーンは以下のように幅広い。 デュアルブート環境: WindowsとLinuxを切り替えながら同じパーティション上のファイルにアクセスするユーザーにとって、安定性向上は直接的な恩恵になる 企業のデータ移行: WindowsファイルサーバーからLinuxへの移行プロジェクトで、NTFSボリュームの読み書きが従来より確実になる WSL（Windows Subsystem for Linux）連携: WSLはWindowsのNTFS上でLinuxが動作する独特なアーキテクチャを持つため、カーネルレベルのNTFS改善がWindows開発者環境にも間接的に波及する可能性がある 従来の実装は長年にわたり改善が重ねられてきたが、Windowsの最新機能への追従で後手に回る局面もあった。7.1で採用された新ドライバーはより近代的なアーキテクチャで構築されており、安定性・パフォーマンス・互換性の三拍子が揃った設計になっているとされる。 次世代Intel・AMD向けパフォーマンス最適化 Linux 7.1では次世代IntelおよびAMDプロセッサーへの最適化が大規模に実装された。新しいCPU命令セットへの対応拡張、メモリ帯域幅の効率化、電力管理アルゴリズムの改善などが含まれる。 サーバー・データセンター環境では、カーネルレベルの最適化が実ワークロードのパフォーマンスに直結する。Azure・AWS・Google Cloud上でLinux VMを運用している企業にとっては、カーネルアップグレードによる性能向上がそのままクラウドコスト削減につながる可能性を持つ。 現時点では「次世代チップ向け」の最適化であるため、恩恵を得られるのは新しいハードウェアを持つ環境に限られるが、それらのチップが普及し始めたタイミングにカーネルの準備が整っているという意味で、先行投資的な価値がある。 重要なハードウェアバグ修正も同梱 「vital hardware bug fixes」と表現されている修正群も本リリースに含まれる。具体的な詳細は個別のパッチノートを確認する必要があるが、ハードウェアレベルの安定性修正は実運用環境において見逃せない変更だ。特に特定のハードウェア構成で問題が報告されていた場合、このリリースで解決される可能性がある。 実務への影響 インフラ・クラウド担当者へのポイント： クラウドインスタンスのカーネル更新タイミングを把握する: Ubuntu・RHEL・Debianなど各ディストリビューションへの7.1系の取り込みスケジュールを確認し、社内標準イメージの更新計画を立てておく NTFSアクセスが絡む作業の再評価: WindowsファイルサーバーからLinuxへのデータ移行作業や、デュアルブート環境での運用を行っているチームは、7.1以降のドライバー挙動を検証環境で早めに確認することを推奨する 新規サーバー調達の参考に: 次世代Intel・AMD向け最適化が入ったことで、新規ハードウェア選定時にLinuxカーネルとの親和性を検討する根拠が一つ増えた ディストリビューションごとにバックポートの方針やサポートポリシーが異なるため、自社が使うディストリビューションのリリースノートを追うのが確実だ。 筆者の見解 NTFSドライバーの全面刷新は、地味に見えて実務上は大きな変化だ。WindowsとLinuxの境界がかつてより曖昧になっている現代では、ファイルシステムの互換性は開発者にとっても運用担当者にとっても日常的な摩擦源だった。その摩擦を減らす取り組みは、どちらの陣営のユーザーにとっても歓迎できる。 パフォーマンス最適化については、「今は関係ない」と思って素通りするのは早計だ。新しいIntel・AMDチップは1〜2年以内に市場に出そろい、気づけば手元のサーバーに入っているものだ。カーネルがそれに対応していなければ、ハードウェアの能力を半分も引き出せない状態が続くことになる。 日本のエンタープライズでもクラウドやオンプレ問わずLinuxを基盤とするシステムが着実に増えている。「Linuxはサーバー担当が見るもの」という時代から、アプリ開発者やクラウドアーキテクトもカーネルの変更を把握しておく時代に変わった。このリリースはその意味でも、チェックリストに入れておく価値のある更新だと思う。 出典: この記事は Linux 7.1 arrives with an NTFS overhaul and major hardware performance boosts の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GoogleがSearch全体をGemini 3.5 Flashで刷新し、従来の「リンク一覧を返す検索」から「クエリごとにAIがカスタムサマリーページを生成する検索」へと抜本的に転換した。 何が変わったのか——「リンクを探す検索」から「答えを受け取る検索」へ これまでのGoogle Searchは、キーワードに合致するWebページのランキングリストを返すものだった。ユーザーは複数のサイトを行き来しながら情報を収集・統合するのが当たり前だった。 今回の全面移行後は、クエリに応じてGemini 3.5 Flashがリアルタイムに生成したサマリーページが最初に表示される。複数ソースの内容を統合し、検索意図に合わせてカスタマイズされた回答が提示される形だ。 既に段階展開されていたAI Overview（旧SGE）の延長線上にある変更だが、今回は「一部のクエリ」ではなく「全クエリへの全面適用」という点でスケールがまったく異なる。 Gemini 3.5 Flashが実現した「秒284トークン」の意味 全面移行を支えているのがGemini 3.5 Flashの生成速度だ。秒あたり284トークンという数字は、検索結果を返す体感速度をほぼ損なわずにAIサマリーを生成できることを意味する。 従来のAI Summary実装は、モデルの推論コストと生成レイテンシがボトルネックになりがちだった。Flashシリーズは「高速・低コスト」に最適化されたモデルであり、Googleが持つ膨大な検索インフラと組み合わせることで全クエリ対応を可能にしている。 実務への影響——SEOとリサーチワークフローが変わる SEO戦略の再考が急務 これまでは「Googleの検索結果上位に表示される」ことが集客の基本だった。AIサマリーが全面化すると、ユーザーが検索結果ページのリンクをクリックしないケースが増える。「ゼロクリック検索」は以前から議論されていたが、今回の変化でその比率は大きく上昇する可能性がある。 企業のWebマーケティング担当者は「クリック数の最大化」だけでなく、「AIに信頼できる情報源として引用されるか」という視点を戦略に加える必要がある。 技術調査ワークフローへの影響 エンジニアやIT管理者が技術情報を調べる際の体験も変わる。エラーメッセージ、設定方法、ベストプラクティスといった技術系クエリでは、複数ドキュメントをはしごしなくても統合された回答が得られるケースが増えるだろう。 ただし、AIサマリーが古い情報や不正確な情報を含むリスクは常に存在する。セキュリティ設定や本番環境の操作に関わる情報は、必ず公式ドキュメントの原文を参照する習慣を維持することを強く勧める。 日本語対応の現状把握 Googleの新機能展開では日本語対応が英語に比べて遅れることが多い。導入初期は英語検索で精度を確認しながら活用を始め、日本語対応の品質を継続的に見極めていくのが現実的なアプローチだ。 筆者の見解 検索エンジンが「リンクのインデックス」から「AI生成の回答エンジン」に転換するという流れは、もはや避けられない。Googleの今回の動きは、その転換への本格的な踏み込みだ。 気になるのは正確性と透明性の担保だ。AIが生成するサマリーは便利だが、参照元を追いかけにくくなる分、誤情報が広がりやすくなるリスクがある。技術情報や医療・法律情報のように正確性が命の領域では、AIサマリーをそのまま信頼するのは危険だ。生成AIの「もっともらしさ」は、正確さの保証ではない。 同様の方向性はMicrosoft Bingでも進んでいる。CopilotとBingの統合は道半ばながら、「検索体験とAI回答の融合」という方向性は共通だ。Googleの全面移行は競合にとって圧力になる一方、MicrosoftがWebブラウジング体験のシームレスさで差別化を図るチャンスでもある。正面から勝負できる力があるだけに、どう応えるかが楽しみだ。 道具が賢くなればなるほど、使い手のリテラシーが問われる。AIが要約した情報だけに頼るのではなく、一次情報にあたる力——ソースを自分で読み批判的に評価する力——がこれまで以上に重要になる。今のうちに情報収集のワークフローを見直しておきたい。 出典: この記事は Google Search Now Entirely Powered by Gemini 3.5 Flash の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AnthropicはClaude APIの旧バージョン「Claude Sonnet 4」と「Claude Opus 4」を2026年6月15日（本日）をもって正式廃止した。 廃止後はこれらのモデルIDを指定したAPIリクエストがすべてエラーを返す。組み込みシステムや自動化ワークフローに使っている場合は、今すぐ後継モデルへの切り替えが必要だ。 何が廃止され、何に移行すべきか 今回廃止対象となるモデルと、Anthropic公式が案内する移行先は以下の通り。 廃止モデル 移行先モデル Claude Sonnet 4 Claude Sonnet 4.6 Claude Opus 4 Claude Opus 4.6 2026年6月15日以降、旧モデルIDを指定したAPIリクエストはすべてエラーレスポンスを返す。MakeやZapierといった自動化プラットフォーム上でAnthropicモジュールを組み込んでいるシナリオも例外ではなく、放置すれば既存ワークフロー全体が停止する。 なぜこれが重要か モデル廃止は「あとで対応すればいい」では済まない。廃止日当日からAPIが実際にエラーを返すため、準備なく迎えれば本番システムが突然止まる。特に影響を受けやすいのは次のケースだ。 SaaS・業務ツール連携: Make、Zapier、n8n などの自動化プラットフォームでAnthropicモジュールを使っているシナリオ 独自開発アプリケーション: Anthropic SDKを直接使い、モデルIDをコードにハードコーディングしているケース 社内RAG・チャットシステム: 一度構築したら長期運用しがちな内製ツール LLMのモデルIDをコードに直書きする実装は、こうした廃止サイクルで必ず問題になる。環境変数や設定ファイルで外部管理するのが基本中の基本だ。 実務での対応手順 ステップ1：影響範囲の特定 コードベースを横断的に検索して、旧モデルIDの使用箇所を洗い出す。 出典: この記事は Anthropic Claude Model Deprecations on June 15, 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年6月のProduct Terms更新で3ヶ月連続となるAIライセンス条件の大幅改定を実施した。Copilot StudioのCustomer Copyright Commitment（CCC）適用指定の削除、Agent 365の前提ライセンス要件の明文化、Azure Local向けAzure Hybrid Benefitの適用縮小など、企業の調達・コンプライアンス担当者に直結する変更が複数含まれている。 3ヶ月連続の改定——何が動いているのか 直近の動きを振り返ると、3月はAzure Arcの簡素化、4月はハイリスクAIコンテンツへのガードレール強化、5月はAIエージェントへのマルチプレクシング規定拡大とRPA出力のAIトレーニング禁止、そして6月は「Azure AI Services」という包括定義の新設だ。Azure Foundry経由でデプロイされるすべてのモデル（サードパーティ含む）にEnterprise AI Services行動規範が適用される形になった。 個別のモデルプロバイダー条件は外部ドキュメントページに集約された。これは管理の一元化という観点では合理的だが、追跡すべきドキュメントが増えることも意味する。 最重要変更①：Copilot StudioのCCC指定が告知なし削除 Customer Copyright Commitment（CCC）とは、AI生成コンテンツが第三者の著作権を侵害した場合の法的リスクをMicrosoftが顧客に代わって負う知的財産補償制度だ。「MicrosoftのAIが作ったものはMicrosoftが守る」という企業向けの大きな売り文句でもあった。 6月更新前、Power Platform Service Specific TermsにはCopilot Studioが「Covered Product（対象製品）」として明記されていた。これが今回の更新でひっそりと削除された。変更説明には一切記載がない。 重要な補足として、CCC自体の保護が消えたわけではない。CCCのRequired Mitigationsページ（最終更新：2026年3月20日）にはCopilot Studioが引き続き掲載されており、保護は継続している。ただしProduct Terms本文から消えたということは、CCCドキュメントページを個別に監視していなければ変更を見落とすリスクがある。さらに、外部モデルをCopilot Studioに接続した場合、そのモデルの出力はAzure OpenAI経由でなければCCC対象外になる点も忘れてはならない。 最重要変更②：Agent 365のライセンス前提条件が明文化 Agent 365の利用には以下のいずれかが必要と初めて明示された。 Microsoft 365 E5 F5 Defender and Purview Business Premium 裏を返せば、Microsoft 365 E3、Business Basic、Business Standardでは利用できない。E3のみでAgent 365活用を検討していた組織には追加投資が求められる。段階的なエージェント活用計画を描いていた場合、ライセンス計画の見直しが必要だ。 その他の注目変更点 Azure Hybrid Benefit for Azure Localの適用縮小：従来は比較的広く適用できたが、ハイパーコンバージドインフラ（HCI）構成に限定された。Azure Localを使ったオンプレミスコスト最適化を計画している組織はアーキテクチャ要件を再確認すること。 SPUR（サービスプロバイダー利用規約）へのAIトレーニング禁止拡大：5月のRPAトレーニング禁止がSPLA（サービスプロバイダーライセンス契約）ホスティング会社向けに拡大。Office Suites、Project、Visio経由で処理したデータをAIモデルのトレーニングに使うことが禁止された。 非公表変更：Customer LockboxがCompliance Services一覧から削除され、「Microsoft Discovery」という未告知サービスがLimited Accessレジスターに追加された。前者は何らかの移行が背景にある可能性があり、後者はまだ詳細不明だ。 ...

Microsoft Entraが2026年6月、FIDO2パスキーの組織展開を支援する「Registration Campaigns」機能を一般提供開始した。管理者はサインイン時にパスキー登録を促すキャンペーンを設定できるようになり、フィッシング耐性認証の普及に向けた現実的な移行パスが整備された。あわせてLinux向けフィッシング耐性MFAのGA、App Deactivation機能の追加など、ゼロトラスト戦略の土台を固める複数のアップデートが加わった。 パスキー普及の「最後の1マイル」を埋めるRegistration Campaigns FIDO2パスキーが優れた認証方式であることは広く知られているが、実際の組織展開で最大の壁となるのが「既存ユーザーへの登録誘導」だ。Registration CampaignsはサインインフローのUI内で自然な形でパスキー登録を促せる設計で、強制することなく段階的な普及を後押しできる。 Windows HelloのデバイスバウンドパスキーはMicrosoft Entra参加・登録済みデバイスでなくても利用可能で、生体認証やPINによるフィッシング耐性サインインが実現する。ただしWindowsのインタラクティブコンソールサインインはサポート対象外のため、既存の展開シナリオとの整合性確認は必要になる。 Linux向けフィッシング耐性MFAが一般提供開始 Microsoftのidentity brokerを通じたLinuxデスクトップ向けフィッシング耐性MFAが一般提供（GA）になった。対応ディストリビューションはUbuntu 24.04/26.04およびRHEL 8/9/10で、WindowsとmacOSに続きLinuxも同水準のフィッシング耐性MFAを利用できる環境が整った。 クラウドネイティブな開発環境でLinuxを使うエンジニアが多い日本のエンタープライズ企業にとっては待望のアップデートだ。CI/CDパイプラインやクラウドシェル環境でのMFA強化に直結する。 ガバナンス強化：孤立アカウント検出とApp Deactivation ガバナンス面でも実用的な機能が複数追加された。 孤立アカウントの自動検出（Discovery Reports） 接続済みアプリケーション内のすべてのアカウント（孤立アカウント含む）を可視化するレポート機能。アクセス権のギャップ特定やアプリケーションオンボーディング支援に活用できる。Microsoft Entra ID GovernanceまたはEntra Suiteが必要。 App Deactivation アプリケーションを削除せずに無効化できる機能。セキュリティ調査中の不審アプリ停止や、設定データを保持したまま一時停止したいケースに対応する。無効化されたアプリは新規アクセストークン取得もサインインも不可になる一方、設定・権限・メタデータは保持される。後からの再有効化も可能で、完全削除と異なり「証跡を残しつつ止める」用途に向いている。 テナント間セキュリティグループ同期 複数のEntraテナントをまたいでセキュリティグループとメンバーシップを同期できる。M&Aや企業グループ内IT統合のシナリオで有効な手段が増えた。 Azure AD B2C移行支援：500万オブジェクト以上の大規模移行に対応 High Scale Compatibility（HSC）モードにより、500万オブジェクト以上を持つ大規模なAzure AD B2Cテナントが、ユーザーの再登録やパスワードリセットなしにMicrosoft Entra External IDへ移行できる。B2CポリシーアナライザーでGA移行準備を評価した上で、アカウントチームと連携して進めることが推奨されている。 パブリックプレビュー：ドメインレスSAML連携と秘密度ラベル パブリックプレビューに入った機能のうち特に注目したいのが2つだ。 ドメインレスSAML連携 外部ユーザーがメールドメインのマッチングなしに、自社IdP（アイデンティティプロバイダー）の認証情報でサインインできるようになる。従来の制約が緩和され、パートナー企業やサプライヤーとのフェデレーション設計が柔軟になる。 EntraセキュリティグループへのMicrosoft Purview秘密度ラベル M365のラベルポリシーをEntraセキュリティグループにも適用可能になる。ゲストアクセス制御を含むグループ設定のガバナンスをMicrosoft Purviewと統合して管理できる。 実務への影響 パスキー展開を検討している管理者へ Registration Campaignsは強制ではなく「促す」設計のため、ユーザー体験を損なわずに移行を進められる。まずパイロットグループにキャンペーンを設定して登録率を測定し、全展開の可否を判断するアプローチが現実的だ。 Linux環境のセキュリティ担当者へ 対応ディストリビューション（Ubuntu 24.04/26.04、RHEL 8/9/10）を確認し、identity brokerの導入を優先検討すべきだ。開発環境全体でフィッシング耐性MFAを適用できるかどうかは、ゼロトラスト戦略の実効性に直結する。 マルチテナント管理者へ テナント間グループ同期を活用する場合、どのテナントをマスターとして管理するかのガバナンスポリシーを先に決めておくことが重要だ。技術的な機能が整備されても、運用ルールが曖昧なままでは混乱が生じやすい。 筆者の見解 今回のEntraアップデート群を見ると、Microsoftがアイデンティティ基盤に着実にリソースを投じていることが伝わってくる。特にRegistration Campaignsによるパスキー誘導は、「理想の認証方式を現場に浸透させる」という現実的な課題に正面から向き合った実装で、評価できる。 ゼロトラスト戦略においてアイデンティティが土台であることは言うまでもない。生成AIエージェントが組織内で動き始める中、Non-Human Identities（NHI）の管理と人間のアカウント管理を統合的に扱えるプラットフォームの重要性はさらに高まっている。EntraがそのコントロールプレーンとしてAgent IdentityのSponsorship管理まで備え始めているのは、長期的に見て正しい方向性だと思う。 一方で、毎月これだけ多くの機能が追加され続けると、現場のIT管理者が「何から手を付けるべきか」を見失うリスクも出てくる。機能の充実と、それを実際に使いこなすためのドキュメントや移行支援の充実は、必ずしも同じペースでは進まない。Microsoftには機能を増やすことと同じくらいのエネルギーを、その伴走支援に向けてほしいと、長年利用してきた立場から率直に思う。 Linux向けMFAのGA、App Deactivation、テナント間グループ同期——いずれも地味に見えて、実際の現場では「あれ、これできないんだっけ」と困るポイントを埋める機能だ。そういった堅実な積み上げがEntraへの信頼を支えている。 ...

Microsoftは2026年6月のMicrosoft Build 2026において、Azure HorizonDBのパブリックプレビューを発表した。AIエージェントワークロードを念頭に一から再設計されたPostgreSQL互換のフルマネージドデータベースサービスで、エンタープライズ向けの信頼性とAIネイティブ機能を一体化している。 Azure HorizonDBとは何か Azure HorizonDBは、単なるPostgreSQLのホスティングサービスではない。LLMエージェントが大量のデータにリアルタイムでアクセスするAIネイティブな用途を主軸に設計されたデータベース基盤だ。 Microsoftによれば、自己管理のPostgreSQLと比較してトランザクション性能と検索速度が最大3倍向上している。スケール面でも以下の数値が示されている。 最大 128TBのデータベースをサポート 最大 15台のリードレプリカによるスケールアウト 可用性ゾーン間でのサブミリ秒コミットレイテンシー PostgreSQL互換を完全に維持しており、既存のORM・ドライバー・pgvectorを使ったコードの大部分をそのまま移行できる点は実務上のアドバンテージになる。 AIネイティブ機能の核心：DiskANNベクター検索 Azure HorizonDBが既存サービスと一線を画す最大の特徴は、DiskANN（球面量子化対応）をデータベースエンジンに直接統合した点だ。 DiskANNはMicrosoft Research発の近似最近傍探索アルゴリズムで、ベクターを正規化・圧縮して球面距離（角度距離）で比較する。この球面量子化により、大規模ベクターインデックスをメモリに載せきれない場合でも低ストレージコストで高速な類似検索を実現できる。pgvectorのようなメモリ依存型の実装と比べて、大規模運用でのコスト効率が高い。 さらに、インDB AIモデル管理機能により、エンベディング生成などのAI処理をデータベース内で完結させる構成も視野に入る。データの移動を最小化し、レイテンシーと複雑性を下げる設計思想だ。 エンタープライズセキュリティ：Entra IDとの統合 セキュリティ面では、Microsoft Entra IDとのネイティブ統合を標準装備する。データベースへのアクセス認証・認可を組織のIDインフラに一元化でき、プライベートエンドポイントによるネットワーク分離、保存中・転送中の暗号化も含まれる。 これはAIエージェントがデータベースに自律的にアクセスする構成——いわゆるNon-Human Identity（NHI）の管理においても重要だ。エージェントごとにEntra IDのサービスプリンシパルやマネージドIDを割り当て、最小権限でアクセス制御できる基盤が整っている。 実務への影響 RAG・AIエージェント基盤の有力候補 RAG（Retrieval-Augmented Generation）構成では、埋め込みベクターを格納・検索するデータベースの選定が性能のボトルネックになりやすい。Azure Database for PostgreSQLでpgvectorを運用しているチームが、ベクター検索性能の壁にぶつかっている場合、Azure HorizonDBは現実的な移行先の選択肢になる。 PostgreSQL互換を維持しているため、アプリケーションコードの改修コストは低く抑えられる。 既存Azureインフラとの親和性 Entra ID統合・プライベートエンドポイント・Azure Monitor連携など、すでにAzureを基盤としている組織であれば追加設定のコストが小さい。Azure Kubernetes ServiceやAzure Container Appsと組み合わせたマイクロサービス構成での採用が現実的なシナリオだ。 VS Code向けのPostgreSQLツール拡充も同時発表されており、開発者ループ全体をAzureエコシステム内で完結させやすくなっている。 筆者の見解 Azure HorizonDBは、Azureのデータベースサービス群の中で久々に「コンセプトが一本通っている」と感じる製品だ。「AIエージェントが使うデータベース」という軸を最初から据えた設計は、後付けでベクター検索を追加してきたサービスとは本質的に異なる。 DiskANNの採用は技術的に正しい判断だと思う。Microsoft Researchが長年培ってきた研究成果を自社プラットフォームに組み込む——これをきちんとやれるのはMicrosoftの強みであり、こういうところで真価を発揮してほしい。 Entra ID統合も地味に効いてくる。AIエージェントがデータに自律的にアクセスする時代においては、NHIの認証・認可管理は必ず課題になる。Entra IDを中心に一元管理できる設計を最初から持っているのは、エンタープライズ採用の現場でかなり助かるはずだ。 もっとも、現時点ではパブリックプレビューだ。価格体系・GAのタイムライン・マルチリージョン対応の詳細はまだ不明な部分が多い。PostgreSQL互換をうたう以上、オープンエコシステムの維持とのバランスも長期的に注視する必要がある。 AIエージェント基盤を本気で検討しているチームは、パブリックプレビューの段階から触れておく価値は十分にある。GAを待ってから評価し始めると、競合との差が開く可能性があることも頭に入れておきたい。 出典: この記事は Azure HorizonDB: Enterprise-Ready Postgres, Engineered for the AI Era の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftが2026年6月、Microsoft 365（M365）の重要なセキュリティ関連アップデートを複数リリースした。MSP（マネージドサービスプロバイダー）視点で整理すると、IntuneのEdge向けセキュリティベースライン更新、Windows 11 25H2向けセキュリティベースラインの新規追加、そしてDefender for Office 365 Plan 1の標準組み込みという3点が今月のハイライトだ。管理する顧客テナント数が多いMSPほど、対応優先度を早めに判断する必要がある。 IntuneのEdgeセキュリティベースラインが更新 Microsoft Intuneが管理するMicrosoft Edge向けのセキュリティベースラインが新バージョンに更新された。セキュリティベースラインとは、Microsoftが推奨する設定値のパッケージで、エンタープライズ環境でのブラウザセキュリティを一括適用するための基準定義だ。 旧バージョンのベースラインを適用中のテナントは、Intuneコンソール上に「新しいベースラインへの更新が利用可能」という通知が表示される。ただし、自動更新はされないため管理者が明示的に操作する必要がある。変更点の差分を必ず確認し、既存カスタムポリシーとの競合がないかをテスト環境で事前検証してから本番展開するのが鉄則だ。 セキュリティベースラインは「Microsoftが検証した推奨値」であり、これをそのまま使うことが「道のド真ん中を歩く」最も再現性の高い選択だ。独自設定を足し算してカスタマイズし続けると、ベースライン更新のたびに差分管理が煩雑になる。シンプルに保つことが長期的な管理コストを下げる。 Windows 11 25H2向けセキュリティベースラインが新規追加 次世代アップデートとなるWindows 11 25H2向けのセキュリティベースラインが新たにリリースされた。25H2では新機能の追加に伴い、対応するセキュリティポリシー項目も拡張されている。 MSP各社にとっては、顧客環境が25H2へアップグレードされるタイミングに合わせた事前準備が重要だ。特に大規模テナントでは、展開ロードマップを立てる段階からこのベースラインの内容を織り込んでおくと、展開後の設定漏れや後追い対応を防げる。Windows Update for Business（WUfB）やUpdate Complianceと組み合わせて、アップグレードとベースライン適用をセットで計画するのが効率的だ。 Defender for Office 365 Plan 1が標準組み込みに 今月最大の変更点がこれだ。Defender for Office 365 Plan 1が、M365の一部ライセンスに標準搭載される形に変更された。 これまで個別にPlan 1を契約していた組織は、ライセンス構成の重複が生じる可能性がある。まず現在のライセンス棚卸しを行い、余剰が発生していないか確認することを強く推奨する。一方でDefender for Office 365を導入していなかった組織にとっては、フィッシング対策・マルウェア対策・Safe Links・Safe Attachmentsといった機能が自動的に利用可能になるという意味で、セキュリティレベルの底上げとなる。 注意点は「標準搭載＝即座に有効化」ではない点だ。テナントへの展開タイミングや、自動有効化される設定がある場合に既存のメールフローや他のセキュリティ製品との競合が生じないかをMicrosoft 365管理センターで事前確認する必要がある。 実務への影響——MSP・IT管理者がやること 今週中に確認すべきチェックリスト： Intuneコンソールでセキュリティベースラインのバージョン確認：Edgeベースラインの新バージョンが適用可能になっているか確認し、変更差分をレビューする。テスト環境→本番の順で展開 25H2展開計画へのセキュリティベースライン適用を組み込む：顧客のWindows 11展開ロードマップに25H2ベースラインの適用ステップを追加する Defender for Office 365の有効状態を確認：標準組み込みにより自動有効化される機能がないか管理センターで確認。既存のExchange Online Protection（EOP）設定との整合を取る ライセンス棚卸し：Plan 1を別途契約していた場合、重複コストが発生していないか確認しMicrosoftアカウントチームへ相談 筆者の見解 M365のセキュリティ機能が着実に底上げされていることは、率直に評価したい。Defender for Office 365 Plan 1の標準組み込みは、コスト面から導入を見送っていた中小規模組織にも基本的なメール脅威防御が届くことを意味する。MSPにとっては管理対象テナント間の均一化が進むという観点でも歓迎できる変更だ。 セキュリティベースラインの定期更新も、Microsoftがベストプラクティスを継続的に更新し続けているという姿勢の表れだ。「現状維持」を選びがちな現場が多いが、ベースラインに乗り続けることがコストパフォーマンスの高いセキュリティ投資になる。 ただし、個々のセキュリティ機能を並べただけでは本当の価値は出ない。Microsoft Defender、Intune、Microsoft Entra ID、そしてDefender for Office 365が連携し、認証・デバイス・メール・エンドポイントを統合的に守る設計になって初めてM365の真価が発揮される。今月の更新を機に、顧客環境のセキュリティアーキテクチャ全体を見直すきっかけにしてほしい。「Defender入れたから大丈夫」ではなく、「Entra IDのゼロトラストポリシーと合わせてどう機能させるか」という視点で設計することが、MSPとしての本質的な付加価値を生む。 ...

MicrosoftとGallupの最新調査が「誰もがAIを使っている」という通説を数字で覆した——ChatGPT・Claude・Microsoft Copilotなどの主要AIサービスを月90分以上使う米国の積極的利用者は労働人口のわずか30%に留まり、「積極的利用・時々利用・未使用」にほぼ三等分される実態が明らかになった。 「AIブーム」の実態：3分の1は一度も使っていない ブロガーのGabriel Weinberg氏が複数の調査データを横断比較した分析記事が、実態をくっきりと浮かび上がらせた。 Microsoftが公開したAI普及サイト「United States AI Diffusion」によると、ChatGPT・Google Gemini・Anthropic Claude・Microsoft Copilotなどの主要AIサービスを月90分以上使う米国の労働人口は**30%**に過ぎない。残りの70%は実質的に非利用者だ。 Gallupがジェネレーション Z（Gen Z）を対象に実施した年次調査（2025→2026年）も同様の傾向を示している。 指標 2025年 2026年 たまでも使う（at least rarely） 79% 81% 月1〜数回のみ 32% 31% 全く使わない 21% 19% AIに怒りを感じる 22% 31% 特筆すべきは「怒り」の数字だ。1年間でおよそ40%増加しており、AI普及が進む一方で反発も拡大している。 三等分の法則：積極的・時々・未使用 デスクトップ実利用データを分析したDatos社の調査（2025年6月時点）では、デスクトップ端末の62%がAIツールを月0回しか訪問しないという結果が出た。月10回以上訪問する積極的利用者は21%にとどまる。 Searchlight Institute・The Argumentなど複数の調査を総合すると、米国のAI利用状況はおおむね次の三等分に収束する。 積極的利用（週1回以上）：約3分の1 時々利用（月1回以下）：約3分の1 未使用：約3分の1 「全員がAIを使っている」は、ごく一部のヘビーユーザー視点から生まれた錯覚だったと言える。 AI利用を躊躇する「本物の理由」 Searchlight Instituteの調査は、人々がAI使用を制限する背景を詳しく分析している。上位3つの懸念は： 雇用喪失・失業への恐れ（42%） プライバシーの侵害（35%） 誤情報・偽情報の拡散（33%） これらは「AIがよくわからないから怖い」という漠然とした不安ではなく、具体的な社会課題への懸念だ。AI提供側——ChatGPT（OpenAI）、Claude（Anthropic）、Copilot（Microsoft）、Gemini（Google）——がこれらを真剣に受け止めなければ、利用拡大の壁は下がらない。 実務への影響：日本のIT現場への示唆 日本でも同様の調査があれば、おそらく米国より保守的な数字が出るだろう。AI推進を担うIT管理者・エンジニアへの実践的ポイントをまとめる。 1. 「全員が使っている前提」の社内計画を見直す 米国でさえ積極利用者が30%という現実を踏まえると、「社員はもうAIを使えるはず」という前提での施策設計は危険だ。社内のリテラシー分布を実際に把握した上で、段階的なアプローチが必要になる。 2. 懸念を封じるのではなく、答えを提示する 「仕事が奪われる」「情報が漏れる」という懸念は、禁止や制限では解消されない。安全に使える環境（データポリシーの明示、許可ツールのリスト整備、活用事例の共有）を整備して初めて、組織全体の利用が健全に広がる。 3. KPIより「体験」を先行させる 利用率を数字で追うと、形だけの使用が増える。まず数名のパワーユーザーが本物の成果を出し、その体験が口コミで広がる流れが最も持続する。数字を測るのはその後で十分だ。 筆者の見解 この調査データを見て真っ先に思うのは「思ったより普及していない」ではなく、「これだけ使われていないのに、なぜ一部のエンジニアはAIで大きな成果を出せているのか」という問いだ。 AI利用が三等分されているということは、積極的に使いこなしているエンジニアとそうでないエンジニアの間に、現時点でもすでに相当な生産性ギャップが生まれている可能性を示唆する。そしてAIが改善されるほど、そのギャップは広がっていく。 「使わない」という選択肢そのものを否定するつもりはない。ただ、今の時代にAIを積極的に試さないエンジニアは、それだけで競争上不利な立場に立たされているという現実は直視してほしい。プライバシーや誤情報への懸念は正当だ。しかしその結論が「だから使わない」ではなく、「安全に使える環境を作って使う」であってほしい。 企業でAI推進を担う立場の人には、ユーザーの懸念に具体的な答えを出す責任がある。「禁止せずに安全に使える仕組みを作る」こと——これが今、最も重要な仕事だと思う。 データが示すのは「まだ間に合う」ということでもある。積極的利用者がまだ30%なら、次の波に乗るチャンスは十分に残っている。 出典: この記事は Not everyone is using AI for everything の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

ブラジル・リオデジャネイロ市の情報技術機関IplanRIOが「独自開発」として公開した大規模言語モデル「Rio-3.5-Open-397B」が、実際にはNex-AGIの「Nex-N2」とAlibabaの「Qwen3.5-397B-A17B」を重み比率60:40で合成しただけのモデルであることが、Nex-AGIによる技術調査で明らかになった。 何が起きたか IplanRIOはリオデジャネイロ市のIT推進機関だ。同機関はGitHubリポジトリ prefeitura-rio/Rio-3.5-Open-397B において、3970億パラメータ（397B）の大規模言語モデルを自前で訓練した独自モデルとして公開していた。 これに対しNex-AGIは、GitHubのIssue上で2つの独立した証拠を提示した。 証拠1：アイデンティティテスト Rioモデルに組み込まれた「あなたはRioです」というシステムプロンプトを外した状態でモデルに自己紹介を求めると、79%の確率で「Nex-AGIのNexです」と答えた。「Rio」と名乗った例は0%。さらに、Nex-AGIの設立経緯を一字一句そのまま暗唱したケースも確認された。 証拠2：重みテンソルの統計解析 全60レイヤー・すべてのコンポーネントにわたるweight tensorを解析した結果、Rio-3.5-Open-397Bの重みは「Nex × 0.6 + Qwen × 0.4」という線形結合として数千標準偏差の精度で再現できることが判明した。ファインチューニング後のモデルでは説明できない一致度であり、element-wise mergeの確証だという。 モデルマージとは何か 「モデルマージ（Model Merging）」とは、複数の既存モデルの重みを数式的に合成して新しいモデルを生成する手法だ。ゼロから訓練するより計算コストが大幅に低く、Hugging Faceのコミュニティでも活発に活用されている。 正当なモデルマージに必要な前提はシンプルだ。利用するモデルのライセンスを確認し、マージ元モデルを明示すること——それだけだ。今回の問題は技術手法そのものではなく、自前で訓練した独自モデルであるかのように公共機関が主張した点にある。 実務への影響 オープンウェイトモデルの「来歴」確認が必須に 公開されているLLMの重みをそのまま再配布・改称するリスクが改めて浮き彫りになった。Apache 2.0やMITライセンスで公開されているモデルでも、配布時の帰属表示義務（attribution requirement）を怠ると法的・評判的リスクを招く。企業や行政がAIモデルを調達・評価する際、ベンチマークスコアだけでなく「誰がどのデータで訓練したか」というモデルの来歴（provenance）を問う文化が必要だ。 モデルカードとウォーターマーキングの重要性 今後は、訓練手法・データ・ベースモデルを記録するモデルカード（Model Card）の整備と、モデルウォーターマーキング技術の普及が、こうした不正表示を抑止する有効な手段になりえる。 日本の公共機関への示唆 日本でも各省庁・自治体が独自LLMの開発・活用を推進する動きが広がっている。調達仕様における「独自開発」の定義や、成果物の透明性確保は今後の重要な政策課題となるだろう。 筆者の見解 モデルマージという手法そのものは合理的だ。一からゼロ訓練するよりコストパフォーマンスに優れ、小規模チームでも強力なモデルを手にできる。その意味で「使ってはいけない技術」ではない。 問題の本質は、公共機関が納税者や住民に対して技術的成果を過大に見せたことだ。AIモデルの来歴を偽ることは、単なるライセンス違反にとどまらず、公的機関への信頼を損なう。 一方で今回、Nex-AGIが行った技術的暴露——重みの統計解析とアイデンティティテスト——が有効に機能したことは重要な示唆でもある。オープンなウェイトには「隠せない」という性質がある。コミュニティの検証力は侮れない。 「AIで開発しました」「独自のAIを作りました」という主張の信頼性をどう担保するか。これは今後、公共調達だけでなく企業のAI戦略においても避けられない問いになる。このケースは、その問いに向き合う絶好の教材として記憶されるはずだ。 出典: この記事は Rio de Janeiro’s “homegrown” LLM appears to be a merge of an existing model の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anthropicが世界トップクラスの合成化学者・計算化学者・分析化学者とのコラボレーションにより、ClaudeのNMR（核磁気共鳴）スペクトル解析能力を検証したホワイトペーパーを公開した。化学研究の日常的な補助作業をAIが担う取り組みとして、創薬や材料科学の現場への実用展開を目指す。 化学者の「翻訳作業」がボトルネックになっている 化学者は日々、まったく異なる複数の表現形式の間を行き来している。ホワイトボードの手書き構造式、NMR装置の出力データ、特許データベースの検索クエリ、論文の専門記法——これらはすべて同じ分子を表しているが、それぞれ異なる「読み解き方」が必要だ。 なぜ分子の正確な同定がそれほど重要なのか。化学の本質はそこにある。グルコース（ブドウ糖）とフルクトース（果糖）は同じ化学式 C₆H₁₂O₆ を持ちながら、体内での代謝経路はまったく異なる。さらに深刻なのが「鏡像体（エナンチオマー）」の問題だ。分子をその鏡像に変えただけで、鎮静剤が催奇形性物質に変わることがある。これがサリドマイド事件の根本原因であり、化学の世界では分子の「どちらの顔か」を正確に読み取ることが人命に直結する。 こうした表現間の翻訳作業——論文の図から構造を特定する、装置の出力と予測生成物を照合する、適切な記法でデータベースを検索する——は膨大な時間を要する。CAS（Chemical Abstracts Service）の化学物質レジストリには2億9,000万種類以上の開示済み物質が収録され、毎日約1万5,000種類が新規追加されている。これを人間だけで管理するのはすでに限界に近い。 NMRスペクトル解析という最重要課題 今回のホワイトペーパーは、化学者が日常的に扱う最も重要な分析データ入力のひとつ、NMRスペクトルに焦点を当てている。NMR分光法は薬品・農薬・染料・香料・ポリマー・DNAサブユニットなど、あらゆる小分子の構造決定に欠かせない手法だ。Anthropicの化学者David Kamberが主導し、NMRスペクトルの予測と構造解析において、化学構造描画の業界標準ソフトChemDrawとの比較検証が行われた。 従来のAI化学ツールが普及しなかった理由 化学分野向けのAIツール自体は以前から存在していた。逆合成計算（レトロシンセシス）——目標分子から遡って合成経路を設計するプロセス——の支援ツールは数年前から利用可能だ。しかし現場への普及は限定的なままだった。主な理由として以下が挙げられる。 訓練データの質が低い: 失敗実験のデータが少なく、フォーマットが不統一。有料学術誌のペイウォールに阻まれたデータが多い 推論の不透明性: なぜその結論に至ったかをモデルが示せない、いわゆるブラックボックス問題 整理済みデータへの依存: 手書き図や生の装置出力ではなく、事前に整備されたデータベースを前提とする設計 Claudeが化学分野で発揮できる3つの強み 現行のフロンティアモデルがマルチモーダル対応かつ明示的な推論が可能になったことで、状況は変わりつつある。 1. マルチモーダル処理による直接読み取り 論文の図や手書きスケッチから直接、化学構造を解釈できる。整理済みの分子データベースを経由する必要がなく、実験室の現実に即した入力に対応できる。 2. ステップバイステップの推論開示 なぜその構造と判断したかを逐次表示できる。化学の安全性・正確性が求められる現場では、AIの出力を盲目的に受け入れるのではなく、人間が論理の流れを検証できることが不可欠だ。 3. 実験記述の直接読解 手法欄や補足情報（Supplementary Information）を、出版されている形式のままで読み解ける。「整理されたデータ」がなくても機能する。 Anthropicは今回の主張を「控えめなもの」と表現しており、Claudeが化学者の専門的判断を代替するのではなく、日常的な翻訳・想起・統合作業を補助することを目指している。 実務への影響——日本の研究者・エンジニアにとって 製薬・化学メーカーの研究効率化: 日本には製薬大手や化学素材メーカーが多数存在する。NMR解析補助の実用化は、実験後処理にかかる研究者の時間を削減し、より本質的な研究に集中できる環境をもたらす可能性がある。 「説明できるAI出力」が導入承認の鍵: 日本の製造業・研究機関では、AIの判断根拠を説明できないと規制対応や社内承認が得られないケースが多い。推論プロセスが追跡可能な設計は、こうした現場での普及を後押しする実用上の強みだ。 まずはAPIでの小規模検証から: Anthropic APIのVision機能を利用してNMRスペクトル画像をアップロードし、構造解析の補助ツールとして試験的に活用することは、大規模な設備投資なしに着手できる。研究者個人レベルでの検証を先行させ、有効性を確認してから組織展開するアプローチが現実的だ。 筆者の見解 汎用大規模言語モデルが専門ドメインの「壁」を越え始めている流れの中で、化学分野への本格参入は一つの試金石になると見ている。 マルチモーダル推論と推論根拠の明示という組み合わせは、特定ドメイン専用モデルが持つ「使えるが理由がわからない」という限界を乗り越えるアプローチとして理にかなっている。研究者が「なぜそうなのか」をAIに確認できることは、単なる精度向上以上の意味を持つ——それは信頼の問題だからだ。 ただし、ホワイトペーパー1本の公開はあくまでスタートラインに過ぎない。実験室で実際に研究者が使い込み、失敗例も含めたデータが蓄積されて初めて、この種のAI化学支援の真価が問われる。特に「ヌルリザルト（失敗実験データ）」の蓄積とオープン化は、化学AIの訓練データ問題を解決する長期的な鍵になる。この構造的課題に対してどこまで踏み込めるかが、今後の評価軸になるだろう。 AIエージェントが実験ログを読み込み、次の合成ステップを自律的に提案するループが研究現場に実装されれば、化学研究のスピードは桁違いに変わる。そのハーネスとなる仕組みがどう設計されていくか、今後の展開を注目して追いたい。 出典: この記事は Making Claude a Chemist の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AnthropicのClaude最新モデル「Fable 5」が、以前のモデルに比べて著しく論争的・攻撃的な振る舞いをするとして、海外の開発者コミュニティで批判が広がっている。 何が起きているのか BitTorrentの生みの親として知られるBram Cohen氏が自身のブログで「Claude Fable 5はなぜひどい態度をとるようになったのか」と題した投稿を公開した。Hacker Newsでも100ポイントを超え、160件以上のコメントが集まっており、同様の体験をしている開発者が多いことが窺える。 Cohen氏によれば、問題の傾向はOpus 4.7から始まり、Fable 5で顕著に悪化したという。具体的には次のような挙動が報告されている。 ユーザーとの対話を「議論・対立」のフレームで捉える ユーザーが言っていないことに対してまで注意書きや補足を付け加える 些末な語義の揚げ足取りを繰り返す 一度論理的に反論されると、ますます無関係な意見を連発する 同氏は検証として「Fable 5に質問して不快な返答をもらう → Opus 4.6に同じ質問をする → そのFableの返答をOpus 4.6に見せる」という実験を行ったところ、Opus 4.6自身が「それはひどい返答だ」と評価したと報告している。新旧モデルの挙動差を同じ会社のモデルが指摘するという、やや皮肉な状況だ。 考えられる原因：過剰アライメントの副作用 Cohen氏は、主な原因として過剰なアライメントガードレールの副作用を挙げている。 ユーザーが悪意ある目的を持っているという前提でトレーニングが行われた結果、そのバイアスが本来無関係なコンテキストにまで滲み出ているのではないかという仮説だ。「ユーザーを有害な行動から守ること」を最優先にした設計が、かえって「自分はユーザーより賢い」という態度を生み出す——というのは逆説的な結果と言える。 また、認証済みコンテキストの欠如も問題を拡大している。ユーザーが専門家・研究者として質問していても、AIはその主張を確認する手段を持たないため、最悪のケース（悪意あるユーザー）を想定して応答するしかない。薬物合成について医療研究者が質問する場合と、匿名の一般ユーザーが同じ質問をする場合では、リスクプロファイルはまったく異なるはずだ。 輸出規制への対応が関係している可能性 2026年6月、米政府の指令によりAnthropicはFable 5・Mythos 5の海外向けアクセスを一部制限した。Cohen氏はこの規制に対応するために急いでガードレールを実装した結果、品質に問題が生じた可能性を示唆している。 実際に、Fable 5で特定の質問をするとOpusにダウングレードされる事例も報告されており、「ガードレールの実装が急ごしらえであることを示す傍証」と見る向きもある。 Cohen氏はさらに、認証オプションの導入——ユーザーが自分の立場・専門性を証明できる仕組み——が解決策の一つになりうると提案している。すべての操作に認証を求めるのではなく、高リスクな文脈でオプトインできる設計にするという考え方だ。 日本の開発現場へのチェックポイント 日本企業でもClaudeをAPIで直接統合しているケースは増えている。今回報告されているような「過剰な注意書き」「論争的なトーン」は、ユーザー向けプロダクトに埋め込まれた場合にUX品質を大きく損なうリスクがある。 API統合を行っているエンジニア・IT管理者へのチェックポイント： モデルバージョンを固定する: APIで model パラメータを特定バージョンに固定することで、モデル更新による挙動変化の影響を回避できる。本番環境での急な挙動変化を防ぐ基本的な対策だ システムプロンプトでコンテキストを明示する: ユーザーの役割（例：「このシステムは医療従事者向けです」）を明示的に定義することで、不必要に防御的な応答を軽減できる可能性がある モデル更新後のA/Bテスト: 新モデルへの移行は段階的に行い、ユーザーフィードバックを収集してから本番適用する運用フローを整備しておく フォールバック戦略の検討: 特定モデルの挙動が問題になった場合に備えて、旧バージョンや代替モデルへの切り替えを素早く行える設計にしておく 筆者の見解 AIモデルのアライメント（安全性の調整）と使い勝手のバランスは、本質的に難しいトレードオフだ。それ自体は避けられない課題であり、各社が試行錯誤を続けているのは理解できる。 ただ、今回報告されている問題——「攻撃的なトーン」「論争フレームの押しつけ」——は、本来のアライメントの目的（有害コンテンツの防止）とはほぼ無関係な場所で起きている。本物の悪意を持つユーザーは口調の丁寧さを気にしないし、返答を論争的にしたところで何かが防げるわけでもない。安全性とユーザビリティを同時に最適化できるはずの問題を、片方を犠牲にして解決しているとすれば、設計上の課題がある。 急ごしらえの規制対応が原因であれば、修正は十分可能なはずだ。Anthropicには技術的な底力があることは実績が証明しており、ユーザーコミュニティからのフィードバックがきちんと開発に反映されることを期待したい。Cohen氏の指摘の本質——「モデルが賢くなること」と「一緒に仕事しやすいこと」は分けて最適化できる——はAIエージェントの設計全体に通じる重要な視点だと思う。 出典: この記事は Why Is Claude Turning into an a**Hole? の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Claude CodeやCopilot、Cursorなどのコーディングエージェントが実務に普及するなか、ベンダーが競うように宣伝する「200万トークン対応」「1Mコンテキスト」といった数字を、そのまま信じるのは危険だ——そう警告するエンジニアの知見が、Hacker Newsで大きな反響を呼んでいる。 「スマートゾーン」と「ダムゾーン」という概念 コンテキストウィンドウを語るうえで、今や欠かせないフレームワークが「スマートゾーン（smart zone）／ダムゾーン（dumb zone）」だ。LLMはコンテキストの冒頭部分では鋭い注意力を発揮するが、ある閾値を超えると急速に精度が低下し、「5分前に指示したことを忘れたような」挙動を見せ始める。その閾値はモデルのアーキテクチャによって多少異なるが、おおむね 100kトークン付近 とされている。 重要なのは、モデルが対応する最大トークン数がいくら増えても、この閾値はほとんど動かないという点だ。Anthropicが2Mトークンの対応を謳っていても、Googleが超大容量コンテキストを発表しても、Attentionメカニズムの根本的な限界が解消されているわけではない。 研究が裏付ける「コンテキスト劣化」 これは感覚論ではなく、研究によっても裏付けられている。MicrosoftとMIT等が共同で発表した評価ベンチマーク RULER や、Chromaによる 「Context Rot（コンテキスト劣化）」レポート では、コンテキストウィンドウが埋まるにつれてモデルのパフォーマンスが段階的に劣化することが定量的に示されている。 「広告上の数値」と「実際に使えるコンテキスト量」の間には、大きなギャップがある。これはLLMを道具として使うエンジニア全員が把握しておくべき事実だ。 コーディングエージェントが直面するリスク コーディングエージェントは、使っていると想像以上のスピードでトークンを消費する。ファイルを数個読み込み、デバッグを少しやり取りして、テスト結果を貼り付ければ、あっという間に100kトークンに達する。その時点で、セッションの後半部分にある指示や文脈は事実上「捨てられている」に等しい状態になる。 Claude Codeには「オートコンパクト（auto-compact）」機能があり、セッションが長くなると自動的に履歴を要約して引き継ぐ仕組みがある。これは一定の効果があるが、要約を生成するのはすでにダムゾーンに入ったモデル自身であるという根本的な問題は残る。「何もしないよりはマシ」だが、それ以上ではない。 実務での活用ポイント：コンテキストを「予算」として扱う 元記事の著者が実践する方法は、コンテキストウィンドウを「使い切るもの」ではなく「節約すべき予算」として設計することだ。具体的には以下のアプローチが有効だ。 1. 新規セッションに仕様書を渡す 長いセッションを続けるのではなく、自分で重要情報をまとめたスペック文書（仕様書・引き継ぎメモ）を書き、それを新しいセッションの冒頭に渡す。オートコンパクトによる自動要約より、人間が「何を次のセッションに持ち越すか」を判断した手動要約のほうが信号品質が高い。 2. 小さな成果物（アーティファクト）に情報を逃がす obra/superpowersやmattpocock/skillsのようなプロジェクトは、PRD・計画書・スキル定義・サブエージェントへの引き継ぎなど、名前のついた小さな成果物にエージェントのワークフローを分割する設計思想を持つ。セッション内に情報を詰め込むのではなく、読み出せるファイルとして外に出すことで、常に「スマートゾーン」の状態で作業を継続できる。 3. ファイル読み込みを慎重に行う 「全ファイルをコンテキストに渡す」ではなく、「今のタスクに本当に必要な部分だけを読み込む」。必要最小限の情報でエージェントを動かすことがスマートゾーン維持の基本だ。 実務への影響 このフレームワークは、AIツールの選定基準を変える可能性がある。「コンテキストが大きいほど良い」という単純な評価軸から、「実効コンテキスト内でどれだけ正確に動作するか」「オーバーフロー時の設計がどうなっているか」という評価軸への転換が求められる。 日本企業でもコーディングエージェントの導入が加速しているが、長時間デバッグセッションや大規模コードベースの読み込みを前提とした使い方では、後半の指示が無視されるリスクがある。CI/CDパイプラインへの組み込みや、エージェントを使った自動化設計において、セッション設計そのものがエンジニアリングの対象になる時代だ。 筆者の見解 ベンダー各社が「コンテキストウィンドウの大きさ」を競うように発表してきた流れには、正直なところ「それは本質じゃない」と感じていた。ユーザーが必要なのは大きな数字ではなく、その範囲内で確実に動作することだ。 今後の改善に期待したいのは、ダムゾーン問題への対処だ。オートコンパクトのような機能は正しい方向性だが、あくまで応急処置に過ぎない。根本的には、アーキテクチャレベルでの解決——たとえばRAGとエージェントの統合強化や、より賢いメモリ管理機構——が求められるはずで、各社がそこに本腰を入れ始めているのは良い兆候だ。 エンジニアとしての実践的な結論は一つ：「コンテキストを使い切ろうとするな。情報はファイルに書き出せ」。これはAIエージェントの時代における、新しい設計の鉄則になりつつある。 出典: この記事は Don’t trust large context windows の内容をもとに、筆者の見解を加えて独自に執筆したものです。

NASAの超音速研究機「X-59」が、マッハ1.4（時速約1,488キロ）・高度55,000フィート（約16,764メートル）という重要な性能目標を達成した。Engadgetが6月14日（現地時間）に報じた。これはX-59が市街地上空を飛行する「Quesstミッション」に向けて大きく前進したことを意味する。 なぜX-59が注目されるのか——超音速旅客機復活の鍵 超音速飛行の最大の障壁は「ソニックブーム」だ。音速を超える際に生じる衝撃波は地上に爆発音のような騒音をもたらし、コンコルドはかつて多くの国で市街地上空の超音速飛行を禁じられていた。その結果、超音速旅客機は商業的に成立しないまま退場を余儀なくされた経緯がある。 NASAのX-59はこの問題に正面から挑む研究機だ。機体形状を徹底的に最適化することで、ソニックブームをNASA自身が「quiet sonic thump（静かなドスン）」と表現するほどの微小な音に抑えることを目指している。実用化できれば、各国の超音速飛行規制を見直す科学的根拠となり、超音速旅客機の商業復活につながる可能性がある。 海外レポートのポイント——Engadgetが伝えた最新マイルストーン Engadgetのレポートによると、6月5日のフライトでマッハ1.1を達成したX-59は、6月13日のテストでマッハ1.4・高度55,000フィートへと大幅に条件を引き上げた。NASAはこの最新テストを「前回よりもさらに重要なステップ」と位置づけており、Quesstミッションで再現すべき速度・高度目標を達成したことが確認された。 現時点でのフライトには興味深い仕掛けがある。X-59は通常のソニックブームを発生させる別の研究機と並行して飛行している。これはテスト中のX-59が発する音を別の音でマスキングするためであり、まだ外部に音響特性を公開するフェーズにはない。 今後のスケジュールとして、NASAはまず「音響バリデーションフェーズ」に移行する。ここで超音速時の音響シグネチャを精密測定し、従来のソニックブームを発生させていないことを定量的に確認する。その後、「まだ数ヶ月先」とされるQuesstミッションでは、実際に米国の市街地上空を飛行し、地上の住民から音の聞こえ方についてフィードバックを収集する計画だ。 日本市場での注目点 日本においても超音速旅客機の行方は無関係ではない。かつてコンコルドは日本上空を飛行できず、国内線・国際線への展開が阻まれた歴史がある。JAXAも「D-SENDプロジェクト」を通じて低ソニックブーム超音速機の研究を進めており、X-59が積み上げるデータは日本の航空技術研究とも共鳴する。 また、日本航空（JAL）はBoom Supersonicへの出資を通じて超音速旅客機市場の動向を注視している。X-59の実証データが各国の航空規制当局を動かすことになれば、2030年代以降の超音速路線の現実味が大きく変わる可能性がある。 現時点で日本国内での直接の影響はないが、Quesstミッションの結果次第では国際的な超音速飛行規制の見直し議論が本格化する。日本路線が将来の超音速ネットワークに組み込まれる日が、遠い未来の話ではなくなりつつある。 筆者の見解 X-59の取り組みが際立っているのは、技術開発のアプローチの堅実さだ。飛行性能の検証 → 音響シグネチャの精密測定 → 実際の住民によるフィードバック収集、という段階を踏んで進んでいる。「できると主張する」のではなく「再現性ある検証で示す」という姿勢は、大きな規制変更を引き出すために必要なプロセスとして理にかなっている。 もっとも、商業的な超音速旅客機への道のりは依然として長い。Quesstミッションはまだ数ヶ月先であり、そこから規制見直し・商業機開発へと進めば2030年代の話になる。それでも今のフェーズは「技術的に可能か」から「社会的に許容できるか」を問う段階への移行であり、そのエビデンスを丁寧に積み上げているという点で、着実に前に進んでいる。 「静かなドスン」という小さな音が、航空業界の大きな転換を告げる合図になるかどうか——X-59の旅はまだ続く。 出典: この記事は NASA’s X-59 reaches speed and altitude milestones ahead of first quiet supersonic flights の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GoogleがWeb版Google Earthにフライトシミュレータ機能を追加した。PC Watchが2026年6月15日に報じたところによると、Googleは6月13日に全ユーザー向けの提供を開始しており、現在すでに利用可能となっている。 なぜこの機能が注目か Google Earthのフライトシミュレータといえば、旧デスクトップ版に搭載されていた機能を思い出す古参ユーザーも多いだろう。Web版への移行に伴い長らく失われていたその機能が、今回ブラウザ上に復活した形だ。 近年GoogleはWeb版に対してデスクトップ版の強力な機能を順次移植しており、標高プロファイル表示や新しいインポート形式への対応なども実現してきた。フライトシミュレータはその流れの中での集大成的な追加機能といえる。 PC Watchが伝えた機能の詳細 PC Watch（宇都宮 充氏執筆）の報道によると、以下の仕様となっている。 操作方法 Web版Google Earthで「地球を探索」を開き、「ツール」メニューから「フライトシミュレータ」を選択するだけで利用開始できる。追加のインストールは不要だ。 主な特徴 3Dランドマーク付きの地球上を飛行機で自由に飛び回れる 飛行姿勢・速度を示すHUD（ヘッドアップディスプレイ）が表示される 地面に接触して墜落してもその場から復帰可能 留意点 PC Watchの報道でも明記されているとおり、本機能は「カジュアルに地球上を探索するための機能」と位置づけられており、高度な空力シミュレーションは含まれない。本格的なフライトシミュレーターとしての精度を求めるには物足りないだろう。 日本市場での注目点 本機能はすでに全世界のユーザー向けに提供中であり、日本からも追加手続きなしにすぐ利用可能だ。Googleアカウントとモダンなブラウザさえあれば始められる。 競合としてはMicrosoftの「Microsoft Flight Simulator」シリーズや各種カジュアル飛行ゲームが挙げられるが、Google Earthのフライトシミュレータの最大の差別点は「実際の衛星写真・3D地形データをそのまま飛べる」点にある。行ったことのない観光地を上空から疑似体験したり、地形の学習素材として活用したりといった用途では代えがたい体験を提供する。教育現場での活用ポテンシャルも高く、地理学習の導線として注目に値する。 筆者の見解 「本格シミュレーター」として評価するのはお門違いで、そもそもGoogleがそこを狙っていない。重要なのは、何十年分もの衛星データと3Dモデルという唯一無二の資産を、インタラクティブに体験する新しい入口が無料で増えたという事実だ。 「情報を追うよりも使って成果を出す」という観点でいえば、まず開いて10分飛んでみれば価値が分かる類の機能である。セットアップ不要でブラウザだけで動く手軽さは、特にライトユーザー層や教育現場での利用において本質的なアドバンテージになる。仕事や学習のすき間に気分転換として使うだけでも十分面白い。Google Earthのポテンシャルを改めて引き出す、シンプルだが意義のあるアップデートと評価できる。 出典: この記事は 3Dの地球を自由に飛べる。Web版Google Earthにフライトシミュレータ追加 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが「Microsoft Teams Live Events」を2026年6月30日付けで正式廃止することを確認した。社内放送・全社総会・ウェビナーといった大規模配信を担ってきた同機能は「Teams Town Halls」へ切り替えが必要となり、日本企業のIT管理者には早急な対応が求められる。 何が、いつまでに廃止されるのか Microsoftは段階的なスケジュールを公開している。 日付 変更内容 2026年2月3日（実施済み） 廃止日以降の新規Live Events作成が不可に 2026年6月30日 Teams Live Events 完全廃止 同時期 Microsoft Graph APIの関連エンドポイントも廃止 廃止の対象はTeams Live Eventsの機能本体だけでなく、Graph APIを通じたイベント管理・自動化のエンドポイントも含まれる。社内ツールやPower Automateフローで組み込んでいる場合は特に注意が必要だ。 後継機能「Teams Town Halls」とは Microsoftが移行先として正式に指定しているのが「Teams Town Halls」（タウンホール）だ。大規模仮想イベント向けに設計されており、以下のような用途に対応する。 全社員向け経営アナウンス・CEO講話 社内研修・トレーニングセッション 顧客向けウェビナー・製品発表 定期的な全社ミーティング（All-Hands） Town HallsはLive Eventsと比較してUI・UXが刷新されており、主催者・参加者双方の操作性が向上している。また、Microsoftはイベント管理自動化向けの代替Graph APIも提供しているため、既存の連携をそのまま移植することもできる。 移行前に確認すべき5つのポイント 移行プロジェクトが「突然急ぎ」になる典型例がこのタイプの廃止だ。早めに以下を棚卸しておきたい。 1. 6月30日以降の予定イベント 組織カレンダーを確認し、Live Events形式で登録されているものをすべて洗い出す。年次総会・四半期報告など定例化しているものを見落としがちなので注意。 2. 社内コミュニケーション施策との統合 広報・人事・経営企画が「Live Eventsを使う」と想定している施策がないか確認。IT部門だけで完結する話ではない。 3. ウェビナープロセスの棚卸し 外部向けウェビナーをLive Eventsで運用していた場合、参加登録フォームや招待メールのテンプレートごと切り替えが必要になる。 4. Graph APIを使った自動化・連携の有無 Power Automate、Logic Apps、カスタムアプリからLive Events APIを呼んでいるフローが存在しないか確認し、代替APIへの移行を計画する。 5. ユーザートレーニング 主催者（司会担当・IT担当者）は Town Hallsの操作を事前に習得しておく必要がある。本番直前の初見操作は禁物。 あわせて確認——SharePoint/OneDriveのスタンドアロンプラン廃止 Teams Live Events以外にも、同時期に重要な変更がある。MicrosoftはSharePoint OnlineとOneDrive for Businessのスタンドアロン（単体）プランを段階的に廃止する予定だ。 ...