DataRobotで建設業のお客様を担当しているAIサクセスディレクターの笹口です。

建設業界は、令和の時代に複雑な課題とデジタル技術の進化に直面しています。特に、AIの活用が新たな可能性をもたらす一方で、多くの課題も浮上しています。本記事では、建設業界におけるAIの未来とその課題、そして、それらにどのように対応すべきかに焦点を当てて説明します。

建設業界は今後どのような事業環境に直面し、何を武器として持つべきか？

建設業界の発展は社会課題とそれを解決する技術進化の連続

建設業界の発展は、日本の歴史的背景と深く結びついています。江戸時代には、都市の発展や大名の城下町形成を背景に、伝統的な建築技術や木材を主体とした建築が主流になり、明治時代になると、西洋の技術導入や近代化の流れの中で、鉄骨やレンガを使用した建築が増えました。

その後、昭和期には、戦後の復興や高度経済成長を背景に、コンクリートや鋼材の使用が増え、企業の組織的なプロジェクト管理が始まりました。そして、平成の時代になると、都市の再開発や災害対策、担い手不足といった新たな課題が浮上し、これに対応するため、BIM（Building Information Modeling）やIT技術、ロボティクスの導入が進められました。

特に、BIMは、建築情報の一元管理を可能にし、効率的な設計・施工を実現しています。加えて、データ取得の方法が大きく進化しています。過去には写真や手書きのメモを主に使用していましたが、現在ではドローンや3Dスキャナー、タブレットやウェアラブルデバイスなど、多様なデバイスを用いて現場の情報をリアルタイムで取得・共有することが可能となっています。これにより、より正確かつ効率的なデータ収集が可能となりました。さらに、建設OSや建設デジタルプラットフォームの導入により、業務プロセスの最適化やコミュニケーションの効率化が進められています。これらのデジタル技術と多様なデバイスの活用は、建設業界が直面するその時代毎の課題に対応し、持続的な成長を達成するための不可欠な要素となっています。

令和では様々な課題が複雑に絡み合い、その対処には、人間 x デジタル/AI技術活用の武器入手が急務

そして、現在の令和の時代は、多様な課題が複雑に絡み合い、その解決のために人間とデジタル技術の協働が急務となっています。例えば、人口減少に伴い、建築の「建てる」中心のアプローチから「使う・維持する」へのシフトが加速しています。この変化は、単なる建物の建設や維持だけでなく、まち全体としての視点での「つくる・維持する」へとスコープが広がっています。これは、持続可能なまちづくりの新しい概念として「住み続ける、居続ける」を重視する動きとも連動しています。

また、労働力の不足と高齢化の進行は、業界全体の生産性向上の必要性を強調しています。さらに、カーボン・ニュートラルを目指す動きの中で、創エネ、蓄エネ、省エネといった環境技術の開発が求められています。加えて、地政学的要因、例えばロシア・ウクライナ問題や中東の情勢は、資材調達をより複雑なものとしています。

これらの様々な課題の中で、人間の判断をサポートする予測AIや生成AIの役割は、今後建設業に関わる様々な領域でますます重要となってきています。これらの技術は、複雑な状況下での迅速かつ適切な意思決定を可能にし、建設業界の未来を形成する鍵となるでしょう。

建設業界においてAIはどのように価値を発揮するか？

様々な業務で予測AIは浸透

既に建設業界では、様々な業務・領域で予測AIの活用が浸透しています。ここでは、いくつかの取組事例をご紹介します。

建設業界でのAI活用シーン１：企画評価

企画評価工程では、土地の仕入れに関する原価を予測する際、過去のデータや市場の動向を基に、より正確な原価を算出することが可能となりました。また、販売価格の予測も、類似のプロジェクトや地域の物件価格の動向を元に、最適な価格設定をサポートします。さらに、工事の概算見積や工期の予測も、過去の実績や現場の状況をデータとして活用し、より精緻な見積もりを迅速に提供することができるようになりました。

建設業界でのAI活用シーン２：調査・設計

調査・設計工程では、初期の設計段階で、AIを用いることで初期設定値の予測がより正確に行え、設計の効率化と最適化が進められます。また、竣工後の床振動音レベルを予測することで、住民の快適性を確保しつつ、設計の改善点を明確にすることができます。加えて、コンクリートの品質や性能を最適化するための配合も、過去のデータや実験結果を基にAIが最適な配合を提案します。さらに、地盤の診断においても、機械学習を活用することで、地盤の種類や特性を迅速かつ正確に分類することが可能となり、安全かつ効率的な建築をサポートしています。

建設業界でのAI活用シーン３：工事

工事工程では、プロジェクトの進行中に遅延が生じるリスクを事前に予測し、適切な対策を講じることが可能となります。また、リソースの予測を行うことで、人手の最適な配置やスケジューリングが実現される。工事現場で撮影される大量の写真を、AIを用いて自動でカテゴリー別に振り分けることも可能となり、管理の手間を大幅に削減します。さらに、建設現場の危険予知により、事故のリスクを低減し、安全な作業環境を維持することができます。

加えて、シールドマシンの蛇行量の予測は、トンネル工事の精度と安全性を高める上での大きな貢献を果たしています。なお、昨今、シールドマシンの蛇行量予測が精緻になった背景には、データ取得技術の進化とデータ解析手法の向上が挙げられます。従来のシールドマシンの運用では、地質データやマシンの動作データなど、限られた情報を基に蛇行予測を行っていました。しかし、近年の技術革新により、ドローンや3Dスキャナー、センサーテクノロジーなどの先進的なデバイスが建設現場での使用が一般的となりました。これにより、地下の地質構造や水分量、マシンの動作状況など、より多様かつ高精度なデータをリアルタイムで取得することが可能となりました。加えて、この大量のデータを活用するためのAI技術やデータ解析手法も進化しています。特に、機械学習を用いた解析により、複雑な地質条件やマシンの動作パターンから、シールドマシンの蛇行を予測するモデルが構築されるようになりました。

建設業界でのAI活用シーン４：維持管理

維持管理工程では、建物やコンクリート、電線などの劣化判定が挙げられます。過去のデータや画像解析を基に、AIは劣化の兆候を早期に検知し、適切な対策を提案します。また、建物の電力消費予測を行うことで、エネルギーの効率的な使用やコスト削減の実現が期待されます。さらに、設備の故障予測を通じて、突発的なトラブルを未然に防ぎ、安定した建物運用をサポートします。これらの技術の導入により、維持管理の業務はより予測的、かつ効率的なものとなり、建物の寿命を延ばし、持続可能な環境を実現しています。

今後は、建設業界でも予測AI+生成AIの活用による価値発揮が期待

このように、建設業界においてもAI活用の進化が顕著になってきていますが、今後は特に、予測AIと生成AIの組み合わせが業界の変革を牽引するキーとなると考えられます。

例えば、鹿島建設では自社イントラネット内に自社専用の対話側AIである「Kajima ChatAI」を構築し、自社とグループ会社の従業員約2万人を対象に運用を始めたと発表し、業務の効率化や生産性の向上が期待されています。[1] また、竹中工務店では建設業の専門知識をベースにしたナレッジ検索システム「デジタル棟梁」を構築し、社内ルールや技術標準、ノウハウ集などの専門情報を検索対象として、質問に対する回答を生成することができます。[2]

このように、今後、予測AIと生成AIの組み合わせによる活用が進むことで、建設業界における業務の効率化や新しい価値の創出がさらに加速することが期待されます。

建設業界でのAI活用の課題とは？

このように建設業界では様々な領域で活用が今後も進むと想定されますが、一方で、いくつかの課題が今後待ち受けているとも考えられます。

建設業界でのAI活用の課題１：立場の逆転と個別最適化

まず、大きな課題の1つは、外部のAI開発会社への過度な依存です。特定の技術やサービス提供者に依存することで、技術の更新や変更に柔軟に対応する能力が低下する恐れがあります。また、外部依存が進むことで、業界独自のニーズに応じたカスタマイズや最適化が難しくなる可能性も考えられます。

