要件定義から検証までAIが担うパイプライン
NECソリューションイノベータの伊達拓郎氏は、2004年の入社以来、メインフレームからのマイグレーション案件をはじめ、Webアプリケーション開発、新サービス企画、地域DX推進など、多岐にわたるシステム開発の最前線を歩んできた。現在はAIネイティブな開発プロセスの検証と適用推進を担い、現場でAI駆動開発パイプラインの構築と運用を指揮している。
伊達氏のチームが取り組んだのは、要件定義から設計、実装、単体テスト、さらにはE2Eテストに至るまで、開発プロセスの全行程をAIが主導する一気通貫の自動化パイプラインの実現だ。
パイプラインは、GitHub ActionsとClaude Codeを統合して構築された。具体的なワークフローとしては、まずシステムエンジニアが顧客からの提案依頼書や要件一覧をリポジトリにプルリクエストとして投入する。すると、パイプライン上のAIエージェントが即座に起動し、「要件解析」スキルを実行して要件定義書を自動生成する。続いて設計・実装を進めてソースコードを生成し、単体テストフェーズでは静的解析、ビルド、単体テスト、脆弱性監査までを自動で実行する。さらにWebブラウザの操作を自動化するテストフレームワーク「Playwright」を用いてE2Eテストを実施し、正常動作のエビデンスとして画面のハードコピーを取得・返却する仕組みだ。そして、すべての品質チェックをクリアすることで、評価環境へ自動デプロイされる。
AIが成果を生むほど見えてきた3つの違和感
要件定義からデプロイまで、AIが高速に成果物を生み出し続けるこのパイプラインは、技術的にもプロセス的にも完璧に見えた。結果的に、開発スピードは従来と比べて飛躍的に向上し、数値上の生産性指標も大幅な改善を示していた。
しかし、高度に自動化されたパイプラインを実際のプロジェクトで稼働させるにつれ、現場から3つの違和感の声が聞えてきたと伊達氏は振り返る。それは、「どこを確認すればいいかわからない」という顧客の声、「AIから『できません』と返ってきた」という部下の声、「確認するだけの作業は誰が楽しいのか」という同期の声だった。
どれも最初は小さな違和感に過ぎなかったが、伊達氏はこの3つの声の背景に、AI駆動開発が孕む本質的な課題が隠れていると直感。それぞれの問題と深く向き合う決意をした。
完璧な成果物でも顧客に伝わらない理由
1つ目の違和感は、顧客への「伝わり方」に関するものだ。「設計書が残っていない既存システムのリバース案件で、自社テンプレートをもとにソースコードから設計書をAIで生成していました。AIは、クラス名やメソッド名、ソースの根拠まで網羅された完璧な設計書を出力し、自信を持ってお客様へ提出しましたが、『どこを確認すればよいか、わからない』という困惑の声が返ってきたのです。」と伊達氏は振り返る。
失敗の原因は正確さの欠如ではなく、顧客との関心領域のミスマッチにあった。 AIが出力したのはクラス名やメソッド名など、技術的精度の根拠となる「作り手の情報」であったのに対し、顧客が確認したかったのは業務が正しく成立するかという「受け手の情報（業務サマリーや画面イメージ）」だったのだ。
「正確に書くことと、伝わるように書くことは別問題でした。同じ仕様書でも読者が違えば必要な情報は変わります。誰に向けて書くかは人間が決め、読者ごとの書き分けをAIに担わせる。これが1つ目の気づきでした」と伊達氏は語る。
従来、顧客との対話の中で掴んできた「相手が何を重視して承認するか」というプロセスを、AIのスピードを優先して省いてしまったことが本質的な原因であった。
AIの回答によって探求を止める部下
2つ目の違和感は、部下の「判断」に関するものだ。伊達氏は「AIから『現在のインプットでは実装できません』といった応答が返ってきた際に、それ以上の探求をやめてしまう現場メンバーが増えていました」と語る。
しかし、AIの「できない」は不可能を意味するわけではない。プロンプトの構成や入力情報を工夫し、成功事例をインプットすることで突破できるケースは多い。「AIの『できない』はAIの限界ではなく、こちらの問いの限界です。結果はAIが出せても、なぜその結果になったのかという背景とゴールを握るのが人間の役割です」と伊達氏は強調する。
やりがいを失った現場にあえて組み込んだ「人間のゲート」
3つ目の違和感は、同期からの「やりがい」に対する問いだ。AI駆動開発の設計当初、伊達氏は「作業をAIに任せ、人間はレビューや受け入れテストに専念する」という合理的な役割分担を策定していた。しかし、効率重視の分担により、人間の業務は「AIが出した成果物をひたすら確認する作業」へと化した。「AIのアウトプットを確認するだけの作業は、誰が楽しいのか」という同期からの一言に、伊達氏はハッとさせられたという。
「効率を追い求めるあまり、自ら考える余白を奪っていたのです」と伊達氏は明かす。
そこで、人間が問いを立て、AIがその作業を支え、最終的な意思決定と探索を人間が行う形へ分担を見直した。試行錯誤やアイデアを練るプロセスを人間に戻すことで、仕事への手応えとやりがいを取り戻していくこととなった。
顧客に「伝わらない」、AIの「できない」で立ち止まる、確認作業に「やりがいを感じない」という3つの違和感。一見すると発生場所も対象もバラバラに見えたこれらの問題だが、根本にある原因は一つだった。
「3つとも、根っこはすべて同じでした。それは『自分自身が深く考えることをやめてしまっていた』ということです。AIの利便性に流され、思考の主導権を手放していたことこそが、すべての違和感の正体でした」
この気づきを得た伊達氏は、GitHub ActionsとClaude Codeで構築した全自動パイプラインの工程内に、あえて人間が立ち止まって思考を巡らせる「ゲート（深く考える場）」を明示的に組み込んだ。顧客に伝わる文脈になっているか、AIの「できない」の裏にある背景を考えているか、人間に判断と探索の余白が残されているかを確認するためだ。
AIが担う「作業の正確さ」と、人間が担う「深い思考と判断力」を融合させることこそが、AI時代における理想的な分業の姿であると導き出した。
人と人との「仕事」をつくるエンジニアリングへ
一連のパイプライン構築と運用の試行錯誤を経て、伊達氏はAI活用が前提となるこれからの時代にむけて「エンジニアの役割の再定義」を強く提唱する。
「エンジニアリングの重心は、コードを書く技術から、AIが正しく動くための仕様の境界条件や整合性検証ロジックを設計する技術へ移りつつあります。エンジニアとは、コードを書く作業者から、技術やデータを価値に翻訳し意思決定するアーキテクトへ進化した存在だと考えています」
AIが生成した仕様書やコードに対して、システム全体の矛盾や抜け漏れがないか、非機能要件や将来の影響範囲まで考慮されているかを深く検証し、保証するのは人間にしかできない高度な専門性だ。技術的な実装が自動化されるほど、人間側の「問題設定力」と「深い検証力」が価値の核心として際立つ。
AI駆動開発の進化によって、AIが担う領域と人間が担う領域の対比はより鮮明になった。
AIが担うのは、実装、設計、検証、仕様書生成、コード品質チェック、タスク分解といった技術的タスクである。一方で、自動化が進むことで、人間が本来担うべき領域が浮かび上がってくる。
「何を作るかの合意形成、顧客の真意を引き出す対話、成果物に納得してもらう瞬間、組織間で優先順位を決定する調整。これらは決してAIに仕事を奪われるということではなく、元々あった『人と人との仕事』に回帰するプロセスなのです」と伊達氏は語る。
講演の締めくくりとして、伊達氏は会場および画面の向こうのエンジニアたちへ呼びかけた。
「相手に伝えること、結果について考えること、やりがいのある仕事。AIの活用が進むほど、この3つを手放さないことが人の仕事になると考えています。ぜひ明日からの現場で、自分自身の業務の中に『人と人との仕事』がいくつあるか、数えてみてください」
NECソリューションイノベータ株式会社からのお知らせ
NECグループでは、エンジニアの仲間を募集しています。開発環境やカルチャー、現在募集中のポジションなど、詳しくは採用情報ページをご覧ください。
