CLIツール
microsoft/terminal avatar
microsoft/terminal

Windows Terminalは端末とコンソールの二つの系譜を束ねる

新しい Windows ターミナルと元の Windows コンソール ホストがすべて同じ場所にあります。

スター 104,900フォーク 9,600C++MIT
GitHub

ひと目でわかる

これは何?
Windows Terminal、Preview、conhost.exe、共有コンポーネントを同じリポジトリで扱うMicrosoftのC++プロジェクトを、導入版と開発環境から読む。
誰に向いている?
Windows Terminalは、タブ、Unicode、テーマ、複数のシェルを一つの端末アプリで扱いたいWindows利用者に向きます。安定版、Preview、Canary、手動インストールでは更新と安定性が異なるため、用途ごとに版を固定してください。
商用利用できる?
できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
今もメンテナンスされている?
されています。最後のコミットは 1 日前です。
何の言語で書かれている?
主に C++ です(GitHub の言語統計による)。

回答はプロジェクトの GitHub データ(最終同期:2026年9月15日)と当サイトの分析に基づくもので、法的助言ではありません。

オープンソース詳細解説

一つのリポジトリに端末の世代を置く

microsoft/terminalは、Windows TerminalとWindows Terminal Preview、従来のWindowsコンソールホストconhost.exe、二つのプロジェクトが共有する部品、ColorTool、Windows Console APIの利用例を収めています。新しい端末アプリだけのリポジトリではなく、既存のWindowsコマンドライン基盤とその上のUIを同じ場所で開発する構成です。関連先としてTerminal文書、Console API文書、Cascadia Codeフォントが案内されています。

conhost.exeはコンソールAPIサーバー、入力エンジン、描画エンジン、ユーザー設定を担う従来の基盤です。後方互換性を保ちながらタブ、Unicode、絵文字などを扱う必要から、Terminalが別の現代的なUIとして作られました。DirectWriteの文字処理、UTF-16とUTF-8のバッファ、VTパーサーなどを共有するというREADMEの説明から、二つは独立製品ではなく共通部品を持つ関係だと分かります。

安定版はMicrosoft Storeを入口にする

Windows TerminalにはWindows 10 2004、ビルド19041以降が必要です。READMEが推奨する導入先はMicrosoft Storeで、新しいビルドが出たときの自動更新を利用できます。Storeを使えない場合はGitHub ReleasesからMicrosoft.WindowsTerminal_<versionNumber>.msixbundleを取得し、ダブルクリックするかPowerShellのAdd-AppxPackageでインストールします。

手動導入では自動更新されず、古いWindows 10ではVC++ v14 Desktop Framework Packageが必要になる場合があります。wingetではwinget install --id Microsoft.WindowsTerminal -eが使え、Terminal 1.18以降の依存対応にはWinGet 1.6.2631以上が必要とREADMEは記します。ChocolateyとScoopも選べますが、非公式経路として扱われます。更新の責任と取得元を明確にするなら、Store、GitHub、wingetのどれを標準にするかを組織で固定します。

Canaryは新機能と不安定さを引き受ける版

Windows Terminal Canaryはmainブランチの最新コードを含むナイトリービルドで、Previewへ入る前の機能を試すための版です。READMEは最も不安定な提供形態と説明しています。App Installer版は自動更新に対応しますがWindows 11だけで動き、Portable ZIP版は自動更新も更新確認もせず、Windows 10のビルド19041以降とWindows 11で使えます。

配布表にはApp Installerのx64、arm64、x86、Portable ZIPのx64、ARM64、x86が挙がっています。新機能の早期確認にはCanaryが役立ちますが、業務端末の標準版と同じ安定性を期待するものではありません。検証用の端末と安定版の端末を分け、Canaryで見つかった不具合がPreviewや安定版へ入ったかをリリース履歴で確認します。

Terminalとconhostの共有部品を理解する