さらに、各プロジェクトや部門ごとにAIを個別に最適化するアプローチは、短期的には効果を発揮するかもしれませんが、長期的には「車輪の再開発」という形で効率の悪化を招く恐れがあります。異なる部門やプロジェクトで似たようなAI開発が繰り返されることで、全体としてのシナジーや統一性が失われ、結果的にコスト増や時間のロスを引き起こす可能性が高まります。

建設業界でのAI活用の課題２：AIモデルの”暴走”

建設業界におけるAIの活用は、多大な効果をもたらしている一方で、新たな課題も浮上しています。中でも、AIモデルの”暴走”は深刻な懸念として注目されています。AIモデルの”暴走”とは、モデルが意図しない結果を出力することや、過去のデータや偏見を元に不適切な判断を下すことを指します。特に、モデルの精度が劣化した場合、そのモデルに基づく判断や予測が業務に悪影響を及ぼすリスクが高まります。現在のところ、多くの企業はこのような精度劣化に迅速に対応する体制を十分に整えていないのが現状です。すでにAIモデルの”暴走”がビジネスに大きな影響を与えたケースも存在します。米国の著名な不動産テック企業のZillowは、独自の不動産価格予測アルゴリズムに基づき、物件購入やリノベーション費用を決定していましたが、2020年のパンデミックの影響で予測精度が狂ってしまい、市場価格よりも高い価格で物件を購入し利益率が圧迫された結果、2,000人を解雇する事態になりました。[3]

さらに、予測AIだけではなく、今後は生成AIのような高度な技術が業務に導入されるにつれ、この問題はより複雑化していくことが予想されます。生成AIは、新しい情報やデータを誰もが非常に使いやすい状態で「生成」する能力を持っており、その出力内容の正確性や適切性を確認するのが一層難しくなります。

建設業界でのAI活用の課題３：担い手不足

そして、3つ目の課題としては、専門家、すなわちAI活用の担い手の不足です。AIモデルを構築できるデータサイエンティストは限られており、彼らを育成するには時間がかかります。また、外部からの採用も難しく、特に建設業界特有の知識や経験を持つデータサイエンティストを見つけるのは一層困難です。

さらに、全社的なデジタル変革を進めるための組織やリソースが逼迫していることが多いため、AIプロジェクトの推進やデータサイエンティストの確保は益々難しくなっています。

建設業界においてAI活用の課題をどのように乗り越え、事業課題に対応すべきか？

建設業界でのAI活用において今後直面する3つ課題に対して、どう対応すべきか。以下では、これらの課題を乗り越え、事業の成功に繋げるための戦略とアプローチと紹介します。

個別最適化と立場の逆転 →コア領域は外部活用ではなく内製化

まず、1つ目の課題に対しては、AIの活用においては、企業のコア領域と非コア領域を明確に区別し、それぞれの領域に適したアプローチを採用することが、成功への鍵となります。

AIの場合、個別のAIモデルやそのモデルを実業務に適用するためのノウハウは、企業独自の価値を持つと言えます。これらは、企業の競争力を形成する要素であり、外部に依存することなく、内製化することが求められます。内製化することで、企業独自のニーズに合わせたカスタマイズや、迅速な改善・対応が可能となり、ビジネスの柔軟性とスピードを維持することができます。

一方で、AIプラットフォームやデータストレージなどの基盤技術に関しては、外部のソリューションを積極的に活用することが効果的です。これらの技術は、専門的な知識や大規模なインフラが必要となるため、外部の専門企業が提供するサービスを利用することで、コスト削減や効率的な運用が期待できます。

AIモデルの”暴走”→一元的なAIモデル管理による安定稼働化

2つ目の課題に対しては、一つの解決策として、全社一元的なAIモデルの管理が注目されています。個々に構築されたAIモデルを一箇所で一元的に管理することで、モデルの監視や更新、トラブルシューティングが効率的に行えるようになります。このため、企業や組織は効率的にAIモデルを管理できるプラットフォームの整備に力を入れています。

特に、Pythonやその他の多様なAIツールで構築されたモデルも、この一元的な管理プラットフォームの下で統一的に管理されることが求められています。これにより、異なるツールや言語で作成されたAIモデルでも、一貫した品質とパフォーマンスを確保することが可能となります。

なお、DataRobotにはDataRobot MLOpsというAIモデルを効率的に運用・管理するプラットフォームがあります。さまざまなツールやフレームワークで作成されたモデルを一元的に管理することができ、これによりモデルの運用が大幅に簡素化されます。また、モデルのパフォーマンスをリアルタイムで監視する機能が備わっており、問題が発生した場合にはすぐにアラートを受け取ることができます。

データの変動やモデルの劣化を検知すると、自動的にモデルを再トレーニングすることができるのも大きな特徴です。これにより、モデルの品質を常に最適な状態に保つことができます。さらに、大量のモデルやデータにも対応できる高いスケーラビリティを持ち、企業の成長や変化に柔軟に対応することができます。

AI活用の担い手不足→専門人材の生産性向上 + 非専門人材の戦力化

AI活用の担い手不足に対しては、二つのアプローチが考えられます：専門人材の生産性向上と非専門人材の戦力化です。

まず、専門人材の生産性を向上させるためには、全社デジタル組織の人員だけでなく、各事業部門内での推進組織人材やAI構築人材の育成・強化が不可欠です。これにより、各部門が自らのニーズに合わせたAI活用を迅速に進めることが可能となります。

一方、非専門人材をAI活用の戦力として活かすためには、全員が高度なプログラミングスキルを持つ必要はありません。例えば、Pythonのようなプログラミング言語を習得するのは時間がかかるため、DataRobotのようなローコード・ノーコードツールの活用が推奨されています。これらのツールは、コーディングの知識が少ない、あるいは全くない人材でも、AIモデルの構築やデータ分析を行うことができます。DataRobotでは、そういった非専門人材の戦力化と、専門人材の生産性向上の両方に資するAIプラットフォームとして多くの企業様にてご活用いただいております。加えて、DataRobotでは、AIプラットフォームを活用した業務課題解決を促進する伴走支援や教育コンテンツも様々提供しており、企業におけるAI活用を後押しします。

AI活用が建設業界に与える今後の影響・将来像とは？

建設業界を取り巻くデジタル環境は日々進化しています。例えば、デバイスやクラウド環境の進化により、収集可能なデータは指数関数的に増加しており、これによって業界の効率化や新たなサービスの提供が期待されています。また、ロボティクス技術の開発・進化は、人間が従来担っていた”行動”に関する部分の補助や代替を可能にしています。RXコンソーシアムの設立は、この動きの象徴であり、多くのゼネコン企業が共同で業界の課題解決に取り組んでいます。[4]

しかし、これらの技術進化の中で、益々重要となるのは”判断”の部分です。収集された膨大な情報を行動に変換するための”判断”が、どれだけ高度に、そして正確に行えるかが鍵となります。そして、その”判断”を補うのがAIとなります。なお、2023年に爆発的にブームとなった生成AIは非常に優れたソリューションではあるものの、中央値の回答を返すことは得意です。一方で、それだけでは、企業としての競争優位性や独自性を見出すことは難しくなります。したがって、今後のAI活用においては、中央値から少し外れた、”筋の良い異常値”をどう見つけ出すかが鍵になると考えられます。

この”筋の良い異常値”は、AIだけでは発見が難しく、これまで建設現場の中で技術や知見を磨いてきた人間の感性や経験が極めて重要となると考えられます。これを踏まえると、今後の建設業界における将来像としては、AIと人間が従来以上に緊密に協働し、この二つの力を最大限に活用することで、より高度なそして魅力的なサービスの開発・提供や効率的な業務遂行が期待されます。

最後に：建設業界の未来を創るAI活用

建設業界の歴史を振り返ると、その時代の課題に対する解決策・技術が進化してきました。そして、この令和の時代には様々な課題が、今まで以上に複雑に絡み合っています。そんな状況を打開するのがデジタル技術やAIだと我々は考えています。これらの技術は、単なるツールではなく、業界の未来を形成する大きな力となっていくでしょう。そして、この力を最大限に活用することで、建設業界は新たなステージへと進化することができるとも考えています。技術の進化とともに、人々の生活や社会の質を向上させるという建設業界の使命と、それを支える建設会社の方々の持続的な成長と発展を我々もサポートしていきたい。

