stanford-oval/wikipedia huggingface dataset:
コア・ファイター
機動戦士ガンダム > 設定解説 > プロトタイプ・コア・ファイター

| プロトタイプ・コア・ファイター |
| --- | --- |
型式番号: FF-X5
所属: 地球連邦軍
全長: 8.6m
本体重量: 8.15t
武装: なし
メカニックデザイン企画『MSV-R』で設定された。
MSの共通コックピット・モジュールとして、本機以前にそれぞれ個別に試作されたコア・ブロックとコア・ファイターをもとに開発されている。のちのFF-X7と比較して主翼の翼面形状が異なり、また武装は装備されていない。塗装は白を基調に赤と黒が配されている。
試作機2機による各種テストの結果、MSからの射出の際のエンジンの出力不足と、変形時の機体制御などの問題が判明、エンジンは変更されるが航続距離は短くなっている。その後南米の砂漠地帯で第1回空中換装テストを実施、計19回のテストを経て精度が高められ、空中換装は練度の高いパイロットの使用時のみという制限付きで制式な運用法として採用される。
1号機はプロトタイプガンダムのコア・ブロックとして試験運用されるが、間もなく完成したFF-X7に換装される。1号機ものちにFF-X7に改修され、テストベッドとして運用されている。
機動戦士ガンダム > 『機動戦士ガンダム THE ORIGIN』におけるコア・ファイター

漫画『機動戦士ガンダム THE ORIGIN』では、当初コア・ブロック・システムは存在せず、コア・ファイターはRXタイプMSとは別個の艦載機として登場する。爆雷も装備可能。地球編では戦闘機として活躍。原作と同様にリュウ・ホセイの戦死場面に関わる。大西洋ではスレッガー・ロウ中尉が、水中での機動性に長けるゾックをミサイルで撃沈している。ウォン伍長は、ズビッチのズゴックの右腕をミサイルで破壊したが、ボラスキニフ曹長のゾックのメガ粒子砲によって撃墜された。
また物語の最終局面でのアムロの脱出劇に不可欠だという演出上の必要から、ジャブロー到着時にコア・ポッドという脱出用小型機がガンダムに組み込まれることとなった。
一年戦争以降のコア・ファイター > 宇宙世紀0080年代前半

デラーズ紛争時、ガンダム開発計画によってガンダム試作0号機・試作1号機・試作3号機が採用している。従来の「バーティカル・イン・ザ・ボディ方式」に代わって「ホリゾンタル・イン・ザ・ボディ方式」を採用し、コア・ファイタ－は、コクピットブロックやジェネレーターとしてだけでなく、エアインテークシステムやスラスターユニットや武装も、MS形態で使用可能になった。
ガンダム試作0号機では、脱出時のコア・ファイターの推力および火力増強のため、コア・ファイターに装着してコア・ブースターとして運用するためのブースターや装備をMSのシステムに直接組み込んでいる。
ガンダム試作1号機ではコア・ファイターIIを採用。旧ハービック社の技術が導入され、空中換装は想定していない。ガンダム試作3号機のコア・ファイターII-Spは試作1号機用のものを凌駕する性能を誇っていたが、機体の膨大な火器管制を行うためこれとは別に全天周囲モニター・リニアシートを導入したコクピットが採用されている。
一年戦争以降のコア・ファイター > 宇宙世紀0080年代後半

グリプス戦役時、ガンダム［ケストレル］が採用。Gディフェンサーの脱出艇も資料によってはコア・ファイターと呼称される。また、ガンダムTR-1［ヘイズル・アウスラ］にはコア・ブロック・システムを踏襲した脱出ポッドである「プリムローズ」が採用されている。
第一次ネオ・ジオン抗争時、ΖΖガンダムとSガンダムが採用。ΖΖガンダムのコア・ファイターは、従来式の脱出ポッドでは回収が遅れる事からRX-78のコア・ファイターに着目し、採用された。
SガンダムではGコアの呼称で採用された。同機はA・Bパーツにもそれぞれコクピットが装備されており、独立稼動が可能であるが、合体時には両コクピット部がGコアに接続され、緊急時には接続状態のままA・Bパーツを分離、そのまま大気圏再突入や大気圏内飛行も可能となっている。
→詳細は「Sガンダム § 分離・合体」を参照
一年戦争以降のコア・ファイター > 宇宙世紀0090年代

ナラティブガンダムがコア・ファイターを備えており、構造が剥き出しになった状態で腹部に格納されている。ナラティブガンダムは設定上、νガンダム（宇宙世紀0093年ロールアウト）以前に開発されたサイコフレーム試験機とされている。映画『機動戦士ガンダムNT』の劇中では、終盤にナラティブガンダムが撃破される場面でコア・ファイターが脱出に用いられ、パイロットのヨナ・バシュタがユニコーンガンダム3号機フェネクスに乗り移る場面がある。映画のノベライズ版である『小説 機動戦士ガンダムNT』では、一年戦争前に死去したヨナの父親がハービック社（RX-78系ガンダム用のコア・ファイターの開発元）の研究員であったという設定に言及されている。
なお『ガンダムNT』の原案となった中編小説『機動戦士ガンダムUC 不死鳥狩り』では、ヨナの乗機はスタークジェガンとなっており、映画と同じ展開の場面では機体の圧壊により脱出ポッドが作動せず、ヨナが脱出を諦めかける展開となっていた。
一年戦争以降のコア・ファイター > 宇宙世紀0120年代

ネオガンダムがパイロットの生還性とデータ回収を兼ねてバックパックとしても機能するコア・ファイターを採用している。またクラスターガンダムは稼働キー兼ねたコア・ファイターと、その後部にバックパックを装着したコア・ブースターを採用。
一年戦争以降のコア・ファイター > 宇宙世紀0130年代

クロスボーン・ガンダムには、クラスター・ガンダムのものを参考にしつつも大推力を誇るコア・ファイターが採用されている。量産機フリントにも採用されている。
一年戦争以降のコア・ファイター > 宇宙世紀0150年代

