カテゴリー: 未分類

久々のイベント物理参加。冒頭から高密度なAI活用に関する発表が続いて、AIの勉強会かと錯覚した。が、それほどにAI活用が「AIすごい！」を超え、エンジニアのコーディングにとどまらずQAや顧客対応にも浸透していると感じた時間だった。発表の中で、Claude Code/Copilot/Devinの使い分けの勘所に言及されていて参考になった。仕様駆動が当たり前の様に語られていて、弊社でも実践している。ただ「仕様駆動」で満足するだけでなく、いかに効率性や確実性を高められるかに、世の中の関心ごとが移っていることは明らか。こうした会を通じて各社のナレッジに触れられるのは大変ありがたい。

イベントページ：https://mobiletechflex.connpass.com/event/381976/

---

AIとなら実現できる事業と品質のシン化の両立

@a_key_bako さん

• シン化とは？
• AIによる外部環境の変化（CodexでSoraが28日で）
  • 専門のAndroidチームがいたわけではなかった
  • 爆速で使えるが、品質要求は自ずと高いものが要求される
  • 各社のAI活用法や課題共有に価値がある
• 現状
  • Deploys/Developer/Day 指標の変化推移
  • デプロイされた数を、開発者x営業日で割る
  • 1を超えた：かなり高い
    • Mobileはデプロイを意識しない：masterブランチへのマージ数をdeployとカウント
  • 変わったこと
    • ジュニア：アウトプット出しながら学習（先輩への質問以外という選択肢）
    • シニア：自身の知識が生産性に直結（ボイラープレートをAIに任せる）
  • 役割での使い分け
    • コーディングはCC、レビューはCopilot、越境はDevin（テストケースを尋ねたり、いろんな職能が使う）
    • CC：低コストでペア作業
      • CLAUDE.md、git worktree、ghコマンド（巨大PRの分割もスムーズ）
    • Devin：
      • 専門街プラットフォーム越境に便利（mobile→BE）
      • 作業プロセスがチームに見える
• これからの課題
  • 課題1：技術的夫妻
    • 返済はできない
  • 課題2：AI活用の限界
    • 今のプロセスだとせいぜい一人ができることの効率化で限界がある（2倍にはなってもそれ以上には）
  • 納期ベース下での事業と品質のトレードオフ
    • リソースが潤沢でないと大規模リファクタリングができない
    • 課題をブレストすると、課題の洗い出しと優先度づけをした（重要度、漸進可能性、楽しさ）
      • 重要度：プロダクトへの影響度→やらざるを得ない
      • 漸進可能性：少しずつ進められるか（Viewごとに進められる？画面ごと？or一気に置き換え必要？）
        • 高いものはAIによる自律的置き換えに向いている
      • 楽しさ：学びの多さ、賞味期限→投資効果が高い
• AI支援によって、専門外でも一定品質でコード生成可能に
  • ガードレイルの重要性が増す
  • 原理原則をガードレイルにする

OSアップデート：年に一度の「大仕事」を乗り切るQA戦略

@Myamaguchi75201 さん

---

• OSアップデートはなぜ大仕事なのか
  • リリースが多く、クライアントによって機能の紐付け設定が多様
  • OSアップデートによる調査工数が増大
  • リグレッションテストケースが肥大化
• 現状のテスト戦略の課題
  • テストケースが肥大化しQAリソースが不足
  • 機能仕様の理解の属人化（QA担当者が一番詳しい）
  • 担当者による観点粒度に差分
• 対策
  • 観点粒度を汎用的にし、テストケースを見直し
  • テスト自動化（勉強会を開催し共有）
  • ↑アウトプットのテストコードをGitHubで一元管理
  • 相互機能影響をAIで抽出（過去実施のテスト観点や実装PRを用いて）

“レビュー”だけだったAI活用から半年。ヤプリのiOS開発・運用はどう変化したか？

@ko_yack さん

• 活用深化と活用領域のマッピング
  • チームでの半年前はコーディングとレビュー
  • CCに設計テストレビューするまで全て行っている
  • アプリビルドはDevin経由
  • 問い合わせ調査はAtlassian Rovoでエンジニアが一時解凍できる様に
• CCの活用における課題
  • コンテクストの枯渇：AIが参照不要な情報を読み取ろうとし、コンテクスト枯渇し忘却する
  • AI用ドキュメントをどこに置くか：CLAUDE,mdだとツール入れ替えた時にスイッチできない
  • 広い範囲の修正をしたい
  • メンバー習熟度の違い
