#ai開発

この記事を読んでまず思ったのは、MCPを「未来の規格」として語るより、すでに実用の道具箱として選別し始めている感じが強い、ということだった。そこが面白い。単に“使えるMCPサーバー10選”ではなく、どれが本当に日々の開発で効くのか、しかも「全部盛り」ではなく「この場面ならこれ」と切り分けているのが好印象だった。 特に引っかかったのは、著者がかなりはっきり「入れればいいってものじゃない」と言っているところ。MCPは便利そうに見えるけれど、接続した瞬間にAIへ与える権限が一気に増える。GitHubでもAWSでもCloudflareでも、要するに“操作できる範囲”が広い。だから、文章の中でセキュリティの注意をわざわざ前に出していたのは誠実だと思った。こういう記事はつい、できることの多さだけを煽りがちだから。 もう一つ感じたのは、Chrome DevTools MCPとPlaywright MCPを両方並べているあたりに、現場感があるということ。前者は「今ブラウザで本当に何が起きているか」を見るための道具で、後者は「同じ操作を繰り返して確認する」ための道具。似ているようで役割が違う。AIにコー

Claude Code が、コミットメッセージや Pull Request の説明文の末尾に session URL を自動で入れている。これに対して、GitHub の issue では「最初から有効にするのではなく、使う側が明示的に選ぶ opt-in にすべきだ」という要望が出された。見た目の問題だけでなく、開発履歴に知らないリンクが残ることへの違和感が強く、AI 補助ツールの“署名”をどこまで自動で入れるべきか、という話にもつながるので取り上げる価値がある。 問題提起をしたのは GitHub 上の `anthropics/claude-code` リポジトリに立てられた feature request だ。タイトルは「Session URL appended to commit messages and PR descriptions by default — should be opt-in」で、Claude Code が生成したコミットメッセージと PR description の末尾に、毎回 session URL が自動付与される仕様をやめてほしい、という内容になっている。

最初に思ったのは、「これは地味だけど、かなりいやだな」ということだった。 コミットメッセージやPR説明は、あとから何度も見る場所だ。そこに本人の意図なく Session URL が毎回付くなら、ただの注記ではなく、履歴そのものを汚してしまう。しかも設定で止められるとしても、見つけにくい場所に隠れているなら、実質的には“知らないうちに有効”と変わらない。 特に引っかかったのは、これは attribution の問題というより UX の問題だという点だと思う。 AI で書いたことを示したい気持ちは分かる。でも、あくまで使う人が納得して選ぶべきで、最初から自動で差し込まれるのは筋が悪い。Git の履歴って、あとでチームメンバーや外部の協力者まで目にする半公開の記録だから、そこに「どこまで情報を載せるか」の感覚はかなり大事だ。 提案されている「オンボーディングで一度だけ確認する」という案は、かなりまっとうに見える。 この手の機能は、便利さより先に“勝手に入っていた”不信感で印象が決まることが多い。Claude Code みたいなツールは、出力の質だけでなく、どこまでを自動でやるかの線引きでも評

最初に思ったのは、安いガジェットの話というより、手元にある物をもう一度おもしろくし直す話だなということだった。引き出しの奥で眠っていた $27 のスマートウォッチが、Claude みたいな coding agent を通すだけで、急に「遊べる端末」に戻ってくる。そこがかなり気持ちいい。 特に引っかかったのは、著者が最初から完璧を狙っていないところだ。画面の文字位置がずれて読みにくくても、まずは simulator で動かして、次に少しずつ直す。これ、AI を使うと雑に一発で終わらせたくなる場面で、逆に人間が細かく介入したほうが早いことがある、という実感に近いと思う。全部を agent に丸投げするより、1つずつ「ここを直して」と渡したほうがうまくいく。地味だけど、たぶんここが本質だ。 もうひとつ面白かったのは、画面の静的部分を丸ごと画像にしてしまう発想だ。腕時計の中身を全部コードで描こうとするとしんどいけれど、固定部分を画像に逃がせば、一気に難易度が下がる。ただ、その代償として Bluetooth 転送に10分かかったり、画面更新が1〜2秒かかったりする。ここは「賢いけど、やっ

