今回gatlingを用いたwebサイトの負荷テストの方法に関して書いて行きたいと思います。

まず負荷テストについて説明しますと、負荷テストとは大量のリクエストをサイトに対して送ることによってサイトが求められる性能要件を満たしているか確認することを言います。また負荷テストを行う理由としては、実際の運用フェーズに入ってからその性能問題が表面化すると利用者などに対して多大なる迷惑や信用の低下を招く事態となる可能性があるからです。
したがってwebサイトの性能を計測することは、サイト利用者のUXを向上させることに繋がりますのでアクセス数が多いサイトになると重要な検証となります。

Gatling

今回用いるgatlingはオープンソースのwebサイト検証用ツールで詳細なシナリオをScalaを用いて記述することが可能です。シナリオとは、webサイトに対する負荷のかけ方を記述するもので、普段サイトにアクセスする際に用いているブラウザで行う動作をシミュレートします。認証システムなどの複雑なものではレスポンスデータを解析して必要な値を抽出するなどの作業が発生するためScalaでシナリオを記述できるGatlingなどで無いと負荷テストを行えない場合も存在し、そのような場合に対して重宝します。Enterprise向けのFrontLineというものもありますが今回用いているのはOpen-Sourseのものです。

環境

• Windows10
  • 検証用PC
• Laravel
  • ターゲット用サーバー
  • dockerを用いてローカルホストで起動

• gatling
  • javaをローカルPCにインストール
  • zipファイルを公式サイトからダウンロード

動作確認

公式サイトからzipファイルをダウンロードしたらgatlingが実行できるか確認して行きます。
解凍したフォルダ内に移動して、

Windowsの場合

bin\gatling.bat

を実行

Choose a simulation number:
     [0] computerdatabase.BasicSimulation
     [1] computerdatabase.advanced.AdvancedSimulationStep01
     [2] computerdatabase.advanced.AdvancedSimulationStep02
     [3] computerdatabase.advanced.AdvancedSimulationStep03
     [4] computerdatabase.advanced.AdvancedSimulationStep04
     [5] computerdatabase.advanced.AdvancedSimulationStep05

が表示されれば実行可能な状態にあるので0を選択しcomputerdatabase.BasicSimulationを実行してみます。
オプションを要求されますがそのままEnterを入力して進みます。

検証が終了すれば以下のような検証結果が表示されるので確認します。

================================================================================
---- Global Information --------------------------------------------------------
> request count                                         13 (OK=13     KO=0     )
> min response time                                    175 (OK=175    KO=-     )
> max response time                                    357 (OK=357    KO=-     )
> mean response time                                   192 (OK=192    KO=-     )
> std deviation                                         48 (OK=48     KO=-     )
> response time 50th percentile                        179 (OK=179    KO=-     )
> response time 75th percentile                        179 (OK=179    KO=-     )
> response time 95th percentile                        251 (OK=251    KO=-     )
> response time 99th percentile                        336 (OK=336    KO=-     )
> mean requests/sec                                   0.52 (OK=0.52   KO=-     )
---- Response Time Distribution ------------------------------------------------
> t  800 ms < t  t > 1200 ms                                            0 (  0%)
> failed                                                 0 (  0%)
================================================================================

Reports generated in 0s.

resultフォルダ内にあるindex.htmlファイルを開くと次のようなサマリが表示されます。

Laravelの準備

次に独自シナリオを作成して検証するための仮のサイトを構築します。

今回はdockerを用いてlaravelのデフォルトのページを作成してターゲットサイトとします。

アドレスをhttp://localhost:8000として作成し以下のようなページを表示できる状態とします。

デフォルトのページでは認証機能が存在しないため機能を作成しておいてください。

右上にLoginのリンクが表示されていればOKです。

これに対してシナリオを作成して行きたいと思います。

独自シナリオの作成

動作確認が出来たらシナリオを作成していきます。

今回作成するシナリオは

• TopページからLoginボタンを押してDashboard表示まで

になります。

laravelのログイン認証ではCSRFトークンが用いられているので取得したものをメールアドレスとパスワードと合わせて送信する必要があります。

トークン自体はレスポンスボディに埋め込まれているので正規表現などを用いて抽出します。

CSRFを考慮してシナリオを作成すると

のようになるので先ほどと同様に実行して検証できます。

このようにGatlingを用いれば複雑な認証システムでも簡単に負荷テストできるのが分かると思います。

最後に

シナリオを作成する上で重要なのはWebサイトに置いて発生しやすい障害を想定することかと思います。

