Microsoftが2026年5月、Windows Terminalをフォークして「エージェントペイン」を組み込んだ実験的ターミナル「Intelligent Terminal」を公開した。シェルの出力をそのままコンテキストとして読むエージェントが画面の下半分に常駐し、コマンドが失敗すればそのエラーを抱えたまま修正案を出す。この記事では、使い方を押さえたうえで「対応エージェント5種は実際にどう繋がっているのか」「企業が配布するときに何を制御できるのか」を、公式リポジトリのソースコードまで降りて確認する。
30秒でわかる Intelligent Terminal
・正体：Windows Terminal の実験的フォーク（MIT・C++）。既存のWindows Terminalを置き換えず、別パッケージとして横に並ぶ
・中身：ACP（Agent Client Protocol）対応のエージェントCLIをペインに常駐させ、シェル出力をコンテキストとして渡す
・対応エージェント：Copilot / Claude / Codex / Gemini / OpenCode の5種がビルトイン。ただしACPの喋り方は3種と2種で違う（後述）
・検出方法：「自動検出」と説明されるが、実装は PATH上に <id>.exe か <id>.cmd があるかを見ているだけ
・企業向け：GPO（グループポリシー）で4項目を制御できる。ただし既定はすべて「許可」で、AllowedAgents はカスタムエージェントに効かない
エージェント統合ターミナルという発想自体はこの1年で一気に増えた。フレームワーク側の全体像はAIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証にまとめてあるので、そちらと合わせて読むと位置づけが掴みやすい。
Intelligent Terminalとは——Windows Terminalを「置き換えない」AIフォーク
Intelligent Terminal は、Microsoft が microsoft/terminal（Windows 11 の既定ターミナル）をフォークして作った実験的なターミナルだ。リポジトリは 2026-05-18 に作成され、公開時点で1,600スター超。ライセンスは MIT、主要言語は C++ で、OpenConsole.slnx や src/cascadia といった Windows Terminal 由来のディレクトリ構成をそのまま引き継いでいる。
重要なのは置き換えではないという設計方針だ。READMEは Intelligent Terminal を「既存アプリの隣にインストールする独立したバイナリ」と位置づけており、Windows Terminal 側のコードを書き換えることも、バージョンを揃える必要もない。つまり「試してみて合わなければアンインストールするだけ」で元の環境に戻る。エージェント機能を既定ターミナルに強制的に混ぜ込まなかったのは、実験的プロダクトとしては妥当な判断と言える。
リリースは以下の3本が公開されている。バージョン番号の付き方が独特で、タグは v0.1.18 だがリリース名は Intelligent Terminal v0.1.1841 のようにビルド番号まで含む。
| タグ | 公開日 | リリース名 |
|---|---|---|
v0.1.0 |
2026-05-29 | Intelligent Terminal v0.1.1521 |
v0.1.1 |
2026-06-17 | Intelligent Terminal v0.1.1681 |
v0.1.18 |
2026-07-10 | Intelligent Terminal v0.1.1841 |
何を解決しようとしているのか
従来、ターミナルでエラーが出たときの流れは「エラー文をコピー → ブラウザかチャットに貼る → 回答をコピー → ターミナルに戻す」だった。Intelligent Terminal はこの往復を消すことを狙っている。エージェントはシェルの出力を直接参照できるため、コピペの工程がまるごと不要になる。しかも PowerShell と Bash/WSL の両方のシェル出力にコンテキストを持つ。
Intelligent Terminalのインストールと初回セットアップ——WinGetとFREが実際にやること
配布は Microsoft Store と WinGet の2経路。自動更新が効く Store が推奨だが、企業の展開や検証環境では WinGet のほうが扱いやすい。
# WinGet でインストール（パッケージIDは Microsoft.IntelligentTerminal）
winget install --id Microsoft.IntelligentTerminal -e
動作要件は Windows 10 バージョン2004（ビルド19041）以降。FAQ によればパッケージマニフェストが MinVersion="10.0.19041.0" を指定しているため、これより古いビルドでは MSIX インストール自体がブロックされる。
初回起動時には FRE（First-Run Experience）と呼ばれるウィザードが走る。ここで何が起きるかは、企業展開を考えるうえで無視できない。FAQ が挙げている実際の処理は次のとおりだ。
・winget を使って GitHub Copilot CLI と、必要なら Node.js LTS をインストールする
・BYOA（持ち込みエージェント）のCLIは npm install -g で取得する
・Claude と Codex については、初回起動時に npx が ACPラッパーを取りに行く
つまり FRE はネットワークに出てパッケージを取得する工程を含む。公式FAQは、回線が遅い・絞られている・不安定な環境ではこれが10分以上かかることがあり、断続的な接続では失敗しうると明記している。プロキシや実行ポリシーが厳しい企業ネットワークで配布するなら、この点は事前に検証しておきたい。
なお winget 自体が存在しない環境（App Installer 未導入、LTSC や Server SKU で削られている場合）も想定されており、ソース側に winget の有無を判定する専用パスがある。この場合は「インストール失敗」という誤解を招くエラーではなく、winget のセットアップ手順へ誘導するメッセージが出る。
PowerShell の実行ポリシーが Restricted のままだとシェル統合が初期化できず、UnauthorizedAccess エラーになる。READMEが案内する回避策はこれだ。
# シェル統合が初期化できない場合（UnauthorizedAccess エラー時）
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned
エージェントペインの使い方——ショートカットとスラッシュコマンド
エージェントペインはキーボードで完結するよう設計されている。既定のショートカットは6種で、いずれも設定から変更可能だ。
| ショートカット | 動作 |
|---|---|
| Ctrl+Shift+. | エージェントペインの表示/非表示 |
| Ctrl+Shift+I | エージェントペインへフォーカス移動 |
| Ctrl+Alt+. | エラーのコンテキストを載せた状態でペインを開く |
| Ctrl+Shift+/ | エージェント管理（セッション一覧）を開く |
| Alt+Shift+/ | コマンドパレットをプロンプトモードで開く |
| Alt+Shift+B | 委譲エージェントのタブを起動プロンプトなしで開く |
ペイン内では / を打つとスラッシュコマンドの一覧が出る。ここで押さえておきたいのは、/clear と /new が別物という点だ。/clear はスクロールバックを消すだけでセッションは維持し、/new はセッションごと作り直して履歴を捨てる。
・/help — コマンド一覧
・/clear — チャットのスクロールバックを消す（セッションは維持）
・/new — セッションを作り直す（履歴を捨てる）
・/fix [ヒント] — アクティブなターミナルを診断して修正案を出す。/fix パスがおかしい気がする のようにヒントを添えて誘導できる
・/restart — クリーンなセッションでエージェントを再起動
・/stop — 実行中のプロンプトをキャンセル
・/sessions — エージェント管理を開く
・/agent [id] — このタブで使うエージェントを選ぶ
・/model [id] — このペインのモデルを選ぶ。引数なしならピッカーが開く
WSLでのエージェント選択は「厳密」
地味だが実務で効く仕様がある。プロファイルの General 設定で「エージェントペインのエージェント」に、そのプロファイルのWSLディストロ内にインストールされたACPエージェントを指定できる。このときピッカーに出るのは Windowsホストとそのディストロ1つだけで、他のディストロは絶対に出てこない。
さらに、プロファイルで明示指定したエージェントは厳密（strict）に扱われる。指定したエージェントが起動できなかった場合、別のエージェントに黙ってフォールバックせず、ペインは失敗をそのまま報告する。委譲エージェント（?<prompt> で起動するほう）も同様で、選択したエージェントが使えなければ別のエージェントや別の実行環境に切り替えることなくエラーを返す。「気づかないうちに違うエージェントに課金していた」が起きない設計だ。
対応エージェント5種の実体——ACPネイティブ組とnpmアダプタ組
ここからが英語圏の記事もほとんど触れていない部分だ。多くの紹介記事は「Copilot / Claude / Codex / Gemini / OpenCode に対応」と5種を横並びで書いている。しかしソースを読むと、この5種は繋がり方が2グループに分かれている。
src/cascadia/inc/AgentRegistry.h のコメントが明示している。ACP対応エージェントは「CLI自身がACPを喋る（copilot・gemini・opencode）」か、「npm配布のアダプタが喋る（claude は @agentclientprotocol/claude-agent-acp、codex は @agentclientprotocol/codex-acp）」のどちらかである、と。
さらに同ファイルの ByokMode 列挙型は、BYOK（自分のAPIキー/プロバイダを使う）への対応がエージェントごとに違うことを示している。
| エージェント | ACPの喋り方 | BYOK対応（ByokMode） |
|---|---|---|
| GitHub Copilot | CLI自身がACPネイティブ | ○ CopilotProviderEnvironment |
| Gemini | CLI自身がACPネイティブ | × Unsupported |
| OpenCode | CLI自身がACPネイティブ | ○ OpenCodeConfigContent |
| Claude | npmアダプタ経由 @agentclientprotocol/claude-agent-acp |
× Unsupported |
| Codex | npmアダプタ経由 @agentclientprotocol/codex-acp |
× Unsupported |
この違いは実運用に直結する。Claude と Codex を使うなら Node.js が前提になる（アダプタを npx が取りに行くため）し、BYOK で共有プロバイダ設定を効かせられるのは Copilot と OpenCode の2つだけだ。「5種対応」という一文だけを見て環境を設計すると、Node.js の要件を見落とすことになる。
なお ACP対応エージェントと委譲（delegate）エージェントは別のリストとして定義されている。委譲は ?<prompt> による背景実行に使われるもので、ソースのコメントいわく「委譲はACPを喋る必要がなく、プロンプトを入力として受け取るCLIなら何でも動く」ため、本来は集合が広い。もっとも現時点でビルトインに登録されているのは ACP 側と同じ5種だ。
ビルトインの5種以外も使える。FAQ は Qwen Code・Cline・Goose・Cursor・Kimi CLI・Kiro CLI・OpenHands などACPを実装したCLIなら設定画面の「+ Add new…」からコマンド指定で追加できると案内している。ただし制限が1つあり、エージェントセッション管理（セッション一覧の追跡）が動くのはフックが同梱されている5種だけで、カスタムエージェントのセッションはパネルに出てこない。
セッション追跡はエージェント側のフックで実現している
リポジトリの tools/wta/wt-agent-hooks/ には、各エージェントCLI向けのフックプラグインが同梱されている。Claude 向けは .claude-plugin/plugin.json（wt-agent-hooks v0.1.4・MIT）というClaude Codeのプラグイン形式そのもので、6つのイベントを PowerShell スクリプトに転送する構成だ。
・SessionStart → agent.session.start
・SessionEnd → agent.session.end
・UserPromptSubmit → agent.prompt.submit
・Notification → agent.notification
・Stop → agent.stop
・StopFailure → agent.error
同じ構成が codex（.codex-plugin/）、gemini（gemini-extension.json）、opencode（plugin.json + JS）向けにも用意されている。つまりセッション一覧は Intelligent Terminal がプロセスを監視して実現しているのではなく、各エージェントCLIのフック機構に相乗りして通知を受け取っている。FAQ が「FRE後にインストールしたエージェントはフックを手動で入れ直す必要がある」と書いているのはこのためだ。
エージェント検出はPATHを見ているだけ——ソースで確認する
READMEは初回起動時の挙動を「マシン上のACP対応エージェントCLIを自動検出する」と表現している。この「自動検出」がどこまでやっているのかを確認すると、実装は非常にシンプルだった。
src/cascadia/TerminalApp/FreOverlay.cpp の _IsAgentInstalled は、Win32 API の SearchPathW を2回呼ぶだけだ。まず <name>.exe をPATHから探し、見つからなければ <name>.cmd を探す。どちらかがヒットすれば「インストール済み」と判定する。バージョンの照会もマニフェストの確認も、実際にACPで喋れるかの疎通確認もしていない。
この実装から読み取れることは2つある。
1つ目は、判定が名前ベースの存在確認にすぎないこと。PATH上に claude.cmd という名前のファイルが置かれていれば、それが何であるかに関係なく「Claude が入っている」と判定される。悪意を想定するまでもなく、同名のラッパースクリプトやエイリアスを置いている環境では、意図しない候補が出てくる可能性がある。
2つ目は、_IsNodeInstalled が npx.cmd / npx.exe を別途探していること。前述のとおり Claude と Codex は npm アダプタ経由なので、Node.js の有無が別軸の前提条件になっている。ソースがこれを独立した関数として持っているのは、その依存関係を反映した結果だ。
そして見落としやすいのが、ドロップダウンを組み立てる _PopulateAgentComboBox が GPOフィルタ済みのレジストリから候補を作っている点だ。企業ポリシーは「設定画面で後から効く」のではなく、初回起動ウィザードの選択肢の時点ですでに効いている。
企業導入で効くGPOポリシー4種と、AllowedAgentsの落とし穴
ここが Intelligent Terminal を組織で配る場合に最も重要で、かつ英語圏でもまだほとんど解説されていない部分だ。src/cascadia/inc/AgentPolicy.h は、AIエージェント設定を制御するグループポリシーの読み取り専用モジュールとして実装されている。
読みに行くレジストリキーは1つ。
Software\Policies\Microsoft\IntelligentTerminal
HKLM を先に、次に HKCU の順で読む（つまりマシンポリシーが優先）。制御できる値は4つだ。
| 値の名前 | 型 | 意味 | 未設定時の既定 |
|---|---|---|---|
AllowedAgents |
REG_MULTI_SZ | 使用を許可するエージェントIDの許可リスト | 全許可 |
AllowCustomAgents |
REG_DWORD | カスタムエージェントの追加可否（0=禁止 / 1=許可） | 許可 |
AllowAutoFix |
REG_DWORD | エラーの自動修正提案の可否 | 許可 |
AllowAgentSessionHooks |
REG_DWORD | エージェントセッション追跡フックの可否 | 許可 |
4項目すべて、未設定なら「許可」である。ソースのコメントも Absent = all allowed / Absent = allowed と明記している。情報システム部門が何も設定しなければ、任意のエージェントCLIをターミナルに常駐させられる状態が既定になる、ということだ。これは fail-open な設計であり、良し悪しの評価は組織の方針次第だが、知らずに配ると「制御していないこと」に気づかない種類の既定値である。
コードでの判定はこうなっている（AgentPolicy.h の IsAgentAllowed）。allowedAgents が std::optional で保持されており、「未設定（nullopt）」と「設定されているが空（空集合）」が区別される点が肝だ。
・AllowedAgents が未設定 → 無条件で true（全許可）
・AllowedAgents が設定済み → その集合に含まれるIDだけ true
・AllowedAgents が空で設定済み → どのIDも含まれないので全ブロック
なお ID の照合は CompareStringOrdinal を使った大文字小文字を区別しない比較なので、Copilot と書いても copilot と一致する。ユニットテスト EffectiveAcpAgentBuiltInMatchIsCaseInsensitive がこの挙動を固定している。
許可リストを1つだけに絞る場合の設定例はこうなる。
# Copilot だけを許可し、カスタムエージェントの追加を禁止する
$key = 'HKLM:\Software\Policies\Microsoft\IntelligentTerminal'
New-Item -Path $key -Force | Out-Null
New-ItemProperty -Path $key -Name 'AllowedAgents' -PropertyType MultiString -Value @('copilot') -Force
New-ItemProperty -Path $key -Name 'AllowCustomAgents' -PropertyType DWord -Value 0 -Force
# 現在の設定を確認
Get-ItemProperty -Path $key | Format-List AllowedAgents, AllowCustomAgents, AllowAutoFix, AllowAgentSessionHooks
落とし穴：AllowedAgents はカスタムエージェントに効かない
ここが本記事で最も伝えたい点だ。AllowedAgents に copilot だけを書けば「Copilot 以外は使えない」と考えるのが自然だが、それは成り立たない。
リポジトリのユニットテスト src/cascadia/UnitTests_SettingsModel/CustomAgentAndPolicyTests.cpp は、この挙動を意図的に固定している。ファイル冒頭のコメントが仕様をそのまま述べている——AllowedAgents（REG_MULTI_SZ）が絞り込むのはビルトインのエージェントIDだけであり、custom: スキームは AllowCustomAgents（REG_DWORD）で別途ゲートされる、と。
テストメソッド名がそのまま結論になっている。
・EffectiveAcpAgentBuiltInBlockedWhenMissingFromAllowlist — ビルトインは許可リストに無ければブロックされる
・EffectiveAcpAgentCustomIgnoresAllowedAgentsAllowlist — カスタムエージェントは AllowedAgents の許可リストを無視する
・EffectiveAcpAgentCustomBlockedByCustomPolicy — カスタムを止められるのは AllowCustomAgents だけ
・EffectiveAcpAgentBuiltInBlockedByEmptyAllowlist — 空の許可リストはビルトインを全ブロックする
つまり AllowedAgents = {copilot} だけを配布したポリシーは、「Claude や Gemini のビルトイン選択」は止めるが、ユーザーが設定画面から claude.cmd --acp のようなコマンドをカスタムエージェントとして手で登録する経路は止めない。カスタムを止めるには AllowCustomAgents = 0 を併せて設定する必要がある。2つはANDで効くのではなく、それぞれ別の対象を見ている。
カスタムエージェントのIDがどう決まるかも src/cascadia/inc/CustomAgentId.h に書かれている。ユーザーが入力したコマンドライン（例："C:\Program Files\helper\helper.cmd" --acp）から、①先頭の空白を除去 ②最初のトークン、または引用符で囲まれた領域を取り出す ③ディレクトリ部分を落とす ④末尾の .exe / .cmd / .bat を大文字小文字問わず落とす、という手順で短いIDを導出し、custom: を前置して保存する。この custom: プレフィックスが、ポリシーゲートやコマンドライン解決の分岐に使われる系全体の判別子になっている。
運用時のチェックポイント
・AllowedAgents を設定しただけではカスタムエージェント経路は開いたまま。AllowCustomAgents = 0 を必ず併記する
・4項目とも未設定＝許可。「設定していない」は「制限している」ではない
・AllowAutoFix = 0 にすると、検出したエラーをエージェントへ自動送信する挙動を止められる。シェル出力が外部へ出ることを避けたい環境ではここも検討対象
・ポリシーはプロセス起動時とキャッシュ再読込時に読まれる（Reload()）。配布直後は再起動して反映を確認する
Intelligent Terminalと他のAIターミナル・Windows Terminalの比較と制限
Windows Terminal 本体との違いを整理すると次のようになる。タブ・プロファイル・テーマ・設定・シェル・キーボードショートカットといった既存機能は「期待どおりに動く」とREADMEが明言しているので、差分はエージェント関連に集中している。
| 観点 | Windows Terminal | Intelligent Terminal |
|---|---|---|
| 位置づけ | Windows 11 の既定ターミナル | 実験的フォーク（別パッケージで並存） |
| エージェント統合 | なし | エージェントペイン・委譲・エラー検出 |
| 対応エージェント | — | ACP対応CLI（ビルトイン5種＋カスタム） |
| エージェントのGPO制御 | — | 4項目（既定はすべて許可） |
| シェル出力の参照 | — | PowerShell / Bash・WSL の両方 |
| ライセンス | MIT | MIT |
| テレメトリ | Windows診断データ設定に従う | 同左（IT固有イベントは未収載） |
エージェント統合ターミナルという市場自体は競合が多い。ただ Intelligent Terminal の特徴は、特定ベンダーのエージェントに固定していないことにある。既定は GitHub Copilot CLI だが、ACPという公開プロトコルを採用したことで Claude・Codex・Gemini・OpenCode、さらにサードパーティのCLIまで同じ枠に載る。Microsoft が自社の Copilot だけを繋ぐ実装にしなかった点は、素直に評価してよい設計判断だと思う。
Microsoft のエージェント関連OSSという文脈では、企業ガバナンスの観点を正面から扱ったAgent Governance Toolkit完全解説｜Microsoft発のOWASP Agentic 10/10対応・本番AGガバナンス基盤、エージェントの訓練環境側を担うMicrosoft Orchard｜エージェント訓練用サンドボックスをKubernetesで1000個並列起動する設計、アプリケーション実装のフレームワークであるSemantic Kernel入門：Microsoft製AIエージェントフレームワークでエンタープライズ開発を加速が、それぞれ別のレイヤを担当している。Intelligent Terminal はそのうち「開発者の手元の入口」にあたる。
現時点の制限（公式FAQベース）
バージョンが 0.1 系であることが示すとおり、粗い部分は残っている。公式FAQが自ら挙げている制限を、そのまま押さえておくのが安全だ。
・FREが遅い/失敗しうる：winget・npm・npx でのダウンロードを伴い、回線条件によっては10分超。失敗時は依存を手動導入してから再起動する
・FRE後に入れたエージェントは追跡されない：セッション追跡フックはFREを通したエージェントにしか入らない。設定 → Agent の「Install hooks」で手動導入が必要
・カスタムエージェントはセッション管理の対象外：エージェントペインと委譲そのものは動くが、管理パネルには出ない
・モデルのドロップダウンが一時的にグレーアウトする：エージェント変更直後は default 表示のまま数秒待つ必要がある
・Windows 10 2004 未満は非対応：MSIXインストール自体がブロックされる
読者の3つの問いへの答え
・何ができる？ — Windows Terminal の使い勝手のまま、シェル出力を文脈として読むエージェントをペインに常駐させられる。エラー発生時は Ctrl+Alt+. で文脈込みの相談ができる
・何を解決する？ — 「エラーをコピー→貼る→戻す」の往復。PowerShell と WSL の両方の出力を跨いで参照できるので、環境差を説明する手間も減る
・何を代替できる？ — 単体の Windows Terminal ＋ 別ウィンドウのAIチャット、という組み合わせ。ただし0.1系の実験的プロダクトであり、既定ターミナルの置き換えとしてはまだ推奨されていない
まとめ——評価できる点と注意すべき点
Intelligent Terminal は「Windows Terminal にエージェントが載った」という一行で説明されがちだが、ソースまで降りると評価すべき点と注意すべき点がはっきり分かれる。
評価できるのは、ACPという公開プロトコルを採用して特定ベンダーに固定しなかったこと、Windows Terminal を置き換えず並存させたこと、そしてプロファイル指定のエージェントが失敗したときに黙って別エージェントへフォールバックしない厳密な設計だ。
一方で注意すべきは、①「自動検出」の実体は PATH 上の <id>.exe / <id>.cmd の存在確認にすぎないこと、②ビルトイン5種のうち Claude と Codex は npm アダプタ経由で Node.js が前提になること、そして③GPOポリシー4項目の既定がすべて「許可」で、AllowedAgents はカスタムエージェント経路を塞がないことだ。組織で配布するなら、AllowedAgents と AllowCustomAgents は必ずセットで設計してほしい。
参照ソース
・microsoft/intelligent-terminal — GitHub リポジトリ（README、src/cascadia/inc/AgentRegistry.h、src/cascadia/inc/AgentPolicy.h、src/cascadia/inc/CustomAgentId.h、src/cascadia/TerminalApp/FreOverlay.cpp、src/cascadia/UnitTests_SettingsModel/CustomAgentAndPolicyTests.cpp、tools/wta/wt-agent-hooks/、doc/faq.md、PRIVACY.md、TelemetryEvents.md を参照）
・Announcing Intelligent Terminal version 0.1 — Windows Command Line Blog（公式アナウンス）
・Agent Client Protocol — 対応エージェント一覧（ACPの仕様と対応CLI）
・microsoft/terminal — フォーク元の Windows Terminal
