integration-orchestrator

インテグレーション・オーケストレーター

ブリーフは、チームに何を作るかを伝えます。クリエイティブディレクションは、それがどんな雰囲気であるべきかを伝えます。どちらも、それぞれの決定がいつ確定するのか、誰が何をレビューするのか、前のフェーズが完了する前に次のフェーズが始まるのを何が止めるのかは伝えません。このスキルが埋めるのは、そのギャップです。

出力されるのは、PM が月曜の朝にカレンダーへ貼り付け、火曜から運用を始められる、フェーズ分けされたオーケストレーション計画です。フェーズ、ゲート、確定ポイント、引き継ぎ、QA 検証ルールに加え、チームが実際に使っているスタック（Jira、Linear、Notion、Figma、GitHub、アジャイルスプリント）に合わせたプラットフォーム固有の実装ガイドを含みます。

---

このスキルについて

クリエイティブディレクションを伴うプロジェクトには、3 つのレイヤーがあります。ブリーフのレイヤーでは、スコープ、対象者、成果物、制約、成功基準を定義します。ディレクションのレイヤーでは、トーン、審美性、関係性、感覚的な目標を定義します。どちらも文書化された成果物を生み出します。しかし、どちらも時間に関する問いには答えません。ブリーフはいつ確定するのか、アイデンティティはいつ確定するのか、コピーはいつ確定するのか、それぞれを誰がレビューするのか、ゲートが開いている間に何がブロックされるのか、後続タスクでブリーフの誤りが判明したらどうするのか、「完了」が自己申告ではなくテスト済みであることをどう確認するのか、といった問いです。

このスキルは、その時間軸のレイヤーを作成します。ほとんどのチームにはブリーフとクリエイティブディレクションはありますが、オーケストレーション計画がありません。その結果、3 週目には、どの決定がまだ未確定で、どれが確定済みなのかについて共通認識のないまま、全員が並行して作業しています。ブリーフのずれ。やり直し。コピーが古いトークンを前提にすでに作成された後で、アイデンティティトークンが変更される。デザインがレビューする機会を得る前に、エンジニアリングがリリースする。実際には一度も検証されていない「完了」チケット。

オーケストレーション計画は、これらすべてに答えます。これは理論ではありません。カレンダー上の週を示すフェーズ別タイムライン、PM が Jira や Linear に貼り付けられるチケットテンプレート、セットアップ用の MCP コマンド、測定可能な合格基準を備えたゲート定義、成果物要件を伴う引き継ぎ仕様、そして Playwright または Chrome MCP の呼び出しを使った QA 検証ゲートです。

---

使用する場面

• 新しいブランド構築、リブランディング、キャンペーンを開始し、作業の順序を決める必要があるとき
• 進行中のプロジェクトでブリーフを見直しており、後続作業が頻繁なリセットに悩まされているとき
• MCP と CLI の連携を使った、新しいチームのエージェント主導ワークフローを設定するとき
• ブランド、デザイン、エンジニアリング間の引き継ぎがうまくいっていない、複数チームが関わる作業を進めるとき
• 「完了」を自己申告ではなく、測定可能にする QA 検証ゲートを設けるとき
• 場当たり的なオーケストレーションから、文書化された運用サイクルへ移行するとき
• 進行中のチケットはあるものの、作業順序が文書化されていない既存プロジェクトに、新しい PM やデザインリードをオンボーディングするとき
• 既存のワークフローに新しいプラットフォームやツールを追加し、運用サイクルを再構成する必要があるとき

---

使用しない場面

• 成果物がプロジェクトブリーフそのもの（スコープ、対象者、成果物、制約、成功基準）である場合は、代わりに creative-brief を使用してください。オーケストレータースキルはブリーフを入力として受け取ります。
• 成果物が審美的なディレクション（トーン、審美性、関係性、感覚）である場合は、creative-direction を使用してください。オーケストレーターはディレクションに沿った作業をスケジュールしますが、ディレクション自体は作成しません。
• 汎用的なプロジェクト管理ソフトウェアはプラットフォームです。このスキルは、そのプラットフォーム上で実行する計画を作成します。チームがツール選定の支援を必要としている場合は、このスキルを実行しないでください。ツールスタックはすでに選定済みであることを前提としています。
• ストーリーポイント見積もり、レトロスペクティブ、ベロシティチャートといったスプリント計画の手法は、オーケストレーションの後続工程にあたります。このスキルは運用サイクルを作成し、スプリント計画でその内容を埋めます。

