CSS
イベント
マガジン
技術ブログ
本記事は、Claude Code + さくらのAI EngineではじめるAgentic Codingを加筆修正したものです。 いまやAIは仕事に欠かせない存在になりました。数あるAIサービスの中でもプログラミングにおい […]
Mermaidの見た目、もうちょっとなんとかならんか ども！Mermaidで図を作るたびに「構造は最高なんだけど、見た目がなぁ…」と思ってた龍ちゃんです。 「 Claude CodeでMermaid図を作成する 」でMermaid図の自動生成について書きました。Mermaidはコードで構造を書けるから、フローチャートやシーケンス図がサクッと作れます。AIに「こういう図作って」って言えば一発で出てくるんですよね。 ただ、デフォルトのデザインがシンプルすぎるんですよね。設計書やブログに貼るにはちょっと素朴。 HTML+Tailwind CSSで図解を丸投げする方法 も試したんですよ。装飾の自由度は高いんですけど、フロー図やシーケンス図をCSSで手動配置するのが辛い。特に矢印の表現が鬼の難易度です。Mermaidが自動でやってくれる部分を手で書くのはしんどいです。 じゃあ合体させたらどうだ、と。 Mermaidの構造表現力 + Tailwind CSSの装飾力 。Mermaidに図の構造を任せて、周りの見た目はTailwindで自由に作れます。これを1つのHTMLファイルにまとめてPNGに変換します。 今回の内容です。 コピペで使えるHTMLテンプレート2種（右サイド注釈型 / 下部グリッド注釈型） 色を揃えるカスタマイズのコツ 実際にぶつかった壁と対処法 PNG変換の手段3つ まず完成形を見せます こういうのが作れます。 左がMermaidで描画したシーケンス図、右がTailwind CSSで装飾した注釈パネル。これ、1つのHTMLファイルから出てきます。 ポイントは、Mermaid図の色とTailwind装飾の色が揃ってるところですね。青系で統一してるから、「Mermaidの部分だけ浮いてる」みたいなことにならない。 注釈パネルには設計ポイント、セキュリティ考慮、エラーハンドリングみたいな文脈情報を書けます。Mermaid図だけだと「何が起きてるか」は分かるけど「なぜこうしたか」は伝わらないんですよね。注釈パネルがその「なぜ」を補ってくれます。 関連記事 : 仕様書の図でAIの理解と人間の視認性を両立する方法に関しては「 仕様書の図はAIに読ませるな — 軽量コードを添える設計パターン 」で詳しく書いてます。AIに図の構造を正確に伝えたい人はこちらもどうぞ。 テンプレートA: 右サイド注釈型 ここからが本題です。コピペして使えるHTMLテンプレートを2種類用意しました。 仕組みはシンプルで、1つのHTMLにTailwind CDNとMermaid CDN（ESM版）を同時に読み込んでるだけです。2つのCDNは競合しません（検証済み）。テンプレートをコピペすればそのまま動きます。色のカスタマイズについてはテンプレートの後で説明しますね。 まずはテンプレートA。冒頭で見せた完成形がこれです。左にMermaid図、右に注釈パネルを並べるレイアウトですね。 向いてる場面 : シンプルな図（ノード8個以下）に設計ポイントを3-4個添えたいとき キャンバスサイズ : 1280x720px <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Level 2: Mermaid + Tailwind CSS Decoration</title> <script src="https://cdn.tailwindcss.com"></script> </head> <body class="w-[1280px] h-[720px] m-0 p-0 overflow-hidden bg-white"> <div class="w-full h-full flex gap-6 p-10"> <!-- 左: Mermaid図 --> <div class="flex-1 border-2 border-blue-300 rounded-lg p-6 bg-blue-50"> <h2 class="text-xl font-bold text-blue-900 mb-4">認証フローのシーケンス図</h2> <div class="mermaid"> sequenceDiagram participant C as クライアント participant S as サーバー participant DB as データベース C->>+S: ログインリクエスト S->>+DB: ユーザー照合 DB-->>-S: 認証結果 alt 認証成功 S-->>C: アクセストークン発行 else 認証失敗 S-->>C: エラーレスポンス(401) end </div> </div> <!-- 右: 注釈パネル --> <div class="w-72 flex flex-col gap-3"> <div class="bg-yellow-50 border border-yellow-300 rounded p-3"> <h3 class="text-sm font-bold text-yellow-800">設計ポイント</h3> <p class="text-xs text-yellow-700">DB直接参照を避け、サービス層を経由させることで結合度を低減</p> </div> <div class="bg-green-50 border border-green-300 rounded p-3"> <h3 class="text-sm font-bold text-green-800">セキュリティ考慮</h3> <p class="text-xs text-green-700">トークンはJWT形式、有効期限15分で自動失効</p> </div> <div class="bg-red-50 border border-red-300 rounded p-3"> <h3 class="text-sm font-bold text-red-800">エラーハンドリング</h3> <p class="text-xs text-red-700">認証失敗時は具体的なエラー原因を返さない（セキュリティ対策）</p> </div> </div> </div> <script type="module"> import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.esm.min.mjs'; mermaid.initialize({ startOnLoad: true, theme: 'base', themeVariables: { primaryColor: '#dbeafe', primaryBorderColor: '#3b82f6', lineColor: '#6b7280', fontFamily: 'system-ui, sans-serif' } }); </script> </body> </html> 使い方はシンプルで、3箇所を差し替えるだけです。 Mermaid記法の部分 （ <div class="mermaid"> の中身）を自分の図に差し替える 注釈パネルの内容 （右側の3つのパネル）を自分の設計ポイントに差し替える themeVariables で色を変えたければカラーコードを調整する 注釈パネルは増減しても大丈夫です。3個が収まりいいですけど、2個でも4個でもレイアウトは崩れません。 色の統一について 完成形の画像を見て「Mermaid図と注釈パネルの色が揃ってるな」と思った人もいるかもしれません。これはテンプレート末尾の themeVariables でMermaid図の配色をTailwindのカラーパレットに合わせてるからです。 themeVariables: { primaryColor: '#dbeafe', // Tailwind blue-100 primaryBorderColor: '#3b82f6', // Tailwind blue-500 lineColor: '#6b7280', // Tailwind gray-500 fontFamily: 'system-ui, sans-serif' } 色を変えたいときはここのカラーコードを差し替えてください。 Tailwindのカラーパレット から持ってくると注釈パネル側と揃えやすいです。 1つ注意点として、 Mermaid図の中にTailwindクラスは効きません 。Mermaid図はSVGとして生成されるんで、外部CSSが適用できないんですよね。色のカスタマイズは themeVariables 経由のみです。 テンプレートB: 下部グリッド注釈型 テンプレートAだと、図が複雑になったときに左側のスペースが足りなくなります。シーケンス図で参加者が4人以上いたり、メッセージが10本近くあると、右の注釈パネルに幅を取られて図が窮屈になるんですよね。 そういうときはテンプレートBです。図を上部に全幅で配置して、注釈パネルは下部にグリッドで並べます。 向いてる場面 : 複雑な図（10ステップ近いシーケンス、状態遷移図）で図に全幅を使いたいとき キャンバスサイズ : 1280x1080px（縦に拡張） <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>OAuth 2.0 認可コードフロー</title> <script src="https://cdn.tailwindcss.com"></script> <style> .mermaid svg { transform: scale(3.2); transform-origin: center center; } </style> <script type="module"> import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.esm.min.mjs'; mermaid.initialize({ startOnLoad: true, theme: 'base', sequence: { diagramMarginX: 10, diagramMarginY: 10, actorMargin: 80, messageMargin: 40 }, themeVariables: { primaryColor: '#e0f2fe', primaryBorderColor: '#0284c7', primaryTextColor: '#0c4a6e', lineColor: '#64748b', fontFamily: 'system-ui, sans-serif' } }); </script> </head> <body class="w-[1280px] h-[1080px] m-0 p-0 overflow-hidden bg-white"> <div class="w-full h-full flex flex-col p-8 gap-6"> <!-- 上部: タイトル --> <div> <div class="text-lg font-bold text-gray-800">OAuth 2.0 認可コードフロー</div> <div class="text-sm text-gray-500">ソーシャルログイン実装の標準パターン</div> </div> <!-- 中央: 図（全幅） --> <div class="flex-1 border border-gray-200 rounded-lg p-6 bg-gray-50 flex items-center justify-center"> <div class="mermaid"> sequenceDiagram actor U as ユーザー participant App as Webアプリ participant Auth as 認可サーバー participant API as リソースサーバー U->>App: ログインボタンクリック App->>Auth: 認可リクエスト(client_id, redirect_uri, scope) Auth->>U: ログイン画面表示 U->>Auth: 認証情報入力 Auth->>App: 認可コード(code) App->>Auth: トークンリクエスト(code, client_secret) Auth->>App: アクセストークン + リフレッシュトークン App->>API: APIリクエスト(Bearer token) API->>App: リソースデータ App->>U: ユーザー情報表示 </div> </div> <!-- 下部: 注釈パネル（横並び） --> <div class="grid grid-cols-4 gap-3"> <div class="bg-blue-50 border border-blue-200 rounded-lg p-3"> <div class="text-sm font-bold text-blue-800">フロー概要</div> <div class="text-xs text-blue-700 mt-1">RFC 6749準拠の認可コードグラント。SPAではPKCE拡張を推奨。</div> </div> <div class="bg-amber-50 border border-amber-200 rounded-lg p-3"> <div class="text-sm font-bold text-amber-800">セキュリティ要件</div> <div class="text-xs text-amber-700 mt-1 space-y-1"> <div>state パラメータでCSRF対策</div> <div>client_secret はサーバー側で保持</div> <div>redirect_uri の完全一致検証</div> </div> </div> <div class="bg-green-50 border border-green-200 rounded-lg p-3"> <div class="text-sm font-bold text-green-800">実装チェックリスト</div> <div class="text-xs text-green-700 mt-1 space-y-1"> <div>トークンの安全な保存（httpOnly cookie）</div> <div>リフレッシュトークンのローテーション</div> <div>スコープの最小権限原則</div> </div> </div> <div class="bg-gray-100 border border-gray-200 rounded-lg p-3"> <div class="text-sm font-bold text-gray-700">補足</div> <div class="text-xs text-gray-600 mt-1">アクセストークンの有効期限は15分〜1時間が一般的。期限切れ時はリフレッシュトークンで自動更新。</div> </div> </div> </div> </body> </html> テンプレートAとの違いは3つです。 キャンバスが縦に拡張 （720px → 1080px）。図に余裕ができます 注釈パネルが下部グリッド 。図が全幅を使えるんで、参加者が4人いても窮屈になりません CSS transformでMermaid図を拡大 （ scale(3.2) ）。Mermaidは複雑な図を自動縮小するんで、それを補正してます scaleの調整について テンプレートBの scale(3.2) は、上のOAuth 2.0の例（参加者4人・メッセージ10本）に合わせた値です。自分の図に差し替えたら、scaleも調整が必要です。 Mermaidは図の複雑度に応じて自動縮小するんですけど、その縮小率が図ごとに変わるんですよね。なので 図を差し替えるたびにscaleを微調整する のが前提の設計です。 調整の手順はシンプルで、HTMLファイルをブラウザで開いて、文字が読める大きさになるまで scale の数値を上げ下げするだけです。目安としてはこんな感じ。 図の複雑度 scale目安 シンプル（参加者2-3人、メッセージ5本以下） 1.5〜2.0 中程度（参加者3-4人、メッセージ8本前後） 2.5〜3.5 複雑（参加者4人以上、メッセージ10本以上） 3.0〜4.0 どっちを使う？ 条件 テンプレート 図がシンプル（ノード8以下） A: 右サイド注釈型 図が複雑、横に広がる B: 下部グリッド注釈型 注釈が少ない（2-3個） A 注釈が多い（4個以上） B 迷ったらまずテンプレートAで試して、図が窮屈ならBに切り替える、でいいと思います。 ぶつかった壁と対処 検証してて何度かハマったので、先に共有しておきます。 ノード数には上限がある Mermaidは図の要素が増えると自動で縮小するんですよね。1280pxの幅に収めようとするから、ノードが多いと文字が潰れて読めなくなります。 実際に検証して、このくらいが上限だなというラインが見えました。 図の種類 推奨上限 超えるとどうなるか フローチャート 8-10ノード 文字が小さくなって読めない シーケンス図 4参加者・8メッセージ ラベルが長いと自動縮小される 状態遷移図 8-10状態 縦に伸びてキャンバスからはみ出す 上限を超えそうなときは、図を分割するか、テンプレートBでキャンバスを拡張するのがいいです。 サイズ問題の対策3種 実際にぶつかったサイズ問題と、それぞれの対処法です。 症状 対策 やり方 図がキャンバスからはみ出す キャンバスを拡張する h-[720px] → h-[1080px] に変更。PNG変換時も --height 1080 を指定 図が小さすぎて読めない CSS transformで拡大 .mermaid svg { transform: scale(X); } を追加 右の注釈パネルが図を圧迫する 注釈を下部に移動 テンプレートAからBに切り替える この3つの対策は組み合わせられます。テンプレートBはキャンバス拡張 + CSS transform + 下部グリッドの3つ全部入りですね。制約はあるけど対策は全部見つかってるんで、複雑な図はまずBを試してみてください。 PNG変換 — 3つの手段 HTMLファイルが完成したら、PNG画像に変換してブログや設計書に貼れます。手段は3つあって、好みと環境に合わせて選んでください。 手段 自動化 セットアップ 向いてる用途 CLIツール（html-screenshot） できる Python + Playwright 量産やCI/CD Playwright MCP できる MCP設定 Claude Code連携 ブラウザで直接開く 手動 なし 手軽に確認 CLIツール uv run html-screenshot --file template-a.html --output template-a.png 以前の記事 で紹介したhtml-screenshotツールがそのまま使えます。改修なしでMermaid CDNの読み込みにも対応してました。Playwrightの wait_until="networkidle" がCDN読み込み完了を待ってくれるんで、Mermaid図の描画が終わってからスクリーンショットを撮ってくれます。 テンプレートBのように高さを変えたい場合は --height 1080 を付けます。 Playwright MCP Claude CodeからPlaywrightのブラウザ操作を直接呼び出す方法もあります。HTMLファイルを開いてスクリーンショットを撮る操作がMCPのツールで完結します。 Playwright MCPの記事 で詳しく書いてるんで、Claude Code使ってる人はこっちが楽かもしれません。 ブラウザで直接開く 一番手軽なのはHTMLファイルをブラウザで直接開くことですね。Mermaid CDNが読み込まれて図がそのまま描画されます。PNG変換は手動（ブラウザのDevToolsやOS標準のスクリーンショット）になりますけど、「ちょっと確認したい」くらいならこれで十分です。 まとめ ノード数の上限やサイズ問題はありましたけど、全部対処法が見つかりました。制約を把握しておけばハマることはないです。 今回のポイントです。 「構造はMermaid、装飾はTailwind」の役割分担 。Mermaidが得意な構造の自動レイアウト（矢印の接続、参加者の配置、分岐の描画）はMermaidに任せて、周りの装飾（注釈パネル、色統一、レイアウト）はTailwind CSSで自由に作る。 テンプレートの使い分けはシンプルです。 条件 テンプレート シンプルな図 + 注釈少なめ A: 右サイド注釈型（1280×720） 複雑な図 + 注釈多め B: 下部グリッド注釈型（1280×1080） あと、おまけとして1つ。このテンプレートで作った図はAI連携にも強いです。Mermaidのソースコードは宣言的な記法（ sequenceDiagram 、 graph TD とか）なんで、AIが構造を正確に読み取れます。注釈パネルに設計意図を書いておけば、人間が見ても、AIが読んでもどっちにも伝わる。この辺の話は 仕様書の図にソースコードを添える設計パターン で詳しく書いてるんで、興味あれば読んでみてください。 もう1つ。このテンプレートを毎回コピペするのも手ですけど、Claude Codeの SKILL機能 にreference（参考例）として登録しておくと、「シーケンス図作って」と言うだけでテンプレートに沿った図が出てきます。テンプレートのクオリティがそのままSKILLのクオリティになるんで、良いテンプレートを貯める = 図解の品質を底上げする、という流れができます。コピペ用テンプレートとSKILL化、好きなほうで使ってください。 PlantUML編も書きました。Mermaidが苦手な図種（アクティビティ図、ユースケース図、コンポーネント図）をPlantUMLでカバーする話です。「 PlantUMLの表現力をTailwind CSSで設計書品質に仕上げる 」をどうぞ。 ほなまた〜 関連ブログ 今回の記事はシリーズの一部です。Mermaid図の生成からHTML図解、仕様書への活用まで、一連の流れで読めます。 ClaudeでMermaid図作成を自動化！プロンプトテンプレート集も公開 — 今回の出発点。Mermaid記法をAIで生成するところから始めたい人はここから。プロンプトテンプレートも載せてます。 図解作成、AIに丸投げしたら「たまに自分より上手い」件 — HTML+Tailwind CSSで図解を丸ごとAIに作らせる方法。フロー図以外の図解（比較図、アーキテクチャ図とか）はこっちが向いてます。 仕様書の図はAIに読ませるな — 軽量コードを添える設計パターン — 仕様書をAIと共有してるチーム向け。図にソースコードと設計意図を添えて、AIの「推測」をなくす方法です。 Playwright MCPで始めるブラウザ自動化 — PNG変換の手段の1つとして紹介したPlaywright MCP。Claude Codeからブラウザ操作を直接呼び出せます。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Mermaidのデザインが物足りない？Tailwindで拡張して設計書品質に first appeared on SIOS Tech Lab .
本ブログは、三菱電機株式会社 電力システム製作所 電力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 駆動型開発ツールがもたらす新しい開発パラダイムの構築に取り組んでいます。
動画
該当するコンテンツが見つかりませんでした
書籍
