タグ: クロールとインデックス

ほとんどの時間は、Google の検索エンジンは正常に動作しています。私たちは、ウェブを検索しているユーザーや、Google にインデックス登録されているサイトのウェブマスターに影響を及ぼすような、技術的な問題が起きないように尽力しています。同様に、検索エンジンの基盤となるシステムも、ほとんどの場合意図したとおりに動作しています。わずかな障害が発生しても、サービスの運用を担当するチーム以外はほとんどわかりません。ただし、複雑なシステムである以上、大規模な障害が発生することがあり、ユーザーとウェブマスターの双方に影響する可能性があります。

過去数か月の間に、インデックス登録システムで問題が発生し、インフラストラクチャの他の部分にも波及しました。できる限り迅速に状況の改善に取り組みましたが、ユーザーとウェブエコシステムに高品質のサービスを継続的に提供するという目標に反することになり、誠に申し訳ありませんでした。

その後、何が起きたのかを綿密に精査しました。その過程で得られたいくつかの教訓をここで皆さんと共有したいと思います。このブログ投稿では、発生した問題について詳細に説明したのち、今後同様の問題が発生した場合にどのようにみなさまにお伝えする予定でいるかを共有します。その上で、Google への問い合わせ方法ついてウェブマスターの方々に改めてお伝えします。

数か月前に発生した問題

4 月に、インデックスに関する問題がいくつか発生しました。Google の検索インデックスは、ウェブからクロールした、ユーザーの質問に答えるのに有用と思われる数千億のウェブページを保持するデータベースです。ユーザーが Google 検索エンジンでクエリを入力すると、ランキング アルゴリズムが検索インデックスに登録されているページの中から、最も有益で関連性の高い検索結果を瞬時に見つけます。では、何が起こったのか、詳しく見ていきましょう。

1. インデックス登録の問題

はじまりは検索インデックスの一部が一時的に失われたことでした。
「インデックスの一部が失なわれた」とはどういうことでしょうか。

基本的に、検索結果をユーザーに提供する場合、サービス速度を向上させるために、ユーザーのクエリは Google 検索サービスをサポートする最も近いデータセンターに「旅」します。ここで Search Engine Results Page（SERP）が生成されます。そのため、インデックスの構成に変更（一部のページの追加や削除、ドキュメントの統合、または他の種類のデータ変更）がある場合、対象となるすべてのデータセンターに変更を反映する必要があります。結果として、世界中のユーザーに、最新バージョンのインデックスから一貫したページが提供されます。

すべてのデータセンターで同一のインデックスを維持し続けることは簡単な作業ではありません。大規模なユーザー向けサービスの場合、まず 1 つのデータセンターで更新をデプロイし、関連するすべてのデータセンターが更新されるまで拡大していきます。慎重に扱うべきインフラストラクチャについては、数日間にわたってロールアウトを実施し、異なる地域のインスタンスにインターリーブすることもあります（出典）。

予定していた検索インデックスに対する変更を進めている最中の 4 月 5 日（金）にデプロイシステムの一部が破損しました。具体的には、一部のデータセンターでインデックスを更新しているときに、少数のドキュメントが誤ってインデックスから削除されてしまいました。これが「インデックスの一部が失なわれた」ということです。

幸いにも、Google のオンコール エンジニアが問題を即座に察知しました。これは、私たちがソーシャル メディア上で問題を認識し始めたのと同時でした（週末に Google に連絡してくれた皆さん、ありがとうございました！）。その結果、問題が察知されてからわずか数時間で、すべてのデータセンターの検索インデックスを以前の安定した状態に戻し始めることができました（Google では、このような事態に備えてインデックスのバックアップを保持しています）。

Google は 4 月 7 日（日）に、この問題を認識しており、正常な状態に戻りつつあることを報告しました。データセンターのインデックスが徐々に安定した状態に戻りつつある中、Twitter での発信を続けました（4 月 8 日、4 月 9 日）。これは、4 月 11 日にすべてのデータセンターのインデックスが完全に元通りになったと確信できるまで続きました。

2. Search Console の問題

Search Console は、ウェブマスターが利用できる一連のツールやレポートであり、ウェブサイトの検索に関するパフォーマンスのデータにアクセスできます。たとえば、毎日のオーガニック検索結果における表示回数やクリック数、または検索インデックスに登録されているページ、未登録のページに関する情報を確認できます。

