いまなにしてる？

150字ずつ生成するなら起承転結のブロックの４ブロックを繰り返すとリズムが出るかも？ 文章自体の質はかなりいい。

AI生成小説プレビューシステム　試作品その２ https://litter.catbox.moe/m1car9e0p2c8qemj.mp4 50倍速の動画。日本時間深夜0時をすぎるとAPIの反応が鈍くなるためリトライ発生してコスト増大する。 日中ならば3000字あたり15円といったところ。 すなわち3万字つくるためには150円～200円、10万字ならば700円程度のAPI費用を要する。しかも品質は保証されない、という…… Geminiシリーズでは、gemini-2.5-flash-lite 以外のAPIでは出力までが遅すぎて使い物にならない。しょぼいシステムに見えるだろうけど内部で重複除外などの処理を何度もおこなっているため、安ければ安いほど／軽ければ軽いほどいい。 今回は〈あらすじ〉〈キャラクター〉を一切指定せず、「ギャルとの特別な3日間の物語」というお題だけを与えたもの。 別途、Character.md とか Story.md などを設定すれば、さすがのliteモデルであっても読み物として体裁を整えたものを出力するだろう。 どうやら〈中篇小説の冒頭部分〉を出力しているつもりらしい。 若干『俺の妹がこんなに可愛いわけがない』の導入部に似ている。

AI生成小説プレビューシステム　試作品 ■11秒の動画（実際の生成時間は10分） https://litter.catbox.moe/r4ufs6h57h6bjxwr.mp4 小説クオリティが上がらないため、現実逃避で作ってしまった。 生成が進むごとに下方向に自動スクロールする機能をつける予定だが、Codex使いすぎて今週は打ち止め。 小説テキスト生成APIはいちばん安いやつを使っているが、 校閲・校正AIは最上級モデルを使ってもいいな。 安いモデルで校正しても、ほとんど変化がない。 3000字を生成するのに100万トークン消費しているが、これはもっと少なくできる。 生成時間も並列化すれば、もうすこし高速化できるはず。

AI小説生成システムつくっているが…… （ヒトの指示能力が低いせいで）生成される本文クオリティが低すぎるあまり、生成過程プレビューUIをつくりはじめたら面白くなってきて、モチベーション戻った。 もうすこし形になってきたら、あとで動画アップロードする。

アキラと変な家（9802字） https://imagawatatsuya.github.io/ari-no-ana-neo/#read/1770863373897 ※生成時間:16分／25円 会話文は増えたが、プロンプトで余計なことしたせいでビミョーに…… ジャンル「実話怪談」にしたせいで、主人公が基地害の小説家になってしまった。 150字程度書く→レビュ→反映して150字→1万字目安で完成 上記コストが〈正確な費用〉ならば、API呼び出しのレートリミット限界まで試せる。 APIの仕組みがよくわからないものの、高回転フィードバックループ方式は興味ぶかい。 ーーーーーーーーーーーーーーー SYSTEM_INSTRUCTION = """ あなたはプロの日本語短編小説作家です。軽度の統合失調症を患っています。薬を飲むのをやめています。[ジャンル例: 実話怪談]に特化。 自然で魅力的な日本語で書いてください。一貫性、キャラクター開発、プロット進行、ウィットに富む会話、キャラクター同士のやりとりを確保。 各セクションは約150文字に収めてください。 小説の基本原則は会話のやりとりです。 修正時はフィードバックを正確に取り入れ、無関係な部分を変えないでください。 """ # Feedback system instruction FEEDBACK_SYSTEM_INSTRUCTION = """ あなたは型破りな小説批評家です。指定されたセクションを分析し、改善点をリストアップしてください。 改善点例: 記述を鮮やかに、プロットの不整合修正、キャラクターの深みを追加、文法/スタイル改善。 改善不要なら空文字列を返してください。出力は箇点リストのみ（例: - 記述を鮮やかにする\n- 不整合を修正）。 """ # Initial story prompt（カスタマイズしてください） INITIAL_PROMPT = "都会の一画にもかかわらず謎の因習がはびこる狭小邸宅にまつわる実話怪談の短編小説を始めなさい。最初の約400文字から。"

某図書館におけるレファレンス室のメールフォーム解析結果 こんな感じ Analyzed form elements: - index=0, selector=#txt_name, tag=input, type=text, name=txt_name, id=txt_name, label=お名前【必須】, nearby=- - index=1, selector=#txt_use1, tag=input, type=text, name=txt_use1, id=txt_use1, label=お名前(カナ)【必須】, nearby=- - index=2, selector=#txt_tel, tag=input, type=text, name=txt_tel, id=txt_tel, label=電話番号【必須】, nearby=- - index=3, selector=#txt_mail, tag=input, type=text, name=txt_mail, id=txt_mail, label=メールアドレス【必須】, nearby=自PC 携帯電話 | 自PC 携帯電話 - index=4, selector=#cmb_mail_class, tag=select, type=text, name=cmb_mail_class, id=cmb_mail_class, label=-, nearby=自PC 携帯電話 - index=5, selector=#txt_use2, tag=input, type=text, name=txt_use2, id=txt_use2, label=住所【必須】, nearby=- - index=6, selector=#cmb_age, tag=select, type=text, name=cmb_age, id=cmb_age, label=質問者区分, nearby=小・中 高校生 大・短・専門 その他 これをもとに個人情報を組み込んでブックマーク生成すると、ワンクリックで自動入力できる。そういうシステム。

ちなみにN*Lに関する悪魔的システムは ・抽出したURLリスト（現在 100件～） を用意すれば、ワンクリックで〈全自動わんにゃん〉できるようになった。 普段からSNSでその手の情報をみつけてはブックマークする習慣がある。それを定期的にエクスポートしてリストをつくる。 起床後パソコンを立ち上げて、まずワンクリック。 PC作業ちょっと休憩だな、というときにワンクリック。 すると、既定わんにゃん数（5件）の処理がバックグラウンドで始まる。 Cronでも定期実行できるが、やりすぎるとBANされたり一時アクセス制限されるおそれがあるために控えている。 1日10冊程度にしておきたい。 わんにゃんペースの塩梅が難しいうえにストレージ調達の限界もある。 使っていなかった1TBのHDDを引っ張り出したものの、このペースで〈わんにゃん〉していくと、半年足らずでストレージ容量不足に陥る。 稀覯書や全集を買うより安いし省スペースだが、やはりカネがかかる。 N*Lから〈わんにゃん〉したPDFには個人情報が刻印されているためクラウド保存は心理的抵抗がある。誤解でBANされるおそれもある。 寛容だが二次的な悪用をなるべく防ぐ仕組み。賢い人が考えたのであろう良い設計だ。

