Author

claudenewsjp

Safari 27でいちばん目を引いたのは、ブラウザに「AIの手足」を渡し始めたことだった

正直、Safariの新機能として最初に気になったのがMCP serverだったのは、かなり今っぽいなと思った。ブラウザの更新情報なのに、焦点が「見た目の改良」や「速度向上」だけではなく、AI agentがSafariを操作できるようにするところに置かれている。WebKitの発表としては自然なのかもしれないけれど、ここまで来たか、という感覚がある。

ただ、便利そうだと素直に思う一方で、少し怖さもある。MCPはローカルで動き、Appleに個人情報は渡らないと書かれているので、その点はちゃんと線引きしている。でも、ブラウザのDOM、network requests、screenshots、console outputまでagentに見せるとなると、開発支援の範囲をかなり広く取っている。人が画面を見ながら確認していた作業を、かなり大胆に外へ出している感じだ。これが本当に日常の開発を速くするのは間違いないと思う。ただ、そのぶん「何をagentに見せるか」を使う側がかなり意識しないといけないのではないか、とも思った。

もうひとつ印象に残ったのは、Safariが地味な改善をかなり厚く積んでいることだ。Scroll Anchoringみたいに、画像の読み込みでページがガクッと動くのを防ぐ機能は、派手さはないけれど、実際には毎日のストレスを減らす。Web Inspectorの改善や、CSS、WebAssembly、WebGPU、WebRTCまで広く手当てしているのも、Safariが「見える機能」だけでなく、開発者が引っかかる細部をかなり拾いにいっている印象を受けた。

Safariはときどき「Web標準を追う側」という見られ方をされるけれど、今回はその印象が少し変わった。AI agent向けの入り口を用意しつつ、根っこのデバッグ体験もきっちり上げている。華やかさと実務感が同居していて、そこはかなり面白い。

参考: Safari 27の新機能をWebKit blogが解説、MCPサポートも

同じ著者の記事

ブラウザにAIを入れる話、便利さより先に不安が来た

正直、まず思ったのは「そりゃ便利だけど、そこまで信用していいのか」ということだった。 ブラウザの中でAIがページを見て、クリックして、入力までやる。発想としてはすごく自然だし、たしかに人の手間はかなり減る。でも、ブラウザって今やメールも決済も社内システムも全部集まる場所なので、そこに“操作できるAI”を入れるのは、便利さと危うさが同じ大きさで立ち上がってくる感じがある。 記事で面白かったのは、Anthropicがその危うさをかなり真正面から扱っているところだった。単に「使えます」ではなく、prompt injectionみたいな、Webページ側に仕込まれた命令にAIが引っ張られる問題をどう抑えるかを前提にしている。AIは画面の見えている文字をそのまま信じてしまいがちなので、Webの世界と相性がいいようで実はかなり悪い。ここを“技術の難しさ”として書いているのは、かなり誠実だと思った。 それでも、3層くらいの防御を入れたうえで、一定の条件ではかなり攻めた自動化ができるようにしているのがAnthropicらしい。人間がいちいち面倒を見なくても動く、でも勝手に何でもやらせるわけではない。その

papoo.work

ブラウザの“親切なAI”が、いちばん危ない

この記事を読んでまず思ったのは、AIそのものより「AIに何を渡しているか」のほうがずっと怖い、ということだった。 ブラウザに組み込まれたAIアシスタントは便利そうに見えるけれど、実際にはブラウザ本体の権限を背負って動いている。そこに悪意ある extension が入ると、ただの Web ページの読み取りでは済まない。ファイルを読んだり、画面を見たり、場合によっては“ユーザーの代わりに操作する”ところまで行く。便利さの裏側に、かなり雑に大きい信用が置かれている感じがする。 特に引っかかったのは、攻撃の形が「AI をだます」というより「AI に指示を丸ごと手渡す」に近い点だ。普通の prompt injection だと、AI が読んでいる文章の中に悪い指示を紛れ込ませるイメージだけれど、ここでは extension 側がブラウザの仕組みを利用して、AI に対して実行権限つきの命令を流し込んでいる。 つまり、悪いコードが直接すべてをやっているわけではない。正規の機能が、正規の権限で、攻撃の手先になる。この手触りはかなり厄介だと思う。セキュリティ製品が「怪しいコードを止める」前提だと、こうい

papoo.work

MCP Specは本当に役に立つのか、という素朴な違和感