---

必須入力

• プロジェクトの種類。 新規ブランドの構築、リブランド、単一のランディングページ、キャンペーン、アイデンティティの刷新、ウェブサイトの刷新、マイクロサイト、製品ローンチです。種類に応じて標準的なフェーズ分割が決まり、このスキルが具体的なプロジェクトに合わせて調整します。
• チーム構成。 総人数と役割の内訳です。1人、小規模（2〜3人）、中規模（4〜7人）、大規模（8人以上）から選びます。AI エージェント（Claude Code、Claude in Chromeなど）が制作、QA、またはその両方に参加するかどうかも指定します。
• ツールスタック。 チームが Jira、Linear、Notion、Figma、GitHub のどれを使用しているかを指定します。既知であれば、QA ツール（Playwright、Chrome MCP、Windows MCP、モバイルテスト用ハーネスなど）も指定します。さらに、コミュニケーションとページングのチャネル（Slack、メール、ツール内のメンション）も指定します。出力は実際のスタックに合わせて調整されます。
• 目標スケジュール。 エクスプレス（スケジュールを圧縮し、レビュー担当者を減らして、手戻りリスクの増加を許容）、標準（そのプロジェクト種類の標準期間で一般的な進行）、または詳細（レビュー担当者を増やし、正式なフェーズレビューを実施して、納期の遅れと引き換えに手戻りリスクを抑制）から選びます。
• 既存の制約。 すでに確定しているものは何ですか？ 承認済みのブリーフ、確定済みのアイデンティティ、固定されたプラットフォーム、すでに公開済みのブランドボイス、変更不可のコンテンツ管理システムなどです。オーケストレーターの計画は新規プロジェクトと進行中のプロジェクトの両方に対応します。既存の制約を入力することで、進行中のプロジェクトにも対応できます。
• AI エージェントの参加。 どのワークフローにエージェントがどの程度参加するかを指定します。例：Claude Code はリポジトリ内の状態ファイルを参照して制作タスクを実行する。Claude in Chrome はステージング環境で、人が読みやすいQAフローを実行する。エージェントは Linear MCP と GitHub MCP にアクセスできるが、Jira にはアクセスできない。エージェントはチケットを Todo、In Progress、Waiting、Blocked の間で移動できるが、Done には移動できない（Done にするには人による検証が必要）。
• リスクプロファイル。 チームが特に懸念している障害モードを指定する任意の入力です。ブリーフとのずれ、並行作業の競合、QAの漏れ、エージェントの暴走などがあります。オーケストレーション計画では、指定されたリスクへの対策を優先して組み込みます。

---

フレームワーク：オーケストレーションに関する7つの考慮事項

デリバリーのオーケストレーション計画は、7つの考慮事項が交わるところに位置します。それぞれが、その後の選択肢を絞り込みます。

1. フェーズ分割

プロジェクトをどのようにフェーズに分けるかです。標準的な構成は、ディスカバリー、方向性の策定、アイデンティティ、制作、QA、ローンチです。すべてのプロジェクト種類で、すべてのフェーズを使うわけではありません。キャンペーンではアイデンティティのフェーズを省略します（確定済みのブランドアイデンティティを引き継ぎます）。ランディングページでは、ディスカバリーと方向性の策定を1つのブリーフフェーズにまとめます。リブランドでは、ディスカバリーを監査に置き換えます（ポジショニングはすでに明らかなため、監査で維持するものを評価します）。

