dejaは履歴をどう予測するか: zshの行内ゴーストテキスト
zsh の予測インライン シェル自動提案 - Go デーモン、TUI なし、同期なし。
ひと目でわかる
- これは何？
- fuzzy matching、ディレクトリ、実行順、SQLiteを組み合わせるzsh補完候補の仕組みと導入時の注意点を具体的に見ます。
- 誰に向いている？
- dejaは、READMEに記載された構成と用途が自分の環境に合う人向けです。合わない人は採用すべきではありません。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 8 日前です。
- 何の言語で書かれている？
- 主に Go です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月14日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
履歴の次の一手を候補にする
通常の履歴検索が入力文字列の先頭一致に寄るのに対し、dejaは文字を飛ばした入力や順序の揺れも候補にします。現在のディレクトリを順位へ反映し、make buildの後にmake testを実行する、といった系列も予測します。これはコマンドを実行する機能ではなく、入力行に候補を提示する機能です。
候補の妥当性は、履歴に似た名前のコマンドを用意し、異なるディレクトリで同じ接頭入力を試すと見えます。表示された候補と実際にEnterで実行されるバッファは別なので、READMEの説明どおり右矢印で受け入れる操作も確認します。
dejaの確認では、READMEに書かれた対象を一度に広げず、1番目の論点に対応する入力、処理結果、ログまたは生成物を分けて記録します。機能が使えるという説明と、特定のOS、版、権限、データ量で期待どおりに動くという判断は同じではありません。deja固有の設定名やファイル名を残しておけば、別の環境で再確認する際にも、どの記述を根拠にした判断かを追跡できます。
frecencyとSQLiteの境界
頻度と新しさを混ぜたスコアは、1週間の指数減衰を使うとREADMEにあります。daemonは全ターミナルウィンドウから共有され、応答は1 keystrokeあたり1ms未満と主張されています。数値は環境依存の自称値であり、測定条件やDBの上限は資料にありません。
履歴をimportした直後と、同じコマンドを繰り返した後で候補順位を比べると、頻度と新しさの影響を確認できます。SQLiteファイルの場所、バックアップ、複数ユーザーの分離は、実行環境で確認すべき未記載項目です。
dejaの確認では、READMEに書かれた対象を一度に広げず、2番目の論点に対応する入力、処理結果、ログまたは生成物を分けて記録します。機能が使えるという説明と、特定のOS、版、権限、データ量で期待どおりに動くという判断は同じではありません。deja固有の設定名やファイル名を残しておけば、別の環境で再確認する際にも、どの記述を根拠にした判断かを追跡できます。
zshへの統合方法の違い
Homebrewではdejaを入れ、deja importを実行し、deja init zshを.zshrcへ追加してshellを再読み込みします。curl installerも提示され、Oh My Zsh、zinit、手動配置という別経路があります。インストーラとプラグインを二重に有効化しないこと、zsh-autosuggestionsと同時に列挙しないことが明記されています。
既存環境ではまず~/.zshrcのdeja行とzsh-autosuggestionsの有無を確認します。deja init zshは統合スクリプトを~/.local/share/deja/init.zshへ書き出しsource行を表示するため、毎回evalする方式との起動コスト差もREADMEが説明しています。
dejaの確認では、READMEに書かれた対象を一度に広げず、3番目の論点に対応する入力、処理結果、ログまたは生成物を分けて記録します。機能が使えるという説明と、特定のOS、版、権限、データ量で期待どおりに動くという判断は同じではありません。deja固有の設定名やファイル名を残しておけば、別の環境で再確認する際にも、どの記述を根拠にした判断かを追跡できます。
キー操作が担う確定と抑制
右矢印は全文受け入れ、Ctrl+右矢印は次の単語だけを受け入れます。Tabは候補picker、Ctrl+Xは現在の候補をセッション単位で抑制し、Shift+左右はfuzzy presetを切り替えます。空のプロンプトでゴースト表示を切り替えるキーも状態を保存します。
Enterは表示されたゴーストを採用せず、バッファに文字として入っている内容を実行します。この差を理解しないと予測入力の検証を誤ります。各キーを再割当した場合は、通常入力、候補確定、候補消去、次回shellへの状態保持をそれぞれ確認します。
dejaの確認では、READMEに書かれた対象を一度に広げず、4番目の論点に対応する入力、処理結果、ログまたは生成物を分けて記録します。機能が使えるという説明と、特定のOS、版、権限、データ量で期待どおりに動くという判断は同じではありません。deja固有の設定名やファイル名を残しておけば、別の環境で再確認する際にも、どの記述を根拠にした判断かを追跡できます。
履歴を除外する規則
先頭空白をHIST_IGNORE_SPACEで除外したコマンドや、HISTORY_IGNOREに一致するコマンドは、~/.zsh_historyだけでなくdejaにも入らないと説明されています。ローカル保存という性質だけで、履歴が必ず取り込まれないと考えてはいけません。
除外設定を一つずつ有効にし、deja import前後で候補に現れないことを確認します。履歴ファイルを--fileで指定する経路もあるため、HISTFILEがexportされていないzshでは、読み込むファイルを明示した時の結果を確認します。
dejaの確認では、READMEに書かれた対象を一度に広げず、5番目の論点に対応する入力、処理結果、ログまたは生成物を分けて記録します。機能が使えるという説明と、特定のOS、版、権限、データ量で期待どおりに動くという判断は同じではありません。deja固有の設定名やファイル名を残しておけば、別の環境で再確認する際にも、どの記述を根拠にした判断かを追跡できます。
向く人とMITの範囲
dejaはMITで、zshの行内候補をローカルだけで使いたい人、ディレクトリやコマンド系列を検索順位へ反映したい人に合います。TUIや同期サーバー、アカウントを必要とする設計ではありません。READMEは応答値を示しますが、予測精度や対応シェル以外の保証はしていません。
履歴を外部へ出したくない端末でも、SQLiteとdaemonの保存場所を確認してから採用します。zsh以外のshell、候補を別ペインで見たい操作、既存プラグインとの併用を前提にする場合は、READMEの統合モデルと一致しません。
dejaの確認では、READMEに書かれた対象を一度に広げず、6番目の論点に対応する入力、処理結果、ログまたは生成物を分けて記録します。機能が使えるという説明と、特定のOS、版、権限、データ量で期待どおりに動くという判断は同じではありません。deja固有の設定名やファイル名を残しておけば、別の環境で再確認する際にも、どの記述を根拠にした判断かを追跡できます。
編集部の結論
dejaは、READMEに記載された構成と用途が自分の環境に合う人向けです。合わない人は採用すべきではありません。先にdejaのREADMEにある具体的な入力、出力、設定、実行経路を小さな検証環境で確認し、未記載の保証を補って考えないでください。
コミュニティノート