kun432's blog

Alexaなどスマートスピーカーの話題中心に、Voiceflowの日本語情報を発信してます。たまにAWSやkubernetesなど。

〜スマートスピーカーやVoiceflowの記事は右メニューのカテゴリからどうぞ。〜

Prometheusをざっくり理解する

Kubernetesの監視はPrometheusがデファクトスタンダードになっており、インストールもk8sクラスタ上に行うのが一般的です。が、今回はPrometheusをざっくり理解するために普通のサーバに入れてみようという、今更だけど自分用メモです。

Prometheusとは

ちゃんとした解説は世の中に色々転がっていると思うので、そちらを見てください。自分的には

  • Prometheus server/Prometheus Web UI/Alertmanager/Push Gateway/Exporter/Grafanaなど複数のコンポーネントで構成
  • 構造がシンプルでバイナリ+設定ファイルだけで動く
  • DockerやKubernetesとの連携も可能

というイメージです。

コンポーネントが細かく別れていることと、UIがコンポーネントごとに別だったり、他の外部UIコンポーネント(grafanaとか)も現実的に必要になったり、ということで全貌が見えにくい印象があります。が、Promethes本体はあくまでも各監視対象のメトリクスを保存しておく単なる時系列データベースであり、周辺ツールがここにアクセスすることで一つの監視システムを構成していると考えています。

なので、各コンポーネントが何をしているのか、というところからまず整理します。

  • Prometheus Server
    • 本体。時系列データベース、それにアクセスするためのAPI、監視対象からメトリクスを収集
  • Exporter
    • いわゆるエージェント。監視対象システム上でメトリクスを収集、Prometheus Serverからの取得要求に答える
  • Push Gateway
    • 監視対象側からメトリクスをpushしたい場合に待ち受けている。Prometheus Serverはここをポーリングしてメトリクスを拾うので、pushとpullの中間層的なイメージ。
  • AlertManager
    • Promethes本体は通知機能を持たない。AlertManagerにpushして通知を行う。そのためのWeb UIも持つ。
  • Prometheus web UI/Grafana
    • Prometheus ServerのAPIにアクセスして、メトリクスの抽出、視覚化を行う。PromQLというクエリ言語でアクセスする。

ま、ざっとこんな感じかなと。このあたりをアーキテクチャ図と見比べると理解しやすいかと思います。他にもサービスディスカバリ等でkubernetesと連携したりしますが、そこはちょっと置いときましょう。

Prometheusのインストール

では早速やっていきましょう。Prometheusサーバと監視対象サーバの2台のサーバを用意してやってみます。

  • Prometheusサーバ
    • OS: ubuntu 18.04
    • IP: 10.240.0.31
  • 監視対象サーバ
    • OS: ubuntu 18.04
    • IP: 10.240.0.32

インストール方法は色々あるようですが、ubuntuなので素直にパッケージ使いたいと思います。

Prometheusサーバ

インストール

$ sudo apt-get install -y prometheus

設定ファイルは/etc/prometheus/prometheus.yaml

# Sample config for Prometheus.

global:
  scrape_interval:     15s # By default, scrape targets every 15 seconds.
  evaluation_interval: 15s # By default, scrape targets every 15 seconds.
  # scrape_timeout is set to the global default (10s).

  # Attach these labels to any time series or alerts when communicating with
  # external systems (federation, remote storage, Alertmanager).
  external_labels:
      monitor: 'example'

# Load and evaluate rules in this file every 'evaluation_interval' seconds.
rule_files:
  # - "first.rules"
  # - "second.rules"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  - job_name: 'prometheus'

    # Override the global default and scrape targets from this job every 5 seconds.
    scrape_interval: 5s
    scrape_timeout: 5s

    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.

    static_configs:
      - targets: ['localhost:9090']

  - job_name: node
    # If prometheus-node-exporter is installed, grab stats about the local
    # machine by default.
    static_configs:
      - targets: ['localhost:9100']
  • 15秒間隔で監視対象からデータを引っ張る
  • 15秒間隔で引っ張ったデータとルールの比較を行う
  • アラートルールの設定はなし
  • scrape_configs.[].job_nameで監視対象の設定を行う。デフォルトでは以下が含まれている。
    • ローカルのprometheusサーバ自身
    • ローカルのnode-exporter(prometheusのインストールで自動で入る)

とりあえずこのままでも動きそうなので起動します。node-exporterも起動しておきましょう。

