依頼を分類し、既存作業と権限を確認して、実行結果まで確かめる
AI Work Governance｜基礎 4/6 — 依頼から実作業へ
「これ、Issueにして」
AIにこう頼むだけなら簡単です。文章を整え、タイトルを考え、Issue本文の案を作る。それだけなら、現在の大規模言語モデル（LLM）はかなり上手にできます。
しかし、本当にGitHub上へ仕事を残そうとすると、その間にはいくつもの判断があります。
そもそも新しいIssueが必要か 既存Issueへ追記する話ではないか すでにPull Requestが開いていないか 調査・設計・実装・レビューのどれなのか どの実行手段を使えるか その操作をしてよい権限があるか どのリポジトリ・Issue・Pull Request・ブランチが対象か 実行後、本当に期待した状態へ変わったか
自然言語を理解することと、リポジトリ上で正しい仕事を実行することは別の問題です。
前の記事では、AIがリポジトリをどこから読むかを扱いました。この記事ではその次、読める状態になったAIが、ユーザーの依頼をどう継続可能な実作業へ変えるかを考えます。
「Issueにして」を、そのままIssueにしない
AIに「Issueにして」と頼まれたときでも、最初の仕事はIssueを作ることではありません。まず、依頼が何を達成したいのかを確認します。
- 既存の記事Issueへ追記する
- 記事候補の一覧へ追加する
- 情報源の整理だけ行う
- 既存記事の一節として吸収する
- 新しい独立記事として起票する
- まだ会話内の検討に留める
最初に必要なのはGitHub上の箱を決めることではなく、この依頼のあとに何を残したいのかを明確にすることです。
ユーザーの言葉
↓
この作業のあと、何が残ればよいか
↓
すでに同じ責務を持つ作業はあるか
↓
どこへ残すのが適切か
依頼と、GitHub上の作業記録は同じものではない
自然言語の依頼は、仕事の入口です。IssueやPull Requestは、その仕事を継続して扱うための記録です。
GitHub Issue = 何を追跡する仕事なのか Pull Request = どんな具体的変更をレビュー・検証するのか 作業メモ = 検討途中の情報や判断を残す 設計記録 = なぜその設計を選んだのかを残す
これはGitHubの唯一の使い方を主張するものではありません。重要なのは、問題を追う場所と、具体的な変更を確認する場所を分けられることです。
依頼 ├─ 会話内の検討だけ ├─ 既存Issueへ追記 ├─ 新規Issue ├─ 設計作業 ├─ 実装Pull Request ├─ レビュー └─ 記録して保留
依頼文の名詞と、作るGitHub上の記録を直結させない。これが第一の境界です。
新しい作業を作る前に、既存の担当先を探す
依頼のたびにIssue、再利用手順、規則、記事、設計書を新しく作れば、局所的には前へ進んだように見えます。しかし同じ責務を持つものが複数あると、あとで維持コストが増えます。
新しい依頼 ↓ 既存作業を探す ↓ 責務を比較する ↓ 新規 / 更新 / 関連 / 重複 / 後続 / 保留
検索は候補を見つけるために使い、その後に何を担当する仕事なのかを比較します。
実行手段があることと、やってよいことを分ける
実行手段がある
↓
技術的に実行できる
↓
今回実行してよい
しかし、この三つは別です。できることと、やってよいことを分ける。
内部のシステム表現では、この違いを次のようなtokenで持つことがあります。
Capability Authority
読者が英字を覚えることが目的ではありません。確認したいのは、その操作を技術的に実行できるか、ユーザー指示と対象のルールが許可しているか、現在状態を十分に確認できているか、といった条件です。
リポジトリAへの書き込み許可が、リポジトリBへ自動で広がるわけではありません。コメントしてよいことが、マージしてよいことを意味するわけでもありません。
「GitHubへ書き込める」を一個の真偽値にしない
Issueへコメントする Pull Requestを作る ブランチを作る 既存ブランチを更新する マージする 履歴を書き換える
は、それぞれ別の状態変化です。公開記事で内部形式を覚える必要はありません。持ち帰るべき問いは二つです。
権限の問い この種類の操作を、この対象へ行ってよいか？ 実行の問い 具体的に、どの状態をどの状態へ変えるのか？
設計があることと、すべて自動で強制されることも別
考え方が定義されている
≠
すべての環境で実装済み
≠
すべての操作で自動強制される
≠
十分に検証済み
この差を消さないことは、AI-WGを説明するときに重要です。設計済み、実装済み、実行中、検証済みを同じ「できている」にまとめると、実際の運用状態から離れていきます。
小さな実例 — 記事アイデアを作業へつなぐ
会話で記事アイデアが出る
↓
何を残したい依頼か整理する
↓
既存の記事・候補と重複していないか確認する
↓
どの記事群・役割に置くか確認する
↓
必要ならIssueや原稿案へ変換する
↓
情報源と文章品質を確認する
一つの機能が最初から最後まで全部を決める必要はありません。分類することとGitHubを書き換えること、提案することと外部公開することは別です。
分類した ≠ 変更してよい 提案した ≠ 公開してよい
この限定された経路は「あらゆる依頼を完全自動でGitHub作業へ変換できる」という証明ではありません。しかし、依頼を理解する責務、既存作業を探す責務、置き場所を決める責務、実際に変更する責務を分けられる実例にはなります。
実行したら、もう一度読む
「実行した」という報告と、現在の状態は別だからです。
意図 ↓ 実行 ↓ 実行結果の記録 ↓ 現在状態を読み返す ↓ 期待した状態と実際の状態を比較する
- 作ったIssueのリポジトリは正しいか
- タイトルと本文は意図した内容か
- ブランチの先頭は想定したコミットか
- Pull Requestの変更元と変更先は正しいか
- コメントは対象の会話へ入ったか
内部のシステム表現では、実行後の確認を次のようなtokenで表す場合があります。
Verification Read-back
大切なのは英字ではなく、AIの自己申告を現在状態の正本にしないことです。
一枚で見る「依頼から実作業へ」
ユーザーの依頼
↓
何を残したいか整理する
↓
既存作業との関係を確認する
↓
適切な作業記録を選ぶ
↓
必要な現在状態を確認する
↓
実行手段を確認する
↓
権限を確認する
↓
許可された操作を実行する
↓
実行結果を読み返す
↓
期待した状態になったか確認する
↓
人間が確認できる作業記録として残す
この経路の目的は、AIを遅くすることではありません。曖昧な依頼を、その場の思いつきではなく、既存の仕事とつながった継続可能な作業へ変えることです。
コメント