AIを完全に決定的にせず、自由度をレビューできる範囲へ寄せる
AI Work Governance｜基礎 5/6 — 境界と品質確認
AIモデルが賢くなれば、仕事の品質も自然に安定する。一見すると、そう思えます。
しかし、同じ「このPull Requestをレビューして」という依頼でも、何を正本として確認するか、どこまで見るか、修正までしてよいか、どの版を見たのか、何をもって承認候補とするのか、マージまで進んでよいのかは、モデル性能だけでは決まりません。
AIを完全に決定的にするのではなく、AIの自由度をレビューできる範囲へ寄せる。
品質管理は、出力された後だけに行うものではない
AIの品質管理というと、生成した文章やコードを最後にチェックするイメージが強いでしょう。しかし仕事の境界は、実行前にも決められます。
この作業の目的は何か 何をしてはいけないか どんな条件で止まるか どこまで操作してよいか 何を確認できれば完了と言えるか
内部実装では、この種の実行前の外枠を正式な構造として扱う場合があります。
Agent Run Envelope
重要なのは名称ではありません。実行する前に、仕事の目的・禁止範囲・停止条件・必要な根拠を確認できることです。
「何をするか」だけでなく「何をしないか」を決める
今回扱う範囲 = 何をするか 今回扱わない範囲 = 何をしないか
一つの不具合を直す依頼から、関連する設計整理、命名変更、大規模な整理まで広げることはできます。それらが有益でも、今回の仕事として許可されているとは限りません。
目的 対象範囲 今回は扱わないこと 禁止する操作 止める条件 必要な確認結果
内部の正規表現では、これらを次のようなtokenで持つことがあります。
objective scope non-goals forbidden_actions stop_conditions expected_evidence
読者がtokenを覚えることが目的ではありません。自由に考えてよい範囲と、越えてはいけない境界を外から確認できることが重要です。
「できる」と「やってよい」を分ける
技術的に実行できる
≠
今回その操作をしてよい
内部では、次のようなtokenで区別することがあります。
Capability Authority
読み取りできる
≠
書き込みしてよい
元に戻せる
≠
勝手に変更してよい
レビューできる
≠
マージしてよい
AIは「こう直すとよい」と考えられます。しかし、考えられることと、実際にリポジトリを変更することは別の状態変化として扱えます。
契約は、答えの形を固定するためだけではない
契約というと、JSON形式や定型文を想像しやすいかもしれません。しかし価値は「同じ形の文章を毎回出す」ことだけではありません。
あとから仕事が成立したか判断できる情報を残すことが重要です。
- 何を変えたか
- なぜ変えたか
- どの版を対象にしたか
- 何を検証したか
- 残る制約は何か
内部では、成果物に求める条件を次のような名前で扱う場合があります。
Output Contract
ここでも名前より、仕事の成立条件を観測できる形にすることが重要です。
生成・評価・承認を同じ仕事にしない
生成 = 成果物を作る 評価 = 定義された基準で確認する 承認 = 次の状態へ進めてよいか判断する
内部の処理名を正確に示す必要がある場合は、次のようなtokenを使うことがあります。
Generate Evaluate Approve
同じAIが複数の役割を担当する場合でも、意味上の責務を分けることはできます。作ること、確かめること、先へ進めてよいと判断することは別です。
品質ゲートは「品質保証機」ではない
品質ゲートは、決められた検査項目について、現在確認できた結果を返す仕組みです。
- 情報源は適切か
- 誇張した主張になっていないか
- 情報が古くなっていないか
- 根拠なしの断定がないか
内部の判定値として次のようなtokenを使うことがあります。
PASS WARN BLOCK
PASS = 定義された検査範囲で、進行を止める問題が見つからなかった WARN = 進める可能性はあるが、未確認事項や人間判断が残る BLOCK = 定義された条件を満たさず、そのまま次へ進めない
大切なのは、ゲートがどこまで確認したのかを失わないことです。
ゲートの判定 ≠ 内容の自動修正 ≠ 人間の受け入れ ≠ 外部公開の権限
警告があることは、失敗とは限らない
記事の根拠は十分だがWordPressのスマートフォン表示をまだ確認していない。設計としては成立しているが、人間がタイトルを最終判断したい。こうした状態を全部失敗にすると品質ゲートは硬すぎ、全部合格にすると未確認事項が消えます。
未確認事項を残したまま次の判断へ渡す状態が必要です。ただし、警告を誰が受け入れてよいかは別問題です。
「レビュー済み」には対象の版が必要になる
レビュー結果には、何を、どの版で、どこまで見たかが必要です。
対象 + 版 + 確認範囲 + 判定 + 根拠 / 残る制約
単に「レビュー済み」という状態だけを残すより、どの対象について成立したレビューなのかを固定する方が安全です。
人間を「最後に見る人」だけにしない
- 対象範囲が二つの正当な方向へ分かれた
- 元に戻しにくい操作へ進む
- 警告を受け入れる
- 設計上のトレードオフを選ぶ
- 外部公開を許可する
人間の判断が必要になる場所は最後だけとは限りません。重要なのは、どの判断・リスク・不可逆な操作を人間が保持するかを設計することです。
ルールは便利さを減らすだけではない
このリポジトリでは何を正本とするか レビューでは何を残すか どの操作で止まるか 技術的な主張をどう確認するか
こうした境界が外に残っていれば、別の会話や別のAIへ仕事を渡しやすくなります。毎回説明し直す必要がない境界を外へ出し、AIが考えるべき場所へ能力を使えるようにすることが狙いです。
一枚で見る、AIの仕事を安定させる構造
人間の目的
↓
今回の目的・対象範囲・扱わないこと
↓
何をしてよいかという権限
↓
AIが生成・提案する
↓
定義された基準で確認する
↓
PASS / WARN / BLOCK
↓
必要な人間判断
↓
許可された状態変化
↓
結果を確認する
AIを完全に同じ出力へ固定することは目的ではありません。AIが自由に推論できる場所を残しながら、仕事として越えてはいけない境界と、確認すべき条件を外から見えるようにする。これがAI Work Governanceにおける出力と作業の統治です。
前の記事： 04｜自然言語の依頼がGitHubの実作業に変わるまで
次の記事： 06｜AIの仕事をどう収束させるか
コメント