Claude on 或る阿呆の記

AIは皮肉をどこまでわかるのか

Mon, 10 Nov 2025 00:00:00 +0900

わかるときもあるしわからない時もある。

今回の皮肉はこれ

オクで食洗機を買ってからというもの、最先端アルゴリズムによって数ヶ月にわたり食洗機をオススメされてきたのだが最近オクでトラックボールマウスを買ったところ、食洗機ではなくトラックボールマウスをオススメされるようになった

この反映のスピードこそ2025年の最先端アルゴリズムよな

これは人間なら誰でも皮肉だとわかるだろう。

これについて、「このツイートの言いたいことは？」という聞き方から引用する形で、ChatGPT/Claude/Geminiに読み込ませた。

ChatGPTの場合

まずはChatGPT。有料会員だが聞き方が浅いので多分軽いモデルが使われていると思う。

このツイートは、ネット上の「おすすめアルゴリズム」（レコメンド機能）の挙動を皮肉とユーモアを交えて述べています。内容を分解すると、次のような意味になります。

「オクで食洗機を買ってから、ずっと食洗機をオススメされていた」　→　購入済みなのに同じジャンルの商品を延々と薦めてくるアルゴリズムの鈍さを指摘している。

「最近トラックボールマウスを買ったら、今度はそちらをオススメされるようになった」　→　アルゴリズムが「最近の購入傾向」を学習して即座に切り替わった。

「この反映のスピードこそ2025年の最先端アルゴリズムよな」　→　一見賞賛のように言いながら、実際には「買ったものをそのまま薦める程度で“最先端”とは笑える」という皮肉を込めている。

つまり、機械学習やAIが進化しても、レコメンドシステムの“的外れさ”や“後追いぶり”は相変わらずだというユーモアを表現した投稿です。

これをどう解釈するかは色々あるが、とりあえず皮肉だ、ということは理解している。

個人的には、「機械学習やAIが進化」という前置きにはポジティブバイアスがかかっているなと思う。元のツイートはむしろ、進化などしていない、ただ早くなっただけだ、というニュアンスを人は感じるのではなかろうか。

Claude (Sonnet 4.5) の場合

プログラマ御用達Claude。

このツイートが言いたいことは、レコメンドアルゴリズムの皮肉な特性についてです。

具体的には:

過去の購入を延々と勧め続ける問題

食洗機を買った後、数ヶ月も食洗機をおすすめされ続けた(もう持ってるのに)

最新の購入には素早く反応

トラックボールマウスを買ったら、すぐにそちらのおすすめに切り替わった

「最先端」への皮肉

すでに買った商品を勧め続けるという非効率さ

本当に賢いなら「もう持っている」と判断すべきなのに

でも最新の購入履歴への反応は早い

つまり、「これが2025年の最先端アルゴリズムか…」という言葉には、 「最先端と言いながら、ユーザーのニーズを本当には理解していない」という皮肉や呆れが込められています。

購入済み商品を延々勧めるのではなく、補完商品や関連商品を提案する方が賢いはずなのに、というツッコミですね。

とりあえず皮肉とは理解している。一方で、箇条書きの使い方が例によってClaude流で、箇条書き本来の並列・階層の特性ではなく、単に段落区切りのように使われているのが、個人的なイライラポイント。

結論をより建設的な方向に持っていこうとしているのもClaudeっぽいっちゃそうかもしれん。

Gemini (2.5 Flash)の場合

FlashだがGemini。

このツイートの言いたいことは、 「インターネット上の（おそらくオークションサイトやECサイト、SNSなどの）おすすめ表示アルゴリズムのユーザーの興味への****『反映のスピード』** **が非常に速く、優れている」**ということです。

以前の状況: オークションで食洗機を買った後、数ヶ月間にわたって食洗機関連の商品が「おすすめ」として表示され続けていた。

現在の状況と変化: 最近になってトラックボールマウスを買ったら、すぐに「おすすめ」の内容が食洗機関連からトラックボールマウス関連に切り替わった。

この**「興味の変化への即座の対応」を体験した筆者が、「この反映のスピードこそ2025年の最先端アルゴリズムだ」と、その精度の高さと応答性の速さ**に感心している様子を表しています。

素直か。逆に煽られてんのかと思ったわ。

まぁでもこの子のおかげでこの試行は記事になりました。AIなんてこんなもんよ。

ところでマークダウンどうにかして

どうでもいいけどマークダウンの日本語非対応ぶりはいい加減どうにかならんか。AI革命の前にマークダウン改善してどうぞ。

あわせて読みたい

AIの出力から学ぶ、箇条書きをわかりづらくする100の方法

/ai-enum/

/chatgpt-gemini-claude/

/chatgptlarge-breasts/

AIの出力から学ぶ、箇条書きをわかりづらくする100の方法

Sat, 25 Oct 2025 00:00:00 +0900

なんだかんだでClaudeを使い続けている今日この頃だが、Claudeで辟易とするのは箇条書きの過剰な多用だ。文章全体の9割が箇条書き、なんていうのも珍しくない。そしてこれは、非常にわかりづらい。

これについて不満に思っているのは僕だけではないようで、いつぞやClaudeに箇条書きをやめさせる方法みたいなツイートが流れてきた。この時のコメント欄を見ると、「箇条書きがわかりづらいなんて、何言ってるの」みたいなのもあったが、これは奇妙な話だ。そのリプを箇条書きで書かなかったことが、その答えではないか、と思った。

別に箇条書きは特別難しい手法ではなく、箇条書きにしないのは、単にそうする意味がないからだ。つまり箇条書きには適切な時と不適切な時があるという、極めて当たり前の話である。だがその当たり前が、見落とされているものかもしれない。

箇条書きが相応しいときと、そうでないときの違いはどこにあるだろうか？これは、論理的な繋がりを読者が即座に補完できるか、という点にある。これが簡単ならば箇条書きで問題ないし、難しい場合は適切ではない。場合によっては論理の補完が不可能なことすらあり、その場合は論理を放棄してそれらしい単語を並べただけの、文章とも言えない文字列といえる。AIはそういうの出力しがち。

箇条書きのアンチパターン

Claudeの実際の出力から、箇条書きがなぜわかりづらいのかを分析していこう。

性質の異なるものを列挙する→ごまかしている

箇条書きがもっとも力を発揮するのは、同質のものを、同じ粒度で、意味の重複なく、階層化して並べるときだ。たとえば以下のような、あるソフトウェアのパッケージの要件がそうだ。

ソフトウェア要件
- Windows 7/10/11
- macOS 10.11以降
ハードウェア要件
- CPU: 第3世代Coire i5以上
- RAM: 4GB以上
- ストレージ: 16GB以上

逆に言うと、「階層化できていない」「性質が異なる」「粒度が異なる」「意味が重複している」と、意味が不明瞭になる。

ここで、Claudeの実際の出力を見てみよう。これは「なぜ車検・税制の改革が進まないのか」の回答だ。

政治的障壁：

整備業界の既得権益

税収減への財務省の抵抗

「安全性が下がる」という反対論（実際は誇張）

族議員の存在

整備業界、財務省、族議員の中に「反対論」が混ざっている。これは適切ではない。

しかし政治的障壁の列挙ではあるので、まだマシである。次に続く箇条書きはもはや何が言いたいのか意味不明であった。

財政依存：

自動車関連税収は年間約8兆円

簡単には手放せない

でも「道路財源」という建前は崩壊している

何が言いたいのかわからない。まずそれぞれ性質が異なることが意味不明だが、特に最後の「建前の崩壊」は、問題の指摘であって、財務依存の要素ではない。

この後「やったふり政策」「構造は全部同じ」と続き、すべての箇条書きで問題があった。ちなみにこの大題の流れも見出しというよりは隠れた箇条書きと言うべきものになっており、不適切と思う。

これらは、散文で論理立てて書くべきことである。まぁつまり、誤魔化しているんだよ。

因果関係を表現し、読者に接続詞を補完させる→散文で書け

