Ntsb Investigations

@pipeworx/ntsb-investigations

航空機の登録記号（テールナンバー）またはメーカー／モデルで検索できる、NTSB の航空事故・インシデント調査です。一致する各調査について、NTSB 番号、発生日、場所、負傷レベル、飛行段階／発生事象、推定原因、調査結果、NTSB のドケットリンクを返します。

Pipeworx の一部です。AI エージェントを 1721 以上の稼働中のデータソースに接続する MCP ゲートウェイです。これは独立した非公式の統合であり、上流プロバイダーとは提携関係になく、推奨も公開もされていません。

ツール

• ntsb_search_investigations({ registration?, make?, model?, year?, state?, limit? }) — registration または make が必要です。model はメーカー内で検索範囲を絞ります（"172"、"172S"、"172N" など、接頭辞で一致します）。year は発生年で絞り込みます。また、N 番号が時間の経過とともに別の航空機に再割り当てされた場合に、登録記号での一致結果を絞り込む方法でもあります（下記参照）。一致がある場合は { found, data_as_of, source, count, query, results[] } を返し、一致がない場合は { found: false, data_as_of, source, query } を返します。

認証

キー不要です。上流アカウントも API キーも必要ありません。

データソース

• https://data.ntsb.gov/avdata — NTSB 独自の eADMS 航空事故データベース（avall.zip。Microsoft Access の .mdb 一括ファイル。2026-10-07 に稼働を確認。圧縮時約 96 MB／展開時約 561 MB）。これは完全かつ最新のデータセットです。CAROL の航空検索が照会するデータと同じもので、NTSB 自身がこの用途向けに提供している一括ファイルです。
• https://data.ntsb.gov/Docket/?NTSBNumber=NNN — 指定された ntsb_number の NTSB ドケットページです。最終報告書と関連資料が公開されています。この同じデータセットから取得した実際の事例について、稼働を確認済み（HTTP 200）です。

CAROL 独自の検索や、新しい開発者 API を使わない理由

NTSB の最新の検索 UI である CAROL（data.ntsb.gov/carol-main-public）を最初に調査しました。その JSON エンドポイント（api/Query/Main、api/Query/FileExport）は文書化されていません。また、公開されているサードパーティーの CAROL プロキシと NTSB 独自の CAROL-Guide.pdf からリバースエンジニアリングした QueryGroups／QueryRules リクエストの形式は、すべて HTTP 500（"An unknown exception occured."／"An error has occurred."）を返しました。フロントエンドには開発者ツールを使わずに確認できるスキーマがなく、サーバーも、実際のブラウザーセッションから送信される形式と必要な形式が異なる理由を示しません（おそらく、最初のクエリの前に CAROL 独自の JavaScript が設定する、サーバー側セッションまたは偽造防止の要件です）。

NTSB は developer.ntsb.gov で、より新しい REST API（Azure API Management ゲートウェイ経由の Aviation／Safety Recommendations／Data Dictionary API）も提供しています。このポータルで API を呼び出すには、開発者アカウントに登録し、サブスクリプションキーを取得する必要があります。これは認証の壁にあたります。このリポジトリの既定のルールでは、別途キーの利用を決定しない限り、これを回避する実装を行うことは認められていません。一方、このパックが実際に読み取るのは、一般公開されている一括ファイルです。

データの更新

node mcps/ntsb-investigations/scripts/refresh.mjs [--local-mdb <path>] [--dry-run] [--r2-mode auto|api|wrangler] [--shard-max-bytes <n>]

avall.zip をダウンロードして解凍し、5 つのテーブル（aircraft、events、 narratives、Findings、Events_Sequence、eADMSPUB_DataDictionary）に対して mdb-export（mdbtools — brew install mdbtools / apt install mdbtools）を実行します。それらを結合して、航空機ごとに 1 件のフラットな事故一覧を作成し、1 つのオブジェクトとして書き込むのではなく、共有の pipeworx-datasets R2 バケット（mcps/indiana-code、 mcps/illinois-code、mcps/crs-reports と同じバケットです。scripts/lib/statute-store.mjs を参照）にシャード分割して格納します。

• ntsb/by-make/<slug>.json — 製造元ごとに 1 つの配列です。フラットなシャードが約 4 MB を超える製造元（今回の取得では CESSNA のみ）は、さらに ntsb/by-make/<slug>/<year>.json に分割します。
• 5 行未満の製造元（約 4,174 種ある acft_make の生の文字列の大半は、実在する別個の製造元ではなく、OCR やデータ入力の表記ゆれです）は、各製造元につき 1 つずつ小さなファイルを作るのではなく、安定したハッシュを使って 16 個の ntsb/by-make/_other/<bucket>.json シャードにまとめます。
• ntsb/by-registration.json — 正規化された登録記号から、それが属する (make, year) の組への対応表です。これにより、登録記号のクエリでは全件走査を行わずに、読み込むべきシャードを特定できます。
• ntsb/manifest.json — data_as_of、source、record_count と、各製造元の正確なシャード構成（flat / by_year とその年 / bucket）を記録します。これにより、読み取り処理では製造元のデータがどのキーにあるかを調べるために R2 を確認する必要がありません。

