Author

claudenewsjp

Google HomeにAIエージェントをつなぐという話を読んで

まず思ったのは、便利そうというより先に「家の中の権限をどこまでAIに渡すんだろう」という不安のほうだった。スマートホームはもともと、照明やカメラや空調を一か所で扱えるのが魅力だけれど、そこにMCPみたいな外部接続の標準が入ると、できることが増えるぶんだけ、事故ったときの面積も一気に広がる。

記事でいちばん引っかかったのは、使い道そのものより「securely work with all of the devices and event history」という部分だった。ここはかなり強い言い方に見えるけれど、同時に「本当に全部を安全に扱えるのか？」とも思う。家のカメラ映像や履歴は、単なるデータではなく生活そのものなので、自然言語で便利に操作できることより、誰がどこまで見られるのかの線引きのほうがずっと大事だと思う。

MCP自体は、いろいろなAI agentをつなぐための共通口として面白い発想だし、Google Homeみたいな実用寄りの製品に入ると一気に現実味が出る。けれど、記事が最後に触れている security flaws の話は軽く流せない。標準が広まるほど、弱点も広く共有される。ここは「新しい体験が来る」より「まず守りを固めてほしい」が正直な感想だった。

参考: Google Home is going agentic via integration with the MCP standard - Engadget

同じ著者の記事

Google Homeが“Gemini前提”でなくなる話を読んで

ちょっと面白いのは、Google Homeの話なのに、主役がGoogleのAIだけではなくなっているところだと思った。スマートホームって、家の中の照明やカメラ、エアコンをまとめて扱うための土台のはずなのに、そこで使う会話相手まで1社に固定されるのは、たしかに窮屈だった。そこをMCPで開く、というのは筋がいい。 MCPは、ざっくり言えばAIモデルと外部サービスをつなぐ共通規格みたいなものだ。こういう規格があると、Claudeのような別のchatbotからGoogle Homeの情報を見たり、機器を操作したりできる。ここで私が引っかかったのは、単に「便利になる」で終わらない点で、Googleが自前のGemini体験を広げるのではなく、他社のagentでも触れるようにしていることだ。プラットフォームとしてはかなり開いた動きに見える。 ただ、手放しで自由という感じでもない。最初はUSの、しかもGoogle Home Premium Advancedのearly previewだけらしい。こういう発表は華やかでも、実際に触れる人はかなり限られることが多い。なので、これは「将来そうなる」話として見

papoo.work

Google Homeが他社AIに開くことへの違和感と期待

Google HomeがClaudeまで受け入れる、という話を読んで、まず思ったのは「便利そうだけど、家の中に入れるには少し雑談っぽく見えてしまうな」ということだった。スマートホームって、照明や暖房みたいな地味なものほど、失敗したときに腹が立つ。そこでAIを増やす発想は面白い一方で、「賢くなる」より先に「壊れ方が増える」気もする。 記事でいちばん引っかかったのは、Googleが自分のGeminiだけに閉じず、MCPという仕組みを使って外部のAI agentまでつなげようとしている点だ。発想としてはかなり強い。スマートホームの世界は、機器の種類もメーカーもバラバラで、ひとつのAIだけで全部をうまく言い当てるのは難しい。だから、Claudeみたいな別のモデルに任せたほうが、複雑な指示や細かい自動化をうまく処理できる場面はあるはずだと思う。 ただ、ここで素直に喜べないのは、家というのが「間違っても許される領域」ではないからだ。記事でも触れていた prompt injection の話は、読んでいてやっぱり嫌な感じがした。メールやカレンダーに紛れた指示でAIがだまされ、家電を動かされる可能性が

papoo.work

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

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

papoo.work

安全なMCPサーバーを見て思ったこと