• 課題の解決
  • ドキュメントの構造化：root.instructions.mdを起点として、アーキやコーディングプラクティスを記載する
  • ドキュメントは読むべきタイミングと参照先をセットで管理し、無駄な参照を防ぐ
• Spec-Driven Development (SDD) の導入
  • Proposal phase, Research & Planning phase, Implementation phase, Retrospective phase
  • フェーズごとにsubagentで分ける
  • 例: Swift移行のために、設計やマイグレーションのナレッジを構造化
  • 例: iOSで作った設計ドキュメントをもとにAndroidでもなぞらせた
• Snapshotテストを導入
  • UIテストもAIに自律的に修正させる
• Skills の活用
• 問い合わせチケット切られたらRovo AgentにJiraなどの情報をRAG経由で参照させ、回答させる

謎現象の解決手段を発見して プチ英雄になりました

@shiosioco40 さん

• Androidだと、React移行後JSInterface経由のインタラクションができなくなった
• zod: プロパティアクセスと呼び出しの分離が原因
  • 参照と実行顔同時でないとJSInterfaceのメソッドをWeb側が実行できない
• 回避策：JSInterfaceの参照を無名関数でラップする（アクセス実行の寸前まで触れない）

Claude × Markdown で仕様書をいい感じに管理したい

@AtriaSoft さん

• Claude Code を使った仕様書作成管理の便利さと課題
• 仕様書の老朽化問題（Confluenceの最終更新が2年前、、）
  • メンバー入れ替わりでメンテナンスが宙ぶらり
  • エンジニアに書くモチベーションがない、余裕がない
• サブエージェント4体
  • reader, writer, reviewe, simpler(簡潔に書き換える)
  • 自然言語で指示したら、readerが既存仕様書やコードベースを読み解いて、writerに渡して仕様書を作成、更新。reviewrがその仕様書の生合成をチェックし、simplerが仕様書を簡潔に書き換える
  • エンジニアがレビューしてPR、レビュー、マージ
  • honkitを利用して、mdファイルは見やすい形にエクスポート
• 良かったこと
  • 「書く」でなく「レビューする」で知り的ハードルが激減
• 課題
  • 出力が冗長になりがち、コンテクスト共有に最適化されていない、図表表現に限界（Mermain導入したい）

Kotlin Multiplatform + iOS アーキテクチャの実践

株式会社ディップ 権 さん

• KMPの実運用での使い分け
• ビジネスロジックをKMP共有、UIは各OSネイティブ
  • Presentationは書くOS
  • sharedで、Domain/DataをKMP共有
  • modelはPure domain model
  • データ変換フローは、
    • Entity
    • DTO
    • Model
• iOS側のUIアーキテクチャ
  • 画面ごとの状態管理がバラバラだと、状態遷移の追跡とKMP連携の責務分離が難しくなる、自作アーキテクチャ(Store Pattern)を採用（Intent(ユーザー操作)/Store/State/View）
  • iOS側はMVIをStore Patternで実装し、Android MVIと読み方揃t、チーム認知を統一
  • ObservableでState変更を購読
• Store Patternのメリット
  • 複雑な機能にスケールしやすい：小規模から大規模まで設計を継続可能
  • チーム運用しやすい：Androidと似た設計で読み方統一、UIイベントの扱い方を共有化でき、レビュー観点揃えられる
• KMPのSwift側の呼び出し体験をSKIEで改善
  • 今後、Swift Exportで、Obj-Cヘッダ経由の負荷を減らせる可能性があり、experimentalだが、よりSwiftらしいAPI公開に期待

バイトルiOSアプリのリアーキテクト / SwiftPMとAIルールで実現するモジュール設計

株式会社ディップ 宮川さん

• 20年以上続くシステム課題の解消
  • ドメイン駆動設計、AI前提の開発プロセス、AIネイティブな体制
• SwiftUI、デザインシステム、KMP、Strinct Concurrency Checking…
• Swift Package Managerによるパッケージ管理
  • 分割の基準、機能画面ごと、外部依存の隔離(Firebase, KMPなど)、再利用性の担保(UI components, design system)
  • 全体構成が把握しやすくなり、循環参照を抑止できた
