世界を動かす技術を、日本語で。

Crush: お気に入りのターミナル用の魅力的なAIコーディングエージェント

概要

  • Crushは、ターミナルで動作する 新しいAIコーディングアシスタント
  • 複数の LLM(大規模言語モデル) に対応し、柔軟な切り替えや拡張が可能
  • 主要OSのターミナル (macOS, Linux, Windows, FreeBSD)で利用可能
  • LSPやMCP による高度な拡張性とカスタマイズ性
  • 豊富な インストール方法 と簡単なセットアップ手順

Crush:ターミナルで使えるAIコーディングアシスタント

  • Crushは ターミナル上 で動作する、開発者向けAIアシスタント
  • 複数モデル対応 :OpenAI、Anthropicなど主要LLMを選択・追加可能
  • セッションベース :プロジェクトごとに独立した作業コンテキスト管理
  • LSP連携 :Language Server Protocolを活用した追加コンテキスト取得
  • MCP拡張 :http、stdio、sse経由で機能追加可能
  • クロスプラットフォーム :macOS、Linux、Windows(PowerShell/WSL)、FreeBSD対応
  • パーミッション制御 :ツール実行時の許可・ホワイトリスト・YOLOモード

インストール方法

  • Homebrew
    • brew install charmbracelet/tap/crush
  • NPM
    • npm install -g @charmland/crush
  • Arch Linux
    • yay -S crush-bin
  • Nix/NUR
    • nix-shell -p '(import <nur> { pkgs = import <nixpkgs> {}; }).repos.charmbracelet.crush'
  • Debian/Ubuntu
    • リポジトリ追加・aptでインストール
  • Fedora/RHEL
    • リポジトリ追加・yumでインストール
  • バイナリダウンロード
    • Debian/RPM形式や各種OS用バイナリ配布
  • Go経由
    • go install github.com/charmbracelet/crush@latest

初期設定と環境変数

  • APIキー入力 :Anthropic, OpenAI, Groq, OpenRouter等のAPIキーを用意
  • 環境変数対応 :各プロバイダ専用の環境変数で自動認識可能
    • 例:OPENAI_API_KEYANTHROPIC_API_KEYGROQ_API_KEYなど

設定ファイルとカスタマイズ

  • 設定ファイルの優先順位
    • ./.crush.json
    • ./crush.json
    • $HOME/.config/crush/crush.json
  • JSON形式 で各種設定を管理
  • LSP追加例
    • 言語ごとにコマンド・引数指定
  • MCP追加例
    • stdio/http/sseの各種プロトコル対応
    • 環境変数展開もサポート

パーミッションと安全性

  • ツール実行時の許可確認 がデフォルト
  • ホワイトリスト機能 で特定ツールの自動許可
  • --yoloフラグ で全許可(注意推奨)

カスタムプロバイダ対応

  • OpenAI互換API
    • Deepseekなどの独自API追加例
  • Anthropic互換API
    • カスタムAnthropicプロバイダ追加例

ロギングとデバッグ

  • ログファイル./.crush/logs/crush.logに出力
  • CLIコマンド でログ閲覧・追跡
    • 例:crush logs --tail 500crush logs --follow
  • デバッグモード
    • コマンドラインフラグや設定ファイルで有効化

コミュニティ・サポート

  • 公式SNS :Twitter, Discord, Slack, Fediverseでコミュニティ展開
  • Catwalk :モデル管理リポジトリ。貢献も歓迎
  • ライセンス :FSL-1.1-MIT。Charm製、オープンソース

まとめ

  • Crushは 柔軟性・拡張性・マルチOS対応 を兼ね備えたターミナルAIアシスタント
  • 多様な インストール方法簡単な初期設定
  • LSP・MCP による高度な拡張とカスタマイズ性
  • 安全性重視 のパーミッション管理と豊富なログ機能
  • オープンソース でコミュニティ主導の開発推進

Hackerたちの意見

これらの新しいツールの比較が知りたいな。Claude Code、opencode、aider、cortexとか。どのツールがどう違うのか、全体像がつかみにくいんだよね。

LLM研究で現在大きな問題の一つは、商業モデルとの比較や評価が非常に高額になることだよね。最近、共同執筆した論文では、研究を評価するためにさまざまな最先端の商業モデルに1万ドル以上使ったんだ。オープンウェイトモデルよりもずっと優れていることは簡単に(しかも安く)示せたけど、「最高のもの」と比較しなかったらレビューで評価が下がるのは分かってた。費用の問題を除いても(大学や小規模な研究所には厳しいよね)、学術研究が不透明な商業製品と比較することを求めるのは良くないと思う。例えば、OpenAIが推論を行うときに実際に何が起こっているのか、詳細がほとんどわからないし、技術スタックやモデルはいつでも変わる可能性がある。ユーザーは、モデルを使うたびに慎重に再ベンチマークしない限り、そのことに気づかない。学術誌は、彼らが使用しているアーキテクチャ、エンジニアリングスタック、トレーニングデータについて非常に正確な情報がない限り、商業モデルとの比較を控えるべきだと思う。

