G-gen の高宮です。当記事では、AI 駆動フロントエンドデザインツール Stitch と、AI 駆動統合開発環境 Google Antigravity 2.0 を組み合わせた、AI 駆動開発について紹介します。 はじめに AI 駆動開発（AI-Driven Development）とは Stitch とは Google Antigravity とは 環境準備 Stitch でのフロントエンドデザイン Antigravity 2.0 での開発 Stitch との連携 アプリケーションコードの開発 Google Cloud 環境へのデプロイ 実践と応用 はじめに AI 駆動開発（AI-Driven Development）とは 2026年7月現在、生成 AI の進化に伴い、ソフトウェア開発の手法は大きく変化しています。従来の AI コードアシスタントは、開発者が記述するコードの補完や部分的なリファクタリングを支援する補助ツール的な位置づけに留まっていました。 これに対し、 AI 駆動開発（AI-Driven Development） と呼ばれる新しいアプローチでは、自律的な AI エージェントが主体となり、プロンプトに従って設計、実装、テスト、そしてデプロイまでを人間の監督のもと実行します。人間はコードを一行ずつ記述するのではなく、自然言語でシステムの要件を定義し、AI の実装方針やコードに対してレビューを行うことで、システム開発プロセスをコントロールします。 当記事では、この開発ライフサイクルを Google のツール群を用いて実践した内容を紹介します。 参考 : AI駆動開発とは｜仕組み・メリット・導入プロセスをわかりやすく解説 Stitch とは Stitch とは、Google Labs が提供する AI 駆動フロントエンドデザインツールです。 自然言語によるプロンプトや、参考となるサイトの URL、あるいは既存のスクリーンショットを入力するだけで、レスポンシブな UI/UX デザインができます。また、デザインをブラッシュアップ、本番展開に向けた開発のために、以下の機能が提供されています。 機能 説明 継続的な会話 生成されたデザインに対して、チャットを通じてピンポイントで具体的な修正指示を出してデザインの変更が可能 テーマ編集 デザインの根本となるコアテーマ（テーマカラー、フォント等）をより素早く一括で調整・変更が可能 プロトタイプ 静的なデザインのモックを、実際の利用シーンを想定して文字の入力、ボタン押下などの操作が可能 エクスポート 完成したデザインを、実際の開発に移行するためのファイル（HTML, CSS, JavaScript）やデザイン定義（ DESIGN.md ）として出力 Model Context Protocol（以下、MCP） AI ツールから接続するための MCP サーバーが提供され、デザインの操作が可能 2026年7月現在、Stitch は Beta 版として提供されています。入力されたデータはサービスの改善のために収集されるため、機密性の高い情報の入力については十分に注意して使用してください。 参考 : Google Stitch 参考 : Everything you need to know to design with Stitch 参考 : Stitch MCP Guide 参考 : Stitch のプライバシーに関するお知らせ Google Antigravity とは Google Antigravity とは、Google が開発した AI 駆動統合開発環境です。2026年7月現在、以下のプロダクトが提供されています。 プロダクト名 概要 説明 ユースケース Antigravity 2.0 スタンドアロン型のエージェント管理デスクトップアプリケーション ・IDE から独立した、エージェント管理のための単一プラットフォーム ・複数のワークスペースやワークツリーをまたいだプロジェクト管理 ・非同期のタスク管理、定時実行に対応 複数のローカルサブエージェントを並列で動かし、複雑なタスクを統合制御したい開発者 Antigravity CLI 軽量なコマンドラインインターフェース ・デスクトップアプリと同等のコアエージェント機能をターミナルで実現 ・高速なプロンプトショートカットやカスタムキーバインディング ・並列サブエージェントの管理に対応 SSH セッションでの利用やキーボード中心の操作を好む開発者 Antigravity SDK 開発者・研究者向けの Python フレームワーク ・エージェントの挙動やデプロイをコードから完全に制御可能 ・カスタムエージェントの構築、カスタムツールの登録 エージェントの挙動を高度にカスタマイズ・プログラム制御したいシステム開発者や研究者 Antigravity IDE AI 駆動型統合開発環境 ・コーディングエージェントを搭載した Code OSS ベースの IDE ・コードベースに対する深い理解 ・MCP や Skills などとシームレスに統合 日常のコーディング業務を AI エージェントと強力に連携して標準化・効率化したい開発者 参考 : Google Antigravity 参考 : Google Cloud MCP Serversを解説 参考 : Agent Skillsを徹底解説！ Antigravity では、AI エージェントが以下のようなタスクを実行できます。 アクション 概要 実装プラン（Implementation Plan）の作成 リサーチを行い、アプリケーション開発のための具体的な実装計画を自動生成し、人間の承認を経て実行 ウォークスルー（Walkthrough）の作成 実装プランを実行した結果をウォークスルーとしてまとめて報告 システムコマンドの実行 エージェントが直接システムコマンドを起動・制御 ファイル操作（Read/Write） ファイルの読み込みや書き込みをシームレスに実行 Web 検索の実行 最新の情報やリサーチのために、エージェント自らが Web 検索を実行 外部ツール・MCP 連携 Skills や MCPサーバー を介して、外部のツールやサービスに接続 サブエージェントの管理 メインのエージェントが複数のサブエージェントを配下に置き、タスクを分担・管理し実行 Google Chrome との連携 Chrome ブラウザを操作し、アプリケーションを操作しテスト等のタスクを実行 参考 : Antigravity 2.0 また、Antigravity を使用した開発については、以下の記事も参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp 環境準備 当記事での AI 駆動開発では Antigravity 2.0 を使用します。以下の手順でバックエンドに Google Cloud を指定することで、 Antigravity 2.0 を安全に使用できます。 Google Cloud プロジェクトの準備 Google Cloud コンソールにアクセスし、使用するプロジェクトを選択または新規作成します。 プロジェクトの新規作成には「プロジェクト作成者（ roles/resourcemanager.projectCreator ）」ロールが必要です。 請求（Billing）の確認 対象の Google Cloud プロジェクトで課金が有効になっていることを Google Cloud Billing コンソールで確認します。 Agent Platform API の有効化 必要な API（ aiplatform.googleapis.com ）をプロジェクト内で有効化します。 API の有効化には「Service Usage 管理者（ roles/serviceusage.serviceUsageAdmin ）」ロールが必要です。 IAM の付与 Antigravity の認証に使用する Google アカウントに対し、プロジェクトレベルで「Agent Platform ユーザー（ roles/aiplatform.user ）」ロールを付与します。 セキュリティとログの構成（任意） ログの監査 : 必要に応じて、リクエストおよびレスポンスのロギングを有効化・構成します。 VPC Service Controls : 組織でサービス境界を設定している場合は、境界内に「Agent Platform API」を追加します。 Antigravity 2.0 での認証 設定完了後、Antigravity 2.0 の初期画面で Use business account を押下します。 次の画面で Continue with Google Cloud を押下します。 認証に使用する Google アカウントでログインします。 対象のプロジェクトを入力し、適切なエンドポイント（ global 、 eu 、 us のいずれか）を指定します。 参考 : Getting Started with Antigravity and Gemini Enterprise Agent Platform Stitch でのフロントエンドデザイン Stitch を使用したフロントエンド UI の作成は、非常にシンプルかつ直感的に進めることができます。まず、Stitch のコンソール画面を開き、以下のプロンプトを入力します。作成対象は「ウェブ」、モデルは「Gemini 3.1 Pro」を選択します。 Google Cloud 専業のクラウドインテグレーターの株式会社○○のホームページを作成してください。モダンでクリーンなデザインが好ましいです。 入力されたプロンプトに対してデザインの構成案が提示され、回答候補から次のアクションを選択するか、任意のプロンプトを追加で入力できます。今回は提示された構成案でデザインを進めてもらいます。 AI が思考を開始し、プロンプトにあったデザインが生成されます。 生成されたデザインに対して、追加の要件がある場合は、個別のページを選択して追加の要件を入力することもできます。今回は全てのページを日本語に修正して欲しいので以下のプロンプトを入力します。 全てのページを日本語にしてください。 追加のフィードバックを与えることで、ホームページが日本語化されました。また、プロトタイプ機能を使用することで、画面の雰囲気を Stitch 上で確認できます。 このように Stitch はプロンプトで指示された内容を認識し、対応する HTML, CSS, JavaScript のコードを自動的に書き換えます。 Antigravity 2.0 での開発 Stitch との連携 Stitch でデザインが完成したら、Antigravity 2.0 を使用してフロントエンド UI を表示する Web アプリケーションを開発します。まず、Antigravity 2.0 から、Stitch のデザイン仕様を読み込むために、以下の手順で MCP サーバーを使用します。 Stitch の設定画面から Stitch API キーを発行します。 API キーは共有したり公開コードに埋め込まないように管理には十分ご注意ください。 Antigravity 2.0 の MCP 設定画面から Stitch MCP サーバーの構成を登録し、Stitch から取得した API キーを設定します。 上記の手順により、Antigravity 2.0 内で稼働する AI エージェント群が、Stitch のプロジェクトに直接アクセスし、UI の構造やカラーテーマ、スタイル仕様を取得できます。 参考 : Stitch MCP Setup & Authentication 参考 : Antigravity Editor: MCP Integration アプリケーションコードの開発 今回は、Stitch でデザインした静的なホームページ（HTML、CSS、JavaScript）を表示し、Python バックエンドで Web サーバーを起動して動作させるシンプルな Web アプリケーションを開発します。まず、Antigravity 2.0 で、対象のフォルダ、エージェントのセキュリティ設定を選択し、実装のためのプロジェクトを作成します。 その後、コンソールで以下のプロンプトを入力します。 Stitch MCPを使用して「Google Cloud Integrator Site」プロジェクトからデザインをインポートし、それをユーザーに提供する Python のアプリケーションを構築してください。必要な依存パッケージの設定、ローカル動作検証用のユニットテストコードの作成、そして Google Cloud のベストプラクティスに則ったデプロイ準備まで実施してください。 指示を受け取ると、以下のステップで実装計画（Implementation Plan）を立案します。この際、エージェントがローカルでコマンドの実行が必要な場合には、実行前に必ず人間に実行するコマンドと実行して問題がないかを確認します。 選択したフォルダ内に Git リポジトリが存在するか確認します。存在しない場合はリポジトリを作成します。 Stitch MCP サーバー経由で、Stitch でデザインした情報を取得します。 Antigravity 2.0 の初回起動時に組み込み可能な、 modern-web-guidance Skills を使用して、Web アプリケーションを設計します。 実装計画をレビューし、修正して欲しい内容があれば、以下のようにコメントできます。 コメントを追加して、以下のプロンプトを入力します。 コメントを記載したので、実装計画を見直ししてください。 コメントを確認して、以下のように実装計画が見直されました。問題がなければ、実装計画を承認して実装を開始します。 エージェントは実装計画に沿って以下のステップで実装・テストを行います。 アプリケーションが動作するために必要なコードを作成します。 アプリケーションがコンテナで起動するための Dockerfile を作成します。 ローカルでコンテナを起動し、作成したテストコードでテストを実行します。 実装・テストの結果は、以下のウォークスルー（Walkthrough）として報告されます。結果をレビューし指摘事項があれば、開発のサイクルを回せます。 今回の手順で以下の画面の実装が完了しました。 このようにエージェントはファイルを生成するだけでなく、エージェント用の仮想ターミナル上でコマンドを実行し、動作確認まで行えます。テストに失敗した場合は、エラーログを自律的に読み取って修正を行い、完全に動作する状態になるまで自己修正ループを繰り返します。開発者はそのプロセスを Antigravity 2.0 の Conversation で確認し、適宜指示を行うだけで開発が完結します。 Google Cloud 環境へのデプロイ アプリケーションのローカルでの動作確認が完了したら、アプリ開発に使用した Conversation で、引き続き Google Cloud の Cloud Run へのデプロイと、Identity-Aware Proxy（以下、IAP） を使用したアクセス制限の設定を指示します。 開発したアプリケーションを Google Cloud プロジェクトの Cloud Run にデプロイしてください。 g-gen.co.jp ドメインのユーザーのみがアクセスできるように、IAP で保護して公開してください。 アプリケーションコードの開発時と同様に、実装計画が立案され、内容を承認することで作業を開始します。エージェントは以下の手順で Google Cloud にアプリケーションをデプロイします。 Google Cloud プロジェクトのプロジェクト番号を取得し、IAP サービスエージェントに「Cloud Run 起動元（ roles/run.invoker ）」ロールを付与します。 gcloud run deploy コマンドを使用して、ソースコードからコンテナをビルドし、IAP を有効にした状態でサービスをデプロイします。 IAP 構成を更新し g-gen.co.jp ドメインのユーザーのみに「IAP で保護されたウェブアプリユーザー（ roles/iap.httpsResourceAccessor ）」ロールを付与します。 デプロイ完了後、エージェントから Cloud Run のサービス URL が提示され、アクセスすると IAP での認証完了後に、Cloud Run にデプロイされたホームページにアクセスできます。 参考 : Cloud Runを徹底解説！ 参考 : Cloud Runでロードバランサを使用せずIdentity-Aware Proxy（IAP）を構成する 参考 : ビルドを使用してデプロイする 実践と応用 当記事で紹介する Stitch と Antigravity2.0 を使っているわけではありませんが、以下の記事では、ライオン株式会社様が GitHub Copilot と SpecKit 等を用いて本格的なデータパイプライン開発を行った実例が紹介されています。システムインストラクションや Constitution によるハーネスの制定は、どのようなツールでも共通して重要です。AI 駆動開発における参考にしてください。 zenn.dev なお関連して、2026年7月30日から31日に開催される Google Cloud Next Tokyo '26 では、ライオン株式会社様や株式会社 G-gen が各種セッションで登壇します。これらのセッションも参考にしてください。 日時 実施会社 セッション種別 タイトル 2026年7月30日 (木) 13:00 - 13:30 ライオン株式会社 カスタマーセッション 生成 AI による SAP を中心とした AI-ready なデータ基盤の実践的な構築 2026年7月30日 (木) 15:00 - 15:30 ライオン株式会社 ブース内セッション (G-gen 出展ブース) ライオンのデータモデル Deep Dive 2026年7月31日 (金) 15:00 - 15:30 株式会社G-gen スポンサーセッション AI エージェント時代のクラウド インフラ設計ガイドラインの重要性 Google Cloud Next Tokyo '26 には、以下から申し込み可能です。 申込URL　: Google Cloud Next Tokyo '26 招待コード: NxT26_pt023 高宮 怜 (記事一覧) クラウドソリューション部ソリューションアーキテクト課 2025年6月より、G-genにジョイン。前職は四国のSIerで電力、製造業系のお客様に対して、PM／APエンジニアとして、要件定義から運用保守まで全工程を担当。現在はGoogle Cloudを学びながら、フルスタックエンジニアを目指してクラウドエンジニアとしてのスキルを習得中。 Follow @Ggen_RTakamiya

