DevOpsパイオニアが警告：AIエージェントの採用にはツールだけでなく、システムレベルの変更が必要

Agentが生成したコードを修正するのではなく、そのコードを生成するシステムを修正してください。

記事執筆者、出典：InfoQ

開発者がエージェントをうまく使えない場合、問題は開発者にあるのではなく、会社がエージェントが機能するためのシステムを整えていない可能性がある。

多くの企業が謳うAIの変革は、開発者にCursorやClaude Codeなどのツールを購入させ、数回のトレーニングを開催し、あとは各自で摸索させる段階にとどまっている。最終的にエージェントの効果が不十分だった場合、責任は利用者に転嫁される。

しかし、DevOpsという用語を提唱したパトリック・デボイスは、「エージェントが期待通りにタスクを完了しなかった場合、そのエージェントが生成したコードを修正するのではなく、プロンプトだけを変更するのではなく、システム全体を改善すべきだ」と考えている。

デボイスによると、これはソフトウェアエンジニアリングが決定論的システムから非決定論的・確率的システムおよびワークフローへ移行する際に不可避な変化である。これは技術的な側面だけでなく、開発者、チーム、そして組織全体の働き方を再定義する。しかし、この変化は単一のエンジニアだけでは実現できず、単一のチームレベルにとどまることもできない。DevOpsと同様に、スケールして実装されなければ、真に実現することはできない。

問題の核心は、開発者がエージェントを使えるかどうかではなく、企業がエージェントを中心にチーム、プラットフォーム、協力方法を再構築できるかどうかである。

核心观点如下：

• Agentが生成したコードを修正するのではなく、そのコードを生成するシステムを修正してください。
• もしあなたのチームにまだ「YOLO（まず動かしてみる）」という無茶な方法でビブコーディングをしている人がいるなら、すぐに止めるべきです。エンジニアリング実践は、システムの保守にとって重要であるだけでなく、エージェント自身の継続的な改善にも不可欠です。
• 暗工厂は完全な暗黒ではなく、わずかに微光を残している（dim factory）可能性があり、これはどの機能にどの程度のリスクを負うかをあなたが決定する必要があることを意味します。すべての機能が完全な自律に適しているわけではありません。
• AIを極め、堅実なエンジニアリングスキルを持ち、共有と協力を惜しまない人物が、あなたが探している人です。
• あなたの競争優位は、現在skillやContext、さらにはHarnessの制約に注入しているビジネスコンテキストという、蓄積された知識を捉えることにあります。

2009年には、多くの人が継続的デリバリーというアイデアは狂気だと言った。

注：2009年には、業界全体が数ヶ月に1回の大規模バージョンアップを標準としており、リリース回数が増えるほどリスクが高まると一般的に考えられていました。開発と運用の間には厳格な壁があり、コンテナやクラウドなどの自動化インフラは未成熟で、標準化されたパイプラインツールも存在しませんでした。また、従来のテストや変更承認プロセスは、リリース前に可能な限り欠陥を排除することを目的としていました。一方で、継続的デリバリーは高頻度・増分的・いつでもリリース可能という発想を提唱し、ソフトウェアリリースのリスクやプロセス管理に対する従来の認識を根底から覆しました。そのため、多くの企業にとって、これはまるで空想話のように思え、非常に異常だと見なされました。

そして今、暗工厂はまったく同じ抵抗に直面しています。

注：暗工場とは、AIが駆動する自律的ソフトウェア生産モデルであり、人間はSPECを入力するだけで、AIがコードの記述、テスト、リリースを自律的に完了し、人間が一行ずつコードをレビューする必要がない。従来の大量のエンジニアがプロセスに参加する必要がある従来のソフトウェア工場とは異なる。

私はさまざまな場面で同じ言葉を繰り返し聞いてきました。「この仕組みはここではうまくいかない。」しかし、この言葉が真に伝えているのは技術的な問題ではなく、「私たちの準備ができていない」ということです。彼らはこの仕組みを実現したくないのではなく、現在の組織全体の体制がこのモデルを支えることができていないのです。

今、多くの人がどのようにしてループでエージェントを最適化するか、ハーネスを構築するかについて語っています。これらはすべて素晴らしいことです。しかし私が言いたいのは、最終的には私たちはすべてその技術レベルに到達し、いずれそれらは標準的な商品となり、ある最先端の研究室によってサービスとして提供されるようになるということです。その日が来れば、技術的な壁はなくなります。真の差別化は、あなたの組織がこの技術をどう取り入れて協働方法を再構築するかにあります。

