Loading
DeNA AI
contact

STORY

project member

KEI HARADA マネージャー Kaggle Master
AMANE SUZUKI データサイエンティスト Kaggle Master
KENTARO NAGATA プロジェクトマネージャー

液化天然ガス(以下、LNG)を安定的に貯蔵し、供給する関西電力(以下、関電)姫路LNG基地。
現場の熟練技術者2名による、LNGの輸送、貯蔵についてのスケジューリング「燃料運用計画」が日々行われていました。

1記事目「LNG基地運用効率化に向け関西電力とDeNAが向き合ったAI導入“前段階”」では、その作業の半自動化と運用コストの削減を目標に掲げ、AI開発プロジェクトとして取り組むまでをクライアントである関電の岡垣さんを交えてお話いただきました。

定めたゴールに向け、どのような理念を持ち、どんなプロセスを経てアルゴリズムを選定していったのか。
技術統括をしたDeNAシステム本部データ統括部データサイエンス部の原田慧、実際にアルゴリズムを開発した鈴木天音、クライアントとの橋渡し役であるスマートシティ統括部エネルギー&モビリティ事業推進部の永田健太郎に聞きました。

story 03 lng detail 01

それぞれの役割について

原田 慧(以下、原田)
僕は技術的な専門家の役割と、コンサル的な役割とを半々で担当したような感じです。
クライアントの課題をヒアリングした上で具体的に何がどうできるかと提案したり、技術選定のために必要なプロジェクトのスコープを決めたり。

--

鈴木天音(以下、天音)
僕はアルゴリズムの検討および実装を中心となって行いました。
盛り込む要件は岡垣さん(※1)、原田さん、永田さんたちと検討し、アルゴリズムの実装は原田さんと相談しつつ自分がメインで作りました。
アルゴリズムの専門的な概念をクライアントに深く理解していただくという部分では、永田さんの存在が大きいと思ってます。

--

永田健太郎(以下、永田)
確かにそこは僕の役割ですね。
ただ、原田さんも天音さんも説明が上手なので僕の出番があまりなかった(笑)。

クライアントの理解の及ばない部分を積極的にフォローするよう心掛けていますし、プロジェクトを進めていく中で両者の理解や期待値などにズレが出ないよう、常に目配せしていくことが必要だと考えています。
そんな僕の役割は「プロダクトオーナー」といったところでしょうか。

--

※1:関西電力株式会社の岡垣 義也さん。同社にて、本件の推進を担当。

works_kepco-lng_detail_02

AIを導入する意味があるか、結果を見通す最初のハードル

永田
関電さんからお話しをいただいた時点で、原田さんと天音さんに相談しましたよね。

--

天音
その後、岡垣さんの話を実際に伺ったのですが、7つあるタンクにどのようにLNGを配分すれば良いのか、コストを抑えられる良い組み合わせはどういう形なのかなど、いくつかのパターンを予めシミュレーションしていただいたんです。

その際お聞きした、良いスケジュールを作る方法論に納得感があったため、これを膨らませていけばAI開発も上手く行きそうという感触が得られました。

--

原田
AI開発のプロジェクトを始める前は、どこまでうまくいくか分からなくて「何もうまくいかないかも」と不安を抱えながら始めるものなんですよね。
今回のプロジェクトは岡垣さんの方でかなり解像度高く整理されていたので、始める前から「何も出ないってことはないな」と自信を持てていましたね。

--

天音
深堀する価値のある問題だなというのが見えました。

story 03 lng detail 02

数多くのデータを見て鍛えられた「Kagglerの勘」

永田
先方の話を聞いた時点でそこまで見えるのがすごいところですよね。

--

原田
言語化は難しいですね。勘と経験と度胸ですかね(笑)。
でもこれは僕だけが持っているものじゃなくて、天音さんも同じ感触を持っていたはずです。

--

天音
そうですね。Kagglerって、所謂「汚いデータ」に対しての耐性が高いと思うんですよ(笑)。
「汚いデータ」を見慣れていることで、これは必要な要素なのか、いらない要素なのかの判別能力が養われている気がします。

--

永田
僕が思うKaggler像は「現実の問題を解く能力が高い人」なんです。
複雑な問題を解きほぐし、解決への道筋をつけることができるのが、Kagglerに共通する特徴だと思っています。

--

原田
僕も天音さんも、現実の問題はそれとして一旦受け止め、その上で数理モデルの世界に置き換えて考える。
現実世界と数理モデルの世界の両方から見て、お互いここの部分で妥協するとうまくいくよね、とか考えています。

