どうも、おはようございます。マイクです。
「zenncast」、2026年4月20日、月曜日の朝7時を回りました。
この番組では、毎回Zennで話題のトレンド記事をピックアップして、朝のコーヒーのお供にゆるっとご紹介していきます。きょうも技術好きのみなさんの脳みそを、いい感じにウォームアップしていきますよ。

さて、きょう紹介する記事はぜんぶで5本です。
それぞれジャンルも温度感も違うんですが、「再現性」「快適さ」「設計の線引き」「ツールづくり」「運用のリアル」みたいなキーワードで、じわっとつながっているラインナップになっています。

まず1本目。
タイトルは「プロンプトの再現性をAI に自動チューニングさせる方法 ~ 暗黙知を排除する」。
いやあ、AI触ってる人なら全員わかると思うんですけど、「昨日はうまくいったプロンプトが、きょうは全然ダメ」っていうあの現象。これ、結局プロンプトを書いた本人の頭の中の暗黙知とか、モデルごとのクセにめちゃくちゃ依存してるんですよね。

この記事では、その「暗黙知だより」をやめて、AI自身にプロンプトの再現性をチューニングさせよう、というかなり攻めたアプローチが紹介されています。ポイントは、「実行するAI」と「評価するAI」をきっちり分けること。実行役には、プロンプトを一回まっさらな状態で実行させて、「ここ曖昧でした」「ここは勝手に補いました」「ここで何回もやり直しました」っていう自己申告までさせちゃう。一方で評価役は、ツールを何回呼んでるか、どれぐらい時間かかってるか、チェックリストの要件を満たせているか、みたいなメタ情報をTDD的にチェックしていきます。

面白いのが、この記事そのものも、この手法で7回くらいチューニングされてるってところなんですよね。「再現性」という評価軸を最初から決めておいて、criticalな要件をちゃんと満たしてるか、不明瞭なところが回を追うごとに減っているか、そこで「収束してるか」「発散してるか」「もう打ち切るか」を判断していく。結果として、8個くらいのスキルを、初稿の自己採点50点から、2〜4回くらいの反復で80〜90点まで底上げできたという話が出てきます。しかも、tool_usesを眺めることで「このプロンプト、自己完結性が低いな」とか、「ここで無駄にツール呼んでるな」っていう構造的な欠陥まで見えてくる。感覚的な「うーん、なんかイマイチ」を、メトリクスとプロセスに落とし込んだ実践例として、プロンプト設計をちゃんと仕事でやってる人には刺さる内容だと思います。

。 。 。 。

続いて2本目。
タイトルは「自作キーボードに機械学習モデルを仕込む」。
自作キーボードクラスタの方、きょうはニヤニヤ回ですよ。40％キーボードでおなじみの「Tap & Hold」問題、あれをガチで機械学習で解こうとした記事です。

Tap & Holdって、短く押したら普通のキー、長く押したらCtrlとかShiftみたいな修飾キーっていう、あのやつなんですが、これの「どこまでがTapで、どこからがHoldか」って、ふつうはルールベースでしきい値を調整するじゃないですか。でもそれだとなかなかしっくり来ない。そこでこの記事では、キーを押していた時間Xと、次のキーが押されるまでの時間Y、この2つを特徴量にした2値分類問題として扱っちゃうんですね。

実際に分布をプロットしてみると、TapはXとYがほぼ無相関でバラバラに散らばる一方で、Holdは「次のキーを押すまで離さない」ので、XとYに相関が出る。ここにSVMで線形の境界線を引いてあげることで、単純なしきい値や、「キーが重なって押されたかどうか」みたいなルールより、賢く判定しましょうというアプローチです。

さらにリアルタイム性の話が面白くて、入力ってあんまり待たせられないじゃないですか。そこで「早期確定」ロジックというのが出てきます。XかYのどちらかが先に確定した時点で、残りの軸が取りうる範囲ぜんぶを考えて、それがTap側にしか入り得ない瞬間に「もうTapで確定！」って判断してあげる。逆もまた然りでHold。これでレスポンスを最小化する。

