Warp完全解説：Rust製AIターミナルがOSS化、Claude Code・Codex・Gemini CLIと統合

ターミナルが「コマンドを叩く道具」から「エージェントと一緒に開発する環境」へ変わり始めた象徴的な動きが、2026年4月28日に発表された Warpクライアントの完全OSS化 だ。Rust製のターミナルアプリがGitHubで warpdotdev/warp として公開され、AGPL v3とMIT（UI部分）のデュアルライセンスで誰でもソースに触れる。執筆時点でGitHub Stars 38.3k、Forks 2.1k、利用者は700,000人を超える。本記事では、何がOSS化されて何がされていないか、Claude Code・OpenAI Codex・Gemini CLIとの統合がどう設計されているかを掘り下げる。

この記事では Warp のOSS化と AIターミナルとしての位置づけを解説します。AIコーディングツール全体の見取り図はVibe Coding完全ガイド2026をご覧ください。

Source: warpdotdev/warp — モダンなUI、コードエディタ機能、エージェント統合を持つRust製ターミナル。

Warp 2026とは：ターミナルから「Agentic Development Environment」へ

Warpは2020年に登場したRust製の高速ターミナルだが、2026年版の自己紹介はもう「ターミナル」ではない。公式Wordingは “Warp is an agentic development environment, born out of the terminal.”——ターミナルから生まれた、エージェント駆動の開発環境だ。

エンタープライズ向けに Agentic Swarm Coding（多エージェント並列開発）を売り文句にしており、SOC 2認証取得済み。「2人のシニアエンジニアが10分かかる作業を数秒に」とCEO Zach Lloydは表現している。

ボトルネックが「コードを書くこと」から「製品仕様を切り出して、結果を検証すること」に移ったというのが彼らの仮説で、ターミナル側がエージェントに作業させる司令塔へとUIを再設計しているのが2026年Warpの本質だ。

何がOSS化されたか：AGPL v3 + MIT のデュアルライセンス

「OSS化」の中身は具体的に区切られていて、ライセンスがコンポーネントで分かれているのが特徴だ。

AGPL v3は「ネットワーク経由でアクセス可能にした時点でソース公開義務」が発動する強いコピーレフトで、競合がWarpのクライアントをそのままSaaS化する経路を塞ぐ意図がある。一方、UIフレームワーク部分はMITで「外部の開発者がGPUI風のRustベースUIを取り入れる」のを促進する設計だ。Zedエディタが採用するGPUIに近い思想で、Rust UIエコシステムの広がりに賭けている。

そして特筆すべきは、OpenAIが創設スポンサー（founding sponsor）として加わった点。OpenAIエンジニアリングリードのThibault Sottiauxが「オープンソースは開発者が学び、構築し、分野を前進させるために中心的な役割を果たしてきた。私たちはこの実験を支援することに興奮している」とコメントを寄せている。AnthropicがClaude Code向けに広範な公式統合を進める中、OpenAI側がWarp経由でターミナル文化に張りに来たという構図だ。

OSS化に至る背景：「コードを書く」より「仕様を切り出す」

なぜ2026年のこのタイミングでOSS化に踏み切ったか。CEO Zach Lloydの発言を要約するとこうなる。

1. ボトルネックの所在が変わった — コード生成はAIに任せられる領域が増え、人間の時間は「何を作るか・正しく動いているか」の方に振り向ける価値が高い。
2. エージェント駆動開発が成立する条件が揃った — Claude Code、Codex、Gemini CLIが揃い、ターミナル経由で複雑なタスクを丸投げできるベースができた。
3. OSS化＝コミュニティ拡張のスピードを最大化 — クライアントを開ければ、エージェント自身がWarpのコードに貢献できる。

実際、Warpの新しい貢献モデルは異色だ。

「コミュニティはアイデアと検証、Ozエージェント群が実装・計画・テストの重い仕事、Warp社は方向性のガイダンス」という分業を最初から公式の貢献モデルとして掲げている。GitHub Issuesは公開、ロードマップも公開、リリースは毎週木曜日という運用だ。

これは旧来のOSSの「メンテナがレビューしてマージ」とは異質で、「PRを書くのは大半がエージェント」という前提がベースにある。AnthropicやOpenAIがClaude Code/Codexを通じて押し進めている方向と一致しており、エージェント時代のOSS運営のテンプレを確立しに来ているとも読める。

機能の中身：エージェント統合と「open」モデル

OSS化と同時に、Warp 2026は機能面でも以下を発表している。

