まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:watson

以前にも似たようなものを何度か作ったことがあったのですが、その最新改良作品です。 ツイッターでのつぶやき内容を元に自分の性格を分析して、その内容が時間とともにどのように変化していくか、を視覚化するというものです。

実際に自分の3月21日時点でのツイートを元にためしてみた結果がこちらです。なお現時点でスマホで表示する場合はレイアイトが最適化されていないため画面を横にして御覧ください:
https://personality-transition.mybluemix.net/transition/6f24cd50fa6f528cdd3162aadb716b03

2020032101


画面は最上部にシェア用のアイコンが並んだ下に性格を分析した本人の twitter アイコンと名前が表示され、その下に IBM Watson Personality Insights API を使った分析結果の「性格分析」と「消費行動動向」が表示されます(「消費行動動向は初期状態では省略表示されているので、内容を表示するには三角形部分をクリック(タップ)してください)。

性格分析はビッグ5と呼ばれる5つの性格要素(知的好奇心、誠実性、外向性、協調性、感情起伏)に加え、ニーズ(共感を呼ぶ度合い)&価値(意思決定に影響を及ぼす要素)という7つのカテゴリを更に細分化した結果がレーダーチャートで表示されます:
2020032102


また消費行動動向はその性格から結びつく消費行動の度合いが表示されます(色の濃い方がその要素が高く、薄い方が低い、という意味です):
2020032103


画面最下部にはスライダーが表示されています。初期状態では一番右にセットされていて、これは時間的に一番新しい分析結果が表示されていることを意味します:
2020032104


このスライダーを左に移動していくと少しずつ前の(古い)性格分析結果や消費行動動向が表示されていきます。自分の性格が時間とともにどのように変化していったのか/変わらない要素は何か といった内容がわかるようになる、というものです:
2020032105


このページの画面右上のリンクから皆さんのツイートでも試すことができます。興味ある方はぜひ挑戦してみて、よろしければその結果を SNS でシェアしてみてください:
https://personality-transition.mybluemix.net/transition/6f24cd50fa6f528cdd3162aadb716b03



以下、このサービスを実現する上での技術要素の説明です。なおソースコードは公開していますので興味ある方はこちらも参照ください。なお IBM Cloud を使って動かす想定のコードとなっており、後述の IBM Watson やデータベース機能含めて無料のライトアカウントの範囲内でもデプロイ可能な内容となっています:
https://github.com/dotnsf/personality_transition


このサービスは Node.js で実装していますが、サービスを実現する上で利用しているライブラリは大きく3つです。1つ目は Twitter のログイン認可を実現するための OAuth 、2つ目は認可したユーザーのツイートを取得するための Twitter API 、そして3つ目は取得したツイート内容から性格分析を行う IBM Watson Personality Insights API です。

なお、ここで使っている IBM Watson Personality Insights は IBM Cloud から提供されている IBM Watson API の1つで、テキストの内容を使用単語レベルで分析し、そのテキストを記述した人の性格や、その性格毎の購買傾向を取得する、という便利な API です。日本語を含む5ヶ国語に対応しています。詳しくはこちらも参照ください:
https://www.ibm.com/watson/jp-ja/developercloud/personality-insights.html


おおまかな処理の流れとしては、まず OAuth2 で Twitter にログインしてもらうことで、そのユーザーの権限で Twitter が操作できるよう認可します。そして Twitter API でユーザーのタイムライン内容を取得します。 この時に直近の 200 ツイートを取得します。この 200 件のツイートを投稿時刻の順に 40 件ずつ5つのブロックにわけます。そして各ブロック毎のツイート内容をそれぞれまとめて IBM Watson Personality Insights API を使って性格分析を行います(つまり1回の処理で Twitter のタイムライン取得 API を1回、IBM Watson Personality Insights API を5回実行します)。このようにすることでツイートの内容を時間で区切って直近のものから少しずつ時間を遡りながら5回ぶんの性格分析を行い、その結果を上述のようにスライダーバーで時間ごとに表示/非表示を切り替えることで実現しています。

