みなさんこんにちは。 「ソフトウェアレビューをエンジニアリングっぽく捉える会」の”弦音”です。 今回は「何のためにやるの？」がテーマです。 ＜ソフトウェアレビューをエンジニアリングっぽく語ってみる　記事一覧＞ ※クリックで開きます 【第1回】［#0］イントロダクション 【第2回】［#1］レビューとは？ 【第3回】［#5］レビューの終わり方～レビュー評価・ふりかえり（1/2） 【第4回】［#5］レビューの終わり方～レビュー評価・ふりかえり（2/2） 【第5回】［#2］何のためにやるの？ レビューって、何してますか？ 「これ、レビューしておいて」「さて、レビューしようか」 さて、レビューと言われて何を思い浮かべますか？ 誤字脱字を探すのでしょうか。 仕様の抜け漏れを調べるのでしょうか。 設計や実装に問題がないかを評価するのでしょうか。 どれもレビューで行われることですが、これだけだとレビューの目的を十分に表しているとはいえません。 レビューでは、成果物を読み、内容をさまざまな観点から評価します。その結果、問題や改善の余地が見つかれば、指摘や提案として伝えます。 ここで見つける問題や改善の余地とはどのようなことでしょうか。 レビューで指摘すること レビューでまず思い浮かぶのは、成果物に含まれる欠陥をみつけることです。 ここでいう欠陥とは、成果物に含まれる不備があることや、要求・仕様に合っていないことを意味します。 たとえば、次のようなものです。 要求や仕様と異なる内容が記載されている お客様が本当にやりたかったことと仕様がずれている 計算式や条件分岐に誤りがある 必要な処理や仕様が抜けている 前提条件が考慮されていない 仕様の解釈が曖昧で、関係者によって理解が分かれる ドキュメント内に誤字脱字衍字がある このような欠陥は、発見した時点で指摘し、修正する必要があります。 しかし、レビューで扱うのは、すでに存在している欠陥だけではありません。 現在は問題なく動作するように見えても、将来、問題につながる可能性があります。たとえば、データ量が増えると性能が低下する恐れがある、構造が複雑なので保守が難しい、アクセス権限の設定が不十分である、といったケースです。これらはレビューでは欠陥ではなくリスクとして扱います(一緒に扱うこともあります)。 また、欠陥やリスクには該当しなくても、よりよい方法を提案できる場合があります。処理結果は同じでも、より効率的なアルゴリズムを選べるかもしれません。現在の仕様でも要求を満たしていても、別の仕様のほうが利用者にとって使いやすいかもしれません。 このように、レビューで指摘するものには、次の三つがあります。 欠陥 ：要件や仕様を満たさない不備や欠点 リスク ：将来、障害や損失につながる可能性 改善点 ：欠陥やリスクではないものの、よりよくできる点 レビューでは、これらを見つける(指摘する)ことが目的だ、と考えてよさそうです。 レビューで指摘するものの深堀（何に着目しているか） レビューで指摘する欠陥やリスク、改善点にはどのようなものがあるかもう少し見ていきましょう。 たとえば、次のようなものがあります。 表1　レビューで着目しているものの例 機能性 要求された機能を実現できるか 信頼性 障害が発生しにくく、発生時にも適切に対応で 効率性 性能に関すること。必要な処理速度やデータ量に対応できるか 安全性 不正アクセスや情報漏えいなどのリスクを抑えられているか 使用性 利用者にとって理解しやすく、操作しやすいか 保守性 将来の修正や機能追加を行いやすいか 運用性 監視、障害対応、バックアップなどを適切に行えるか 互換性 他のシステムや既存の仕組みと適切に連携できるか 法令・規約への適合性 関連する法令や規約、社内標準などに適合しているか レビューでは、対象となる成果物や開発の段階に応じて、必要な品質の観点から内容を評価します。 たとえば、要求された機能を実現していても、個人情報の扱いが不適切であれば、安全性や法令・規約への適合性に関する問題になります。 また、仕様に適合した処理であっても、プログラムの構造が複雑であれば、将来の変更時に欠陥を作り込むリスクが高まります。 このように、レビューの目的に、機能が成立しているかどうかだけではなく、利用者、運用、保守、性能、安全性、法令などの観点から、成果物に必要な品質が備わっているかを確認するということがあります。 問題を早い段階で発見する これらの問題は一部を除いて(この一部、は大事なので次で説明しますね)、テストで見つければいいじゃないか、と、思う人も多いでしょう。確かに、多くの問題はテストして(モノを動かして)見つけることができます。でも、レビューで見つけることの良さがあるのです。レビューを行うことの良さの一つに開発の早い段階で発見できる、ということがあります。 ソフトウェア開発では、要求、仕様、設計書、プログラムなどの成果物を順に作成していきます。 ある段階の成果物に欠陥やリスクが残ったまま次へ進むと、それらが後続の成果物に引き継がれます。 たとえば、要求に含まれる問題を発見しないまま仕様を作成し、その仕様をもとに設計や実装を進めると、後になって複数の成果物を修正する必要が生じます。 安全性や法令・規約への適合性に関する問題であれば、設計やデータの扱いを根本から見直さなければならない場合もあります。 一方、要求や仕様の段階で問題を発見して指摘できれば、その段階で修正できます。 問題の発見が後の工程になるほど、指摘後に必要となる修正の範囲や影響は大きくなりやすくなります。 そのためレビューの目的には、問題が後の工程へ広がる前に発見し、手戻りや将来のリスクを小さくするということもあるのです。 表2　欠陥の修正：レビューとテストの比較 項目 レビュー テスト 発見してから修正にかかる時間 短い(数分～数時間) 長い(数日～数週間) 修正に必要なプロセス 指摘されたところの修正、再レビュー 原因究明(デバッグ)、修正、ビルド、再現環境の構築、テスト 再確認方法 修正箇所をレビューアが確認 テスト、リグレッションテスト レビューでしか見つけられない問題 先ほど「問題は一部を除いて、テストで見つければいい」の、一部とはどのようなものでしょうか。既に答えの出ているものもありますが、このようなものがあります。 要求そのものがあいまい 記述があいまい 仕様と要求に齟齬がある 変更や保守、障害発生時の対応が難しい コードがコーディング基準に則っていない ドキュメントやコードが読みにくい ドキュメントやコードの管理がめちゃくちゃ 思い当たるものはありますか。このようにレビューでは要求や仕様の不備、設計上のリスク、保守・運用への影響、関係者間での認識の齟齬、標準への遵守、など、テストでは見つけにくい・見つけられない問題を指摘するという目的もあるのです。 複数の視点から評価する レビューは何人で行いますか？ ひとりで行うセルフレビューもありますが、チームや組織で行うものもあるでしょう。 レビューには、作成者とは異なる視点から成果物を評価するという意味もあります。 成果物を作成した人は、その内容や背景をよく理解しています。しかし、前提を疑わなくなったり、自分の見落としに気づきにくくなったりすることがあります。 別の人がレビューすることで、異なる知識や経験を取り入れられます。 データベース、性能、セキュリティ、過去の障害、利用者、運用など、それぞれの立場から成果物を評価することで、一人では発見しにくい欠陥やリスク、改善点が見つかることがあります。 たとえば、次のような指摘です。 「この処理は、データ量が増えたときに性能上のリスクになりそうだ」 「この仕様では、利用者が意図しない操作をする可能性があるのではないか」 「この設計では、将来の機能追加による変更範囲が大きくなりそうだ」 ひとりでレビューする場合でも、一晩寝かせておく、帽子をかぶりなおす(比喩表現です)など、違う人を演じると問題を見つけられるといったハックもありますね。 このように、レビューの目的として、作成者では発見しにくい問題や改善点を見つけ、成果物の品質を高めるということもありそうです。 過去の問題を繰り返さない 複数の人がレビューに参加し、問題や知識を共有することには、さらに別の意味があります。 それは、過去に発生した問題を、次の開発に生かせることです。 たとえば、以前のプロジェクトで、特定の条件を考慮していなかったために、本番環境で障害が発生したとします。 その経験を関係者の記憶だけに頼っていると、時間の経過や担当者の交代によって失われてしまいます。 そこで、過去の障害や問題から得られた知識を、チェックシートやデータベースとしてまとめておき、レビューで評価する観点として活用します。そうすれば、同じような成果物を作成するときに、過去と同じ問題がないかを検討できます。 レビューには、目の前にある成果物の欠陥やリスクを発見するだけでなく、過去の経験を組織の知識として蓄積し、同じ問題を繰り返さないようにする目的もあります。 レビューによって得られる副次的な効果 レビューを通して、作成者とレビュアーが互いの考えや前提を知ることもあります。 「この仕様は、こういう意図で作成されたのか」 「この処理には、このような前提があったのか」 このような理解が進めば、チーム内の認識合わせにつながります。 また、 「このアルゴリズムより、こうしたほうが性能が出る」 「この処理は××ライブラリを応用するとよい」 などの知見を得られることもあります。 さらに、 「この機能の実現はどうしたらよいか」 という議論に発展してしまうこともあります。（組織によってはレビューの場での議論は禁じられていることもあるので注意） このような場に同席することによって、経験の浅いメンバーは、経験者がどのような観点で成果物を評価し、どのような問題を指摘するのか、どのような知見があるのかといったことを学ぶこともできます。 このように、レビューにはコミュニケーションや教育、議論の場を提供するといった目的もあります。 ただし、これは、レビューの第一義の目的ではないでしょう。副次的な効果と捉えてよいと思います（諸説あります）。 まとめ：「レビューってなにするの？」にもいろいろある ここまで見てきたように、レビューと一口に言ってもいろいろな目的があることがわかりました。 成果物に含まれる欠陥を見つける（指摘する） 成果物に必要な品質が備わっているか確認する 問題が後の工程へ広がる前に発見し、手戻りや将来のリスクを小さくする テストでは見つけにくい・見つけられない問題を指摘する 作成者では発見しにくい問題や改善点を見つけ、成果物の品質を高める 過去の経験を組織の知識として蓄積し、同じ問題を繰り返さないようにする コミュニケーションや教育、議論の場を提供する 何を目的とするかによって、レビューで注目する点や、やり方は変わります。 レビューしようと思った時、目的は何かな？ということをまず考えてみてください。そうすればよりよいレビューをおこない、より良い結果を得ることになるでしょう。 この記事を担当したメンバー 弦音（ 吉澤智美／ @tulune ） 物を作るのは好きだけどじっくり壊すのも好き。ということで、レビューやらテストやらの集まりに生息。NPO法人ASTER テスト設計コンテスト担当理事。 https://aster.or.jp/testcontest/ 【連載】ソフトウェアレビューをエンジニアリングっぽく語ってみる｜記事一覧 【第1回】［#0］イントロダクション 【第2回】［#1］レビューとは？ 【第3回】［#5］レビューの終わり方～レビュー評価・ふりかえり（1/2） 【第4回】［#5］レビューの終わり方～レビュー評価・ふりかえり（2/2） 【第5回】［#2］何のためにやるの？ The post 【第5回】［#2］何のためにやるの？｜ソフトウェアレビューをエンジニアリングっぽく語ってみる first appeared on Sqripts .

