Pages

Thursday, April 28, 2022

子供向けのスマートフォン、iPhoneとAndroidのどちらを選ぶべき?:子どもとスマホの関係(1/2 ページ) - - ITmedia Mobile

tahupedascabe.blogspot.com

 子どもに専用のスマートフォンを持たせると決めたら、次に気になるのは機種選びでしょう。iPhoneとAndroidのどちらを選ぶべきか悩みますね。また、新しいスマホを買う、中古スマホを買う、親のおさがりを渡すなどの選択肢もあります。さらにキャリアかMVNOかも悩みどころでしょう。

 まず、子ども世代にどのスマホが人気なのか、調査を見てみましょう。MMD研究所が2021年12月に発表した「2021年12月スマートフォンOSシェア調査」によると、10代男性が利用しているスマホのOSはiPhoneが69.5%、Androidが27.0%です。一方、10代女性はiPhoneが82.4%、Androidが13.2%と、圧倒的にiPhoneが人気です。ちなみに、20代も男女ともiPhoneが多く、若い世代はiPhoneを使っている人が多いことが分かります。

 実際に女子高生を取材すると、ほとんどがiPhoneを使っています。その理由は、ケースがかわいいから、AirDropが便利などですが、最も大きな理由は「みんながiPhone使っているから」。Androidを持っていた女子高生も、修学旅行を機にiPhoneに変えてもらうとウキウキしていたので、女子はいつかiPhoneを欲しがると思っていてもいいでしょう。

 ただし、もちろんAndroidユーザーも大勢います。周囲とOSが異なってもLINEやInstagramなどのアプリでつながれますし、Androidでは困るというシーンはほとんどないでしょう。親が子どもに使い方を教えるという点では、家族で同じOSにそろえておくと分かりやすくなりますね。

子どものスマートフォン 「2021年12月スマートフォンOSシェア調査」(MMD研究所)

 具体的な機種ですが、iPhoneはiOSのアップデートで旧機種でもそれほど変わりなく使えることから、最新にこだわる必要はないでしょう。子どもの小さな手でも使いやすいiPhone SEも良さそうです。

 Androidの場合は、個性豊かにさまざまな端末が出ています。子どもの年齢にもよりますが、防水・防塵(じん)性能や本体サイズを見て決めるといいでしょう。例えば、「AQUOS wish」は手ごろな価格で頑丈な作りをしています。

 また、故障時の対応も両者で異なります。iPhoneが故障した場合は、キャリアではなく、Appleの窓口に持ち込むか、配送で修理を依頼する必要があります。Androidは販売したキャリアで修理を受け付けてくれることがほとんどです。子どもが乱暴に扱って画面割れや水没が起きる可能性もあるので、チェックしておくといいでしょう。

 フィルタリングに関しては、iPhoneは「ファミリー共有」と「スクリーンタイム」、Androidは「ファミリーリンク」が提供されています。iPhoneを子に持たせる場合、親もiPhoneでなければファミリー共有などが利用できません。その場合は、キャリアのフィルタリングサービスに加入することになります。Androidは、親がiPhoneでもAndroidでもファミリーリンクを利用できます。

 ところで、キッズ向けのスマホがあればそれを買いたい人も多いと思います。スマホケースのメーカーでおなじみのHameeが、キッズ向けスマホも扱っています。

 「Hamic POCKET L」(Hamee)は3.0型のAndroidスマホで、初めてスマホを持つ人を想定した「Goエディション」が搭載されています。防犯ブザーが付いており、キッズケータイを思わせますが、保護者の許可があればアプリのインストールも可能です。カメラやアルバム、オリジナルの連絡アプリがインストールされています。通信キャリアはIIJが提供し、フィルタリングについては「ファミリーリンク」を設定します。先代からバッテリー容量が2倍となった2000mAhのバッテリーを備えています。

スマホは新品にする? キャリアはどうする?

 新品のスマホか、中古のスマホかはご家庭の状況や使い方によります。ちょうど親が買い替えようと思っていたのなら、今まで使っていたスマホを譲ってもいいですね。例えば、スマホは家のWi-Fiでしか使わせないといった場合、バッテリーの持ちが悪くなっていても、それほど影響はありません。ただし、親のスマホを譲る際には、キャリア決済情報などを全て消去しておきましょう。子どもが誤って課金してしまう事例が頻発しています。

 通信回線を3キャリアかMVNOにするかも迷いどころです。3キャリアの格安料金プランも若者をターゲットにしています。まずは家族が契約しているキャリアで、初めてのスマホキャンペーンや家族割などの割引プランを確認し、試算してみましょう。

 子どもの場合はWi-Fiでの運用がメインになることが多いので、データ通信量は少なめでも足りると思います。キャリアメールが必要になるケースは少なく、通話もLINEなどのアプリで行うため、あまり電話を使いません。となると、MVNOや格安料金プランで事足りる人も多いかと思います。

 トーンモバイルは見守りを重視した端末やプランを用意しています。トーンモバイルでは、ドコモショップで「TONE for Android」とスマートフォンの「TONE e21 rev.2」をセット販売しています。iPhone向けプランの「TONE for iPhone」も提供しています。

 TONE for AndroidとTONE for iPhoneは、アプリ制限やGPS見守り機能、自画撮り防止機能を持つ上に、特定の場所で端末をロックする「ジオロック」と、特定の時間帯で端末をロックする「端末時間制限」も備えています。トーンモバイルは独自の見守り機能を提供しているので、一度チェックしておくといいでしょう。

TONE for Android 見守り機能を充実させたオリジナルのAndroidスマートフォンを用意している「TONE for Android」

 筆者の場合、我が子のスマホデビューは中古スマホショップでiPhoneを購入し、MVNOのSIMで運用しました。その後、iPhoneは買い換えましたが、同じSIMを使い続けています。高校生でも特に支障はないようです。

 スマホ選びは、ご家族のスマホの状況によって大きく変わります。どのスマホが我が子向けなのか、価格も含めて検討してみてくださいね。次回はフィルタリングについて、さらに詳しくお話したいと思います。

Adblock test (Why?)


からの記事と詳細 ( 子供向けのスマートフォン、iPhoneとAndroidのどちらを選ぶべき?:子どもとスマホの関係(1/2 ページ) - - ITmedia Mobile )
https://ift.tt/BmKeyJp

Wednesday, April 27, 2022

Appleが提供するSwiftのUnified Logging Systemの概要 - InfoQ Japan

tahupedascabe.blogspot.com

原文(投稿日:2022/04/24)へのリンク

最近の一連の記事で、iOSだけに依らない開発者のMajid Jabrayilov氏は、ロギングの重要性に焦点を当ててきた。デバッガーで見つけるのが困難なバグの分析を可能にし、アプリを介してユーザの行動をよりよく理解するためである。

Xcodeデバッガーを使ってiOSアプリをテストすることは、アプリにバグがないことを確認するための妥当な良いアプローチかもしれない。一方で、これがシンプルに選択肢ではない場合もあるとJabrayilov氏は言っている。

たとえば、[バグ]はアプリを数日使用した後にのみ発生する場合があります。この場合、シミュレーターでアプリを実行して機能をテストしても意味がありません。ユーザがアプリケーションで何をしたか、そしてこの状況で、アプリケーションがユーザの操作にどのように反応するかを理解する必要があります。

Jabrayilov氏は、記事の中で、AppleのUnified Logging Systemを活用する手法について説明している。それにより、iOSアプリに適切なロギングシステムを構築するのと同じくらい簡単にできるようになる。

このアプローチの要はos.Loggerクラスである。このクラスでは、すべてのログエントリが所定のsubsystemcategoryの下にあるデバイスベースのシステムストアに保持される。Loggerは、tracenoticewarningcriticalなど、いくつかのレベルのログを提供する。ログエントリには、MacのConsole.appからアクセスできる。すべてのログ情報をConsole.appで簡単に読み取れるようにするために、iOS 14以降で利用可能なOSLogInterpolationポリシーを使うと便利だとJabrayilov氏は言っている。このポリシーには、配置、可視性、フォーマットなどを制御するオプションが含まれる。

AppleのUnified Logging Systemの興味深い機能は、ユーザのデバイスからログ情報を簡単にエクスポートできることである。これは、バグが本番稼働時のみに現れ、テスト中に再現できない場合に、本当に助かるものとなる。

この目的のために、カスタムOSLogStoreを定義する必要がある。これは、エントリカテゴリ、日付など、特定の基準に一致するすべてのログエントリのフィルタリングする役割を担う。Jabrayilovが示すように、OSLogStoreはアプリに簡単に統合できる。それによって、ユーザはボタンをタップしてログエントリをエクスポートし、オプションでそれを開発者と共有できるようになる。

まとめると、Jabrayilov氏は、iOSアプリにロギングを追加するための便利なテクニックについて説明している。興味がある場合は元の記事をお見逃しなく。サンプルコードを含んでおり、この概念の全てが詳細に説明されている。

作者について

Adblock test (Why?)


からの記事と詳細 ( Appleが提供するSwiftのUnified Logging Systemの概要 - InfoQ Japan )
https://ift.tt/Az7oxHp

Tuesday, April 26, 2022

ネットいじめ対策で、教育委員会・大学・デジタルアーツが連携 - 沖縄タイムス

tahupedascabe.blogspot.com ~尼崎市の児童生徒がネットいじめにつながるワードを選定、書き込みをブロックする取り組み事例を公開~

情報セキュリティメーカーのデジタルアーツ株式会社(本社:東京都千代田区、代表取締役社長:道具 登志夫、以下 デジタルアーツ、証券コード2326)は、兵庫県尼崎市教育委員会(教育長:白畑 優(しらはた まさる)、以下、尼崎市)による、Webセキュリティクラウドサービス「i-FILTER@Cloud」GIGAスクール版を活用したネットいじめ対策を4月27日に公開したことを発表します。

デジタルアーツの「見守りフィルター」でネットいじめにつながるNGワードをブロックし教師に通知、指導につなげる
尼崎市は2022年度、ネットいじめにつながるワードの書き込みをブロックする「i-FILTER@Cloud」GIGAスクール版の「見守りフィルター」の導入を検討しています。「見守りフィルター」とは、任意のワードで検索や書き込みをブロックし通知できるもので、尼崎市の児童生徒自身がネットいじめにつながるワードを選定し、尼崎市はそれを「見守りフィルター」で検出するワードとして設定します。

他人を傷つける言葉を使わないよう自分たちで決めたルールを守ることや、「見守りフィルター」でブロックされた際には教師がそれを指導につなげることが狙いです。このプロジェクトは主に尼崎市立教育総合センター 学校ICT推進課係長(2022年3月取材当時)の瀧本晋作氏と兵庫県立大学の竹内和雄准教授が進めています。

教師がNGワードを設定するのではなく、児童生徒にNGワードを考えさせる
尼崎市は、児童生徒に1人1台端末を配布するGIGAスクール構想で約3万台のタブレット端末を整備し、Webフィルタリングソフトとして「i-FILTER@Cloud」GIGAスクール版(以下、「i-FILTER@Cloud」)を導入しました。尼崎市は2022年度から「見守りフィルター」を活用してネットいじめにつながるワードをブロックする取り組みを始めようと検討しているところです。

尼崎市の特筆すべき点は、この「見守りフィルター」に登録するワードを教師など大人が設定するのではなく、児童生徒に考えさせて決める点にあります。竹内准教授は「教育委員会の生徒指導担当と情報担当の連携、大学の研究者と企業、今回の場合はデジタルアーツが連携していることは画期的なことです。他では聞いたことがありません」と強調します。

多くの教育委員会や学校では生徒指導担当と情報担当が分かれており、それぞれが単独で動く傾向にあります。尼崎市では2021年度に児童生徒がスマートフォンなどの使用に関するルールづくりを考える「尼崎市スマホサミット2021」を開催し、これをきっかけに教育委員会内の連携が密になりました。




スマホのルールづくりを考える「尼崎市スマホサミット2021」

この連携について竹内准教授は「ネットいじめは生徒指導担当と情報担当が一緒になって取り組まなければ対策が難しい問題です。従来、生徒指導が優先されていましたが、GIGAスクール構想で情報が逆転し、町田市の事件をきっかけにまた生徒指導優先に逆戻りしてしまい、チャット機能を使用禁止という自治体が出てきたり…と行ったり来たりしている状況です」と背景を語ります。

しかし「児童生徒は端末を使いながら光と影を学んでいかなければなりません。その上で機械による制御も重要です」(竹内准教授)といいます。

教師は「見守りフィルター」の通知から指導につなげられる
「見守りフィルター」の活用について、瀧本氏は「児童生徒がリアルな目線で選んだネットいじめにつながるワードを『NGワード』として、『見守りフィルター』の検出ワードに加えての運用を検討しています」といいます。竹内准教授は「NGワードの認識は大人と異なり、児童生徒だからこそ見えるものがあります。自分たちでルールを決められるため、責任感を持つことになりますし、自身も納得感が得られることから、ルールの順守にもつながります」といいます。

NGワードの書き込みが「見守りフィルター」で検出されると、教師はいつ・誰が・どんなNGワードで書き込みをしようとしたのかを確認することができます。竹内准教授は「実際の喧嘩であれば教師は介入することができますが、ネット上ではそれは難しいです。GIGA端末は文房具ですから、個人所有のスマホと違って教師は中身を見ることができます。せっかくツールを持っているのに、学校でチャットは一律禁止などとしていては指導の機会を手放していることにもなります。『見守りフィルター』があることによって教師も指導につなげることができるのです」と述べています。

尼崎市は市内全校に「学校管理者」の権限を与えて、各学校の実情に合わせた形で「i-FILTER@Cloud」を運用していく運用を始めています。これに加え、2022年度からは全市で効果的に「見守りフィルター」を活用していく方法についても検討していきます。

■尼崎市教育委員会導入事例の全文はこちら ▶ https://www.daj.jp/bs/case/case92/

