GitHub PR から Control Center に話しかける

このガイドでは、GitHub から離れずに Control Center を操作する方法を説明します。 PR ページから AI レビューを依頼し、コメントでボットに質問し、そのレビュースレッドで会話を続けられます。

ボットは、あなたのサーバー自身の GitHub App です — すでにサインインとバックグラウンド作業を担っているものと同じです。新しく登録するものは何もなく、インターネットから到達可能でなければならないものもありません。サーバーはポーリングによって GitHub 上で発言された内容を検出するため、NAT の背後にあるノート PC も公開デプロイとまったく同じように動作します。

前提条件

サーバーに GitHub App が登録およびインストールされていて、Pull requests: read and write （コメント、スレッド、リアクション用）と Issues: read（コメント検索用）の権限があること。どちらもそのガイドの権限一覧にすでに含まれています
リポジトリが Control Center のワークスペースにリンクされていること
Webhook URL もトンネルもコールバックも不要 — ネットワーク側で設定するものは何もありません

ボットの名前を調べる

ボットのログイン名は <appslug>[bot] です。ここで appslug は、アプリを登録したときに付けた名前です。

設定 → サーバー → シングルサインオンに移動し、プロバイダーアプリカードまでスクロールします
GitHub ブロックを開き、テストをクリックします
ボットログインが入力されたらコピーします。空のヒントが表示されたままの場合は、ログイン名は常に <appslug>[bot] です — それを入力するか、短縮形の @appslug を入力します

GitHub は @ オートコンプリートでアプリのアカウントを候補に出さないため、ログイン名は手入力する必要があります — 設定カードがワンクリックでコピーできるようにしているのはそのためです。[bot] サフィックスは省略できます。@myapp と @myapp[bot] はどちらもボットに届きます。

GitHub からレビューを依頼する

2 つの方法があり、どちらも AIに質問ボタンが開始するのと同じ、シード済みの pr_review パイプラインを開始します。

PR に ai-review ラベルを追加する。これは、ボットをレビュアーとして割り当てるために GitHub が提供する最も近い手段です — アプリのアカウントは、GitHub ネイティブの「レビュー依頼」スロットを保持できません。リアクションを付ける対象のコメントがないため、GitHub には何も投稿されず、レビューは Control Center で開始されます
PR 会話に @myapp review（または単に @myapp）をコメントする。ボットは 👀 でリアクションし、レビューが開始されたとき（またはすでに実行中であるとき）に返信します

レビュアーはその PR のレビュースペースで作業します。指摘の読み方と公開の仕方は AI レビューを使うと同じです。GitHub への公開は Control Center で下す判断のままです — GitHub からレビューを開始しても、それだけで GitHub に何かが公開されることはありません。

ラベルは PR ごとに 1 回だけ発火します。追加することが依頼であり、外して付け直しても再び武装されることはありません。レビューをもう一度実行するには — たとえば push の後など — ボットをメンションします。

質問する

PR 会話にコメントします:

@myapp why does the flaky test in runner_test.dart fail on CI but not locally?

何が起きるか、順番に:

ボットが 👀 でリアクションし、コメントが見られたことがわかります
質問はあなたとしてその PR のレビュースペースに投稿されます — Control Center で入力した場合と同じ帰属です
エージェントがスペースで回答し、その回答はあなたを @メンションするコメントとして PR に返信されます

まだレビューのない PR での質問は、ワークスペースの CEO エージェントを起こします。レビューが一度実行された後は、最後に発言したエージェントが答えるため、フォローアップはコンテキストを持っている相手に届きます。

レビュースレッドでフォローアップする

ボットが参加しているインラインのレビュースレッドの中で返信します — ボットが残した diff コメント、またはそのスレッドに投稿した回答です。メンションは不要です。スレッド自体が宛先指定です:

> @myapp the retry loop looks O(n²) to me

what would the complexity be with the bounded queue instead?

マルチターンも同じように機能します。各返信は同じ会話におけるもう 1 つの質問であり、レビュースペースがコンテキストとなり、回答はそのスレッドに返ってきます。

PR 会話のタイムラインでのフォローアップは新しいトップレベルのコメントになるため、依然として @メンションが必要です。

ボットが応答する相手

GitHub のコメントはログイン名程度のものしか運んできません。そのためボットは、何かを行う前に作者を解決します:

あなたの GitHub アカウントが、Control Center のあなたのアイデンティティにリンクされている必要があります — 設定 → ワークスペース → プロフィールと識別情報 → コードホスティングから GitHub でサインインするか、トークンを貼り付けます
そのリポジトリをリンクしているワークスペースで、書き込みロールを持つメンバー（member、admin、owner）である必要があります

それ以外の相手には、何が足りないかを説明する丁寧な返信が 1 つ届くだけです — 未知のログイン名（未リンク、またはリンク済みだがここのメンバーでない）と読み取り専用ロールの 2 つのケースがあります — そしてその発言がワークスペースに入ることはありません。ai-review ラベルはこのようにはゲートされません。作者が存在しないため、すでにそのリポジトリをリンクしているワークスペースでレビューを開始します。

想定される動作

項目	動作
確認	コメントに 1 分ほどで 👀 — スイープ間隔です。`ai-review` ラベルにはリアクションを付けるコメントがありません
回答	ボット（アプリ）として、質問が投げかけられたレーンに投稿されます
スペース内の帰属	質問はあなたのものです。エージェントはあなたの代理として、スペースの自律度設定のもとで実行されます
レビュー	指摘はレビュースペースに届きます。GitHub への公開は手動です

およそ 1 分のレイテンシは、受信方向のネットワークアクセスを一切必要としないことの代償です。スイープはどれも緊急ではなく、サーバーがオフラインの間に失われるものもありません — 停止中に届いたコメントは、次のスイープで拾われます。

トラブルシューティング

ボットをメンションしたコメントに対して何も起きない。

アプリは、そのリポジトリを所有するアカウントにインストールされていますか。また、そのリポジトリはワークスペースにリンクされていますか。リンクされていないリポジトリは、何かが記録される前にスキップされるため、後からリンクしてもコメントは配信されます
あなたの GitHub アカウントはリンクされていますか。また、書き込みロールを持つメンバーですか。PR でボットの拒否返信を確認してください — どちらが問題かが書かれています
それでも何も起きない場合は、何かが失敗したときにサーバーログにスイープと PR が記録されます。pr_conversation:（ポーラー）と github_pr_conversation:（ブリッジ）を探してください

ラベルを付けてもレビューが開始されない。

これは PR ごとに 1 回だけ発火します。レビューがすでに実行されたか、サーバーが PR を認識する前にラベルが追加された場合（最初のスイープは未処理分を一斉に処理せず、黙って記録します）は、代わりにボットをメンションしてください — @myapp review は、レビューがすでに進行中でない限り、必ず開始します。

ボットの回答が GitHub に届かない。

回答自体が失われることはありません — Control Center のその PR のレビュースペースにあります。投稿の失敗（GitHub の障害、権限の変更）はログに記録され、返信は再試行されません。重要であれば、スレッドでもう一度質問してください。