2026.03.12 プラットフォーム

Chrome最新バージョンは150（2026年6月最新）｜更新方法・確認方法とリリース履歴の総まとめ

Q: 自分のChromeのバージョンを確認する方法は？

アドレスバーに chrome://settings/help と入力するか、右上の三点メニューから「ヘルプ」→「Google Chromeについて」を選択します。この画面に現在のバージョンが表示され、同時に最新版への更新チェックも自動で実行されます。

Google Chromeの最新安定版は、2026年6月30日に公開されたバージョン150（150.0.7871.x）です。直前のChrome 149は6月2日、次のChrome 151は7月28日にリリースが予定されています。現在使っているChromeのバージョンはアドレスバーにchrome://settings/helpと入力すれば確認でき、同じ画面で最新版への更新も実行されます。Chromeは原則4週間ごとに更新されますが、2026年9月公開のChrome 153からは2週間ごとのサイクルへ短縮される予定です。本記事では、最新バージョンの確認・アップデート方法から、Chrome 146〜150で実際に入った主要な変更点、リリース履歴の一覧までをまとめて解説します。

まとめ：最新バージョンと確認・更新の要点（結論先出し）

細かい変更点に入る前に、多くの人が最初に知りたい「いま最新版はいくつか」「どう確認・更新するか」を先に整理します。

最新安定版：Chrome 150（2026年6月30日公開、バージョン番号は150.0.7871.x）
バージョン確認：アドレスバーにchrome://settings/helpを入力、または右上の三点メニュー→「ヘルプ」→「Google Chromeについて」
アップデート：上記画面を開くと自動で更新チェックが走り、新版があればダウンロード後に「再起動」で適用される
バージョン番号の意味：「メジャー.マイナー.ビルド.パッチ」の4桁。先頭のメジャー番号がリリースごとに1ずつ増える
リリース周期：現在は4週間ごと。2026年9月のChrome 153から2週間ごとへ短縮予定

Chrome 150を含む最新バージョンの一覧とリリース履歴（2026年最新）

Chromeはメジャーバージョンを定期的に更新するため、「いま使っている版が最新か」「どの版で何が変わったか」を一覧で把握しておくと管理が容易になります。直近のリリース履歴と主要な変更点は次のとおりです。

バージョン	安定版リリース日	主な変更点
Chrome 151	2026年7月28日（予定）	次期安定版（リリース予定）
Chrome 150	2026年6月30日	IndexedDBのSQLiteバックエンド、popover=hintの重なり制御簡素化、Workerのdata: URL分離、WebUI Refresh 2026
Chrome 149	2026年6月2日	CSS gap decorations、shape-outsideのpath()対応、選択的クリップボード読み取り、WebSocketのbfcache対応
Chrome 148	2026年5月5日	脆弱性79件を修正
Chrome 147	2026年4月7日	text-indentのhanging/each-line、UIオートメーション移行完了
Chrome 146	2026年3月10日	スクロール連動アニメーション、WebGPU Compatibility、Sanitizer API、ポスト量子暗号の必須化

Chrome 145（2026年2月）ではJPEG-XL画像形式のサポートやローカルネットワークアクセス権限の分割が導入されました。それ以前のバージョン（Chrome 144など）の詳細はGoogle Chrome 144の解説記事にまとめています。

安定版バージョン番号150.0.7871.xの読み方とチャネルの見分け方

Chrome 150の安定版バージョンは「150.0.7871.x」という形式で表記されます。構成は「メジャー.マイナー.ビルド.パッチ」の4桁で、先頭のメジャー番号がリリースごとに1ずつ増加します。マイナーアップデート（緊急のセキュリティパッチなど）が入った場合は、メジャー番号は変わらず末尾のパッチ番号だけが更新されます。

ベータ版と安定版はメジャー番号だけでは区別できないため、チャネルの確認が必要です。chrome://settings/helpを開くと、安定版（Stable）であれば「Google Chrome」とだけ表示されますが、ベータ版では「Google Chrome Beta」と明記されます。開発版（Dev）やCanaryも同様に名称で見分けられます。

