Japanese IT global

TechCrunchが得た情報によると、Facebook（フェイスブック）は、EUのプライバシー規制当局から、ユーザーデータを引き続き米国へ転送できるかどうかに影響を与える「修正された」予備的決定案を受け取ったという。 「Meta（メタ、旧Facebook）には28日以内にこの予備的決定に対する意見を提出する権限が与えられており、その時点で他の関係監督機関向けに第60条の決定案を作成する予定です。これは4月中に行われると予想しています」と、アイルランドのデータ保護委員会（DPC）のGraham Doyle（グレアム・ドイル）副委員長は筆者に語った。 ドイル氏は、予備決定の内容については詳細を語らなかった。 しかし、2020年9月に関係者の発言を引用した当時のWall Street Journalの報道によれば、DPCは、Facebookにデータ移転の停止を指示する仮命令を出している。 最近そのデータマイニング帝国の名称を（Facebookから）変更したMetaは、投資家との電話会談で、EU-US間のデータ転送には継続的なリスクがあることを警告している。 同社は直ちに先のDPCの仮命令に異議を唱えようともしたが、2021年5月にアイルランド高等裁判所がDPCのやり方に対する異議を棄却する判決を下したため、この法的手段は頓挫していた。 欧州のデータ保護法と米国の監視権限との衝突を争点とするこの訴訟では、同社にデータ転送の一時停止を指示した先の仮命令以降、規制当局が今回は異なる結論を出すことになるような、事実関係に重大な変化があったかどうかは不明だ。 さらに、ここ数カ月の間に、欧州の他のデータ保護機関は、Google Analytics（グーグル・アナリティクス）など、米国へ個人データの転送を行う他の米国のサービスに対して「違法」との決定を下しており、少なくとも一般的な観点からは、DPCがMetaに対して最終的な決定を下す方向へ圧力が高まっている。 この規制当局はまた、当初の申し立て人であるMax Schrems（マックス・シュレムス）氏による手続き上の課題にも直面している。同氏は2021年1月に、長年の申し立てを速やかに最終決定するという合意を引き出している。つまり、もう1つの準期限があるということだ。 関連記事：フェイスブックのEU米国間データ転送問題の決着が近い この合意条件に基づき、DPCはシュレムス氏が（並行して）「自らの意思」で行う手続きでも審理を受けることに合意した。これはシュレムス氏の最初の（2013年の）苦情に関する調査に加えて開始されたもので、現在はMetaに出されたこの新しい予備的決定を通して進められている。 シュレムス氏は、DPCから決定書が送られてきたことを認めたものの、それ以上のコメントはしなかった。 （さらにややこしいことに、2021年11月には、シュレムス氏が設立したプライバシー擁護団体が、他の苦情草案の公表を阻止しようとしたことに関連して、DPCが「手続き上の脅迫」を行ったとして、この規制当局に対して刑事上の汚職の訴えを起こしている……） Metaにデータ転送の停止を命じる可能性のある最終的な決定が下されるまで、この数年にわたるデータ転送問題が、具体的にあとどれくらい続きそうであるかは、依然として不明だ。 しかし、もはや数年というよりは数カ月に近いはずだ。 第60条のプロセスには、利害関係のある他のデータ保護機関も加わることになる。これらの機関は、主導する機関の決定案に対して、まず1カ月の期間内に理由のある異議を唱えることができる。ただし、延長も可能だ。仮決定に対してデータ保護当局間で大きな意見の相違があった場合には、最終的な決定を下すプロセスに数カ月を要することになり、最後には欧州データ保護委員会が介入して最終的な決定を下すことになるかもしれない。 これらはまだ先の話だ。今のところ、ボールはMetaのコートに戻り、同社の弁護士がどんな新しい言い訳を思いつくか、見守る段階となっている。…

