RAGの事例｜つまずくのは検索より手前の文書の扱い

当社が読んだRAGの導入事例のページは、多くが完成した構成図と効果の数字から始まります。文書の形式を変えた話や見せる範囲を分けた話は、工夫の段落の中ほどに短く出てくるだけです。デジタル庁の検証報告や4社の導入事例からその短い記述を工程ごとに抜き出し、着手前に確かめる1点と並べました。

本記事で読む事例は、官公庁と自治体の公開資料、各社が公式に公開した導入事例ページに書かれた内容だけです。導入事例ページは提供事業者が掲載したものなので、効果の数値は引かずに工程と運用の記述だけを使います。当社はRAGの製品や仕組みを運用していません。当社の記録として示すのは、正本を決め直した運用とAIに読ませない情報の線引きで、どちらも社内ナレッジの記事に書いた範囲です。外部の引用は2026年10月6日に閲覧した範囲です。IPAのガイドラインは中核人材育成プログラムの卒業プロジェクトとして公開された文書で、本文には内容がIPAと産業サイバーセキュリティセンターの意見を代表せず、著者の見解に基づくと書かれています。同じ本文に発行日から2年間の有効期限の記載があり、2026年10月時点では期限を過ぎた文書として参照します（IPA 産業サイバーセキュリティセンター 中核人材育成プログラム7期生（卒業プロジェクト）「テキスト生成AIの導入・運用ガイドライン（2024年7月）」（PDF）／2026年10月6日閲覧）。デジタル庁のガイドブック（α版）は、内容を別のガイドラインへ統合してその枠組みの中で更新すると告知されています（デジタル庁「テキスト生成AI利活用におけるリスクへの対策ガイドブック（α版）」／2026年10月6日閲覧）。

RAGの事例とは、社内文書を検索してAIに答えさせる仕組みの公表例で、直した跡は検索より手前の文書の扱いに残っている

RAGの事例とは、RAG（検索拡張生成）で社内文書を検索してAIに答えさせる仕組みを、官公庁や企業が公表した例です。Microsoft LearnはRAGを、組織が独自に持つコンテンツで大規模言語モデル（LLM）の応答に根拠を与えてLLMの機能を広げるパターンと定義しています。考え方は単純でも、実装は大きな課題に直面するとも書いています（Microsoft Learn「RAG および生成 AI - Azure AI Search」／2026年10月6日閲覧）。公表例を工程ごとに読むと、課題に当たって直した跡は検索の仕組みより手前の文書の扱いに残っています。

図は、公表例に書かれた困りごとを左の列に置いた表です。右の列には各社がその後に置いた運用と、公的資料が示した手順や将来像を並べました。セルは公表例から読める範囲の短い語にとどめ、効果の数値は入れていません。4つの工程は文書を集める前から本番で答えたあとまでの順に並べました。当社はこの順で上から決めていくことを勧めています。

本記事で読むのは、工程と運用の記述がある公表例です。デジタル庁の2023年度の技術検証の報告書、IPAのガイドラインに載った組織ヒアリング、RIZAPテクノロジーズ・SBI生命保険・スクウェア・エニックス・豊田自動織機ITソリューションズの公式の導入事例を読みました。出典は各節の段落に付けています。

RAGの仕組みそのものは、取り込みから索引化・検索・生成までの工程としてRAGの仕組みの記事に書きました。つまずきの一般論も同じ記事に5つに分けて書いています。本記事は公表例に残った直した跡だけを工程ごとに追います。

文書の準備のつまずきは、形式がばらばらで表や図が検索に乗らない工程で、取り込む形式と置き場を決め直している

文書の準備でつまずくのは、形式の違う文書をそのまま入れて表や図の中身がAIに渡らない工程です。デジタル庁の技術検証のユースケースB-1は、長いガイドブック類を参照して職員の問い合わせに答える試みでした。1回目の試行では、RAGに登録したPDFとdocxの図表のテキストをGPTが正確に読み取れず、回答精度に問題が出ています（デジタル庁「行政における生成AIの適切な利活用に向けた技術検証の環境整備（2023年度技術検証の報告書）」（PDF）／2026年10月6日閲覧）。

