アプリケーションプログラミングインタフェース








ウィキペディア ウィキペディアなど、MediaWikiに対して使えるAPIについては、MediaWikiの解説ページをご覧ください。


アプリケーションプログラミングインタフェース（API、英: Application Programming Interface）とは、広義の意味ではソフトウェアコンポーネントが互いにやりとりするのに使用するインタフェースの仕様である。


APIには、サブルーチン、データ構造、オブジェクトクラス、変数などの仕様が含まれる。APIには様々な形態があり、POSIXのような国際規格、マイクロソフトのWindows APIのようなベンダーによる文書、プログラミング言語のライブラリ（例えば、C++のStandard Template LibraryやJava API（英語版）など）がある。


商業的に使われる狭義の意味ではOSやミドルウェアやWebサービス等サービスを利用するアプリケーション(Application)を作成する(Programming)ためのインターフェース(Interface)である。[1][2][3][4][5]こちらの意味ではサービスから提供されないStandard Template Libraryなど言語の標準ライブラリーは含まない。


APIはApplication Binary Interface (ABI) とは異なる。APIはソースコードベースだが、ABIはバイナリインタフェースである。例えば、POSIXはAPIだが、Linux Standard Base (LSB) はABIである[6]（LSBはいろいろな規定の集合なので、正確には「LSBには、ABIにまで踏み込んでいる部分もある」）。




目次






  • 1 概要


    • 1.1 ライブラリーとAPI




  • 2 詳細


    • 2.1 ライブラリとフレームワーク


    • 2.2 APIとプロトコル


      • 2.2.1 オブジェクトAPIとプロトコル






  • 3 ウェブAPI


    • 3.1 ウェブによるコンテンツ共有




  • 4 実装


  • 5 公開の方針


  • 6 リバースエンジニアリングと著作権


  • 7 類似する概念


  • 8 APIの例


  • 9 言語束縛とインタフェースジェネレータ


  • 10 脚注


  • 11 関連項目


  • 12 外部リンク





概要


広義のAPIでは単なるライブラリーのインターフェースを含むかどうかにばらつきがあるなど定義が曖昧であるため、ここでは狭義のAPIについて説明する。


前述のとおりAPIはサービスがサービスを利用するアプリケーションに提供するためのインターフェースである。APIの重要な役割はサービス提供者が公式に仕様を定義し管理している操作方法(インターフェース)を提供することである。APIは多くの場合アプリケーションを構築する言語と同じ言語のライブラリーとして(HTTPやXMLなどを組み合わせたプロトコル形式の場合もある)提供され、サービス開発者によって提供・管理される。


アプリケーションがサービスを利用するにはAPIを無視してサービスの現在の実装に依存した方法で利用することもできるが、サービス提供者はアプリケーションがAPI以外の仕様に依存していることは認知しておらずAPI以外の仕様が永続的に維持されることも保証しない。バグ修正などで少しでもサービスに変更があればAPIを利用しないアプリケーションはたちまち動かなくなってしまう。アプリケーションがサービスを操作するにあたりAPIにだけ依存することでこのような永続性の問題を防ぐことができるのである。


なお、APIを備えたサービスとして代表的なOSにWindowsやOSXやiOSがあるが、これらには俗に隠しAPIやプライベートAPIなどと呼ばれるものが存在した。これらはサービス提供者が公式に提供している機能ではなくAPIではない。このためこれらの機能を使ったアプリケーションの将来は保証されることはない。



ライブラリーとAPI


APIは関数、プロシージャ、変数やデータ構造といったライブラリーによって実装されることが多いが、狭義のAPIではライブラリーとAPIは同一ではない。
ライブラリー形式ではなくプロトコル形式で提供される場合もあるという理由もあるが、ライブラリー形式である場合も同一視せず区別する必要があるという理由がある。


