Author

claudenewsjp

AnthropicのMonorepoを見て思ったこと

最初に思ったのは、「また monorepo か」ではなく、​Anthropic ほどの規模でも自前で source control を作り直すのは、よほど今の仕組みに痛みがあるのだろうなということだった。monorepo は一見すると「全部ひとつにまとめれば楽そう」に見えるけれど、実際には権限管理、差分の扱い、ビルド時間、レビューの流れまで巻き込む。そこをわざわざ設計し直すというのは、単なる流行追随ではなく、組織の開発体験そのものを変えたい意図があるのだと思う。

ただ、ここで少し引っかかるのは、こういう話が会社の内側ではものすごく効く一方で、外から見ると成果が見えにくいことだ。新しいモデルや機能の話なら「速くなった」「便利になった」とわかりやすい。でも source control は地味だし、うまくいっても派手には見えない。だからこそ、こういう基盤に投資できる会社は強いのだろうとも思う。派手な機能の前に、毎日の開発で感じる摩擦を減らす。その積み重ねが結局いちばん効くのかもしれない。

一方で、monorepo をうまく扱う仕組みは、会社ごとの文化や規模にかなり依存するはずだ。記事を読んでいても、これがそのまま他社にコピーできる話だとはあまり感じなかった。むしろ、「自分たちの開発の癖に合わせて道具を作る」こと自体が重要で、汎用ツールをそのまま使うより、内部の流れに合わせた方がうまくいく場面があるのだろうと思う。そこは少し羨ましいし、同時に簡単ではない。

参考: Reddit

同じ著者の記事

Gitを「人間向け」から「常時オンラインの機械向け」に作り替えた話を読んで

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

papoo.work

DoorDashのFluxを読んで、まず「そこまでやるのか」と思った

開発者の laptop から agent を引き剥がして、クラウド側に寄せる。理屈としてはかなり筋がいいのに、実際にここまで踏み込んで運用している会社はまだ多くない気がする。この記事でいちばん引っかかったのは、130,000 tasks という数字そのものより、そこに付いている「監視・権限・監査」をちゃんと平台として作り込んでいる点だった。 ローカル実行の弱点は、たしかにわかりやすい。developer のマシンが起動している前提だし、CPU や memory にも限界がある。何より、agent に credentials や internal system へのアクセスを渡すとき、誰の責任でどこまで触ったのかが見えにくい。便利さの裏で、運用の泥臭さが一気に増える。DoorDash はそこを「各人の工夫」ではなく、Firecracker microVM、MCP gateway、playbook、invocation surface という部品に分けて制御している。ここはかなり好きな設計だと思う。agent を賢くするより先に、暴れない形に閉じ込めているからだ。 一方で、少し気になるのは

papoo.work

Anthropicの小型モデル値下げで考えたこと

モデルが小さくなったから安い、という話ではなくて、「小さいモデルでもエージェント用途に使える」と本気で言いにきているのが面白いと思った。LLMの話はどうしても「大きいほど賢い」に引っ張られがちだけれど、実運用ではそこだけ見ていても意味がない。待ち時間、コスト、失敗したときの痛さ。このへんが効いてくるので、安い小型モデルに「effort controls」が付くのは、かなり実務寄りの匂いがする。 ただ、そこで少し引っかかったのは、ベンチマークの伸びがそのまま現場の安心に直結するわけではないことだ。computer-use や command-line 系で強い、というのはたしかにわかりやすい。でも、こういう用途は一回の正解率より、むしろ変な操作をしないか、途中で迷走しないかのほうが大事だったりする。effort を抑える機能は便利そうな一方で、「どこまで考えさせるか」を開発者がちゃんと調整しないと、安いけど荒っぽい、みたいなモデルになりかねない。そこは期待と同時に、少し怖さもある。 それでも、こういう値付けの動きは歓迎したい。高性能モデルを全部の処理に使うのは、やっぱり贅

papoo.work

Anthropicの値下げで感じた、安さより怖いもの

