はじめに
なぜリリース手順書作成に苦しんでいたのか?
毎回手作業!
プロダクトのリリースごとにリリース手順書を作成していました。しかし、この手順書作成が、地味ながらも非常に工数とストレスのかかる作業になっていたのです。リリースという重要なフェーズにもかかわらず、毎回手作業で一から手順書を作るのは、正直言って「だるい」の一言に尽きました。
従来のリリース運用と抱えていた課題
従来のリリース手順書作成フローは以下の通りです。
- テンプレートの複製:担当者がNotionなどのツールに用意されたテンプレートを複製。
- 内容の書き換え:今回のリリースで実行する具体的なタスクや手順に内容を書き換える。
- 時間計算:各作業にかかる開始時刻と終了時刻を計算し、手順書に記載。
- レビューと修正:手順書に抜け漏れがないか、時間計算にミスがないかをレビューし、修正。
❌ 課題点
- 無駄なコスト:慣れない担当者にとっては負担が大きく、手順書の作成に数時間を費やしてしまうため、リソースの無駄遣いとなっていた。
- 作業時間の計算ミス:書く作業の実施時間の計算が手作業で毎回ミスがある。
- レビューのコスト:雛形を用意しているものの人によって書き方や更新の仕方が異なりレビュー、指摘が大変だった。
🚀 7行のプロンプトで解決!Notion MCPを活用した自動化への挑戦
この非効率な現状を打破するため、私たちはNotion Management Control Plane (MCP) と、Cursorを組み合わせて、自然言語による手順書作成の自動化に挑戦しました。
-
Notionで「雛形」を用意
まず、自動化の土台として、Notion上にリリース手順書の雛形ページを用意しました。この雛形には、定常的に行う手順や、作業時間計算のためのベースとなる構造が含まれています。 -
Cursor × Notion MCPによる自動生成の仕組み
核となるのは、CursorとNotionのコンテンツを操作できるNotion MCPの連携です。(Cursorである必要はないですが当社ではエンジニアに付与されているのでCursorにしました)Notion MCPセットアップ手順
https://developers.notion.com/docs/get-started-with-mcp具体的なプロンプト
プロンプトNotion MCPを使って以下のページの手順書を更新してください。 [[notion のリリース手順書のリンク]] リリース開始日時:○○○○/○○/○○ ○○:○○ リリースバージョン:○.○ リリース範囲:○○○○ notion タスク一覧:○○○○ その他:envの変更などあれば -
Cursor Ruleによる更新の「細かい指定」
単にプロンプトを投げるだけでは、AIが勝手に意図しない変更を加えてしまう可能性があります。これを防ぐために、私たちはCursorでCursor Ruleを作成し、「どのように更新するか」を細かく指定しました。
(例)Cursor Ruleの内容(イメージ)
- 必須項目: 「リリース日時」、「リリースバージョン」、「リリース範囲」など、特定の情報を必ず所定のプロパティに記入させる。
- 構造維持: 「定常確認事項」セクションは、リリース対象外の項目でも削除せず、そのまま残すこと。(後述の失敗を回避するための対策)
🚧 うまくいかなかったこととその回避方法
自動化の道のりは平坦ではありませんでした。いくつかの課題に直面し、試行錯誤の末に解決策を見つけました。
-
定常確認内容の削除問題
-
現象: プロンプトでリリース対象に
コンソールが入っていない場合、と指示したところ、AIが賢く(?)働きすぎ、定常確認作業内のコンソールの確認作業を勝手に手順書から削除してしまいました。 - 回避方法: 前述の通り、Cursor Ruleにて特定のセクションは削除しないという強い指示を明記することで、この問題を解消しました。
Cursorによる認識違いがあった場合はなぜそれがおきたのかを聞き、それが再発しないようにCursor自身にcursor ruleを修正させると的確な改善案を出してくれます。
-
現象: プロンプトでリリース対象に
-
リリース物一覧の抽出問題
-
現象: リリース物をNotionデータベースで管理しているため、最初は以下のようなプロンプトで一覧化を試みました。
-
最初: 「
リリースverカラムがx.xのものを一覧化して」 $\rightarrow$ 失敗 - 次: 「以下のタスクIDを持つページを一覧化して」 $\rightarrow$ 失敗
-
最初: 「
- 原因: Notion MCPツールは、Notionデータベースに対して直接SQLクエリのような高度な検索・抽出処理を実行する機能を持っていなかったため、カラムの値を元にデータ抽出ができないようです。
- 最終的な回避方法: 力業ですが、リリース物のNotionページのURL一覧をすべてコピー&ペーストし、プロンプト内で直接渡すことで、一覧表を作成させることに成功しました。
-
現象: リリース物をNotionデータベースで管理しているため、最初は以下のようなプロンプトで一覧化を試みました。
⚠️ 唯一の惜しい点: URLを全部コピペする作業だけは、まだ手作業が残ってしまいました。しかし、この小さな手間を許容することで、残りの膨大な作業を自動化できたメリットは計り知れません。
🎉 結果:作業時間は数時間からたった5分へ!
いくつかの試行錯誤はあったものの、それ以外の項目は期待通り、あるいはそれ以上にうまくいきました。
| 項目 | 従来の手作業 | Notion MCPによる自動化 | 改善率 |
|---|---|---|---|
| 所要時間 | 数時間 | 5分程度 | 劇的な削減! |
| 時間計算ミス | 頻繁に発生 | ゼロ | 計算はAIに任せられる! |
| 担当者の負担 | 高い | 非常に低い | コア業務に集中できる! |
この自動化により、リリース担当者は手順書作成の雑務から解放され、リリースの本質的な確認作業や、予期せぬトラブルへの備えに集中できるようになりました。
💡 今後やりたいこと
今回の成功を基に、さらなる効率化を目指しています。
-
リリース内容変更時の更新テスト
- 「リリース内容に変更があった」というシナリオで、再度プロンプトを投げた際に、手順書が正しく上書き更新されるかを検証したいです。
-
各手順の作業時間自動調整テスト
- 例えば「DB手順の作業時間は通常30分だが、今回は大規模なので45分に増やす」といった、各手順の作業時間を状況に応じて適切に更新してくれるかを試す予定です。
まとめ
本記事では、リリース手順書作成の非効率な現状を、Notion MCPとCursorを組み合わせた「7行のプロンプト」で解決した事例を紹介しました。
AIは、単純なコンテンツ生成だけでなく、構造化されたドキュメントの「更新」や「計算」といった、定型業務の自動化に非常に強力なツールとなります。皆さんのチームでも、同様の「だるい」手作業をAIに任せて、より生産性の高い業務に集中できる環境を構築してみてはいかがでしょうか。