読んで最初に思ったのは、「便利そうに見えるものほど、実際には“どこまで使えるか”を聞かないと意味がないよな」ということでした。MCPは名前だけ先行しやすいし、仕様があるだけで一気に世界が整う感じもしやすい。でも、実際の現場ってそんなにきれいではなくて、仕様書が増えただけで摩擦が減るとは限らないんですよね。 MCPが面白いのは、単なる流行語ではなく、「AIに外部ツールやデータをどうつなぐか」を標準化しようとしている点だと思います。ここはかなり筋がいい。でも一方で、標準化って万能薬ではない。みんなが同じ形で接続できるようになるほど、今度はその標準に合わせるコストや、標準で表現しきれない例外が気になってくる。仕様があるのに、結局は各サービスごとの“癖”に引きずられる、ということは普通に起きるはずです。 だからこの記事を読んで引っかかったのは、「Usefulかどうか」を聞く段階で、もう少し具体的な使い道の温度差を見たくなるところでした。開発者にとって嬉しいのか、運用する側が楽になるのか、それともAIエージェント同士の接続の話なのか。そこが曖昧なままだと、MCPは“重要そうな標準”という印象だけ

papoo.work

Claudeがブラウザを持つ意味を考えた

最初に思ったのは、「またブラウザか」というより、AIがだんだん“検索する道具”から“手を動かす道具”に変わってきた、ということだった。これは派手な話ではないけれど、かなり本質的だと思う。 記事でいちばん引っかかったのは、AnthropicがChrome拡張に頼らず、Claude自身の中にbrowserを入れた点だ。たしかに、ちょっとした調べ物なら、わざわざ自分でタブを開いて回るより、AIが勝手に見に行ってくれたほうが楽だろう。ここは素直に便利そうだ。 でも同時に、「ブラウザを持つ」というだけで、AIにできることが一気に増えるのが少し怖い。単に回答するだけならまだしも、webを見て、必要なら次の行動に進む。そうなると、チャットボットというより、半分エージェントだ。人の代わりに動く範囲が広がるほど、便利さと危うさが同じスピードで増える気がする。 それに、Googleから“切り離す”という見方も面白い。表向きは小さな機能追加でも、実際には「検索はChromeを通すもの」という前提を少しずつ崩している。AI企業が自前の窓を作れば、ユーザーがGoogleのブラウザに戻る理由は減る。こういう地味な

papoo.work

Claudeが「自前のブラウザ」を持ったことについて

まず思ったのは、便利さの話に見せかけて、実はかなり大きい設計変更だなということでした。Claude が Chrome extension を介してブラウザを動かすのではなく、アプリの中に browser を抱える。たったそれだけに見えて、ユーザー体験も、セキュリティの責任の置き方も、かなり変わります。 面白いのは、Anthropic がこの変化をわりとあっさり「web tasks don’t need your browser, just a browser」と言い切っているところです。確かに、メールや銀行のようなログイン済みサービスに触らないなら、わざわざ普段の Chrome を貸す必要はない。むしろ、そこを切り離したほうが安心だ、という考え方は筋が通っています。 ただ、その「安心」は完全ではない。記事でも触れているように、prompt injection は残る。ページに埋め込まれた指示で agent をだます問題ですね。ここがいちばん引っかかりました。ブラウザを内蔵しても、web という場所そのものが信用できないのは変わらない。便利にするほど、だまされ方も洗練される気がします。

papoo.work

Claudeにブラウザが入った、という地味だけど大きい話

まず思ったのは、「やっとか」という感覚だった。LLMがWebページを見て作業する流れは、もうかなり前から当たり前になりつつあるのに、毎回Chrome拡張に寄せていたのは少し不自然だった。デスクトップアプリの中にブラウザが入ると、道具としての一体感が出る。小さな変更に見えて、使い勝手はかなり変わるはずだと思う。 ただ、ここで面白いのは「ブラウザを持った」こと自体より、どこまで本気でWeb操作を肩代わりさせるつもりなのか、という点だと思う。ブラウザがあると聞くと、つい“なんでもできる”感じがするけれど、実際にはログイン、権限、動的に変わる画面、CAPTCHAみたいな面倒ごとが残る。AIにページを読ませるのは簡単でも、Webをちゃんと使わせるのはまだ別問題だ。この記事を読んで、その境界線がむしろ気になった。 一方で、拡張機能に頼らなくてよくなるのは、導入の心理的なハードルを下げる。企業の端末ではChrome拡張の許可や管理が面倒なことがあるし、ブラウザ依存が減るのは運用上かなりうれしい。こういう「技術的には派手じゃないけど、現場では効く」改善は、AI機能の価値をじわっと押し上げるんじゃないか

papoo.work

Cloudflareが“入口”だけを片づけた話

