みずほと富士通のセキュリティ話を聞いてきた！

３月２１日

第二回　情報セキュリティマネジメントSummit
～知の終結でサイバー攻撃と内部犯行に立ち向かう

を午前中だけきいてきたのでメモメモ

---

■みずほフィナンシャルグループのサイバーセキュリティへの取り組み
経営の重要課題として、サイバーリスクにいかに取り組んでいるか

・自己紹介

１．みずほの紹介
・みずほフィナンシャルグループの概要
・拠点展開　４７都道府県、店舗約８００、ATM５万以上、世界１２０拠点

２・サーバー攻撃はトップリスク
・世界経済フォーラム　The Global Riskc Report 2017
　サイバーセキュリティはトップクラスのリスクファクター

・Allianz Risk Barometer
　サイバーセキュリティ３位
　多くの国でサイバーインシデントはトップリスク

・サイバー攻撃は世界全体で深刻な脅威
　サイバー攻撃の戦線拡大：ボットネット：テラバイト
　相互接続の弱いところ標的
　サイバー戦争

・サイバーセキュリティ経営ガイドライン

３．みずほのサイバーセキュリティの取り組み
・サイバーセキュリティを経営レベルで考え、進めるには、どのようにしたらよいでしょう？

・みずほにおける取り組みの経緯
　ワーキングを作った→点検
　サイバーセキュリティチーム　CIRT
　　不正送金対策も
　データマネジメント　衣替え
　　プロアクティブな体制強化

・サイバー攻撃への対応体制

　データマネジメント部
　サイバーセキュリティチーム
　みずほCIRT
　　　↑
　　　↓
　主要グループ
　　　↑
　　　↓
　関係子会社

・経営課題としてのサイバーセキュリティのすすめかた
　サイバーセキュリティは企業が対処すべき多くのリスクのなかの１つ

①必要な機能の全体像を把握する
　→標準フレームワークの活用　NIST CSF、FFIEC CAT
　　標準フレームワークを用いた第三者評価・ベストプラクティスとの比較
　経産省ガイドラインもいい

②自社としての機能を定義する
　機能の全体像
　　平時からやること
　　対策
　　できているもの、できていないもの、外でやったほうがいいもの

③ビジョン・目標・基本方針を定める
　サイバーセキュリティ戦略
　　みずほのビジョン
　　サイバーセキュリティビジョン・目標
　　基本方針
　５つ（プロアクティブ、レジリエンス）

④アクションプランを具体化する
　サイバーセキュリティ重点施策

⑤社内のプロセスに組み込む
　ルールとプロセス

弊社のサイバーセキュリティ業務の一部をご紹介します
・ポイントは
　　小さくてもよいので、まず、できることからはじめてみる
　　平時の業務も重要です（情報収集・警戒活動）

・サイバー攻撃から守るべきものは？
　サイバーーリスクアセスメントレポート
　例：Struts2の脆弱性→どこで使っているかわかるように

・SOCによるモニタリング業務
　過去ログ調査。アラート監視→ダッシュボード監視

・インテリジェンス業務
　人間系からはじめてみる

・フォレンジック業務　Cyber AIR3 Force
　マルウェア解析
　機械学習を含め検討

弱いところが狙われる
・金融機関への主なサイバー攻撃
　金融機関への直接攻撃
　お客様からの間接攻撃

・バングラディシュ中央銀行不正送金事案
　SWIFT：クローズド→マルウェアを利用したAPT攻撃
　
・インターネットバンキング不正送金発生状況
　メガバンクが狙われた→地域金融機関へ広がる

・不正送金被害のグローバル推移

・インターネットバンキングをめぐる犯罪者との攻防戦
　いたちごっこ

・不正送金対応例　トランザクション認証　メガバンク初
　ワンタイムパスワード

自助を前提にこうじょ、きょうじょ
・関係機関との連携体制
　金融ISAC（あいざっく）：２０１４年１０月に発足

・これからのサイバーセキュリティ
　東京２０２０対応
　IoTセキュリティ
　セキュア・バイ・デザイン

・政府主導のサイバーセキュリティ対策
　重要インフラの情報セキュリティ対策に係る第四次行動計画

まとめ
・IoT時代の発展に向け、サイバー空間のセキュリティ確保は必須条件
　　　↓
　みずほグループは志を持って
　サイバー空間の安心・安全と持続的発展に取り組んでまいります


■ワークスタイル変革を加速させる
　クライアントセキュリティソリューション
～テレワークの推進には、今すぐに万全な情報漏えい対策を！～
　富士通クライアントコンピューティング

・労働環境に関する国の動向
　労働者を取り巻く環境の変化　
　男性正規労働者を中心とした長時間労働
　ワークライフコンフリクトへの増大

・社会環境の変化でワークスタイル変革に期待が高まる
　労働力確保、生産性向上、高付加価値創出が必要

・テレワーク導入の状況
　テレワーク導入企業の８割は効率を実感。６割はモバイルワーク

・富士通のワークスタイル変革　実践事例
　富士通事例：どこでも安全な仕事環境
　１６年より国内従業員PCを仮想化、セキュリティを向上

・動画

・１７年４月からテレワーク制度を正式導入
　誰もが働きやすい、魅力的な会社に
　生産性向上、時間の有効利用
　多様な人材が活躍できる職場環境
　BCP

ワークスタイル変革を加速するクライアントセキュリティソリューション
・テレワークの注目　２点
　就業管理規則
　セキュリティ

・ワークスタイル変革と機密情報の漏洩
　オフィス内のセキュリティ対策

・情報漏えい事故の主な原因

・パスワード運用の厳格化と利用者の実態
　利用者へのパスワード使いまわしアンケート
　　プライベートのパスワードを仕事でも利用

・不正アクセスを誘発するパスワード管理の実態
　　パスワードのお設定や管理の甘さが不正アクセスの標的に
　　パスワードさけのアクセス管理では・・

・情報漏えいの脅威
　情報漏洩事故は経営リスクにつながります
　　経済的な損失
　　社会的信用の失墜

・ワークスタイル変革実現に向けて
　安全性の要求を高めている
　　ぽりしーの厳格運用
　　パスワードの複雑化
　　USB持ち出し禁止
　利用者：
　　心理的負担が増大
　　事後対策
→利用者に優しく、リスク最小化

・ワークスタイル変革実現におけるモバイル端末の課題と対策
　オフィス外での安全なモバイル端末の利用
　　VDI
　　WindowsPC

　認証：手のひら静脈認証
　データ持ち出し　PASERI
　ひみつ：CREARSURE

　利用者に対策

・対策１：秘密分散方式ソフトウェア　PASERI For　RC
　データは暗号化デバイスではなく、秘密分散で安全に持ち出す
　　秘密分散法＝PASERI
　PASERI For PC
　　導入のメリット：安全、簡単操作、管理工数の削減

・対策２：リスクを最小限にする対策（情報漏えい対策）
　モバイル新クライアントたいまつ
FUTRO（ふゅーろ）

・シンクライアント端末メリット
　端末にデータ残さない

・モバイルシンクライアント端末　FUTRO　
　ばんぜんのセキュリティ
　　生態認証による本人確認の強化
　　データの抜き取りを防止
　長時間駆動と軽量コンパクトを実現

対策３　リスクを最小限にする
CLEARSURE

・モバイルPCにおけるセキュリティ対策
　電源の状態にかかわらず
　CLEARSURE 3G/LTEの仕組み
　シャットダウンされていても、遠隔地から確認できる
　　→BIOSと通信モジュールで行う
　スマートフォンからロックできる
　GPS情報の提供

・対策４　利用者に優しい対策
　認証ソフトウェア、認証サーバー
　ビデオ
　　リスト型アカウントハッキング
　認証ソフトウェア　SMARTACCESSの商品体系
　　お客様の環境・規模に応じてご提供
　SMARTACCESSはセキュリティと利便性を両立した人に優しいソリューションです

　SMARTACCESS/Virtual
　Secure Login Box：ユーザーの認証情報を一元管理８９万８千円（標準）

　離席対策「Sense You Technology Biz」
　カフェや交通機関での短時間の離席時対策

・ワークスタイル変革への業務への広がり
　オフィス
　営業
　現場

