G-gen の杉村です。2026年4月に発表された、Google Cloud や Google Workspace のイチオシアップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Google Cloud Next '26 の開催 プロダクトの名称変更 概要 Looker Studio → Data Studio（和名: データポータル） Dataplex Universal Catalog → Knowledge Catalog Cloud Composer → Managed Service for Apache Airflow BigLake → Google Cloud Lakehouse Dataproc → Managed Service for Apache Spark Vertex AI → Gemini Enterprise Agent Platform Google Cloud のアップデート オープンモデル Gemma 4 がリリース Cloud Armor に match condition builder が登場（Preview） Google の動画生成 AI モデル Veo 3.1 Lite が Preview 公開 Google Cloud の VPC で Hybrid Subnets が使用可能に Google Cloud コンソールでも Load Balancer 作成時に Certificate Manager 証明書アタッチが可能に Pub/Sub で AI Inference Single Method Transform （SMT）機能が一般公開 BigQuery に AI.AGG 関数が登場（Preview） Cloud SQL でストレージの縮小ができるように すべての Google Cloud 認定資格で日本語版が受験可能に BigQuery Graph が Preview 公開 Privileged Access Manager（PAM）で将来の IAM 権限付与を予約できるように Colab Enterprise で visualization cells が使えるように Cloud Run woker pools が Preview 版 → 一般公開（GA） Google Cloud〜AWS間のPartner Cross-Cloud Interconnectが一般公開（GA） Gemini Enterprise 用の専用 IAM ロールが登場 データポータルで BigQuery の Conversational Analytics が使用可能に Cloud Run でエフェメラルディスクが Preview 公開 Gemini Cloud Assist のサイドパネルが強化 Gemini Enterprise app でカスタム MCP サーバーが接続可能に BigQuery の CDC テーブルからマテリアライズドビューを作成可能に Compute Engine、GKE、Cloud Storage で「AI Zone」が公開 Google SecOps が VPC Service Controls に対応 VPC Service Controls の ingress/egress ルールで IAM ロールが使用可能に Google Workspace のアップデート Google Vids から YouTube への直接エクスポートが可能に Chrome 拡張機能 Google Vids Screen Recorder が登場 Gemini アプリの macOS 版ネイティブデスクトップアプリが登場 Gemini アプリで会話結果から Docs や PDF を生成可能に Google Meet の Take notes for me（自動議事録）のカスタマイズが可能に はじめに 当記事では、毎月の Google Cloud（旧称 GCP）や Google Workspace（旧称 GSuite）のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Google Cloud Next '26 の開催 Google Cloud の旗艦イベントである Google Cloud Next が、米国ネバダ州ラスベガスにおいて4月22日（水）から24日（金）までの3日間、開催された。 Agentic（エージェンティックな、自律的な）をテーマに、数多くの新機能が発表された。発表された機能の中には、既に一般公開（GA）されているもの、Preview 公開されているもの、まだ使用可能になっていないものなどが混同している。 主要な発表がされたキーノート（基調講演）については、以下の記事を参照されたい。 blog.g-gen.co.jp blog.g-gen.co.jp また G-gen では、現地に派遣したエンジニアや日本からリモートで情報収集するエンジニアが、各種セッションレポートを公開している。以下のカテゴリ一覧から、Google Cloud Next '26 の関連記事にアクセスできる。 blog.g-gen.co.jp プロダクトの名称変更 概要 2026年4月には以下のように、プロダクトの名称変更が相次いだ。 旧名称 新名称 Looker Studio Data Studio（和名: データポータル） Dataplex Universal Catalog Knowledge Catalog Cloud Composer Managed Service for Apache Airflow BigLake Google Cloud Lakehouse Dataproc Managed Service for Apache Spark Vertex AI Gemini Enterprise Agent Platform Gemini Enterprise Gemini Enterprise app Looker Studio → Data Studio（和名: データポータル） Data Studio returns as new home for Data Cloud assets (2026-04-11) Looker Studio は Data Studio（和名: データポータル）に名前が再変更された。昔の名前に戻ったことになる。経緯は以下のとおり。 もともとは「英名: Data Studio / 和名: データポータル」という名称だった 日本では商標の関係で「Data Studio」という名称が使えないため「データポータル」と表記される 2022年10月の Google Cloud Next '22 で「Looker Studio」に名前が変更され、Looker ブランドに統一された。Looker と Looker Studio の2つの製品が存在する状態になり、混乱を呼んだ 2026年4月に「英名: Data Studio / 和名: データポータル」に戻った システム的には以下の変更がされた。 UI 上の表記が「データポータル（Data Studio）」になった 従来の URL（ lookerstudio.google.com ）にアクセスすると、新しい URL（ datastudio.google.com ）にリダイレクトされる Dataplex Universal Catalog → Knowledge Catalog Knowledge Catalog release notes - April 10, 2026 Dataplex Universal Catalog は Knowledge Catalog に改名された。 フルマネージドのデータカタログサービス。今回で4回目の名称変更となる。名称の変遷は以下のとおり。 Data Catalog → Dataplex Catalog → BigQuery universal catalog → Dataplex Universal Catalog → Knowledge Catalog Cloud Composer → Managed Service for Apache Airflow Cloud Composer release notes - April 15, 2026 Cloud Composer は Managed Service for Apache Airflow に改名された。 フルマネージドの Apache Airflow であり、データパイプラインの実装等に使われるマネージドサービス。 BigLake → Google Cloud Lakehouse What is Google Cloud Lakehouse? (2026-04-20) BigLake が Google Cloud Lakehouse に改称。 Google Cloud Lakehouse は、Apache Spark、Apache Flink、Trino といったオープンソースのクエリエンジンとの互換性を持つ、レイクハウスフレームワーク。BigQuery を基幹技術とする。 Dataproc → Managed Service for Apache Spark Managed Service for Apache Spark cluster deployment overview (2026-04-22) Dataproc が Managed Service for Apache Spark に改称。 Managed Service for Apache Spark はその名のとおり、フルマネージドの Apache Spark クラスタ。 Vertex AI → Gemini Enterprise Agent Platform Vertex AI to Gemini Enterprise Agent Platform naming changes (2026-04-22) Vertex AI は、Gemini Enterprise Agent Platform と改名された。これに伴い、これまで Gemini Enterprise と呼ばれていた Web サービスは、Gemini Enterprise app と改名された。また Vertex AI プロダクト群は、以下のように名称が変更となる（一部のみ抜粋）。 旧称 旧名称 Vertex AI Gemini Enterprise Agent Platform Gemini Enterprise Gemini Enterprise app Generative AI on Vertex AI Generative AI Vertex AI Studio Agent Studio Vertex AI API Agent Platform API Vertex AI Agent Engine Agent Runtime Vertex AI Search Agent Search Vertex AI Search for Commerce Agent Search for Commerce Vertex AI Conversation Agent Conversation Vertex AI Vector Search Vector Search Vertex AI Training Agent Platform Managed Training Vertex AI Pipelines Agent Platform Pipelines Google Cloud のアップデート オープンモデル Gemma 4 がリリース Gemma 4 モデルの概要 (2026-03-31) オープンモデル Gemma 4 がリリース。商用利用可。以下の種類がある。 E2B / E4B : モバイル、エッジ、ブラウザ向け 31B : より高密度 26B A4B : 高スループットで高度な推論向け Cloud Armor に match condition builder が登場（Preview） Use the match condition builder (2026-03-31) フルマネージド WAF である Cloud Armor に match condition builder が登場（Preview）。 CEL 文を書く時の UI 補助ツール。ルールを書く負担が軽減される。 Google の動画生成 AI モデル Veo 3.1 Lite が Preview 公開 Veo 3.1 Lite Generate Preview (2026-04-02) Google の動画生成 AI モデル Veo 3.1 Lite が Preview 公開。 Veo 3.1 < 3.1 Fast < 3.1 Lite の順で生成秒数あたりの料金単価が安く、Lite が最も安価なモデルとなる。 Google Cloud の VPC で Hybrid Subnets が使用可能に About migrating to Google Cloud with Hybrid Subnets (2026-04-03) Google Cloud の VPC で Hybrid Subnets が使用可能になった。 クラウド側サブネットにオンプレと同じ CIDR を持たせ、IP アドレスを変えずにサーバーをクラウドへ移行できる。オンプレ側ルーターに Proxy ARP の設定が必要であり、またクラウド側のルーティングも少しトリッキーになる。 Google Cloud コンソールでも Load Balancer 作成時に Certificate Manager 証明書アタッチが可能に Google Cloud release notes - April 05, 2026 (2026-04-05) Cloud Load Balancer 作成時に Certificate Manager 証明書のアタッチが Google Cloud コンソールでもできるようになった。 従来は DNS 認証した証明書だと gcloud コマンド等を使う必要があった。今後は証明書マップを UI 上で選択できる。 Pub/Sub で AI Inference Single Method Transform （SMT）機能が一般公開 AI Inference SMT (2026-04-06) Pub/Sub で AI Inference Single Method Transform （SMT）機能が一般公開。Pub/Sub トピックまたはサブスクリプション内のメッセージを Gemini 等の AI モデルで加工。以下のような用途がある。 メッセージに対してリアルタイムで AI モデルによる推論結果を追加（エンリッチメント） アプリケーション側の処理のオフロード 以下の記事も参照。 blog.g-gen.co.jp BigQuery に AI.AGG 関数が登場（Preview） The AI.AGG function (2026-04-06) BigQuery に AI.AGG 関数が登場（Preview）。Cloud Storage 上の非構造化データ（画像またはテキスト）に対して Gemini を使い「意味的な集計」のような処理ができる。感情分析、コンテンツ要約、ログ分析など。 Cloud SQL でストレージの縮小ができるように About storage shrink (2026-04-06) Cloud SQL でストレージの縮小ができるようになった。従来は拡大はできたが縮小はできなかった。インスタンスの再起動が必要。 プライマリインスタンスとリードレプリカの両方で可能。 すべての Google Cloud 認定資格で日本語版が受験可能に Google Cloud 認定資格の一覧を解説。全部で何個ある？難易度は？ (2026-04-08) これまで日本語版しか提供されていなかった以下の2試験の日本語版が公開された。 Professional Security Operations Engineer Professional Cloud Database Engineer これをもって、14種類すべての Google Cloud 認定資格が、日本語で受験可能になった、 以下の記事も参照。 blog.g-gen.co.jp BigQuery Graph が Preview 公開 Introduction to BigQuery Graph (2026-04-09) BigQuery Graph が Preview 公開。 Graph Query Language（GQL）を使ってデータ間の関係性を可視化できる。CREATE PROPERTY GRAPH 文でノードテーブル・エッジテーブルを事前に定義。 Privileged Access Manager（PAM）で将来の IAM 権限付与を予約できるように Grant scheduling (2026-04-13) Privileged Access Manager（PAM）で将来の IAM 権限付与を予約できるようになった。最大7日後の予約が可能。 Colab Enterprise で visualization cells が使えるように Use visualization cells (2026-04-13) Colab Enterprise で visualization cells が使えるように。データフレームに入れた値を基にチャート（図表）を簡単に UI で作成できる。BigQuery → df → 可視化を UI 上で簡単に行える。 Colab Enterprise の visualization cells Cloud Run woker pools が Preview 版 → 一般公開（GA） Deploy worker pools to Cloud Run (2026-04-14) Cloud Run woker pools が Preview 版 → 一般公開（GA）。 Pub/Sub などに対してタスクを取得する pull 型ワークロードを実行するためのフルマネージドのコンテナ基盤。高いコスト効率でコンテナのジョブを実行できる。 Google Cloud〜AWS間のPartner Cross-Cloud Interconnectが一般公開（GA） Partner Cross-Cloud Interconnect for AWS overview (2026-04-14) Google Cloud と AWS を容易に専用線接続できる Partner Cross-Cloud Interconnect が一般公開（GA）。 VPC ピアリングまたは Network Connectivity Center 経由で接続できるため、かなり手軽に Google Cloud 〜 AWS 間で専用線確立が可能。 最短で当日中に接続を確立できる。帯域は1Gbps〜100Gbps。 Gemini Enterprise 用の専用 IAM ロールが登場 IAM roles and permissions (2026-04-15) Gemini Enterprise 用の専用 IAM ロールが登場。 Gemini Enterprise 管理者（ roles/discoveryengine.agentspaceAdmin ） Gemini Enterprise ユーザー（ roles/discoveryengine.agentspaceUser ） これまでは事前定義ロールとして「ディスカバリー エンジン管理者（ roles/discoveryengine.admin ）」および「ディスカバリー エンジン ユーザー（ roles/discoveryengine.user ）」が存在していた。 なお2026年4月現在、これらのロールはそれぞれ名称が違うだけで、含まれている権限が全く同一である。 Gemini Enterprise 管理者 <=> ディスカバリー エンジン管理者 Gemini Enterprise ユーザー <=> ディスカバリー エンジン ユーザー データポータルで BigQuery の Conversational Analytics が使用可能に Data agents in Data Studio (2026-04-16) データポータル（先日、Looker Studio から改名した）の画面から、BigQuery の Conversational Analytics（会話型分析）を使用できるようになった。 データポータル Proライセンスは不要。BigQuery でデータエージェントを作成して、一般従業員にエージェントを配ることが容易になった。 データポータルから BigQuery のデータエージェントを使用する Cloud Run でエフェメラルディスクが Preview 公開 Configure an ephemeral disk for Cloud Run services (2026-04-20) Cloud Run でエフェメラルディスクが Preview 公開。 ext4 フォーマットの一時ディスク。インスタンス停止で消去される。 service、job、worker pool いずれでも使用可。従来の /tmp はインメモリのためメモリ料金を消費したが、今後は一時ディスクに逃がせる。 Preview 公開されている2026年4月現在、料金の表記はない。 Gemini Cloud Assist のサイドパネルが強化 Gemini Cloud Assist release notes - April 22, 2026 (2026-04-22) 日本語でも使える 表示させているコンソール画面をコンテキストとして読み取る グラウンディング有無を設定 カスタムインストラクション など。その他にも Private Preview で MCP への対応など。 Gemini Cloud Assist のサイドパネルが強化 Gemini Enterprise app でカスタム MCP サーバーが接続可能に Set up your custom MCP server data store (2026-04-22) Gemini Enterprise app でカスタム MCP サーバーをデータストアとして接続できるようになった（Preview）。 認証は OAuth。MCP 準拠の外部システムや社内データに Gemini Enterprise app からアクセスできる。 BigQuery の CDC テーブルからマテリアライズドビューを作成可能に Tables with active change data capture (2026-04-28) BigQuery の CDC（change data capture）適用テーブルをベーステーブルとして、マテリアライズドビューを作成可能になった。 ストリーミングデータを受け取るテーブルをベースに、自動更新のマテビューを作成でき、運用負荷の軽減になる。 Compute Engine、GKE、Cloud Storage で「AI Zone」が公開 AI Zones (2026-04-27) Google Cloud で「AI Zone」が公開。Compute Engine、GKE、Cloud Storage が対応。 us-south1-ai1b のような名称の特殊なゾーン。GPU や TPU が優先的に提供される代わりに一部サービスは提供されない。オランダ、テキサス、アイオワのリージョンで使用可能。地理的に隔離されているため、通常ゾーンとのレイテンシは比較的大きい。 Google SecOps が VPC Service Controls に対応 Configure VPC Service Controls for Google SecOps (2026-04-30) Google SecOps の VPC Service Controls 対応が一般公開（GA）。Google SecOps は Google の SIEM 製品。VPC Service Controls による IP アドレス制御や、コンテキストアウェアなアクセス制御が可能になった。 VPC Service Controls の ingress/egress ルールで IAM ロールが使用可能に Configure IAM roles in ingress and egress rules (2026-04-30) VPC Service Controls の ingress/egress ルールで、IAM ロールを使用した許可設定が可能に（Preview → GA）。 これまでプリンシパルやメソッドの指定ができたが特定の IAM ロールを持っている場合のみアクセス許可するよう設定できるようになった。以下の記事も参照。 blog.g-gen.co.jp Google Workspace のアップデート Google Vids から YouTube への直接エクスポートが可能に Export Google Vids directly to YouTube (2026-04-02) Google Vids から YouTube への直接エクスポートが可能に。 MP4 で一度エクスポートする必要がない。限定公開動画のエクスポートも可能。 Chrome 拡張機能 Google Vids Screen Recorder が登場 Record your screen directly from Chrome with the Google Vids Screen Recorder Chrome Extension (2026-04-02) Chrome 拡張機能「Google Vids Screen Recorder」が登場。ブラウザ画面を録画して直接 Google Vids に記録できるため編集や共有が容易になる。 Google Workspace でも個人アカウントでも利用可能。 Gemini アプリの macOS 版ネイティブデスクトップアプリが登場 Gemini アプリが Mac に登場 (2026-04-15) Gemini アプリの macOS 版ネイティブデスクトップアプリが登場。 Web 版にない機能として、画面共有して Gemini に質問する機能などがある。 Gemini アプリで会話結果から Docs や PDF を生成可能に Move from conversation to creation with file generation in Gemini (2026-04-27) Gemini アプリで会話結果から Google ドキュメント、スプレッドシート、Microsoft Word（.docx）、Microsoft Excel（.xlsx）、PDF などのファイルを直接、生成可能になった。その他の対応フォーマットは以下のとおり。 Google Workspace files (Docs, Sheets, and Slides) PDF file Microsoft Word (.docx) Microsoft Excel (.xlsx) CSV file (.csv) LaTeX (.tex) Plain Text (.txt) Rich Text Format (.rtf) Markdown (.md) Gemini アプリで会話結果から Docs や PDF を生成可能に Google Meet の Take notes for me（自動議事録）のカスタマイズが可能に New ways to customize AI-generated meeting notes (2026-04-30) Google Meet の Take notes for me（自動議事録）のカスタマイズが可能に。メモの長さや決定事項を入れるかどうかなど。 ただし、一部機能は英語にしか対応していない。詳細なカスタムプロンプトを入れられるわけではない。2026年4月30日から15日間かけて段階的ロールアウト。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

