AI成果物の品質管理｜下書き・内部承認・公開の3段階

「これ、もう納品扱いでいいんでしたっけ」。AIエージェントに資料を作らせている現場で、いちばんよく出るのがこの一言です。

作らせるところまでは、思っていたより早く進みます。詰まるのはそのあとで、出来上がったファイルがいまどういう扱いなのかを、誰も言い切れなくなります。下書きのつもりだったものが共有の場所に置かれ、そのまま社外へ渡ってしまう。この種の事故は、中身の出来ではなく、扱いの曖昧さから起きます。

この記事は、AIエージェントが作った成果物を下書き・内部承認・公開の3段階で扱い、承認した事実をあとから取り出せる形で残す運用フローを扱います。素材は運営元WEBMARKSの運用ルールと、公式ドキュメント4件です（確認日2026-08-03）。

進行役は3人です。高梨課長が自分の手で動かす側から聞き、大森部長が任せる範囲と責任の側から聞き、鈴木さん（本誌監修）が答えます。

01AIエージェントが作った成果物は、そのまま納品してもいいんですか？

高梨課長

高梨課長の発言

AIに作らせた報告書、体裁は整っているんです。これをそのままお客様へ出していいのかが、どうにも決めきれなくて。

鈴木さん

鈴木さんの発言

出来のよさと、出してよいかは別の話だと思っています。厨房で仕上がった料理と、客席へ運んでよい料理は、同じ皿でも扱いが違いますよね。

判断のよりどころは、中身の完成度ではありません。その成果物がいまどの扱いに置かれているかです。同じファイルでも、作業中の下書きとして置かれているのか、社内で正式版と決めたものなのか、外へ出したものなのかで、してよいことが変わります。

扱いを決めずに運用すると、判断はその都度の空気に委ねられます。急いでいる日は下書きが確定版に見え、余裕のある日は確定版がもう一度見直される。同じ組織の中で基準が揺れるのは、たいてい状態の言葉が用意されていないからです。

そこで、成果物の管理を3つの層に分けて考えます。いまどの状態にあるかという定義、誰がいつ何を根拠に承認したかという記録、承認を経ていない道からは書き込めないという入口の設計の3つです。この3層は、それぞれ別の失敗を受け止めます。

02AI社員の成果物の品質管理は、承認ゲートだけでは足りないんですか？

AIエージェントそのものの輪郭はAIエージェントとは｜3条件で見分け、任せる前に決める3つで、取り消せない操作を止める仕組みはAIエージェントの承認ゲート｜止める操作4種と3層の選び方で扱っています。

Anthropicは、処理の途中でいったん立ち止まり、チェックポイントで人の判断を仰ぐ設計を挙げています（出典: Anthropic公式）。承認ゲートは、この立ち止まる場所を、送信・公開・削除といった操作の直前に固定したものです。

ただし、ここで止まるのはその1回の操作です。成果物のほうは、作られてから外に出るまでの間に何度も手が入り、いくつもの版を持ちます。どの版が承認を受けたもので、どの版がまだなのか。この情報は、操作を止めるだけでは手元に残りません。

言い換えると、承認ゲートは点を守り、状態管理は線を守ります。本記事が扱うのは、承認ゲートの手前にある「そもそも、いまどの状態にあるのか」のほうです。

03AIエージェントの成果物は、どの3段階で状態を分けるんですか？

高梨課長

高梨課長の発言

状態を分けるといっても、結局はフォルダを分けるという話でしょうか。

鈴木さん

鈴木さんの発言

置き場所は結果のほうです。先に決めるのは、その状態では誰が何をしてよいか。そこが決まると、置き場所は自然に決まります。

WEBMARKSが2026-07-10に定めた運用ルールでは、状態を次の3段階に分けています。

読み替えるときの勘どころは3つあります。第一に、既定は下書きです。何も宣言していない成果物は、どれだけ整っていても下書き扱いになります。第二に、内部承認は「社内では正式」であって「外に出してよい」ではありません。第三に、公開は状態が進むだけで、ファイルは動きません。

04AI導入した現場で、成果物の置き場所はどう分けるんですか？

状態を決めたら、置き場所でも同じ線を引きます。設計の考え方が伝わるよう一般化すると、案件フォルダはこうなります。