　事例：
　　生態認証で「セキュリティ強化」と「利便性」を両立
　　VDI(仮想化）＋生態認証で営業事務の効率化を実現
　　ペーパーレス化の実現と情報漏えいの危険を防止
　
・最後に
　人に優しいクライアントセキュリティで
　お客様のワークスタイル変革をお手伝いします！

セクハラし放題の女性ロボットが売れたら・・・

セクハラに対し女声アシスタントは従順に振る舞うようプログラムされるべきではない

って言っても・・・ねえ・・

「AI」は声でセクハラを助長する？ 「女性秘書はロボットだから」に潜む人間の危険性
https://www.fuze.dj/2017/03/ai_sexual_harassment.html

「テスト自動化の８原則」を経営者はまず理解しろ！

３月１９日
システムテスト自動化カンファレンス2017

にいってきた！ので、その内容をメモメモ

---

■あいさつ・諸注意
・今回は、アーキテクチャ
・YAHOO　きおいちょうオフィスは写真厳禁

■快適・簡単・安心なアプリE2Eテストの実行環境
・自己紹介
・取り上げる話題：アプリE2EテストのUI環境
・アジャンダ（省略）

・ヤフーのアプリ開発について
　１００を超えるアプリ、ダウンロード　３億8千万超える
　開発体制：２０００名以上、サービスごとにチームが分離
　アジャイルスクラム導入しているところも

・アプリ開発テスト環境
　自動化進んでいる
　開発
　GITにコミット
　CI上で単体テスト＆ビルド
　社内アプリ配布サイトにデプロイ
　ダウンロードして手動テスト

　アプリキャット
　　E２Eテストを追加

・開発の背景
　E2Eテスト自動化に取り組んでいるところ
　　→テストケース開発
　　　CI連携に手が回らない
　　　Macを必要なだけおくことが出来ない、動かす稼動状況安定しない

　アプリE2Eテストの実行環境の整備大変
　　テスト対象のアプリのビルド　　　環境構築大変
　　テスト実行端末の起動・初期化　　初期化大変
　　テストスクリプト実行　　　　　　並列実行難しい
　　結果保存、プロジェクトに周知　　手作業だと忘れる

　気づき
　　アプリのE2Eテストの実行環境整備はサービスの開発と両立しない
　　実行環境は全社共通で整備したほうがいい

　→Applicat

　　ヤフーの規模で快適に使える
　　簡単にCIにつかがる

・特徴
　Appiumを採用
　並列実行可能

・自社開発を決めるまで
　クラウドサービスの利用検討
　　Sauce Labs
　　AWS Device ふぁーむ
　　Xamarin

　メリット
　　結果安定、スケール、スピード
　デメリット
　　社外にアプリを出す、クローズドなAPIが使えない
　→自社開発

　テストフレームワーク
　Appium（あぴーむ）
　OS標準（Expresso/XCUITEST)→ios
UIオートメーション、UIオートメーカー
　→仕様の安定性、抽象化

・Appiumでのテストをスケールさせる
　端末の排他制御・実行待ち・冗長構成がスケールさせるために足りない
　AppiumをスケールアウトさせるOSS
　　Selenium Grid
　　　複数のAppiumへのアクセスを振り分けるLBのようなもの
　　Selenium Grid　Router
　　　GridへのLB
　Grid/Grid Routerでは大規模な運用は難しい
　GridRouterとテスト実行がSPOF

　→フルスクラッチ

　キューとワーカーを使う

　テスト実行キュー
　　テスト実行をWork Queueで管理
　　　並列実行
　　　Workerを増やすことでスケールアウト可能へ

・安定したテスト実行のための工夫
　ビルド
　　社内標準のCIツール上でビルドされたバイナリでテストを実行

　ipaファイル　アプリとメタデータがZIPでまとめられたファイル
　　→テスト実行できない
　　→メタデータを置き換える：再署名
　　fastlaneのsighを利用

　端末の初期化
　　初期化ができていないとテスト結果がぶれる
　　実機のリセットは難しい
　　　全てのアプリを削除
　　　keyChainはアプリからしか消せない
　　iosのテスト前初期化用アプリ
　リトライ機能
　　テスト失敗時、同条件の別端末で再実行するリトライ
　デバイス監視
　　実機との接続が切れることがある
　　定期的にデバイスの接続を確認、接続切れたらアラート
　安定して実行されるように

・他にも・・
　ライブラリの提供
　　YAHOO JapanIDのログイン
　　ネットワーク設定
　ログイン機能
　　ほとんどのアプリで実装
　　テストケースにアノテーションを付けるだけで、ログイン状態に出来る

　ネットワーク設定機能
　　WebAPIリクエストのあて先を変える

　フレームワークの整備
　　テストの書き方のサポート
　　　PageObjectパターン
　　　適度なタイミングで画面遷移待ち

・まとめ

・最後に　募集してるよ

■Q&A
・かわったこと
　E２Eテストに取り組んでくれる人が増えた
・実機VSシミュレーター
　サービス側のニーズがあった（端末固有の問題）
・複数端末テスト
　まだ取り組めていない
・他のアプリに依存するケース
　将来的にできるようにしたい
・Grid Routerの限界
　Grid１０くらいにしておいたほうが・・
　Grid Router　１００くらい、ただし、SPOFのほうが問題
・エビデンスは
　アップロードして、参照できるように

---

■普通の開発ってなんだ？
・アンタだれ
・ナンデキタン？
・茶番（登壇に至るまで）
　２つの仕事をしている
　　　ふるぼっこされたり
　　　自動化したり
　→ひよる
・今日は自動化
　Gitサーバーにある：メンテしにくさ
　自動化の道具を使う
　　CI
　　Jenkins
　　Sonarqube
　　Slack連携
　　UnitTest→自動テスト
　顰蹙を買う
・つくりなおす
　Android
　フラットにおいてある
　作り直してもらう
　→DDDのレイヤードアーキテクチャ
　　MVP
・若年性Ststicおじさん
・これをしたい
　　CIやテスト
・仕事として成立する理由
　　バギー
　　技術的負債のあるコード品質
　新しく作る：
　　技術的負債を返上するチャンス：リプレイス・リメイク
　　　→長期化の兆しがあるとき
・なんでした？
　一般化してみると
　　不満が多い
　　やりにくい形を解消
　　結局同じ
　理由
　　時間的制約
　　育ってきた環境
　　作法
　　定石
　　過去の経緯
　　組織の壁

　プログラマーのパートナーの壁、専属、突然の指令、基準なき検査機関、バグ

　言い訳に強いコード

　シンゴジラ
　「ここではどう動いても人事査定には影響新バイから、自由に発言してかまわない」

　言い訳に津用コードを書いている感じがするなら
　　人系やプロセス疑ったほうが良いかもねー？
　　純然たる勉強不足もある

・普通の開発
　ソース
　　思想がある
　　設計がアル
　　FW選定
　　→出来る限りの虫食い問題にする
　環境
　　CI/CDがある（考慮がアル）
　　環境調達にある程度自由が利く
　プロセス
　　出来る限りノイズがある
　　よくわからない手続き承認がない
　　テストに理解がある
　　　書いても怒られない
　　変えていける
　人
　　教育不要
　　苦手克服

・機能追加が修正の能力が１と感じたら１である
　開発の後半には、新規機能の追加はラクになっている

・ちょっとまて、それは理想の現場？

Q&A
　いくつぐらい、普通の現場？
　１つ。あるはある

---

■テスト自動化システム　成長記
　継続的に運用するために何をしてきたか？

・アジャンダ

・自動テストを継続していくときの障害
　コスト
　環境の維持
　人に依存

・テスト自動化サービス（Lynx)とは
　自動テストを実施するうえで必要なことを全て代行

・誕生
　Selenium WebDriver
　テスト内容：GUITest
　　シナリオテスト
　Selenium Grid
　　シナリオテスト：回帰テスト
　　機能テスト

・２０１３年ｔ月
　顧客増えた、スクリプト増えた、バージョンアップが頻繁
　重複するコーディングが多い
　共通関数記化、テンプレート化

　毎回同じ・・・自動化エンジン
　パターン、都度違う→Excel

・アーキテクチャ
　　Jenkins
　　エクセル
　エンジニア・テスターでの作業を分離できた

・対応
　config対応
　　Excel→スクリプトは作成できても、時間は変わらない
　DDT
　結果送信：テスト通知
　レスポンスタイム測定
　ダッシュボードの作成・報告書の廃止
　オフショア

・アーキテクチャ
　AWS上に構築
　任意に実行可能

・規模感
　対応キーワード：４３種類
　テストステップ数　８万ステップ
　エラー発生数　１０件以上
　バグ発見数　約１～２件／月

・OpenCVを使って画像認識をして押している

・今後の課題

■Q&A
・IDが動的に変わる場合
　　変わらないでいいところを見つけ、それでいいですか？
　　自動化しやすい提案

・ご検知とチューニング
　チューニング sleepをいれる
　slackで報告
　→タイムアウトが多い

・AWSってパフォーマンス安定しないよね
　で、レスポンスの取り方？
　→情報収集中

・オフショア
　テストラボを外に持っていった
　ダナンは日本語読める
　日本側に残さないと、技術のこらない

---

■テスト自動化８原則

１．手動テストはなくならない
２．手動でおこなって効果のないテストを自動化しても無駄である
３．自動化テストは書いたことしかテストしない
４．テスト自動化の効用はコスト削減だけではない
５．自動テストシステムの開発は継続的に行うものである
６．自動化検討はプロジェクト所期から
７．自動テストで新種のバグが見つかることはまれである
８．テスト結果分析という新たなタスクが生まれる

※テスト自動化研究会のサイトに出ている

・策定の経緯

・こんなことありましたか？
　全てのテストを自動化しようとして苦闘した
　自動化すればコストは減るはずだ
　自動化したもののメンテナンスが大変

