Web小説リーダーアプリ総合 ★6

!extend:default:default:1000:512:donguri=1/1:

Web小説リーダーアプリ一般についてのスレ

次スレは>>980が立ててください

※前スレ
Web小説リーダーアプリ総合 ★5
https://egg.5ch.io/test/read.cgi/android/1734880341/

---

VIPQ2_EXTDAT: default:default:1000:512:donguri=1/1: EXT was configured

>>157
リストに数百とか多い人なら千ももあるのにいちいち手動で個別にDLするのか？
意味ないだろ

>>158
たいした更新じゃないからきにすんな

【2026.04.02】ver2.0.9
・Plugin関連のバグ修正
・Pluginの編集UIを修正

>>157
Filterかけても大量のカクヨム作品のDLが捗らないことには変わりないぞ

ymo更新したらカクヨム直ったわ。

更新来たのって一週間前の話やないかー

あー、YMOのカクヨム作品、やたら差分だけじゃ無くてフルダウンロードしまくるのワイだけじゃ無かったんやな
流石に短時間アクセス制限に引っかかってダウンロードエラーでつっかえつづかえでなのはツラいし、アクセス過多で家回線のIPBANとかされそうでコワいわ

なろうとカクヨム両方に載せてるのはカクヨムで取得をメインにしてたけど、
更新頻度が同じ作品はなろうに切り替えるかなぁ

YMOのカクヨム対応アプデ来てくれたけど
全話再DLの判定ルーチンとか見直すとかなと思ってたら
単純にDL時のアクセス一話ごとに挟むウェイトを長くして
アクセス頻度を落として403を防ぐという正面突破だった

1000話オーバーの作品とか落とすのスゴく時間かかってて震える…

正確に計ったわけじゃ無いけど、DL1話あたりに約1秒かかってる
300話の作品DLしなおしだと一作品更新で約5分ｗｗｗ
イヤ、いつ終わるんだこの更新作業……

未読だけ取ってくるオプション追加してくれ

そうだね
数千話ある作品複数登録してると改稿あると更新に時間かかるしサーバーにも負担かかってるんじゃないかな
最新話だけならすぐダウンロード終わるのに

昔無かったっけ差分チェックでダウンロード
差分ファイルでストレージが圧迫された記憶があるんだけど

だけど何

一度落とした分は差分だけになってるし、今回のカクヨムの仕様変更で変更前の項の場合再ダウンロードになってるだけでは

>>172
YMOは作者が作品を改訂改稿したら1話目から全部DLしなおす仕様
いまのカクヨムの規制状況だと数百話千話あるような作品を連続でいくつもDLするのは厳しい
カクヨムの規制回避するためにウェイト入れると更新チェックDLにものすごい時間がかかる　←　いまここ


いまの仕様だと頻繁に全話DLしなおすから未読話だけDLできるようにしてくれって話
誤字なおされたからってわざわざ古い話見なすことなんてないしな

更新チェックに時間かかってもいいから対策はしてほしい

とりあえず、なろうにもある作品はそっちにするつもりだけど、それにしても面倒くさい。

カクヨムは公式アプリかな

小説ラクヨミってのが
なろうもカクヨムも登録できていいかなも思ったものの

広告邪魔だし、ふりがなをちゃんと表示してくれないしであかんわ

>>173
ビューワー側で最新話更新なのか途中更新なのか自動的個別に判別する方法ないと無理
その辺が作品毎にバラバラだから一括ダウンロードで処理してるんだと思われる

一応その場しのぎで今は
カクヨムのやたら長い作品とかは読書状態を「後で読む」にしといて更新チェックのときは「読書中」Filterかけてやってる
まあそれでももとが多いからなあ

>>177
話数チェックして増えた分取ってくる単純な仕様でいい

アプリの広告が邪魔ならadpuardでも入れれば良いんじゃね？　アプリ入れたくなければプライベートDNSでadpuard設定すれば良いし
まあそのアプリの広告が消えるから試して無いから知らないし広告ブロックしたらアプリそのものが使えなくとかならどうにもならないけど