機能的にはこれだけでもできるのですが、このサービスでは「分析結果をシェア」できるようにしました。シェアするためには(シェアされた人はツイートを取得せずに分析結果を見ることができる必要があるため)分析した結果をデータベースに格納する必要があるため、データベースも併用しています(あくまで分析結果を保存するためのもので、ツイート内容は保存していません)。

また上述のような仕様であるため、仮に Twitter 上で非公開アカウントとしているアカウントに対しても(本人の権限でツイートを取得することになるので)性格分析を行ったり、その結果をシェアすることができます(公開許可されていない人や、そもそも Twitter アカウントを持っていない人でも分析結果を見ることができます)。ただしあくまで分析結果だけがシェアされるのであって、ツイート内容がシェアされるわけではない点はご安心を。


このデモサービスでは Twitter のツイートを元に性格分析を行っていますが、必ずしも分析元はツイートである必要はありません。1人の人が書いた文章であればよいので、メールなり、社内掲示板なりからテキストを取得することができるのであれば理論上は可能です。ただし1回の性格分析におけるテキストの単語数が少ないと充分な精度がでない結果となることも考えられます。ある程度の単語数が含まれるテキストを取得できる必要があります(このサービスでは上述のように 40 ツイートぶんのテキスト内容をひとまとめにして分析しています)。

また IBM Watson Personality Insights API の特徴でもあるのですが、単にテキスト内容とその単語傾向から性格を分析するだけでなく、購買行動への傾向と合わせた実行結果を得ることができます。つまりまだ何も買っていないユーザーに対してでも、その購買傾向を調べた上でレコメンドを出したり、特定興味分野の広告を出したりする、といった使い方にも応用ができるもので、特に今回のデモではその時間変化にも着目できるようにしています。応用の幅が非常に大きな API であると考えていて、その一部が伝わればいいと思っています。

 

本ブログエントリは IBM Cloud Advent Calendar 2019 に参加しています。12/03 ぶんのネタです。経緯を紹介する導入部分がちと長めですが、お付き合いください。

あまり公に宣伝したりしてなかったのですが、以前に「空耳アワー・マシーン」を作ったことがありました。「空耳アワー」はテレビ番組「タモリ倶楽部」の人気ミニコーナーのあれです。 「外国語で歌われた歌詞が日本語だとこう言っているように聞こえる・・・」という空耳にフィーチャーした紹介コーナーです。ちょっとググってみただけで多くの傑作作品動画が見つかります:
2019112100


この空耳は、曲に合わせて歌われる外国語の歌詞の中で、「日本語だとこう聞こえる」という特徴ある部分を見つけることで成立しています。ふと「・・・これって自動化できるんじゃないか?」と閃いたのが「空耳アワー・マシーン」誕生のきっかけでした。いわゆる "Speech to Text"(音声のテキスト化)機能を使い、外国語の歌唱部分を(その言語ではなく)強制的に日本語でテキスト化する、というロジックです。実装にあたっては IBM Cloud から提供されているWatson Speech to Text API を採用しました。ちなみに Watson Speech to Text はライトプランと呼ばれるプランで利用する場合であれば、各種カスタマイズを行うことはできませんが、毎月 500 分ぶんの音声データ変換までは無料で利用することができます(2019年11月現在)。

実装したソースコード(Node.js 用)はこちらで公開しています:
https://github.com/dotnsf/soramimi

2019112801


ソースコードを git clone するかダウンロードして、settings.js 内で Watson Speech to Text API 用の API キーを指定すると実際にウェブブラウザで動かすことができるようになります。


ウェブブラウザを起動してアプリケーションにアクセスすると、最初にブラウザがマイクの使用許可を求めてくるので「許可」します:
2019112101


画面を下の方にスクロールすると「どの言語でテキスト化するか」を選択するボックスがあります。「空耳アワー」の場合ここは日本語固定ですが、機能としてはここで指定する別言語でも認識→テキスト化を行うこともできるようになっています:
2019112102