・テスト自動化の８原則
　経営者はまず理解しろ！

・手動テストはなくならない
　自動化できないもの
　ROI的に割に合わないよね
　最初の1回は手でやったほうがいい
　あんなに自動化好きなGoogleは１０％～２０％は手動
　ケースを作るのは手動
　　テスト実行とレポートが自動化できる
　　テスト観点を与えてあげれば自動化できるけど

・手動で行っても効果のないテストを自動化しても無駄である
　GIGO
　手動で効果のないテストを行っている組織に明日はない

・自動テストは書いたことしかテストしない
　自動化されたテストは視野が狭くなる
　　→質はがたおちになる
　つまんないテスト：枯れたテストを自動化する

・テスト自動化の効用はコスト削減だけではない
　そもそも、コスト削減のハードルは高い
　バグの改修速度が上がった
　デリバリーを早める：製品の進化の速度があがる
　あき時間の活用
　銀行：影響管理分析をしないでCICDを行った

・自動テストシステムの開発は継続的に行うものである
　一度にすべてを自動化できない→おそらくする必要もない
　構成管理も必要。継続管理。開発プラットフォームと思ったほうがいい

・自動化検討はプロジェクト初期から
　自動化されると思うと、コーディング規約も変わる
　あとからだとやりにくい：ID振るのに
　ツールをそろえる：グルーコードがふえる
　製品コードとあわせておいたほうが(ICSTでGoogleが）

・自動テストで新種のバグが見つかることはまれ
　基本的にデグレが見つかる
　自動テストはセイフティテスト
　殺虫剤のパラドクス：ソフトウェアテスト７原則

・テスト結果分析という新たなタスクが生まれる
　自動テストでフェイルがでたとき、あとで人間が確認
　自動化した場合、あとでまとめて大量に行うことになる
　　バグの種類は同じ：それをまとめる仕組みもいれないと
　結果分析が負担にならない自動テストを考えなくてはならない

・つづきはまたいつか

■Q&A
・効果のあるないの判断
　～なったら～できる→に「こと」とつけるテスト
　同値分割のクラシフィケーション
・要求段階で自動化を決めたほういい
　遅くとも計画まで
・結果分析の自動化？
　自動化しないとスケールしない
・継続的システムテスト
・ファジングは新種のバグみつからない
　みつかるかも・・→「まれ」である
・自動化に向いたシナリオ
　正しく動作することは無理
・２００画面のテスト
　優先度次第
・テスト自動化のフェイルはインシデントでバグと決まったわけではない
　　→一次仕分けしていない

---

■機械学習を活用したテスト自動化システムの設計

・自己紹介

・今日のお話：Magic Podの概要

１．概要
　機械学習の技術を活用した自動テストWebサービス
　　ディープラーニング技術などを利用
　　現在はモバイルアプリ向けのみ
　これまでつくった数々のツールのノウハウを凝縮
　magic potから解明

・開発状況
　アルファユーザーテスト
　機能ギャップを埋めている

・最終目標
　人間向けの手動テストケースをAIが理解し自動実行
　多くはUI手動テスト→フォーカス

２．設計する
（非公開の予定）
・２．１　テスト実行エンジン
　捜査対象の指定範囲は何がいい
　　画像テンプレートマッチ　→画面変化に弱い
　　座標指定　→画面変化に弱い
　　システム情報で指定　→画面変化に強い
　システム情報指定の問題点
　　内部構造の理解
　　システム情報に外部からアクセスできない
　　見つからないときのエラー原因
　　開発者：システム情報のキープはあまり考えてくれない
　検索ボタン、名前入力エリア
　　→Magicロケーター findbyMagic

・要素技術
　見た目から特定→CNNのディープラーニングでTensorFlow,Chainer
　位置関係でラベル付け→Captioning　SVMで

　画像解析
　　１．領域分割
　　２．各領域をCNNにかけて物体認識
　　３．OCR
　　４．Captioning
　　２，３，４の結果をマージして表示

　１＆２が時代遅れ＆低速なので

・全体像
　２とおり
　　テスト実行時ロケーター計算方式
　　テスト作成時ロケーター計算方式

１．テスト実行時ロケーター計算方式
　画像解析
　選んでテスト作成
　Mocaテストコードに変換
　コマンドラインから実行、CIから実行
　実行時にサイド画像解析
　Appium要素計算
　Appium実行

２。テスト作成時ロケーター計算方式

　画像とUIツリー情報をアップロード
　画像解析＆ロケーター計算
　選んでテスト作成
　実行前にUIマップ
　そのままAppium実行

・改良
　物体認識ロジックのカイゼン
　UI操作をAppium非依存に
　内部で使用するロケーターをよりRobastに

２．２　スクリプトの生成
　キャプチャ＆リプレイ　サポートすべきか
　→画面のUIをサーバーにおいて作る
　問題
　　１つのUIが複数の画面状態
２．３　スクリプトの形式
　表形式
　プログラムコード
　→相互変換可能
　表形式からスクリプト：できている
　Sahagin　テストコードをASTに
　　Gebもやってきた
　あらゆるテストコードを表形式に？→できない

３．細かい機能デモ

---

■自動化アーキテクチャにまつわるスキル
1割くらいがオートメーター
AutomationtestSSF
・だれ　
　STAR(システムテスト自動化研究会）こみっター
・２０１５年アルファ版発表、β版の差分
・自動化アーキテクチャにまつわる箇所
・

・そもそもテスト自動化とは
　開発者より
　　バイナリを作る前
　テスターより
　　繰り返し操作、リソースを有効に
　ユーザー（運用）より
　　受け入れチェック
　→現場ごとに範囲、種類異なる
　　学習すべきことが変わる
　　AutomationTest.SSF（スキル標準フレームワーク）

・何が嬉しいの
　現場の人が学習するための指標を作れるようにする

・想定使用方法

・全体像
　テスト自動化戦略の策定
　テスト自動化システムの開発
　自動テストケースの開発・実行
　テスト自動化関連の管理

　テスト自動化システム
　　自動化戦略で考えること
　　テスト自動化システム
　テストケース　　　モニタリング
　SUI I/F　　　　　　駆動　判定　レポート
　　　　　　　　　　初期化・あとしまつ
　　　　ユースケース

　アルファ版

・再検討して

　β版：めちゃ増えてる

・テスト自動化アーキテクチャ
　　そもそもアーキテクチャとは　IEEE1471の定義

　ソフトウェアシステムアーキテクチャ構築の原理
　３つのスキル
　　技術的スキル
　　ビジネスの知識（ドメイン知識）
　　ソフトスキル
　　　→情報キャプチャ、促進、交渉、コミュニケーション、柔軟性

　テスト自動化アーキテクチャ共通の特徴
　　継続的に運用
　　つなぎ方・つなぐシステムが変わる

　テストプロセスとの関連
　　テスト設計→自動化
　　テスト実装
　　テスト実行
　　テスト報告

　分け方・つなぎ方

・SSFの解説に入る前に
　２つの想定ロールを定義
　　テスト自動化マネージャー
　　テスト自動化エンジニア
　※兼任も可

・システム関連の管理
　上手くテスト自動化すすめること
　計画の策定：見積もり
　教育：開発、実行、運用、スキル把握
　保守：構成・変更管理
　テストベース：前提資料全部
　効果の予測と測定：KPIの設定・測定
　　　→　数字でものを言う／複数のインジケーター／自動記録・収集
　フィードバックサイクルの構築・実施
　テスト技術戦略の策定：テスト技術の蓄積（体系化、規格・RFC)

・テスト自動化戦略の策定
　ライフサイクルと戦略をまとめる
　テスト戦略の分析：目的、要求、自動化できるテストの識別、効果予測
　要件定義：テスト自動化要件の調査、制約の調査、他の手段、まとめる
　状況把握：開発プロセスの状況把握、テスト対象の理解、
　スコープの設定：範囲の設定、徹底度、粒度
　開発プロセス：
　ツールの選定：使用ツール、連携ツール、フィージビリティ（制約、スケール）
　テスト対象、プロセス管理：変更点の識別

・テスト自動化システムの開発
　システム作ること
　設計：アーキテクチャ、実行プロセス、自作部品、運用ルール、容易性向上
　実装：作る、既存のものの変更、連携、環境構築
　検証・妥当性確認

・自動テストケース
　実行する部分なので、みなさんあとで確認してください。

・まとめ

・今後の展望
　微調整
　パイロット利用
　レビュー
　パブリックコメント
　公開

DMMのたまご型対話ロボット

３月11日、OSC2017 Tokyo/Spring の
お昼のライトにングトークと、展示会でたちよってお話ししたところのメモメモ

---

＜＜ライトにングトーク＞＞
■Raspberry Piでハイレゾオーディオ
・ハイレゾオーディオ：カットされる音の部分まで入っている
　　USB DAC(デジタルアナログコンバーター）
　　I2C
・RuneAudio
　Volumio　　：フリーでダウンロード
　　SDカードの書き込み
　　Win32DiskImager
　　DDコマンド

■メールサーバーセキュリティ診断
　MS checkerで診断
　方法
　　MS checkerから送信されるメールに返信するだけで診断できる
　　http://mschecker.jp
　メールに返信（空メールでOK)
　結果通知のメールに診断結果サイトURLが載っている

■Vulsで始めようDevSecOps
・自己紹介
・脆弱性の情報収集と該当サーバー探し：超大変
　　それをしてくれるソフト
・OSS、エージェントレス（SSH)、非破壊スキャン
　主要ディストリビューションのスキャン可能
　OpenVAS,AmazonInspectorと比較
　Qiitで公開している
　slackにレポートできる

