「導入しても使われない」を解決する ― 三菱電機電力ICTセンターが Kiro と GitLab で実現した開発ワークフローの標準化

本ブログは、三菱電機株式会社電力システム製作所電力ICTセンター小森様と、アマゾンウェブサービスジャパン合同会社ソリューションアーキテクト稲田、GitLab 合同会社ソリューションアーキテクトの小松原様の共著です。三菱電機電力ICTセンターにおける Kiro と GitLab を組み合わせたソフトウェア開発効率化の取り組みについてご紹介します。

電力ICTセンターについて

三菱電機電力システム製作所電力ICTセンターは、再生可能エネルギーの拡大や電力自由化に対応する電力×ICTの専門組織です。電力取引・需給管理から、分散型電源/VPP、蓄電池制御、スマートメーター、託送・精算、環境価値管理、アセットマネジメントまで、電力事業全体をカバーする主力ソリューション「BLEnDer（ブレンダー）」を開発しています。BLEnDer を軸に電力の”見える化→判断→計画→制御”を一気通貫で実現する電力デジタルソリューションを提供し、電力会社様、送配電事業者様、小売電気事業者様、発電事業者様など、幅広い事業者様を支えています。

これまでの取り組みと課題

電力ICTセンターでは、ソフトウェア開発の効率化に向けてさまざまな取り組みを行ってきました。

GitLab をベースにした CI/CD 環境の構築
Amazon Bedrock を活用した RAG システムの開発（開発工数見積もりの支援）
Amazon Bedrock を活用した設計書レビューの効率化
CI/CD ツールを活用したビルド・テスト・デプロイ作業の効率化
ワークフロー自動化ツールを活用した申請フローの自動化

これらのシステムやツールはそれぞれ開発効率化に寄与していますが、導入・展開時に共通の課題がありました。

開発したシステムやツールは、基本的に納入先の開発チームに運用・保守を担っていただきます。そのため、利用方法を示したドキュメントや設計ドキュメントの作成、利用フローの整備が不可欠です。時には勉強会を開催し、必要なスキルを習得していただく必要もありました。しかし、毎回フルセットで伴走支援を行うことは現実的ではなく、ドキュメントや勉強会だけで実践していただくには限界があると感じていました。

「ドキュメントを読まなくても、AI に聞けばワークフローに沿った開発ができる」 ― そんな仕組みを実現するために、Kiro と GitLab を組み合わせた新しいアプローチに取り組んでいます。

Kiro の Steering・Powers・MCP とは

本題に入る前に、今回の取り組みで活用している Kiro の主要機能について説明します。

Steering：プロジェクト横断のグラウンドルール

Steering は、Kiro の振る舞いに対して常に適用されるグラウンドルールを定義する仕組みです。プロジェクトのルートディレクトリに .kiro/steering/ ディレクトリを作成し、マークダウンファイルでルールを記述します。

.kiro/
└── steering/
    ├── coding-standards.md    # コーディング規約
    ├── language.md            # 言語設定（日本語で回答する等）
    └── security.md            # セキュリティポリシー

Steering に記述したルールは、どの Power が発動しているかに関わらず常に Kiro のコンテキストに読み込まれます。そのため、「日本語で回答すること」「機密情報をコードに含めないこと」といった、プロジェクト全体で一貫して守るべきルールの定義に適しています。

電力ICTセンターでは、プロジェクト固有ではない共通のグラウンドルール（言語設定、コーディング規約の基本方針など）を Steering で管理しています。

Powers：動的に呼び出されるワークフロー定義

Powers は、Steering とは異なり、ユーザーの発話内容に応じて動的に呼び出されるルール定義の仕組みです。Power は POWER.md というメタデータファイルと、steering/ ディレクトリ配下のステアリングファイル群で構成されます。

.kiro/powers/
└── my-power/
    ├── POWER.md          # Power のメタデータ（name, description, keywords）
    ├── mcp.json          # この Power 専用の MCP サーバー設定（任意）
    └── steering/
        ├── guide-a.md    # ステアリングファイル A
        └── guide-b.md    # ステアリングファイル B

POWER.md の frontmatter には keywords を定義でき、ユーザーの発話にこれらのキーワードが含まれると、その Power が動的に発動します。

---
name: "standard-dev-flow"
displayName: "Standard Dev Flow"
description: "GitLab を使用した開発ワークフローを標準化する Power"
keywords: ["イシュー", "ブランチ", "コミット", "MR", "マージリクエスト", "レビュー", "パイプライン", "実装"]
---

