Google 検索におけるコンテンツのプレビューをもっと制御できるようになります

Google では、文字形式のスニペットを始めとする様々な形式のコンテンツをプレビューとして検索結果に表示していますが、これは、検索結果と検索クエリとの間に関連性があるかどうかを、ユーザーが判断しやすくすることを目的としています。どのような形式のプレビューが表示されるかは数多くの要因によって決められており、その要因の中には、ユーザーが探しているコンテンツの形式や、そのときに使用しているデバイスなどが含まれます。

例えば、Google でレシピの検索を行っているユーザーには、サムネイル画像やレビュー スコアが表示されます。なぜなら、何を食べたいか決める際は、文字形式のスニペットよりも、そういった情報のほうが参考になると考えられるからです。上記のような形式の情報は、パブリッシャーが構造化データを使ってページを作成しているおかげで表示が可能になっています。

Google は、表示された検索結果がユーザーのクエリと関連性が高く訪問したくなるサイトが表示されていることを分かりやすく示すために、プレビューを自動的に生成します。一方で、サイト オーナー側でも、プレビューで表示される情報をある程度調整したいという要望があることを私たちも理解しています。そこで本日は、ウェブマスターが行える新たな設定項目をいくつかご紹介します。これらの設定により、スニペットに表示する文字列はどの部分からどのくらいの長さであるべきか、その他の形式の情報はプレビューに表示するべきかどうか、などをそれぞれのサイトが簡単に定義できるようになります。

スニペットとコンテンツ プレビューの設定を Google に知らせる

これまでは、文字形式のスニペットの表示を許可するかどうかのみが設定可能でした。今回紹介する方法を使用することで、検索結果のページに対して表示されるプレビュー コンテンツを、より細かく設定できるようになります。その方法は、二種類の新しい設定を駆使して行います。その二種類とは、robots メタタグによる設定と、HTML 属性による設定です。

robots メタタグを使用する

robots メタタグは HTML ページの <head> 要素内に追加するか、x-robots-tag HTTP ヘッダー で指定します。ページのプレビュー コンテンツの設定で使用する robots メタタグは、以下の通りです。

  • "nosnippet"
    既存の設定値です。ページに対して文字形式のスニペットを表示したくないときに使用します。
  • "max-snippet:[number]"
    新しい設定値です!ページに対して表示するスニペットの最大文字数を設定します。
  • "max-video-preview:[number]"
    新しい設定値です!動画再生プレビューの最長再生時間(秒)を設定します。
  • "max-image-preview:[setting]"
    新しい設定値です!ページ内の画像がプレビューで表示されるときの最大サイズを指定します。指定可能な設定値は、"none"、 "standard"、 "large" のいずれかです。

上記のメタタグは 2019 年 10 月 より有効になります。設定値は以下のようにまとめて記述することが可能です。

例:

<meta name="robots" content="max-snippet:50, max-image-preview:large">

新しい data-nosnippet HTML 属性を使用する

"data-nosnippet" HTML 属性は、ページ内のコンテンツのうち、スニペットとして表示してよい部分を制限するのに役立つ新しい方法です。span、div、section 要素で使用出来ます。"data-nosnippet" HTML 属性が指定された要素は、そのページに対する文字形式のスニペットとして表示されなくなります。

例:

<p><span data-nosnippet>Harry Houdini</span> is undoubtedly the most famous magician ever to live.</p>

"data-nosnippet" HTML 属性は今年中に有効になります。詳しくは、robots メタタグと X-Robots-Tag HTTP ヘッダーの仕様に関する開発者ドキュメントを参照してください。

リッチリザルトと強調スニペットについて

構造化データ内のコンテンツは、検索結果におけるリッチリザルトとして表示することが可能です。リッチリザルトは、上記のメタ robots による設定で制限することは出来ませんが、構造化データ内のコンテンツ自体を制限したり修正したりすることで、より柔軟な設定が可能になります。例えば、レシピが構造化データに含まれている場合、その構造化データのコンテンツは、検索結果のうち、レシピのカルーセル内に表示されることがあります。そのような表示を制限するために、パブリッシャーは構造化データ内のコンテンツの量や形式を制限することが出来ます。

