---
title: "エージェント型開発：コード生成から「選択と検証」へ注力シフトする時
"
description: "エージェントはアイデアをほぼ瞬時にプルリクエストへ変換できます。現在難しいのは、何を構築するかを決定し、生成されたコードが安全にリリースできるか検証することです。本記事では両者に対するリスクベースのアプローチを紹介します。

"
authors:
  - name: "Riccardo Cocetta"
    url: "https://auth0.com/blog/authors/riccardo-cocetta/"
date: "Nov 6, 2026"
category: "Engineering"
tags: ["ai", "engineering"]
url: "https://auth0.com/blog/jp-agentic-development-time-to-shift-focus/"
---

# エージェント型開発：コード生成から「選択と検証」へ注力シフトする時


>本記事は「[Agentic Coding is a solved problem, we need to focus on something else now.](https://auth0.com/blog/agentic-development-time-to-shift-focus/)」を翻訳した記事です。


<style>
  
/* Style a table. Add borders, center table, and reduce font size. */
 table {
   width: 90%;
   margin: 2.4rem auto !important;
   border-collapse: collapse;
   font-size: .9em;
 }
 table, td, th {
   border: 1px solid;
 }
 table th {
   line-height: normal;
   padding: .8em;
 }
 td {
   padding: .8em;
   line-height: normal;
 }

</style>
*TL;DR: アイデアからプルリクエストを作成することは今日ではよく理解されている問題であり、実現するためのツールや手段は豊富にあります。今後のソフトウェア開発で本当に違いを生むのは、何を構築するかを定義し、構築後に顧客が期待する品質とサービスのレベルを提供できるか検証することです。*

今日でも要件からコードを生成するシステムに注力している多くのプロジェクトや製品、スタートアップを目にします。素晴らしい試みですが、非常に2025年的です。今日では解決済みの問題であり、少なくとも自己解決しつつあります。実現方法はすでにわかっています。

アイデアからプルリクエストを作成するソフトウェアを構築しても、現時点では新しい問題を解決していません。市場はまだ存在するかもしれませんが、知的領域はコモディティ化しています。


## AIベースのソフトウェア開発の最新状況

本記事の目的のため、スペクトルを2つの極端な例に単純化します。 

今日、AIベースの開発方法には2つの大きなトレンドが見られます。バイブコーディングと、人間が監督するエージェント開発と呼ぶより構造化されたアプローチです(完全なエージェント開発の実験もありますが、ここでは議論しません)。


### バイブコーディングとは何か
 
前者のバイブコーディングは、AIに雰囲気を伝えて何が起こるかを見る手法です。製品が何をすべきか考え、記述し、満足するまで反復を続けます。バイブコーディングはエンジニアリングではありませんが、プロトタイプやPOC、MVPには最適であり、率直に言って非常に楽しいものです。しかし明らかに、成熟した製品向けのアプローチではありません。

### 人間が監督するエージェント開発とは何か

人間が監督するエージェント開発では、より構造化されたアプローチを使用します。

* 計画する
* 何を構築するかをより明確に定義する(仕様駆動開発を用いる場合もある)
* 結果を比較するための参照テストも提供する

これによりはるかに予測可能な結果が得られ、適切なエンジニアリングにずっと近づきます。エージェントの処理が完了すると、好みに応じて非常に詳細で整ったプルリクエストや、より簡潔なプルリクエストを作成できます。

すべて魔法のようですが、数百万から数十億のユーザーと数百の機能やサービスがあると仮定します。製品に多額の資金がかかっている場合、エージェントに自律的なマージとリリースを許可するでしょうか。

許可しない場合、なぜでしょうか。何が問題なのでしょうか。

## 高速化に伴う問題

超光速(FTL)エンジンを構築しているにもかかわらず、宇宙船に搭載して宇宙の反対側へ連れて行ってもらうのは恐ろしいことです。なぜでしょうか。

まず第一に、宇宙船がその速度に耐えられるかわからず、テストできる必要があります。耐えられる以上の速度を出して宇宙船を壊していないか検証する必要があります。すべてのシステムが機能し続ける必要があります。

また、FTLエンジンを起動するなら、宇宙船を正しい方向に向ける必要があります。そうしなければすぐに何かに衝突し、高い確率で負傷します。

[エージェント開発](https://auth0.com/blog/part-of-software-engineering-ai-cannot-replace/#The-Engineer-as-Auditor)の用語に翻訳すると、最初の問題は何を構築するか決定することであり、2つ目は生成されたコードの検証です。

## 顧客価値への注力、すなわち何を構築するかの選択

無限の速度でリソースの制限なく、好きなものを構築できる能力があると仮定します。何を構築するでしょうか。
 
思いついたものをすべて構築するのは、実際の製品にとって良いアイデアではないかもしれません。誰も[The Homer car](https://simpsons.fandom.com/wiki/The_Homer)を買いたがりません。
  
1000個の機能を投入してA/Bテストし、牽引力のない機能を廃止できます。しかし顧客体験に膨大な解約を生み出し、チームがサポートすべき製品の表面積を大幅に増やしてしまいます。

### 何を構築するかをどのように選択するか

正直なところ、優先順位付けの多くの方法は変わりません。リソースの制限はなくなりましたが、顧客とビジネスにとって何が最善かを考える必要があります。

そこで4つのアイデアを紹介します。

1. **顧客に価値を追加するか** 決して変わらない点であり、顧客は最も重要な焦点です。ノイズや複雑さに対して顧客価値の比率が高い機能のみを追加すべきです。
2. **目的は明確か** どのような問題を解決しているでしょうか。製品のコンテキストにおいて、機能が解決する問題を明確に説明できる必要があります。
3. **機能は製品に適合しているか** 機能は製品の物語に適合しているでしょうか。すでに構築したものの自然な拡張でしょうか。それともニュースサイトのチャットボットのように違和感があるでしょうか。すべてをこなす製品を構築することが勝利の戦略だと考えがちですが、実際には顧客のメンタルマップと市場開拓戦略の両方にノイズを引き起こします。
4. **財務戦略と一致しているか** 製品の表面積を追加していますが、顧客が対価を支払う表面積でしょうか。あるいは何らかの形でより多くの収益をもたらすでしょうか。もしそうなら、利益率と両立する方法で実現できるでしょうか。

## 検証の課題

何を構築するか決定し、エージェントに瞬時でコーディングさせ、プルリクエストを作成させると想像してみます。

プルリクエストをマージし、安全に本番環境へリリースできると[どのように判断するのでしょうか](https://auth0.com/blog/ai-agents-have-two-souls-you-control-only-one/)。


## 安全にとはどういう意味か

まず「安全に」の意味は製品やコンポーネントによって異なります。最終的に「安全に」とは、設計原則との整合性を維持することだと言えます。

整合性を保ちたいと考える外部の側面をいくつか挙げます。

- **機能性** すべてがまだ正常に機能しているか
- **パフォーマンス** パフォーマンスの低下を引き起こしていないか
- **セキュリティ** 新しい脆弱性を導入していないか
- **回復力** 以前と同じように障害に対する回復力があるか
- **コンプライアンス** すべての規制やポリシーの要件(プライバシー、規制管理、監査要件など)をまだ満たしているか
- **内部品質** 良いコード(保守可能、読みやすいなど)か
 
複雑さや保守性など、コードのすべての内部品質を忘れてはいけません。

では、自動化されたソフトウェア構築マシンの出力を検証する問題にどのように取り組むのでしょうか。


## 利用可能なツール

ありがたいことに、基礎的なエンジニアリング作業は明確で決定論的な手法として依然として役立ちます。さらにLLMの強みのおかげで、新しい手法も用意されています。

本記事の目的は検証に関する論文ではないため、本記事ではツールとカバーする側面の表を提示するにとどめます。手法の詳細については読者の調査に委ねます。

| ツール/手法 | 機能性 | パフォーマンス | 回復力 | セキュリティ | コンプライアンス | 内部品質 |
| :---- | :---: | :---: | :---: | :---: | :---: | :---: |
| ユニット/統合/機能テスト | **✓** |  |  |  |  |  |
| パフォーマンスとカオステスト |  | **✓** | **✓** |  |  |  |
| 契約テスト | **✓** |  | **✓** |  |  |  |
| AIランタイム生成テスト | **✓** |  | **✓** | **✓** |  |  |
| DAST*(動的セキュリティテスト)* |  |  |  | **✓** |  |  |
| SAST*(静的セキュリティ分析)* |  |  |  | **✓** |  | **✓** |
| 依存関係とシークレットのスキャン*(SCA)* |  |  |  | **✓** | **✓** |  |
| コード品質分析*(リンティング、複雑さ、コードの匂い)* |  |  |  |  | **✓** | **✓** |
| アクセシビリティとコンプライアンスのスキャン |  |  |  |  | **✓** |  |
| LLMベースのコードレビュー*(レビューのためのアンサンブル)* | **✓** | **✓** | **✓** | **✓** | **✓** | **✓** |
| 段階的なロールアウト | **✓** | **✓** | **✓** |  |  |  |
| 形式手法 | **✓** |  |  |  |  | **✓** |


## ソフトウェア検証へのリスクベースのアプローチ

利用可能なすべてのツールは、生成されたコードに対する大きな自信を構築するのに役立ちます。自動マージにつながるでしょうか。検証のための完全なパイプラインを持つことは高価ではないでしょうか。
 
ソフトウェアのどの部分について話しているかによります。

一部の領域では、間違いを犯すことが大きな影響を与える可能性があります。例えばコードの高度にセキュアな部分や、データに修復不可能な損害を与える可能性のある部分です。ドキュメントサイトではおそらく影響は少ないでしょう。SDKやUI、Quickstartはどうでしょうか。デモアプリケーションはどうでしょうか。

ソフトウェアの価値がどこから来るかに応じて、コードの異なる部分に対して異なるレベルのリスクが存在する可能性があります。異なるレベルの検証を適用したいと考えるかもしれません。

深いレベルの検証は高価であり、最もリスクが高い場所で使用すべきです。おそらく人間がマージするのを待つべきです。しかしリスクが低い場所では少し手を抜き、エージェントの自動マージするところまで進められます。


# 焦点を移す時期

本記事全体の要点は何でしょうか。焦点を移す時期だということです。

エージェントベースの開発の中間部分はコモディティ化しています。明確に定義されたアイデアから自動的にPRへ移行する方法はよく理解されています。チームに惰性で実行と解決を続けさせるか(内部で解決する場合)、市場にある多くの利用可能な製品のいずれかを購入すべきです。

これからの時代に本当に違いを生むのは、何を提供するかを非常に明確に定義し、適切な検証フレームワークによって安全な高速化を達成することです。何を構築するかを定義し、構築すべきでないものにノーと言い、検証と確認のパイプラインが製品と顧客の期待する品質を保証できるようにすることに努力を注ぐ必要があります。以上が解決すべき新しい困難な問題です。