一言で言うと
「AIで開発が速くなった」という話は、数値だけ追うと半分しか読めません。珍しいのは、成果を出した責任者が同じ場で「まだ解けていない問題」を並べたことです。速度向上と、それに伴う組織の変化——両方を同じ報告に載せた点が、今回の発表の価値です。
何が起きているのか
The Decoderが2026年5月31日に報じた内容によると、SalesforceのエンジニアリングトップであるSrinivas Tallapragada氏が、AnthropicのAIコーディング支援「Claude Code」を開発組織全体に展開し、トークン制限（AIが一度に処理できる文字量の上限）なしで全開発者に開放した結果を公開しました。
公開された数値（2026年4月 対 2025年4月比）
Tallapragada氏が発表した数値は次のとおりです。開発者あたりの完了タスク数が50.8%増加。マージ済みPR数が79%増加。ML（機械学習）ベースの「実質アウトプットスコア（Effective Output Score：開発成果の量を社内指標で測ったもの）」が151.3%改善。PRの急増にもかかわらず、インシデント（本番環境での障害・問題）は5%減少したとされています。
これらはすべてSalesforce自身による発表値であり、第三者による独立した検証は行われていません。
具体例：33個のAPIエンドポイントの移行
Tallapragada氏が前面に出した事例は、33個のAPIエンドポイント（他システムとやり取りする接続口）をクラウド向け設計へ移行した案件です。見積もり231人日の作業が13日で終わったとされ、PR79%増などの集計数字の「顔役」に据えられた、と読めます。
Claude向けのルール（Markdownと参照コードのセット）を用意し、PRの指摘を都度ルールに反映させながら、ビルド（プログラムを実行可能な形に変換すること）・修正・検証を自動で回した、と説明されています。並行処理によりPRは5本に集約され、最大の1本で21エンドポイントがテスト付きで実装された、とされています。
開発者の役割と新しい成果物
Tallapragada氏によると、開発者はコードを直接書く人から、複数のAIエージェントを指示する「オーケストレーター（調整役）」へシフトしつつあります。チーム固有の作法を再利用できる「Claude Code skills」や、全社共通の「AI Expert Suite」といった仕組みが、新しい開発の成果物として生まれています。
チーム編成も変わりつつあります。従来のスクラムチーム（2週間ごとに成果を出すアジャイル開発の小チーム）に代わり、1人または3人という小単位での実験が始まっていると、Tallapragada氏は述べています。
Tallapragada氏自身が挙げる「本当に難しい未解決問題」
一つ目は「長いエージェントセッションでのコンテキスト（文脈・背景情報）管理」で、エンジニアが習得すべきスキルとしてまだ発展途上だと言います。
二つ目は「CLAUDE.md（Claude向けのプロジェクト設定ファイル）の品質がチームごとにばらつき、出力の質に直結する」こと。
三つ目はセキュリティです。エージェントがシステムを操作するようになると、設定ミスの影響範囲が格段に広がり、セキュリティの考え方を根本から作り直す必要があると述べています。
そして最も根本的な問いです。「AIが初級の実装作業を担うようになったとき、ジュニアエンジニアはシニアエンジニアにどう育つのか。デザイナーやプロダクトマネージャー（企画・要件をまとめる役）の役割はどう変わるのか」。Salesforceにはまだ明確な答えがない、とTallapragada氏は認めています。
AI業界の文脈では
5月28日夜版で触れたCognition（AIコーディングエージェント「Devin」）の「市場は実需フェーズか」という問いに対し、今回は「大企業が全社導入したらどうなったか」という報告です。Tallapragada氏の若手育成問題は、Andrej Karpathy氏が指摘した「動くが品質は低いコード量産」と合わせて読むと、速さと組織の学習能力のトレードオフを示唆します。Karpathy氏自身はエージェント型開発を支持していますが、この品質問題を「解決した」とは言っていません。
私の見立て
最も注目すべきはPR数79%という数字ではなく、「ジュニアエンジニアの育ち方が分からなくなった」というTallapragada氏の発言だと考えます。エンジニアリングの知識はかつて、初級の実装・レビュー・リファクタリング（動作を変えずコードを整理すること）の繰り返しで積み上げられてきました。エージェントがこの「実行層」を担うと、若手はいきなり「オーケストレーター（調整役）」を求められますが、そのスキルは実行経験なしには身につきにくい。ARR（年間経常収益）規模のSalesforceが「まだ答えがない」と言っている問いは、今後数年で各社の試行錯誤が積み上がる領域だと見ています。
留保も2点あります。今回の数値はすべて自己申告で、Effective Output Scoreの定義も外部検証も公開されていません。「231日→13日」も見積もりとの比較です。また「インシデント5%減」は短期指標であり、技術的負債（後回しにした修正の積み残し）や長期保守性には触れられていません。Karpathy氏が指摘した「動くが汚いコード」問題が、1〜2年後にどう現れるかはまだ分かりません。
それでも、大規模開発組織が「全社移行後の課題」を正直に公開したこと自体は、AIエージェント導入の議論を実装の話から組織論へ引き上げる材料として、今後参照される可能性があると考えます。
→ 何が変わるか: AIコーディングエージェントの評価軸が、「どれだけコードを速く書けるか」から「エージェント中心の開発体制に移行したとき、セキュリティ・品質・人材育成をどう設計するか」へ移っていきます。Salesforceが「まだ答えがない」と言った問いが、各社の採用・研修・セキュリティ設計の再検討を迫る問いになっていきます。
→ 何をすべきか: 全社展開を検討している組織は、生産性の数値目標と同時に「若手の育成経路」と「エージェントが操作する権限範囲のセキュリティ設計」を先に議論することを勧めます。CLAUDE.mdのような設定ファイルの品質管理も、チームをまたいだ標準化が早めに必要になります。Salesforceの事例は、これらを後回しにすると規模が大きいほど問題が複雑になることを示しています。