<script src="https://unpkg.com/budoux/bundle/budoux-ja.min.js"></script>

<budoux-ja>今日は天気です。</budoux-ja>

<!-- Shadow Root -->

<span style="word-break: keep-all; overflow-wrap: anywhere;">今日は<wbr>天気です。</span>

import budoux

parser = budoux.load_default_japanese_parser()

print(parser.parse('今日は天気です。'))  # ['今日は', '天気です。']

import com.google.budoux.Parser;

public class App {

    public static void main(String[] args ){

        Parser parser = Parser.loadDefaultJapaneseParser();

        System.out.println(parser.parse("今日は天気です。"));

        // ["今日は", "天気です。"]

    }

}

Adobe.com での活用ストーリー

ここからは、BudouX をご活用いただいているアドビの Japan R＆D に所属する Software Development Engineer の吉田さんに活用の経緯などをお伺いしました。

どこで BudouX を活用している？

自社のオウンドメディアである adobe.com の日本語サイトにて BudouX を活用しています。適切な改行処理を行うことでデバイスサイズに限らずに読みやすい日本語になるように工夫しています。

BudouX を活用しているページの例

https://www.adobe.com/jp/acrobat/online/ppt-to-pdf.html

https://business.adobe.com/jp/resources/main.html

https://business.adobe.com/jp/customer-success-stories.html

BudouX を活用に至るまでの経緯

実は BudouX 採用前からアドビでは日本語の改行処理に力を入れていました。adobe.com は自社製品の CMS、Adobe Experience Manager 上で構築されていますが、ページを編集する際に区切り文字をマニュアルで入れることで著者が改行ポイントを設定することができました。我々は以前から日本語における適切な改行処理に関心があったというわけです。

話は本題へと移ります。現在 adobe.com は Adobe Experience Manager で構築された従来のサイトから、次世代のアドビの CMS 製品である AEM Franklin をベースにしたサイトへの移行プロジェクトを実施しています。AEM Franklin では Google Docs や Microsoft Word をオーサリング ツールとして活用することができます、また、Adobe Experience Manager で課題であった複雑なシステム構成やウェブサイトのパフォーマンスなどを容易に改善することができる等、新しいコンセプトの製品となっています。

しかし AEM Franklin をベースとした新しい製品を活用したウェブサイトへの移行となったため、今まで存在していた編集時の日本語の改行処理の機能がなくなってしまいました。このような状況の中で、この問題の解決のためにさまざまな手法を検討し、実装コストや運用コストなどを考慮した結果、サーバーサイドで分かち書きなどの前処理するのではなく、クライアントサイドだけで軽量に動作する BudouX がベストだという結論に至り、採用することとなりました。

それでも導入の際には 3 つ課題がありました。1 つ目は BudouX の日本語のデフォルト モデルはアドビのコンテンツを学習していません。特に「お、ご、などの尊敬語に弱い」、「デジタルエクスペリエンスプラットフォームなどの長いカタカナの複合名詞」は精度の面でやや不安があったわけです。そこで新たに adobe.com のデータをスクレイピングし学習させることでよりアドビのサイトにあったモデルを開発することができました。詳しい話はこちらの記事で書かれているので興味がある方はご覧ください。

2 つ目は禁則処理の問題です。禁則処理とは行頭や行末に特定の文字が来ないように文字の並びを調整する処理を指します。例えば、句読点は行頭には来ないようにするなどが挙げられます。BudouX は次の文字の間で区切るべきか否かの二値分類問題を考えています。その結果、かなり低確率ではありますが、周辺文字の状況によって句読点の前で文字が区切られてしまう例がわずかに見られました。我々が普段 HTML で文章を書いているときはブラウザが自動で日本語の禁則処理をしてくれるので問題ありませんが、BudouX では改行ポイントを <wbr> でコントロールしているので、例えば以下の画像のように行頭に疑問符（半角）が来てしまいます。この問題を解決するために、我々はルールベースの禁則処理を BudouX に追加することで禁則処理を実現しました。なお、この問題は現在 BudouX の GitHub にイシューとして登録しています。

3 つ目はウェブサイトのコンテンツの著者の期待通りに改行処理されていない場合にどうするか？ BudouX は高い精度で読みやすい単位に改行処理を行ってくれます。しかし、軽量さやスピードを重視しているので、ときには著者が意図する挙動と違う出力をしてしまうことがありました。また、どれだけ高い精度のモデルを採用したとしても、完全自動では 100% 著者の意図通りの結果を出すことは不可能です。どうしてもコンテンツを運用していく中でここだけは間違えてほしくないという場面は存在するわけです。そこで我々は自動+マニュアルの微調整を可能にすることでこれを解決しました。

