「TensorFlow」をはじめとするAIフレームワークや、Pythonで提供されている多くのライブラリにより、AIサービス制作・参入ハードルが下がっている。一方で、こうしたサービスを使わずに、あえて「必要なツールはほぼ自作」という選択をしているのがウェザーニューズだ。
同社のAIイノベーションセンターに所属するエンジニアの萩行正嗣（はんぎょう・まさつぐ）さんに、気象サービスでのAI活用事例と、「ユーザーと開発者のどちらの幸せも追い求める」開発哲学を伺った。
AIを使い、気象情報を早く正確に伝える
――まず、どのようなサービスでAIを活用されているのか教えてください。
私たちは特定のサービスだけにAIを使っているわけではありません。ウェザーニューズが提供するサービスはいずれも「気象情報を正確に伝える」ためのもの。天気予報自体にAIが活用されているので、すべてのサービスにAIが使われていると言っても過言ではありません。
個別のサービスにもAIを活用している事例が多くあり、たとえば天気予報番組のニュース原稿作成を支援するシステムでは自然言語処理を活用しています。
これはテレビ局向けに提供している天気予報のデータを読み込み、AIでニュース原稿の候補を100から最大1万程度作成したのち、実際に使えそうな原稿の候補を自動で10個までに絞る、というもの。天気予報番組の原稿を作るライターは提示された10個の候補から1つを選び、テレビ局へ送付しています。
数値のミスを防ぐだけでなく、気温が0度を下回ったときに「マイナス」「氷点下」のどちらの表現を使うのか、といったテレビ局ごとの決まりもAIに学習させ、ライターの負担を減らしています。
ウェザーニューズには、こうしたメディアへの配信やユーザー向けアプリ以外に、より細かな気象情報を企業に発信するサービスもあります。
たとえば自治体の方など、避難勧告を出して防災・減災に取り組んでいらっしゃる方には、単純な気象予報よりも「近くで崖崩れが起きた」などの情報のほうが重要ですよね。こうした方々の「自分の自治体で今何が起こっているのか、住民はどのように感じているのかを知りたい」というニーズに応えるのが、リアルな気象情報を伝える「住民の声」です。
ウェザーリポート（気象情報）には、自治体の住民からさまざまな災害情報が寄せられます。過去のリポートのコメントと、選択式の天気報告（パラパラ、ゴォーなどをわかりやすい擬音語をユーザーが選択して送付）の関係をAIで学習し、キーワードと気象災害との関連を算出。直近のリポートにAIを使って、自治体担当者が意志決定しやすいよう、AIが担当者にとって「重要なリポート」を自動的に判断し提示したり、住民から寄せられたリポートをもとに危険度をAIで計算し、閾値を越えたときにアラートを飛ばしたりと、避難情報の発令などの参考にしていただいています。
このように、よりお客さまのニーズに沿った情報を提供できるよう、私が所属するAIイノベーションセンターのエンジニアは日々サービスを研鑽しています。
萩行正嗣さん
2008年、京都大学工学部電気電子工学科卒業。 14年、同大大学院情報学研究科知能情報学専攻博士後期課程修了。黒橋・河原研究室で博士（情報学） 取得。同年4月、株式会社ウェザーニューズ入社。AIイノベーションセンター【※】に所属し、自然言語処理、機械学習を活用した業務改善、新価値創 造に取り組む一方、機械学習技術の気象分野への応用に挑戦中。
※ 2013年ウェザーニューズ社内で設立。AIを使った新しいサービスの開発や既存サービスの高速化・半自動化を推進している。併せて、機械学習の専門家として社内開発チームへの助言も手がける。萩行さんいわく「他社さんでいうテックリードに近い役割」とのこと
なぜ、あえてPerlを使うのか？
――機械学習のフレームワークに、Pythonほどツールやエコシステムが充実していないPerlを使われていると聞いて「珍しいな」と思いました。実際の仕組みを教えていただけますか。
先ほどお話した「天気原稿生成」や「災害関連リポート提示・アラート」は機械学習部分も含めて完全にPerlで実装されています。
気象データ「ウェザーリポート」はまとめてSQLサーバに保存され、このデータはウェザーニューズのすべての気象サービスで共有されています。
本文（バイト列）、エンコーディング情報、時間、場所などがリポート情報保存用SQL DBに記録される
PerlとPythonのいいとこ取りをして活用している自社サービスが、二次災害を防ぐための最新情報を提供する「リアルタイム冠水」。Perlで前処理をしたのちPythonの機械学習にかけ、冠水情報を生成しています。
Perlで実装されたリポート取得・正規化APIをコンテナ技術（Docker）で立ち上げ、Perlで正規化処理をした後、APIを叩いてリポート情報を取得。取得したデータをPythonで自然言語処理をしています。
――なぜPerlだったのでしょうか？
PythonのAIエコシステムが充実するなか、「AIでPerlを使っている」というと不思議なイメージを持たれると思うのですが、Perlの正規表現検索では日本語のUnicodeブロックが使えますし、自然言語処理や文字列処理ではPerlが他の言語よりも優れていると言えます。
現在稼働しているサービスとの親和性の高さも、理由の1つです。「ウェザーリポート」は古くからあるサービスで、当時の主流言語はPerlでした。サービスが拡大したのもその頃なので、いわゆるガラケー時代のデータも蓄積されています。ガラケーの文字コード処理や絵文字処理にPerlを使っていたこともあり、当時作成したライブラリは今でも利用できるのです。もしガラケー対応などの文字コード正規化処理をPythonで再実装するとなると、開発コストに見合いません。
一方で、数値予測のシミュレーションなどには、PerlよりもPythonの機械学習ライブラリが向いています。そのため判定や数値予測をPythonで担い、アプリケーションに合わせて出力しています。
「ウェザーリポート」に投稿された画像をもとに、減災に役立つ情報を検出する
PythonのライブラリであるMeCabを使えば、形態素解析（生成された文章を単語に区切り、品詞分解する）も不可能ではありません。しかし、Pythonの正規表現では、ひらがなやカタカナはネイティブサポートされていない。自然言語処理に強いPerlを使ったほうがいいと判断し、現在に至ります。
――機械学習というとPythonに目が向きがちですが、Perlと併用されているのですね。
私たちの提供する多くの気象予報サービスは、「気象データを受け渡して、さまざまなサービスにあった形で発信する」というマイクロサービスアーキテクチャ【※】に近い構造をとっています。なので、サーバー単位で切り分け、フロントエンドに近い部分でPerlが使えそうな所は活用していく、という仕組みになっています。
※複数の小さなサービスを組み合わせて、1つのアプリケーションを作る設計手法。各サービスが独立し、管理しやすくなる（メンテナンス時にサービス全体の挙動を考えなくて良いため、管理コストが下がる）というメリットがある
Perl自体も進化していますし、慣れた言語で自作のライブラリやフレームワークを作るのはそう難しくありません。自社での開発効率を上げるためにフレームワークを作るので、自分たちの習熟度が高い言語を使ったほうがいい。一方で、数値計算や機械学習の高速化などをフルスクラッチで作ろうとすると、手間も時間もかかってしまうでしょう。そういうときは、OSSなど外部にあるものを選んで使うようにしています。
フレームワークを作る大変さは人によって意見が分かれるところですが、個人的にはフレームワークを作れてこそ一人前のソフトウエアエンジニアだと思います。
ウェブサービスなどでは、「決まりきった」既存のアーキテクチャやパターンを無理矢理にでも自社サービスに当てはめているという話も聞きます。果たしてそれで、ユーザーに提供したい価値や体験が本当にユーザーの元に届いているか疑問なところです。当社ではサービスをただ動かすだけでなく、「ユーザーに提供したい価値は何か」を突き詰め、最適な技術を選んでいます。
コア部分は自作にこだわり、確実にユーザーへデータを届ける
――とはいえ独自の技術を使われていると、採用でのハードルが高くなるなどのデメリットもあるのでは。
採用訴求力よりも学習コストがかかってしまう、という問題はあると思います。
ただ、当社は気象予報に基づくサービスをお客様に売っている企業です。自社で作ったサービスを「売る」企業として、フレームワークを自社で開発して個々のサービス開発スピードを上げたり、インフラも自分たちで開発して運用したりするのは必要コストだと考えています。
外部のAPIを実行するサービスを利用すると、仕様変更があったときに、お客さまにサービスを提供できなくなってしまう可能性があります。たとえば、外部の機械学習サービスを使うと自社での開発コストが少なくなる反面、「学習器【※】がどのようなアルゴリズムによって学習しているのか」はユーザーからは見えません。
※ 入力された学習用データから、規則性を見いだして出力する装置
このように、ブラックボックス化した技術をサービスの中心部に埋め込まず、データを確実にお客さまに届ける仕組みを自分たちで作り、「コア技術」として自社で持つようにしています。なので、気象データの見せ方や編集ツールといった、特に直接お客さまの目に触れる部分は基本的に自作しています。
こうしたコア技術を自社で持っていれば、外部の環境変化に振り回されずサービス自体が継続できるほか、世の中と違うことをやるときにすぐに取り組めるというメリットもあります。
最適な技術を選んでいたら「世の中の先」を行っていた
――マイクロサービスアーキテクチャのお話が出ましたが、これからトレンドになりそうな分野や、新しい技術情報をどのようにキャッチアップされているのですか？
もちろん、開発者として新しい技術やサービスに触れてみることもあります。新しい技術を取り入れるというよりは、ユーザーの声や要望を聞いて問題を解決しようと考えた結果、自然と最適解を選んでいたというパターンが多いです。
たとえばユーザー参加型企画の1つとして、弊社が独自開発した花粉観測ロボット「ポールンロボ」をIoT化したのは、今から10年以上前のこと。2005年に完成した初号機は、観測機に表示された数字をユーザーが手入力して送信するというものでした。
左から2番目がIoTを搭載した2代目ポールンロボ
「手入力は面倒だから、測定結果をインターネット経由で送信できたらいいな」と改良を進め、2006年には有線LANを搭載した2代目をリリースしました。今でこそ時流に乗って「IoTやっています」と言うこともありますが、2代目が世に出た頃は時代を先取りしすぎて、現在のように騒がれてはいなかった。
自分たちで先行的にやっていたら、世の中が後からついてきた、という感じです。日本で初めて商用として打ち上げた宇宙衛星も、ポールンロボの改良と同じように「ユーザーの要望に応えたい」という思いからプロジェクトが始まりました。「北極海航路を行く船舶向けの気象サービスを始めたい」「でも北極海の氷を観測している企業はいないよね」「じゃあうちで衛星上げればいいんじゃない？」という流れですね（笑）
新しいサービスは「儲かるか」より「誰が幸せになれるのか」
――既存サービスの運営だけでなく、新しい事業にもチャレンジできる環境なんですね。研究開発をサポートする制度があるんですか？
独自の制度はないものの、新しいサービスをリリースする機会が多く、挑戦しやすい環境ではあると思います。当社が関わっている業界の数は44にのぼり、かつそれぞれに複数のサービスがあります。既存サービスの形にとらわれ、それらの機能拡張やシナジーだけを考えていては、なかなか新たなチャレンジはできませんよね。
5年後、10年後を見越したサービスを支えるのに必要なチャレンジは、社員誰でも提案ができて会社も投資をしていく、という風土があります。逆に言うと「新サービスによって何ができるようになり、誰が幸せになるのか」を常に考え、提案することは社内ですごく求められる部分です。
ウェザーニューズでは短期的なコストよりも、いかに多くの人が幸せになれるサービスを提供できるかを重んじています。
「How muchよりもHow wonderful！」という社是があり、新しいサービス・インフラを提案することをHow wonderful提案と呼んでいます。一般的には「いくら利益が出るのか、投資を回収できるか」という投資提案が重要視されがちなもの。しかし当社では、そのサービス・インフラを提供することによって「どんな素晴らしい価値が生まれ、それがどのような人たちの役に立つのか」を重要視しています。新しく生まれたサービスが「素晴らしい！」と市場に共感されるものであれば、時間がかかったとしても、サービスの利益につながるからです。
弊社のサービスには「How wonderful！」に共感してくださるビジネス・パートナーと共にチャレンジして創られてきた歴史があり、これは現在まで受け継がれています。
そうした企業方針もあり、ビジネスに直接関わるデータや個人情報などを除いて、社内の気象データにはエンジニアがある程度自由にアクセスできます。日々の予報精度を上げるためにデータを調べてみた結果、サービス改良につながったり、個人で開発したものがサービスの大元を支えるインフラとして使われたりすることも少なくありません。
――個人開発の延長上ってすごいですね。エンジニアにとって、非常に魅力的な環境ではないでしょうか。
エンジニア個人の裁量でマシンや開発環境が決められるので、そこは自由度が高いと感じます。見合う価値が出せればという条件つきではありますが、ハイスペック機の導入を咎める人はいません。
いわゆる大企業の「研究開発」というと、サービスから離れた場所にいるようなイメージを持たれる方もいるでしょう。しかし、会社の規模が800人強とそれほど大きくないため、ビジネスサイドやユーザーの声を聞きながら研究開発に取り組めます。日頃から「このサービスはこういう切り口なら売れそうだ」といった提案もしやすいですね。
新しい技術を追うことだけに固執してはいけない
――ユーザーの声を拾い、かつ将来のサービス成長も考えられた上で、うまく技術を選ばれていたんですね。
そうですね。社内ではPerlメインで開発をしつつ、必要に応じて新しい技術や知識をキャッチアップしていく、という感じです。Perlはレガシーコードで汚いと思われがちですが、きれいに書かれたPerlは悪くないですよ（笑）
「PerlでAI」というと不思議なイメージを持たれると思いますが、プログラミング言語の流行は常に変わっていくもの。流行の言語に軽く触れるだけの人より、1つの言語について深く詳しく知っている人のほうが、まったく違う言語にも適応できるでしょう。
とはいえ「新しい技術を全然知らない」のも問題ではあります。ただ単純に流行を追うだけでなく、その技術の本質を知り、いかに活用するとユーザーにとってうれしいのかまで理解を深めることが大切なのではないでしょうか。「仕組みはよくわからないけど、ディープラーニングっていうのがすごいらしいからやっている」という話をたまに聞きますが、ちょっとズレているなと思います。
――最後に、今後の展望を教えてください。
私が入社した当時のAIイノベーションセンターは、まだ役割もはっきりしておらず、手探り状態でのチャレンジでした。今は、AIイノベーションセンターと私個人、それぞれで取り組んでいきたいことがあります。
AIイノベーションセンターでは、既存のサービスの精度向上・高速化から一段上のレイヤーとして、人力で行う業務の自動化を目指しています。そして、私自身はAIイノベーションセンターの業務に携わりつつ、「気象情報をどう扱うか」を突き詰めていき、ウェザーニューズでしかできないAI活用に取り組みたいです。私が見ている範囲内での話ではありますが、気象業界全体ではまだまだディープラーニングを活用できる余地があると思います。
野望は、自然言語処理や情報系から気象の世界に飛び込んできた私のような人間が、気象業界を変えていくこと。その方法も重要で、AIという形にこだわらず、計算機、情報処理技術を使ってどう貢献しようか、という部分にはすごく興味がありますし、今後も挑戦し続けたいですね。
編集：ノオト