そのなかで最もリスクの高い順から検証し足りない部分に関してはスケーリングしていくなどの対策案が

考えられていくように想像します。

 必要な知識

以下の知識を用います。

・公開鍵暗号

隠しておく秘密鍵と公開していい公開鍵を使う暗号方式。公開鍵で暗号化→秘密鍵で復号が一般的だが、秘密鍵で暗号化→公開鍵で復号も可能。

・ハッシュ関数

任意の数列から不規則な固定長の数列を作る関数。出力をハッシュ値という。ハッシュ値を計算することは簡単だが、ハッシュ値から元の値を計算することは不可能。

 他人の支払いを偽造

誰の宣言かしっかり確認しないとこのようなことも起こりえます。ブロックチェーンはこれを公開鍵暗号の署名を用いて防止しています。この3つをまとめて送信することによって、暗号化されたものを復号することができなかったら偽造と見抜くことができます。逆に言うと、秘密鍵さえあれば自由に取引ができてしまうので絶対に他人には教えないようにしましょう。もし他人に知られてしまったら、管理者がいないので取引の停止ができず資産がなくなってしまします。対策としてマルチシグを用いることもあります。マルチシグとは秘密鍵を分割し、暗号化するには一定数集めないといけないもので1つ秘密鍵が流出しても資産を守ることができます。

 ブロック作成の仕組み

始めに前回省略したブロックチェーンに必要な計算について説明します。

ブロックは取引情報とは別にナンス値と前のハッシュ値を持っています。ナンス値とはブロックのハッシュ値を調整するためのものです。条件を満たすハッシュ値になるナンス値を見つけた人がブロックを追加できるけれど、この条件がとても厳しいです。ハッシュの性質上、検証は簡単なので適当なナンス値を入れても偽造がばれてしまいます。ブロックを作ると報酬がもらえるので、報酬を狙っている人たちは時間と電力を使ってナンス値を計算してブロックを作っています。

ブロックチェーンではチェーンが複数伸びてしまうことがありますが、その場合は長いほうのチェーンが採用され、短いほうのチェーンはなくなります。ブロックを改ざんするには正しいチェーンより長いチェーンを作ればいいことになります。

 過去のブロックの改ざん

ブロックの情報を改ざんするとハッシュ値が変わってしまうためナンス値を計算しなおす必要があり、もしできたとしても次のブロックが前のブロックのハッシュ値を持っているためそこも計算しなおし…と繰り返し現在のブロックまでのナンス値を計算しなおし、正しいチェーンより長いチェーンを作らなければいけません。これは不可能に近いと言われています。

 不正ブロックの追加

正しいチェーンよりも長いチェーンを作ることができればこれは可能です。過去には1000万円相当のモナコインが流出したことがあります。全体の過半数の計算能力を手に入れることができれば不正ができるので「51%攻撃」とも呼ばれます。ブロックチェーンの規模が大きくなるほど全体の計算コストも大きくなるので、過半数の計算能力を手に入れることはコスト的に現実的ではありません。しかし、規模が小さいと比較的簡単に過半数の計算能力が手に入るので51%攻撃が成功しやすくなります。不正ブロックを追加すれば、過去に起こった取引を長いチェーンによって消して同じお金を使える（二重支払い）などが可能です。

51%攻撃への効果的な対策はなく、チェーンが十分伸びたら取引を承認するといったような対策がされています。

 最後に

51%攻撃の危険性はありますが、ビットコインやイーサリアムといった規模の大きいものを使えばリスクは少ないと思われます。セキュリティ以外で、仮想通貨で危惧すべきなのは価値変動のしやすさでしょうか。暴落してしまうこともあるので仮想通貨を始める人はニュースをしっかり見ておくようにしましょう。

現在さまざまなサービスがブロックチェーンを利用しています。自分のサービスがブロックチェーンを生かせそうならブロックチェーンの利用を検討してみてはいかがでしょうか。

インターン生の齋藤です。

社内の物語要約コンテストにGDBを用いた手法で挑戦してみました。

今回はその概要を説明しようと思います。

 GDBとは？

GDBとはグラフデータベース(Graph Data Base)の略であり、ノードとエッジ(点と線)で構成されたデータベースのことです。

GDBのサービスの一つにneo4jがあり、以下の画像はブラウザ上でGDBを可視化したものです。

テーブルで構成されるリレーショナルデータベースと比べると、「各点同士の関係が分かりやすい」「新しい関係を付け足すことが簡単」などの良い点があります。

