Chrononglyph

このブログは、"こっぱちゃ"の日記系個人ブログです。2004年より連載中。毎日00時更新、掲載は7日遅延します。執筆に際しAI不使用。 記事を読んだら「いいね 」押して頂けると執筆の励みになります。
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
06
07
08
09
10
11
12
#8177

作業三昧の黄金連休 #2

今年のゴールデンウィークは作業三昧と割り切って計画しましたが、結果的にはかなり良かったと思います。
まず、最大にして唯一のタスクという位置付けだったイベントアプリ開発の着手。
これは内心、UIを作り始めるところまで行ければ上出来かな……と思っていました。
なんだかんだでCodexと連携するための設計書が大きなネックになって、形式的にはそれほど進まないだろうと。
ところがどっこい、蓋を開けてみれば1日目で設計書はまとめ終わり、2日目から本格的な開発が始動。
3〜5日目もなんだかんだで各日それなりの進捗があり、
「UIに着手」どころか想像していたUIの大半はプロトタイプとはいえほとんど完成してしまいました。
3年間の躊躇はいったいなんだったのか……。


まぁでも、この快進撃はCodexとGPT-5.5だからこそというのもあると思います。
少なくともCodex導入以前、つまり人間が全体像を把握した上で関数単位でAIに任せる方式だったら
こんな複雑怪奇なコーディングを丸投げなんて絶対できなかったはず。
Codexのリリースは去年の秋であり、
リリース当時から使い始めていたとしても年内には間に合わなかったであろうことを考えると、
今年ようやくコマが揃ったと言えるのかも。


ただ、とはいえ順風満帆というわけではありません。
おそらく非プログラマーには理解されないレベルでエージェントコーディングもいろいろ試行錯誤しています。
AIもエスパーではない以上、言語化されていないような仕様まで読み取って実現してくれるわけではないため、
個々の細かい動作について逐一改修指示を出さないと思っている通りの動作はしてくれません。
まずその点でめちゃくちゃ言語化スキルを問われるし、入力する日本語も齟齬を生まないように気を付ける必要があり、
これはこれでプログラミングとはまた違うスキルを求められるのかなと改めて思います。
当然、言語化するためにはアプリの設計事情にある程度精通している必要があり、
AIがあるからといってまったくの素人ができるのかと言われるとかなり疑問です。
今回はWebとゲームのハイブリッドみたいなプロジェクトなのですが、
自分もWeb系の仕様については細かく突っ込めるものの、ゲーム的な仕様やデザインなどはAIがありつつも苦戦しています。
デザインなんかは言語化という伝達手段そのものにも限界があると言え、
この辺はまだまだ既存のクリエイターに優位性がありそうです。


「GPTが優秀すぎてポン出しだけで本格的なゲームが作れた!」みたいな声をGPTアプデのたびに聞きますが、
それはネットに転がっているソースをただ組み合わせればできるレベルのほぼパクりか、
同じくネットにソースがもうあるレベルのシンプルな要件のアプリに限られると思います。
自分が思い描いているアプリを過不足なく動かすには、人間側がすべての情報を言語化してAIに開示しなければなりません。
その苦労はとても「ポン出し」レベルでは済まないはずです。


そういうわけで、設計書が大きなネックかと思いきやここからが本番な雰囲気のアプリ開発ですが、
作業自体はいままでに無いことをやっていてかなり新鮮で楽しいので、これ自体は問題なさそうです。
こだわりのポイントをどこまで詰めるか、完成をいつに据えるかといった問題は別途ありますが、
いったんこの勢いで行けるところまで行ってみようかなと。


