AIネイティブSDLCはインフラから始まる

AIネイティブSDLCはインフラから始まる Eyal Bukchin · 2026年8月30日 · 6分読書 このページで Anthropicは、コーディングエージェントを中心にソフトウェアライフサイクルを再構築するためのプレイブックを公開しました。その前提は、従来のSDLCはコードを書くことが遅い部分だった時代に設計され、エージェントがその部分を高速化し、制約がその周辺のステージに移ったということです。 このフレームワークには6つのステージがあり、各ステージは次のステージが読み取れる成果物をコミットします。計画はintent.mdを生成します。設計はそれをspec.mdに変換します。ビルドは、コードが編集される前にplan.mdを生成します。デプロイは、REVIEW.mdにレビューポリシーを配置します。 これはほとんどのプロセスドキュメントよりも具体的ですが、プロセス全体が実際に機能するかどうかを決定する重要な詳細が欠けています。それは、エージェントのコードが自己チェックを行う際に何に対して実行されるかということです。 ステージ4：エージェントが自身の作業をチェックする場所 ステージ4はフィードバックループであり、エージェントがエンジニアが見る前に自身の作業をチェックします。プレイブックでは、テスト、ビルド、またはスクリーンショットの差分など、チェックするためのものを与えるように求めています。修正中にテストファイルを編集することをブロックするフックを使用して、エージェントが赤いテストを緑に変えるのを防ぐように指示しています。UI作業については、MCP経由でブラウザまたはスクリーンショットツールを配線することを提案しています。 次に、それはほとんどの組織が行っていることよりもさらに進んで、コーディングエージェント自身の設定をソフトウェアとして扱うように求めています。CIで実行される評価（evals）は、CLAUDE.md、スキル、およびフックのいずれかが変更されるたびにそれらを再テストし、すべての本番インシデントを永続的な評価に変換します。 ステージ4が、それらのすべてが機能する前に、ローカルで各コマンド1つで実行できるテストスイートとビルドを用意するように求めていることです。その前提条件が、プレイブックが終了し、あなたのインフラストラクチャが始まる場所です。エージェントには実行できるテストが必要であると述べています。それらのテストが何に対して実行されるかについては述べておらず、多くの他のサービス（データベース、キュー、サードパーティAPIなど）と通信するサービスの場合、それは質問の大部分を占めます。 検証が難しい理由 テストがそれらの多数のサービスをエージェントのマシン上の偽のコピーに対して実行される場合、テストの合格はコードが偽物に対して機能することを示します。クラスター内の実際のサービスに対して機能するかどうかは別の問題です。 同じテストを実行する開発者は、それらをどの程度信頼できるかを大まかに知っています。彼らは、偽の請求サービスが1年前に書かれ、実際のサービスが2ヶ月前に認証ヘッダーを変更したことを知っています。偽の検索エンドポイントが常に同じ3つの結果を返すことを知っていますが、実際のサービスはページネーションしています。そして、偽のセットの何もレート制限されたりタイムアウトしたりしたことがないことを知っています。エージェントはそのいずれも知りません。テストが合格したと見て、作業完了を報告します。 これはプレイブックの欠陥というよりは、カバーできる範囲の限界です。他のすべてのステージはリポジトリ内のファイルで機能し、Anthropicはそれらが彼らのものであるClaude Codeであるため、それらについて具体的に述べることができます。コードが通信するサービス、データベース、キュー、メッセージブローカー、およびその他のすべてはあなたのものです。モデルベンダーはそれらがどのように見えるかを教えてくれないため、プレイブックはチェックを用意するように指示し、そこで止まります。 Anthropicのプレイブックの採用グラフ。矢印は最初にこれを採用することを意味し、最上段は前提条件なしで開始できる場所です。フィードバックループはその行にあります。 エージェントは実行中のシステムを一度も見たことがない 成果物チェーンが保持しているものを見てください：intent.md、spec.md、plan.md、CLAUDE.md、スキル、REVIEW.md。それぞれが人が決定し書き留めた何かを記録しています。 それらのどれも、エージェントが現在本番（またはステージング）で実行されているシステムを調べられるようにしません。アップストリームサービスが呼び出し時に返すもの、キューにあるもの、ステージングデータベースのスキーマが実際に今日どうなっているか（エージェントが作業しているブランチから数世代遅れている可能性があります）などです。CLAUDE.mdは、組織が決定したことをエージェントに伝えますが、実際に実行されていることは伝えていません。 mirrordの機能 mirrordは、エージェントのコードが偽物ではなく、ステージングクラスター内の実際のサービスに対して実行できるようにします。 コードはローカル、CIランナー、またはサンドボックスで引き続き実行されます。変更されるのはその周囲のすべてです。プロセスは、それが代行しているクラスターと同じ環境変数とシークレットを読み取り、アウトバウンドコールはクラスターのネットワークを経由して行われ、クラスター内のトラフィックはそれにルーティングできます。 私たちはこれを開発者向けに構築しました。彼らのほとんどは、デプロイと待機のサイクルを排除することでフィードバックループを短縮するためにこれを使用しています。開発者は偽物のセットがどれだけ古くなっているかを判断できますが、エージェントはできません。クラスター内のサービスに対してチェックを実行することは、誰もその判断をする必要がないことを意味します。 チェックの前にも役立ちます。同じ接続により、エージェントはAPIが実際に何を返すか、キュー上のメッセージが実際に何を含んでいるかを確認できます。ドキュメントから作業するのではなく。 1つのクラスターに対して複数のエージェントを実行する プレイブックは、複数のClaude Codeセッションを同時に実行することを提案しています。各セッションは独自のgit worktree内にあり、セッション内にサブエージェントがあります。 Worktreeはコードを分離します。それらは、セッションがチェックするクラスターについては何も行いません。5つのエージェントを同じステージングサービスに向けると、それらは互いに、そしてすでにそれを使用しているエンジニアと干渉します。これは通常、組織がエージェントと共有ステージングは一致しないと判断し、各エージェントに独自の（遅い、高価な、浅い）コピーを与えることに戻る場所です。 mirrordオペレーターがこれを解決します。トラフィックはヘッダーでフィルタリングされるため、各エージェントのセッションは独自の要求のみを受信し、キューは分割されるため、各セッションは共有トピックのプライベートスライスを取得し、データベースは分岐されるため、書き込みを行うセッションは他の誰にも影響を与えません。1つのステージングクラスターは、実行する必要のある多数のエージェントセッションを提供できます。 どこから始めるか プレイブックを採用している場合、最初に答える価値のある質問は、プレイブックが尋ねない質問です。エージェントのコードは、自己チェックを行う際に何に対して実行されるのでしょうか？ mirrordはオープンソースです。上記の同時セッションを処理するオペレーターは、当社の商用製品の一部です。ステージ4がクラスターに対して実行される様子を確認したい場合は、metalbear.com/mirrord/docsから始めてください。 mirrordとは何ですか？ mirrordは、開発者やAIコーディングエージェントがデプロイ前に本番環境のような環境でコードをテストできるKubernetes開発プラットフォームです。あなたのサービスは、ローカル、CI、またはエージェントのサンドボックスなど、作業している場所で実行されますが、mirrordはトラフィック、環境変数、およびファイルを共有ステージングクラスターにプロキシして、実際にデプロイすることなくデプロイされたかのように動作します。 monday.com、National Australia Bank、SurveyMonkeyなどの企業のエンジニアリングチームは、mirrordを使用して、開発環境インフラストラクチャのコストを削減しながら、より迅速にイテレーションおよび出荷しています。 この投稿を共有する