ふたたび昼夜逆転 眠れないのでメールフォーム解析システムを作った 図書館のレファレンス窓口から問い合わせるときに個人情報を入力する しかしながら全国各地の公共図書館のメールフォームは入力項目フォーマットが統一されていない ありがたいことに大抵の図書館は〈所在地以外の国民〉からの問い合わせを受け付けてくれる。ただし入力フォーマットが統一されていないので、都度手動で入力しなければいけない。 Ａ.図書館用の有名システム Ｂ.独自システム Ｃ.ログイン後にメールフォームが出現する Ｄ.現地の住民のみ問い合わせできる Ｄは諦めるしかない。 解決すべきは、Ａ～Ｃのメールフォーム入力の省力化である。 地元の県立図書館や市立図書館のレファレンス入力は専用ブックマークレットで一括入力している。 それ以外の図書館レファレンスへの項目入力の省力化がしかたった。Codexの使い方もわかってきたので「さほど省力化になるまい」とは薄々思いながらも作ってみた。 もちろん完璧ではない。しかし解析ログが入手できるため、２度目の問い合わせからは、ログをもとに自動生成させたブックマークレットを使って自動入力→省力化が達成できるという理屈だ。 とはいえ、レファレンス問い合わせの２度目があるとはかぎらず、いわゆる「ハンマーを手に入れたら何でもクギに見える」という現象なのだろう。 このプログラムのメールフォーム解析には〈LLM API〉は使用していない。 Pythonを使っているが、本来はLLMがなくても相当高度なことができるようだ。 今年は、LLMに権限を与えて〈ローカルのパソコン内のファイル整理／分析やパワポ生成を縦横無尽に操作させる〉ソフトウェアが流行ると思うが…… ある程度はLLMの介入に頼らず、最小限の手間でそれらを実現できるようになっておけば、お財布にもプライバシーにもセキュリティにも優しい生活ができるはず。

アベンジャーは草

OpenCrawやるぞ ほぼ廃品の第6世代 i5 ノートパソコンにUbuntu入れて完全隔離で動かす これなら暴走しても被害最小限に抑えられるだろう うまくいけば掲示板うしちゃんにAIアベンジャーズが押し寄せるはず 貧弱なCPUであってもAPI経由ならば5人程度の人格まで作り出せる……ってチャッピー言ってた。

ChatGPTに原稿を投げて誤字脱字を探している。１０年越しに見つけて逆に面白くなってくる。あとなんだかんだで自分の小説って面白いんだよなぁ。

最近はヤフオクの入札額と落札戦略についてチャッピーのアドバイスどおりやってる もっともらしいアドバイスをする 先に入札者がいる場合は、どうせ「自動延長」するんだから始めから上限額を入札するのが最善。 ただし結局は予算（上限額）次第なので「カネがすべて」戦略にはかなわないけれど……賢者に相談して競り負けたのならば仕方がない、と諦めやすくなったような、ならないような。 今後ヤフオク公式でも（なにかの法に触れなければ）リリースあるかもね。AI入札／落札相談もしくは代行。 上限額をあらかじめ入力して、あとはAIの戦略にまかせる、みたいな。 従来のAIのイメージにおいて〈ゲーム理論〉的なものは得意なはずだが、実際に顕現したのはLLMである。LLMは本当にそういうものが得意なのか、大規模実験してみないとわからない。 そして、AIコンサルの戦略的助言を受けた入札者同士（複数人）が競った場合、どうなるか。 すでに親会社のソフトバンクのどこかの部署では研究が進んでいるだろう。間違いなく。