■サイボウズでHackする方法
・こどもぷろぐらみんぐ
・サイボウズがHackできるって知ってた？
　開発者ライセンスある
・OSS出してる。walb（わるびー）
・脆弱性報奨金制度
・ラボコース：インターン（サイボウズの仕事はしない）
　→年齢制限ない
・副業採用
・５０４でプラレール

■（つなぎ話）４月１９日、優秀なエンジニアを育てるには
　サイボウズで　コンパスに　DevNight
　OSPN：情報発信

■Fuego　組み込みLinuxテストフレームワーク
　bitbacketに入っている
　Jenkins+シェル
　組み込みLinuxの課題
　　クロスビルド
　　依存関係の動的インストール
　　ハードウェア制約
　Jenkinsのフロントエンド使ってる

■なぜサイオスがNGINX
・前はテンアントニーだった
　扱っているもの；Oracle ,redhat,suse,edb,nginx
　Nginx plus　エンタープライズ向け：国内代理店
・どこで使う　フロントエンドのLB
　運用から見たマイクロサービスアーキテクチャ
　機械学習／人工知能

---

展示：生活革命

DMMのたまご型対話ロボット
１０万円くらい。ＳＤＫは公開されていない。
スクリプトも作成できない
Pepperもやっている。スクリプトを作って納品したりしている

親御さんが「CISCOが使えるように、PHPが・・」で専門学校って、５年後、どうするんだよ・・

３月10日、OSC2017 Tokyo/Spring で

オープンソースの側面から見る「箱」とSDN

のお話を途中からきいてきた！んだけど、ここにメモしてなかったのでメモメモ

---

（途中から）