4週間から2週間へ短縮されるリリースサイクルとChrome 153の位置づけ

Chromeは長らく4週間ごとにメジャーバージョンを更新してきましたが、2026年9月公開予定のChrome 153から、メジャーリリースの間隔が2週間ごとへ短縮されます。これにより新機能やセキュリティ修正の到達が速くなる一方、エンタープライズ環境では検証サイクルの見直しが必要になります。2026年前半は従来どおり4週間サイクルが維持され、Chrome 151は7月28日、以降も9月のChrome 153までは4週間間隔でのリリースが見込まれます。

セキュリティパッチが緊急で必要になった場合は、メジャー更新を待たずにマイナーアップデートとしてパッチ番号が更新されます。更新頻度が上がるほど自動更新の重要性は増すため、後述のアップデート手順で自動更新が有効になっているかを確認しておくことを推奨します。

Windows・Mac・Linux・Android・iOS・ChromeOSの6プラットフォーム別対応状況

Chromeの最新版はWindows、macOS、Linux、Android、iOS、ChromeOSの6つのプラットフォームで提供されます。デスクトップ版（Windows・Mac・Linux）は安定版リリース日に同時公開され、Android版・iOS版も同日前後に配信されます。ただしプラットフォームごとにビルド番号の末尾が異なる場合があり、たとえばiOS版のChrome 150のビルド番号は「150.0.7871.x」の形式でApp Storeから配信されます。

機能面でも差があります。WebGPU Compatibilityモードのようなグラフィックス系機能は主にデスクトップ向けで、モバイルではGPUドライバの制約から恩恵が限定的です。LinuxはUbuntu 18.04以降、Debian 10以降、Fedora 39以降がサポート対象で、それ以前のディストリビューションでは動作保証がありません。iOS版はiOSのバージョンが古い（おおむねiOS 15未満）と最新版がサポートされない点にも注意が必要です。

リリース履歴と今後のロードマップを公式情報で追う方法

各バージョンの修正履歴やリリース日を正確に追うには、公式情報を確認するのが確実です。バージョンごとの修正一覧は「Chrome Releases」ブログ、開発者向けの新機能はChrome for Developersのリリースノート、企業管理者向けのポリシー変更はChrome Enterprise and Educationリリースノートに掲載されます。Enterprise向けのポリシー新設・廃止は安定版リリースの約2週間前から事前告知されます。

今後搭載予定の機能やスケジュール変更を追跡するには、Chrome Platform Status（chromestatus.com）で各機能のリリースマイルストーンを確認できます。より詳細な開発スケジュール（フィーチャーフリーズ日やブランチポイント）はChromium Dashboardで公開されています。なお、当初あるバージョンで搭載予定だった機能が次バージョンへ延期されることもあり、たとえばtext-indentのhanging/each-lineキーワードはChrome 146から147へ延期されたうえで搭載されました。

JavaScript不要のスクロール連動アニメーションとCSS新機能（146〜150の進化）

Chrome 146で正式搭載されたScroll-Triggered Animations（スクロール連動アニメーション）は、これまでJavaScriptで実装してきたスクロール連動演出を、CSSだけで宣言的に記述できる機能です。さらにChrome 149ではgap decorationsやshape-outsideの拡張、Chrome 150ではpolygon()の角丸パラメータなどが加わり、レイアウト表現の自由度が継続的に高まっています。

Intersection Observerを置き換えるCSS Scroll-Triggered Animationsの宣言的記述

従来、要素がビューポートに入ったタイミングでアニメーションを開始するには、JavaScriptでIntersection Observerを設定し、コールバック内でCSSクラスを付与する手順が必要でした。Scroll-Triggered Animationsでは、CSSのanimation-triggerとtimeline-triggerを組み合わせることで、同様の制御を宣言的に実現できます。