Amazon Web Services（AWS）のパートナー企業で構成する「FISC対応APNコンソーシアム」に参加する全10社は2022年2月14日、『「AWS FISC安全対策基準対応リファレンス」参考文書』（46ページPDF）を無料で公開した。金融機関は、AWSを活用して構築したシステムがFISC安全対策基準に準拠しているかを判断する参考情報として、同参考文書を活用できる。同文書は、公益財団法人金融情報システムセンター（FISC）が提供する「金融機関等コンピュータシステムの安全対策基準・解説書」（FISC安全対策基準）第9版令和2年3月版に対応する。 　「AWS FISC安全対策基準対応リファレンス」参考文書は、AWSを活用して構築したシステムがFISC安全対策基準に準拠しているかを判断可能な、46ページのPDF文書である。FISC対応APNコンソーシアム参画メンバー全10社（表1）の共同著作物であり、金融機関に向けて無料で提供する。FISCが提供する「金融機関等コンピュータシステムの安全対策基準・解説書」（FISC安全対策基準）第9版令和2年3月版に対応する。 図1は、参考文書の概要と活用イメージである。金融機関は、AWSを活用して構築したシステムがFISC安全対策基準に準拠しているかを判断する参考情報として、同参考文書を活用できる。加えて、クラウドサービス（AWS）によるFISC安全対策基準への準拠状況を把握できるように、準拠性の根拠となる第三者認証の該当項目を示している。これにより、準拠性の確認にかかる負荷を軽減できる。 図1：「AWS FISC安全対策基準対応リファレンス」参考文書の概要と活用イメージ（出典：NTTデータ）拡大画像表示 図2は、参考文書の構成例である。FISC安全対策基準の各基準について、AWSが公式見解として作成している「金融機関向け AWS FISC安全対策基準対応リファレンス」の記載の抜粋と、その内容に対する本コンソーシアムによる付加情報を記載している。 図2：「AWS FISC安全対策基準対応リファレンス」参考文書の構成例（出典：NTTデータ）拡大画像表示 「金融機関が安全にクラウドサービスを利用するためにはFISC安全対策基準を満たす必要がある一方で、FISC安全対策基準の項目は多岐にわたり、クラウドサービスを活用して構築したシステムの準拠性を確認する作業が負荷になっている」（FISC対応APNコンソーシアム）。 Original Post>

　Googleは、2019年に「Google Workspace」（旧称「G Suite」）に組み込んだ企業向けSNSツール「Currents」を廃止し、代わりに「人、トピック、プロジェクト」を整理するサービス「Spaces」を推進していくことを明らかにした。 Currentsは組織内のコミュニケーションを改善することを目的としており、また終了したSNSサービス「Google+」の後継としての役割も担っていた。 Googleは2023年にCurrentsの「段階的な縮小」を開始し、ユーザーのコンテンツを「Spaces」に移行する計画だ。それまでの間、Spacesに複数の改良を加える予定で、それには「コミュニティーとリーダーシップのコミュニケーション拡大に向けたサポート、高度な検索への注力、コンテンツモデレーション用のツールが含まれる」という。 Googleはまた、検索と「見つけやすさ」を強化し、Spacesをアプリ開発のプラットフォームとして改善するほか、データ保護や情報漏えい対策（DLP）、Google Workspaceの情報ガバナンスと電子情報開示のためのツール「Vault」のサポートなど、サイバーセキュリティとコンプライアンスに関する企業向け機能にも取り組むとしている。 Currentsの終了については、「Currentsを利用している組織には、今後数カ月の間にデータ移行へのオプトインやその他のマイルストーンのスケジュール、および移行を支援するガイダンスを共有する」と説明した。 今回の変更は、ハイブリッドワークへの対応の一環だという。「ハイブリッドワークへの移行が加速したことで、人々のコラボレーションの方法は大きく変化しており、Google Workspaceの利用者は『Chat』とSpacesを利用して、プロジェクトに関するコミュニケーションや組織の最新情報の共有、コミュニティーの構築を行っている」（Google） 「CurrentsをSpacesにアップグレードすることで、ユーザーに対しては個別にサイロ化された場所にアクセスする必要をなくし、組織には今日の世界の動きを反映した最新のエンタープライズ水準の体験を提供する。Spacesは、チームがトピックごとの議論に参加し、知識とアイデアを共有し、プロジェクトを推進し、コミュニティーとチーム文化を構築するための中心的な場を提供する」（同） この記事は海外Red Ventures発の記事を朝日インタラクティブが日本向けに編集したものです。 Original Post>