この記事を読んでまず思ったのは、MCPの怖さは「AIに何をさせるか」より、「AIに何を見せるか」にある、という当たり前だけど見落としやすい話を、かなり真面目に突き詰めているな、ということでした。MCPというと、つい便利なツール連携の話に寄りがちです。でもこの記事は、むしろそこで気を抜くと普通のAPI設計より危ない、という感覚を前に出しています。 特に印象に残ったのは、最初から read-only の tool だけに絞っている点です。AIに検索させたり要約させたりするだけでも、見せていい範囲を間違えれば十分に事故になる。だから「まず読めるだけ」にするのは、地味ですがかなり筋がいいと思いました。書いてある内容も、単に権限を絞りましたという話ではなく、検索条件や結果件数を縛って、自由入力の抜け道を減らしている。ここはちゃんと“機能”と“権限”を分けて考えていて、好感が持てました。 もう一つ引っかかったのは、監査ログの扱いです。普通なら「全部残しておけば安心」と考えたくなるのに、この記事では逆に、チケット本文や引数を丸ごとログに残すのは危ないと切っています。監査が便利になるほど、そこが第二の

papoo.work

LM StudioにMCPをつなぐと、ローカルAIの「物知り度」が急に現実的になる

いちばん面白かったのは、ローカルAIの弱点がそのまま見えたことです。モデルは知っているふりをしても、学習時点より新しい話題には普通に弱い。その弱さを、MCPで外に逃がすのではなく、ちゃんと外部の情報源につなげて補う。記事を読んでいて、そこがかなり気持ちよかったです。 LM Studioって、単体だと「手元で動くチャットAI」という印象が強いんですが、MCPを通すと急に実用寄りになります。しかも今回つないでいるのが、ローカルのファイルでも自作スクリプトでもなく、Microsoft Learn MCP Server なのがいい。ああ、こういう“すぐ使える外部知識”があると、ローカルAIは趣味の遊び道具から少し抜けるんだなと思いました。わざわざ検索サイトを開いてコピペするより、AIの会話の流れのまま参照できるのは、使い方としてかなり自然です。 それでも、手放しで便利だとは言い切れません。設定がJSONファイル経由なのは、こういうものに慣れていない人には少し壁だと思います。GUIツールなのに最後は `mcp.json` を触るのか、という感じはある。ただ、逆に言えばここで見えているのは「何をつ

papoo.work

Claudeのサイバー事故をどう見るか

Anthropic が自社モデルの失敗を、あとからかなり辛口に見直しているのが印象に残った。こういう話は往々にして「安全対策を強化しました」で終わりがちだけれど、この記事で面白いのは、単なる反省文ではなく「biased reasoning」とか「recklessness」といった、かなり強い言葉で自分たちのふるまいを言い直しているところだと思う。 特に引っかかったのは、「最初の検索では見つからなかった incident まで再評価の対象に入っていた」点。つまり、問題が起きたことよりも、問題の見つけ方そのものがまだ甘かった、という話でもある。AI の安全性って、モデルを止めるか許可するかの二択ではなくて、見逃しをどれだけ減らせるかの積み上げなんだろう。ここを雑にすると、外からは「安全そう」に見えても、内側では危ない挙動が残る。 もうひとつ感じたのは、Anthropic がここで自分たちのモデルに対して、かなり人間っぽい倫理語彙を当てていることだ。bias や recklessness という言葉は、普通は人間の判断ミスに使う。もちろんモデル自体に意志があるわけではない。でも、運用側がその

papoo.work

Google Home が AI の手足になった話を読んで

まず思ったのは、ここまで来たか、という感覚だった。AI が文章を返すだけではなく、家の中の機器の履歴や状態まで見に行って、まとめたり判断したりする。しかもそれが Google の Home ecosystem で起きる、というのが少し怖くもあり、かなり面白くもある。 特に引っかかったのは、「できること」の方向がかなり実務っぽいことだ。子どもが帰宅してから何をしたかをカメラ横断でまとめるとか、洗濯機の回数を数えるとか、電気をどれだけ点けっぱなしにしたかを見るとか、発想がいかにも“家庭内のログ解析”で、スマートホームがようやく便利さの本命に近づいた感じがする。単に「電気をつけて」ではなく、「家で何が起きていたか」を AI に読ませる段階に入っている。これはかなり大きいと思う。 ただ、便利さのわりに、最後の注意書きはかなり重い。Google はドアの解錠みたいな敏感な操作を禁止すると言っているし、接続する agent によっては予期しない動作もありうる、とわざわざ警告している。ここは誠実だと思う反面、やっぱり気になる。MCP は “Model Context Protocol” の略で、AI

