こんにちは、ゼノクリース合同会社の齋藤です。このコラム記事では、企業の AI 活用や AI の最新情報について紹介しています。
この記事の著者
ゼノクリース合同会社 代表（Web）
斎藤 智樹
X:@TomokiSaito0920
スタンディングテックのWEB開発コース主任講師を務める。
企業の AI 活用では、PoC（概念実証。ここでは、プロトタイプやデモを作ったり、「上手くいくかは分からないけど、試しに AI を組み込んだシステムや業務ワークフローを作ってみようというような意味で表します」）までは進んだものの、その後の本番導入に進まないケースがよくあります。
デモでは動いている。社内でも「便利そう」という反応はある。しかし、いざ業務に組み込もうとすると、対象範囲、データ、評価基準、権限、運用体制の整理に時間がかかり、プロジェクトが意外と進まないということはよくあります。
AWS の生成 AI PoC に関するガイダンスでも、PoC は単なる技術デモではなく、ビジネス価値、データ準備状況、技術的実現性、リスク低減を検証するための取り組みとして説明されています。特に、ビジネス目標と技術指標をつなげること、必要なデータが利用可能で品質も十分か確認すること、評価データを用意することが重要とされています。
「AI で何かやりたい」という状態から始めると、最初のデモはすぐに作れます。社内文書を少し読み込ませる、問い合わせに回答させる、議事録を要約させる、メール文面を作らせるなど。ここまでは、今の生成 AI ならかなり短期間でできます。
しかし、そのデモを本番運用に持っていくとなると、一気に難易度が上がります。
PoC が長引く理由
AI プロジェクトの PoC が長引く理由は、技術そのものが難しいからだけではなく、次のようなことが決まっていないために止まるケースが多いです。
- どの業務を対象にするのか
- その業務は、AI でどの程度自動化してよいのか
- 成功したと判断する基準は何か
- 例えば「成功率 90%」のような、確率的な失敗を許容できる業務かどうか
- どのデータを AI に使わせてよいのか
- 個人情報や機密情報をどう扱うのか
- 誰が最終責任を持つのか
- 本番運用後に、回答品質や利用状況をどう確認するのか
そうすると、PoC を導入する側もいつまでも業務が効率化されませんし、PoC を進める側（社内のプロジェクトチームや「AI 事業部」のような部門だったり、外部のベンダーだったり）もいつまでも納品できないという、双方が損な状況になってしまいます。
そのような状況を回避するには
このようなことを回避するためにも、PoC で本当に検証すべきなのは「AI がそれっぽく動くか」ではなく、その AI が業務の中で使われ続ける仕組みになるかということだと考えています。
従来も、「SaaS のエンタープライズプランを入れたものの、あまり現場で使われていない」ということはよくありました。AI もせっかく良いプランを導入したり、AI システムを開発して導入したりしたのに、結局あまり使われていないという状況になってしまうのはもったいないことです。
OpenAI の Production best practices でも、AI プロジェクトをプロトタイプから本番へ移行するには、API アクセスの保護、スケール可能なアーキテクチャ、セキュリティ・コンプライアンス、データの扱いなどを含めて計画する必要があると説明されています。
Production best practices | OpenAI API
AI プロジェクトで時間がかかる 5 つのポイント
もう少し具体的に考えてみましょう。PoC では、最初の設計で次の 5 つを決めておくのがよいと思います。
1) 業務課題を絞る
最初に時間がかかるのは、「どの業務に AI を使うか」を決めるところです。
たとえば、「社内問い合わせを減らしたい」というテーマだけでは広すぎます。人事規程の問い合わせなのか、情報システム部門への問い合わせなのか、営業資料の探し物なのか、製品仕様の確認なのかによって、必要なデータも評価基準も変わります。
AI は万能ではなく、業務ごとに設計する道具という形で考えます。まずは、対象業務を小さく切り出すことが重要です。
私の感覚では、最初の PoC では「効果が大きい業務」よりも、「失敗しても学びが大きく、関係者が少なく、データを集めやすい業務」から始める方が上手くいきやすいです。
というのも、何か新しいことをするときに、対象と手段の両方が分からないという状況ではカオスになりがちです。分かりやすい対象から始めると、対象はよく分かったものなので、手段（AI をどう使うか）に集中できます。その過程で手段の方の理解が進んでいくので、今度は対象の方を難しいものにする（大きな業務や、複雑な業務フローなど）という形がおすすめです。
2) データを集める
次に時間がかかるのが、データの準備です。
生成 AI は、社内の業務を何も知らない状態では、一般論しか答えられません。これは個人での AI 利用でも同じことで、例えば
- すごく頭が良い恋愛コンサルタント
- 自分のことを知っていて、恋愛遍歴も知ってる昔からの友達
だったら、友達の方が上手く相談に答えてくれる気がします。同じように、
- Claude Opus 4.7 のような最新の大きいモデル（ただし、社内の業務やナレッジは知らない）
- Claude Sonnet 4.6 のような小さいのモデル（社内の業務やナレッジにアクセスできる）
と、モデルの賢さよりもむしろ、対象業務に関する情報を集める方が重要です。
社内規程、業務マニュアル、FAQ、過去の問い合わせ、製品仕様書、営業資料、議事録など、AI に参照させる情報を用意する必要があります。「資料はあるが、どれが最新版か分からない」という問題も合わせて解決することが大事です。
3) 評価基準を作る
AI の PoC でももちろん、評価基準を後回しやなぁなぁにせずに定めることが重要です。
「なんとなく良さそう」「それっぽく答えている」では、本番導入の判断ができません。AI が回答した内容が正しいのか、どの程度なら許容できるのか、どのミスは絶対に避けるべきなのかを決める必要があります。
OpenAI の評価に関する公式ガイドでは、生成 AI は同じ入力でも異なる出力をすることがあるため、従来のソフトウェアテストだけでは不十分であり、構造化されたテストで性能を測ることが重要だと説明されています。また、「雰囲気で評価する」ことはアンチパターン（よくないパターン）として挙げられています。
Evaluation best practices | OpenAI API
この評価基準づくりは AI ベンダーだけではできず、その業務に携わっている方々の協力が必要です。（もちろん、AI ベンダーや社内のプロジェクトチーム側にも、その業務について十分にインタビューする義務はあります）
たとえば、社内規程の回答であれば人事・総務部門の判断が必要です。製品仕様であれば開発・サポート部門の確認が必要です。営業資料であれば、営業企画や法務の観点も必要になるかもしれません。
AI プロジェクトは、技術プロジェクトであると同時に、業務設計プロジェクトでもあります。
4) セキュリティと権限を決める
最近特に関心の多い、セキュリティと権限についてです。
AI に社内データを扱わせる場合、「誰が何を見てよいか」を決める必要があります。全社員が見てよい情報なのか、部署限定なのか、役職者だけなのか、顧客情報や個人情報を含むのか。
ここを曖昧にしたまま進めると、PoC では便利に見えても、本番導入時に情報システム部門や法務部門で止まってしまいます。中堅 〜 大手企業の場合だと、便利になるがインシデントのリスクが高くなるという場合は導入しない方が合理的にも良いでしょう。（企業が大きければ大きいほど、過去の実績や現在の規模などが参入障壁になって、高い利益を生むことができるという構造があるため）
Azure AI Foundry（旧 Azure AI Studio 系の名称で知られていた Microsoft の生成 AI プラットフォーム。ドキュメント上は Microsoft Foundry と表記される場合もあります）の生成 AI オブザーバビリティに関するドキュメントでも、AI アプリケーションのライフサイクルでは、正確性・関連性・安全性を確保するために評価フレームワークが必要であり、開発から本番監視まで、ログ、トレース、モデル出力、評価指標を収集して可視化する考え方が示されています。
Observability in Generative AI – Microsoft Foundry | Microsoft Learn
AI を本番で使うなら、作って終わりではなく、運用中に観測できる状態にする必要があります。これは処理だけでなく、権限周りについてもです。
5) 現場の業務フローに入れる
最後に時間がかかるのが、現場の業務フローへの組み込みです。
AI チャットを作ったとしても、社員がどこで使うのかが決まっていなければ、結局使われません。Slack なのか、Teams なのか、社内ポータルなのか、WordPress サイト上のチャットボットなのか、既存の業務システムの中なのか。
また、AI の回答で完結させるのか、人間に引き継ぐのか、問い合わせ履歴を残すのか、回答が間違っていたときに誰が直すのか、といった運用も決める必要があります。
ここまで決めて初めて、AI プロジェクトは「デモ」から「業務システム」に近づいていきます。
PoC の成果物は、AI デモではなく業務改善の設計図
AI プロジェクトで時間がかかるのは、業務課題の整理、データ準備、評価基準づくり、セキュリティ設計、現場への組み込みなどです。そして、ここを丁寧に進めないと、PoC は「すごそうなデモ」で終わってしまい、本番運用にはつながりません。
- どの業務に効果がありそうか
- どのデータが必要か
- どの程度の精度なら使えるか
- どの部署の協力が必要か
- どのセキュリティ要件を満たす必要があるか
- 本番化する場合、どのくらいの運用体制が必要か
こうしたことが見えるようになることが、PoC の価値です。
逆に言えば、PoC でこれらが明らかにならなければ、「AI が動いた」というだけで終わってしまいます。
AI 活用を成功させるためには、最初から大きな変革を狙う必要はありません。まずは小さな業務を選び、データを集め、評価基準を作り、現場で試し、改善していくことが重要であり、そこにおいて、エンジニア / コンサルタントと、社内の業務に携わってる方々の協力や泥臭い調整が重要になります。
最新コラム、最新ニュース、おすすめセミナー等を毎月配信する公式メルマガ
「月刊KUSANAGI」の配信購読はこちら。
企業でWordPressを利用している方にも、制作されている方にもおすすめ！
WordPressやWebの情報がぎっしり詰まった情報を定期的にお届けします。
GMOプライム・ストラテジーでは、こうした AI 活用の基盤づくりから運用までを支援するサービスを提供しています。ぜひご活用いただき、AI 導入のきっかけにしてみてください。
- MAGATAMA Stack（セキュアで高性能な汎用 RAG 製品。オンプレミスやクラウドに構築可能。パイロット版リリースを目指す開発段階）
- MAGATAMA WordPress プラグイン（WordPress に AI チャットボットをかんたん設置。リリース予定）
- AI ソリューション（業務課題の整理から PoC 開発・運用まで一貫支援）
【この記事の著者】
ゼノクリース合同会社 代表（Web）
齋藤智樹
在学中から高校や予備校、IT 企業に携わり、講師とソフトウェアエンジニアとして活動。
大学卒業後 (2020年4月〜) はフリーランスエンジニアとして活動を始め、以下のような幅広い業務を行う。2021年3月に、業務を拡大させるためにゼノクリース合同会社を設立。スタディングテックの WEB 開発コース主任講師も務める。
