Nobu-Kobayashi : Generative AI Technology
@nyaa_toraneko
元UTJのシニアエバンジェリスト。ユニティちゃんトゥーンシェーダー2.0の生みの親。今は生成AI技術のテックアーティスト。ComfyUIワークフローやカスタムノード、GPTs開発をやってます。お仕事や技術上のご相談はDMにて承っておりますが、2026年中はフルタイムでお仕事が詰まってます。
4.5K フォロー中 13K ファン
MIniMax-H3でローカル生成。
自分としてはSeedance 2.0の生成結果にはまだ及ばない印象だが、かなり癖はわかってきた。
あ。そうか。
NVFP4を使えるようにするためにはBlackwell世代にCUDA13.0以上を入れなきゃいけないんだった。
ずいぶん前に終わらせていたから、すっかり忘れてた。
もっと見る
Agentを扱ううえで、「違う。そうじゃない」と修正を繰り返す方法は、あまり効果的ではないと感じている。
否定や追加指示を重ねるほど、コンテキストには失敗した経路や場当たり的な制約が蓄積していく。一方で、何を基準に正しいと判断するのかは、必ずしも明確にならない。結果として、Agentは目的そのものではなく、直近の修正指示に過適合しやすくなる。
だから、「違う。そうじゃない」と伝える前に、まず取り得る候補を列挙させるべきだと思う。
そのうえで、各候補についてPoCの計画を立て、評価基準とテストゲートを設ける。小さく検証し、結果を比較しながら、最も有望な案を選ぶ。そして、十分に見込みのある方向性が確認できてから、本格的な実装へ進む。
このプロセスを踏まなければ、「違う。そうじゃない」という状態は根本的には解消されない。
Agentのうまい扱い方とは、誤った出力を何度も修正することではない。最初から候補、評価基準、検証方法を設計し、「そうそう、その通り」と言える方向へ進みやすい道筋を整えることだ。
試行錯誤そのものが不要なのではない。重要なのは、試行錯誤を会話上の押し問答として行うのではなく、管理された仮説検証として行うことである。
最近は、Agent Engineeringの本質は、指示を細かく書くことではなく、探索と検証のプロセスを設計することにあると考えている。
もっと見る
自分は検証寄りの見方をすることが多いので「観測事実とその説明が事実と整合しているかどうかを見る」というところがすごく腑に落ちました。「なぜそうしたのか」への答えは、それ自体が新しく作られた出力なので、証拠ではなく仮説として扱うのが安全なのだと思います。説明を無視するという話ではなく、どこを確かめるかの当たりをつけるために使うくらいの距離感なのかなと読んで思いました。
もっと見る
人間の意思決定の多くは、まず無意識の評価系（システム1）が方向性を決め、その後でシステム2が「なぜそうしたのか」という理由を組み立てている。
だから「なんでそうしたの？」という問いに対する答えは、人間ですら後付けの説明になっていることが少なくない。
AIも同じように、出力の理由は直接取り出せるものではなく、観測できる事実から最も整合的な説明を組み立てている。
だから本当に見るべきなのは「説明」ではなく、「観測事実」と、その説明が事実と整合しているかどうかなんだと思う。
もっと見る
考えてみたら、自分はLLMに対して「なんでこうしたの？」と問い詰めるようなことをしたことがない。
「そんなの確率論なんだから直接わかるわけがない」と思っていたのもあるけど、そもそも人間だって、自分がなぜそうしたのか本当の理由を理解していないことは珍しくない。
AIの出力も、人の行動も、その理由は観測された事実から推測するしかない。
だから大事なのは「説明」を信じることではなく、事実を検証すること。
AI相手に感情的にブチ切れている人を見ると、無駄に血圧を上げているな、としか思えないのである。
もっと見る
そろそろこの件に言及しておこうかなーと思っていたので引用で課題意識をお借りする。
少なくとも Claude についていうと、「なんで」かは Claude 側も「知らない」。というのも thinking の内容が直近ターンのものしかコンテクストウィンドウに入っていないため。
なので Claude は過去の自分のアウトプットだけを見て、事後推測するしかないというわけ。だからそれっぽい「ウソ」ついたりする。
Claude Code でコレに手軽に対策するには showThinkingSummaries を true にして、セッションログである jsonl ファイルに記録される thinking summary を振り返り取得させるようにする仕組みを導入するとよい。オススメはやはり DuckDB に hooks で自動投入させるようにすること。もっと高度にやるなら環境次第では eBPF でも。
ただあくまでこれは summary であって raw ではないので、「なんで」の詳細は容易には掴めない。とはいえ出力結果だけからの事後推測よりはだいぶマシ。raw についてはとりわけ Fable などで分かる通り蒸留を警戒されてるので隠蔽されている。
人間は、自分が取った言動に対してある程度の内省をできる。「あ、さっきこうしたのは、こう思ったからで……」それが Claude にはできない。thinking が揮発してるから。「なんで！？」と詰めれば詰めるほど、それっぽいことを言う。で、それっぽいことがコンテクストウィンドウに残るので、余計に悪い結果が後に続くようになる。
ということでまとめると、
- thinking summary を参照させるしくみを作って、正しく自省させられるようにしよう
- 自省させた結果、hooks 等のなんらかのしくみで対策とれるなら改善を積み重ねていこう
ストレートに使ってると Claude Code でなぜなぜ分析をするのは役に立たないどころか有害になる。が、そこで諦めることはなく、制約はあれど多少はおこなえるようにすることはできる。保身や悪意で理由をでっち上げることはないので、その点の信頼感もある。
もっと見る
そろそろこの件に言及しておこうかなーと思っていたので引用で課題意識をお借りする。
少なくとも Claude についていうと、「なんで」かは Claude 側も「知らない」。というのも thinking の内容が直近ターンのものしかコンテクストウィンドウに入っていないため。
なので Claude は過去の自分のアウトプットだけを見て、事後推測するしかないというわけ。だからそれっぽい「ウソ」ついたりする。
Claude Code でコレに手軽に対策するには showThinkingSummaries を true にして、セッションログである jsonl ファイルに記録される thinking summary を振り返り取得させるようにする仕組みを導入するとよい。オススメはやはり DuckDB に hooks で自動投入させるようにすること。もっと高度にやるなら環境次第では eBPF でも。
ただあくまでこれは summary であって raw ではないので、「なんで」の詳細は容易には掴めない。とはいえ出力結果だけからの事後推測よりはだいぶマシ。raw についてはとりわけ Fable などで分かる通り蒸留を警戒されてるので隠蔽されている。
人間は、自分が取った言動に対してある程度の内省をできる。「あ、さっきこうしたのは、こう思ったからで……」それが Claude にはできない。thinking が揮発してるから。「なんで！？」と詰めれば詰めるほど、それっぽいことを言う。で、それっぽいことがコンテクストウィンドウに残るので、余計に悪い結果が後に続くようになる。
ということでまとめると、
- thinking summary を参照させるしくみを作って、正しく自省させられるようにしよう
- 自省させた結果、hooks 等のなんらかのしくみで対策とれるなら改善を積み重ねていこう
ストレートに使ってると Claude Code でなぜなぜ分析をするのは役に立たないどころか有害になる。が、そこで諦めることはなく、制約はあれど多少はおこなえるようにすることはできる。保身や悪意で理由をでっち上げることはないので、その点の信頼感もある。
もっと見る
これAIを業務システムに組むときに大事な点で、SFのAgentforceが登場した頃の実装レクチャーでかなり口酸っぱく言われた記憶ある。
AIに任せる範囲（セキュリティやデータスコープ含む）を小さくしないと怖いんだよね。
もっと見る
ゼロから設計した複雑なシステムはうまくいかない、という記事
・過去に関わったメインフレームの書き換えプロジェクトでは、マネジメント層が段階的なリリースを拒否したために失敗に終わった
・今でもその組織は新しいシステムを稼働させるために苦労を続けている
・この失敗は「機能する複雑なシステムは、機能する単純なシステムが進化したものである」というGallの法則の典型例といえる
・ゼロから複雑なシステムを設計しても機能することはなく、機能する単純なシステムから作り直すしかない
・小さく機能するシステムを稼働させて実データから学ぶ手法を提案したが、マネジメント層は完全なシステムを一括で構築することを望んだ
・不完全なシステムをビジネス側が受け入れないという恐れからだったが、未テストの巨大なシステムを一発で成功させることに賭ける最もリスクの高い戦略である
・小さくリリースして実際の使用パターンを観察する段階を飛ばすと、証拠ではなく推測に基づいてシステム全体を設計することになってしまう
・既存のシステムが複雑なのは長い時間をかけて進化してきたからであり、最初からその複雑さを設計して進化の過程を省略することはできない
・小さく機能するシステムを最初に公開できないのであれば、巨大なシステムを設計できるほどまだ問題を理解していないということである
・反発を恐れて大規模な設計に逃げ込んでも、リスクがプロジェクトの終盤に先送りされて間違いに気づくコストが高騰するだけである
もっと見る
『Skillとは、LLMを賢くする仕組みではない。LLMが毎回同じように成功できるよう、設計によって成功率を保証する仕組みである。』
この2か月ほどCodexと開発を続けてきて、一番大きな収穫はこれだった。
最初は「良いプロンプトを書けばうまくいく」と思っていた。でも実際には逆だった。
本当に重要なのは、AIに考えさせることではなく、「AIが考えなくて済む部分」を徹底的に設計することだった。
決定論で解ける部分は決定論で処理する。
AIに残すのは、本当に推定が必要な部分だけ。
その結果は必ず検証し、ダメならリトライ、それでもダメならオーナーへエスカレーションする。
失敗の扱いまで設計に含まれているから、最後にAIへ渡すプロンプトは一行で済む。
そうして成功した工程だけを抽出し、Skillとして固定化する。
Skillとはプロンプト集ではない。
決定論の骨格に、最小限の推論だけを埋め込んだ、再現可能なマクロなんだと思う。
もっと見る
CLAUDE.mdやAGENTS.mdのグローバル設定は、文面より「構造＋防いでいる失敗モード」を共有すべきだと思う。
あのルールの正体は、自分の失敗から生まれた傷跡だ。失敗と切り離してコピーしても、検証も更新もできず、指示書が肥大化して形骸化する。
整理すると3層ある。
①個人の運用スタイル
→ 信頼モデルが違うので移植不可
②ドメイン固有のベストプラクティスやNG
→ 文面ごと共有する価値あり。ただしリポジトリ側へ
③プロジェクト固有の事実
→ 当然リポジトリ側で管理
グローバルは構造と理由を共有し、プロジェクト側は文面ごとコミットする。
共有すべきなのはテンプレではなく、失敗から導かれた設計思想だ。
もっと見る
『みんなの日報が、AIになっていた。』って、「誰も読んでいませんでした」みたいな落とし穴が控えてそうだ。
何をしてもほとんど絡まれないマンなので自由にやっている。
それはそれでちょっと寂しいところもあるけど、下手に拡散しまうと頓珍漢なツッコミが来て困るというのは確かにある。
もっと見る
AIによるツール開発を1か月半ほど続けていて気づいたことの一つ。
開発期間が1か月を超え、テストスクリプトが800本前後まで増えてくると、初期設計の良し悪しが一気に表面化する。
設計が甘いツールは、この辺りから追加機能の実装が急に難しくなり、バグも増え始める。アプリも重くなり、メンテナンスコストや運用コストが目に見えて上がってくる。
逆に、この壁を越えられる設計なら、その後は大きな手戻りがほとんど発生しない。大規模データ運用やユーザーテストにも耐えられるだけの頑健性が備わっていることが多い。
チーム開発で言えば、ちょうどβ版が完成して「この先も開発を続ける価値があるか」を判断するタイミングに近い。
AIのおかげで実装速度は上がった。でも最終的に問われるのは、やはり初期設計の質なんだと思う。
もっと見る
PS1時代にしばしば揶揄された「俺、感性で指揮するハイパーメディアクリエイターですから」のようだ😅
当時は、「椅子の上で💩座りをしたがら、🍌喰いながらケツを掻いて🐒」このセリフを言う、んだった。
もっと見る
最近試して、かなり良かったレポート作成術。
PoCの作業ログをSlackに残し、成功・失敗・保留などのタグを付ける。
PoC終了後、そのスレッドをSlackbotでCanvas化し、「ケースごとに成功例・失敗例を整理して」と指示。
CanvasをGoogleドキュメントへ移し、Markdownで書き出す。
そのMarkdownをConfluenceのRovoに渡して、報告書として再構成してもらう。
最後に画像やムービーを追加し、内容を確認して完成。
これでConfluence向けレポートの制作時間が、体感で従来の1/3ほどになった。1時間程度で、きちんと読める報告書まで持っていける。
関連リンクまで比較的きれいに引き継がれるのも大きい。
もちろん、元になるSlackログが雑なら、最終成果物も良くならない。
これは文章を水増ししたり、体裁だけ整えたりする方法ではない。
PoC中に残した一次情報を、段階的に整理・圧縮・再構成するパイプラインだ。
「金曜までにPoC、翌週月曜にレポート」が、週内で片付くようになる。
これはかなり助かる。
もっと見る
今週は、コレと「クリップ長を変えずに、指定フレームをキーへ合わせる」という『フレームシンク』機能を実装したので、もう十分働いたと言っていいだろう。
つか、「昼間仕事して夜も趣味の開発をする」みたいなのは、「楽しいから」といっても、多少は控えないとマジに死ぬ😂
もっと見る
AI動画あるあるですが、部分的に動画フレームの中に入りこんでしまったパネルナンバーとかを削除するツールを、MovieCutBank Editorに実装してみました。
サンプルは左上の半透明のパネルとヒロインの頬っぺたの汗を消してみた例。
Photoshopの「削除ツール」の動画版程度の使い勝手になってます。動画のままで処理し、マスクの位置にもキーを打てるので、手っ取り早くさっと修正が施せることを目指しました。
これでちょっとしたゴミだったら、動画素材から消せる目途がついた。
もっと見る
AI動画あるあるですが、部分的に動画フレームの中に入りこんでしまったパネルナンバーとかを削除するツールを、MovieCutBank Editorに実装してみました。
サンプルは左上の半透明のパネルとヒロインの頬っぺたの汗を消してみた例。
Photoshopの「削除ツール」の動画版程度の使い勝手になってます。動画のままで処理し、マスクの位置にもキーを打てるので、手っ取り早くさっと修正が施せることを目指しました。
これでちょっとしたゴミだったら、動画素材から消せる目途がついた。
もっと見る
「やりたいことだから、休日返上でもやる」という気持ちはわからないでもないけど、その作品が会社のプロダクトとしてしか表現され得ないのは、本当に幸せなのかどうかは、わからないなぁ…。
ただそういうものがないと、良いものにはならないだろうというのは、よく分かる。
もっと見る
生成されたものの、結局そのまま使われず、ストレージの肥やしになっているムービーはかなり多いと思う。
版権物や実在人物などの権利上の問題がなく、投稿者も再利用を認めるなら、生成サイトのショーケースに「CC0」「リミックス可」「映像素材として利用可」といった表示を付けられないだろうか。
完成作品として眺めるだけでなく、別の誰かがMADやMV、新しい映像作品へ組み替える。
生成サイトのショーケースが、単なる展示場ではなく「生成映像の素材庫」になったら、かなり面白い文化が生まれそうだ。
もっと見る
