2026/06/02(火)LLMに対する最近の思いとか過去の考えとかの整理
これまでいろいろ書いてきたが、それらの総括的なものを吐露していく。
金銭面での問題
LLMは金が掛かる。特にAnthropicをBANされて、Poeから叩いている私はなおのこと金が掛かる。
レートリミットがないので無限に使えるのを強みと言いたいが、そんなのはすっぱい葡萄の話でしかない。
またクラウドの登場からずっと言われていることだが、デジタル赤字の根源の一つにもなっている。
LLMを使えば使うほどAnthropicやOpenAI、Googleなどに富が流れ出ててしまうので、これは国としてみた場合に深刻だ。最近はデジタル小作人とかとも言われている。
とはいえ、正直これは仕方がない面もあり、ぶっちゃけITシステムはコモディティ化しやすく、局所的なところに集中せざるを得ないと思っている。例外的に中国だけは国内で回せているが、最前線とまでは言えないにせよ自前で実用水準を回せているが、これは中国の地政学的な問題が大きく影響していると考えている。
何故なら中国はその体制的に、アメリカのIT資産にアクセスできなかったり、仮にできてもある日突然禁じられるリスクがある。それなら中国の国家運営にフィットし、あわよくば普及させることで他国を操作しうる国産モデルの開発を好み、そのためなら予算を惜しまないだろう。だからこそ、一定のLLM開発が成立していると言える。
何故なら、もしアメリカを超えるモデルを作って普及させられれば、アメリカがやっているように「使わせない」ことで圧力をかけたり、制裁の脅しに使えるからだ。当然、そこから情報を抜き取って中国に有利な形で活用することもできるだろう。実際、中国が怪しい振る舞いをしているのは、Huaweiの問題や、宇通のバスに仕込まれていたバックドアからも明らかだ。
一方、日本にこれはできない。ドイツやイタリアをはじめとした欧州諸国だってそうだろう。アメリカ以外の国の大半には自国でフロンティアモデルレベルのLLMを作るだけの技術もリソースも恐らくない。何故なら現状フロンティアモデルは中国ですら到達できていないからだ。中国はフロンティアモデルを使ってLLMをトレーニングしていることが知られており、AnthropicもDetecting and preventing distillation attacksでそのことを公表している。要するに、中国でさえ自力でまともなモデルを作るだけのリソースを持っておらず、他人の成果物を横取りすることしか出来ない訳だ。
だが本質はそこではない。仮に世界各国が作り合ったとしても、同じようなものが万国に散らばっていても意味がない。すべての国が中米のように敵対しているわけでもない以上、いずれどこかに収束するのは自明であり、結局やる意味がないと言える。
開発時の認知負荷の重さ
AIを使った開発に取り組み始めてみた雑感で軽く触れ、Value-DomainのDNSを操作するユーティリティを更新したで実感したことだが、LLMを書いたコードをレビューするのは大変だ。
何せ一気に大量のコードを書いてくるし、もっともらしいコードを書いてくるので非常に疲れる。これが人間の書いたコードなら荒探しをしたい気持ちなどが湧いてきて徹底的に見たりするような気がするのだが、LLMは人間ではないのでそんな気も起きない。だって、間違いを指摘しても学んだり成長しないから、意味がない。
AIコーディングのレビュー負荷に関することは色んな企業のテックブログでも言われていると思うが、正直大量に書かせてしまうとレビューはほぼ無理だと思う。
先日読んだテストコードの意味がないという記事もまさにそれに近い話だろう。とはいえ、なかなか難しい話だとは思う。
個人的には実装からテストコードを書かせるのであっても、正常ケースと異常ケースを網羅的に書かせることができれば、以後の修正でテストが落ちれば、それは問題ないと感じる。但し初回作成時に実装コードを破壊して、意図したとおりにテストが落ちることの確認はしておいたほうが良いだろう。とはいえ、LLMに書かせているとそれすらおっくうになってくるのが個人的には困りものだ。
やるとしたらモジュラモノリスのような小さなモジュールを集めた構造にし、それを書かせれば多少はマシになると思う。でもそれって人間書いてもいいですよねってなるわけで、何ともな感じもある。
他にもLLMが書くと人間が正しく認知しないとか、人間が手で書いていればハマった部分や苦労した部分などで記憶に残り、バグが出たときに「あそこかも!」という当たりが付いたりするが、LLMに書かせていると、まず無理だろう。
当然LLMでも特定はできるだろうが、LLMは金が掛かるし、ソースを精査する時間も長い。チューニングで何とかなるといっても誰がチューニングするんだという話になってくる。
思考力の低下
よく昔はできたが今はできないということが語られると思う。例えば元開発者のマネージャーが、手を動かさなくなった結果、開発方法を忘れたとか、そんなことを話したりする。やっていなかったことができなることは自然なことだ。日々やり続けることによってのみ筋力が維持されるのと同じことである。
同様にLLMを使っていれば、LLMを使う力は養われるだろうが、LLMに文章を書かせていれば文章力が、LLMにコーディングさせていれば設計力や実装力が失われていくのは自明のことだろう。
果たしてこれはいいことなのかどうかというのはとても思う。たぶんLLMに漬かりすぎていると早期にボケるのではなかろうか?
登山中に電波が届かない環境や、会議のファシリテートなどで「LLMを使わないとわからない」なんてことは言いたくないものである。山の中は電波が届かないし、悠長にやっていてはバッテリーがなくなり、日が暮れる。ファシリテーターが一々LLMに聞いていては会議が進まない。
またLLMの技術を使ったブラウザ操作や、ECサイトでの買い物なども出てきており、この辺りでは意思決定の一部さえLLMに委ねており、人としてそれでいいのかとも思ってしまう。何も考えられなくなりそうだし、人としての意思とかは残るんだろうとか。
2024年12月20日には兵庫丼に次のことを書いていたが、まぁこんなのは今となってはもうどこでも起きていそうである。
「AIが提案したので実装しました。なんで動くのかは知りません」
「AIの提案なら大丈夫でしょう!レビュー通過です」
みたいなやり取りは全国でどのくらい起きてるのだろう
人類そのうちAIに質問して出てきた返事のとおりにしか行動できなくなるのではないかみたいな心配をしてしまいがち
LLMプロバイダに生殺与奪の権利を握られる
AnthropicなどのLLMプロバイダは規約違反した人物をBANすることで有名だ。実際に私もAnthropicをBANされている。
BANされると使えなくなるのでBANされないように忖度が始まるが、使わなければこんなことは気にしなくても済む。まぁ忖度したところで企業レベルでBANされてる話も聞くし、そもそも夜職に関わる開発など、BANされるような産業だとどうしようもなさそうだが…。
他にもおむつメーカーがパッケージを見せたところ児童ポルノ判定されたという話もみたことがあるので、何とも難しいことだと思う。LLMはなんにでも使えるわけではないのだ。
LLMは本当のことを言えない
これは何が本当のことか?という話になってくるのだが、LLMは本当のことを言えない。それに対して人間ならそれを言えるという話だ。
では何が本当のことか?だが、人間は生きている間ずっと、連続して何かを経験している。そして経験したことを、自分の言葉として言える。一方LLMは、膨大なテキストを流し込まれているだけだ。知識カットオフ以降のことやRAGで与えられた情報も語れるが、それらも結局は外から与えられたものにすぎない。つまりLLMが発することは、全て他人の又聞きでしかない。要するにLLMの言葉は「隣の田中さんがそう言っていた」と言う噂話を膨大に集めて確率的に確かにした話ということになる。
私は本当のこととは実体験に基づく、その人物だけが言えることだと考えている。「私はこれを見た」「私はこう感じた」、そういった実体験に基づく知識は人間にしかない。例えば昔事故を引き起こした振る舞いを知っていれば、それを止めることができる。いわゆる筋の悪さを語れるという話だ。しかし、LLMにはこの経験そのものが存在しない。だからLLMは、世界についての情報をいくら正確に語れても、「私が経験した」という意味での本当のことを、ただの一つも言えない。
もちろん、その経験が実際に役立つとは限らない。人間の側の知識が間違っていたり、古すぎたり、今回のケースとは違ったりして、役に立たないこともあるだろう。それ故にLLMのほうが正確な情報を出すことも少なくない。
しかし、LLMの情報がどれほど正確でも、LLMの言葉は誰のものでもない又聞きのままだ。そして人間の言葉には、たとえ間違っていても、その人が実際に経験したという、唯一無二の価値があると考える。
そう考えると人間はLLMの又聞きを聞いて頷いているだけではなく、独自の知見を求めるのがより大切なのかもしれない。他の誰も知りえない、そんな自分だけの体験を得ることができれば、何かになるのかもしれない。
LLMは日々成長しない
人間は基本日々成長したり劣化したりするけど、AIにはそれがない気がする。AIは学習したことをミックスして吐き出すことしかできないので思いつきや閃きと言ったイノベーションは起こせないと思う。
いやまぁ遺伝的アルゴリズムみたいなことすればできなくはないと思うけど、AIは人間に比べると個体数が少ないし多様性にも限度があると思うし、どうしてもどこかに収束していきそうだ。
ということを2023年12月12日に兵庫丼に書いていたので、こちらにも転記しておく。
LLMと話してると疲れる
壁打ちなどでLLMを使うことはよくあると思うし、だる絡みだっていくらでもできるが、割と虚無な話になって時間だけが経ち、無意味な会話になっていて可処分時間がつぶれて疲れただけというのは経験として割とよくあった。
回答に対しても一貫性がなく、生成するごとに違う回答をしてくるので疲れるみたいなところもある。
また基本的にスレッドを分けると過去の記憶は残らないので、以前の話はなかったものとして進むとかもあり、なんと言うか友人とかと思って接していると疲れる気がしている。
これはSNS疲れによく似たLLM疲れについてで幾らか書いているほか、個人的に思うLLMの活用方法についてにもある程度通じることを書いている。
LLMは理想を完全には作ってくれない
自分が作りたいものを100%形作ることにはLLMにはできない。人によっては気に食わず直すこともよくあるだろう。
これは単純な話で、部下にこれを作れと命じたところで微妙に違うものが出てくるのと同じことである。本当に解像度100%で自分が欲しいものを作りたい、こだわりや矜持を持ちたいなら、それは自分で作るしかなく、LLMに作らせる時点でそこに妥協が生まれるのだ。
あとがき
LLMそのものは便利だが、人間の手に余りすぎるし、金はかかるし、人の思考を奪ってくる割に、熟練の人間の思考より早く動くわけでもないので、常に使えるわけでもない。それに頼りすぎると人間性が失われそうでもある。そして何よりもそこに拘りは残らない。
Value-DomainのDNSを操作するユーティリティを更新した記事のあとがきにも次のように書いたが、きっとLLMに頼りすぎず、自分で何かを成し遂げていけたらいいのだとは思う。問題は今の時代にそれがどれほど実際に可能か、みたいな話ではあると思うのだが、このままではLLMの言いなりになって、LLMの単一思考によるコモディティ化と先細りしかないようにも思うし、デジタル赤字とかも問題だと思うので…。
ボケ防止のためにはAIに頼らず、自分の手を動かすのも大切なことだと思う。こういう話では、よくそろばん論を持ち出して、そろばんを使わなくなったが人類は劣化していない、電卓があるみたいなことを言う人がいるが、実際問題珠算ができる人は非常に速い速度で暗算ができ、頭の回転も速いとされているので、電卓があるから優位と言われれば、それは違うと思う。例えば電卓を取り出す時間で計算が終わっていたり、物事を予測しやすかったりするわけだ。
なんと言うかLLMを主とせず、あくまで補助的な役割で使っていければ、人の判断や軸が残るので、良いのではないだろうか?とかは少し思った。
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
入出力例
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
入出力例
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よりはよいと思うので、お金を節約したい人にはオススメかもしれない。
2026/02/03(火)最近のLLM活用状況について
投稿日:
さて、世の中ではAI開発全盛期という感じで、とにもかくにも全盛期という感じになってきているので、今回は私自身の活用状況について書いていく。
あらかじめ断りを書いておくと、世の中の人ほど活用できてはいない。
今のところは簡単なツール作りや、実装の部品作りといった、小規模用途に利用していて、開発工数の圧縮には便利だと感じている。
開発でLLMを使ってみた事例
仕事ではなく趣味の開発の話。
事例1:MarkdownをYAMLに変換するスクリプトの作成
私は職務経歴書をWordで作っているのだが、WordそのままだとLLMに読ませるのはしんどい。
そこでLLMに読ませる形にしたいが、Markdownはそこまで構造的ではない。なのでYAMLにすることにした。
単刀直入にやるならWordファイルの中身をLLMに渡し、「これをYAMLにしてください」というのが恐らく一般的で、最も手っ取り早いだろう。
しかし私はそれを避けた。私の経歴書はかなり長く、LLMがどこかでミスをしていた場合、それをレビューするのは至難の業だからだ。例えば経歴の一部がLLMによって書き換えられていたりするリスクは拭えない。
なので私はLLMにWordファイルから切り出したプレーンテキストをYAMLに変換するスクリプトを書くことを依頼した。これであればレビューするのはコードそのもので良いし、静的コードは基本的に文脈を見て判断して勝手に書き換えることはしないし、仮にそんな処理があったとしてもそんなものはコードを見ればわかるからだ。
作らせたのはSESや受託系の経歴書にありがちな、死ぬほど繰り返される案件ごとの経験セクションだ。職務経歴書の中でも職務要約だとか、活かせる経験みたいな単純な文章セクションは手作業でどうにもなるので、そこは手で移植すればいいが、繰り返しはしんどい。
というわけで次のようなものを書いてもらった。これで9割はうまく変換してくれたし、後はざっと目検して行って変換にしくじっている部分を直して対応した。
要はLLMに変換させるのではなく、LLMに変換ツールを作らせると間違いが少ないという話だ。
#!/usr/bin/env perl
use strict;
use warnings;
use utf8;
binmode(STDIN, ':utf8');
binmode(STDOUT, ':utf8');
my $input = do { local $/; <STDIN> };
# 複数のプロジェクトを分割(日付パターンで分割)
my @projects = split(/(?=\d{4}\/\d{2}\s*-\s*\d{4}\/\d{2})/, $input);
print "projects:\n";
for my $project (@projects) {
next if $project =~ /^\s*$/;
parse_project($project);
}
sub parse_project {
my ($text) = @_;
# 時期を抽出
my ($period) = $text =~ /^(\d{4}\/\d{2}\s*-\s*\d{4}\/\d{2})/m;
return unless $period;
# タイトル(時期の後の行)
my ($title) = $text =~ /^\d{4}\/\d{2}\s*-\s*\d{4}\/\d{2}\s*\n(.+?)(?:\t|規模|$)/m;
$title //= '';
$title =~ s/^\s+|\s+$//g;
# 要員数
my ($members) = $text =~ /要員数\s*\t?\s*(\d+名)/;
$members //= '';
# 役割
my ($role) = $text =~ /役割\s*\t?\s*([^\t\n]+)/;
$role //= '';
$role =~ s/^\s+|\s+$//g;
# プロジェクト概要
my ($overview) = $text =~ /【プロジェクト概要】\s*\n(.*?)(?=\n\s*\n|\n【|$)/s;
$overview //= '';
$overview =~ s/^\s+|\s+$//g;
$overview =~ s/\n\s*/\n/g;
# 主な業務
my ($tasks) = $text =~ /【主な業務】\s*\n(.*?)(?=\n\s*\n|\n【|$)/s;
$tasks //= '';
$tasks =~ s/^\s+|\s+$//g;
# 実績・取り組み
my ($achievements_text) = $text =~ /【実績・取り組み】\s*\n(.*?)(?=\t要員数|\n開発環境|$)/s;
$achievements_text //= '';
# 開発環境セクションを抽出
my ($dev_env_text) = $text =~ /開発環境\s*\n(.*?)$/s;
$dev_env_text //= '';
# 出力
print " - 時期: $period\n";
print " 内容: $title\n";
print " 要員数: $members\n";
print " 役割: $role\n";
# プロジェクト概要
print " プロジェクト概要: |-\n";
for my $line (split /\n/, $overview) {
print " $line\n" if $line =~ /\S/;
}
# 主な業務
print " 主な業務:\n";
print " - $tasks\n";
# 実績・取り組み
print " 実績・取り組み:\n";
parse_achievements($achievements_text);
# 開発環境
print " 開発環境:\n";
parse_dev_env($dev_env_text);
}
sub parse_achievements {
my ($text) = @_;
# 実績項目をパース(タイトル + 説明の形式)
my @items;
my $current_title = '';
my $current_desc = '';
for my $line (split /\n/, $text) {
$line =~ s/^\s+|\s+$//g;
next if $line eq '';
# 新しい項目タイトル(短い行で次の行に説明がある)
if ($line =~ /^(.+?)$/ && length($line) < 30 && $line !~ /。$/) {
if ($current_title) {
push @items, { title => $current_title, desc => $current_desc };
}
$current_title = $line;
$current_desc = '';
} else {
$current_desc .= ($current_desc ? "\n" : '') . $line;
}
}
if ($current_title) {
push @items, { title => $current_title, desc => $current_desc };
}
for my $item (@items) {
print " - $item->{title}: |-\n";
for my $desc_line (split /\n/, $item->{desc}) {
print " $desc_line\n" if $desc_line =~ /\S/;
}
}
}
sub parse_dev_env {
my ($text) = @_;
my %sections;
my $current_section = '';
for my $line (split /\n/, $text) {
$line =~ s/^\s+|\s+$//g;
next if $line eq '';
if ($line =~ /^【(.+?)】$/) {
$current_section = $1;
$sections{$current_section} = [];
} elsif ($current_section) {
# カンマやスペースで分割し、バージョン番号を除去
my @items = split /,\s*/, $line;
for my $item (@items) {
$item =~ s/^\s+|\s+$//g;
# バージョン番号を除去(数字とドットのパターン)
$item =~ s/\s*[\d.]+\s*$//;
$item =~ s/\s+\d+(\.\d+)*$//;
push @{$sections{$current_section}}, $item if $item =~ /\S/;
}
}
}
# 順序を維持して出力
my @section_order = ('言語・FW', 'インフラ', 'ドキュメント', 'CI/CD', 'VCS');
for my $section (@section_order) {
next unless exists $sections{$section};
print " $section:\n";
for my $item (@{$sections{$section}}) {
print " - $item\n";
}
}
# 定義順以外のセクションも出力
for my $section (keys %sections) {
next if grep { $_ eq $section } @section_order;
print " $section:\n";
for my $item (@{$sections{$section}}) {
print " - $item\n";
}
}
}
入力に使ったワードファイルのフォーマットは以下のような内容だ。
[企業情報A]
[案件情報1]
[案件情報2]
...
[企業情報B]
[案件情報1]
[案件情報2]
...
ツールの想定漏れにより一部手修正しているが、低いレビューコストと最低限の手作業で完遂でき、LLMに読ませて分析させられる経歴書を作れたので、結果としてこれはよかった。
事例2:adiaryのMarkdownパーサーへの脚注記法の追加
これは重い腰を上げてadiaryのMarkdownパーサーを脚注記法に対応させたでも書いた内容だ。
端的に言うと既存コードを読ませて部品程度の機能を書いてもらった。
そのまま愚直に書いてもうまく動かなったので、結合する部位などは適当に手直ししているが、これもLLMを使ったコーディングが役に立った一例だ。
ローカルLLMの利用状況
現状ではベンチマークを取るくらいしか出来ていないが、試したことを書き留めておく。
Ollamaからllama.cppに乗り換えようとして失敗した話
Ollamaよりllama.cppの方がCPUオフロードなどのチューニングができるので20〜100%程度のパフォーマンス向上が望めるみたいな情報も見かけたが、GitHubのCUDA対応バイナリを単に叩くだけではパフォーマンスが著しく劣化し、Reasoningの影響で、ただでさえ遅いのが余計に遅くなるなど、全く使い物にならなかった。
調べたところ-nglオプションでGPUオフロードを指定したり、--reasoning-budget 0を付加することでReasoningを防げるらしいがReasoningを防げるかどうかはモデルに依存するらしく上手く行かなかったし、-nglオプションも適切な値が謎だったので諦めた(コンテキストトークン長で変わるらしいが計算ツールがWindowsだとハングしたので調べられなかった)
llama.cppは元々mac用に開発されていてCPUオフロードが標準らしいのでWindowsで使うのは結構大変なのかもしれない。
Ollamaの動きを観察していた感じ、なんかいい感じにCPUオフロードとGPUオフロードを按分してくれてるように見えたので、Ollamaでも別に構わない気はした。
それとCPUに全部オフロードしても実用性は薄いが、それなりの速度で生成してくれるのが分かったのは収穫だった。
もし過去にこれを知っていればメモリ高騰前に128GBにしておきたかったと後悔した。何せ去年の8月に5万だったDDR5の32GBメモリ二枚組が、今や22万と、四倍以上も値上がりしていて、もはや手の出しようがない。
ああ、去年DDR4からDDR5に上げるときに64GBを維持せず、いつものように意味もなくメモリを盛っていれば…。
ローカルLLMの活用方法が見えない
たぶんLLMをチューニングする知識がないとどうにもならなさそう。RAGとかMCPとかLoraを自作できれば夢があるのかも?
30b程度のモテルだとClaude Opus 4.5の足元にも及ばないので、多分何かに特化させないと使いみちはないと思う。
PoeでGLM-7を試した感じ体感そこそこ使える気がしたので120b辺りなら実用性が期待できそうだが、これをまともに動かすにはNVIDIA RTX PRO 6000 Blackwellが必要らしく、こいつは140万円もするし、GMKtec EVO-X2 GMKtec EVO-X2でも実用速度で動くらしいが、LLM以外に使いみちのない端末のために貴重な電源と部屋のスペースを取られるのも困りものなので乗り気にはなれない。
まとめ
現状そこまでバチバチに使えているかといわれると、そこまで使えていないのが正直なところだとは思う。
例えばサブエージェントやスキルといったものや、MCP、RAG、ファインチューニング、Loraといったものは活用できていない。
まぁ徐々に使えるようになっていければいいのかなぁというところで、程々にやっていきたい。
ローカルLLMはまたなんかいい感じの情報が出たら試したい。Poeの利用料金もタダではないので…。
2026/01/19(月)AnthropicをBANされてもClaude Codeを使う方法
投稿日:
何かしらの理由でAnthropicのアカウントをBANされて復活ができなくなった場合にClaude Codeを使う方法。
結論
poe-codeを使う。
poe-codeがあると、AnthropicのアカウントがなくてもClaude Codeを使うことができる。
確認環境
| Env | Ver |
|---|---|
| OS | Ubuntu 24.04.3 LTS |
| Node.js | v24.10.0 |
| Claude Code | 2.1.45 |
| poe-code | 3.0.60 |
やり方
- Claude Codeをインストールする
curl -fsSL https://claude.ai/install.sh | bash - Poeのアカウントを作る
- Poeの設定からPoeのサブスクリプションを契約する。最安は700円
- PoeのAPIキーを取得する
- poe-codeをインストールし、Claude Codeをインストールする
npm i -g poe-code # ここでAPIキーを入れ、モデルを選ぶ poe-code configure claude-code # このコマンドを叩くとpoe用のClaude Codeがインストールされる poe-code install claude-code # このセッションでは普通にclaudeを叩くと使えるようになる claude

トラブルシューティング
claudeを叩くとコマンドが見つからない
本家Claude Codeが必要なため、インストールすることで解消する。
poe-codeによるclaudeは本家のラッパーとして機能しているため、本家がないと動かない。
備考
Poeは従量課金制だが、標準だと自動課金になっていないためPoeの設定から自動チャージを有効にすると勝手に止まることがなくなって便利。
レートリミットは恐らくないので無限に使うことができる反面、放置してると無限に請求されるので気を付けたほうがいい。
またpoe-codeでは、Claude Codeに限らずCodexやOpenCode、Kimiも使えるようだ。Poeは殆ど大抵のLLMがレートリミットなしで無限に使えるため、色々試してみるのも悪くないだろう。