これは以前オープンコードだったけど、開発者同士のトラブルの後に名前が変わったと思う。

パフォーマンスはツールだけでなく、モデルや作業しているコードベース(コンテキスト)、与えられたタスク(プロンプト)にも依存するんだ。これらの要素は独立してないし、組み合わせによってはうまくいくものもあれば、そうでないものもある。例えば:

  • Claude Sonnet 4は、Claude Codeを使ったバックエンドのPythonコードの機能実装にはうまくいくかもしれない。
  • Gemini 2.5 Proは、フロントエンドのReactコードベースの大きな修正にはより効果的だ。 ...だから、ツールだけをテストして他の要素を一定に保つことはできないんだ。代わりに、ツール * モデル * コンテキスト * プロンプトの組み合わせの爆発的なテストが必要になる。16x Evalは問題の一部に対処できるけど、ツールのような要素はまだカバーしてないよ。 https://eval.16x.engineer/

大きな疑問は、これらの新しいエージェントの中で、どれがローカルモデルをある程度使えるかってこと。外部APIへの依存をなくしたいから、パフォーマンスを少し犠牲にする覚悟はあるよ。

CrushにはOllamaサポートを追加するオープンな課題があって、2週間経ってるけど進行中みたい。

sst/opencode

ほとんどのエージェントは、OpenAI互換のエンドポイントで動くよ。

Aiderはそう言ってるけど、まだ試してないんだ。 https://aider.chat/docs/llms.html

自分のソースに指示を出して、その機能を追加するように頼んだらどうなるの?

OpenHandsは、好きなLLMを設定できるよ。 https://github.com/All-Hands-AI/OpenHands

わお、このUIめっちゃ好き!今まで使った他のコーディングエージェント(例えば、Claude Code、aider、opencode)と比べて、これが一番使ってて楽しい感じがする。もう誰か、これでLLMプロバイダーを切り替えてみた人いる?他のコーディングエージェントではちょっとバグがあったから気になってるんだ。

Bubble Teaはいつも素晴らしいTUIだよ。React TUI(Claude Codeが使ってるやつ)はバグが多くて、いつもそれに逆らって作業しなきゃならない。

もう一つ、確かに見た目がすごくいいね。絶対にテストしてみるつもり。これらのツールに欠けてるのは、月額サービス(github copilot、claude code、openai codex、cursorなど)で認証できないことだな。これがあれば最高の追加機能になると思う。サブスクリプション持ってるけど、インターフェースが気に入らないこともあるから、切り替えられるといいな。

これのいいところは、まだ初期段階で、コードがすごくクリアでスキーマ的だってこと。エージェントをツールコールやセッション、自動要約、永続性を持たせてレイアウトするための青写真が欲しいなら、このコミットリンクを保存しておくといいよ。

情報ありがとう!君の判断を信じてるから、このリポジトリがもっと面白くなったよ。

これらのターミナルベースのAIコーディングエージェントが、テキストUIを派手にしようとする試みが多いのが不思議だよね。たくさんのホワイトスペース、ラインアート、ウィジェット、アスキーアート、グラデーション、そして今やアニメーションまで。だけど、期待されるキーバインディングやタブ補完、一貫したスクロールバック、さらにはちらつきのないテキストレンダリングが全然ないんだ。(少なくとも、これに関してはnode.jsで書かれてないみたいだから、ターミナル出力が大きな再描画を最小限に抑えるように最適化されてる可能性もあるかな?)でも、コマンドプロンプトを実行するという同じインタラクションモデルを持っているにも関わらず、REPLやCLIのようには全然動かないんだよね。それに、フルスクリーンのUnix TUIのような感じもしないし、エディタやリーダープログラム(メールリーダー、ニュースリーダー、ブラウザ)とも違う。これは新しい参加者がClaude Codeを真似してるだけなのか、それともこのトレンドはもっと前から始まってたのかな?(これがAiderが今でもお気に入りの理由の一つだよ。REPLらしい見た目と感触があるから。)

フル機能のユーザーインターフェースを作るより簡単だから、もっとたくさん見ることができるんだよね。

少なくとも、emacs内でClaude Codeを使うことができるよ: https://github.com/stevemolitor/claude-code.el

これらのインターフェースは急速に支持者(そして開発者!)を得ていると思う。彼らはグラフィカルなIDE風のエディタを好んで使っているからね。開発者の中でも、みんながターミナルウィンドウで生活しているわけじゃないんだ。(そう聞いてるけど、X/Waylandを立ち上げるのが面倒な日もあるし。)

いや、このタイプのテキストUIは、AIエージェントが現れる前からcharmbraceletの特徴だったんだ。伝統的なTUIとは違って、キーバインディングが直感的に見つけやすいから、すごく好きなんだよね。

この特定のツールは、コマンドラインを魅力的にすることをミッションにしているCharmという会社のものだよ。LLMブームの前から数年活動しているんだ。彼らはgolang用のCLIフレームワークとそのためのツールを作っている。