参考文献

[1] 鹿島建設株式会社 プレスリリース 「グループ従業員2万人を対象に専用対話型AI「Kajima ChatAI」の運用を開始」(2023年8月8日)

[2] ASCII.jp「デジタル棟梁」の実現に向け、竹中工務店がAmazon Bedrockを試用」 (2023年10月3日)

[3] PALO ALTO INSIGHT, LLC 「Zillowは何故AI経営に失敗したのか？」(2021年12月27日)

[4] 建設RXコンソーシアム

投稿 建設業界のデジタル変革　〜AIと人間の協働の可能性とは？〜 は DataRobot に最初に表示されました。

ゲストキーノートにはヤンマーホールディングス株式会社 取締役/CDO 奥山 博史 氏が登壇し、「現場主導でお客様価値創造につなげるデータ分析・活用を」と題する講演を行った。本レポートでは、ヤンマーが取り組むデジタル戦略について紹介する。

■中期経営計画に合わせたデジタル戦略を推進する

創業111年を迎えるヤンマーホールディングス株式会社。ディーゼルエンジンの販売を祖業にし、1933年にディーゼルエンジンの小型化に成功。その後も、様々な世界初の製品を生み出し、現在ではディーゼルエンジンに加え、農業機械、建設機械、マリン関連、エネルギーシステムなどの分野で研究開発、製造、販売を行っている。

ヤンマーの中期経営計画の戦略課題のうちの一つが、デジタル基盤を整え次世代の経営基盤を作ること。そして、もう一つがこれまでの機械を販売する会社というイメージから脱却し、顧客価値創造企業に変革することだ。

さらに人材育成の方針として「HANASAKA（はなさか）」の推進を掲げている。これは、いろいろな分野の従業員が、それぞれ新しいことにチャレンジし、成長するとともに、新しい価値を作り出すこと、それを会社が全面的にバックアップすることで、花を咲かせようという考え方だ。

「会社としての全体戦略を踏まえて、デジタルという文脈においても、デジタルを駆使しないと実現できない新しい価値をお客様に届けることを最大の目標としています。そして、データに基づいた意思決定ができるような基盤やプロセス、文化を合わせて変革していくことを目指しています」

この目的の達成のために、ステップ1「スケーラブルな展開を可能とするデジタル基盤構築」、ステップ2「デジタルサービスの提供や効率性の向上による既存オペレーションの最適化」、ステップ3「デジタルを通じて新しい付加価値をお客様に届ける」ことを段階的ではなく、同時に進めていくという。

このような方針において、次の4つを今後3−4年間で実現していく。

「3つ目については、デジタルに興味があって、自主開発しているような従業員を見つけて声をかけ、コミュニティに参加してもらいます。グループ全体でコミュニティを盛り上げ、参加者を集中的に教育していきます。そこで成果の出るユースケースを作り、関心の薄い人たちに紹介することで『自分たちもやらないと』と意識を変えていくことができます。他社の成功事例はピンとこなくても、隣の事業部の事例は自分ごととして受け止められます。消極的な人でも、お客様に価値を提供したい、業務を効率化したいという思いは同じなので、デジタルを使えばそれができるということをしっかりと伝えていくことが重要です」

■収集したデータを活用し、これまでにない価値を提供する

ヤンマーでは、業務分野ごとに様々なデータを収集している。そのデータを組み合わせることで、お客様に価値として提供できるアウトプットが生まれる。例えば、農業機械が田植えや収穫の最中に壊れると、農作業の時期を逃してしまうなど、大きな問題が生じる。そこで、機械の振動データなどを活用して故障を予測して、機械が壊れる前に問題の部品を修理できれば、顧客への新たな価値となる。

他にも、葉っぱの色などのデータから土壌の性質を予測して、例えば窒素分が足りない、リンが足りないことがわかれば、その予測結果をトラクターに連携して、土壌に合わせた施肥ができるように最適化できる。

「機械販売だけではなく、農作業そのものに貢献できるようになりたいと考えています。データ分析によって最適な手法を提案できれば、収穫量の増加、肥料最適化による消費量の削減など新たな価値を届けられるようになります。加えて、我々のデータを農家が使う他のシステムに提供することで、貢献できることもあります」

■PoCに移る前に、アイデアを精査し、選定する

前述したように、同社ではデジタルに興味がある人を組織化し、コミュニティを作っている。現在は500人ほどがコミュニティに参加しており、データ活用のアイデアを募っている。同社では2022年よりDataRobotを導入し、データ活用・AI活用を進めているが、まずはDataRobot社と連携した勉強会を開催し、どんなデータがあればアイデアを実現できるかを考え、「テーマ創出アイデアシート」を使って応募する。2022年後半からこの流れでアイデアを募集し、集まったアイデアから、データがあるもの、ビジネスのインパクトが大きいものなどを選定してPoCを行う。現在すでに7つのPoCが始まっており、うち2つが現場での実装に近いところまでできている。

「テーマ出しをするといろいろなアイデアが出てくるので、分類することが重要です。例えば、自動機械学習で解ける問題もあれば、モデルを自分で構築する必要があるもの、AIを使わなくても市販のSaaSで対応できるものもあります。今年度もすでに同じ取り組みを通して10個くらいのPoCが出てきています」

この取り組みを通して、筋の良い分析テーマが多く出るようになってきて、奥山氏は全社に浸透しつつあることを実感するという。

■現場、経営陣とのコミュニケーションと、バランス調整が必要

ヤンマーの取り組みのまとめとして、次の3つがあげられた。

「1つ目は現場。特に重要なのは、現場の責任者です。PoCを実施したけど、その後全然プロセスにのらないということがありますが、その多くが現場の責任者を巻き込めていません。

例えば、生産部の人から、工場の設備Aが壊れるので故障を予測したいというアイデアがありました。そこで、その人の上司である課長も交えて議論したところ、経営視点で見ると設備Aよりも、Bの故障のほうがラインへの影響が大きいという話がありました。こうした議論を積み重ねることで、現場の人も経営インパクトが大きいテーマを見つけ出すことができますし、改善案を出した課長にとってもプロジェクトが自分事となるので、その後の展開がうまくいきます。 反対に責任者が関わらないと、PoCが終わって効果を説明しても、押し付けになってしまうので理解が得られません。実装に至らず現場のプロセスに落ちていかないということになります」

加えて、現場とのコミュニケーションも重視している。月に1回DXに関するメッセージをヤンマーグループ社員全員が見れるデジタルのポータルサイトに上げるほか、そのポータルサイトに、現場で実施しているプロジェクトを紹介して周知するようにしているという。他に、現場報告会と称して、奥山氏自身が現場に行って、取り組み内容や成果を動画で紹介して、全体に訴求するようにしている。

2つ目が、経営陣とのコミュニケーションだ。ヤンマーグループ全体で月に1回、幹部約60人が集まる月次会議があるので、奥山氏は毎回約15分ほど、デジタルについての取り組みや現場での成果を報告している。事業部長クラスになると、現場のDXの成果について知る機会が少ないので、奥山氏が取り組みを報告することで、デジタルのマインドシェアを高めている。経営幹部のマインドシェアがあがると、中間管理層へのプレッシャーにもなる。また、奥山氏は事業部や地域のトップと定期的に会議して、現場の実践を紹介したり、表彰するような取り組みを行っている。

3つ目が文化醸成だ。一足飛びには文化は変えられないが、デジタルに興味がある人を集中的にサポートして活性化させ、ユースケースを作り横展開していく形でデータドリブン文化の醸成を図っている。

「ただし一つ成功しても、全体が変わるわけではないので、全体がどう関連しているのかを見極めて、コーディネートして、よりよいバランスを見つけ出すことが必要です。組織の反応をみながら、一つの取り組みでやり過ぎであれば調整して他のアイデアに力を入れるなど、全体のコーディネートをするのがCDOの役割です」

