成果物から、変更・調査・定期のどれを頼むか決める

hirostaの社内で行っていることとして、依頼は成果物に合わせて「変更・調査・定期」に分けています。変更は記事や機能などを作る・直す仕事、調査は判断材料をまとめる仕事、定期は同じ条件で繰り返す仕事です。目的・範囲・受け入れ条件を本文に書き、未決の判断を着手前に解消します。

業務への当てはめでは、まず「下書きを作る」「調べた結果を報告する」「継続して処理する」のどこまでを頼むかを決めます。これは依頼を整理するための提案であり、どのAIでも同じ種類の仕事を実行できるという意味ではありません。

「問い合わせ対応を改善して」だけでは、改善案の報告が欲しいのか、返信下書きが欲しいのか、送信まで任せるのかが分かりません。最初に必要な成果物と、誰が使うものかを示してください。

依頼本文に書く項目と、書き漏れたときに起きること

次は、社内の依頼の書き方を業務担当者向けに整理した項目です。製品固有の操作方法ではありません。

目的：誰の、どの困りごとを解消したいか

「返信を作る」だけでなく、「担当者が回答資料を探し直す負担を減らすため、根拠付きの下書きを用意する」と書きます。目的がないと、文章はできても、担当者が確認したい根拠が欠けることがあります。

範囲：使う資料、成果物、しない操作

対象の仕事、参照してよい資料、結果を残す場所を示します。下書きの作成と送信、集計候補の作成と正式な登録は別の操作です。「下書きまで。送信と元資料の変更は対象外」のように境界を明記します。

範囲があいまいだと、必要な成果物が足りない、想定より広い変更案になる、といった食い違いが起きます。参照先を示す前に、AIへ共有してよい資料かを確認することも必要です。

受け入れ条件：何を確かめれば完成といえるか

受け入れ条件は、依頼を完了と判断するための確認項目です。「分かりやすく」だけでなく、「回答の根拠を示す」「資料にない内容は確認待ちにする」「担当者が下書きと未確認の点を見分けられる」と書きます。

条件がないと、AIが作成した結果と、人が必要とする完成状態がそろいません。確認できなかった条件は、完了したものに混ぜず残します。

前提の判断：今回使うルールを本文にも書く

既に決めた対象、判断基準、数値や条件の意味を、今回の依頼に直接書きます。資料へのリンクは補助として使い、「前に決めた通り」だけにしないことが大切です。条件を使うために過去の会話を探し直す必要があるなら、その条件を本文へ補います。

人が決める点：承認する操作と、止める条件

着手、結果の採用、送信・登録・公開などを誰が決めるかを書きます。担当者が不明、参照資料が矛盾する、依頼にない操作が必要、といった場合は、推測で進めず何を確認するかを示します。

hirostaの社内の開発基盤では、着手とマージ（変更の取り込み。本番公開を兼ねます）を人がラベルで承認します。通知は、人の対応が必要なときに限ります。読者の業務でも、単なる進捗報告と、判断が必要な連絡を分ける方法が考えられます。

社内の記録：前提不足と記録の読み違いで止まった

ここはhirostaの社内で実際に起きた記録です。材料は2026年10月9日に取得したもので、お客様の業務の事例ではありません。

過去の依頼を読めず、前提が分からなかった

2026年10月8日、作業中のAIが閉じた過去の依頼を読めず、前提が分からずに止まりました。そこで、前提にする判断・数値・条件は依頼の本文に直接書く決まりにしました。

この記録を依頼の書き方に結び付けると、人が過去の合意を覚えていることと、作業中のAIがその合意を参照できることは別だと分かります。リンクを添える場合も、作業の可否を左右する条件は本文だけで分かるようにします。資料を読めない原因や、改善後の停止頻度は、この材料からは確認できません。

残した記録が、これから必要な作業と受け取られた

2026年10月9日には、PR（変更案）本文の記録を「マージ前に必要な作業」と読み違え、自動マージが止まりました。

この記録から依頼文に活かせるのは、「確認した結果」「これから人が決める点」「承認後に人が行う作業」を分けて書くことです。例えば、確認済みの項目には結果を記し、未実施の項目には担当と実施する時点を記します。記録を残すという行為だけでは、それが完了報告か次の指示かは伝わりません。

これは読み違いから停止した記録であり、その後の自動マージの再開や、この書き分けによる効果を確認した記録ではありません。導入全体の見直しはAI導入のつまずき、利用開始後の更新・復旧は業務ツールの保守で扱っています。この記事は依頼本文に残す条件に絞っています。

想定シナリオ：問い合わせの返信下書きを依頼する

以下は中小企業の担当者が使うための想定シナリオです。hirostaやお客様がこの依頼で実際に導入・検証した記録ではなく、社内で使っている指示文の転載でもありません。

問い合わせの返信を担当者が確認する会社で、回答資料を探す工程と、下書きを作る工程を整理したい場合を想定します。依頼を出す前に、次の内容を埋めます。

  • 目的：担当者が根拠を確認して返信を仕上げられるよう、回答資料に基づく下書きを用意する。
  • 範囲：共有を許可した問い合わせ文と、業務責任者が指定した現行の回答資料だけを使う。結果は社内の下書き欄に残し、メール送信や顧客台帳の更新はしない。
  • 受け入れ条件：問い合わせの要点、下書き、参照した資料、確認待ちの点が区別されている。資料にない回答を確定したように書かない。
  • 前提の判断：担当者が返信前に内容を確認する。回答資料が矛盾する場合は確認待ちにし、納期や個別の条件を推測して約束しない。この方針を依頼本文にも書く。
  • 人が決める点：業務責任者が着手と資料の利用範囲を決め、返信担当者が回答内容を確認して送信する。根拠不足や担当不明は、確認が必要な内容として戻す。

結果を見る画面は「問い合わせの要点・返信下書き・根拠資料・確認待ち」が並ぶ形を想定します。根拠不足の項目は担当者が資料を補うか、別の担当へ確認します。下書きができただけで、返信が完了したとは扱いません。

過去に納期の扱いを決めていたとしても、「以前の相談と同じ」とは書かず、「資料にない納期は約束しない」と本文へ残します。結果の報告では、下書き作成の完了と、送信前に人が確認する項目を分けます。

費用や準備の手間を検討するときは、下書きの作成だけでなく、回答資料の整理、確認画面や保存先の用意、人の確認、資料の更新も含めます。この想定シナリオには、実測の費用・時間や削減効果はありません。具体的な業務範囲は問い合わせ対応の業務ページで確認できます。

よくある質問

Q. AIに仕事を任せる依頼には何を書けばよいですか？ 目的、対象と成果物、完成と判断する条件、前提の判断、人が承認する操作を書きます。未決の判断を着手前に解消し、作業を止めて確認する条件も添えます。

Q. 過去の依頼へのリンクだけでは足りませんか？ 作業中のAIが読めるとは限りません。今回の判断を左右する条件は本文に直接書き、リンクは詳しい経緯や補足を参照するために使います。本文へ書く情報も共有してよい範囲に限ります。

Q. 条件がまだ決まっていない場合はどう頼みますか？ 実行する仕事を先に任せず、未決の点を整理する調査として依頼する方法があります。必要な成果物を比較や確認事項の報告に限定し、実行へ進む判断は人が行います。

Q. 結果の報告では何を分けますか？ 完了した作業と確認結果、未確認の点、人の判断が必要な点、これから行う作業を分けます。未実施の作業には担当と実施する時点を示し、完了の記録を次の指示と混同しないようにします。