検索の特別な機能の中には、プレビュー コンテンツが利用可能な場合のみ動作可能になるものがあります。つまり、プレビューを制限することで、それらの特別な機能の領域でコンテンツが使用されるのを防ぐことが出来ます。例えば、強調スニペットは表示するのに必要な最低文字数があり、それに満たない場合は表示されません。しかしながら、これは言語によって様々なので、強調スニペットで確実に表示されるための具体的な max-snippets の値は存在しません。強調スニペットとしてコンテンツを表示したくない場合は、 max-snippets の値を小さくしてみてください。強調スニペットから確実にオプトアウトしたい場合は、nosnippet を指定してください。

AMP フォーマット

AMP フォーマットには確実なメリットがあります。例えば、検索結果Google Discover のフィード画面で、より多くの注目を集めるような形でサムネイル画像を表示することが可能になります。このような特徴により、パブリッシャーはさらに多くのトラフィックを記事ページに誘導できるようになりました。一方で、パブリッシャーの中には、AMP ページが検索や Discover で表示された際に、大きいサムネイル画像を表示してほしくない場合があるかもしれません。その場合は、上記の meta robots タグのうち、max-image-preview に対して “standard” か “none” を指定します。

本日ご紹介した新しい方法は、世界中のコンテンツ所有者の皆様が利用でき、全世界どこでも同じように機能し検索結果に反映されます。Google 検索におけるサイトの価値を最適化し、ビジネスの目標を達成するうえで、今回の方法が皆様のお役に立つことを願っています。さらに詳しい情報は、メタタグに関する開発者ドキュメントを御覧ください。ご質問がある場合は、私たちにお知らせいただくか、ウェブマスター ヘルプ フォーラムまでお越しください。

モバイル ファースト インデックスに向けて、構造化データと画像の代替テキストをお忘れなく!

「モバイル ファースト インデックス」の取り組みについて最初にお知らせしてから 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 はこの変更を慎重に確認して評価し続けます。ご不明な点がございましたら、ウェブマスター フォーラムまたはイベントでご質問ください。

Google 画像検索の参照元 URL の変更について

Google 画像検索を使って日々ウェブ上のコンテンツを視覚的に探索するユーザーはかなりの数に上ります。次に焼くクッキーのアイデア、視覚的にわかりやすいタイヤ交換の手順など、ときおりテキスト検索より画像検索のほうがずっと役立つ場合があります。

参照元 URL の変更

これまで、サイトへのトラフィックのうち Google 画像検索がどれだけ貢献しているかを把握するのは簡単ではありませんでした。そこで Google では、Google 画像検索専用の新しいリファラー URL を導入し、これから数か月かけて順次ロールアウトしていくことにしました。リファラー URL とは HTTP ヘッダーの一部で、これを見るとユーザーが 1 つ前にいたページ(目的のウェブページを訪れるためにクリックしたページ)がわかります。

ウェブサイトへのトラフィックの追跡や分析を行うソフトウェアを開発している場合は、ぜひこの変更にご対応いただければと思います。新しいリファラー URL を取り入れて、Google 画像検索からのトラフィックを識別できるようにしてください。新しいリファラー URL は https://images.google.com です。

サイトデータを Google アナリティクスで追跡している場合は、特に対処の必要はありません。新しいリファラー URL が自動的に適用され、Google 画像検索からのトラフィックを正しく識別できるようになります。なお、この変更は Search Console には影響しません。サイトへのトラフィックに貢献している上位検索クエリの集計リストは、これまでどおりご利用いただけます。

国別のクエリへの影響

新しいリファラー URL には、Google 画像検索で使用する URL と同じ国別コード トップレベル ドメイン(ccTLD)が含まれています。つまり、世界中のほとんどのユーザーは images.google.com からのアクセスとなります。昨年実施した変更(英語)で、世界中のユーザーが検索するとき、デフォルトで google.com が選択されるようにしたのはそのためです。ただし、一部のユーザーは引き続き、国別のサービス(日本なら google.co.jp)に直接アクセスしている可能性があります。その場合は、その国の TLD(たとえば images.google.co.jp)が使用されます。