この他にもGDBは「A君の友達の友達の友達は、、？」のような深い関係の検索を高速で行えるという特徴を持ちます。

しかし、この特徴は今回活かせず、ただ関係性を操作しやすいデータベースとしての活用に留まりました。

 PythonでGDBを使う

今回、GDBはPythonでNeo4jを動かすことで作成しています。

書いたコードでは、以下のようにstory_gdbというclassを定義しました。

(url、username、passwordにはそれぞれNeo4jのURL、登録したユーザー名、パスワードを代入しています)

from neo4jrestclient import client
from neo4jrestclient.client import GraphDatabase

class story_gdb:
    def __init__(self,url,username,password):
        #グラフデータベースの初期化を行う
        self.gdb = GraphDatabase(url,username = username,password = password)

以下のようなコードを実行するとGDBにノードやエッジを追加できます

n_dict["sentence0"] = gdb.nodes.create(name = "sentence0")
n_dict["sentence0"].labels.add("sentence")
n_dict["sentence0"].relationships.create("next_sen",n_dict["sentence1"+],senNo = 0)

今回はPythonの辞書型でgdbで作成したノードを管理できるようにしました。

辞書型でノードを管理するとこの後の経路探索などの時に便利です。

このあたりの詳細はneo4jのリファレンスを参考にしてください。

又、クエリを直接打ち込むことによりGDBの編集を行うことも可能です。

 今回の手法概要

今回は物語の要約ということで、文脈の把握をするために、

①類似概念をまとめる　②頻度以外でキーワードを評価する　③時系列を考慮する

ことを目標としてアルゴリズムを考案しました。

具体的には、

①文章を要約文章作成用のGDBに落とし込む

②各ノードのスコアをLexRankによって計算した上で経路探索する

という流れで出力を得ました。

要約文章作成用のGDB構成

自然言語処理ライブラリのGiNZAを利用して、形態素解析・構文解析を行ったものをGDBに落とし込みました。

