AI とリスク管理

「AIビジネスの法律実務」人工知能法務研究会

AIに起因する問題の想定と法的責任、その対応について、ざっくりと書かれていました。リスクマネジメントです。新技術によるリスクの想定、リスク対応です。

扱うデータの著作権等を考えたことはありますが、それを利用して出てきた結果や生み出されたモデルの著作権、あるいはそれらが被害を与えた場合の法的責任については考えていませんでした。手落ちです。

自動車メーカーの自動運転に対するリスク管理は大変ですね。当然、実施されているでしょうし、対策も取られたうえで参戦されているのでしょう。リスクは多くても、管理がうまくいくと無事に利益を生み出せる、魅力的な分野なのだと思われます。生き残るためには必要に迫られている面もあるのでしょう。

土木分野でも「AI」を利用する話題を時々聞きます。が、自動車業界ほど真剣に取り組まれていません。どちらかというと、バズワードとなっている感があります。土木のことはわかっていてもデータサイエンスはわからない方々がほとんどで、そのプロとも交流のない、これからの分野なのでしょう。少子高齢化、働き手減少への措置としてロボット活用は叫ばれていますが、自動車業界ほど危機に感じていない executives が多いのかと思われます。

おそらく、土木分野へのAIの波には、技術より営業や財務といった非技術系の部署の方々が先に取り込まれていくでしょう。その場合、図書に書かれていたように、経営の観点からは社内規定や契約のありかたが問題になるでしょうね。
リスクマネジメントやAIにリスクを感じていない executives では、リスクが発現してから「どうしよう」になるのでしょうか？近い将来のことです。

AWS その2

Docker を入れてから気付きました。

「H2O の公式イメージがない」

無料枠のインスタンスでは GPU がついていませんので、Deep Water は無意味。開発も中止されているようですので、今後の実務での運用も期待できません。
公式には、AWS 用に Cloud Formation を利用したテンプレートが用意してありました。が、これも無料枠内のインスタンスは含まれていないようです。

Docker より Cloud Formation を利用した方が簡単で早い、というのはわかりましたが、AWS 初心者ですので、まずはその構成を理解することから始めました。

実際に手を動かしてみると機能や設定すべき項目が予想よりも多くありました。少し甘かったようです。
今回は、以下の設定を行いました。今後、各種インスタンスを立ち上げるにしても、最低限必要な設定でしょう。

・セキュリティ
　MFA, security group
・アカウント
　IAM （group, policy）
・ネットワーク
　VPC （IP, subnet, route table, internet gateway）, elastic IP
・仮想マシン
　EC2
・ファイル転送
　WinSCPを利用

オンプレミスであれば、情報インフラ担当部署の範疇。ネットワークを組むなら家でも必要な設定ですので案外ハードルは低いのですが、AWS の仕様に沿って進めるのは初めてで（当たり前）、また関連付けも必要になります。今回は以下の図書を参考に設定しました。
「Amazon Web Services パターン別構築・運用ガイド 改訂第2版」NRIネットコム株式会社

最終的には H2O を稼働させ、外部から計算をかけることが可能となりました。
流れはわかったのですが、いくつか注意点があります。書き残しておきましょう。

• flow を用いるには、セキュリティーグループのインバウンドで54321ポートの解放が必要。
• 停止中のインスタンスに Elastic IP を関連付けていると課金対象。https://aws.amazon.com/jp/premiumsupport/knowledge-center/elastic-ip-charges/

まだ、社内ではAWS を導入していません。インフラ担当部署に整備を依頼しても、「やったことないからわからない」とか言われて投げ返されるでしょうね。積極的に関与してくれるプロがそばに欲しい。技術は担当技術だけに注力したいのですが。
ま、ハードの選定や準備、保守管理の手間が省ける（その時間を購入できる）のがメリットと、プラス方向に考えましょう。

石割り

先日、石割りの実演を見せていただきました。

2m角の石が、5cmほどの楔で綺麗に割れました。面白いですね。
割れた面は少ししっとり。観察しても割れた方向の「目」はわかりませんでした。