Google（グーグル）のChrome（クローム）ブラウザに導入されたPrivacy Sandbox（プライバシー・サンドボックス）のイニシアチブは、必ずしも完璧な成功を収めているわけではないものの、オンライン・プライバシーに関して、そして広告エコシステムにおけるGoogle自身の役割について、健全な議論を巻き起こしたことは間違いない。現在、Chromeにおけるこの取り組みの多くは依然として流動的だが、Googleはこれらのツールの多くをAndroid OSにも拡大することを計画している。これは広告業界に重大な影響を与えることになるだろう。 とはいえ、まだ広告エコシステムに関わっている人たちが絶望する必要はない。Googleによると、これらの新しいシステムをテストする間、現行のシステムは「少なくとも」あと2年間は有効のままになるとのこと。 通常、Androidでは、広告主はGoogleの広告IDを利用して、パーソナライズされた広告を提供したり、アプリケーション間でユーザーの行動を追跡したりする。これによって広告主は、例えば、あなたが商品を購入したのは、あなたがクリックした広告によるものだと、判断することができるというわけだ。簡単に言えば、広告IDはAndroid版のCookieと考えてよいだろう。ユーザーはAndroidの「広告」設定から、広告IDを削除することにより、この機能をオフにして、パーソナライズされた広告を拒否することができる。広告IDを削除すると、Googleは親切にも、広告が多くのサービスの無料化に貢献していることを気づかせてくれる。そしてそれこそが、Googleが今回の変更を行う理由でもある。 この発表に先立って行われたブリーフィングで、GoogleのAndroidセキュリティ／プライバシー担当プロダクトマネジメントVPは、特に広告の重要性を強調した（もちろん、広告はGoogle自身の収益においても大部分を占めている）。 「このエコシステムにとって重要な機能を強調することは有益なことです」と、VPは語った。「広告IDのようなツールは、より適切な広告体験の提供や不正行為への対処などに役立ちます。また、現在私たちがモバイルアプリで楽しんでいる無料コンテンツやサービスの多くを可能にするためにも役立っています。ですから、次世代のモバイル技術を構築する際には、こうした機能が確実にサポートされるようにすることが重要なのです」。 ここで問題となるのは、もちろんApple（アップル）だ。アップルは、Googleのチームが極めて露骨な手段と見なすようなものを使って、本質的にトラッキングを不可能にしている。これはプライバシーにとっては好都合だが、広告主は絶望の中から必死に這い上がって、あなたの行動やデバイスを追跡する新しい方法を考え出し、有益なトラッキングデータを手に入れようとするだろうと、Googleは主張する。しかし、Meta（メタ）が、アップルのポリシー変更によって、2022年には100億ドル（約1兆1500億円）の広告収入を失うだろうと述べたという事実は、Googleの主張を否定するようにも感じられる。Metaがこの問題を回避する良い方法を見つけられないのであれば、他の誰が見つけられるというのだろう？ そこで、Chromeと同様に、Googleはユーザーのプライバシー保護と広告エコシステムの維持という両方を実現しようとしているのだ。念の為にはっきりさせておくと、Googleは自社の広告システムも、サードパーティの広告主と同じルールに従うとしている。 今回の提案の中には、GoogleがChromeで行ってきたことをベースとするものがある。その中には、FLoC（フロック、コホートの連合学習）に代わって最近導入されたTopics（トピックス）や、個体識別子に依存することなく、広告主が独自に定義した「カスタムオーディエンス」に基づいて広告を表示することができるシステムのFLEDGE（フレッジ）が含まれる。 アトリビューションレポートなくして現代の広告エコシステムはありえないため、Googleはここでも新しいシステムを提案し、広告主が必要とするデータを提供し続けながらも、ユーザーのプライバシーを改善することを約束している。 また、開発者向けのSDKでは、サードパーティの広告コードを分離し、アプリ自体のコードとは別に実行されるようにする予定だ。現時点では、これはAndroid 13のみの機能になるようだ。なぜなら、これらの新しいプライバシー機能に加えて、あらゆるSDKに追加のセキュリティ保証を提供するという両方を重視した、全体的に異なるSDKアーキテクチャが必要だからだ。 Googleは、この新しいシステムについて、広告業界と連携していきたいと述べている。これまでのところ、これをサポートする意見は、広告エコシステムではなくアプリ開発者から多く寄せられている。 画像クレジット：rylan9 / Getty Images ［原文へ］ （文：Frederic Lardinois、翻訳：Hirokazu Kusakabe） Original Post>