「i-FILTER@Cloud」GIGAスクール版について
デジタルアーツのWebセキュリティクラウドサービス「i-FILTER@Cloud」GIGAスクール版は、GIGAスクール構想における1人1台端末を、教育の現場で安全にかつ円滑な学習ができるよう利用いただくために改良した学校用フィルタリングサービスです。国内導入シェアNo.1※の「i-FILTER」におけるフィルタリングデータべースをもとに、学習の現場に合わせたきめ細やかなフィルタリングルール設定が可能です。

※ 株式会社富士キメラ総研「2021 ネットワークセキュリティビジネス調査総覧」Webフィルタリングツール市場占有率(2020年度)(2021年9月発行)

本件に関するお問合わせ先
デジタルアーツ株式会社 広報担当 石井   TEL : 080-8750-0425 / E-mail : press@daj.co.jp
※新型コロナウイルス感染症拡大に伴う在宅勤務実施中のため、お電話でのお問い合わせは上記とさせていただきます

関連リンク
尼崎市教育委員会導入事例
https://www.daj.jp/bs/case/case92/

Adblock test (Why?)


からの記事と詳細 ( ネットいじめ対策で、教育委員会・大学・デジタルアーツが連携 - 沖縄タイムス )
https://ift.tt/4r9zApM

Thursday, April 21, 2022

日本旅行とジャスミーがブロックチェーンとエッジAIによるユーザー生成コンテンツ(UGC)活用に向けた実証実験を開始 - PR TIMES

tahupedascabe.blogspot.com

 
  • 実証実験の概要
ジャスミーと日本旅行はこれまで、ジャスミーのブロックチェーン技術をつかった個人情報活用サービスであるJasmy Personal Data Locker(以下「PDL」)を活用し、デジタルトランスフォーメーション(以下「DX」)に向けた様々な検討を重ねてまいりました。

この度、株式会社Archaic(本社:東京都渋谷区、代表取締役:横山 淳、以下「アルカイック」)とジャスミーとが共同開発中のAIエンジンを用いることで、日本旅行の旅行メディアサイトTripαにおけるメディア訴求力向上に向けた、新たな取り組みを行う事といたしました。

このAIエンジンは、これまで多くのインターネットサイトで用いられてきた協調フィルタリング等のレコメンド手法とは異なり、収集した情報から得られる個人の嗜好性を、全く異なるジャンルやサイト等のレコメンドに活用出来る仕組みです。

PDLに蓄積された、個々人それぞれの個性を表すデータと、上記AIをエッジ環境(手元のパソコン、スマートフォンなどの機器内)で利用することで、これまでにない安全なデータ利用と、それによるユーザー本位のアウトプットを実現することを目指します。

本実証実験となる日本旅行が運営する旅行メディアサイトTripαにおいては、旅行に関心があるユーザーや自らの旅行体験を発信するユーザーの情報によって、Tripαを訪れたユーザーに対して、慣れ親しんだ旅先の新たな魅力発見や、未だ見ぬ新たな旅への出会いを実現する、訴求力のあるメディア提供が実現できると考えております。

 

  • Tripαとは

あなたの旅に+αの情報を!
Tripα(トリパ)は、日本旅行が運営する旅行メディアサイトです。「旅のプロがお届けする旅行に役立つ情報」をコンセプトに、観光・グルメ・体験など、旅行に関するあらゆる情報を随時発信しています。旅行に出かける前や、旅行中ちょっと知っておくだけでもっとあなたの旅が豊かになるような+αの情報をお届けすることで、あなたの素敵な旅のお手伝いします。

Tripα公式サイト
https://www.nta.co.jp/media/tripa/

Tripα公式インスタグラム
https://www.instagram.com/tripa.official/

 

  • ジャスミー株式会社について
ジャスミー株式会社はIoTのプラットフォームを開発・提供する会社です。あらゆるモノがネットにつながる時、人々の生活に密着する「衣・食・住・動」が大きく変わります。誰もが簡単に安全にそして安心してモノを使うことが出来る仕組み(プラットフォーム)をつくり提供する、これがジャスミーの使命です。いま、私達の生活から生み出される大事なデータは限られた企業に占有されがちです。ジャスミープラットフォームは、本来の持ち主にデータの主権を取り戻し、個々のデータを安全安心に利用いただくことを目的のひとつとしています。その為、ジャスミーはIoTにブロックチェーン技術を融合させ、今までにない発想のもと業界・業種の垣根を越えて幅広く利用いただけるプラットフォームを準備して参ります。

ジャスミーのチームはエレクトロニクス、メカ、通信、デバイス、システムインテグレーター、デザイナー等、多種多様で豊かな経験を持つメンバーで構成され、世界中のお客様それぞれに最適なIoT プラットフォームを提供していきます。 

ジャスミー株式会社 公式サイト
https://www.jasmy.co.jp/

 

  • 株式会社日本旅行について
日本旅行は、1905 年創業の日本で最も歴史のある総合旅行会社です。これまで 117 年の長きに渡りツーリズムを事業の軸に据え、「旅行」を通じて多くのお客様の満足を想い、心豊かな人生の彩りを創るお手伝いをしてきました。ニューノーマルと言われる時代においても、顧客に寄り添う企業姿勢は変えることなく、アライアンスパートナーの皆様と事業を共創していくことを通じ、〝旅行業〟という枠に留まらない新たな価値の創造をする「顧客と地域のソリューション企業」へと進化します。次の時代に向け、当社はお客様の求める価値を実現する企業グループとして社会課題の解決に貢献してまいります。

 

  • 株式会社Archaicについて
AIの最新技術の学術的知見も持ちグローバルなAIベンダーで実績があり、ディープラーニングや人工知能システムの受託開発、受託研究開発のスペシャリスト集団です。

幅広いAI技術
・最適化問題、画像認識、自然言語認識など多様な技術を保有
・包括的なDX化支援(オペレーション最適化、院内作業の見える化)
・AI人物認識エンジン、リコメンデーションエンジンの無償提供可

世界的トップレベルのAIエンジニアが貴社のAI化を支援
・世界的AIコンテストのトップランカー、AI分野の大学准教授、東京大学を始め世界トップの大学でAIの研究実績のある人材
・IBM、アクセンチュアを始めグローバルなAIベンダーで実績を残したエンジニア
 

Adblock test (Why?)


からの記事と詳細 ( 日本旅行とジャスミーがブロックチェーンとエッジAIによるユーザー生成コンテンツ(UGC)活用に向けた実証実験を開始 - PR TIMES )
https://ift.tt/zCZTcMB

Wednesday, April 20, 2022

子どもに携帯電話を持たせる際の心配ごと、第1位は「長時間利用」=Soldi調べ= - ICT教育ニュース

tahupedascabe.blogspot.com

エイチームライフデザインは20日、同社の通信費・家計見直しサイト「Soldi(ソルディ)」が、24歳以下の子どもがいる保護者640人を対象に実施した、「子どもの携帯電話事情についての調査」の結果をまとめ発表した。

それによると、子どもが携帯電話を初めて持つタイミングについては、「小学1年生」18.1%が最も多く、以下、「小学6年生」12.7%、「小学3年生」と「中学3年生」の11.7%などが続いた。

子どもに携帯電話を持たせた理由を聞いたところ、1位は「緊急時の連絡のため」、2位は「入学や新学期に合わせて」、3位は「周りの友達で持つ子が増えてきたから」が挙げられた。入学などで新しく始まる環境に合わせて携帯電話デビューをしているようだ。

子どもに携帯電話デビューをさせた保護者に、「心配していること」を聞いたところ、1位は「携帯電話の長時間利用」50%、2位は「視力の低下」36%、3位は「学力の低下」29%という結果になり、保護者が子どもへの悪影響を心配していることが分かる。

心配ごとを解消するために行った「具体的な対策」を聞いたところ、1位は「フィルタリング(アクセス制限)機能」45%、2位は「プラン(料金)の制限」28%、3位は「何もしていない」24%だった。

このほか、「利用アプリの制限機能」23%、「位置情報監視(GPS)機能」22%など、様々な機能の活用と制限対策を行っていることが分かった。

一方で、携帯電話を「持たせている」保護者が最も心配している項目として挙げられた「利用時間制限」に関して、対策ができている保護者は約1割程度ということも分かった。

また、「子どもに携帯電話を持たせない理由」を聞いたところ、7割以上(76%)の保護者が「まだ携帯電話を持つには幼いと思うから」と回答。

小学校入学前から小学生・中学生・高校生・大学生と、世代を問わず「まだ携帯電話を持つには幼いと思うから」という回答が最多になったことから、子どもの年齢に関係なく、携帯電話を持たせるのは心配だという親心が垣間みえる。

また、子どもに携帯電話を持たせてない保護者に、「どういうことができたら携帯電話を持たせようと思うか」と聞いたところ、「アプリの利用制限」や「携帯電話の利用時間制限」、「位置情報の監視」、「不適切なサイトのフィルタリング」が多く挙げられた。

この調査は、同社の引越し比較・予約サイト「引越し侍」のユーザーで、24歳以下の子どもがいる全国の保護者640人を対象に、3月1日~24日にかけて、インターネットで実施。

関連URL

調査結果の詳細

「Soldi」

エイチーム

Adblock test (Why?)


からの記事と詳細 ( 子どもに携帯電話を持たせる際の心配ごと、第1位は「長時間利用」=Soldi調べ= - ICT教育ニュース )
https://ift.tt/OQSAnc8

Monday, April 18, 2022

IoT データの取り込みと可視化のための7つのパターン – ユースケースに最適なものを決定する方法 | Amazon Web Services - amazon.com

tahupedascabe.blogspot.com

この記事は 7 patterns for IoT data ingestion and visualization- How to decide what works best for your use case の日本語訳です。

モノのインターネット(IoT)を始めたばかりでも、すでに数百万台の IoT デバイスが接続されていても、IoT データから抽出される価値を最大化する方法を探しているのではないでしょうか。IoT デバイスのデータには、報告されたテレメトリデータ、メタデータ、状態、コマンドとレスポンスの中に、豊富な情報が含まれていることがあります。しかし、適切なレポート作成および可視化ソリューションを持つことは、業務効率を最大化し、ビジネス成果を実現するために必要な洞察を得るための鍵となります。

それゆえ、AWS Well-Architected のようなフレームワークは、管理、パフォーマンス、コスト、および運用の観点から最適なソリューションを選択するのに役立ちます。例えば、リアルタイムでデータを提供できるレポートと可視化ソリューションを探しているかもしれません。あるいは、完全にカスタマイズ可能で、インサイトを検索できるソリューションをお探しかもしれません。

このブログ記事では、AWS の様々な IoT レポート作成と可視化ソリューションについて説明します。リアルタイム、ニアリアルタイム、スケジュールに沿ってレポートを提供できる7つの異なるアーキテクチャパターンを紹介します。さらに、各ソリューションのユースケース、更新頻度、データ取り込みプロセス、アーキテクチャ、および複雑さに関するデータポイントも提供します。

アーキテクチャーのパターン

下図はすべてのアーキテクチャパターンを集約したものであり、各パターンの詳細は以降のセクションで説明します。

パターン1:AWS IoT Greengrass ストリームマネージャー

概要

AWS IoT Greengrass のストリームマネージャーは、大量の IoT データを AWS クラウドに送信することをより簡単かつ信頼性の高いものにします。ストリームマネージャーは、ローカルでデータストリームを処理し、自動的に AWS クラウドにエクスポートします。この機能は、機械学習(ML)推論などの一般的なエッジシナリオと統合され、データは AWS クラウドまたはローカルストレージにエクスポートされる前に、ローカルで処理および分析されます。ストリームマネージャーは、接続が断続的または制限されている環境でも動作するように設計されています。使用できる帯域幅、タイムアウトの動作、およびコアの接続または切断時にストリームデータをどのように処理するかを定義することができます。

メトリクスと分析

ストリームマネージャーは、以下の AWS の主要な出力先へのエクスポートをサポートしています。

  • AWS IoT SiteWise: AWS IoT SiteWise は、産業用機器からのデータを大規模に収集、整理、分析することができます。
  • Amazon Kinesis Data Streams: Kinesis Data Streams は、大容量データを集約し、データウェアハウスやマップリデュースクラスターにロードするためによく使用されます。
  • AWS IoT Analytics: AWS IoT Analytics を使用すると、データに対して高度な分析を行い、ビジネス上の意思決定や機械学習モデルの改善に役立てることができます。
  • Amazon S3 オブジェクト: Amazon S3 を使用して、大量のデータの保存と取得を行うことができます。

レポート作成

レポートは、使用する AWS サービスによって異なります。例えば、AWS IoT SiteWise パターンではリアルタイムモニタリングのために AWS IoT SiteWise Monitor を、Kinesis Data Firehose パターンではレポートのために QuickSight を使用することがしばしばあります。

なぜこのパターンが有用なのか

  • AWS IoT Core が提供するフリート管理やモニタリング機能を必要としない、またはデータを他のサービスにルーティングする前にエッジでデータを修正する必要がないシステムにとって、これは素晴らしいコスト効率の高いソリューションとなりえます。
  • カスタムの組込みオフライン管理とバッファリング最適化をサポートするため。IoT アプリケーションは、ストリームごとにストレージの種類、サイズ、データ保持のポリシーを定義し、ストリームマネージャーがストリームを処理およびエクスポートする方法を制御することができます。

パターン2:AWS IoT SiteWise (+ AWS IoT SiteWise Monitor)

概要

デバイスにインストールされた AWS IoT Greengrass ソフトウェアは、オープンソースのエッジランタイムとクラウドサービスを提供し、インテリジェントなデバイスソフトウェアの構築、展開、管理を支援します。AWS IoT SiteWise コンポーネントを使用すると、ローカルデバイスと機器データを AWS クラウド上の AWS IoT SiteWise のアセットプロパティに送信するために Greengrass と統合することができます。AWS IoT SiteWise Edge ソフトウェアを通じて、オンプレミスで簡単に機器データを収集、整理、処理、監視することができます。

メトリクスと分析

