ハクソク

世界を動かす技術を、日本語で。

フォント比較：Atkinson Hyperlegible Mono vs. JetBrains Mono と Fira Code

2025年7月22日原文(anthes.is)

概要

  • Atkinson Hyperlegible Mono の実用評価と JetBrains Mono ・ Fira Code との比較レビュー
  • 文字判別性 ・ 可読性 に焦点を当てた詳細な分析
  • 導入手順 や 注意点 も解説
  • 視覚的特徴 や設計思想の解説
  • 開発者・プログラマ 向けフォント選定の参考情報

Atkinson Hyperlegible Mono 実用レビューと比較

  • Atkinson Hyperlegible Mono をターミナルやWebサイトで1か月間実用評価
  • JetBrains Mono や Fira Code など、定番プログラミングフォントとの比較
  • Google Fonts や GitHub などで配布されているダウンロードリンク案内

文字判別性と可読性

  • プログラミングフォントは 文字の見分けやすさ が最重要

  • 0（ゼロ）とO（オー）、1とlとIなどの ホモグリフ（類似字形） 問題

  • ミラーイメージ字形 （例：dとbなど反転で生じる混同）の課題

  • Monospace（等幅） フォントはマルチキャラクターホモグリフ（例：cl→d）を軽減

    • マルチキャラクターホモグリフ ：複数文字が1文字に見える問題
    • シングルキャラクターホモグリフ ：1文字が別の1文字に見える問題
    • ミラーイメージ字形 ：反転で混同しやすい字形

  • 文字判別性 が重要なシーン

    • SQLクエリでIDを誤認
    • ハッシュ値やGPGフィンガープリントの転記
    • gitのコミットハッシュ比較
    • コマンドライン引数（-1と-lなど）の誤認防止

Atkinson Hyperlegible ファミリーの特徴

  • Braille Institute と Applied Design Works が開発
  • 視覚障害者向け に判別性と調和を両立した設計
  • Atkinson Hyperlegible Next ：7ウェイト・150言語以上対応
  • Mono版 は開発者からの要望で誕生

独自のデザイン要素

  • 視覚的シルエット の差異強調（例：Bの上下のボウルの大きさ、8の上下形状）
  • 字形の強化 （例：jの尾、Iの上下バー、i/lのセリフ、!の点間隔）
  • 非対称スパー と 誇張されたディセンダー でミラー字形を識別
    • bとd：スパーの太さと出方で差別化
    • pとq：qの長い尾で区別

JetBrains Mono・Fira Codeとの比較

シングルホモグリフ比較

  • JetBrains Mono ：7にセリフ追加、jIil1!グループで差別化
  • Fira Code ：jのフック、lのセリフで識別
  • Atkinson Hyperlegible Mono ：8/B/5/Sの判別が特に優秀、j/lの非対称セリフ、5の斜めストローク

ミラー字形比較

  • JetBrains Mono ：d/b/q/pがほぼ鏡像、aとeも類似
  • Fira Code ：微妙な差別化、gやpの方向性・装飾性
  • Atkinson Hyperlegible Mono ：非対称設計でd/b/q/pを明確に区別、a/eも明瞭

プログラミング記号比較

  • JetBrains Mono ：., :; ()[]{} などの識別性高
  • Fira Code ：記号のバランス良好
  • Atkinson Hyperlegible Mono ：[]{}はやや弱いが、-/+/_の長さや*のサイズ差で区別、<>も独立表示