ザンスカール戦争時、VガンダムやV2ガンダムに採用されている。従来のコアブロックがMSに内包される形式と異なり、コア・ファイター自体が頭部と胴体を形成し、腕・脚パーツが結合する形式となっている。
→詳細は「ヴィクトリーガンダム § 分離・合体」、および「ヴィクトリーガンダム § 分離・合体 (V2)」を参照
宇宙世紀以外の作品 > 機動武闘伝Gガンダム

『機動武闘伝Gガンダム』には、コア・ファイターに類似した装備としてコア・ランダーと呼ばれる小型浮上式車両（エアカー）が、一部のモビルファイターの装備として登場している。用途は緊急脱出やガンダムファイターの移動用。
宇宙世紀以外の作品 > ∀ガンダム

∀ガンダムでは腰部のフロントアーマーが緊急脱出用のコア・ファイターとなる。
宇宙世紀以外の作品 > 機動戦士ガンダムSEED DESTINY

『機動戦士ガンダムSEED DESTINY』には、インパルスガンダムの装備としてコアスプレンダーという小型戦闘機が登場する。
→詳細は「インパルスガンダム § コアスプレンダー」を参照
宇宙世紀以外の作品 > 機動戦士ガンダム00

『機動戦士ガンダム00』では、機体数は少ないもののいくつもの陣営でコア・ファイターが採用されている。また、そのどれもが太陽炉搭載機であり、ソレスタルビーイング（以下CB）の技術・データを利用している点が共通の特徴である。
設定上は外伝作品『00P』に登場する第2世代ガンダム「ガンダムプルトーネ」で実装され、GNドライヴとパイロットの回収を目的として導入された。また、アルケーガンダムにもイノベイター専用機と同様の設計思想を持つコア・ファイターが導入されている。
『00V戦記』にて「ジンクスIV」への配備が進んでいる。ELS戦を生き残ったジンクスIV全機に配備され、次世代機の「ジンクスV」では標準装備が予定される。ジンクス系統のコックピットは腰部にあるため、コア・ファイターは腰部の一部とスカートアーマーとなるよう設計されている。
宇宙世紀以外の作品 > 機動戦士ガンダムAGE

『機動戦士ガンダムAGE』では、「第3部・キオ編」にて登場するガンダムAGE-3、および「第4部・三世代編」にて登場するガンダムAGE-FXに装備されている。
AGE-3ではコクピット脱出ポッドと戦闘機を兼ねた「コアファイター」が採用され、AGE-3の各ウェアにはコクピットが用意された有人機として運用され、ドッキング後はコアファイターとウェアのそれぞれのコクピットが接続されて複座型のコクピットを形成する。また、AGE-3を改修したガンダムAGE-FXにもXラウンダーの生存性を高めるため、コアファイターが採用されている。
また、ヴェイガン製のMSであるガンダムレギルスもガンダムAGE-3を参考に開発されており、「レギルスコア」と呼ばれるコアファイターを形成可能としている。
宇宙世紀以外の作品 > ガンダム Gのレコンギスタ

『ガンダム Gのレコンギスタ』では、G-セルフにコア・ファイターが搭載されている。あくまで緊急脱出システムのため、武装は機首内蔵の炸薬系バルカンのみ。高い運動性を持ち戦闘力もあるが、武装のバルカンはMS戦には心許ない。合体はバックパックのない状態のG-セルフの背中から合体する。
宇宙世紀以外の作品 > ガンダムビルドファイターズ

『ガンダムビルドファイターズ』および『ガンダムビルドファイターズトライ』では、分離した機体もサブマシンとして使用可能なため、状況によっては本体が破壊されてもコアファイターやバックパックブースター等を使用し戦闘を継続することが可能となっている。
『ガンダムビルドファイターズ』に登場する、ビルドストライクガンダム フルパッケージは支援戦闘機となるビルドブースターが分離可能で、改良型となるスタービルドストライクガンダムはプラフスキーパワーゲートを発生させることができるユニバーサルブースターが分離可能。ビルドガンダムMk-IIのバックパックは、ビルドブースターMk-IIに分離可能で、更にブースターのコクピット部はコクピットブロックに分離する。
『ガンダムビルドファイターズトライ』に登場するウイニングガンダムおよびスターウイニングガンダムは、ボディの各種が支援武器となり、頭部が変形しコアファイターとして単独行動が可能となっている。
Windows Display Driver Model

Windows Display Driver Model（ウィンドウズ・ディスプレイ・ドライバ・モデル、WDDM）とは、GPU用デバイスドライバ（グラフィックスドライバ）の枠組みである。
2006年にリリースされたWindows Vistaで最初に導入され、Direct3D 9ExやDirect3D 10以降のDirect3Dは、WDDMに対応するよう設計されている。
概要

DirectX 9（Direct3D 9）までのバージョンにおいては、DirectXランタイムおよびデバイスドライバ層の設計がシングルタスク前提となっており、同時に複数の3Dアプリケーションを安全かつ安定的に動作させることが困難になってきた。そのため、Windows Vistaのリリースに伴い大幅に設計を変更し、マルチスレッドに対応させ安定度も向上させるべく設計された新しいドライバモデルがWDDMである。WDDMおよび後述のDWMにより、Windows AeroではOSのデスクトップの描画自体にビデオカードやオンボードグラフィックスなどのGPUを活用したハードウェアアクセラレーションを使用することができ、結果としてCPUの負荷を軽減することができるようになる。
並列処理性能の高いGPUに汎用計算を高速実行させるGPGPUという取り組みがあり、プログラマブルシェーダーが登場した頃から試みられてきたが、長時間かかるタスクをGPUに実行させるとシステム全体を巻き込んで不安定化したりクラッシュしてしまったりする問題があった。CUDA（2007年登場）、OpenCL（2008年登場）、DirectCompute（2009年登場）のようなGPGPU対応APIは、ドライバーがWDDMに対応することで、汎用計算のタスクによってGPUに過負荷がかかったとき、強制的にデバイスをリセット・再初期化してシステム全体の安定性を保つことができるようになる。
.NET Framework 3.0以降に含まれるWindows Presentation Foundation (WPF) はDirect3D 9ベースのハードウェアアクセラレーションに対応しているが、Vista以降ではWDDM対応のDirect3D 9Exが使われる。
バージョン > XDDM/XPDM

