Why Now
生成AIによって、コードは「書く」ものから「生成される」ものに変わり、実装は誰でもできるようになりました。
しかし事業を動かすシステムに求められることは変わっていません。
不具合なく動くことだけでなく、使い続けていくシステムとして保守をどのように行うのか、人が変わってもシステムがあり続けられるのか、そして誰がなぜその時、その判断をしたのかを後から辿れるドキュメントなど、実はシステム開発は「プログラム実装」以外の多くのことが必要とされます。
それらはAIによる完全補完はまだ難しく、どうしても人の手を介入せざるを得ません。
Googleの DORA が2026年に出した報告はAI導入の投資対効果を左右するのはコードレビューだと結論づけています。実装を何倍速くしても、承認できる量が変わらなければ、出せる量は変わりません。増えるのは待ち行列だけです。
Google DORA "ROI of AI-assisted Software Development" (2026)
IPAの『DX動向2026』では国内企業のAI導入が大企業を中心に広がった一方で活用は業務効率化にとどまり、新しい価値の創出や事業への展開は限定的だと報告されています。入れたことと効いていることは別です。
いまはもはやAIを導入するかどうかの議論ではなく、速くなった実装工程にその上流と下流が追いつけていないという構造のズレにどう対処していくか、そこがAI駆動開発の難所です。
ECNでは、この難所をお客様と越えるお手伝いをしています。
Issues
AI駆動開発を進めていく上でよくある問題をまとめてみました。
01
DORAはAI導入後にレビュー待ちが膨らむ組織を多数観測しています。制約理論でいえば、ボトルネックが実装からレビューへ移っただけの状態です。
Faros AI が開発者22,000人の実データを見たところ、PRがレビューを待つ時間の中央値は441%増えていました。前年の同じ調査では91%増です。レビューを一度も通さずにマージされたPRも31%増えています。
実装を10倍速くしても、レビュアーが承認できる量が変わらなければ、全体で出せる量は変わりません。増えるのは滞留したPRとレビュアーの疲弊です。
Google DORA "ROI of AI-assisted Software Development" (2026)
02
Apiiroの観測ではAI生成コードに起因するセキュリティ指摘が2024年12月から2025年6月で10倍になりました。特権昇格の経路は322%増、設計上の欠陥は153%増。いずれもFortune 50規模の、専任のセキュリティ部門を持つ組織での数字です。
CodeRabbitが2025年12月に出した比較でも、AI共著のPRはセキュリティ指摘が2.74倍。シークレットの混入率は3.2%と人手だけのPR（1.5%）の2倍を超えています。
事故が起きたとき、何をどう説明するのか。ここを先に決めておく必要が出てきます。
03
2026年6月、Tenet Securityが「Agentjacking」という攻撃を報告しました。Sentryのようなエラー追跡サービスに悪意ある指示を紛れ込ませ、それをMCP経由で読んだAIコーディングエージェントを乗っ取るというものです。試験では85%が成功し、DSNが公開状態の組織が2,388件見つかっています。
この攻撃ではどの手順も単体では不正ではありません。開発者がエラーの修正を頼み、エージェントがMCPで問い合わせ、返ってきた内容に従う。不正な操作を検知する仕組みではそもそも引っかかりません。
AIが薦めるパッケージ名の一部は実在しないものです。攻撃者がその名前を先回りして登録する Slopsquatting も現実の脅威になっています。従来のSASTと依存関係スキャンだけではこの面は守れません。
04
McKinseyの調査では単純な作業でのAIの時間短縮は46%、複雑な作業では10%未満にとどまりました。効き方を決めているのは要件の解像度です。
AIが入っているのは実装工程まで、というケースが多くあります。どの機能をなぜ作るか、KPIに何で効くのか。上流の判断は今までどおりのままです。
McKinsey「Unleashing developer productivity with generative AI」
05
速く作った結果、全体像を誰も把握していないコードベースが残ることがあります。設計判断の来歴がどこにも残らないためです。
半年後の障害対応でなぜこの実装なのかを誰も説明できない。これは監査にも保守にも引き継ぎにも効いてきます。
期限も決まっています。EU AI Act の高リスク用途の義務は2026年7月に発効した Digital Omnibus によって2027年12月からになりました。求められているのはまさにこの「なぜこの判断をしたのか」を後から示せることです。
Reality
生成AIが安くしたのは動くものを作るコストです。動き続けるものを作るコストは下がっていません。
01
「今月の売上」が何を指すかは社内で一つに決まっていません。返品を引くのか。社内取引を含むのか。締めはいつか。部署ごとに答えが違います。
これまではその定義をBIツールの中に少しずつ貯めてきました。AIに生のテーブルを渡して質問すると、その資産を通らずに毎回その場で定義が作り直されます。同じ質問をした二人に違う数字が返ります。
結合を一つ間違えて売上が二重に数えられていても、画面にはもっともらしい数字が出ます。エラーにもなりません。文章の嘘は読めば気づきますが、数字の嘘は気づけません。
02
現場が自分でアプリを作れるようになると、次に要るのはそれを基幹システムにつなぐ口です。作った人の数だけ必要になります。
どのデータを渡すか。どこまで書き込ませるか。権限をどう切るか。一本ごとに判断が要ります。この判断は現場だけでは決めきれません。
結果として、作る仕事は分散し、つなぐ仕事は一箇所に集まります。作る人が増えるほどそこが細くなります。
03
試しに作ったものが便利だと、現場で使われ始めます。使われ始めたら、止める判断をする人はいません。
作った本人が異動しても、そのアプリは動き続けます。誰が直すのかは決まっていません。仕様も、その人の頭の中にしかありません。
システムの価値は動いた瞬間ではなく、動き続けた年数で決まります。ECNが請け負っているのはこの「作れたあと」を含めた範囲です。
今はAIに頼めばパッと見それなりのものが出てくるので、ある程度はそれでも良いと思います。
ただ、AIで作ったものって全部“AI臭く”、見る人が見るとすぐに分かってしまいますよね。
調査によると、コンテンツがAIによって生成されたものと分かると52％の人が興味を失うようです。
現代においてもはやAIを使わずに仕事をするということは考えられませんが、AIを使って“AI臭くない”成果物を作るのには、やはり工夫や手間が必要になります。
我々は、AI臭さをできる限り取り除きつつ、AIによる開発の効率化・時短・費用削減をはかっています。
出典：Bynder「AI vs human-made content study」（2024年4月・米英2,000人）
AIは常時平均点を取るのが仕事なので、その時求められる100点に近い成果をあげるためには、やはり人間の確認と調整が必要になります。
Approach
多くの支援会社は要件定義まで、PoCまで、実装まで、と工程で線を引きます。AI駆動開発ではその線がそのままセキュリティの穴と運用できない原因になります。
仕様の変更がその場でテストと脅威モデルの更新に伝わる。本番の運用ログがその場で次の仕様に反映される。この閉じたループを設計できるかどうかで事業の成果が変わります。
ECNの伴走は次の5つの工程を一つの契約の中でカバーします。
| 工程 | 担うこと | AIの役割 | 人の役割 |
|---|---|---|---|
| Discover見つける | 事業KPIから逆算して要件を出す | 業界事例と仕様案を網羅して出す | 事業判断と優先順位づけ |
| Specify決める | 実行できる仕様を確定させる | 仕様案の生成と矛盾の検出 | 受入基準の確定と合意形成 |
| Implement作る | 生成、レビュー、マージ | 実装、単体テスト、PRの作成 | 設計判断とレビュー |
| Secure守る | 多層の防御を通す | 脆弱性の検査、依存部品の検査、認証情報の走査、部品一覧の作成 | セキュリティ境界の設計 |
| Operate動かし続ける | 運用と改善のループ | 異常の検知と改善案の生成 | 変更の判断と監査対応 |
Methodology
思想の話ではなく、実装できる方法として置きます。現場で効くと確認できたものだけです。
01
プロンプト中心で進めると、仕様の正本がどこにも無くなります。コードとテストとドキュメントがそれぞれ別の時点のプロンプトの残りとして食い違っていきます。
Microsoftが提唱している Spec-Driven Development もこの問題への回答です。GitHubが公開した Spec Kit は要件を計画・実装タスク・検証手順へ落とす流れをCopilot や Claude Code の上で回せるようにしたものです。
ECNは仕様を先に確定させ、そこからテストと実装を導きます。仕様が変われば、テストと実装とレビュー観点が同時に変わります。日本の商習慣に合わせて、受入基準の合意を仕様の確定と同じ工程に置きます。
工程は Constitution（原則）、Specify（仕様化）、Clarify（明確化）、Plan（計画）、Tasks（タスク分解）、Implement（実装）、Validate（検証）の順に進みます。受入基準は EARS 記法で書き、要件がそのままテストに変換される状態にします。
02
Palo Alto Networks の Unit 42 が2026年1月に公表した SHIELD を組織のポリシーに落とします。
AIが生成した差分にはPRで印を付け、レビューの観点を人のコードと切り替えます。認証・認可・暗号・課金といったセキュリティ境界に触れる差分はAIの一次レビューを通ったあとに人の承認を通します。
03
Claude Code、Codex、Cursor といったエージェント型のツールはMCPを介して外部の資源に触ります。2026年の時点でここがいちばん監視の薄い面です。
意識の問題ではなく、手順として組み込むものです。
04
実装は速くなったのに納期が縮まらない。この処方は人を増やすことではありません。制約理論の順で工程を組み替えます。
5から始めると費用だけが増えます。ECNは1から4で改善の余地を回収してから5に進みます。
05
事業システムにはなぜこの実装なのかを後から追える義務があります。改正個人情報保護法、PCI DSS、GDPR、そしてEU AI Act。いずれも根拠を辿れることを求めています。EU AI Act の高リスク用途の義務は2026年7月に発効した Digital Omnibus によって、単独のシステムが2027年12月から、規制対象の製品に組み込まれるものが2028年8月からに後ろ倒しになりました。
作ったあとに書く文書ではありません。生成と同時に残る記録として、パイプラインに組み込みます。
Features
01
要件定義までPoCまで実装まで。工程で線を引けば、線のところで文脈が落ちます。AI駆動開発ではその落ちた文脈がそのままセキュリティの穴になります。
ECNは Discover から Operate までを同じチーム、同じチケット、同じ仕様の上で進めます。要件の変更がテストと脅威モデルと運用手順に伝わり、本番のログが次の仕様に返る。この閉じたループの設計そのものをサービスの中心に置いています。
02
AI案件でいちばん重要な判断は何をAIに任せないかを決めることです。エージェントを増やせば、費用と攻撃面だけが増えます。
ECNは大規模なシステムを動かし続けるところまで請け負ってきました。どこが壊れると事業が止まるかを運用の側から知っています。その上でAIで速くなる工程とAIに触らせない工程を先に切り分けます。
03
AI駆動開発のセキュリティはリリース直前の脆弱性診断では守れません。設計、生成、レビュー、依存関係、運用のすべての層に防御を織り込む必要があります。
ECNはSAST、SCA、SBOM、シークレット走査、MCPのゼロトラスト運用、生成の記録を後から足す項目ではなく、最初の見積もりに含めた形でお出しします。
FAQ
ツールの導入は、実装工程の一部が速くなるところまでです。ECNのAI駆動開発は、要件、実装、セキュリティ、運用を一つのループとして組み直すものです。ツールはその中で使う手段の一つに過ぎず、入れ替わることを前提にしています。
コードが本体に取り込まれる前に、認証情報の混入、脆弱性、使っている外部部品の既知の問題を自動で検査します。外部部品の一覧も成果物として残します。そのうえでAIによる一次レビューと人によるレビューを重ね、認証・認可・暗号処理に触れる部分は人の承認なしに取り込まれない形にしています。
成果物の権利が御社に帰属することと、第三者の知的財産の扱いは契約書に明記します。使用する外部部品のライセンスは、コードを取り込む前に自動で確認しています。
EU域内の利用者に関わる場合は必要になります。高リスクに当たる用途の義務は2027年12月からです。対応が要る案件では、どの判断をどの根拠で行ったかを後から示せる形にすることを、最初の要件に含めて設計します。
ソースコードに加えて、設計の記録、テストの仕様、インフラの構成、運用の手順、そしてAIが生成した部分の来歴を残す形で進めます。特定のベンダーに依存しない状態を保つことを前提としており、引き継ぎのための資料づくりと説明も行います。将来的に内製へ移していく場合もご相談ください。
可能です。まず現状をうかがったうえで、課題の整理と、AI駆動開発を当てられるかどうかについて意見をお出しします。
