AIに任せる範囲、自動化のレベル、業務フローへの組み込み方、処理を始めるきっかけ、条件分岐、参照情報、人間による確認。ここまで個別の考え方を理解していても、実際の業務に当てはめる段階では、「どの順番で組み合わせればよいのだろう」と迷うことがあります。このセクションでは、問い合わせ対応と社内書類作成の例を使い、AI処理・定型処理・人間確認を一つの実務フローとして設計する方法を整理します。

AI導入の実務フロー例を学ぶ意味

AI導入の検討では、生成AIが何を作れるか、どのツールを使うかといった話題に目が向きやすくなります。しかし、事業会社で成果につなげるには、AIの機能だけでなく、AIを含む業務全体の流れを考えることが大切です。

たとえば、「問い合わせへの回答案をAIに作らせる」という案だけでは、実際の運用方法はまだ十分に決まっていません。どの問い合わせを対象にするのか、どの情報をAIへ入力するのか、どの資料を参照させるのか、誰が回答案を確認するのか、処理結果をどこに記録するのかまで整理する必要があります。

顧客情報や社内資料をクラウド型AIへ入力する場合は、外部送信の可否、利用目的、秘密保持義務、AIサービス側での保存や再利用の条件も確認します。AIへ渡せる情報と、渡さない情報を分けることも、AI業務フローの設計に含まれます。

AI処理・定型処理・人間確認を組み合わせる

一つの業務の中には、性質の異なる処理が含まれています。受信日時を記録する処理、顧客番号を照合する処理、問い合わせの意味を読み取る処理、回答内容が適切かを判断する処理は、それぞれ役割が異なります。

決められたルールどおりに動かせる部分は、既存システムやワークフロー機能による定型処理が向いています。一方、文章の意味を読み取る、長い資料を要約する、複数の情報から下書きを作るといった部分では、AIを活用できる可能性があります。承認、例外対応、対外的な意思表示などは、人が担当する形が考えられます。

このように複数の技術や人の判断を連携させ、業務全体を自動化・支援する考え方は、「ハイパーオートメーション」と呼ばれることがあります。初級段階では、難しい用語として捉える必要はありません。「工程ごとに、適した担当を割り振る」と考えると整理しやすくなります。

業務フローを整理する基本項目

業務フローを整理するときは、各工程について「何をきっかけに始まり、何を入力し、誰または何が処理し、どのような結果を出し、次にどこへ渡すのか」を確認します。

最初からすべてを細かく決める必要はありません。現在の業務を書き出し、その中で判断に時間がかかる箇所、情報を探している箇所、転記が多い箇所を見つけるところから始めると、検討を進めやすくなります。

AI導入事例1：問い合わせ対応の業務フロー

最初の例は、カスタマーサポートや管理部門に届く問い合わせへの対応です。問い合わせ対応は、生成AIによる業務効率化の事例として取り上げられることが多い業務です。ただし、単に「AIに回答させる」と考えるだけでは、実務に必要な確認や例外処理が見えにくくなります。

ここでは、受信した問い合わせを分類し、関連する社内情報を参照して回答案を作成し、担当者が確認して送信する流れを考えます。送信後には、実際に使用した回答や修正内容を記録し、必要に応じてナレッジを更新します。

ステップ1　問い合わせを受け付ける

業務の始点となるトリガーは、問い合わせフォームの送信、メールの受信、社内チャットへの投稿などです。既存の受付方法を大きく変えず、その後の処理だけを支援する設計も考えられます。

受付時には、問い合わせ本文、顧客番号、契約内容、利用製品、問い合わせ日時、添付ファイルの有無など、回答に必要な情報を確認します。ただし、これらをすべてAIへ入力するわけではありません。AIに渡す必要がない情報、外部送信が認められていない情報、匿名化やマスキングが必要な情報をあらかじめ区別します。

個人情報や機密情報を含む場合は、利用目的、契約上の秘密保持義務、社内の情報分類ルールなどを確認します。必要に応じて、氏名、住所、電話番号、顧客番号、案件を特定できる記述などを削除または置換してから処理します。

入力情報が不足している場合は、AIが推測して回答案を作るのではなく、「追加確認が必要」と表示して担当者へ戻す流れを設けると、運用を安定させやすくなります。

ステップ2　内容を分類し、処理先を決める

