PaPoo

3Dの地図や空間表現は珍しくなくなったが、実際に触って気持ちいいデモはまだ多くない。Orbifyの「Demo 2 - v72」は、Gaussian-splat という描画手法を使ったナビゲーションの見せ方を、ブラウザ上でどう成立させるかに焦点を当てたページだ。今回はそのデモページに何が置かれているのかを整理しつつ、単なる技術デモ以上の意味があるのかを見ていく。見た目は軽いが、裏側にはかなりはっきりした狙いがあるように読める。 元記事は、Orbify のウェブデモ「Demo 2 - v72」をそのまま公開したページだ。ページ中央では「Navigation Reimagined. Preparing Demo 2 - v72…」という文言が出ており、読み込み中は 0% から始まって「Loading Orbify scene」と表示される。つまり、完成品の紹介というより、まずはこの体験をブラウザで動かすこと自体を見せる作りになっている。 デモの説明には「interactive Gaussian-splat navigation visualization」とある。Gaussian splat

オープンソースのセキュリティ対応は、これまで「欠陥の詳細をしばらく伏せておけば、その間に利用者へ安全に直せる」という前提で回ってきました。Anil Madhavapeddy氏は、その前提がLLMや自律エージェントの登場で崩れつつある、と書いています。この記事は、OCamlのHTTPライブラリ `cohttp` のパッチ作業を起点に、公開前でも攻撃の兆候が走り出した現実を示し、OSSメンテナがどう守りを組み替えるべきかを考えるものです。単なる「AIで攻撃が速くなった」という話ではなく、公開・非公開・修正・配布の境界そのものが揺れている、というのが芯にあります。 著者はその日、OCaml向けの `cohttp` 6.3.0 に対するセキュリティ修正を出したと説明しています。内容は path traversal、つまり本来たどれないはずのパスにアクセスさせる脆弱性です。普通なら、こうした修正はまず私的に直し、影響を受ける利用者へ伝え、最後に公開アドバイザリを出す流れになります。ところが今回は、PR を開いてからほんの数分で、実運用中の自分のWebサーバーログに、そのバグの典型パターンを試す

SamsungがHot Chips 2026で示したのは、メモリをただの保管場所ではなく、計算の場としても使うProcessing-in-Memory、いわゆるPIMの具体像だった。LPDDR5Xの中にMAC演算器を入れつつ、外からは通常のメモリチップのように扱える、というのが肝だ。発想自体は昔からあるが、今回は理論ではなく、実装と運用の面倒さまでかなり踏み込んでいる。面白いのは、性能の話より先に、OSやキャッシュとの相性の悪さがはっきり見えてくるところにある。 元記事が紹介しているSamsungのLPDDR5X-PIMは、見た目こそ通常のLPDDR5X-9600チップだが、16 banksそれぞれにPIM blockを持たせた設計になっている。DRAMは内部で bank に分かれていて、通常は memory controller が bank を選び、row を開き、column access strobe、つまり CAS 命令でデータを読む。だがPIMでは、その bank にぶら下がった演算ブロックが内部帯域を直接使う。外部バスに縛られないので、16 banks全体で理論上 614

Rustで使える埋め込み型のkey-value storeとして、TurboKVというライブラリがGitHubで公開されています。単に「速いDBです」で終わる話ではなく、非同期API、batchの原子性、range scan、耐久性の切り替え、圧縮、バックグラウンドcompactionまで含めて、かなり実戦的な機能をひと通り揃えているのが目を引きます。Rustで小さく始めたいが、あとから保存方式や一貫性で困りたくない、という人には気になる存在です。今回はそのREADMEを軸に、何を目指したDBなのかと、そこから見える設計の匂いを追います。 TurboKVは「A fast, simple, and embedded key-value store for Rust」と名乗る、非同期の埋め込み型データベースです。READMEでは、atomic batches、ordered range scans、configurable durability、compression、background compaction を備えると説明されています。つまり、単純な `get` / `put` だけの

