(Azure Pipelines) 複数リポジトリのチェックアウトステップを試してみた

Azure Pipelines では、yamlファイルが含まれているリポジトリとは異なるリポジトリをチェックアウトすることができます。 あるリポジトリが別のリポジトリに依存するような仕組みの場合、この機能を使う必要性があります。 私自身、この機能を使ったことがなかったので使い方をまとめます。

使い方

docs.microsoft.com

基本的には上記リンクを参照するのが良いです。 これを書いている時点では以下の Git ホスティングサービスに対応しているようです。（ただし、Azure DevOps Server の場合は Azure Repos のみ対応） Azure Repos の場合、別 Project や別 Organization のリポジトリについても認証さえできればチェックアウトすることができるようです。

• Azure Repos
• GitHub
• GitHubEnterprise
• Bitbucket Cloud

基本的な構文

複数リポジトリを利用する上で必要な定義がいくつかあります。 ひとつはresources、もうひとつはcheckoutです。 複数リポジトリをチェックアウトする上で必須なのがcheckoutで、それを利用するためにresourcesのリポジトリ定義が必要になるイメージです。 スキーマはそれぞれこちらを読めばわかります。

docs.microsoft.com

docs.microsoft.com

resourcesは、複数定義することもできてそれぞれ別サービスからリポジトリをチェックアウトすることもできるようです。

resources:
  repositories:
  - repository: <yaml で参照するための名称>
    type: <Azure Repos の場合は`git`。他にも`github`も指定することができる>
    name: <リポジトリの名称。`プロジェクト名/リポジトリ名`で指定する>
    ref: <ブランチ名。`refs/heads/main`のように指定する>
    endpoint: <異なる Organization の場合はここに接続サービスの名称を記載する>
    trigger: <CI トリガーが必要な場合はここに定義する>

基本的なresourcesの構文としては、これで事足りそうです。 repositoryに指定する名称にはアルファベット大文字・小文字、数字とアンダースコア_のみ使用できます。 nameに指定するリポジトリ名は空白スペースが含まれていても問題ありません。プロジェクト名も同様です。

次にcheckoutです。 checkoutはstepsごとに指定することができます。 -checkout: selfの場合は、自分自身、つまりyamlファイルのあるリポジトリを指定することになります。 別リポジトリを指定する場合は、resourcesの- repository:で指定した名称を設定します。

チェックアウトパス

チェックアウト後にリポジトリがどこにクローンされるかについては以下のページに記載されています。

docs.microsoft.com

挙動としては、リポジトリが単体か複数かによって異なります。 単体か複数かの判断基準はyamlに定義されたcheckoutに定義したリポジトリの数に依存するようです。

単体リポジトリ構成では変数の$(Agent.BuildDirectory)のサブフォルダであるC:\agent\_work\1\sにチェックアウトされます。 複数リポジトリ構成の場合は、$(Agent.BuildDirectory)のサブフォルダにC:\agent\_work\1\<リポジトリ名>というフォルダが作られ、その配下にチェックアウトされます。 ここの<リポジトリ名>はresourcesの- repository:で指定した名称が使われます。

複数リポジトリ構成でチェックアウトパスがデフォルトのままでは都合が悪い場合、pathを指定することで別フォルダへチェックアウトすることができます。

初回のリポジトリチェックアウトの認証

別リポジトリをチェックアウトする際に CI を初めて実行すると、チェックアウトするための承認が必要になります。 詳細は以下のリンクを参照してください。

docs.microsoft.com

初回だけの操作にはなりますが、手動で実施しなければならないため注意してください。

PR トリガーの挙動

PR(Pull Request) トリガーをブランチに指定していた場合、PR が作成されるとブランチの source と target を merge した結果が使用されます。

チェックアウトステップを使用した場合でも、PR トリガーを指定したリポジトリが merge した結果を使用するかどうか確認してみました。 イメージとしては以下のような構成です。

PR トリガーを指定するのが Repos1 リポジトリで、yamlファイルは Repos2 で管理しているような構成です。 master ブランチに対して feature/xxx のようなブランチを作り、Pull Request を作成するようにしています。

この場合でも、Repos1 PR トリガー実行時には feature/xxx と master を merge していました。

---

