CLIツールのGUI化は、これまでツール作者側の協力を強く求める作業だった。Instagui 0.1.0は、その前提を外側から崩そうとしている。Omar Soutari氏が公開したこのオープンソースツールは、対象コマンドの--helpを読み、Claude APIでJSONスキーマへ変換し、127.0.0.1で動くWebフォームをブラウザに開く。ユーザーはフォームを埋めながら実行コマンドを確認し、最後にローカルでCLIを走らせる。

The Registerによると、Soutari氏はffmpegのフラグを何度も検索していた経験からInstaguiを作った。GUIに必要な情報は多くのCLIのヘルプ出力にすでにある、という発想である。新しさは、CLIをGUIにすること自体ではない。AIがヘルプ文を読んで操作面を組み立てるため、元のツールがPython製かどうか、作者がGUI用のコードを足したかどうかに依存しにくい点にある。

AD

Claudeが読むのはヘルプ出力だ

Instaguiの流れは短い。npx instagui ffmpegのように起動すると、まず対象ツールの--helpを取得する。READMEによれば、失敗した場合は-h、help、manページへ順にフォールバックし、止まらないようにタイムアウトとサイズ上限を置く。次に、そのヘルプ文をClaude APIへ送り、オプション名、フラグ、型、説明をJSONスキーマへ変換する。選択肢と必須項目も入り、グループや位置引数も扱う。

ここで使われるモデルはREADME上ではclaude-haiku-4-5とされている。生成結果はZodなどで検証され、無効な出力は1回だけ再試行される。スキーマができると、Instaguiは単一ページのフォームをhttp://127.0.0.1で配信する。フォーム部品は、チェックボックスやドロップダウンのほか、数値入力やテキスト入力などをスキーマの型から選ぶ。

この設計は、CLIを隠す方向には振り切っていない。フォームを編集すると、Instaguiは実際に実行されるコマンドを表示する。実行時も文字列をシェルに渡すのではなく、Node.jsのspawnへ引数配列として渡す。フォーム入力に;や&&が含まれても、シェルが解釈する追加コマンドにはならない、という安全策である。

Gooeyとの違いは、作者の協力を前提にしない点

CLIをGUI化する道具には先行例がある。たとえばGooeyは、Python 3のコンソールプログラムをGUIアプリに変換するライブラリだ。READMEでは、argparse宣言を持つメソッドに@Gooeyデコレータを付ける使い方が示されている。実行時にはArgumentParserへの参照を読み取り、アクションに応じてウィジェットを割り当てる。

この方式は、CLI作者が協力できる場合には強い。引数定義そのものを読むため、ヘルプ文を推測するよりも確かな材料がある。ただし、対象はPythonプログラムに寄り、既存バイナリや他言語製ツールにはそのまま届きにくい。Instaguiは逆に、情報源を--helpへ寄せることで、言語や実装方式をまたぐ。

その代わり、Instaguiはヘルプ文の品質に影響される。The Registerに対し、Soutari氏も不完全なヘルプ文が弱点になり得ると認めている。README上の非対象にも、その制約は表れている。v0.1ではvim、top、REPLのような対話型/TUIプログラム、git commitとgit pushのようなサブコマンドツリー、ネイティブのファイル選択ダイアログは扱わない。

AD

費用は初回抽出に寄る

Instaguiはオープンソースだが、未知のCLIを初めて解析するときにはClaude APIの呼び出しが必要になる。READMEでは、スキーマの解決順序を4段階に分けている。ユーザーが--schemaで指定したファイル、~/.instagui/のキャッシュ、同梱スキーマ、最後にClaude APIによる新規抽出である。

この順序のため、費用は毎回発生するわけではない。ffmpeg、yt-dlp、pandocは同梱スキーマがあるためAPIキーなしで使える。過去に抽出したツールもキャッシュから起動できる。新しいツールに初めて向けたときだけANTHROPIC_API_KEYが必要になり、READMEは「APIキーがない場合もスタックトレースへ落とさず、何をすべきかを表示する」と説明している。

採用の広がりは、共有スキーマの数に左右される。Soutari氏はThe Registerに対し、よく使われるツールのスキーマをコミュニティで育てたいと述べている。実際、READMEはtest/fixtures/<tool>-help.txtでヘルプを捕捉し、生成スクリプトを通してschemas/<tool>.jsonを作る貢献手順を示す。生成時には、すべてのフラグが元のヘルプ文に存在するかを確認するガードも置かれている。

127.0.0.1でも、実行リスクは残る

Instaguiはローカル単独利用を前提に設計されている。サーバーは127.0.0.1にだけバインドされ、POST /runとPOST /stopは一致するOriginヘッダーを要求する。実行は一度に1件で、タブを閉じてストリームが切れると子プロセスを止める。APIキーはログや配信ページに出さず、外へ送られるのはスキーマ抽出に使うヘルプ文だけだとREADMEは説明する。

それでも、このツールは本物のCLIを実行する。プレビューが見えること、シェル文字列を作らないこと、ローカルに閉じることはリスクを減らすが、危険なオプションを選んだユーザーの代わりに判断するわけではない。フォームは端末操作を柔らかくするが、実行対象が削除、上書き、ネットワーク送信を行うなら結果もそのまま起きる。

Instagui 0.1.0の価値は、CLIを初心者向けに薄めることより、既存CLIの操作面をあとから作れる点にある。今後の確認点ははっきりしている。サブコマンドや対話型ツールに進めるのか。共有スキーマがどこまで増えるのか。生成スキーマを人間がレビューできる運用が保たれるのか。そこが揃うほど、AIはCLIの代替物ではなく、CLIの入口を増やす層として効き始める。