次に、問い合わせ内容を分類します。たとえば、「操作方法」「契約変更」「請求」「不具合」「苦情・要望」「その他」といった分類です。分類結果は、担当部署への振り分けや、回答案を作成するときに参照する資料の選択に使えます。

分類は、AIが候補を提示し、定型ルールと組み合わせて処理する方法が考えられます。明確な条件はルールで処理し、文章全体の意味を読まなければ判断しにくい場合はAIが補助します。

苦情、事故、法的な主張、個人情報に関する申出、重大な損害につながる可能性がある内容などは、通常とは異なる対応が必要です。このような案件は、回答案を自動作成する前に、人や専門部署へ引き継ぐ設計が考えられます。

ここでいう例外案件とは、単に珍しい問い合わせではありません。定型回答では処理できない案件、組織としての責任判断を伴う案件、法務・コンプライアンス・安全管理上の確認が必要な案件など、通常の担当者だけでは確定できない案件を指します。

ステップ3　必要な情報を参照して回答案を作る

通常の問い合わせであれば、AIが問い合わせ内容と関連資料をもとに回答案を作成します。参照する情報としては、FAQ、製品マニュアル、契約条件、社内手順書、過去に承認された回答例などが考えられます。

ここで重要なのが、AIに与えるコンテキストです。コンテキストとは、AIが処理を行う際の前提情報や文脈を指します。問い合わせ本文だけでなく、「どの立場で回答するのか」「どの資料を優先するのか」「確認できない内容は断定しない」といった条件を示すと、担当者が確認しやすい回答案を作りやすくなります。

同時に、AIサービスのデータ取扱条件も確認します。AIモデルの学習やサービス改善に自社データや顧客情報が利用されない契約体系が確保されているか、API利用、法人向けプラン、オプトアウト設定などによって目的外の再利用を制限できるかを確認します。保存期間、保存地域、アクセス権限、ログ管理、再委託先の取扱いについても、社内の安全管理基準と照らして整理します。

回答案の形式も整理しておくとよいでしょう。たとえば、「結論」「対応手順」「注意事項」「追加確認事項」の順に出力させると、担当者が内容を確認しやすくなります。文章の完成度だけでなく、確認作業を行いやすい形式にすることが実務上のポイントです。

ステップ4　担当者が確認し、必要に応じて修正する

AIが作成した回答案は、担当者が確認します。確認項目としては、事実関係、社内ルールとの整合、顧客の状況への適合、表現の適切さ、必要な案内の不足などがあります。

「担当者が確認する」とだけ定めるのではなく、何を確認するのかを明確にしておくと、運用のばらつきを抑えやすくなります。たとえば、定型的な操作案内は通常確認、契約条件に関する回答は責任者確認、苦情や法的主張を含む案件は専門部署へ引き継ぐなど、案件の性質に応じて確認レベルを変えます。

AIの出力は、担当者や責任者の判断を支援するための案です。AIが文章を作成した場合でも、最終的な法的・業務上の判断と責任は、その内容を確認し、承認して利用する担当者または責任者が負います。業務フロー上も、最終判断者を明確にしておくことが大切です。

ステップ5　送信結果と修正内容を記録する

担当者が確認・修正した後、回答を送信します。送信した内容、AIが作った最初の案、担当者が修正した箇所、分類結果、参照した資料などを記録できると、運用状況を振り返りやすくなります。

記録の粒度は、何に使うかを基準に決めます。処理の再現性を確保するのか、問い合わせ対応について説明責任を果たすのか、修正傾向を分析して改善するのかによって、必要な記録項目は異なります。すべてを保存するのではなく、目的に応じた範囲を選びます。

たとえば、同じ種類の問い合わせで修正が繰り返されている場合、AIへの指示だけでなく、FAQや社内手順書そのものを見直した方がよいことがあります。AI導入によって見えてきた情報の不足を、業務改善やナレッジ整備へ戻していくことが大切です。

問い合わせ対応の設計で確認したいこと

• 問い合わせは、どの窓口から、どのような形式で届いているか
• 分類基準が担当者間で共有されているか
• FAQや手順書の更新日と管理責任者が明確か
• 通常案件と例外案件を分ける条件を説明できるか
• 確認担当者と、責任者へ引き継ぐ条件が決まっているか
• 個人情報や機密情報について、外部送信の可否と匿名化の要否を確認しているか
• 自社データや顧客情報がモデル学習等に利用されない契約や設定を確認しているか
• 保存場所、保存期間、再利用ポリシー、委託先管理を確認しているか
• 修正内容を次の改善に使える形で記録できるか