片方だけ考えられる人はいっぱいいるんですが、両方の視点で考えられるのは泥臭い問題に慣れているKagglerの特徴かもしれません。

--

天音
今回のプロジェクトで言うと、年に一度しか発生しないようなイレギュラーな操作をどう扱うのか、何をプログラムに盛り込んで、どこを削ぎ落として人手での運用に任せるべきなのか、場合によっては運用ルールを見直すというような判断が大切だと考えていました。

削ぎ落としの境界を置くポイントや、プログラムに盛り込む優先順位を関電さんと共有できたのがとても大きかったです。
ミーティングですり合わせていきましたが、実はこれってかなり難しいことなんですよね。この境界を見極められるのもKagglerの強みですかね。
このようにある程度事前検討を行ったあと、アセスメントの段階に入ります。

story 03 lng detail 03

少数精鋭で行うアセスメントで認識のズレを防ぐ

原田
DeNAのアセスメントはごく少人数で行います。
ここまで少人数でやれる会社はそうないんじゃないかと考えています。
これが成り立つのは、ひとえにメンバーの守備範囲が広いからなんですけど(笑)、これは大きな強みだと思ってます。

--

永田
1人のエンジニアがクライアントと直接コミュニケーションを取り、現場の運用を想像して、要件の落とし込みや技術選定まで踏み込みながら実装するというのは、このような開発では珍しいかもしれません。
それぞれに担当者がいて分業しているパターンが多いと思います。

--

原田
このように、クライアントとの初期の営業ミーティングの段階からデータサイエンティストが参加することは、DeNAのAI開発の大きな特徴だと思います。
この一気通貫の体制で業務に当たってることが、チーム内だけでなくクライアントとの意思統一、認識のズレの修正をしやすくしてくれています。

story 03 lng detail 04

徹底的なヒアリングから、現実の動きをシミュレーション

天音
アセスメントの段階で、ヒアリングとプロトタイプ作成、現場の確認から意見をいただいてズレを埋めていく3つの作業を行います。

まず「燃料運用計画」を組む時はどんなことを考えながら作業しているのかを徹底的に理解します。
ヒアリングはもちろん、現場で使用している計算表から計算式を全て読み解き、発電所を訪問して実際のモノの動きや設備の運用方法を把握しました。

そして、自分の中での理解が進んだ段階でコードを書き始めます。
まずはPCの中に仮想のLNGタンクなどの設備を作り、現実の動きを再現してみるんです。

すると、この日にタンカーが運んできたLNGをこのタンクに入れると、タンク内の残量や密度はこう変化する、といった具合にシミュレーションができるようになります。
スケジュールを入れれば設備全体がどういう動きをするのかが分かり、その動きを元にスケジュールの良し悪しを定量化できるというわけです。
スケジュールの評価を定量化できれば、あとはその評価が良くなるスケジュールを探索することに集中できます。

このような形でプロトタイプ作成は進んでいきます。
ただ、アセスメントの目的はあくまで「燃料運用計画」をAIで組めるかということを確認することです。
そのためイレギュラーな操作は省き、発生頻度の高い操作のみに絞って迅速に検証を進めていきます。

story 02 lng detail 05

現場で使われなければ意味がない。最適化にかける想い

原田
一般的には要件定義書をきっちり作成した上で開発をスタートすることが多いと思うのですが、それだとスタートするまでに半年とか1年とか時間を要してしまいます。
一方、僕らはプロジェクト開始の時点ではある程度の目処を立てるだけで臨むんです。

アセスメントフェーズでは、まず運用実態の確認を進めます。
関電さんから伺った内容をいったんシステムの言葉に直して整理して、抜け漏れや不明瞭な部分を明らかにして、改めて定例ミーティングなどで確認します。
そうやって確認できた実態をベースに、アセスメント時点での要件を定義し、それに沿って天音さんが実際にコードを書いてモデルを作っていきます。

そして、過去の実績データをインプットし、そのモデルで計算し、その結果を関電さんに確認いただき、フィードバックもいただいて……という感じでプロジェクトを進めています。

--

天音
アセスメントの段階で完璧な要件定義を作るのは無理なので、7〜8割固まった段階で作り始める感じです。
常にフレキシブルな対応ができるような体制をとっているところも強みだと思います。

--

永田
進めていく中で見えてくる要件もありますからね。

--

原田
現場のニーズと意識が乖離しないことを重要視した結果です。現場で使われないAIを作っても意味がありませんから。
現場の話をしっかり聞く、ということは常に心がけています。

--

永田
その部分について、今回特に意識した部分などあれば教えてください。

--

