島津製作所が抱えていた課題とは？ 技術選定から導入までのプロセス
grasysは2014年11月に設立された、Google CloudやAWSの技術を主に活用してクラウドインフラの設計・構築・運用を行っているITサービスプロバイダ。オンラインゲーム基盤やIoT基盤、分析基盤など、大規模で複雑なクラウドインフラを多数構築している。同社のCloud Tech Div. Cloud Development Sec.でリーダーを務める細谷氏と、サーバーサイドを主に担当しているエンジニアの上間氏が紹介したのは、膨大な資料を活用するため、Vertex AI Searchを導入した島津製作所の事例。
最初に細谷氏が登壇。「今回の島津製作所の事例では、Vertex AI Searchの実装周りをメインに話す」と前置きし、セッションが始まった。
島津製作所航空機器事業部品質保証部では業務上、確認すべき資料が膨大にあるため、検索・確認に時間を要していた。grasysはこの課題を解決するソリューションを提供することになった。
島津製作所からのソリューションに対する要望は、以下の4点。
- 手書き資料を含む膨大な資料の検索や確認に時間がかかる課題を解消したい
- セキュリティ面の考慮もしたい
- 費用は最低限にしたい
- 利用ユーザーが増加しても問題がないようにしたい
これらの要望に対して、「業務上で利用する膨大な資料の検索について、AIを活用して迅速に見つけ出し、業務の効率化を図る」ことを提案したと細谷氏は話す。
その提案を満たすために、細谷氏たちが検索AIサービスの選定を行ったところ、3つの候補があがった。一つはAWSの「Amazon Kendra（以下、Kendra）」。理由は、「島津製作所様がAWSを利用していたため」と細谷氏。2つ目はGoogle Cloudの「Vertex AI Search」。候補に挙げた理由について細谷氏は、「島津製作所のプロジェクト担当者様が実際に触ったところ、簡単に設定ができて、好感触だったため」と明かす。3つ目は「Microsoft 365 Copilot（以下、Copilot）」。理由として、島津製作所ではMicrosoft 365アカウントの使用率が高かったからだ。
これら3つの検索AIサービスの比較検討を実施。まずは料金について、島津製作所の要望は「費用を最低限にしたい」。Kendraは時間単位の課金なので、「1回の処理時間と検索数を予想する必要があるため、個人的には試算しづらい印象があった」と細谷氏は話す。
2つ目のVertex AI Searchは、クエリ単位の課金なので試算しやすそうだったという。検索は1000クエリ4ドル、それに要約を追加すると4ドルが加算されるので、1000クエリで8ドルとなる。「それでもかなり安い印象を持ちました」（細谷氏）
3つ目のCopilotは月額課金だ。全員が多数、利用することが確定していれば、お得に使える。料金面での比較においては、「Vertex AI Searchが最も好印象だった」と細谷氏は話す。
続いて、「手書き文書も存在する資料から検索したい」という要望を叶えるため、OCR機能を比較した。「Vertex AI Searchはこの要望を簡単に実現できそうだったが、KendraやCopilotは一筋縄ではいかなさそうだと思った」（細谷氏）
本来はここでVertex AI Searchに決定ということになるが、島津製作所ではマイクロソフト製品に慣れていることやノーコードで利用できるといった魅力もあることから、「ギリギリまでCopilotを候補として残した」と細谷氏は話す。
そして実際に、島津製作所のプロジェクトメンバーにVertex AI SearchとCopilotの比較検証を実施してもらった。根拠資料についてはVertex AI Search、Copilotともに取得はできたが、「Vertex AI Searchのほうが根拠資料のページまで取得できたことを島津製作所様は評価した」と細谷氏。また図面を認識できたのは、Vertex AI Searchのみ。手書きデータに関してもVertex AI Searchは検索できたが、Copilotは一手間加えないと検索は難しそうだったという。「回答精度もVertex AI Searchのほうが質問に対して、こちらが期待するような回答をピンポイントで返してくれるなど、全体的に高かった」（細谷氏）
以上の結果から、Vertex AI Searchを採用することになったのだが、特に決め手となったのは「料金が安いことやOCRが簡単に設定できること。そして、Gemini（LLM）の回答精度が他のツールと比べて高かったことが挙げられる」と細谷氏は話す。とはいえ、今回の比較検討の結果は、あくまでも「2024年3月時点でのこと。今は変わっているかもしれない」と細谷氏は注意を促すことも忘れなかった。
アプリケーションの構成と技術の選定理由
Vertex AI Searchの採用を決めたことで、Google Cloudをプラットフォームとして構築することとなった。
構成は図の通り。セキュリティ面を考慮するという要望に応えるため、Google Cloud Interconnectを活用。外部IPなしのプライベートなデータ通信が可能になった。さらにVPCSC（VPC Service Controls）境界をさらに設定し、社外からのアクセスをできなくした。利用ユーザーが増加しても問題がないようにするため、自動でスケールアウト・スケールインするCloud Runを使用した。また、誰も使用しなくなったらインスタンスがゼロになるよう設定。「負荷や料金面に対しても、要望に応えられたと思っている」（細谷氏）
今回は外部IPがない構成なので、ロードバランサーはリージョン内部アプリケーションロードバランサーを使用。「これは時間課金で、ゾーンが数分発生するので注意が必要になる」と細谷氏は強調した。
ここから先は、メインで開発を進行した上間氏が登壇し、実装の話に移った。
アプリケーションは、バックエンドがPythonとFlask、フロントエンドがReactとNext.js、環境はDockerで構成。選定した理由について上間氏は、「今回の案件は納期が短かった。そこでバックエンドのPythonとFlaskは私がメインで利用している言語のため、開発スピードを出せるために選択した」と語る。ReactとNext.jsを選定したのは拡張性が高いからであり、開発を進行しながら機能追加されることが予想されたからだ。DockerはCloud Runを使用するため選択したという。
4つの機能を実装、それぞれの問題解決策も解説
実装した機能は大きく4つ。まずはデータストアの切り替え機能。データストアは質問や検索に対する回答を見つけるために使用する。「規定集や手書き文書など、ドキュメントの種類で検索の範囲を切り替えたいという要望があった」と上間氏は言う。そこでデータストアをドキュメントの種類ごとに作成し、APIを使用してVertex AI Searchにクエリを投げるときに、データストアを選択するように実装。検索画面では、ドロップダウンリストで選択できるようにした。また、拡張性を持たせるために、必要に応じてデータストアの追加や変更ができるようにもしたという。
2つ目は要約言語モデルの切り替え機能。これは言語モデルごとの回答の精度の変化に対応するためだ。「島津製作所のプロジェクトメンバー様が検証した際に、質問によってはtext-bison@002のほうが、精度が良かったり、Gemini 1.5 Flashのほうが良かったりしたため、言語モデルを選択できるようにしたいという要望があった」（上間氏）
実装としてはデータストアの切り替え同様、APIを使用してVertex AI Searchにクエリを投げるときに予約言語モデルを選定するようにした。また、拡張性を持たせるため、必要に応じて簡単に追加・変更ができるようにしたという。
3つ目は、参照ドキュメントを開く機能。検索結果のレスポンスは、クラウドストレージのURIが返ってくるが、ブラウザのアドレスバーにこのURIを設定しても閲覧はできない。島津製作所の要望は「誰がどのドキュメントを見たのかをログに残したい」「回答に使用した参照ドキュメントの確認をしたい」の2つ。
これを叶える実装方法は次の通り。まず、クエリパラメータでクラウドストレージのURIを受け取り、ユーザーとそのURIをログに残す。次に受け取ったクラウドストレージのURIからドキュメントを閲覧できるURLを生成し、リダイレクトを行うことで参照ドキュメントを開けるようにしたのだ。
4つ目は監査ログ機能。島津製作所の要望は、「誰がログイン、検索、ドキュメントを参照したのかを残したい」。そこで、Cloud Loggingにログイン情報や検索情報など必要な情報を書き込むようにし、ログシンクで定期的にクラウドストレージに保存（長期保存もできるようにした）。さらにクラウドストレージに保存したログから、BigQueryにインポートして解析することも可能にした。
実装が完了したところで、島津製作所のプロジェクトメンバーと一緒にテストを実施。すると、いくつか問題や要望が出てきた。
1つ目は、漢字だけの名詞で質問すると、要約が中国語で生成されるという問題。具体的には「特工申請」と漢字だけで質問すると、中国語で結果が返ってきたという。原因はデフォルトの要約言語がオートになっていたこと。「質問が漢字だけだと中国語と判定されていたようだ」と細谷氏は説明する。例えば「特工申請の方法は」といった文章にすれば問題は無いのだが、毎回文章を打つのは手間である。そこで、「オート／日本語／English」から要約言語を選択できるようにした。
2つ目は産廃と略すと産業廃棄物として認識してくれない問題。「このような業界用語が含まれる場合は、検索モデルのチューニングがおすすめ」と細谷氏はアドバイスする。そのためにはクエリファイル（業界用語が含まれた質問のサンプル）、コーパスファイル（業界用語が含まれた質問に対する回答のサンプル）、トレーニングラベル（クエリとコーパスのペアに対して重みをつける）という3つのファイルを用意する必要がある。これらでチューニングすることで、「業界用語が含まれた質問への対応が可能になる」と上間氏は言う。
3つ目はOCRで「φ（ファイ）」が「4」や「中」と誤認される問題。一般的に円の直径を表す記号として、φが用いられる。「Aの穴形は」と質問すると、「φ10」が410と返ってきたそうだ。「この問題についてはGoogle Cloudのサポートエンジニアから助言をもらった」と上間氏。Vertex AI Gemini APIを併用し、2回クエリを実行することで、誤認しないようにした。
具体的には、最初にVertex AI Searchで質問のクエリを実行し、ドキュメントを取得。次に取得したドキュメントと、実行した質問のクエリを使って、Vertex AI Gemini APIで回答を生成した。「この課題は検証、解決の確認まではしたが、今動いている検索サービスには未導入になっている」と上間氏は話す。
4つ目はVertex AI Searchの要約クォーター制限への対応問題。「負荷試験を行ったところ、ある一定量の負荷をかけるとエラーが発生した」と上間氏。原因は検索の要約には上限値があり、デフォルトが1分間で15回となっていたこと。1分間で15回は達しない認識だったが、将来的に発生するリスクがあり、対応することにした。
解決策として上間氏が行ったのは、HTTPステータスが「429 Too Many Requests」のエラーとなったとき、少し時間をあけて再リクエストするよう画面に表示すること。規模が大きくなり頻発するようであれば、クォーター上限値アップの申請をGoogle Cloudに出すことにした。
最後に上間氏は、「スピード感を持ってドキュメント検索システムを構築できたこと、さらにはVertex AI Searchだけではなく、Kendra、Cloud Runなどにも実際触れて検証できたことが良かった」と、今回Vertex AI Searchを使った感想を紹介した。
そして細谷氏も、「Vertex AI Searchは簡単に構築でき、カスタマイズ性も高いなど、優れたサービス。開発陣の頑張りもあるが、時間があまりない中での開発を助けてくれた」と述べた。
今回紹介した機能以外にも、要約のプロンプトのカスタマイズ、フォローアップ検索機能のほか、クラウドストレージのACLをインポートすることでドキュメント単位でのアクセス制御もできる。また、プレビュー版であるが、サードパーティのデータソースをVertex AI Searchに接続できるようになっている。「Vertex AI Searchは1年間有効な無料トライアルクレジットも用意されている」と細谷氏。ぜひ、興味のある人は試してみてはどうか。
grasys で身につく一生モノの技術と経験
現在 grasys では、クラウドインフラの知見を活かし、AIやデータ分析など最先端技術を取り入れたプロジェクトに挑戦しています。技術の幅を広げ、成長したいエンジニアを募集中です。興味のある方はぜひご応募ください！