この変更により、ウェブ上の視覚的なコンテンツがさらに充実することを願っております。ウェブページを Google 画像検索に最適化する方法については、画像公開に関する Google のガイドラインをご覧ください。ご質問、ご意見、ご提案などございましたら、ウェブマスター  ヘルプ フォーラムからお寄せください。

”詐欺写真”を見分けるアプリTruepic――開発元が175万ドル調達

「これって本当に写真の通りなの?」「私たちが借りようとしている家の写真って加工されてない?」「これは本当に自分が買おうとしてるものが写った写真なの? それともどこかの画像を流用したもの?」――このような質問に応えようとしているのが、写真認証テクノロジーを開発しているTruepicだ。本日同社は、コンシューマー向けのアプリと共に、Truepicの技術を利用したいと考えている企業のためのSDKを発表した。さらに175万ドルの資金調達についても明らかにしたTruepicは、「世界初のデジタル写真の公証人」になろうとしている。

Truepicの仕組みは次の通りだ。まずユーザーは、iOSAndroidの両OSに対応したTruepicのアプリか、TruepicのSDKが埋め込まれたサードパーティーのアプリを使って写真(もしくは動画)を撮る。すると特許取得済みのTruepicのテクノロジーが、撮影した画像に加工が施されていないかを確認し、タイムスタンプやジオコードをはじめとするメタデータと透かしを写真に追加する。オリジナルの写真はTruepicのサーバー上にアップされ、そのときに生成される6桁のコードとURLを使って元の写真を回収することもできる。さらに必要に応じてブロックチェーン技術を使い、写真データを複製することも可能だ。

その後ユーザーは、透かしが追加されたTruepic認証済みの写真を自由に使うことができ、写真を見た人は画像に埋め込まれたURLを辿ってTruepicのデータベースを確認することもできる。Tinderのようなデーティングサイトで、ユーザーがプロフィール写真に写っているのは自分であることを証明するために使ったり、Airbnbのようなサービス上で物件情報に信頼性を持たせたり、eBayのようなECサイトで、商品の状態を見せたり、保険を請求する際にダメージの状態を見せたりと、Truepicのサービスにはさまざまなユースケースが考えられる。

企業は月々の料金を支払えば、Truepicの軽量なエンタープライズ向けSDKをアプリ内に組み込み、写真撮影、認証、共有という全ての機能を自分たちのアプリ上で提供できるようになる。現在同社は10数社のベータ顧客にSDKを提供しており、Fortune 500の保険会社から大手美容ブランドまで顧客企業の分野はさまざまだ。まだAirbnbやTinderはTruepicを採用していないが、すでに両サービスのユーザーは同社の認証した写真をアップロードし始めているため、彼らもTruepicのSDKをうまく活用できるかもしれない。

「オンライン上の情報は簡単に改ざんできるようになり、自然さや現実感よりも完璧なものを求める考え方が広まってきました」とTruepicの共同ファウンダーでCOOのCraig Stackは語る。PhotoshopやInstagram、Snapchat、FaceTune、Meituなどの登場もあり、画像加工はもはや普通のことだ。「企業がインターネット上に溢れる手の加えられた画像への対策を欲している一方、消費者は他の人が本物だと信じられるような認証済みの写真を共有したいと考えています」とStackは説明する。「これこそTruepicの存在する理由です。私たちはアンチフィルター企業なんです」

以前Stackは、複数の保険会社に加え、後にTripAdvisorに買収されることになる、Flipkeyという別荘貸し出しサービスを提供するスタートアップに投資していた。そこでの経験から加工された画像の問題点に気づいた彼は、Truepicを設立することになる。設立にあたってStackは、Dashというペイメント企業を立ち上げてReserveに売却したJeff McGregorをCEOに迎えた。

