sgpt を採用する前に読む: シェル統合と対話モードの実際

sgpt が埋めるのは「コマンドを思い出せない」という隙間

find の構文や ffmpeg のフィルタ指定を毎回検索するのは、作業の流れを切る小さなコストである。sgpt はこの隙間を埋めるために作られた CLI ツールで、README は「shell commands, code snippets, documentation」の生成を用途として挙げている。対象は Linux、macOS、Windows で、PowerShell、CMD、Bash、Zsh などの主要なシェルで動くと説明されている。

用途は技術的な設定から一般的な知識まで幅広いとされ、sgpt "What is the fibonacci sequence" のような単純な質問にも使える。ただし中心にあるのはコマンド生成であり、README の例はほぼすべて「探す手間を省く」文脈で書かれている。汎用チャットとして使うより、シェル上の補助として使うほうが設計意図に沿う。

プロンプトは引数と標準入力の両方から渡せる

sgpt はコマンドライン引数と標準入力のどちらからでもプロンプトを受け取る。README では git diff | sgpt "Generate git commit message, for my changes" のようにパイプで差分を渡し、コミットメッセージを生成する例が示されている。docker logs -n 20 my_app | sgpt "check logs, find errors, provide possible solutions" という例もあり、ログの解析とエラー箇所の指摘に使えるとされている。

リダイレクトも同様に扱える。sgpt "summarise" < document.txt、sgpt << EOF ... EOF のヒアドキュメント、sgpt <<< "..." のヒアストリングが README に列挙されている。つまり既存のシェルの入出力の仕組みをそのまま使い、sgpt 側で特別な入力形式を覚える必要はない。この点は、パイプ前提のワークフローに組み込みやすい。

--shell は OS と $SHELL を見てコマンドを出す

sgpt --shell（短縮形 -s）は、生成したコマンドを提示したうえで [E]xecute, [D]escribe, [A]bort の選択肢を出す。README によれば、sgpt は実行環境の OS と $SHELL を認識し、そのシステム向けのコマンドを返す。macOS で sgpt -s "update my system" とすれば sudo softwareupdate -i -a が、Ubuntu で同じプロンプトを投げれば sudo apt update && sudo apt upgrade -y が返る例が示されている。

パイプと組み合わせることもできる。sgpt -s "POST localhost with" < data.json では curl のコマンドが生成される。--no-interaction を付けると対話モードを無効にして標準出力にコマンドだけを出せるため、sgpt -s "find all json files in current folder" --no-interaction | pbcopy のようにクリップボードへ渡せる。実行前に必ず確認が入る設計なので、生成結果をそのまま実行する事故は避けやすい。

シェル統合は Ctrl+l で入力行を置き換える

sgpt --install-integration を実行すると、.bashrc または .zshrc に数行が追記され、ターミナルを再起動すると有効になる。以降は Ctrl+l（既定）で ShellGPT を呼び出せる。README の説明では、現在の入力行（バッファ）が提案コマンドで置き換わり、そのまま編集して Enter で実行できる。

この動作は、sgpt を毎回プロンプト付きで打つ手間をなくす点で実用的である。ただし提案は入力行を上書きする形で出るため、呼び出し前に入力していた内容は失われる。また README は変更が .bashrc / .zshrc に加わると明記しているので、シェル設定を dotfiles で管理している場合は差分として現れる。統合を外す手順は README には書かれていない。

--code は純粋なコードだけを返す

sgpt --code（短縮形 -c）はコードのみを出力するよう指示するモードである。README の例では sgpt --code "solve fizz buzz problem using python" に対して FizzBuzz の Python コードが返り、sgpt --code "solve classic fizz buzz problem using Python" > fizz_buzz.py のようにファイルへリダイレクトして python fizz_buzz.py で実行できるとされている。

標準入力からコードを渡すこともできる。cat fizz_buzz.py | sgpt --code "Generate comments for each line of my code" では、各行にコメントを付けたコードが返る例が示されている。出力がコードだけに限定されるため、ファイルへのリダイレクトやパイプと相性がよい。ただし生成されたコードが正しいかどうかを確認する仕組みはなく、実行は利用者の責任になる。

ローカルモデルは「無料で動く」が最適化されていない

既定では OpenAI の API と GPT-4 モデルを使う。API キーは初回に求められ、~/.config/shell_gpt/.sgptrc に保存される。OpenAI の API は無料ではなく、料金は OpenAI の価格ページを参照するよう README は案内している。

代替として Ollama などのローカル LLM バックエンドを使う方法が wiki で案内されているが、README は「ShellGPT is not optimized for local models and may not work as expected」と明記している。無料で動かせるという利点はあるが、動作が保証されているわけではない。API キーを外部に出したくない場合でも、この注意書きがある以上、ローカル構成は検証前提で考える必要がある。

対話型 CLI とエージェント型ツールの違い

sgpt は生成したコマンドを提示し、実行するかどうかを人間が選ぶ。この設計は、コマンドの意味を確認しながら進めたい場面に向く。一方、複数ステップの作業を自律的に進めるエージェント型のツールとはアプローチが異なる。sgpt にはタスクの計画を立てて複数のコマンドを連続実行する仕組みはなく、あくまで一度のプロンプトに対する提案と確認が基本である。

同種の CLI として、シェル統合や対話的な確認を備えない単純なラッパーもあるが、sgpt の特徴は OS と $SHELL を認識してコマンドを変える点、そして Ctrl+l で入力行に直接提案を差し込む点にある。逆に、長い手順を自動で実行させたい用途には向かない。

導入前に確認すべきこと

インストールは pip install shell-gpt で行う。初回起動時に API キーを求められ、~/.config/shell_gpt/.sgptrc に保存される。ライセンスは MIT で、リポジトリの情報から確認できる。

確認したいのは三点ある。第一に、sgpt --install-integration が .bashrc / .zshrc に追記する内容を実際に開いて見ること。第二に、API キーが平文で .sgptrc に置かれるため、そのファイルの権限とバックアップの扱いを決めること。第三に、利用するモデルの料金体系で、README は OpenAI の価格ページを参照するよう案内している。ローカルモデルを使う場合は、README 自身が最適化されていないと述べている点を踏まえ、自分の用途で期待どおり動くかを先に試す必要がある。

編集部の結論

シェル操作のたびに構文を検索しているエンジニア、特に Bash や Zsh で Ctrl+l による補完を使いたい人には向いている。逆に、API キーを外部に渡せない環境や、ローカルモデルだけで完結させたい人には勧めにくい。導入前に確認すべきは、sgpt --install-integration が .bashrc / .zshrc に追記する内容と、~/.config/shell_gpt/.sgptrc に保存される API キーの扱い、そして利用するモデルの料金体系である。

公式情報源

1. Issues
2. License: MIT
3. README
4. Releases
5. TheR1D/shell_gpt on GitHub