Facebook 最新のものを出してくる(Googleは使って古くなってから公開）
SDN:試して使う
　　→ネットワークプログラミングできる：やってみる
　　→プログラミングが変わってくる
・ネットワークわからない人が書いたプログラム
　インフラ屋がぎゃーという（CPU振り切れとか）
・DevOps:ベンチャーなら当たり前→大きい会社
　インフラ：コンサバ
　とらぶる減るとか
　→システム全体が自動化→面白い
・オーぷソース：値段が下がるはプログラマ屋さんにとっては
　たいした差ではない

・SDN：一時期盛り上がり、最近そうでもない
　→なくていいわけではない。使い方はそれぞれ差がある
　　コストダウンをやらなければ負ける。SIerもそう
　　避けて通れないなら、速く触るべき
　　話ちがうといえる。どこまで

・箱がいじれるようになる
　　最近はWebで設定
　　結構前からツールでネットワーク設定あった
　→キャリアが使っている。すげえ高い。技術はあった
　SDNで自分たちで作り始めた

・SDN:
　サーバの仮想環境につくる
　既存の箱をソフトウェアでいじる
　　→限界：APIから許している機能だけ
　サーバーの割りに売上悪い：薄利多売になる
　　→OSいらない→箱だけになる
　　→Linux動く、それでいいじゃん→Open

・安くする→CISCOとか、脱落していく。それ以外は？・・・
　→台湾、中国から買ったほうが安い
　キャリアはオープンにならないので、生き残るが、他はとめられない
　SIer:Openflowから、雪球が転がるように
　ブロケード：身売り

・専門学校　オープンソース学科　だめ
　理由：両親がCISCOが使えるように、PHPが・・
　→どうするんだよ。５年後とか・・
　こうなった状況でまだ止まらない

K標本化とデータフュージョンとか、聞いてきた

3月１８日

人工知能技術コンソーシアム オープンイベント
に行ってきた！ので、その内容をメモメモ
（本文中、AITCとでてくるが、これこのブログの他のエントリで出てくる先端IT活用推進コンソーシアムの
　AITCではなく、「人工知能技術コンソーシアム」のこと）

---

■次世代人工知能技術の社会実装と人工知能技術コンソーシアムの役割
（前のほうは聞けなかった）
・ビデオ　
　　AI：バリューチェーン、マッチング、商品の入れ替えなど
・人工知能技術コンソーシアム
　　ユースケース開発
　　プラットフォーム
　　共通ツール
　　運用ノウハウ
　　（実証の）プロジェクト立案支援
　→カイゼンのループ

・共通認識
　ユーザーがシステムの内部に入った改革
　社会側の起きる現象
　　関数モデル　　　　　確率分布モデル
　　線形・ニューラル　　ガウシアン
　PLASMA,JAVAで実装
　　PLSA　ベイジアンネット

　実世界データからの現象
　　自分でアクションを取れば、因果関係に迫れる

・AIリビングラボ
　KINNECTつけている：人が通ると反応
　　→因果モデル→自己決定
　計算はモジュール化進んでいる
　質の高いビッグデータ
　→バリューチェーン変革

・シェアできるデータ・・コンソーシアムの目的
　評価：効果の推定、デイリーで結果分かる

・HumanLife WG
　課題の見える化、データ化を行う。ヘルスケア

・データ知識融合WG
　ビッグデータ（量的データ）と質的データを複合
　　→人間理解
　PLSAによる顧客タイプわけ

・データプラットフォームWG

・製造業WG
　　機械の導入：データの導入・どう連携をとるか
　　独自のAIの活用方法が見つかれば・・・

・AIリビングラボWG
　デジタルサイネージ等からビッグデータ→スマートホーム

・AIツールWG
　特に確率モデリング、PLASMAの使いこなし

・データマイニングWG

・関西支部
　実証事業

　ニューエコノミー

・ユースケースWG
　あのムービーのシナリオの作り方
　データクリニック

産業技術ロードマップなどでも・・

Q&A　成果はどこで見れる？
・会員さん向け情報提供。外部に対してはメディア、教材（手が足りていない）

---

■ビッグデータ利活用事例３０
　様々な業界の変革にビッグデータ
　人工知能、IoTと深い関係
　　データ取得　IoT
　　データ　　　ビッグデータ
　　流通　　　　パーソナルデータストア、データ取引
　　分析　　　　AI、機械学習
　　デジタルトランスフォーメーション

～２０１５　ビッグデータ　勝ちパターン　一部署のデータ
　　　　　　異常のアラート（不正取引など）
２０１６　　コマツ　KOMTRAX、　　　　　全社データ活用
　　　　　　トヨタ　コネクテッドカンパニー
２０１７～　スマートシティ　　　　　　　複数企業

【社内のデータを活用：IoT】
（１）いすず　トラック故障原因を機械学習で　4万台のデータ
（２）スマートドライブ　運行管理サービス　OBD2
（３）東急建設　トラックに端末、ダンプカーが来たら行けばいいように
（４）トヨタITC　大阪市と運転データ活用、危険割り出し　APIで公開
（５）NTTDocomoの自転車シェアリング
（６）パルコ　顔写真認識で顧客分析、降水センサーによる来店予測（雨：雑貨増える）
（７）テザミス　牛にもIoT　、動けば反応
（８）ソフトバンクがヤフオクドームに新型センサー、球の回転、角度把握
【社内のデータを活用：既存システム】
（９）新生銀行　販売予測にAI予測モデル　５倍の販促効果
（１０）東急カード　PLSA　匿名でクラスタリング　
（１１）ドクターネット　レントゲン画像を人工知能で自動診断
（１２）SanSan　機械学習で名刺のデータ化、費用３分の１、項目分割を機械学習
（１３）オークネットIBS　深層学習で写真から自動車の型式特定
（１４）JINS　BRAIN　似合うめがね　社員＋メガネ合成、似合か判断、教師信号に
（１５）新日鉄住金ソリューションズ　大学の退学を予測
（１６）資格スクエアのサイトビジョン　AIで理解度に応じた学習教材
（１７）ネスレ　コールセンター　WATSON　チャットで答えだす
（１８）シミック　人事　上司と部下の適正
【社外データ】
（１９）JR九州　イベントごとの集客をデータ把握。割安切符販売
（２０）ナビタイム　オープンデータで電車の混雑度
（２１）CCC　テレビCM出稿量で売上を予測
（２２）インディード　ディープラーニングで年収を推定
（２３）TSON　物件情報、販売状況把握、いくらで売れるか
（２４）サイジニア　似たファッションを提案、クラウドソーシングで教師データ作成
（２５）ホンダ　口コミで新しい指標
【気象】
（２６）アパレル商品３日後販売予測　ニューラルネットで
（２７）三菱電機　生産調整　夏売れるところ予測
（２８）ポッカサッポロ　豆腐の生産量　Docomo環境センサーネットワーク
（２９）ポーラ　美肌予報　ブランディングに
（３０）ウェザーニューズ　ゲリラ豪雨の予測でAI活用
今、追加
（３１）スマートシティーで進むデータ共有　札幌市、藤沢市、会津若松市

---

■データ統合プラットフォームの実現に向けて
　いきなり雑談
・BigDataはバズワード？
　グーグルトレンド：アメリカは今は横ばい、インドまだ微増
　　日本は２０１２年にブレイク、２０１３年ピークで緩やかに下がる
　入れ替わるように人工知能、機械学習　２０１４年から

・人工知能
　本、教科書いっぱいある。やってみた系も
　テック系の人は遊びにぴったり。でも実務で使おうとすると食材（ビッグデータ）ない

・ビッグデータ
　サイズが多いが項目が限定的
　協業、連携
・AI for your life
　気の聞いた社会　ささやかなワンシーンの実現にも、協業連携が必要
　ビッグデータの多くは個人情報
・昨今の風潮
　社会が萎縮している：個人データっぽいものは受け取りたくない
　→個人データでないとだめですか？
　　　K標本化→クラスタリング
　　　　　最低K人以上となるマイクロクラスタを大量に生成
　　　統計量を利用：１人ではなくマイクロクラスタ
・特徴
　実在するデータは外に出ない
　K標本化の結果でてきた人は実在しない人＝攻撃できない
　データを持っている人は有利なポジション

・他のデータをあわせる；データフュージョン
　統計的マッチング：双方から似た人をくっつける

・K標本化＆フュージョン
　実際に使ってみれば
　POS-AD
・オープンイノベーション
　近いものなら、作れるのでは？
・データ「で」つながろう

Q&A
・K標本化のKは？
　厚生労働省では１０にする例があるが、様々
　理論的にはKの人数が違ってもデータフュージョンできる

---

■人工知能技術コンソーシアム　共創ワークショップ報告
・目的　人工知能の社会実現
　人工知能
　　検出、評価、省力化、能力開発
　検出
　　見つける、集約コスト、ベネフィット小さいものを、例：文書のバージョン
　評価
　　データを情報に変換、非効率業務の発見、センサー置くべき場所、潜在能力
　省力化
　　サービス領域から人間を解放
　能力開発
　　オーダーメードで能力を習得させる

・CES2017レポート
　CES２つの変化
　　①インターフェースが変わる：音声インターフェース→人工知能
　　②産業構造が変わる：垂直から水平に

・パネルディスカッション
　４つの分類；ほかにマッチング（最適化）があるかも？

　業種をまたぐ目的の設定
　　目の前の課題を解く→主催者側で考える
　　デザインシンキング　クロスファンクション→フラットに話せる
　　課題を持っている人が複数人入ったほうがいい

　インバウンド、地方のほうが待ったなし

　データが間違っている場合、仮説が間違っている場合→高速にまわす

　欧州のAI：インテリジェンス・アシスタント　めんどくさいことを変わってもらう
　　AIを使うのは当たり前、どこに向かうのか
　　AI・・ITは同系列、システムにインテリジェント
　　→プラティカルな方向に風向きが変化した？
　　　アルゴリズムでは差が出ない

　クルマで、壁にぶつけるか、子供に突っ込むか
　　日本：壁にぶつける
　　米国：自分が助かるように
　　中国：突っ込む
　→データに文化づけ、素養が入る：どこのデータかで変わる

　ローカライズ
　　違う答えを出す。ドラえもんはグーグルでは出せない
　　プログラム；人間の相性にあっていない？
　問題意識
　　東京は集中しない
　　地方を見ることは参考になるかも
　　ネットフリックス　１本に１００億投資
　　　→テストマーケティング後、俳優をこう変えたら・・とか検討
　目的変数をなんにするか・・言うまでもなくモデリング
　　多様性のあるモデル
　　統合化と機能限定
　データ連携、下請け？、地域版

画像キャプション生成とかStair Captionsとか

３月１２日

ステアラボ人工知能シンポジウム2017
https://stair.connpass.com/event/48746/

を聞いてきたのつづき。後半

---

■視覚X言語の最前線
・最近の結果
　画像キャプション生成
　キャプションからの画像生成
　ビジュアル質問応答・・まんなかあたりに、アテンション

・コンピュータービジョン勉強会
　MITU2017若手プログラム

・１本目
　世界初の画像キャプション生成論文
　キャプション生成の論文；ディープラーニングの前
　データセットの収集　PASCAL Sentence DataSet
　　amazon mechanical turk
　　フリッカー
　　MS COCO
　パイプライン
　　既存キャプション再利用アプローチ
　　データセットの画像＋キャプションに
　　＜Object,action,scene＞を手作業で付与
　　MRFで推定
　　同じキャプションを検索して利用

　その後の展開
　　２台アプローチが台頭
　　　　どこかの文にある：既存キャプションの検索アプローチ
　　　　新規キャプションの生成アプローチ
　　ディープラーニングによる流行
　　　　画像認識、機械翻訳が深層学習で実現可能に
　　　　参入障壁が低下
　入力してある文から画像生成　ICLR
　　　　黄色いスクールバス、赤いスクールバス
　　　　画像補完なら、既にある
　文からの画像生成に条件付生成
　　　generative adversarial networks(GAN)
　　　生成　　　　敵対的
　　　→ジェネレータとディスクリミネーターに文を与える
　　　自然な画像　　不自然な画像

　StackGAN:２段階のGANモデル
　　１段目でボやっと、２段目でより精細

・VQA
　ビジュアル質問応答を分野として確率
　　ベンチマーク
　　パイプライン
　　ポータル
　VQA:多クラス分類問題
　　なぜには弱い
　２０１７年AIは６１歳：１９５６年のダートマス会議で分野が誕生
　　これからもどんどん皮をむこう
　　弱いAIでイノベーティブ

・GANの動画論文は、けっこうRejectされている
　Acceptされたのもあるけど、チャレンジング

---

■ヒューマンコンピューティングのための専門家発見
・自己紹介
　KDD,IJCAI(いじかい）、AAAIで論文

・品質保証のアプローチ
　専門家の発見：補助情報を使って見つける

・ヒューマンコンピュテーション
　人間と計算機の組み合わせによる問題解決
　例：大量の書籍の文字認識
　　　ビジュアル　クエスチョン　アンサリング→VizWiz
　　　視覚障害者支援システムに人間を組み込む
　実現上の課題
　　QCD、特にクオリティ大切
　　不特定多数の人間：品質保証が大切
　→回答統合、専門化発見、ワークフロー設計

・専門化発見
　正しく回答できる専門家
　　医療について
　洗練された方法
　　検索行動を利用
　　参加者属性を利用
　　問題文を利用

①検索行動を利用
　検索クエリに応じた問題を広告に埋め込む
　検索連動型広告を使うと専門家は見つけやすい
　貢献度の指標を作る

　正解率の推定
　　活用問題　正解未知
　　探索問題　正解既知

②参加者の専門性：属性
　事前テスト・・有効な属性の発見→専門家発見
　　属性だけ聞けばよくなる
　　参加者の属性ベクトルが与えられている・・

③問題文の中身：参加者トピック推定
　問題文生成：トピックモデル・・問題文がどのトピックに
　解答
　今後：協調性を考慮していない　専門家チーム
　データセット：共通なのがない

---

■自然言語処理分野の最前線

　これまで
　　構文解析
　　複単語表現解析
　　述語項構造解析
　Triple scoring task

　ACL2016の傾向
　　採択数
　　　１．セマンティックス
　　　２．情報抽出質問応答
　　　３．解析系
　　ベストペーパー
　　　計算言語学
　　　　言葉の形と意味は関係ない：本当かどうか、統計的に検証
　　　カーネル回帰、Word2Vec
　　そんなにディープラーニングはない
　　　中では使っているけど・・

　構造学習としての自然言語処理
　　１．系列→系列：形態素
　　２．系列→木構造：構文解析
　　３．系列→グラフ構造：意味解析

①系列らべりんぐ（系列→系列　出力空間狭い）
　形態素解析（単語分割、品詞タギング）
　固有表現認識（人名、会社名、場所名）
　LSTM-CNN-CRF
　　単語列をたたみこみに
　　　　　　　　　　　　　Bi-LSTMで→CRF組成ベクトル(2014)
　　単語をWord2Vecで

　可変長文字列→固定長の表現

②構文解析
　シンタックスネット
　前提：依存構造解析（係り受け解析）
　　遷移型：こっち。行動とリデュースがある
　　グラフ型
　ニューラル遷移型　依存構造関係　行動の確率の和が１
　　入力→３層NN→ソフトMAX
　シンタックスネット：全行動系列の確率の和を１にする
　BiLSTM　フィーチャー　リプリゼンテーション
　入力文全体から大域的な特徴量を学習
　dependency Parsing as head selection

③翻訳
　seq2Seq：アテンションに基づくRNN　サブ単語ベースでの機械翻訳


・対話関係：結構ある。機械翻訳先行
・amazon mechanical turk　日本からはX

---

■ステアラボの研究
・データセット：きめ細かい画像認識：花の認識
　　http://flowers.stair.center/ja/

・画像の日本語キャプション生成
　マルチモーダル、クロスドメイン
　動画行動認識
　　→データセット重要

・Stair Captions
　MS Cocoを使っている　５つの日本語キャプション
　クラウドソーシングサービスで
　今日から公開
　http://captions.stair.center/
　NLP2017で詳しく

・Stair　Actions
　動作が動画に収まっている
　公開を検討：NEDOと相談

・応用：Stair Captionsを使った動画認識

・FAQ
　何故データセット：データセットのよさに精度が依存
　何故日本語キャプション：日本語しゃべって欲しいから
　データセット作成：Webアプリで画像見ながら

---

このあとの休憩で用事があったので帰った
最後の質疑応答は聞いていない・・

世界最大の配送会社UPSはなぜ、最短距離を走らないのか

自分の研究に関係するんでメモ

世界最大の配送会社 UPS が効率化に成功した意外な秘策とは？
http://gereports.jp/post/158429014824/ups-dont-turn-left

自分へのメモ
運搬経路問題（vehicle routing problem）

SQLServerをSUSE LINUXで稼動できるようになる話を聞いてきた！

３月１５日、

Suse Expert Days 2017

に行ってきた！の続き。後半の内容をメモメモ

---

■スピードと柔軟性を向上させるためのこれからのIT環境のクラウド化
　・これからのIT環境をどうすべきか
　・IaaSとPaaSの併用で始めるクラウド化
　・これから選ぶクラウドの選定ポイント

１．これからのIT環境をどうすべきか
　２つにわけられる
　(A)今まで出来なかったことを実現する
　　　新規事業：
　　　　Uberはマイクロソフトのクラウド活用
　　　　　　顔認証チェック
　　　→SaaS,PaaSが増えている　例：Office365

　(B)今まで出来ていたことを早く、安く、簡単に実現する
　　　Webサーバーの立ち上げ
　　　　→社内手続き、拡張するのに投資
　　　クラウドでIaaS（リフト＆シフト）

２．IaaSとPaaSの併用で進めるクラウド化
　コグニティブ：同じ人？年齢、性別　サマーランドの入口カメラ

・IaaSで柔軟性とコスト最適化を両立する選択肢
　　SQL Server + SLES HA
　SQL ServerのLinux版

　IaaSで実行環境の構築を自動化
　　ARM（Azure Resource Management)のテンプレートで出来ること
　　　　最適なデプロイ、べきとうせい
　　　　リソースをまたいだ構成
　　ARMテンプレート
　　　Githubでテンプレートを公開

・PaaSで自動運用型Webサイト構築
　　スタジオ　カラーさん

・デモンストレーション
　　Azureの中のLinuxマシン：いま３分の１だが、増えている
　　サブスクリプション：プリペイドカードで買うことも出来る
　　PaaSでも

・エンタープライズクラウド選定のポイント
　スケーラビリティと事業継続性
　セキュリティ・コンプライアンス
　出来なかったことが出来るか→デジタルトランスフォーメーション

　マイクロソフト：いかなる国でもクラウド内の情報を開示しない

　ビデオ

・グローバル規模でのビジネスを支援するスケーラビリティ
　３４の地域でサービス中（３８まで予定）
　地球約５６周分の光ファイバ
　日本で２つのリージョン　SAP　HANA　ワークロード
　Hadoop最適化
　Azure+SUSE+SAP→アビームで

　ビデオ

・マイクロソフトはオープンで柔軟なクラウドを提供します
　デベロッパーセンターでSDKやサンプルを提供
　Azureフォーラム
　AzureOSSコミュニティ・ブログ

---

■Software Defined Storage
　OpenStack最新ソリューション

（ごめん、説明した人の日本語がよくわからなくて？
　聞き取れなかった。適当にコトバが、以下並んでいる）

・トラディショナルなエンタープライズストレージの課題
　　値段高い
　　スケールと管理難しい
　　SDDCむずかしい

・SUSEエンタープライズストレージ
　コモディティサーバーとディスクドライブ
　Cephアーキテクチャ

　ブロックデバイス　オブジェクトストレージ　ファイルインターフェース
　　　　RADOS(コモン　オブジェクト　ストレージ）

　ユースケース
　　Bulkストレージ
　　ビデオサービランス
　　データアーカイブ

・HPCストレージ

・OpenAttic
　　デモ

・ロードマップ


●OpenStack
　なぜ使っていないのか？
　大企業の８１％は使う予定
　９３％はIaaS

・SUSE　OpenStack Cloud
　速くて簡単
　ハイパーバイザーサポート
　SUSE OpenStack7
　OpenStack
　　６つのコア
　　他のプロジェクトもサポート

・SUSE OpenStack Cloud7
　　Day2管理
　　コンピュートノードHA（KVM,XEN)
　　構成サポート：Magnum,Kubernetus
　　ハイパーバイザーの選択とサポート KVM,XEN,Z/VM,VMWare
　　JeOS(じゅーす）ミニマム

・SUSE Open Stack ロードマップ

・SUSE コンテナ　あず　あ　さーびす（CaaS)プラットフォーム

・CloudFoundry

●SUSEが提供する開発ツールチェーン
　SUSEの由来（ドイツ語）
　　Software
　　Und
　　System
　　Entwicklung
　→ソフトウェアとシステム開発

・開発ソリューション
　モジュール式オープンソースソリューションスイート
　Open Build Service(OBS)
　　ソースをOBSに提出
　　パッケージ化して
　　KIWIでイメージ作成→Docker,ISO

　JeOS
　　最小構成ホスト
　　　目的に応じ、それに何かを足す
　　Machinery　高度なシステム管理モジュール

　OpenQA
　　自動テストインフラストラクチャー
　　OpenSUSEとSUSE Linux Enterprise
　　　様々なコードパスとインストールオプションをテスト
　　　アウトプット：ログファイル、画像

　ツールチェーンモジュール
　　新しいコンパイラとツールチェーンを提供する
　　コンテナモジュール
　　　Portusで安全にコラボレーション
　　コンテナとイメージの管理
　　　コンテナアプリを外科的にパッチ
　　　　コンテナとイメージチェック
　　　　セキュリティホール見分ける
　　　　イメージのアップデート

　SUSE Developer Program
　SUSE Linux Enterprise 12 For Raspberry PI
　　ダウンロードできる
　　Raspbianとの違い：カーネル、６４ビット、ブート、ルートファイル

　　

なぜ、機械翻訳が素人考えで、プロは翻訳メモリを使うのか？

「人工知能が変える仕事の未来」を聞いてきた
http://blog.goo.ne.jp/xmldtp/e/6089e0ee0fb3f8734273e8e06acc69ef

で「機械翻訳→経済的に使い物にならない」と書いてある。
この前に、「素人は良く思いつくんだけど」みたいな事を言ってた気がするけど、
じゃあ、プロはどうしていて、

どうして、
　素人は機械翻訳をやろうとして失敗し、
　プロは翻訳メモリを使うのか
について、説明しようと思う。

これを説明すると、今の人工知能の限界が分かると共に、
機械翻訳っていうのが、どんだけ「無茶しやがって」
なのかがわかる。

でははじめる

---

■翻訳のプロは、翻訳メモリを使っている

例えば、あるソフトを日本語化するときとかは、
十印とかに依頼すると思うけど、そこでは
翻訳メモリを使って日本語文が作られる（らしい）。


翻訳メモリ（ほんやくメモリ、英語: translation memory）は、原文と翻訳文を一対としてデータベース化し、その内容を自動的に繰り返し利用することで翻訳を支援する翻訳支援ツールである

Wikipediより

つまり、
　英語を訳すのではなく
　既に訳した文を元に、それを効率的にコピペする。

手順としては
　　はじめに画面などから、いくつかの単語を取り出す

　　それを（場合によっては何人かの人＝翻訳スタッフ各人に）訳してもらう：仮訳

　　訳したものを持ち寄り、違いを見つけ、統一見解を出し、そのように訳す
　　　　用語統一

　　用語統一した単語を、辞書に入れる

　　この辞書に入れた単語をベースに訳していき、翻訳メモリに入れていく

こうすると、翻訳メモリをベースに訳語が統一されたものができる。
用語統一した時点で、プログラムチームだけでなく、マニュアルチームにいったりする

私が関わっていた頃はこんな流れだけど、今は、この分野発展したので、
大きく変わってるかも。今は、TMSになってるのかな？
たぶん、Tradosが有名なのは、変わっていない？
フリーではOmegaTすくしょはここ

---

■そもそも、翻訳には、２つのケースがある

「It's fine today」を「今日は晴れです」と訳した場合を考えよう。

このケースには、２つの場合がある。

（１）日本語を知ったアメリカ人が、「It's fine today」を
　　「今日は晴れです」と訳した場合と

（２）英語を知っている日本人が「It's fine today」を
　　「今日は晴れです」と訳した場合（って、普通こうは訳さないけど・・）

（１）は、
　アメリカの文化を知ったアメリカ人が、
　日本語の知識を元に、
　日本人なら、こういうだろうと「妄想して」
　つけた訳文

（２）は、
　日本の文化を知った日本人が、
　英語の知識を元に、
　多分、こういうことを言いたいんだろうと推測して、
　つけた訳文

　アメリカ人でも、「It's fine today」というのを見たとき、
　　２通りの意味があることは、想像がつくと思う。

　一つは、　「今日は晴れです」
　もう一つは「マイクのテスト中」

　どちらのことを言っているかは、コンテキストからわかる。
　だが、日本の文化で、マイクのテスト中は
　「本日は、晴天なり」というということまでは、妄想できないかもしれない。
　なので、どっちかの訳になる。

　日本人は、日本の文化で知っている。
　なので、コンテキストでマイクのテスト中だと分かれば、
　「It's fine today」を　「今日は晴れです」ではなく
　「本日は、晴天なり」と訳すだろう。
　場合によっては、「チェック・ワン・ツー」と訳してもOKだ。

　つまり、

・文化によって、訳文は違うのだ。

・そして、訳される文化のほうにあわせないと
　訳の意味が変わってしまう可能性すらある

・逆に、意味さえ通じればよいのなら、
　シチュエーションさえ分かれば、
　元の言葉わかんなくっても、OKなときある
　（上記でIt's fine todayを仮に知らなくて
　　チェック・ワン・ツーって訳してしまっても、
　　原文みてない人には、OKだ・・・いわゆる超訳）

---

■なぜ、「機械」翻訳でなく「日本人が翻訳メモリを使って日本語で訳す」のか

機械翻訳は、どういう文化を理解しているのか、さっぱりわからないから。

　英語と日本語の対を学習させたのでは、

　　日本の文化を理解してるのか、
　　アメリカの文化を理解しているのか
　　別の国の文化をりかいしているのか
　　何の文化もりかいしていないのか

わからない。

例えば、神Excelということば、
この言い方は、なんでも神にしてOKな日本だから、ゆるされる。
これをアラビア語にして、イスラム圏の人に行ったら・・・
・・神を冒涜してる！とか言われて、大変なことになりそうです（＞＿＜！）

翻訳メモリを使う話は、実は、翻訳メモリが大事なのではない。
日本人が日本語にする点が重要。

はっきり言って、ソフトなんて、使い方とデータが分かれば、
パネルに書いてある言葉なんて、大体想像つく。
英語が読めなくても・・・

なので、英語は、想起しやすい目印程度でいいのだ。
日本語でつじつまが合うことが重要。
だから、日本人が訳をチェックし、
そのチェックを支援する翻訳メモリをプロが使うということ

はじめに、用語統一するのは、表面的な言葉の統一をしているのではなく、
そのソフトの世界観とか、日本におけるそのソフトの特徴づけとかを
用語を通じて統一してるわけ（カルチャーを統一しているわけね）

---

素人は、翻訳の裏に文化があり、その文化が違うと、
おかしな文になるということを知らないし、
ましてや、文化を理解させるのに、どれだけ学習させないと
いけないかなんて、まだ分かっていないということを知らない
だから、機械翻訳といってしまうけど、

翻訳するくらいなら、日本人がテキトーに画面見て、
言葉つけてったほうが、まだましなのだ・・・

それほど、文化って、影響大きい。
その文化の理解までは、機械翻訳は行っていない。

カメレオンとペンギンが抱き合う動画見てきた！

３月１５日、

Suse Expert Days 2017

に行ってきた！ので、その内容の前半をメモメモ
（表題の動画は、始まる前に流れていたので、
　以下のメモには出てこない
　ちなみにカメレオン　＝SUSE)