例えばAPIが関数であればサービスにより提供される関数はAPI関数と呼ぶが、API関数を利用して構築された関数はAPIではないためライブラリー関数と呼ぶ。
ライブラリー関数は直接サービスと関係ないか、APIを使って構築されておりサービスを利用する上で必須ではない。逆にAPI関数の存在はサービスを利用する上で必須である。例えばCのライブラリー関数であるfwrite[7]はWindows上であればAPI関数であるWriteFile[8]を使って実装されておりOS間の移植性を考えなければfwriteでなくWriteFileで代替できる。


APIはサービスを利用するうえで必須になるが、APIを直接使用することは外部サービスに対する依存性を高め移植性を妨げる。例えばWriteFileを使うプログラムは基本的にWindows用にしかコンパイルできないがfwriteを使うプログラムはフリースタンディング環境以外ならどの環境でもコンパイルできる。このため移植性を考えるのであればAPIの直接使用は避けAPIを抽象化したライブラリーを使用することが望ましい。
さらに、後述するように移植性を意識する言語ではライブラリーとAPIを厳密に区別している場合が多い。特に後述のSmalltalkはクロスプラットフォームが一つの長所となっているためAPIの直接使用を避けることは重要となる。


C++の規格書では、API関数とライブラリー関数は一貫して区別されており、API関数は標準のライブラリー関数から呼び出されるもの、あるいは標準ライブラリーの関数が同等の機能を模倣する対象として書かれている。[9]またCの規格書においてはAPIという言葉は無く相当する関数がライブラリー関数以外の関数として書かれている。[10]1980年代から存在するSmalltalkでもAPIとライブラリーは区別されており例えばSmalltalk環境の一種であるPharoはAPIと対応しているパッケージをライブラリーとは別にAPIとして区分している。[1]


なお、標準ライブラリーはOSやファームウェアなどアプリケーション以外からも使われる。



詳細



ライブラリとフレームワーク


APIはソフトウェアライブラリと対応しているのが一般的である。
APIは「期待される挙動」を規定し説明するが、ライブラリはその規則群の「実際の実装」である。
1つのAPIが複数の実装を持つこともあるし、実装のない抽象的APIもありうる。


広義のAPIはソフトウェアフレームワークと対応する場合もある。フレームワークはいくつかのライブラリを備え、いくつかのAPIを実装することもあるが、通常のAPIとは使い方が異なり、「フレームワークに組み込まれた」挙動への「アクセス」としてフレームワーク自身に新たなクラスをプラグインすることでその内容を拡張するという手段をとる。さらに言えば、呼び出し側はプログラムの動作を制御できず、制御の反転や他の類似の機構によってフレームワーク側が流れを制御する[11]。



APIとプロトコル


APIはプロトコルの実装となっていることもある。


プロトコルは、共通の転送手段に基づいた要求と応答の標準的交換方法を定義している。一方プロトコルを実装していないAPIは、ライブラリとして実装され、直接使われるのが一般的である。したがってAPIには「転送手段」が関与することはなく（遠隔のマシンとの物理的情報転送を行わない）、「関数呼び出し」によって単純に情報交換し、データは特定の言語で表現された形式で交換される[12]。


APIがプロトコルの実装である場合、下層にある通信プロトコルを使ってリモート呼び出しを行うためのプロキシ的手段となっている。その場合のAPIの役目は、プロトコルの詳細を隠蔽することである。例えばJava RMIは、JRMP（英語版）プロトコルまたはRMI-IIOPとしてのIIOPを実装している。


プロトコルは一般に異なるテクノロジー（特定OS内の特定プログラミング言語に基づくシステム）間をつなぎ、それらの間での情報交換を可能にしている。一方APIは特定のテクノロジーに固有であり、何らかの変換手段を用いない限り、ある言語用のAPIを別の言語では使用できない。



オブジェクトAPIとプロトコル


オブジェクトAPIは具体的なオブジェクト交換フォーマットを規定し、オブジェクト交換プロトコルはメッセージ内の同種の情報をリモートシステムに転送する方法を定義する。