したがって、私たち全員が暗黒工場の方向に向かっていると仮定します。Tesslを含む他の企業で観察されたのは、人々がこれらの技術を採用し始めたとき、協力のダイナミクスが根本的に変化するということです。コンウェイの法則に精通している方はご存知でしょうが、組織の構造とツールの間には相互に形作り合う関係があります——どのように人を組織するかによって、どのようなシステムが生まれるかが決まります。しかし今日は、エージェントをより良くする方法について話すのではなく、これがどのようにチームのダイナミクス、プラットフォーム、そして全体の組織を変えるかについてお話しします。

おそらくここにいるほとんどの方が、単独で作業するのではなく、何かしらのチームで働いていると思います。チームで協力して働くことと、一人でClaude Codeに向かってコードを打ち込むことは、まったく別の話です。

今、多くの人がこうした言い方を好んでいます：開発者は最終的に指揮者、あるいはエージェントの編成者になるだろう。私はこの見解に異論はありません。確かに、私たちはその道を歩んでいます。私たちはますますエージェントの管理者に近づいており、エージェントとの関係を管理する必要が生じています。

しかし問題は、多くの開発者が密かにこう言っていることです：私たちがこの業界に入ったのは、こうしたことに時間を費やしてPromptを最適化したり、より良いSPECを書いたりするためではなかった。私たちはエンジニアであり、技術に携わってきた。これにより、自分の役割に対するアイデンティティの葛藤が生じ、常に自分に問いかけるようになります：これは本当に私がやりたい役割なのだろうか？

その後、「コンテキストエンジニアリング」という概念が登場し、開発者にやや救いの手を差し伸べた。これは、単にプロンプトを呼び出すだけでなく、プロンプトのテスト、評価、配布、最適化も行う必要があるという意味であり、確かに多少のエンジニアリングの要素が含まれている。しかし正直なところ、多くの開発者は、プロンプトとSPECだけと向き合うことに虚無感を覚え、自分自身がエンジニアから「プロンプト管理者」に変わったように感じている。

しかし実践の中で、興味深い転機に気づきました。Harnessやループを導入し、組織全体をより高度な自律性へと導き始めたとき、全新的な技術的道筋が開けました。突如として、開発者はAgent用のツールを作成する必要が生じ、その瞬間、多くの人々の情熱が再燃しました。以前は「これは私の仕事じゃない」と思っていた開発者たちが、一転して「そうだ、僕たちにできる！僕たちはその知識を握っている！プログラミングでこのシステムをより良くできる！」と声を上げ始めたのです。したがって、私たちが「抽象化、抽象化、さらに抽象化」と言い続けていた一方で、「職人技」の感覚が別の場所で再び浮上し、よりハードコアなエンジニアリングのための新たな空間が生まれました。

よく人々から聞かれます：「疑念を持つ人々をどう対処すればいいですか？」私の答えはいつも同じです：彼らは実はあなたの宝物です。なぜなら、彼らの頭には膨大な暗黙の知識と判断力が詰まっているからです。それらすべてをエージェントに取り込む必要があります。彼らにこう言ってください：「あなたのすべての知識と厳しさを出し切ってください」。これにより、エージェントとハーネスはより良くなるでしょう。もし「このツールが生成するコードの品質がひどすぎる」と毎日文句を言うような人を見つけたら、彼らを燃料として扱い、その怒りと疑念をシステムの改善への原動力に変えましょう。

今、会社の開発者たちに一つ提案したい。大きなマインドセットの転換だ：Agentが生成したコードを修正するのではなく、そのコードを生み出すシステムを修正しよう。数年前、誰かがこう言ったことがある。「そのものを作るのではなく、そのものを生み出すものを作れ。」今、私たちはまさにその抽象レベルにいる。Context、Harness、ループを通じて、「ものを生み出すもの」を構築している。まだ「Human in the Loop」や自動補完、Promptの調整の段階にとどまっている人々は、自分自身をシステム思考のレベルへ引き上げる方法を考えるべきだ。

