東京地下鉄(東京メトロ)は、東京の地下に張り巡らされた 13 の地下鉄路線のうち 9 路線を運営しています。約 200 km にも及ぶ全路線の線路保守は安全運行の前提となる重要な業務。従来はその基本を人間の目視による点検に頼ってきましたが、いうまでもなくそれは地道で苦労の多い作業であり、点検の質を高めながら社員の負荷を減らすことは重要なテーマとなっています。そこで同社は Microsoft Azure の AI サービスと Microsoft Power Platform を活用し、線路を撮影した画像から設備の劣化など異常を検出するソリューション作りに着手しました。開発をベンダーに依存せず、内製化することを重視したこの取り組みにクローズアップします。
人の目視チェックに頼る線路点検にデジタルの目を加える
私たちが日頃利用する鉄道は、レールの上を走っています。レールは枕木の上に設置されていますが、レールを枕木に固定する役割をしているのが締結装置です。方式により異なるものの、レールは両側から 2 つの締結装置で枕木に固定され、その枕木が 1 m に 2 本、そしてレールは左右 2 本あるため、1 m あたり 8 個の締結装置が使われていることになります。
列車運行の安全を守るため、線路の点検は鉄道事業者にとって欠かすことのできない業務。点検は長い間、人の目で行ってきたもので、東京地下鉄(以下、東京メトロ)でもその事情は変わりません。そういった線路やトンネル、橋梁、駅舎をはじめ鉄道関連施設の保守管理を担うのが工務部であり、その軌道課で課長補佐を務める山本 努 氏は、軌道保守の現状を教えてくれました。
「人が地道に歩き、視認して、目にした状況をメモ帳に書きつける。この作業が線路点検の基本です。しかし少子高齢化による労働力不足という状況に直面し、生産性の改善が大きな課題となっています」(山本 氏)。
実際に現場で保守管理を担当するのは各路線の工務区という部門で、軌道課は軌道の保守管理・改良にまつわる計画立案や技術開発・導入支援などを行います。軌道保守の品質をさらに高め、生産性を上げて働き方も変えていくために同課が着目したのが、デジタル技術です。
「そもそも鉄道の軌道保守は、現地を歩き、目で見ることがあくまでも安全を保つための基本中の基本となっています。そのため、イノベーションが起きづらい環境にあると感じています」(山本 氏)。
イノベーションが進みにくいという軌道保守の世界にあっても、同課は若手・中堅の社員が多く、そこにベテラン社員がうまく噛み合って、新たな技術に積極的に取り組もうという機運が高い部署であると山本 氏は話します。その同課の主任でプロジェクトリーダーを務める工藤 浩之 氏は、あるアイデアを考えつきました。昨今は地下の暗い場所でも線路の画像を高精度に撮影し、点検に役立てる技術が進化しています。東京メトロも一部で導入していますが、その技術を AI と組み合わせることで、点検業務のさらなる高度化に活用できないかという発想です。
「線路画像の活用は、軌道保守業界では比較的進んでいます。当社も応用が可能なところは取り入れていますが、地下鉄特有の課題も多くあり、そこについては当社自身が技術開発にアプローチしなければなりません。これまでも AI の専門ベンダーに相談しながら開発を行ってきました。ですが労働力不足の現状に加えてコスト面を考えても、開発環境をスリム化しながらより良いものを目指さなければならないということもあり、画像を有効活用する仕組みを可能な範囲で内製化できないかと考えました」(工藤 氏)。
地下鉄特有の課題とは、例えば水の問題です。トンネル内で漏水があると、鉄製の締結装置が錆び、腐食しやすくなります。そうした部分をいち早く見つけ、交換していかなければ、地下鉄の安全運行は担保できません。なお、東京メトロの全路線には膨大な数の締結装置があり、現地に赴いて全路線の点検を終えるには、通常約 1 年かかるとのことです。
締結装置を含めた線路画像を撮影する技術があり、実際に数年前から画像を蓄積しているため、現在は画像を使った目視チェックも併せて行っています。その画像と AI を組み合わせ、従来目視に頼ってきた点検業務を自動化し、締結装置の早期異常検知を実現しようというのが、工藤 氏の考えたアイデアです。
AI を活用したソリューション開発の内製化にチャレンジ
こうして、人の目と画像を使った AI による判断の掛け合わせというハイブリッドの方法論で、より品質の高い点検業務を実現するための新たな取り組みが始動しました。
ユニークなのは、こうした取り組みが IT 部門からではなく、現場に近いところから生まれてきたことです。前述のように以前にもベンダーに依頼して AI を開発し、試験的に導入したことはありましたが、その取り組みも IT 部門発ではなく軌道課が考案したものだといいます。「工務部ではトンネルなどを担当する土木課がいち早く AI を活用したひび割れ検知に実験的に取り組んでいたこともあり、IT 部門から新技術のシーズについてヒントを得つつ、現場ならではの知見を具体化するという風土は定着していると思います」と山本 氏は話します。
そして、内製化を視野に入れて今回の取り組みで選定したものが、マイクロソフトのソリューションです。「線路の画像を活用するうえで効率的な方法がないか、できれば軌道課のメンバーで AI などを用いた異常検知を内製したいと、当社 IT 部門の担当者に話してみました。そこで、Microsoft Azure(以下、Azure)の AI サービスである Azure Cognitive Services と Microsoft Power Apps(以下、Power Apps)を利用するのが最適ではないかとマイクロソフトを紹介されたのです」と工藤 氏。その工藤 氏がプロジェクトを牽引するリーダーとなり、2021 年 11 月、レールと締結装置の画像を持ってマイクロソフトとの相談に臨みます。
マイクロソフト側で最初にこの相談を受けた Data & AI スペシャリストの大橋 洸輔 氏は、「東京メトロ様の目的が、『画像から締結装置の異常を検知すること」と当初から明確であり、工藤 様をはじめ軌道課メンバーのモチベーションもきわめて高いものでした。マイクロソフトとしても、『ぜひやらせてください!』と応えました」と振り返ります。
ただ、AI を開発するプロジェクトはトライ&エラーが付きものであり、必ず成果が出ることを確約できる性格のものではないため、東京メトロで実際に手を動かしてもらう前に、まずはマイクロソフト側で一旦画像データを預かり、事前検証を実施することになりました。
画像認識の難しさに直面してモデル作りの方向性を転換
ところが、2022 年初めに行われたこの事前検証は、思ったように進みませんでした。Azure で提供される画像認識サービス Custom Vision を用いて、線路の写真から異常な締結装置のみを検出するモデルを作成したところ、マイクロソフト側では締結装置の正常/異常の違いを判断することが難しく、十分な検知の精度を発揮することができませんでした。実際に作業に取り組んだ、AI/ML Specialist 濵田 隼斗 氏が当時を振り返ります。
「どういう状態が正常であり、どういう状態が異常であるといったことをあらかじめ AI に学習させるため、教師データを作る必要があるのですが、画像を最初に見た瞬間、これは私一人では難しいと直感しました。締結装置に傷があるかどうか、その傷が異常なものなのか、またどういう状態であれば異常の兆候といえるのか、画像を見てもわからなかったのです。工藤 氏に『ここに傷がありますよね』とうかがうと『それは傷ではなくホコリです』『それは問題のない傷です』といったご指摘をいただくのです。そもそも最初は、画像から締結装置の部分を検出すること自体が上手くいきませんでした。こうした判断がつかないため、『画像から締結装置の異常を直接検知する AI モデルの作成は難しい』という結論に達したのです」(濱田 氏)。
ただ、前述のように AI のプロジェクトにはトライ&エラーが付きものであって、一つの手段がうまくいかない場合は、別の解決方法を考えます。しかも線路点検という特殊な業務で使われるものとなれば、そのソリューションを実際に用いる側の協力と、関与が不可欠。「東京メトロ様としっかり手を組み、さらに一歩 AI の側へ歩み寄っていただくことで、より深いソリューションの開発を目指していました。ですから、失敗を実際に体験していただくのは良いきっかけでもあったと思います」と濱田 氏は話します。
東京メトロとしても「トライ&エラーは当然で、むしろ失敗がなければ自分たちにも学びがないと考えていたので、課題解決を当社も一緒になって進めていこうとの思いを強くしました」と工藤 氏。
この“失敗”を経て、濱田 氏から一つの提案がなされます。線路画像から異常な締結装置をダイレクトに検出するのはなかなか厳しい。それならまずは締結装置自体を検出する画像モデルを作成する。次にその画像から締結装置のみを切り取り、そのうえで正常か異常かを分類する。つまり、三つの工程に分けて、より精度高く異常な締結装置を見つけるモデルを作成するという提案です。
ワークショップの実施でモデルとアプリ作成に伴走
この提案に即して 2 月、マイクロソフトのレクチャーを受けながら、東京メトロ側が実際に検出モデルと分類モデルを作成するワークショップがオンラインで数回開催されます。
すると、マイクロソフトが事前検証で作成したよりもはるかに精度の高いモデルを、東京メトロ側が作り出しました。濱田 氏が語ります。「当然ですが、工藤 氏をはじめとする皆さんは、やはり締結装置自体をよく知っています。加えて、Custom Vision を使いながら試行錯誤して精度を上げていけば良いという AI の勘所もしっかりつかんでいました。結果的に、当初マイクロソフトで作ったモデルの精度は 70 %程度でしたが、皆さんがつくられたモデルの精度は 90 %を大きく超えていたのです」(濱田 氏)。
対して工藤 氏は「初めはアノテーション(AI モデルに学習させるための教師データ作成のラベル付け)という言葉すら知らなかったのですが、マイクロソフトからはアノテーションが重要だと教えてもらい、そのうえで線路画像から締結装置を切り抜いて判別しやすいように工夫したことが、精度の高さにつながったと考えています」と、この最初のステップを回顧します。
工藤 氏は、以前に行った同課の AI プロジェクトは「ベンダーとの会話のなかで、自分たちが AI について理解が浅かったことに危機感を覚えていた」と言います。その危機感が土台となり、AI を積極的に学ぶ姿勢に転じたことが早速、実を結んだともいえます。その様子を見ていた山本 氏も「まるで子どもが理科の実験に取り組むように盛り上がり、遊び心を抱きながら AI 開発に自分ごととして取り組む姿を見て、うらやましく思うと同時に、自分たちが主役となって AI を創り出す“AIの民主化”という言葉を実感しました」と話します。
精度の高いモデルが出来上がったことで、3 月からはそのモデルを実際に利用するためのアプリケーションを制作するステップに入りました。このステップでマイクロソフト側のキーメンバーとして動いた、Azureアプリイノベーションスペシャリストの宮坂 航亮 氏が説明します。
「アプリをローコードで作成できる Power Apps を使い、Power Apps から Custom Vision で作った検出モデルを呼び出すアプリと、分類モデルを基に締結装置の正常/異常を判断するアプリを作りました。今回は内製化したいという東京メトロ様の強い要望があったので、具体的な作り方のレクチャーも含めたワークショップを実施しながら進めていきました。実はワークショップではアプリを動かせるところまでいかなかったのですが、その後も打ち合わせを重ね、最終的にしっかり動くアプリを開発できました」(宮坂 氏)。
工藤 氏は「目的通りのアウトプットを出せるアプリが出来上がり、とても感動しました」と振り返ります。Power Apps に触れるのは初めてだったそうですが、Microsoft PowerPoint のスライド作成と似た感覚でアプリ開発ができ、一部コードが必要なところはマイクロソフトの支援を仰いだものの「総じて簡単でした」と話します。
マイクロソフトが“プロ”の立場で難しい部分をサポート
アプリ開発はスムーズに進み、いよいよ AI を実際の正常/異常判断に活用する最後のステップへと移ります。ここで宮坂 氏とともに支援を行ったのが、マイクロソフト シニアクラウドソリューションアーキテクトの望月 美由紀 氏です。
「東京メトロ様には、素晴らしい検出モデルと分類モデル、及び検出モデルを呼び出すアプリと分類モデルから正常/異常を判断するアプリも作り上げていただきました。ですが、検出モデルから分類モデルに受け渡す間の部分は、手作業で画像を切り取っていました。これを毎回人手でこなすのは大変手が掛かりますので、そこを自動化するコードを作成し、そのコードをアプリから呼び出して、表示画面でアウトプットを確認できるように全てをつなげる仕上げの作業が、ここで行ったことです」(望月 氏)。
締結装置として検出した画像は Power Apps から Azure Blob Storage に蓄積。併せて、画像は Azure Functions に Azure API Management でつなげられています。そして望月 氏のコメントにあるように、検出モデルと分類モデルを組み合わせ、画像を切り取り分類モデルにかける機能のコードについてはマイクロソフトで作成しました。さらに、Power Apps のもう一つのアプリから Azure Functions を通じてこのコードを呼び出し、表示画面へとつなぐ部分を、マイクロソフトの支援を受けながら東京メトロが主体となり作り上げていきました。
4 月にスタートしたこの工程から工務部 軌道課の開発メンバーとして参加したのが、工藤 竜也 氏と羽場 鴻太郎 氏です。工藤 竜也 氏はもともと軌道課で山本 氏のもと保線の技術開発に携わり、山本 氏、工藤 浩之 氏と同じく工務区での軌道保守の実務も経験していました。一方の羽場 氏は 3 月まで同部 土木課に所属し、4 月に軌道課へ配属されたばかりでした。
工藤 竜也 氏はそれまでアプリ開発の経験はなく、「Power Apps を使った開発は難しそうだと思っていましたが、実際はこんなに簡単に作れるのだと驚きました。とにかくわかりやすかったです」と話します。一方、羽場 氏もアプリ開発は初体験。「いろいろと説明を受けながらですが、わかりやすく、今回とは別に自分で何か作りたいと考えたときもできそうな気がしました」と、簡単さを強調しました。
将来的な活用拡大も視野に、取り組みを加速する
こうして出来上がった AI 活用ソリューション。プロジェクトリーダーの工藤 氏はここまでの取り組みを次のように評価します。
「精度の高いものができ、その点については満足しています。ただ、実用化についてはまだこれからの課題ですね。改良しなければならない部分があるし、精度ももっと高めていきたい。また、締結装置はさまざまな種類があるため、他の種類への応用もこれからの課題です。ただ、今回の取り組みでそれらを実現できるという手応えは十分に得られました」(工藤 氏)。
実用化に向けたスケジュール感としては、今回のプロジェクト以外に画像やその他のセンサーデバイスを使って軌道保守を効率化する取り組みも視野に入れており、併せて 2 年後をめどに実用化を進めていく考えとのことです。
山本 氏は、今後の点検業務の高品質化・効率化に加えて、新技術の導入によってこれまで頼ってきたベテランの“勘所”が正しかったことを確認でき、その技を解明して次代につないでいくためのツールにもなると期待しています。実際に羽場氏は今回の開発に取り組むなか、Custom Vision で作成した教師データを見て「これが先輩たちの言うチェックの勘所なのだと実感しました」と話しており、山本 氏も羽場 氏の言葉を聞いて「勘所をこれまでのように“背中を見て学べ”ではなく、視覚として見られることで、技術の継承に使えそうだという思いを深くしました」と語ります。
一方のマイクロソフトとしては、今回の取り組みは市民開発者とプロ開発者、そして現場のプロ技術者が連携する、今後につながるモデルケースと捉えています。検出モデル・分類モデルは鉄道のプロ技術者である東京メトロが作り、そのモデルを活用するアプリは東京メトロが市民開発者の立場で開発しました。そして、その間をつなぐ Azure Functions や Azure Blob Storage と連携する部分をプロ開発者であるマイクロソフトが作成。「3 者の卓越した技術を横断的に束ねる体制を構築できたことが、マイクロソフトが目指すクラウドネイティブ開発の方向性ともマッチしています。しかも今回はそれをワークショップという、一緒に走る形で実現でき、今後に向けた手応えを感じています」と宮坂 氏が語ります。
AI を正常/異常判断に用いる前の段階で、開発するソリューションを踏まえた将来的な展開について「蓄積されるデータを機械学習で活用し、BI ツールで可視化することで、予防保全や点検の判断に活かすこともできる。そこが最終的に目指す地点だという認識合わせを両社で行いました」と望月 氏。
地下鉄の安全運行と効率的・生産的な働き方の実現に向けて進む東京メトロの取り組みを、マイクロソフトは引き続きサポートしていきます。
[PR]提供:日本マイクロソフト