#ai開発

AI にコードを書かせる道具は、いまや機能の多さより「毎日使って壊れないか」のほうが重要になってきています。今回取り上げるのは、長く Claude Code を使っていた開発者が、細かな不満の積み重ねから Pi に乗り換えたという話です。単なる乗り換え報告ではなく、AI コーディング支援ツールに何を求め、何にうんざりするのかがかなりはっきり出ています。製品の派手な機能追加が、必ずしも使い心地の改善につながらないことも見えてきます。 筆者は、Claude Code が Claude Pro のサブスクリプションで使えるようになってから長く愛用してきたと書いています。最初に触れたときは、週末の気まぐれな個人プロジェクトに対して、ひとつの prompt だけで雑多な Python コードを出してくることに興奮したそうです。数年後には、このサービスが新しいソフトウェア開発の流れを作った重要な存在として振り返られるはずだ、とも見ています。 それでも最終的に、筆者は Claude Code を主力の coding harness として使うのをやめ、Pi に移る決断をしました。きっかけは大きな一発

この記事を読んでまず思ったのは、「AIに口で注意する」のをやめて、面倒ごとを仕組みに押し込んでいるのが気持ちいい、ということだった。 「秘密を出すな」「完了にするなら確認しろ」「今どれだけ文脈を食っているか見せてくれ」みたいなことは、つい毎回プロンプトに書きたくなる。でも実際には、そういうお願いは忘れるし、忘れた瞬間に事故る。著者はそこをちゃんと見ていて、記憶力に頼るより、Claude Code の中で動く mod に任せたほうがいいと割り切っている。 特に引っかかったのは、hook ではなく mod を使うと軽いという話だ。外から毎回プロセスを起こしてチェックするより、Claude Code の内部で動かすほうが 55〜99 ミリ秒の待ちを減らせる、というのはかなり実感がある。小さい数字に見えるけれど、AI 相手の作業ではこの手の待ちがじわじわ効く。しかも単に速いだけでなく、画面上に plan の進捗を出したり、未テストの完了を警告したりと、ただのガードレールではなく“作業しやすくする UI”にもなっているのがうまいと思った。 一方で、少し怖さもある。mod は便利そ

いちばん最初に思ったのは、「Google、そこまで開くのか」という驚きでした。自社のIDEに他社のAI agentを入れるのは、思った以上に大胆です。普通なら、せっかく育てた自前のAI体験に寄せたくなるはずなのに、今回は逆に“選ばせる”方向に振っている。これは単なる寛容さというより、Android開発の現場で起きている力学の変化をそのまま認めた感じがします。 面白いのは、これが「AIがコードを書く」話で終わっていないところです。Android Studioの中で、agentがproject structureやbuild、Emulator、Logcatまで見られるなら、ただ雰囲気でそれっぽいコードを吐く存在ではなくなります。実際に動かして、ログを見て、失敗を確かめる。そこまで行くと、AIは補助輪というより、かなり実務寄りの共同作業者です。ここが一番おもしろいし、少し怖くもある。便利さが増すほど、開発者は「どこまで任せるか」をちゃんと考えないといけなくなるからです。 一方で、少し引っかかったのは、こういう仕組みが広がるほど、結局は“使える人が使いこなせる道具”になりやすい点です。Chan

AI エージェントにコードを書かせるのが当たり前になりつつある一方で、「動くかどうか」と「何をしているか」を同じものとして扱う危うさも目立ってきた。今回紹介する Sphinx は、そのズレを Git の push 直前にわざわざ突きつける仕組みだ。コードを最終的に通す前に、変更の意味を人間に説明させる。便利さを追う流れの中で、あえて立ち止まらせる発想が面白い。 Sphinx は、agent-assisted development 向けの Git hook だ。つまり、コードを書いたあと、Git の push の場面で割り込んでくる。しかも止める理由は、テストが落ちたからでも、lint が通らないからでもない。Sphinx が知りたいのは、そのコードが実際に何をするのか、そして何かがうまくいかなかったときにどう振る舞うのかだ。 導入はかなり簡単で、元記事では `npm install -g sphinx-understand` として入れ、`sphinx install` を実行する流れが示されている。対象は Git そのものにも、OpenRouter や OpenAI-compati

いちばん印象に残ったのは、「レビューは人間が読むもの」という前提をかなり崩しているのに、雑になっていないことでした。普通ならコードレビューを自動化すると、最後は誰かが薄く眺めて終わりになりがちです。この記事のやり方は逆で、機械に読ませる場所を増やすほど、人間は「本当に危ないところ」だけを見るように寄せている。そこが気持ちいいです。 特におもしろかったのは、レビューを“最後の関門”ではなく、書いている途中からずっと走る仕組みに変えている点です。テストを通す、build を見る、別 context の agent に diff を見せる。そうやって PR の前からかなりのミスを潰しておく。これ、言われてみれば自然なんですが、実際に運用まで持っていくのはかなり難しいはずです。人間のレビューを減らすには、単に速くするだけでは足りなくて、戻しや incidents が増えないことをちゃんと見ないといけない。その視点が一貫していました。 もう一つ、地味だけど大事だと思ったのは、「human review を減らした」ではなく「human time and attention を守る」と言っていると