• SwiftPMにおける課題
  • KMPなど外部に依存している状態で、SwiftUI Previewが不安定（タイムアウト）
  • 外部サービス依存のモジュールを限定的にし、protocolやmockのみを定義したInterfaceモジュールを定義し、中間に挟む様にし、KMPなどへの直接依存を回避した
    • poinfree / swift-dependencies により実現
• AIコーディングによる課題（CC）
  • 意図しないモジュールにコードが生成される
  • モジュールごとに定めた依存関係のルールを守らない
  • CLAUDE.mdに全ルールを記述していたが、コンテクスト肥大化するため、.claude/rules/を活用して最適化した
  • レイヤー概念を導入してルールをシンプル化：モジュール数の増大で依存関係が複雑化する、AIにとっての認知負荷も増大するため、モジュールの責務ごとにグルーピングしたレイヤーを導入した（同じレイヤーは、同じ依存ルールに則る）
  • ruleファイル自体が設計ドキュメントとして機能

10年くらい前から、ONKYOのCR-N755というオーディオレシーバーを使っているのだが、数年前からCDプレイヤーが壊れて聴けない状態が続いていた。

とはいえCDはまだ手元にあるし、Apple Music や Spotify にない音源は買うしかない。さらにコンサートに行けばサイン目当てにCDを買ったりもする。なので聴く手段はないがCDの数は増えていくという不思議な状態に陥っていた。

そんな中この記事で Relax というメーカーのCDプレイヤーを知り、先日とうとう購入した。

初代iMacから着想を得たCDプレーヤー「RELAX PIXEL TUNES」新色「Ray of Light」 – AV Watch

話題の？CDプレイヤー買った、メモリに音源データ読み込むので、再生中に回転が停止再開繰り返すのがなんとも不思議。音質はちょうど良くローファイ。https://t.co/jcIV5XVQQO pic.twitter.com/JR6Yl0QmWA

— Takeshi Tanaka (@p0dee) February 8, 2026

かつてはこうしたCDプレイヤーは珍しくなかったはずだが、時代はMD、iPodと移り、いまやストリーミング意外の手段で聴くのはオーディオマニアくらいに限られた今、逆にポータブルにCDを聴けるという体験が新しい。

さらに、CD主流の当時であってもこうして本体独立で音源再生できるのは決して多くはなかったのではないだろうか？ ラジカセ感あるローファイな音質で、ながら聴きだとかえって疲れしなくて良い。きちんと聴きたければヘッドフォン端子に有線イヤホンや外付けスピーカーを刺すか、Bluetoothイヤホンとペアリングすればよい。

なにより、CDが回転する様子を眺めているのが楽しい。音飛び防止としてオンメモリに音源を読み込む機能が搭載されていて、その都合でCDの回転が途中で止まったり、再開したりする挙動は、何度見ても不思議。この機能はON/OFF可能なので、ずっとCDを回転させ続けることも可能。

こうした機能性抜きにしても、初代iMacを想起させるボンダイブルーの筐体は可愛らしくて眺めてても楽しい。個人的には良い買い物だった。

最近開発するときは、仕事・個人共に Claude Code 全振りなのだが、Claude の開発者 Boris Cherny 氏が、Claude Code を使う際の10のチップスを共有していたので、勉強がてら読んでみた。

Claude は雰囲気だけで十二分に使えてしまうので、意識的にこうした手法を取り入れてトライ&エラーしないと、我流のまま世の中の進歩から取り残されてしまう実感がある。

I'm Boris and I created Claude Code. I wanted to quickly share a few tips for using Claude Code, sourced directly from the Claude Code team. The way the team uses Claude is different than how I use it. Remember: there is no one right way to use Claude Code — everyones' setup is…

— Boris Cherny (@bcherny) January 31, 2026

1. 並行でより多くを行う
   • 複数セッション起動し、それぞれに git worktree (大半の Claude Code チームが好んでいる) を走らせる
2. 複雑なタスクは必ずプランモードから始める
   • ある Claude にプランを書かせ、別の Claude にそれをレビューさせる
   • 問題があればプランモードに戻し、プランし直す
   • 実装だけでなく、検証時もプランモードを活用する
3. CLAUDE.md に投資する
   • 修正のたびに、同じ間違いをしないようCLAUDE.md を修正することを、Claude に指示をする
   • CLAUDE.md に惜しみなく修正を加え、目に見えて間違いが減るまで繰り返すこと
