iPhoneのホーム画面のバグ？仕様？

iPhoneですべてのホーム画面が完全に埋まっている状態だとする。

この状態でPWA（プログレッシブウェブアプリ）でホーム画面に追加をする。

追加したものは検索すると一覧には出る。

この検索一覧のモードは、長押しでアイコンの配置を変える機能だが、埋まっているので配置は変えられない。

このモードは削除は存在しない。

削除はホーム画面から長押しのみ。

ホーム画面をすべて見渡しても、追加したアイコンは存在しない。

ので削除不可。

codexのwebsearchの仕様がいつの間にか変わってた。

Alibabaのagent scopeを使う

Alibabaのagent scopeを使う

https://github.com/agentscope-ai/agentscope

Limitless AI販売終了

Limitless AIのペンダント型デバイスの新規販売は終了しています。

Meta社によるLimitless社の買収に伴い、2025年12月5日をもって公式ストアでの販売が停止されました。

claude opus 4.5で変な住所

株式会社T-Trustで、

お問い合わせメールを作らせたら、なぜか以下の住所をどっからともなく拾ってきた。

大阪府大阪市中央区南船場3-9-6

鶏Soba 座銀 にぼし店 （トリソバ ザギン） - 心斎橋/ラーメン

なんだこれ？新たなLLM向けの最適化か？？？

bingでサジェストが表示されない時が発生した。

なぜかbingでサジェストが表示されない問題。

実験した結果。

# 場所 | OS | Browser | 結果

自宅 | windows | chrome | OK

自宅 | windows | firefox | OK

自宅 | linux | chrome | OK

自宅 | linux | firefox | OK

RA | windows | chrome | OK

RA | windows | firefox | OK

RA | linux | chrome | OK

RA | linux | firefox | NG

よくわからん。

linuxでfirefoxでCPUの速度が遅い時に制限があるとしか思えない。

TraeのSOLOモード。

AI搭載IDE(vscode)のTraeのSOLOモードにすると、

完全にbolt.newっぽい見た目になった。

cursorの新モードっぽいとも言える。

htmlの入力フォームにリアルタイム検索とFEP（フロントエンドプロセッサ）の挙動

htmlの入力フォームにリアルタイム検索とFEP（フロントエンドプロセッサ）の挙動。

https://youtu.be/NYJgymLON2Q?t=840

確かに昔はよく合った問題だが、最近は何も考えずに実装できてるよな・・・

俺の組んでいるsvelteで入力フォームでのFEP(IME等)の挙動が正常なので、実装を確認した。

「入力中（IME未確定状態）なのに、バックグラウンドで検索が走り、かつIME入力も邪魔されない」 という点ですね。

これは以下の3つの要素が組み合わさって実現されています。

1. 入力を即座に検知する bind:value

Svelteの bind:value={query} は、ブラウザの input イベントを監視しています。

現代のブラウザでは、IMEで文字を打っている最中（未確定の「やま」の状態）でも input イベントが発生し、その内容がリアルタイムで変数 query に反映されます。

これにより、変換キーを押す前の「ひらがな」の状態で検索を開始できます。

<!-- frontend/src/lib/InPage.svelte -->

<input

  bind:value={query}  <!-- ここで入力内容を常に変数queryと同期 -->

  ...

/>

2. 0.25秒の「待機時間」 (Debounce)

これがIME入力をスムーズにしている最大の要因です。

文字が入力されるたびに即座にAPIを叩くと、処理が重くなり入力がカクつく原因になりますが、この実装では 「入力が止まってから0.25秒後に検索する」 という制御（Debounce）が入っています。

  function scheduleSearch(input) {

    // ...

    // 前回の待機があればキャンセル（連打している間は検索しない）

    if (searchTimeoutId) clearTimeout(searchTimeoutId);

    

    // 0.25秒後に検索を実行

    searchTimeoutId = setTimeout(() => {

      void doSearch(normalized);

    }, 250);

  }