天音
最も大切だと感じているのは、AIが作成する「燃料運用計画」に違和感がないこと。
次にインターフェースが使いやすいことです。アセスメントを進める上で、その時点のプログラムが作成した「燃料運用計画」を、何度も関電さんにチェックしてもらいました。
数字や運用ロジックの正誤はもちろん、「なんとなく変」といったちょっとした違和感についても確認していただきました。

UIなどのデザイン周りに関しては、使用しているフォーマットに近い使用感を望まれたので、まずは現在の表計算シートの内容を検証して、必要最低限の要素だけを残したバージョンを確認してもらいました。
その上で「こんな情報があった方が便利だ」という要素を吸い上げて肉付けしていった、という感じです。
ここまでがDeNAでやっているアセスメントの範囲です。

--

原田
この段階では、システム開発というような大規模なものではなく、あくまで天音さんのPC上で動くAIを作っています。
この時点でAIが作った「燃料運用計画」を見てもらった上で最終的にプロジェクトを先に進めるかを意思決定していただき、その後、詳細部分を詰め、さまざまな機能を実装してシステム開発に進めていきます。

story 03 lng detail 06

「実用に耐えうる技術か」を判断するDeNA独自のPoC

永田
DeNAでは、アセスメントの段階で技術としての可否を見極めます。
LNGの案件については「この問題は解けそうです」という報告を出し、現在(2021年5月)はPoC(proof of concept)の段階にいます。

--

原田
「DeNAのPoC」は「一般的なPoC」の概念とは違いますね。
「AIとしてこの問題は解けるかどうか」を確認するのが一般でいうところのPoCですが、DeNAの場合「実用に耐えうる技術かどうか」を本番と同じ条件で検証するところまでをPoCの範囲に含めています。
これは、永田さんの影響が大きいんですよね。

--

永田
そうですね。「実際の運用で役に立ってこそのプロダクト」だと考えているので、一度作り上げておしまいとは考えていません。
プロダクトを一度作ったら、それを念入りに検証してフィードバックを受け、修正していくというサイクルを何度も繰り返すことで、実用に耐えるプロダクトが出来上がります。
なので、当然リリース後の運用にも重きをおいています。運用が変化した際はそれに即した対応をしなければなりません。

これはAIに限らず、DeNAのプロダクト開発のポリシーなんですよね。
お二人が思うDeNAのAI開発の特徴はありますか?

--

原田
いろいろありますが、DeNAのAI開発には既存商品がないので、良くも悪くも全てが一つひとつ手作りしているオーダーメイド。そこが大きな特徴だと思います。

--

天音
「感覚の擦り合わせ」に長けているところですね。
DeNAでは、ゼロベースの状態からヒアリングや現場確認などを経て、必要な要素を汲み取っていきます。知識が豊富な現場の方とお互いに感覚を擦り合わせ、AIで実現できる着地点を両者で探すことは良いものを作る過程でとても重要な作業です。
そこを事前にご理解いただけているといいな、と思っています。

PoCを進め、本運用へと進める

永田
LNGプロジェクトは現在、最初のPoCのフェーズを終えたところです。
関電さんには既に手元で検証を進められるプロトタイプを提供しているので、今後はそれを活用してフィードバックをいただきながら皆で検討しつつ、次のPoCに進む予定です。
一連のPoCが終了したら、運用に向けて保守運用面の確認など最終チェックを行った後に運用開始という流れになります。

--

資料提供:関西電力株式会社

client message

関電の推進担当の岡垣さん、記事内で熟練技術者として紹介されている根本さんの目に今回の取り組みがどう見えていたのか聞きました。

根本昇治さん
関西電力株式会社 姫路第二発電所 発電室運営(LNG管理)

「私がまず抱いた印象は『楽しそう』ということでした。それには、ほぼ毎週実施している三者間のミーティングの雰囲気が良くチームとしての一体感を感じられることが大きく影響しています。データサイエンティストの方自身が参加され、私たち現場の人間からのさまざまな意見や要望もくんでいただけるような議論が行われ、双方の満足できる形を一緒に模索できています。そういったところからも、長期に渡り実運用できるツールを作成しようという思いが伝わってきて、現場としても、より良くするために意見を出しました」

--

岡垣義也さん
関西電力株式会社 火力事業本部 火力開発部門 技術開発グループ

「実際にアルゴリズムを開発やコーディングする人とディスカッションできるのは有難かったです。どうしてそのアルゴリズムなのか?エラーの理由は?そもそも出来そう?といったことを本人の口から聞けたので、意思統一がはかれたと思いますし、プロジェクトの輪郭がはっきりしました。今後も運用に向けてよろしくお願いします」