インストール・設定方法

  • Unix系OS （Linux, BSDなど）向け手順
    • gitインストール 後、公式リポジトリをクローン
      • $ git clone https://github.com/googlefonts/atkinson-hyperlegible-next-mono
    • フォントディレクトリ作成
      • $ mkdir -p ~/.local/share/fonts
    • フォントファイルをコピー
      • $ cp ./atkinson-hyperlegible-next-mono/fonts/ttf/*.ttf ~/.local/share/fonts/
    • フォントキャッシュ再構築
      • $ fc-cache -fv
    • システム全体や各アプリで monospaceフォント として設定
      • 詳細は Arch Wiki などを参照

注意点・留意事項

  • 一部バージョンで バッククォート（`） 未収録
  • Applied Design Works はブランドデザイン専門で書体設計は本業外
  • 設計思想は主に 視覚障害者向け （ディスレクシア特化ではない）
  • 商業的背景やブランド意図が判別性主張に影響の可能性
  • プログラミングリガチャ （合字）未対応
  • 客観的な 読解性能の科学的検証 は未実施（ユーザー調査や内部テストのみ）

関連リソース

  • Pimp My Type ：Atkinson Hyperlegible系のレビュー・組み合わせ例
  • Coding Font ：フォント比較サイト、Atkinson Hyperlegible Monoの専用ページあり
  • ブックマーク集 ：タイポグラフィ・可読性・フォント関連情報

Atkinson Hyperlegible Mono は、判別性重視の開発者向け等幅フォントとして有力な選択肢。 JetBrains Mono や Fira Code と比較して、特に ホモグリフ対策 に優れるが、用途や記号の識別性などで一長一短。 科学的裏付け や リガチャ対応 の有無も考慮しつつ、用途に適したフォント選びを推奨。

Hackerたちの意見

ウェブサイトをAtkinson Hyperlegibleフォントにデザインし直した後、ターミナルとコードエディタをモノスペース版に切り替えて、ちゃんとテストしてみたんだ。1ヶ月のテストと良い体験を経て、さらに調べてみたくなって、Atkinson Hyperlegible MonoとJetBrains Mono、Fira Codeを比較する記事を書こうと思った。視覚的な比較には、ホモグリフやミラーグリフに関するアクセシビリティの論文からの例を使ってるよ。JetBrains MonoとFira Codeは多くの開発者が使っているし、馴染みがあるから基準に選んだんだ。Atkinson Hyperlegible Monoは文字の識別に優れてるけど、完璧なものはないよね。「注意点」セクションでトレードオフについて詳しく説明してるから、インストール手順の下にあるよ。他の人の体験や考えも聞いてみたいな。フォントの選択が可読性やアクセシビリティにどんな役割を果たすのかに興味があるけど、この分野の研究はまだまだ少ないんだよね。

└

最初の段落でダウンロードリンクを貼りたいな。私の印象では、可読性はあるけどちょっと太すぎるかな。Fira CodeとJetBrains Monoが似たように幅広で、Atkinson Hyperlegible Monoよりも狭いのに気づくと思うよ。

└

英語のテキストのブロックやプログラムコードのブロックを比較するのを見たかったな。文字単位じゃなくて、任意のブロックで読む感覚を理解するのに役立つし、特定のデザイン特性を評価するのにも良いと思う。

なんでコーディングにプロポーショナル（モノスペースじゃない）フォントをもっと使わないんだろう？個人的には、可読性の面で大きな進歩だと思う。サイドバー（通常はプロポーショナルフォント）での読みやすさに気づいてから、私も切り替えたんだ。もちろんターミナルでは使えないけど、時々モノスペースの整列に頼っているコメントもあるよね。それ以外はプロポーショナルフォントにデメリットは感じないな。Inputを使ってるけど、特殊文字にもっとスペースがあって全体的にかなり良いよ。: https://input.djr.com/

└

このプロポーショナルフォントはどのIDEやエディタで見てるの？Emacsでのプロポーショナルフォントは私の目には合わないな。ブラウザや書籍の出版社がテキストをレンダリングする時の文字間の微妙な違いをEmacsが知らないんじゃないかな。

└

プロポーショナルフォントについてのこのアイデアは前に聞いたことがあって、興味を持ってたんだ。でも、私はNeovimをAlacritty内で使ってるから、私に合うかどうかは分からないな。そのフォントをチェックしてみるよ、提案ありがとう！ :)

└

Plan 9のAcmeエディタをチェックしてみて！: https://en.wikipedia.org/wiki/Acme_(text_editor)#/media/File...

└

プロポーショナルフォントはコードでも読みやすいっていうのに完全に同意だよ。使おうとしたとき、Goの自動フォーマットがスペースで整列させるから、プロポーショナルフォントだとすごく見栄えが悪くてイライラした。解決策はエラスティックタブストップ[1]なんだけど、実際にはどのエディタでもサポートされてないみたいだね。[1] https://nick-gravgaard.com/elastic-tabstops/

└

Commit Monoフォントにある「スマートカーニング」のモノスペースフォントもいいかもしれないよ。https://commitmono.com

└

何人かはIDEで比例フォントを使ってるし、何十年もそうしてきたんだ。ただ、あまり一般的な慣習ではないね。（90年代にMicrosoftがIDEで比例フォントを使ってたような気がする。もしくはVisual Basicのことを考えてるのかな？よくわからないけど。）コーディングのときに比例フォントを使いたいと思わなかった主な理由は、比例フォントは同形異義語を区別するのが非常に苦手だから。それは構文エラーや未定義の変数を探すときに一番避けたいことなんだ。ただ、実際にプログラミング用に作られた比例フォントを探していないのも認めるよ。もう一つの理由は、時々、誰かがコメントにASCIIダイアグラムを作ったり、縦の整列が重要な他の構造や空白があるコードを読むことがあるから。これってCでは非常に人気があったけど、「現代」では悪い慣習と見なされてるね。モノスペースのコードはすごく読みやすいから、結局のところ、比例フォントにはいくつかの欠点があって、実際の利点はないと思う。少なくとも私にとってはね。

└

もちろん、ターミナルには使えないよ それが問題なんだよね。俺はweztermの中でneovimを使ってる。コードに比例フォントが使われてるのを見たことが何回かあるけど、面白いと思ったけど、現実的にはvt100の世界に生きてるから、全体的にはそんなに悪くないよ。プログラミングフォントとしてAtkinson Hyperlegible Monoに興味がある。モノスペースはプログラミングフォントの特徴だと思う。基本的に、可読性はプログラミングとテキストで違うんだよね（ただ、俺は明らかにVerdanaを読みすぎてるけど）。

└

本当の比例フォントを使うと、基本的なインデント以外のコード要素を揃えるのを諦めることになる。ほとんどの人にとって、それは大きすぎる妥協だね。Iosevka Aileみたいな準比例フォントは好きだな。すごく幅の広い文字や狭い文字が自然な幅に近い感じで使えるから。たぶん、"Wl"（広い + 狭い）が"xx"（通常の2倍）と同じ長さになるように幅が調整されてると思う。EmacsでIosevka Aileを使った経験では、だいたいは揃うけど、必ずしもそうじゃないこともある。完全な比例フォントよりは、ずっと良い妥協だと思う。

Hacker Newsで議論の続きを見る