>>146
こっちも完結済みじゃないと面倒だけどブラウザのスクリプトでハーメルン作品はepub形式とtxtでも保存出来るよ 同スクリプトでハーメルン なろう 読もう カクヨム pixiv辺りはepub txt形式保存出来るから結構便利だわ

>>179
それを指定するスイッチがあればいいんだよね
どこまで取得するか選択の自由があればうれしい

というか増えた話や最新話だけを読むのが一般的な読者の行動で、
せいぜいそれに加えて改訂された話だけを読むくらい

頻繁に全話読み直したりはまずしないから、
頻繁な全話ダウンロードはカクヨム側ではあきらかに異常なツールによるクローリングと判別される
こんなの続けてたらそのうちYMOがアプリ指定でブロックされる気がする

なおったぞ

ボットチェック入れるだけでYMO無力化できるからそのうちカクヨムにも導入されるんじゃね

>>183
言いたいことも分かるけど
ダウンロードして端末で読むアプリの挙動じゃないぽい
ていうか各種サイトの既読位置の管理アプリが欲しくて現状それに一番近いのがYMOって感じか
確かにサイトのユーザー登録必須でいいからそんな感じの管理アプリは欲しいけど

>>67
MHEが同じく開かなくなって、色々と試したら行けたから解決法？
(sd read errorって出た場合だけかも)
YMOのデータ保存先が
/storage/emulated/0/Android/data/mhe.mhenv_ymo/
↑これだといけて
/storage/emulated/0/Android/data/mhe.mhenv_ymo/files/
↑だと無理だった

もし次も同じようになったら試してみて

自作してみようと思って
プログラムわからないけど
claudeに聞いてコピペ駆使して
やっとランキングだけ取得できた

もう疲れたよ

そこはパトラッシュに語りかけないと

> claudeに聞いて

何コレ？

claude登録からここまで10分くらい
アプリ作ってくれって指示したらコードの表示とかなしでここまでやってくれたぞ

https://i.imgur.com/QMPjI30.jpeg
https://i.imgur.com/Cir5fFM.jpeg

ここで無料トークン尽きた
これ以上調整するなら5時間後なので素直にProに課金した方がいい気はする

あーそうか俺のアプローチが間違ってたんだな
claudeに作りたいでアプローチ掛けたから

作ってくれのほうがスマートでいいんだな

頑張っててエラい
単発なら挑戦してみたくはあるけど
勉強しないとサイトの仕様変更に対応し難いだろうしなぁ
アプリ製作者の皆様御世話になっております

geminiに
コレコレこういうアプリをclaudeに作ってもらいたいから、プロンプト考えて
って聞けばいい

誰でも簡単にアプリケーションが作れるのは良いが、皆がそうやって作ったアプリでアクセスするとトラフィックが増えて別の問題が出てきそうだな。

作るのは良いけど、ローカル環境というかテストサーバーというか、やらかしても被害が作った人だけで済む状態で一旦テストして、サーバーに負荷を掛けないことを確認してから使ってほしいという思いはある
なんか本番環境でロクにテストしてないプログラムを実行しているような空恐ろしさを感じるんよ

アプリだったら何万というマシンから同時アクセスで負荷がかかるということはあるかもだけど
個人のマシンで走らせたプログラムのバグでひっきりなしにアクセスしたとしても
所詮は一台のマシンなので、その負荷なんてたかが知れてるよ。

アプリだったら → 公開されているアプリだったら

ハメはあまりに厳しくしてるので二次以外は衰退するんじゃないかな
それかいずれ緩和するか
聞こうならオンライン運用に支障ないし個人的にはどうでもいい

どうしてもダウンロードしたいならスマホアプリという形態はバッテリーのことを考えるとなし、開発のことを考えてもなしなんで、そのうち必要としてる誰かがNarou.rb 2みたいなの開発するんじゃない？
Cloudflare Challenge/Cloudflare Turnstile回避をスマホアプリで延々追随し続けるのむだだし