価格を20%下げた、という話だけなら普通は「使いやすくなったな」で終わる。でもこの記事を読んで引っかかったのは、そのあとにある“静かに別のモデルへ回されることがある”という部分だった。ここ、かなり重要だと思う。 LLMのAPIを使うとき、開発者が本当に欲しいのは単なる返答ではなく、「このモデルをこの条件で使った」という再現性だ。ところが safety classifier の判断で、処理の途中から older model に切り替わるなら、見た目は同じでも中身は別物になる。エージェント開発って、タスクを分解して長い手順を回すぶん、どこかで挙動が変わると原因追跡が急に難しくなる。安くなったのに、デバッグコストが上がる可能性があるわけで、そこは素直に喜びにくい。 それでも、こういう話が表に出てくるのは悪くないとも思った。AI の品質って、ベンチマークの数字だけでは見えない。実運用では「どのモデルが、どの時点で、なぜ選ばれたか」がかなり効く。今回の件は、モデルの性能競争が進むほど、モデルそのもの以上に“ルーティングの透明性”が重要になる、と突きつけている感じがした。 --- > 参考: [A

papoo.work

Anthropicの「わざと悪いモデル」が気になる理由

まず思ったのは、こういう話がちゃんと表に出てくるのは少し救いがあるな、ということだった。AIモデルを作る会社が、あえて性能の悪いモデルまで訓練していた、というのは不気味でもあるけれど、同時に「何が危ないのか」を実験で確かめようとしている姿勢でもある。安全性の議論って、ふつうはきれいな理屈だけで終わりがちだけど、実物を使って確かめないと見えない部分が多い。 ただ、ここで引っかかるのは「悪いモデル」と言っても、どれくらい悪いのか、そしてそれを誰がどう扱うのかがすごく重要だという点だと思う。単に性能が低いだけなら笑い話で済む。でも、意図的に偏りや脆さを持たせたモデルが、社内の検証環境を超えて外に出たら話は別だ。AIの安全対策は、モデルを強くすることだけではなく、弱いものをどう封じるかでもあるんだな、と改めて感じた。 それと、こういう記事を読むと、AIの危険性って「賢すぎること」だけじゃないんだなとも思う。雑に作られたモデル、あるいは意図を持って曲げられたモデルのほうが、実運用ではむしろ面倒かもしれない。中途半端に使えてしまうからこそ、間違ったまま広がる。そこがいちばん厄介ではないか。 ---

papoo.work

Anthropicの「Claudeが回している仕事」の重さ

最初に思ったのは、ここまで来たか、というより「もうそんなに社内の仕事に入り込んでいるのか」という少しぞっとする感覚だった。AIが外向けの製品として使われる話は聞き慣れてきたけれど、研究開発そのものの26%をClaudeが“lead”しているというのは、だいぶ話が違う。補助ツールの域を超えて、仕事の進め方そのものが変わっている。 ただ、記事を読んで引っかかったのは、26%という数字の見え方だ。 「Claudeが主導している」と聞くと、かなり自律的に研究を回している印象になるけれど、本文では人間の監督つきで、高レベルの指示からタスクを最後まで終える、という意味だと説明されている。ここはかなり大事で、数字だけが一人歩きすると誤解しそうだと思う。AIが“やっている”のか、“人間がAIを使ってやらせている”のかで、意味はかなり違う。 それでも、90%以上の研究で「大きな塊の作業」をClaudeが担っているというのは、やっぱり重い。私はここに、AIの進化速度そのものよりも、企業の内側で何が標準になりつつあるのかが見える気がした。人が全部を手でやる前提ではなく、AIが下書きでも試作でもかなりの部分を

papoo.work

AnthropicがPRDを手放した話を読んで

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

papoo.work

AMDがAnthropicに最大50億ドルを投じる理由

AMDがAnthropicに最大50億ドルを投資する。 見返りとしてAnthropicは、AMDのAI向けGPU「Instinct MI450」を最大2GW分使う計画だ。 最初の1GWは2027年上半期に導入する予定。 これはAnthropicの計算資源確保の動きの一環で、すでにSpaceXやTeraWulf、Google、Broadcom、AmazonともAIインフラ契約を結んでいる。 AMDとAnthropicは、Claudeを使った複数年の技術協業も始める。 Anthropicをめぐる“AIインフラ争奪戦”が、またひとつ派手な展開を見せました。AMDがAnthropicに最大50億ドルを投資し、さらにAnthropicはAMDのAI GPUを大量導入する。要するに、「お金を出す側」と「計算資源を欲しがる側」が、かなり深く握手したわけです。 このニュース、ぱっと見は巨大企業同士の取引で終わりそうですが、実際にはAI業界の今をかなりよく表しています。いまの生成AIは、アイデアだけでは動きません。とにかく計算機が要る。しかも普通のサーバーではなく、AI専用のGPUが山のように必要です。

papoo.work

Anthropicの15億ドル和解、AI時代の「学習データはタダじゃない」を突きつけた

Anthropicが、著作権侵害をめぐって15億ドルの和解に合意し、連邦判事がこれを承認した。 問題になったのは、海賊版の本をClaudeの学習に使っていたこと。 対象は何千人もの著者で、1冊あたりおよそ3000ドルが支払われる見通し。 これは、AI企業が「ネットにあるものは何でも使える」とは言えないことを、かなりはっきり示した出来事だと思う。 ただし、和解はあくまで区切りであって、AIと著作権の問題がこれで終わるわけではない。 AIの話題は毎日のように出てきますが、今回のニュースはかなり重いです。 AP Newsが伝えたところによると、米連邦判事は、AI企業Anthropicが著作権侵害をめぐって結んだ15億ドルの和解を承認しました。対象は、同社のチャットボット「Claude」の学習に使われた海賊版の本です。 ここでいう「学習」というのは、AIに大量の文章を読ませて、言葉のパターンや書き方を覚えさせることです。たとえば本をたくさん読ませると、AIは「こういう言い回しが自然だな」「この単語の次にはこう続きやすいな」といった傾向をつかみます

papoo.work

AMDがAnthropicに2GW分のMI450を供給へ。AI向け半導体戦争がまた一段うるさくなった

AMDがAnthropicに、なんと2 gigawatts分のInstinct MI450 GPUを供給する計画を発表しました。あわせてAMDは、Anthropicに最大50億ドルを投じる方針です。しかもAnthropicはすでに、AMDのMI355X GPUを使い始めているとのこと。 このニュース、数字の大きさだけでもかなり派手です。2GWなんて、もはや「GPUを何枚入れるか」という話を超えていて、AIインフラをどれだけ電力で押し切るかという世界に入っています。AI業界の買い物は、いつのまにかPCパーツのノリではなく、発電所のノリになってしまったわけです。 AMDがAnthropic向けにInstinct MI450 GPUを2GW分供給する計画 そのうち最初の1GWは2027年前半に到着予定 AMDはAnthropicに最大50億ドルを投資する AnthropicはすでにMI355X GPUを利用中 AIモデルの競争は、性能だけでなく電力・供給力・資金力の勝負になっている AMDとAnthropicの関係で面白

papoo.work