2022 年 11 月12 日 (土) に開催される DjangoCongress JP 2022 に RevComm のエンジニアの松土慎太郎が登壇します。タイトルは「Django 管理コマンド manage.py を深掘り」です。 イベント概要 公式サイトより引用 https://djangocongress.jp/ DjangoCongress JPは日本で開催されるDjango Webフレームワークのカンファレンスです。 DjangoCongress JPは、Djangoでアプリケーションを開発している人、Djangoを学んでいる人などDjangoに関わる全ての人が参加できます。 参加する全ての人がDjangoについて交流し、出会い、学び、楽しみ、深い理解を得ることを目的にしています。 日程: 2022 年 11 月12 日 (土) 会場 日経カンファレンスルーム 参加申し込みは こちら 主催: 日本経済新聞社 デジタル編成ユニット 運営: django-ja 登壇情報 Django 管理コマンド manage.py を深掘り 公式サイトより引用 https://djangocongress.jp/#talk-11 manage.py は Django プロジェクトに欠かせない、様々な操作を行うためのコマンドラインユーティリティです。 本発表では、manage.py の内部実装を追いかけていき、どのようなことが行われているか見ていきます。 また、デフォルトコマンド (check, migrate, runserver, shell, testなど) の解説や、カスタムコマンドを非同期処理やバッチ処理で使用する事例を紹介します。 みなさんのハッピーDjango開発ライフの一助になれば幸いです。 日時: 2022年 11 月 12 日 (土) 17:10～17:55 (ROOM 1) 登壇者: SHINTARO Matsudo リンク: https://djangocongress.jp/#talk-11 最後に RevComm は電話営業や顧客応対を可視化する音声解析AI搭載型のクラウドIP電話「MiiTel（ミーテル）」を開発しています。 プロダクトの開発において Web アプリケーション、機械学習/深層学習などの領域で Python が広く使用されており、Django も採用しています。 「コミュニケーションを再発明し人が人を想う社会を創る」というミッションを達成するべく、一緒にプロダクトを開発して頂けるエンジニアを募集しています！ hrmos.co

RevComm の小門です。 2022年10月14日(金)～15日(土) に開催された PyCon JP 2022 に参加しました。 弊社からは陶山 嶺、川添 貴之の2名が登壇、松土 慎太郎がコアスタッフとして参加しました。 今回はカンファレンスの振り返りとして登壇者らのコメントと、トークの感想をお送りします。 登壇振り返り 詳解 print(“Hello, world”) 誰もが知る print() 関数の処理を例に、C言語/OS レイヤーの仕組みを深堀していきます。 そして Python を含め「プログラミング言語がどのようにして動くか」という仕組みを知れるきっかけになるかと思います。 登壇者: Rei Suyama (rhoboro) アーカイブURL: - YouTube 資料: docs.google.com 登壇の感想 バックエンドエンジニアの陶山です。普段は PBX という音声通話に関わる機能の設計、開発を行っています。 コロナ禍になってからはPyCon JPに限らずオンライン登壇ばかりでしたので、オフラインでの登壇は久しぶりでした。 オフラインだと参加者が目の前にいるため、反応を掴みやすい点はやはり良かったですね。 私の登壇は1日目の比較的早い時間帯だったため、その後の休憩時間などに「陶山さんのトーク聞いていました」と声をかけてくださった方々がいてとても嬉しかったです。 他の方々のトークでは、内容も当然のことながらスピーカーの方々の話し方や立ち振る舞いから学べることも多かったので、それらも今後の自分の発表に生活かしていきたいと思いました。 Fast API と学ぶ WebRTC リアルタイム通信の仕組みとして昨今主流になりつつある WebRTC について概要から導入し、デモを通して簡単に動きを追いかけていく内容です。 登壇者: Takayuki Kawazoe (@zoetaka38) アーカイブURL: - YouTube 資料: docs.google.com 登壇の感想 ソフトウェアエンジニアの川添です。普段は社内業務を円滑化することで事業に寄与するためのチームでマネージャーをしています。 このような登壇は経験がなかったので、資料作りから発表の仕方まで試行錯誤の連続でした。 よく言われることですが、発表というアウトプットをするために細かいところまで調べてインプットできたので、発表に対してだけでなく技術面・知識面の向上もできて非常に良い経験でした！ この記事をご覧頂いた皆様も、是非発表や登壇の機会があれば社内外を問わずチャレンジしてみて頂けるといいかと思います。 当日スタッフ バックエンドチームの松土がコアスタッフとして参加しました。 現地開催が3年ぶりということで混乱やトラブルが多かったかと思います。 裏方としてスタッフの皆さんがいたからこそイベントが成り立ちました。この場でも感謝申し上げます。 Python 3.11 is coming! 今回のイベントでは初日の基調講演をはじめ、Python 3.11 の性能改善 (高速化) や新機能に関わるトークが複数ありました。 Day2 16:00〜「 What's new in Python 3.11 and beyond 」より内容をピックアップします。 性能改善 例外処理のオーバーヘッドが10～15%から1%程度まで削減 正規表現の処理が10%程度高速化 関数呼び出しが10～20%高速化 “ float -heavy” つまり浮動小数の演算が行われていれば、50～60%程度高速化 ※ただし「Numpy をはじめとするライブラリは使用せず、標準機能の場合」と言及あり 上記のように一言で「性能改善」と言っても、実際は様々なケースで地道な改善が行われていることが分かります。 トータルとしては「多くの場合で 20～30% 程度の性能改善が期待できる」とのことです。 機能追加 Exception Groups (例外グループ) raise ExceptionGroup による「例外グループの送出」 except* による「例外グループの捕捉」 Asyncio Task Groups (非同期タスクグループ) asyncio.gather() の代替機能 例外グループ機能によってエラーハンドリングする 型関連 typing.Self 自身のクラスを表現するためのエイリアス クラス継承やファクトリーに最適 Variadic Generics (可変長ジェネリクス) tomlib (PEP 680) TOML パーサーの標準サポート 機能追加の全容、詳細は公式ドキュメント What’s New In Python 3.11 で確認できます。 新機能の追加とアップデート、特に asyncio と typing 周りは昨今着々とアップデートされてきており、今後は積極的に Python 3.11 に移行していきたいところです。 そして Python 3.11 に移行する だけ で性能改善が期待できるのはとても嬉しいですね。 そんな Python 3.11 は 10/24(月) にリリース予定 です！ PEP 664 – Python 3.11 Release Schedule まとめ PyCon JP 2022 は3年ぶりにオフライン開催で行われ、私は今回が初めての現地参加でした。 参加した一番の感想は「 とにかく楽しかった！ 」ということです。 多くのエンジニアが同じ場所に集まって技術を共有し合えることはもちろん、参加者や登壇者の熱量を現地で感じることができました。2日間ずっとワクワクしていました。 また RevComm は全社員がフルリモートで働いています。 今回登壇した陶山と川添は遠方からの現地参加だったため、今回初めて対面しました。 普段は直接会わないメンバーとイベントをきっかけに顔を合わせてたくさん話をすることができました。 左から小門、松土、川添、陶山 イベントを支えてくださった登壇者、スタッフの皆さん、協賛企業様に改めて感謝申し上げます。 来年もぜひ参加したいです！ 最後に RevComm では Python でのアプリケーション開発に熱意のあるエンジニアを募集しています。 RevComm では自社プロダクト「MiiTel（ミーテル）」の開発において Web アプリケーション、機械学習/深層学習などの領域で Python を広く使用しています。高い安定性とスピードを両立して開発を進めるため、試行錯誤を続けるチャレンジングな環境です。 ぜひご応募をお待ちしています。 hrmos.co

2022年10月14日(金)～15日(土)に開催される PyCon JP 2022 に RevComm のエンジニアの陶山 嶺と川添 貴之が登壇します。 イベント概要 公式サイトより引用 https://2022.pycon.jp/ PyCon JP は、Python ユーザが集まり、Python や Python を使ったソフトウェアについて情報交換、交流をするためのカンファレンスです。 PyCon JP の開催を通じて、Python の使い手が一堂に集まり、Python にまつわる様々な分野の知識や情報を交換し、新たな友達やコミュニティとのつながり、仕事やビジネスチャンスを増やせる場所とすることが目標です。 日程: 2022年10月14日(金)～15日(土) 会場 TOC有明コンベンションホール 参加申し込みは こちら オンライン: YouTube Live 主催: 一般社団法人 PyCon JP Association 登壇情報 詳解 print("Hello, world") 新しい世界に飛び込むときの定番 Hello, world 。 Python に出逢い学び始めたとき print("Hello, world") を実行したひとも多いのではないでしょうか。 このトークでは、Python に慣れた今だからこそ改めて print("Hello, world") を実行し、その裏側で起きていることを深掘りしていきます。 Python の仕組みやシステムプログラミングの世界に Hello, world しましょう！ 日時: 2022年10月14日(金) 13:00～13:30 登壇者: Rei Suyama リンク: https://2022.pycon.jp/timetable?id=ZJB8DS Fast API と学ぶ WebRTC 近年、様々な分野で使われるようになったWebRTCを使ってのクライアント・サーバ間のリアルタイム通信。 この技術はこれからのリアルタイム通信を利用したサービスに置いては必須の技術になりつつあります。 このトークでは、そんなWebRTCについて、FastAPIを利用してWebRTCサーバを簡易実装して、WebRTCの中身について実装とともに解説します。 日時: 2022年10月14日(金) 14:20～16:50 登壇者: Takayuki Kawazoe リンク: https://2022.pycon.jp/timetable?id=JKLGKZ 当日は FastAPI + aiortc を用いたデモを交えながら WebRTC の動作を深追いしていきます。 最後に RevComm は電話営業や顧客応対を可視化する音声解析AI搭載型のクラウドIP電話「MiiTel（ミーテル）」を開発しています。 プロダクトの開発において Web アプリケーション、機械学習/深層学習などの領域で Python が広く使用されています。 「コミュニケーションを再発明し人が人を想う社会を創る」というミッションを達成するべく、一緒にプロダクトを開発して頂けるエンジニアを募集しています！ hrmos.co

今回は、チーム開発などにおいて運用しやすくなる、エンジニアのための「より綺麗なCSSの書き方」を紹介します。 !important を使わない 余分な div は書かない CSS セレクタを深くしない HTML に style を直接指定しない 自分より外のコンポーネントに margin の情報を持たせない まとめ !important を使わない 例えば、以下のようなHTMLがあったとします。 < style > p { color : red !important ; } </ style > < p > 青色のテキスト </ p > < p > 緑色のテキスト </ p > ここで要件として「文字色が赤なのをそれぞれに合った色にしたい」とします。 そこで blue 、 green というクラスで色を変更してみます。 修正は以下の通りです。 <style> p { color: red !important; } + .blue { + color: blue; + } + .green { + color: green; + } </style> - <p>青色のテキスト</p> - <p>緑色のテキスト</p> + <p class="blue">青色のテキスト</p> + <p class="green">緑色のテキスト</p> 結果は、文字色は変わらず赤色のままです。 これは p タグに対して !important が指定されていることが原因です。 まず、CSS には優先順位があり !important を指定しない場合、後者が優先して適用されます。 p タグ (要素型セレクタ) .blue または .green (クラスセレクタ) このような優先順位のことを「詳細度 (Specificity) 」と言います。 参考: 詳細度 - CSS: カスケーディングスタイルシート | MDN 詳細度は 0 以上の数値で計算され、ある要素に対して複数の style が指定される場合、数値(= 詳細度) の高い CSS 定義が優先して適用されます。 しかし !important を使用した場合、詳細度が強制的に上書きされてしまいます。 したがって上記HTMLの例では、 p { color : red !important ; } が優先され、文字色は赤色のままだったのです。 この場合、文字色を変更するには .blue や .green の各クラスにも !important を指定するしか方法はありません。 上記で紹介した MDN の参考リンクでも !important の使用は「 悪しき習慣 」とされています。 また詳細度の計算例をご紹介します。 ( Specificity value が高いほど優先順位が高い状態となります) 引用: CSS Specificity - W3Schools 今回のように、影響範囲が目に見える形であればよいですが、そうでない場合は「想定していない箇所まで修正してしまう」ことになります。 基本的に !important は使わない運用にした方が良いでしょう。 仮に運用中のコードで既に !important が使われている場合、なるべく影響範囲が小さくなるような修正にするべきです。 上記例のHTMLで新たに「テキストを太字にしたい」という要件が追加になった場合、以下の修正となるイメージです。 p { color: red !important; /* こちらに変更を加えると影響範囲が大きい font-weight: bold !important; */ } /* 新たにクラスを用意して適用 */ .text--bold { font-weight: bold !important; } < p class = "text--bold" > 太字のテキスト </ p > 余分な div は書かない 「CSS の書き方とあるのに div ?」と思われるかもしれませんが、とても大切なことです。 1番の大きな理由は、次に話す「CSS セレクタを深くしない」にもつながるのですが「余分なコードを書かずに済む」ためです。 div に限らず、その要素がなくても構成が成り立つ要素を入れると、HTML の構造が複雑になってしまい、開発者・それを解釈してレンダリングするマシンにとっても優しくないコードとなります。 「セマンティクスを意識してコードを書くことで、文書構造をシンプルに保つこと」が CSS をシンプルに保つためにも非常に重要になってきます。 参考: HTML: アクセシビリティの基礎 - ウェブ開発を学ぶ | MDN 例えばよくあるパターンとしては、h2 や p を無意味に囲むものです。 Bad: < div class = "wrapper" > < div class = "head_margin" > < h2 class = "head" > h2 </ h2 > </ div > < div class = "text_margin" > < p class = "text" > あいうえお </ p > </ div > </ div > .wrapper .head_margin .head { font-size: 16px; margin-bottom: 8px; } .wrapper .text_margin .text { font-size: 14px; } これは、下記のように簡略化することができます。 Good: < div class = "wrapper" > < h2 class = "head" > h2 </ h2 > < p class = "text" > あいうえお </ p > </ div > .wrapper .head { font-size: 16px; margin-bottom: 8px; } .wrapper .text { font-size: 14px; } 無駄な div (div に限りません) は削減していきましょう。 ※ 今回は一例として 不要な div の例を出しましたが、ブロック要素をまとめる場合など例外もあるため、適材適所で使用します。 また「A > B (A の B要素にのみ適用する)」などを使っていると、クラスセレクターを当てるときに、うまく当たらない場合があります。これは下の「余分にセレクタを指定しなくて済む」に繋がってきます。 CSS セレクタを深くしない CSS セレクタを不用意に深くしてしまうと可読性が下がり、詳細度が上がってしまうため、意図しない修正をしてしまう可能性があります。 例えば「赤」という文字だけ赤色にしたいのに、うまくいかないパターンがでてきます。 例: .block > .text { color: yellow; font-size: 12px; } .block > .wrapper > .text { color: red; font-size: 12px; } .block > .wrapper > .text > .small { font-size: 10px; } < div class = "block" > < p class = "text" > 黄色 </ p > < div class = "wrapper" > < p class = "text" >< span class = "small" > ※ </ span > 赤 </ p > </ div > </ div > このように CSS 設計を考慮しない状態でクラスを書くと、深くセレクタを指定することになります。 「文字のサイズは共通化したい」のに共通化ができなくなってしまう、ということになってしまいます。 1ページのみの LP ページなどでは特に困らなくとも、大規模な Webサービス・アプリケーションでやると、管理が大変なことになります。 例えば .block ではなく .block-2 というコンポーネント配下で同じようなことをしたいとき .block-2 > .text { color : yellow ; font-size : 12px ; } .block-2 > .wrapper > .text { color : red ; font-size : 12px ; } .block-2 > .wrapper > .text > .small { font-size : 10px ; } と、同じコードを指定しなければいけません。 同じコードを複数作らずに使いまわすことで共通化ができ、可読性・管理の向上にもつながります。 先ほどのコードを CSS セレクタを深くせずに書くと、以下のような一例になります。 < style > .block .text { font-size : 12px ; } .block .text--yellow { color : yellow ; } .block .text--red { color : red ; } .text > .small { font-size : 10px ; } </ style > < div class = "block" > < p class = "text--yellow" > 黄色 </ p > < div class = "wrapper" > < p class = "text--red" >< span class = "small" > ※ </ span > 赤 </ p > </ div > </ div > 一見すると最初のコードより量が増えたように見えますが、.block 配下の .text に font-size を一括で指定することができています。 このように「階層構造が違うだけで、スタイル自体の指定は同じコード」はコード管理のコストが減るため、できるだけ共通化した方がよいです。 その他の解決策としては「ユニークなクラス名を使用する」などがあります。 (例: .block > .text も .block > .wrapper > .text も、クラスの役割は同一のため) HTML に style を直接指定しない <div style="background: blue"> のように、直接 HTML 要素に CSS を記載しているケースがあります。 このように、HTML に直接 style 要素を記述するのは避けましょう。（インラインスタイルとも呼ばれます） インラインスタイルを使用すると外部 CSS よりも優先されるため見通しが悪くなり、コードの保守性の低下につながります。 Bad: // HTML < button style = "background: blue;" > ボタン </ button > Good: // CSS .bg-blue { background: blue; } // HTML < button class = "sample-button" > ボタン </ button > 自分より外のコンポーネントに margin の情報を持たせない このデザインを作りたいとき、あなたならどうコーディングしますか？ よく下記のようなコードが書かれがちですが、実はベストプラクティスではありません。 < style > .title { margin-top : 16px ; } .title_text { margin-top : 16px ; margin-bottom : 16px ; } </ style > < div class = "wrapper" > < h2 class = "title" > title </ h2 > < p class = "title_text" > sub title </ p > </ div > このように「自分より親の要素」に対して余白を空けたいときに情報を持たせるべきではありません。(この場合は .wrapper の上余白調整のためのCSS) .title を他の要素で使いたくなったときに、その要素用に CSS を書き直さなくてはいけなくなる .title の上に何か要素を置いたときに .title で保っていた上部分の余白を、新規で置いた要素に置き換えなければいけなくなる などのデメリットが出てきます。 この場合は .title に情報を持たせるのではなく .wrapper に余白の情報を持たせるべきです。 < style > .wrapper { padding : 16px ; } .title_text { margin-top : 16px ; } </ style > < div class = "wrapper" > < h2 class = "title" > title </ h2 > < p class = "title_text" > sub title </ p > </ div > まとめ 以上、より綺麗な CSS を書くためのワンポイントアドバイスを紹介しました。 アドバイスとありますが、今回記載したものはあくまで実践で得た一例になります。 開発をする上での 一つの指標にしていただければと思います。 参考リンク: MDN による CSS のまとめ: https://developer.mozilla.org/ja/docs/Web/CSS