言語を指定したらマイクを持った人のアイコン部分を1回クリックして、枠が赤になる(録音モードになる)ことを確認します。枠が赤になっている間に英語の歌をマイクから「歌ってください」(笑)。歌い終わったらもう一度人のアイコンをクリックします。枠は水色に戻り、録音モードも解除されます:
2019112103


録音モードからモードが解除されると同時に、録音された内容が Watson Speech to Text API に渡され、「日本語でどう聞こえたか?」の結果が表示されます:
2019112804



一応、動くには動いています(よね?)。このアプリではマイクを使ってその場で録音した音データを使って日本語テキスト化を行っていますが、理屈の上ではこの入力を外国曲の MP3 データなどに切り替えればいいはず・・・と考えていました。

・・・が、いざそのように使ってみると、仕組みとしては動くのですが、期待していたほどの精度では認識してくれませんでした。もともと Speech to Text 機能は「喋った内容のテキスト化」に最適化されたものであって、「歌った内容のテキスト化」ではないという違いに加えて、「BGMによるノイズ」の影響が多分にあるように感じられました。要するに曲の中で楽器で演奏される部分が Speech to Text 的にはノイズとなってしまい、思っていたほどの精度でテキスト化できなくなっているようだったのでした。 まあネタとしてはある程度使えるが、正しくテキスト化できる箇所が少なすぎて実用(?)にはほど遠い、というものになってしまったのでした。これも公開を控えていた理由の1つでもあります:
2019112802


さて、長い導入部分が終わりました。ここまでが「空耳アワー・マシーン」を「作ってみた」という話で、ここからが本エントリのタイトルでもある「改良してみた」部分です。最近、音楽ストリーミング事業を展開している Deezer 社から spleeter というものすっごいライブラリが公開されました:

無料で曲からボーカルが抜ける音楽素材分離エンジン「Spleeter」公開
2019112104


この spleeter は TensorFlow を用いた機械学習によって音源からボーカルやドラム、ベースといったパーツを抜き出して分離することができるようになる、というオープンソースなライブラリです。音楽ストリーミング事業を展開している Deezer 社の立場を最大限活用し、大量のサンプリングデータを所有している状態で機械学習を行うことができ、その成果をオープンソース化して公開していただいたことになります。ウェブ上のパフォーマンスや精度に関する評判もよいものばかりという印象です。

この spleeter を使うことで上述の空耳アワー・マシーンの BGM ノイズ問題を解決できるのではないか、と考えました。BGM が Speech to Text のノイズとなっていた問題に対して、spleeter で曲データからボーカルデータだけを抜き出しておいて、そのボーカルデータに対して Speech to Text を実行することでノイズのない音声データからのテキスト化が実現できるのではないか!? と考え、これも実装してみました:
2019112803


この機能を実装するためには、あらかじめサーバー上に spleeter を導入しておく必要があります。そして spleeter をインストールする際にはパッケージ管理ツールである conda が必要になります。というわけでまずは conda (今回は簡易版の miniconda)を導入します。このページから自分のシステム環境にあった miniconda のインストーラーを選択してダウンロードし、実行して導入します:
2019112101
(↑画面は Linux 版 Miniconda のダウンロードリンクを選択する箇所)

miniconda 導入後に spleeter を導入します。コードは github で公開されているので、以下の手順を実行します:
$ git clone https://github.com/deezer/spleeter

$ conda env create -f spleeter/conda/spleeter-cpu.yaml

これで spleeter の導入が完了しました。spleeter を利用するにはまず以下のコマンドで spleeter をアクティベートし、・・: 
$ conda activate spleeter-cpu

続けて spleeter をテスト実行します。spleeter フォルダの中にサンプルの mp3 ファイル(spleeter/audio_example.mp3)があるので、これを使って実行してみます。今回はボーカルとそれ以外(2stems)に分割し、実行結果を output フォルダ以下に作成する、というオプションを指定して実行してみました:
$ spleeter separate -i spleeter/audio_example.mp3 -p spleeter:2stems -o output

