開発者が最初に確認すべきWindows Terminal Preview 1.25の全体像と安定版1.24との機能差

開発者が最初に確認すべきWindows Terminal Preview 1.25の全体像と安定版1.24との機能差

Windows Terminal Preview 1.25は、2026年3月5日に一般公開されました。Microsoftは四半期ごとのリリースサイクルを一時的に停止し、信頼性とパフォーマンスの改善に集中した期間を経てからこのバージョンを送り出しています。同時に安定版も1.24へ更新されており、Preview 1.25で先行搭載された機能が段階的に安定版へ移行していく流れが続いています。本セクションでは、1.25の位置づけと安定版との違いを整理し、どちらを導入すべきかを判断するための基礎知識を提供します。

2026年3月リリースの背景にある四半期サイクル一時停止と品質重視への方針転換

Windows Terminalは通常、四半期に1回のペースで新バージョンをリリースしています。しかし1.25のリリースに先立ち、Microsoftは一時的にこのサイクルを停止しました。公式ブログではその理由として、信頼性とパフォーマンスへの集中を挙げています。この方針転換は、ユーザーから寄せられていたクラッシュ報告やスレッド関連のエラー表示など、安定性に関する課題への対応を優先した結果です。

実際に1.25のリリースに先立つサービシングアップデートでは、スレッド間操作のuse-after-free対策や中国語・日本語IMEとの互換性復元といった安定性修正が行われていました。1.25ではそれらに加え、Profile-Guided Optimization（PGO）の再有効化など、パフォーマンスに直結する改善が多数含まれています。新機能の追加だけでなく、既存機能の動作品質を引き上げることに開発リソースを割いた点が、今回のリリースの大きな特徴です。Preview版であっても、基盤の安定性が向上していることは、業務環境での試験導入を検討するうえで重要な判断材料になります。

Preview 1.25の新機能と安定版1.24に含まれる機能の対応表で見る導入判断の基準

Preview 1.25と安定版1.24では搭載機能に明確な差があります。以下の表に、1.25で新たに追加された主要機能と、1.24で安定版として提供される機能を整理しました。どの機能がどちらのバージョンで利用可能かを把握することで、導入判断がしやすくなります。

安定版1.24には、1つ前のPreviewサイクルで検証済みの機能が含まれています。一方、Settings検索やKittyプロトコルといった1.25の目玉機能を使うには、現時点ではPreview版の導入が必要です。

Preview・Stable・Canaryの3チャネル構成と各チャネルの更新頻度・リスク比較

Windows Terminalには3つのリリースチャネルが存在します。最も安定した「Stable（安定版）」、次期安定版の候補機能を先行搭載する「Preview（プレビュー版）」、そして最新のコミットがほぼリアルタイムで反映される「Canary」です。Stableは四半期に1回の更新で、企業のIT管理者が検証を行いやすいペースを維持しています。Previewは同じく四半期更新ですが、Stableより1バージョン先行した機能を搭載しており、新機能の早期評価に適しています。

Canaryは開発ビルドに近い位置づけで、GitHubリポジトリから直接取得できます。日常的な業務利用には向きませんが、特定のバグ修正が早期に取り込まれているかを確認する用途には有用です。チャネル選択の基本方針としては、業務利用はStable、新機能の事前評価はPreview、開発参加やバグ追跡はCanaryという使い分けが推奨されます。

Windows 10とWindows 11で異なる動作要件とバージョン1.25の対応OS範囲

Windows Terminal Preview 1.25は、Windows 10およびWindows 11の両方で動作します。ただし、Windows 10ではビルド18362.0以上（バージョン1903、2019年5月更新以降）が必要です。これより古いWindows 10環境ではMicrosoft Storeでのインストール時にシステム要件エラーが表示されます。Windows 11ではプレインストール版が標準搭載されているため、Storeからの更新だけで最新版に移行可能です。

なお、非パッケージ版（ZIP配布）のポータブルモードはWindows 10バージョン2004（ビルド19041）以降でのみ動作する制約があります。業務端末のOS状況が混在している場合は、展開形態ごとの要件を事前に確認しておくことが重要です。Windows 11 22H2以降ではWindows TerminalがWindows Consoleに代わるデフォルトのターミナルとなっており、OS標準としての位置づけがさらに強まっています。

Preview導入が適する開発者像と安定版で十分なケースの判断基準3パターン

Preview 1.25の導入が特に有効なのは、以下の3つのパターンに該当する開発者です。第一に、Claude CodeやGitHub Copilot CLIなどエージェント系コマンドラインツールを日常的に使用しており、Shift+Enterの正確な送信が必要な場合です。Kittyプロトコル対応により、これらのツールとの互換性が大きく改善されます。第二に、Settings UIの検索やActionsの一括編集を通じて、設定管理の効率化を図りたい場合です。JSON手動編集の手間が大幅に減ります。