WDDM発表後、従来のグラフィックスドライバの枠組みをWindows 2000 Display Driver Model (XDDM) あるいはWindows XP Display Driver Model (XPDM) と呼んで区別するようになった。
Windows Vista以降のOSでも引き続きXDDM/XPDMドライバを使用することは可能であるが、その場合、Desktop Window Manager (DWM)、ひいてはWindows Aeroテーマが使用できない。DWMがDirect3D 9Exを使用するためである。
XDDM/XPDMのドライバは、Windows 8以降のOSではサポートされなくなり使用できなくなった。DWMが常に有効になりWDDM 1.0以上が必須要件となったためである。
バージョン > WDDM 1.0

Windows Vistaでサポートされた最初のWDDMである。
Windows 7以降のOSでも、引き続きWDDM 1.0のドライバを使用することは可能である。ただしその場合、WDDM 1.1以降で追加された機能は利用できない。
WDDM 1.0のドライバは、Windows 11以降のOSではサポートされない。WDDM 2.0以上が必須要件となった。
バージョン > WDDM 1.1

Windows 7では、新バージョンのWDDM 1.1がサポートされた。
BitBltやClearTypeフォント描画などGDI描画への支援の追加
ビデオオーバーレイへの対応
OpenGL ICDのための強化
異なるベンダーのGPUの同時利用に対応
テストおよびソースコード管理の複雑さを低減するため、WDDM 1.1ドライバーインターフェイスにはWindows Vistaとの後方互換性があり、（SP2およびプラットフォーム更新プログラムを適用する前の）WDDM 1.0しかサポートしていないWindows Vistaで使用することも可能である。またその場合、単純にWDDM 1.0ドライバーとして動作する。
2009年10月、Windows Vistaに対して「Windows Vista 用のプラットフォーム更新プログラム（KB971644）」が配信された。このアップデートによりWindows VistaでもWDDM 1.1へとアップデートされた。DirectX診断ツールでもWDDM 1.1の表記が確認できるが、GDIはソフトウェアレンダリングであるなど、一部の動作に差異はある。
WDDM 1.1のドライバは、Windows 11以降のOSではサポートされない。WDDM 2.0以上が必須要件となった。
バージョン > WDDM 1.2

Windows 8では、WDDM 1.2がサポートされた。
ビデオメモリのより効率的な利用、Direct3D 11.1のサポートなどが追加されている。
WDDM 1.2には必須機能とオプション機能があるが、ドライバーがWDDM 1.2の必須機能をすべて実装していない場合、WARP（英語版）ベース（ソフトウェア実装）のMicrosoft Basic Display Driver (MSBDD) にフォールバックされる。
なお、Windows 7 SP1およびWindows Server 2008 R2 SP1に対して、「Windows 7 SP1 および Windows Server 2008 R2 SP1 用のプラットフォーム更新プログラム（KB2670838）」を適用することでDirect3D 11.1やDirect2D 1.1などの一部機能が使えるようになるが、ドライバーモデルがWDDM 1.2対応になるわけではない。
WDDM 1.2のドライバは、Windows 11以降のOSではサポートされない。WDDM 2.0以上が必須要件となった。
バージョン > WDDM 1.3

Windows 8.1では、WDDM 1.3がサポートされた。
タイル化されたリソース（メガテクスチャ（英語版））や、Direct3Dレンダリングパフォーマンスの改善、Direct3D 11.2のサポートなどが追加されている。
また、Miracastのサポートもオプションとして追加された。Windows 8.1やWindows 10でMiracast機能を利用するにはWDDM 1.3以降に対応したドライバが必要になる。
WDDM 1.3のドライバは、Windows 11以降のOSではサポートされない。WDDM 2.0以上が必須要件となった。
バージョン > WDDM 2.0

Windows 10では、WDDM 2.0がサポートされた。
Direct3D 11.3およびDirect3D 12のサポートなどが追加されている。また、GpuMmuおよびIoMmuと呼ばれる2つの仮想アドレッシングモデルを持つGPU仮想メモリ機能などをサポートする。なお、この仮想メモリ機能はかつてWinHEC（英語版） 2006にて"WDDM v2"の機能として発表されたが、実際にWDDM 1.0の後継としてWindows 7に搭載されたWDDM 1.1では実現していなかった。
バージョン > WDDM 2.1

Windows 10 Anniversary Update (version 1607) では、WDDM 2.1がサポートされた。
同時にDirect3D 12およびDXGI 1.5の更新も行なわれ、シェーダーモデル6.0のサポート、およびUWPアプリケーションにおける可変リフレッシュレートのサポートなどが追加される。
バージョン > WDDM 2.2

Windows 10 Creators Update (version 1703) では、WDDM 2.2がサポートされた。
Windows Mixed Realityの仮想/拡張/複合現実の立体視レンダリングのサポートなどが追加された。
バージョン > WDDM 2.3

Windows 10 Fall Creators Update (version 1709) では、WDDM 2.3がサポートされた。
バージョン > WDDM 2.4

Windows 10 April 2018 Update (version 1803) では、WDDM 2.4がサポートされた。
バージョン > WDDM 2.5

Windows 10 October 2018 Update (version 1809) では、WDDM 2.5がサポートされた。
バージョン > WDDM 2.6

Windows 10 May 2019 Update (version 1903) では、WDDM 2.6がサポートされた。
バージョン > WDDM 2.7

Windows 10 May 2020 Update (version 2004) では、WDDM 2.7がサポートされた。
DXGI