成功すると ./output/audio_example/ というフォルダ(フォルダ名はファイル名から生成される)が作成され、その中に vocals.wav と accompaniment.wav という2つのファイルが生成されています。vocals.wav がボーカルだけを抜き出したもの、accompaniment.wav がボーカルを抜き出した残りの音源です:
2019112102


実際に audio_example.mp3(元の曲)と、vocals.wav(ボーカルのみ) / accompaniment.wav(ボーカル以外)を聴き比べてみるとわかるのですが、信じられないくらいキレイにボーカルが分離されています。これが無料でできるとは驚き!

audio_example.mp3(元の曲)
vocals.wav(ボーカルのみ)
accompaniment.wav(ボーカル以外)



そしてこれを上述の空耳アワー・マシーンに組み込んでブラウザから実行できるように改良してみました。この拡張機能は上述のソースコードにも含まれているので、こちらの機能を試す場合はアプリケーション実行後に /spleeter.html にアクセスすると、mp3 の音楽ファイルを指定して実行することができます(結果は out/ フォルダ内に作成されます):


そして実行してみましたが・・・ 想定外だったのは処理時間でした。例えば5分程度の曲を対象にした場合、これまでは単に Watson Speech to Text を実行するだけで、その処理時間が1分を超えるようなことはなかったのですが、spleeter でのボーカル抜き出し処理だけで5分前後かかるようになりました(ちなみに自分の PC のスペックは i5-8350 の8コアCPUでメモリは 8GB)。これは処理内容を考えるとかなり高速な処理であるとは思いますが、これまでと比べると、1曲単位での処理にかなり長い時間がかかるようになった、という印象です。 またその長い処理の間、CPU やメモリはほぼフル稼働となります。仮にネット上から利用できるサービスとして作ろうとすると、かなり高いスペックのサーバーインスタンスを用意する必要があることに加え、タイムアウトとの戦いも意識して実装する必要がある、という印象を持っています。 といった背景もあって、現時点ではバッチでまとめて処理して後から結果を確認する、という方向での実装が中心です。


一方、この処理によって得られた結果は spleeter で分離する前とは比較にならないほど良質でした。Watson Speech to Text API は日本語としてある程度の確信度をもって認識出来なかった部分は結果に含まれない(つまり正しく認識できた部分のみが結果として得られる)のですが、分離前は「あー」とか「うー」とかいうコーラス部分を除くとほんの数箇所だけが識別できていたのですが、分離後の結果のサイズは数倍になりました。つまりボーカルだけを対象とすることで識別可能な音声が数倍になった、ということになります。なお上述の vocals.wav (ボーカルのみ抜き出したオーディオデータ)を Speech to Text で変換した結果は以下になりました:
{
  "status": true,
  "results": [
    {
      "alternatives": [
        {
          "timestamps": [
            [
              "令和",
              2.37,
              2.77
            ],
            [
              "OSS",
              2.77,
              3.77
            ],
            [
              "は",
              3.77,
              3.88
            ],
            [
              "萌え",
              5.96,
              6.25
            ]
          ],
          "confidence": 0.38,
          "transcript": "令和 OSS は 萌え "
        },
        {
          "transcript": "令和 OSS は 親 "
        },
        {
          "transcript": "映画 を SNS は 萌え "
        }
      ],
      "final": true
    }
  ]
}

↑確信度は 0.38 とあまり高くありませんが、データの 2.37 秒から 6.25 秒部分が赤字のように聞こえた、という結果です。