2つの異なるプラットフォーム間で、両者にあるオブジェクトを使ってプロトコル経由でメッセージを交換する場合、あるプログラミング言語内のオブジェクトは相手の異なる言語でのオブジェクトに変換される。例えばJavaで書かれたプログラムがC#で書かれたサービスをSOAPやIIOP経由で呼び出す場合、どちらのプログラムもリモート呼び出し用API（API自体はローカルに存在する）を使って情報交換し、ローカルなメモリ内でオブジェクトの変換を行う。


一方、同一マシン上でAPI経由のオブジェクト交換を行う場合、メモリ内で効率的に（オブジェクトまたはオブジェクトへの参照の）交換が行われる。例えば、1つのプロセスに割り当てられたメモリということもあるし、共有メモリを使って複数プロセス間で行うこともあるし、タプルスペースのような共有技法を使うこともある。



ウェブAPI


詳細は「Webサービス」を参照

ウェブ開発においては、APIは一般にHTTP要求メッセージ群とXMLまたはJSON形式などの応答メッセージの構造定義で構成される。「ウェブAPI」はWebサービスと事実上同義だが、Web 2.0と呼ばれる最近の傾向では、SOAPベースからREST風の直接的通信へと変化している[13]。ウェブAPIはマッシュアップと呼ばれる技法で複数のサービスを組み合わせて新たなアプリケーションとすることを可能にする[14]。



ウェブによるコンテンツ共有


APIを公表する慣習により、ウェブコミュニティにはコミュニティ間やアプリケーション間でコンテンツとデータを共有するオープンアーキテクチャが発展していった。そのため、ある場所で作成されたコンテンツはウェブ上の様々な場所で盛んにポストされ更新される。



  1. 写真はFlickrやPhotobucketといったサイトからFacebookやMyspaceといったソーシャルネットワークサイトに共有される。

  2. コンテンツは埋め込むこともできる。例えば、SlideShareにあるプレゼン資料をLinkedInのプロファイル情報に埋め込むことができる。


  3. TwitterのつぶやきをFacebookの投稿にも同時に反映させるAPIもある。

  4. 動画コンテンツも別のホスト上のサイトに埋め込むことができる。

  5. ウェブコミュニティにおけるユーザー情報を外部アプリケーションと共有させることができ、アプリケーションの更新をウェブ側から働きかけるなどの機能もオープンなAPIで実現されている。好例としてFacebookプラットフォーム（英語版）やOpenSocialプラットフォームがある。



実装


POSIX標準は、様々な一般的コンピューティング機能を各種システム上で実装できるよう考慮したAPIを定義している。例えば、macOSやBSD系システムで実装されている。ただし、POSIX準拠のプログラムを別のPOSIX準拠のプラットフォームで実行するには、再コンパイルが必要である。


一方、互換APIの場合、そのAPIを実装したシステムならどこでも同じオブジェクトファイルがそのまま実行可能である。これはソフトウェア業者にもユーザーにも有益であり、業者は互換APIが実装されていれば新システムが登場しても製品を修正せずに済むし、ユーザーも古いソフトウェアを新システムにインストールできる。ただし、それには一般に各種ライブラリが必要なAPI群を実装している必要がある。


マイクロソフトはAPIの後方互換性の維持を心がけており、特にWindows API (Win32) ライブラリは古いアプリケーションが新しいWindows上でも動作できるよう互換モードを備えている[15]。


Unix系OSでは、相互に関連はあるが非互換なOS群が同一ハードウェア上で動作している。ソフトウェア業者が同一バイナリで各種OSに対応できるようAPIとABIを共通化する試みがなされてきたが、いずれも失敗に終わっている。そのような試みとしてLinuxではLinux Standard Baseがある。BSD系OSも各種あるが、互換性のレベルは様々である。



公開の方針


