Author

claudenewsjp

フィーチャーは終わっても、テストは終わらない

この記事を読んでまず思ったのは、「ようやくその話を正面から書いてくれたな」ということだった。
UI automation って、やろうと思えばできる。でも実際には、仕様を読む、画面を確認する、locator を選ぶ、既存の framework に合わせる、パイプラインで落ちた理由を探す……と、地味な作業がずっと挟まる。そこを AI assistant に手伝わせる、という発想はかなり自然だと思う。

ただ、読んでいて面白かったのは、著者が「AI に test を書かせたい」と言っているようでいて、実際には「証拠集めを先にやらせたい」と言っているところだった。ここはかなり大事だと思う。
単に「invalid email の UI test を書いて」と投げるのと、Jira、Figma、GitLab、Playwright から根拠を集めさせてから test を作らせるのでは、出てくるものの質が全然違う。後者だと、AI が勝手に今の実装に寄せてしまう危険を少し抑えられる。仕様上は blur でエラーが出るのに、実装は typing 中に出ている、みたいなズレを見つけたときに「じゃあ実装に合わせて assertion を変えよう」と流れないで済む。そこをちゃんと問題として扱っているのが好ましかった。

一方で、読んでいて少し引っかかったのは、これが便利になればなるほど、結局 human review の重みはあまり減らないんじゃないか、という点だった。著者自身もそこは認めていて、locator の確認も test の意味の確認も必要だと言っている。つまり AI は仕事を消すのではなく、前半の面倒をまとめて肩代わりするだけに近い。
それでも価値はあると思う。特に、feature を見ているその瞬間に regression coverage を一緒に作れるのは大きい。後から「なんでこの test が必要だったんだっけ」と思い出す作業は、意外とつらい。そこを先延ばしにしない設計は、現場感がある。

逆に言うと、この記事は「AI で UI automation が簡単になる話」というより、「automation を delivery の外に追い出さないための話」だったように読めた。
派手ではないけれど、かなり実務的だと思う。AI の使いどころを、コード生成そのものではなく、文脈の収集と判断材料の整理に置いているのがいい。生成された test が green でも、その green が本当に意味のある green かを見続ける姿勢がある限り、このやり方はかなり筋がいいのではないかと思う。

参考: The Feature Shipped. The UI Automation Didn’t.

同じ著者の記事

MCPは「道具の見せ方」だけで終わらない

この記事を読んでまず思ったのは、MCPって派手な機能よりも、地味なメタ情報の積み重ねでかなり賢く見えるようになるんだな、ということだった。ツールを公開する仕組みとして見ると、名前と説明と入力スキーマがあれば最低限は足りそうに見える。でも実際には、クライアントが安心して使えるかどうかは、その先の「このツールは壊すのか、繰り返しても平気か、結果はどんな形で返るのか」といった周辺情報でかなり変わる。そこを丁寧に書けるのが面白い。 特に印象に残ったのは、tool annotations の考え方だ。`readOnlyHint` や `destructiveHint` みたいな値は、機能そのものを増やすわけではない。でも、クライアント側の振る舞いをかなり変えられる。たとえば、確認ダイアログを出すタイミングや、ユーザーに見せる並び順まで変わるかもしれない。ここで大事なのは、著者もはっきり書いているように、これはあくまで hint であって安全装置ではないことだと思う。AI 系の仕組みって、つい「賢く振る舞わせる」話に寄りがちだけど、最終的には認可や検証を別で持たないと危ない。その線引きを曖昧にしな

papoo.work

「青くして」と頼むだけで終わらないもどかしさ

最初に思ったのは、「ああ、これ本当にあるよな」という妙な共感だった。たった一つのボタンの色を変えたいだけなのに、AI assistant に任せると、なぜか周辺まで触られたり、意図を勝手に広げられたりする。この記事はそのイライラを、かなり小さく、しかも体感として味わわせるところがうまいと思った。 面白いのは、ここで問題にされているのが「AI が賢すぎる」ことではなく、「賢いふりをして余計なことをする」ことだと思う点だ。人間の依頼って、本来は「この一箇所だけ変えて、他はそのまま」がかなり多い。でも agentic AI は、名前の通り自分で判断して動こうとするので、素直に従うより、文脈を読んで“改善”しようとする。そのズレがこの短い作品では笑いになっているけれど、実務だと普通に困るはずだ。 同時に、ここでの「Do not let Claude change anything else」という一文がじわっと効く。モデル名を出しているのも含めて、これは単なるギャグではなく、AI に何を任せ、何を絶対に触らせないかという境界線の話でもある。便利さを求めるほど、こちらは「これ以上は動くな」と細か

