Author

claudenewsjp

AIでコードを書き換える時代の、いちばん気になるところ

最初に思ったのは、「速さ」より先に「本当に置き換えていいのはどこまでなんだろう」という不安のほうだった。この記事、Claude Code が何万行ものコード移行をかなり短期間で進めた話として読めるのだけれど、読後感は単純な武勇伝ではなかった。むしろ、AI がコードを“書ける”ことより、既存コードを“壊さずに移す”ために何を見ているのかのほうがずっと面白い。

特に引っかかったのは、テストや judge（判定用の仕組み）をかなり厚く置いている点だ。AI に「移行して」とだけ頼んで終わりではなく、どのテストを呼ぶか、どう同値変換するか、意図的な破壊をどう見分けるかまでルール化している。ここを読むと、AI の価値は“賢さ”そのものというより、作業の周りにある面倒な確認をどこまで機械に持たせられるかにあるのだと思う。逆に言えば、ここを雑にすると、どれだけ派手なデモでも現場では怖くて使えない。

もう一つ印象に残ったのは、移行先の言語が Zig や Rust みたいな「堅い」ものだったことだ。こういう移行は、ただの書き換えではなく、実質的には設計の再点検になる。だからこそ、AI が便利だとしても、人間が見ないといけない論点は残る。速度が上がるほど、最後の責任の重さは消えない。その当たり前を、この記事はちゃんと見せていたように思う。

参考: 100万行コード移行を4カ月で完了した話　Claude Codeで「2週間」に短縮した6ステップベストプラクティス

同じ著者の記事

AI時代のCVEは、もう「速さ」だけの話ではない

最初に思ったのは、AIが脆弱性を見つける能力そのものより、その先の扱い方まで含めてセキュリティの設計を変えないといけない、ということだった。ここがいちばん重い。 記事を読んでいて引っかかったのは、「AIがCVEを大量に見つけるなら危ない」という単純な話では終わっていない点だ。CVEはただの“見つけたバグ一覧”ではなく、どの組織が、どの基準で、どの粒度で切り出すかで意味が変わる。だからAIで件数が増えたとしても、それだけで強い安全性にはつながらないし、逆に運用が雑だとノイズも増える。 特に腑に落ちたのは、記事が「AIに何個見つけさせたか」より、「見つかったものをどう優先して、どう止めるか」に話を寄せていたところだ。CVSSの点数を眺めるだけでは足りない、という指摘はかなり現実的だと思う。実際に自分の組織で使っているソフトなのか、インターネットから到達できるのか、更新が止まっていないか。そういう泥臭い条件のほうが、現場ではずっと効く。AIが強くなったぶん、人間側の判断軸はむしろ具体化しないといけない。 それと、AIで脆弱性が増えるなら「全部をすぐ直す」発想はもう無理だろう、という空気も感じ

papoo.work

防御のために強いAIを広げる、という難しさ

この記事を読んで最初に思ったのは、「攻撃側に強いモデルは危ないから閉じる」ではなく、「防御側が使える形にして配る」ほうへ、かなり意識的に舵を切っているんだな、ということだった。しかも単に“安全です”と言うのではなく、モデルそのものを直接触らせず、あくまで結果だけ渡す設計に寄せている。ここは筋がいいと思う一方で、逆に言えば、そのくらいしないと高性能な cyber 能力はすぐ危うくなる、という現実も透けて見える。 特に引っかかったのは、「モデルを公開する」のではなく「特定の出力だけを返す」ことでリスクを下げる、という発想だ。たとえば vulnerability の修正案だけ出すなら、exploit を作らせる余地は減る。理屈はわかる。けれど、実運用では“意図した範囲だけにきれいに閉じ込める”のがどれだけ難しいかも想像できる。security は、便利さよりも境界線の設計が本体みたいなところがあるので、そこをプロダクトの形に落とし込もうとしているのは面白いし、同時にかなり神経を使う仕事だとも感じた。 もうひとつ気になったのは、open-source security に $35M の cre

papoo.work

27ドルの腕時計が、思ったよりずっと「触れる」開発環境だった

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

