本記事は 2025 年 10 月 5 日 に公開された「 Integral Ad Science scales over 100 M documents with Amazon OpenSearch Service 」を翻訳したものです。 ソーシャルメディアプラットフォーム全体でコンテンツ量が急増し、リアルタイムの機械学習 (ML) モデルトレーニングが求められる中、 Integral Ad Science (IAS) にはソリューションが必要でした。コンテンツ分類器の継続的な開発を支え、手動アノテーションによる遅延を解消し、ピーク時の処理スループットを最大化できるソリューションです。 IAS はデジタルメディアの計測と最適化におけるグローバルリーダーであり、デジタルメディア品質の信頼性と透明性の基準を確立しています。データドリブンなテクノロジーでリアルタイムのインサイトと包括的なデータを提供し、広告が安全で適切な環境で実際のオーディエンスに届くようにしています。 本記事では、IAS が Amazon OpenSearch Service を活用し、スケーラブルな SaaS 型 ML プラットフォームを構築した事例を紹介します。プラットフォームは日次 1 億件以上のドキュメントを処理し、プロジェクト開始時と比較して複雑な検索オペレーションで 40〜55% のパフォーマンス向上を達成しました。 課題 従来、データサイエンスチームは手動および半自動のアノテーションワークフローに数日から数週間を費やしていました。目標は、パフォーマンスとコンプライアンスの要件を満たしつつ、データサイエンティストやエンジニアが組織全体でセルフサービスで利用できる統合 ML プラットフォームの構築でした。 主な要件は以下のとおりです。 高次元ベクトル埋め込みの類似検索処理 リアルタイムのインデキシングとクエリ 数百の ML 分類器の自動再トレーニング ベクトルデータベースの評価 Apache Spark と Databricks プラットフォーム上に構築したカスタムベンチマークフレームワークで、ベクトルデータベースソリューションを広範に評価しました。 チームは以下のパフォーマンス指標で複数のソリューションを評価しました。 毎秒の類似検索クエリ数 一括書き込みスループット 一括読み取りスループット Spark とのネイティブ統合 結果として、優れたパフォーマンス、コスト効率、Amazon Web Services (AWS) との統合、活発なコミュニティサポートを理由に OpenSearch Service が選定されました。 カスタムベクトルインデキシングを備えた従来型データベース、専用ベクトルデータベースサービス、オープンソースソリューションなど、他のアプローチも検討しました。それぞれ強みはあったものの、コスト効率とスループットの要件を満たしつつ、チームが求める ML 体験を提供するソリューションは OpenSearch 以外にありませんでした。 ソリューション概要 広範な評価の結果、IAS は Amazon OpenSearch Service と Amazon Managed Streaming for Apache Kafka ( Amazon MSK ) を戦略的基盤として採用しました。アーキテクチャはホットストレージとコールドストレージの両階層にわたり、リアルタイム処理と履歴分析の両方に対応します。ベクトルとメタデータは Amazon MSK を通じてストリーミングされ、信頼性の高いスケーラブルな取り込みを実現します。Spark ベースのコンシューマーがマイクロバッチを処理し、リアルタイムベクトル検索用の Amazon OpenSearch Service (ホットレイヤー) と長期分析用の Databricks 上の Delta テーブル (コールドレイヤー) に送信します。 以下がソリューションの全体像です。 図 1: ソリューションアーキテクチャ OpenSearch Service のベクトル検索機能と豊富なフィルタリング API により、データサイエンティスト、ナレッジワーカー、開発者がノートブック、カスタムアプリケーション、ワークベンチやポータルなどの GUI から利用できるようになりました。 ソリューションの最適化 OpenSearch Service クラスター構成は、目標パフォーマンスの達成に向けて複数の最適化フェーズを経ました。AWS チームの支援により、初期のパフォーマンスボトルネックと構成上の課題を克服しています。チームは AWS Graviton3 プロセッサ の r6g から r7g インスタンスへ移行し、OpenSearch Service のバージョンを 2.13 から 2.19 にアップグレードし、 Concurrent Segment Search 機能を有効化しました。 OpenSearch Service のインデックスマッピングは、高次元ベクトル埋め込みと効率的な k 近傍法 (k-NN) 検索 に対応するよう最適化しました。具体的には、 Hierarchical Navigable Small Worlds (HNSW) アルゴリズム と内積類似度を使用した 1,024 次元のベクトルフィールドを構成し、フィルタリング用のメタデータフィールドマッピングも設定しました。ベクトルフィールドでは構築と検索のパフォーマンスに最適化したパラメータ設定も行っています。IAS は OpenSearch Service の Scalar Quantization 機能でコスト削減も実現しました。 パフォーマンス最適化には、効率的な k-NN フィルタリング、シャード数とサイズの調整によるシャード最適化、 Java Virtual Machine (JVM) ヒープ設定の調整と Concurrent Segment Search の有効化によるメモリ管理が含まれます。通常の検索では 40〜55% のパフォーマンス改善を達成しました。複雑なフィルタ付きオペレーションでは最大 80% の改善が見られ、最も大きな改善では 20 分以上かかっていた複雑なフィルタ検索が 1 分未満に短縮されました。 今後、IAS は OpenSearch Service 3.0 への移行を検討しています。集約パフォーマンスの最大 20% 向上、高カーディナリティ集約のレイテンシー大幅削減、GPU アクセラレーション対応の可能性を含むベクトルデータベース機能の強化が期待されます。 インデキシングの最適化 データ取り込みパイプラインは、Amazon MSK をストリーミング基盤として活用し、高可用性のために 10 パーティション、レプリケーションファクター 3 で構成しています。パイプラインは複数のステージでデータを処理し、信頼性の高い高スループットなドキュメント処理を実現します。継続的に実行される Spark ジョブが Kafka トピックを消費し、スループットとレイテンシーを最適化します。マイクロバッチは OpenSearch Service と Delta テーブルの両方に同時書き込みされ、ストレージレイヤー間の整合性を維持します。 アーキテクチャ変更により、IAS はクラスターに過負荷をかけることなく大量のドキュメントストリームを OpenSearch Service に安全にインデキシングでき、インデキシングプロセスのスロットリング制御が向上しました。 OpenSearch Hadoop コネクタ の統合により、knn-vector フィールドの Spark 連携が可能になり、処理量が大幅に向上しました。ホットレイヤーとコールドレイヤーへの書き込みの並列化により、ベクトルドキュメントのインデキシングパフォーマンスは日次 6,000 万件から 1 億件以上に向上しました。 IAS は knn-vector フィールドの Spark 連携をサポートするプルリクエストを OpenSearch Hadoop コネクタに提出しました。このコントリビューションは OpenSearch のオープンソースコミュニティとの協業を示す好例であり、IAS 固有の技術要件を満たすソリューションの実現にもつながりました。OpenSearch Hadoop コネクタとの統合は、システムの安定性を維持しつつ目標処理量を達成するうえで不可欠でした。 メリット これらの工夫によって、IAS のデータサイエンティスト、エンジニア、ナレッジワーカーにスケーラブルな SaaS 型 ML 機能を提供するソリューションを実現しました。社内ユーザーは好みのツールで分類器のトレーニングとデプロイを行いながら、大規模環境で高いパフォーマンスを維持できます。Amazon OpenSearch Service をベクトル検索に活用するアプローチにより、インフラストラクチャの複雑さと手動プロセスが削減されます。 その他のメリットは以下のとおりです。 新しいデータの到着に基づく分類器の継続的な再トレーニング アノテーションサイクルを数日〜数週間からわずか数時間に短縮 スパイクのあるトラフィックパターンでも日次 1 億件以上のドキュメントを効率的に処理 異なるチームやビジネスユニット間のマルチテナンシー対応 高いインデックスチャーンでのデータ保持コンプライアンスの維持 データサイエンスチームが新しい ML モデルや実験をデプロイするまでの時間を短縮 アーキテクチャの柔軟性も重要なポイントです。IAS のベクトルデータベーススタックは柔軟な構成により、新しいユースケースに素早く対応できます。 AWS Cloud Development Kit (AWS CDK) を使い、チームごとの一貫したコスト配分を維持しつつ、ソリューションをチーム間で複製できます。 まとめ IAS は取り組みの当初、厳しいパフォーマンスとコスト要件を満たしつつベクトルデータベース機能を実現するスケーラブルなソリューションを求めていました。Amazon OpenSearch Service は、データサイエンスチームへの約束を果たすために必要な機能を提供しました。ベクトル検索の最適化と Amazon Managed Streaming for Apache Kafka の統合を含むアーキテクチャ改善により、コスト効率を維持しつつ大幅なパフォーマンス向上を達成しています。 IAS は複数のビジネスユニットへのプラットフォーム展開を続けており、SaaS 型 ML ソリューションのスケールに合わせてより多くの分類器をサポートする計画です。パイプラインにはさらに多くのユースケースが追加される見込みです。 ビジネスの加速を支援する方法については、 AWS の担当者 にお問い合わせください。 関連情報 Amazon OpenSearch Service vector database capabilities revisited Amazon OpenSearch Service Resources Amazon OpenSearch Service Documentation 著者について Brian Maguire Brian Maguire は、Amazon Web Services の Principal Solutions Architect です。クラウド上でお客様のアイデア実現を支援しています。テクノロジスト、ライター、教師、そして学ぶことを愛する学生でもあります。書籍「Scalable Data Streaming with Amazon Kinesis」の共著者です。 Daniel Cintron Daniel Cintron は、IT 分野で 16 年以上の経験を持つ Sr. Technical Account Manager です。アドテック業界のお客様が AWS で目標を達成できるよう支援しています。仕事以外では、家族との時間や新しいテクノロジーの探求を楽しんでいます。 Dmitry Goldenberg Dmitry Goldenberg は、Integral Ad Science の Staff Engineer です。ベクトルデータベースの統合や大規模分類器トレーニングフレームワークの構築プロジェクトをリードしています。ソフトウェア開発とデータエンジニアリングで 30 年の経験を持ち、AI/ML、NLP、情報検索技術を専門としています。IAS では Databricks、Amazon MSK/Kafka、Spark、AWS OpenSearch Service を活用し、高度なメディア計測ソリューションを提供しています。 Rudra Ghosh Rudra Ghosh は、ダブリンを拠点とする Integral Ad Science の Machine Learning Operations Engineer です。AWS のクラウドネイティブコンポーネントを活用したスケーラブルな ML プラットフォームの構築を専門としています。データエンジニアリングと MLOps の両分野に精通し、本番対応の ML システムを実現しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

