  |
はてなキーワード:seleniumとは
このまま日本で働き続けた場合の未来シナリオ（5年ごと）2025～2030年（32～37歳）「消耗フェーズ」プロジェクトの遅延対応で残業・休日出勤が常態化
英語は「読み書き中心」で会話力伸びず（IELTS 6.0止まり）
この時期に「スキル停滞＋過労」が確定する
2030～2035年（37～42歳）「リストラ・再雇用フェーズ」黒字リストラの対象年齢（40歳前後）
2035～2040年（42～47歳）「老後不安フェーズ」年金は月10万以下（氷河期世代＋納付期間不足）
「働きたくても雇われない」状態
なぜこうなるのか？（構造的要因）要因
あなたの状況への影響
人口減少
昨日一番肝心なファイルなのにURLとみなされる部分が多いことの関係で投稿できなかったのでそれを小分けにして書く。
小分けというか例のスパムの影響でNGワードに引っかかっていたようなのでそこだけ書き換えた。
suuportと書いていある部分は元のコードでは当然uが一つ少ないので利用するときはそうすること。
fromselenium importwebdriver
fromselenium.webdriver.chrome.options import Options
fromselenium.webdriver.chrome.service import Service
fromwebdriver_manager.chrome importChromeDriverManager # ← 追加
fromselenium.webdriver.common.by importBy
fromselenium.webdriver.suupport.ui importWebDriverWait
fromselenium.webdriver.suupport import expected_conditionsasEC
importtime,json
fromselenium.common.exceptions importTimeoutException
class HatenaClient:
def __init__(self, username,password):
self.username = username
self.password =password
self.driver = None
def start_browser(self):
options = Options()
options.set_capability("goog:loggingPrefs", {"browser": "ALL"})
options.add_argument("--headless=new") # 開発中は消してよい
options.add_argument("--disable-gpu")
# ✅webdriver-manager を使ってChromeDriver を自動取得・設定
service = Service(ChromeDriverManager().install())
self.driver =webdriver.Chrome(service=service, options=options)
deflogin(self):
self.driver.get("https://b.hatena.ne.jp/my")
print(self.driver.current_url)
self.driver.get("https://www.hatena.ne.jp/login")
time.sleep(2)
self.driver.find_element(By.NAME, "username").send_keys(self.username)
self.driver.find_element(By.NAME, "password").send_keys(self.password)
self.driver.find_element(By.XPATH, "//button[contains(text(), 'ログイン')]").click()
WebDriverWait(self.driver,10).until(lambda d: "my" in d.current_url or "login" not in d.current_url)
if "passkeys" in self.driver.current_url:
self.driver.get("https://b.hatena.ne.jp/my")
print(self.driver.current_url)
print(self.driver.title)
return "dorawii" in self.driver.current_url
defadd_bookmark(self, target_url):
self.driver.get(f"https://b.hatena.ne.jp/{self.username}/add.confirm?url={target_url}")
time.sleep(2)
try:
#コメントがあれば入力
comment_box = self.driver.find_element(By.CSS_SELECTOR, "textarea.bookmarkadd-comment-form")
comment_box.clear()
comment_box.send_keys("わしが書いた")
#登録ボタンを押す
save_button = self.driver.find_element(By.CSS_SELECTOR, "input.bookmarkadd-submit-btn")
save_button.click()
time.sleep(2)
returnTrue
except Exceptionas e:
print(f"Bookmark failed: {e}")
returnFalse
def quit(self):
self.driver.quit()
-----BEGINPGP SIGNEDMESSAGE-----
Hash: SHA512
https://anond.hatelabo.jp/20250822131958#
-----BEGINPGP SIGNATURE-----
iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaKfv9AAKCRBwMdsubs4+
SE26AQCkpJE4RdUbFIDIJjOunjFYRQ34zdS1cqV7IX277S7IPAEAshVE/rD8Ggcr
9UKo5yOY6GNrHGYJJtYTYkn3cySu6AA=
=E4vq
-----ENDPGP SIGNATURE-----
サウンド・エンジニアでよいの? にしても文脈的に違和感あるが。
「SE」という言葉は文脈によって異なる意味を持つことがありますが、システムエンジニア（System Engineer）以外で一般的なものをいくつか挙げます：
インターネット上の情報を検索するためのツールやサービス。例：Google、Yahoo!、Bingなど。
Software Engineer（ソフトウェアエンジニア）
ソフトウェアの設計・開発・保守を行う技術者。システムエンジニアと似ていますが、よりソフトウェア開発に特化。
技術的な知識を持ち、製品やサービスの販売をサポートする役割。顧客に技術的な説明や提案を行う。
Special Edition（特別版）
株式や債券などの取引が行われる場所。例：東京証券取引所（東証）。
夏競馬が始まると、決まって湧いてくる「オッズ操作」を疑うやつが netkeiba に多すぎる。
地方競馬ならまだしも、公営ギャンブルの厳しさは競馬ファンなら知ってるだろう、間違ってスマホを控え室に持ち込むだけで、使わなくても、処分される世界だということを忘れないで欲しい。
ではなぜこんなにオッズが急激に下がることが起きるのか。純粋にお前らのせいだよ。
まずこれ。夏競馬はこの暑い中で走る。ちょっとでも体調が悪い馬は、能力があってもあっさり凡走する（なんならここ３週間は故障も多発してる）可能性が跳ね上がる。
だから、特にうまプロ（笑）は、ギリギリまで馬の状態を見極める。直前の返し馬の動き、馬体、汗のかき方、パドックでの雰囲気…これらを総合的に判断して、最終的な買い目を決める。
最近はうまプロがその情報を X やYouTube に流す。それを見てる人が追従する。その結果、締切直前に特定の馬に投票が集中して、結果的にオッズが下がる。というかお前らも普通にやってると思うんだけどな。お前がいいと思った馬はみんないいと思ってるだけ。
これもデカい。夏競馬って、やっぱり世間の注目度は低い。春のG1レースが目白押しだった頃と比べて、馬券を買う人間の数が圧倒的に少なくなる。
結果、普段なら数百万、数千万の票が入るレースでも、夏だとその何分の一か、ひどいと数十分の一しか票が入らない。そこに、いわゆる「ぶっ込み」が入ったら、あっという間にオッズが動く。
普段なら埋もれるような金額でも、参加者が少ない夏競馬では、オッズを破壊する力がある。これを一部の金持ちがオッズ操作しているように見えるかもしれないが、ただ単に市場規模が小さいから起こる。
雲隠れしてるYouTuberみたいなこと言っちゃうけど、パリミュチュエル方式を理解とけまじで。
前から自動馬券購入ツールはある（なんならJRA-VANが公開している）。
そしてスマホ版の即PAT見たらわかるけど、正直めちゃくちゃ作りがチープで、自動操作はかなりやりやすく、PlaywrightとかSelenium触ったことあるやつならだれでも自動化できるレベルだし、なんならLLMで土台準備するのもやる気あればできちゃうんじゃないかね。それぐらい敷居は下がっている。
株式市場でアルゴリズム取引が普及して、去年も理由もなく株価が下がった時期があるがあれと一緒で、特定条件に該当する（期待値とオッズのバランスが崩れていて旨みがある）ところに一気に投票が集中する。
そもそもこんなツールを本格運用していたり本気で作る人は競馬を投資だと捉えて運用するだろうから、そこそこでかい額がベッドされていても何もおかしくない。そうすれば簡単にオッズは変動してくる。
程よく遊べ程よく。
最近は最前線から離れててあんまり追えてないけど、現役のときの2008年くらいから10年くらいの間で、仕事のやり方や設計の考え方が大きく変わったIT技術要素で、いまぱっと思い浮かぶのはこんな感じかな。
分野にもよるし、調査して試作した結果自分の業務には採用しなかった技術とかもある。流行ると思って使えるようになったけど流行らなかった技術を入れるとたぶんもっとある。
あと、新機種が出てOSが新しくなったり、ミドルウェアの新バージョン対応、テスト手法の進化もけっこうカロリー高いけどここには書いてない。
「自分はフロントエンド専門でReactしかやらない」みたいに分野を絞れば大分減るけど、その技術が何年持つかわからないから普通はリスクヘッジのために他の技術も齧らざるを得ないし、バックエンドとかの人と議論するのに結局他分野の知識もそれなりに必要。
NoSQL(memcached,Redis,Cassandra)
クラウドアーキテクチャ、XaaS(AWS,Google Cloud, MicrosoftAzure)
CI/CD(TravisCI,CircleCI,Jenkins)
トランスパイラ(Browserify, webpack,CoffeeScript,TypeScript)
型システム(Rust,TypeScript,Haskell)
オーケストレーション(Ansible,Kubernetes, Terraform)
SPA(React, AngularJS, Ember.js,Vue.js)
3Dゲームエンジン(Unreal Engine無償化、Unity5)の他分野への普及
GraphQL
機械学習ライブラリ(Tensorflow, PyTorch,Chainer)
Jupyter Notebook
NFT
増田を全削除するのであればPowerAutomationDesktopかSeleniumIDEあたりでも使えば可能ですが、中にはブクマを集めた珠玉の増田やブクマは付かなくても割と気に入ってる増田もあるので全削除はしたくありませんでした。
Masuda Deleter
https://github.com/oribeolive/masuda-deleter/
Masuda DeleterはDockerコンテナに環境を作って動くのでDockerが必要です。
M1Macで動作していますがWindowsは検証できるマシンが手元にないので動作未確認です。
インストールはGitHubのREADMEに書かれたコマンドを実行すればできると思います。
Masuda Deleterははてラボにログインして指定されたページ分の自分の増田の投稿をスクレイピングしてローカルのDBに保存します。
取得された投稿のリストがブラウザで見られるので、そこで削除するものを選んで実行すると、またログインして投稿を削除しにいきます。
ページのアクセスごとに読み込みと遠慮のために1秒から数秒sleepするので少し時間がかかります。
一旦投稿をローカルに保存するという過程があるため副作用として自分の投稿を検索できます。
これにより
が容易になります。
増田にはAPIがないので、IDとパスワードを使ってログインして、表示されている文章をスクレイピングしてくるという原始的なやり方になります。
(2回目からはcookieがある場合はcookieを復元してログイン状態になります。)
ユーザーが知らない外部サイトにクレデンシャルを渡すのは危険であり、サービス運営側としてもパスワードを平文で持ちたくないので、Webサービスとして実装せずセルフサービスとしております。
ユーザーによってローカルの.envファイルに書かれたIDとパスワードを使用する形です。
ソースをオープンしておりますので怪しいことをしていないかも確認ができるかと思います。
一応下にプログレスバーが出ますが、ページ遷移すると見られなくなります。進捗は進捗管理でも確認できます。
取得された投稿はリアルタイムで画面に反映されないのでブラウザをリロードしてください。
増田のID、タイトル、本文の省略、投稿日時、ブクマ数、トラバ数が表示されます。
「あとで消す」投稿をチェックし、「あとで消す」記事をついに消すボタンで削除を実行します。
チェックは別のページに遷移しても有効です。
こちらは実行した時点で表示されているページのみリアルタイムに画面に反映されます。
投稿の全文を見られます。タグ等は取得しないのでテキストのみになります。
投稿を個別に取得してローカルの文章とブクマ数とトラバ数を更新します。
対象の投稿のタイトルを空に、本文をスペース1文字にしにいきます。
処理の進捗(何件中何件処理済みか)を見ることと、処理を停止させることができます。
排他処理(取込と取込、特定IDの削除と同じIDの削除等)にしているので動いていなそうな処理を停止して再度処理を実行するときに使います。
停止する場合は停止ボタンを押すか、それでも停止しそうにない場合は強制停止ボタンを押してください。
「停止」は今行っている最中の処理ではなく次以降の処理を停止するという形になります。
停止ボタンを押したときに4ページ目を取得している場合は、5ページ目の取得を始める前に処理を終了することになります。
そのためプロセスそのものが止まっている場合は停止されません。
「強制停止」はプロセスをkillします。スクリプト名とプロセスIDでプロセスを検索して子プロセスも含めてkillします。
おまけとして、投稿日とブクマ数、投稿日と3ブクマ以上の投稿の件数、投稿時間(hour)ごとの1ブクマ以上の投稿の件数のグラフが見られます。
ブクマが付いた瞬間ではなく投稿日時なので、いつの時期に投稿した、何時に投稿した増田が活きが良いのかを見られる程度です。
集計データを別に持っていないので増田を削除するとグラフに使用されるデータも消えます。
私はこれで多いときには4000件程度あった増田を3000件程度に減らしました。
これを開発する前からも増え続ける増田の削除に日々勤しんでいたので総数はもっと多いはず。
まだまだ削除したいです。
たまに
Message: unknownerror:net::ERR_CONNECTION_CLOSED
というSeleniumのエラーが出て処理が実行されないことがあります。再度実行してください。
フロントエンドがレガシーなのでMasuda Deleterの開発に飽きていなければもう少しモダンにリプレースしようと思っています。
dockerでubuntu:20.04でchromeDriverにchromium-browserとか入れればいいんだろ？
誰か「chromium-browser？ それならapt-get installlsb-release libappindicator3-1 の次に
wgethttps：//dl.goo略/_amd64.deb して dpkg でインスコや」
ってか、これじゃchromeDriverが動かない。chromium-browser も無いし、インスコ出来てなくない？
別の誰か「ちゃうちゃう、apt-get installchromium-browser がシンプルでええやん」
まあ、そうやろな。インスコしとくれ。
ターミナル「色々DLしとるが、どっかのhttps：//archve.略/foobar で Bad Request が返ってきたでｗ」
何やそれ・・1回くらい自動でリトライしてくれていいんやない？自分でリトライしたら通ったで。
しかしこれも動かない。
別の誰か「apt-get install default-jre いるみたいやで。ドキュメントどこにも書かれてないけど」
何やそれ？なんでJREが出てくるの。
まあJRE入れれば、確かにchromedriverの出すエラーは変わった。
「chromium-browserのプロセスが居なくなったし、クラッシュしたんじゃね？」と。
何やそれ。。。
chromium-browser --version をやってみると
ターミナル「snap installchromium でsnap版入れてくれｗ」
まあよく知らんが、やったるか。snap installchromium っと
ターミナル「あかん、http：//localhost/v2/snaps/chromium に繋げられんのやがｗ」
なんでlocalhostに繋げようとしてんの。
いまだにLinuxくんと仲良くできない。
追記。
なるほど、Ubuntu20.04からはsnappyに移行しとるんだと。しかしWSL2ではsystemdが動いてないんでsnapdも動いてない。だからアカン。
わいが仲良くできていないのは、LinuxくんではなくWSL2くんと言うべきなのか？
転職歴としては1社目は新卒で入った地元の零細受託Web制作会社→4年前くらいに転職し現在自社サービス企業に勤務中。
ちなみにまだ内定は0件。
コロナを機にフルリモート案件が増えたのと、リーダー経験とか積むにつれて市場価値と今の職場が合わなくなってきたのがあるのと、
今の年収だと婚活で戦うのはかなりきついということを実感したので動き出すことに。現年収は400万ちょっとくらい。
専門卒で経験はPHP/JS中心だから経験してきた技術スタックや学歴的にはあんまり上位狙えるようなアレじゃないんけど今回は心が折れるまでは初年度年収600万を目指すことに。
現職でのリーダー経験と、Saasを立ち上げから設計・開発全部8割型自分で進めて競合と戦えるサービスに成長させた経験とか、ゼロイチで既存案件をDDDに移行したりテスト駆動体制を導入したりとか、まあまあ個人開発もやってますよとかその辺をアピールポイントとして戦うことに。
肌感覚としては「500万までは余裕だけど600万はきつい」だわ。
まず某転職サイトに応募すると早速600万のスカウトが来たユニコーン系ベンチャー。フルリモート。
「貴方のSaas開発経験に魅力を感じ～」とか書いてたから誰でも送ってる風じゃないと思い応募。
結果はなんと書類選考落ち。いや学歴とか職務経歴とかほぼ転職サイトにそのまま書いとったやん。
恐らくだけど選考時にGithubアカウントとかTwitterアカウントを求められたときに仕事用のものはセキュリティ上渡せないとか渋ったのと、
渋々渡した個人用Githubアカウントはオープンソース活動とかはしたことなかったからこれがしょぼいって思われたのかな？って思った
ちなみにこの会社からは書類選考落ち後に各転職サイトから5回くらいスカウトが来てる。
大手っていうわけではないけど割と有名なSaas企業。こっちもスカウト。転職サイトの上の方でよく見る気がする。
結構近しい分野のSaasを立ち上げから関わったことがあるのでこちらを武器に面接へ。1次面接落ち。
面接は割とうまく行ったと思うけどなぁ、って思ったけどやっぱりフルリモートでこの給与帯の休日は倍率半端なさそうだからちょっと良いくらいだと全然落ちるんだなと実感。
立ち上げから3年も経っていないベンチャー、ただし既に利益率は割と凄い感じで業界的にも硬そうだから応募。
カジュアル面談のときにCTOに是非応募してほしいって直接言われた。
1次の技術面接のレベルがたけぇ。○○の設計思想の内容だとかDIコンテナとかReactの状態管理用ライブラリの運用とかの質問をクイズ形式っぽく質問される。
割とうまく答えられたと思ったけど1次面接落ち。
有名地元に拠点がある東証一部上場の自社サービス企業。600万の求人と450万の求人で分かれてて600万の方で応募したら書類選考で「600万は厳しいけど450万なら良いですよ～」って言われてる状態。
やっぱ相場観的にはそうだよなぁって思った。
今週1次選考だけど受かっても年収交渉時に450万しかもらえないなら辞退しちゃうかも。
有名医療系ベンチャーと車業界系のSaas。カジュアル面談の要請出すも音沙汰なし。
別の転職サイトで確認すると応募条件大卒以上って書いてたから多分それが原因。ちゃんと書いとけや。実質書類落ち。
少人数の建築系ベンチャー。HPの情報量も少なく恐らく資金調達のフェーズでは？って感じの企業。
なんとなく社長から与沢翼の匂いがする。まだマネタイズまで行けてないのに何百億とか何兆とかやたらでかい数字を言いたがる感じ。
技術スタックに対して年収が高すぎるのが逆に怪しい感じがする。
一応最終選考まで残ってるが、通ったとして行くべきかは悩みどころ……
スカウト来て応募。かなり好感触だが求人票と実態の下限年収に相違あって思ってた年収より100万くらい下がりそう。
去年末くらいから始めた転職活動。今週も面接面接面談面談面接。
自分の市場価値みたいなところは良くも悪くも痛感する。500万までのスカウトはよく来るけど600万になるとやっぱなかなかこない。これが相場観なんだろうなって感じ。
「テックリード」とか「シニア」とかのスカウトは全く来ないからまだそういうレベルではないんだなぁって。
「誰もが知る有名企業で年収600万」は多分俺のスペックだと無理ゲーで、あとはいかに穴場のベンチャー狙えるかっていうところにかかってる感じ。
それはそれで安定捨てて市場価値より高い会社に勤める感じになるわけだし将来トータルで考えるとそれはそれで大丈夫なの？って感じもある。
でも専門卒じゃ20代現年収600万くらい武器ないと婚活じゃ戦えないしなぁとも……はよ彼女作ってこの悩みから開放されたい……
エントリーする度にそこで働く未来の自分を思い浮かべるのに祈られた瞬間に全部がなかったことになるの辛い
あとカジュアル面談受けまくってるけど、これが割と面白かったりする。
「こんな有名企業だけどQAは俺がリーダーやってる案件のがカバレッジ率とかしっかりしてるんだー、バグったら人が死ぬタイプのシステムじゃないし逆に今の運用が過剰品質すぎなのかなぁ」「LeSSって開発手法あるんだー」「前職も現職もSelenium導入って微妙な感じになってるけどこのMablってテストツールだと割と良い感じかも」「今の職場みたいに運用フェーズのエンジニア部署でKPI設定を半期ごとに設定するのは粒度がでかすぎるよなぁ、この会社みたいに1ヶ月周期とかで設定した方がよさそう」「ワーカーサーバーの悩むポイントはどこも同じだなぁ、でもやっぱGoだとPHPよりも並列処理強いんだなぁ」
他の会社の運用とか技術スタックの話を深堀りして質問しまくれる機会とかなかなかないから、落ちたは落ちたなりに吸収できるものはある気がする。
あと社交辞令かもしれんけど「いやその経験と技術力で今の年収はどう考えてもおかしいっすよ」とか結構言ってくれるの嬉しい。
諸君は巨乳と聞いたとき大体どのくらいの大きさを想像するだろうか。EカップやFカップ？それともGカップだろうか。世の中には巨乳の最頻値がHカップであり中にはQカップなどという存在が出てくる分野が存在する。それはユーザ投稿サイトの男性向けエロ小説である。
本稿ではノクターンノベルズ*1に投稿された短編を解析することで男性向けジャンルで好まれるバストサイズの変遷を調べる。特に読者・作者に巨大と認識されるカップサイズが年を重ねる毎に増大していることを明らかにする。(なぜそんなこと調べたのかというと、小説漁りしてる時になんか最近極端に大きなバストサイズが多いなーって感じたから。以上！)本文章は男のアホさをご了承の上、特に女性の方々におかれましてはリアリティの欠如や空想すぎる産物への指摘を留めて頂き、男ってバカだなぁと笑って読んで下さい。
*1株式会社ナイトランタンの提供する男性向け18禁版小説家になろう
2006年から2020年までの各年(2020年のみ12月29日まで)に投稿された短編を総合ポイントの高い順に百本抽出した。そして各小説の調査フィールド(タイトル、概要、タグ、本文)に対して、MeCab+mecab-ipadic-NEologd(およびAからZまでのカップ数を羅列したユーザ辞書)による形態素解析を実行し、キーワードの出現回数を数えた。検証対象を短編に制限した理由は、キャラクター内面の作り込める長編小説と異なり、R18短編小説は表面上の属性(巨乳とか巨乳とか)が市場の潜在的な需要を反映する傾向にあると考えたからである。すべてのコードはPython 3 で実装した(実装としては年齢認証を突破するため適当にSelenium 叩いているだけ。コードとデータが欲しいという物好きがいたらgithub にでも上げるので言って下さい)。注意点として、小説ポイントは積み上げ式であるため、当時は人気がなかったが後年に人気が出てポイントが上がった可能性は排除できない。よって当時の人気を厳密に反映しているわけではなく、現時点での総合人気ということでご容赦を。
はじめに検証対象となる短編の総投稿本数を示す。各年の短編投稿本数は以下の表1の通り年々上昇している。
| 2006 | 2007 | 2008 | 2009 | 2010 | 2011 | 2012 | 2013 | 2014 | 2015 | 2016 | 2017 | 2018 | 2019 | 2020 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 26 | 117 | 238 | 218 | 163 | 387 | 342 | 488 | 651 | 834 | 911 | 1103 | 1668 | 1165 | 2470 |
表2は本研究のメインデータとなる、調査フィールド(小説のタイトル、概要、タグそして本文)にバストサイズに関連するキーワードを含む短編の数である。ヘッダーのAからRはカップ数を表している。なおOカップ、Pカップ、およびSカップ以降は出現しなかったため省いている。表3は表2の均していないデータ、つまり調査フィールドでのキーワードの出現合算(連呼頻度)である。
| 表2 | A | B | C | D | E | F | G | H | I | J | K | L | M | Q | R | # | 貧乳 | 巨乳 | 爆乳 | 表3 | A | B | C | D | E | F | G | H | I | J | K | L | M | Q | R | # | 貧乳 | 巨乳 | 爆乳 | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | # | 1 | 3 | 0 | 2006 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | # | 2 | 11 | 0 | |
| 2007 | 1 | 0 | 1 | 3 | 2 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | # | 0 | 6 | 1 | 2007 | 2 | 0 | 3 | 4 | 2 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | # | 0 | 16 | 3 | |
| 2008 | 1 | 4 | 3 | 3 | 4 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | # | 0 | 7 | 0 | 2008 | 2 | 7 | 7 | 5 | 4 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | # | 0 | 10 | 0 | |
| 2009 | 1 | 1 | 0 | 0 | 0 | 3 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | # | 2 | 7 | 2 | 2009 | 2 | 3 | 0 | 0 | 0 | 5 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | # | 4 | 29 | 4 | |
| 2010 | 0 | 3 | 0 | 0 | 0 | 2 | 2 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | # | 2 | 5 | 0 | 2010 | 0 | 3 | 0 | 0 | 0 | 2 | 2 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | # | 2 | 11 | 0 | |
| 2011 | 0 | 0 | 2 | 1 | 1 | 0 | 2 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | # | 3 | 16 | 8 | 2011 | 0 | 0 | 2 | 1 | 1 | 0 | 8 | 5 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | # | 7 | 48 | 21 | |
| 2012 | 0 | 2 | 2 | 2 | 0 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | # | 1 | 15 | 3 | 2012 | 0 | 7 | 2 | 4 | 0 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | # | 1 | 29 | 3 | |
| 2013 | 1 | 2 | 0 | 3 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | # | 1 | 9 | 3 | 2013 | 2 | 2 | 0 | 3 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | # | 1 | 12 | 4 | |
| 2014 | 2 | 2 | 5 | 0 | 2 | 2 | 3 | 3 | 5 | 2 | 1 | 2 | 2 | 0 | 0 | # | 4 | 24 | 10 | 2014 | 4 | 2 | 5 | 0 | 7 | 2 | 4 | 5 | 18 | 3 | 1 | 4 | 2 | 0 | 0 | # | 9 | 54 | 27 | |
| 2015 | 0 | 0 | 1 | 1 | 1 | 2 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | # | 4 | 23 | 5 | 2015 | 0 | 0 | 1 | 7 | 1 | 6 | 2 | 1 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | # | 4 | 54 | 36 | |
| 2016 | 1 | 1 | 0 | 1 | 1 | 0 | 2 | 2 | 2 | 1 | 1 | 0 | 0 | 0 | 1 | # | 4 | 22 | 9 | 2016 | 1 | 1 | 0 | 1 | 1 | 0 | 2 | 4 | 3 | 1 | 1 | 0 | 0 | 0 | 1 | # | 12 | 48 | 30 | |
| 2017 | 0 | 2 | 1 | 0 | 2 | 1 | 0 | 4 | 1 | 1 | 0 | 0 | 1 | 0 | 0 | # | 9 | 32 | 10 | 2017 | 0 | 2 | 2 | 0 | 4 | 1 | 0 | 16 | 1 | 6 | 0 | 0 | 5 | 0 | 0 | # | 15 | 101 | 33 | |
| 2018 | 1 | 1 | 2 | 0 | 2 | 2 | 2 | 4 | 3 | 0 | 2 | 0 | 0 | 0 | 0 | # | 7 | 34 | 8 | 2018 | 1 | 3 | 2 | 0 | 4 | 2 | 9 | 6 | 6 | 0 | 3 | 0 | 0 | 0 | 0 | # | 8 | 134 | 53 | |
| 2019 | 0 | 0 | 0 | 0 | 1 | 2 | 4 | 4 | 4 | 4 | 5 | 1 | 1 | 0 | 0 | # | 3 | 37 | 22 | 2019 | 0 | 0 | 0 | 0 | 1 | 4 | 9 | 8 | 17 | 19 | 9 | 2 | 3 | 0 | 0 | # | 11 | 95 | 120 | |
| 2020 | 1 | 0 | 0 | 0 | 2 | 4 | 8 | 10 | 1 | 3 | 2 | 1 | 0 | 1 | 0 | # | 5 | 43 | 18 | 2020 | 1 | 0 | 0 | 0 | 6 | 6 | 13 | 13 | 2 | 5 | 10 | 1 | 0 | 10 | 0 | # | 8 | 116 | 216 | |
| 合計 | 9 | 18 | 17 | 14 | 18 | 24 | 25 | 30 | 17 | 11 | 11 | 4 | 4 | 1 | 1 | # | 46 | 283 | 99 | 合計 | 15 | 30 | 24 | 25 | 31 | 34 | 50 | 60 | 49 | 34 | 24 | 7 | 10 | 10 | 1 | # | 84 | 768 | 550 |
これらの表よりノクターンノベルズにおいて次のような傾向が存在することが分かる。
以上よりノクターンの短編部門においてカップ数のインフレ傾向が存在することは立証できた。しかしここまで読んできて次のような疑問を抱かなかっただろうか。カップ数の増大は確かだがそれと物理的な乳房のサイズ増大(概ねトップサイズと対応)との相関は直ちに結びつかないのではないか。そう「ロリ巨乳」の存在である。すなわち巨乳と判定されるトップサイズ(90cmとか)は高止まりしており、アンダーサイズの方が減少しているのではないか。
この推測に対し同データを利用して、身長を表す120cmから199cmまでの語を含む短編数を調べた(表4)。下限を120cmに限定した理由は100cm付近だとバストサイズが引っかかる可能性(実際あるのよ…)があるからである。また低身長、ロリ、ロリ巨乳、巨乳についてのデータも右列に併記する(160cmやロリ、ロリ巨乳、巨乳を正しく分類できる NEologd は凄いぞ)。身長の分布に顕著な差が見られないことおよび巨乳の増大率に対してロリ巨乳の増大率が低いことから、低身長の増加を加味しても2014年以降のカップ数のインフレを吸収しているとは考えにくい。したがって近年のカップサイズインフレ傾向はトップサイズの増大によるものだと推測できる。
| 表4 | 120cm-129cm | 130cm- | 140cm- | 150cm- | 160cm- | 170cm- | 180cm- | 190cm-199cm | # | 低身長 | ロリ | ロリ巨乳 | 巨乳 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | # | 0 | 5 | 0 | 3 |
| 2007 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | # | 0 | 17 | 0 | 6 |
| 2008 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | # | 0 | 19 | 0 | 7 |
| 2009 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | # | 0 | 20 | 0 | 7 |
| 2010 | 0 | 0 | 1 | 1 | 0 | 1 | 1 | 0 | # | 0 | 9 | 0 | 5 |
| 2011 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | # | 0 | 12 | 1 | 16 |
| 2012 | 0 | 0 | 1 | 0 | 0 | 2 | 0 | 0 | # | 0 | 8 | 1 | 15 |
| 2013 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | # | 0 | 8 | 0 | 9 |
| 2014 | 0 | 0 | 0 | 0 | 4 | 3 | 0 | 0 | # | 0 | 9 | 1 | 23 |
| 2015 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | # | 0 | 19 | 2 | 23 |
| 2016 | 0 | 0 | 1 | 2 | 0 | 0 | 0 | 0 | # | 0 | 23 | 2 | 22 |
| 2017 | 0 | 1 | 4 | 7 | 4 | 4 | 1 | 0 | # | 0 | 20 | 1 | 32 |
| 2018 | 0 | 0 | 6 | 3 | 3 | 4 | 4 | 3 | # | 0 | 25 | 9 | 34 |
| 2019 | 0 | 1 | 5 | 1 | 1 | 1 | 0 | 1 | # | 1 | 15 | 8 | 37 |
| 2020 | 0 | 2 | 4 | 4 | 2 | 2 | 3 | 0 | # | 6 | 15 | 8 | 43 |
| 合計 | 0 | 4 | 25 | 19 | 14 | 17 | 9 | 5 | # | 10 | 224 | 33 | 282 |
作品名は挙げないが、一つの作品のタイトル、概要、タグ、本文全て含め、最も連呼されたいたのは、IカップとJカップである。それぞれ2万とちょっと文字数の中に8回出現していた。なお、爆乳は2万文字で21回、巨乳については8千文字で29回であった。後者については理由があり、作中で「巨乳ちゃん」が連呼されるからである(25回)。前者は全てそのままの意味で出現する。
本分析より、ノクターンノベルズの短編小説において巨乳の定義がインフレ傾向があることが分かった。これは小説描写においてはビジュアルを描写するコストが低いこと、すなわちデザイン面で人体のバランスを取る必要がないため、(本人の常識の範囲内で)自由にバストサイズを設定できるからであるためと思われる。小説描写においてバストサイズは大中小のどこかのカテゴリに入れば十分であり、また前述のように小と中は既に共通認識が固定化されているため、その範囲はどこまでが大か(かつ著者が興奮できるか)により決定されるからである。
真面目なのはここまで。インフレしている理由は単純に男は大きい数字が好きだからだと思う。DよりEのが強い、いやEよりF、FよりHだ！という少年漫画方式で盛っているのではないかな。ぶっちゃけエロ小説において大きいおっぱいの役割は、たっぷり揉める、なんか挟める、アレした時よく揺れるくらいしかないのでそれらを満たせるサイズであればなんでもいいのじゃないかな。(特殊性癖として妊娠していないのに母乳が出るとかあるけどそれは取り上げない)。
また、あくまでもこの分析はカップ数や「巨乳」という直接的に豊満さを表す言葉に注目したものであり、それらを使わない作者も大勢いることを主張しておく。間接的に豊満さを表す手法としては隠喩的な外見描写やキャラの立ち振る舞いでの表現が存在する。これらは古き良き読者の想像に任せる書き方になるので、描写が上手い人には割と手練れの作者が多い気がする。
個人的には大きすぎるのは現実味ないのでノットフォーミー。大きさより体のラインの綺麗さや形の良さの方がリアリティあると思うのだけど…調査楽しかったです。
