SSH用のネイティブグラフィカルシェル

2026年6月30日原文(probablymarcus.com)

概要

サーバー と クライアント 間の新しいWebベースのシェル構想
各アプリが 小型HTTPサーバー として動作、連携可能
SSH経由 やローカルで利用、セキュリティ向上
Unixドメインソケット 利用による柔軟な権限管理
Outer Shell や関連ドキュメント、デモ動画の紹介

ブラウザベースのグラフィカルシェル構想

Webブラウザ は、サーバーとクライアント間で優れた体験を実現
新提案： サーバーやエッジデバイス がブラウザベースのグラフィカル「シェル」を提供
シェルは アプリのホーム画面 を提供し、各アプリは 小型HTTPサーバー として独立動作
シェルAPIにより、アプリ同士が URL検索・連携 可能
- 例：テキストエディタアプリ登録、他アプリからのファイル編集連携
従来の ターミナルアプリ に代わる新しいグラフィカルアプリの形

セキュリティと実装方法

各HTTPサーバーは プライベート で、他デバイスからは基本的にアクセス不可
利用方法は SSH経由 またはローカル利用が中心
一般的なWebサーバーツールと異なり、 localhostポート ではなく
- Unixドメインソケットファイル を利用
- ファイルシステム上で明示的なユーザー権限管理
HTTPサーバーは シンプル構成 で暗号化不要
- 暗号化は SSHレイヤー で処理
アプリは HTMLベースWebアプリ や ネイティブOuterframeアプリ として実装可能

Outer Shellとデモ

Outer Loop をSSHブラウザとして構築
新たに オープンソースOuter Shell を公開
デモ動画（Screencast）や YouTubeミラー も提供

ドキュメントとリンク集

ブラウザの仕組み説明：https://outerloop.sh/
Outer Shell API・アプリ追加方法：https://outershell.org/
ネイティブアプリの仕組み：https://outerframe.org/

考察：なぜ今まで存在しなかったのか

ブラウザの Unixソケット接続機能 はニッチ扱い
SSHやsudo対応 と組み合わせることで新しい可能性
従来のLinuxサーバーはローカルGUI重視だったが、
- 今後は「外部」グラフィカルシェルでリモート利用が主流に
JupyterやTensorboardなど 個別サーバー型Webアプリ は登場したが、
- セキュリティや統合面で最適化されていなかった
AIによるコード生成支援 で、各プラットフォーム向けのネイティブアプリ開発が現実的に
今後のWebアーキテクチャの自然な進化：
- HTMLは閲覧や簡易アプリ 向け
- 本格作業はネイティブアプリ へ

謝辞

Rosanne Liu、Mirko Klukas、Adam Zethraeus、Felix Andrews へのフィードバックへの感謝

Hackerたちの意見

https://terminal.click/posts/2026/06/tui-stability/#:~:text=...

└

もし「ユーザーベースが1人で自分だけ、デスクトップOSからサービスにアクセスする」っていう使い方なら、リバースプロキシやTLS証明書の面倒を省けるんじゃないかな。

└

サーバーやSSHを使う人たちにはいろんなグループがいると思う。私は深層学習の実験、GPUカーネルの最適化、ロボット開発（ロボットは動くサーバーだよ！）に使うグループに近いかな。リモートコンピュータを明示的に使うケースだね。このグループにとっては、このツールの方が君が提案するフローより直感的に感じると思う。でも、もしかしたら私が勝手に思ってるだけかも！それに、これは存在するべき基本的なものの一つに感じる。リモートファーストのグラフィカルオペレーティングシステムみたいなものだね。

└

そういえば、もしSSHでポートをたくさん送信してるなら、SSHでSOCKS5プロキシを立てるオプションも考えてみて。ssh -D 4711 -q -C -N user@hostってやると、localhost:4711がSOCKS5プロキシとして使えるようになるから、ブラウザに指定して使わせることができるよ。もちろん、WireGuard VPNの方がいいけどね。SSHは単一のTCP接続でマルチプレクシングしてるから、パケットが落ちると全ての転送トラフィックが再送されるまでブロックされちゃうし。

グラフィカルアプリのフロントエンドとバックエンドを分けるアイデアはいいね。でも、これってあんまり新しいアイデアじゃない気がする。もしかして何か見落としてるのかな？「X11Forwarding yes」や「html5ウェブアプリ」については知らないってこと？ブラウザに関しては、Unixソケットに接続する機能は極めてニッチだとされてる。セキュリティの問題があるから実装されてないんだよね。少なくとも生のUnixソケットはね。WebSocketや他のポートはHTTPに限定されてることもあるし。

└

セキュリティに関する素早い返答：いくつかのMozillaフォーラムで見た議論は基本的にこうだった。

ブラウザがどのソケットにも接続できるようにはできない。多くのソケットは、明示的にブラウザの接続を望んでいないか、ブラウザに無関心だから。
...だから、何らかの許可リストを追加する必要がある。
...このニッチな機能のために、これがあまりにも複雑になってきてる。だから、ニッチさがここでは重要な要素だったと思うよ。（ちなみに、Outer Loopは許可リストを追加してるよ： https://outerloop.sh/unix-domain-sockets/）

素敵なまとめだね！自分の研究用にブックマークしておくよ。私のターミナルの「カチカチ」機能はローカルマシンにしかないから、どこかにリモート接続するとグラフィカルさが失われちゃうんだ。それが、オフラインリプレイで少し変わり始めてる。ネイティブのGUIとTUIが連携して巻き戻しを可能にしてるんだ。でも、まだまだ道のりは長いし、他の人がちゃんと実験してるのを見るのが好きだな。（ターミナルはすごく過小評価されてる。）

これは問題を探している解決策に見えるね、過去の多くのものと同じように…以下の引用がこの試みに関連していると思う。「Unixを理解できない者は、再びそれを貧弱に再発明する運命にある。」 ~ヘンリー・スペンサー

└

ちょっと厳しすぎる気がするな。これが取り組んでる実際の使いやすさのギャップがあると思う。Linuxのディレクトリを_ssh_でネイティブUIコンポーネントで見るっていうアイデアは、結構クールだと思う。確かに、いくつかは他の方法で解決されてるようにも見えるけど（例えばsshfsマウントみたいに）。

└

「Unixを理解しない人々」なんか面白いけど、これが根本的な問題なんだよね。昔の投稿かブログを思い出すな、プログラム可能なサーモスタットについて話してて、ほとんどの人には使いにくいっていう内容だった。要するに「人々はあなたの難解なシステムを学びたくない、ただその広告してる利益を得たいだけなんだ」ってこと。良いUIはそのギャップを最小限に抑える方法を知ってる。

└

これ、UNIXよりもPlan9に近いね。UNIXを神格化するつもりはないよ。

└

いや、今はもっと多くの人がLinuxを使ってるから、40年前に決まったUXの選択が疑問視されるようになってきたんだ。ほとんどの開発者向けのマシンにはSSHサーバーがインストールされててアクセスできるし。なんでSSHのターミナルは1960年代の文字だけのゴミみたいに見えなきゃいけないの？なんでTUIがSSHを通して使う最高のものなの？ターミナルで4K映画を見たり、ピンチでズームしながらウェブをブラウジングできないのはどうして？

Hacker Newsで議論の続きを見る

ハクソク