Steering との使い分けのポイントは、コンテキストウィンドウの効率です。Steering は常に読み込まれるため、大量のルールを定義するとコンテキストを圧迫します。一方、Powers は必要なときだけ動的に読み込まれるため、ワークフロー固有の詳細なルール（数千行に及ぶガイドラインなど）を定義しても、関係ないタスクの際にはコンテキストを消費しません。

電力ICTセンターでは IDE での利用が多く、IDE 上で Power が動的に呼び出されていることを視覚的に確認できる点に安心感を感じています。「いま Kiro がどのルールに従って動いているか」が見えることで、AI の振る舞いを制御できている実感が得られます。

Kiro から Power を呼び出すイメージ

MCP（Model Context Protocol）：外部ツールとの連携

MCP は、Kiro が外部のツールやサービスと連携するためのプロトコルです。MCP サーバーを定義することで、Kiro が GitLab API の操作や独自のスクリプト実行など、IDE の外にある機能を呼び出せるようになります。

Power ごとに mcp.json を配置できるため、特定のワークフローでのみ必要な MCP サーバーを、その Power に紐づけて管理できます。例えば、Standard Dev Flow Power には GitLab 操作用の MCP サーバーを、Playwright Power にはテスト実行用の MCP サーバーを、といった使い分けが可能です。

3 つの機能の関係性

まとめると、以下のような役割分担になります。

機能	適用タイミング	用途
Steering	常時	プロジェクト横断のグラウンドルール
Powers	キーワードに応じて動的	ワークフロー固有の詳細ルール・手順
MCP	Power に紐づけて動的	外部ツール・API との連携

この3層構造により、「常に守るべきルール」「タスクに応じて必要なルール」「外部ツールとの連携」を整理して管理でき、コンテキストウィンドウを効率的に活用しながら AI エージェントの振る舞いを制御できます。

現在の取り組み：Kiro × GitLab による開発プラットフォーム

全体像

現在、CI/CD を中心としたソフトウェア開発サイクル全体の効率化に取り組んでいます。

開発ワークフローの整理（ブランチ戦略・リリース戦略を含む CI/CD 環境の整備）
アプリケーションのデプロイ方法の検討、テスト自動化環境の整備
GitLab CI/CD カタログを活用したパイプラインの標準化
ガイドラインの整備

これらの取り組みにおいて、Kiro と GitLab をどのように活用しているかをご紹介します。

Kiro の活用：Powers による開発ワークフローの標準化

Kiro では 2 つの Power (Standard Dev Flow Power, Playwright Power) を利用しています。それぞれについて解説します。

その 1: Standard Dev Flow Power

開発ワークフロー全体を標準化する Power を作成しました。以下のワークフローを Kiro に定義しています。

1. Issue 作成 → 2. ブランチ作成 → 3. 実装 → 4. コミット → 5. MR 作成 → 6. レビュー → 7. マージ

この Power には、各フェーズに対応するステアリングファイルが含まれています。

standard-dev-flow/
├── POWER.md                              # Power 定義（ワークフロー全体像）
├── mcp.json                              # MCP サーバー設定
└── steering/
    ├── issue-management.md               # Issue 作成ガイド
    ├── branch-commit-mr.md               # ブランチ・コミット・MR作成ガイド
    ├── implementation.md                 # 実装作業ガイド
    ├── gitlab-duo-review.md              # GitLab Duo レビューワークフロー
    ├── pipeline-troubleshooting.md       # パイプライン失敗解析ガイド
    └── gitlab-official-mcp-tools.md      # GitLab 公式 MCP ツールリファレンス

POWER.md にはワークフローの全体像と各ステアリングファイルの参照タイミングを記述しています。例えば、「新しい Issue を作成する際は issue-management.md を参照」「パイプラインが失敗した際は pipeline-troubleshooting.md を参照」といった形で、Kiro がどのフェーズでどのルールを適用すべきかを明示しています。

各ステアリングファイルには、そのフェーズで Kiro が従うべき具体的なルールが記述されています。例えば branch-commit-mr.md には以下のようなルールが含まれます。

ブランチ命名規則：feature/{issue-number}-{brief-description} 形式
Conventional Commits 1.0.0 準拠のコミットメッセージ（type/scope/description/body の構造化、日本語での記述）
MR 作成時の squash merge による 1 コミットへの集約
MR テンプレート（変更内容/テスト/レビュー観点/補足）に基づいた記述