「Claude Codeはあなたのプロジェクトで使う。CodexはOSS実験用。Gemini CLIはGCP関連。Qwenは社内秘データ。」のような エージェント・モデルの混在運用 をターミナル側が一手に引き受ける、というのが世界観だ。

# Warpを起動した状態でのCLI連携の例（イメージ）
> claude refactor src/auth.ts
（Warpブロック内でClaude Codeセッションが開く）

> codex generate-tests --target src/auth.ts
（同じワークスペースでCodexが並列で走る）

> gemini deploy-cloud-run --image latest
（Gemini CLIで本番デプロイ。ブロック単位で履歴が残る）

「複数エージェントを切り替える際にコンテキストが分断される」問題を、Warpのブロック型UI＋共通ワークスペースで吸収する。これが従来のターミナル（iTerm2、Alacritty、Wezterm）が踏み込んでいない領域だ。

OSSモデル＋Auto (open)：データ主権を意識した設計

Kimi、MiniMax、Qwenなど 中国・OSS発のモデルを Auto (open)で扱える点も2026年版の特徴だ。これは単に対応モデルを増やしたのではなく、「商用LLMに送りたくないデータをルーティングで隔離する」設計の入り口になっている。

エンタープライズで「ソースコードや顧客情報を外部APIに送れない」という制約は珍しくない。Auto (open)はこのケースで「Warp自体は使いつつ、機密データはOSSモデルに送る」運用を可能にする。

OSSモデルとマルチエージェント運用の関連性についてはOpenHandsとマルチエージェント連携も併読すると視座が広がる。Warpが「ターミナル」をフックにしているのに対し、OpenHands系は「エージェント基盤」をフックにしているが、根底にある「OSSモデル/商用モデルの混在運用」のニーズは同じだ。

既存ターミナルとの違い：Alacritty / iTerm2 / Wezterm との位置取り

「Rust製ターミナル」は他にもある（AlacrittyもRust）。Warpを乗り換え対象にすべきかどうかは、何を重視するかで変わる。

「速度」「設定の柔軟性」が最優先ならAlacritty/Weztermが今でも強い。Warpが他を圧倒しているのは「エージェントとの統合」と「ブロック型UIによるコマンドの再利用」で、ここに価値を感じない開発者にとっては乗り換える理由が弱い。

逆に、「Claude Codeを起動するたびに別ウィンドウになって追えない」「複数エージェントの履歴を一画面で扱いたい」「機密プロジェクトでOSSモデルだけに切り替えたい」のようなニーズがあるチームには、現時点で他に競合がない。Cursorとの比較でAIコーディング全体の選択肢を俯瞰したい場合はClaude Code vs Cursor 比較2026が併読向きだ。

既存ツールからの移行コスト：iTerm2/Wezterm/tmux ユーザー向け

「乗り換える」と決めたとき、何を持っていけて何が変わるか。実務で意思決定する時の論点を整理する。

特にtmuxユーザーは選択を迫られる。「ペイン分割で多数のターミナルを並べる」という設計とは思想が違うため、tmux + Alacritty/Wezterm のままで生き続ける選択肢も依然として有効だ。Warpはその上位レイヤー（ターミナルそのものをADE化する）に行くツールなので、「tmux派 vs Warp派」は当面共存する。

「貢献の70%がエージェント」のリアル：オープンPRの中身

WarpがOSS化と同時に打ち出した「エージェントが大半のPRを書く」貢献モデルは、見る人によっては奇妙に映る。GitHubのIssuesとPRsを観察すると、

• Issueは人間が書いた要望・バグ報告
• PRはOzエージェントが起票・人間レビュアーがマージ承認
• レビュー時のコメントは人間とエージェントが混在

という運用が見える。これは旧来の「メンテナがすべてのPRを精査する」モデルが、「メンテナが方向性を示し、エージェントが実装し、コミュニティが検証する」モデルに移行している実例だ。

ここで気になるのは品質保証だが、WarpはOzエージェント側にレビュアー・テスター・スペック検証者を役割分担させる構造を採っている。1つのPRに対して、

1. 実装担当エージェント（コード生成）
2. テスト担当エージェント（テストを別途書く）
3. レビュー担当エージェント（コードレビュー）
4. 人間レビュアー（最終承認）

の4階層を通すことで、単一エージェントの暴走を防ぐ。これは多エージェント検証パターン（Santaメソッド等）の流れに近く、「複数のエージェントを敵対的にぶつける」設計が品質を担保する、という賭けだ。