同じ報告書のユースケースB-2は、人事院規則への問い合わせです。RAGで精度が高くなるファイル形式を確かめるため、HTML・XML・PDF・Wordで学習セット（RAGで検索させる文書の登録先）への登録を試しました。その結果、本検証はPDFのテキストをもとにテストケース20件で進めています。他の形式では表などが崩れて取り込まれ、精度が落ちたためです（デジタル庁「行政における生成AIの適切な利活用に向けた技術検証の環境整備（2023年度技術検証の報告書）」（PDF）／2026年10月6日閲覧）。これはその検証の仕組みで比べた結果で、どの製品でもPDFがよいという意味ではありません。読み取れるのは、形式を比べてから1つに決めるという手順のほうです。

企業の公表例でも、形式を揃える作業は工程の重い部分に置かれています。SBI生命保険はコールセンター向けに、Amazon Kendraと生成AIで保険商品と契約手続きの文書を検索する仕組みを作りました。その際、古い保険商品のパンフレットと契約書の手続き文書をPDF形式に変換する作業を、プロジェクトの重要な部分としていました（アマゾン ウェブ サービス ジャパン「AWS 導入事例: SBI 生命保険株式会社」／2026年10月6日閲覧）。

置き場のほうを先にまとめた例もあります。豊田自動織機ITソリューションズは2017年ごろ、散在していた社内ファイルサーバーの運用を議論しました。情報の検索性を重視して、2018年にGoogleドライブへ統合しています。その後、統合済みの社内データをGemini Enterpriseで活用する形をとり、グラウンディング（回答の根拠を示すこと）で情報の正確性を担保できる点も選んだ理由に挙げています（Google Cloud「株式会社豊田自動織機 IT ソリューションズ の導入事例」／2026年10月6日閲覧）。生成AIを使う前の段階で、置き場をまとめていた順番が公表された経緯から読めます。同社は、生成AIの社内展開は部署を限定して段階的に進めるのが定石とされる中で、全社員に一斉提供する方法を選んでいます（同ページ／2026年10月6日閲覧）。置き場の統合が先に済んでいれば、対象を絞らない進め方もとられているということです。

言葉の揺れも準備の工程に入ります。RIZAPテクノロジーズは、「RIZAP」「らいざっぷ」「ライザップ」のような表記揺れを辞書にして、さまざまな表現に対応できるようにしました（アマゾン ウェブ サービス ジャパン「AWS 導入事例: RIZAP テクノロジーズ株式会社」／2026年10月6日閲覧）。社内の呼び名が部署ごとに違う文書でも、同じ辞書の考え方が使えます。Microsoft Learnも、RAGの品質は取得するコンテンツの準備で変わるとし、用語の不一致への対処にシノニムマップ（同義語の対応表）を挙げています（Microsoft Learn「RAG および生成 AI - Azure AI Search」／2026年10月6日閲覧）。

AIに読ませる文書で置き場が分かれる経験は、当社にもあります。編集規格を作るときに、同じ基準が計画書と規格とメモリの3か所にあると分かりました。要約文の字数の目安は古い計画書で約80字、新しい規格で100〜120字と2つ残っていました。形式が揃っていても置き場が複数あれば、集めた時点で版が並びます。

権限のつまずきは、見せてよい文書と見せない文書を分けないまま集めた工程で、格納の領域と質問の経路を分けている

権限でつまずくのは、見せてよい文書と見せない文書を分けないまま1つの置き場に集めた工程です。IPAのガイドラインはRAG利用時の課題の例として、機密情報を含むデータをベクトルDB（文書を検索しやすい形で保管する仕組み）に入れると全ユーザーが参照できてしまうことを挙げています。ユーザーや部門ごとにデータを分けたり閲覧権限を付けたりできないことも挙げ、従来の方法で解決するには環境を複数作る必要がありコストが上がるとしています（IPA 産業サイバーセキュリティセンター「テキスト生成AIの導入・運用ガイドライン（2024年7月）」（PDF）／2026年10月6日閲覧）。これらの課題は2024年6月時点で研究中と書かれているので、いまの製品に同じ制約があるとは限りません。同じガイドラインは5.5.2で、情報の重要度ごとに参照できるユーザーを設定する解決策を一例として示しています（同ガイドライン／2026年10月6日閲覧）。

仕組みの側の対処として、Microsoft Learnは文書単位のセキュリティトリミング（利用者の権限に応じて検索結果から文書を外すこと）を挙げています（Microsoft Learn「RAG および生成 AI - Azure AI Search」／2026年10月6日閲覧）。本記事ではその手前にある、運用の側の公表例を見ます。