案件フォルダ/
├ _work/                 ← 下書き（既定・検索対象外）
│  └ 20260803_report/
├ 納品/                  ← 内部承認・公開（承認済み現行版のみ・直接書き込み禁止）
│  └ 20260803_report/
├ retired/               ← 旧・公開版（差し替え後・復元用に可逆移動）
│  └ 20260710_report_v2/
└ _MANIFEST.md           ← 状態・正本・承認の記録（SSOT）

案件フォルダの直下に置いてよいのは、この4つだけに絞ります。ここに他のファイルが紛れ込むと、どれが正本なのかが一目で言えなくなり、状態の線が引かれていても意味を失います。

もうひとつ、昇格させる範囲にも枠をはめます。1回の昇格操作は、1つの案件ID（CASE-YYYYMMDD-形式）に閉じた範囲で行います。GitHub Copilot cloud agentが1タスクにつき1ブランチ・1プルリクエストへ範囲を絞るのと同じ考え方です（出典: GitHub公式ドキュメント）。

05AIエージェントの成果物の品質管理で、承認の証跡は何を残すんですか？

状態を先へ進めるだけでは、あとから「誰が・いつ・何を根拠に」承認したのかを説明できません。承認した事実は、次の4つの欄で記録します。各欄をなぜ残すのかは、AIエージェントの承認ゲート｜止める操作4種と3層の選び方の証跡の表で扱っています。

成果物の差し替えという観点でいちばん見落とされやすいのが、対象ファイルのハッシュ値（canonical_sha256）です。承認は「そのときの中身」に下されたものであり、あとから差し替わったファイルにまで効いているわけではありません。記録項目の全体設計はAIエージェントの監査ログ｜説明できる5項目と3段の点検で扱っています。

_MANIFEST.mdへの記録例は次のとおりです（値は仮のものです）。

{
  "case_id": "CASE-20260803-EXAMPLE",
  "artifact": {
    "status": "approved_internal",
    "canonical_path": "納品/20260803_report/report_v3.md",
    "canonical_sha256": "8f0a2c1e...",
    "approved_by": "(承認者の氏名)",
    "approved_at": "2026-08-03T10:00:00+09:00",
    "approval_evidence": "(承認の発言・証跡へのリンク)"
  }
}

承認者の名前と時刻と根拠は、承認した瞬間に書けます。ハッシュ値だけは性格が違い、書いた瞬間には何の役にも立ちません。効いてくるのは、外へ出す直前に照らし合わせるときです。

06AI社員に成果物を承認させてよい範囲は、どこまでなんですか？

大森部長

大森部長の発言

承認まで任せられれば速いのですが、どこまで預けてよいものでしょうか。線を引く根拠が欲しいです。

鈴木さん

鈴木さんの発言

社内でとどまる判断は預けられます。外へ出ていく判断は預けられません。速さより、戻せるかどうかで線を引いています。

社内正式採用への委任は、案件単位で明示された場合に限って認められます。この委任が及ぶのは、内部承認や旧版の退役のように、社内で完結する範囲までです。

公開そのものは委任の対象外とし、人間の判断を経ます。ここを一緒にすると、対外的な確定まで代行させることになり、あとから「誰の判断だったのか」が誰にも言えなくなります。

07AIエージェントの成果物を納品フォルダへ上げる道は、どう1本にするんですか？

高梨課長

高梨課長の発言

状態も記録も決めました。ただ、私がうっかり手でコピーしたら、そこで終わりですよね。

鈴木さん

鈴木さんの発言

そのとおりです。だから決まりで支えるのをやめて、入口を1本にして、他の道を閉じます。人の注意力を仕組みの一部にしないほうがいいと思っています。

内部承認への昇格は専用のコマンドに寄せ、直接のWrite・Edit・cp・mvを塞ぎます。手をつける順番としては、通ってよい道のほうが先です。

# 内部承認への昇格計画を確認する（既定はdry-run。実際には書き込まない）
python3 90_tools/output-lifecycle/cli.py adopt \
  --manifest '案件フォルダ/_MANIFEST.md' \
  --source '案件フォルダ/_work/report.md' --target '案件フォルダ/納品/report.md' \
  --approved-by '(承認者の氏名)' --approved-at '2026-08-03T10:00:00+09:00' \
  --approval-evidence '(承認の発言・証跡)'