検索インデックスに上記の問題が発生した結果、Search Console でも不整合が見られるようになりました。これは、Search Console で表示されるデータの一部が検索インデックス自体から抽出されているためです。

• インデックス カバレッジ レポートは、データセンター間で整合性が取れた検索インデックスに依存します。
• 検索インデックスにページを格納するとき、ページにリッチリザルトのマークアップが含まれている場合など、ページに関する重要なシグナルでエントリにアノテーションを付けることができます。したがって、検索インデックスの問題は Search Console のリッチリザルト レポートに影響を及ぼす可能性があります。

基本的に、Search Console の個別レポートの多くは、専用データベースからデータを抽出しています。このデータベースの一部は、検索インデックスから取得した情報を使用して構築されています。以前のバージョンの検索インデックスに戻す必要があったため、Search Console データベースの更新も一時停止する必要がありました。これにより、一部のレポート（および URL 検査ツールなどの他のレポート）のデータが横ばい状態になりました。

問題が発生した検索インデックス全体のロールバックに数日かかったため（上記の説明を参照）、インデックス登録の問題が修正された数日後まで Search Console データベースの修正に取り掛かることができませんでした。Google は 4 月 15 日に、Search Console に問題があり、修正に取り組んでいることをツイートで明らかにしました。修正が完了したのは 4 月 28 日（レポートで新しいデータの収集を再開した日。上のグラフを参照）でした。4 月 30 日には Twitter で問題が解決したことを報告しました（ツイート）。

3.（インデックス登録の問題とは無関係な）その他の問題

Google 検索は数多くのシステムで構成されており、それぞれが別のシステムと密に連携しています。問題が同時期に起きた場合そこには因果関係があることが多いですが、場合によっては同時期に直接関係のない複数の問題が発生することもあります。

たとえば今回のケースでは、上記で説明したインデックス登録の問題とほぼ同時期に、新しい Google ニュースにおける最新のコンテンツの収集に関する問題が短時間発生しました。さらに、ページのレンダリング中に、特定の URL が Googlebot を他の無関係なページにリダイレクトし始めました。この問題はインデックス登録の問題とは関係ないもので、すぐに解決することができました（ツイート 1、ツイート 2）。

Google のコミュニケーションとその改善予定

数週間の間に行った（これまでご紹介してきた）ソーシャル メディアを使用した報告に加え、2 つの別チャネル（Search Console と Search Console ヘルプセンター）でウェブマスターに詳細を説明しました。

Search Console ヘルプセンター記事

Google は、問題を完全に特定した後、Search Console のデータの異常に関するヘルプページを更新しました。このページは、多数のウェブマスターに影響が及ぶ場合に、データ破損に関する情報を Search Console サービスに伝えるために使用されます。

Search Console

すべてのユーザーがソーシャル メディアや外部のヘルプセンター ページを読むわけではないので、Search Console レポートにアノテーションを追加して、データが正確でない可能性があることをユーザーに通知しました（下の画像を参照）。この情報は、問題が解決した後に追加したものです。[詳細を見る] をクリックすると、ヘルプセンターの「データの異常」ページに移動します。

今後のコミュニケーションについて

問題が発生した場合、Google には「事後分析」の文化があります。障害に関して報告するドキュメントを作成し、同じ問題が今後発生しないよう努めます。プロセス全体について詳しくは、Google サイト信頼性エンジニアリングのウェブサイトをご覧ください。

4 月のインデックス登録の問題をきっかけに、大規模なシステム障害が発生した場合にウェブマスターに明確に伝える方法を事後分析に含めました。主な決定事項は次のとおりです。

1. Search Console 内で広範な問題に関する情報を迅速に共有する方法を探り、機能停止が疑われる場合にウェブマスターが確認すべき主な参照ポイントとして役立つ情報を提供します。
2. 必要に応じて、より迅速に Search Console のデータの異常ページに投稿します（Search Console データに長期間にわたって障害が見られる場合）。
3. このような問題の発生時に、Google が問題を認識しており、その解決が近いことを速やかに知らせてウェブマスターの方々に安心していただけるよう、可能な限り速やかに Twitter で発信を続けます。

上記のコミットメントは、今後起こり得る同様の状況に備えて、ウェブマスターに対し全体的な透明性を確保するためのものです。