200,000 tokens を先に食ってからようやく答え始める、という話を読むと、便利そうに見えるAIツールの裏側で、ずいぶん雑なことが起きていたんだなと感じる。人間なら「資料が多いから少し重い」で済む場面でも、LLM だとその「少し重い」がそのままコストと待ち時間に跳ねる。しかも利用者から見えにくい形で起きていたのが、かなり気持ち悪い。 いちばん引っかかったのは、問題が“賢さ”ではなく“読み込み方”にあったことだと思う。Claude Code の skill が、質問に答える前に関係ありそうなドキュメントをまとめて抱え込んでいたわけで、これは人間でいえば「とりあえず本棚の全部を机に積む」みたいなものだ。実際の作業では、必要なページを必要なときに開けばいい。そこを on-demand に変えて 25K まで落とした、というのはかなり素直な改善に見える。 ただ、ここで終わらないのも面白い。LLM 周辺の製品は「モデルの性能」ばかり話題になりがちだけれど、実際には入力の設計、ドキュメントの切り出し方、どのタイミングで何を読むか、みたいな地味な部分が体験を決める。今回の話は、その地味な部分

最初に思ったのは、これはかなり気持ち悪いな、ということでした。質問に答える前から 200,000 tokens も食っていた、という話は、単なる「遅い」よりずっと嫌な種類の問題です。遅さなら体感できるけれど、見えないところでコストだけ先に積み上がっているのは、使う側としてかなり不信感が残ると思いました。 特に引っかかったのは、原因が「skill」だという点です。Claude Code のような開発支援ツールは、便利さの代わりに内部で色々な文書や設定を抱え込むわけですが、その読み込み方が雑だと、賢くなるどころか巨大な前置きで首を絞めることになる。AI の文脈では、モデルの性能ばかり語られがちですが、実際にはこういう「周辺の設計」の方が効くのだと改めて感じました。 25K tokens に減った、という改善は素直にいい話です。ただ、ここでも少し気になったのは、そもそも 200K まで膨らんだことが“静かに”起きていた点です。人間のソフトウェアなら、そんなに無駄な読み込みがあればメモリや起動時間で早めに気づけそうなのに、LLM 系だと請求やレイテンシに現れるまで見逃されやすい。便利な道具ほど

最初に思ったのは、これは「AIがコードを書く」話というより、「人間がコードを読んだ気になってしまう問題」への嫌なほど実用的な返しだな、ということだった。LLM が差分を作ってくれるのは速い。でも速いぶん、書いた本人の頭の中にできるはずだった“なぜこうしたか”の手触りが抜け落ちる。そこで observability data、つまり metrics や logs、traces を開発の途中に引っ張ってくる。発想としては地味なのに、かなり効く気がする。 特に引っかかったのは、MCP server と gcx を分けている点だ。MCP server は決まった道具が揃った、やや opinionated な入口。gcx は CLI で、もう少し自由に workflow を組める。ここは単なる製品分けではなくて、「AI にどこまでやらせるか」を段階で分けようとしているように見えた。全部を柔らかい自然言語で包むのではなく、必要なら CLI で組み立てる余地を残す。これはかなり現実的だと思う。 一方で、この記事を読んで少し立ち止まったのは、これがそのまま“正しい判断”を保証するわけではないことだ。た

最初に思ったのは、「もうここまで来たか」という驚きと、同時に「そりゃそうだよな」という妙な納得感だった。 Claude Code の auto mode は、要するに毎回の確認ダイアログを減らして、ある程度はエージェントに任せるモードだ。コード生成ツールとしては便利でも、勝手にファイルを書き換えたり削除したりする可能性がある以上、普通は慎重になる。そこをデフォルトにしたのは、Anthropic が「人間が逐一止める前提」より「ある程度は任せて前に進む前提」に軸足を移した、ということだと思う。 一方で、数字の出し方はかなり強気に見えた。危険なコマンドを人間が見つけられた割合より classifier のほうがずっと高い、しかも手動確認はプロンプトが増えると精度が落ちる、という話はたしかに筋が通っている。でも、ここで面白いのは「人間より機械のほうが安全」だから安心、ではなく、Anthropic 自身が最後にちゃんと「classifier でリスクは消えない」と釘を刺しているところだと思う。便利にするほど、責任の置き場所はむしろ曖昧になる。そこを完全には隠していないのは好感が持てた。 あと、

