コラム

CTC教育サービス・ホーム　＞　コラム　＞　スーパーエンジニアの独り言　＞　第62回　籠の鸚鵡

スーパーエンジニアの独り言

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第62回　籠の鸚鵡 2016年11月

先々月に上梓されたハードカバー本で「籠の鸚鵡」"Parrot in a Cage" という小説を探すために週末に数件の本屋を梯子する羽目に陥りましたが、今現在は見つけ出しており無事に手にしております。

「籠の鸚鵡（かごのおうむ）」"Parrot in a Cage" の著者は「辻原登」(Noboru Tsujihara) という方です。

『プロローグ』：

不勉強で恥ずかしいのですが、辻原昇氏の作品を読んだことは無いです。ですがモノクロームの背景に薄手の生地で誂えた（あつらえた）真っ赤なドレスを装う「ファム・ファタール」"Femme Fatale" が現れる物語の場面設定を妄想して勝手に筆者好みだと理屈つけたので是非読みたいという欲求が沸いてきました。そこはかとなく「フィルム・ノワール」"Film Noir" の香りがしたからです。

知らない作家さんの書籍を突然見つけて惹かれた切欠の件（くだり）なのですが、週末に気分をリフレッシュするためと身体を少しは動かそうと近場の高尾山を目指して家を飛び出したのですが、到着してみるとそこはまるで原宿の様相を呈しており身動きできないほどの混雑振りで困惑してしまいました。久しぶりの晴れ間と紅葉の色づき具合とミシュランによる効果が絶大であったことを思い知らされました。

時間を遡りましてその困惑の表情を醸し出す少しだけ前、目的地の混雑など露知らず意気揚々と高尾山行きの電車に乗り込む前に道中の暇潰しにコンビニで購入した新聞を心地よく揺れる車中で眺めておりました。その日本経済新聞の紙面にあった新刊書籍レビュー欄に「籠の鸚鵡」が表紙の写真入りで掲載されており、その書籍タイトルが目に留まったのです。

いつもの様にコラムのタイトルを名付けるのに四苦八苦していた矢先のタイミングであったことが更に購買意欲へと駆け出した要因であったのは間違いありません。

このタイトルの何が琴線に触れたのかと申せば、表紙の写真を見た際「龍」に「竹」冠で「籠」（かご）と読むのだと改めて気づかせてくれたことです。「籠」という漢字を見つめると「かごめかごめ」（籠目または籠女）という童謡を思い出さずにはいられません。

「かごめかごめ」と言えば「悪魔の手毬唄」、「岸惠子」と立て続きに連想して思わず「石坂浩二」が扮する手入れしていない頭髪を掻き毟って（かきむしって）は頭垢（ふけ）を辺り構わず飛ばしまくる「金田一耕助」という探偵が活躍する「横溝正史」シリーズの映画のシーンを彷彿させられてしまうのは筆者だけではない筈です。これは、何某かの曰く（いわく）と謎解きがありそうだと勝手に勘繰ってしまったのです。

この話の続きは本題の終わりに差し上げることにします。本題に入りましょう。

『第二弾』：

さて今回ですが、前回（第一弾コラム『第61回カネゴンの繭』）からの流れを引継ぎます。
第二弾を「籠の鸚鵡」（かごのおうむ）と題したのは、メモリ領域という「籠」の中を彼方此方（あちこち）に行き来するオブジェクトを「鸚鵡」に擬えて（なぞらえて）譬え（たとえ）とさせて頂いたのです。譬えで「鸚鵡」が受容されたのは「空飛ぶモンティ・パイソン」"Monty Python's Flying Circus" には「死んだオウム」"Dead Parrot" という有名なスケッチがあるのが起因してシナプスで神経細胞伝達物質が放出されたからでもあります。

前回コラムでは、"Ruby" にフォーカスしてインタプリタ内でのメモリ管理はどうなっているのかという話題を皮切りにインタプリタに内蔵されているガベージコレクション "Garbage Collection, GC" という機能、つまり不要になったオブジェクトを探してメモリ領域を解放してくれる「ゴミの車」（ガベージコレクター、Garbage Collector）の車種（アルゴリズム）についても調査してみました。

今回は前回のおさらいから始めて所謂（いわゆる）もう一つの「軽量プログラミング言語」"Lightweight Language, LL" である Python でのガベージコレクションはどうなっているのか？という方面について調べてみようと思っています。

『Ruby のガベージコレクション』：

まずは前回のおさらいから始めましょう。

