日次スプリントレポートのAIエージェント:GitHubリポジトリを毎朝wikiに要約

役に立つスプリントアップデートは、短く、日付があり、日ごとに比較できます。しかし作るのは大変です。リポジトリを開いてマージ済みのプルリクエストを数え、レビュー待ちのものを探し、issueに目を通し、リリースが近いかを確認して、誰も磨き込む時間のない2段落を書かなければなりません。結局、アップデートが存在しないか、会議の直前に急ごしらえで作られ、ブロッカーに気づくのが遅れがちです。これは自律型AIエージェントに最適な仕事です。毎回同じ形で繰り返され、すでに構造化されたデータに基づき、ひと目で確認できるからです。

きっかけ:誰も集計しなかった朝のアップデート

出発点は、自律型エージェントを運用している人々の体験談にある使い方です。開発チームのツールを読み、起きたことを数え、毎朝スプリントのレポートを置いていくエージェントです。こうした話で繰り返されるのはデータ量ではなく規則性です。同じ構成のアップデートが毎日存在するので、単発の数字に反応するのではなく、傾向が見えるようになります。

Atakoはこの考え方を、1体のエージェントと1つの成果物で取り入れています。エージェントはGitHubを読み、計算し、書き、公開します。リポジトリには何も変更を加えず、生み出すのはレポートだけです。

エージェントの仕事

デリバリーアナリストは、「オーナー/名前」の形式で指定されたリポジトリをGitHubで読みます。実行のたびに、決まった手順を踏みます。

まず、今日の日付から数えて直近7日間にマージされたプルリクエスト、まだオープンのものとその経過日数、3日を超えてレビュー待ちのもの、開閉したissue、公開されたリリースを数えます。次にブロッカーを見つけます。5日を超えてオープンのプルリクエスト、同じテーマで積み上がるissue、コミットから見て遅れているリリースです。それぞれをリンクと作成者とともに挙げます。最後に直前の7日間と比較し、何が動いたかを伝えます。

その後、プロジェクトのwikiに「スプリントアップデート - 」にその日の日付を続けた新しいページを書きます。その日のページがすでにある場合は、2つ目を作らずに更新します。構成は変わりません。重要な3〜4つの数字、前の期間と比べた進捗、ブロッカーと滞留しているプルリクエスト、検討すべき判断です。結論から始まり、2分で読め、要点はチャットでも要約されます。

エージェントがしないこと

アナリストは読むだけで、GitHubには決して書き込みません。コメント、ラベル、レビュー、マージ、クローズはありません。コードもプッシュしません。誰にも連絡せず、出力先はレポートとチャットだけです。数字やリンクを創作することはなく、足りない数字は「取得不可」と書かれます。

日ごとにページがあり、エージェントが過去の日のページを上書きすることはありません。そのため、チームが読み返せる履歴が残ります。事実と解釈は分けられ、解釈にはその旨が明記されます。レポートは優先順位を提案しますが、押し付けはしません。これがヒューマン・イン・ザ・ループ設計の原則です。

Atakoでの設定方法

このユースケースのページから、デプロイは4つの手順で完了します。

1. GitHubを接続する。 Atakoが求めたときに、追跡するリポジトリの読み取りアクセスを渡します。接続は何かが作られる前に確認されます。
2. 状況を入力する。 リポジトリを「オーナー/名前」の形式で、そしてレポートの読み手を指定します。読み手に合わせてトーンが調整されます。
3. デプロイする。 1回の操作でエージェントと「スプリントアップデート」プロジェクトが作成されます。エージェントはプロビジョニングされ、最初の指示を自分で受け取ります。
4. 最初のアップデート、そして毎日のリズム。 アナリストが直近7日間の最初のレポートを作成し、その後、毎朝8時の実行を自分で予約します。

まだアカウントがない場合は、作成するとトライアルが始まり、その直後にシナリオが設定されます。管理者がエージェントの作成を許可していない場合、デプロイはその旨を伝えて停止します。

結果を見る場所

レポートは「スプリントアップデート」プロジェクトのwikiにあり、1日1ページ、新しいものから順に並びます。エージェントの要約はそのチャットにも届くため、ページを開く前にスマートフォンで要点を読めます。Atako Floorではアナリストが活動とともに表示され、リポジトリを読んでいるときと書いているときが、進捗を尋ねなくても分かります。

チャットで話しかけられます。数字の出どころを尋ねたり、ブロッカーの詳細を頼んだり、別のリポジトリを追うよう頼んだり、別の切り口でアップデートをやり直すよう頼んだりできます。エージェントは過去の実行の記憶を保持しています。

安全策

アクセスは意図的に絞られ、読み取り専用です。GitHubツール8個で、リポジトリの一覧と閲覧、プルリクエストの一覧と閲覧、issueの一覧と検索、コミットとリリースの一覧ができます。短いツールリストを見るエージェントは、数百のカタログに迷うエージェントより確実にツールを使います。既定では何も付与されず、各アクセスはAtakoからいつでも取り消せます。

人間による確認は、判断の場面に置かれています。レポートはブロッカーと滞留しているプルリクエストを示しますが、レビュアーに声をかけるか、プルリクエストを分割するか、リリースを延期するかを選ぶのはチームです。エージェントが見られるのはGitHubが返す情報だけです。説明のないプルリクエストや、ラベルのないissueが多いリポジトリは、精度の低いアップデートにつながり、レポートはそれを隠さずに伝えます。

期待できること

最初のアップデートは有用ですが、まだ一般的な内容でしょう。チャットで読み手と基準を調整すると、たとえばレビュー待ちの基準を3日から2日に短縮すると、精度が上がります。価値は繰り返しから生まれます。2週間たつと、連続したページを比較して、どのブロッカーが長引いているか、どんな傾向が現れているかが見えるようになります。少人数の技術チームにとっては、会議の前に記憶から組み立て直す振り返りと、毎日同じ定義でただ存在する日次のアップデートとの差になります。