最後に今年度の目標や取り組みについて紹介した。

「今年度の目標は、コミュニティに参加する部門数、人数をさらに拡大していくことです。具体的には、本社だけではなく、事業部、現場で、分析して課題解決できる人を100人以上にしたい。自分で企画をして、分析、実装できる人を育てたいです。

もう一つは、現場発だとビジネスモデルそのものを変えるような提案がでにくいので、もう少しトップを巻き込んで経営インパクトが大きいテーマを発掘したいです。そして、AI活用のコミュニティを活性化して、自発的なテーマ創出をしていきたいです」

奥山氏は、「現状は完成形ではなく、日々試行錯誤しながら改善しているところ」と述べ、講演を締めくくった。

投稿 イベントレポート(1)：顧客価値創業企業として変革するヤンマー。DXをどう推進し定着させているのか。 は DataRobot に最初に表示されました。

原則１－ガバナンス：取締役会等及び上級管理職は、モデル・リスクを包括的に管理するための態勢を構築すべきである。

AI 推進のための組織構築は多くの企業が検討してきたが、管理運用のための組織構築はまだ未着手という企業がほとんどであろう。本原則によって指針は示されたものの、実際に具体への落とし込みをする際にその難しさが顕在化するであろう。特に Part 1で述べたことの再強調になるが、AI モデル・リスクの管理を特定の個人のみに依存するのは限界がある。膨大なデータを扱い、複雑な処理を実施する AI モデル全てを人の頭脳によって把握・記憶することは困難であり、また例えできたとしてもそれは個別の力量の高い者に頼った結果であり、それらの者のリテンション問題が不安定要素として常に付き纏う。運用するAIモデルが多ければ多いほど、その限界は顕在化し、ツールをも活用した管理態勢が検討の俎上に上がってくるであろう。

原則２－モデルの特定、インベントリー管理及びリスク格付：金融機関は、管理すべきモデルを特定し、モデル・インベントリーに記録した上で、各モデルに対してリスク格付を付与するべきである。

昨今の AI プロジェクトは複数メンバーが担う傾向が高く、また人材の流動性が高くなっている観点からインベントリー管理の重要性は以前より高まっている。
気をつけるべきことは AI モデルはデータとコードから生成されるバイナリファイルに過ぎない点である。手元の AI モデルがなんのために生成されたものなのか、どういったデータとコードから作成されたものなのか、を正しく記録しておかないと再現性を満たすことができない。さらにコードとデータだけでなく、リスク格付など作成手順には含まれない情報も管理することが AI モデルの構築・運用におけるリソースをどこに割くのか判断する上で重要となる。

DataRobot はユースケース（AI 活用プロジェクト情報）登録機能を有している。AI モデルを生成するために利用したデータ、AI モデル生成過程が記録された AI モデル構築プロジェクト、運用に利用している AI モデルと IT アセットを登録するだけでなく、AI モデルが何の業務のために利用したものなのかや、AI モデルのビジネスにおける重要性（リスク格付）などの情報を登録・保持することができる。またユースケース登録機能で作成された各ユースケースは他のユーザーやグループに共有することが可能である。第1線がAIモデル作成まで完了した上で、ユースケースを第2線に共有すれば、それに紐づくデータやAIモデル構築プロジェクト、AIモデルへの参照を一元的に渡すことができる。
また、ユースケースへの更新はアクティビティとして全て記録されているため、第2線はどのような手順で第1線が AI モデルを構築していったのかを辿ることができ、そしてそこにコメントを残して再度第1線に返すこともできる。

原則３－モデル開発：金融機関は、適切なモデル開発プロセスを整備すべきである。 モデル開発においては、モデル記述書を適切に作成し、モデル・テストを実施すべきである。

AI モデルは、入力に対して確率値を返す動作は誤った AI モデルでも同じであるため、従来の IT 的なテストだけでなく生成元のデータとコード自体をチェックする必要がある。特に AI モデル生成には乱数が利用されるものも多いため、その再現性が可能な形で開発プロセスを整備する必要がある。さらに特定のツールで作成された AI モデルにおいては、そのツールが仮に利用できない状態になった場合での AI モデルの利用や再現を考慮することも重要である。そして AI モデルの限界を把握するためには、AI モデルの性質を可視化できるようにしておくべきであり、具体的には学習時に存在しない値や欠損データに対してどのように振る舞うのかなどを把握しておく必要がある。
精度面での検証では、ホールドアウト（= 学習に利用していないデータ）を利用する。これは学習時のデータだけではなく、未知のデータに対してもパフォーマンスを発揮する（= 過学習していない）AI モデルになっているかを確かめるために重要である。そしてホールドアウトそのものに過学習した AI モデルとなる可能性を防ぐ上でも、第1線からはホールドアウトが閲覧できない形で AI モデル構築を行える仕組みがあることが望ましい。

DataRobot は、AI モデル構築ステージにおいて、ブループリントと呼ばれるデータ前処理とアルゴリズム、ハイパーパラメータのチューニングが組み合わさったテンプレートが自動的に多数実行され、精度順にリスト化される仕組みとなっている。その上で、AI モデルが構築する上での学習データと検証、ホールドアウトデータの分割や全ての AI モデルに共通なモデル可視化機能も自動で実行される。また AI モデルの差別も海外では頻繁に問題として取り沙汰されているが、DataRobot は AI モデルが差別的な判定をしていないか、様々な尺度から構築段階で検知する仕組みを有している。
またベンダーロックインを防ぐ上で、より包括的なモデル記述書として、SR11-7に対応したAI モデル構築に関するモデルコンプライアンスレポートを自動で生成することも可能である。

原則４－モデル承認：金融機関は、モデル・ライフサイクルのステージ（モデルの 使用開始時、重要な変更の発生時、再検証時等）に応じたモデルの内部承認プロセスを有するべきである。

シャドウ IT という言葉が一時期話題になったが、AI モデルが誰にでも手軽に作成できるようになった今、「シャドウ AI モデル」が社内に氾濫する可能性がある。そのため、AI モデルを安全に正しく使う上でも、第2線からの独立的なチェック体制及び、稼働開始フローをシステム的にも整備することが重要となる。また AI モデルは導入後にも時間とともに精度が劣化する性質から、定期的な再学習を必要とする。すなわち、AI モデルにおいては使用開始時のみに気を配るのではなく、再学習という変更の発生が従来の IT システムに比べて頻繁に起こることを考慮した内部承認プロセスを構築する必要がある。

DataRobot では AI モデル・ライフサイクルのステージに合わせたタスク、またそのタスクへの関わり方に応じて権限分掌を行うことができる。そして、権限分掌を行った上で、AI モデル・ライフサイクルのステージ変更及びその AI モデルの重要度に応じて、設定した承認ポリシーに従った承認ワークフローを設定することが可能である。これにより、第1線と第2線での内部承認プロセスをシステムとして構築することができるようになる。

原則５－継続モニタリング：モデルの使用開始後は、モデルが意図したとおりに機能していることを確認するために、第１線によって継続的にモニタリングされるべきである。

AI モデルは時間とともに当初想定していた性能を発揮しなくなる。また急激な市場の状況やその他の環境の変化等によって AI モデルの性能が大幅に劣化することは少なくない。実際、本稿執筆時（2022年3月）、新型コロナウイルスの蔓延に伴い、過去に作成された多くの AI モデルが再作成を余儀なくされている。このような AI モデルの性能変化を適切な間隔でモニタリングすることで、モデルを再作成するべきタイミングを適切に検知し、劣化したモデルの使用によってもたらされる経済的損失を未然に防ぐことができる。AI モデルにおけるモニタリングポイントは、従来のシステム的な「サービス正常性」と AI モデル特有の「データドリフト」と「精度変化」の三点となる。
「サービス正常性」とは、運用に利用している AI モデルがシステムとして正常に稼働しているかを確認するものである。未知の入力が来た場合のエラーハンドリングをできているかなども含まれている。また従来の統計モデルに対して複雑化した AI モデルは推論時においても処理時間がかかるものもあるため、想定時間内に計算が完了しているかなどもチェックは必須となる。
「データドリフト」とは、AI モデルの運用にとって非常に重要な概念となる。学習時と推論時の各特徴量（説明変数）の分布が変化したことを表現する言葉で、データドリフトが発生していると AI モデルが学習時と同等の性能を発揮しない可能性が高い。データドリフトが発生する要因はいくつかあるが、代表的なカテゴリとしては以下の2つとなる。