試してみた結果、システム全体で複数のリポジトリを使用する場合に想定されそうな運用パターンは結構網羅できていそうです。 具体的な挙動については実際に動かして確認するしかありませんが、すでにあるリポジトリに後から CI を構成するような場合は重宝しそうです。

コンデンサマイクを購入しました

在宅勤務が長引き Web 会議にもなれてきた頃、１日の会議の数が増加してきました。 これまでイヤフォン型のマイクを使ってたのですが会議が長時間に渡ると耳が痛くなるのでコンデンサマイクを購入しました。

購入したもの

購入したのはこちら↓↓↓

【Amazon限定ブランド】888M マランツプロ USBコンデンサーマイク 在宅勤務 生放送・録音・ポッドキャスト MPM1000U

これを選択した理由としてはこちら。

• レビュー数が多く、Amazon 以外のレビューがそれなりにある
• デバイスの相性不一致で失敗してもギリ妥協できる金額

開封の儀

また、合わせてポップガードとマイクスタンドを購入しました。

KC グースネック 卓上マイクスタンド 固定型 ブラック MDS-4/BK

GRANPRO ポップガード ポップブロッカー マイクフィルタ ノイズ防止

設置してみた

設置するとこのように。

今回購入したマイクスタンドは MDS-4/BK という蛇腹型のものになっており、折りたたみ式と比較して短い反面、かなり自由に曲げることが可能です。 私のデスクでは大型モニタを使っているため、折りたたみ式スタンドではちょっと邪魔になるかも？と思い、このスタンドにしたのです。

おかげでこのようにモニタの下部からマイクを通すことができました。

使用感

よく使用するコミュニケーションツールは Microsoft Teams と Zoom ですが、どちらも使う分には全く問題ありません。 相手にどのように聞こえているかまではわからないですが、声が小さく聞こえたりこもったりということはないようです。 また、毎日 USB を抜き差ししていますが特に接触不良なども起きてません。

全体的にとても満足な結果となっています。

管理

コンデンサマイクは精密機械なので管理方法どうしたら良いのかな～、とググってたら本来はデジケーターを使うようです。 が、流石にそこまでお金は掛けられないのでもうちょっと簡易な方法を取りました。

CanDo で見つけたポーチにマイクを入れて、ダイソーで見つけたパスタケースにポーチごと入れてます。 また、湿気対策としてシリカゲルも一緒に入れてます。

乾燥剤 シリカゲル 日常に使える便利な除湿剤（シリカゲル5g×30個）チャック■SA5g 30個チ■

唯一面倒なのは業務開始前にマイクを接続して、業務終了後に切断・ケースに戻す作業でしょうか。まぁ、仕方ないと割り切っています。

---

在宅勤務用にコンデンサマイクをお探しの方はご参考にしてみてください。

Azure DevOps拡張機能で自作アプリを呼び出せるかどうか試してみた

Azure DevOps 拡張機能は PowerShell を使用して開発することができますが、ちょっと PowerShell 力が足りないときに .NET 使いたいなーと思うことがありました。 しかし、リファレンス上では .NET アプリを使う方法については記載されていません。なので、未対応なのかと思いましたが「ひょっとして、PowerShell から自作した .NET アプリを呼び出すことができるのではないか？」と思い、少し試すことにしました。

結論

結論から言うと「制限はあるものの Azure DevOps の拡張機能で自作アプリ（アセンブリ）を呼び出すことは可能」でした。 制限については後ほど説明します。 また、今回は Azure Pipelines タスクの拡張機能として作成しています。 もしかすると Web ページを表示するようなタイプの拡張機能だと、この方法では実現できない可能性はあります（未検証）。

開発環境

• Visual Studio Code
• C# / .NET Core 3.1
• PowerShell

自作アプリは .NET Core 3.1 で作成したコンソールアプリです。 このコンソールアプリを PowerShell で呼び出すような想定で作りました。

フォルダ構成

今回のフォルダ構成は細かいファイル配置は省いて次のようになっています。

/CallDotNetExample
│  .gitignore
│  package-lock.json
│  package.json
│  vss-extension.json
│  
├─console
│  │  console.csproj
│  └  Program.cs
│                      
└─src
    │  Startup.ps1
    │  task.json
    │  
    ├─dotnet
    │      console.exe
    │      console.pdb
    │      
    ├─node_modules
    │      
    │          
    └─ps_modules
        └─VstsTaskSdk

重要なのはconsole/Program.cs, src/Starup.ps1, dotnetフォルダです。