私たちが真にすべきことは、優れたエンジニアリング実践を用いて人間の介入回数を最小限に抑えることです。最初のうちは、みんな「vibe coding」が楽しくて、Promptを投げて結果が出れば気にせず次に進んでいました。しかし今では、私たちがAgentに与えるのは単なる指示ではなく、「テストとともにコードを書け」「ドキュメントを更新しろ」「コード規約を守れ」というメッセージであることが明確になってきました。かつて優れたエンジニアに求めていたことすべてを、今やAgentにそのまま適用しているのです。もしあなたのチームにまだ「YOLO（まず動かしてから考えよう）」という野放しのvibe codingを続ける人がいるなら、すぐに止めさせなければなりません。エンジニアリング実践は、システムの保守にとって重要であるだけでなく、Agent自身の継続的な改善にとっても不可欠です。

より前進しているチームの中で、新しい儀式が見られるようになってきた。彼らは依然としてプランニングミーティングとレトロスペクティブを開催しているが、議論の内容が完全に変わっている。レトロスペクティブでは「コードに何が問題があったか」ではなく、「システムに何が問題があったか」と問うようになっている。

計画会でも、興味深い分業が見られました。定義が非常に明確で範囲が十分に明確なタスクは、Harness の性能が向上しているため、そのままエージェントに任せることができます。一方で、境界が曖昧で協議が必要なタスクは、依然として人間が担当します。そのため、計画会では自然な分業が生まれました：これらのカードはエージェントのワークフローに直接流し、あちらのカードは私たちで話し合います。

開発者は一般的に、Promptを学び、次により良いSPEC、その後Context、Harness、ループと学習サイクルを経験します。業界全体もこのサイクルを進んでいます。しかし、チームリーダーができることは、このプロセスにリズムと制約を設けることです。たとえば、「Promptをさらに調整するのをやめて、Contextを再利用可能にしよう」と伝えたり、「このステップは完了した。次に進もう」と促したりすることです。チームリーダーの価値は、このようなリズムを設定することにあります。単に「自分で探しなさい」と放っておくだけではうまくいきません。

さらに、連鎖的な影響があります。チームの生産性が急激に向上すると、GTM（Go to Market）を担当する下流のメンバーや、ユーザーさえもそのスピードについていけなくなります。そのため、自動化を活用して彼らを支援する必要があります。あなたのフレームワークはコーディングの段階で終わらず、彼らの側まで拡張しなければなりません。同様に、上流の要件入力についても、要件の供給が十分でないとチームは停滞します。これらの工程も、この新しいワークフローに取り込む必要があります。

現在、トークンコストなどのさまざまな指標が存在しますが、私は生産性を真正に測るための2つの指標にますます信頼を置き始めています。一つ目は、エージェントが1つのタスクを正しく完了させるために、まだどれだけの人的介入が必要かを数えることです。この数値は継続的に低下すべきです。ハーネスが優れ、コンテキストが整い、ガイドが明確であればあるほど、この数値は低くなります。二つ目の指標は、単独作業から共有システムへ移行した際に生じる乗数効果です。ある場所で何かを修正すれば、すべての人が恩恵を受けます。これは1人が10倍の効率になるという意味ではなく、エージェントシステムへの1回の最適化が全員に乗数効果をもたらすということです。

最初はリポジトリ内や小さなチーム内でスタートし、Contextを共有してHarnessを共同で改善できます。しかし、本当に行いたいのは、この効果を組織全体に拡大することです。その際、プラットフォームチームの話に進む必要があります。

プラットフォームチームは典型的な共有型組織であり、現在はインフラストラクチャ、クラウドサービス、MCPゲートウェイなどの分野に注力しており、Agentに関する取り組みにはあまり注目していません。しかし、新たな要素が次々と登場しており、それらを引き継ぐ必要があります。たとえば、スキル登録センター（誰もが自分の角落で同じスキルを独自に開発しないようにする）、コンテキスト評価システム（このコンテキストは実際に役立っているのか？定量的に測定可能か？）、コーディングAgent専用のガードレールとアイデンティティ管理（Agentは誰の身份でコードを提出するのか？権限の境界はどこか？）。そのため、プラットフォームチームがこの新しい中心的役割へと成長するためには、誰かが手を差し伸べて支援する必要があります。

これは難しい課題であり、推進する明確なオーナーが必要です。しかし、そのオーナーは誰でしょうか？プラットフォームチームですか？開発者エクスペリエンステームですか？前者は通常、開発レベルの作業には関与せず、後者はインフラにはあまり関与しません。そのため、何らかの融合が必要ですが、この融合は自動では起こりません。この中心化された作業を推進する責任者を確実に確保しなければ、あなたのチームは各自の狭い領域でしか活動せず、「舗装された道（Paved Road）」は生まれません。

