2026年7月13日月曜日

AI agent tool piebald

この作者がClaudeのシステムプロンプトを毎回抽出している。

https://piebald.ai/

https://github.com/Piebald-AI








Antigravityのgpt-oss-120b使えるの、便利すぎるだろ。


投稿者 時刻: 0 件のコメント:

gradface.netの顔認識をgoogle TPUで計算できるのか？

pixel10AのTPUを有効に活用する方法ないか、考えてみたけど・・・

gradface.netの顔認識をgoogle TPUで計算できるのか？
感覚的には、乗り切らなそうな気がするけど・・・


Fable5 UltraCodeに調査してもらう。


対象は InsightFace buffalo_l の5つのONNXモデル（SCRFD検出 + ArcFace埋め込み等）なので、「LiteRT(旧TFLite)への変換可否 × Edge TPU(Coral)のハード制約 × 精度・既存データ互換 × アプリ統合」の4軸で判定が要ります。まず手元のモデル実サイズを確認してから、並列で調査します。






4方向の調査を並列実行中です（一次情報のURL付きで検証させています）。完了次第、「完全移植は可能か」の判定を根拠付きでまとめます。

先に判定の骨格だけ共有しておくと、鍵になるのは以下の4点です:

  1. 変換可否 — ONNX→LiteRTはツール(onnx2tf等)があるので技術的には通る見込み。ただしSCRFDの動的入力形状の固定化が必要
  2. Edge TPUの物理制約 — Edge TPUはINT8必須+オンチップ8MB。認識モデル(174MB FP32→INT8でも約44MB)は明らかに超過し、性能が大きく落ちる可能性
  3. 既存データとの互換性 — INT8化すると埋め込みベクトルが変わるため、登録済みの顔DBが全て無効化される可能性が高い
  4. Coral製品自体の現状 — 2026年時点でGoogleがどこまでメンテしているか

調査結果が揃ったら最終判定を報告します。






結論: 「完全移植」は技術的には一部可能だが、実用上は成立しない（非推奨）

「GoogleのTPU + LiteRT」= Coral Edge TPU として調査しました（他の解釈も末尾に）。4方向×一次情報で検証した結果です。

成立しない理由（3つの壁）

壁1: ハードウェアの物理制約

  • Edge TPUは INT8完全量子化必須 + オンチップSRAM約8MB という設計です
  • ところが認識モデル w600k_r50 は 174MB（INT8化しても約44MB）で、SRAMの5倍以上。収まらない分は推論のたびにUSB経由でウェイトを流し込む「ストリーミング」になり、大幅に遅くなります。実測報告でもResNet-50級はUSB Coralで37ms/枚程度 — 今日復旧したRTX 4070 Ti（数ms）どころか、GTX 1660 Tiにも負けます
  • 検出モデルの det_size=960×960 はEdge TPUの想定ワークロード（MobileNet級・~640px）を大きく外れ、TPUフル実行はほぼ不可能

壁2: 精度と既存データの互換性

  • INT8量子化そのものの劣化は小さい（ArcFaceはLFWでほぼゼロ、SCRFDも0.2〜0.3pt）のですが、問題はそこではなく:
  • TPUに収めるため検出入力を960→640以下に縮小すると、WIDER FACE hard（小さい顔）でAPが82→68.5と約13.5pt低下。集合写真の小顔の取りこぼしが激増します — このアプリの用途に直撃
  • 認識モデルを8MBに収めるにはMobileFaceNet級への置き換えが必要ですが、埋め込み空間が非互換になるため、全プロジェクトの登録顔が無効化 → 全ユーザー再登録が必須になります

壁3: Coralエコシステムが事実上死んでいる

  • pycoral は2025年7月にアーカイブ（Python 3.9止まり）、google-coral/edgetpu リポジトリも2026年4月にアーカイブ
  • Edge TPUコンパイラは2021年から更新凍結、PCIe版ドライバはLinuxカーネル6.4以降で消滅
  • 2025年発表の「Coral NPU」はRISC-VベースのNPU IPで、Edge TPU製品の後継ではないとGoogle自身が明言。今買える後継ハードは存在しません

技術的に「できる」部分（参考）

  • ONNX→LiteRT変換自体は onnx2tf で SCRFD / ArcFace とも変換実績あり
  • insightfaceの後処理（NMS・アライメント）は純numpyなので流用可能で、統合コード自体は1〜2週間規模
  • LiteRTランタイム自体（ai-edge-litert）は活発にメンテされています

つまり「LiteRTへの移植」は可能ですが、「TPUで速く・良くなる」が成立しません。移植して得られるのは「遅くて・小顔が検出できなくなり・全登録データが飛ぶ・サポート切れハード」です。