スクロールコンテナ内の要素がビューポートに到達した時点でフェードインさせる処理を、JavaScriptを書かずにCSSだけで完結できます。バンドルサイズの削減にも寄与し、とりわけモバイル環境でのパフォーマンス改善が期待できます。JavaScript APIも併用可能なため、Web Animations APIと組み合わせた高度な制御や、既存ライブラリの段階的な置き換えにも対応しやすい設計です。こうした標準機能の対応状況はWeb Platform Baselineの解説記事で体系的に確認できます。

メインスレッド負荷を抑えるコンポジタースレッド委譲の仕組みと注意点

Scroll-Triggered Animationsの技術的な利点は、アニメーション処理がコンポジタースレッドに委譲される点にあります。従来のJavaScript実装では、スクロールイベントのたびにメインスレッドでコールバックが実行され、重いDOM操作やレイアウト再計算と競合してジャンクの原因になっていました。CSSベースの実装ではブラウザがアニメーションの開始・停止・リセットをコンポジタースレッド上で処理するため、メインスレッドの負荷を大幅に抑えられます。

特にスクロールイベントが高頻度で発火するモバイルデバイスでは体感差が顕著です。従来はrequestAnimationFrameやthrottleでチューニングする必要がありましたが、CSSではそうした調整が不要になります。ただし、アニメーション対象のプロパティがコンポジタブルでない場合（widthやheightなど）は依然としてメインスレッドでの再計算が発生するため、transformやopacityを優先して使う設計が無難です。

Chrome 149のgap decorationsとshape-outside拡張による余白・回り込み制御

Chrome 149では、グリッドやフレックスボックスのギャップ（溝）に罫線スタイルを適用できるCSS gap decorationsが追加されました。column-rule-insetやrow-rule-insetといったプロパティで、アイテム間の区切り線を擬似要素や追加マークアップなしに描画できます。これまで区切り線のために空のborder要素を挟んでいたレイアウトを簡素化できます。

同じくChrome 149では、フロート要素の回り込み形状を指定するshape-outsideがpath()やshape()、rect()、xywh()に対応し、複雑な輪郭に沿ったテキストの回り込みが表現可能になりました。あわせてimage-rendering: crisp-edgesによるニアレストネイバー拡大や、SVGのpathLengthに対応するpath-lengthプロパティも追加されています。

Scoped Custom Element RegistryとChrome 150のpopover=hint整理によるコンポーネント運用

Chrome 146で正式導入されたScoped Custom Element Registryは、Web Componentsの長年の課題だったカスタム要素名の競合を解決する仕組みです。従来はwindow.customElementsというグローバルな単一レジストリにすべての定義を登録する必要があり、複数ライブラリが同名タグを定義するとエラーになっていました。new CustomElementRegistry()で独立したレジストリを作成し、attachShadowのオプションにcustomElementRegistryを指定すれば、そのShadow Root内で独立した定義を使えます。チームAとチームBが共に<my-card>を使っていても、別スコープに登録すれば競合なく共存できます。

Chrome 150では、ヒント用ポップオーバー（popover=hint）の重なり（スタッキング）モデルが簡素化されました。従来はpopover=hintを開くと無関係なpopover=auto要素が意図せず閉じてしまう挙動がありましたが、150ではこれが整理され、ツールチップ的なヒント表示と通常のポップオーバーを併用しても干渉しにくくなっています。マイクロフロントエンドやデザインシステムでコンポーネントを組み合わせる構成ほど、これらの分離・整理の恩恵が大きくなります。

旧世代GPUでも動くWebGPU Compatibilityモードと描画性能の改善点

Chrome 146で正式導入されたWebGPU Compatibilityモードは、OpenGLやDirect3D11しかサポートしない旧世代デバイスでもWebGPUアプリケーションを動作させる仕組みです。WebGPUは本来Vulkan・Metal・Direct3D12といったモダンなグラフィックスAPIを前提としますが、Compatibilityモードを使うことで対応デバイスの裾野を広げられます。あわせてVRAM最適化やWGSLシェーダーの記述性向上など、性能と開発体験の両面で改善が施されています。

featureLevel指定で旧デバイスにWebGPUを展開する手順と上方互換性