ハメ単体でオリジナルはあんまないし二次を読む所になってる

そもそも非公式リーダー使ってる層がどれくらいいるのか
そこまで多くないと思うよ

そもそもハメは二次メインのサイトだし

一部だけに触れられてもw

カクヨムもなろうみたいにAPI提供すればいいのにな

数日がかりでやっとYMOアプデ後のカクヨム作品更新DLおわた
端末ディープスリープになるとDL止まるし、家回線からのみとかだったからホント長かった…

話毎改稿情報を得る方法がないとどうしようもない
HEADで照らし合わせができてもGETしちゃってもあまり変わらないだろうし

話数増えたとき増えた分だけ取ってくればそれでいいのに
全話ダウンロードはユーザー側が必要と思ったときにユーザーが手動処理でやればいい

改稿で全話DLという動作がデフォで有効になっててオフにできないのがYMOの問題点なんだよな
オプション化してデフォでは無効にしておいて必要な人だけオンにするようにすれば規制にもそうそうかからんだろうに

>>206
なろうとハーメルンは目次のサブタイトルの投稿日時の横の（改）で改稿情報持ってるんで、
目次ページだけで負荷少なく改稿分だけダウンロードできます。

>>209
そうだよ

だから>>208は思いっきり勘違いしてる
思い込み激しすぎ
UXで数字をカウントアップしちゃってるから勘違いしやすいんだけどね
このネタは過去スレにもあるくらい

ついでに>>207もYMOは当初からこの仕様なのでいまさら
なんでYMO使ってんのになる

まあでも
オプションで改稿無視して話数増加分だけダウンロード
そんな設定があればこういう文句もなくなるのかもしれないかな
作者に伝えてみたら？

YMOのログが増えすぎて辛い

手動でログファイルを削除したら？

ログ整理の古い稿の削除
YMOの古い稿の削除は100行以内の変更のログのみ抽出しての削除だけど、ぶっちゃけ1000行以内でも良いと思ってる
千行は幅広すぎて固定がマズいならオプションメニューからとかで自分で行数指定して一括ログ削除できる機能有れば自分は大歓喜する
もしくはオプションの古い稿を残す基準の数値のMAX100行は正直小さいから、もっと大きい数字設定したい

>>212
別人だけどやり方押してほしい

>>214
YMOの小説データ保存場所に「YMO!log」ってフォルダがあるから、そこへアクセス
月毎のファイルがまとめられてある（たとえば今月分なら「YMO!2026年4月.log」）ので、いらないものを削除
全部削除しても動作に支障がないのは確認済み

データ保存先にどうやってアクセスするかまでは面倒だから書かないぞ

>>215
ymo.logフォルダより、消去されない小説ファイルデータが気になる。

作者名フォルダの中に、indexファイル(とsub_indexファイル)、infoファイル、txtファイルが作られるが、YMOで小説を削除しても、消えるのはtxtファイルだけ。
作者が「ななし」から「ななし@書籍発売中」と名前を変えると、ななしフォルダとななし@書籍発売中フォルダの2つが残る。

>>216
> 作者が「ななし」から「ななし@書籍発売中」と名前を変えると、ななしフォルダとななし@書籍発売中フォルダの2つが残る。
著者名はユニーク且つ不変という当初設計に依ってる
異なる小説サイト間で同一著者名の場合は同じフォルダにまとめられる
作品を登録するとその情報の著者名や作品名は更新されないので、同じ作品でフォルダが異なるという事態は起こらない
異なる作品でその間で著者名が異なれば別フォルダとなる
そもそもなろうだと別名名義作品で公開できる（マイページで即バレするアレ）ため別名毎にフォルダが異なる

ただの仕様

/Android/media/mhe.mhenv_ymo/mhenv/.yomou/YMO!log/
10年ためても二桁MBにしかならないのに気にする人がいるのか

>>218
容量の問題じゃなくて、ログが多いと年表タブを開いたときにアプリが処理落ちしたりしない？