Ruby (MRI, CRuby) のインタプリタでは当初より「マーク・アンド・スイープ」"Mark and Sweep" 方式の「ガベージコレクター」"Garbage Collector" が採用されていました。

「マーク・アンド・スイープ」"Mark and Sweep" は最初に考え出された基本の方式であり（後述の問題が発生しない）決定打とも言える方策です。先ず「マーク・フェーズ」では、ルート（オブジェクト）から辿ることが出来る（到達可能な）使用中のオブジェクトに印（マーク）を付けていきます。次に「スイープ・フェーズ」では、マークされていないオブジェクトをゴミとして掃き出す（スイープ）して綺麗にするのです。この二つのフェーズを繰り返すことで「ゴミ収集」（ガベージコレクション）を行うのです。

この方式では確実にゴミが回収出来る利点がありますが、欠点としてマーク・フェーズではすべてのオブジェクトを「総なめ」（オブジェクト・グラフ全体を走査）するために時間が掛かることがあります。更にはマークされなかったオブジェクトをスイープするのにもこれまた同様に時間が掛かってしまいます。二つのフェーズが全部完了するまで終わらないのです。これを称して「双頭の怪物」"Two-Headed Monster" と揶揄する人も居る様子です。

実際のアプリケーションでの実行でもGCが走るタイミングが問題となる可能性があり、マークしてスイープしてGCに掛かりっきりになってしまい長くアプリケーションが止まってしまう（停止状態）ことがあります。これは "Stop the World"（世界が静止する日）とも呼ばれ大きな問題となります。

「世界が静止する日」"The Day the Earth Stood Still" という直面する危機を解消するため様々な工夫が Ruby のガベージコレクターには既に加えられています。

その解決策の一つとして採用されたのが「世代別ガベージコレクション」"Generational GC" です。
メモリ領域を二つの世代 (Generation) に分離して管理する手法です。世代別に分離することでマークする対象の寿命（長く生存している古いオブジェクトと産まれては直ぐに破棄される新しいオブジェクト）が認識され、同時に探索対象が絞られて減るという効果が期待できるのです。これによりマークするのが軽くなる効能が期待できます。また世代別にGCが用意されて新世代 (New Generation) 用途を「マイナーGC」"Minor GC"、古い世代 (Old Generation) 用途を「メジャーGC」"Major GC" として各々の役割を担います。ほとんどのオブジェクトはマイナーGCが走るだけでゴミ収集が行われるので大幅な高速化が期待できるのです。

更には「インクリメンタル・ガベージコレクション」"Incremental GC" が採用されました。
これも「マーク・アンド・スイープ」の処理を細かくすることで長く中断するのを回避しようとする試みです。どのようにインクリメンタル（増分）で処理するのかというと、今までマークされているか？されていないか？という二値判定だったマーク処理に「作業中」という中間判定を加えるという方策です。これによりGCを細切れにして（一遍に行うのでは無く）ちょっとずつ動かすことが可能となってアプリケーションの中断時間を短くするという作戦です。マーク "Mark" もスイープ "Lazy Sweep" もちょっとずつ行うので停止時間が短くなりますが、トータルでは同じ時間ゴミの車が走ることになります。これを実現するのに必要なことがありまして、一遍に GC を行うのではなく中断して再開を繰り返すために作業中の場所を保護する仕組み「ライトバリア」"Write Barrier" が必要になります。

ここでは二つの大きな改良部分を記載しましたがこれ以外にも細やかな改修が加えられており、現行の Ruby ではアプリケーションを快適に実行できるようになっています。

ご紹介した内容は、Ruby オフィシャルサイト内に掲載されている「るびま」(Ruby magazine) の複数の記事に詳細に記載されていますので、ご興味あれば是非サイトをご覧になってくださいませ。

『Python のガベージコレクション』：

では今回の本題に参りましょう。Python インタプリタでのメモリ管理について探ってみようと思います。

Python (CPython) のインタプリタでは、「参照カウント（リファレンス・カウント）」"Reference Counting" によりガベージコレクションが実行されています（どうやら CPython ではメモリの割り当ても自前で実装しているのが、この方式を選択していることに関係しているらしいです）。

「参照カウント」"Reference Counting" ではオブジェクト側に自分自身が参照されている数を格納するカウンターを設置しておいて参照が増減する毎に数値を書き換えるというやり方です。