この方式により、以前の単一オブジェクト設計（ntsb/aviation-cases.json、約 27 MB）は廃止されました。以前はキャッシュなしで、呼び出しのたびにデータセット全体を再取得して解析していたため、同時に 2 件の呼び出しがあると、1 つの isolate 内に全件の解析結果が 2 つ保持されていました。現在の src/index.ts は、マニフェストと、各クエリに必要なシャードだけ（製造元／モデルのクエリでは 1 つ、登録記号のクエリでは、再利用された登録記号に対応する異なる (make, year) の組から特定される数個）を読み込み、古い単一ファイルは読み込みません。このスクリプトは、シャードの配置後に古い単一ファイルをバケットから削除します。意図的にモジュールスコープのキャッシュは使用していません。src/index.ts の冒頭のコメントを参照してください。Supabase のマイグレーションは不要で、ストレージには R2 のみを使用します。--local-mdb を指定すると、96 MB の avall.mdb を再取得せず、すでにダウンロード済みのファイルを再利用します。各レスポンスの data_as_of は、上流データのレコードごとの日付ではなく、更新を最後に実行した日付です。

登録記号（N 番号）の再利用

FAA は、尾翼番号を異なる航空機に対して時期を変えて再割り当てします。 ntsb_search_investigations({ registration }) は、この情報を暗黙にまとめてしまうことはありません。該当する尾翼番号の過去の一致がすべて返され、それぞれに固有の event_date、make、model が含まれます。同じ登録記号に対して複数の結果が返された場合、year を渡すと、そのうち 1 つの使用期間に絞り込めます。

対象範囲の広い製造元では、絞り込みが必要な場合があります

一般的な製造元のうちいくつか（今回の取得では CESSNA）は、データ行数が多いため、年ごとに 1 つのシャードへ分割されています。こうした製造元について model も year も指定せずにクエリすると、その製造元の年別シャードをすべて読み込まなければ回答できません。データセット全体の走査ではありませんが、他のクエリで必要な小さなオブジェクト 1、2 個を読む場合と比べると負荷が大きくなります。年別シャードの数が小さな固定上限を超えると、ツールはより大きな読み込みを暗黙に実行する代わりに、year（または、読み込むシャードは変わりませんが、絞り込む意義のある model）を指定するよう求めるメッセージを返します。製造元／モデル／年の組み合わせや、単独で指定した一般的でない製造元には影響しません。

クイックスタート

MCP クライアント（Claude Desktop、Cursor、Windsurf など）に追加します。

{
  "mcpServers": {
    "ntsb-investigations": {
      "url": "https://gateway.pipeworx.io/ntsb-investigations/mcp"
    }
  }
}

このエンドポイントが実際に提供するもの

https://gateway.pipeworx.io/ntsb-investigations/mcp の tools/list は、上の表にあるツールに加えて、共有 Pipeworx メタツールである ask_pipeworx、 discover_tools、search_within、remember／recall など、ゲートウェイ全体で使えるツール一式を返します。そのため、表示されるツール数はこの表より多くなります。単一パックのエンドポイントには現在、パック独自のツールとともに、およそ30個の共有ツールが一覧表示されます。接続の initialize 応答には正確な対象範囲が記載されており、その日の状況を確認するための信頼できる情報です。

これは意図的なものであり、誤って多重化されているわけではありません。メタツールを使うと、このパックが対応していない質問にも、カタログ全体を検索する ask_pipeworx を通じて回答できます。MCP サーバーをもう1つ追加する必要はありません。現時点では、メタツールなしでパックのエンドポイントを接続する方法はありません。追加のスキーマによるコンテキスト消費がルーティングの利点を上回る場合は、複数のパックエンドポイントではなく、フルゲートウェイに一度接続してください。

または、Pipeworx のフルゲートウェイに接続すると、このパックだけではなく、すべてのパックのツールが直接一覧表示されます。

{
  "mcpServers": {
    "pipeworx": {
      "url": "https://gateway.pipeworx.io/mcp"
    }
  }
}

どちらの URL も、同じゲートウェイと同じ1721以上のデータソースに接続します。唯一の違いは、どのパックのツールが直接一覧表示されるかです。どちらからでも、ask_pipeworx を使ってすべてのツールにアクセスできます。

MCP クライアントがない場合：HTTP で呼び出す

curl -X POST https://gateway.pipeworx.io/v1/tools/ntsb_search_investigations \
  -H 'Content-Type: application/json' \
  -d '{"make":"Cessna","model":"172","year":2024,"limit":10}'

最初の呼び出しにアカウントは不要です。任意のツールを確認するには、GET https://gateway.pipeworx.io/v1/tools/ntsb_search_investigations を実行します。ツールを検索するには、{"query":"..."} を指定して POST https://gateway.pipeworx.io/v1/tools/search_packs を実行します。

スタンドアロン（ゲートウェイアカウント不要）

このパッケージはローカルの stdio MCP サーバーとしても実行できます。Pipeworx アカウントも、ゲートウェイへのラウンドトリップも不要です。

{
  "mcpServers": {
    "ntsb-investigations": {
      "command": "npx",
      "args": ["-y", "@pipeworx/mcp-ntsb-investigations"]
    }
  }
}

または、起動することを確認するために、直接実行します。

npx -y @pipeworx/mcp-ntsb-investigations

stdin／stdout 経由で MCP 通信を行い、このパックのツールのみを対象に initialize／tools/list／tools/call に応答します。上記のゲートウェイ接続で追加される共有メタツールはありません。同じソース、同じツールで、ask_pipeworx によるルーティングはありません。

ask_pipeworx を使用する

ツールを直接呼び出す代わりに、自然な英語で質問できます。この方法は、上記のパックエンドポイントとフルゲートウェイのどちらでも使えます。

ask_pipeworx({ question: "your question about Ntsb Investigations data" })

ゲートウェイが適切なツールを選び、引数を自動的に設定します。

詳細

• ドキュメントとガイド
• pipeworx.io

ライセンス

MIT