目次 はじめに Partial Prefetchingは何を解決するのか すべてを先読みする方法と、何も先読みしない方法の中間を作る OISHYでPartial Prefetchingを試す 検証条件 計測方法 実験1：クリック前の取得を減らすと、通信と遷移はどう変わるか 実験2：URL固有のデータを待つ間に何が見えるか 補足：適用範囲によって先読みの形が異なった まとめ 参考文献 はじめに こんにちは、開発本部の 黒髙 です。最近はアメリカ向けレシピサービスである OISHY の開発に関わっています。 Next.js 16.3 では、ページ遷移の応答性を改善する仕組みとして Instant Navigations が追加されました。クリック前に再利用できるUIやデータを準備し、クリック後に必要な部分を取得することで、遷移直後から次のページを描画しやすくする仕組みです。 Instant Navigationsを構成する機能のうち、今回取り上げるのは Partial Prefetching です。本記事では、Partial Prefetchingを紹介したうえで、OISHYの既存ページでは通信と画面遷移にどのように現れるのかを検証します。 Partial Prefetchingは何を解決するのか すべてを先読みする方法と、何も先読みしない方法の中間を作る Next.jsの <Link> によるprefetch（先読み） では、リンクが画面内に入ると、ユーザーがクリックする前に遷移先のデータを取得します。クリック時にデータが揃っていれば、遷移先をすぐに表示できます。 一方、リンクが多い画面では、実際にはクリックされないリンクのデータも取得します。先読みを無効にすれば事前通信はなくなりますが、その場合はクリックしてから遷移先のデータを取得することになります。 Next.js 16.3のPartial Prefetchingは、この二つの中間を作る機能です。Cache Componentsを使うページへの既定の <Link> では、URLごとの完成形をすべて先読みする代わりに、同じ種類のページで再利用できるApp Shellを先読みします。クリックされたURLに固有のデータは、必要になった時点で取得します。 App Shell とは、URL固有のデータを待たずに表示できるページの共通部分です。サイト共通のレイアウトや、データの読み込み中に表示するUIなどが含まれます。 レシピ詳細ページを例にすると、レシピ名や材料はURLごとに変わりますが、それらを待っている間の枠組みは複数のレシピで共有できます。 同じルートを指す複数のリンクで一つのApp Shellを再利用できる ため、リンクごとに同じ共通部分を取得し直す必要もありません。 この仕組みは、次のようなページで効果が現れやすいと考えられます。 商品、記事、レシピなど、同じ種類の詳細ページへのリンクが多数並ぶ 表示されたリンクのうち、実際にクリックされるのは一部だけである 詳細ページに、共通レイアウトやデータ取得中の表示など、URLをまたいで再利用できる部分がある OISHYのトップページにも、同じ /recipes/[id] へ遷移するレシピリンクが多数並びます。そこで今回は、レシピ詳細ページをPartial Prefetchingへ切り替えたとき、クリック前の通信とクリック後の表示がどう変わるかを確かめました。 OISHYでPartial Prefetchingを試す OISHYでは、すでに Cache Components を有効にしています。まず、レシピ詳細ページへの遷移にPartial Prefetchingを適用するため、次の設定を追加しました。 // app/recipes/[id]/page.tsx export const prefetch = 'partial' ; 公式リファレンスでは、 prefetch = 'partial' はリンクではなく遷移先に設定する ものと説明されています。この設定により、レシピ詳細ページをPartial Prefetchingへ段階的に切り替えます。 検証条件 主な検証では、次の3条件を比較しました。 条件 Next.js Partial Prefetchingを適用する場所 データ取得中の表示 条件A 16.2.11 適用しない なし 条件B 16.3.1 レシピ詳細ページ なし 条件C 16.3.1 レシピ詳細ページ スケルトン表示 実験1では条件Aと条件Bを比較し、クリック前の取得を減らしたときに通信と画面遷移がどう変わるかを確認しました。実験2では条件Bと条件Cを比較し、URL固有のデータを待つ間にApp Shellが画面にどう現れるかを確認しました。 以下で扱う条件B・Cと補足検証の先読み通信は、Next.js 16.3.1で観測したものです。内部的な通信の形は、今後のバージョンで変わる可能性があります。 OISHYの既存構成では、Next.jsの standalone server をECSで動かし、その前段にCloudFrontとALBを置いています。今回の計測もこの配信経路で行いました。 計測方法 対象 ：同じ10件のレシピを、それぞれ3回ずつ計測 操作 ：トップページを新しいタブで開き、対象リンクが画面内に入る位置までスクロール。5秒待ってからクリックし、クリック前の先読み通信とレシピタイトルが表示されるまでの通信・時間を記録 ブラウザ条件 ：画面サイズは1280×900、回線速度の制限はなし。ブラウザ側のHTTPキャッシュは計測のたびに無効化し、スクロール位置とクリックまでの待ち時間を統一 集計 ：各レシピの3回の中央値を求めたあと、10件の中央値を代表値として使用。通信量にはChrome DevTools Protocolの Network.loadingFinished.encodedDataLength を使い、ブラウザが受信したデータ量に近い値を比較 実験1：クリック前の取得を減らすと、通信と遷移はどう変わるか 最初に、Next.js 16.2.11の条件Aと、16.3.1へ更新してレシピ詳細ページをPartial Prefetchingへ切り替えた条件Bを比較しました。この比較にはNext.js自体の更新も含まれるため、Partial Prefetchingだけの効果ではなく、OISHYで16.3.1への更新と機能導入を行った前後差として扱います。 ここでいう RSC（React Server Components）データ は、Next.jsがクライアント側の画面を更新するために送るデータです。 指標（中央値） 条件A（変更前） 条件B（レシピ詳細ページに適用） クリック前のRSCリクエスト 75 6 クリック前の転送量 約319KB 約20KB クリック後のRSCリクエスト 0 1 クリック後の転送量 0KB 約20KB クリック前後の合計リクエスト 75 7 クリック前後の合計転送量 約319KB 約38KB クリック前のリクエスト数は約92%、転送量は約94%減りました。クリック後には、選択したレシピのRSCリクエストが1件発生しています。それを含めた合計転送量も約88%減っており、クリック前の通信がそのまますべてクリック後へ移ったわけではありませんでした。 変更前は、画面内に並ぶ多数のレシピについてURL固有のRSCデータを取得していました。変更後は、共通部分を先読みし、選択したレシピのデータをクリック後に取得しています。今回の画面では、クリックされなかったレシピへの先読みが減ったことが、通信量の差として大きく現れました。 次の画像は1回の計測例で、表の数値は反復計測から求めた代表値です。 条件Bでのクリック前のNetwork記録の例 一方、クリックからレシピタイトルが表示されるまでの代表値は、変更前が約44ms、変更後が約82msで、どちらも100ms未満でした。URL固有のデータをクリック後に取得するようになったことと整合しますが、今回の条件では目視できるほど長い待ち時間にはなりませんでした。大きく変わったのは、完成画面が出るまでの見た目よりも、クリック前に取得するデータの量でした。 なお、この結果は回線速度を制限しない環境でのものです。Partial Prefetchingは、クリック前の転送量を減らす代わりに、URL固有データの取得をクリック後へ移す仕組みです。低速な回線では、クリック後の待ち時間が今回より長くなる可能性がある一方、クリックされないリンクへの先読みを抑える効果は大きくなるため、有効に働くかどうかは通信環境によってトレードオフになり得ます。 実験2：URL固有のデータを待つ間に何が見えるか Partial Prefetchingでは、URL固有のデータがクリック時点で揃っていなければ、クリック後にデータの取得を待つ時間が生じます。その間にApp Shellがどのように現れるかを見るため、条件Cではレシピデータの取得中に表示するスケルトンを loading.tsx として定義しました。 loading.tsx 自体はNext.js 16.3の新機能ではありません。同じルート階層のページを Suspense 境界で囲み、定義したUIをデータの準備中に表示する仕組みです。Partial Prefetchingでは、 この代替表示を含むApp Shellが先読みの対象になります 。 // app/recipes/[id]/loading.tsx export default function RecipeDetailLoading () { return < RecipeDetailSkeleton /> ; } スケルトンとは、完成後のレイアウトに近い枠を先に表示し、データを待っている場所を示すUIです。今回のレシピ詳細ページでは、次のスケルトンがApp Shellとして先に表示される部分になります。 レシピ詳細ページのスケルトン表示例 30回中25回はスケルトンを経由せず、完成したレシピ詳細が直接表示されました。スケルトンが先に現れたのは5回で、クリックから14〜22msで表示され、レシピタイトルより約68〜856ms先行しました。 この結果から、スケルトンは毎回挟まる中間画面ではなく、レシピ固有のデータがクリックまでに揃わなかった場合だけ、遷移先の枠組みとして先に表示されることが分かりました。 また、条件Cの通信を追加で確認すると、条件Bとは異なる挙動が見つかりました。条件Bではレシピ固有のデータをクリック後に取得していた一方、条件Cの補完計測では、10回中4回で複数のレシピ固有データをクリック前に取得するRSC通信が並びました。 条件Cでクリック前に観測したレシピ固有データの先読み この違いがPartial Prefetchingの適用範囲と関係するのかを確認するため、追加計測しました。 補足：適用範囲によって先読みの形が異なった 条件Cでは、レシピ詳細ページだけに prefetch = 'partial' を設定していました。 prefetch = 'partial' は、設定したページより上位のルート階層まで同じ設定にするものではありません。 Next.js 16.3.1の実装 では、それぞれのルート階層が、その階層で指定された設定かアプリ全体の既定値を参照します。 この挙動を調べる中で、 段階導入時の先読みを扱うNext.js 16.3.1の公式テスト を見つけました。このテストにも、動的なページだけをPartialにし、未設定の上位階層を従来の方法で扱う構成で、リンク先固有のデータまで先読みする例があります。 そこで、条件Cの loading.tsx とページ側の設定を残したまま、 アプリ全体の既定値をPartialにする partialPrefetching: true だけを追加しました。 // next.config.ts const nextConfig = { cacheComponents : true , partialPrefetching : true , } ; 同じ導線を10回計測した結果は次のとおりです。 Partial Prefetchingの適用範囲 URL固有データの先読み 共有部分の先読み レシピ詳細ページのみ 10回中4回で観測 あり アプリ全体 10回中0回 あり 同じ loading.tsx を残したまま適用範囲を変えると、今回の導線ではURL固有データの先読みが10回中4回から0回になりました。一方、App Shellを構成する共有部分の先読みは続いていました。Next.js 16.3.1の実装と公式テストを合わせると、今回観測した通信にはPartial Prefetchingの適用範囲が関係していたと考えられます。 まとめ Partial PrefetchingをOISHYのレシピ一覧で試したところ、16.3.1への更新と機能導入後、クリック前のRSC転送量が約94%減り、クリック後を含む合計でも約88%減りました。 一方、変更前からレシピタイトルまでの表示は約44msと十分に速く、回線速度を制限しない今回の環境では、通信量ほど大きな見た目の差はありませんでした。スケルトンを含むApp Shellは、URL固有のデータがクリックまでに揃わなかった場合だけ、完成したページより先に表示されました。 また、レシピ詳細ページだけに適用した場合と、アプリ全体に適用した場合では、クリック前の先読みも異なりました。ページ単位で試せる機能ではありますが、今回の検証では適用範囲も実際の通信に関係していました。 Partial Prefetchingは、商品・記事・レシピの一覧のように、同じ種類の詳細ページへのリンクが多く、その一部だけがクリックされる画面を想定しています。クリックされないURL固有データの先読みを抑えながら、データが間に合わない場合にはApp Shellを先に表示する仕組みです。今回のOISHYでは、先読み通信量には大きな差が出た一方、見た目の差は小さいという結果でした。 参考文献 Next.js 16.3 Next.js 16.3: Instant Navigations Instant Navigationガイド Adopting Partial Prefetching <Link> のprefetch（先読み） Cache Components Server and Client Components output: 'standalone' prefetch のルート設定（Next.js 16.3.1） 同じルートでApp Shellを再利用する説明（Next.js 16.3.1） partialPrefetching の全体設定（Next.js 16.3.1） loading.tsx とSuspense境界（Next.js 16.3.1） loading.tsx の代替表示を先読みする説明（Next.js 16.3.1） ルート階層ごとの先読み設定を扱う実装（Next.js 16.3.1） 段階導入時の先読みを確認する公式テスト（Next.js 16.3.1） Chrome DevTools Protocol: Network.loadingFinished