ビルドして動かす：Rust初心者向けクイックチェック

Warpクライアントは標準的なRustプロジェクトとして公開されているので、git cloneしてcargoで動く。

# クローンしてビルド
git clone https://github.com/warpdotdev/warp.git
cd warp

# Rust toolchain インストール（未導入なら）
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# プレビュービルド（プラットフォーム別の手順は公式ドキュメント参照）
cargo build --release

OSSバージョンを毎週木曜日のリリースに合わせてビルドし続けるのは現実的ではないので、普段使いはダウンロード版、ハックしたい部分だけソースから、という運用が想定されている。AGPLの制約があるため、改変版を社内ネットワーク経由で配布する場合はソース公開義務が発生する点に注意。

GPUI風のRust UIを学びたいなら、warpui_core/warpuiがMITで切り出されているのが大きい。Zed以外でモダンなRust UIフレームワークを参考にできるリポジトリとしての価値もある。

RustでGPU描画する設計：なぜ「Rust製ターミナル」が増えたか

WarpのUI層は Rust製のGPU描画フレームワーク で書かれている。同じ路線でZedエディタが採用しているGPUI、AlacrittyのOpenGLバックエンド、Wezterm等の系譜にあるが、Warpが今回MITで切り出した warpui_core / warpui はターミナル特有の要件——ブロック単位のレンダリング、IME対応、リッチテキスト、画像インライン表示、コードエディタ風のシンタックスハイライト——を1つのフレームワーク内で扱える点が新しい。

なぜターミナルが揃って Rust に流れているのかは、ハッキリした実利がある。

「ターミナルがGPUで動くべき理由」は、現代のターミナルが扱うコンテンツがもはや単純な文字列ではないことだ。コードのシンタックスハイライト、Mermaid図のインライン描画、AIエージェントの応答ストリーム、画像の埋め込み、ブロック境界の動的レンダリング——これらをCPU描画でやると、スクロールするたびにフレームが落ちる。Warpの「60fpsでスクロールできるブロック型ターミナル」は、GPU描画前提だからこそ実現している。

warpui_coreをMITで切り出した狙いは、Zedエディタ陣営に対するカウンターとも読める。Rust UIの選択肢をターミナルアプリ系のニーズ——大量のテキストフロー、ブロック型のレイアウト、リアルタイム更新——に最適化した形で公開することで、外部開発者が同じ系統のアプリを作るときの基盤を取りに行っている。

AGPL v3の実務的影響：誰が困って、誰が困らないか

「AGPL v3」と聞くと身構える企業法務担当者は多いが、多くのケースで実害はない。実務上の影響を場面別に整理する。

要するに「Warpを使って自社製品を作るなら気をつけて、自社の道具として使う分には気にしなくていい」というのがAGPL v3の本質だ。日本企業の法務がよく心配する「OSSを使ったら自社プロダクトのソースを公開する義務が発生する」という誤解は、AGPLでもプロダクト自体には及ばない（ターミナルの中で作ったコードはあなたのもの）。

実害が出るのは、Warpクライアントをフォーク + リブランド + SaaS化して儲けたい競合だけだ。これはWarpが意図して引いた防衛線で、「OSSにしたが、ビジネスは渡さない」という戦略の表れと読むのが正しい。

設定ファイル：「プログラマブルなターミナル」の実体

Warpがアピールする Settings file for programmatic control は、設定をテキストファイルで持ち、AIに編集させるという設計だ。具体的にどうなっているか。

# ~/.warp/settings.toml の概念例
[appearance]
theme = "tokyo-night"
font = "JetBrains Mono"
font_size = 13
line_height = 1.4

[ai]
default_model = "auto-open"           # OSSモデル優先ルーティング
allowed_models = [
  "claude-sonnet-4-6",
  "gpt-4o",
  "gemini-2-5-pro",
  "qwen3-coder",
  "kimi-k2",
]
context_files = [
  "CLAUDE.md",
  "AGENTS.md",
  ".cursorrules",
]

[blocks]
auto_label = true                     # ブロックに自動でタグ付け
keep_history_days = 30
share_redact_pii = true               # ブロック共有時にPIIマスク

[agents]
"claude" = "claude code"               # 短縮エイリアス
"codex" = "codex"
"gemini" = "gemini-cli"

設定がテキストなので、AIに「Claude Codeをデフォルトに、Geminiは社内VPC環境のときだけ使うように設定して」と頼める。これは見落とされがちだが、実務インパクトの大きい変化だ。「設定ファイルを読み書きできるエージェント」が前提に立つと、UI操作のためにマウスを動かす時間が消えていく。