開発者は Kiro に「Issue #123 の実装を開始してください」と伝えるだけで、Power に定義されたワークフローに沿って作業が進みます。Kiro は自動的に以下を実行します。

ブランチの確認・切り替え
Issue の内容確認と tmp/{タスク名}-issue-details.md の作成
実行計画の作成（tmp/{タスク名}-plan.md）
実装作業の実施
作業サマリーの作成（tmp/{タスク名}-summary.md）

このように、作業の追跡ファイルを自動生成する仕組みも Power に組み込んでいます。Issue の詳細理解、チェックリスト形式の実行計画、作業完了後のサマリーを tmp/ ディレクトリに残すことで、作業の透明性を確保しています。

Standard Dev Flow Power には、GitLab 公式 MCP サーバーと独自の MCP サーバーの両方を mcp.json で定義しています。

GitLab 公式 MCP サーバーが提供する主なツール：

create_issue / get_issue：Issue の作成・取得
create_merge_request / get_merge_request：MR の作成・取得
search / semantic_code_search：検索機能

独自 MCP サーバー（GitLab MCP Enhancer）で補完しているツール：

get_mr_discussions / reply_to_discussion / resolve_all_discussions：MR ディスカッション操作
list_merge_requests / update_merge_request：MR の一覧・編集
list_issues / update_issue / add_issue_note：Issue の一覧・編集
get_latest_pipeline / get_pipeline_jobs / get_job_log：パイプライン解析

この 2 つの MCP サーバーを組み合わせることで、Issue 作成から MR レビュー対応、パイプライン失敗の解析まで、GitLab の操作をほぼ Kiro 上で完結できるようになりました。

その 2: Playwright Power

次のステップとして、Playwright を活用した E2E テスト生成のための Power も作成しています。

playwright/
├── POWER.md                              # Power定義
└── steering/
    ├── playwright-rule.md                # コーディング規約・POM変換手順
    ├── playwright-cli.md                # playwright-cli の使い方
    └── test-best-practices.md            # テスト実装のベストプラクティス

この Power のポイントは、playwright-cli の出力から Page Object Model（POM）への変換手順をステアリングファイルに詳細に定義している点です。playwright-cli はコーディングエージェント向けに設計された CLI ベースのブラウザ自動化ツールで、操作ごとに Playwright コードを出力します。

playwright-rule.md には、この出力コードから POM クラスへ変換する 3 ステップの手順が定義されています。

ロケーター抽出：出力コードから要素を特定
readonly 定義：コンストラクタでロケーターを宣言
アクションメソッド：操作をメソッドに抽象化

さらに、ロケーター戦略の優先順位も明確に定義しています。

getByRole() – ボタン、リンク等のセマンティック要素
getByLabel() – フォーム要素
getByPlaceholder() – プレースホルダーテキスト
getByText() – 表示テキスト
getByTestId() – テスト専用属性
CSS/XPath – 最後の手段

test-best-practices.md には、AAA パターン（Arrange/Act/Assert）によるテスト構造化、アサーション強化（toBeVisible() だけでなく toHaveText() で内容確認）、テスト安定化テクニック（スピナー待機、古い DOM の回避）など、実践的なベストプラクティスが記述されています。

これらのルールを Power に落とし込むことで、誰が Kiro にテスト生成を依頼しても、組織のベストプラクティスに沿った一貫性のあるテストコードが生成されます。

GitLab の活用

GitLab Pages によるガイドライン公開

プラットフォームを他 BU に展開するにあたり、ガイドラインの整備は不可欠です。GitLab Pages を活用し、マークダウンで記述したガイドを静的 Web サイトに変換して公開しています。ガイドには、GitLab CI/CD カタログを活用した標準パイプラインの説明や、GitLab Duo や Kiro の基本的な使い方や Tips を掲載しています。関連するソースコードはすべて GitLab で管理しており、ソースコードの修正があれば生成 AI を活用して即時にガイドに反映・公開できるため、管理の手間を感じません。

ここで重要なのは、Powers には基本的にガイドに書いてあることをそのまま落とし込んでいるという点です。これにより、ガイドの内容と AI の振る舞いが常に一致し、「ガイドを読む」か「AI に聞く」かのどちらでも同じ情報にたどり着ける状態を実現しています。

GitLab Pages の利用イメージ

CI/CD カタログによるパイプラインの標準化

GitLab CI/CD カタログを作成し、アーティファクトやキャッシュの設定を含むパイプラインテンプレートを配布しています。ユーザー側は環境固有のパラメータ値のみを入力すれば、即座に使用可能な状態です。

GitLab Duo による MR レビュー：AI 同士の協働

Kiro でコーディングを行い、MR を作成した後、GitLab Duo にレビューを依頼するワークフローを構築しています。

生成 AI は自分で生成したコードに対して正しいという認知バイアスがかかる可能性があるため、コード生成（Kiro）とレビュー（GitLab Duo）を異なる AI に担当させることで、より客観的なレビューを実現しています。

GitLab Duo へのレビュー観点は、社内の有識者を交えて mr-review-instructions.yaml に定義しており、レビューコメントに必ず prefix（接頭辞）を付けるルールを設けています。この prefix により、レビュー指摘の重要度が一目で判断できるようになります。

instructions:
  - name: Common Review Policy
    fileFilters:
      - "**/*"
    instructions: |
      - **言語**: すべての応答は必ず日本語で行ってください
      - レビューする際には、以下のprefix(接頭辞)を必ず付けてください
        - [must] → 必須修正、修正しないのであれば修正しない理由を開発者に求める
        - [want] → できれば対応してほしい、改善として望ましい提案
        - [imo]  → 個人的意見、好みベースの提案
        - [ask]  → 質問、意図・背景の確認
        - [nits] → 細かい指摘(nitpicks)、超軽微なスタイル修正など
        - [info] → 参考情報、共有・補足・関連情報

一方、Kiro 側の Power（gitlab-duo-review.md）には、GitLab Duo のレビュー結果をどう受け取り、どう対応するかのルールを定義しており、GitLab Duo が付与する prefix に対して、Kiro がどのように判断・行動すべきかを明示しています。

・・・

### 2. GitLab Duoにレビュー依頼
**重要**: GitLab Duoのレビューは**新規ディスカッション**で`@GitLabDuo`をメンションすることで発動する。MR作成時のdescriptionに記載しても発動しない。
**レビュー依頼のポイント**:
- 新規ディスカッションを作成する（これが必須）
- `@GitLabDuo`はスペースなしで記載
- 依頼メッセージには以下を含めると効果的：
  - 実装内容の概要
  - 特に確認してほしい点
  - 変更理由や背景
  - 参考資料: 関連ドキュメント
### 3. レビュー結果確認
**レビューコメントのprefix（重要度の判断基準）**:
GitLab Duoのレビューには以下のprefixが付与される。これを基に対応の優先度を判断する。
| Prefix | 意味 | 対応方針 |
|--------|------|----------|
| `[must]` | 必須修正 | 修正必須。対応しない場合は理由を説明 |
| `[want]` | できれば対応 | 改善として望ましい。可能な限り対応 |
| `[imo]` | 個人的意見 | 好みベースの提案。採用は任意 |
| `[ask]` | 質問 | 意図・背景の確認。回答が必要 |
| `[nits]` | 細かい指摘 | 超軽微なスタイル修正。余裕があれば対応 |
| `[info]` | 参考情報 | 共有・補足・関連情報。対応不要 |
**[ask]への対応**:
`[ask]`が付いた質問には、該当ディスカッションに`@GitLabDuo`メンション付きで返信して不明点を解消する。
・・・

[ask] が付いた質問には、該当ディスカッションに @GitLabDuo メンション付きで返信して不明点を解消するルールも定義しています。

また、GitLab Duo へのレビュー依頼方法についても Power に明記しています。GitLab Duo のレビューは MR の description に記の最後に /assign_reviewer @GitLabDuo を記載することで発動します。こうした「知らないとハマるポイント」も Power に落とし込むことで、開発者が試行錯誤する手間を省いています。

以上を踏まえた、Kiro と GitLab Duo の協働ワークフローは以下の通りです。

Kiro で機能を実装し、MR を作成
GitLab Duo に MR レビューを依頼（MCP 経由）
レビュー指摘を Kiro が取得し、対応可否を判断
対応が必要な指摘に対してコード修正を実施
修正をコミット・プッシュし、再度 GitLab Duo にレビューを依頼
承認後、全ディスカッションを一括解決

この AI 同士の協働によるレビューサイクルにより、ある程度のクオリティが担保された状態で人間のレビュアーが入ることで、レビュー負担の軽減が期待できます。

この構成のメリット

1. 導入ハードルの大幅な低下