　Google Cloudが、クリプトジャッキングを検出する新たなセキュリティ機能を発表した。 Googleは米国時間2月7日、「Virtual Machine Threat Detection（VMTD）」のパブリックプレビュー版を「Security Command Center（SCC）」で提供開始したことを明らかにした。SCCは、セキュリティの脆弱性や構成ミスがないかスキャンして、クラウドアセットに対する脅威を検知するプラットフォームだ。 製品マネージャーのTimothy Peacock氏は、組織のクラウド移行が進むのに伴い、仮想マシン（VM）ベースのアーキテクチャーがワークロードを扱うことが多いと述べた。 クラウド環境はまた、価値のあるデータを狙うサイバー攻撃者や、仮想通貨をマイニングするマルウェアを仕掛けようとする者たちの主要な標的にもなっている。 「XMRig」のような仮想通貨マイニングツールは、合法的なプログラムだ。しかし、攻撃者によって仮想通貨マイニングツールが悪用され、クラウドシステム上で許可なく使用されるおそれがある。 クリプトジャッキングと呼ばれる攻撃では、侵害されたシステム上にマイニングツールが配置され、このツールがコンピューティングリソースを不正に使用する。Monero（XMR）を含む仮想通貨は、往々にしてこの方法でサイバー犯罪者によって採掘され、マルウェアの運営者が管理するウォレットに送られる。 Googleの最新の「Threat Horizons」レポート（PDF）によると、最近に不正アクセスを受けたインスタンスの86％は仮想通貨のマイニングに利用され、10％は他の脆弱なインスタンスのスキャンを実行するのに利用されたという。 Google Cloudで運用されているVMに対するクリプトジャッキング攻撃の脅威に対抗するため、VMTDソリューションはSCC内で「エージェントレス型メモリースキャン」を実行する。 Googleのアプローチは、感染の疑いがあるシグナルの収集をハイパーバイザー（VMを実行するソフトウエア）に指示するというものだ。VMTDは、仮想通貨マイニングを検出する手段としてスタートし、パブリックプレビュー版から正式版になる段階で、Google Cloudの他の機能と統合される予定だ。 ユーザーはSCCの設定でVMTDを有効にすることで、試用できるようになる。このサービスはオプトイン方式で、ユーザーはスキャンする範囲を選択できる。 この記事は海外Red Ventures発の記事を朝日インタラクティブが日本向けに編集したものです。…

人気のカレンダーアプリ、Fantastical（ファンタスティカル）の開発元であるFlexibits（フレクシビッツ）は、スケジューリングを便利にする新機能をいくつか追加した。この分野は、Calendly（カレンドリー）が支配しているようだが、Flaxbitsはアプリの「Opening（オープニング）」機能を、プライバシーファーストのスケジューリング機能だと強調している。そして、もちろん新機能はFantasticalに直接組み込まれ、別のツールやサービス、サブスクリプションなどは不要だ。

Google（グーグル）は米国時間2月8日、Safer Internet Day（セーファーインターネットデー、SID）に合わせて、Googleアシスタント、Google Fi、Google Oneを含むさまざまなアプリやサービスの新機能とともに、安全なオンライン体験に関する情報提供の拡大を目的としたパートナーシップを発表した。特に、教育系非営利団体であるKhan Academy（カーンアカデミー）に500万ドル（約5億8000万円）を寄付し、無料のオンラインセーフティレッスン開発を委託するとのこと。また、Googleは非営利の政策・政治団体と協力して「Campaign Security Project（キャンペーンセキュリティプロジェクト）」という新しい取り組みを行っている。このプロジェクトは、2022年の米国中間選挙に向けて、選挙の候補者やキャンペーン担当者にオンラインセキュリティに関するトレーニングを行うことを目的としている。 後者のプロジェクトのパートナー団体には、Veterans Campaign、Collective Future、Women’s Public Leadership Network、LGBTQ Victory Institute、Center for American Ideas、サンフランシスコ大学、Emerge、Latino Victoryなどが含まれている。米国外でも、Googleは国際選挙制度財団（International Foundation for…

