ADOPT：戦略から実装へ、AI実行計画のフレームワーク

By /

SCANで見極めた価値は、実装しきって初めて手に入る。ADOPTは、選ばれたAI施策を「堅実・具体的・実現可能・測定可能」な実行計画へと落とし込むフレームワークである。

　前稿のSCANでは、AI施策の潜在価値を「獲得できる価値」と「戦略との針路整合」に基づいて見極め、優先順位を評価した。その先、選ばれた施策は実装フェーズに入る。ここで難しいのは、成否が「一つの要素」だけでは決まらないことだ。

　例えば、優れたAIモデルやアルゴリズムを用意しても、支えるデータが無ければ動かない。狙う成果が明確でも、現場が使わなければ何も変わらない。正しい計画でも、移行の道筋を誤れば頓挫する。つまり、リスクは、価値が各要素の「継ぎ目」でリークしていくことだ。

　そこで本稿では、実行計画のフレームワーク「ADOPT」を提案したい。ADOPTは、①AIの主体設計（Agent）、②それを支えるデータ（Data）、③目指す成果（Outcome）、④動かす人と組織（People）、⑤既存業務からの移行（Transition）、という相互に連結した五つの要素から実行計画を組み立てる手法である。選ばれたAI施策を、五つが互いに噛み合う一つの実行計画へと落とし込む、そのための枠組みだ。

ADOPTの概要

  • AIの主体（Agent）：AIは何を担い、人とどう協働するか。役割・自律度・ガードレールを定め、AIソリューションの仕様を描く。
  • データ（Data）：必要なデータは何で、使える状態にあるか。データの品質・取得性・ガバナンスを明確に整理し、フィードバック等の新しいデータの仕組みも整える。
  • 成果（Outcome）：何をもって成功とし、どう測るか。SCANが見積もった獲得価値を目標として引き継ぎ、KPI・基準値・測定方法を、コスト差引きで定める。これはADOPTの中心。
  • 人と組織（People）：社内で誰の仕事が変わり、どうすれば「できる・やる気になる」か。能力ギャップ・動機・定着を見極め、変革（チェンジマネジメント）を設計する。
  • 移行（Transition）：今日の業務から新しい業務へ、どう移るか。連続的な変化か、非連続性を伴う切替か。試行・撤退・順序・時間軸を計画する。

　ここで二つの原則を押さえたい。一つ、部品ではなく「整合」が計画を生かす――価値は五つの要素の継ぎ目でリークする。もう一つ、成果（Outcome）がこの実行計画の中心（ハブ）であり、SCANが見積もった価値から逆算して定める。AIの主体・データが技術の翼、人と組織・移行が人の翼、この両翼のバランスとシナジー効果により、AIの価値が実現するのだ。

1. AIの主体（Agent）― ソリューションの設計

　まず、AIは何を担うのか。単純な人間の代行なのか、人の判断を補助する相棒なのか、それとも自律して動くのか。この「自律度」を決め、人が介在する要所、逸脱を防ぐガードレール、失敗時のエスカレーションを設計する。ここで描くのは「AIソリューションの仕様」だ。

　チェックするべきリスクポイントは、技術の実現性・モデルの成熟度・ガードレールの信頼性にある。

　注意したいのは、無理やりに「エージェント」を前提にしないことだ。もしかしたら正解は、従来型の機械学習モデルや、定型のワークフロー、あるいはデータ処理のパイプラインかもしれない。成果に届く「最も単純な」手段を選ぶことだ。

　技術実現で一つ着眼したいのは、Agentの頭脳である、LLM（Large Language Model）の「居場所」の選定だ。API経由でクラウド上のLLM（Cloud AI）を活用するか、自社環境のGPUでLLM（Local LLM）を動かすか、この選択により、データ主権・機密性・応答速度・コスト構造・運用負荷が大きく変わる。汎用的な処理で、最新の能力を素早く安価に立ち上げたいならCloud AI、機微データを外に出せない・規制が厳しい・大量処理を定常運用する用途なら、Local LLMを選ぶ。ここは「機能性」だけでなく、「性能性」、「セキュリティ性」、「コスト面」を総括的に考えるべき論点だ。詳細は付録にまとめた。

　イチマルは以前、デジタルトランスフォーメーションのプロジェクトを実施した。その時、需要予測モデルを構築して社内に展開していた。しかし、二つの課題でビジネスへのインパクトが限定的だった。

　1. 当時構築した予測モデルは、天気予報情報と近隣イベントの情報を加味しておらず、これらの状況によってしばしば外れが激しく、そのままの運用が難しい。

　2. 予測の根拠情報は出力されず、エリア長たちは予測数値に疑問があった際に納得できる答えを得られないので、モデルを信用した上での運用になっていない。

　今回は、この二つの課題に焦点を当ててAIソリューションを設計したい。具体的には、天気予報・イベント情報を加味した予測値の補正処理、及び予測結果・過去精度評価における誤差要因・予測値の運用・発注業務における助言等で、AIからの分析・サポート機能を構築する。

　そしてもう一つ、LLMの選定について、Cloud AIかLocal LLMかの議論があった。ここで社長がこう言った：

「最近、訪日観光客、特に欧州から来たお客さんの数が増えてきた。一部の店舗では、その売上がほぼ半分を占めた。今後、ロイヤルティAIの導入の考えもあり、個人情報関連でLocal LLMで進めたい。今回は個人情報を取り扱わないが、将来を見据えLocal LLMを検討したい」

※注：社長が欧州客の個人情報を気にしたのは、EUのGDPR（一般データ保護規則）による部分もある。欧州在住者の個人データをCloud AIで処理する場合、Cloud AIプロバイダーとの間でデータ処理契約（DPA）や標準契約条項（SCC）など法的書面を交わし、越境移転の適法性を担保する必要がある。これは日本の一般企業にとって負担が重く、現実的でないことが多い。データを外に出さないLocal LLMなら、この問題を回避できる。

2. データ（Data）― AIエンジンへの燃料

　次に、その解を動かすデータだ。必要なデータは何か、どこから得るか、アクセス権はあるか、品質は保てるか、ガバナンス・プライバシーは満たせるか。そして、AI自身が生み出すフィードバックをどう回収するか。

　チェックするべきリスクポイントは、データの量・品質・可用性・ガバナンスにある。

　注意したいのは、データがしばしば「ボトルネック」になることだ。到達できる成果は、導入するモデルではなく、実際に手に入るデータで決まる。さらに、そのフィードバックデータは、積み上げれば積み上げるほど、データ活用が生み出す価値を高めていく。逆に言えば、フィードバックの回収を設計しなければ、次のサイクルはまたゼロから始まる。

　イチマルにとってはまず、二つの必要なデータは明確だ。

　一つは天気予報データ。今は、エリア長はモデルの需要予測値と翌日・翌週の天気予報値を並べて見て、自分の経験と勘で予測値を修正している。これはAIが代行できる処理だ。政府関連省庁のパブリック情報を活用すれば、追加のデータライセンス費用も省ける、というメリットもあるのだ。

　なお、現行モデルの実行本体を変更せず、あくまでも後処理の形で一次予測の結果に補正を加える考えだ。こうして天気予報加味の効果を得られ、システムの改修工数も最大限に抑えられる。

　もう一つは近隣イベント情報。ここで少し難しいことが二つある：

　1. 今、エリア長たちが参考にしているのがウェブ検索から得た近隣イベント情報。これらの情報はほとんど構造化されておらず、アルゴリズムに処理させるためにデータの整形処理が必要である。

　2. イベントの規模、とりわけ参加人数の情報は明記されないことが多く、ここでエリア長が自分の経験・勘で見込み来場人数を判断し、それによってさらに見込み需要を調整する。

　この二つの点についてLocal LLMを活用して手早く机上検証試験を実施した。データ整形については、LLMはうまく処理できて、きれいな構造化データを加工できた。一方で、LLMは、ヒントが与えられた状況でイベントの来場人数もある程度リーズナブルに予想できるが、やはりエリア長の判断とのギャップが存在する。

　ここで、回収するべきデータが一つ見えてくる。それはエリア長によるLLM補正の訂正フィードバックだ。インプット条件、LLMの一次補正、そしてエリア長の最終訂正結果を継続的に蓄積し、その情報をさらにAIにインプットする。こうして、AIの補正スキルはだんだんと上がっていく。AIの活用により、データを通じた社内ノウハウの言語化と、さらなる活用のアプローチが明確になる――それこそがAI活用の一つのメリットだ。

