2026/05/26(火)個人サイトを巡るのに役立ちそうなサイト

更新日:
投稿日:

個人サイトを巡るのに何かしら使えそうなフィードキュレーションサイトやディレクトリ型検索エンジン、リンク集などで思いついたものを適当にパラパラ置いてみる。

ブログ系

  • ミンゲイインターネット
    • 民藝的な志を持ったブログをキュレーションしているところ
    • フィードは運営者の気分で手動更新されているらしい
    • この手のキュレーションサイトとしてはもっとも最初に出会ったところ
    • うちも登録している
  • Enjoy feeds! - rururu
    • ソーシャルフィードリーダーという新概念
    • rururuという語感が楽しくていい
    • 様々な個人ブログやポッドキャストのフィードが配信されている
    • うちも登録されている
  • 読・視・聴
    • 個人運用されているセルフホストのソーシャルブックマーク的なものっぽいが、事実上フィードキュレーターとして機能している
    • うちのブログも地味にここからの流入があったりする
    • ここからうちへ複数ホストの流入を観測しているので、恐らくいろんな人が使ってる
  • こぶりー
    • 出来立てほやほやの個人ブログ向けフィードキュレーター
    • 読みたいブログを購読登録すると、自分だけのタイムラインが作れるほか、カレンダーから日付指定することで特定日のフィードをキュレーションした結果を見れるようだ
    • うちも登録されている
  • adiary利用者のページ
    • 本サイトで利用しているCMS、adiaryの利用者のフィード
    • 時代に取り残されたようなインターネットの辺境にあるようなブログが沢山並んでいる
    • 設定で掲載を切り替えられるため、adiary利用者の全員が載っているわけではない
    • うちは登録する設定にしている
  • にほんブログ村
    • ここが好きな人がどれほどいるか謎だが、一応ブログキュレーションサイトの元祖みたいなところだと思うので載せておく
    • 実はうちも登録している

