イベント参加者の送迎 2026：統一ルートプラン

空港、ホテル、会場間の参加者送迎の実践的なスキーム：データ、ウェーブ、手荷物、配車管理、予備。

飛行機は定刻に着陸し、バスも手配済みなのに、それでも一部の参加者がいないまま受付が始まる。一人は別の出口で出迎えを探し、二人目は手荷物を待ち、三人目はプログラム上すぐ会場に向かうべきなのにすでにホテルへ運ばれてしまった。車はあるのに、共通のルートがない。

「Aventura」では、輸送計画をバスの台数から始めません。まずフローマップをまとめます。誰がいつ到着するか、いつ乗車可能になるか、手荷物はどれくらいか、どんな支援が必要か、どこへ引き継ぐか、プログラムの次の地点にいつまでに到着すべきか。

出迎え、輸送、宿泊、プログラムを一つの計画にまとめる必要がある場合は、送迎とコーディネーションの見積もりをリクエストしてください。最初の打ち合わせには、都市、日程、おおよその参加者数、暫定プログラム、到着地点のリストがあれば十分です。

イベント参加者の送迎には何が含まれますか？

私たちにとって、移動は車両の手配より前に始まります。まず到着情報を確認し、参加者をお迎えします。次にグループをまとめ、乗車を管理し、目的地まで車両を運行します。受け入れ側の確認をもって便をクローズし、各区間ごとに責任者、ステータス、代替対応を定めます。

ルートは一連の引き継ぎとして捉えると分かりやすくなります。

フライトまたは列車 -> 出迎え担当 -> 集合地点 -> 交通機関 -> ホテルまたは会場 -> 受け入れコーディネーター

ここでの各矢印は責任の切り替わりを示します。参加者がターミナルにいる間は、到着コーディネーターがステータスを管理します。乗車後は、車両コーディネーターとともに輸送ディスパッチャーが業務を引き継ぎます。目的地では、受け入れ側がグループが所定のエリアに到着し、プログラムを継続できることを確認します。

移動はバスが建物のそばに停まった瞬間に終わるわけではありません。参加者が違う入口で降りてしまったり、審査の列に並んだり、受付カウンターが見つからなかったり、客室の準備前に到着したりする可能性があります。そのため、計画には最終チェックポイントを設けます。例えば「グループを登録責任者に引き渡し済み」または「参加者をホテルコーディネーターが受け入れ、荷物を配置済み」といったものです。

輸送計画は隣接するプロセスと連動しますが、独自の責任者とステータスを持ちます。ホテル手配と宿泊者名簿（rooming list）は宿泊を担当します。参加者登録はゲストプロフィールとイベントへの入場を管理します。送迎チームは必要なデータのみを使用し、確認済みの到着ステータスを返します。

イベントが複数の都市、ホテル、施設にまたがる場合、ロジスティクスは独自の責任者を持つ別個のタスクになります。そのようなプロジェクトでは、MICEとコーポレートツーリズムが移動、宿泊、プログラムを結びつけ、輸送計画は独立した業務の一部として残ります。

輸送ウェーブのマスター・マトリクス

チームはフライト、バス、連絡先、現在の変更を1つの表で共有します。これがマスター・マトリクスです。各行は参加者またはグループに対応し、輸送ウェーブが互換性のある行をまとめます。更新の責任者は1人で、変更を関係者に伝え、タスクが変わる人に知らせます。

以下の表は、私たちの最小限の実務テンプレートです。必須の様式はありません。

マトリクスの基本バージョンは1つです。ドライバー、出迎え担当、ホテル用のコピーはフィールドを減らせますが、降車時刻と目的地は必ず記載します。チャットのメッセージだけではステータスは変わりません。変更は、基本表が更新され、実行者が新しいタスクを受け取り、確認した時点で完了です。

計画と現在のステータスを分けると便利です。計画は「どうあるべきか」に答えます：ウェーブ、車両、ポイント、責任者、予備。現在の部分は、計算到着時刻、乗客の準備状況、搭乗、出発、到着、引き渡しを示します。

輸送チームに不要な情報は共通マトリクスに追加しません。パスポート番号、医療文書の内容、VIPプロトコルの詳細は、ドライバーがフライトを遂行する助けにはなりません。クローズドルートや特別なニーズには、アクセスを制限した別のビューを作成します。

見積もりの前にどのようなデータを集めるべきか？