他の「Google TPU」解釈も念のため

解釈判定
Cloud TPU (v5e/v6e)LiteRT非対応・ONNX非対応（JAX/TF/PyTorch-XLA専用）。この規模のモデルには常時課金が見合わない
Pixel Tensor NPULiteRTのNPUデリゲートはAndroid専用。Linuxサーバーでは使用不可




省電力エッジ化が真の目的なら、Coralではなく現役でメンテされているNPU（Hailo等）を検討する方が筋が良いです。




hailoのNPUなら完全再現できるの？
いくら？




4方向（モデルズー収録状況 / ハード価格 / コンパイル制約 / 統合・運用）で並列調査中です。完了したら「完全再現できるか」と「総額いくらか」を根拠付きでまとめます。

先にCoralとの決定的な違いを言っておくと、Hailoが有望なのは:

  • SCRFDとArcFaceの両方が公式Model Zooに収録されている（前回調査で量子化後精度 82.1 mAP まで公表されていることを確認済み）— Coralには顔系モデルの公式サポートが一切なかった
  • ツールチェーン（Dataflow Compiler / HailoRT）が現役でメンテされている
  • Raspberry Pi AI Kit採用でエコシステムが活発

一方で確認が必要な懸念は、960×960入力のカスタムコンパイル可否と、174MBの認識モデルがオンチップに収まらない場合のmulti-context動作のペナルティ、そして既存登録データの互換性です。結果が出たら報告します。





調査完了です。まとめます。

判定: 「完全再現」は不可。ただしCoralと違って「実用的な移植」は現実的に可能 — でも速くはならない

できる根拠（Coralとの決定的な違い）

  • 検出も認識も公式Model Zooに既製コンパイル済みモデルがある: scrfd_10g（量子化後 mAP 82.13→82.1でほぼ劣化ゼロ、440fps）と arcface_r50（LFW 99.72→99.7、w600k_r50と同一アーキテクチャ・512次元）。配布も現役です（2026年5月更新を実確認）
  • ツールチェーン（Dataflow Compiler / HailoRT）は無料（要登録）で現役メンテ中。Hailo公式コミュニティにSCRFD+ArcFaceの顔認識システム構築ガイドも存在
  • 量子化はEdge TPUと違い入出力float可（内部だけINT8）なので、insightfaceへの組み込みも素直

「完全」にならない3つの理由

  1. 重みが別物: Model Zooの arcface_r50 は ms1mv3 学習で、buffalo_lの w600k_r50（WebFace600K学習）とは別の重み = 埋め込み空間が非互換。手元の w600k_r50.onnx を自前でDFCコンパイルすれば同一重みにできますが、それでもINT8量子化で数値は変わるため、既存の登録顔DB（pickle）は全件再登録 + 類似度閾値/DBSCAN epsの再調整が実務上必須
  2. 960×960の既製はない: 既製HEFは640×640固定。960×960化は自前再コンパイルが必要（全畳み込みなので原理的に可能、~1MP入力の前例もModel Zooに実在）だが、実例未確認で実機コンパイル検証が必要
  3. 補助モデル（年齢性別・ランドマーク2種）はModel Zoo未収録 → これらはCPU（onnxruntime）に残すハイブリッド構成が現実解

性能の現実

arcface_r50 はHailo-8のオンチップSRAMに収まらず3コンテキスト動作（公式プロファイラで確認）: 113fps（逐次）/390fps（バッチ8）。試算すると集合写真1枚あたり約0.15〜0.4秒 — つまり:

  • RTX 4070 Ti（0.37秒/枚）と同等止まり
  • GTX 1660 Tiと比べても速くならない（1660 Tiの埋め込み推論の方が2〜3倍速い推定）
  • Hailoが勝つのは電力（約2.5W vs GPU 120W）・ファンレス・静音・常時稼働だけ

価格（2026年7月実売・確認済み）

構成価格
Raspberry Pi AI HAT+ 26 TOPS（Hailo-8）$110 / 秋月 ¥20,350（在庫あり） / スイッチサイエンス ¥24,860
AI HAT+ 2（Hailo-10H 40 TOPS）公式$200 / 秋月 ¥38,390
Hailo-8 M.2単体（既存PCに挿す）$180〜266（Waveshare $180、UP Shop $199）
Hailo-8L M.2（13 TOPS・半分）$99
Pi 5 8GB本体（DRAM高騰中）米$130〜175 / 秋月 ¥35,200
  • 最安の現実ライン: Pi 5 8GB + AI HAT+ 26 TOPS = 日本で約¥55,000〜60,000 + 電源等¥5,000
  • 既存Linux機（1660 Ti機）に追加するなら: Hailo-8 M.2 モジュール約$180〜200（M.2スロットかPCIe変換が必要）。ただしHailoRTのドライバはカーネルに合わせて自前ビルドです