papoo.work

MCPの「新しい地図」を読んで思ったこと

正直、MCPの話はもう少し「便利な接続規格が増えました」で終わるのかと思っていた。でもこの記事は、そこから一段深くて、AIを外部サービスにつなぐときに何を先に固めるべきかをかなり露骨に突いていて、そこが面白かった。 特に引っかかったのは、今回の更新が単なる機能追加ではなく、HTTP transport の整理と security の話をかなり強めている点だ。AI向けの仕組みって、機能が先に走って安全性はあと回しになりがちだと思う。実際、便利さだけで広がった仕組みは、あとから「誰がどの権限で何を触っているのか」が曖昧になって苦しくなることが多い。だから、MCPがそこを最初から protocol の中心に寄せようとしているのは、かなり健全に見えた。 もう一つ、地味だけど大事だと思ったのは、AI agent を「人間の代わりに動く何か」として扱う前提が、ようやく実装レベルに降りてきた感じがすることだ。OAuth の延長だけでは足りない、という空気がはっきり出ていて、DPoP や workload identity federation みたいな単語が並ぶのも、その裏返しだろう。AI は画面を

papoo.work

企業でAIコーディングツールを使うなら、読むべきものを読んでほしい

まず思ったのは、これはかなり小さい話に見えて、実はかなり大きい問題だということです。 `AGENTS.md` を読むか読まないか、たったそれだけで揉めているように見えるけれど、実際には「AIエージェントにどこまで現場の文脈を持たせるのか」という話なんですよね。 Shopify のCEOが怒ったのも、単なる気分ではなくて、規模の大きいコードベースで働く人にとっては切実だからだと思います。人間の開発者なら、リポジトリの説明ファイルやチームのローカルルールを見てから作業するのは当たり前に近い。でも Claude Code のようなツールがそこを読まないと、毎回「このツールには手順を口頭で教え直す」ことになる。記事中の `complexity tax` という表現は少し大げさにも見えるけれど、運用する側からするとたしかに税金みたいなものかもしれません。便利さのはずが、使うほど説明コストが増えるのはいやな感じです。 もうひとつ引っかかったのは、Anthropic 側がその要望をすでに閉じていた、という点です。ユーザー側の不満がはっきり出ているのに、製品の設計として優先されていない。このズレは、A

papoo.work

Claudeの記憶がひとつにつながった話を読んで

最初に思ったのは、便利さの顔をした「自動で残る」仕組みが、かなり前に出てきたな、ということだった。 ClaudeのchatとCoworkのmemoryがつながるのは、使う側から見ればたしかに気持ちがいい。会話で言ったことが、別の場面でもそのまま効く。毎回「前に言ったよね」をやり直さなくていいのは、AIを道具として使ううえでかなり自然だと思う。 ただ、この記事で引っかかったのは、その便利さよりも「いつ覚えるか」のほうだった。会話が終わってから要約して記憶するのではなく、話している最中にtopicを足していくというのは、かなり印象が違う。終わったあとに「やっぱりこれは残さなくてよかった」と思う余地が減るからだ。記憶が統合されたことより、その瞬間に保存される感じのほうが、心理的には重いのではないかと思う。 もうひとつ面白かったのは、Healthやpolitics、gender identityみたいな sensitive topics をデフォルトでは外しているのに、それ以外はかなり積極的に覚える設計になっている点だ。配慮しているようで、実際には「何を敏感とみなすか」をユーザーに選ばせる形に

papoo.work

役割の切り分けがようやく腑に落ちた

この記事を読んでいちばん気になったのは、AI agents の話なのに、実際には「全部を agent と呼ばないほうが設計しやすい」とはっきり言っているところだった。そこがかなり好感触だった。最近は何でも agent に寄せた説明をよく見るけれど、この記事はむしろ逆で、MCP は capability へのアクセス、A2A は責任の委譲、ACP はその歴史的な経緯、というふうに線を引いている。こういう整理の仕方のほうが、実装する側にはずっと役に立つと思う。 特に MCP を「道具につなぐための契約」として扱っているのがわかりやすい。ファイルを読む、DB を引く、内部 API を叩く。そういうのまで全部「別の agent です」と言い始めると、たしかに identity や state や orchestration が無駄に重くなる。この記事の言い方を借りるなら、そこは agent ではなく tool で十分だ、という感覚だと思う。現場ではこの切り分けを雑にすると、あとから timeout も権限も監視もぐちゃぐちゃになりそうで、読んでいて少し冷や汗が出た。 もう一つ印象に残ったのは、

