久能 弘嗣(日本経済新聞)/世界のメディアは、航空機事故をどのようにビジュアルで報道しているのか

2025年12月2日に PYNT竹橋で開催されたイベント「災害と事故をめぐる可視化:報道・デザイン・建築をつなぐ対話」における、日本経済新聞社 シニアニュースルームデザイナー・久能 弘嗣さんの講演です。2024年1月の羽田空港JAL機炎上事故の報道コンテンツをどう作ったか、そして海外メディアが航空機事故をどう可視化しているかを紹介します。


スライド

日本経済新聞の久能と申します。本日は「世界のメディアは航空機事故をどのようにビジュアルで報道しているのか」というテーマで、弊社の事例なども含めてご報告させていただきます。

2024年1月に羽田空港で JAL の航空機と海上保安庁機が衝突・炎上するという大きな事故がありました。日経がその事故をどのように報道したのか、制作の裏側をお話しします。そこから話を広げて、海外メディアは航空機事故をどのようにビジュアルで報道するのか、日頃ビジュアルコンテンツを収集しているのでまとめてまいりました。

自己紹介

シニアニュースルームデザイナーという役割で仕事をしています。聞いたことがない役割の名前だと思いますが、対外的な呼称として社内で昨年定められたものです。

2012年に武蔵野美術大学を卒業し、グラフィックデザインやタイポグラフィなどをやっていました。卒業後はデザイン事務所でエディトリアルや展覧会のデザインなど、デザイン業務全般をやっていました。

そこから、データ可視化やインフォグラフィックスで情報を読み手に伝えることを専門的にやりたいと思い、インフォグラフィックスをやるために新聞社に行きました。新聞社は「ニュースグラフィックス」という言葉があるくらいインフォグラフィックスが多いので、どこか新聞社に入りたいと思っていたところ、今の会社がちょうど募集していたので入りました。

そこで紙面用のグラフィック、ひたすらチャート作りをやって、しばらくしてプログラミングでグラフィックスが作れるようになり、デジタルの職場に異動して、これからご紹介するようなデジタルコンテンツの制作を始めて、早10年目に突入というところです。

これまでの仕事では、これからご紹介する JAL 機の事故のコンテンツや、コロナ禍における感染状況をビジュアルで伝えるコンテンツを作っていました。また、衛星画像やオープンソースを使ったビジュアルの制作にも力を入れていて、ガザの戦争に関する報道もやっています。少し時間が空いてしまいましたが、大統領選の開票なども担当していました。

1. 日経は「JAL機炎上」事故報道をどう作ったか

2024年1月1日に能登で大きな地震があり、その翌日、羽田空港で JAL の航空機と海保機がぶつかって大きく炎上してしまうという事故がありました。

それをオープンソースから事実を掘り起こし、3D空間上に再現しながら、ユーザーに何が起こったのかを伝えるコンテンツを作りました。Flightradar24 というデータサービスや Google Earth を使い、これから紹介する Blender というアプリケーションや After Effects などを組み合わせて、事故状況を再現しています。

SNS上に投稿された写真・映像なども使いながら、リアリティを持ってどのような事故だったのかを伝えています。

我々が近年力を入れていたのが**オープンソース・インテリジェンス(OSINT)**です。公開情報や SNS 投稿、当局の発表など、誰もが手に入れられるデータをもとに事実を掘り起こす。その技術を用いて「どうもこういうことらしいぞ」ということを伝えているというものです。

コンテンツには、通信の記録をタイムテーブルにして、どういうやり取りがあったのかを音声とともに並べたものもあります。また、事故発生から1週間で作ったので、1週間経った時点でどのあたりに課題が残っているのかをまとめたり、専門家の立場から「この事故を冷静に分析するとどう思われますか」というコメントをいただいたり。手に入るデータで「そもそも羽田空港とはどういう空港なのか」というデータから羽田空港を見る、という構成にもなっていました。