2022年2月9日(水)麻生川 静男 ドイツの総合重電機メーカー、シーメンス（Siemens）。その企業スローガンは“Infinite opportunities from infinite data（無限大のデータから無限大の可能性が広がる）”である。新製品やそれに関連するトピックから、デジタル化を強力に推進するシーメンスの取り組みと根底にある戦略を紹介する。 　ドイツだけでなく、欧州を代表する重電機メーカーのシーメンスがデジタル化を加速させている。その成果の一部を一気に見ていくことにしよう。 CO2排出量管理システム「SiGreen」 SDGs（Sustainable Development Goals：持続可能な開発目標）の観点から、CO2排出の削減が大命題となっている。取り組みにあたって、企業はどのぐらいCO2を排出しているのか、またそれぞれの製造行程でどれぐらい排出しているのかを正確に知る必要がある。そのためには、メーカーだけの情報では不十分で、サプライヤー、顧客、パートナーが、それぞれのCO2排出量（いわゆるカーボンフットプリント）に関するデータを交換できなければいけない。 シーメンスの「SiGreen（シーグリーン）」は、これら複数の企業にまたがって製造過程におけるCO2の実排出量に関する情報の検索、計算、情報共有を可能とするシステムである。このシステムのために、同社は分散型台帳技術（DLT：Distributed Ledger Technology）を使った業界横断型のオープンなネットワーク「Estainium」を立ち上げた。 SiGreenでは、分散型アーキテクチャの利点を生かしてハイレベルのデータ保護が保証されている。DLTと共に、暗号化された証明書を交換する仕組みにより、企業は機密情報の漏洩を心配することなく、データを交換することが可能になっている。メーカーだけでなく、関連する企業や顧客のすべてがCO2排出量データを共有することができる。 製造業マーケットプレイス「Industrial Edge」 「Industrial Edge」は、シーメンスが運営する製造業マーケットプレイスである。ここには、シーメンスのエッジアプリケーションだけでなく、Braincube、Cybus、Seio Tec、TOSIBOXなどのゲートウェイを介してサードパーティも出品できる。実際に出品されている製品としては、接続端子、ハードディスク、データ視覚化ソフト、データ解析から、デバイス監視、エネルギー管理、資産管理にまで広範である。 技術的な基盤として、Industrial…

　Googleは米国時間2月3日、個人が職場で使用できる同社の生産性スイートの無償版である「Workspace Essentials Starter」をリリースしたと発表した。これは、同社の生産性ツールを日々の生活の中で個人的に使用しており、職場のレガシーなテクノロジーを使わずに済ませたいと考えている膨大な数のコンシューマーに向けた製品だ。 提供：Google Essentials Starterでは、「Docs」や「Sheets」「Slides」「Drive」「Meet」といったGoogleの人気ツールを利用できるが、「Gmail」アカウントへのアクセスは含まれていない。ユーザーはその代わり、会社から与えられている電子メールアドレスを用いてサインアップする。こうしたアカウントがいったん確認されれば、ユーザーはすぐにEssentials Starterを使用し、コラボレーションに向けて他の人々を招待できるようになる。 またユーザーは、ファイル形式を変換することなく、既存のツールを用いて作業できる。「Microsoft Office」ドキュメントやPDFを含む100種以上のファイルの保存や共有、編集が可能となっている。さらにEssentials Starterはファイルの暗号化やセキュアなアクセスを提供する。 「Google Workspace」のマーケティング担当バイスプレジデントであるKelly Waldher氏は米ZDNetに対して、「従業員が大局的な観点から、自らどう働きたいのかや、誰のために働きたいのかという決定を下す時期に（この新製品を）投入する」と述べ、「われわれは、この新製品を提供することで、従業員らが自らにとって最適な意思決定を下せるよう支援し続ける」と続けた。 さらに、これは「モダンなコラボレーションツールセットを採用し、現在のハイブリッドな作業環境を念頭に置いて開発されていないレガシーなテクノロジースタックを使い続ける必要がない」ことを意味していると同氏は続けた。 Google Workspaceは大半のデジタルコミュニケーション／コラボレーションツールと同様、新型コロナウイルス感染症（COVID-19）のパンデミックによって拡大してきたリモートワークやハイブリッドワークというトレンドの恩恵を受けている。Waldher氏は、ビデオ会議ツールの「Google Meet」が過去2年間で特に大きく伸びてきていると付け加えた。 このパンデミックによってビデオ会議ツールに対する関心が高まったことを受け、GoogleはMeetに対して多大な投資を実施した。また同社は、生産性向上ツールのラインアップを全面的に刷新し、2020年10月には「G Suite」として知られていたツール群をWorkspaceという名称にリブランディングした。 2月1日に開催された第4四半期決算（10～12月期）発表後の電話会議において、GoogleはWorkspaceの売上高の成長について、シート数と1シートあたりの平均売上高の双方が堅調に伸びたことによるものだと説明した。 この記事は海外Red Ventures発の記事を朝日インタラクティブが日本向けに編集したものです。

