なぜ SSH はチャットより難しいか
LLM にシェルコマンドを書かせるのは小さな問題に聞こえます。違います。チャット製品で間違った答えは、ユーザーが読み直したり再び質問するコスト。シェルでは間違った答えのコストは、本番サーバーで実行されるコマンド。出力が実行されるとき、「十分」の閾値ははるかに高い。
TermAI v0.4 で AI コマンドヘルパーを出荷し、1 年のテレメトリを見てきました。約 3 分の 1 のユーザーが毎日使用；約半数が週単位で使用；4 分の 1 はほとんど触れません。毎日のユーザーが私たちが最も注意深く聞く相手 ── 彼らはすべての痛点を発見し、意見を持っています。
コンテキスト：どれだけ、何を
最初のバージョンはユーザーの質問だけを送り、他は何も送りませんでした。モデルはしばしばシェルコンテキストを誤って推測 ── Alpine なのに Ubuntu と仮定、zsh なのに bash と仮定、root でないのに root だと仮定。
そこでコンテキストを追加。でもどれだけ？
安価なのは完全なターミナルスクロールバックを送ること。やりませんでした、3 つの理由で：
- プライバシー。スクロールバックにはすべてが含まれる ── ファイル内容、出力、スクロールして消えた秘密。それをデフォルトでモデルに送るのは間違っていると感じました。
- トークンコスト。長いコンテキストは高価。AI ヘルパー使用は無料枠；呼び出しあたり 10 倍のコストは負担できません。
- 品質。直感に反して、より多くのコンテキストはしばしば答えを**害します**。モデルは新しい質問と無関係なスクロールバック内の古いエラーに食いつきます。
出荷された動作：ヘルパーは作業ディレクトリ、最後のコマンドの終了コード、（オプションで）最後の 5 行の出力を見ます。それで残りを漏らさずに答えを**このセッション**に根付かせるには十分。プロキシは転送前に IP、ホスト名、明らかな秘密を取り除きます。ユーザーは「素の prompt」のためにコンテキストを完全にオプトアウトできます。
機能する prompt 設計
プロンプトエンジニアリングはそれ自体エッセイに値しますが、1 年の反復後に収束したパターンは次のようなものです：
System: You are a shell command generator. Output ONLY a runnable
command, no explanation. If the request is ambiguous, generate the
most common interpretation. Do not include backticks or markdown.
Target shell: {detected_shell}
OS: {detected_os}
User: {question}
Context (last 5 lines of output):
{context_lines}注目すべき 2 つ。第一に、コマンドだけを、コマンドだけを出力するようモデルに伝える ── 前置きなし。モバイルユーザーは結果が欲しい、チュートリアルではない。第二に、システム prompt は明確化を求めるのではなく「最も一般的な解釈」と言う。ChatGPT でチャットを通じて明確化を求めるのは問題ない；ターミナルではそれが余分なラウンドトリップで流れを壊します。ユーザーがもっと具体的なものを欲しければ、結果を編集します。
実行前の確認
生成されたコマンドは決して自動実行されません。ヘルパーが提案を生成；あなたがタップしてターミナルに送る。これは当たり前に聞こえますが、製品全体で唯一最も重要な UX 決定です。ヘルパーがあなたを驚かせないからこそ、ユーザーは信頼します。
各提案に 3 つのアクション：Run はそのまま送信、Edit は入力行に落として調整、Dismiss は提案を閉じる。「シンプルなコマンドの自動実行」モードを検討し、短期間出荷しました。ユーザーは嫌いました。ls でさえタップが必要、なぜならヘルパーが次に提案するものは ls ではないかもしれないから。
エラーをコンテキストとして貼り付ける
最も使われるフローは結果的にコマンド生成ではなく、エラー分析でした。パターン：ユーザーがコマンドを実行、失敗、エラー出力を選択、「これについて AI に聞く」をタップ。ヘルパーはエラー、失敗したコマンド、コンテキストとしてのスクロールバックの最後の数行を取得 ── 何が間違っているかを説明します。
この機能だけでヘルパー使用量の 40% を占めるかもしれません。エラーメッセージは醜くて威圧的；LLM はそれらを解析するのが本当に得意です。入力がエラーのように見えるとき（sshd、nginx、systemd、docker などからの既知パターンと一致）検出し、より小さなモデルにより厳密なエラー説明 prompt でルーティングする fast-path を追加。より速く、より安く、しばしばより良い。
いつどのモデルにルーティングするか
これは最も頻繁に変わる部分。あなたが読む頃には詳細は違います。原則は違いません。
複数のモデルを使用。高ボリュームケース（シンプルなコマンド、エラー解析）には安くて速いモデル、難しいケース（複雑な多段階リクエスト、「nginx を TLS とリダイレクトで設定」）には遅くて賢いモデル。クライアント側の小さな分類器が、トークン数、特定のキーワードの有無、ユーザーの階層に基づいてどちらにルーティングするかを決定。
無料枠ユーザーはすべてに fast モデル（80%+ のケースに十分）。Pro ユーザーはデフォルトで賢いモデル、ピーク時のフォールバックとして fast モデル。
私たちが苦労して学んだ 5 つの教訓
- レイテンシは品質に勝つ。200ms のまあまあの答えは 800ms の素晴らしい答えより良い。モバイルユーザーは遅く感じるものを却下して自分でコマンドを入力します。
- コンテキストはダイヤルで、最大値ではない。より多くのコンテキストはしばしば害する。クエリタイプごとにチューニング。
- 決して自動実行しない。製品は信頼の上に構築されている。一つの驚きで失うのに十分。
- 失敗を翻訳するのではなく説明する。良いエラー分析は「これは X を意味する、Y を試す」 ── 「このエラーは Y/n prompt が回答されなかったことを意味する」ではなく。
- 無料枠は機能ではなく呼び出しを制限。1 日 20 回のフル機能セットは、薄まったモデルでの無制限呼び出しよりはるかに変換が良い。アップグレードで利益を得る人はする；そうでない人は圧迫を感じない。
クイックファクト
- 自然言語からコマンドへ:タスクを説明すると、実行前に確認できる shell コマンドを AI が提案
- 危険なコマンドはゲート:再帰的な削除、ディスクへの直接書き込み、再フォーマットなどの破壊的コマンドは明示的な確認が必要、通常コマンドはタップで実行
- 実際のコンテキスト:AI は OS/ディストリ、リアルタイムのディスク/メモリ/CPU、直近の出力とコマンド履歴を参照し、その端末に合ったコマンドを提案
- 無料枠:軽量モデルで AI 1日5回、深夜にリセット;Pro は無制限
- オプトイン:セッションが自動でモデルに送られることはなく、AI は質問ごとに呼び出す