ChatGPT、Claude、Cursor、Grokbotなど、複数のAIを使い分けると作業を速く進められます。一方で、「終わりました」という報告だけを次のAIへ渡すと、古い情報や未確認の作業まで完了扱いになることがあります。
この記事では、複数のAIに仕事を分担するとき、初心者でも進捗を安全に確認する方法を紹介します。
AIごとに担当を決める
最初に、AIの役割を分けます。例えば次のような分担です。
- 実装担当：コードを書き、アプリを動かす
- 監査担当：実際のファイルやURLを見て、報告を確かめる
- 発信担当：確認済みの事実を記事や動画にまとめる
- 統括担当：期限、担当、判断待ちを一覧にする
1つのAIに全部を任せると、作ることと確認することが同じ視点になります。担当を分けると、「作った」と「確認できた」を別の状態として扱えます。
完了報告には5項目を付ける
AIへ作業を頼むときは、完了報告に次の項目を含めるよう指示します。
作業名：
状態：完了 / 進行中 / 要確認 / 保留
変更したファイルまたはコミット：
確認したURLや画面：
確認日時：
未確認のことと次の一手：
「完了」とだけ書かれた報告は、後から検証できません。ファイル名、コミット、公開URL、確認日時があれば、別のAIや人間が追いかけられます。
「作成済み」と「公開済み」を分ける
アプリでは、コードを書いた状態と、利用者が公開URLで使える状態が異なります。記事でも、原稿を書いた状態と、公開ページを確認した状態は別です。
次のように状態を分けます。
- 作成済み：ファイルや原稿ができた
- 動作確認済み：決めた操作を実行できた
- 公開済み：公開URLを開いて確認した
- 発信済み：記事や動画を公開した
「作成済み」を「公開済み」と書き換えないことが重要です。状態が一段ずつ分かれていれば、次の担当が何を確認すべきか分かります。
監査AIには同じ報告を再利用させない
監査を頼むときは、前のAIの報告だけを貼って「問題ありませんか」と聞かないようにします。報告の内容を事実として受け継いでしまうからです。
代わりに、次のように依頼します。
前の報告は仮情報として扱ってください。
実ファイル、Gitの状態、公開URL、画面表示を確認し、
報告と一致する点、一致しない点、確認できない点を分けてください。
確認できないことは完了扱いにしないでください。
監査AIは、前の報告を要約する役ではありません。根拠と照合する役です。
判断待ちを「未完了」と混ぜない
作業が止まっている理由も分類します。
- AIだけで進められる：次の確認を実行する
- ユーザー判断待ち：公開、マージ、削除などの許可が必要
- 外部待ち：サービスの制限、返信、審査などを待つ
- 要確認：情報が古い、根拠が不足している
例えば、Zennの記事を作成済みでも、公開操作がユーザー待ちなら「記事公開済み」とは書きません。判断待ちを明示すると、作業が止まった理由を誤解しにくくなります。
原本を1つにして、更新日を書く
進捗表が複数の場所にある場合は、どれが正本かを決めます。各AIが別々のメモを更新すると、古い記録が最新情報に見えることがあります。
進捗表の先頭に、次の情報を置きます。
最終確認日：2026-10-12
正本：このファイル
確認した範囲：実装、公開URL、記事、未完了タスク
更新履歴は残しても、現在の状態と混ぜません。AIに過去の記録を読ませる場合は、「現在の表を優先し、履歴は経緯として使う」と伝えます。
発信する文章は確認済みだけにする
最後に、発信担当が記事を書くときは、確認済みの事実だけを使います。公開されていない予定、効果を測っていない成果、推測した原因は、事実のように書きません。
確認済み：公開URLが開き、ボタン操作を確認した
未確認：利用者が何人使ったか
予定：明日、動画を作る
この3つを分けるだけで、読者に誤った完成報告を伝える危険が減ります。
まとめ
複数のAIを使うときは、役割を分けるだけでなく、完了の根拠も分けて管理します。実装AIは作り、監査AIは実ファイルやURLと照合し、発信AIは確認済みの事実だけを文章にします。
担当、状態、出典、確認日、判断待ちを1つの原本に残せば、AIが増えても進捗を追いやすくなります。「報告された」ことと「確認できた」ことを分けるのが、安心してAIと協働するための基本です。