AWS IoT SiteWise は、機器とプロセスのパフォーマンスメトリクスの計算をサポートします。これらのメトリクスは、機器の問題、生産ギャップ、品質欠陥など、さまざまな種類の無駄を特定するのに役立ちます。AWS IoT SiteWise のデータは AWS IoT Core で利用でき、AWS IoT Core のルールを介して AWS IoT Analytics や Amazon Kinesis などの他の分析サービスで利用することが可能です。

レポート作成

AWS IoT SiteWise モニターは、AWS IoT SiteWise にすでに取り込まれモデル化されたアセットからデータを自動的に発見し、可視化することができます。コードを書くことなく、フルマネージドのウェブアプリケーションをすぐに提供します。

AWS IoT SiteWise for Grafana プラグインは、AWS IoT SiteWise が AWS クラウドに保存したデータを Grafana ダッシュボードで監視することを可能にします。

なぜこのパターンが有用なのか

  • 製造業のオペレーションの改善: 製造ライン、組み立てロボット、工場設備からのパフォーマンスメトリクスを監視し、改善の機会を発見して対処します。
  • 資産のメンテナンスを最適化: 過去とニアリアルタイムのデータを使用したリモート資産監視により、機器の問題をより迅速に防止、検出、解決します。
  • 資産データのライブトレンドチャートの表示(ノーコード、フルマネージドウェブアプリケーション)

パターン3:AWS IoT Core + AWS IoT Analytics + Amazon QuickSight

概要

AWS IoT Core は、接続されたデバイスがクラウドアプリケーションや他のデバイスと簡単かつ安全にコミュニケーションすることを可能にします。AWS IoT Core を使用すると、アプリケーションは、すべてのデバイスを追跡し、それらがオフラインであっても、常にコミュニケーションすることができます。デバイスから収集したデータは、MQTT メッセージ経由で AWS IoT Core に送信でき、IoT ルールを使用して、データの分析のために AWS IoT Analytics にデータを取り込むことができます。

メトリクスと分析

AWS IoT Analytics は、IoT デバイスからのデータを分析するために必要なステップを自動化します。AWS IoT Analytics は、IoT データをフィルタリング、変換、拡張してから、分析用に時系列データストアに保存します。デバイスから必要なデータのみを収集し、数学的変換を適用してデータを処理し、デバイスの種類や場所などのデバイス固有のメタデータでデータを拡張してから保存するよう設定できます。その後、ビルトインの SQL クエリエンジンを使ってクエリを実行することでデータを分析したり、より複雑な分析や機械学習の推論を実行したりすることができます。

レポート作成

AWS IoT Analytics では、Jupyter Notebook との連携により、高度なデータ探索が可能です。また、AWS IoT Analytics は、Amazon QuickSight との統合により、データの可視化を可能にします。Amazon QuickSight は、こちらのリージョンで利用可能です。

なぜこのパターンが有用なのか

  • 使い勝手の良さ: AWS IoT Analytics は、AWS IoT Core と非常によく統合されており、IoT データの収集、処理、保存、分析、構築を支援します。完全にサーバーレスでローコード(Lambda で拡張可能)です。
  • 予知保全: AWS IoT Analytics は、強力な予知保全モデルを簡単に構築し、デバイス群に適用するための事前構築されたテンプレートを提供します。
  • 包括的な分析の実施: AWS IoT Analytics は、AWS IoT レジストリやその他のパブリックデータソースを使用して、IoT デバイスデータをコンテキストメタデータで自動的に拡張できるため、時間、場所、温度、高度、その他の環境条件を考慮した分析を実行することができます。
  • 異常検知の自動化: AWS IoT Analytics では、Amazon SageMaker を使用して異常検出ワークフローを自動化し、ML ワークフローによるインサイトを得ることができます。コンテナ化された Jupyter ノートブックを AWS IoT Analytics で使用する方法については、こちらで詳しく説明しています。

パターン4:Amazon Timestream

概要

このパターンでは、まず AWS IoT Core に時系列データを公開し、次にビルトインの IoT ルールによって Amazon Timestream にデータをプッシュし、様々なダッシュボードオプションを使用してデータを可視化することができます。

メトリクスと分析

Amazon Timestream の IoT ルールは、MQTT メッセージから Amazon Timestream データベースにデータを書き込みます。その後、Amazon QuickSight のようなツールを使用して、データのクエリと可視化を行うことができます。詳細については、Timestream ルールアクションを参照してください。

Timestream のためのヒント: DB への書き込み回数を最適化したい場合は、こちらに記載されているバッチ書き込みのアプローチに従ってください。

レポート作成

Amazon QuickSight とともに、Amazon Managed Grafana をダッシュボードとアラートツールとして使用することもできます。詳しくは Timestream-Grafana integration を参照してください。

なぜこのパターンが有用なのか

  • このパターンは、平滑化、近似、補間などのデバイスデータの分析機能を実行しようとしている場合に便利です(Amazon Timestream によるビルトインサポート)。例えば、スマートホーム機器メーカーは、Amazon Timestream を使用して、デバイスセンサーから動きや温度データを収集し、動きのない時間範囲を特定して補間し、消費者が省エネのために暖房を弱めるなどのアクションを取るように警告することができます。

パターン5:AWS IoT Core + Amazon Kinesis + Amazon QuickSight

概要

このパターンでは、Amazon Kinesis と統合された AWS IoT Core にデータを公開することから始め、リアルタイムで大容量のデータを収集、処理、分析することができます。データは Amazon QuickSight を使用して可視化することができます。

メトリクスと分析

Amazon Kinesis Data Analytics を使用すると、ストリーミングデータから実用的な洞察を得ることができます。Amazon Kinesis Data Analytics for Apache Flink を使用すると、Java、Scala、SQL を使用してストリーミングデータを処理および分析することができます。このサービスでは、ストリーミングソースに対してコードを作成・実行し、時系列分析の実行、リアルタイムダッシュボードの提供、リアルタイムメトリクスの作成が可能です。

レポート作成

レポート作成には、Amazon QuickSight を使用し、バッチおよびスケジュール式のダッシュボードを作成することができます。よりリアルタイムのダッシュボード機能が必要な場合は、Amazon OpenSearch と OpenSearch Dashboards パターンを使用することができます。

なぜこのパターンが有用なのか

  • もしあなたのアプリケーションが高帯域幅のストリーミングデータポイントを含むなら、このパターンはその高帯域幅とリアルタイムのストリーミングデータを分析する能力を提供し、実用的な洞察を導き出すことができるようにします。

パターン6:Amazon OpenSearch Service + OpenSearch Service Dashboards/Amazon Managed Grafana

概要

このパターンでは、まず AWS IoT Core にデータを送信し、次にビルトインの IoT ルールによって Amazon OpenSearch Service にデータを送信し、様々なダッシュボードオプションを使用してデータを可視化することができます。

メトリクスと分析

OpenSearch IoT ルールアクションは、MQTT メッセージから Amazon OpenSearch Service ドメインにデータを書き込みます。その後、OpenSearch Dashboards のようなツールを使用して、OpenSearch Service のデータをクエリして視覚化することができます。詳細については、OpenSearch ルールアクションを参照してください。

レポート作成

Amazon OpenSearch Dashboards の使用とともに、ダッシュボード作成オプションとして Amazon Managed Grafana を使用することもできます。Amazon Managed Grafana では、Grafana ワークスペースコンソールで AWS データソース設定オプションを使用して、Amazon OpenSearch Service をデータソースとして追加することができます。設定方法の詳細については、Grafana plugin for OpenSearch を参照してください。

なぜこのパターンが有用なのか

  • デバイスの健全性またはデバイスのメトリクスを監視することを検討している場合、このパターンによって、その裏にあるデータを検索し、カスタム設定を実行し、リアルタイムのダッシュボードアプリケーションを手に入れることができます。

パターン7:AWS IoT Core + AWS Lambda + Amazon DynamoDB + Amazon QuickSight / Custom Dashboards

概要

このパターンでは、AWS LambdaAmazon DynamoDBAWS AppSync、お好みのカスタムダッシュボードを使用して、AWS IoT Core 経由で IoT デバイスから直接送信されるリアルタイムのテレメトリデータを可視化することができます。

AWS IoT Core の IoT ルールは、AWS Lambda 関数に MQTT メッセージを送信します。Lambda 関数はメッセージをフォーマットすることができ、その後、AWS AppSync GraphQL ミューテーションを実行します。ミューテーションの呼び出しは、Amazon DynamoDB テーブルにメッセージを保存し、カスタムダッシュボードにリアルタイムでメッセージをブロードキャストします。カスタムダッシュボードは、更新されたメッセージを受信する AWS AppSync サブスクリプションを購読します。このパターンについて、詳しくはこちらでご覧いただけます。

メトリクスと分析

IoT データは、Amazon DynamoDB テーブルに格納されます。高度な分析を行うには、データを分析プラットフォームにエクスポートする必要があります。これは、Amazon S3 にデータを移行するデータパイプラインを構築し、Amazon Athena を使用して、高度な分析を実行することで実現できます。詳細については、高度な分析と可視化を実行するAmazon Athena のブログ記事を参照してください。

レポート作成

AWS Amplify を使用して、カスタムダッシュボードとモバイルアプリケーションを簡単に作成し、立ち上げることができます。カスタムダッシュボードは、iOS、Android、React Native、Flutter、React、Vue などの AWS Amplify Framework を通じて AWS AppSync と通信することができます。

なぜこのパターンが有用なのか

  • このパターンは、IoT データがカスタムリアルタイムダッシュボード上で変化したら、すぐにエンドユーザーに配信する必要があるユースケースに最適です。ユーザーは、カスタムで設定可能なフロントエンドクライアントを使用してデータにアクセスすることができます。
  • このパターンは、消費者が家電製品をリアルタイムで監視するためのモバイルアプリケーションにも最適です(オンデマンドでのみ有効化される場合)。

考察と注意点

  • 万能のソリューションはありません: この記事で紹介されているすべてのアーキテクチャパターンは、最も実現可能なパスにフォーカスしています。それぞれのユースケースは異なるので、ほとんどのパターンでは、他の関連するサービスを追加して、機能を追加したり、欠点を克服したりするために微調整することができます。もし、どのパターンも要件を満たさない場合は、直接呼び出しを許可し、AWS サービス(AWS IoT サービスを含む)と統合するためのクレデンシャルプロバイダのパターンを見てください。
  • 費用について: どのパターンにも独自のコストモデルがあり、アプリケーションのデバイスの数やデータ量によって大幅に変わる可能性があります。パターンを選択する際には、これらの要素を考慮することが重要です。
  • リージョン固有のサービス: すべてのサービスがすべてのリージョンで利用できるわけではないので、パターンを選択する前にサービスを確認する必要があります。

まとめ

この投稿では、AWS 上で IoT データのレポートと可視化ソリューションを構築するためのさまざまなアーキテクチャパターンを紹介しました。また、各パターンがどのように異なるニーズや要件に対応できるかを説明しました。リアルタイムレポート、リアルタイム分析、または履歴トレンドレポートが必要な場合に応じて、ビジネスニーズに沿ったソリューションを選択してください。

AWS IoT サービスでクラウドジャーニーを始めましょう

著者について

Umesh Kalaspurkar

Umesh Kalaspurkar は、ニューヨークを拠点とする AWS のソリューションアーキテクトです。20年以上にわたり、企業や新興企業におけるデジタルイノベーションとトランスフォーメーションプロジェクトの設計と実施に携わってきた経験を持ちます。顧客が課題を発見し、それを克服するのを支援することにやりがいを感じています。仕事以外では、父親であること、スキー、旅行などを楽しんでいます。

Ameer Hakme

Ameer Hakme はペンシルバニアに拠点を置く AWS ソリューションアーキテクトです。北東部の独立系ソフトウェアベンダーを対象に、AWS クラウド上でスケーラブルかつモダンなプラットフォームの設計と構築を支援しています。余暇にはバイクに乗ったり、家族と過ごしたりしています。

Ravikant Gupta

Ravi Gupta は AWS のエンタープライズソリューションアーキテクトです。熱狂的な技術愛好家であり、お客様と一緒に仕事をし、革新的なソリューションの構築を支援することに喜びを感じています。IoT と機械学習を専門分野としています。余暇は家族と過ごすことと、写真を撮ることを楽しんでいます。

この記事はソリューションアーキテクトの三平が翻訳しました。

Adblock test (Why?)


からの記事と詳細 ( IoT データの取り込みと可視化のための7つのパターン – ユースケースに最適なものを決定する方法 | Amazon Web Services - amazon.com )
https://ift.tt/Ppuvykt

Sunday, April 17, 2022

NVIDIAより強力!? 3960円のノイズ除去プラグイン「Clarity Vx」を試す【藤本健のDigital Audio Laboratory】 - AV Watch

tahupedascabe.blogspot.com
Waves Audioのプラグイン「Clarity Vx」

先日、「NVIDIA Broadcast」というNVIDIA提供の無料ソフトを利用したノイズ除去についてレポートした(記事参照)。同ソフトは無料とはいえ、NVIDIAのそこそこハイスペックなGPUを搭載したPCを使わなければならないが、同様のリアルタイムノイズ除去をCPUパワーで行なうソフトが先日話題を集めた。それが、イスラエルのWaves Audioが開発した「Clarity Vx」というプラグインだ。

現在、発売記念プライスとして3,960円という手ごろな価格で販売されていたので、NVIDIA Broadcastと比較してどのくらいの差があるのか試してみた。その結果、おそらくClarity Vxのほうが優秀と思われる性能であることが分かった。ただ、使い勝手で気になる点もあったので、合わせてレポートしていこう。

強力なノイズ除去性能。NVIDIA Broadcastよりも声質変化が少ない

イスラエルのソフトというと、軍需系ソフト? と思う方も少なくないと思うが、WavesはDTMをある程度経験ある方なら知らない人はいないほど、著名な音楽制作専業のメーカーである。コンプレッサやマキシマイザ、イコライザほか、数多くのエフェクトプラグインを開発するメーカーであり、プロからアマチュアまで数多くのユーザーが利用している。国内ではメディア・インテグレーションが輸入代理店をしている。

さまざまなエフェクトプラグインをラインナップする