そしてふたりは、FirstCallのファウンダーでThomson FinancialのCEOを務めたこともあるJeffrey Parkeや、Platinum TechnologyやHRスタートアップのSilkRoadを立ち上げたAndrew Flilpowski、ハーバードビジネススクールの教授でベンチャーキャピタリストでもあるWilliam Sahlmanが参加したシードラウンドで175万ドルを調達した。この資金は今後の売上の伸び具合も勘案しながら、人員増強やエンタープライズ向けSDKの正式ローンチにむけて使われる予定だ。

Truepic以外にも類似サービスを提供する企業は存在するが、既存のサービスは写真加工が一般に広まる前の早過ぎる段階で事業をスタートさせてしまったとMcGregorは考えている。Image EditedFotoForensicsImgOpsといったアプリでも、画像が修正されているかや、ウェブ上に同じ画像が公開されているかといったチェックができるが、基本的な機能しか揃っていない。

大企業は自社で画像認証システムを開発できるだろうし、実際にそうしている企業も存在するが、McGregorによれば「何か問題があったときに自分たちで全責任を負わず、どこか独立した組織に画像認証の責務を負わせることができるという意味で、『自分のケツは自分で拭く』Truepicのサプライヤーとしての側面を気に入っている企業」もいるという。月々の料金を払って、あとは専門家にお任せする方が良いと考えている企業もいるということだ。

もしもTruepicのコンシューマー向けアプリを使ったユーザーが、以前よりも多くの相手とデートできるようになったり、マーケットプレイスでの売上やレンタル回数が以前よりもあがったりということになれば、Truepicの透かしがバイラル化を保証する印のような存在になるかもしれない。法人顧客であれば、自社のサイトに透かし付きの画像を使って信頼度を向上させたり、ウェブサービスのプレミアムユーザー用の機能としてTruepicのテクノロジーを活用することもできる。

画像編集の盛り上がりは既に頂上を越えたと思っている人がいれば、ARが一般に広まるまでその考えを留めておいた方がいいだろう。既にSnapchatのフィルター機能では、肌を滑らかにしたり、自動的に写っている人を美しく見せたりすることができる。さらにAR技術が進めば、Photoshopを使ったことがない人でもプロ並みの偽造写真を作れるようになるかもしれないのだ。画像の編集は単純に楽しいものだが、ビジネスの妨げや詐欺、なりすましに繋がる可能性もある。しかしTruepicを使えば、本当の写真(true pics)と偽物を見分けられるようになるだろう。

原文へ