DXGI (DirectX Graphics Infrastructure) は、DirectX 10 (Direct3D 10) 以降で利用可能になる新しいグラフィックス共通基盤およびそのAPI集合である。カーネルモードドライバーやハードウェアとの通信といった低レベルのタスクを担当する。
DXGIは、アダプター（グラフィックスカードあるいはリファレンスラスタライザーなど）やアウトプット（モニター）といったデバイス概念を抽象化する。さらに、以前のバージョンのDirect3Dでもおなじみとなっているダブルバッファリングシステムは、スワップチェーンと呼ばれる概念に集約される。
DXGIを導入することで、変化の頻繁なDirect3D APIやDirect2D APIによる実際のレンダリング部分と、変化の緩やかなデバイス通信部分を分離して考えることが可能となる。また、DXGI層を経由したDirect3DとDirect2Dの相互運用が可能となる。そのほか、DirectComputeでは、DXGIアダプターの列挙によって、プライマリモニター出力に利用されるデフォルトアダプターだけでなく、セカンダリアダプターも統一的に分散コンピューティング用演算リソースとして活用することが可能である。
DXGIのバージョンは、WDDMおよびDirectXのバージョンとともにアップデートされている。例えばWDDM 1.1とDirectX 11をサポートするWindows 7には、DXGI 1.1ランタイムが導入される。Windows Vista SP2 Platform Updateでも、WDDM 1.1のサポートは完全ではないものの、DXGI 1.1ランタイムはDirectX 11ランタイムと同時にバックポートされているため、DXGI 1.1 API自体の使用は可能である。
Windows 8にてDirectX 11.1に対応するDXGI 1.2が導入された。Windows 7 SP1 Platform Updateでも、WDDMのバージョンは1.1のままだが、DXGI 1.2ランタイムはDirectX 11.1ランタイムと同時にバックポートされており、一部のAPI機能が使える。
DirectX 11.2に対応するのはDXGI 1.3 (Windows 8.1以降)、そしてDirectX 11.3とDirectX 12に対応するのはDXGI 1.4 (Windows 10) となる。
Windows 10 November 2015 Update (version 1511, build 10586) にてDirectX 11.4とともにDXGI 1.5が導入された。
Windows 10 Creators Update (version 1703, build 15063) にてDXGI 1.6が導入された。以降はDXGI自体のバージョン番号は1.6で据え置きのまま、Windows 10の機能更新リリースとともにDXGIにも機能が追加されている。
FUKUIスーパーレディス駅伝

FUKUIスーパーレディス駅伝（フクイスーパーレディスえきでん）は、1985年から2017年まで、毎年11月の第2日曜日に、福井県福井市で開催されていた駅伝競走大会。正式名称は「スーパーレディス駅伝競走大会」。
大会概要

1985年に、北陸女子駅伝（ほくりくじょしえきでん）としてスタート。当初は5区間22kmのコースだったが、1994年の第10回大会から6区間30kmに延長された。現在は日本陸上競技連盟に公認された、福井市の福井運動公園陸上競技場をスタート・ゴールとし、堀ノ宮町を折り返すコースとなっていた。特に長距離ランナー（マラソン・ロードレース含む）の育成と、テレビ中継を通して競技力の高揚を図ることが狙いであった。
同日に福島テレビ主催で行われる東日本女子駅伝との違いは、東日本女子駅伝は東日本が北海道から静岡県までの18都道県対抗レースとして行われるが、こちらは大きく第1部と第2部の2つのカテゴリーに分かれ、広く門戸が開放されているところにあった。
第1部は福井県や周辺府県陸連選抜だけでなく、実業団や大学チームもエントリーできた。主力チームは年末に行われる富士山女子駅伝や全日本実業団女子駅伝などの大レースを控えているため、絶好の調整レースともされていた。
第2部は一般のクラブチーム（原則高校生以上。ただし3キロで行う第2区に限り中学生の参加も可）などを対象としていた。
2004年の第20回大会を前に、新しい名称を公募し、「FUKUIスーパーレディス駅伝」に変更。
2017年の第33回大会をもって終了した。
大会運営

主催：福井陸上競技協会、福井テレビジョン放送
後援：福井県、福井県教育委員会、福井県高等学校体育連盟、福井県中学校体育連盟、福井県体育協会、福井市、福井市教育委員会、福井市体育協会、福井市陸上競技協会、北陸陸上競技協会、北陸実業団陸上競技連盟、福井新聞社、福井エフエム放送
協力：陸上自衛隊金沢駐屯地 第14普通科連隊、陸上自衛隊鯖江駐屯地 第372施設中隊、自衛隊福井地方協力本部、福井県隊友会、福井県警察本部、福井警察署、福井南警察署、福井県警察本部交通機動隊、福井市消防局、福井市消防音楽隊、福井県交通安全活動推進センター、福井市交通指導員会、福井県医師会、福井市医師会、福井県済生会病院、福井ダイハツ販売、えちぜん鉄道、福井鉄道、京福バス
冠スポンサー
アサヒ緑健（～2003年）
福井工業大学（2004年〜2007年）
大和ハウス工業（2008年〜2017年）
各区間距離

| 区間 | 距離 | 起点 | 終点 | 備考 |
| --- | --- | --- | --- | --- |
| 1区 | 6.55km | 福井運動公園 | 福井市渕3丁目 | - |
| 2区 | 3.0km | 福井市渕3丁目 | 福井市西木田2丁目 | - |
| 3区 | 4.0km | 福井市西木田2丁目 | 福井市光陽4丁目 | - |
| 4区 | 4.0km | 福井市光陽4丁目 | 福井市八ツ島町 | 途中折り返し点（第4中継所手前） |
| 5区 | 5.0km | 福井市八ツ島町 | 福井市二の宮3丁目 |  |
| 6区 | 7.45km | 福井市二の宮3丁目 | 福井運動公園 | - |
テレビ中継

主催の福井テレビが制作しており、フジテレビ・関西テレビ・東海テレビ・テレビ西日本・石川テレビ・富山テレビ・テレビ静岡・長野放送が制作協力していた。また関西テレビ、東海テレビから中継車が1台ずつ派遣されていた。実況・リポーター担当のアナウンサーは、制作局の福井テレビのほか、石川テレビや富山テレビ、東海テレビからも派遣されていた。
開催当日の日曜昼のニュースでは、全国枠で放送される東日本女子駅伝の直前情報を差し替え、当駅伝の直前情報を福井テレビ・石川テレビ・富山テレビで放送していた。
テレビ中継 > 放送体制

