翻訳しただけのナレッジベースは、ローカライズされたものではありません。日本のユーザーは名詞句のクエリで検索し、文章ではなく見出しの構造で記事をスキャンし、敬語・手順の書式・検索語が期待とズレるとサポート記事から離脱します。本記事では、翻訳されただけのKBを、日本のユーザーが実際に見つけ、たどれるものへと変える、構造面・言語面の判断を扱います。
英語版と日本語版のナレッジベースの間で最も影響の大きい違いは、記事の本文を読んでいる人には見えません。記事が開かれる「前」に何が起きるか、です。日本のユーザーは検索の仕方が違い、もし検索が正しい記事を浮かび上がらせなければ、記事そのものの品質は意味をなしません。
日本語のKB検索は、体言止め（たいげんどめ）——動詞や疑問符を伴わない名詞句のクエリ——が大半を占めます。英語話者が「how do I add a user」や「adding users」と入力するところで、日本語話者は「ユーザー追加」や「ユーザー 追加 方法」と入力します。クエリは疑問文ではなく、複合名詞や名詞のかたまりなのです。英語の疑問句クエリに最適化された検索エンジンは、日本語の名詞クエリに対して悪い結果を返します。重み付けが間違っているからです——日本語のクエリで意味を担うのは疑問語ではなく、名詞です。
2つ目の複雑さは、表記の切り替えです。日本語では1つの概念が、ひらがな・カタカナ・漢字で表現されることがあり——しかも、同じ用語に対して異なるユーザーが異なる表記を入力します。ログイン（カタカナ）、ろぐいん（ひらがな）、認証（漢字、よりあらたまった同義語）は、いずれもアプリケーションにサインインする行為を指します。もしKB検索がカタカナ表記しかインデックスしておらず、ユーザーがひらがな版を入力した場合、検索はゼロ件を返します。これは机上の問題ではありません。日本語のKBユーザー調査で最もよく挙がる「検索が壊れている」という不満そのものであり、英語話者の直感で検索をテストしているかぎり、まったく見えてこない問題です。
3つ目の検索行動。日本のユーザーは、手順記事を探しているとき、名詞クエリに「方法」（やり方／ハウツー）、「手順」（手続き／ステップ）、「やり方」を頻繁に付け足します。「ユーザー招待 方法」や「パスワード変更 手順」が自然なクエリの形です。つまり、これらのクエリが生む検索結果に表示されるためには、記事タイトルとメタデータに、トピックの名詞だけでなく、こうした接尾辞も含める必要があります。日本語タイトルから「方法」を省いた「ユーザー招待」というタイトルの記事は、それを含むタイトルに見劣りします。
英語のナレッジベースのタイトルは、慣習として動名詞や現在分詞の形を使います。Adding Users、Resetting Your Password、Configuring API Access。これらの形が英語の読者にとって心地よいのは、能動的なプロセスを示唆するからです——あなたはこれからこれをするのだ、と。日本語には英語の動名詞に文法上対応するものがなく、直訳すると、文法的にぎこちなく、日本のユーザーの検索の仕方とも一致しないタイトルになります。
自然な日本語のKBタイトルの構造は、名詞句＋の＋トピックの名詞＋方法／手順です。「Adding Users」は「ユーザーの追加方法」になります。「Resetting Your Password」は「パスワードのリセット手順」になります。「Connecting to the API」は「APIへの接続方法」になります。「方法」や「手順」という接尾辞は、任意の飾りではありません——それは、この記事が実行可能なステップを含んでいることを読者に伝え、別のタイトル形式を使う参照記事や概要コンテンツと区別する役割を果たします。
参照記事——ハウツーガイドではなく、概念の説明——は、別のタイトル構造を使います。トピックの名詞単独、あるいはトピックの名詞＋「について」や「とは」です。「ユーザー権限について」や「SSO認証とは」が、説明的なコンテンツの自然な形です。これらの形式を混ぜること——参照記事に「方法」を使ったり、手順記事から省いたり——は、読者が記事を開く前に、その期待を混乱させます。
英語のロングフォームのコンテンツは、見出しのスタイルをしばしばペース配分の仕掛けとして使います。小見出しで好奇心を生み（「保存をクリックしたら、何が起きる？」）、小さな問いを投げかけ、あるいは比喩やトーンを使って読者を文章の中へと運びます。これは英語のエディトリアルなライティングで機能し、一部の英語のヘルプコンテンツでも機能します。しかし、日本語のナレッジベース記事では機能しません。
日本のサポート記事の読者は、見出しを読書の手がかりとしてではなく、ナビゲーションのシステムとして使います。記事にたどり着き、見出しをスキャンし、自分の特定の問題に対応する見出しを見つけ、そのセクションへ直接ジャンプします。内容を明示的に宣言しない見出し——代わりにじらしたり、問いを投げかけたり、くだけたトーンを使ったりするもの——は、このスキャンパターンを壊します。読者は、その下の文章を読まないかぎり、そのセクションに自分の必要なものが含まれているかどうか判断できず、KBの文脈における見出しの目的そのものが失われてしまいます。
実務上のルール。日本語のKB記事のすべての見出しは、そのセクションが扱う内容を正確に説明する、完結した明示的な名詞句、または動詞を名詞化した句であるべきです。「チームメンバーはどうする？」ではなく「チームメンバーの招待方法」。「次のステップ」ではなく「設定の保存と確認」。「トラブルシューティング」単独（トップレベルの見出しとしては有用）ではなく「ログインできない場合のトラブルシューティング」。
文体（レジスター）——日本語の動詞の形と語彙における丁寧さのレベル——は、日本語ナレッジベースのコンテンツで最も頻繁に取り扱いを誤られる要素の1つです。失敗のパターンは3つあります。くだけすぎ（辞書形やカジュアルな文体。機械翻訳されたコンテンツによくある）、あらたまりすぎ（敬語。顧客対応のやりとりに使う尊敬・謙譲表現）、そして命令形（命令の形。英語のステップ説明によくあり、それを直訳すると自然に、しかし誤って出てきます）。
日本語のKB記事に正しい文体は丁寧体です。全体を通して文末をです・ます調にし、敬語の構文（ご利用いただけます、お選びください）は使わず、命令形（クリックせよ、命令の意味での「押してください」）も使いません。です・ます調は、敬語が帯びるへりくだり——直接の顧客コミュニケーションに属し、セルフサービスのドキュメントには属さないへりくだり——を伴わずに、プロフェッショナルで明快に読めます。
最も具体的な失敗は、命令形のステップ説明です。英語のKBのステップは命令形で書かれます。「Click Save」「Select your plan」「Enter your email address」。直訳は命令形を保ちます。「保存をクリックしてください」——これは「ください」を使い、丁寧な依頼であって、厳密には命令ではないものの、それでもです・ます形よりは命令に近いものです。正しい日本語のKBのステップの形は、その操作を、ユーザーが行うことの事実としての記述として述べます。「保存をクリックします」——「あなたは保存をクリックする」を、現在形の丁寧な形で。この違いは微妙ですが、流暢な日本語の読者はそれを感じ取ります。そして、全体で「ください」を使うKBは、ドキュメントのシステムというより、チャットボットのように感じられます。
英語のナレッジベースの書き手は、2〜3段階の操作に番号付きリストがふさわしいか、それとも文章（「まずXをし、次にYをする」）のほうがすっきりするか、と議論することがあります。日本語のKBライティングでは、この議論は存在しません。すべての手順操作は、含まれるステップがどれほど少なくても、番号付きリストとして書式化されます。文章形式の説明は——たとえ優雅で明快に書かれた文章であっても——日本のサポート記事の読者には信頼しづらく感じられます。番号付きステップが普遍的な慣習であり、その慣習からの逸脱は、その記事が日本語ドキュメントの規範を念頭に書かれていないことを示すからです。
各番号付きステップの構造は、一貫したパターンに従います。最初にステップ番号が来ます。操作は現在形の丁寧な形で記述します（クリックします、入力します、選択します）。操作が目に見える結果を生む場合——モーダルが開く、ページが読み込まれる、確認が表示される——その結果は、新しいステップとしてではなく、同じステップ内の次の文として記述します。サブステップが必要なら、親ステップの文章に埋め込むのではなく、副次的な採番方式（1-1、1-2）を使います。
関連する慣習。日本語のKB記事は、ユーザーが結果や確認を目にすべき箇所を、はっきりした視覚的・テキスト的な目印で示します。多くの場合、ノートブロックの中か、該当するステップの下にインデントして配置します。「確認: 招待メールが送信済みになります」は、ユーザーに検証ポイントを与えます。英語の記事はこれを暗黙のまま残すことが多いのに対し、日本語の記事はそれを明示します。
日本語のKB検索最適化は、英語のKB SEOとは根本的に異なります。課題はキーワードの密度でも、見出しタグの重み付けでもありません——表記のカバー範囲です。日本のユーザーは1つの概念に対して3つの表記のいずれも入力しうるため、ある重要な用語に1つの表記しか使っていないKB記事は、検索エンジンが正しく機能していても、他の表記による検索には表示されません。
実務的なアプローチは、重要な用語のすべての表記ゆれを記事に含めることです——文章の中に自然に、あるいは、KBプラットフォームが対応していればメタディスクリプションや類義語リストの中に。ログインについての記事なら、ログイン（カタカナ）、ログインする（動詞形）、サインイン（別のカタカナ）、そして場合によっては認証（漢字）を、自然な文脈で使うべきです。権限についての記事なら、権限（漢字）、アクセス権（混在）、そしておそらくパーミッション（カタカナ、より技術的な読者が使う）を、それぞれ少なくとも1回は使うべきです。
| 概念 | 主要な用語 | インデックスすべき表記ゆれ | 備考 |
|---|---|---|---|
| ログイン | ログイン | ろぐいん、サインイン、ログイン | カタカナが主。ひらがな表記は技術に詳しくないユーザーが入力 |
| パスワード | パスワード | ぱすわーど、パスワード | カタカナが優勢。ひらがなはカジュアルなユーザーやモバイルのフリック入力で |
| 設定 | 設定 | せってい、セッティング、設定 | 漢字が正。カタカナ表記は若いユーザーがときどき検索 |
| 招待 | 招待 | しょうたい、インビテーション、招待 | 漢字が主。カタカナ表記は製品固有の文脈で使用 |
| 権限／アクセス | 権限 | けんげん、アクセス権、パーミッション | B2Bでは漢字。カタカナは開発者が使用 |
| ダッシュボード | ダッシュボード | だっしゅぼーど、管理画面 | カタカナが主。一部の製品では「管理画面」を同義語として使用 |
類義語辞書やクエリ拡張に対応するKBプラットフォームは、最初からこれらの表記ゆれのマッピングを設定しておくべきです。類義語に対応しないプラットフォームでは、表記ゆれの用語を記事本文やメタディスクリプションに自然に含める必要があります。これはキーワードの詰め込みではありません——自分の好みの表記で入力する日本のユーザーが、すでにKBに存在する記事を見つけるために必要な、最低限のカバー範囲なのです。
日本語のナレッジベース記事はスクリーンショットを多用し、そのスクリーンショットにまつわる慣習は、経験豊富なユーザーが即座に読み取る品質シグナルを帯びています。翻訳されたKBコンテンツでは、2つの問題が一貫して生じます。日本語の読者向けに更新されていない代替テキストと、日本語ではなく英語の慣習に従ったキャプションです。
日本語のKBスクリーンショットの代替テキストは、行われている操作ではなく、スクリーンショットが示すインターフェースの状態を説明すべきです。英語の代替テキストはよく操作を説明します（「Screenshot showing the Save button being clicked」——保存ボタンがクリックされる様子を示すスクリーンショット）が、日本語の代替テキストは画像に見えている状態を説明します（「設定画面の「保存」ボタンが強調表示された状態」）。状態を説明するこの慣習は、手順を追うスクリーンリーダーのユーザーにとって代替テキストを有用にします——期待される状態が、自分が目にしているものと一致しているかを確認できるのです。
キャプションの配置も異なります。英語のキャプションは、画像の下に一文として現れることが多いです。日本語のKBキャプションは通常、対応するステップのテキストの上、あるいはステップ番号の直後に、「▼ 図1: 設定画面」の形式で配置されます。この配置は、読者が画像を見る前にスクリーンショットとそれが示すステップを結びつけます。これは、内容を確認する前にラベルを読む、という日本語の読み方のパターンに合致します。
現代の多くのヘルプセンタープラットフォームは、「関連記事」セクションをアルゴリズムで生成します——テキストの類似度、同時閲覧データ、機械学習のレコメンデーションに基づいて。これは、消費者向けの文脈でアルゴリズムのおすすめに慣れている英語のユーザーには、それなりにうまく機能します。しかし、ナレッジベースの文脈における日本のB2Bユーザーには、うまく機能しません。
日本のユーザーは、「関連記事」（かんれんきじ）セクションが構造化され、人の手でキュレーションされたリストであることを期待します。記事の内容を理解した誰かが、どの記事が関連していて、どの順番で並べるかを決めた——それが前提です。動的にシャッフルされるリスト、サムネイルと星評価のついたカルーセル、「おすすめの記事」と銘打たれたセクションは、プロフェッショナルなKBコンテンツが持つ、ドキュメントとしての真面目さと噛み合わない印象を与えます——そしてB2Bの文脈では、そのベンダーが日本のユーザーのためにサポートドキュメントをキュレーションする投資をしていないことを示すシグナルになります。
「関連記事」セクションは、「関連記事」または「関連ドキュメント」という見出しの下に置かれた、プレーンな順序付き、または順序なしのリストであるべきです。各項目は記事タイトルで、前述の「方法／手順」の構造と一貫して書式化します。サムネイルなし、閲覧数なし、評価なし。リストには3〜5項目を含め、親記事を読んだ人間が編集します。これは、日本語のKBにおける、最も労力が少なく、最も信頼シグナルの高い投資の1つです——ただし、手動のキュレーションに対応したプラットフォームとワークフローが必要です。
複数表記の検索のすき間、動名詞スタイルのタイトル、文章形式のステップ説明は、日本のユーザーがヘルプセンターから離脱する最もよくある理由です。日本語KBのQAレビューは、どの記事に再構成が必要か、そして、ユーザーが実際に入力しているクエリに対してどの検索設定が無言でゼロ件を返しているかを特定します。
ミニ診断を依頼する日本のユーザーは、英語圏のユーザーとどのように違うやり方でナレッジベースを検索しますか？
日本語のナレッジベース検索は、疑問形や動名詞ではなく、名詞句（体言止め）のクエリが大半を占めます。日本のユーザーは、完全な疑問文よりも「ユーザー追加」や「パスワード リセット 方法」と入力する可能性のほうがはるかに高いのです。さらに、同じ用語をひらがな・カタカナ・漢字の各表記で切り替えるため、KB検索は1つの概念に対して3つの表記すべてに対応するよう設定しておく必要があります。もしKB検索が漢字表記しかインデックスしておらず、ユーザーがカタカナを入力した場合、コンテンツが存在していても記事はゼロ件として返ってきます。
日本語のナレッジベース記事のタイトルは、英語のタイトルと同じ構造にすべきですか？
いいえ。英語のKBタイトルは通常、動名詞の形を使います（Adding Users、Resetting Your Password）。日本語のKB記事タイトルは、名詞＋「方法」、または動詞を名詞化した構造を使います（ユーザーの追加方法、パスワードのリセット手順）。動名詞の形には直接対応する日本語がなく、直訳するとぎこちないタイトルになり、ユーザーが検索で入力する言葉と一致しません。「方法」や「手順」という接尾辞は、ユーザーの期待を正しく設定する役割も担います——この記事は参照用の資料ではなく、手順を追って説明するものだ、と伝えるのです。
日本語のナレッジベース記事は、どの文体を使うべきですか？
日本語のナレッジベース記事は、丁寧体を使います。全体を通して文末をです・ます調にし、敬語の構文は使わず、命令形も使いません。命令形の「Click」はKBの文章では「クリックします」になり、「クリックしてください」でも単なる「クリック」でもありません。この文体は、敬語の過剰なへりくだりを伴わずに、プロフェッショナルで親切な印象を伝えます。敬語はセルフサービスのドキュメントではなく、顧客対応のメールに属するものです。文体の混在は、スタイルガイドなしで翻訳された記事であることを示す、最もよくある品質シグナルの1つです。
日本語のヘルプ記事では、番号付きの手順をどう書式化すべきですか？
日本のユーザーは、たとえ2つの操作で済むほど短い手順であっても、すべての手順記事が番号付きステップを使うことを期待します。文章形式の説明は、番号付きステップが普遍的なKBの慣習であるため、日本のユーザーには信頼しづらく感じられます。各ステップには主たる操作を1つだけ含め、です・ます形で記述し（「設定をクリックします」）、目に見える結果があればそれに続けます。サブステップは、文章ではなく副次的な採番方式（1-1、1-2）を用います。
日本語ナレッジベースの「関連記事」セクションは、アルゴリズムによるおすすめウィジェットとどう違いますか？
日本のユーザーは、「関連記事」セクションが、動的に変化するアルゴリズム的なウィジェットではなく、構造化され、キュレーションされたリストであることを期待します。どの記事が関連していて、どの順番で並べるかを、人間の編集者が決めている——それが前提です。セクションの見出しは、文字どおり「関連記事」または「関連ドキュメント」と書くべきです。サムネイル画像・評価・閲覧数を伴うアルゴリズム的なカルーセルは、日本のB2Bヘルプコンテンツが持つ、ドキュメントとしての真面目さと噛み合わない印象を与えます。