幸いなことに AEM Franklin にはオーサリング ツールである Google Docs と Microsoft Word のファイルに対してウェブサイトのページごと、またはすべてのページに細かいメタデータを追加する機能が備わっていました。この機能を活用することで、著者が期待するルールや設定を細かく追加できるようになりました。例えば以下のようなことが可能となっています。

• " ご覧ください " というテキストがあったときに " ご " と " 覧ください " の間では改行できないようにする
• " カスタマージャーニーマップ " というテキストがあったときに " カスタマー " と " ジャーニーマップ " の間で改行できるようにする
• ページの一部分に BudouX を適用しないようにする
• BudouX に渡すパラメータを調整する

この結果 BudouX のスマートな自動改行処理のベネフィットを受けつつ、著者が細かい微調整を加えることを可能にし、理想な運用体制を構築の実現に成功しました。また、現在では移行前の Adobe Experience Manager で管理されているページでも BudouX は活用されており、マニュアルで実施していた改行処理は自動化されています。

BudouX はその軽量さとパフォーマンスが売りです。Lighthouse のスコアへの影響も軽微なもので、adobe.com のパフォーマンス メトリクスをクリアしています。また、最近では finetune が可能になり個別のサイトのコンテンツにあったモデルをより簡単に開発できるようになりました。今後も BudouX の発展に期待しています。 

Before

After

今回は、Maps JavaScript API の読み込み方法に関する 3 つの大きな改善点をご紹介します。3 つの改善点とは、柔軟なライブラリ読み込み用の API、新しいインライン ブートストラップ ローダ、一連のパフォーマンスの向上です。

柔軟なライブラリの読み込み

Maps JavaScript API は、API を読み込むときに開発者が指定して追加できるライブラリで構成されています。これらのライブラリは、ウェブサイト上に地図を表示する以外のことも行います。たとえば、開発者は Places API にアクセスするために、プレイス ライブラリを読み込むことができます。ただし、これらのライブラリの読み込みは柔軟性が低く、これまでは Maps JavaScript API の初期読み込み時にしか指定できなかったため（libraries=places URL パラメータを介するなど）、起動時の読み込みに時間がかかっていました。

そこで、今回、ライブラリを動的にインポートするための API を提供することになりました。たとえば、次のようなものです。

これで、Maps JavaScript API の依存関係を読み込むタイミングをより正確かつ効率的に制御できるようになります。

もう一つの問題は、Maps JavaScript API <script> ローダを使用するには、グローバルに定義された関数に対するコールバック パラメータを定義しなければならないことです。現在、開発者の皆様には、API の読み込みを待たずにすぐに google.maps.importLibrary() を使用できる新しいインライン ブートストラップ ローダの使用をおすすめしています。これにより、面倒なグローバル コールバックを回避し、Promises または async/await を使用して、Maps JavaScript API の準備が完了するタイミングを追跡することもできます。

URL で <script> タグを指定する代わりに、ほんの小さなインライン JavaScript である 新しいインライン ブートストラップ ローダを含めることができます。このコードは構成パラメータを受け取り、ブートストラップ URL を構築して、すぐに使用を開始できるように google.maps.importLibrary() を定義します。最初に google.maps.importLibrary() が呼び出されるまで、Maps JavaScript API のどの部分も読み込まれません。この新しいインライン ブートストラップ ローダはページごとに複数回使用することもできます。なお、最初の構成のみが使用されます。また、新しいローダを使用すると、Maps JavaScript API の読み込み時に問題が発生した場合（古いコールバック メカニズムがではサポートしてされていなかったもの）、google.maps.importLibrary() Promise によって適切に拒否されます。

今年は、エンドユーザーの読み込み時間を自動的に短縮できるように、Maps JavaScript API にもいくつかの変更を加えました。静的 JavaScript ファイルの Brotli 圧縮を有効にし、画面外のマップに対して自動遅延読み込みを導入しました。また、今年の後半には、より新しいコードの出力ができるように JavaScript をアップグレードし、より多くのブラウザの組み込み機能を利用してファイルサイズを削減する予定です。

多くの開発者から、なぜ npm 経由で配布しないのかと質問されることがあります。Google は API にアクセスするためのオプションを定期的に評価しており、ほとんどの JS パッケージが npm 経由で配布されている世界では <script> タグが時代遅れに見える可能性があることを十分に認識しています。

