経営者のための、会社を90日でAIファーストに変える計画

1. 利益を生むAIファーストは、運営モデルから始まる

AIファーストという言葉は使い古されていて、全員にツールを買い与え、あとは自然に良くなるのを待つ、という形で終わることがよくあります。差がつくのは、損をしているとわかっている業務プロセスを1つ選び、効果を測れるところまで改善するかどうかです。

社員にツールを配れば、一人ひとりの生産性は上がるかもしれません。それでも会社の手順も、仕事の受け渡しも、人数も以前のままです。組織としてのAIファーストとは、データが自動で流れ、定型的な仕事はシステムが処理し、人は例外と成果に責任を持つように業務プロセスを設計することです。

90日で全部署を変えると約束するのはやめましょう。現実的な目標は、1つか2つのワークフローを本番環境で実証し、データ、セキュリティ、効果測定の標準をつくり、次のプロジェクトの候補（パイプライン）をそろえることです。こうすれば、研修を1回開いて終わりにならず、会社に変わり続ける力が残ります。

2. 日数を数え始める前に決める5つの経営原則

初日を迎える前に、2つのことを合意しておきます。成功かどうかを判断する数字は何か、そしてその数字が出なかったときにプロジェクトを止める権限は誰にあるかです。この2点があいまいなままだと、90日は言い争いで終わります。

1. 事業の成果から始める：どのユースケースも、売上、コスト、スピード、リスクのいずれかに結びつけます。デモが面白そうだからという理由では承認しません。
2. 一度に1つの業務プロセス：仕事の流れを端から端まで1本選びます。小さなツールをあちこちに作って、効果を測れなくなるような進め方はしません。
3. 責任は人が負う：AIには責任を問える立場がありません。KPIとインシデントの責任は、引き続き業務プロセスの責任者が負います。
4. 設計段階からのセキュリティ：権限、データ、ログ、システムに許す操作の範囲は、本番運用の前に決めておきます。
5. 根拠をもとに広げる：品質とROIが基準を満たしたら、利用者、権限、予算を増やします。周囲からのプレッシャーで広げることはしません。

小さなステアリングチームをつくります。メンバーは経営者かスポンサー、業務プロセスの責任者、そしてデータ、技術、セキュリティの担当者です。意思決定の会議は決まったリズムで開きます。全員に拒否権があるのに誰も結果に責任を負わない、大きな委員会は避けてください。

3. 1〜15日目：ベースラインを測り、最初に取り組む領域を選ぶ

1〜5日目：事業の目標を発表します。たとえば、人を増やさずに50%多い仕事量をこなす、顧客への回答時間を4時間から20分に縮める、といった目標です。使ってよいデータとツールの範囲を暫定的に決め、安全に試せる場を用意して、シャドーAIを防ぎます。

6〜10日目：各部署に業務プロセスを3つまで提案してもらい、件数、時間、コスト、責任者も添えてもらいます。それを仕事量、データの準備状況、結果を確認しやすいかどうか、リスクで採点し、メインのプロジェクトを1つ、予備を1つ選びます。

11〜15日目：業務フロー図を描き、実際の作業を計測し、50〜100件のサンプルを集めて、低・中・高のビジネスケースを作ります。目標は測れる形で書き、品質とコストのガードレールも含めます。システムが何をし、人が何を確認し、どんなときにすべてを止めるのかを決めます。

4. 16〜30日目：仮説を検証する試験導入をつくる

まずシャドーモードで始めます。システムに実際の仕事を受け取らせ、社員と並行して結果を出させますが、外部への送信や操作はまださせません。回答、所要時間、ミスの種類を比べます。過去のデータだけでテストしても不十分です。生のデータの状態や利用者の行動が見えないからです。

評価セットを作り、標準的なケース、情報が欠けたケース、くだけた言葉づかい、食い違う情報、リスクのあるケースを入れます。正確さは「答えが良さそうに見える」という感覚ではなく、仕事の基準で測ります。たとえば5つの項目がすべて埋まっている、価格を正しいシステムから引いている、正しい承認ルートを選んでいる、といった基準です。

この期間は、要望があるたびに機能を足すのは禁物です。要望を、KPIに必要なもの、安全のために必要なもの、後回しにできる便利機能に分けます。中心となるやり方に価値があるのかどうかの答えを出すために、プロダクトオーナーは範囲を守らなければなりません。

5. 31〜60日目：試験導入を、責任の所在がはっきりした本番運用に切り替える

41〜50日目：少人数の利用者グループに公開します。システムが下書きを作り、毎回人が承認します。フィードバックは、データの誤り、ルールの誤り、不適切な言葉づかい、連携元のシステムの準備不足といった種類ごとに集めます。何でもプロンプトの修正で済ませず、原因のほうを直します。

51〜60日目：数週間分の実績で裏づけられた標準的なケースに限って、人を介さず最後まで処理する自動完結の運用を始めます。自動処理した仕事は抜き取りでチェックし、インシデント対応訓練を行って、チームがシステムを止め、経緯をさかのぼって確認し、手作業で仕事を続けられるかを試します。

SOPと職務記述書も、これに合わせて更新します。社員が「念のため」に毎回古い手順を繰り返しているなら、節約の効果は生まれません。新しいチェックポイントを合意し、システムが安定したら、並行して作っていたファイルやレポートは廃止します。

6. 61〜90日目：価値を回収し、規律を保って広げる

71〜80日目：権限の仕組み、コネクター、テンプレート、評価、監視、承認の手引きといった、再利用できる部品（Reusable Components）を作ります。データとチェンジマネジメントについての教訓も書き残し、次のプロジェクトがゼロから始まらないようにします。

81〜90日目：次のユースケースはデータをもとに選びます。今の業務プロセスの対象範囲を広げる方法もあれば、プレイブックを別の部署に持ち込む方法もあります。ポートフォリオをNow・Next・Laterに整理し、責任者のいないプロジェクトやROIの見込めないプロジェクトは断ります。

7. 中堅企業に必要なチームとガバナンス

大きなAI部門をつくる必要はありません。ただし、どのシステムにも業務の責任者（Business Owner）、技術の責任者（Technical Owner）、データの責任者（Data Owner）が必要で、リスクを承認する人とインシデントの報告を受ける人も名前で決めておきます。外部の開発会社を使う場合でも、業務とデータについての責任は社内に残さなければなりません。

AIシステムの台帳を作り、システムごとに責任者、目的、データ、モデル、権限、提供元、費用、見直しの日付を記載します。誰も管理しないままツールが広がるのを防ぐためです。社員が辞めたりベンダーが変わったりしても、どのシステムが何をしているのかを会社が把握し続けられます。

8. 経営者が毎月見るべきダッシュボード

AIシステムを1つずつ見直し、拡大（Scale）、改善（Improve）、廃止（Retire）のどれにするかを決めます。どのシステムにもライフサイクルが必要で、月額料金が小さく見えるからといって動かしっぱなしにすべきではありません。利用者も成果もないシステムは止めます。そうすれば、リスクにさらされる範囲も、見えないコストも小さくなります。

まとめ：会社が業務プロセスを1つに絞り、ベースラインを測り、シャドーモードで試し、本番運用の前に管理の仕組みを整え、稼働後に価値を回収するなら、AIファーストの力を築くのに90日で足ります。ツールの導入数を目標にするのではなく、定型的な仕事をシステムが処理し、人が例外、判断、新しい取り組みを担う運営モデルを目指してください。