改善策の実施例「新しい URL のインデックスが登録されない」

5 月 22 日に別の問題が発生した際、新しいコミュニケーション方法を試しました。発生した問題は、特定の URL の処理中、予定されていたインフラストラクチャ アップグレードの後に重複管理システムのメモリが不足し、すべての受信 URL の処理が停止したというものです。

上記 の 3 つのポイントに加えて、コミュニケーションについて考慮した結果を時系列で示します。

1. Google が問題を認識（カリフォルニア時間 5 月 22 日午前 5 時半頃）
   現在発生中の問題についてツイート（同 5 月 22 日午前 6 時 40 分頃）
   解決したことをツイート（同 5 月 22 日午後 10 時頃）
2. ヘルプセンターの「データの異常」ページを更新することを検討しましたが、大部分のウェブマスターの Search Console データに長期的な影響はないと判断し、更新を見送ることにしました。
3. この問題によりご迷惑をかけたことで、「いずれかの Google システムに問題が発生し、ウェブマスターに影響を及ぼす可能性がある」ことを Search Console 上で明確に知らせる手段が必要という以前の結論が裏付けられることになりました。こうしたソリューションの実装には時間がかかる場合があります。このトピックは今後も引き続き取り上げていく予定です。

8 月にも同様のインデックスの問題が発生しました。5 月 22 日の時と同じように、みなさんに問題の発生と問題解決に取り組んでいることをお伝えするツイートを行い、問題が解決した際にもツイートしてお知らせしました。

デバッグ方法とお問い合わせについて

この投稿により、Google のシステムの複雑さと、時にはシステム障害が発生する事を知っていただけたことと思います。また、問題が発生したときに Google がどのようにお知らせするかをご理解いただく一助となれば幸いです。ただし、この投稿ではシステムの広範囲にわたる障害に焦点を当てていますが、ほとんどのウェブサイトにおけるインデックス登録の問題は、個々のウェブサイトの構成に原因があります。構成によっては Google 検索が対象のウェブサイトのインデックスを適切に登録できない場合がありますので、ご留意ください。そのような場合、ウェブマスターは Search Console やヘルプセンターを使用して問題をデバッグすることができます。デバッグした結果、自身のサイトの問題ではないと考えられる場合、または解決方法がわからない場合は、Google や Google コミュニティまでご連絡ください。いつでもお待ちしております。Google に問題を報告する方法は次のとおりです。

• ウェブマスター コミュニティを確認する。他のウェブマスターが報告した問題で、あなたのサイトに影響を及ぼすものが含まれている場合があります。
• 直接、報告する。イベントの際などにも直接ご報告ください。いつでもお待ちしています（カレンダー）。
• Google プロダクト内で報告する。Search Console のフィードバック ツールをご利用いただくと、非常に助かります。
• Twitter や YouTube もぜひご活用下さい。

「モバイル ファースト インデックス」の取り組みについて最初にお知らせしてから 2 年が経過しました。これは、ユーザーがウェブにアクセスする際に最も使用しているデバイスを考慮してスマートフォン用 Googlebot でクロールを行う取り組みです。あらゆる種類のデバイスに対応する素晴らしいウェブサイトが作られ、世界中で数多くのウェブサイトがモバイルウェブに対応しました。まだすべきことは多くありますが、ここに、モバイル ファースト インデックスに移行したページがグローバルでの検索結果の半数を超えたことをお知らせします。

モバイル ファースト インデックスの確認

通常、モバイル ファースト インデックスへのサイトの移行は、移行準備が完了したことをテストで確認できたときに行います。サイトを移行させた場合には、Search Console のメッセージを通じて、サイト所有者への通知が行われます。サイトの移行はサーバーログでも確認できます。移行後はスマートフォン用 Googlebot からのリクエストが大半を占めているはずです。また、URL 検査ツールを使用することでより簡単に確認できます。サイト所有者は同ツールでサイトの URL が最後にどのようにクロールおよびインデックスされているかを確認できます（確認はサイトのトップページだけで十分です）。

レスポンシブ デザインの手法がサイトに採用されているのであれば、特に準備は不要です。レスポンシブ ウェブデザインが採用されていないサイトでは、評価時に次の 2 種類の問題が比較的多く見られました。

モバイル版ページの構造化データの欠落