なぜ各チームが独自に認証システムの連携方式を構築しなければならないのでしょうか？これは共有コンポーネントであり、レジストリに統合すべきです。なぜ各自でハーネスを構築するのでしょうか？もし全チームが同じlinterや同じセキュリティスキャンツールを使用すれば、それは再利用可能なコンポーネントになります。私はこれがかつてのクラウドインフラストラクチャの整備のように、徐々にプラットフォームレジストリに集約されていくと考えています。

しかし問題は、誰でもこの中央リポジトリに自由にものを追加できると、すぐに無秩序に拡大してしまうことです。たとえば、あるスキルがアップロードされた場合、誰がそれをメンテナンスするのでしょうか？別の人が似たスキルをフォークした場合、どちらを選べばよいのでしょうか？そのため、特定の分野を明確に担当する人物が存在し、そのものがテスト可能でモジュール化されていることを保証し、他の人がその上にContextやHarnessのセキュリティスキャン部分を拡張できるようにする必要があります。組織内で適当に渡すのではなく、集中管理の方式で行う必要があります。

コンセンサスを築くのは難しい。これはタブとスペースの議論ほど有名ではないが、時として同じような感覚を覚える。二つの開発チームが作業方法について合意に達させるには、膨大なコミュニケーションと仲介が必要だ。そのため、最終的には一本の舗装路ではなく、三本や四本の道が用意され、彼らが選べるようにする。もし彼らが独自の方法を採用したければ、それは彼らの予算で行えばよい。集中して保守されるのが「楽な道」であり、人々にその道を歩ませるためのものだ。

皆がこれらの共有機能を無計画に使用する場合、そのコストを明らかにしなければなりません。費用を可視化すれば、自然と最適化したいという気持ちが湧いてきます。これはプラットフォームチームの責任です。どれだけ費用がかかったのか、どの程度役立ったのかを明確にすること。Agentの反復回数を減らすことができれば、それが最適化です。しかし、その指標が見えず、最終結果だけを見ていると、手の打ちようがありません。可視化は、すべての最適化の前提です。

したがって、私の核心的な主張は、単独で活動する開発者から、チームレベルでの共有コンテキストと共有コンポーネントへと進み、最終的には組織全体にわたる「マルチプレイヤーゲームシステム」へと移行することです。そこでは、改善が複数の方向に同時に広がるフライホイールが存在するため、乗数効果が爆発します。

その上の階層、VPエンジニアリング部門はこの件をどう考えているでしょうか？私はあなたの組織で起こるであろう物語をほぼ予測できます：ハッカソンやランチタイムでの共有会、成功事例の共有、共有Slackチャンネルの設立、チャンピオンプログラムの実施。これらはすべて一般的な変革のパターンです。かつてアジャイル変革でもそうしましたし、DevOpsでもそうしました。まったく新しいことではありません。

一方で、「ライセンスを発行し、トレーニングを行い、自由にやらせて、千の花が咲くようにする」という戦略はこれまで一度も成功したことがないと私たちは知っています。千の花の結果は通常、千本の雑草に過ぎず、百花繚乱ですが、そのうち一つも実を結ぶことはありません。そのため、私は組織側で明確に権限を付与し、チームリードとプラットフォームチームにこの取り組みを任せることを提唱します。これは、あるスーパーアイビーが単独で成し遂げられるものではなく、正式に推進を委任された人物がいなければ実現できません。

人を頼むのも頭が痛い。現在の職種名はめちゃくちゃで、AI製品エンジニア、フォワードデプロイドエンジニア、エージェンティックエンジニア、AIエンジニア……これらの用語には実質的な意味がない。業界全体が未成熟であるため、肩書きからその人の成熟度を判断することはできない。しかし、採用要件を掲げる際、これらの用語は確かに何らかのシグナルを発し、意図のある人を引きつける。だが、それ自体が相手が必ずしもそのスキルを備えていることを意味するわけではない。さらにひどい話では、面接中に候補者が耳にAIを仕込んでリアルタイムで答えを教えてもらい、面接官が質問するとAirPodsからAIのアドバイスが聞こえるというケースもある。

そのため、より多くの企業がこのような面接方法を採用しているのを耳にします。第一段階では、課題を提示し、AIを自由に活用して解いてもらいます。AIが役立つのであれば、それはむしろAIを上手に活用できる証拠です。第二段階では、彼らに自身の解答を検証させ、「なぜこの方法を選んだのか？どのように正しさを確認したのか？」と説明させます。ここでは、検証能力とエンジニアリングの判断力を試しています。前半はAI活用能力、後半はエンジニアリングの基礎力を評価します。第三に、彼らがどのように協力するか、共有を喜ぶか、オープン型か単独型かを見ます。技術力は高いが、すべてを自分一人で抱え込むタイプの人は、エージェント時代には却ってボトルネックになります。

