英語を上達させるには 〜インプット編〜
どうも、ITコンサルタントのShoheiです。
最近電車で社会人向けの英語教室の広告をよく見ますね。
以前こちらの記事でグローバルで働くことについて説明しましたが、いずれの形であれ、社会人になってからも英語力を向上させたい人は多いようですね。
今日は、グローバル人材の端くれである自分が、自分の思う英語の極意について述べて行きたいと思います。
ここでいう英語力とは
本編に入る前に。ここで言う英語力はTOEICの点数ではありません。
僕はこう理解していますが、TOEICの点数だけで英語能力を見てしまうとTOEICのお勉強で手に入れた小手先のTOEIC力が含まれてしまうので、真の英語力は見抜けなくなります。
実際、「TOEIC970点なんす！ (俺天才っしょペラペラやでﾃﾞﾚｼｼｼｼ)」て言うやつと国際の電話会議に一緒に入りましたが、そいつは何か話題振られても大体理解できずに黙ってました。
確かにTOEICの点数と本当の英語力と相関があるかもしれませんが、高いから真の英語力が高いとは言えません。
上述のように小手先で200点ぐらい伸ばして自慢してるだけで、実践では役に立たないゴミもいますからね。
僕がいう真の英語力は、真の読み書き聞き喋りの力です。
とりわけ、翻訳ソフト等が使えず真の実力が如実に出やすい、リアルタイム英会話の力を僕は重視しています。
リアルタイム英会話力を向上させよう
英会話。大きく分けるとインプット(聞くこと)とアウトプット(話すこと)ですよね。
インプット= ①音声を言葉として識別して②言葉を意味に変換する
アウトプット= ①伝えたいことを言葉に変換して②言葉を発音する
僕は上記のように理解しています。
今日はインプットの作業を以下のように分解して、それぞれについて向上させる方法について考えて見ましょう。
①音声を言葉として識別する
これは、なんとなく聞こえてくる音の羅列を聞き取るフェーズです。
単語の意味は知らなくてもいいし、相手が言ったことを再現する、それさえできればここは勝ちです。
ただ、これってなかなか難しいですよね。単語の意味とかは知ってるのに実戦だと聞き取れなかったりする人も多いのではないでしょうか。
さて、それが出来ないのは何故か、そしてどうすれば上達するかを思いつくままに書いていきます。
・1つ1つの発音が分かっていない
sってこんな音、lってこんな音、とか、aの母音にこんな音がある、てのが理解できていないパターンですね。
例えば、lackとluckとlockとrackをうまく聞き分けられますかね。
もちろん上記の違いは文脈でも判断できますが、正確に聞き取れるにこしたことはないのです。
これを鍛えるには、発音記号一つ一つ理解して、自分で発音して解明するのが一番早いと思います。
例えば"s"の発音は下と上の歯をしっかり閉じて息を出します。そのとき、喉に手を当てて見てください。震えてたら違います。喉が震えてたらzです。
次に、sを発音しながら少しだけ歯と歯の間に隙間をあけます。そうするとthinkのthの発音になります、といったように。
まずは、一つ一つの発音を知って、自分で再現できるようになり、識別するところから始めましょう。
・単語のアクセントが理解できていない
例えば、important。読み方を、インポータントだと思い込んでる人は、正確な発音が相手から飛んできてもピンときません。
日本語でもイントネーションが全然違う地方の言葉だと聞き取れなかったりしますもんね。
これは少し単語のアクセントにも注意を払って単語を覚えることで克服できます。
・単語と単語の繋がり部分で見失っている
英語と日本語の違いの一つに、英語は日本語と違って子音+母音がセットでは無いという点があります。
日本語でありがとうは a-ri-ga-to-uと必ずセットになっています。
なので単語と単語が混ざって発音されることはほとんどありません。
英語は違います。 passは pa-suのように発音するのではなく(本当はæですが）、pa-sと、sのあとに母音がきません。
なので、もしpassのあとがaのような母音であれば、pa-s-a→pa-saのように混ざって発音されるのです。※意図せずとも、正確に、sのあとに母音をつけずにそのままaを発音すると混ざります
pass an examをぱす あん いぐざむだと思っているところに、ぱさにぐざむというように正確な発音がくると、なんのことだろうと混乱しますよね。
この原則を知って、自分でも発音してみると、英語の響きが見えて、聞き取りもしやすくなると思います(発音もカッコよくなりますよ)
・文章のイントネーションで混乱している
My name is Shohei. これの文章で強く読まれるのは、Shohei、次にnameです。
英語のリズムと強弱のコツがわかっていないと、ときに混乱します。
ただ、この項目も重要ですが、それよりも上で述べてきた３項目の方が重要なので、まずは上の３つの克服からするといいかと思います。
自分には何も得がないけど宣伝
このへんは、この本がめちゃめちゃめちゃめちゃおすすめです。
自分はこの本で音声学を勉強して、発音がまぁまぁよくなったと思います。
おすすめ。
②言葉を意味に変換する
これは、当たり前なんであんまり深くは書きません。
先ほど聞こえてきた パサニグザムをpass an examと変換し、意味を理解することです。
ここで初めて、音から単語を識別し、単語から意味を識別する能力が必要となります。
これは中高でよくやってきた勉強、単語・熟語・文法を知っているかという世界になってきますかね。
一つだけ、僕が勉強するときに注意していることは、和訳しないということです。
apple→りんご→赤くて食べれるやつと変換してては、英語脳になっていません。
appleと聞いた瞬間にジュルリとなれるよう、英単語ともののイメージを直結させることが重要となります。
僕がずっと使っている単語アプリでは、必ず英単語とともに単語の絵がでてきますが、そういうのを活用することで単語とイメージを直結させましょう。
おすすめの勉強法
文章を3回シャドウィングしたあとに、1回聞く、というやり方で僕はよく鍛えていました。
まずは言葉を聞いて、少し遅れて発音。発音もイントネーションも全て真似しながら発音します。音声に追われるのではなく、必ず自分の言葉で発音できていると思えるまでシャドウィング。
そしてその後、シャドウをやめて見て、英語を聞く。英語がすっと入ってきて意味がイメージできたら勝ち。
こうすることで、上述の①②をまとめて鍛えるトレーニングをしていました。
まとめ
リアルタイム英会話力におけるインプット能力の内訳と、鍛える方法について書きました。
完全に自分流ですが、ぜひみなさんも試してみてください！
原爆と科学 〜計算機の倫理〜
どうもhaseです。
今日はサビマネの話をする予定で、記事を書いてました。
でも被爆三世の僕が今日担当になったことに運命を感じざるをえないので、ちょっとだけ真面目に戦争の話をしようかなと。ブログの趣旨からは少しずれてしまうかもしれないけど…計算機に絡めるから許して笑
8:15
さて、広島県民であれば、1945/08/06 08:15という数字はなんの苦もなく出てきます。広島の学校なら毎年嫌という程聞かされる数字だし、僕の祖父のように実際にキノコ雲を見て、黒い雨を浴び、家族を亡くした人が身近にいたりするのです。忘れようがないですね。
広島にいると8/6には、街中になんとなく特殊な悲しみというか連帯感のようなものが流れているのを感じますが、去年今年と東京で過ごしてみると、あまりの何もなさに驚きます。
でも私自身、大事件でも自分に関係なければ日付なんか興味ないし、調べてみようなんて思わないもんなあと妙に納得する今日この頃。まあ、だからこそ逆に書いてみるのもいいのかなと。
ヒロシマ
原爆のことあんまり知らないっていう人もいると思うので、まずはちょっとだけ広島原爆の話をしましょう。
昭和20年(1945年）８月６日午前８時１５分。
人類史上最初の原子爆弾が、広島に投下されました。原子爆弾は、投下から４３秒後、地上約６００メートルの上空で目もくらむ閃光を放って炸裂し、小型の太陽ともいえる灼熱の火球を作りました。火球の中心温度は摂氏１００万度を超え、１秒後には最大直径２８０メートルの大きさとなり、爆心地周辺の地表面の温度は3,000～4,000度にも達しました。
爆発の瞬間、強烈な熱線と放射線が四方へ放射されるとともに、周囲の空気が膨張して超高圧の爆風となり、これら３つが複雑に作用して大きな被害をもたらしました。
原爆による被害の特質は、大量破壊、大量殺りくが瞬時に、かつ無差別に引き起こされたこと、放射線による障害がその後も長期間にわたり人々を苦しめたことにあります。http://www.city.hiroshima.lg.jp/www/contents/1111637106129/index.html
1945年末までに広島で14万人（長崎で7万人）以上が亡くなったといわれます。当時の広島市の人口が35万人ですから、街の半分の人がたった一発の爆弾によって命を奪われたわけです。"1945年末までに"という表現にも原爆の怖さが現れていて、爆発による一次被害に加え、放射線による二次被害によって亡くなる人が大勢いたということを表しています。
ちなみにフェルミ推定で有名なフェルミさん。死の床においても点滴のしずくが落ちる間隔を測定し、流速を計算していたと言われる人物ですが、彼は広島・長崎に投下された原爆を開発したマンハッタン計画において、中心的な役割を演じた天才物理学者です。かのアインシュタインも原子爆弾の開発を提言する手紙に署名するなど、著名な科学者たちが関わった原爆開発ですが、核分裂という科学者たちの偉大な発見が最初に人類にもたらしたものは、たった一発の爆弾で14万人を殺戮するという人類史上最大の汚点になったわけです。（フェルミ・アインシュタインは後に、原水爆開発に反対する立場をとります。）
原爆と計算機
ここで、マンハッタン計画に多大な貢献をした人物がもう一人います。
情報工学を専攻していた学生で知らない人はいないでしょう。
現在のほとんどのコンピュータの動作原理である「ノイマン型コンピュータ」の開発者です。アラン・チューリング、クロード・シャノンらとともに、現在のコンピュータの基礎を築いた功績者とされています。
ノイマンは「爆縮レンズ」（長崎型原爆の中心となる技術）の開発を担当しますが、当時、コンピュータが実用化に至っていなかったため、開発のための計算をノイマンら計算が得意な数学者らの手によって10ヶ月以上の時間を要して計算されたとのこと。この時の経験がのちのコンピュータ開発の大きな動機の一つになったことは間違いないでしょう。
彼は間違いなく天才でしたが、過激な思想も持ち合わせていたようで、ソ連のスパイだったクラウス・フックスと水素爆弾を共同で開発していたり、日本に対して原爆投下の目標地点を選定する際には「京都が日本国民にとって深い文化的意義をもっているからこそ殲滅すべき」だとして、京都への投下を進言したそうです。このような側面を持つノイマンは、スタンリー・キューブリックによる映画『博士の異常な愛情』のストレンジラヴ博士のモデルの一人ともされています。（wikipediaより）
計算機と戦争
計算機と戦争との接点をノイマンというコンピュータの生みの親と結びつけましたが、そもそも、一般的に最初のコンピュータと言われるENIACは（どれを最初とするかは諸説あるようです）、砲撃の弾道計算の目的で開発され、 完成後水爆の研究に使われました。
計算機黎明期の研究は砲撃の弾道計算から始まり、敵国の暗号解読、兵器開発に関わる微分方程式の解析などに費やされ、計算機は戦争のために作られたものだと言い切ってしまっても言い過ぎではないでしょう。
戦争と計算機は切っても切れない関係にあるわけです。
シンギュラリティの倫理
2045年にくるというシンギュラリティ。（ちなみにシンギュラリティという言葉を技術発展の文脈で初めて使ったのは、ノイマンさんらしいですよ）
戦争のために作られた計算機が、今では人々の生活を豊かにしています。
でもIoTやらAIやら、今まで以上にITが現実に及ぼす影響力が増していく中で、僕らITに従事する人間たちは、第二のフェルミ・アインシュタイン・ノイマンになる可能性を秘めている、と少し大げさに思うわけです。
フェルミ・アインシュタインが最初に関わっていた段階では、彼らは自分のしていることを正しいと思ってやっていたはず。（実際、ナチスドイツが原爆の開発を進めており、先に完成させるのではないかという危機感があった）
それでも彼らはのちにそれを後悔している。
彼らのような人類史に残る天才にさえ、原爆の開発を止めることはできなかった。
今までは原爆などの兵器を開発することを助ける手段だった計算機。
しかし今では仮想の世界からどんどん飛び出して、現実への影響力を強めています。
そしてシンギュラリティが現実味を帯びていく中で、僕らがほんの一部でも関わったAIがIoTが、サラ・コナーを殺しにいく未来がくるかもしれない。
そう思うと少しだけ気が引き締まる思いです。
科学者の倫理が問われる今日という日に、少しだけちゃんとしようと思ったhaseでした。
8/9 11:02（長崎原爆の投下時間）には少しだけ原爆のことを思い出してもらえると嬉しいです。
【最終回】DODA体験記③ - ITコンサルへの転職 -
どうも、Keiです。
いよいよDODA体験記も今回で最終回です。
前回の2回では、DODAの簡単な説明から面接練習までを書きました。
まだ見ていない人はぜひぜひ見て下さいね！
最終回となる今回は何を書くかというと、実際の面接の内容についてです。
まず結果から言うと、ITコンサルの内定をもらいました！
3戦1勝という辛い結果となりましたが、主要6社の中から内定をもらうことができました。（主要6社については、DODA体験記②を見て下さい）
今回は3社受けた中で、面接の中で聞かれたことや感じたことについて書いて行きます。
ぼくの情報まとめ
学歴：大学院卒理系
社会人歴：4年目
職業：インフラエンジニア
内定までかかった期間：一カ月＋1週間
DODA登録後のスケジュール：
もちろん 3社受けたので、1回目の面接から最終面接まで他にも面接を受けています。
こうして見ると、DODAの登録から最初の面接までのスピード感はすごいですね。DODA側としてもエージェント自身の給料や出世のためにやっているとはいえ、早く転職をしたい！という人にとっては助かりますね。
面接で聞かれたこと
今回の活動では、 5回の面接と1回のWebテストを受けました。
面接の回数自体はそこまで多くはないですが、聞かれて困ったこと、感じたことを書いて行きたいと思います。
まず、全ての面接は次の流れで行われました。
1次面接と最終面接に限らず、だいたい同じでした。
- 今までの業務内容
- 志望理由
- マッチング
- 応募しているポジションの業務説明（企業側から。マッチングの一部）
- ケーススタディ（1次面接で1回だけ）
このように、始めに自分のこれまでの経験と企業に入ってからやりたいことを聞いた後に、それが本当に応募しているポジションと合っているか3のマッチングで確認します。
具体的には、質問形式で下のような質問をしました。
「その経験活かせないかも知れないけど大丈夫？」
「〇〇企業の方が君のやりたいことできるんじゃない？」
「グローバルで活躍したいってどういう意味で使っている？」
「今より激務になると思うけど大丈夫？」
グローバルの意味については偶然にも下の記事が役に立ちそうですね。
また、4にある企業側からの業務紹介はマッチングに含まれると思うのですが、企業側が応募者を気に入った時に、より深いマッチングのために行う気がしました。
相手の興味がないことが伝わる面接は本当にツラいですよね泣
最後のケーススタディは、コンサルだと当たり前に出るそうですが、僕の場合は1社のみしかありませんでした。
（この面接はケーススタディ含めて2時間の長丁場だったのでどっぷり疲れました・・）
ご存知だと思いますが、ケーススタディは大きく以下の2つに分けることができます。
- フェルミ推定型
- 提案型
「 フェルミ推定型」はよくある、"日本の電柱の本数を予想せよ"みたいな問題です。知っているか知らないかを問う話ではなく、論理的に仮定しながら、どのように実際の答えに近づくことができるかを試しています。
「提案型」は、"この消しゴムを1000円で売ってください"のような5分から10分で面接官に提案をする形式です。
僕の場合は「提案型」で、クライアントのITインフラの現状が書かれた紙をもらい、応募しているポジションのコンサルになった体で、面接官にプレゼンをするというものでした。
プレゼン後に面接官からの質問タイムとなり、その1つ1つにも丁寧に答える必要がありました。
このような「提案型」は、クライアントに提案する際に「コスト削減」と「商材の単価を上げる」の大きく2軸があるのですが、個人的には「商材の単価を上げる」ためにクライアントも気づかないような潜在的なニーズにアイディアを出せると面接官の評価が上がる気がしました。
面接官も一般的な回答だけでは飽きてしまうので、論理のほころびを探そうと意地悪な質問が多くなりますが、 面白いアイディアがあると興味本位な質問となり議論に発展できる可能性があります。
DODAを使った転職活動を終えて
エージェントによる話かもしれませんが、DODAのエージェントは丁寧に話を聞いてくれる人が多い印象を受けました。
また、無理やり転職先を押し付けてくる人はあまりいませんでした。1人いましたけど、、笑（パート①参照）
特にぼくはDODAのBRSという外資系を専門にしているエージェントを利用しましたが、日本で働いている外国人にとっては非常に良いと感じました。
一方で、日本人で外資を受けようという場合はわざわざ英語しか話せないエージェントと話すよりは、日本人のエージェントで良いと思います。外資の人事は日本人の場合が多いため、BRSのエージェントとあまり意思疎通できていない印象も受けましたし・・
（個人的に英語で転職活動をした経験は非常に面白かったですが）
もう一つ、DODAに求める最大の不満は専属のエージェントとBRSのエージェントで意思疎通も情報の共有もできないことです。
パート①で、DODAでは登録をすると絶対に専属のエージェントが1人つくという話をしましたが、BRSのエージェントと転職活動を始めたところ、専属エージェントから電話があり「BRSでなく、こちらから申し込んでもらえればよかったのに・・」とのことでした。
こちらとしても、エージェント同士の仕事の取り合いに巻き込まれるのは気分が良いものではないので、改善して欲しいと思います。
最低でも情報共有くらいは・・・
さて、いかがでしたでしょうか？
この記事が転職を考えている人のお役に少しでも立てれば非常にうれしいです。
ではでは。
AIの音声に恋をするかもしれない
どうも、Koheiです。
気が付けば8月ですね。
今日はこんな記事があったので紹介します。
英語の記事ですが、ざっくりいうと
Google Duplexというgoogleの新しいサービスがturing testというものをクリアできるのか考察しています。
真新しいキーワードばかりなのでそれぞれ説明してきます。
Google Duplexとは
2018年夏の開発者カンファレンス Google I/O にて、googleが発表したgoogle アシスタントが自分の代わりにレストランに電話して予約してくれるサービスです。
デモ動画がこちら
女性がgoogleアシスタントに「予約しといて～」ってお願いすると
なんとGoogleアシスタントがお店に電話して、予約の時間や人数を回答しています。
お店との対話もいい感じです。
すげー
受け答えがすげーってのもそうですが、これができると何がうれしいって
・お店の時間外でもアシスタントにお願いしとけば、指定時間にお店に電話して予約してくれる。オンライン予約非対応のお店でもok。
・本人がしゃべらなくていいのて、海外でもその国の言語で予約してくれちゃう
がさらっと実現できていることですね。
チューリングテスト
Turing testについてWikipedia先生に聞いてみると下記のとおりです。
チューリングテスト（英: Turing test）とは、アラン・チューリングによって考案された、ある機械が知的かどうか（人工知能であるかどうか）を判定するためのテスト。
つまり機械がどれくらい人に近いかを評価する方法です。
やることは単純です。
判定者が一人の人間と一つのコンピュータとどちらかわからない状態で会話をします。
そこで、会話の相手が人だったかロボットだったかを当てます。
ここで判定者が人と機械を正しく判別できなければ、機械は人間同等の知能を持つと評価するわけです。
コンピュータがどれだけ人間を真似られるか、が焦点になります。
判定者の30％をだますことができれば合格と言われています。
ちなみにこのチューリングテストですが、
2014年にウクライナ在住の13歳の少年になりすましたプログラムが初めてチューリングテストをクリアしたと話題になりました。
ただ判定対象がウクライナ人にとっては第二外国語の英語を使用、かつ13歳の少年だった、ということもあり、まだまだ自然な会話を実現するには課題があると評価されていました。
Google Duplex はTuringTestをクリアすることができるのか？
さて、では記事に戻ってみましょう。
記事の中ではGoogle DuplexがTuring Testを クリアできるのかという点では、
「美容院の予約」という1つのジャンルに対しても膨大な時間の学習が必要であり、まだ合格しないだろうと言われています。
ただ、“Mmm-hmm.”といった通常は意味をなさない間投詞を使い、時間をかけながら着実に各シチュエーションを学習しており、テストを合格するのは時間の問題で、いずれ音声AIに恋する世界すらくる、とまでコメントしています。
おそらく会話するお店の種類によって、質問事項も変化しますし、地域や言語によってかなりのバリエーションが発生するので、大量の学習パターンが必要になるのは間違いないですが、大量のデータと計算資源を持つGoogleなら、そう無理な話でもないように感じます。
AIに恋する時代。。。なんてことも現実味を帯びてきています。
さて、そんな夢のような世界を現実にするGoogle Duplexですが
ある一つのことが話題に上がり、議論になりました。
AIアシスタントがお店に電話する際に自らをAIだと名乗るべきか、という点です。
人と変わらない音声というのは、悪意のあるユーザによっては脅威になります。
誰かがどこかの企業にいたずら電話をかけるプログラムを作ることなんて簡単にできますし、誰かをだますこともできるかもしれません。
人に近づくにつれ、AIの倫理の問題がいよいよ浮き彫りになってきます。
人工知能と倫理
このような動きに対して、Googleは 2018/6/7にAIに関する基本原則を下記の通り掲げています。危害を加えるような軍事利用やプライバシーや人権を侵すことに利用しないことを明記しています。
日本でも総務省がAI社会推進に向けて、社会的・経済的・倫理的・法的課題の議論が進められています。
AIの普及がますます広がっていく中で、自動運転でも話題になっていますが、倫理的な観点を抑えながらAIを活用していく必要があります。
今後もこのあたりの動向については、引き続きチェックしていきたいと思っています。
では、今日はこのあたりで
ではでは
CASBとは 〜クラウドを使った業務を許容するために〜
どうも、ITコンサルタントのShoheiです。
みなさん、CASBって知っていますか？ 僕は知らなかったです。
Service Provider側よりも、サービスを使う側の方が馴染み深い用語かもしれません。
今日は、そのCASBについて、ざっくり説明していきたいと思います。
CASBって何？
CASB。Cloud Access Security Broker。キャスビーって読みます。
これはざっくり言うと、クラウド、とりわけSaaSを安全に使うためのセキュリティ機器です。
この、安全にの考え方が他のセキュリティ機器と若干違うところが面白いと僕は思います。
※SaaSって何？についてはこの記事に記載しているので、説明が見たい方はそちらを参照ください。
許されつつあるSaaS利用
最近は自社でシステムを作り込んだりするのではなく、SaaSを契約して既にできているものをサービスとして使うことが増えてきました。
例でいうと、以下のような感じですかね。
- チャットシステムは自社で作り込んでいた ⇨Slackを使い始めた
- 会社では禁止されていたが勝手にSlackを使っていた ⇨会社公式でSlackを使うようになった
- メールは社内でサーバをたてて管理していた ⇨ G Suiteで独自ドメインをとってgmailを利用するようになった
- 営業成績はエクセルで管理していた ⇨ Salesforceを利用するようになった
さて、どうしてこういう動きが起きているのでしょう。
社内のデータは社外に出さない、がポリシーだった
以前は、社内データは全て紙で管理して機密情報は金庫にいれて一切社外に出さない、という時代でした。
ビジネスで扱うデータが全て電子化してからは、インターネット接続可能なPCからも社内の機密情報が閲覧できるようになったものの、ここでも重要なデータは会社管理のサーバに保存する、というのがポリシーでした。
SaaSを利用すると言うことは、そこで扱う情報が全て他社のサーバに保存されるということ。
例を言えば、社内のメールから機密情報をgmailに送ることは、社内のサーバ内で閉じて保管されていた機密情報が、google社のサーバ上に転送されるということです。
社内のデータは社内管理のサーバで管理するんだ！というポリシーからすると、とんでも無いことをやっていることになります。それはSaaSなんて許されなかったでしょう。
進むクラウド利用
さて、上で話したお話は過去の話です。
今後のクラウド利用の予測について、総務省の平成30年版情報通信白書から引っ張ってみました。(平成30年版情報通信白書: http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h30/pdf/n1100000.pdf))
全体的にクラウド利用の総額が伸び続けているのは明らかですが、SaaSの方が一般に値段が安いことを考えると、同じくらいの金額増加でも、SaaS利用量は特に急激に伸びていると言えるんじゃ無いでしょうかね？
この急激な変化はなんでなの
ここは予測も含みますが、以下のような点があげられるのではないでしょうか
- ビジネスと切っても切れなくなったIT事情。それに加え、IT業界の変化の速さから、ITサービスを作る/所有する、という風潮から欲しい分だけ使うという風潮がでてきた。
- 多種多様なIT企業が出現し各企業が専門性を深める中で、自企業で開発を進めるよりも、専門のことはプロに委託し、自企業は本来のビジネスに人員を割こうという風潮がでてきた。
- サイバー攻撃が急増する中、自社管理基盤を持つことをリスクと考え、システムを持たず使う流れへとシフトした
- コンプライアンス(要は、このクラウドはこんだけ厳しい条件満たしてますよみたいな認定)を取得するクラウドが増え、信頼できるクラウドサービスが増えた
というところですかね。いずれにせよ、自社で持っていた情報も、クラウド等外に出していこうという流れがあることは、数値から見ても明らかですね。
CASBって何ができる
ようやく本題ですね。
CASBにはAPI型、Proxy型、ログ分析型等あるのですが、細かい話は置いておいて、
イメージとして以下のような使い方をします。
各クラウドサービスにアクセスしに行く際、CASBを必ず経由するようにすることで(Proxy型を例に説明しています)、クラウドサービスとのやりとりを監視します。
これで特に嬉しくなるであろうポイントは、個人的には以下の３つだと思っています。
①シャドウITの防止と個人利用の防止
シャドウITっていうのは、会社で許されていないのに勝手に使われているITのことです。
仕事の会話にLINE使っちゃダメって言っているのに隠れて使っちゃっているケースとかですかね。
こういったシャドウITを防ぐために、会社のPCからLINEにアクセスできないようにする、ということもCASBでできますが、これは既存プロキシ設定でも実現できる内容。
面白いのは、アカウント単位でも制御ができる点です。
ちょっとややこしいので例をTwitterにすり替えましょう。
広報活動でTwitterを使うために会社PCからTwitterにアクセスをした瞬間、個人が業務中に個人アカウントでツイートしまくるようになった、という問題があったとします。
なんせ業務に使うので、Twitterへのアクセスを閉じることはできません。
ここでCASBの登場。
アカウントレベルで制御ができるので、会社で許されたアカウントしかログインができないように設定ができます。
会社の公式アカウントは使えるが、個人アカウントは使えない、といった柔軟な設定ができるのです。
※説明簡易化のためにTwitterを例にしてますが、既存のCASBにTwitterに対するこの機能があるかは不明です
②データ移転防止
これが面白い。
特定の文字列(社外秘など)がついているデータなどが、アップロードされそうになったら、それをブロックする機能です。
先ほどのgmailの例だと、gmailを許すことで日本の社内サーバから、アメリカ等にあるgoogleのサーバにバンバン機密情報がアップロードされても検知できなくなります。
これは、GDPR法や中国のサイバーセキュリティ法など、個人情報を無断で域外に持ち出してはいけない法律が定められている地域では大問題になります。法律違反です。
SaaSを許した瞬間にこれがバンバンやられるようになっては、ガバナンスが効かなくなってしまいますね。
こういった防止ができるのが二つ目の機能です。
ファイルの中身を見て、SaaSにデータを預けていいかどうか判断する機能なのです。
※ただ、この制御果たしてうまく機能するかは懐疑的です。文字列で判断させるとしたら、重要書類に特定文字列を入れるよう人の手で運用することになりますからね。特定製品の仕様まで細かく見れていませんが、なんとなく予防ぐらいにしかならない気がしています。
③セキュリティ強化
まぁこれは個人的には面白く無いのですが、SaaSにアップされたファイルをウイルスチェックかけて、害のあるものはブロックするという機能ですかね。
既存のセキュリティ機器とかぶる部分があるのですが、入り口出口で対策するのではなく、直接SaaSを見にいって検査するというのがポイントだと思います。
まとめ
今流行りのCASBについて説明しました。
既存のセキュリティ機器と何が違うの？という疑問が湧きがちなところに、
CASBならではの機能とその面白さについていくつかお話ししていきました。
【AWS】【Azure】ハイブリッドクラウドって？
どうも、Keiです。
先日夏バテで一日ダウンしてしまいました。みなさんも水分補給など気を付けてくださいね。
今日は、最近ますます進むクラウド化と、従来からあるオンプレの両立的なサービスであるハイブリッドクラウドについて説明していきたいと思います。
また、ハイブリッドクラウドに対するITジャイアントであるマイクロソフトのAzureと同じくアマゾンのAWSの取り組みについて紹介していきたいと思います。
ハイブリッドクラウドって？
NIST(アメリカ国立標準技術研究所、標準化団体ですね)ではハイブリッドクラウドについて、下記のように定義を行っています。
(Hybrid) cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability..
つまり、ハイブリッドクラウドとは2つ以上のプライベートクラウド（オンプレ）やパブリッククラウドから成り、データ連携がシームレスに行われるものであると言っています。
これは、本来クライアントにとってITインフラは元々オンプレでもクラウドでも場所は別にどうでも良くて、下の3つが満たされれば良いという考えに基づいていると考えられます。
- 可用性が高い
- 管理（運用）しやすい
- 価格が安い
つまり、ハイブリッドクラウドとはクラウドで解決しきれなかったクライアントのITインフラへの要望を満足させる方法の1つということです。
ハイブリッドクライドのメリットとは？
さて、従来からあるクラウドで実現できないこととは何でしょうか？
1つずつ見ていきましょう。
セキュリティの問題
クライアントのITインフラをクラウド化する上で最も大きな課題として挙げることができるのが、このセキュリティの問題です。
顧客データをクラウドに上げることを嫌がるクライアントは非常に多いです。そのため、クライアントのデータはオンプレで自社で持ち、それ以外のデータはクラウドで持つという形をとる必要があるため、ハイブリッドクラウドを採用しているクライアントが多い印象を受けます。
一方でオンプレでITインフラを持っていたとしても、当然社内の情シス部でセキュリティを担保する必要があります。また、外部のセキュリティ会社にアウトソースするとしてもベンダ選びなど、専門の技術者がいないと不安は消えないでしょう。
そのため、最近ではAWSなどに代表されるように、クラウド化する際のセキュリティ基準を公開しているクラウドを利用する動きもあります。
例えば、AWSではISO 27001などのプロセスのセキュリティ基準などの多くのセキュリティ基準に合格していることをアピールしています。
なんか、AWSのPR記事みたいになたいですね笑
Bigdataなどデータ分析の需要とコストの問題
もう一つ、ハイブリッドクラウドを後押しする理由の1つとして、最近各社で取り組みが進んでいるAIを利用したBigdataの分析があります。
Bigdataの分析では、膨大な情報をAIに学習させることで、AIのモデル化の精度を上げていきます。（AIについてはKoheiの下の記事を参照）
ここで、クラウド環境を利用していると問題になってくるのが、ローカル（手元）にある膨大なデータをクラウドに挙げる際の通信料とサーバ側での処理料金です。
プランにもよりますが、サーバ側の処理料金は従量課金制となっていて、データが多ければ多いほど、ランニングコストが高くなります。
そのため、Bigdataを利用するクライアントで5年以上など、長い利用期間を想定している場合は、オンプレもしくはハイブリッドクラウドを採用した方がコスト的に安く済む可能性があります。（もちろんオンプレですと初期費用が高額なので、ある程度長く利用しないと旨味が出てきません。）
このように、ハイブリッドクラウドを使用すると、膨大なデータを利用したAI学習はオンプレで行い、他のサービスはクラウドのものを使うように、必要に応じてオンプレとクラウドを使い分けることができます。
ITジャイアントにおけるハイブリッドクラウドへの取り組み
最後に、マイクロソフトとAWSでの、ハイブリッドクラウドに対する取り組みについて紹介したいと思います。
AWS (アマゾン)
結論としてはアマゾンはハイブリッドクラウドに対してマイクロソフトほど、重きを置いていない印象を受けています。
アマゾンでは「クラウドファースト」という思想を持っており、ITインフラの将来像は全てのインフラがクラウド化され、オートスケールされる状況を考えています。そのため、ハイブリッドクラウドに関しては、当初から動き出しは良くない印象です。
もちろん、ハイブリッドクラウドを実現するためのオンプレとクラウドをVPC gatewayと呼ばれるVPNネットワークで接続するような機能やセキュリティの保障は行っています。
Azure stack (マイクロソフト)
一方、マイクロソフトではクライアントからのハイブリッドクラウドの需要が出てきた頃から、大きくハイブリッドクラウドに先手を打っています。
皆さんもAzureと呼ばれるマイクロソフトのPaaSサービスはご存知かと思いますが、マイクロソフトでは、2017年後半にAzure stackと呼ばれるハイブリッドクラウドのためのPaaSサービスをリリースしました。
Azure stackとは、上で挙げた「顧客データ」や「膨大なデータを利用したAI学習」をオンプレで実現し、なおかつパブリッククラウドにあるAzureのサービスとも連携が取れるというサービスです。
少し具体的に説明しますと、Azure stackを契約したクライアントにはマイクロソフトが用意し、設定したサーバを使用します。
もしくは、ISPなどのキャリアのデータセンタにサーバを置いて、そこまでVPNで接続するという方法もあります。この場合でAIの学習をする場合は学習元のデータもキャリアのデータセンタに同様に保存してある必要があります。
でないと、膨大なデータをローカルからキャリアに移す間がボトルネックとなってしまい、場合によってはネットワークの強化をしなければ・・なんてことになってしまうからです。
いかがでしたでしょうか？
今回はハイブリッドクラウドのメリットや、ITジャイアントの取り組みについて紹介しました。
ではでは。
自動運転を作りたい！～自動運転を実現する強化学習とは？～
どうも、Koheiです。
台風の中いかがお過ごしでしょうか
今日は以前の記事「AIを業務でどう使うか？～AIを使おうとしたら困った～」でも少しふれました、
強化学習というトピックについて触れたいと思います。
数ある手法の中でもDeepLearningなどと組み合わせて、自動運転やGoogleのAlphaGoなどでも使われている有名な手法になります。
過去の記事はこちら
AIを使って自動運転を作りたい！
機械学習のアプローチとして大きく2つの方法を紹介してきました。
・正解データが用意できる
→正解データをコンピュータに学習させる教師有り学習
・正解データはないけど、たくさんのデータがある
→コンピュータにデータを分類させる教師無し学習
では、これらの手法を使ってAIを使った将棋ロボットを作りたいとします。
さて、正常に運転しているという正解は見えていますので、なんとなく正解データは取れそうな気がします。ということで教師有り学習？を選択します。
ところが、正常に運転しているときのデータを集めるかと思ったとき困ったことが起こります。
正常な運転をしているときのデータとはどんな状態なんでしょうか？
例えば、
前に障害物がなくて、ハンドルがまっすぐで、アクセル踏んでたら正解？
雨降ってたら？高速道路？実は工事中で一時的に反対車線に出なきゃ…
などなど...
天候や周りの環境による要因によって組み合わせが膨大になり、
逐次その時のハンドルの位置、アクセルの踏み具合が正常かどうかを判断するのは難しいです。それぞれの状況のデータを集めるのもかなりの労力が必要になりそうです。
ぶつからずに安全に走ってればいいんだけどなぁ
というゴールは見えるのですが、そこに至るまでの各状態を正常？or異常？の判断が
明確ではありません。
そこで使うのが強化学習です。
目的にどれくらい近づいているか？を正解とする
強化学習では、逐次その状態が正解かどうかは判定しません。
ただ、目的に対してポジティブか、ネガティブかだけを報酬として教えてあげます。
例えば自動運転の場合は
正常に運転している（例えば、車線の中を制限速度内で走って前後に障害物がない）状態であれば+1点、そうでなければ-1点を付けます。そのときのハンドルの位置やアクセル、ブレーキの具合などは評価しません。
これを何回も繰り返して、報酬が最大になる最適な組み合わせをモデル化します。
こうすることで、最も正常な運転状態にいたる過程をコンピュータ自らで導き出すことができます。
このように、一連の状態の移り変わりに対して報酬を与えることで、目的を満たす行動パターンを学習させるのが強化学習のアプローチになります。
習うより慣れよ精神ですね。
「報酬を与える」という点では、教師有り学習のようですが
ゴールと方向性（報酬）だけを与えるという観点が大きく違うところになります。
これによって各状態の評価はそこそこにして、教師有り学習に比べて、複雑な状態な組み合わせを扱うAIを作ることができます。
実際にPreferred Networksのブログでも強化学習を使って、車の自動駐車をシミュレーションしている記事がありました。
深層強化学習による自動駐車の実装 | Preferred Research
ブログの中でも取り上げていますがスマブラDXで強化学習を使ったAIを作った話もありますね。
[1702.06230] Beating the World's Best at Super Smash Bros. with Deep Reinforcement Learning
状態が複雑に遷移するゲーム系でよく活用されているイメージがあります。
強化学習使えばどんなAIでもつくれる？
明確な正解も作らなくてもいいし、めっちゃ応用できるやんけ！
強化学習で全部解決するやろ！
と思ったあなた。
強化学習は確かに応用性の高いアプローチですが、大きな欠点として計算コストが膨大なことが指摘されます。
これを何回も繰り返して、報酬が最大になる最適な組み合わせをモデル化します。
としれっと書きましたが、「何回も繰り返す」というレベルではありません。
自動運転の例でいえば、
ハンドルの状態、周りの障害物との距離、アクセル、ブレーキの踏み具合etc...など各状態で何千、何万というパラメータが存在し、それが何千、何万という組み合わせで状態が遷移していきます。
何十億パターンを繰り返し計算させる必要があり、最適な組み合わせを計算するには家のmacでちょっと計算させるっていうレベルではありません。
まともに計算したら人生がいくつあっても足りなくなるので、「だいたいの最適解でいいから早く出せる方法」を取ることが多いです。
このあたりは数学的手法の話になるので今回は割愛しますが、最適化問題という分野で研究されています。
とはいえ、これでも最適解を導くのは非常にコストが大きいものなので
規模の大きくないものであれば、各状態ごとの正解データを作って、素直に教師有り学習を実践する方が早かったりします。
機械学習のアプローチまとめ
さて、これまで機械学習のアプローチとして、教師有り学習、教師無し学習、強化学習の3つを紹介してきました。
結局のところ
これらの学習方法ってどうやって使っていけばいいの？という方もいると思いますので、ちょっと整理してみましょう。
とってもざっくり書いてみましたが、強化学習と教師有り学習、教師無し学習の最大の違いは、報酬を設定することでデータを集める過程もモデル化しているという点にあります。
つまり、データがまだなくても、集める方針さえ決めれば機械学習ができます。これは実際に大量データを持たない規模の小さな企業で活きるポイントになります。
逆に既にデータが揃っているのであれば、強化学習を取らずとも教師有り学習のアプローチをとったほうが、ゴールに早くたどりつく場合が多いです。
どんなAIモデルを作りたいのか、それに対してどんなデータがあるのか
を考慮して適切なアプローチを選択していく必要があります。
さて、今日は強化学習について書いてみました。
今後は、AlphaGoなどでも活用されているDeepLearningについても書いていきたいと思います。
ではでは