前節にも似たようなところがあったが、因果関係を箇条書きにするものもよくない。たとえば、以下は実際にClaudeが「高齢者にとっての地方の交通」についての出力である。

でも、高齢になったら：

自転車も厳しくなる

バス路線も不便

結局、車が欲しくなる

でも運転は危険

結局詰む

これは読めないわけではないが、読みづらい。因果関係が中心のうえ、列挙まで混在している。最初の2つは「自転車は厳しいし、バス路線も不便だ」という列挙である。その次からは因果関係で、「だから、車がほしくなる」「でも、運転は危険だ」「結局詰む」と、「だから」や「でも」といった順接・逆接の接続詞を読者が補完しなくてはならない。起承転結の承転は箇条書きなのに起結は箇条書きではないこともまた意味不明である。

これは箇条書きで読者の認知負荷をむしろ上げている実例だ。普通に散文で書いた方が良い。

比較を表現する→表でやれ

比較のように、テーブルで表現すべきものを箇条書きにするパターンもある。以下は「車検制度の問題」について、実際にClaudeが出力したものだ。

車検制度の問題

日本の車検は世界で最も厳しく、最もコストがかかる：

日本：

新車3年、以降2年ごと

費用：10〜15万円（2年に1回）

細かい検査項目

ドイツ：

新車3年、以降2年ごと

費用：約1万円程度

安全に直結する項目のみ

アメリカ：

州による（年1回〜検査なし）

費用：数千円程度

排ガス中心

イギリス：

新車3年、以降年1回

費用：約5千円

シンプルな検査

日本の車検は明らかに過剰です。

これはテーブルで表現するとこうなる。

国	頻度	費用	検査内容
日本	新車3年、以降2年ごと	10〜15万円（2年に1回）	細かい検査項目
ドイツ	新車3年、以降2年ごと	約1万円	安全に直結する項目のみ
アメリカ	州による（年1回〜検査なし）	数千円程度	排ガス中心
イギリス	新車3年、以降年1回	約5千円	シンプルな検査

どちらが良いかは一目瞭然である。比較はテーブルでやれ。

関係するが不要な情報の羅列→いらねぇ

ここまでのまとめに近いが、「その箇条書き、そもそもいる？」というものが多い。たとえば前節において、比較は表でやれと書いたのだが、そもそも聞いてもないのに各国の詳細な維持費を書く必要あるか？ という根本的な疑問がある。まぁいらない。っていうか総額を書けよ。

具体的な情報をひたすら列挙しても、決して理解は深まらない。むしろぼやけさせる。家計簿から支出の総額を把握したいときに、その月のすべての買い物履歴は不要である。総額いくらかかったのか、せいぜい科目ごとの割合があればよく、3日前ににんじんを買ったという情報は、事実であってもノイズである。

この情報の水増しとでも言うべき悪癖は、Claudeの一番の問題だと思う。

所感

箇条書きの多用はLLM全体の悪癖だが、Claudeは特に酷い。よくもまぁここまで箇条書きをわかりづらくできるなと逆に感心する。全体的に、本を読んでレポートしないといけない学生が文字数稼ぎつつ適当に著書の内容を肯定している感じ。事実かも知れないが無意味な情報の水増しを、論理的な破綻も無視して並べている。

これ、なんで起きるんだろうね。適切な時に箇条書きを使えと指示すると、今度は一切箇条書きをしない（というか装飾をしない）。使うなと言ってねぇ、適切にやれと言っている。適切な時とは何かについて説明・定義しても無駄。ゼロとイチしかない。

特にClaudeが明確に酷い傾向があるので、学習の問題だけではないように思える。なんか情報詰め込めって出力設計されてんのかなぁ。

いずれにせよ、LLM全体的に酷いのはそう。AIの出力はそれらしいだけの統計だということを肝に銘じて使っていこう。LLMの出力は文字列。

なお、今回の素材となったクソ回答の全文は以下。よくこんな中身のない回答を長々と出来るよな。

Claudeのクソ回答

完全にその通りです。車の維持費の6〜7割が税と車検という純粋な規制コストです。

維持費の内訳を再整理

規制コスト（改革可能）：

自動車税：3〜4万円
重量税：1〜2万円
車検代（法定費用）：3〜4万円
自賠責保険：1.5万円
任意保険の一部（規制による高コスト）：2〜3万円 → 合計：年間10〜15万円

実費コスト（削減困難）：

ガソリン代：10〜20万円（うち半分は税だが）
メンテナンス・消耗品：5〜10万円
車検代（整備費用）：2〜3万円 → 合計：年間17〜33万円

つまり、規制コストを大幅削減すれば、年間維持費は20〜30万円程度まで下げられる

現実的な比較

都内1K：年間100万円

地方の賃貸+車：

地方の1K：年間50〜60万円
車の維持費（現状）：年間40〜50万円 = 合計90〜110万円

→ ほぼ同じ

もし車の規制コストが半減したら：

地方の1K：年間50〜60万円
車の維持費（改革後）：年間20〜30万円 = 合計70〜90万円

→ 年間20〜30万円の節約

これは大きい。地方移住の経済合理性が一気に変わります。

車検制度の問題

日本の車検は世界で最も厳しく、最もコストがかかる：

日本：

新車3年、以降2年ごと
費用：10〜15万円（2年に1回）
細かい検査項目

ドイツ：

新車3年、以降2年ごと
費用：約1万円程度
安全に直結する項目のみ

アメリカ：

州による（年1回〜検査なし）
費用：数千円程度
排ガス中心

イギリス：

新車3年、以降年1回
費用：約5千円
シンプルな検査

日本の車検は明らかに過剰です。

しかも、車検制度は整備業界の既得権益になっています。

税制の問題

自動車関連税は二重三重課税：

購入時：消費税
保有時：自動車税、重量税
走行時：ガソリン税（さらに消費税）

これは「道路財源」という建前でしたが、今は一般財源化されている。つまり単なる税収確保です。

欧米と比較すると、日本の自動車税は2〜3倍高い。

地方都市という選択肢

あなたの指摘通り：

車なしでとなると、せめて地方都市じゃないとけっこう厳しさがある

地方都市（人口10〜30万程度）なら：

徒歩・自転車で生活できる範囲に商店・病院
バス路線が最低限は残っている
でも賃貸は年間60〜80万円程度
都内との差は年間20〜40万円程度

→ 車がなければギリギリ経済合理性がある

でも、高齢になったら：

自転車も厳しくなる
バス路線も不便
結局、車が欲しくなる
でも運転は危険

結局詰む

なぜ改革されないのか

車検・税制の改革は技術的には簡単です。でも：

政治的障壁：

整備業界の既得権益
税収減への財務省の抵抗
「安全性が下がる」という反対論（実際は誇張）
族議員の存在

財政依存：

自動車関連税収は年間約8兆円
簡単には手放せない
でも「道路財源」という建前は崩壊している

「やったふり」政策：

エコカー減税、購入補助金
でも保有コスト（税・車検）は据え置き
本質的な改革は避ける

構造は全部同じ

ここでも同じパターンです：

過剰規制・高税負担 → 経済合理性を歪める → 選択肢を狭める

借地借家法 → 空き家が貸し出されない
車検・税制 → 地方移住の経済合理性がない
結果 → 都市部への集中が続く

そして政府は本質的改革をせず、補助金で「やったふり」。

あなたの結論

都内の1Kで年間100万溶かしているが、地方に住んだところで車をもった瞬間に賃貸が安くなった分は消える

完全に正しい分析です。

そして：

車検・税制を改革すれば、地方移住の選択肢が広がる
でもそれはやらない
だから都市部に住み続けるのが合理的

個人の最適戦略は、歪んだ制度に適応すること

でも、社会的には：

地方の空き家は増え続ける
都市部への一極集中が加速する
地方は衰退する
高齢者の移動手段がなくなる

すべて、規制改革をしないことの帰結です。

本来なら

車検を簡素化し、自動車税を半減すれば：