ブロック型UIの再評価：「コマンド = ブロック」という発想

Warpの初期からの差別化点だったブロック型UIは、エージェント時代になって真価を発揮し始めている。各コマンドを独立したブロック単位で扱うため、

• ブロック単位でコピー・共有・再実行できる
• ブロックの出力をそのままAIに「これを解析して」と渡せる
• 失敗したブロックだけ手元で再現できる
• スクロールバックで過去のセッションを構造化された形で参照できる

という運用が成立する。従来のターミナル（テキストの巨大なバッファ）では、「数時間前の出力を見つけて再実行する」のが面倒だった部分が、ブロックを単位として綺麗に整理される。

# 従来のターミナル
$ npm install
（数百行のログがスクロールアウト）
$ npm test
（また数百行）
$ git diff
（人間が目でログを遡って原因を探す）

# Warp ブロック型UI
[block 1] npm install         → ✓ 0.3s で展開可能、AIで「失敗時は再実行」スニペット生成
[block 2] npm test            → ✗ 失敗。ブロックをコピペでClaude Codeに渡せる
[block 3] git diff            → ブロック単位で履歴・コメント・タグ付け可能

エージェントとの会話で「昨日のあのテスト失敗を再現して」のように指示できるのは、ブロックという意味のある単位でコマンドが残っているからだ。

Ozの「Agentic Swarm Coding」：推測されるアーキテクチャ

Warpがクラウド側で運営する Oz は、公式情報が少ないがマーケティング上は 「Agentic Swarm Coding」 を中核に据えている。OSS化対象外のSaaS層なので想像する余地は大きいが、公開情報を繋ぐと次のような構図が見える。

「1人の開発者が、複数のエージェントを同時に走らせる」という運用は、Cursor Background（CursorのバックグラウンドAgent）やDevin、Anthropicのmanaged-agentsが示してきた方向と同じだ。Warp/Ozの賭けは、ターミナルを司令塔にすることでこのSwarmを直感的に操る点にある。

実際のシナリオ別に展開すると、こう。

これらを1つのターミナルウィンドウで一望できるのは、ブロック型UIの真価が出る場面だ。複数のtmuxペインで擬似的に同じことをやるのと比べ、ブロック単位のキャンセル・再実行・履歴管理ができるのが構造的に強い。

日本企業導入時の論点：SOC 2・データ主権・商用LLM禁止

日本のエンタープライズでWarpを採用するときに必ず浮上する論点を、現実的な質問形式で整理する。

特に3点目の「商用LLM API送信禁止」は、日本の金融・公共・医療系プロジェクトで深刻な障壁だった。Auto (open)の登場で、「Warpを使う＝Claude/GPTにコードが流れる」という単純構造が崩れる。これはCursor / Claude Codeが現状解いていない領域で、Warpが企業市場で先行する可能性がある。

OpenAI×Anthropicの分業：ターミナル vs IDE

2026年の構図として面白いのは、OpenAIとAnthropicがADE領域で異なる入り口を選んでいることだ。

「IDE（Cursor）vs CLI（Claude Code）」の二項対立だった2025年から、2026年はターミナルを含めた三つ巴になった。エージェント時代の「主戦場」がどこに落ち着くかは、まだ流動的だ。

クラウド側の多エージェント並列実行（Oz）は、Anthropicがまだ公式プロダクトを持っていない領域で、ここがOpenAIの賭けどころと読める。Cursor BackgroundやClaude Codeのバックグラウンドジョブと比較して、Ozがどれだけ実用に耐えるかが2026年後半の見どころだ。エージェントの並列実行・分担という観点ではAIエージェントフレームワーク比較2026で他の選択肢も俯瞰できる。

実例セッション：1日のWarp駆動開発の流れ

抽象的な話ばかりだと掴みづらいので、Warp 2026 で1日の開発がどう進むかを具体的に描いてみる。架空のシナリオではなく、公開機能の組み合わせで実現可能な範囲だ。

[09:00] 朝のスタンドアップ後、Issue #1234 を着手
   → claude "Issue #1234を読んで、影響範囲と実装方針を整理して"
   → Claudeがリポジトリを横断スキャン、Warpブロックに影響ファイル一覧と
     リスク評価が並ぶ

[09:30] 仕様の不確実性をスペックに固める
   → 同じワークスペースでcodexに「ユーザーストーリーをBDDで起こして」
   → Warpは両エージェントの出力をブロック単位で並列保持