RevComm の木村です。 所属チームはInfrastructure（インフラチーム）です。 今回は、RevCommの全社オフサイトに関する記事の第3弾になります。 第1弾： 【レポート】年に1度の全社オフサイトミーティングを開催しました！ 第2弾： RevCommインハウスデザインナーが取り組んだ「イベントデザイン」の制作裏話 オフラインでの開催予定だった会が急遽オンラインイベントとなり、第1部はZoom開催、第2部の懇親会はGatherでの開催となりました。 Gatherとは、2D RPGのような雰囲気でアバターを操作して会話や画面共有をしながらビデオチャットを行うことができるバーチャルスペースです。 本記事では、Gatherを利用した参加者 160人超 のオンラインイベントを実現する上で発生した課題と解決策に関して触れていきたいと思います。 記事の構成は以下のとおりです。 第1章 - バーチャルスペースの方法 第2章 - リハーサル時に発生した問題とその解決策 第3章 - イベントを終えてみての感想 第4章 - さらなる工夫 第1章 - バーチャルスペースの方法 本記事では、イベントの参加人数とコンテンツ内容は決まっているものとします。その段階でまず行うべきことが、会場の作成です。 Gather公式のテンプレートもいくつかあり、公式のマップエディタも存在するためスペース作成をブラウザ上で完結することも可能です。しかし、今回は条件に見合う公式テンプレートがなく、さらに公式マップエディタの自由度も少なく感じたため、 Tiled というマップエディタを利用してスペースを作成することにしました。 スペースの作成自体は本記事の主題ではないので軽く触れる程度に説明しますが、以下の5ステップを実行してGatherのスペースを作成しました。 32×32のマスでスペース全体のサイズを決定する Tiled上でGatherのタイルセットを配置して、PNG形式でエクスポートする PNGをPhotoShopで編集して、文字や矢印を配置する 出来上がった画像をGather上でインポートする Gather上でSpotlightやワープ設定、制限エリアなどを設定する 結果として、今回作成したスペースは以下の構成になりました。 幅1280px × 縦2560px（40マス × 80マス）の2ルーム構成 メインルーム側には司会者用にSpotlightを多数配置する サブルーム側には中継者用のSpotlightを少数配置する 各ルームの上段にはテーブルを配置する テーブルにはPrivate Areaを設定する ※スペース設計にもこだわりが隠れているのですが、本記事では割愛します。 第2章 - リハーサル時に発生した問題とその解決策 いよいよ作成した会場でリハーサルです。 前提として、今回のイベントでは、参加者に対して司会者が画面共有をしながら運営を行う必要がありました。 Gatherの公式ページには、100人以上の参加者がいるルームで配信を行う場合には、YouTube LiveやZoomなどの別ツールを使用することが推奨 されています。 調査をしたところ、配信者用のルームを別途用意し、会場に設置したEmbed Mediaで配信者の風景をYouTube Liveで配信するといった記事がWeb上で見つかりました。 今回も当初は見つけた記事と同様に別室からの配信を行う選択肢を検討しました。しかし、試行錯誤の結果、低遅延で画面共有を行いつつ会場の雰囲気を司会者に伝えるために配信用のルームは作成せず、メインルームの内容をサブルームに配信する方式を採用しました。 この方法であれば、各ルームの参加人数が100人を超えないように調整しながら、司会者にもライブ感を伝えることが可能です。 ※中継者の画面。参加者の反応が見えることが分かります。 懇親会のコンテンツとしては複数の企画がありましたが、その一つに ennoshita と言うツールを利用したクイズがありました。クイズの設問もその場で提示され、回答までの時間制限もある、リアルタイム性が厳しく求められるコンテンツです。 ※実際に実施されたクイズの画面。 当初検討していたYouTube Liveを利用する方法では、数秒の遅延が発生することがあらかじめ分かっていました。そこは司会者の話術でカバーしてもらう想定でしたが、実際にリハーサルを実施してみると、話術ではカバーできない問題が発生しました。 具体的には、ライブ配信を見ている人によって配信のタイムラインがずれるという問題です。司会者の知らないところで配信が遅れている状態では、クイズの進行が成り立たなくなるため致命的です。 また、GatherのEmbed Mediaの仕様も、この問題をより深くした理由です。 GatherのEmbed MediaにYouTube Liveを埋め込んだ場合には、YouTube側のコントロール機能が隠されてしまい、一時停止および再生のみ実施できる仕様になっています。そのため、ユーザ側の操作で最新のタイムラインに移動することが一切できません。 ※YouTube公式サイトにはある上記のコントロール機能が隠されてしまいます。 事前に小規模なテストをしていた際には、配信とのギャップが10秒ほどあれば、最新のライブ映像状態にスキップされる動作（※）が確認できていました。しかし、より大規模にリハーサルを行ったところ、そのスキップ動作が再現されない人がいました。先に述べたとおり、コントロール機能は隠されているため、こうなるとどうしようもありません。 ※実際には、一時停止後に再開するという操作が必要でした。 この問題が発覚したのは本番2日前のリハーサルで、今さらコンテンツの内容を変えることはできません。Gatherでの配信を諦め、Zoom配信に切り替えるべきかと全関係者で悩んでいたところに、とあるひらめきが天から舞い降りました。 ここからが本記事の本題です。 ひらめきにより実現された、公式のベストプラクティスを超えた配信方法の概要は以下のとおりです。 同一のPCから各ルームに中継用のアバターを設置（送信者、受信者） メインルームの画面を中継用のアバターで画面共有し、サブルーム内にSpotlightで共有 ルーム間の中継をYouTube Liveで行わず、同一のPCを利用する点が一番のポイントです。 全体構成を図にすると以下のようになります。 この方法のよい点をまとめると以下になります。 ルーム間の転送に要する遅延がほぼない（およそ0.1秒） 仮に人数がさらに倍になったとしても、ルームと中継者を増やすことでスケールアウトが可能 中継者は2ルームとも様子が見えているため、不測の事態に対応しやすい ※実際にサブルーム側の準備が整う前にクイズが進行しそうになったので、中継者をしていた私が司会者に声をかけ、進行を待ってもらいました。 逆に悪い点をまとめると以下になります。 メインルームからの一方向の共有となるため、メインルーム側の参加者からはサブルーム側の状況が見えない（※おそらく改善可能で、第4章で触れます） 中継担当者も一参加者としてイベントに参加する場合は、中継用とは別のPCが必要になる PCと画面がたくさんないと、全部を把握することが難しい ※当日はこんな形で参加していました。右上のディスプレイには、別入力で中継者の画面が全画面表示されています。 第3章 - イベントを終えてみての感想 Gatherを採用した決め手は、ホテルなどの会場を借りて実施する懇親会のように参加者が自由に各テーブルを移動しながら懇親できる場を用意したいという点でした。今回は、思惑通りに各テーブルでの会話が繰り広げられていました。 RevCommはフルリモートの社員が多いためオンラインの懇親会の開催頻度は多いのですが、普段はZoomやGoogle Meetを利用しています。今回の経験から、オフラインの空気感を再現することができるGatherを利用した懇親会もいいものだなと思いました。 第4章 - さらなる工夫 悪い点でも取り上げましたが、今回採用した方法はメインルームからの一方向配信です。 さらに大規模なイベントやコンテンツの内容次第では、ルーム間でのやり取りもしたくなることもあると思います。ということで、改善の余地がないか考えてみました。 一方向配信にしていたのは、音声がループすることが理由でした。逆に言うと、音声のループ問題さえどうにかできれば、ルーム間での双方向配信が可能になります。 改めてGatherの設定を行い、ループ問題が解決できないか確認してみました。その結果、理屈上は以下の構成を取ることにより双方向での配信が可能ではないかという結論に至りました。まだ実際に試してはいませんが、試された方がいれば ツイッター などで教えていただけると幸いです。 基本的な構成は同様 中継者を1名追加（便宜上Proxyとします） 中継者AのGather上で、Proxy BのUser Volumeをミュートする

この度、2022年10月5日(水)〜7日(金)に開催される DroidKaigi 2022 に SUPPORTER スポンサーとして RevComm が協賛します。 イベント概要 公式サイトより引用 https://droidkaigi.jp/2022/ DroidKaigiはエンジニアが主役のAndroidカンファレンスです。 Android技術情報の共有とコミュニケーションを目的に、2022年10月5日(水)〜7日(金)の3日間開催します。 日程: 2022年10月5日(水) ～ 7日(金) 会場 東京ドームシティ プリズムホール オンライン ( Youtube ) 主催: DroidKaigi 実行委員会 RevComm は技術コミュニティの応援、貢献に引き続き取り組んでまいります。 最後に RevComm では自社プロダクトの通話用アプリ「MiiTel Phone Mobile」を iOS、Android で開発しており、モバイルアプリエンジニアを募集しています。 hrmos.co

初めまして、RevCommインフラチーム所属の平島と申します。 インフラチームは、主に当社で用いられる全マイクロサービスの共通基盤の設計・構築・運用を担当していますが、それに加えてSite Reliability Engineering (SRE) 業務も担っています。その SRE 業務の一環として、サービスのセキュリティ強化に順次取り組んでいます。 セキュリティ対策の一つひとつは、技術的には地味なことも多いです。しかし、どこかに対策漏れがあれば、情報漏洩などの重大インシデントを引き起こしかねません。ひとたびそのような事態が引き起こされれば、多額の損害賠償や信用失墜による顧客離れなどのネガティブインパクトが非常に大きいため、セキュリティ向上はビジネスでは非常に重要なタスクです。 今回は以前に取り組んだ AWS 上のセキュリティ対策である、CloudFront を経由しないApplication Load Balancer (ALB) へのアクセスを制限する方法についてご紹介します。 前提 セキュリティ上の課題 方法 1：カスタムヘッダーを利用したリクエストの検証 方法 1 のデメリット 方法 2：AWS Managed Prefix Listを利用した Security Group によるアクセス制限 AWS Managed Prefix List とは 設定 まとめ 前提 今回想定するのは、以下のような CloudFront-ALB-Elastic Container Service (ECS) で構成されたアーキテクチャです。ユーザからのリクエストはすべて CloudFront が受け付け、CloudFront-ALB 間は HTTPS で接続するものとします。 また、CloudFront にはWeb Application Firewall (WAF) を設定しており、リクエストの中身を検査します。 セキュリティ上の課題 ALB は世界各所に設置された CloudFront のサーバーからアクセスを受け付けるために、インターネットに向けて設置する必要があります。逆に言えば、ALB の DNS 名が外部に漏れてしまった場合、CloudFront を経由せずとも、直接 ALB の DNS 名を指定してアクセスすることが可能です。 これは CloudFront で設定した WAF によるリクエストの検査をすり抜けることと同義であり、セキュリティリスクとなりえます。したがって、CloudFront 以外からの ALB へのアクセスを何かしらの方法で防ぐ必要があります。 方法 1：カスタムヘッダーを利用したリクエストの検証 AWSによって公式に紹介されている方法で、当初はこちらを採用していました。 大まかな方針は以下の通りです。 CloudFront において、到来したリクエストに対してカスタムヘッダーを付与する。カスタムヘッダーの値には、秘密の値を設定する。 ALB のリスナールールを設定して、カスタムヘッダーの値が秘密の値と一致するか検証する。一致した場合はアプリケーションの Target Group にリクエストを転送し、一致しない場合は 403 エラーをクライアントに返す。 それでは、AWS Console 上で具体的な設定方法を見ていきます。 まず、CloudFront の設定を行います。オリジンである ALB にリクエストを転送する際に付与するカスタムヘッダーは、オリジンの新規作成／編集画面で設定することが可能です。 ここでは仮に、ヘッダー名を "x-cf-secret"、値を "test1234" としておきます。 次に、ALB Listener の設定を行います。CloudFront でオリジンとして設定した ALB のListener Rule を編集します。今回は、HTTPS (443) のリスナーを編集します。 まず、Target Group へ転送する既存ルールについて、それぞれ条件を設定します。「条件の追加」から「HTTP ヘッダー」を選択し、CloudFront で設定したカスタムヘッダー名と値をそれぞれ入力します。 さらに、一番最後のルール（デフォルトルール）では、常に 403 エラーを返すよう設定します。 以上で設定は完了です。実際にオリジンに直接リクエストを飛ばすと、403 が返ってくることが確認できます。 方法 1 のデメリット カスタムヘッダーの情報が漏洩した場合、ヘッダーさえ付与していれば、CloudFront 以外からでもオリジンにアクセスできてしまいます。つまり、カスタムヘッダーは秘匿情報にあたりますが、方法 1 ではその秘匿情報が平文の状態で CloudFront、ALB Listener それぞれの設定に保存されることになります。そのため、開発者・運用担当者が容易に秘匿情報にアクセスできてしまいます。 秘匿情報へのアクセスを厳格に管理するなら、前記 2 つのリソースに対して、IAM Role などによる閲覧制限を行う必要があります。ただし、権限の設定が煩雑になる上、カスタムヘッダー以外の設定作業においても作業者が限定されてしまうなど、日常の開発・運用に支障をきたすおそれがあります。 方法 2：AWS Managed Prefix Listを利用した Security Group によるアクセス制限 2022年2月に CloudFront の Managed Prefix List が公開されたことで、方法 1 よりも簡単に目的を達成できることが判明しました。そのため、弊社では現在こちらの方法を採用しています。 AWS Managed Prefix List とは AWS Managed Prefix List（以下、Prefix List）は複数の CIDR Block を一括して登録・管理することができる機能です。Security Group の Rule を作成する際に、ソースとしてこの Prefix LIst の ID を指定することができます。こうすることで、Prefix List に登録されたすべての CIDR Block に対してRule が適用されます。 また、いくつかの Prefix List がデフォルトとして用意されています。CloudFront の Prefix List はその 1 つで、CloudFront から ALB へリクエストが転送される際は、この Prefix List に登録された CIDR の範囲に含まれる IPアドレスからリクエストが送られることになります。 ここでは、CloudFront の Prefix List をソースとした Security Group を作成し ALB にアタッチすることで、CloudFront 以外からのアクセスを防ぎます。 設定 まず、VPC > マネージドプレフィックスリストより、CloudFront の Prefix List を確認します。Prefix List 名 "com.amazonaws.global.cloudfront.origin-facing" が、今回使用する Prefix List です。 次に Security Group を作成します。Inboud Rule では HTTPS のソースに先ほど確認した Prefix List の ID を指定します。 最後に、作成した Security Group を ALB にアタッチすれば完了です。 実際に curl を使ってオリジンにアクセスしようとすると、応答がないままタイムアウトします。方法 1 と挙動は異なりますが、接続を阻止できていることに変わりありません。 まとめ 今回は、CloudFront 以外からの ALB へのアクセスを防ぐ方法を 2 つ紹介しました。 方法1（カスタムヘッダーを用いるやり方）と比べて、方法 2 （Prefix List を用いるやり方） は、 秘匿情報の管理が不要 作業が少ない（Security Group を作成してアタッチするだけ） という点でメリットが大きいです。結論として、何か特殊な事情がない限りは Prefix Listを用いる方法 2 をお勧めします。