WebGPU Compatibilityモードを有効にするには、navigator.gpu.requestAdapterの呼び出し時に{ featureLevel: 'compatibility' }を渡します。ブラウザはOpenGLやDirect3D11をバックエンドとするアダプターを返すため、シンプルなアプリケーションならこの一行の変更だけで旧世代GPU対応が完了します。

重要なのは、Compatibilityモードがコア仕様のサブセットである点です。Compatibilityモードで動作するコードはコアモードでもそのまま動作しますが、逆方向の互換性はありません。したがって、対応デバイス数を最大化したい場合はCompatibilityモードの制約内をベースラインとして開発し、モダンGPU向けの拡張を段階的に追加する設計が合理的です。Compatibilityモード非対応のブラウザでは通常のコアモードとして動作するため、別途フォールバックを実装する必要はありません。

TRANSIENT_ATTACHMENTフラグでVRAM消費を削減するタイルメモリ活用

TRANSIENT_ATTACHMENTは、テクスチャ作成時に指定するGPUTextureUsageフラグです。これを指定するとレンダリングパス内の操作がタイルメモリ上で完結し、VRAM（ビデオメモリ）へのデータ転送を回避できます。テクスチャ内容がレンダリングパス終了後に破棄されるため、GPUドライバがVRAM自体の割り当てを省略できる場合もあります。

効果が大きいのは、マルチパスレンダリングで中間バッファを多用するシーンです。デプスバッファやステンシルバッファなどレンダリングパス内でのみ参照されるアタッチメントをTRANSIENT_ATTACHMENTとして宣言すると、VRAM消費を抑えられます。タイルベースレンダリングが一般的なモバイルGPUでは恩恵が特に大きくなります。一方、後続パスで再利用するテクスチャには使えないため、パイプライン設計の段階で各アタッチメントのライフサイクルを整理しておく必要があります。

Compatibilityモードで制約されるテクスチャ形式と深度ステンシルの注意点

Compatibilityモードはコア仕様のサブセットであるため、機能的な制約があります。最も実務に影響するのがテクスチャ形式の制限です。OpenGLやDirect3D11をバックエンドにする場合、一部のテクスチャ圧縮形式（BC圧縮やASTC圧縮の一部バリアント）が利用できないことがあります。デスクトップ向けのBC形式とモバイル向けのASTC形式は、バックエンドAPIのサポート状況によって可否が分かれます。

深度ステンシルバッファにも制約があり、コアモードで使える一部の形式がCompatibilityモードでは使用できません。レンダーターゲットの構成もコアモードほど柔軟ではない場合があります。対応するには、アプリケーション起動時にアダプターの機能情報をクエリし、利用可能なテクスチャ形式を動的に判定するロジックを組み込む方法が推奨されます。Compatibilityモード固有の制約を一覧化し、テストマトリックスに組み込んでおくと、リリース後の不具合を抑えられます。

XSS対策を標準化するSanitizer APIと強化されたブラウザセキュリティ基盤

Chrome 146ではXSS対策を標準化するSanitizer APIの搭載、ポスト量子暗号（PQC）の必須化、ローカルネットワークアクセス制御の強化が行われ、Chrome 150ではWorkerのデータURL分離や「常に安全な接続を使用する」機能の既定有効化など、さらに踏み込んだ強化が加わりました。

Element.setHTMLによるスクリプト除去とinnerHTML直接代入との安全性比較

Sanitizer APIの中核はElement.setHTML()メソッドです。innerHTMLの安全な代替として設計されており、渡されたHTML文字列からスクリプト実行につながる要素や属性を自動的に除去したうえでDOMに挿入します。ユーザー入力を含むHTMLをそのままinnerHTMLに代入すると<script>タグが実行されXSSの原因になりますが、setHTML()を使えばスクリプトタグは除去され安全なHTMLのみが残ります。