「やま」と素早く打っている間は検索が走らず、打ち終わって一瞬手が止まったタイミングで検索が走るため、IMEの入力を邪魔しません。

3. 入力欄を「書き換えない」

検索結果（suggestions）が返ってきたとき、このプログラムは入力欄（query）の中身を一切いじりません。

単に候補リスト（ドロップダウン）を表示するだけです。

もしここでプログラムが「検索結果に合わせて入力欄の文字を補完する」ような動きをすると、IMEの未確定文字が確定されてしまったり消えたりしますが、「入力欄はユーザーに任せて、結果は下に表示するだけ」 という実装になっているため、IME変換を継続したまま検索結果を見ることができます。

まとめ

• Svelteの機能: 未確定の文字もリアルタイムで変数に取り込む。

• Debounce: 入力中は検索を我慢し、手が止まったら裏でこっそり検索に行く。

• 表示の分離: 検索結果が出ても入力欄には触らないので、IMEが途切れない。

この組み合わせにより、「入力しながら（変換しながら）検索結果が出る」という体験になっています。

gemini3.0Proが、Claude4.5と比べると頭悪い

 

リリース直後から数日、同じような作業をgemini3.0proで行った・・・

gemini3.0Proが、Claude4.5と比べると頭悪い。

プログラムでちょっと難しい条件だと、間違った回答を頻発する。

これはcursorがよくない可能性もあるが、

（Windsurfでgemini 3proでも先に別場所の実装を確認しているように見えた、cognition aiの新開発の高速grepが効いてるっぽい）

同じ条件でclaude4.5 thinkingだと起きていないような気がする。

自分の体感で実際に計ってないので、正確性に欠けるが・・・メモとして残しておく。

cloudflare workersの実行時間制限

Cloudflare Workers の無料版と有料版における 実行時間（CPU 時間／壁時計時間） の主な制限は以下の通りです：

---

✅ 主な制限

• 無料プラン（Free）では「CPU 時間」が 10 ms／リクエスト が目安となっています。 Qiita+3Zenn+3Cloudflare Docs+3

  • この「CPU 時間」というのは、実際にスクリプトが CPU を使って処理している時間であり、外部への fetch／待機時間などはカウントされません。 Stack Overflow+2Cloudflare Docs+2

• 有料（Paid／Standard）プランでは、CPU 時間をユーザーが設定でき、最大で 5 分（300,000 ms）／リクエスト まで設定可能というアップデートが行われています。 Cloudflare Docs+2Cloudflare Docs+2

• 壁時計時間（real-time／wall time。待機も含む）は、明確な厳しい上限がない場合が多く、「クライアントが接続を保っている間」は実行継続できるという記述があります。 Cloudflare Docs+1

---

⚠️ 注意すべきポイント

• 無料プランの「10 ms」というのは目安であって、必ずピッタリ 10 ms で打ち切りというわけではありません。ただし、常時これを大きく超えるような処理を実装すると、リクエストが失敗する・スクリプトが終了される可能性があります。 Answer Overflow+1

• 「CPU 時間」が 10 ms を超えても、処理の大半が外部呼び出し・待機であれば、無料プランでも実用に耐えるケースがあります。外部 API 呼び出し中は CPU を使っていないため、カウントされないためです。 Zenn+1

• 有料プランで “最大 5 分” というのも「CPU 時間」であって、壁時計時間での待機（たとえば外部 fetch を待つ時間）が含まれない点に留意です。 Cloudflare Docs

---

🎯 実際にどちらを使うべきか

• 簡単なエッジ処理、ヘッダー操作、認証チェック程度の軽量な処理なら 無料プランでも十分可能です。

• ただし、画像処理・暗号化・大きな JSON の変換・D1/R2 を用いたデータ操作など「CPU を使う処理」がある場合は、 有料プラン を検討すべきです。

