右から左へ書く言語、デザインの『ズレ』を自動で見つける

『左右反転』って、実際のコードではどう指定されてるの？書き手が『右に寄せて』って明示的に書かなくても、言語の向きで自動で反転されるシステムなの？

実は、コード上では「言語別に別の指示を書く」のではなく、最初から「論理的に」書いておく仕組みなんですよね。 たとえば、英語向けサイトなら「margin-left: 20px」（左に20ピクセルの余白）と書く。ブラウザは「これは左方向だな」と認識して、アラビア語で表示する時には自動で「margin-right: 20px」に読み替える。書き手は何度も書き直さなくていい、という発想です。 ところが現実は、古いコードや複雑な指定には「position: absolute; left: 0」みたいに座標で直接指定されていたり、JavaScriptで動的に位置を計算していたり、CSSのgridやflexboxの複雑な組み合わせだったりする。そうなると、ブラウザの自動反転ルールが追いつかず、「書き手は反転対応のつもりだったのに、表示されたら妙な位置になってた」という齟齬が生まれるわけです。 この研究の強みは、「コードが反転対応のつもりになってるか」ではなく、「実際に描画された見た目」を測って、ズレを見つける点。コードの意図と見た目が乖離しているケースを、初めて系統的に検出できるようになったと言えそうです。

アラビア語やヘブライ語で使うウェブサイトがズレてても、日本語ユーザーには関係ない話？

一見そう思えるんですが、実は逆なんですよね。 日本語ユーザーにとって直接的な被害はないけれど、この「ズレを見つける技術」そのものは日本にも波及する可能性が高い。 なぜかというと、同じウェブサイトが複数言語に対応するケースが増えてるからです。グローバル企業のサービスなら、日本語版と同時にアラビア語版も提供していることがほとんど。研究では Bootstrap や Material Components という世界中で使われるデザインシステムのバグを検出してる。つまり、こうした汎用的なコンポーネントの欠陥は、日本語対応のサイトにも波及してる可能性があります。 さらに重要なのは、この研究が示してる問題の本質。コードだけ眺めてては見えないバグを、実際の描画結果から検出する方法論です。これは右から左への言語に限った話じゃなく、レイアウト崩れ全般を早期に見つけるアプローチとして応用できるかもしれません。 地理的には遠い言語の問題に見えても、ウェブの多言語化が進む時代、テック業界全体の品質向上に繋がる研究と言えそうです。

なぜ今まで『左右反転漏れ』のバグに気付きにくかったの？需要が小さかったのか、それとも見つけ方が難しかったからなのか？

見つけ方が難しかった、というのが大きいように思います。 コードの段階では「左寄せ」と書いてあれば、静的解析ツールには「ルール通り反転指定がある」と見えるんです。でも実際のブラウザ表示では、JavaScriptの動的な処理や、デザインシステム内の複雑な継承関係のせいで、反転がスルーされてしまう。コードと見た目のズレが起きてるわけです。 つまり従来のチェックツールは「書かれたコードが正しいか」を調べてただけで、「最終的な画面が正しいか」は見てなかった。左右反転漏れは、コード検査の網目をすり抜けるバグだったんですね。 需要の問題もあるでしょうけど、実は要因として浮かび上がってくるのは、テストのしにくさです。アラビア語やヘブライ語に対応したサイト自体がまだ限定的で、開発チーム内にそもそも右から左の言語ユーザーがいないことも多い。するとバグが表面化しにくく、気付かれないまま本番環境に残る。「見えない」「見つけにくい」「優先度が後回し」が重なってた、というのが実態に近そうです。

これって『コード上では正しく見えるのに、実際の画面に表示されたら間違ってる』という、テスト方法の盲点を突いた話なの？

その通りです。そしてそれが、どれだけ厄介な問題かが浮き彫りになってます。 コードは「左寄せを右寄せに反転させろ」と正しく書いてある。でもブラウザが実行するときに、その指令がちゃんと成立していない。あるいは、デザインシステムが提供するコンポーネント自体に、反転ルールが抜けてる。静的解析ツールは「コードに何が書いてあるか」しか見ないから、こうした「描画時の実現状況」を検査できないんですよ。 ここで重要なのは、バグが起きるタイミング。開発者が「コード的には正しく書いた」と思っても、CSS の複雑な継承や上書きが絡んだとき、あるいはライブラリのバージョン間で動作が変わったとき、実装側の意図と画面表示がズレる。従来のツールではそれを捕捉できない。 だから研究は逆向きにアプローチした。「実装が正しいか」ではなく「見た目が正しいか」を数値的に判定する。参照状態との比較で、ズレを客観化する。地味に見えるけど、ここが多言語対応の急所だったんでしょう。左右反転は一度ズレると、ユーザーの使いやすさに直結するから。

デザインシステムのメーカー（BootstrapやMaterial Components）は、このズレに気付かずに配布してたわけ？それとも多言語対応は利用者の責任だと考えてたの？

デザインシステムの側も、当然ズレの存在には気づいていたはずなんです。ただ、修正と「公式対応」の線引きが曖昧だったのが実情だろうと思います。 例えば Bootstrap は右から左への対応（RTL対応）を一応サポートしていますが、その実装は基本的な仕組みだけ。細部のレイアウトやコンポーネントの組み合わせ方による予期しないズレまでを全てテストするのは、手作業では限界がある。既存ツールが「何千件も警告を垂れ流す」という記事の記述からも分かるように、チェックして回ると、本当の問題とノイズに埋もれてしまう。結果として「修正より後回し」になりやすい。 言い換えれば、多言語対応は確かに「メーカーの責任」でもあり「利用者の検証責任」でもあって、その境界が曖昧なまま放置されてきたということかもしれません。ビジネス的には、日本語や英語だけで困らない市場が大きい限り、マイナーな言語のズレ修正は優先度が低いままになる構造もあるのだと思います。この研究の価値は、その優先度を変える判断材料を与えたところにあるのかもしれません。