GWではこれ以外でも、これもネックになっていた創作アシスタントのスマホ環境整備(#08161 / 2026年04月20日)についても、
ネックを解消してスマホでの吟味を再開できるようになりました。
要は創作系ナレッジの最新情報がスマホとPCでバラバラになりがちなため、
いったんCodexのアシスタントができるようにPCに最新環境を構築してみたものの、
実際に着想したアイデアを吟味するのはスマホ環境であることが多いため、情報が散らばってしまうという悩みでした。
これについてはいったん不定期に手動で同期する方法を採りましたが、
GPT Projects機能が特定のリポジトリと連携できるようになったら一挙に解決するため、
ぜひその辺のアップデートをしてほしいものです。


このほか、生活系のタスクや細々としたタスクも用意していたのですが、ほぼ完遂できました。
唯一、ブログだけは余剰を生み出せませんでしたが……。
いずれにしろここまで計画通りにタスクをこなせた長期連休ってかなり久々なんじゃないだろうか。
普通に03月帰省よりも及第点は高く、実家帰省に依存せずとも作業モチベは捻り出せるのだという自信がつきました。
これにより、実感できるレベルでもろもろのタスクが次のステップに進んだため、
ゴールデンウィーク明けからは心機一転頑張っていきたいところです。


#8176

機会損失の歴史

これは30代が語ることとしてはわりとベタな話題なのかもしれませんが、
最近改めて「機会は待ってくれない」ということを痛感しています。
たとえば、いま自分はようやく重い腰を上げてイベントアプリの準備に取り掛かりました。
最新の技術スタックをふんだんに使っているプロジェクトでしかも完成の目処も立っており、
苦しみながら作っていた6年前の同等イベントと比べるとその規模は完全に雲泥の差であることは間違いありません。


しかし、仮に2026年夏秋のいずれかのベストタイミングで開催できたとしても
想定参加者は少なくとも15人は割るだろうと思われ、10人行けば御の字と考えざるを得ないという状況です。
対して6年前はここまで大掛かりでなかったにも関わらず、25人もの参加者が盛り上げてくれました。
重い腰がどうしても上がらなかったのは、界隈の衰退に対する「割りに合わなさ」に抗えないと思ったのもあり、
今更になって着手できたのはそれに対する諦めの気持ちも多分にあります。


こういうことは歳を重ねると多方面で感じるようになります。
そのもっともありがちな例はコミュニケーション能力でしょう。
自分はここ3〜5年、ほぼ毎年のように実感できるレベルでコミュニケーション能力が改善していると思っています。
もしかしたらそれは自意識過剰なのかもしれませんが、
コミュニケーションが左右するような査定評価や会社での立ち回りやすさなどから言っても間違いないのかなと。
逆に言えば、5年以上前の自分はあまりにもひどかった。
この違いは社交スキルの有無というよりもメンタル的なところに原因がありそうですが、
5年以上前の自分はいかにも自己中心的で協調性も無く、まあひどいものだったと思います。
周囲を気遣えるだけの心理的余裕が無かったのでしょう。


しかし、周囲の人に恵まれていたのは間違いなくここ5年以内よりも5年以上前、つまり上京前です。
もちろん上京後にできた縁も大事なのは絶対そうなのですが、
「濃い」人間関係を構築できていたのは圧倒的に上京前の方が多いんですよね。
他人を気遣えないから、何も考えずに他人の懐に入ってたまたま受け入れられていただけなのかもしれませんが。


いずれにしろ、いまのコミュニケーション能力で昔の会社や学校にいたら、と思わずにはいられません。
絶対にその方が良く立ち回れただろうし、それによって得られるものは多大だったでしょう。
その「果実」は、現実この先頑張ったところで果たして手に入れられるのか、甚だ疑問です。
しかしまぁ、こんなのはよくありがちな自己都合ありきの妄想に過ぎないわけです。
結局のところ、経緯がどうであれ磨き上げてきたスキルを使えるのはこれから先にしかなく、
また不足していた過去があるからこその この現状なのでしょう。
手札が揃うまで待っていたらものすごい時間が経っていて、気がつけば盤面は当時とは似ても似付かぬものになっている。
自分はそういう未練がましいものをいまだ多く携えていますが、だからといって手放すこともできません。


思うに、昨今の自己満足への盲信というか、他者承認への不信に絡む考え方の諸々は、
実はこういう機会損失の歴史がそう思わせている節もありそうです。
だとすればその哲学は、自分のように機会を逸し続けてきた間の悪い人への慰み言葉にしかならないのでしょう。


#8175

高校の参考書を読む

今日の出来事読書

ゴールデンウィーク明けの出社日に読むための本を物色するために、
最寄駅の書店よりも比較的大規模な立川高島屋のジュンク堂へ行きました。
自分の中で書店規模の序列は「池袋ジュンク堂>丸の内丸善>立川ジュンク堂>地元本屋」となっていて、
ガチで大人買いしたいときは基本的に池袋か東京駅へ行きます。
今回はそこまでガチでもないが多少ガッツリ探したい気持ちもあったので立川がちょうどいいと判断。
最近できた神保町の三省堂書店も気になってはいるんですけどね。


書店は主なカテゴリを隅々まで練り歩き、今回新たなジャンルの発掘に成功したかもしれません。
それは「高校の参考書」。
え、いい歳したおっさんが高校の参考書を? と思われるかもしれませんが、かなり面白そうですよ。
自分が今回手に取ったのは2022年の指導要領で「公共」と呼ばれている科目。
いわゆる公民科の1カテゴリで、2022年から必修になった新しい科目のようです。
出来の良さそうな参考書を手に取ってパラっとめくってみると、
青年期の心理(エリクソン、マズロー、フロイト)から古代哲学、主な宗教、近代哲学(カント、ヘーゲルなど)、
実存哲学、現代の哲学、生命倫理まで網羅していてとっても面白そう。
そこから政治の仕組み、社会の仕組みの基礎までを1冊でまるごとカバーしているので、
単純に知的好奇心を満たす大人のエンタメ本としても魅力的に感じました。
もちろんかなりかいつまんだ内容しか書いていないことには注意が必要ですが、
全体像を把握するにはもってこいなんじゃないかなと。


ちなみに、本当は国語の教科書が売っていたら買うつもりで学習参考書コーナーを探し回っていました。
どうやら教科書はこの手の書店には置いていないそうで、ちょっと特殊な書店に赴く必要があるそうです。
以前、生物の教科書をAmazonで探したときに普通に買えた記憶があるので、教科書については通販に頼るのも手かも。
国語も面白そうな参考書があれば買おうかなと思ったのですが、
こちらは文章題の解き方に特化した本ばかりという印象で、さすがに現役生以外に需要はなさそうな雰囲気です。
「国語便覧」という本が歴史のガイドも兼ねていて面白そうではありましたが、
自分が求めているのは教科書に載る近現代の作品を普通に読める本なので、やはり参考書ではなく教科書が無難そう。
「公共」を面白く読み終えられたら、次は歴史に手を出そうかなと思っています。
なぜこの学習意欲を現役のうちに発揮できなかったのか……と思わずにはいられませんが、
それについて書き出すと猛烈な学校批判になってしまうので割愛します。


そのまま立川のカフェで読み途中だった本に取り組み、9冊目を読み終えました。
10冊目からは予定通り新書縛りを解除して単行本などにも着手します。
公共の参考書はさすがに読書メーターに載せられないのでノーカウントにするつもりですが、
こういう本はこういう本で楽しむ余地も捻出したいところです。


#8174

想定外の高負荷

今日の出来事web制作

いよいよ満を持して中型イベント専用アプリ(期間限定ランキング)開発に着手しました。
技術スタックはReact(Next.js)、Phaser 4、Laravel APIで、
主にフロントエンドコンテナのAPIはNext.js、スクロールなどweb的な動きをさせたい部分はReact、
ゲーム的な動きをさせたい部分はPhaser、サーバーサイド処理をLaravelに任せるといった構成です。
このうちPhaserはいわゆる2Dブラウザゲームを作るためのゲームエンジン的なもので、今回が初使用。
自分はまったく存じ上げませんが、実装主体はCodexに全面的に任せる方針を採用しているため、
ネットにノウハウさえ転がっているなら実務経験ゼロでも採用できるというわけです。
年初にほんの少しPICO-8に触れたことを除けば、本格的にゲーム系プラグインに触れるのはこれが初めてとなります。


が、いざスタートしてみると思いもよらぬところで壁にぶち当たりました。
開発していると頻繁にMacbookのWindowServerが落ち、そのタイミングで強制再起動がかかってしまうのです。
最初、これは最近アプデしたmacOS 26.4.1に固有の不具合なのかと思っていました。
ChatGPTに確認すると確かに当該バージョンでWindowServerが落ちるという報告があると言うので。
ただ、あまりにも頻繁に再起動するので、もしこれが世界中のユーザー環境で起きているならもっと騒ぎになっているはず。
そうでないということは、この開発のせいでは?
……と思いアプリ側、特にPhaserの設定を見直したところ、あっさり改善しました。
アプリの描画負荷があまりにも高かったので、
OSのウィンドウレンダリングを司るプロセスをクラッシュさせてしまっていたわけです。


今回作成しているwebアプリはそれほどレンダリングに負荷を与えるものではないと思っていました。
3Dアクションを作っているわけでもないし、そもそも常時何かが動いているわけでもない。
しかしまさかOSのコアプロセスをクラッシュさせるなんて……。
この辺はAIに任せきりでは大変な負荷がかかるものだと思って、
意識的にレンダリング負荷を落とす工夫を盛り込む必要があると感じました。
今回のこれは自分の環境で動けばOKというものではなく、参加希望者すべてのPCで無事に動かなければなりません。
自分の開発環境であるMacbook Pro M1 Maxはそこまでスペックが低いとも言えないので、
この環境で落ちてしまうようでは先が思いやられます。


開発自体は思っていたより10倍順調なのですが、
レンダリング負荷などのように当初想定していなかった作業は他にもありそうな予感がしています。
一番良くないのはリリース後にそれが発覚することなので、とにかく多方面からテストする必要はありそう。


余談ですが、YouTubeで2017年のアニメ『けものフレンズ』が期間限定で全話無料公開されていたので、
作業のお供に流していました。観たのはほぼ9年ぶり(#04864 / 2017年05月01日)でしたがやはり面白いですね。
内容について語り出すとまた止まらなくなるので割愛しておきますが。
ガッツリ作業するときのお供にアニメ、意外と悪くないかも?


#8172

突き指の労災切り替え

今日の出来事トラブル

珍しく病院で嫌な思いをしたので、備忘録がてら書いておきます。
先月初頭にオフィスビルの近辺で突き指をした件(#08142 / 2026年04月01日)。
当時はまず退勤後に診療を受けられる病院に行く必要があり、
かろうじて某駅前で夜遅くまで受け付けている病院があったのでそこでレントゲンやら電気治療やらの施術を受け、
大量の湿布をもらって帰りました。
その病院をGoogle Mapsで見るとめちゃくちゃ評判が悪く、
確かにいかにも昭和の匂いがする前時代的な病院で診療のクオリティも微妙なのは確かではあるものの、
退勤後のサラリーマンが診療を受けたいというニーズの受け皿になっているのは素晴らしいと思ったものです。
そういう意味ではクチコミの低評価も不当なのではないかと思ったものでした。


しかしその後、会社の総務にいちおう顛末を報告したところ「労災を適用できそう」と連絡が来ました。
突き指をしたのは04月01日で、通勤経路が変わるまさに当日でした。
一般に通勤中の事故(通勤災害)が労災として認められるためには
その災害が会社に申告した通勤ルートで起きている必要があり、関係ないルートでは原則認められません。
自分の場合はオフィスビルの近くなので電車の通勤経路はあまり関係ないといえば関係なかったのですが、
いずれにしろまだ通勤経路を申告していない段階だったので病院では普通に健康保険で受診したんですね。
これを労災に切り替える書類が「療養給付たる療養の給付請求書 様式第16号の3」というもので、
会社にはこれを病院に出せば労災に切り替えられると言われたので病院に持っていきました。
いちおう、本当にこれで通るのか不安だったのでネットで少し調べたところ、
基本的には(病院側も料金は把握しているはずなので)領収証等は不要という情報があり、それを信じて病院へ。


ところが受付のおばさんは不機嫌そうな表情で
「うちは一度受診したのを労災に切り替えるのはやってないんですよ」と受け取りを拒否。
少なくとも返金対応するには領収証がいると言われ、
またここまで歩いてくるのが面倒で仕方ない自分は少し食い下がって
「この書類さえ出せば病院側は切り替え対応できるはずなので少し調べてくれませんか?」と対応を求めたのですが、
結局受付のおばさんはこれに応じず、後日連絡するからと言われ書類は持ち帰ることに。


やや憤慨しつつもこれを会社にいちおう報告すると、労災に切り替える「様式第16号の3」で病院が対応してくれない場合、
返金を労基署に直接請求する「様式第16号の5」を用意する必要があるとのことで、
しかもその場合健康保険適用ではなくいったん自己負担に切り替える手続きが必要になり、
病院がレセプトを健康保険組合に送ってしまった場合は健康保険組合側への手続きもしなければならず、
まあ簡単に言えばめちゃくちゃ面倒くさくなるということです。
この突き指の自己負担額はたかだか2,190円なので、すでに割に合いません。


会社からは「病院に『自己負担に切り替えることはできるか』、
『様式第16号の5なら対応してくれるのか』の2点を確認してほしい」と言われ、後日渋々病院に電話。
するとそれを訊く前に病院側から「本来対応していないが、領収証さえ持ってくれば様式第16号の3で対応してやってもいい」
と大変上から目線で特別対応をしてもらう旨の提案があり、
今日再び病院に行って無事に返金対応を受けてきたという次第です。


そういうわけで微妙なケースで健康保険を選択してしまったがためにたらい回しにされて散々でしたが、
まあ最終的にお金は戻ってきたのでよしとします。
そして今回受付のおばさんとのやりとりを通じて、
Google Mapsのクチコミにボロクソ書かれている件についてはちょっと納得してしまいました。
こんな粗暴な対応をする人が受付の椅子に座っていたらそりゃ病院としての印象は良くないわな。


#8171

都内で過ごすゴールデンウィーク

今日の出来事休日計画

今年は帰省しないことにしたゴールデンウィーク。
新年度からプロジェクトが変わるので参画して早々に有休を使いにくいと思ったのが主な理由で、
帰省しないゴールデンウィークは2年ぶりということになります。
前回はやや後悔したので「ゴールデンウィークはやはり実家帰省するのが無難」と考えていましたが、
果たして今年はどうなることやら。


完全にカレンダー通りの休みなので、今週末がメインで5連休、そして2日出勤してまた2連休という感じになります。
ただし来週の土曜日はなぜか会社のオフライン飲み会があるので実質的に平日のようなものかも……。
いずれにしろ、自分のゴールデンウィークは今週末の5日間が勝負ということになります。
タスクが入っていない休日はだいたい正午前後に起き、そこから夕食前までがメインの作業時間となります。
経験上、ここで何もできないと夕食後のフリータイムも何もできないことが多いと思っているので、
とにかくこの起床後からの時間を有効活用することを意識したいところ。


メインのタスクは期間限定ランキングの開発を進めること。
毎度説明していますが、「期間限定ランキング」とは自分が運営するサイトの大型イベントで、
いろいろあって2022年を最後に開催できていません。
当初から年1回開催を目安にしていたのもあって2023年には開催を公言していたのに結局技術トラブルで開催できず、
そのリベンジとして位置付けた2024〜2025年もなんやかんやで開催できず。
Codexを本格的に開発に導入した2026年こそは四度目の正直で開催したいと思っているところです。


基本的に開発主体はCodexです。だったらすぐにできるんじゃないかと思われるかもしれませんが、
想定しているのはかなり本格的なデスクトップwebアプリに近い構成になるため、
最初にある程度仕様を決めておかないと後に退けなくなってから破綻しかねません。
その辺もイマドキのAIくんなら抜本的な軌道修正もできるかもしれませんが、
そもそもルールやシステムを想像できていなければそれを具現化することもできないわけです。
要するに、詳細設計書をちゃんと作らないといけないということですね。
自分にとっては詳細設計書から作ってCodex主体で開発するのはこれが初めてなので、ハードルは感じています。
この最初のハードルを乗り越えるのがゴールデンウィークの最大にして唯一の目標というわけです。
おそらく、一定程度の粒度で設計書を作ってしまえばあとはCodexでどうにかなるんじゃないかなと……。
頭の中を整理して言語化する最初のステップが一番大変そう。
それを大型連休の機会に乗り越えておきたいということです。


5日間ずっとそれをやるつもりはなく、サブタスクとして創作ナレッジベース整理もやりたいと思っています。
こちらはCodex導入以降、むしろそれがボトルネックになって進んでいないという問題があり(#08161 / 2026年04月20日)、
今後のためにもボトルネック解消はやっておかねばなりません。
要は今回のGWは2つの大きなボトルネックを解消して、年間計画を次のステップに進める役割があると認識しています。
ここを逃すと3連休以上の機会は07月まで待たされるので、そういう意味では最低限の仕事はしたい。


去年はお絵描きやらなんやらクリエイティブな計画を立てて結局挫折したので、
そういう挑戦的なタスクは今年は立てずに無難に行くことにしました。
あとは気分転換にどこかへ行くかどうかですが、それは当日になってから気分に従う方針でいいかなと思っています。


#8170

動的サイト制作の機運

『ピクミン2』22周年ということで、
だからというわけではないのですがピクチャレ大会の開発作業に1日を捧げました。
その一環で移転前にしかないコンテンツを確認したいというニーズがあったため、
レガシーとなっているリポジトリを復旧する作業をしていました。


自分が制作・管理しているピクチャレ大会というサイトは2007年の今日、
特設サイトのコンテンツの一部としてスタートし、その後2015年09月01日に移転、2023年07月21日に再移転しました。
このうち2015年の移転は当時さまざまな思惑の交差するところで実行を決意したという経緯があります。


ざっくり自分のweb制作運営遍歴を振り返ると本番環境の基盤(というより制約)によって5段階に分かれています。
楽天広場や「Yahoo! Geocities」でテキストサイトを作っていた2003〜2005年。
忍者ホームページでサブドメイン運用をするようになった2006〜2009年。
独自ドメインとレンタルサーバーを運用してもろもろまとめることを目論み
「新本家サイト」という位置付けのポータルを中心に制作していた2010〜2013年。
2003年からやっていたブログをその新本家サイトと同じ格付けにして独立した2014〜2022年。
ついにVPSを契約して基盤も自由にいじれるようになった2023年〜現在。


忍者ホームページまで(〜2009年)はHTML, CSS, JavaScriptのみでバックエンドはいじれず、
2010〜2013年の新本家サイトはGMOの「XREA(エクスリア)」、
2014〜2022年の3代目本家ブログ&ピクチャレ大会ver.2はGMOペパボの「heteml(ヘテムル)」を使っていましたが、
当時、両者にそこまで大きな仕様の違いはなかった……と思います。
ただ、2010年当時の自分はそれ以前のノウハウを活かしてHTML+JS主体のサイト設計をしたこともあり、
XREAでPHPを使えることさえ知らず、JavaScriptベースの自己満足なサイトを構築していました。
当時はPerlの方が耳にする機会があったので、Perlの勉強をしていたくらいです。でも結局そのPerlも使わなかったという。
独自ドメインで運用できればそれでよし、というスタンスだったのでしょう。


新本家サイトプロジェクトも自分の中ではちゃんとした成果になったとは言い難く消化不良のまま終わってしまい、
結局ゲームファンというだけでコンテンツを生み続けるのは難しいのだと察したのか、
ブログ10周年の節目である2014年には新本家サイトを半ば放棄し、
ブログをWordPressに移管してそれに専念することになります。
そしてそのWordPressを通じてPHPを触るようになり、HTMLタグのようにスクリプトを埋め込めるその簡便さに感動。
それによって改めてPHPとデータベースを使って参加型サイトを作りたいという機運が高まってきました。
そこへ来ると当時のピクチャレ大会(ver.1)は外部サイトの応募フォームに依存してExcelで人力更新していたため、
投稿を自動化したいというニーズを考えたときに いの一番に考えつく既存のコンテンツでした。
さらに当時はTwitterでピクミン界隈とのコミュニケーションが盛り上がって所属意識が形成されつつあったこともあり、
コミュニティに貢献できるという意味でも大きな意義があることは明らかでした。
ピクチャレ大会はそうした数々の巡り合わせのおかげで制作に漕ぎ着け、独立したという経緯があります。
蛇足ですが、さらに言えば『ピクミン3』がリリースされたのが2013年だったのも絶妙なタイミングだったと思います。
2010〜2012年は黎明期スマホゲームや音ゲーに夢中だったのでピクミンはほぼ忘れ去られており、
その時点でPHPを知ったりコミュニティに所属したりしても結果的にこうはならなかったんじゃなかろうか。


そもそもピクチャレ大会の開催自体も2本のゲームとの巡り合いによるものだったことを考えると(#07494 / 2024年06月23日)、
今日で開催から19周年を迎えるこのサイトもさまざまな奇跡の積み重ねで立っていると言えるのかもしれません。
いま、改めてレガシーを復旧してみるとページの読み込みにめちゃくちゃ時間がかかるし、ページの動線はわかりにくいし、
余白をまったく考慮されていないキツキツのデザインはいかにも前時代的で、チープさを拭えません。
各ドキュメントにはメンヘラ期の遺物とも言える管理人のお気持ちが垣間見える文章もあって絶妙に黒歴史感がありますが、
一方でナビゲーションメニューなど、当時の自分が自分なりにこだわっていた痕跡もしっかり残っています。
このサイトの客観的なクオリティはどうあれ、
これに打ち込んだ日々があってこその現在があることは忘れてはならないと改めて感じます。


#8169

「感想さ」の奇妙さ

今日の出来事日本語

1週間くらい前に何気なくYouTubeのコメント欄を見ていたら、「感想さ」という奇妙な日本語を目にしました。
あいにくなんの動画か覚えていなかったのでそのコメントは見失ってしまったのですが、
試しにweb検索したら同じニュアンスの使用例を発見したので引用します(ブログ主さんすみません)。



食べたものが違うのですが、概ね同じ感想さです。

私はポテトサラダ、オニオングラタンスープ、アワビ煮込みを頂きました。
ですが、これらでドリンク込み3500円の価値は無いかなと思います。


東京美食Life, 2017/02/02 のコメント - 2023/07/16



おそらくですが、この「感想さ」とは文字通りに受け取れば感想の程度というニュアンスになりますが、
文脈的には飲食店に対する評価の程度を表現しようとしているのだと思います。
同じようなニュアンスで以下のように「感動さ」という表現も見つけました。



詳しく話してしまったら動画の感動さ(?)が欠けてしまうかもしれないのでここら辺にしておきますが、
凄く細かく作られているので考察のしがいはありそうだなと思います


さちの自己満日記, 2019/11/30



これも「感動の度合い」という意味なのでしょう。
つまり「程度」を表すために名詞に「-さ」がくっついているというわけですが、これは正しいのでしょうか。


形容詞は、それを名詞化するために「-さ」がつくことがあります(例:大きい→大きさ)。
同様に、「〜な」と表現できる形容動詞についても、「-さ」に置き換えて名詞化できます(例:公平→公平さ)。
「公平」のように(活用が隠れていて)名詞としても形容動詞としても通用する語彙については、
「〜性」とつけても違和感なく通じることが特徴として挙げられます。
ざっくり言えばこの「〜性」を「〜さ」に置き換えることができるというわけですね。


感想という語それ自体に度合いを表現するニュアンスは含まれていないので、
「感想さ」を正しい日本語と言い切るのは相当厳しいような気がしていますが、では「感動さ」についてはどうでしょうか。
感動にも程度の違いというのはあるのだから、「〜さ」でその程度を表すのは間違いとは言い切れない気がする。
「感動」は名詞なので形容動詞としての活用形は作れないし、「〜性」をつけるのも違和感があります。
何かつけたいならこの場合は「〜的」とつけるのが妥当ですが、それでは感動の度合いを説明したことにならない。


そこで引用文をもう一度読むと、そのあとに「欠けてしまうかもしれないので〜」と続いています。
結局ここで感動の度合いについてのニュアンスを説明できているので、
「感動さ」の「-さ」は不要で、「感動が欠けてしまう」で十分に伝わるというのが正解かなと。
欠けてしまう、というのは物質みたいで少し違和感があるので、より自然な文にするなら「薄れてしまう」でしょうか。
1つ目の引用も、「食べたものが違うのですが、概ね同じ評価です」で何も問題ありません。


つまり、若者言葉になりつつある(?)名詞の形容動詞化はシンプルに蛇足だという結論になりますが、
言葉のルールというのは実は単に正しい・正しくないで決まるわけではありません。
誤用が広まった結果、それが辞書に載るようになったケースはけっこうあります。
「敷居が高い」「とんでもございません」「既存(きぞん)」などなど。
もし今後「感動さ」という表現を使う人が多数派になれば、それは正しい日本語として受け入れることになるのでしょう。
「タピる」(タピオカミルクティーを飲む、を意味する動詞)が流行する若者言葉界隈なら何が起きてもおかしくない。
言葉はいきものと言われますが、本当にその通りだと思います。


#8168

AIの改修による暴走

今日の出来事web制作

出社日の退勤は、まず会社最寄駅から新宿駅まで行き、
新宿駅から自宅最寄駅までは確実に座るために次発乗車列に並ぶことも考慮して駅で待機します。
そして新宿駅で無事に座れたらあとは読書タイム。
逆に言えば、新宿駅に辿り着くまでは乗り換えの都合で読書をする余裕が無いのでスマホをいじるしかありません。
こういうとき、最近はGoogleアプリでニュースをチェックしていることが多いのですが、
自分のサイトを巡回することも結構あります。
そこで今日はサイトを巡回しようとしたらサイトがめちゃくちゃ重く502エラーを吐くこともあったため、
「またサーバーが攻撃されているかも?」と思いつつ内心不安になりながらも帰路を急ぎました。


サーバーのリソースモニタを見ると夕方からCPU使用率が不自然に上昇しており、
ターミナルでSSH接続するとターミナル自体が固まってしまうほどサーバーが激重状態になっていました。
が、結論から言うとこれはセキュリティ・インシデントやDDoS攻撃などではなく、
単にこのブログのフロントエンドが不当にリソースを食う設計になっていたせいで暴走していただけした。


基本的にこの手のトラブルが起きた場合はChatGPTに訊けばどうにでもなります。
React2Shellの件(#08035 / 2025年12月15日)や今回使った手法はどちらもtopコマンドを起点にしています。
これはWindowsでいうところのタスクマネージャーで、CPU使用率の高いプロセスが一目瞭然になるんですよね。
プロセス番号さえ分かればどこの何が暴走しているのかは仮想化環境内だろうと特定できるので、
今回はこのブログのフロントエンドコンテナの中にあるNode.jsが暴走していたとわかったわけです。
そしてなぜ暴走していたのかと言えば、
本家ブログで本文やタグを表示しようとするときに全記事(執筆時点で8,167本)を探索するAPIが走っていたと。
実際、ログをリアルタイムで流すようにして本番環境にアクセスしてみると、
面白いくらいアクセスした瞬間だけCPU負荷が爆上がりすることがわかりました。


今回、この原因を作ったのはAIの改修であり、これはこれで問題だと改めて思いました。
やはり自分の手が届かない範囲で改修を完結させてしまうとこういう予期せぬ問題が発生することがあるんだなと。
人力開発では何を書いて何が起こりうるのかを自分がそれなりに把握できていたのでこうした問題は起こりにくく、
それゆえにどうしてもテストなどの後工程は軽視されがちでした。
しかしエージェントコーディングにおいてはむしろ盤石なテストプロセスが必須なのかも。
AIを過信しないことはもちろん大事ですが、人の手が介入しないからこそ個々のプロセスについて言語化しておき、
ルールを過不足なく決めることは今後の開発において急務になるんじゃないかと思っています。