最近、新たなCSSプロパティ text-autospace が主要なWebブラウザーでサポートされました。どうしても和文と欧文の交ぜ書きが多くなる技術ブログにおいて、待望のプロパティです。そのあらましと、このブログにおける採用について紹介します。 やったこと 背景 将来 デジタル改革推進部の小林です。普段は社内ID基盤のプロダクトオーナーをやっています。きょうはブログ運営チームの一員として、この記事を書いています。 この記事のエッセンスとしては「やったこと」と「将来」をお読みいただければ十分ご理解いただけることと思います。「背景」は読み物としてお楽しみください。 やったこと 2026年6月末に、このブログのCSSに次の指定を入れました。 .entry-content p , .entry-content ul , .entry-content ol { text-autospace: normal ; } 本文について、和文と欧文（数字含む）の間に細い空白（八分アキ。厳密には「水」の8分の1の幅の空白）が自動的に挿入されます。これにより、記事がより読みやすくなりました。 こちらが変更前後のイメージです。「NTT」や「2015年6月」などに特徴が出ます。この処理は対象とする文字種の選択がかなり工夫されていて、必要のない位置、例えば句読点や括弧と欧文の組み合わせでは空白が入らないようになっています。 コードスニペットや本文以外の要素（見出し、カテゴリー、右サイドパネルなど）にはこの指定をしていませんので、従来通り詰め組みになります。本文以外の要素を対象外としたのは、長文で構成されるのがまれなこと、また1画面にできるだけ多くの内容を詰めた方がよい要素だと判断したことによります。 text-autospaceは、Baseline 2025に収録されており、2025年11月以降主要なWebブラウザーでサポートされています。詳しいリファレンスは次を参照してください。 背景 背景について述べるには、印刷の話を少ししないといけません。 印刷の分野において、日本語の文（和文）に西洋言語の文（欧文）を混ぜてレイアウトすることを和欧混植といいます。和文と欧文の組版はそれぞれ異なる文化を取り込んで成長してきました。代表的なところでは次の表に述べるような差があります。 特徴 和文 欧文 使う文字の形 正方形 幅も高さもまちまち 文字の並べ方（組み方） 隙間を空けずきっちり並べる（ベタ組み） 1単語を構成する字は隙間なく並べ、単語の区切りに空白を入れる 1行の文字数 和文のみであれば常に一定 かなりまちまち 行揃え 字の大きさを変えない限り、自動的に行頭行末が揃う 単語間の空白の量を行ごとに調整して両端揃え（箱組み）にするか、左だけ揃えて右を揃えない 本文における行間 字の高さの25％から75％程度空ける まったく空けないこともある こうした異なる文化を持つ組版の作法をいかに融合させるか、過去からさまざまな試行錯誤がされてきました。その成果として、多くの横書きの印刷物では和文と欧文の間には四分アキ（全角文字の4分の1の幅の空白）を挿入するのがスタンダードになっています（この空白を和欧文語間といいます）。和文と欧文では文字のデザイン手法に差があることから、ぴったり詰めて組むと詰まった印象を受けるためとされています。 ちなみにMicrosoft Wordにおいて、和文と欧文の間に自動的に入る見た目上の空白もこれが理由です。pTeXに起源を持つ日本語TeX処理系も同様で、TeXソースコードにおいてこの目的のために故意に空白文字を入れるのはよろしくないとされています（その自動調整が作用しなくなるため）。 こうした和欧混植を含め、日本語の印刷物の組版（レイアウト）をいかにしてなすべきかについての標準として、「JIS X 4051 日本語文書の組版方法」が存在します。これをベースにしたW3C Working Group Noteとして Requirements for Japanese Text Layout （日本語組版処理の要件） が提供されています。その序論に、この文書をリリースするに至った目的が端的に記されていますので、引用します。 すべての文化集団は，独自の言語，文字，書記システムを持つ．それゆえ，個々の書記システムをサイバースペースに移転することは，文化的資産の継承という意味で，情報通信技術にとって非常に重要な責務といえよう． この責務を実現するための基礎的な作業として，この文書では，日本語という書記システムにおける組版上の問題点をまとめた．具体的な解決策を提示することではなく，要望事項の説明をすることにした．それは，実装レベルの問題を考える前提条件をまず明確にすることが重要であると考えたからである．《日本語組版処理の要件（日本語版）　序論 この文書の目的より》 「日本語組版処理の要件」では、和欧文語間のように行内の文字の組み方に限らず、印刷物の基本となる体裁、見出しの取り方、ルビ（ふりがな）の付け方などについても広範に論じられています。 ちなみに「日本語組版処理の要件」が基本となって、昨今電子書籍市場で広く使われるフォーマット “EPUB” の日本語対応が進みました。EPUB 3では縦書きやルビといった日本語ならではの表現に対応し、日本の商業出版における電子書籍（特にリフロー対応）の市場拡大につながりました。「日本語組版処理の要件」がEPUBの日本語対応にどのような役割を果たしたか、当時関わった方々が述懐されていますので興味ある方は覗いてみてください。 今回のtext-autospaceの実装に関しても、「日本語組版処理の要件」が参照されたと聞いています。このほか、ルビの表示方法などいくつかW3Cで議論されているテーマがあるそうです。 わたしにとってWebの原体験は「Internet Explorer上で詰め組みにされたＭＳ Ｐゴシック」とともにあったので、今回CSS仕様に日本語文書に由来する表現手法が盛り込まれたことにはちょっとした感動を覚えました。時代を遡れば日本語の文字がWebブラウザー上に表示されているだけでもすごい時代があったのだと思いますが、時代が下るにつれてより高度な、より文化固有の表現を実現したくなるのは当然の要望であり、こうした先人の足跡にはただ頭が下がります。 将来 このブログでは、従来和欧文語間（空白）に関する規則がなかったため、和欧文間が詰めてある記事と空白 (U+0020) が入れてある記事とが混在しています。今後リリースされる記事ではこの目的での空白挿入は禁止しますが、従来記事の修正は積極的には行わない方針です。 ただ、text-autospaceには興味深い指定 replace があります。リファレンスでは「表意文字と非表意文字の間の既存の空白（例：U+0020）を、指定した間隔で置き換えます」と説明されており、上記のような記事をレンダリング時に補正して見た目を整えられるようになります 1 。 利点はそればかりではありません。例えば アドベントカレンダー 3 日目の記事です のように空白入りで書かれている記事の場合、現状Webブラウザーのページ内検索機能では空白なしの 3日目 と検索するとヒットしません。これが replace によって、素直に入力した文字列で検索できるようになることが期待されます。 ただ2026年7月時点では、 replace は punctuation と並んでどのWebブラウザーでもサポートされていないため、導入は将来への宿題としておきます。 お読みいただきありがとうございました。今後もこうした改善を通じて、読者のみなさまによりよい環境をお届けできればと思います。 余談ですが、Unicodeには空白とされる文字が25種類あるのですよね（参考： 空白文字 - Wikipedia ）。 ↩

