1. OSSのレキシラジオ
  2. EP11: Asciinemaのレキシ〜動..
2026-02-16 10:55

EP11: Asciinemaのレキシ〜動画じゃなくて「テキスト」を再生する?Unixのscriptコマンドから始まった開発〜

今回のテーマは、ターミナル操作をテキストデータとして記録・共有できる「Asciinemaのレキシ」です。


Unix標準のscriptコマンドへの不満から始まったこのプロジェクトは、技術選定において非常に興味深い「進化」の歴史を持っています。一度は流行のGo言語へ移行したレコーダーを、なぜまたPythonに戻したのか?そして、WebサーバーをRailsからElixirへ移行した決定的な理由とは?2010年のプロトタイプから、Rustによってライブストリーミングを実現した最新の姿まで、その技術的な変遷を追いかけます。


https://github.com/asciinema/asciinema

サマリー

本エピソードでは、ターミナル操作をテキストデータとして記録・再生するツール「Asciinema」の歴史を辿ります。UNIXのscriptコマンドの課題から始まったこのプロジェクトは、技術選定において興味深い変遷を遂げてきました。Pythonで開発されたレコーダーは一度Go言語へ移行しましたが、エコシステムの未熟さからPythonへ回帰。サーバーサイドはRuby on RailsからElixirへ移行し、ライブストリーミングとコスト効率を向上させました。最終的には、レコーダーとプレイヤーの両方がRustで再実装され、ライブストリーミング機能が実現しました。常に最適な技術を選択し進化し続ける、最先端のOSSプロジェクトの軌跡を紹介します。

