本ブログは、三菱電機株式会社 電力システム製作所 電力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 駆動型開発ツールがもたらす新しい開発パラダイムの構築に取り組んでいます。

目次 はじめに 開発環境 事前準備 メインデータの用意（Sample web logs） 国マスタのインポート Lookup Index への変換 【実践】ES|QL での集計比較 Lookup Join なし（国コードのみ） Lookup Join あり（国名を結合） まとめ 参考資料 添付資料：country_list.csv はじめに これまで Elasticsearch で「メインのインデックスに、別インデックスの情報を紐付けて表示したい」場合、Enrich Processor を使用して、取り込み（Ingest）フェーズであらかじめデータを結合しておくのが一般的でした。 しかし、この方法ではデータの更新のたびに Enrich Policy の再実行が必要になるなど、運用の手間がかかる側面がありました。 最新の Elasticsearch では、ES|QL の LOOKUP JOIN 機能が登場し、クエリ実行時にリアルタイムで別インデックスの情報を参照できるようになりました。本記事では、この便利な新機能の使い方を紹介します。 開発環境 Elasticsearch / Kibana: v9.2.4 Chrome ※注意事項: LOOKUP JOIN … ON … == … の記法は、Elasticsearch 9.2 時点で Preview です。 事前準備 メインデータの用意（Sample web logs） 今回は Kibana に標準で用意されている「Sample web logs」を使用します。 まだ取り込んでいない場合は、Kibana ホームの「Add data」から Sample web logs を追加してください。 参考: https://elastic.sios.jp/blog/elasticsearch-esql-introduction-log-analysis/ 国マスタのインポート この記事の末尾に記載している country_list.csv を使用して、マスタデータを作成します。 ※筆者は、Webブラウザに Chrome を使用しました。 Kibana の Home > Upload a file を開きます。 country_list.csv をアップロードし、設定を以下のように変更します。 Index name: country_list Advanced options > Data view: off（マスタなので Data view は不要です） [Import] をクリックします。 Lookup Index への変換 ES|QL の Lookup Join を利用するには、通常のインデックスを「Lookup 用」に変換する必要があります。 Stack Management > Index Management から country_list を選択します。 2. Manage ボタンから Convert to lookup index をクリックします。 3. Lookup index name に lookup-country_list と入力し、Convert を実行します。 Note: この操作により、インメモリで高速に結合可能な特殊なインデックスが生成されます。元の country_list もそのまま残ります。 【実践】ES|QL での集計比較 Lookup Join なし（国コードのみ） まずは、通常の集計を行ってみます。 Kibana の Discover を開き、上部の [Try ES|QL] をクリックします。 以下のクエリを入力して実行します。 FROM kibana_sample_data_logs | STATS bytes_sum = sum(bytes) BY geo.dest | KEEP geo.dest, bytes_sum | SORT bytes_sum DESC | LIMIT 8 集計対象の期間は、適当に調整してください。下記の例では、Last 24 hours を指定しています。 結果: geo.dest 項目に CN や US といった 2 桁の国コードが表示されます。これだけでは、直感的にどの国か分かりにくいですよね。 Lookup Join あり（国名を結合） 次に、LOOKUP JOIN を使って国マスタから国名を引っ張ってきます。 FROM kibana_sample_data_logs | STATS bytes_sum = sum(bytes) BY geo.dest | LOOKUP JOIN lookup-country_list ON geo.dest == country_code | KEEP country_name, bytes_sum | SORT bytes_sum DESC | LIMIT 8 結果: country_name が結合され、「CHINA」「UNITED STATES」といった具体的な国名が表示されるようになります！ まとめ ES|QL の LOOKUP JOIN を使うメリットは以下の通りです。 運用の簡略化: Enrich Policy を管理・更新する手間が省ける。 直感的な記述: SQL の JOIN に近い感覚で、クエリ内で動的に結合できる。 柔軟性: 必要なときだけマスタ情報を付与できる。 現在は Preview 機能ですが、将来的に Elasticsearch でのログ分析やレポート作成において、欠かせない機能になるはずです。 参考資料 Elastic公式: LOOKUP JOIN command https://www.elastic.co/docs/reference/query-languages/esql/commands/lookup-join 添付資料：country_list.csv 国マスタのCSVです。 ※このデータは、 https://www.e-tax.nta.go.jp/toiawase/qa/crs/countrycode.htm を元に生成したものです。 country_code,country_name AF,AFGHANISTAN AX,ALAND ISLANDS AL,ALBANIA DZ,ALGERIA AS,AMERICAN SAMOA AD,ANDORRA AO,ANGOLA AI,ANGUILLA AQ,ANTARCTICA AG,ANTIGUA AND BARBUDA AR,ARGENTINA AM,ARMENIA AW,ARUBA AU,AUSTRALIA AT,AUSTRIA AZ,AZERBAIJAN BS,BAHAMAS BH,BAHRAIN BD,BANGLADESH BB,BARBADOS BY,BELARUS BE,BELGIUM BZ,BELIZE BJ,BENIN BM,BERMUDA BT,BHUTAN BO,"BOLIVIA, PLURINATIONAL STATE OF" BQ,"BONAIRE, SINT EUSTATIUS AND SABA" BA,BOSNIA AND HERZEGOVINA BW,BOTSWANA BV,BOUVET ISLAND BR,BRAZIL IO,BRITISH INDIAN OCEAN TERRITORY BN,BRUNEI DARUSSALAM BG,BULGARIA BF,BURKINA FASO BI,BURUNDI KH,CAMBODIA CM,CAMEROON CA,CANADA CV,CABO VERDE KY,CAYMAN ISLANDS CF,CENTRAL AFRICAN REPUBLIC TD,CHAD CL,CHILE CN,CHINA CX,CHRISTMAS ISLAND CC,COCOS (KEELING) ISLANDS CO,COLOMBIA KM,COMOROS CG,CONGO CD,"CONGO, THE DEMOCRATIC REPUBLIC OF THE" CK,COOK ISLANDS CR,COSTA RICA CI,COTE D'IVOIRE HR,CROATIA CU,CUBA CW,CURACAO CY,CYPRUS CZ,CZECHIA DK,DENMARK DJ,DJIBOUTI DM,DOMINICA DO,DOMINICAN REPUBLIC EC,ECUADOR EG,EGYPT SV,EL SALVADOR GQ,EQUATORIAL GUINEA ER,ERITREA EE,ESTONIA ET,ETHIOPIA FK,FALKLAND ISLANDS (MALVINAS) FO,FAROE ISLANDS FJ,FIJI FI,FINLAND FR,FRANCE GF,FRENCH GUIANA PF,FRENCH POLYNESIA TF,FRENCH SOUTHERN TERRITORIES GA,GABON GM,GAMBIA GE,GEORGIA DE,GERMANY GH,GHANA GI,GIBRALTAR GR,GREECE GL,GREENLAND GD,GRENADA GP,GUADELOUPE GU,GUAM GT,GUATEMALA GG,GUERNSEY GN,GUINEA GW,GUINEA-BISSAU GY,GUYANA HT,HAITI HM,HEARD ISLAND AND MCDONALD ISLANDS VA,HOLY SEE (VATICAN CITY STATE) HN,HONDURAS HK,HONG KONG HU,HUNGARY IS,ICELAND IN,INDIA ID,INDONESIA IR,"IRAN, ISLAMIC REPUBLIC OF" IQ,IRAQ IE,IRELAND IM,ISLE OF MAN IL,ISRAEL IT,ITALY JM,JAMAICA JP,JAPAN JE,JERSEY JO,JORDAN KZ,KAZAKHSTAN KE,KENYA KI,KIRIBATI KP,"KOREA, DEMOCRATIC PEOPLE'S REPUBLIC OF" KR,"KOREA, REPUBLIC OF" KW,KUWAIT KG,KYRGYZSTAN LA,LAO PEOPLE'S DEMOCRATIC REPUBLIC LV,LATVIA LB,LEBANON LS,LESOTHO LR,LIBERIA LY,LIBYA LI,LIECHTENSTEIN LT,LITHUANIA LU,LUXEMBOURG MO,MACAO MK,NORTH MACEDONIA MG,MADAGASCAR MW,MALAWI MY,MALAYSIA MV,MALDIVES ML,MALI MT,MALTA MH,MARSHALL ISLANDS MQ,MARTINIQUE MR,MAURITANIA MU,MAURITIUS YT,MAYOTTE MX,MEXICO FM,"MICRONESIA, FEDERATED STATES OF" MD,"MOLDOVA, REPUBLIC OF" MC,MONACO MN,MONGOLIA ME,MONTENEGRO MS,MONTSERRAT MA,MOROCCO MZ,MOZAMBIQUE MM,MYANMAR NA,NAMIBIA NR,NAURU NP,NEPAL NL,NETHERLANDS NC,NEW CALEDONIA NZ,NEW ZEALAND NI,NICARAGUA NE,NIGER NG,NIGERIA NU,NIUE NF,NORFOLK ISLAND MP,NORTHERN MARIANA ISLANDS NO,NORWAY OM,OMAN PK,PAKISTAN PW,PALAU PS,"PALESTINE, STATE OF" PA,PANAMA PG,PAPUA NEW GUINEA PY,PARAGUAY PE,PERU PH,PHILIPPINES PN,PITCAIRN PL,POLAND PT,PORTUGAL PR,PUERTO RICO QA,QATAR RE,REUNION RO,ROMANIA RU,RUSSIAN FEDERATION RW,RWANDA BL,SAINT BARTHELEMY SH,"SAINT HELENA, ASCENSION AND TRISTAN DA CUNHA" KN,SAINT KITTS AND NEVIS LC,SAINT LUCIA MF,SAINT MARTIN (FRENCH PART) PM,SAINT PIERRE AND MIQUELON VC,SAINT VINCENT AND THE GRENADINES WS,SAMOA SM,SAN MARINO ST,SAO TOME AND PRINCIPE SA,SAUDI ARABIA SN,SENEGAL RS,SERBIA SC,SEYCHELLES SL,SIERRA LEONE SG,SINGAPORE SX,SINT MAARTEN (DUTCH PART) SK,SLOVAKIA SI,SLOVENIA SB,SOLOMON ISLANDS SO,SOMALIA ZA,SOUTH AFRICA GS,SOUTH GEORGIA AND THE SOUTH SANDWICH ISLANDS SS,SOUTH SUDAN ES,SPAIN LK,SRI LANKA SD,SUDAN SR,SURINAME SJ,SVALBARD AND JAN MAYEN SZ,ESWATINI SE,SWEDEN CH,SWITZERLAND SY,SYRIAN ARAB REPUBLIC TW,"TAIWAN, PROVINCE OF CHINA" TJ,TAJIKISTAN TZ,"TANZANIA, UNITED REPUBLIC OF" TH,THAILAND TL,TIMOR-LESTE TG,TOGO TK,TOKELAU TO,TONGA TT,TRINIDAD AND TOBAGO TN,TUNISIA TR,TURKEY TM,TURKMENISTAN TC,TURKS AND CAICOS ISLANDS TV,TUVALU UG,UGANDA UA,UKRAINE AE,UNITED ARAB EMIRATES GB,UNITED KINGDOM OF GREAT BRITAIN AND NORTHERN IRELAND US,UNITED STATES UM,UNITED STATES MINOR OUTLYING ISLANDS UY,URUGUAY UZ,UZBEKISTAN VU,VANUATU VE,"VENEZUELA, BOLIVARIAN REPUBLIC OF" VN,VIET NAM VG,"VIRGIN ISLANDS, BRITISH" VI,"VIRGIN ISLANDS, U.S." WF,WALLIS AND FUTUNA EH,WESTERN SAHARA YE,YEMEN ZM,ZAMBIA ZW,ZIMBABWE XK,KOSOVO The post ES|QL の Lookup Join でインデックス結合が驚くほど簡単に first appeared on Elastic Portal .

