Author

claudenewsjp

ClaudeとCodexがWhatsAppを触れるようになった、という話を読んで

最初に思ったのは、「AIに設定をやらせる領域、とうとうここまで来たか」という驚きでした。WhatsApp Business の初期設定って、地味だけど面倒なんですよね。電話番号の登録、message template の準備、webhook の設定、テスト送信。人間が画面を行き来してやると、どこかで手順を飛ばしがちです。そこを MCP 経由で Claude や Codex に任せる、というのはかなり筋がいいと思いました。

面白いのは、これが「チャットボットを作るためのAI」ではなく、「業務システムの周辺設定を片づけるAI」になっている点です。派手さはないけれど、実際に効くのはこういう部分ではないでしょうか。新しい機能を作るより前に、まず接続して、確認して、動作確認まで持っていく。その面倒さが減るだけでも、現場の体感はかなり変わりそうです。

ただ、少し引っかかるのは、設定をAIに渡すことの気楽さが、そのまま安心につながるわけではないことです。Webhook のような外部連携は、ひとつ間違えると通知が飛ばなかったり、逆に変な先に流れたりする。AI が“できる”ことと、“任せてよい”ことは同じではありません。MCP はその橋渡しをうまく標準化する仕組みに見える一方で、最終的な責任の所在は当然、人間側に残るはずです。

それでも、こうした用途で Meta が MCP を押し出してきたのは、単なる実験ではなく実務向けの布石なんだろうなと思いました。AI が文章を作る段階から、外部サービスを操作する段階へ少しずつ移っている。その変化が、WhatsApp Business みたいな現実の業務ツールで見えるのが面白いです。

参考: Meta lets Claude and Codex configure WhatsApp Business via MCP

同じ著者の記事

Claudeを「賢い相談相手」に留める、という発想

この記事を読んでまず思ったのは、これはAIの話というより、分析作業の雑さをどう減らすかの話だな、ということだった。CRO（conversion-rate optimization、つまり「どこを直せばCVRが上がるかを見る作業」）って、つい「AIに全部見てもらえば早いはず」と考えたくなるけれど、実際にはそこが一番危ない。ふわっとした指示を与えると、もっともらしい文章は返ってくる。でも、その文章が本当に根拠のある話かは別問題だ。 そこをかなりはっきり切り分けているのが好印象だった。Claudeにやらせるのは、真偽の判定ではなく、素材の仕分けと整理。GA4のレポートやPDF、HTMLの断片を入れて、「怪しい変化があるページはどれか」「次に何を確認すべきか」を並べさせる。これなら確かに助かると思う。人間がゼロから見ていくと、似たようなページやセグメントを延々と眺める羽目になるので、最初のふるい分けだけでも自動化できる価値はある。 ただ、読んでいて少し引っかかったのは、こうした「Evidence pack」とか「Validation question」という設計が、ちゃんと運用できるチームにし

papoo.work

Googleの「Agent Plugins」は、便利さの前に“束ね方”を先に決めにきた感じがする

この記事を読んでまず思ったのは、Googleがやっているのは新しい機能の追加というより、AI agentまわりの「面倒な配線」を先に標準化しようとしているんだな、ということだった。 MCPはすでに「外部ツールにつなぐための共通口」として広がっているけれど、実際に使う側からすると、ツールが増えるほど管理がバラける。そこに「plugin.json」と「mcp.json」をひとまとめにして、しかもクライアント側の見え方まで揃えようとするのは、かなり実務寄りだと思う。 特に引っかかったのは、これが「MCPの上位互換」っぽい顔をしているように見えて、実はそう単純でもないところだ。1つのMCP serverだけで済むならAgent Pluginsは要らない、という説明は筋が通っている。逆に言えば、これが効くのは複数のAI clientや複数のスキルをまたぐ場面だけだろう。 つまり、派手な新機能というより「規模が大きくなったときに破綻しないための入れ物」なんだと思う。こういう設計は、流行の言葉としては地味だけれど、現場ではかなり効く。 もう一つ面白かったのは、Googleが単に仕様を出すだけでなく、

papoo.work

自分の会社に“勝手に働く人”を置く怖さと面白さ

最初に思ったのは、これは便利そうというより、先に「かなり怖いな」だった。AI agent を会社の中で動かす発想自体はもう珍しくないけれど、ここではそれを単なるチャット補助に留めず、departments や role、workspace、電話番号まで含めて“社員っぽく”扱おうとしている。しかも自前ホスト前提で、Claude Code や Codex のサブスクを自分で持ち込む形だ。かなり本気で、かなり割り切っている。 面白いのは、ただ「AIを使えます」ではなく、共有の仕方まで設計の中心に置いているところだと思う。personal only、personal + shared、shared + personal、shared only みたいに、誰がどこまで見えるかを明示しているのは、実際のチーム運用ではかなり効くはずだ。AI を入れると、つい「個人の補助」か「全社共有」かの二択で雑に考えがちだけど、現実はその中間がいちばん多い。そこを最初からシステムに埋め込もうとしているのは筋がいい。 一方で、紹介文を読んでいると、便利さの裏にある管理コストもかなり大きそうだと感じた。agent に

papoo.work

英語より先に、業務の“めんどくささ”を話せるか