1. はじめに DRE（Data Reliability Engineering）グループ のつざきです。タイミーのデータエンジニアリング部で、BigQuery / dbt / Cloud Composer / Looker といったデータ基盤の開発・運用をしています。 DREチームでは 2026 年 2 月から、AWS が提唱する AI-DLC（AI-Driven Development Life Cycle）というワークフローを運用しています。きっかけは、 1 月末に AWS 主催の研修「Unicorn Gym」で3 日間 AI-DLC を体験したことでした。 AI-DLC 自体とタイミー全体への波及は同部の橋本さんが、Operations フェーズ（リリース後の検証）の独自構築については同じ DRE G の chanyou さんが、それぞれまとめています。 3日間のUnicorn Gymが1ヶ月で組織を変えた —— データで見るAI-DLC導入の波及効果 （橋本さん） 「リリース後」に向き合うAI駆動開発の実践 （chanyou さん） 本記事はこれらの続編的な位置づけで、「DREチーム が Inception と Construction フェーズで何を実装・運用しているか」に絞って書きます。 対象読者 : AI-DLC を個人ではなく、チーム（モブ）で運用したい開発/データ基盤チーム この記事の目的 : 公式の想定（単一プロジェクト/個人運用）を、複数リポジトリ・リモートモブ前提に翻訳した実装パターンを共有する 扱わないこと : Operations フェーズの詳細、全社展開の話、AI-DLC の一般解説 TL;DR DREチームは 2026 年 2 月から AI-DLC を運用中 実装 : Workspace + CLAUDE.md 読み替え、Intent 単位の運用 モブ : 1 日 3 ~ 4 時間のフルリモートモブ。狙いは「フロー効率（承認ゲートで止まらない）」「キーパーソンに頼らない（新基盤導入や新メンバー受け入れに効く）」「AI 出力の欠陥を集合知で減らす」の 3 つ 3 ヶ月の結果 : Intent 完了が月 14〜17 件で推移、PR 数は維持、サイクルタイムに劇的な変化は見えず 記事の立ち位置 : 公式に書かれていない実装の隙間（Mob、複数リポジトリ、パス読み替え等）を自分たちで翻訳した事例として記録 2. AI-DLC をざっくり AI-DLC の全体像は既出記事に譲り、本記事で後から使う概念だけ押さえておきます。 本記事での用語の使い方 Intent : 1 つのゴール（例: あるデータソースを BigQuery で使えるようにする） Unit : Intent を疎結合に分解した作業単位（DDD の Subdomain 相当。例: Terraform 追加、DAG 実装など） Ritual : モブでの儀式的な作業（後述の Mob Elaboration / Mob Programming / Mob Testing） Workspace : ドキュメントとルールを置く専用リポジトリ フェーズと成果物の階層 AI-DLC には 3 つのフェーズがあります。 Inception : 要件分析・設計 Construction : 実装・テスト Operations : デプロイ・監視 3 つの Mob Ritual 各フェーズには対応する儀式（Ritual）が定義されています。 Mob Elaboration （Inception）: 要件分析・分解を全員で Mob Programming （Construction）: 実装を全員で Mob Testing （Construction）: テストを全員で いずれも、公式推奨は「物理集合 + 共有スクリーン + ファシリテーター」です。 Human Oversight = Loss Function AI-DLC は AI が実行主体、人間は各ステップで検証・承認する構造です。公式ペーパーの表現が印象的で: "Each step serves as a strategic decision point where human oversight functions like a 'loss function' - catching and correcting errors early before they snowball downstream." 機械学習の損失関数のように、人間のレビューが早期にエラーを補正する、というメタファーです。後の章でモブワークの話をするときに効いてきます。 3. 公式ドキュメントに書かれていない実装ギャップ chanyou さんの記事では、awslabs/aidlc-workflows リポジトリで Operations フェーズがプレースホルダになっている話が出てきます。実は Inception と Construction の側にも、公式の文書と実装の間にいくつかのギャップがあります。 awslabs/aidlc-workflows の構成 原典の awslabs/aidlc-workflows は MIT-0 ライセンスで公開されている、マークダウンのルールファイル群です。 aidlc-rules/ ├── aws-aidlc-rules/ │ └── core-workflow.md # ワークフロー本体 └── aws-aidlc-rule-details/ ├── common/ # 共通ルール ├── inception/ # Inception 詳細 ├── construction/ # Construction 詳細 └── operations/ # プレースホルダ ギャップ 1: ルール実装に Mob の記述がない AI-DLC 公式ペーパーでは Mob Elaboration / Mob Programming / Mob Testing が中核の儀式として定義されています。しかし原典のルールファイル群を mob で grep してもヒットしません。実装部分は「個人と AI エージェントが 1 対 1 で対話しながら承認ゲートを通す」構造になっており、Mob は想定されていない書き方です。 ギャップ 2: 公式チュートリアルは個人開発の例 AWS 公式ブログの実践記事 Building with AI-DLC using Amazon Q Developer のサンプルは、単一 HTML ファイルの川渡りパズルを個人で作る例だけで、モブで回す実演は出てきません。 ギャップ 3: 複数リポジトリの扱いが明確でない 公式は単一プロジェクト前提です。データチームのように「1 つの機能を作るのに複数リポジトリにまたがる」ケースへの具体的な示唆はほぼありません。 理念と実装の翻訳が必要 つまり、公式ペーパーに書かれた「Mob ワーク」や「複数チームでの協調」を実際に動かすには、自分たちで翻訳する必要があります。DRE では、各ギャップに対応する形で次のように対処しています。 ギャップ 1（Mob がルールにない） → モブでの意思決定を組み込み（章 6） ギャップ 2（単一 Intent 想定） → Workspace + CLAUDE.md 読み替え（章 4） ギャップ 3（複数リポジトリが薄い） → 複数リポジトリを 1 Intent でまとめる（章 5） 次章から具体に入ります。 4. DRE の実装: Workspace + CLAUDE.md 読み替え AI-DLC を Claude Code で回すために、DRE では次の構成にしています。 全体像（先に結論） ルール階層 : aidlc-rules/ （上流）→ .claude/rules/ （上書き）→ CLAUDE.md （入口） パス読み替え : aidlc-docs/requirements.md を aidlc-docs/intents/<YYYY-MM>/<intent_name>/inception/requirements.md に読み替え Intent 箱 : Intent ごとに独立したディレクトリ（ intents/<YYYY-MM>/<intent_name>/ ） 状態管理 : aidlc-state.md に Status と Code Repositories を記録 スキル化 : Intent ライフサイクルを Claude Code のスキルで操作 以下、理由と詳細を順に見ていきます。 なぜこの構成なのか awslabs のリポジトリは単一プロジェクト・単一 Intent 前提で書かれていて、1 つの aidlc-docs/ ディレクトリに成果物を蓄積する想定になっています。 一方で DRE は、Intent という単位で開発を進めていて、完了した Intent もそのまま保存しています（後述しますが 2026 年 3 月は 14 件の Intent が完了しました）。Intent ごとに独立したディレクトリが必要になるので、パス読み替えが不可欠です。 ルール階層（継承構造） aidlc-rules/ : awslabs/aidlc-workflows の中身をそのまま取り込む。手動変更禁止、 /aidlc-rules-update スキルで上流追従 .claude/rules/ : プロジェクト固有のルール。aidlc-rules のオーバーライドや追加ルールを置く CLAUDE.md : エントリポイント。プロジェクト概要とディレクトリ規則を最小限に記述 上流は変えない。プロジェクト固有の振る舞いは派生側で足す。オブジェクト指向の継承に近い発想です。 [入口] CLAUDE.md ├─ 参照: aidlc-rules/ # 上流（awslabs 同期、変更禁止） └─ 参照: .claude/rules/ # 派生（DRE 固有、オーバーライド＋追加） パス読み替えの例 awslabs のルールは、成果物の置き場として aidlc-docs/ というパスを前提に書かれています。DRE ではこれを Intent ごとのディレクトリに読み替えます。 公式: aidlc-docs/requirements.md DRE: aidlc-docs/intents/<YYYY-MM>/<intent_name>/inception/requirements.md この読み替えは .claude/rules/aidlc-workflow.md に定義してあり、Claude Code が実行時に解釈します。ルール本体（aidlc-rules/）は触らずに、パスだけ派生側で書き換える構成です。 Intent ディレクトリの構造 1 つの Intent のディレクトリはこういう構造です。 aidlc-docs/intents/<YYYY-MM>/<intent_name>/ ├── intent.md # Intent の目的・受け入れ基準 ├── aidlc-state.md # Intent の状態管理 ├── audit.md # 監査ログ ├── inception/ │ ├── requirements.md │ ├── stories.md │ └── ... └── construction/ └── <unit_name>/ ├── functional-design.md ├── code-generation.md └── ... aidlc-state.md のカスタマイズ Intent の進捗追跡に使う aidlc-state.md は、公式テンプレートをベースに少し拡張しています。 Status : OPEN / SUSPEND / CLOSED の 3 値を追加 Assignee : 担当者 Code Repositories : 複数のコードリポジトリのブランチ状態を記録 この Code Repositories セクションが次の章（複数リポジトリ運用）の鍵になります。 スキル化 Intent のライフサイクル管理は Claude Code のスキルとして定義しています。 /aidlc-intent-start : 新規 Intent 開始 /aidlc-intent-continue : 既存 Intent の再開 /aidlc-intent-save : 作業内容を PR 化してマージ /aidlc-rules-update : 上流（awslabs）への追従 chanyou さんの記事では /inception のように AI-DLC のワークフローそのものを呼び出すスキルが紹介されています。一方、DRE では「Intent というライフサイクルの入れ物」をスキル側で担う構成にしています。どちらも awslabs のルールに乗りつつ、スキルで扱う粒度が違う、という関係です。 5. 複数リポジトリを 1 Intent でまとめる DRE のようなデータ基盤チームでは、1 つの機能を作るのに複数のリポジトリが絡みます。 典型的なワーク 例えば「ある外部 SaaS のデータを BigQuery に自動転送するパイプラインを構築する」といった Intent だと、以下のようなリポジトリにまたがる変更が必要になります。 GCP Terraform リポジトリ : IAM やデータセットの定義 Composer インフラリポジトリ : Cloud Composer や Secret Manager の Terraform Composer DAG リポジトリ : Cloud Run Job と Airflow DAG のコード dbt リポジトリ : staging モデル これを 1 つの Intent としてまとめます。まず Inception フェーズで全体の要件・設計を固め、その後 Construction フェーズで各リポジトリに Unit を切って進めます。例えば DRE の 2026 年 2 月に動かしたあるパイプライン構築 Intent では、4 ユニット・60 ドキュメント・6 PR で完了しました（規模感の一例として）。 ブランチ戦略の 2 階建て ドキュメントとコードで別々のブランチ戦略を使い分けています。 Workspace リポ : session/<intent_name>/<hex> という短命ブランチ。スキル呼び出し単位で切って都度 main にマージ コードリポ : feature/<intent_name> という長命ブランチ。Intent が完了するまで維持 Workspace 側はドキュメントの進捗を小さくマージして積み上げ、コードリポ側は実装が揃ったタイミングで main に入れる、という二層構造です。 aidlc-state.md に Code Repositories を記録 1 つの Intent が複数リポジトリに触るので、どのリポのどのブランチで作業しているかを aidlc-state.md に記録しておきます。 ## Code Repositories - < dbt-repo > (feature/ < intent _name> ) - < composer-dag-repo > (feature/ < intent _name> ) - < composer-infra-repo > (feature/ < intent _name> ) - < gcp-terraform-repo > (feature/ < intent _name> ) Intent を再開するときも、Claude Code がどのブランチをチェックアウトすればよいか即判断できます。 横断ドキュメントとして蓄積される Inception で作る requirements.md や application-design.md は、複数リポジトリにまたがる機能の「横断的な設計書」になります。公式ペーパーではこうした成果物を "semantically rich context memory" と呼んでいて、AI がライフサイクル全体で参照する知識として機能します。 「1 機能 = 複数リポジトリ」というデータチーム特有の性質と、AI-DLC のコンテキストメモリの思想が、意外とうまくかみ合った部分です。 並列 Unit と audit.md 分散 モブとは別に、1 つの Intent の中で独立した複数 Unit を並列処理で進めるケースもあります。これは、Worktree で複数の Claude Code Agent を同時起動する方式です。このとき地味に困ったのが audit.md の Git コンフリクトです。並列の Agent が 1 つの audit.md に書き込もうとして衝突します。 対策として、 audit.md は Intent レベルのマイルストーンのみ記録する役割に限定し、Unit 内の詳細ログは construction/<unit>/audit.md に分散する運用にしました。このルールは .claude/rules/parallel-unit-audit.md に定義しています。 6. モブでの意思決定: なぜモブにしたか DREチームではメンバー 5〜6 名でモブワークを組み、1 日 3 ~ 4 時間をこれに充てています。全員フルリモートのため、公式ペーパー推奨の「物理集合 + 共有スクリーン」ではなく、Google Meet を接続して画面共有しながら進めています。本章では「なぜモブにしたか」と「どう使い分けているか」を DRE 視点で書きます。 3 つの狙い モブを採用する狙いは、マーク・パール『モブプログラミング・ベストプラクティス』で挙げられている利点と重なります。特に以下の 3 つが今の DRE に効いています。 フロー効率（Loss function を強化する） 章 2 で触れた通り、AI-DLC の各ステップには人間の検証・承認ゲートがあります（"human oversight functions like a 'loss function'"）。この承認が詰まるとフロー全体が止まる構造です。 AI の確認質問（clarifying questions）に即答できる人がその場にいないと、承認ゲートで数時間〜半日止まることもあります。Intent 単位で開発を進める AI-DLC では、並行して複数の Intent を抱えるより、少数に集中する方がリードタイムが短くなります。 少人数のDREチームでモブをやると、WIP は 1〜2 Intent に絞られ、意思決定の待ち時間がほぼゼロになります。モブは AI-DLC の Loss function を強化する実装とも言えます。ただし、外部チームへの依存がある場合はこの限りではなく、PR レビュー待ちや情報提供待ちになることはあります。 キーパーソンに頼らない Cloud Composer の統合や TROCCO から dlt への移行など、DRE は新しい基盤への切り替えを多く抱えています。こうした新基盤は「誰か一人だけが仕組みを分かっている」状態になりがちで、障害対応や次の意思決定がその 1 人に依存するリスクがあります。 モブで設計判断を進めると、全員が同時に基盤の意図を理解していきます。ドキュメントで読むのと、設計を議論しながら作るのとでは、後の理解度の深さが違います。 加えて、Intent の議論は Claude Code の audit.md に自然と記録されていくので、後から加入したメンバーが「なぜこの設計にしたか」を追えるようになります。口頭の議論を議事録に起こす手間が、AI-DLC の運用中に自動で払われる形です。 AI の出力の欠陥を減らす モブで AI の出力をその場でレビューすると、一人では見逃しがちな欠陥が減ります。厳密に比較計測したわけではないのですが、集合知がうまく効いている実感はあります。 AI の提案に対して「そこは業務仕様的にこう違う」「その構成だと監視が弱くなる」「別の選択肢の方が運用が楽」といった指摘が即座に入るので、Intent 完了後に気づく修正が減っていると感じます。 使い分け: 全員モブ / 2 分割 / 個人 タスクの性質に応じて、モブの粒度を変えています。 粒度 想定シーン 全員モブ（チーム全員） Intent の Inception、新基盤の設計判断、障害対応 2 分割モブ（2 ~ 3 人 × 2） 複数 Unit を並列で進められる Construction 個人ワーク 既知パターンの実装、軽微なドキュメント整備 判断基準は「不確実性」と「依存関係」です。不確実性が高いものは全員モブ。独立した Unit に切れるなら 2 分割。どちらも低い軽微な作業は個人。 公式ペーパーでも Mob Elaboration（Inception 相当）は必須、Mob Programming（Construction 相当）は分岐可能、と書き分けられていて、DRE の使い分けもほぼこの原則通りです。 リモートモブの実装と未解決の課題 公式ペーパーが想定するモブは「物理集合 + 共有スクリーン + ファシリテーター」ですが、DRE は全員フルリモートなので、ここを読み替える必要がありました。現在の構成は Google Meet + 画面共有 + 各メンバーのローカルエディタ（VS Code / Zed / Vim など人により様々）+ Claude Code です。 タイピスト交代 タイピスト交代は時間交代式（30 分サイクル）で、現タイピストが /aidlc-intent-save スキルで作業を保存・マージし、次のタイピストが自分のマシンで /aidlc-intent-continue で引き継ぎます。 試して撤退したもの VS Code Live Share : タイピスト交代のスイッチングコストを下げる狙いで試しましたが、ターミナル共有はできても接続環境によって表示が崩れ、肝心の Claude Code 拡張機能自体は Live Share で共有できなかったため断念しました タイマーの Claude Code スキル化 : タイピスト交代を時間で促すスキルを試作したものの、時間ベースで AI セッションに割り込む仕組みが安定せず、一旦撤退。今は Google Meet のタイマー機能で運用しています バットマン 『モブプログラミング・ベストプラクティス』に登場する「バットマン」（モブの外で外部からの問い合わせや割り込みに対応するメンバー）に倣い、その日の障害対応当番はタイピストに入れない運用にしています。データ基盤の障害対応はアラート監視と並行処理が必要で、モブに入ると集中を妨げるためです。 未解決の課題: スイッチングコスト 『モブプログラミング・ベストプラクティス』では 10 分ごとの交代が目安として紹介されていますが、DRE では現状 30 分が限界です。AI-DLC を始めた当初は 1 時間以上かかっていたのを、保存・再開処理の高速化や Google Meet のタイマーで短縮してきました。それでも、各メンバーが自分のマシンで作業するスタイルでは、保存・再開を速くしても、セッションを次の人のマシンに同期し直すスイッチングコストが残ります。10 分にはまだ遠いのが現状で、ここはリモートモブの構成上の制約として残っています。 7. 3 ヶ月の数字 AI-DLC を運用してみて、何が数字で変わったかを見ていきます。 計測の方針 2025 年 10 月〜 2026 年 4 月の PR を集計しました（4 月は 4/24 時点）。対象は、DREチームのメンバー（5〜6 名程度）が author の PR に限定しています。なお、ドキュメント中心の Workspace リポは /aidlc-intent-save で作られる即マージ PR が多く数字を歪めるため、集計は コードリポジトリのみ にしています。また、他チーム調整が必要で構造的に長い PR は、上位 5% を外れ値として除外しています。 Intent 完了数 一番わかりやすい変化は、Intent 単位で開発を進められるようになったことです。 月 完了 Intent ドキュメント成果物 2026-02 0（初月、進行中 1） 60 2026-03 14 263 2026-04（4/24 時点） 17 215 2 月は AI-DLC 導入初月で Intent の完了は 3 月にずれ込みました。3 月は 14 件完了、ドキュメントは 263 ファイルが積み上がりました。4 月は月途中（4/24 時点）で既に 17 件の Intent が完了しています。 PR 数 コードリポジトリのマージ済み PR 数（DRE メンバー author 分）です。 月 コードリポ PR 2025-11 36 2025-12 24 2026-01 43 2026-02 41 2026-03 74 2026-04（4/24 時点） 58 1 日 3 ~ 4 時間をモブに充てているので、「モブで時間を使っている分、実装量は減るのでは?」という懸念もありましたが、少なくとも PR 数の面では減っていません。2026-03 で 74 件、4 月は月途中で既に 58 件のペースです。 PR サイクルタイム DRE メンバーの PR サイクルタイム（作成〜マージ）です。外れ値除外後の値です。 月 PR 数 中央値 P90 2025-10 19 1.5h 64.9h 2025-11 36 10.6h 104.7h 2025-12 24 21.2h 94.5h 2026-01 43 2.1h 89.1h 2026-02 41 6.5h 137.5h 2026-03 74 2.6h 96.5h 2026-04（4/24 時点） 58 2.2h 89.6h 月ごとのばらつきが大きく、AI-DLC 導入前後で劇的な改善があるとは言いにくい数字です。ただ、モブで 1 日 3 ~ 4 時間を使いつつ中央値 2〜3 時間台で安定しているので、モブによる時間投入に見合う速度は維持できているとは言えそうです。 注記 この期間の数字を AI-DLC の効果だけで説明するのは慎重にしたいところです。大型案件の時期的な偏りや、メンバーの稼働割合など、他の要因も混ざっています。 それでも、Intent 単位で開発を進める仕組みが 2 月から稼働し、3 月に 14 件の Intent 完了まで回せるようになったのは定量的な変化です。PR サイクルタイムの劇的改善は見えていませんが、モブで使う時間分の生産性ロスが起きていない点は、少なくともマイナスの兆候は出ていないと言えます。 何が効いていそうか（仮説） PR サイクルタイムが変わっていない一方で Intent 完了数は増えている、という組み合わせから、いくつか仮説を立てられます（断定はできません）。 WIP の削減 : 少数の Intent にチーム全員が集中することで、リードタイムのばらつきが抑えられている可能性 レビュー待ちの削減 : モブで合意してから PR を作るので、PR 段階での非同期レビュー待ちが実質なくなっている（中央値を押し下げる方向） 外部依存が P90 を支配 : P90 は 60〜140h 台で大きく変わっていません。他チームとの調整や権限待ちで止まる PR が混ざっているためと思われ、ここは AI-DLC 単独では改善しにくい部分 記事執筆時点での仮説として記録しておきます。 8. やれていないこと 3 ヶ月で骨格はできた感覚がありますが、まだうまく回せていない領域もあります。 Operations フェーズ : DRE では /aidlc-ops-incident という障害対応スキルに留まっています。chanyou さんの記事で紹介されている Operations ワークフローを取り込むのが次のステップです ハーネスエンジニアリング寄りの自動化 : コードレビューはモブで全員でやっていますが、AI にコードをレビューさせる仕組み、Claude Code の Hooks / Agents の活用、AI 出力の評価ループなど、人間介入を減らす方向（いわゆるハーネスエンジニアリング）の仕組みはまだ薄いです。モブの検証密度は保ちつつ、自動化できる部分はそちらに寄せていきたいと考えています 本記事で触れなかった工夫 本記事は Inception と Construction フェーズの実装に絞ったため、以下のような工夫は紙面の都合で触れていません。続編で書く予定です。 多角的レビュー : コンテキスト分離型のサブエージェントで Inception / Construction 成果物をレビューする仕組み Knowledge Base 体系 : Intent 横断の仕様・運用ノウハウを knowledge-base/ に蓄積し、Intent 完了時に差分提案するルール 他チームとの擦り合わせルールの統合 : 連携する別チームとの合意事項を AI-DLC ワークフローに組み込み、PR 差分の自動準拠レビューも用意 効果計測・導入促進 : 月次効果計測レポートの自動生成と GitHub Discussions 投稿、社内全体の AI-DLC 導入状況レポート 運用ガードレール : 本番環境への破壊的操作を一律禁止するルール、bash コマンド実行規約 9. おわりに 3 ヶ月運用して現時点で落ち着いている構成を書き残しました。完成形ではないですが、この方向で続けるメリットはあると感じています。 公式ドキュメントには書かれていない実装の隙間を埋める例として、同じようにデータチームで AI-DLC を運用している方の参考になれば嬉しいです。 参考 AI-Driven Development Life Cycle: Reimagining Software Engineering — AI-DLC の理念を紹介した AWS DevOps Blog AI-DLC Method Definition（Raja SP, AWS）— https://prod.d13rzhkk8cj2z0.amplifyapp.com/ — 本記事で引用した "Human oversight as loss function" 等の出典 awslabs/aidlc-workflows — AI-DLC ワークフローの原典リポジトリ（MIT-0） Building with AI-DLC using Amazon Q Developer — Amazon Q Developer を使った実践ガイド マーク・パール『モブプログラミング・ベストプラクティス — ソフトウェアの品質と生産性をチームで高める』オライリー・ジャパン タイミーのデータエンジニアリング部 DRE G では、こうしたデータ基盤の構築と AI-DLC の運用に取り組んでいます。興味がある方は、以下よりプロダクト採用サイトをご覧いただけますので、ぜひカジュアル面談などお申込みください！ 株式会社タイミー | プロダクト採用サイト