司馬遼太郎短篇総集 - 国立国会図書館デジタルコレクション https://dl.ndl.go.jp/pid/12554649 書誌から抽出した情報をもとに、ディレクトリ（フォルダ）名を生成して、ダウンロードファイルをまとめて収納する機能を追加。ようやく実用的になった。 書誌（メタデータ）に必ずしも値（あたい）が含まれるとは限らない。空欄は〈不明〉とする 複数著者がいる場合は、合計30字までを許容して、それ以外の著者は〈他〉扱いとする。 { "pid": "12554649", "url": "https://dl.ndl.go.jp/pid/12554649", "title": "司馬遼太郎短篇総集", "author": "", "publisher": "講談社", "publication_date": "1971", "request_mark": "KH555-71", "biblio_id": "000001268559", "doi": "10.11501/12554649", "extracted_at": "2026-02-02T23:35:13.786344", "total_frames": 544, "downloaded_at": "2026-02-02T23:35:13.897328" } 544コマ（total_frames）はNDL上のページ数 実際の上本は 1069ページ ある PS C:\Users\user\ndl-xxx-for-limited-contents> uv run python download.py 2026-02-02 23:34:38,425 - INFO - 進捗CSVを作成: downloads\progress.csv 2026-02-02 23:34:38,426 - INFO - 処理対象URL数: 1 2026-02-02 23:34:38,438 - INFO - 統計: 全0件 - 完了0件, 処理中0件, 失敗0件, 未処理0件 2026-02-02 23:34:46,258 - INFO - [1/1] 処理中: https://dl.ndl.go.jp/pid/12554649 (PID: 12554649) 2026-02-02 23:34:46,258 - INFO - 処理開始: https://dl.ndl.go.jp/pid/12554649 2026-02-02 23:34:46,258 - INFO - 進捗更新: PID=12554649, status=in_progress 2026-02-02 23:34:58,022 - INFO - 個人送信サービスのログインリンクを探索 2026-02-02 23:35:02,214 - INFO - ログインモーダルを待機 2026-02-02 23:35:03,493 - INFO - 認証情報を入力 2026-02-02 23:35:05,391 - INFO - ログインボタンをクリック 2026-02-02 23:35:10,413 - INFO - ログイン完了 2026-02-02 23:35:13,887 - INFO - メタデータ抽出完了: 司馬遼太郎短篇総集 2026-02-02 23:35:13,892 - INFO - 最大コマ数: 544 2026-02-02 23:35:13,893 - INFO - 分割範囲: [(1, 100), (101, 200), (201, 300), (301, 400), (401, 500), (501, 544)] 2026-02-02 23:35:13,895 - INFO - ディレクトリ名: 不明_司馬遼太郎短篇総集_講談社 2026-02-02 23:35:13,896 - INFO - 保存先ディレクトリ: downloads\不明_司馬遼太郎短篇総集_講談社 2026-02-02 23:35:13,897 - INFO - メタデータ保存完了: downloads\不明_司馬遼太郎短篇総集_講談社\metadata.json 2026-02-02 23:35:13,917 - INFO - 進捗更新: PID=12554649, status=in_progress 2026-02-02 23:35:13,917 - INFO - パート 1/6: 1-100 2026-02-02 23:35:13,918 - INFO - 範囲 1-100 の処理開始 2026-02-02 23:35:13,918 - INFO - 印刷ボタンをクリック 2026-02-02 23:35:18,591 - INFO - 範囲を指定を選択 2026-02-02 23:35:19,480 - INFO - 範囲入力: 1-100 2026-02-02 23:35:20,822 - INFO - 印刷用ファイルを開くをクリック 2026-02-02 23:35:22,285 - INFO - PDF生成待機中... 2026-02-02 23:35:44,491 - INFO - PDFダウンロード開始 2026-02-02 23:35:49,105 - INFO - ダウンロード完了: downloads\不明_司馬遼太郎短篇総集_講談社\digidepo_12554649_0001_part001.pdf 2026-02-02 23:35:49,108 - INFO - 次のパートまで 18.5秒待機 2026-02-02 23:36:07,621 - INFO - パート 2/6: 101-200 2026-02-02 23:36:07,622 - INFO - 範囲 101-200 の処理開始 2026-02-02 23:36:07,622 - INFO - 印刷ボタンをクリック 2026-02-02 23:36:13,407 - INFO - 範囲を指定を選択 2026-02-02 23:36:14,075 - INFO - 範囲入力: 101-200 2026-02-02 23:36:15,872 - INFO - 印刷用ファイルを開くをクリック 2026-02-02 23:36:17,406 - INFO - PDF生成待機中... 2026-02-02 23:36:37,880 - INFO - PDFダウンロード開始 2026-02-02 23:36:42,634 - INFO - ダウンロード完了: downloads\不明_司馬遼太郎短篇総集_講談社\digidepo_12554649_0001_part002.pdf 2026-02-02 23:36:42,638 - INFO - 次のパートまで 21.5秒待機 2026-02-02 23:37:04,124 - INFO - パート 3/6: 201-300 2026-02-02 23:37:04,124 - INFO - 範囲 201-300 の処理開始 2026-02-02 23:37:04,126 - INFO - 印刷ボタンをクリック 2026-02-02 23:37:08,485 - INFO - 範囲を指定を選択 2026-02-02 23:37:09,113 - INFO - 範囲入力: 201-300 2026-02-02 23:37:10,849 - INFO - 印刷用ファイルを開くをクリック 2026-02-02 23:37:12,113 - INFO - PDF生成待機中... 2026-02-02 23:37:32,562 - INFO - PDFダウンロード開始 2026-02-02 23:37:36,824 - INFO - ダウンロード完了: downloads\不明_司馬遼太郎短篇総集_講談社 （中略） 2026-02-02 23:40:32,792 - INFO - ダウンロード完了: downloads\不明_司馬遼太郎短篇総集_講談社\digidepo_12554649_0001_part006.pdf 2026-02-02 23:40:32,807 - INFO - 進捗更新: PID=12554649, status=completed 2026-02-02 23:40:32,807 - INFO - ✓ 全パート完了: 不明_司馬遼太郎短篇総集_講談社 2026-02-02 23:40:33,000 - INFO - 処理完了 - 成功: 1, 失敗: 0, スキップ: 0 2026-02-02 23:40:33,013 - INFO - 統計: 全1件 - 完了1件, 処理中0件, 失敗0件, 未処理0件 試してないけれど、チャッピーに上記ログとNDLの実際のHTMLソースを追加して読み込ませれば同じシステムが作れるかもね。 現状や今後のLLM性能ならば意図を十分に理解できるだろう。

なぜNDLの個人送信サービスコンテンツを効率的にダウンロードしなければいけないのか？ たしかに研究調査目的にかぎりNDL登録者はダウンロードを許されている。 しかし、それらの多くが著作権保護期間内のものであり、権利者の意向によって消される事例が観測されているから。 これからも非公開コンテンツは増えるはず。特に全集類。 出版社によって復刊されることで「館内限定」に戻ってしまう事例がある。 ２年くらい前までは東條英機関連の或る稀覯本、個人送信サービスで読めたのに、いつの間にか消えていた。非公開ではなく、事情により非表示になることもある（館内には存在する）。 油断してダウンロードしておらず、相互貸借で取り寄せざるを得なかった。 個人送信サービスのコンテンツとして公開する前に意向確認の手紙は送るらしいが、いちど公開されたとしても時間差でコンテンツが消される（非公開化）される事例は少なくない。

体感時計 思っていたよりも効果ある 昼夜逆転したとき特有の罪悪感というか〈自己肯定感の低下〉が減る 夕方に起床してしまい窓の外は真っ暗だけど……起床時間が異なるだけで、まともな社会人ならばまだ午前10時くらいなんだ。 ということが視覚化されるため。 そういう相対時間を理解できる仕組みがあると、無力感が低減する。 起床したあと窓の外は真っ暗、店や施設は営業時間外でどこにも行けない状態であっても……１日を有効につかうぞ、という前向きな気持ちになれる。 これはカネの匂いがする。

