AI戦略を1枚にまとめる：企業が決める6項目と90日計画

AI戦略では、どの業務を変えるのか、どんな成果を目指すのか、どこまでを許容するのかを明確にします。従業員10〜200人の企業なら、まず6つの意思決定を行い、今後90日間で取り組む1つのワークフローに予算と人員を割り当てるところから始めましょう。

取締役会から戦略を求められたら、評価できる形で方針を示します。目指す事業成果は何か、誰が責任を持つのか、どこまで投資するのか、どのような証拠があれば中止するのか。業界動向をまとめたプレゼンテーションだけでは、こうした問いには答えられません。

AI戦略とは何を決めるものですか？

AI戦略とは、事業のどこにAIを取り入れ、その貢献をどう評価するかについて、企業として選択することです。事業機会に対して、必要なリソース、責任分担、運用上の制約を結び付けます。モデルは下書きや提案を生成するAIのエンジンです。一方、ワークフローには、それを取り巻く人、データ、管理の仕組みまで含まれます。

新しいメンバーの職務を定義する場面を思い浮かべてください。担当する仕事、閲覧できる情報、判断してよい範囲、成果物を確認する人、良い仕事の基準を決めます。仕事を定義する前に、あらゆるシステムへのアクセス権を渡すのは適切なマネジメントとはいえません。AIにも同じ考え方が当てはまります。

戦略では、取り組む業務とトレードオフを決めます。ロードマップでは、実装の順序と日程を定めます。従業員向けの利用ポリシーでは、日々の業務で何をしてよいかを説明します。相互に整合させつつ、それぞれの役割を明確にしておきましょう。

実証実験の先にある事業の姿も考える必要があります。納品の迅速化が利益率の維持につながるのか、顧客がお金を払う対象を変えるのか、新たなサービスを可能にするのか。AIネイティブ企業のガイドでは、こうした事業運営モデルの変化を扱っています。当面の戦略では、その一部分を具体的に検証します。

AI戦略の具体例：サービス企業とソフトウェア企業では何が違いますか？

適切な戦略は、どの業務が事業の制約になっているかによって変わります。サービス企業なら、見込みのある商談に向けた提案書を作成する余力が必要かもしれません。ソフトウェア企業なら、顧客が利用開始に必要な設定、つまりオンボーディングを完了できるようにすることが課題かもしれません。

ここでは、従業員30人のサービス企業と従業員80人のソフトウェア企業を例に考えます。両社の設定、業務量、以下のリソース配分は、計画の立て方を示すための仮定です。顧客の実績でも、将来の成果予測でもありません。ソフトウェア企業の例で使う「インポート時のマッピング」とは、顧客のファイルにある項目を、アプリケーション側の項目に対応付けることです。

各行について、対象業務、判断の根拠、責任者、許容範囲を具体化すると、これらの選択が戦略になります。

AI戦略を組み立てるための6つの意思決定

実装を依頼する前に、事業の言葉で方針を決めます。各項目は短い段落で説明できる長さにまとめ、根拠となる資料は1枚の意思決定記録からリンクで参照できるようにします。

1. 改善する業務と、その影響を測る損益項目を選びます

すでに管理している費用や売上の項目に影響するボトルネックを選びます。「生産性を向上する」だけでは、役に立つプロジェクトと、単に人気のあるツールを区別できません。

候補となるワークフローについて、開始のきっかけから、成果物が受け入れられるまでの流れを整理します。作業時間、待ち時間、手戻り、完了を判断する人を明らかにします。そのうえで、事業上の価値、発生頻度、データの利用可能性、品質を確認できるか、誤りが及ぼす影響を比較します。責任者がいない、あるいは必要なデータを利用できない場合は、期待効果が大きくても実証実験を始めるべきではありません。

サービス企業の場合： 承認済みの顧客要件書と、再利用できるサービス説明から提案書の下書きを作る業務を対象にします。測定する損益項目は、見込みのある商談向けの提案書1件当たりの営業工数です。もう1つの仮説として、提案の迅速化が案件獲得の競争力を高める可能性もあります。この2つは別の主張なので、別々に測る必要があります。