「本当に空耳アワーでそのまま即採用されるレベルの空耳が検出できるか?」という観点においては残念ながら難しそうな印象を持っています。特に Watson はエロネタは不得意っぽい(?)のか、結果にエロなワードは皆無でした。まあこのあたりは有料版の Watson Speech to Text でカスタマイズすると変わってくるのかもしれませんが・・・ ただそのまま採用されるようなレベルでの検出はできなかったとはいえ、ここで検出された結果をヒントにそれっぽいワードを混ぜて改良すればもしや・・・ という期待は充分に持てる結果になりました。一ヶ月に 500 分、1曲5分とすれば一ヶ月で約 100 曲ほど無料で空耳を調査できることになります。あのTシャツを狙って・・・はまだ遠い夢かもしれませんが、(個人的に欲しい)耳かきあたりは狙えるんじゃないか・・・と期待が膨らむ結果となりました。

先日、IBM Watson のサービスが IAM (Identification & Access Management)およびリソースグループに対応した、というニュースがありました:
IBM Watson AI のサービスについて、IAM およびリソースグループが有効に


この対応により、IBM Watson API を使うサービスの認証方式が変更になります。現行の(この変更前に作ったものの)方式は 2019/10/31 まで有効ですが、それ以降は認証エラーになってしまいます。また 2018/11/01 以降に作成した Watson サービスインスタンスは新しい認証方式でないと接続できなくなっています。

要は Watson サービスを使って今動いているアプリケーションは1年以内にこの新しい認証/認可の方式に対応させる必要があり、また新しく作るアプリケーションに関しては新しい認証/認可方式を使って作成する必要がある、ということになります。この「Watson の新しい認証/認可方式を使ってアプリを作成」するための手順を紹介します。

【新しい認証/認可方式に対応した Watson サービスのインスタンス化】
まず、新しい認証/認可方式に対応した Watson サービスを用意する必要があります。今回は比較的多く使われていると思われる画像認識機能 Visual Recognition API を使って紹介しますが、基本的には全てのサービスで同様の方法を実装することになります。

2018/11/07 時点で、IBM Cloud 内で新しく Visual Recognition サービスを作成すると、新しい認証/認可方式に対応したインスタンスとなります。というわけで IBM Cloud にログインし、リソースの作成にて「AI」カテゴリの Visual Recognition を選択します:
2018110701


インスタンスの属性を選択します。以前はここで「ロケーション」に加え「組織」や「スペース」を選択していたのですが、新しいインスタンスではロケーションとリソースグループ(default のままで大丈夫です)を選択します:
2018110702


下にスクロールしてサービスのプランを選択します(下図では無料版の Lite を選択しています)。最後に右下の「作成」ボタンでインスタンスを作成します:
2018110703


作成したインスタンスの画面がこちらです。この画面で API KeyURL が確認できます(API Key は当初マスキング処理されています):
2018110704


クレデンシャル情報を表示させることで一時的に API Key を確認することができます。新しい認証/認可方式ではこの API Key を使ってサービス API を利用することになります:
2018110705



【新しい認証/認可方式に対応したアプリケーション】
次に、アプリケーション側をこの新しいサービスインスタンスに対応した形で作り直します。今回は Node.js と Watson Developer Cloud SDK を使う前提でアプリケーションを作る想定で以下を記述します。

新しい認証方式の Visual Recognition では以下のようなコードで認証し、インスタンスオブジェクトを作成します:
//. test01.js
var fs = require( 'fs' );

//. https://www.npmjs.com/package/watson-developer-cloud
var vr_v3 = require( 'watson-developer-cloud/visual-recognition/v3' );

var vr = new vr_v3({
  url: "https://gateway.watsonplatform.net/visual-recognition/api",
  version: '2018-03-19',
  iam_apikey: "(上記で取得した API Key)"
});

var filename = 'sample.png';
if( process.argv.length >= 3 ){
  filename = process.argv[2];
}

var params = {
  images_file: fs.createReadStream( filename )
};

vr.classify( params, function( err, result ){
  if( err ){
    console.log( err );
  }else{
    console.log( JSON.stringify( result, null, 2 ) );
  }
});

青字部分は API Key を取得した時に同時に表示されていた URL の値を url に指定しています。また赤字部分は取得した API Key 文字列を iam_apikey に指定しています。この形でインスタンスオブジェクト(上記コードだと vr 変数)を作成する必要がある、という点がこれまでと異なります。