Power を活用して開発フローを定義しているため、開発者は Kiro に質問しながら作業を進めるだけで、ワークフローに沿った開発を行うことができます。分からないことは Kiro に質問して解決できるため、Kiro の基本的な使い方を覚えるだけで開発を始められます。BU への展開時に「AI がサポートしてくれるし、ガイドを特に読む必要はないよ」と伝えるだけでハードルがぐっと下がります。

2. 開発の証跡とコラボレーション

Issue や MR で開発の証跡を残すことで、他の開発者とのコラボレーションが容易になります。Issue を追うことで、別の開発者が作業を引き継ぐことも容易になると考えています。

3. レビュー負担の軽減

コード開発の速度が上がる一方で、レビュー者への負担が増大するリスクがあります。GitLab Duo での観点に基づいたレビューと CI/CD パイプラインの実行結果を Kiro にフィードバックさせて改善することで、人間のレビュアーが入る前にある程度のクオリティを担保できます。人間のレビュー疲れやレビュー工数の削減にも寄与することを期待しています。

工夫した点と苦労した点

1 : Power の発動率を上げる工夫

Power に keywords を設定して呼び出しの工夫をしましたが、期待通りに発動しないケースがありました。例えば、Standard Dev Flow Power には ["イシュー", "ブランチ", "コミット", "MR", "マージリクエスト", "レビュー", "パイプライン", "実装"] といったキーワードを設定していますが、ユーザーの発話がこれらのキーワードに完全に一致しない場合、Power が発動しないことがありました。

調査の結果、Power を積極的に活用するよう促す Steering ファイルを作成することで、利用率が向上しました。Steering は常にコンテキストに読み込まれるため、「利用可能な Power がある場合は積極的に活用すること」というルールを Steering に記述することで、Power の発動率を改善できます。AI エージェントツールを組織で活用する際には、こうしたチューニングが重要になります。

2: GitLab 公式 MCP サーバーの補完

GitLabの良さはそのカスタマイズ性の高さにあります。公式 MCP サーバーを補完する独自の MCP サーバー（GitLab MCP Enhancer）を自作しました。gitlab-official-mcp-tools.md というステアリングファイルに公式 MCP サーバー（Beta 版）の全 14 ツールのパラメータ定義と使用例を記述し、Kiro が正しくツールを使えるようにガイドしています。これによりMR ディスカッションの取得・返信・解決、Issue の一覧・編集、パイプラインのジョブログ取得など、 GitLab の操作が大幅に向上し、ほぼ Kiro 上で操作を完結できるようになりました。

今後の展望

直近では、現在作成中の Playwright Power を完成させ、E2E テスト生成の効率化を推進していきます。また、Playwright Power と並行して、SonarQube の MCP サーバーを活用し、静的解析結果を Kiro にフィードバックする仕組みの構築も検討し始めました。これにより、コードレビュー時だけでなく、実装段階からコード品質を高めるための仕組み作りにも取り組んでいます。このように、組織で活用が見込まれる OSS の活用を推進する Power を順次作成し、AI を活用してソフトウェア開発が楽になる土壌を広げていく方針です。また、GitLab Duo のレビュー観点も継続的に育てていき、適用範囲を広げることでレビュー負担のさらなる軽減を目指します。

1 : 効果の定量化と継続的な改善

AI 活用による開発効率化の効果を可視化するため、定量的な評価指標の測定に取り組んでいきます。Issue からマージまでのリードタイムやレビューイテレーション回数といった開発速度の指標、GitLab Duo のレビュー指摘の精度、Kiro の Playwright Power で生成されるコードの品質などを、実際に各ビジネスユニット (以降、BU)で使用していただきながら評価していきます。これらのフィードバックを基に、Power のルール定義の改善や MCP サーバーの機能拡張など、継続的な改善サイクルを回していきます。

2 : Power とパイプラインのエコシステム構築

Power や CI/CD パイプラインを組織全体で活用していくため、バージョン管理と配布の仕組みを構築していきます。GitLab で Power/MCP や CI/CD パイプラインテンプレートを一元管理し、GitLab Pages で導入方法・アップグレード方法を公開します。バージョン更新時には更新ダッシュボードでユーザーに通知し、各 BU からの要望は Issue やチケットで収集して継続的に改善します。また、既存の管理システムとの連携も視野に入れ、障害報告から修正、リリースまでの開発サイクル全体の効率化を図ります。

3 : 組織全体への展開とコミュニティ形成