はじめに こんにちは。MercariでPMインターンをしている 菊池翔吾 です。 インターン期間中に mercari-pm-agent というClaude CodeのSkillを開発しました。PMが行う「問題の発見→データ収集→PRD作成→UIモック」の一連のワークフローを、1つのセッション内で処理するエージェントです。 この記事では、PMのワークフローをClaude Code上でどのように実装したか——Skillの設計と、MCP（Model Context Protocol）を使ったNotion・Slack・Looker・Figmaとの接続方法——を中心に紹介します。 背景：メルカリPMの情報収集ワークフローと課題 メルカリのPMが意思決定を行うには、複数のツールを横断して状況を把握する必要があります。 Notionで中期戦略・KPI目標の方向性を確認する Slackで社内の改善要望やフィードバックを検索する Lookerでユーザー行動の定量指標を確認する Figmaで対象画面の現状デザインを確認する これらを統合してPRD（製品要求仕様書）に落とし込む 各ツールへのアクセス自体は難しくありませんが、ツールを横断しながら「どのデータが今の判断に関係するか」を整理する作業には一定の時間がかかります。PMが本来時間を使うべきは、集めた情報をもとに深く考え、意思決定し、関係者と対話することのはずです。情報収集にかかる時間を、思考と意思決定に充てられるようにしたい——それがこのツールを作った動機です。 mercari-pm-agentの概要 mercari-pm-agent は、Claude CodeのSkillとして実装したPM支援エージェントです。 PMがプロダクト上のビジネス課題を自然言語で入力すると、以下のステップが自動的に進みます。 処理の流れ 実装：Claude Code SkillsでPMワークフローを定義する Claude Code Skillsとは Claude Code Skillsは、Claude Codeの振る舞いをMarkdownファイルで定義する仕組みです。 SKILL.md にエージェントの動作手順・制約・ツールへのアクセス方法を記述することで、特定の業務フロー専用のエージェントを構築できます（ 公式ガイド ）。 コードを書かずにエージェントの振る舞いを定義できる点が特徴です。PM向けSkillの実装例としては phuryn/pm-skills も参考にしました。ただし、後述するように「Markdownを書くだけ」では精度は出ません。振る舞いの制約設計と評価サイクルが重要です。 ファイル構成：関心の分離をプロンプト設計に適用する mercari-pm-agent/ ├── [SKILL.md](http://skill.md/) # エージェントの振る舞い定義（英語） └── references/ ├── [prd-template.md] # PRDテンプレート ├── [prd-checklist.md] # PRD品質チェックリスト（9項目） ├── [ui-and-figma.md] # UI Spec・Figma Makeプロンプトテンプレート ├── [laplace-guide.md] # データ解釈ガイド ├── [data-sources.md] # データソース一覧・使い方 └── [quick-reference.md] # 出力チェックリスト 初期は全ての定義を SKILL.md 1ファイルに集約していましたが、後述する評価スキルによるスコアリングを通じて、 ファイルが長くなるほど出力精度が低下する という問題を確認しました。 これはLLMの特性と関係しています。コンテキストが長くなると、モデルが文脈の中で関連情報に適切に注目できなくなる現象（いわゆる「Lost in the Middle」問題）が知られており、Anthropicのプロンプトエンジニアリングガイドでもプロンプトを簡潔に保つことが推奨されています。 対応として、 振る舞いの定義 （ SKILL.md 本体）と 参照データ・テンプレート （references/）を分離しました。ソフトウェア開発における「関心の分離（Separation of Concerns）」をプロンプト設計に適用したアプローチです。 SKILL.md はエージェントが「何をどの順序でするか」のみを保持し、具体的なデータやテンプレートは必要なタイミングでreferencesから参照する設計です。この構造変更だけでスコアが明確に改善しました。 なお、 SKILL.md は英語で記述しています。Claudeへの指示として英語の方が精度が高いためです。 MCP接続：複数ツールをエージェントに繋ぐ mercari-pm-agent の中核的な価値は、Step 2のデータ収集を自動化する点にあります。ここではMCP（Model Context Protocol）を使ったツール接続の設計について説明します。 MCPとは MCPはAnthropicが策定したオープンプロトコルで、LLMアプリケーションが外部ツールやデータソースに接続するための標準仕様です。MCPサーバーを通じて、Claude CodeからNotion・Slack・Lookerなどの外部サービスをツールとして呼び出せるようになります。 接続しているMCPサーバー MCPサーバー 種別 取得できる情報 用途 Notion MCP 公式（Notion提供） 戦略ドキュメント・KPIダッシュボード 中期戦略との整合性確認 Slack MCP 社内独自実装 社内フィードバックチャンネルの投稿 改善要望・現場の声の収集 Socrates 社内独自実装（BigQuery・Lookerベース） CVR等の指標データ 定量的な課題の裏付け Figma MCP 社内独自実装 デザインファイルのコンポーネント情報 既存デザインの取得・UI Specへの反映 並列クエリと堅牢性の設計 Step 2（データ収集）では、これら複数のMCPを 並列で クエリします。 data-sources.md に以下のルールを記述しています。 - Pull in parallel during Data Enrichment — do not wait for one source before querying another. （データ収集フェーズでは並列で参照する。1つのソースの完了を待たないこと） - If a source is unavailable, skip silently and mark it in the output. （ソースが利用不可の場合は、出力にその旨を明記してスキップする） 直列での順次参照に比べてユーザーの待ち時間を削減するためです。また、いずれかのMCPが利用不可の状態でも処理が止まらないようフォールバック設計を入れています。 セキュリティ上の考慮 Slack MCPのセットアップには社内VPN接続とUser Tokenによる認証が必要です。トークンはClaude Codeの設定ファイルに環境変数として渡す形にしており、チャット上でトークン文字列が露出しない設計にしています。また、SlackのUser Tokenは7日で失効するため、更新用のスクリプトを別途用意しています。 開発で大事にしたこと 評価基準を先に決める——プロンプトのTDD 実装を始める前に、まず「エージェントの出力をどう評価するか」の基準を定義しました。 課題の理解精度（問題の本質を正しく捉えているか） 仕様の具体性（実装可能なレベルで記述されているか） 実現可能性（技術的・リソース的に妥当か） UXの妥当性（お客さまにとって使いやすいか） これはソフトウェア開発におけるテスト駆動開発（TDD）に近い発想です。LLMベースのエージェントは「動くかどうか」より「正しく動くかどうか」の判定が難しい。評価軸を先に定義することで、プロトタイプの改善サイクルを感覚ではなく基準で回せるようになりました。実際のWeb改善課題を収集して評価データセットを作り、反復的に精度を上げていきました。 LLMの「それらしい嘘」を制約として防ぐ LLMを業務フローに組み込む上で最も危険なのは、「根拠のないそれらしい情報」の生成です。データが存在しない状況でも、モデルは自然に「それっぽい数値」を出力します。PMがその数値を信じてPRDに記載してしまうと、意思決定の根拠がフィクションになります。 これは「嘘をつくな」とプロンプトで命令するだけでは解決しません。モデルがデータ不足を認識したとき、どう振る舞うかを 制約として設計 する必要があります。 Data integrity rules: Unconfirmed data must be labeled "Not provided" or "To be validated" （未確認のデータは "Not provided" または "To be validated" とラベルすること） Never fabricate numbers or sources （数値や出典を捏造しないこと） さらに、PMの確認なしに次のステップへ自動的に進むことを禁じました。 You are NOT allowed to infer completeness. Only explicit confirmation from the PM allows progression. （完了を推測して次へ進むことを禁じる。PMの明示的な確認があった場合のみ次へ進める） これにより、エージェントが「それらしい流れ」で自動進行するのではなく、常にPMが意思決定のドライバーである状態を維持します。 スキルをスキルで評価する——自動評価パイプライン 設計したルールが実際に機能しているかを検証するため、評価専用のスキル（ skill-creator-max ）を別途作成しました。 mercari-pm-agent に対してテストケースを投げ、出力の品質をスコアリングして返すエージェントです。このスコアを使った反復改善の中から、前述の「 SKILL.md は短いほど精度が上がる」という知見が得られ、ファイル分割の設計変更につながりました。 まとめ mercari-pm-agent の開発を通じて得た、Claude Code Skillsを使ったエージェント設計の主な知見をまとめます。 Skillの設計は「振る舞いの仕様書」を書くことに近い。  命令ではなく制約の設計が重要で、LLMが「どう振る舞うべきでないか」を明示することが精度に直結する。 MCPによる外部ツール接続は並列設計で。  直列参照はユーザー体験を悪化させる。フォールバック設計とあわせて、接続の堅牢性を考慮する必要がある。 プロンプト設計にも関心の分離が有効。  コンテキストが長くなるほど精度が下がる。振る舞い定義と参照データの分離は、ソフトウェア設計の原則をLLM設計に適用した結果として機能した。 評価基準は実装より先に作る。  LLMエージェントの品質評価は主観に陥りやすい。評価軸を先に定義し、評価専用のエージェントを作ることで客観的な改善サイクルが回せる。 mercari-pm-agent はClaude CodeのSkillとして実装しているため、MCP設定が済んでいれば /mercari-pm-agent のコマンド1つで起動できます。 PMの業務効率化やClaude Code Skillsを使ったエージェント設計に興味のある方の参考になれば幸いです。