Media > AI活用ユースケース > 品質管理 > 内部監査とISO審査の記録から、指摘事項と是正の進捗を管理する

内部監査とISO審査の記録から、指摘事項と是正の進捗を管理する

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

監査の記録を入力に、指摘事項を1件ずつ台帳の形に整理し、是正の期限と進捗を追えるようにします。事務局の作業は、報告書を読み直して転記することから、整理された指摘を確かめて各部門に回すことに変わります。

サマリー
利用ツール
ChatGPT/Claude/Gemini/Google Apps Script/Make/n8n/Power Automate
対象業界
IT・SaaS/医療/建設/製造
対象部門
品質管理/経営企画
対象業務
台帳・マスタ管理/記録・議事録作成
主な課題
人手が足りない/属人化している/期限・対応漏れが起きる
AIで行う処理
要約
主な効果
品質標準化/属人化解消/工数削減
導入難易度
★★☆☆☆
実装レベル
半自動化
費用感
ノーコード連携(中)
人間の確認
条件付き
現在工数
30h/月
AI導入後
10h/月
想定削減
67%
年間削減
240h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 監査員が監査を実施し、報告書を作る
  2. 事務局が報告書を受け取り、読む
  3. 指摘事項を拾い出し、Excelの管理表に転記する
  4. 指摘ごとに、対象部門・区分・期限を決める
  5. 部門に是正処置の計画を依頼する
  6. 部門から是正計画が返る
  7. 計画の内容を確認し、管理表に記録する
  8. 期限が来たら、是正の完了を確認する
  9. 次回の監査で、前回の指摘が再発していないかを見る
導入後(After)
  1. 監査員が監査を実施し、報告書をSharePointの所定フォルダに置く
  2. 自動報告書から指摘事項を1件ずつ切り出す
  3. 自動指摘ごとに、対象部門・要求事項の条項・根拠となる記述を抜き出す
  4. 自動過去の指摘から、内容の近いものを探す(繰り返しの検出)
  5. 事務局が切り出し結果を確認し、区分と期限を決める
  6. 自動台帳に登録し、部門に是正計画の依頼を出す
  7. 部門が是正計画を出す
  8. 自動計画の記載に不足がないかを確認する(原因、処置、期限、有効性の確認方法)
  9. 事務局が計画を確認し、承認する
  10. 自動期限の1週間前と当日に、未完了のものを通知する
  11. 自動月次で、未是正の件数・期限超過・繰り返しの指摘を一覧にする
各工程の詳しい説明を読む
  1. 監査員が監査を実施し、報告書を作る
  2. 事務局が報告書を受け取り、読む
  3. 指摘事項を拾い出し、Excelの管理表に転記する
  4. 指摘ごとに、対象部門・区分・期限を決める
  5. 部門に是正処置の計画を依頼する
  6. 部門から是正計画が返る
  7. 計画の内容を確認し、管理表に記録する
  8. 期限が来たら、是正の完了を確認する
  9. 次回の監査で、前回の指摘が再発していないかを見る

問題は5つあります。

(a)報告書の書き方が監査員によって違う。 「〜が確認できなかった」「〜の記録がない」「〜について改善の余地がある」と、指摘の書き方が揃っていません。どこまでが1件の指摘かの切れ目も、読む人によって変わります。

(b)台帳への転記に時間がかかる。 16部門分の報告書を開いて、指摘を1件ずつExcelに写します。この作業が、監査の後の2週間を占めます。

(c)未是正の件数が即座に出ない。 「今、何件が未是正か」を聞かれても、管理表の更新が追いついていないため答えられません。

(d)期限の管理ができていない。 是正の期限を過ぎても、誰も気づきません。外部審査の直前に慌てて確認します。