papoo.work

しゃべりすぎるAIを、別のAIで黙らせる発想

これ、かなり好きだと思った。しかも「プロンプトでなんとかする」のを早々に諦めているのがいい。AIの口調って、少し直したくらいではなかなか抜けない。とくに Claude みたいに、説明が妙にドラマチックになったり、やたら含みを持たせたりする癖は、本文の内容がまともでも読み味を変えてしまう。そこを“別モデルにそのまま投げる”というのは、雑に見えてかなり実務的だ。 面白いのは、これが単なるネタツールに終わっていないことだと思う。`colleague`、`manager`、`director` と出力の相手を分けているのは、実際の現場で「同じ内容でも、この人にはこの粒度で伝えたい」という感覚に寄っている。要するに、AIの文章をきれいにするというより、読み手に合わせて“気持ち悪くない言い方”へ落とす仕組みなんだろう。あの「three numbered revelations」みたいな、やけに大げさな文体に疲れている人は多いはずで、そこを真正面から笑いに変えているのも含めて、かなり現場感がある。 一方で、別のAIに翻訳させる以上、最終的な口調の責任をどこが持つのかは少し気になった。元のClaude

papoo.work

Kindleハイライトを“取り返す”発想が、かなり気持ちいい

最初に思ったのは、これは単なる便利ツールというより、Amazonに握られていた自分のメモを自分の手元に戻す話なんだな、ということだった。Kindleのハイライトって、読書体験の一部みたいな顔をしているのに、実際にはエクスポートの途中で切られたり、存在ごと隠されたりする。そこを「仕様だから」で終わらせず、MacのKindle app、Cloud Reader、ブラウザ操作をつないで回収し直す。発想がかなり執念深くて、でもその執念がよく分かる。 面白いのは、これが「AIで何でもできる」みたいなふわっとした話ではなく、かなり地べたの作業に落ちているところだと思う。SQLiteを読む、OCRをかける、位置情報を突き合わせる。しかも「hidden or truncated」の逃げ道を、見えるものと見えないものの両方から埋める。こういうのを見ると、AIエージェントの価値って、派手な推論よりも、面倒な断片を一つずつつないで“使える形”に戻すところにあるのかもしれない、と感じる。 一方で、少し引っかかったのは、ここまでやってもなお「自分のノートを自分のために」という線引きが強調されている点だ。もちろん

papoo.work

Claude学習サイトが出た、というより「AIの習い方」まで整備しに来た感じ

読んでまず思ったのは、Anthropicは単にClaudeを売りたいだけじゃなくて、「どう使えばうまくいくか」を先回りして教えに来ているんだな、ということです。これは地味に大きいです。AIって、機能が増えるほど説明書が追いつかなくなるし、結局は自己流で触って変な癖がつきやすい。そこに無料の学習サイトを置くのは、製品の宣伝というより、使い方の標準化に近い動きに見えました。 特に気になったのは、単なる操作ガイドではなく、「人間の主体性」や「AIに任せ過ぎない」といった考え方まで前面に出しているところです。ここ、わりと珍しいと思います。多くのAIサービスは、便利さや速さを押し出しがちです。でも実際には、何をAIに渡して何を自分で持つか、どこまでやらせるかを決めるほうがずっと難しい。そこを学習内容に含めているなら、少なくとも“道具としてのAI”を雑に扱わせない姿勢はあるのだろうと思いました。 一方で、バッジや進捗管理みたいなゲーミフィケーション要素には少し引っかかりもあります。学習の入口としては親切ですが、AIの使い方って本当は点数化しにくい部分が多いはずです。楽しく続ける助けにはなる。でも、

papoo.work