[Chromeの自動入力] ふりがな対応を強化されたらしいので試してみた
どうも!オペ部の西村祐二です!
Chrome for Developers Blogで、Chromeの自動入力が日本語のふりがな(phonetic name)対応を強化したという記事が2026-04-15に公開されていました。
日本の住所入力フォームには「氏名」と「フリガナ」が両方ある構成が多く見られます。これまでChromeの自動入力はふりがな欄のカバーが弱く、結局ユーザーに手入力させていたサービスが多かった印象です。今回のアップデートでふりがなも保存・自動入力対象になったので、既存のフォーム構成で動くかを試しました。
Japanese phonetic name autofill とは
公式ブログによると、Chromeの自動入力が日本語のふりがな(カタカナ/ひらがな)を保存し、フォーム上のふりがな欄に自動入力する対応が強化されました。要点は次の通りです。
- 日本の名前はKanji(漢字)とFurigana(ふりがな)で別フィールドに入力することが多いが、HTML標準にはふりがなを示す標準値が存在しない
- Chromeが保存したphonetic profileをもとに、フォーム側の該当フィールドを検出して自動入力する
- Chromeは日本語のフルネームを姓・名に自動分割する。分割精度を上げるため、ユーザー側で区切り文字を指定することもできる(
chrome://settings/addresses) - 設定UIではひらがな表示がデフォルト(Google Contactsと同じ挙動)
Chromeが使う3つのシグナル
公式ブログによると、Chromeの自動入力は以下の3つのシグナルに基づくヒューリスティクスでふりがな欄を識別するようです。
autocomplete属性(最も強いシグナル)- フィールドの
<label>テキスト - フィールドの
name属性
autocomplete属性が最優先ですが、ふりがなを表す標準値がHTMLに存在しないため、この属性だけでふりがなかどうかは判別できません。そこでChromeは、同じautocomplete値(例: family-name)を持つ複数のフィールドがある場合に、ラベルとname属性で「漢字の姓」と「ふりがなの姓」を区別します。
Chromeの処理は2段階
ふりがな欄に関するChromeの処理は、目的が異なる2つのステップに分かれています。
| ステップ | 目的 | 参照するもの |
|---|---|---|
| 1. 検出 | このフィールドは「ふりがな欄」か? | autocomplete / name / <label> |
| 2. 入力種別決定 | カタカナで入れるか、ひらがなで入れるか? | <label> のみ |
このため、後続の表で name 属性欄に セイ / せい のようなカタカナ・ひらがな文字列が並んでいても、それはステップ1(検出)の手がかりにすぎません。実際に入力される文字種(ステップ2)には影響せず、入力種別は <label> だけで決まります。
有効なname/ラベル文字列
公式ブログは、Chromeのパーサーがふりがな欄として認識する「有効な文字列」を明示しています。
| フィールドタイプ | 有効な name 属性 | 有効な <label> テキスト |
|---|---|---|
| Phonetic full name | full-name-phonetic / セイメイ / せいめい |
セイメイ / せいめい |
| Phonetic family name | family-name-phonetic / セイ / せい |
セイ / せい / 姓ふりがな |
| Phonetic given name | given-name-phonetic / メイ / 名ふりがな |
メイ / めい / 名ふりがな |
日本のフォーム慣習として last_name_kana や first_name_kana のような命名も広く使われていますが、これらは公式の有効パターンに含まれていません。ただし後述のパターン2で検証したとおり、ラベルに「フリガナ」のようなカタカナ文字列が含まれていればlabel側ヒューリスティクスで拾われるケースもあります。検出の安定性を重視するなら、新規設計では上表の文字列に合わせておくのが無難です。
カタカナ/ひらがなの判別
Chromeは入力先がカタカナかひらがなかをラベル文字列から判定します(name属性ではありません)。
- ラベルにカタカナが1文字以上含まれていれば → カタカナで入力
- それ以外 → ひらがなで入力
ラベル例ごとの挙動:
| ラベル | 入力される文字種 |
|---|---|
セイメイ(カタカナ) |
カタカナ |
せいめい(ひらがな) |
ひらがな |
セイメイせいめい(混在) |
カタカナ |
Phonetic full name(英語) |
ひらがな |
英語ラベルの場合はカタカナが含まれないため、ひらがなで入力されます。多言語対応のフォームでも動作の方針を把握しておくと迷いが減ります。
今回のポイントは、HTML側に「これはふりがな欄です」という標準属性が無いにもかかわらず、Chrome側のヒューリスティクスで検出してくれる点です。既存のフォームでも、name属性やラベル文字列が公式の有効パターンに近ければ検出される余地があります。後述のパターン2でもそのケースが確認できました。
試してみる
環境
- Chrome(147で検証。公式ブログでは対象バージョンの明記は無し)
- macOS 15 (Sequoia)
- 検証用HTML: 1ページに4パターンのフォームを並べた最小構成
1. Chrome側にphonetic profileを保存する
Chromeのふりがな自動入力は、保存された住所プロファイルのふりがな情報を参照する仕組みです。chrome://settings/addresses で住所を編集/追加すると、「名前」の下に「よみがな」の入力欄が表示されます。ここに氏名のふりがなを登録しておくと、フォーム側のふりがな欄へ自動入力されます。ふりがなを登録していない住所プロファイルでも漢字氏名や住所本体のautofillは動くので、ふりがな自動入力を利用したい場合にだけ登録すれば十分です。

姓・名の区切りが曖昧な場合は、次の区切り文字のいずれかを挟むことで分割精度が上がると案内されていました。
-(ハイフン)・(カタカナ中黒)·(中点)(全角スペース)(半角スペース)
カタカナで入力しても、設定UI上はひらがなに統一表示されます(Google Contactsの標準挙動)。フォーム側にカタカナで入力されるかひらがなで入力されるかは、入力先フォームのラベル文字列から判定されるため、保存はひらがなで問題ないです。
2. 検証用HTMLを用意する
4パターンを1ページにまとめました。
- 公式推奨パターン
- よくある日本のフォーム慣習
- autocomplete非標準値の落とし穴
- 反証用
の4つで、Chromeが何を拾い何を落とすかを一度に確認できる構成です。
検証用HTML(index.html)
<!doctype html>
<html lang="ja">
<head>
<meta charset="utf-8">
<title>Chrome ふりがな自動入力テスト</title>
<style>
:root { color-scheme: light; }
body { font-family: -apple-system, "Hiragino Sans", sans-serif;
max-width: 720px; margin: 2rem auto; padding: 0 1rem;
color: #222; background: #fff; line-height: 1.6; }
form { border: 1px solid #ccc; border-radius: 8px;
padding: 1rem 1.25rem; margin: 0.75rem 0 1.5rem; background: #fafafa; }
label { display: block; margin-top: 0.75rem; font-weight: 600; }
input[type="text"] { width: 100%; padding: 0.5rem 0.75rem;
font-size: 1rem; border: 1px solid #bbb; border-radius: 6px; box-sizing: border-box; }
.row { display: flex; gap: 0.75rem; } .row > div { flex: 1; }
</style>
</head>
<body>
<h1>Chrome ふりがな自動入力テスト</h1>
<!-- パターン1: 公式推奨(漢字 + ひらがな + カタカナの3行) -->
<h2>パターン1: 公式推奨パターン(漢字・ひらがな・カタカナ)</h2>
<form>
<div class="row">
<div><label>姓</label>
<input type="text" name="family-name" autocomplete="family-name"></div>
<div><label>名</label>
<input type="text" name="given-name" autocomplete="given-name"></div>
</div>
<div class="row">
<div><label>せい</label>
<input type="text" name="family-name-phonetic-hiragana" autocomplete="family-name"></div>
<div><label>めい</label>
<input type="text" name="given-name-phonetic-hiragana" autocomplete="given-name"></div>
</div>
<div class="row">
<div><label>セイ</label>
<input type="text" name="family-name-phonetic-katakana" autocomplete="family-name"></div>
<div><label>メイ</label>
<input type="text" name="given-name-phonetic-katakana" autocomplete="given-name"></div>
</div>
</form>
<!-- パターン2: よくある日本フォーム(last_name_kana / first_name_kana) -->
<h2>パターン2: 日本フォームの慣習(*_kana 命名)</h2>
<form>
<div class="row">
<div><label>姓</label>
<input type="text" name="last_name" autocomplete="family-name"></div>
<div><label>名</label>
<input type="text" name="first_name" autocomplete="given-name"></div>
</div>
<div class="row">
<div><label>姓(フリガナ)</label>
<input type="text" name="last_name_kana"></div>
<div><label>名(フリガナ)</label>
<input type="text" name="first_name_kana"></div>
</div>
</form>
<!-- パターン3: 非標準 autocomplete(autofillを壊すアンチパターン) -->
<h2>パターン3: 非標準autocomplete(アンチパターン)</h2>
<form>
<label>氏名</label>
<input type="text" name="name" autocomplete="name">
<label>フリガナ</label>
<input type="text" name="name_kana" autocomplete="furigana">
</form>
<!-- パターン4: ラベルが曖昧(反証用) -->
<h2>パターン4: ラベル曖昧(反証用)</h2>
<form>
<label>入力1</label>
<input type="text" name="field1" autocomplete="name">
<label>入力2</label>
<input type="text" name="field2">
</form>
</body>
</html>
autofillの挙動は http:// 経由の方が本番に近いため、簡易サーバ越しの確認も推奨します。
cd /path/to/test
python3 -m http.server 8080
# → http://localhost:8080/
手っ取り早くブラウザ上で試したいだけなら、公式ブログにCodePenデモのリンクが張られているので、そちらでも挙動を確認できます。
3. 公式推奨パターン(パターン1)
公式ブログが提示する推奨形をベースに、ラベルだけをひらがなとカタカナの2種類用意した構成です。各行の autocomplete には対応する通常name欄と同じ標準値(family-name / given-name)を指定し、ラベル文字列だけを変えて、入力種別がラベルから決まる挙動を確認します。
- 1行目(漢字): ラベル
姓/名— 漢字氏名がautofillされる - 2行目(ひらがな): ラベル
せい/めい— ひらがなふりがながautofillされる想定 - 3行目(カタカナ): ラベル
セイ/メイ— カタカナふりがながautofillされる想定
全6欄が自動入力された結果。

DevToolsのAutofillツールでは、ふりがな欄が Alternative family name / Alternative given name として分類されていることも確認できました。

公式の有効パターンに合致しており、ラベルのカタカナ/ひらがなに合わせて入力種別が切り替わる構成です。
4. 日本フォームの慣習(パターン2)
last_name_kana / first_name_kana のような日本のフォームで広く使われる命名です。ラベルには「姓(フリガナ)」「名(フリガナ)」を設定し、漢字側の autocomplete="family-name" / autocomplete="given-name" と対応させています。
4欄すべてが自動入力された結果。

DevToolsのAutofillツールでも、ふりがな欄が Alternative family name / Alternative given name として分類されていることを確認できました。

last_name_kana / first_name_kana というname属性自体は公式の有効パターン(family-name-phonetic など)に含まれていませんでしたが、実機で試したところ、パターン2でもふりがな欄まで自動入力されました。
ラベル「姓(フリガナ)」「名(フリガナ)」にカタカナの「フリガナ」が含まれているため、Chromeのlabel側ヒューリスティクスがふりがな欄として拾ってくれたと考えられます。
既存フォームで *_kana 命名が定着しているサービスでも、ラベル文字列に「フリガナ」を入れておけば検出される可能性があるという実例になりました。ただし検出の安定性を重視するなら、新規設計ではパターン1(family-name-phonetic 系)に揃えておくのが無難です。
5. 非標準autocompleteのアンチパターン(パターン3)
ふりがな欄に autocomplete="furigana" のような非標準値を付けた構成です。公式の説明によると、非標準値が指定されるとChromeはフォールバックせず、自動入力そのものが動かなくなります。
autocomplete="furigana" を指定したフリガナ欄にはautofillの候補が出ず、漢字氏名欄まで含めて自動入力が止まった状態です。

実機でも想定通り、フリガナ欄にautofillが発火せずアンチパターンが成立することを確認できました。autocomplete="furigana" のような「何となくふりがなと分かる属性値」を書きたくなる場面は現場でも起こりがちです。ただしChromeはその値を解釈できず、フォールバックもかからないため、結果的に自動入力を壊してしまいます。
6. ラベルが曖昧なケース(パターン4、反証用)
ラベルを「入力1」「入力2」と抽象化し、name属性も field1 / field2 にした構成です。3つのシグナルのうち autocomplete 以外(ラベル・name)を意図的に曖昧にしているため、ふりがな欄としては検出されない想定の反証テストになります。
ラベルとname属性を曖昧にしたフォームでは、ふりがな欄として検出されず自動入力候補が出ない状態。

この結果をもって、ラベル・name属性が実質的な判別材料になっていることを逆から裏付けられます。
autocomplete の扱い
Chromeの自動入力では autocomplete 属性が最も強いシグナルとして扱われます。ただし、非標準値を指定するとヒューリスティクスにフォールバックしないため、自動入力が動かなくなります。HTML標準にはふりがなを表す autocomplete 値が存在しないため、推奨される書き方は次の2択です。
- ふりがな欄の
autocomplete属性を省略する - 対応する通常name欄と同じ標準値を指定する(例: 姓のふりがなには
family-name、名のふりがなにはgiven-name)
どちらの場合も、Chromeは name 属性と <label> テキストで「漢字の名前」と「ふりがな」を判別します。
<!-- 推奨: autocomplete省略、ラベルとname属性で判別 -->
<label for="phonetic-family">セイ</label>
<input id="phonetic-family" name="family-name-phonetic" type="text">
<!-- 推奨: 対応する通常name欄と同じ標準値を流用 -->
<label for="phonetic-family">セイ</label>
<input id="phonetic-family" name="family-name-phonetic" type="text" autocomplete="family-name">
<!-- 非推奨: 非標準値でautofillが効かなくなる -->
<input name="last_name_kana" autocomplete="furigana">
公式ブログに掲載されているベストプラクティスの最小例は次の形です。
<form>
<!-- Full phonetic name -->
<label for="phonetic-full">セイメイ</label>
<input id="phonetic-full" name="full-name-phonetic" type="text">
<!-- Family phonetic name -->
<label for="phonetic-family">セイ</label>
<input id="phonetic-family" name="family-name-phonetic" type="text">
<!-- Given phonetic name -->
<label for="phonetic-given">メイ</label>
<input id="phonetic-given" name="given-name-phonetic" type="text">
</form>
1Password拡張を有効にしているとChrome autofillが働かないときの対策
Chrome拡張の1Passwordを有効化していると、そもそもChromeの「住所を保存、入力する」トグル自体が1Passwordに制御されて無効化されているケースがありました。
chrome://settings/addresses で住所autofillトグルがグレーアウトしているなら、ふりがな以前にChrome側のaddress profile機能が使えない状態です。
1Password Settings → General → 「Make 1Password the default password manager」をOFF にするとChrome側のaddress profile機能が利用できます。
手順の詳細・スクリーンショット・候補重複の抑え方などは、以下記事を参照ください。
試してみた感想
日本語フォームでネックだった「氏名は自動入力されるのにフリガナは手入力」という挙動が軽減される構成になりました。サービス会員登録のUXだと、この一手間が離脱要因になりがちなので、Chromeをメインブラウザで使っているユーザーには効いてきそうな改善だと感じました。
既存フォームで last_name_kana のような命名が定着しているサービスでも、ラベルに「フリガナ」(カタカナ)を入れておくだけで検出されることを確認できました。改修コストを抑えつつふりがな自動入力の恩恵を受けたい場合、ラベル側の調整が最小の打ち手になりそうです。
逆に、autocomplete="furigana" のような一見分かりやすい非標準値を付けるとautofill自体が止まるため、この落とし穴は避ける必要があります。DevToolsのAutofillツールで分類結果を見れば、どの手当てが効いたかを定量的に追えるので、既存フォーム改修時はDevToolsを活用すると良いかなと思いました。
まとめ
- 検出の仕組み: autocomplete / ラベル / name属性の3シグナルで動く。HTML標準にphonetic値がないため、実質の決め手はname属性とラベル
- 推奨実装: 新規フォームはname属性+ラベル
セイ/メイ。autocompleteは省略するか通常name欄と同じ標準値を流用。既存のlast_name_kana命名でも、ラベルに「フリガナ」を入れておけば検出される - 入力種別の判定: カタカナ/ひらがなはラベル文字列のみで決まる(カタカナが1文字でもあればカタカナ)
- 検証手段: DevToolsのAutofillツールで
Alternative full name / family name / given nameに分類されていれば検出成功 - ユーザー設定:
chrome://settings/addressesの「よみがな」欄でふりがなを保存(姓・名の区切りは-/・/·/ 全角/半角スペース)
vanilla-autokana のようなJS側のふりがな補助とは競合しないので、新規フォームはパターン1、既存はラベル文字列の調整から段階的に進めるのが良さそうです。
誰かの参考になれば幸いです。
参考リンク:





