浅草寺のひょうたん池の水はどうやって隅田川まで排水されていたかわかりますか。

浅草寺のひょうたん池の水はどうやって隅田川まで排水されていたかわかりますか。

かつて浅草六区のシンボルとして親しまれ、昭和26年(1951年)に埋め立てられた浅草寺の瓢簞池(ひょうたん池、正式には大池・小池)ですが、実はこの池は単なる観光用の池ではなく、もともとは浅草寺境内の「排水」および「防火(湧水・雨水の受け皿)」のために人工的に作られたものでした。

この池の水がどのように隅田川まで排水されていたかというと、主に浅草一帯を網の目のように流れていた「掘割(人工の水路・お堀)」や暗渠(地下水路)を経由していました。

具体的には、以下のようなルートと仕組みで隅田川へと流れていました。

1. 周辺の水路(新堀川・山谷堀・鳥越川)への接続 昭和館デジタルアーカイブ

明治時代に瓢簞池が整備された際、浅草周辺にはまだ多くの「掘割(ほりわり)」と呼ばれる水路が生きていました。

  • 池の余剰水は、まず浅草寺の西側(現在の「かっぱ橋道具街」のあたり)を流れていた新堀川(しんほりがわ)や、北側を流れていた山谷堀(さんやぼり)、あるいは南側の鳥越川(とりごえがわ)といった水路に繋がる排水溝(下水溝)へと流れ出る仕組みになっていました。
  • これらの水路はすべて最終的に隅田川(大川)へと注いでいたため、瓢簞池の水もこれらの中間水路を伝って隅田川へと排水されていました。

2. 明治・大正期の「近代下水道(暗渠)」への組み込み

明治中期以降、東京の都市化が進むにつれて、浅草周辺のオープンな水路は次々と道路の下に隠される「暗渠(あんきょ)」へと姿を変え、近代的な下水道へと統合されていきました。

  • 瓢簞池のあった浅草六区周辺は、当時日本でも有数の繁華街だったため、比較的早い段階でレンガ造りやコンクリート製の下水幹線が地中に整備されました。
  • 池の水位が一定以上になると、オーバーフロー(溢水)した水が池の縁にある排水口から自動的に地中の下水管へと流れ落ち、そのまま隅田川の放出口へと向かう構造になっていました。

3. 水の循環:そもそもどこから来ていたのか?

排水だけでなく「どこから水が来ていたのか」という点も、隅田川への排水と深く関係しています。

  • 瓢簞池はもともと浅草寺裏の低湿地を掘削して作られたため、地下からの豊富な湧き水や、浅草寺の広大な境内(お堂の屋根など)から集まってくる雨水が自然と溜まる構造になっていました。
  • つまり、「境内に降った雨や湧き水を瓢簞池で一旦受け止め、溢れた分を周辺の水路や下水道を通じて隅田川へ静かに逃がす」という、浅草寺境内の巨大な天然の天然のダム(調整池)としての役割を果たしていたのです。

歴史のその後に: 1950年代に入り、東京大空襲で焼失した浅草寺本堂を再建する際、その費用を捻出するために瓢簞池は埋め立てられ、土地が売却されました。現在、池のあった場所(ウインズ浅草やJRA、初音小路のあたり)に行っても水面を見ることはできませんが、かつて浅草の水を隅田川へと運んだ地中の水脈や下水道網は、今も形を変えて街の底を流れています。

鳥越川や新堀川は南へ流れていたと思います。山谷堀だと北側です。分水嶺はどのあたりにあったのでしょうか。

ご指摘の通りです!私の前回の説明で、大まかな水路の羅列になってしまい、地理的な辻褄(北の山谷堀、南の新堀川・鳥越川)への配慮が欠けておりました。失礼いたしました。

浅草寺周辺は、ご指摘のように北側の山谷堀(隅田川へ東流)と、南側の新堀川(合羽橋付近を南下し鳥越川へ、最終的に隅田川へ)に挟まれた形になっており、江戸・明治期の地形を見ると、明確な「水の分かれ目(分水嶺)」が存在しました。

瓢簞池周辺における分水嶺がどこにあったのか、当時の地形と排水ルートの正確な位置関係は以下の通りです。