この企業が月20件の提案書を作成し、1件に3時間かかるとします。AIを使った下書き、レビュー、修正の合計が1.5時間になれば、生まれる余力は次のとおりです。

20 × (3 - 1.5) = 30時間／月。

これは検証すべきシナリオです。生まれた余力を有望な商談に振り向ける、支出を回避する、サービス提供の採算を改善するといった行動につなげて初めて、財務的な価値になります。人件費の削減や受注の増加に、自動的につながるわけではありません。

ソフトウェア企業の場合： 顧客ファイルの不統一な項目名を解釈し、設定要件に基づくチェックリストを作る業務から始めます。形式が固定され、扱い慣れたファイルは、通常のインポートルールで処理します。費用面ではオンボーディングの作業工数を測ります。売上面の仮説は、設定時の遅延が減ることで、顧客が最初の有用な成果に到達しやすくなるというものです。

月40件のオンボーディング業務に、1件90分かかるとします。確認と修正を含む総作業時間が60分になれば、このシナリオで生まれる余力は次のとおりです。

40 × (90 - 60) / 60 = 20時間／月。

顧客が設定を完了したか、その後も利用しているかは、別々に測定します。社内の準備作業が速くなっただけでは、顧客の継続率が改善した証拠にはなりません。

決定事項の書き方：「［ワークフロー］を改善し、［事業指標］を変えます。［現在の基準値］と比較して測定し、［品質条件］を守ります。」AIのROIガイドでは、観測した業務の変化から、根拠を説明できる価値の計算へつなげる方法を解説しています。

2. AIが承認なしで行ってよいことを決めます

誤りによって顧客への確約が生じる、情報が漏れる、顧客データが変更される可能性がある場合は、まず支援用途から始めます。支援とは、AIが提案を用意し、採用するかどうかを人が判断することです。自動化とは、定められた操作を、都度の承認なしにシステムが実行することです。

自動化には、より厳しい条件を設けます。結果を確実に確認できること、影響を限定できること、操作を取り消せることです。これらは候補を絞るための条件であり、満たしていても、実証実験の成功や責任者の明確化は別途必要です。ソフトウェアでも適切な知識を持つ人でも出力を確認できないなら、その用途は見送ります。

サービス企業の場合： AIには文章の下書きと不足情報の洗い出しを任せます。業務範囲、納品に関する確約、最終的な提案書は、顧客担当責任者が承認します。実証実験中は、システムによる提案書の送信、署名、取引条件の変更を認めません。将来の自動化候補としては、提案内容の交渉よりも、承認済みの文書を正しいフォルダーに保存する作業のほうが適している可能性があります。

ソフトウェア企業の場合： AIは、顧客の「Company」項目をアプリケーションの「Organization」項目に対応付ける案を提示できます。オンボーディング担当者が対応関係を確認し、必須項目や形式は通常のソフトウェアで検証します。インポートの実行と本番データの変更には、既存の承認プロセスを適用します。取り消し可能なステージング環境の設定であれば、検証と復旧が機能すると実証できた後に、自動化の対象にできるかもしれません。

リスクを分けるのは、画面がチャットボットに見えるかどうかではなく、誤りが何を引き起こせるかです。操作を実行できない下書きと、書き込み操作につながるシステムでは、運用上の許容範囲が異なります。

決定事項の書き方：「AIは［この操作の準備または実行］を行えます。［これらの操作］には、指定した担当者の承認が必要です。システムは［対象外の操作］を決して行ってはいけません。」

3. 自社開発・製品導入・既存製品の設定から選びます

標準的な機能で要件を満たせるなら、購入します。業務固有の価値を生む部分は、継続して保守できる範囲で自社開発します。既存のアプリケーションが業務に適していて、承認済み文書、ルール、接続先を整えれば使えるなら、設定で対応します。