資料がそろっていない段階でも、業務の流れから整理できます。現場の担当者が普段どの資料を探し、どの点に注意して回答しているかを聞き取ることで、必要なコンテキストや確認ポイントが見えてきます。

AI導入事例2：社内書類作成の業務フロー

二つ目の例は、稟議書、報告書、会議記録、社内通知、業務引継書などの社内書類作成です。書類作成には、文章を書く工程だけでなく、必要情報を集める、形式を整える、内容を確認する、修正する、決められた場所へ保存する工程があります。

生成AIを活用する場合は、下書き作成だけを対象にする方法もあります。ただし、前後の工程まで含めて考えると、より実務に合ったAI業務フローを設計できます。

ステップ1　書類の目的と利用場面を決める

書類作成のAI業務フローを考えるときは、最初に「何のための書類か」を確認します。同じ報告書でも、経営会議で判断に使う書類と、チーム内で経過を共有する書類では、必要な情報や確認レベルが異なります。

作成目的、読み手、提出先、対象期間、必須項目、文体、分量などを入力条件として整理しておくと、AIが作った下書きを確認しやすくなります。

ステップ2　必要な情報を収集する

次に、書類の根拠となる情報を集めます。週次報告書であれば、案件一覧、進捗記録、会議メモ、課題管理表、数値実績などが考えられます。

情報収集は、既存システムから決められた項目を取り出す定型処理と、自由記述のメモを整理するAI処理に分けられます。数値や日付など、正確な転記が求められる項目は既存データから取得し、文章の要約や構成にはAIを使うという役割分担が考えられます。

外部資料、購入したデータ、ライセンス契約のある記事やデータベース、取引先から受領した資料などを利用する場合は、その資料をAIサービスへ入力できるか、契約や利用規約で確認します。閲覧が認められていても、外部サービスへのアップロードや二次利用まで認められているとは限りません。

使用する情報の時点をそろえることも大切です。対象期間や基準日を明確にし、不足情報がある場合は下書き作成を進めず、確認事項として表示する設計も考えられます。

ステップ3　所定の形式で下書きを作る

必要情報がそろったら、AIが書類の下書きを作成します。既存の様式がある場合は、見出しや項目の順番を維持しながら、各欄へ情報を整理します。

AIには、事実と提案を区別して出力させると確認しやすくなります。たとえば、「実績」「発生した課題」「考えられる原因」「次の対応案」を分けます。事実として確認できない内容には印を付け、担当者が確認できるようにする方法もあります。

AIに求めるのは、最終判断ではなく、確認しやすい下書きを作ることです。原因分析、評価、責任の所在、今後の方針など、組織として判断すべき内容は、担当者や責任者が確認・追記する余地を残します。

AIが生成した文章であっても、既存資料の引用や要約を含む場合は、著作権、契約、利用規約、引用条件などへの配慮が必要です。原資料の表現を必要以上に再現させず、業務上必要な範囲で情報を整理します。

ステップ4　正確性と権利関係を確認する

担当者は、下書きに含まれる数値、固有名詞、日付、事実関係、評価、提出先に応じた表現を確認します。AIが資料を要約した場合でも、重要な条件が省略されていないか、原資料と意味が変わっていないかを確認します。

正確性に加えて、原資料の著作権や第三者の権利を侵害する表現が含まれていないかも確認します。原文の特徴的な表現が長く残っていないか、引用部分と自社の説明が区別されているか、出典表示が必要な箇所はないか、利用規約で要約や再利用が制限されていないかを見ます。

書類の種類によっては、複数の確認者が必要です。作成担当者が事実関係を確認し、部門責任者が評価や方針を確認し、管理部門が形式、社内ルール、権利関係を確認するといった役割分担が考えられます。

AIの出力は作成支援のための案です。最終的な法的・業務上の責任は、内容を確認し、承認して利用する担当者や責任者が負います。書類の用途に応じた確認者と承認者を明確にしておくことが大切です。

ステップ5　確定版を保存し、次回へつなげる

内容が確定したら、決められた保存先へ登録します。ファイル名、版番号、作成日、作成者、承認者などは、可能であれば定型処理で付与すると、保存ルールを統一しやすくなります。