こんにちは。ファインディ株式会社でモバイルエンジニアをしている加藤です。 技術カンファレンス向けのモバイルアプリ「Findy Events」を、React Nativeで開発しています。iOSは App Store 、Androidは Google Play で公開しています。 Findy Conferenceチームでは、職種を問わず、プロダクトを作っている本人がカンファレンスの会場に立ち、参加者へのユーザーヒアリングを実施しています。私も AI Engineering Summit Tokyo 2026 の会場に立った1人です。この会場でチームとして集めた101人分の声から、ナビゲーション構造の作り直しと、次のカンファレンスでの仮説検証まで一周させました。 この記事では、ユーザーヒアリングを通して得られた課題から、どう仮説を立てて検証したのかについて書きます。 モーダルの中にタブバーを置いていた当初の画面構成 101人へのヒアリングで見つかった2つの発見 見た目と文言を直す案に残った引っかかり ターゲットペルソナの認識をチームで揃え直す Appleのガイドラインを読み直して見えた構成の問題 起動直後の画面を直近のカンファレンスのホームに変える 96人への再ヒアリングの結果 まとめ モーダルの中にタブバーを置いていた当初の画面構成 Findy Eventsには、当初からUI/UXの課題感がありました。それは、本来トップレベルに置くべき「タブバー」を一時的なモーダルの中に置いてしまったことです。 アプリを起動すると、参加予定のカンファレンスが並ぶチケット一覧が表示されます。カードの下には「入場チケットを表示」ボタンが並んでおり、タップすると入場用のQRコードが開きます。カード自体をタップした場合はモーダルで詳細画面が開き、そのモーダルの中に、ホームやタイムテーブルを行き来するタブバーを配置していました。 ※本記事に掲載している画面はすべてテスト環境のもので、カンファレンス名や日付はテストデータです。 タブバー は、アプリのトップレベルのセクション間を移動するためのものです。一方で モーダル は、今の画面の上に一時的に重なり、閉じれば消える層であって、トップレベルのセクションではありません。冒頭に書いた課題は、この定義のズレのことです。 Androidで同じ役割を担う ナビゲーションバー も、アプリの画面をまたいで一貫した行き先を並べるものだとされています。モーダルの中にだけ現れる置き方は、こちらの条件も満たしていません。 この構成を選んだ理由は、ユーザーがカンファレンスに参加する前と当日とで、欲しい情報が異なると考えていたためでした。参加前であれば申し込んだカンファレンスやおすすめのカンファレンスを、当日であれば参加するカンファレンスの情報だけを見たくなるはずだ、という想定です。 1stビューはどちらか一方にしか倒せません。両立させるために取ったのが、この苦肉の構成でした。カンファレンス当日もチケット一覧から該当のカンファレンスをタップすれば見たい情報にはたどり着けますし、モーダルの中の操作も使い始めれば慣れるはずだと考えていた側面もあります。 つまり、原理原則から外れていることは理解した上で、代わりの案を出せずにいました。そして開発を続けるうちに、開発者である自分自身がその操作に慣れてしまい、違和感は少しずつ薄れていきました。 101人へのヒアリングで見つかった2つの発見 違和感が薄れたまま迎えたのが、2026年6月8日から9日にかけて開催されたAI Engineering Summit Tokyo 2026です。この会場で、チームで手分けして101人に話を聞きました。 「アプリを見て使いにくかった点や、もっとこういう機能があれば嬉しいなどあれば教えてください」というオープンクエスチョンでヒアリングしました。まだアプリを使っていない方には持ち込んだデモ機をお渡しし、操作していただきながら答えていただく形です。 この質問を用意しながら、内心期待していたのは機能要望でした。あの情報が足りない、こういう画面が欲しい、といった声が集まるものだと考えていたのです。 実際に多かったのは、カードをタップすると開く詳細画面やタイムテーブルの存在に気づかれていない、という話でした。デモ機で見られたのは、一覧を眺める、上下にスクロールする、「入場チケットを表示」からQRコードを出す、設定画面を開く、といった操作です。カードをタップしてモーダルを開くところには至っていませんでした。モーダルの先で既に提供している情報が、そのまま「あったら嬉しい」という要望として挙がることもありました。 もうひとつ、モーダルのタブバーの「ホーム」を連打する様子が見られました。その意図を尋ねたところ、「ホームに戻りたいから」とのことでした。つまり、チケット一覧画面をホームと捉えていた、ということです。モーダルを閉じる導線は左上にありましたが、選択肢として認識されていませんでした。ユーザーが思い描いていた動きと実態のズレです。 この2つから、薄れていた違和感を改めて突きつけられました。使い慣れた開発者に見えなくなっていただけで、構成そのものの問題は残っていたわけです。 見た目と文言を直す案に残った引っかかり 最初に出した答えは、モーダルに気づいてもらうためにチケット一覧のカードをタップできる見た目に寄せることと、タブバーの「ホーム」という項目名を実態に合わせて連打をなくすよう誘導することでした。会場で見えた2つの症状に、それぞれ手を打つ形です。 ただ、この案では、モーダルの中にタブバーがあるという構成そのものは変わりません。気づいてもらえるかどうかを見た目の強さに委ねているだけで、なぜ気づかれなかったのかには答えられていない、という引っかかりが残りました。 ターゲットペルソナの認識をチームで揃え直す 立ち返ったのは、誰に向けたアプリなのかというところでした。 Findy Eventsが向き合うのは技術カンファレンスの参加者で、参加の頻度は年に数回です。前回の利用から数ヶ月空いた状態で起動されることを前提にすると、原理原則から乖離した構成は、アプリを開くたびにユーザーへ再学習を求めることになります。会場で見えたのと同じことが、次の機会にも起こる可能性があるということです。 Appleのガイドラインを読み直して見えた構成の問題 参考にしたのが、Appleの Human Interface Guidelines です。設計の原則がいくつか挙げられており、そのうちPurpose、Agency、Familiarityの3つが、当時の構成を見直す手がかりになりました。 Purposeは、人々がどう使いたいかに沿って最も重要な機能を絞り込むという原則です。参加前と当日の両方を1stビューで抱えようとしていたため、どちらの利用目的にも焦点が合っていませんでした。 Agencyは、ユーザーが主導権を持てるようにするという原則で、目の前のタスクやコンテンツに直接導くこと、特定のフローやモードに閉じ込めないことが述べられています。チケット一覧から段階を踏む構成は当日必要な情報へ直接導けておらず、モーダルを閉じる導線が認識されないままホームを連打していた状態は、ユーザーの行動を不自然な形で閉じ込めているのと変わりません。 Familiarityは、人々が既に知っている概念を使うという原則です。現実世界や他のソフトウェアで得た知識を持ち込むことで、インターフェースは馴染みやすく直感的になるとされています。年に数回の利用が前提のアプリで頼れるのは、アプリの中で積み上がる学習ではなく、人々が普段から慣れ親しんだ知識や経験のほうでした。 最初の案に残っていた引っかかりの正体は、ここにありました。単に表面を整えるだけでは、このPurpose、Agency、Familiarityはどれも変わりません。構成そのものを見直す必要があると考えました。 起動直後の画面を直近のカンファレンスのホームに変える ターゲットペルソナを踏まえると、アプリが起動されるのはカンファレンス開催日の直前から当日である可能性が高いと考えられます。それであれば、参加当日に欲しい情報へ直接導くのが妥当です。代案を出せずにいた「参加前と当日のどちらに倒すか」も、ここで決着がつきました。 そこでアプリ起動時の1stビューを、直近の参加予定カンファレンスのホーム画面に変更しました。これまでモーダルの中に置かれていた画面が、そのまま最初に表示される形です。結果として、モーダルの中にタブバーがある構成も解消されました。 変更前は起動後にチケット一覧が表示され、そこから先に進む必要がありました。変更後は、当日必要になる情報が最初から表示されます。 もちろん、他に参加予定のカンファレンスの情報などへの導線は残しています。行き先を塞いだわけではなく、あくまでも1stビューで最も必要な情報へ導くことを意識した整理になります。 なお、この変更はAndroidの Principles of navigation でいうstart destinationを選び直したことにあたります。Material DesignにHIGの3原則と直接対応するものはありませんが、Androidのナビゲーション原則から外れる判断ではありませんでした。 96人への再ヒアリングの結果 1stビューを変えることで、機能の見落としや、ユーザーが思い描く動きと実態のズレを減らせるはずだ。この仮説を持って、2026年7月22日から23日に開催された AI DevEx Conference 2026 の会場で、同じくチームで手分けして96人に話を聞きました。 1回目は「画面遷移に気づかない」という趣旨の声が15件以上あがり、タブバーの「ホーム」を連打する様子も見られました。2回目は、その声は0件で、連打する様子も見られませんでした。 ただし、これをもって因果の断定はできません。同一人物に聞き直したわけではなく、カンファレンスが異なるため参加者の属性も揃っていないためです。言えるのは、101人と96人というほぼ同規模のヒアリングで、仮説を否定する材料は出てこなかった、というところまでです。 まとめ 改めて感じたのは、現場に出て直接ユーザーの声を聞くことの大切さでした。違和感そのものは、チームの中でも気づけます。ただ、それが本当に直すべき問題なのかまでは確信が持てず、時間とともに薄れていきました。実際に使っていただき、その言葉と操作に触れたことで、はじめて確信に変わりました。 そうして一周させた結果、「恒常的に起動されるアプリではない場合ほど、原理原則に準ずることが効いてくる」という手応えを得ることができました。日常的に起動しないアプリでは、ユーザーが他のアプリを通じて既に学習している使い方をそのまま持ち込めれば、自然に使えるアプリに近づきます。 会場で聞いて直し、次の機会に確かめる。この形で仮説と検証を回しながら、引き続き会場に立ち、聞いた声を改善につなげていきます。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

