久住昌之・加藤総夫「脳天観光」を改めて読みなおす

脳天観光 (扶桑社文庫)

脳天観光 (扶桑社文庫)

夢って何なのか?記憶ってどうやって残されているのか?感動って?ココロって科学的に言うとどういうものなの?人間に関する謎は、元をたどっていけば、みんな脳に関することだ。だけど、今まで何を読んでも脳が理解できなかったり、『賢くなれる脳科学の本』の類を読んでもあまり効果がなかったと感じたりで、脳って難しくてわかんない、とあきらめてるアナタ!科学者は一体何が楽しくて研究なんて訳分からないことをしているの?と思っているキミ。そんなみんなにオススメの、観光気分で脳がわかる1冊。

孤独のグルメ」原作者として今をときめく久住昌之氏と、現役バリバリ研究者な加藤総夫氏(現在は慈恵会医科大学教授)がタッグを組んで書いた脳研究入門書。
元々は1990年「月刊SPA!」連載だったんですが、1992年に単行本化、1996年に大幅な改訂・加筆訂正の上で文庫化されています。

と、まずべた褒めの前に予め難点を揚げておくと、最大の難点はやっぱり古いこと。日進月歩な勢いで研究が進んでいる分野な訳で、やっぱ18年前の内容で新しいトピックが含まれてないというのは辛いところです。


ただ、古いという欠点はあるものの、高校生~大学教養課程ぐらい、あるいはあんまり科学とか普段は縁のない社会人向けの入門書としては今でも最強クラスなんじゃないかなーと思います。

なんつーか、研究者と文化人との対談本って色々ありますが、パターンとして「功績を積み上げてきたエライ教授」と「功績を積み上げてきたエライ文化人」的な感じがあります。一冊例を挙げると

とか。まあエライ人とエライ人が対談してっていうのはそれはそれで面白い物ですが、やっぱり退屈というか正座して傾聴的なフォーマルさがあってどうにも「入門書」として食いつきが良いかどうかっていうと微妙な部分があります。

で、本書なんですが、加藤総夫氏はここの略歴を見る限り、1990年の雑誌連載当時は助手。その後はフランスで研究生活を送った後、文庫版出版時には慈恵会医科大学講師です。つまり、バリバリ研究して成果を出し、キャリアを積み上げていく真っ最中な若手研究者なんですな。「地位を固めた後のエライ人」ではなく「油の乗った現役バリバリな研究者」が、久住昌之氏の絶妙にボケの入った質問にノリノリで答えていくわけで、面白くない訳が無い。

また、扱っている内容も、神経細胞の基本構造とか、神経細胞内での情報伝達の仕組みとか、神経回路網が形成される基本的仕組みとか、あるいは脳内での情報処理(立体視や「漫画を読むときにバックグラウンドで処理されてる情報」みたいな)とかそういった、当時としても最新の知見では無いけれど、でも脳研究とは縁のない普通の人にとっても興味深いトピックがてんこ盛りです。

いやほんと、どれだけ面白いかって言うと、文庫版出版等時に高校生だった自分の生涯所得を数百万円単位で削っていった(工学部へ入ったもののやっぱりバイオ系へ転科したけど、研究者に成れず退学して一般企業に入ったって事だ書かせんな恥ずかしいってアレコレの一因になった)ぐらい破壊力がある。

ということで、この本はもっと評価されても良いと思います。
久住昌之人気に火が着いてる今、再度加筆訂正+最新トピックの補足を入れて再刊したら売れると思うんだけどなあ。

この辺は他にも、「アシモフの科学エッセイ」シリーズとか

斉田博「おはなし天文学」シリーズとか

おはなし天文学〈1〉

おはなし天文学〈1〉


内容的にはかなり古いものの、トピックごとに現在の専門家から見た補足説明や解説を入れれば、今でも十分以上に面白い入門書は色々あるんですが、科学入門書の「アップデート版」って出版社的には難しいんですかねえ。

SwaggerでREST APIドキュメントを生成する


2016/06/24 追記
www.itmedia.co.jp

今のところまだこの脆弱性の対策版がリリースされていないので注意。