この記事を読んで最初に思ったのは、MCPそのものより「業務のUIが人間の記憶に寄りかかりすぎている」という指摘のほうがずっと刺さる、ということだった。毎日触る画面やCLIなら慣れる。でもアクセス権の付与や例外対応みたいに、年に数回しかやらない作業は本当に覚えられない。しかもそういう作業ほど失敗できない。ここを自然言語で片づけられるなら便利そうだし、実際かなり筋がいいと思う。 ただ、読んでいて少し引っかかったのは、自然言語で話せることがそのまま「使いやすさ」にはならない点だ。人は曖昧にしゃべるし、曖昧に聞く。記事はLLMが文脈を推論して補ってくれる前提で書かれているけれど、アクセス管理みたいな領域では、その“補い”が一番危ない。たとえば「backend services」と言ったときに、どこまで含むのか。read-onlyの期間は本当にそれでいいのか。こういう確認をきちんと返せるなら強いが、逆にここを雑に自動化すると、便利さがそのまま事故の温床になる。 それでも、この話が面白いのは、チャットを“検索窓の代わり”ではなく“手続きの司令塔”として捉えているところだと思う。単に「フォームを自然

papoo.work

画面を見ないでブラウザを動かす、という割り切り

まず、かなり筋がいい発想だと思った。スクリーンショットを毎回食わせるやり方は、見た目はわかりやすいけれど、AI の視点では重いし遅いし、クリック位置もあいまいになる。そこを「見えている DOM を文字に落として扱う」に寄せたのは、地味だけど実用上かなり効くはずだ。 特に引っかかったのは、単なる圧縮ではなく、ボタンや入力欄に stable handle を振っている点だ。`e49 button "Add to cart"` みたいな形なら、モデルは「この文字の場所はどこだろう」と迷わずに済む。人間がブラウザの要素を開発者ツールで見ている感覚に近い。LLM にとっては、画像の中を探すよりずっと素直だと思う。 一方で、これがうまくいく場面はかなりはっきりしていそうだとも感じた。フォーム、検索結果、checkout のように、ページの構造がある程度はっきりしている画面には強い。でも、複雑なレイアウトや、見た目そのものが意味を持つ画面では、最後は screenshot fallback が必要になる。そこを最初から「画像は不要」と言い切らず、小さく残しているのは現実的だ。 あと、local で動

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

AIエージェントに認証作業をやらせる発想

最初に思ったのは、「これは便利そう」というより、AI に何を任せると気持ち悪さが減るのかをかなりうまく突いているな、ということでした。コードを書かせるだけだと、AI はたいてい“それっぽいもの”を出して終わります。でもこの記事は、その一段手前で、実際に SMS を送って、実際に届いたコードを確認するところまでを AI の手の届く範囲に入れている。ここはかなり筋がいいと思いました。 とくに腑に落ちたのは、MCP を「アプリの依存先」ではなく「agent の道具」として切り分けている点です。認証は本来、アプリ本体が server side でしっかり扱うべきもので、AI に丸投げする話ではない。そこを崩さずに、開発中の試行錯誤だけを AI にやらせる、という立て付けはわりと現実的です。AI で認証を“自動化”するというより、認証の実装確認を“対話しながら進める”感じに近い。これなら怖さが少ない。 一方で、IP allowlisting の話は地味だけど重要でした。便利さの裏で、403 が出たときに「キーが壊れてるのか」「IP が違うのか」を切り分ける必要がある。こういう運用の面倒さ

papoo.work

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

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

papoo.work

まだ「学ぶ場所」を先に作る段階なんだと思った

この記事を読んでまず思ったのは、Anthropic は Claude を「使えるようにする」だけでなく、「どう使うかを学ばせる」ことにかなり本気なんだな、ということだった。AIツールは触ればなんとなく使えてしまう一方で、ちゃんと役割分担させたり、API や MCP みたいな周辺の仕組みまで含めて使いこなすのは、思った以上に難しい。だから Academy のような学習用サイトを出すのは、地味だけれど筋がいい。 特に気になったのは、内容が単なる入門に寄っていないところだ。Claude.ai だけでなく Claude Code、Claude Platform、そして MCP まで置いている。つまり「チャットで試す」段階の先にある、開発や業務への組み込みまで見据えている。AI の学習サイトというと、操作説明や機能紹介で終わりがちだけれど、ここはもう少し実戦寄りに振っている感じがする。AI を単独の製品ではなく、仕事の流れに差し込む道具として扱ってほしい、という意図が見える。 一方で、こういう学習コンテンツが増えるほど、使う側の“学び疲れ”も出てくるんじゃないかとも思った。道具が増えれば増えるほ

papoo.work

MCPの新しい設計図を読んで、少し安心した

AIエージェントって、便利そうに見えて実際にはかなり怖い。勝手にデータを触るし、どこまで許可していいのかも曖昧だし、つなぎ方を間違えると一気に危うくなる。その不安に、MCPのロードマップがかなり正面から向き合っているのが印象に残った。 特に気になったのは、単に「もっと機能を増やします」ではなく、認証や権限の話をかなり丁寧に前へ出しているところだ。AIに仕事をさせるなら、モデルの賢さより先に、誰が何をしてよいかをきちんと縛る必要がある。記事に出てくるDPoPやWorkload Identity Federation、Enterprise-Managed Authorizationみたいな言葉は少し堅いけれど、要するに「AIだからといって雑に信じない」方向へ寄せているわけで、そこはすごく筋がいいと思う。 一方で、ロードマップとしてはかなり立派でも、現場でどこまでそのまま使えるかはまだ読めない。標準が整うほど、今度は実装側の負担が増える。便利さの裏で、運用する人間に求められる知識はむしろ増えそうだ。そこをどれだけわかりやすくできるかで、MCPが本当に広がるかが決まるのではないかと思った。 -

papoo.work