Python のオブジェクトを表現する構造体 (PyObject) のメンバーに含まれる "ob_refcnt" という変数が「参照カウンター」"Reference Counter" となります。該当オブジェクトが参照される毎にリファレンス・カウンターである ob_refcnt をインクリメント（増分）し参照数を増やす、或いはデクリメント（減分）し参照数を減らすという操作が随時行われます。参照数が「0」（ゼロ）になれば誰からも見られていないのですから該当オブジェクトを破棄することで占有していたメモリ領域が解放されるという仕組みです。

この方式でのメリットは幾つかの点がありますが、シンプル（単純）が故にガベージコレクションが高速に動作するという点が挙げることが出来ます。その都度で破棄が実行されるので少ないメモリで円滑に実行できる点やメモリ解放が分散されて行われるためにマーク・アンド・スイープで問題となった "Stop the World" といった長い停止時間の発生を抑制できる点も魅力的です。

ですがこの「参照カウント」方式には大きな欠点があります。

「循環参照」"Circular Reference" による「メモリ・リーク」"Memory Leak" が顕在化する場合があるのです。まず「循環参照」"Circular Reference" についてですが、これは簡単に理解が出来ます。コンテナ・オブジェクトが相互参照しているような場合です。

# create a circular reference list object
crlo = []
crlo.append(crlo)
del crlo

例えば上記の様に、リストを生成してその要素に自分自身が居る訳ですので自分自身を参照するような循環参照となっています。リスト以外にもタプルや辞書、関数、自作したクラスのインスタンスなどのコンテナ・オブジェクトで循環参照となることが容易に起こり得ます。

そして問題は、このサンプルコードで最後に削除を行っているので、このリストを二度と使用することは出来ませんがリスト自体はメモリ上に残ってしまうのです。循環参照しているが故に参照カウントが「0」にならないからです。これが循環参照に因って問題が顕在化した例であり、つまりは参照カウント方式での大きな欠点となります。

『循環参照ガベージコレクター』：

現行の Python インタプリタでは前述の問題を回避するために「循環参照ガベージコレクター」"Circular Reference Garbage Collector" が参照カウントを補うために併用されています。

理屈としては循環参照が発生するコンテナ・オブジェクトに対して GC 追跡用のヘッダ情報を組み込みます。このヘッダ情報には代表選手である "gc_refs" フィールドが有りオブジェクトが「追跡可能か否か」といった情報をカウンタ（及びフラグ）で保持することで発見するという作戦です。

大まかなあらすじとしては、この "gc_refs" は参照カウントがシナリオに沿って増減設定されると操作 ( update_refs(), subtract_refs() ) がされますので「1」以上であれば参照先がある筈です。GC ヘッダ情報を使って参照先を探し出しますが、見つからなければ「到達不可能オブジェクト」（循環参照オブジェクト）と見做して（みなして）リスト化します。この「ゴミ」リストを基にして掃きだして綺麗にします。

つまり参照されていない「ゴミ」オブジェクトを探し出すという方策でマーク・アンド・スイープの逆ロジックを使うのです。それに加えてここで「ゴミ」をリスト化する際に世代別GCを使うのだそうですが、これは循環参照GCを二度生き残ったオブジェクトを洗い出すためで二回調査して本当に到達不可能と判断してから安全に「ゴミ」を掃きだすための工夫となっているのです。

上記の記載は、Python Committer （コミッター）である Neil Schemenauer が解説する "Garbage Collection for Python" が公開されておりこれを拝読して理解しました。原文はそちらをご覧ください。

現行の Python では搭載されている循環参照ガベージコレクターの一部を制御可能にする GC インターフェース・モジュールが装備品とされており徐々に充填されています。
下記にガベージコレクタ・インターフェースを利用したサンプルコードを記載します。サンプルを実行する目的はガベージコレクターの挙動を拝見したいのでタイミングを診る為にも対話モードでコードを動かしてみます。

