ページ作成日時：2026-06-25 22:40 JST
最終更新日時：2026-06-25 22:40 JST
はじめに
平易版では、AIとの共同作業の失敗を、単なる能力不足ではなく、作業環境の設計ミスとして捉えた。詳解版では、この見方を、ワークフロー設計（workflow design）、状態管理（state management）、人間参加型（human-in-the-loop）、監査可能性（auditability）、検証ループ（verification loop）の観点から整理する。
生成AIを使うとき、私たちはしばしば「どう聞けばよいか」だけを考える。しかし、長い作業、外部ツール、Notion整理、GitHub更新、メール文面作成、会計データ確認、記事公開のような作業では、プロンプト一発の問題ではなくなる。重要なのは、AIに何を任せ、人間が何を決め、どこに状態を保存し、どの段階で検証し、どの条件で止めるかである。
AIとの共同作業は、会話ではなくワークフローとして設計する必要がある。
1. AIとの共同作業は、会話ではなく作業系である
ChatGPTの画面は会話の形をしている。そのため、私たちはAIとのやりとりを、人間同士の会話の延長として見やすい。しかし、実際にAIを仕事に使うと、そこには複数の作業段階がある。
資料を読む。要点を抽出する。構成を作る。文体を整える。Notionに転記する。GitHubに反映する。メール文面を作る。送信前に確認する。結果を記録する。次回の作業に引き継ぐ。これは、単なる会話ではない。作業の流れである。
したがって、AIとの共同作業を安定させるには、会話のうまさだけでなく、作業系の設計が必要になる。問いは、「どう聞けばよいか」だけではない。「どこから始めるか」「どこまで任せるか」「何を根拠にするか」「どこで確認するか」「失敗したらどう止めるか」である。
2. 作業を分解する
生成AIとの作業で失敗しやすい原因の一つは、一つの依頼に複数の作業を詰め込みすぎることである。
たとえば、「この資料を読んで、重要点を整理して、Notionに転記して、Web記事用に整えて、GitHubにも反映して」と頼むとする。人間には自然に見える。しかし、AIの実行環境から見ると、読解、抽出、編集、Notion作成、Web向け整形、GitHub操作という別々の作業が混ざっている。
これを一度に行うと、途中で前提が混線しやすい。出力形式が崩れる。ツールの実行順序が曖昧になる。人間の確認が必要なところを飛ばす。作業途中の失敗を回収できなくなる。
だから、AIとの共同作業では、タスクを分解する必要がある。読解、判断、編集、書き込み、検証、記録を分ける。AIに任せる段階と、人間が確認する段階を分ける。読み取り系のツールと書き込み系のツールを分ける。
作業分解とは、AIのためだけではなく、人間が責任を持つための設計でもある。
3. 状態管理が必要になる
長い作業では、状態が重要になる。ここでいう状態（state）とは、作業がどこまで進んでいるか、何が決まっているか、何が未決か、どの資料を正とするか、どのページが作成済みか、どの変更が反映済みか、といった情報である。
AIとのやりとりだけに状態を閉じ込めると、長期作業は不安定になる。会話が長くなると、古い前提が埋もれる。途中で別の話題が入る。別チャットに移る。ツール実行が失敗する。作業の現在地が分からなくなる。
そのため、状態は外部に明示的に置いた方がよい。Notionの進行管理ページ、GitHub Issue、README、AGENTS.md、作業ログ、更新履歴などがその役割を持つ。AIの会話文脈だけに頼らず、外部の作業台に状態を残す。
OpenAIのAPIでも、会話状態を自動で管理する方法や、過去の応答とつなげる方法が用意されている。しかし、実務上は、どの状態を会話内に残し、どの状態を外部のソース・オブ・トゥルースとして管理するかを設計する必要がある。
4. ソース・オブ・トゥルースを決める
AIとの作業では、何を正とするかを決めなければならない。これをソース・オブ・トゥルース（source of truth）と呼ぶ。
たとえば、記事の最新版はNotionなのか、GitHubのHTMLなのか、ローカルファイルなのか。会計データの正本は税理士作成資料なのか、freeeなのか、取引所CSVなのか。業務メール文面の正本は前回送信メールなのか、社内テンプレートなのか、ユーザーの最新指示なのか。
ソース・オブ・トゥルースが曖昧だと、AIはもっとも目立つ情報を正として扱いやすい。直近で貼ったメモ、古い下書き、検索結果、前回の応答、ツールから返ってきた断片が、知らないうちに基準になってしまう。
だから、実務では明示する必要がある。「この作業では、NotionページAを正とする」「GitHub側は公開反映先であり、本文判断の正本ではない」「取引所CSVを原本とし、freee入力済み仕訳は照合対象とする」。このように、どの情報を根拠にするかを明示すれば、AIの判断は安定しやすくなる。
5. 人間参加型の確認点を置く
AIにすべてを自動で任せるほど、作業は速くなる。しかし、誤った方向へ速く進む危険も増える。そこで重要になるのが、人間参加型（human-in-the-loop）の確認点である。
人間が確認すべきポイントは、作業によって違う。文章なら、意味の変更、公開可否、文体、固有名詞、引用、タイトル。会計なら、期首残高、分類、計算方法、異常値、提出前の確認事項。メールなら、宛先、件名、敬称、送信可否。NotionやGitHubなら、既存ページの上書き、公開反映、リンク構造。
AIに「必要なら確認して」とだけ言うと、確認点が曖昧になる。むしろ、どの操作は確認なしで進めてよいか、どの操作は必ず止めるかを先に決める必要がある。読み取り、要約、下書き作成は進めてよい。しかし、送信、既存ページ上書き、公開反映、確定処理は確認が必要。このように境界を引くことで、AIは行動しやすくなり、人間も責任を持ちやすくなる。
6. 書き込み系ツールには停止条件が必要である
外部ツールを使うAIでは、停止条件が重要になる。特に、書き込み系ツールを使う場合は、止まる条件を書いておく必要がある。
たとえば、対象ページが一意に特定できない。既存ページを上書きする可能性がある。ユーザーが禁止したツールを使わないと実行できない。送信先が不明である。ファイル名が似ていて取り違える可能性がある。ツール実行が途中で失敗した。こうした場合は、作業を進めるより止まる方が安全である。
停止条件がないAIは、曖昧さを推測で埋めようとする。これは、文章生成では便利なこともある。しかし、外部世界を書き換える作業では危険である。
したがって、AGENTS.md、CHATGPT.md、プロジェクト指示、ツール利用ポリシーには、何をするかだけでなく、何をしないか、どこで止まるかを書く必要がある。
7. 監査可能性を残す
AIとの作業では、あとから何が行われたかを確認できることが重要である。これを監査可能性（auditability）と呼ぶ。
監査可能性がないと、作業は不安になる。どの資料を読んだのか。どのページを更新したのか。どのファイルを作ったのか。どの判断をAIが行い、どこを人間が確認したのか。ツール実行が失敗したとき、どこまで進んでいたのか。
Notionの更新履歴、GitHubのコミットログ、メール下書き、作業メモ、実行ログ、引用リンク、検算表などは、AIとの共同作業における監査可能性を支える。
特に、長期プロジェクトでは、更新履歴が重要である。ページ作成日時、最終更新日時、何を変更したか、なぜ変更したか。これらが残っていれば、AIとの作業は再開しやすい。残っていなければ、AIも人間も現在地を失いやすい。
8. 検証ループを作る
AIとの作業を安定させるには、最初から完璧な指示を書くより、検証ループを作る方がよい。検証ループとは、出力し、確認し、修正し、再確認する流れである。
たとえば、記事作成なら、構成、本文、タイトル、要約、公開用HTML、リンク確認のように段階を分ける。会計データなら、原データ標準化、分類、計算、残高照合、異常値抽出、確認事項、提出用Excelのように段階を分ける。ソフトウェアなら、編集、テスト、差分確認、レビュー、デプロイのように段階を分ける。
OpenAIのエージェント評価では、トレースや評価基準を使って、エージェントが正しいツールを選んだか、指示に反していないか、変更によって改善したかを確認する考え方が示されている。通常のChatGPT運用でも、これは応用できる。
つまり、AIとの共同作業では、「良い答えを一回で出す」より、「悪い答えを検出して修正できる流れ」を作る方が重要である。
9. AIの役割を段階ごとに切り替える
ワークフロー設計では、AIの役割を固定しすぎないことも大事である。AIは、執筆者にもなる。編集者にもなる。検索者にもなる。検算者にもなる。秘書にもなる。コード修正者にもなる。議論相手にもなる。
しかし、一つの作業の中で役割が頻繁に変わると、文脈が混線する。たとえば、AIに「批判的に読んで」と言った直後に「このままNotionに転記して」と言うと、批評者としての姿勢と作業者としての姿勢が混ざることがある。
そのため、フェーズごとに役割を切り替えるとよい。今は読者として読む。次に編集者として直す。次に作業者として転記する。最後に検査者として確認する。このように役割を段階化すると、AIの応答は安定しやすい。
AIに人格を与えるより、作業上の役割を与える。これが実務では効く。
10. 外部記憶を設計する
AIとの長期作業では、外部記憶を設計する必要がある。ここでいう外部記憶とは、Notion、GitHub、Google Drive、スプレッドシート、README、AGENTS.md、作業ログ、更新履歴など、人間とAIが共同で参照できる記録である。
AIの会話文脈は流れる。長くなれば圧縮される。別チャットに移れば引き継ぎが必要になる。だから、重要な状態は会話の中だけに置かない方がよい。
外部記憶には、役割がある。事実の保存。決定事項の保存。未決事項の保存。作業手順の保存。失敗例の保存。次回の再開条件の保存。これらが整っていると、AIとの作業は継続しやすくなる。
ただし、外部記憶も増えすぎると混乱する。どこが正本なのか、どれが古いのか、どれを参照すべきなのかが分からなくなる。だから、外部記憶には階層が必要である。正本、作業メモ、ログ、参考資料を分ける。最新ページと過去ログを分ける。
外部記憶を設計することは、AIのためだけではない。人間が現実の作業に戻るための足場でもある。
11. 平易版の結論を詳解版として言い換える
平易版では、こう言った。AIとの失敗は、能力不足だけでなく、作業環境の設計ミスとして起きる。
詳解版では、これを次のように言い換えたい。AIとの共同作業を設計するとは、目的、状態、権限、確認点、停止条件、外部記憶、検証ループを設計することである。
この見方を持つと、AIとの失敗を単なる「プロンプトが悪かった」「モデルが弱かった」だけで片づけなくなる。もちろん、モデルの限界はある。しかし、作業の失敗の多くは、目的が曖昧だった、状態が外部化されていなかった、正本が決まっていなかった、確認点がなかった、停止条件がなかった、検証ループがなかった、という形でも起きる。
生成AIを使う力とは、単にうまい指示文を書く力ではない。AIが応答し、ツールを使い、人間が確認し、記録が残り、必要なところで止まれる作業環境を作る力である。
中心フレーズ
AIとの共同作業を設計するとは、誰が何を記憶し、何を確認し、どこで止めるかを決めることである。
用語メモ
ワークフロー設計（workflow design）
作業を複数の段階に分け、順序、役割、確認点、成果物を設計すること。
状態（state）
作業がどこまで進んでいるか、何が決まっているか、何が未決かといった現在地の情報。
状態管理（state management）
作業状態を会話内外で保持し、次の作業に使えるようにすること。
ソース・オブ・トゥルース（source of truth）
その作業で正本として扱う情報源。
人間参加型（human-in-the-loop）
AIの作業過程に人間の確認や判断を組み込む設計。
停止条件（stop conditions）
不明点、危険な操作、権限不足、ツール失敗などが発生したとき、作業を続行せず止める条件。
監査可能性（auditability）
あとから、何を根拠に、どの操作が行われたかを確認できること。
検証ループ（verification loop）
出力、確認、修正、再確認を繰り返して品質を上げる流れ。
外部記憶
Notion、GitHub、Google Drive、作業ログ、README、AGENTS.mdなど、人間とAIが共同で参照できる記録。
参考リンク
- OpenAI Platform｜Conversation state：https://developers.openai.com/api/docs/guides/conversation-state
- OpenAI Platform｜Agents SDK：https://developers.openai.com/api/docs/guides/agents
- OpenAI Platform｜Evaluate agent workflows：https://developers.openai.com/api/docs/guides/agent-evals
- OpenAI Platform｜Using tools：https://developers.openai.com/api/docs/guides/tools