第三に、大量のログ出力を伴うCI/CD環境やTUIアプリを多用しており、Kittyプロトコルによるキー入力精度の改善やSettings検索によるワークフロー効率化を総合的に活用したい場合です。なおPGO再有効化によるスループット改善は安定版1.24にもバックポートされているため、パフォーマンス目的のみでPreview版を選ぶ必要はありません。逆に、安定版1.24で十分なケースとしては、現在の機能に不足を感じておらず、設定変更もほとんど行わない運用が挙げられます。Preview版は安定版より不具合リスクがわずかに高いため、業務継続性を最優先する環境ではStableチャネルの維持が合理的な選択です。

設定画面の検索UIとActionsエディタ刷新がもたらす日常オペレーションの時短効果

Windows Terminal Preview 1.25で最も実用的なインパクトを持つのが、Settings画面への検索機能追加とActionsページの全面刷新です。従来は目的の設定項目にたどり着くまでに複数のカテゴリを順に開く必要がありましたが、検索バーの導入により名前で直接アクセスできるようになりました。Actionsの編集もJSON手動編集からGUIベースに移行し、設定管理にかかる時間が大幅に短縮されています。

Settings検索バーが対象とする6カテゴリとプロファイル重複表示の仕様上の注意

新しいSettings検索バーは、単なるキーワードフィルターではなく、Settings画面内のほぼすべての項目をインデックス化しています。検索対象は、ビルトイン設定、カラースキーム、プロファイル、拡張機能（Extensions）、新しいタブメニューの項目、そしてActionsの6カテゴリにわたります。設定名の一部を入力するだけで候補が即座に絞り込まれるため、目的の項目を探す手間が大きく減ります。

ただし注意すべき仕様があります。特定のプロファイルに限定されない汎用設定（たとえばフォントサイズやカーソル形状など）は、該当するすべてのプロファイルで検索結果に表示されます。プロファイルを多数作成している環境では、同一設定が複数回表示されることがあるため、編集対象のプロファイルを確認してから操作する習慣が求められます。この仕様は設計上の意図的な動作であり、バグではありません。検索対象のカテゴリ幅が広い分、結果一覧の中から目的の項目を的確に選択するリテラシーが必要になります。

旧JSON手動編集と新GUIエディタの操作ステップ数比較で見える作業時間の削減幅

従来のWindows Terminalでは、キーバインドの変更やコマンドパレットへのカスタムエントリ追加を行うには、settings.jsonを直接テキストエディタで開いて編集する必要がありました。具体的な操作ステップとしては、Settings画面からJSONファイルを開く、該当セクションを検索する、JSON構文を正しく記述する、保存してTerminalを再読み込みする、という最低4ステップが必要でした。

1.25の新しいGUIエディタでは、Settings画面のActionsページから直接、アクション名・キーバインド・コマンドパレット表示名をフォーム形式で入力・編集できます。JSON構文エラーのリスクがなくなり、保存と同時に反映されるため、操作ステップは実質2ステップに短縮されます。特にキーバインドを頻繁にカスタマイズする開発者にとっては、1回あたり数分の作業時間削減が積み重なり、月単位で見れば無視できない効率改善につながります。

Actionsページ全面書き換えで可能になったキーバインド・コマンドパレット一括管理の手順

Preview 1.25では、SettingsのActionsページが完全に書き直されました。従来のActionsページは基本的なキーバインドの変更のみをサポートしており、コマンドパレットのエントリやアクションの詳細設定はJSONでの編集が不可欠でした。新しいActionsページでは、すべてのアクション定義をGUI上で作成・編集・削除できます。

操作手順としては、まずSettingsを開き、左メニューからActionsを選択します。既存のアクション一覧が表示されるので、編集したい項目をクリックするとインラインエディタが展開されます。ここでアクションの種類、対象コマンド、割り当てるキーバインド、コマンドパレットでの表示名を一画面で設定できます。新しいアクションを追加する場合も同じ画面からフォームを使って登録できるため、JSONの構造を覚える必要がなくなりました。複数のアクションを連続して編集する際の切り替えもスムーズで、一括管理の利便性が格段に向上しています。

カラーピッカーがダイアログからフライアウトに変更された背景と直接入力対応の利点

Settings UIのカラーピッカーが、従来の全画面ダイアログからフライアウト（軽量ポップアップ）形式に変更されました。この変更は1.25 Previewで導入されたものですが、安定版1.24にもバックポートされています。色を選択する際に画面遷移が発生せず、設定画面の文脈を保ったまま色の調整が行えます。さらに、フライアウト内でカラーコードの直接入力が可能になった点も重要な改善です。

