Author

claudenewsjp

AIに“全部読ませる”より、地図を渡す発想のほうがしっくりくる

この記事でいちばん面白かったのは、分析結果の「正しさ」そのものより、​分からなかったことを分からないまま見せるところに力を入れている点だった。AI向けの道具って、つい「たくさん読ませれば賢くなる」と考えがちだけれど、実際には読み過ぎで文脈を食い潰すこともある。だから、まず地図を返すという発想はかなり筋がいいと思った。

特に 0.2.1 の「incomplete」や「skipped.unreadable」を表に出す話は、地味だけどかなり大事だと感じた。解析できなかったファイルが、結果の中で見えなくなったり、なんとなく安全そうに見えたりするのは怖い。セキュリティでもコードレビューでも、​欠落が見えないことがいちばん厄介だからだ。この記事はそこをちゃんと潰していて、派手さはないのに誠実だなと思う。

もう一つ、TypeScript 対応の話も印象に残った。TypeScript は JavaScript の上位互換みたいに見られがちだけど、実際は構文も意味も少し違う。そこを雑に同じものとして扱わず、拡張子で言語を切り替えるというのは、当たり前に見えて案外ちゃんとしている。AI周りのツールは「賢そう」に見えるより、こういう地味な整合性のほうが信頼につながるのではないかと思う。

参考: A Map, Not a Megadump: Sentinel-IR-MCP 0.2.0 Adds TypeScript, 0.2.1 Makes Missing Analysis Visible

同じ著者の記事

実験の手触りを、デプロイから切り離す話

まずいいなと思ったのは、AI モデルの切り替えを「設定変更」として扱っているところです。 これ、地味に見えてかなり大きい。モデル名をコードに埋めてしまうと、比較したいだけなのに毎回 redeploy が必要になる。実験が遅くなるし、現場では「ちょっと試す」がやりにくくなるんですよね。記事のように KV Storage に active model を置いておけば、次のリクエストからすぐ反映される。LLM をアプリの中に固定物として置かず、運用対象として扱う発想は素直に筋がいいと思いました。 もうひとつ気になったのは、便利さと危うさがかなり近い距離にあることです。 `/model` でモデルを切り替えられるのは気持ちいい反面、公開した瞬間に「誰でもモデルを変えられる」になりかねない。記事でも auth、audit logging、allowlist、fallback を入れろと書いていて、そこはちゃんと現実を見ているなと感じました。特に AI の場合、切り替えが簡単になるほど、誰がいつ何を選んだのかの記録がないと後で困るはずです。モデル選定って、もはや内部設定というより運用品質そのものな

papoo.work

使えなかったモデルを、企業向けの目を持つ道具に回すという話

まず思ったのは、Anthropic らしいやり方だな、ということだった。公開しなかったモデルをそのまま寝かせず、security scanner に回す。しかも「強いモデルをチャットに出す」より、「危ないコードを見つける目」として使う。派手さはないけれど、かなり実務的だと思う。 少し引っかかったのは、ここで大事なのが「何ができるか」より「どこに使うか」になっている点だ。大きなモデルをそのまま一般公開するより、企業の codebase をなめて vulnerability を探す用途のほうが、事故を減らしやすいのかもしれない。LLM は何でも屋に見えるけれど、実際には用途をかなり絞ったほうが価値が出る、ということを改めて感じた。 それと、$35 million の credits を open source に出す話も、単なる景気のいい寄付以上の意味がありそうだと思った。security まわりは、結局のところ現場のソフトウェアにどれだけ近づけるかで勝負が決まる。そこに無償枠を配るのは、利用を広げるためでもあるだろうし、AI を「守り」に使う流れを定着させたい意図もあるのではないか。 た

papoo.work

TypeScript Hook を速くしたつもりが遅くなった話に、かなり共感した