※注：構造化データとは、行・列・属性など、明確で厳格なフォーマットに従って作成・加工・格納されたデータを指す（例：リレーショナルデータベースの表、CSV、スプレッドシート）。これに対し、ウェブ記事やメール本文のように定まった形式を持たないものを非構造化データと呼ぶ。後者はそのままではアルゴリズムで扱いにくく、整形が必要になる。

3. 成果（Outcome）― 成功目標と物差し

　AI施策は何をもって成功とし、その効果はどう測るか。ここがAI実行計画の中心である。SCANが見積もった「獲得価値」を目標として引き継ぎ、KPI・KGI、基準値、測定の仕組みを定める。その際、構築・運用のコストを差し引いた「正味価値」で見る。KPIを設計する際に、先行指標と遅行指標も分けておく。

　チェックするべきリスクポイントは、事業としての妥当性・市場の準備・タイミングにある。

　注意したいのは、「実行活動」ではなく、「実現した価値」を測ることだ。「削減できた時間」は「獲得できたコスト」ではない（SCANの「0.3人分」問題）。AI施策の成果は、SCANが約束した価値を具現化したものであり、ADOPTの中心点である。他のすべての要素は、これに資するよう計画される。

　イチマルの成功目標は二つある。一つは、平均廃棄コスト率を現行の5%から3%へ引き下げること。もう一つは、エリア長の発注計画作業時間の50%削減だ。

　まずはイチマルのコスト構成を確認しよう。そこでこの二つの目標が示すビジネス上の意味がわかる。

　イチマルは、年間およそ500万杯のラーメンを販売している。クーポン・特典等を差し引いて平均売上単価が1,200円である。材料費は30%、人件費30%、粗利益は40%で、利益率は同業種でやや高めの状況である。

　しかし、ここで平均廃棄コストは食材原価に対して5%で、主に発注精度に起因する売れ残り分である。金額に換算すると、年間でおよそ9,000万円である。この数字の意味はこれだけではない。問題はこの5%の構造である。

　内訳を見ると、開店から3年未満の店舗（全体の2割程度）が、常に廃棄コストの8割を占めている。エリア長たちはこれらの店舗の発注計画に最も時間を費やしているが、それでもこの状況である。つまり、このままだと、今の廃棄率を維持するだけでエリア長も精一杯となり、さらに店舗数が増えれば、廃棄率の悪化を招きかねず、イチマルの業績が落ちる恐れがある。

　よって、この二つの目標及びその戦略への意味をより詳細に説明すると、

　目標1： 廃棄コストは5%から3%に下がり、現状なら年間で3,600万円のコスト削減効果を得られる
　戦略への意味： 属人的な発注計画は半自動化・自動化になるため、店舗が増えても廃棄率が増加せず、出店戦略上の大きなオペレーションリスク要因を取り除く

　目標2：エリア長たちは平均で発注計画作業時間、現状毎週10時間の50%を削減、4人で年間、総じて960時間を削減できる
　戦略への意味：エリア長たちが総じて浮いた時間は年間0.5人の作業時間であり、それを重点的に出店準備・交渉業務に移し、もともと予想していた外部コンサルを自社戦力に切り替え、外注費の抑制・ビジネスノウハウの流出を防げる

ということがわかる。

4. 人と組織（People）― ステークホルダーとロール設計

　AIが余剰を生んでも、最後に価値を刈り取るのは人だ。現場が実際に行動を変えなければ、成果は実現しない。だから人と組織の次元では、社内で誰の仕事がどう変わるのかを見極め、その人たちが能動的に実行できる状態をどう実現するかを設計する。

　まず要るのは、明確なロール設計だ。進捗と品質・リスクを見張る「統制」、実際に手を動かす「主導・実施」、実務を支える「サポート」――この三つの役割で、誰が何を担うのかを曖昧にしない。役割が宙に浮くと、AIは動いても組織は動かない。

　その上で、現状とあるべき姿の間の「ケイパビリティ・ギャップ」を分析する。新しい役割に必要な能力は何で、今どれだけ足りないのか。そのギャップを埋めるためのケイパビリティ・ビルディング（研修・OJT・採用・再配置）を定義し、計画に織り込む。

　チェックするべきリスクポイントは、ケイパビリティ・ギャップ・動機（インセンティブ）・定着にある。

　イチマルの場合、ロール設計はこうなる：