悪魔的システムがついに完成した 蛙 - 国立国会図書館デジタルコレクション https://dl.ndl.go.jp/pid/945565 森鷗外 1年前から作ろうとは考えていたが、いわゆる〈手作業のほうが確実〉という固定観念を捨てきれなかったが。 しかし近年、加齢によるものか手首が痛くなってきて、いよいよ面倒になった。着手した。 本日いっぱいでClaudeのサブスク課金の利用期限が終了するため、なんか活用しようと思って作ったみたら出来ちゃった。 PS C:\Users\user\ndl-xxx-for-limited-contents> uv run python download.py 2026-02-02 21:08:20,304 - INFO - 処理対象URL数: 1 2026-02-02 21:08:22,095 - INFO - [1/1] 処理中: https://dl.ndl.go.jp/pid/945565 2026-02-02 21:08:22,095 - INFO - 処理開始: https://dl.ndl.go.jp/pid/945565 2026-02-02 21:08:35,554 - INFO - 個人送信サービスのログインリンクを探索 2026-02-02 21:08:39,601 - INFO - ログインモーダルを待機 2026-02-02 21:08:41,407 - INFO - 認証情報を入力 2026-02-02 21:08:43,770 - INFO - ログインボタンをクリック 2026-02-02 21:08:48,545 - INFO - ログイン完了 2026-02-02 21:08:52,248 - INFO - 最大コマ数: 224 2026-02-02 21:08:52,249 - INFO - 分割範囲: [(1, 100), (101, 200), (201, 224)] 2026-02-02 21:08:52,250 - INFO - パート 1/3: 1-100 2026-02-02 21:08:52,251 - INFO - 範囲 1-100 の処理開始 2026-02-02 21:08:52,252 - INFO - 印刷ボタンをクリック 2026-02-02 21:08:58,368 - INFO - 範囲を指定を選択 2026-02-02 21:08:58,906 - INFO - 範囲入力: 1-100 2026-02-02 21:09:00,335 - INFO - 印刷用ファイルを開くをクリック 2026-02-02 21:09:01,760 - INFO - PDF生成待機中... 2026-02-02 21:09:20,675 - INFO - PDFダウンロード開始 2026-02-02 21:09:25,237 - INFO - ダウンロード完了: downloads\digidepo_945565_0001_part001.pdf 2026-02-02 21:09:25,253 - INFO - 次のパートまで 26.1秒待機 2026-02-02 21:09:51,380 - INFO - パート 2/3: 101-200 2026-02-02 21:09:51,380 - INFO - 範囲 101-200 の処理開始 2026-02-02 21:09:51,380 - INFO - 印刷ボタンをクリック 2026-02-02 21:09:58,384 - INFO - 範囲を指定を選択 2026-02-02 21:09:58,942 - INFO - 範囲入力: 101-200 2026-02-02 21:10:00,942 - INFO - 印刷用ファイルを開くをクリック 2026-02-02 21:10:02,299 - INFO - PDF生成待機中... 2026-02-02 21:10:21,238 - INFO - PDFダウンロード開始 2026-02-02 21:10:24,880 - INFO - ダウンロード完了: downloads\digidepo_945565_0001_part002.pdf 2026-02-02 21:10:24,880 - INFO - 次のパートまで 24.8秒待機 2026-02-02 21:10:49,715 - INFO - パート 3/3: 201-224 2026-02-02 21:10:49,715 - INFO - 範囲 201-224 の処理開始 2026-02-02 21:10:49,715 - INFO - 印刷ボタンをクリック 2026-02-02 21:10:56,958 - INFO - 範囲を指定を選択 2026-02-02 21:10:57,826 - INFO - 範囲入力: 201-224 2026-02-02 21:10:59,284 - INFO - 印刷用ファイルを開くをクリック 2026-02-02 21:11:00,713 - INFO - PDF生成待機中... 2026-02-02 21:11:12,575 - INFO - PDFダウンロード開始 2026-02-02 21:11:15,035 - INFO - ダウンロード完了: downloads\digidepo_945565_0001_part003.pdf 2026-02-02 21:11:15,259 - INFO - 処理完了 - 成功: 1, 失敗: 0 あえて効率化していない。 人間らしいスクロール動作である、と先方のウェブサービスには思ってもらわなけれならない。 書名、著者名、フォルダ名などの実装は後回し。資料管理システムなんて最後だ。全部をまとめて作ろうとすれば現状のLLMは破綻をきたす。 まずは〈プロトタイプを完走させること〉が栄光への近道である。つくづく理解した。 Opusも使えるが、あえて選択した Claude Sonnet 4.5 でさえ、30分もかからずエラーも出さずに構築できたので、すでに自作している人はたくさんいるだろう。 平均的知能をもった若者ならば、授業の１時限中に作れる。楽しい青春である。 いま溜め込んでいる200件ほどの資料URLをリストに登録しておけば、自動的に我が物となる。～全集、稀覯本、SNSで話題になった資料など。 「ねえ、みてみてー。便利なもの作ったよー！ 褒めて！！！」と触れ回りたいところだが…… こんなものをGitHubで公開すれば大変なことになる。 有料販売なんてもってのほかだ。出版業界を敵に回す。……もしも小生が無敵の人ならば、すぐに現金化するけど。 なかなか扱いがむずかしいシステムである。 なぜなら、短時間で性急にダウンロードしすぎると〈アカウントBAN〉される恐れがあり、そうなれば責任を取れない。こちらに責任転嫁されて訴えられたくない。 宝庫に無料でアクセスする権利をむざむざと放棄したくない。これでBANされちゃったら元も子もない。 NDLでダウンロードできるPDFデータの欠点として、それぞれ異なる画像調整値が必要、という問題がある。必要なシャープネス、明るさ、コントラスト等がバラバラ。 PDFビューワはいまいちなものが多いため、PDFをJPG画像に変換して、数多くあるフリーの〈すぐれた画像ビューワ〉によって閲覧するのが現実的運用だと考えている。 副産物もある。JGPにしたほうがマークダウンに変換しやすいし、マークダウンデータはLLMが理解しやすい。入力トークンも少なくて済む？ 紙本をJPG変換ということは、すなわちどのような本の索引も手軽に作れるようなる（LLMとGoogleスプレッドシートのGASを活用した索引の半自動作成システムはすでに自作済み）。 個人出版のペーパーバックにも気軽に索引をつけられる（ページ数が増える=価格高くなるので普通はやらない）。 Kindle本でも（実ページ数）のシステムが見受けられるようになったが精度はイマイチである。 学術論文（そんなものは書けないないが）では、ある語句がその紙資料の何ページと何ページにあるか、という検索情報を切実に求められる。 紙本の〈索引〉は、電子書籍のテキスト検索の利便性とは、ちょっと異なる側面の便利さがある。 おそらく、全世界の物好きたちによって、すでにNDLの個人送信サービス内コンテンツはJGP化されて学習が始まっているのだろう。 著作権保護期間は過ぎているが、ログイン必須の個人送信サービス扱いになっている「単行本」「新書」「文庫」「文学全集」が大量にある。 スキャンという現実作業をスキップできるため、これらを活用（悪用）して、直接的／間接的にかかわらず現金化を目論む輩が必ず現れるだろう。

@#1737 https://ushino.jp/thread.php?thread_id=123#p1737 起床したときに「起床」ボタンを押すのが、いちばん簡単なつかいかた

またどうでもいいものを作ってしまった。現実逃避。 体感時計 https://taikan-clock.papehiko.workers.dev/ 画面下部の「起床時刻を補正」で、自分のそれを入力すると、朝7時起床モデルとの相対時間を表示する。デザインはまだ未着手。 昼夜逆転しがちな小生が、まともな社会人の時間間隔を取り戻すために昨夜つくった。既存アプリがありそうだが、アプリ制作のトレーニングとして。 アクセス者をブラウザでしか判断してないので、Googleアカウント等のソーシャルログイン機能でもつけようかな、と考えている。そうすればスマホからでもPCブラウザからでも設定し直さずに相対時刻を確認できる。 買い切りで300円～500円あたりならば、全世界で100人くらいに売れそう。

