間質性肺炎を検出するAIを開発し、その有効性を検証した研究を論文化しました - エムスリーテックブログ
こんにちは、AI・機械学習チームの浮田です。最近、私が筆頭著者の論文が公開されたので、今回はその紹介をします。 発表した論文はこちらです： www.ncbi.nlm.nih.gov この論文では、 胸部X線 (レントゲン) から間質性肺炎を検出するAIの評価を行いました。 結果、このAIを使うことで医師の読影成績が統計的有意に改善しました。 このAIを使うことで間質性肺炎の見落としを減らすことができることが期待されます。 エンジニアリンググループで論文を書くのは珍しい機会でしたが、査読対応など大変な時も経て無事公開することができました。 図1. 今回開発・検証した医療AIの実際の画面。プレスリリースより転載 今回開発・検証した医療AIの概要 有効性を検証するための臨床試験 目的 データセット、実験設定 結果 評価方法の詳細 感想 We're hiring! 今回開発・検証した医療AIの概要
機械学習で逆ストリートビューを作り、写真から港区らしさを判定する - エムスリーテックブログ
テストデータでの予測結果 先日新橋を散歩していたときの会話。 妻 "こういう路地って新橋らしさあるよねー" 私 "本当です？どういうところで当てられるの？" 妻 "歩道の雰囲気？" 私 "うーん" ということで、MLエンジニアたるもの、そんなことが本当にできるのか機械学習で検証してみましょう。 写真から撮影場所を当てる 作るもの 港区らしさとは 柵でわかる中央区・千代田区・江東区 最もXX区に間違えそうなYY区の写真とは 技術的な話 参考論文: PlaNet Google Streetview API と Geolonia API 学習について 他の地域の分類機を作る 自分の撮った写真の地域を当てる Limitation まとめ We are hiring! おまけ: モデルと勝負！ 写真から撮影場所を当てる こんにちは、AI・機械学習チームリーダーの大垣(id:Hi_king)です。 こ
SREの民主化とクラウド移行 - エムスリーテックブログ
あけましておめでとうございます。今日から02/05までの平日にエムスリーのSREでブログリレーを開催します。その初日の投稿を担当させていただくエムスリーエンジニアリンググループの岩佐です。グループリーダーという立場でSREチーム、基盤チーム、セキュリティチーム、Unit4(m3.com/サイトプロモ)を担当しています。 私からはエムスリーでSREを拡大しようと推進している経緯/流れについて一筆認めさせていただこうかと思います。 要約、早速だけど 経緯、メンバーに敬意を、チームに契機を 方針、状況に合わせて更新 計画、そして軽快に改革 まとめ、ちょっとまともに 要約、早速だけど SREを短期的に大量に採用するのは不可能、じゃないかのう？ オンプレミス環境で拡大していくサービス群をSREチームのみが運用していくのは難しい。こんなん困難では？はー、どうしよう 権限の移譲、DevOpsの推進をする
たくさんのオンプレサービスをひたすらクラウドに移して得られた知見まとめ - エムスリーテックブログ
こんにちは、エムスリーエンジニアリンググループの福林 (@fukubaya) です。 本記事はエムスリー Advent Calendar 2020 の8日目の記事です。 この記事とかこの記事とかこの記事で 書いているように、弊社ではオンプレ環境で稼動するサービスのAWSやGCPへの移行が進行中で、 ここ数ヶ月でクラウド移行作業が自分の業務の9割を占めています。 いろんなサービスのクラウド移行(主にECS Fargate)をやってきて知見が貯まってきたので一旦まとめてみます。 当初は何を考慮しなければいけないのかもよく分かっていませんでしたが、数をこなした結果、気をつけるポイントが分かってきました。 Docker化してECS Fargateで動かすのが目標ですが、GCPでk8sでも基本的に考える点は共通だと思います。 秩父ミューズパークは、埼玉県秩父市および秩父郡小鹿野町にまたがる地域にある
社内サービスを一括・即座・セキュアにリモートワーク開放した話 - エムスリーテックブログ
はじめまして。 エムスリーエンジニアリンググループSREチームの山本です。 先日来のリモートワーク促進の中、弊社でも多くの社員がオフィス外から接続するようになりました。 もちろん、VPNを利用すれば社内のサービスも利用できますが、VPNの使用量が一気に増えるとそちらの制限にかかります。 今回「VPNを可能な限り利用せず、なおかつセキュアに社内のサービスを利用してもらう」という課題に取り組みましたので、ここでその紹介をさせてください。 前提 方針 クライアント証明書の問題点 一括でのSSL化・証明書検証 ドメイン変換 実際の設定 Squidの設定(抜粋) unboundの設定 nginxの設定(クライアント証明書検証) nginxの設定(HTTPサーバに対するproxy) nginxの設定(個別対応) ブラウザのProxy設定 その後発生した問題 ポート問題 Hostヘッダ問題 戻りヘッダ問
タイムゾーンを考慮した日時の扱いのベストプラクティス - エムスリーテックブログ
こんにちは、server-side kotlin や terraform を書くことが多い、エンジニアリングGの矢崎(id:Saiya)です。 タイムゾーンや日時の扱いについての話題がホットな昨今ですが、 そういった日時の扱いについて例えば以下のようなお話を受けることが少なからずありました: とりあえず日時は UTC からの時差情報付きで扱えばいいんでしょ？ DB に保存するときもタイムゾーン情報付きで入れておけばいいんでしょ？ こういったお話を振られた際に、思うところを一言でサッと説明できずもやもやする事もあり、 また web サービスにおいて日時・タイムゾーン・オフセットをどう扱うべきか？納得の行く説明をあまり見つけられなかったため、 筆者なりに考えをまとめてみました。 国家的祭典のために急にサマータイムが導入されるといった話に限らず、 クラウドサービスが UTC+0 の日時になってい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
