AWS Summit Japan 2026の来場者向けセッションで、GitLab合同会社 シニア ソリューション アーキテクト 小松原 つかさとソニービズネットワークス株式会社(以下、SBN) 開発本部 グループマネージャー 濱田 一成氏が登壇しましたので、その模様をお伝えします。
GitLabブースの様子
GitLabは2026年6月25~26日、千葉・幕張メッセで開催された「AWS Summit Japan 2026」に出展しました。ブースでは最新ソリューションの紹介だけでなく、ノベルティが当たる抽選会なども行い、多くのユーザー様やGitLabに興味を持っていただいた方と交流することができました。
そして、今年も会場内のセッションに、多くのお客様に来場いただくことができました。登壇者は、昨年と同じ2人。ゲストにSBN開発本部 グループマネージャー 濱田 一成氏をお迎えし、GitLabからはシニア ソリューション アーキテクト 小松原 つかさが講演しました。両社のブースに近いセッション会場ということもあってか、大勢のお客様にご来場いただき、立ち見が出るほどの盛況でした。終了後に小松原と濱田氏が直接お話させていただいた方も多く、30分という短いセッションでしたが、濃密な時間になりました。この記事では、セッションの模様を中心にお届けします。
GitLab合同会社 シニア ソリューション アーキテクト 小松原 つかさ
セッションは、小松原の講演からスタート。その冒頭で小松原は、「おそらく、IT業界でいまがいちばん面白い時期でしょう。こんなに激しく周りの環境が変わったことはありませんでした。きっと、40~50歳の方には深く共感いただけるはず。いま、このタイミングを迎えていらっしゃる方は、大変なミッションもあるかもしれませんけど、ぜひこの状況を愉しんでいただければ」と会場に語りかけます。
変化は、AIの急速な浸透によってもたらされました。一方、AIがまだ懐疑的な目で見られていたころから、開発現場の制約としてコンプライアンスの問題が語られてきました。大規模開発では、自分で仕様を決め、実装も自分でやり、テストまで自分でやることはありません。多くの人がかかわる開発プロセスにおいて、ルールを決めて責任の所在を明確にすること。それが開発におけるコンプライアンスです。「ただし、ルールがありすぎると効率が悪くなります。だからと言ってルールをなくせばだれかのツッコミを食らって作り直しを要求されてしまう……。これが開発現場のジレンマになっています」(小松原)
こうした状況の中でAIが浸透したために、“AIパラドックス”がよりクローズアップされています。コーディングの高速化を求めてAIを導入したものの、実はボトルネックは設計、レビュー、テストなどコード生成以外のプロセスにあり、ガバナンスも含まれます。そのため、AIを本格的に活用するためには、AIによるコード生成だけでなく、「開発プロセス全体でAIを活用する」という方針の下に、プロセスそのものを再設計する必要が出てきます。
図:インテリジェントオーケストレーションの概要
小松原は、「ソースコード開発がプロセス全体に占める割合は20%くらいでしょう。設計がきちんとできていれば、成果物はほぼ出来ている状態に見えるかもしれません。それでも、テストでは必ずバグが見つかるものです。バグにもいろいろあって、直すバグと直さなくても大丈夫なバグを判断しなければなりません」と話します。GitLabを使えば、AIの拡張範囲をこの部分まで容易に拡張できます。
GitLabは、開発現場における「管理ツール」から「AIの成果物を評価・統制するクオリティゲート(合否判定のチェックポイント)」へと進化しています。GitLab上のチケットやマイルストーンを管理する独自のMCPサーバー(GitLab Model Context Protocol)を活用し、AIエージェントが必要とする情報を抽出。ClaudeやKiro、Copilotなどに渡すことができるのです。そして、これがAIエージェントのクオリティゲートとして機能します。GitLab OrbitでAIにコンテキスト=文脈を提供できることも重要です。次の濱田氏のパートでも語られたトークンの浪費を防ぐことにもつながります。