そのWavesが先日発売したのが、冒頭で紹介した「Clarity Vx」と、その上位版の「Clarity Vx Pro」だ。メディア・インテグレーションの情報を見ると、通常価格はそれぞれ19,030円、101,970円と、結構な価格なのだが、現在発売記念のイントロプライスということで3,960円(79% OFF)、32,868円(68% OFF)で提供されている。Wavesによると、Clarity VxとClarity Vx Proの違いは機能の有無であり、ノイズ除去の性能に関しては「まったく同じである」という。

上位版の「Clarity Vx Pro」

そこで、まずは安価なClarity Vxを中心に使っていく。

最初に、先日NVIDIA Broadcastで行なった実験と同じヘアドライヤーを用いたノイズ除去を試してみた。とりあえず、以下の動画をご覧いただきたい。

Waves Clarity Vxオーディオ・ノイズリダクションテスト1

いかがだろうか? ドライヤーをオンにすると、声が盛大なノイズに埋もれてしまうのだが、ノブを0の状態から少しずつ回していくと、声質はほとんど変わらず、ノイズだけが消えていくのがお分かり頂けるだろう。

ノブを真上の50%程度のところに持っていくと、ノイズの大半は抑え込まれている。もちろん、この状態でドライヤーを遠ざけたりしているわけではなく、ドライヤーの音量は一定だ。ただ、ヘッドフォンで聴くと、50%の状態ではまだノイズの音は認識でき、70%、80%、90%と上げていくとノイズは消えていくが、まったく聴こえないわけではない。

約70%の状態

しかし100%にすると、ノイズは完全に消え去り、声が出ていない部分では完全に無音。この時でもNVIDIA Broadcastのときのような声質の劣化はあまりなく、かなり原音に近いまま残っている。ノブを元の状態に戻していくと、またドライヤーの音が聴こえてきて、0まで持ってくると声が完全に埋もれてしまうこともわかるはず。ここまでキレイに除去できるのは驚きだ。

続いて、ドライヤーではなく、マイクのそばでiPhoneから音楽を鳴らしながらしゃべってみたらどうなるか。その実験が以下のビデオだ。

Waves Clarity Vxオーディオ・ノイズリダクションテスト2

ドライヤーの場合は比較的単純なホワイトノイズに近い音だったが、より複雑なノイズと思われる音楽に変えても、ほぼ同様の効果が得られているのがわかるだろう。

AIパワーでリアルタイムにノイズを除去する

どのような実験を行なったのか、少し解説していこう。

Clarity Vxはプラグインで動作するソフトであり、リアルタイム処理を可能にするもの。まさに入ってきた音に同ソフトを通して出すと、ノイズが消えるフィルターとして機能する。

動作環境としてはWindowsのVST2、VST3、AAX、そしてMacのVST2、VST3、AAX、AudioUnitsのそれぞれで動く。これらが利用できるDAWに組み込んで使うことで、リアルタイムに入ってくるマイク入力をその場でノイズレスにすることができる。先日のNVIDIA Broadcastと異なり、スタンドアロンで動くわけではなく、あくまでもプラグインとして使うためホストアプリが必要だ。

実験には、Cubaseを使用した

今回はWindows上のCubaseで使っているが、リアルタイムでの動作とはいえ、処理時間に10msec程度は要するようだ。

実際、オーディオインターフェイスのバッファサイズを16 Sampleや32 Sampleなどの設定にすると、うまく機能せず、逆にブチブチといったノイズが追加されてしまう。そこで、実験では48kHzのサンプリングレート、512サンプルとやや大きめのバッファサイズとしている。入力音をモニターすると、20msec程度のディレイがかかった状態で自分の声が聴こえるが、この程度であればほとんど違和感はない。

実験では48kHzのサンプリングレート、512サンプルとした

先ほどのビデオからもわかる通り、ワンノブで操作できるのが非常にわかりやすく、50%程度まで上げれば、大半のノイズは抑え込むことができる。徹底的にノイズを消すのであれば、100%に設定するのがいいのだろうが、やはりある程度は声質にも影響を与えるため、50%程度での運用がお薦めだ。

先ほどの“ドライヤー”と“音楽”のノイズ除去実験で変更していたのがNEURAL NETWORK設定。ドライヤーでは「Broad 1」としていたが、音楽では「Broad 2」としている。

音楽では、NEURAL NETWORK設定を「Broad 2」にしている

Wavesの説明によると、Broad 1は「複数の音声が録音されている場合、主音声と副音声の両方を保存するのに適しています」とあり、Broad 2は「ノイズがひどい場合は、また、複数の音声が録音されている場合、主音声と副音声を分離するのに適しています」と記載されていた。

当初は音楽でも、Broad 1で行なったのだが、若干ノイズ除去の具合が十分でなかったため、Broad 2に変えたところ、より効果的にノイズを取ることができた。

ただ、このBroad 2の場合でも、100%にすると、声の切れ際などに若干音楽が入り込むのが分かる。やはり完全分離ができないケースがある、ということなのだろう。そのため、完全にシャットアウトさせるより、50%かせいぜい80%程度に留めておくのが効果的と思う。

では、なぜここまでキレイにノイズと声を分離できるのかというと、周波数帯でフィルタリングする従来の仕組みではなく、AI技術を利用しているからだ。AIの活用という点では、NVIDIA Broadcastと共通するが、Wavesでは「Waves Neural Networksエンジン」というものを使い、何がボイスで、何がノイズなのかを深層学習で理解させているという。

具体的には「何十万ものボーカル録音のオーディオファイルを供給され、機械学習と細心の注意を払った人間の評価を組み合わせて、ボイスとアンビエンスの違いを認識するように訓練されている」とのこと。従来のノイズリダクションは、ノイズとともに原音も削り取られるため、ノイズを取れば取るほど原音の劣化が激しいが、Clarity VxはAI技術を活用することで、ノイズを除去しながらも原音を維持しているわけだ。

上位バージョン「Clarity Vx Pro」も試す

前述した通り、上位バージョンとして「Clarity Vx Pro」が存在するが、これは何が違うのだろうか。

下記の写真がメイン画面なのだが、Clarity Vxと違い、少し複雑になっている。画面上部にはFFTが表示されており、声の部分と、ノイズの部分が分離される形で表示されている。

「Clarity Vx Pro」のメイン画面

基本的な使い方はClarity Vxと同じで、画面下中央のノブを回していくだけだが、真上に向けた状態がClarity Vxでいう0%の状態になっていて、右に回していくとClarity Vxと同じ動作をする。反対に左に回していくと、声が消え、ノイズというかアンビエンス成分だけが聞こえるようになる。つまり、先ほどの例でいうと、ドライヤーの音だけを取り出したいとか、音楽だけを取り出したい場合は左にノブを回していけばいいのだ。

アンビエンス成分だけを聞こえるようにした状態

さらに画面下にある「ADVANCED CONTROL」というボタンをオンにすると、上のFFT画面が4バンドに分割され、下部にいくつかのパラメータが表示される。4バンドのほうは、周波数帯ごとの処理する/しない、どのくらい強く処理するか、といった設定ができ、そのバンド幅を調整することもできる。まさに従来からの手法を重ね合わせることで、より効果的に使おうというものなのだ。

「ADVANCED CONTROL」ボタンをオンにした状態

ほかにも、反射音に対する効果を調整する「REFLECTIONS」、各バンドごとにどのくらいかけるかを調整する「PROCESS AMOUT」、アンビエンスを完全にシャットアウトする際に利用する「AMBIENCE GATE」などが用意されている。各種パラメータを追い込んでいく場合は、Clarity Vx Proがよさそうだが、ライトに利用するのであれば、Clarity Vxで十分のような気もする。

Clarity VxはDAW利用が必須。OBSでの利用ができない

ところで、こうしたノイズリダクションは、さまざまなシーンで利用できるが、やはりネット配信などで利用したい、という人は多いだろう。VST2プラグインで使えるので、OBSで利用できるのでは? と思ったのだが、結論からいうと、直接は利用できなかった。

実はWavesのプラグインはすべてライセンス管理されているため、一般的なVST2プラグインと扱いが違うのだ。Windowsであればdllファイル、MacであればvstファイルがVST2プラグインの本体プログラムとなるのだが、WavesのプラグインはどれでもWavesShell-VSTというファイル名になっており、これを経由して各プラグインを動作させる仕組みとなっている。ところがOBSはこれを使うことができず、動作しないのだ。

WavesShell-VSTというファイル名になっている

裏ワザがないかといろいろ試してみたものの、どうも無理そう。先ほどの実験映像はCubase Pro 12でリアルタイムに動かしたものなので、やはりVSTホストの問題と思われる。

となると、やはり間にDAWを介すしか方法はなさそうだ。ちょっと接続が煩雑にはなるが、2台のPCを使うか、2つのオーディオインターフェイスを接続するか、またWindowsであれば以前紹介したバーチャルドライバ「Voice Meeter Banana」を使うことで連携させることができる。Voice Meeter Bananaは、いろいろなことができるソフトであるだけに、接続がやや煩雑にはなるが、ハードウェアコストをかけずに使えるという面では大きなメリットがあるだろう。

接続がやや煩雑になるものの、バーチャルドライバ「Voice Meeter Banana」を使うことで連携させることができる

以上、Waves Audioのリアルタイム・ノイズリダクション「Clarity Vx」を取り上げたが、いかがだっただろうか。プラグインで、かつDAWをホストにしないと使えないという制約はあるものの、非常に効果的なソフトなので、使ってみる価値は高いと思う。

Adblock test (Why?)


からの記事と詳細 ( NVIDIAより強力!? 3960円のノイズ除去プラグイン「Clarity Vx」を試す【藤本健のDigital Audio Laboratory】 - AV Watch )
https://ift.tt/E7nm1Dp

Friday, April 15, 2022

メタバースブームに求められる、企業のパーパス・リーダーシップ - Sustainable Brands Japan

tahupedascabe.blogspot.com

Aaron Pickering

仮想空間「メタバース」のゴールドラッシュに参入する企業は、これまでの多くの急成長産業と同じく、社会への影響よりも利益を最優先する可能性がある。新たな産業が誕生し、その初期段階から、企業がブランド・パーパスやESG戦略を積極的に取り入れてきた事例はまだ多くはない。現在湧き上がるメタバースブームにおいて、企業は時代に求められる持続可能な事業の在り方を選択できるのか。米クリエイティブ・コンサルタント企業ヘッドスタンドの役員でジョージ・ワシントン大学非常勤准教授のアーロン・ピッカーリング氏が解説する。(翻訳=梅原洋陽)

ここ1年ほど、バーチャルな世界が子どもたちに与える影響について絶望を感じ、そして正直に言うと、ある種の恐怖さえ感じてきた。パンデミックが起きた当初、若者のスクリーンを見る時間が増えることによる悪影響についての不安は増し、そしてそれが現実のものになったことも多かった。新型コロナウイルス感染症による影響を受け始めて3年が経ち、登校できるかがはっきりしない日々が続くことで、わが家の未就学の子どもたちが、バーチャルな世界に慣れ、対面での誕生日会や外での遊び、そして図書館に行く回数が減っていくのを感じている。

一方で、世界中で数百万人もの学生が遅れをとり、孤立や不安、そして恐れによって次世代の若者の精神的健康が損なわれている現状を私たちは目の当たりにしている。子どもたちがオンラインで過ごす時間が増えるほど、いじめや好ましくない行為のリスクが増加する。

AIを使い、有害なオンラインコンテンツを子どもが見られないようフィルタリングを行うL1ght社によると、ロックダウンの間、オンラインチャットにおいて若者の憎しみが70%も増加したという。

これまでなら、子ども時代の重要な体験として扱われていたものが疑問視され始めている。教育制度が急速に変化する社会における優先順位と予測不可能な未来への対応を重視することで、青少年のスポーツは衰退し、多くの課外活動は二の次になっている。

このような背景の中で、まるでまだ問題が足りていないかのように、メタバースがブームとなりやってきている。メタバースが今後どのような存在になるかを定義するチャンスは私たちにもまだ残されてはいるものの、メタバースの一攫千金に群がる多くの企業はこれまでの多くの新興産業と同様に、ユーザーへの影響に思いを馳せることはないだろう。メタバースの根本的なあり方を意識的に構築することは私たちの責任である。しかし、多くの産業や文化の変化と同様に、主導権を握る企業が最終的にあるべき形を決定してしまうだろう。

メタバースの課題

革新的な企業がこのブームをけん引することは良い結果につながることもあり得る。ただしそれは意図的に、さらに一貫して自社の掲げるパーパス(存在意義)に沿った意思決定を行い、そしてマーケットに新製品やサービスを提供する際に、積極的にESGリスクを特定し、緩和しようとする場合に限る。

これはビジネスリーダーが「アウトサイドイン」と「インサイドアウト」について考える機会だ。この進化する産業において「どのようにパーパスを見つけるのだろうか」と問いかけるのである。企業ブランドは、「この新しい形のインターネットは何を必要とし、私たちが独自に提供できるのは何か」を問うことができる。そうすることで、企業は利益とパーパスを共に追求でき、より持続可能な形でメタバースの進化に貢献することができる。

従来は、産業の初期段階において、ブランドパーパスとESG戦略を積極的に取り入れることはほとんどなかった。今回は最初から組み込めるまたとない機会なのだ。ビジネスリーダーも消費者も、歴史が繰り返されるのを眺めるのではなく、より良いことをすべきだ。すでに、データプライバシーやセキュリティ、知的財産権の保護やアクセシビリティ、ハードウェアインフラの環境負荷など、メタバース関連の課題が明らかになっている。

簡単に言うと、メタバースはインターネットの進化系のことである。次のインターネットの姿とはどのようなものだろう。この問いは、あらゆる人にとっての心配事であり、同時に関心事であるだろう。

メタバースの可能性に注目すべきさらなる理由は、私たちがすでにその中で生活をおくっているという事実だ。例えばロブロックスは毎日約5000万人が利用する大手ゲームコミュニティだ。このようなコミュニティは他にも多数存在し、さらに増え続けている。つまり、ゲーマーやソーシャルメディアの利用者は、自覚しているかどうかに関わらず、すでにメタバースに足を踏み入れているのだ。

