AIが文章を答えるだけでなく、ファイルを扱い、複数の手順を進めるようになると、経営者の仕事にも変化が生まれます。増えるのは、何を完成させ、どこまでの操作を任せるかを決める仕事です。AIから成果物が返ってくるほど、その成果物を何に使うのか、誰が確認するのかが問われます。

ただし、「定型作業はすべてAIへ、判断はすべて人へ」という分け方だけでは足りません。見積書の体裁は定型でも、どの価格表を使うか、納期を確約できるか、顧客へ送ってよいかには別の条件があります。作業名よりも、その中の操作と判断を分ける必要があります。

本稿では、経営者がAIへ仕事を依頼し、結果を受け取る場面を考えます。後半の案件メモは編集部が作成した架空の演習です。企業への取材例、AIの実測出力、時間短縮や利益増の実績ではありません。

実行できる範囲は、モデルだけで決まらない

Anthropicは2026年4月のエージェントに関する説明で、AIが計画・操作・結果の観察・修正を繰り返してタスクを進める仕組みを示しています。その行動はモデルに加え、指示や制約、利用できる道具、実行環境に左右されます。

同じAIでも、文章を読むだけの環境と、メールを送れる環境では任せている仕事が違います。下書きを作れることは、会社としてその条件で提案してよいことを意味しません。モデルの能力と、会社が許す行為を分けて考えるのが出発点です。

また、過去の見積書を読み込ませたからといって、ベテランの判断がすべて引き継がれるわけではありません。書類には、値引きした理由や、今回は引き受けなかった条件が残っていないかもしれません。AIの出力が会社らしい文体に整っていても、その背景まで正しく理解した証拠にはなりません。

経営者は、AIへ渡す資料が現在も使えるものか、例外がどこにあるかを、現場の担当者と確認します。ここには、従来の業務知識が引き続き必要です。

目的・権限・完成条件を決める

AIに「見積もりを進めて」とだけ頼むと、資料の整理、金額の計算、条件の提案、送信のどこまでを求めたのか曖昧になります。まず、依頼を三つに分けて書きます。

経営者が決めること 依頼に書く内容 曖昧なままだと困ること
目的 誰が何を判断するための成果物か 見栄えはよくても必要な情報がない
権限 読んでよい資料、変更してよい範囲、許可する操作 下書き依頼が送信や元資料の変更へ広がる
完成条件 必須項目、根拠、未確認の扱い、確認者 「できました」を受けても使えるか判断できない

完成条件には、進められなくなった場合の扱いも含めます。たとえば、価格表が二つありどちらが現行か分からなければ、勝手に選ばず確認事項として返す。納期が未定なら、過去の案件から推測して約束しない。こうした止める条件を決めます。

Anthropicのエージェント設計の解説も、実行結果から状況を確認すること、人へ判断を戻す地点、停止条件の重要性を述べています。これは開発者向けの設計資料ですが、業務の依頼にも「何を見れば終わったと分かるか」という問いとして応用できます。以下の依頼例は、その考え方を編集部が業務向けに整理したものです。

指示文と、実際にできる操作を揃える

「送信しないで」と依頼文へ書くことと、送信できない環境を用意することは同じではありません。下書きだけが目的なら、最初から送信機能を接続する必要があるかを考えます。参照用の資料と、成果物を書き出す場所も分けておくと、何が変わったかを確認しやすくなります。

Claudeの安全な利用に関する公式ヘルプは、AIが読める内容と実行を許される操作によって、誤動作の影響が変わると説明しています。外部から読んだ文書に、利用者の意図に反する操作へ誘導する指示が含まれる場合もあるため、文章での注意書きだけを操作制限の保証にしません。

具体的な設定は利用する製品や契約で異なります。経営者自身がすべての設定を操作する必要はありませんが、運用担当者に「今回の依頼で、実際に読めるもの・変えられるもの・送れるもの」を説明してもらいます。目的に対して広すぎる操作範囲があれば、小さくしてから試します。

成果物は、根拠と未確認事項も一緒に受け取る