# 差分と対象ハッシュを人が確認したうえで、案件IDを完全一致させて実行する
python3 90_tools/output-lifecycle/cli.py adopt \
  --manifest '案件フォルダ/_MANIFEST.md' \
  --apply --confirm-case-id CASE-20260803-EXAMPLE

--applyには対象の案件IDを完全一致で渡します。一致しなければ処理はそこで止まり、書き込みは実行されません。このコマンドが扱うのは内部承認までで、公開そのものは対象外です。送信・公開は人間の直接判断であり、CLIでは代行しません。

08AIエージェントが別の道から書き込もうとしたら、どこで止まるんですか？

道が1本できたら、残りの道を閉じます。閉じる場所は、書き込まれたあとではありません。呼び出しが実行される、その手前です。

塞ぐ側は、ツール実行の直前で判定する仕組みで支えます。Claude Codeは、ツール実行直前に発火するPreToolUseフックを定義しています（出典: Claude Code公式ドキュメント）。Write・Edit・Bashなどの呼び出しをmatcherで捕捉し、判定結果をallow・deny・askで返せます（出典: Claude Code公式ドキュメント）。決定を返さずに終了したときは、その呼び出しは通常の権限フローに戻ります（出典: Claude Code公式ドキュメント）。

納品/宛のWrite・Edit・cp・mvを検出したら、そのフックはdenyを返し、「コマンド経由で進めてください」という理由を添えます。昇格コマンド自身の書き込みだけは、このdenyの対象から外します。ここを外し忘れると、正しい道まで閉じてしまいます。

09AI活用の現場で、成果物の品質管理はどこでつまずくんですか？

設計どおりに書いたつもりでも、次の3つでつまずきます。

1. 状態の正本を複数の場所に置いてしまう。フォルダの状態と_MANIFEST.mdの記載が食い違うと、どちらを信じればよいのか誰にも言えなくなります。状態の正本は_MANIFEST.mdの1か所に固定します。
2. ハッシュを記録せず、差し替わった版にも承認が及んでいると思い込む。承認はそのときの中身に対してのものです。
3. 委任の範囲を公開まで広げてしまう。内部承認や旧版の退役を預けても、公開の判断は人に残します。

大森部長

大森部長の発言

2番目は、記録を1欄足すだけの話に見えます。それでそんなに変わるものでしょうか。

鈴木さん

鈴木さんの発言

変わりました。うちでは、ファイルの更新時刻から担当や正当性を推定する仕組みを使っていた時期があります。3日間で233回、誤った確認が出ました。

原因は、時刻という代理指標が、実際の変更内容を表していなかったことです（出典: 社内タスク台帳、2026-07-10記録）。近い時刻に触られていることと、同じ担当が同じ意図で触ったことは、別の話でした。

これは状態管理そのものというより、状態を裏づける証跡のほうの欠陥です。詳しい経緯はAI運用の障害の原因切り分け｜証跡で追う4段の順序で扱っています。

10生成AIの成果物を公開してよいかは、どう確かめるんですか？

設計しただけでは、実際に機能しているかは分かりません。次の3点を確かめます。

• _MANIFEST.mdのstatusと、実際にファイルが置かれているフォルダ（_work/・納品/・retired/）が一致しているか
• 納品/配下のファイルすべてで、記録済みのcanonical_sha256と現物のハッシュが一致するか
• 納品/へ直接Write・Edit・cp・mvを試みたとき、実際に拒否されるか

# 1. MANIFESTのstatusを確認する
grep '"status"' 案件フォルダ/_MANIFEST.md

# 2. 納品/配下のハッシュが記録値と一致するかを確認する
shasum -a 256 案件フォルダ/納品/report.md

# 3. 直接書き込みが拒否されるかを確認する（フックが動いていればdenyで止まる）
cp 案件フォルダ/_work/report_v4.md 案件フォルダ/納品/report.md

3点目を省くと、書いたところで安心してしまいます。実際に操作を試して、拒否される画面を目で見たときに、はじめてこの設計は機能したと言えます。

11よくある質問

12まとめ｜今日やる3つのこと

状態は名前ではなく、その状態で誰が手を出せるかで決めました。証跡は名前と時刻だけでは足りず、中身の指紋まで残しました。そして塞ぐときは、通ってよい道を先に1本作りました。