追加１２：４５
動画、抱き合うところは

What Does the Chameleon Say? (Ylvis - What Does the Fox Say parody)
https://www.youtube.com/watch?v=VNkDJk5_9eU
の１分５０秒のところで、SUSEっていっているところは、このビデオなんだけど、
前の部分がっていうか、大部分が違う
見てきたビデオは、ホットパッチを当てる話なんだけど・・・

---

■Define your future with SUSE

①SUSEの全体の方向性
　　｜－④クラウド
　－－－－－－－－－－－－－－－ーーーーーーーーー
｜　　　　　　｜　　　　　　｜　　　　　　　　　　｜
②Linux　③運用管理　⑤ストレージ・OpenStack　⑥開発ツール

デジタルトランスフォーメーションを支えるテクノロジーとそれが目指すもの
　Time to Market
　アジリティ
　低コスト
　カスタマーセントリック
　クオリティ、セキュリティ、RAS
　　↓
　オープンソース
　　クラウド、◎コンテナの登場、◎マイクロサービス、aaS、DevOps

　最適組み合わせを見つけてUpdateしていくのは、とても大変？

　SUSEによる「Spftware－Defined」インフラ
　　オープンソースと標準APIで構築
　　オープンソースといいながら垂直統合で囲い込み？
　　SUSEでそろえるのではなく、既にお使いのもの、他社のものも大歓迎
　サーバー、スイッチ、ストレージ
　　カーネル４．４をいち早く採用
　　SAP用、HPC用など、用途別製品
　　～用途のLinux
　Software Defined Everything
　　各種のハイパーバイザーやSDNを幅広くサポート
　ストレージ
　　Cephをベース、ノード単位課金、戦略的価格
　　SUSE自身でストレージを出す
　プライベートクラウド、IaaS、PaaS
　　もっともDeployしやすいOpenStack、HPEさまから開発リソースを買収
　　SUSEがインストール競争で勝つ
　　CloudFoundryにコミット
　コンテナ、マイクロサービス
　　Kubernetes,Magnumに投資
　運用管理
　　SUSE Managet : RHEL,CentOSも管理できるパッチ管理
　　OPEN ATTIC,Salt等

