GitHubのプルリクエストをNotionの週次レポートに変換する方法
Leinaでマージ済みおよびオープンなGitHub PRのソースリンク付き週次レポートを作成し、チャットで下書きをレビューしてNotionに追記します。
エンジニアリングの週次レポートを書くとなると、通常は何十ものプルリクエストを手作業で確認し、リンクをコピーし、何がマージされて何がまだレビュー待ちなのかを把握する必要があります。
Leinaを使えば、このワークフローをチームチャットから直接自動化できます。GitHubとNotionを接続すると、エージェントがPRを収集し、ソースリンク付きの構造化されたサマリーを下書きし、承認されたバージョンをNotionワークスペースに追記できます。これを確実にする鍵は、下書きと書き込みのステップを分離し、公開前に数値を検証できるようにすることです。
まずは完了した1週間分から始めると、下書きを既知の記録と比較できます。
レポートの範囲を定義する
AIエージェントに記録を取得させる前に、レポートに含めるべきものの境界ルールを明確にします。最初の実行では、単一のリポジトリと完了した1週間に限定してください。
| セクション | 含めるルール | 伝える内容 |
|---|---|---|
| 今週マージされたもの | マージのタイムスタンプが指定された開始と終了の境界内にある | 期間中に対象ブランチに入った変更 |
| 現在オープンなもの | クエリ時点でPRがオープンである | 進行中の作業、下書きステータス、記録されたレビューのブロッカー |
オープンPRに関する注意: オープンPRのリストはクエリ時点のリポジトリを表します。前の週の終わりにオープンだったものを報告するには、保存されたスナップショットか、それ以降の状態変化の証拠が必要です。日付付きのレポートを保管しておくと、将来の比較のためにそれらのスナップショットが得られます。
GitHubのstateおよびmerge-date検索修飾子を使ってソースレコードを確認できます:
repo:OWNER/REPOSITORY is:pr is:merged merged:2026-09-28T00:00:00+00:00..2026-10-04T23:59:59+00:00リポジトリと日付を置き換え、タイムゾーンをレポートと一致させてください。この例ではUTCに+00:00を使用しています。チームが別のタイムゾーンで働いている場合は、レポート期間に適したオフセットを使用してください。
GitHubとNotionを接続する
Leina Consoleで、2つのワークスペース接続を認可します:
- GitHub: 対象リポジトリを読み取れるアカウントと、サマリーに必要なPRの詳細を公開する接続を使用します。
- Notion: 保存ステップでは、対象ページを読み取り、コンテンツを追記できる接続を使用します。
利用可能な操作はIntegrationsで、認可済みアカウントはConnectionsで確認してください。リクエストするメンバーにも、それらの接続を使用する権限が必要です。接続されたチームチャットでレポートを下書きし、レビュー後にNotionに書き込みます。
エージェントにレビュー可能な下書きを依頼する
ソースリンクと、情報が欠けている場合の明示的な扱いを必須とするプロンプトから始めます。このリクエストをコピーして調整してください:
[owner/repository]の週次エンジニアリングレポートを、[timezone]の[start timestamp]から[end timestamp]までを対象に作成してください。
- マージされたPR: その期間内にマージされたすべてのPRをリストアップしてください。各PRについて、番号、タイトル、作成者、マージ時刻、ソースリンク、およびPRの説明とツールで利用可能な変更に基づく1〜2文の変更サマリーを含めてください。
- 現在オープンなPR: 現時点でオープンなPRをリストアップし、下書きステータスと、記録されているレビュアーやブロッカーを記載してください。
- 不足しているコンテキスト: PRの説明が空であるか影響が不明確な場合は、明示的に*「Impact undocumented」*とマークしてください。ビジネス上の理由や結果を捏造しないでください。
- 取得に関する通知: 取得タイムスタンプを記載し、サポートされている場合は範囲内のすべての結果ページを取得し、不完全な取得やアクセスできない記録があれば報告してください。
完全な下書きをここチャットで返してください。まだNotionには書き込まないでください。
チームが標準化されたmarkdownレイアウトを使用している場合は、空の週次レポートテンプレートをフォーマットの参考として提供することもできます。
下書きをGitHubと照合する
Notionに何かを反映する前に、記録リストを比較し、サマリーをスポットチェックします:
- GitHub検索と件数を照合する: GitHub検索でmerge修飾子クエリを実行します。PRの数はエージェントのマージ済みリストと一致しますか？
- 境界のタイムスタンプを検証する: 時間枠の両端付近のPRをソースリストと比較します。それらのタイムスタンプと、選択に使用されたタイムゾーンを確認します。
- マージ済みとクローズ済みを分ける: マージされずに放棄されたクローズ済みPRが、誤ってマージ済みセクションに紛れ込んでいないか確認します。
- マージ済みとデプロイ済みを分ける: コードを
mainにマージしても、自動的に本番環境にデプロイされたことを意味するわけではありません。デプロイ記録や別の明示的なソースがその環境へのデプロイを確認しない限り、サマリーは実際にマージされたものに焦点を当ててください。リリースタグだけではコードのバージョンを識別するものです。 - 捏造されたサマリーがないか確認する: PRタイトルが単に「fix typo」や「chore: deps」である場合、エージェントが精巧なアーキテクチャ改善を捏造していないか確認します。
ギャップを見つけた場合、たとえばPRの説明が欠けている場合は、未記載としてマークしたままにします。未記載の変更を強調することは、チームがPRの説明を改善するための有用なフィードバックです。
レビュー済みレポートをNotionに追記する
下書きが正確に見えたら、Leinaに指定のNotionページへレポートを書き込むよう指示します:
レビュー済みレポートを
[Notion page URL]の見出し"[repository] — [reporting period]"の下に追記してください。
- まずその見出しが既に存在するか確認してください。存在する場合は、何かを変更する前に既存のセクションを見せてください。
- ページ上の他の既存コンテンツをすべて保持してください。
- 書き込み後、追加されたセクションを読み返し、Notionページのリンクを返してください。書き込み結果が不確かな場合は、再試行する前にページを確認してください。確認できない場合は、その旨を伝えてください。
これにより、ドキュメントが変更される前にレビューポイントが得られます。これはあなたがリクエストするワークフローであり、Leinaが実行できる操作は接続権限によって決まります。チームと共有する前に、保存されたセクションを確認してください。
このワークフローがチームでスムーズに機能するようになったら、このプロンプトを再利用可能なSkillに変換することができ、新しいレポート期間でフォーマットを再利用できます。チームメイトには引き続き関連する接続権限が必要です。