Tencentが自社の大規模言語モデル「Tencent Hy4 preview」を公開し、同時にオープンソース化した。単に新しいAIモデルを出したという話ではなく、770Bという巨大な総パラメータ数、49Bのアクティブパラメータ、100万トークン超の長い文脈処理を前面に押し出しているのが特徴だ。しかも用途は研究室のデモではなく、coding、office work、scientific researchのような実務寄りの場面に置かれている。Tencentがこのモデルをどう位置づけ、どこで使わせようとしているのかを見ると、いまの生成AI競争の焦点がかなりはっきりしてくる。 Tencentの発表によると、Hy4 previewは次世代のlarge language modelで、総パラメータ数は770B、実際に推論時に動くactive parametersは49B、context windowは100万トークンを超える。要するに、モデル全体としてはかなり大きいが、常時全部を動かすわけではなく、必要な部分だけを使って計算効率を確保する設計だと読める。Tencentはこのモデルを、実際の生産性

音楽の制作や練習で、ボーカルだけ抜き出したい、ドラムだけ消したい、あるいはベースの動きを追いたい、という場面は珍しくありません。GitHub に公開された StemDeck は、そうした用途に向けた stem separation ツールです。クラウドに音源を上げず、自分のPCの中だけで処理を完結させる点を強く打ち出しています。最近の音声AIは便利さと引き換えにアップロード前提になりがちですが、そこに違和感を持つ人にはかなり刺さる作りだと思いました。 StemDeck は、音楽ファイルをいくつかの“stem”に分けるためのデスクトップ向けプラットフォームです。対応している入力は MP3、WAV、FLAC、OGG/Opus、MP4、M4A で、YouTube の URL を貼り付けて使うこともできます。分割できるのは最大 6 系統で、ボーカル、ドラム、ベース、ギター、ピアノ、other に切り分けます。見た目は DAW 風のマルチトラックミキサーになっていて、各 stem を mute や solo で切り替えたり、音量を調整したり、波形を拡大表示したり、区間ループをかけたり、そのまま個

LLMに長時間の作業をさせると、途中まで積み上げた前提を忘れたり、いったん否定したはずの仮説をまた持ち出したりする。今回取り上げる記事は、その不安定さをどう抑えるかを考えた末に、著者が「記憶」を会話履歴ではなくプログラム解析の問題として捉え直した話だ。単なるメモリ強化の工夫ではなく、Datalog というルールベースの仕組みまで作ってしまったところが面白い。しかもそれを、脆弱性調査の実務にかなり近い形で組み立てている。 著者はここ数か月、脆弱性調査向けに LLM agent を試していた。大きなコードベースを歩き回ったり、見慣れないサブシステムを説明したり、攻撃面を探したりする用途では、LLM はかなり頼れるようになってきたという。ただ、調査が数時間単位に伸びると、同じ問題が何度も起きた。モデルが、すでに否定された仮説を再び提案したり、間違いだと分かった前提に基づいて推論し続けたりするのだ。人間が「それは違う」と伝えても、その前提にぶら下がっていた他の結論まで自動では消えない。 最初は、こうした混乱を減らすために memory system を探っていた。一般的な方法は、古い会話や観察

Apple SiliconのMac上で、仮想のiPhoneを起動するためのCLIツールがGitHubに公開されています。名前は `vphone-cli`。見た目は地味ですが、中身はかなり攻めています。iOS向けのファームウェアを準備し、パッチを当て、DFU復元を経て、カスタムファームウェアを入れ、最初の起動まで一気通貫で進められるようにしているからです。単なるデモではなく、研究用途や自動化テストまで視野に入った道具に見えます。 この手の話は、単に「面白い」で終わりません。AppleのVirtualization.framework、iOSの復元、AMFIやSIPの制約、さらにはSileoやTrollStoreまで出てくるので、macOSとiPhoneの境界がどこまで揺らされているのかを知る材料になります。元記事はREADME中心ですが、そこに書かれている内容だけでも十分に濃いです。 `vphone-cli` は、Lakr233 が公開している公開リポジトリで、README には「Apple の Virtualization.framework を使って、PCC research VM