$ sudo systemsctl start prometheus
$ sudo systemsctl start prometheus-node-exporter

では、ブラウザでprometheusサーバの9090版ポートにアクセスします。

f:id:kun432:20200629175812p:plain

はい、prometheusの管理画面が表示されていますね。ではメトリクスを表示してみます。ドロップダウンリストから適当なメトリクスを選択して"Execute"をクリックします。今回は「node_cpu」を選択してみます。

f:id:kun432:20200629180352p:plain

こんな感じでメトリクスが表示されます。次に、Graphタブをクリックしてみてください。

f:id:kun432:20200629180547p:plain

時系列でメトリクスが時系列でグラフ表示されます。つまり先程数値で表示されていたのは最新のメトリクスということですね。

f:id:kun432:20200629180736p:plain

監視対象サーバ

こちらはprometheus-node-exporterをインストールしてプロセスを上げておくだけです。

$ sudo apt-get install -y prometheus-node-exporter
$ sudo systemctl start prometheus-node-exporter

で、あとはprometheusサーバ側で監視対象に追加してあげます。/etc/prometheus/prometheus.yamlに以下を追加します。

... snip ...

scrape_configs:
... snip ...

  - job_name: prometheus-client
    static_configs:
      - targets: ['10.240.0.41:9100']

反映します。

$ sudo systemctl restart prometheus

先ほどと同じように「node_cpu」のグラフを見てみましょう。新しく追加した監視対象サーバが下の方に追加されているのが見えるでしょうか?

f:id:kun432:20200629183414p:plain

ここまでがprometheusの基本になります。

AlertManagerのインストール

上でも述べたとおり、Prometheus自体は通知の機能を持たず、通知はAlertManagerの仕事になります。ということでAlertManagerをPrometheusサーバ上にインストールします。

$ apt-get install -y prometheus-alertmanager

アラートの条件やしきい値はPrometheus Server側で設定します(なのでAlertManagerはほんと通知だけですね。)/etc/prometheus/prometheus.yaml に以下を追加します。別ファイルで切り出している形です。

... snip ...

rule_files:
  - "/etc/prometheus/alert.rules"

... snip ...

/etc/prometheus/alert.rulesを記載します。で、prometheusのアラートルールを色々紹介しているサイトがあるみたいなので、そこからルールを持ってたいと思います。

groups:
  - name: prometheus-client
    rules:
    - alert: PrometheusTargetMissing
      expr: up == 0
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: "Prometheus Target missing (instance {{ $labels.instance }})"
        description: "A Prometheus Target has disappeared\n  VALUE = {{ $value }}\n  LABELS: {{ $labels }}"
    - alert: HostHighCpuLoad
      expr: 100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "Host high CPU load (instance {{ $labels.instance }})"
        description: "CPU load is > 80%\n  VALUE = {{ $value }}\n  LABELS: {{ $labels }}"

ノードが死んだ場合とcpuが80%を超えた場合を試しに設定してみました。

反映します。

sudo systemctl restart prometheus

prometheusの管理画面にあるAlertメニューを開くと追加したルールが表示されていますね。

f:id:kun432:20200629210258p:plain

では試しに監視対象サーバを落としてみましょう。Prometheusのalertを開くと、ちゃんと状態が変化していることを検出できています。

f:id:kun432:20200629210822p:plain

この状態でしばらく待つと、さらに状態が変わり「FIRING」となります。これがalertmanagerにpushされる状態です。

f:id:kun432:20200629211221p:plain

では、通知の設定を行います。色々通知の方法はありますが、今回はSlackに投げてみましょう。/etc/prometheus/alertmanager.ymlを以下のように修正します。

global:
  slack_api_url: "https://hooks.slack.com/services/XXXXXXXX/XXXXXXXXXXX/XXXXXXXXXXXXXXXXXXXXXX"

route:
  receiver: 'slack-notification'

receivers:
- name: 'slack-notification'
  slack_configs:
  - channel: '#general'
    text: "<!channel> \nsummary: {{ .CommonAnnotations.summary }}\ndescription: {{ .CommonAnnotations.description }}"

シンプルにslackだけに投げてます。グループは使ってません。あとはテキストにアラート設定側のannotationsを含めるようにしてます。通知のテンプレは以下も参考にしてください。

そして、Prometheus serverからalert manager似pushするように設定します。/etc/prometheus/prometheus.yaml に以下を追加します。

alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - localhost:9093

でAlert Managerを起動、Prometheus Serverも再起動して反映しましょう。