>>219
待たされても数秒間程度だと思うが
そもそも左下の小さな「年表」タブボタンを押さない限り処理もされないし
むしろあのころこんな作品を閲覧していたんだなと振り返ることができるかなり優秀な機能のためのデータだと思うんだが

小説データ（YMOだとだいたい作者ごとだけど）は作品にもよるけどたまに見るとフォルダ内すごいことになってるな
半年くらい間引きさぼってたら
多い順に436MB 299 268 255 232 206 206 198 ……

一応古い行残す基準は100行にしてるんだが

>>217
>作品を登録するとその情報の著者名や作品名は更新されないので、同じ作品でフォルダが異なるという事態は起こらない

うん、それは知ってる。
作品はnコードで管理されてるので、なろうとカクヨムに同一作者名で同一作品名の小説を投稿してる物をYMOに両方登録しても、YMOの同一フォルダで、別ファイルとして保管されてる。
ただ、削除した作品の本来必要とされないはずのフォルダやファイルが残るのが気になるだけ。旧作者名フォルダも不要だし、

>>221

>>213も言ってるが、古い稿の削除とかを500行とか1000行とかでしたいよね

>>222
> ただ、削除した作品の本来必要とされないはずのフォルダやファイルが残るのが気になるだけ。旧作者名フォルダも不要だし、
残している理由はわからないが、削除したあとで再度登録したことを考えている可能性がある
別アプリで.yomou下作者フォルダ内に本文テキストファイルがない場合は、メタ情報ファイルを削除する、空ならフォルダを削除するといったものを用意すればどうだろうか
TaskerやMacroDroidであればある程度処理時間は取られるにしても可能だと思うが
そんなに頻繁に行うようなことでもないだろうし

それ関連で言えば、個人的には「もう読まない」フラグを立てた作品については本文履歴をクリアしてほしい（最新最後の本文テキストファイルを残して、本文履歴ファイルを削除してほしい）かな
もう読まないフラグにしたときに手動で履歴クリアはしているけどうっかりミスがあるので
（だから削除という行為がいまいち理解できない。削除するということはもう読みたくないという意思表示だと思うが、削除してしまうと気付かず再度登録してしまい再読するハメになる。それを避けるためには少なくともメタ情報を残さざるを得ないと思うんだが）

diffについてはたった一つの冴えた正解はないんじゃないかな
基本的にYMOは本文履歴ファイルの存在を以て「古い稿」を認識しているようなので、YMOの判別基準とは別にまたTaskerやMacroDroidで処理するしかないんじゃなかろうか
作品名_作品コード.txt
作品名_作品コード_rev年月日時分秒.txt
rev付きのファイルとrevなしの最新ファイルをdiffさせて好きな程度でrev付きを削除してしまえば概ね要望は叶うと思う

>>215
ありがとう
早速調べたけれど下の場所には無かったので他にあるかな
\内部ストレージ\Android\media\mhe.mhenv_ymo\mhenv\.yomou

>>226

>>215じゃ無いけど、そのフォルダ(.yomo)でYMOで検索かけてみれば見つかると思う。

うちの場合はAndroidと同じ層に
/mhenv/yomou/YMO!log　やな
「非表示のフォルダを表示する」は要るかどうかわからん

>>227-228
ありがとう
今晩にでももう一度試して見升

AndroidからiPhoneに変えたら 小説を聞こう 系の音読アプリの声が違和感やばい

ロボットボイスじゃん
siriの声出読み上げしてくれよ

読み上げ系はほかのも含めてAndroidのがGoogleの合成音声使えるから優秀なんやな

なろうブックリーダーもカクヨム読めなくなったかもしれない

Webブラウザ(Edge)で好きなフォントで読みたいだけで、
Tampermonkey 用のスクリプトを AI に作ってもらった
一度、フォントを base64 エンコードしたもの(8MB)を食わせるという力技だったけど思ったより使えた、G99 8GB の泥タブ、FireHD10+、クソ古い雑魚スペックスマホ
ついでに、
- 本文を画面横幅いっぱい(タブで)
- タブレットで1行28文字、スマホで1行18文字
- スクロールガイドライン表示
- カクヨムではじめたけど、なろう にも対応