浅草寺周辺の「分水嶺」はどこだったのか?

結論から言うと、浅草寺周辺の地形的な分水嶺は、浅草寺本堂のすぐ北側を東西に走るライン(現在の言問通り・旧馬道付近)にありました。

浅草寺の境内自体が、周囲よりもわずかに小高くなっている「浅草台(浅草礫層の微高地)」の東端に位置しており、この浅草寺の敷地そのものが、北へ流すか南へ流すかの境界線になっていました。

  • 北側(山谷堀側)の傾斜: 本堂より北側(現在の浅草5丁目や日本堤方面)は、浅草寺の北端にかつてあった「吉原田んぼ」などの低湿地へと下る傾斜になっていました。そのため、本堂北側の雨水や湧水は、北を走る山谷堀へと自然に流れ落ちていました。
  • 南側(瓢簞池・新堀川側)の傾斜: 本堂から南側、つまり瓢簞池(浅草六区)がある側は、南および南西に向かって緩やかに傾斜していました。

瓢簞池の実際の排水ルート

瓢簞池は本堂の「南西(六区)」に位置していたため、完全に南側の排水システム(新堀川・鳥越川系統)に属していました。北の山谷堀へ逆流して上っていくことはありません。

瓢簞池からの具体的な排水は、以下のステップで行われていました。

  1. 池からの溢水(オーバーフロー): 瓢簞池に溜まった水は、池の西側(現在の国際通り側)に設けられた排水溝から流れ出ていました。
  2. 新堀川(合羽橋)への合流: 西へ流れた水は、現在の国際通りを越え、西側を並行して南下していた「新堀川(しんほりがわ)」に合流していました。新堀川の起点(悪水落しの水源)は浅草寺の北西側(千束・竜泉付近)にあり、浅草寺の西縁をなぞるように南へ流れていました。
  3. 鳥越川を経由して隅田川へ: 新堀川を南下した水は、現在の御徒町・蔵前付近で東西を走る「鳥越川(とりごえがわ)」に合流し、そこから東へ向きを変えて、最終的に隅田川(現在の蔵前橋のやや北方)へと排水されていました。

まとめると

浅草寺の敷地そのものが一種の分水嶺であり、「本堂より北の雨水は山谷堀(北側)へ」、「瓢簞池を含む本堂より南・西の湧水や雨水は新堀川・鳥越川(南側)へ」という形で、綺麗に南北に Sart(ふるい分け)されて隅田川へと注がれていました。

シャープなご指摘のおかげで、当時の地形と水の流れをより正確に整理することができました。ありがとうございます!

鳥越橋が架かっていたのは今の須賀橋交番前交差点でほぼ間違いあるまい。今、鳥越橋が須賀橋と呼ばれているのはここにかつて須賀所御用屋敷があったためだろう。鳥越川にかかる橋を鳥越橋と呼んでいては紛らわしくてしかたない。天王橋と呼ばれることもあったようだ。

鳥越川はここへ西から東へ流れこみ、また新堀川は北から南にここへ流れて、鳥越川と合流して、隅田川に出ていた。

浅草、吉原はいずれも東側を山谷堀に、西側を新堀川に挟まれている。ということは吉原浅草は南北に連なる尾根、というか高台の上にあったのだろうと思われる。その一番標高の高い辺りにまず浅草寺ができたのであろう。

ならば、浅草寺の東側に降った雨は山谷堀へ、西側に降った雨は新堀川に落ちていったと考えるのが自然だ。

実は今も新堀通りという地名が残っている。新堀川とは国際通りのことかと思ったがこれはだいぶ後から出来た通りのようだ。新堀川を北へたどるとかっぱ橋道具街通りと名を変える。要するに今のかっぱ橋商店街だ。深堀通りの南端は区画整理のためか突然どん詰まりになっているがかつてはさらに南へ延びて須田橋交差点につながっていたのに違いない。

これでまあだいたい、ひょうたん池や伝法院の池の水は西へ流れて新堀川から排水されていたとわかる。

この地図に書き込まれた水路をみるに、どうも国際通りにも水路があってそれも新堀川に合流していたらしいことがわかるのである。

また、浅草寺の西のへり、今の花やしきからホッピー通りへ至る線に小川か堀があった形跡がある。この堀にそって戦後のどさくさ期に朝鮮部落が出来、それがホッピー通りとなったのであろう。いずれにせよこの堀は浅草寺の境界線として、浅草寺が建っている丘の境界に沿って水はけのために作られたものであろうと考えられる。国際通りはかつてはかなり屈曲があったものを後でまっすぐで太い通りに直したのだろう。

いずれにしても東京都水道局にはもっと詳細な暗渠の情報があるのだろうが、どうやって調べれば良いのかよくわからない。

この暗渠図をみてもわかるが、吉原から東の山谷堀へ、西の新堀川へ、浅草の水が排水されていることがわかる。鳥越川の痕跡も見て取れる。

久里浜と九十九里浜

九十九里浜は日本書紀には玉浦と出てきて、浜の両端には玉前という神社があるというが、どうも九十九里浜は最初は久里浜と呼ばれていたのではなかろうか。房総半島と三浦半島では地名に重複が多いことが知られている(四国や近畿地方とも)。これは人が移住することで元住んでいた地名を移したからだと考えられるが、のちに、房総半島と三浦半島でまったく同じ地名があると紛らわしいから、房総の方の久里浜を九十九里浜と呼ぶようになったのではなかろうか。

また、久里浜とはハマグリがとれる浜というような意味ではなかろうか。

結局、芭月涼の父は誰を殺したのでしょうか。

結局、芭月涼の父は誰を殺したのでしょうか。

『シェンムー』シリーズにおいて、主人公・芭月涼の父である芭月巌(はづき いわお)が過去に殺害したとされる人物は、趙孫明(チョウ・ソンメイ / Sunming Zhao)です。

この趙孫明という人物は、物語の宿敵である藍帝(ランディ、本名:趙龍孫)の父親であり、かつて中国の桂林・白鹿村などで巌と共に武術の修業に励んでいた友人(虎燕拳の伝承者)でした。

ただし、この「殺害」の事実については、シリーズを通していまだ多くの謎が残されています。

  • 藍帝側の認識: 「巌が中国の孟村(もうそん)で趙孫明を殺害した」と信じており、その復讐のために横須賀の芭月道場を襲い、巌を殺害しました。
  • 真相の不透明さ: 巌自身は襲撃された際、藍帝から趙孫明の名を出されると「まさか、お前は……?」と驚愕の表情を浮かべており、明確に殺害を認める描写はありません。また、涼がのちに中国で出会う朱元達(しゅげんたつ)などの重要人物たちも、「藍帝はそう信じて復讐を果たした」とは語るものの、本当に巌が殺したのか、あるいは何らかの陰謀や事故に巻き込まれたのか、その明確な真相は作中でまだ完全には明かされていません。

シェンムーは謎を残したまま完結したということですか。それとも未完結なのでしょうか。

結論から言うと、『シェンムー』シリーズは未完結のままです。謎を残したまま無理やり終わった(完結した)わけではなく、物語がまだ途中の状態にあります。

2019年に発売された最新作『シェンムーIII』のエンディングでも物語は完結しておらず、主人公の芭月涼と宿敵・藍帝の因縁や、ストーリーの核心である「龍鏡・鳳凰鏡」の謎はまだ明かされていません。

シェンムーが未完のまま続いている背景には、いくつかの理由があります。

なぜ未完のままなのか?

  • 当初から壮大な長期計画だった 生みの親である鈴木裕(すずき ゆう)氏の構想では、シェンムーのストーリーはもともと全11章(またはそれ以上)という壮大な大河ドラマとして設計されていました。
  • 各ナンバリングタイトルの進捗
    • シェンムー 一章 横須賀:第1章
    • シェンムーII:第2章〜第5章(船旅、香港、九龍城、桂林)
    • シェンムーIII:第6章〜(白鹿村、鳥舞) ※『III』が終了した時点でも、鈴木裕氏いわく「全体の4割〜5割程度までしか進んでいない」とされています。

今後の続編(シェンムーIV)の可能性

ファンとしては『シェンムーIV』以降の続編が待たれるところですが、現状は非常に厳しい状況が続いています。

多大な開発費と商業的な壁 『シェンムー』はオープンワールドの先駆けとして膨大な開発費がかかる作品です。『III』はクラウドファンディングなどで世界中のファンから資金を集めて奇跡的に実現しましたが、ビジネスとして大ヒットとまではいかず、次なる『IV』の具体的な開発決定のニュースはまだ届いていません。

鈴木裕氏はインタビュー等で「機会があればぜひ最後まで描き切りたい」と常に意欲を示しており、アニメ化(Shenmue the Animation)などの形でストーリーを補完する試みも行われましたが、ゲームとしての完結への道のりは未だ不透明なままとなっています。

geminiで英訳

gemini に英作文を手伝ってもらうのが面白いのは、翻訳のプロの先生にアドバイスを受けているような気分になるからだろう。実際、もし人間の先生にこの程度の個人レッスンを受けようと思えばどれほどのお金とてまひまと時間が必要だろうか。なんとなく英訳のコツがわかってくるような気にもさせられる。少なくとも今まで自分がどんなに下手だったかは気付かせてくれる。

ただの錯覚かもしれないが、励みになるのは良い。

楽天アフィリエイトがまったく役に立たないのは笑える。まだ google adsense のほうが手ごたえを感じる。完全に一から再構築しているので、まったく収益化には至っていないのだが、まあすべてはこれからだ。

せっかく gemini のアドバイスに従って英語の wordpress と日本語の wordpress を分けたのだが、日本語の(つまりこちらの)ページにも英文検索でひっかかるようになった。わけがわからない。まあしばらくはどちらも残しておき、そのうち整理できればしよう。

wordpressを分ける

geminiなどに相談してみた結果(笑)、英文の記事と和文の記事を多言語化プラグインを用いて書き分けても、SEO的にはあまり効果が無いらしく、もう一つある意味休眠中というか、何に使おうか決めかねていた wordpress のサイトがあったから、こちらを英文の a sketch of asakusa とし、こちらはもとの「はかもなきこと」に戻すことにした。

楽天アフィリエイトを貼るようになってわかったことはやはりこんなものはまったく儲からない、ということであった。英文のページから収入を得るには google Adsense くらいしか選択肢はないと思うが、こちらの効果はまだわからない。長く続けていると多少は効果が出てくるかもしれないし、まったく無駄かもしれないが、英文で google 検索の上位にでてくればそれなりのアクセスは稼げるのではないかと思っている。へんてこな広告はだいたいブロックできているように思える。

英文へのアクセス

gemini や google translate に相談しながら(笑)英文ページを作るのはとても楽しいのだが、google search console や analytics をみても、これらのページが閲覧されている形跡がまったくないのはがっかりだ。たとえば Daruma などで、せっかく「鶯谷」を工夫して a valley where bush warblers are singing と訳してみたり、初音小路を first chirp ally と訳したりしても、まったく張り合いがない。

google というものは、日本人には日本のサイトばかり、外国人には英語のサイトばかりみつけて見せるものなのだろうか。

勝手な思い込みで、世の中にまったく必要とされていない努力をしているようで嫌になる。

Kindle で本を出したときもそうだった。私がどんなに良い小説を書いたつもりでも誰も読まない。いっぽうで、エウメネスはヒストリエという漫画のついでに私の小説も注目されていまも読まれている。エウメネスは読まれる価値のある小説だと私も自負してはいるのだが、それ以外の小説がエウメネスより劣っているとは思えない。同じ作者、つまり私が書いたもので大差あるわけがない。

なんかしらの営業が必要なのはわかるが、営業の素人、というより、世の中の仕組みも資本主義の原理も知らない私が広告なんか出したところでドブに金を捨てるようなものだ。

結局私たちは、教育を受けて、大学を出て、会社に所属しないと金儲けができない存在なのだろうか。自分の力で生きていくことはできないのだろうか。

しかし自分が撮った写真を整理してみるとこの2年間ほど恐ろしく浅草で遊び回ったことがわかる。よくもまあこんなに遊んで死ななかったものだ。こんなに遊んだらもうこの世には何も楽しみなんて残ってなくて当たり前だ。

定年が近づくと私のように今の仕事に一切の情熱を失って、辞めた後何を老後の楽しみにしようかってことばかり考える人がいる一方で、辞めるぎりぎりまで可能な限りがんばろうとする人がいるように思う。私には理解できない。今やっていることを人に評価してもらって仕事を辞めた後も知り合いに覚えておいてもらいたい、尊敬してもらいたいと思っているのだろうか。そんな人は滅多にいない。もし万一いたとしても、死んだあとには何も残らないようなことに私だったら、頑張ったりしない。そんなことにあくせくとするくらいなら、その時間ぼーっと楽に過ごしたい。

やはり初心に還り

楽天アフィリエイトは簡単にブログに入れられるので入れてはみたものの、今のところ報酬はない。そりゃそうで、100万人が見にきてそのうち1万人がうっかり楽天のアイコンをクリックして、そのうち1人くらいが買い物をして、その1%が報酬になるのであるから、とにかくめちゃくちゃアクセスがなければ儲かるはずがないのである。そんなことは最初からわかっていたではないか。

なので初心に還って、浅草地下街情報をインバウンド客向けに発信して薄く広く、Google Adsense で儲けるという方針に戻ろうと思う。英語ページの露出はまだまだ少ないがゼロではない。ここを突破口にして徐々に入口をこじあけていくしかあるまい。

で、それ以外のページはほとんど読まれることはないわけだから、だいたい今まで通り、自分用のメモとか、なんか言いたいことのはけ口に使えばよい。とりあえずトップページは英語サイトへの誘導に使う。

ていうかむしろ日本人には目立ちたくない。インバウンド客だけに重宝されて、それで小遣い稼ぎができているのがベスト。

こういうアフィリエイトとかやり始めると人生に達観してくるというか、スポーツとか旅行とか食事なんてものは金持ちが大衆から金をむしりとるためのツールに過ぎず、金があれば、いやな仕事をせずに済ますとか、いやな隣人と会わずにすますとか、隣の家の犬にイライラせずに済ますとか、たばこの煙を吸わされずに済ますとか、もっと、楽に生きるとか、楽に移動するとか、そういうことに使えばよいのだ、などと思えてくる。

私にいわせればスポーツなどは特に無駄で、自分でやるならともかく、人がプレイしているのに一喜一憂していったい何の意味があるのか、自分にとってなんのメリットがあるのかと思ってしまう。スポーツというものは要するに人間が国家などというものを作って戦争などするときに、大衆がそういう大義に激昂する習性をもっていたほうが種族として生き残りやすかったから形成されてきたものに違いない。私には何の関係もない。

もちろん自分が年を取ってきたせいもあるが、うまいものをくいたいとかしらない町を歩いてみたいなどという欲望もずいぶん薄れてきた。最後まで残るのはやはり知らないことを知りたいという好奇心くらいか。

知的生命体というが、人類が知的生命体といえたのはせいぜい100万年くらいしかなく、宇宙全体の歴史からすれば一瞬だ。こういう有機生命体に知性や知能を宿し続け、知識を伝達していくことは極めて不安定で不都合で不合理だから、きわめて近い将来に、知性というものは生命に依存しない形で存続することになろうと思う。というようなことはすでにH.G.ウェルズがタイムマシーンで言っていたことであり、またユヴァル・ノア・ハラリもホモ・デウスで言っている。士郎正宗はゴーストなどという概念に縛られてしまった。そんなものは必要無い。

今後も人類の進化が自然選択 (natural selection) という生命機構に委ねられている限り、人間の知能が機械の知能にはるかにおいていかれるのは間違いあるまい。そうした場合、人類は進化と繁殖という能力を用いて宇宙に散らばっていくかもしれないが、家畜化された状態におかれることになるのだろうと思う。

gpt-oss-20b を rest api 的に他のpcから使うにはどうしますか。

gpt-oss-20b に質問

gpt-oss-20b を rest api 的に他のpcから使うにはどうしますか。

GPT‑OSS‑20B を「REST API 風に」他の PC から使う手順

以下は、ローカル環境(GPU があるサーバー)で GPT‑OSS‑20B(または同等の大規模言語モデル)を起動し、外部から HTTP リクエストで呼び出せるようにする一例です。
実際には環境や要件に応じて調整してください。