(翻訳:Atsushi Yukutake/ Twitter

似顔絵から写真を再現、オランダの研究チームが逆発想のソフトウェアを開発

algo-photos

スマートフォンで撮影した写真を絵画調のアート作品へと加工するアプリ「Prisma」を愛用している人は多いだろう。しかしその逆のプロセス、つまりアート作品を写真へと変換させることも同様に面白い。そして、そんな逆発想のテクノロジーの実現はそう遠くないと、オランダの研究者たちは断言する。

オランダ、ラドバウド大学の4名の神経科学者は、ディープ・ニューラル・ネットワーク(深層神経回路網)を利用し、似顔絵を写真のようにリアルな顔の画像に転換するモデルに取り組んでいる。この研究(Convolutional Sketch Inversion)の結果は、最初にオンラインアーカイブ「arXiv」にて公表された。10月にアムステルダムで開催予定の「European Conference on Computer Vision」にも先日受理されている。

科学者達によると、このモデルは様々な形で応用が期待できるという。例えば、芸術分野で似顔絵を写真に近い形に変えたり、あるいは科学捜査で、目撃者の情報をもとに書いた犯人の似顔絵を、画像認識ソフトで検知可能なデータにするといったことなどだ。

「最近発表された、ニューラルスタイル変換(neural style transfer)という、写真をアート作品へと変換するアルゴリズムの研究に触発されました」と、29歳のYağmur Güçlütürkと30歳のUmut GüçlüはTechCrunchへのメールに書いた。認知神経科学の博士課程学生である二人は、Marcel van GervenとRob van Lierと共に今回の研究を行った。

VanGogh-shutterstock

GüçlütürkとGüçlüが参考にした論文には、ドイツの街テュービンゲンを、フィンセント・ヴァン・ゴッホの名作「星月夜」の絵画スタイルで再現するテクニックが記されていた。「これを読んだ時、逆の場合はどうなのかと考え始めました。つまり、このフィンセント・ヴァン・ゴッホの作品を写真にするとどうなるか、ということです」とGüçlütürkとGüçlüは書く。

GüçlütürkとGüçlüによると、人工神経回路網を利用した独自のソフトウェアは以下のように機能する:

「例えば、科学者である私が、人工神経回路網であるあなたに、スケッチ(インプット)を写真(アウトプット)に変換する方法を教えたいとしましょう。まず、スケッチと写真のペアを取り込んだ膨大なデータセットを構築します。そしてあなたにスケッチのみを渡し、写真に変換するよう依頼します。あなたは適当に1つ戦略を考え、写真を再現します。初めのうちは、作成した写真とデータセットの写真はかけ離れています。私は、あなたが描いた写真とデータセットの写真を比べ、間違いを指摘します。そのフィードバックをもとに、あなたは戦略を変え、改めて写真を作り直します。すると徐々に、写真のクオリティが高まっていくのです」。

Examples of the synthesized inverse sketches from the LFW dataset. First image in each column is the ground truth, the second image is the generated sketch and the third one is the synthesized inverse sketch. (Source: "Convolutional Sketch Inversion" Study)

LFWデータセットから合成した似顔絵の例。最初の列が本物、2番目が生成されたスケッチ、そして3番目の列がスケッチから合成した顔写真。(論文「Convolutuonal Sketch Inversion」より)

今回、スケッチと写真を一致させるモデルの習得プロセスにおいて、反復学習がとても重要な役割を果たした(これは神経回路網を訓練させるスタンダードな方法でもある)。

「この最後の2つのステップを何度も繰り返します」とGüçlütürkとGüçlüは書く。「最終的に、合成した写真はデータセットの写真と似てきます。上手くいけば、習得した新たなスキルを使って、すでに見たことのあるスケッチだけでなく、まだ見たことがないスケッチでも素早く高画質な写真へと変換することが可能になるのです」。

このアルゴリズムの訓練とテストを実施するため、研究者達はまずウェブ上で公開されているデータをもとに似顔絵をコンピューターで生成した。使用したのは、CelebAにある20万枚以上の芸能人の写真が保管されたデータセットと1万3000枚の顔写真が保管されているLFWデータセットだ。さらに、手描きのスケッチをCUFSデータセットから入手した。

2人の博士課程の学生がまず始めに試したのは、Güçlütürkが描いた彼ら自身の似顔絵を変換することだった。さらに、このアルゴリズムを使うことで、2人は有名なオランダ人アーティスト3人(レンブラント、ヴァン・ゴッホ、エッシャー)の自画像をもとに、写真のようにリアルな顔の画像を構築することを試みた。

Self-portrait sketches and synthesized inverse sketches along with a reference painting or photograph of famous Dutch artists: Rembrandt (top), Vincent van Gogh (middle) and M. C. Escher (bottom). (Source: "Convolutional Sketch Inversion" Study)

左の列から有名オランダ人アーティストの自画像、スケッチから合成した顔写真、参考写真又は絵。レムブラント(上)、フィンセント・ヴァン・ゴッホ(真ん中)、M. C. エッシャー(下)(論文「Convolutional Sketch Inversion」より)

彼らは現在、この成果を市場に投入する方法を探している。芸術や科学捜査などの領域での収益化を目指している。

「今回の研究からスピンオフして設立した会社Neurantは、そういったアプリケーションの開発をすでに行っています。近いうちに市場に参入したい考えです」とGüçlütürkとGüçlüは締めくくった。

[原文へ]

(翻訳:Tomoya Mori)