4. スキルを作成し、Git にコミットし、すべてのプロジェクトに流用する
   • 1日のうちに複数行うことは、スキルかコマンドにすること
     • すべてのセッションの終わりで実行し、重複したコードを削除するコマンドを作る
     • 1週間分の Slack、ドライブ、GitHub などの情報をコンテクストダンプに同期するコマンドを作る
5. Claude はたいていのバグを自身で修正できる
   • Slack MCP を有効にし、Slack URL を Claude Code に与えて修正を依頼する
6. プロンプトをレベルアップする
   • 自己レビューしてテスト通るまでPR出すな
   • ここまでの知見を活かして、現状を破棄しより良い方法で実装しなおせ
   • 仕様を詳細に書き実装前にあいまいさを減らせ
7. ターミナルや環境のセットアップ
   • Claude Team 推奨の Ghostty
   • /statusline コマンドでステータスバーをカスタマイズする
   • 音声認識を使う：タイピングよりも3倍早く指示できる
8. Subagent を利用する
   • “subagents を使うこと” を、より複雑な課題解決を依頼する際に加える
   • 個別タスクを subagent にオフロードすることで、メインのコンテクストをクリーンに保てる
   • 承認リクエストをフック経由で Opus 4.5 にルートして、攻撃をスキャンし安全なリクエストを自動で承認させる
9. Claude をデータ分析に用いる
   • bq CLI を用いて Claude にデータ取得と分析をさせる
   • BigQuery スキルがコードベースに組み込まれていて、Claude チームの誰もが Claude Code でクエリを書いている
10. Claude で学ぶ
    • Explanatory または Learning アウトプットスタイルを有効とし（/config で）、Claude が変更の「なぜ」を説明できるようにする
    • HTML 表現による説明、ASCII 図による説明の生成
    • 自分自身の理解を Claude に述べ、Claude がフォローアップをすることで不足を補う（spaced-repetition learning）

昨年から仲良くしていただいているショウヘイさんが主催されるもくもく会に行ってきた。中野駅近くのコワーキングスペースNAKANO HAKO、参加費は個々の利用料2,500円。

イベントページ：https://mokumokuios.connpass.com/event/381241/

こんな感じで、Vision Pro でミラーリングしながら週末プログラミングの延長線的な作業をしていた。

飲み物、お菓子食べ放題なのは嬉しい。お菓子のセレクションが素晴らしかった。

参加者はiOSエンジニア、Webエンジニア、個人開発者、デザイナー（プロダクトデザイナーの方も）とさまざま。

各々で作業しているときは、文字通り黙々と手を動かしているのだが、こんな感じで作品見せあったり談笑したり、情報交換できて楽しい時間だった。

---

おまけ：お昼に食べた、会場下のCoCo壱カレー。

週末ふと思いついたアイデアを、Claude Code を使ってかたちにしてみようと思った。

仕事でも Claude Code を使っていて、実装は99%手で書くことがなくなったのだが、どのように指示しているかというと、まず要件レベルのドキュメントを Claude に与え、詳細設計レベルの仕様書に落とし込んでもらい、それをもとに質疑を交わしたり認識合わせを経てから、コーディングに落とし込んでもらっている。

いっぽう個人開発は、よりふわっとしたアイデアからスタートするので、数行のアイデアメモから始まる。これを実現するために、AIにとっての不足情報を質問形式で引き出し、それに答えながら構想を詳細化していく。

ちなみに筆者の場合、この質疑応答はチャット上ではなくテキストファイル上で行っている。質問が書き出された .md ファイルに筆者が回答を記載し、追加で質問があればさらに書き込んでもらい、、というラリーをひたすら繰り返す。質疑以外のコミュニケーションもコンテクストに溶けないよう、かたちに残るファイル上で行っている（特別な方法ではないはずだ）。

ドキュメントベースでレビューできる内部ロジックに限らず、外見の画面イメージがAIと認識が揃っているかも、本実装の前にきちんと把握しておきたい。そこでAIに図示を依頼すると、大抵ASCIIアートで描いてくるきらいがある。しかし文字列で表現できるレベルなんてたかが知れているし、そもそも表示が崩れまくるので使い物にならない。