Windows Terminalはタブ、リッチテキスト、国際化、設定変更、テーマとスタイルを備えた現代的な端末アプリです。conhost.exeは従来のコマンドライン体験を提供し、WindowsのコンソールAPIを支えます。チームは2014年以降、背景の透明度、行単位の選択、ANSIとVTシーケンス、24ビットカラー、ConPTYなどを追加してきたとREADMEは説明しています。

後方互換性を保つ制約によって新しい表示機能を従来ホストへ足しにくくなり、Terminalが作られたという経緯があります。Terminalのコアは再利用できるUIコントロールとして構築され、共有のテキストレイアウト、バッファ、VT処理を使います。アプリの見た目を変える作業と、コンソールAPIやConPTYの互換性に関わる作業は別の層なので、変更箇所を分けて読むべきです。

ソースビルドはWindows開発環境を揃える

ソースからビルドするにはWindows 10 2004、開発者モード、PowerShell 7以降、Windows 11 SDK 10.0.26100.8249以上、Visual Studio 2026 18.6以上が前提です。Visual StudioにはC++によるデスクトップ開発とWinUIアプリ開発のワークロードを入れ、テストプロジェクト向けに.NET Framework 4.7.2 Targeting Packも用意します。WinGet設定ファイルで環境を整える方法もREADMEにあります。

PowerShellではtools/OpenConsole.psm1を読み込み、MSBuildの開発環境を設定してビルドを呼び出します。Cmdではtools/razzle.cmdとbczを使います。デバッグ時はCascadiaPackageをスタートアッププロジェクトに設定し、アプリとバックグラウンドタスクのプロセスをNative Onlyへ変更し、x64またはx86を選びます。WindowsTerminal.exeを直接起動できないという注意もあるため、既存のビルド手順を省略しないことが大切です。

ドキュメントと貢献の入口を分ける

利用者向けの文書はaka.ms/terminal-docsで、文書への貢献はMicrosoftDocs/terminalの別リポジトリで行います。Console API文書も別のリポジトリです。コードを変更したい人はContributor Guideを読み、issueを新しく作る前に既存のissueを探すようREADMEは求めています。チームの連絡先と公開された窓口、Microsoft Open Source Code of Conductへの言及もあります。

このリポジトリはMITライセンスで、著作権表示と許可表示をコピーや重要部分へ残す条件で、使用、複製、変更、結合、公開、配布、サブライセンス、販売が許可されます。ソフトウェアは現状のまま提供され、保証や責任を負わない条件です。ライセンスはWindowsのサポート契約や本番動作の保証ではないため、導入版の更新、社内配布、サポート窓口は別に決めます。

導入版と開発版を運用で分ける

日常利用ではMicrosoft Storeやwingetなど更新経路が明確な安定版を標準にし、手動msixbundleは自動更新されない点を記録します。PreviewやCanaryは新機能の評価対象に分け、Portable ZIPを使う場合は更新確認を人が行います。OSビルド、アーキテクチャ、依存フレームワークが端末ごとに揃っているかも確認します。

開発では、Windows SDK、Visual Studio、PowerShell、開発者モード、ターゲットパックを固定し、CascadiaPackageから起動する手順を共有します。READMEは導入、ビルド、貢献の入口を詳しく示しますが、各社の管理ポリシー、セキュリティ保証、長期サポート期間は定めていません。公式リリースと文書を参照し、安定版の利用とソース変更を別の承認経路に置けるチームに適したプロジェクトです。

編集部の結論

Windows Terminalは、タブ、Unicode、テーマ、複数のシェルを一つの端末アプリで扱いたいWindows利用者に向きます。安定版、Preview、Canary、手動インストールでは更新と安定性が異なるため、用途ごとに版を固定してください。開発者はWindows SDK、Visual Studio、PowerShell、開発者モードなどの前提を揃え、Microsoftの公式配布元とリリースを確認してから運用やソース変更へ進むのが安全です。

公式情報源

  1. Official README
  2. Project repository
  3. Release notes
コミュニティノート

コミュニティノート