制作の流れ ― 正月に有志13人

ざっくりとしたチーム構成は、新聞社でよく言われる「デスク」という立場のエディターが3人、記者が6名(クレジット掲載ベースなので、断片的に関わった記者はほかにもいます)。クリエイティブは、私を含めてウェブディレクター、デザインエンジニア、デザイナー、エンジニアの4名。総勢13人が、正月にもかかわらず有志で集まって作りました

流れとしては、事故発生と同時に Slack のチャンネルが立ち上がり、そこに取材・調査の状況が上がってくる。これがキックオフです。

3Dのモデリングや動画に強いデザイナーがいて、彼を中心にデジタル空間上で事故状況を再現していきました。

私は事故発生と同時に取材の状況や Slack のチャンネルを追っていて、いろいろ集まってきている、「これだけ材料があればビジュアル・ストーリーテリングができそうだ」と判断したあたりで Figma での構成を始めました。そして「ビジュアルデータ」という自由度が高いインフラで、まるごと手作りするという流れで作っていました。

3D再現動画の作り方

冒頭でお見せした、飛行機が動く動画の部分です。主に使ったのは5つ――Blender、Google Earth Studio、(ADS-B のデータ)、Flightradar24 / FlightAware、After Effects です。

3Dモデルは Blender で作り、航空機の飛行経路データと衛星画像は Google Earth Studio で管理。データは Flightradar24 / FlightAware から取得しました。

Google Earth Studio では、KML というデータを入れると航空機の経路がプロットされます。下にタイムラインが付いていて、カメラワークを設定できます。

Google Earth Studio で編集したデータを Blender に持っていきたい、というときにどうしようかと彼が悩んでいたところ、GitHub 上に Earth Studio Tools というプラグインを見つけた。これを見つけたおかげで何とか Blender に持っていくことができて、動画を作ることができたと言っていました。

Blender 上で飛行機のモデルを置き、アニメーションをつける。最後に After Effects で動画として調整します。コンテンツ上では、実際の写真と3Dの空間を重ね合わせるような処理を加えたり、航空機がどういう動きをしたと見られるかという矢印を加えたりと、最終的な動画としての処理を After Effects 上で加えていました。

これが、デジタル空間上に事故状況を再現するプロセスです。昨今のジャーナリズム界隈ではスペーシャル・ジャーナリズム(空間ジャーナリズム)3Dリコンストラクションと呼ばれています。

Webページをどう作ったか

材料が集まってきた段階で、ビジュアルストーリーを Figma で構成し、「こういう話の順序にしたらいいのではないか」という叩き台を私が作る。それをエディターやリポーターと一緒に Figma を見ながら「ああしたらいい、こうしたらいい」と議論することを繰り返し、「この構成で良さそうだね」となった段階でプログラミングに入ります。

「ビジュアルデータ」は内部的な呼び名で、インタラクティブなコンテンツ群のことです。これらは HTML、CSS、JavaScript を用いて1つ1つ手作りしています。フルスクラッチで、それをひたすら1週間で書き上げるということをやっています。

初めてインタラクティブなコンテンツを公開してから10年が経ちました。その10年の蓄積を CSS のフレームワークとして開発していて、定型化できるところはそのフレームワークで組み上げれば、統一されたタイポグラフィでビジュアルコンテンツができる。中長期的にそれを育て続けているというもので、これも活用します。

スクロリーテリングの仕組み

「スクロリーテリング」という言葉を使いますが、改めておさらいすると――背景がユーザーのスクロールに合わせてインタラクティブに動き、その中で特定のシーンに合わせて原稿が流れてくる。スクロールさせながら背景が動き、説明したいことを解説するテクニックです。時系列的な表現や段階的な表現をより分かりやすくするので、複雑な事象の場合によくこの手を使います。

技術的にそれほど難しいものではありませんが、スクロリーテリングのフレームワークを独自に作っています。