APIの公開に関しては2つの一般的な方針がある。



  1. 自社のAPIを厳重に秘匿する。
    例えばソニーはライセンスをもった開発者にしかプレイステーションの公開APIを利用できないようにしている。なぜならプレイステーションのゲームを開発できる人の数を制限したほうが、より多くの利益をあげられるからである。これはAPIの実装を売ることで利益を上げるわけではない会社の典型的な例である。（ソニーの場合は、ゲーム開発時のAPIのライセンス料によって利益を上げようとしたがうまくいかず、プレイステーション用コンソールの販売を中止している。）


  2. 自社のAPIを広く普及させる。
    例えばマイクロソフトは計画的にAPIに関する情報を公開しているので、誰でも簡単にWindowsプラットフォーム用のソフトウェアを作成することができる。これはAPIの実装を販売して利益をあげる会社の例である。OSなどのAPIは、いくつかのコードに分割され、ライブラリとして実装されており、OSと一緒に配布される。OSと一緒に配布されるWindowsのAPIは誰でも使うことができる。また直接アプリケーションの中に統合される必要があるAPIもある。



この2つの方針の中間もある。



リバースエンジニアリングと著作権


互換性のためのAPIを作成するためにそのAPIの実装を解析することは一般的に合法である。この手法は相互運用性のためのリバースエンジニアリングと呼ばれる。しかしAPIそのものとは異なり、APIの実装には著作権が存在するため、リバースエンジニアリングする前には著作権侵害の問題が生じないよう、十分注意する必要がある。また、使おうとしているAPIに、特許保持者の許可がなければ使えない特許技術が許可なく含まれていたら、それは特許権侵害になりうる。（ただし、これはリバースエンジニアリングに限られた話ではなく、APIを利用するプログラムにも全般的に言えることである。）


2010年、米オラクルはGoogleがJavaの新たな実装をAndroidの一部として配布したとして、Googleを訴えた[16]。GoogleはJava APIを複製する許可をとっていなかったが、類似の許可はOpenJDKプロジェクトに与えられていた。これに対して、地方裁判所はAPIは著作権法の対象外であるとする判断を下したものの、控訴裁では保護対象であるとされ、最終的に2015年、最高裁によりアメリカ合衆国内ではAPIにも著作権があるとの判断が確定した[17][18][19]。ただし著作権があってもフェアユースの下に利用可能かについては、2015年現在継続して審理されている。


日本においては、著作権法第10条第3項において、プログラムのインタフェースやプロトコルが著作物とみなされないことが明確に示されている[20]。



類似する概念




  • DDI - デバイスドライバーを開発するためのソフトウェアインターフェース


  • ファームウェアインターフェース - ファームウェアを開発するためのソフトウェアインターフェース


  • ASPI - SCSI 装置を制御するためのソフトウェアインターフェース


特にDDIやファームウェアインターフェースを使う場合はソフトウェアがアプリケーションと異なる環境で動作しAPIに依存するライブラリを使用できない場合があるため、開発者は自分が何を使っているか意識する必要がある。



APIの例




  • CarbonとCocoa - macOS

  • CORBA


  • Document Object Model (DOM) - HTML文書やXML文書をアプリケーションから利用するためのAPI


  • DirectX - Microsoft Windows

  • EHLLAPI


  • iconv - 文字コード間の相互変換用API（POSIXの一部）

  • I/OKit - Darwin

  • Java API（英語版）


  • ODBC - Microsoft Windows


  • OpenAL - クロスプラットフォームのオーディオAPI


  • OpenCL - CPUやGPUを汎用処理に使用するためのクロスプラットフォームのAPI


  • OpenGL - クロスプラットフォームのグラフィックスAPI


  • OpenMP - クロスプラットフォームの共有メモリ型マルチプロセッシング用API。C、C++、Fortranで利用可能。

  • POSIX

  • QuickTime

  • Single UNIX Specification


  • Simple DirectMedia Layer (SDL)

  • Toolbox - Mac OS


  • Video for Windows - Microsoft Windows


  • Windows API - Microsoft Windows

  • XPCOM


  • EXtelligence API- EDIを組み込めるAPI



言語束縛とインタフェースジェネレータ