(e)繰り返しの指摘に気づけない。 同じ部門で同じ内容の指摘が3回続いていても、過去の管理表を横断して見る手段がありません。

  1. 監査員が監査を実施し、報告書をSharePointの所定フォルダに置く
  2. 【自動】 報告書から指摘事項を1件ずつ切り出す
  3. 【自動】 指摘ごとに、対象部門・要求事項の条項・根拠となる記述を抜き出す
  4. 【自動】 過去の指摘から、内容の近いものを探す(繰り返しの検出
  5. 【人】 事務局が切り出し結果を確認し、区分と期限を決める
  6. 【自動】 台帳に登録し、部門に是正計画の依頼を出す
  7. 【人】 部門が是正計画を出す
  8. 【自動】 計画の記載に不足がないかを確認する(原因、処置、期限、有効性の確認方法)
  9. 【人】 事務局が計画を確認し、承認する
  10. 【自動】 期限の1週間前と当日に、未完了のものを通知する
  11. 【自動】 月次で、未是正の件数・期限超過・繰り返しの指摘を一覧にする

自動化されるのは「切り出す」「抜き出す」「探す」「通知する」「集計する」の5つです。残るのは「区分と期限を決める」「是正計画を承認する」で、これは事務局と責任者の仕事です。

02今回想定するシステム構成

構成図
監査員(監査報告書・チェックリスト)
   │
   ▼ SharePoint の監査フォルダ
   │
   ▼【トリガー】ファイルが作成されたとき
n8n
   │
   ├──▶ 文書からテキストを取り出す(Word / Excel / PDF)
   │
   ├──▶ LLM API ── 指摘事項の切り出し
   │                 + 対象部門・条項・根拠の抽出
   │                 + 是正計画の記載不足の指摘
   │
   ├──▶ 過去の指摘との照合(繰り返しの検出)
   │
   ▼
指摘事項の台帳(SharePoint リスト)──【事務局が区分と期限を決める】
   │
   ├──▶ 部門へ是正計画の依頼(Teams / メール)
   └──▶ 期限の通知(1週間前・当日)
   │
   ▼【トリガー】毎月1日 朝8時
n8n ── 未是正・期限超過・繰り返しの指摘を一覧にする
役割想定する製品代替候補
ワークフローn8nMake、Power Automate、Google Apps Script
生成AIClaude APIOpenAI API、Gemini API
保管SharePointBox、Google Drive
台帳SharePoint リストGoogle スプレッドシート、Excel

マネジメントシステムの運用を支援するツール(文書管理、監査計画、指摘の管理を一体で扱うもの)が存在します。 まずそれを検討してください。自前で組む価値があるのは、すでにWordとExcelで運用していて、システムを入れ替えずに台帳化だけを足したい場合です。

ISO 9001 では、内部監査を計画的に実施するための監査プログラムを定めることと、不適合に対して適切な処置をとり、是正処置の有効性をレビューすることが求められています。 この構成は、その記録を追える形にするためのものです。

03どうやって実装するのか

Step1

処理の起点を決める

トリガーは3つです。

1つ目は、監査報告書がSharePointに置かれたときです。監査の直後に切り出しが終わっていれば、事務局の作業が翌日から始められます。

2つ目は、期限の通知です。n8n の Schedule Trigger は、秒・分・時・日・週・月・cron式の7種類の間隔を設定できます。毎日の実行で、期限が近い指摘と超過している指摘を拾います。

3つ目は、月次の集計です。未是正の件数、期限超過、繰り返しの指摘を一覧にします。

なお、セルフホストの n8n では既定のタイムゾーンが America/New_York です。環境変数またはワークフロー設定で日本時間にしてください。

Step2

入力データを集める

データ中身取得元
監査報告書監査日、監査員、被監査部門、指摘事項、良好事項監査員
チェックリスト確認項目と結果(適合/不適合/観察)監査員
外部審査の報告書審査機関からの指摘(不適合・改善の機会)審査機関
顧客監査の報告書顧客からの指摘と要求顧客
要求事項の一覧規格の条項(ISO 9001の箇条、ISO 14001の箇条)と社内規程の対応事務局
組織図部門と責任者人事
過去の指摘台帳過去の指摘、区分、是正内容、完了日事務局(整備が必要
是正計画原因、処置の内容、期限、有効性の確認方法被監査部門

「過去の指摘台帳」がこの構成の要です。 繰り返しの指摘を見つけるには、過去分が同じ形で並んでいる必要があります。過去2年分の報告書から作れます。 この作業自体をこの構成でやらせることもできます。

「要求事項の一覧」も先に整えてください。 指摘が規格のどの条項に関わるかを紐づけられると、「同じ条項で複数部門が指摘を受けている」という傾向が見えます。

Step3

データの取得方法を決める

報告書からのテキスト抽出: 形式ごとに扱いが違います。

形式注意
Word本文と表をそのまま取得できる
Excel(チェックリスト)セル単位で取得。結合セルと改行に注意
PDF(外部審査)テキスト層があればそのまま。なければOCR

チェックリストのExcelがもっとも扱いにくくなります。 監査員ごとに様式が違い、指摘が備考欄に書かれていたり、判定列に「×」とだけ入っていたりします。様式を1つに統一するのが先です。

過去の指摘台帳の作成: 過去2年分の報告書を1本ずつ処理し、指摘を切り出します。事務局が確認して台帳にします。180件×2年=360件です。 この作業に1〜2週間かかりますが、1度だけです。

Step4

AIへ渡す前に整形する

  1. 報告書の種別判定 … 内部監査/外部審査/顧客監査を分けます。区分の体系が違うため、同じ扱いにできません
  2. 被監査部門の特定 … 報告書の見出しから部門を特定し、組織図と照合します
  3. 監査日と監査員の抽出 … 台帳の必須項目です
  4. 指摘の候補の切り出し … 「不適合」「改善の機会」「観察事項」といった見出しの下の記述を候補にします
  5. 良好事項の除外 … 良好事項を指摘として台帳に入れないよう分けます
  6. 過去台帳の読み込み … 同じ部門の過去の指摘を用意します

5番目を必ず入れてください。 良好事項が指摘として台帳に入ると、件数が水増しされ、部門から不信を招きます。

Step5

AIに処理させる

処理内容
指摘の切り出し報告書の文章から、指摘を1件ずつに分ける
要点の整理「何が、どの基準に対して、どう合っていないか」を整理する
根拠の抽出監査員が確認した事実(記録の不備、手順との相違)を原文のまま引用する
条項の紐づけ規格のどの条項に関わるかの候補を示す
繰り返しの検出過去の指摘から内容の近いものを探す
是正計画の記載不足の指摘原因・処置・期限・有効性の確認方法のうち、書かれていない項目を挙げる

AIに次のことをさせないでください。

させないこと理由
不適合か観察事項かの区分の判断監査員と事務局が決めること。区分は認証に影響する
是正処置が有効かどうかの判断規格が求める「有効性のレビュー」は人が行う
原因の推定原因分析は被監査部門が行う。AIが書くと部門が考えなくなる
指摘の重大性の評価事務局と責任者が判断する
「この指摘は是正済みと見なせる」という結論完了の判定は人が行う

「原因の推定をさせない」ことが、特に重要です。 指摘を受けた部門が自分で原因を考えることが、是正処置の本体です。AIが「教育不足が原因と考えられます」と書くと、部門はそれを写して終わりにします。 そして同じ指摘が繰り返されます。

Step6

指示内容を固定する

あなたは、マネジメントシステムの事務局を支援する担当者です。
監査報告書から指摘事項を1件ずつ切り出して整理してください。

【厳守事項】
- 指摘の区分(不適合/改善の機会/観察事項)を、あなたが判断しないでください。
  報告書に区分が明記されている場合のみ、その語をそのまま転記してください。
  明記がない場合は category を null にし、
  「区分の記載なし」と needs_review に入れてください。
- 原因を推定しないでください。
  「教育が不足していたためと考えられます」と書かないでください。
  監査員が記録した事実だけを evidence に引用してください。
- 指摘の重大性を評価しないでください。
  「重大な指摘です」「軽微な問題です」と書かないでください。
- 是正が有効かどうか、完了と見なせるかを判断しないでください。
- 報告書に書かれていないことを補わないでください。
  対象部門・監査日・監査員が読み取れない場合は null とし、
  needs_review に挙げてください。
- 指摘の根拠は、報告書の記述を原文のまま quote に入れてください。
  要約した文言で台帳に載せないでください。
- 良好事項(良い点として挙げられている記述)を指摘として扱わないでください。
  good_practices に分けてください。
- 1つの指摘に複数の問題が含まれている場合は、分けずに1件として扱い、
  複数の論点があることを notes に書いてください。
  あなたが分割の判断をしないでください。

【要求事項の一覧(規格の条項と社内規程の対応)】
{requirements_map}

【この部門の過去の指摘(直近2年)】
{past_findings}

【監査報告書】
監査の種類: {audit_type}
{report_text}

「区分をあなたが判断しないでください」の1行が、この構成の安全装置です。 不適合と観察事項の区分は、認証の維持に影響します。AIが「これは不適合に当たると考えられます」と書いた台帳が残ると、外部審査でその判断の根拠を問われます。

「1件の指摘を分割しない」も入れてください。 監査員が1件として起票したものを2件に分けると、件数が合わなくなり、部門との認識がずれます。

Step7

出力形式を固定する

{
  "report_id": "",
  "audit_type": "internal | external | customer",
  "audit_date": "",
  "auditor": "",
  "audited_department": "",
  "findings": [
    {
      "finding_no": "",
      "category": "不適合 | 改善の機会 | 観察事項 | null",
      "summary": "",
      "quote": "",
      "evidence": [],
      "clause_candidates": [],
      "related_past_findings": [
        { "finding_id": "", "audit_date": "", "summary": "", "similarity_basis": "" }
      ],
      "notes": []
    }
  ],
  "good_practices": [],
  "needs_review": [],
  "extraction_warnings": []
}

是正計画の確認:

{
  "finding_id": "",
  "plan_completeness": {
    "cause_analysis": "written | missing",
    "correction": "written | missing",
    "corrective_action": "written | missing",
    "due_date": "written | missing",
    "effectiveness_check_method": "written | missing"
  },
  "missing_items": [],
  "quote_of_plan": ""
}

quote(報告書の原文)を必ず残します。 台帳に要約だけが載ると、後から「監査員は何を見てそう書いたのか」を追えません。外部審査で指摘の根拠を説明する場面があります。

clause_candidates は「候補」です。確定ではありません。 事務局が確認して決めます。

plan_completeness は、是正計画に必要な5項目が書かれているかだけを見ます。 内容が妥当かどうかは判定しません。「原因分析が書かれていない計画」を差し戻すのは、機械的にできる作業です。

なお、Claude API には出力をJSONスキーマに沿わせる構造化出力の機能があります(2026-09-17時点ではベータ機能として提供)。項目が多い出力なので、利用できると形の崩れを防げます。

Step8

システムへ連携する

つなぐ先内容
SharePoint監査報告書の受け取りと保管
SharePoint リスト(台帳)指摘事項の登録と進捗の管理
Teams / Outlook部門への是正計画の依頼、期限の通知
過去の指摘台帳繰り返しの検出

台帳への登録は、事務局が区分と期限を決めてから行ってください。 切り出した直後に自動登録すると、区分が空の指摘が台帳に並びます。件数を数えるときに、それが何なのか分からなくなります。

期限の通知は自動化してよい部分です。 1週間前と当日、そして超過後は週1回。この通知があるだけで、期限超過は大きく減ります。

Step9

人が確認する

すべての指摘を事務局が確認します。

確認する点誰が
指摘の切り出しが監査員の意図と合っているか事務局(必要なら監査員に確認)
区分(不適合/改善の機会/観察事項)事務局・監査責任者
対象部門と責任者事務局
是正の期限事務局・部門
繰り返しの指摘かどうか事務局
是正計画の内容の妥当性事務局・監査責任者
是正の有効性監査責任者(次回監査で確認)

最後の2つは、この構成の外です。 規格が求める「是正処置の有効性のレビュー」は、記録を整理することとは別の行為です。台帳が整うことで、そのレビューに時間を回せるようになる、というのがこの構成の狙いです。

Step10

例外に対処する

起きること対応
報告書に区分の記載がないnull として人が決める。推測しない
指摘の切れ目が判断できない分割せず1件として扱い、notes に論点を書く
良好事項が指摘として切り出されたgood_practices に分ける。件数の水増しを防ぐ
対象部門が特定できない人へ回す。推測で部門を割り当てない
チェックリストの様式が監査員ごとに違う様式を統一する。できるまでは人が読む
外部審査の指摘と内部監査の指摘を同じ扱いにする種別で分ける。区分の体系が違う
過去の指摘台帳がない過去2年分から作る。なければ繰り返しの検出はできない
是正計画に必要項目が欠けているmissing_items を添えて差し戻す。内容の妥当性は人が見る
是正の期限が過ぎている週1回の通知を続ける。自動で完了にしない
同じ指摘が3回以上繰り返されている月次の一覧で強調する。マネジメントレビューの議題にする
顧客監査の指摘に機密情報が含まれる台帳の閲覧範囲を分ける
Step11

記録を残す

  • 監査報告書の原本(監査の種類・日付つき)
  • 切り出した指摘と、その原文
  • 事務局が切り出しを修正した内容と、修正前後
  • 区分・期限・担当の決定と、決めた人
  • 是正計画と、その確認結果
  • 是正の完了と、有効性のレビューの記録
  • 繰り返しの指摘の履歴

監査の記録は、認証の維持に必要な記録です。 保存期間は自社のマネジメントシステムの規定に従ってください。AIの処理に使ったコピーとは別に、報告書の原本が正本であることを明確にしてください。

「事務局が切り出しを修正した内容」の蓄積が、切り出しの精度を上げます。 「この監査員は指摘を箇条書きで書く」「この様式では備考欄に指摘が入る」といった傾向が見えます。

04実装レベルの3段階

最小構成:報告書を生成AIに貼り、指摘を切り出して管理表に貼る / 切り出し
半自動化:報告書の提出をきっかけに切り出し・条項の紐づけ・繰り返しの検出を行い、台帳に登録する / 上記+照合・登録
本格構成:上記+是正計画の記載不足の確認+期限の通知+月次の集計+マネジメントレビュー向けの資料 / 判断以外のすべて

本格構成に価値があります。 半自動化だけだと、台帳はできても期限の管理が手作業のまま残ります。期限超過をなくすことが、この業務の目的です。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
2 名
月間件数
15 件
1件あたり現在時間
120 分
1件あたり導入後時間
40 分
現在  15件 × 120分 ÷ 60 = 30 時間/月
導入後 15件 × 40分 ÷ 60 = 10 時間/月
月間削減時間
20h
削減率
67%
年間削減時間
240h
年間金額換算(時間単価3,500円)
84万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. マネジメントシステムの認証を受けていて、内部監査を年1回以上実施している企業。監査の記録が電子データで残っていること。指摘事項の是正を部門に依頼する運用があること。
向いていない
  1. 認証を受けておらず、監査の実施義務がない場合。部門数が5以下で、事務局が全指摘を把握できている場合。すでに指摘事項の管理機能を持つマネジメントシステム支援ツールを導入している場合。

07最小構成で試す方法

  1. 直近の内部監査の報告書を3部門分用意する
  2. 生成AIに貼り、指摘事項を1件ずつ切り出させる
  3. 事務局が管理表に転記した内容と比べる

見るのは次の4点です。

見る点判断
指摘の件数が合っているか合っていれば台帳化に使える
区分を勝手に判断していないかしていたら、プロンプトを強める。ここが最重要
原因を推定していないかしていたら同上
良好事項を指摘に混ぜていないか混ざっていたら件数が水増しされる

そのうえで、過去2年分の台帳を作ってください。

  1. 過去2年の報告書から、指摘を切り出して一覧にする(360件程度)
  2. 同じ部門で同じ内容の指摘が繰り返されている件数を数える

5で見つかる件数が、この構成を作る理由になります。 繰り返しの指摘が2割を超えるようなら、台帳がないことが是正の妨げになっていると言えます。

08実装時につまずきやすいポイント

問題対策
AIが指摘の区分を判断するプロンプトで禁止する。「不適合と考えられます」といった記述を機械的に検査する。最重要
AIが原因を推定する禁止する。原因分析は被監査部門の仕事
良好事項が指摘として台帳に入る分けさせる。件数が水増しされると部門の不信を招く
チェックリストの様式がばらばらで読めない様式を1つに統一する。技術より先に
1件の指摘が複数に分割される分割させない。監査員の起票単位を保つ
過去台帳がなく繰り返しが検出できない過去2年分から作る。1〜2週間かかるが1度だけ
区分が空のまま台帳に登録される事務局が決めてから登録する
期限超過に誰も気づかない週1回の通知を続ける。自動で完了にしない
外部審査と内部監査を同じ区分体系で扱う種別で分ける
台帳の閲覧範囲が広すぎる顧客監査の指摘は範囲を絞る

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 監査の記録、指摘事項、是正の状況、部門と担当者名。自社のマネジメントシステムの弱点が集約された情報です。

  1. 外部AIへの入力可否 … 監査の指摘は、自社の管理の不備を示す情報です。顧客監査の指摘には、顧客名と顧客固有の要求が含まれます。 自社の情報管理規程と、顧客との秘密保持契約を確認してください
  2. 個人の評価に使わない … 指摘の件数を、被監査部門の責任者や担当者の評価に直接結び付けないでください。指摘を受けないように監査で事実を隠す行動につながります。 内部監査は改善のための仕組みです
  3. 学習利用 … 入力を学習に使わないことが契約で保証されるサービスを選びます
  4. アクセス権限 … 台帳の閲覧を、事務局・監査責任者・当該部門に限定します。顧客監査の指摘は、さらに範囲を絞ってください
  5. 記録の完全性 … 監査の記録は認証の維持に必要です。AIが加工した内容を原本として扱わないでください。 台帳は管理のための派生物であり、正本は報告書です
  6. 審査での説明 … 外部審査で「指摘の管理をどう行っているか」を問われることがあります。AIが切り出した結果を人が確認している手順を、説明できる形にしてください
  7. 自動実行してよい範囲 … 切り出し・照合・通知・集計までです。区分の決定、是正計画の承認、有効性のレビューは、必ず人が行います

誤りが起きた場合のリスクは、指摘の見落としと、区分の誤りです。前者は是正されないまま次の監査を迎えることにつながり、後者は認証の維持に影響します。

10まず何から始めるか

1週目:監査報告書の様式を点検する

直近1年の報告書を開き、次を確認します。

  • 指摘事項の見出しが統一されているか
  • 区分(不適合/改善の機会/観察事項)が明記されているか
  • 良好事項と指摘が分けて書かれているか

統一されていないなら、様式を直すのが先です。 見出しを揃えるだけで、切り出しの精度が変わります。

2〜3週目:過去2年分の台帳を作る

過去の報告書から指摘を切り出し、一覧にします。繰り返しの指摘が何件あるかを数えてください。 この数字が、導入の理由になります。

4週目:3部門で切り出しを試す

直近の監査報告書3部門分で切り出しを試し、事務局の転記内容と比べます。区分の判断と原因の推定をしていないかを必ず確かめてください。

2か月目:期限の通知を作る

台帳ができたら、まず期限の通知だけを自動化してください。 実装が軽く、効果がすぐ出ます。

3か月目以降: 報告書の提出をきっかけとした切り出しと、月次の集計を追加します。120分が何分になるかを実測し、繰り返しの指摘の件数を追ってください。 それが減ることが、この構成の本当の成果です。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-09-17/最終更新:2026-09-17
確認した内容情報源確認日
n8n の Schedule Trigger が秒・分・時・日・週・月・cron式の7種類の間隔に対応し、セルフホスト版の既定タイムゾーンが America/New_York であることn8n Docs: Schedule Trigger2026-09-17
Claude API に、出力をJSONスキーマに沿わせる構造化出力の機能があること(2026-09-17時点ではベータ機能)Claude Platform Docs: Structured outputs2026-09-17
Claude のプロジェクトに参照用の文書をアップロードして会話の中で読ませられること(最小構成で要求事項の一覧を持たせる場合)Claude Help Center: What are projects?2026-09-17

内部監査の実施方法、指摘の区分、是正処置の要求は、取得している規格および認証機関の運用によって異なります。この部分は、自社のマネジメントシステムの規定と認証機関の指導に従ってください。 監査記録の保存期間についても同様です。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-0114)についてのご相談はこちらから。

AI活用について相談する
目次