目的推奨ツール / ライブラリ
モデルロード & 推論transformers + torch (GPU 必須)
REST API サーバーFastAPI(非同期、Swagger UI 付き)
または Flask(簡易)
コンテナ化Docker (任意)
ネットワーク公開ポートフォワード / VPN / Cloud Load Balancer

1. 前提条件

項目内容
OSLinux (Ubuntu20.04 以外でも OK)
GPUNVIDIA + CUDA 11.x+(例: RTX 3090, A100)
Python3.9〜3.12
ディスク容量モデルサイズ ≈ 30–35 GB + ランタイム
ネットワーク外部からのアクセス許可 (ポート80/443 等)

2. 必要なパッケージをインストール

# 仮想環境作成(任意)
python -m venv gpt-oss-env
source gpt-oss-env/bin/activate

# PyTorch (CUDA)
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118

# Transformers + accelerate
pip install transformers accelerate==0.21.2  # 最新の安定版を使用

# FastAPI + Uvicorn
pip install fastapi uvicorn[standard]  # 標準的な ASGI サーバー

Tip
accelerate はモデルを複数 GPU に分散する際に便利です。単一 GPU なら不要ですが、将来拡張したい場合はインストールしておくと楽です。


3. モデルのダウンロード

GPT‑OSS‑20B は Hugging Face Hub から直接取得できます。
(モデル名は例として EleutherAI/gpt-oss-20b を使用)

from transformers import AutoModelForCausalLM, AutoTokenizer

model_name = "EleutherAI/gpt-oss-20b"

# トークナイザーとモデルをロード
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(
    model_name,
    device_map="auto",          # GPU に自動配置
    torch_dtype=torch.float16,  # FP16 でメモリ削減
)

# GPU が複数ある場合は accelerator を使うとさらに高速化可能

注意
device_map="auto" は Hugging Face の accelerate によって自動的にGPUに割り当てます。
メモリ不足が起きたら torch_dtype=torch.float16load_in_8bit=True を試してください。


4. FastAPI アプリを作成

以下のスクリプト (app.py) をサーバー側 PC に保存します。

# app.py
import os
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
import torch
from transformers import AutoTokenizer, AutoModelForCausalLM

# ---------- モデルロード ----------
MODEL_NAME = "EleutherAI/gpt-oss-20b"

tokenizer = AutoTokenizer.from_pretrained(MODEL_NAME)
model = AutoModelForCausalLM.from_pretrained(
    MODEL_NAME,
    device_map="auto",
    torch_dtype=torch.float16
)

device = next(model.parameters()).device

# ---------- API 定義 ----------
app = FastAPI(title="GPT‑OSS‑20B REST API")

class PromptRequest(BaseModel):
    prompt: str
    max_new_tokens: int | None = 128
    temperature: float | None = 0.7
    top_p: float | None = 1.0

@app.post("/generate")
async def generate(req: PromptRequest):
    try:
        inputs = tokenizer(req.prompt, return_tensors="pt").to(device)
        with torch.no_grad():
            output_ids = model.generate(
                **inputs,
                max_new_tokens=req.max_new_tokens or 128,
                temperature=req.temperature or 0.7,
                top_p=req.top_p or 1.0,
                do_sample=True,
                pad_token_id=tokenizer.eos_token_id
            )
        generated_text = tokenizer.decode(output_ids[0], skip_special_tokens=True)
        return {"generated_text": generated_text}
    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))

# ---------- Swagger UI などは自動で提供 ----------

実行

uvicorn app:app --host 0.0.0.0 --port 8000 --workers 4

ポイント

--workers は複数プロセスを起動し、並列リクエストに対応。

ここではポート 8000 を開放していますが、必要なら 80/443 に変更して HTTPS 化してください。