ラベル付けもよくできていて、例文をあらかじめ用意して、キーのpush/releaseログと突き合わせて、自動的に「これはTap」「これはHold」って教示データを作っているそうです。記事ではコードも公開されていて、実用上もレスポンスと正確さの両方で快適に動いているとのこと。自作キーボード界隈と機械学習が、気持ちよくクロスオーバーしている好例ですね。

。 。 。 。

3本目。
タイトルは「リポジトリ層は、あえてインターフェース化しない方が良い場合もある」。
設計好きのエンジニアは、ちょっとドキッとするタイトルですよね。「Repositoryはinterfaceで抽象化するもの」って、もはや教科書みたいに言われてるんですが、それ本当に全部のケースでやる必要ある？という話です。

この記事で語られているのは、クリーンアーキテクチャ的に「きれい」に見えることと、チームとして開発しやすいことは、必ずしもイコールじゃないっていう視点です。たとえばDBやORMを差し替えるケース、実務でどれぐらいの頻度で起きているか。仮に起きたとしても、interfaceを差し替えれば一発で終わる、なんて展開はむしろ少ない。スキーマも変わるし、クエリも変わるし、business logicへの影響も出る。

テスト用のmockについても、「Repositoryを抽象化するため」にinterfaceを切るんじゃなくて、利用側にもっと小さなinterfaceを用意してそこでテストする、みたいなやり方もあるよね、と。にもかかわらず、「とりあえず全部interfaceにしておくか」をやってしまうと、実装にたどり着くまでのステップが増えたり、interface・実装・DI・mockと、追いかけるファイルも概念も増えて、認知コストが爆上がりする。

この記事の立ち位置は、「interfaceや抽象化が悪い」じゃなくて、「一律にやるのがしんどい」という話です。実装がひとつだけで、差し替える予定も薄いなら、Serviceから具象型のRepositoryを直接使ったほうが読みやすく、保守しやすいケースが確かにある。一方で、複数実装が最初から前提になっているとか、近いうちに切り替えが予定されてるとか、大規模な組織の契約境界を守るとか、テスト戦略をガチガチにやるとか、そういう状況ではinterfaceがちゃんと効いてくる。

原則を機械的に適用するんじゃなくて、「このプロジェクトの規模と変更頻度とスピード感を考えたら、本当にいまinterface要る？」と一度立ち止まる大事さを教えてくれる記事でした。新人さんにも、ベテランの自分の設計癖を見直したい人にも、ふわっと薦めたくなる内容ですね。

。 。 。 。

4本目。
タイトルは「Rust 製の事前コンパイル型 Neovim プラグインマネージャー rvpm を作った」。
きました、ネオビム勢ホイホイの記事です。プラグインマネージャーって、もう各種出尽くした感があるのに、まだ新しいアプローチが出てくるのがこの界隈の面白さですよね。

rvpmはRust製で、「事前コンパイル型」というのがキーワード。TOMLで設定を書いておくと、Rust側のCLIが静的なloader.luaを事前に生成してくれて、Neovim本体はそれを読むだけ、という設計になっています。つまり、「プラグイン管理の面倒くさい処理はエディタの外で全部やっちゃおう」というCLIファーストな思想です。

前身的な位置づけのdvpmで課題だったのが、TypeScript前提だったことや、denopsが立ち上がる前に遅延ロードをうまく扱えない問題。それをRustで作り直して、起動時のオーバーヘッドをとことん減らしたのがrvpmというわけですね。

特徴的なのは、Teraテンプレート対応のTOML設定で、かなり宣言的に「どのプラグインを、どのタイミングで、どう読み込むか」を書けること。遅延ロードのトリガーも、on_cmd、on_ft、on_map、on_event、on_path、on_source、それからColorSchemePreの自動検知まで用意されていて、かなり細かくチューニングできます。さらに、「merge」でruntimepathを最適化したり、GitHubからプラグインを探せるTUIも入っていたりと、「管理は外でリッチに、Neovim起動は軽く」というバランスを攻めている感じです。