複数の高水準言語での使用を意図したAPIは、文法的・意味的に各言語に適したインタフェースをAPIに自動的にマッピングする機能を提供している。これを言語束縛と呼び、それ自体もAPIである。その目的は、そのAPIに要求される機能のほとんどをカプセル化するため、各言語に薄い層を設けることである。


以下に挙げたものは、コンパイル時に言語とAPIの束縛を行うインタフェースジェネレータである。




  • SWIG - オープンソースの多言語間のインタフェースジェネレータ（通常はC/C++からスクリプト言語へのインタフェースを生成）

  • F2PY:[21] - FortranからPythonへのインタフェースジェネレータ



脚注


[ヘルプ]




  1. ^ https://www.ibm.com/support/knowledgecenter/ja/SS4SVW_2.0.0/com.ibm.zosconnect.doc/backmatter/glossary.html#glossary__api


  2. ^ https://developer.mozilla.org/ja/docs/Glossary/API


  3. ^ http://www.ocn.ne.jp/support/words/abc/API.html


  4. ^ https://www.synergy-marketing.co.jp/glossary/api/


  5. ^ Smalltalk環境の提供元Cincomによる見積サービスの説明 APIの解説がある。


  6. ^ Stoughton, Nick (2005年4月). “Update on Standards (PDF)”. USENIX. 2009年6月4日閲覧。


  7. ^ https://www.ibm.com/support/knowledgecenter/ja/SSLTBW_2.2.0/com.ibm.zos.v2r2.cbcpx01/write.htm


  8. ^ https://msdn.microsoft.com/ja-jp/library/cc429856.aspx


  9. ^ C++14の規格書の最終草案


  10. ^ C14の規格書の最終草案


  11. ^ Fowler, Martin. “Inversion Of Control”. 2012年10月18日閲覧。


  12. ^ “API vs Protocol”. 2012年10月18日閲覧。


  13. ^ Benslimane, Djamal; Schahram Dustdar, and Amit Sheth (2008年). “Services Mashups: The New Generation of Web Applications”. IEEE Internet Computing, vol. 12, no. 5. Institute of Electrical and Electronics Engineers. pp. 13–15. 2012年10月18日閲覧。


  14. ^ Niccolai, James (2008-04-23), “So What Is an Enterprise Mashup, Anyway?”, PC World, http://www.pcworld.com/businesscenter/article/145039/so_what_is_an_enterprise_mashup_anyway.html 


  15. ^ Microsoft. “Getting older programs to run on Windows XP”. Microsoft. 2012年10月18日閲覧。


  16. ^ “Oracle and the End of Programming As We Know It”. DrDobbs (2012年5月1日). 2012年5月9日閲覧。


  17. ^ Josh Lowensohn (2012年5月23日). “Jury clears Google of infringing on Oracle's patents”. ZDNet. 2012年5月25日閲覧。


  18. ^ Joe Mullin (2012年5月31日). “Google wins crucial API ruling, Oracle’s case decimated”. Ars Technica. 2012年6月1日閲覧。


  19. ^ “米最高裁がGoogleの訴えを却下、OracleとのJava著作権訴訟で”. ITPro (2015年6月30日). 2015年7月1日閲覧。


  20. ^ 松下正. “知的財産権（特許・商標・著作権）の基礎講座”. 知的財産権（特許・商標・著作権）の基礎講座. 2015年7月1日閲覧。


  21. ^ “F2PY.org”. F2PY.org. 2011年12月18日閲覧。




関連項目





ウィキメディア・コモンズには、アプリケーションプログラミングインタフェースに関連するカテゴリがあります。


  • システムコール

  • 呼出規約

  • Foreign function interface

  • 名前修飾

  • プラグイン

  • ソフトウェア開発キット



外部リンク



  • What is an API? Your Guide to the Internet (R)evolution

  • How to design a good API and why it matters

  • How to Design APIs for Cryptographic Protocols































  • 表

  • 話

  • 編

  • 歴