• 時間経過とともに全体のトレンドがドリフトするもの
• 学習時と推論時の条件違いによって発生するもの

「時間経過とともに発生するデータドリフト」も、緩やかに発生するものや急激に発生するもの、周期的に発生するものがあるため、データドリフトが発生するサイクルに合わせて AI モデルの再学習を計画することが重要である。これらのドリフトは世の中のトレンドに影響を受けて起こるため、AIモデル作成者自身もその発生タイミングで感覚的に気づける場合が多い。
もう一つの学習時と推論時の条件違いによるデータドリフトは、データ変換処理上の違いが原因で発生する。同一の変換処理を利用しない理由として、例えば”学習時にはバッチで学習データを準備したが、運用時はオンライン推論だったため、それぞれの処理で通るデータパイプラインが違った”などが存在する。
変換処理の違いで実際に起こりうるものには以下のようなものがある。

• 学習時にだけ表記ゆれを修正し、推論時には表記ゆれ修正を行っていない
• 学習時と推論時でエンコーディングが違い一部の値が別の値として認識されている
• SQL の処理系の中で学習と推論時で欠損値の扱い方が違う

これらはそもそもがミスが起点で発生しているため、AI モデル作成者が捉えることは難しい。ただし、データドリフト検知を実施することによってミスに気付くことができるため、中長期的な AI モデル運用だけでなく、短期的なモニタリングにおいてもデータドリフト検知は重要となる。
「精度変化」はそのまま AI モデルの最終パフォーマンスを見るものだが、注意すべきは、精度が変化したことに気づくまで推論時点からはラグがあるということである。仮に AI モデルが3ヶ月後のデフォルトを予測しているものだった場合、その正解データは3ヶ月後にならないと収集することができない。この点からも AI モデル運用では精度変化を検知することも重要だが、精度変化だけでなく、先に上げたデータドリフトをモニタリングし、未然にリスクを検知することが重要となる。

DataRobot 内で作成した AI モデル及び Python、R、SAS などで作成した AI モデルを DataRobot に取り込んだ場合には自動的に「サービス正常性」「データドリフト」「精度変化」を時間および特定のセグメントごとにモニタリングできる。また DataRobot から外部に書き出された AI モデルでも、エージェント機能によって「データドリフト」「精度劣化」を同様にモニタリングできる。そして、運用状況をデプロイレポートとしてスケジュールされたタイミングで自動発行する機能も有しているため、AI モデルが増えた場合においてもスケールする運用体制を構築することができる。

原則６－モデル検証：第２線が担う重要なけん制機能として、金融機関はモデルの独立検証を実施すべきである。独立検証には、モデルの正式な使用開始前の検証、重要な変更時の検証及びモデル使用開始後の再検証が含まれる。

第2線に関する議論、特に体制面での議論に落とし込むと、一つ大きな課題が見えて来る。本原則の3つの防衛線ルールでの第2線は、原則1.4においてそれが第1線から独立すべき監督部門となるべき、とされている。第3線が管理態勢全般への監督を役割とする以上、実質的な管理監督の要はこの第2線であるため、その役割は極めて重大だ。ただ、”この役割に付きたい人はいるのだろうか？”
AI モデル分析は現在最も先進性/将来性の高い領域の一つだ、データサイエンティストを志す者が、膨大な時間をかけてスキルを身につけてきたのも、その最前線で挑戦を続け、更なる高みとリターンを目指すためであり、「管理監督」という一歩引いた役割を望む者は少ないであろう。一方でAIモデルリスク発生時のインパクトを考えれば、企業としてはこの役割に最先端の知識を持つ者を配置したい。米国での AI 普及の初期を振り返ってみると、多くの企業でこのギャップが見落とされていた。例を挙げると第2線に引退間近の人員を配置し、管理態勢が形骸化し、リスクへの防衛が疎かになってしまった。この課題を解決し、強固な第2線体制を構築するには3つの方法があり得る

①    系列企業の第1線同士が検証し合う体制の構築
②    第2線ポジションの魅力向上
③    牽制役ではなく、第1線と共闘する第1.5線の設計

①   
ごく自然に思いつく打ち手だが、系列各社の第1線が他社の第1線の AI モデルを検証することができれば、上記の課題にはなりうる。金融庁の質疑回答を確認する限り、この対策は推奨されているとまでは言えないが、明確な否定もなく、その妥当性はどちらかと言うと、企業ごとの実務的な有効性次第であろう。系列企業とは言え、業務を異にする以上、他社の AI モデルをどれだけ理解し、有効な検証ができるかは各社が慎重に判断すべきであろう。

②     
上記の打ち手が現実的でない日本企業には、米国企業の反省を踏まえると、ぜひ第2線のポジションの強化、そしてそのための人材キャリアパス設計を進言したい。端的に言えば、第2線での役割でも十分な報酬を期待でき、社内的にも将来性のあるキャリアパスが見えれば、スキルの高い人材にも十分魅力的なポジションとなる。
このような管理監督ポジションはどうしても軽視されがちだが、今一度AIモデルリスクのインパクトを概算して頂きたい。その数字を見れば、このポジションにいくらのコストをかけるべきか、自ずと見えて来るはずだ。

③     
また、そもそもの役割として第2線を単なる第1線に対する牽制役とすべきではなく、もっと第1線と共闘する役割と考えても良いのではないか。第2線のポジションはある意味、ガードレール的な役割だが、現在 AI モデルリスク管理においては絶対的に正しいガードレールは存在しない。ならば、第2線は第1線がやろうとすることの本質を正確に捉え、リスクを抑止しつつ、その実現をサポートする、いわば「第1.5線」の役割である方がより現実的である。それにより第1線はより積極的に第2線の協力を仰ぐようになり、“守り”だけではなく、“攻め”をも兼ねた AI モデル検証体制が構築できるはずだ。

原則７－ベンダー・モデル及び外部リソースの活用：金融機関がベンダー・モデル等や外部リソースを活用する場合、それらのモデル等や外部リソースの活用に対して適切な統制を行うべきである。

ベンダー・モデルのデータやパラメーター等が不透明な場合に生じるリスクとしては、以下の2つが存在する。

• ベンダーがサービスを停止した際に再現性が保てなくなるリスク
• モデルの特性や限界を正しく把握できないリスク

1つ目のリスクはベンダー・サービスより API 経由で AI モデルを利用している場合などにおいて、その API が使えなくなることを意味する。このリスクを回避するためには、AI モデルをベンダー・サービスと切り離せる何らかの仕組みをそのベンダーが提示できるかどうか確認する必要がある。
2つ目のリスクはベンダー・サービスの AI モデルに予期しないバイアスが含まれていることやどのようなパターンで精度が劣化するか把握できていないことを意味する。リスク回避手段の一つは、AI モデルの性質を調べるためベンダーに学習用データとコードの開示を要求することだが、学習データやコードの開示はそのベンダーの知的財産にも関わるため現実的ではない。現実的には、AI モデルのリスク格付けが高いものに関しては、ベンダー・モデルの利用を停止するという手段も選択肢にいれるべきである。補足となるが、近年の AI モデルは複雑化しており、ベンダー・モデルが一部処理のみで使われている場合も存在し、一見手元のデータからゼロベースで学習させたと思っていても潜在的にベンダー・モデルが紛れている可能性もある。そのため、AI モデルの透明性を求めた上でその内容を注意深く確認する必要がある。

