人間からAIへの指示は当然の話になった。しかしこれからの核心は逆方向だ ── AIが自律的に動き、人間にしかできない「最後の一歩」を頼む。その設計が、AIと人間の新しい分業を決める。十章で描く、指示の逆流の全構造
「AIに何をさせるか」から「AIに何を頼まれるか」へ ── 問いの重心が移動しつつある
AIへの指示の作法 ── プロンプトエンジニアリング ── はこの数年で急速に整備された。どう頼めばよいか、どう文脈を与えればよいか、どうロールを設定すればよいか。しかし今、別の問いが浮上しつつある。
AIが自律的に動き続けた後、人間に何かを頼む必要が生じたとき、それはどのような形を取るべきか。
夜中に走り続けたAIエージェントが朝5時にバグを発見した。修正候補を三つ用意した。しかし本番環境へのデプロイには人間の承認が必要だ。そのときAIは人間に何を伝え、どんな形で判断を促すか。あるいは、顧客からのクレームをAIが分類・処理し、最後の一件だけ「これは私が判断できません」と人間にエスカレーションする。そのとき、どんな情報をどんな形で渡せば、人間は正しく速く判断できるか。
AIが人間に指示・依頼・エスカレーションを行う局面 ── これを「AIから人間へのラストワンマイル」と呼ぶ。このラストワンマイルの設計が、AIシステムの実用性を左右する。どんなに高度なAIも、この最後の一マイルでつまずけば、人間の行動に繋がらない。繋がらなければ、現実は変わらない。
本書は、この逆方向の指示 ── AIから人間への指示 ── を設計するための地図だ。なぜその設計が難しいか。どこで詰まるか。どう解くか。Web制作・開発・サービス運用の文脈を軸にしながら、より広い含意まで描く。
そしてもう一つの命題を本書は持つ。AIが多くの作業を肩代わりするほど、人間に残る「私事（ひとごと）」 ── 個人の判断、身体、関係、権威、感情 ── の価値が相対的に高まる。この逆転の構造を、最後の章で描く。
「ラストワンマイル」とは物流用語だ。全行程の中で最も難しく、最もコストがかかる最後の区間。AIにおいても、同じ構造がある
宅配便の文脈でラストワンマイルとは、物流センターから顧客の玄関先までの区間を指す。幹線輸送はトラックの大量輸送で効率化できる。しかし最後の一マイルは、バラバラな住所に一軒一軒届けなければならない。自動化が最も難しく、コストが最も集中する区間だ。
AIにおけるラストワンマイルも、同じ構造を持つ。AIは大量の情報を処理し、判断し、コードを書き、文章を生成できる。しかし最後の一歩で、物理的な世界に接触したり、法的な権威を行使したり、人間関係の温度を伴った対話をしたりすることは、今のAIにはできない。その「最後の一歩」をいかに人間に渡すかが、ラストワンマイルの問題だ。
AIが届かない場所を五つに分類する。この分類が、後の章で設計の議論をするときの基盤になる。
ラストワンマイルに共通するのは、「その行為の結果が現実世界を直接変える」という性質だ。AIがコードを書いてもそれはデータに留まる。しかし人間がそれを承認してデプロイすると、現実のユーザの体験が変わる。人間がその契約書にサインすると、法律関係が生まれる。現実への接触がラストワンマイルの本質だ。
抽象論から降りて、Web制作と開発の現場でラストワンマイルがどこに現れるかを列挙する。
AIが人間に「頼む」とき、その頼み方の設計が、人間の行動の速さと正確さを決める
人間からAIへの指示（プロンプト）の設計には多くの知見が蓄積された。しかしその逆 ── AIから人間への指示・エスカレーション・ハンドオフ ── の設計はまだ体系化が進んでいない。にもかかわらず、これはシステムの実用性を決定的に左右する。
AIが人間に何かを伝えるとき、それは人間の注意という有限かつ高価なリソースを消費する。通知が多すぎれば無視される（通知疲れ）。情報が多すぎれば判断が遅れる（情報過負荷）。文脈が少なすぎれば間違いが増える（理解不足）。AIから人間への指示設計は、この三つの罠を同時に避けなければならない。
設計の基本原則は、人間が必要な行動を最短で取れるように構造化することだ。「何が起きたか」ではなく「あなたに何をしてほしいか」を最初に示す。背景情報はその後に続ける。「重要度がわからない通知の洪水」ではなく「今すぐ必要な行動が明示された依頼」を届ける。
第一層：アクション（何をしてほしいか）
「本番デプロイの承認が必要です」「この顧客に折り返し電話をしてください」
第二層：文脈（なぜ必要か・何が起きたか）
「自動テストは全件通過。ステージング環境で30分動作確認済み。変更は3ファイル」
第三層：詳細（詳しく知りたければ）
変更差分・ログ・関連チケット ── 読む必要があれば読める、読まなくても判断できる
AIが人間に作業を渡す（ハンドオフする）ときの設計原則を七つ定める。
AIが人間に通知・依頼するチャネルは、緊急度と文脈によって使い分ける。
全自動と全手動の間に、無数の設計パターンがある。どこに人間を介在させるかは、リスクとスピードのトレードオフだ
Human-in-the-loop（HIL）とは、AIの処理の一部に人間の判断や行動を組み込む設計パターンだ。この概念は機械学習の訓練（アノテーション）から来ているが、今はより広く、AIエージェントのワークフロー設計に使われる。
AIと人間の役割分担には、完全手動から完全自動まで連続したスペクトラムがある。どの段階に設定するかは、タスクのリスク・信頼度・速度要件・コストによって決める。
どの段階を選ぶかは、「間違えたときのコスト」と「AIの信頼度」の二軸で決める。間違えたときのコストが高い（本番サービスへの影響・金銭的損失・法的リスク）ほど、人間介在を増やす。AIの信頼度が高い（十分な検証済み・実績あり）ほど、自動化を進める。この二軸の交差点が、適切な段階だ。
具体的なタスクとその推奨段階を示す。
最初は高い段階（より人間介在）から始め、実績とともに段階を下げていく。これが安全なAI自動化の進め方だ。
段階を下げる判断基準の例：「過去30回のデプロイで、人間が承認を却下したのは0回だった」「カスタマーサポートのAI一次回答に対するユーザ満足度が、人間対応と同等だった」「自動スケーリングが3ヶ月間、人間の介入なしに正常動作した」── このような実績の蓄積をもって、段階を一つ下げる。勘ではなく記録に基づいて自動化を広げる。
人間が寝ている8時間を、AIは働ける。朝の「AIからの報告」をどう設計するかが、非同期エージェントの核心だ
Claude CodeのScheduled Agentsや、GitHub ActionsのCronジョブ、さまざまなワークフロー自動化ツールが成熟した2026年、非同期エージェントというパターンが実用段階に入った。人間が離席している間にAIが複数の作業を並列で進め、完了したとき ── または問題が生じたとき ── に人間へ報告する。
非同期エージェントの最も自然なメタファーは、熟練した秘書が夜中に処理を進め、翌朝に要点をまとめて提出するモデルだ。良い秘書は「どんな細かいことでも報告する」のではなく「あなたが判断すべきことだけを整理して提出する」。このふるまいをAIエージェントに設計する。
朝のレポートが優れているとは：人間が5分でレポートを読んで、その日の判断と行動が確定できることだ。「読んで何もしなくていい」情報と「読んで今日中に行動が必要」な情報が明確に分かれている。優先度が一目でわかる。承認が必要なものには、承認のワンクリックが用意されている。
【今日のアクション必要事項】（3件以内に絞る）
→ 本番デプロイの承認：ステージング24時間正常稼働。差分3ファイル。[承認] [詳細を見る]
【昨夜の処理結果】（完了した自律作業のサマリー）
→ バグ修正7件完了 / テスト全件通過 / パフォーマンス改善: LCP 2.1s→1.7s
【注意が必要な状況】（緊急ではないが把握しておくべき）
→ エラー率が昨日比+0.3%。原因は特定済み（外部APIの不安定）。監視継続中。
【参考情報】（読まなくてもよい）
→ 今週のトラフィックレポート / 依存ライブラリの更新履歴
Claude Codeの自律ループ（Scheduled Agentsや継続的タスク）を使う場合、エージェントが完了時に出力するレポートの形式を、最初に定義しておく。
CLAUDE.mdに「作業完了時は必ず以下の形式で報告すること：①完了したこと（箇条書き）、②問題が生じて対処できなかったこと（理由付き）、③人間の判断・行動が必要なこと（優先順に3件以内）、④次回のセッションで注意すべきこと」と明記する。これで、AIが自律的に動いた後の報告が自動的に一定の形式を取るようになる。
非同期エージェントが人間の就寝・離席中に動いているとき、緊急の問題が生じた場合の割り込みトリガーを設計する。「起きたら報告」ではなく「即座に起こす」べき条件と、「朝まで待つ」でよい条件を、あらかじめ定義する。
信じすぎれば盲信。信じなければ使えない。AIへの信頼は「適切に校正」するものだ
AIが「この対応で問題ありません」と言うとき、人間はどの程度信じるべきか。AIが「このコードは安全です」と言うとき、どの程度検証が必要か。この問いへの答えは、「常に信じる」でも「常に疑う」でもない。適切に校正することだ。
AIへの信頼を「なんとなく信頼できる感じがする」という感情で設定するのは危険だ。AIは自信を持って間違えることができる。流暢な文章、確信に満ちたトーン、論理的に見える構造 ── これらは正しさの証拠ではない。
信頼は記録に基づいて設定する。「過去100回の判断のうち、何回正しかったか」「どのカテゴリの判断で間違えやすいか」「どの条件下で信頼度が下がるか」── これらを実績として記録し、その記録に基づいてどこまで委ねるかを決める。これを信頼の校正（calibration）と呼ぶ。
過剰な信頼（盲信）のコスト：AIの誤りを見逃す。本番でバグが出る。セキュリティホールを見落とす。間違った判断を実行に移す。
過小な信頼（不信）のコスト：AIを使う意味が失われる。全出力を手作業で検証する時間が発生する。自動化の恩恵がゼロになる。
適切な校正：「このタスクでは信頼する・このタスクでは検証する」を記録に基づいて決め、そこから外れない。
全てのタスクに同じ信頼水準を適用するのではなく、タスクの種類ごとに信頼水準を設定する。以下は一例だ。
AIが判断を示したとき、その判断だけでなく判断根拠を説明させる習慣を持つ。「このコードは安全です」ではなく「このコードが安全だと判断した根拠を、見落としやすいリスクとともに説明してください」と追加で問う。説明を読んで「確かにその根拠は妥当だ」と自分が判断できれば、信頼する。説明に見落としがあれば、追加検証する。
この習慣は二つの効果を持つ。第一に、AIが根拠を示せない場合（根拠が薄い場合）に早期に発見できる。第二に、人間が根拠を理解することで、次回同じ判断が必要なときに自分でできるようになる。AIへの委譲が、人間の無知化ではなく、人間の学習になる。
AIから人間への指示が届く「画面」のUXは、これまでほとんど語られてこなかった。しかしここが、システム全体の速度と正確さを決める
AIから人間への指示が届く場所 ── 承認画面、レポートダッシュボード、エスカレーション通知 ── のUX設計は、AIシステム全体の実用性に直結する。どんなに高度な自律AIも、人間への提示が分かりにくければ、正しい行動に繋がらない。
AIから人間への提示UIは、従来のダッシュボード設計とは目的が異なる。ダッシュボードは「状況を把握するための画面」だが、ラストワンマイルUIは「判断して行動するための画面」だ。この違いが設計をまったく変える。
判断を助ける画面の原則。何を決めるべきかが最初に見える。判断に必要な情報が揃っている（多すぎない）。行動の選択肢が明示されている。取り消しが可能かが示されている。急ぐ必要があるかが伝わる。これら五点が一画面に収まっていれば、人間は迷わず判断できる。
① 件名：「本番デプロイの承認」（何についての判断か）
② AIの提案：「今すぐデプロイを実行することを推奨します」
③ 根拠：テスト全件通過・ステージング24h正常・変更3ファイル（差分リンク）
④ リスク情報：「変更対象：ログイン画面。影響ユーザ：全ユーザ。ロールバック：可能（5分）」
⑤ アクションボタン：[今すぐ承認] [1時間後に実行] [却下] [詳細を見る]
⑥ 期限：「この承認は24時間有効です」
AIがカスタマーサポートを処理し、対応できないケースを人間にエスカレーションするとき、エスカレーション画面に含めるべき要素がある。
複数のAIエージェントが並列で動くシステムでは、人間への依頼が複数チャネルから届き、認知的な混乱を生む。この解決策が「決定のインボックス」パターンだ。
全てのAIからの承認依頼・エスカレーション・報告が、一つの画面に集約される。優先順位順に並び、人間はトップから順番に処理する。処理済みは消える。未処理は残る。メールのインボックスに似た体験だが、「読む」ではなく「判断する」に特化している。これにより、AIが多数動作している環境でも、人間の注意が分散しない。
技術の進歩がどれだけ速くても、この三つの障壁はAIが乗り越えられない。ここが人間の専売特許であり続ける
「AIに何でもできる」という言説が広がる一方で、構造的にAIが届かない領域がある。それは技術的な限界ではなく、社会・法・生物学的な構造が作る障壁だ。この障壁は、AIが強くなっても消えない。
長年の取引先と築いた関係は、過去のメールログの総体ではない。「あのとき無理を聞いてくれた」「一緒に失敗した経験がある」「子どもが同い年だ」── こういう積み重ねが、信頼の実体だ。AIはメールログを読んで「この顧客との関係は良好です」と分析できる。しかしその関係が生んできた温度は、AIには再現できない。
ラストワンマイルの中で最も重要な局面 ── 謝罪、感謝、重要な依頼の最初の一声 ── は、この関係の温度が機能する局面だ。AIが作った完璧な謝罪文より、不完全でも生身の声の方が届くことがある。それは文章の質の問題ではなく、誰が言うかの問題だからだ。
「私が決定します」という行為は、その人物の地位・役割・法的な立場に紐付いている。AIがCEOの代理として「この契約を締結します」と言うことはできない。代表取締役が電子署名を押す行為は、代表取締役としての権威の行使だ。その権威はAIに委譲できない。
これは現在の法制度の制約という面もあるが、より根本的には責任の所在の問題だ。何かが間違ったとき、誰が責任を取るか。AIに責任を取らせることは、今の社会制度では不可能だ。だから、権威を要する行為は常に人間が行う。AIはその行為の準備を最大化し、人間が判断と実行に集中できるようにするだけだ。
AIはネットワークの内側にいる。物理的な世界への接触は、ロボティクスの領域に入る。Webの世界においても、「顧客のオフィスに出向いて会議をする」「展示会のブースに立つ」「工場の現場を見て課題を掴む」── 身体を持つことが要件になる行為は、今もこれからも人間のものだ。そしてこれらの行為が、しばしばビジネスにおいて最も重要な接触点になる。
関係・権威・身体が必要な局面においては、「AIが準備する」と「人間が実行する」をセットで設計する。これが最も実用的なアプローチだ。
AIが人間に依頼し、人間が行動する。その結果をAIに返さなければ、ループは一方通行で終わる
ラストワンマイルの設計で最も見落とされるのが、人間の行動結果をAIに戻すフィードバックループだ。AIが承認を求め、人間が承認する。それで終わり ── この設計では、AIは「自分の判断が正しかったか」を学べない。次回同じ判断を繰り返すか、人間が毎回同じ補正を手作業で行うかのどちらかになる。
AIエージェントを「一回ごとに完結する道具」として設計するのか、「経験を蓄積して精度が上がる協働者」として設計するのかで、システムの長期的な価値が大きく変わる。後者を目指すなら、フィードバックループは最初から設計に織り込む必要がある。
フィードバックは形式的に設計するほど効果が高い。「なんとなく次回に活かす」ではなく、「人間が却下した理由をAIがログに記録し、同じカテゴリの判断に反映する」という具体的なメカニズムを持つ。
即時フィードバック：人間が承認/却下した直後に、理由を一言入力する。「理由：ステージングのテスト期間が短すぎる」。AIは次の承認依頼時に「前回却下された理由：テスト期間」を考慮する。
事後フィードバック：デプロイ後24時間の問題有無・顧客対応の最終結果・判断の成否 ── 行動の結果が出た後にAIに報告する。
定期振り返り：週次または月次で「AIの判断の正解率・人間が補正したパターン・改善すべき判断基準」を振り返り、CLAUDE.mdやシステムプロンプトを更新する。
人間がAIの提案を却下したとき、その理由は次回の判断に最も価値あるデータだ。却下理由を自由記述ではなく、分類可能な形で記録する。
フィードバックの蓄積を、CLAUDE.mdの更新という形でAIの行動に反映する。週次の振り返りで「先週、AIが人間に補正を求めた判断のパターン」を分析し、「このカテゴリは○○の条件下では人間に確認を取ること」という行動指針を追記する。
CLAUDE.mdは初期設定のままにしない。プロジェクトが進むにつれて、実際の経験から学んだ判断基準が蓄積されるドキュメントとして育てる。これがAIの「学習」を、モデルの再訓練なしに実現する実用的な方法だ。
AIが作業の大半を担うようになったとき、人間に残る「私事（ひとごと）」が、最も高価な希少資源になる
経済学の基本原理に希少性の法則がある。供給が増えるほど価値が下がり、希少になるほど価値が上がる。AIが大量のコンテンツ・コード・分析・提案を生成するようになった世界で、この法則はある逆転をもたらす。
AIによって大量生産されるようになったものの価値は、相対的に下がる。一般的なブログ記事、標準的なコードのスニペット、汎用的なマーケティングコピー ── これらは以前は希少であり価値があった。今、これらはコモディティになりつつある。
逆に、AIが生産できないものの価値は相対的に上がる。固有の経験に基づく洞察。特定の人物との関係。その場に居合わせた身体的な記憶。長年の実践から来る判断。これらは複製できない。AIが出力できない。だから、希少性を保ち続ける。
価値が下がるもの（AIが大量生産できる）
一般的な情報記事 / 標準的なWebデザイン / 汎用コードのテンプレート / 定型的なプレゼン資料 / 一般的なSEO対策
価値が上がるもの（AIが生産できない）
固有の経験・失敗・成功の語り / 特定の人物との長年の関係 / 現場を見た感覚 / 判断の責任を取る意志 / 特定の文化・コミュニティへの深い帰属 / 顔が見える誠実さ
ここで「私事（ひとごと）」という言葉を使う。個人にしか語れない出来事、個人にしかできない経験、個人の歴史に紐付いた固有性 ── それが「私事」だ。かつてビジネスの文脈で「私事を持ち込まない」という規範があった。プロフェッショナリズムは、個人の私事から距離を置くことを意味した。
しかし、AIがコモディティな情報を大量に生産する時代に、私事こそが差別化の源泉になる。「私はこの業界で15年働き、3回失敗し、ようやく○○に気づいた」という語りは、AIには生成できない。それは生きた経験であり、特定の身体と歴史に紐付いている。これが、信頼とコンテンツの希少性を作る。
Webサイト・ブログ・プロダクトにおいて、「私事」をどう戦略的に組み込むか。
人間→AIの一方通行から、AI⇄人間の双方向へ。これが次の5年で起きる分業の再編だ
本書を通じて描いてきた構造を、一枚の地図に統合する。AIと人間の分業は、今まさに再編の途上にある。その地図を持つことで、設計の判断が速くなり、間違いが減る。
第一世代（〜2022年）── 道具の時代：AIは特定のタスクに特化した道具だった。翻訳ツール、画像認識API、レコメンデーションエンジン。人間が全体を制御し、AIは部分を担う。指示は常に人間→AIだった。
第二世代（2023〜2025年）── アシスタントの時代：LLMの普及で、AIが汎用的なアシスタントになった。「これをやって」と言えば、ある程度できる。プロンプトエンジニアリングが重要なスキルになった。指示は人間→AIが主だが、AIが次のアクションを「提案」するケースが増えた。
第三世代（2026年〜）── 協働者の時代：AIエージェントが自律的に動き、自ら判断し、人間が必要なときだけ介在を求める。人間→AIとAI→人間の両方の指示が常態化する。分業の境界は固定ではなく、タスクの性質・リスク・信頼度によって動的に変わる。
人間が担う：目的の設定 / 価値観の定義 / 最終判断 / 関係・権威・身体を要する行為 / 結果の責任 / フィードバックの入力 / 私事の語り
AIが担う：情報収集・分析 / 選択肢の生成 / ルーティン作業の実行 / エラーの検知 / 報告の作成 / 次のアクションの提案 / 記録の管理
共同で担う：判断基準の設計 / リスク評価 / 品質の確認 / フィードバックループの運用
この分業の地図をWeb制作・開発の現場に落とすと、以下のような設計になる。
双方向の指示設計を持つチームや個人は、片方向しか設計していない競合より速く動ける。人間→AIの指示だけが上手くても、AIが何かを発見したときに人間への伝達がうまくいかなければ、発見が行動に繋がらない。AI→人間の伝達設計が整ったとき、AIの自律作業が初めて実際の価値に変換される。
本書で描いてきたことは、技術の話ではなかった。人間とAIの協働の形を設計するという、組織設計に近い問いだった。その設計ができる人間が、これからの5年間でもっとも大きな生産性の恩恵を受ける。
かつて問いは「AIをどう使うか」だった。これからの問いは「AIに頼まれたとき、何を返せるか」だ
AIが広く普及した世界で、人間の価値は「何がAIより速くできるか」によって決まらなくなる。AIは多くの作業で人間より速い。これは変わらない。
人間の価値はむしろ、AIが頼んでくるときに、どんな質の応答を返せるかによって決まるようになる。承認を求められたとき、深く理解した上で判断できるか。エスカレーションを受けたとき、顧客と誠実に向き合えるか。「私はここで判断できません」とAIが言ったとき、その判断を引き受けられるか。
① 理解する力：AIが提示した情報・根拠・選択肢を、正しく理解する能力。情報を受け取るだけでなく、解釈できること。
② 判断する意志：AIに委ねず、自分で決めることを引き受ける姿勢。「AIが言ったから」を理由にしない覚悟。
③ 行動できる身体と関係：理解して判断したことを、物理的・関係的に実行する手段を持つこと。ネットワークの外に、自分の身体と人間関係があること。
AIが強くなるほど、ラストワンマイルの重要性は上がる。AIが9割を担えば、人間の1割の行動が全体の価値を決める。その1割が精確であることは、以前の9割と同じくらい重要だ。
本書を閉じるにあたって、一つの問いを置いていく。あなたがAIに頼まれたとき、何を返せるか。 その答えを育てることが、これからの時代の、人間としての仕事ではないかと思う。
さらに深く学ぶための地図