みなさんこんにちは！ ワンキャリアでエンジニアをしている佐藤（GitHub： seiya2130 ）です。 ワンキャリアの開発組織では、月に一度、部署のメンバーが自由にテーマを選んで発表する「LT（ライトニングトーク）会」を開催しています。

本ブログは、三菱電機株式会社 電力システム製作所 電力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 エージェントに落とし込むことで、初めて組織全体の開発効率が向上します。本ブログが、同様の課題を抱える皆様の参考になれば幸いです。 著者 小森 裕之 電力システム製作所 電力デジタルエナジーシステム開発部 システム基盤課所属。 コーヒーと Kiro が大好きです！ 電力ICTセンター内の全ビジネスユニットの開発・運用に貢献するため、ITIL4 に準拠した専用プラットフォームの開発に携わっており、主に CI/CD 環境の検討・構築・導入や AI エージェントツールを活用した開発の仕組みづくりを担当しています。 稲田 大陸 – いなりく AWS Japan で働く Kiro をこよなく愛すソリューションアーキテクト。2022 年から三菱電機グループを支援しています。その活動の傍ら、最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、 Kiro のブログ などを執筆しています。 小松原 つかさ GitLab 合同会社 シニアパートナーソリューションアーキテクト 長きに渡るソフトウェア開発経験を持ち、データベース、セキュリティ、ビッグデータの領域での深い専門知識を持ちます。2022 年にGitLab に参加し、AI 駆動型開発ツールがもたらす新しい開発パラダイムの構築に取り組んでいます。