AI Innovators Circle 第7回｜AI導入企業の88%が直面する「成果の壁」②
※このレポートは音声データを元にAIエージェントがライティングを行っております。
PoCを目的化した瞬間、AI導入は止まる――日本企業に必要な「点から線へ」の転換
2026年5月28日に開催された「AI Innovators Circle」第7回。キーノートに続く対談では、クラスメソッド株式会社の武田信夫氏と、Synthesyの馬渕邦美が「日本のAI導入実情とDevRevの可能性」をテーマに議論した。
生成AIを取り巻く技術は、短期間で大きく進化している。一方、企業の現場では、PoCから本番運用へ進めないケースが少なくない。
技術が足りないのか。経営判断が遅いのか。それとも、PoCの設計そのものに問題があるのか。クラウドとAIの実装現場を知る武田氏の発言から、日本企業が直面する構造的な課題が浮かび上がった。
「クラウドインテグレーター」として、実装の現場を見る
武田氏が所属するクラスメソッドは、創業約22年。AWSのパートナーとして知られる一方、Google CloudやMicrosoft Azureにも対応し、マルチクラウド化を進めている。AnthropicおよびDevRevともパートナー関係にあるという。
武田氏は、業務効率化ソリューション部とゲームソリューション部を率いる。前職はナムコで、現在もゲーム業界の顧客支援を強みの一つとしている。
対談は、武田氏による印象的な自己紹介から始まった。
「我々は違いますよと。クラウドインテグレーターをやるといいますと、まるで雲をつかむような話をいつもやっている」
一般的なシステムインテグレーションではなく、クラウドを前提に企業の業務やシステムを設計する。その立場から、AIも単一製品だけで完結するものではないと武田氏は見る。
AnthropicとDevRevの双方とパートナー関係を結ぶ理由についても、明確に答えた。
「どっちを使うという話ではなくて、共存する話なんですよね」
基盤モデルと業務基盤は競合するのではなく、役割が異なる。高性能なAIモデルを、企業のデータ、権限、業務フローへどう接続するかという問題が残るからだ。
DevRevを理解する二つの鍵
武田氏がDevRevについて繰り返し強調したのが、ナレッジグラフとシェアドメモリーである。
ナレッジグラフは、顧客、製品、チケット、担当者、文書などの関係性を構造化する仕組みだ。シェアドメモリーは、個人がAIと行ったやり取りや、組織に蓄積された知識を、権限に応じてチームで利用するという考え方である。
「一人の開発者、一人の営業の困りごとは、その人、そのポジションの中で完結しがちなんです。DevRevのコンセプトは、いろいろな場所を横断しながらサービスをつなぐところからスタートしている」
企業内の課題は、部門の中だけで完結しない。
顧客の問い合わせは、サポート部門だけの情報ではなく、製品開発や営業にとっても重要である。営業が得た顧客の反応は、マーケティングや経営判断にも関わる。
しかし、部門ごとにシステムとデータが分かれていると、情報は担当者の中に閉じる。ナレッジグラフとシェアドメモリーは、その断絶を埋めるための基盤として紹介された。
武田氏は、基盤モデルと業務システムの関係を自動車に例えた。
「Claudeを使えばいいという人は世の中にたくさんいると思うんですけども、速く行こうとすると、それにやっぱり機能が付く」
標準的な自動車でも、多くの用途には十分対応できる。しかし、より高い速度、安定性、制御性を求めるなら、用途に合わせた装備や調整が必要になる。
同様に、高性能な基盤モデルを使うだけで十分な業務もある。一方、企業全体で安全かつ継続的に利用するには、データ統合、権限、監査、共有メモリーといった周辺の設計が必要になるという考え方だ。
半年前の常識が、すでに通用しない
対談では、直近数カ月のAIツールの変化も取り上げられた。
Claude Code、Gemini、Codexなど、開発支援を中心とするAIツールの能力は短期間で大きく向上している。以前の「バイブコーディング」と呼ばれた使い方と比べても、実行できる範囲や自律性が変わってきたという。
企業向け市場でも、SalesforceのAgentforceをはじめ、各社がAIエージェントを打ち出している。NVIDIAや大手クラウド事業者も、エージェントを支える基盤やモデルを強化している。
「生成AIが最初に出た時に『もう見切った』と離脱した人たちがいたが、実際には見切れていなかった」
初期の生成AIを触り、「業務には使えない」と判断した企業や担当者もいる。しかし、当時の評価を現在の技術へそのまま当てはめることはできない。
一方で、技術が進歩したからといって、企業導入が自動的に成功するわけではない。むしろ、利用できる選択肢が増えたことで、目的と設計の重要性は高まっている。
PoCは手段であり、ゴールではない
今回のテーマである「PoC止まり」について、武田氏は問題の核心を次のように表現した。
「PoCって手段だから、PoC止まりになりがちなんです」
PoCを始める前に、何を変えたいのか。終了後に、どの状態へ移行するのか。導入対象となる業務や、期待する効果は何か。
こうした出発点と到達点が曖昧なままでは、PoCの結果を評価できない。「動いた」「一定の精度が出た」という確認だけで終わり、本番投資を判断する材料にならないからだ。
武田氏は、AIの理解と実践の違いを坂道発進に例えた。
「頭で理解している状態って、何も進まないと思っていて」
運転方法を知識として理解していても、実際に操作できるとは限らない。AIも同じで、記事やセミナーで知識を得るだけでは、業務への組み込み方は身に付かない。
重要なのは、実際に触り、失敗し、期待どおりに動かない理由を理解することだという。
PoCを卒業する三つの条件
武田氏は、PoCから本番へ進むためのポイントを三つに整理した。
1．点ではなく、線で捉える
単発のユースケースとしてAIを導入すると、その業務だけで完結し、データも効果も広がらない。
例えば、会議録の要約だけを自動化しても、その内容がタスク管理、営業活動、製品改善につながらなければ、業務全体の変化にはならない。
AIを既存の業務フローへ組み込み、前後のプロセスと接続することで、PoCは継続的な仕組みになる。
2．文脈とデータをつなぐ
AIの回答は、与えられる文脈によって大きく変わる。
営業担当者、カスタマーサポート、開発者では、同じ顧客を見ても必要な情報が異なる。各部門が持つ視点とデータを接続しなければ、AIは部分的な回答しか返せない。
モデルへ投入するデータ量を増やすだけではなく、「誰が」「何の目的で」「どの情報を必要としているのか」を構造化することが重要になる。
3．個人で止めない
個人がAIを使って成果を出しても、そのプロンプト、判断基準、参照データが共有されなければ、組織の能力にはならない。
「チームで動いているので、チームの情報をどう活用するかが課題です」
AI活用を組織へ広げるには、個人の会話履歴をそのまま公開するのではなく、再利用できる知識やワークフローとして蓄積する必要がある。
シェアドメモリーは、AIの利用を個人技から組織能力へ変えるための考え方として位置付けられた。
AIに「役割」を渡す
対談で特に印象的だったのが、生成AIへ役割を与えるという議論である。
「小学生には小学生に合わせにいくんですよ。中学生には中学生に合わせにいくんですよ」
AIは、利用者の質問や前提に合わせて回答する。役割や評価基準を与えずに使うと、利用者と同じ目線にとどまり、考えを深める相手にならない場合がある。
対策は、意図的に異なる役割を設定することだ。
企画を評価させるなら、経営者、顧客、法務責任者などの立場を与える。文章を改善するなら、編集者や構成作家として批評させる。複数のエージェントを使う場合も、それぞれの責任範囲を明確にする。
武田氏は、「社長.md」「人事.md」のようなMarkdownファイルで役割や判断基準を定義する方法を実践しているという。
AIエージェントが増えるほど、人間の役割はすべてを実行する担当者から、目的と役割を設計し、結果を監督する立場へ移っていく。
一方、部署ごとに独立してAIエージェントを導入すると、データ、目的、判断基準がばらばらになる。複数のPoCが同時に進んでも、互いに連携できず、組織全体では効果を生まないという問題も指摘された。
見落とされ始めたトークンコスト
馬渕は、今後の企業AIで「トークン」が重要な経営指標になる可能性を指摘した。
現在は定額制のサービスも多いが、利用量の増加に伴い、従量課金や利用制限が広がる可能性がある。AIを人件費削減の手段とだけ捉えると、想定以上の利用コストが発生することもある。
武田氏も、自らの利用経験を率直に語った。
「Claude Codeを使って、OpenAIのツールも使って、何とか使っていたら、あっという間にトークンが大変なことになる」
AIエージェントは、人間が操作しなくても複数回の検索、生成、修正を行う。そのため、1回の指示で消費するトークンが見えにくい。
今後は、利用人数だけでなく、業務単位のトークン消費、得られた効果、不要な検索や生成の割合を管理する必要がある。
ナレッジグラフや共有メモリーは、必要な情報へ短い経路で到達し、同じ処理を繰り返さないための仕組みとしても重要になる。
データサイロと属人化を同時に解く
馬渕は、AIエージェント導入を成功させる条件として、経営のコミットメント、事業価値、ガバナンス、現場定着、人材育成、継続改善などを挙げた。
その中でも、DevRevの特徴と最も重なるのが「データサイロをつなぐ基盤」であると指摘した。
武田氏も、「つなぐ」ことが重要だと応じた。
部門ごとのデータが分断されているだけでなく、企業では特定の担当者だけが持つノウハウも多い。担当者が退職・異動すれば、業務の背景や判断基準が失われる。
いわゆる「Excelマクロ職人」のように、一人しか仕組みを理解していない状態は、短期的には効率的でも、長期的には事業継続上のリスクになる。
AIへ知識を渡す際にも、単なるファイルの保管ではなく、業務上の関係性や利用履歴を含めて残す必要がある。ナレッジグラフとシェアドメモリーは、データサイロと属人化の双方へ対応する基盤として期待された。
「分析したい」の前に、目指す姿を決める
クラスメソッドに寄せられる相談の中で、対応が難しいものの一つが「データ分析をしたい」という依頼だと武田氏は語った。
分析によって把握できるのは、基本的には現在地である。どの方向へ進むのか、どの事業を伸ばすのか、何を変えるのかは、経営側が決めなければならない。
目指す姿が曖昧なままPoCを始めると、「分析できた」「AIが動いた」こと自体が成果になってしまう。
PoCの前に必要なのは、導入する製品を決めることではなく、事業上の目的と、変えたい業務を定義することだ。
戦略と実装を分離しない
対談の終盤、武田氏は企業変革に必要な支援について次のように語った。
「会社が変わろうとすると、戦略支援と実装支援の両方が必要」
経営層がAI戦略を掲げても、現場の業務やシステムへ落とし込めなければ成果は出ない。一方、現場が個別のツールを導入しても、経営上の目的と結び付かなければPoCで止まる。
Synthesyが経営・戦略面を支援し、クラスメソッドが技術と実装を支援するという役割分担は、こうした分断を埋める協業モデルとして紹介された。
武田氏は最後に、再び自動車の比喩へ戻った。
標準的な基盤モデルだけで十分な企業もある。しかし、本格的に業務へ組み込み、速度、コスト、安全性を管理するなら、企業固有のデータやワークフローに合わせた基盤が必要になる。
PoC卒業の鍵は、より優れたデモをつくることではない。点在するAI活用を業務の線へ変え、個人の知識を組織の資産へ変えることにある。
後編へ
対談で示された「点ではなく線で捉える」「個人で止めない」という論点は、続くパネルディスカッションで技術的に掘り下げられた。
後編では、RAGの限界、マルチエージェントの設計、アクセス権限、監査、暗黙知の継承を通じて、AIを本番環境で使うための条件を考える。
主催：シンセシー株式会社
公式サイト：https://synthesy.co.jp/
※本レポートは当日の文字起こしをもとに構成しています。製品・サービスに関する説明および将来見通しは、登壇者の発言に基づいています。