2026 年 5 月 21 日から 23 日に開催された「第 21 回情報危機管理コンテスト」にて経済産業大臣賞 と AWS 賞 を受賞した 『ITソルーション室_げんこつ』 の皆様にインタビューを行いました。 情報危機管理コンテストは、企業インフラを模した環境で発生するセキュリティインシデントに対し、参加チームが調査・対応を行い、主催者が用意した窓口へ報告を行う実践的なコンテストです。今回はチーム編成や役割分担、コンテストへの準備に加えて、生成 AI の活用が進むなかでのインシデントレスポンスの変化についてもお話をうかがうことができました。インタビュー記事を通して、コンテストで得た学びや、これからのクラウド、AI 、自身のキャリアイメージなどをお伝えできればと思います。 ITソルーション室_げんこつ 静岡大学 総合科学技術研究科 情報学専攻 1 年 河口 欣仁 氏 情報学部 情報科学科 3 年 高島 湊斗 氏 総合科学技術研究科 情報学専攻 2 年 髙橋 陽拓 氏 情報学部 行動情報学科 4 年 齊藤 遼太 氏 日々の研究や活動について AWS : はじめに、日々どのような研究や活動をされていますか。 河口 : 教育分野での LLM エージェント活用を研究しています。個人的には Web 開発の経験が長く、アルバイトや受託開発のほか、AWS と関わりのある企業に 1 年ほど在籍していたこともあります。 齊藤 : サイバーセキュリティ領域で、バイナリの静的解析やデコンパイラの研究開発が専門です。セキュリティ・キャンプでは受講生・講師の両方を経験し、サイバー・スレット・インテリジェンス領域でのインターンも経験しています。 高島 : 自分で法人を立ち上げ、AI システムの PoC や業務システムの受託開発をしています。法人設立から半年ほど、個人事業も含めると数年ほどシステム開発に携わっています。 髙橋 : 生成 AI 系の研究で、オントロジーを AI に読み込ませ、背景の概念が変化したときにマッピングを自動化するテーマに取り組んでいます。 『げんこつ』 と ITソルーション室について AWS : ITソルーション室とはどのような組織ですか。 齊藤 : 静岡大学 情報学部の学生団体です。浜松キャンパスで IT やパソコンのトラブルを持ち込んでもらい、学生が一次対応として解決しています。年間 100〜200 件ほど対応しています。大学から部屋と予算をいただき、独自ネットワークの運用や勉強会、コンテスト出場といった活動をしています。アクティブメンバーは約 40 人で、浜松キャンパスの人なら誰でも入れます。 AWS : チーム『げんこつ』の成り立ちを教えてください。 齊藤 : もともと「 sawayaka-sec (さわやかセキュリティ)」というチームが 6〜7 年前に大木研究室から始まり、情報危機管理コンテストで受賞するなど実績を重ねてきました。そこから系譜が続き、当初は研究室メンバーが多かったのですが、次第に ITソルーション室のメンバーが増えました。今年は研究室系が私だけになったため、チーム名を「げんこつ」に変更しました。情報危機管理コンテストには通算 8 年参加しています。 コンテストでの役割分担 AWS : 今回の役割分担はどのように決めましたか。 齊藤 : 私がコマンダーとして全体の意思決定・レポーティング・先方とのやり取りを担当しました。他のメンバーには、意思決定に必要な情報を集めるファストフォレンジックを分担してもらいました。 河口 : 準備段階でも役割が分かれていました。得意領域の調査、事前に環境を再現して起きそうなことを練る人、エージェントを前もって作る人、特化した MCP を作る人もいました。 AWS : 役割の割り振りはどう決まるのですか。 齊藤 : 明確に指名するのではなく、「エージェント基盤をなんとなく用意しておいてね」「こういう技術が使われそうなので予習しておいてね」といった形です。お互いの得意分野を分かっているので、自然と決まっていきます。 コンテストで得た学び AWS : 今回のコンテストで得た学びを教えてください。 齊藤 : AI エージェントを使えば、インシデントレスポンスの技術的な部分の 8 割ほどを代替できる時代になったと感じています。コンテストは、かつて技術とそれ以外が半々だったのが、意思決定のゲームに変わってきています。その中で我々が明確にミスしたのは、意思決定のときに「仮定」と「事実」を混同した点です。結論ありきで「この仮定が正しければこうなるはずだ」という調査をしてしまいました。「2 時間以内にどうにかしてください」という時間的プレッシャーもありました。 河口 : エッジで情報を集めるメンバー間で横のコミュニケーションから筋の通らない仮説が立ち、「この結論を論じるために情報を取りに行こう」という合意をコマンダーに投げてしまうことがありました。コマンダーもエッジの人間も、その状況をメタ的に認知できていなかったのが反省点です。 AWS : 次に活かすとしたら、どのように改善しますか。 河口 : 自分たちがどういう情報にアクセスでき何を知れるのかを初動で把握し、症状と原因を分けて考えるべきでした。症状の原因を当てずっぽうに追うのではなく、アクセスできる情報を一つずつ見て原因を探り当てるべきだったと思います。 齊藤 : インシデントレスポンスに残る技術的要素とは、「今使える事実は何が存在し、どこから取りうるのか」に対する直感を持っていることだと思います。今回、AWS コンソールに対してその直感を持っている人があまり多くなかった。 髙橋 : その直感を持っていたチームがあり、彼らは対象環境をほぼ完答していました。我々はプレッシャーの中で「こうすればうまくいくだろう」という方向に飛びつき、そこで 30 分ほど失ったのが大きかったです。 今後のキャリアへの影響 AWS : 今回の経験は今後のキャリアにどうつながりますか。 髙橋 : 一次情報や確定したドキュメントを大切にする姿勢は、今後も活かしていきたいです。 高島 : 先ほどの「結論ありきで情報を探してしまった」反省で、結論を一番出していたのは僕だと思います。今後は AI に自分が収集しきれない範囲まで集めてもらい、自分は意思決定に時間を集中させたいと考えています。 齊藤 : 私の専門のバイナリ解析は、インテリジェンスが欲しいから行うものです。マルウェアを解析して通信先を突き止め、攻撃者の属性（アトリビューション）を導く。そのためには事実とインテリジェンスの切り分けが重要で、当面は人間側にも一定の専門性が求められます。AI を前提とした専門性について考えるきっかけになりました。 河口 : 大きく 2 つあります。1 つは、インシデントが起きる前提でどう対応するか、信頼性の高い環境をどう作るか、許容されるダウンタイムについて利害関係者とどう合意するか、といったことを具体的に考える機会になった点です。作り込まれたシナリオが良い材料になりました。もう 1 つは、シビアな事態でのチームや個々のメンバーの心情をキャッチする大切さです。情報は人的要因で歪むことがあるので、心理的安全性に配慮したコミュニケーションと、二人で一緒に確認する進め方が大事だと感じています。 これから参加される方に向けて AWS : 最後に、これから参加される方へ一言お願いします。 齊藤 : 本物に近いインフラの上で本物に近いインシデントが起きる体験は、学生が独力で用意するのはかなり難しい。それが無料で参加でき、決勝まで進めば会場（和歌山県白浜）までの費用も負担されます。机上演習としての学習効果は高く、私は 3 回参加しましたが毎回学びがあります。最近は出場チームが固定化しつつあるので、参加チームが増えてほしいと思っています。 おわりに ITソルーション室_げんこつ の皆様、お忙しい中インタビューに快く対応いただきありがとうございました。 このブログは、2026 年 8 月時点の情報に基づいて ソリューションアーキテクト 深井 宣之 が執筆しました。