だいぶ昔にJersey(JAX-RS参照実装)についての記事を書いてからずっと気になっていたんですが、せっかくアノテーションを使ってURLとメソッドとの間にヒモ付が出来たのに、このアノテーション情報からJavadoc的なAPIドキュメントを生成する方法は無いものかと思っていました。
追記: いやjerseyでwadlを生成できるけどレスポンスのJSONXMLの構造については何も情報が出ないので・・・)

JAX-RSでは今のところAPIドキュメント生成についてはカバーして無いようですが、最近仕事でREST APIドキュメントを生成出来ないかという話が出てきたので調べてみるとSwaggerというREST APIドキュメント生成フレームワーク?が有るようなので触ってみました。

Swaggerを使ったREST APIドキュメントはこんな感じです

Swagger-UI デモサイト


URLとHttpメソッドの組み合わせで、どのようなパラメータを受け付けるのか、戻ってくるJSONの構造、エラー時のhttpステータスコードといった情報を一覧取得することが可能です。

例: http://petstore.swagger.wordnik.com/#!/pet/getPetById



ちょうどJersey(Jax-RS) + AngularJSの組み合わせでサンプルを作っていたので、こいつをSwaggerによるREST APIドキュメント生成に対応させてみます。
というか、あっけなくREST APIドキュメントが生成されてちょっと感動したので、手順を書いてみます。

JerseyベースのRESTサービスでREST APIドキュメントを生成するためのステップ

以下の環境を前提としています。

  • Java8
  • Tomcat8
  • maven2以降
  • Jerseyを使用したREST APIが既に作成済み

 (ソースについては後日githubへpush予定)

1. pom.xmlの編集(maven使用時)

dependenciesエレメントに下記のdependencyを追加してください。

        <dependency>
            <groupId>com.wordnik</groupId>
            <artifactId>swagger-jersey-jaxrs_2.10</artifactId>
            <version>1.3.0</version>
        </dependency>

2. web.xmlの編集

まずはjerseyのservletについて。
元々のservlet定義は

    <servlet>
        <servlet-name>Example Web Application</servlet-name>
        <servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
        <init-param>
            <param-name>com.sun.jersey.config.property.packages</param-name>
            <param-value>jp.gr.java_conf.ka_ka_xyz.example.service</param-value>
        </init-param>
        <init-param>
            <param-name>com.sun.jersey.api.json.POJOMappingFeature</param-name>
            <param-value>true</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>Example Web Application</servlet-name>
        <url-pattern>/service/*</url-pattern>
    </servlet-mapping>


ですが、以下のように"com.sun.jersey.config.property.packages"にswaggerのパッケージ名を追加してください。

    <servlet>
        <servlet-name>Example Web Application</servlet-name>
        <servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
        <init-param>
            <param-name>com.sun.jersey.config.property.packages</param-name>
            <param-value>jp.gr.java_conf.ka_ka_xyz.example.service;com.wordnik.swagger.jersey.listing</param-value>
        </init-param>
        <init-param>
            <param-name>com.sun.jersey.api.json.POJOMappingFeature</param-name>
            <param-value>true</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>Example Web Application</servlet-name>
        <url-pattern>/service/*</url-pattern>
    </servlet-mapping>


また、以下のservlet定義を追加してください。

    <servlet>
      <servlet-name>JerseyJaxrsConfig</servlet-name>
      <servlet-class>com.wordnik.swagger.jersey.config.JerseyJaxrsConfig</servlet-class>
      <init-param>
        <param-name>api.version</param-name>
        <param-value>1.0.0</param-value>
      </init-param>
      <init-param>
        <param-name>swagger.api.basepath</param-name>
        <param-value>http://localhost:8080/AngularjsWithSwagger/service</param-value>
      </init-param>
      <load-on-startup>2</load-on-startup>
    </servlet>


初期パラメータ"api.version"はREST APIバージョン、 "swagger.api.basepath"はREST APIのURLを指定します。

3. リソースクラスの編集

もともと、クラス自体に@Pathアノテーションが付いていましたが

@Path("/employee")
public class EmployeeService {
    //

このようにjavax.ws.rs.Pathとcom.wordnik.swagger.annotations.Apiアノテーションを追加してください。

@Path("/employee")
@Produces(MediaType.APPLICATION_JSON)
@Api(value = "/employee", description = "社員に関するサービス")
public class EmployeeService {
    //略

また、もともとこんな感じでメソッドとURL・戻り値のMediaTypeを対応付けていましたが、

    @GET
    @Produces(MediaType.APPLICATION_JSON)
    @Path("/all")
    public List<Employee> getEmployees(){
    //略

以下のようにcom.wordnik.swagger.annotations.ApiOperation, com.wordnik.swagger.annotations.ApiResponses, com.wordnik.swagger.annotations.ApiResponseアノテーションを使ってREST APIドキュメント用の説明を書いてください。

    @GET
    @Produces(MediaType.APPLICATION_JSON)
    @Path("/all")
    @ApiOperation(value = "全ての社員情報を取得", notes = "条件指定せず、すべての社員情報を取得する", response = Employee.class)
    @ApiResponses(value = {
      @ApiResponse(code = 500, message = "サーバー内部エラー") 
    })
    public List<Employee> getEmployees(){

4. モデルクラスの編集

もともとこんな感じでJax-RBアノテーションを使用してJSONとの対応付けていましたが

@XmlRootElement(name = "employee")
@XmlAccessorType(XmlAccessType.FIELD)
public class Employee implements Serializable{
    
    /**内部的に使用されるUUID*/
    @XmlAttribute
    private String id;
    /**一意な社員コード*/
    @XmlAttribute
    private String employeeCode;