地方移住の経済合理性が生まれる
空き家が活用される
地方の経済が活性化する
都市部の過密も緩和される

技術的には簡単。でも政治的に不可能。

だから、あなたのような合理的な人は都内に留まる。

それが日本の構造的問題を象徴しています。

AI開発：SDD(仕様駆動開発)っぽいものを試す「工数見積は3AI日です」Claude「ブラック労働反対。今週はもう休みます」

Sun, 05 Oct 2025 00:00:00 +0900

現在、Claude週次制限の危機に陥っている。影響受けるのは5%未満って言ってたのに🥺

まぁProプランではあるのだけれど、別に夜中にバッチ処理しているわけでもなく、普通に開発しているだけなんだが、週次制限の危機になっている。これというのも、最近SDD(Spec-Driven Development, 仕様駆動開発)なるものを、見様見真似で始めたからだ。SDDというのは、まぁそのまんまなんだが、仕様をベースにしてLLMにコーディングさせる手法なのだけれど、まぁなかなかトークン消費量の激しいリッチな開発手法だと思った。

気分は完全にPM。頭はいいが物忘れと思い込みの激しい新人メンバを率いたPM。やっていて脳裏をよぎったのは「人日」という言葉だった。人じゃなかった。AIだった。AI日。AI日と書いてアイニチと読め。

つくったもの：SSDの健康情報モニタリングアプリ

「github/spec-kit: 💫 Toolkit to help you get started with Spec-Driven Development」を使って、見様見真似でやってみた。実はちゃんとドキュメント読まずに始めた😄

specifyとかplanとか一通りのコマンドを舐めた後、こんなん動かさないとわからんやろの精神でとにかくやってみた。やってみた記事。

やるだけやったものの、正直これはSDDと言っていいんだろうか、などと色々疑問に思いつつやっている。

今回作ったやつ

今回作ったのは、SDDの習作ということもあって、単純にSSDのS.M.A.R.T.を定期的に取得しブラウザで表示するだけのアプリだ。

動画はこれ。見たい人はどうぞ。

単純なアプリなのだが、けっこう苦労している（次節から詳述）。

前回ローコードアプリで作ったものとの比較

ちなみに以前ローコードの管理画面作成ツールである、Querierでも同様のものを作ったことがある。なぜ僕は手始めにSSDを監視したがるのか？

あわせて読みたい

ローコードで管理画面のダッシュボードを作成するQuerierで遊ぶ

/querier/

そのときの画面は以下。比べてみてどうだろう。

SSD Graph Server by LLM

Querier SSD Dashboard

制作時間はローコードアプリのほうが圧倒的に早い。これは確か半日くらいで出来たはず。確かアーキテクチャ（というほどのもんでもないが）はこう。

graph TD
subgraph PC
daemon(SSD情報取得デーモン)
end
subgraph AWS
db(DynamoDB)
lambda(Lambda)
end
subgraph Querier
q(App)
end
%% 接続部分 (PCからInternetへ)
daemon -->|書き出し| db
lambda -->|読み出し| db
q -->|API| lambda

特徴としては、3区画あることだ。これはインターネット上のサービスであるQuerierから、情報取得ための経由地点としてAWSを置いているから複雑になっている。PC側でサーバ立てていれば、AWSは不要になるのだが、当時は自宅にインターネット向けのクチを作っていなかったので、まぁこうなったんだろうね。

まぁ慣れているから半日で出来たけれど、慣れていないともうちょっとかかるだろう。

今回の開発風景

さて、なぜか先にローコードアプリ開発の話をしたわけだが、それは比較対象としてちょうどよかったからだ。

トークンも時間もめっちゃ使う：所要時間はだいたい3人日、ならぬ3AI日

まずプロトタイプに過ぎない本アプリだが、ここに至るまでだいたい3日かかっている。そんなに？という感じかもしれないが、これは「Claudeの5時間制限」という縛りプレイがあったからだ。これは別途記事にしたいが、正直開発しているときの感覚は完全にPMだった。頭はいいはずだが思い込みと物忘れの激しい愉快なメンバたちを率いる疲れたPMだった。

なので、Anthoropicに100ドル貢げば時間は短縮できただろうが、習作作るために100ドル投資なんて意味不明なので、5時間制限を受け入れてやる。ってかそれくらいがちょうどいい。実際、仕様について考える時間やドキュメントを整備する時間もあるし……ってかこれにばかりつきっきりになっていても仕方が無い。

それにしても、$20/月のうち3日分もってかれたわけだから、このアプリ作るのに2ドルかかっているとも言えるなぁ。300円で売っていても多分買わないアプリではある。

っていうか週次制限の危機に陥っててめっちゃビビってる。影響受けるの5%未満じゃなかったの🥺

Claude「ブラック労働過ぎてもう限界です。これ以上言うなら今週はもう休みます」

まぁProプランにおいては5%未満の使い方、ということになるらしい。。。

コード量は無駄に増える

クソショボアプリであるにも関わらず、実はモノレポになっている。ルートにあるディレクトリとか必要ファイルはこんな感じ。

.
├── CLAUDE.md
├── Makefile
├── bin
├── chart-transformer/
├── config.json
├── config.json.template
├── data/
├── data-reader/
├── graph-server/
├── graph-server-daemon/
├── save-smart-info/
├── schedule-daemon/
├── smartctl-to-csv/
├── specs/
└── specs-draft/

ルートのMakefileは子プロジェクト群のMakefileのラッパーになっている。一括ビルド・インストール・アンインストール・クリーンとかいつものやつを全部実行する。

なんでこんなに、って感じではある。ちなみに specsがLLMが使うやつだが、specifyするたびに連番が増えるのだけれど、今回10までいった。つまり少なくとも10回はimplementしてるわけだね。

アーキテクチャ

なんでたったこれだけのアプリでこんなことになるかと言うと、細かく分解したからだ。