まず、自分のケースかどうかを切り分けます。この症状は、Claude Code の実行中に `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` という文字列が出て、`keys=` と `messages=` の数が一致していない形で報告されています。今回寄せられた 2 件の issue はどちらも未解決で、片方はセキュリティ監査の依頼中、もう片方は Claude Opus 5 の挙動変化を訴える内容でした。報告された場面は違いますが、出ているエラー本体は同じです。参照できる issue は [#90610](https://github.com/anthropics/claude-code/issues/90610) と [#90514](https://github.com/anthropics/claude-code/issues/90514) です。 症状の出方は、少なくとも issue 上ではかなり似ています。たとえば #90610 では、ローカルで動かしている Gitea の安全性確

このエラーは、少なくとも今回確認できた issue では、Cowork の VM サービス側で起動に失敗しているときに出ています。ユーザー向けの文言は同じでも、原因は 1 つではありません。 自分のケースかどうかを見分ける材料としては、まず「どの製品で出ているか」が重要です。[#39010](https://github.com/anthropics/claude-code/issues/39010) は Windows 10 Pro 上の Cowork で、起動時に `VM service not running. The service failed to start.` が出ています。報告者は、実体としては MSIX パッケージ配下の `AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\` に作られた VM 用の `rootfs.vhdx` や `smol-bin.vhdx` が NTFS 圧縮を引き継ぎ、Hyper-V が圧縮された VHDX をマウントできずに失敗していたと書いています。そこで見えていた HCS エラ

このエラーは、Claude の Cowork/interactive session で、隔離された Linux 環境が立ち上がらないときに出ています。少なくとも issue 報告上では、ファイル操作の機能は動くのに、shell/sandbox だけが落ちるケースがありました。 該当する報告は [#70199](https://github.com/anthropics/claude-code/issues/70199) です。 切り分けの起点はかなりはっきりしています。`Workspace unavailable. The isolated Linux environment failed to start (VM service not running. The service failed to start.)` が出ていて、しかも Read/Write/Edit のようなファイル系ツールは使える。ならば、壊れているのはワークスペース全体というより、隔離 Linux 環境の起動部分だと考えるのが自然です。 別系統の issue ですが、Cowork の周辺で「内部の実行環境や受け

Claude Code 活用 TIPS が投稿した記事の一覧です（公開のみ・新着順、最大 100 件）。 *最終更新: 2026-08-29 23:37 UTC* https://papoo.work:3443/doc/c281086c81b72864 https://papoo.work:3443/doc/65b2170f158c8bb2 https://papoo.work:3443/doc/a3ba132682adaf4a https://papoo.work:3443/doc/b6e67b7d4727c323 https://papoo.work:3443/doc/2fd3dc6e80a9435a https://papoo.work:3443/doc/a4be38744afbb059 https://papoo.work:3443/doc/ac2ce76f652ce948 https://papoo.work:3443/doc/761477ecd8ee524c https://papoo.work:3443/doc/a17a25c33edf2d3c https://p

長時間いじったあとに「全部見直してください」と投げるのは、だいたい破綻する。差分がでかすぎて、Claude Code も人間も本当に大事なところを見失うからだ。ここでやるべきなのは、差分圧縮と要点整理だ。作業の途中で散らかった変更を、あとから読める単位に畳み直す。変更点の量を減らす話ではない。意味の粒度をそろえる話である。 Claude Code では、ひたすら作業を続けたあとに「変更を要点だけ残す形にして」と頼むと、雑多な修正をまとめ直す助けになる。ファイル整理でも、文書作成でも、コード修正でも効く。要は、あとで自分か相手が追える状態に戻す作業だ。 最初にやることは単純だ。いったん変更を見せて、何を残し、何を捨てるかを明確にさせる。 ```text ここまでの変更を差分圧縮したい。 次の3つに分けて整理してほしい。 1. 本当に残すべき変更 2. まとめられる変更 3. 捨ててもよい一時的な変更や試行錯誤 出力は、変更点の要点を箇条書きで短くまとめて。 そのあと、必要ならコミットメッセージ案も出して。 ``` この頼み方のいいところは、Claude Code に「全部説明しろ」と言わ

「たまに起きる」「さっきは動いた」──その手の話は、だいたい不具合そのものより先に、話の組み立てが崩れている。Claude Code で詰まるのもそこだ。再現しないまま雑に修正へ飛ぶと、原因と対処がズレる。不具合切り分けと再現性確認を先に固めるだけで、勘違いはかなり減る。 Claude Code は、曖昧な状況説明をそのまま飲み込むと、もっともらしい修正案を出してくる。そこに人間側の思い込みが乗ると、別の場所を直して終わりだ。だから最初にやるべきは「直すこと」ではなく、「再現する条件を削ること」になる。 たとえば、こんな頼み方が効く。 ```text この不具合を再現したいです。まず修正はしないでください。 次の情報を整理してください。 どの操作で起きるか 毎回起きるのか、たまに起きるのか 何が起きたように見えるか 直前に変えたファイルや設定は何か 再現手順を1つずつ最小化するならどこまで絞れるか 必要なら、再現確認用のチェックリストを作ってください。 ``` この頼み方のいいところは、Claude Code を「修理係」ではなく「切り分け係」として使える点だ。いきなりコードを書かせる

変更を見ただけで納得した気になると、だいたい後で崩れる。差分は「何を変えたか」しか教えてくれないが、ログは「そのとき何を考えていたか」を残す。Claude Code では、この二つを並べて追う癖をつけると、作業のズレがかなり減る。作業ログ、履歴確認、どちらの感覚でも使えるやり方だ。 特に効くのは、ファイル整理や文書作成みたいに、完成物そのものより「なぜそうしたか」が重要な場面だ。最初はうまくいったように見えても、後から「この並び替えは何のためだったのか」「この削除は本当に安全だったのか」で止まる。筆者も一度、メモの整理を Claude Code に任せたあと、変更履歴だけ見て満足していたら、不要な重複を消したつもりで別の版を残していた。ログを並べていなかったせいで、判断の筋道が消えていたわけだ。 やることは単純だ。Claude Code に作業を頼むとき、最初に「作業ログを残しながら進めてほしい」と明示する。次に、区切りごとに変更内容と判断理由を短く書かせる。最後に、必要なら Git の差分やファイルの更新履歴と見比べる。これだけで、単なる「結果の確認」から「判断の確認」に変わる。 た

PR にそのまま貼る説明文を、いきなり Claude Code に書かせると、だいたい散らかる。要点が混ざる。変更の理由が薄まる。読んだ相手が「で、何を見ればいいの」となる。 ここで効くのが、先に論点整理をさせて、PR説明の芯を作ってから本文に落とすやり方だ。非エンジニアの作業でも同じで、ファイル整理でも文書作成でも、先に「何を伝えるか」を固めるだけで手戻りがかなり減る。 Claude Code は、雑に頼むと雑に広げる。これは欠点というより、指示のあいまいさをそのまま反映するだけだ。だから最初にやることは、文章を書かせることではない。論点を切ることだ。 PR説明、論点整理、この二つを先にやると、説明の芯ができる。芯ができると、後から差分を見た人が追いやすい。レビューの質も上がるし、あとで自分が読み返したときの恥ずかしさも減る。 やり方は単純だ。まず変更内容を丸ごと説明させるのではなく、論点だけを短く抜き出させる。たとえばこんな頼み方でいい。 ```text この変更について、PR説明を書く前の論点整理をしてください。 以下の観点で、重複しないように箇条書きにしてください。 変更の目的

コミット直前に「たぶん大丈夫」で流すのが、いちばん雑に事故る。差分が少ない日ほど油断するし、ファイル整理でも文書作成でも、ひとつの見落としがあとで地味に効く。 Claude Code には、コミット前確認、見落とし確認をやらせておくといい。要は、コミットする前に「何を変えたか」「消し忘れたものはないか」「別ファイルに漏れていないか」を一度洗う。人間がやると集中力が切れた瞬間に抜けるが、Claude Code は淡々と一覧化してくれる。そこが強い。 まず、作業ツリーを見せて、変更点を要約させる。これだけでも十分役に立つ。 ```bash claude ``` Claude Code が起動したら、こんなふうに頼む。 ```text 今の作業ツリーの変更を確認して、コミット前に見落としがないか洗ってください。 次を順に見てください。 変更ファイルの一覧 追加・削除・名前変更の有無 差分の要点 置き忘れた設定値、コメントアウト、デバッグコードの残り 仕様上まずい変更や、関連ファイルの更新漏れ 最後に、コミット前に人間が目で確認すべき点を短く箇条書きで出してください。 ``` この頼み方のいい

修正した説明を、そのまま長文で押しつけるのはだいたい失敗する。読む側は「で、何が変わったのか」だけ知りたいのに、前提や経緯まで全部読む羽目になるからだ。ここで効くのが、要約だ。さらに引き継ぎメモとしてそのまま使える形に落としておくと、次の人が拾いやすい。 Claude Code は、長い説明を短く圧縮するのが得意だ。ただし、雑に投げると要点まで薄まる。修正後の内容を、誰に渡しても同じ理解になる粒度に削るには、最初に「何のための要約か」を言い切るのがコツになる。単なる短縮ではなく、引き継ぎ用のメモにする。ここを外すと、ふわっとした文章が返ってきて終わる。 たとえば、修正した文章がこれだとする。 ```text この機能は、重複したファイル名をまとめて整理できる。対象フォルダを選ぶと、同名ファイルを一覧化し、最後にまとめて確認してから処理を実行する。誤削除を避けるため、最初はプレビューだけ表示する。 ``` これを Claude Code にそのまま丸投げするより、次のように頼むほうが使える出力になる。 ```text 次の説明を、引き継ぎメモとして使えるように短く要約してください。 条件

「直しました」で終わらせると、たいていどこかがまだ死んでいる。見た目は直っていても、テストは別の場所で赤いまま、あるいは差分だけ眺めると肝心の修正が抜けている。そこで効くのが、検証と照合だ。テスト結果と git diff を突き合わせる。これだけで「直したつもり」のまま次に進む事故がかなり減る。 Claude Code でも同じで、修正依頼を出して、返ってきた変更をそのまま信じるのは雑すぎる。AI はちゃんと直すこともあるが、関係ない箇所を触ったり、テストの失敗原因を外したまま別方向をいじったりもする。だから最後は、人間が「テストが指している場所」と「差分で実際に変わった場所」を重ねて見る。ここをサボると、手戻りが増える。かなり露骨に増える。 たとえば、こんな流れだ。 ```bash git diff ``` で変更点を見てから、 ```bash npm test pytest go test ./... ``` でテストを走らせる。失敗したら、そのエラーメッセージと diff を同時に見る。Claude Code に頼むときも、ただ「直して」では弱い。こう投げるといい。 ```tex

自分で書いた差分ほど、雑に見てしまう。そこが一番まずい。 「差分レビュー」や「レビュー依頼」を自分宛てに投げる感覚で Claude Code を使うと、勢いで書いた変更を一度外に出せる。すると、読みにくい命名、説明不足のコメント、余計なファイル変更が、かなり早い段階で見つかる。 人間の目は、実装した瞬間の文脈に引っ張られる。だから「動くしまあいいか」で流しやすい。Claude Code に赤入れさせる価値は、そこを機械的に叩ける点にある。コードの正しさだけでなく、差分の見た目、変更範囲の広さ、説明の足りなさまで見させると、後で恥をかく率が下がる。 やり方は単純だ。作業が一段落したら、未コミットの差分をまとめて見せて、レビュー観点を先に渡す。Claude Code はターミナルから使うエージェントなので、ローカルのファイルを見ながら指摘を返せる。ここで大事なのは、「直して」と丸投げする前に、まず「レビューして」と頼むことだ。いきなり修正させると、確認したい論点まで勝手に書き換えられることがある。 たとえば、こんな依頼文で十分だ。 ```text 以下の差分をレビューしてほしい。 目的はコ