構造化データは、ページのコンテンツを把握しやすくする上で便利なものです。また、検索結果で自身のページをより効果的に強調できるようにもなります。デスクトップ版ページで構造化データを採用しているのであれば、モバイル版ページでも同じ構造化データを使用する必要があります。これは、非常に重要なことです。モバイル ファースト インデックスでは、インデックスの対象となるのはモバイル版ページのみになるため、モバイル版ページで構造化データが使用されていないと、構造化データが見落とされてしまいます。

なお、この問題に関しては、ページのテストの際に気をつける点があります。テストに際しては、構造化データの一般的な検証を行い、次にモバイル版ページの構造化データと比較することをおすすめしています。モバイル版ページに対しては、モバイル端末のシミュレーションを行ってソースコードを確認したり、モバイル フレンドリー テストツールで生成した HTML を使用したりすることをおすすめしています。一点ご留意いただきたいのは、モバイル ファースト インデックスに関して言えば、ページがモバイル フレンドリーである必要ありません、という点です。

モバイル版ページの画像代替テキストの欠落

画像に alt 属性（「代替テキスト」）を指定することで、スクリーン リーダー（モバイルでも使用されます）を使うユーザーや検索エンジンのクローラに対して、画像の内容を説明できるようになります。画像に代替テキストが指定されていない場合、Google 画像検索でページ上の画像のコンテキストを把握することが非常に難しくなります。

ウェブサイトの主要なモバイル版ページで、ソースコードの「img」タグを確認してください。上述のとおり、モバイル版ページのソースコードは、ブラウザでモバイル端末のシミュレーションを行って表示させることも、モバイル フレンドリー テストで、Googlebot が生成するバージョンを確認することもできます。ソースコードの「img」タグを探し、Google 画像検索で表示させたい画像に alt 属性が適切に指定されているか再度確認してください。

たとえば、次のように指定します。

代替テキストが適切に指定されている例:
<img src="cute-puppies.png" alt="ブランケットの上にかわいい子犬がいる写真">

代替テキストが指定されていない例:
<img src="sad-puppies.png">

多くの素晴らしいウェブサイトが、モバイルでも適切に表示されるようになるのは喜ばしいことです。より多くのウェブサイトがモバイル ファースト インデックスでインデックスされ、サイトへのアクセスに最も使用されるスマートフォンでより多くのユーザーがウェブを検索できるようになることを願っています。Google はこの変更を慎重に確認して評価し続けます。ご不明な点がございましたら、ウェブマスター フォーラムまたはイベントでご質問ください。

AJAX クロールに関するスキーム（英語）は、JavaScript ベースのページに Googlebot がアクセスできるようにするための方法として導入されましたが、廃止の予定であることを以前にお知らせいたしました。長期間にわたる Google のエンジニアの取り組みによって、Googlebot による JavaScript のレンダリング能力は大幅に向上してきました。こうした進歩を踏まえて、2018 年の第 2 四半期に、サイト側に JavaScript ベースのページのレンダリングを求めるのではなく、Google 側でレンダリングする形へと移行します。つまり、AJAX クロールに関するスキームは使用されなくなります。

ご存じのとおり、AJAX のクロールに関するスキームでは、URL に「#!」が含まれているページか、「fragment メタタグ（英語）」が設定されているページのいずれかを対象として、URL に「?_escaped_fragment_=」が含まれたページをクロールします。この URL でクロールされるページは、完全にレンダリング済みのページか、それと同等の状態のページ（そのウェブサイト自体で作成されるもの）である必要があります。

今回の変更に伴い、#! が含まれている URL は Googlebot によって直接レンダリングされるようになり、ウェブサイトの所有者はレンダリング済みのページを提供する必要がなくなります。こうした URL のページは Google 検索結果に引き続き表示されます。

ほとんどの AJAX クロールのウェブサイトに対しては今回のアップデートに伴う大きな変化はないものと想定していますが、ウェブマスターの皆様は以下に説明するようにページを再度確認してください。サイトに潜在的な問題が検出された場合は通知が送信されます。

サイトにおいて現在、#! が含まれている URL か fragment メタタグのいずれかをお使いの場合は、以下の手順を行うことをおすすめします。

