株式会社ずんだもん技術室AI放送局 podcast 20260224
内容紹介
Agentic Software Engineering - The Future of Code、SaaSは死なない、ただし「人間がUIを触る前提の設計」は終わる──AIエージェント時代のSaaS再設計論、Red/green TDD - Agentic Engineering Patterns
出演者
youtube版(スライド付き)
関連リンク
本ドキュメントは、AIエージェントがソフトウェア開発のプロセスに深く組み込まれる「エージェンティック（自律的）・ソフトウェア・エンジニアリング」という新たな時代の到来と、その中でのエンジニアの在り方を定義したガイドです。AIがコードを書くことが当たり前になる未来において、私たちがどのように思考をアップデートすべきかを説いています。
■ 開発における「ボトルネック」の変化 これまでのソフトウェア開発では、仕様をコードに落とし込む「実装スピード」や「技術的なコーディング力」が重視されてきました。しかし、生成AIの台頭により、コードの生産自体はもはや開発の停滞要因（ボトルネック）ではなくなっています。現代の真の課題は、システムの肥大化に伴う「複雑性の管理」、開発者間の「コミュニケーション」、そして長期にわたってシステムの整合性をどう「維持」し続けるかという点にシフトしています。
■ 新しい規律：Agentic Software Engineeringの定義 「Agentic Software Engineering」とは、人間だけでなく、確率的な振る舞い（Stochastic）をするAIエージェントが開発に関与することを前提とした、新しいエンジニアリングの規律です。AIは常に100%同じ結果を出すわけではない不確実性を伴う存在です。そのようなAIを開発プロセスに組み込みながら、いかにしてシステム全体の「信頼性」と「信頼（Trust）」を担保するかという手法や規律を扱うのがこの分野の核心です。
■ これからのエンジニアに求められる役割 これからの時代、成功を収めるのは「単にコードを速く書ける人」ではありません。AIという自律的なエージェントを指揮する側に回り、以下の役割を果たせるエンジニアやチームが真の価値を持ちます。
- 明確な意図（Intent）の設定：AIに対して、何を作るべきかという目的と設計思想を正確に定義し、伝える能力。
- リスク境界の管理：AIが自律的に動く範囲を適切に定め、予期せぬ挙動によるリスクをコントロールする能力。
- 証拠（Evidence）の要求：AIの成果物を鵜呑みにせず、それが仕様通りに動作しているか、セキュリティ上の問題がないかといった「証拠」を厳格に検証する姿勢。
■ 新人エンジニアへのアドバイス 新人エンジニアの皆さんにとって、AIは非常に心強い味方です。しかし、AIに実装を任せられるようになるからこそ、「どうすればこのシステムが安全で信頼できるものになるか」という、より高い視点での「設計力」と「検証力」を磨くことが重要になります。
これからは「コードをどう書くか」というHowのスキルに加え、「何のためにどう設計し、どう正しさを証明するか」というエンジニアリングの本質的な力がより一層求められるようになります。AIというパートナーと共に、より大規模で高度なシステムを構築できる未来を楽しみに、この新しいエンジニアリングの形を学んでいきましょう。
引用元: https://agenticse-book.github.io/
2026年、AIエージェントの普及に伴い「SaaSは死んだ」という議論がなされていますが、本質的には「人間がUIを操作することを前提としたSaaS設計」が終焉を迎え、AIエージェントが利用することを前提とした「業務エンジン」へと進化していくフェーズにあります。本記事では、AIエージェント時代に生き残るSaaSの条件と、エンジニアが意識すべき新しい設計原則を解説しています。
1. 「UIファースト」から「APIファースト」への転換
これまでのSaaSは、人間が使いやすいUI/UXを提供し、作業効率を上げることが価値でした。しかし、AIエージェントがユーザーとなる時代では、SaaSは「APIを通じて操作されるデータ処理エンジン」へと変わります。画面の見やすさよりも、APIの表現力、データの一貫性、イベント連携（Webhook）の充実が重要視されます。
2. エージェント時代の4つの設計原則
AIエージェントとの統合を前提としたシステムには、以下の技術的要件が求められます。
- Agent-Facing API: エージェントは「1つのAPI呼び出しで1つの業務を完結」させることを好みます。そのため、高粒度なAPI設計が必要です。
- 冪等性（Idempotency）の担保: エージェントはネットワークエラー等に対し自動リトライを行います。二重決済などの不具合を防ぐため、
Idempotency-Key（冪等キー）を用いた設計は「必須要件」となります。 - 非同期ワークフロー: 長時間の処理を伴うタスクに対し、202 Acceptedを返し、ジョブIDで進捗を追跡できる仕組みが必要です。ポーリングよりもWebhookによる通知が推奨されます。
- 可観測性（Observability）: 「なぜエージェントがその操作を行ったのか」を後から追跡できるよう、実行全体を紐付けるTraceIDや詳細な監査ログの設計が不可欠です。
3. ビジネスモデルと選定基準の変化
従来の「ユーザー数（ID数）課金」は、エージェントが1人で10人分の仕事をこなすようになると機能しません。今後は、API呼び出し数や処理レコード数に応じた「従量課金（Usageベース）」への移行が加速します。
エンジニアがSaaSを選定する際は、UIの良し悪しだけでなく、OpenAPI仕様の公開状況、認証方式（OAuth 2.0等）、レート制限情報の透明性などをチェックリストとして評価する必要があります。
まとめ：新人エンジニアへのメッセージ
これからのSaaS開発や導入において、エンジニアに求められるのは「UIという皮」を剥ぎ取った先にある、純粋な「業務ロジックの提供能力」を設計することです。SaaSを単なる便利なツールとしてではなく、AIエージェントが自在に操れる「強力なエンジン」として再定義し、構築していく視点が、これからのキャリアにおいて大きな武器となります。
引用元: https://qiita.com/nogataka/items/e04d1f6f417eec2bab54
AIエージェントにコーディングを依頼する際、非常にシンプルかつ強力な成果を引き出す指示が「Red/green TDD（テスト駆動開発）を使用して」という一言です。Simon Willison氏が提唱する「Agentic Engineering Patterns（エージェント開発パターン）」の一つである本記事は、AI時代におけるエンジニアの新しい「武器」としてのTDDを解説しています。
1. AI時代に再注目される「TDD」とは
TDD（Test Driven Development）は、プログラムの実装前にテストコードを書き、そのテストをパスさせるように実装を進める手法です。特に「Red/green」という言葉は以下のサイクルを指します。
- Red: まずテストを書き、実行して失敗することを確認する。
- Green: テストをパスするように最小限の実装を行い、成功を確認する。
2. なぜAIエージェントにTDDが効くのか
AIエージェントは非常に高速にコードを書きますが、「動かないコードを出力する」「不要な機能まで作り込んでしまう」といったリスクがあります。この問題を解決するのがTDDです。
- 確実な検証: テストを先に書かせることで、AI自身が「自分の書いたコードが正しいか」を客観的に判断できるようになります。
- 資産としてのテスト: AIが生成したテストスイートは、将来の変更で既存機能が壊れていないかを確認する「防護柵」として機能し続けます。
- 指示の簡略化: 「テストを先に書き、失敗を確認してから実装してほしい」という長い説明をせずとも、現代の高度なLLM（ClaudeやChatGPTなど）は「Red/green TDD」という用語だけでそのプロセスを理解します。
3. 新人エンジニアが意識すべきポイント
AIを「魔法の杖」として使うのではなく、エンジニアとして「開発の品質をコントロールする」という意識が重要です。AIに丸投げするのではなく、Red（失敗）を確認してからGreen（成功）へ進むという「型」を指示することで、ハルシネーション（もっともらしい嘘）を防ぎ、信頼性の高いシステムを構築できます。
結論
「コードを書くコスト」がAIによって劇的に下がった今、エンジニアに求められるのは「正しいコードであることを証明する力」です。古典的な知恵であるTDDは、AIエージェントという最新のツールを使いこなすための、最も現代的なプラクティスとなります。プロンプトに「Use red/green TDD」と添えるだけで、AIとの共同作業の質は劇的に向上するでしょう。
引用元: https://simonwillison.net/guides/agentic-engineering-patterns/red-green-tdd/
（株式会社ずんだもんは架空の登場組織です）