AIやAIエージェントのPoCを実施した後、次の判断が難しくなることがあります。ツールは動いたものの、どの業務を変えるのか、何を評価すればよいのか、誰が拡大・修正・停止を決めるのかが曖昧な状態です。
この段階で必要なのは、AIの機能を追加で比較することだけではありません。対象を1本の業務フローに絞り、現在の流れ、目指す流れ、データと権限の条件、評価条件、次の決定を同じ記録に置くことです。
本稿は、PoC後にこの記録を作るためのワークショップを提案します。どの業務でPoCを始めるかを選ぶ方法や、KPIに基づくGo/No-Goの基準そのものを定める記事ではありません。PoCで得た出力を、次に設計・確認すべき業務の条件へ戻すための実務テンプレートです。
テンプレートは、IPAとデジタル庁の公開情報を踏まえた編集上の提案です。特定のPoCが業務設計の不足で停滞したこと、この手順がROIや本番展開を保証すること、読者需要や事業効果は示していません。
PoC後の整理に使える公開情報と、本稿の提案
事実：IPAは現状の共有から施策と進捗管理へつなげる考え方を示している
IPAのDX推進指標に関する公式説明では、経営者、事業部門、DX部門、IT部門が現状と課題の認識を共有し、行動へつなげることが扱われています。そこでは、根拠・エビデンスを添えた現状把握、あるべき姿とのギャップと原因の分析、KPI・マイルストーン・体制・予算・責任者・期限を含む具体策の設定、進捗管理と見直しという流れが示されています。
これはAIエージェントのPoC専用手順ではありません。また、個別企業が特定のKPIや業務フローを採用すべきことを示すものでもありません。
事実：デジタル庁は行政の実装文脈で、ツール利用と業務・データの設計を区別している
デジタル庁のガバメントAI「源内」ページは、行政における生成AIの試験的利用では、機密情報を扱えない環境で業務上の有効性を検証しにくいことを説明しています。また、実務データをAIが参照できる状態にすることを、行政へのAI実装の前提条件として扱っています。
同ページでは、汎用的なチャットツールの利用にとどまることと、AIを前提に業務・データのあり方を考える取組が区別されています。これは行政の取組に関する事実であり、民間企業のすべての業務に同じ条件が当てはまることを意味しません。
本稿の提案：PoCの結論を出す前に、業務の判断材料を1枚に集める
上記の公開情報を踏まえ、本稿では次の実務上の提案を置きます。PoC後の検討では、AIを入れたかどうかだけで評価せず、1つの業務について現状、目標、データ・権限条件、評価条件、責任者、決定日を記録します。
この提案は、複数社で成果が確認された普遍的な方法ではありません。自社の業務影響、扱う情報、利用可能な記録に合わせて調整してください。
ワークショップの準備：対象は1業務、参加者は判断できる人に絞る
最初に、対象を1つの業務フローへ限定します。例えば、問い合わせ対応全体ではなく、受付後に担当部署の候補を作る工程だけを対象にします。対象が大きすぎると、AIの出力、確認者、例外対応、評価条件が一枚に収まりません。
参加者は、少なくとも次の役割を明確にします。
| 役割 | ワークショップで決めること |
|---|---|
| 業務責任者 | 業務の完了条件、対象範囲、許容できない影響 |
| 現場担当者 | 現在の入力、判断、例外、引き継ぎの事実 |
| AI・IT担当者 | 使えるデータ、連携、権限、技術上の制約 |
| 決定責任者 | 拡大、修正、停止、追加検証の最終判断 |
この役割分担は、公開資料が特定の組織編成を定めたものではありません。誰が何を確定するかを曖昧にしないための記入例です。
記入テンプレート：AS-ISから次の決定までをつなぐ
以下を同じ表に記入します。空欄が残ることは失敗ではありません。空欄は、次の決定前に確認すべき事実として扱います。
| 項目 | 記入する内容 | 確認する問い |
|---|---|---|
| 対象業務 | 開始条件と完了条件が説明できる業務の一部 | どこからどこまでを今回扱うか。 |
| AS-IS | 入力、判断、出力、確認者、例外、引き継ぎ | 実際には誰が何を根拠に判断しているか。 |
| TO-BE | 変えたい業務上の状態。AIを使わない選択肢も含める | 何が変われば業務として前進したと言えるか。 |
| AIの役割 | 要約、候補提示、照合、下書きなど | 出力は提案か、確定処理か。 |
| データ条件 | 参照元、更新頻度、欠損、機密性 | AIが参照できる形で必要な情報があるか。 |
| 権限・安全条件 | 利用者、閲覧範囲、承認、対象外 | 誰がどの情報を扱えるか。 |
| 評価条件 | 確認したい品質、時間、保留、例外の記録 | 何を見れば次の判断を説明できるか。 |
| 決定 | 拡大、修正、停止、追加検証の候補 | 誰が、いつ、どの記録を見て決めるか。 |
重要なのは、TO-BEをAI導入そのものにしないことです。例えば、TO-BEを「担当者が必要情報を確認して適切な部署へ渡せる状態」と書けば、AIは候補提示、ルール整備、入力フォーム変更など複数の手段の一つとして比較できます。
進め方は4段階でよい
1. AS-ISを事実で書く
現在の手順を、期待や理想ではなく、実際の流れとして書きます。
| 観点 | 記入例 |
|---|---|
| 入力 | 共有受信箱に届く問い合わせ文と添付資料 |
| 判断 | 受付担当者が内容を読み、担当部署の候補を考える |
| 出力 | 担当部署への転送と、必要情報の確認依頼 |
| 確認 | 受付担当者が転送先を確定する |
| 例外 | 内容が不足している、複数部署にまたがる、緊急度が不明 |
この表で、すでにある判断基準、入力不足、例外処理を分けて残します。業務上の推測を事実のように書かないため、確認できない箇所には「未確認」と記します。
2. TO-BEを業務の状態として書く
次に、変えたい状態を短く書きます。AIの採用を前提にせず、業務の完了条件から考えます。
| 書き方 | 例 |
|---|---|
| 避けたい書き方 | 問い合わせ対応をAI化する |
| 状態で書く例 | 受付担当者が、必要情報の不足と担当候補を確認でき、定めた手順で引き継げる |
この差により、AIの出力が役立ったかだけでなく、業務全体のどこが変わったかを確認しやすくなります。
3. データ・権限・引き継ぎの条件を先に出す
デジタル庁の行政実装の説明は、AIが参照可能な実務データの準備を前提として扱っています。この点を民間の各業務へそのまま当てはめることはできませんが、少なくともデータと利用条件をPoCの評価から切り離さない参考になります。
| 条件 | 記入すること |
|---|---|
| 参照データ | AIに見せる情報源と、見せない情報源 |
| 更新 | 情報が更新される場所と頻度 |
| 権限 | 利用者、閲覧者、承認者の範囲 |
| 不足時 | 入力不足や参照不能時に出す保留・確認依頼 |
| 引き継ぎ | AIの出力後に誰が確認し、どこへ渡すか |
ここで条件が決まらない場合、AIの精度だけを比較しても、業務として使えるかを判断する材料が不足しやすくなります。追加で確認する条件と担当者を残してください。
4. 次の行動を4択で記録する
会議の最後に、次の候補を記録します。この4択はIPAやデジタル庁がAI PoC向けの判定区分として提示したものではなく、次の行動を曖昧にしないための編集上の整理です。
| 次の行動 | 選ぶときの記録 |
|---|---|
| 拡大する | 広げる範囲、維持する確認、追加で必要な条件 |
| 修正する | 変える対象範囲、データ、手順、確認方法 |
| 停止する | 停止理由、戻す業務手順、残す学び |
| 追加で事実を集める | 未確認の項目、収集方法、担当者、判断日 |
数値基準やGo/No-Goの結論は、この記録を基に別途定めます。本稿では、次の判断を可能にする業務設計上の事実を残すことを優先します。
仮想例：問い合わせの担当候補を作る工程
以下は仮想例です。MASTER keyまたは顧客企業の実績ではありません。
ある組織が、社内外から届く問い合わせについて、受付担当者が担当部署の候補を作る工程を見直すとします。
| 項目 | 仮想例での記入内容 |
|---|---|
| 対象業務 | 受付後、担当部署の候補を作るまで |
| AS-IS | 受付担当者が本文と添付を読み、過去の経験をもとに候補を判断する |
| TO-BE | 必要情報の不足と候補部署を確認してから引き継げる |
| AIの役割 | 問い合わせの要約、不足情報の指摘、候補部署の提示 |
| 人の確認 | 受付担当者が候補を確認し、転送先を確定する |
| データ条件 | 部署の役割一覧と問い合わせ分類の参照可否を確認する |
| 対象外 | 顧客への回答送信、契約判断、個人情報を含む判断 |
| 評価条件 | 候補をそのまま採用できた理由、修正理由、保留理由を記録する |
| 決定 | 2週間後に業務責任者が記録を確認し、対象範囲を維持・修正・停止・追加検証から選ぶ |
この例では、AIが候補を出すことを業務の完了にしていません。人が確認して引き継げる状態を業務上の目的に置いています。そのため、AIの出力だけでなく、入力不足、部署情報の更新、確認負荷も次の判断材料になります。
会議の最後に残す決定メモ
ワークショップ後は、次のメモを残します。決定日を空欄にしないことがポイントです。
| 記録項目 | 記入内容 |
|---|---|
| 今回確認できた事実 | |
| 未確認の条件 | |
| 今回は採用しない前提 | |
| 次に集める記録 | |
| 次の行動 | 拡大・修正・停止・追加検証 |
| 決定責任者 | |
| 次の判断日 |
判断を保留する場合も、保留だけで終わらせず、何を確認すれば決定できるかを記録します。そうすれば、PoCの議論をツールの印象論へ戻さず、業務上の条件として引き継げます。
MASTER key AX事業部が本稿で提示する視点：AI活用を業務・データ・意思決定につなぐ
MASTER key株式会社のAX事業部は、本稿で、AI活用をツール導入だけで完結させず、対象業務、データと権限、確認・引き継ぎ、評価、次の意思決定までをつなげて考える視点を提示します。
この視点が、どの業種・組織・PoCにどの程度役立つかは未検証です。本稿はMASTER keyの顧客成果や独自性を示すものではありません。まずは1業務を選び、AS-IS、TO-BE、条件、判断日を同じ一枚に書き出してみてください。