レバレジーズで AWS AI-DLC Unicorn Gym を実施しました レバレジーズでは、開発プロセスにAIをより深く組み込む取り組みの一つとして、AWS AI-DLC Unicorn Gymを実施しました。 これまでAI活用というと、実装補助やコード生成、ドキュメント作成など、個人の生産性向上に寄った使い方が中心でした。 一方で、実際のプロダクト開発では、要件定義、仕様のすり合わせ、デザイン、実装方針の決定など、チームで意思決定する場面が多くあります。 今回のAI-DLCでは、AIを単なる作業補助ではなく、チーム開発のプロセスそのものに組み込むことを目的に、PdM、デザイナー、エンジニアが一緒に参加し、実際のプロダクト課題を題材に3日間取り組みました。 この記事では、AI-DLCの概要、当日の進め方、参加チームの感想、そして推進者として感じた手応えを紹介します。 AI-DLCとは AI-DLCは、AWSが提唱するAI駆動開発ライフサイクルです。※1　AIを単なるコード生成ツールとして使うのではなく、要件整理、作業計画、仕様検討、実装、レビューといった開発ライフサイクル全体に組み込み、人間が重要な判断を行いながらAIと協働して開発を進める考え方です。 ※1：Amazon Web Services,Inc.：AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築（ https://aws.amazon.com/jp/blogs/news/ai-driven-development-life-cycle/?utm_source=chatgpt.com ） 今回のイベントでは、各チームが実際のプロダクト課題を持ち寄り、AIとの壁打ちを通じて要件や仕様を整理しながら、最終的な成果物の作成を目指しました。 当日の流れ 1日目 1日目の午前中は、AI-DLCの考え方や進め方を学ぶ時間でした。 午後からは各チームに分かれ、実際のプロダクト課題を題材にしながら、ユーザーストーリーの作成を進めました。 最初は、AI-DLCとしてどのように進めればよいのかを掴みきれておらず、これまでの開発と同じように人間中心で議論を進めてしまう場面もありました。 ただ、AWSの皆さまからAI-DLCとしての動き方や、AIをどのタイミングでどう活用していくかをアドバイスいただくことで、少しずつAIを開発サイクルの中に組み込んだ進め方に変わっていきました。 この日のゴールは、AI-DLCの進め方を理解したうえで、各チームが扱うテーマをユーザーストーリーとして整理することでした。 2日目 2日目は、1日目に作成したユーザーストーリーをもとに、開発対象を具体的な作業単位に落とし込む Unit of Work の作成を進めました。 また、14時からは中間報告会を実施しました。各チームがどこまで進んでいるのか、どこで詰まっているのか、どのようにAI-DLCを進めているのかを共有し、チーム間でナレッジを交換する時間になりました。 2日目になると、各チームともAI-DLCの進め方に少しずつ慣れてきました。1日目は人間が考えた内容をAIに補助してもらうような使い方が中心でしたが、徐々にAIに問いかけてもらいながら論点を整理したり、AIに案を出してもらったうえでチームで判断したりする動きが増えていきました。 この日のゴールは、ユーザーストーリーをさらに具体化し、実装に着手できる状態まで進めることでした。 3日目 3日目は、17時からの成果発表会に向けて、各チームが成果物の作成を進めました。 最終日ということもあり、限られた時間の中で成果物を形にしなければならないプレッシャーもありました。その中で各チームは、要件整理や実装方針の確認だけでなく、実装や発表準備にもAIを積極的に活用しながら開発を進めていました。 1日目と比べると、AIを「必要なときに使うツール」としてではなく、開発を前に進めるためのチームメンバーのように扱う場面が増えていたように感じます。 最後に成果発表会を行い、各チームが作成したユーザーストーリー、Unit of Work、プロトタイプ、AI-DLCを通じて得られた学びを共有しました。 感想 ここからは、実際にAI-DLCに参加した各チームの感想を紹介します。チームごとに題材や進め方は異なりましたが、それぞれの立場からAI-DLCを通じて感じたことをまとめています。 teratail teratailでは、以前から仕様駆動開発を試した経験がありました。そのときは、人間が仕様を考え、AIが実装するというスタイルでした。 一方で、AI-DLCでは仕様を作成する段階からAIが質問を投げかけ、PdM・デザイナー・開発者が全員で意思決定していく点に新しさを感じました。 AI-DLCのよかった点は、議論の過程と意思決定が自然とドキュメントに残っていくことです。フェーズが進んでも、なぜその設計にしたのかを辿れる安心感がありました。 一方で、今回はUI/UXの刷新という大きなテーマだったため、意思決定の量が膨大になり、判断が追いつかない場面もありました。今後は、ドキュメントをHTML/CSSで整形したり、図式化したりして読みやすくすることや、レビュー観点自体をAIに整理させることなど、人間が判断しやすくする工夫が必要になりそうだと感じました。 レバテックプラットフォーム レバテックプラットフォームチームでは、今回はUX改善も含めたシステムリプレイスを題材にAI-DLCを行いました。 これまでの開発では、ディレクターや開発PMなど一部のメンバーで要件を決め、それを他メンバーに共有する進め方が中心でした。 AI-DLCでは、Inceptionフェーズにメンバー全員で要件定義を実施することで、要件の認識合わせにかかるリードタイムが短くなり、認識齟齬による手戻りも減らせたように感じます。 一方で、既存のレガシーシステムの仕様を明らかにするのに時間がかかりました。新規機能開発と比較すると、既存システムのコンテキストを事前に整備しておくことが重要だと感じました。今後チームでAI-DLCに取り組むうえでも、コンテキスト整備は重要になりそうです。 レバテックダイレクト レバテックダイレクトチームでは、チーム一丸となって取り組んでいる感覚が強く、メンバー全員で楽しく実施することができました。また、議論や意思決定の内容がドキュメントとして自然に残っていく点もよいと感じました。 一方で、今回は完成まで至らなかったため、結果としてうまくいったと言い切るのは難しい部分もあります。ただ、普段よりも細かく合意形成を行えたことで、常にチーム内の認識を揃えながら進められた点はよかったです。 うまくいかなかった点としては、モック作成後に後追いでデザインを作成したため、手戻りが発生してしまったことがあります。また、役割によって忙しい時間と待ち時間に差が出てしまう場面もありました。 チームとして取り入れる場合、要件を詰め、デザインが固まった後にAIにコードを書かせる進め方がよいのか、それとも要件やデザインが完全に固まっていない状態でも、まずAIにコードを書かせ始める進め方がよいのかは、まだ判断が難しいと感じています。前者が正しい進め方であれば、AI-DLCは非常に有効に使えると思いました。 レバテックルーキー レバテックルーキーチームでは、当初は抽象的なアイデアからのスタートでしたが、AIにチェックリストの作成や問いかけを促すことで、今までにないアプローチを試すことができました。 AIとの壁打ちを通じて、イメージが徐々に具体化し、思考がクリアになっていくプロセスの有用性に驚きました。 開発面では、モバイルアプリチームが先行してAI-DLCを導入していたため、その知見を活かすことで非常にスムーズに進めることができました。一方で、「どのフェーズで、どこまで具体的な指示を出すべきか」「どのタイミングで既存のリポジトリやコード情報をAIにインプットさせるべきか」といった、コンテキスト共有の粒度とタイミングのコントロールには課題が残りました。 現在、当チームでは開発スタイルの刷新を進めています。具体的には、ストーリーワークショップ、PBR、タスク分解、プランニングポーカーの進め方を見直し、AI-DLCを実践するための枠組みへ移行しています。 なお、デイリー、プランニング、レトロスペクティブなどの各種スクラムイベントは継続します。これにより、継続的なコミュニケーション、優先度の決定、成果物報告、振り返りのプロセスは維持していく方針です。 AI推進者: 苑田 AI-DLCを通して、チームメンバーがAIを前提に開発を進めている感覚を共有でき、個人的にも実施してよかったと感じました。 私は推進者なので実際には手を動かしていないのですが、PdM、エンジニア、デザイナーの3職種のチームを横で見ていて、ものすごく手応えを感じました。論点の洗い出しや初期案の作成をAIに任せることで、人間はゼロから考える時間よりも、選択・判断・修正に時間を使えるようになりました。その結果、議論の立ち上がりが早くなり、開発スピードが上がった感覚があります。 特に、長時間席を離れる際も、「AIにタスクを渡してからご飯行こうか」というやり取りが見られたのは、AI推進者としてもすごく印象的でした。 AI-DLCは単に開発サイクルを良くするだけではなく、AIに対する認識自体を変えるすごくいい方針だなと思ったので、これからも推進していきたいです！ 推進者: 山川 全チームで AI を使う範囲を広げようとする行動が多くなり、推進者としてとても嬉しく思います。 参加したチームからは、1つのイベント参加に留めず、今後も継続して取り組んでいこうとする動きも生まれてきました。例えば、開発プロセスやスクラムイベントの見直し、チーム関係者との業務調整、他チームへのコーチング、リモートワークでどうやって導入するか、などを自律的に検討しながら進められており、AI-DLCへの大きな期待を感じます。 今回の AWS AI-DLC Unicorn Gym 実施に向けて、推進者として調整や準備などは大変だったものの、チームや組織に大きな動きが生まれて開催してよかったと思います。今後は、より多くのチームが AI-DLC を体験して導入していけるように、社内イベントの開催といった推進活動にも注力していければと思います。 まとめ 今回のAI-DLCは、単に新しい開発手法を試すイベントというより、レバレジーズとしてAIを開発プロセスにどう組み込んでいくかを考える良い機会になりました。 実際に複数のチームで取り組んでみることで、AI-DLCは「決まった手順をそのまま導入すれば終わり」というものではなく、チームの体制、扱うプロダクト、既存システムの複雑さ、関わる職種によって、最適な進め方を調整していく必要があることも分かりました。 一方で、AIを開発の一部として自然に使う体験をチームで共有できたことは、今後のAI活用を広げていくうえで大きな意味があったと感じています。個人の作業効率化にとどまらず、チームでの認識合わせや意思決定、開発プロセスの見直しにまでAI活用の範囲を広げられる可能性が見えてきました。 今回得られた学びをもとに、今後は各チームの開発スタイルに合わせたAI-DLCの取り入れ方を整理し、より実践しやすい形で社内に展開していきたいです。 We are hiring! 最後までお読みいただき、ありがとうございました。レバレジーズでは、AIを個人の作業支援にとどめず、チームの開発プロセスに取り入れる取り組みを進めています。こうした取り組みに興味を持っていただけた方は、ぜひ採用情報もご覧ください。 HRMOS求人ページ 会社説明資料