AIが作った初稿と確定版の差分を記録できると、下書き作成の改善に使えます。毎回同じ項目が追加されているなら、入力条件や文書様式にその項目を加えます。毎回表現が修正されているなら、文体や用語のルールをコンテキストへ追加する方法があります。

保存する情報の範囲は、再現性、説明責任、改善分析のどれに使うかを基準に決めます。機密情報や個人情報を含む入力内容、AIとのやり取り、修正履歴を保存する場合は、保存期間、アクセス権限、削除方法も併せて整理します。

営業提案支援へ置き換える場合

同じ考え方は、営業提案支援にも応用できます。顧客情報、商談記録、過去の提案、商品・サービス情報などをもとに、提案の構成案やフォローメールの下書きをAIが作成し、営業担当者が確認する流れです。

たとえば、商談終了をトリガーとして、定型処理で顧客情報と商談メモを集めます。AIが課題、要望、次回確認事項を整理し、提案の方向性やお礼メールの案を作ります。営業担当者は、顧客との関係、商談時のニュアンス、社内の提案方針を踏まえて修正します。

顧客情報や過去提案をAIへ入力する場合も、秘密保持義務、個人情報の利用目的、外部送信の可否、提案資料に含まれる第三者の著作物やライセンス条件を確認します。

AIが受注可能性や価格条件を単独で決めるのではなく、担当者が判断するための材料や下書きを準備する役割から始めると、業務へ組み込みやすくなります。

自社業務へ置き換えるための進め方

実務フロー例は、そのまま導入するための完成形ではありません。自社の業務、扱う情報、既存システム、担当者の役割、確認体制に合わせて調整するための参考例です。

自社業務へ置き換えるときは、AIを使う場所から決めるのではなく、現在の業務を出発点にします。そのうえで、AIが補助できる工程、定型処理でつなげられる工程、人が判断する工程、AIへ情報を渡す前に確認する工程を分けていきます。

開始地点と終了地点を決める

対象業務を選ぶときは、業務の開始と終了を言葉にしてみましょう。問い合わせ対応であれば、「問い合わせを受信した時点から、回答を送信し履歴を記録するまで」と定義できます。

書類作成であれば、「必要情報が登録された時点から、承認済みの書類を所定の場所へ保存するまで」と定義できます。開始と終了が明確になると、対象範囲が広がりすぎることを避けやすくなります。

現在の業務を作業と判断に分ける

現在の業務を書き出すときは、作業と判断を分けて見ると整理しやすくなります。コピー、転記、通知、保存などは比較的ルール化しやすい作業です。一方、問い合わせの意図を読む、例外かどうかを見分ける、回答の妥当性を確認するといった工程は判断を含みます。

判断を含む工程が、すべてAIに適しているとは限りません。判断基準が共有されているか、結果を後から確認できるか、誤りがあった場合に人が修正できるかを確認します。

AIに任せる範囲を出力単位で決める

「問い合わせ対応をAI化する」「営業活動をAI化する」といった大きな単位ではなく、AIが何を出力するのかを具体化します。

• 問い合わせの分類候補を出す
• 問い合わせ内容を短く要約する
• 参照すべきFAQの候補を示す
• 回答メールの下書きを作る
• 報告書の項目に沿って情報を配置する
• 商談記録から次回確認事項を抽出する

出力単位を具体化すると、誰が使うのか、どの程度の品質が求められるのか、どのような確認が必要かを話し合いやすくなります。

人間確認を必要な場所へ配置する

人間確認というと、AIが作ったものを最後に確認する工程を想像しやすいかもしれません。しかし、実務ではAI処理の前にも人の判断を置くことがあります。

たとえば、担当者がAI処理の対象案件を選ぶ方法や、入力情報がそろっているか、外部サービスへ送信できる情報かを確認してからAIへ渡す方法があります。処理の途中で条件分岐を設け、一定の条件に該当した場合だけ人へ戻すこともできます。

人間確認は一か所に固定せず、業務上の判断や情報管理上の確認が必要な場所へ配置します。

改善に必要な記録を設計する

AI導入後の改善は、担当者が気づいたときだけ個別に行う形では続きにくくなります。どの情報を記録し、どの頻度で振り返り、誰が変更を判断するのかを業務フローへ含めておくと、改善を継続しやすくなります。