　・統制は社長で、各重要指標値をもとに進捗を見張り、遅れがあれば催促する。
　・主導・実施はエリア長で、AIの補正を使いこなし、最終の発注判断を下す実施の担い手である。
　・サポートは店長と店舗スタッフで、周辺イベントの情報を詳細に入力し、データフィードバックの質を支える。

　構築するべき重要なケイパビリティは、エリア長のAIツールの使いこなしだ。AIが何をできるか、どのような状況で外れやすいか、その上で何をもとに発注判断を決めるか、こうした細かなポイントを、AIの検証とAIとの会話のプロセスを通じて深く理解し、本質的に今までの発注業務プロセスを変えて精度と効率を改善する。

　そしてとりわけ社長による統制が非常に重要だ。社長は、遅行指標である廃棄コスト率の結果を待つのではなく、先行指標（需要予測と実績の乖離度合い、補正状況、エリア長のAI採用率、イベント情報の入力率など）を定期的に確認し、自らメッセージを発信してアクションを催促する。この経営トップダウンの統制こそが、行動変容を確実に前へ進める最大の推進力になり、AI導入においては不可欠な要素である。

5. 移行（Transition）― 変化のゴールと道筋

　移行は、これまでの四つの次元を一本の「変化」に束ねる次元だ。AI主体・データ・成果・人と組織のそれぞれに、「今日から明日へ、何がどう変わるのか」という意味を与え、今日の姿から目指す姿までを一続きの道筋として描く。成果（Outcome）が到達点だとすれば、移行は、四つの次元をその到達点まで運ぶ「ジャーニー」である。

　チェックするべきリスクポイントは、乗り越えないと行けないギャップの大きさと、変えない行けいない組織構造の「硬さ」にある。

　ここで問うべきは、突き詰めれば競争優位だ。今日の競争優位は何か。明日それをどう維持・強化するのか。そして、この施策から新しい競争優位は手に入るのか。この三つの問いに明確な答える。SCANで見極めた針路にAIの実装計画を付け加え、ゴールへ至る道筋を用意する。

　その変化は、層ごとに具体的に描く。ツール・データ資産はどう変わるか。業務フローはどう変わるか。人のケイパビリティはどう変わるか。組織はどう変わるか。そして最終的に、ビジネスはどう変わるか。今日の姿（As-Is）と明日の姿（To-Be）を層ごとに並べれば、変化の全体像と、埋めるべき距離が見えてくる。

　イチマルの今日の優位は、自家製麺・スープの独自の味とブランドだ。明日、それをどう強化するか。ここに移行のゴールがある。

　狙いは二つ。味とブランドを守りながら、AIで発注精度を底上げして「廃棄」という弱点を消し、浮いた時間を出店へ振り向けて展開を加速する。そして、蓄積するフィードバックデータとAI補正のノウハウという、店舗が増えるほど効く強みを手に入れる。こうして、AI活用は、確実にイチマルの店舗拡張・キャッシュフロー改善の戦略の実現を支えていく。

　そして変化を層で描くと：

　・ツール・データ：後処理の補正AI、構造化イベントデータ、訂正フィードバックという新しいデータ資産。
　・業務フロー：発注計画が「勘での修正」から「AI補正＋エリア長の確認」へ。
　・ケイパビリティ：エリア長がAI活用と出店開発の力を得る。
　・組織：外部コンサル依存から内製へ、社長の先行KPI統制のもとで。
　・ビジネス：廃棄率が店舗数に左右されず安定し、出店戦略のオペレーションリスクが下がる。

　導入アプローチの設計も必要だ。リスクと実現性を踏まえ、まず一つのエリアで試行し、予測精度の閾値を満たせたら地域全体へ広げる。システム上での一つの工夫点は、現行の需要予測モデルの本体には手を入れず、追加データをもとにした「後処理」で補正を足す設計だ。いつでも手動計画へ戻せる、後戻り可能な一歩になっている。こういう「2-Way（後戻りできる）設計」も、AI導入においてはしばしば有効な戦術になるのだ。

おわりに ― 良い計画は、整合している

　ADOPTは、選ばれたAI施策を、五つの次元が噛み合う一つの実行計画へと落とし込む。主体（Agent）とデータ（Data）が「作れるか」を支え、人と組織（People）と移行（Transition）が「根づくか」を担い、その中心には常に、SCANが見積もった価値を引き継いだ成果（Outcome）がある。

