AI Catalog グループ

概要

AI Catalog グループは、GitLab ユーザーがエージェント、フロー、MCP サーバー、スキルなどの AI 搭載オブジェクトを発見、評価、有効化、管理するための場を構築することに注力しています。私たちは Explore、Group、Project の各スコープにわたるカタログ体験を担当し、プロダクト、デザイン、エンジニアリングを横断して、AI オブジェクトをどのように作成、キュレーション、提示し、信頼できるものにして活用するかを定義します。

チームメンバー

AI Catalog

Type	Names	Count
PM	Roman Kolosovskiy	1
UX	Michael Moyers	1
EM		0
FEM		0
Engineering		0
Total		2

連絡方法

状況に応じて、AI Catalog グループに連絡する最も適切な方法は以下のとおりです。

• Slack チャンネル: #g_ai_catalog
• GitLab グループ @gitlab-org/ai-powered/ai-catalog/engineering（エンジニアのみ）

取り組んでいること

未定

私たちの担当範囲

• GitLab for Slack アプリは、 このグループ内の External Agents 機能チーム （#f_external-agents）が 所有しています。 リリースとマニフェストのプロセスを参照してください。

私たちの働き方

私たちはまだ始まったばかりで、新しいチームに馴染んでいきながら働き方を定義していきます。 始めるためのいくつかのリンクを以下に示します。

• ルートエピック: すべての作業をグループ化し、ロードマップを設定するため
• Issue ボード: 進行中のすべての Issue 用
• チームタスク: プロダクトに関連しないすべてのチーム Issue 用
• 非同期アップデート
• チーム Wiki: プロダクトの意思決定と有用な情報のため

DRI

大規模なプロジェクトに取り組む際は、それをエピックと Issue に分割します。 各エピックの Directly Responsible Individual（DRI）は、その領域に対する単一の説明責任を担います。 DRI は必ずしもすべての作業を行うわけではありませんが、自分のエピックの成功を所有します。

DRI の責任:

1. エピックのステータス、範囲、技術的な意思決定に関する質問に答える
2. 正確なエピックと Issue の説明を維持する
3. デリバリーの健全性ステータスを監視し伝える
4. Issue リストをキュレーションする。必要なものを含め、不要なものを削除する
5. 作業が複数のエピックにまたがる場合、他の DRI と調整する

支援の依頼への対応方法

お客様がカタログで問題を経験している場合、Support チームが 支援の依頼（request for help）を提起します。 支援の依頼を提起したい場合は、その方法とタイミングについての指示をこちらの readmeで読んでください。

チーム全体の気を散らすことなく支援の依頼にタイムリーに対応するために、各マイルストーンにゴールキーパーを任命します。 ゴールキーパーは、入ってくる依頼、質問、Issue がトリアージされ、適切な人やチームに振り分けられるようにする責任があります。

各マイルストーンで、新しいゴールキーパーをアサインし、ゴールキーピングの Issue を作成します。

詳細はIssue テンプレートで確認できます。

コミュニケーション

AI Catalog チームは、以下のガイドラインに基づいてコミュニケーションを行います。

• 同期的なミーティングよりも、常に非同期コミュニケーションを優先します。
• 非同期では非効率であることがわかった場合は、同期通話を設定することを躊躇しないでください。ただし、チームメンバーと共有できるように常に録画します。
• デフォルトでオープンにコミュニケーションを行います。
• 仕事関連の Slack メッセージでは、プライベートメッセージよりも公開チャンネル（#g_ai_catalog）を優先します。

フロントエンドとバックエンドの協業

私たちは、開発のスピードとコード品質を確保するために、フロントエンドエンジニアとバックエンドエンジニアの間で高いレベルの協業を促進することを目指しています。

