スピードと品質の両立 – Kiro が加速する開発、GitLab AI が支えるレビュー。新時代の開発パートナーシップ設計

本記事は Kiroweeeeeeek in Japan ( X: #kiroweeeeeeek) の第 10 日目です。GitLab 合同会社小松原様に寄稿いただきました。

はじめに：開発が速すぎる時代の新しい課題

Kiro の登場により、ソフトウェア開発は劇的に加速しました。チャットで要望を伝えるだけで、あっという間に仕様書が生成され、コードが書かれる。開発者にとっては夢のようなツールです。

しかし、この「速すぎる開発」は、特に日本の開発現場において新たな課題を生み出しています。それは、発注元と開発会社の間に生まれるスピードギャップです。

発注元の担当者はこう悩みます。「開発が速すぎて、レビューが追いつかない」「コードを見せられても、正直よくわからない」「品質は本当に大丈夫なのか？」

一方、開発会社側も苦しんでいます。「Kiro で速く作れるのに、レビュー待ちで開発が止まる」「後から『思っていたのと違う』と言われて大幅な手戻り」「非エンジニアへの技術説明に膨大な時間を取られる」

本記事では、GitLab Self-Hosted Model（Amazon Bedrock 活用）を組み合わせることで、この課題を解決する新しい開発パートナーシップモデルを提案します。

日本の開発現場の実態：発注元と開発会社の分離

日本のソフトウェア開発において、発注元と開発会社が分離しているケースは非常に一般的です。

発注元の立場：

ビジネス要件は理解している
しかし、プログラミングの経験はない
コードレビューは実質的に不可能
「動くものを見て初めて理解できる」状態

開発会社の立場：

技術的な実装は得意
しかし、発注元の真のニーズを引き出すのは難しい
後段での仕様変更・手戻りに悩まされる
レビュー待ちによる非効率な稼働

従来、この問題は「丁寧なコミュニケーション」「詳細な要件定義」「時間をかけたレビュー」で解決しようとしてきました。しかし、それでは Kiro の圧倒的なスピードを活かしきれません。

Kiro の強みと、それがもたらす新たな課題

Kiro の最大の特徴は、いきなりコードを書くのではなく、まず仕様書を生成してくれる点にあります。これは実は非常に重要な機能です。

しかし、現実にはこの仕様書レベルでの認識合わせが十分にできていません。

なぜなら：

仕様書が詳細すぎる：技術的な詳細が多く、非エンジニアには理解しづらい
考慮漏れの発見が難しい：発注元が「何が書かれていないか」を判断できない
コード生成が速すぎる：仕様書のレビューが終わらないうちに実装が進む

結果として、「実装完了後に初めて問題が発覚」→「大幅な手戻り」というパターンが頻発します。

「ソフトウェア工学の研究では、バグ修正コストは発見タイミングによって劇的に変わることが示されています。

一般的に：

要件定義段階：基準
コーディング段階：2〜5 倍
統合・テスト段階：5 〜 10 倍
本番環境：10 〜 30 倍以上

つまり、早期に問題を発見することが、コスト削減の最大の鍵なのです。

解決策：GitLab + Amazon Bedrock による「仕様書レベルの品質担保」

ここで登場するのが、GitLab Duo Self-Hosted（Amazon Bedrock 活用）です。

GitLab Duo Self-Hosted は、自社環境内にAI Gatewayを配置し、Amazon Bedrock を通じて Anthropic の Claude などの大規模言語モデルを利用できる仕組みです。重要なのは、データが自社ドメイン内に保持され、外部 API への依存なしに GitLab Duo 機能（コードレビュー、チャット、コード生成など）を活用できる点です。つまり、セキュリティ要件が厳しい企業でも、最新の AI 技術を安心して活用できます。

これを Kiro と組み合わせることで、以下のような新しいワークフローが実現します。

ステップ1：発注元が要望を下書き

発注元の担当者は、ラフな要望を GitLab のイシュー機能に書き込みます。技術的な詳細は不要です。「エアコンのリモートコントロール機能が欲しい」といった業務レベルの記述で十分です。

ステップ2：GitLab AI が要件を整形

GitLab 上の AI（Amazon Bedrock）が、この下書きを正式な要件仕様に整形してくれます。必要な技術要素、考慮すべきセキュリティ、エラーハンドリングなどを自動的に追加し、「プロが書いた要件定義書」に仕上げます。

ステップ3：Kiro が詳細仕様書を生成

開発会社のエンジニアは、このイシューを Kiro に渡します。Kiro は自社の技術スタックや開発標準を理解した上で、詳細な仕様書（Spec ファイル）を生成します。これを GitLab へ Commit & Push します。

ステップ4：GitLab AI が発注元目線でレビュー

ここが最も重要なポイントです。発注元の担当者は、Kiro が生成した仕様書を直接レビューする必要はありません。代わりに、GitLab AIに質問します。

「この仕様書に考慮漏れはありますか？」「セキュリティ上の問題はありますか？」「当初の要望と違う部分はありますか？」

GitLab AI は、以下のような観点で自動的にレビューを実施し、日本語でフィードバックします：

セキュリティ関連：認証・認可の不備、通信暗号化の欠如など
エラーハンドリング：ネットワーク障害時の対応、エアコンが応答しない場合の処理など
機能面：現在室温の表示、操作履歴の記録、複数台のエアコン管理など

発注元の担当者は、これらの指摘を見て「確かに、それも必要だ」と気づくことができます。今までのやり方とは次元が違うレビューが可能になっていますよね。

ステップ5：Kiro が仕様を修正

GitLab AI の指摘を受けて、開発会社のエンジニアは Kiro に修正を依頼します。Kiro は数分で仕様書を更新し、コード生成へと進みます。

ステップ6：GitLab AI がコード品質もチェック

生成されたコードも、GitLab AI が自動的にレビューします。コーディング規約、脆弱性、パフォーマンス上の問題などを自動検出し、必要に応じて Kiro に修正を依頼できます。

経済合理性：なぜこのモデルが持続可能なのか

このワークフローがもたらす経済的メリットを整理しましょう。

削減できるコスト

レビュー待ち時間の削減 : 従来、発注元のレビューには数日から数週間かかることも珍しくありませんでした。その間、開発会社のエンジニアは次の作業に進めず、非効率な稼働となります。GitLab AIによる自動レビューで、この待ち時間を大幅に削減できます。
手戻りコストの削減 : 前述の通り、後段での修正は初期段階の5倍以上のコストがかかります。仕様書段階で問題を発見できれば、コーディング後やテスト後の大幅な手戻りを防げます。
コミュニケーションコストの削減 : エンジニアが非エンジニアに技術的な説明をする時間は、想像以上に大きなコストです。GitLab AIが「翻訳者」の役割を果たすことで、このコストを大幅に削減できます。
品質向上による保守コストの削減 : 早期段階でのAIレビューにより、セキュリティ問題や設計上の欠陥が減少します。これは、リリース後の保守・運用フェーズでのコスト削減にもつながります。

新時代のパートナーシップ：AI が繋ぐ信頼関係

このモデルが実現するのは、単なるコスト削減ではありません。発注元と開発会社の新しい信頼関係です。

発注元にとって：

コードを理解できなくても、品質を担保できる安心感
早期段階で「本当に欲しいもの」を確認できる
開発会社への的確なフィードバックが可能に

開発会社にとって：

レビュー待ちのストレスから解放
手戻りが減り、計画通りの開発が可能に
技術的な説明ではなく、本質的な開発に集中できる

両者にとって：

仕様書レベルでの継続的な対話
早期の問題発見による「左シフト」の実現
スピード（Kiro）と品質（GitLab AI）の両立

まとめ：持続可能な開発パートナーシップへ

AI 時代の開発は、単に「速く作る」だけでは不十分です。発注元と開発会社が、それぞれの強みを活かしながら協働できる仕組みが必要です。

Kiro が実現する圧倒的なスピードと、GitLab + Amazon Bedrock が実現する品質担保。この 2 つを組み合わせることで、両者が幸せになる持続可能な開発パートナーシップが実現します。

「速すぎて困る」という贅沢な悩みを、「速いからこそ品質も高められる」という新しい価値に転換する。それが、これからのソフトウェア開発のあるべき姿なのかもしれません。

Amazon Web Services ブログ