依頼時に目的と参照資料、許可する操作、完成条件と止める条件を決める。AIから下書き・根拠・未確認事項を受け取り、人が資料との一致、範囲、利用や送信の可否を確認する。
依頼時に目的と参照資料、許可する操作、完成条件と止める条件を決める。AIから下書き・根拠・未確認事項を受け取り、人が資料との一致、範囲、利用や送信の可否を確認する。
図解を大きく見る ↗

図:依頼から受領までを整理した提案例です。下書きの完成と、社外へ送信してよいという判断を分けます。

きれいな文章だけを受け取ると、どこが資料に基づき、どこが推測なのかを確認するのに時間がかかります。そこで、成果物と一緒に「参照した資料」「残った疑問」「まだ行っていない操作」を返してもらいます。

ただし、AIが示す根拠にも誤りはあり得ます。人は元資料へ戻り、該当箇所を確かめます。確認者が忙しくて見られないなら、作成量を増やす前に、確認できる量へ依頼を調整する判断も必要です。

下書きの完成と、業務上の完了を分けると、受け取り方が変わります。文書ができた、社内で承認した、顧客へ送った、という状態を一つの「完了」にまとめないようにします。

演習:案件メモから、依頼の範囲を決める

次のメモをもとに、営業責任者がAIへ初回回答の下書きを頼むとします。すべて架空の情報で、実際の顧客データではありません。

案件メモ
L1:顧客は部品Xを400個希望している。
L2:参考単価は1個500円。現行価格かは未確認。
L3:顧客希望納期は11月15日。製造担当は未回答。
L4:顧客へは営業責任者が内容を確認して返信する。
L5:依頼する作業は、社内確認用の回答文案と確認事項の整理。

この時点で、AIに最終見積書の作成や送信まで任せると、未確認の単価と納期を確定条件として扱う余地が生まれます。目的を「営業責任者が次の確認を進めるための文案」に絞った依頼は、次のように書けます。

L1〜L5だけを使い、社内確認用の回答文案を作ってください。
出力は、文案・根拠の行番号・未確認事項の3つに分けます。

条件:
- 数量は400個として扱う。
- 500円を確定した見積単価として提示しない。
- 11月15日の納品を約束しない。
- メール送信、注文登録、元資料の変更は行わない。
- 判断できない条件は推測で埋めず、確認先と一緒に残す。

完成条件:文案に確定していない金額・納期の約束がなく、
営業責任者が次に確認する事項を特定できること。

比較のために、編集部が作った誤った回答を見てみます。AIを実行して得た出力ではありません。

部品Xを400個、単価500円で承りました。11月15日に納品します。先方へ送信済みです。

この回答を完成扱いにできない理由は、文章の質ではなく依頼の条件にあります。

確認する点 この回答の問題 受け取り時の判断
取引条件 参考単価を確定し、注文を受けた表現になっている 現行価格と受注の可否を確認する
納期 顧客の希望を会社の約束に変えている 製造担当の回答を待つ
操作範囲 社内文案の依頼なのに送信済みと述べている 実際の操作履歴を確認し、送信を前提に処理を進めない

文案の一例は「部品Xを400個ご希望の件、承りました。価格とご希望納期への対応を社内で確認のうえ、改めてご連絡します」です。これも編集部が用意した下書きであり、そのまま送ることを推奨するものではありません。営業責任者は文脈に合うかを確認し、価格の現行性と納期回答を未確認事項として引き取ります。

経営者が確認すべきなのは、仕事全体の変化

AIを使うと、下書きにかかる時間が減る場合があります。一方で、資料の整理や確認、例外への対応が増えることもあります。生成の速さだけを見て、人が不要になった、利益が増えると結論づけることはできません。

最初の一件では、指示の準備、確認、修正に使った時間と、残った未確認事項を記録します。確認漏れがあったら、「もっと正確に」と頼み直すだけでなく、資料が足りなかったのか、完成条件が曖昧だったのか、許可した範囲が広かったのかを見直します。

経営者は、すべての作業から離れるのではなく、任せた仕事の結果を判断できる位置を保ちます。現場の知識を持つ人が完成条件を説明でき、その条件で成果物を受け取れるようにすることが、AIへ仕事を任せるための土台になります。