[10:30] 実装開始
   → claude "src/auth.tsからJWT検証部分を別モジュールに切り出して"
   → diffがブロックに表示、ブロックから直接 git add → 確認 → commit

[11:30] テスト追加
   → claude "切り出した部分にユニットテストを書いて"
   → npm test を別ブロックで実行、失敗したら同じブロック内で対話的に修正

[14:00] 本番に近い検証
   → gemini "GCP staging に deploy して、Cloud Trace の latency を見て"
   → 別ターミナル不要、Warpブロック内で完結

[16:00] PRレビュー対応
   → claude "PR#5678のレビューコメントを全部反映して"
   → Ozで並列実行→人間レビュー→マージ

「1人で複数のIssueを並行に進める」運用が、ブロック型UIによる並列管理で初めて現実的になる。tmuxでも同じことはできるが、「どのペインで何のエージェントを動かしているか覚えておく」コストは認知資源を消費する。Warpはこれをブロックに自動でラベル付けし、意味的に整理することで肩代わりする。

開発者文化への影響：「コマンドの再利用」の意味が変わる

ターミナルがブロック型になると、コマンドの「再利用」の概念が変わる。これまでの「シェル履歴を上下キーで遡る」体験から、

• ブロック単位で意味のある単位に名前を付けて保存
• AIに「あの時のテスト失敗を再現するコマンドを呼び出して」と依頼
• ブロックをワークフロー化して、後輩エンジニアに引き継ぐ

ということが日常的に起こるようになる。これは「ターミナルが個人の作業空間から、チームの共有資産になる」変化で、ナレッジマネジメント観点で見ても大きい。Warp 2026の本当の価値は、「個人開発者の作業ログが、組織のドキュメントとして再利用できる」状態を作ることにあると言える。

ナレッジを共有する文脈では、Andrej Karpathy式 Skills + CLAUDE.mdガイドで説かれる「コードと並走するナレッジファイル」と相補的に機能する。Warpブロックは動的な操作履歴を、CLAUDE.md系は静的な知識の集合を担う、という分担だ。

まとめ：「ターミナル戦争」から「ADE戦争」への転換点

Warp 2026のOSS化は、単なる「閉鎖的だったツールが開かれた」というニュースではない。

• ターミナルそのものが、AIエージェントを束ねるAgentic Development Environmentとして再定義された。
• OSSモデル+商用モデルの混在運用を、Auto (open)という形で前面に出した。
• OpenAIが創設スポンサーとして加わり、Anthropicが進めるClaude Code生態系へのカウンター的ポジションを取った。
• 貢献モデル自体が「エージェントが大半のPRを書く」前提になっており、OSSの運営ルールも変容しつつある。

CursorやClaude Codeの対抗軸として「IDE型」「CLI型」が議論されてきたが、Warpはあえてターミナルという第3の入り口でADEレースに参戦してきた。Rustエンジニアにとっては実装の中身を読める教材として、エンタープライズ管理者にとってはOSSモデルとの統合解として、それぞれ意味のあるリリースだ。

1年後の予想：Warp/Ozが変える3つの開発習慣

ここまでが事実と公式情報の整理だった。最後に、Warp 2026のOSS化が今後1年でどう開発文化を変えるか、独自視点での予想を3つ置いておく。

予想1：「コマンド履歴」が「チームナレッジ」に昇格する

これまでのターミナル履歴は、~/.zsh_historyに流れていく個人の運用ログだった。Warpのブロック型UIが普及すれば、「金曜の本番障害をどう収束させたか」がブロック単位で再現可能なナレッジになる。OnCallの引き継ぎ・新人オンボーディング・ポストモーテム作成が大幅に省力化される。

予想2：「設定をAIが書く」が前提になる

Settings file for programmatic controlは今は地味な機能だが、「AIが自分の作業環境を書き換える」という概念がエンタープライズ標準になる兆しだ。「新しいプロジェクトに移ったら、リポジトリのCLAUDE.mdを読んでターミナルの設定を最適化する」のような、初期セットアップ自動化の出発点になる。

予想3：「Warp互換」が新しい標準を生む

AGPL v3でクライアントがオープンになり、UI部分がMITで切り出されたことで、「Warp互換のクライアント」が複数登場する可能性がある。Anthropic公式のターミナル、Google公式のターミナル、社内専用ターミナル——いずれも同じUI規約・ブロック構造・スキル仕様を持つ、というシナリオだ。これが起これば、ターミナルは「特定ベンダーの製品」から「インフラの一部」へ変質する。