航空業界では、散在するデータの横断的な活用が長年の課題でした。本ブログでは、 Amazon S3 を中心としたデータレイクに航空データを集約し、Amazon Bedrock AgentCore と Amazon Bedrock Knowledge Bases で横断的に AI 検索できる 航空オペレーション基盤 を紹介します。この基盤の上に業務アプリケーションを載せて具体的な課題を解決する例として、 ターンアラウンド管理 （フライトの地上折り返し作業の可視化・管理ツール）を紹介します。 また、本ソリューションは Kiro （AI 搭載の IDE）を活用し、自然言語による仕様定義からコード実装までを一貫して行う「スペック駆動開発」で構築しています。要件を自然言語で整理すれば、ここで紹介する規模のソリューションを開発できることも合わせてお伝えします。 注： 本ソリューションで使用している航空データ（フライトスケジュール、整備マニュアル、乗客情報など）はすべて架空のデモデータです。実在の航空会社・便名・人物とは一切関係ありません。 なぜ作ったのか 本ソリューションは、以下の問いに答えるために構築したデモソリューションです。 「航空会社が保有する膨大で多様なデータを、 AWS の AI ・データサービスで統合し、現場の意思決定を加速できるか？」 航空会社は日々、フライトスケジュール、フライトデータ、整備マニュアル、安全報告書、作業員音声記録、ケータリング在庫、乗客情報など、膨大なデータを生成しています。しかしこれらは業務システムごとにバラバラに管理されており、横断的な分析には人手と時間がかかります。 現場がよく直面する課題として、たとえば以下のようなものがあります。 情報がバラバラに散らばっている — 「この機材の整備履歴と異常を突き合わせたい」と思っても、 3 つも 4 つもシステムを開いて手作業で確認するしかない 蓄積されたデータが業務改善に活かされていない — 日々生成されるフライトデータ、作業記録は膨大ですが、分析や意思決定に活用する仕組みが追いついておらず、経験と勘に頼った判断が続いている ベテランの知識が共有されない — 整備マニュアルの PDF 、安全報告書、経験に基づくノウハウ。キーワード検索では見つからず「あの人に聞くしかない」状況 これらの課題に対し、 AWS が提案するのは 「聞けば、必要な情報が集まり、状況が分かる」 航空オペレーション基盤です。各システムのデータをデータレイクに集約し、 AI が横断的に検索・統合して回答する仕組みで解決します。 ソリューションの全体像 本ソリューションは 2 つの層で構成されています。 データレイク（基盤層） — 38 GB ・約 29 万ファイルの航空データ全体に、自然言語で質問するだけで答えが返ってくる AI 検索基盤 ターンアラウンド管理（活用層の一例） — データレイク基盤の上に構築した、フライトの地上作業を可視化・管理する課題解決ツール（このようなツールを業務ごとに追加できる構成です） 両層は AI の検索基盤を共有しており、ターンアラウンドの作業画面から画面を切り替えることなく、整備マニュアルや過去のフライトデータに自然言語で質問できます。 データレイク — 「聞くだけ」で全データから答えが返る フライトスケジュール、整備マニュアル、安全報告書、フライトデータ、作業員の音声記録。これまで別々のシステムに散在していた航空データを、 AI が横断検索できるようにしました。 使い方は簡単です。画面右側のチャット欄に、普段使う言葉で質問を入力するだけ。 AI が関連する複数のデータソースから情報を収集・統合し、回答を生成します。キーワードの完全一致ではなく「意味」で検索するため、マニュアルの表現が少し違っていても関連情報を見つけ出します。 従来は複数のシステムを手動で開いて突き合わせに 30 分以上かかっていた作業が、 AI への一言の質問で数秒に短縮されます。しかも、人が見落としがちな関連情報も AI が自動的に引き出します。 AI 分析パネル。「このデータをどう活用できるか？」と聞くだけで、 AI がターンアラウンド最適化、整備計画の高度化、安全分析など具体的な活用シナリオを提案。左側のエクスプローラーでデータを閲覧しながら AI に相談できる統合画面。 データの全体像を把握するダッシュボードも備えています。「そもそもどんなデータが、どれだけあるのか」を可視化することで、分析の出発点を明確にします。データの偏りやカバレッジの不足も一目で発見できます。 データカタログダッシュボード。カテゴリ別のデータ量・ファイル数・最終更新日を一覧表示。「特定カテゴリのデータが最大」「最近更新されたファイル」など、データの健全性を即座に確認できる。 地図・フライトデータ・音声 — 多様なデータをそのまま活用 航空データは構造が多種多様です。テキストだけでなく、航路データ（地図表示）、フライトレコーダー、作業音声（録音ファイル）を、それぞれ最適な形式でプレビュー・活用できます。わざわざ専用ソフトを開く必要がなく、ブラウザ上で即座に確認できることが運用効率に直結します。 航路データの地図表示。特定便の飛行ルートが地図上に自動描画される。航路計画と実績の比較や、空域の可視化に活用。 フライトレコーダーの構造表示。姿勢・エンジン・環境・位置の各データが 2,880 ポイントで記録。専用ソフト不要でデータの中身を即確認。 作業音声の再生画面。ケータリング搭載作業の録音をブラウザ内で直接再生でき、 AI による文字起こしと要約もセット表示。ベテランが口頭で伝える作業ノウハウを、テキスト化して組織の共有知にする仕組み。 ターンアラウンド管理 — データ活用による課題解決ツールの一例 データレイク基盤の上に構築した具体的な課題解決ツールとして、ターンアラウンド管理（フライトの到着から出発までの地上作業の可視化・管理）を紹介します。 飛行機が到着してから次に出発するまで、わずか 45 〜 90 分。その間に清掃、給油、ケータリング搭載、手荷物積み降ろし、機体点検など多数の作業を並行して完了させなければなりません。本デモでは仮に以下の 8 つの作業を定義していますが、実際の運用では乗務員ブリーフィングや機用品補充なども加わります。必要な作業が変わった際にも柔軟に追加や入れ替えができる設計にしています。 口頭報告を待たなくても全タスクの状態が即座にわかり、遅延の兆候を早期に検知できます。 45 分のターンアラウンドで 5 分の遅延発見が早まるだけで、定時出発率への影響は大きく変わります。 フライト一覧 — 全便の状況を一目で把握 本日の運航便を一覧表示し、各便のターンアラウンド進捗を色分けで即座に確認できます。「どの便が問題を抱えているか」を管理者が瞬時に判断し、リソースを再配分するための全体俯瞰画面です。 3D 地球儀モードでは飛行中の便の位置がリアルタイムに更新され、全体のオペレーション状況を直感的に把握できます。 フライト一覧。各便の進捗が色分け表示され、遅延が発生している便を即座に特定できる。 3D 地球儀モード。飛行中の便は赤色アイコンで位置がリアルタイム更新。運航全体の俯瞰に。 フライト詳細 — 1 便の全情報を集約 便を選択すると、その便に関する全ての情報が一画面に集約されます。 8 タスクの進捗バー、機材情報、出発・到着時刻、乗客数。複数画面を行き来する必要がなく、「この便は今どういう状態か」が 1 クリックで完全に把握できます。 フライト詳細画面。 8 タスクの進捗バー・機材情報・乗客数が一画面に統合され、便の全体像を即座に把握できる。 タスク管理 — 現場からリアルタイムに報告 作業員が無線機やスマートフォンから「作業開始」「作業完了」を 1 タップで送信するか、現場の無線通信内容から AI がステータスを自動判定して、管理画面にリアルタイムで反映されます。 従来の口頭報告やハンドサインに頼る仕組みでは、「報告を受けた時にはもう遅い」ことが多発していました。デジタル入力にすることで、報告の遅延ゼロ・記録の自動蓄積を同時に実現します。蓄積されたデータは過去分析に活用でき、「どのタスクがどの空港でボトルネックになっているか」を定量的に把握できるようになります。 タスク管理の初期状態。 8 タスクが全て「未着手」。ここからリアルタイムに状態が変化。 作業進行中。一部タスクが「進行中」に変わり、進捗バーで可視化される。 無線機から受信を開始すると、文字起こしをしながらステータスコマンドを監視。 無線通信が終了すると、録音データとともに、文字起こしと要約を保存し、音声からタスクのステータスを自動変更。 スマートフォンからもタスク入力が可能。専用デバイスがなくても、既存のスマートフォンで即座に運用開始できる。導入コストの低さも重要なポイント。 完了結果 — 作業実績の自動記録と分析 全タスク完了後、各タスクの所要時間・音声記録の文字起こし・ AI 要約が自動的に生成されます。手書き報告書の作成が不要になり、作業記録は即座に検索・分析可能な形で蓄積されます。「何が報告されたか」「どのタスクで問題があったか」を定量的に振り返れるようになります。 作業音声の文字起こし結果を自動表示。 AI が文字起こしから要約を自動生成。 タスク別の作業報告をテキストで一覧確認。 フライトツイン 3D — 巡航中の機体のデータを「見て」判断する 飛行中の航空機のフライトデータを 3D でリアルタイムに可視化し、フライトレコーダーのデータと連動させます。 PFD（計器表示）、エンジン状態、健全度スコアがリアルタイムに更新されます。 エンジン温度の偏差や N1 回転数の左右非対称など、数値だけでは気づきにくい異常の兆候を視覚的に捉えられます。「見ていて面白い」だけでなく、故障予兆の早期発見という実用的な価値があります。整備部門との情報共有も、 3D 画面を共有するだけで直感的に行えます。 フライトツイン 3D 。巡航中の機体をリアルタイムに可視化。 PFD（速度・高度・姿勢）とエンジン計器が連動し、機体の健全度スコアも常時表示。 7 つの表示レイヤー（3D 地形、飛行経路、 PFD 、エンジン、健全度、環境、方位）を目的に応じてオン・オフ可能。 フライトレコーダー分析 — フライトデータを AI が読み解く エンジン温度、振動、油圧などのフライトデータを時系列グラフで表示し、 AI が異常値の傾向を自動判定します。過去のフライトとの比較も可能です。 ベテラン整備士が経験に基づいて「この数値の傾向は気になる」と判断していたプロセスを、 AI が 24 時間自動的に実行します。属人的な判断を組織的な仕組みに変え、見落としリスクを低減します。 フライトデータの時系列表示。各パラメータの推移を一画面で確認。 AI による分析結果。エンジン健全度スコアや異常傾向を自動判定し、注意が必要な箇所をハイライト。 ケータリング搭載管理 — 搭載計画から在庫管理まで一元化 機内食の搭載計画と在庫管理を統合しています。「どの機材のどのギャレーに、どのカートを搭載するか」を視覚的に管理できます。在庫状況・販売実績・需要予測まで一画面で確認でき、欠品リスクの早期検知と発注判断を支援します。 ケータリング搭載の遅延はターンアラウンド全体に波及します。搭載計画を事前に最適化し、在庫不足を予測段階で検知することで、当日の手戻りを防ぎます。また、エアライン別のデータ分離により、外航受託便でも正確な搭載管理が可能です。 品目別の搭載数と在庫引き当て。欠品リスクを事前に検知。 ケータリング管理の概要。搭載計画の全体像を把握。 機材別カート配置図。搭載位置を視覚的に指示。 乗客情報 — サービス品質の事前準備 搭乗予定の乗客情報を事前に把握し、サービス品質の準備に活用できます。上級会員の比率が高い便では追加の対応準備が必要になりますし、販売チャネルの偏りは今後のマーケティング施策にも活きるデータです。 会員ランク別構成。上級会員比率を事前把握し、サービス準備の判断材料に。 販売チャネル別構成。予約経路の傾向分析に活用。 分析ダッシュボード — 過去データから改善ポイントを発見 蓄積されたターンアラウンドデータを集計し、「どのタスクが遅れやすいか」「どの空港で遅延が多いか」「時間帯による傾向はあるか」といった分析が行えます。 感覚的だった改善活動が、データに基づく定量的な PDCA サイクルになります。「特定空港の給油は午後に遅延しがち」「特定機材の清掃は他機材より 10 分長い」といった具体的な知見が得られ、人員配置やプロセス改善の根拠になります。 ターンアラウンド分析ダッシュボード。タスク別の平均所要時間・遅延傾向・空港別パフォーマンスを可視化し、改善すべきポイントを明確にする。 AWS アーキテクチャ ここからは、本ソリューションを支える AWS の技術構成について解説します。 データレイクの構成 データレイクの AWS 構成。 CloudFront → ALB → ECS Fargate（Private Subnets）。 S3 Files Volume をマウントし、 VPC Endpoint 経由で AgentCore Gateway → Knowledge Base → Claude に接続。 EventBridge → SQS → Lambda → DynamoDB でカタログ自動同期。 S3 共有バケットに格納された航空データ（38 GB / 29 万ファイル）を Amazon Bedrock Knowledge Bases でベクトルインデックス化し、 Amazon Bedrock AgentCore Gateway 経由で統合的にアクセスします。 主要コンポーネント： Amazon Bedrock AgentCore Gateway — RAG 検索の統合エンドポイント（IAM SigV4 認証、複数システムから共有利用） Amazon Bedrock Knowledge Bases — S3 上の航空データに対するセマンティック検索 Amazon S3 Vectors — サーバーレスベクトルストア（管理不要、低コスト） Amazon Titan Embed V2 — 埋め込みモデル（1,024 次元） Amazon EventBridge — S3 オブジェクト変更のリアルタイム検知 Amazon SQS — デバウンス付きバッファ（5 分ウィンドウで変更を集約） AWS Lambda — カタログインデクサー、 KB 同期、統計集計（6 関数） Amazon DynamoDB — カタログメタデータ・統計情報のサーバーレス管理 カタログ自動同期の仕組み S3 オブジェクト変更 (PUT / DELETE) → EventBridge ルール（リアルタイム検知） → SQS キュー（デバウンス: 5 分ウィンドウで集約） → Lambda（カタログインデクサー） → DynamoDB 更新 → Knowledge Base インジェスション（ベクトル再構築） S3 にデータを置くだけで AI 検索インデックスが自動更新される仕組みです。 SQS の 5 分デバウンスで細かな変更を集約し、 Lambda 起動回数とコストを最適化しています。 ターンアラウンド管理の構成 ターンアラウンド管理の AWS 構成。 ECS Fargate 上のフロントエンド（React + Three.js + MapLibre）とバックエンド（Express.js + WebSocket）が、 AgentCore Gateway 、 Transcribe 、 Location Service 、 S3 Files と連携。 ユーザー（ブラウザ） → CloudFront → ALB → ECS Fargate (フロントエンド: React + Three.js + MapLibre) → ECS Fargate (バックエンド: Express.js + WebSocket) ├→ AgentCore Gateway (SigV4) → KB → Claude [AI 分析] ├→ Amazon Transcribe (WebSocket) [音声文字起こし] ├→ Amazon Location Service (API Key) [地図・航路描画] └→ Amazon S3 + S3 Files (/mnt/s3) [データストレージ] └→ エフェメラルキャッシュ (50 GB) [高速読み込み] 主要コンポーネント： Amazon Bedrock (Claude Sonnet 4 / Claude 3.5 Haiku) — AI 分析・要約生成 Amazon Transcribe — 作業員音声のリアルタイム WebSocket 文字起こし Amazon Location Service — 空港マップ・航路可視化（API Key 方式） Amazon ECS on AWS Fargate — バックエンド・フロントエンドのコンテナ実行 Amazon S3 + S3 Files — 38 GB / 29 万ファイルの共有ストレージ（NFS マウント） Amazon Polly — デモ音声生成（Neural ボイス、デプロイ時バッチ処理） AWS Cost Explorer — システム別コスト可視化 Kiro によるスペック駆動開発 本ソリューションは、 AWS が提供する AI 搭載 IDE Kiro を活用して構築しています。 Kiro のスペック駆動開発では、開発者が自然言語で要件を定義すると、 AI が設計・タスク分解・コード実装までを一貫して支援します。 自然言語で要件を記述（requirements.md） → Kiro が技術設計を提案（design.md） → タスクリストを自動生成（tasks.md） → タスクに沿ってコードを実装 → 受入基準に基づく検証 本プロジェクトでは、 12 のサブシステムにわたる 79 個の仕様ファイルを Kiro のスペックとして管理しています。 24 の要件を 9 つのフェーズに分割して段階的に実装しました。要件を自然言語で整理すれば、ここで紹介した規模のソリューションを Kiro で開発できます。 まとめ 本ソリューションは、航空オペレーションが抱える「データのサイロ化」「作業進捗の不可視性」「暗黙知の属人化」という 3 つの課題に対して、 AWS サービスの組み合わせでどこまで解決できるかを示すリファレンス実装です。 散在するデータは AI が横断検索する。 Amazon Bedrock Knowledge Bases + Amazon Bedrock AgentCore Gateway により、 29 万ファイルに自然言語で即座にアクセス 作業進捗はリアルタイムに見える化。 無線機・モバイル対応で、口頭報告に頼らない進捗管理を実現 フライトの状況は地図上で一目でわかる。 Amazon Location Service により、全機材の航路・空港状況をリアルタイムに可視化 データ変更は自動でカタログに反映。 EventBridge + SQS + Lambda のイベント駆動で運用負荷を最小化 仕様は自然言語で書き、 AI が実装する。 Kiro のスペック駆動開発で、 12 システム・ 79 仕様を効率的に管理・実装 このアーキテクチャパターンは航空に限らず、製造業・物流・医療など、複数の業務システムにまたがるデータを AI で統合検索・分析し、現場の意思決定を支援したい多くの産業で応用可能です。要件を整理すれば、 Kiro で開発できます。 著者 アマゾンウェブサービスジャパン合同会社 エンタープライズ事業統括本部 交通・物流事業本部　シニアアカウントマネージャー 金子 暁人 アマゾンウェブサービスジャパン合同会社 技術統括本部 ソリューションアーキテクト 稲田 崇志