AIが仕事を続けられる作業環境の全体像
AI Work Governance｜基礎 2/6 — 全体像
前の記事「01｜AIを賢くするより、賢く動ける作業環境を作る」では、AIとの仕事を会話だけで終わらせず、判断材料・履歴・ルール・道具をつないだ作業環境へ残す考え方を紹介しました。
この記事では、その考え方に名前を付けます。
AI Work Governance（AI-WG） = AIそのものを管理するのではなく、AIと進める「仕事」の意味・状態・権限・根拠を、継続可能な状態として扱うこと。
ここでいうAI Work Governanceは、このサイトの記事群で使う整理のための概念です。外部で標準化された業界用語だと主張するものではありません。
AI Work Governanceが扱うのは、プロンプトより広い問題
AIを使うとき、最初に注目されやすいのは指示文です。もちろん、指示の書き方は重要です。しかし仕事が長くなり、複数の課題やAIが関わると、それだけでは足りません。
- 何を達成したいのか
- 何を正しい情報として扱うのか
- 何を先に進めるのか
- 何と何が依存しているのか
- どこまで終わったのか
- なぜその判断をしたのか
- 誰が何を決めてよいのか
- 何を確認すれば成立したと言えるのか
これらを人間の頭と、その場の会話だけで持ち続けるのは難しい。そこでAI-WGでは、AIへの指示文だけを工夫するのではなく、仕事を続けるための条件そのものを会話の外へ出すことを重視します。
会話の外へ、仕事の意味と状態を出す
人間の意図 正しい情報の置き場所 何をしてよいかという権限 判断した理由と履歴 未完了の作業状態 再利用できる手順 本当に成立したかを示す根拠
重要なのは、会話を全部保存することではありません。必要な状態を、その状態に責任を持つ場所へ残すことです。
- 作業課題はGitHub Issue
- 具体的な変更とレビューはPull Request
- 再利用する手順はファイルや手順定義
- 現在の意味を決める情報は、その責務を持つ正本
こうしておけば、次のAIが前の会話を丸ごと覚えていなくても、仕事を再構築する材料が残ります。
AIやGitHubは、AI Work Governanceそのものではない
AI Work Governanceは、ChatGPTでもClaude CodeでもCodexでもありません。GitHubやObsidianそのものでもありません。
GitHub Issues / Pull Requests Markdown / YAML Obsidian / ファイルシステム Git / worktree ChatGPT / Claude Code / Codex / OpenClaw
これらは実装手段です。目指すのは、どれか一つを交換したときに、仕事の意味まで失う設計にしないことです。
何を達成する仕事なのか どれを正本として読むのか どこまで変更してよいのか 何を満たせば完了なのか 何を確認すれば成立と言えるのか
もちろん、どのAIでも同じように動くという意味ではありません。使える道具、得意な作業、権限の仕組みは実行環境ごとに違います。
交換したいのは実行役であって、仕事の意味ではない。
一枚で見る、AI Work Governanceの責務
人間の目的
│
▼
意図と正しい情報の置き場所
│
▼
何をしてよいかという権限の境界
│
▼
作業項目と判断の状態
│
▼
再利用できる手順
│
▼
実行するAIと実行環境
│
▼
GitHub / ファイル / 各種ツール
│
▼
結果の確認と根拠
│
▼
次回も再構築できる作業状態
これは理解のための責務図です。すべての処理が必ずこの順番で動く、という実行フローではありません。
技術的にできる
≠
今回やってよい
内部のシステム表現では、この違いを次のようなtokenで持つことがあります。
Capability Authority
同じように、何を満たすべきか、何をしてよいか、どう進めるかも別の責務です。
何を満たすべきか 何をしてよいか どう進めるか
内部表現を正確に示す必要がある場合は、たとえば次のように区別できます。
Contract Authority Skill
読者がこれらの英字を覚えることが目的ではありません。仕事の条件・権限・手順を同じものとして扱わないことが重要です。
忘れても、仕事を再構築できるようにする
前回の作業から引き継ぎメモを残しても、それを現在の真実とは扱いません。引き継ぎは、再開するための手掛かりです。
前回残した再開の手掛かり
↓
参照先の正本・作業項目を確認
↓
変わり得る状態を現在の情報で確認し直す
↓
いまの仕事を再構築する
前回「次はこのPull Requestを直す」と書かれていても、すでにマージ済みなら現在の状態を採用します。目指す継続性は、AIが永遠に覚えていることではなく、忘れても仕事を再構築できることです。
「実行した」と「成立した」を分ける
- ファイルは本当に変更されたか
- 必要なテストは通ったか
- Pull Requestの対象版は正しいか
- 必要なレビューは成立したか
- 実際のGitHub状態は変わったか
- 人間の承認が必要な地点を越えていないか
Pull Requestがマージされた
≠
目的そのものが完了した
≠
外部公開が完了した
≠
必要な検証が完了した
「実行した」という報告
≠
「必要な状態変化が確認できた」という根拠
完全自動化を意味するわけではない
AI Work Governanceは、すべての仕事を自動で完遂する常駐AIを意味しません。ルールを書けばすべてのAIが必ず守る、という意味でもありません。
- コードやデータ形式で機械的に止められる境界
- 手順や規則としてAIへ要求する境界
- 人間の承認に残す境界
どこまで機械へ任せられ、どこから先が根拠不足・権限不足・人間の判断なのかを区別できること。
SHIPPOは、AI Work Governanceを具体化した実装例の一つ
ここまで説明したAI Work Governanceを、実際のリポジトリ、GitHub Issue / Pull Request、作業規則、再利用できる手順、検証記録、複数のAI実行環境へ落とし込んだ具体例の一つがSHIPPOです。
AI Work Governance = 一般概念 / 設計原理 SHIPPO = 具体実装 / 検証事例
SHIPPO固有の仕組みを理解しなくても、AI Work Governanceという考え方自体は利用できます。
まとめ：AIではなく、AIと進める仕事を統治する
AIそのものを管理するのではなく、AIと進める仕事の意味・状態・権限・根拠を、会話の外でも継続できるようにすること。
次の記事では、この作業環境にAIが入ったとき、どこから読み始め、何を正しい情報として確認するのかを扱います。
コメント