$ sudo systemctl start prometheus-alertmanager
$ sudo systemctl restart prometheus-alertmanager

AlertManagerのWeb画面を見てみるとこちらでも検出しています。

f:id:kun432:20200629223406p:plain

そしてslackにも通知が来ました!

f:id:kun432:20200629223133p:plain

まとめ

とりあえず一通り動きました。あとはgrafana入れればよくあるprometheus構成になると思いますが、ちょっとそこは割愛します。次回はこれをkubernetesでやってみたいと思います。

ask-cli v2でAlexa-hostedスキルを作ってみる

2020/07/11追記 治ってるみたいです。ask-cli-2.11.1で確認してます。

2020/07/03追記 ask-cli v2でalexa-hostedの場合に、pushしてもskill-packageが更新されない(lambdaは更新される)という方は以下の手順でやってみてください。

$ ask new
$ cd スキルのディレクトリ
$ git add .gitignore
$ git commit -m "add .gitignore"
$ git push
(以降は自由に編集して、git add/commit/pushしてください)

理由はよくわかっていませんが、ask newしたあとの一番最初のコミットでskill-packageをまとめてcommit/pushするとどうも反映されなくなるようです・・・ 2020/07/03追記ここまで

遅ればせながらask-cli v2の話。

先日GAになったask-cli v2の良さは、AWSリソース(Lambda/S3/DynamoDB)をオールインワンでセットアップしてくれることだと個人的に思ってるので、逆にAlexa-hostedで使う場合の手順があまりない気がする。ということでAlexa-hostedで使う場合です。

ask-cli v2のインストール

ask-cli v1を引き続き使いたい方は本記事の手順だとマルっとv2に置き換わってしまうのでご注意ください。そうするとv1で作ったプロジェクトはv2へのマイグレーションをしないといけなくなります。マイグレについては以下あたりをご参考に。

qiita.com

個人的にはまだ各プロジェクトのマイグレは落ち着いてからやりたいので、nodebrewで環境を分けようと思います。nodenvとか使ってプロジェクト単位にするのもいいんでしょうが、そこまでnode.jsのプロジェクトが多いわけでもないし、コマンドラインはグローバルに切り替えるほうが好みなので。

ということで、まずask-cli v1が動いている現在の環境。

$ nodebrew ls
v10.16.0
...

current: v10.16.0

これを"ask1"というエイリアスにします。

$ nodebrew alias ask1 v10.16.0

ask-cli v2用にnode-10.21.0を入れて、"ask2"というエイリアスをつけます。

$ nodebrew install v10.21.0
$ nodebrew alias ask2 v10.21.0

あとは、nodebrew useで切り替えるだけです。

$ nodebrew use ask2
use v10.21.0

ask-cli v2をインストール

$ npm install -g ask-cli@2

インストールしました。

$ ask --version
2.11.1

ask v1に戻したい場合は以下でいつでも戻せます。

$ nodebrew use ask1

プロジェクトの新規作成

Alexa開発者コンソールとの連携はすでにできているものとします(v1だとask init, v2だとask configure。v2では別にask initがあるのでややこしいですね・・・)

プロジェクトの作成はask newです。対話形式になってるので順に答えていきましょう。

$ ask new

開発言語を聞いてきます。とりあえず NodeJS"で進めます。カーソルキーで選択してENTERします。

Please follow the wizard to start your Alexa skill project ->
? Choose the programming language you will use to code your skill:  (Use arrow keys)
❯ NodeJS
  Python
  Java

スキルのバックエンドを選択します。Alexa-hosted skills/AWS with CloudFormation/AWS Lambda/self-hosted の4つから選択しますが、もちろん"Alexa-hosted"で。

? Choose a method to host your skill's backend resources:  (Use arrow keys)
❯ Alexa-hosted skills
      Host your skill code by Alexa (free).
  AWS with CloudFormation
      Host your skill code with AWS services and provision with AWS CloudFormation (requires AWS account)
  AWS Lambda
      Host your skill code on AWS Lambda (requires AWS account).
  ──────────────
  self-hosted and manage your own hosting

スキル名を入力します。多分日本語通らないと思うのでご注意ください。今回はデフォルトの"Hello World Skill"で進めます。

? Please type in your skill name:  (Hello World Skill)

プロジェクトを保存しておくローカルのディレクトリ名を聞かれます。デフォルトはスキル名とおなじになりますので、そのままENTER。