AIを極限まで活用でき、堅実なエンジニアリングの基盤を持ち、共有と協力を惜しまない——この三点を組み合わせた人物こそ、あなたが探している人である。MLやAIを学んだことのある人でも、暗号解読の専門家でもない。それは一種のハイブリッドな存在だ。三点すべてを満たす人物を見つけるのは難しいかもしれないが、それは問題ない。たとえば、ある候補者はある分野で非常に優れているが、他の分野では指導を必要とするかもしれない。また、これらのスキルを混同して「初心者」や「上級者」とラベル付けしないでください。これらは異なるスキルの次元であり、ある人がAI活用能力は「上級」でも、協力意欲は「初心者」である可能性があります。

VPのエンジニアリング部門は上層部に説明しなければなりません。これだけ多くのライセンスを購入したのですから、投入対効果を証明できますか？納品は早くなりましたか？約束はあるかもしれませんが、証明するのは難しいです。品質は向上しましたか？これも同様に言いにくいです。しかし、私が以前述べた2つの指標に戻れば、介入回数がどれだけ減り、どれだけ改善され、再利用率がどれだけ向上したかを示すことができます。これは「エージェントありとなしのコーディング生産性」を比較するよりもはるかに簡単で、説得力があります。

したがって、誰かがエージェントのコストが高すぎると言ったり、予算を制限すべきだと言ったとき、あなたの本能的な反応は「すべての支出を削除する」ではなく、「支出を最適化する方法は？」であるべきです。最も簡単な方法は、適切なモデルを選択することです。すべてのタスクに最強のモデルが必要というわけではなく、一部のタスクには安価なモデルで十分です。開発者にどのシナリオでどのモデルを使用すべきかを教育し、さらに優れたコンテキストとハーネスを提供することで、エージェントが無駄な道を歩むことを減らし、コストをさらに大幅に削減できます。

チーム規模についてもう一つ話題があります。すべての作業を一人の万能型人材がこなすのは究極の夢ですが、よく考えてみてください。その人は、プロダクトマネージャーやデザイナーなどの補完的なスキルを持つ人と組む必要があります。さらに、誰かが休暇を取った場合に備えて、バックアップ要員も必要です。これでまた三人になります。その後、生産や作業票の監視を担当する人も必要になるかもしれません。もし本当に極めて効率的であれば、同じ人々が兼務する可能性もありますが、バグを修正している間は、新機能の開発速度は落ちてしまいます。さらに、新人がいる場合、彼らに「良い」とは何かを教えるための道筋を用意する必要があります。そのため、私は依然として、組織内ではどのチームも本当に二人や三人にまで縮小することはできないと考えています。

最後に、暗黒工場は完全な暗黒ではなく、わずかに微光を残す（dim factory）可能性があり、これはどの機能にどの程度のリスクを負うかをあなたが決定しなければならないことを意味します。すべての機能が完全な自律性に適しているわけではありません。監査にさらに投資できます。たとえば、ソースを追跡して、コードを変更したのは人間かエージェントかを確認し、コードが実際に有効であることを検証するバリデーターを導入し、自動プロセスが失敗した際に状況認識能力に投資します。完全なマイクロマネジメント（すべてのコード行を人間が確認）から完全な自律承認（エージェントの出力はすべて正しいと仮定）まで、これは一連のスペクトルです。あなたが行うべきことは、リスクレベルに応じて異なるタイプの変更に対して異なる自動化レベルを選択することです。

一方で、あなたの競争優位は、現在skill、Context、さらにはHarnessの制約に注入しているビジネスコンテキストという、蓄積された知識にあると考えます。私にとって、これは継続的デリバリーを継続的学習へと昇華させています。自問してみてください：新しいものをシステムにどれだけ速く導入でき、古いものをどれだけ速く除去できるか？これがあなたの反応能力です。もしこの能力を継続的に改善できるなら、重要な課題は「システム全体をより信頼性高くする」ことではなく、「システムのより多くの部分を変更しながらも、その信頼性を維持できるか？」になります。

もし一文だけ持ち帰るとしたら、それは次の言葉だ：勝者は一人で戦うスーパープレイヤーではなく、複数の層で組織の改善方法を理解する人々である。