以下のように、com.wordnik.swagger.annotations.ApiModel、 com.wordnik.swagger.annotations.ApiModelPropertyアノテーションを使ってREST APIドキュメント用の説明を書いてください。

@XmlRootElement(name = "employee")
@XmlAccessorType(XmlAccessType.FIELD)
@ApiModel(value = "社員情報")
public class Employee implements Serializable{
    private static final long serialVersionUID = -7816174850279421158L;
    
    /**内部的に使用されるUUID*/
    @XmlAttribute
    @ApiModelProperty(value = "内部的に使用されるUUID", required=true)
    private String id;
    /**一意な社員コード*/
    @XmlAttribute
    @ApiModelProperty(value = "社員コード", required=true)
    private String employeeCode;

5. api-doc JSON生成を確認

さて、mavenでビルドしてwarファイル(AngularjsWithSwagger.war)をデプロイします。

http://localhost:8080/AngularjsWithSwagger/service/api-docs

へアクセスすると、

{"apiVersion":"1.0.0","swaggerVersion":"1.2","apis":[{"path":"/employee","description":"社員に関するサービス"}]}

のようなJSONを取得できるはずです。これはweb.xmlおよびリソースクラスのアノテーションで記述したREST API全体についての情報がJSON形式で出力されているものです。

また、

http://localhost:8080/AngularjsWithSwagger/service/api-docs/employee

へアクセスすると("employee"はリソースクラスのcom.wordnik.swagger.annotations.Apiアノテーションで指定されたパス)、swaggerが生成したREST APIに関する説明を示すJSON文字列が出力されるはずです。

6. swagger-uiでドキュメントを見る

さて、取得したJSONをユーザーフレンドリーな形で表示するには、swagger-uiを使用する必要があります。

とりあえず

GitHub - swagger-api/swagger-ui: Swagger UI is a dependency-free collection of HTML, Javascript, and CSS assets that dynamically generate beautiful documentation from a Swagger-compliant API.

からzipをダウンロードし、binフォルダの内容を適当な名前(swagger-ui)に変更し、webappsフォルダへ配置します。

その後

http://localhost:8080/swagger-ui/?url=http://localhost:8080/AngularjsWithSwagger/service/api-docs

へアクセスすると、

f:id:ka-ka_xyz:20141030003117p:plain

と、REST APIドキュメントが表示されます。各メソッドをクリックすると

f:id:ka-ka_xyz:20141030003145p:plain

のように、JSON構造やパラメータ、レスポンスコード情報等が表示されます。



追伸(業務連絡)東宝怪獣的なサーバー名に心当たりのある人は「これ書いたのはアイツか」とか思わずに素知らぬ顔でスルーしてください。

「金持ちは税率70%でもいいVSみんな10%課税がいい」感想

金持ちは税率70%でもいいVSみんな10%課税がいい: 1時間でわかる格差社会の増税論

金持ちは税率70%でもいいVSみんな10%課税がいい: 1時間でわかる格差社会の増税論

金持ちからもっと税金をとるべきか。

この、現代社会のきわめて重要なテーマについて、
4人の知性が激論を交わします。

クルーグマンとパパンドレウは、金持ち増税に賛成。

・スーパーリッチの税負担をちょっと増やしても経済に悪影響はない。
・平等な社会のほうがいろいろな面で望ましい、

というのがその根拠です。

一方のギングリッチとラッファーは、金持ち増税に反対。

・がんばって成功した人からむしりとってそうでない人に渡すような社会でいいのか。
増税しても、金持ちは賢い弁護士をやとって抜け道を探し出す。
増税の前に、政府を改革して効率化するべきだ、

というのがその根拠です。

税の問題は、つきつめれば、誰からとって誰に与えるか、という問題になります。
その問題を考えるときの主要な論点を網羅した本です。

この手のディベート本は初めて読むけど、「朝まで生テレビ」的なgdgdに陥らずに議論できてるってだけでもう羨望モンですよ。
で、争点な累進課税について。日本でも所得税最高税率は80年代中盤まで70%以上( 所得税 - Wikipedia )だったんですが、この辺は米国も同様に昔は結構最高税率が高かったという話が出てて意外。まあ、そういう制度が妥当かどうかという点はともかくとして、それでも社会は回る(むしろ日本でも米国でも結構景気がいい時代には最高税率が高い)という所は面白い。


あと、この本の笑いどころ。元米下院議長のニュート・ギングリッチ氏が「累進課税なんか止めて公平に課税しようぜ派」として熱弁をふるっているのですが。

[ギングリッチ] (前略。「金持ちからもっと税金を取るべきか?」という質問に対して)ビル・ゲイツの財産を没収すべきなのか?結局のところ、何十億も持っている必要は無い訳で。
 
[グリーン(インタビュアー)] そんな簡単な話ですか?
 
[ギングリッチ] 政府がやるのはそういうことですよ。政府は奪うんです。政府は権力であって、慈善団体では有りません。「僕等に手を貸してくれたらうれしいんだけど」なんて政府は言わないわけです。(後略)

すげーよ。元下院議長で大統領選候補にもなったガチな政治家が、

「政府は奪うんです。」

発言ですよ。もしホントにそう思ってるんなら政治家になって泥棒の片棒を担ぐなんてことやらずに「アメリカリバタリアン革命軍」でも作ってゲリラ活動するべきでは?
(まあ、「行政府と立法府は違う。行政府の専横を抑えるのが立法府なのだ」って理屈かもしれないけど、「奪った」お金の分配方法について議論する場の元責任者がそういうこと言ってもな~)

森岡浩之「突変」感想(ネタバレ有り)

突変 (徳間文庫)

突変 (徳間文庫)

関東某県酒河市一帯がいきなり異世界に転移(突変)。ここ裏地球は、危険な異源生物(チェンジリング)が蔓延る世界。妻の末期癌を宣告されたばかりの町内会長、家事代行会社の女性スタッフ、独身スーパー店長、ニートのオタク青年、夫と生き別れた子連れパート主婦。それぞれの事情を抱えた彼らはいかにこの事態に対処していくのか。異様な設定ながら地に足のついた描写が真に迫る、特異災害(パニツク)SF超大作!

異世界にいきなり放り込まれる系SF。


ある時期から、ある程度の広さの地域が消失し、かわりに現在の地球とは全く異なる凶暴な生態系へ置き換えられるという「突変」現象が発生するようになった世界。元々存在していた場所は、その全く異質な生態系を持つもう一つの(おそらく平行世界上の)地球に存在する同じ地域と置き換えられてしまうと推定されています。
S・キング「霧」( スケルトン・クルー〈2〉神々のワード・プロセッサ (扶桑社ミステリー) 収録)あたりとシチュエーションは似てるかもしれない。


過去に人口密集地(関西圏中核部とか)がまるごと「突変」してしまったこともあり、それなりの規模の人口・産業基盤が「突変」先の地球上に存在し、社会を維持している可能性はあります。ただし、その平行世界と連絡を取る方法は全く存在していないため、「突変」先の世界でどのような社会が築かれているのかは全くわかっていません。

この「突変」現象は現実世界でいうところの巨大地震のように、稀にしか発生しないものの防ぎようの無い天災として認識されています。なので市役所レベルで外の地域と切り離されることを想定した非常食糧が備蓄されていたり、「突変」先の生物へ対応するため軽火器を扱う「防除団」が組織されていたりといった行政レベルでの対策は取られていますが、かといって今日明日にも自分たちが「突変」してしまうという切迫感はあんまり有りません。

で、どうという事もない平凡な郊外ベッドタウンでの平凡な日常の中で「突変」現象が発生し、否応なく異世界でのサバイバルが始まることに・・・・・・

面白いのでオススメだけど、ちょっと気になる点もあるので以下ネタバレ。

続きを読む

javaScriptとノーブレークスペースについてあれこれ

ノーブレークスペースについて

ノーブレークスペースってなんぞやというと、Web系の人にとってはお馴染みなはずの実体参照"&nbsp;"で表示される空白文字です。Unicode符号は0x00A0。
通常の半角スペース文字は0x0020なので、見た目は同じ空白文字でも実態は違う文字です。

細かいことはwikipedia参照。
ノーブレークスペース - Wikipedia

何でこんな事を書いてるかというと

<!DOCTYPE html>
  <html>
    <head>
      <meta charset="UTF-8">
    <head>
  <body>
    <div id="example">This&nbsp;is&nbsp;a&nbsp;pen</div>
  </body>
</html>

というhtmlに対して

var acutualText = document.getElementById("example").textContent;
var expectedText = "This is a pen";
assertEquals(acutualText, expectedText);

みたいなテストを書いてて通らなかった事がきっかけ。

見分け付ける方法

取り敢えず、文字列をユニコード符号で見てみましょう。

こんな感じのhtmlをブラウザで表示し

<!DOCTYPE html>
  <html>
    <head>
      <meta charset="UTF-8">
    <head>
  <body>
    <div id="whitespace">This is a pen</div>
    <div id="nbsp">This&nbsp;is&nbsp;a&nbsp;pen</div>
  </body>
</html>

コンソールから以下を実行

String.prototype.toCharCode = function (){
    var rtn = "";
    var myself = this;
    this.split("").forEach(function(s, i){
        var c = myself.charCodeAt(i).toString(16).toUpperCase();
        rtn += " U+" + (c.length === 2 ? "00" + c : c);
    })
    return rtn.length > 0 ? rtn.substr(1):"";
}

//ホワイトスペース区切り文字列
var whitespace = document.getElementById("whitespace").textContent;
//ノーブレークスペース区切り文字列
var nbsp = document.getElementById("nbsp").textContent;

console.log("ホワイトスペース(U+0020)区切り:   " + whitespace.toCharCode());
console.log("ノーブレークスペース(U+00A0)区切り: " + nbsp.toCharCode());

結果はこんな感じ

ホワイトスペース(U+0020)区切り: U+0054 U+0068 U+0069 U+0073 U+0020 U+0069 U+0073 U+0020 U+0061 U+0020 U+0070 U+0065 U+006E

ノーブレークスペース(U+00A0)区切り: U+0054 U+0068 U+0069 U+0073 U+00A0 U+0069 U+0073 U+00A0 U+0061 U+00A0 U+0070 U+0065 U+006E

太字強調した部分は区切り文字ですが、ちゃんとノーブレークスペース文字が"U+00A0"として取得出来ている事が分かります。

空白文字の違いなんかどうでもいいからさっくり文字列比較したい

正規表現の"\s"はホワイトスペース文字(U+0020)だけに限らず空白文字全般にマッチするので、String.prototype.replace()を使ってホワイトスペースへ置換するのが一番手っ取り早いかと。

例:

//ホワイトスペース区切り文字列
var whitespace = document.getElementById("whitespace").textContent;
//ノーブレークスペース区切り文字列
var nbsp = document.getElementById("nbsp").textContent;

var nbsp_replaced = nbsp.replace(/\s/g, " ");

console.log("ホワイトスペース(U+0020)区切り:   " + whitespace.toCharCode());
console.log("ノーブレークスペース(U+00A0)区切り: " + nbsp.toCharCode());
console.log("置換後: " + nbsp_replaced.toCharCode());
console.log("置換後に一致するか? " + (whitespace === nbsp_replaced));

結果はこんな感じ

ホワイトスペース(U+0020)区切り: U+0054 U+0068 U+0069 U+0073 U+0020 U+0069 U+0073 U+0020 U+0061 U+0020 U+0070 U+0065 U+006E

ノーブレークスペース(U+00A0)区切り: U+0054 U+0068 U+0069 U+0073 U+00A0 U+0069 U+0073 U+00A0 U+0061 U+00A0 U+0070 U+0065 U+006E

置換後: U+0054 U+0068 U+0069 U+0073 U+0020 U+0069 U+0073 U+0020 U+0061 U+0020 U+0070 U+0065 U+006E

置換後に一致するか? true

ノーブレークスペース(U+00A0)が全てホワイトスペース(U+0020)へ置き換えられ、文字列比較も一致することが確認できました・・・と、ここまではChrome上での話。

ブラウザごとのノーブレークスペースの扱い

jsでテキストノードの値を取得するには、大抵textContentかinnerTextを使うかと思いますが、各ブラウザごとにノーブレークスペースの扱いがどうか見てみましょう。

Chrome Firefox IE11
textContent 0x00A0 0x00A0 0x00A0
innerText 0x00A0 (innerTextは未サポート) 0x0020


IE11ではinnerTextでテキストを取得した時に、ノーブレークスペース("0x00A0")がホワイトスペース("0x0020")として取得されます。textContentがサポートされたのはIE9以降(参照
Node.textContent - Web API インターフェイス | MDN
)となるため、textContentが使えないレガシーIEでノーブレークスペースをノーブレークスペースとして扱うのは手間がかかりそう(innerHTMLで文字列"&nbsp;"として取るか)。

「エリア51 世界でもっとも有名な秘密基地の真実」感想

エリア51 世界でもっとも有名な秘密基地の真実 (ヒストリカル・スタディーズ)

エリア51 世界でもっとも有名な秘密基地の真実 (ヒストリカル・スタディーズ)

「NYタイムズ・ベストセラー・リスト」に11週連続でランクインした全米ベストセラーが日本上陸! エリア51の知られざる数々の事実、核や人体実験などアメリカ軍事史の闇に迫る渾身のノンフィクション! ◆「エリア51」はUFO墜落・宇宙人の遺体回収で知られる「ロズウェル事件」の舞台として世界的に有名だが、実際はネヴァダ州の砂漠地帯にある米最高機密の軍事施設である。衛星写真でも隠せないほど広大な基地にもかかわらず、いまも当局は存在を伏せている。 ◆ジャーナリストの著者は、ふとしたきっかけからエリア51で働いていたという人物と知りあい、取材を開始。以後、基地に勤務していた20人近い関係者、プロジェクトに関わった50人以上の科学者、基地近郊の30人を越える居住者などからの証言を得て全容解明に挑戦。その結果、冷戦下の軍事秘史が明らかになった。 ◆貴重なモノクロ写真を約60点収録

学研「ムー」矢追純一UFOスペシャル方面で常に注目を浴びてきた、世界で一番有名な(でも具体的に何をやってるのかさっぱり見えてこない)秘密基地「エリア51」についてのノンフィクション。

まあ、第二次大戦後のドイツから(倫理的にヤバい研究してた人を含め)科学者・技術者をかき集めてきた「ペーパークリップ」作戦、秘密核実験、U-2偵察機の開発、ソ連上空偵察飛行作戦、A-12オックスカート偵察機SR-71ブラックバードのCIA版)開発、偵察機開発を巡る空軍とCIAとの綱引き、核戦争を想定した極秘生体実験、熱核推進ロケット開発、ロズウェル事件の真相等等・・・エリア51とは直接関係無い話も入ってますが、冷戦の「闇」の部分を関係者の豊富な証言を元に再構成してみたという感じの本です。