console/Program.csは、自作したコンソールアプリです。src/Startup.ps1から呼び出されることを想定しています。 src/Startup.ps1は、自作したコンソールアプリを呼び出します。この PowerShell は、Azure DevOps 拡張機能が実行された際に最初に呼ばれるエントリポイントです。 dotnetフォルダは、ビルドした自作コンソールアプリの出力先フォルダです。src/Startup.ps1は、このフォルダ配下にあるアセンブリを実行するようにしています。

実装したコード

それぞれのコードは以下のようになっています。

using System;

namespace console
{
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                Console.WriteLine("Hello World from dotnet console app!");
                System.IO.File.WriteAllText(System.IO.Path.Combine(Environment.CurrentDirectory, "example.txt"), "Hello World from dotnet console app!");
            }
            catch (System.Exception e)
            {
                Console.WriteLine(e.Message);
            }
        }
    }
}

[CmdletBinding()]
param()

try {
    $samplestring = Get-VstsInput -Name "samplestring"

    Write-Host "Hello world from Starup.ps1."

    Start-Process -FilePath "${PSScriptRoot}\dotnet\console.exe" -Wait -NoNewWindow
    
} finally {
    Trace-VstsLeavingInvocation $MyInvocation
}

Start-Processで-Waitにしているのは、自作コンソールアプリを呼び出したあとに処理を待つため。 そして、-NoNewWindowにしないとコンソール出力の結果が Azure Pipelines のログに出力されないためです。

実行結果

これを実行すると次のようになりました。 期待したとおり、PowerShell の Hello world と C# の Hello world が出力されています。

制限

今回調査した限りだと次のような制限事項があります。

アップロードサイズ

Azure DevOps 拡張機能ではパッケージしたファイルのサイズに制限があります。 試しに .NET アプリをシングルファイルにしてアップロードしようとしたところ以下のようなメッセージが表示されました。

Upload Error

The extension package size 'XXX bytes' exceeds the maximum package size '26214400 bytes'

なので、アップロード可能なサイズは26.2 MBまで。 Hello world だけのアプリをシングルファイルで生成しても 30 MB 程度はあったので、.NET のシングルファイル生成によるパッケージは不可能です。

また、アップロードファイルのサイズについて、削減する方法をまとめてくれているブログがありました。といってもこっちは正規の方法（Node.js + TypeScript）で作られているようなので、本記事とは関係は薄いです。

levelup.gitconnected.com

環境依存

上記にも関連しますが、シングルファイル生成によるパッケージが不可能ということは、拡張機能で呼び出す .NET アプリが環境に依存してしまうということです。 Azure Pipelines の特性上、Microsoft がホスティングしている環境上で実行される場合は .NET のフレームワークバージョンに制限があります。というより LTS でない古いバージョンは使えません（例えば、現状では .NET Core 3.0 などは Microsoft がホスティングしている環境にはインストールされていない）。 この対策としてシングルファイル生成によるパッケージングができればどの環境でも動作できるのでは？と考えましたが、結果は上記のとおりでした。

他の対策は「常に .NET アプリ側を常に最新バージョンに対応させる」か、「プライベートホストを使って環境を固定する」かでしょうか。 どちらが良いかはプロダクトによるでしょうが、いずれにしろコストは掛かります。 このコストと C# / .NET が使えるメリットは考慮しておく必要があります。

検証していないこと

管理者権限で実行する

多分無理ですが、管理者権限でアプリを実行することは検証していません。 うろ覚えですが、たしか Azure DevOps 拡張機能自体、管理者権限では実行されなかったと記憶しているのでアプリ側も同じく不可能かと。

といっても管理者権限で実行したいようなケースは無いとは思いますが。

どこまでの機能が使えるか

少なくとも拡張機能の実行フォルダにファイルを出力することはできます。 しかし、それ以外の機能、例えば HttpClient で Web API を呼び出すなどのようなことが可能かどうかまでは検証できていません。 OSS ライブラリを使う場合、ものによっては Azure DevOps 側で制限がかけられる機能を使っている可能性もゼロではありません。 アプリによってはここがボトルネックになることが多いでしょうから予め検証は必要です。

まとめ