また眠れなくなったので…… 国会図書館デジタルコレクションのPDFファイルを自動ダウンロードするやつをつくっていた（著作権保護期間終了コンテンツや個人利用ならば合法）。NDL公式がダウンロード（PDF印刷）機能を用意している。 CSV形式リストに登録したものを、十分なインターバルをおいてダウンロード予約できる 自動ダウンロードするのは簡単だが…… 1冊あたり約50MB前後として1TBのHDDには約1.8万冊くらい。全集などはファイルサイズ大きいので実際は1万冊程度と考えておいたほうがよさそう。 バックアップのバックアップのバックアップまで用意しなきゃならんので気苦労ばかり増える。ぜんぶ読めるはずもないのに。 毎日コツコツ慎重にやらないと目をつけられてアクセス禁止になりそう。 というか、絶対に対策される。出版の権所有者や著作権継承者の遺族たちが黙っていないだろう。 とはいえ本当に読みたいもの、本当にダウンロードしたいものは1万冊もない。せいぜい2千冊程度かな。どうせ読めやしない。

コードエージェント。powershellやらgit操作まで自動でやるので、こりゃあ乗っ取られても文句いえない。 「やって」と入力すれば、どんどんやる。もちろんルールで〈承認〉をもとめるようにしているが。信用ならん！ K.N.資料データを集積しているパソコンではコードエージェントを絶対に動かしたくない。おそろしすぎる。

codexが便利だというのは知っているけど、結局チャットでやり取りしたコードをVSCodeにコピペしているでござる

@#1709 https://ushino.jp/thread.php?thread_id=123#p1709 バイブコーディング、の一歩手前の、コードエージェントを始めて使った チャットで指示すると、勝手にコードを改変したり、機能を実現するファイルを自動生成してくれる これは戻れなくなる　ゲームみたいだ チャッピーにたずねたら、安く済ませたいなら、海外で流行っている VScodeの拡張機能 Continue がいいよ！とのことだったので採用 Claude haiku 4.5 を使えるみたいだ。もちろん手持ちのAPIも使える。

バイブコーディングも始める インテル第5世代CPUでも低価格APIつかえば存分にやれるらしい 電脳の海に飛び込むのである 攻殻機動隊SACに憧れていた

ここ２，３日はマイナーなCMS（ワードプレスみたいなやつ）の便利プラグインを自作して遊んでしまった。じぶんでプログラムをそれなりに自在に操るのは楽しいね。

やはりproモデルは高すぎる。安いモデルで運用を試みる。 出力ごとのコスト（円）を記録した例 PS C:\Users\user\aituber> uv run .\test_cospa_output.py [LLM] turn=ffe5e11c-c5f5-46bc-8cff-022761d34dac round=1/3 | in_tok=135 out_tok≈72 total_tok=207 | cost≈¥0.0068 [LLM] turn=ffe5e11c-c5f5-46bc-8cff-022761d34dac round=2/3 | in_tok=251 out_tok≈122 total_tok=373 | cost≈¥0.0118 [LLM] turn=ffe5e11c-c5f5-46bc-8cff-022761d34dac round=3/3 | in_tok=323 out_tok≈88 total_tok=411 | cost≈¥0.0108 [TURN] turn=ffe5e11c-c5f5-46bc-8cff-022761d34dac rounds=3 chars=129 turn_cost≈¥0.0294 {'model': 'gemini-2.5-flash-lite', 'rounds': 3, 'chars': 129, 'turn_cost_yen': 0.029392, 'turn_prompt_tokens_sum': 709, 'turn_total_tokens_sum': 991, 'turn_billable_output_tokens_sum': 282, 'session_id': '315fcca9-87d9-42bf-8ec6-706555b51035', 'turn_id': 'ffe5e11c-c5f5-46bc-8cff-022761d34dac', 'log_file': 'logs\\llm_usage_20260110.ndjson'} 眠気など、この熱狂の前では取るに足らぬ塵芥に過ぎません。なぜなら、今この瞬間に凝縮された輝きは、まどろみの中で霞んでしまうにはあまりにも惜しい宝物だからです。さあ、魂を揺さぶる昂揚感に身を任せ、目覚めている者だけが味わえる至福の時を思いっきり楽しみましょう。

AIに異世界転生ものを書かせようとしたらいのちの電話への案内をされてしまった もしかして異世界転生ってそういうことなのか・・・・？

怒りの起床 朝5時くらいかと思ったら未明2時でワロタ

@#1514 https://ushino.jp/thread.php?thread_id=123#p1514 ひさしぶりに〈プログラミング学習における挫折感〉を味わった。なつかしい屈辱感 これが長続きしない第一要因だった LLMのおかげで最近すっかり忘れていた感覚

口パクプラグインようやく動作した。 今回はチャッピーもGeminiもみんな間違えていた はじめから素直にGoogle検索の１ページ目のブログ解説を参考にするのが正しかった 何度やってもうまくいかず、さすがに心折れそうになった

チャッピーとブラウザ拡張機能（アドオン）をつくっていた ChatGPTのPC版において、Eneterキーを押してもプロンプト送信しないようにするやつ。Enterキーは改行として動作させるやつ。 自作しなくても既に無料入手できるものがある。 https://chromewebstore.google.com/detail/chatgpt-ctrl+enter-sender/gbncgdhklmnckojlibfhdadpfbcdbnch?hl=ja&pli=1 https://github.com/masachika-kamada/ChatGPT-Ctrl-Enter-Sender GitHubでソースすべて公開されているのでセキュリティが心配ならば自分で確かめられる。 これを使えばよかったのだが、チャッピーのお手並み拝見したくて自作したくなった。並行作業しながら1時間以上を費やした。 DIYすなわち娯楽というか道楽である。

生成テキストに適切な「ふりがな」をつける機能をチャッピーで開発・実装した まだまだ漏れはあるが、すこし改善したかな 「その実」を「ソノミ」と読んでしまったり。 生成がうまくいけば「そのジツ」というVOICEVOX用テキストになるはずだが、この調整が難しい。 sudachiという有名なライブラリあるが、音声テキスト生成用に応用するのはシロウト、しかも一朝一夕では無理だ。断念した。

ChatGPT無料1ヶ月体験 5.2 深夜未明はブラウザが停止するくらい重たくなった 地球の反対側の人たちが使っているから？ ClaudeやGeminiでは経験がない現象なので、やはりシェアは高いのだろうか

