1. 文章を整える前に、影響と再操作の可否を確認する
最初に、止まっている業務、期限、影響を受ける担当や取引を確認します。全員が利用できない、締め処理が止まった、情報漏えいが疑われるといった場合は、詳しい報告文の完成を待たず、社内責任者と契約で決めた窓口へ連絡してください。AIへの入力や文章作成を、初動の前提にしないことが大切です。
特に「画面にエラーが出た」と「保存や送信が行われなかった」は同じではありません。処理は済んでいて、結果の表示だけに失敗した可能性もあります。保存・送信の状態が不明なら、そのまま「未確認」と伝えます。
| 状況 | 最初に伝えること・控えること |
|---|---|
| 注文確定・請求・送信の後にエラーが出た | 操作した日時と対象を伝え、結果の記録を担当者に確認してもらう。確認前に同じ処理を繰り返さない |
| 一部の画面だけ開けない | 開けない画面と、使えている業務を分ける。確かめていない画面を「正常」と書かない |
| 情報漏えいや不正操作が疑われる | 社内の事故対応手順と保守窓口への連絡を優先する。自分で記録を消したり、AIへログを丸ごと貼ったりしない |
再現できていなくても連絡できます。「一度だけ発生」「再操作は未実施」「他の担当者への影響は未確認」と、分かっている範囲を明記しましょう。
2. 操作順・期待した結果・実際の結果を分けて残す
Microsoftの「フィードバックの詳細」は、問題報告で操作内容、期待する動作、実際の結果、再現手順と頻度、エラーの正確な文言を記すよう案内しています。Windows Insider向けの資料であり、個々の業務システムの保守契約や連絡方法を定めたものではありません。
以下は、その考え方を参考にhirostaが提案する業務用の整理表です。保守会社に指定の書式があれば、そちらに合わせます。
| 項目 | 記録する内容 | 書き分けの例 |
|---|---|---|
| 発生日時・対象 | 日時と時間帯、システム・画面名、対象を探す手掛かり | 「午後に動かない」ではなく、確認できる日時と画面を記す |
| 利用環境 | 端末、OS、ブラウザーと版、利用者の役割など、分かる範囲 | 分からない版や権限は推測せず「未確認」 |
| 操作順 | どの画面から、何を選び、どのボタンを押したか | 最後のボタンだけでなく、そこまでの順序を番号で書く |
| 期待した結果 | 何が表示・保存・出力されるはずだったか | 手順書にある仕様か、担当者が期待した動作かも区別する |
| 実際の結果 | 見た表示、出力されたもの、確認できた保存状態 | 「保存失敗」と断定せず「エラーを表示。保存状態は未確認」 |
| エラー原文 | 画面の文言や番号を、意味を変えずに記録 | 記憶による要約なら「原文未確認」と付ける |
| 頻度・影響 | 発生した回数、業務上の支障、他の担当者への影響 | 試していない条件を「必ず発生」「全員」と広げない |
| 依頼したい確認 | 保存の有無、再操作の可否、暫定手順、次の回答予定 | 原因の断定や修正方法の指定を先に置かない |
長いログを集めるより先に、この表の空欄を確認します。調査に必要なログや対象の識別情報は、保守担当者と範囲・共有先を決めて渡してください。
3. AIには、記録の整理と不足項目の指摘を任せる
AIを使わず、上の項目を自分で埋めても構いません。メモが散らばっているときや、文章にまとめにくいときは、下書きの整理にAIを使う案があります。原因の特定や復旧操作は、この依頼の範囲に含めません。
入力前に、会社が認めたAIか、その情報を入力してよいかを確認します。パスワード・認証コード・接続用の秘密情報は入れず、顧客名や注文内容などは省略・置換します。詳しい判断は顧客情報をAIに入力する前の確認をご覧ください。
エラーに顧客名や認証情報が含まれる場合、原文の正確さを理由にAIへ渡す必要はありません。AI用のコピーではその箇所を「［顧客名を省略］」などに置き換え、原記録は社内の認められた場所で管理します。保守会社へ原記録を渡す場合も、許可された経路と必要な範囲に限ります。
AIへの依頼文の例
以下のメモだけを使い、保守会社へ送る報告文の下書きを作ってください。 件名、業務への影響、発生日時と環境、操作順、期待した結果、実際の結果、エラー原文、確認を依頼したいことの順に整理してください。 観察した事実、担当者の期待、未確認事項を分けてください。原因・回数・保存結果・復旧見込みを補わないでください。足りない項目は「未確認」とし、最後に担当者への確認質問を並べてください。 エラー原文は言い換えず、省略箇所の表示も残してください。送信や再操作は行わず、文章の作成だけにしてください。
下書きができたら、担当者がメモと一項目ずつ比べます。「更新後に起きた」が「更新が原因」に変わっていないか、「一度見た」が「毎回起きる」に変わっていないかを確認してください。読みやすさのために操作順やエラーをまとめすぎた場合も、元の記録に戻します。
4. 想定シナリオ：受注システムで確定後にエラーが出た
ここからは架空の卸売会社を使った、未実施の想定シナリオです。実システムの操作、AIの出力比較、保守会社への連絡や復旧を行った記録ではありません。画面名・エラー文・日時は説明用です。
営業担当者は、11月2日14時10分（日本時間）に受注編集画面で納品予定日を変え、「確定」を一度押しました。画面には「処理結果を取得できませんでした（E-204）」と表示されました。担当者は保存の有無を確かめられておらず、再操作も行っていません。別の担当者で発生するかは未確認です。
「システムの更新が原因で保存できない。早く直してほしい」とまとめると、確認していない原因と保存結果が事実のように伝わります。この例では、次のように分けます。
保守会社へ渡す報告文の例
件名：受注編集画面の確定後にE-204を表示／保存状態の確認依頼
11月2日14時10分（日本時間）、受注編集画面でエラーが出ました。納品予定日を確定できたか分からず、該当受注の更新作業を止めています。
操作順：受注一覧から対象を開く → 納品予定日を変更 → 「確定」を一度押す。
期待した結果：変更した納品予定日が保存され、完了の表示が出ると考えていました。手順書との一致は未確認です。
実際の結果：「処理結果を取得できませんでした（E-204）」と表示されました。保存されたか、後続の通知が送られたかは未確認です。
発生は一度です。二重処理を避けるため再操作していません。他の担当者への影響、OS・ブラウザーの版、原因は未確認です。
保存と通知の記録、再操作してよいか、作業を続ける暫定手順をご確認ください。調査に必要な対象情報の共有方法と、次に回答をいただける予定もお知らせください。
実際に送る前には、担当者が日時と原文を見直し、保守先が対象を探すための情報を、社内で認められた方法で加えます。不明な環境情報をAIに推測させる必要はありません。追加調査を待つ間に業務の期限を迎えるなら、その期限と代替手順を決める担当者も伝えます。
5. 連絡後は、調査・修正・業務再開を分ける
保守先から回答が来たら、確認できた事実、残る不明点、次に誰が何をするかを追記します。同じ問い合わせを別の担当者が重ねて送らないよう、窓口と報告の置き場所を決めておきます。
「修正しました」という連絡だけで、止まっていた受注を一括で再実行しないでください。修正の反映と、影響を受けたデータの状態は別です。想定シナリオなら、既に保存・通知された分と未処理の分を保守担当者と確認し、再操作する対象と担当者を決めます。改修を依頼する場合の確認条件は外注したシステムの改修先の選び方でも整理しています。
費用と期間は、文章作成と調査・改修を分けて考える
報告文をAIで整えても、原因調査や改修の費用がなくなるとは限りません。契約内の問い合わせか、別途の調査・改修か、確認用環境の準備や公開後の確認を含むかを保守先に聞きます。見積りが必要なら、調査の範囲・上限と、調査後に改修へ進む判断の区切りを決めましょう。
期間も、初回回答、調査結果、暫定対応、修正の反映、業務再開の確認を分けて相談します。原因や影響が分からない段階で、AIが出した日数を復旧予定として使わないでください。
既存システムの整理・改修はシステム開発、継続支援の内容と料金はサービス・料金でご案内しています。無料相談では、秘密情報を含めず、止まっている業務と資料の状況からお聞かせください。