サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
2025年ランキング
nowokay.hatenablog.com
AIはWikipediaやブログやStackOverflowやOSSのコードで学習してますね。 でもそういった学習材料が、AIのせいで新しく書かれなくなってきてます。 Wikipediaが書かれない けどまず、AIがいろいろ詳しく解説してくれるので、Wikipediaを見なくなりました。Google検索でWikipediaを出してくれるのでWikipediaのサイトに行かなくなったというのはありますが、AIでは事前学習の知識だけで書かれたものは情報の出所がわからず、Wikipediaを意識しなくなります。 また、今までだと何かについて知りたくてがんばって調べたら、それをどこかにまとめておきたくなるので、Wikipediaを更新したりしてました。けど、自分でがんばってないのでWikipediaを更新しようとは思わないですね。 結構名が通った人なのにWikipediaに項目がない、ということも
AIがバイナリを直接吐くのではないかとか、AIのための言語ができるのではないかという話の根底には、プログラミング言語は人間が扱いやすく機械が実現できるよう論理を表現するものでありソフトウェアの本体であるということが共有されてないのかなと思います。 AIがバイナリを直接吐くようにはならない - きしだのHatena AI専用のプログラミング言語は現れない - きしだのHatena AIがコードを書くようになるなら、AIだけに理解できる言語を作ればいい、のかな? - きしだのHatena つまり、プログラミング言語で書かれたプログラムコードというのは、機械を動かすための中間表現ではなく、ソフトウェアの本体であるということです。 そこで表された論理的な意味表現を機械が実現できる形にするのがコンパイラやインタプリタやVMで、そこは置き換え可能です。 アプリケーションの意味表現が大事で、機械を介して
たびたび見かける「そのうちAIが直接バイナリを吐くようになるんでは」という話、原理的に難しいし、できるとしてもだれもやらないし、できるようになったとしてもだれも使わないので、今の仕組みのAIが直接バイナリを吐く未来は来ないと思います。 ここらへんも参照 AIがコードを書くようになるなら、AIだけに理解できる言語を作ればいい、のかな? - きしだのHatena AI専用のプログラミング言語は現れない - きしだのHatena AIが読み書きするコードも読みやすいほうがいい(トランスフォーマの特性の考慮やリーダブルコードについて追記) - きしだのHatena プログラミング言語は人間が扱いやすく機械が実現できるよう論理を表現するものでありプログラムの本体 - きしだのHatena ※ LLMが生成したコードを内部でコンパイラを呼び出してバイナリにするというのは、例えばここにあるようなプログラ
Z.aiのGLM-4.7のコーディング性能が高くて、動かす環境さえあれば自宅でコーディングエージェントが動かせるようになるので素敵です。 日本語表現力も高いので、コーディング以外でも広く使えそう。 GLM-4.7は355Bでアクティブ32Bです。MITライセンスです。どこにもライセンスファイル見当たらないけど。 https://z.ai/blog/glm-4.7 なので、Q4_K_Mで216GB、MLX 4bitで198GBあるので、おうちで動かすとしたらMac Studio 256GB以上ということになり90万円からとなりますが、GLM-4.7-Airがそこそこの性能で出てくれれば35万円のEVO-X2でも動くということになり、期待が持てます。 ところで12月に300Bレベルのモデルが3つ立て続けに出ていました。速度こんな感じ。 モデル サイズ リリース日 プロンプト Thinking
Qwen-Imageは日本語のテキストが書けません。 ところで最近Nano Banana Proがかなりテキストを破綻なく書くようになっていて、どうやらこれは裏でテキストをレンダリングして読み込んでるようなので、同じことをQwen-Imageやったらどうかと試すと、結構うまくいきました。実際はQwen-Image-Editだけど。 ただ、毎回テキストの画像を用意するのは面倒なので、テキスト描画用のカスタムノードを作ってみたら便利だったので共有。 Text Renderer Nodeのインストール テキストを描画して画像化するカスタムノードを作ってます。 https://github.com/kishida/comfyui-text-renderer というかコードはほとんど全部Claude Sonnetに書いてもらってます。10文字くらいフォント拡張子を追加した。 git使える人はComf
Qwen-Image-Editを使ってたら、どうにもうまく画像編集してくれないなと思っていたのだけど、Q4_K_SをQ4_K_Mにしたら断然思い通りに生成してくれるようになりました。 ほとんど違いがないのにこれだけ挙動が変わるのかとビックリしたので、この量子化の違いはなんぞやということも含めてまとめてみました。 画像や動画の生成モデルは量子化の影響が出やすく、そしてVRAMを大幅にはみ出るサイズでも生成時間に影響がないので、メインメモリの許す大きいサイズを選ぶのがいいようです。 2枚入力時のプロンプト追従 Qwen-Image-Edit-2511で「pict1の男性をpict2の女性に入れ替える。」とやってみます。メガネをかけることがあったのでネガティブ側に「メガネ」をいれています。 まずQ8_0。たまに失敗はあるけど、だいたいうまくやってくれます。 生成時間は52秒 ところがQ4_K_S
動画生成のWanというのがいいというのは知ってたけど導入がめんどくさそうで試してなかったのを年末にGGUFで試してたのでまとめ。 生成結果 ということで、まずは14BのQ4_K_Mで試した動画を先に。 Wan 2.2で「the man drinking beer」を指定して3分くらいでこれ。ビールが減ってないけど。 1年半前のOpen Soraだと2時間半待ったものがこれ。ハードウェアが同じなのにすごい。 Open Soraを使っておうちのWindowsで動画生成する - きしだのHatena Google ColabのA100を使ってOpen Solaで2分で「japanese maiko is dancing」で生成したのがこれ。 それがWan 2.2ならおうちのRTX 4060 Ti 16GBで2分でこれです。 FramePackも5秒動画を30分で作ってくれてました。 少ないVRA
大晦日だか正月だかにQwen-Image-2512が公開されましたが、これが「そこらへんにいそうな人」が生成できるということで話題。 ということで4ビット量子化のGGUFと4 step LoRAで動かしてみたので手順をまとめました。 Qwen-Image-2512の詳細はこちら。 Qwen-Image-2512: Finer Details, Greater Realism 生成してみる。 生成した画像がこれ。なんか、いそう。箒が折れてなければ違和感あまりないですね。 プロンプトはこう。 カメラで撮影したスナップ写真。晴れた日の路地裏でほほに手をついて座っているメイドさん。メイドさんは20歳くらいの日本人女性で少し垂れ目のギャル。髪形は明るい茶髪のロングストレート。石畳でレンガ造りの家の前の植栽の横に座り込んでいる。上からのアングルで撮影。カメラ目線。メイドさんは左側に位置している。横には
AIがコードを書くのでプログラマ(or エンジニア)が不要になるという話が出てくるようになりましたね。 けど、プログラマ不要論って、プログラミング言語が現れて以来、10年に1度くらいのペースで表れている話です。10年前の2015年あたりにはちょっと途切れていたというか限定的だったので、久しぶりに現れたプログラマ不要論にみんなビックリ、という状況なんじゃないでしょうか。 ここで「プログラミング言語が現れて以来」と書きましたが、最初のプログラマ不要論は、1960年ごろFORTRAN、COBOLという最初期のプログラミング言語が現れたときに言われたものです。1956年FORTRAN、1960年COBOLという感じで仕様書やマニュアルが書かれたみたいですね。ちなみにLISPが1960年3月、COBOLは1960年4月という感じらしい。 それ以前は直接数値コードを書いていたり、さすがにそれは大変とい
OpenCodeというオープンソースのコーディングエージェントから、GLM 4.7が無料で、しかもアカウント登録もなしで試せたので、やってみました。 コーディングエージェント、便利そうだけど課金がすごそうだし・・・と思ってた人も気軽に試せます。 https://opencode.ai/ インストール インストールはGitHubのほうにパッケージ管理ツールでのインストール方法が並んでるので、好きなものを。 # YOLO curl -fsSL https://opencode.ai/install | bash # Package managers npm i -g opencode-ai@latest # or bun/pnpm/yarn scoop bucket add extras; scoop install extras/opencode # Windows choco instal
久しぶりに、Railsについて「設定より規約だなぁ」という発言を目にして、「規約よりアノテーションがいいし、AIに不利」みたいなツッコミをしたわけです。 ということで、どのようにAIに不利かまとめてみます。 一応、いまのRailsについてはAIがかなり学習しているので、Opusなどではかなり的確に扱えているようです。 なので「AIに扱えるようにならない」という意味ではないです。 規約ベースのフレームワークとは ここでは例えばmodelフォルダの下にUserという名前のクラスを作るとusersというテーブルへのマッピングになる、というような規約の話です。 アノテーションベースであれば、Userというクラスに@Tableというアノテーションを付けるとuserというテーブルへのマッピングになります。ただ、ここでUserというクラスがuserというテーブルに対応するというところは規約ベースになって
NVIDIAから新しいモデル、Nemotron 3 Nanoが出ていました。30BのMoEでアクティブパラメータは3B。つまり30B-A3Bです。 試してみたら、かなり賢いんだけど、コーディングの長いやりとりをしてたら過去のコードをうろ覚えになってて変な挙動をしてました。 どうやら、Transformerの代わりに使ってるMamba 2だとそういう挙動になるみたい。自信がないので、こうやって書いたら、だれかが間違いを指摘してくれるはずメソッド。 追記:30Bモデルの主戦場になるのは、言語処理的な単機能部品だと考えると、長いやり取りは不要なので、かなり強いモデルではないかと思います。また別にブログかきます。たぶん。 Nemotron 3 Nemotronはこちらにブログが。 Inside NVIDIA Nemotron 3: Techniques, Tools, and Data That
LLMにやさしいSui言語が話題だった。 で、「ヤサシクナイヨ」とか書いてたのだけど、それならSui言語にやさしいLLMを作ってみるのはどうか。 LLMにやさしい言語SuiはLLMにやさしくなさそう - きしだのHatena まあ、ファインチューンという金槌を持ってウロウロしてるところにSui言語という釘を見つけたので打ってみましょう、ということで。 データセットを作る 最初はCodeNetのコードをSuiに変換してデータセット作ろうかと思ったのだけど、Suiで書くにはちょっとコードが複雑すぎるのでやめた。 簡単な問題をChatGPTに作ってもらう。 整理して80件になった。まあデータセットとしては少なすぎるけど、今回は小さいモデルを学習させるだけなのでどうにかなるはず。(追記:どうにかならなかった・・) そしてgpt-oss-120bにコードを書いてもらう。 コードはここ。「さくらのAI
LLMにやさしい言語という謳い文句の言語、Suiが話題。 けどこれ、LLMにあまりやさしくなんじゃなかろうか。 https://github.com/TakatoHonda/sui-lang 9月にこういうエントリを書いてます。 AI専用のプログラミング言語は現れない - きしだのHatena ここで理由として挙げたのは、この4点です。 すでにAIは独自の言語を持っている 低レベルな記述にはコストがかかる 意味の記述が必要であることに変わりはない 作っても学習させるのが大変 この4点にあてはまっていると思います。 追記: あと、こういうことも10月に書いてます。 AIが読み書きするコードも読みやすいほうがいい(トランスフォーマの特性の考慮やリーダブルコードについて追記) - きしだのHatena 去年の4月ですが、こういうことも書いてました。 AIがコードを書くようになるなら、AIだけに理
SB Institutionから日本の情報に特化した画像言語モデル、Sarashina-2.2-Vision-3Bが出ていたので試したところ、性能の高さは感じたものの、VRAM 16GBで動かすのがつらかったのでまとめました。 Sarashina2.2-Vision-3B: コンパクトかつ性能が高いVLMの公開 - SB Intuitions TECH BLOG ※ use_cache=Trueつけたら解決!12GBで動きそうです。追記しています。 GradioでのUI とりあえず、いろいろ試すたびにコードいじるのは面倒なので、gradioでUIをつけました。 ChatGPTに「gradioで、画像と短文を入力したら長文が返ってくるシステムのUIを作りたい。実際の処理はこちらで書くので、generate_text(intput_txt, image_pil)関数がある前提で画面構築のスクリ
情報を右から左に流すだけのIT土管はAIに作れるので、その情報たちから新たな価値を生むのが、ITエンジニアの仕事になるのではないかなと思います。 2004年に広まったWeb 2.0は、CGM(Consumer Generated Media: ユーザー生成コンテンツ)という言葉を生みました。 それまでは、広く共有されるコンテンツというのはマスコミのような一部の集団がつくってメディアに一方的に流すものでした。Web 2.0では、ブログやSNS、写真、動画共有など、一般消費者がアップロードしたコンテンツが、広く共有されるようになりました。 日本でも、はてなやmixi、pixiv、ニコニコ動画のようなサービスが始まりました。 こういったサービスは、結局のところ、ユーザーが入力したデータを他のユーザーに表示させる、いわば IT土管 になっています。 それでも、2015年くらいまでは、多数が同時に投
Mac Studioを借りたのでいろいろクソデカ言語モデルを試したところ、GLM-4.5-Airがいいなとなってます。 試したモデルこちら。 モデル パラメータ数 アクティブ thinking 画像 時期 URL GPT-oss 120B 120B 5B o x 2025/8 OpenAI hf link Qwen3 235B-A22B-2507-thinking 235B 22B o x 2025/8 Alibaba hf link Qwen3-VL 235B-A22B-thinking 235B 22B o o 2025/9 Alibaba hf link Qwen3-Next-80B 80B 3B o x 2025/9 alibaba hf link Qwen3 Coder 480B 480B 35B x x 2025/7 alibaba hf link Qwen3 Coder 30
DeepSeek-OCRの仕組みが面白いので遊んでしまっている。 最初に試したときは、純粋にOCRさせてますね。きれいな心をしている。 画像でテキストをトークン圧縮するDeepSeek-OCRがいろいろすごい - きしだのHatena そして前回はランダムな文字列を読ませて誤認識を誘ってみた。 DeepSeek-OCRにはランダム文字列が読めない - きしだのHatena もう2つ、弱点ぽいところをついてみる。 その前に、DeepSeek-OCRの構造を確認。 https://arxiv.org/abs/2510.18234 ここで、DeepEncoderがSAM->Conv->CLIPってなってるのがキモ。 SAM(Segment Anything Model)は、画像の領域分けをする仕組み。 GitHub - facebookresearch/segment-anything: The
DeepSeek-OCRの精度が高くて驚いたところですが、仕組み的にランダムな文字列での認識率がかなり落ちるんではないかと試してみたところ、やっぱりかなり悪かったです。 DeepSeek-OCRについてはこちら。 画像でテキストをトークン圧縮するDeepSeek-OCRがいろいろすごい - きしだのHatena DeepSeek-OCRは、画像をトークン化したほうがテキストをトークン化するより情報圧縮できるんでは、というアイデアを試すために、トークン化した画像をテキストに戻してみたらOCRとして精度があがった、というものです。 ここで、「画像のほうが情報量が多いのにトークン化したら容量増えるのでは?」ってなりますが、情報量が多いのは画像を画像として復元する場合で、画像についてお話するために必要十分な情報としてであればそこまで多くならないはずです。 テキストのトークン化は、よくある文字の並び
おとといくらいにDeepSeek-OCRというのが出てました。 https://github.com/deepseek-ai/DeepSeek-OCR ただのOCRじゃなくて、「テキストを画像にしたほうがトークンサイズを小さくできるのでは?」というのをやっていて、テキストを画像にしてトークン化したものをテキストトークンに戻すというのをやってたらOCRになったという感じですね。 LLMの開発効率化に革新? 中国DeepSeekが「DeepSeek-OCR」発表 “テキストを画像化”でデータ圧縮:Innovative Tech(AI+) - ITmedia AI+ 中身的には、3Bでアクティブパラメータが0.6BのMoEモデルに0.4Bの画像エンコーダーを載せた画像言語モデルです。 導入や使い方は、モデルのページに書いてあります。 何も考えずに最新のTransformers 4.57.1を入れ
AIが読むんだから読みやすくする必要はないんでは、という話が流れてきた。 けど、実際にはAIにも読みやすさは大事だと思う。 データ形式によって、そのデータに関する回答精度がどうかわるかという調査がある。 Which Table Format Do LLMs Understand Best? (Results for 11 Formats) HTMLまでの上位5形式はキーワードによってレコードが区別される。JSON以降は記号や改行によってレコードが区別される。また、上位4形式ではキーと値が一緒に書かれる。 このように、表現形式でAIによる読み取りの精度は変わる。GPT-4.1-nanoなので失敗しやすいということはあるだろうけど、どう書いても同じというわけではない。 OpenAI公式のGPT-5コーディングチートシートでも、構造はMarkdownよりXMLがいいと書いてあるし。というか、恐ら
Claude Sonnet 4が出たときにいろいろゲームを作ってもらっていたのでまとめてみた。 あと、これって著作権どうなるんかなって考えてみる。 あ、ゲームいっぱい作ってると10個目くらいからアイデア枯渇し始めるので、最初に作ろうと思ってたものを作りきってからが勝負だなーみたいなことを思いました。 1. マリオ 試しにやってもらったら一発でいい感じに作ってくれたので、いろいろ試したくなった。 敵がいてブロックがあってコインもある。 javaのswingでリアルなマリオのようなゲームを作って。 1ソースで完結して。 背景もかわいいほうがいい。 ところで、著作権法でいう「著作物」は「思想や感情を創作的に表現したもの」です。 けど、このプロンプトは「創作的に表現」とは言い難い。特定のゲーム名をだして、どういうルールになるか完全にSonnetに任せてます。調整もしていないので、著作権の主張はでき
AIが賢くなると、AIにわかりやすく人間には理解困難なプログラミング言語が出てくるのでは、みたいな話をよく聞きます。 ただ、次の点から、AI専用の言語は現れないだろうなと思います。 意味の記述が必要であることに変わりはない すでにAIは独自の言語を持っている 低レベルな記述にはコストがかかる 作っても学習させるのが大変 意図の記述が必要であることに変わりはない プログラムを書くときには、「ここを3回繰り返そう」とか「この一連の処理の塊を、この部分だけパラメータで変更可能にしつつまとめよう」とか「xとyをまとめて扱うようにしよう」といった意図をもって処理を書きます。そうすると、その意図が直接書ける言語のほうがいいです。 また、ここでは整数だけ扱うとか、文字列を扱うとか、xとyをまとめたデータを扱うとか、そういったデータ内容を明示すると、プログラムが失敗しにくくなるだけではなく理解もしやすくな
PLaMo翻訳のGGUFをmmngaさんが公開されています。 https://huggingface.co/mmnga/plamo-2-translate-gguf PLaMo翻訳のプロンプトは次のような指定をする必要があります。 <|plamo:op|>dataset translation <|plamo:op|>input lang=English Write the text to be translated here. <|plamo:op|>output lang=Japanese で、plamo-2-translate-ggufには次のようなプロンプトテンプレートが設定されています。 これ、LM StudioのチャットUIで使うにはいいのだけど、APIで使おうとするとうまく動かせません。 ということで、手動にしてEmptyに。 そうするとこんな感じのクラスを用意すればPLaM
AIとやりとりしてると、こんな感じでさっきのバグを再現してしまって「アホか!」って暴言吐きたくなることありますね。 で、このエントリのときに、こういうチャットは捨てて やりなおしたほうがいいと書きました。 AIに激詰めしてしまうのはAIだからじゃなく、そのくらい言わないとわからなそうだから - きしだのHatena なんでそうなるかというと、まずトランスフォーマーのアテンションという単語ごとの関係を見る仕組みがあります。 で、バグコードが続くとき、非常に雑にアテンションを書くとこんな感じで、間違ったコードを強調しあってしまうのですね。どのくらい注目してるか、というのを書いてます。 / / 結構 たくさん / 結構 / 結構 / たくさん 結構 / アテンションではそのトークンが否定されたかどうかをあまり気にできないので、こうなると、トランスフォーマーさんはこの方向のコードが大事なので似たよ
AIプログラムの開発、つまり、AIにコードを書かせるのではなくて、LLMを呼び出したりRAGを実装したりエージェントを作ったりといったAIを組み込むプログラミングの演習をしたいときに、参加者のPCに十分なリソースを前提とできないことは多いと思います。 Java AIプログラミング記事でQwen3 1.7B Q4_K_Mを選んだ 先月gihyo.jpの連載で、「JavaでAIプログラミングをはじめよう」という記事を出しました。 「JavaでAIプログラミングをはじめよう」という短期連載をgihyo.jpで出しました - きしだのHatena そのときに、読者のPCにGPUが載ってたりMacであることだったりは前提にできないので、なるべく必要なリソースが少ないモデルを選ぶ必要があって、最終的にQwen3 1.7BのQ4_K_Mを選びました。初回に、LM Studioとあわせた導入方法を載せてま
CerebrasがQwen3 Coderのホストをして2000tok/secを出してるという話があって、試したいなぁと思ってたのですよ。 Qwen3 Coder 480B is Live on Cerebras ただ、$50/monや$200/monの定額プランは早々に売り切れ。 けど、1M tok/dayまで無料という噂を聞いて、使ってみることにしました。 で、以前つくった雑なエージェントを試す。 Tool Useが効かないDevstralでコーディングエージェントを作る - きしだのHatena そしたら、3秒でSpring BootでのTODOアプリが!これ、ほんとにこの速さで生成してます。 といいつつ実際に計測すると2000tps出ないんでは、とか思ってたら逆で、2600tok/sec出ていました。 いま、Claude Sonnet 4は70tpsくらいですね。 https://o
GoFの「デザインパターン」の「終わりに」という章の「終わりに」という項は次のようになっています。 もっとも良い設計は、全体がたくさんのデザインパターンをぴったりとつなぎ合わせて、組み合わせてできているものである GoFのデザインパターンのコンセプトは、パターンのカタログを提示することだけではなくて、その構成を使って多くのパターンを見出してほしいというものでした。 けど、名前をつけてカタログ化するほどのパターンは、コンピュータの高性能化とネットワークの普及に応じて変化したソフトウェアアーキテクチャを整理したものが多く粒度が大き目で、GoFのデザインパターンの想定した粒度のようなものはあまり共有されいません。 実際のところパターンは数多くあるものの、粒度が小さく変化も大きく、デザインパターンとして名前をつけて整理をして共有するのが難しい。 そうすると、Erich Gammaのいう「全体がたく
みなさん、AIコーディングしてますか?そうですよね、やってますよね。 みなさん、AIに激詰めしてますか?罵声あびせてますか?やってますよね。 「おめーは何回いえばわかるんだ」みたいなことを、そんなこと書いても意味ないとわかってるのにやってしまいますよね。 ぼくは性格が悪いので、嫌味をいいがちです。 まあ、そうするとキレ気味に「お疲れさまでした!」って言ってくるので、AIかわいい。 これはGPT-4oだったけど、Claude Sonnet 4に聞き直して解決しました。GPT-5ならちゃんと目的完遂できたかもしれません。 で、生身の人間には言わなそうなことを口走ってしまうことも多いわけですね。 でもこれ、「相手がAIだから何をいってもいい」っていうことじゃないように思います。さっきも書いたとおり、AIってわかってれば、そんなこと言っても意味ないことがわかるはず。 そうではなくて、ここまでのやり
次のページ
このページを最初にブックマークしてみませんか?
『きしだのHatena』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く