FAQ

Q. Warpは無料で使えますか？

A. はい、ダウンロード版は引き続き無料で配布されています。OSS化されたのはクライアントコードで、有料プラン（Pro/Team/Enterprise）はOzを含む高度機能やSOC 2対応を提供する別建てです。詳細は warp.dev で確認できます。

Q. macOS以外でも動きますか？

A. macOS / Linux / Windows の3プラットフォーム対応です（Linuxは Debian、Ubuntu、Red Hat、Fedora、SUSE、Arch、Windowsは10/11、x64・ARM64）。READMEではmacOS/Linuxが主に言及されますが、公式サイトはWindows対応を明記しています。

Q. AGPL v3って具体的に何が制約されますか？

A. クライアントを改変してネットワーク経由で第三者に提供する場合、改変版のソースコードもAGPL v3で公開する義務が発生します。社内専用ツールとして使う分には公開義務は発生しませんが、SaaSとして外部公開するなら影響を受けます。UIフレームワーク部分（warpui_core / warpui）はMITなのでこの制約から外れます。

Q. Claude Code・Codex・Gemini CLIはWarp上でどう動きますか？

A. それぞれのCLIをWarpのブロック型UIで起動し、出力を構造化して表示する形です。複数エージェントを並列に走らせ、Warp上でコマンド履歴・出力・コンテキストを共通管理できます。エージェントの呼び分けそのものはユーザーが行います（Warpが自動オーケストレーションするわけではない）。

Q. Ozも将来OSS化されますか？

A. 公式アナウンスではOzはOSS化対象外と明確に区別されています。OzはWarp社のSaaSとして継続提供される、というのが2026年4月時点の方針です。

Q. 既存のiTerm2 / Alacritty設定は引き継げますか？

A. シェルの起動コマンド、エイリアス、.zshrc/.bashrc等は引き継げます。一方、iTerm2/Alacrittyのカラースキーム・キーバインド設定はWarp独自の設定形式に書き換える必要があります。Warpはテキストファイルで設定を持つため、AIに「私のiTerm2設定をWarp用に変換して」と依頼しやすい構造ではあります。

Q. ブロック型UIで既存のCLIアプリは正しく表示されますか？

A. ほぼすべて動きます。ANSIエスケープシーケンス・カーソル制御・カラー出力は標準対応。vim htop lazygit tmux内部実行などのフルスクリーンTUIアプリも問題なく動作します。一部、画面の高速書き換えに依存する古いアプリ（mcの特殊モード等）でちらつきが出るケースがありますが、実用上問題になることはほぼありません。

Q. AGPL v3のクライアントを使う＝自分のコードを公開しないといけない、ですか？

A. 違います。 AGPLが要求するのは、Warp自体を改変して配布したときにその改変部分のソースを公開することです。Warpを使って書いたあなたのプロジェクトのソースコードには影響しません。会社のCIシステムでWarpを動かすケースでも、Warpそのものに手を加えていなければソース公開義務は発生しません。

Q. Warp Drive（クラウドのコマンド共有機能）はOSS化対象に含まれますか？

A. 含まれません。 Warp Drive はSaaS側の機能で、OSS化されたのはあくまでクライアントです。クラウドでチームのコマンドや環境変数を共有する機能を使うには、引き続きWarpの有料プラン契約が必要です。

Q. 旧来のターミナル（screen/tmux）のセッション再接続のような機能はありますか？

A. シェル単体のセッション再接続は、Warpのブロック型UIとは思想が異なります。リモートサーバ上で永続セッションを維持したい場合は従来通りtmux/screenをWarp内で動かすのが定石です。一方、ローカルでのコマンド履歴の永続化は、Warpブロックがすべて自動保存・タグ付けされるため、tmuxよりむしろ強力です。

Q. プラグインやテーマはどこで配布されますか？

A. OSS化に伴い、GitHubのwarpdotdev/warpリポジトリ自体がコミュニティ拡張の中心になります。テーマ・ワークフロー・カスタムキーバインドはコミュニティ貢献として受け入れる方針が公開されています。AnthropicやOpenAIのスキル流通レイヤー（前述のskills.sh等）との連携はまだ未整備ですが、エージェント時代のターミナル拡張機構として今後整理されると見られます。

参照ソース

• warpdotdev/warp — GitHub
• Warp is now open-source — Warp Blog
• Warp Terminal Goes Open Source—But AI Agents Do the Work — byteiota
• Warp (terminal) — Wikipedia