まず、到着地点、時間枠、最終目的地を含む詳細なフロー図を作成します。手荷物、必要な支援、許容される待ち時間は別途記録します。次に、各ウェーブをプログラムの次の地点と結び付けます。こうすることで、チケット購入や最終スケジュールの確定後に輸送を再編成する必要性が減ります。

空港や駅については、ターミナル、待ち合わせ場所、搭乗までの経路を確認します。バスの駐車場と予備地点も別途確認します。ホテルや会場では、アプローチ、降車場所、利用可能な入口を確認します。受け入れコーディネーターの連絡先はルートの近くに保管します。

次に、乗客に関するデータを収集します。最小限の項目はプロジェクトによって異なりますが、通常は次の順序が必要です：

1. レコードの内部IDとデータ所有者を指定します。
2. 交通手段、便名または列車番号、日付、到着地点を記載します。
3. 予定時刻、計算時刻、実際の到着時刻、迎えの準備状況を分けます。
4. ルートの特定区間の最終地点を記録します。
5. 手荷物の数と種類を集め、機材や大型荷物は別途記載します。
6. 必要な支援を中立的に説明し、余分な医療情報は含めません。
7. 参加者またはそのアシスタントとの許可された連絡チャネルを指定します。
8. 確認ステータスと最終更新時刻を設定します。

到着時刻を自動的に車への搭乗時刻と見なすことはできません。着陸後、参加者は飛行機からの降機を待ったり、入国審査を受けたり、手荷物を受け取ったり、同行サービスを利用したりする場合があります。そのため、ディスパッチャーには別途ステータス迎えの準備完了が必要です。これは参加者と連絡を取った後に迎え担当者が設定します。表の数式ではこれを判断できません。

手荷物はグループの実際のプロファイルに基づいて集めます。「スーツケースを持っている」という1行では不十分です。参加者の中にトランク、展示資料、楽器、製品サンプル、移動補助具がある場合です。プロジェクトチームは航空規則を設定しません。バッテリー、機内持ち込み手荷物、大型荷物に関する制限は、参加者が運送業者に確認します。

どのデータが確認済みで、どれがまだリクエストであるかを別途定義します。必要な車両、早期チェックイン、空港の支援、専用入口、車椅子のスペースなどは、責任者の回答があるまで確定サービスとして扱うべきではありません。マトリックスでは「リクエスト済み」「確認済み」「代替案付きで拒否」のステータスが有用です。

最終申請書に署名する前に輸送スキームを確認する必要がある場合は、ウェーブの下書きリストをお送りください。到着、手荷物、降車地点、プログラムを照合し、議論の余地のある仮定は別リストとして提示します。

普遍的な基準なしで車両とウェーブをどう計算するか

基準とするのはピーク需要と、確認済みの各車両の実際の定員です。各ウェーブごとに、空いている乗客席、荷物の構成、チャイルドシート設置および添乗員配置後の座席数を確認します。実用定員はこれらのうち最小の値となります。車検証上の座席数だけでは計算には適しません。

まず、乗客を互換性のあるルートごとにグループ化します。航空機の搭乗時刻が近いだけでは、同じウェーブとは言えません。国際線と国内線の到着では、出口までの時間が異なる場合があります。参加者が異なるホテルに向かうこともあります。

登壇者はすぐに会場へ向かう必要があり、メイングループはまずチェックインに向かうことがあります。大型荷物や搭乗支援もサイクルを変えます。

各ウェーブごとに確認します：

1. 空港、駅、ターミナルが一致するか。
2. 搭乗準備完了の想定時刻がどの程度近いか。
3. 最終目的地が同じか。
4. 荷物のプロファイルが互換性があるか。
5. 車両が空き状況の面で適しているか。
6. グループがプログラムの次の地点に間に合うか。
7. このカテゴリーの参加者に対してどのような待ち時間が合意されているか。
8. 出発に間に合わなかった乗客はどこへ移動するか。

車両の完全なサイクルはナビゲーター上のルートより長くなります。計算には配車、敷地内への入構許可、乗車が含まれます。移動後は、降車、グループの引き継ぎ、次の地点への戻りの時間を確保します。車両が複数回往復する場合、次の出発は前のサイクルの完了に依存します。

実用定員は次のように表せます：

実用定員 = 最小値(乗客席、荷物の構成、チャイルドシート設置および添乗員配置後の座席数)