デフォルトではスクリプト実行に関連するすべての要素・属性が除去されます。Sanitizerオブジェクトに構成辞書を渡せば許可する要素・属性を調整できますが、どの構成でもsetHTML()はスクリプト実行を許可しません。ブラウザのHTMLパーサーと直接連携するため、パーサーの挙動差を突く迂回攻撃のリスクが原理的に排除される点が、ライブラリによるサニタイズとの最大の違いです。なお、Safari（WebKit）が未対応のうちは、機能検出（'setHTML' in Element.prototype）でDOMPurify等へフォールバックする実装が堅実です。

ポスト量子暗号ML-KEMの必須化とPostQuantumKeyAgreementEnabledポリシー廃止

Chrome 146で、TLS接続におけるポスト量子暗号（PQC）の使用がデフォルトで必須になりました。具体的にはML-KEM（Module-Lattice Key Encapsulation Mechanism）が標準の鍵カプセル化方式として組み込まれています。これは「Harvest Now, Decrypt Later」攻撃、すなわち現時点で暗号化された通信を将来の量子コンピュータで復号する脅威への予防措置です。

従来はエンタープライズ向けにPostQuantumKeyAgreementEnabledポリシーでPQCを無効化できましたが、このポリシーはChrome 145までで、Chrome 146以降は削除されています。つまりPQCを無効化する手段がなくなったため、ネットワーク管理者はTLSインスペクション機器やプロキシがML-KEMの鍵サイズに対応しているかを確認する必要があります。ML-KEMの鍵データは従来より大きいため、未対応のミドルボックスでは接続がドロップまたはハングアップする可能性があります。

ローカルネットワークアクセス権限の2分割と社内デバイス接続制御の変更点

Chrome 145で導入されたローカルネットワークアクセス権限の2分割は、Chrome 146でさらに管理性が強化されました。従来はlocal-network-accessという単一の権限でローカルネットワーク全体を制御していましたが、local-network（イントラネットや社内デバイス）とloopback-network（localhost／127.0.0.1）の2つに分割されています。

Chrome 146ではLocalNetworkAccessIpAddressSpaceOverridesとLocalNetworkAccessPermissionsPolicyDefaultEnabledの2つのエンタープライズポリシーが追加されました。前者はIPアドレス空間の分類をオーバーライドする機能で、特殊なネットワーク構成を持つ企業が判定ロジックをカスタマイズできます。後者はPermissions Policyのデフォルト動作を制御し、社内Webアプリがローカルネットワークリソースへアクセスする際の権限プロンプト表示を管理者が制御できます。

Chrome 150のWorkerデータURL分離と「常に安全な接続」既定化

Chrome 150では、専用WorkerおよびShared Workerが扱うdata: URLの取り扱いが変更され、これらのWorkerに一意の不透明（opaque）オリジンが割り当てられるようになりました。これによりWorkerが生成元の同一オリジン状態から分離され、データURL経由でのオリジン汚染リスクが低減します。既存コードがWorkerのオリジンに暗黙的に依存している場合は、挙動の変化がないかを確認しておくと安全です。

あわせてChrome 150では、ユーザーが「セーフブラウジングの保護強化機能（Enhanced Safe Browsing）」を有効にしている場合、「常に安全な接続を使用する」機能がデフォルトで有効になります。HTTPページへのアクセス時にHTTPSへのアップグレードを試みる挙動が標準になるため、混在コンテンツや内部のHTTP専用エンドポイントを抱える環境では、事前に接続経路を点検しておくとトラブルを避けられます。Chromeの脆弱性修正の規模感は、Chrome 148で公開された脆弱性79件の解説記事もあわせて参照すると把握しやすくなります。

Adopted Style Sheets対応やMCPサーバー刷新など開発者向けDevToolsの改善点

Chrome 146前後のDevToolsでは、日常的なデバッグワークフローを改善する更新が続いています。代表的なのがAdopted Style SheetsのElementsパネルでの可視化で、Shadow DOMやWeb Componentsのスタイルデバッグが容易になりました。DevTools MCPサーバーもバージョンを重ね、AIエージェント向けの機能が拡充されています。