福井テレビ、石川テレビ、富山テレビ
上記3局を除くフジテレビ系列25局で11月から12月にかけて放送。ほとんどが深夜に放送。2008年からネット局が大幅に増え、2009年以降は全局で放送されている。ただし2010年のみ、岩手めんこいテレビ、福島テレビ、沖縄テレビでは放送されなかった。
主な参加チーム

府県陸連選抜
主に福井県や周辺府県の陸連選抜チームが主体。
大学・女子大学チーム
立命館・佛教大・名城大の様な大所帯の名門クラスの女子陸上部では、AB方式の2チームで構成されることもあった。
実業団チーム
キヤノンアスリートクラブ九州（キヤノン全額出資、同系列の大分キヤノンに運営委託）が26回大会で初出場。同大会の1区では好順位で襷渡しを行っている。また、登録での実業団チームでトップの常連であるデンソーや小島プレス・パナソニック（パナソニックモバイルコミュニケーションズ運営）等も出場していた。
備考

同日の午前には嶺南4市町（敦賀市、美浜町、若狭町、小浜市）に於いて嶺南駅伝が開催されていた。
この駅伝は過去に高橋尚子、松野明美、福士加代子、真木和など日本を代表するランナーも走った経験がある。
また吉本ひかり、竹中理沙ら今後の日本女子陸上界を担う存在の選手も大学時代に走っている。
1950年のラジオ (日本)

1950年のラジオ (日本)では、1950年の日本のラジオ番組、その他ラジオ界の動向について記す。
主なその他ラジオ関連の出来事

3月25日 - NHKが盛岡、宮崎、北見でラジオ第2放送を開始。
4月25日 - NHKが旭川、帯広、釧路、甲府、鳥取、大分でラジオ第2放送を開始。
6月1日 - この日、無線電信法に代わる放送関連の規制法「電波三法（電波法・放送法・電波監理委員会設置法）」が施行。放送法施行に伴い、NHKが社団法人から特殊法人に改組されたほか、民間放送事業者設置に関する規定が初めて明文化された。
7月～8月 - レッドパージにより、共産主義者およびその支持者と目されたNHK職員のべ119人が解雇される。
11月6日 - NHKラジオの時報音の零秒音を衝撃音から持続音に変更。
開始番組 > 1950年1月放送開始

8日 - 今週の明星
開始番組 > 1950年3月放送開始

6日 - 趣味の手帳
開始番組 > 1950年4月放送開始

30日 - 三太物語
1日 - 女性教室
開始番組 > 1950年6月放送開始

14日 - 私の見たこと聞いたこと
開始番組 > 1950年8月放送開始

3日 - 世界の危機
開始番組 > 1950年9月放送開始

1日 - 気まぐれショウボート
開始番組 > 1950年11月放送開始

11日 - ラジオ喫煙室
12日 - 国際連合だより
終了番組 > 1950年12月放送終了

29日 - 鐘の鳴る丘
ピカ☆★☆ンチ LIFE IS HARD たぶんHAPPY

『ピカ☆★☆ンチ LIFE IS HARD たぶんHAPPY』（ピカンチハーフ ライフイズハードたぶんハッピー）は、嵐主演の日本映画。
2002年に公開の前々作『ピカ☆ンチ LIFE IS HARDだけどHAPPY』、そしてその続編として2004年に公開された『ピカ★★ンチ LIFE IS HARDだからHAPPY』から10年を経て制作されたスピンオフ映画。
単なる続編ではなく、2.5作という位置づけとされている。
概要

「次があるとすれば10年後」と言っていたが、メンバーの発案によって製作が実現した。8年経ち、30代の大人となった5人が再会を果たす姿が描かれる。2014年6月中旬より撮影が開始され、映画のポスターは、セーラー服姿や長髪に謎のヒッピースタイルなど5人それぞれが前作より8年成長した姿で、6月下旬に都内の公園で撮影された。
2015年2月25日にBlu-rayとDVDが発売され、売上8.5万枚でDVD邦画部門2015年年間1位を記録した。
上映

当初は2014年8月1日より8月31日までTOKYO DOME CITY HALLにて限定公開予定だったが、2014年7月13日にチケットが発売されたところ、約25万枚のチケットが2日間で完売。ファンからの要望も多かったため、東京・大阪での公開のみだった前2作より範囲を拡大し、札幌、名古屋、福岡での地方拡大公開が決定した。
東京：TOKYO DOME CITY HALL（2014年8月1日 - 31日）
北海道：Zepp Sapporo（2014年10月28日 - 11月2日）
福岡：都久志会館ホール（2014年11月3日 - 8日）
大阪：シアターBRAVA!（2014年11月5日 - 19日）
名古屋：名古屋国際会議場センチュリーホール（2014年12月20日、21日）
当時5大都市合計で約36万人を動員予定としていた。
あらすじ

前作から10年。
それぞれの道に進んだ4人（タクマ以外）は、ひょんな出来事から再び八塩で集まることになった。
キャスト

岡野瞬（シュン） - 相葉雅紀
二葉廉太郎（ボン） - 松本潤
恩田琢磨（タクマ） - 二宮和也
貴田晴彦（ハル） - 大野智
鴨川忠（チュウ） - 櫻井翔
鴨川弥生 - 水川あさみ
田沢 - 小林一英
鉄 - 小林令門
天宮三六 - でんでん
天宮美加里 - 宮地真緒
高野ゆか - 優紀
鮫洲一家のメンバー - 谷川功
北の裸族店員 - 屋良学
葵学 - 近江谷太朗
三途の川渡し人（タクマの父） - 半海一晃
上島竜兵 - 上島竜兵（ダチョウ倶楽部）
村岡 - 松原智恵子
妙子 - 上地春奈
鴨川鉄壁 - 大西利空
アニャンゴ - シリム・エスター
YCB新宿店店長 - 越村公一
貴田君江 - 秋山菜津子
鴨川かごめ - 井ノ原快彦（20th Century）
スタッフ