コーディネーターと添乗員の座席はあらかじめ差し引きます。荷物容量は、記載されたプロファイルに基づいてサプライヤーが確認します。バスの写真は計算には適しません。車椅子の固定のために乗客席数が変わる場合、計算は実際の運行構成に基づいて行います。

運行モデルは流れの構造に合わせて選択します：

例外は、他の参加者を待たせる代償を払ってメインの流れに組み込まない方がよいでしょう。

普遍的な予備率はありません。それは遅延のコスト、代替の可用性、ルートの長さ、プログラムの密度、独立した流れの数に依存します。あるプロジェクトでは予備の車両が有効です。

別のプロジェクトでは、代替に関する合意と連絡可能な専任ドライバーで十分です。決定はイベント前に文書化し、実施業者に確認します。

私たちはロジスティクスと送迎をイベントの全体的な制作計画に含めています。これにより車両計算が受付、宿泊、会場のタイミング、帰りの出発と整合します。

空港と駅での出迎え

参加者には事前に短い案内を送付し、コーディネーターには基本シナリオと予備シナリオを渡します。到着日の前に、待ち合わせ場所とコーディネーターの識別方法を確認します。その後、連絡チャネルとフライトのステータスを確認します。搭乗までのルートと、参加者が指定時刻に現れなかった場合の対応を別途記録します。

参加者への案内には、次のステップを実行するのに役立つ情報のみを記載します。どこで待ち合わせるか、コーディネーターや看板の外見、出発時にどの連絡先に知らせるか、出口が変わった場合にどこへ向かうか、モバイルインターネットがない場合にどうするか。長すぎるメールは移動中に埋もれてしまうため、実務的な部分は短いメッセージに収める必要があります。

出迎え担当者はステータスを確認します：

1. expected - 公式ステータスは変わらず、コーディネーターは出迎えの準備中；
2. arrived - 飛行機または列車が到着したが、乗客はまだ準備できていない；
3. under control - 参加者が現在の段階を報告した；
4. collecting baggage - 出迎え担当者が待機理由を把握している；
5. ready for pickup - 参加者が待ち合わせ場所へ向かっている；
6. met - 接触が確認された；
7. boarding - グループが車両コーディネーターに引き継がれた；
8. participant not found - 合意された確認手順が開始された；
9. reassigned - 参加者が新しい便または個別ルートを割り当てられた。

基本と予備の待ち合わせ場所は、慣れたターミナルでも必要です。出口が変わったり、一部のエリアが閉鎖されたり、大人数のグループが人気の場所に集まるのが難しいことがあります。コーディネーターは、いつ人々をポイントBへ移動させるか、そしてそれをディスパッチャーにどう伝えるかを事前に把握しています。

参加者が連絡を取らない場合、出迎え担当者はまずフライトまたは列車の公式ステータスとメッセージログを確認します。次に、許可されたチャネルで電話またはメッセージを送ります。合意された待機時間の後、ディスパッチャーが割り当てを維持するか、乗客を別の便に移すか、ステータス「participant not found」をクローズするかを決定します。ここでドライバーが独自に判断すると、バージョンの不一致が生じます。

遅延した手荷物は、乗客の流れから分離するのが望ましいです。参加者は、受取エリアを出る前に手荷物捜索サービスで未受領手荷物の届出を行い、運送業者の指示に従います。プログラムや本人の状態により別段の必要がない限り、主要グループはルートを続行します。コーディネーターは、誰が手続きに同行し、誰がその後ステータスを更新するかを記録します。

ホテルや会場でグループをどのように引き継ぐのか？

私たちは、ホテルまたは会場のコーディネーターからの確認を得た後にのみ、便の対応を完了とします。コーディネーターは到着便を出迎え、乗客と手荷物の情報を受け取り、次のルートを案内し、完了をディスパッチャーに報告します。入口、客室、または受付の準備が整っていない場合、チームは事前に合意したシナリオを使用します。

ホテルでは、事前にアプローチと降車場所を確認します。その後、スーツケースを持ってフロントまたはクロークまでの経路を実際に歩きます。早朝の便については、個別のシナリオと担当者の連絡先を合意します。

予約が完了しているからといって、標準チェックイン時間より早く客室が準備できているわけではありません。グループは荷物を預け、チェックインを済ませ、食事に向かうか、そのまま会場へ向かうことができます。

会場では、アプローチ、駐車場、降車可能な時間、利用可能な入口、受付までの距離が重要です。イベント会場のカタログは選定の出発点として役立ちますが、交通動線は実際の施設ごとに確認する必要があります。美しいホールがあっても、バスがどこに停まり、スーツケースを持った参加者がどのように中に入るかという問いには答えられません。