世界は、次のインターネットに対応する準備はできているだろうか。ソーシャルメディアを含むインターネット・プラットフォームが、若者や私たちの文化に及ぼす潜在的な負の影響に関する研究はまだ表面的なものしかない。例えば、10代の若者の認知能力の発達や心理的な幸福にソーシャルメディアがどのような悪影響をもたらすのかについてはまだ専門家達も調査している段階だ。

米国心理学会は、「デジタル技術と共に成長することは、どのようにかはまだ不明だが、10代の脳の発達を変化させている可能性がある」と伝えている。もちろん、ソーシャルメディアの利点はたくさんある。しかし、欠点については検討し、対処をし始めたばかりだ。

これは、ブランドがメタバースにおけるビジネスチャンスを掴むべきではないと提案しているのではない。そうではなく、このチャンスは是が非でも追い求めるようなものではないと言いたい。

今こそ、メタバースをつくり上げるブランドが、それぞれのパーパスをどのように達成し、積極的にESGを実践していくかを明らかにするよう求めるべきだ。そうすれば、今までのようにビジネスチャンスを生かすことを重視するあまり、早急に動き、人や地球を犠牲にしてしまうという、他の業界のリーダーが陥ってきた失敗を防ぐことができるだろう。

最近の分析では、「メタバースが主流になることで生まれる市場機会は、今後数年間で1兆ドル(約126兆円※4月13日、1ドル126円時点)以上になる可能性がある」と言われており、大手ハイテク企業や各分野のブランドが投資するために力を結集し始めている。ほんの一例だが、マイクロソフトは、ゲームスタジオのアクティビジョン・ブリザード(コール オブ デューティ、キャンディクラッシュなどのゲームを制作している)を687億ドル(約8兆6000億円)で買収。フェイスブックはメタ・プラットフォームズに社名変更し、VRのハードウェアに莫大な投資を行った。また、ナイキは昨年、バーチャルスニーカーを販売する企業RTFKTを買収し、わずか6分間で600足のバーチャルスニーカーを販売し、300万ドル(約3億7000万円)以上の利益を得ている。

しかし、すでにネガティブな側面も明らかになっている。いくつかの初期リスクがあるようだ。NBC Newsによれば、「オンライン上でのヘイト(憎悪)や誤った情報を取り除く非営利組織CCDH(Center for Countering Digital Hate)の研究者は、メタが販売するOculusヘッドセットでアクセスできるVRプラットフォームVRChatで展開されている活動を12時間記録した。この記録の中で、性的コンテンツ、人種差別、虐待、ヘイト、同性愛嫌悪、女性嫌悪などが7分に1回記録され、しかも多くの場合は未成年者がその場にいたようだ。

このような問題のある言動は現実世界にも蔓延しているが、インターネット上ではより悪質になる。社会全体で、私たちは今も変化し続けている新型コロナウイルスの影響によって、繋がりが失われ、孤立していっている。人間は、他者との繋がりを求めるようにできているし、私たちは繋がりや人間関係こそが、幸せになるための鍵だと本質的に知っている。しかし、現在のインターネットの世界でも、このバランスの取り方はまだ理解されておらず、次のインターネットの世界でどうすべきかは全くの未知である。

健全なデジタル習慣をつくる

メタバースの世界に踏み込む前に、私たちが解決すべき重要な課題がある。それは、現実世界とデジタルのつながりを強くするための健全なデジタル習慣をどのように構築するかだ。これはより多くのスクリーンタイムの獲得を目指すことと、それによって生じる落とし穴との2つの課題に向き合うというブランドにとって不可欠な課題だ。

では、ナイキ、マイクロソフト、メタなど業界をリードする企業に、私たちはどのような質問を投げかけるべきだろうか。

ナイキのブランドパーパス、つまり社会的な存在意義の中核にあるのは「子どもたちが体を動かすこと」と「アクティブな次世代を生み出すこと」だ。実際にナイキのパーパスを構成する3つの柱は「人」「地球」「遊び」。同社のウェブサイトによると「ナイキはすべての子どもたちの遊びやスポーツに投資している。次世代がアクティブであるということが、より健康的で公平な未来につながる」と伝えている。メタバースに参入したナイキは、この2つの世界をどう跨いでいくかを積極的に考えていくことができるだろう。

・メタバースユーザーをただ接続している状態で引き止めるのではなく、アクティブな状態にさせるためにはどのようなツールや、リソースそしてインセンティブを提供すべきか。

・若者たちがバーチャルではなく、本物の靴を履くようになるために、企業はどのような研究やソリューションへの投資を行うべきか。

次に、マイクロソフトの社会的責任に関するウェブサイトでは、「私たちが創造するテクノロジーには、地球に存在するすべての人に、そして地球にとっても利益をもたらすことを保証する大いなる責任と機会があります」と伝えている。また、同社は「人類と地球の未来に利益をもたらすことができ、そうであるべき」テクノロジーを構築することを公言し、明示している。最新のCSR報告書でも「プライバシーは基本的人権だと認識し、お客様が自分のデータを管理することができ、プライバシーを守るために、十分な情報を得た上で選択することができるように取り組んでいます」と説明している。

・マイクロソフトは、メタバースにおけるプライバシーとデータ・ガバナンスに関する懸念にどのように対処できるだろうか。また、アクティビジョン・ブリザードの買収はこれらの取り組みにどのような影響を与えるのか。

・マイクロソフトは、メタバースのアバターを自分自身の延長にある者として扱う方法をユーザーに知らせ、指導し、コーチすることによって、プライバシーとデータの保護に対して高まる動きをどのように支援できるのだろうか。

メタは未だにプライバシーやセキュリティ、ネット上でのいじめ、誤った情報の拡散など、フェイスブック時代から残る懸念に完全に対処することはできていない。現在、メタバース・ゴールドラッシュの先頭を走る同社は、株主を不安にさせる無数の新たな困難にも直面している。例えば、現時点ですでに6万8000人の従業員の職場での混乱が報じられている。

・メタは将来に向けて若い世代を育てるために、どのような人材開発に投資すべきなのだろうか。

・メタだけでなく、急成長しているこの業界全体に利益をもたらすような方法で、今いる従業員をスキルアップさせることができるのだろうか。

過去の教訓から学ぶ

幸運なことに、メタバースという未知の世界に足を踏み入れる企業には、歴史的な事例と、教訓的なストーリーがある。石油と製造業もその一つだ。環境にサステナブルなビジネスをする上での事実上の指針となっているバルディーズ原則(セリーズ原則)は、史上最悪の環境へのダメージと、地域経済への影響を引き起こした、1989年のエクソンバルディーズ号の原油流出事故をきっかけに生まれた。

同じく、公正労働協会(FLA)の職場行動規範は、アパレル業界の製造工場での搾取に対して世論の抗議を受けて制定された。セリーズとFLAの両原則は、自主的なものではあったが、多くの企業にとってビジネスによる社会・環境への負の影響を低減させるための初期段階の取り組みの基礎となってきた。

現在、石油会社や製造会社は、環境や社会の影響を考慮してビジネスを計画しなかったためにESGの課題に直面し続けている。同じように、ソーシャルメディア企業もネット上でのいじめや間違った情報、ヘイトスピーチのような重大な問題にユーザーや政府からの圧力が大きくなってから対応し始めた。

このようなESGに関する経験を振り返ると、企業はメタバース界でパーパス・リーダーシップを発揮するチャンスを捉え、大胆な行動を今すぐとる必要がある。米国電気電子学会(IEEE)やデジタルヘイト対抗センター(CCDH)などの組織が、初期段階でのリスクを評価し管理するための取り組みを始めている。

しかし、リスクを減らすための取り組みのスピードは、メタバース界の成長スピードと同じである必要がある。私たちは、メタバースに関する企業行動に対して業界の基準値と期待値を設定するために、より多くのステークホルダーと早急に協力体制をとる必要がある。

RBA(レスポンシブル・ビジネス・アライアンス)やセリーズ、FLA、BSR(ビジネス・フォー・ソーシャル・レスポンスビリティ)といったESGをけん引するリーダー団体と、インターネット問題やデータ保護、プライバシー、ネット上でのいじめ、安全性や若者のメンタルヘルスの専門家たちが協働すれば、次のインターネットに伴うリスクについて対話を始めるベストな機会をつくれるだろう。

Adblock test (Why?)


からの記事と詳細 ( メタバースブームに求められる、企業のパーパス・リーダーシップ - Sustainable Brands Japan )
https://ift.tt/TfGp7w6

Thursday, April 14, 2022

「DevRel」ってなんだろう - ThinkIT

tahupedascabe.blogspot.com

はじめに

皆さん、はじめまして。MOONGIFTの中津川と申します。本連載では、最近よく聞かれるようになった「DevRel」(デブレルと読みます)について、開発者の目線で事例を含めながら紹介していきます。多数のテックカンパニーがDevRelを取り入れてサービス提供を行っている現在、多くの開発者たちがその一端に触れた経験があるはずです。今はまだDevRelの意味を知らなくとも、読み進めていくうちに「ああ、あれがDevRelだったのか」と思ってもらえるでしょう。

DevRelは「Developer Relations」の略語で、簡単に言えば「自社や自社製品と外部の開発者との良好な関係性」を形成するためのマーケティング活動になります。そんなDevRelはビッグテック(GAFAM)はもちろんのこと、小さなスタートアップ企業でも実践されています。例えばブログ記事の執筆、コミュニティ活動、ハッカソンへの協賛、年次の開発者カンファレンスを催すといった具合です。

Facebookの開発者カンファレンスf8の様子

Facebookの開発者カンファレンスf8の様子

年次の開発者カンファレンスとしては、有名なところでAppleの「WWDC」、Googleの「Google I/O」、Facebookの「f8」、AWSの「AWS Dev Day」などがよく知られています。そうした開発者向けのカンファレンスでは多くの開発者が集って新しいサービスに関する発表を聞いたり、その場にいるエンジニアに質問したりして自社サービスを宣伝しています。これは大規模なカンファレンスの例ですが、小さなブログ記事やソーシャルメディアでの発信もDevRelの大事な施策です。

なぜDevRelを行うのか

では、そもそもなぜ企業はDevRelを行っているのでしょうか。その理由は簡単で、企業が自分たちのサービスや製品を開発者に使って欲しいからです。特にAppleでいうiOS、GoogleでいうAndroidなどのプラットフォームにおいては、自社開発するOSやアプリだけでは魅力はほとんどありません。その上で動くアプリが魅力を作ってくれるのです。

スマートフォンを電話としてだけ使っている人はごくごくわずかでしょう。多くの人がYouTubeやLINEなどのアプリ、さらに数多あるゲームアプリを利用しているはずです。これらはプラットフォーマーであるAppleやGoogleが開発しているものはごく僅かで、大多数がサードパーティーの開発者の手によるものです。AppleやGoogleは自社プラットフォームの魅力を宣伝することで、開発者を引きつけているのです。そして開発者がプラットフォーム上で動くアプリを開発することで、プラットフォームの魅力が増大します。

プラットフォームを魅力的にするのはサードパーティーの開発するソフトウェア

プラットフォームを魅力的にするのはサードパーティーの開発するソフトウェア

プラットフォーマーに限らず、API提供企業においてもDevRelは重要です。APIの多くはシステム内部に組み込まれます。そして一旦組み込んでしまえば、正しく動き続ける限り早々に乗り換えることはありません。従って、開発者に魅力を伝えて組み込んでもらえれば、システムを使い続けてもらえるのです。大抵のAPIは排他的であり、類似した機能を提供するAPIを複数使うことはあまりないでしょう。同じクレジットカード決済APIを複数選定する理由があるとすれば、メインで障害が発生したときの控えとしてくらいですが、そうした予備を用意するケースは多くありません。その意味において、選ばれることの重要性はお分かりいただけるかと思います。

DevRelを活用して成長したサービスの例

DevRelがサービスを飛躍的に成長させた例として、Twitterがよく知られています。Twitterはサービスリリース当初からAPIを公開していました。今でこそOAuthによる安全なAPI提供となっていますが、リリース当初はBASIC認証だけで使える状態でした。セキュリティ上の課題はありましたが、その緩さから数多くのTwitterクライアントや関連サービスが生み出されていったのです。Webブラウザ版のTwitterはほとんど使われず、多くのユーザーがサードパーティー製のTwitterクライアントを利用していました。その中からリツイートの文化が生まれたり、数多くのサービスがTwitter連携機能を開発していったのは記憶に新しいでしょう。

さらに、同じソーシャルサービスを例にすると、Facebookの躍進を支えたのも開発者の力だったと言えます。FacebookアプリはFacebookの中で動作するWebアプリケーションで、農場系ゲームや診断アプリなど様々なものを誕生させました。JavaScriptだけで使える認証機能や、今はGraphQLと呼ばれるFQL(Facebook Query Language)もFacebookアプリ開発では欠かせない存在でした。それまでMySpaceというソーシャルサービスに押されていたFacebookは、このFacebookアプリによって一気に世界的なSNSに成長したと言っても過言ではありません。

有名なサービス(企業)とその主な施策

サービス名 主な開発者向けの施策
Twitter 緩く、簡単に使えるAPI
Facebook Facebookアプリ、「いいね」ボタン
Google オープンソース、各種API
AWS 柔軟で拡張性に富んだ機能、API操作による自動化、開発者コミュニティ
Apple/td> アプリストア、魅力的なデバイス
GitHub 学生向けプログラム、ハッカソンへの協賛、API

最近であればGitHubが人気を集めたのも、DevRelによるところが大きかったと言えます。彼らは学生向けのプランを提供したり、数多くのハッカソンやカンファレンスにスポンサードしています。GitHubの有名なキャラクターであるMonalisaの多種多様なステッカーは、何かのカンファレンスや技術系勉強会に参加したことがある人はもらった経験があるのではないでしょうか。MonalisaがGitHub成功のカギだったという訳ではありませんが、Monalisaに似た動物などのキャラクターを作成する風潮がテックカンパニー界隈でしばらく続きました。