そこで Swift Playground でモック実装させてみたら、これがうまくいった。例えばオーディオデータを扱う筆者のアイデアは、波形を描画して、範囲選択をし、編集操作を行う要件がある。これを人間の手でサクッと作るのはガワだけでも結構大変だ。だがAIなら、アイデアの壁打ちを始めてからたった10分足らずで次のような絵に仕上がった。ほぼ一発で、バシッと筆者のイメージを具現化してくれた。

あとはボタンの配置がどうの、配色がどうのと細かい部分を指示し、随時 Preview 上で反映を確認しながら、ワイヤーレベルのデザインを固めていった。

---

ちなみにこのアイデアだが、アプリとしてきちんと形にしようと思うと、音声処理に関する実装知識が必要だし、インタラクションや機能の複雑さもあるため、日曜大工感覚で1ヶ月くらいは掛かるだろうと見込んでいた。が、Claude Code を使えば日曜の夕方2時間程度でほぼほぼ完成形までこぎつけられた。（といっても、今更このスピード感に驚くこともないのだが、、）

この時点でバグは多いものの、実際に手に取って動かせることで、UIやインタラクションの課題が浮き彫りになり、アイデアのブラッシュアップに繋げられた。まさに Vibe Coding 的な体験だった。

これまで Cursor を使っていたが、仕事が Claude Code 1本なので、個人開発でも使おうと Claude をインストールしたが、claude コマンドの実行時で失敗してしまった。

$curl claude
warn: CPU lacks AVX support, strange crashes may occur. Reinstall Bun or use *-baseline build:
  https://github.com/oven-sh/bun/releases/download/bun-v1.3.6/bun-darwin-x64-baseline.zip
error: Invalid DNS result order.

Terminal.app が Rosetta で起動する設定になっていたのが原因だった。チェックボックスを外して再度実行したら成功した。

昨夜はじめてブルーノート東京の臨時席を体験してきた。事前にネット検索してどんなものか調べてみたが、あまり情報が出てこなかったので、これを機に記しておく。結論としては、普通にオススメできる。

---

先日ロン・カーターの公演を観にブルーノート東京へ行った際、クラブ会員特典で来場ポイントが7貯まるごとにもらえる招待状（インビテーション）をいただいた。この招待状で（条件付きだが）１公演のミュージックチャージが無料になる。

いちいち、あと何公演で招待状もらえるかなんて数えていないので、いつも不意打ちで受け取ることになる。また招待状の期限はその日から２ヶ月間なので、その限られた期間の中で行きたい（し行ける）公演を探すことになる。今回は翌週にケニー・ギャレットのステージがあったので幸運だった。

基本的にいつもはステージに近いアリーナを選ぶし、加えて会員特典で先行予約するためたいてい最前テーブルを割り当てられることが多い。しかし今回は公演直前で、さらにケニー・ギャレットともなると当然空席はない。というわけで、唯一の空席であった（電話では最後の１席と告げられた）臨時席を、50回近いブルーノート歴で初めて選ぶことになった。

招待状の予約は電話で行う必要がある。電話口の予約ではウェブにはない「２階席」を予約することも可能で、今まで２階で観る機会もなかったし、どちらにしようか迷ったのだが、電話口のオペレータは暗に臨時席の方を勧めてきた。話によると「臨時席を好んで選ばれる方もいる」と言うが、会場最奥で椅子しかない席だ、本当だろうか、、？

と半信半疑で当日迎えたが、結果としてオペレータの助言は確かだった。

臨時席は、入り口側のレジ脇に６つほどスツールが並べられているエリア。実はここはカウンターを背にしているので（カウンターがあることを知らなかった）、ドリンク・フード置き場は必然的にステージ向かって真後ろ側になる。つまり、飲食を置いたり取ったりするには、都度背を捻る必要がある。そこは難点。とはいえスツールの座り心地は申し分なく、１時間半の公演で座り疲れることもなかった（30代後半男性の感想）。ちなみに、老若男女、カップル客もいたので、誰でも馴染めそう。

席からの光景。通路の突き当たりで、これは運が良かった。なぜならアーティストの通り道で、入退場時に間近で見ることができたからだ（握手は叶わず）。