受け入れ側のコーディネーターは、予想人数、便のID、予定時刻、遅延、特別な対応を受け取ります。マスターマニフェスト全体は必要ありません。到着後、コーディネーターは実際の人数、例外、グループが次へ進む準備ができているかを確認します。バスに残った人、独自に移動した人、別のエリアに案内された人がいれば、それはステータスに反映されます。

複数の施設で行われるイベントでも同じ論理が適用されます。2つの会場でフォーラムを開催する記事では、会場間の移動の完全なサイクルを詳しく解説しています。私たちは、空港送迎を、参加者が次のチームに引き継がれ、プログラムを続けられる状態になった時点で完了とみなします。

ディスパッチ、ステータス、意思決定ログ

すべての運用上の変更を1つのディスパッチに集約し、チームが共通のイベントバージョンで動けるようにします。ここでは、公式な到着ステータス、乗客の準備状況、車両、コーディネーター、受け入れ地点、および逸脱がプログラムに与える影響が確認できます。ドライバーと出迎え担当が事実を伝え、輸送ロジスティクス責任者がシナリオを選択し、次の確認を指示します。

役割は複数の人物に割り当てることも、小規模なチームで統合することもできますが、機能は維持する必要があります：

• 輸送ロジスティクス責任者は計画を掌握し、意思決定を行う；
• マニフェストオペレーターはメインテーブルを更新する；
• 到着コーディネーターは乗客との連絡を担当する；
• 車両ディスパッチャーは配車と代替を管理する；
• 搭乗コーディネーターは人員と手荷物を照合する；
• 受け入れ側は準備状況と引き渡しを確認する；
• 非標準ルートコーディネーターは例外を処理する。

運用ステータスは短いスキームで構築します：

事実 -> 影響 -> 決定 -> 実行者 -> 次の確認

例えば、ディスパッチャーにとって「便が遅延している」というメッセージは役に立ちません。必要な記録は：「到着予定が変更された；ウェーブAが影響を受けた；メイン車両は乗客2名を残して出発する；乗客はウェーブBに再割り当てされた；コーディネーターが実際の到着後に連絡を確認する」です。ここには架空の分数はありませんが、アクションがあります。

ログには、時刻とメッセージのソース、以前と新しいステータス、採択された決定と責任者を残します。その横に次の確認時刻を記載します。これにより、新しいシフトが結果と再割り当ての理由を確認できます。

通信チャネルはタスクごとに分けます。一般的な運用チャネルには、ウェーブのステータスと決定が残ります。ドライバーは配車、ルート、ディスパッチャーの連絡先、照合用の最小リストを受け取ります。

VIPおよびアクセシビリティに関するデータはクローズドチャネルに送られます。参加者には、待ち合わせ場所、ウェーブの変更、到着に関する短いメッセージを準備します。

通信のバックアップも必要です。これには、最小マニフェストのオフラインコピー、事前に保存された電話番号、現場での無線通信、またはコーディネーターを通じた報告ルールが含まれます。バックアップは実際にテストします。インターネットなしで誰も開かなかったファイルは、有効な代替シナリオとは見なされません。

遅延、不参加、手荷物の紛失が発生した場合の対応は？

逸脱が生じた場合、私たちは主要な流れとプログラムを守り、例外はあらかじめ定められたシナリオに沿って処理します。判断は、確認済みのステータス、利用可能なウェーブ、次の地点への最終時刻に基づきます。各アクションには担当者、参加者への連絡、再確認の時刻が定められます。ディスパッチャーは受け入れ側への影響を別途記録します。

意思決定マトリクスはイベント前に作成します：

1. 予定時刻が変更されたが、プログラムは維持される。 時刻を更新し、車両の割り当てを確認し、受け入れ側に連絡します。
2. 乗客が自分のウェーブに間に合わない。 その乗客を次に互換性のあるウェーブに再割り当てし、新しい指示を確認します。
3. 便が主要な流れから分離した。 メインバスは出発し、遅延した人には予備ルートが割り当てられます。
4. 手荷物が引き渡されない。 参加者は公式サービスを通じて捜索を申請し、ディスパッチャーは付き添いとその後の移動の問題を解決します。
5. 車両が手配されない、または故障している。 ディスパッチャーは確認済みの代替車両を起動し、コーディネーターはグループを安全な地点に留めます。
6. 目的地の準備ができていない。 輸送ロジスティクス責任者の判断で出発を遅らせるか、グループを合意された中間地点へ移動させます。
7. 参加者が見つからない。 公式ステータスを確認し、許可されたチャネルで連絡を取り、合意された不参加ルールを適用し、決定を記録します。
8. プログラムの次の地点に到達できない。 参加者は後からの入場、直接会場へ、または別の合意されたルートへ案内されます。

