> ## Documentation Index > Fetch the complete documentation index at: https://docs.wakechatapp.com/llms.txt > Use this file to discover all available pages before exploring further. # Linear Loopsで期限変更からSlack通知まで自動化。制作案件の「変更伝達漏れ」をどう防ぐ？ > Linear Loopsで、案件の期限・担当者・ステータス変更を資料更新とSlack通知へつなぐ方法を解説。制作案件で情報のズレを防ぎ、クライアントとの合意を残す運用も紹介します。 制作案件では、納期や担当者の変更そのものよりも、「誰が、どの情報を、いつ知るか」をそろえるほうが難しいことがあります。タスクの期限は更新したのにSlackには旧日程が残る。進行表は直したのに、デザイナーや営業には伝わっていない。このような情報ずれは、手戻りや不信感の原因になります。 Linearは2026年9月14日、繰り返し実行するエージェントワークフローである「Loops」をプロジェクト管理向けに拡張しました。プロジェクトの期限・担当者・ステータス・マイルストーンなどの変更を起点に、Linear内のドキュメントを更新し、Slackへ状況と次のアクションを投稿できます。 [Linear公式：Loops for product management](https://linear.app/changelog/2026-09-14-loops-for-product-management) この記事では、制作会社・受託チームがLinear Loopsを使って変更伝達漏れを減らす考え方と、自動化してよいこと、クライアントとの合意として人が残すべきことを整理します。 > [!NOTE] > > この記事は2026年9月19日時点のLinear公式情報をもとにしています。Loopsの提供条件、利用可能な連携、AI機能のクレジットや挙動は変わる可能性があるため、導入時は管理画面と公式ドキュメントを確認してください。 ## Linear Loopsは何ができるようになった？ Loopsは、チームのワークスペース内で繰り返し動くエージェントワークフローです。今回の拡張により、プロジェクトやイニシアチブの変更、サイクルの開始・完了、Issueの変更をトリガーとして扱えるようになりました。 制作進行で特に使いやすいトリガーは、次のようなものです。 * プロジェクトのステータス、担当者、目標期限、マイルストーン、メンバー、ラベルの変更 * プロジェクトへの更新やコメントの追加 * Issueのステータス、優先度、担当者、プロジェクトの変更 変更を検知したあと、Loopsは関連するLinearドキュメントを更新できます。さらに、変更内容と次に対応すべき人を文脈に合わせてまとめ、Slackへ下書き・投稿することもできます。たとえば、公開予定日が変わったときに、ローンチ計画を更新し、「何が変わったか」「なぜ変わったか」「誰が次に対応するか」をSlackへ共有する、という流れです。 [Linear公式：トリガー、ドキュメント編集、Slack更新の説明](https://linear.app/changelog/2026-09-14-loops-for-product-management) 大切なのは、通知を増やすことではありません。**一つの変更を起点に、正本となる情報と関係者の認識をそろえること**です。 ## 案件変更で情報がズレる3つの場所 ### タスク管理 まず、担当者がLinearのプロジェクトやIssueで期限を変更します。ここは変更の記録として正しい一方で、タスクを日常的に見ない営業、制作担当、協力会社には気づかれないことがあります。 また、親プロジェクトの納期だけが変わり、個別タスクの優先順位や担当者の対応が変わっていないと、「変更を見たが、何をすべきか分からない」状態になります。 ### 仕様書・資料 進行表、ローンチ計画、要件メモなどは、変更後の前提を共有するための資料です。しかし手作業で更新する運用では、タスクを直した人と資料を直す人が異なるほど、更新のタイムラグが生まれます。 資料の内容とタスク管理の期限が食い違うと、会議資料やクライアントへの説明が古い情報に基づいてしまいます。Loopsで関連ドキュメントの更新までつなげる価値は、この二重管理を減らせる点にあります。 ### チャット Slackは素早く周知するのに適していますが、過去の投稿を書き換えない限り、旧日程のメッセージは残ります。チャンネルを見返したメンバーが、最新の計画ではなく、先に目に入った投稿を基準に動くこともあります。 そこで通知には、単に「期限を変更しました」と書くのではなく、変更前後、理由、影響範囲、次の担当を入れます。通知を、最新情報へ移動するための入口として設計します。 ```text theme={null} 【公開日変更】採用サイトリニューアル 変更前：10月15日 変更後：10月22日 理由：採用写真の差し替えと最終確認に追加日数が必要なため 影響：実装・QAの完了予定を再調整 次の対応：デザイナーは10月8日までに差し替え画像を確認、PMは進行表を確認 正本：Linearプロジェクトとローンチ計画のリンク ``` ## 自動化すると効果的な変更 ### 納期 納期変更は、もっとも自動化の効果が出やすい対象です。期限が動いたら、進行用ドキュメントの予定日を更新し、関係する社内チャンネルへ定型の変更通知を出します。 ただし、何日以上の変更で通知するかは最初に決めます。たとえば1日の微調整まで全員に通知すると、かえって重要な変更が埋もれます。おすすめは、公開日・クライアント確認期限・マイルストーンの変更を必ず通知し、個別作業の小さな調整は担当者だけに伝える設計です。 ### 担当者 担当変更は、引き継ぎ漏れが起こりやすい変更です。Loopsで担当変更を検知したら、新旧担当者とPMへ、対象タスク、現在のステータス、次に必要な作業をまとめて通知します。 担当者名だけを差し替えて終わらせず、引き継ぎに必要な資料や未解決の論点へのリンクを含めると、変更後の立ち上がりが速くなります。 ### ステータス 「レビュー待ち」「ブロック中」「完了」などのステータス変更は、必要な相手だけに知らせると効果的です。たとえばデザインがレビュー待ちになったらディレクターへ、実装がブロック中になったらPMと該当の依存タスク担当者へ共有します。 すべてのステータス変更を全体チャンネルに流す必要はありません。通知先を「変更の影響を受け、次の行動がある人」に絞ることが、読まれる自動通知にする条件です。 ## 自動化してはいけない「クライアントとの合意」 内部の期限変更を共有することと、クライアントが新しい期限を了承したことは別です。社内で「10月22日に変更」と決めた通知を自動投稿しても、契約上の納期変更、追加費用、スコープ変更まで合意されたことにはなりません。 特に次の内容は、クライアントとの明示的な確認・承認を残しましょう。 * 契約上の納期、公開日、検収日の変更 * 追加費用や追加工数が発生する仕様変更 * 成果物の範囲、優先順位、公開可否の変更 * クライアント側の素材提供・確認期限の再設定 自動化は、確認依頼を漏れなく作るところまでに使えます。しかし「了承された」と判断してステータスを完了にするのは、決裁権者からの回答を確認してからにします。 ## 自動通知と正式な承認を分ける 実務では、内部向けの自動通知と、クライアント向けの確認依頼を別の流れにすると混乱を抑えられます。 | 項目 | 内部の自動通知 | クライアントとの確認・合意 | | - | - | - | | 目的 | 関係者の認識と作業をそろえる | 変更条件への回答・承認を得る | | 起点 | Linear上の期限・担当・ステータス変更 | PMが内容と影響を確認後に依頼 | | 記録する内容 | 変更前後、理由、次の担当、正本リンク | 対象、変更理由、影響、回答期限、承認結果 | | 完了条件 | 通知が送られ、内部の対応が割り当てられた | 決裁者の明示的な回答が記録された | Linearは、開発・プロダクトチーム内部の変更を同期する基盤として強力です。一方で社外の関係者も含む制作案件では、依頼、返信、ファイル、承認状態を案件単位で追える場所が必要になります。 WakeChatでは、顧客・案件ごとのチャンネルの中に、確認事項ごとの案件スレッドを作成できます。スレッドには状態、期間、メッセージ、ファイルをまとめられるため、「納期変更の確認」「追加ページの見積もり確認」「公開前チェック」といった合意を、日常の自動通知と分けて残せます。 ## 制作会社向け変更管理フロー 最初からすべての変更を自動化する必要はありません。公開日変更のように影響が大きく、手順が定型化しやすいものから始めるのがおすすめです。 1. **Linearを内部の正本にする**：プロジェクトの期限、担当、ステータスを変更したら、まずLinearを最新にする 2. **Loopsで資料と内部通知を同期する**：公開日やマイルストーンの変更を起点に、進行資料を更新し、影響を受ける社内チャンネルへ通知する 3. **PMが社外への影響を確認する**：契約・費用・成果物・クライアント側の対応期限に影響するかを判断する 4. **WakeChatで確認依頼を作る**：変更前後、理由、対象資料、回答期限、承認してほしい内容を案件スレッドにまとめる 5. **回答を記録して完了にする**：クライアントの回答と対象を残し、承認後に社内の計画を確定する この分担では、**Linear＝内部の変更を同期する場所、WakeChat＝クライアントを含めた確認・合意状態を残す場所**となります。役割を分けることで、自動化の速さを活かしながら、「誰が了承したのか分からない」状態を防ぎやすくなります。 ## まとめ Linear Loopsは、期限・担当・ステータス変更に伴う資料更新とSlack通知をつなぎ、制作案件の情報ずれを減らせる機能です。まずは公開日や主要マイルストーンの変更から始め、変更前後、理由、影響、次の担当を通知に含めましょう。 ただし、自動通知は内部共有のためのものです。クライアントとの納期・費用・範囲の合意は、確認対象と回答を案件単位で残し、明示的な承認を得てから確定します。内部同期をLinear、社外を含む確認・承認をWakeChatに分けると、変更の速度と合意の確かさを両立しやすくなります。 [WakeChatの案件スレッドを見る](https://docs.wakechatapp.com/docs/threads/manage-project-threads.md) ・ [WakeChatの機能を見る](https://docs.wakechatapp.com/features.md) ・ [無料でWakeChatを始める](https://wakechatapp.com) ## 参考情報 * [Linear：Loops for product management](https://linear.app/changelog/2026-09-14-loops-for-product-management) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.