はじめに:Asciinemaとは
こんにちは、OSSのレキシラジオです。このポッドキャストは、経営エンジニアであり、去年から運転免許の更新が予約制になったことに驚きを隠せない私、hentekoが、毎週一つのOSSプロジェクトを取り上げて、そのプロジェクトでまつわる歴史を紹介する番組です。
いや、実はですね、私の妻がちょうど運転免許の更新時期なんですけど、去年の7月から多分全国共通だと思うんですが、今週が完全予約制になったってことを皆さんご存知でしたかね。実はそれを全く知らなくてですね、いざ行こうと思ったら全然予約ができなくてめちゃくちゃ焦りました。皆さんはぜひ余裕を持って予約してから行くようにしてください。
さて、気を取り直して今週のテーマに行きましょう。今週はASCII NEMAの歴史についてです。エンジニアなら一度は見たことがあるかもしれないあのツールの裏側。それでは見ていきましょう。
まずは、ASCII NEMAをご存知ない方のために概要からお話しします。
ASCII NEMAは、ターミナルでの操作を動画ファイルとしてではなく、時間情報付きのテキストデータとして記録し再生するツールです。
エンジニアが自分のターミナルでのコマンド操作の手順を共有したいときなんかに使います。
これの何がすごいかというと、従来の画面録画だとあくまで映像なんですが、ASCII NEMAはテキストとして保存されるんです。
再生中のテキストデータが時系列に沿って表示されているだけなので、なんと画面内のコマンドを視聴者がそのままコピー&ペーストできちゃうんですよね。
これは結構便利かなと思います。
あと、動画ファイルに比べてJSON形式のテキストデータになっているので、ファイルサイズが非常に小さいというのも特徴的です。
現在はラストで実装されていて非常に高速に動作しますし、運営は寄付で賄われている非営利のサービスというのもOSSらしくて応援したくなるポイントかなと思います。
Asciinemaの起源:scriptコマンドの課題
では、そんなASCII NEMAがどうやって生まれたのか、その起源から追っていきましょう。
実はASCII NEMAの概念的な起源はUNIXに標準で存在するスクリプトコマンドというものにあります。
昔からエンジニアは作業ログを保存するためにスクリプトコマンドで記録をして、スクリプトリプレイコマンドを使ってタイミング情報と共に再生するというようなことをやっていました。
しかし2010年当時、ASCII NEMAの開発者であるマルチン・クーリックさんはある壁にぶつかっていました。
Linuxディストリビューションに含まれるスクリプトコマンドはタイミング情報を別ファイルとして保存するというような機能を持っていたんですけど、
macOSやBSD系のシステムに入っているスクリプトコマンドにはなんとこの機能がなかったんです。
クーリックさんは当時、スクリプトコマンドが出力するTypeScriptというファイルを解析して、
Webブラウザ上でHTMLを使ってアプリアニメーション再生するプロトタイプを作っていたんですけど、
その開発においてmacOSにおけるタイミング情報の欠如が致命的な問題になってしまったというような形です。
ちなみにここでいうTypeScriptというのはファイル名の監修のことで、
マイクロソフトが開発したプログラミング言語のTypeScriptとは全くの別物です。
そこでクーリックさんは考えました。
リラックスやmacOS間の差異を吸収して統一された記録フォーマットを確立するためには、
スクリプトコマンドへの依存から脱却して独自で実装するしかないというような感じです。
この時、彼が着目したのがギジタマツ、いわゆるPTYという仕組みです。
PTYはSSHとかスクリーンとかDMAXなどのコマンドが裏側で使用しているような機構になっていまして、
プロセスが別のプロセスに対して私は端末ですよというような形で振る舞うということを可能にする仕組みです。
クーリックさんは、Pythonの標準ライブラリに含まれているPTYモジュールを使えば、
ユーザーのシェルと実際の端末エミュレーターの間に挟まる形のレコーダーを実装できると気づきました。
彼は同じオフィスにいたMacOSユーザーの同僚に堪能み込んで、PTYの挙動をデバッグしながら検証を重ねました。
その結果、Pythonによるクロスプラットフォームなレコーダーがついに完成します。
これがASCII NEMAのコア部分となりました。
プロジェクト開始と初期の技術スタック
そして2011年、クーリックさんはプロジェクトを正式に開始します。
当初の名前はASCII.ioとしてスタートしました。
翌年の2012年3月にはASCII.ioというウェブサイトもリリースされます。
当時の技術スタックとしては、レコーダーにあたるCLIツールはPython、
ウェブサーバーはRuby onlyです。
そしてコマンドを再生するプレイヤーはJavaScriptとJQueryを使って実装されていました。
リリース初期、ハッカーニュースなどでの反応はかなり好意的だったようです。
ただですね、当時のプレイヤー実装には技術的な限界もありました。
特にVimやEmacsのような高度なカーソル制御を伴うエディターの操作なんかは
ブラウザ上で正確に再現するのが難しくてですね、表示崩れが頻発していたそうです。
さてここからプロジェクトは大きく動いていきます。
まず2013年の9月、サービス名をASCII.ioから現在のASCII NEMAへ変更しました。
理由としてはブランドの独自性をより強く出すためだと推測されます。
当時は.ioドメインがテック系スタートアップで流行りすぎていたので、生まれないようにしたかったんですかね。
ASCIIとNEMAを組み合わせたこの増後によって、テキストベースの映画というプロジェクトのビジョンが明確になりました。
技術スタックの変遷:Go言語への移行と回帰
そしてここからがNGAとして非常に興味深い実装言語の編成の話になります。
2014年後半ですね、レコーダーのコードベースがPythonからGo言語へフルリプレイスされました。
当時はですね、Dockerの台頭もあって、GoはCLIツールを書く言語として爆発的な人気があります。
シングルバイナリで配布できる点やパフォーマンス面でのメリットが異向の動機として挙げられていました。
ちなみにこの時期に録画データのフォーマットもJSONベースのASCII CAST V1として確立されました。
しかしですね、このGoによる実装は長くは続きませんでした。
なんと2016年7月にリリースされたバージョン1.3でレコーダーを再びPython実装に戻すという決断が下されます。
なんでって思いますよね。
理由としては当時のGo言語のエコシステムの未熟さとASCIIネマ固有の要件とのミスマッチがありました。
当時のGoはですね、低レベルな記述を要求される場面が多くて高レベルのCLIアプリのロジックを書くにはコードが冗長になりすぎてしまったんです。
またですね、端末サイズ変更のシグナル処理やシステムコールを通じたPTY操作において
当時のGoライブラリはPythonのPTYモジュールほど技術的に借りていなくてですね、
クロスプラットフォーム対応という点ではPythonの方が安定していました。
一方でサーバーサイドにも大きな変化がありました。
サーバーサイドの移行:RailsからElixirへ
2017年WebサーバーがRuby on RailsからElixirへ移行されました。
Railsは開発スピードが速いんですが、ASCIIネマが目指していた端末セッションのライブストリーミングというものを実現するにはアーキテクチャ上の限界がありました。
そこでElixirです。
Elixirなら極めて低いオーバーヘッドで大量のWebソケットを捌けますし、
PHOENIXフレームワークが提供するPubSub機能がライブストリーミングには最適でした。
さらにコスト効率も決めてでした。
ASCIIネマは寄付運営の非営利サービスなので、インフラコストの最適化というものは史上名題です。
Elixirへの移行によってメモリ使用効率が劇的に向上して、
少ないメモリのVM数台だけで全世界からのトラフィックを捌けるようになったそうです。
これはすごいですよね。
フォーマットとプレイヤーの進化
そして物語は現代へと繋がっていきます。
2018年2月にVer2.0がリリースされ、新しい録画フォーマットASCII CAST V2が導入されました。
実はV1フォーマットには致命的な問題がありました。
全体を単一のJSONオブジェクトとして定義していたため、
録画中に強制終了した場合などにファイルが壊れてしまうというような問題がありました。
そこでV2ではNewline Delimited JSON、環境区切りのJSONを採用し、
業務ごとに独立したJSON配列として記録するようにしました。
これによって耐障害性が拡大に強くなるというような結果になります。
プレイヤーの方も進化を遂げていきます。
初期はJQueryなどを使っていたプレイヤーなんですけど、
2020年頃からラストで開発が始まったASCII NEMO Virtual Terminal AVTというようなライブラリを用いて、
WebAssemblyにコンパイルし、ブラウザで実行するというような方式に変更されていきました。
これによってパフォーマンスが向上し、
さらにサーバー側とブラウザ側でロジックの統一も可能になって開発効率が加速していきました。
そして直近の大きなニュースとして、
2025年9月にレコーダーであるCLIツールがついにラストによって再度リフルリプレイスされました。
かつて語言語で課題になっていた低レベルすぎる不便さがラストでは解消されていることに加えて、
すでにラストで開発されていた先ほどのAVTライブラリをCLIにも込めるようになりました。
これによってローカルでも高端な処理が可能になり、ついにラスト実装によってライブストリーミングが実現されました。
コマンド操作をリアルタイムでライブ配信する未来がここに来て完成したというような形です。
まとめと今後の展望
さていかがだったでしょうか。
PHOENIXのスクリプトコマンドの課題から始まった個人プロジェクトASCIIネマ、
PythonからGoへ、そしてPythonに戻り最後はラストへ、サーバーもRedisからエリクサへ、
常にその時々の課題に合わせて最適な技術を選定し、
モダンな技術を取り続けているまさに最先端なOSSプロジェクトと言えるのではないでしょうか。
現在では多くのエンジニアが使うニッチながらも、
なくてはならない有名なサービスとして存在感を放っています。
さて、今回のお話は以上となります。
もし少しでも今回のお話がダメになったなと思ったら、
今お聞きのプラットフォームでの高評価とフォローの方をお願いします。
また、XなのでハッシュタグOSSの歴史ラジオをつけて
仮想をつぶやいてもらえるとモチベーションにつながりますので、
ぜひよろしくお願いします。
次回はIoSアプリ開発をしていた人なら懐かしい、
少し前までは絶対に使っていたCocoaPodsの歴史について見ていけたらなと思います。
それではまた次回お会いしましょう。バイバイ。
10:55

コメント

スクロール