• Google Search Console でウェブサイトの所有権を確認して Search Console のツールへのアクセス権を取得し、問題が検出された場合に Google から通知が届くようにします。
• Search Console の「取得してレンダリング」を使ってテストします。#! が含まれている URL とエスケープされた URL のテスト結果を比較して、違いがないかを確認します。ウェブサイトのさまざまな部分についてこのテストを実施します。サポートされている API について詳しくはデベロッパー向けドキュメント（英語）をご覧ください。また、必要に応じてデバッグガイド（英語）もご参照ください。
• Chrome の [要素を検証] を使用して、リンクに「a」HTML 要素が使われていることと、必要に応じて（ユーザー作成コンテンツ内など）rel=nofollow が指定されていることを確認します。
• Chrome の [要素を検証] を使用して、ページのタイトルと description メタタグ、robots メタタグ、その他のメタデータを確認します。また、レンダリングされたページで構造化データ（英語）が利用可能となっているかどうかも確認します。
• Flash や Silverlight といったプラグイン ベースのテクノロジーに含まれているコンテンツを検索のインデックスに登録するには、JavaScript か「標準の」HTML に変換する必要があります。

この変更がウェブサイトの運営と管理をより容易にし、サイト側でページをレンダリングする必要性が軽減することを願っています。ご質問やご意見がございましたら、お気軽にウェブマスター ヘルプ フォーラムか JavaScript サイトのワーキング グループ（英語）までお寄せください。

注 : この投稿は、Google のウェブ検索に固有のものです。Google の他のサービスについては、適切なヘルプセンター（Google ショッピングなど）またはヘルプ フォーラムに問い合わせてください。

今や「年中無休」が当たり前となっている世の中ですが、オンラインサービスでは、サイトを一時的に停止しなければならない場合もあります。今回は、検索結果の掲載順位に影響を及ぼすことなく、サイト（またはその一部機能）を一時停止する方法をご紹介します。

方法 1: カート機能をブロックする

ユーザーによる購入のみを停止したい場合は、その特定の機能だけを無効にする方法が一番簡単です。ほとんどの場合、ショッピング カート ページのクロールかインデックス登録のどちらかをブロックすることで対応できます。クロールは robots.txt ファイルで、インデックス登録は robots メタタグでブロックできます。検索エンジンによるコンテンツの検出またはインデックス登録が停止するため、それを適切な方法でユーザーに伝える必要があります。たとえばカートへのリンクを無効にする、適切なメッセージを表示する、カートの代わりに情報ページを表示するなどの方法があります。

方法 2: インタースティシャルやポップアップを常に表示する

ユーザーがサイト全体にアクセスできないようにする場合は、サイトが一時的に利用できないことを示すメッセージ、情報ページ、またはポップアップを表示し、サーバーから 503 HTTP ステータス コード（「サービスはご利用いただけません」）を返します。503 ステータス コードを返すことで、ユーザーに表示する一時的なコンテンツが Google にインデックス登録されるのを防ぐことができます。503 ステータス コードを返さないと、インタースティシャルなどがウェブサイトのコンテンツとしてインデックス登録されてしまうことがありますのでご注意ください。

Googlebot は 503 を返すページに対して、最長で 1 週間ほどクロールを再試行します。その期間を過ぎても 503 を返すページはパーマネント エラーとして扱われ、検索結果から除外されます。Retry-After ヘッダーを追加すると、サイトが利用できない期間を示すことができます。ただしサイトのブロックが 1 週間を超えると、サイトを停止している方法に関わらず、サイトの検索結果に悪影響が及ぶ可能性があります。

方法 3: ウェブサイト全体をオフにする

サーバーを完全にオフにするという方法もあります。サーバーを別のデータセンターに物理的に移動する場合などはこの方法がよいでしょう。この方法を使用する場合は、一時的なサーバーを用意してユーザー向けの情報ページを表示し、すべての URL で503 HTTP ステータス コードを返します。その期間中は DNS を切り替えて、この一時的なサーバーを経由するようにします。

1. 切り替えの数日前に、DNS TTL の時間を短く（5 分など）設定しておきます。
2. DNS を一時的なサーバーの IP アドレスに変更します。
3. リクエストが一時的なサーバーに送信されるようになったら、メインサーバーをオフラインにします。
4. ... サーバーがオフラインになりました ...
5. 戻す準備ができたら、メインサーバーを再びオンラインにします。
6. DNS をメインサーバーの IP アドレスに戻します。
7. DNS TTL を通常の設定に戻します。