なお、上記コードで作っているコマンドアプリ(test01.js)は
$ node test01 (画像ファイル名)

という形で指定して実行することを想定しています。(画像ファイル名)部分に画像認識を実行する画像のファイルパスを指定します(無指定の場合は同じフォルダにある sample.png に対して実行します)。

今回はいらすとや様の、この画像を sample.png として用意しました:
sample01


この画像に対して実行してみます。まず Watson Developer Cloud SDK を導入します:
$ npm install watson-developer-cloud

そして実行(実行結果は緑字):
$ node test01

{
  "images": [
    {
      "classifiers": [
        {
          "classifier_id": "default",
          "name": "default",
          "classes": [
            {
              "class": "first-aid kit",
              "score": 0.879,
              "type_hierarchy": "/kit of things/first-aid kit"
            },
            {
              "class": "kit of things",
              "score": 0.879
            },
            {
              "class": "dado (dice)",
              "score": 0.5
            },
            {
              "class": "figure",
              "score": 0.79
            },
            {
              "class": "jade green color",
              "score": 0.77
            },
            {
              "class": "emerald color",
              "score": 0.511
            }
          ]
        }
      ],
      "image": "sample.png"
    }
  ],
  "images_processed": 1,
  "custom_classes": 0
}

(結果はともかく)新しい認証/認可方式のコードで実行できました!


IBM ワトソン対応の CMS である BlueCMS を公開しました。IBM Cloud を使ったセットアップ手順はこちらをご覧ください:
ワトソン対応の IBM Cloud 向き CMS "BlueCMS" を公開しました(セットアップ手順)


今回は初期セットアップ後の、実際の使い方を紹介します。


コンテンツタイトル等

初期セットアップの中で管理者権限を持った最初のユーザーを作っているので、このユーザーの ID とパスワードでログインします:
2018071001


管理コンソール画面が表示されます。管理コンソールにはコンテンツタイトルなどコンテンツ全体に関係する設定項目に続き、現在までに登録されている文書の一覧テーブルと、添付ファイルの一覧テーブルが表示されますが、ログインユーザーが管理者権限を持っている場合はコンテンツの設定項目の下にユーザー一覧テーブルも表示されます:
2018071101
(↑上からコンテンツ設定、ユーザー一覧)

2018071102
(↑上から文書一覧、添付ファイル一覧)

コンテンツ設定は以下のようになっています:
2018071103


これらは OGP(Open Graph Protocol) と言われる設定項目になっており、有名どころでは facebook で BlueCMS のトップページや各記事を共有した場合に表示される内容を定義します。

また title と desc は BlueCMS トップ画面の jumbotron の中で表示される内容でもあります。自分のブログのタイトルとその説明を記述するようにしてください。url はブログの URL、image_url は OGP イメージ画像の URL を指定します(指定していない場合は無視します)。

なお、現時点(2018/Jul/12)では個別ページの OGP を設定する機能がなく、個別ページをシェアするとトップページと同じ OGP が表示されます(リンク先の URL だけは個別ページになります)。この辺りは今後の機能拡張で対応したいと思っています。


ユーザー追加/管理

管理者権限を持ったユーザーはユーザー一覧テーブルで登録済みユーザーの一覧を確認したり、編集したり、削除したり、新規にユーザーを追加することができます:
2018071104


新規作成は一番下の編集行の各フィールドに入力して "update"、既存ユーザーの変更は右にある "edit" をクリックすると編集行に値がコピーされるので、ここで変更して "update"、ユーザーの削除は右にある "delete" をクリックします。

なおユーザー編集時には role の値に注意してください。この値が 0 のユーザーは管理者、1 のユーザーは編集者として扱われます。name は画面表示用の名称で、email はメールアドレスですが、これらは現時点では特に利用していません。


文書追加/管理

管理コンソールには現在までに登録されている文書の一覧も表示されます:
2018071105


