はじめに
こんにちは、CX開発グループの @n-black-cat です。
便利な社内ツールはあるのに、使うまでの準備や使った後の作業が面倒 — そんな経験はないでしょうか。
弊社では、大きなプロジェクトをリリースする際にリリース手順書を作成し、それに沿ってリリース作業を行う文化があります。手順書を作成する際には Go で書かれた自家製の CLI ツールがあり、分単位のタイムテーブル、リリースコマンド、ロールバック手順、Slack テンプレートまで含んだ、そのまま使える手順書を出力してくれます。
ただ、ツール自体は正確に Markdown を吐いてくれるものの、その前後はすべて手作業でした。
- リリースのたびに Go のソースコードを直接書き換えて値を埋める
- Jira のリリース用 Epic を開いて、PJ名・日時・担当者・PR URL を目視で拾う
- 出力された Markdown を esa（社内ドキュメント共有ツール）にコピペして投稿する
- esa 投稿後の URL を Slack メッセージテンプレートに埋め直す
この記事では、既存ツールの入力を JSON 化し、Claude Code の Skill（AI に作業手順を教える定義ファイル）と MCP（Jira や esa などの外部システムを AI から操作するための接続口）で前後の手作業を自動化したアプローチを紹介します。ツールを丸ごと AI に置き換えるのではなく、AI を既存ツールの「接着剤」として使うパターンは、同じような社内ツールを持つチームにも応用できるはずです。
Before / After
Before: ソースを書き換えて実行 → コピペ投稿
[人間] Jira を開いて Epic の情報を読む ↓ 手作業 [人間] Go ソースコード内の値を直接書き換える ↓ 手作業 [Go] go run . → result.md 生成 ↓ 自動 [人間] result.md を esa にコピペ投稿 ↓ 手作業 [人間] esa URL を Slack テンプレートに貼り直す ↓ 手作業
After: AI がツールの前後をつなぐ
[人間] /release-manual https://jira.../browse/PROJ-1234 ↓ Skill 起動 [AI] Jira MCP で Epic 情報を取得 → パラメータ抽出 ↓ 自動 [AI] 不足情報だけユーザーに質問（コピペ用テンプレート付き） ↓ 人間が回答 [Go] go run . '<JSON>' → result.md 生成 ↓ 自動 [AI] esa MCP で投稿 → URL 取得 → Slack テンプレート差し替え → 更新 ↓ 自動 [AI] 完了報告（esa URL）
全自動ではなく、不足情報の入力と投稿先の確認は人間が判断します。ただ、Jira → ターミナル → esa → Slack と画面を行き来していた作業が、Claude Code の中で会話するだけで済むようになりました。
やったこと
変更は 2 つだけです。
1. 既存 CLI ツールの入力を JSON 引数化
元のツールは Go ソースコード内に値が直書きされており、リリースのたびにソースを書き換えて go run . する運用でした。これを go run . '<JSON>' で渡せるように改修しました。テンプレートの中身は一切変えていません。
Skill が組み立てる JSON のイメージです。
{ "project_name": "機能Aの開発", "release_datetime": "2026-04-23 10:00", "operator": "田中", "reporter": "鈴木", "pr_urls": ["https://github.com/.../pull/123"], "slack_channel": "#pj-feature-a", "cache_clear": false }
2. Claude Code Skill で前後をつなぐ
Claude Code 側では、この処理を Skill として定義しています。Skill には、使えるツールや実行手順を自然言語で記述します。
SKILL.md の中身
実際の SKILL.md から抜粋して紹介します。まず frontmatter で、Skill が使えるツールを制限しています。
--- name: release-manual description: リリース手順書を、Goテンプレートツールを実行して作成する allowed-tools: Bash(cd lenet-templates *) Read mcp__atlassian__getJiraIssue mcp__esa__esa_create_post mcp__esa__esa_update_post ---
Bash はリリースツールのディレクトリでのみ実行可能にし、外部連携は Jira と esa の MCP に限定しています。
Skill の本体は 7 ステップの手順です。ここでは設計上こだわったステップ 2 と 3 を載せます。
ステップ 2: 情報の自動抽出
取得した `fields.summary` と `fields.description` の全文を読み、 手順書に必要な以下のパラメータに該当する情報を **すべて** 探す。 抽出ルールを固定せず、毎回Epicの内容を読んで判断すること。 手順書に必要なパラメータ一覧: | パラメータ | JSON key | 例 | |---|---|---| | PJ名 | project_name | 機能Aの開発 | | リリース日時 | release_datetime | 2026-04-23 10:00 | | 担当者（実行） | operator | 田中 | | 担当者（報告） | reporter | 鈴木 | | チケット URL | ticket_url | (入力そのもの) | | PR URL | pr_urls | https://github.com/.../pull/123 | | Slackチャンネル名 | slack_channel | #pj-xxx | | キャッシュクリア要否 | cache_clear | true / false | | 事前告知日（任意） | announce_date | 省略時はリリース前営業日を自動計算 |
AI に「よしなに読み取って」と任せるのではなく、抽出すべき項目をテーブルで明示しています。こうすることで、案件ごとに拾う項目がブレるのを防いでいます。
ステップ 3: 不足情報の質問
取得できた情報を提示した上で、**まだ埋まっていないパラメータのみ** を質問する。 すべて取得できた場合は確認だけ行い、質問はスキップする。 質問時は、取得済み情報を埋めた **コピペ用の回答テンプレート** を返す。 ユーザーはテンプレートの空欄を埋めてそのまま返信できる。 例: チケットから以下の情報を取得しました: - PJ名: 機能Aの開発 - リリース日時: 2026/04/23 10:00 以下を埋めて返信してください: --- 担当者（実行）: 担当者（報告）: PR URL: Slackチャンネル: キャッシュクリア（要/不要）: ---
Slack チャンネル名のように Epic には載っていないが手順書には必要な情報があります。ここを曖昧にすると、AI がもっともらしい値を推測で埋めてしまうリスクがあるため、「埋まっていない項目だけ質問する」「コピペ用テンプレートを出す」と明示しています。
このほか、esa 投稿前にカテゴリのプレビュー確認を挟むステップも入れています。これは実際に投稿先を間違えたことがあり、後から追加しました。取り消しにくい操作の前には確認を挟むのが実用上のポイントです。
この Skill の中で AI が自由にテキストを書く場面はありません。手順書の中身はすべて既存テンプレートから生成されるため、AI の出力ブレが手順本文に入り込みにくい構造になっています。ただし Jira からのパラメータ抽出は AI が行うため、Epic の記載によっては誤った値が入る可能性はあります。確認ステップや生成後の目視チェックと組み合わせて運用しています。
生成されるドキュメント
実際に生成されたリリース手順書の一部です。
# 概要 - リリース日時: 2026/04/23(木) 10:00 - リリース対応日時: 2026/04/23(木) 09:00 〜 11:00 - Epic: https://jira.../browse/PROJ-1234 # 実行手順 | 日付 | 開始 | 終了 | 作業 | 担当 | | :---: | :---: | :---: | --- | --- | | 04/22 | 18:30 | 18:33 | `#release-request` にて事前告知 | 鈴木 | | ... | | | | | | 04/23 | 09:59 | 10:00 | リリースコマンド実行 | 山田 | | 04/23 | 10:00 | 10:02 | ⚠️ batch PRをmasterマージ | 山田 | | 04/23 | 10:03 | 11:00 | 動作確認 | 鈴木・山田 |
分単位の時刻、担当者、条件付きの batch 手順、ロールバック手順、Slack の告知文まで含まれます。これらはすべて既存テンプレートと入力パラメータの組み合わせで決まるため、フォーマットの揺れを防げます。
期待している変化
これまで手順書を作る人は、Jira・ターミナル・esa・Slack を行き来しながら 30 分ほどかけて作業していました。Skill 化後は /release-manual を実行して数回の質問に答えるだけで、同じ品質の手順書が数分で完成します。
もうひとつ期待しているのは、手順書作成のハードルが下がることです。新しいメンバーが増えてリリース手順書を作った経験がなくても、Skill 化されていれば簡単に作成できるようになります。
気になる点と今後
- Skill の手順は自然言語で書いているため、AI の解釈がたまにブレます。前述の esa 投稿カテゴリの例のように、重要な操作の前には確認ステップを入れるのが実用上のポイントでした。
- Jira の Epic の書き方が案件によってばらつくため、パラメータ抽出の精度が安定しません。Epic 側に決まったフォーマット（担当者欄、PR URL 欄など）を用意すれば、抽出精度が上がり対話のやりとりも減らせるはずです。
- スケジュールの都合上で休日を計算する必要があり、計算で土日は避けられますが、祝日は判定できません。祝日 API を使うか、祝日リストを持たせるかを検討したいです。
このパターンを試すための前提
同じアプローチを試す場合に必要な条件は 3 つです。
- 既存ツールが引数で入力を受けられること。 JSON でもコマンドライン引数でも構いません。ソースを書き換えないと動かない状態なら、まずここを変えます。
- 外部システムへの MCP が設定済みであること。 今回は Jira と esa の MCP を使っています。接続先に合わせて MCP を用意する必要があります。
- 人間が確認すべきポイントを残すこと。 AI の推測が入る箇所や、取り消しにくい操作の前には確認ステップを挟みます。
まとめ
既存ツールを AI で置き換えたわけではなく、入力をプログラムから呼べるようにし、その前後を Skill + MCP でつないだだけです。
チームに「毎回ソースを書き換えて実行する」ようなツールがあれば、入力を JSON や引数で受け取れるようにするだけで Skill から呼び出せるようになります。Go でもシェルスクリプトでも Python でも同じです。既存ツールの信頼性はそのままに、AI を接着剤として前後の手作業を自動化する — このパターンが参考になれば幸いです。
ホワイトプラスでは一緒に働いてくれるエンジニアを募集しています。興味を持っていただけたら、ぜひ採用ページやエントランスブックをご覧ください。
