Category: General

多くの機械学習デベロッパーの方々が、AWS 上でさまざまなアルゴリズムの開発やモデルの構築を行なっています。中でも自然言語処理を行う際には、対象言語の言語ごとの辞書データや単語ベクトルデータを用いることが一般的です。これらのデータは GB 以上のサイズにおよび、また計算の際にも大量の GPU および CPU を必要とするため、従来こうしたモデルを構築する際には常にストレージおよびコンピューティングのリソースの調達が問題となってきました。AWS 上で自然言語処理モデルの開発を行う際には、Amazon SageMaker を用いて学習に必要なリソースを確保することで、ALBERT のような最新の言語モデルを利用することが可能です。 今回 AWS の Open Dataset に新しく、日本語自然言語処理で定番の形態素解析器である Sudachi の語彙（SudachiDict）および単語ベクトル（chiVe）のデータが加わりました。これらについて以下でご紹介します。 Sudachi Sudachi はオープンソースの日本語形態素解析器です。形態素解析では、主に文章のテキスト分割、品詞の付与、そして正規化処理を行います。Sudachi は従来の形態素解析器と比較して、(1) 複数のテキスト分割単位を併用することが可能、(2) UniDic や NEologd をベースとした多数の語彙を収録している、(3) プラグインによりさまざまな機能を追加可能、といった特徴を持っています。そのため日本語で自然言語処理を行う際に一般的によく利用されています。 SudachiDict SudachiDict は形態素解析器 Sudachi で利用されている語彙データです。収録語彙の範囲に応じた以下の 3 種類が提供されているため、用途に合わせて好きなものを利用することが可能です。 Small: UniDic の収録語とその正規化表記、分割単位を収録 Core: 基本的な語彙を収録 Full: 雑多な固有名詞まで収録 chiVe chiVe は大規模コーパスと複数粒度分割に基づく、日本語単語ベクトルです。自然言語処理において、2013 年に提唱された word2vec 以降、単語をベクトルに変換して機械学習モデル構築の中で利用するのは、非常に一般的なアプローチとなっています。chiVe では、国立国語学研究所の日本語ウェブコーパス（NWJC）に対して、Sudachi による分かち書きを用いています。chiVe は、オープンソースの日本語自然言語処理ライブラリである GiNZA と組み合わせて利用することもでき、それにより高精度なモデル開発を行うことが可能です。 […]

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も週刊AWSをお届けします。 10月に入りましたね。先月は初のオンライン開催となった AWS Summit Online Japan が開催されていましたが、今月はエンジニア向けイベントAWS Dev Day Online Japanが開催されます。2020年10月20日（火）～22日（木）、こちらもオンラインで開催されます。キーノートにはJavaの産みの親ジェームス・ゴスリンが登壇する等、見どころ満載になっていますのでぜひこちらもご参加いただければと思います。 それでは、先週の主なアップデートについて振り返っていきましょう。

このブログは株式会社レンガ 取締役 開発担当 小原 和磨 氏により寄稿され、AWS Japan ソリューションアーキテクト 金杉 有見子 が編集したものです。 株式会社レンガは 、月間100万人以上に利用されている日本最大級のマンションの口コミ・評価サイト『マンションノート』を運営している会社です。マンションノートは日本全国にあるマンション・アパートの「口コミ」と「ランキング」を見ることができるWEBサービスです。マンションの住人をはじめとして、元住人、周辺住人、専門家、不動産会社、物件オーナーなど、あらゆる立場の方々が自分の立場を表明し、マンションに対する生の意見・評価を投稿・共有します。その集合知により、マンション検討者が（住む前に）住んだ後のリアルな生活を想像できるようになり、大切な住まい選びにおいて“こんなはずではなかった”、“別のマンションを選べば良かった”といった後悔を世の中からなくすことを目的としております。 エンジニアは私を含め合計6名在籍しています。レンガはコードクオリティを非常に重要視しているため、コードレビューは私たちの開発において欠かせないプロセスです。しかし、開発量に比例してコードレビューのタスクが増えるため、レビュアーの負担が大きいという課題がありました。また、レビューを重ねたとしても見落としてしまうバグは存在するため、より網羅的にコードレビューを行える仕組みを必要としていました。

