「AIの完了報告は信用できない」。この結論で止まっている記事は多いのですが、私は逆側に倒しました。完了判定の権限をAIに渡し、人間は事後に覆す運用です。

タスク台帳の✅化を、私が毎回確認してから付ける方式をやめました。代わりに、証拠（コミットと成果物のパス）が実在するものだけAIが✅化し、私は後から差し戻します。この記事は、その線引きをどこに引いたか、引いた理由は何か、の記録です。実装は私の個人環境（Claude Code + Markdown台帳 + シェル/Node.js）のもので、一般的なベストプラクティスとして書くものではありません。

なぜ「確認してから✅」をやめたのか

最初は「AIが完了と言ったら、私が中身を見て✅にする」運用でした。安全ですが、台帳の未完了が溜まる一方でした。完了済みのものを私が✅に変換するだけの作業が毎日発生し、見るべき「本当に怪しいもの」が埋もれていきました。

ここで効いたのが、過去の体験の2つです。

1つ目は、AIの生成物を「信頼するが検証する」に切り替えたときの経験です。Claude Codeが存在しないライブラリのメソッドを書くことが何度かあり、CLAUDE.mdに「外部ライブラリを使うなら公式ドキュメントのURLを添える」というルールと、自動テストの実行を足しました。ハルシネーション由来のエラーは月10件から2件に減りました。教訓は、AIに任せるかどうかではなく、検証コストをほぼゼロにできる形に変えられるかだということです。完了判定も同じで、「見る」を人間の作業にしている限りスケールしません。

2つ目は、誤送信を一度起こした経験です。メール送信のような外部向けアクションをAIが自律で行う構成にしたところ、誤送信が1回発生しました。以降は外部アクションに必ず承認キューを挟んでいます。ここから得たのは「内部操作は自動、外部操作は承認必須」という線引きです。完了判定の権限委譲を考えるときも、この線がそのまま使えました。

設計の核：3つの線引き

私の環境で採用したルールは次の3つです。

線引き	内容
① 証拠必須	成果物のパスが実在し、そのパスに触れたコミットがある、または実行ログが実在する。この場合だけ「高確度」で自動✅
② 対象外	人間の物理行動（署名・現地作業など）、外部アクションの実行、毎月繰り返す定常タスクは自動✅しない
③ 事後監査	高確度は全件レビューせず、週1回の抜き取りで検査。台帳の宣言だけが根拠のものは全件レビュー

AIの判定区分は4つです。

区分	意味	扱い
auto-high	成果物＋コミット実在、または実行ログ実在	自動✅・抜き取り監査のみ
auto-mid	台帳の完了宣言だけ（裏づけなし）	自動✅・全件を私がレビュー
llm-review	対象外の疑いあり（機械では判別不能）	AIが行文を読んで確定してから処理
excluded	定常タスク／差し戻し済み	自動✅しない

ポイントは、自動✅を許す代わりに、確度の低いものほど人間の目に必ず触れる設計にしたことです。midは「自動✅したが全件を私に見せる」。highは「見せないが、抜き取りで質を担保する」。どちらも「勝手に完了にして終わり」にはなりません。

証拠判定の最小実装

判定ロジックは、考え方だけ伝わる最小のものを書きます。以下は説明用に書いた簡略版で、私の本番スクリプトそのものではありません。今回は実行していません（not-executed）。 動作の出力は載せません。

#!/bin/sh
# usage: classify.sh <task-line-file> ; git リポジトリ内で実行する想定
line=$(cat "$1")
case "$line" in
  *"分類:定常"*|*"[物理]"*|*"[外部]"*) echo excluded; exit 0;; esac
path=$(printf '%s' "$line" | sed -n 's/.*path=\([^ ]*\).*/\1/p')
if [ -n "$path" ] && [ -e "$path" ] && [ -n "$(git log --oneline -1 -- "$path" 2>/dev/null)" ]; then
  echo auto-high; exit 0
fi
case "$line" in *"完了"*) echo auto-mid; exit 0;; esac
echo no-evidence

読み方は次のとおりです。

1つ目の case は、対象外のマーカー（分類:定常 / [物理] / [外部]）が行に含まれていれば excluded にする。
path= に書かれた成果物が存在し（-e）、そのパスに触れたコミットが1件でもあれば auto-high。
証拠はないが行に「完了」という宣言があれば auto-mid、どちらもなければ no-evidence。