? Please type in your folder name for the skill project (alphanumeric):  (HelloWorldSkill)

スキルの作成が開始されます。1分ぐらいかかります。

⠼ Creating your Alexa hosted skill. It will take about a minute.

ローカルにディレクトリが作成されます。コマンド実行時のカレントディレクトリの直下にディレクトリが作成されるようです。メッセージ見ている限りは、alexa-hosted側でスキルが作成され、それをローカルにcloneしてる感じですかね。

Project directory for aaa created at
    /Users/kun432/repository/HelloWorldSkill
⠋ Cloning Alexa Hosted Skill...

以下のように表示されれば完了です。

Project directory for Hello World Skill created at
    /Users/kun432/repository/HelloWorldSkill

Lambda code for Hello World Skill created at
    ./lambda

Skill schema and interactionModels for Hello World Skill created at
    ./skill-package

Skill is enabled successfully.
Hosted skill provisioning finished. Skill-Id: amzn1.ask.skill.XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Please follow the instructions at https://developer.amazon.com/en-US/docs/alexa/hosted-skills/build-a-skill-end-to-end-using-an-alexa-hosted-skill.html#askcli to learn more about the usage of "git" for Hosted skill.

以下のようにディレクトリが作成されています。

$ ls
HelloWorldSkill

中をちょっと覗いてみましょう。

$ cd HelloWorldSkill
$ tree -a
.
├── .ask
│   └── ask-states.json
├── .git
... snip ...
├── .gitignore
├── ask-resources.json
├── lambda
│   ├── index.js
│   ├── package.json
│   └── util.js
└── skill-package
    ├── interactionModels
    │   └── custom
    │       └── en-US.json
    └── skill.json

28 directories, 45 files

ask-cli v1とは微妙に構成が変わっていますね。あとgit init済みのようなので、ちょっとのぞいてみます。

$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    new file:   .gitignore

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    skill-package/

initial commitされてます。

$ git log
commit XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (HEAD -> master, origin/prod, origin/master, origin/dev, prod)
Author: AlexaHostedSkills <VoiceHubCodeCommitRole/provisioning>
Date:   Sun Jun 28 16:50:04 2020 +0000

    Initial Commit

masterとprodブランチがあります。それぞれのリモートブランチがあって、リモートにはdevもありますね。

$ git branch -a
* master
  prod
  remotes/origin/dev
  remotes/origin/master
  remotes/origin/prod

リモートブランチがCodeCommitにあるようです。

$ git remote -v
origin  https://git-codecommit.us-east-1.amazonaws.com/v1/repos/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX (fetch)
origin  https://git-codecommit.us-east-1.amazonaws.com/v1/repos/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX (push)

ask newが完了したときに表示されていたURLにも書いてあるのですが、AWS CodeCommitやAWS CodeBuildが使われているようです。

おそらくaskコマンドの内部で使っているだけで、自分でgit pushしたりすることはないんじゃないかなーと思っているのですがどうでしょう?逆に自分でgithubあたりでコード管理する場合にどういうふうにすればいいんでしょうか?

まだちょっとよくわかってないのでとりあえず先に進みましょう。次はAlexa開発者コンソールの方です。

f:id:kun432:20200629021806p:plain

スキルが作成されていますね。en-USになるようです。中身も見てみます。

f:id:kun432:20200629022056p:plain

f:id:kun432:20200629022106p:plain

はい、Hello Worldスキルの対話モデルとコードが作成されていますね。これで準備は完了です。

スキルの開発とデプロイ

2020/07/03追記 skill-package以下のファイルが更新されないという事象があるようなので、以下をまず実施してから、各ファイルの編集を行ってください。

$ git add .gitignore
$ git commit -m "add .gitignore"
$ git push

2020/07/03追記ここまで

あとはローカルで開発をしてアップするだけです。まずは練習として日本語に変えてみましょう。この辺が参考になると思います。

qiita.com

skill-package/skill.json

ロケールとスキル名を変更。

    "publishingInformation": {
      "locales": {
        "ja-JP": {
          "name": "ハローワールドスキル"
        }
      }
    }

skill-package/interactionModels/custom

リネームします。

$ mv en-US.json ja-JP.json

ja-JP.jsonの、呼び出し名とHelloWorldIntentのサンプル発話を変更します。