まあ、これがまさに僕がジャン=ピエールに取り組んでる理由なんだよね。[0] これはこういうものだよ:

「ソフトウェアプログラマーの日常業務をサポートするためのコマンドラインツールキット。既存のワークフローに統合できるように作られていて、LLMと一緒に柔軟でパワフルなペアプログラミング体験を提供します。」 DCD[1]のチームが僕の作業を資金提供してくれてるんだけど、ローカルファーストでオープンソースなCLI駆動のプログラミングアシスタントには大きな可能性があると思ってるんだ。もちろん、これは競争が激しい分野で、日々さらに混雑してるけど、まだ改善の余地がたくさんあると思う。基本的な部分にはまだ取り組んでるけど、Claude Codeに似たエージェント的なワークフローをサポートする方向に近づいてるところだよ。UnixのDOTADIWの哲学を使って、既存のワークフローやエディタ、ツールに基づいて構築してるんだ。今はファイルフォーマットに破壊的な変更を加えてるから、あまり大々的に宣伝する状態じゃないけど、もう少し進んだら、過去数ヶ月間に僕たちが既存のターミナル設定やエディタ、ローカルシェルスクリプトに統合してきたように、みんなにも役立つといいなと思ってるよ。[0]: https://github.com/dcdpr/jp [1]: https://contract.design

君がどれだけ若いかを見せてるね。 ;-) BBS時代に育った者として、カラフルなテキストベースのものは楽しい思い出を呼び起こすよ。自分のターミナルCLIコーディングエージェントを作ってるんだ。完成したら、ASCIIアートでこんなにカラフルにするつもりなんだけど、今は機能に集中してるよ。

NCに戻る感じだね(ノートンコマンダー)

僕が気になるのは、ターミナルの良さって、コマンドを書いて、いろんなソースやプログラムからのアクションや出力をログとして順番に見るスクロールワークフローなんだよね。だから、僕が求めてるのは、リッチなフルHTMLのマルチプログラムスクロールワークフローなんだ。なのに、みんな最悪の両方を組み合わせちゃってる。何やってるんだ? 優れたレンダリングシステムで優れたUIを提供してくれよ、劣ったUIなんていらないんだ、くそっ。

派手なTUIは数年前からあるよ。TUIフレームワークのギャラリーをチェックしてみて:https://ratatui.rs/showcase/apps/ https://github.com/charmbracelet/bubbletea/tree/main/example... https://textual.textualize.io/ 彼らの長所と短所についてブログ記事を考えてるところなんだ。君の言う通り、テキスト入力は本当のREPLって感じがしないね。多分、readlineを使ってないからだろうね。それに、画面スペースに余裕があるから、もっと境界線や余白が見えるんだ。でも、マウスサポートや発見可能なコマンド、色のヒントみたいな利点もあるよ。ところで、誰かが普通のGUIを作るのと、君のワークフローに合わせた普通のGUIを作るの、どっちがいい?

それは「魅力的」って感じだね、イギリス英語でも。 https://dictionary.cambridge.org/dictionary/english/glamorou...

デモGIFで何が起こってるかを実際に「読む」ことができるようにしたい人のために、ffmpegでスローダウンして動画に変換したよ: https://share.cleanshot.com/XBXQbSPP

最近、Crushをいじってみてるんだけど、その可能性に本当に期待してる。Charmをしばらくフォローしてて、彼らはDXを理解してる数少ないグループの一つで、開発者が好きなツールを一貫して出してるんだ。AIコーディングレースに参加するのを見るのが楽しみだね。まだ始まったばかりだけど、これは実際に使ってる人たちが作ったツールだって明らかだよ。

15分くらい真剣に使ってみた。Claude Codeと比べて、良い点: - 美しいUI - 便利なサイドバー、変更されたファイルやコストを追跡できる - 変更を受け入れるためのUXが良い(ホットキーがあって、きれいなdiffを表示する) 悪い点: - モデルを組み合わせられない。Claude Codeは、単純な検索にはHaiku、思考にはSonnetを組み合わせて使うのがいいんだ。 - ディレクトリに説明のないゴミのバイナリファイルがたくさん追加される。多分、どこかのドキュメントに書いてあるんだろうけど。 - 最初のinitで作られるCHARM.mdは役に立とうとしてるけど、モデルに知ってほしいこととは思えない内容ばかりだった。例えば、僕のGoテストはPascalCasingを使ってる、例えばTestCompileみたいな簡単なこと。 - Ctrl+Cで終了したらターミナルがクラッシュした。

最初のinitでCHARM.mdが作られる お願いだからやめてくれ…有名な単一エージェントの指示ファイルの標準を、AGENT.mdみたいに合意できないかな? [1] そう、これはAmpが彼らのCLIツールのために宣伝してる標準なんだ、皮肉だね。そうじゃないと、こんなハックに頼ることになる [2] [1] https://ampcode.com/AGENT.md [2] https://kau.sh/blog/agents-md/