中長期的には、電力ICTセンター内の各 BU への展開を加速させていきます。積極的な情報発信を通じて周囲を巻き込みながら、地道に活用の輪を広げていきます。Power やルール整備の取り組みは電力ICTセンターに閉じた話ではないため、ゆくゆくは三菱電機全社的な取り組みとして認知され、活用方法について議論できるコミュニティが形成されることを目指しています。まずは足元の電力ICTセンターのソフトウェア開発効率化につながる活動をどんどん進めていきたいと考えています。

まとめ

三菱電機電力ICTセンターでは、Kiro の Steering・Powers・MCP と GitLab の各機能を組み合わせることで、「AI に聞けばワークフローに沿った開発ができる」 プラットフォームの構築を進めています。

この取り組みの本質は、単なるツール導入ではありません。

Steering でプロジェクト横断のグラウンドルールを定義し
Powers でワークフロー固有の詳細なルール・手順を動的に呼び出し
MCP で GitLab をはじめとする外部ツールとシームレスに連携する

この 3 層構造により、ガイドラインの内容を Powers に落とし込み、GitLab Pages で公開するガイドと AI の振る舞いを一致させることで、ドキュメントを読んでも AI に聞いても同じ結果にたどり着ける仕組みを作っています。さらに、Kiro によるコード生成と GitLab Duo によるレビューという AI 同士の協働により、人間のレビュー負担を軽減しながら品質を担保するワークフローを実現しています。

ソフトウェア開発の効率化は、ツールの導入だけでは完結しません。開発ワークフローの標準化、ガイドラインの整備、そしてそれらを AI エージェントに落とし込むことで、初めて組織全体の開発効率が向上します。本ブログが、同様の課題を抱える皆様の参考になれば幸いです。

Amazon Web Services ブログ

「導入しても使われない」を解決する ― 三菱電機電力ICTセンターが Kiro と GitLab で実現した開発ワークフローの標準化

電力ICTセンターについて

これまでの取り組みと課題

Kiro の Steering・Powers・MCP とは

Steering：プロジェクト横断のグラウンドルール

Powers：動的に呼び出されるワークフロー定義

MCP（Model Context Protocol）：外部ツールとの連携

3 つの機能の関係性

現在の取り組み：Kiro × GitLab による開発プラットフォーム

全体像

Kiro の活用：Powers による開発ワークフローの標準化

その 1: Standard Dev Flow Power

その 2: Playwright Power

GitLab の活用

GitLab Pages によるガイドライン公開

CI/CD カタログによるパイプラインの標準化

GitLab Duo による MR レビュー：AI 同士の協働

この構成のメリット

1. 導入ハードルの大幅な低下

2. 開発の証跡とコラボレーション

3. レビュー負担の軽減

工夫した点と苦労した点

1 : Power の発動率を上げる工夫

2: GitLab 公式 MCP サーバーの補完

今後の展望

1 : 効果の定量化と継続的な改善

2 : Power とパイプラインのエコシステム構築

3 : 組織全体への展開とコミュニティ形成

まとめ

著者

お役立ちリンク

フォローお願いいたします

学ぶ

リソース

デベロッパー

ヘルプ

Amazon Web Services ブログ

「導入しても使われない」を解決する ― 三菱電機 電力ICTセンターが Kiro と GitLab で実現した開発ワークフローの標準化

電力ICTセンターについて

これまでの取り組みと課題

Kiro の Steering・Powers・MCP とは

Steering：プロジェクト横断のグラウンドルール

Powers：動的に呼び出されるワークフロー定義

MCP（Model Context Protocol）：外部ツールとの連携

3 つの機能の関係性

現在の取り組み：Kiro × GitLab による開発プラットフォーム

全体像

Kiro の活用：Powers による開発ワークフローの標準化

その 1: Standard Dev Flow Power

その 2: Playwright Power

GitLab の活用

GitLab Pages によるガイドライン公開

CI/CD カタログによるパイプラインの標準化

GitLab Duo による MR レビュー：AI 同士の協働

この構成のメリット

1. 導入ハードルの大幅な低下

2. 開発の証跡とコラボレーション

3. レビュー負担の軽減

工夫した点と苦労した点

1 : Power の発動率を上げる工夫

2: GitLab 公式 MCP サーバーの補完

今後の展望

1 : 効果の定量化と継続的な改善

2 : Power とパイプラインのエコシステム構築

3 : 組織全体への展開とコミュニティ形成

まとめ

著者

お役立ちリンク

フォローお願いいたします

学ぶ

リソース

デベロッパー

ヘルプ

「導入しても使われない」を解決する ― 三菱電機電力ICTセンターが Kiro と GitLab で実現した開発ワークフローの標準化