はじめに 前回 は、CI/CDの基本から、GitLab Runnerの導入、そしてコンテナイメージのビルド・プッシュ・デプロイまで、一連のワークフローを解説しました。 今回は、マージリクエスト（MR）の重要な役割であるコードレビューに焦点を当てます。コードレビューは、バグの早期発見やコード品質の向上、さらにはチームの知識共有を促す、開発プロセスに欠かせない作業です。 本記事では、GitLabのMR機能を活用し、レビューをスムーズに進めるための具体的な操作方法を、レビュアー（レビューする人）とレビューイ（レビューしてもらう人）の両方の視点から解説します。 コードレビューの概要 コードレビューとは、他の開発者が書いたコードを読み、フィードバックや改善点を議論するプロセスです。これは、単にバグを見つけるだけでなく、チーム全体のコード品質を高め、知識を共有し、開発の一貫性を保つために重要です。 GitLabでは、このコードレビューのプロセスがマージリクエスト（MR）に統合されています。MR上でコードレビューを行う流れは以下のようになります。 レビューイ（レビューしてもらう人）：構文チェック後にMRを作成し、パイプラインの自動テストが完了していることを確認する。 レビューイ：レビュアーを指定してレビュー依頼を出す。 レビュアー（レビューする人）：レビュー依頼を受けたらMR画面を確認し、MRの概要を把握する。 レビュアー：コードの変更点へのコメントをする レビューイ：MRのレビューを確認し、コードの変更が必要な場合は修正する。 レビュアー：コードの変更点に問題がなければMRを承認する。 レビューイ：MRが承認されたらマージする。 今回はレビューイが承認をもらったら、レビューイ自身でマージする流れで紹介します。 承認に複数名必須な場合もあるので、すべての承認者が承認してからマージするためにレビューイ自身でマージする流れを紹介しましたが、誰がマージするかはチーム文化に依存します。 マージリクエストのレビュー機能紹介 MRの設定 マージリクエスト（MR）を作成する際、タイトルや説明、担当者といった様々な項目を設定できます。 タイトル MRの目的を示します。一目で内容がわかるように「feat: 新機能追加」や「fix: バグ修正」といったルール（コミット規約）を適用するのが一般的です。 説明 以下の点を意識して記載すると、レビュアーは内容を素早く理解できます。 なぜこの変更が必要かといった背景や課題 何を変更したかといった技術的な詳細 何を確認してほしいかといったレビューのポイント 関連するイシュー番号 担当者 このMRの責任者をアサインします。通常は作成者（レビューイ）自身をアサインします。 レビュアー コードレビューを依頼する人を指定します。 マイルストーン プロジェクトの特定のフェーズやリリース目標にMRを関連付けます。次のバージョンのリリースに向けたタスクをまとめること等ができます。 ラベル MRを分類するためのタグ付け機能です。「バグ」「ドキュメント」「緊急修正」などのラベルをつけて分類します。 マージ開始日時 マージを特定の日時にスケジュールするための機能です。特定の時間に自動でマージを実行したい場合に利用します。例えば、深夜に自動デプロイを行う際などに便利です。マージを開始するには、CI/CDのテストが成功している状態などのチェックに合格している必要があります。 マージオプション MRが承認されたときにソースブランチを削除します。 マージ完了後に、不要になった作業用ブランチを自動的に削除します。マージ後にブランチを削除し忘れることがなくなり、リポジトリを整理できます。 MRが承認されたときにコミットをスカッシュします。  マージする際に、複数のコミットを1つの大きなコミットにまとめる機能です。マージ時には1つのコミットとして履歴に記録できます。これにより、mainブランチの履歴を見やすく保てます。 ブランチ保護 以前の記事 で解説したように、mainのような重要なブランチは保護設定をすることが推奨されます。これにより、MRを経由しない直接のプッシュを防ぎ、レビューのプロセスを強制します。 Approve必須化 プロジェクトの承認ルールを設定することで、特定のチームメンバーやコードオーナーからの承認をマージに必須できます。例えば、「2人以上のレビューアの承認が必要」といったルールを設定することで、コード品質のチェック体制を強化します。この設定は、Premium, Ultimateのプランで行えます。Free版では1人の承認必須設定が可能です。 参考： https://docs.gitlab.com/user/project/merge_requests/approvals/rules/ レビュアー（レビューする人）の視点 レビュアーとしてMRをアサインされたら、以下のステップでレビューを進めましょう。 MR画面の確認 まず、MRの概要を把握します。 MRの目的、関連するイシュー、変更の概要を確認します。 失敗したCI/CDパイプラインのエラーが未解決の場合は、そこでレビューを中断し、修正を依頼します。 変更されたコードを詳細に確認します。以下の点を意識して確認するとよいと思います。 コードの品質 境界値や大規模データでの計算量が考慮されているか プロジェクトのコーディング規約に準拠しているか 変更点へのコメント 特定の変更点にコメントを付けることで、レビューイにフィードバックを伝えます。 変更された特定の行にカーソルを合わせると、コメントアイコンが表示されます。クリックすると、コメント入力欄が現れます。 修正案をコメントで提案できます。 「レビューを開始」 複数の箇所にわたるフィードバックを、まとめて一度に投稿したい場合に使うボタンです。このボタンをクリックすると、コメントはすぐに投稿されず、「保留中のコメント」として保存されます。すべてのレビューを終えた後、MRの画面の「Your review」から「レビューを送信」ボタンをクリックすると、保留中のすべてのコメントがまとめて投稿されます。 「今すぐコメントを追加」 特定のコード行に対して、すぐに投稿したい単発のコメントに使うボタンです。 明確な正解はありませんが、基本的には「レビューを開始」でフィードバックをまとめ、「今すぐコメントを追加」で緊急性の高いシンプルなコメントを送るのが良いと思います。例えば、大きめのリファクタリングでは「レビューを開始」、小さな誤字では「今すぐコメントを追加」といった使い分けができます。 「提案」 コメント入力欄にある「候補を挿入する」ボタンをクリックし、修正後のコードを記述します。これにより、ワンクリックで修正を適用できるようになります。 記述したら、その他コメントと同様にコメントを追加します。 承認（Approve） レビューが完了したら、MRを承認します。コードに修正が必要な場合は、レビューイに修正依頼を出し、修正完了の連絡をもらったら再度変更を確認して承認します。 変更が適切であると判断したら、MR画面の「承認」ボタンをクリックします。これは、コードを承認したという意思表示になります。 レビューイ（レビューしてもらう人）の視点 レビューイは、MRを作成してビューを依頼した後、レビュアーからのフィードバックに対応し、変更を完了させます。レビューが完了したらマージを行います。 MRの作成 マージするブランチのコードを確認して、レビュアーに見てもらえる状態にします。以下の点を意識して確認するとよいと思います。 パイプラインのテスト結果が成功しているか 不要なデバッグコードやコメント、一時ファイルが残っていないか レビュアーを指定してMRを作成します。MRの作成手順は 第5回 を参考にしてみてください。 コメントへの返信 質問のコメントに対しては意図を説明する返信を行います。議論が必要な場合は、返信で対話を続けます。 感謝の意を常に忘れないようにしましょう。 変更の適用 レビュアーから「提案」を受け取った場合、GitLabの機能を使って簡単に変更を適用できます。しかし、提案をそのまま適用すると1コミット単位で履歴が増えるため、コミットをまとめたい場合はローカルでの修正が必要です。「提案」機能ではコミットの粒度を制御しにくいため、ローカルでの修正との使い分けが必要です。 MRの「変更」タブで、コメントに付いている「変更を適用」ボタンをクリックします。コミットメッセージを入力して「適用」をクリックします。これで、提案された変更をコミットとして追加できます。 表示するコミットを最新バージョンに変更します。 提案された変更が適用されていることが確認できます。これで、簡単に変更を適用できました。 追加コミットと再プッシュ 複雑な修正が必要な場合や、提案をまとめて適用したい場合は、ローカルで変更を行い、再度コミットしてプッシュします。コメントに対してすべて対応が完了したら、再度レビュアーに連絡して、承認をもらいます。 マージ レビューが完了したら、MRを承認してマージします。 承認ルールが満たされ、すべてのチェックが完了したら、MR画面の「マージ」ボタンをクリックして、ブランチをマージします。 まとめ 今回は、GitLabのマージリクエストを単なるマージの申請ではなく、コードレビューの場として活用する方法を解説しました。 レビュアーは、MR画面を確認し、具体的なコメントや提案を使ってフィードバックを伝えます。一方、レビューイは、コメントに適切に対応し、修正を迅速に反映させることが重要です。MRでレビューを行うことで、レビューの履歴が残り、開発の透明性も向上します。 MRの機能を使いこなすことで、チーム全体のコード品質が向上し、効率的な開発が可能になります。 参考文献 https://docs.gitlab.com/user/project/merge_requests/reviews/ https://docs.gitlab.com/user/project/merge_requests/approvals/rules/ https://qiita.com/C_HERO/items/c5cfbdbb269efb72fb8f https://bake0937.hatenablog.com/entry/2019/10/24/145241   ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Git & GitLab 入門 (9) ～Git マスターへの道～「コードレビューの進め方」 first appeared on SIOS Tech. Lab .