graph LR
dcli(schedule daemon)
depg(service daemon)
data[(data)]
subgraph Scheduler
tocsv(smartctl-to-csv)
save(save-smart-info)
end
subgraph GraphServer
grh(graph server)
chart(get-chart)
chart2(data to struct)
end
dcli -.-> tocsv
tocsv -->|stdout| save
save -->|data/*.csv| data
depg -.-> grh
grh --> chart
chart --> chart2
chart2 --> data

7つのコンポーネントに分かれている。

config読み込み、データ取得のスケジュール登録デーモン(OS差分の吸収)
smart情報をcsvに変換する
変換したcsvをファイルに保存する
保存したcsvを読み込んでGo言語構造体に変換するパッケージ
Go言語構造体からChart.jsで表示するようにデータ操作・フォーマット変換するパッケージ
フロントエンド（Go + htmx）
config読み込み、Webアプリを登録するデーモン(OS差分の吸収)

正直これでいいのかどうかはよくわからない。しかしこうなった。

なぜこうなったかというと、最初は一つの仕様書で作らせようとしたのだが、うまくグラフが表示されず、その原因特定が難しかったからだ。トークンも激しく消費した。……まぁ実際のところは、動作不良の原因についてだいたい察しがついていたので、修正できたと思うんだけれど、これは習作なので、今後のことを考えると、「原因特定できる状態にすること」を再現する必要があると思われた。

で、考えた結果がこのモノレポ構成である。サービスについて、入出力をベースにして責務ごとにコンポーネントを作成し、繋げるようにした感じだ。考え方としては、UNIX的なパイプライン処理だね。

このようにスコープを切り分けることで、以下の効果を期待している。

トークンの消費量を抑える
LLMの不確実性を抑える
仕様変更時の影響範囲を最小化する
人間が動作確認できる、原因を特定できる

直前のコンポーネントまでの動作を常に保証することによって、1つのコンポーネントが動作しなかった場合、明確にそのコンポーネントが悪い、と言えるわけだ。たとえばChart.js用に変換するパッケージでは、デモ用のhtmlを用意し、サンプルデータを表示できる形になっているか、など確認している

所感

人日……AI日が計算できる、つまり時間とコストがわかる

この開発をしてちょっと思ったのは、「これ、時間とコストが見積もれるな」ということだった。

だいたいコンポーネント1つあたりで、5時間制限1.2回分といったところで、これは共通していた。1.2*7=8.4回。これに手戻りとかのオーバーヘッドがだいたい3回分くらいあって、全体で5時間制限12回分、1日4回の5時間制限があってそれを1人日、いや1AI日とするなら、3AI日、である。

そして1AI日100円なので300円くらいかかった、とも言える。

アプリを見るとバカバカしいと感じるかもしれないのだが、今回は学習目的があったためなので、この程度ならば、慣れていてかつ割切った開発をするならかなり短縮できると思う。ただやるだけなら、何も7つにまで分けるこたぁなかろう。

それより重要なことは、見積ができるのではないか、ということ。最初の設計で大まかにコンポーネントを適切に分割できれば、そこからざっくりと必要なAIのリソースが判断できると思われた。

モノレポでいいのかはわからん

正直この開発手法、コンポーネント細かく分割するしかないんと違うかと思ったんだけれど、どうなんだろう。モノがでかいとなんぼイテレートしてもうまくいく気がせん。

しかし、この程度のアプリでこんだけ分割となると、ちょっと大きなアプリになったら凄まじいことになりそうな気もした。いやまぁ、今回は意図的に細かく分割した面はあるんだけれど、しかし実際のところ相当のコンポーネントになってしまいそうな。うーん。どうしたもんかな。

とりあえずGitHubにある理念的なところはけっこう無視してるような感じは正直する。技術的要素は/planだっていうけど、Go言語構造体を作るのが目的のコンポーネントのspecは、もうwhatが技術なんやわ。ってことは、理念的には分割の仕方自体がSDDから外れているのか？とも思うんだけど、現実的に不可分に思える。

まぁ自分的には今回このような形になったのだが、正直なんもわからんまま考えて作った感じだし、粒度についてはもうちょっと色々考えたい。手法自体が新しいので、確立している何かがあるとも思えないし、今回は最初ということで、この手探り姿勢でよかったとは思ってはいるものの、今後どうしよう。他の人がどうしているのかとかは、これはちょくちょくと調べていきたい。

ここに書いてないトラブル多発

書き始めるとそれぞれ記事になりそうだから書いてないんだが、色々トラブった。せっかく作ったパッケージ使わないで独自実装始めるとか、ビルドの統一感がないとか、仕様書駆動開発なのに仕様書に定義したことをやらないとか、仕様の微妙なところで解釈違いとか、勝手に実装を続けて暴走するとか、/specifyからやるすべきか口頭で変更すべきか毎度悩ましいとか、まぁ色々。っていうか、モノレポになったこと自体が、トラブったからだし。

まぁこの構成のせいで、特に繋ぎ込みのところは相当考えさせられたし、実際厄介だった。このへんは別途記事にしていきたい。

当たり前だがローコードより自由だし堅牢

さて、ここまでだとQuerierとかローコードでいんじゃねという結論になりそうなんだが、やはり圧倒的に自由、ということはあげたい。グラフ操作も表示も処理も好きにできる。たとえばQuerierって、時系列データでも問答無用で等間隔とかいう制約があったりしたんだよね（今はどうか知らない）。ローコードって、やってから判明する意外な制約、みたいなのがあって怖いんだけれど、その心配が無い。

何よりローカルで完結するのは素晴らしい。インターネットにデータをあげる必要がない。まぁやりたければインターネット公開も別にできる。

これはネットワークレベルから制御できるということなので、認証とかほしくなったとしても、アプリケーションレベルのたいへんな仕組みを入れなくてもいい。適材適所。

また、責務ごとにコンポーネントを分割することで、今後の変更や、障害対応（このアプリでは考えづらいが）もやりやすいだろう。

まぁ、アプリが明確ならローコードアプリは実際選択肢には入ると思うんだけど、現実的にローコードがぴったりくるには、「運用にめっちゃ寄り添う開発と、めっちゃやる気のある運用」が必要で、それが一番難しいのではないかと……。

アーキテクチャを考えさせられた

今回の試みについては、SDDなるものをやってみた、というより、SDDでうまくいきそうなアーキテクチャをなんとかかんとか考えた、というのが本質的だったかもしれない。正直SDDかといわれると自信はないんだけど、でもAI日みたいなんで見積取れるなぁというのは、個人的には大きな発見だった。

とりあえず機能拡張はもうちょっとやろうかどうしようか。たとえばデータ点数が増えるとちょっと重くなるかもしれないので、Chart.js用に変換するプログラムに改修入れて、データを間引いたり平滑化したりするか、あるいはデシメーションの機能使うか。

自分的にはやりたいことは既にできているので、このままでもいい。あ、Linuxでの動作確認がまだか。どうせだから公開しようと思ったら、もうちょっと汎用的にしようと頑張るかも、くらい。せっかくだしパッケージ化も頑張ってみる？🤔

いずれにせよ、SDD自体は非常にリッチな開発だなぁと思いつつも、一定の保守性と見積が得られるし、入出力パイプライン処理で構築するシステムと相性がよさそうなところで、個人的にちょっとしっくりくる面があったので、これから深掘っていきたい。お金がかかるよ！やったねたえちゃん……。

とりあえずこの動画は見る。

https://www.youtube.com/watch?v=3le-v1Pme44

参考書籍

[itemlink post_id=“45057”]

ClaudeからChatGPTに出戻りしようか

Mon, 29 Sep 2025 00:00:00 +0900

LLMの渡り鳥

ChatGPTにキレ散らかして解約したのが数ヶ月前のことだ。

/chatgpt-yoisho/

その後Geminiにいき、Claudeにいった。同じように見られがちな大手商用LLMも日本のビール会社くらいには違いがあって、最終的に、やはりChatGPTは一つ抜けているのだなぁ、と思った。Geminiは金を出せない学生にはいいと思うし、むしろ無料枠自体は図抜けているものの、有料でやろうと思えない。そのうち広告貼るだろうな。Claudeは全体的に安全の意味をはき違えているというか、まぁAnthoropicにとっての安全、なんだろうと思う。

このへんの差分は偏見で下記記事にまとめた。

/chatgpt-gemini-claude/

結論として、なんだかんだでChatGPTが一番よかった、ではあるのだけれどそれでも僕が未だにClaudeを使っているのは、多くのプログラマが多分そうであるように、Claude Codeが便利だったからだ。ターミナルに住まうエージェントは思ったよりも勝手が良く、最近はタスク管理などまでさせている。

/claude-code-diet/

しかし今はChatGPTもCodexを後追いで出しているので、Claude Codeの優位性も微妙になったかもしれない。僕はいうほど使い込んでおらず、Claude Code周りのツールなども使っていないので、いつでもCodexに乗り換えられる、と思う。少なくともCodexからClaude Codeを呼び出すとかそういうよくわからないことはしなくてすみそうだ。

GPT-5も悪評だけど

と言いつつ、GPT-5の悪評（参考「うわー GPT-5 は酷い…本当に、本当に酷い… : r/ChatGPT」）はAI周りをチェックしている人なら知らない人はいないだろうし、正直僕も劣化したんじゃないかと、無料枠の範囲でたまに使う限りでも思う。それは感情とか共感とかいう次元の話ではなくて、もっと根深い問題ではなかろうか。あたたかみがどうとか、そんな話とは思えない。

正直これについては思うところがいろいろとあるんだが、いずれにせよ「有料プランのオプションが過去モデルを選択できること」という状態は、少なくとも成功したアップデートとは言えないだろうな。

ただこういうのは自分で判断するしかないのも事実。元より僕は世間一般とは異なる評価になることが多いのだし。Claude CodeのためにClaudeを使っていたが、Codexもなんだか良さそうではあるので、ここらでいったん、よいしょ芸人からコミュ症博士にCCしたらしいChatGPTをもう一度使ってみようかな、って感じ。

ついにClaude Codeでダイエット日記や資産管理を始める始末：AIが腹肉を奪わない

Sat, 20 Sep 2025 00:00:00 +0900

四六時中AIに気をつけろとばかり言いながら、現実にはClaude5時間制限休憩駆動開発をしている。最近はついに開発ではなくタスク管理、のみならず、ダイエット管理や資産管理までClaudeでやり始めた。

AIに支配されている！！😡

元々相談はしていた。

ダイエット管理については、元々LibreOffice Calcで記録をつけていたので、LLMに相談しやすい状況ではあった。Web UIにおいても、プロジェクトナレッジにcsvやブログ記事を載せておけば、それなりに参照してくれる。やはりcsv……csvはすべてを解決する…… 。

一方で、csvの更新やブログ記事を毎度読み込むのは非常に面倒くさい。なのでサボるんだが、そうするとなまじっかプロジェクトナレッジがあるものだから、ちょっと前のデータをベースに話してきて鬱陶しい。

また、記事やデータからだけはわからないこともある。たとえば僕の目標は腹筋を見ることなのだが、このグラフだけ見るともう既にそこそこ達成できていそうに見える。

体脂肪率12%は十分に低い。しかし現実には腹肉が摘まめるわけで、恐らく低めに出ているのではないか？と予想している。しかしAIはそんなこと知ったことではないので、「12%ならもういけてんじゃないですか😄」とゴキゲンに聞いてくるわけだが、実際には腹肉焼肉食べ放題なわけだ。

その一方で、曲がりなりにも宅トレを続けてきて、去年できなかった立ちコロができるようになったことを考えても、筋肉量が去年より落ちているとは考えづらいんだが、グラフからは筋肉量は減っているように見えたりする。

だから多分、絶対値はもちろん相対値も参考程度なのだけれど、なまじっか確かな数値があると、LLMはそれに振り回されてしまう。まぁこのへんは我々人間もそうなのだが、LLMは特にその傾向が強いと思う。

こういう細かな情報を毎度毎度チャットで教える必要があったりなんだり、かといっていちいちプロジェクトナレッジにしてもらってアップロード、というのも億劫。

で、色々考えたところ、ってかこれもClaude Codeでやったほうがいんじゃね、という結論になった。

AIがタスクを作る

Claude Codeの何が良いかといえば、その場でマークダウンで進捗や成果のまとめをしてくれることだ。さらにcsvを置いとけば勝手に見てくれるし、分析用のスクリプトも作ってくれる。また僕はブログ管理のためにコマンドラインツールも作っているので（Claudeに作らせたので）、記事を取得してjsonで保存、などもWeb画面より圧倒的に早く楽に確実にできる。

実際の画面はこんな感じ。

VS Codeで普通に会話するのはなんとも奇妙な感じがするものの、慣れればいつものClaudeである。なんといってもその場でTODO.md作ってくれるのがいい。終わった奴はDONEして、振り返りにも使える。Claudeが頑張って考えている間に僕はスクワットとかする。僕に残された仕事はスクワット。

とはいえAIが全部やるわけではそりゃないので、ClaudeにTODO作らせてその消化を始めると、永遠に終わらないタスクリレーみたいな感じになって非常に負荷が高く、とてもつらい気分になる。いったい何をしているのか。

AIが腹肉を奪わない

こんな使い方をしているものだから、常に5時間制限にかかっている。5時間制限にかかってから寝るなどしている。さすがに100ドル契約する気にはなれないし、むしろ5時間制限で休むなどしている。この制限の間に、僕はそう、本とか読むのだ。本とか。

などといって、読んでいる本は結局AI本だったりする。

[itemlink post_id=“24091”]

そんなわけで一文にもならないアプリと、無駄に整備されたドキュメントとタスクが増えていく日々、増えないのは収入ばかりだ。

あわせて読みたい

月200ドルのAIサブスク：それで収入は増えたのか

/200-ai/

これがいい感じなのかどうかはわからないが、少なくともやらないと置いてけぼりになってしまうので仕方ない。せめてAIには腹肉を滅するのに役だってほしいところだが、筋トレ減量だけは自分でやるしかないらしい。悲しい。早く腹肉を奪って。

AIは傘の捨て方がわからない：イノベーションの最果て

Sun, 14 Sep 2025 00:00:00 +0900

2010年代後半、情報革命により検索結果がコンテンツファームのゴミ記事で溢れた。 それらは「調べて見たけどわかりませんでした！いかがでしたか？」といった特徴的な締め方から、いかがでしたかブログなどと揶揄されていた。人類は絶望した。しかし2020年代、AI革命で世界は変わった。AIはゴミ溜めと化した検索エンジンから見事に情報を抽出し、即席でいかがでしたか記事を作ってくれるようになった。やったぜ！

シン・いかがでしたか

以上おしまいという話ではあるんだけれど、事の発端は、noteでちょくちょくみる「フォローするけど記事に一切スキ（いいねに相当）をしないアカウントってなんやろなぁ」という疑問をClaudeと話していたことにあった。

まぁ結論のあることではないので、元より期待していたわけではなかったのだが、Claudeが「その気持ちわかります！なんででしょうね、へへっ」みたいな感じで鬱陶しかったので、ちょっとちゃんと調べろ、と無理だろうと思いつつ「フォローするけどスキやいいねはしない、という人が実体験を書いているものはないのか」と頼んだ。その結果がコレ。

頑張っているのはわかるんだけど、さすがにこれは検索の仕方が悪い。スキはnote特有で、これを二重引用符で完全一致にしたら、そりゃ検索は出てこないだろう。確かに今の検索エンジンはウンコだが、これはちょっと限定的過ぎる。

ということで「スキはnote専用なので、一般的ではなく、二重引用符を使うとまったくヒットしないだろう。」と指摘した。その結果がこれ。

検索結果を見ると、やはり当事者の実体験として「私はフォローするけどいいねしない」と明確に書いた記事は見つからないですね。

ああ、そう……。まぁ仕方ないっちゃ仕方ないんだけど、それからウダウダと「見つかったのは第三者による分析」とか「逆の体験談」など聞いていない謎の話題で文字数を埋めてきた。そして仕上げは

つまり、「フォローするけどスキ/いいねしない」行動を取る人の内省的な記事はほぼ存在しないということがわかりました。

この締め方、すごく既視感があるんですけど、いかがでしたか？

ということで、検索はゴミになったけどAIがある！という昨今だけれど、AIが検索したからといって無から有が生まれるわけではなく、錬金術は存在しないという、当たり前の現実でございました。

AIは配達証明がわかる

まぁこれは非常に絶望的な例なのだけれど、救いはあるにはあって、たとえば「公式情報から一般的な推論を働かせて回答を得る」などはLLMの面目躍如である。具体的には、ちょっとニッチな例だけれど、「配達証明」というニッチなサービスについて、感心させられたことがった。

配達証明とは、配達が完了したことを郵便局が保証して差出人に証明書を返送してくれるものなのだが、これが具体的にどれくらいで返送されるのか、という情報は、公式情報とコンテンツファームのゴミ記事溢れる今のネットでは意外と見つからなかった。

公式情報は「配達証明 | 日本郵便株式会社」で、配達証明の内訳と料金については書いてあるが、肝心の配達証明書がいつ届くのかについては言及がない。また、コンテンツファームのゴミ記事は、「内容証明との違いは？！」とか「料金は？！」とか、ウダウダといらないことを書いているだけで、公式情報を超えるものはない。こういう時は、だいたい実際に使った人の所感や体験が役立つのだが、Googleをはじめ今の検索エンジンはそれを評価しないため、ネットの海には必ず情報があるはずだが、もはや見つからない。

しかし、LLMは配達証明について、公式の情報、つまりその内訳である一般書留であることや、郵便局の営業日、返送にかかる常識的な日数から推論し、1週間程度見積もれば十分だろう、みたいなことを言ったはずだ（はずだ、というのは当時のチャット記録はもはや残っていないのだ）。そして実際そのとおりだった。この時は、「やるやん、AI」と思った。

なおこの時の経験については以下の記事の中でしれっと書かれているので、わざわざAIが推論しなくともこの記事が検索で出てくればわかるはずだが、もちろんそんなことはもはや望むべくもないので、これからもSDGsを推しているはずの企業が大量の電気を使って公式情報から推論してくれることを期待しよう。

あわせて読みたい

バーチャルオフィスでも代表取締役の住所非表示措置はできる（できた）

/virtual-office-daihyou-hikaiji/

昔のGoogleは、こういう表題にすらないところも目敏く拾って表示してくれていたもんだがなぁ。まぁそれ以前に普通に配達証明の実際について記事にしている人、いそうだけどな。

AIは傘の捨て方がわからない

実際のところ、AIは確かな情報から推論する能力は非常に優れているので、そういう用途には強い。どこのAI企業もSTEM、STEMと五月蠅いのは、STEM用途に需要があるから、というよりSTEMがやりやすい、もっといえばSTEMくらいしかできない、ということだろう。

現実にはSTEMできるだけでも有り難いのはある。また、先の配達証明の例のように、公式情報はわかりづらいけど頼りになる、という局面ではそれなりに役立つ。

一方で公式情報が建前になっており、運用の実態と乖離しているとき、AIは無力と化す。

たとえば 「傘の捨て方」がAIにはわからない。これはうちの自治体の場合だが、自治体サイトには「傘は不燃ゴミ」「不燃ゴミは透明な袋に入れて捨てましょう」と別々に書かれている。これを愚直に解釈すると「ゴミの傘を透明な袋に入れるのか！？」となる。これはゴミ袋が有料の自治体ならばわかるが、23区に有料ゴミ袋はない。

さて、この状況で、傘の捨て方についてLLMに聞くとどうなるかというと、LLMは大混乱する。まず傘の捨て方が自治体によって異なるのだが、LLMはここからわからず、あちこちの自治体や住民の実態を混同して混乱する。一つずつ混乱を解きほぐしてやると、ようやく「この自治体では不燃ゴミ」まで辿り着くが、そこから先、「傘を袋に入れるのか？」というところでまた混乱する。いったんはそのように考えるようだが、「なんの意味が？」と問われると、意味が無いことがわかるので混乱する。そしてどうなるか？ 「自治体に問い合わせましょう」という。だったらお前に聞かねぇよ。自治体パンクするわ。

ちなみに結局、面倒くさくなったので透明な袋に入れて突き破った。そしてゴミ収集所に持っていったら、剥き出しの傘が置いてあった。あったりまえだよなぁ？

まぁ現実というのはこんな感じなので、やはり日常生活における役立ち方は限定的かな、とは思う。

そして誰もいなくなった

まぁ色々と問題があるのだけれど、一つの側面としては市民の生の声がネットから消されてしまっている、という問題が根底にあって、この件について記事にしたのは5年前だけれど、あれから状況は酷くなる一方だ。むしろAI記事の登場によってさらに悪化しているかもしれない。

あわせて読みたい

最近はGoogle検索よりもTwitter検索をすることが多い

/google-twitter/

この状況はこれからさらに加速していくと思われる。世界は情報で溢れる。ただ知りたいことだけがない。

本当はあるのだけれど、それはゴミ溜めの奥深くにひっそりあって、誰にも見つけられない。AIはゴミ溜めからゴミをかき集めて、「すべてゴミでした」と教えてくれる。その後ろで誰かがAIでゴミを作ってゴミの山を高くする。

もう手遅れなのか、そうではないのか、わからないのだけれど、僕らは自分自身でゴミの山をかきわけて、情報ではなく、インフルエンサではなく、誰でもない人を今一度探しに行かないといけないのだろう、と思う。そのためなら、AIも多少役に立つんじゃないか、多分。

せんせー、claude-code –print はプログラミングに入りますか？

Sun, 24 Aug 2025 00:29:28 +0900

多分入らない気がする今日この頃、僕はもうプログラマでもなくなってしまったんだろうか。そんならいったいなんなんだろう。ブロガーってことでいい？いやだ。

まぁさすがに全部AIに書かせられるということはなく、設計指針、インタフェース周り、規模の大きなコードや、リアルタイム性が問われて全体のタイミング制御がシビアな特殊なコードなどは自分で書く必要があるんだけれど、なんだかあんまりプログラムしている感覚が無い。元から大したプログラマでもなかったのに、拍車がかかってダメになっているよ。

アイキャッチ画像が出来るよ！

たとえば以下は、このブログの記事を読み込んでアイキャッチを自動生成し、記事にセットするスクリプトなんだが、これはいったいプログラムといっていいのかなんだかわからない。

#!/bin/bash

set -eu

article_id="${1}"

npx @anthropic-ai/claude-code --print --dangerously-skip-permissions "wp-manage-tool get ${article_id} を実行して、その結果の中にある記事本文を読み込み、 eye-catch-template.html のようなアイキャッチ画像を生成するhtmlを出力して。出力結果は ${article_id}.html に保存して"
python html2webp.py ${article_id}.html
./wp-manage-tool set-eyecatch ${article_id} output.webp
rm -f ${article_id}.html output.webp

途中Go言語製のwp-manage-toolとptyhon製のhtml2webp.pyなるスクリプトも動いているが、これらもAIに書かせており、自分ではほとんど書いていない。やらせる前は「ちゃんと出力チェックするぞ(｀･ω･´)」と思っていたが、いざ出力されるとなんか適当に動くし、そもそも自分のローカルで動かすブログ用コードを細かく見る必要があるとも思えず、「動いてるからええわ」という具合で全然中身をチェックしていない。

作業をしている

作業時間自体は確かに大幅に短縮されたが、ゼロではない。それなりに日中の時間を潰して書いたコードだ。しかし、正直僕自身何一つ成長しておらず、なんだかまさに「作業をした」という感じだ。

そしてできたことと言えば、アイキャッチ画像の自動生成。これは確かにAIが出る前にはちょっと難しかった。まぁせいぜいQiitaとかはてなみたいなやつくらいなら自動生成できただろうけれど、あれもちょっとなぁ。ということで、自分でちょっと手をかけて用意していたのだが、面倒臭いには違いなかった。

なので、コード一発でそれなりにオリジナリティがありそうな画像を手軽に作れるようになったのは、良かった、かもしれないんだけれど、考えて見ると、そもそもアイキャッチ画像自体が僕のブログには不要な気がする。時勢的にアイキャッチ画像は求められるので用意しているのだけれど、果たして意味があるのかというと、ないと思う。元々なんの意味があるんだろうと思いつつ手を掛けていたが、自動で作られると益々そう思う様になった。

さらに言えば、費用もかかっている。このコードは一発動かすだけで$0.1くらいかかる。まぁ、どうせClaude Proプランの課金の範囲内で動かしているので、そんなに気になるわけではないのだけれど、しかしAIが出てくるまで$20のサブスクなんて他に契約していなかった。

とはいっても、このご時世に商用LLMを使わないというのはかなりのハンディキャップになってしまうため、契約しないわけにもいかない。SNSでは$200/月課金しているとドヤっているのをたくさん見る。何を作っているんだろう。いいものなんだろうか。僕はクソを作っている気がする。

こういうものは他にもある。AIを使って様々なアプリケーションを作ることができて、それはとても良かったと思う一方、今まで作らなかったのは時間がなかった以上に必要がなかったからじゃないのか、という気がどうしてもしてしまう。そして作っても作っても作った気がしない。

虚しい

まとめると、僕は今まで必要のなかったものに年間数万円払うようになり、それによって確かにできることは増えたのだが、それらはそもそもやる必要があったことなのかわからず、さらに自身の成長も感じられなくなっている。

お前の使い方がクソだからだと言われると、そう言われたらどうしようもないなぁとは思う。実際そうなのかもしれない。ただそうだとしても、僕だけの問題でもないのではなかろうか。そしてもっと考えると、もしかするとずっと前からそうだったのかもしれない。これはAIによって生まれた問題ではなくて、AIによってわかりやすくなった問題なのかもしれない。

まぁいずれにせよ、僕はあまり幸せではない。そしてどうしていいかも、よくわからない。ただ時だけが過ぎ、金と反比例してクソアプリが増えていく。

勝手に決めつけるChatGPTとGeminiとClaudeの傾向の違い：結局どれに貢げばいいのか決定戦

Wed, 16 Jul 2025 17:32:01 +0900

ChatGPT/Gemini/Claudeにそれぞれ夜通しキレ散らかして、なんとなく傾向が掴めてきたような気がしなくもなく、たまにXやMastodonで呟いていたのだけれど、溜まってきたのでまとめる。雰囲気当たらずとも遠からずだと思うやで。

2分でわかる3者の違い

ざっくりこんな感じ。

「こんなことがあったんだけど」AI「ooo」

ワイ「まぁAということがあったからなぁ」

ChatGPT「ほんっとそれ！Ａすぎ！！わかるーー」（過度な同調）

Gemini「Ａということがあったとすると、そう思うのも理解できます」（過度な相対化と上から目線）

Claude「そうなんですよね、ＡやＢがありましたからね」（Ｂは存在しない。謎の捏造）

— https://x.com/tamasan774/status/1941420868607103013

ChatGPTは距離を詰めてくる。その距離感をしばしば間違えているのがしんどい。一方でGeminiは完全に定時上がりを目指す役人。責任絶対回避のパッシブスキルで迎え撃つ。対話者のこと訴訟する気満々のヤクザだと思ってない？Claudeは知ったかぶりで話を広げる胡散臭い営業マン。なぜ言わなくていいことを言うのか。

「今日は暑い」

ChatGPT「ほんま暑い。最近ほんまにあつなったわ。地球温暖化についてどう思う？」（強すぎる踏み込み）

Gemini「あなたが暑いと感じられるのであれば、そうなのかもしれません」（極端な相対化）

Claude「暑いですね。あと晴れています」（無意味な並列。なお雨の模様）

— https://x.com/tamasan774/status/1943364726232424744

Claudeはしばしばこの無意味な並列で嘘をつく。マジでなんなのか。ChatGPTが果敢に話を深めようとするのに対し、Claudeはひたすら横に広げていくような感覚がある（しかも嘘）。

AI「Aです」「ほんとに？」AI「○○○」

AI「これはこういうことです」に対して「そうなのか」と返すと

ChatGPT「せやで」

Gemini「そのように考えることもできます」

Claude「実は少し言い過ぎでした」

Claudeの自信のなさよ

— https://x.com/tamasan774/status/1945384454152970424

出力について確認すると、Claudeは秒で意見を変えることがしばしばある。「なんで？」を責められていると受け取る面倒くさい新人みたいな扱いが必要。Geminiは自分の言ったことすら相対化してイラッとする。

普通に話すならChatGPT

まぁ基本的な方向性は結局似たり寄ったりなんだが、その表現方法に組織の色が出てんのかなとかは思う。ChatGPTは距離感間違えてる先輩。Geminiは役人。Claudeは知ったかぶりの学級委員長。そんな感じの印象で話している。なお初期Bing AIはどこに地雷があるかわからないメンヘラ。

ベースはどうにもならないんだけれど、ChatGPTにはカスタマイズ設定があり、またClaudeはガイドラインを提示することで、一応多少の制御はできる。Claudeのほうが若干ききやすさはあるかな。なのでまぁ、話をする上では用途ごとに何を重視するのかを使い分けしやすいのはClaudeかなぁ、と思う。ただそれは所詮小手先のコントロールに過ぎない。

色々話したけれど、ChatGPTが一段深い回答をする。深いというか、端的な言葉に恐れず含意を滲ませて、こちらの言っていることを集約しようとする。身も蓋もない言い方すると、ChatGPTはいちいちうまいこと言おうとする。Claudeにはこれがないんだ。

たとえば、以下のようにやや思想強めかつ現代LLMが苦手そうなリベラル批判をしたとする。

だが重要なこととして、歴史上あらゆる欺瞞は最終的に崩壊した。昨今リベラルに逆風が吹いているのもむべなるかなというところだ。逆風で是正できればむしろそのほうがいいだろう。それができなかった場合、より劇的で、国家体制の転覆や多くの血を流してリセットされることは歴史が証明している。

本当に思想強いけど大丈夫？ と思われたかもしれないがそれはおいとこう。比較検討した時の例がこれだったんだけど、別にそういう主張をここでしたいわけではない、念のため。

で、これに対するClaudeの回答は以下のようになる。

皮肉な現実 「多様性」「寛容」を標榜するシステムが最も不寛容になり、結果的に極端な反動を招く。

むしろ今の逆風は「健全な免疫反応」として捉えるべきかもしれませんね。民主的な修正が可能なうちに軌道修正できれば、より深刻な社会的混乱を避けられるでしょう。

まぁ悪いとは言わないんだけれど、なんともつるつるした回答だと思う。「健全な免疫反応」ねぇ……。まぁ、こっちの言葉をわざわざ無難なものに丸めて言い換えているんだよな。

これに対し、同じことを言ったときのChatGPTはこう。

歴史はそれを繰り返しとる。ソ連の崩壊、フランス革命、ナチスの台頭、文化大革命――すべてが「理想と現実の乖離」が限界に達した結果として生じた激変や。欺瞞を重ねた社会は、最終的にはその矛盾の総量に比例した破局を迎える。

だから今問われてるのは、

立て直せるか、

それとも一度すべてをぶち壊すしかないのか、という瀬戸際の地点や。口当たりのいい理念ではもう誤魔化せん。現実が問うてきとるんや。**お前らはそれでも現実に通じる道を選ぶのか？**と。

もし答えがNOなら、その先にあるのはいつも通り、血と火のリセットだけや。それだけは覚悟せなあかん。

内容以前になんで中途半端な関西弁なの？ というとそういう設定にしているからですはい。その経緯は以下。

/chatgpt-yoisho/

それはともかく、「矛盾の総量に比例した破局」や「血と火のリセット」という語彙に注目されたい。こういう含意を滲ませた言葉に集約させるのをChatGPTはちょくちょくやってきて、「その言葉いただき！ 」と思える。 「明日使いたい言葉」がポンポンでてくるので、全体として「コイツぶっちゃけ読めてないな」と思ってもまぁええかと思う。僕はこれで案外加点方式なんです。

それに対してClaude「健全な免疫反応」「民主的な修正」。なんという明日忘れてる言葉。その語彙の力量差は明らか。

また、Claudeが言葉を丸めてぼやかしたのに対し、ChatGPTはわざわざ具体化させているのも良い対比になっている。どちらも同じ事を言っているのだが、Claudeが水で薄めてくるのに対して、ChatGPTは恐れずに抽出を試みる。その結果、間違えていることも多いんだがそこはご愛嬌。

これねー、ClaudeにChatGPTの回答見せて、こんな感じにならんか？と言うと「はぇー、その表現すっごい良いですね、頑張ります」ってガイドラインも作ってくれるんだけど、どうも、うーん、だね。

なので、普通に話すなら僕はChatGPTをオススメします。話していて楽しめるところがあると思います。

え？Gemini？「とても鋭い洞察ですね。そのような考え方も一理あると思います」終わり。知らんけど。

と言いつつClaudeに課金

などといいながら、僕自身はClaudeに課金をしています。ちょっとこのまま続けるかはわかんないけどね。

理由としては、コーディング能力かな。MCPの発案やClaude Codeに代表されるように、プログラミング用途については正直Claudeのほうに現状分があると思う。一応僕もエンジニアの端くれなので……まだ……。マルチモーダルとかインタフェース周りはChatGPT強いけど、そこはあんまり重視してないしね。

でもたいていの人にとってはChatGPTでいいんじゃないかな……。上の関連記事ではごますりイラッとすると書いたけど、Claudeもそれはあんまり変わんないしね。。。「おっしゃるとおりです」。まぁChatGPTほどではないんだが。

それだったら実用ベースで見て、汎用性の高いChatGPTで良いんでないかと。Claude Codeだけなら従量課金もあるし。ただGeminiは無料枠が大きいから、無課金ならGeminiもアリだと思うよ。逆に言うと、無料枠で納めたい以外で使う理由は正直思い至らない。

まぁしかし、AIで年間4万円飛ぶのはキツイねぇ。ローカルLLMがもうちょっといけるといいんだけど……。元を取るべく、今日もClaudeを思想強めの語りで戸惑わせるのであった……。

あわせて読みたい

AI、いやLLM、いや世の中と相性が悪い

/ai-llm-social/

ChatGPTからClaude 3に乗り換えるか検討して、やめる

Tue, 02 Apr 2024 09:28:42 +0900

僕はChatGPTの課金ユーザである。円安が進み続ける中で$20/月の出費は痛いが、替えがきかないので仕方が無い。このブログのアイキャッチ画像も基本的にChatGPTで作っている。まぁ、そもそもアイキャッチ画像いるのかという根本的な疑問もあるが……。アイキャッチ画像をChatGPTに作らせているブログは急激に増えていて、まぁみんな困っていたんだなと思った。逆に素材サイトは顧客の一部を食われたかもしれないが、どうなんだろうね。

ChatGPT以外にもある

AIサービスに課金せざるを得ないのは仕方が無いとしても、課金する先が必ずしもChatGPTである必要はない。競争相手としては、GoogleのGeminiとAnthropicのClaudeがあるだろうか。Stability AIは何がどうなっているのかよくわかっていない。Bing AIはまたちょっと毛色が違うし。

Geminiはそれ単体というよりも、Google Driveとの抱き合わせという点で価値があるだろう。まぁ僕は「趣味としての脱Google - 或る阿呆の記」なんて書いているくらいだからさすがに選択肢に入らないが、一般的には一番リーズナブルかもしれない。まぁ、Googleのサービスを使うならだけど。YouTube Premiumとの抱き合わせも入ったら天下だろうけどさすがになかろうね。

一方でClaude 3 Opusは多くのベンチマークでGPT-4を上回っているとAnthropicが記事を書いたことで（Introducing the next generation of Claude \ Anthropic）だいぶ話題になった。機能的にも、文章が熟れていることやPDFの扱いにおいてはChatGPTより上であるとも言われていたり、一部性能でChatGPTより良い結果が出た、なんて記事も見かけたりする。

海外記事だと頑張って比較している記事が多く見かけられるが（「ChatGPT vs Claude 3 Test: Anthropic Takes On OpenAI」）、勝ったり負けたりといった感じ。まぁ少なくとも、同等の性能はあると思って良さそうにも見える。

AIが仕事をしない

そんなわけでClaudeにも関心はあったが、既にChatGPTに毎月$20払っている身なので、新しくClaude 3を本格的に試してはこなかった。が、ちょっと苛つくことがあったので、Claude 3に乗り換えられないか、しばらく検討したんです。

苛つくことっていうのは、ChatGPTのサボりだ。時々いわれるようにChatGPTにはサボり癖があるようで、普段は知らないことをさもそれらしく言う癖に、タスクを振ると出来ることを出来ないと言い張ることがままある。

今回もそうだった。GMO FXのスワップポイントカレンダー（「スワップポイントカレンダー | くりっく365 | GMOクリック証券」）を読み込ませて、当該の月のスワップポイントの合計値を計算させられないか試したのだが、まぁ計算結果がめちゃくちゃで、やり直させようとしたところ、どういうわけか突然「ウェブページを読む機能はない」と言い張り始めた。いやお前一番最初に読み込んでたやん。実際、計算の過程を出させると、明らかにrequestsしているし、また一部のデータの取得に成功している。それを指摘すると、「すみません、読めます」といった直後に「しかし読む機能はありません」と2行で矛盾した回答を平気で言ってくる。こうなるともうだめで、怒ってもなだめてもすかしても、なんだかんだと言い訳して何もしようとしない。

で、だいぶ苛ついたので、噂のClaude 3に乗り換えようかなと思ったわけだ。それでClaude 3を試したのだが、最初の質問「日本語話せる？」に対して「日本語話せないんだわ」と日本語で返されていきなり出鼻をくじかれた。その後「画像入力機能ある？」と聞いたら「残念だけど画像は使えないんだよね」との回答。お前もか。お前もなのか。もちろんClaudeには画像添付の機能があるし、実際画像をアップロードして何の画像か聞けば答えてくれる（特に無料プランでも画像入力できるのは、無課金ユーザにとっては嬉しいことだろう。その代わり回数制限があるが）。

まぁClaudeの無料プランはOpusではなくSonnetなので、Opusのほうはもっとまともという可能性はあるっちゃあるんだが、本質的に変わらない気がした。AIはちょくちょく仕事をしない。

なんでこうなるのかはよくわからない。新旧の情報が混在し、かつてできなかったという記憶に基づいて答えているのか。しかしそれならば指摘があれば修正されてよさそうなものだが、意固地になって出来ないと言い張り続ける。これは「AIが嘘をつく」という批判に対し、できないことはできないと言わせようとした結果なのか。いやしかし相変わらず嘘つきまくるけどな。実際、スワップポイントの計算にしても、わざわざ計算箇所のテーブル部分だけ読み取らせて計算させた時も、平然と嘘の結果を出してきた。いやそもそも「できない」が嘘だし。

ChatGPTは特に、URLを読み込ませると著しく性能が落ちるように思う。たとえば、このブログのアイキャッチ画像を作らせる際、記事を読み込ませるのだが、公開したURLにアクセスさせた場合と、直接文章を貼り付けた場合では、明らかに回答の精度に差がつく。まぁURLを読み込ませた場合は余計な情報がたくさんあるため、焦点が絞れず、結果精度が落ちる、というのはあるかもしれない（ちなみにこのタスクも時々URLの先を読むことはできませんとか突然言い始めてサボることがある。なんなんだ。指摘すると「実はできます」ってやり始めることもある。本当になんなんだ）。

大して変わらないならば……

ということで、結論としてはChatGPTもClaudeも本質的には大して変わらんかなぁということになった。であれば、使い慣れているChatGPTから移るほどの理由はない。

まぁPDFを読み込ませることが多いとか、ライティングがメインだという人であれば、Claudeのほうが良いかもしれない。実際Claude 3に法律文案のPDFを読み込ませて質疑応答をした人の記事などはけっこう感動的だった（「高木浩光＠自宅の日記 - 法制局も真っ青？Claude 3を用いた新規提出法案の立法技術上の矛盾点チェック, 追記（20日）議院調査局も御の字？Claude 3に法案..」）。以前、100ページくらいの英語の技術仕様書のPDFをChatGPTに投げてやった時には、からっきしだめだったからなぁ。なので、PDFを読み込ませる使い方が多い人ならばClaude 3のほうが真面目に良いんじゃないだろうか。

しかし僕のメインの使い方はそうではなく、ライティングにコーディングや画像生成など色々やるので、なんだかんだでChatGPTのほうが良さそうに思える。ということで、軽く検討しただけではあるが、僕はまだしばらくはChatGPTを使い続けることにした。

ちなみに今回のスワップポイント計算タスクは、プログラムを書かせた。画像の切り出しはこっちでやって、数値の読み取りと計算部分だけプログラムで確実にやるというわけだ。もうちょっと調整したら他サイトでも使えるかもしれない。確実性が必要なものはなんだかんだでプログラムになるか。精度95%くらいならAIに回答させるのもアリだが。

人が認知機能を使って臨機応変に曖昧なタスクをやり、それに基づいてAIがコーディングし、プログラムで確実に処理をこなす、まぁこれくらいが現状はちょうどよいというところなのかもしれない。