私の見立て

このアプリの用途は「集合写真を数千枚バッチ処理するサーバー」なので、速度目的でHailoに移す意味はありません。




投稿者 時刻: 0 件のコメント:

2026年7月12日日曜日

EVM系のトークンってDEXにあげるときに、監査サービスみたいなのがあったが、

EVM系のトークンってDEXにあげるときに、監査サービスみたいなのがあったが、
Solanaはどうなのか調べてみた、SPLトークンだとできなそうだが・・・




🔥 まず大前提：Solanaでは「独自トークンプログラム」はほぼ使われない

Solanaのトークンは SPL Token Program（2020）か Token-2022（Token Extensions） のどちらかで作るのが普通。 ウォレットもDEXもこれらの標準プログラムしか扱わない。

つまり：

  • 勝手に新しいトークンプログラムを作って配布しても、ウォレットが対応しないのでユーザーは受け取れない

  • そのトークンを扱うには専用UIや専用ウォレットが必要になる

  • → 一般ユーザーを騙す用途には使えない

⚠️ しかし Token-2022 は「危険な拡張」を持てる

検索結果からも分かる通り、Token-2022 は SPL よりはるかに複雑で、悪意ある設計が可能。

危険な拡張例（すべて公式機能）

以下はすべて Token-2022 が標準で持つ機能：

1. Permanent Delegate（恒久デリゲート）

  • トークン発行者が ユーザーの残高を勝手に移動・焼却できる

  • 署名不要、ユーザーの許可不要

  • これは公式仕様（悪用可能）

2. Transfer Hook（転送フック）

  • トークン送信のたびに 任意の外部プログラムを強制実行

  • つまり「トークンを送るだけで任意コードが走る」

  • EVM の ERC-777 のコールバックと同じで、最も危険な拡張

3. Mint Close → 再初期化攻撃

  • トークン発行者が Mint を閉じて再初期化できる

  • 再初期化後に別の拡張（例：Transfer Fee、NonTransferable）を付けられる

  • 古いトークンアカウントは「旧ルールのまま」動く → プロトコル側が想定外の挙動になる

4. Transfer Fee（転送手数料）

  • 転送時に自動で手数料徴収

  • 手数料は受信側から引かれる（仕様が特殊）

  • 会計処理を誤るとプロトコルが損失

🧨 これらは「ウォレットをハックする」わけではないが…

ユーザー資産を奪うトークンを作ることは可能。

できること

  • ユーザーが受け取った瞬間に残高を勝手に移動（Permanent Delegate）

  • トークン送信時に任意コード実行（Transfer Hook）

  • DEX や Lending に預けられた資産を吸い上げる（Permanent Delegate）

  • プロトコルの会計を狂わせて資金を抜く（Transfer Fee）

できないこと

  • ウォレットの秘密鍵を盗む

  • 他のトークンを勝手に操作する

  • SOL を勝手に送金させる

  • ウォレットアプリを乗っ取る

Solana のセキュリティモデル上、トークンはそのトークンのアカウントしか操作できないため。

🧩 つまり「怪しいトークン」は作れるが、仕組みはこう

✔ トークン自体に悪意ある権限を付ける

✔ トークン転送時に悪意あるプログラムを呼び出す

✔ プロトコル側の検証不足を突いて資金を抜く

これらはすべて Token-2022 の公式機能の悪用。

🛡️ ユーザー視点での防御策

Solanaで怪しいトークンを受け取った時に確認すべきポイント：

  • Permanent Delegate が設定されていないか

  • Transfer Hook が付いていないか

  • Transfer Fee が異常に高くないか

  • Mint Close Authority が存在しないか

  • Token-2022 かどうか（SPLより危険性が高い）

これらは solana account <mint> で確認できる。







って、監査必要なんか・・・・








🏆 Solana監査の主要プレイヤー（EVM系＋Solanaネイティブ）

🔥 Solanaネイティブ（Solana特化）

これらは Rust / Anchor / CPI / アカウントモデル を深く理解しているため、Solana監査では最重要。

  • OtterSec Solanaネイティブの代表格。Wormhole、Jito Labs、Solana Foundation などを監査。 Solanaの TVL 36.8B を超える領域を担当。

  • Zellic Solana Foundation とも協業。Wormhole や Pyth を監査。Rust と Solana専門性が高い。

  • Neodyme Solanaの古参セキュリティチーム。CTF文化が強く、低レイヤーの脆弱性に強い。

  • Sec3 Solana専用の自動脆弱性スキャナとリアルタイム監視を提供。

  • Softstack 1,200+監査、ゼロエクスプロイト。Solanaのアカウントモデルや Anchor に強い。

