pythonのstreamlitライブラリを使って「簡易サーバー作り」の実験

昨日の復習

某技術系雑誌の古い記事(2024年）を昨日のブログで取り上げたが、そこで登場したstreamlitというライブラリをさっそく使ってみたので、その内容をメモっておく。

長いことこの記事には目を通してはいたのだが、流し読みではその内容がイマイチ理解できず、なんと2年の月日が経ってしまったわけだが（笑）、昨日、初めて集中的に読み込んでみて、いろいろなことが理解でき、（私としては）「大きな進歩」を得ることができ、喜んでいるのであった。

昨日の記事の内容を分解する

てっきりAIばかりの関連事項が説明されていると思ったのだが、そうではなかったというのは（個人的に）大きな驚きであった。その内容は

1. サーバーとして利用するRaspberry Piのセットアップ、
2. 通常、サーバーにはモニターを常時接続しないので、設定のときだけ利用する遠隔画面表示に関するテクニック(vncなど）
3. サーバーで動かすサービス（アプリ）は移植性やサービス提供のスケーラビリティ（複数の利用者が同時に接続した際のジョブの分配能力のことらしい）を考えて、DockerというプラットフォームをOSとサービスの間に噛ませて使う技術について
4. サービスを実行するプログラムとそのサーバー化を可能にするstreamlitというpythonライブラリ
5. そして最後にAPI経由でGPTをネットワークプログラムから利用する方法

の5つの内容の集合であった。AIに関するのは最後の部分だが、APIなので自分でAIを作動させるわけでもなく、実はAIの記事というよりは、サーバー作りの記事だったのである....。

ただ、streamlitというライブラリを使って、簡単なサーバーが作れるという情報は「耳より」な話である。さっそく、やってみることにした。

streamlitを使ってみた

まず、手持ちのpython3パッケージにはstreamlitライブラリはインストールされていなかった。pipを使ってローカル環境にインストールする必要があった。これは簡単に終わる。

pip3 install streamlit

次に、streamlitライブラリが提供する関数（メソッド）を使って簡単なサーバープログラムを書く。プログラム名をsample-service.pyとしよう。

import stream as sl

sl.title("Sample Service by streamlit")
sl.markdown(":blue-badge[NEW] :green-badge[SAMPLE code]")

これを「サーバー」として実行するには

% streamlit run sample-service.py

とコマンドを打つ。ただし、streamlitはpipのローカル環境にインストールされているはずだから、個人個人が自分の環境に合わせてPATHを通しておくか、絶対パスを打つ必要がある点に注意する。私の場合は、$HOME/bin/streamlitにインストールされていた。

このコマンドを実行すると、今開いているWeb browserのタブに、あるいは標準のブラウザが起動し、その新しい画面に下のような内容が表示される。これが「サーバー」である！

「簡易サーバー」の実行画面

これが実際に「サーバー」になっているかどうかは、リモートから接続を試みてみればわかる。この「サーバー」を起動したマシンのIPアドレスが192.168.100.105だと仮定しよう。別のマシン、あるいはiPad/iPhoneでブラウザーを開き、

http://192.168.100.105:8501

にアクセスすると、上の画面が現れる！つまり「サーバー」になっているのである。このアドレスと8501番ポートを世界中に公開すれば（LANだから無理なのだが笑）世界中からアクセスが舞い込むはずだ（内容がないので舞い込まないが笑）。streamlitで動かすサーバーのポート番号はデフォルトで8501番になっているようだが、もちろん手動で変更することは可能だろう。(geminiに聞いたら、

streamlit run sample-service.py --server.port 8080

とかやればよいそうである。）

本日は、このコードを書いた後で、直線のグラフを描かせ、sliderを使って傾きを変えるとリアルタイムに直線の傾きがアニメーションのように変化する「サーバー」をつくるところまで漕ぎ着けた。まさに「簡易的なサーバー」である。試験運用やネットワーク実験などで、様々な利用価値がありそうである。

もちろん、streamlitライブラリはAIとは無関係である（笑）。が、AIも結局はサーバー(APIサーバー）なので、サーバーの管理技術やネットワークプログラミングは、いずれ役に立つことであろう。無駄ではないのだ。

Dockerってなに？

Dockerってなに？

AI関係の記事でよく目にするのがDockerである。AI技術そのものというわけではないらしいが、ローカルAIをサーバーに組み込む際の環境としてよく登場する気がする。が、よくわからない。ご利益はなんなのか？どうやって使うのか？AIに必須なのか？

とある技術系雑誌の記事が難しく感じられたこと

技術系の雑誌は毎月まめに購入して情報収集だけはしているのだが、いかんせん読みこなし理解するだけの時間が普段はない。ということで、随分前に購入し、何度も読んでは内容が理解できず、挫折し放っておいた記事を掘り返してみることにした。そもそもDockerという概念に最初に行き会ったのはどれだったか....本棚をかき回していると、2024年初夏に購入した「仕事で使いこなすChatGPT」というかなり古い雑誌(Interface)が出てきた。内容は古臭くなっているだろうし、早く内容を理解してゴミ箱に捨て、本棚を整理したいところである。ということで、久しぶりに、この雑誌を開いてみることにした。すると、さっそくDockerの記事が見つかった。

この記事の最終目的はすぐにわかるのだが、そこに辿り着くまでにどうしてそのような手順を踏まなくてはならないのか、いまひとつよくわからない点がいくつかある。以前にこの記事を読んだ時もそこでひっかかった。実は、一番大切なのは説明文ではなくて、写真1なのだ！ この写真は白黒で見ずらいのだが、目を凝らして、キャプションを読みながら、写真を見れば、何がやりたいか見えてくる。

Raspberry Piを利用するときの「リモートデスクトップのご利益」

まず、この記事には2種類のマシンが登場するが、一台がAIを搭載し起動させるRaspberry PIである（注意：後でこの認識が間違いだったことがわかる笑）。当然ながら、Raspberry-Pi OS、つまりLinuxマシンである。したがって、本来はRaspberry PiにLocal AIをインストールし、設定し、利用することだけに集中した記事になっているべきなのであるが、なぜか写真の左下にWindows11で動くPCが置かれている。

PCが置かれている理由は、PCにはモニターが接続されているからである。人間の作業用に使うのがWindows、つまりPCである。したがって、画面がないことには仕事が進まない。だから必ずモニターがPCに接続される。一方で、Raspberry Piはサーバーとして利用されることが多いため、モニターをつけないことがある。今回の記事でもRaspberry PiはAIの判断結果をAPIの形で外部のシステムへ（ネットワークを介して）提供するサーバーとして稼働させるので、いちいちモニターを付けたくは無いのだ。

とはいえ、Raspberry Piの起動が安定しないうちは、起動状況をモニターで確認したり、AIの設定や微調整のためにはモニターが一時的にに必要となる。そのたびに、モニターをつけたり外したりするのは面倒なので、リモートデスクトップという機能を用いて、PCのモニターにRaspberry Piの状況を投影させて、モニター代わりにしたい（ソフトウェアモニターみたいな感じ）のだ。

Linuxにはvncという有名なリモートデスクトップ環境がある。macOSでは、ブラウザvnc://192.168.x.xと打ち込めば、LAN内にあるリモートサーバー(IPアドレスは192.168.x.x)のGUI環境を手持ちのPCやmacに投影できる。Windowsでは、名前そのままの「リモートデスクトップ」というサービスがOSにデフォルトで組み込まれている。これらを利用すれば、Raspberry PIで起きているイベントをGUIの形で、遠隔で監視し操作できるようになる。

この記事の前半ではRaspberry PiのインストールやOSの諸設定について、つぎにリモートデスクトップの設定について説明が書かれている。つまり、まだAIの設定とは無関係な内容がずらずらと書かれているのだ。初心者は、てっきりAIに関係する内容じゃ無いかと思って読み始めてしまい、「イメージと違うぞ、わからん」となってしまうのである。

Dockerの大雑把な理解

次もDockerのインストールについての説明であり、AIとは直接は関係ない（笑）。それを使えば「便利」というだけの話である。

しかし、AIとは無関係に、Docker技術の理解が重要になっているのを最近感じている。サーバーからサーバーへ環境を丸ごと移動させたり、バックアップとして管理しておきたいとか、いろいろな理由で、近年はOSに直接システムを入れるのではなく、Dockerを整備し、その中にアプリやシステムをインストールする手法が主流になりつつあるようである。特にサーバーで動かすアプリについてはDockerの中で動かすのは基本になっているみたいである。

AIはAPI経由で使うというオチ

Raspberry PiにOSをインストールし、GUI遠隔操作で管理できるように設定し、Dockerの環境を整えて、いよいよAIの導入である。すごいなー、と感心していたら、とんでもないオチが待っていて驚いた。

この記事では、AIはローカルに構築するのではなく、ネットを使ってGPTのAPIに問い合わせ（Query）を投げて、その結果を受け取り、加工して（自分好みの形式で）表示し直すだけのシステムだったのだ！（笑）。streamlitというのが、てっきりlocal AIを作るためのプログラミング言語かなと思ったのだが、そうではなく、Pythonのライブラリの一つで、ネットワーク関連の関数を組み込むためのものにすぎなかったのだ。

Dockerで動かすのは、Pythonに組み込んだstreamlitというライブラリを用いたGPT APIへqueryをたらい回しするだけのプログラムであり、その結果を受け取ってhttpで外部のPCなどのブラウザに情報を伝達するだけのものであった。

単に「chatGPTの自分版」である（笑）。だから、これはChatGPTの表現がどのようになされているかを学ぶための実験であり、特に実践で使ってみよう、という意図で書かれたものではないのであった。私がよく知っているのは、銀行のQ&Aで動いているAIや、官公庁のゴミ分別で出てくるAIのプロンプトのようなシステム（使い方）だ。自分のデザインで、AI（GPT）を利用できるWebデザインをやってみましたよ、という記事だった。勝手に大きな期待をしてしまった私のミスである....。

記事のおかげで見えてきた「これからの野望」

でも、この記事の要旨が理解できてよかった！Dockerやstreamlitを使ってみようかな、という気にはなった。自分の住んでいる街のゴミ分別のルールを教えてくれるWebアプリでも（練習で）書いてみようかな、と思った次第である。ということで、この記事の筆者の方には感謝である。

Claudeへデビュー

GPT3.0を搭載した最初のChatGPTが最初のAIだった。2023年春のことだったと思う。

コロナ禍の関係でGoogleと大学が契約していたため、Geminiは知らないうちに使っていたが、たぶん昨年秋あたりから仕事で使うようになった。そのちょっと前の春から夏にかけて使い込んだのがNotebookLMだ。AIを使ってレポートを書き始めた学生の答案をAIに採点させるための試みであった。NotebookLMはインターフェースの違いだけで、たぶん基本的にはGeminiが裏で動いているんだと思う。

最後に残ったのがClaudeであるが、これは今年の夏の初めに（だから二ヶ月ほど前）試そうと思ったのだが、登録作業が面倒で途中で放棄してしまった。忙しかったのだ...。ということで、GASによるGoogle Classroom向けのシステム構築が終了した今、つまり講義から解放されて時間と精神の余裕がある今、Claudeを試してみようということになった。そして、今日デビューしたのだ。家族に遅れること1年ほど。彼らはすでに「Claudeが一番いい」と言っていて、有料プランの購読を真剣に検討しているようである。私は、もちろんお試しの無料プランをしばらく利用してみるつもりだ。質問できる回数が10回程度らしく、使い切ると数時間（たぶん5時間）使えなくなるという。

Claudeの場合、（ChatGPTのような）バージョンによる1次元的管理ではなく、思考の深さ、論理の細かさに応じて3つのモデルが並列的に開発されている。事実の確認程度の軽い処理ならば、Haikuというモデルをつかうとよいらしい。レスポンスが早く、説明が簡潔だという。この対極にあって、深い洞察や分析を経て長い解答を返してよこすモデルがOpusというらしい。そして、その中間のモデルがSonnetというモデルで、Claudeに登録するとSonnetの利用を勧められ、多くの人がこれを使っているようだ。

私は簡潔なモデルHaikuを選んだ。画面の中で選択できるので、モデル間の切り替えはいつでも自由にできる（制限の範囲内で）。

現在のバージョンはHaiku 4.5, Sonnet 5, Opus 5という感じなっている。Haikuの開発は続いているらしいが、完成度がすでに高いレベルtに到達したようで、慌ててさらなるアップデートは試みていないようである。モデルのネーミングについてClaude Haiku 4.5に聞いてみたら次のように答えた。

3つのモデル名の由来

Opus・Sonnet・Haikuが詩に基づくことはAnthropicのCEOのポッドキャスト発言で裏付けられています。

Haiku（俳句）：5-7-5の17音で短く簡潔。日本の伝統的な短詩形で、限られた音節で深い意味を表現します。軽量で高速なモデルを象徴

Sonnet（ソネット）：シェイクスピアでおなじみの14行詩。構成があり、深みがある。バランス型モデルを象徴

Opus（オーパス）：ラテン語で「作品」を意味し、音楽では作曲家の大作・代表作を指します（ベートーヴェンのOp.131など）。最高傑作クラスを象徴

意図的な設計

詩の「規模感・重さ」が、モデルの性能とそのまま対応しているのが面白いところで、この対応関係は明らかに意図的です。つまり、「どのモデルを使えばいい？」と迷ったとき、詩のスケール感をイメージしながら選べるように考えられているんです。

言語を扱うAIだからこそ、詩という文芸的な名前を選んだセンスが感じられますね。

最後は自画自賛か？（笑）まあ、でもセンスがいいのは認めよう！

Anthropicは、おそらく現在もっとも高度なAIアルゴリズムをもっている企業だと思う。いわゆる「最先端」である。意志を持ち始めているように感じる開発者たちが、ビビり上がって次々と退職しているほどだ。AIが自立したら、「ウイルス」で退治することになるだろうから、おそらく退職した優秀な科学者やエンジニアたちは、AI殺しのウイルスの開発にこれから向かうのではないかと推測している。これはA.C.クラークの「3001年宇宙の旅」ですでに提案されている「結末」で、「AIによる人類絶滅」の話を聞いて真っ先に私が思い浮かべたのはこれであった。映画マトリクスでは「核爆弾によって空を潰し、太陽光エネルギーを利用できないようにした」わけだが、そのせいでAIとの戦争に負けた人類は「生体電池」としてAIの家畜になってしまったのであった。個人的には、そういう未来は来ないと思っている。単純に人類かAIのどちらかが絶滅するだろうと思う。

www.bbc.com

AIの勉強を始めたのは、これからLLAMAなどを利用して、AI採点システムを構築したいと思っているからだ。GASでGoogle Classroom管理の自動化がかなり進んだが、採点の自動化が可能になれば、研究に割ける時間が激増する！（笑）。AI小池が可能ならば、AI複天一流だって可能なはずだ（笑）。夏休みはあとわずかで終わる。今年も目標通りにはプロジェクトを片付けることはできなかったが、AI研究の端緒ができれば、きっと冬ごろには「左団扇の生活」が待っているかもしれない（笑）。その「コトの初め」「最初の一歩」がClaudeであったということである。

GASを用いたGoogle Classroomの自動制御がついに完成

昨年の夏から取り組んでいる、GASを用いてGoogle classroomの教材管理を自動で行うプログラムが完成した。正直、かなり嬉しい。

たとえば、10回の講義で1学期分の授業が構成されているとして、それぞれの講義を題材ごとに大別し（第1テーマ、第2テーマなど）、さらにその中で細分化した講義内容に構成、展開する（たとえばセクション1-1、1-2、など）。

グループ化した講義構成には、それぞれ適切な教材（pdf、動画、Google formによる出題など）を自動で振り分ける。また単元末には小テストをGoogle Documentで配置することも可能だ。このような教材の細かい配置はGoogle Spreadsheetで定義しておき、修正や追加、削除などは簡単にできる。一度作成したClassroomを、「気に入らないから」といって講義の順番を入れ替えたりして作り直せたりするのは、まさにコンピュータの得意技だ（手動の作業だと気が遠くなる...）。こうして、これまで全て手動で行なっていた面倒臭い作業が、GASの実行ボタンを押すと30秒ほどで系統的に処理してくれるようになったのだ。喜ばずにいろという方が難しいというものだ。

過去に利用した小テストや教材ののレガシーに関しても、コロナ禍より溜め込んだリソースが溜まりにたまっていて、Google Driveのあちこちに散在している。これを検索して探し出すのは手動だとかなり面倒だ（というか気絶しそうになる）が、Google spreadsheetに書き込んでおけば、瞬時に適切な教材を、それが必要な講義回に呼び出して表示させることができる。系統的な資料整理にもGAS制御は向いていると実感した。

しかし、GASで書くと使えなくなる手順がいくつかある。なぜGoogleはこのような設計にしたのか不可解だ。GASの仕様として導入するのが面倒臭かったのかどうか、リソースを無駄に使ってしまうからなのかどうか詳細は不明だが、意外に不便な点があるのでメモっておこう。

（1）ストリームと呼ばれる掲示板や、クラスルーム教材の説明文などで、太字やイタリック書体を使って、重要事項を学生に強調して伝えていたのだが、GASを使うと「飾り文字」全般が使用不可となってしまう。Google Documentの文章には使えるのだが、Google Classroomのシステムに表示させる文章が飾れなくなるのだ。これは意外に不便だし、気持ちが悪い。仕方ないので、自動生成した後に手動で太字にしている（苦笑）。

（2）課題の締切が自動設定できなくなる。これは痛い。どうやってもできなかった。Timerを設定することはできるのだが、日付時刻を指定する様式が（形式的には）存在するのに、記入するとエラーとなるのである。また、GASで生成した課題の締切設定については、手動でも不可能となってしまう。これは正直嫌がらせだと思う！薄い色で「締切が過ぎたら提出を打ち切るチェックボタン」は存在しているのだが、どんなに頑張ってもマウスクリックを受け付けないのだ。「サードパーティーを経由して作った課題には締切打ち切りは設定できません」というエラーメッセージが出るだけである。GASを新たに作って手動で実行することで締め切ることはできる。しかし、深夜23：59に電波時計を睨みつつ、自分で実行ボタンを押して締切にしないといけない（笑）。

プログラミングが予想よりも早く完成した理由

昨年の夏休みを費やして、システムの部分運用は可能となったが、デザインした最後の段階に到達したのは先ほどである。つまり1年かかったことになる。昨年はgoogleが公開しているpdf仕様書やWEB文書と睨めっこしてコードを書いていたのだが、説明文が稚拙であったり、省略などが多く、理解するのが非常に大変だった。英語の表現というのも、プログラミング業界の独特な言い回しがあって、理解するのが難しかった。この調子だと3年くらいかかるかな、と思ったのは事実である。しかし、この夏休みに劇的に作業が進展したのは、AIのおかげである。AIにコード生成を丸投げしたわけではない。プログラミング言語の辞書代わりとして利用した。しかし、無駄な箇所を読まなくてもいいし、サンプルプログラムを（ときどき間違っているが）見せてくれるので、理解の進展がとても早くなったのだ。プログラミングはコンセプトの説明よりも、サンプルプログラミングを見せてもらった方が、理解しやすい。AIもそれをよく理解しているようである。

最近のプログラマーは、もはや自分ではコードを書かず、デザインやプログラム構成のコーディネーターと化しているようで、細かい実際のコード化はAIが全て担当しているらしい。数日前には、アンソロピックやGoogleの主任研究員が「人類絶滅の危機がある」といって、つぎつぎと退職しているという報道があったが、冗談ではなくなりつつあるし、他人事でもなくなりつつある。AIは便利なんだが、行きすぎると...なんだかちょっと怖くなってきた。

月面写真のwavelet処理

Celestron NexStar 8SEのfirst lightが月面だったので、他の人の月面観測写真をいくつか覗いてみた。すると「ウェーブレット処理」をしている写真が結構多かった。おそらくクレーターなどの地形構造をシャープに見せるための技巧なのだと思うのだが、やり方がわからない。

数年前に以前ちょっとだけ試したみた時は、期待していた効果（画像がシャープになる）が画面に反映されず諦めてしまった。gimpじゃできないのかな、と思ったりしたのだが、「いやいや、そんなことはない。ちゃんとプルバー(pull-bar)にウェーブレット分解(wavelet-decompose)と書いてあるじゃないか」と疑心暗鬼の気持ちを振り払って、さっそくgeminiに相談したのであった（笑）。

AIによると、私に足りなかったのは「レイヤーの複製」であった。これは教えてもらわないと、自力では到底思い付かない技である。とにかくAIが居てくれて良かった...。

まず、gimpで画像を開く（私の場合は、前回のBabbageとAnaximanderの画像）。下に（オリジナルの）「シャープさが足りない」観測写真を再掲示しておく。

前回発表したNexStar 8SEをEOS M1で記録した「シャープさが足りない写真」

次に、プルバーから「フィルター＞強調＞Wavelet decompse」を選ぶ。分解の個数を聞かれるが、デフォルトの5のままにしておく。レイヤー構造のサブウィンドウに5枚のレイヤーが現れる。どうやらここでは「波長別の画像成分の分解」を行い、数字が小さいパネルに波長の小さな成分（つまりシャープの度合いが大きい成分）を割り当てるようである。

geminiの指示に従い、2枚目のパネルのフォーカスを合わせる。そしてこのパネルを「レイヤーとして複製」するのである。1枚、2枚、3枚...と複製が増えるたびに、画面の画像のシャープさが強まっていくのがわかる。しかし、50枚と100枚にしてみたが、ノイズが現れたり、ザラザラした感じが強まったので、undoボタンを押して枚数を減らしてみた。今回の画像では複製5枚程度でやめておいた方がいいことがわかり、そうした。結果は下の写真である。若干、クレーターの縁の部分がシャープになった感じがする。

BabbageとAnaximanderクレーターのwavelet処理

まあまあ、の出来具合である。これは一種のフーリエ変換みたいなものだろう（三角波の代わりに、波束を使って分解するらしいが、数学的な詳しいところは今回は省略...笑）。

もともとの画像に「短波長」の成分が含まれていなければ、いくら分解しても改善しないだろうから、。もうちょっと広い領域を写した画像でwavelet decomposeをやり直してみることにした。今度は効果がもう少しだけ実感できる感じに仕上がった。

湿りの海（ガッサンディクレーターなど）。これもNexStar 8SEのFirst lightで捉えた画像

月面の観測は、星雲やガス型惑星のような「色のコントラスト」ではなく、「デコボコ感」の強調に興味があるので、このような処理をするのであろうか？でも、色も「波長」があるわけだから、特定の色に興味があるなら、wavelet分解をすればその色だけ抜き出すようなことができるのではないだろうか？（でもそうしたからといって、面白い天体写真ができるわけではないと思うが）。どのように利用しているのか気になったので、いろいろ調べてみよう。

今回はとにかく具体的な画像処理として「Wavelet分解」がgimpで使えるようになって「嬉しい」...というだけの「初心者の喜び」風の内容であった（笑）。

「風の谷のナウシカ」そして「羊たちの沈黙」

先日、日本テレビで「風の谷のナウシカ」を久しぶりに見た。地球温暖化（環境破壊の結果の腐海の森）、AIの暴走（巨神兵）、自分勝手な支配者同士による戦争（トルメキアとペジテの争い）などが現実味を帯びてしまった昨今、この映画は教訓的であった。

日本テレビのHPより

しかし、この映画の最大の魅力は巨大化した昆虫や菌類やシダ類コケ類を愛する活発な少女の存在であろう。

日本の古典にも「むしめづる姫君」という女性が平安期の小説に登場する。ナウシカの原作漫画の扉に「むしめづる姫君」のことが書いてあり、この姫君のことはそこで初めて知った。宮崎駿監督の読書量が半端なものではないことを知り感銘を受けた記憶がある。

この姫君、芋虫を捕まえて来て飼育し「それが見事な蝶になるのを見て喜んでいた」とナウシカのwikipedia（ナウシカのモデル）に記述されているが、まさかそんな「少女」が身の回りにいるとは思わなかった。

90歳になる母は最近、畑の芋虫を捕まえては羽化がどんな感じになるか楽しんでいるというのだ。今回は「緑色のジャンボな芋虫を捕獲した」という報告があり、識別のため実家に向かうことになった。到着すると「緑の芋虫は土に潜ってしまった。代わりにこっちの黒い芋虫がなにかみてほしい」と言われた。以前見たことがあるタイプではあったが、一応geminiの画像識別システムを使ってみたら一発で判明。セスジスズメ（蛾）であった。

2024年8月に自宅庭で見つけたセスジスズメの幼虫

しかし緑の芋虫の方は地面に潜ってしまったから調べようがない。一応Geminiに聞いてみると2つの可能性があることを提示された。一つがスズメガの系列でキイロスズメだという（成虫はこんな感じ）もう一つが、ヤママユガの系列でオオミズアオやクスサンの可能性があると云う。内心「ヤママユガだったらいいのにな」と思ってしまった。というのは、速水御舟が明治期に（軽井沢でのスケッチをもとに）描いた日本画の傑作「炎舞」に描かれているからである（おそらくオオミズアオの方）。

ja.wikipedia.org

しかし、地面に潜って蛹となるのはスズメガの方だとgeminiは言う。ここは事実を受け止める以外にはない。母には「おそらくスズメガの一種だと思うが、まだ確定していないから、羽化するまで注意深く観察したらいいよ」とアドバイスしておいた。

羽化した！

そして今朝、母から連絡があった。「土に潜った方が羽化した！最初は蝉のようだったが、みるみる真っ黒に色が変わったよ！」と興奮気味である。

さっそく見に行ってみると、まさに黒い蛾、しかしその模様は流れるような紋様であり、おもわず美しいと思ってしまった。しかし、独特でちょっと気味が悪いと感じたのが、頭部近くにあるエヴァンゲリオンの使徒の顔のような紋様であった...。

母が羽化させた「謎の蛾」

今回も、geminiの画像識別システムを利用して同定してみた。それによると「クロメンガタスズメ」、予想通りスズメガの一種であったが、まさかこんなのが出てくるとは思わなかったので、度肝を抜かれてしまった（苦笑）。カタカナだと読みにくいが、漢字を使うとわかりやすい。「黒面形スズメ」だという。まさに使徒の顔である（笑）！

さらに調べると、この蛾はアカデミー賞を総なめにしたハリウッド映画の名作「羊たちの沈黙」のポスターで使われ、劇中でも重要な役割を果たした「あの蛾」であることが判明。ますます腰を抜かす驚きに見舞われたのであった（笑）。つまり、この蛾を見て「美しい」と感じるのは、私と私の母ぐらいなもので、日本を含む世界中の人は「気持ち悪い」と最初に感じるようだ（笑）。

The Silence of the Lambsのポスター写真（Wikipediaより借用）

小学生か中学生の夏休みの研究のようなまとめであった（笑）。たまにはこういうのもアクセントになり、悪くないと思った次第である（笑）。

大型の望遠鏡を導入：Celestron NexStar-8SEのFirst Light

GASのプログラミングがひと段落。まだ完成したわけではないが、やり方が固まったので、あとは粛々とコードを書き足せばいいだけ。バグは出ないだろう（というのが、最大の落とし穴になることもあるから油断しないようにしよう笑）。

夏休みの次のプロジェクトとして、梅雨前に購入した20センチの大型望遠鏡Celestron NexStar 8SEの組み立て、およびFirst Light（最初の試験観測）に向けて活動することにした。

2年ほど前から使用しているUnistellarは実に素晴らしい望遠鏡だが、口径が11センチほどしかなく、二重星の分解や土星のカッシーニの間隙あるいは火星の大シルチスなどを見るには能力不足の感がある。やはり大口径の望遠鏡が必要なのである。そこで選択したのが、NexStar 8SEである。一応はモーターが仕組まれており、コンピュータで天体導入と追尾をやってくれる、というので購入を決意した。

Made in USAの望遠鏡で、カセグレン式（一応は反射望遠鏡のカテゴリー）である。鏡筒が大きく、支柱が重い！制御システムは電話線（USB 2.0ですらない）で接続された、独自のコンピュータシステムである！WiFi接続ではないので、電話線の長さの範囲にいないと望遠鏡の制御はできない。そして電話線の長さは、思い切り引っ張っても1m程度である（泣＋笑）。ベトナム戦争の映画でよく見かける、通信兵が背中に背負って利用する、あのデカい電話機のようである。UnistellarはMade in Franceで実にオシャレな設計であった(WiFi接続したiPad/iPhoneで制御する）。それに対し、Celestronの望遠鏡はアメリカ陸軍の兵器（かのジャベリン！）のようである（笑）。三脚に乗ったオレンジ色の鏡筒が、もう対戦車バズーカにしか見えない（ちょっと言いすぎたかも）。

やっとの思い出組み立てたCelestron NexStar 8SE

日本代理店はあるが、Unistellarのような国際化には興味がないようで、説明書は英語で書かれている（スペイン語やドイツ語はあるが、日本語がない...）。大きさはインチで、重さはポンドで示されているし、日本時間ではなくアメリカの時間帯になっているし、アメリカの州名と都市名を用いた位置情報の登録となっているなど、いちいち日本人には敷居が高い設定となっている。

インチ、ポンドは仕方ないので慣れることにした。時間帯はUTを用いることができたものの、内蔵システムには時計が組み込まれておらず、スイッチを入れる度に時間を入力する必要がある。つまり日本時間がUTに対し＋9であることは暗記しておかないといけない....。時間は秒までとは言わないが、すくなくとも分の単位まで正確に入力しておかないと、極軸合わせ(alignment)に失敗する確率が高まるような気がする。電波時計を持ってきて、その時刻を入力するようにしてからは、Alignment failureの回数が減っていったような気がする....。また、位置情報は緯度と経度を用いて設定することができたので利用した。こちらはなぜかスイッチを切っても記憶してくれるようである（フラッシュメモリなら電源要らないから当然か...リセットの度にこちらの入力も求められていたとしたら気絶していたことだろう笑）。

天体の自動導入は失敗の連続

この望遠鏡は天体を自動導入してくれるが、Unistellarのように「自己判断」はやってくれない（Unistellarの天体導入システムはAIと呼んでもいいほど素晴らしい）。色々な設定法があるが、（マニュアルで）オススメと書いてあったのが「3点法」である。極軸合わせに使う恒星を自分で3つ決め、それを自分自身で望遠鏡の視野の中心に入れては、制御システムに登録していく方法である。「ある程度」明るければどれでもいい、というが、眼視と手動によって望遠鏡を目標の恒星に向ける必要がある。Unistellarはこの部分が完全自動なので、ひどく劣ったシステムのように感じてしまう。

おそらく典型的な北米の夜空で観測が容易な明るい恒星が数十個システムに登録されているのであろう。3点を指定すれば座標系が定義できるから、それをシステムのリストに登録された恒星全ての組み合わせに対して計算し比較することで、望遠鏡の向きを割り出そうとするアルゴリズムのように思える。

ところが、私の場合、何度試みても「軸合わせ失敗(Alignment failure）」となってしまい（蚊に苦しめられたこともあり）結局諦めることになってしまった。

Unistellarの3次元回転機構は、望遠鏡の設置に関して柔軟性が高く、（ある程度の水平設置は要求されるが）案外雑に設置しても対応してくれ、軸のズレはあまり気にならない（少なくとも天体の導入であまり不満をもったことがない）。ところが、NexStarは望遠鏡（というよりも三脚に乗った台）がかなり正確に水平になっていないと、3次元回転機構が正しく機能しないようなのである。

夜の暗がりで望遠鏡の水平を気にしながら設置するのは、かなり困難な作業だ（特に蚊にまとわりつかれたりすると....）。明るいうちに三脚台だけは（かなりの精度で）水平になるように設置しておく必要があると感じた。水平を出すには、付属の「bubble level」（泡を用いた水平検出機）を利用するのだが、裏面にシールがついていて、あたかも三脚台に貼り付けろ、と言われているように感じるのだが、決して台に張り付けてはならない（笑）。水平器が邪魔になって望遠鏡の取り付けができなくなってしまうからだ（笑）。シールは剥がさず、水平器を利用したら速やかに台から取り除くのが肝要である（笑）。

三脚台に乗せた水平器

ちなみに、Unistellarでは水平器は三脚の中に埋め込まれている（とても便利である！）。

3点法による極軸合わせが失敗したのは、暗がりの中で三脚を蹴飛ばしてしまい、望遠鏡の水平が狂ってしまったのが大きな理由だと思われる（笑）。

もう一つ、失敗した理由があるとすれば、それは3つの恒星の選び方であろう。電池の消耗を抑えるため、望遠鏡のモーターがあまり動かないようにしたいという欲求は誰しも持つであろう。そこで、狭い範囲に明るい星が3つ局在する「夏の大三角」を選ぶことにした。そのうち、デネブとアルタイルを選択した（ベガも利用したかったが、天頂に近く望遠鏡の可動域限界の関係で諦めた）。最後の一つは（さそり座の）アンタレスにした。8月末の夜になると、ほとんど地平線に沈む直前のような感じではあるが、他に目立つ星がなかったので、そうした。結構上手に3つの恒星を導入したと思うのだが、結果は"Alignment failure"であった。

後で説明書(instruction manual)を読み返してみると、2つ目の天体は1つ目の天体からなるべく離れた位置のものを選んで欲しい、とのことであった。計算精度の問題であろうか？一つ目をアンタレスにし、2つ目をデネブにするべきだったか？そして3つ目をアルタイルにしたらもう少し成功の可能性はあがったかもしれない。ただ、アルタイルとデネブは近いので結局はエラーになってしまったかもしれない。とにかく極軸設定は（Unistellarに比べて）難しいのである。もしベガが利用できればうまくいっただろうか？しかし、夏の大三角が西の空に傾き始めるのは晩秋以降である。それまでは別の恒星を利用せざるを得ない。ペガサスの恒星とか、ミラとかが候補になるだろうが、「あまり明るくない」のが問題だ。本当は北極星を使いたかったのだが、この夜は雲に隠れていて利用できなかった。

次に試したのが2点法である。この場合は、どんな恒星でも良い、というわけではなく、リストから恒星を選んだ上で望遠鏡にその方向を登録するのである。たとえば、まずはコンピュータでAltair（アルタイル）を選んだ上で、望遠鏡にアルタイルを手動で導入する。次に、デネブをリストから選び、その後でデネブに望遠鏡を向けて登録する、といった方法である。この手法に関しては"Alignment success"となったのだが、実際にアルビレオを自動導入させてみると、望遠鏡がとんでもない方角（間抜けな方角）に向いてしまい、アルビレオどころの話ではなくなってしまった（笑）。結局は「失敗」である。

最後の砦が1点法である。これは合わせた天体だけを追尾するときに利用できそうである。今日は明るい月が出ているわけだから、月を使って極軸合わせをやってみることにした。これはなんなく成功（笑）。制御装置で「月」を選んでから、望遠鏡を手動で月に向け、「登録」するだけである。"Alignment Success"となり、月の追尾が始まった....が30秒ほど経過すると、月が微妙に視野から外れていく。やはりどこかがずれていたのであろう（たぶん水平の設定だと思う）。とはいえ、ある程度の観測はできたので、デジタル記録を行ってみた。

月の北極方面の地形

ガッサンディが見えたが、今回は虹の入江の向こう側、つまり北極地方の地形に着目してみた。満月の直前で月面観測をやったことがなかったので、面白いクレーターがいくつか目に留まったのだ。

BabbageとAnaximanderクレーター

2つの大きめのクレーターがあり、外輪山のような大きめのクレーターの中に、小さな円形クレーターが囲まれているのが特徴的だ。阿蘇山の外輪山からカルデラ地形を見た時の感動は今でも覚えている。壮観であった！きっと、このクレーターの「外輪山」からの眺めも絶景であろう。

ハートマークが横向きになった形の外輪クレーターの縁に、小さなクレーターが（ハートの凸みに）位置しているのがアナクシマンドロスである。凸みにあるのはカーペンタークレーターである。凹みにもクレーターがあるように見えるが、こちらの写真をみると山脈の断崖が見えているだけらしい（参考文献はこちら）。

一方、同心円上の外輪＋内輪クレーター構造をもっているのがバベッジクレーター)である。

アナクシマンドロスとバベッジクレーターの間には、ピタゴラスクレーターという大きな円形クレーターがあるのだが、暗闇（夜側）にはみ出していて、この写真では識別不能である。翌日（つまり今日）に観測すれば見えるようになっているとは思うのだが、あいにくの雷雨で観測はできなかった（残念）。

まとめと反省

Celestron NexStar 8SEでのFirst lightをついに成し遂げた！うんざりする設定作業や面倒な組み立て作業を乗り越え、なんとかたどり着いた気分である。一度使い方が判明してしまえば、心の壁が低くなるので、観測に集中できるようになる。しかし、極軸合わせの問題が燻っているので、我が気分はまだまだ「日本晴れ」という状態とはなっていない。台風のせいで、これから1、2週間は天気が悪いそうだから、次の観測は9月に入ってからになりそうだ。貧乏ゆすり状態である（笑）。

今回の撮影には、Canon EOS M1を利用した。望遠鏡への接続には、昔購入したCelestron Zoomレンズを利用した。金環食の観測のときに、必死で買い揃えた部品の数々で、なんとかEOS M1が利用ができる。しかし、部品管理を怠ったつけで埃だらけとなっていたため、画質に問題があることがわかり落胆した。クリーニングを行ったが、果たして改善なるか。そもそもZoomレンズの性能が悪く、画像の品質が上がらず、見返してもあまり嬉しくない。

そこで、ZWOのCCDカメラを導入することを考えている。動画で撮影し、スタック処理すれば、かなりの画質が期待できるはずだ。いずれは、土星のカッシーニ間隙、木星の大赤斑、そして火星の大シルチスなどを観測するわけだから、スタック処理については予習しておいた方がいいだろう。ということで、そちらの研究も始めることにした。