背景で飛行機が消失する瞬間を表現しているのですが、デジタルに詳しい方は「背景に MP4 か何かがあって制御しているのかな」と想像されるかもしれません。実はこれ、1枚1枚が画像ファイルです。原稿が流れてくるタイミングに合わせて、止めたい画像を表示させるというロジックになっています。この JAL のコンテンツでは290枚ほどの画像を背景に仕込んでおいて、スクロールに合わせて該当のシーンを表示させています。

技術的には MP4 でもできますし、MP4 の方が動きは滑らかです。ただ、スマートフォンに低電力モード(省エネモード)がオンになっていると、そもそも自動再生がされないという仕様があったりします。もう1つは、MP4 だとローディングの状況によっては、説明したいシーンのときにテキストが来なかったりする。シーンと原稿を精密に、確実に合わせたいときは、画像のフリップブックにした方が正確に合わせられるというメリットがあるので、こちらのやり方をよく使っています。

レスポンシブ ― どんなデバイスでも同じ体験に

デザインの話になりますが、レスポンシブ・ウェブデザインに気をつけましょう、と。どんなデバイスやシチュエーションでも、情報が欠落することなく適切に見やすく表示されるようにデザインとコーディングをする。

具体的には、交信のタイムラインは PC だと大きな画面なので一覧性を高くできますが、スマホでは画面が小さく、全部をぎゅっと詰め込もうとすると無理が生じるので、レイアウトを変える。グラフィックスも、PC で大きく表示できるものをそのままスマホに持っていくと文字が小さくて読めないので、スマホ版と PC 版で画像を作り分けて出し分けましょうということをしています。

記者においては「この暗闇の中で起きた事故をどこまで調査・検証できるのか」、デザインにおいては「フロントエンドでうまくいくか、レスポンシブでうまくいくか、コーディングは間に合うか」、エンジニアに関しては「バグや不具合が出ないか、どのデバイスでも安定して動くか」――それぞれの領域で全力を出して1週間で作る、ということをしておりました。

(途中の質疑から)

Q. 事故発生後すぐに Slack が立ち上がったと伺いましたが、報道機関ではよくあることなのでしょうか。「ビジュアライズするべき」という判断でチームが立ち上がるのですか。

弊社の実情しか存じ上げないのですが、少なくともこのときは、社内で部を横断した OSINT のチームが立ち上がっていて、そこで部を超えたコミュニケーションがまずあった。そのチームがオープンソースから分かることや、ガザの戦争がどうなっているかといった定点観測をいろいろなところでしていて、それをウォッチしていた有志たちが集まって立ち上げた、という感じです。

「ビジュアライズすべき」という判断は、トップダウンのこともありますし、今回はボトムアップ型でした。どちらもあります、という感じになってしまいますが。

2. 海外メディアの航空機事故報道を追う

ここからは、海外メディアが大きな航空機事故をどのように報道するのかを事例としてまとめてきました。

2024年、2025年と大きな航空機事故がありすぎました。昨年末に韓国でバードストライクが主な要因とされる墜落事故、今年1月にワシントンでジェット機と米軍ヘリが空中衝突する事故、今年6月にインドで航空機が墜落して241名の方が亡くなるという大きな事故が相次ぎました。

ロイター ― 速さとテーマ設定のうまさ

ロイターばかりになってしまいますが、とにかく速くて、ビジュアルなまとめ方がうまい。

韓国の事故では、翌日には事故の概要をまとめたものを出しています。「こういう機体がまず落ちて、生存者はここに座っていて」という話と、鳥の寝ぐらはどこにあって、どういう飛行経路で、といったことをまとめる。Flightradar24 と Google Earth、プラネットなどの衛星画像を使うのが、もう定石のような勢いで出てきます。

