Atuinはシェル履歴をSQLiteと暗号化同期で再設計する
あなたのシェルを魔法のようなものにしましょう。さらに、Atuin サーバーを介して、オプションでマシン間の履歴の_完全に暗号化された_ 同期を提供します。
ひと目でわかる
- これは何？
- zshやBashなどの履歴をSQLiteに保存し、終了コードや作業ディレクトリを含む検索と、任意の暗号化同期を提供します。
- 誰に向いている？
- 複数端末で同じ履歴を検索したい開発者、終了コードや実行時間を後から調べたい運用者に向きます。履歴を外部サーバーへ出せない環境では同期を使わずローカル機能だけを選ぶべきです。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Rust です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月14日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
履歴をファイルからデータベースへ
Atuinは既存のシェル履歴を置き換えるのではなく、SQLiteデータベースにコマンドと追加コンテキストを記録する設計です。READMEが挙げる項目は終了コード、cwd、ホスト名、セッション、コマンド実行時間です。単なる文字列検索より運用上の絞り込みに向きますが、収集する情報が増えるため、端末名やディレクトリ名に機密情報が含まれないかを先に確認します。
ctrl-rから条件付き検索へ
ctrl-rとupを全画面検索UIへ再割り当てでき、現在のセッション、ディレクトリ、全体というフィルターモードを切り替えられます。READMEの例は、成功したmakeを昨日の15時以降に絞るatuin search --exit 0 --after "yesterday 3pm" makeです。Enterは実行、Tabは編集なので、検索結果をそのまま投入する操作と編集する操作を分けて確認します。
同期は任意で暗号化される
Atuinはホスト側のサーバーを使う方法、自分でサーバーを運用する方法、同期を使わない方法を並べています。READMEは履歴同期が完全に暗号化され、サーバー運営者でもデータにアクセスできないと説明します。ただし、暗号化の実装詳細、鍵の復旧手順、組織の保持要件はREADMEだけでは分かりません。同期を有効にする前にその点を公式ドキュメントで詰めます。
対応シェルと初回セットアップ
対応シェルはzsh、bash、fish、nushell、xonsh、PowerShellです。Quickstartではsetup.atuin.shから導入し、atuin register、atuin import auto、atuin syncを順に実行してシェルを再起動します。これはAtuin Cloudへの登録例であり、オフライン構成や自ホストサーバーは別のドキュメント入口です。環境に合わせて同期を省略した手順を選びます。
Bashではフックを確認する
READMEはBash利用時にbash-preexecを設定するが、フックには制限があると明記しています。したがって、Bashだけを対象に「導入できた」という判断は不十分です。サブシェル、長時間コマンド、異常終了、cwdの変更、履歴import後の重複を検証し、既存のPROMPT_COMMANDや他の履歴拡張との干渉をログで確認します。
採用判断とライセンス
MITライセンスで、リリースにはv18.20.1が記録されています。向いているのは端末横断の検索と履歴共有に価値がある人で、同期の暗号化だけを根拠に秘密情報の扱いを決める人には向きません。検証ではSQLiteに期待した件数が入り、--exitと--afterの条件が意図どおり絞り込み、同期前後で復号された履歴の内容と端末差分が一致するかを確認します。
検証では、既存の履歴ファイルをバックアップしてから専用ユーザーでatuin import autoを実行し、SQLite内の件数と元ファイルの代表行を照合します。ctrl-rで現在のディレクトリだけを選んだ結果、--exit 0、--after、検索語の組み合わせが期待どおり動くかを確認します。履歴に含まれるトークンやパスワードをダミー値で再現し、同期を有効にした場合と無効にした場合の保存範囲を分けて観察します。Bashではbash-preexecの導入前後で既存フックの終了コードが変わらないか、zshではupキーの操作が他のキーバインドと衝突しないかを確認します。
Atuinの検索性は、履歴を正しく記録できて初めて役に立ちます。短いコマンドだけでなく、パイプ、複数行、終了コードが異なる処理を試し、cwdと実行時間が検索結果に反映されるかを確認します。古い履歴ファイルが置き換えられないという説明も、導入前後のファイル差分で確かめます。複数端末の同期では、片方で編集したコマンドがもう片方にいつ現れるか、同じコマンドが重複しないか、登録解除後にローカル検索が使えるかを確認します。暗号化の主張と実際のアクセス制御は別の検証項目です。
導入を戻す場合のため、既存履歴とキーバインドのバックアップを残します。同期を使わない利用でも、SQLiteデータベースの権限とバックアップ方法を決め、端末廃棄時に履歴が残らない手順を用意します。
Atuinの検証では、検索結果からEnterを押したときの実行対象を必ず目視します。履歴の収集範囲を利用者へ伝え、同期の有無を端末ごとに把握できる状態で運用します。
導入前には、対象版のリリースと実行環境を記録します。入力と出力を固定した小さな試験を作り、成功だけでなく失敗時の状態も保存します。設定ファイルの既定値を確認し、変更した値を一覧にします。権限は必要な範囲に絞り、管理者操作と通常利用を分けます。ログには時刻、版、対象、結果を残します。外部サービスを使う場合は通信先と認証の境界を確認します。更新時は同じ試験を再実行し、以前の結果との差を見ます。素材にない性能や安全性を数値として補いません。READMEの機能説明と実際の動作が異なる場合は、動作を優先して原因を調べます。
編集部の結論
複数端末で同じ履歴を検索したい開発者、終了コードや実行時間を後から調べたい運用者に向きます。履歴を外部サーバーへ出せない環境では同期を使わずローカル機能だけを選ぶべきです。導入前に既存履歴の保存先、bash-preexecの影響、同期対象に秘密値が混じる可能性を確認し、まず一つの検証シェルでimportとsearchの結果を照合します。
コミュニティノート