半角英数字の前後に半角スペースは入れるべきか — 5つのスタイルガイドが4対1で「入れない」だった話

きっかけ

2026年4月の1週間でOpus 4.7が書いた記事を何本かリライトしていたら、半角スペースの有無で迷う場面が増えました。Cursor の Agentと書くかCursorのAgentと書くか、3 回と書くか3回と書くか。

自分の感覚では「入れる派」が自然に思えていて、過去の記事もすべてその方針で書いてきました。ただ改めて考えると、なぜ「入れる」が自然だと感じるのか根拠がありません。書籍や新聞のページを思い浮かべると、「iPhone17」「3回」のように詰めて書かれているような気もします。

ルールを決めないまま書き続けると記事ごとに揺れるので、主要な日本語スタイルガイドを調べて立場を確認することにしました。

調べた5つのスタイルガイド

選定は、Web技術ブログでよく参照されるものと、日本語表記の公的な基準を混ぜて選びました。結論から先にまとめると次のとおりです。

JTF 日本語標準スタイルガイド v3.0（入れない）

日本翻訳連盟が無償公開している実務翻訳用のスタイルガイドで、ルール10に明記されています。

10. 半角文字と全角文字の間に半角スペースを入れない。
◯ JTF標準　✗ JTF 標準

出典: JTF 日本語標準スタイルガイド（PDF） §2.3.1.1

共同通信『記者ハンドブック』第14版（入れない）

1956年初版で60年以上使われてきた、新聞用字用語集のデファクトです。紙面の組版は日本語と半角英数字を詰めて書くのが前提で、数字と単位、漢字とアルファベット略語が隣接する場面もすべてベタ組みになっています。

新聞記事を読み慣れている目には、「iPhone17」「午前9時」「3回」のように詰めて書かれている方がむしろ見慣れた形のはずです。

文化庁「公用文作成の考え方」（2022建議）（入れない）

省庁・行政の公用文の書き方基準で、令和4年の文化審議会建議がベースになっています。縦書き横書きを問わず、日本語文中の半角英数字は前後にスペースを入れずベタ組みで書くのが原則とされています。

textlint-rule-preset-ja-spacing 既定値（入れない）

Web技術者に馴染みがあるのはこれです。textlintの日本語スペース関連プリセットの中にja-space-between-half-and-full-widthというルールがあり、既定値は"space": "never"になっています。

{
  "rules": {
    "ja-space-between-half-and-full-width": {
      "space": "never"
    }
  }
}

この設定ではこれはUnicodeが通り、これは Unicodeが警告になります。つまり明示的に設定を上書きしない限り、textlintを入れた時点で自動的に「入れない派」の校正になります。

出典: textlint-rule-preset-ja-spacing（GitHub）

Microsoft Japanese Localization Style Guide（入れる）

5つのうち唯一「入れる派」に立っていたのがこれです。§4.1.11「スペース」で次のように規定されています。

全角文字と半角文字の間
原則として半角のスペースを入れる。
OK: Word を利用するときは、　NG: Wordを利用するときは、

Microsoftのドキュメント、ローカライズされたWindowsのUI、ヘルプ文書、翻訳されたOfficeのマニュアルは、すべてこの方針で書かれています。

集計すると4対1だった

日本語出版物の側（翻訳・新聞・公文書・校正ツール）は4つ揃って「入れない」側で、「入れる」側はMicrosoftのローカライズガイド1つだけでした。

この結果は自分の事前予想と違っていて、直前まで「入れる派の方が主流で、入れない派は一部の古い書式」くらいに思っていました。実際に並べてみると逆で、日本語の公的な標準はほぼ揃って「入れない」側でした。

「入れる派」はどこから来たのか

ではなぜ自分は「入れる派が主流」と感じていたのか。振り返ると、普段読んでいるのがQiita・Zenn・noteといったWeb技術ブログで、これらは大半が「入れる派」で書かれています。書き手のスタイルガイドも「全角と半角の間に半角スペースを入れる」と明記しているケースが多い印象です。

この流派の起点を辿ると、行き着くのがMicrosoftのローカライズガイドです。

英語のタイポグラフィにはword spacing（単語と単語の間のスペース）の概念があり、空白で意味の切れ目を示すのが大前提になっています。英語ネイティブの目で日本語と英語の混在文を見ると「スペースを入れないと語の境界が分からない」という感覚が働きます。