最近のトピック
・オープン　コンテナ　イニシアチブ、
　クラウドネイティブ　コンピューティング　ファンデーション
　Zero Outage（ダウンタイム０）
　Cloud Foundryのボードメンバーに
　パートナーシップ
　　富士通　ハイブリッドクラウド、ビジネスクリティカル、コンテナ技術
　　インテル
　　HPE　Preffered LINUXに
　　SaltStack　自動化

製品
　リリース
　　SUSE　Linux　Enterprise 12 SP2
　　ARM Raspberry Piサポート
　　SUSE Enterprise Storage 4
　近日
　　OpenStack Cloud7(Kubernetes)

SUSE
　２５年前、商用ディストリビューションとしてドイツで
　親会社、マイクロフォーカス
　HPと統合すると＄４B企業へ
　８％の伸び
　SUSEを中心としたエコシステム

オープンソースコミュニティに貢献するには？
　まずはコミュニティエンタープライズの要求を
　The Open,OpenSource Company
　タグラインにこめられたSUSEの哲学
　　We adapt,You Succeed
　逆が多い
　　You adapt,You Succeed

---

■SUSE Linux　エンタープライズ　Server SLES（すれす）最新動向

・デジタルエコノミーの要求：ベンダーロックインされない
　ソリューションの適用

・SLESロードマップ
　　SLES 11 SP4　２０１５年７がつGA　２０１９年
　　SLES 12 SP1
　　SLES 12 SP2
　１２　カーネル４．４　SP3開発中
　ライフサイクル：１０年標準、３年拡張
　勝手にSP2にはあがらない
　HPC・・・ARM　SP3で
　12SP2　カーネル４．４
　　→HPCとミッションクリティカル中心
　NVDIMM,XEN4.7,TPM2.0,GNOME3.20
　SUSE LINUX Enterprise for ARM
　　ARMを使ったHPC事例
　１２SP3
　SUSE コンテナ　AS A サービス　プラットフォーム

