VimConf2025でLT発表してきました
こんにちは、Sirasagi62です。今回はVimConf 2025に"From Fuzzy to Fluent: Semantic Code Search in Vim/Neovim"と題して登壇させていただけたので、僭越ながら登壇までの流れと考えたこと、実際に登壇した感想を綴っていこうと思います（発表内容の技術的な話については後日別記事で話そうと思います）。
参加と登壇に至るまで
参加自体は去年に続いて2回目ですが、登壇したのは今年が初めてとなります。それどころか技術系のイベント自体で登壇したのも今回が初めてでした。というわけでめちゃくちゃに緊張していたのですが、そもそもどうして登壇しようと思ったのか、といったところも含めて登壇までの経緯を書いていこうと思います。
プログラミングとVim/Neovimに触り始めてだいたい10年くらいになりますが、実は今年になるまで記事を書いたり、ソフトウェアを公開したりといった、対外的に発信する活動をほとんど行ってきませんでした。SNSにほとんど触れてこなかった自分にとって誰からも閲覧できるインターネットで何かを発言すること自体がハードルが高く、ソフトウェアの公開についてもメンテナンスできずに燃え尽きてしまうのではないかという懸念があったためです。また、そもそも9年間このスタンスでいたため、あえて変える動機も乏しいというのもありました。そのため、今年の夏までの9年間はインプットするだけの状態が続いていました。
しかし、大学4年生になってこの心境に変化が生じました。ふと見返したときに自分のスキルや知識を証明できる成果物が何もないのです。大学院進学後に就職活動が控えていることや今が時間的余裕のある最後のタイミングであることを考えるとこのままでよいのか、という疑問が湧いてきました。また、vim-jpで交わされる会話や質問を見るたびに自分の知っている範囲で対応できる話題も多いことに気づきました。これらの2つから徐々に 「せっかく貯めた知識や経験をただ寝かせておくのはもったいないことをしているのでは？」 という思いが強くなってきました。
そんなわけで今年になってからVim駅伝に参加したり、vim-jp内での発言も増えてきました。またOSS開発にも着手するようになり、redditで宣伝したり記事を書いたりしていくうちに予想以上の反応を得られることもあって、発信することがプログラミングを行う上での新たなモチベーションとなりました。
そんなスタンスの変化から、実際のイベントで登壇してみたいという思いも徐々に強まり、プログラミング活動の１つのマイルストーンとしてVimConf 2025 SmallのLT枠に応募しました。
プロポーザル
はじめての登壇挑戦ということでLTで応募することに決めたのですが、テーマでずっと迷い続けました。
今回実際に登壇したのは 「SLMを使った埋め込みによるコード検索（Fluent Finder,flf）」 ですが、実は個人的に第一候補ではありませんでした。というのも
- Transformerを動かす関係で実行に非常に時間がかかり、実用できるほどではない
- いくらかの最適化をしても実用まで持っていこくことが難しい
という思いがあったからです。しかし、
- 既にこのテーマでいくつか記事を発信しておりそのときの反応が良かった
- 友人が「このテーマが一番いい」と後押ししてくれた
というのがあり、プロポーザルにしました。
そして実はこれの他にもう１つ投稿して通らなかったプロポーザルがあります。それが 「miseを使ったNeovimとその周辺の依存関係管理」 です。こちらは今まで記事として発信したことがありませんでしたが、
- 開発用のSSHと2度のサブ機の切り替えを通じて、ある程度実用できることを確信していた
- Nix派が多いVimmerにYet Anotherとして
miseを推すのが面白いのでは？と思った
という理由から個人的には結構気に入っていました。
最初はどちらか片方を出すつもりだったのですが「別に両方して運営で判断してもらえばいいだろう」ということに気づいて「ダメだったらしょうがない」という軽い気持ちで両方提出してみました。
今回、プロポーザル提出自体初めてだったため、「ピッチって何！？」という右も左もわからない状態から色々調べて書き上げました。
特に参考にしたのは下の記事です。
最終的にピッチを書くうえでは両テーマとも以下の3つを意識していました。
必要性：ユーザーの何の問題をどのように解決するか
新規性：既存の問題解決手法とどのような点が異なり、どのような優位性を持つか
固有性：なぜ私がこのテーマで発表する必要があるのか
- 必要性：同義語や文章での検索が難しい→ベクトル検索
- 新規性：embeddingを用いる・同義語に強い
- 固有性：ベクトル検索に関する記事をいくつか書いたりした
miseでは
- 必要性：LSP/linterやNeovim本体などNeovimのパッケージマネージャで管理できない依存管理が難しい→miseを用いる
- 新規性：Nixではない。tomlで管理できる。デフォルトのやり方で管理者権限が不要（Nixだとできないわけではないが、専用の設定が必要）
- 固有性：PCの2度の故障とSSHでの設定を通じて、誰よりもこのやり方に熟達している。そもそもmiseでNeovimの依存関係を行っている先行事例が少ない
手法ではなく発表者自体の固有性が求められるのがディベートや論文とは異なっていて、面白いなと思いました。
結果としてFluent Finderを採択していただけました。限りなく対照実験に近い状態（出した人、採択する人、イベント、枠が全部同じ）で片方が採択されて、もう片方が見送られたという意味で両方とも非常に価値あるピッチになったなぁ、という風に思っています。今振り返るとmiseの方は固有性とインパクトが弱いようにも感じられます。興味があればリンク先のピッチも覗いてみてください。
発表構成
Fluent Finderが採択されたのはいいものの、構成にはずっと迷い続けていました。最初は仕組みを中心にどういうプラグインかを紹介するプラグインだったのですが微妙だなと感じていました。
そんな中、件の友人が「カレントバッファだけを検索できる機能があったほうがよくない？」というアドバイスを本番３日前に伝えてきました。最初は「短時間で実装できるか！」という感じだったのですが、ロジックとUIを完全に分離していたお陰で１日で実装することに成功し、２日前にバッファ検索機能が実装されました。
この機能追加のお陰でプロポーザルで懸念していた「時間がかかりすぎて実用に耐えない」という弱点をある程度緩和されたました。また、ここまでの「全体検索→実用に耐えない→バッファ検索を実装」の流れをLTに取り込むことで、ナラティブに機能紹介が行えるようになり、発表としても自然なものになりました。プロポーザルで軸にしていた「必要性」「新規性」の要素も補強され、より期待に沿ったプレゼンにできたかな、とも思っています。
原稿
「どうせアーカイブ残るなら、海外からも見てもらいたいし、スライド読めば日本人でもだいたい何やったか分かるから英語でええやろ」という軽い判断で英語で発表しました。
５分間の発表なのでWPM(Words Per Minutes,１分あたりの単語数)を100~111と設定して原稿を書き上げました。「単語数を合わせながら英語で原稿を書く」というのは字面だけで見れば難しそうに見えますが、英訳の部分はGoogle翻訳で行いました。したがって実際には550単語程度の英文がGoogle翻訳で生成されるように日本語原稿を調整しただけで、そんなに難しい作業ではありませんでした。
ちなみに僕は「Google翻訳で訳したときに自然な英文になるような日本語を書く」のが得意という謎特技があるので、この執筆→翻訳→修正のサイクルをめちゃくちゃ簡単に回すことができました。「主語を省略しない」「概要→詳細の順に論理展開する」あたりを気をつければ割と自然な英語になるので、英語で発表する際にはぜひ試してみてください。
ただ、Google翻訳だけではどうしてもしっくりこない表現というのが何箇所がでてきます。そうした表現についてはGeminiに文脈と意図を伝えたうえで何個か候補を用意させたうえで一番良さそうなものを選びました。また、直訳に頼ると
- 非ネイティブ英語話者が聞き取って理解できない程度に難しい（大学入試より上レベルの単語）
- 読んで音にしたときにリズム感が悪い
- 最後に持ってきたいオチが文頭に来ている
といった表現が出てくる問題も発生します。こうした表現についてもLLMで候補を出しながら自分で修正を加えました。細かい表現修正では単語数が20以上ずれることはほとんどないので、Google翻訳で作った単語数を基準とし、目標としている単語数に一致したあとに推敲を英語で加える、というのが個人的にはやりやすいと思っています。
最終的には541ワードとなり、目標のサイズ（500~555）の範疇に収めることができました。練習段階では4分55秒でちょうど良いかなという感じでした。
練習後はスライドのPDFと練習時の録音をGemini Proに与えて発音と改善点をざっくり解析しました。「ベタに実装すると１時間かかるくだり」を強調したほうがよいと指摘したので、そこだけ修正を加えました。本番で結構ウケたので、取り込んで正解だったと思います。割とおすすめの練習法です。
しかし、本番では原稿が頭に入っていなかったのと、緊張からかなり早口（WPMが121）になってしまいました。また、原稿を見るためにずっと下を向いてしまったのでそこも次回以降では改善していきたいと思います。一方で練習段階では終わるかギリギリのところを狙えたので、WPMはやはり有効な指標だろうとも感じました。
スライドと原稿のどちらを先に作り始めるか、という問題はあると思いますが、個人的にはテキストを固めてからそれをベースにスライドをイメージするほうが肌にあっていると感じます。最初、仮段階でスライドから作り始めたのですが、機能追加などで発表直前に出戻りが生じた結果、未使用スライドが７枚くらいできてしまいました。テキストのほうが修正コストが低いので、迷ったらテキストから原稿から作り始めるのがいいと思います。
スライド
LT採択後にスライド関連でTipsを共有したい・情報収集したいということもvim-jp内の#tech-presentationを作ってみました。便利なツールや色んな人のスライドを見れて非常に良かったと思います。特にslidevの存在を知れたのも非常に良かったです。今回は初めての登壇ということもあり使い慣れたPowerPointで作成しましたが、機会があれば使ってみようと思います。
#tech-presentationを作った張本人でもあるので今回のLTのスライドについても一通りまとめてみたいと思います。
フォント
タイトル・見出しではGlacial Indifference、本文ではInterを使いました。どちらもフリーフォントです。フリーフォントにこだわったわけではないのですが、Windowsの初期搭載フォントよりも見栄えが良いことと、途中でWindows PCがぶっ壊れてサブ機のmacbookで作業を継続せざるを得なかったので、いい選択だったなと思っています。
Glacial IndifferenceはHankenというフィリピンのフォントメーアが開発しているマイナーなフリーフォントですが、字形がFuturaに似たジオメトリックサンセリフとなっており非常に美しいのがポイントです。タイトルなので字形が大きく、多少遊んでも可読性が損なわれない点と個性を出したかったため、こちらを採用しました。
ジオメトリックサンセリフ自体、可読性と個性をいい塩梅で両立していて個人的に好きなのですがフリーで使えるものがほとんどなく貴重な存在といえます（最近だとOutfitなどもありますが）。
macで発表したのでFuturaに切り替えてしまってもよかったのですが、Futuraは
- "j"が直線で"i"と見分けがつきづらい
- "?"が独特な形状
FuturaとGlacial Indifferenceでの「jump!?」の比較。Futuraはjが直線で?が独特
という点もあり字形の観点からもGlacial Indifferenceのほうが好きだったりします。 本文で使ったのはよく知られたフリーフォントであるInterです。Interは小さい文字での可読性が非常に高いため採用しました。字形としてはHelvetica, Arial, Apple San Fraciscoに連なる癖のない典型的なサンセリフですがArialよりもウェイト数が多く今回のプレゼンテーションにマッチしていたためWindowsの段階から採用していました。最初はタイトル・見出しもInterにしようかと思ったのですが、当たり障りがなさすぎてやや無味乾燥に感じられたため本文のみでの採用となりました。
InterにグラデーションをかけるとApple感が出るという謎知見
"Fluent"の部分を中心にInterグラデーションをかけているのですがAppleのプレゼン感があって面白かったです。特に「またFuzzyFinderか！」の直後の"No, It's Fluent"についてはワードアート感の強い5000兆円ジェネレータの出力とコントラストが効いていてとても気に入っています。全体に渡ってGlacial Indifferenceと混ぜて使用しましたが、どちらも個性が強すぎるフォントではないので違和感なく使えたと思います。
また、スクリーンでの可読性を確保するためにスライド全体に渡って見出し・本文ともにウェイトをboldとし、強調は文字色で行いました。Windows・MS Office付属のフォントはウェイトが少ない上に、細身の傾向があり、太字にしても期待通りの見た目にならないこともフリーフォントの採用を後押ししました。
配色
左が今回の配色。右が原色。右だとやや強すぎるように感じた
配色はcocoponさんのIcebergのソースコードを見ながらライトテーマをベースにスライドマスターを手動で変更しました。Icebergは目に優しいことが売りの１つなのですが、液晶と比べてプロジェクタを使うことコントラストが下がるため、今回は色相を維持できる範囲で背景色と前景色のコントラストを上げました。とはいっても原色の白・黒・赤だと強すぎるため、特に黒は#232633,強調用の赤は#fe5a5aにして可読性を維持しつつ、印象を和らげています。
その他
LTだとライブデモの切り替えコストが無視できないため、GIFでデモを紹介しました。GIFの撮影にはvhsを使いました。スライド作成直前の駅伝記事で初採用したのですが、iTermだと色がおかしくなったり（mac付属のターミナルで問題回避）、記法に苦戦するなど一筋縄ではいきませんでした。ただ、一度方法を確立してしまえば、ファイルをコピーして少し書き換えるだけで撮影できるため、慣れると撮影効率が劇的に向上しました。フォントサイズやウィンドウサイズを手動で調整しなくて済むのは非常に楽です。スライド作成時には記事で作ったファイルの設定が流用できたため、細かい時間調整以外ではリテイクせずにGIFを作成できました。
Vimのアイコンを含んでいて、可愛らしいデザインのアイコンセットを使いたいと思い、teenyiconsを採用しました。可能な限りアイコンで情報を表現することで特にプロフィールでのテキストを削減できました。
また、発表中はflf-vimのレポジトリのQRを表示していました。昨年度参加した際に、スライド1枚だけに貼られたQRだと、読み取れる前にスライドが切り替わってしまったことが何回かあったため、常に右上に表示するようにしました。一方で自分自身のプロフィールのQRについては表示時間が短い、スライドの本題とは関係がない、という観点からインパクト重視で中心にOctocatのドット絵を配置した自作のQRを貼りました。
仕組みの説明用にinkscapeで模式図を書いたのですが、これは今回の発表内容にほとんど寄与しませんでした。仕組みに関連するスライドをバッサリお蔵入りさせてしまったためです。あまりにも勿体なくて概要説明に入れてみたのですが、スライド１枚の情報量が多くなりすぎたので悪手だったかなぁという気もします。
背景は基本白ですが、プロフィールと最初のフックの部分のみ画像を設定しています（ちなみにFinderの抽象画みたいな背景はMacのFinderのアイコンだったりします）。テキストの可読性を損なわないようにするために画像全体にぼかしをかけたうえで半透明の白い四角形でオーバーラップして画像の主張を薄くしています。テキストが黒に近いと入っても濃紺なので背景が常に明るくなるようにしました。
感想とAI時代のVim/Neovim
去年はvim-jpでほとんど活動していなかったので、知り合いがほとんどいなかったのですが、今回はvim-jpを通じて交流している人間と話すことができたので、去年とは違う観点から楽しかったです。vim-jpではもっぱら#hobby-aiか自分のtimesにいることが多いので、「機械学習系のエンジニア」だと思われていた点も面白かったです。また、自分の成果物について様々な人から対面で評価していただけたのも非常に良かったです。インターネットでは体験できない、現実に根ざした貴重な体験ができました。
発表自体はもう少し改善できる点もあるとは思いつつ、手応えもよく準備して作った甲斐がありました。普段100人を超える人前で話す機会なんてまずないので、そういう意味でも貴重な経験になったと思います。
また、今回のVimConf参加を通じて「プログラミングを書く」というタスクが大きく変化しているということも改めて痛感しました。
個人的には、今回のVimConfでは次の4つをテーマとして採択していったように感じられました。
- Vim/Neovimそのものが持つコアな機能や内部実装
- Vim/Neovimに入門するための道筋
- LTらしいVim/Neovimの可能性を突き詰めたアイディア系プラグイン
- AIの導入でコードを書くことが少なくなっていく中で、Vim/Neovimを使い続ける理由
最初の3つは去年参加したときも見られたテーマだったのですが、特に4つめは今年特有で今後も突きつけられ続ける問いになるような気がします。
自分のテーマについて言えば「ローカルで動くSLMをプラグインとしてVim/Neovimに統合してしまう」というぶっ飛び具合ではLTらしさを、「Vim/Neovim定番のファジーファインダにAIを導入してリーディングの生産性を改善する」という意味では「AIの時代にVimを使う理由」と合致してアピールできたのかなと思います。
AIコーディングが発展し続ける現代で、それでも我々Vimmerが古典的なエディタと言われるVim/Neovimを使い続ける理由は何でしょうか？個人的にはエディタ自体の拡張性の高さとそれに起因する改善イテレーションの速さにあると思います。
一番最初のedのリリースが1973年で半世紀前、Vimの最初のバージョンが1987年で既に四半世紀以上経ちます。この50年間でプログラミングを取り巻く環境は大きく変化しました。記録手段は磁気テープからSSDへと変化し、エディタのあり方もラインエディタからスクリーンエディタへと変化しました。PDP-11もAmigaもコンピュータ博物館に収蔵され、IDE、VSCode、LSP、Claude Codeが生まれました。こんなにも編集を取り巻く環境は変わり続けているのにVimは未だに使われ続けています。それはひとえにVimとそのエコシステムが改善され、拡張され続けたからだと思います。そしてそれが可能だったのは、変化と拡張を行う土壌としてプラグイン・パッチ双方の十分な拡張性とそれを実行するだけのコミュニティが存在したからにほかなりません。もちろんAIの登場はVimのあり方に大きな変化をもたらすとは思いますが、それでもなおVimがなくなることはないと思っています。
今回の記事を書いているとき、自分のtimes(#times-sirasagi62)で次のような投稿をしました。
この投稿のあと深夜1時すぎにもかからわず「プロンプトを書くためのVimプラグイン」について少し盛り上がりました。この会話を通して、もしAIがさらなる進化をして一行もコードを編集せずにソフトウェアを作成・保守できるようになったとしても、人間が何らかの形でコンピュータを操作する限り、そのフロントエンドとしてVimは使われ続けるだろうなと思いました。
Vim/NeovimがAIの影響でどのような方向に進化するかはまだ未知数ですが、このエディタはきっとこれからも進化を続けながら時代の最先端を走り続けていくだろうと確信しています。
Discussion