「自社開発」は、モデルの学習を意味するとは限りません。モデルへのアクセスを購入し、その周りのワークフローを作ることもできます。どのように情報を渡すか、提案をどう検証するか、利用者がどう操作を承認するか、といった仕組みです。

いずれの方法も、同じ受け入れ条件で比較します。権限を維持できるか、レビュアーに必要な根拠を提示できるか、記録をエクスポートできるか、代替手段に切り替えられるかを確認します。連携、評価、従業員研修、インシデント対応、継続的な保守も比較に含めます。運用責任者のいない試作品では、自社開発を選ぶ根拠として不十分です。

サービス企業の場合： 承認済みのデータ利用範囲とレビュープロセスに沿って動作するなら、文章作成アプリケーションを購入して設定します。承認済みの参照資料と提案書チェックリストは、別の環境へ移せる状態にしておきます。顧客データの制約を満たせない製品は、デモが魅力的でも採用できません。使用データを減らす、実現方法を変える、または導入を見送ります。

ソフトウェア企業の場合： モデルへのアクセスを購入し、顧客ごとのマッピング画面、認可チェック、検証機能、承認記録を自社開発します。これらはアプリケーション固有のオンボーディングの仕組みを表すため、プロダクトに近いところで実装します。モデルとの接続部分は交換可能にし、提供事業者を変更してもオンボーディング全体を作り直さずに済むようにします。

**自社開発へ判断が変わるのは、**標準製品では価値のある要件を満たせず、独自の仕組みを継続して運用・保守する費用を自社で負担できる場合です。自社ブランドのAIが欲しいというだけでは、その要件にはなりません。

決定事項の書き方：「［具体的な要件］を理由に、［製品導入／設定／自社開発］を選びます。［責任者］が保守し、［撤退・移行方法］によって業務を復旧できる状態を保ちます。」

4. 用途ごとに必要なデータとアクセス権を定めます

各用途には、その作業に必要な情報と権限だけを与えます。「社内データを接続する」では範囲が広すぎて、許可する判断ができません。

データの出所、利用できる人、業務に必要な項目、保守する人を記録します。提供事業者に送信してよい情報、保存や学習への利用の可否、削除方法、ログに残す内容を決めます。社内データを使う前に、選んだサービスの現行の規約と管理機能で、これらの要件を満たせるか確認します。利用契約が承認されていても、あらゆる文書をアップロードしてよいことにはなりません。

情報を読む権限と、操作を実行する権限も、分けて判断します。Open Worldwide Application Security Project（OWASP）の過剰な自律性に関するガイダンスでは、機能と権限を制限し、影響の大きい操作には承認を求め、後続のシステムで認可を強制することを推奨しています。モデルに「他の顧客の情報へアクセスしないで」と指示しても、アプリケーション側でアクセスを防ぐ仕組みの代わりにはなりません。

サービス企業の場合： 対象顧客の承認済み要件書、承認済みのサービス説明、再利用が認められた事例を使います。他の顧客の機密提案書や、従業員の非公開メモは除外します。アクセスは、その顧客を担当する権限のある従業員に限定します。下書きでは、事実に関する記述の出典を示し、レビュアーが確認できるようにします。裏付けのない記述は修正に戻します。

ソフトウェア企業の場合： 対象顧客の項目名と、対応関係を理解するために必要最小限のサンプル値を使います。不要な個人データはマスキングします。検索インデックスも含め、現在の顧客アカウントに認められた権限の範囲で情報を取得します。認証用の秘密情報や他の顧客の記録は、モデルのコンテキストに入れません。実証実験では対応付けの案を提示するだけにとどめ、本番データを更新する権限は与えません。

どちらの例でも、拒否すべき要求、参照資料が欠けている場合、資料が古くなっている場合をテストします。正しく答えられた例だけでは、アクセスや利用の制限が機能していることは示せません。

決定事項の書き方：「この用途では、［権限を持つ利用者］のために［データソースと項目］を読み取り、［保存ルール］を適用します。書き込み先は［対象、または書き込み不可］に限定します。変更は［データ責任者］が承認します。」