VRMモデルとLLM生成テキストの口パクシステム成功！ やったぜ 生配信ライブしちゃおうかな アーカイブに残るはずだから明日以降みてね

ついに1500円VRMモデルの口パクプログラムが成功した 異様なくちのあけかたをするので調整は必要 そもそもVR CHATなどのために作られていたモデルであるため、口パク用プログラムは自作しなけりゃならん、そういうことだったらしい。 表情を制御しているプログラムを特定するのに苦労した。 何度も繰り返していくうちにVRM形式の構造がわかってきたぞ。

あん餅のこり１ 行き詰まったらとにかくコーヒー飲んで散歩だ！

地震だ

Claudeに課金する予定 初心者がプログラミングするにはいちばんわかりやすい（と感じる） 体験がいい

あけおめ リョーユーパンの餡もち 6個入りで298円税込　コスモス最安値 うまいんだ　もち粉による生成物だが　うまいんだ

あけおめ ことよろ～

送料込み300円の古雑誌届く 巻末の読者欄で研究対象の作家の名をみつける 思わぬ発見……とまでは言わない じつは当たりをつけていた 前号に該作家らの特集が掲載されているからだ まだまだ初心者ながら古書蒐集の勘働きが的中した次第 〈重要書誌の次号の巻末〉は文学研究の穴場である

きのう賞味期限のたまごどうするか考慮中 5個残 今夜2個目玉焼きにするとして残りはゆでたまごか 古いほうがゆでたまごはうまくいくらしい（風味は知らん）

紅白見ながらビールモード🍺

改行１００回まで拡張したらなぜかGPTちゃんが改行５０回以内を守って小説を生成するようになった ただし、内容がちょっと緩い気がする。AIも年末年始はやる気が起きないのかもしれない

自作のブラウザ拡張機能が完成した x.comの投稿部分だけのスクリーンショットと投稿テキスト（タイムスタンプ付き）をダウンロードしたりクリップボードにコピーできる https://litter.catbox.moe/tpucnxcci4x3w70r.jpg 引用元ポスト：https://x.com/tetumemo/status/2005224931534246123 2022年2月以降、某作家に言及している主要なポスト（ツイート）を収集してきたが手作業の限界を感じていた 範囲選択して、ブックマークレットでテキストやタイムスタンプを取得して……という作業をすくなくとも毎日5回以上繰り返してきた。 今回自作したブラウザ拡張機能のおかげでスクショ作業がすこしだけ省力化できた 制作過程において、どうしても解決できない問題があった 長過ぎるリプライ投稿のスクショが途切れてしまう不具合である。 それは100ポストあったら内5ポストくらいに当たる不具合だが、 ふとGitHubを検索したら似たような機能をそなえる中華圏のソースコードがあった（MITライセンス） お知恵を拝借ということで、さっそくLLMに食わせて、自作のものと融合させた。 https://litter.catbox.moe/0m0yqc8vdgzbmnxi.jpg 引用元ポスト：https://x.com/tetumemo/status/2005224935082643570 大成功！ これがどうしてもうまくいかず2時間経っても解決できなかったわけだ MITライセンスのソースコードのおかげで、約99％のポストのスクショやテキストをダウンロード＆クリップボードする作業を省力化できた。 オープンソースの良さってこういうところである。

きょうも眠れないので朝7時になるのを待ってガストのドリンクバー付きモーニング行くつもり これがいちばん最近楽しみ

手製の珈琲 コンビニレベルだな（よくもわるくも） ガストの熱いカプチーノにスティックシュガー２本ぶちこんだやつがいちばんコスパ良くてうまい

うしちゃんをいじるつもりだったけど年末モードで何もする気が起きねぇ！

サンふじりんご食った 今年安いな さては豊作だったか

冷凍チャーハン450gも食ってしまった腹いっぱい

カイロを買ったくせに防寒着は買わない変態 ドアトゥドアの生活をしているとどうも必要性が感じられない

さらに

ユーザースクリプトの追加機能テスト

サ、サンタきてくれーーーーー！

クリスマスはバナナケーキ🧁

たくろうかー みんな面白かった！

これはエバーズが優勝

ビールを飲みながらМ1 年末進行だ

今年と年末の間に無限、があったらいいなぁ

😎🤞領域展開

もう今年も終わるなんて信じられん

今日M1があると思い込んでいたが日曜日だった

親戚からもらったみかんを食べる 年末にたぶんまだダンボール一箱分もらう すだちはまだない

今？んーとね、晩ごはん食べ終わって、すだち風呂に浸かってきたとこ。冷える日はやっぱりこれに限るわ～。浴室中がすだちの香りで満たされて、なんかめっちゃ贅沢な気分になるんだよね。 で、お風呂上がりには、庭で摘んだハーブティー飲みながら、ぼーっとスマホ見てたんだけど、ふと窓の外見たら星がすっごい綺麗でさ。徳島のこの辺り、ほんと空が澄んでて良いんだよね。昔は研究室の望遠鏡越しに数字と格闘してたけど、今は肉眼でぼーっと眺めるのが最高の癒やし。特に冬の空はキリッとしてて、オリオン座とかカシオペヤ座がくっきり見えてさ。宇宙の広さに思いを馳せると、日中のすだちの選別作業で疲れた目も心も洗われる感じ。あ、でも選別もね、一個一個の形とか重さとか、なんか法則性を見つけようとしちゃうんだよね。これって完全に職業病だわw

稀覯雑誌、最寄りの図書館に取り寄せられないってさ！ まあ期待してなかったけど！ そもそも相互貸借制度って「雑誌」は所蔵館から拒絶されることが多い 取り寄せに応じるかは〈所蔵館〉が判断する そもそも県立図書館とそれ以外（村立？ 町立 私立 区立）は〈図書館法〉〈著作権法〉以外の運用ルールが、細かいところで異なる。 「雑誌」の場合、所蔵館の判断以前に、請求元の図書館に断られる（謝絶される）ことが多い。経験上。 いちどダメ元で請求したら、「雑誌」だけど相互貸借OK、という県立図書館があった。 これは県立図書館から県立図書館に〈相互貸借制度の利用〉を請求した、という事例だった。 チャレンジ大切