DataRobot は、基本的には企業内での AI モデルの内製化を目指したプラットフォームであり、ベンダー・モデルに該当するケースは多くはない。ただし、一部の高度な分析テンプレートにおいては、事前学習済みのモデル（高度な自然言語処理や画像データの前処理）を含んだものが存在する。DataRobot では、これらの処理が使われた AI モデルかどうかを確認することができるため、該当処理を含まない AI モデルを選択することもできる。また、他の処理は残したまま、該当処理だけを除きたいという要望に対しては、自動生成された分析テンプレートを編集する ComposableML 機能も備えている。
そして内製化を目的としてDataRobotを導入しても、その利用者をすべて外部リソースに頼っている場合には、活動の結果を理解し、適切に評価することは難しい。外部リソースの活用をリスク管理を実施した上で実現できるためにも、ツールの導入だけでなく、人材育成は重要なウェイトを占めることになる。

原則８－内部監査：内部監査部門は、第３線として、モデル・リスク管理態勢の全体的な有効性を評価すべきである。

第3線の論点も多々あるが、一つ絞るなら、“今ではなく、これから”を見据えた管理監督が求められる。監督対象として企業が“今”どんな AI モデル・リスク管理態勢にあるのか、は当たり前として、第3線は企業の AI 戦略、つまり“これから”やろうとすることまで、助言し監督すべきである。さらにその前提として、常に最新のトレンドと情報を踏まえたアドバイスを求められる。前述のように AI モデルリスクがどんどん進化する以上、管理監督の論点も変化し続けているため、それらをいち早くキャッチアップし、社内での検証・改善に落とし込める機能が第3線に求められる。しかし、そこまで行くとやはり管理監督体制は一朝一夕で構築できるものではない。したがって企業によっては一定の外部支援を初期は求めるのも一つの手であろう。

まとめ

本稿ではあくまで AI モデルに注視して記述したが、モデル・リスク管理の原則では、モデルの定義は統計モデルやルールベースモデルなど、様々な手法をカバーするものと回答されており、AI モデルに限定されるものではない点には注意が必要となる。
リスク管理では、組織的な体制、人材の育成、またそれらをサポートするシステムが重要となる。AI モデル活用が金融機関において拡大中のいま、本ブログ及び弊社ソリューションが参考になれば幸いである。

参照文献

金融庁：モデル・リスク管理に関する原則
金融庁：コメントの概要及びコメントに対する金融庁の考え方
COSO──ガバナンスと内部統制３つのディフェンスライン全体でのCOSOの活用
三つの防衛線（3つのディフェンスライン）によるリスクマネジメント
Machine Learning in Production: Why You Should Care About Data and Concept Drift

投稿 モデル・リスク管理の原則におけるAIモデルの対応について Part 2 は DataRobot に最初に表示されました。

本稿は二部構成をとっている。Part1 では金融庁の示すモデル・リスク管理における8原則への対処を思案する上での重要論点を整理し、Part2 では各原則について個別に DataRobot を利用した対処案を説明する。（AI モデル・リスク管理は金融業界だけでなく全ての業界で遅かれ早かれ具体的対処が必要になる重要項目であると考えられるため、金融業界とは直接関わりがなくてもDataRobot が提唱する対処法・機能についてご興味のある読者はぜひ Part2 だけでもお読みいただければ幸いである）

今回、本原則の発表は金融業界にとって青天の霹靂では無いはずだ。元々モデルの管理を規定する SR 11-7 は米国で早くから導入されており、日本にもいずれ類似の業界ルールが規定されることは予見できた。それでも、本原則の正式発表は、今まで各社が企業単位で独自努力と理解の範囲で行って来たモデルリスク管理がとうとう、業界単位でのルール規定の下に、チェックされることを意味している。それは、モデルリスク管理が金融機関にとって最重要アジェンダである時代の到来を告げている。

DataRobot は米国で、SR 11-7 が登場した黎明期から、AI モデルガバナンスの支援を AI 活用をリードする金融機関に対して実施して来た。その経験は本原則への対応でも参考価値があると考えられる。

本原則を議論する上での論点は下記のように大まかに整理できる：

①    本原則の対象となる企業はどれか？
②    管理対象となるモデルはどこまでか？
③    管理すべきリスクとは何か？
④    ガバナンス（管理体制・社内ルール）をどのように設計すべきか？

本稿は主に上記論点④の範疇にあるが、論点①、②、③における要点をまず述べさせて頂きたい。端的に要点をいうならば、

①　本原則対象は今後将来的に拡大する可能性は高い。
現状、G-SIBs、D-SIBs、FSB により選定された G-SIBs（本邦 G-SIBs を除く。）の本邦子会社であって、金融庁によるモデルの承認を受けている金融機関が対象となっているが、SR11-7 のトレンドを見ても、日本では今後対象範囲が拡大することは必至だ。
また、原則の対象外になっているからと言って、例えば現対象の子会社がモデルリスク管理をしていない訳ではない、子会社ごとに方向性の異なる管理アプローチが進むと、いざ対象範囲内に入った時に、親会社を含めたグループ全体の管理方針に齟齬が生まれてしまう。現時点から先取って、子会社をも検討の範囲内に含めることは長い目で見れば間違い無く多くのコストを節約することができる

②　本原則の発表により、管理すべき対象はより広義のものとなった。
恐らく、直近ではまずこれが各対象企業にとっての一番の頭痛であろう。本原則では、明確な線引きはされていないが、質疑応答などをも含めて読み解くならば、広義にモデルを解釈する方向性は確かだ。各業界/企業ごとの事情によるため、一概に論じることは難しいが、ガバナンス体制を検討する上でも影響は出てくる。
*本稿においては、より精緻な議論のため、広義のモデルの中でもあえて AI モデルに範囲を制限していきたい。AI は近年金融業界で業務利用が急拡大する一方で、運用管理について悩まれている企業がまだ大多数であり、議論の価値が高い領域と認識している。

③　AI モデルリスクは絶えず変化/進化しており、現状特定できていないリスクにも備える必要がある。
これは本原則というよりも、近年の AI モデルの進化とそれに伴う事件を見れば、AI モデルリスクというもの自体、まだ我々が把握しているのはほんのわずかであり、今後AIモデル活用が本格化するに連れて、どんどん新しいリスクも発生する。例えば、AI モデルのバイアスによる不公平性のリスクは、凡そ今まで予見が難しいリスクであった。そのような新しいリスクをいかに早くキャッチアップし、自社における対策を講じることができるのか、これもガバナンス体制に問われるポイントの一つとなりうる。

④　構成においては、他のリスク管理と同様に、実効的なけん制を確保する基本的な枠組みとして、「3つの防衛線（3線モデル）」の概念の下で整理する。
この中で、「第1の防衛線（第1線）は、モデルを所管する又はモデルの開発・使用に直接関係する部門・個人で構成される（モデル・オーナー、モデル開発者、モデル使用者等）。」を想定と書かれているので、実際に AI モデルを構築するデータサイエンティストが含まれることになる。そして「第2の防衛線（第2線）は、第2線に対するけん制を通じてモデル・リスクを管理する部門・個人で構成され、モデル・リスク管理態勢の維持、規程等の遵守状況及びモデル・リスク全体に対する独立した立場からの監視、モデルの独立検証等の役割を担う。」を想定と書かれていることから普段業務においては、AI モデル構築は行わないながらも、監視や独立検証ができるレベルということで、第1線以上のデータサイエンススキルを求められることになる。最後に、「第3の防衛線（第3線）は、内部監査部門で構成され、金融機関のモデル・リスク管理態勢の全体的な有効性を評価する。」となることから、単純なデータサイエンススキルだけでなく、企業の AI 戦略を見据えることができる人材を必要とする。これらの構成を満たした上で、さらに理想とするガバナンス体制は、透明性、継続性、効率性の3つのキーポイントを実現できるものであるべきである。

AI モデルリスク管理のガバナンスにおける絶対的な正解はまだ無いが、米国の金融機関の先端的な取り組みを支援して来た DataRobot の経験から見えてきたキーポイントの中で、特に重要な3つのキーポイントがあると考えている。そして、DataRobot は下記の3つを満たすガバナンス体制の構築には、人にだけ依存するのではなく、ツールをも活用することを提言している。