DeepMind（ディープマインド）は、任意の問題を解決するためにコードを書くことができるAIを開発した。このAIはコーディングチャレンジに参加し、中間あたりの成績を収めたことで実証されている。まだソフトウェアエンジニアの仕事を奪うまでには至っていないが、基本的な作業の自動化に役立つ可能性がある。 Alphabet（アルファベット）の子会社であるDeepMindのチームは、できる限り多くの形で知能を創造することを目指しており、最近ではもちろん、多くの優秀な頭脳が取り組んでいる作業としてコーディングが挙げられる。コードは、言語、論理、問題解決の融合であり、コンピュータの能力に自然に適合すると同時に、難題でもある。 もちろん、このような試みは初めてではない。OpenAIには独自の自然言語コーディングプロジェクト「Codex」があり、GitHub Copilotと、Microsoftが提供する、GPT-3にコードを完成させるテストの両方を支えている。 関連記事：OpenAIが自然言語AIコーダーのCodexをアップグレード、プライベートベータを開始 DeepMindの論文では、競技プログラミングを狙う理由を説明する中で、フレンドリーながらも競争相手を遠回しに侮辱している。 近年の大規模な言語モデルは、コード生成能力に優れており、簡単なプログラミングタスクをこなすことができるようになってきた。しかし、これらのモデルは、単に命令をコードに変換するだけでなく、問題解決能力を必要とする、より複雑で見たことがない問題で評価すると、いまだに性能が低い。 それについてOpenAIは言いたいことがあるかもしれないが（そして、同社の次の論文ではこの点についての反論が期待できるだろう）、研究者たちが指摘するように、競技プログラミングの問題は一般的に、既存のコードAIには見られないレベルの解釈と創意工夫の組み合わせを必要とする。 DeepMindは、この分野に挑戦するために、GitHubの厳選されたライブラリと、コーディング問題とその解決策のコレクションを使って、新しいモデルをトレーニングした。言葉にすると簡単に聞こえるが、些細なことではない。完成したモデルを、この種のコンテストを主催するCodeforcesが最近開催した（言うまでもなく、AIはそれ以前に見ていない）10のコンテストに投入した。 その結果、50パーセンタイルを少し超える中位の成績を収めた。人間であれば中途半端な成績かもしれないが（決して簡単ではない）、機械学習（ML）モデルの最初の試みとしては、かなり注目に値する。 CodeforcesのMike Mirzayanov（マイク・ミルザヤノフ）CEOはこう述べている。「AlphaCodeの成績は、私の期待を超えていたと断言できます。なぜなら、競技プログラミングでは単純な問題であっても、アルゴリズムを実装するだけでなく、それを発明することも求められることが多いので（これが一番難しい）、半信半疑でした。AlphaCodeは、新人の有望なコンペティターと同レベルの性能を発揮してのけました」。 AlphaCodeが解決した課題とそのソリューションの一例は以下の通り。 画像クレジット：DeepMind （DeepMindへのメモ：SVGはこのような図には厄介なフォーマットだ。） ご覧のとおり、これは賢いソリューションだが、エンタープライズ向けSaaS級のものではない。心配無用、それはもっと先の話だ。今は、このモデルが複雑に書かれた課題を一度に解析して理解し、ほとんどの場合、首尾一貫した実行可能な回答を生み出すことができると示すだけで十分だ。 DeepMindチームはこう書いている。「コード生成に関する私たちの探求には改善の余地が大きく残されており、将来はプログラマーの生産性を向上させ、現在コードを書いていない人々にもこの分野を開くことができるような、よりエキサイティングなアイデアを示唆しています」。最後の部分は、筆者に当てはまる。もしAlphaCodeがCSSでレスポンシブレイアウトを変更できるなら、私よりもよほど優れている。 こちらのデモサイトでは、AlphaCodeがどのように構築されたのか、また、さまざまな問題に対するAlphaCodeの解決策をより詳しく見ることができる。 画像クレジット：Krisztian Bocsi/Bloomberg / Getty Images…