新規作成は一番下の編集行の各フィールドに入力して "update"、既存文書の変更は右にある "edit" をクリックすると編集行に値がコピーされるので、ここで変更して "update"、文書の削除は右にある "delete" をクリックします。

なお文書の status は 1 のものが公開、0 のものは非公開(ドラフト)となります。body は nicEdit を使ったリッチテキスト編集が可能です。category はカテゴリー文字列を直接指定して入力します(category と body の値は IBM ワトソン連携時に利用する値となります)。

body の入力が狭い nicEdit を使っている点が不便であると理解しています。この辺りも今後も機能拡張の対象と考えています。


添付ファイル追加/管理

管理コンソールには現在までに登録されている添付の一覧も表示されます:
2018071106


添付ファイルの新規作成はファイルを選択後、一番下の編集行の name フィールドに入力して "update"、添付ファイルの削除は右にある "delete" をクリックします。添付ファイルには編集機能はありません。


ワトソン連携

セットアップ時に IBM ワトソンの NLC(Natural Language Classifier) 連携も含めて行っている場合は、BlueCMS 内のコンテンツを NLC に学習させたり、学習結果を使って問い合わせを行うことができます:
2018071107


文書一覧の下に NLC 関連のボタンが3つあります。それぞれ以下のように使います:

- "update NLC" : 現在までに BlueCMS に格納された全文書を NLC のトレーニングデータとして学習を初期化&再学習します。学習時には各文書の body 値と category 値だけを取り出して、body 値の内容を category 値として学習します。これを全ての文書に対して行います。

- "NLC status" : 上記学習命令を発生した後の、ワトソンのトレーニングステータスを確認します。この実行結果が "Available" となれば学習準備は完了していて、後述の "classify" で問い合わせが可能になります。一方、実行結果が "Training" であればまだ学習中なので、いましばらくお待ち下さい。

- "classify" : 学習が済んだ後に問い合わせを実行します。具体的には編集行の body に何か文章を入力した後にこのボタンをクリックすると、上述で学習させたコーパスに対してこの body 内容を問い合わせ、「今までの学習データから、どのカテゴリーがふさわしいか」の結果を取得し、category フィールドを更新します。いわば「ワトソンがその内容に相応しいカテゴリーを自動的に決めてくれる」機能です。


現時点での制限事項等

このブログエントリを編集している 2018/Jul/12 時点での BlueCMS の機能と使い方を紹介しました。上述のように CMS として足りない機能や使いにくい部分も多くあり、ワードプレスなどと比較するとまだまだだと思っています。

一方で新しくスクラッチで開発したからこそできた挑戦的な機能もあります。特に標準で IBM ワトソンと連動する機能については BlueCMS の特徴の1つだと思っています。

自分でも少しずつ使っていきながら感じた機能を拡張させていく予定ですが、もしお試し程度でも使ってみていただける場合は、感想や希望を伝えていただければと思っています。


IBM Cloud から提供されている IoT サービスである IBM Watson IoT Platform (の QuickStart)にメッセージをパブリッシュする Node.js のサンプルアプリケーション(とソースコード)を作って公開しました:
https://github.com/dotnsf/mqtt_pub_ibmiot

2018051501


主要なソースコードは app.js だけですが、内部的に MQTT.js ライブラリを使っています:
2018051500


主な挙動としては settings.js で指定された内容に併せて、1秒(デフォルト)ごとに0から1つずつ増えるカウンタ値、タイムスタンプ値、実行したマシンの CPU 稼働率、12回周期のサイン値およびコサイン値、そしてランダムな値が JSON で IBM Watson IoT Platform の QuickStart に送られます。その際のデバイス ID 値は settings.js 内で指定されていればその値が、されていなければ動的に生成されるようにしました。


IBM Cloud 環境で Node-RED ランタイムを作ると動作を確認しやすく、またそのためカスタマイズの勘所が分かりやすいと思っています。以下、この環境での動作確認方法を紹介します。

