guides

EspansoのYAML設定からGUIテキストエキスパンダーへの移行

Trofin Sorin-IoanTrofin Sorin-IoanCTO, Lightning Assist2026年7月26日9 分で読了
espansoyamlmigrationguitext-expanderlinuxwindowsmacos
シェア:

簡単な回答: Espansoはすべてのスニペットを、YAML形式のmatchファイル(~/.config/espanso/match/*.yml)内でtriggerreplaceのペアとして保存します。つまり、スニペットを追加・編集するたびにテキストエディタを開き、YAMLのインデントルールを守り、テストのためにサービスを再起動する必要があるということです。Lightning AssistのようなGUIテキストエキスパンダーへ移行するということは、各matchをビジュアルエディタ上のスニペットとして作り直すことを意味します——同じトリガーのテキスト、同じ置き換え内容ですが、ファイルの代わりにフォーム入力欄になります。現時点ではYAMLの一括インポートはできないため、移行はスニペット1件ずつの手作業になります。50件未満のライブラリであれば、たいてい15分もかからず終わります。

開示:私たちは有料のテキストエキスパンダー Lightning Assist を開発しており、Espanso は競合製品にあたります。Espanso は無料のオープンソースソフトウェアで、以下の解決策はすべて Espanso 自体に対するものです。乗り換えを必要とするものは一つもありません。

~/.config/espanso/match/base.ymlを一度も開いたことがない方には、ここまでの話はピンとこないかもしれません。そしてそれこそが、このガイドが想定する読者です。つまり、Espansoを動かせるようになり、十数個のスニペットを追加してみたものの、YAMLのことを一切考えずに済むバージョンがあるのではないかと思い始めている人たちです。

EspansoのYAML設定が摩擦になる理由

Espansoは本当によく作られたソフトウェアです。無料でオープンソース、クロスプラットフォームであり、ファイルベースのモデルは見落としではなく意図的な設計上の選択です——YAMLは移植性があり、差分を取りやすく、スクリプトからも扱えます。摩擦が表面化するのは後になってから、実際に日々使い始めてからです。

matchファイルがファイルシステム内に分散する。 Espansoは設定をmatch/フォルダ(何を展開するか)とconfig/フォルダ(展開の挙動をどう制御するか)に分けて管理しており、起点はmatch/base.ymlです。スニペットの数が増えるにつれ、1つのファイルに追加し続けるか、複数の.ymlファイルに分割していくことになります——どちらにしても、半年後に「料金についてのあれ」を探すには、検索ボックスがないためファイルを開いて目で探すしかありません。

インデントそのものが構文になる。 基本的なmatchは次のようになります。

matches:
  - trigger: ":br"
    replace: "Best Regards,\nJon Snow"

Espanso自身のドキュメントもこの点をはっきりと述べています。「インデントを必ず含めてください。さもないと有効なYAML構文にはなりません」。テキストエディタの扱いに慣れた開発者であればそれで問題ありませんが、Slackからスニペットを貼り付けたり、複数行のブロックをコピーした際に空白がうまく引き継がれなかったりすると、まさに静かに壊れる典型例です。たいていの場合、気づくきっかけはトリガーが展開されないことだけです——ダイアログも赤い波線も出ず、迷い込んだ余分な空白を探し当てるまで、スニペットはただ黙って何もしません。

同期もチーム共有もない。 Espansoは設計上、すべてをローカルに保存します——プライバシーの観点では本当に優れていますが、その代わりスニペットを2台目のマシンに持っていくには、手動でのファイルコピーか、Dropboxフォルダか、自分で維持するgitリポジトリが必要になります。アカウントも組み込みのマルチデバイス同期もなく、同僚にスニペットライブラリを渡す方法は、.ymlファイルを送って正しいフォルダに置いてもらうよう頼む以外にありません。

テストのたびに再起動が必要。 matchファイルを編集して動作を確認するには、たいてい保存してからテスト対象のアプリに切り替え、トリガーを入力し——もし発火しなければ——ファイルを確認しに戻る、という流れになります。短いループではありますが、変更のたびに、これからもずっと繰り返すことになるループです。

だからといってEspansoが悪いソフトウェアというわけではありません。設定をコードとして扱うことに抵抗がない人向けに作られたソフトウェアだ、というだけのことです。もしそこに時間を使いたくないのであれば、解決策はGUIです——「もっと良い」YAMLエディタではありません。

GUI版は実際にはどういうものか

GUI版のテキストエキスパンダーでは、スニペットはファイルではなく1行のデータです。パネルを開き(Lightning Assistでは「My Snippets」です)、「Create Snippet」をクリックして、片方のフィールドにトリガーを、もう片方に展開内容を入力し、保存するだけです。探すべきファイルはなく、再起動が必要なサービスもなく、正しく合わせるべきインデントもありません——そもそもインデントという概念自体が存在しないからです。リッチテキスト、HTML形式、複数行の内容は、いずれもエスケープ処理なしで展開フィールドに直接入力・貼り付けできます。スニペットは自分で名前を付けたフォルダに整理でき、ファイルを目で探す代わりにライブラリ全体を検索できます。

トレードオフは想像どおりのものです。ファイルへの直接アクセス(スニペットの履歴をgit diffで見たり、Vimで編集したりすること)を手放す代わりに、そもそもYAMLの仕組みを一切必要としなくなります。

Espanso → Lightning Assist:概念対応表

すでにEspansoの用語で考える習慣がある方向けに、それぞれの概念がどう対応するかをまとめました。

Espansoの概念 YAMLでの表現 GUIでの対応
Match .ymlファイル内のmatches:の下にあるエントリ スニペット——Snippetsパネル内の1行
Trigger trigger: ":br" Triggerフィールド——同じ略語をそのまま入力するだけ。コロンは残したい場合のみ付ければよい
Replace replace: "Best Regards,\nJon Snow" スニペットの展開テキスト——リッチテキスト、HTML、複数行の内容をネイティブにサポート
Vars/拡張機能(日付、シェル、クリップボード、フォーム) 変数の種類を参照するvars:ブロック 展開内容に挿入するプレースホルダー——[#Date#][#Name#]、クリップボード変数など
Matchファイルbase.yml、独自の.yml ~/.config/espanso/match/内のファイル Snippetsパネル内のフォルダ——ファイル名ではなく見た目で整理
リロード/espanso restart 変更を反映するための手動サービス再起動 何もする必要なし——保存した瞬間にスニペットが有効になる
正規表現トリガー、シェルコマンドmatch YAML+スクリプト、Espanso特有の機能 再現されていない。 これがワークフローの中心であれば、その用途にはEspansoを使い続けてください

最後の行は重要です。これは移行ガイドであって、「Lightning AssistはEspansoにできることを全部できる」という主張ではありません。正規表現パターンのトリガーやシェルコマンドに基づくmatchは、Espansoならではの強みであり、ここにはGUI版の対応物がありません。

手順ごとに解説:スニペットを手動で移行する

  1. 既存のmatchを洗い出す。 ~/.config/espanso/match/base.ymlと、自分で作成したその他の.ymlファイルをすべて開きます。triggerreplaceのペア1つ1つが、作り直す対象です。
  2. GUI版のエキスパンダーをインストールし、設定ファイルの作成は不要。 Lightning Assistを14日間無料でお試しください——クレジットカード不要です。アプリはスニペットパネルへ直接開くので、最初に書くべき設定ファイルはありません。
  3. 各matchをスニペットとして作り直す。 New Snippetをクリックし、トリガーのテキストをTriggerフィールドに貼り付け(:br/addrといった記法が気に入っているならそのまま維持して構いません——どんなテキストでも有効なトリガーになります)、replaceの内容を展開フィールドに貼り付けます。
  4. 変数をプレースホルダーとして作り直す。 日付の変数は[#Date#]プレースホルダーに、クリップボードの変数はクリップボード用プレースホルダーになります。プレーンテキストはそのままプレーンテキストです。シェルコマンドの変数や正規表現トリガーには直接対応するものがないため、必要であればそれらのmatchはEspanso側に残しておきましょう。
  5. トリガーモードを設定する。 As-You-Type展開(トリガーを入力すると、その場でインライン展開される)がデフォルトで、設定は不要です。トリガー入力後にキーを押す方式にしたい場合は、Settings → Triggersで一度だけ設定してください。
  6. 何かを削除する前にテストする。 試し書き用のドキュメントで各スニペットを試してみましょう。移行したセットが期待どおりに動くと確認できるまでは、Espansoの設定はそのまま残しておいてください——一時的に両方が併存していても何も問題はありません。

かかる時間については現実的に見積もっておきましょう。現時点ではYAMLの一括インポートはできないため、すべてのスニペットを手作業で作り直すことになります。50件未満のライブラリであれば、たいてい15分もかからず終わります。100件以上を移行する場合でも、YAMLの構造のおかげで少なくともコピー&ペーストは単純です——各ブロックからtriggerとreplaceの値を読み取り、対応するGUIのフィールドに貼り付けていくだけです。

得られるものと、手放すもの

得られるもの: 設定ファイルが不要になり、テストのたびの再起動ループもなくなり、フォルダで整理された検索可能なスニペットライブラリが手に入ります。さらに、ホットキーから選択したテキストを書き換えたり翻訳したりするAIコマンド、同じアプリ内でのプッシュ・トゥ・トーク方式の音声テキスト入力、デバイス間の自動クラウド同期、必要であればチームでのスニペット共有も使えます。これらはすべて、同じアカウントでWindows・macOS・Linuxのいずれでも動作します。

手放すもの: Espansoは無料かつオープンソースで、それはこれからもずっと変わりません——Lightning Assistの無料プランはスニペット3件までに制限されており、無制限のスニペット・フォルダ・チーム共有を使うには14日間のトライアル後、月額$5.99が必要です(AIコマンドと音声機能は、別途購入するAIクレジットを使用します)。また、正規表現ベースのトリガーやシェルコマンドmatchも失うことになります。これらはGUIモデルには対応物がありません。もしそれらこそがEspansoを使う理由なのであれば、この移行はあなた向けではありません——それは十分に正当な、留まる理由です。

Espansoのエコシステムを完全に離れることなくGUIが欲しいのであれば、コミュニティ発のプロジェクトも存在します——espansoGUI(Rust/Iced製、Flathubで配布)、EspansoEdit(Windows向けフリーウェア)、EspansoGUI IDEなどです。試してみる価値はありますが、いずれも根底にある同じYAMLファイルの上に載る、ボランティアが個別に保守している別レイヤーにすぎません。Espanso自体には今も公式GUIがありません(コア・プロジェクトの最新安定版はv2.4.0、2026年7月リリース)。GUI自体が製品そのものであるようなツールが欲しいのであれば、この移行が埋めるのはまさにそのギャップです。

よくある質問

EspansoのYAMLファイルを直接インポートできますか?

現時点ではできません——一括インポート機能はありません。各matchはビジュアルエディタ上でスニペットとして作り直すことになります。50件未満のライブラリであれば、たいてい15分もかかりません。それより大きなライブラリでは、1件ずつの作業である以上、規模に比例して時間がかかります。

正規表現ベースのトリガーやシェルコマンドmatchは失われますか?

はい、失われます。それらはEspanso独自のYAML/スクリプトモデルの上に構築された機能であり、ここにはGUI版の対応物がありません。正規表現トリガーやシェルベースのmatchが自分の環境の中心である場合は、それらについてはEspansoを使い続け、GUI版のエキスパンダーはよりシンプルで静的なスニペットにのみ使うことを検討してください。

:br/addrのような同じトリガーのテキストをそのまま使えますか?

はい、使えます。Triggerフィールドには入力したテキストがそのまま使え、慣れ親しんだ記法であれば先頭の:/も含めて構いません。移行の際に略語のスタイルを変える必要は一切ありません。

ツールを完全に乗り換える前に試すべき、公式のEspanso GUIはありますか?

公式のものはありません。espansoGUI、EspansoEdit、EspansoGUI IDEといったコミュニティ発のプロジェクトがグラフィカルなレイヤーを追加してくれますが、これらは同じYAMLファイルの上に載る、別個のボランティア保守ツールにすぎません——生の設定ファイルまではあと一歩という距離感です。GUIが後付けの追加機能ではなく製品そのものであってほしいなら、それこそがこの移行がもたらす違いです。

関連記事

出典