App Storeのキーワードフィールド：100文字を使い切る方法
キーワードフィールドはApp Store掲載情報の中で最も目立たないパーツでありながら、最も重要な要素の1つです。ユーザーの目には触れません。App Store Connectの中、ローカライズごとに1つずつ存在し、Appleの検索インデックスに直接反映されます。使えるのはちょうど100文字で、その使い方次第でアプリが表示される検索クエリが決まります。
このフィールドの多くは、いつも同じ理由で無駄になります。カンマの後のスペース、複数形、アプリ名にすでにある単語、そして「the」や「app」のような穴埋め語です。この記事では正確なルールを解説し、実例で100文字をすべて埋め、さらに同じストアフロントで2つ目の100文字フィールドを手に入れる二次ロケールの裏技を紹介します。
Appleが実際に検索インデックスに使う要素
App Storeでは、キーワード検索のランキングに影響するテキストフィールドはごく一部です。
- アプリ名 — 最大30文字。最も強いシグナルです。
- サブタイトル — 最大30文字。アプリ名の次に強いシグナルです。
- キーワードフィールド — 最大100文字、ユーザーには非表示。この記事の主題です。
Appleはほかにも、アプリ内課金の表示名、アプリ内イベントのタイトル、そして2025年半ば以降はスクリーンショット内のテキストをOCRで拾い上げています。ただし核となるのはアプリ名・サブタイトル・キーワードフィールドの3つです。
説明文はApp Storeの検索にインデックスされません。狙いたいキーワードを説明文に10回書いても、ランキングには何の影響もありません（これはGoogle Playとは逆で、Google Playでは長い説明文がインデックスされます——両ストアの大きな違いの1つです）。だからこそ100文字のキーワードフィールドはこれほど重要になります。30文字のアプリ名と30文字のサブタイトルに収まらないランキング用語を置ける唯一の場所だからです。
何が収まるかを決めるルール
ここに挙げるルールはすべて、100文字をうまく使い切るためのものです。
- カンマは用語の区切りで、カンマも文字数に含まれます。フィールド全体で100文字であり、区切り文字も含まれます。10個の用語には9個のカンマが必要で、それだけで9文字を消費します。
- カンマの後にスペースは入れません。
budget,tracker,expenseと書くべきで、budget, tracker, expenseではありません。カンマの後のスペース1つひとつが、何の得もない無駄な文字です。 - フレーズ内のスペースは許可されますが、やはり文字数に含まれます。
net worthのような複数語の用語は問題ありませんが、単語間のスペースも100文字に含まれます。 - 単数形を使います。Appleは自動的に複数形にもマッチさせます。
trackerと入れれば「trackers」でもランクされます。trackersと書くのは余計な1文字を無駄にするだけです。 - アプリ名やサブタイトルの単語は絶対に繰り返しません。Appleはすでにそれらをインデックスしています。同じ単語を2回書いてもキーワード密度のボーナスはなく、繰り返した単語は無駄な枠になります。
- 穴埋め語と「app」は省きます。「the」「a」「for」「with」「app」といった単語は検索価値を持ちません。「app」やカテゴリ名は無料でマッチされるので、そこに文字を使ってはいけません。
- 競合名や商標は入れません。Appleの審査ガイドライン2.3.7は「アプリを正確に説明するキーワードを設定する」よう求め、「システムを操作する目的だけで、商標や人気アプリ名、価格情報、その他無関係なフレーズをメタデータに詰め込む」ことを禁じています。Appleは「不適切なキーワードをいつでも修正する場合がある」としています。競合ブランドをキーワードフィールドに入れるのは、メタデータ却下を招く行為です。
フレーズを作るのにスペースや大文字は必要ありません。Appleはアプリ名・サブタイトル・キーワードフィールドをまたいで単語同士を自動的に組み合わせ、複数語のクエリを作り出します。「budget」がアプリ名にあり、「planner」がキーワードフィールドにあれば、そのフレーズを一度も書かなくても「budget planner」でランクされる可能性があります。つまりキーワードフィールドは完成したフレーズのリストではなく、単語の集まりだと考えるべきです。
実例：100文字を余すことなく埋める
習慣トラッカーをリリースするとしましょう。掲載情報はこうなります。
- アプリ名（30文字以内）：
Streaks: Habit Tracker - サブタイトル（30文字以内）：
Build routines and goals daily
アプリ名とサブタイトルにはすでに streaks、habit、tracker、build、routines、goals、daily に加えて「app」とカテゴリ名（無料）が含まれています。これらの単語はキーワードフィールドに入れる必要はありません。残るのは、習慣管理アプリを探すユーザーが検索しそうな、それ以外のすべての言葉のためのスペースです。
ちょうど100文字ぴったりに収まるキーワードフィールドの例はこうです。
reminder,planner,checklist,journal,ritual,chore,productivity,motivation,discipline,self control,diet
数えてみましょう。11個の用語、10個のカンマ、そしてself control内の1つのスペース。合計でちょうど100文字になり、余りも無駄もありません。すべての用語が単数形の名詞で、アプリ名やサブタイトルと重複するものはなく、カンマの後にスペースが1つもありません。もしreminders, planner, checklistsのように複数形とカンマ後のスペースを使っていたら、制限を超えてしまい、実際にインデックスされる用語は少なくなります。
自分のフィールドをチェックする簡単な方法は、文字数カウンターに貼り付けてみることです（App Store Connectはリアルタイムで文字数を表示します）。100文字を超えると、超えた分の用語は単純にインデックスされません。きれいに切り詰められるわけではなく、ランキングシグナルの末尾から静かに消えてしまいます。
es-MXの裏技：同じストアフロントでもう100文字
1つのストアフロントがインデックスするロケールは1つだけではありません。米国のApp Storeは英語（米国）のキーワードフィールドと同時に、二次ロケールのキーワードフィールドもインデックスします。米国の場合、スペイン語（メキシコ）——es-MX——が定番の2つ目の枠です。es-MXのキーワードフィールドを埋めれば、それらの用語も米国ストアで検索対象になります。
正しく行えば、これでインデックス可能なキーワードの空間が100文字から約200文字へと、ほぼ2倍になります——しかも同じユーザー層に対してです。注意点は、2つ目のフィールドに別の用語を入れて初めて効果があること。ここには2つの正確なルールがあります。
- 各単語は1回だけカウントされます。ある単語がen-USとes-MXの両方のキーワードフィールドに現れても、重複分には何の意味もありません。同じリストをes-MXにコピペしても追加のリーチはゼロで、2つ目のフィールドを無駄に使うだけです。
- 単語はロケールをまたいで組み合わされません。Appleは1つのローカライズ内で複数語のフレーズを組み立てるのであって、2つをまたいでは組み立てません。つまり「bus」がen-USだけに、「metro」がes-MXだけにあれば、それぞれの単語ではランクされる可能性があっても「metro bus」というフレーズではまずランクされません。
実践的なやり方はこうです。メインの100文字をen-USに入れ、es-MXにはまったく別の単語のセット——最初に入りきらなかった用語——を埋めます。上記の習慣トラッカーなら、es-MXにはgym,water intake,meditation,mindfulness,sleep,focus timer,calendar,progress,quit,streak counterのような用語を入れられます。どれもen-USのフィールドやアプリ名・サブタイトルと重複しません。同じストアフロントでインデックス可能な範囲が2倍になり、どの用語もアプリを正直に説明しているのでガイドライン違反のリスクもありません。
この仕組みはes-MXだけにとどまりません。米国のストアフロントは複数の並行ロケールをインデックスできるため、各フィールドをきちんと別内容に保つ限り、同じ原理でセマンティックなリーチをさらに広げられます。
フィールドが無駄になる5つのパターン
- カンマの後のスペース。最も多い漏れです。10個あれば10文字を失います。
- 複数形。Appleは単数形からマッチさせます。余分な「s」は純粋な無駄です。
- アプリ名やサブタイトルの繰り返し。ボーナスはなく、ただ枠を使うだけです。
- 穴埋め語や「app」。検索価値はゼロです。
- en-USをes-MXにそのまま複製する。無料で手に入るはずの2つ目の100文字を捨てることになります。
掲載情報全体、そしてMokbiの中での位置づけ
キーワードフィールドは、30文字のアプリ名、30文字のサブタイトル、説明文、フィーチャーグラフィック、スクリーンショットを必要とする掲載情報の中の1要素にすぎません——それぞれがストアごとにローカライズされる必要があります。これを数言語だけでも手作業でやると、そこに時間の大半が消え、誰も2つ目のキーワードフィールドをゼロから書きたがらないために、es-MXの裏技もたいてい省略されてしまいます。
Mokbiは単なるスクリーンショットエディタではなく、掲載情報全体のパブリッシャーです——スクリーンショットは、Screenshots → Feature graphic → Store text → Translate → Publish というフローの1ステップにすぎません。AIがアプリの情報から掲載情報全体（タイトル、サブタイトル、キーワード、説明文）の草案を作り、それを50言語に翻訳します。ストアごとにキーワードフィールドを書き分けてローカライズするため、es-MXフィールドはコピペではなく本物の別の用語で埋められ、2倍化が脚注のままで終わらず実際に起こります。
次に読むべき記事
出典：AppleのApp Store searchおよびReview Guidelines（2.3.7）ドキュメント、aso.devのクロスローカライゼーション解説、AppTweakのiOSキーワードフィールドガイド。