@optimisuke(Naosuke Ito)Team Tea & Waterin

AIエージェントは開発組織をどう変えるのか、調査結果から整理した

Posted at 2026-06-16

はじめに

Claude Code、Codex、Devin などの AI コーディングエージェントを使う組織が増えてきていると思います。実装、調査、テスト追加、レビュー観点の洗い出しなど、すでに開発の進め方はかなり変わっています。

一方で、「AI があるから開発組織は小さくなる」「エンジニアは不要になる」といった単純な話には見えません。実装が速くなるほど、何を作るべきか、どう検証するか、誰が責任を持つかと考えることが増えているようにも見えます。

自分のキャリアを考える上でも、あるべき開発組織を考える上でも、AIエージェントが開発組織をどう変えるのかがかなり重要だと思ったので、公開されている調査や事例をもとに整理しました。

先に結論

調査や各社事例を並べると、見えてくる方向性はかなり一貫しています。

AI は開発組織を置き換えるというより、既存の強みと弱みを増幅する。

DORA 2025 も、AI の主な役割を「amplifier」と表現しています。つまり、テスト、レビュー、要求管理、設計判断、組織知の管理が整っているチームでは効果が出やすく、逆にそこが弱いチームでは混乱も大きくなります。

この記事で整理するポイントは次の3つです。

開発の重心は「実装」から「意図・検証・統率」へ寄る
アジャイル、テスト、自動化された品質ゲートの重要性は下がらない
個人のキャリアでは、コードを書く力に加えて、任せ方と確かめ方を設計する力が重要になる

1. AI の採用は進んだが、信頼は追いついていない

DORA 2025 は、2025年版のテーマを AI-assisted Software Development として扱っています。同レポートは、AI が組織の強みと弱みを増幅すること、AI 投資のリターンはツール単体ではなく組織システムへの投資から生まれることを強調しています。

元メモで参照した DORA 2025 の要点は次の通りです。

AI ツールの採用率は開発者の約90%
80%超が生産性向上を実感
一方で、約30%は生成コードをほとんど、または全く信用していない

ここから読み取れるのは、「使われている」と「信頼されている」は別だということです。AI コーディングは普及しましたが、生成物をどう検証するかはまだ成熟途上です。

このギャップは、開発組織にとってかなり重要です。2025年時点では、AI がコードを書く量を増やすほど、レビュー、テスト、セキュリティ確認、運用観点の確認が詰まりやすくなります。2026年現在また少し状況は変わっていると思いますが。

2. 実装よりも、意図と検証の価値が上がる

AI エージェントは、一定の実装作業を速くします。結果として、「コードを書くこと」だけの希少性は下がっていきます。

ただし、これはエンジニアの価値が下がるという意味ではありません。価値の中心が、実装そのものから実装の前後へ移るという話です。

重要になるのは、たとえば次のような仕事です。

何を作るべきかを定義する
要求、制約、非機能要件を明文化する
AI に任せるタスクの粒度を切る
出力が正しいかを検証する
設計判断とトレーサビリティを残す
複数の人間とエージェントの作業を統率する

生成 AI によって多くのソフトウェアエンジニアが役割適応を求められると色々な文献に記載があります。方向性としては、実装中心から、問題解決、設計、オーケストレーションへ寄っていく見立てです。

この変化は、開発者だけでなく、プロダクトオーナー、アーキテクト、テスター、スクラムマスターにも影響します。

役割	変化しそうな重心
プロダクトオーナー	要求の管理から、意図と価値の設計へ
アーキテクト	構造設計から、制約と検証基準の設計へ
開発者	実装者から、AI の統率・検証者へ
テスター	品質確認から、検証戦略の設計へ
スクラムマスター	人間のフロー支援から、人間とエージェントのフロー設計へ

3. AI 時代でもアジャイルとテストは弱くならない

AI が開発を速くするなら、アジャイルやテストの規律は不要になるのか。調査や専門家の見解を見る限り、むしろ逆です。

Thoughtworks Technology Radar Vol.33 は、AI の成功には文脈、インフラ、セキュリティを真剣に考える必要があり、AI 関連のアンチパターンとして shadow IT や生成コードへの過信を挙げています。