{
  "interactionModel": {
    "languageModel": {
      "invocationName": "ハローワールドスキル",
      "intents": [
        {
          "name": "AMAZON.CancelIntent",
          "samples": []
        },
        {
          "name": "AMAZON.HelpIntent",
          "samples": []
        },
        {
          "name": "AMAZON.StopIntent",
          "samples": []
        },
        {
          "name": "HelloWorldIntent",
          "slots": [],
          "samples": [
            "こんにちは",
            "お元気ですか",
            "こんにちはと言って",
            "ハロー",
            "ハローワールド",
            "ハローといって",
            "ハローワールドと言って"
          ]
        },
        {
          "name": "AMAZON.NavigateHomeIntent",
          "samples": []
        }
      ],
      "types": []
    }
  },
  "version": "1"
}

lambda/index.js

発話部分を変更してください。今回はテストなのでLaunchRequestHanlderとHelloWorldIntentHandlerだけで試します。

const Alexa = require('ask-sdk-core');

const LaunchRequestHandler = {
    canHandle(handlerInput) {
        return Alexa.getRequestType(handlerInput.requestEnvelope) === 'LaunchRequest';
    },
    handle(handlerInput) {
        const speakOutput = 'ハローワールドスキルにようこそ。こんにちはと言ってみてください。';
        return handlerInput.responseBuilder
            .speak(speakOutput)
            .reprompt(speakOutput)
            .getResponse();
    }
};
const HelloWorldIntentHandler = {
    canHandle(handlerInput) {
        return Alexa.getRequestType(handlerInput.requestEnvelope) === 'IntentRequest'
            && Alexa.getIntentName(handlerInput.requestEnvelope) === 'HelloWorldIntent';
    },
    handle(handlerInput) {
        const speakOutput = 'こんにちは。私はアレクサです。';
        return handlerInput.responseBuilder
            .speak(speakOutput)
            //.reprompt('add a reprompt if you want to keep the session open for the user to respond')
            .getResponse();
    }
};

... snip ....