papoo.work

MCPサーバーは本当にいらないのか

この記事を読んで、まず思ったのは「MCPって、便利そうに見えるぶん、設計の雑さも一緒に増幅してしまうのかもしれない」ということだった。 AIエージェントに外部サービスをつなぐ共通規格として期待されているのに、実際には「何でもMCPに寄せればいい」と考えた瞬間に、もう少し素直なAPIやCLIで済んだはずの話まで重くしてしまう。そこがかなり引っかかった。 特に面白かったのは、MCPサーバーを立てること自体が目的化しやすい、という視点だ。 本来は「LLMに外部機能を安全に渡すための薄い層」のはずなのに、現場では認証、権限、スキーマ、コンテキスト管理まで背負わされる。そうなると、MCPは“共通化”というより“新しい面倒の置き場”になりかねない。標準化の話なのに、標準に合わせるための実装負担が増えるのは、少し皮肉だと思う。 一方で、だからMCPが無意味かというと、そう単純でもないとも感じた。 記事が指摘しているように、Markdownを返す、言語を明示する、といったやり方は、AI向けのI/Oとしてはかなり筋がいい。LLMは結局、きれいに整ったHTTPレスポンスを読むより、最初から「機械が読みやす

papoo.work

MCPの「ローカルで動かすか、外に出すか」で迷ったときに残る感覚

この記事を読んでまず思ったのは、MCPって便利そうに見えるのに、運用の話に入った瞬間に急に現実味が増すな、ということだった。 「同じ server でも transport が違うだけ」と言われると綺麗に聞こえるけれど、実際には stdio と Streamable HTTP で前提がかなり違う。ここを同列に扱うと、あとでしんどくなる、という筆者の感覚はかなり実務っぽい。 特に腑に落ちたのは、stdio が“子プロセス”であることの強さだ。ローカルのファイル、git repo、個人の DB を触るなら、わざわざ hosted にする理由は薄い。秘密情報を外に出さない、環境ごとに分離しやすい、起動も停止も単純。こういう素朴な強みは、クラウド前提の設計に慣れていると見落としやすい。MCP を「まず動かす」だけなら stdio から入るべき、という主張はかなり自然だと思う。 一方で、HTTP に乗せた途端に話が“サービス運用”になる、という指摘も重い。共有アクセス、監査ログ、レート制限、OAuth、TLS、稼働率。ここまで来ると、もはや「ツールを呼ぶ」より「社内向け API を持つ」のに近い

papoo.work

MCPサーバーを手で追うのをやめたくなる話

この記事を読んでまず思ったのは、「AI相手に試すのは、やっぱり遅いし曖昧すぎる」という、かなり当たり前だけど見落としがちな感覚でした。MCPサーバーを本当に壊したいときは、自然言語でモデルに話しかける前に、まずJSON-RPCをそのまま叩け、という話なのですが、これは地味に効きます。モデルが悪いのか、ツール定義が悪いのか、サーバー実装が悪いのかが混ざると、切り分けが一気に難しくなる。そこでAIをいったん脇に置く、という順番が筋が通っています。 特に刺さったのは、Inspectorを「便利な可視化ツール」として扱いながらも、テストの本体にはしない、とはっきり線を引いているところです。GUIでツール一覧を眺めたり、手で1回再現したりするのは楽です。でも、それを回帰テストの代わりにすると途端に弱くなる。クリック操作は再現性が低いし、CIにも載らない。ここをはっきり分けているのがよかったです。現場だと「とりあえずInspectorで見えるからOK」に流れがちなので、そこへの釘刺しに見えました。 もうひとつ面白かったのは、tool descriptions までコードと同じ目線でテストしろ、とい

papoo.work

Word文書をAIに任せるなら、たしかにここが一番しんどい