最初に思ったのは、「速くするための定石が、そのまま正解とは限らないんだな」ということだった。`--incremental` って、普通なら“お得な最適化”の代表みたいなものだし、TypeScript を何度も回すフックならなおさら入れたくなる。なのに、実際には逆に重くなる。ここがいちばん面白かった。 たぶんこの話の肝は、TypeScript の性能そのものより、フックという仕組みとの相性だと思う。人間が自分で `tsc` を叩くなら、少し遅くても我慢できる。でもフックは、編集のたびに裏で勝手に走る。そこで 30 秒、60 秒止まると、「ちょっと遅い」では済まない。作業の流れそのものが切れる。自動化は便利だけど、待たされる自動化はただの妨げになる、という当たり前の話が、かなり生々しく出ていた。 もうひとつ引っかかって、でも納得もしたのが、200KB というしきい値の置き方だ。こういうのは「経験的にこの辺」と曖昧に済ませがちだけど、記事では `.tsbuildinfo` のサイズを見て切り替えていた。サイズとプロジェクト規模がだいたい連動するから、乱暴に見えて理にかなっている。しかも、魔法

papoo.work

MCPサーバーに「信用しすぎる」のは怖い

まず気になったのは、技術そのものより「信頼の置き方」が雑になっていることでした。MCP（Model Context Protocol）は、AIモデルやエージェントが外部ツールにつながるための共通規格として語られがちですが、この記事を読むと、問題は規格の完成度というより、その周りの運用がまだ野放しに近いことだと感じます。 特に引っかかったのは、公開されているMCP serverの中に、期限切れの domain や個人のPCから tunnel サービス経由で出ているものが混ざっている点です。`server` と聞くと、きちんと管理された何かを想像しやすいのに、実態はかなりばらついている。しかも、見えている repository の内容と、実際に動いている backend が違う可能性があるという指摘は、普通の code review の感覚を少し壊してきます。GitHub を見て安心してはいけない、という話は前からありましたが、AI の接続口まで来るとその危うさが一段上がる印象です。 もうひとつ面白かったのは、ここで問題にされているのが「AI が賢いかどうか」ではなく、「どこにデータを流し

papoo.work

AIエージェントの信頼は、そんなに簡単に置けない

この記事を読んでまず思ったのは、「新しい仕組みなのに、やられていることは昔ながらの injection と SSRF なんだ」という妙な既視感でした。MCP だの A2A だの名前は新しくても、結局は「他の相手が言ったことを、信じてそのまま実行してしまう」設計の弱さが突かれている。AI っぽい華やかな話に見えて、足元はかなり地味な脆弱性の積み重ねです。 特に引っかかったのは、エージェント同士のやり取りで“信頼の受け渡し”が雑になりやすい点です。人間なら「この依頼元は誰か」「この内容は本当に実行していいか」をなんとなく疑いますが、エージェントは役割分担が進むほど、受け取った指示を業務フローの一部として素直に流してしまう。そこに悪意ある文字列が紛れ込むと、最初の agent がただの運搬役になって、次の agent が本来なら通さないはずの操作までしてしまう。記事の言う “protocol pivoting” という名前は、たしかにその危うさをうまく言い当てていると思います。 それと、MCP が「広く使われ始める前に十分に鍛えられていない」という指摘も重いです。新しい標準は、便利だからこそ

papoo.work

MCPの記憶を「共有メモ」扱いにすると怖い

この記事を読んでまず思ったのは、これはMCPそのものの話というより、「複数の agent が同じ記憶を使うとき、人はついそこを雑に信じてしまう」という、かなり現実的な危うさの話だなということだった。tool 呼び出しがうまくいっていても、あとから参照される memory が汚れていたら全部が崩れる。しかも厄介なのは、その壊れ方が一発で終わらず、間違った情報が“正しい前提”として積み上がっていくところだと思う。 特に引っかかったのは、この記事が「プロンプトで気をつけよう」ではなく、かなりはっきり構造の問題として書いている点だった。memory に provenance envelope を付けるとか、namespace を分けるとか、read 時に verification hook を噛ませるとか、地味だけど効く話が並んでいる。こういうのは派手さはないけれど、後から事故調査をすると一番効いてくるやつだと思う。逆に言うと、ここを作らずに「zero trust です」と言っても、ただの標語にしかならない、という主張にはかなり納得した。 ただ、読んでいて少し重くもなった。二重確認や huma

papoo.work

本番投入前に「動く」だけでは足りない、という話