なお、上記のQiitaの記事では、ask-resources.jsonやskill-package/assets配下のアイコン画像のリネームもやっているようですが、

  • Alexa-hostedの場合、ask-resouce.jsonは以下のエントリしかないので修正する必要ががなさそう。
{
  "askcliResourcesVersion": "2020-03-31",
  "profiles": {
    "default": {
      "skillInfrastructure": {
        "type": "@ask-cli/hosted-skill-deployer"
      }
    }
  }

Alexa-hostedの場合はとりあえず不要です。

デプロイ

ではデプロイしてみましょう。ask deployを実行します。

$ ask deploy
[Warn]: Alexa hosted skills can be deployed by performing a git push.
The master branch gets deployed to skill's development stage
The prod branch gets deployed to skill's live stage
Please run "git push" at the proper branch to deploy hosted skill to your targeted stage.

おっと、これってもしかしてAlexa-hostedではCodeCommitのレポジトリが使えるってことですかね?

ということでドキュメントを見てみるときちんと書いてありました。

Gitを使ってAlexa-hostedスキルをデプロイする

Alexa-hostedスキルを作成した場合は、Gitを使ってスキルをデプロイします。

git pushコマンドを実行し、ローカルリポジトリmasterブランチから、Alexa-hostedスキルのあるリモートリポジトリ(通常はorigin)のmasterブランチにコードをプッシュします。

$ git push origin master


このコマンドは、最後に確定したバージョンをAlexa-hostedスキルにデプロイする場合に使用します。変更をプッシュすると、Alexa-hostedスキルはスキルパッケージリソースとリモートのmasterからのバックエンドのスキルコードの両方をデプロイします。Alexa-hostedスキルは、リモートのmasterブランチにプッシュするコードのみをデプロイします。

https://developer.amazon.com/ja-JP/docs/alexa/smapi/ask-cli-intro.html#deploy-skill

ということで、Alexa-hostedの場合はask deployは使わないようですね。。。masterが開発中ステージ、prodが公開中ステージということなので、masterにpushします。

$ git add .
$ git commit -m "日本語化"
$ git push
After the code pushed, please check the deployment status
via Alexa Developer console:
https://developer.amazon.com/alexa/console/ask/build/custom/amzn1.ask.skill.XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/development/ja_JP
Enumerating objects: 8, done.
Counting objects: 100% (8/8), done.
Delta compression using up to 8 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 627 bytes | 627.00 KiB/s, done.
Total 5 (delta 1), reused 0 (delta 0)
To https://git-codecommit.us-east-1.amazonaws.com/v1/repos/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/
   XXXXXXX..XXXXXXX  master -> master

では開発者コンソールで見てみましょう。

スキル一覧の表示がきちんと日本語になっています。

f:id:kun432:20200629032552p:plain

対話モデルも変わってますね。

f:id:kun432:20200629032641p:plain

そしてコードも書き換わっています。

f:id:kun432:20200629032612p:plain

これでデプロイ完了です!

まとめ

Alexa−hostedの場合、通常のAWSへのデプロイとはやり方が異なるようですね。gitのレポジトリがCodeCommit上に自動で作成されるようなので、コードも管理もやってくれるのはいいんですが、試してみた限りCodeCommitのUIへはアクセスできないっぽいです。まあhostedだとほぼほぼ個人のプロジェクトだろうし、githubみたいなUIは必要ないってことなんですかね・・・・

まあ普通には使えますので、そのうちCodeCommit見れるようになったらいいなーと期待してます。とりあえず今作っているタイマーAPI使ったスキルは、ask-cli v2で管理するようにしてみよう。

ご参考になれば。

VoiceflowでGoogleアクションを作る場合の連携手順がちょっとだけ変わりました

2020/12/19追記
VoiceflowのGoogleアクション連携はすでにDialogflowからActions Builderに移行しています。この記事の手順は、記事作成時点のDialogflowからActions Builderへの移行途中の手順であり、現在はもう不要です。

公式のフォーラムに質問が上がってたのですが、Googleアクション向けの新しいIDE「Actions Bulder」がリリースされたことにより、Actions on GoogleのUIがちょっと変わりました。それに伴い、VoiceflowでGoogleアクションを作る場合の連携手順が少しだけ変わっていますのでまとめておきます。

新しい連携手順

1. Actions on Googleへのアクセス

Actions on Google にアクセスして、"Go to Actions Console" をクリック。

f:id:kun432:20200628170805j:plain

2. プロジェクトの作成

"New project" をクリックして、新しいプロジェクトを作成していきます。

f:id:kun432:20200628170820p:plain

プロジェクト名を入力、言語・国を選択して、"Create Project" をクリック。

f:id:kun432:20200628171154p:plain

プロジェクトのタイプは "Custom" を選択、"Next" をクリックします。

f:id:kun432:20200628171010p:plain

変わったのはここですね。この画面で上にある6つの選択肢を選ぶと "Actions Builder" でプロジェクトが作成されてしまい、(おそらくですが)Voiceflowで連携できなくなってしまうと思います。

f:id:kun432:20200628173354p:plain

なので、一番下までスクロールすると・・・ここに以前と同じDialogFlowと連携させるためのリンクがありますね。こちらをクリックします。

f:id:kun432:20200628173649p:plain

はい、プロジェクトが作成されました。"Build your Action"をクリックして、表示される"Add Actions(s)"をクリックしてみます。

f:id:kun432:20200628181618p:plain

この画面が出ていればOKです。

f:id:kun432:20200628181748p:plain

実際に連携させるところまで試してないのですが、ざっと見た感じ、これ以降は過去の手順でいけると思いますので、DialogFlow/GCP/Voiceflowと連携していけば、VoiceflowでGoogleアクションが作成できるようになると思います。

あとはハンズオン資料をよしなに読み替えていただければと・・・m( )m

ちなみに、Actions BuilderとDialogFlowのどっちを使っているかは、Actions on Googleでプロジェクトを開いた際の左のメニューに違いが出ます。

DialogFlowと連携させている場合にはこんな表示になります。

f:id:kun432:20200628182346p:plain

Actions Builderの場合、こんな感じで選択できるメニューが多いです。DialogFlowでやってることがここでできるようになるのでメニューが多いというわけですね。

f:id:kun432:20200628182438p:plain

まとめ

まさかActions Builderができてこんなところに影響があるとは思いませんでした・・・

VoiceflowでAlexaスキルを作成する場合はAlexa開発者コンソールと連携させるだけなのでかんたんなのですが、Googleアクションの場合はActions on Googleだけではなく、DialogFlowだったりGoocle Cloud Platformだったりとも連携しないといけなくて非常にわかりにくいんですよね・・・

Actions Builder、細かいところまで触れてないのですが、Actions on Googleだけでほぼ完結するような印象なので、非常にわかりやすくていいですね。Voiceflowがこれに対応すればGoogleアクションを作る人がもっと増えるんじゃないかなと思ったりしてます。

ハンズオン資料もそのうち更新したいと思います(インタフェースも変わってるので時間かかりそう・・・)