PMOとして開発プロジェクトを支援する中で直面した、ツール間のつなぎと漏れの課題を解決するためGitHub Copilotの「Agent Skills（以下、Skills）」を活用した運用業務の半自動化事例をご紹介します。手順そのものをファイル化し、日々の定型作業をオーケストレーターに実行させることで、判断の属人化を防ぎつつ正確な予実管理や各種申請を実現しています。
要約：プロンプトではなく「運用手順そのもの」をファイル化する
予実管理や各種申請などの運用業務にGitHub Copilotの「Skills」を全面的に導入しています。手順をチャットで毎回指示するのではなく、「運用手順そのもの」をファイルとして管理し、エージェントに読み込ませて実行する仕組みです。
朝のプロジェクト管理業務は、チャットに 「開始」 と入力するだけ。オーケストレーター（daily-task-runner）が起動し、あらかじめ定められた順序で約20本ある専門スキルを順番に実行していきます。
【例：処理の流れ】
ニーズ取得 ＞ プロジェクト開始申請 ＞ 工数同期 ＞ 予実比較 ＞ 月曜：ブログ当番 ＞ 勤怠チェック
外部への書き込み前には必ず確認テーブルを表示し、人間が「はい」と判断してから実行します。
実現したい運用の狙いは以下の3点です。
1. 漏れをなくす
毎日・月初・月末の定型作業を、曜日や日付から自動判定して確実に実行・スキップする。
2. 判断を残す
各ツールへの書き込み、データ更新の前には、人の確認を挟む。
3. 判断の自動化
「報告すべきか」を個人の裁量に頼らず、ルールに基づいた閾値でシステム側から提示する。
課題と目的：ツールの不足ではなく「つなぎと漏れ」を解消する
プロジェクト管理において直面していた課題は、ツールが存在しないことではありませんでした。社内コミュニケーションツール、Jira、Jira Service Management、ガントチャート、Confluence、GitHubなどは、すでに導入されており、真の課題は各ツールの 「つなぎと漏れ」 にありました。
| 直面していた課題 | 現場で起きていた実態 |
|---|---|
| 定型作業が頭の中にある | ニーズ登録、開始申請、工数同期、勤怠確認などを、各自の当日の記憶頼みで運用していた |
| 数字の正（マスター）が複数ある | ガントチャート、Jira、GitHub Projects、口頭確認が乱立し、議論の前提数値がブレていた |
| 困り事が事前に上がってこない | 定例会が「順調です」で終わり、期日に間に合わない懸念案件を事前に検知できなかった |
| 変更の経緯が記録に残らない | 工数計画が変更されても、どのような理由・経緯で動いたのか後から追跡できなかった |
Skillsの目的は「AIに丸投げする」ことではなく、「人間が毎日やらなくてよい単純作業を手順化し、人間が担保すべき判断だけを残す」ことにあります。
同一順序・同一品質の維持
担当者が変わっても、Skillsファイルを読み込めば常に同じ水準の結果が得られる。
新しい入力を増やさない
新規管理表は増やさず、既存のデータ（予定・実績・ニーズ）を統合管理表へ自動集約する。
判断の型を事前定義
変更はプルリクエスト経由、更新前は確認表の提示、課題化は閾値判定とし、属人的な裁量を排除する。
組織の資産として蓄積
個人のチャット履歴に埋もれさせず、Gitリポジトリ上の資産として手順を管理・再利用する。
Skillsを活用した運用の全体像と設計
Skillsの本質：エージェントに渡す業務手順書
Skillsとは、エージェントへ渡す構造化された業務手順書です。リポジトリ上の所定パスに配置して管理します。 手順の修正はチャット上で指示をし直すのではなく、Markdownファイルをコミットして修正します。運用の改善そのものがGitのバージョン管理下に入る仕組みを作りました。
毎日の朝ルーティン：「開始」1回で実行されるパイプライン
チャットに「開始」と入力するだけで、daily-task-runnerが以下の順序で各専門スキルを同期的に実行します。
| 番号 | 実行スキル | 実行内容 | 実行タイミング |
|---|---|---|---|
| 0 | 曜日チェック | 月曜日ならミッション確認のため一度停止 | 月曜日のみ |
| 1 | project-business-needs | 社内コミュニケーションツールのニーズを取得し、統合管理表への登録候補を作成 | 毎日 |
| 2 | 同上（翌月保守） | 翌月の定例保守Issueを準備 | 最終月曜の1週前の月曜 |
| 3 | project-start-application | 実施確定ニーズから、Jira Service Managementのプロジェクト開始申請を実施 | 毎日 |
| 4 | project-maintenance-end-application | 前月の保守終了申請を実施 | 当月最初の平日 |
| 5 | project-effort-management（予定） | ガントチャートの予定工数を統合管理表へ反映 | 毎日 |
| 6 | project-effort-management（実績） | Jira実績を人日換算して反映（即時更新） | 毎日 |
| 7 | project-planned-effort-change | Approve済みプルリクエストの工数変更をProjectへ反映・マージ | 毎日 |
| 8 | project-yojitsu-comparison | 当月の予定工数と実績工数の乖離表を生成 | 毎日 |
| 9 | blog-duty | 各種当番のTODO通知（作成処理を含む） | 月曜日のみ |
| 10 | check-attendance | 勤怠確認の結果を共有 | 毎日（最終処理） |
スキル実行の基本3フェーズ
【フェーズA】事前チェック：確認テーブルを出力
【フェーズB】承認：人間が「はい」と判断
【フェーズC】実行：登録・更新・外部投稿を実施後、自動で次のステップへ移行
実績同期については、後続の予実比較を最新化するため確認テーブル提示後に即時書き込みを行います。
運用の安全性を高める9つの工夫
1. 手順をファイルで管理
指示ブレを防ぎ、カタログ（Skills-catalog）を常時読ませることで自律的なスキル選定を実現。
2. 単機能化とオーケストレーション
巨大な一つの手順にせず独立したSkills群に分割。「今日は勤怠だけ」といった個別実行にも柔軟に対応可能。
3. 人間確認地点の固定化
対象・変更前後・スキップ理由の確認表を必須とし、AIによる未確認の誤更新を構造的に防止。
4. カレンダー条件の内製化
「当月1日」「最終月曜の1週前」などの日付条件をSkills内に埋め込み、人間の記憶負荷をゼロに。
5. 入力台帳を増やさない
ガントチャート・Jira・社内コミュニケーションツールの既存データを活用。数字が2系統に分かれて議論が迷走する事態を防止。
6. 充足率による機械的信号判定
充足率を客観的に計算。報告すべきかを担当者の感覚に委ねず閾値で自動議題化。
| 信号状態 | 充足率の基準 | 定例会での扱い |
|---|---|---|
| 青信号 | 100%以上 | 議題に挙げず順調としてスキップ |
| 黄信号 | 80%以上 - 100%未満 | 一言確認を行い進捗状況を共有 |
| 赤信号 | 80%未満、または残工数が2週連続で減っていない | 必須議題化し、リスケジュールや体制見直しを協議 |
客観的な信号判定基準（充足率ロジック）
状態を客観的に判断するため、以下の計算式で「充足率」を算出しました。
充足率 ＝ 期限までに該当プロジェクトへ割ける工数 / 残工数
7. 出力を要約しない原則
予実乖離や勤怠文面はスクリプトの標準出力を全行そのまま表示。重要な特異行の欠落を排除。
8. セッション内の二重登録防止
同一セッションで2度実行しても安全なように、処理済みIDをメモリ保持して重複申請をガード。
9. 障害時フォールスルー
途中ステップでエラーが起きても全体を止めず、最後に完了・スキップ・エラーの一覧を出力。
今後の展望：PMOの数値を「課全体の共通言語」へ昇華する
リアルタイムな進捗の可視化
チャットログを開かなくても、誰でもその時点の最新数値を確認できる状態を整備します。問い合わせを受ける前に進捗が把握できる環境をつくります。
課のKPIとプロジェクト管理の連動
予定・実績・充足率といった数値を課の目標（KPI）と直結させます。「今、自分は何に貢献しているか」「次に何をすべきか」を各自が主体的に考えられる組織土壌を目指します。
現在のSkills運用により、日々の定型業務を漏れなく安定して運用する体制が確立できました。今後はこの基盤を足がかりに、管理側だけが見ていたデータを課員全員の共通認識へと広げてまいります。