今回は QA チームのインタビューです。 システム開発において QA (Quality Assurance; 品質保証) とは、成果物であるソフトウェアの品質を保証する業務を指します。RevComm においては、MiiTel に不具合がないか、新機能導入時に既存機能との整合性がとれているかなど、お客様に安心して MiiTel を利用いただくために様々な観点からテストをすることがメインの業務です。 RevComm のQA チームは 2022 年 8 月現在でこそ 6 人体制になりましたが、半分ほどのメンバーが 2022 年入社の方で構成されており、まさに、これからチームの基盤を強化していくフェーズになっています。 RevComm が提供している MiiTel は電話サービスであり、高い信頼性が求められます。一方で MiiTel for Zoom を 2022 年 7 月にリリースするなど、まだまだ機能の追加や発展も著しい側面もあります。お客様に MiiTel を安心して使っていただくため、品質向上のための取り組みは重要度を増すばかりです。 そこで今回は MiiTel の品質保証を担う QA チームの廣瀬さん、福田さんのおふたりにお話を伺い、これまでの QA チームの活動や工夫してきたこと、今後やっていきたいことなどについてお聞きしました *1 。 廣瀬 知里 新卒から IT 業界で開発、工程管理などに携わり、その過程で QA に関心を持つ。その後、エンジニアやカスタマーサポートの経験を経て、2020 年の 2 月に RevComm にカスタマーサポートとして参画。現在、RevComm の QA チームが属するサポートチームのリーダーを務める。 福田 華奈子 新卒からプログラマーとして主に Windows アプリの開発等に従事。経験を重ねていく過程で、運用・保守のみならずカスタマーサポートとしても経験を積み、2020年 10 月に RevComm にサポートチームのメンバーとして参画。入社後、サポート業務をする傍ら QA チーム立ち上げに携わる。 お客様の気持ちになってテストする 「開発も QA もお互いに尊重し合う」 自動化の及ばない領域 メンバーが助け合うようになれたら お知らせ 終わりに お客様の気持ちになってテストする ── QA チームの成立の経緯をまず教えてください 廣瀬: もともと RevComm ではエンジニアの方が責任をもってテストするという方針で、そこは徹底されていました。ですが、開発者だけではどうしてもお客様の利用状況をカバーしきれないことがあり、2021 年の夏頃に福田さんが入社されたのを機に、開発者とは異なる目線でのテストを本格的に始めよう、というのがチーム発足の経緯です。 ── RevComm の組織図では QA チームは開発チーム配下ではなく、カスタマーサポートチーム配下になっています。その理由はなんでしょうか 廣瀬: 成り立ちからもわかるように、元からユーザー目線といいますか、お客様の気持ちになってテストをしてみたくなった、というのが発端にあります。それはサポートという仕事をしているからできた発想だったのかなと思います。 大きな開発組織だと、開発部門のQAチームと全体の品質管理の部門とで分かれているような組織もあります。後者がユーザー目線でのテストをするチームで、わたしたちが目指しているのは後者の役割を担うことです。 ── 機能を実現できているかなどが中心となる作り手の視点でのテストというより、ユーザー目線でのテストをするチームということですか？ 廣瀬: そうです。お客様は開発者が意図しない操作をすることもあるんですが、それを作り手が意識してテストすることは難しいんじゃないかなと。開発者とは違う目線、違う視点でできるテストもあるんじゃないか、その両方のテストをやることで品質面に貢献できるんじゃないかと考えています。 福田: サポートチームに上がってくる問い合わせは開発者やサポートチームも予期していなかった使い方があがってくることもあるので、その知識をテストの観点に活かせるのがいまの体制の強みかなと思っています。 「開発も QA もお互いに尊重し合う」 ── QA 業務でやりがいを感じるときはどんなときですか？ 福田: 開発者が新たに実装したものが、お客様の目線からするとすごく大きな変化になってしまうなと感じることがたまにありました。これをそのままリリースするとお客様が困ってしまいますよ、ということを開発者に伝えると受け止めてもらえるんですね。そして、じゃあどうしようかという建設的な議論ができます。それが RevComm の凄いところだと思います。 これが仕様なんだよで終わらないで、一回考えようと議論をする場面が結構多いので、気づいたことをお伝えできると、とてもよかったなと思います。 ── 議論をして実際に改善につなげられているのは素晴らしいことですね。開発チームとのコミュニケーションで何か工夫していることはありますか？ 廣瀬: 福田さんに開発チームのテストや品質改善に関わるチームのミーティングに毎週参加してもらって、開発チームの取り組みをキャッチアップをしています。毎週参加することでお互いの立場を理解しようと努めているとか、小さいことの積み重ねから信頼が生まれていったのかなと思います。 あとやっぱり、開発とテストはぶつかることも正直あると思うんです。でも、率直に意見を交わしてもあまりぶつからないでできているのは、お互い頼っているし、尊重することができているからだと思っていて。それは QA とか関係なく、全社的に相手の立場に立ったコミュニケーションをお互い意識できているからなのかなと思います。 自動化の及ばない領域 ── 開発チームと連携して Autify の導入を進めていますが、自動化についてはどんな恩恵を感じていますか？ 福田: 単純に、リリース後の手動確認の負荷が軽減されましたね。問い合わせベースの不具合修正をリリースしてもらうとき、今まではその周辺で問題が起きてないかとか不安になることもあったんですが、今はテストが実行されて Slack でテストの成功通知を見るとやっぱり安心感が違います *2 。 廣瀬: 自動化自体もそうなんですが、導入を機会に仕様や機能を体系的に整理するきっかけになったと思うんですよね。 サポートチームがこれまで内々で作ってきたテストケースや仕様の整理が開発チームの方に活用いただけたり、逆に開発チームの方がつくったテストケースで新たな観点を知ったり。製品に対する理解をチームをまたいで深めるような相乗効果があったように感じてます。 ── ツールの手が及ばない、人の手がどうしても必要な部分ってありますか？ 廣瀬: 電話という特性上、お客様の環境や外部要因ということもあるので、そういう部分はどうしてもカバーしきれないところはありますね。 たとえばモバイルアプリの場合、アプリの問題なのか、OS のバージョン差異起因なのか、はたまた端末固有の事象なのかということもあって。切り分けも難しいし、再現が難しいことがあるとどうしても時間がかかりますね。 多くの Web アプリケーションだと、お客様からご報告いただいた事象はだいたいこちらでも再現できるんですけど、電話アプリだと必ずしも再現しきれなかったりするのでそれが難しいなと思いますね。 メンバーが助け合うようになれたら ── これからやりたいことを教えてください 廣瀬: メンバーが増えたので、やっと今までよりも時間を割けるようになってきたので、もっと QA の観点を醸成していきたいですね。 それから QA チームの体制作りに本腰を入れていきたいです。いったんプロダクトそれぞれに対してメンバーをメイン担当にアサインしてという形で体制作りをしていきます。 一方でユーザー目線のテストという観点だと、自分の担当プロダクトしかわからない、だと難しいと思っています。幅広く知識を得るためにも、それぞれのメンバーが助け合って動けるようになれたらいいなと思っています。 ── チームとしてより成果をあげるための体制作りをこれから時間をかけてやっていくということですね。これからもご協力よろしくお願いします。今回はありがとうございました！ お知らせ RevComm の QA チームの大野泰代が、2022 年 10 月 1 日（土）に行われる 「XP 祭り 2022 @ Online 」にて登壇します。 xpjug.com XP 祭りはソフトウェア開発の現場をよりよくするためにできることを発表する場です。大野はRevComm への転職を踏まえて、QA エンジニアが自分のスキルや働き方にマッチした転職方法を紹介する予定です。 QA チームメンバーの話を直接聞ける場になります。お時間ありましたらぜひご参加ください。 終わりに MiiTel はこれまでになかった価値を届けるプロダクトであると同時に、電話というお客様の業務のインフラとなるプロダクトでもあります。日々お客様が安心して使えるよう、品質保証への取り組みをさらに強化していきます。 この記事を読んで MiiTel の開発や品質保証に興味をもっていただけた方は、ぜひ当社の採用サイトをご覧ください。 www.revcomm.co.jp 企画・聞き手・文責 小島孝弘 RevComm Tech / Backend チーム 聞き手・編集 小門 照太 RevComm Tech / Infrastructure チーム *1 : インタビューはオンラインで実施しました。 *2 : より詳しくは Autify 社からのインタビュー もぜひご覧ください:

