乗り継ぎ接続時間チェック
ターミナルを移動しない120分の乗り継ぎは、最低接続時間60分を60分上回るので余裕ありと判定されます。乗り継ぎ時間とターミナル移動の有無を入れるだけで、余裕・ぎりぎり・危険が分かります。ブラウザで無料で使えます。
- 無料
- ブラウザで動作
- 登録不要
- データは端末の外に出ません
無料で実行
計算例
- 乗り継ぎ時間 (分)
- 120
- 最短乗り継ぎ時間 (分)
- 60
- 余裕時間 (分)
- 60
- ステータス
- comfortable
乗り継ぎを逃すと旅程は崩れ、次のゲートまで落ち着いて歩けるか走ることになるかの差は、予定された乗り継ぎ時間が空港の実用的な最小接続時間を上回るかどうかにかかることが多いです。このフライト乗り継ぎ接続時間チェックは、停留時間(分)とターミナル変更の要否フラグを受け取り、航空会社で広く用いられる最小接続時間の目安に照らして、接続を快適・余裕なし・危険に分類します。同一ターミナルは60分のMCT、ターミナル変更は90分、適用MCTを30分以上上回る場合は快適とマークします。負の時間は拒否されるため、不正データが有効なリスク評価に見えることはありません。
快適・余裕なし・危険の決め方
航空会社が公表する最小接続時間は、通常運航下で乗客が降機し、ターミナル間移動を終え、次便に搭乗するまでに平均で要する時間を表します。本機能はライブのMCT表を取得するのではなく、その目安の透明で決定的な近似を符号化します。乗り継ぎがMCTより短い場合、status は risky、sufficient は false です。
天候や遅延の前から一般的な目安を下回っています。MCTを満たしても MCT+30 分未満なら status は tight、sufficient は true です。多くのキャリアでは法的・運航上は妥当でも、到着遅れや長いタキシングの余裕は少ないです。
少なくとも MCT+30 分あれば status は comfortable です。最低時間に加え、多くの常連が「落ち着いて歩ける」実務閾値とみなすバッファがあります。
活用例
予約フローでの接続警告
チェックアウト前に、各複数区間の停留を乗り継ぎ分数とターミナル変更で採点し、risky はブロック/警告し、tight を強調します。
企業出張ポリシーの確認
提案旅程を一括分類し、快適帯未満の接続は担当者または出張者の承認へエスカレーションします。
よくある質問
このツールが使う最小接続時間は何ですか?
同一ターミナル:60分。ターミナル変更:90分。comfortable は少なくともそれらの下限+30分が必要です。航空会社風の一般的な目安であり、空港のライブMCTデータベースではありません。
tight と comfortable の違いは何ですか?
tight はMCT以上だが MCT+30分未満です。comfortable は予定乗り継ぎが少なくとも MCT+30分ある場合です。
ターミナルの移動とはどんな場合ですか?
次の便までに別のターミナルや別の空港へ移る必要がある乗り継ぎです。シャトルでの移動や保安検査のやり直し、長い歩行で時間がかかるため、最低接続時間は90分になります。
「危険」と判定されるのはどんなときですか?
乗り継ぎ時間が最低接続時間より短いときです。天候や遅れがなくても一般的な目安を下回っています。たとえばターミナル移動ありで70分なら、必要な90分に20分足りません。
結果に出る余裕の分数とは何ですか?
乗り継ぎ時間から適用される最低接続時間を引いた値です。この余裕が30分に達すると余裕ありになるので、同じターミナルなら90分で十分です。それ未満で最低時間以上なら、ぎりぎりです。
関連ツール
開発者向け — APIアクセス
このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。
エンドポイント
Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。
お使いのスタックから呼び出す
curl -X POST https://api.kit.forhosting.com/travel/layover-time-check \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"layover_minutes":90,"terminal_change":false}'const res = await fetch("https://api.kit.forhosting.com/travel/layover-time-check", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"layover_minutes": 90,
"terminal_change": false
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/travel/layover-time-check",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"layover_minutes": 90,
"terminal_change": false
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/travel/layover-time-check", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"layover_minutes":90,"terminal_change":false}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"layover_minutes":90,"terminal_change":false}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/travel/layover-time-check", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)リクエスト例
{
"layover_minutes": 90,
"terminal_change": false
}レスポンス例
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "travel.layover_time_check",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}非同期APIです。task_idは即時に返ります。ポーリングは1秒あたり1リクエストまでです。
料金
単価はすべて公開しています。トークン換算や独自クレジットはありません。失敗したタスクは課金されません。
エラー
| HTTP | コード | 意味 |
|---|---|---|
401 | unauthorized | APIキーが無効か、指定されていません。Authorizationヘッダーを確認してください。 |
402 | insufficient_balance | 残高が不足しています。チャージ後に再度お試しください。 |
404 | unknown_type | 指定されたタスクタイプは存在しません。タイプ名を確認してください。 |
429 | rate_limited | リクエストが多すぎます。しばらく待ってから再度お試しください。 |
技術的な注記
快適・余裕なし・危険の決め方
同一ターミナルなら60分、terminal_change が true のときはターミナル間シャトル、再保安検査、長い徒歩が時間を増やすため90分です。これらの下限から、分類器は固定の30分の快適バッファを適用します。応答には margin_minutes(乗り継ぎ−MCT)、適用された min_connection_minutes、短い guidance 文も含まれ、クライアントはルールを自ら書き直さずに信号機UIの横に一行説明を表示できます。
入力契約、応答フィールド、エラー動作
負の乗り継ぎは接続時間がゼロ未満になり得ないという明確なメッセージで拒否され、課金されません。true は90分MCT、false は60分を選びます。true/false、1/0、yes/no などの一般的な文字列を受け付け、それ以外は検証に失敗します。例:ターミナル変更なし90分は comfortable(MCT60、快適帯へ30分の余裕)。例:ターミナル変更あり70分は risky(MCT90、20分不足)。ラベルはご自身の旅程UIと組み合わせてください。必須2フィールドのJSON本体をPOSTしてください。layover_minutes は非負の有限数で、到着便到着から出発便出発までの予定間隔(分)です。JSON数値または数値文字列で渡せます。非有限値や空文字列はフィールド名付きの invalid_input で失敗します。terminal_change は停留中にターミナル(または空港)変更が必要かを示す真偽値です。成功時は layover_minutes と terminal_change をエコーし、適用規則の min_connection_minutes、符号付きの余剰/不足である margin_minutes、comfortable/tight/risky のいずれかである status、margin_minutes が0以上と同等の sufficient、英語の読みやすい guidance 文を返します。本エンドポイントは時間長のみを分類し、ライブ便表・手荷物規則・空港地図は照会しません。
乗り継ぎ接続時間チェックが役立つ場面
旅行代理店やオンライン予約エンジンは、買い物客が複数区間の旅程を選んだときにこのチェックを表示し、支払い前に余裕なし/危険な停留を警告します。企業の出張デスクは、ポリシー適合の旅程を組むときに提案接続を一括採点し、快適帯未満を人のレビューへ回します。「常連向けモバイル伴走アプリは好みのバッファを保存しつつ、公開MCT下限に対する一貫した3段階ラベルのためにこのAPIを呼び出します。実装は純粋な parse ティアAのため、成功コールは公開の基準価格 $0.002 のみでモデルトークンも外向き通信もなく、無効入力は残高を消費しません。
連携の活用例
旅行計画のコンテンツとウィジェット
読者がランディングで乗り継ぎ時間とターミナル変更フラグを入力し、快適・余裕なし・危険を即座に確認できます。
技術的な質問
フライトの乗り継ぎ接続時間が足りるかはどう確認しますか?
layover_minutes(非負)と terminal_change(ターミナル変更が必要なら true)を送ってください。APIは60分または90分のMCT目安と30分の快適バッファに基づき status を comfortable / tight / risky で返します。
layover_minutes が負の場合はどうなりますか?
タスクは invalid_input で失敗します。接続時間はゼロ未満にできず、無効入力は課金されません。
乗り継ぎ接続時間チェックの料金は?
ブラウザツールは無料です。APIリクエストはKIT前払い残高を成功コールごとに $0.002 で使用し、無効入力は課金されません。