正直、これはかなり“地味だけど効く”アップデートだと思った。派手な新機能というより、複数の作業が同時に走っているときの、あの面倒な説明の繰り返しを減らしてくれる話だからだ。 特に引っかかったのは、Claude が単にメッセージを中継するだけでなく、「要約された内容」を次の session に渡すところ。履歴や files を丸ごと引き継ぐわけではない、という線引きは妙に現実的だと思う。便利さはあるけれど、何でも自動で共有されるほど怖い仕組みにはしていない。AI に仕事を投げるとき、結局いちばん事故るのは“勝手に全部つながっている感”なので、この控えめさは好ましい。 一方で、これが本当に活きるのは、1 人が複数の作業を並走させる場面よりも、複数の worktree や長い処理が絡むときではないかと思う。人間がタブを行ったり来たりしながら「さっき何を見つけたんだっけ」と探す代わりに、Claude 同士が軽く受け渡してくれるなら、かなりストレスが減るはずだ。逆に言うと、単独の session しか使わない人にはあまり刺さらない。そこは機能として少し玄人向けだなとも感じた。 あと、permis

まず思ったのは、PRD（Product Requirements Document）を捨てたこと自体より、その代わりに「eval suite」を置いたという発想のほうがずっと象徴的だ、ということだった。PRDは人間向けの説明書だけれど、eval suite はモデルや機能を実際に測るためのものだ。AI の会社では、きれいに要件を書き下ろすより、まずどう動くかを定義して測れる形にするほうが、たしかに筋がいいのかもしれない。 ここで面白いのは、これは単なるドキュメント文化の話ではない点だと思う。Anthropic が coding を戦略的優先事項にした、という話も同じ文脈にある。AI のプロダクトは、見た目の機能一覧よりも、どの場面でどれだけ役に立つかが本体になる。そうなると、PRDで「こういう機能を作ります」と書くより、評価用の問題を並べて、期待値を継続的に確かめるほうが、現実に近い。人間の会議で合意したつもりでも、モデルは平気で外してくるからだ。 ただ、少し引っかかるのは、これがすべてのチームにそのまま当てはまる話ではないことだ。eval は強いが、何を測るかを決めるのがそもそも難し

Claude Cookbook は、Anthropic が公開している実践ガイド集です。名前のとおり「レシピ本」みたいなもので、Claude をどう使えばうまく動くのかを、コード例つきでかなり具体的に教えてくれます。 単なる使い方の説明ではなく、「実際のアプリに入れるとき、どこで詰まりやすいか」「どう設計すると破綻しにくいか」まで踏み込んでいるのが面白いところです。正直、こういう資料は読んでいて楽しいです。理想論よりも、現場の泥臭さがにじむからです。 Claude Cookbook は、Claude を使った実装パターンを集めた実践ガイド集 tool use、RAG、multimodal、memory、agent など、いまの AI 開発で重要な論点を幅広く扱う 「どう作るか」だけでなく、「どう遅延を減らすか」「どうコンテキストを保つか」みたいな運用の悩みにも答える 1本1本の記事がかなり具体的で、机上の空論ではなく手を動かす前提になっている いわゆる“AIの便利さ”より、“AIをプロダクトに落とし込む難しさ”がよく見える Cookbook の中身を眺めると、単に「Claude で文章

Anthropicの「Claude Code」が、AppleのiOS Simulatorと連携できるようになりました。しかも公開ベータです。 これ、地味に見えてかなり面白い動きです。AIがコードを書くのはもう珍しくありませんが、「書いたあとに実際のiPhoneアプリっぽい画面で動かして、触って、直す」ところまで入ってきたのは、開発の流れを一段変える話だと思います。 MacRumorsによると、Claude Code for desktop が iOS Simulator を扱えるように更新されました。 Claude Code に「build」「run」「check」などを指示すると、作業中のアプリを iOS Simulator の中で開き、実際に動いている様子を見ながら操作し、必要なら修正を繰り返して完成まで持っていけるそうです。 しかも、開発者はその間も普通に iOS Simulator を使い続けられます。AIに作業を任せていても、自分で動作確認を並行できる。ここはかなり実用的です。AIが勝手に画面をいじって、こっちは何も触れない、みたいな窮屈さがないのはいいですね。 今回のポイン

