日本全国の公営競技場に向けて、情報提供システムやファンサービスシステムなどを提供する日本トーター株式会社。情報端末の提供などを行う部署では、生成AIを活用した新サービス検討に向け、まずは自社内に知見を蓄積する必要性を感じていたといいます。
完成品を外部に任せるのではなく、自分たちで手を動かし、生成AIの可能性と限界を理解したい。そうした思いに応える形で、クラスメソッドは4カ月間にわたり、RAGを用いたAIボット構築の技術検証を伴走支援しました。プロジェクトの背景や検証を通じて得られた気づき、今後の展望についてお話を伺いました。
生成AIを「使う」前に仕組みを理解したい
今回ご依頼いただいた日本トーター株式会社のみなさまは、同社提供サービスのユーザー向け情報照会端末などのシステム導入・保守、インフラの取りまとめを担当するメンバーです。
同部署が生成AIに向き合うきっかけとなったのは、新サービスの企画立案に取り組んだことでした。そこで生成AIを活用したシステムやサービスの構築を検討したところ、当時のチームには生成AIを事業にどう取り込めばよいのかを判断できるだけの知見が不足しているという課題が見つかりました。
「生成AIに関する知識があまりにも不足していたため、自社だけで事業活用を始めるのは難しい状態でした。まずは伴走サービスに協力を仰ぎながら自社でモノづくりを進めることで、足りない知識をキャッチアップすることを目指しました」（Yさん）
日本トーターが求めていたのは、外部が製作する完成品ではありません。自分たちで手を動かすことで、社内に知見を残しつつ、自ら設計・構築・改善できる力をつけることでした。複数社に相談する中で、その意向を最も具体的に汲み取ったのがクラスメソッドでした。
「他社様は『こちらで作ります』という提案が多かったのですが、クラスメソッドは、自分たちでやりたいという部分を尊重してくださいました。私たちが求めていたものを一番具体的に提示していただけたと感じています」（Yさん）
こうして、生成AIの基礎理解と技術検証を目的とした4カ月間のプロジェクトが始まりました。
座学から実装へ。AWSと生成AIを同時に学ぶ伴走プロジェクト
プロジェクトは「生成AIとは何か」「RAGとは何か」といった基礎を学ぶ座学から始まりました。その後、AWS上で生成AIを動かすための環境を構築し、問い合わせ対応の効率化を目指した業務資料をもとに回答するAIチャットボットの検証へと進みます。
日本トーター側が主体的に手を動かし、つまずいた箇所をクラスメソッドが支援する形で進行しました。週1回程度の定例会議に加え、コミュニケーションツールで随時相談しながら、開発環境の構築、データ投入、回答精度の確認を重ねていきました。
クラスメソッドの支援は、単なるレクチャーにとどまりません。AWS上でAmazon Bedrockを用いたGenU（AWSが公開するオープンソースの生成AIチャットアプリケーション）を構築し、生成AIモデルにはAnthropicのClaudeを採用しました。Amazon Bedrock Knowledge Basesへのドキュメント取り込み手順や、IAMユーザー管理、GitHubを活用した開発・運用フローなど、検証に必要な環境整備から運用面までを支援しました。
ただ、実際に取り組むと、生成AIだけではなくAWSの知識も同時に必要になる難しさに直面します。会社としてAWSの利用実績はあったものの、同部署の業務では普段から触れる機会が多かったわけではありません。
「AWSの上に生成AIが乗る形になるため、AIがどう動くのかという話と、AWSがどう構築されているのかという話を同時に理解しなければなりませんでした。最初はかなり苦労しましたが、細かな設定についてはクラスメソッドに丁寧に教えていただきましたので、少しずつですが自分で構築できる手応えを感じていました」（Mさん）
手順書通りに進めてもエラーが出る。原因を調べても解決できない。問題が発生するたびにクラスメソッドへ相談し、助言を受けながら一つずつ課題を解消する。そうした地道なやり取りを重ねることで、メンバーは少しずつAWSや生成AIの構造を理解していきました。
「取り組みが進むなかで、Gitなどの開発ツールを含めた理解が進みました。AWSについても、どこにどのような項目があるのかが見えてきて、知見が深まっていく感覚はありました」（Yさん）
クラスメソッドにすべてを任せるのではなく、自分たちで試し、つまずき、相談しながら進める。そのプロセス自体が、同部署にとって生成AIを理解するための重要な学びとなっていきました。
AIボット構築で見えた“暗黙知”の可視化とドキュメント整備の重要性
実際の業務資料をAIチャットボットに取り込む段階では、資料に明記されていない「暗黙知」の存在が大きな課題となりました。仕様書や取扱説明書、設計書はそろっていても、人間が読む前提の資料ではAIが意図通りに読み取れないケースがあります。改版履歴や過去仕様の記載が回答精度に影響する場面もあり、AI活用には知識やドキュメントの整理が必要になるという新たな課題が浮かび上がりました。
「回答例を作ろうとするたびに『この回答を出すにはこの資料が必要だよね』という話になります。ただ、実際には資料に書かれていない暗黙知がかなりありました。テキストになっていない情報をもとにAIが回答することはできないので、チャットボットに必要な資料は想像以上に膨大になると感じました」（Mさん）
この課題に対して、クラスメソッドはRAGの回答精度を高めるためのチューニングも支援しました。
検索結果を再評価するリランキング、複雑な質問を複数の検索クエリに分けるクエリ分解、検索対象を絞り込むメタデータフィルタリング、質問文の変更などを検証。さらに、MarkItDownによるドキュメント変換やKnowledge Basesのパーシング設定の見直しも行い、業務資料をAIが扱いやすい形に整えていきました。
一方、プロジェクト後半にはAmazon Bedrock AgentCoreを活用したAgentic RAGの検証も行われました。AIが自律的に回答に必要な情報を考え、必要に応じて追加でデータの再検索を行い、不足情報を補完する仕組みを加えたことで、より期待に近い回答が得られるようになりました。
「同じ質問で比較してみましたが、Agentic RAGの手法を利用すると回答精度が格段に上がりました。望んでいた回答に近いものが出るようになりましたので、それ以降はAmazon Bedrock AgentCoreを活用したAgentic RAGの手法を中心に使うようになっています」（WSさん）
もちろん、AIがすぐにベテラン社員と同じように答えられるわけではありません。それでも、根拠資料を示し、確認すべき箇所を探す時間を短縮できる点には大きな価値がありました。
「完全にベテランのような回答をしてくれるわけではありませんが、やる気のある3年目ぐらいの人材のようなレベルには来たと感じました。対話を重ねることで、一生懸命考えながら一定品質の回答までまとめ上げられるのは助かりますね。頼れるメンバーが1人増えたような感覚があります」（Yさん）
現場とバックヤードに生成AI活用の可能性を広げる
4カ月間のプロジェクトを通じて得られた成果は、AIチャットボットそのものだけではありません。生成AIに何ができ、何が難しいのか。業務に取り入れるには、どのような準備や設計が必要なのか。その解像度を高められたことが大きな収穫でした。
今後は、構築したQAシステムの精度向上を進めながら、問い合わせ対応や資料検索の効率化に活かしていく考えです。さらにその先には、公営競技などのファンへの情報提供や、自治体・運営側のバックヤード業務を支える仕組みへの応用も視野に入れています。
「近い将来で言えばQAシステムの精度を高め、熟練メンバーに近い回答ができるレベルまで上げていくことを目指しています。長期的には、ファンサービスや現場を運営する自治体様のバックヤード側にも、生成AIの波はいずれ入ってくると思っていますので、私どもがサポートに回れるようにさらに知見を深めたいですね」（WTさん）
若手メンバーからも、AIを活用した新しい情報提供の可能性が語られました。SMさんとSTさんは、AIを活用した新たな情報提供や予想材料の可能性という観点から、それぞれ今後の展望に触れています。
「例えば映像や音声を解析したデータを、ファンが望む新しい予想材料として提供できるかもしれません。そうした新しい情報提供のあり方を考えるうえでも、今後クラスメソッドにお力添えいただければ心強いです」（STさん）
「今回の検証を通じて、自社がAIを活用した場合にはどのような可能性があるのかという、新しい視野の広がりにつながったと感じています」（SMさん）
日本トーターは各種サービスを提供する立場として、今後も生成AIを活用した新サービスの可能性を検討していくといいます。その実践にあたり、自社単独での対応が難しい領域においては、今回伴走したクラスメソッドとの連携も有力な選択肢の一つとして考えているようです。
「今回、非常に手厚く丁寧に対応いただきました。次のサービスで生成AIの活用を考える際には、優先してクラスメソッドに相談させていただくことになるのではないかと思っています」（Yさん）
生成AIを何となく知っている段階から、自社の事業にどう活かすかを考えられる段階へ。日本トーターは、公営競技の現場と運営を支える新たなサービスづくりに向けて、生成AI活用の次の一歩を踏み出しています。