これらの方法が、ウェブサイトを一時停止するときにお役に立てば幸いです。ご不明な点などありましたら、ウェブマスター ヘルプフォーラムでお気軽にご質問ください。

なお、地域密着型のビジネスを展開されている方は、ローカル リスティングの営業時間にビジネスの停止期間を設定することも忘れないでくださいね。

Google では、ウェブ上の技術の変化に応じて、Googlebot で使用するユーザー エージェントを定期的に更新しています。来月、Googlebot のスマートフォン用ユーザー エージェントを更新する予定です。

現在は、次の Googlebot スマートフォン用ユーザー エージェントを使用しています。

Google では、最新のウェブ技術を使用しているページをレンダラーが適切に解釈できるように、ユーザー エージェント文字列を更新しています。Google のレンダラーは進化を続けており、今回のユーザー エージェント文字列の更新は、レンダラーが Safari よりも Chrome により近づいていることを示しています。サイトが幅広いユーザーやブラウザで適切に表示されるように、機能検出やプログレッシブ エンハンスメントの使用をおすすめします。

Google の評価によると、今回のユーザー エージェントの変更は 99% のサイトで影響がない見込みです。サイトが影響を受ける場合に最も多い理由として考えられるのは、そのサイトが Googlebot の特定のユーザー エージェント文字列を期待している場合です。Googlebot に対するユーザー エージェント スニッフィングは推奨されておらず、クローキングの一形態と見なされます。Googlebot は他のブラウザと同様に扱ってください。

サイトが今回の更新による影響を受けそうな場合は、Search Console の「取得してレンダリング」ツールを使って（新しいユーザー エージェント文字列で更新済みです）、または、ブラウザのデベロッパー ツール（Chrome のデバイスモードなど）でユーザー エージェント文字列を変更する方法で、サイトを確認することをおすすめします。ご不明点については、ウェブマスター ヘルプ フォーラムでお気軽にお問い合わせください。

Google では常にユーザーのセキュリティを最優先に考え、長年にわたってウェブの安全性の向上やブラウジング体験の改善に取り組んできました。Gmail、Google 検索、YouTube では以前からセキュアな接続を実現しており、昨年は、検索結果での HTTPS URL の掲載順位を若干引き上げる取り組みにも着手しました。ウェブのブラウジングはウェブサイトとユーザーとの間の私的な体験となるべきであり、傍受、中間者攻撃、データ改ざんの対象となってはいけません。Google が「HTTPS everywhere」の推進に取り組んできたのはこのためです。

この流れの一環として、Google は、より多くの HTTPS ページを探すよう、インデックス システムを調整していることをお知らせします。具体的には、HTTP ページに対応する HTTPS ページのクロールを開始します。これは、対応する HTTPS ページがどのページからもリンクされていない場合にも対象となります。同じドメインの 2 つの URL が同じコンテンツを掲載していると思われ、かつ、両者が異なるプロトコル スキームで配信されている場合、通常、以下の条件を満たしていれば HTTPS URL を選択してインデックスに登録します。

• セキュアでない依存関係が含まれていない。
• robots.txt によってクロールがブロックされていない。
• セキュアでない HTTP ページに（または HTTP ページを経由して）ユーザーをリダイレクトしていない。
• HTTP ページへの rel="canonical" リンクが含まれていない。
• noindex robots メタタグが含まれていない。
• 同一ホスト上の HTTP ページヘのリンクが含まれていない。
• サイトマップに HTTPS URL が掲載されている（または URL の HTTP バージョンが掲載されていない）。
• サーバーに有効な TLS 証明書がある。

Google のシステムではデフォルトで HTTPS バージョンが優先されますが、HTTP サイトを HTTPS バージョンにリダイレクトしたり、サーバー上に HSTS ヘッダーを実装することで、他の検索エンジンでも HTTPS バージョンを明示的に優先させることができます。

今回の取り組みにより、ウェブの安全性がさらに高まることを嬉しく思います。Google 検索結果で HTTPS ページを表示することにより、Google では、セキュアでない接続を介してウェブサイトを閲覧してコンテンツ インジェクション攻撃を受けやすくなるリスクを減らしたいと考えています。ご質問やご意見がございましたら、ウェブマスター ヘルプ フォーラムまでお気軽にお問い合わせください。