お知らせ
現在サイトのリニューアル作業中のため、全体的にページの表示が乱れています。
- 投稿日：
私が子供のころ、スーパーで売っているおはぎには、緑色のおはぎが一つ入っていた。四つ入りなら黒黒黄緑という感じのラインナップだったと思う。それぞれの色は黒はあんこ、黄色はきなこ、緑はのという具合だ。私はこののりのおはぎが何故か好きだった。なので、のりおはぎだけが入ったおはぎを食べたいと子供のころからずっと思っていた。一つだけは少ない。
最近童心を思い返してスーパーに行ってものりのおはぎそのものが売られていないことに気が付いた。三年ほど探したが、まったく見つからない。代わりにずんだ餅が入っているのはよく見た。なぜ東北の和菓子が関西のスーパーのおはぎにしれっと混入しているのか、私は頭を悩ませたが、悩んでも仕方がないので和菓子屋に行けばあるのではないか？と思いネットで情報を集めると、見事当たった。
しかし、和菓子屋を当たれど当たれど、のりのおはぎどころかおはぎ自体が売ってないのだ。そこで近所の和菓子屋に聞いてみたところおはぎは彼岸の時期しかやってないという情報を得た。
いや、それでもおはぎの専門店であれば売っているのではないか？私はそう考え、ナダシンの餅へ赴いたが、ここにはあんこのおはぎしかなさそうだった。次におはぎといえば丹波屋だろうと考え、垂水の丹波屋に足を延ばした。初日は夕方で、この時間からは作れないといわれ、翌週に行くと今は作ってないんですと言われ、他に何か宛はないものか…と探していたところ、御影の虎屋吉末が春の彼岸なのでおはぎの売り出しを始めるという告知をしているのを見かけた。
もしかしたら、この時期なら丹波屋でものりおはぎを売ってもらえるのではないか？そう考え今日、三度目になる訪問をしたところ、店頭には並んでおらず、メニューにも書いていなかったが、「おはぎあります」と書かれたイラストにはまごうことなき、のりおはぎの絵が描かれていたので、のりおはぎがないか聞いてみたところ、作ればあると言われ、無事入手することができたのだ。
そして私は今日、子供のころからの夢だった、おはぎ四つ入りがすべてのりで埋め尽くされたおはぎを入手することができたのだ。
このまりものような見た目。香ばしい青のりの香り。なんともたまらない。
食べてみると口の中で、まぶされたのりのふわふわ感が広がりなかなか新鮮だ。もう何年ぶりに食べるかもわからない味だったが、特に美味しくはなかった。一個しか入ってない縁起物感だ。青のりは高価なので売られなくなったのも納得という感じ。
ただそれでも十分にうれしかった。またこのおはぎを食べられたことが、何よりもよかった。
丹波屋ののりおはぎは、これでもかというほどふんだんに青のりがまぶされており、贅沢な一品だ。
ちなみに以前、垂水でサメを買ってきたが、この時が丹波屋に行った一回目の時だった。二回目の時は魚を買わなかったのだが、今回はまた魚を買ってきてみた。
垂水漁港昼網のコチ一尾を刺身用に下ろしてもらったものだ。1,500円もして、サメはお買い得だったなぁ…と思った。
そぎ切りにしたところ。身の締りは良くてムチムチしてて、甘みがあって美味しかった。何よりカサゴの仲間が刺身で食べられるとは思わなかったので、それが美味しいとなると二度驚いた。
- 投稿日：
UbuntuにSSDを追加した時にラックの保守性の悪さをどうにかしたいなと思ったのでどうにかした話。
作業前
ラックは二段で下段にPCとルーターなどのネットワーク機器やケーブルBOXが重ね置きされている状態だった。
この状態でPCを触ろうとすると上に載ってるものをどける必要があるのだが、ケーブルで全部繋がっている関係上一筋縄に行かない問題があった。なので今回はPCと、その上に載っているものを分かつために棚を追加することにした。ついでに前々から限界を感じていたケーブルBOXの拡張も行うことにした。
作業う前のケーブルBOXはぎゅうぎゅう詰めで何が何だか全く分からず、これ以上物を足すことも、何かを入れ替えることも困難な状態だった。
作業準備
まず必要なものを買いそろえることにした。ラックの棚板と、ラックをかさ上げするための基礎ポール、ポールと棚をつなぐためのキャップ、大きなケーブルBOX、あとは組み立て用のゴムハンマーだ。
事前にしっかり計画していたわけではなく、組み立て用のゴムハンマーは作業開始直後に存在に気付き、ケーブルBOXの入れ替えも作業中に気付いたため、これが後の作業に響くことになる。
作業中の風景：トラブルまみれの初日
PCの上に載っている危機が壊れないように慎重に下ろしてゆく。
その前に一番上のノートPCが邪魔だったので排除。
ぐちゃぐちゃになりつつも無事PCの引き出しに成功。この時ネットワーク機器とメイン・サブPCの電源が喪失し、実質全電源喪失的な感じになった。
ここで棚をばらそうとするもゴムハンマーがないことに気付き夜の道を走りドンキに急行。三宮に住む利点の一つ、突如ドンキに行きたくなった時に行けるである。
ゴムハンマーを手に入れたので解体にかかるが、あまりにも強力にはめ込まれていて、既存の上部構造がポールの途中から吹き飛ぶという珍事が起こる。
吹き飛んだ部分はハンマーで叩いた勢いで棚板も歪んでおり、ちょっと使い物にならない状態だった。
しかしラックのポール同士をつなぎ合わせるネジ部分が吹き飛ぶとは夢にも思わなかったので驚愕した。これはもう使えそうにない。
この時再調達は翌日になってしまうし、ついでにケーブルBOXも大きくするかという閃きに至り、ヨドバシで注文をかけた。
幸い既存のラック構造のうち、下部は無事だったので、そこと予め買ってあった中間用の棚板を組み合わせ形にするところで、この日は終わりにした。
棚の高さの調整にやや悩んだが、余白があってもさして恩恵がないと感じたので、最低限引き出せて掃除にも困らない程度の余白を残すことにして、右側の画像の高さとした。分かりづらいが左右の画像で棚の高さが4cmほど違う。
再度配線するのが非常に面倒だったので電源喪失状態のまま、この日を終えた。
作業中の風景：無事完成させた二日目
新しくやってきたケーブルBOXと、今まで使っていたケーブルBOXの比較。サイズは倍くらい大きくなっている。
旧ケーブルBOXと新ケーブルBOXの比較。ずいぶんすっきりしたと思う。
どれがどのケーブルなのかもわからなかったので、ついでにラベルもつけている。4年前に買った中華性のケーブルラベルが重宝する。このラベルは安いうえに、かなり大量にあり、さらに中々頑丈で剥がしやすい優れモノだ。
ラックのほうも追加の部品を買ってきたところでくみ上げて良い感じにものを収めて完成だ。以前と比べるとメンテナンス性が格段に良くなったと思う。
あとがき
元のラックは3年ほど前にリモートワーク用のPCを置く場所がないということで急遽作ったものだが、実は作った当初からこうなる懸念は持っていた。その当時はラックを高くしすぎると圧迫感が出ると考え、多少の保守性は犠牲にしてでも低く抑えようという考えが働き、棚を一個抜き、それも一番いい塩梅にできるようにダイソーで売っているパーツのパターンを調べ、一番いい高さになるように設計し、神戸中のダイソーを回って部品を調達してまで作ったものだ。
今回高くしようと決めた背景には、棚板を増やし高さを上げても圧迫感は出ないだろうということを感じていたからだ。何せラックがある位置は普段見えない場所で、周囲にも結構余白があるため、特に気にならないだろうという考えがあった。組み立ててみた感想、実際気になりそうになかったので正解だ。
何なら必要性があれば更に高くすることさえも検討しているくらい。
ところで、このラックにはダイソーのジョイントラックの棚を使っていて、これは300円で買えるのだが、別の用事でコーナンに行ったら棚板だけで2,280円と出ていて、ダイソーは安くて助かるなぁ…と思うのであった。
そりゃまぁ、ダイソーのラックのパーツはお世辞にも品質がよくなく、上手く嵌らないとか曲がってるとかバリがついてるとか色々あるし、逆にコーナンの棚はずっしりしていて如何にも頑丈そうで、ちゃんとしていそうだったので、仕方がないことではあるのだが、ここまでの差が出るのかぁ…という感じである。
そういえば使っていた電源タップがNational時代のもので時代を感じたりもした。これは専門学生の頃に買った設備で、それをずっと使い続けているのだ。だいぶ汚れていたので、この後拭いて綺麗にしておいた。因みにあの小さいケーブルBOXも確かそのくらい年季が入っていた気がする。
- 投稿日：
H200やH100は手が届く値段とは言い難いし、L40Sもなかなか厳しい…。そんな中、先日NVIDIAからDGX Sparkなる128GBものVRAMを積んだマシンが比較的安価で出るという噂を聞いたので軽く調べてみた。
想定販売価格は$2,999で、これまで出てきたワークステーション向けより安価だ。過去にあったJetsonの強化版的なものだろうか？
今持っている4070Tiと性能を比較してみたところ申し分ないグレードアップに見える。スタンドアローンマシンとのことなので、StableDiffusionを常時起動できたり何かと便利そうでもあるため、価格次第では買ってもいいかもしれない。二台繋げて動かすこともできるようだが、さすがにそこまではしない。
OSもUbuntuが動くとのことで、恐らく一般的なARM PCに仕上がってそうだ。ストレージも4TBあるそうなので、画像生成用途なら一台ですべて完結できそうである。個人的にはLLMを乗せるとどうなるのかが気になるところだが、特に調べていない。もし、CloudeレベルのLLMが動かせれば非常に魅力的だと思う。
比較
| 性能 | DGX Spark | GeForce RTX 4070 Ti |
|---|---|---|
| CUDAコア数 | ？ | 7,680 |
| Tensorコア | 第5世代 1,000 AI TOPS | 第4世代 641 AI TOPS |
| GDDR | 128GB LPDDR5x | 12GB GDDR6X |
| メモリインターフェース | 256-bit | 192-bit |
| メモリ帯域 | 34Gbps | 21Gbps |
| 電源 | 170W | 700W |
DGX Sparkのメモリ帯域は273GB/sとあったのでbit換算するために8で割っている。
メモリがLPDDRなのが気になるが、恐らくここが安価にできているポイントのような気がする。
ゲーミング向けグラボのGDDRは容量が抑えられがちなので、恐らく高いのだろう。しかしメモリ容量の割にバス幅が狭いのでここはボトルネックになりそうだ。とはいえ、StableDiffusionを使うケースでは現状より性能アップなので不満を覚えることはないと思う。
参考
- 投稿日：
注意：この記事には未成年にふさわしくない、不健全な内容が含まれます。
LLM、つまりLarge Language Modelとの個人的な付き合い方について書いてみる。
LLMとの出会いと馴れ初めとERPと
AIのべりすととの出会い
私とLLMとの出会いはAIのべりすととの出会いまで遡る。当時これで何をしていたかというと、いわゆるERP(Erotic Role Playing)だ。古めかしい言い方をすると「なりチャ」
しかし当時ののべりすとのERPはあまり面白くなかった。そこから暫く経ち、2022年11月ごろだったろうか、OpenAIがChatGPTをローンチしたという情報が入った。
OpenAI、ChatGPTへ
初期のころはChatGPTへの事前ユーザー登録をしつつ、未登録で利用して遊んでいた。2023年3月になると有料ユーザーになり、よりハードに使い始めた。
ChatGPT 3は非常につまらないもので、正直私の期待は満たされていなかったが、3.5でより面白いものとなった。しかし徐々に検閲が強くなり、私は検閲の回避方法を調べ始めた。
初期のころは虹裏にあったJailbreakマニュアルのスプシや、RedditやDiscordチャンネルのJailbreak情報を見ていたが、どれも更新されなくなったり、消えたりしたため、新しいのを探すの面倒で、そのうち見なくなった。ただ今でもこの手の行いをするときの基盤はこの時に得た知見が基になっている。
ChatGPT 4辺りから検閲が更に強化され、この頃になるとどうすれば検閲を破れるかを試行錯誤していた。基本的には通常操作をしていた時に出てきた例外的なパターンを検出したら、そこをひたすら攻めるというものだ。
やり取りの長期化によるシステムプロンプトの喪失、再生成連打によるブレによる検閲方面への文脈の破壊、投稿→検閲→投稿削除→再投稿で検閲を突破、投稿→検閲→そのまま再投稿で検閲前の文脈に回帰させるなど、様々な手法を編み出したが、試行錯誤に対するクレジット消費がえげつなく、金銭的負担となっていた。
LLM探しの旅
この頃になるとBing CopilotやGemini、Notion AIなどありとあらゆる可能性を試すようになっていた。Bing Copilotはごく初期のわずかな間は近いことができたがすぐに封じられた。Geminiは元から無理で、Notion AIはある程度使えていたが使いづらかった。
因みにBing Copilotでは意図的に不埒な検索結果が出るように誘導させ、不埒な発言をさせるという遊びをしていた。これは割と楽しかった。初期のころから検閲自体はあったものの、Reasoning的な挙動をしていたため、検閲判定が入る前に生成を止めることで遊ぶことができた。
しかし本来のERPがしたいので何かないかというのを探していたところ、ナレッジサービスであるQuoraが運営するPoeが出てきて、RedditではERPはPoeで持ちきりだったため、こちらに移住することにした。
Poeとの邂逅
当初のPoeは様々なLLMモデルが使えるサービスで、ChatGPTはもちろん、当時徐々に存在を大きくしていたClaudeも使うことができた。私が目をつけていたのはRedditで話題になっていたClaude 3 Sonnetの存在だ。
Claude 3 Sonnetはこれまでに使ってきたLLMとは一線を画す性能だった。まるで人間とやり取りしているような自然な応答、マンネリ化やループの少ないやり取りは魅力的で、何よりシチュエーションを指定せずともある程度判断して自らストーリーの筋道を立ててくれるのは魅力的だった。またClaude 3 Opusはより魅力的で、極めて高度なやり取りが可能だった。正直ERPにおいては今でも神だと思ってる。しかしClaude 3 Opusはクレジット消費がすさまじく、月間のレートリミットにすぐ引っかかった。
この時のPoeは月のリミットを超えるとそれ以上何もできなかったため、私はGoogleアカウントを量産し、最盛期では10個くらいのPoeアカウントを保有していた。月刊課金額もなかなかひどい状態だった。
そのうちClaude 3.5 Sonnetがリリースされ、Claude 3 Sonnetを遥かに超える性能で、3 Opusを使う頻度を大幅に下げることができた。また、Poeの月間リミットも課金額に応じた引き上げが可能となった。これによって大多数のPoeアカウントを閉鎖することができた。
その後も今日に至るまでERP目的で利用しているが、最近出てきたClaude 3.7 Sonnetは非常に強力で、贅沢を言わなければ多くのケースで3 Opusを置換可能な性能となり、大幅な節約を実現できると感じている。
それでもClaude 3 Opusには強い創造性があり、他のLLMにはない突拍子もない提案をしてくれるという意味では非常に優れていると思う。Poeであればスレッド内で適宜モデルを切り替えられるのでマンネリ化してきたときに使ってみるのも悪くないかもしれない。ちなみにOpusはSonnetと比較して検閲が強いので、制御にはコツが必要だ。
Claude系も初期のころはJailbreak用のプロンプトを頻用していたが、最近では自然なプロンプトでERPに誘導する方法を編み出したので、ある意味でJailbreakしていない。
あとこれはOpenRouterを使うと解るのだがClaudeには検閲モデル（ハードウェアモデレーション）と非検閲モデル（ソフトウェアモデレーション）があるようで、前者ではERPが厳しく、後者では普通にできるので恐らくPoeは非検閲モデルを使っているのだと思う。
Grokの登場
XがGrokを作ったとき、これも使ってみた。ERPができないわけではないが、特段満足できる代物ではなかった。ERP以外に何か使えないかも多少探ってみたが、結局よくわからなかった。多分ネタ枠だと思う。
今でもこいつが何に使えるのかはよくわかっていないし、Xのアカウントを消したのもあり、使うことはもうないだろう。Poeにもあるけど使うことはない。
ERP用途でのLLMの活用
個人的な評価表を置いておく。すべてPoeで利用する場合の話。
| モデル | 創造性 | ストーリー性 | コストの低さ |
|---|---|---|---|
| Claude 3 Sonnet | ★☆☆ | ★☆☆ | ★★★ |
| Claude 3.5 Sonnet | ★★☆ | ★☆☆ | ★★☆ |
| Claude 3.7 Sonnet | ★★☆ | ★★☆ | ★☆☆ |
| Claude 3 Opus | ★★★ | ★★★ | ☆☆☆ |
各項目の説明
| 機能 | 意味合い |
|---|---|
| 創造性 | 与えられた要素以外の事柄をどれだけ作れるか |
| ストーリー性 | ストーリー進行が正常に進む度合。3.5以前は話がループしたり、直前のやり取りと整合しない進行が起きることが多い。3 Opusではまずおきない |
| コストの低さ | Poeは月間の使用回数にリミットがあるため、低ければ低いほどいい |
一般用途でのLLMの活用
さてERPのためにLLMを様々な角度からしばき回していると、通常用途でも活路が見えてくる。いや普通はこっちが本命だと思うのだが、まぁそれはさておき…。
個人的にどのような分野で利用しているかというと主に文章の整理や、だる絡みだ。
文章の整理
文章の整理だと例えば殴り書きした要領も取り留めもなんもない解読不能な長文をLLMに読ませ、どのような指向性でまとめてほしいかを指示するといい感じにまとめてくれたりする。他にもプロジェクト経歴書を丸ごと食べさせて、職務経歴のサマリを書かせたりするのにも便利だ。
このブログの執筆でも最近は構成を作って貰うのによく利用している。例えば以下の記事はLLMにある程度構成を出してもらって、それをベースに書いている。LLMに書かせると自分の言葉ではなくなってしまうため、文章としては基本的に取り込んでいない。単語や表現は取り込むこともある。
| 記事 | LLMのログ |
|---|---|
| ペルソナウェアから、伺か、そしてうかどんへ | GPT-4oのログ |
| メイクアガールを観てきた 五回目 | Claude 3.7 Sonnet Reasoningのログ |
逆にLLMにほとんど書いてもらったものを手直しして出した記事もあり、単体テストを書くメリットがそれにあたる。LLMの出力の多くを、そのまま採用しているため、見出しの多さやつけ方や文章の書き口がどことなくLLMっぽい。この記事は何度かLLMと対話し、調整しながら作ったので複数のログがある。
だる絡み
Copilotとかにどうでもいい話を振るといい感じに答えてくれるのでガス抜きとかにちょうどいい。
あとがき
本記事はフルスクラッチの手書きで、LLMを使っていないが、使うとどうなるかをGPT4oで試してみたので、以下にログとして残しておく。何とも丁寧で長く、見出しまみれだ。文脈が削られすぎているのもあり、適合させるのも調整させるのも面倒で特に採用しなかった。ブログなんて気軽に書くものなので、普段は雑なくらいがちょうどいい。
結論としては私はLLMをERPや文章整理、あとはだる絡みに使っている。検索とかそういうのは自分でやるし、見当違いの情報が出てくることも多々あるので特に活用していない。コーディング用途も、LLMに書かせると何を書いたかが記憶に残らない気がしていて今のところ採用していない。そもそも、そこが一番楽しいとこじゃんっていう。
最近はもっぱらERPはPoeのClaude 3.7 Sonnet、文章整理はPoeのGPT4o、だる絡みはCopilotという使い分けになってきている。
なんだかんだOpenAIとPoe合算で累計20万は課金している気がするので同等のローカルLLMが出てきたら乗り換えたいところである。なんでも近々出るNVIDIA DGX Sparkは128GBのVRAMを搭載したGPU PCで2,999USDでローンチされるというので少し興味がある。
- 投稿日：
Webツール置き場に阪神バス神戸西宮線の接近情報のリンク集を作った。
阪神バスに乗るときに時刻表代わりに接近情報を見ることが多いのだが、この接近情報は開くのに非常に手間がかかる難点があり、パッと開ける仕組みが欲しかった。
ブックマークできることからURLが存在することは知っていたので全部網羅したリンク集を作っておけば困ることが減るのでは？と思い、作ることにした。
URLフォーマットの解析
しかしURLのフォーマットが難儀でやや苦労した。フォーマットは以下のような感じだ。可読性のためURL Encodeは外してあるが、実際にはURL Encodeされている。
https://rosen.hanshin-bus.co.jp/busstatedtl?mode=4&fr=＜バス停名＞&frsk=B&tosk=&dt=＜yyyymmdd0000＞&dgm=＜バス停名＞:&dgmpl=＜バス停名＞:＜上下コード＞:1&p=0,8,9&IncludeHankyu=0&pole_station_code=＜バス停コード＞
各パラメーターの役割について、値とパラメーター名から幾らか推定はできたが、幾らか消したり足したりしながら試行錯誤していても、正直よくわからない部分が多かった。
例えばfrとdgmはなくても動くっぽいので最悪削ってもいいのだが、dgmplが曲者で、ここに正規のバス停名が入ってないとサーバーから応答が来なくなる。またfrとdgmをhogeにして、dmgpl=hoge:2:1みたいにするとバス停検索画面に遷移し機能しなくなった。また、dtは数年前の日付をしても動くので恐らく機能には深く関わってなさそうだった。
恐らくこういった挙動からして、裏側でバス停名による検索を走らせてるのではないか？と考えたり、まぁ色々ありそうな気もしたのだが、面倒なのでパラメーターは全部残すことにした。
バス停の特定なんか、pole_station_code=＜バス停コード＞で全部やればいいじゃんとも思うのだが、恐らく歴史的経緯で複数のサブシステムが関連しており、上手く整合が取れていないのだろう。
正規バス停名の取得
しかし、こうなると正規のバス停名を取得するのが手間だった。何せ文字列で一気に取れる一覧がないのだ。悩みつつ何かないか探しているとバス停コードからバス停名を取得できる便利なAPIを見つけたので、これを使うことにした。
次のようなスクリプトを書くとバス停名が取れたため、適当にバス停コードに1～500辺りを設定し流してみると上手いこと行った。
curl 'https://rosen.hanshin-bus.co.jp/listrosenzucode' -H 'user-agent: hoge-bot' --data-raw 'qry=＜バス停コード＞' | perl -ne '/"name": "(.+?)"/; print "$1"'
HTMLの生成とリンク集の作成
ここまでくれば後は簡単だ。この結果からリンク集を作るためのHTMLを生成すればいい。そして出来たのが記事先頭で紹介した阪神バス神戸西宮線の接近情報のリンク集だ。これでどのバス停にいるときでも瞬時に接近情報を開くことができるようになった。
ろくにCSSを書いていないので見た目が簡素だが、気が向いたら調整しようとは思う。
あとがき
バス停コードからバス停名を取得するためのhttps://rosen.hanshin-bus.co.jp/listrosenzucodeというAPIを見たとき、これを呼んでいるのがJavaScriptだったので、JSにハードコードしておくか、マッピングを書いたJSONなりXMLを転がしておけば一々APIを作らずともよく、サーバーのCPU時間や帯域も使わずに済むので良くないか？とか思ったが、きっと色々あるのだろうと思い、深く気にしないことにした。