ChatGPT、Claude、Cursorなど、用途に応じて複数のAIを使い分けると、一人でも調査、執筆、開発を進めやすくなります。
ただし、使うAIを増やすだけでは仕事は整理されません。むしろ、それぞれのAIが別の前提を持ち、同じ質問に違う答えを返し、どれが最新なのか分からなくなることがあります。
私が複数のAIを使うときに最初に決めたのは、AIごとの高度なプロンプトではありませんでした。先に決めたのは、どの情報を原本として扱うかです。
この記事では、非エンジニアが複数のAIを使い始める前に、原本を1つにする理由と、無理なく続けるための小さな運用方法を紹介します。
AIが増えると、答えより先に前提が分かれる
たとえば、午前中にChatGPTと企画を考え、午後にCursorで実装し、夜に別のAIで説明文を作るとします。
それぞれのAIとの会話だけを見ると、作業は順調に進んでいるように見えます。しかし、次のようなずれが起こりやすくなります。
- 午前中に決めた対象読者が、午後の実装へ伝わっていない
- 実装中に変えた仕様が、夜の説明文へ反映されていない
- 採用しなかった案を、別のAIが決定事項として扱う
- 古いチャットを開き、すでに変更した内容で作業を再開する
- AIごとに違う「次にやること」が残る
問題は、どのAIが優秀かではありません。AIの外に、全員が確認できる現在地がないことです。
会話は考えるためには便利ですが、決定事項の保管場所として使うと、どの会話が最新かを人間が覚え続ける必要があります。作業が増えるほど、この記憶頼みの運用は苦しくなります。
原本は「いちばん賢いAI」ではなく「確認できる場所」
ここでいう原本は、すべての情報を保存する巨大なデータベースではありません。
最低限、次の内容を確認できる場所です。
目的：何のためのプロジェクトか
現在地：どこまで終わったか
決定事項：何を採用し、何を採用しなかったか
禁止事項：触らない範囲、公開しない情報
次の作業：再開するときの最初の一歩
私はローカルのMarkdownを中心にしています。Obsidianで読み書きでき、必要に応じてGitで変更履歴も確認できるからです。
ただし、大切なのはObsidianという製品名ではありません。テキストファイルでも、GitHub上の文書でも、チームで管理する別の仕組みでも構いません。
重要なのは、AIの回答ではなく、人間が確認して保存した記録を原本にすることです。
AIが新しい案を出しても、それだけでは決定事項にしません。人間が確認し、原本へ反映した時点で初めて、次の作業に使う前提になります。
最初から全部を共有しない
原本を作ると聞くと、過去の資料をすべて整理し、AIへ全部読ませたくなります。しかし、情報量を増やすほど正確になるとは限りません。
古い計画、却下した案、参考資料、現在の仕様を一度に渡すと、AIがそれらを同じ重要度で扱うことがあります。そこで、私は現在地を小さなファイルに分けます。
たとえば、次の4つです。
README.md プロジェクトの目的と入口
CURRENT_STATUS.md 現在地と完了したこと
DECISIONS.md 判断と理由
NEXT_ACTION.md 次に行う小さな作業
秘密情報や顧客情報は、AIへ共有する原本に混ぜません。APIキー、パスワード、個人情報、公開前の機密情報は別の安全な場所で管理します。
「何でも読めるようにする」のではなく、「この作業に必要な確認済み情報だけを読めるようにする」ことが、複数AI運用の出発点です。
AIへ依頼する前に、読む順番を固定する
原本を作っても、AIが毎回違うファイルから読み始めると判断が揺れます。私は、作業前に読む順番も決めます。
1. 目的を確認する
2. 現在地を確認する
3. 今回に関係する決定事項を確認する
4. 触ってはいけない範囲を確認する
5. 今回の依頼を実行する
AIへの依頼も、次のように短くできます。
README.md、CURRENT_STATUS.md、DECISIONS.mdの順に確認してください。
確認できた事実と提案を分けてください。
未確認の内容を補わないでください。
変更する範囲と、変更しない範囲を先に示してください。
作業後は、変更したファイルと確認結果をまとめてください。
この依頼で重要なのは、AIを細かく支配することではありません。作業を始める前に、共通の現在地へ戻すことです。
ChatGPTで企画するときも、Cursorでコードを直すときも、別のAIで文章を整えるときも、最初に同じ原本を確認します。役割は違っても、出発点を同じにします。
会話の内容をそのまま原本へコピーしない
AIとの会話には、採用した案だけでなく、途中の仮説や思いつきも含まれます。会話全文をそのまま原本へ入れると、決定事項と検討中の案が混ざります。
そこで、作業後に残す内容を3つへ分けます。
| 種類 | 残す内容 | 例 |
|---|---|---|
| 事実 | 実際に確認できたこと | ファイルを変更した、テストが通った |
| 判断 | 人間が採用した内容と理由 | 今回は機能を増やさない |
| 次の作業 | 再開地点 | 公開前にスマートフォン表示を確認する |
AIが「できました」と言っても、それだけでは事実にしません。ファイル、画面、公開URL、テスト結果など、作業に合った方法で人間が確認します。
確認できなかった内容は、完成済みとして原本へ書きません。「未確認」「保留」「次回確認」として残します。
この区別があると、別のAIが作業を引き継いでも、提案を実装済みと取り違えにくくなります。
更新する担当を曖昧にしない
原本を共有すると、今度は複数のAIが同時に書き換える問題が起こります。同じファイルを別々に更新すると、どちらを残すか判断が必要になります。
そのため、1回の作業では更新担当を1つにします。
調査するAI：候補と根拠を整理する
作業するAI：決めた範囲だけ変更する
レビューするAI：差分と矛盾を確認する
人間：採用を決め、原本の更新を承認する
複数のAIを使っても、同じ瞬間に全員へ同じファイルを自由に編集させる必要はありません。調査、作業、レビューを順番に分けるだけでも、衝突は減らせます。
また、原本を更新したら、更新日と変更理由を短く残します。長い日報を書く必要はありません。
2026-10-04
変更：複数AIの開始手順を追加
理由：作業ごとに参照する現在地がずれていたため
未確認：他の端末でも同じ手順を使えるか
この短い記録が、次のAIにとっての入口になります。
初心者は1つのプロジェクトから試す
最初から仕事全体の情報基盤を作る必要はありません。まずは、1つの小さなプロジェクトだけで試します。
- プロジェクト用のフォルダを作る
- 目的、現在地、禁止事項、次の作業を書く
- AIへそのファイルを先に読ませる
- 作業後に事実、判断、次の作業だけ更新する
- 翌日に別のAIでも同じ現在地から再開できるか試す
うまく引き継げなかった場合は、プロンプトを長くする前に、原本に足りない情報がないか確認します。
AIが間違えたときも、「もっと賢く答えて」と頼むだけでは再発を防ぎにくいものです。判断基準が原本にないなら追加し、古い情報が残っているなら整理します。改善する対象を、AIの性格ではなく共有情報の構造に置きます。
原本が役立っているかを確かめる3つの質問
原本を作ったあとも、文書が増えるだけで使われなければ意味がありません。私は定期的に次の3つを確認します。
- 初めて読むAIが、プロジェクトの目的を説明できるか
- 完了したことと、まだ実行していないことを区別できるか
- 次に変更してよい範囲と、触ってはいけない範囲を説明できるか
答えが曖昧なら、AIに推測させず、原本の文章を直します。たとえば「今後追加する」と「追加済み」が同じ段落にあるなら、現在と将来を別の見出しへ分けます。古い情報が必要なら履歴へ移し、現在地のファイルには今の判断だけを残します。
原本は一度完成させる成果物ではなく、作業を再開するための道具です。毎回きれいな文章にする必要はありません。日付、状態、根拠、次の一手が短く確認できるほうが役立ちます。
また、AIに原本の要約を作らせる場合も、その要約を新しい原本にはしません。要約はその時点の作業用メモとして扱い、判断を変えるときは元の記録へ戻ります。コピーを増やしすぎないことも、「どれが最新か分からない」を防ぐ運用の一部です。
まとめ
複数のAIを使うとき、最初に必要なのは複雑な連携ではありません。
- 原本を1つ決める
- 目的、現在地、判断、禁止事項、次の作業を残す
- AIへ読ませる順番を固定する
- 事実と提案を分ける
- 最後の採用と更新は人間が確認する
この5つだけでも、AIごとに前提が分かれる問題を減らせます。
AIは役割ごとに変えても、現在地は毎回同じ場所へ戻る。そうしておけば、新しいAIを試すときも、過去の経緯をすべて説明し直す必要がありません。
複数AIの仕組みを大きくする前に、まず1つのプロジェクトで「昨日とは別のAIが、同じ現在地から作業を再開できるか」を試してみてください。そこで詰まった場所が、次に原本へ追加すべき情報です。
この記事は、ローカルMarkdownを原本とし、AIごとの役割とHuman Approvalを分けてきた本プロジェクトの運用記録をもとに構成しました。特定のAIが常に正しいという前提ではなく、人間が確認した記録を作業の出発点にする方法を扱っています。