Microsoftはソフトウェアのローカライズで、英単語や製品名を日本語訳文に大量に埋め込む必要があり、読みやすさを確保するために「入れる」ルールを採用したと考えるのが自然です。翻訳会社やQA業界はMicrosoftの案件を請け負う過程でこのルールを受け入れ、やがてWebのテクニカルライター・個人ブロガーへと伝わっていった、というのが自分の仮説です。

つまり「入れる派」は英語タイポグラフィの移植であって、日本語本来の組版から来たルールではありませんでした。

60d.devを「入れない派」へ試行転換した

ここまで調べたうえで、60d.devのスタイルガイド（.cursor/rules/blog-writing-style.mdc）を試行的に「入れない派」へ切り替えました。理由は次のあたりです。

• 4対1という数字そのもの
• 日本語組版の文化的系譜（書籍・新聞・公用文）に揃う
• 校正ツール（textlint）の既定値と一致し、自動化を乗せたときに追加設定が要らない
• 書籍タイトルでは当たり前の表記で違和感がない（書店で「Cursorの使い方」という本を見ても誰も違和感を覚えないはず）
• AIリライト時に、英語ベースの推論で不自然に混入する空白を抑制できる

特に最後のAI由来の混入は実害があります。Opus 4.7が書いた日本語をリライトすると、Cursor の AgentとCursorのAgentが同じ記事内で混在することがあり、これは英語の直感で1文ごとに揺れているせいだと考えられます。ルールを「入れない」で統一すると、lintで揺れを機械検出しやすくなります。

既存記事の移行は一括置換しない

方針転換で怖いのは過去に書いた記事です。60d.devには手書きHTMLの記事が20本弱あり、全部「入れる派」で書かれています。これを機械的に全置換しようとすると、次のような誤変換が起きます。

• コード片（バッククォート内）のスペースまで消してコンパイルエラー相当の表記になる
• URLやファイルパス内部の意味のあるスペース（まずないが）を消す
• 固有名詞の区切り（「Apple Silicon」のような半角語どうしの間）を消す
• 記事間で一斉置換が走ると、レビューが追いつかず意図しない破壊が混ざる

一括置換はやめて、編集・リライトの機会に併せて段階的に移行するという方針にしました。

• 新規記事は「入れない派」で書く
• 既存記事は、推敲やリライトの機会に併せて半角スペースの除去も行う
• 過渡期は記事単位で揺れがなければ可、ただし1記事内での揺れはNG

揺れるのが一番不自然なので、「記事ごとにはどちらかに倒す、記事間では当分混ざる」の線で運用します。

コード片の前後は例外を置いた

実務上の折り合いとして、インラインコード（バッククォート内）の前後は、必須ではないけれど半角スペースを入れてよい、という例外を設けました。

• OK: git stash を実行して、ブランチを切り替える
• OK: git stashを実行して、ブランチを切り替える
• NG（記事内で揺れる）: git stash を実行し、git checkoutで切り替える

理由は、密集箇所（例：「git stash git checkout git stash pop を順に実行する」のような文）でベタ組みにすると、どこまでがコードでどこからが日本語か一瞬迷うことがあるからです。JTFも記者ハンドブックもコード片を想定していないので、このあたりはWeb技術ブログ独自の都合で決めてよい部分だと考えました。

どちらを採るかは記事単位で統一すれば可、というゆるめのルールにしています。

迷ったときの判断軸

スタイルガイドに書いた優先順位はこうなりました。

1. 1記事内で揺れさせない（揺れが一番不自然）
2. 「入れない派」の原則に従う
3. コード片の前後は記事単位で入れる／入れないを統一
4. 公式表記が明確な固有名詞は公式に従う（例：Next.js、SwiftUI、iPhone 17 Pro）
5. 判断に困るケース（絵文字・半角カナ・数式記号との隣接など）はレビューで決め、ルールに追記する

半角英数字の前後に半角スペースを入れるかは、どちらが正しい日本語かの問題ではなく、媒体の性質と文化的系譜で決まる話だと思っています。Web技術ブログの文化圏だけを見ているとMicrosoft流が主流に見えますが、日本語の書籍・新聞・公文書を視野に入れると景色が変わる、という発見が今回の個人的な収穫でした。