omohayui blog

おも‐はゆ・い【面映ゆい】[形][文]おもはゆ・し[ク]《顔を合わせるとまばゆく感じられる意》きまりが悪い。てれくさい。

E2E Testing for Google Assistant Apps

これは何か?

先日、GDG Tokyo New Year LT大会 2021 で「E2E Testing for Google Assistant Apps」というテーマでLTをさせて頂いたのですが、5分では伝えきれない点があったので、こちらの記事に詳細を書くことにしました。

会話形アクションにこそ自動テストが必要

GoogleアシスタントアプリやAlexaスキルを作ったことがある方は、経験されているかもしれませんが、 会話型アクションをテストするのってすごく大変なんですね。
ちょっとインテントのフレーズを変えただけでも、その対象のシーンまで会話を持っていかないといけないので、何度も同じことを言ったりして労力を奪われてしまいます。
そこで必要になってくるのが End to End の自動テストです。
一度テストを作ってしまえば、改修のたびに都度都度、話しかけるという手間もなくなります。

Assistant Conversation Testing Library

github.com

Actions on Google には E2Eテストがコードベースで書けるライブラリが用意されています。
これは、Actions API をラップしていて、テストスイートを定義すれば、自分で作ったアクションにクエリを送信して、返ってきたレスポンスに対して検証することができます。
また、テスト実行前に Actions API の writePreview メソッドをコールすることで、Draftから自分のプロジェクトにプレビューを作成し、そこに対してテストすることができます。つまり、リリース前にひととおりの検証ができるってことですね。

Setup

Actions API を有効にする

従来のテストライブラリ actions-on-google-testing-nodejs ではテスト対象の Action のプロジェクトとは別のプロジェクトの Actions API を使ってテストができたのですが、こちらはテスト対象のプロジェクトで Actions API を有効にする必要があります。
また、比較的最近作られた Actionプロジェクトではデフォルトで Actions API は有効になっているそうです。

  1. Google API Consoleにアクセス
  2. プロジェクトをテスト対象のものに切り替え
  3. "Actions API" を検索し、もしenabled になっていない場合は enable にする

f:id:omohayui:20210207001841p:plain:w300

Service Account Key を作成する

  1. 同じプロジェクトで、Credentials pageにアクセス
  2. "Create credentials" > "Service account" をクリック
  3. service account name に actions のテスト用だと分かるような名前をつけて Create
  4. Role に "Actions" > "Actions Admin" を指定する
  5. Service Account Key をJSONファイルでダウンロード

f:id:omohayui:20210207002923p:plain:w300

READMEには Role(権限) に project.OWNER を付けろって書いてあったけど、強すぎる。actions.ADMIN で動いたのでこちらがおすすめ → こちら PullRequest 出したら merge してもらえました!

github.com

環境変数 GOOGLE_APPLICATION_CREDENTIALS の設定

ダウンロードした JSON ファイルを環境変数GOOGLE_APPLICATION_CREDENTIALS セットします。
他のプロジェクトでは使いたくないものなので、direnv などを使って .envrc に記載しておくのがおすすめです。

export GOOGLE_APPLICATION_CREDENTIALS=/path/to/service_account.json

ライブラリのインストール

npm install @assistant/conversation-testing --save
# 以下は必要な人は入れる
npm install @types/mocha --save
npm install mocha --save
npm install typescript --save

Test Code 作成

テストコードを書いていきます。
ここでは、今日食べるものを占ってくれる「カワウソ食べ物占い」のテストコードをサンプルにしています。

import 'mocha';
import {ActionsOnGoogleTestManager} from '@assistant/conversation-testing';

const PROJECT_ID = 'otter-fortune-telling-xxxxx';
const TRIGGER_PHRASE = 'カワウソ食べ物占いにつないで'; // 呼び出すフレーズ

const DEFAULT_LOCALE = 'ja-JP';  // 各言語の指定
const DEFAULT_SURFACE = 'PHONE'; // 各デバイスの指定