まずはこのサンプルを動かす前提として Node.js がインストールされたマシンが必要です。Windows/MacOS/Linux/Raspberry Pi などなど、Node.js をインストール可能なマシンで導入を済ませていると仮定して以下を続けます。

次に上記リポジトリから git clone またはダウンロード&展開して、アプリケーションのソースコードを手元に用意します:
$ git clone https://github.com/dotnsf/mqtt_pub_ibmiot
$ cd mqtt_pub_ibmiot

必要に応じてテキストエディタで settings.js の中身を編集します。とはいえ、変える必要がありそうなのは exports.interval の値(メッセージデータを送信する時間間隔(ミリ秒)。デフォルト値は 1000 なので1秒ごとにメッセージを送信する)と、exports.deviceId の値(後で指定するデバイス ID。デフォルトは空文字列なので、後で自動生成された値になります)くらいです。なお、settings.js の値は変えなくても動きます。


※もし exports.deviceId の値を編集する場合は、("test" のような簡単な単語ではなく)他の人が使わないようなユニークな値になるよう指定してください。exports.deviceId の値をデフォルトのから文字列のままにする場合は、実行時ごとにデバイス ID を生成するので、この値は実行ごとに変わることに留意してください。


ではアプリケーションの動作に必要なライブラリをインストールします:
$ npm install

そして実行します:
$ node app

実行が成功して IBM Watson IoT Platform に接続すると、"client#connect: " という文字列に続いてデバイス ID が画面に表示されます(以下の例では 5d7436e992d0)。この値は settings.js で指定した場合はその値が、指定しなかった場合は自動生成された値が表示されます。この後で使うのでメモしておきます:
2018051502


※なお、メッセージを送信しているアプリケーションの終了方法は特に用意していないので、終了する場合は Ctrl+C で強制終了してください。


これでサンプルアプリケーションが IBM Watson IoT Platform に接続し、exports.interval で指定した値の間隔でメッセージデータを送信し続けている状態になりました。

最後にこの送信データを Node-RED で確認してみます。IBM Cloud で Node-RED ランタイムを作成し、IBM IoT のインプットノード(右側にジョイントのあるノード)と、debug アウトプットノードをキャンバスに配置して接続します:
2018051503


↑IBM Watson IoT Platform サーバーにメッセージが送られてきたらその payload の内容をデバッグタブに表示する、というシンプルなフローです。


IBM IoT インプットノードをダブルクリックし、Authentication が Quickstart になっていることを確認した上で、Device Id 欄に先程確認した実行中アプリケーションのデバイス ID を指定します。そして「完了」してから、このアプリケーションを「デプロイ」します:
2018051504


すると、Node-RED 画面右のデバッグタブに(デフォルトであれば)1秒おきにメッセージが追加されていく様子が確認できるはずです:
2018051505


メッセージの1つを選んで展開してみると、元のアプリケーションから送信されたカウント値(count)、タイムスタンプ値(timestamp)、CPU稼働率(cpu)、サイン値(sin)、コサイン値(cos)、そして乱数値(random)が確認できます。つまり Node.js を使って動かしたアプリケーションから MQTT 経由で実際にデータが送信されていて、その内容を Node-RED と IBM IoT インプットノードを使って取り出して確認できたことになります:
2018051506


送信データをカスタマイズしたり、別の値を送信したい場合は app.js をカスタマイズして、publish 時に送信する data 変数の中身を変える(必要な値を取得して、この中に JSON で入れる)ということになります。こちらはシンプルなのでなんとなく理解できるんじゃないかな・・・と期待しています。


また Node-RED の場合であれば node-red-dashboard と組み合わせることで、ここで取得した値を簡単にチャート化することもできます。例えば Gauge ノードと Chart ノードを使って CPU 負荷とサインカーブをこんな感じで・・・
2018051600


IBM Watson IoT Platform の Quickstart にデータを送信するサンプルとして使ってくださいませ。

このページのトップヘ