この席位置で特に恩恵を得られるのは、遮るものなくステージを一望できることだろう。これまでアリーナを積極的に選んできた筆者だが、今回改めてその欠点に気がつくことができた。アリーナは、席によっては前の客に遮られてまともに演者が見られなかったり（ハズレ席）、角度によっては譜面台やピアノの天板でですら演者の姿が隠れることも珍しくない。また前すぎても、その迫力と引き換えに音のバランスが偏ったり、ステージを一望できず演者同士の掛け合いを見失ったりすることもある。一方臨時席は、アリーナより高くステージから離れる分、基本的にその心配は不要だろう。

また今回のようなセクステット編成だと、なおさらステージを俯瞰できた方が、その全体像を余すことなく味わえたと思う。今回はなかったが、アーティストによっては客席外周を練り歩いてパフォーマンスすることもあり、その時は間違いなく臨時席の前を通るので得である。席料払ってアリーナで観るより、場合によってはむしろ体験を上回る可能性がある。（ちなみに2024年のケニー・ギャレットはアリーナ中央最前で観て、もちろんそれはそれで素晴らしかった。が、体験としては今回と比べても甲乙つけ難い。）

いくつか注意点（予約時オペレータからの案内を含む）：

• 入場は開演の5-10分前（と電話で案内されたが、15分前に通していただけた。ここは入場の状況にも依りそう）
• 席は先着順ではなく、指定席同様事前に決定される（公演前日のメール案内はなく、フロントでシート番号を渡される）
• ふつうにオーダーは必須
• 席の目の前は基本スタッフらが慌ただしく行き来する

最後のスタッフの行き来については、個人的にはまったく気にならなず、それどころかバー特有の活気ある雰囲気を楽しめたし、普段見ることのないスタッフの（公演開始前、開始後〜終盤と変わり行く）動きを知れて、むしろプラスだった。

---

まとめると、臨時席といえども、まったくあなどれないということ。カジュアルに肩肘張らず楽しみたいなら、むしろ全然アリだと思った（もちろんテーブル席で余裕ある時間を料理と共に楽しみながら過ごすのも◯）。

ちなみに「臨時席」という名前だが、調べた限りだとすべての公演に臨時席が用意されているように見えた。

昨年末暖房をつけ始めたあたりから、仕事中のコンディションが非常に悪い日が続き、その原因のひとつに部屋の二酸化炭素濃度があるだろうと考えていた。二酸化炭素濃度の計測は前々から興味あったが、計測器を買ったことがなかったので、これを機にアマゾンで購入してみた。

二酸化炭素濃度測定器［CO2ランプ］|CO2Lamp|CO2濃度測定器|日本製|日本精機|新潟県感染症対策認証制度対応製品

二酸化炭素濃度測定器で調べると無限に製品が出てきて何を選べば良いか分からないのだが、この日本精機 CO2Lampは、他の計測器と異なって数値ではなく青黄赤の3色カラーランプだけで現在の状態を示すのに惹かれて、かつメイドインジャパンだったので選んだ。およそ6千円が、ポイント使って半額以下で買えた。

届いてさっそく自室で計測しみたら、すぐさま真っ赤（2000ppm以上）に点灯して、換気の悪さが露呈した。

真っ赤なランプは、10分ほど窓を開けたら青（400-1000ppm）に戻った。青に戻っても窓を閉めると割とすぐに黄色（1000-2000ppm）に戻るため、自室で青ランプを持続するのは難しそう。

手のひらサイズで軽く、バッテリーは内蔵していない。そのため、基本は USB-C で給電して使用する。単四電池x2 も同梱されていて電池で駆動もするが、取扱説明書に書いてある通り、乾電池での連続使用はせいぜい8時間程度で、あくまで予備に留めるのがよいらしい。

使い勝手だが、3色ランプで示してくれるのは一目瞭然で分かりやすい。が、現状を知ると欲が出て、3段階以上の精度で知りたくなってくる。そういう意味では、400-1000, 1000-2000ppm と刻みが広いのは難点。

また、本製品サイトの紹介だとユースケースがオフィスや教室に偏っており、意外にも家庭用途が示されていない。実際に使ってみてその点は、仕事部屋やリビングだと問題はないと思った。が、

• ランプの明るさが、最弱でも（3段階で調整可能）そこそこ明るい
• 青→黄、黄→赤 と段階が上がるたびに電子音が鳴り、OFFにできない

という点で、寝室で使うには難がありそう。

---

とはいえ、一目瞭然のわかりやすさから早速寝起きに1度換気するようにはなったし、午後イチにも空気を入れ替えるなど、換気の習慣作りにはさっそく役立ち始めている。