Scale AI（スケールAI）が73億ドル（約8400億円）企業になるまでの道には、画像、テキスト、音声、動画などのリアルデータが敷き詰められていた。現在、その基盤を利用し、AIで最もホットで新しいカテゴリーの1つであるシンセティック（合成）データゲームに参入する。 同社は米国時間2月2日に、機械学習エンジニアが既存の実世界のデータセットを強化するために使える製品「Scale Synthetic」の早期アクセスプログラムを発表した。同社は、この新しい部門を立ち上げるために2人の幹部を採用した。Nines（ナインズ）で機械学習の責任者を務め、Apple（アップル）で3Dマッピングのコンピュータビジョンエンジニアを務めたJoel Kronander（ジョエル・クロナンダー）氏をシンセティックデータ部門の新責任者として、また、Vivek Raju Muppalla（ビベク・ラジュ・ムッパラ）氏をシンセティックサービス部門のディレクターとして採用した。ムッパラ氏は、Unity Technologies（ユニティ・テクノロジーズ）でAIとシミュレーションのエンジニアリングディレクターを務めた人物だ。 シンセティックデータとは、その名の通り、現実世界の情報を使わず、機械学習アルゴリズムによって作成された偽のデータのことだ。医療用画像など、プライバシーが重視されるデータを作成する際に、強力で便利なツールになり得る。開発者はシンセティックデータを使って学習モデルをより複雑にし、収集された実世界のデータセットに散見されるバイアスを取り除くことができる。 Scaleは当初、人がラベル付けした実際の画像、テキスト、音声、動画データとソフトウェアを組み合わせ、自動運転車メーカーに機械学習モデルの学習に必要なラベル付きデータを提供していた。機械学習モデルは、ロボタクシー、自動運転トラック、倉庫やオンデマンド配送に使われる自動ボットの開発と配備に使われる。その後、このスタートアップは、政府、金融、eコマース、自動運転車とエンタープライズ産業などを顧客とするデータ管理プラットフォーム企業へと変貌を遂げた。 創業者でCEOのAlexandr Wang（アレクサンドル・ワン）氏は、この新しいサービスをデータへのハイブリッドアプローチだと表現し、実験室で育てられた肉にたとえた。 「研究室で育てられた肉が本物の動物の細胞から始まるように、私たちは本物のデータから始まり、そこから製品を育て、開発・構築していきます」と同氏はTechCrunchに語った。実世界のデータをベースにしてシンセティックデータを作成することで、実にユニークで強力なサービスを顧客に提供することができると同氏は述べ、同社は市場にそうしたギャップがあると見ていると付け加えた。 Scaleの顧客も、そのギャップを感じていたようだ。同社がシンセティックデータに力を入れたのは、顧客からの需要に応えるためだったとワン氏はTechCrunchに語った。この製品の開発を始めてから、まだ1年経たないという。自動運転車技術開発企業のKodiak Robotics、Tractable AI、米国防総省はいずれも、Scaleの新しいシンセティックデータ製品を採用していると同氏は述べた。 現在、約450人の従業員を抱えるScaleは、シンセティックデータを2022年の最優先事項として捉えており、製品ラインを充実させるために投資を続ける分野だとしている。しかし、それはリアルデータ事業を引き継ぐことを意味するものではない。ワン氏はシンセティックデータを、開発者が「アルゴリズムなどのAIや、特にエッジケースでより多くの利益を得られるようにするための補完的なツール」と考えている。 例えば、自動運転車の会社は通常、シミュレーションを使って現実世界のシナリオを再現し、その環境で自動運転システムがどのように対処するかを確認する。現実世界のデータでは、彼らが求めているシナリオは得られないかもしれない。 「例えば、100台の自転車が一度に横断するようなシナリオは、現実世界ではあまり遭遇しません」とワン氏は説明する。「現実世界のデータから出発して、すべての自転車や人を合成的に追加することで、アルゴリズムを適切に訓練することができるのです」。 画像クレジット：Getty Images ［原文へ］…