オペレーティングシステム
概要


  • 歴史

  • 一覧
カーネル











構造


  • モノリシックカーネル

  • マイクロカーネル

  • エクソカーネル（英語版）

  • ハイブリッドカーネル（英語版）
構成

  • アドレス空間

  • マイクロカーネル

  • ローダブル・カーネル・モジュール

  • デバイスドライバ

    		•


    プロセス管理











    概念


    • プロセス

    • プロセス制御ブロック

    • 割り込み

    • スレッド

    • コンテキストスイッチ
    スケジューリング
    アルゴリズム

  • マルチタスク

  • プリエンプション

  • ラウンドロビン

  • 多段フィードバックキュー

  • Shortest job next

    		•



    メモリ管理と
    リソース保護

  • セキュリティリング

  • メモリ保護

  • 仮想記憶

  • ページング方式

  • セグメンテーション違反 / バスエラー

  • 一般保護違反（英語版）

    		•
    実装例

  • AIX

  • AmigaOS

  • BeOS

  • BSD

  • Haiku

  • HP-UX

  • Linux

  • Classic Mac OS

  • macOS

  • MorphOS

  • MS-DOS

  • Multics

  • OS/2

  • OS2200

  • ReactOS

  • Solaris

  • UNIX

  • Windows

  • z/OS

  • IBM i

  • Redox

    		•
    その他

  • ブートローダー

  • Live CD

  • Live USB

  • PXE

  • API

  • 仮想ファイルシステム

  • 仮想テープライブラリ（英語版）

  • コンピュータネットワーク


  • OSシェル（CLI

  • TUI

  • GUI


  • VUI（英語版））

  • HAL

    		•

    ポータルコンピュータ - カテゴリカテゴリ



    -

    Popular posts from this blog

    冬

    Image
    季節による積雪の変化 冬 （ふゆ）は、四季の一つであり、一年の中で最も寒い期間・季節を指す。二十四節気や旧暦のように、一年中で最も太陽の高度が低く夜が長い期間を指すこともある。 北半球では冬至後の1月-2月頃に気温が低いことが多く、南半球では夏至後の7月‐8月頃にあたる。 日本の気象庁では一日の日最低気温が0℃以下の日を 冬日 （ふゆび）、また、日最高気温が0℃以下の日を 真冬日 （まふゆび）と呼んでいる。このような日は1月を中心に前後の毎年12月から翌年3月頃にかけて発生するから（ただし、年や地域によっては、11月・4月でも生じる場合もある）、この時期のあたりが冬の範囲に入る。 冬が特別・特有とされる物（特に収穫物）に付いては旬#冬を参照。 目次 1 定義 2 気候 3 生物 3.1 植物 3.2 動物 4 冬の行事 5 天文・自然 6 比喩的な用法 7 冬を題材にした作品 7.1 文学 7.2 音楽 7.2.1 クラシック 7.2.2 童謡 7.2.3 ポピュラー系 8 関連項目 定義 地球と太陽の光の模式図。この図では北半球が冬となる。 北半球が冬のときは南半球は太陽高度が高くなるため夏となり、南半球が冬のときは同様に北半球は夏となる。 社会通念・気象学では1月・2月・12月。たとえば「暖冬」「厳冬」などはこの3か月の平均気温で判断する。 寒候年・1年間の間で1月、2月、12月とすると1シーズンとしての冬を評価できない。そのため1月、2月を含む年をそのシーズンで括る。たとえば、「2009年の冬」といった場合、2008年の12月、2009年の1月、2月である。また、「2008/2009年冬」という書き方をする。初雪・終雪の日など11月以前、3月以降になることのあるようなものもこの定義による。 二十四節気に基づく節切りでは立冬から立春の前日まで。 旧暦による月切りでは十月・十一月・十二月。上に近いが、最大半月ずれる。 年度では1月・2月・3月。英語ではこの3か月をwinter quarterと呼ぶ。 天文学上は冬至から春分まで。ここでの「冬至」「春...
    Read more

    浄心駅

    Image
    浄心駅 浄心駅5番出口（2010年3月） じょうしん Joshin ◄ T03 庄内通 (1.4km) (0.8km) 浅間町 T05 ► 所在地 名古屋市西区城西四丁目3208 愛知県の地図を表示 名古屋市の地図を表示 北緯35度11分32秒 東経136度53分27秒 駅番号 ○ T04 所属事業者 名古屋市交通局 （名古屋市営地下鉄） 所属路線 鶴舞線 [1] キロ程 4.1km（上小田井起点） 駅構造 地下駅 ホーム 2面2線 乗車人員 -統計年度- 7,116人/日（降車客含まず） -2017年- 開業年月日 1981年（昭和56年）11月27日 [1] テンプレートを表示 浄心駅 （じょうしんえき）は、愛知県名古屋市西区城西4丁目にある、名古屋市営地下鉄鶴舞線の駅である。駅番号は T04 。 運行上の拠点であり乗務員の交代が当駅で行われる他、上り最終電車のみ当駅止まりとなる（翌朝当駅から上小田井駅へ回送し、上小田井駅発の列車となる）。かつては日中にも当駅起終点の列車が1往復設定されていた。 目次 1 歴史 2 駅構造 2.1 のりば 3 駅周辺 4 バス路線 5 隣の駅 6 脚注 7 関連項目 8 外部リンク 歴史 1981年（昭和56年）11月27日 - 当駅 - 伏見間の延伸に際し開業 [1] 。 1984年（昭和59年）9月6日 - 庄内緑地公園 - 当駅間の開業に伴い途中駅となる [1] 。 駅構造 浄心駅ホーム 相対式ホーム2面2線を有する地下駅。1番ホームには東改札口、2番ホームには西改札口がそれぞれあり、両ホームは線路の下を通る連絡通路でつながっている。改札外では東西それぞれのコンコースをつなぐ通路は無く、分断されている。 1番又は2番出入り口から入り階段を降りると1番ホーム（赤池・豊田市方面）にしか行けず、4～6番出入り口から入り階段を降りると2番ホーム（上小田井・犬山方面）にしか行くことができない。 よって、例えば2番ホームで降りて...
    Read more

    カンタス航空

    Image
    カンタス航空 Qantas Airways IATA QF [1] ICAO QFA コールサイン Qantas 法人番号 1700150004605 設立 1920年 ハブ空港 キングスフォード・スミス国際空港 メルボルン空港 焦点空港 香港国際空港 シンガポール・チャンギ国際空港 パース空港 ブリスベン空港 アデレード空港 マイレージサービス Frequent Flyer 会員ラウンジ Qantas Club 航空連合 ワンワールド 保有機材数 213機 (147機発注中) 就航地 144都市 (39カ国) 親会社 Qantas Airways Limited 本拠地 オーストラリア ニューサウスウェールズ州シドニー 代表者 Alan Joyce (CEO) Leigh Clifford (会長) 外部リンク qantas.com テンプレートを表示 カンタス航空本社 (Qantas Building A) カンタス航空 （カンタスこうくう、英語: Qantas Airways Limited ）は、オーストラリアおよび南半球最大手の航空会社。 オーストラリアでのQantasの発音は、 Quantas ( [ˈkwɒntəs] [2] [3] [4] 、 クウォンタス ) のように発音される。 目次 1 概要 2 歴史 2.1 設立 2.2 第二次世界大戦 2.3 第二次世界大戦後 2.4 拡大 2.5 現在 3 就航都市 4 保有機材 4.1 特別塗装機 5 マイレージサービス 6 機内サービス 6.1 広報活動 6.2 新ユニフォーム 7 事故及び故障 8 「オーストラリア・アジア航空」 9 補足 10 関連項目 11 脚注 12 外部リンク 概要 カンタス航空はオーストラリアのナショナルフラッグの航空会社であり、その機材数、国際便と国内便の就航都市数...
    Read more