(GiNZAのGithubページ：https://megagonlabs.github.io/ginza/)

この時に

・同じ英単語に翻訳される単語をつなぐ(①類似概念をまとめる)

・時系列をエッジで管理する(③時系列を考慮する)

・文章の頭にノードを追加する(不要な文章をスキップさせる目的)

などの点を考慮してデータベースを作成しました。

その結果、例えば「石ころを投げた。石を食べたらおいしくなかった。」という文章を表示すると先ほどの図のようになります。

・「石」と「石ころ」という似た概念が”rock”でつながっている

・時系列を考慮しているため、矢印の通りにノードを辿ると大体意味が分かる

・文章の最初と最後にsentenceの名前のノードが存在する

ことが分かると思います。

ここでは、動詞は全て動詞の原形で表示するようにして、活用は各エッジに格納するようにしています(残念ながら上の画像では表示されていないのですが)。

これにより、1つの動詞に対して1つのスコアをつけることや、時系列ごとに動詞の活用をとることができるようになります。

 ノードのスコア計算・経路探索を行う

物語では重要な単語は物語内に散らばって存在すると考えたので、各ノードのスコアはPageRankと併せて文章内での分散の値を計算して平均をそろえて算出しました。これにより、特に伏線回収のような文脈に注目できます(②頻度以外でキーワードを評価する)。

経路探索については、強化学習の状態価値評価を参考に、離れるにつれて将来のスコアが割り引かれるようなモデルを考案しました。

 結果

例としてシンデレラの物語を入力すると

。行く事はできませんでした。舞踏会どんな女性何処女性は誰だろうとささやきあっていましたがトレメイン夫人は何処の誰だか確かめない侭時ガラスの靴片一方のガラスの靴が合う女性事を王子様が御ふれを知るなりましたがなる大公様。片一方のガラスの靴はぴったり。王子様とシンデレラし再会し結婚式を挙げました。仲良しの動物達は二人を見送るのでした。

のような出力が返ってきました。

 問題点

・GiNZAからGDBに落とし込みきれていない

GDBへの落とし込みが上手く出来ていないために文法が滅茶苦茶になってしまう部分があります。今回は経路を辿って出力を行うため、再現性が低くなってしまうという問題もあります。

・経路探索アルゴリズムが不完全

今回、経路探索で扱うノード数が大きすぎる問題などにより、全ノードについて時系列を考慮した経路探索アルゴリズムは実装・検証しきれませんでした。

・文章が短くならない

一番最初のノードと一番最後のノードを辿る最大スコアの経路を探索する手法なので、要約と言えるまで文章が短くなりきらない場合があります。

 今後の展望

今回は文脈把握にあたっての3つの目標をうまくアルゴリズムで表現することが出来ませんでした。

今後、日本語の文章構造に最適化したGDBへの落とし込み、経路探索アルゴリズムの効率化を行うことにより、より精度の高い要約文が生成されるのではないかと思います。

 ブロックチェーンとは

「ブロックチェーン」という言葉を1度は聞いたことがあるでしょうか。この言葉を聞いたことはなくてもおそらく「ビットコイン」という言葉はニュースで聞いたことがあるでしょう。↓のようなロゴを店で見たことがある人もいるはずです。ビットコインはブロックチェーンの技術を用いて実装されています。

ブロックチェーンとは分散型台帳と呼ばれるデータベースのことです。今回はこの仕組みを簡単な例を通して見ていきたいと思います。

 ブロックチェーンの構造

名前通りブロックチェーンは取引履歴をいくつかまとめたブロックをチェーンでつないだ構造をしています。

分散型なので同じデータを全員が持っています。

 ブロックチェーンの例

ここでは例としてAさんがFさんに400円送金した場合どのように処理されるのか見てみます。

①AさんがFさんに400円渡すことを周りに宣言し、Aさんの宣言であることを確認しながら渡していく。

②誰か(今回はEさん)が取引を承認して新しいブロックを作成。

③ブロックを全員が受け取り、確認して取引成立。

 ブロックチェーンのメリット

ブロックチェーンにはメリットが多く存在しますがここでは3つのメリットを紹介します。

1. データが失われにくい

一般的な集中管理型のサーバーはメインのサーバーに何かトラブルが発生するとデータが失われてしまうのに対し、ブロックチェーンはデータを分散させているので、参加しているすべてのユーザーのデータが消えない限りデータは失われません。

２．改ざんがされにくい

例ではEさんがさらっとブロックを作っているように書きましたが、実際にブロックを作るには難しい計算が必要で膨大な時間と金が必要になります。詳しくは次回書きますが、過去のデータを改ざんするということはこの計算を何度もすることになりほぼ不可能になっています。

３．コストが安い

ビットコインのような大きなサービスを管理できるサーバーは作成費も維持費もかなりのものになります。ブロックチェーンはユーザーの機器で成り立っているのでコストが削減されています。

 スマートコントラクト

スマートコントラクトとは契約を自動で行う仕組みのことです。要するに仲介が必要ないので短時間で手数料も必要ありません。よく例に挙げられるのは自動販売機の例です。商品を選んでボタンを押すだけで契約が成立して商品が出てきます。ブロックチェーン上でスマートコントラクトを行うと改ざんされにくく、透明性もあるのでイーサリアムなどが実装しています。

ただし、あくまでプログラムなので柔軟な対応ができなかったり、一度契約を作ると自動で行うためミスがあったときに直す手間がかかったりするので気を付けなければなりません。

 余談　コインチェック社の流出事件について

仮想通貨というと実体がなく信用できない人も多いと思います。その信用できない理由の一つとしてコインチェック社の仮想通貨が流出した事件がある人も多いでしょう。勘違いしてほしくないのはこの事件は仮想通貨のセキュリティのが原因だったわけではないということです。簡単にいうと、この事件はコインチェック社がハッキングを受けユーザーのパスワードのようなものが流出したことが原因です。パスワードが漏れて被害を受けるサービスは仮想通貨だけではなく、決して仮想通貨が特に危険なわけではないのです。

 最後に

今回はブロックチェーンの仕組み、メリットについて簡単に説明しました。メリットは多いですが、もちろんリスクもあります。リスクの説明にはブロックチェーンについてもう少し詳しい知識が必要なので今回は省略しました。次回、ブロックチェーンが安全性を保つために具体的にどのような仕組みをとっているのか説明します。

eF-4のインターン生には自然言語処理に関する研究に取り組む人もいます。

そんな彼らが物語を要約するという課題に挑戦しました！

今年社内で開催した要約コンテストについてレポしたいと思います。

コンテストの司会進行は入社2年目の青木さん。技術指導の松田先生より自然言語処理に関する解説もありました。

なぜ「要約」?

自然言語処理技術を利用した文書要約技術の重要性は、キーワード検索を含め、Webオーサリング、経済文書・ビジネス文書・医療文書・法律文書等の要約…等、あらゆる分野で注目されています。

eF-4は昨年、株式会社モノゴコロとの協業で「世界のすべてを要約する」プロジェクト、”SEW(Summarizing Everything of the World)” を発足しました。

要約対象は文字通り「全て」！ 技術指導としてシンボリックシステムズより言語学者の松田先生にもご協力いただいています。

最終的には動画とテキストが中心になると思われますが、当面はテキストの要約をメインテーマとして研究しています。

今回はインターン生の研究成果を発表する場として、コンテスト実施の運びとなりました。

補足：
「要約」というと、一般的には長文を短文にするイメージを持つ方も多いと思います。SEWでは「要約」とは、例えば小説を漫画にするように、或いは映画にタイトル(文、フレーズ等)をつけるように、言語という形式に縛られず、内容をより端的に表すこと全般を指しています。

コンテスト概要

本コンテストでは、物語を題材にして文書要約技術を競いました。 題材を物語に選んだのは、文書が持つトピック（テーマ）を捉えるのにもっとも向いているため。さらに、トピック抽出は文書要約の肝であるそうです。

今回は、用意された文書が意図する “テーマ” を見つけることを課題としました。

各自が用意したアルゴリズム等に文書を読ませ、新しい “タイトル” を創作(出力)します。”タイトル” はテキストでも絵でも良しとします。

文書は星新一のショートショートより「おーい、でてこーい」を練習題材として使用し、本番題材として「鍵」を要約しました。参加者全員の投票で優勝者を決定します。

いざ、要約！

今回のコンテスト参加者はインターン生3名。 与えられた文書をどう扱うか、それぞれ目の付け所が異なり結果も全く違うものとなりました。

■中山さん

２種類のword2vecモデルを用いて文書から重要そうな単語を抽出するアルゴリズムを作成しました。

中山さんの研究はブログでも公開していますので、ぜひ合わせて御覧ください。

中山さんは都合が合わず欠席のため、代わりに青木さんが解説を行いました。

■齋藤さん

文章をginzaで解析した結果をグラフデータベースでまとめ、その構造から各単語の重要性を予測しました。
その後、文章に登場する順番なども考慮して単語を辿り、要約された文章を生成する方法を提案しました。

単語同士のつながりを図で表現した点が初心者にもわかりやすく感じられました。

■松倉さん

2種類の文章構造解析ツールを用いて、文章構造と単語のスコアリングを用いた要約を試みました。
複数アプローチから構造解析をすることでより詳細な解析を行い、他との関係の薄い文節、文、また文章内で重要な役割を持たない文を分析することで、一文単位 → 文章全体の順で要約を行いました。

文章構造解析の過程の様子。

また、エキシビションとして松田先生の取り組みもご紹介いただきました。

優勝者は・・！?

優勝は齋藤さん。 単語同士の関係性を追いかける手法と、応用すればトレンド予測に繋がりそうな点が評価されました。

優勝者には弊社代表取締役から景品が！多忙のため残念ながらコンテストには間に合わず・・青木くんから譲渡。おめでとう！

今後の展望

このプロジェクトで最終的に求めたいのはトレンド予測。

もっと手前の文書分類ができればいいと思っていたので予想以上の成果だった、と松田先生。

今回は物語を題材としましたが、今後はもっと踏み込んだ内容でトレンド予測にも取り組んで行きたいと思います。

みなさん、お疲れ様でした！

主催：株式会社eF-4

技術指導：松田裕幸（シンボリックシステムズ）

qubitについての記事では、

「qubitとは二準位系の量子状態のことである」

と説明しました。

また、ディラック記法を使うと重ね合わせまで含めた二準位系の任意の量子状態|ψ〉は状態|0〉, |1〉の線形結合として

と表現されるのでした。

 qubitの可視化 —ブロッホ球—

量子コンピュータでは量子状態|ψ〉に様々な変換を施していきます。

計算の各ステップで量子状態は常に変わり続けますが、その変化を上で説明したディラック記法を用いた、式での表現で追い続けるのは簡単ではないでしょう。

また、式を追うだけでは量子計算で頻出するPauli-Z ゲートやHadamard ゲートといった量子ゲートが、量子状態|ψ〉をどのように変換するのかを直観的に理解するのは難しいでしょう。

そこで、ブロッホ(bloch)球です。

Smite-Meister [CC BY-SA 3.0], via Wikimedia Commons

状態|ψ〉が単位球面上の点として表現されている

ブロッホ球とは、qubitを球面上の１点として表現したものです。

確率の総和が１であることからブロッホ球は単位球です。

qubitを球面上の１点として理解することで、視覚的に量子状態を見ることができ、さらには計算をしなくても量子ゲートによるqubitの変換を理解することができます。

とにかく量子コンピュータを理解するうえで、ブロッホ球の考え方を知っていると便利なんです！

図を見ていただければわかる通り、z軸の上方向を状態|0〉、下方向を状態|1〉とするのが慣例です。

したがって、北極点が純粋な|0〉の状態、南極点が純粋な|1〉の状態、それ以外が|0〉, |1〉の重ね合わせの状態に対応します。

図中のθ, φはそれぞれ緯度、経度を表しています。

さらにPauli-Z ゲートやHadamard ゲートといった量子ゲートは、ブロッホ球での回転や鏡映反転に対応します。

前回のイントロでは詳しくは説明しなかった、量子コンピュータが扱うデータの最小単位であるqubitについて説明していこうと思います。

イントロでは、古典コンピュータが扱う通常のbitについて、電圧が高い/低い、という物理的実体を与えました。

しかし、qubitの物理的実体を理解するのは難しいです。そのためここでは紹介するだけにします。

現在qubitの物理的実現方法として、超伝導を使った方法がメジャーです。IBMやGoogleといった大企業がこの方法の量子コンピュータを開発しています。

ほかにも光を用いた量子コンピュータも研究されており、東京大学の古澤明さんがこの分野で有名です。

（ちなみに富士通や日立といった日本企業はイントロで軽く触れた、量子アニーリング方式を開発しています）

このようにqubitの実現には様々な方法がありますが、量子アルゴリズムを考えるうえで重要になる、qubitの性質はどれも同じです。

以下では、qubitを数学的・量子力学的な対象として説明します。

 qubitとは

「qubitとは二準位系の量子状態のことである」

量子力学を勉強したことがある人にとっては上の説明が最も簡潔で分かりやすいと思います。

。。。こんなんじゃわかんねーよ！！

って方に向けてqubitを説明するのがこの記事の目的なのでちゃんと説明します。。はい。

まず二準位系とは、２つの状態しかないということです。つまり

• 電圧が高い/低い
• 電流が時計回り/反時計回りに流れている
• 矢印が上/下を向いている

といったような状況だけを考える、ということです。

これだけだと、”0″と”1″という２つの古典的状態を持った古典コンピュータのbitです。

しかしこの二準位系を量子力学的にとらえると、不思議なことになります。

量子力学では２つの状態があった時、その２つの状態の重ね合わせの状態もある、という約束があります。

では、重ね合わせの状態とはいったいどんな状態でしょうか。

よく重ね合わせの状態は「状態”0″であり、かつ状態”1″であるような状態」と言われます。

ではそういう「状態”0″であり、かつ状態”1″であるような状態」を実際に観測してみると、本当に状態”0″で、かつ状態”1″であるような状態が得られるのでしょうか。

もちろんこの答えはNoです。

まず、そもそも矢印が上/下を向いているような状況だけを考えているので、矢印が上を向いていてさらに下を向いているという状態はありません（というかそもそも上も下も向いた矢印ってなんなんだよ…）

実は「状態”0″であり、かつ状態”1″であるような状態」を観測しても、状態”0″または状態”1″のどちらかしか得られません。

では、「状態”0″であり、かつ状態”1″であるような状態」と状態”0″や状態”1″との違いは何なんでしょうか。

その違いは、複数回観測してみると分かります。

状態”0″は何回測定しても、状態”0″である、という当然の結果だけです。状態”1″についても同じです。

しかし、「状態”0″であり、かつ状態”1″であるような状態」は全く違います。

この状態を測定すると、あるときは状態”0″であるという結果が得られ、またある時は状態”1″という結果が得られます。

しかしどちらの状態が観測されるかはランダムではありません。

ある確率Pで状態”0″が観測され、確率1−Pで状態”1″が観測されます。

「状態”0″であり、かつ状態”1″であるような状態」というのはこういう意味です。

したがって、量子力学では、

• 観測すると絶対に”0″/”1″が得られる状態

だけでなく、

• 観測すると確率的に”0″や”1″が得られる重ね合わせの状態

も存在します。

これらをまとめたものが量子状態です。

したがってqubitとは、状態”0″と状態”1″さらにその重ね合わせの状態のどれかをとるbitです。

 ディラックの記法

上で述べたことを数式で扱うには、ブラベクトル、ケットベクトルを用いたディラック記法がよく使われます。

２つの状態”0″, “1”を表すのにベクトルを用います。

ここで状態”0″のベクトルを表す記号を|0〉、状態”1″のベクトルを表す記号を|1〉として、

のように、２成分のベクトルを定義します。

この|0〉や|1〉をケットベクトルと言います。

すると重ね合わせの状態|ψ〉は

で表されます。ここでα,βは複素数です。

さらに、|α|²+|β|²=1とすると|α|²が状態|0〉が得られる確率、|β|²が状態|1〉が得られる確率を表していると解釈できます。

量子コンピュータとの対比で、現在私たちが普段使っているコンピュータのことを古典コンピュータと呼びます。

量子コンピュータについて理解するために、まずは古典コンピュータについて振り返ります。

古典コンピュータは、データをbitという最小単位で扱います。この1bitは”0″または”1″の状態をとることができます。この”0″または”1″という状態は、具体的にはコンピュータ内部で電圧が高いか低いかで表されます。

古典コンピュータはこのbitに様々な処理をすることでいろいろな計算をすることができます。

一方、量子コンピュータで扱うデータの最小単位はqbit(Quantum bit; 量子ビット)です。qbitとは具体的には一体何なんだ、という疑問は一旦置いておきます。

古典コンピュータではbitが”0″または”1″の2つの状態をとることができましたが、qbitはさらに”0″と”1″の間の状態もとることができます。ここでいう「間の状態」とは状態”0″が３割、状態”1″が７割というように、”0″と”1″がある割合で混ざっている状態です。この混ざった状態を「重ね合わせ状態」と言います。

量子コンピュータは重ね合わせ状態にあるqbitに処理をすることで、”0″と”1″の２つの状態に同時！に処理をすることができます。これを量子並列性と言い、古典コンピュータにはない量子コンピュータの大きなメリットです。

 方式について

量子コンピュータには現在大きく分けて量子ゲート方式と、量子アニーリング方式があります。

量子ゲート方式は、古典コンピュータの論理ゲートと同じようなものを用いて計算を行う方式です。従来の古典コンピュータと同様に様々な計算を実行することができる汎用コンピュータです。さらにゲート方式の量子コンピュータ上で古典コンピュータと同等な処理を行うこともできます。

量子アニーリング方式は、汎用型コンピュータではありません。最適化問題を解くことに特化した専用計算機です。しかし最適化問題が解けるというのは大きなことです。配送トラックが配送先をどの順番で回るのが最善かという問題は巡回セールスマン問題といわれ、最適化問題の１つです。巡回セールスマン問題のほかにも最適化問題は、実社会に対して大きな影響力のある問題を数多く含んでいます。

本当の意味での量子コンピュータは量子ゲート方式です。しかし量子ゲート方式は現状数十qbit 程度の規模のものしか実現できていません。

一方、量子アニーリング方式は2011年にカナダのD-waveが世界で初めて商用の量子アニーリングマシンを販売しました。

量子ゲート方式の今後の発展に期待ですね！

 何ができるのか

量子コンピュータを使えば何でも速くなるわけではありません。

しかし、量子コンピュータを使った方が計算が圧倒的に速くなることが示されている例があります。

特に重要なのがshorのアルゴリズムという、素因数分解をするアルゴリズムです。

現在主流となっている暗号方式であるRSA暗号の安全性は、大きな数の素因数分解には膨大な時間がかかる、という点に依っています。したがって、量子コンピュータが完成して素因数分解があっという間にできてしまうと、RSA暗号が成り立たなくなる可能性があります。

量子コンピュータを使う方が速くなるアルゴリズムはほかにも見つかっていますし、今後さらに見つかるでしょう。そうなれば量子コンピュータの重要性はますます高まります。

eF-4 インターン生のなかやまです。

文書要約コンテストで、私は与えられた文書からタイトルを生成するモデルを作りました。

 アプローチ

文書中で最重要な単語を推測するためにword2vecを使いました。

実際に作成したアルゴリズムの概要は以下の通りです。

1. 与えられた文書を形態素解析し、標準形の単語単位に分解
2. 形態素解析された文書を教師データとしてword2vecを学習
3. 学習したword2vec内の文書中で最頻出の単語ベクトルに最も近い単語ベクトルをいくつか抽出
4. “wikipediaの記事から学習した”word2vecに、最頻出語と抽出したいくつかの単語の平均に最も近い単語を抽出

最後に”wikipediaの記事から学習した”word2vecから抽出した単語を今回の出力結果としました。

 解説

今回は２種類のword2vecモデルを使いました。

１つは与えられた文書にのみ基づいて学習したモデル(text_model)、もう１つはwikipediaを用いて膨大な量の文章から事前に学習したモデル(wiki_model)です。

text_modelは与えられた文書での独特な単語の使われ方などをよく表現できます。また、文書において、最頻出語、特に名詞の中での最頻出語は、その文書において重要な要素であると思われます。そこで、text_modelにおいて最頻出語の単語ベクトルの周りには最頻出語が文書内でどのような意味で使われ、どのような意味で重要なのかを示す単語ベクトルが分布していると考えられます。

そこで最頻出語の周辺にある単語をいくつか見ることで、文書の主題が分かります。しかし、ただ単語を並べただけではタイトルとすることができません。得られたいくつかの単語から自然な文章を生成するタスクはそれ自体が大変難しいので、今回は得られた単語を１つの単語に集約するという方針にしました。

具体的には、事前にwikipediaの記事を用いて学習したモデルwiki_modelを使いました。広範な内容の文章から学習することで、一般的な日本語の知識が暗に得られていると考えられます。そこでこのwiki_modelにおいて、上で説明したようにして得られたいくつかの単語を平均化したベクトルの周辺には与えられた文書の主題を表すような”一般的に使われる”単語を得ることができます。

このような考えに基づいて、今回のアルゴリズムを作りました。

 おわりに

今回は文書をword2vecで単語単位で詰め込むことによって、文書から重要そうなものを抽出しました。しかし、このword2vecの学習が難しいところでした。各文書ごとに最適な学習のハイパーパラメータが違うことがあります。これを系統的に見つけ出す方法がなければ、真に自動な文章要約はできません。同じことですが、今のままでは般化性能に疑問が残ります。

今回はインターン共同開発プロジェクトとしてpepperのアプリを2つ作ったのでそれについて投稿します。

 pepperとは

知らない人はいないと思いますが一応簡単な説明を。pepperはsoftbankが作っている人型ロボットでさまざまなセンサーが搭載されており、家庭ではもちろんビジネスでの利用もされています。Choregrapheというアプリを用いるとpepperに自作のコードを入れることができ、センサーを利用して複雑な動作もできるようになっています。

 アプリ①　勤怠管理

1つ目に作ったアプリは勤怠管理アプリです。人の顔を認識して出勤、退勤を記録して給料を計算するものです。給料の計算が複雑ということで開発しました。pepperはデフォルトで人の顔を覚えて判断する機能が備わっており始めは実装が簡単そうだと思っていましたがいろいろハプニングはありました…。やはりそこまで精度が高くないのか、ある一定の角度でpepperを見ないと認識してくれなかったり、眼鏡によって精度が大きく下がったりしました。結局、精度はあまり高くならずpepperにHTMLファイルを入れて間違えたらそこで正しい名前を送信する手段を取りました。そして、データベースは誰が何時に出勤、退勤したかをpepperから受け取り給料を計算して、リクエストしたらExcelファイルでデータを返します。

 アプリ②　受付管理

2つ目に作ったアプリは受付アプリです。受付アプリでは、来客時の対応をpepperにて行うため、来客者情報のSlackへの送信を行います。受付対応での来客者、用件の確認の手間を削減できるよう作成しました。用件や情報をタブレットにて選択、入力してもらい、それらの情報をAPIにてSlackへ送信、また同時にpepperへAPIを送信し、受付完了の旨をpepperが話す機能を作成しました。ただ、タブレットの操作性の悪さ、pepperの動作の不安定さなど、ハード面での問題もあり、IoTを扱う難しさを感じる結果となってしまいました。

 余談

最終的に完成はしませんでしたが個人的に社内でpepperにものを運ばせたら楽なのでは？と考えてpepper移動アプリを作ろうとしてみましたが断念しました。障害物が多い場所を移動させるのはやはり厳しいのでしょうか。社内のマップを入れることはできてもpepperが自分の位置をセンサーで把握することは難しそうです。〇〇cmのように具体的な長さで管理しようとしてもpepperの移動に誤差があるためいつかは障害物にぶつかってしまうと思われます。高度な位置把握機能か移動精度があれば実装できそうでしたね。

 pepperの今

アプリが完成してこれから役立つぞ！と思ったのも束の間。なんとpepperの調子が悪くなってしまいました…。最初は「足の調子が悪いです」程度だったのですが今となっては「エラーが13個あります」という状態で結局アプリはインストールできず自分のパソコンに残っている、というのが今回の企画のオチです。pepperは身をもって私たちに「トラブルが起きても冷静でいることの大切さ」を教えてくれたのです。いい経験をさせてくれたpepperに感謝。

いつかpepperが元気になってくれることを心から願っています。