標準をDiYする
2026-02-14
WordGrain
ラッパーの語彙を収集するツールであるBarScanを作る過程で、
その記録のためにWordGrainという標準的なJSONフォーマットを作った
これはもともと作る予定はなく、BarScanを作る過程で他の複数のアプリケーションへの可搬性を考えた結果、途中で作ることを決めたものだ
WordGrainを作ろうと決めた時に、同僚との会話、GMLについて頭にうかんでいた
標準に則ることの良さ - 同僚との会話
担当しているプロダクトにSSOの機能がついておりその対象プロバイダーの範囲について回答したときのことだ
私: ◯◯は非対応ですね-
同僚: いえ、Open ID connectのプロトコルをサポートしているので、◯◯も動くはず
その後同僚がさっと◯◯の動作を確認して、回答は完了した
プロトコルをサポートすることの偉大さを実感した瞬間だった
同僚は仕組みを作り、その上で拡張性を持たせる設計のセンスがよく、数年たって実装したものが非常にうまくワークする、という結果を出せる
私はどちらかというとワンオフのものを作りがちなので、この同僚の仕事の仕方には尊敬の念をもっている
GML(Graffiti Markup Language)
学生の時に同じくGraffiti Research Labをフォローしている知人から、
「GRLの次の作品はなんか言語?らしいよ」と教えてもらった
プログラミング言語かな?と思っていたがその後リリースされたのはGML(Graffiti Markup Language)だった
彼らはLaser TagなどでデジタルとGraffitiをつなげ、OSSとして作品をリリースする活動を行っていたが、
GMLはGraffitiを共通フォーマットとして保存し、Open Data化するためのものだ
同時期にリリースされた EyeWriter はALSを患ったグラフィティアーティストがアイトラッキングでタグを書き、
それを遠隔地でプロジェクションすることで身体が動かなくなったアーティストに再度グラフィティを描いてもらう作品だった
GMLはそのデータ基盤となっているようだ
データフォーマットを作る、という発想はこのときからずっと頭のどこかにあった
自分で標準を作る
標準、というとなにか遠くの方、大企業や組織で決められたものであり、自分はそれに従う存在のように思えるが、
GMLの例のように自分が欲しい標準をつくってもいいわけだ
広く広まっていない標準に意義はあるのか?という思いもなくはないが、
私は少なくとも複数のプロジェクトでWordGrainを使うつもりだ
欲しかったら標準だって作っていい
個人のエコシステム
小さいながらもWordGrainには既にエコシステムがある
- WordGrain仕様(JSON Schema) - データフォーマットの定義
- shimpeiws.github.io/word-grain(ドキュメントサイト) - 仕様リファレンス・可視化・比較ツール
- BarScan(リファレンス実装・CLI) - 仕様に準拠した分析ツール
BarScanはWordGrainを利用する最初の実装の位置づけで、
ドキュメントサイトの下部の Ecosystem からもリンクをはっている
誰か興味を持った人がWordGrainを利用したアプリケーションを作ってくれても嬉しいが、
まず自分が第一のユーザーとしてこの標準を使ってみようと思う
→ BarScan on PyPI
→ WordGrain Docs
→ GitHub: BarScan
→ GitHub: WordGrain
→ BarScanの技術的な話