Adopted Style Sheetsノードの可視化でShadow DOM内CSSデバッグを容易にする変更

DevToolsでは、Adopted Style SheetsがElementsパネルのDOMツリー内に専用の#adopted-style-sheetsノードとしてグループ化表示されるようになりました。従来Adopted Style Sheetsは通常の<style>タグと異なりDOMツリー上に表示されず、Stylesペインで間接的にしか確認できなかったため、デバッグの障壁になっていました。

この変更で、Web ComponentsやShadow DOM内の構築済みスタイルシートを通常のスタイルタグと同じ操作感で検査できます。Stylesペインからのルール編集もリアルタイムに反映されるため、デザインシステムの共有スタイルシートの問題も迅速に特定できます。スタイルの適用順序や優先度の問題を視覚的に追跡できるようになった点は、Web Components重視のアーキテクチャで特に効果的です。

MCPサーバー刷新で追加されたLighthouse統合とLCPデバッグスキルの活用場面

Chrome DevToolsのMCPサーバーは更新を重ね、AIコーディングエージェントから利用できるデバッグ機能が拡充されています。MCPプロトコル経由でLighthouse監査を直接実行できるようになり、パフォーマンスや品質チェックをAIエージェントのワークフローに組み込めます。

また、LCP（Largest Contentful Paint）のデバッグと最適化に特化したスキルや、アクセシビリティの監査・デバッグスキルが追加されています。ストレージ分離されたブラウザコンテキストのサポート、メモリスナップショット取得ツール、ツール記述を最適化してトークン消費を抑える--slimモードなども加わりました。GeminiやClaude Codeなどのエージェントと連携して本番サイトのパフォーマンス最適化を自動化する際に、これらの機能が役立ちます。Chrome本体に統合されたAI機能についてはGemini Nanoの解説記事も参考になります。

Console履歴ナビゲーション改善とGrid Editor・スタックトレースの細部修正

DevToolsのConsoleでは、履歴をナビゲーションする際の操作性が改善されました。以前のコマンドを編集中に上下矢印キーで履歴をブラウズしても、編集中の内容が保持されます。従来は履歴をたどった時点で編集中のコマンドが失われ、入力し直す必要がありました。長いスニペットやfetch呼び出しを扱う際の地味ながら確実な効率改善です。

その他、StylesペインのGrid Editorでgrid-auto-flowのdenseキーワードをチェックボックスで切り替え可能になったほか、Sourcesパネルのスタックトレースアーキテクチャが改修され、ソースマップの遅延読み込みに起因するUIのジャンプやファイル切替の不具合が解消されました。Networkパネルのイニシエーターポップオーバーも改善されたスタックトレースを使用するようになり、リクエストチェーンの追跡信頼性が向上しています。

DLPスキャン拡張やAI Mode連携を含むエンタープライズ管理機能

エンタープライズ管理者向けの機能強化も継続しています。Chrome Enterprise Premiumのデータ損失防止（DLP）機能では大容量・暗号化ファイルのスキャン対応が追加され、AI ModeではGoogle Driveファイルのコンテキスト連携が強化されました。あわせてアクセシビリティフレームワークの移行など、ポリシーの見直しが必要な項目も含まれます。

50MB上限を撤廃したDLPスキャンの大容量・暗号化ファイル対応

Chrome Enterprise Premiumでは、DLP機能とマルウェアスキャン機能が拡張され、従来スキップされていた50MBを超える大容量ファイルと暗号化ファイルもスキャン対象に含まれるようになりました。これまではファイルサイズが50MBを超えた時点でコンテンツスキャンがバイパスされ、大きなファイルを経由したデータ流出のリスクが残っていました。

このアップデートにより、DLPルールによる検出・ブロックが大容量・暗号化ファイルにも適用され、重大なセキュリティギャップが解消されます。証拠保存が設定されたDLPポリシーで最大2GBのファイルをEvidence Lockerに収集・保存する機能は段階的に展開されます。新ポリシーの追加は不要で、Google Admin Consoleで構成済みの既存DLPルールが自動的に大容量・暗号化ファイルにも適用されるため、アップロード・ダウンロード・印刷のルールが設定済みの環境では追加設定なしで恩恵を受けられます。