リーダーなアプリで読み始める前のチョイ読みには割と使えるな、って(小並

スクロールガイドライン表示について補足しておくと、スクロールで
どこ読んでたかしょっちゅう見失うので、スクロールを始めると
画面最下端(最上端)だった位置にラインをスクロールに追従させつつ
しばらく表示して見失いにくいようにする、というもの
電車内とかで強い(個人の感想です

>>232
で？

>>233
チラ裏
出来る人は自作でアプリまで行くんだろうなぁ
でも、私にはこれが精一杯
スクロールガイドライン表示は便利だった

おわり

スクロールバー・インジケーターのこといってるのか（スクロールバーの現代実装）
物理リーディングトラッカー（リーディングガイド）のソフト版（Kindle的にはリーディングルーラー https://www.lifehacker.jp/article/2510perplexity-makes-me-wonder-why-i-ever-used-chatgpt/）のこといってるのか

よくわからない説明からすると前者だと思うが
とりま勝手造語されてもイミフ

ここは「Android」板の「Web小説リーダーアプリ」スレです

>>235
まぁうまく伝わらないだろうなとは思ってた
正式名称があるのかそもそも知らないし分からないので、
命名した Gemini のまんまを便宜上使っただけ、御勘弁
https://i.imgur.com/4bqpumN.png
こういうの何ていうの?

>>236
気合を入れたらこの雛形がアプリになる可能性が微レ存

>>237
「こういうの」が何を指しているのかスクショを見てもさっぱり分からない

ここはAbdroid板のWeb小説リーダーアプリスレなので、「Tampermonkey」とは何ぞや、 「base64 エンコード」とは何ぞやを説明しないのでは話が通じないと思われる。

>まぁうまく伝わらないだろうなとは思ってた

伝える気が無いのだと思ってた、もしかしたら伝える気あったの？

かまうなよ

>>238
Siki で作業してたからサムネでもアニメーションするので気が付かなかった、
imgur のURL開くだけじゃアニメーションしないのね
ダウンロードして開けば動くけど、これはすまんかった

>>239
そりゃそう、届けるひとを意図的に絞ってましたから
「Tampermonkey」「base64 エンコード」を知っている人、
あるいは気になって自力で確認したひと(こっちがメイン)に
伝われば良いやで書いたので
アプリ開発は厳しい、けど Tampermonkey 使って AI に聞けば
カクヨム、なろう、などで UI をある程度自分好みに弄れましたよ
というお話

android板だからandroidnの事しか知らない人ばかりということも無いと思うのだけど。
わからない言葉が出たらググれば良いのだし

>>238
pngもアニメーションするんだねえ。
スクロールの際に読んでる位置を見失わないようになのか
なんか線が出てるからそれじゃないかな。

>>237 のアニメーションpng画像
もうひとつごめんなさい、アニメーションが無限ループしてない
厳密な動作をする環境なら1回しか動かない
親切?な画像ビューアだと無限ループしてくれるかも

ソフトウェア板にいけばいいのに

>>241,242
pngをダウンロードしても俺のスマホの標準の画像ビューアーやSolid Exploreのビューアーではアニメーション表示されなかったw

いくつかのビューアーで試したら最下行にアンダーラインが出るアニメーションが出た!
アニメーションになってるってレスがなければ気付かなかったよ

最近はmngだけでなく、pngでもアニメーション可能なんだと知ったおっさんです

俺はYMOのハーメルン復活を諦めないぞ！

どちらでもなかった件
かすりもしなかった件

>>237
スクロール開始するときの最上下行に下線を引いてるのか
それら行にマークを付けて、ユーザーのスクロール操作を補助する役割か
一般的に名前が付いてる記憶がないな

敢えてこねくり回すと、Visual Scroll Helper、scroll helper、visual scroll indicator / guide、スクロールガイド
それが行ならスクロールガイドラインか

最終的にやってることの本質は、ページめくりをスクロールで再現する仮定において、「一時的な」既読位置管理だな
巻物文化では用語ありそうな気がする

なおページめくり補助なのでふつうはページめくりそのものができるようにする
Androidのブラウザ界隈なら einkbro: https://github.com/plateaukao/einkbro が有名か
要はページアップ/ダウンキーを画面の特定領域に割り当てる
画面上の最下行が最上行まで飛ぶことは厭われることもあるので80%ページアップ/ダウンみたいな調整も可能

ただおそらくあなたはスクロール及びページめくり時に「どこの行（のどの文字）まで読んでいた」のかの把握が苦手で、それの補助までしたくてラインを引いているように思える
リーディングトラッカーまでは必要ないが、若干ディスレクシア的な人の補助ツールと言ったところか
タッチパネルのあるタブレットにおいては、指がその役割をする（はずな）のでどうしてあなたが必要に駆られたのかそこは理解が及ばないが、機能性そのものはとても理解できる

一般にわかりやすく言えば、スクロールにおける読んだ位置把握の「指読」か
速く読める、しっかり読める！ 指読ガイドツール｢ブックフーバー｣ | ギズモード・ジャパン: https://www.gizmodo.jp/2023/05/machi-ya-bookhoover-review-665951.html
ここまでではなく、スクロール操作時限定バージョンってところだな
タッチパネルタブレットではまさに指がその役割をするはずだがなにか理由があるんだろう

Kindleにもリーディングルーラーあるしその機能性アイデアは個人的にかなり評価したい
健常者という名の多数派もその実はグラデーションで一部に於いては障礙者であることもあるしな
タッチパネルよりスクロールホイールユーザーこそ必要性がありそうだから、なにか先行事例もありそうだ

あきら🍈

伝わるかどうじゃなくてただスレチなだけです
日記は他所でやってね

丁寧な考察、解説ありがとうございます
必要とした理由は単純明快で
文字に手や指がかかるのが嫌で割と端っこを弾いてスクロールしている
→ 弾くのでスクロール自体結構速い
→ 止め損なう、加減が下手でスクロール量が一定しない
→ 見失う
なところです

そして、GoogleAI検索モードが頑張ってくれて、先行者を見つけました
「Scroll Marker」 で、かつて lifehacker で紹介されています
https://www.lifehacker.jp/article/130522scrollmaker/
既に Chrome ウェブストア には存在しないものの、非公式自己責任系な
Crx4Chrome からは .crx ファイルが入手可能でした
Edge に突っ込んで触ってみたところ、持っていなかった機能として
下端からのオフセット設定があったりして、なるほどな、と

https://github.com/kcarrhall/Scrollmarks
弾いている＆先行事例了解
オフセットはルパン三世タイトル的極北
https://togetter.com/li/1588408
視線移動に得手不得手があって実は読み方が人それぞれってやつ

世の中同じことしてるようで実は異なる方法で実現してたというのはありがち
Android小説リーダーアプリもこの方面で展開するものが出てきても面白いね
スクロール苦手、ページめくり苦手は本が読めない文字が追えないわけでなく、既存の表示方法がマッチしていないだけって人もいるだろうから

速くは読めるけど理解度は低いとか落とし穴がありそう

要はandroidで作ればいいだけだな

>>252
棘のならあれは速読であって速理解じゃない
ルパンタイトル以外の他の速読も同じ
理解は別

>>246
ハメの規制の仕様変更あったっけ？と思って調べたけど通常作品には見当たらんかった。
R18作品は、初回アクセス時に目次の移動履歴が無いとForbiddenを返してくるようになったので、この辺のハメ独自のロジックを入れてもらえるかだね

>>255
そのロジックをたとえ入れてもハメ側が対抗するいたちごっこスタート

>>255
r18もプラグインでダウンロードできた
ダウンロード中に画面がパタパタ変わって動き変だけど

>>256
ですです
ハメはhtmlの解析ロジック以外を弄らされるんで、対応するたびにサポート終了したくなるのが何とも