• また、レスポンスに対して長時間待ちが発生する（例：長い API チェーン・大きなデータの読み込み）ようなら、有料プランで CPU 時間の上限を広げるか、別設計（バッチ処理・キュー処理）を検討した方が安全です。

✅ 最新の制限（2025 年時点）

• Cloudflare Workers の公式ドキュメントによれば、**CPU 時間（CPU time）**とは「実際に CPU が処理をしている時間」であり、外部フェッチ／I/O 待ち時間などはカウントされない、という定義が明記されています。 Cloudflare Docs+1

• 同ページでは、デフォルトの CPU 時間上限が 30 秒（30,000 ms） で、設定を変更することで最大 5 分（300,000 ms） に拡張できると記載されています。 Cloudflare Docs+1

• 無料プラン（Free）について、10 ms 程度という言及が複数の非公式記事にあります：

  • StackOverflow 解答： “A Worker may consume up to 10 ms on the free plan…” Stack Overflow

  • Zenn 記事： 「無料枠だと CPU 実行時間が10 msという制限があり…」 Qiita+1

  • Publickey というまとめ記事でも「1リクエストあたり10ミリ秒までの CPU タイム」 と紹介されています。 Publickey

• 有料プラン（Standard やそれに相当するプラン）で「最大 5 分まで CPU 時間を設定可能」と公式にアップデートされています。 Cloudflare Docs

---

⚠️ 注意すべきポイント・補足

• 「10 ms まで」は 保証された上限値 ではなく、無料プランでは「目安／推奨／典型的な範囲」であるという記述もあります。たとえば、「10 ms を超えると即失敗」という明確な記載ではなく、「10 ms 程度が普通だが超えると挙動が保障されない可能性あり」というものです。 koryporter.com+1

• 無料プランで 10 ms を超えても実際に動いている事例も報告されており、「10 ms 超＝必ずエラー」というわけではありません。 Qiita+1

• また、「壁時計時間（wall-time／実際の経過時間）」については、CPU 時間制限とは別に「クライアント接続が続いている限り実行可能」という記述もあります。つまり I/O 待ちが多いような処理では「実経過時間」は長くなりうるということです。 Stack Overflow+1

• プランや契約内容・リージョン・発展状況によって制限値が変わる可能性があります。公式ドキュメントで最新確認することが推奨されます。

• 「無料プランでも CPU 時間をユーザー設定できる」「5 分まで拡張できる」というのは有料プラン対象、かつ設定変更 (wrangler など) が必要という条件付きです。無料プランではこの拡張ができないケースが多いです。

google IDE antigravity

俺はcursorもwindsurfもtraeもcodexもclaude codeもあるので、あえてAgent-drivenをやってみる。

アラビア配列のキーボードを日本語配列にできるのか？

Arabic (101) 配列、電源キーも含めて80個の物理キー。

キーが足らなそうだが、基本的な記号が日本語配列にできればよしとする。

Zenbook S 16 UM5606WA Ryzen AI 9 HX 370 -arabic-

カーソル以外は、中華PCのキーボードシリコンカバーに印字ついてるので代用できそうだが・・・

電源とDELの位置が逆という、独特すぎる形状。

一応、売ってはいるが日本語印字版はない。

ちなみにUM5606WAの日本国内版はエンターが大きい。

https://ja.aliexpress.com/item/1005008772054382.html?spm=a2g0o.productlist.main.3.64071f53OcpkQH&algo_pvid=0ec535f9-9da4-4df9-a589-e2885d4731ab&algo_exp_id=0ec535f9-9da4-4df9-a589-e2885d4731ab-2&pdp_ext_f=%7B%22order%22%3A%2226%22%2C%22eval%22%3A%221%22%2C%22fromPage%22%3A%22search%22%7D&pdp_npi=6%40dis%21JPY%21399%21179%21%21%212.49%211.12%21%402141115b17636155032138136e463e%2112000047115798734%21sea%21JP%212371207844%21X%211%210%21n_tag%3A-29919%3Bd%3A5ce233ce%3Bm03_new_user%3A-29895&curPageLogUid=yhFtRPLRY6fX&utparam-url=scene%3Asearch%7Cquery_from%3A%7Cx_object_id%3A1005008772054382%7C_p_origin_prod%3A