プロジェクトにおいて重要なのはフェーズの構成そのものより、次の2つの問いに明確に答えることです。1つ目は、後続のフェーズが前のフェーズの成果物なしには開始できないため、順番に進めるフェーズはどれか。2つ目は、成果物が互いに依存しないため、並行して進められるフェーズはどれか。コピーの制作は、トーンの軸上の位置（アイデンティティの一部）に依存するため、アイデンティティの完了後に開始する必要があります。QAはローンチ前に完了する必要があります。ディスカバリーと監査は、ブリーフの作成と並行して進められる場合があります。ブリーフは、得られたディスカバリーの知見を随時取り込むためです。

2. ゲート

ゲートとは、フェーズの移行を管理する承認のタイミングです。標準的なゲートには、ブリーフの承認、方向性の承認、アイデンティティの承認、ボイスの承認、コピーの承認、デザインの承認、QA 検証、ローンチ準備の確認があります。各ゲートには、トリガー（ゲートを開く作業）、承認者（合格を判断する人またはテストスイート）、合格に必要な基準（合否を判断する測定可能な事項）、ゲート通過まで保留される事項、前のゲートですでに確定している事項があります。

基準が測定可能であれば、ゲートは機能します。「ブリーフを承認済み」では曖昧すぎますが、「クライアントがブリーフの成果物に書面で署名する、または記録されたレビューで承認する」であれば測定可能です。「QA に合格」では曖昧すぎますが、「Playwright のクリティカルフロースイートがすべて成功し、コンソールエラー数がベースライン以下で、アクセシビリティの最低基準を維持している」であれば測定可能です。測定できないゲートは政治的な駆け引きの場になり、測定できるゲートは構造的な仕組みになります。

3. ロックポイント

ロックポイントとは、成果物が変更不可になるタイミングです。ブリーフは方向性の承認後にロックされます。アイデンティティトークンはアイデンティティのゲート後にロックされます。ボイスルールはボイスの承認後にロックされます。コピーはコピー承認後、ページごとにロックされます。一度ロックされると、後続の作業でその成果物を変更することはできません。変更するには正式な変更リクエストを通じて、依存する作業の再レビューを行う必要があります。

明確なロックポイントがなければ、どの成果物も概念上はいつまでも編集可能なままです。それがブリーフの逸脱の原因です。オーケストレーション計画では、どのゲートで何をロックするのか、ロックされた成果物をどこに保存するのか、誰が変更をリクエストできるのか、変更が承認された場合に何を再レビューするのかを明記します。ロックは最終確定と同じではありません。ロックとは、「これ以降に変更すると後続作業のレビューが発生するため、慎重に変更してください」という意味です。

4. 引き継ぎ

引き継ぎとは、フェーズやスキルの間で作業を移管するタイミングです。標準的な引き継ぎには、ディスカバリーからブリーフへ、ブリーフからアイデンティティへ、ブリーフからボイスへ、アイデンティティとボイスからコピーへ、アイデンティティとコピーからデザインへ、デザインからエンジニアリングへ、エンジニアリングからローンチへ、があります。それぞれが特定の成果物と決定事項を引き継ぎます。また、それぞれの引き継ぎでは、未決のまま残す事項とロックする事項があります。

さらに、横断的な引き継ぎとして、隣接事項の観察を共有する引き継ぎがあります。ホームページのヒーロー部分に取り組んでいるとき、エージェントや人が、フッターのコピーが新しいボイスと一致していないことに気づいたとします。その観察事項は現在のタスクではありません。プロジェクトのトリアージキューに観察事項として記録します。PM またはテックリードが定期的に観察事項を確認し、適切なチケットに振り分けます。このパターンにより、現在の作業に集中しながら、チームが見落としたり、対応のために現在の作業を中断したりしない限り失われていた、文脈に関わる発見も残せます。

5. チーム規模に応じた調整

2 人のチームと 12 人のチームでは、必要なオーケストレーションが異なります。1 人での作業では、1 人がすべての役割を担います。小規模（2～3 人）では、各ゲートにレビュー担当者を 1 人配置し、非同期の引き継ぎで問題ありません。中規模（4～7 人）では、複数のレビュー担当者と非同期の同期ポイントが必要です。大規模（8 人以上）では、正式なフェーズレビュー、オーケストレーション専任の PM、明示的なトラック横断の同期ミーティングが必要です。これらがないと、並行するトラックが互いにずれていきます。

