「DevinやClaudeなどのAIツールを導入してみたものの、思い描いたコードが出てこない」「結局、手直しに時間がかかってしまう」――そんな、“AIのコントロールのむずかしさや、アウトプットのブレ”に悩んでいませんか？
本記事では、2026年3月18日にSHIFTが開催したイベント「AI駆動開発の現在地 ― 品質・生産性・コミュニケーションの実践レポート」の内容をもとに、工数40％削減を達成したAIエージェントと実践する「SDD×TDD」※の実践ノウハウをお届けします。
品質保証を原点とするSHIFTの開発現場から生まれたこの手法は、AIが意図しない方向へ進んでしまうのを防ぐだけでなく、「誰が指示を出しても高品質なコードが出力される」「レビュアーの負担を激減させる」という画期的な仕組みです。
明日から使える5つの実践ステップとは。
※SDD（Spec-Driven Development）：仕様駆動開発
※TDD（Test-Driven Development）：テスト駆動開発
-
AIモダナイゼーション技術企画部 馬塚（まづか）
独立系ソフトウェアベンダーにてWebアプリ開発等に従事した後、2020年にSHIFT入社。SHIFTではスクラム開発チーム向けにExtreme Programmingの各種プラクティスのコーチングや技術支援を実施。現在はSHIFT 開発標準(DQS)のボイラープレートの作成とAI開発プロセスの策定をメインで行っている。
-
AIモダナイゼーション技術企画部 和田
金融機関でのリスク管理業務、Web制作会社でのバックオフィス部門立ち上げを経て、2020年にエンジニアへ転身。保険会社の契約者向けWebサービスやBtoB向け音楽配信サービスなどの新規開発プロジェクトに参画。2025年3月にSHIFT入社。現在はSHIFT DQSのフロントエンド（React／Flutter）ボイラープレート開発に従事し、AI駆動開発の実践に取り組んでいる。
-
AIモダナイゼーション技術企画部 森下
金融系SIerにて、海外送金ハブシステムのシステム開発に従事した後、2023年11月にSHIFT入社。入社後は、DX推進案件に参画し、AWSへのデータ基盤移行・構築を経験。現在はSHIFT DQSのバックエンドボイラープレート開発に従事し、DQS新規機能開発、AI駆動開発の実践に取り組んでいる。趣味はアメフト。
目次
チャット感覚の指示が招く、AIのブレ
――近年、AIを使った開発が当たり前になりつつありますが、最初はSHIFTでも苦労があったと聞いています。当時の“壁”について、教えてください。
和田：はい、最初からうまくいったわけではありません。私自身、最初はチャット感覚でAIに指示を出していたのですが、最終的に出てくるコードが自分の思い描く理想の形になっていないことが多々ありました。
AIの回答が変な方向に進んでしまうことがあるんですよね。「自分の思い描く出力になるように、AIをなんとかコントロールしたい」と考えるようになりました。
――その課題解決に貢献したのが、高品質・高生産性を実現するSHIFT独自のシステム開発フレームワーク「SHIFT DQS（Development Quality Standard）」ですよね。馬塚さん、DQSについて教えていただけますか？
馬塚：はい。DQSは、プロジェクトを成功に導くための要素――要件定義、設計、実装、レビュー、テスト、運用など、それぞれにおける“品質と生産性を確保するための観点”を整理し、標準化したものです。
SHIFTでは、これにAIエージェント（主にDevin）を組みあわせて活用する独自のAI駆動開発手法を確立しています。
もともとはAIと関係なく、チームが拡大するなかで「品質のブレ」や「ノウハウが貯まらない」というチームの課題を解決するためにはじまりました。
――品質保証を原点にもつ、SHIFTならではの取り組みですね。
馬塚：ええ。そこからAIが浸透してきまして、「標準化の枠組みのなかでAIを使えば、生産性と品質を高くできるのではないか」と考え、DQSを進化させました。
現在のDQSは具体的な仕組みの集合体となっており、AIに的確な指示を出すためのルールファイルや、要件定義・設計書のテンプレートを大量に用意しています。そして、SHIFTのAI駆動開発の基盤といえる存在です。
SHIFTのAI駆動開発では、ウォーターフォール的な開発プロセスの各工程における、AIの役割を明確に定義しています。
たとえば、要件定義ではRFPなどから自動で要件定義書をつくり出します。
つづく設計工程でも、DQSに基づいてドキュメントを生成させています。実装においては、ReactやFlutterなどのボイラープレート（テンプレート群）を活用して爆速での開発を可能にしています。
――まさにSHIFTのDNAともいえる「品質保証」や「仕組み化・標準化」の思想を、AI駆動開発に乗せたような感じですね。 和田さんは前職でも標準化の取り組みをされていたと伺いました。
和田：はい。以前から「誰が書いても同じ品質でプロダクトをつくる」ことが重要だと考えて実装していました。SHIFTの品質保証に対するこだわりに賛同して入社した経緯もあります。
標準化の思想とAI開発を掛けあわせた結果、AIをコントロールする手法にたどり着いたわけです。曖昧な指示を排除し、誰がやっても同じ品質でAIにコードを書かせる仕組みです。
それが、現在私たちが実践している「SDD（Spec-Driven Development：仕様駆動開発）とTDD（Test-Driven Development：テスト駆動開発）を掛けあわせたAI駆動開発」です。
AIエージェントと実践する 「SDD×TDD」5つの実践ステップ
――では、その具体的な手法について教えてください。まず「SDD」とは何でしょうか？
和田：SDDは仕様を先に書き、それをAIへインプットして開発を進める手法です。
ここでAI制御の鍵となるのが「構造化された入力」です。チャットベースの曖昧な指示ではなく、構造化された入力をAIに与えることで、出力の品質が劇的に向上します。
――具体的にどのように進めるのですか？
和田：AI駆動開発のパイプラインを5つのステップに分けています。
ステップ1は「EARS記法」による要件の構造化です。
EARS形式とは、要件記述の標準化された書き方です。たとえば「ログインつくって」ではなく、「ユーザーが認証情報を送信するとシステムがこうなる」というルールに沿って書きます。
AIはEARS記法を知っているので、「要件をEARS記法で出して」と指示するだけで、精度の高いインプットがつくれます。
森下：ステップ2の「Gherkin（ガーキン）記法」も重要ですよね。
和田：はい。ステップ2では、構造化した要件の「受け入れ条件」をGherkin記法のシナリオベース（Given-When-Then）で書きます。
これの何がうれしいかというと、このシナリオが「テストコードの書き方」とほぼいっしょなんです。だからAIにお願いすると、想定通りのテストコードを高精度で書いてくれます。
――ステップ3は「タスク分解」ですね。
和田：そうです。ステップ1と2でつくったシナリオをベースに、AIが実装できる粒度にタスクを分解します。「1タスク1実装単位」が基準です。
大きすぎるタスクを振るとAIは変な方向に行ってしまうので、細かく分解することが出力の安定につながります。
ここまできたら、いよいよ実装です。ステップ4はTDD。
AIは実装が速い分、暴走することもあります。もしAIが間違ったコードを書いてからテストをつくると、その間違ったコードにあわせてテストを通してしまい、品質が悪いのにテストはOK、という状態になりがちです。
馬塚：辻褄あわせをしてしまうんですよね。
和田：ええ。だからこそ、まずGherkin記法をベースにAIにテストを書かせます（Redの状態）。
AIが変な方向に進まないようガードレールを設置してから、ステップ5でそのテストが通るように実装をお願いする（Greenの状態にする）。これで、AIの挙動をコントロールできます。
ここで一番お伝えしたいのは、「特定のツールより、考え方が先」だということです。弊社では主にDevinを使っていますが、Claude Codeでもその他のツールでも構いません。
ツール云々よりも、「要件を構造化して与え、テストから書いてAIをコントロールする」という考え方そのものを身につけることが重要です。
工数40％削減！圧倒的な成果と、浮き彫りになる「人間の新たな役割」
――この「SDD×TDD」を導入して、実際の成果はいかがですか？
森下：成果は大きく2つあります。
まず、社内で「イチゲキPJ」と呼ばれるフロントエンド開発の自動化プロジェクトでは、Figmaのデザインシステムと、あらかじめ整備されたReactなどのボイラープレートを連携させています。
AI経由で、デザインに忠実なコードを一気に自動生成しています。これにより、DQSを使った実案件では40％もの工数を削減できました。
また、レガシーシステムの内部仕様をAIで解析して可視化し、モダンなシステムへつくり変える「モダナイゼーション」の超効率化にも取り組んでいます。
実装フェーズでの生産性は、人が書くよりAIの方が確実に速く、数倍レベルに跳ね上がっています。
森下：最近は、技術進化が目覚ましいですよね。Claude Codeでいうと、サブエージェントなどさまざまな機能が追加されました。
エージェントを並列で動かして開発することもできるようになってきて、ますます生産性は向上すると思います。
――圧倒的ですね！ 一方で、「生産性が上がる分、レビューの量が増えるのでは？」というコメントも来ています。
馬塚：そこが現在の新たな壁です。AIの実装能力が高くなると、今度は「人のレビュー」が強烈なボトルネックになります。シニアエンジニアに負荷が集中してしまうわけです。
これからは「レビューをする能力」よりも、「いかにレビューの絶対量を減らすか」を考える能力が重要になります。
AIに事前レビューをさせたり、人間が見やすいサマリーを出させたりして、レビュアーをいたわるようにしたいですね。
――人間が必ず確認しなければならないポイントはどこでしょうか？
馬塚：自動テストでカバーできない部分ですね。例えば、画面のレイアウト崩れや大量の文字列入力時のイレギュラーなUI挙動などは自動テストでは判断できないため、引き続き人が目視で確認するよう切り分けています。
SHIFTでは、世界的品質保証標準と年間4,000件もの支援経験から得たナレッジを融合させた独自の品質保証標準「SQF（SHIFT Quality Framework）」を用いて、自動でできるテストと手動でやるべきテストを明確に区分けしています。
コードを書く喜びから、最速で価値を届ける喜びへ
――レビューの負荷も含め、これからのエンジニアに必要なスキルはどう変わっていくと感じていますか？
馬塚：コードを書く力以上に、「タスクをどう分解して、どの順序でAIに指示を与えるか」を見極める判断力が必要になります。
また、AIは複数のアーキテクチャ案を出してくれますが、システム全体の制約やチームのスキルを考慮して「最終的にどれを選ぶか」を決めるのは人間です。
森下：私も痛感しています。いままでのような単純な実装作業が減った分、設計全体を広い視野で考えないと、よいものはつくれません。頭の使い方が根本的に変わってきているのを感じます。
――求められる視野が広がると、若手エンジニアの参入が難しくなりませんか？
馬塚：昔のように「とりあえずコードを書いてシステムを覚えていく」という体験は減るでしょうね。
ただ、逆にAIをツールとして使えば、既存システムの理解は圧倒的に早くなります。AIに「ここどうなってる？」と聞けば、複雑な仕様もすぐにサマリーで教えてくれますから。
AIを味方につければ、若手にとっても強力なオンボーディングツールになります。
和田：確かにコードを叩く時間は減りましたが、別の楽しさがありますよ。先日、AI駆動開発でお客様のプロダクトをリリースしたのですが、AIを駆使して高速で高品質なものをつくり上げる体験は、非常に刺激的でした。
工数を40％削減しながらも、お客様からポジティブなフィードバックをいただけたこと。これが、これからのエンジニアの新たな「成功体験」になるのだと思います。
（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）