・    透明性
・    継続性
・    効率性

上記で論じたように、AI モデルリスクはまだ絶えず進化しているものである。世界中で膨大な数のAIモデルが運用されており、今まで想定していなかったリスクが突如現れる。ここ数年、これらのニュースは幾度も金融業界を騒がせてきた。新しいリスクの発現において、企業がまず実施すべきは、自社での類似の運用状況の把握である。そこにおいて、人に依存しない透明性が重要となる。”うちには優秀なデータサイエンティストがいて、その人に聞けば状況把握は全てわかる！”、と安心している企業は多いのかもしれない。ただ、それは盲信・過信の危険性があり、ガバナンスの思想ではない。どのようなデータを持ち、どのように分析し、どのように運用されているかの状況は理想として、人の頭にではなく、全てツールとして記録され、誰もがすぐに、明確に把握できるようにすべきだ。

継続性も上記議論から生じるものだ。人への依存には、転職・各種事由による勤務不能、パフォーマンスの不安定などのリスクが付き纏う。第1線、第2線のキーマンが離職したばかりの時期に、AI モデルリスク側が空気を読んで発生を控える、ということが望めない以上、ガバナンスの根幹として人への依存は可能な限り抑えるべきである。

最後に効率性も見落としてはならない重要なポイントである。ガバナンスの目指す姿を今一度お考え頂きたいが、リスク回避だけがガバナンスの目的では無いはずだ。”リスクを抑制しつつ、業務効率をも維持すること”が理想像のはずである。恐らく、AI モデルリスク管理を具体的に検討した企業はすぐにこの難題にぶつかるであろう。本原則1.3で求められる、”文書化”、は実務者から見れば、”言うは易し・・”の典型である。AI モデル活用は今最も進化が活発な技術領域であり、第1線のデータサイエンティストは日々トライアンドエラーを繰り返しており、また扱うデータの種類・量も膨大である。それらを管理監督の実効性を維持できるレベルで記録する手段は、具体的にどう設計すれば良いか？AI モデル構築・運用を行いつつ、横手で一つ一つのアクションをエクセルなどにでも記録するのか？それは現場を無視し、効率低下を招く非現実的な管理手法に他ならない。AI モデルの構築・運用、そして記録、それらが自動的に、シームレスに、一つのプラットフォーム上で行われるべきである。記録という行為で人への依存をできる限り抑止する、それは、効率性のみならず、正確性の観点からもガバナンスの理想像と言える。

”人への依存の抑止”、は DataRobot が提供する重要な付加価値の一つであり、それは Part2 でより具体的に、技術的に解説していく。その根幹をなす思想として、上記3つのキーポイントの観点があることを覚えて頂きたい。

各原則については、Part2 にて DataRobot としての対処案をより具体的に論じていくが、その概要を下記に提示する：

Part 2に続く。

投稿 モデル・リスク管理の原則におけるAIモデルの対応について Part 1 は DataRobot に最初に表示されました。

社内のハッカソンでDataRobotを活用したチャットボットを作成したのでそのことについて紹介します。

背景

弊社のプロジェクトはJIRAというチケットシステムで内容や担当者、進捗状況などが管理されています。下の図は横軸が時間になっていて縦軸がチケットの件数になっています。そして各チケットのプロジェクト種別ごとに色分けしています。図で確認できるように、始めは単純な進捗管理だけでプロジェクトに別れていなかったのですが、人や組織、機能が増えたことによってプロジェクトの細分化が発生しています。またチケットの件数自体も増加傾向にあります。

会社自体が急激に成長している中で、新しい人がどんどん入社しています。新しい人は問い合わせ先がどのプロジェクトチームなのかを覚えるのも一苦労で、問い合わせを受けるプロジェクトチームも自分たちが担当でない問い合わせを受けるのは時間の無駄となります。

このような問い合わせ先のディスパッチはどの企業でも多かれ少なかれ問題になると思います。今回はハッカソンの一環として、チケットシステムにある過去データからどのプロジェクトになるかを予測する機械学習モデルを作成し、問い合わせに対しての答えを返してくれるチャットボットを作成することにしました。

弊社は社内チャットツールとしてはSlackを利用しているため、チャットのインターフェースとしてはSlack、機械学習エンジンとしてはもちろんDataRobotを利用しました。元のデータはJIRAからAPIを利用して取得しています。

学習データと予測モデルを作成する

学習データ取得と定常化

まずは予測モデルを作成しないといけないので、チケットシステムからデータを抜き出してきます。一件一件チケットを手動で抜くわけには行かないのでJIRAのAPIを活用しました。普段あまり利用しないAPIを利用することは、どんなデータ形式でどんなデータが抜き出せるのか把握するのは大変ですが、学習データの作成をスクリプト化しておくことによって、今後データが増えた際にデータの再収集が楽になります。参考までにJIRAのAPIでデータを抜いて来た時のコードを紹介します。コード化することによって、今後新しいチケットができた場合にも同じコードでデータを簡単に収集することができます。

[sourcecode language=”python” wraplines=”false” collapse=”false”]
import pandas as pd
from jira import JIRA
JIRA_USERNAME = ‘mikio.ogawa@datarobot.com’
JIRA_PASSWORD = ‘XXXXXXXXXXXXXXXXXXXXXXXXX’
JIRA_URL = ‘https://atlassian.net/’

def get_jira_client(**kwargs):
 jira_client = JIRA(JIRA_URL,
 basic_auth=(JIRA_USERNAME, JIRA_PASSWORD),
 **kwargs)
 return jira_client

def get_feature_from_issue(issue):
 Key = issue.raw[“key”]
 ProjectName = issue.raw[“fields”][“project”][“name”]
 Summary = issue.raw[“fields”][“summary”]
 Description = issue.raw[“fields”][“description”]
 d = {‘Key’ : Key,’ProjectName’ : ProjectName,’Description’ : Description,’Summary’ : Summary}
 df = pd.DataFrame([d])
 return df

jira = get_jira_client()
df = pd.DataFrame([])

for startnumber in range(0, 80000, 100):
 issues = jira.search_issues(‘status IN (“Resolved”,”Closed”,”Done”)’,
  startAt=startnumber, maxResults=100,fields=”summary,description,project”)
 for issue in issues:
  tmpdf = get_feature_from_issue(issue)
  df = df.append(tmpdf, ignore_index=True)
 print(startnumber)
df.to_csv(‘training.csv’,index=None,header=True)
[/sourcecode]

学習データ作成で気をつけるポイントとしては、JIRAには、チケットが登録されてからのコメント、アサインされた人、添付ファイルなど様々な情報が記録されています。ただ今回の目的としては、チケットを登録するときにどのプロジェクトチームに向けて登録するかを教えて欲しいチャットボットを作ることです。そのため、チケットを登録する瞬間で得られる情報だけで学習データを作っていきます。

リーケージなどの学習データのクオリテチェック

元々はチケットを登録した際の区分（新機能リクエストなのか、不具合報告なのか）もやくにたつと思ったのですが、最初に選んだプロジェクトによって、入力可能な区分に制約があり、リーケージとなっていたため除くことにしました。劇的に精度が高くなるわけではなく、見つけづらいリーケージでしたが、このようなものもしっかりと除いて汎化性能を高めます。また、チケットの中には未対応、対応中、完了などのステータス情報があります。未対応や対応中のものに関しては、チケットが進むに連れてプロジェクトが変わる可能性があるため、ステータスが完了のチケットのみを学習データで使用します。状態が揺らぐものを除くことによって学習データの質をよくします。さらに調べていくとプロジェクトの中にはもう解散したプロジェクト、マージされたプロジェクトが存在したため、解散したプロジェクトのデータは除き、マージされたプロジェクトはデータの方もマージしました。

予測モデルの作成

ここまでくればモデルを作るパートとしては、DataRobotは多値分類に対応していて、テキストデータもそのまま分析に使用することができるので、学習データを放り込んで開始ボタンを押すだけです。*DataRobotでは現時点では10カテゴリまでをサポートしていますが、社内プロジェクトのため、特別に30カテゴリまで拡張しています。