日本企業も欧米に比べると数は少ないですが、DevRelに取り組んでいる企業はあります。例えばSORACOMは元々AWSでエバンジェリストをされていた玉川社長とあって、効果的にDevRelに取り組んでいる企業です。その成長速度はすさまじく、あっと言う間に200億円企業としてKDDIに買収されました。さくらインターネットはDevRelに関係する専門チームがあり、全社員の約1%がチームに在籍しています。kintoneは外部エバンジェリスト制度があり、コミュニティ活動も活発です。クラスメソッドのDevelopersIOは、企業としての発信文化を強固に形成し、事業活動上も大きな役割を担っています。Forkwellは元々イベント活動をサポートしてきましたが、コロナ禍になってからは自社主催イベントを強化しています。そして昨年末にはDevRelチームを専門的に立ち上げるに至っています。

このように、日本企業でもDevRelを行うところが増えています。それは海外のDevRelを真似るだけでなく、日本独自の方法も少なくありません。

DevRelとPRは何が違うのか

さて、話をDevRelに戻しますが、DevRelを理解してもらうためにPublic Relations(PR)について触れておきます。日本ではPRというとプレスリリースのことだと思われがちですが、世界的にはPRというとPublic Relationsを意味します。そして、このPRとは日本語で広報になるのですが、日本で広報というと情報発信を行うイメージが強いでしょう。しかし、本来のPublic Relationsの意味合いでは広報はもちろんですが、傾聴(耳を傾ける)という意味もあります。つまり、発信とともにユーザーボイスを聞くのも大事な機能なのです。

Public Relationsの分かりやすい例として、あなたの近所に大きなモール建設計画が持ち上がったことをイメージしてください。利点はありますが、問題点も多数あるでしょう。モールに向かう車で付近の道路が大渋滞したり、近くの森を切り開くため環境悪化が問題になるかも知れません。治安が悪くなる懸念もありますし、何より昔ながらの商店街にとっては大打撃でしょう。そうした問題によって、住民を中心に建設反対運動が起こることもしばしばあります。その際に企業側の窓口となるのが広報担当者です。広報担当者は多数のステークホルダー(利害関係者)と対話し、落とし所を見つけるのが役割です。

近所にモールができる際に懸念される問題

近所にモールができる際に懸念される問題

落とし所とは、例えば駐車場の位置を工夫して幹線道路に渋滞ができないようにしたり、モールの近くに交番を誘致する、モール内に地元商店街の商品を扱うスペースを作るなどといった具合です。家族向けに公園を新設するのも良いかもしれません。そうした住民や商店が納得できる条件を提示したり、要望を企業に持ち帰って検討するのが広報の役割です。企業は自分勝手に物ごとを進められる訳ではなく、社会の一員として受け入れてもらえるように環境を整える必要があるのです。

開発者の社会に受け入れられる必要がある

開発者の社会に受け入れられる必要がある

そして、このPRの開発者版がDevRel(Developer Relations)です。クラウドサービスをはじめ、開発者向けにサービスを提供する企業は開発者の社会に受け入れてもらわなければいけません。個人の開発者もちろん、企業やコミュニティにも信頼されなければ使ってもらえません。そのため、単に自分たちが良いと思うものを作るのではなく、開発者からフィードバックをもらったり、世の中のトレンドを受けとめて製品開発に活かしています。これもDevRelの大きな役割の1つです。

DevRelが注目される理由

なぜ、ここ数年DevRelが注目されているのでしょうか。まず「広告の費用対効果が悪い」点が挙げられます。こと開発者に対する広告(AdWordsやバナー広告など)はクリック率が非常に悪いです。なぜ広告が効果的ではないのかと言うと、開発者は普段の仕事やプライベートにおいてインターネットの利用時間が他職種と比べて圧倒的に長いからです。その際、数多くの広告コンテンツに触れ続けている結果、広告コンテンツ(PRと書いてあったり、バナーだったり)が見えなくなるようなフィルタリングを獲得してしまうのです。

広告の課題とDevRelによる解決法

課題 理由 DevRelとしてできること
広告を見てくれない 仕事・プライベートを問わず広告に触れる機会が多いため ブログやイベントなど、アクティビティベースでのアプローチ
サービスの乱立化により差別化できない APIやデザインはデジタルで模倣しやすい コミュニティやサポートなど定性的な部分での差別化

そこでDevRelでは、自社サービスを知ってもらうためにブログを書いたり、ソーシャルメディアでの発信、勉強会の開催など日々のアクティビティを通じた宣伝活動を行っています。さらに使い方に困っているユーザーがいればサポートしたり、ドキュメントを整備するなど利用する際に困らないように開発環境を整えます。使ってみたけれど何かエラーが出て動かない、ユーザー登録が手間、クレジットカード登録が必須など開発者が苦痛に感じるポイントを極力なくしていくことで、自社サービスを使い続けてもらえるように促すのです。

次に「サービスの乱立化」が挙げられます。何か新しいサービスが流行ると、それを模倣するようなサービスが雨後の竹の子のように次々に登場します。クラウドサービスが整っている現代では、開発力さえあれば似たようなサービスを作るのはさほど難しくありません。すでに先駆者たるサービスがあれば、それを真似て管理画面を作ったり、APIを用意できます。

技術的に大きな差がない中で他社との差別化を図る上で重要なのがDevRelです。UIやAPIは模倣するのが容易ですが、コミュニティやQ&Aなどを通じて培った開発者とのつながりは一朝一夕に真似できるものではありません。そうした開発者との感情的なつながりがサービスの差別化につながるケースは少なくありません。

サービス選定する際に、人は完璧に理性的であるとは言い切れません。意外と感情的(エモーショナル)な決断を下すことはよくあります。例えば身近な人が教えてくれたり、すでに過去に導入した経験がある、ブランドへの安心感などが選定理由になるケースは多いです。毎回理性的に、機能差を吟味して判断することはあまりないでしょう。そうした「選んでもらえる理由」を作るのもDevRelの重要な仕事なのです。

開発者に必要なもの

2006年頃に発売された書籍に「ドリルを売るには穴を売れ」があります。これはワカサギ釣りを想像してもらうと分かりやすいのですが、釣りをしたい人に氷に穴を空けるドリルを売るのは筋が悪く、ドリルを使って氷に空けた穴を売るべきだという考えです。顧客はドリルが欲しいのではなく釣りをしたいのだから、穴を掘ってそれを売れば良いのです。確かに一般消費者を対象にするならその通りですが、開発者に対する考え方としては異なります。

開発者に売るならば、もっと格好良く穴が掘れるドリルです。シャープで綺麗な穴が掘れたり、またはもっと高速に穴が掘れるドリルです。APIが用意されていて、外部からコントロールできるドリルも良さそうです。開発者はそのドリルを使って素晴らしい穴を掘り、顧客に提供できるのです。つまり開発者が必要とするのは、もっと彼らの仕事をスマートにしてくれる道具であったり、何度も繰り返し行ってきてうんざりしている作業を省略化してくれるサービスになるでしょう。

一般的なマーケティングと開発者向けマーケティングの違い

一般的なマーケティングと開発者向けマーケティングの違い

そのため、ある程度の先進性があったり、使っていて周囲からすごいと思われるようなサービスが好まれます。有名なサービスを真似たようなものは好まれません。ただ安価なだけのサービスも好かれないでしょう。開発者に選ばれるサービスには、心に刺さるメッセージやデザイン、機能など、統合的な価値が必要となります。それもまた「選んでもらえる理由」の1つなのです。

おわりに

今回は「そもそもDevRelとは何か」について概要を紹介しました。次回以降は、より各論を深掘りして解説していきます。最近ではDevRelに関係する求人も増えており、それらは開発者としてのバックグラウンドを必要としています。ぜひDevRelに興味を持っていただき、そうしたキャリアパスがあることを知って欲しいです。

筆者はこのDevRelを広める活動を2015年から行っていますが、年々求められる役割の広がりや提供する企業の拡大を感じています。DevRelを知って、ぜひ皆さんの会社でも実践してみてください。

Adblock test (Why?)


からの記事と詳細 ( 「DevRel」ってなんだろう - ThinkIT )
https://ift.tt/CS7FWU8

Tuesday, April 12, 2022

報道ベンチャーがリスニングツールに参戦 n=1、千3つを抽出 - 日経クロストレンド

tahupedascabe.blogspot.com
インサイト創出術 第3回

報道テックベンチャーのJX通信社が2022年2月、ソーシャルリスニングツール「KAIZODE(カイゾード)」の本サービスを開始。マーケティング支援以外の業界からの参入は異例だが、SNSの膨大な投稿から事件・事故関連投稿を抽出するノイズ除去技術を応用し、見落としがちなインサイトを拾い上げる。顧客理解の“解像度”は高まるか?

解像度が高くなると見えてくるものがある!?(写真/Shutterstock)

解像度が高くなると見えてくるものがある!?(写真/Shutterstock)

記者ゼロ人の通信社がソーシャルリスニングツールを提供

 「記者ゼロ人の通信社」の異名を持つ、知る人ぞ知る報道テックベンチャー、JX通信社(東京・千代田)。今や誰もがスマートフォンを持つ時代、目の前で事件・事故が発生すれば、それをリアルタイムで実況ツイートする「誰でもメディア時代」になっている。「○○の近くで火災」「病院にクルマが突っ込んだ」といった現場の目撃者のツイートをAI(人工知能)が抽出し、デマ・フェイクの可能性も判断したうえで、確度の高い情報を契約先の報道機関や自治体などに即時配信する。このサービス「FASTALERT(ファストアラート)」の浸透によって、テレビ各局のニュース番組で「視聴者提供」の動画放映が定着した。

JX通信社のソーシャルリスニングツール「KAIZODE(カイゾード)」

JX通信社のソーシャルリスニングツール「KAIZODE(カイゾード)」

 そんな同社が2022年2月、マーケティングリサーチ業にも名乗りを上げた。提供を開始したのは、ソーシャルリスニングツール「KAIZODE(カイゾード)」。顧客理解の“解像度”を高める、という意味合いだ。

 特集第1回でも触れたが、マーケティングリサーチのグローバルな業界団体であるESOMAR(European Society for Opinion and MArketing Research、ヨーロッパ世論・市場調査協会)が、リサーチ業界の業務領域定義を「インサイト産業」へと拡大した。そのインサイト産業を構成する8セグメントの1つに、「ソーシャルリスニングコミュニティー」がある。コミュニティーサイト構築やソーシャルデータの分析といったサービス内容で、KAIZODEはこのセグメントに含まれる。

 オンライン上の消費者の声を拾って分析するソーシャルリスニングツールは、SNSの普及とともに開発、企業の導入が進んできた。国内では、NTTコム オンライン・マーケティング・ソリューション(東京・品川)提供の「Buzz Finder」、ホットリンク提供の「BuzzSpreader Powered by クチコミ@係長」などが知られている。分析に特化したものから、自社SNSアカウントの運用効率化を兼ねるものまで、国内だけでも10を超えるツールが出ている。提供元は基本的にマーケティング支援企業である。

 それだけに報道ベンチャーからのリスニングツール参入は異色に映る。だが決して畑違いな領域に進出したわけではない。情報の海の中から確からしい事件・事故関連投稿を抽出する技術を、確からしいインサイトの抽出に応用している格好だ。21年4月に「FASTALERT」の兄弟ブランドとして「FASTALERT for Marketing」のβ版サービスを開始し、今般、KAIZODEの名称で本格ローンチに至った。インサイト分析のデコム(東京・品川)から同社マーケティングマネージャーに転身した、データサイエンティストの松本健太郎氏が開発をリードしてきた。

 ではKAIZODEは既存のソーシャルリスニングツールとどの辺りが違うのか。

このコンテンツ・機能は有料会員限定です。

有料会員になると全記事をお読みいただけるのはもちろん
  • ①2000以上の先進事例を探せるデータベース
  • ②未来の出来事を把握し消費を予測「未来消費カレンダー」
  • ③日経トレンディ、日経デザイン最新号もデジタルで読める
  • ④スキルアップに役立つ最新動画セミナー
ほか、使えるサービスが盛りだくさんです。<有料会員の詳細はこちら>

Adblock test (Why?)


からの記事と詳細 ( 報道ベンチャーがリスニングツールに参戦 n=1、千3つを抽出 - 日経クロストレンド )
https://ift.tt/6YDQkL1

Monday, April 11, 2022

DeepMindのAIシステム、競技プログラミングで人間と互角の成績 - @IT

tahupedascabe.blogspot.com

DeepMindがAIベースのコンピュータプログラム作成システム「AlphaCode」を開発し、競技プログラミングコンテストへの参加をシミュレートしたところ、同システムはコンテスト参加者の54%以内の順位に相当する成績を収めた。

この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。

 DeepMindは2022年2月2日(英国時間)、AIベースのコンピュータプログラム作成システム「AlphaCode」を開発し、競技プログラミングコンテストへの参加をシミュレートしたところ、同システムはコンテスト参加者の54%以内の順位に相当する成績を収めたと発表した。

 こうしたコード生成システムが競技プログラミングコンテストで人間と張り合えるレベルに達した初の例だとしている。

AlphaCodeのコード生成能力

 AlphaCodeはこのシミュレーションで、クリティカルシンキング、ロジック、アルゴリズム、コーディング、自然言語理解などを組み合わせた新しい問題を解決した。AlphaCodeは、トランスフォーマーベースの言語モデルを使用して膨大なコードを生成し、それらを賢くフィルタリングして、有望なプログラムの小さなセットを抽出するものであり、DeepMindは、このシステムを解説した論文のプレプリントを公開している。