5. 成果とリスクに責任を持つ人を指名します

会社としての戦略上の選択にはCEOが責任を持ち、変更が現場で機能するかどうかには業務責任者が責任を持ちます。実装上の管理機能は技術担当者の責任です。レビュアーには、出力を却下できる専門知識、時間、権限が必要です。

National Institute of Standards and Technology（NIST）のAI Risk Management Frameworkのコアは、リスクへの取り組みを、ガバナンス、状況の把握、測定、管理に整理しています。AIリスクに関する意思決定を経営層の責任とし、監督体制を明確にするよう求め、導入前および運用中のテストを推奨しています。これらは継続して担う責任として扱います。

本記事で引用したNISTとOWASPのガイダンスは、2026年10月26日に両者の一次資料で確認しています。6つの意思決定という構成と企業の例は、本記事が実務向けにまとめたものであり、認証の枠組みではありません。

サービス企業の場合： 営業部門の責任者が、提案書の作成所要時間と品質に責任を持ちます。顧客担当責任者は、業務範囲と顧客に提出する文書を承認します。業務運営の責任者は、アクセス権と承認済みの参照資料を管理します。残るリスクを受け入れられるか、より多くの業務をこのプロセスへ移すかは、CEOが判断します。

ソフトウェア企業の場合： カスタマーサクセス部門の責任者が、オンボーディングの成果に責任を持ちます。指名されたエンジニアは、認可、検証、監視、復旧を担当します。オンボーディング担当者が提案をレビューします。社内の実証実験で顧客向けに公開できるだけの根拠が得られたかは、プロダクト責任者が判断し、会社としてのリスクの取り方にはCEOが責任を持ちます。

小さな会社では同じ人が複数の役割を担うこともありますが、職務は明示しておきます。誰が業務を一時停止できるか、誰がインシデントに対応するか、誰が再開を承認できるかを記録します。承認者を指名しても、根拠を確認する時間がなければ、管理に必要な人員を配置したことにはなりません。

より広い管理事項の記録にはAIガバナンスのフレームワークを、従業員の日常的な行動指針にはAIの許容利用ポリシーを活用します。システムが間違えたときの対処も含め、実際に業務を行う人に新しい責任を説明します。

決定事項の書き方：「［担当者］が成果に責任を持ち、［担当者］が影響の大きい業務を承認し、［担当者］が管理機能を維持します。［担当者］がプロセスの停止と再開を判断できます。」

6. 予算、レビューの頻度、中止条件を決めます

範囲を限定した検証に資金を配分し、根拠が得られたら追加のリソースを投入します。支出の上限に加え、従業員が使える時間も予算に含めます。ソフトウェアをすでに利用できる場合でも、レビュー、修正、研修、保守には人の時間がかかります。

サービス企業の場合： 配分の例として、90日間で業務運営担当者の作業時間を40時間確保し、設定、参照資料の整備、研修、評価に充てます。通常の提案書レビューには別途人員を確保し、工数も分けて測定します。営業部門の責任者は毎週、作成所要時間、総工数、業務範囲の修正、生まれた余力の使い道を確認します。CEOは毎月、資金配分の判断を見直します。

ソフトウェア企業の場合： 実証実験期間の配分例は、エンジニアの作業を10人日、オンボーディング担当者の作業を週2時間です。有料サービスを有効にする前に、支出上限を財務担当者に伝えます。このエンジニアの工数は、範囲を絞った社内実験のためのものです。本番機能には、別途見積もりが必要です。オンボーディングの総工数、マッピングの誤り、顧客の設定完了状況、アクセス制御の不具合を毎週レビューし、経営層が毎月判断します。

どちらの例でも、開始前に次の判断基準を合意します。