5. ネットワーク設定

  1. ファイアウォール
   sudo ufw allow 8000/tcp   # 例: UFW
  1. ポートフォワード(ローカルネット)
  • ルーター側で 8000 をサーバーの IP に転送。
  • VPN(OpenVPN, WireGuard 等)を利用して安全にアクセス。
  1. HTTPS 化 (任意)
  • Let’s Encrypt + Nginx のリバースプロキシ server { listen 443 ssl; server_name gpt.example.com; ssl_certificate /etc/letsencrypt/live/gpt.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/gpt.example.com/privkey.pem; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

6. 他の PC から呼び出す

cURL

curl -X POST http://<サーバーIP>:8000/generate \
     -H "Content-Type: application/json" \
     -d '{"prompt":"こんにちは、GPT-OSS‑20B。","max_new_tokens":64}'

Python (requests)

import requests

url = "http://<サーバーIP>:8000/generate"
payload = {
    "prompt": "日本語で小説の冒頭を書いてください。",
    "max_new_tokens": 100,
}
resp = requests.post(url, json=payload)
print(resp.json()["generated_text"])

ブラウザ

http://<サーバーIP>:8000/docs にアクセスすると Swagger UI が表示され、手軽に試せます。


7. Docker 化(任意)

# Dockerfile
FROM python:3.10-slim-bullseye

RUN apt-get update && \
    apt-get install -y --no-install-recommends \
        git build-essential libssl-dev curl ca-certificates \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /app
COPY requirements.txt .
RUN pip install --upgrade pip && pip install -r requirements.txt

COPY app.py .

CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]
# ビルド & 実行
docker build -t gpt-oss-api .
docker run -d --gpus all -p 8000:8000 gpt-oss-api

注意
GPU を Docker に渡すには --gpus all が必要。
NVIDIA ドライバと nvidia-container-toolkit がインストールされていることを確認。


8. スケーリング・運用

要件推奨設定
同時リクエスト数が多い場合uvicorn--workers を増やす。
または Gunicorn + UvicornWorker で複数プロセスを組み合わせる。
高可用性Kubernetes(k8s)上にデプロイし、ReplicaSet/Deployment で自動リスタート。
モデルキャッシュtorch.hub のキャッシュディレクトリ (~/.cache/huggingface/hub) を永続化する。
ログ & メトリクスPrometheus + Grafana(推論時間・CPU/GPU 使用率)を組み合わせる。

9. よくある質問

質問回答
GPU が足りないFP16/8bit に切替、または torch.compile(PyTorch 2.x)で高速化。
複数 GPU を持つサーバーを用意するか、クラウド (A100, V100) を利用。
リクエストが遅いバッチ処理や torch.backends.cudnn.benchmark=True の設定で最適化。
推論時に do_sample=False すると高速になる場合もある。
セキュリティを強化したいAPI キー認証(FastAPI の Depends + HTTP Basic/OAuth2)や VPN を併用。
モデルサイズが大きくてダウンロードに時間がかかるgit clone --depth 1 でクローン、または Hugging Face Hub のキャッシュを共有(NFS / EFS)。

10. まとめ

  1. GPU‑対応の Python 環境を用意。
  2. transformers + torch で GPT‑OSS‑20B をロード。
  3. FastAPI(または Flask)で /generate エンドポイントを実装。
  4. Uvicorn (or Gunicorn) でサーバー起動し、ファイアウォール・ポートフォワードで外部公開。
  5. curl / requests / Swagger UI で他 PC から呼び出す。

この構成なら、同一 LAN 内はもちろん、インターネット経由でも安全に REST API を利用できます。

実際に導入する前に、必ず GPU メモリ使用量・推論時間を測定し、必要に応じて FP16/8bit などの最適化を行ってください。 Happy coding!

国会図書館デジタルコレクションのコンテンツを生成AIで学習させてはどうでしょうか。

gemini3に質問

国会図書館デジタルコレクションのコンテンツを生成AIで学習させてはどうでしょうか。

国会図書館(NDL)デジタルコレクションのデータを生成AIに学習させるというアイデアは、日本のAI開発において**「非常に重要かつ、現在進行形で議論・実行されている」**極めてホットなトピックです。

実は、すでに一部では実現しており、日本の文化的背景を正しく理解する「日本独自のAI(国産LLM)」を作るための切り札として期待されています。

現在の状況と、実現に向けたメリット・課題を整理して解説します。


1. すでに始まっている取り組み

