AIに仕事を渡す設計｜指示・状態・データ・権限・引き継ぎをどう組み立てるか
AIを仕事で使い始めた頃、僕が考えていたのは「どのAIを使うか」でした。
通常Chatで考えるのか。Workへ実作業を渡すのか。dotへ継続作業を任せるのか。複数AIで反証するのか。
その使い分けを整理したのが、上位の記事「AIを仕事で使う｜Chat・Work・dot・複数AIをどう分けるか」です。
ところが実際に仕事を渡す量が増えると、次の問題が出てきました。
どのAIを使うかが決まっても、それだけでは仕事は続かない。
何を指示として残すか。どこまでをAIへ任せるか。今どこまで終わったかをどう残すか。必要なデータだけをどう渡すか。別のAIへどう引き継ぐか。どんな権限を与え、どこで止めるか。
海辺の部屋で実際に試した記事が増え、2026年10月には、この問いに関係する記事が10本になりました。
そこで10本を改めて読み直すと、「AI仕事設計」という一つのSeriesとして見る方が、個別記事を並べるより全体像が分かりやすいと判断しました。
「どのAIを使うか」と「どう仕事を渡すか」は別の問い
上位Hubでは、Chat、Work、dot、複数AIを、考える・実行する・継続する・反証するといった役割で分けています。
このSeriesで扱うのは、その次です。
担当を決めたあと、そのAIが迷わず仕事を続けられるように、仕事の側をどう設計するか。
僕が実運用でつまずいたのは、AIの性能不足だけではありませんでした。資料はあるのに読めない。別スレッドでは現在地が消える。API結果を返しすぎて扱えない。短い変更指示が別の処理まで巻き込む。Skillをコピーしても権限までは移らない。
こうした問題は、モデル名を変えるだけでは解けません。仕事の入口、状態、データ、権限、完了条件を分けて設計する必要がありました。
1．誰に何を任せ、人間はどこで戻るか
最初の問いは、AIへどこまで任せるかです。
一つのAIを万能にせず、調査、反証、構造化、表現などの役割を分け、最後は人間が統合する考え方です。
AIの自律性を「勝手に動く能力」ではなく、人間がどこまで動いてよい範囲を設計したかとして捉えています。
企業全体へ広げると、モデル選択より、仕事・基盤・権限・停止をどこへ配置するかが重要になります。
AIへ仕事を渡す最初の設計は、「AIに何ができるか」ではなく「この仕事のどこを任せるか」です。
2．仕事を止めずに続けるには、何を状態として残すか
AIと長い仕事をすると、会話が変わるだけで現在地が消えることがあります。
短い合図で次工程へ進めるのは、ゴール、工程、人間が戻る地点を先に共有しているからです。
TARGET、STATE、DONE、FAILED、UNKNOWN、NEXTなど、成果物ではなく『再開地点』を残す方法を扱っています。
思いついた瞬間に完成したタスクへせず、元の言葉を共通INBOXへ逃がし、後からAIが整理する入口を作りました。
元発言とAIの解釈を分けることで、正しい最新版だけでなく、誤解→訂正→現在値の経緯も残せるようにしました。
AIが長く働くほど、記憶量より「どこから現在地へ戻れるか」が重要になります。
3．AIへ何を渡し、何を渡さないか
状態を残しても、AIへ渡す情報が多すぎれば別の問題が起きます。
APIから取得できる項目を全部返すのではなく、次に何を判断するかを先に決め、必要な件数とフィールドを絞る考え方です。
手順はSKILL.mdへ外出ししやすい一方、現在データ、接続先、実行権限、検証基準は別の場所に残ることを確認しました。
AIへ渡す情報は、多ければ多いほどよいのではありません。手順、現在値、実行環境を分けた方が再利用しやすくなります。
4．どこまで動かし、どう止めるか
仕事をAIへ渡す範囲が広がるほど、最後に残るのが権限と停止です。
読む・書く・実行する・外部へ接続する権限をどう分けるか。異常をどう監視し、誰が停止し、事故後にどう追跡するかを扱っています。
これは『AIを信用するか、しないか』という話ではありません。仕事に必要な自由は渡し、不要な自由は渡さず、越えてはいけない境界を実装する話です。
AI仕事設計の最後は、能力ではなく責任の境界へ戻ります。
10本だから親を作ったのではない
同じSeriesの記事が10本になったことは、見直すきっかけでした。でも「10本になったら必ず親記事を作る」というルールにはしていません。
今回親が必要だと判断したのは、10本が同じ大きな問いへつながっている一方、上位Hubだけでは『仕事を渡したあとの設計』を一覧できなくなったからです。
上位Hubは、どのAI・役割を使うかを見る入口。このSeries親は、AIへ仕事を渡すときの指示・状態・データ・権限・引き継ぎを見る入口。役割を分けます。
そして、この10本をさらに別Seriesへ分割するのはまだ早いと判断しました。4つの読み筋はありますが、一つの親から十分に見渡せます。
記事数ではなく、読者が一つの入口で全体像をつかめるかを基準に構造を変えます。
AI仕事設計は、完成した方法論ではなく実験の地図
ここにある10本は、最初から一つの理論として設計したものではありません。
Workを長く動かして詰まった。別スレッドへ移ったら状態が足りなかった。API結果を返しすぎた。自動化の範囲を誤解した。Skillを作ったら権限は別に残った。
実際の仕事で起きた問題を一つずつ直していった結果、後から『同じ仕事設計の問題だった』とつながってきました。
だから今後、新しいAIや機能が出ても、このSeriesでは製品名より、
誰に何を任せるか。何を状態として残すか。何を渡すか。どこまで動かし、どう止めるか。
を見ます。
新しい記事が増えて、この親だけでは全体を見渡せなくなったときに、初めて子Seriesへの分割を考えます。
コメント