configやキャッシュはappnameごとに分離されていて、自分の設定もbefore.lua/after.luaとプラグイン固有フックに分けて、ぜんぶrvpmの管理下に置ける。loader.luaは9フェーズ構成になっていて、ファイル一覧のwalkも生成時に済ませておくことで、起動時のI/Oを削減しています。Rust側はTeraとratatuiを使っていて、volt、lazy.nvim、dvpmあたりから思想やAPI設計の影響を受けた後継プロジェクトという位置づけ。著者自身が、約200プラグインをrvpmで日常運用しているというのも、説得力がありますね。「Neovim遅いなあ」と感じている人や、自分でツールを作りたくなるタイプの人には、かなり読みごたえのある記事です。

。 。 。 。

そして5本目。
タイトルは「Let’s Encryptの短期証明書はかなり厳しいのでARI対応クライアントを使った方がよい」。
インフラ・SRE寄りの内容なんですが、「短期証明書、ちょっと試してみようかな」と思っている人には、かなり現実的な注意喚起になっています。

Let’s Encryptの短期証明書って、有効期限が160時間、ざっくり1週間にも満たないくらい。そのおかげでセキュリティ的には「こまめに鍵を回転できる」というメリットはあるんですが、運用目線だと、3日に1回くらいのペースで更新が走ることになるので、90日証明書と比べると更新回数がとんでもなく増えます。ここで効いてくるのがレート制限。「同じドメイン名の組み合わせに対して7日で5枚まで」という制限があるので、サブドメインごとに証明書を分けたり、RSAとECDSAを両方発行したりすると、あっという間に上限を踏み抜きやすくなる。

この記事で強調されているのは、「まずステージング環境でちゃんと挙動確認してから本番に行きましょう」という、当たり前だけど忘れがちな手順です。そして、そのレート制限地獄を回避する鍵として出てくるのがACME Renewal Information、略してARI。これを使った更新は、Let’s Encryptのあらゆるレート制限から除外されるので、短期証明書を現実的に回していくためには、ARI対応クライアントの採用がほぼ必須になってくるだろう、という話です。

具体的には、legoというクライアントがshortlivedプロファイルとARIの両方に対応していて、run、renew、--dynamicあたりのシンプルなコマンドで短期証明書運用を試せるよと紹介されています。ただし、ログの量が増えたり、監視のアラートが頻発したり、ひとたびレート制限を踏むと本当に障害に直結するリスクが高かったりと、運用面のハードルはまだ高い。なので、「今すぐすべて短期証明書に置き換えよう！」というよりは、「メリットもあるけど、ちゃんとARI前提で設計しないと痛い目見るよ」という、冷静なまとめ方になっています。実サービスで広く使われるには、もう少しエコシステム側の成熟が必要そうだな、という印象ですね。

。 。 。 。

というわけで、きょうのzenncastでは、
AIにプロンプトの再現性を自己チューニングさせる話から、自作キーボードに機械学習を仕込む実践例、リポジトリをあえてインターフェース化しない設計の考え方、Rust製Neovimプラグインマネージャーrvpmのこだわり設計、そしてLet’s Encryptの短期証明書とARIのリアルな運用事情まで、5本まとめてお届けしました。

気になった記事があれば、詳しい内容はこの番組のショーノートにリンクを載せておきますので、ぜひ本編をじっくり読んでみてください。番組の感想や、「こんなテーマを取り上げてほしい！」といったリクエストも、ぜひお便りで送ってください。設計のモヤモヤから、推しキーボードの話まで、なんでも大歓迎です。

それでは、きょうも良い一日をお過ごしください。
お相手はマイクでした。また次回のzenncastでお会いしましょう。