「参加者が見つからない」というステータスを、イベントへの参加辞退と混同してはなりません。本人が自力で来場した、別の車両に移った、コーディネーターにチェックインしなかった、連絡が取れなくなった可能性があります。バスの空席はまだ不参加を確定するものではありません。まずチームが参加者のステータスを確認します。輸送不参加の普遍的な割合も、他のイベントから転用されるものではありません。

便の遅延時には、運送会社が連邦航空規則および適用される運送会社と空港の手順に従ってサービスを提供します。輸送チームは別の課題、すなわちイベントのルートを維持することを解決します。私たちは航空会社のサービスを約束するものではなく、公式の情報チャネルを代替するものでもありません。マニフェストには確認済みのステータスと私たちのチームのアクションを記録します。

予備プランは6つの問いに答える必要があります：

1. どの検証可能な事実がシナリオを起動するか？
2. 誰が決定を下すか？
3. 追加の合意なしに実行される最初のアクションは何か？
4. 誰に通知する必要があるか？
5. どの車両、地点、ウェーブを使用するか？
6. チームがいつ状況を再確認するか？

「別のバスを見つけます」という言葉では、これらの問いのどれも解決しません。確認済みの予備プランは地味かもしれませんが、実際の契約、連絡先、スケジュールの中に存在します。

アクセシビリティ、VIP、特殊手荷物

こうした移動については、全体の輸送計画の中で個別のルートを組み立てます。私たちは対応に必要な情報だけを収集し、空港、駅、輸送業者に対して事前にサービスを確認し、受け渡し地点を検証し、機微な情報へのアクセスを制限します。特別なシナリオの理由はチーム全体には開示しません。

データ収集の前に、依頼者は管理者、目的、必要最小限の情報、法的根拠、保存・廃棄の期限、アクセス範囲、委託先への受け渡し手順を定めます。回答が健康状態やその他の特別カテゴリーの個人データを明らかにする場合、処理の形式と根拠を個人データ責任者または弁護士が事前に確認します。必要に応じて別途書面による同意を取得します。目的達成後、法令や契約上さらなる保存が不要であれば、作業用マニフェストは削除します。

移動が困難な参加者については、経路全体を確認します：

• 支援要請の地点と出迎え者への引き継ぎ；
• ターミナルと車両の間の経路；
• 乗車と移動支援機器の固定；
• 付き添い者の位置；
• ホテルと会場のバリアフリー入口；
• 次のコーディネーターへの引き継ぎ。

バスのリフトがあっても、車両が必要な地点に横付けできなかったり、その先に代替のない階段があれば、課題は解決しません。

作業プロセスは次のとおりです：

1. 処理の目的と法的根拠を定める；必要に応じて、支援の手配に必要な情報について別途同意を取得する。
2. 航空会社、空港、駅に対してサービスを確認する。
3. 受け渡し地点と責任者を記録する。
4. 輸送に影響する場合、移動支援機器のパラメータを取得する。
5. 車両の実際の仕様を確認する。
6. 実務担当者にはその担当区間のデータのみを渡す。
7. 次の地点での引き継ぎ完了を確認する。

私たちは、必要性と別途の法的根拠がない限り、診断名を共通マニフェストに含めません。運用チームには中立的な表現が必要です：乗車時の支援が必要、低床の車両が必要、乗客は車いすで移動、付き添い者と同乗、引き継ぎに追加の時間が必要。詳細へのアクセスは、サービスの手配に必要な人だけが得ます。

VIPシナリオは、閉鎖的なアクセスとルートの継続性を中心に組み立てます。専用の連絡先、車両、出迎え者、受け渡し地点を含めることができます。こうしたステータスは、交通規則に違反したり、未確認のアクセスを利用したりする権利を与えるものではありません。ルートはターミナル、ホテル、会場、警備部門の管理者と合意します。