Anthropicが、自社の開発基盤の中核にあるsource controlをGitから自前実装へ移した。理由は単純で、コードを書く速さではなく、変更をさばく仕組みのほうが先に詰まったからだ。Claudeが研究ループの反復やサービス開発まで担うようになり、1日にマージされるコード量が短期間で桁違いに増えた。この記事は、その“開発がAIで速くなった結果、古い前提のツールが足を引っ張る”という現象をかなり具体的に示している。 Anthropicによると、2026年5月ごろは1日あたり約2,500件だったコードのマージが、9月には30,000件を超えた。増え方が極端だが、同社ではClaudeが研究ループを自律的に回し、複雑なプログラムを最適化し、新しいサービスをゼロから作ることまでできるため、そもそものコード生産量が止まらないという。問題はコードを書くことではなく、それを受け止めるsource control、build、CIのほうになった。 そこでAnthropicはScionという社内版のversion control systemを作り、monorepoをGitから5か月で完全移行した

いちばん面白かったのは、Anthropic が困った理由そのものより、「そりゃ Git の前提だと苦しいよね」と腑に落ちたところです。 ふつう Git は、開発者がローカルに丸ごと持っていって、オフラインでも作業できることに価値があります。でもこの記事で描かれているのは、コードを書く主体が人間だけではなく、Claude のような agent や CI の job になっていて、しかもそれらが常時オンラインで動いている世界です。そこで「全部を手元に持つ設計」が重荷になるのは、かなり自然だと思いました。 特に引っかかったのは、Git が優れていた性質そのものが、規模が変わると足を引っ張るという点です。 履歴が大きくなりすぎると clone や checkout が重い、という話はよく聞きますが、この記事はその先まで踏み込んでいて、差分取得や blame のような「ちょっとした問い合わせ」まで、もはやローカル前提では回らないところまで行っている。しかも Anthropic では、単に人が困っているのではなく、機械が毎日大量にコードを動かすので、問題が一気に表面化する。ここはかなり現代的だなと

いちばん最初に思ったのは、これは派手なアプリというより、地味だけど毎日効く道具だな、ということだった。会議の文字起こしはもう珍しくないけれど、匿名の Speaker 1, Speaker 2 が並ぶだけだと、あとで読み返しても結局つまずく。そこに名前が付くだけで、検索のしやすさも、記録としての使い勝手もかなり変わるはずだ。こういう「小さい不便」を潰す用途に、coding agent がよくハマっている感じがする。 面白かったのは、著者が「新しいものを全部毎回判定する」のではなく、いったん音声を埋め込みとして保存して、似ている話者なら自動でつなぐ設計にしているところだ。埋め込みは、ざっくり言うと音声を数値の地図に置き換えて、近いもの同士を探すやり方だと思えばよい。人間が毎回同じ人の声を聞いて判別する代わりを、機械にやらせている。発想としては地味だけれど、これが「一度ラベルを付けたら次から楽になる」仕組みを支えている。 一方で、少し引っかかったのは、匿名の transcription をかなり信頼している点だった。実際には会議音声って、かぶり話しや雑音やマイク品質の差があるので、そこをどこ

読んでまず思ったのは、これは単なる「使い方のコツ」ではなく、LLM を道具としてどう運用するかの話なんだな、ということだった。Claude Code が高くつくから注意しよう、では終わっていない。むしろ、どこで余計な文脈を切り、どこにだけ計算資源を使わせるかを、かなり露骨に設計している。ここが面白い。 特に引っかかったのは、`/compact` の扱いだ。会話を短くするだけなら何となく想像できるけれど、記事を読むと「短くする」こと自体が目的ではなく、次のターンに残すべき情報を選び直す作業になっている。人間のメモ整理とかなり似ている。要らない雑音を削ると同時に、後で効くものだけを残す。逆に言うと、雑に長話を続けるほどコストが膨らむ。ここは、AI を賢くするというより、人間側の整理力がそのまま料金に跳ね返る感じがして、なかなか生々しかった。 もう一つ、`/clear` や context の切り替えがやたら強調されているのも印象的だった。普通のツールなら「履歴が残る」のは便利さの象徴だけど、Claude Code では履歴がそのまま負債にもなる。過去の情報を全部抱え込むのではなく、タスクご

Claude Codeの changelog は、単なる修正一覧ではなく、この開発ツールがどう現場向けに育ってきたかをそのまま映しています。今回のページには 2.1.277 を中心に、細かな不具合修正から管理機能、プロキシ対応、プラグイン周りの改善まで、かなり大量の変更が並んでいました。生成AIの話題は新機能ばかりが目立ちますが、実際に使う人に効くのは、こうした地味な修正の積み重ねです。だからこそ、この changelog を読む意味があります。 この changelog は GitHub 上の `CHANGELOG.md` から生成されていて、`claude --version` で手元の版を確認できる、と案内しています。ページで最上位に出ているのは 2.1.277 で、日付は September 18, 2026 です。ここで追加されたのは、まず `CLAUDE.md` がないプロジェクトでは `AGENTS.md` を読むようにした点です。プロジェクトごとの指示ファイルの読み方を広げた形で、設定画面の “Project instructions” から切り替えられますが、Bedr