describe('Action project', function () {
  // write Preview するときは set timeout したほうが良い
  this.timeout(60000);
  let test: ActionsOnGoogleTestManager;

  before('setup test suite', async function() {
    test = new ActionsOnGoogleTestManager({ projectId: PROJECT_ID });
    await test.writePreviewFromDraft();
    test.setSuiteLocale(DEFAULT_LOCALE);
    test.setSuiteSurface(DEFAULT_SURFACE);
  });

プロジェクトIDには、テストしたいアクションのプロジェクトIDを記載し、トリガーフレーズにはアクションを呼び出すフレーズを入れます。 ロケールsurfaceでは、テストしたい言語やデバイスを指定することができます。

// おやつを占うテストパス
it('should match Snack Type, and end the conversation', async function () {
  await test.sendQuery(TRIGGER_PHRASE);

  // TestManager を使って API レスポンスをアサーションする
  test.assertSpeech('カワウソたべもの占いへようこそ! 占ってほしいのはランチ?ディナー?それともおやつ?');

  // ユーザークエリをアクションに返答する
  await test.sendQuery('おやつ');

  // 正規表現を使ってアサーションする
  test.assertSpeech(`ふむふむ。おやつか〜。\nそんな君におすすめのおやつは.*楽しみだね〜!もう一回やる?`, {isRegexp: true});

  // 会話を終了させる返答をする
  await test.sendQuery('やらない');
  test.assertSpeech('じゃあまたね!');
  // 会話が終了していることを確認する
  test.assertConversationEnded();
});

ここでは、テストスイートを定義しているのですが、お菓子を占ってもらって会話終了、という流れをテストしています。
このテストマネージャーには各種アサーションのメソッドが用意されているので、それを使ってレスポンスや、会話が終了していることを検証します。
もちろん正規表現やリストも使えるので、柔軟にテストは書いていくことができます。

// ランチを占ってから、もう一回占うテストパス
it('should match Lunch Type, and again the conversation', async function () {
  await test.sendQuery(TRIGGER_PHRASE);

  test.assertSpeech('カワウソたべもの占いへようこそ! 占ってほしいのはランチ?ディナー?それともおやつ?');

  await test.sendQuery('ランチ');
  test.assertSpeech(`ふむふむ。ランチか〜。\nそんな君におすすめのおやつは.*楽しみだね〜!もう一回やる?`, {isRegexp: true});

  // 会話を続ける返答をする
  await test.sendQuery('やる');
  // シーンAgainに遷移したことを確認する
  test.assertScene('Again');
  test.assertSpeech('占ってほしいのはランチ?ディナー?それともおやつ?');
  // 会話が終了していないことを確認する
  test.assertConversationNotEnded();
});

このテストでは、占ったあとに会話を終了せずにシーン Againに遷移することをテストしています。

Run Tests

先程作成したテストコードのファイルは、src/test/ 下に配置します。 そして、package.json に以下の script コマンドを追加しておきます。

  "scripts": {
     "test": "mocha --recursive --require ts-node/register src/test/*.ts",
   },

テストを実行します。

npm run test

出力結果

Failed した結果

f:id:omohayui:20210207155659p:plain:w600

「もう一回やる?」「やる」のあとに、シーン Again に遷移してほしいのに、会話が終了してしまい、期待値と異なるメッセージが返ってきています。 そして、コンソールには期待したレスポンスと実際に返ってきたレスポンスのDIFFが表示されます。

Pass した結果

f:id:omohayui:20210207155756p:plain:w800

レーニングフレーズを修正すると、テストが通りました。

Assertions 各種

用意されているアサーションは、assertSpeech や assertScene だけではありません。 Assertions を確認してください。

  • assertText - テキストレスポンスの検証
  • assertCard, assertImage, assertTable, etc - 各表示要素の検証
  • assertIntent - クエリにマッチしたインテントの検証
  • assertSessionParam, assertUserParam, assertHomeParam - セッションストレージなどストレージへのパラメータの検証

ただ、まだビルトインインテントトランザクションのテストは未対応となっているので、これから拡張されることを期待しています。

まとめ

  • 会話型アクションのインテグレーションテストはとても大変
    • でも自動テストがあれば改修も気軽にできる
  • Actions on Google には E2Eテスト用のライブラリが提供されている
    • Draft の状態に対して E2Eテストができるので、リリースする前の自動テストとして利用できる
    • テストモジュールにはさまざまなアサーションが用意されているので、ディスプレイに表示する要素のテストもできる
    • 現時点では、ビルトインインテントトランザクションのテストは未対応

所感:やはりこれだけの内容を5分でやるのは無理があった・・・

DevFest 2020 で Local Home SDK を使った開発の話をしました

これは何か?

先日、GDG DevFest Tokyo 2020 と言うイベントで、
「Local Home SDK を使った Local Fulfillment とオリジナルホームデバイスの開発について」という話をしてきました。

DevFest は、Google Developer Group (GDG) コミュニティによって世界各地で開かれるデベロッパー向けイベントです。
そんな規模の大きいイベントに登壇させていただけるのは恐縮なのですが、せっかくなので話した内容をより詳しく記事にしようと思います。

発表自体は Youtubeに上がっているので、気になる方は Google Home のマイクをオフにして、ご視聴ください(私が発表内で「OK Google」を連呼した為に、複数の視聴者が被害に遭われました。。。)

youtu.be

発表内容詳細

Agenda

  1. Smart Home Action について
  2. Smart Home 統合フロー
  3. Local Fulfillment を使った構成
  4. Local Fulfillment を使うメリット
  5. Local Home SDK を使った開発方法
  6. オリジナルホームデバイスのデモ
  7. 使ってみた感想など

Definition of the term

本資料での用語定義💡

※ 注意したいのは、デベロッパーとは Google Assistant 本体を開発している人でなく、ホームデバイスを開発している人です。

Smart Home Action

f:id:omohayui:20201021235520p:plain
smart home action

Smart Home Action を構築すると、ユーザーが “OK Google 電気をつけて” と自宅の Google Home に話かけると、デベロッパーの Cloud Fulfillment が呼び出され、ユーザーの自宅にあるホームデバイスを制御できるようになります。 また、ユーザーはボイスコントロールだけでなく、iOSAndroidなどのスマートフォンGoogle Home アプリからリモコン操作のように各デバイスを制御することもできます。

Smart Home Controls

Smart Home Control
これは余談ですが、Android11 では電源ボタン長押しでホームデバイスの操作ができるようになりました。
これでさらにホームデバイスの操作が簡単になったかと思います。

Smart home integration flow

Google Home からホームデバイスを管理できるようになるまでの Smart Home のフローを説明していきます。

Sync Device

f:id:omohayui:20201022000438p:plain
Sync Device
まずユーザーは Google Home アプリでホームデバイスを登録します。
このタイミングで、アシスタントはデベロッパーの Fulfillment に SYNC インテントを送信して、ホームデバイスの情報と Traits と言うデバイスが持っている機能のリストを取得します。
本来はこの前にデベロッパーのサービスを認証するためにデベロッパーが用意した Authorization URL, Token URL にアクセスし、アシスタントは OAuth Token を取得する必要などがありますが、この図からは省略しています。
今この図を見ると、SYNC インテントに対して Cloud Fulfillment が、デバイスタイプ LIGHTで、ON/OFFの traits が使えるよという情報を返しているのが分かると思います。

  • Device Type - ホームデバイスの種別
    • CAMERA, DISHWASHER, DRYER, LIGHT, OUTLET, PHONE, REFRIGERATOR, SPEAKER, SWITCH, THERMOSTAT, TV, VACUUM, WASHER など
  • Traits - デバイスが持っている機能のリスト
    • OnOff, StartStop, Brightness, ColorSpectrum, ColorTemperature, Dock, TemperatureSetting など

SYNCインテントに返す Device Type, Traits はデベロッパーが自由に指定できるものではなく、Google Assistant 側で予め定義されたものです。 自分で作ったホームデバイスを、どの DeviceType にして、どの Traits を受け取るようにするか決める前に、ドキュメントで定義されたものの一覧を確認することをおすすめします。

Execute Command

f:id:omohayui:20201022000856p:plain
Execute Command

ユーザーが Google Home に “OK Google 電気をつけて” と話しかけるとデベロッパーの Fulfillment は電気をONにする実行コマンドを含む EXECUTE インテントを受け取ります。
そして、Fulfillment はユーザーの自宅にあるホームデバイスに対して電気をONするというリクエストを行います。

Query Device Status

f:id:omohayui:20201022001019p:plain
Query Device Status

「リビングの電気は点いてる?」とユーザーが Google Home に質問したり、「音量を上げる」「明るさを上げる」のような相対的なコマンドを処理するときに、アシスタントは QUERY インテントデベロッパーの Fulfillment にリクエストします。
そして、Fulfillment はデバイスの状態をアシスタントに返してあげます。
この図だと、デバイスは今、ONになっているよというのをアシスタントに返しています。

Smart Home with Local Fulfillment

f:id:omohayui:20201022001143p:plain
Smart Home with Local Fulfillment

一連の流れで、ホームデバイスを操作するには、デベロッパーは Execute Command を受け取ってホームデバイスへそれを伝える Cloud Fulfillment を作成する必要がありました。 ですが、Local Home SDK を利用すると、Local Fulfillment を作成し Google Home 上でデベロッパーが書いた JavaScript を動かし、ホームデバイスを制御することができます。 また、Cloud Fulfillment は Local Fulfillment が機能しなかった際の fallback としても機能します。

Benefits of using Local Fulfillment

ホームデバイスを提供する企業としてのメリット🏭

  • Cloud Fulfillment を経由しないので、遅延が少ない、安定稼働できる
  • Local Fulfillment が動かない時は Cloud に fallback させることができる

オリジナルホームデバイスを作成する個人のメリット👩‍💻

  • ローカルネットワークからデバイスを操作できるので、マイコンボードで作ったデバイスと連携が簡単
  • バイスはローカルネットワークからしか叩かれないのでセキュリティリスクが下がる

How to use Local Home SDK

Implement Local Fulfillment app

Local Fulfillment に必要な Handler

  • IDENTIFY handler
  • EXECUTE handler
  • REACHABLE_DEVICES handler (only Hub)

※ REACHABLE_DEVICES Handler は、IDENTIFY Handler がアクセスするホームデバイスをプロキシとして利用したい場合にのみ必要になります。

IDENTIFY handler

f:id:omohayui:20201022001630p:plain
IDENTIFY handler

Google Homeバイスが再起動時に、ローカルネットワーク上で未確認のデバイスを検出すると、IDENTIFY handler をトリガーします。
このとき Google Home がスキャンする構成は、Actions console で設定した値に基づいてデバイスを探しに行きます。
IDENTIFY Handler は、ホームデバイスがスキャンに対して返すデータ(local device id)を取得し、これをアシスタントに送信します。
そして、IDENTIFY Handler からの verificationId が前述に登場した SYNC インテントが取得した other Device Ids のいずれかと一致する場合、アシスタントはホームデバイスの関連付けを確立します。

EXECUTE handler

f:id:omohayui:20201022001813p:plain
EXECUTE handler

アシスタントは、Cloud Fulfillment への EXECUTE Intent と同じ入力値を EXECUTE handler に渡します。 同様に、EXECUTE hander は、EXECUTE Intent の処理と同じ形式で出力データを返します。
また、Localfulfillment は、デバイスIPアドレスに直接アクセスできません。 代わりに、CommandRequestインターフェイスを使用して、UDPTCP、またはHTTPのいずれかのプロトコルに基づいてコマンドを実行します。

How to debug Local Fulfillment

Google Home 上で動いている Javascript をどうやってデバッグして開発するのか?というところを説明します。
Actions console 上の Testing URL に、自分で作成した Local Fulfillment を実行する HTMLページのURLを追加すると、 Google Home 上で実行される JavascriptデバッグChrome の DevTools 上で出来ます。

f:id:omohayui:20201022002155p:plain
Actions console

f:id:omohayui:20201022002312p:plain
Chrome DevTool

Demo

youtu.be

1.スマホGoogle Home アプリからデバイスを追加します。
今回は Otter Light というデバイスを Otter Smart Home というスマートホームアクションに作成しているので、最初に Otter Smart Home というサービスとアカウント連携をします。
アカウントをリンクさせたら、追加するデバイスを選んで、ホームを選んで、部屋を選んで、すると、Otter Light がアプリ上から操作できるようになります。

2.次に、Google Home 上で動作するJavaScriptデバッグします。
Chrome の DevTool の inspect を開いて、Nest Audio の inspect のリンクをクリックします。
すると Console Log に Nest Audio を再起動したタイミングだったり、一定間隔でリクエストしてきた IDENTIFY hander のログが確認できます。

3.アプリから実行してみます。 ラズパイ上で動いている UDP サーバが、Nest Audio から Execコマンドを受け取り、赤外線が送られて電気がついたり、消えたりしてます。
4.最後に Google Home から声で実行してみます。

使ってみた感想

  • Local Home SDK は手軽に Google Home や Home アプリと連携ができて便利
  • QUERY Intent を処理しようとすると Cloud Fulfillment 上でデバイスのステータスを管理しなくてはいけない
    • Cloud ↔ Home Deviceのやり取りは無くならない、元々 Fallback は必要な前提だと思われる
  • Local Fulfillment の修正を反映するのに時間がかかる
    • Google Home を再起動してから反映されるまで10, 20分待つこともある

おまけ

Twitter で「(デモで使っている赤外線が)結構遠くまで届いてそうだったので何を使っているのか気になる」という話が上がっていたので、赤外線学習リモコンモジュールという強力で便利なやつを紹介しました。

[Amazon] BitTradeOne ラズベリーパイ専用学習リモコン基板 [ 完成品 ] ADRSIR

(翻訳とサマリ) Dialogflow to Actions Builder migration tool

これは何か?

先日、Actions on GoogleでDialogflowを使用して作成した既存アクションを、Actions Builderに移行する方法と移行ツールが公開されました。

ただ、ドキュメントに書かれているように、Actions Builderへの移行は必須ではなく任意です。
Dialogflow自体は今後も使えますし、既存のアクションは引き続きGoogleアシスタントバイスで機能します。

また、DialogflowとActions Builderとの機能差分は大きく、そのまま同一プロジェクトで移行してしまうと既存のアクションを破壊してしまう可能性もあるので、かなりリスクがあると思います。

まずツールを使う前に、何が移行されるのか、移行のメリットは何かといったところを確認しようと思い、内容を確認するために翻訳してみました。

 

この記事では、下記のページをまとめて翻訳しています。

先にまとめ

この記事を見ていただければわかると思いますが、内容がかなり多いので、重要と思われるところをまとめました。

  • 移行のメリットは大きいが、移行は必須ではない!(重要

  • 移行ツールには2つの方法がある

    • 1. 新規プロジェクトに移行(推奨)

    • 2. 既存プロジェクトで移行

    • (2) を選ぶとしても、移行試験用に(1)をまず試してからにすべし

  • 移行レポートは後で検証できるようにダウンロードしておくべし
  • 移行できるもの、移行できないもの、移行できるが手動操作が必要なものがある

    • 移行できるもの
      • 「移行ツールの機能」を参照すべし
    • 移行できないもの
      • 複数の入力コンテキストを持つインテント。シーンは手動で作成する必要がある
      • Dialogflowでカスタムイベントを使用するインテント
      • 日付または数値ではないDialogflowシステムエンティティ。これらのエンティティは新しいタイプとして作成されるが、類義語を手動で追加する必要がある
      • DialogflowフルフィルメントソースコードAPIバージョンの違いにより、このコードはBuilderに移行されない
  • Actions on Google Node.jsクライアントライブラリを使用している場合は、Actions SDK Node.jsライブラリを使用するようにコードを手動で更新する必要がある

    • 「フルフィルメントコード変換マップ」参照すべし

(追記) 移行ツールを試して分かったこと

  • "Migrate"ボタンを押すと即反映される
  • 移行後もDialogflowには設定はそのまま残る
  • シーンを追加したりフローを再構築するにあたって色々検討事項がある
  • フルフィルメントを新SDKに書き直すのが結構大変
  • 既存SDKで使っていたpromptのUI Elementsが新SDKで用意されていなかったりする
  • →BrowseCarouselに対応する移行後のInterfaceがなかったので、別のElementで代用するのに苦戦した。(UIがかなり変わってしまった)

DialogflowからActions Builderへの移行ツール (Ja)

(原文) https://developers.google.com/assistant/conversational/dialogflow-to-builder

Actions Builderは、会話型アクションを簡単かつ合理的に構築するのに役立つため、Googleアシスタント向けに構築するのに最適な方法です。Actions Builderは、Actions Consoleに統合されたWebベースのIDEであり、次の機能を提供します。

  • アクションの会話を制御するための視覚的なワークフローと状態ベースの方法
  • プロトタイピングの高速化と待ち時間の短縮
  • 会話型アクションを構築、分析、デバッグするための単一のインターフェース

Dialogflowで作成した会話型アクションがある場合は、アクションコンソール内でプロジェクトをActions Builderに移行することを選択できます。

注:DialogflowプロジェクトのActions Builderへの移行は任意です。

移行する理由

Dialogflowエージェントを移行することは必須ではなく、アクションは引き続きGoogleアシスタントバイスで機能しますが、Actions BuilderとActions SDKを使用することには利点があります。

  • Actions SDKCLIによるツールの改善
    • Actions SDKCLIを使用すると、複雑なプロジェクトを構築し、チームと簡単にコラボレーションできます。会話デザイナーは、最初にActions Builderで会話フローを構築できます。その後、開発者はプロジェクトをファイルベースの構造にダウンロードし、お気に入りの開発ツールとバージョン管理システムを使用して機能を構築し続けることができます。プロジェクトをActions Builderにプッシュバックすることにより、他のチームメイトはアクションのビルド、テスト、およびデプロイを続行できます。
  • 会話デザインのベストプラクティスとのより良い統合
    • 各シーン内のフォールバックインテントのカスタマイズにより、会話の任意の時点で入力なしおよび一致なしの応答を提供できます。
    • 会話型エクスペリエンスを構築するグラフィカルな状態ベースの方法により、デザイナーと開発者の間の簡単なコラボレーションが実現できます。
  • より簡単なローカリゼーション
    • インテント、シーン、タイプ(トレーニングフレーズ、プロンプト、タイプの類義語など)のローカライズ可能なすべてのコンテンツを1つのページで編集できます。https://developers.google.com/assistant/conversational/images/dialogflow-to-builder/translation.png

会話型実装の改善

Actions Builderは、Actions Consoleに多くの改善をもたらし、開発プロセスを簡素化します。このセクションでは、Actions Builderがアクションの開発プロセスを合理化および簡略化する方法について説明します。

インテントの再利用性

Dialogflowでは、Webhookロジックはインテントに関連付けられています。つまり、インテントは他のWebhookで再利用できません。同じトレーニングフレーズを使用するが、Webhookロジックが異なる場合は、Webhookロジックのケースごとに異なるハンドラー名を参照する追加のインテントを作成する必要があります。  

Actions Builderでは、インテントにはトレーニングフレーズとエンティティが含まれますが、Webhookは独立しています。このアプローチは、同じインテントに対して異なるWebhookハンドラーを使用できることを意味し、柔軟性を高めます。

会話フローの視覚化の改善

Dialogflowでは、コンテキストは、会話の特定の時点で、どのインテントが一致する可能性が高いかを示します。  

コンテキストの代わりに、Actions Builderはシーンを使用して、会話のさまざまな部分でアクセス可能なインテントを処理します。  

ユーザーがシーンに入ると、遷移(トランジション)はユーザーが取ることができる会話パスを定義します。遷移は、条件付きロジック、およびカスタムまたはシステムインテントマッチングに基づくことができます。

Actions BuilderのUIにより、トランジションがシーンをどのように接続するかを簡単に理解できます。図1では、シーンguess_gamesuggested_new_gameシーン(1)に遷移します。また、シーン内で2つのアクセス可能なインテントを表示することもできます:generic_nogeneric_yes。一致するインテントに応じて、suggested_new_gameシーンはshow_menuまたはrouting_gameシーンに遷移します(2)。

https://developers.google.com/assistant/conversational/images/dialogflow-to-builder/builder-scene.png

図1.シーンの遷移(1)とインテント処理(2)を含むシーンのグラフィカルビュー

シナリオに基づいてカスタマイズ可能なプロンプト

Dialogflowでは、Webhookで単純な応答を送信するか、Dialogflowコンソールで静的応答を定義できます。

Actions Builderでは、プロンプトキューの概念が導入されています。プロンプトは、シーンの複数のセクションとWebhookで定義できます。すべてのプロンプトがプロンプトキューに追加され、1つの応答にマージされて、ユーザーに配信されます。このアプローチにより、ユーザーが一致したインテントだけでなく、ユーザーの発言または実行に基づいて応答をつなぎ合わせることができます。

たとえば、シーン Webhookでプロンプトが定義されている場合、最初にWebhookプロンプトがプロンプトキューに追加され、次にシーンプロンプトが追加されます。

次のリストは、Actions Builderでプロンプトを定義できる場所と、プロンプトキューに追加される順序の概要を示しています。

  1. On enter (入力時)
  2. Conditions (条件)
  3. Slot filling (スロットフィリング)
  4. Scenes (シーン)

注:Webhookの呼び出しは、プロンプトをシーン内で定義できる場所であればどこでも有効にできます。すべての場合において、シーンプロンプトとWebhookプロンプトの両方が提供されると、Webhookプロンプトがシーンプロンプトの前にキューに追加されます。

組み込みの会話デザインのベストプラクティス

Dialogflowプロジェクトが設定されると、デフォルトのウェルカムインテントと同様に、グローバルフォールバックインテントが自動的に生成されます。デフォルトのフォールバックインテントは、ユーザーが既存のインテントと一致しないものを言うとき、またはユーザー入力がないときに一致します。

エラーを適切に処理するには、会話のターンごとに、フォールバックインテントにフォローアップインテントを追加する必要があります。

Actions Builderでは、NO_MATCHNO_INPUT という2つのグローバルインテントは、自動的に予めプロジェクトに含まれています。

Assistant NLUがNO_MATCHまたはNO_INPUTシステムのインテントに一致すると、それぞれのデフォルトまたはカスタマイズされたプロンプトがユーザーに送信されます。

1 回NO_MATCHまたはNO_INPUTに3回一致すると、それぞれの最終メッセージがユーザーに送信され、アシスタントはアクションとの会話を終了します。

各シーンに3つのNO_MATCHおよびNO_INPUTハンドラーを追加できます。 この機能により、ユーザーの一致や入力がないために発生する一般的なフォールバックの代わりに、特定のエラー処理のためのカスタマイズ可能なプロンプトが可能になります。

https://developers.google.com/assistant/conversational/images/dialogflow-to-builder/system-intents.png

図2. 1つのシーンに割り当てられた3つのNO_MATCHNO_MATCHインテントハンドラー

 

 

DialogflowからActions Builderプロジェクトへの移行 (Ja)

(原文) https://developers.google.com/assistant/conversational/project-migration

 

Dialogflow開発者は、既存のアクションをActions Builderに移行することができます。新しいコンソール内メソッドを使用してアクションを開発することには多くの利点があり、既存のDialogflowプロジェクトの移行は簡単です。このページでは、Dialogflow / Actions Builder移行ツールの使用方法について説明します。

このガイドを読む前に、DialogflowからActions Builderへの移行の概要をご覧ください。重要な概念と、DialogflowとActions Builderの違いについて説明しています。

移行ツールの機能

DialogflowからActions Builderへの移行ツールは、インテントやエンティティなどの特定のDialogflow要素をAction Builderで動作するように変換します。

移行ツールは、次のDialogflow要素をActions Builderに自動的に移行します。

  • Dialogflowのデフォルトのウェルカムインテント。メインの呼び出しとして移行されます。
  • アクションがサポートする各言語のすべてのトレーニングフレーズとエンティティ。
  • グローバルインテントとして移行される、入力コンテキストのないインテント
  • シーンとインテントとして移行される、1つの入力コンテキストを持つインテント
  • 1つの入力コンテキストとスロットフィルを含むインテントは2つのシーンになり、1つのインテントはスロットフィルでシーンへの遷移を処理します。
  • Dialogflowフォールバック、メディア、ウェルカムイベントを使用するインテントは、関連するActions Builderハンドラーとトレーニングフレーズ付きのインテントになります。
  • Dialogflowの日付と数値のシステムエンティティを使用するインテントは、関連するActions Builderシステムタイプになります。

移行ツールは、次のDialogflow要素を処理しません

  • 複数の入力コンテキストを持つインテント。シーンは手動で作成する必要があります。
  • Dialogflowでカスタムイベントを使用するインテント
  • 日付または数値ではないDialogflowシステムエンティティ。これらのエンティティは新しいタイプとして作成されますが、類義語を手動で追加する必要があります。
  • DialogflowフルフィルメントソースコードAPIバージョンの違いにより、このコードはBuilderに移行されません。

移行ツールにアクセスする

移行ツールにアクセスするには、アクションコンソールでDialogflowプロジェクトを開き、Develop > Actions に移動します。

アクションコンソールで使用されているプロジェクトが不明な場合は、Dialogflowコンソールに移動して、次の手順に従います。

  1. 移行するプロジェクトを開き、Settings アイコンをクリックします。
  2. General > Project ID 下の Action on Google リンクをクリックします。この手順では、特定のプロジェクトのアクションコンソールに移動します。
  3. Develop > Actions にアクセスし、Preview migration をクリックします。

https://developers.google.com/assistant/conversational/images/dialogflow-to-builder/migration-banner.png

インフォスライドを確認し、Start migration をクリックして、移行ダッシュボードを表示します。

移行ダッシュボード

移行ダッシュボードには、移行オプションと、移行するアイテムに関連する情報が表示されます。

https://developers.google.com/assistant/conversational/images/dialogflow-to-builder/migration-dashboard.png

移行オプション

移行ツールには、DialogflowプロジェクトをActions Builderに移行するための2つのオプションがあります。

  • 新しいプロジェクトとして移行(推奨)
    • 既存のDialogflowプロジェクトをそのまま維持し、コピーを新しいプロジェクトに移行します。
    • 表示名とディレクトリ情報は、既存の本番プロジェクトに関連付けられたままです。移行したプロジェクトでライブプロジェクトを上書きする方法についての推奨プロセスをご覧ください。
  • このプロジェクトを移行する
    • 既存のDialogflowプロジェクトを置き換え、プロジェクトに定義した既存の表示名とアシスタントディレクトリ情報を保持します。
    • 注意:この移行オプションを元に戻すことはできません。既存のDialogflowプロジェクト、および表示名とディレクトリ情報が移行されます。この移行オプションを使用する際の考慮すべき事項:
      • 運用アクションは引き続き有効ですが、何らかの理由で更新する必要がある場合は、最初に手動の移行手順を完了する必要があります。
      • Dialogflowプロジェクトは引き続き編集できます。ただし、表示名とディレクトリ情報は、移行されたActions Builderプロジェクトに関連付けられます。

移行レポート

移行レポートの各セクションを展開して、以下の情報に関するプロジェクト固有の詳細を表示できます。

  • 完全に移行されるもの
  • 移行されるが、追加の移行後の設定が必要になるもの
  • 移行されず、手動で追加する必要があるもの(必要な場合)
  • Dialogflowプロジェクトで使用できるが、Actions Builderでは使用できない機能

移行レポートをダウンロードすることもできます。このレポートは、プロジェクトに移行後の変更を加えるときに参照できます。

注:Dialogflowプロジェクトを移行すると、一部の履歴分析データはアクションコンソールに移行されません。移行する前に、分析データをエクスポートすることを検討してください。

移行後のセットアップ

移行ツールはDialogflowプロジェクトの重要な部分をActions Builderに移動させるのに役立ちますが、移行されなかった遷移、プロンプト、Webhookを設定するには、追加の開発が必要です。

シーンを使用するように会話フローを更新する

移行ツールは、1つの入力コンテキストを持つDialogflowインテントに基づいてシーンを生成しますが、これは1対1の関係ではありません。新しい会話モデルでは、マイグレーションされたシーンの一部はActions Builderで意味をなさない場合があります。

必要なシーンを評価して、会話の流れを再考する必要があるかもしれません。アクションの複雑さによっては、生成されたシーンの一部が会話の流れに合わなくなった場合、削除する方が簡単な場合があります。

グローバルインテントの確認と更新

入力コンテキストのないDialogflowインテントは、グローバルインテントとしてActions Builderに移行されます。グローバルインテントは会話全体でアクティブです。つまり、いつでも一致させることができます。

グローバルインテントを使用して、ユーザーがアクションを呼び出したときに、ユーザーを特定のフローにディープリンクすることもできます。

生成されたグローバルインテントがアクティブで、グローバルスコープのユーザーがアクセスできるかどうかを検証することが重要です。 グローバルインテントを通常のインテントに変更するには、インテントをクリックして、グローバルインテント処理オプションをNOに変更します。

 

https://developers.google.com/assistant/conversational/images/dialogflow-to-builder/global-intent.png

共通するトレーニングフレーズでインテントを統合する

一部のインテントが非常に類似したトレーニングフレーズを共有している場合は、インテントを単一の汎用インテントに統合する必要があります。これにより、インテントマッチングの精度が向上します。

たとえば、インテントAには次のトレーニングフレーズがあります。

  • 「OK、準備ができていることを確認したい」
  • 「よし、これで準備完了」
  • 「やってみましょう」

インテントBには、次のトレーニングフレーズがあります。

  • 「OK、準備ができていることを確認したい」
  • 「よし、準備はできていると思う」

2つのインテント間のトレーニングフレーズは類似しているため、インテントAインテントBをより一般的なインテントインテントC)に統合し 、元のインテントを削除します。そして、インテントAまたはインテントBを参照するシーンでインテントCを使用します 。

インテントCには、次のトレーニングフレーズがあります。

  • 「OK、準備ができていることを確認したい」
  • 「よし、これで準備完了」
  • 「やってみましょう」
  • 「よし、準備はできていると思う」

イベント処理の更新

Dialogflowで特定のイベント(フォールバック、メディア、ウェルカム)を使用するインテントの場合、移行ツールはそのイベントに関連するシステムインテントを作成します。 同じDialogflowインテントにトレーニングフレーズがある場合、同じトレーニングフレーズを使用して追加のインテントが作成されます。

https://developers.google.com/assistant/conversational/images/dialogflow-to-builder/system-events.png

Actions Builderでイベントの設定を完了するには、必要に応じて、遷移だけでなくWebhookハンドラーを追加する必要があります。

https://developers.google.com/assistant/conversational/images/dialogflow-to-builder/webhook.png

フォールバックインテントを処理するシステムインテントを追加する

Dialogflowでは、フォールバックインテントは、インテントがユーザーの入力を認識しないケースをハンドリングします。Actions BuilderはNO_MATCHNO_INPOUTこれらのケースを処理するためにシステムインテントを利用します。

NO_MATCHNO_INPUTシステムインテントの両方を最大3回までシーンに追加できます。たとえばNO_MATCH、シーンに3つのインテントを追加すると、アクションがユーザーの応答で何を求めているかについて、より詳細に段階的に応答できるようになります。

Dialogflowプロジェクトがフォールバックインテントを利用したシステムインテントを追加することが重要です。 一般的に使用されるActions Builderシステムインテントの例には、NO_MATCHとNO_INPUTがあります。 これらのシステムインテントの詳細については、システムインテントを確認してください。

フルフィルメント戦略を更新する

DialogflowフルフィルメントコードをActions Builderに移動することは、移行プロセスの中でも大きな部分の1つです。Webhook呼び出しと一般的なフルフィルメントの概念は同じですが、Actions Builderは機能を再利用するためのオプションを提供し、より多くのWebhookトリガーの機会を追加します。

これを念頭に置いて、Actions Builderの機能を利用するためにプロジェクトのフルフィルメントを再検討することを検討してください。

  • カスタムwebhookハンドラー名は、異なるシーンの複数の部分から同じwebhook関数を呼び出すことができることを意味します。
  • Webhookの呼び出しは、シーンの入力、条件付き検証、スロットフィリング、インテントマッチングに基づいて行うことができます。Webhookの呼び出しがいつどこで行われるかをより詳細に制御できるため、よりクリエイティブなフルフィルメントソリューションが可能になります。

フルフィルメントコードを更新するときは、いつどこでWebhook呼び出しをトリガーするかを検討します。Call your webhookオプションを使用して、シーンの複数の部分でWebhookを有効にできます。Webhookの有効化の詳細については、フルフィルメント移行ガイドのWebhookセクションをご覧ください。

移行の例(サンプルコード)

DialogflowからActions Builderに移行されたプロジェクトは、各ツールが使用する会話モデルが異なるため、構造が大きく異なります。Actions Builderでのシーン、プロンプト、トランジションの使用、および再利用可能なWebhookハンドラーなどの機能により、移行されたプロジェクトのコードは元のプロジェクトと大幅に異なります。

移行したプロジェクトを比較すると、DialogflowからActions Builderに移行するときに必要な変更の種類と範囲を理解するのに役立ちます。次の移行されたサンプルプロジェクトを確認して、実装を比較できます。

サンプルプロジェクト

Dialogflowコード

Actions Builderコード

Googleの実績

プロジェクトコード

プロジェクトコード

トランザクション

プロジェクトコード

プロジェクトコード

アカウントのリンク

プロジェクトコード

プロジェクトコード

推奨される移行プロセス

このセクションでは、推奨される移行プロセスについて説明し、現在の表示(呼び出し)名、ディレクトリ情報、および履歴分析を保持できるようにします。

このプロセスには、2つの異なるActions Builderプロジェクトでの作業が含まれます。どちらも同じDialogflowプロジェクトから移行されます。明確にするために、これらのプロジェクトは次のように呼ばれます。

  • experimental:このプロジェクトは、移行のセットアップとテストに使用されます。
  • original:このプロジェクトは現在ライブで、ユーザーにサービスを提供しています。

プロジェクトを移行するには、次の手順を実行します。

  1. Dialogflowのエクスポート機能を使用して、Dialogflowプロジェクトのバックアップを作成します。
  2. アクションコンソールに移動し、移行するプロジェクトを開きます。
  3. Develop > ActionsPreview migration クリックします。
  4. インフォスライドをクリックしていき次に、Start migrationをクリックします。
  5. Migrate as a new project (新しいプロジェクトとして移行)を選択します。
  6. 移行レポートを確認し、オプションで後の確認用にダウンロードします。
  7. Migrateクリックします。
  8. 実験用プロジェクトの名前を入力し、Create Project をクリックします。プロジェクトIDを書き留めます。
  9. 必要な移行後の設定を完了し、アクションが意図したとおりに機能していることを確認します。
  10. gactions CLIを使用して、実験用プロジェクトのドラフトを取得します。
    gactions pull --project-id experimental-project-id
  11. アクションコンソールで「元の」Dialogflowプロジェクトを再度開きます。
  12. Develop > ActionsPreview migration クリックします。
  13. Migrate this projectを選択します。
    注意:この手順を完了する前に、実験用プロジェクトが期待どおりに機能していることを確認してください。
  14. Migrate をクリックします。
  15. More icon > Project settingsをクリックし、プロジェクトIDをメモします。
  16. ローカルシステムで、Pullした実験用プロジェクトのsettings.yamlファイルを開き、プロジェクトIDを「元の」プロジェクトのプロジェクトIDに置き換えます。
  17. gactions CLIを使用して、ローカルに保存されたプロジェクトのドラフトをプッシュします。
    gactions push
  18. アルファチャネルまたはベータチャネルを介して公開する手順に従うか、アクションをプロダクションに公開します。

 

 

フルフィルメントの移行 (Ja)

(原文) https://developers.google.com/assistant/conversational/fulfillment-migration

 

インテントとシーンを設定したら、フルフィルメントのコードを更新して、Actions Builderのリクエストとレスポンスのフォーマットの変更に対応する必要があります。これは、Actions Builderの追加機能の利用を検討する機会でもあります。このページでは、フルフィルメントコードを更新する際の一般的な手順と考慮事項について説明します。

フルフィルメントのアプローチを検討する

プロジェクトのフルフィルメントコードは、会話型モデルと開発プラットフォームの機能に依存しています。Actions Builderは、会話の構築方法を変更する新しい会話モデルと機能を導入し、プロジェクトの遂行へのアプローチ方法を変更する可能性があります。このセクションでは、Dialogflowとは異なるActions Builderの機能と、これらの違いがフルフィルメントコードの実装方法をどのように変えるかについて説明します。

  • 会話実装の変更
  • 再利用可能なWebhook関数
    • Dialogflowでは、Webhookハンドラは個々のインテントに関連付けられています。追加のロジックが必要な場合は、新しい関数を処理する別のインテントを作成する必要があります。
    • Actions Builderでは、Webhookハンドラーにカスタムハンドラー名があります。この機能により、プロジェクト全体の複数のシーンから関数を呼び出すことができます。
  • Webhookを呼び出すその他の方法
    • Dialogflowのインテントアプローチごとに1つのWebhookを使用するには、プロジェクトのフルフィルメント内で会話ロジックを促進するために追加のインテントが必要です。
    • Actions Builderを使用すると、シーン内の複数の場所からWebhook呼び出しを行うことができます:開始時、条件、スロットフィリング、カスタムおよびシステムインテントマッチング。

フルフィルメントコードを更新する

各アクションのフルフィルメントコードは、アクションの複雑さと目的に応じて異なりますが、コードを更新するときに行う一般的な手順があります。

 

  1. クライアントライブラリの最新バージョンをダウンロードしてインストールします。
    npm install @assistant/conversation
  2. requireコード内のステートメントを更新します。例:

    const {

      SimpleResponse,

      BasicCard,
      Image,
    } = require('actions-on-google');


    上記のコードは次のように更新されます。

    const {

      conversation,

      Simple,

      Card,

      Image,

    } = require('@assistant/conversation');

  3. 新しいメソッドを使用するようにコードをリファクタリングします。
    • インテントハンドラー:app.intentapp.handle
    • レスポンス/プロンプト:conv.askconv.add
    • 表面/デバイス機能:conv.surface.capabilities.has('actions.capability.SCREEN_OUTPUT')conv.device.capabilities.includes('RICH_RESPONSE')
    • データストレージ:conv.dataconv.session.params
    • レスポンスタイプ:
      • SimpleResponseSimple
      • BasicCardCard
      • SuggestionsSuggestion
    • インテントパラメータ:conv.parameters[KEY]conv.intent.parameters[KEY].resolved
    • コンテキスト/シーン遷移:conv.contexts.set(content_name, 5);conv.scene.next.name = 'context_name'
    • 会話を終了:conv.close(response)conv.add.response; conv.scene.next.name = 'actions.page.END_CONVERSATION'
  4. Builderの新しい応答プリミティブを利用するように応答コードを更新します。例:
    conv.ask(new Suggestions (['a', 'b']));

    上記のコードは次のように更新されます。

    for (suggestion of ['a', 'b']) {

      conv.add.(new Suggestion({title: suggestion}))

    }

 

メソッドの完全なリストについては、このページの下にある「フルフィルメントコード変換マップ」を参照してください。

また以下のページを使用して、リクエストとレスポンスのペイロードを比較できます。

注:Actions on Google Node.jsクライアントライブラリを使用している場合は、Actions SDK Node.jsライブラリを使用するようにコードを手動で更新する必要があります。

Webhookをセットアップする

フルフィルメントを更新したら、プロジェクトのシーン全体でWebhook呼び出しを有効にします。移行ツールはDialogflowインテントのWebhook設定を移行しますが、リファクタリングされたフルフィルメントコードとWebhook関数が変更される可能性があるため、これらの設定を確認する必要があります。

Dialogflowでは、インテントでウェブフックが有効になっており、インテントが一致したときに実行するハンドラーと関数がフルフィルメントコードに含まれています。Actions Builderでは、Webhookは呼び出しインテントまたはシーン内でトリガーでき、フルフィルメントエンドポイントにリクエストを送信します。フルフィルメントには、リクエストのJSONペイロードを処理するWebhookハンドラーが含まれています。以下の状況でWebhookをトリガーできます。

  • 呼び出しインテントマッチの後
  • シーンが入力ステージに入ったとき
  • シーンの条件ステージで条件がtrueに評価された後
  • シーンのスロットフィリングステージ中
  • シーンの入力ステージでインテントマッチが発生した後

DialogflowからActions Builderに移行する場合、会話フローへの変更を考慮する必要があります。これは、Webhook呼び出しを行うタイミングと場所が変わる可能性があるためです。

Webhook呼び出しを有効にするには、次の手順に従います。

  1. Webhookを呼び出すシーンを選択します。
  2. Webhookを有効にする状態を選択します。次の1つ以上の状態に対してWebhookを有効にできます。
  3. Call your webhook オプションを選択します。

    https://developers.google.com/assistant/conversational/images/dialogflow-to-builder/enable-webhook.png


  4. フルフィルメントコード内で定義したWebhookハンドラーを入力します。
  5. Saveクリックします。
  6. Test移動し、変更したフルフィルメントに対してWebhookの呼び出しを試してみます。

フルフィルメントコード変換マップ

次の表は、Dialogflowのフルフィルメントコード構文がどのようにActions Builderコードに変換されるかを示しています。メソッドの完全なリストについては、Actions BuilderとSDKのリファレンスドキュメントをご覧ください。

Dialogflow

Actions Builder

conv.data

conv.session.params

conv.ask

conv.add

conv.close

conv.scene.next.name = 'actions.scene.END_CONVERSATION'

conv.user.storage

conv.user.params

conv.input.raw

conv.intent.query

conv.parameters

conv.intent.params[key].resolved

conv.arguments.get('MEDIA_STATUS')

mediaStatus.status==='FINISHED'

conv.intent.params['MEDIA_STATUS']

mediaStatus.resolved==='FINISHED'

Events

システムインテントハンドリング:

MEDIA_STATUS_FINISHED

MEDIA_STATUS_FAILED

conv.device.capabilities.has("actions.capability.SCREEN_OUTPUT")

conv.device.capabilities.includes("RICH_RESPONSE")

app.intent

app.handler

app.middleware

app.middleware

シンプルレスポンス

prompt -firstSimple

リッチレスポンス

prompt -content -card: object -image: object -table: object -media: object -suggestions -link

以下から、その他のツールに関する情報を確認できます。

(翻訳) Migrating from Dialogflow to Actions Builder

これは何か?

先日、Actions on GoogleでDialogflowを使用して作成した既存アクションを、Actions Builderに移行する方法と移行ツールが公開されました。

Dialogflow to Actions Builder migration tool  |  Conversational Actions

(追記:こちらのドキュメントは (翻訳とサマリ) Dialogflow to Actions Builder migration tool - omohayui blog で、翻訳しました。)

ただ、こちらに書かれているように、Actions Builderへの移行は必須ではなく任意です。
Dialogflow自体は今後も使えますし、既存のアクションは引き続きGoogleアシスタントバイスで機能します。

また、DialogflowとActions Builderとの機能差分は大きく、そのまま同一プロジェクトで移行してしまうと既存のアクションを破壊してしまう可能性もあるので、かなりリスクがあると思います。
まずツールを使う前に、何が移行されるのか、移行のメリットは何かといったところを確認しようと思い、まずは下記の導入動画を観て翻訳してみました。
移行ツールのドキュメントの翻訳やツールを使ってみた感想も別のブログ記事に載せようと思ってます。

DialogflowからActions Builderへの移行 (Ja)

www.youtube.com

Dialogflowを使用して作成したアクションを、Actions Builderに移行して、利用可能な新機能を利用したいと考えている人もいるでしょう。

まず詳細に入る前に、2つのワークフロー間で共有されるいくつかの概念について説明します。
タイプ、プロンプト、インテント、シーンを含む会話モデルから始めます。

Dialogflowエンティティは、Actions Builderではタイプと呼ばれ、応答はプロンプトと呼ばれます。

インテントは引き続きトレーニングフレーズとパラメータアノテーションで構成されています。

ただし、Actions Builderのコンテキスト管理、Webhook、応答はシーンで管理されるようになりました。

シーンは、会話の個々の状態を表します。

シーンの主な目的は、会話を論理コンポーネントに編成し、タスクを実行し、プロンプトをユーザーに返すことです。

DialogflowとActions Builderのもう1つの明確な違いは、
Actions Builderは、Webhookがインテントから独立しているということです。

つまり、複数のインテントで1つのハンドルまたはロジックを再利用できます。

インテントは、処理に使用するコードではなく、ユーザーの話すことを表す必要があります。

これにより、さまざまなインテントでワークフローを再利用するという点で、柔軟性が大幅に向上します。

次に、Actions Builderが予期しないユーザー入力を処理する方法について説明します。

Dialogflowとは異なり、Actions Builderにはフォールバックインテントはありません。

フォールバックインテントは、2つの異なるシステムインテントに置き換えられます。NO_INPUTインテントは、ユーザーが応答しない場合にトリガーされ、NO_MATCHインテントがトリガーされるのは、アクションがユーザーの入力をインテントに一致させることができない場合です。

これらのシステムインテントには、カウンターが組み込まれているため、失敗した各試行に対してアクションの応答が異なり、会話の流れがより自然になります。

そして、アクションをActions Builderに移行するのに役立つように、コンソールの移行ツールを使用できます。

このツールは、Actions Builderに使用可能な各言語のインテントとタイプを自動的にインポートすることで、移行プロセスをスピードアップするのに役立ちます。

アクションをActions Builderに移行する方法の詳細については、以下の説明にあるドキュメントをご覧ください。

(記事の先頭に貼ったドキュメントです。)

Acronyms I see at work

これは何か?

去年の暮れに転職し、グローバルメンバーと働くようになってから、職場の Slack や GItHub でよく見かけるようになった略語たち。
手元でメモしてのが溜まってたので、とりあえず晒してみようと思います。

ちなみに入社初日で「???」ってなったのは、何人かの Slack のステータスの "OOO" でした。

仕事で見かける略語たち

よく見かける順に並べてみた。

  • WFH = work from home
  • OOO = out of office
  • BTW = by the way
  • IMO = In my opinion
  • AFAIK = as far as I know
  • NVM = never mind
  • TBH = to be honest
  • TDB = to be determined
  • PTAL = please take another look
  • TIL = today I learned
  • BRB = be right back
  • DFT = done for today
  • NIT = nit-pick
  • IDK = I don't know
  • OMW = on my way
  • MOM = minutes of meeting
  • AFAIUI = as far as I understand it
  • AFK = away from keyboard
  • ETA = estimated time of arrival
  • SSIA = subject says it all

※ 詳しい方々のご指摘お待ちしてます。