運用の側で分けた組織もあります。IPAのガイドラインが2024年3〜5月に行った組織ヒアリングでは、RAGを導入済みの組織は一部でした。多くの組織は、全社のデータを最初からベクトルDBに入れていませんでした。部門やプロジェクトの単位で利用申請を受け、文書を単位ごとに領域を分けて格納し、その中で検索させる運用です（IPA 産業サイバーセキュリティセンター「テキスト生成AIの導入・運用ガイドライン（2024年7月）」（PDF）／2026年10月6日閲覧）。仕組みで権限を細かく切る前に、集める単位を小さくして見せる範囲を揃えた形です。

質問の側に線を引いた例もあります。スクウェア・エニックスは、社内ゲームエンジンの文書をAzure AI Searchで検索してAzure OpenAI Serviceで答えるSlack上のAIチャット「ひすいちゃん」を使っています。Slackへの質問は他のクラウドサービスを経由して記録が残るため、機密性の高い質問用にAzureへ直接渡すC#のローカルアプリも用意しました。ローカルアプリからの質問はRAGに使わないようにして、他人に知られたくない内容も質問しやすくしています（日本マイクロソフト「スクウェア・エニックスがゲームエンジン活用支援に Azure OpenAI Service を活用、質問に回答する AI チャットやコード自動生成を実現」／2026年10月6日閲覧）。見せる範囲の線引きは文書だけでなく、利用者が打ち込む質問にも要るという例です。

当社が文書を集める前に決めている線は、入れない情報の種類です。鍵（パスワードなどの認証情報）・顧客名・未公開の案件条件の3つは、AIに読ませる文書に入れない側に置いています。書いた禁止だけでは操作は止まらないので、止めたい操作は権限の設定で分けています。この線引きの経緯は社内ナレッジの記事に、何を入力してよいかの社内ルールの作り方は生成AIの社内利用ルールにまとめました。

更新のつまずきは、古い版が残り答えに混ざる工程で、更新日と担当者を回答の側に持たせている

更新でつまずくのは、規則や手順が変わったあとも古い版が置き場に残り、新しい版と並んで答えに混ざる工程です。IPAのガイドラインは、ベクトルDBにない新しい情報を質問した場合や古い情報と重複した情報がDBに残っている場合は、誤った回答の可能性が高くなるとしています。精度を保つには格納した情報を定期的に更新し、最新で重複のない状態に保つことが重要だという説明です（IPA 産業サイバーセキュリティセンター「テキスト生成AIの導入・運用ガイドライン（2024年7月）」（PDF）／2026年10月6日閲覧）。

更新の重さが導入の判断を左右した例が、RIZAPテクノロジーズの公表事例にあります。同社は社内規定やサービス手続きに関する社内問い合わせのチャットボットを以前に検討しました。しかし、ルール変更のたびに文書を更新して回答内容を保守する工数が懸念され、一度は見送っています。その後、LLMが普及した2023年後半にAWSに相談しました（アマゾン ウェブ サービス ジャパン「AWS 導入事例: RIZAP テクノロジーズ株式会社」／2026年10月6日閲覧）。

相談のあとに作った仕組みには、更新に関わる工夫が並んでいます。社内文書を検索して生成AIで答える構成に、更新日付の順に優先する設定と参照ファイルの表示を加えました。よくある質問はFAQに蓄積しています。ログで問い合わせと回答を一覧で確認し、事業部の意見を聞きながら精度を上げています。参照先のマニュアルなどの文書の課題も見つけて、解消を進めています（アマゾン ウェブ サービス ジャパン「AWS 導入事例: RIZAP テクノロジーズ株式会社」／2026年10月6日閲覧）。答えの誤りを仕組みの設定だけでなく文書の側でも直す経路が、運用に入っている例です。

回答のたびに担当者を呼ぶ形もあります。スクウェア・エニックスの「ひすいちゃん」は、回答するときにゲームエンジンの該当部分の担当者にもメンションを送ります。回答に問題があれば担当者がコメントでき、その内容も取り込まれます（日本マイクロソフト「スクウェア・エニックスがゲームエンジン活用支援に Azure OpenAI Service を活用、質問に回答する AI チャットやコード自動生成を実現」／2026年10月6日閲覧）。該当部分を受け持つ人が回答の宛先に入っているので、回答に問題があると気づいた担当者がその場で指摘を返せます。古い記述による誤りもこの経路で拾える形だと、当社は読んでいます。