この簡略版には既知の限界があります。path= の中身が実在するだけでは、そのコミットが当該タスクのために作られたかは分かりません。別の作業で触れたファイルでも auto-high になり得ます。また、対象外の判定を文字列マッチだけに頼っているため、行にマーカーが書かれていない物理タスクは素通りします。後者は次の節の問題につながります。

正規表現に「対象外」を判定させて失敗した話

対象外の判定は、最初は正規表現だけでやっていました。「署名」「現地」「送信」などの語が行にあれば除外、という素朴なものです。

問題は、「その操作を行うタスク」と「その操作の仕組みを直すタスク」を正規表現は区別できないことでした。「メール送信の承認フローを直す」は私の物理行動でも外部アクションでもないので自動✅してよいのに、「送信」という語で除外されます。逆の取りこぼしもあります。自分の台帳で候補を洗い出したところ、117件の候補のうち53件が誤検知でした（私の台帳を一度スキャンした観測で、一般的な精度ではありません）。

そこで、除外の疑いがある行は llm-review という区分に分け、AIが行文を読んで確定してから処理することにしました。機械で決められない部分を「人間に聞く」ではなく「AIに読ませる」にしたのは、聞く件数を増やすと元の確認作業に戻ってしまうからです。ただし、ここもAIの判断なので、後述の抜き取り監査の対象になります。

事後監査：週1で3件、成果物を実際に開く

自動✅を許す以上、誤完了は必ず起きます。それを前提に、監査の側を仕組みにしました。

起動時に、前回以降に自動✅した全件の1行リストを必ず出す（件数が多くても全件）。
auto-midは最大4件ずつ、私に「完了でよい／差し戻す／中身を見たい」と聞く。その際、何のタスクか、何を根拠に完了としたか、残作業がありそうな記述はないか、を添える。
差し戻した行は以後、自動✅の対象外にする。人間が「未完了」と判断した行を、機械が閉じ直す往復を防ぐためです。
週に1回、auto-highから3件を抽出し、成果物を実際に開いて完了条件と照合する。

抜き取りの頻度は固定にしていません。誤完了が見つかったら、その後1週間はauto-highも全件レビューに格上げします。4週連続でゼロなら、抜き取りを週2件に緩めます。監査を「やった形跡」で終わらせないために、強度を結果に連動させました。

ここでE-044（工数管理）の経験が効いています。8人のチームで工数がExcelの自己申告だったとき、「正確に入力させる」より「自動で推定して、差異をアラートする」方が現実的でした。完了判定も同じ構造で、正確な完了報告を求めるより、証拠から機械が推定し、怪しい差異だけ人間が見るほうが続きます。差異の拾い方を工夫した結果、赤字になりかけた3件のプロジェクトを早めに見直せたのと同じ発想です。

やってみて分かった限界

証拠は「完了の十分条件」ではない。 コミットがあってもテストが通っていない、成果物があっても依頼の半分しか満たしていない、は普通にあります。抜き取りで拾えるのは、見た3件の範囲だけです。
差し戻しのコストは非対称。 内部ファイルの更新ミスなら差し戻しで済みますが、外部アクションの完了を誤認すると取り返しがつきません。だから外部アクションは自動✅の対象外にしています。
この権限委譲はまだ短期の運用実績しかありません。 手順を決めたのは2026年10月で、抜き取りを緩める条件（4週連続ゼロ）をまだ満たした週はありません。効果を数字で示せる段階ではない、という前提で読んでください。

まとめ

完了判定の権限をAIに渡す条件は、証拠（コミット・成果物パス・実行ログ）が機械で確認できること。
人間の物理行動・外部アクション・定常タスクは、自動✅の対象外にする。
確度が低いものほど人間の目に触れさせ、確度が高いものは抜き取り監査で担保する。
監査の強度は、誤完了の発生に連動して自動で上下させる。

結局のところ、私がやったのは「AIを信用する」ことではなく、「信用しなくても回る形に、確認の入れどころを動かす」ことでした。確認作業をなくしたのではなく、毎回全部を見る確認から、怪しいものだけ・一部だけ・事後に見る確認へ置き換えた、というのが実感に近いです。

正直、対象外の判定を正規表現だけで済ませようとして、誤検知に何度かやり直しました。同じところでつまずいている方が遠回りせずに済めば、この記事を書いた意味があります。似た経験や「うちはこう回避した」があれば、ぜひコメントで共有してください。