「船長、AI に聞いてください !」AI Agent x Text2SQL で実現する次世代運航支援
2026-05-07 | Author : 墨 幹 (株式会社ウェザーニューズ)、鈴木 諒 (株式会社ウェザーニューズ)、長友 健人
はじめに
ウェザーニューズは、統合型航海気象サービス「SeaNavigator」に AI エンジン「SeaNavigator AI Agent」を搭載しました。このシステムは、AI Agent と Text2SQL 技術を組み合わせることで、船長や運航管理者が必要とする気象情報を自律的に取得・分析し、即座に提供します。
従来、荒天時にはオペレーターの手作業による情報抽出が逼迫し、最も重要な時に高頻度の情報提供が困難でした。SeaNavigator AI Agent は、この課題を解決し、ユーザーは問い合わせなしで気象情報を取得でき、ルート変更や遅延リスク把握が迅速化。同時にオペレーター業務も大幅に効率化されました。
本記事では、100 万航海の実績データを活用して構築された SeaNavigator AI Agent の技術的な実装について詳しく解説します。
builders.flash メールメンバー登録
builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。
SeaNavigator AI Agent の実装
SeaNavigator AI Agent は、これらの課題を解決するために構築されました。 オペレーターの業務の本質は、エンドユーザーの問い合わせに対応するデータを収集し、理解、分析、解説を行うことです。この業務を AIAgentで代替するためには、多様な問い合わせに対して柔軟にデータを取得できる高精度な Text2SQL の実装が不可欠でした。SeaNavigator AI Agent は、この Text2SQL を中核に据え、利用者の役割に応じて異なる価値を提供します。
船長向け
運航判断の支援を行います。自然言語による問いかけに対し、荒天の影響期間や遭遇状況を専門的かつ柔軟に解説し、即座にフィードバックします。
運航管理者向け
膨大なデータの精査を肩代わりします。「北太平洋の荒天リスクについてブリーフィングシートを作成してください」と問いかければ気象概況を自動で解説し、「今後 3 日間で荒天リスクのある船舶をリストアップして」と指示すれば、全フリートから優先対応すべき船舶を特定します。これにより、監視漏れのリスクを最小限に抑えます。
経営層向け
データドリブンな意思決定を支援します。 「この 3 ヶ月で最も燃費の悪い船を 5 隻リストアップして欲しい」と問いかければ、CO2 排出量や燃料消費を瞬時に分析。会議に活用できる資料を対話を通じて作成し、船のパフォーマンス管理や傭船契約に必要な性能証明の作成もサポートします。
UI/UX
チャット U Iは Vue3 + TypeScript + Tailwind CSSで 構築し、ホスティングは Amazon S3 + Amazon CloudFront による静的サイトホスティングで実現しています。
AI の応答は Amazon API Gateway + AWS Lambda Response Streaming + SSE によりリアルタイムに逐次表示され、ユーザーは待ち時間を感じることなく回答を受け取れます。
AI Agent が生成したグラフや GeoJSON 地図は、チャット内にインラインでリッチに表示されます。データの可視化を会話の文脈の中で自然に提示することで、船長や運航管理者が直感的に状況を把握できるようにしています。
AI Agent の工夫
AI Agent の中核は LangChain + LangGraph によるReAct (Reasoning + Acting) パターンのエージェントです。基盤モデルには Amazon Bedrock の Claude を使用し、Application Inference Profile によりアプリケーション単位のコスト追跡を可能にしています。プロンプトキャッシュにも対応し、コスト最適化を図っています。
システムプロンプトとモデルパラメータは Langfuse (self hosting) で一元管理しており、コードデプロイなしにプロンプトを更新できます。
会話履歴管理では、過去の会話一覧・検索に対応し、Amazon DynamoDB で Thread metadata を管理、Amazon Bedrock AgentCore Memory で会話状態を永続化しています。長期記憶には 3 つの記憶戦略を組み合わせています。
SemanticMemoryStrategy は会話から事実や知識を自動抽出して保存し、UserPreferenceMemoryStrategy はユーザーの好みや行動パターンを記録、SummaryMemoryStrategy はセッションごとの会話を自動要約します。これにより、エージェントは過去の文脈を踏まえた応答が可能になります。
例えば、SemanticMemoryStrategy では「ユーザーはニッケル船のステータスを監視している」「管理している船の航海情報を追跡している」「日本語での情報提供を好む」といった、ユーザー固有の業務コンテキストが蓄積されます。UserPreferenceMemoryStrategy では「台風・熱帯低気圧の予報情報に継続的な関心がある」といった嗜好がカテゴリ付きで保存されます。
Text2SQL
Text2SQL を行うコンポーネントは AI Agent の Tool として定義しました。ユーザーの自然言語の問い合わせを SQL に変換し、統合 DB から必要なデータを取得します。Agent はユーザーの質問を分析し、データ取得が必要と判断した場合にこの Tool を自律的に呼び出します。
DB 設計
Text2SQL の精度は、モデルの能力だけでなく、モデルに与える DB 構造の設計にも大きく依存します。先行研究 (DIN-SQL: Decomposed In-Context Learning of Text-to-SQL with Self-Correction, Pourreza & Rafiei, NeurIPS, 2023) では、LLM が Text2SQL で失敗する 500 クエリを手動分析し、エラーを 6 カテゴリに分類しています。中でも支配的だったのが、テーブル名・カラム名の特定を誤る「Schema Linking エラー」(1 番) と、必要なテーブルの見落としや外部キーの誤りによる「JOIN エラー」（2 番）でした。LLM は SQL の文法は概ね正しく書けますが、「どのテーブルのどのカラムを使うか」「どのテーブル同士をどう結合するか」という判断で頻繁に間違えます。さらに複数 DB が存在する場合、「どの DB に問い合わせるか」という DB 選択自体も失敗の原因になり得ます。
この知見をもとに、SeaNavigator AI Agent では以下の設計判断を行いました。
単一 DB への統合
今回の対象データは複数の DynamoDB や S3 に分散しており、それぞれアクセス方法やクエリ言語が異なります。複数のデータソースをそのまま扱うと、LLM は DB 選択自体で失敗し、テーブル名やカラム名の重複・類似による Schema Linking の難易度も上がります。エラーの最大要因である Schema Linking の難易度を構造的に下げるため、複数データソースから Amazon Aurora PostgreSQL のシングル DB に統合しました。
スタースキーマの採用
JOIN の数が増えるほど、JOIN が失敗する確率が上がります。スタースキーマは結合パスが一意に決まり、JOIN の深さも浅くなるため、LLM が正しいテーブルペアを特定しやすくなります。
DB 選定のポイント
チャットベースのAIエージェントという利用形態が、DB 選定の判断に大きく関わっています。Amazon Redshift のような OLAP ではなく Aurora PostgreSQL を選択した理由は 3 つあります。
実行時間
OLAP は大量データの集計に最適化されている一方、クエリの起動コストが高く、小 ~ 中規模のクエリでもレイテンシが大きくなりがちです。チャット UI では即座の応答が求められ、さらに Text2SQL ではリトライループも発生するため、1回あたりのクエリ実行コストが低い OLTP が適しています。
同時接続
チャットエージェントは複数ユーザーから同時に軽量なクエリが飛ぶワークロードになります。OLAP は同時実行スロットに制限がある場合が多く、多数のユーザーが同時にクエリを投げるとキューイングが発生し、体感レイテンシがさらに悪化します。
課金モデル
Text2SQL ではリトライにより、1 つのユーザー質問に対して内部的に複数回のクエリが走ることが常態化します。クエリ単位課金ではコストが予測困難になるのに対し、インスタンス課金であればクエリ回数に依存しない固定的なコスト構造となり、エージェントの試行錯誤を許容できます。
セキュリティの担保
認証は SeaNavigator 統合認証と連携し、顧客ごとにデータアクセスを分離しています。同じ UI で異なる顧客がそれぞれのデータのみにアクセスできる構成です。DB 層ではPostgreSQL Row Level Security (RLS) により顧客ごとのデータ分離を実現し、ロールベースアクセス制御により必要なテーブルアクセスのみに制限しています。アプリケーションから DB 層まで一貫してマルチテナント環境でのデータ安全性を担保しています。
プロンプトの工夫
プロンプトは Langfuse 上で一元管理しており、コードを再デプロイせずに改善を反映できる構成としています。単に自然言語の指示を与えるだけでなく、各エージェントの役割に応じて、利用可能なデータソース、回答方針、ツール利用ルールを明示的に定義しています。
特に Text2SQL の精度向上では、会話サンプルを増やすというよりも、SQL 生成時の制約と典型パターンをプロンプトに埋め込む設計を重視しました。具体的にはクエリ生成前に必ずスキーマを確認すること、テーブル参照時の必須 join 条件、NULL 値の扱い、代表的な集計クエリや航路取得クエリの例をプロンプト内で明示しています。これにより、モデルの自由度を適切に制御しつつ、誤った SQL や非効率なクエリの生成を抑え、実運用で必要な精度と再現性を確保しています。
導入効果
今後の展望
筆者プロフィール
墨 幹 (SUMI Motoki)
株式会社ウェザーニューズ航海気象事業部
Generative AI チーム
航海気象サービスへの Generative AI 導入を推進。SeaNavigator AI Agent の企画・開発をリード。
鈴木 諒 (SUZUKI Ryo)
株式会社ウェザーニューズ
航海気象事業部 Generative AI チーム
SeaNavigator AI Agent の開発を担当。 Amazon Bedrock ベースの AI Agent 設計からチャット UI 構築まで幅広く従事。
長友 健人 (Nagatomo Kento)
アマゾン ウェブ サービス ジャパン合同会社
ソリューションアーキテクト
AWS のソリューションアーキテクトとして Web 系のお客様を中心にアーキテクチャ設計支援を担当。犬の名前はキリちゃんです。