Issue起票をAIに任せず、判断のない処理をワーカーに戻す
今回やったこと
GitHub Issue の起票をモデルに実行させる方式から、決定的なPythonワーカーへ移した。理由は、起票手順の中にモデルの判断が必要な箇所がなく、実機では前提としていた認証上の制約も成立していなかったためだ。対象の処理は、要求を受け取り、同じ印が付いたIssueを探し、必要なら作成し、結果を再取得して確かめるところまでである。
初版は「無人機から gh を使えない」という前提で、手順書をモデルに読ませてGitHubコネクタ経由で処理する設計だった。しかし運用機の gh は認証済みで、検索・作成・ラベルや担当者の設定を実行できた。前提が実際の環境と違うなら、モデルを中継させる理由は薄い。手順が決まっている作業は通常のコードで処理できる。
定型処理をワーカーにする
github_issue_outbox_worker.py は、モデルを使わないワーカーとして実装されている。要求に含まれる marker を使って既存Issueを探し、見つからなければ作成し、作成後に実物を取得して要求との差分を確認する。権限不足などで設定が反映されない場合もあるため、成功応答だけを信じず、取得し直した値を検証する。
検索インデックスには反映の遅れがある。そこで検索結果だけに依存せず、最近作成されたIssueも直接読み、markerを照合する。閉じたIssueが見つかった場合は新規作成ではなく再オープンする仕様もある。markerが複数件に一致したときは、推測で一件を選ばず曖昧な状態として扱う。これらは「起票する」一言の中に隠れた、重複や誤更新を避けるための境界条件だ。
outboxの要求
→ markerで検索
→ 必要な場合だけ作成
→ Issueを再取得
→ marker・設定内容を照合
→ 検証済みとして完了
モデルを挟んだときの実害
初版と並行して動いていたCodexのオートメーションは、10分ごとに同じスレッドを使い回していた。記録によると、スレッドは51MBに達し、1回あたりの消費は0.10Mから0.67Mトークンへ増えていた。5日で週枠の約半分を使い、処理対象が0件の回も同程度の文脈を読み直していた。これは記事生成のように判断や文章作成を必要とする仕事ではなく、手順が固定された起票処理で起きていた。
モデルの利用が常に無駄という話ではない。依頼内容から要件を整理するなど判断が必要な段階と、決まった要求をAPIへ反映する段階は分けられる。後者をスクリプトに移せば、入力が同じときに処理も追跡しやすくなり、実行コストを一定に保ちやすい。
スクリプト化にも必要な確認
モデルを外しただけで安全になるわけではない。GitHub APIが成功を返しても、ラベルや担当者が権限の都合で反映されないことがある。ワーカーは結果を再取得し、markerを含むタイトルや要求された設定を確認する。失敗した要求は記録し、次回に再試行できる設計が必要だ。また、処理の途中で応答が途切れた場合に、同じIssueを重複作成しないよう既存確認を先に置く。
この方式が向くのは、入力と手順が構造化され、結果の正しさを機械的に照合できる作業である。依頼の意味を判断する部分はモデルや人が担い、API操作と結果確認はワーカーに任せる。境界を切ることで、モデルの柔軟さを残したまま、繰り返し処理の挙動を予測しやすくできる。
環境・参照
実装と運用記録は scripts/github_issue_outbox_worker.py、docs/ai-ops/github_issue_outbox.md にある。トークン量は同ドキュメントが記録する当時のオートメーション実績であり、現在のモデル利用一般の値ではない。
更新履歴
- 2026-10-19: 初稿作成。