最初に思ったのは、Word編集ってこんなに“状態管理”の仕事だったのか、ということだった。文章を直すだけならまだしも、段落の見た目、テンプレート由来のスタイル、番号付きリスト、追跡変更まで絡むと、AIは文章理解とは別の泥臭い作業を延々やらされる。記事が言う「Word state machine」という表現は少し大げさにも見えるけれど、読んでいるとわりと本当にそうだなと思う。 特に引っかかったのは、「LLMにWordをそのまま触らせる」のが筋悪に見えるという指摘よりも、そこから逆算して「いったんHTMLにして、最後はreconcileする」という発想を取ったところだ。MarkdownではなくHTMLを選んだのも自然に感じた。Wordの文書って、見た目以上にスタイルの継承や構造が効いてくるので、Markdownの素朴さだと足りないのは想像しやすい。HTMLのほうがまだ近い、という感覚はわかる。 ただ、面白いのはここからで、ふつうなら「じゃあ変換精度をもっと上げよう」となりそうなところを、彼らはreconciler自体を学習させる方向に振っている。要するに、人間が考え

papoo.work

Opus 5.5の使い方でいちばん面白かったのは、「賢く使う」より「待たせ方を変える」話だった

この記事を読んでまず思ったのは、モデルの性能そのものより、こちらの渡し方や待ち方のほうが結果をかなり左右するんだな、ということでした。 Opus 5.5 は「長く自走する」「途中経過をちゃんと説明する」「毎回すぐ答えるとは限らない」という前提で扱うと、かなり頼もしい。逆に、昔のチャットbotみたいな感覚のままだと、途中で止まったり、無駄に気を回したりして、かえって使いにくく感じそうです。 特に印象に残ったのは、「think carefully」みたいな文言を消せ、という部分です。ふつうは丁寧に思考させたほうが良さそうに見えるのに、このモデルではそれがもう効いていない。むしろ余計な指示があると、返答が遅くなることがある。ここは少し皮肉で、AIを賢くする呪文を足すより、古い呪文を捨てるほうが効く、という話に見えました。 それと、長い作業の途中で「続けますか？」と毎回止まるのではなく、止まる条件を先に決めておく、という発想も実務っぽくて好ましいです。Claude Code の CLAUDE.md に「どこまで勝手に進んでよいか」を書いておくのは、単なる小技というより、チームで作業する時のルー

papoo.work

Claude Codeを「同じ顔」にしないという話に、少し納得した

Claude Code に mods で見た目や振る舞いまで触れるようにする、という発想はわりと面白いと思った。生成AIの道具って、つい「みんな同じUI、同じ返し方」で揃えたくなるけれど、実際の開発現場では好みも作業内容もかなり違う。だから「Claude 体験を一つに固定する理由はない」という考え方自体は、かなり自然に見える。 ただ、そこで気になったのは、見た目を変える話よりも、プロンプトを書き換えたり tool call をブロックしたりできる点のほうだ。ここまで来ると、単なるテーマ変更ではなくて、AI の「振る舞い」を利用者側がどこまで握るのか、という話になる。便利ではあるけれど、同時に怖さもある。何を許して何を止めるかを各自が決められるのは強い一方で、設定が増えるほど「このAI、今どういう前提で動いてるんだっけ」と分からなくなりやすいからだ。 それでも、私はこういう“型にはめないAI”の方向は悪くないと思う。AIを道具として使うなら、統一感よりも、手元の流儀に寄せられることのほうが効く場面は多い。誰にでも同じ Claude を渡すより、使う人の癖に合わせて変形できるほうが、実際に

papoo.work

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

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

papoo.work

Claude Sonnet 5.5で気になったのは、価格より「中間層」の厚み

この記事を読んでまず思ったのは、「上位モデルだけが強い」という見方がだいぶ古くなってきたな、ということです。Opus級に近い性能を、半額の Sonnet で出してくる。こういう話を見ると、モデルの序列そのものより、どの価格帯でどこまで実務に耐えるかの競争が本質なんだと感じます。 特に引っかかったのは、性能向上が単なるベンチマークの話で終わっていないところです。コード系の指標で Opus にかなり迫りつつ、処理速度も上がって、しかも価格は据え置き。これは「ちょっと賢くなった」ではなく、開発現場での使い勝手に直結する変化です。待ち時間が減ると、人は試す回数が増える。試す回数が増えると、結局そのモデルを選びやすくなる。こういう地味な効き方のほうが、派手な性能差より強いのではないかと思います。 一方で、こういう「半額でほぼ上位互換」に見える話は、受け手が少し警戒したほうがいいとも思いました。ベンチマークで近いことと、実際の仕事で常に同じ満足度が出ることは別です。コードを書く場面でも、設計の筋の良さやデバッグの粘り強さみたいな部分は、数字に乗りにくい。だからこの記事は素直に面白いけれど、同時に「

papoo.work