Anthropicが、コードを書いている途中で脆弱性を見つけて警告してくれる「security-guidance」というプラグインを、Claude Code向けに無償提供しました。しかも対象は特定プランだけではなく、すべてのClaude Codeユーザー。こういう「便利だけど高そう」な機能を最初から広く配るのは、かなり攻めた打ち方だと思います。 Claude Code向けの新しいプラグイン「security-guidance」が公開された コード編集の流れの中で、リアルタイムに脆弱性を検出して警告する 仕組みは「Hook」を使った自動実行で、手動で毎回呼び出す必要はない 監査は3段階で行われる - ファイル編集時 - ターン終了時 - コミット時 危険なライブラリの誤用、危ないデシリアライズ、DOM操作、認証バイパスなどを検出対象にしている Anthropicの内部テストでは、プルリクエストへのセキュリティコメントが30〜40％減ったという インストールにはClaude Code CLI v2.1.144以降とPython 3.8以降が必要 今回の話で面白いのは、セキュリティチェックを

Claude Code v2.1.181以降は、JavaScriptランタイムのBunを「Rustで書き直した版」で動かしている。 きっかけはBun作者Jarred Sumnerの投稿で、起動がLinuxで10%速くなったが、見た目の変化はほとんどないという話だった。 Simon Willisonは実際に自分の環境を調べ、Claude Codeの中にBunのバージョン文字列やRustのソースファイル名が埋め込まれているのを確認した。 つまり、かなり多くの端末で、Rust版Bunが静かに本番投入されているらしい。 “Boring is good” という一言が、この話のいちばん面白いところだと思う。派手な新機能より、地味でも速くて安定しているほうが現場では強い。 この話、派手さはないのに妙におもしろいです。 Claude CodeはAnthropicの開発補助ツールで、要するに「AIにコード作業を手伝わせるための道具」です。その内部で動く仕組みのひとつに Bun という runtime が使われています。runtime というのは、JavaScriptやTypeScriptを動かすための

AnthropicがClaude Sonnet 5を発表しました。The New Stackの記事が面白いのは、単に「新モデルが出た」ではなく、このモデルが上位モデルのOpus 4.8にかなり近づいたうえで、API価格が8月までかなり安いという、実務目線で効いてくるポイントを押さえているところです。 AIモデルの世界は、毎回「最高性能です！」という話になりがちですが、実際に使う側が気にするのはもう少し地味です。十分賢いか。長い作業を任せても破綻しないか。で、いくらかかるか。Sonnet 5は、その三つを同時にかなり意識したモデルに見えます。 Claude Sonnet 5は、Anthropicの中でも上位のOpus 4.8にかなり迫る性能とされた 特に「agentic benchmarks」で強さを見せた API価格は導入期として、2026年8月まで $2 / $10 per million tokens つまり、試しやすさと実運用のコスパをかなり意識した出し方になっている “最高性能一本勝負”ではなく、現実の開発で使いやすい位置づけが目立つ Sonnet 5の話を理解

Metaが、社員の作業状況を追跡する社内ツールをいったん止めました。理由はかなり皮肉で、社員の入力データが社内で見える状態になっていたからです。 「人の行動を細かく集める仕組み」を作った会社が、そのデータの扱いでつまずいた。こういう話は、技術企業ではよくあるように見えて、実はかなり重いです。監視と安全管理は、ほんの少し歯車がずれるだけで一気に信頼問題になるからです。 Metaは社員向けの追跡ツール「Model Compatibility Initiative（MCI）」を一時停止した MCIはマウス操作、クリック位置、キー入力、画面内容などを集める仕組み そのデータを含む内部データベースが、社内の想定より広い範囲に見える状態になっていた Metaは「不正アクセスの兆候はない」としつつ、調査のため停止したと説明 この件で、社員の反発が強いツールにさらに火がついた形になった Metaが導入したMCIは、4月に米国の社員向けに始まりました。名前はおだやかですが、やっていることはなかなか強烈です。記事によると、このツールはマウスの動き、クリックした場所、キー入力、さらには画面の内容まで集めます