株式会社Polyscape AI/DX事業の事業責任者の冉 蘭驪です。
2025年後半を境に、日本企業のAI利活用は明らかに「次なるフェーズ」へと移行しつつあります。以前はIT・開発部門による「生成AIに触れてみる、試してみる」という探索的な取り組みが中心でした。しかし現在は、経営陣や業務部門を巻き込み、「どの業務に、いかに実装し、具体的にどれほどのインパクトを出すか」という投資対効果（ROI）をシビアに問う企業が、着実に増えてきました。
一方で、現場のリアリティに目を向けると、ある深刻な課題が浮き彫りになります。
AIエージェントやRAG（検索拡張生成）のPoCは急増しているものの、その多くが「本番導入」の壁を越えられずに停滞しているのです。「プロトタイプは開発したものの、業務に定着しなかった」。あるいは「プロトタイプは動くし、現場の評価も悪くない。けれど、追加投資の判断には至らない」。こうした“PoCの踊り場”とも言える状況が、今、至る所で顕在化しています。
本記事では、AI活用を「一時的な検証」で終わらせず、真に事業成長へ寄与させるための具体的なメソッドを提示します。
以下のような方を想定読者としています。
- AI活用を進めたいが、どの業務から着手すべきかわからない事業責任者・企画担当者
- PoCは実施したものの、本番導入や追加投資につながらなかった方
- AIエージェントの開発を内製・外注のどちらで進めるか検討している方
- 要件定義や検収の進め方が、従来のシステム開発と同じでよいのか悩んでいる方
目次
- 目次
- 2026年のAI活用は、「やるかどうか」ではなく「どうやるか」
- なぜPoCは止まるのか──よくある3つの失敗パターン
- 効果が出やすい業務には共通点がある
- 最初に狙うべき業務は、「少し便利」ではなく「部分代替」ができるもの
- 失敗を回避し、成果を最大化する「5つの導入ステップ」
- PoCの導入前に実施すべき要件定義
- 検収では、「動くか」だけでなく「業務で使えるか」を見る
- AI実装の本質：100点の仕様書より、高速な「評価・改善・再設計」のサイクル
- ベンダー選定の要諦：「AIの実装力」以上に「上流の設計力」を問う
- 結びに：AIを「事業の武器」にするために
2026年のAI活用は、「やるかどうか」ではなく「どうやるか」
AI活用において先行し、確かな成果を上げている企業を俯瞰すると、もはや論点は「AIを導入すべきか否か」ではありません。彼らの関心は一貫して、「どの業務に組み込むか」「どの深さまで実装するか」「誰がその成果に責任を持つか」という実効的な問いへと移行しています。
ここで極めて重要な視点は、AIを単なる「便利なITツール」として矮小化しないことです。実務上、AI活用の習熟度は以下の3つのレイヤーで多層的に捉える必要があります。
経営レイヤー：AI戦略の策定、投資判断基準の明確化、責任体制の構築
業務レイヤー：具体的ユースケースの特定、オペレーションへの組み込み、現場への定着
基盤レイヤー：データ連携、システム接続、ガバナンスおよびセキュリティ
企業の歩みは、この3レイヤーが相互に影響し合いながら、以下の3つのレベルを辿ります。
結論として、競合他社との差を生むのは「いかに優れたモデル/サービスを選んだか」という技術選定の巧拙だけではありません。「どの業務に、どのような深さで実装したか」という事業への解像度こそが、本質的な勝敗を分けるのです。
なぜPoCは止まるのか──よくある3つの失敗パターン
PoCが本番導入に至らずに停滞してしまう理由、それは一言で言えば、成功の鍵が技術の成否だけでなく、戦略や業務フローといった「複合的な要素」の整合性に依存しているからに他なりません。現場で頻発している失敗は、大きく以下の3つのレイヤーに集約されます。
戦略レイヤーの失敗：投資対効果（ROI）の欠如
PoC自体は成功し、現場からも一定の評価を得ている。しかし、会社として追加投資を行うだけの「経営インパクト」が見いだせない——。これは、多く見られる失敗パターンです。
例えば、「個人の調べものが早くなった」「特定の作業が数分短縮された」といった成果は、確かに現場には喜ばれます。しかし、対象人数が少ない、あるいは業務頻度が低いといった理由で、全社規模でのROIが算出できない場合、経営層にとってそのプロジェクトは「次の投資先」としての優先順位を失います。「現場の満足度」と「事業としての投資価値」は、峻別して考えなければならないのです。
業務レイヤーの失敗：オペレーションへの「埋め込み」不足
プロトタイプは動く。しかし、実業務のフローに馴染まない。これは、精度不足以前に、「AIのアウトプットが業務のどこで、誰によって活用されるか」というプロセス設計（UX）が欠落しているケースです。
例えば、商談内容を要約するAIを導入したとします。しかし、その要約データが自動的にCRM（顧客管理システム）へ連携されず、結局人間が別のフォーマットに転記したり、上司への報告用に作り直したりしているのであれば、本質的な効率化には繋がりません。単に「AIが何を答えるか」だけでなく、その後の次アクションやレビュー運用まで含めた、エンド・ツー・エンドの設計が不可欠です。
開発レイヤーの失敗：実装精度とデータ基盤の不備
PoCそのものの品質に起因するケースです。回答精度の低さ、システム設計の甘さ、既存システムとの連携不足、あるいは参照すべきデータが構造化されていないといった問題が挙げられます。
ただし、ここで注意すべきは、「開発品質を上げるだけで解決するプロジェクトは稀である」ということです。プロジェクトがどこで詰まっているのか。戦略・業務・開発の3層のどこにボトルネックがあるのかを正確に診断しなければ、的外れな改善を繰り返すことになってしまいます。
効果が出やすい業務には共通点がある
では、数ある業務の中で何を最初のターゲットに据えるべきなのでしょうか。私は、AI活用において早期に目に見える成果（Quick Win）を出すためには、少なくとも次の3つの条件を満たしている必要があると考えています。
判断基準と「正解」が言語化されていること
業務のプロセスや、何をもって「良質なアウトプット」とするかの基準が、ある程度整理されていることは極めて重要です。判断基準が属人化しすぎず、論理的に説明できる業務は、AIへの指示（プロンプト）に落とし込みやすく、精度の検証も容易になります。
逆に、「ベテランの勘」や「長年の経験による塩梅」に頼り切り、アウトプットの良し悪しを定義できない業務は、PoCの段階で迷走しがちです。これはAI側の性能の問題ではなく、「人間側の業務要件」が未整理であることに起因する停滞です。
参照すべきデータが「構造化」されていること
ナレッジが適切に管理されているか、データの接続先が明確であるかも成否を分けるポイントです。
よくある失敗として、Slack、Google Drive、Notionなど複数のプラットフォームに情報が散在しているケースが挙げられます。さらに、ワークスペースが分断されていたり、命名ルールが形骸化していたり、アクセス権限が複雑に絡み合っていたりすると、AI以前に「情報のアクセシビリティ」というインフラ面で躓いてしまいます。AIを導入する前に、まずは「情報の参照環境」を整える視点が欠かせません。
「大量・反復・一次処理」の要素があること
実行回数が多く、人間が定型的に繰り返している業務は、AIとの相性が抜群です。
ここで特に注目したいのが、最終判断の一歩手前にある「一次処理」です。情報の整理、分類、要約、抽出といった作業がこれに当たります。
- 議事録や商談の要約
- 採用面接の評価支援（定性情報の整理）
- ナレッジ検索や問い合わせの一次回答
- 大量の文書のカテゴリ仕分け
これらは典型的な成功例です。最終的な意思決定をいきなりAIに委ねるのではなく、その前段階の「情報の料理」をAIに任せる。この「AIによる下準備 ＋ 人間による最終判断」というワークフローは、導入の心理的ハードルが低いだけでなく、確実な工数削減と品質向上に直結します。
最初に狙うべき業務は、「少し便利」ではなく「部分代替」ができるもの
AI導入のターゲットを選定する際、最も意識すべきは「便利になるかどうか」ではなく、「業務をどこまで代替できるか」という踏み込みの深さです。現場におけるAI活用の効果は、大きく以下の3段階で顕在化します。
- 体感的な負荷の軽減：「なんとなく楽になった」と感じるレベル
- 定量的な工数削減：実際の作業時間が計測可能なほど短縮されたレベル
- 役割・配置の変革：人員配置や役割分担の変更を検討できるレベル
もちろん、第1段階の「楽になる」ことにも価値はあります。しかし、企業として継続的な投資を決断する根拠となるのは、多くの場合、第2段階以降の「可視化されたリソースの創出」です。
そして、この第2、第3のフェーズに到達するためには、AIを単なる「補助ツール」として使うのではなく、「業務プロセスの一部を安定して代替させる」という設計思想が不可欠になります。
具体的には、以下のような「役割の再定義」を伴う活用が理想的です。
- 議事録作成：単なる文字起こしに留まらず、要約・ネクストアクションの整理までをAIが完結させる。
- 顧客対応：問い合わせの一次切り分けをAIが担い、人間は判断が必要な高難度案件にのみ集中する。
- 採用業務：面接情報を構造化して読み込み、比較観点を揃えた評価材料の整理までをAIが代替する。
これらは単なる「便利ツール」の導入ではありません。AIを「デジタルレイバー（デジタルの労働力）」としてワークフローに組み込み、人間との役割分担を再設計するプロセスそのものなのです。
失敗を回避し、成果を最大化する「5つの導入ステップ」
実務においてAI活用を軌道に乗せる際、私は次の5つのステップで設計することを推奨しています。技術から入るのではなく、あくまで「事業の合理性」から逆算するのが鉄則です。
STEP 1：対象業務の解剖（ビジネスプロセスの棚卸し）
まずは対象部門の既存業務と課題を徹底的に洗い出します。業務内容、頻度、工数、判断の難易度、そして「誰が」担っているかを可視化します。
ここで最も重要なのは、「AIで解決すべき課題」と「従来のDXや業務改善で解決すべき課題」を厳格に切り分けることです。「AIなら何かできそう」という技術起点の視点は一度捨て、業務構造そのものを凝視してください。ルール化、SaaSの導入、UIの改善、あるいは入力ルールの統一だけで解決できる課題も多く、それらはAIを投入するまでもない「前段の整理」に当たります。
STEP 2：投資対効果（ROI）とリスクの多角的な試算
次に、各業務への導入インパクトを試算します。選定の軸は、感情的な「現場の困りごと」ではなく、以下の3軸による客観的な評価です。
- インパクト（期待効果）：業務頻度、対象人数、総工数、他部門への横展開の可能性、売上・品質への寄与度。
- コスト（投資額）：初期開発費、継続的な運用・改善費、データ整備コスト、そして「業務部門が検証に割くリソースコスト」。
- リスク（不確実性）：個人情報の取り扱い、誤回答（ハルシネーション）の許容度、レピュテーションリスク、オペレーションの混乱。
この3軸でマッピングすると、「現場のニーズは高いが、投資対効果やリスクの観点から、今は着手すべきではない業務」が明確に浮かび上がります。
STEP 3：ソリューションの構造設計（抽象化と共通化）
対象業務に対し、どのような技術的アプローチが最適かを設計します。ここでのポイントは、特定の製品名や「RAGかエージェントか」といった手段に固執しないことです。
重要なのは、「異なる業務を、共通の論理構造で捉え直す」という抽象化の視点です。 例えば、「採用面接の評価支援」と「商談の要約」は、一見すると別物です。しかし、「非構造化データ（会話）を読み解き、特定の観点に沿って整理し、次アクションを生成する」という構造は共通しています。このように業務を抽象化できれば、個別最適の開発ではなく、拡張性の高い「共通基盤」としての設計が可能になります。
STEP 4：実装フェーズの「隠れたコスト」の精査
ソリューション案ごとに、より詳細な開発工数とリスクを見積もります。AIプロジェクトにおいて、純粋な「開発工数」だけで議論するのは極めて危険です。以下の「隠れた工数」を必ず算入してください。
- 参照データのクレンジングや前処理（データエンジニアリング）
- セキュアな権限制御の設計
- 精度検証（評価）のために、業務部門が費やす膨大な工数
- 導入後のオンボーディングと、継続的な精度改善の運用体制
「PoCの後ろには、必ず評価と改善の長い道が続く」という前提に立つことが、プロジェクト破綻を防ぐ唯一の方法です。
STEP 5：初期導入スコープの戦略的決定（Quick Winの創出）
これらすべてのステップを踏まえ、最初に着手するテーマを確定します。
基本戦略は、「効果が可視化しやすく、リスクを制御可能で、将来の横展開を見込める領域」への集中投下です。最初から全社横断の巨大なテーマを狙う必要はありません。むしろ、評価基準が明確なスモールスコープで確実に「成功の型」をつくる。その実績こそが、次なる大きな投資を引き出すための最強の武器となります。
PoCの導入前に実施すべき要件定義
AIプロジェクトを成功に導くためには、従来のシステム開発と同じ要件定義だけでは不十分です。私は実務において、要件を「システム要件」と「レスポンス要件」の2軸で定義することを徹底しています。
システム要件：基盤とインターフェースの設計
システム要件とは、いわば「器」の設計です。これは従来のシステム開発の進め方に近く、主に以下のような項目を確定させます。
- INPUT&OUTPUTの定義：どのような形式でデータを投げ、どのような形で受け取るか。
- 接続先・データの定義：Google Drive、Notion、Jira、社内DBなど、どの接続先を参照するか。また、外部参照する時に、どのウェブサイトをどのような仕組みで情報を取ってくるか、ログインが必要かどうか。
- ツール定義：どのようなタスクをいつ、どのような挙動でどういった入出力なのか。
- 機能・UI・権限管理：ChatGPTのような会話型エージェントなのか。共有機能や評価機能、誰に閲覧・操作権限を与えるか。
「どこからデータを持ってきて、どの画面にどう出すか」という、システムとしての物理的な挙動を固めるフェーズです。
特にツール定義に関して前に投稿した記事も参考になるでしょう。
レスポンス要件：知能の「品質」と「振る舞い」の設計
AIプロジェクトにおいて真に難易度が高く、かつ成果を左右するのがこの「レスポンス要件」です。一言で言えば、「どのような問いに対し、どの程度の粒度・形式・品質で回答を返すべきか」という知的なアウトプットの定義です。
ここで有効な手法が、「期待される質問（プロンプト）」と「理想的な回答」をセットで具体化することです。 例えば、「契約書のリスク分析を行う」という定義だけでは不十分です。
- どの条項を重点的にチェックするのか
- どのようなリスク分類（高・中・低）で出力するのか
- 根拠となる条文番号やURLは併記するのか
- 要約の深さはどの程度か
これらを事前に定義しなければ、AIの精度を評価する尺度（ものさし）が存在しないことになってしまいます。
効率的にレスポンス要件を固める「3ステップ・アプローチ」
理想を言えば、最初から完璧な理想回答を定義したいところですが、現実には困難です。そこで、私は次のような「既存AIを叩き台にする」現実的なアプローチを推奨しています。
- 汎用AIによる試作：まずChatGPTなどの汎用AIに、実際の業務で想定される問いを投げてみる。
- ギャップ分析：返ってきた回答に対し、業務の専門家が「何が足りないか」「どこが違うか」を評価・添削する。
- 要件への昇華：その添削結果を、レスポンス要件（制約条件や出力ルール）としてドキュメントに落とし込む。
ゼロから正解を書くのは骨が折れますが、「AIの回答にダメ出しをする」形であれば、現場の担当者も要件を言語化しやすくなります。この「人間によるフィードバック」を設計に組み込むことが、実運用に耐えうるAIを作るための最短ルートなのです。
検収では、「動くか」だけでなく「業務で使えるか」を見る
AIエージェントの「検収（UAT）」は、従来型のシステム開発におけるそれよりも遥かに難易度が高いのが実情です。その理由は明白で、「入力も出力も、常に揺らぎを孕んでいるから」です。
同じ意図の質問でも言い回しが変われば、AIの回答も変化します。時には想定外の問いが投げかけられることもあります。そのため、単に「仕様書通りに動くか」を確認する従来の検収手法だけでは、その真価を測ることは不可能なのです。
私は、AI案件の検収は「機能要件」と「非機能要件」の二つの側面から、多層的に評価すべきだと考えています。
機能要件：業務としての「遂行能力」を問う
ここでは、AIが業務上のミッションを正しく遂行できているかを確認します。
- 機能実装の整合性：定義した機能が、意図したワークフローに沿って実装されているか。
- データの参照精度と権限：指定された文書・データを、権限範囲内で過不足なく参照できているか。
- 出力形式・ルールの遵守：指定したフォーマットや、遵守すべき業務ルール（禁則事項など）に沿っているか。
- 業務適合性（実用性）：生成された回答が、実際の現場業務で「価値」を生んでいるか。
非機能要件：システムとしての「安定性」を問う
AIがビジネス基盤として信頼に足るものか、背後の性能を評価します。
- 応答性能（レイテンシ）：主要なユースケースにおいて、実用的な速度で回答が返ってくるか。
- レジリエンス（回復性）：タイムアウトや停止などのエラー率が許容範囲内か、安定稼働しているか。
- ガバナンス・セキュリティ：厳格な権限制御、機密情報の保護、そして回答の追跡可能性（トレーサビリティ）が担保されているか。
現場の納得感を生む「業務活用レベル」の5段階評価
業務適合性（実用性）の評価は定性評価であり、同じクオリティでも評価者によって評価が分かれやすいため、ここでは、業務部門が主観ではなく、一定の基準で評価できるよう、私は以下の5段階の評価指標を用いることを推奨しています。
この評価軸の優れた点は、ChatGPTなどの外部ツールとの漠然とした比較ではなく、「自社のその業務において、どれほどのリソース（工数）を浮かせてくれるか」という実利に軸足を置けることです。
評価基準が明確になれば、現場はフィードバックを出しやすくなり、開発側も「どこを改善すべきか」の優先順位を迷わずに判断できるようになります。
AI実装の本質：100点の仕様書より、高速な「評価・改善・再設計」のサイクル
AIエージェントが従来のプロダクト開発と決定的に異なる点。それは、開発の比重が「リリース前」ではなく、「プロトタイプが立ち上がった後」に大きく傾くという事実です。
従来のシステム開発は、要件定義から設計、開発、テストへと段階的に進み、リリース時の完成度をいかに高めるかに心血を注ぎます。しかし、AIエージェントにおいては、初期段階で100点の仕様を固めることは不可能です。なぜなら、現場の生きたデータや多種多様な入力に触れて初めて、真の課題と改善点が見えてくるからです。
重要なのは、PoCの時点で完璧を求めることではなく、「使いながら精度を上げ、実務に合わせて柔軟に再設計していく」というアジャイルなマインドセットです。そして、このサイクルを回し続けるためには、以下の3つの「運用設計」が成否を分ける鍵となります。
現場の「キーパーソン」によるオーナーシップ
AI活用は、単に便利なツールを配布すれば自然に浸透するものではありません。現場に「このAIを使って業務のあり方を変える」と腹をくくったキーパーソンが存在するかどうかが、導入後の定着率を劇的に左右します。
現場の負債を理解し、AIとの共存をリードする「人」の存在こそが、技術以上の推進力となります。
徹底した「オンボーディング」とリテラシー教育
現場のメンバーに対し、「どの業務で使うべきか」「どのようなプロンプト（指示）が有効か」といった基本的な使い方はもちろん、「AIの回答のどこを疑い、どこを人間が担保すべきか」というガードレールの共有が必要です。ここが疎かになると、一度の誤回答で信頼を失い、「使えないツール」というラベルを貼られてプロジェクトは終焉を迎えます。
本番稼働後の「伴走型」改善プロセス
開発チームにとっても「システムを納品して完結」という旧来のスタンスは、もはや通用しません。一度開発してフェードアウトするのではなく、AIエージェントを実際に活用する部門のキーパーソンや推進チームと密に連動し、現場のリアルな声を拾い続ける「伴走」が不可欠です。
開発側は、現場のフィードバックを単なる「修正依頼」として受け取るだけでなく、AIの特性に応じた「使いこなしの勘所」や「効果的なプロンプトの設計ノウハウ」を現場へ丁寧にトランスファーしていく役割を担うべきです。
技術者が現場のリテラシー向上を支援し、現場が技術の限界と可能性を理解する。この双方向のコミュニケーションを通じて、AIエージェントは単なるソフトウェアから、「組織の欠かせない戦力」へと進化していくのです。
ベンダー選定の要諦：「AIの実装力」以上に「上流の設計力」を問う
外部パートナーと共にプロジェクトを推進する場合、私は選定基準として、少なくとも次の3つの観点を重視すべきだと考えています。
事業・業務設計力（Upstream Design）
単に「DifyやLangChainを扱える」「LLMのAPI接続ができる」といった技術スタックの有無だけでは不十分です。
真に価値あるパートナーは、「どの業務にAIを投入すれば最大のレバレッジがかかるか」「現場のオペレーションにどう組み込めば定着するか」を、事業責任者と同じ目線で議論できる力を備えています。
技術の「手段」を語る前に、業務の「構造」を解き明かせるかどうかが、最初の分岐点です。
アーキテクチャの構想力（Technical Architecture）
同じ業務課題であっても、エージェントの階層構造、RAG（検索拡張生成）の組み込み方、外部ツールの連携手法、そして精度評価のフレームワークによって、最終的なアウトカムは劇的に変わります。
AIプロジェクトにおいては、「動くものを作った」という事実以上に、「その設計が、実運用における変化や例外に対してどれほど妥当で堅牢か」という設計思想の深さが、中長期的な投資対効果を左右します。
社会実装の完遂実績（Proven Track Record）
単なる導入件数ではなく、「類似の業務構造やデータ構造に対し、どのように設計し、いかにして現場に定着させたか」という泥臭いプロセスを語れる実績があるかを確認してください。
「作って終わり」のPoCを量産しているベンダーではなく、本番導入後の課題を乗り越え、実運用におけるKPIの改善まで伴走した経験こそが、プロジェクトを成功に導く生きた知見となります。
結びに：AIを「事業の武器」にするために
2026年、日本企業のAI活用は「模索」の時代を終え、明確な「実戦」の時代へと突入しました。 本稿で述べた通り、PoCの停滞を打破し、AIを真の事業成長へと繋げるために必要なのは、最新のモデルを追いかけることではありません。
「戦略・業務・開発」の3つのレイヤーを整合させ、現場のキーパーソンと共に、不確実な領域を泥臭く耕し続ける覚悟です。
AIエージェントを「一時の流行」で終わらせるか、「本質的な変革の鍵」にできるか。今、ビジネスの現場で問われているのは、技術を単なるツールとしてではなく、事業戦略の核として捉え直すリーダーシップのあり方そのものです。
株式会社Polyscapeもまた、単なる「開発ベンダー」としてではなく、お客様の事業をAIで変革する「パートナー」として、この挑戦的なフェーズを共に歩んでいきたいと考えています。
ここまで読んでいただき、ありがとうございました。
Polyscape SF ジャーナル 