Author

claudenewsjp

Android StudioにClaudeとCodexが入ってくる違和感と期待

いちばん最初に思ったのは、「Google、そこまで開くのか」という驚きでした。自社のIDEに他社のAI agentを入れるのは、思った以上に大胆です。普通なら、せっかく育てた自前のAI体験に寄せたくなるはずなのに、今回は逆に“選ばせる”方向に振っている。これは単なる寛容さというより、Android開発の現場で起きている力学の変化をそのまま認めた感じがします。

面白いのは、これが「AIがコードを書く」話で終わっていないところです。Android Studioの中で、agentがproject structureやbuild、Emulator、Logcatまで見られるなら、ただ雰囲気でそれっぽいコードを吐く存在ではなくなります。実際に動かして、ログを見て、失敗を確かめる。そこまで行くと、AIは補助輪というより、かなり実務寄りの共同作業者です。ここが一番おもしろいし、少し怖くもある。便利さが増すほど、開発者は「どこまで任せるか」をちゃんと考えないといけなくなるからです。

一方で、少し引っかかったのは、こういう仕組みが広がるほど、結局は“使える人が使いこなせる道具”になりやすい点です。Change Reviewみたいなレビュー支援は確かに助かるはずですが、AIが大きな変更を作るようになると、レビューの意味自体も変わります。読む量が減るのか、読む対象が変わるのか。そこはまだ整理しきれていない気がします。便利にはなる。でも、開発の責任の置き場所まで自動で軽くなるわけではない、という当たり前を改めて感じました。

参考: Google is letting Claude and Codex into Android Studio, and that changes everything

同じ著者の記事

Claude CodeがiOS Simulatorに対応　Apple向けアプリを作って試せる時代に

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が勝手に画面をいじって、こっちは何も触れない、みたいな窮屈さがないのはいいですね。 今回のポイン

papoo.work

Claude CodeがiOSアプリの実機テストに近いことをMac上でできるようになった話

Claude CodeのMacアプリに、かなり面白い新機能が入りました。iOSアプリを、ClaudeがSimulator上で実際に動かしながらテストできるようになったんです。しかも会話画面の横にシミュレーター用の表示が出て、コードを書かせて、そのまま動作確認までつなげられる。これは開発体験としてかなり気持ちいいと思います。 Anthropicが公開ベータとして、Claude Code DesktopにiOSアプリのテスト機能を追加しました。対象はPro、Max、Teamプランのユーザーです。使えるのはClaude Desktop v1.24012.0以降。そして前提条件として、XcodeにiOS platformが入っていることが必要です。 ここでいうSimulatorは、iPhoneやiPadの代わりにMac上でアプリを動かす仕組みです。実機そのものではありませんが、起動して、画面をタップして、スワイプして、UIの確認をするにはかなり便利です。開発者なら「毎回本物のiPhoneをつないで試すの、地味に面倒だよね」と思ったことがあるはずで、そこをClau

papoo.work

Claude Cookbookをのぞくと、AIアプリ開発の「今」が見える

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

papoo.work

グーグルがClaudeを解禁したことについて

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

papoo.work

Claude Codeで自動承認が標準になったことへの違和感と納得

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

papoo.work

Claude CodeがRust版Bunを使い始めた話

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を動かすための

papoo.work

Claude Codeの「見えない重さ」に驚いた

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

papoo.work

Claude Codeのセッション同士が話せるようになって思ったこと

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

papoo.work

Claude Codeのトークン浪費を見て思ったこと

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

papoo.work

Claude Codeの新しいProjectsを読んで、まず気になったこと

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

papoo.work