Google が得た重要なインサイトに、Maps JavaScript API を採用している多くのウェブサイト（大小問わず）は積極的にメンテナンスされていないというものがあり、Google はこうしたウェブサイトの機能を維持できるようにできる限りのことを行いたいと考えています。UI レンダリングを構成するコードはかなり複雑で、内部で多数のバックエンド サービスを利用します。長年にわたってブラウザやバックエンド サービスに無数の変更が加えられたため、正しい動作を続けるためには、Maps JavaScript API の内部動作を更新する必要がありました。アクセシビリティ、プライバシー、セキュリティに関する重要な更新もありました。また、各ウェブサイトは API を Google から直接読み込むため、こうした更新をすべて自動的に取得できています。積極的に管理されているウェブサイトであっても、Maps JavaScript API を使用する価値の一つは、この種の変更によって引き起こされる予期せぬ破損の多く（およびその結果として生じる、修正を見つけてデプロイするというストレスのかかる作業）を回避できることです。これは、依存関係の管理に取り組む代わりに、自分自身の目標に集中してより多くの時間を費やすことができることを意味します。

<script> の読み込みと npm との間のギャップを埋められるものを探している開発者のために、Google Maps Platform は @googlemaps/js-api-loader パッケージを提供しています。新しい google.maps.importLibrary() は、Loader.importLibrary() を介して js-api-loader とともに使用することもできます。

また、Maps JavaScript API の新しいリリースを採用する時期をより細かくコントロールしたいと考えている開発者の方は、利用可能なオプションをご確認ください。Maps JavaScript API の各バージョンは、1 年間利用することができます。

Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。

Posted by 丸山 智康 (Tomoyasu Maruyama) - Developer Relations Engineer

大気質と花粉のデータを使用して環境の変化を理解し、個人的な行動を促す

Air Quality API と Pollen API を使用すると、企業は気候変動と環境の変化についての理解を深めることができます。これにより、情報に基づいた選択や、改革の推奨、影響を軽減するための革新的なエクスペリエンスの構築に必要な情報が得られます。また、この情報を利用して、ユーザーがより多くの情報に基づいた意思決定を行えるようにすることもできます。

Air Quality API

Air Quality API を使用すると、企業は信頼性の高い大気質データにアクセスして、ヒートマップで汚染を可視化できます。また、汚染物質の詳細情報と推奨される対策を対象ユーザーに提供することもできます。

ニューヨーク市の現在の大気質の状態を、詳細な汚染物質とともに示した地図

大気汚染の高い流動性を考慮するため、Google は、政府の観測所、低コストのセンサー、気象データ、衛星、土地被覆、リアルタイムの交通情報など、複数のデータソースからの情報を組み合わせています。この手法では、1 つのデータソースが利用できなくなった場合でも情報を収集できます。Google は、毎時数テラバイトのデータを検証、整理し、地域に固有の信頼性の高い大気質情報を提供します。Air Quality API の詳細については、お知らせのブログ投稿をご覧ください。

Pollen API

Pollen API では、世界中の最も一般的なアレルゲンに関する最新の花粉情報にアクセスできます。Pollen API を使用することで、アレルギーの原因となる花粉にさらされるリスクを抑え、情報に基づいた意思決定を毎日適切に行えるようになります。また、気候が変化するなかで、より長く厳しくなるアレルギーの季節に適応できるようになります。この API は、局所的な花粉の飛散数や植物アレルゲンに関する詳細情報を提供します。ヒートマップによる可視化ができるほか、アレルギー患者が花粉への曝露を最小限にするための実用的なヒントも得られます。花粉と気候の関係を研究している組織や、ユーザーがより健康的な意思決定を行えるように支援したいと考えている企業は、データに基づいた分析情報が得られます。

花粉飛散量と植物アレルゲンに関する詳細情報を示すヒートマップによる可視化

Pollen API は、世界 65 か国以上の 1 平方キロメートル グリッドにおける花粉の季節性と 1 日あたりの量を計算するモデルを利用しています。また、最大 5 日間の予測、3 種類の植物、15 種類の植物種に対応します。このモデルは、土地被覆、気候データ、植物ごとの年間花粉生成量などのさまざまな入力情報を使用して、地域の花粉飛散量と曝露リスクに関する信頼性の高い予測値を提示します。Pollen API の詳細については、お知らせのブログ投稿をご覧ください。

Google Maps Platform を通じて、環境に関するその他の情報をデベロッパーに提供します。Google は、新しい環境データや、Photorealistic 3D Tiles（間もなくプレビュー版に移行）や Aerial View（一般提供中）などの臨場感あふれるエクスペリエンスを提供するプロダクトへのアクセスを可能にすることで、気候変動に対する革新的なソリューションをサポートする役割を果たしていきたいと考えています。環境データを 3D 画像に重ねて大気質や花粉の飛散量を可視化することは、これらのプロダクトが連携できる方法の一つにすぎません。皆で協力することで、より健康な地球への道を描くことができます。

Google の新しい Environment API 群の詳細については、8 月 30 日の午前 11 時から 11 時 45 分（米国太平洋夏時間）に行われた「Google Maps Platform の新機能」のセッションでもご覧いただけます。

Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。