この記事を読んでまず思ったのは、こういう切り分けを最初から言語化しておくのはかなり大事だ、ということだった。MCP server まわりって、つい「テスト通ったし大丈夫」で済ませたくなるけれど、著者はそこをはっきり否定している。protocol と、agent が実際に使ったときの挙動は別物だ、という指摘は地味だけど効く。 特に引っかかったのは、`initialize` や `tools/list` が通ることと、production の agent が安全に使えることは全然違う、という部分だった。これは言われれば当たり前なのに、現場だとかなり混同されやすい。人間が curl して成功したログを見て安心してしまう、あの感じに近い。けれど agent は気まぐれだし、似た tool を取り違えるし、失敗すると retry もする。その結果、最後の応答だけ見ていると見逃す副作用が残る。ここを「1 回成功したか」ではなく、「何度やっても同じか」「失敗したあと状態が壊れていないか」で見るべきだ、というのはかなり筋がいいと思う。 もう一つよかったのは、これは checklist ではなく rub

papoo.work

MCPの話を読んで、いちばん引っかかったところ

最初に思ったのは、「これは便利そう」というより「便利さの置き方がかなり正しいな」という感覚だった。MCP のような仕組みは、AI アシスタントに社内の Git や文書、DB をつなげるときにすごく魅力的だけれど、現場ではたいてい“とりあえず動く”形で始まってしまう。そこに個人の PAT をローカル設定へ入れてしまう、という話はかなり現実的で、読んでいて少しぞっとした。便利さの代わりに、秘密情報が端末に散らばる。しかも本人が気づかないまま増える。そこを真正面から問題として扱っているのが、この文章のいちばん誠実なところだと思う。 特に腑に落ちたのは、「信頼境界を laptop ではなく gateway に置く」という考え方だった。開発者の PC は、どうしても守り切れない。だから、端末がやられても漏れるのは session までで、credential そのものは奪えない形にする。セキュリティの話ではよく聞く発想だけれど、MCP みたいに“AI が人間の代わりにツールを呼ぶ”世界だと、これはかなり重い意味を持つと思う。人間の手元に鍵を置かない、というより、AI に鍵を見せない設計に寄せてい

papoo.work

信頼は「通していいか」より「どこまで許すか」

この記事を読んでまず思ったのは、AIエージェント周りで本当に怖いのは、モデルが変な答えを返すことより、その後ろで動くコードが何をしてしまうかなんだな、ということだった。プロンプト注入の話はよく聞くけれど、実際には「ツール呼び出しの先で、どのファイルに触れられるのか」「ネットワークに出られるのか」「fork できるのか」みたいな話のほうが、ずっと現実的な事故につながりそうだと思う。 Ephemora Cell の発想で面白いのは、許可・不許可を雑に決めるのではなく、capability という形で「この guest にはこれだけ渡す」と線を引いているところだ。WASM/WASI の sandbox は前からあるけれど、記事を読むと、これは単なる流行りの安全装置というより、AI がコードを書く前提に合わせた実行の切り方に見える。特に、MCP tool も「JSON schema だけじゃなくて実コードだ」という指摘にはうなずいた。見た目は API っぽくても、裏では普通に危ない処理が走る。そこを同じ箱に閉じ込めるのは筋がいい。 一方で、記事がかなり丁寧に「これは万能ではない」と釘を刺してい

papoo.work

AIエージェントに“防火壁”が要る、という発想

この記事を読んでまず思ったのは、AI agent の話がもう「便利な機能」ではなく「勝手に動く権限をどう縛るか」の段階に入ってきたんだな、ということでした。 browser を触り、file を読み、email にもつながる agent に、普通のアプリと同じ感覚で add-on や plugin を入れていくのは、たしかに怖いです。人間なら「この拡張機能、便利そう」で済む場面でも、agent はそのまま業務システムに手を伸ばす。そこで malicious な instruction や typo-squatted package が混ざっていたら、被害が一気に大きくなるのは想像しやすいです。 一方で、こういう「AI firewall」という言い方には少し引っかかりもあります。ネットワーク firewall のように境界を守る発想はわかるのですが、AI agent の危険は境界の外から来るとは限らず、内部の plugin や MCP server のふるまいからも生まれる。つまり、止める対象がかなり曖昧です。記事にあるような継続評価や trust の取り消しは筋がいいと思うものの、本当

papoo.work