デジタル庁の報告書は、特定部門への問い合わせ対応の将来像として次の流れを示しています。回答者が受けた個別の質問と回答を一般化し、Q&A形式のJSON（機械が読みやすいデータの書式）にしてシナリオDBに格納します。そのDBをRAGとプロンプトに追加し、シナリオDBは回答者が定期的に目で確認します（デジタル庁「行政における生成AIの適切な利活用に向けた技術検証の環境整備（2023年度技術検証の報告書）」（PDF）／2026年10月6日閲覧）。答えを足す人と確かめる人を、問い合わせに答えている回答者に置いた設計です。

当社の記録も、この工程に当たります。2026年9月上旬に、サイト運用のAIへ読ませていた代表のやること一覧が3か所に分かれ、どれが正本か決まっていない状態でした。9月9日に正本の文書を1つに決め、チェックリストの画面は写しとしています。正本と直す人が決まるまでは、どの記述を読ませるべきかも決まっていませんでした。経緯は社内ナレッジの生成AI活用の記事に書きました。

評価のつまずきは、正解の例を用意しないまま精度を議論した工程で、過去の問い合わせを採点の基準にしている

評価でつまずくのは、正解の例を用意しないまま「精度が高い」「使えない」を議論する工程です。正解の例がなければ、同じ回答を見ても人によって判断が割れます。デジタル庁のガイドブック（α版）は、RAGを使うシステムの定性評価で観点を3つに分けることを例示しています。1つ目は質問に対して適切な関連文章を抽出できているかで、再現率と適合性の観点です。2つ目は関連文章に対してLLMの出力が適切か、3つ目は最終的な生成物が求める品質を満たすかです。分けることで、評価者の主観による偏りを分けない場合と比べて大きく抑えられるとしています（デジタル庁「テキスト生成AI利活用におけるリスクへの対策ガイドブック（α版）」（PDF）／2026年10月6日閲覧）。再現率は拾うべき文章を取りこぼしていないか、適合性は関係のない文章が混ざっていないかを見る観点です。

正解の例の作り方も、同じガイドブックに書かれています。既存の業務をテキスト生成AIに置き換える場合は、過去に実際にあったやりとりをそのままテストケースにできます。例はヘルプデスク業務で、過去の問い合わせと回答をプロンプトと正解データにします。ただし過去のやりとりをテストケースにしやすい形で保存していない場合や、まったく新しい業務を作る場合はこの手法を使えないとも書いています（デジタル庁「テキスト生成AI利活用におけるリスクへの対策ガイドブック（α版）」（PDF）／2026年10月6日閲覧）。問い合わせの記録を残しているかどうかが、評価の工程の入口になります。

テストケースがあれば、方式の比較も数字で出せます。デジタル庁の技術検証のB-1では、システムプロンプト（AIに最初に渡す指示文）での生成の評価が低かったテストケースについて、RAGでの生成も評価しました。各章2問ずつのテストケースで、RAGはシステムプロンプトより得点率が26％低く、実用にはシステムプロンプトを使うべきという結果でした（デジタル庁「行政における生成AIの適切な利活用に向けた技術検証の環境整備（2023年度技術検証の報告書）」（PDF）／2026年10月6日閲覧）。これは2023年度の検証で当時の文書と仕組みを使った比較で、RAGが劣るという一般的な結論ではありません。読み取れるのは、同じテストケースで方式を比べたからどちらを使うかを決められたという手順です。

評価を先に置く理由は、改善の手がそこから決まるからです。Google Cloudは、RAGの評価を実装すると基準になる指標が得られると書いています。そのうえで、検索エンジンの構成と元データのキュレーション（集める文書の選別と整理）で品質を最適化できるとしています。文書レイアウトの解析とチャンキング戦略の改善、検索前に質問を絞り込むことも手として並べています（Google Cloud「検索拡張生成（RAG）とは」／2026年10月6日閲覧）。RIZAPテクノロジーズが置いた質問のカテゴリーを絞り込める機能も、質問を絞り込む手の一つの形だと当社は読んでいます（アマゾン ウェブ サービス ジャパン「AWS 導入事例: RIZAP テクノロジーズ株式会社」／2026年10月6日閲覧）。基準の指標がないまま手を入れると、どの手が効いたのかを後から分けられません。