改善対象は、AIへの指示だけではありません。入力情報、参照資料、分類ルール、確認項目、承認経路、保存形式なども対象です。出力の修正が多い場合でも、原因がAIではなく、参照資料の古さや入力項目の不足にあることがあります。

効果測定の詳細は次のChapterで扱いますが、フロー設計の段階でも、回答作成時間、修正率、一次回答で完結した割合、例外案件への振り分け率など、後から確認したい指標を想定しておくと、必要な記録項目を決めやすくなります。

よくあるつまずき

AI業務フローの設計では、いくつか整理しにくい点があります。ここでは、検討の初期段階で起こりやすい状況として確認してみましょう。

フローが複雑になりすぎる場合

例外や条件が増え、フロー図が複雑になる場合は、すべてを一枚にまとめる必要はありません。まずは通常案件の基本フローを作り、その後に、情報不足、重要案件、外部送信できない情報を含む場合、システム連携が止まった場合などを別に整理します。

全体像と詳細を分けることで、経営者、責任者、現場担当者のそれぞれに説明しやすくなります。

担当者ごとに手順が異なる場合

同じ業務名でも、担当者ごとに進め方が異なることがあります。その場合は、すぐに一つの手順へ統一せず、複数の担当者から実際の進め方を聞き取ります。

手順が異なる理由を確認すると、顧客区分、案件の難易度、担当者の経験、使用資料の違いなどが見えてきます。それらを条件分岐として整理できれば、業務の違いを残しながら共通部分を設計できます。

経営者・責任者向けの確認ポイント

経営者や部門責任者がAI導入後の業務フローを確認するときは、AIの機能だけでなく、業務上の責任、情報管理、権利確認、判断の流れを確認することが大切です。

業務上の目的が明確か

「生成AIを使うこと」自体が目的になっていないかを確認します。回答作成時間の短縮、確認作業の標準化、情報検索の負担軽減、担当者間のばらつきの縮小など、業務上の目的を言葉にします。

この段階では、詳細なROIや投資判断まで算定する必要はありません。ただし、何を良くしたいのかを整理しておくと、次のChapterで効果測定を検討しやすくなります。

最終判断者が明確か

AIが回答案や書類案を作っても、それだけでは業務上の確定結果にはなりません。誰が確認し、誰が承認し、誰の名義または責任で利用するのかを確認します。

特に、顧客への回答、契約条件に関する案内、経営判断に使う報告書などでは、最終判断者を明確にします。AIは補助者であり、最終的な法的・業務上の責任主体にはなりません。

外部サービスへ情報を送信できるか

AIへ入力する情報について、個人情報保護法、プライバシーポリシー、秘密保持義務、取引先との契約、社内規程に照らして外部送信できるかを確認します。

クラウド型AIでは、データの保存場所、保存期間、学習やサービス改善への再利用、オプトアウト、再委託先、アクセス制御、削除方法などを確認します。法人契約やAPIを利用する場合も、実際の契約条件と設定を確認することが大切です。

例外を受け止める体制があるか

AIの対象外となる案件や、判断が難しい案件を人へ戻す設計があっても、受け皿となる担当者や部署が決まっていなければ、処理が滞ります。

例外案件が多い場合は、AIの能力だけでなく、対象業務の分類基準や入力情報を見直す必要があるかもしれません。例外から業務の特徴を把握する視点も役立ちます。

既存業務との接続が現実的か

AIが作った内容を別の画面へ毎回コピーし、複数のシステムへ手作業で登録する設計では、負担が十分に減らない場合があります。

初期段階では手作業を残すこともありますが、転記や二重入力がどこで発生するかを把握しておくと、将来の改善対象を整理できます。

確認に必要な情報が提示されるか

担当者がAIの回答案を確認するときに、参照した資料や判断の前提へ戻れるかも重要です。出力文だけが表示され、根拠となる情報を確認できない状態では、確認作業が難しくなります。

どの資料を参照したか、情報が不足している箇所はどこか、AIがどの分類を提案したかなど、確認に必要な情報を併せて提示する設計を検討します。

第三者の権利と利用条件を確認できるか

外部資料や過去の提案書をAIで要約・再構成する場合は、著作権、営業秘密、データベースの利用規約、ライセンス条件などを確認します。AIが生成した文章であっても、既存資料の表現や構成を過度に維持している場合は、権利上の確認が必要になることがあります。