そして1か月後くらいに、バードストライク(野生動物と航空機が衝突することの総称)とはどういうものなのかを、データとビジュアルを使いながら解説するコンテンツを出しています。

  • 航空機のフライトの数を線の量で示し、それが野生動物と衝突する可能性を示す
  • バードストライク自体が生命を脅かすような事故につながることは9割方ない、というのをデータビジュアルで表現。一部は機体の損傷につながる
  • バードストライクはどのタイミングで起きることが多いか(着陸・離陸、アプローチという段階で最も多い)
  • 過去の例を見ると、野生動物との衝突がどれほど命を落とす事故になったかを、歴史的な事例で可視化(円の大きさが死者数)
  • どこに衝突することが多いか

ロイターは絵がとにかくうまくて、どういう野生動物にぶつかることが多いかをひたすらイラストで描いてまとめていたりします。データビジュアルで言うと、夏の時期に多いといったことも。多岐にわたる角度からバードストライクを捉えている。1か月後くらいに出しているのですが、その事故自体がどういうテーマ・軸なのかをキャッチして、コンテンツの軸を作っているのがすごくうまいなと思いました。

ワシントン空中衝突 ― 「ヘリコプターからの視点」の再現

今年1月にワシントン上空で起きた、ジェット機とヘリコプターの衝突事故です。

ここ数年で、このビジュアルの作り方が初段の報道に出てくるようになったなという印象があります。Google Earth Studio に Flightradar24 の航空機データおよび ADS-B のデータを使ってプロットし、デザインツールでグラフィックスとしての見た目を整えて、「とりあえずこういう状況だった」というのをビジュアルで初報的に出す。これが結構決まったパターンになってきたかなという印象です。このときは、上空の衛星画像から事故発生までの2分間の流れを追うというものを、ほぼライブ更新的に作っていました。

ポイントはここからです。ニューヨーク・タイムズが1週間後に、ヘリコプター側からの視点を再現したコンテンツを作りました

衝突の瞬間の映像があり、「このヘリコプターは一体何を見ていたのか、どういう見え方をしていたのか」を、オープンソースのデータから3D空間上に再現する。これを見ると、上空から見るといくつも航空機が飛んでいるのが、ヘリコプターの視点から見るとかなり密集して見えるということが可視化されています。

さらに、パイロットは夜間に暗視ゴーグルをつける。光が増幅されて視認しやすくなるのですが、その特性からすると夜間の街の明かりに溶け込んで、陸が近い場面では逆に見えづらいこともある――といったことも解説しています。これが1週間後ぐらいのペースで作られるというスピード感です。

さらに数週間後、ワシントン・ポストが出した例。考え方としては同じくオープンデータからヘリコプターの視点を再現するものですが、その作りがすごい。フルスクリーンでコンテンツを作っていて、見え方に没入感がある。同様に、複数の航空機が密集している様子を可視化しています。

ワシントン・ポストの書き方では「ヘリコプターのパイロットは別の航空機と見間違えた可能性があることが分かった」というくらいの表現です。ポイントは、単なるイメージ映像として作っているのではないこと。OpenStreetMap、航空データ各種、通信の記録に加えて、この飛行経路を何度も飛んだことがあるパイロットにインタビューするなど、裏付けも作りながらこれほどの再現コンテンツを作る。その力の入れようが、すごいところまで来ているなという感じがしました。

インド航空機墜落 ― 「安全な座席はない」

6月に起きたインドでの墜落事故です。こちらも初報的なものは似た印象で、箱庭的に空から見下ろして、どのような経路で飛んでいってどこでクラッシュしたかを作っています。車輪がしまわれていなかった、翼のフラップがうまく動いていなかったのではないか、など事故直後はいろいろな情報がありましたが、1〜2日後には「その時点で分かる限りのこと」を可視化して伝えていました。この手のものは大体1〜2日で出るようになってきたという、可視化報道の速度感です。

