A Manifesto for Meaning Infrastructure
Observing the Semantic Big Bang.
ソフトウェアは言葉でできている。ボタンのラベル、仕様書の用語、コードの命名、APIのフィールド名、AIへのプロンプト——プロダクトとは、無数の命名の集積である。私たちはその言葉の層を研究し、道具を作る。
Observing the Semantic Big Bang
生成AIが、プロダクトのあらゆる層を横断して概念を交配させている。Figmaのラベルが仕様書に流れ、仕様書がコードの命名に影響し、コードがヘルプ記事を書き換え、ヘルプ記事が翻訳に流れ、翻訳がUIに戻る。
いま起きているのは、意味のビッグバンだ。一度広がった概念は元に戻らない。この窓が開いている間に何をするかで、これから10年のプロダクトの概念分布が決まる。
私たちはこのビッグバンを観測し、構造を与える側に立つ。
What we study
プロダクトの「意味」を対象とする。UIラベル、仕様書の用語、コードの命名、APIのフィールド名、ヘルプ記事の語彙、翻訳の整合性——これらを横断して概念の一貫性を保つ層を、意味層（semantic layer）と呼ぶ。
デザインシステムが視覚のインフラであるように、意味層はプロダクトの概念のインフラだ。
私たちの研究対象は4つの領域にまたがる。
Ontology。 このプロダクトの世界に何が存在するか。何をEntityとして独立させ、何をPropertyとして扱うか。存在の定義。
Grammar。 Entityを言語にどう射影するか。同じ「申請」が行為・状態・対象・画面名のどの軸にいるかを分化するルール。
Meaning Token。 言語に先立つ概念の原子単位。日本語では「コレクション」、英語ではCollection、韓国語では「컬렉션」——表層形は異なるが、指している概念IDは同一。
設計の分岐。 一つの概念には、ありうる設計が複数ある。「削除」には5通り、「承認」には6通り。その分岐を並べ、どれを選んだかを追跡可能なかたちで記録する。
Why Japanese
英語はAPIの言語と日常会話の言語が同一だ。users.create(user)とThe admin created a userは語順が一致する。可算・不可算の区別が文法レベルで強制され、日常会話のなかで無意識にEntityとPropertyの区別がなされている。
日本語はこの前提を共有しない。主語と目的語の省略が許容され、サ変構文が曖昧性を増幅し、同じ漢字二字が行為にも状態にも対象にもなる。「お気に入りする」と書けば文として成立するが、その裏で5通りの異なるデータ設計が同時に成立する。
dbtのsemantic layerのようなツールも、schema.orgのような語彙標準も、StripeのAPIのような美しい命名も、英語の文法がモデリングを半分肩代わりしてくれる前提の上に成り立っている。日本語プロダクトには、この前提が成立しない分だけ、固有の工具がもう一段必要になる。
Thesis
Ontology precedes Interface.
存在が定まらなければ文は安定しない。文が安定しなければ、UIは成立しない。
ほとんどのチームは、UIから始めて、命名を後付けし、存在の定義をついに決めないまま走り続けている。順番は逆であるべきだ。何がある世界なのか。それをどう呼ぶのか。それをどう見せるのか。
この順序を意識的に守らなければ、見えるもの（UI）から始めるのが人間の自然な傾向であるかぎり、見えないもの（意味の構造）は永遠に決まらない。
What we value
私たちは、プロダクトに現れる日本語を観察し、名づけ、分解し、構造化する実践を通じて、よりよいデジタル体験のつくり方を見つけだそうとしている。この活動を通して、以下の価値に至った。
きれいな文言よりも、意味の分解を。
自然な日本語よりも、操作を誤らせない日本語を。
漢字二文字の便利さよりも、対象と行為の明確さを。
画面ごとのコピー改善よりも、語彙体系の設計を。
ユーザーの言葉をそのまま使うことよりも、プロダクトの言葉としての再定義を。
説明文を足すことよりも、名前そのものを正しくすることを。
翻訳されたUIよりも、言語の文脈に根ざした多言語体験を。
すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
Twelve principles
1. 言葉は、装飾ではなく構造である。 UIテキストは、最後に貼るラベルではない。ユーザーが対象を理解し、行為を選び、状態を判断するための構造である。
2. 日本語UIは、名詞化しすぎる。 登録。編集。削除。管理。設定。連携。確認。行為がすぐに名詞になり、短さの代わりに主語・目的語・時制・責任を失う。まず、その名詞が何を隠しているのかを問う。
3. 漢字二文字は、強いが、危うい。 漢字二字の言葉は、意味の圧縮形式である。密度が高い言葉ほど、解釈の幅も広がる。圧縮されたまま使わず、必要に応じて展開する。
4. UIコピーは、画面ではなくオブジェクトに属する。 文言を画面ごとに考えない。まず対象を定義し、その対象にふさわしい言葉を与える。
5. ボタンは、動詞と目的語を持つ。 「実行」「保存」「次へ」だけでは、何が起きるかわからない。よいボタンは、可能な限り「何を、どうするか」を明らかにする。
6. 状態は、ユーザーの判断材料である。 状態表示は、システムの都合ではなく、次の行動を支えるためにある。「失敗」「停止中」「上限超過」は、次に何をすべきかを導く入口である。
7. 同じ意味には、同じ言葉を使う。 「ユーザー」「アカウント」「メンバー」が混在するとき、それは表記ゆれではなく、概念設計の揺れである。不統一は、データ構造・権限設計・サポート体験にまで伝播する。
8. 文言の問題は、しばしばIAの問題である。 コピーを直すだけでは解決しない問題がある。背後には、分類の失敗、オブジェクトの未定義、関係性の曖昧さがある。
9. ユーザーの声は、素材であって仕様ではない。 声を尊重する。しかし、そのままUIに反映しない。声の奥にある対象・行為・目的・制約を読み取り、プロダクトの構造へ翻訳する。
10. 多言語化は、翻訳ではなく再設計である。 日本語の曖昧さを英語に移すことも、英語の構造を日本語に押しつけることも、多言語対応ではない。言語ごとの文法・文化・情報の粒度に合わせて、意味を再構成する。
11. よいプロダクトには、よい辞書がある。 プロダクトの言葉は、偶然に増えてはいけない。名称、定義、関係、状態、禁止語、代替語。チームで共有され、更新され、プロダクトに接続される。
12. 意味のインフラは、体験のインフラである。 言葉が整うと、UIが整う。UIが整うと、操作が整う。操作が整うと、チームの理解が整う。
What we build
意味層を制度化するための道具を作る。
散歩する。 既存プロダクトのUI文言を形態素レベルで構造化し、検索ではなく散歩して、言葉の使われ方を理解する。NINJALの「少納言」「中納言」が日本語コーパスを散歩可能にしたように、プロダクトの言葉も散歩可能にする。
並べる。 曖昧な仕様のなかから、ありうる設計の分岐を並べて、選べるようにする。どれを選んだかはURLに残る。
見張る。 デザインツールや仕様書の中の言葉のブレを自動検出する。コードにlinterがあるように、意味にもlinterを。
返済する。 プロダクト全体の意味的負債を計測し、返済計画を立てられるようにする。
Open by default
意味のインフラストラクチャは、一社が閉じて作れるものではない。日本語という言語全体を横断する公共財であるべきだ。
ソースコードはオープン。コーパスはコミュニティで構築。辞典はupvoteベースで検証。蓄積された観測値が、次の設計者の地図になる。
自分の道具で自分を作る。tokyogrammarの命名を、tokyogrammar自身の辞典で引く。自分の道具で自分を作れないなら、他者にも使ってもらえない。この反証可能性を、開発プロセスに組み込んでいる。
この宣言は、まだ完成された理論ではない。プロダクトの言葉を観察し、名づけ、構造化し、再利用可能にするための実践から、更新され続ける。