小松原は、「ここからは、実際にAWSとGitLabを組み合わせてプロダクト開発をされている現場のお話です。濱田さんは、この技術を駆使して、ブースでデモも展示してくださっています。まさに“スーパーエンジニア”による、リアルなAI駆動開発の知見に耳を傾けてください。それでは、濱田さん、よろしくお願いいたします」と濱田氏にバトンを渡しました。
SBN 開発本部 グループマネージャー 濱田 一成氏
濱田氏は、今年もAWS Ambassador かつAWSの全12資格を持つ者の証である金のジャケットを身に纏って登壇しました。まずは「AI駆動開発」という言葉を「AIが主体となって開発から保守まで行うこと」と再定義しました。
ソフトウェア開発の歴史を紐解くと、長く人間が主体となってコードを書く時代が続きました。数年前からAIに補助してもらうことが一般化し、現在はAIがコード生成して人間がそれを監視するようになりました。そのため、AI駆動開発と聞くと、「生成AIや機械学習モデルをソフトウェア開発ライフサイクルの全工程に組み込み、AIの支援や自律的な処理を主軸に据えて開発を進める手法」ととらえてしまうかもしれません。しかし、濱田氏は「AIが主体になる」と踏み込んだことになります。
そのAI駆動開発を実現するためには、単一のツールに依存せず、AIの特性に合わせて賢く使い分ける戦略が有効です。濱田氏は、「AIをフルに活用しようとすると、避けて通れないのがコストの話。つまり、消費クレジットの管理が問題になってきます。モデルによって消費量が変わるため、何も考えずに高機能で高コストなAIにすべてを任せてしまうと、あっという間にコストの限界がやってきます。GitLabとKiroは組み合わせて利用することで価値を得られますが、私たちは作業領域やAIの活用についても明確に役割分担させています」と話します。
具体的には、重い処理やガバナンスが求められる領域はGitLabで実行し、日々のコーディング部分をKiroに任せています。
「たとえば、コードレビューや脆弱性スキャンといった、セキュリティのクオリティゲートを通過させるのはGitLabの役割です。一方、実装やブラッシュアップといった泥臭いコーディングはKiro。このように、作業の内容に合わせてツールとAIを使い分けることで、クレジット効率は劇的に向上します」(濱田氏)
さらに、濱田氏はAWS環境特有の強みとして「AWS DevOps Agent」の導入を挙げました。AWSアカウント内のリソースをエージェントが自律的に探索・把握し、ドキュメント化まで完了させてくれるこの仕組みが、開発効率を底上げしてくれるといいます。
SBN 開発本部 グループマネージャー 濱田 一成氏
濱田氏は、「GitLabの良さの1つは、あらゆるAIに対して中立という立場を守り続けていることです。KiroはもともとClaude中心でしたが、今後、GPT-5系への対応が予想されますし、、個人的にも“特定の場面に最適なAI”は日々変わると考えています。今後は、コストと成果のバランスを判断しながら、GitLabとKiroを併用する環境で、より柔軟にAIを切り替えながら開発を進めていけることを期待しています」と話します。
GitLabとKiro、そしてAWS DevOps Agentの相性の良さは、GitLabのパイプラインやデプロイログをAWS DevOps Agentが情報ソースとして取り込める点からも明らかです。これが実現することで、AIエージェントの目には、インフラの設定値と実際のデプロイの成否が一連のストーリーとして見えることになります。これこそ、ただのコード生成ツールを超えたAI駆動開発基盤の強みだと濱田氏は強調しました。
実際、障害調査をAIエージェントに丸投げしても、過去のログやデプロイ履歴から即座に原因を突き止めてくれるため、トラブルシューティングの時間は劇的に短縮されます。
濱田氏は最後に、開発現場で起きた次のようなエピソードを会場にシェアしてくれました。
「今回、ブースで披露しているデモの準備中、テスト用にわざとバグを仕込んだら、GitLab Duoにめちゃくちゃ怒られました(笑)」
ログ機能とは無関係なディレクトリ構造の変更に対し、GitLab Duoはすかさずこう指摘したといいます。
――この変更はAWS Lambdaのデプロイに支障をきたす可能性があります。誤って変更した場合は元に戻してください――
GitLabが品質を担保するガードレールとして機能していることを証明するエピソードでした。AIと人が共創し、GitLabがその土台としてガバナンスを効かせることはすでに実現しています。濱田氏の再定義したAI駆動開発は、すでに手に入る技術になっていると感じさせてくれるセッションになりました。
左からGitLab合同会社 シニア ソリューション アーキテクト 小松原 つかさとSBN 開発本部 グループマネージャー 濱田 一成氏
ノベルティのルービックキューブ
このブログ記事を楽しんでいただけましたか?ご質問やフィードバックがあればお知らせください。GitLabコミュニティフォーラムで新しいトピックを作成してあなたの声を届けましょう。
フィードバックを共有する