実現可能とはいえ、普通なら PowerShell でいいじゃんと多くの人が思うでしょうから、あまりにもニッチな需要かもしれません。 制限事項もあるので使い所も難しいケースもあるでしょう。 それでも使い慣れた言語が使えるというのはそれ単体では絶大なメリットだと思うので、どうしても…という場合には選択肢に追加しても良さそうです。

Azure Functionsで自作したカスタムコネクタをPower Automateで使おうとしたらハマった事象と原因と回避策について

随分とタイトルの示す範囲が大きくなりましたが、そういうことです。

やろうとしていたことは「Azure Functionsで作成した関数アプリをPower Automateで使う」という至ってシンプルなものでした。 しかし、いざ実践してみると期待した通りに動作しなかったため、しばらく悩み続けてなんとか解消した話です。

事象

Azure Functionsで作成した関数アプリをカスタムコネクタを使って呼び出すようにしました。 新規にフローを作成してカスタムコネクタのアクションを実行すると失敗し、次のようなメッセージが表示されました。

ResponseSwaggerSchemaValidationFailure. API 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' が、種類 'OpenApiConnection' のワークフロー操作 '<API名>' について無効な応答を返しました。エラーの詳細: 'API 操作 '<API名>' では、プロパティ 'body' の種類を 'Object' にする必要がありますが、種類が 'String' です。'

内容的には json の応答を Object から String にしろと言うことのようです。

---

2020/11/16 追記 （コメント頂きましたので修正）

内容的にはカスタムコネクタでは Object が来る想定だったけど String が来たよ、ということのようです。

---

ちなみにAzure Functionsでは、作成した関数の応答は json で返していました。

ただし、この現象が発生するのは実際のフローのみで、カスタムコネクタの[テスト]タブで実行した場合や、HTTP アクションで同じ URL 呼び出しを行っても同じ現象は発生しませんでした。

似たような事象が発生していないか Power Automate で探したところ、ドンピシャなスレッドがありました。が、質問した方はカスタムコネクタを修正して対応したようです。（良いのかな…）

Error in Power Automate Flow When Using Custom Connector -requires the property 'body' to be of type 'String' but is of type 'Object'

原因

色々試した結果、原因はAzure Functions側にあることがわかりました。 応答する際に json にシリアライズしたのは良いのですが、json 文字列を body に設定してしまっていました。

はい、つまり完全に私のしょーもないミスが原因ですね。

具体的には次のようなコードになっていました。

[FunctionName("function")]
public async Task<IActionResult> Run([HttpTrigger(AuthorizationLevel.Anonymous, "get")] HttpRequest req, ILogger log)
{
    ...省略
    var json = Newtonsoft.Json.JsonConvert.SerializeObject(result, _settings);

    return new OkObjectResult(json);
}

このまま関数を呼び出すと応答結果のContent-Typeは、text/plainになってしまいます。 要はこれをapplication/jsonにすれば良いわけですね。

対策

今回のケースでは応答は json で返し、シリアライズする際の書式設定はNewtonsoft.Json.JsonSerializerSettingsで設定していたため、Microsoft.AspNetCore.Mvc.JsonResultで応答する手法を取りました。 この方法にたどり着くまでに twitter 上でしばてぃさん(@shibatea365)に何度もアドバイスいただきました。感謝の極みです😂

さて、変更後のコードはこのようになります。

[FunctionName("function")]
public async Task<IActionResult> Run([HttpTrigger(AuthorizationLevel.Anonymous, "get")] HttpRequest req, ILogger log)
{
    ...省略
    return new JsonResult(response, _settings);
}

なお、JsonResultを使う場合はMicrosoft.AspNetCore.Mvc.NewtonsoftJsonパッケージを追加する必要があります。 また、csprojファイルに<FrameworkReference Include="Microsoft.AspNetCore.App" />を追加しないと以下のような事象が発生するそうなのでご注意を。

MethodNotFound when trying to call JsonResult ctor with JsonSerializerSettings #1907

これを実行するとContent-Typeはapplication/jsonになり、Power Autoamte のフローも成功します。

最後に

本当にしょうもなことが原因で何日もハマってしまいました… Azure Functionsについてはまだまだ初学者であったとは言え、今回のような事象はユニットテストでレスポンス ヘッダーまでテストして入れば検知できたはずです（やってませんでした！）。 ちょっと手を抜いた結果がこれです。 手を抜くの絶対ダメ！！！

（生活）スマートホーム デバイスで生活が快適になりました