Codeforcesがコンテストで出題した問題と、AlphaCodeが作成した、問題を解決するコード(提供:DeepMind)

 競技プログラミングコンテストでは、参加者は一連の長い問題文を受け取り、それを解決するプログラムを数時間で作成する。

 典型的な問題は、一定の制約の中で道路や建物を配置する方法を求めたり、カスタムボードゲームに勝つための戦略を立てたりするといったものだ。参加者は主に、問題をどれだけ解いたかで順位付けされる。企業はこうしたコンテストを採用ツールとして利用しており、ソフトウェアエンジニアの採用プロセスでも、同様の問題がよく出題される。

 こうした競技プログラミングコンテストで優秀な成績を上げるために必要な問題解決能力は、既存のAIシステムの能力を超えている。だが、DeepMindは、大規模トランスフォーマーモデルの進歩と、大規模なサンプリングおよびフィルタリングを組み合わせることで、AIシステムが解決できる問題の数を大幅に増やすことに成功した。

Copyright © ITmedia, Inc. All Rights Reserved.

Adblock test (Why?)


からの記事と詳細 ( DeepMindのAIシステム、競技プログラミングで人間と互角の成績 - @IT )
https://ift.tt/Efiu6KF

Friday, April 8, 2022

AWS WAF Bot Control のチューニングと最適化 | Amazon Web Services - amazon.com

tahupedascabe.blogspot.com

数年前の AWS Summit Sydney で、ある参加者から素晴らしい質問を受けました。彼女は、Amazon Web Services (AWS) 上のウェブ上のリソースをシンプルなボットから保護するために、コスト効率がよく、信頼性が高く、複雑すぎないソリューションを設計するのを手伝ってほしいと言いました。AWS WAF Bot Control のリリースにより、その質問にエレガントなソリューションで対応できるようになったので、私はこのときのことをよく覚えています。Bot Control の機能は、Web アプリケーションに対するトラフィックの 50% 以上を占める一般的で広範なボットのフィルタリングを開始するために、スイッチを入れるだけの問題になっているのです。

新機能 – AWS WAF Bot Control でウェブサイトの不要なトラフィックを削減 では、AWS WAF Bot Control とその機能の一部が紹介されています。この記事では、どこから始めればいいのか、どの要素を設定と保護のために使用すればよいかについて、知るべき情報をカバーしています。本記事では、密接に関連する機能を明らかにし、重要な考慮事項、ベストプラクティス、および一般的なユースケースのためのカスタマイズ方法について説明します。対象となるユースケースは以下の通りです。

ボット軽減機能の細かい設定に移る前に、このプロセスの構成要素を理解することが重要です。

ラベルは Bot Control 独自のものではありませんが、この機能を活用し、多くの設定でラベルをメインの入力として使用しています。ラベルは、ルールステートメントのマッチングに基づいて、リクエストに適用される文字列です。いわば、特定のリクエストに属するタグのようなものです。リクエストはルールステートメントによって処理された後、同じ Web ACL 内の後続のすべてのルールでラベルを取得し、同様のリクエストの識別に利用できます。ラベルを使用すると、特定の条件を満たすリクエストのグループに対処することができます。それは、同じ Web ACL 内の後続のルールが追加されたラベルにアクセスでき、それらに対してマッチングができるからです。

ラベルは、単なるルールマッチングの仕組みにとどまりません。ラベルはルールのアクションとは独立しており、 Block、 Allow、 Count のいずれに対しても追加することができます。これにより、 AWS WAF ログのレコードに対してラベルに基づくフィルタリングやクエリを構築し、高度な分析が可能になります。

ラベルは、コロンで区切られた、接頭辞、オプションの名前空間、名前で構成される文字列です。
例:
prefix:[namespace:]name
接頭辞の prefix 部分は AWS WAF によって自動的に追加されます。

これらのラベルは、マネージドなボット検出ロジックによって追加され、 Bot Control はこれらを使って、以下のような処理を実行します。

既知のボットの分類: リクエストのユーザーエージェントを既知のボットと比較、分類し、お客様がカテゴリ別にブロックできるようにします。ボットは、スクレイパー、検索エンジン、ソーシャルメディアなどの機能別に分類されます。

ボットの確認: ほとんどの正当なボットは、ユーザーエージェントを超える検証方法を提供しており、通常は IP アドレスの逆引き DNS によって、ドメイン名とホスト名の妥当性を検証します。これらの自動チェックは、正当なボットだけを許可し、下流のシステムにボット検出のフラグを立てるためのシグナルを提供するのに役立ちます。

ヘッダの検証: リクエストヘッダの検証で、ヘッダの欠落、不正なヘッダ、無効なヘッダを探すための一連のチェックを実行します。

ブラウザシグネチャーの照合: TLS ハンドシェイクのデータとリクエストヘッダを分解し、部分的に再結合することで、ブラウザと OS の組み合わせを識別するブラウザシグネチャを生成することができます。このシグネチャーは、ユーザーエージェントと一致していることを確認するために検証され、既知の良性・悪性のブラウザシグネチャーのリストと照合することができます。

以下に、Bot Control のラベルの例をいくつか示します。DescribeManagedRuleGroup API を使用して、すべてのリストを取得できます。

awswaf:managed:aws:bot-control:bot:category:search_engine
awswaf:managed:aws:bot-control:bot:name:scrapy
awswaf:managed:aws:bot-control:bot:verified
awswaf:managed:aws:bot-control:signal:non_browser_user_agent

Bot Control を始めるためのベストプラクティス

Bot Control を有効にして、デフォルトの Block アクションでウェブリソースの保護を開始できますが、最初にルールグループのすべてのルールを Count アクションに切り替えることができます。これにより、次のことが実現されます。

  • Bot Control のルールの1つにマッチしても、リソースに対する正当なボットである可能性があるリクエストが誤検出されるのを回避します。
  • リクエストの一部が Bot Control のルールにマッチした際に、ラベルとリクエストへのアクションという形で、十分なデータポイントを蓄積できます。これにより、ボットやカテゴリごとにルールを構築し、いつデフォルトのアクションに切り替えるべきかについて、十分な情報を得た上で判断できます。

ラベルは Amazon CloudWatch メトリクスや AWS WAF ログから確認でき、そこからすぐに、特定のシナリオに対応するための例外やカスタムルールの必要性について計画することができます。この投稿では、「典型的なユースケース」のセクションで、それらを検討します。

さらに、AWS WAF はルールを順番に処理するため、Bot Control のルールグループが Web ACL のどこに位置しているかを考慮する必要があります。不要と確信できるリクエストをフィルタするために、評価順序で Bot Control ルールグループの前に、Amazon IP Reputation List などの AWS Managed Rules ルールグループを配置することができます。これにより、Bot Control が処理するリクエスト数が減少し、費用対効果が高まります。同時に、次の要件がある場合には、Bot Control は早い段階のルールで評価されるよう配置すべきでしょう。

  • 後続のルールのためにラベルを生成したい。副次的な効果として、高い視認性ももたらします。
  • Bot Control が評価する前に適切なボットをブロックしてしまう誤検出を減らしたい。

AWS WAF Bot Control のチューニングは、最近リリースされたAWS WAF の一連の機能なしには、完備かつ設定可能とは言えません。それらを紐解いてみましょう。

CloudWatch メトリクスと AWS WAF ログにおけるラベルの動作

生成されたラベルは CloudWatch のメトリクスを生成し、 AWS WAF のログに記録されます。これにより、ウェブサイトにヒットしたボットやカテゴリ、それに関連するラベルを確認でき、チューニングに利用することができます。

CloudWatch メトリクスは以下のようなディメンジョンとメトリクスで生成されます。

  • Region ディメンジョンは、 Amazon CloudFront を除いて、すべてのリージョンで利用可能です。Web ACL が CloudFront に関連付けられている場合は北バージニアリージョンのメトリクスとなります。
  • WebACL ディメンジョンは Web ACL の名前です。
  • Namespace は接頭辞を含む、完全修飾の名前空間です。
  • LabelValue はラベル名です。
  • Action は最終的なアクションです。 (例えば、 Allow, Block, Count)

AWS WAF は Overview ページのトップに、図 1 のように関連する CloudWatch メトリクスへのショートカットがあります。

図 1: CloudWatch メトリクスへのショートカットを含む、チャートのタイトルと説明文

図 1: CloudWatch メトリクスへのショートカットを含む、チャートのタイトルと説明文

または、CloudWatch メトリクスの WAFV2 サービスカテゴリで確認することができます。

CloudWatch は、生成されたラベル、日時ごとのボリュームをメトリクスとして取得できるため、評価の上、ルールの構成や誤検出への対処について、情報に基づいた判断を下すことができます。図 2 は、私のウェブサイトへのボットからのリクエストに対して、生成されたラベルを示しています。この例では、明示的な Allow アクションをいくつか設定しただけなので、ほとんどがブロックされました。図 2 の上段には、選択された2つのラベルのメトリクスを示しています。

図 2: ラベルの WAFV2 CloudWatch メトリクス

図 2: ラベルの WAFV2 CloudWatch メトリクス

AWS WAF ログでは、ラベルは labels フィールドの配列として記録されます。図 3 に、labels 配列を含むリクエストの例を示します。

図 3: AWS WAF ログレコードの例

図 3: AWS WAF ログレコードの例

この例では、同じリクエストに対して 3 つのラベルが生成されています。uptimerobot は monitoring カテゴリラベルに従います。この 2 つのラベルを組み合わせることは、それらに基づく設定に柔軟性を持たせるのに有効です。カテゴリ全体を使うこともできますし、特定のボットのラベルを使ってフォーカスすることもできます。この投稿の後半で、このことがどのように、そしてなぜ重要であるかを説明します。3つ目のラベル、non_browser_user_agent は、通常とは異なるヘッダを持ったリクエストのシグナルです。ラベルと組み合わせてボットから保護するために、特定のリクエストに対してアプリケーションで特別なスキャンを構築できます。

スコープダウンステートメントとは

Bot Control はプレミアム機能であり、有料の AWS Managed Rules であることを考えれば、コストを抑えられるかどうかは非常に重要です。スコープダウンステートメントでは、Bot Control による検査を必要としないトラフィックをフィルタすることで、コストを最適化できます。

このゴールのために、2 つの大まかなシナリオで、スコープダウンステートメントを使用できます。

リソースの特定の部分を Bot Contorl によるスキャンから除外することができます。ウェブサイトのうち、ボットにアクセスされても構わない箇所を考えてみましょう。一般的には、画像や CSS ファイルなどの静的コンテンツがこれにあたります。それ以外の API やログインページなどの部分には保護を残します。また、安全と思われる IP レンジを除外することもできます。例えば、自社組織から発信されていることが分かっているトラフィックや、パートナーや顧客等の閲覧者です。

また、視点を変えて、リソースのごく一部にのみボット管理を適用することも可能です。例えば、ログインページや機密性の高い API を Bot Control で保護し、それ以外は対象外にできます。

これらを駆使して、ユースケースとシナリオを掘り下げてみましょう。

AWS WAF Bot Control のチューニングの典型的なユースケース

Bot Control を、よりニーズに合うようチューニングする方法はいくつかあります。このセクションでは、使用できるいくつかの方法を紹介します。

クロールレートの制限

場合によっては、ウェブサイトへのボットのアクセスを許可する必要があります。例えば、検索エンジンのボットは、ウェブサイトをクロールしてインデックスを作成します。検索エンジンの最適化がビジネスにとって重要である一方、ウェブリソースへのリクエストが多すぎて負荷がかかりすぎている場合、必要以上にブロックすることなくクローラーの速度を下げる方法についてジレンマに直面することがあります。Bot Control の検知ロジックと、レスポンスのステータスコードやヘッダでクローラーに意図を伝えるレートベースルールを組み合わせることで、これを解決できます。有用と判断されるほとんどのクローラーは、負荷の増加を検知した際に、クロールレートを低下させるメカニズムを持っています。

ウェブリソースに悪影響を及ぼす可能性のある制限値以下にクロールレートを設定する

  1. AWS WAF コンソールで、左メニューから Web ACLs を選択します。Web ACL を開くか、Web ACL を作成する手順に従います。
  2. Rules タブを選択し、Add rules をクリックします。Add managed rule groups を選択し、以下のように設定します。
    1. AWS managed rule groups セクションで、Bot Control の Add to web ACL トグルを選択し、Web ACL で Bot Control を有効にします。これにより、Web ACL 内の評価プロセスで、後続のルールで使用できるラベルも取得できます。
    2. Add rule をクリックし、Save をクリックします。
  3. 同じ Web ACL で、Add rules をクリックし、Add my own rules and rule groups を選択します。
  4. Rule builder を使用し、以下のように設定します。
    1. 任意の名前を入力し、Rate-based rule を選択します。
    2. ルールに適用する Rate limit を入力します。例えば、500 などです。

      注意: Rate limitは 5 分間に 1 つの IP アドレスから許可する最大リクエスト数です

    3. Only consider requests that match the criteria in a rule statement を選択し、ルールで評価されるリクエストの範囲を狭めるためにスコープダウンステートメントを有効にします。
    4. 対象のボットにフォーカスするために、Inspect メニューで Has a label を選択します。
    5. Match key フィールドに以下のラベルのいずれかを入力し、図 4 で示すように、検査済みボットやスクレイピングと判別されたボットなど、幅広いカテゴリに基づいて照合します。

      awswaf:managed:aws:bot-control:bot:verified
      awswaf:managed:aws:bot-control:bot:category:scraping_framework

    6. または、ラベルで特定のボットに絞り込むこともできます。

      awswaf:managed:aws:bot-control:bot:name:Googlebot

      図 4: Match key を指定したラベルマッチルールステートメント

      図 4: Match key を指定したラベルマッチルールステートメント

  5. Action セクションで以下のように設定します
    1. Custom response を選択し、Enable にチェックを入れます
    2. Response code429 を入力し、一定時間内に送信するリクエストが多すぎることをボットに伝えます。
    3. Add custom new header を選択し、Retry-After を Key に、指定する秒数を Value にそれぞれ入力します。この値は、ボットが新しいリクエストを送信するまでに何秒待つべきかを示します。
  6. Add rule をクリックします。
  7. このカスタムルールでラベルが使用できるよう、Web ACL 内の Bot Control ルールグループの後にルールを配置することが重要です。
    1. Set rule priority セクションで、新しいレートベースルールが既存の Bot Control rule set の下にあることを確認し、もしそうでなかった場合は、新しく作成したルールを選択して、後ろになるまで Move up か Move down を選択します。
    2. Save をクリックします。