・KIWI(きゅーい）
　Workload/OS Image Templating
　→イメージを作る
　→外向けにしたのがSUSE Studio
　　オンライン版あり、アカウント作って
　　ラックスペースなどが利用
　JeOS(じゅーす）とコンテナ

・マイグレーションユースケース
　オンライン・マイグレーション・パス
　　オンラインで挙げることもできる
　　　→ワンステップごと？スキップする？：注意いることも
　オートメーション：メディアから

・フットプリントを軽く
　１２から考え方変わる
　　ベースOS:コアOS　その他：エクステンディット（メディアに入っている）
　HPCモジュールも別だしで
　　→OPEN HPC　ファアンでーション

・SUSE　HPC　スタック
　カーネルはSUSE中心、
　ハードやツールはパートナー様中心

・パッケージハブ

・ゼロダウンタイム：btr（ばたー）fs→スナップショット取れる、元に戻せる
　スナッパーが動いている

・ダウンタイム減らす
　　SAP HANA 4Tのメモリ：リブートすると１時間
　　ライブパッチング：カーネルのAPIが呼ばれる部分で切り替え
　　KPatch,Ksplice,KGraft
　　　　１年に1回定期メンテナンスのときだけ、リブートはいる
　　Oracle KSpliceとSUSEのKSpriceの違い
　　　買収されてなくなることない→オープンソースだから
・HA：業務継続性
　　Hawk2（ふぉーく）デフォルトの管理画面
　　AWS Fencing agent（将来Azureも→別にAzure組めることは組める）

・SQLServer:Linuxの上で
　ORACLE RAC必要ですか？
　Exadataでなくても、AzureのDBでよくないですか？

・SAP
　ダウンタイム減らす
　SAP HANAに特化したファイヤーウォール

・Page Cache Limit
　HANAのパフォーマンスをあげるためではなく
　処理パフォーマンスのデグレードを防ぐ
　　S/4 HANA Windows→Linuxへ（Azure多い）

・SALTで自動化
　SUSEマネージャー　サテライトベース
　サードパーティーをつなぐプラグイン
　SUSEマネージャーエコシステム
　何が問題
　　スケール◎ここ問題
　　並列化
　　Express
　SALT：並列性を挙げる軽いスケールアウト対応
　　スペースウォークから
　　SALT Masterキー
　　Minion端末
　SUSEマネージャーを使い、自動化部分はSALT

メモリ付ニューラルネットとかアテンションの仕組みとか聞いてきた

３月１２日

ステアラボ人工知能シンポジウム2017
https://stair.connpass.com/event/48746/

を聞いてきた。まずは、一番初めの論文紹介をメモメモ
（論文紹介は４人ある。そのうちのはじめの先生）

---

■ごあいさつ

■最近の重要な論文の紹介－テキストとの対応づけによる映像の理解に関連して－
中島先生
・これまでの研究
　映像に関するアテンション
　ディープセマンティックフィーチャー：要約、プライバシー
・映像の表現

紹介する論文
・アテンションの仕組み
・メモリ付ニューラルネット
・Adversarial Examples

・アテンションの仕組み
　アテンションの利用例
　　画像・映像・テキストをエンコード
　　時間（？）的に変化させる場合も
　アテンションの基本的な仕組み
　　画像→ＣＮＮ（たたみこみ）→位置が残るところでやめておく
　　言語→ＬＴＳＭ－－－－－－－－↑

　応用
　・翻訳、変換的なタスク
　　画像・映像のキャプショニング　言語観翻訳
　・Visal Question Answeringのタスクでも
　　単純な作業では実はよく内面もありそう
　　言語しか見ないと正しく出るが、画像を入れるとよくないことも
　画像理解に向けた可能性
　　人が映像を見るとき
　　外部情報のようなものはない？それでも人は、どこかに着目している

・メモリつきニューラルネットワーク
　　　Differentiable neural computer(DCN)
　ＤＣＮのすごいところ
　　読み込み、書き込みの仕組みもすべて微分できるカタチ
　　メモリの読み込み、ソフトアテンション
　　メモリの使い方も学習する
　塩蔵理解で役に立ちそう？
　　ＲＮＮタイプのネットワークは本当に「メモリ」として働いているのか／役に立っているのか
　　３Ｄ－ＣＮＮのほうが性能がいい
　　Mean/Maxプーリングでも性能に大きな変化がない
　　シーン、人物を記憶する外部メモリの可能性
　　　もっと単純なネットワークがいい？学習が難しそう

・Adversarial examples
　人には分からないくらいのノイズを画像に足しただけでＤＮＮは簡単にだませる
　→ＤＮＮの線形性が問題
　　新しいロス関数として、ｘとＸばーのロス関数をあわせたものを使うと汎用性能が上がる？
　映像関連のタスクを考えてみると・・・
　　映像は似たようなフレームばかり、データ数もそんなに多くはない
　使えるデータセット・・・（時間切れでせつめいできず）

「家庭用IoTの8割は失敗に終わる」

ま、そうだろうな・・・
HEMSを導入しているようなところが、発電量を見たいとか、そういうのはあると思うけど、
あえて家電を自動化しなくても・・・

「家庭用IoTの8割は失敗に終わる」大胆予測の根拠はどこにあるのか
http://www.sbbit.jp/article/cont1/33346


多くの人が見てくれているようなので、
このニュースを追加（＾＾；）

シャープ、メニューの提案やねぎらいの言葉もかけてくれる“IoT冷蔵庫”
http://kaden.watch.impress.co.jp/docs/news/1049357.html
目の付け所がシャープ？？

「人工知能が変える仕事の未来」を聞いてきた

３月１３日、

2017年3月期　AITCセミナー&AITCオープンラボ
～人工知能が変える仕事の未来～
https://aitc-seminar.connpass.com/event/51616/

を聞いてきたので、その内容をメモメモ

---

■AITCの紹介
　Javaコンソーシアム
　XMLコンソーシアム
　AITC

　第7期　部会
　共同：機械学習　IoT

■人工知能が変える仕事の未来
・５００ページ読みきった
　メディアの人は本質的なことを理解していない
　　→構造的な知識
　本当の人工知能を理解しましょう→ほかにはウソが書いてある

　元旦の日経朝刊写真

　人工知能
　　１位、２位はオライリーのHowTo本
　　→やった、うごく、よかったね、So What？
　　　テンソルする？それも違う・・
　　ディープラーニングの計算量：限られたケースしか証明されていない
　　→エンジニアリング的

　カーツワイル：科学者ではない。Googleの社員でもない
　　→刺激のためにしゃべってもらっているだけ
　そもそも、アメリカに共通の常識がない：進化論知らない
　　→生物が自分で自分を進化させたように、人工知能も進化する？
　AIを死刑にする？
　３Dプリンタで銃暴発：バグあったかも？プリンターメーカー？インク？
　　→温度が一定温度以下→むらができて、暴発した

　科学：説明できないといけない、ある程度で正しい
　　意識とか説明できない

　飛行機：どうやって飛べてるか未解明→でもいいじゃん！工学
　　AI学会：科学と工学の区別
　　AIはデータ次第
　　情報システム室部員のためのAI講座
　　　アクセンチュア、ガートナー
　　　AIに対する１０の誤解

　エンタープライズ
　厚生労働省の科研費
　行政情報システム研究所：自治体におけるAIの活用

　ソースコードは１行も書かなくても
　正解データ作りで高くなる
　→あとから請求する会社もあるけど・・

　自己紹介

　wordnet
　イメージネット
　　　名詞：写真をマッピング
　２０１２年　１０００枚の画像認識
　→共通の制度評価指標

　GHPの最大化

　ディープラーニングの本質
　 End to end コンピューティング
　　生データコンピューティング
　　→ディープラーニング万能と思ってはいけない
　　問題は答え・・ではなく、その直前
　　　情報を捨てている→特徴を残す（予定調和的に）
　　６X８ピクセルのRGB画像

　　スーパー　
　　　１分おきに、３０００店舗、フル監視
　　　→いままでやれてなかったサービス

　　２０３０年は、いまより人手不足になる

　医者に眼底の検査：１００円しかもらえない
　　→精度：６８パーセント・・・１００円じゃ～ね～

　わいふ２X（アップコンバーター）

　どれをやるか
　　対話型ロボットなども、どの目的、局面で、制度がどれだけ必要か
　　要求段階から数値評価
　　　精度評価しやすくなった
　　　日本語OCR　９９．５％→精度低い
　　機械翻訳→経済的に使い物にならない
　　　いらいざよりも退化している

　　危険運転の疑いをかける　５０％→もうかる

　問題
　　・精度が予測できない：実験しないと・・・

　エレファンとなテクノロジー
　　病理画像からディープラーニング用：スーパーコンピューター
　クラウドソーシング

　正解データづくりにシフト→人間がデータ作っている
　　　責任分解点の問題

　みるとーく：企画会議が終わるまでに答えかえってくる

　何猫マッチング：合コンに使う
　　→写真をとる、
　API化すると・・・奇天烈なアプリを考える

　AI導入したら・・・欧米に追いつかない、差がつけられる。

AIポジショニングマップ
　失注理由
　自動分類
　　１０万語の日本語語彙を１万の意味カテゴリに
　　　　LDAを使っている
　　類似度

Q&A
・画像認識はAIと読んでいいか？
　ディープラーニングはAIでない？
　→そもそも、第二次AIブームは、ニューロはAIではなかった

　RPA　ロボティクス　プロセス　オートメーション
　　→非効率な業務フローを固定化する可能性あり

　ライセンス：データをアップデート
　　学習済みモデルの著作権
　　→主語と述語だけでは著作権？

　人間のようなAI？

　監査・検査　１００％をもとめる
　　ちばれぽ
　切り口違う
　　ダベンポート先生もデータデータにかわったし・・

「週刊 鉄腕アトムを作ろう！」

創刊号は４月４日　講談社

自宅で作れる「鉄腕アトム」販売へ　ＡＩで会話も
http://www.asahi.com/articles/ASK2Q4J27K2QULFA00J.html