AI導入支援者としての着眼点

AI導入コンサルタントを目指す人や、社内推進担当として部門を支援する人は、完成したフローを提示する前に、現場の業務がどのように成立しているかを聞き取ることが大切です。

現場担当者が「問い合わせ対応を効率化したい」と話していても、負担の中心が文章作成とは限りません。顧客情報を探す時間、担当部署を判断する時間、承認を待つ時間、同じ内容を複数システムへ登録する時間が大きい場合もあります。

業務名ではなく、実際の動作を聞く

ヒアリングでは、直近の案件を例に、実際の動作を順番に確認します。

• 最初に何を確認しますか。
• どのシステムや資料を開きますか。
• 誰に確認することがありますか。
• 通常とは異なる案件を、どのように見分けますか。
• どの情報は外部サービスへ送信できませんか。
• 処理後、どこへ記録しますか。
• 修正することが多いのは、どの部分ですか。

具体的な一件を追うことで、正式な業務手順書には書かれていない判断や工夫が見えてきます。

情報の利用条件をヒアリングに含める

AI導入支援では、技術部門や現場部門だけで情報の入力可否を決めず、必要に応じて法務、情報セキュリティ、個人情報保護の担当者と確認します。

「社内で利用している資料だからAIへ入力できる」とは限りません。資料の取得条件、利用目的、契約、ライセンス、外部送信の制限を確認し、入力可能な範囲を業務ルールとして整理します。

工程が存在する理由を確認する

業務フローには、過去の事情から残っている工程もあれば、品質や説明責任のために重要な工程もあります。工程を減らす前に、その目的を確認します。

たとえば、二重確認が行われている場合、担当者と責任者が異なる観点で確認している可能性があります。誰が何を確認しているのかを分けて聞くと、AI導入後も残した方がよい確認が見えてきます。

移行途中のフローも考える

AI導入後の理想形を描くことは大切ですが、現場がすぐに移行できるとは限りません。既存システムとの連携が難しい場合は、AIが作った下書きを担当者が確認し、既存システムへ登録する運用から始めることも考えられます。

将来の全体像と、現在の環境で実施できる範囲を分けて示すと、関係者が検討しやすくなります。最初から完璧に決める必要はありません。できる範囲から確認し、運用を通じて対象範囲や接続方法を見直していきます。

確認者の負担も見る

AIを導入すると、作成担当者の作業時間が減る一方で、確認者の負担が増える場合があります。大量の回答案や書類案が短時間で作られると、確認工程が新たな滞留点になることもあります。

支援時には、AIが何件処理できるかだけでなく、誰が何件確認できるか、確認に必要な情報がそろっているか、案件に応じて確認レベルを変えられるかを確認します。

フロー図を関係者の共通言語にする

AIワークフローの図は、システム設計者だけの資料ではありません。経営者には業務の全体像と責任の流れを、現場担当者には日々の作業の変化を、IT部門には連携箇所を、法務や情報セキュリティ部門には外部送信と確認ポイントを説明する資料として使えます。

一枚の図へすべてを詰め込まず、説明相手に応じて情報量を調整します。経営者向けには主要工程と判断ポイント、現場向けには入力項目と操作、システム担当向けにはデータの受け渡し、管理部門向けには情報区分や承認条件を示すと、話し合いを進めやすくなります。

ミニチェックリスト

自社のAI導入設計を考える際は、次の項目を確認してみましょう。すべてに回答できない段階でも大丈夫です。答えにくい項目は、今後のヒアリングや情報整理の対象になります。

• 対象業務の開始地点と終了地点を、一文で説明できますか。
• AIへ渡す情報、匿名化が必要な情報、外部送信できない情報を区別できていますか。
• 利用するAIサービスの保存場所、保存期間、再利用、オプトアウト、委託先管理を確認していますか。
• AI処理、定型処理、人間による判断の役割を工程ごとに分けていますか。
• 通常案件、情報不足、定型回答不可の案件、責任判断を伴う案件を分ける条件がありますか。
• AIの出力を誰が確認し、事実、規程、権利関係、表現の何を確認するか決まっていますか。
• 最終的な法的・業務上の判断と責任を負う担当者または責任者が明確ですか。
• 処理結果や修正内容を、再現性、説明責任、改善分析の目的に応じて記録できますか。