AI ModeでGoogle Driveファイルをコンテキスト化する機能とポリシー制御

デスクトップ版（macOS・Windows）で、Google DriveファイルをAI Modeのコンテキストとして利用できる機能が追加されました。Google Drive上のドキュメントやスプレッドシートを参照しながら、AI Modeで質問・比較・要約・情報検索を効率的に行えます。Android・iOSでは先行してマルチタブコンテキストやLens連携が強化されています。

エンタープライズ管理者はこの機能をSearchContentSharingSettingsポリシーで制御できます。値を1に設定するとAI Mode機能を無効化でき、より広範なAI機能の制御にはGenAiDefaultSettingsポリシー（値を2に設定）も利用できます。機密情報を扱う部署ではコンテキスト共有を無効化し、一般部門では有効化するといった組織単位の柔軟な運用が可能です。ポリシー変更はGoogle Admin Consoleから適用でき、既存のChrome管理基盤に組み込めます。

UIオートメーション移行とキャッシュ暗号化によるBYOD環境のデータ保護

Windows環境におけるChromeのアクセシビリティフレームワークは、Microsoftの互換性シム経由からChrome自身のUIオートメーションプロバイダへ移行が進められ、UiAutomationProviderEnabledポリシーによる切り替えを経てChrome 147で移行が完了しました。Chrome 147以降はすべてのクライアントが新プロバイダを使用するため、Narrator・Magnifier・Voice Accessや、サードパーティのスクリーンリーダー・自動テストツールがUIオートメーション経由で正常に動作するかを検証しておく必要があります。

セキュリティ面では、デスクトップ版（Linux・macOS・Windows）でキャッシュ暗号化が利用可能になりました。バックグラウンドで透過的に動作し、ブラウザキャッシュをディスク上で暗号化状態に保ちます。CacheEncryptionEnabledポリシーで管理でき、有効・無効の切り替え時にはデータ一貫性のため既存キャッシュが自動的にクリアされます。BYOD（私用端末の業務利用）環境で、物理的なデバイスアクセスによる企業データ漏洩のリスクを軽減します。ストレージIOが高負荷な環境では事前の性能検証が望ましいでしょう。

よくある質問（Chromeのバージョンとアップデート）

Google Chromeの現在の最新バージョンはいくつですか？

2026年7月時点の最新安定版はChrome 150で、2026年6月30日に公開されました。バージョン番号は「150.0.7871.x」の形式です。次のChrome 151は2026年7月28日にリリースが予定されています。

自分のChromeのバージョンを確認する方法は？

アドレスバーにchrome://settings/helpと入力するか、右上の三点メニューから「ヘルプ」→「Google Chromeについて」を選択します。この画面に現在のバージョンが表示され、同時に最新版への更新チェックも自動で実行されます。

Chromeのバージョン履歴（修正履歴）はどこで確認できますか？

各バージョンの修正一覧は「Chrome Releases」ブログ、開発者向けの新機能はChrome for Developersのリリースノート、企業管理者向けのポリシー変更はChrome Enterprise and Educationリリースノートで確認できます。今後のロードマップはChrome Platform Status（chromestatus.com）やChromium Dashboardで追えます。

Chromeのアップデート頻度（リリースサイクル）はどのくらいですか？

現在は原則4週間ごとにメジャーバージョンが更新されます。2026年9月公開のChrome 153からは2週間ごとのサイクルへ短縮される予定です。緊急のセキュリティ修正はメジャー更新を待たず、パッチ番号の更新として随時配信されます。

アップデートしないと何が問題になりますか？

各バージョンには多数のセキュリティ脆弱性の修正が含まれます。たとえばChrome 148では79件の脆弱性が修正されました。更新を放置すると既知の脆弱性を悪用されるリスクが高まるため、更新アイコンが表示されたら速やかに再起動してパッチを適用することを推奨します。

資料請求