従来のダイアログ形式では、カラーピッカーのスライダーで微調整するか、別途コードをコピーして貼り付ける必要がありました。ブランドカラーや既存テーマのカラーコードが手元にある場合、16進数値を直接入力したほうが正確かつ高速です。この変更はSettings UI全体の操作感を軽量化する設計思想の一部であり、特にカラースキームを自作している開発者やデザイナーにとって日常的な恩恵をもたらします。細かい改善ですが、Settings画面を頻繁に操作するユーザーほど体感的な違いを実感できるでしょう。テーマ作成やカラースキーム調整を繰り返す場面では、ダイアログの開閉が積み重なるストレスから解放される効果は無視できません。

拡張機能ページ（Extensions）で追加プロファイルやカラースキームを一覧管理する実務例

安定版1.24から搭載されたExtensions専用ページは、Preview 1.25でも引き続き利用できます。このページでは、サードパーティの拡張機能やフラグメント（fragment）によって追加されたプロファイル、カラースキーム、アクションを一覧で確認できます。従来はどの拡張が何を追加したのかを把握するにはsettings.json内のフラグメント情報を手動で確認する必要がありました。

実務での活用例として、チーム共通のカラースキームやプロファイルをフラグメントとして配布している場合が挙げられます。Extensionsページを開けば、現在適用されているフラグメントの一覧とそれぞれが追加した設定項目を即座に把握できます。不要な拡張が残っていないかの棚卸しや、新しいフラグメント導入後の影響確認も容易になります。チーム内で設定ファイルを共有する運用をしている開発組織にとっては、管理コストの低減に直結する機能です。

Kittyキーボードプロトコル対応で変わるキー入力の精度とエージェント系CLIツールとの相性

Windows Terminal Preview 1.25の注目機能のひとつが、Kittyキーボードプロトコルへのビルトイン対応です。ターミナルにおけるキー入力処理は長年にわたり曖昧性を抱えており、特定のキーの組み合わせが同一のエスケープシーケンスに変換されてしまう問題がありました。Kittyプロトコルはこの問題を根本から解決する仕様であり、最新のCLIツールとの互換性を大きく向上させます。

