この記事の要点
- Aspireチームは、製品の変更がマージされた後に、関連ドキュメントの下書きプルリクエストを自動で作る流れを紹介した。
- 2026年5月3日から6月2日までの30日間で、396件の製品プルリクエストに対してワークフローが396回走り、82件のドキュメント下書きプルリクエストが作られた。
- AIが直接マージするのではなく、下書き作成、レビュー依頼、権限制限を組み合わせている点が実務向き。
説明が追いつかない時間を縮める
ソフトウェアの現場では、新しい機能が先に公開され、説明ページやヘルプ文書が後から追いかけることがよくあります。使う側から見ると、機能はもうあるのに、どこに何が変わったのかが分からない。作る側から見ると、担当者は次の開発へ移り、文書を書く人は過去の変更を掘り起こすことになります。
GitHubの公式ブログで紹介されたAspireチームの事例は、この遅れをAIエージェントで縮めようとしたものです。Aspireは分散アプリ向けの開発ツールを作る小さなチームで、製品側のリポジトリはmicrosoft/aspire、ドキュメントサイトはmicrosoft/aspire.devに分かれています。コードを書く場所と説明を書く場所が別々だからこそ、変更の流れを追う仕事が重くなっていました。
AIが入ったのは文章の前後だった
中心に置かれたのは、microsoft/aspire内のpr-docs-check.mdというワークフローです。製品のプルリクエストがmainまたはrelease/*に対してマージされた時に走ります。ただし、AIがいきなり文章を書き始めるわけではありません。先に通常のbash処理で、どのリリースブランチへ文書を出すかを決めます。プルリクエストのマイルストーン、リンクされたIssueのマイルストーン、ベースブランチを順に見て、最後はmainに落とす設計です。
その後にAIエージェントが差分と関連Issueを読み、この変更にドキュメントが要るかを判断します。要ると判断した場合は、microsoft/aspire.devの作業領域で下書きを作り、create_pull_requestという安全な出力を出します。AIが得意な文章作成だけでなく、どこへ出すか、誰に回すか、どの変更は文書化しないかまで、作業の流れの中に組み込まれている点が大きいところです。
数字で見える現場感
GitHubブログでは、2026年5月3日から6月2日までの30日間の数字が示されています。この期間にmicrosoft/aspireでは396件の製品プルリクエストがマージされ、pr-docs-checkのワークフローも396回走りました。そのうち82件でmicrosoft/aspire.devにドキュメント下書きプルリクエストが作られ、82件すべてがマージされています。ドキュメントのマージまでの中央値は44.8時間で、24時間以内に38%、7日以内に96%がマージされました。
すべての変更が文書になるわけではありません。内部リファクタリング、テスト修正、依存関係の更新のように、ユーザー向けの説明が不要な変更もあります。396回走って82件だけ下書きが作られたという数字は、AIが何でも文章化するのではなく、文書にすべき変更をふるい分ける役割を持っていたことを示しています。
最後の承認は人に残した
この仕組みの読みどころは、AIが下書きを作っても、最後の承認を奪っていないことです。safe-outputsの設定では、作られるプルリクエストはdraft、つまり下書き扱いです。タイトルにはdocsの接頭辞が付き、docs-from-codeというラベルが付きます。対象リポジトリはmicrosoft/aspire.dev、ベースブランチはmainまたはrelease/*に制限されます。レビュー担当には、元の製品プルリクエストで機能を理解していたSMEが指定されます。
権限の作り方も慎重です。AIが直接GitHubへ自由に書き込むのではなく、意図を出し、それを別の小さな処理がプルリクエストとして形にします。GitHub Appの権限はaspireとaspire.devの2つのリポジトリに絞られ、AGENTS.mdや依存関係のmanifest、セキュリティ設定のような保護ファイルは触れない設計です。AIの判断は柔らかくても、実際に動ける範囲は固く狭められています。
チャットの外へ出るAI
エンジニアでない人にとって、このニュースの面白さはGitHubの細かな設定そのものではありません。AIが質問に答える箱から、仕事の流れの中で動く存在へ移っていることです。変更が起きたら、関係する文書を探し、下書きを作り、担当者へ回し、古い通知を片づける。こうした小さな受け渡しは、営業資料、FAQ、社内マニュアル、契約文書の更新にも似た形で存在します。
AIエージェントの価値は、人の判断を消すことではなく、判断の前後にある面倒な運搬を短くするところにあります。Aspireの例では、機能を作った人が文書の正しさを見るという最後のハンドルが残りました。だからこそ、AIは暴走する自動化ではなく、現場の遅れを減らす仕組みとして読めます。