ただまあ引っかかるのはやはり"ロズウェル事件の真相"(と著者が主張している)話でして。
ソ連ホルテン兄弟の設計にヒントを得て開発した超絶技術の飛行機(空中静止可能で、アメリカ本土まで飛べるほど航続距離が長い。ホルテン兄弟ってそんな超絶技術持ってたっけ?)に生体改造されたパイロットを載せてネバダくんだりまで飛ばしたが結局は墜落し、エリア51に収容されたって話なんですがね・・・著者は「アメリカとしては米本土にソ連機の侵入を許したと認める事が出来なかったし、そもそも自分たちも相当胡散臭いことをしていたから藪蛇にならないように口をつぐんだのだ」と言ってますが、どうにもこうにも、不合理な点を全てソ連スターリンに押し付けただけという感じがします。
普通に考えれば、当時の技術水準を大幅に凌駕しているような貴重な機体を、わざわざ米本土まで飛ばして墜落させたりとかしたらソ連側では政治的大事件になっていたでしょう。それに、後の「スターリン批判」の流れで格好のネタになったはずです。著者的には「いや墜落したことも含めて高度な心理作戦なんだよ!」と主張してますが・・・キバヤシさん乙です。
また、空中で自由に静止出来て、かつソ連領から米本土ネバダまで飛べるような機体を(研究用の一品物であっても)開発できるような技術力があれば、後の実用VTOL機Yak-38フォージャーがなんであんな残念な出来にしかなってないのかとか、合理的に考えると突っ込みどころ満載です。