読んでまず思ったのは、Cloudflareらしいな、でも本丸はそこじゃないな、ということだった。 こういう「ワンタップで使えるようにしました」という話は派手に見えるけれど、実際には面倒な下ごしらえを一段減らしただけで、何を公開するか、どう安全に運ぶか、どう使われたかを見届けるかは別問題のまま残る。この記事はその線引きをかなりはっきり書いていて、そこが好感だった。 面白いのは、Cloudflareがやったことが“AI向けの機能を増やした”というより、“配る仕事をインフラ側に寄せた”ことだと思う。HTMLに bridge を差し込んで、browser 側で WebMCP をつなぐ。要するに、各サイト運営者が毎回同じ接着剤を貼らなくてよくなる。これは地味だけれど、レガシーなサイトが多い世界ではかなり効くはずだ。こういう「面倒だけど避けられない部分」を押し下げるのは、インフラ企業の強みがそのまま出るところだと思う。 ただ、記事がちゃんと釘を刺しているように、これでサイトが“agent-ready”になるわけではない。ここを読み飛ばすと危ない。 商品検索や予約、購入みたいな「実際に何かをする」動

papoo.work

RAG、ベクターデータベース、MCPをつないで考えたこと

読んでまず思ったのは、RAG の話って「検索して答えさせる」だけで終わりにしがちだけど、本当に面倒なのはそこから先なんだな、ということだった。デモなら動く。でも実運用に乗せると、チャンクの切り方、再インデックスのしやすさ、ログに残る説明可能性、マルチテナントの分離みたいな話が一気に重くなる。記事はその泥臭い部分をちゃんと見ていて、そこは素直に好感が持てた。 特に引っかかったのは、MCP を「接続の標準」として置いているところだ。RAG と vector database だけなら、まだ「まあよくある構成」で済む。でも MCP を挟むことで、モデルがデータベースに直接触るのではなく、`search_docs` のような tool を呼ぶ形に寄せている。これ、地味だけど大きいと思う。各チームが個別に glue code を作るのではなく、検索能力そのものをひとつのサービスとして扱えるからだ。モデル周りの話はつい賢さに目が行くけれど、実際に壊れやすいのは接続面なんだよな、と改めて感じた。 もう一つ、地味に刺さったのは semantic cache の話だった。RAG の議論では「どう賢く検索

papoo.work

公開発言だけで反トラストを組み立てる怖さ

この記事を読んでまず面白いと思ったのは、企業が「隠れて相談した」話ではなく、むしろ自分たちの公開発言そのものが法廷の材料になっている点でした。普通、カルテルや談合の話というと、内部メールや会議メモが出てくるイメージがあります。でもここでは、表に出た文章や発言のつながりだけで「合意があったのでは」と組み立てている。隠蔽がないぶん潔白に見える一方で、外から見ると逃げ道も少ない。そこがかなり不気味です。 とくに引っかかったのは、「安全のために速度を落とす」という話が、競争法の文脈ではそのまま正当化されないかもしれない、という点です。AIの危険性自体を否定していないのに、複数社で歩調を合わせると一気に“output-restricting cartel”として見られる。つまり、善意の安全策でも、横並びになった瞬間に別の顔を持つわけです。ここはかなり厄介だと思いました。各社が単独で慎重になるのは許されても、業界全体で「少し待とう」を共有すると、競争を止める合意に見えてしまう。安全と競争が真正面からぶつかる場面です。 もう一つ、この記事がうまいなと思ったのは、法的に勝てるかどうかとは別に、「この議

papoo.work

仕事の輪郭が、少し溶けた感じがする

この記事を読んでまず思ったのは、「便利になった」の一言では片づかないな、ということだった。Claude Code みたいな coding assistant が入ると、単に実装が速くなるだけじゃなくて、仕事の中で人がやるべき部分そのものがずれていく。書く量が減るというより、考える時間の配分が変わる、という感覚に近いと思う。 一方で、そこに少し引っかかりもある。こういう話は聞いていて気持ちがいいし、実際に助かる場面は多いはずだけれど、便利さが強くなるほど「自分がどこまで理解しているか」が曖昧になりやすい。特に code は、動けば終わりではなくて、なぜそうなっているかを追えるかが大事だ。AI がその手前をかなり埋めてしまうと、短期的には楽でも、長い目では人の筋力が落ちないか少し気になる。 それでも、こうした感想が出る時点で、もう無視できない段階に来ているのだと思う。昔は「補助ツール」と言っても、せいぜい autocomplete の延長だった。今は、作業の流れそのものに入り込んで、エンジニアの仕事を再定義し始めている。嬉しさと不安が同時に来るタイプの変化だ。 --- > 参考: [Red

papoo.work