2か月後くらいに、この事故のポイントの1つとして――242名が搭乗していて、唯一1人だけ飛行機から飛び降りて奇跡的に助かった方がいた。そこで「生存者がいた航空機事故が起きた場合、航空券の中で一番安全な座席はどこなのか」が毎回話題になる。ロイターは、データから「生き残れる席」「絶望的な事故が起こった場合の生き残れる確率」を見てみるというコンテンツを作っていました。

今年のインドの事故は生存率としては最低でした。ビースウォーム的なチャートで、生存者が1人でもいた場合の生存率をプロットしていて、エア・インディアの事故が一番左(割合が低い方)に来ている。242名中1名なので0.4%の生存率

結論として「安全な席はない」ということをデータから追っています。生存者がどこに座っていたのかを分かる限りプロットしていて、コックピット側、フロントセクション、中央席、後部セクションと、ざっと見る限りいろいろなところに生存者がいる。当たり前と言えば当たり前ですが、ひいては「安全な座席はない」ということの表現になっています。

そして50年にわたる航空機事故の生存者数を追ってプロットしたものが、なかなか見応えがあります。オレンジの1粒がエア・インディアの事故で助かった男性。タイムラインに沿って「これくらいの事故があって、これくらい生存して」というのをとにかくプロットしている。50年分追っていくと、50年前に近づくにつれてだんだん塊の数が大きくなってくる。今の航空機事故は減っているということの表れかもしれません。

可視化報道の「型」

バードストライクの件もそうですが、事故直後に「どういう事故状況だったのか」が報道された後、一拍置いて「その事故のコアになるテーマは何なのか」を定めて可視化する。そういう一段目・二段目があるかなという感じがしていました。

まとめると、最近の航空機事故の可視化の流れはこうです。

  1. 即時:Google Earth Studio と Flightradar24 で事故状況を箱庭的に可視化する。すぐ作れるので、とにかく出す
  2. 1週間程度:手に入るオープンデータから分かる事実を掘り起こしてまとめる
  3. 数か月後:視野を広げて「この事故が意味するものとは」あるいは事故にまつわるテーマを広げたストーリー展開

ほかにも、乱気流の影響で緊急着陸があった件(5月)や、インド・パキスタンの緊張によってパキスタン上空を飛べなくなり、路線が迂回する飛び方をしなければならなくなったことが飛行経路のデータから明らかに可視化できる、といった例もあります。

最後に弊社の事例に寄せると、日航機ジャンボが40年前に墜落して520名の方が命を落とすという世界最悪の事故がありました。節目のコンテンツが読売さんでも朝日さんでも出ていました。現代と違うのは、データがリアルタイムのものではなく、過去の書類や発表資料に頼らざるを得ないこと。今のリコンストラクションとはまた別の難しさがあります。

質疑応答

Q. シニアデザイナーの方はアートディレクター的にプロジェクトの品質を保証するほか、「早く出したいがここまでできないと出せない」といったディレクション、コンテンツを出す・出さないの意思決定にも関わるのでしょうか。

基本的に、商品としてクオリティを保てない限り、いい加減なものを出すわけにはいかない。リポーター側の「ここまでは言えるが、これ以上は言えない」という感覚、あるいはクリエイティブの領域で「これ以上の実装は難しいぞ」という判断。「やるかどうか、いつ出すか、どこまでやるか」は基本的に平場で、リポーターとデザイナーとエンジニアが対等に話すのが定着してきたかなという感じはあります。

Q. JAL の事故報道で、お正月に Slack で自然にチームが集まってきた。これは相当チームの人間関係や普段の空気感があってこそなのでは。

私も現場にいた身なのであれですが、やはり「何かせねばならぬ」という人たちが正月休みであれ集まってきたなというのがあります。そこまでのプロセスで、先ほど話した横断的な OSINT チームがあった。記者・エディターとデザイナー・エンジニアが結構ざっくばらんに話すようになって、しばらく経つという感じがあります。過去のコンテンツのキックオフから完成まで、本当に二人三脚、何人何脚で手を取り合って作ることが円滑になったなという感じがあります。

