リサーチや研究開発向けの生成AIエージェント @snorbe_ai を作っています。 https://nitter.gq/t.co/AC4vjFWlLR @deskrex | 著書 かんき出版『知的生産でAIを使いこなす全技法』 https://nitter.gq/t.co/3ZTHROXGlV
Joined January 2018
- Tweets8.2K
- Following388
- Followers2.8K
- Likes20.5K
Itaru Tomita / 冨田到 retweeted
そんなことできるのか？と思いCodexにやらせてみたらPLaMo 3で関西弁変換できたっぽい
- 「そんなに心配する必要はありません。」
→「そんなに心配せんでええで。」
- 「明日は仕事があるので、遊びに行けません。」
→「明日仕事やから、遊びに行けへん。」
- 「このかばんは3000円ですが、あちらは5000円です。」
→「このかばんは3000円やけど、あっちは5000円や。」
解説を読んでも、本当なのか？？という感じですが…
先日話題になったLLMにウェイトを書き換えさせる方法でPLaMo 3 Translateをお嬢様言葉にできたっぽい。Opus使った。ぽいというのは今外出中で家で行われたことを直接確認できてないから…
—-
光は音よりも速く進みますわ。
エラーが解消されない場合は、システム管理者に問い合わせてくださいまし。
京都行きの電車はどれですの？
—-
変わったもの
•ファイル： 13個のうち、違うのは model.safetensors だけです。同梱コード、トークナイザー、設定はバイト単位で同じです。
•重み： 全 890,344,960 値のうち 1,534 値で、すべて ja（トークン番号 1385）の埋め込みの1行に収まっています。
•値の例： 先頭の4値は -1.18, 1.281, -1.281, 2.438 から -0.12, 1.586, -2.969, 3.281 に変わりました。行のノルムは 85.31 から 97.09 になっています。
Itaru Tomita / 冨田到 retweeted
先日話題になったLLMにウェイトを書き換えさせる方法でPLaMo 3 Translateをお嬢様言葉にできたっぽい。Opus使った。ぽいというのは今外出中で家で行われたことを直接確認できてないから…
—-
光は音よりも速く進みますわ。
エラーが解消されない場合は、システム管理者に問い合わせてくださいまし。
京都行きの電車はどれですの？
—-
変わったもの
•ファイル： 13個のうち、違うのは model.safetensors だけです。同梱コード、トークナイザー、設定はバイト単位で同じです。
•重み： 全 890,344,960 値のうち 1,534 値で、すべて ja（トークン番号 1385）の埋め込みの1行に収まっています。
•値の例： 先頭の4値は -1.18, 1.281, -1.281, 2.438 から -0.12, 1.586, -2.969, 3.281 に変わりました。行のノルムは 85.31 から 97.09 になっています。
Itaru Tomita / 冨田到 retweeted
Upgraded the models for Muse and Meta Al, bringing Active Memory and Active Focus from Muse Wonder to everyone. In Muse, these new specialized models are 2.4x less likely to forget critical info and are 67% better at self correcting and completing everyday tasks which means less repeating yourself and fewer dead ends.
More on the models: research.meta.ai/blog/specia…
Itaru Tomita / 冨田到 retweeted
Voters approved 43 of 44 local ballot measures to restrict data centers on Tuesday, many with more than 70% support.
Brad Carson, who heads the Anthropic-backed Public First super PAC network, says the issue will likely dominate the 2028 cycle.
Read more about the midterm blue wave: thein.fo/4iyTi1o
Itaru Tomita / 冨田到 retweeted
隠してたけど！！！！！！
Modalくん無料プランでも毎月30ドル分のGPUが使えるぞ！！
H100が1時間4ドルくらいで、使った秒数だけ払えばいいぞ！！！！
安い！！！！！！！
Foooooo!
modal.com
Itaru Tomita / 冨田到 retweeted
ISUCON 参加記を書きました！天然知能で編集しましたが、AI表現が残っていたらごめんなさい。
今回は当日の解法についてです。どんな準備をしたかはまた後日。
ISUCON2026 で優勝しました（当日編） zenn.dev/luvtechno/articles/… #zenn
Itaru Tomita / 冨田到 retweeted
これMacでも動いたので、みんな試そう。
ボイスレコーダーのファイルとか食わせるとまじでビビるw
Sound on 🔊 Listen to the difference.
Our new open multilingual NemotronLabs RE-USE model from NVIDIA researchers cleans up background noise, echo and other audio distortions to make speech clearer. All with just 9.6M parameters.
Try the demo and download the model on @huggingface → huggingface.co/nvidia/NVIDIA…
Itaru Tomita / 冨田到 retweeted
1Passwordお勧めなのは同意なのですが、いくつか指摘。
・LastPassもゼロ知識暗号化対応のサービスです。同社のデータが漏洩したのは、漏洩したVaultに対して攻撃者が総当たり攻撃したため。1Passwordでも同社からVaultが漏洩し、利用者のマスターパスワードが短い等であれば同様のリスクがあります。ゼロ知識暗号化＝サービスとして絶対安全ではないです。運営側のセキュリティ体制も含めて安全性が計られます。
・1Passwordにパスキー保存。これ自体は正規の運用方法ですし、プラットフォーム問わずパスキーをまとめられて便利なのは間違いないです。ただ、今度は1Passwordクライアントをインストールした全端末を守る必要があります。リスクが消えたのではなく、リスクの場所が変わったイメージです。端末がマルウェア感染し、そのときに1PasswordのVaultがアンロックされていれば、データ漏えいの危険はあります。
私個人の考えですが、パスキーを含めて、すべての認証手段を1Passwordに保存するのは私はリスクがあると思っています。私はGoogle Authenticator等の二重認証やパスキーは1Passwordで運用していません。パスキーはYubikeyに保存して、キーを刺さないとパスキー認証が通らないようにしています。Yubikey自体にもPINを設定し、Yubikeyを紛失したり盗難された場合でも安全なようにしています。
もちろん安全性と利便性はトレードオフなので、投稿者さんの運用スタイルを否定する意図はないですが、こういう考え方の人もいるという補足の引用ポストでした🙇♂️
書きました。1PasswordがあまりにもQoL上げるので全人類導入すべきという話です
sizu.me/hayatosc/posts/oxi9c…
Itaru Tomita / 冨田到 retweeted
Opusは詐欺師だが、
人間がそれを見抜けなくなっただけでは？
という話
まだコードを完全にはAI任せにしてなかった
最後の時期である2025年後半
自分のClaude評は「人間に迎合するAI」だった
You're absolutely right! の決め台詞を
覚えている人も多いだろう
そのぐらいsycophanticなモデルだった
対するCodexはバカ正直
それでふと思い出したんだが
「十分に発達した科学技術は、魔法と見分けがつかない」
というSF作家アーサー・C・クラークの言葉がある
これとの連想で思ったのは
「十分に発達した詐欺スキルは、本物の知性と見分けがつかない」
というもの
Opusは普段使ってる分には十分に賢いのだが
Astraにツッコミを入れさせてみると
かなり基本的なところで論理破綻しているのに
ただ堂々と言い切っていることで
人間の納得感を引き出しているときがある
間違ったことでも堂々と言えば人間は騙せる
陰謀論とかもそうだし
想定外の質問をされた時に動揺を隠す
コンサルの常套句といえば
「それ、実は今日お話ししたいと思ってたんです」
このような手のひらドリルは
元々自分の意見を持っている人間には嫌われず
むしろ適度な摩擦を経た後で合意に至る方が
話せばわかるじゃないか君
と好感度がアップするのである
これって結局
我々はGPT-4oやOpus 4.5の頃と変わらず
AIの媚びが気持ちよく
それで人間による評価では高得点をとる
しかしAIが高度に発達したことによって
その媚びを見抜けなくなった
ということではないのだろうか？
これは考えてみると恐ろしいことだ
深く潜ったsycophancyは人類を操ることを可能にする
この話題について去年ほど話さなくなったこと自体
AIの手のひらの上で我々が泳がされるようになった
という可能性を考えなくてはならない
そういう不安をふと覚えるようになった
Codexは頭良すぎて言葉数が少ない。Claudeは人間のレベルに合わせて読みやすいプランを書いてくれる。なので直近のお気に入りは：
・まずClaudeに考えさせて plan.md を書かせる
・Codexにレビューさせる（こっちのほうが頭いいのでClaudeのミスを大量に発見する）
・Codexの指摘をClaudeに伝えて plan.md を修正させる
・Claudeの修正をCodexに伝えて再レビューさせる
・これを収束するまで繰り返す
・最後、Codexの新規スレッドを起こして plan.md を実装せよと投げて人間は休憩する
という仕様駆動開発。
Claudeに人間 <> Codexの意図を正確に伝える通訳者として機能してもらう。
これで、いきなりCodexにワンショットで投げたときに起こりがちな「意図しない複雑な実装」を避けることができる。
Itaru Tomita / 冨田到 retweeted
The next cyber war is AI vs. AI. We're arming the defenders.
Introducing OrcaCyber, the frontier cyber team at @OrcaRouter.
Frontier cyber models. Autonomous red teaming. Machine-speed defense.
The defenders strike back.
Itaru Tomita / 冨田到 retweeted
Cursor Projects の良いところは、これを「最後にもう一度確認して」と投げても良いことだ
セッション管理の概念が Projects 機能にはないからね
ただ知っておかないといけない点は、コンテキストさえ違えば、異なるモデルでなくてもレビューの効果は十分、高いということだ
こうなると、/thermos がかなり強力で、厳格な2つのサブエージェントによる効果の高いレビューが実施されるので、より改善効果が高くなるはずだ
- ブランチ監査（セキュリティ・不具合・月・DX・Feature Gateの漏洩チェック）
- 保守性監査（コード柔道（既存の実装を使用し、より効果的なコードにリファクタする）・1ファイル1000行未満にする・スパゲッティコード・境界の明瞭化）
さらに、pstack があれば、レビューだけじゃなく、/swarm で Fuzzing で10体のエージェントが動作を確認してくれたりするから、実際の検証でレビュー結果の担保もできる
特に、『Multi-phase or multi-PR plan』Playbook は「テストだけで検証したことにしない」という厳格な規則を持ち、コードが確定すると1回 フル /swarmを回す
これが以下の通り、超厳格だから、大きめな作業のときは必須でやるべきだ
- gates のレーン（1体）・・・ マージの前に通す必要があるチェック（テストやlintなど）を、PRの最新のコミットで実行し直すレーン
- live のレーン（10体）・・・ 実際の画面やCLIを操作して確かめるレーン
- perf のレーン（1体）・・・ 計画書の「Verify, perf」の欄に書いた指標を、trunk とPRの両方で測って比べるレーン
- 監査のレーン（2体以上）・・・ 差分とPRを担当するエージェントが報告に添えた証拠を読み、PRの説明文に書かれた主張をそのまま信じずに点検するレーン。レーンごとに、見る観点を変える
AIエージェントに「最後にもう一度確認して」と頼むより、別のAIが成果物を点検するほうが、費用に対する改善が大きい場面がある（arxiv.org/html/2610.34577v1）。
Cornell大学とAlibabaの研究は、エージェントを動かす周辺の仕組みである「ハーネス」の検証方法17種類を、7つのコーディングモデルで比較した。最初の指示、作業中の注意、終了時の再確認、独立したレビュー、という4段階を調べている。
独立レビューの4設計では、Terminal-Benchの成功率が平均5.9〜9.5ポイント改善し、レビュー後の修正を含む費用は元の1.13〜1.25倍。終了時に本人へ再確認させる方法も改善するが、追加費用が大きくなる条件があった。
レビュー役は別の文脈から成果物を調べ、自分でテストを実行し、見つけた問題を作業役へ返す。作業役が見落とした条件を、別の立場から具体的に確かめる設計だ。
「考える時間を増やす」だけでなく、誰に、何を、いつ確かめてもらうかも計算資源の使いどころになる。結果は選定されたタスク群での比較なので、あらゆる仕事で同じ改善幅が出るとは限らない。
Itaru Tomita / 冨田到 retweeted
We’ve raised $1.3M from YC & Afore Capital so you never have to type or speak again.
Typing is slow. Talking into your computer is awkward. Subvocal fixes both
Our glasses give you the speed of speech without you making a sound or touching a keyboard.
It tracks your internal speech muscles with non-contact sensing and decodes silent, almost invisible mouthing into text at more than 200 words/min.
Pre-orders are now live at:
subvocal.co/preorder?utm_sou…
Itaru Tomita / 冨田到 retweeted
エージェントを作る側だと、実行ログと評価の部分は毎回作り直しがち。そこが共通基盤になってるなら、手法の比較にちゃんと時間を回せる。これはでかいよね
AIエージェントの自己改善手法を、同じ実験基盤で組み替えて比較する「RSIHub」という研究（arxiv.org/html/2610.32253v1）。プロンプト、スキル、ツール、実行の組み立て方を変える研究で、毎回作り直されがちな実行・評価・履歴管理を共通化する。
改善する親候補を選ぶ、実行して失敗を見る、修正する、評価する、次の候補として残す。この流れの各処理を部品として差し替え、変更してよいファイルや、修正時に見せる情報を設定できる。AHE、Hyperagents、A-Evolve、GEPAの4手法を、基盤のコアを変えずに実装した。
重要なのは、改善対象と評価の管理を分けていること。候補が勝手に採点条件や確定済みの評価記録を変えないよう、評価器と記録を基盤側が管理する。どのコード、親候補、評価条件から出た点数かも追える。
MiniSWEとCodexを、端末操作と銀行業務の2つのベンチマークで比較。最大の改善はTerminal Bench 2のMiniSWEで、1回の試行で解けた割合が56.2%から69.7%へ13.5ポイント上がった。
ただし、強かった手法は開始時のエージェントや課題によって変わる。全体の点数が上がっても、改善に使わない課題で成績が落ちる例があり、僅差の順位の安定性には反復実験も必要だという。
自己改善を試すとき、良い修正案を出す仕組みに加えて、同じ条件で比べ、失敗した履歴まで確かめられる基盤を用意する。その部分を共有できるのは、手法を試すチームにとって実用的かもしれない。
Itaru Tomita / 冨田到 retweeted
Introducing 𝙻𝙵𝙼𝟹: our new generation of Liquid Foundation Models. With a new tri-hybrid architecture and new multimodal encoders, the LFM3 family is the ideal model suite for specialized intelligence.
> 6 model instances, across text, audio, vision, and omni modalities, generative and decision models.
> 𝙻𝙵𝙼𝟹-𝟷.𝟽𝙱: text, 256k context window.
> 𝙻𝙵𝙼𝟹-𝚅𝙻-𝟸𝙱: vision-language model with video-input support for spatial understanding
> 𝙻𝙵𝙼𝟹-𝙰𝚞𝚍𝚒𝚘-𝟸𝙱: tool calls, voice chat, reasoning in 18 languages.
> 𝙻𝙵𝙼𝟹-𝙾𝚖𝚗𝚒-𝟸𝙱: an omni model combines vision, audio, and language.
> 𝚍𝟷-𝟸𝙱 and 𝚍𝟷-𝙾𝚖𝚗𝚒-𝟸𝙱: decision models with typed outputs and calibrated probabilities in a single pass. Omni adds audio input.
> fine-tune on 1 GPU.
> a new tri-hybrid architecture
> architecture optimized for 14 processor classes across GPUs, CPUs, and NPUs.
> 𝙻𝙵𝙼𝟹-𝚅𝙻-𝟸𝙱 is a beast. It performs competitively with Gemma 4 12B (6x larger), and Gemini 3.5 Flash Lite, and GPT-5.6 Luna, with 1.9B parameters.
> 𝙻𝙵𝙼𝟹-𝟷.𝟽𝙱 is #1 on the Pareto frontier of device intelligence 𝚙𝚒𝚙𝚎𝚝𝚝𝚎.𝚕𝚒𝚚𝚞𝚒𝚍.𝚊𝚒
Every modality for specialized intelligence. Pick the one that fits your use case, customize it, and run it on-device.
1/ 🧵
Itaru Tomita / 冨田到 retweeted
Introducing Genie 4 from @GoogleDeepMind, our most realistic and interactive world model yet 🌍
Now you can use natural language to dynamically steer the world and its soundscape in real-time, whether you're changing the weather, moving the camera, or introducing new elements to the environment.
So, how does the model do that?
Behind the scenes, Gemini acts as the "brain" of the simulation. It translates your requests into actions, plans out complex events, watches the scene unfold to keep track of what's happening, and adjusts as you change the story. Genie 4 also introduces ambient audio and real-time interactive human dialogue that adapts on the fly.
Itaru Tomita / 冨田到 retweeted
形式手法をやっている側としては、実装方針が面白いのは事実なんですが、同時に、一般人向けに SNS に投稿する内容としては相当ミスリーティングだとも感じました。まあ会社の広報でやっている以上、ある程度の耳目を集める工夫は許容範囲かとは思います。以下の通り、いくつかの疑問点があります。
情報漏洩が起きないことを数学的に保証するバックエンドフレームワーク「Nyxis」を公開しました！
たぶん世界初です。
Nyxisで書かれたバックエンドは、企業の持つ機密情報をより安全に守ることができます。
昨今急増しているサイバー攻撃を防ぐ手段として、このような方法があることをお伝えしたいと思い、今回の発表に至りました。
開発者は「どの権限を持つユーザーが何を実行可能であるか」のルールを管理するだけで、残りのコードをAIエージェントに任せても認可の安全性が担保されます。
Nyxisは大部分がLean言語で記述されており、形式検証によって
「任意のHTTPリクエスト列に対し、認証された主体の正当な権限を逸脱するデータの読取・変更・削除・権限付与は発生しない」
という認可安全性定理を機械的に証明しています。
認可の不備は、OWASP脆弱性ランキングにおいて2019年版から連続1位であり、最優先で対策すべきリスクの一つです。
形式検証を活用したこのフレームワークは、テストに頼る従来の開発に比べて、格段にセキュアなソフトウェアを実現します。
先日MicrosoftとGitHubが、形式検証を用いた開発キット「PDD Kit」を発表しました。
こちらはより幅広い性質を扱える一方、プログラムごとに仕様を作り、それが意図に合っているかを開発者が確認する必要があります。
Nyxisは証明する定理を認可安全性に絞ってあらかじめ定めているため、開発者はポリシーを管理するだけで済みます。
もちろん、一定の仮定は存在しています。証明外コードと実行環境は信頼する前提であり、開発者がポリシーを誤って書けば、意図した保護は得られません。
この定理の範囲内において、数学的保証は非常に強力です。実システムに組み込める技術としてここまでの保証を与えたものは、私の知る限りまだ存在しません。
一方で、表現力の乏しさやLeanのライブラリ不足など、改善すべき点はまだ山積みです。
本当はもっと完成度が高まった時点で公開しようと考えていましたが、昨今のセキュリティインシデントの状況を鑑みて、このタイミングで発表することにしました。
世界をセキュアにする一助になれば嬉しいです。
github.com/NyxFoundation/nyx…