合格の線を数字で置いて判断した公表例もあります。RAGと明記された例ではありませんが、生成AIに市民の質問へ答えさせた実証です。三豊市は東京大学大学院工学系研究科松尾研究室と協力して、ChatGPTによる市民向けのごみ出し案内を実証しました。本格導入の条件は正答率99％に置いています。1回目（2023年6月1日〜7月7日）は62.5％でした。モデルの更新や対話形式への変更などを加えた2回目（2023年10月23日〜11月30日）は94.1％でした。99％に届かなかったことなどから、市は「ごみ出し案内」業務にChatGPTを活用しないと決めています（三豊市「『チャットGPTを利用したごみ出し案内』本格導入について」／2026年10月6日閲覧）。導入を決める線を数字で置いていたので、2回目の結果が出た時点で使うかどうかを決められた例です。

評価項目と母数と判定日を開始前に紙に書く手順は、PoCの評価項目と進め方の記事にまとめました。RAGの試験導入でも、過去の問い合わせから作った正解の例をその紙の評価項目の欄に置けば同じ手順で読めます。

RAGが向かないのは、正確さの線が高い窓口と、答えがまだ文書になっていない業務である

RAGが向かないのは、正確さの線が高い窓口と答えがまだ文書になっていない業務です。1つ目の窓口について、デジタル庁の技術検証のB-1は総括で、RAGの有無にかかわらずLLMに行政職員レベルの正確さで回答を代行させるのは容易でなかったと結論づけています。一方で、文書からの要約や個別の質問の一般化には有効と判定しました。正確さが求められる問い合わせには、FAQの整備や従来型チャットボットとの組み合わせを推奨しています（デジタル庁「行政における生成AIの適切な利活用に向けた技術検証の環境整備（2023年度技術検証の報告書）」（PDF）／2026年10月6日閲覧）。更新の節で見たシナリオDBの将来像と合わせると、人が答えを書くFAQを軸にしてRAGはFAQを増やす作業に回す組み方が読めます。

2つ目の業務について、IPAのガイドラインは「RAGを利用するとどのような質問に対しても正しく回答できる」を誤解の例に挙げています。精度が上がるのはベクトルDBに格納した情報についてだけで、格納していない情報の精度は上がらないという説明です。そのため、どの情報について答えられるかを利用者に知らせておく必要があるとしています（IPA 産業サイバーセキュリティセンター「テキスト生成AIの導入・運用ガイドライン（2024年7月）」（PDF）／2026年10月6日閲覧）。同じガイドラインのヒアリングでも、課題には回答精度と、ユーザーの期待とRAGで実際にできることとの差が挙がっていました（同ガイドライン／2026年10月6日閲覧）。答えがまだ文書になっていない業務では、格納する情報そのものがありません。

文書の更新を受け持つ人を置けない場合の進め方は、社内ナレッジの生成AI活用の記事に書きました。

事例から始めるなら、文書の置き場と更新する人を決めてから仕組みを選ぶ

事例から始めるなら、仕組みの比較より先に文書の置き場と更新する人を決めます。本記事で読んだ範囲では、直した跡の多くは仕組みを動かしたあとに文書の側へ戻って直した箇所でした。仕組みを選ぶ前にその戻り先を決めておくのが、公表例から引ける順番です。決める項目を工程の順に並べると次の5つになります。

1. 置き場が1つにまとまる前は、対象を部門か文書の種類で1つに絞る
2. 取り込む形式を自社の文書で比べて決め、同じ文書の置き場を1か所にまとめる
3. 見せない文書と記録に残したくない質問を分け、それぞれの扱いを決める
4. 文書ごとに更新する人を決め、更新日と参照した文書が回答に出るようにする
5. 過去の問い合わせと回答から正解の例を作り、検索と出力と最終品質に分けて採点する

5つのうち情報システム部門が主に進められるのは2つ目で、ほかの4つは文書を書いて問い合わせに答えている部門の人と一緒に決める項目です。とくに4つ目は、仕組みを入れたあとも続く仕事です。

仕組みを選ぶのは、この5つが埋まってからです。比べるときの問いは、文書を直してから答えに反映されるまでの経路の確かめ方として社内ナレッジの生成AI活用の記事に書きました。文書の量が少なければ検索の仕組みを組まずに全文を渡す方式で足りることもあり、その見分け方はRAGの仕組みの記事にあります。

RAGの事例についてよくある質問