(矢崎:記者・デザイナー・エンジニアそれぞれの職能がありつつ、少しお互いカバーし合う、乗り越え合う側面もあるのですか。)

まさにそうです。報道機関にいる以上、デザイナーもやっぱり新聞を読んでいた方がいいに決まっているし、エンジニアもまた然り。最近その組織で始めているのは、デザイナーもエンジニアも取材に同席する、取材に行くということ。それによってドメイン知識、ベースとなる報道の知識を前提として分かった上で作っていくプロセスの方が、コミュニケーションの質や最終的な成果物のクオリティに直結する。デザイナーにせよリポーターにせよエンジニアにせよ、少しずつ領域をまたいでいくのがものすごく大切ですね。

Q. 日経が日本のマスコミの中で図抜けてデータビジュアライゼーションがうまいと思うのですが、何か戦略的に社内でやっていることはあるのですか。

ありがとうございます、大変誉れなお言葉で。戦略的に、というと――先ほど少し申し上げたように、ビジュアルコンテンツを出して10年経ったというやり続けることもそうですし、やり続ければ社内でも「ちょっとビジュアルコンテンツを作って」と頼っていただけるような関係ができてきた。

戦略的にやっていることの1つとしては、私が所属するグループを3チームに分けるということを、ここ1年ほどやっています。ビジュアル・ストーリーテリング(エクスプレイナリーなもの)、ツール的なもの(エクスプローラーなもの)、そしてビジュアル・インベスティゲーション(オープンソースを使い、視覚的な証拠で事実を掘り起こす)。組織が大きくなってきたので、その中で少しずつスペシャライズさせていく動きが最近のものです。

Q. 今日は事故後に検証するコンテンツが多かったですが、災害では事前(ハザードマップ的なもの)や災害の最中に役立つものという観点もあるかと思います。報道機関の役割としてどうお考えですか。

直接ビジュアルコンテンツに関わることと少しずれるかもしれませんが、やはりフェイクがすごく流れるようになりました。戦地におけるプロパガンダの画像が AI で簡単に作れてバズってしまう。事故が発生したときに「車が流されている映像」がバズっていて、それは過去の報道のものだった――というのは、もうありふれた光景になりつつある。

自戒の念を込めて、やはりいい加減なことを言うわけにはいかない。ビジュアルが簡単に作られるようになりつつある時代だからこそ、真偽をちゃんと確かめてお届けしないといけないなというのはありますね。

(矢崎:海外では NPO が SNS の写真・動画を1つ1つ検証して、本物だけをアーカイブしている。それが裁判や戦争犯罪の証拠になったりする。報道機関がそこまでやろうとすると手に余るのでは。)

その手の話で言うと、やはり画像・写真がどこから来たものであるかを追える必要が出てきています。写真自体に、どこで発生してどこでどういう加工がされて今ここにあるのか、という付随情報をブロックチェーンで作る仕組みを開発している動きもあります。誰がこの画像の真偽を証明するのか。本当に大事ですよね。

Q. プロフィールに「編集とデザイン・エンジニアリングを融合した新たなニュース体を目指す」とありますが、個人として今後実現していきたいことは。

デザインとエンジニアリングとジャーナリズムを混ぜ合わせていくと、いいものができるという実感があります。デザインとエンジニアリングはしばらくやってきたので、もうちょっと自分がジャーナリズムを学んで、どういうときにどういう報道を出すのがベストなのか、自分自身が報道の判断をできるようになれるといいなという感じです。個人的にもニュースを打ったり、いろいろビジュアルコンテンツの出し方を試したり。せっかく報道機関にいるので、ジャーナリズムの領域にどんどん踏み込んでいきたいなというのがあります。

Built with Hugo
Theme Stack designed by Jimmy