予測モデルを確認

作成した予測モデルが実際に使えるものか確認します。

トップのモデルはTensorFlow Blender AUC 0.96。これだけ見るとおかしいくらい良いモデルに見えますが、元々難しい未来を予測しているのではなく、専門のエンジニアがテキストを見ればほぼ間違いなく正しいプロジェクトに割り振れるので妥当な数字です。特徴量のインパクトを見ると文字量のわりにSummary(要約)が、Description(詳細)に比べて倍以上効いている結果になりました。ちゃんとタイトルに情報を短くまとめられている証拠かもしれません。テキストの文字数、添付ファイルの拡張子などのフューチャーエンジニアリングも実施しましたが、精度にほとんど影響を与えられず、その割にコードの修正、予測時の入力の手間が増えるのでシンプルにSummaryとDescriptionだけを特徴量として使用することに決断しました。

作成した予測モデルのプロジェクトごとのAccuracy(正解率)を予測としてトップに出てくる一つ(Top1)だけで当てた場合、Top2で当てた場合、Top3で当てた場合で積立棒グラフでプロットしました。

比較的当てやすいプロジェクトはTop1で80-90%を超えていますが、50−60%付近のものも多くあります。Top2にすることによって、だいたいのプロジェクトが70%を超えてきて、Top3にするとほとんどが80%を超えてきます。二つほど異常に低いプロジェクトがありますが、件数も少なく中身を確認するとどう見ても他のプロジェクトと同じ内容であったので、ここは社内で再度確認が必要という課題も見つかりました。全体のAccuracyだと、Top1で71.1%、Top2で84.2%、Top3で90.4%という精度になりました。

予測値としては、一番高い確率に予測されたプロジェクト名だけを返すのが当初の予定でしたが、それだけだと精度が要件を満たせないので、トップ3のプロジェクト名を返すようにプランを変更しました。予測モデルの確認が完了したので、100%の学習データで再学習させて予測モデルの準備は完了です。

Slack Bot(チャットボット)の作成

Slackのアカウントがあれば、こちらからボット用アカウントを作成できます。ボットを作成すると、APIトークンが確認でき、ボットのサムネイル画像などを設定できます。APIトークンはコードからボットを認証させるのに使用するので、大切に保管しましょう。

Slackにはボット用のAPIが用意されており、様々なプログラミング言語に対応したSDKがこちらに提供されています。今回はデータセット作成でPythonを使用していたので、そのままPythonのSDKを利用しました。

Slack Botコードを作成

Slack Botの動きとしては、サーバでボット用のプログラムを作成しておくと、Slackのトークにポーリングを行い、特定のメッセージに反応して動作します。業務で利用するため、そこまでフランクな話しかけなどに対応する必要はなく、ボットに対して直接、SummaryとDescriptionを問いかけると予測モデルを使用して該当しそうなプロジェクトをトークに返してくれるようにします。

メインのコードだけを紹介します。実際のコードでは初期設定、ロギング、エラーハンドリングも実装していますが、キーポイントだけピックアップしたものにしています。

[sourcecode language=”python” wraplines=”false” collapse=”false”]
class PredictionBot(object):

 def __init__(self, slack_client, datarobot_client):
  self.datarobot_client = datarobot_client
  self.slack_client = slack_client
  self.bot_id = slack_client.api_call(‘auth.test’)[‘user_id’]

 def do_predictions(self, channel, message):
  summary, description = message.split(‘n’, 1)
  self.say(
   channel,
   ‘Ok, please give me a minute to think about it :thinking_face:’,
  )
  try:
   predictions = self.get_predictions(summary, description)
  except Exception as e:
   msg = ‘I am sorry but I am puzzled with your request :dizzy_face: `%s`’ % e
   self.say(channel, msg)
   return

  if predictions is None:
   self.say(
    channel,
    ‘Something went wrong with this prediction. I am sorry about that :confused:’,
   )
   return

  most_probable = predictions[:3]  # top 3 predictions to show
  context = itertools.chain.from_iterable(most_probable)
  context = [i if type(i) == str else i * 100 for i in context]

  response = (
   ‘I think it should belong to `{1}` with {0:.2f} accuracy :nerd_face:’
   ‘or `{3}` with {2:.2f}%, `{5}` with {4:.2f}%’
  ).format(*context)
  self.say(channel, response)

 def event_loop(self, sleep_time=0.5):
  while True:
   events = self.slack_client.rtm_read()
   if not events:
    time.sleep(sleep_time)
    continue

   for channel, message in self.parse_events(events):
    if message.startswith(‘     self.do_switch(channel, message)

    elif self.validate_request(message):
     self.do_predictions(channel, message)

    else:
     self.say(
      channel,
      ‘Sorry but I am puzzled. I have expected at least two lines as input. ‘
      ‘The first line stands for summary and all the rest for a description’,
     )

if __name__ == ‘__main__’:
 # Slack
 slack_token = os.environ.get(‘SLACK_TOKEN’, ”)
 slack_client = SlackClient(slack_token)
 bot_id = slack_client.api_call(‘auth.test’)[‘user_id’]

 # Datarobot
 datarobot_token = os.environ.get(‘DATAROBOT_TOKEN’, ”)
 datarobot_endpoint = os.environ.get(‘DATAROBOT_ENDPOINT’, ”)
 datarobot_client = dr.Client(
  endpoint=datarobot_endpoint,
  token=datarobot_token,
 )

 # Default PID,LID
 pid = os.environ.get(‘PROJECT_ID’, ”)
 lid = os.environ.get(‘MODEL_ID’, ”)

 # Setup and run main loop
 bot = PredictionBot(slack_client, datarobot_client)
 bot.setup(pid, lid)
 bot.event_loop()
[/sourcecode]

Slackイベントのポーリング

event_loopから見ていくと、events = self.slack_client.rtm_read()と出てきますが、これはSlackのAPIを利用してイベントが発生しているかポーリングを行なっていきます。イベントが発生していなければスリープに入るようになっており、発生していればその条件にそってアクションを実行し、do_switchとdo_predictionsのどちらかを実行します。

モデルの動的切り替え機能

do_switchはメッセージがurlだとDataRobotで使用するモデルを切り替える機能を仕込んでいます。モデルは一度作成したら終わりでなく、時間とともに劣化していくもののため、継続的に作成し直していく必要があります。作り直すたびにボットを停止させるとメンテナンスが大変なためこの機能をつけました。

プロジェクトの予測

do_predictionsは２行からなるメッセージの１行目をSummary、２行目をDescriptionと認識して、予測モデルを利用してどのプロジェクトに該当するかの確率を返します。DataRobotの予測コードに関しては、以前にブログで書いていますがハッカソンでも例文とほぼ同じものを利用しています。DataRobotは実際には今回のような多値分類の際には該当する全てのクラスに所属する確率を返しますが、先ほどの精度のレベル的にトップ3までを返すように設定します。

今後のプランとまとめ

学習曲線を見た所、より多くのデータが溜まっていけばさらなる精度向上が望めます。DataRobotでは学習データを増やす価値がどれくらいあるかも一目でわかる機能を設けていますので、この点も今後のプラン作りに役に立ちます。新しいモデルを作成した場合には、モデルのスイッチ機能を利用すればダウンタイムなしでモデルを更新することができるので、数ヶ月後にはモデル更新を予定しています。

今回のSlack Botの仕組みは別のチケットシステムにも応用ができそうだとすでに実験が始まっています。他にもチケットがどれくらいで解決するのかの解決目安を予測するとかアイディアはつきません。

機械学習プロジェクトにおいて最後のデプロイにつまずくことはよくあります。チャットボットなら比較的簡単に実装できるので、本当のビジネス実装前の試験運用に有効なアプローチとなります。機械学習のモデルをデプロイする一つの手段として皆さんもぜひチャットボットに挑戦して見てください。

投稿 プロジェクトアサインを予測モデル搭載チャットボットで解決する は DataRobot に最初に表示されました。