🧩 EVM系の大手で Solana も対応している会社

EVMで有名な監査会社の多くは Solana もカバーしている。

  • Trail of Bits Rust解析・形式手法が強い。Solana runtime や SPL の監査も実施。

  • Halborn Solana Labs / Solana Foundation とも協業。インフラ・アプリ・スマートコントラクトを総合的に監査。

  • Quantstamp 初期からの大手監査会社。Solanaも対応。

  • CertiK 高ボリューム監査会社。Solanaも対応。

  • Hacken EU中心の大手。Solana監査も提供。

  • Cyfrin Codehawks などで有名。Solanaも対応。

  • Spearbit 世界中のトップ研究者を束ねる監査集団。Solana対応。

📊 まとめ：Solana監査は「EVMより専門性が高い」

Solanaは Rust / Anchor / CPI / アカウントモデル / runtime の理解が必要で、 EVMより監査難易度が高いと言われている。

そのため：

  • EVM監査会社でも Solanaを扱えるところは限られる

  • Solanaネイティブの OtterSec / Zellic / Neodyme / Sec3 が強い

  • Halborn / Trail of Bits は EVM・Solana両方でトップクラス



投稿者 時刻: 0 件のコメント:

2026年7月11日土曜日

GoogleのAntigravityがClaude DesktopやChatGPT Codex（旧Codex Desktop）と同じ感じになってる。

Antigravity 2.0系

いつのまにかIDEじゃなくなってる。

IDEモードもあるんだけど、他のChatエージェント系のデスクトップアプリとほとんど同じになってる。

スケージュール（定期タスク）もある。



投稿者 時刻: 0 件のコメント:

2026年7月10日金曜日

SUMinchoVを調べてみる。

「SUJPMLFV.TTF」は、ウイングアーク１ｓｔ社が提供する帳票出力システム「SVF（Super Visual Formade）」に付属している「SUMinchoV（明朝体）」というフォントファイルです。前回の回答にあった台湾の「AVECTOR TECHNOLOGY」社が製造したフォントをベースに、リコー社がSVF用にチューニングして提供しているものです。



どうやらSUMinchoVはLinux環境でMS明朝の代替品として作られた。

なのでWindowsの場合、MS明朝でほぼ同じになるっぽい。




SUMinchoV は MS明朝と同じグリフ順序を持つため、フォントファイルを差し替えるだけで済みます。グリフマッピングの調整は不要です。全GIDの一致を包括的に確認します



全角英数字・記号の11文字だけGIDがずれています。これらは「（」「）」「＊」「：」「Ｂ」「Ｅ」「Ｇ」「Ｌ」「Ｏ」「Ｒ」などです。


非常に良い知らせです。ずれは全角文字11個すべて一定の-304です。


つまり、これらの全角文字だけGIDが304ずつずれていますが、すべて同じ差分です。これは、SUMinchoVの作成時に全角英数字・記号ブロック（U+FF00〜）のGIDが304だけ後ろにずらされたことを意味します。


投稿者 時刻: 0 件のコメント:

2026年7月9日木曜日

Wrangler v4 の主な変更点

 

⚡ Wrangler v4 の主な変更点（実質 “小規模アップデート”）

1. Node.js 16 が完全に非対応

  • Wrangler v4 は Node.js 18 以上必須。

  • Node.js 16（2022年に EOL）はサポート外。

  • v16 のままだと Wrangler が正常動作しない可能性あり。

2. esbuild が v0.17 → v0.24 に大幅アップデート

  • 内部バンドラーが新しくなり、以下の影響が出る可能性：

    • ワイルドカード動的 import の挙動が変わる

    • esbuild は pre-1.0 のため、今後も Wrangler minor 更新で破壊的変更が入る可能性あり

  • 新しい JS 機能が利用可能：

    • using キーワード（Explicit Resource Management）

    • Import Attributes（例：with { type: "json" }）

3. CLI のデフォルトが “local mode” に変更

  • 以前：必要に応じて remote

  • 今回：すべてのコマンドが local をデフォルトに

  • リモート API を叩きたい場合は --remote を明示する必要あり

    • 例：wrangler kv list --remote

4. 古いコマンド・設定が削除

  • Wrangler v3 で非推奨だったものが完全削除

  • 古い flags や legacy 設定が使えなくなる

投稿者 時刻: 0 件のコメント:

2026年7月8日水曜日

surrealdb v3ってメモリ2Gじゃコンパイルできない。

Out of Memory で落ちる。
投稿者 時刻: 0 件のコメント:
登録: 投稿 (Atom)
あいうえお