原案：井ノ原快彦（20th Century）
監修：堤幸彦
監督：木村ひさし
脚本：河原雅彦
オープニングテーマ：嵐「PIKA★★NCHI DOUBLE」
エンディングテーマ：嵐「PIKA☆NCHI」
Zswap

| --- | --- |
開発元:  Seth Jennings ほか
プログラミング 言語:  C
対応OS:  Linux
種別:  Linux kernel features
ライセンス:  GNU GPL
公式サイト:  kernel.org
テンプレートを表示
zswap とは、仮想メモリ圧縮（英語版）を実現する Linux カーネルの機能で、スワップされたページを圧縮されたライトバックキャッシュ上に保持する。メモリページ（英語版）がスワップアウトされる際にスワップデバイス上に移動させるのではなく、システム RAM 上に動的に確保されるメモリプール内に圧縮して保存する。実スワップデバイスへのライトバックは延期されるか完全に回避されるので、スワップが必要とされる Linux システム上の I/O を大きく低減させることができる。トレードオフとして、圧縮を実行するために CPU サイクルの消費は増加する。
組み込みデバイスやネットブックその他のローエンドハードウェアデバイスなどに加え、SSD をストレージに利用するデバイスなど、様々なフラッシュベースストレージ（英語版）を用いるデバイスにおいて、zswap の I/O が低減される利点を活かすことができる。なぜなら、フラッシュメモリは原理上書き込み回数が限られておりスワップ領域として利用されると急速に消耗してしまうためである。
内部機構

zswap は、Linux カーネルの仮想メモリサブシステムに、frontswap が提供する API を利用して組込まれている。frontswap とは、Linux カーネル内で様々な種類のストレージを抽象化してスワップ領域として利用するための機構である。結果として、zswap は 内部的には疑似 RAM デバイスを提供する frontswap のバックエンドドライバーとして動作する。言い換えると、 zswap は frontswap API により、スワップアウトされるメモリページをインターセプトすることで、ページフォールトの際にスワップ済のページをインターセプトすることが可能となる。 これら二つのパスにアクセスできることにより、 zswap はスワップされたページの圧縮されたライトバックキャッシュとして振る舞うことができる。
内部的には、zswap は Linux カーネルの crypto API（英語版） が提供する圧縮モジュールを利用する。このモジュールにより、たとえば圧縮による負荷をメイン CPU ではなく Linux カーネルがサポートするハードウェア圧縮アクセラレータに負担させることができる。望ましい圧縮モジュールの選択は、カーネルブートパラメータ（英語版） zswap.compressor の値を通じて
起動時に動的に行うことができる。指定のない場合、デフォルトで Lempel–Ziv–Oberhumer (LZO) 圧縮アルゴリズムが利用される。Linux カーネルバージョン 3.13 時点で、zswap を利用するには明示的にカーネルブートパラメータ zswap.enabled に 1 を指定する必要がある。
zswap が利用できるメモリプールの最大サイズは sysfs パラメータ max_pool_percent により設定可能である。このパラメータには、総システム RAM の何パーセントをメモリプールが占有できるかを指定する。指定された最大サイズのメモリープールが事前に確保されるわけではなく、必要に応じてサイズは増減する。スワップが実行された結果設定された最大プールサイズに到達した場合、もしくは out-of-memory（英語版） 状態のためプールを拡大することができなかった場合、スワップされたページは
Least Recently Used アルゴリズムに基いてメモリプールからスワップデバイスへと退避させられる。このアプローチにより、キャッシュが満杯になった際に最古のキャッシュページがスワップデバイスに退避させられ、新しいスワップページを圧縮してキャッシュするための余地が確保されるという意味で、zswap は真のスワップキャッシュといえる。
zbud は、圧縮されたページの格納用に zswap 内部で利用されている特定用途向けメモリアロケータ（英語版）である。Oracle による、別の仮想メモリ圧縮実装である zcache で利用されている zbud アロケータの書き直しとして実装された。内部的には、zbud は物理メモリページごとに二つまでの圧縮済ページ（"buddies（英語版）" と呼ばれ、これがアロケータ名の由来となっている）を格納できるよう動作するため、開放された領域の結合と再利用が容易である利点を持つ一方で、メモリ利用率が低い（圧縮率が2を超えない）という欠点もある。zbud のもう一つの設計上のメリットとして、zbud は非圧縮時のページが元々占有していた領域よりも大きなメモリ領域をアロケートすることはない、すなわち本来使用するはずだったメモリ領域以上の領域を使用することが無い。
歴史

zswap と zbud は、どちらも Seth Jennings により作成された。最初のアナウンスは2012年になされ、2013年5月までの開発の結果コードベースは成熟段階に達しているが、未だに実験的カーネル機能の状態である。
zswap は（zbud と共に） Linux カーネルのメインラインに2013年9月2日にリリースされたバージョン 3.11 においてマージされた。
2014年6月8日リリースのバージョン 3.15 からは、複数のスワップデバイスを適切にサポートするようになった。
代替

zswap の代替となりうるものの一つに zram が挙げられる。この手法は似ているもののまた別の「RAM 上に圧縮されたスワップページを置く」機構を Linux カーネルに提供する。
主な違いは、zram はデータの格納用に RAM を利用した圧縮ブロックデバイスを提供し、これを通常のスワップデバイスとして追加で利用するという点である。zram を利用するには、mkswap コマンドラインユーティリティによる初期化と swapon による利用設定をユーザースペース（英語版）側から行う必要がある。その設計上、zram はスワップが他に存在しない場合にもスワップ領域を提供することができるため、組み込みシステムなどスワップ領域がもともと存在しないシステムにより適している。
比較すると、zswap は透過的に動作しユーザースペースでの設定が必要なく、通常のスワップデバイスの RAM ベース圧縮キャッシュとして動作する。これにより zswap は zram にはない、より使われていないスワップページを退避させる機構を持っている。しかし、zswap を利用するには設計上少くとも一つのスワップデバイスが存在する必要がある。
ICalendar