• スキーマファースト開発： 実装を開始する前に、フロントエンドエンジニアとバックエンドエンジニアが協力して、 UI 要件、ユーザーエクスペリエンスのニーズ、パフォーマンスの考慮事項に基づいて GraphQL API スキーマを設計します。
• 並行開発プロセス： スキーマが合意されると、フロントエンドは合意したスキーマに一致する モックデータ、モックエンドポイント、または API スタブを使用して進めることができます。バックエンドは、 データモデル、ビジネスロジック、実際の API スキーマの実装に集中できます。
• 整合性の維持： 私たちは優れたコミュニケーションを重視します。要件やスキーマを変更する必要がある場合は、 関連する GitLab Issue または #g_ai_catalog で早めに伝え、 フロントエンドやバックエンドのカウンターパートがすべての変更を把握し、後の段階でブロッカーになるのを避けるために早めにフィードバックを提供できるようにします。

AI ステージとの協業

AI Catalog は、基盤となるバックエンドサービスとして Workflow Service に依存しています。 AI Catalog のほとんどの機能は Workflow Service 内で新しい機能を開発する必要があり、 これは私たちのエンジニアが Agent Foundations内の他のチームと連携して、 そのコードベースに直接貢献する必要があることを意味します。

協業の要件:

• すべての Workflow Service への貢献は、Agent Foundations チームと密接に連携して開発する必要があります
• 私たちの実装は、Agent Foundations のサービスアーキテクチャとビジョンに沿ったものでなければなりません
• 私たちは、Workflow Service のより広範な目標をサポートし、その技術基準を遵守することにコミットします

協業のプロセス:

• 計画フェーズ中に、関連する Agent Foundations の連絡先（以下に記載）に連絡します
• Agent Foundations の #g_duo-agent-platform チャンネルに参加します
• デフォルトで私たちの非同期コミュニケーションの方針に従いますが、必要に応じて同期ミーティングを設定し、主要な成果が GitLab Issue に文書化されるようにします

主要な Agent Foundations の連絡先

計画のサイクル

私たちは GitLab のプロダクトマイルストーンに合わせて作業を計画し、整合させます。マイルストーンの計画は、次のマイルストーンが始まる前の週に行われます。

Issue の分解と重み付けは、マイルストーンが始まる前の計画週に完了する必要があります。分解と重み付けが完了していない Issue やエピックを ~Deliverable としてコミットすることはできません。

計画期間内に Issue やエピックを分解できない場合は、マイルストーン作業の一環として Product や Design と調査・コラボレーションを行うための Spike Issue をマイルストーンに追加します。スパイクの結果に基づいてエピックを更新し、追加の Issue を作成します。

~Deliverable と ~Stretch ラベル

マイルストーンに割り当てられたすべての Issue は、トリアージされ、~Deliverable または ~Stretch のいずれかのラベルが付けられます。 これらのラベルは Issue にのみ適用されます。エピックには ~Deliverable または ~Stretch を付けてはいけません （マイルストーン内のエピックを参照）。

• ~Deliverable: チームがマイルストーン内に完了することをコミットした作業です。これらの Issue には重みが必要です。
• ~Stretch: トリアージ済みですがコミットされていない作業です。すべての ~Deliverable Issue が完了したら、Stretch Issue を取り上げます（優先順位付けを参照）。

~Deliverable ラベルは複数の目的を果たします。

• コミットメントのシグナル： この作業をマイルストーン内で完了する意図があることを、ステークホルダーやお客様に伝える
• 優先順位付け： チームメンバーがどの Issue に最初に取り組むべきかを識別するのを助ける
• 焦点： マイルストーンにとって必須の作業とあれば嬉しい作業を明確にする

誰がいつ適用するか

Engineering Manager は、マイルストーンが始まる前の計画プロセス中に ~Deliverable と ~Stretch のラベルを適用します。 この決定は、以下に基づいて Product Manager と協力して行われます。

• マイルストーンのチームのキャパシティ
• Issue の見積もりと複雑さ
• 戦略的な優先事項とお客様へのコミットメント