石工さん曰く、この山は水平方向が一番割れやすいとのこと。じっと見ると、確かに鉱物にクラックが見えます。目がそろっているようです。これはσ3方向、応力解放でしょう。
実際に割るのは、この水平方向ではなく、次に割れやすい南北方向。水平方向にマーキングして、上下方向を合わせて設置し小割するそうです。周辺の山は大体同じ方向で割れやすいとのことですので、応力履歴と関係しているのかなあ、と考えながら見ていました。

そういえば、落石源の撤去現場では石工さんを呼ぶことがあるそうです。先輩曰く、たいていの石は割ることが可能で、小割してモノレールで運び出されるそうです。製品にしない（綺麗に割る必要がない）のであれば、向きは関係ないのかもしれません。

小さな力で綺麗に割る方法を見出した昔の人には感心します。素晴らしい。

AWS

AWS を利用開始。

機械学習では使う必要もないかな？と思い始めていたのですが、他にも必要となる機会は容易に予想されますし、準備を続けてきたこともあって使用することに。

最初は無料枠でできることを体験。
チュートリアル通りに EC2 インスタンスを立ち上げ。色々用意されていますね。Deep Lerning 用に CUDA から各種ライブラリまでインストール済みのタイプも用意されていました。

アクセスは Win10 から。Windows Subsystem for Linux ＋ Ubuntu を利用。
ssh -i ~/.ssh/Key.pem ec2-user@IP　でOK。簡単ですね。

ひとまず、立ち上げて、アクセスして、削除するまでの流れはわかりました。
次は Docker を使って動かしてみましょう。

巡検

先日、巡検に参加。

仕事で純粋に地質のみを見ることは皆無。巡検もここ数年はほとんど参加できていませんでした。今年は機会に恵まれ3回目です。

責任感や義務感から解放され、ただ案内されて話を聞いて楽しむ。
秋晴れの中、贅沢な時間でした。

洪積層と更新統

洪積層の液状化について、再度検討。
https://phreeqc.blogspot.com/2018/06/blog-post_88.html

示方書が　洪積層＝「概ね」更新統　としているのは、臨海部の2~1万年前の軟弱層を、慣習に外れて洪積層と呼ぶのは不都合という点もあったのでしょう。沖積層・洪積層から完新統・更新統に完全移行できなかった理由の一つと推察されます

この沖積層、洪積層、完新統、更新統の微妙な扱い方は、第四紀学会HPにも記載されています。http://quaternary.jp/QA/answer/ans021.html

なお，沖積低地の構成層である沖積層の基底面は最終氷期の最大海面低下期に形成された不整合面に相当すると考えられ， この最大海面低下期は更新世末期の約2万年頃にあたっていて，日本第四紀学会のホームページ （第四紀の地位と新定義 -完新世の開始期の定義- ） で解説されている約1万年前の完新世と更新世との境界とは若干のずれがあります．このことから，井関(1966, 1983)は， 沖積層の堆積した時期を沖積世とよぶことには意味があると述べており， 現在でもとくに平野部や臨海部の第四紀末期の最大海面低下期以降の堆積物を総称する場合には沖積層という用語が用いられています． なお，内陸部の地層については浅層の河川堆積物については沖積層とよんでも良いと思いますが， それらを構成する砂礫層の下部は最終氷期までさかのぼる場合も多いと考えられるので， 完新統および更新統（最上部）というような表現の方が良いと思われます．

液状化を例にとると、本来は堆積履歴を考慮した補正が必要なのでしょう。基準に載せ得るとすれば、それは地質屋の技量に依存するものでなく、普遍的な指標値を、容易に、安価に得られる試験とバックデータに依ることが必要です。
今の簡易判定を続ける限りは、良くも悪くも地質屋さんの匙加減ひとつということになります。改善の余地が残っているということです。

GEORAMA 2019

GEORAMA を 2019 に UP。

扱うデータによるのでしょうが、個人的な感想は「2018より不安定になった」です。
今回の主な変更点は以下の通り。

• ようやく計算エンジンが 64bit 化（遅すぎ）。
• それに伴い大きなデータも扱えるようになったとのことですが、点群など扱うデータの肥大化に追いついていません。残念ながらエラーやクラッシュが少なくなった感じはしませんでした。
• ボーリングモデルに属性がつくようになった。
• しかし、CIM ガイドラインにおける XML への属性書き出しや、平面・縦横断モデルへの属性付与には未対応。

まだまだこれからのようです。

他に選択肢ないでしょうか？