はじめに 本ブログは、株式会社第一興商と Amazon Web Services Japan が共同で執筆しました。 株式会社第一興商 （以下、第一興商）では、通信カラオケ「DAM」シリーズにおける採点機能の高度化に取り組んでおり、AWS Professional Services と共同で、人間の聴感に即した歌声評価 AI モデル「聴感採点モデル」を開発しました。この技術は、DAM のフラッグシップモデル LIVE DAM WAO! に搭載されている採点機能 精密採点Ai Heart の中核として活用されています。 2026 年 6 月 25 日〜6 月 26 日に幕張メッセで開催された AWS Summit Japan 2026 では、第一興商のブースにてこの聴感採点モデルの仕組みと実装をご紹介いただきました。本記事は、AWS Summit Japan 2026 での展示内容をもとに再構成したものとなります。 第一興商とは 株式会社第一興商は、業務用カラオケ機器「DAM」シリーズの開発・製造・販売を手がける企業です。カラオケ事業においてはトップクラスのシェアを有し、最新機種「LIVE DAM WAO!」では AI 技術を活用した多彩な機能を搭載しています。 写真提供：株式会社第一興商 カラオケ採点における課題 従来のカラオケ採点は、音程・リズム・ビブラートなどの音響パラメータを機械的に評価する方式でした。この方式は一定の精度を持つ一方で、以下のような課題がありました。 人間の感性との乖離 : 機械採点は音程を重視しているため、一定以上の音程精度を持つ歌に対しては妥当性がある一方で、人間が「心地よい」と感じる歌声の微妙なニュアンスを十分に評価できない 「採点歌い」への対応 : 機械的に高得点を狙う歌い方（いわゆる「採点歌い」）に対して過大評価してしまう傾向がある 音程偏重の評価 : 細かな音程のズレに対して過度に厳しい評価となる一方、声質や表現力といった人間の感性に関わる要素が反映されにくい これらの課題を解決するため、第一興商は AWS Professional Services と共同で、人間の聴感に基づく歌声評価 AI モデルの開発に着手しました。 聴感採点モデルの開発アプローチ 本プロジェクトは 2019 年から約 4 年にわたり、AWS Professional Services の Machine Learning Research Scientist および Data Analytics Consultant がプロジェクトに参画し、機械学習モデルの設計・開発だけでなく、教師データの品質向上のための統計手法の導入や、大規模データ処理基盤の構築など、幅広い技術支援を提供しました。以下では、その中で取り組んだ主な実験・技術的アプローチについて解説します。 教師データの収集：一対比較法による聴感ラベリング 聴感採点モデルの開発において最も重要かつ困難な工程は、「人間の聴感」を定量的に表現する教師データの作成でした。 当初は 5 段階尺度法による評価を試みましたが、審査員によるブレが大きく十分な精度が得られませんでした。そこで、2 つの歌声を聴き比べて「どちらが良いか」を判定する 一対比較法 を採用しました。絶対値で点数を付ける方式に比べて審査員間の判断のばらつきが小さく抑えられるため、整合性が高くスケール可能な評価が可能になりました。約 15 万回に及ぶラベル作業を通じて、高品質な聴感評価の教師データを構築しました。 一対比較の結果を Bradley-Terry 法（BT 法）により聴感スコアに変換しました。BT 法では、すべてのペアを網羅的に比較する必要がなく、グラフが連結していればスコアを推定できるため、大規模データへのスケーリングが可能です。 特徴量抽出：Audio Embedding Generator 歌唱音源から特徴量を抽出する方法として、オープンソースの深層学習モデル Audio Embedding Generator を使用しました。これにより、音声データを 1 秒ごとに 128 次元のベクトル表現に変換します。 大規模なエンベディング処理を効率化するため、AWS のコンテナサービスを活用し、最大 1,000 並列での処理基盤を構築しました。これにより、約 13 万ファイルのエンベディング処理を 1.5 時間で完了できるようになりました。 モデルの学習と試行錯誤 学習モデルには AutoGluon Tabular を使用し、聴感評価結果と音源特徴量を組み合わせて学習を行いました。 最適なモデル構成を見つけるため、時間集約特徴量の種類、マルチモーダル特徴量の組み合わせ、トレーニングサンプルの選択方法、モデリング手法（分類・回帰）といった複数の設計軸について、それぞれの組み合わせパターンを網羅的に実験し、精度を比較検証しました。 AWS アーキテクチャ概要 聴感採点モデルのシステムは以下のコンポーネントで構成されています。 機械学習モデル構築（Amazon SageMaker AI） : 聴感評価モデルの学習・評価を Amazon SageMaker AI 上で実施。P3 系 GPU インスタンスを活用し、深層学習モデルの効率的な訓練を実現しています。 教師データ管理（Amazon SageMaker Ground Truth） : 一対比較法によるラベリング作業のプラットフォームとして活用しました。 データ保存（Amazon S3） : 歌唱音源データ、エンベディング特徴量データ、モデルアーティファクトの保存に使用しています。 大規模エンベディング処理 : AWS Fargate for Amazon ECS を活用した並列処理基盤により、大量の音声ファイルのエンベディング処理を最大 1,000 並列で高速に実行しています。 AWS Professional Services との共同開発の成果 上記の実験を経て、開発された聴感採点モデルは以下のような特性を実現しています。 「心地よい」歌声の識別 : AI 聴感スコアの上位には「いまいちな」歌声が混入しにくい特性を実現しました 「採点歌い」への耐性 : 機械採点が高得点であっても、「採点歌い」のような不自然な歌声には低い AI 聴感スコアを付与する結果を得ました コンテスト上位歌唱の適切な評価 : 実際のカラオケ大会におけるデータにおいて、プロ審査員が上位と評価した歌手に対する AI 聴感スコアの評価が適切に向上しました 人の聴感に近い学習データの収集は、本プロジェクト最大の難所でした。当初は評価のばらつきに苦労しましたが、AWS Professional Services が一対比較法を提案し、開発本部の全社員を対象に数か月かけて評価を実施することで、人の聴感に近い高品質な学習データを準備できました。また、製品化にあたっては DAM 端末のスペックに合わせてモデルを大幅に軽量化する必要があり、この移植・軽量化の工程でも AWS Professional Services が継続的に技術支援を行いました。これらの取り組みにより、新機種の発売時期に合わせてプロジェクトを推進できました。 AWS Summit Japan 2026 での反響 AWS Summit Japan 2026 の第一興商ブースでは、精密採点Ai Heart の開発プロセスをモニターで紹介するプレゼンテーションに加え、実際にワンコーラス歌唱でチャレンジできる「透明カラオケボックス」を設置しました。90 点以上を獲得された方にはオリジナルステンレスマグボトルをプレゼントする企画としたところ、2 日間でのべ 300 名以上の方にご参加いただきました。 「なぜ AWS Summit にカラオケが？」と多くの来場者に足を止めていただき、精密採点Ai Heart の背景にある機械学習技術と、それを支える AWS のアーキテクチャに関して、多数のご質問と好意的なご反応をいただきました。「普段何気なく楽しんでいるカラオケの裏側で、これほど本格的な機械学習モデルが動いているとは思わなかった」「15 万回もの人手による聴感評価を積み上げて教師データを作っている点に驚いた」「カラオケも AWS で動いているんですね」といった感想を数多くいただき、身近なエンターテインメントサービスにおける AI 活用の実例として、多くのビルダーの皆様と対話できる貴重な機会となりました。 おわりに 第一興商の聴感採点モデルは、AWS Professional Services との共同開発により、従来の機械採点では実現できなかった「人間の感性に寄り添った歌声評価」を実現しました。採点品質の核となる 15 万回の聴感ラベリングはあえて人間の耳で一つひとつ積み重ね、その貴重なデータを最大限活かすためのモデル構築・運用基盤に AWS の機械学習サービスを活用することで、カラオケ体験をより豊かなものにしています。 今後の展望としては、聴感モデルでは補いきれなかった「得点に対する納得感」をさらに追求していく予定です。今後の精密採点シリーズに是非ご期待ください。 著者について 執行 里恵（Rie Shigyo） 株式会社第一興商 開発本部 コンシューマ事業部 応用技術課 聴感採点モデルの企画・開発を主導。 中本 翔太（Shota Nakamoto） アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト サービス業界のお客様を中心に、幅広い業種業態のお客様をご支援しています。