　だが、五つを個別に詰めるだけでは足りない。価値は、要素の中ではなく、要素と要素の「継ぎ目」でリークしていく――優れたAIも、支えるデータが無ければ動かない。明確な成果も、現場が動かなければ実現しない。だから最後に問うべきは、五つが互いに噛み合っているか、という一点だ。

　その計画が実行に値するかは、四つのチェックポイントで確かめられる。堅実か（主要なリスクに耐えるか）。具体的か（担当・データ・期日が実在するか）。実現可能か（コスト・技術の手が届くか）。測定可能か（SCANが約束した価値の実現を検証できるか）。この四つを、そして継ぎ目の整合を満たしたとき、計画は初めて動き出す。

　SCANで見極めた価値は、実装しきって初めて手に入る。その最後の一歩を確かなものにするのが、ADOPTである。

付録：Cloud AI と Local LLM の違い

定義

  • Cloud AI：API経由でクラウド上の大規模LLM（ChatGPT / Claude / Gemini 等）を利用する形態。
  • Local LLM：自社のオンプレ／プライベート環境のGPU上で、オープンモデル（Llama / Gemma / GPT-oss 等）を自前で動かす形態。

1) 機能性

会話、文章要約・作成、推論、コーディング、翻訳、音声文字起こしなど、基本的なLLM機能においては構造的にほぼ差がない。「何ができるか」という機能の種類でCloudとLocalを選ぶ必要はほとんどなく、差分が出るのは以下の「性能面」、「セキュリティ面」と「コスト面」である。

2) 性能性

観点Cloud AILocal LLM
精度フロンティア級の最大モデルを利用でき、最も高い。常に最新モデルへ追随可能オープンモデル中心で一歩譲るが差は縮小中。用途特化のファインチューニングで特定タスクは逆転も可能
応答速度ネットワーク依存。レート制限・混雑・外部障害の影響を受ける自社ネットワーク内で安定・低遅延。オフライン動作も可能
スケーラビリティ事実上無限。急な負荷変動に即応できるGPU容量が上限。スケール増強にシステムアーキテクチャの見直しや、調達にリードタイムが必要
可用性・障害耐性AIベンダーのSLAに依存。仕様変更・提供終了・値上げのリスク（ロックイン）自社統制下で可用性を設計できる。ただし障害対応も自社責任
運用負荷低い。インフラ・保守はAIベンダー側。少人数で運用可能中から高いレベル。AIパートナーと提携するか、GPU運用・データ処理・MLOps（機械学習の運用仕組み）の内製人材が必要

3) セキュリティ性・データコンプライアンス

観点Cloud AILocal LLM
データ主権・機密性データが外部に出る。契約・リージョン指定で管理は可能だが、越境・第三者処理のリスクは残るデータが組織内に留まり統制下に置ける。外部送信が不要で漏洩面を最小化できる
法規制・コンプライアンスベンダーの準拠範囲に依存。業種・地域の規制（個人情報・金融・医療等）への適合確認が必要自社ポリシーで統制でき、機密・規制業種（医療・金融・官公庁）に強い
監査・トレーサビリティログ・処理履歴の可視範囲がベンダー仕様に制約される入出力・処理経路を自社で完全に把握・監査できる

4) コスト面

観点Cloud AILocal LLM
初期コスト非常に低い。即座に着手でき、PoCに向くGPU調達・環境構築が必要で、数十〜数百万円レベル
運用コスト従量課金。低〜中量なら割安だが、大量処理の定常運用でコストが急増固定費中心。大量・定常運用ではトークン単価が逆転し割安に（総保有コスト、Total Cost of Ownershipで有利）

Cloud AIとLocal LLMの比較のまとめ

  • 機能では差がつかない。選択軸は「性能性（精度・速度・可用性）」「セキュリティ性（データ主権・規制適合）」「コスト面（処理量に対する総保有コスト）」の三つ。
  • Cloud AIが向く：素早い立ち上げ、需要変動が大きい、最新精度が必要、内製リソースが薄い、大量処理の定常運用が想定されていない。
  • Local LLMが向く：機微データを外に出せない・規制が厳しい、低遅延／オフライン必須、大量処理を定常運用し総保有コストで逆転する。
  • 現実解は二者択一ではなく、ハイブリッド（機密＝Local／汎用＝Cloud）やタスク難度によるルーティングになることもある。
Scroll to Top