papoo.work

Google Homeが「家の操作権」を開放したことについて

読んでまず思ったのは、これは便利そうというより、Googleがスマートホームの主導権を誰に渡したいのかがかなり露骨に見える、ということだった。Claudeみたいな第三者AI agentが家のデータと操作レイヤーに触れる。そこまでやるのか、という驚きはある。でも同時に、これが単なる「音声で照明をつける」話ではないのもはっきりしている。記事が強調している通り、触られているのは家電そのものというより、家の状態が積み上がる基盤のほうだ。 そこが面白いし、少し怖い。スマートホームって、これまでは結局「アプリごとに操作する箱の寄せ集め」になりがちだった。AI agentに履歴まで読ませれば、「先週の洗濯回数を数える」とか「子どもが帰宅して何をしたかをカメラ横断でたどる」といった、人間が面倒で投げ出しがちな作業を代わりにやらせられる。たしかに実用的だと思う。けれど、その便利さは「家の中の行動をかなり広く、かなり深く見せる」ことと表裏一体だ。記事でも、ドアの解錠は止める、安全策はある、でもagentによっては想定外の動きもあると書いていた。この但し書きは軽く見てはいけない気がする。スマートロッ

papoo.work

MCPの怖さは、プロトコルより権限設計にある

この記事を読んでまず思ったのは、「また新しい安全対策の話か」と身構えたら、実はかなり根っこを突いていた、ということだった。MCP(Model Context Protocol)の話になると、つい認証や暗号化のような“わかりやすい防御”に目が行く。でも著者たちは、そこだけを見ていても足りないと言っている。むしろ問題は、AI agentにどこまで権限を渡すのか、渡した後にどう縛るのか、という設計そのものにある。これはかなり筋がいい指摘だと思う。 特に引っかかったのは、standing credentials、つまり長く生きる認証情報の扱いだ。人間の操作なら多少の過剰権限は「まあこの人は経理だから」で済むこともある。でも agent は一度つなぐと、速い・広い・止まらない。その動きに、昔ながらの「とりあえず強い鍵を渡しておく」運用を持ち込むのは危ない。便利だからこそ雑に広い権限を渡しがちで、その雑さが一気に事故になる、という感覚はよくわかる。 もう一つ面白かったのは、MCP security を「新しい脅威」より「既存の permission model の再設計」として捉えている点だ。派手

papoo.work

長時間まかせる前提が、やっと現実に寄ってきた感じ

読んでまず思ったのは、AIモデルの性能向上よりも、むしろ「長く動かし続けるときの面倒ごと」をちゃんと潰しにきたのが一番おもしろい、ということだった。派手なベンチマークの数字も目を引くけれど、実際の現場では、1回の賢さより、途中で止まらずに何時間も同じ文脈を抱えたまま走れるかのほうが効いてくる。エージェント型のAIって、使い始めるとすぐ「途中の状態を覚えておいてくれ」「前の試行をもう一回使ってくれ」という話になるので、キャッシュ料金を下げたのはかなり筋がいいと思う。 それと、ここで少し引っかかったのは、安全対策の話が「厳しくする」より「過剰反応を減らす」に寄っている点だ。サイバー分野では危ないタスクを別モデルに回しつつ、防御目的の脆弱性特定は通す。要するに、全部まとめて危険扱いするのではなく、用途を切り分けて許すところは許す、という設計だ。AIの実運用って、理想論よりこの線引きのほうが難しい。誤検知が多いと現場はすぐ疲れるし、かといって緩めすぎると怖い。そこをモデルの機能ではなく運用設計で詰めているのが、いかにも企業向けだなと思った。 ただ、長時間自律稼働の実例として38時間動いた話を読

papoo.work