一応、公式に聞いてみる。

チャットサポートが楽すぎる、対応超早い！

結論。

シールを張るぐらいしか方法がない。

UnrealEngineクロスコンパイラ

WindowsからLinux用のビルドの為のツール。

https://us05web.zoom.us/j/82573256251?pwd=20vJbDKcs3emp1GNpcaU3BXJTmwS59.1

chrome拡張機能で押しても正しく発火しないとき

chrome拡張機能で押しても正しく発火しないとき、

現実のクリックの判定をバイパスできる許可がない為。

event.isTrusted === true

cometやfellouなら押せる。

相川七瀬の125年前の曲

google曰く

1900年の曲？！

 

そうだろうとは思ったが、cloudflare workersでfirebase-admin動かん

cloudflare workersでfirebase-admin動かんよな。

実際にやってみると・・・

Cloudflare Workers 環境で firebase-admin をそのまま使うと

EvalError: Code generation from strings disallowed が出るので、

Workers の WebCrypto 制約に合わせて 事前ビルド済みまたは REST API ベース のライブラリへ切り替えるのが現実的です。

firebase-admin-cloudflareって実装があるとかないとか（実際ない）

Visual Studio Community 2026にする

UnrealEngineも正しく連携できたよ。 

 

2022のプロジェクトもちゃんと動く。

cursor 2.0のComposer 1

ちょい前から並列エージェントにはなっていたが、

独自LLMモデルのComposer 1が、コードに関しては、早くていいらしい。

2800行の+page.svelteを指示通りに分割できるか、チェックしてみる。

どのように分割するかは指示した。

手順１が終わって次の手順が示されたが、以下の状態。

context use: 77.3%

所要時間: 5分

コンテキストが足らなくなりそうだが、このまま続行してみる。

context use: 96%

ビルドできないソースが完成された。

コンテキストがあふれたが、無視して続行。

context use: 88%

7回ぐらいコンパイル失敗したが、最終的にコンパイルが通った。

通ったものを動作確認したが、問題なし。

こういう用途ならいいかも。

LLMによる最適化を試してみたい

ShinkaEvolve

OpenEvolve

Sakana AI⁠⁠、ハイパフォーマンスなAIアルゴリズム探索フレームワーク「ShinkaEvolve」をオープンソースとして公開

eKYCの状況を簡単に説明

eKYCの状況と将来。

# 2025年06月に犯収法施行

## 犯罪収益移転防止法（犯収法）

- 現行のホ方式は2027年11月まで

- 現行の方式では、金融系は人間の目視が必要

- 新方式（ル方式）では、業種に問わず目視不要

ややこしいのが廃止して採番するので（完全に愚かな手法だが）

- ホ方式が廃止になり、2027年以降からチ方式がホ方式に・・・

最大手のLiquid KYCは2025年11月から。

## チップ読み取るだけなら自作eKYCが可能だが？

金融庁・総務省・警察庁などが定めるガイドラインに準拠している必要があります。

本人確認業務を行うには「登録本人確認事業者」や「特定事業者」の認可が必要。

https://www.soumu.go.jp/kojinbango_card/kojinninshou-02.html

一般ユーザーは、サイトが「公的に承認されたeKYC事業者を使っているか」を見抜けません。

ただし、多くの事業者は以下のような形で信頼性を示します：

サービス名の表示（例：「本人確認はLIQUID eKYCを利用しています」）

認定番号やガイドライン準拠表記

金融庁登録番号・特定事業者番号の明示

これらが明示されていないサービスでは、「形式的には本人確認をしているが、法的効力が限定的」な場合もあります。