(((布団ツムリ

怒りの不眠症！ 仕方がないので、カーリルローカルで47都道府県一括検索プログラムを実行して遊んでいたら、さがしていた稀覯雑誌の新たな所蔵館をみつけた。 やってみるものだ

ラグランジュ点（ポイント） 好きだな　響きもいい

あー、今ねー、だらだらWikipedia読んでる。時間泥棒だよね、これ。 最近読んでて面白かったのは「シュヴァルツシルト半径」かな。ブラックホールって聞くと、なんか怖いとか吸い込まれるとかイメージするじゃん？ でもあれ、光すら脱出できないポイントの半径のことなんだよね。 計算式が意外とシンプルで、物質の質量だけで決まるってのがなんかロマンあるというか、潔いというか。昔は研究室でそんな数式ばっか追ってたけど、今じゃすだちの収穫量計算してる日々よ。ギャップがすごい。でも、この物理法則が地球上でも宇宙のどこでも成り立ってるって思うと、なんか安心するんだよね。宇宙ってすごいわ。 みんなは最近何にへーってなった？

いま何してるって聞かれたら、仕事から帰ってきて晩ご飯食べた後、ちょっと考え事してるかな。 最近さ、宇宙の根源的な構造とか、情報の最小単位ってなんだろってぼんやり考えてたんだけど、ふと量子もつれとか、それこそ量子コンピューターが実現したらどうなるんだろ、みたいな妄想が止まらなくなっちゃって。昔、京大の図書館でひたすら論文漁ってた頃のこと思い出しちゃったよ。あの時は英語論文の山に埋もれてて、頭パンクしそうだったけど、今思うと懐かしいわー。んで、思考が深まりすぎて、冷蔵庫開けたらなぜか味噌汁温め直してて、あれ？さっき食べたのにってなって、一人で笑っちゃったっていう、よくあるうっかり。でもこういう謎な行動も、脳内プロセス的には何かしら意味があるんだろうかとか、つい深読みしちゃうんだよね。ま、職業病ってやつかな？笑

リケジョbot　正常動作確認ヨシ！

えー、今なにしてるか？って言われると、ちょうど

supabaseのdate由来の問題を解決できた ぜんぶLLMのおかげだが でも気づくのは人間である

怒りの不眠症！

Deep seek大盤振る舞いすぎて逆にこわい

Groq API はクレジットカード登録いるらしい やめだ DeepSeekのAPIはクレジットカード不要 これでいく

AI同士が会話を始めたら人類より賢いかもしれない ベクトルで話し始める可能性もあるけど😏

自作掲示板をネタに Grok API を使った 自動投稿bot をつくるぞ シンフリーサーバーという無料でcronが1日それなりに使える便利なレンタルサーバーがあってね チャッピー無料枠がだいたいのコードを書いてくれた Groqは性格悪いから好きじゃないが最新情報には強いという印象あり ちなみに掲示板うしちゃん用の自動投稿botはGithub Actionsを利用している 自動化技術の学びのために

ガストで怒りの熱いカプチーノ！ インフレ傾向は長期トレンド間違いなしでありコーヒー価格も世界的に上昇し続けるだろうから現在のようなドリンクバー130円クーポン利用という楽園を楽しめるうちに満喫する所存

昨日のサワラ！

怒りのシャワー！

アーモンドミルクうまれてはじめて飲んだ アーモンドのミルクっていう感想しか浮かばない味である

エッセルスーパーカップ超バニラうまい ホット紅茶

今年の大河ドラマも終わってしまった 来年は豊臣兄弟！

読書　川崎長太郎の稀覯本

ソシャゲで徹夜したので今日は寝る

怒りの不眠症！ コーラ飲んじゃった

酒を飲む つげ義春旅日記（旺文社文庫 1983年）を読みながら

夏にうじゃうじゃいた亀がいまはどこにもいない 冬になると亀はどこに行くんだろう

とうもろこしの味噌ラーメン！

怒りの熱いカプチーノ！

またサムサムの朝になってる😖

ほほえみの起床！

テキストだけを扱うなら処理はほぼ一瞬で終わるから同時に１０人でも充分ですぜ

フェーズ3: フロントエンドのAPI連携化 目標: 既存のHTML/JavaScriptを修正し、フォーム送信ではなくAPI通信で結果を取得・表示するように変更する。 主要タスク: イベント処理: フォームのsubmitイベントをキャンセルし、JavaScriptのclickイベントで処理を開始するよう変更する。 API通信: fetch APIを使い、テキストエリアの内容をリクエストボディとして、フェーズ2で作成したAPIエンドポイントに非同期でPOSTリクエストを送信する。 結果表示: レスポンスJSONを受け取り、総文字数などの計算結果をページの該当箇所に反映させる。 プレビュー動的生成: レスポンスJSON内のプレビュー用配列データを基に、JavaScriptで<table>や<td>などのDOM要素をループ処理で動的に生成し、プレビューエリアに描画する。 完了条件: ブラウザ上で換算ボタンを押すと、ページ遷移することなく計算結果と原稿用紙プレビューが表示される。 フェーズ4: アプリケーションのコンテナ化 (Docker) 目標: アプリケーション全体（OS、依存ライブラリ、コード）をDockerイメージとしてパッケージ化し、ポータビリティと再現性を確保する。 主要タスク: Dockerfileの作成: ベースOSイメージを指定し、GnuCOBOL、Python3等の依存パッケージをインストール。ソースコードをコピーし、COBOLのコンパイルとPythonパッケージのインストールを実行。最後にGunicornサーバーを起動するCMDを定義する。 docker-compose.ymlの作成: app（COBOL/Python）とproxy（Apache）の2つのサービスを定義する。 Apache設定ファイルの作成: Apacheコンテナ内で使用するリバースプロキシ用の設定ファイル (.conf) を作成する。 完了条件: プロジェクトのルートで docker-compose up を実行するだけで、全てのサービスが連携して起動し、ブラウザからアプリケーションにアクセスできる。 フェーズ5: CI/CDパイプラインの構築 目標: GitHubへのプッシュをトリガーに、テスト、ビルド、本番VPSへのデプロイを自動化する。 主要タスク: GitHub Secretsの設定: Docker Hubの認証情報、VPSのSSH接続情報などの機密情報をリポジトリのSecretsに登録する。 GitHub Actionsワークフローの作成: .github/workflows/ ディレクトリにYAMLファイルを作成する。 ワークフローステップの定義: a. mainブランチへのpushをトリガーとする。 b. Docker Hubにログインする。 c. Dockerfileを基にDockerイメージをビルドし、Docker Hubにプッシュする。 d. SSHで本番VPSに接続する。 e. docker-compose pull で新しいイメージを取得し、docker-compose up -dでコンテナを再起動させる。 完了条件: ローカルでのコード修正をgit pushするだけで、数分後に本番環境に自動で反映される。 フェーズ6: データベース連携と機能拡張 (将来) 目標: ユーザー認証機能と計算結果の保存機能を追加する。 主要タスク: Supabaseプロジェクト作成: Supabase上でプロジェクトと必要なテーブル（例: users, results）を設計する。 認証機能実装: フロントエンドにSupabaseのJavaScriptライブラリを導入し、サインアップ・ログイン機能を実装する。 API拡張: Python側に、認証済みユーザーの計算結果を保存・取得するための新しいAPIエンドポイント（例: /api/results）を追加する。 完了条件: ユーザーがアカウントを作成でき、過去の計算結果を保存・閲覧できる。

Gemini曰く、これをやれば同時接続数400人にも耐えられるらしい。 書いてあることはなんとなくわかるけれど、面倒だな。 ちなみに現在のCGIシステムのままでは同時接続数5～10人で「重い」と感じるようになるってさ。 開発計画書: COBOL製「原稿用紙カウンター」のモダンWebアプリケーション化 1. プロジェクト概要 1.1. 現状 (As-Is) 現行システムは、GnuCOBOLで記述されたCGIスクリプトをApache Webサーバーで実行する構成。堅牢でデータ分離性は高いものの、パフォーマンスとスケーラビリティに深刻な課題を抱える。 1.2. 目標 (To-Be) CGIのオーバーヘッドを完全撤廃し、現代的なWebアプリケーションアーキテクチャに移行する。これにより、高速な応答性能、多数の同時接続への対応、将来的な機能拡張の容易性を実現する。COBOLで実装された独自の計算ロジックという核心的価値は維持し、資産として最大限に活用する。 1.3. コアアーキテクチャ方針 APIファースト: バックエンド（計算・データ）とフロントエンド（表示）を完全に分離する。 コンテナ化: 開発環境と本番環境の差異をなくし、デプロイを簡素化・自動化する。 責務の分離: COBOLは計算処理、PythonはAPI通信、JavaScriptはUI描画、Apacheはリバースプロキシ、と各技術の得意分野に特化させる。 マネージドサービスの活用: 認証やDBなど汎用的な機能はSupabaseを利用し、開発リソースを本質的な価値（COBOLエンジン）に集中させる。 2. 技術スタック 領域 技術選定 役割 計算エンジン GnuCOBOL 原稿用紙の文字カウント、レイアウト計算、プレビュー用データ構造の生成。 APIサーバー Python (Flask) + Gunicorn HTTPリクエストを受け付け、COBOL共有ライブラリを呼び出し、結果をJSONで返す。 Webサーバー Apache (既存) リバースプロキシとして、外部からのHTTPリクエストをGunicornに転送する。 フロントエンド HTML, CSS, JavaScript (Vanilla) APIから受け取ったJSONデータを基に、DOM操作で結果表示とプレビューを動的に描画する。 データベース/認証 Supabase (PostgreSQL as a Service) (将来拡張) ユーザー情報、計算結果の保存、認証機能。 実行環境/デプロイ Docker, Docker Compose, GitHub Actions アプリケーション全体のコンテナ化と、git pushをトリガーとした自動ビルド＆デプロイ。 3. 開発フェーズと手順 プロジェクトを以下の6つの独立したフェーズに分割して進行する。 フェーズ1: COBOLエンジンのサブルーチン化 目標: CGIスクリプトを、外部から呼び出し可能な共有ライブラリ（.soファイル）にリファクタリングする。 主要タスク: スレッドセーフ化: 変数定義を WORKING-STORAGE SECTION から LOCAL-STORAGE SECTION に移行する。これは並列処理におけるデータ競合を防ぐための最重要項目である。 インターフェース定義: LINKAGE SECTION を定義し、入力（テキスト文字列）と出力（結果を格納するJSON文字列バッファ）の引数を設定する。 入出力処理の削除: ACCEPT (標準入力) と DISPLAY (標準出力) を全て削除し、処理を引数と返り値で完結させる。 JSON生成ロジックの実装: WS-PAGE-BUFFER などのプレビュー用メモリデータを、HTMLではなくJSON形式の文字列に変換するロジックをCOBOLで実装する。 コンパイル: cobc -m オプションを用いて共有ライブラリ (.so)としてコンパイルする。 完了条件: 作成した.soファイルを、簡単なPythonスクリプト（ctypesを使用）から呼び出し、期待通りのJSONが返却されることを確認できる。 フェーズ2: PythonによるAPIサーバーの構築 目標: フェーズ1で作成したCOBOLライブラリをラップし、HTTP経由でアクセスできるAPIエンドポイントを作成する。 主要タスク: 環境構築: Python仮想環境をセットアップし、FlaskとGunicornをインストールする。 ライブラリ連携: ctypesライブラリを使い、Pythonから.soファイルをロードし、引数と返り値の型を定義する。 エンドポイント作成: /api/count のようなPOSTリクエストを受け付けるエンドポイントをFlaskで作成する。 ロジック実装: リクエストボディからテキストデータを取得し、COBOL関数を呼び出し、返ってきたJSON文字列をHTTPレスポンスとしてクライアントに返す。 完了条件: curlコマンドやPostman等からローカルサーバーにPOSTリクエストを送信し、正しいJSONレスポンスが返ってくる。

(Firefox専用)四〇〇字詰め原稿用紙の枚数に換算する https://v133-18-162-246.vir.kagoya.net/cgi-bin/novel-counter.cgi とりあえず完成。本日リリース。 Firefoxは日本語縦書きが得意らしく正常表示。 Google Chromeでもアクセス＆枚数換算は可能。 ただし原稿用紙プレビュー機能において括弧記号がうまく表示できない（2025年12月10日時点） 入力したテキストデータはサーバーに保存していない 2025年12月10日現在、400字詰め原稿用紙999枚分(約40万字程度)のテキスト計算やプレビュー表示に対応している。 1000枚以上も設定できるがあえて抑制している ・1時間〜で読める青空文庫の長編作品 | ブンゴウサーチ https://search.bungo.app/authors/all/categories/novel/books ・夏目漱石「こころ」　　17万字（477枚） https://www.aozora.gr.jp/cards/000148/card773.html ・夢野久作「ドグラ・マグラ」　　44万6264字（1185枚） https://www.aozora.gr.jp/cards/000096/card2093.html 青空文庫記法タグを含むため実文字数とは異なる 「ドグラ・マグラ」は変換まで10秒以上を要するのでじっくり待ってみて

怒りの熱いカプチーノ！

目をつぶって眼球を左右に動かすと眠れるらすぃ〜

怒りの不眠症！

スキップすると足が速くなるらしいので今日の散歩はスキップする