まあ、"ロズウェル事件の真相"としてセンセーショナルな話を盛り込んでおけば売上的な面で有利だとは思いますが、著者のノンフィクション作家としての誠実さにはかなり疑問を感じます。ほんとうに、他の部分とは違ってこの箇所だけは、その時点での、あるいは現在の技術的・政治的動向とのつながりが全く無いんですよね。


逆にこの点さえ目をつぶれば、当事者の証言による冷戦の裏面史という内容は素晴らしいんですが・・・でも何処まで信用できるのかなあ。
どう考えてもおかしな話を混ぜ込むこと自体が著者による「この本に書かれていることは全て疑え」というメッセージなのだという読み方も可能とは思いますが、その手の陰謀論まっしぐらな読み方はあんまり好きじゃない。

遠藤周作「ブラック大名家に勤めてるんだが、もう俺は限界かもしれない」………じゃなくて「反逆」感想

反逆(上) (講談社文庫)

反逆(上) (講談社文庫)

1度でもいい。上さまの……あの顔に……怯えの影を見たい――己れの力に寸分の疑いをもたぬ信長の自信、神をも畏れぬ信長への憎しみ、恐れ、コンプレックス、嫉妬、そして強い執着……村重、光秀、秀吉の心に揺らめく反逆の光を、克明に追う。強き者に翻弄される弱き者たちの論理と心理を描ききった歴史大作。