先日の Amazon プライムデーセールで Alexa とスマートホーム デバイスを購入したのですが、あまりに便利だったので紹介します。

購入したもの

【Amazon App-to-App対応 Alexa認定】シンプルスマートリモコン EZCON (日本発ブランド・今ある家電をスマホで操作

【Amazon Alexa認定】ゴウサンド(Gosund) スマートプラグ Wi-Fiスマートコンセント コンセントタイマー 遠隔操作 Alexa/Google Home/Echo 対応 音声コントロール ハブ不要 1個

FREDI スマート電源タップ WIFI接続スマートプラグ 遠隔操作可能 USB電源タップ 雷ガード 省エネ電源プラグ 一括スイッチ付き 4+2(ACコンセント4個口+USBポート2個口) コ一ド長2m 合記1400Wまで 【Echo/Alexa/Google Homeに対応】

EZCON は Amazon Alexa とセットで購入しました。 また、余談ですが FREDI スマート電源タップ は2020年11月1日まで50%OFFクーポンがあります。クーポンコード「DEN102013」（早期終了するかも）。

私の家にはすでに Google Home が２台あったのですが、新たに Alexa が追加されました。

EZCON は Alexa から操作できますが、Google Home には対応していないため操作できません。 Gosund スマートプラグ Wi-Fiスマートコンセント と FREDI スマート電源タップ は Alexa と Google Home どちらでも操作できます（というよりもアプリの Smart Life が対応している）。

EZCONの設定方法

事前に EZCON アプリをインストールしておきましょう。

EZCON

• LinkJapan Inc.
• ライフスタイル
• 無料
• 

apps.apple.com

とても簡単です。が、いちいち文章で説明するよりもこちらの動画を見るほうが良いでしょう。 例えば証明のリモコンを登録するような場合はこの動画のように設定します。

play.google.com

照明の登録方法

一つ注意が必要なのが EZCON が Wi-Fi の 2.4GHz にしか対応していないことです。 5GHz では使えないので事前に確認する必要があります。

スマートプラグ／スマート電源タップの設定方法

こちらは Smart Life アプリから設定します。

Smart Life - Smart Living

• Yu xiang
• ライフスタイル
• 無料
• 

apps.apple.com

play.google.com

接続する機器によって設定方法が若干異なるのですが、付属の取扱説明書を読めばOKです。 また、FREDI スマート電源タップ は１口づつ ON/OFF を切り替えられるため、例えばヒーターやサーキュレータを別々の口に接続しておいて独立して切り替えが可能となっています。 これがめちゃくちゃ便利！

スマートフォンからリモコンとして使う

EZCON

EZCON アプリは設定が完了するとこんな感じになります。 部屋ごとにタブが別れていて登録デバイスを一覧で見ることができます。

スマートタブでは音声認識やタイマーによる自動設定も可能になっています。

Smart Life

Smart Life も EZCON と同じようにデバイスの一覧が表示されます。 EZCON との違いとして"ワンクリック実行"というものがあります。 これは特定のデバイス制御を一括で実行できる機能で、一度設定すればプラグに接続したヒーターを付けたり、すべてのプラグを OFF にしたりといったことが可能です。

こちらはスマート プラグの画面です。シンプルに ON/OFF のみです。

このスマート プラグを使うまで知らなかったのですが、使用電力量を計測してくれる機能もあります。 ↓↓↓こんな感じで現在使用している電力量と合計量を見ることができます。

これを利用したら家中のコンセントにスマートプラグを接続して使用電力量の可視化もできそうですね。

こちらはスマート電源タップの画面です。 電源タップはすべての電源を一括で ON/OFF するボタンとそれぞれの口ごとに ON/OFF 切り替えることができます。 ボタン名はデフォルトでは"スイッチn"ですが、これはタップして別名に変更することができます。 私の場合は下２つをサーキュレーターとヒータに割り当てています。

１点残念部分として電源タップ側には電力使用量を計測する仕組みはありません。 スマートプラグが¥1,600ほど、電源タップが¥4,000ほどと考えるとあってほしい機能ですが…

スマートスピーカーと連携して使う

Google Home と Alexa でそれぞれアプリで連携できるようにしました。

Google Homeアプリ

Google Home アプリはスマートスピーカーや Chrome Cat もまとめて確認できます。 数が多くなってくるとごちゃごちゃしそうなので、アイコンや色を変えたりとかできるといいですがそうはなっていません。

ルーティンで特定のフレーズからデバイスを操作できるようにしておけば、帰宅時や外出時にまとめてデバイスを制御することができます。

Alexa

Alexa は最初に部屋（グループ）を選択するため Google Home と違ってシンプルです。 ただし、１タップ分の操作が増えるのと、この時点では何のデバイスがどこの部屋にあるのかは分かりません。新しくデバイスを追加したときとか、家族で共有するときとかは戸惑うかも？

Alexa も Google Home と同じく、特定フレーズからデバイス制御が可能です。 Google Home との違いは Alexa だと EZCON も操作できる、というところです。

スマートスピーカーが２種類あるので、両方に同じフレーズで同じデバイスを操作できるようにしました。 個人的には Google Home の方が好きなのですが、ここは妥協しています…。

生活シーンで使う

我が家では今年娘が誕生して毎日育児に追われているのですが、このスマートホーム デバイスが大変役に立ちます。

例えば外出するときはどうしてもやることが多くてバタバタしますが、「Alexa、いってきます」というだけで家中の各種家電が一斉に OFF になります。 エアコンや照明など、リモコンが複数あるとどうしても置き場所を探しますが、音声による操作なら抱っこひもを使った場合でもベビーカーの場合でも大変楽です。 他にも、これからの季節はヒーターやホットカーペットを使う家庭もあるでしょうし、そういったところにスマートホーム デバイスがあれば、まとめて切り替えができるので使い勝手が良さそうですね。

あとは帰宅時に前もって電源を ON にすることで、寒い日でも帰宅直後からエアコンで十分に温まった部屋で過ごすことなどもできます。

そして、個人的に最も使ってよかったところが-子供をあやして寝かしつけたあと、照明を OFF にするのですが、アプリから操作することによってリモコンを探す手間などが省けます。 また、スマホが手元になかったり抱っこしているときなどはスマートスピーカーから操作することもできます。 フレーズを登録しておいて、照明の OFF と同時に安眠できるような音楽を再生するのもいいでしょう。 リビングでくつろいでいるときに子供が起きたりしたらすぐさま駆けつけることになりますが、別の部屋にいてもつけっぱなしにしていたヒーターを OFF にしたりすることもできます。

まだ使ったことは無いのですが、Smart Life だと気温の変化や GPS で特定の場所に移動したことをトリガーとしてデバイスの制御が可能になっていたりもします。 寒くなってきたら暖房、熱くなってきたら冷房を着けるといった具合です。

こういった機能をうまく使えば今以上に生活が楽になりそうですね。

他のスマートホームデバイスの選択肢

スマートホーム デバイスと言ってもその種類はそこそこあります。 パッと見はそれぞれの差異が分かりづらいのですが、特に注意したいのが「デバイスの制御に使用するアプリ」と「連動可能なスマートスピーカー」です。

上記でもすでに紹介していますが、リモコンとプラグで操作するためのアプリは異なります。 私が調べた限りですが、プラグもメーカーによって使えるアプリが異なる場合があります。 例えば Meross というメーカーでは同じく Meross というアプリでしか操作できません。

せっかく家電をまとめて操作できるようになったのにアプリを複数使用するのでは本末転倒になってしまいます。 使うアプリの種類はせいぜい２種類が限度でしょう。 デバイス購入の前に口コミなどから利用可能なアプリを調べておくのが良いでしょう。

次に連動可能なスマートスピーカーですが、上記の EZCON なんかがそうです。 こちらのリモコンは Alexa とのセット販売＆タイムセールによる大幅割引だったので、Google Home と連携できなくても妥協できますが、リモコンも決して安くはないです（定価 ¥3,980 くらい）。 EZCON はまだ Nature なんかの高性能リモコンよりも安価ですが、それでも手持ちのスマートスピーカーと連携できなくて困る可能性もあります。

スマートスピーカーとの連携は必要だ！という方はこのあたりも注意しないといけません。

---

使ってみると想像以上にできることが多くて最初は戸惑いますが、これは一度経験したら手放せなくなるタイプの UX です。 スマートホーム デバイスは他にも多種多様なものがあるので、自宅に適したものを探してみてください。 （個人的には LED 電球とか気になりますね…これ使って子供と遊べそうですし、ナイトライト代わりにもなりそう。）