彼らがあなたに描く肖像：AI SREは代替品とされ、コーディングアシスタントはパートナーとされる
AI SREとコーディングアシスタントのマーケティングフレームは分化：前者はSREを置き換えるものとして位置づけられ、後者はエンジニアの増強ツールとして包装されている。
日本語
コピー
彼らがあなたに描いてみせる姿
AI SRE とコーディングエージェントの売り込み方には、かなりはっきりした違いがあると前から気づいていた。コーディングアシスタントはエンジニアを強化するものとして売られ、名前まで付けられている。一方の AI SRE は「AI SRE」のままで、決まり文句はたいてい「誰も生産性のない作業に気を取られずに済む」というものだ。コンポーネントやエージェントに名前を付け、擬人化するのが良いことだとは思わない。だが、何に名前が付き、技術者に向けてどんな枠組みが使われるか——この二つを並べると、かなり雄弁に何かが見えてくる。
これは新しい現象ではない。音声アシスタントが、人々が抱くステレオタイプや偏見を広く再生産してきたことはすでに指摘されている——それがどう作られるかにおいても、どう使われるかにおいても。だから発表や売り込みを目にするたびに、パターンがひとりでに浮かび上がってくる。LLM の時代にも、エージェントについて同種の議論がある。エージェントもまた、コーディングされた特定の力学と価値観を体現していると見なせるのだ。
ここで扱うのは、既存製品にすでにある視点へのちょっとした補足にすぎず、網羅的でもない（たとえば Sales Development Representatives も AI SDR としてこのリストに加わっており、そこには各種の専門職、職人、アーティストも並ぶ）。AI SRE とコーディングアシスタントを例に取ったのは、組織内の比較的近い二つの職能の間に生じた分岐を、この二つがはっきり示しているからだ。
観察
以下は、この分野のニュースや発表をネットで見て回りながら集めた、各製品の簡単な整理だ。サンプルは科学的ではないが、現在の市場の参加者を十分にカバーしている。
AI SRE
| ベンダー | 製品名 | 売り込みの枠組み | 備考 |
|---|---|---|---|
| bacca.ai | AI SRE | 「cuts downtime before it cuts your profits」、「stop firefighting, start innovating」、「frees your engineers from the grind of constant troubleshooting」 | |
| resolve.ai | AI SRE | 「Machines on-call for humans」、「Removing the toil of investigations, war rooms, and on-call」、「Operates tools and reasons through complex problems like your expert engineers」🔗 | 同社の AI SRE バイヤーズガイドも同じ枠組みを提示している。「engineering velocity stalls because teams spend the majority of their time firefighting production issues rather than building new capabilities.」 |
| Neubird | AI SRE、Hawkeye | 「No more RCA Delays」、「No more time lost to troubleshooting」、「no more millions lost to downtime, delays, and guesswork.」 | Hawkeye というスーパーヒーロー風の製品名はプレスリリースと FAQ の一項目には出てくるが、製品ページにはそれ以外どこにも見当たらない。動画の最後では「AI SRE Teammate」という言い方が使われている。 |
| Harness | AI SRE、AI Scribe、AI Root Cause Analysis | 「Scales your response, not your team」、「Reduce MTTR」、「Standardize first response」、「Let AI Handle The Busy Work While Your Team Solves What Matters」 | FAQ では人間の SRE と AI SRE を明確に対比している。「Traditional SRE relies on manual processes and rule-based automation, while AI SRE uses machine learning to adapt, predict issues, and automate complex decision-making at scale.」 |
| incident.io | AI SRE | 「resolves incidents like your best engineer」、「The SRE that doesn't sleep」、「No need to stall the whole team」、「Keep builders building」、「AI SRE does all the grunt work [postmortems] too.」 | |
| Rootly | AI SRE、Rootly AI | 「AI SRE agents and your teams resolve incidents together」、「your expert engineer in every incident」、「quickly identify root causes and the fix—even if you don't know that code」 | 2025 年末、このページは別の枠組みに差し替えられた。「Detect, diagnose, and remediate incidents with less effort」となり、チーム連携には触れていない |
| cleric.ai | Cleric | 「本番環境の問題を調査し、有効なやり方を蓄積して、チーム全体のスピードを上げる」「答えへ直行する」「エンジニアの邪魔を取り除く」 | まともな名前が付いた数少ない製品のひとつ。DnD の支援職へのオマージュかもしれない。 | | AlertD | AI SRE | 「SRE と DevOps のための AI Agent」「何時間もスクリプトを書いたりツールを切り替えたりするのはもう終わり」「AI Agent で SRE と DevOps の実践知を結集する」「あなたの DevOps と SRE がベストプラクティスを教える AI Agent の次の一手」「AI ダッシュボードとインサイトを共有して、もっと賢く動く」「あなたの AI でもっと賢く働く」 | 私が調べた製品のうち、SRE と DevOps を 置き換える のではなく 助ける と位置づけているのは2つだけだが、これはそのうちのひとつ。 | | AWS | DevOps Agent | 「24時間365日稼働する自律型オンコールエンジニア」「インシデントを解決し、未然に防ぎ、信頼性と性能を継続的に高める」、MTTR を削減し […] 運用卓越性を推進する。 | | | Ciroos | Ciroos | 「SRE のスーパーヒーローになる」「人の創造性を増幅する」「サイト信頼性エンジニアリング（SRE）、IT 運用、DevOps チームのための AI SRE チームメイト」🔗「あらゆる SRE チームの能力を拡張する」 | SRE と DevOps チームを 助けたい と考えているもうひとつの製品。名前は比較的人間らしい。FAQ に書かれた自動化モデルは俗説をいくつか繰り返しているが、このリストの他のどの製品よりも透明で、現実的でもある。 |
免責事項：上記はいずれも実際に使ったことはなく、各製品の自社ページをもとにまとめたものだ。
これらの製品のうち、チームでの協働に言及しているものはごくわずかで、SRE チームのチームメイトだと自ら位置づけているものは2つしかない。残りはおおむね、この仕事は大したことではない、あるいは置き換えられるべきものだと述べており、なかには非常に露骨なものもある。名前はスーパーヒーローや DnD の支援職から取ったものもあれば、置き換えようとしている役割そのものをそのまま名乗っているものも多い。
コーディングアシスタント
| ベンダー | 製品名 | ポジショニングの文言 | 備考 |
|---|---|---|---|
| Anthropic | Claude Code | 「ビルダー／プログラマー／クリエイターのために」「欲しいものを説明すれば、あとは Claude がやる」「ツールを行き来する必要はもうない」「コードを書く場所であなたに寄り添う」「主導権はあなたにある」 | 人名。委任のさまざまな側面を強調している |
| Gemini code assist | 「可能性を解き放ち、開発をやり切る」「制約の少ないコーディングを体験する」「開発を加速する」「反復作業を[肩代わりする]」「コードレビューの時間を短縮する」 | 名前はラテン語で「双子」。能力拡張と委任の両方を狙ったポジショニング | |
| Zed | Zed（エディタ） | 「速度と人と AI の協働のために作られたミニマルなコードエディタ」「あなたの書き方で働く AI」「人と AI の間の流れるような協働」 | 厳密にはコーディングアシスタントではなく、それらが協働する環境 |
| Github | Copilot | 「自分の技を極める」「あらゆるワークフローのアクセラレータ」「フローを保つ」「コードを書き、指示し、協働する」「一緒にコードを書く AI でより速く届ける」 | 名前が示す役割自体が協働的で、名前もポジショニングも、あなたが主導するという前提のもとで協働を説明しようとしている |
| Cline | Cline | 「あなたのコーディングパートナー」「本質的に協働的、承認を得て自律的に」「完全に協働する AI パートナー」「大規模なコードベースでも一貫した変更を加える」 | |
| Windsurf | Cascade、Editor | 「AI でコードを書く最も強力な方法」「無限の計算資源、完全なフロー」「時間を節約し、より速く製品を届ける」「ボイラープレートや雑務に費やす時間を大幅に減らし、構築の面白く創造的な部分に集中できる」 | エディタ側は厳密にはコーディングアシスタントではないが、agent も提供している |
| Cursor | Cursor（エディタ） | 「驚くほど生産的にするために作られた」「タスクを任せることで開発を加速する」「PR をレビューし、Slack で協働し、ターミナルで動く」「長く使えるソフトウェアを開発する」 | 同じくコーディングアシスタントではないが、それらとやり取りできるタブがある |
| OpenAI | Codex | 「本物のエンジニアリング作業を動かすために作られた」「機能の構築、複雑なリファクタリング、移行などを端から端まで確実にやり遂げる」「agentic コーディングの司令塔」「チームの構築方法に適応する」「バックグラウンドで常時動くために生まれた」 | より決定的な代替役として自らを位置づけている数少ない AI コーディングツールのひとつ。とはいえ口先ではチームとの協働にも触れている |
免責事項：上記のツールは一部は試したが、すべてではない。このリストは各製品の自社ページをもとにまとめたものだ。
上の表を見れば分かる通り、これらのツールの名前はどれもかなり独特で、人名をそのまま使ったものもある。ほとんどはエンジニアやチームを強化し、より効率的に、自分の担当範囲でより多くのことをこなせるようにするツールとして売り込まれている。
では、これは何を意味するのか？
これらの製品の見せ方は、まったく対照的な二つの姿を描き出している（それぞれのカテゴリに例外はあるにせよ）。
- ソフトウェアエンジニアリングの仕事は価値ある仕事と見なされる。エンジニアが主導権を握り、より多くの能力、より多くの制御、より高い生産性を得るべきだ。AI はパートナー、チームメイト、あるいはアシスタントとして存在する。
- ソフトウェア信頼性エンジニアリングの仕事は負担と見なされる。チームはこうした作業に邪魔されず、より価値の高い仕事に精力を注ぐべきだ。睡眠が必要だといった人間の限界は克服されるべきものとされる。AI は労働者を置き換えるために存在する。
こうしたパターンは、業界内部にあるこれらの役割への見方をそのまま外へ映し出しているのかもしれない。
たとえば、以前書いたが、インシデントや障害は組織の学習を促す好機だと私は考えている。この捉え方は必然的に、SRE を重要な仕事をしている職種と見なし、そこから目を背けたくはないという立場になる。ところが AI SRE の背後にあるビジョンは正反対だ。インシデントや障害は、蓋をして先へ進むだけの一回限りの例外であって、自分の仕事（とその進め方）が生む構造的で創発的な帰結でも、そこから学ぶべきものでもない。
この手の現象が面白いのは、実務者が自分の仕事をどう捉えているか（インシデントから学ぶことは必要だ）と、上の意思決定者がその仕事や職能をどう捉えているか（振り返りなど単なる苦役だ）との間に生じる断絶を映し出す点だ。
秘書を原型にした AI アシスタントが、主従関係を模したビジョンを体現していると見なされたように、私たちがさまざまな労働者のために AI ツールをどう作るかは、そのツールを作る側がその仕事をどう見ているかを露わにする。
だがこれは、買い手がその仕事をどう見ているかのシグナルでもある。売り込む相手がパートナーやチームメイトという立場なら、二つの相手に同時に売り込まねばならない。将来そのツールで働く従業員と、そのために金を払う雇用主だ。一方、売り込む技術が職務や職能を置き換えるものであるなら、説得すべきは予算を握る一人だけで済む。
ここから推測できるのは、これらのツールが映し出すのは、同じ職務に対する取引当事者双方の認識が混ざり合ったものだということだ。もし自分が従業員で、そのツールが自分が重視する仕事のごく一部しか担っていないと感じるなら、それはおそらく、本当に権力や影響力を持つ人々の中で、自分と同じようにそれを重視している人がほとんどいないということを意味する。
だからといって、組織が代替を必ず成功させるとは限らない。歴史は繰り返し示してきた。職務の一部は自動化され、集約され、残りはより少ない人数にのしかかる。彼らは自動化しにくい作業をこなし、ついでに残りの自動化の調整も引き受ける。これが残余原則と呼ばれるものだ。
自動化の能力が上がり、組織がそれに場を空けるために自らを作り替えるにつれて、この力学は進化し続ける。
私の目にはすでに明らかなことが一つある。多くの作り手と買い手が SRE に対して抱く想像は、しばしば極端に単純化されていて、かなり不名誉なものだ。この職務が今も消えずに残っているのは、作り手や買い手が思っているより多くのものを含んでいるからだろう。ソフトウェアエンジニアリングについて今描かれつつある姿も同じく不完全だと私は思う。どの程度かは、あなたが作って制御したいシステムがどれだけ複雑かによる。
彼らは今、何を描いているのか？
好奇心から、コード生成のすべてを自動化すると謳うフレームワークがどう自己演出しているかも見てみた。上の表の Codex はその方向へ動いているが、この種の製品は増え続けている。
Anthropic は agent teams を打ち出しつつある。そこではチームメイトはあなたの下にいる。あなたが team lead に指示し、team lead がチームメイトに指示する。この言説が語るのは制御だ。協働は agent に委ねられ、あなたは依然としてそれらをより直接的に管理できる。GasTown はあなたをプロダクトマネージャーの席に座らせ、開発チーム全体をより深い階層へと抽象化する。Amp も同様にさまざまな agent（スキル、役割、コストがそれぞれ異なる）を調整するが、想定ユーザーはあくまで開発者であり、この類推をそこまで強くは押し出していない。
熱意は確かにあり、Software Factory 的な発想に関する報告も増えている。たとえば StrongDM が人間によるレビューを許さないコードを試しているとか、成果工学宣言とかだ。いずれも、未来は高次の制御者として多数の無個性な agent を束ね、うまく働かせるために彼らを制約し、十分な情報を与えることにある、と示唆している。
潮流は、ソフトウェアエンジニアとその自動化の間のパートナーシップから、私にはむしろテイラー主義を思い起こさせる姿へと移りつつあるように見える。この移行が起きるのは、生産を手工業的な労働から自動化するとなると、人々の頭に浮かぶのがこれだからかもしれない。
これらの製品は類推によって構想されている。よく知った型を持ってきて、いくつかの重要な特徴を別の領域へ写し取る。これは新しい領域を探るごく普通のやり方であり、ある領域の理解を別の領域へ移すことだ。
素早くコードを吐き出すことに多くの人が価値を見出すのは分かる。だが、労働者がテイラーが考えたより多くのものを貢献できると信じるなら、このビジョンは限定的だ。もし agent はそこまで有能ではないから当てはまらないと信じるなら、還元主義的な人格化も同じくそぐわない。どちらの場合でも、私たちはより良い類推を求め、探すべきだ。私たちの実際の働き方をよりよく言い表すことは、より良いツールをもたらすはずだから。
類推はてこのようにもなり、拘束衣のようにもなるからだ。あるモデルに閉じ込められると、何もかもをその用語で説明するようになり、別の視点に立つことや、その過度な単純化から抜け出すことがずっと難しくなる。そして新たな領域への理解が十分に深まれば、理想的にはもうその類推に頼る必要はなくなる。あなたの理解そのものが自立するからだ。
テイラー主義的ソフトウェア工場の枠組みを受け入れること、あるいは仕事を低地位なものと規定するために作られたAI SREを受け入れることは、社会の側でもこうした言説を増幅し、正当性を与えることに加担している。その代償として他の設計が犠牲になり、現実の仕事を下手に戯画化した製品がこの領域を埋め尽くす。敬意にも欠け、概念的にも貧弱だ。
新しいものを生み出すことはかつてなく安く、簡単で、手の届くものになったと、いつも誰かが言う。理屈の上では、関わる全員が問題空間を探索し、学ぶための時間を増やせるはずだ。現実はどうか。
彼らが描くあなたの肖像は、情報量は多い。ただ、あなたとはほとんど関係がない。