図 5: カスタムレスポンスコードを含む AWS WAF ルールアクション

図 5: カスタムレスポンスコードを含む AWS WAF ルールアクション

この設定により、Bot Control は必要なラベルを設定し、それをレートベースルールのスコープダウンステートメントで使用することで、特定のボットからのリクエスト数の上限を設定するだけでなく、ボットのクロールレートが高すぎるときにはボットに伝達することができます。ボットがそのレスポンスを尊重し、レートを下げない場合、ルールが一時的にボットをブロックし、ウェブリソースを過負荷から保護します。

注意: scraping_framework のようなカテゴリラベルを使用すると、そのラベルを持つすべてのボットがレートベースのルールでカウントされます。同じラベルを使用するボットの意図しないブロックを避けるには、正確な bot:name: ラベルで特定のボットに絞り込むか、Rate limit を高くして余裕を持たせるかのどちらかを選択します。

Bot Control  をアプリケーションの一部にだけ適用する

前述のとおり、ウェブリソースの一部を Bot Control の保護の対象から除外し、到達するリクエストのサブセットに焦点をあてることで、実行コストを削減できます。このアプローチを利用する一般的なシナリオがいくつかあります。

動的な部分へのトラフィックだけに  Bot Control を適用する

  1. AWS WAF コンソールで、左メニューから Web ACLs を選択します。Web ACL を開くか、Web ACL を作成する手順に従います。
  2. Rules タブを選択し、Add rules をクリックします。Add managed rule groups を選択し、以下のように設定します。
    1. AWS managed rule groups セクションで、Bot Control の Add to web ACL トグルを選択し、Web ACL で Bot Control を有効にします。
    2. Edit をクリックします
  3. Scope-down statement – optional で、Enable Scope-down statement にチェックを入れます。
  4. If a requestdoesn’t match the statement (NOT) を選択します。
  5. Statement セクションで以下のように設定します。
    1. InspectURI path を選択します。
    2. Match typeStarts with string を選択します。
    3. リソースの構造によっては、URI 文字列全体 (images/ など) を String to match フィールドに入力できます。これにより、この文字列が Bot Control の評価から除外されます。
    図 6: スコープダウンステートメントの前方一致による URI path の指定

    図 6: スコープダウンステートメントの前方一致による URI path の指定

  6. Save rule をクリックします。

文字列マッチングを使用する代替案

文字列マッチングの Match type の代わりに、正規表現パターンセットを使用できます。もし正規表現パターンセットを作成していない場合は、以下のガイドに従って作成してください。

注意: このパターンは、典型的なウェブリソースの静的ファイルに関連付けられた、最も一般的なファイル拡張子にマッチします。異なるファイルがある場合には、パターンセットをカスタマイズできます。

  1. 前項の手順 1-4 を行います。
  2. Statement セクションで以下のように設定します。
    1. InspectURI path を選択します。
    2. Match typeMatches pattern from regex pattern set を選択し、図 7 のように Regex pattern set に作成した正規表現パターンセットを選択します。
    3. Regex pattern set では、以下のパターンを入力します。
      (?i)\.(jpe?g|gif|png|svg|ico|css|js|woff2?)$
      図 7: URI path の一部に指定された正規表現パターンセットに基づいたマッチングを行うスコープダウンステートメント

      図 7: URI path の一部に指定された正規表現パターンセットに基づいたマッチングを行うスコープダウンステートメント

アプリケーションの最も機密性の高い部分だけに Bot Control を適用する

アプリケーションの最も機密性の高い部分だけに Bot Control を有効にすることで、他のほとんどすべての部分を除外することもできます。例えばログインページなどです。

注意: 実際の URL path はアプリケーションの構造によって異なります。

  1. Scope-down statement 内の If a requestmatches the statement を選択します。
  2. Statement セクションで以下のように設定します。
    1. InspectURI path を選択します。
    2. Match typeContains string を選択します。
    3. String to match で、マッチさせる文字列を入力します。例えば、図 8 のような login などです。
  3. Save rule をクリックします。
    図 8: URI path 内の文字列でマッチングを行うスコープダウンステートメント

    図 8: URI path 内の文字列でマッチングを行うスコープダウンステートメント

アプリケーションの複数の箇所を Bot Control から除外する

複数の箇所を除外する場合、OR ステートメントを使用して、スコープダウンステートメント内で除外する箇所をリストアップできます。

  1. Scope-down statement 内の If a requestmatches at least one of the statements (OR) を選択します。
  2. Statement 1 セクションで、以下のように設定します。
    1. InspectURI path を選択します。
    2. Match typeContains string を選択します。
    3. String to match で、マッチさせる文字列を入力します。例えば、図 8 のような login などです。
  3. Statement 2 セクションで、以下のように設定します。
    1. InspectURI path を選択します。
    2. Match typeStarts with string を選択します。
    3. String to match で、マッチさせる文字列を入力します。例えば、 payment/ などです。
  4. Save rule をクリックします。

図 9 は、先述の完全一致の例に OR ステートメントを追加して、payment という API を保護するようにしたものです。

図 9: より高度なマッチングを実現するための OR ロジックによるスコープダウンステートメント

図 9: より高度なマッチングを実現するための OR ロジックによるスコープダウンステートメント

注意: コンソール上でのビジュアルエディターでは、最大 5 個のステートメントをサポートしています。それ以上追加するには、コンソール上で JSON を編集するか、API を使用します。

ブロックしたくない検証済みボットに優先順位をつける

検証済みボットは、デフォルトではブロックされないため、ほとんどの場合はボットを通過させるために追加でロジックを適用する必要はありません。しかし、他の AWS WAF ルールが検証済みボットからのリクエストのいくつかの要素に一致し、ブロックしてしまうシナリオは起こりえます。それによって、 SEO のメトリクスにダメージを与えたり、リンクが伝播しソーシャルメディアに表示されるのを妨害したりすることがあります。もしそれがビジネスにとって重要であれば、AWS WAF で明示的に許可することによって、検証済みボットを確実に通過させたいと考えるかも知れません。

検証済みボットカテゴリを優先順位付けする

  1. AWS WAF コンソールで、左メニューから Web ACLs を選択します。Web ACL を開くか、Web ACL を作成する手順に従います。次の手順では、Web ACL で Bot Control ルールグループがすでに有効になっていることを想定しています。
  2. Rules タブを選択し、Add rules をクリックします。Add my own rules and rule groups を選択します。
  3. Rule builder を使用し、以下のように設定します。
    1. Name にルール名を入力します。
    2. InspectHas a label を選択します。
    3. Match key フィールドに以下のラベルを入力し、検査済みボットが持つラベルを元に照合します。

      awswaf:managed:aws:bot-control:bot:verified

    4. Action セクションで Allow を選択し、リクエストがマッチした際のアクションを確認します。
  4. Add rule をクリックします。このカスタムルールで bot:verified ラベルが使用できるよう、Web ACL 内の Bot Control ルールグループの後にルールを配置することが重要です。そのために、以下の手順に従います。
    1. Set rule priority セクションで、今作成したルールが既存の Bot Control rule set の直後にあることを確認し、もしそうでなかった場合は、新しく作成したルールを選択して、直後になるまで Move up か Move down を選択します。
    2. Save をクリックします。
図 10: Match key を指定しての Label match rule statement

図 10: Match key を指定しての Label match rule statement

特定のボットを許可する

ラベルを使用することで、ブロックされたカテゴリの中から、ブロックしたくないボットを選び出すこともできます。代表的な例では、お客様のウェブリソースを監視するサードパーティボットがあります。

UptimeRobot を使って、特定のボットを許可するシナリオを見てみましょう。このボットは、 bot:category:monitoring で、デフォルトではブロックされるカテゴリに該当します。カテゴリ全体を除外することもできますが、リソースに必要以上に大きな影響を与える可能性があります。UptimeRobot だけを許可することもできます。

特定のボットを明示的に許可する

  1. CloudWatch メトリクスや AWS WAF ログを分析し、ブロックされているボットと、それに関連付けられたラベルを見つけます。カテゴリ全体を許可するのでなければ、目的のボットを bot:name: ラベルから探します。例えば、以下は、 awswaf:managed:aws:bot-control:bot:name:uptimerobot というラベルに基づいています。

    ログからは、ボットがどのカテゴリに属しているかを確認でき、スコープダウンステートメントを設定する際にこの情報が役立ちます。

  2. AWS WAF コンソールで、左メニューから Web ACLs を選択します。Web ACL を開くか、Web ACL を作成する手順に従います。次の手順では、Web ACL で Bot Control ルールグループがすでに有効になっていることを想定しています。
  3. Web ACL 内のリストにある Bot Control rule set を開き、Edit をクリックします。
  4. Rules のリストから CategoryMonitoring を見つけ、Count にセットします。これにより、デフォルトの Block アクションを防ぎます。
  5. Scope-down statement – optional で、Enable Scope-down statement にチェックを入れ、以下のように設定します。
    1. Scope-down statementIf a request で、matches all the statements (AND) を選択します。これにより、カテゴリをブロックするが、特定のボットは許可するといった複雑なロジックの構築が可能になります。
    2. Statement 1 セクションの InspectHas a label を選択します。
    3. Match key フィールドで、手順 4 でカウントに設定したカテゴリの大分類のラベルを入力します。この例では、monitoring となっています。この設定によって、カテゴリの他のボットはブロックされたままになります。

      awswaf:managed:aws:bot-control:bot:category:monitoring

    4. Statement 2 セクションで、特定のボットを除外するために、Negate statement results を選択します。
    5. Inspect で、Has a label を選択します。
    6. Match key フィールドで、明示的に許可するボットを一意に識別するラベルを入力します。この例の、uptimerobot は次のようになります。

      awswaf:managed:aws:bot-control:bot:name:uptimerobot

  6. Save rule をクリックします。
図 11: AND ロジックを用いてカテゴリから特定のボット名を抽出する Label match rule statement

図 11: AND ロジックを用いてカテゴリから特定のボット名を抽出する Label match rule statement

注意: この方法は、誤検知の状況を分析し、必要に応じて対処するためのベストプラクティスです。一意の bot:name: ラベルに基づき、任意の、または複数のボットを除外できます。

特定のボットからのリクエストにカスタムヘッダを挿入する

特定のリクエストをさらに処理・分析したい場合や、下流のシステムが提供するロジックを実装したい場合があります。このようなときに、AWS WAF Bot Control を使用すると、リクエストを分類できます。後工程のアプリケーションでは、カテゴリ内のすべてのような幅広い範囲、特定のボットのような狭い範囲のいずれにも、意図したロジックを適用できます。

カスタムヘッダを挿入する

  1. AWS WAF コンソールで、左メニューから Web ACLs を選択します。Web ACL を開くか、Web ACL を作成する手順に従います。次の手順では、Web ACL で Bot Control ルールグループがすでに有効になっていることを想定しています。
  2. Web ACL 内のリストにある Bot Control rule set を開き、Edit をクリックします。
  3. Rules のリストから対象のカテゴリを見つけ、Count にします。
  4. Save rule をクリックします。
  5. 同じ Web ACL で、Add rules をクリックし、Add my own rules and rule groups を選択します。
  6. Rule builder を使用し、以下のように設定します。
    1. Name にルール名を入力します。
    2. InspectHas a label を選択します。
    3. Match key フィールドに対象のカテゴリもしくはボットのラベルを入力します。この例ではセキュリティカテゴリのラベルを使用しています。

      awswaf:managed:aws:bot-control:bot:category:security

    4. Action セクションで Count を選択します。
    5. Custom request – optional を展開し、Add new custom header を選択します。
    6. KeyValue に下流システムで使用するカスタムヘッダのヘッダーキーと値を入力します。この例では図 12 のように設定しています。
    7. Add rule をクリックします。

    AWS WAF は、カスタムヘッダ挿入時に x-amzn-waf- という接頭辞をヘッダ名に付けるため、abc-category を追加した場合には、下流システムからは x-amzn-waf-abc-category として読み取れます。

図 12: カスタムヘッダを挿入する AWS WAF rule action

図 12: カスタムヘッダを挿入する AWS WAF rule action

Bot Control の後に配置されたカスタムルールによって、セキュリティカテゴリ内のボットからであるというラベルが付けられたすべてのリクエストに対してヘッダが挿入されるようになりました。さらに、AWS WAF の下流のセキュリティアプライアンスでは、ヘッダに基づいて都度処理が実行されます。

この実装は、別のシナリオにも対応できます。例えば、特定のコンテンツのキャッシュの利用を明示的に禁止するために、オリジンと通信するカスタムヘッダを使用できます。これにより、ボットは常にオリジンから取得します。挿入されたヘッダは、AWS Lambda@Edge や CloudFront Functions からアクセスでき、より高度なシナリオも実現できます。

まとめ

本記事では、Bot Control 活用のための主な構成要素と、様々なシナリオに対応するために、これらをどう組み合わせてカスタマイズできるのかを紹介しました。Bot Control のチューニングのユースケースを完全に網羅したわけではありませんが、ここで紹介した例が、他の実装の参考やアイデアにつながることを願っています。

すでにウェブリソースに AWS WAF を関連付けている場合、サービスに処理されているリクエストのサンプルに基づいて、アプリケーションのボットトラフィックの現在の推定値を表示できます。AWS WAF コンソールから、Bot overview dashboard を開いてみてください。この投稿から学んだことを実装し、ボット対策を改善するための良いスタート地点になるでしょう。

この機能はまだ初期段階にあり、今後も多くの機能を追加していきますので、ぜひご期待ください。

この投稿について質問がある場合は、AWS WAF re:Post のスレッドを立ち上げるか、AWS サポートにお問い合わせください。

AWS セキュリティに関するニュースをもっと知りたいですか?ツイッターでフォローしてください。

翻訳はソリューションアーキテクト 駒原 が担当しました。原文はこちらです。

Adblock test (Why?)


からの記事と詳細 ( AWS WAF Bot Control のチューニングと最適化 | Amazon Web Services - amazon.com )
https://ift.tt/0MzLITd