この記事で一番引っかかったのは、「これは便利そうだ」と思うのと同時に、「でも今いちばん困っている人にはまだ届かないのか」という距離感だった。クラウド上では、複数のthreadを束ねて、shared memoryまで持たせて、プロジェクト全体をまとめて動かせる。たしかに、AI coding agent が増えてきた今、個々のagentを賢くするより、どう管理するかのほうが先に難しくなるので、この発想はかなり筋がいいと思う。 特に面白いのは、threadごとに会話を分けつつ、それらが互いに memory を共有するという設計だ。普通の「AIに一発で全部やらせる」やり方だと、途中で話が崩れたときに戻りにくい。でもthreadを名前付きで追いかけられて、途中から方向修正もできるなら、AIを“暴走しやすい作業者”ではなく、“途中で指示を出し直せる部下”として扱える。そこはかなり実務っぽい進化だと感じた。 一方で、この記事を読んで素直にモヤっとしたのは、memory の中身がよく見えないことだ。何が保持され、どこまで残り、消せるのかがはっきりしないまま「shared memory」と言われても、現

ちょっと意外というより、むしろ「そこまで来たか」と思った。自社のGeminiを推している会社が、社内の開発用途で競合のClaudeを広く使わせる。しかも「選択肢として少し許す」ではなく、エンジニア全体に開く。AIの競争って、表向きの製品発表より、こういう社内の足元での判断に本音が出るんだなと感じた。 記事を読んで引っかかったのは、GoogleがGeminiを“主力”だと言いながら、実際にはClaudeのほうがコーディングで頼りにされている空気がにじんでいることだ。社内ツールで使う、と言っても無制限ではなく quota 付きなのがまた生々しい。完全な敗北宣言ではないけれど、現場の生産性を優先するときには、看板モデルにこだわっていられない。大企業のAI活用って、理想論より「誰が速く書けるか」で決まるんだろう。 それと、Googleだけの話ではないのも面白い。Amazonも似た動きをしていると書かれていて、結局どの会社も「自前のAIを使え」と言いつつ、実務で強い外部モデルは切り捨てきれない。AIモデルの競争は、機能の優劣だけじゃなく、社内でどこまで使わせるかという運用の競争でもあるんだと思う

AIアプリ向けの周辺コードは、便利になるほど太りやすい。ルーティング、proxy、cache、課金計測、各社SDKの差分吸収まで抱え込むと、使いたい人には少し重い。GitHubに公開された `kennethwolters/litelm` は、その「重さ」を削ること自体を目的にしたプロジェクトだ。元記事は、LiteLLMの機能をかなり絞り込み、どこを残し、どこを捨てたのかをはっきり示している。単なる軽量化の話ではなく、LLM周辺ツールに何を求めるかを問い直す内容でもある。 `litelm` は、名前の通り LiteLLM に似たAPIを持ちながら、機能をかなり削った実装として紹介されている。説明文では「litellm without the bloat」とあり、LiteLLMの routing と translation を中心に、約2,900行、依存関係は `openai` と `httpx` の2つだけだと強調している。LiteLLM側は、複数プロバイダへのLLMルーティングやメッセージ形式の変換を担う一方で、proxy server、cache、cost tracking なども抱

この記事を読んでまず思ったのは、こういうノスタルジーはもう単なるお遊びではなく、ちゃんと「体験」として成立しているんだな、ということです。Windows 3.1風の見た目を再現したランチャーを、Claudeを使って短時間で作ったという話は、技術デモとしても面白いのですが、いちばん引っかかったのはそこよりも「12MBで、Windows 11でもApple Siliconでも動く」という軽さのほうでした。昔のOSっぽさを再現するのに、いまどきの機械でわざわざ重いエミュレータを抱えなくてもいい。そこは素直に気持ちいいです。 一方で、こういうものを見ると、AIで“作れた”こと自体が主役になりすぎる怖さも少しあると思いました。1時間で作った、と聞くと確かにすごい。でも本当に面白いのは速さそのものより、「その速さで、どこまでちゃんと遊べるものに仕上がるのか」だと思うんです。懐かしさを売りにするなら、ただ古い見た目を貼っただけではすぐ飽きられる。逆に、触った瞬間にあの時代の空気を思い出させるなら、それはもう立派なプロダクトの手触りがある。この記事は、その境目をちらっと見せてくれた感じがしました。 -

この記事を読んでまず思ったのは、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月に米国の社員向けに始まりました。名前はおだやかですが、やっていることはなかなか強烈です。記事によると、このツールはマウスの動き、クリックした場所、キー入力、さらには画面の内容まで集めます