オーケストレーション計画の出力は、規模に応じて調整されます。1 人の場合は、各フェーズにセルフレビュー用チェックリストを用意します。小規模の場合は、各ゲートに「レビュー担当者」を割り当てます。中規模の場合は、レビュー担当者をローテーションし、フェーズ内に小さなゲートを設けます。大規模の場合は、正式なフェーズレビュー、トラック横断の同期、ブリーフオーナーの役割を設けます。フレームワークは同じですが、レビューの頻度とミーティングの形式が変わります。

6. ツールスタックの実装

フェーズとゲートは概念として存在しますが、ツールで実装します。オーケストレーション計画では、プラットフォームごとの実装方法を指定します。Jira では、フェーズを「Phase」「Locked」「Approver」「Gate Status」のカスタムフィールドを持つエピックにします。Linear では、フェーズをサイクルとラベルに基づくビューを備えたプロジェクトにします。Notion では、概要をデータベースの行にし、方向性ドキュメント、アイデンティティ仕様書、ボイスガイド、コピー集に結び付けるリレーションプロパティを設定します。Figma では、フェーズをフレーム単位のレビュー状況を備えたライブラリフォルダーにします。GitHub では、フェーズをブランチ保護、PR テンプレート、CODEOWNERS に基づくレビューの割り当てと連動させます。

MCP が存在する場合（Atlassian、Linear、Notion、GitHub）、計画では、MCP が実行できるオーケストレーション設定の操作と、手動の UI 操作として残るものを指定します。MCP が限定的な場合（Figma の Dev Mode MCP は開発モードに特化しており、デザインライブラリの設定は引き続き手動）、エンドツーエンドの自動化が可能であると主張せず、推奨方法を記載します。

7. 自動化と QA 検証

このフレームワークで最も重要な規律です。自動検証に合格した後にのみ、タスクは「QA」から「Done」に移行します。これにより、「Done」は自己申告ではなく、測定可能なゲートになります。

標準のステータス分類は、Todo、In Progress、Waiting、Blocked、Done です。Blocked は Waiting とは異なる、独立したステータスです。Waiting は通常の引き継ぎや予定されているレビューのためにタスクが一時停止していることを意味し、Blocked は特定の問題を人間が解決しない限りタスクを進められないことを意味します。エージェントは自律的に作業を解決できない場合、タスクを Blocked にします。これにより、エージェントが解決不能な問題に取り組み続け、コンテキストを消費するのを防ぎます。

QA 検証ゲートは自動的に起動します。Playwright MCP は重要なフローのテストを実行し、Chrome MCP は人間が読みやすい手順を実行して証拠を記録し、Windows MCP はデスクトップアプリに対応し、モバイルテスト用ハーネスはモバイルアプリケーションを対象とします。失敗した場合は Blocked にし、失敗によって無関係な問題が明らかになった場合は関連する観察事項を記録し、設定済みのチャネルを通じて人間に通知して、処理を停止します。エージェントは自律的に再試行しません。

---

一般的なプロジェクトタイプ別のケイデンス

7つのテンプレートです。それぞれのフェーズを骨組みとして示しており、ケイデンスパターンのリファレンスファイルで詳しく説明しています。