個人サイト全般

  • 佐倉葉ウェブ文化研究室
    • インターネット黎明期を研究しているサイト
    • 個人サイトへのリンクがいくつかあり、特にneocitiesの入り口としてかなり便利
    • うちも貼られている
  • Web 1.0 同盟
    • 古のインターネットに思いを馳せているHP運営者の所有サイトへのリンク集。もといWebリング
    • うちも登録している
  • 駄文同盟.com
    • きわめて長期にわたり運営、もとい放置されている個人サイト向けディレクトリ型検索エンジン
    • 膨大な個人サイトが登録されており、HTTPS化されていないのにもかかわらず、今でも新規登録や更新が見られる
    • 単純計算で2万以上のサイトが登録されている(いた)
    • うちも登録しており、過去に記事も書いたことがある
  • コンパスリンク
    • たぶん令和の駄文同盟.com的なところ。登録数は2000件は少なくともありそう
    • 登録は同人関連サイト限定なので、うちのようなけったいなサイトは登録できない
  • ハコサチ
    • 個人サイト或いは、個人サイト制作支援サイトのディレクトリ型検索エンジン
    • 真・令和の駄文同盟という感じがするが、登録数は極めて少なく、恐らく100件もない
  • 創作ブログサーチ
    • 日記やブログを持った記事ベースサイトのディレクトリ型検索エンジンっぽい?
    • ハコサチよりは登録件数がありそう
    • たぶん女性向けサイトが多い
    • 他のディレクトリ型検索エンジンへのリンクもちょっぴりある
  • (GC)GAMEHA.COM - ガメハコム
    • かつて駄文同盟と双璧をなした個人サイト向けディレクトリ型検索エンジン、旧ゲーム派ドットコム。ゲーム派ドットコムからガメハコムという名前にしたのはネタにやりすぎやと思います
    • 2026/06/01で26周年目を迎えるらしい
    • こんな広告地獄で誰が使うのか…と思うが、今でも保守が続いているのは素直にすごいと思う
    • 私は太古の昔ここから出禁を食らっていたことがある
  • サイトランク
    • 凄く胡散臭いディレクトリ型検索エンジン
    • 個人サイトはほとんどなく、どちらかといえばスパムリンクに近いが、個人サイトもある。ペルソナウェアのサイトが登録されてるようなところなので掘り出し物があるかも?
    • 実はうちも登録しているが、今年の2月に登録したものの、今のところ流入は全くない。まぁ使わないよねぇ…w ぶっちゃけサイトランクを上げる装置(そんな概念もうないだろw
    • アメリカのSiteRank Inc.が運営しているらしく、2002年からあるらしい。凄い
  • 萌駅
    • かつて萌えの個人サイトを登録することに特化したディレクトリ型検索エンジンだったところ
      • ぶっちゃけおかず検索エンジン
    • 最近はpixivやTwitterへのリンクもある
    • 個人サイトのリンクもあるが、管理放棄されてたり、デッドリンクになっているものも見られる

伺か関連

  • うかフィード
    • 伺か関係のサイトの更新フィード
    • たぶんRSSを拾ってるのではなく、各サイトの管理人が更新登録したのを流してる
  • GHOST/BALLOON TOWN
    • 伺かのゴースト、バルーンのリンク集
    • ゴーストやバルーンを探すのにも、その著者のサイトを探すのにも
  • 独立伺か研究施設 ばぐとら研究所
    • 令和8年最新版の伺か総本山
    • 前述の2サイトはもちろんいろんなところに行ける

2026/05/23(土)昨日発見したホームページやWebサイト

更新日:
投稿日:

今年は新しいホームページやWebサイトによく出会う。ここ数年SNSにどっぷりだったのもあり、これは非常に新鮮な体験だ。

そんなわけで今回は昨日発見したそれらを紹介してゆく。本当なら今日と言いたかったのだが、なんと、書いていたら日付が変わってしまっていたのである。仕方ないね。

切れ味のある詩的でジト目な民藝的ホームページ、コーポ雪原

コーポ雪原

まずコーポという名前がいい。最近のアパートというかマンションはセレニテだとか、プロヴィスタだとか、すっかりオシャレになってしまった。コーポとかハイツとか、そういう名前を聞くと一抹の懐かしさを覚える。

こちらは雪原六花さんの運営されているホームページで、まず目に入る淡雪色の落ち着いたトーンと、PC/SPで左右判定するレイアウト、SPビューの時のメニューのCSSアニメーションとかが凄くよくて、こう、いいというのが、初見の感想だった。トップページのロゴや雪の結晶、月とか、全てのページに降ってる淡雪もいいし、トップページをスクロールするとナビバーがじわっと出てくるのも作りが細かくていい。どこか退廃的な雰囲気もいい。

全体的に記事執筆や詩、小説、レビューなど、文章がメインのHPに見えるが、イラストもあり、個人的に好きな絵柄だ。上まつげが太いの好き。

雪原六花さんのアイコンも、上まつげが太いジト目でボブカットで髪の内側が外側と別カラーになっていて、個人的に好きだ。雪原六花という名前そのものも風流で素敵だと思うし、へんないきものという紹介も柔らかくて好きだ。

実は私のアイコンも上まつ毛が太くジト目だったりするが、まぁ要するにジト目が好きなのだ、私は。

HP全体のデザインやレイアウトも落ち着いていて、適度な余白があり、シンプルで、とてもいい。私の雑然として何を書いているのか、何を伝えたいのかちっともわからないプロフィールとは正反対の、簡潔なプロフィールもいい。詩人という感じだ。

執筆されている記事の文体も好きだ。特に『超かぐや姫!』感想と読解にある、この一文がとてもいい。「ダメなやつとは縁を切れ! イエや愛着なんぞクソ喰らえ!」という啖呵の切れ味が良すぎて、読んだ瞬間に膝を打つような、とても清々しい気持ちになった。

ひとつだけ文句をつけるなら、母親とは和解してほしくなかった! 3年間、仕送りもなしで放置するような養育者としてダメなやつとは縁を切れ! イエや愛着なんぞクソ喰らえ!

それと記事ページ下部を見るとURLをコピーするボタンやXやブルスカへのポストボタン、リアクションボタンがあり非常に充実しているし、コピーボタンはうちのブログにもほしいなと思った。ただadiaryを改造するのは中々骨が折れる作業なので、やるとしたら自作CMSを作ったときに盛り込みたい。

また別のペンネームで雪原文庫というサイトもされているようで、こちらは軽小説が主体の様だ。R-18もあるようだが、内容は落ち着いた感じで、比較的万人向けかもしれない。

「言葉を釣る」というコンテンツもあり、様々な言葉と、その意味を示してくれて、これもまたいい。しかも釣りなのでリリースもできる。ここは文筆家ならではの蘊蓄を感じられる素敵なページだ。

何よりすごいのは、文筆とイラスト描きをしつつ、このHPをAstroで作っているということだ。

こちらのHPを発見した経緯だが、久々にBing Webmaster Toolsを開いてバックリンクを眺めていた時に見つけたのだ。最近私はGoogleに嫌気が差しているところがあり、Android Edgeの検索エンジンをBingに倒していたので、そのついでに覗きに行ったのだ。そしてそこで上から順番に辿っていっている中でコーポ雪原と出会ったのだ。

被リンクは月報 - コーポ雪原#創作デー(2026.04.29)にあり、まさかの萌研ヤチヨの部屋 - Yachiyo's Roomと、そして私のこのブログが紹介されていて驚いた。

ブログを書いていてこういう反応が見られるのは非常に楽しいので、書いていてよかったと強く思った。

個人ブログを、見つけて、読んで、シェアしよう。個人ブログライブラリ、略して「こぶりー」

こぶりー

こちらは個人ブログのRSSリーダーサービスを提供しているWebサイトだ。

以前見かけたrururuとは異なり、アカウント登録不要で利用できるが、ミンゲイインターネットの様にOPMLがあったりはしないようで、どうも見た感じだとPWAとして利用する想定のようだった。

ページトップはカレンダースタイルになっており、日ごとの記事にアクセスできるほか、購読履歴機能や、特定ブログの購読を行うことで「購読ブログ」フィルターから、興味のあるブログだけを見れるのは面白いと思った。

興味本位で自分のブログの購読を試してみたが、残念ながら私のPC EdgeのPWA環境ではAPIがエラーを返してきて購読することができなかった。

一応簡単に通信時の情報も貼っておく。

しかし、rururuミンゲイインターネットもそうなのだが、こんなネットの最果てにありそうなブログを一体どうやって見つけてくるのだろうか?[1]

しかもこのブログは建前上、うちのサイトの本体ではない。何故ならルートドメインはlycolia.infoで、まずこんなところ各種SNSのBioからでないと辿り着かない。そう考えると一体どうやってみんな本体サイトを見つけてこんなブログに…と思う訳だ。

いや、検索流入では圧倒的にブログに直に来る人のほうが多いので、そう考えれば不思議はないものの。そもそもこのブログのアクセス数自体が知れているところもあり…みたいなアレなので、どのようにして見つけられているのかは地味に興味深い。

なおこちらからはアクセス解析のMatomo経由でこぶりーを発見している。

あとがき

なんか今年は妙にこういうのが多い気がしたので、今年発掘したホームページ記事を見直してみたら、ほぼ毎月何かを掘り当てていることが分かったので、以下に今年書いたものを並べておく。

個人サイトの展示会である個人サイトWebオンリー めぐる市もあるし、ひょっとしたらそういう風が吹いているのかもしれない。

というのを書いていたら、本日からサークル入場が始まっていたので、中に入って配置をしていたら、カスタマイズなどをし始めてしまい、この記事を出すのが二時間ほど余計に遅れたという話もある。

そういえばコーポ雪原はミンゲイインターネットに絶対登録されているはずだから調べてみたら、見事に登録されていたので、やはりミンゲイインターネットの網羅力はすごいなぁと思うのであった。


  1. ミンゲイインターネットへの登録そのものは自推だが、管理人の15氏から私のサイトは前から知っていて、登録するか検討していたと聞いているため、つまり知られていた訳である。因みに15氏は伺か・伺的 Advent Calendar 2024で、このブログを知ったのだとか。

2026/05/22(金)クレカの支払いが滞ったので時系列を書き出す

更新日:
投稿日:

2月あたりから資金ショートの気配を感じていて、クレカの支払い整理をしていたのだが、最終的にショートしてしまったので経緯や起きたことを時系列で書いていく。なおまだ終わっておらず現在進行形の出来事である。

経緯

何故資金ショートに至ったかだが、去年の秋ごろから割と必然みたいなところはあった。

まず去年、佐賀に3度も旅行に行ったので貯金が底を尽きていた。正直三度目は行くかどうか迷ったが行ってしまった。これは後に欠勤を前提とした転職活動が控えていたことや、転職活動で事故ると無給期間が発生することを経験的に知っていたからだ。

そして転職活動に入り、有給を切らしており、欠勤を前提に活動していたため単純に給料が落ちていた。ただここまではまだギリギリなんとかなっていた。

しかし今年の1月から3月にかけモニタや椅子が壊れ、大きな出費が出た。3月も欠勤が増える見込みで、このことで2月には支払いをリボに切り替え様子を見た方がいいのではないかと考えていた。幸い羽振りのいい会社だったので実態がなくとも7割くらいは勤怠をつけることが許されており、給料が0円になることは回避された。このお陰で計算上ギリギリなんとかなると思い込み、6月まで予定していたリボを解除した。これが諸悪の根源で、この後死ぬことになる。

3月後半で転職先への出張が何度も発生することがわかり、30万近い出張費が突如発生した。これは3月の利用枠内なので4月に飛んでくる請求になるものだった。しかしこの時の私は脳が空っぽになっており、翌月の支払いについて何も考えられていなかった。

常識的に考えれば、生活費もある中で貯金残高が底をついた状態で7割の給与で追加の30万を支払えるはずがない。そして4月の引き落としが無事失敗した。私は三井住友VISAカードを使っているため、引き落とし日以降の金額調整が効かない問題があり、頭を悩ませた。

ひとまず速攻で5月以降の支払いを全てリボに変え、引き落とし額を抑えた。この操作は数日後には不可能になっていたため、このタイミングでできていてよかったと思う。どうも支払い確認ができない判定になると操作できなくなるようだった。

時系列

なぜかカード停止までは猶予がかなりあった。またクレカの停止と切り替え中でも使えるPiTaPaは普通に使えている。

日付 出来事 備考
4月27日 三井住友VISAカードの引き落としが失敗する
4月28日 4月利用分以降の未払いを全て「あとからリボ」に変更
5月1日 カード会社に支払いについて相談したいとWebフォームから連絡 返事は来なかった(恐らく支払いではフォームから送信できなかったので無理やり別の項目を選んで送信したせい)
5月10日 カード会社から支払い催促の手紙が来る
5月11日 リボ関連の設定画面に入れなくなっていることを確認
5月11日 カード会社の有人チャットで支払いについて相談したいと投げる ここでは相談不能と返されるが電話窓口の情報を得た
5月13日 カード会社に支払いの相談の電話をする いつ何を支払うかを伝え、振込口座情報を得た
5月13日 カード会社から支払い催促のメールが来る
5月13日 カード会社から支払い催促のSMSが来る
5月19日 1時 最後にクレジットカードが使えた時刻
5月19日 18時 クレジットカードが停止され、使えなくなる
5月25日 10時 3月利用分を口座振り込み
5月25日 15時 クレカの利用が再開されていることを確認

あとがき

今月末には新しい会社から給与と出張交通費の規定分が振り込まれるはずなので一応何とかなるはずだが、過去最大級の資金ショートを起こしている。

ちなみに過去には貯金残高も現金も底をついており、カードの利用枠が上限を突破した状態もあった。私はリボの達人なので、大体こういう時はリボに逃がしているのだが、今回はちょっと平和ボケをしすぎていた。

私は過去にリボを使ってかなりの危機を乗り越えてきているが、リボの上手な運用方法はネタとして面白い気がしているので、気が向いたら書くかもしれない。

2026-05-28追記

お支払い状況照会
現在、お支払いの確認が取れていないカードはございません。なお、システムの都合上、反映に2~6営業日かかる場合がございます。

vpassには上記のように出ていたが、即日反映されていた。人間が処理している気がするが、もしかしたら仮想口座などで自動処理されていた可能性もあり、面白いなと思った。

2026/05/21(木)GrafanaでLokiのログからログメッセージを部分一致で検索する

投稿日:

Grafana Logs Drilldownではフィルタ出来るのにExplore > Lokiでクエリを打ってもログを引けなかった。これを引けるようにするのが目的。

確認環境

nginxのログをFluentBitで拾いLokiに送る構成。

Env Ver
Ubuntu 24.04.3 LTS
Loki 3.5.9
FluentBit 4.2.2
nginx 1.26.1
Grafana v12.1.1

やり方

server: mstdn.lycolia.info[error]を含むものを検索する場合、こうしておくと引ける。要点はjson msg="log"で別名をつけること。logのままでは構文エラーになる。

{job="nginx"} |= `error` |= `server: mstdn.lycolia.info` | json msg="log" | msg=~`.*\[error\].*`

|= errorについてはQuery best practices | Grafana Loki documentationで、最初にラインフィルタをかけるとパフォーマンスが上がるということで付けている。

server="mstdn.lycolia.info"を指定するとなぜかうまくいかなかった。

2026/05/19(火)ローカルでQwen3.6-35B-A3Bをベンチしてみた

更新日:
投稿日:

前回のマシンを更新したのでローカルLLMを軽くベンチマークしてみたでは生成速度だけを見れば十分実用ラインということを確認したが、品質が悪い問題があった。

そこで4月に出て、そこそこ評判を聞くQwen3.6がいかほどのものかというのを軽く試し、ついでにベンチマークもした。

CPU推論とGPU推論が分かれているが、これは初回ベンチマーク時にCUDAのDLLを入れ忘れていたため、GPU推論はDLLを入れてリトライした時の数値、CPU推論はDLLがない状態の数値で書いている。

確認環境

ハードウェア

種別 デバイス
CPU Intel Core Ultra 7 265F
GPU GeForce RTX 5070 Ti
MEM Crucial CT2K16G56C46U5(DDR5-5600 16GB) * 4
M/B ASRock Z890 Pro RS

ソフトウェア

実行環境はWindows 11。今回はllama.cppをメインで使っている。

Env Ver
llama.cpp 9196
Ollama 0.24.0
Open WebUI 0.9.5

ベンチ結果

[llama.cpp] Qwen3.6-35B-A3B-UD-Q4_K_M

Qwen3.6-35B-A3B-UD-Q4_K_Mを使用。

入出力例

CPU推論時に出した内容。スクショが面倒なのでGPU推論時のはなし

CPU推論

生成速度

指標
cache_n 0
prompt_n 14
prompt_ms 203.404
prompt_per_token_ms 14.528857142857143
prompt_per_second 68.82853827849993
predicted_n 1553
predicted_ms 94147.172
predicted_per_token_ms 60.622776561493886
predicted_per_second 16.495450335990974
input_tokens 14
output_tokens 1553
total_tokens 1567

リソース消費

GPU推論

生成速度

指標
cache_n 0
prompt_n 14
prompt_ms 103.612
prompt_per_token_ms 7.400857142857142
prompt_per_second 135.11948422962593
predicted_n 1554
predicted_ms 26037.862
predicted_per_token_ms 16.755380952380953
predicted_per_second 59.68231953913881
input_tokens 14
output_tokens 1554
total_tokens 1568

リソース消費

[llama.cpp] Qwen3.6-35B-A3B-UD-Q5_K_M

Qwen3.6-35B-A3B-UD-Q5_K_Mを使用。

入出力例

CPU推論時に出した内容。スクショが面倒なのでGPU推論時のはなし

CPU推論

生成速度

指標
cache_n 0
prompt_n 14
prompt_ms 228.782
prompt_per_token_ms 16.34157142857143
prompt_per_second 61.19362537262546
predicted_n 1816
predicted_ms 119116.155
predicted_per_token_ms 65.59259636563877
predicted_per_second 15.24562306431063
input_tokens 14
output_tokens 1816
total_tokens 1830

リソース消費

GPU推論

生成速度

指標
cache_n 0
prompt_n 14
prompt_ms 156.28
prompt_per_token_ms 11.162857142857144
prompt_per_second 89.58280010238033
predicted_n 1575
predicted_ms 30901.59
predicted_per_token_ms 19.620057142857142
predicted_per_second 50.96825114824189
input_tokens 14
output_tokens 1575
total_tokens 1589

リソース消費

[llama.cpp] Qwen3.6-35B-A3B-UD-Q8_K_XL

Qwen3.6-35B-A3B-UD-Q8_K_XLを使用。

入出力例

CPU推論時に出した内容。スクショが面倒なのでGPU推論時のはなし

CPU推論

生成速度

指標
cache_n 0
prompt_n 14
prompt_ms 262.85
prompt_per_token_ms 18.775000000000002
prompt_per_second 53.262316910785614
predicted_n 1704
predicted_ms 119261.701
predicted_per_token_ms 69.98926115023474
predicted_per_second 14.287906223977135
input_tokens 14
output_tokens 1704
total_tokens 1718

リソース消費

GPU推論

生成速度

指標
cache_n 0
prompt_n 14
prompt_ms 190.329
prompt_per_token_ms 13.594928571428571
prompt_per_second 73.55684104892055
predicted_n 1829
predicted_ms 51098.747
predicted_per_token_ms 27.93807927829415
predicted_per_second 35.7934412755757
input_tokens 14
output_tokens 1829
total_tokens 1843

リソース消費

[Ollama] qwen3.6:35b

qwen3.6:35bを使用

入出力例

CPU推論時に出した内容。スクショが面倒なのでGPU推論時のはなし

CPU推論

生成速度

指標
input_tokens 14
output_tokens 1364
total_tokens 1378
prompt_tokens 14
completion_tokens 1364
response_token/s 20.84
prompt_token/s 5.84
total_duration 126876747900
load_duration 58586625500
prompt_eval_count 14
prompt_eval_duration 2398703000
eval_count 1364
eval_duration 65458229300
approximate_total "0h2m6s"

リソース消費

llama.cpp実行コマンド

実行コマンド

このコマンドはRTX 5070 Ti + 9800X3D running Qwen3.6-35B-A3B at 79 t/s with 128K context, the --n-cpu-moe flag is the most important part. |r/LocalLLaMAにあったものを利用している。

llama-server.exe ^
  -m "ここにモデルファイルのパス" ^
  --fit on ^
  --fit-ctx 128000 ^
  --fit-target 256 ^
  -np 1 ^
  -fa on ^
  --no-mmap ^
  --mlock ^
  -b 2048 ^
  -ub 2048 ^
  -ctk q8_0 ^
  -ctv q8_0 ^
  --temp 0.6 ^
  --top-p 0.95 ^
  --top-k 20 ^
  --min-p 0.0 ^
  --presence-penalty 0.0 ^
  --repeat-penalty 1.0 ^
  --reasoning-budget -1 ^
  --chat-template-kwargs "{\"preserve_thinking\": true}" ^
  --host 0.0.0.0 ^
  --port 8033

まとめ

CPU

指標 Q4_K_M Q5_K_M Q8_K_XL
入力tok/s 68.82 61.19 53.26
出力tok/s 16.49 15.24 14.28

GPU

指標 Q4_K_M Q5_K_M Q8_K_XL
入力tok/s 135.11 89.58 73.55
出力tok/s 59.68 50.96 35.79

Ollama

指標 Ollama
入力tok/s 5.84
出力tok/s 20.84

上の表の指標については明確な根拠を見つけることができなかったため、指標の名前から推測して、おそらくこの指標はこれだろうというので割り当てて書いている。

何故というとAPIレスポンスの仕様書が何処にあるかわからず、Claude Opus 4.7に聞いてもデッドリンクになった仕様書を提示され、後はソースコードを読めと言われたため、わからないのだ。ソースコードなんか一々読んでられない。しかも嘘を教えられたため、自力で解釈した。

さて、処理時間についてだが、これはOllamaよりllama.cppのほうが圧倒的に早いことが判明した。また、ついでに言うとOllamaはどのモデルを実行してるのかが不明なため、単純比較ができない。

またリソース消費を見る感じ、OllamaはCPU・GPU共に遊ばせていたので、これが処理が遅い原因になっていた可能性がある。llama.cppはマニュアルでそのあたりをうまくやっているので早かったのだろう。

生成品質としては前回とそこまで変わらない気がしたが、質問を一回投げているだけなので、正直なところちゃんとした品質を確かめるには叩きまくる必要はあると思う。面倒なのでそこまではしてない。

おまけ:Poe上のQwen3.6-Plus

Qwen3.6-Plusはクラウド専用モデルのため、ローカルでは動かないが、動かしてみた感じ大分品質は良さそうに思った。少なくともローカルモデルのように目立ったハルシネーションは見られない。

あとがき

一般的なマシンで動くローカルLLMは、まだそれなりという感じの次元だが、Qwen3と比べると3.6は気持ち品質が上がったように感じた。とはいってもLLMはコンテキストがある状態で質問したり、コーディングさせたりしないと真価がわからないので、今回のように「神戸市について教えて」と聞くだけではあまり意味のある結果にはならないので、あくまで参考値くらいだろう。

取り敢えずまともなモデルはOpenAIもQwenもクラウドにあって、配布されているモデルは劣化版というのが分かったのが今日の収穫だったように思う。

Qwen公式の比較表を見る限り、Qwen3.6-35B-A3BはClaude Sonnet 4.5よりは賢いようだ。ただSonnetは個人的にはもう使っておらず、レートリミットがない環境で使っているのもあり、もっぱらOpus 4.7しか使っていないので、Sonnet 4.5を超えたところで微妙な感じは否めない。4.5は個人的にERPをするときにOpus 4.7, Sonnet 4.6, Opus 4.6でも返事をしなくなったときに4.5を叩き、その次のターンでOpus 4.6→Sonnet 4.6→Opus 4.7という流れで回帰させるのに使うことが多い。これは何をしているかというとSonnet 4.5の検閲が緩いのを逆手にとって、上位バージョンを騙すためのコンテキストを書かせているわけだ。

Sonnet 4.5が出た時は割と重宝していた記憶もあるのだが、Opus 4.7が優秀なので、もうまともな用途ではOpus 4.7以外全く使わなくなった。Opus 4.6も悪くはないと思うので、Opus 4.6くらいまでローカルLLMが進歩してくれたら助かるところである。

ひとまず今回の収穫はQwen3.6-35B-A3Bという昨今注目されているモデルが、特にメモリの増設なしでも動いた上に、VRAMを使わずRAMだけで実用速度で走らせることができたことだ。

クラウドLLMは高いのでローカルLLMで解決できるようになれば、それに越したことはない。

余談だがQwen3.6-35B-A3Bは検閲モデルだがQwen3.6-35B-A3B-Uncensored-HauhauCS-Aggressiveという無検閲モデルがあり、ERPが機能することを軽く確認している。弾かれないこと程度しか確認してないので品質は謎いが、テストで叩いた感じはそこそこの内容を出してくれたと思う。少なくともGPT-4やGrokよりはよいと思うので、お金を節約したい人にはオススメかもしれない。