所属しているメルマガチームでは、メルマガの改修・運用業務を行っています。
定型的な軽微修正から、要件確認が必要な新規メール作成まで、案件の粒度はさまざまです。
私自身は普段メルマガ案件の実装を担当しているわけではなく、このプロジェクトで「AI導入施策の企画・推進・分析」を担当しました。実装はチームのメンバーにお願いする形で進めています。
「AIを使って工数をどれだけ削減できるか」を、実装担当メンバーと二人三脚で計測しながら進めたので、その過程と結果をまとめます。使用したのは社内向けのAIツールで、GitHub Copilotのチャット機能（モデルはAutoを使用）・オープンモデルのQwen・OpenAIのGPT-5.6 Lunaです。
計測の結果、全体で33%の工数削減を達成できましたが、案件の性質やツールによって効果に大きな差が出ることが分かりました。
導入の背景と目標
きっかけは、メルマガチームの対応にかかる工数を減らし、より多く別チームの業務に時間を割けるようにしたい、という課題でした。
設定した目標は次の2つです。
- 目標①：メルマガチームの対応工数削減率20%以上を達成する（上長からの目標として設定）
- 目標②：月稼働の60%を別チームの業務に安定して充てられる状態にする
この2つは直接計算でつながっているわけではなく、別々の見積もりから設定しています。
※目標②の60%の根拠について、メルマガ案件の稼働見込みから逆算したものです。
- 過去の実績では月あたりの案件数が2件を超えたことはなかったため、これをMAX稼働のケースとして、工数の大きい定形外案件が月2件来た場合を想定しています
- AI導入後の見立て工数（1案件3.2人日）から算出すると、メルマガ案件に必要な稼働は月の約30%程度に収まる見込みです
- 理論上は残り約70%を別チームの業務に充てられる計算ですが、連絡のやり取りなど数値化しづらい工数も考慮し、余裕を持って60%を目標に設定しました
ここからは実際にどう計測を進めたかを見ていきます。
まず、案件は大きく2種類に分けて計測しました。
- 定形外案件：新規メルマガ作成など、要件確認や文章作成が必要な案件
- 定形案件：バナー差し替え、リンク変更など、実装作業がシンプルでAIの活用が見込める軽微な案件
各工程（要件確認・検品環境確認・実装・表示確認・コードレビュー・リリース準備）ごとに「AI導入前の体感工数」と「導入後の見立て工数」を先に見積もり、そのうえで実績を計測する、という進め方にしました。
AI活用の仕組み
進める前に、まず「AIに何をどう任せるか」の設計から始めました。
設定したのは大きく3つです。
- ルールブック（設定ファイル）：コーディング規約、レビュー観点、HTMLメール特有の制約（テーブルレイアウト・インラインCSS・Outlook対応）など、AIが守るべきルールをファイルにまとめたもの
- 手順書（スキル）：定型的な作業の手順を切り出したもの。たとえば「Figmaから画像を取得して所定の場所に保存する」といった、繰り返し発生する作業をスキル化
- 作業者（エージェント）：要件確認・実装・レビューなど、工程ごとに役割を持たせたAIエージェント
なお、MCPは検討したものの、コンテキストを消費する割にやりたいことはシェルコマンドで代替できたため、今回は採用を見送りました。
進め方は段階的にしています
- 設計：工数削減率の見立てを立てる
- 叩き台作成：AIにプロンプトを投げてベースの設定ファイルを作成し、実際の案件で動かしてみる
- 慣らし運転：ツールに慣れつつ、定形案件はAIのみでのタスク完遂を目指す。うまくいかない場合はスキルを更新して再挑戦
- 導入完了：本格運用しつつ、工数削減目標の達成を目指す
AIを活用した工程
主にAIを活用したのは「要件確認」と「実装（コードレビュー含む）」の2工程です。実装・工数の計測は実装担当メンバーが担当し、私は分析を担当する形で役割を分けました。
- 要件確認：要件定義書の要件漏れをチェックするエージェントを使い、あいまいな点がないか確認したうえで人間が最終チェック
- 実装：AIが要件を踏まえて実装のアウトプットを作成し、実装担当メンバーが確認して必要に応じて再度プロンプトを投げて修正する、という往復のやり方で進めました。レビューエージェントには「冗長な処理の簡素化」「未使用変数の削除」「命名の改善」といった観点を持たせています
- 表示確認・リリース準備：ここは引き続き人間が必須の工程としています（AI化の余地はありつつ、各所との連携が必要なので今回は未対応）
ルール系のファイルは実装者が随時更新し、変更履歴はCHANGELOGとして残す運用にしています。設計がまだ固まりきっていない期間は、ルールの変更内容を定例MTGでチーム内共有しながら進めました。
結果
3ヶ月ほど運用し、実際の工数を計測した結果です。
| 見立て | 実績 | |
|---|---|---|
| 案件工数削減率 | 30% | 33% |
| AI導入後の空き時間 | 66% | 73% |
全体としては、目標としていた「工数削減率20%以上」「月60%を別チームの業務に充てる」を上回る結果になりました。
内訳を見ると、案件の種類によって傾向が分かれました。
| 削減率（見立て） | 削減率（実績） | |
|---|---|---|
| 定形外案件 | 42% | 53%（目標を大きく上回る） |
| 定形案件 | 22% | 19%（目標にわずかに届かず） |
定形外案件は、AIに任せられる「要件確認」「実装」の工程がもともと工数の大きな部分を占めていたため、AI活用による削減効果がそのまま実績に反映されました。
定形案件は、実装工程の実績が見立ての約2.4倍に膨らんだことが主な原因でした。掘り下げると、Qwenを使った案件で工数が大きく増加していたことがわかりました。該当案件を除いて再計算すると、見立てに対する実績の乖離率（実績÷見立て）は 231% → 120% まで改善し、目標水準にかなり近づく結果になりました。
考察
AIツールによって精度に差があった
Qwenを使用した案件は、スキルを1回実行しただけでは完了せず、何度かやり取りが必要になるケースが多く、結果的に工数が増加しました。特に「HTMLメール特有の複雑な制約（テーブルレイアウトやインラインCSS）をプロンプト通りに維持できない」「指示した仕様の一部が抜け落ち、修正プロンプトを何度も打ち直すことになった」点が主な原因と考えています。一方、GitHub CopilotやLunaを使った案件は、想定より精度の高い出力が得られました。
実際にある定形案件で、1回目にQwenで実装した後、2回目に同じ案件をGitHub Copilot（モデル：Sonnet 5）でやり直したところ、「実装・コードレビュー」の工程において0.34人日も差が開きました。
| 工程 | 1回目：Qwen | 2回目：GitHub Copilot（Sonnet 5） |
|---|---|---|
| 実装・コードレビュー | 0.48 | 0.14 |
なお、この1回目（Qwen）・2回目（GitHub Copilot）の実装は、それぞれ独立した案件として「定形4件」の集計に含めています。
案件数がまだ少なく、振れ幅が大きい
定形外2件・定形4件（うちQwen使用2件）と、集計対象の案件数自体がまだ少なく、乖離率（実績÷見立て）も 31.5%〜231.0% とばらつきがありました。継続して案件数を積み上げ、傾向を確かめていく必要があると感じています。
「AIに任せられる工程の比率」が削減効果を左右する
定形外案件で削減効果が大きく出たのは、そもそもAIに任せられる工程（要件確認・実装）の見立て工数が大きかったためです。逆に定形案件は、AIに任せられる工程の見立て工数がもともと小さく、ツールの精度差の影響を相対的に受けやすいという構造でした。
来期に向けたアクション
計測結果を踏まえて、次の2点を来期のアクションとして設定しました。
- 精度が安定しなかったQwenの使用を停止し、GitHub Copilot・Lunaの活用を優先する
- 案件工数の測定を継続し、実装工程のブレを抑えるために、プロンプトやレビュー手順をテンプレート化する
まとめ
AI導入の効果を工程ごとに見立てと実績を数値で比較した結果、以下のような学びが得られました。
- 全体としては目標を上回る削減効果が出た
- ただし効果の出方は案件の種類（定形/定形外）によって異なる
- AIツールによって精度・安定性に差があり、それが工数のブレに直結する
今回はまず「工数を計測しながら手探りで進める」フェーズでしたが、ここで得られたデータをもとに、今後は要件確認から実装・レビューまでを一気通貫でAIに任せるフローの検討も視野に入ってきています。目の前の工数削減だけでなく、次のフェーズに進むための土台づくりができた3ヶ月だったと思います。