• 新規ブランド構築。 5つのフェーズで6〜8週間：ディスカバリー（1週間）、方向性の決定（1週間）、アイデンティティ（1〜2週間）、制作（2〜3週間）、ローンチ（1週間）。各フェーズの後にゲートを設け、コピー制作を始める前にアイデンティティを確定します。
• リブランド。 4つのフェーズで4〜6週間：監査（1週間。ディスカバリーに代わる）、方向性の決定（1週間）、アイデンティティ（1〜2週間）、制作（1〜2週間）。監査では、ポジショニングとオーディエンスが把握済みであることを前提とします。何を維持し、何を削除し、何を刷新するかを評価します。
• 単一のランディングページ。 3つのフェーズで1〜2週間：ブリーフ（2〜3日）、制作（5〜7日）、QA・ローンチ（1〜2日）。アイデンティティとトーン・オブ・ボイスは確定済みであることを前提とします。作業対象はページ固有のコピー、デザイン、エンジニアリングです。
• キャンペーン。 4つのフェーズで2〜4週間：ブリーフ（3〜5日）、制作（1〜2週間）、QA（3〜5日）、ローンチ（1〜2日）。ブランドアイデンティティとトーン・オブ・ボイスが存在し、確定済みであることを前提とします。
• アイデンティティ刷新。 3つのフェーズで3〜4週間：監査（1週間）、アイデンティティ（1〜2週間）、制作（1週間）。ディスカバリーとポジショニングは省略します。成果物は、適用例の制作に進む、刷新されたアイデンティティシステムです。
• ウェブサイト刷新。 4つのフェーズで4〜8週間：監査（1週間）、方向性の決定（1週間）、制作（2〜4週間）、QA・ローンチ（1〜2週間）。監査でポジショニングの不足が明らかになった場合、方向性の決定でブリーフを刷新することがあります。
• マイクロサイトまたは製品ローンチ。 4つのフェーズで3〜5週間：ブリーフ（3〜5日）、制作（2〜3週間）、QA（3〜5日）、ローンチ（2〜3日）。マイクロサイトや製品のローンチでは、通常、固定のローンチ日があり、それを起点に逆算して計画します。

各ケイデンスは、PMがカレンダーに貼り付けてすぐに運用を始められるように記述されています。可能な限り、フェーズの区切りを暦週に合わせています。チームは実際にそのように計画するためです。

---

失敗パターン

オーケストレーション計画は、こうした失敗を防ぐためにあります。どれも実際のプロジェクトで確認された、現実に起こりうる失敗モードです。

• ブリーフが一度きりの文書になる。 ブリーフを作成して承認した後、誰も参照しなくなります。後続の作業が本来の方向からずれていきます。対策：ゲートでブリーフをロックし、ブリーフへの参照は編集ではなく閲覧として扱います。
• 依存する作業を再レビューせずに、進行中にブリーフの凍結を解除する。 誰かがブリーフの対象読者やポジショニングを調整しても、その変更は、古いバージョンに依存しているアイデンティティ、トーン、コピーに反映されません。対策：正式な変更リクエストのプロトコルを設け、依存する成果物の再レビューを開始します。
• トーンが決まる前にアイデンティティがロックされる。 トーンの承認前にタイポグラフィが確定します。その結果、書体とトーンの方向性が衝突します（厳格な書体に親しみやすいトーン、またはカジュアルな書体に真面目なトーン）。対策：トーンの承認ゲートを、アイデンティティのロック前または同時に実施します。
• トーンがロックされる前にコピー制作を始める。 ライターは変わり続ける目標に向けて原稿を作成します。元の草稿がロック済みのトーンと比較されないため、手戻りが見えません。対策：コピー制作の前にトーンを承認します。
• 複数の並行デザイントラックで、ブリーフとの整合性が失われる。 トラック A とトラック B がブリーフをそれぞれ少しずつ異なる解釈で捉え、第 3 週には別々のブランドのように見えるようになります。対策：トラック間の同期ミーティングと、ブリーフオーナーの役割を設けます。
• デザインが確定する前にエンジニアリングを始める。 まだ変更中のデザインをもとにコンポーネントが構築されます。デザインが別の方向に決まると、後続の作業で手戻りが発生します。対策：影響を受ける領域のエンジニアリングを始める前に、デザイン承認ゲートを設けます。
• レビューがフェーズの最後に集中する。 全員が最終日までレビューを先送りし、ゲートが 10 時間に及ぶレビューのマラソンとなり、承認者は疲労した状態で承認します。対策：フェーズ内に小さなゲートを設け、レビューの負荷を分散します。
• 成果物の指定がない非同期の引き継ぎ。 必要な成果物（Figma ファイルの URL、エクスポートしたトークン、アセットライブラリの参照、PR ドラフトのテンプレート）を指定せずに「デザインをエンジニアリングに引き継ぐ」と、エンジニアリングチームは必要なものを探すために、Slack のスレッドをいくつも確認することになります。対策：引き継ぎごとに成果物を明確に指定します。
• QA ゲートが自己申告に頼っている。 検証されないまま、「完了」チケットが「完了」に移されます。バグが本番環境に入り込みます。対策：ステータスが「完了」に移行する前に自動検証を実行し、失敗した場合は「ブロック中」に移します。
• エージェントが解決できない作業に取り組み続ける。 Claude Code のタスクが自力で解決できず、エージェントは再試行を続け、コンテキストを消費し、トークンを使い果たし、作業開始時より悪い状態で残してしまいます。対策：「ブロック中」を正式なステータスとして扱います。自律的に解決できない場合、エージェントはタスクを「ブロック中」に移し、阻害要因を記録して停止します。