モバイルエンジニアの長尾です。 最近は暑くてすっかり外に出なくなってメタボ体型になってしまったので、定期的に運動する方法としてジムに通うようになりました。やっぱり運動はいいっすね。 はじめに バックグラウンドでの着信時の動作 フォアグラウンド状態での動作をバックグラウンド状態でも続けたい時の動作 まとめ 最後に はじめに みなさんは、iOSアプリは、ユーザーには見えていないけれどもアプリが動いている状態があることをご存じですか？ iOS アプリはバックグラウンド状態でのアプリの動作は厳しく制限されていて、ユーザーに見えない状態において、アプリはほとんど動かせません。しかし、いくつかのケースにおいては、バックグラウンド状態でもアプリを動作させることができます。 例えば、ミュージックプレイヤーのようなアプリは、アプリがユーザーから見えていなくとも、音楽を流し続けることができています。これはアプリがバックグラウンド状態になっていても、動作し続けているからこそ実現できています。 弊社で提供している MiiTel Phone Mobile は、電話アプリです。 電話という機能は、iPhone がロックされている状態でも、着信できる必要があります。この機能を実現するために、バックグラウンド状態でも動作するように設計しています。 本稿では、MiiTel Phone Mobile において遭遇したバックグラウンドでのアプリの動作ケースにおいて利用した API を2つご紹介し、それぞれの API における実装上の注意点をまとめています。 バックグラウンドでの着信時の動作 電話アプリの特徴として、電話がかかってきた際に、アプリを使用していなくても、アプリを起動させる必要がある点が挙げられます。ここで言う「アプリを起動する」とは、アプリが前面に立ち上がることだけを指しているのではなく、アプリのプロセスが動き始める、という意味も含みます。電話がかかってきた際は、少なくともサーバーと通信ができる程度にはアプリが動作する必要があります。 このようなケースにおいては、Voice-over-IP (VoIP) push notifications を用います。 VoIP push notifications を使用して、VoIP プッシュ通知を受信することでアプリを起動することができます。 ただし、VoIP プッシュ通知を受信する際は、所定の手順を実行しないと、OSがアプリを強制終了します。 もし所定の手順を実行しないようなアプリであれば、VoIP push notifications でアプリを起動させることができなくなることもあります。 ここでいう所定の手順とは以下の通りです。 pushRegistry() メソッドの中で、 reportNewIncomingCall() をコールすること reportNewIncomingCall() の completion() クロージャ内で pushRegistry() メソッドの completion() をコールすること WWDCでもかなり強い口調で言及されている *1 *2 ので、OSによって強制終了させられないようなコードにしておく必要があります。 pushRegistry() メソッドは、PKPushRegistryDelegate に定義されているデリゲートメソッドで、VoIP プッシュ通知を受信した際にOSからコールされるメソッドです。 reportNewIncomingCall() メソッドは、CXProviderクラスに定義されたメソッドで、画面に着信画面を表示するためのメソッドです。 reportNewIncomingCall() メソッドをコールすること自体に制約はありません。 所定の手順を満たそうとすると、VoIP プッシュ通知を受信した際に必ず着信画面が表示されることになります。 コード例を例示しておくので、参考にしてください。（WWDC のセッションで表示されていたコード *3 を参考にしています） let provider = CXProvider(configuration : providerConfiguration ) func pushRegistry (_ registry : PKPushRegistry , didReceiveIncomingPushWith payload : PKPushPayload , for type : PKPushType , completion : @escaping () -> Void ) { if type != .voIP { return } guard let handle = payload.dictionaryPayload[“handle”] as? String else { return } let callUpdate = CXCallUpdate() callUpdate.remoteHandler = CXHandle(type : .phoneNumber, value : handle ) let callUUID = UUID() 　　 // 1. pushRegistry(_:,didReceiveIncomingPushWith:,for:,completion:)メソッド内で、reportNewIncomingCallをコール provider.reportNewIncomingCall(with : callUUID , update : callUpdate ) { _ in // 2. reportNewIncomingCall(with:update:completion:)のクロージャ内でpushRegistry(_:,didReceiveIncomingPushWith:,for:,completion:)メソッドのcompletionをコール completion() } establishConnection( for : callUUID ) } もし、先ほどの所定の手順を実行しなければ、以下のようなエラー文がコンソールに出力されます。ログに現れている通り、アプリは強制終了させられます。 2022-08-25 14:36:30.016132+0900 AppName[4899:1149881] Apps receving VoIP pushes must post an incoming call (via CallKit or IncomingCallNotifications) in the same run loop as pushRegistry:didReceiveIncomingPushWithPayload:forType:[withCompletionHandler:] without delay. 2022-08-25 14:36:30.016292+0900 AppName[4899:1149881] *** Assertion failure in -[PKPushRegistry _terminateAppIfThereAreUnhandledVoIPPushes], /Library/Caches/com.apple.xbs/Sources/PushKit/PushKit-37/PKPushRegistry.m:343 2022-08-25 14:36:30.017563+0900 AppName[4899:1149881] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Killing app because it never posted an incoming call to the system after receiving a PushKit VoIP push callback.' *** First throw call stack: (0x1b0851654 0x1b0573bcc 0x1b07546ec 0x1b0b9a16c 0x1c4a47ab8 0x107d2b730 0x107d3a488 0x1c4a46a70 0x107d2a338 0x107d2b730 0x107d39710 0x1b07cf6bc 0x1b07ca590 0x1b07c9ba8 0x1ba940344 0x1b49053e4 0x102def5b4 0x1b06518f0) 中でも、2. の手順は、見落としがちなので注意が必要です。 また、2. の手順は pushRegistry() メソッド内でなるべく早く実行することをお勧めします。サーバーとの通信の確立等やらないといけないことも色々あると思いますが、b)の手順を行っておいてからでも遅くはないはずです。 フォアグラウンド状態での動作をバックグラウンド状態でも続けたい時の動作 アプリを使用中に、通信が長くなってしまうと、ユーザーが痺れを切らして、スマホをロックしてしまうケースはよくあることだと思います。こういったユースケースでは、フォアグラウンド状態の時にはじまった通信がバックグラウンド状態になっても継続し、通信が完了するまで動作し続けることが望ましいです。 そのようなケースで使うのが、Background Task Completion です。 Background Task Completion の使い方は、以下の通りです。 UIApplication.beginBackgroundTask をコールして、OSに対して Background Task Completion が開始されたことを通知する タスクが完了した時点で、UIApplication.endbackgroundTask をコールし、Background Task Completion を完了させても良いことをOSに対して通知する 必要であれば、定められた時間内に、タスクが完了できなかった場合、エラー通知などタスクが完了できなかった時の後始末を行うコードを、beginBackgroundTask メソッドの expirationHandler 引数へ定義しておく 使用例を示します。こちらも WWDC のセッションで表示されていたコード *4 を参考にしています func send (_ message : Message ) { let sendOperation = SendOperation(message : message ) var identifier : UIBackgroundTaskIdentifier! // ここからバックグラウンドになっても継続したい処理が開始されることをOSへ通知する identifier = UIApplication.shared.beginBackgroundTask(withName : “sendOperationTask”,expirationHandler : { sendOperation.cancel() postUserNotification(“Message not sent, please resend”) // バックグラウンドでの動作が継続できる時間を過ぎてしまった時に呼ばれる }) sendOperation.completionBlock = { // バックグラウンドでも継続したい処理が完了したことをOSに通知する UIApplication.shared.endBackgroundTask(identifier) } operationQueue.addOperation(sendOperation) } ここで大事なことは、beginBackgroundTask をコールした後、必ず endBackgroundTask をコールすることが必要ということです。 beginBackgroundTask をコールしたにもかかわらず、endBackgroundTask をコールしないとどうなるでしょう？ 答えは簡単で、OS によってアプリが Terminated されます。 ちゃんと endBackgroundTask をコールできていないと、以下のようなメッセージが出るので、気をつけましょう。 [BackgroundTask] Background Task 145 ("sendOperationTask"), was created over 30 seconds ago. In applications running in the background, this creates a risk of termination. Remember to call UIApplication.endBackgroundTask(_:) for your task in a timely manner to avoid this. まとめ 本稿においては、バックグラウンドでの動作ケースにおいて利用したAPIを2つ挙げ、それぞれのAPIにおける実装上の注意点をご紹介させていただきました。本稿では取り上げませんでしたが、バックグラウンド中に少しだけアプリを起動して、情報をリフレッシュしておくと言った使い方のできるAPIも用意されています。興味がある方は「Background Task App Refresh *5 」で調べてみてください。 本稿がご参考になれば幸いです。 最後に RevComm は 9月10日(土)〜12日(月) に開催される iOSDC Japan 2022 *6 にシルバースポンサーとして協賛します。 RevComm では自社プロダクトの通話用アプリ「MiiTel Phone Mobile」を開発しており、モバイルアプリエンジニアを募集しています。 hrmos.co iOSDC トークンはこちら！ #RevCommでMiiTelを一緒に作りませんか *1 : Advances in App Background Execution - WWDC19 - Videos - Apple Developer 9:40から *2 : And new this year, it's very important that you know that you must report incoming calls with CallKit in the didReceiveIncomingPush callback or your app will be terminated. And, if you repeatedly do this, or if you repeatedly fail not to report an incoming call, the system may stop launching your app for VoIP pushes altogether. *3 : Advances in App Background Execution - WWDC19 - Videos - Apple Developer 10:04から *4 : Advances in App Background Execution - WWDC19 - Videos - Apple Developer 7:34から *5 : https://developer.apple.com/documentation/backgroundtasks/bgapprefreshtask *6 : https://iosdc.jp/2022/

RevComm では自社プロダクト「MiiTel」におけるお客様向けの通話用アプリを iOS、Android で開発し「MiiTel Phone Mobile」としてご提供しています。 この度、2022年9月10日(土)〜12日(月)に開催される iOSDC Japan 2022 にシルバースポンサーとして協賛します。 イベント概要 公式サイトより引用 https://iosdc.jp/2022/ iOSDC Japan 2022 はiOS関連技術をコアのテーマとしたソフトウェア技術者のためのカンファレンスです。今年はリアル会場とオンライン配信のハイブリッド開催を予定しています。 日本中、世界中から公募した知的好奇心を刺激するトークの他にも、パンフレットに掲載された技術記事、参加者であれば誰でも作れる即興のトーク・アンカンファレンスなど、初心者から上級者まで楽しめるコンテンツがみなさんを待っています。 日程: 2022年9月10日(土)〜12日(月) 会場: 早稲田大学 理工学部西早稲田キャンパス オンライン（ニコニコ生放送） 主催: iOSDC Japan 2022 実行委員会 参加申し込みはこちら https://www.eventbrite.com/e/iosdc-japan-2022-tickets-347187606477 今回は弊社メンバーの登壇、スポンサートークはありませんがコアスタッフとして1名が参加予定です。 RevComm には #電話営業をAIで可視化するMiiTel（ミーテル） を開発する多くのエンジニアがいます。 今後も技術コミュニティの応援、貢献を継続してまいります。 最後に、下記はコアスタッフとして参加予定の長尾が執筆した iOS アプリ開発に関する記事です。 ぜひ合わせてご覧ください（iOSDC トークンもあります！）。 tech.revcomm.co.jp

RevCommで音声処理の研究開発を担当している加藤集平です。皆さんは 電話の通話相手が屋外やカフェなどの雑音環境下にいるために、相手の声が聞こえづらくて苦労した経験はありませんか？ 本記事では、 物理的な音量はそのままに 雑音環境下の聞こえ（音声了解度）を改善するモデルであるNELE-GANを用いた、通話相手が雑音環境下にいても聞き取りやすい電話の実現に向けた実験を紹介します。 弊社のサービスであるMiiTel（ミーテル）の大量の通話音声を用いてモデルを学習することで、ベースラインよりも大幅に性能を改善することに成功しました 。 ※本記事の内容は、筆者らが日本音響学会2022年春季研究発表会で発表した内容（加藤 & 橋本, 2022）に基づいています。 加藤集平（かとう　しゅうへい） シニアリサーチエンジニア。RevCommには2019年にジョインし、音声処理を中心とした研究開発を担当。ADHDと付き合いつつ業務に取り組む2児の父。 個人ウェブサイト X → 過去記事一覧 要約 背景 本手法で強調した音声の例 強調前 強調後 手法 音声了解度を表す客観指標 音声品質を表す客観指標 実験 音声データおよび雑音データ モデルの学習条件および実験条件 実験結果 モデルの学習に用いる音声データの量および多様性の変化に伴う客観評価値の変化 モデルの学習に用いる雑音の多様性の変化に伴う客観評価値の変化 考察 汎化性能 音声データの量および多様性を変化させたときの音声了解度や音声品質の変化 雑音の多様性を変化させたときの音声了解度や音声品質の変化 結論 発表文献 参考文献 要約 NELE-GANを、 非常に大量のMiiTel通話音声 および様々な雑音の組合せで学習しました（学習データ量はNELE-GANの論文の実験の最大 33倍 ）。 上記のデータを用いて学習した結果、 音声了解度を同程度に保つかさらに向上させた上で、音声品質を大幅に向上させることに成功しました 。 背景 雑音の大きい環境下では、同じ音声でも雑音の小さい環境下にくらべて聞き取りが難しくなります。 音声了解度 (speech intelligibility) は音声により伝えられた単語や文章が相手にどれだけ正確に伝わるかを表す尺度で、雑音環境下ではこの音声了解度が下がることが知られています。 音声了解度が下がる仕組みは未だ解明されていません。一方で、音声の周波数特性などを変化させることで音声了解度が向上することがあることが知られています。実は私たち人間は雑音環境下で無意識のうちにこれを行っており、この現象はロンバード効果 (Lombard effect) (Lombard, 1911) と呼ばれています *1 。 雑音環境下での音声了解度（つまり音声の聞き手が雑音環境下にある場合の音声了解度）を向上させるように音声を変換する（音声強調を行う）ことは、near-end listening enhancement (NELE) と呼ばれています *2 。本記事では2021年に提案されたばかりのNELE-GAN (Li & Yamagishi, 2021) を用いた実験を行います。この手法は、複数の音声了解度の客観評価値を向上させるような変換 *3 を、敵対的学習ネットワーク (generative adversarial network; GAN) によって学習します。 Li & Yamagishi (2021) では、学習データに男女各1名の英語読み上げ音声（各600文、合計1,200文）を用いています。本記事では、モデルを電話音声により適応させると同時に汎化性能 *4 をより高めるため、大量のMiiTelの通話音声を用いてモデルを学習し、その性能をベースライン（Li & Yamagishi (2021) の著者らが公開しているモデルと同等のモデル）と比較します。 本手法で強調した音声の例 強調前 強調後 ランダムな数字を読み上げている音声に、雑音を付加したものです。強調前と強調後でSNR *5 は同じにしてありますが、強調後の音声のほうがより聞き取りやすくなっていることが分かります。 手法 NELE-GANの詳細についてはLi & Yamagishi (2021) に譲りますが、モデルの構造は図1および図2のようになっています。 図1 識別器の構造 図2 生成器の構造 NELE-GANは、クリーンな音声（背景雑音をほとんど含まない音声）および雑音を入力とし、識別器からは客観指標の推定値が出力され、生成器からは音声の周波数特性を変化させるフィルタが生成されます。 識別器の学習においては、 Q 関数（複数の客観評価値を算出する関数）の出力である客観指標の真の値と、識別器が出力する客観指標の推定値の平均二乗誤差損失 (mean squared error loss; MSE loss) を最小化するように学習が行われます。一方、生成器の学習においては、客観指標の取りうる最大値と、識別器が出力する客観指標の推定値のMSE lossを最小化するように学習が行われます（このとき、識別器の重みは固定します）。これらを交互に繰り返すことで、客観評価値を最大化するようなフィルタを学習することができます。 Q 関数では、音声了解度を表す3つの客観指標に加えて、音声品質を担保するための2つの客観指標が用いられます。 音声了解度を表す客観指標 Speech intelligibility in bits (SIIB) (Kuyk et al., 2018) Hearing-aid speech perception index (HASPI) (Kates & Arehart, 2014) Extended short-time objective intelligibility (ESTOI) (Jensen & Taal, 2016) 音声品質を表す客観指標 Perceptual evaluation of speech quality (PESQ) (Rix et al., 2001) Virtual speech quality objective listener (ViSQOL) (Hines et al., 2015) 実験 音声データおよび雑音データ 音声データには、 弊社の業務において MiiTelを通じて行われた通話音声から、 弊社から発信した通話を着信した側 のチャンネルの音声区間のみを抜き出して使用しました。着信側の話者がそれほど重複しているとは考えづらいので、話者数は通話件数とほぼ等しいと見なせます。なお、音声は厳密な意味でのクリーンな音声ではありませんが、この実験のためにできる限りクリーンな音声を選別しました。 音声データについては、モデルの学習・検証のために、 S : 音声区間数2,269（通話件数466件、4.2時間）、 M : 音声区間数9,004（通話件数2,089件、16.7時間）、 L : 音声区間数34,962（通話件数7,322件、66.7時間）の3つのデータセットを用意しました。ただし、音声区間数のより多いデータセットは、より少ないデータセットを包含しています。モデルの評価のためには、学習・検証のために使用していない音声区間数116（通話件数18件、0.56時間）のデータセットを用意しました。 雑音データには、Li & Yamagishi (2021) と同じく、The Microsoft Scalable Noisy Speech Dataset (MS-SNSD) (Reddy, 2019) を使用しました。モデルの学習・検証のために、​​ a : 音声系の雑音3種類 (airport, babble, neighbor speaking)、 b : セット a （音声系の雑音3種類）＋雑踏系の雑音2種類 (traffic, station) の2つのセットを用意し，それぞれ SNR = −10 dB, −5 dB, 0 dB となるように雑音を音声に重畳しました。モデルの評価のためには、 closed : 学習・検証セット a と同一種類の雑音（音声系の雑音3種類、ただし異なるサンプルです）、 acoust : 学習・検証セット a に含まれるものとは異なる音声系の雑音2種類 (bus, cafe)、 crowd : 学習・検証セット b に含まれるものとは異なる雑踏系の雑音2種類 (field, metro)、 office : オフィス系の雑音3種類 (air conditioner, copy machine, typing) の4つのデータセットを用意し、それぞれ SNR = −12 dB, −9 dB, −6 dB, −3 dB, 0 dB, +3 dB となるように雑音を音声に重畳しました。 結果として、モデルの学習・検証には S a – L b の6つのデータセット、評価には4つのデータセットを用いました（表1、2）。 S a がベースライン（Li & Yamagishi (2021) の著者らが公開しているモデル）に最も近いモデルになります。なお、学習・検証に用いた S a – L b の6つのデータセットについては、無作為に選んだ320サンプルを検証に、残りのサンプルを学習に用いました *6 。 表1 学習・検証データセットの詳細 データセット 音声データセット 雑音データセット SNR サンプル数 時間長 [h] Li & Yamagishi (2021) 1,320サンプル（時間長不明） （4種類） （3種類） 15,840 （不明） S a S （4.2時間） a （3種類） -10 dB, -5 dB, 0 dB（3種類） 20,421 37.5 S b b （5種類） 34,035 62.5 M a M （16.7時間） a 81,036 150 M b b 135,060 250 L a L （66.7時間） a 314,658 600 L b b 524,430 1,000 表2 評価セットの詳細 データセット 音声データセット 雑音データセット SNR サンプル数 時間長 [h] T closed （0.56時間） closed （3種類） -12 dB, -9 dB, -6 dB, -3 dB, 0 dB, +3 dB（6種類） 2,088 10 T acoust acoust （2種類） 1,392 6.7 T crowd crowd （2種類） 1,392 6.7 T office office （3種類） 2,088 10 モデルの学習条件および実験条件 音声および雑音の標本化周波数は8 kHz *7 とし、ミニバッチの大きさは32としました。さらに、学習の安定化と高速化のために、1エポック目はSIIB, ESTOI, PESQの3つの指標のみを用いて学習を行い、2エポック目以降は5つ全ての指標を用いて学習を行う方法を取りました。そして、3エポック目以降の学習では、当該エポックの学習を終えた時点での検証セットに対する客観評価値が、前エポック終了時のものよりも小さくなるか上昇率が1 %以下になった時点で学習を打ち切り、客観評価値の平均が最も大きなモデルを評価に使用しました。 モデルの評価においては、評価セットの各サンプルに対する客観評価値を平均したものを、当該セットに対する客観評価値としました。 実験結果 実験結果を図3に示します。 どの評価セット ( T closed , T acoust , T crowd , T office ) においても、強調後の音声 ( S a – L b ) は強調前の音声 (unmodified) に対して、音声了解度を表す客観指標 (SIIB, HASPI, ESTOI) の値は上昇傾向にあり，音声品質を表す客観指標 (PESQ, ViSQOL) の値は低下していることが分かります。 図3 各条件および評価セットの組合せに対する客観評価値 評価セット間の客観評価値の相関を見てみます（表3–5）。音声了解度を表す客観指標 (SIIB, HASPI, ESTOI)、音声品質を表す客観指標 (PESQ, ViSQOL) ごとに見れば、評価セット間の客観評価値の相関係数はおおむね0.9以上と、非常に強い相関があることが分かります。 表3 全ての客観評価値についての評価セット間の相関係数 T acoust T crowd T office T closed 0.569 0.511 0.946 T acoust - 0.994 0.769 T crowd - - 0.720 表4 音声了解度に関する客観評価値についての評価セット間の相関係数 T acoust T crowd T office T closed 0.929 0.891 0.969 T acoust - 0.994 0.977 T crowd - - 0.959 表5 音声品質に関する客観評価値についての評価セット間の相関係数 T acoust T crowd T office T closed 0.931 0.932 0.968 T acoust - 0.997 0.978 T crowd - - 0.970 モデルの学習に用いる音声データの量および多様性の変化に伴う客観評価値の変化 モデルの学習に用いる音声データの量および多様性を変化させると、客観評価値はどのように変化するのでしょうか？これを観察するために、各評価セットに対する結果を ( S a , M a , L a ) または ( S b , M b , L b ) の組合せで比較しました（図4、図5）。音声了解度を表す客観指標のうちSIIBおよびHASPIについては、 S a / S b から M a / M b へと音声データの量および多様性を大きくすると値が若干低下しましたが、 L a / L b へとさらに大きくすると値は同程度まで回復しました。ESTOIについては、音声データの量および多様性を大きくするにしたがって、単調に値が上昇しました。一方、音声品質を表す客観指標 (PESQ, ViSQOL) については、 S a / S b から M a / M b へと音声データの量および多様性を大きくすると値が上昇し、 L a / L b へとさらに大きくすると値は若干低下するか同程度となりました。 図4 各条件における ( S a , M a , L a ) の組合せに対する客観評価値 図5 各条件における ( S b , M b , L b ) の組合せに対する客観評価値 モデルの学習に用いる雑音の多様性の変化に伴う客観評価値の変化 モデルの学習に用いる雑音の多様性を変化させたときの客観評価値の変化についてはどうでしょうか？これを観察するために、各評価セットに対する結果を ( S a , S b )，( M a , M b )、または ( L a , L b ) の組合せで比較しました（図6–8）。音声了解度を表す客観指標 (SIIB, HASPI, ESTOI) については、 S a / M a から S b / M b へと雑音をより多様にすると若干値が低下しましたが、 L a から L b への変化については、値が同程度か若干の上昇にとどまりました。音声品質を表す客観指標 (PESQ, ViSQOL) については、 S a から S b へと雑音をより多様にすると値が大きく上昇しましたが、 M a / L a から M b / L b へと変化させた場合は、評価セットや客観指標によるものの、値はおおむね同程度にとどまりました。 図6 各条件における ( S a , S b ) の組合せに対する客観評価値 図7 各条件における ( M a , M b ) の組合せに対する客観評価値 図8 各条件における ( L a , L b ) の組合せに対する客観評価値 考察 汎化性能 評価セット間の客観評価値には、非常に強い相関が見られました。これは、音声データの量および多様性、雑音の多様性の変化によらず、異なる系統の雑音に対するモデルの性能変化の傾向が類似していることを示しています。雑音種類オープンの評価セット ( T acoust , T crowd , T office ) に対する客観評価値が雑音種類クローズド ( T closed ) の評価セットに対する客観評価値を上回ったことをあわせて考えると、 NELE-GANが雑音の種類に対して高い汎化性能を持っている ことが示唆されます。 音声データの量および多様性を変化させたときの音声了解度や音声品質の変化 音声データの量および多様性を変化させたときの音声了解度や音声品質の変化については、興味深い傾向が見られました。すなわち、比較的小規模の音声データを用いて学習した場合 ( S a / S b ) でも音声了解度は十分に向上しましたが、音声品質は大きく劣化してしまいました。そこからデータの規模を大きくすると、一旦は音声了解度が若干低下する一方で、音声品質はかなり回復しました ( M a / M b )。さらにデータの規模を大きくすると、音声品質をおおむね保ちつつ、音声了解度が回復またはさらに向上することが分かりました ( L a / L b )。このことから、 非常に大量かつ多様な音声データを用いてNELE-GANを学習することで、比較的少量のデータを用いて学習する場合よりも、モデルの性能を向上させることができる と言えるでしょう。 雑音の多様性を変化させたときの音声了解度や音声品質の変化 雑音の多様性を変化させたときの音声了解度や音声品質の変化は、音声データが比較的小規模の場合は顕著に差がありましたが、より大規模であるほど差は少なくなりました。この理由については、本実験の結果からだけでは推測が難しく、さらなる検討を必要とします。 結論 本記事では、NELE-GANをより大量かつ多様な音声データを用いて学習したときのモデル性能の変化を検証しました。同時に、音声に重畳する雑音についても、その多様性を変化させたときのモデル性能の変化を検証しました。結果として、 非常に大量かつ多様な音声データを用いることで、比較的少量のデータを用いる場合とくらべて、音声了解度を同程度に保つかさらに向上させた上で、音声品質を大幅に向上させられる ことが明らかになりました。 さらに大規模な音声データを用いた場合のモデル性能がどうなるのか気になりますが、それは今後の課題とします。 発表文献 加藤集平, & 橋本泰一 (2022). NELE-GANの学習に用いる音声データ量および多様性の影響についての調査. 日本音響学会2022年春季研究発表会講演論文集 , 1025–1028. 参考文献 Glasberg, B. R., & Moore, B. C. J. (1990). Derivation of auditory filter shapes from notched-noise data. Hearing Research , 47(1–2), 103–138. https://doi.org/10.1016/0378-5955(90)90170-T Hines, A., Skoglund, J., Kokaram, A. C., & Harte, N. (2015). ViSQOL: An Objective Speech Quality Model. EURASIP Journal on Audio, Speech, and Music Processing , 2015(13), 1–18. Jensen, J., & Taal, C. H. (2016). An Algorithm for Predicting the Intelligibility of Speech Masked by Modulated Noise Maskers. IEEE/ACM Transactions on Audio, Speech, and Language Processing , 24(11), 2009–2022. https://doi.org/10.1109/TASLP.2016.2585878 Kates, J. M., & Arehart, K. H. (2014). The Hearing-Aid Speech Perception Index (HASPI). Speech Communication , 65, 75–93. https://doi.org/10.1016/j.specom.2014.06.002 Kuyk, S., Kleijin, W. B., & Hendriks, R. C. (2018). An Instrumental Intelligibility Metric Based on Information Theory. IEEE Signal Processing Letters , 25(1), 115–119. https://doi.org/10.1109/LSP.2017.2774250 Li, H., & Yamagishi, J. (2021). Multi-Metric Optimization using Generative Adversarial Networks for Near-End Speech Intelligibility Enhancement. IEEE/ACM Transactions on Audio, Speech, and Language Processing , 29, 3000–3011. https://doi.org/10.1109/TASLP.2021.3111566 Lombard, É. (1911). Le signe de l'élévation de la voix. Annales des Maladies de L'Oreille et du Larynx , XXXVII(2), 101–109. Reddy, C. K. A., Beyrami, E., Pool, J., Cutler, R., Srinivasan, S., & Gehrke, J. (2019). A Scalable Noisy Speech Dataset and Online Subjective Test Framework. Proc. INTERSPEECH , 1816–1820. https://doi.org/10.21437/Interspeech.2019-3087 Rix, A. W., Beerends, J. G., Hollier, M. P., & Hekstra, A. P. (2001). Perceptual Evaluation of Speech Quality (PESQ) — A New Method for Speech Quality Assessment of Telephone Networks and Codecs. Proc. IEEE International Conference on Acoustic, Speech, and Signal Processing (ICASSP) , II, 749–752. https://doi.org/10.1109/ICASSP.2001.941023 芝慎太朗, 橘亮輔, & 岡ノ谷一夫 (2015). ジュウシマツの歌発声におけるロンバード効果と基本周波数の変化. 情報処理学会研究報告 , 2015-MUS-107(37), 1–3. *1 : もっと言えば、人間以外の動物でもロンバード効果が観察されることがあることが知られています（芝慎太朗ほか, 2015）。 *2 : 音声強調という言葉は、雑音や残響が混ざった音声信号においてそれらを抑制することを指すことが多いです。 *3 : 具体的には、あらかじめビン数を固定したequivalent rectangular bands (ERB) (Glasberg & Moore, 1990) 尺度に基づくフィルタバンクの各ビンに対する重み付けを行います。 *4 : モデルが特定の場面に限らず広い場面で高い性能を発揮すること。ここでは、どのような声あるいはしゃべり方の人でも聞き取りやすい声に変換できることを指しています。 *5 : Signal to noise ratio（S/N比、信号対雑音比）。信号（ここでは音声信号）のパワーの雑音のパワーに対する比で、値が小さいほど雑音が大きいことになります。 *6 : 音声データの学習・検証セット S に雑音データの学習・検証 セット（ a または b ）を重畳したものを、雑音の種類、音声サンプル（ランダムな識別子を付与）の順にソートして並べ、前半の320サンプルを S / M / L 共通の検証セットとしました。 *7 : Li & Yamagishi (2021) では16 kHzでしたが、本実験に用いた音声は電話の通話音声であるため、標本化周波数は電話の音声信号を符号化する際に用いられる8 kHzに制限されます。

こんにちは。はじめまして。PBX チーム所属の山崎です。 はじめに さてみなさま、夏休みはいかがお過ごしでしょうか。 夏休みで子どもがずっと家にいると、WEB 会議に乱入してくる可能性が高くなります *1 。 「おとーさーん！おとーーさーーん！あれ〜いないの〜〜？」「ちょっと静かにしててー💢」みたいなご経験、ないでしょうか。 もちろん乱入してきたからといってどうということはなく、同僚のそんな様子はむしろ和むのでウェルカムですが、自分がその立場になるとやはり気まずいものがあります。 そんな折、同僚が ON AIR ライト を買っていて、良さそうだったので自分も買ってみました。 しかしながら、日に数回とはいえ都度付け消しするのは面倒です。そこで、自動で on/off するようにしてみました。 前書きが長くなりましたが、今回の記事は MacBook のヘッドセットの接続/切断イベントを契機に、 ライトを自動で on/off して、 家族にミーティングの開始/終了を伝える というものを作ってみた、というご紹介になります。 お買い物 今回、製作するにあたって以下を使用しました。 スマートプラグ TP-Link Tapo P105 を使用しましたが、API が公開されていません もしこれから購入するのであれば、API ドキュメントが充実している SwitchBot プラグミニ が良さそうに思います ON AIR ライト 常時スイッチオンの状態にできる (スマートプラグで操作できる) ものであれば、なんでも OK です ヘッドセット MacBook (Monterey) 無線LAN 今回はスマートプラグと ON AIR ライトの組み合わせで製作しましたが、macOS からコマンドで操作できるものであればなんでも構いません。 ヘッドセット接続・切断イベントの検知 自動化するにあたって悩ましいのは、何をトリガーにするかという点です。 私はミーティング時のみ Apple EarPods with 3.5 mm Headphone Plug を MacBook に挿しているので、これをトリガーにすることにしました。 実はここが一番苦労したところでして、Apple 社のドキュメントのどこを見ても、オーディオデバイスの接続・切断の検知方法が書いてありません (調べきれていないだけかも) 。 ブラウザなら MediaDevices の devicechange イベント を拾えばサクッと終わりますが、これだけのために１プロセス常駐させるのももったいない話です（貧乏性なんです）。 また、 system_profiler コマンドで接続中のデバイス一覧がとれるので、これを例えば 「5 分に 1 回実行して状態を検出」でもいいのですが、これもなんだかもったいないですし、最大5分遅延してしまうので、嬉しくありません。 それっぽいアプリもなく煩悶としていたところ、システム環境設定の「サウンド」の項目が変化することに気付きました。 システム環境設定は /Library/Preferences/ 以下に設定を保存するので、それっぽいファイルを漁ってみます。 すると、抜き差しのタイミングで /Library/Preferences/Audio/com.apple.audio.SystemSettings.plist が更新されることがわかりました。そして、ファイルの変更イベントは launchd で検出できます。これで勝ち筋が見えました。 やってみよう ファイルを2つ、作成します。実際のファイル名は適宜環境に合わせて読み替えてください。 ~/Library/LaunchAgents/com.example.on-air.plist /path/to/on-air.sh まず ~/Library/LaunchAgents/com.example.on-air.plist を作成します: <? xml version = "1.0" encoding = "UTF-8" ?> <! DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd" > <plist version = "1.0" > <dict> <key> Label </key> <string> com.example.on-air </string> <key> WatchPaths </key> <array> <string> /Library/Preferences/Audio/com.apple.audio.SystemSettings.plist </string> </array> <key> ProgramArguments </key> <array> <string> /path/to/on-air.sh </string> </array> </dict> </plist> ここでは、 WatchPaths で指定したファイルに変化があったら、 ProgramArguments を実行する という処理をしています。 次に、 on-air.sh を実装していきます。このファイルには実行権限の付与( chmod +x on-air.sh )をしておきます。 #!/bin/sh # "system_profiler -json SPAudioDataType" コマンドで表示される、お手元のデバイスの名前にあわせてください AUDIO_DEVICE_NAME = ' 外部マイク ' JQ =/opt/homebrew/bin/jq connected () { osascript -e ' display notification "ON AIR: connected" ' } disconnected () { osascript -e ' display notification "ON AIR: disconnected" ' } # 切断中 or 接続中を判断する system_profiler -json SPAudioDataType | \ $JQ -e " .SPAudioDataType[]._items[] | select(._name == \" $AUDIO_DEVICE_NAME \" ) " > /dev/null if [ $? == 0 ]; then connected else disconnected fi launchd からは接続・切断を見ずに、単に設定ファイルの更新イベントだけを拾って on-air.sh を呼びます。 そこで、 on-air.sh の中で接続 or 切断を判断しています。 2つのファイルを作成できたら、以下のコマンドで launchd に設定を読み込みます: $ launchctl load ~/Library/LaunchAgents/com.example.on-air.plist この状態でヘッドセットを抜き差しすると、通知センターに connected/disconnected が出力されます(数秒のタイムラグがあります)。 あとは connected()/disconnected() の部分を実装して、ライトの on/off を制御できるようになったら完成です。 ライトのon/off 実際に on/off する処理を書いていきます。 今回使用したスマートプラグ Tapo P105 は API 仕様が公開されていません。 適当にググっていくつか試したところ、 fishbigger/TapoP100 がいい感じに動いたので、ありがたくこれを利用することにします。 *2 3つ目のファイル、 tapo-p105.py を作ります: #!/usr/bin/env python3 import sys from PyP100 import PyP100 ipaddress, email, password, onoff = sys.argv[ 1 :] p105 = PyP100.P100(ipaddress, email, password) p105.handshake() p105.login() if onoff == "on" : p105.turnOn() elif onoff == "off" : p105.turnOff() この Python スクリプトを使って、先ほどの connected()/disconnected() の部分を以下のように書き換えます。 SCRIPT_DIR =/path/to/tapo-p105 PYTHON = " $SCRIPT_DIR /venv/bin/python3 " IP = 192 . 168 . 0 . 2 # スマートプラグの IP アドレス P105_EMAIL = " your-account@example.com " P105_PASSWD = " your password " connected () { $PYTHON " $SCRIPT_DIR /tapo-p105.py " " $IP " " $P105_EMAIL " " $P105_PASSWD " on } disconnected () { $PYTHON " $SCRIPT_DIR /tapo-p105.py " " $IP " " $P105_EMAIL " " $P105_PASSWD " off } 最後に、TapoP100 ライブラリをインストールします: cd /path/to/tapo-p105 python3 -m venv venv source venv/bin/activate pip3 install PyP100 これで完成です。 ヘッドセットを接続してライトを点灯したところ むすびに 実は春休みに作って 4 ヶ月ほど運用してきました。実際に使ってみると、いい感じに QoL が上がりました。 WEB 会議中に割り込まれることが少なくなって快適 (家族からは) 話しかけて大丈夫なタイミングがわかるようになって、ストレス軽減と好評 子どもから、お父さんすごーい！とピュアな尊敬を得られる 一方、抜くのを忘れてて夕ご飯に呼ばれず、一人寂しく食べる羽目になったこともありました。 技術の過信は良くないですね（大げさ）。 *1 : RevComm ではフルリモート制度を導入していまして、普段のミーティングは基本的にオンラインで行われます *2 : Tapo P105 はファームウェアバージョンによって API の仕様が異なるらしく、試した他のライブラリは動作しませんでした。

はじめに：アップデートできていますか？ 作ったきりで一度もライブラリをアップデートしていない、そんなプロダクトも多いのではないでしょうか。新規ライブラリの利用が古いライブラリへの依存により実現しないことなど、損失が発生するケースは多々あります。脆弱性対策のアップデートをして、新たな不具合を発生させていては本末転倒です。それらを理解していても、必要に迫られるまでアップデートは後回しにされることが多いと思います。しかし、アップデートが必要になった時には大規模アップデートとなり、エラーと隣り合わせの状態で、祈りながらリリースされることも多いのではないでしょうか？ 本記事では Dependabot、GitHub Actions、Sentry を利用してアップデートを半自動化し、実現可能な工数で祈らず継続的にアップデートする手法を提案します。 本記事のまとめ 以下の 3 ステップでの継続的なアップデートを提案します。 情報を集める：Dependabot を設定する アップデートを検証する：ビルド差分を比較する 監視する：Sentry でエラーを検知する 情報を集める：Dependabot を設定する まず、アップデート情報を定期的に取得する必要があります。これに関しては優れた解決策がすでに用意されています。筆者のチームでは GitHub 公式の Dependabot を利用することにしました。Dependabot は更新を通知してくれるだけではなく、リリースノートが記載されたアップデート Pull Request の作成まで行ってくれます。 Bump TypeScript 公式 https://docs.github.com/ja/code-security/dependabot/dependabot-version-updates/about-dependabot-version-updates アップデートを検証する：ビルド差分を比較する Dependabot が Pull Request を作成してくれるとしても、全ての Pull Request のリリースノートを読み影響範囲を特定しテストを行うとすると、検証にかなり多くの工数を割くことになります。 そこで、コードベースでアップデートを検証する仕組みを整え、一部のアップデートについては自動検証を可能にしました。 フロントエンドではユーザーに配信するファイル（ビルド成果物）が全く同じであれば、リグレッションが発生しないことの証明になります。さらに、多くのビルド環境では Tree shaking (Dead Code Elimination) の仕組みがあり、ライブラリの利用していない部分の変更に関しては、ビルド成果物には反映されません。つまり、実際には多くのライブラリアップデートはビルド成果物をコードベースで比較し差分がないことをもって検証を完了できるのです。 *1 筆者のチームでは Dependabot の作成した Pull Request に対して、アップデート前後のビルド成果物を比較する CI を設定し、それが通過していればそのままリリースに進める運用としました。実際にチームのプロダクトでは 120 件あったマイナーアップデートの内、73 件は差分が生じておらず、人力での検証をスキップしてリリースできました。 実際には GitHub Actions で以下のように実装しました。 *2 name : Dependabot diff on : push : branches : - 'dependabot/npm_and_yarn/**' jobs : diff : timeout-minutes : 10 if : github.actor == 'dependabot[bot]' runs-on : ubuntu-latest steps : - uses : actions/setup-node@v3 with : node-version : '16' # アップデート後のビルド - uses : actions/checkout@v3 with : ref : ${{ github.ref }} - name : Install run : | npm ci - name : Build run : | npm run build mv build /tmp/head # アップデート前のビルド - uses : actions/checkout@v3 with : ref : main - name : Install run : | npm ci - name : Build run : | npm run build mv build /tmp/base # 比較 - name : Diff run : | diff -r /tmp/head /tmp/base 監視する：Sentry でエラーを検知する 実際に運用してきた中で、リリースノートを読み影響範囲を調査し修正を加えたとしても、エラーがないことの確証を得られないケースは多くありました。また、Tree shaking 可能な形で配信されておらずアップデートの度に差分が生じてしまうライブラリも多いです。そこで、そのようなアップデートに関しては、社内環境にリリースして1週間程度監視した後、新規エラーが検出されていないことを確認できれば社外向けにリリース可とする運用にしました。 エラー検知には Sentry を使用しました。設定すればアプリケーション内で発生したエラーを検知して送信、集計、レポートを作成することまで自動化することができます。 参考： docs.sentry.io techblog.cartaholdings.co.jp おわりに 以上、祈らないアップデートを提案しました。筆者のチームでは、実際にこれらの仕組みを導入してから半年以上継続的にアップデートが行われています。一部メジャーバージョンの更新を除き、ほとんどのライブラリが最新になっています。 継続的なアップデートを！ *1 : Dev dependencies も成果物に影響を与えないことが多いです。アップデートで知らないうちに開発環境を壊してしまうと困るので、しっかり Formatter や Linter も CI で実行するようにしています。 *2 : pull_request をトリガーにした場合ビルド対象を base head の変数で参照可能です。しかし、全ての Pull Request に反応して Action が起動されスキップしたログが残るのが気になったので、トリガーはブランチ名フィルタを指定することにしました。

こんにちは、RevComm にて主に MiiTel の音声解析機能に関する研究開発を担当している石塚です。 石塚賢吉（いしづか　けんきち） プリンシパルリサーチエンジニア。筑波大学大学院博士後期課程卒業。博士（工学）。日本HP株式会社にて通信事業者向けのシステム開発、株式会社ドワンゴで全文検索システムの開発などに従事。2019年12月、株式会社RevComm入社。音声認識、音声感情認識、全文検索システムの研究開発を行なっている。 → 過去記事一覧 RevComm では、電話営業やお客様対応を可視化する音声解析 AI 搭載型のクラウド IP 電話 MiiTel (ミーテル) を提供しています。 2022年2月9日、その MiiTel に音声感情認識機能を追加しました。 prtimes.jp これによって話し手のポジティブ、ネガティブな感情が可視化され、会話の当事者以外でも感謝を伝える様子やクレームなどに気づくことができます。 弊社プロダクト「MiiTel」画面 (抜粋) ビジネスの電話応対について、話者の発話音声の感情の側面からの解析を可能とするため、RevCommでは音声感情認識の研究を重ねてきました。成果の一部は国立大学法人筑波大学との共同研究による音声感情認識に関する論文として、2021年8月に音声処理系トップカンファレンス「INTERSPEECH 2021」にて発表しています。 今回は、INTERSPEECH 2021で発表した論文 「Speech Emotion Recognition based on Attention Weight Correction Using Word-level Confidence Measure」 について解説します。 1. はじめに 2. 提案手法 2.1 提案アルゴリズムのベースとなる音声感情認識器の構造 2.2 単語信頼度とは 3. 評価実験 4. まとめ 5. 参考文献 1. はじめに 　深層学習技術が発展し、時系列データを扱うリカレントニューラルネットワークや Self-Attention による重み付けの技術が音声からの特徴抽出に有効に機能し、音声感情認識の性能が向上してきました [Mirsamadi, 2017]。また、音声認識により得られたテキストと音響特徴量の両方を利用して、高精度な音声感情認識を達成しようとする研究もあります。 　しかし、音声認識による文字起こしの精度はまだ十分とは言えません。特に、文法が崩れがちな感情を含む音声を音声認識で正確に文字起こしするのは困難です。そこで、音声感情認識モデルと事前学習された音声認識モデルを End-to-end で結合し、感情音声データセットを用いたマルチタスク学習でファインチューニングすることで、認識精度を向上する方法などが提案されています [Feng, 2020]。しかしこの方法では、感情音声データセットに対して音声認識と音声感情認識を行うモデル全体をファインチューニングするために計算コストがかかります。本研究では、音声認識により得られるテキストの信頼度の情報を用いて、音声認識の誤りの影響を軽減しながら音声感情認識を行うための手法を提案します。 2. 提案手法 2.1 提案アルゴリズムのベースとなる音声感情認識器の構造 　図1に提案アルゴリズムのベースとなる、テキスト情報と音響情報を用いた音声感情認識器の構造を示します [Mirsamadi, 2017] 。本音声感情認識器は、音響特徴抽出器、テキスト特徴抽出器、そして2つの抽出器の出力を組み合わせて最終的な分類を行う感情分類器の3つから構成されています。本アルゴリズムでは、まず発話音声から音響特徴量とテキスト特徴量を抽出します。次に、音響特徴量を BiLSTM に入力し、Self-Attention を用いて重み付けを行い、中間表現を得ます。テキスト特徴量は、Word-Embedding によりベクトル化し、 音響特徴量と同様に処理します。最後に、中間表現を連結し、完全連結ネットワークで分類することで、最終的な感情クラスが出力として得られます。 　本研究では、この音声感情認識器の構成をベースとし、Self-Attentionの重みを単語レベルの単語信頼度で補正することで、音声認識時に誤認識された単語に Self-Attention で注目する事を防ぎ、音声感情認識精度の向上を目指します。 図1. ベースとなる音声感情認識器の構成 2.2 単語信頼度とは 　単語信頼度とは、音声認識結果の単語ごとの信頼度を0.0 - 1.0の値で表現したものです。表1に、正解文の単語と音声認識結果の単語と単語信頼度の例を示しています。表1の赤で塗りつぶされた箇所は誤認識された単語で、基本的には、誤認識された単語の信頼度は低くなる傾向があります。ただし、黄色で塗りつぶされた箇所のように、正しく認識された単語の場合でも信頼度が低くなることがあります。 表1. 単語信頼度の例 正解文 I NEED YOUR BIRTH CERTIFICATE 音声認識結果 (単語信頼度) I (1.0) READ (0.5) YOUR (0.3) BURST (0.4) CERTIFICATE (1.0) 　音声感情認識のテキスト特徴量として単語信頼度を用い、誤って認識された単語の影響を抑制したり、正しく認識された単語の影響を強調したりすることを考えます。本論文では、テキスト特徴抽出器での単語信頼度の利用方法として、図2のような3つの構成で単語信頼度の有効性を比較します。 Proposed (a) Early fusion method: 単語信頼度をテキストの特徴量と組み合わせて、テキスト特徴量の一部として使用する構成 Proposed (b) Late fusion method: 単語信頼度を中間特徴量と組み合わせて使用する構成 Proposed (c) Confidence Measure (CM) as weighting correcting: 単語信頼度をアテンション重みと組み合わせて使用する構成です。こちらは、前の二つの構成に対して、単語信頼度のテキストの特徴に対する依存が小さくなることが期待されます 図2. テキスト特徴抽出器での単語信頼度の利用方法 　次に、Proposed (c) の構成において、単語信頼度がアテンションの重みに対してどのように作用するかについて図3を例に説明します。図3において、横軸は時間軸となっており、音声認識結果のテキストが下部に示されています。上から一番目の折れ線グラフは、補正前の単語に対するアテンションの重みを表現したものです。二番目は、単語信頼度であり、黄色で塗りつぶされた部分に音声認識誤りの単語列があったとして、その部分の単語信頼度が低くなっています。三番目は、補正後のアテンションの重みです。このとき、音声認識の誤り部分のアテンションの重みが、単語信頼度で補正され、小さくなっていることがわかります。逆に、単語信頼度の大きな部分のアテンションの重みは、大きくなります。 図3. 単語信頼度のアテンションの重みに対する作用 3. 評価実験 　本研究では、感情認識のベンチマークデータセットの一つである Interactive Emotional Dyadic Motion Capture (IEMOCAP) データセット[Busso, 2008] を利用して、提案手法の有効性を評価します。IEMOCAP データセットでは、合計10人の話者(男性5人、女性5人)による各発言に対し、人手での書き起こしテキストと7つの感情（幸せ、悲しい、中立、怒り、興奮、欲求不満、その他）ラベルのどれかが1つ付与されています。評価実験では 5-fold cross validation を行い、話者の独立性を確保しながら音声感情認識の精度を評価します。 表2. 手法の比較 Method　　　　　　　　　　　　 UA　　　　 WA　　　　 Speech 61.1 64.3 Text (Transcript) 75.5 75.6 Text (ASR) 71.8 71.9 Speech + Text (Transcript) 78.6 78.4 Speech + Text (ASR) 73.9 74.2 Our Proposed Method Proposed (a) 74.3 74.4 Proposed (b) 74.9 75.4 Proposed (c) 75.9 76.1 　使用する特徴量の組み合わせを変えた音声感情認識の実験結果を表 2 にまとめています。IEMOCAP データに対する音声認識テキストの Word Error Rate（WER）は43.5%でした。音声感情認識の評価指標として、先行研究に従い、Unweighted Accuracy（UA）および Weighted Accuracy（WA）を採用していますが、両評価指標は類似した傾向を持つため、主にWAを用いて結果を分析します。 　音声のみを用いたとき [Speech] の WA 値は64.3%であり、人手での書き起こしのみを用いたとき [Text(Transcript)] の WA 値は75.6%となりました。音声と人手での書き起こしテキストを組み合わせたとき [Speech+Text(Transcript)] の WA は78.4%であり、音声のみ [Speech] よりも14.1%、人手で書き起こしたテキストのみ [Text(Transcript)] よりも2.8%上回りました。一方、人手で書き起こしたテキストを使う代わりに音声認識結果を用いると [Text(ASR)]、WA が3.7%低下することがわかりました。 　音声と音声認識結果の組み合わせ [Speech+Text(ASR)] では WA が74.2%となり、4.2%の性能劣化となりました。 　単語信頼度をテキスト特徴量に組み込む手法として提案した Proposed (a): Early fusion、Proposed (b): Late fusion、Proposed (c): CM as weighting correcting については、それぞれ74.4%、75.4%、76.1%のWAが得られました。提案した手法のうち Proposed (c): CM as weighting correcting は、[Speech+Text(ASR)] からの性能向上が最も大きく、音声と人手での書き起こしテキストを組み合わせた手法の結果に最も近い性能を示しています。これは、単語信頼度でアテンションの重みを調整し、誤っている可能性の高い音声認識結果の単語の重要度を下げることで、性能向上が実現できることを示唆しています。 表3. 先行研究の実験結果と本研究の実験結果の比較 　IEMOCAP データセットを用いた先行研究の実験結果と本研究の提案手法の実験結果の比較を表3にまとめています。提案手法は、最も高い UA と WA を達成しました。 4. まとめ 　本研究では、音声認識により得られるテキスト情報と単語レベルの信頼度を利用する音声感情認識手法を提案しました。そして、感情音声データセット IEMOCAP を用いて、単語信頼度により音声認識テキストの音声認識誤りの影響を軽減する手法について検討しました。提案した3つの手法のうち、単語信頼度をSelf-Attentionの重みの補正として用いる方法が最も良い性能を得ることができました。そして、IEMOCAP データセットを用いた先行研究の多くと比較して、提案手法がより良い性能を示すことがわかりました。 　「Speech Emotion Recognition based on Attention Weight Correction Using Word-level Confidence Measure」の本文はインターネット上で無料公開されているので、詳しくは こちら をご覧ください。また、RevComm では ICASSP（International Conference on Acoustics, Speech, & Signal Processing）2022でも京都大学との音声感情認識についての共同研究の成果を発表しておりますので、興味があればぜひ こちら もご覧ください。こちらの研究では、マルチタスク学習を用いて、RevCommが保有するビジネス電話応対の自然な感情音声データセットと、演技された感情音声のデータセットを組み合わせて、より効果的に音声感情認識モデルを学習する手法について提案しています。 　今後も、共同研究で得られた成果をもとに音声感情認識モデルを強化し、弊社プロダクトに組み込むことで、お客様の感情の可視化や、お客様の不満を示す対話の抽出と解析などへの応用に取り組んでいきます。RevComm は AI 技術領域にイノベーションをもたらし、コミュニケーションをより豊かにしていくことを目指しています。そのために、今後も音声・言語・画像の領域に関わる研究開発を推進し、国内外へ積極的に学術的な貢献を行っていきます。 5. 参考文献 [Mirsamadi, 2017] S. Mirsamadi, E. Barsoum, and C. Zhang, “Automatic Speech Emotion Recognition Using Recurrent Neural Networks with Local Attention,” Proc. ICASSP, pp. 2227-2231, 2017. [Feng, 2020] H. Feng, S. Ueno, and T. Kawahara, “End-to-End Speech Emotion Recognition Combined with Acoustic-to-Word ASR,” Proc. Interspeech pp. 501–505, 2020. [Busso, 2008] C. Busso, M. Bulut, C. Lee, A. Kazemzadeh, E. Mower, S. Kim, J. N. Chang, S. Lee, and S. S. Narayanan, “IEMOCAP: Interactive Emotional Dyadic Motion Capture Dataset,” Language Resources and Evaluation, vol. 42, no. 4, pp. 335-359, 2008.

はじめまして。RevComm の渋谷です。MiiTel Phone Mobile のバックエンドや E2E テストなどを主に担当しています。2021 年 6 月に入社し、在籍がちょうど 1 年経過したところです。 それとは別に、TechTalk （エンジニア主体の技術共有の場） 運営にも 2021 年 8 月頃から参加しております。 今回は RevComm における TechTalk の立ち位置や意義、どのような発表が行われてきたか、そして続けていくコツなどをお話してみたいと思います。 RevComm における TechTalk とは RevComm では毎週水曜日に 15:30 〜 16:00 の 30 分枠で TechTalk を開催しています。 エンジニアの発表体験を増やす場 エンジニアの技術スキルを底上げする場 プロダクトに関する技術共有・相談の場 エンジニア個人の技術的（に限らない）興味に関する発表の場 エンジニア同士のコミュニケーションの場 自社プロダクトにユーザーとして触れる場 といった場を提供することを目的として活動を続けています。 参加は任意で、 RevComm に所属しているメンバーであれば役職や部署に関係なく、カジュアルに発表・質疑応答などが行われています。 発表は弊社のプロダクトである MiiTel for Zoom と連携されたZoom上で行っており、日本や世界各地に点在している RevComm エンジニアたちが時間になると集まってきます。 RevComm の Technology 本部所属メンバーは 2022 年 6 月現在 64 名おり、コンスタントに 20 〜 30 名ほどが参加しております。 発表は録画され、これも弊社プロダクトである MiiTel Analytics で後から振り返る事ができます。 弊社プロダクト「MiiTel Analytics」による解析画面 こちらは私が先日発表した「モバイルチームの CI / CD 」の MiiTel Analytics の解析結果ですが、自分の発表を客観的に振り返ることによって発表スキルの向上が見込めますし、プロダクトへの理解を深めることもできます。 個人的にはフィラー（つなぎ言葉）を除かないままの文字起こし結果を見て、「えーと」や「あー」などがとても多いな…というのが反省点となりました。 発表資料もまとめておりますので、後から他のメンバーが閲覧することが可能です。 発表者は主に自発的な参加（立候補）で決まりますが、その他に運営が発表を依頼（スカウト）する場合もあります。 スカウトは Slack 上での発言を元に依頼したり、CTO が他部署へ行った技術解説の紹介を依頼したりしています。 TechTalk 発表例 では実際にどのような発表を行っているのか、これまで実施した内容を少しご紹介いたします。 スタートアップの知財戦略 知財とは何か、プロダクトにとってどのような意味・メリットを持つのかを、過去の事例や今後の戦略を交えて紹介 Interspeech 2021 参加報告 Interspeech （音声言語処理分野の国際会議）における RevComm の研究成果の発表報告や興味深かった発表の紹介 「Interspeech 2021 参加報告」スライド 配信サービス作ってみた話 WebRTCや配信技術に関心を持った発表者が独自の配信サービスシステムを構築してみた体験談 「配信サービス作ってみた話」スライド RevComm のおすすめの開発方針のアップデート RevComm における開発方針を見直し、より良いプロダクトを生み出せるような方針の相談会 また RevComm における技術的ルールについても改めて周知 TechTalk横断企画〜各プロジェクトの自動化について〜 TechTalk 運営主催による「各プロジェクトに同一テーマについて発表してもらう」横断企画 Analytics・Corporate Engineering・Mobile・Softphone の4チームが取り入れている自動化のツールや取り組みなどを発表 Analytics　…　忘れやすい作業や属人化を防ぐための自動化の導入について（ 当TechBlog でも発表） Corporate Engineering　…　BackOffice 系システムの構築に使用している CI / CD ツールやそのフローについて Mobile　…　モバイルアプリビルド用 CI / CD の流れや取り組み中の E2E テスト自動化について Softphone　…　ライブラリアップデートの自動化について 心理的安全性とは 書籍情報に基づき、心理的安全性とはどういう概念か、心理的安全性が高いチームのメリット、などを解説 「心理的安全性とは」スライド TechTalkを続けていくコツ このように RevComm の TechTalk では、技術的な話からマネジメントや知財といったバラエティに富んだ発表が行われています。 ちなみに、2021 年 8 月 1 日 から 2022 年 6 月 15 日 まで水曜日は 52 日（祝日は 3 日）あり、うち 32 回開催しております（開催率 65 %）。 TechTalk 運営に 9ヶ月ほど携わっていく中で「継続していくコツ」として下記のような取り組み方があるのではないか、と感じるようになりました。 運営だけで頑張りすぎない 運営がアンケートを取ったり、資料を作成するなど、様々な準備をして臨まれる社内勉強会の形式もとても有意義だとは思いますが、続けていくには負荷が高くなってしまう場合があります。 例えば RevComm 内の横断企画の場合ですと、運営が立案はしましたが、発表者の選定や発表内容・資料は各プロジェクトにお任せしました。 出来るだけ運営外のエンジニアも巻き込んでいった方が、負荷が集中しないのかな、と思います。 気軽に参加できる雰囲気を作る 発表を含めた参加は出来るだけ気楽な感じで出来ると良いと思います。 そのため、1 回の発表の分量や責任を重くしすぎない事も重要です。 RevComm の TechTalk は 30 分という短時間スケジュールとなっており、実際の発表は 15 分程度（残りは質疑応答や雑談）というライトなものになっています。 TechTalk に参加するということは、エンジニアのその時間のスケジュールを押さえることにもなりますので、その点でも 30 分という短時間開催は続けやすいと思います。 同じ時間帯で予定を組む 定期的に開催し、参加してもらいやすくするためには、ルーチンとして同じ時間帯のスケジュールを押さえておいた方が良さそうです。 RevComm では同じ水曜日の 13〜18 時にもくもく会（エンジニア主体で同じスペースに参加しながら個々人の業務を執り行うオンラインミーティング）が開催されているのですが、TechTalk はその中間に位置しているため、息抜きを兼ねて参加するメンバーも多いようです。 失敗も良い経験 人があまり集まらなかった、発表者がいなくて開催できなかった、といった失敗も、「こういう事もあるよね」と（ある意味で）割り切る淡白さもあるといいかもしれません。 失敗した理由の振り返りはもちろん行いますが、失敗したり成功したりを繰り返しつつ続けていくのが、最終的に長続きさせることが出来るように感じます。 まとめ 私は TechTalk 運営に携わる事ができてとても良かったと思っています。 TechTalk の運営であることでたくさんの社内エンジニアと関わるきっかけも増えましたし、自分の存在も知ってもらうことができて、業務を円滑に進められるようになりました。 RevComm 内には様々なエンジニアがそれぞれのペースで業務に携わっていますが、その中でオアシスのようにちょっとした気分転換や息抜きの場として TechTalk を提供できていたらいいな、と考えながら運営に携わっています。 いつか様々な会社の TechTalk （やそれに類する企画）の運営に携わってる方々とも交流してみたいですね。 そんな RevComm ではエンジニアを募集しております。 この記事で RevComm に興味を持ってくださった方がいらっしゃいましたら、ぜひ奮ってご応募ください。 www.revcomm.co.jp

こんにちは、株式会社RevCommでAndroidアプリ開発を担当している吉村です。 私が開発を担当しているアプリに MiiTel Phone Mobileというものがあります。このアプリはスマートフォンでインターネット回線を介して発着信ができる通話アプリです。日々の業務において機能追加・機能改修をする場面は多いのですが、その中でも通話部分の実装には通話アプリ特有の実装の難しさがあります。 今回は、その一例として、通話やビデオチャットを実装するときに用いられる テレコムフレームワーク の導入方法について、実装例を交えて紹介していきます。 目次 目次 テレコムフレームワークとは なぜ通話状態を共有する必要があるのか テレコムフレームワークの導入手順 AndroidManifestにPermissionとConnectionServiceを指定 ConnectionServiceの実装 Connectionの実装 Connectionの状態を変更・監視する機能の実装 Connectionの状態（通話状態）の監視 終わりに 参考 テレコムフレームワークとは テレコムフレームワークとは一言で言うと「Android OSに通話状態を伝えることにより、OSを介して他の通話アプリと通話状態を共有するための機能」です。 とはいえこの一言では、なぜテレコムフレームワークを用いて他の通話アプリと通話状態を共有する必要があるのか分からないと思います。したがって、「他の通話アプリと通話状態が共有されていないとどういった不具合が発生するか」を考えてみましょう。 なぜ通話状態を共有する必要があるのか 結論としては「通話を排他制御するため」です。 仮に、端末に通話状態をOSに共有する機能がない通話アプリAと、通常の通話アプリBがそれぞれインストールされているとします。そして、アプリAで通話中にアプリBに向けて電話がかかってきたら、アプリBはアプリAが通話中であることを知らないので「保留」という選択肢は出てきません。「電話に出る」か「着信を拒否する」の二択になります。電話に出てしまった場合、一対二で通話が成立してしまうこともあり得ます。 アプリで通話中に他の通話アプリに着信が発生したら「保留して電話に出る」「着信を拒否する」などの選択肢が表示されるのが一般的な電話のイメージかと思います。電話として当たり前の機能のようですが、通話アプリがOSを介して「他の通話アプリで既に通話中である」と知っていて初めてこれらの選択肢を出すことができます。 このように、アプリ間で通話の状態を共有することは、通話を排他制御するために重要となってきます。Androidにおいては、テレコムフレームワークを利用することで、他の通話アプリの通話状態を取得することができます。 テレコムフレームワークの導入手順 それでは、他の通話アプリと通話状態を共有するために、テレコムフレームワークを通話アプリに実装してみましょう。 公式ドキュメントによると、テレコムフレームワークを通話アプリに組み込むオプションとして self-managed型 managed型 の二つが存在していますが、本稿は、self-managed型のオプションを選択した場合について説明しています。 なお、self-managed型を選択した場合、着信時・発信時のUIなども含めて全て自前で実装することが可能です(MiiTel Phone Mobileにおいては発着信時のUIを自前で実装しているため、こちらを採用しています) managed型を選択した場合、Androidデフォルトの着信時・発信時のUIを利用することで、self-managed型と比較して、簡便に実装することが可能です。 まずはテレコムフレームワークの導入の流れを簡単に説明します。 ※公式提供のライブラリのメソッド名やクラス名は斜体表記とします。 AndroidManifestにPermissionと ConnectionService の指定 テレコムフレームワークを扱うために必要なPermissionを追加し、通話開始時に起動するServiceクラスを指定します。 ConnectionService の実装 ConnectionService とは、発信時 or 着信時に起動するServiceクラスです。発着信時に発信中または着信中の状態を持った Connection のインスタンスを生成し、それをアプリケーションのスコープで保持するようにします。 Connection インスタンスの通話状態の監視の実装 OSと通話状態を共有するための Connection クラスを実装し、その通話状態の変更を監視するlistenerを実装します。 Connection の状態を変更・監視するための機能の実装 アプリ側からテレコムフレームワークを使用するためのinterfaceを定義し、実装例を解説します。 Connection の状態（通話状態）の監視 Connection のstateを監視するlistenerの実装例を解説します。 上記のような流れとなります。それでは詳細に入っていきます。 AndroidManifestにPermissionと ConnectionService を指定 OSから通話状態を取得したり、通話状態を変更するための権限が必要なので、下記の三つのパーミッションを追加します。 <uses - permission android:name= "android.permission.CALL_PHONE" / > <uses - permission android:name= "android.permission.MANAGE_OWN_CALLS" / > <uses - permission android:name= "android.permission.READ_PHONE_STATE" / > また、通話を開始するときに立ち上げる ConnectionService というサービスクラスもAndroidManifestにて指定する必要があります。（ ConnectionService の実装については後述） <service android:name= "jp.co.sample.telecom.MyConnectionService" android:exported= "false" android:permission= "android.permission.BIND_TELECOM_CONNECTION_SERVICE" > <intent - filter> <action android:name= "android.telecom.ConnectionService" / > < / intent - filter> < / service> ConnectionService の実装 前節でAndroidManifestにて ConnectionService の実装クラスを指定しました。 ConnectionService とはざっくり言うと「通話開始」をOSに伝えるためのServiceクラスです。 発信するときに TelecomManager.placeCall() をコールすると ConnectionService の onCreateOutgoingConnection() が呼ばれます（着信を受ける場合は TelecomManager.addNewIncomingCall() をコールすると onCreateIncomingConnection() が呼ばれます）。 onCreateOutgoingConnection() 内で Connection という通話状態を伝えるためのインスタンスを生成して、それを返すとOSに通話開始を知らせることができます。 ConnectionService を継承したクラスを作成し、発信時に TelecomManager.placeCall() を呼ぶことで呼び出されるメソッド onCreateOutgoingConnection() を実装します。 // class MyConnectionService : ConnectionService() override fun onCreateOutgoingConnection( connectionManagerPhoneAccount: PhoneAccountHandle?, request: ConnectionRequest? ): Connection { // TelecomManager.placeCall()を呼ぶとこのメソッドが呼ばれます // ↓また、placeCall()の引数に渡したbundleから値を受け取れます val name = request?.extras?.getString( "name" ) val connection = MyConnection(stateChangedListeners).apply { // 発信者名をセットしています setCallerDisplayName(name, TelecomManager.PRESENTATION_ALLOWED) // Connectionのstateをdialingに設定しています setDialing() } return connection } 次に、上記の発信時とほぼ同様の着信時のコードを追加します。 // class MyConnectionService : ConnectionService() override fun onCreateIncomingConnection( connectionManagerPhoneAccount: PhoneAccountHandle?, request: ConnectionRequest? ): Connection { val bundle = request?.extras?.getBundle(TelecomManager.EXTRA_INCOMING_CALL_EXTRAS) val name = bundle?.getString( "name" ) val connection = MyConnection(stateChangedListeners).apply { setCallerDisplayName(name, TelecomManager.PRESENTATION_ALLOWED) setRinging() } return connection } そして上記の発着信をしたときに生成したConnectionに渡すlistenerの管理をするメソッドを追加します。 // class MyConnectionService companion object { // リスナーが複数セットされるため private val stateChangedListeners = mutableListOf<ConnectionStateChangedListener>() fun addConnectionStateChangedListener(listener: ConnectionStateChangedListener) { stateChangedListeners.add(listener) } fun removeConnectionStateChangedListener(listener: ConnectionStateChangedListener) { stateChangedListeners.remove(listener) } } Connection の実装 次に Connection を実装します。 Connection はOSとアプリを繋ぐ重要な役割を持ったクラスです。 Connection を実装するにあたってすべきことは二つあって、一つ目はstateの変化を取得することです。例えばstateがIncomingになったら着信画面を表示したり、stateがOutgoingになったら発信画面を表示したり、stateに応じて行いたいことがあるかと思います。そのためにstateの変化を取得します。 二つ目は、OSに由来したポップアップに対してユーザーがアクションしたときに、OSからそのアクションを受け取ることです。 Connection の onAnswer() , onDisconnect() などが呼ばれるので、その結果に応じて Connection のstateを変更します。 これらを実装することによって、OSにこのアプリの通話状態が伝わったかどうかという情報や、他アプリの通話状態からどのような影響を受けたか（例えば他アプリで着信を受けたから受電するために、このアプリの通話は切電しようとした、などのアクション）、などの情報を得られます。 具体的な実装に移ります。 まずは Connection を継承し、初期化処理を書きます。通話状態を監視するためのlistenerのリストをコンストラクタに渡しています。(複数箇所で監視する必要がある場合のためにlistenerを複数セットできるようにリスト形式にしています） interface ConnectionStateChangedListener { fun onStateChanged(state: Int , connection: MyConnection) } class MyConnection( private val stateChangedListeners: MutableList <ConnectionStateChangedListener> = mutableListOf() ) : Connection() { init { audioModeIsVoip = true // 自己管理型の通話アプリの場合は必要です // （これを設定しないと発信時にデフォルトの発信画面が表示されます） connectionProperties = PROPERTY_SELF_MANAGED setInitializing() } 通話状態の変更があった場合にlistenerに伝えます。 // class MyConnection override fun onStateChanged(state: Int ) { super .onStateChanged(state) stateChangedListeners.map { listener -> listener.onStateChanged(state, this ) } } また、他のアプリとの通話状態の兼ね合いで、OS由来のポップアップが出てくることがあり、そのポップアップへのアクション結果が下記の三つのメソッドにコールバックされます。 まずは onDisconnect() についてですが、一例として、このアプリで通話中に他のアプリから発信しようとすると「この通話を発信すると、このアプリの通話が終了します。」という旨のポップアップが表示され、OKをタップすると onDisconnect() がコールされます。下記にサンプルとしてPixel5(Android 11)のポップアップを載せますが、OSや機種によって若干の文言の違いがあったり、挙動が異なる場合があります。 ※「TelecomFrameworkSam...」という表示は、アプリ名であるTelecomFrameworkSampleが略されて表示されたものです。 次に、 onAnswer() と onReject() についてです。一例として、このアプリで着信中に他のアプリから着信があると「応答すると、進行中の通話は終了します」というポップアップが出て、「応答」か「拒否」かをタップすると上記メソッドがコールされます。下記がサンプルとなります。 ※「test incoming user」というのは Connection に設定したもので、「Telecom..」というのはアプリ名であるTelecomFrameworkSampleの略となります。 // class MyConnection override fun onAnswer() { super .onAnswer() // OS由来のポップアップに対して電話に出るという類のアクションをするとコールされます setActive() } override fun onReject() { super .onReject() // OS由来のポップアップに対して拒否するという類のアクションをするとコールされます setDisconnected(DisconnectCause(DisconnectCause.REJECTED)) } override fun onDisconnect() { super .onDisconnect() // OS由来のポップアップに対して切電するという類のアクションをするとコールされます setDisconnected(DisconnectCause(DisconnectCause.UNKNOWN)) } Connectionの状態を変更・監視する機能の実装 前節においてConnectionの状態を取得するところまで実装できました。 ただ、上述の一通りの実装を読んでみても「結局のところどのクラスをどうやって使えば良いの？」としっくりこないかと思います。より簡潔にテレコムフレームワークを扱えるようにしたいです。 冒頭の説明を繰り返すと、そもそもテレコムフレームワーク本来の目的は「他の通話アプリと通話状態を共有すること」でしたよね。 では、そのために必要なことは何なのか。 発信をOSに伝えること 着信をOSに伝えること 通話開始をOSに伝えること 保留中をOSに伝えること 通話終了をOSに伝えること Connectionの状態（通話状態）を監視すること 上記を満たせば、OSに十分に通話状態が伝わるかと思います。上記の箇条書きをinterfaceにしてみます。 interface TelecomHelper { @RequiresPermission (Manifest.permission.READ_PHONE_STATE) // 発着信の際に必要なため fun initPhoneAccount(): PhoneAccount? @RequiresPermission (Manifest.permission.CALL_PHONE) fun startOutgoing(number: String , name: String , accountHandle: PhoneAccountHandle) fun startIncoming(name: String , accountHandle: PhoneAccountHandle) fun activate() fun hold() fun disconnect() fun firstConnectionOrNull(): MyConnection? fun addConnectionStateChangedListener(listener: ConnectionStateChangedListener) fun removeConnectionStateChangedListener(listener: ConnectionStateChangedListener) } ほとんど箇条書きそのままのinterfaceを定義できました。このinterfaceを実装して必要に応じて呼び出すことができれば、アプリのソースコードがすごくクリーンに保たれるかと思います。モジュール化しても良いと思います。 続いて、interfaceの実装サンプルです。やや実装量が多いのでメソッドごとに分解して紹介していきます。 まずクラスの構造については、 TelecomHelper を継承してコンストラクタにContextと TelecomManager をインジェクトし、 Connection を保持するリストをメンバに置きます。 class TelecomHelperImpl @Inject constructor ( @ApplicationContext private val context: Context, private val telecomManager: TelecomManager ) : TelecomHelper { private val connections = mutableListOf<MyConnection>() } 続いて各メソッドについてです。 まずは発着信時に、 ConnectionService において生成されたConnectionをリストに追加したり、stateがdisconnectedになった時にリストから除外するためのlistenerをセットします。 // class TelecomHelperImpl init { // Connectionのaddやremoveをするためにリスナーをセット val listener = object : ConnectionStateChangedListener { override fun onStateChanged( state: Int , connection: MyConnection ) { when (state) { Connection.STATE_RINGING -> { startConnection(connection) } Connection.STATE_DIALING -> { startConnection(connection) } Connection.STATE_DISCONNECTED -> { endConnection(connection) } } } } MyConnectionService.addConnectionStateChangedListener(listener) } listenerをadd or removeするためのメソッドを追加します。 // class TelecomHelperImpl override fun addConnectionStateChangedListener(listener: ConnectionStateChangedListener) { MyConnectionService.addConnectionStateChangedListener(listener) } override fun removeConnectionStateChangedListener(listener: ConnectionStateChangedListener) { MyConnectionService.removeConnectionStateChangedListener(listener) } Connection をメンバのリストにadd or removeするためのメソッドです。 endConnection() においては Connection の破棄も行っています。 // class TelecomHelperImpl private fun startConnection(connection: MyConnection) { connections.add(connection) } private fun endConnection(connection: MyConnection) { connections.remove(connection) connection.setDisconnected(DisconnectCause(DisconnectCause.UNKNOWN)) connection.destroy() } 次に、 PhoneAccount を取得するためのメソッドたちを実装します。 PhoneAccount とは、通話時の通信プロトコルの指定やself-managed形式の指定などをするためのクラスです。常に新規にアカウントを作ることはせず、 ConnectionService に PhoneAccount が既に紐付いていた場合はそれを取得します。 // class TelecomHelperImpl @RequiresPermission (Manifest.permission.READ_PHONE_STATE) override fun initPhoneAccount(): PhoneAccount { return findExistingAccount(context) ?: return createAccount(context) } private fun createAccount(context: Context): PhoneAccount { val accountHandle = PhoneAccountHandle( ComponentName(context, MyConnectionService :: class .java), context.packageName ) val account = PhoneAccount.builder(accountHandle, "test" ) .setCapabilities(PhoneAccount.CAPABILITY_SELF_MANAGED) .setSupportedUriSchemes(listOf(PhoneAccount.SCHEME_SIP)) .build() telecomManager.registerPhoneAccount(account) return account } @RequiresPermission (Manifest.permission.READ_PHONE_STATE) private fun findExistingAccount(context: Context): PhoneAccount? { val connectionService = ComponentName( context, MyConnectionService :: class .java ) val targetPhoneAccountHandle = telecomManager.selfManagedPhoneAccounts.firstOrNull { phoneAccountHandle -> phoneAccountHandle.componentName == connectionService } return telecomManager.getPhoneAccount(targetPhoneAccountHandle) } 続いて、発信を開始するときに startOutgoing() をコールします。その内部で TelecomManager.placeCall() を呼びます。これにより ConnectionService が立ち上がって Connection が追加されます。 // class TelecomHelperImpl @RequiresPermission (Manifest.permission.CALL_PHONE) override fun startOutgoing(number: String , name: String , accountHandle: PhoneAccountHandle) { telecomManager.placeCall( Uri.fromParts( "tel" , number, null ), Bundle().apply { putParcelable( TelecomManager.EXTRA_OUTGOING_CALL_EXTRAS, Bundle().apply { putString( "name" , name) } ) putParcelable( TelecomManager.EXTRA_PHONE_ACCOUNT_HANDLE, accountHandle, ) } ) } そして着信時に startIncoming() をコールします。その内部で TelecomManager.addNewIncomingCall() を呼ぶことで ConnectionService が立ち上がって、 Connection が追加されます。 // class TelecomHelperImpl override fun startIncoming(name: String , accountHandle: PhoneAccountHandle) { telecomManager.addNewIncomingCall( accountHandle, Bundle().apply { putParcelable( TelecomManager.EXTRA_INCOMING_CALL_EXTRAS, Bundle().apply { putString( "name" , name) } ) } ) } そして最後に、通話状態が変更された際に、そのことをアプリからOSに伝えるために Connection インスタンスのstateを変更します。 activete() メソッドは、通話開始時および保留解除時、 hold() メソッドは、保留開始時、 disconnect() メソッドは切電時にコールするようにします。 実装例は以下の通りです。 // class TelecomHelperImpl override fun activate() { connections.lastOrNull { it.state == Connection.STATE_DIALING || it.state == Connection.STATE_RINGING || it.state == Connection.STATE_HOLDING }?.setActive() } override fun hold() { connections.lastOrNull { it.state == Connection.STATE_ACTIVE }?.setOnHold() } override fun disconnect() { connections.lastOrNull { it.state == Connection.STATE_DIALING || it.state == Connection.STATE_RINGING || it.state == Connection.STATE_ACTIVE || it.state == Connection.STATE_HOLDING }?.let { endConnection(it) } } 以上がTelecomHelperの実装例となります。 Connection の状態（通話状態）の監視 前節の序盤で、 Connection のstateを監視するためのメソッドを追加しました。 // class TelecomHelperImpl override fun addConnectionStateChangedListener(listener: ConnectionStateChangedListener) { MyConnectionService.addConnectionStateChangedListener(listener) } override fun removeConnectionStateChangedListener(listener: ConnectionStateChangedListener) { MyConnectionService.removeConnectionStateChangedListener(listener) } 上記の二つのメソッドです。 本節では、このlistenerのセット方法と、監視方法についての実装サンプルをご紹介します。 // class SomeViewModel: ViewModel() private val listener = object : ConnectionStateChangedListener { override fun onStateChanged( state: Int , connection: MyConnection ) { STATE_INITIALIZING -> {} STATE_NEW -> {} STATE_RINGING -> {} STATE_DIALING -> {} STATE_ACTIVE -> {} STATE_HOLDING -> {} STATE_DISCONNECTED -> {} STATE_PULLING_CALL -> {} } } init { telecomHelper.addConnectionStateChangedListener(listener) } override fun onCleared() { // メモリリークしないように telecomHelper.removeConnectionStateChangedListener(listener) super .onCleared() } 上記で Connection のstateの変化を監視できます(メモリリークしないよう、ライフサイクルに応じて適切にlistenerを取り外してください)。 これによって、例えば発信がスタートしたときに STATE_DIALING の部分を通るので発信画面を出したり、着信なら STATE_RINGING を通るので着信画面を出したり、 STATE_DISCONNECTED なら通話中画面を閉じたりといった実装ができます。 以上で実装方法については終わります。Helperクラスを介して、アプリとOS間で通話状態の共有ができました。 終わりに テレコムフレームワークの導入に関する情報はニッチすぎてなかなか見つからないので、今後実装に取り組まれる方にとってこの記事が少しでもお役に立てれば幸いです。 また、RevComm ではエンジニアを募集しています。技術好きな方々が多く在籍しており、モブプロや勉強会などが盛んに行われています。ぜひぜひ奮ってご応募ください。 www.revcomm.co.jp 参考 公式ドキュメント: Telecom フレームワークの概要 linphone-android

こんにちは！ RevComm に2022年1月に入社したフロントエンドエンジニアの小山 (koji-koji) です。 RevComm では、 React を採用しているサービスの状態管理に Recoil を使っています。今回は Recoil の理解をより深めるために Context と比較してみました。 Context では小さく状態管理できる。 Recoil でもできないか？ Context の状態管理のスコープは <Context.Provider> で括った対象であり、一方 Recoil では <RecoilRoot> で括った対象です。 Context では、ルートコンポーネント以外を <Context.Provider> で括った場合、子コンポーネントでの変更はグローバルには反映されません。 ローカルではないけれど、グローバルというほど大きくなく状態管理をしたいときに使えます。それが Recoil でもできるのか？と考えました。 Recoil では atomFamily() を使って atom の key を動的に生成する方法があるようです。これはリストを扱うときは良さそうです。一方、リストでない場合もあるので、もう少し調べてみました。 <RecoilRoot> をネストさせると小さく状態管理できる <RecoilRoot> のドキュメント によると、ネストさせるとスコープを調整できることがわかりました。 ルートコンポーネントだけでなく子コンポーネントでも使うと、子コンポーネントの中だけで状態管理ができます。 親コンポーネントで状態を変更しても、子コンポーネントには反映されません。 子コンポーネントで状態を変更しても、親コンポーネントには反映されないという形でスコープが狭まります。 サンプルです。 サンプルコード function MyApp ( { Component , pageProps } : AppProps ) { return ( < RecoilRoot > < Component { ...pageProps } id = "modalId" / > < /RecoilRoot > ); } const ParentComponent: React.FC = () => { const [ sample , setSample ] = useRecoilState ( sampleState ); return ( < div className = "bg-blue-100 p-2" > ParentComponent: { sample } < button className = "ml-3 bg-gray-100 p-3" onClick = { () => setSample ( sample + 1 ) } > ボタン < /button > < div className = "mt-2 flex" > < RecoilRoot > < NestChildComponentA / > < NestChildComponentB / > < /RecoilRoot > < ChildComponentC / > < /div > < /div > ); } ; const NestChildComponentA: React.FC = () => { const [ sample , setSample ] = useRecoilState ( sampleState ); return ( < div className = "bg-pink-300 p-2" > < RecoilRoot > NestChildComponentA: { sample } < button className = "ml-3 bg-gray-100 p-3" onClick = { () => setSample ( sample + 1 ) } > ボタン < /button > < NestGrandChildComponent / > < /RecoilRoot > < /div > ); } ; const NestChildComponentB: React.FC = () => { const [ sample , setSample ] = useRecoilState ( sampleState ); return ( < div className = "bg-green-300 p-2" > < RecoilRoot > NestChildComponentB: { sample } < button className = "ml-3 bg-gray-100 p-3" onClick = { () => setSample ( sample + 1 ) } > ボタン < /button > < /RecoilRoot > < /div > ); } ; const ChildComponentC: React.FC = () => { const [ sample , setSample ] = useRecoilState ( sampleState ); return ( < div className = "bg-yellow-300 p-2" > < RecoilRoot > ChildComponentB: { sample } < button className = "ml-3 bg-gray-100 p-3" onClick = { () => setSample ( sample + 1 ) } > ボタン < /button > < /RecoilRoot > < /div > ); } ; const NestGrandChildComponent: React.FC = () => { const [ sample , setSample ] = useRecoilState ( sampleState ); return ( < div className = "mt-2 bg-blue-300 p-2" > < RecoilRoot > NestGrandChildComponent: { sample } < button className = "ml-3 bg-gray-100 p-3" onClick = { () => setSample ( sample + 1 ) } > ボタン < /button > < /RecoilRoot > < /div > ); } ; export const sampleState = atom < number >( { key: 'SampleAtom' , default : 0 , } ); </div> <RecoilRoot> を適切にネストさせることで状態管理のスコープを調整できそうですね。 なぜ <RecoilRoot> をネストさせるとスコープが閉じるのか <RecoilRoot> をネストさせたときの挙動はわかったのですが、なぜこうなるのかあまりよくわかりませんでした。 そこで RecoilRoot のコード を見てみました。 Flow で書かれていますが、あまり知識がなくても読めそうです。 553 行目から RecoilRoot の記述があります(今回参照した Recoil のバージョンは 0.7.2 です)。 function RecoilRoot ( props: Props ) : React. Node { const { override , ...propsExceptOverride } = props ; const ancestorStoreRef = useStoreRef (); if ( override === false && ancestorStoreRef.current !== defaultStore ) { // If ancestorStoreRef.current !== defaultStore, it means that this // RecoilRoot is not nested within another. return props.children ; } return < RecoilRoot_INTERNAL { ...propsExceptOverride } / >; } ストアを比較して異なっている場合はネストしているので、処理を分けているという感じです。 ネストしている場合は、別のストアを作るという処理をしています。 なお Recoil_RecoilRoot.js の中のコードで気がついたのですが、 useContext を使っていました。 私は Recoil を触る前は、 Context vs Recoil というイメージを持っていました。しかしその理解は少し違っていたみたいです。 Recoil は Context を内部的に使っていて、 atom と selector をうまく活用することで再レンダリングを抑えているといった方が正しそうです。 RecoilRoot の挙動についての記事は以上です。 今回はドキュメントを読むのに加えて、実際に挙動を確認したり、コードリーディングをしました。 コードリーディングをすると、やはり理解が深まったり発見があったりしますね！ 今後も気になるところがあったら、どんどんコードリーディングしていきたいです。

RevComm で Software Engineer をやっております、佐藤と申します。 現時点で弊社には4名の佐藤が在籍していますが、今のところ全員の所属部門が大きく違うため、苗字で呼ばれてもあまり困らない日々を過ごしております。 今回は弊社で利用している E2E テストツールの Autify についてのお話です。実際の運用について少しだけ踏み込んだ話になりますので、Autify についての紹介・説明は省いている場合があります。Autify を利用している・利用を検討している方に読んでいただけたら嬉しいです。 最初の実行回数オーバーが契機に ある月の半ばに「このままいくと Autify の実行回数が当初購入分を超えるかも？」という状況が発生しました。これは弊社の製品 MiiTel の E2E テストツールとして Autify を導入してから初めてのことです。 その時点で、完成形のシナリオ数と現在回している定期実行のペースを元に月当たりの実行ペースを算出したところ、今のプランでは明らかに実行回数が足りないことが判明しました。 そこで Autify の利用方針を定めて最適な実行回数を見積もり、それを持って Autify 社と実行回数を増やす相談をしよう、ということになりました。 導入初期を思い出すと、実行回数は今のプランで足りるのか？ということを検討できるくらいシナリオが出揃った事はかなり感慨深いものがあります。 必要な消費回数の見積もり MiiTel にはさまざまなマイクロサービス(以下サービス)が存在し、それぞれの実装を行うチームが Autify のシナリオ実装も行っています。また、SLA や障害時のリスクといった必要な実行回数の根拠となる考え方も、サービスによって異なります。 一方、Autify の実行回数は会社単位の数字です。何の制限もなく使っていった結果、あちらのチームが使いすぎて別のチームが困った...という事態は防ぎたいところです。 最終的には、以下のような体系で指針を示し、それに沿って各チームが見積もった数字を合算して全体の消費回数見積とすることにしました。 製品をテストするための実行 自サービスリリース時の実行 リリース前にステージング環境で実行 リリース後にプロダクション環境で実行 他サービスの変更に影響を受けるシナリオの実行 MiiTel 以外のサービスに影響を受けるシナリオの実行 MiiTel の他サービスの変更に影響を受けるシナリオの実行 それ以外の実行 シナリオ実装時の実行 シナリオメンテナンス時の実行 製品をテストするための実行 数字を見積もる上では、シナリオ実行を「製品をテストするための実行」と「それ以外の実行」に分ける必要があります。 「製品をテストするための実行」はMiiTel の E2E テストとして実行することです。普通に考えたらここについてだけ数字を考えれば良さそうな気がしてしまいます。 一方、「それ以外の実行」とは、シナリオを作成する際に試しに回す実行や、Autify の運用中にテストがコケてしまいメンテナンスする時の実行などです。ここを極力減らす方法も考えがちですが、人間が手を動かす時間を削減したくて導入した Autify の実行回数を減らすために人手を割くようになると本末転倒ですから、大まかにでもこの数字を見積もっておく必要があります。 自サービスリリース時の実行 自分のチームが担当するサービスに対するテストは、リリース時だけ行えば良さそうです。リリース前に不具合をキャッチできるよう、ステージング環境で網羅的な回帰テストを実行。また、プロダクションでも同じ内容でもう一度実行します。同じテストを二度実施するのは、環境差異が動作に影響する可能性を潰したい、お客様に使っていただいている環境でテストが終わっていれば安心という理由です。 つまり、シナリオ数の見積もりは以下のようになります。 フルテストのシナリオ数 × 月当たりのリリース回数 × 2 他サービスの変更に影響を受けるシナリオの実行 MiiTel のサービスの中には、リリース時に他のサービスの変更に影響を与えてしまうものがあります。他のチームのサービスのテストを行うことを考える場合、それに伴うリスクやコストも考える必要があります。そこで、MiiTel 内の他サービス・他社のサービスに変更があった際に影響を受ける箇所のテストを毎日定期実行で回す方針にしました。リリースを行う（影響を与える）側のチームではなく、影響を受ける側がテストについて責任を持てる形になります。 シナリオ数の見積もりは以下のようになります。 影響を受けるテストのシナリオ数 × 31 また、MiiTel 内のサービスであればリリースが行われる可能性が低い曜日が決まっていますから、MiiTel 内の他サービスに影響を受けるテストの場合は以下のようになります。 影響を受けるテストのシナリオ数 × 20 それ以外の実行 すでに説明した、製品をテストするための実行以外のテストです。こちらは実績から見積もるしかありません。現時点ではそういった画面は用意されていないため、テスト結果検索画面で YYYY-MM（対象の年月）を検索してその月を検索して件数を確認しました。今回調べたところでは、全体の実行回数に対し約30%が「それ以外の実行」によるものでした。 シナリオ作成作業のボリュームは作成済みのシナリオ数には関係がないため厳密ではありませんが、いったんこの方法でとりあえずの最大値は決めることにしました。 今後の課題 以上の方法で、弊社では Autify の実行回数を大まかに見積もることができました。他社で Autify を導入する際にそのまま使えるやり方ではないかもしれませんが、同じ考え方で適切な実行数を保てると思います。 とはいえ、まだまだ課題はたくさんあります。現在は、Autify のシナリオレビューをどう管理していこうかという課題に取り組んでいます。今後徐々に手動テストを削っていくにあたって、自動テストが適切に作成されていることを担保したいからです。 RevComm は高い安定性を求められるプロダクトにおける E2E テストの実装や運用に興味のあるエンジニアを募集しております。ご興味ある方のご応募、お待ちしております。 hrmos.co

こんにちは。 Infrastructure (インフラチーム) 所属の小門です。 RevComm (レブコム) では、電話営業や顧客対応を可視化する音声解析 AI 搭載型のクラウド IP 電話 MiiTel (ミーテル) を提供しています。 miitel.com はじめに MiiTel を含め RevComm ではクラウドプラットフォームに AWS を利用しています。 環境や用途に応じて複数の AWS アカウントを保有しています。 各 AWS アカウントの特権ID (※) を使用できるのは、業務上必要とするごく少数のメンバーのみに制限しており、必要が生じたメンバーには一時的に権限付与する運用をしています。 ※特権ID…ルートユーザーや AdministratorAccess IAMポリシーがアタッチされたユーザーID (= Admin ロール) 特権IDをやみくもに使用することはセキュリティガバナンス面でリスクが高いため、原則必要十分な権限を持つユーザーIDで操作するルールとしています。 例えば、環境の確認をする場合には ReadOnlyAccess、リリース作業をする場合には PowerUserAccess を使用するというイメージです。 今回は、やみくもな特権IDの使用に対するけん制やアカウント流出のリスクに備えるために特権IDの使用を検知する仕組みを構築しました。 また特権ID使用時には用途や作業内容を記載する運用ルールとし、監査証跡として残せるようにしています。 全体構成 ステップ1. ログイン検知 (メール通知) ルートユーザー Admin ロール 通知結果 ステップ2. 個別メンション付きリプライ Slack App 作成 メンション用のユーザーID取得 ボットのコア処理 デプロイ 動作確認 まとめ 全体構成 ステップ1. ログイン検知 (メール通知) ステップ2. 個別メンション付きリプライ 大きく2段階に構成になっています。 ステップ1. ログイン検知 (メール通知) ルートユーザー AWS ルートユーザーがログインしたことを通知するための CloudFormation (以下、CFn) テンプレートが公開されており、これを参考にしました。 CloudTrail を介してルートユーザーのログインを検知し EventBridge、SNS 経由でメールが送信されます。 参考: ルートユーザーアカウントが使用されたことを通知する EventBridge イベントルールを作成する ルートユーザーがログインした CloudTrail イベントレコードは下記のようになり、これが上記 CFn テンプレートの EventPattern に対応しています。また IAM はグローバルリージョンサービスのため CloudTrail イベントデータが us-east-1 リージョンに集約される点に注意します。 CloudTrail イベントレコード (抜粋) { " eventVersion ": " 1.08 ", " userIdentity ": { " type ": " Root ", ... } , " awsRegion ": " us-east-1 ", " eventType ": " AwsConsoleSignIn ", ... } CFn テンプレート (抜粋) Resources : ... EventsRule : Type : AWS::Events::Rule Properties : Description : Events rule for monitoring root AWS Console Sign In activity EventPattern : detail-type : - AWS Console Sign In via CloudTrail detail : userIdentity : type : - Root ... Admin ロール 上記を参考にして特定の IAM ロールが使用されたことを検知するイベントパターンも作成しました。 RevComm では、Google Workspace を用いた AWS SSO によって開発者が IAM ロールを使用するルールになっています。 Google アカウント認証後に IAM ロールを利用すると、裏側で AssumeRoleWithSAML というアクションが実行され CloudTrail で検知できます。 コンソールログイン AWS CLI などによる認証情報取得 ( aws sts assume-role-with-saml ... ) の両操作をカバーできます。 CloudTrail イベントレコード(抜粋) { " eventVersion ": " 1.08 ", " userIdentity ": { " type ": " SAMLUser ", " userName ": " xxx@revcomm.co.jp ", ... } , " eventSource ": " sts.amazonaws.com ", " eventName ": " AssumeRoleWithSAML ", " awsRegion ": " us-east-1 ", " requestParameters ": { ... " roleArn ": " arn:aws:iam::012345678910:role/AdministratorRole ", ... } , ... } CFn テンプレート(抜粋) Mappings : AccountAdminRoleNameMapping : AdminRoleArn : # account-1 "012345678910" : arn:aws:iam::012345678910:role/AdministratorRole # ... Resources : ... AssumeRoleWithSAMLEventsRule : Type : AWS::Events::Rule Properties : EventPattern : detail-type : - "AWS API Call via CloudTrail" detail : eventSource : - "sts.amazonaws.com" eventName : - AssumeRoleWithSAML requestParameters : roleArn : - !FindInMap [ AccountAdminRoleNameMapping, AdminRoleArn, !Ref "AWS::AccountId" ] ... 通知結果 正しく設定できると、下記のようにメール送信することが確認できます (Slack) 。 また、EventBridge の「入力トランスフォーマー」を使用して各種情報を抜粋しています。 ルートユーザーのログイン通知 Admin ロールのログイン通知 ステップ2. 個別メンション付きリプライ ログイン検知から通知までの仕組みができましたが、一歩踏み込んで個別メンションするようにしました。 ステップ1 で Slack に送信されたメールをトリガーにした Slack App (ボット) を作成し、AWS Lambda で動作させています。 ボットの実装には Slack が公式に公開しているフレームワークである Bolt for Python を使用しました。 slackapi/bolt-python: A framework to build Slack apps using Python ドキュメント: Slack | Bolt for Python Lambda ランタイムは Python 3.9、ライブラリは下記のバージョンを使用しています。 slack-bolt==1.11.2 slack-sdk==3.13.0 Slack App 作成 Slack App コンソール から「Create New App」を選び、新規アプリを作成します。 Slack App がメッセージの受信をハンドルできるよう「Event Subscriptions」をオプトインします。※Slack App 自体の詳細な手順は本記事では割愛させて頂きます。 Lambda 関数で利用するトークン情報の取得方法のみ記載します。 SLACK_BOT_TOKEN OAuth & Permissions > OAuth Tokens for Your Workspace > Bot User OAuth Token SLACK_BOT_SIGNING_SECRET Settings > App Credentials > Signing Secret メンション用のユーザーID取得 ボットから送信するメッセージでメンションを付けるには単に @xxx とするのではなく、 <@[user-id]> とする必要があります。 [user-id] は Slack 内部で管理されている固有値です( "W012A3CDE" のような形式)。 個別メンションのためにユーザーIDをメールアドレスから取得する必要があります。 from typing import Optional from slack_sdk import WebClient SLACK_BOT_TOKEN = 'xxx' def get_user_id_by_email_address (email_address: str ) -> Optional[ str ]: client = WebClient(token=SLACK_BOT_TOKEN) response = client.users_lookupByEmail(email=email_address) if not response.data.get[ "ok" ]: return if response.data.get( "error" ) == "users_not_found" : return return response.data[ "user" ][ "id" ] 参考: users.lookupByEmail method | Slack ボットのコア処理 Bolt App を初期化すると @app.event のようにデコレーターで Slack 上のイベントをリッスンして処理を実装できます。 またエントリーポイントとなる lambda_handler もフレームワークのメソッドが用意されているため簡潔に実装することができます。 import json import re from typing import Union from slack_bolt import App from slack_bolt.adapter.aws_lambda import SlackRequestHandler from slack_sdk import WebClient SLACK_BOT_TOKEN = 'xxx' SLACK_BOT_SIGNING_SECRET = 'xxx' app = App( process_before_response= True , token=SLACK_BOT_TOKEN, signing_secret=SLACK_BOT_SIGNING_SECRET ) @ app.event ({ "type" : "message" , "subtype" : "file_share" , }) def reply_to_sns_email (body, logger): """Amazon SNS からのメール通知に対してメンション付きスレッド返信を行う""" attachment = body[ "event" ][ "files" ][ 0 ] # メール以外のイベントはスキップする if attachment[ "filetype" ] != "email" : return { 'statusCode' : '200' , 'body' : json.dumps({ 'message' : 'This message is not email.' }) } # ... email_body = attachment[ "plain_text" ] # " -- " 以降の改行を含む全ての文字を除去する login_info_text = re.sub( "--.*" , "" , email_body, flags=re.DOTALL).replace( " \r\n " , "" ) login_info = json.loads(login_info_text) arn = login_info[ "RoleArn" ] if arn.endswith( "root" ): """root ユーザーが使用された場合 e.g. arn:aws:iam::012345678910:root """ user_id = None message_abstract = "rootユーザーによるコンソールログインが行われました。" else : """Assumed Role Arn からログイン者のメールアドレスを取得する""" email_address = login_info[ "UserName" ] message_abstract = "権限の強いアカウントが使用されました。" # メールアドレスから Slack ユーザID を紐づける user_id = get_user_id_by_email_address(email_address) if user_id is None : mention = "<!here>" else : mention = f "<@{user_id}>" message_text = \ mention + " \n " + message_abstract + " \n " \ "- 作業目的や内容 \n " \ "- タスクチケットURL \n " \ "などを記入してください。" client.chat_postMessage( channel=body[ "event" ][ "channel" ], thread_ts=body[ "event" ][ "event_ts" ], text=message_text ) return { 'statusCode' : '200' , 'body' : json.dumps({ 'message' : 'ok' }) } def lambda_handler (event, context): slack_handler = SlackRequestHandler(app=app) return slack_handler.handle(event, context) デプロイ 上記の Lambda 関数をデプロイし、API Gateway の配下に配置します。 API Gateway は「REST API」ではなく「HTTP API」で作成する必要があるので注意します。 デプロイ後、API Gateway の URL を Slack App のリクエスト URL に登録します。 ※Features > Event Subscriptions > Request URL 動作確認 ここまでの手順が正しく設定できていれば、ルートユーザー/Admin ロールのログインを契機に一連処理を通してボットによる個別メンション付きリプライが届きます。 まとめ 特権IDの使用を通知し、セキュリティガバナンスを改善する取り組みについてご紹介しました。 本記事の取り組みでは下記のメリットを実現しました。 特権IDがやみくもに使用されることをけん制しつつ、使用状況をモニタリングする 特権IDを用いる作業内容の監査証跡を残す RevComm ではお客様に安心して製品をご利用頂けるよう、引き続きセキュリティの向上に力を入れてまいります。 Infrastructure では、プロダクト横断で考慮するセキュリティの管理や IaC 、また一部オンプレ環境の管理・運用を行っています。ご尽力頂けるエンジニアを探しています。 インフラ以外にも全方位でエンジニアを積極的に採用中ですのでぜひ採用サイトをご覧ください！ www.revcomm.co.jp

こんにちは、RevComm の玉城です。MiiTel Analytics のサーバーサイドの開発を主に担当しています。MiiTel Analytics は通話や会議の履歴・音声解析結果を集約し可視化する製品です。 MiiTel Analytics では以下の2つを提供するために Amazon OpenSearch を運用しています。 全文検索機能 使用単語頻度レポート この Amazon OpenSearch のシャード数を切り替えるタイミングがありそちらを私が担当しましたので、その時の内容を紹介したいと思います。 シャード数切り替えに至った経緯 リインデックスとは リインデックスの高速化 MiiTel における OpenSearch へのデータ登録の仕組み まとめ シャード数切り替えに至った経緯 OpenSearch には MiiTel Analytics で解析された応対履歴が保存されます。そのため、MiiTel の利用ユーザーが増えると保存されるデータも増大し、書き込み/検索に掛かる負荷が大きくなっていきます。参考として、記事執筆時点では 1 億近いドキュメント数と 300 GB を超えるデータサイズとなっています。 このようにデータ数増大による負荷増大への対応として、OpenSearch にはインデックス毎にシャード数を設定します。シャードとは、OpenSearch でクラスターにデータを分散するときの単位です。 切り替え前のシャード数は 2 で各シャード数の容量は約 65 GB でした。AWS 側では適切なシャードのサイズは 10 〜 50 GiB にすることを推奨しており、既に推奨値を超えている状態でしたので早めの対応が必要でした。 そのため、今回の対応ではシャード数を 2 -> 4 に増やしてデータを分散させることで各シャード毎のサイズを 10 〜 50 GiB 以内に収めました。 参考: Amazon OpenSearch Service ドメインのサイジング - Amazon OpenSearch Service リインデックスとは OpenSearch のシャード数設定はインデックス作成の際に行われます。既存のインデックスのシャード数を途中で変更することはできません。そのため、今回のシャード数切り替えのためにリインデックスを行いました。 リインデックスとは既存インデックスとは別に新しくインデックスを作成し、既存インデックスのデータをまるまる新しいインデックスにコピーすることです。この新しくインデックスを作成する際に、シャード数を 4 に設定することでシャード数切り替えの対応を行います。 新インデックスを作成します。その際に既存インデックスから更新したい設定値を新たに設定します。今回の場合はシャード数です。 既存インデックスから新インデックスに向けて Reindex API を実行します。 既存インデックスから新インデックスへエイリアスを変更し既存インデックスを削除します。 リインデックスの高速化 リインデックスを行う上で注意したい設定があります。それは refresh_interval です。refresh_interval はインデックスのドキュメント更新を検索に反映する操作の実行間隔になります。refresh_interval が 10 秒だった場合、下記の図のようにインターバルの間に起こった変更は次のインターバルにて検索ができるようになります。 refresh_interval の設定を無効にすることでリインデックスの実行時間を早く終わらせることができます。詳細は後述しますが、今回のリインデックス作業中はデータの更新を一時的に止めることで、新しくデータが投入されない状況にすることができました。そのため、refresh_interval の設定を無効にすることができました。 例として約 110 万のドキュメント数に対して refresh_interval を -1（無効）と 100 秒で比較検証したところ、-1 の場合は 5 分 50 秒だったのに対して 100 秒の場合は 11 分 19 秒と倍近くの差が出ました。 MiiTel における OpenSearch へのデータ登録の仕組み MiiTel Analytics で解析された応対履歴は Amazon RDS へ保存されます。OpenSearch へはこの Amazon RDS へデータが保存されたタイミングでデータが同期されます。 応対履歴を RDS へ保存/更新 保存/更新された応対履歴 ID を SQS に送信 Lambda が応対履歴 ID を SQS より取得 Lambda にて応対履歴を OpenSearch へ同期する API を呼び出す 同期 API のリクエストの応対履歴 ID を元に RDS より応対履歴を取得 取得した応対履歴を OpenSearch 用に変換し登録 今回のリインデックス作業では上図の定期実行される Lambda を一時的に止めます。それによりリインデックス中は上図の 3 〜 6 が止まり、OpenSearch へのデータ追加/更新が行われないのでデータの不整合を防ぐことができます。 また、上図の 1 〜 2 はリインデックス中も稼働しているので SQS には新規または更新された応対履歴の ID が溜まっていきます。これらの応対履歴はリインデックスが完了した後に Lambda を再稼働することで OpenSearch へ登録されますので、リインデックス中の応対履歴も取り零すことなくシャード数の切り替えが行えます。デメリットは一点で、データ同期を一時的に止めるのでリインデックス中は最新のデータを扱えなくなります。 *1 上記で説明してきたように、今回のリインデックスはサービスのダウンタイムなしで行えます。しかしながら最新のデータを扱えないままサービスを提供するのはあまり宜しくないため、顧客に事前にメンテナンス時間を通知し、その時間内にシャード数の切り替えを行いました。 データ数が多いのでリインデックスが完了するまでに約 8 時間も掛かりました。お客様にご協力いただいたおかげで refresh_interval を無効にすることができたのでこの時間で収まったことになります。もしも refresh_interval を 100 秒に設定していたら倍の 16 時間は掛かっていたかと思うと恐ろしいです。 まとめ 今回のシステム要件とデータ量の場合、ダウンタイムなしの約 8 時間でリインデックスが完了しました。しかし、近い将来にまた負荷を緩和するためのシャード数の切り替えを行わなければなりません。なぜなら、このリインデックスを行った当時のドキュメント数は約 6,600 万で現在は約 9,300 万弱とありがたいことに利用者は順調に増えているからです。 今回の対応が次回も丸々使えるかと言うと規模が増大しているため使えないと思います。しかし、今回の対応でシャード数切り替えやリインデックスに対する知見は得られたので、今後の Amazon OpenSearch の運用をより良くしていくために模索していきたいと思います。 リインデックスは、リインデックス中のデータ登録/更新/検索が行なえます。しかし、リインデックス中のコピー元のデータ登録/更新はコピー先へ反映されないため、コピー元とコピー先のインデックス内容に差異が生じます。 *1 : リインデックスは、リインデックス中のデータ登録/更新/検索が行なえます。しかし、リインデックス中のコピー元のデータ登録/更新はコピー先へ反映されないため、コピー元とコピー先のインデックス内容に差異が生じます。