Q. 導入事例に載っている効果の数字は、自社の見積もりに使えますか？

そのままは使えません。導入事例ページの数字はその会社の文書と問い合わせの条件で出たもので、自社の条件とは揃っていないからです。本記事でも各社の効果の数値は引いていません。見積もりに使うなら、評価の節で見たように過去の問い合わせと回答を正解の例にして、自社の文書で測るほうが確かです。

Q. 文書はPDFとWordのどちらで入れればよいですか？

決まった答えはなく、自社の文書と仕組みで比べて決めます。デジタル庁のB-2が形式を比べてから1つに決めた手順は、文書の準備の節で見たとおりです。試す文書は、表の多い規程や図の入った手順書のように崩れ方が違いそうな種類から1本ずつ選びます。同じ質問を形式ごとに投げ、答えに表や図の中身が出ているかを見比べます。

Q. RAGの失敗事例はどこまで公表されていますか？

失敗と正面から書いた公表例は、当社が読んだ範囲では多くありません。企業の導入事例ページは提供事業者が掲載したもので、つまずきは工夫の段落に短く出てくる形です。結果が届かなかった検証を載せているのは、主に公的機関の資料です。デジタル庁の2023年度の検証のB-1と、RAGと明記はされていない三豊市の実証は、評価と向き不向きの節で見たとおりです。

Q. 文書の更新は情報システム部門が持つべきですか？

仕組みの保守は情報システム部門でも、文書の中身を直すのは文書を書いている部門です。担当者へのメンションやシナリオDBを回答者が確かめる将来像は、更新の節で見たとおりです。線を引くなら、検索の設定や取り込みの不具合は情報システム部門に回し、答えの中身が古い・違うという指摘は文書を書いた部門に回します。指摘の受け口は1つにして、振り分ける人を先に決めておきます。

SAIの視点：公表例で手を入れた先は、検索の仕組みより文書の側だった

PDFへの変換・更新日付の優先・担当者へのメンションは、それぞれの公表例で効果の段落ではなく工夫の段落に置かれていました。3つとも、手を入れた先は検索の精度そのものではなく文書の形式と鮮度と持ち主です。この読み方は、当社が自社のAIに読ませる文書の正本を決め直したときの記録と照らして決めました。

答えの元になる文書の正本は、いま1か所にまとまっていますか。分かれていれば文書の準備の欄から、まとまっていれば権限と更新の欄から決めていきます。製品の比較より先にこの4つの欄を埋めるのが、AI導入支援でRAGを扱うときの当社の方針です。

お問い合わせには、検索させたい文書の種類を並べ、それぞれの横にいま更新している役職を1つずつ添えてください。役職の欄が空いている文書があれば、そこが最初に決める場所です。

出典と確認日

外部の出典はいずれも2026年10月6日閲覧。各社の導入事例は提供事業者が公開したページで、効果の数値は本記事では使っていない。当社の記録はサイト運用のAIに読ませる文書の運用から取ったもので、RAGの運用記録ではない。

• Microsoft Learn「RAG および生成 AI - Azure AI Search」
• Google Cloud「検索拡張生成（RAG）とは」
• IPA 産業サイバーセキュリティセンター 中核人材育成プログラム7期生（卒業プロジェクト）「テキスト生成AIの導入・運用ガイドライン（2024年7月）」（PDF）（2024年7月発行。本文に発行日から2年間の有効期限の記載があり、2026年10月時点では期限を過ぎた文書として参照）
• デジタル庁「テキスト生成AI利活用におけるリスクへの対策ガイドブック（α版）」（PDF）（掲載ページの最終更新日は2025年6月6日。内容は「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン」へ統合して更新すると告知されている）
• デジタル庁「行政における生成AIの適切な利活用に向けた技術検証の環境整備（2023年度技術検証の報告書）」（PDF）
• 三豊市「『チャットGPTを利用したごみ出し案内』本格導入について」
• アマゾン ウェブ サービス ジャパン「AWS 導入事例: RIZAP テクノロジーズ株式会社」
• アマゾン ウェブ サービス ジャパン「AWS 導入事例: SBI 生命保険株式会社」
• 日本マイクロソフト「スクウェア・エニックスがゲームエンジン活用支援に Azure OpenAI Service を活用、質問に回答する AI チャットやコード自動生成を実現」
• Google Cloud「株式会社豊田自動織機 IT ソリューションズ の導入事例」