---

出力形式

デフォルトの出力は Markdown ドキュメントで、通常はプロジェクトのルートまたは docs/ サブディレクトリに ORCHESTRATION.md として保存されます。このドキュメントには計画全体が記載され、チームの正式な参照資料となります。

構成：

1. プロジェクトのオーケストレーション計画。 カレンダー上の週、マイルストーンの日付、フェーズごとの成果物を含む段階的なタイムライン。
2. フェーズごとのゲート仕様。 各ゲートに何が入り、何が出るのか、誰が承認するのか、QA 検証ゲートを含む測定可能な合格基準。
3. ロックポイントの一覧。 何がいつ変更不可になるのか、ロックされた成果物の格納場所、変更を申請できる人、変更によって発生する再レビュー作業。
4. ツールスタックの実装ガイド。 Jira、Linear、Notion、Figma、GitHub の具体的なセットアップ方法と、自動化する部分の MCP コマンドまたは CLI の呼び出し。
5. QA 検証ゲートの仕様。 合格必須の自動テスト、実行に使う MCP、証拠の添付先、失敗時の対応。
6. 引き継ぎ仕様。 引き継ぎごとに移管する成果物、ロック済みの項目、変更リクエストの手順、周辺作業での観察事項の振り分け。
7. スキル間の依存関係グラフ。 各フェーズで実行するスキル、それぞれが受け取るものと生成するもの。
8. リスク一覧。 ケイデンス固有のリスクとその軽減策。

このドキュメントがオーケストレーション計画となります。納品後の次のステップでは、PM が計画に沿ってチームのツール（Jira のエピック、Linear のプロジェクト、Notion のデータベース、Figma のライブラリ、GitHub のブランチ保護）をセットアップし、計画の実行を開始します。

---

参照ファイル

• references/cadence-patterns.md。7 種類のプロジェクトタイプについて、フェーズの分解、タイムライン、ゲート定義、ツールスタック実装のひな形を含む詳細なケイデンス。
• references/gate-definitions.md。各標準ゲートのトリガー、承認者、合格基準、ブロックされる作業、すでにロック済みの項目、変更リクエストの手順。
• references/handoff-protocols.md。フェーズ間およびスキル間の標準的な引き継ぎと、周辺作業中に気づいた事項を起票するための周辺観察事項の引き継ぎ。
• references/platform-implementation.md。オーケストレーションを Jira、Linear、Notion、Figma、GitHub にどう対応付けるかを説明しています。各プラットフォームの MCP 統合に関する注意事項と、MCP が適切でない場合の CLI の代替手段も含みます。
• references/team-size-modulation.md。個人、小規模、中規模、大規模の各チームに合わせてケイデンスを調整する方法。
• references/automation-and-qa-tooling.md。QA 検証ゲートのパターン、MCP と CLI のトレードオフ、セッションメモリーとモメンタムのパターン、コードとチケットの連携、証拠の追跡記録。
• references/example-orchestration.md。代表的なシナリオについて、すべてのセクションを記入した完全な実例。