Kent Beck 氏へのインタビューでも、TDD は AI と働くときに重要だと語られています。AI はそれらしいコードを速く出せますが、正しさを保証するわけではありません。

そのため、AI を使うほど次の土台が重要になります。

自動テスト
CI による品質ゲート
コードレビュー
要求と実装とテストの対応関係
失敗したときに戻せるバージョン管理

AI が間違えること自体は避けられません。問題は、間違いを早く検出できる仕組みがあるかどうかです。

4. マルチエージェントは有望だが、適用範囲を選ぶ

Anthropic の multi-agent research system の記事では、複数エージェント構成が単一エージェントより良い成果を出したと報告されています。社内評価では、Claude Opus 4 をリードエージェント、Claude Sonnet 4 をサブエージェントにした構成が、単一エージェントを 90.2% 上回ったとされています。

ただし、同じ記事は制約も明確に書いています。

通常のチャットに比べ、エージェントは約4倍、マルチエージェントは約15倍のトークンを使う
並列化しやすい調査タスクには向く
多くのコーディングタスクのように依存関係が強い作業には、現時点では向きにくい

つまり、マルチエージェントは万能な開発体制ではありません。価値が高く、並列化でき、評価しやすいタスクで効果が出やすいと見るのが現実的です。

5. 規制産業では説明責任が残る

自動車、航空、医療のような領域では、要求から設計、コード、テストまでのトレーサビリティが重要になります。AI は要求抽出、テスト生成、トレース作成を支援できますが、認証や説明責任そのものは組織から消えません。

CoLab の AI for MBSE の記事でも、MBSE や設計検証に AI エージェントを使う方向性が紹介されています。

この観点では、MBSE、Digital Thread、ALM/ELM のような基盤は、単なる管理ツールではなくなります。人間と AI エージェントが共有する「組織の記憶」として重要性が上がる可能性があります。

6. 組織として先に整えるべきもの

調査結果を踏まえると、AI エージェント導入で先に見るべきなのは、ツール選定よりも土台です。

共有知識を AI が読める形にする

設計指針、用語集、レビュー観点、セキュリティ基準、運用制約、過去の判断理由が人の頭の中や流れたチャットにしかないと、AI は組織の文脈を理解できません。

リポジトリ上のドキュメント、CLAUDE.md のようなエージェント向け文脈、ADR、運用 Runbook などを整えることは、AI 活用の前提になっていきます。

完了条件を自動化する

AI の出力をすべて人間が手で確認するのは限界があります。テスト、lint、型チェック、セキュリティスキャン、依存関係チェックなど、機械で確認できるものは CI に寄せる必要があります。

人間のレビューをなくすのではなく、人間が見るべき判断に集中できる状態を作る、ということです。

小さく任せられるタスクを増やす

AI に向いているのは、要求が明確で、成果物を検証しやすいタスクです。移行作業、脆弱性修正、テスト生成、定型実装、ドキュメント更新などは始めやすい領域です。

逆に、コアのビジネスロジックや、複数部署をまたぐ判断が必要な変更は、人間の同期的な監督がまだ必要です。

7. 個人のキャリアへの示唆

個人としては、コードを書く力が不要になるわけではありません。AI の出力を判断するには、実装を理解している必要があります。

ただし、それに加えて重要になるスキルは変わります。

意図を言語化する力
検証方法を設計する力
システム全体を読み、トレードオフを判断する力
AI に任せる粒度を切る力
チームの開発フローに AI を組み込む力

特に重要なのは、「AI に何を頼むか」よりも「何が返ってきたら受け入れてよいか」を定義する力だと思います。

おわりに

AI エージェントが当たり前になると、開発組織は「人間が全部実装する組織」から、「人間が意図、制約、検証、責任を持ち、AI エージェントを使って実装を進める組織」へ寄っていきます。

調査結果を見る限り、AI は開発組織を単純に置き換えるものではありません。既存の開発規律、テスト、レビュー、要求管理、組織知を増幅するものです。

だからこそ、個人としては任せ方と確かめ方を磨くこと、組織としては AI に任せても壊れにくい土台を作ることが重要になりそうです。

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up