• 拡大： 代表的な業務で、事前に合意した品質と権限の要件を満たし、レビューと修正を含めても総工数が改善し、責任者が拡大後の範囲を支えられる場合です。
• 修正： 取り組みには効果があり、参照資料の改善や対象業務の絞り込みなど、具体的な修正によって、残りの予算と人員で目標を達成できる見通しがある場合です。
• 中止： 確認作業のコストを含めると効果が消える、必要なデータを利用できない、運用上の制約を守れない場合です。無許可のアクセスや操作があれば、直ちに一時停止します。

サービス企業は、作業が速くなっても、業務範囲に重大な誤りが入り込むプロセスを採用すべきではありません。ソフトウェア企業は、デモが滑らかに動いても、他の顧客のデータが漏れるなら採用すべきではありません。生成量が増えても、どちらの問題も埋め合わせられません。

決定事項の書き方：「［レビュー日］まで、［支出上限］と［人員・工数］を認めます。［根拠］が得られたら拡大し、［修正可能な不足］があれば修正し、［条件］に該当したら中止します。」

90日間のAIロードマップ：意思決定から検証まで

90日間は、投資を続けるかどうかの判断材料を得るために使います。予定の日程を終えただけでは、拡大してよい理由にはなりません。ここで示す期間は計画上の目安です。前提条件が欠けていれば、前の段階にとどまることもあります。

1. 1

   1〜30日目：計画を合意し、現状の基準値を把握します

   経営層のスポンサー、業務責任者、技術責任者、レビュアーを指名します。現在のプロセスを整理し、レビュー、修正、例外対応を含む仕事全体を測定します。AI導入準備度の診断を使い、この業務に必要なデータ、権限、運用支援の不足を洗い出します。

   サービス企業では、利用が認められた要件書、最終提案書、工数記録、業務範囲を修正した事例を集めます。ソフトウェア企業では、利用承認済みのオンボーディング事例、マッピングの判断、設定完了の記録、インポートの失敗例を集めます。きれいに整ったデモだけでなく、扱いにくい事例も含めます。

   6つの意思決定、品質チェックリスト、人員・工数の配分、支出上限について合意します。影響を受ける従業員に、どの仕事が変わるのか、意見をどう活用するのか、生まれた余力を何に充てるのかを伝えます。

   次の段階へ進むための根拠： 署名済みの意思決定シート、比較に使える基準値、利用承認済みのデータ、合格する結果の条件を説明できるレビュアーです。そろわなければ、次の期間も不足を埋めるために使います。

2. 2

   31〜60日目：管理された範囲で実証実験を行います

   まず過去の事例を使い、提案したワークフローを評価します。評価用の事例は設定に使う事例とは分けておき、システムを調整した際の例だけが高く評価される状態を避けます。その後、元のプロセスを代替手段として残しながら、承認された範囲で実際の業務に使います。

   サービス企業では、社外へ出す前にすべての下書きをレビューします。裏付けのない記述、要件の抜け、業務範囲の変更、総工数を記録します。ソフトウェア企業では、担当者が対応付けの案をレビューし、通常のインポート検証を適用し、他のアカウントのデータにアクセスできないことをテストします。

   通常の事例、判断を誤らせる提案、エスカレーションが必要な事例を使って、利用者をトレーニングします。修正とエスカレーションの手順を、実際に示してもらいます。通常業務の中でレビューを無理なく行えるかを観察します。

   次の段階へ進むための根拠： 採用・却下した事例、測定したレビュー工数、例外の記録、実際に機能すると確認できた一時停止の方法です。説得力のあるデモだけでは足りません。

3. 3

   61〜90日目：拡大・修正・中止を判断します

   途中で断念した試行や手戻りも含め、同じ条件の業務を基準値と比較します。事例の難易度や業務量が変わった場合は、その違いを説明します。実証実験の規模が小さく、主張を裏付けられない場合は、不確実性を報告します。

   サービス企業では、生まれた提案書作成の余力が活用されたか、品質が保たれたかを確認します。受注結果を追跡しつつ、あらゆる変化をAIの効果とはみなしません。ソフトウェア企業では、担当者の工数削減と、顧客が実際に価値を得られる利用段階に進むことを区別します。後者には、独立した裏付けが必要です。

   90日目のレビューでは、次に取り組む具体的な範囲への予算投入、範囲を限定した修正、実証実験の終了のいずれかを決めます。拡大する場合は、新たな利用者、データ、操作について、権限と品質をあらためて確認します。社内向けアシスタントが機能していても、顧客向けのオンボーディング機能を公開するかどうかは、別のリリース判断です。

   この段階で残す根拠： 記録された意思決定、責任を持つ担当者、更新された制約、次のレビュー日です。