CNDT2021から、メルカリのエンジニアリング部門のマネージャーである中島大一氏によるマイクロサービスのセキュリティを強化するための施策に関するセッションを紹介する。 タイトルは「How We Harden Platform Security」 メルカリには「メルカリ」と「メルペイ」という2つの大きなサービスが存在し、それぞれがマイクロサービスとしてGCPの上のKubernetesに実装されている。合計200以上のマイクロサービスが、4000個以上のPodによって配備されているという。 メルカリとメルペイのサービスはマイクロサービスとして実装 メルカリは2020年のCNDTでもセッションを行っており、その際はメルペイ側のSREである高木氏が講演を行い、デベロッパー自身が運用まで行うという特徴的な体制について解説を行っている。今回の中島氏の講演でも、運用に専任しているエンジニアはおらず、プラットフォームの自動化などを行うエンジニアが存在するという内容を解説した。 参考：CNDT2020シリーズ：メルペイのマイクロサービスの現状をSREが解説 メルカリの開発組織の概要 メルカリ全体のセキュリティを強化するための施策について、3つのポイントに絞って解説を行ったのが今回のセッションである。基本はそれぞれのレイヤーにおいてのセキュリティを確保するだけではなく、多層防衛として複数のレイヤーに跨った深い防御を行うことが重要だと解説し、今回はその中から3つを紹介している。 3つのポイントでセキュリティを強化 開発環境におけるセキュリティ メルカリのプラットフォームは、マルチテナントを前提としてKubernetesのネームスペースによって分離されている。その際に特権の付与については、最低限必要なものだけを与える「Least Privilege」を基本としているという。 最低限の特権だけをテナントに渡す方針 これは実行環境であるKubernetesとアプリケーションをビルドするCI/CD開発環境においても適用されているおり、デベロッパーからビルドシステムへのアクセス、そしてビルドシステムからGCP上のKubernetesへのアクセスという2点において、最低限の特権を管理する方法が取られていると説明した。 実行環境だけではなくCI/CDにもLeast Privilegeを適用 Kubernetesにおいては、RBAC（Role Based…

Web 1.0とWeb 2.0はともに、セキュリティモデルがアプリケーションアーキテクチャーともに変更され、まったく新しい経済の扉を開いた。Web 1.0では、Secure Socekts Layer（SSL、セキュリティ・ソケット・レイヤー）がNetscape（ネットスケープ）によっていち早く開発され、ユーザーのブラウザーとさまざまなサーバーとの間の堅牢なコミュニケーションを可能にした。Google（グーグル）、Microsoft（マイクロソフト）、Amazon（アマゾン）などのWeb 2.0の信頼できる仲介者と認証機関は、SSLの後継となるTransport Layer Security（TLS、トランスポート・レイヤー・セキュリティ）の実装を加速する中心的役割を果たした。 同じことがWeb3でも起きようとしている。これが、新しいWeb3セキュリティ会社への投資が2021年10倍以上増えて10億ドル（約1兆1500万円）を超えた主な理由だ。 Web3の成功は、さまざまなアプリケーションアーキテクチャーが生み出す新たなセキュリティ問題を解決するイノベーションにかかっている。Web3では、分散型アプリケーション（dApps）が、Web 2.0に存在する伝統的アプリケーションロジックやデータベースレイヤーに依存することなく作られている。代わりにブロックチェーン、ネットワークノード、スマートコントラクトなどのプロトコルがロジックと状態の管理に使われている。 ユーザーは今までと変わらずにフロントエンドをアクセスし、そこからノードにつながってデータの更新、たとえば新しいコンテンツの公開や商品の購入などを行う。この手順では、ユーザーが各自のプライベートキー（秘密鍵）を使って取引を承認する必要があり、通常秘密鍵はウォレットで管理される。これはユーザーのコントロールとプライバシーを保護することを目的としたモデルだ。ブロックチェーンを利用した取引は完全に公開されていて、誰もがアクセス可能でイミュータブル（改変不可能）だ。 どんなシステムでも同じだが、このデザインにはセキュリティとのトレードオフがある。ブロックチェーンでは、Web 2.0のように行為者が信頼されている必要がなく、セキュリティ問題に対応するための更新がより困難だ。ユーザーはアイデンティティに関する制御を自ら維持することができるが、アタックを受けたり、キーを悪用された時に助けてくれる仲介者は存在しない（Web 2.0プロバイダーは、盗まれた財産を復活させたりパスワードをリセットできる）。ウォレットも、Ethereum（イーサリアム）アドレスなどの重要情報を漏らす可能性がある。ソフトウェアである限り完璧にはなりえない。 こうしたトレードオフは、当然ながら重大なセキュリティ上の懸念を喚起しているが、それによってWeb3の機運が削がれるべきではなく、実際その可能性は低い。 改めてWeb 1.0、Web 2.0との類似点を見てみよう。SSL/TLSの初期バージョンには致命的な脆弱性があった。かつてのセキュリティツールはよくいって原始的であり、時間とともに堅牢になっていった。Web3のセキュリティ会社やプロジェクト、たとえばCertik（サーティック）、Forta（フォータ）、Slither（スリザー）、Securify（セキュリファイ）などは、Web 1.0やWeb 2.0アプリケーションのために当初開発されたコードスキャニングやアプリケーションセキュリティテスティングのツールに相当する。…