29万ファイルを一瞬で検索、AWSの実証が示す「探さない」時代
AWSが航空データ29万ファイルを自然言語で横断検索する仕組みを実証。中小企業の社内資料活用にも応用できる設計思想を解説します。
「探す」が消える。
約29万ファイル。30以上のシステム。それらを横断して、AIに話しかけるだけで数秒で答えが返ってくる——そんな実証デモを、AWS（Amazon Web Services）が発表しました。舞台は航空会社の業務データです。
出典: https://atmarkit.itmedia.co.jp/ait/articles/2609/18/news025.html
29万ファイルを、AIに聞くだけで
航空会社は、フライトスケジュール、整備記録、乗客情報、気象データなど、実に多様な種類のデータを日々蓄積しています。今回の実証では、そうした情報を約29万ファイル分、30以上のシステムにまたがる形で集約し、AIへの自然言語の問いかけだけで必要な情報を数秒で引き出せる状態を作り上げました。地上業務全体を管理するターンアラウンド管理の画面では、到着から次の出発までの一連の状況を一目で確認できるようにもなっています。
これは単なる検索速度の話ではありません。「どのシステムのどのファイルを見ればいいか」を人が覚えておく必要がなくなった、という働き方そのものの転換を示すデモだと言えます。
容量ではなく「散らばり」が問題だった
興味深いのは、集約されたデータの総容量が38GBにとどまっている点です。今どきのストレージ感覚からすれば、決して「ビッグデータ」と呼べる規模ではありません。それでも29万ファイルという数の多さが業務を圧迫していたのは、データ量ではなく、データの「散らばり方」こそが本質的な課題だったからです。
AWSはこの実証において、航空データ活用の課題を大きく3つに整理しています。第一に、情報が30以上のシステムに散在していること。第二に、それらが分析しやすい形に整理されていないこと。そして第三に、ベテラン担当者の頭の中にしかない暗黙知が、システムのどこにも記録されず埋もれていることです。
容量を圧縮する技術ではこの3つは解決しません。必要なのは、散らばった情報を一箇所に集め、誰でも自然な言葉で引き出せるようにする仕組みです。中小企業の現場でも、この構図には見覚えがあるのではないでしょうか。見積書はローカルPC、マニュアルは共有フォルダ、過去のやり取りはメールの奥、そして一番大事なノウハウはベテラン社員の頭の中——容量の問題ではなく、まさに散らばりの問題です。
集約し、意味で検索できるようにする仕組み
この実証の核となる設計は、驚くほどシンプルです。まず、散在していた全データをオブジェクトストレージであるAmazon S3を中心としたデータレイクに集約します。次に、検索基盤としてAmazon Bedrockのナレッジベース機能を用い、集めたデータをベクトル化して検索用のインデックスに変換します。ベクトル化とは、文章の「意味」を数値の形で表現する技術で、これによりキーワードが完全一致しなくても、意味が近い情報を引き当てられるようになります。「〇〇便の整備状況は」といった曖昧な日本語の質問でも、関連する記録を的確に探し出せるのはこのためです。
さらに、AIが複数の業務システムやアプリケーションにアクセスするための共通の窓口として、ゲートウェイが配置されています。利用者からすれば、裏側に30以上のシステムがあることを意識する必要はなく、ひとつの窓口に質問を投げるだけで済みます。
運用面で見逃せないのは、Amazon S3上のデータが追加・更新・削除されると、その変更が自動的に検知され、検索用インデックスに反映される仕組みになっている点です。つまり、誰かが人手でインデックスを作り直す作業は要りません。日々の業務でデータが更新され続けても、検索の鮮度は自動的に保たれます。これは「作って終わり」になりがちな社内システムにおいて、地味ながら極めて重要な設計です。運用の手間がかからない仕組みでなければ、結局は使われなくなり、また情報は散らばっていくからです。
音声・地図・文字起こしまで束ねる周辺技術
この土台の上には、テキストデータ以外の情報も同じように載せられます。今回の実証では、無線などの音声記録をサービスで自動的に文字起こしし、検索対象に含めています。また、航空機の位置情報を地図上に表示するサービスも組み合わされており、位置や時系列といった情報も統合的に扱える構成になっています。
なお、今回使用された航空データそのものは、AWSのAI開発ツール「Kiro」で生成された架空のデモデータです。開発の過程では、仕様書を起点にAIが設計・実装タスクを整理する「仕様駆動開発」という手法が採用され、12のサブシステムにまたがる仕様ファイル群をもとに、24の要件を複数のフェーズに分割して段階的に構築されたと説明されています。実データではないとはいえ、業務の複雑さを再現した設計として参考になる部分は多いはずです。
中小企業が今日から考えるべきこと
この実証が航空会社という大企業の話だからといって、自社には関係ないと片付けるのは早計です。設計の骨格——散在するデータを一箇所に集約し、意味で検索できる状態に変換し、共通の窓口を用意する——は、規模に関わらず応用できる考え方です。
自社の見積書、作業マニュアル、議事録、過去のクレーム対応記録は、それぞれ別の場所に保存されていないでしょうか。そして「あの資料、どこに保存したっけ」という会話が、社内で日常的に交わされていないでしょうか。もしそうなら、それはまさに今回の実証が解決しようとした課題そのものです。
経営者やIT担当者に求められる判断は、「どこに何を保存するか」というルールを社員に徹底させることではなく、そもそも「どこに保存したかを人が覚える」という前提から降りることです。データを一箇所に集め、自然言語で聞けば答えが返ってくる仕組みを整えることは、もはや大企業だけの特権ではありません。クラウドの検索基盤を活用すれば、中小企業でも十分に手が届く規模の投資で実現できる時代に入っています。
情報の在り処を記憶する働き方から、AIに尋ねれば答えが返る働き方へ。この転換に早く着手した企業ほど、日々の「探す時間」から解放され、本来の業務に集中できるようになるはずです。
参考リンク