C:\garbage_collection> python
Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import gc
>>>
>>> gc.set_debug(gc.DEBUG_UNCOLLECTABLE | gc.DEBUG_STATS)
>>>
>>> gc.disable()
>>> gc.isenabled()
False
>>>
>>> # create a circular reference list object
... crlo = []
>>> crlo.append(crlo)
>>>
>>> print(crlo)
[[...]]
>>> gc.get_stats()
[{'uncollectable': 0, 'collected': 74, 'collections': 30}, {'uncollectable': 0,
'collected': 0, 'collections': 2}, {'uncollectable': 0, 'collected': 0, 'collect
ions': 0}]
>>> gc.collect()
gc: collecting generation 2...
gc: objects in each generation: 747 2794 9179
gc: done, 0.0160s elapsed
0
>>>
>>> # delete a object
... del crlo
>>> gc.get_stats()
[{'uncollectable': 0, 'collected': 74, 'collections': 30}, {'uncollectable': 0,
'collected': 0, 'collections': 2}, {'uncollectable': 0, 'collected': 0, 'collect
ions': 1}]
>>> gc.collect()
gc: collecting generation 2...
gc: objects in each generation: 276 0 12672
gc: done, 1 unreachable, 0 uncollectable, 0.0000s elapsed
1
>>>
>>> gc.get_stats()
[{'uncollectable': 0, 'collected': 74, 'collections': 30}, {'uncollectable': 0,
'collected': 0, 'collections': 2}, {'uncollectable': 0, 'collected': 1, 'collect
ions': 2}]
>>>
>>> exit()
gc: collecting generation 2...
gc: objects in each generation: 137 0 12933
gc: done, 0.0150s elapsed
gc: collecting generation 2...
gc: objects in each generation: 256 0 12840
C:\garbage_collection>

上記サンプルコードを使って例示したのは gc モジュールを使用することで循環参照ガベージコレクターの機能（の一部）を制御が出来ることを試みました。

コード冒頭で設定しているデバッグ・フラグは、回収不能 (UNCOLLECTABLE) オブジェクトの情報と検出中の統計情報を出力する設定です。回収不能というのは到達不能でガベージコレクションでも解放できないものを指します。

コードの指示内容は、gc.disable() メソッドで自動ガベージコレクション（デフォルト有効）を無効にしておき、先ほど例示した循環参照オブジェクトを生成し削除することで到達不能 (Unreachable) オブジェクトを恣意的に産み出します。その後 gc.collect() メソッドで任意のタイミングで「ゴミの車」（ガベージコレクター）を走らすことが出来ます。

再度明示しますが、"gc" は循環参照ガベージコレクターに対応したモジュールですので gc.disable() で停止するのは循環参照ガベージコレクターです。参照カウントだけでオブジェクトの破棄が行われているのは通常通りで変わりません。

サンプルでは意図的に循環参照となるオブジェクトを生成して破棄をしたのですが、ちゃんと掃除（ガベージコレクト）されているのが確認できました。今回は任意のタイミングで確認したかったためにゴミの車を手動で発進させましたが、これら循環参照のゴミは遅延検出でゴミの車は自動運転で走るので気にしなくて良い様子です。もしかすると、かなり昔の Python であれば「二度と使われることの無い」このリストを解放することは叶わなかったかもしれないのですが、現在ではちゃんとごみ収集が為されるのが確認できました。またこのサンプルでは副次的に循環参照ガベージコレクターはオブジェクトを三世代に分類した世代別GCの手法を採用しているのも垣間見ることもできました。また今度の機会に探ります。

ここで記載した内容については公式ドキュメント（データモデル、及び、ガベージコレクタ・インターフェース）に記載がありますので是非ご覧になって下さい。

併せて Python インタプリタがメモリ管理に於いてどのような実装しているのかの詳細を御知りになりたい場合には、「ガベージコレクションのアルゴリズムと実装」（著者：中村成洋、相川光、監修：竹内郁雄）を御一読されることをお薦めさせて頂きます。RubyのGC実装をご担当されている中村成洋氏が著者という事もあり、難解なお題目を噛み砕いて紹介されておりとても分かりやすいです。前回にも紹介させて頂きましたが再度のお薦めです。

現行の CPython は循環参照ガベージコレクターと参照カウントのガベージコレクションを採用しているので心配なく利用できることが理解できました。さらに未来の Python ではより良い優れた方法で実装されるのかとも想像されます。

『核心を突くために』：

Ruby (CRuby) インタプリタと Python (CPython) インタプリタでのガベージコレクションというお題目で色々と眺めてきました。Ruby と Python 各々で課題に取り組んでいる実装があることを確かめることで基本アルゴリズムとなるマーク・アンド・スイープと参照カウントを採用したことでの大きな違いも露呈しました。同じ LL でも実装（方策）に寄って内情は異なるのを診ることが出来た様にも思います。

今まで難解だからと敬遠し続けてはいましたが、地道ではありますが少しだけGC と仲良くなれたように思います。

ですが今回も大枠だけの理解に留まり仔細な箇所は飛ばしましたし、新たなキーワードもたくさん登場してきました。勉強のために拝読した「ガベージコレクションのアルゴリズムと実装」には他の主要アルゴリズムや多言語での実装などについて多岐に記載がありましたが、それらの理解までには遠く及んでいません。それに加えて筆者が知りたい本丸（未だ内緒にしておきます）には未だ辿り着いていません。これらは時間を経てから再度取り組むべき課題とさせて頂きます（前回にも宿題があった筈ですが、その上に積みます）。次回以降にあるかもしれない続きの（仮称）第三弾まで気長にお待ち下さいませ。

古（いにしえ）からの魔法であるガベージコレクションの秘密を解き明かすにはもう少し準備が必要みたいです。もしも、ジェットモグラをサンダーバード2号のコンテナに積んでいれば、もっと速く「核心」（コア）に近づけたのかもしれませんが、生憎ジェットモグラが内蔵されたコンテナの持ち合わせがありません。
次回からはもう少し準備（基礎）万端にして望みたいと思っています。乞うご期待です。

『エピローグ』：

龍は水神を象徴します。水（神）を竹で組んで覆い捕まえるというのは愚かな行為でしょう。「籠」で水を汲むことは出来ないからです。書籍タイトルである「龍」に「竹」冠で「籠」（かご）をいう漢字の成り立ちとその由来へと想いを馳せました。

この「籠の鸚鵡（かごのおうむ）」"Parrot in a Cage" というタイトルに魅入られて手にした訳ですが、本書の「籠の鸚鵡」というタイトルは「南の花嫁さん」という歌謡曲の歌詞から由来していました。物語序章にその歌の歌詞（作詞：藤浦洸）そのものが文中に登場していたのです。

引用された楽曲「南の花嫁さん」の歌い手は女優の「高峰三枝子」(Mieko Takamine) です。彼女は「歌う映画女優」の走り（第一号）だったのだそうです。サイレントからトーキーへと時代は移り変わり始めたばかりのこの頃、ビジュアルは良いけど台詞を喋らすとまるで駄目という一芸（専門職）の時代にあって「銀幕のスター」が「歌い手」も兼ねてスポットライトを浴びたという意味では先んじた草分け的な存在第一号だったと考えられます。

若かりし頃の彼女は、嘸かし（さぞかし）美麗な風貌であったろう事は想像に違わないのでしょうが、筆者が思い出す高峰三枝子と言えば「犬神家の一族」"The Inugamis" （昭和51年、1976年リリース）の存在感は忘れ難いものです。そしてこの高峰三枝子というミッシング・ピース（失われた欠片）を時間軸に連ねて埋めることで筆者が直感的にインスパイアされた短絡的イメージと符合して終戦後の昭和初期を舞台とした横溝正史の金田一耕助シリーズとして勝手にイメージしたパズルとして帰結しました。脳内イメージのビジュアルとしては「犬神家の一族」の「佐清」（すけきよ）が被っていた白いラバーの仮面が気味悪く毒々しい強い印象を与えてくれたそれが残像として定着しました。パズルは完成しました（但し、「籠の鸚鵡」はミステリーでも探偵小説でもありません）。

しかしながら、実は本書のタイトルの由来となった「南の花嫁さん」（昭和17年、1942年リリース）という歌自体の存在を筆者は知りませんでした。ですから、本当にヒット曲なのかどうかと疑心暗鬼を生じたので当時「真知子巻き」（映画「君の名は」で「氏家真知子」役の「岸惠子」がストールを頭に巻くスタイル）を好んでいたお袋さん（昭和15年製、1940年リリース）に電子メールで訊ねてみたところ「よく知らない。」と素っ気無く言っておりました。
仕方なく YouTube で「南の花嫁さん」を探すとリリース後年の映像で艶を増した高峰三枝子が歌謡ショーで美声を披露しているのを聴くことができました。きっと空前の大ヒットだったことでしょう。この映像に続いて慰問で特攻隊の前で「湖畔の宿」を唄った事を語っているのも観ました。死んだ親父さん（昭和11年製、1936年リリース）なら歌謡曲が好きだったので知っていたのかとも思います。筆者（昭和40年製、1965年リリース）が「花嫁さんの唄」と聞くと「小柳ルミ子」が歌う「瀬戸の花嫁」（昭和47年、1972年リリース）を想起する世代です。

加えて筆者世代にとって「歌う映画女優」といえば「薬師丸ひろ子」(Hiroko Yakushimaru) となります。薬師丸ひろ子が主演した映画の主題歌「セーラー服と機関銃」"Sailor Suit and Machine Gun"（昭和56年、1981年リリース）が大ヒットしたのです。アイドル全盛、歌謡曲全盛のこの時代でバロメーターとも言えるテレビ番組「ザ・ベストテン」でも上位にランクインされていました（彼女の出演はありませんでした）。

薬師丸ひろ子を牽引車として後に続く「角川三人娘」（原田知世、渡辺典子）も彼女達各々が主演する映画の主題歌を歌うようになったのは「セーラー服と機関銃」の大ヒットのお陰です。更には後年、「セーラー服と機関銃」は、長澤まさみや橋本環奈が主演して何度かリメイクされたのでご存知の方も多いでしょう。彼女達も同じく主題歌を歌っています。

連続テレビ小説「あまちゃん」では薬師丸ひろ子は同時代のアイドル「小泉今日子」と競演して音痴の歌手「鈴鹿ひろ美」役で歌っていたのでご存知の方も多いと思います。「あまちゃん」では薬師丸ひろ子が演じる役をシンボルとした虚構であるドラマのストーリーと過去に起こった現実世界を意図的に混同（混乱）させる秀逸な設定は流石にクドカン（宮藤官九郎）ならではの脚本だと想います。

ですが昨今の「歌う映画女優」の代表の一人といえば「柴咲コウ」(Ko Shibasaki) でしょうか。彼女は多数の映画、テレビドラマに出演する傍らにラジオが切欠でリリースしたレコードは玄人跣（くろうとはだし）の歌唱力と世界観を醸し出しており「演技」も「歌唱」も双方に才能を発揮する様は「天は二物を与えず」この諺（ことわざ）に例外が存在することを示しています。そういえば、柴咲コウは「真田丸」に続く大河ドラマ「おんな城主直虎」の主演に抜擢されたポスターを今日拝見しましたが、「千と千尋の神隠し」"Spirited Away" の「ハク」"Haku" みたいな髪型で凛々しい御姿になられておりました。

もう一人の「歌う映画女優」代表選抜としては「満島ひかり」(Hikari Mitsushima) が候補に挙げることができるでしょう。彼女の鬼気迫る演技は凄いものは証明済みですし、歌唱では「中島みゆき」の名曲を女性シンガー達が歌い上げるライブ「歌縁（うたえにし）」で彼女がカバーした「ファイト！」は惹きこまれる魅力に溢れています。そもそもアクターズスクール出身である彼女の歌は本職なのです。

表層に飛び出した彼女達だけでなく、水面下にまだまだ隠れた才能はいっぱいいらっしゃって陽光目指して磋琢磨されていることなのでしょう。

『ファム・ファタール』：

ところで、肝心の書籍「籠の鸚鵡」についてですが、新書でもありますし筆者如きが読み終えてすぐ書評するなぞ恐れ多いのでここでは控えさせて頂きますが、少しだけヒントを。

物語終盤に「補陀落渡海（ふだらくとかい）」という捨身行（しゃしんぎょう）が登場します。「補陀落（普陀洛）」の語源は古代サンスクリット語「ポータラカ」から由来するもので「浄土」を意味するのだそうです。この捨身行は小船で海上の沖合に向かい行者の身体に石を巻きつけて入水するというものです。これが物語のクライマックスにシンクロナイズしてファム・ファタールとユニゾンを奏でます。

せっかちなので「籠の鸚鵡」は「浅野忠信」主演で映画化されそうな気がして来ました。
そうとなれば、相手役となる女優さんの配役と演技が映像作品として成否の鍵を握ることになります。そして映画館に映し出されたフィルムの中の物語と同じく現実世界の作品に向けて世の中の賛否も女優さん次第となるのでしょう。

今となっては叶わぬ配役ですが、ファム・ファタールは「高峰秀子」(Hideko Takamine)（三枝子じゃなくて秀子です）、そうです「デコちゃん」をキャスティング出来れば最高なのではと夢想させて頂きました。現在（いま）ならば「場末にあるスナックのママ」という設定を無理なく熟せる（こなせる）「宮沢りえ」(Rie Miyazawa) が最初に思い付きます。演技力は折り紙付きです。「色っぽくて大柄な女」という点ではハイボールのテレビ・コマーシャルで露出した「小雪」(Koyuki Kato) が想起されます。役柄が求めるビジュアル、彼女の男っぽい性格が物語との相性の良さが映像に滲んでくることでしょう。

果たして誰が「運命の女」を演じることになるのでしょうか。
まさに「魔性の女」の面目躍如ですね。

次回もお楽しみに。