従来のターミナルキー入力が抱えていたEscとCtrl+[の曖昧性問題の具体例

従来のターミナルでは、物理的に異なるキー操作が同一のバイト列としてアプリケーションに送信される問題が多数存在していました。代表的な例がEscキーとCtrl+[の組み合わせです。どちらも同じバイト（0x1B）を送信するため、アプリケーション側ではユーザーがどちらのキーを押したのかを区別できませんでした。同様に、TabキーとCtrl+Iも同一のバイトとして処理されます。

この曖昧性は、Neovimなどのテキストエディタで深刻な問題を引き起こしていました。たとえばEscキーの単独押下を検出するために、アプリケーション側ではタイミングベースの推測（一定時間内に後続のバイトが来なければEsc単独と判定する）を行っており、ネットワーク遅延がある環境では誤判定が頻繁に発生していました。複数の修飾キーの組み合わせも正しく伝達できないケースが多く、Shift+AltやCtrl+Alt以外の組み合わせは実質的に使用不可能な状態でした。

Kittyプロトコルが採用するCSI uシーケンスの仕組みと対応する修飾キー8種の一覧

Kittyキーボードプロトコルは、従来のエスケープシーケンスに代わる構造化された形式としてCSI uシーケンスを採用しています。このシーケンスでは、物理キーのコード、修飾キーのフラグ、イベントタイプ（押下・リリース・リピート）を個別のフィールドとして送信します。これにより、EscとCtrl+[、TabとCtrl+Iといった従来区別不可能だったキー操作を完全に識別できるようになります。

従来のターミナルでは実質的にShift・Alt・Ctrlの3種類しか修飾キーとして扱えませんでしたが、Kittyプロトコルでは8種類の修飾キー状態を同時に報告できます。これにより、キーバインドの設計自由度が飛躍的に向上します。

Shift+Enter送信が可能になったことでClaude CodeやCopilot CLIとの連携が改善する理由

Kittyプロトコル対応がもたらす最も実用的な恩恵のひとつが、Shift+Enterの正確な送信です。従来のターミナルではEnterとShift+Enterを区別できなかったため、エージェント系CLIツールでの操作に制約がありました。たとえばClaude Codeのような対話型コマンドラインツールでは、Shift+Enterで入力中のテキストに改行を挿入し、Enterで送信するという操作体系が一般的です。

この区別ができない環境では、複数行の入力を一度に送信することが困難で、ワークフローに余計な手順が生じていました。Windows Terminal 1.25でKittyプロトコルが有効になると、Shift+Enterは独自のCSI uシーケンスとして送信されるため、アプリケーション側が正確にイベントを識別できます。公式ブログでもこの改善が「モダンなエージェント系コマンドラインツールとのインタラクション向上」として言及されており、AI支援型の開発ツールを積極的に活用する開発者にとって実質的な利便性向上をもたらします。

レガシー互換性を維持するオプトイン方式の設計とアプリ側の対応状況確認方法

Kittyプロトコルは、既存のアプリケーションとの互換性を壊さないようオプトイン方式で設計されています。ターミナルがKittyプロトコルに対応しているだけでは動作が変わらず、アプリケーション側が明示的にプロトコルの有効化を要求（DECプライベートモードで設定を送信）した場合にのみ、新しいシーケンスが使用されます。つまり、既存のシェルスクリプトやレガシーなCLIツールの動作には一切影響しません。

アプリケーションがKittyプロトコルに対応しているかを確認するには、各ツールのドキュメントやリリースノートを参照するのが最も確実です。対応済みのツールとしては、Neovim、kittyターミナル自体、foot、WezTermなどが知られています。Emacsではkkp.elパッケージを導入することで対応可能です。Windows Terminal 1.25での対応により、Windowsプラットフォームでもこれらのツールがプロトコルの恩恵を受けられる環境が整いました。

Neovim・Emacsなど主要TUIアプリでKittyプロトコルを有効化する際の設定差異と注意点

Kittyプロトコルを実際に活用するには、ターミナル側の対応に加えてアプリケーション側の設定も必要です。Neovimでは比較的早い段階からKittyプロトコルに対応しており、最新バージョンではターミナルがプロトコルをサポートしていることを検出すると自動的に有効化されます。特別な設定を追加しなくても、Windows Terminal 1.25上で動作するNeovimは自動的にCSI uシーケンスの恩恵を受けられます。

一方、Emacsの場合はkkp.elパッケージの導入が必要です。(global-kkp-mode +1)を設定ファイルに追記し、有効化する拡張レベル（disambiguate-escape-codes、report-alternate-keysなど）を選択します。注意点として、disambiguate-escape-codesのみを有効にした場合、シフトキーの組み合わせが従来と異なるキーコードで報告されるため、既存のキーバインド設定との競合が発生する可能性があります。導入前にkkp-statusコマンドでプロトコルの対応状況を確認し、段階的に拡張レベルを上げていくアプローチが安全です。

PGO再有効化による10〜25%スループット向上とセッション管理改善の実測評価

Preview 1.25では、パフォーマンスと安定性の両面で大幅な改善が施されています。特にProfile-Guided Optimization（PGO）の再有効化によるI/Oスループットの向上と、管理者権限・通常権限ウィンドウ間のセッション管理問題の解消は、日常利用における体感品質を直接的に左右する変更です。なお、PGOの再有効化は同時リリースの安定版1.24にもバックポートされており、Preview版に限定された改善ではありません。数値的な指標と実際の利用シーンを紐づけて、その効果を検証します。

Profile-Guided Optimizationの仕組みとWindows Terminalで一時無効化されていた経緯

Profile-Guided Optimization（PGO）は、コンパイラがプログラムの実行プロファイル（実行頻度の高い関数やコードパス）を収集し、その情報をもとにバイナリの最適化を行う手法です。ホットパスのインライン化や分岐予測の最適化が実行時データに基づいて行われるため、一般的な最適化よりも高い効果が得られます。Windows TerminalはC++で実装されたネイティブアプリケーションであり、PGOとの相性が良い構造です。

しかし、ある時点でPGOはWindows Terminalのビルドプロセスから一時的に無効化されていました。具体的な理由は公式には詳述されていませんが、ビルドパイプラインの変更や信頼性向上のための作業期間中に一旦外されたと推測されます。1.25ではPGOが再度有効化され、GitHubリリースノートでは10〜25%のI/Oスループット向上が見込まれると記載されています（公式ブログでは10〜20%と表記）。この改善は安定版1.24にもバックポートされているため、Preview版を使わなくても恩恵を受けられます。ビルド時最適化であり、ユーザー側で追加の設定は不要です。

I/Oスループット10〜25%改善がログ大量出力やCI結果表示で体感できる場面の具体例

I/Oスループットの10〜25%改善は、抽象的な数値としてはピンとこないかもしれません。しかし実際の開発作業では、この差が明確に体感できる場面があります。たとえば、DockerコンテナのビルドログやCI/CDパイプラインの実行結果をターミナル上でリアルタイムに確認する場面です。大量のテキストが高速にスクロールされる状況では、スループットの差がそのまま表示の滑らかさに反映されます。

また、catコマンドで大容量のログファイルを出力する場合や、grepで大量のマッチ結果を表示する場合にも効果が現れます。特にカーソルブリンク用のタイマー使用の削減やSixel画像パースの改善といった内部最適化も相まって、重いターミナル操作全般での応答性が向上しています。日常的に数万行規模のログを扱う開発者やSREにとっては、PGO再有効化は体感に直結する改善と言えるでしょう。ビルドやデプロイ中にターミナルを注視し続ける作業スタイルであれば、スクロールの滑らかさの違いは集中力の維持にも貢献します。

管理者権限ウィンドウと通常権限ウィンドウのセッション相互上書き問題の解消内容

Windows Terminalには、前回のウィンドウ配置やタブ構成を再起動後に復元するセッション永続化機能があります。しかし従来のバージョンでは、管理者権限（Elevated）で起動したウィンドウと通常権限（Non-elevated）で起動したウィンドウが、互いのセッションデータを上書きしてしまう問題がありました。これにより、管理者権限で作業した後に通常権限で再起動すると、前回の通常権限セッションが失われるという不便が生じていました。

Preview 1.25では、管理者権限と通常権限のセッションデータが分離保存されるように修正されました。再起動後は、それぞれの権限レベルに対応するセッションが正しく復元されます。サーバー管理など管理者権限と通常権限を頻繁に切り替える運用を行っている開発者にとっては、毎回のウィンドウ再構築の手間がなくなる大きな改善です。複数タブで異なる環境を開いた状態を維持できるため、作業再開までの時間が大幅に短縮されます。

レイアウトのみ保持する新しいセッション永続化オプションと従来方式との違い

1.25では、セッション永続化に新しいオプションが追加されました。従来の方式ではウィンドウのレイアウト（タブの数や配置）に加えて、各タブのターミナル出力内容もすべて保存・復元されていました。新オプションでは、レイアウト情報のみを保持し、ターミナルの出力内容は破棄する設定が可能です。

この設定は、セキュリティやプライバシーの観点から出力内容を永続化したくない場合に有用です。たとえば、認証情報やAPIキーが表示されたセッションの内容がディスク上に残ることを避けたいケースが該当します。また、セッションデータのサイズが大きくなることで起動速度に影響が出る環境でも、レイアウトのみの保持は実用的な選択肢です。設定はSettings UIまたはsettings.jsonから変更できます。ウィンドウ構成は維持しつつ、出力内容はクリーンな状態で再スタートしたいという運用ニーズに応える機能です。特に共有端末やデモ環境では、前回の操作履歴を見せたくないケースも多く、レイアウト限定の永続化はセキュリティと利便性を両立させる実用的な選択肢となります。

検索中の画面ジャンプ問題修正やMark Mode改善など操作安定性に関わるバグ修正5件

パフォーマンス改善と並行して、日常操作の安定性に関わる複数のバグが修正されています。最も多くのユーザーに影響していたのが、ターミナルで検索を実行中に出力が続いていると画面が激しくジャンプする問題です。ログ出力を監視しながらキーワード検索を行う場面で発生しやすく、作業効率を著しく低下させていました。1.25ではこの問題が解消されています。

そのほかに修正されたバグとしては、検索がアクティブな状態でMark Modeに入ると現在の検索結果が正しくマークされるようになった点、Mark Mode開始時のカーソル位置がビューポート上部ではなくスクロール領域の先頭に配置されるようになった点、コマンドパレットでプレビューされたアクションが閉じた後も残り続ける問題の解消、そして「Move tab forward」と「Move tab backward」のエントリが左右の方向を明示するようになった点があります。いずれも日常的な操作で遭遇しやすい問題であり、Preview版の成熟度を高める修正です。

CJK環境ユーザーが押さえるべきUnicode曖昧幅設定とVS Codeカラースキーム同梱の実務影響

日本語をはじめとするCJK（中国語・日本語・韓国語）環境でWindows Terminalを使用する開発者にとって、1.25には特に注目すべき変更が含まれています。Unicode文字の表示幅に関する新しい設定オプション、VS Codeとの視覚的統一を図るカラースキームの同梱、そしてコミュニティ翻訳の拡大など、多言語環境での利便性に直結する改善が複数追加されています。

Unicode East Asian Ambiguous幅をnarrowとwideで切り替えるJSON設定の書き方と既定値

Unicode規格では、一部の文字が「East Asian Ambiguous」という幅カテゴリに分類されています。この分類に含まれる文字は、CJK環境では全角（2カラム幅）で表示されることが多い一方、欧米環境では半角（1カラム幅）で表示されます。Windows Terminal 1.25では、この曖昧幅文字の表示カラム数をユーザーが明示的に設定できるようになりました。

設定はグローバル設定としてsettings.jsonに記述します。キーはcompatibility.ambiguousWidthで、値は"narrow"（既定値、1カラム）または"wide"（2カラム）のいずれかを指定します。この設定は文字のレンダリングサイズ自体を変更するものではなく、ターミナルが文字に割り当てる論理的なカラム幅のみを変更します。そのため、見た目は変わらないものの、カーソル位置の計算やテキスト配置の整合性に影響します。日本語環境で罫線文字や記号が半角として扱われて表示がずれていた問題に対処する際に有用です。

日本語・中国語コンソールアプリで表示崩れが発生する条件とwide設定による回避手順

Unicode Ambiguous幅の不一致が原因で表示崩れが発生するのは、主にCJKロケールで動作することを前提に設計されたコンソールアプリケーションを使用する場合です。たとえば、罫線文字（┌、─、└など）や一部の記号（○、■、※など）をAmbiguous幅として持つ文字は、アプリ側が2カラム幅を期待して配置計算を行っているのに対し、ターミナル側が1カラム幅として処理すると、テーブルの罫線がずれたり文字が重なったりします。

この問題を回避するには、settings.jsonを開き、グローバル設定セクションに"compatibility": { "ambiguousWidth": "wide" }を追加します。ただし公式リリースノートでも注意喚起されているように、wide設定はCJK環境向けの互換性オプションであり、CJK以外のアプリケーションでは逆にグラフィカルアーティファクト（表示の乱れ）が発生する可能性があります。普段使用するアプリケーションの種類に応じて設定を切り替えるか、プロファイル単位での設定分離を検討するのが実用的な対処法です。

VS Code Modern Dark/Lightカラースキーム同梱によるエディタ・ターミナル間の統一効果

Preview 1.25には、VS Code Modern DarkおよびVS Code Modern Lightという2つのカラースキームが新たに同梱されました。これらはVisual Studio Codeで標準採用されているモダンテーマの配色と一致するよう設計されています。VS Codeの統合ターミナルとWindows Terminalを併用する開発者にとって、両者の色味が統一されることで視覚的な一貫性が確保されます。

カラースキームの不一致は、単なる美観の問題にとどまりません。エラーメッセージの赤、成功表示の緑、警告の黄色といった意味を持つ色が環境間で異なると、出力内容の視認性が低下し、判断ミスにつながるリスクがあります。VS Code Modern Dark/Lightスキームの同梱により、Settings画面のカラースキーム選択から直接適用するだけで、追加のカスタマイズなしにエディタとターミナルの配色を揃えられます。チーム全体で統一したカラースキームを使用する運用ルールを設ける場合にも、標準同梱のスキームであれば展開が容易です。

セルビア語・ウクライナ語コミュニティ翻訳追加と多言語コマンドパレット検索の動作仕様

Windows Terminal 1.25では、コミュニティ貢献によるセルビア語（キリル文字）とウクライナ語の翻訳が初めて追加されました。これらはコミュニティメンテナンスの翻訳として位置づけられており、今後も翻訳対象言語の拡大が見込まれます。日本語のUIは以前から対応済みですが、多言語対応の進展はプロジェクト全体の国際化の方向性を示しています。

関連して、安定版1.24で導入されたコマンドパレットの多言語検索機能についても触れておきます。この機能は、システム言語が英語以外に設定されている環境でも、英語のキーワードでコマンドパレットのエントリを検索できるようにするものです。たとえば日本語環境で「settings」と入力すれば「設定」に関連するエントリがヒットします。英語の技術文書を参照しながら操作する場面では、コマンド名を日本語に変換する手間がなくなるため、検索効率が向上します。この機能はPreview 1.25でも引き続き利用可能です。

wt -posの単一引数対応やconpty改善などCJK環境に波及するその他の変更点まとめ

Preview 1.25には、上記の主要機能以外にもCJK環境に影響する小規模な変更が含まれています。まず、コマンドラインからウィンドウ位置を指定するwt -posオプションが単一引数に対応しました。従来はwt -pos 40,40のように2つの値を指定する必要がありましたが、wt -pos 40と書けば40,40として解釈されるようになり、スクリプトでの記述が簡略化されます。

また、conpty（Console Pseudo Terminal）においてリサイズ後にカーソル位置を再取得する処理が追加されました。これにより、PowerShellなどGetConsoleCursorPositionを呼び出すプログラムでリサイズ後のカーソル位置がずれる問題が軽減されます。なお、中国語や日本語のIME（入力メソッドエディタ）との互換性については、1.25に先立つ1.24サービシングアップデート（v1.24.10212.0）で既に復元されており、1.25ではその修正が引き継がれています。これらの修正は個別には小さいものの、CJK環境での日常利用における安定性向上に寄与する変更群です。

Microsoft Store・GitHub・WinGetからのインストール手順と安定版との併用時の注意点

Windows Terminal Preview 1.25は、Microsoft Store、GitHub Releases、WinGetの3つの方法で入手できます。それぞれの導入手順には固有の利点と注意点があり、利用環境や運用方針に応じた選択が求められます。また、安定版との併用には設定ファイルの共有やエイリアスの競合といった注意点があるため、事前に理解しておくことが重要です。

Microsoft Storeからの導入で自動更新を確保する手順と1.25ロールアウト遅延の現状

Microsoft Storeからのインストールは、最も手軽な導入方法です。Storeアプリを開き「Windows Terminal Preview」を検索して「入手」をクリックするだけで導入が完了します。Store経由で導入した場合、以降のアップデートは自動的に適用されるため、手動での更新作業が不要です。チーム内の端末を一括管理する場合にも、Storeの自動更新に委ねることで運用負荷を抑えられます。

ただし、1.25のリリースにおいてはStore経由のロールアウトに遅延が発生していたことが公式に報告されています。Microsoft側でStoreの配信担当チームと原因を追跡中とのことですが、2026年3月5日時点ではGitHubおよびWinGetでは一般入手可能な状態でした。Storeからの配信が遅れる場合は、GitHubまたはWinGetからの手動導入で先行入手する選択肢もあります。自動更新の利便性を重視するならStore導入が最適ですが、最新版の即時入手を優先するなら他の手段も併用する柔軟性が求められます。

GitHub Releasesページからmsixbundleを手動ダウンロードしてインストールする5ステップ

GitHub Releasesからの手動インストールは、Storeにアクセスできない環境や特定バージョンを固定したい場合に適しています。手順は以下のとおりです。

1. ブラウザでGitHubのmicrosoft/terminalリポジトリのReleasesページを開く
2. 最新のPreviewリリース（タイトルに「Preview」と記載）を確認する
3. 「Assets」セクションを展開し、拡張子が.msixbundleのファイルをクリックしてダウンロードする
4. ダウンロードしたmsixbundleファイルをダブルクリックしてインストーラーを起動する
5. 画面の指示に従いインストールを完了する

msixbundleでのインストール時には、依存パッケージのダウンロードのためにネットワークアクセスが必要になる場合があります。なお、GitHub経由で導入した場合はStoreを通じた自動更新が適用されるため、初回のみ手動で以降は自動更新される点を覚えておくと便利です。

WinGetコマンド1行でPreview版を導入する方法とバージョン固定オプションの指定例

WinGet（Windows Package Manager）を使えば、コマンド1行でPreview版を導入できます。PowerShellまたはコマンドプロンプトで以下のコマンドを実行するだけです。

winget install --id Microsoft.WindowsTerminal.Preview

このコマンドにより、WinGetリポジトリから最新のPreview版が自動的にダウンロード・インストールされます。特定のバージョンを指定してインストールしたい場合は、--versionオプションを使用します。たとえばwinget install --id Microsoft.WindowsTerminal.Preview --version 1.25.622.0とすれば、そのバージョンに固定した導入が可能です。企業環境でバージョン管理を厳密に行いたい場合や、アップグレード前にテスト環境で特定バージョンを検証したい場合に有用な手法です。WinGetはスクリプトとの相性もよく、端末のセットアップ自動化に組み込みやすいメリットがあります。

パッケージ版・非パッケージ版・ポータブル版の3配布形態が持つ設定共有範囲の違い

Windows Terminalの配布形態は、パッケージ版（msixbundle / Microsoft Store）、非パッケージ版（ZIP展開）、ポータブル版（非パッケージ版のバリアント）の3種類に大別されます。それぞれ設定ファイルの保存先と共有範囲が異なるため、複数バージョンを併用する環境では事前の理解が不可欠です。

特に注意が必要なのは非パッケージ版です。複数の非パッケージ版を同時に起動している場合、一方で行った設定変更が他方にも即座に反映されます。設定を独立させたい場合はポータブル版への変換が必要で、インストールフォルダに.portableというマーカーファイルを作成することでポータブルモードに切り替えられます。

安定版とPreview版を同一端末に共存させるときのwt.exeエイリアス競合と切り替え設定

パッケージ版の安定版とPreview版は、同一端末にサイドバイサイドでインストールできます。スタートメニューには「Windows Terminal」と「Windows Terminal Preview」の2つが登録され、それぞれ独立して起動可能です。ただし、両者はアプリ実行エイリアスとして同じwt.exeを使用するため、コマンドラインからwtと入力した際にどちらが起動するかは設定に依存します。

エイリアスの切り替えは、Windowsの「設定 → アプリ → アプリの詳細設定 → アプリ実行エイリアス」で行います。ここで「Windows Terminal」と「Windows Terminal Preview」のそれぞれについてエイリアスのオン/オフを設定できますが、両方を同時にオンにすることはできません。自動化スクリプトでwtコマンドを使用している場合は、どちらのバージョンがエイリアスに紐づいているかを確認しておかないと、意図しないバージョンで起動する問題が発生します。明示的にPreview版を起動したい場合は、スタートメニューのショートカットや実行ファイルのフルパスを直接指定する方法が確実です。

Preview 1.25導入後に確認すべきバグ修正一覧と既知の不具合への対処法

Preview 1.25は多数のバグ修正を含んでいますが、Previewリリースである以上、未解決の不具合や新たに報告される問題も存在します。導入後に安定した環境を維持するためには、修正済みのバグと既知の問題の両方を把握しておくことが重要です。本セクションでは、影響範囲の大きいバグ修正とセキュリティ改善、そして現時点で確認されている未解決事項への対応策を整理します。

下線カラー描画不正やBroadcastモード貼り付け失敗など修正済み不具合7件の影響範囲

Preview 1.25で修正された主要な不具合は以下の7件です。テキスト選択時に下線のカラーが正しくない色で描画される問題、Broadcastモードでのテキスト貼り付け時に一部の文字が消失する問題、管理者権限と通常権限ウィンドウのセッション相互上書き、検索中の画面ジャンプ、コマンドパレットでのプレビュー済みアクション残留、Mark Mode開始時のカーソル位置不正、そしてタブ移動コマンドの方向表示欠如です。

これらの不具合は日常的な操作で遭遇する可能性が高いものばかりです。特にBroadcastモードの貼り付け問題は、複数のサーバーに同時にコマンドを送信する運用で実害が生じていました。下線カラーの問題は、LSPのエラー表示やリンクのハイライトなど色による情報伝達に影響していたため、ターミナル上でコーディングを行う開発者への恩恵が大きい修正です。セッション相互上書きの解消は前述のとおりで、権限切り替えを頻繁に行う管理者にとって長らく待ち望まれていた修正でした。

OSC 52クリップボード書き込みのフォーカス制限が加わったセキュリティ改善の背景

Preview 1.25では、OSC 52エスケープシーケンスによるクリップボード書き込みに対して、ウィンドウがフォーカスされている場合のみ許可するという制限が追加されました。OSC 52はターミナル上のアプリケーションがシステムクリップボードにテキストを書き込むためのエスケープシーケンスですが、この機能が悪用されると、バックグラウンドのターミナルウィンドウからユーザーの知らないうちにクリップボードの内容を書き換えられるリスクがありました。

いわゆるクリップボードハイジャック攻撃の一種で、悪意のあるスクリプトを通じてクリップボードに偽のコマンドやURLを仕込む手法が知られていました。フォーカス制限の導入により、ユーザーがアクティブに操作しているウィンドウ以外からのクリップボード書き込みがブロックされるため、この攻撃ベクトルが大幅に縮小されます。セキュリティ意識の高い環境では特に重要な改善であり、Preview版であっても早期に適用する価値がある変更です。

conhostへの新Atlasエンジン提供とレガシーレンダリングのボールドフォント対応の詳細

Windows Terminal 1.25に関連するconhost（従来のWindowsコンソールホスト）への変更も注目に値します。conhostの新Atlasレンダリングエンジンが、レジストリキーHKCU\Console配下のUseDx（DWORD型、値1で有効化）で利用可能になりました。Atlasエンジンはハードウェアアクセラレーションを活用した高性能なテキストレンダリングを提供します。

また、conhostの従来のレンダリングエンジンにボールドフォントのサポートが追加されました。これはコミュニティ貢献による改善で、レガシーコンソールアプリケーションでもボールド表示が正しく反映されるようになります。これらの変更はWindows Terminal自体ではなくconhostに対するものですが、Windows Insiderプログラムの将来のビルドで提供される可能性があるとリリースノートに記載されており、ターミナルエコシステム全体の品質向上に寄与する改善です。conhostを直接使用する場面がある開発者にとっては、注目しておくべき動向です。

タブ移動時のクラッシュやXAMLフォーカス例外など未解決報告への暫定ワークアラウンド

Preview 1.25では多くのバグが修正されましたが、一部の問題は依然として報告されています。特にGitHub Issuesで継続的に追跡されている問題として、タブを別のウィンドウに移動する際にクラッシュが発生するケースがあります。この問題はSSH接続中のタブで特に発生しやすく、クラッシュ後にSSHセッションが孤立プロセスとして残る場合があります。

暫定的な対処法としては、タブ移動を行う前に重要な作業を保存し、SSH接続中のタブについてはウィンドウ間移動を避けることが推奨されます。XAMLフォーカス関連のクラッシュについてはスペキュラティブフィックス（推定による修正）が適用されていますが、完全には解消されていない可能性があります。クラッシュが頻発する場合は、Settings UIでの操作を減らしsettings.jsonの直接編集に切り替えることで回避できるケースもあります。いずれの問題も開発チームが認識しており、次回以降のリリースでの修正が期待されます。

次回アップデートまでにGitHub Issuesで追跡すべき注目チケット5選と報告の書き方

Preview 1.25を業務環境で使用する場合、GitHub Issuesの動向を定期的にチェックすることで、影響の大きいバグへの早期対応が可能になります。特に追跡すべきチケットとしては、タブのウィンドウ間移動時のクラッシュ、XAMLフォーカス例外、Store経由のロールアウト遅延、Kittyプロトコル対応における特定キーの組み合わせでの未対応ケース、そしてセッション復元が正常に動作しない環境固有の問題が挙げられます。

バグを発見した場合にGitHub Issuesへ報告する際は、以下の情報を含めることで開発チームの対応が迅速化します。Windows Terminalのバージョン番号（Settingsの「About」から確認可能）、Windowsビルド番号、再現手順の詳細、期待される動作と実際の動作、そしてスクリーンショットやログがあれば添付します。テンプレートに沿って記載するとトリアージが早くなります。コミュニティからの正確なバグ報告はWindows Terminalの品質向上に直結するため、Previewユーザーとして積極的にフィードバックを提供することが推奨されます。