| --- | --- |
拡張子: .ical; .ics; .ifb .icalendar
MIMEタイプ: text/calendar
種別: PIMデータ標準
国際標準: RFC 5545
iCalendar（アイカレンダー）とはPIMソフトなどで使われるスケジュールの標準フォーマット。RFC 5545 （旧版 RFC 2445）で規定されている。「iCal」と略称される。
iCalendarをサポートしたソフトウェアを使うことで、他のユーザーに対してミーティングの時間や予定を電子メール経由で知らせることが容易になり、メールの受信者もミーティングの日時を簡単に提案できるようになる。
iCalendarは多くの製品に実装、サポートされている。そのデータは従来の電子メールで交換され、仕様上、送信プロトコルに依存しないこととなっている。たとえばWebDAVサーバやSyncMLを使って共有や編集が行える。HTTPプロトコルしか使用しないシンプルなWebサーバは、iCalendarフォーマットのスケジュールデータを配付するために使われる。hCalendarを使えばWebページにiCalendarデータを埋め込むことができる。
基本仕様

iCalendarの仕様はオープンテキストのアニク・ガングリーを議長とする、Internet Engineering Task Forceのカレンダー・スケジュール作業部会によって定められた。仕様の記述はロータス社のフランク・ドーソン、マイクロソフトのデリック・ストナーソンによる。iCalendarの仕様はインターネットメール・コンソーシアム（英語版） (IMC) によって規定されたvCalendarに依拠している。
iCalendarデータのMIMEタイプは「text/calendar」である。
このMIMEタイプを持つカレンダー・スケジュールデータファイルには、拡張子「ics」が付けられる。（Mac OSではタイプコード「iCal」）
「free and busy time」（空いた時間と予定のある時間）を含むデータには拡張子「ftb」が付与される。（Mac OSではタイプコード「iFBf」）
iCalendarデータはプレーンテキストで、デフォルトでUTF-8が使用される。別の文字コードを使うときは「charset」MIMEパラメータで指定することができる。各行は CR + LF (16進:0D0A) で改行され、各行75オクテットの文字数制限がある。次の行にまたぐ場合はスペース (16進:20) またはタブ (16進:09)で行を始めることで、前行からの続きであることを明示できる。データ項目内での改行をしたい場合は「バックスラッシュ + N」（UTF-8で5C6Eまたは5C4E、\n）でコーディングする。
基本仕様 > コア・オブジェクト

iCalendarの先頭には「カレンダー・スケジュール・コア・オブジェクト」が位置する。これはカレンダーとスケジュール情報の集合体である。最小単位は単一のiCalendarオブジェクトであり、これらが複数まとめられている。1行目は必ず「BEGIN:VCALENDAR」で始まる必要があり、最後は「END:VCALENDAR」で終わる。この行の間には「icalbody」と呼ばれる主データ記述が入る。主データ部は一連のカレンダー・プロパティおよびカレンダー・コンポーネントからなり、前者は全体の属性を記述、後者は具体的な用事や日程、日時などのタイムスケジュールが記述され、アラーム[要曖昧さ回避]設定なども行われる。
RFC 2445によるシンプルなiCalendarオブジェクトのサンプルを以下に示す。内容は1997年7月14日-15日のパリ祭に関するものである。
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//hacksw/handcal//NONSGML v1.0//EN
BEGIN:VEVENT
DTSTART:19970714T170000Z
DTEND:19970715T035959Z
SUMMARY:Bastille Day Party
END:VEVENT
END:VCALENDAR
この標準仕様には他にも以下に述べるような様々なコンポーネントが定義されている。Apple iCal やマイクロソフトのOutlookでは次のような追加記述子が使われる。
X-WR-CALNAME:Revolution Parties
X-WR-CALDESC:Celebrations of various revolutionary activities.
X-WR-RELCALID:3E26604A-50F4-4449-8B3E-E4F4932D05B5
X-WR-TIMEZONE:US/Pacific
X-WR-RELCALIDは汎用一意識別子 (UID) である。
イベント (VEVENT)

VEVENTコンポーネントはカレンダー上で予定されたイベントについて記述された属性の集合体である。これは具体的な用件だけでなく、「TRANSPARENT」（白紙）といった記述も可能である。アラームを定義する場合、VEVENT内部にVALARMコンポーネントが含まれる。また開始時刻を定義するDTSTARTプロパティと終了時刻を定義するDTENDプロパティを持つ。
記念日や毎日行うことのように何度も繰り返されるイベントもVEVENTで記述される。標準ではDATE-TIMEに日時が記述されるが、DTSTARTプロパティが日時データを持ち、DTENDプロパティは持たない。
予定をキャンセルするときもUIDはそのまま保持され、他のコンポーネントには <SEQUENCE:更新番号>がセットされる。
ToDo (VTODO)

ToDo、つまりアクションアイテムや宿題事項などが記述されるコンポーネント。下記はRFC 2445による1998年4月15日のToDoについて記述したサンプルである。
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VTODO
DTSTAMP:19980130T134500Z
SEQUENCE:2
UID:uid4@host1.com
ORGANIZER:MAILTO:unclesam@us.gov
ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:jqpublic@example.com
DUE:19980415T235959
STATUS:NEEDS-ACTION
SUMMARY:Submit Income Taxes
BEGIN:VALARM
ACTION:AUDIO
TRIGGER:19980403T120000
ATTACH;FMTTYPE=audio/basic:http://example.com/pub/audio-
 files/ssbanner.aud
REPEAT:4
DURATION:PT1H
END:VALARM
END:VTODO
END:VCALENDAR
ジャーナル (VJOURNAL)