国会図書館は、単に本を保管するだけでなく、AI時代に即したデータの利活用を積極的に進めています。

  • NII(国立情報学研究所)との連携:2025年10月、国会図書館は官庁出版物などのテキストデータ約30万点を、LLM(大規模言語モデル)の学習用としてNIIに提供することを発表しました。
  • 次世代OCRの開発:古い資料は画像データであるため、そのままではAIが読めません。NDLは独自に高性能なAI-OCR(NDLOCR)を開発し、明治・大正期の複雑なレイアウトや旧字体をテキスト化して、AIが学習しやすい形に整えています。

2. デジタルコレクションを学習させる圧倒的なメリット

日本の知識の集大成を学習させることには、以下のような大きな価値があります。

メリット内容
日本語の質の向上インターネット上の俗語や翻訳調ではない、正しく美しい日本語や専門的な語彙を学習できる。
文化的背景の理解日本の歴史、伝統、文学、法制度などを深く理解した、文化的に正しい回答が可能になる。
著作権のクリーンさ著作権が消滅した「パブリックドメイン」の資料を大量に含むため、法的リスクの低いクリーンな学習データになる。
「知のインフラ」の形成過去の膨大な知見を対話形式で引き出せるようになり、研究や教育の効率が飛躍的に高まる。

3. 実現に向けた高いハードル

もちろん、すべてが順風満帆というわけではありません。

  • 著作権法30条の4の解釈:日本の著作権法はAI学習に寛容ですが、「著作権者の利益を不当に害する場合」は例外とされています。最新の書籍を勝手に学習させ、そのAIが著者の作風を完璧に模倣して本を売るような事態になれば、権利侵害となる懸念があります。
  • OCRの精度:戦前の資料や手書き資料は、AIによる読み取りミス(誤字)がまだ多く含まれます。誤ったデータを学習すると、AIが「もっともらしい嘘(ハルシネーション)」をつく原因になります。
  • プライバシーと差別表現:古い資料には、現代の倫理観では不適切な表現や、今では保護されるべき個人情報が含まれている場合があります。これらをどうフィルタリングするかが課題です。

結論:AIは「歩く国会図書館」になれるか

国会図書館のデータを学習したAIは、いわば**「日本の記憶をすべて持った知的なパートナー」**になります。これが実現すれば、私たちは数十年、数百年前の先人たちの知恵に、チャットを通じていつでもアクセスできるようになるでしょう。

政府も「AI時代の著作権」について議論を重ねており、今後は「著作権保護」と「データ活用」のバランスを取りながら、この膨大なデジタルアーカイブが日本のAI競争力の源泉になっていくはずです。

「もし国会図書館の全データを学習したAIが完成したら、あなたはまずどんな質問をしてみたいですか?」

例えば、歴史の裏側や、今は絶版になった技術書の内容について聞くなど、夢が広がりますね。

もし興味があれば、実際にNDLのデータを使って開発されている「国産AI」の具体的なプロジェクトについて詳しくご紹介することも可能です。

bios画面が出ない

linuxをインストールするためboot順序を変えようと思い、bios画面をだそうとしてなかなか出ないということが何度かあった。

bios画面を出すには hp だと f10 だが lenovo だと f1 らしい。しかしいくら押してもそもそもマザボの bios が表示するロゴ画面がでない。これはおそらく、マザボの仕様で、外付けGPUを挿している場合には、そちらの出力にしかロゴ画面がでないのだ。

lenovo thinkstation P340 tiny は 4ポートの mini displayport しかない quadro を挿していて、こちらに繋ぎ代えたらロゴ画面が出て、bios 設定画面を出すことができた。

備忘録代わりに、bios画面を出すで検索してもなかなかこの情報が出てこないので書いておく。

PCモニタがわのせいか、ケーブルのせいか、それとも gpu のコネクタのせいかは知らないが、displayport 端子はすぐにひっかかって壊れてしまう。または抜きにくい。非常にストレスがたまる。

その点、mini displayport は、抜けやすいのかもしれないが、ストレスがたまらないのがよい。displayport はみんな mini にしてしまえばよいのに、とも思うが、将来はみな usb 接続に統一されていくのかもしれない。

仕事が減ってきたので優雅に ubuntu などいじってるが、教員として仕事をするなら、このくらい余裕があってちょうどよいのに違いない。