マイルストーン内のエピック

エピックには ~Deliverable または ~Stretch を付けません。これらのラベルは Issue にのみ適用されます。

• 現在のマイルストーンにコミットされたエピックには、そのマイルストーンにもコミットされた Issue のみを含める必要があります。
• エピックが単一のマイルストーンより大きい場合は、各イテレーションがマイルストーンに収まるよう、サブエピック（イテレーション 1、2 など）に分解する必要があります。

優先順位付け

~Deliverable ラベルが付いた Issue は、マイルストーン内の他の作業よりも優先されます。 チームメンバーは以下を行うべきです。

1. まず、現在のマイルストーンでアサインされた ~Deliverable の Issue に取り組む
2. すべての ~Deliverable の Issue が完了またはブロックされている場合、マイルストーンから ~Stretch の Issue を取り上げる
3. 優先順位が不明確な場合、または ~Deliverable の Issue の優先度を下げる必要がある場合は、Engineering Manager に相談する

マイルストーン中:

• ~Deliverable の Issue がブロックされたり完了できなくなったりした場合は、#g_ai_catalog または関連する Issue で早めに伝える
• Engineering Manager は、優先順位やキャパシティの変化に基づいて、マイルストーン中に ~Deliverable と ~Stretch のラベルを調整する場合があります

重み付け

Issue はフィボナッチ数列（0、1、2、3、5、8+）を使用して重み付けされます。

• 重み 1： 不確実性が最小限の単純な Issue（新規コントリビューターに適しています）
• 重み 2： 複数のコード/テスト更新を必要とする、直接的な Issue
• 重み 3： ある程度の複雑さがあるものの、スコープを管理できる大きめの Issue
• 重み 5： 通常は分解する必要があります
• 重み 8+： 分解が必要であることを示すプレースホルダーの重み。即時実装には大きすぎるか、不確実性が高すぎます

ステータスアップデート

全員が、担当する ~Deliverable と ~Stretch の Issue およびエピックについて、金曜日までに、またはそれ以前の方が合理的であれば早めに、非同期の週次ステータスアップデートを提供します。

• アップデートのコメントは ## Weekly Status · YYYY-MM-DD · <On Track | Needs Attention | At Risk | No Status | Complete> で始めます。 過去 6 日以内に Weekly Status のコメントを手動で投稿している場合、AI が生成する週次サマリーはスキップされます。
• 3 日以上の作業を要する Issue ではアップデートが求められます。1 日か 2 日で完了する Issue にはアップデートは不要です。
• エピックが主要な ~Deliverable であり、その子 Issue がすべて小さい（作業期間が 3 日未満）場合は、 エピック自体に週次アップデートを投稿します。
• workflow:: ラベルと健全性ステータスを最新に保ち、アサインされた担当者（DRI）を明確にします。 健全性ステータスの評価が実態と一致しない場合は、手動で更新します。

私たちの技術スタック

• GraphQL のバックエンドと フロントエンド。すべての新しいスキーマアイテムは、 必要なときに破壊的変更を行えるように実験的としてマークする必要があります。
• ポーリングではなく GraphQL サブスクリプション。
• AI Catalog Backend Architecture のデザインドキュメント（2026 年 2 月に執筆）を読んでください。

UX 原則

すべてのデザインとエンジニアリングの意思決定を導く、AI Catalog の UX 原則を参照してください。 これは、カタログに貢献するすべての人がトレードオフを判断する前に意図をすり合わせるための参照点です。

チームミーティング

AI Catalog: グループミーティング

• 時間： 毎週火曜日、05:30 UTC と 15:00 UTC を週ごとに交互に。
• 目的： このミーティングは、現在の Issue やブロッカーを取り上げるための一般的な同期ミーティングとして機能します。
• アジェンダ： Google Doc（内部のみ）
• 録画： Google Drive（内部のみ）

ページのソースコードを見る - ページの編集 - please contribute.