VJOURNALコンポーネントは日誌のように特定の日付にコメントを付けたり、作業内容や進捗の実績を記録するために利用される。実際のところ、iCalendarの実装でVJOURNALをサポートしているものはほとんど無い。プラムカナリーズ・チャープ・ソフトウェア社は、プロジェクトタスクの進捗管理ソリューションのデータフォーマットとしてVTODOとVJOURNALを採用している。また、KDEのシステム手帳、KOrganizerもVJOURNALをサポートしている。
下記はRFC 2445によるVJOURNALの記述サンプルである。
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VJOURNAL
DTSTAMP:19970324T120000Z
UID:uid5@host1.com
ORGANIZER:MAILTO:jsmith@example.com
STATUS:DRAFT
CLASS:PUBLIC
CATEGORY:Project Report, XYZ, Weekly Meeting
DESCRIPTION:Project xyz Review Meeting Minutes\n
 Agenda\n1. Review of project version 1.0 requirements.\n2.
 Definition
 of project processes.\n3. Review of project schedule.\n
 Participants: John Smith, Jane Doe, Jim Dandy\n-It was
  decided that the requirements need to be signed off by
  product marketing.\n-Project processes were accepted.\n
 -Project schedule needs to account for scheduled holidays
  and employee vacation time. Check with HR for specific
  dates.\n-New schedule will be distributed by Friday.\n-
 Next weeks meeting is cancelled. No meeting until 3/23.
END:VJOURNAL
END:VCALENDAR
フリー・ビジータイム (VFREEBUSY)

VFREEBUSYコンポーネントはフリー・ビジータイム……つまり空いた時間と予定のある時間を定義する。以下はRFC 2445による予定時間情報を記述したサンプルである。特定のURLに置かれる場合、拡張子は「ifb」となる。
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//RDU Software//NONSGML HandCal//EN
BEGIN:VFREEBUSY
ORGANIZER:MAILTO:jsmith@example.com
DTSTART:19980313T141711Z
DTEND:19980410T141711Z
FREEBUSY:19980314T233000Z/19980315T003000Z
FREEBUSY:19980316T153000Z/19980316T163000Z
FREEBUSY:19980318T030000Z/19980318T040000Z
URL:http://www.host.com/calendar/busytime/jsmith.ifb
END:VFREEBUSY
END:VCALENDAR
その他のコンポーネント

VTIMEZONE - 等時帯を定義
VALARM - アラーム設定を定義
スケジュール更新

予定されたスケジュールに変更がかかった場合、UIDフィールドを利用して改訂版の割り当てが行われる。最初に予定が設定されたときに一意の識別子 (UID) が生成され、スケジュールに変更がかかったときも同じUIDで発行される。UIDの例としては、「とある大学の第2学期131学級の5回目の打ち合わせ」なら「Y2007S2C131M5@example.com」という具合になる。
データ互換

iCalendarフォーマットはカレンダーベースのデータを記述するために設計されており、即座にこのデータをもって何かを記述するわけではないので、実際の運用には他の規約が必要となることがある。
付属規約であるiTIPプロトコル (RFC 5546) はカレンダーユーザー間でカレンダー・スケジュールデータを交換するための規約であり、最初に交換を提案した人が「オーガナイザ」と呼ばれることになる。この標準は「発行」「要求」「応答」「追加」「中止」「更新」「撤回」「撤回却下」といったメソッドを定義する。
他の付属規約にIMIPプロトコル (RFC 6047) がある。これは電子メールでの通信にiTIPを実装する手順に関する仕様である。
RFC 3283の「インターネット・カレンダー・ガイド」ではiCalendarと関連規格との様々な関係が述べられている。
iCalendarフォーマットはカレンダーデータの相互運用もサポートしている。使用頻度の高い、基本的な特徴はiCalendar実装時にサポートされ、互換性も高いのだが、拡張機能のようなものになると途端に実装度合いは低下してしまう。ほとんどのベンダーは「JOURNAL」をサポートしていないし、予定の繰り返しやスケジュール反復も相互運用に不自然な問題を抱えている。VTODOプロパティも2004年時点での相互運用は出来ない状態である。
iCalendarはイスラエルやサウジアラビアなどで運用されている非グレゴリオ暦ではカレンダーへの記入もままならない。それらの暦をグレゴリオ暦に一対一で置き換えることも様々な要因で困難を極める。例えばユダヤ暦では13月というものが存在する場合があるし、天皇が変わるたびに変化する日本の元号も問題である
RFC 4324の「カレンダーアクセスプロトコル」は最初の汎用スケジューリングデータ標準として普及を試みたが、その複雑な仕様により、実装されることなく終わった。現在GroupDAVやCalDAVといったiCalendarベースの実用的な通信プロトコルが、クライアント・サーバ双方のパッケージソフトに現れ、カレンダーアクセス標準としての地位を確保せんとしている。
IETFカレンダー・スケジュール作業部会は、過去の標準を参照し、カレンダー・スケジューリングコンソーシアム (Calconnect) のような他の作業部会とも連携を取りながら、iCalendar標準の改定プロセスに入っている。2004年設立のCalconnectは専門委員会により実装及び相互運用試験を行う機関であり、あらゆる団体、個人も加入が可能である。
vCalendar 1.0

vCalendar1.0はインターネットメール・コンソーシアム (IMC) によって公表されたiCalendarフォーマットの元となった規格である。以下がその例。
BEGIN:VCALENDAR
VERSION:1.0
BEGIN:VEVENT
CATEGORIES:MEETING
STATUS:TENTATIVE
DTSTART:19960401T033000Z
DTEND:19960401T043000Z
SUMMARY:Your Proposal Review
DESCRIPTION:Steve and John to review newest proposal material
CLASS:PRIVATE
END:VEVENT
END:VCALENDAR
IMCはiCalendarリリース後、ベンダーがこれらのオープンフォーマットを採用して、vCalendar1.0とiCalendarの両方に互換性をもつソフトウェアを開発するよう呼びかけている。
ライブラリ

iCalendarデータファイル生成のため、様々なプログラミング用ライブラリが公開されている。
iCalcreator - PHP
VObject - Python
iCal4j - Java