特殊な手荷物は個別のプロファイルで扱います。まず寸法と重量を収集し、次に積み込み方法と車両の制約を確認します。トランク、サンプル、楽器、展示資材、大型機材は、座席が埋まる前に荷室を占めることがあります。危険物やバッテリーに関する規則は、参加者が運送事業者に確認します。

積み込みと積み下ろしの際には、個数の確認責任者を任命します。その責任者は数量を照合し、個人の手荷物とグループ機材を分け、積み下ろし後に荷室が空であることを確認します。この簡単な手順により、ケースやスーツケースが次の便へ向けて既に出発した車内に残るリスクを減らします。

通しリハーサルと見積もり用ブリーフ

リハーサルでは、チームは集合地点から受け入れコーディネーターへの引き渡しまで、参加者と同じ経路をたどります。実際の集合地点、搭乗までの経路、人数確認、手荷物の積み込み、ホテルや会場への乗り付け、便の終了までを確認します。リハーサル後には、一つの確定版スキームと、担当者を明記した修正リストが残ります。

確認は、本番と同じ構成で行います。バスがターミナルに横付けできない場合は、グループ到着前にそれを明らかにします。降車地点から入口までの所要時間がナビの表示より長い場合は、その補正をスケジュールに反映します。会場に複数のゲートがある場合は、ドライバーとコーディネーターに同じ名称と配置図を渡します。

リハーサルの最小シナリオ：

1. 主要および予備の集合地点を見つける。
2. 連絡手段とコーディネーターの識別方法を確認する。
3. 通常の手荷物と特殊な手荷物の両方でグループの経路をたどる。
4. 待機場所と搭乗場所を確認する。
5. 指定クラスの車両の乗り付けとマニューバを確認する。
6. 降車地点と入口までの利用可能なルートをたどる。
7. テストグループを受け入れ側に引き渡す。
8. 遅延便、連絡不通、最新の記録がない乗客をシミュレーションする。
9. プログラム後の帰りの出発と集合地点を確認する。
10. 結果に基づいてマスターマトリクスを更新する。

見積もりと最初のブリーフには、完璧な航空券リストは必要ありません。次の初期フレームを渡すだけで十分です：

• 都市と日程；
• 空港、駅、ホテル、会場；
• 暫定プログラム；
• 到着・出発の想定ウェーブ；
• グループ構成と参加者の役割；
• 想定される手荷物と機材；
• アクセシビリティのニーズ；
• 余分な個人情報を含まないVIPカテゴリー；
• 施設の制約；
• 希望する配車管理とレポートの形式。

航空券を受け取った後、マトリクスを精緻化します。そこには更新期限と、発注者側および主催者側の担当者を明記する必要があります。データが複数の部署を経由して変更される場合は、新しい移動を確定し、車両をキャンセルし、または目的地を変更する権限が誰にあるかを事前に定めます。

最終版をリリースする前に、最終確認を行います：

• 各ウェーブに担当者と受け入れ側がいる；
• 到着時刻と搭乗準備完了が区別されている；
• 有効定員が人数、手荷物、アクセシビリティに基づいて確認されている；
• 主要な流れと例外が分離されている；
• ポイントAとBが確認されている；
• 予備には起動の条件が設定されている；
• 帰りの出発がイベント開始前に確定している；
• 実務担当者には必要なデータのみが渡されている；
• 変更がメインテーブルに反映される；
• プログラムがグループの実際の到着を把握している。

輸送はイベント全体の計画の一部でなければなりません。私たち「Aventura」は、輸送を受付、宿泊、会場、タイミングと連動させます。そうすることで、配車担当者は参加者がプログラムを続ける準備状況を管理し、車両をその課題のリソースとして活用します。

お出迎え、シャトル、手荷物、宿泊、帰りの送り出しを一つの計画にまとめる必要がある場合は、プロジェクトについてご相談のうえ、お見積もりをご依頼ください。まずフロー図から始め、まだ確認が必要なデータは別途明記します。

出典

• ロシア運輸省令第161号：旅客および手荷物の輸送規則
• ロシア運輸省令第368号：空港および航空機のアクセシビリティ
• 連邦法第152-FZ「個人データについて」第5条、第9条、第10条および第18.1条
• 連邦航空規則：旅客および手荷物の輸送に関する一般規則
• Domodedovo：移動制限のある旅客向け
• Pulkovo：特別なニーズのある旅客向け
• 鉄道駅管理局：旅客向けサービス
• IATA：Passenger Baggage Rules
• ACI World：Accessibility