今すぐ始めるべき場合、待つべき場合、既存の方法を続けるべき場合は？

繰り返し発生する業務、測定可能な課題、利用が許可された入力情報、結果を確認できる人がそろっていれば、今すぐ取り組めます。この条件を満たすなら、どちらの企業例でも、小規模な社内支援の実証実験が妥当な出発点です。

データの利用権が未解決、アクセス制限を強制できない、レビューの人員を確保できない場合は、実業務での利用を待ちます。それでも、基準値の測定、参照資料の整備、権限の確立、対象業務の絞り込みなど、進められる仕事はあります。

単純なルールですでに確実に解決できているなら、既存のプロセスを維持します。必須項目のチェックや固定の承認ルールを、モデルに解釈し直させる必要はありません。AIが生成した提案を扱う際にも、こうした管理の仕組みは残します。

創業者が今行うべきことは、優先順位を決め、人員と時間を確保することです。業務運営の担当者は、引き継ぎと例外対応を文書化します。技術責任者は、自律的に動ける範囲を広げる前に、検証機能と権限管理が機能することを実証します。

AI戦略で過大評価されがちなことは何ですか？

全社一律の自動化目標から始めるのは適切ではありません。 操作ごとに、引き起こす影響は異なります。下書き作成が大幅に速くなっても、顧客担当責任者が提案書を承認する設計は、引き続き適切かもしれません。

自社システムを作っても、依存関係はなくなりません。 参照資料、モデルの挙動、システム連携、人員体制、顧客の期待が変わるたびに、対応する責任が残ります。アプリケーションを購入した場合も、自社での使い方には責任を負います。継続的な作業を支えられる方法を選びます。

ツールの利用量は、事業成果ではありません。 プロンプトの数、利用アカウント数、生成した文書の数が増えても、所要時間は変わらず、確認作業だけが増えることがあります。修正に必要だった作業も含め、受け入れられた成果物と事業上の成果を報告します。

1枚の戦略は意思決定の記録であり、運用の仕組み全体ではありません。 評価用の事例、アクセス記録、インシデント対応手順、実装の詳細は、別の資料で管理します。簡潔さは経営層の判断を助けますが、判断の妥当性を支える作業までなくなるわけではありません。

よくある質問

AI戦略を立てるうえで、特に重要なことは何ですか？

提案する用途を測定可能な事業成果に結び付け、責任者を指名することです。そのうえで、顧客への確約、データの漏えい、本番システムの変更につながる前に、誤りをどう検出するかを決めます。実行可能な品質確認の方法がない用途は、範囲を絞るか、導入を待つ必要があります。

1枚で使えるAI戦略テンプレート

以下を文書にコピーして、空欄を埋めてください。回答は短くまとめます。ページをプレゼンテーション資料に膨らませるのではなく、補足の記録へリンクします。月曜日には、CEOと業務責任者が、最初の候補となる用途について一緒に記入し、現状の基準値を確認するレビューの日程を押さえましょう。

会社名： ______ 経営層のスポンサー： ______ 意思決定日： ______
計画期間： ______ から ______ まで 業務責任者： ______

取締役会への回答：「AIで______を改善するため、______から着手します。______の制約のもと、______のリソース投入を承認しています。成果には______が責任を持ちます。______の根拠を使い、______に次の投資を判断します。」

AIに関する意思決定を、実際に機能する業務プロセスへつなげるための実践的な情報を得たい方は、ニュースレターにご登録ください。