本投稿は AWS サーバーレス アプリケーションのシニアデベロッパーアドボケートである Benjamin Smith による寄稿です。 本シリーズの他のパートは以下のリンクからアクセスできます。また、関連するサンプルコードはこちらの GitHub リポジトリにあります。 パート1：サーバーレス LAMP スタックの紹介 パート2：リレーショナルデータベース パート3：Webサーバーの置き換え パート5：CDK コンストラクトライブラリ パート6：MVC からサーバーレスマイクロサービスへ この投稿では、サーバーレスアプローチで Laravel アプリケーションをデプロイする方法を学びます。 これは「サーバーレス LAMP スタック」シリーズの4番目の投稿になります。過去の投稿はこちらです。 パート1：サーバーレス LAMP スタックの紹介 パート2：リレーショナルデータベース パート3：Webサーバーの置き換え Laravel は PHP 用のオープンソースの Web アプリケーションフレームワークです。フレームワークを使用すると、開発者は一般的なコンポーネントとモジュールを再利用することで、より速く構築できます。また、開発標準に準拠することにより、長期的なメンテナンスにも役立ちます。ただし、従来の LAMP スタックを使用して PHP フレームワークをスケーリングする場合は、まだ課題があります。サーバーレスアプローチを使用してフレームワークをデプロイすると、これらの課題の解決に役立ちます。 Laravel アプリケーションのサーバーレスインフラストラクチャへの展開を簡素化する方法は数多くあります。ここで紹介する方法では、AWSサーバーレスアプリケーションモデル（AWS SAM）テンプレートを使用しています。これによって、Laravel アプリケーションが単一の Lambda 関数にデプロイされます。この関数は、Bref FPM カスタムランタイムレイヤーを使用して PHP を実行します。AWS SAMテンプレートは、「サーバーレス LAMP スタック – パート3: […]

ヘルスケア・ライフサイエンス ソリューション部では、お客様の課題に対してAWSの技術支援やアーキテクティングを実施しておりますが、支援の一つとしてプロトタイピングを提供しています。今回は、塩野義製薬株式会社(データサイエンス室、デジタルインテリジェンス部)、シオノギデジタルサイエンス株式会社と行った、モバイルアプリ開発のプロトタイピングを報告致します。プロトタイピングでのクイックな開発を実現するにあたり、共同でリアルタイムにコーディング可能な統合開発環境(IDE)であるAWS Cloud9と、フロントエンドの実装から、認証、AI、データ登録・参照、Amazon S3に蓄積したログの分析といったバックエンド実装までをAWS Amplifyを利用することで2日間でアプリ開発を行いました。

こんにちは、IoTソリューションアーキテクトの飯塚です。本記事では、新規の公開したAWS IoT Coreハンズオンについてご紹介します。

こんにちは、AWSソリューションアーキテクトの小林です。 今日の東京はすがすがしい秋晴れの一日でした。9月はカラッと晴れる日が少なくどんよりした天気が多かったのですが、たまにカラッと晴れると気持ちがいいですね。気温も過ごしやすく湿度も低いという爽やかな一日でした。こういった日が週に一度くらいあるといいなぁと思いますが、なかなかままならないものです。 それでは、先週の主なアップデートについて振り返っていきましょう。

セキュリティの向上とユーザーエクスペリエンスの強化、AWS Identity との将来の互換性のために、AWS Single Sign-On (SSO) はサインインプロセスの変更が予定されています。一部の AWS SSO のユーザーに影響を与えるこの変更は、2020 年 10 月上旬に実施される予定です。

バーゼル規制フレームワークは、規制裁定取引を防止するために、金融機関のトレーディング勘定とバンキング勘定の厳密な区分けを目指しています。これらの規制のトレーディング勘定要素 の見直し(FRTB：トレーディング勘定に関する抜本的見直し) は、厳格なリスクモデリングを適用することと引き換えに、金融機関が資本準備金のレベルを最適化できるようにすることでトレーディングのリスク管理を強化することを目指しています。FRTB は、資本準備要件を最小限に抑える内部モデルアプローチ (IMA)、または実装が容易な標準化アプローチ (SA) といった、十分に規定されたメカニズムの 1 つを適用することでリスク管理を追求することを金融機関に求めています。バーゼル III モニタリング報告書 (2019 年 10 月) によれば、欧州の大手銀行では、全体的な必要最小資本 (MRC) が 18.6% まで上がる可能性があることを示しており、個々の銀行への影響は、SA と IMA のどちらを使用してリスク資本要件を計算するかによって左右されます。限定的な影響度調査では、SA よりも IMA を導入する方が、資本効率を最大 10% 最適化できると結論付けています。しかし、期待に反して、市場分析では IMA の採用が減少していることを示されています。SA と比較して、IMA の実装はかなり複雑で費用がかかると認識されているため、いくつかの銀行は、IMA の計算適用について十分に調査しそのメリットを定量化しています。すべての銀行が SA を採用した場合は、システムリスクの可能性があるため、規制当局は、グローバルなシステム上重要な銀行 (G-SIB) がグローバルかつ体系的に IMA を実施することを求めています。この記事では、IMA と SA のどちらを実装するかに関係なく、リスクマネージャーとトレーディングデスクの責任者が、これらの課題に対処するためにこれまでのレガシーな IT システムを超える手段を検討しなければならない理由について説明します。

先日(2020/9/10)開催しました 第1回  Amazon RDS Online Seminar「Amazon Aurora と RDS Proxy」
の資料・動画を公開しました。当日、参加者の皆様には数多くの QA を頂きありがとうございました。
頂いた QA の一部についても共有しております。