反逆(下) (講談社文庫)

反逆(下) (講談社文庫)

なんたる上さまの冷酷――命乞いをする幼な子の首を刎ねた信長、秀吉と光秀、2人の心理的競い合いを楽しむ信長。信長を討つことは天の道!光秀は長い間心に沈澱していた反逆の囁きから解き放たれた……。戦いの果てにみた人間の弱さ、悲哀、寂しさを、そして生き残った村重、右近らの落魄の人生を描く。

いやー、面白い面白い。荒木村重明智光秀松永久秀といった一癖も二癖もある織田家家臣が、相互不信と嫉妬、信長への愛憎、「毛利なら、毛利ならきっと何とかしてくれるはず!」という希望的観測、そして何より信長から「使い捨てされる」ことの恐怖に振り回されて反逆にへと至る心理描写が素晴らしい。
また、反逆に至らないまでも腹に一物ある豊臣秀吉や、裏表無くまっすぐ生きようとしても周囲の事情により色々と抱え込んでしまう高山右近、あるいは歴史に名を残すこと無く消えていった人々の悲壮な思い等の描写についても、中々面白く描かれています。

で、上で書いた"「使い捨てされる」ことの恐怖"なんですが、この辺は

信長と消えた家臣たち―失脚・粛清・謀反 (中公新書)

信長と消えた家臣たち―失脚・粛清・謀反 (中公新書)

でも、反乱を誘発した要素の一つではないかとされており、フィクションの"味付け"として読み流すには勿体無い視点だと思います。

で、人材使い捨てといえば昨今のブラック企業問題ですが、いやほんとに当時の人から見たら「ブラック大名家」だったんじゃないですかね織田家って。まあ、他の勢力が今日的な意味で「ホワイト」だったかって言うとかなり微妙だと思いますが。