Rob Collie、CEO兼創業者（P3 Adaptive）および『Fair Game』著者 – インタビューシリーズ

Rob Collie は、データと AI の Microsoft ソリューション パートナーであり、数百の中堅企業と Fortune 1000 クライアントにサービスを提供する P3 Adaptive の創業者兼 CEO です。かつて Microsoft の Excel、Bing、Power BI チームでエンジニアリングリーダーを務め、Microsoft を退社した後は Power BI の波を牽引しました。これまでにビジネス・テクノロジーに関する書籍を 3 冊執筆（累計 92,000 部以上販売）しています。また、Raw Data with Rob Collie ポッドキャストを主催しています。2026 年 8 月出版の第 4 弾書籍 Fair Game: ビジネスに合わせた AI カスタマイズは思ったより簡単 では、AI 時代における実務家としての信頼性を示しています。

Microsoft で 10 年以上にわたり Excel と Power BI のビジネスインテリジェンス機能開発に携わり、2013 年に P3 Adaptive を創業しました。その後、Microsoft 内でソフトウェアを構築する立場からクライアントのデータ課題を解決する立場へ転換したことは、エンタープライズ AI に対する現在の見方にどのような影響を与えましたか？

Microsoft でプロダクトチームを率いていたとき、私たちは「全世界で機能しなければならない」ソフトウェアを作っていました。そのため、特定の顧客のニーズに合わせることはできませんでした。かつては「3 億人が受け入れられるトッピングのピザを注文する」ことに例えていました。このような仕事には必然的に最低共通分母的な雰囲気があり、個々の顧客からは距離が生まれます。

大舞台で働くことには確かに名誉がありますが、特定のクライアントが独自の野望を実現する手助けをするほど感情的に満足できることはありません。クライアントと密に協働することで、彼らの成功に自ら投資し、汎用的なビッグソフトウェアでは決して実現できない創造的な解決策を探求できます。知的刺激が多く、クライアントとの直接的なつながりが勝利をはるかに充実したものにします。

しかし、責任も大きくなります。Microsoft では、1 人の不満顧客は単なる統計に過ぎず、私は日々クレームを「仕事の一部」として軽く流していました。P3 Adaptive では、1 人の不満クライアントは私たちが失敗したことを意味します。統計はありません。すべての関係に対して責任を負う必要があります。

Microsoft で得た貴重な経験は多く、決して交換したくはありませんが、今は自分を「回復中のソフトウェアエンジニア」と呼んでいます。なぜなら、成功の定義が全く異なるからです。

そしてそれが、私がエンタープライズ AI に持ち込むレンズです。既製品 AI は、300 億人向けの究極のピザです――誰にでも価値があるように設計された驚異的なものですが、誰にも合わせてはいません。しかし、組織的な AI の勝利はカスタマイズから生まれます――特定の企業に寄り添い、その AI を その データ、その プロセス、その 定義に合わせることです。私はその分断の両側でキャリアを積んできたので、エンタープライズ AI がどちらで勝つかについては疑いの余地がありません。

『Fair Game』では、多くの企業が汎用チャットボットのライセンスを配布することで AI に逆行していると主張しています。汎用 AI アシスタントの限界はどこにあり、ビジネスがカスタマイズを必要とするサインは何ですか？

汎用 AI は、ビジネス以外のすべてに博士号を持っています。インターネット全体を読んでいますが、インターネットには「アクティブ顧客」の定義や価格ロジック、運用プロセス、二つのシステムが食い違ったときにどちらを信頼すべきかといった、貴社固有の情報が欠けています。これらの知識は公開されません。したがって、個人利用では世界を席巻する汎用 AI でも、実際のビジネス利用には不足しており、両者のギャップは落胆と混乱を招きます。

今日、ほとんどの企業が「AI への対策はサブスクリプションを購入して様子を見る」ことだと答えています。これは自然な第一歩であり、批判的になるつもりはありません。むしろ同情的です――誰も汎用サブスクリプションだけでは不十分である理由を説明する時間を取っていません。したがって、企業は「手に入るものを試し、十分でないことに気づく」段階にいると言えるでしょう。

解決策は AI モデル自体に手を加えることではありません――LLM 研究者になる必要はありません。モデルを取り巻くすべて、すなわちデータ、平易な英語で書かれた指示、そして通常のソフトウェアが重要です。今週 5 回目に同じコンテキストをチャットボットに入力する自分に気づいたときがサインです。何度も再説明していることこそ、カスタムシステムがすでに知っているべきことです――起動するたびに。

「Crafter（クラフター）」という用語は、従来のソフトウェア開発者ではなく、価値あるカスタム AI システムを構築できるデータに精通したビジネスプロフェッショナルを指すと説明しています。Crafter を特徴付ける資質は何で、リーダーは既存の人材の中からどのように見つけ出すべきですか？

Crafter とは、ツールで問題解決したいという衝動を持って生まれつく人のことです。私の経験では、知識労働者 16 人に 1 人はその資質を持っています。彼らはかつて Excel のパワーユーザーであり、次に Power BI 世代、そして IT が「シャドウ IT」と呼んだ人々です。アナリスト、財務モデラー、オペレーションリーダー――ビジネスの中で育ち、ツール活用に才能を見出した人たちです。

2 つの特性が AI 作業に最適です。第一はシステム思考――散らかったプロセスを入力・ルール・出力に自然に分解できる点で、プロのソフトウェア開発者と似ています。第二はビジネスへの根ざし――CFO が実際に注視する数値や、質問者が本当に求めているものを理解しています。これらはブートキャンプで教えられるものではありません。

見つけ方はシートを追うことです。現在の貴社には、重要なワークフローの中心にスプレッドシート、ダッシュボード、オートメーションがあります。IT が作ったものではなく、すべてに作者がいます。そこから探し始め、彼らがカスタム AI ソリューションにどのように才能を転用できるかを評価してください。

なぜ Crafter が開発者だけでなく、多くの社内 AI プロジェクトをリードするのに最適だと考えるのか、またビジネスエキスパート、データチーム、ソフトウェアエンジニア、IT 部門、セキュリティチームの責任分担はどうすべきか？

カスタム AI の難しい部分はコードではなくコンテキストです。AI プロジェクトで最も高いインパクトを持つ活動は、システムがビジネスについて何を知るべきかを決めることです。Crafter はその知識を生まれながらに持っています。数段階離れた組織図上の優秀なエンジニアは、オペレーションリーダーが直感的に知っていることを学ぶために何ヶ月ものインタビューが必要です。

しかし、これは「開発者は不要」という話では決してありません。私が推奨する労働分担は 3 つの要因に基づき、年功序列や性格では決めません――再利用性、複雑性、機密性 が高まるほどプロの開発者が関与します。顧客向け、機密データに触れる、自律的に意思決定するものはすべて開発者の領域であり、エンジニアリングスキルは増えるほど価値が高まります。ビジネスプロセスのニュアンスが支配的な領域は Crafter が主導します。

また、過小評価されがちな中間領域があります――Crafter が構築し、開発者が監査する形です。IT とセキュリティはプロジェクトを承認するゲートキーパーではなく、舗装された道路を所有すべきです。認可されたプラットフォーム、データアクセスルール、レビューのチェックポイントを提供し、問題に最も近い人々に構築を任せます。全体を成熟度モデルとして捉え、フェンスではなくパイプラインと考えてください。

カスタム AI は企業固有の用語、指標、プロセス、組織知識へのアクセスが必要です。セマンティックモデルや既存のビジネスインテリジェンス基盤は、AI に企業を正確に理解させる上でどのような役割を果たしますか？

それらはデコーダーリングです。現在、貴社の定義――「アクティブ顧客」とは何か、粗利益に含めるコストはどれか――は人々の頭と千差万別のスプレッドシートに散在しています。AI エージェントは、これらの定義が機械が信頼できる形で文書化されるまで、データを正しく推論できません。業界ではこの領域を「コンテキストエンジニアリング」と呼び始めており、訳すなら「ビジネスが知っていることを構造化し、AI が実際に利用できるようにする作業」です。アナリストは新しい概念のように語りますが、BI の実務者は 15 年前から同様のことをやってきました。

この「見える」良いニュースは、BI 時代（特に Power BI）に投資していれば、すでに先行優位を持っている可能性があるということです。しっかり構築されたセマンティックモデルは、エージェントが必要とする機械可読なビジネス意味の捕捉そのものです。セマンティック層を後回しにした企業は、今や「退屈な」定義作業が AI への入り口の料金所になっていることに気づきます。そしてこの作業はビジネスに深く特化しているため、耐久的な優位性となります。ベンダーは同じモデルを売れますが、あなた自身の定義は誰も売れません。

カスタム AI エディタ「Eddie」を構築し、Fair Game の執筆を支援しました。そのシステムは執筆プロセスで具体的に何を行い、成功と失敗からどんな設計教訓を得ましたか？

はっきり言うと、私は本の各段落をすべて一から書きましたが、Eddie は主に待機していました。章の全体セクションを書き上げてから「彼」に読んでもらうこともあれば、数分ごとにアイデアを投げかけることもありました。重要なのは、Eddie が 24 時間体制で待機していたことです。午前 3 時でも午後 1 時でも同じようにフィードバックを得られ、1 分以内に返答してくれました。全体で少なくとも 30 回は原稿を読んだと推測しています。人間なら到底できない仕事です――人間はそれを「したい」とは思わないからです。

彼は第 3 章で私が約束したことを追跡し、第 12 章で忘れたと指摘しました。私の執筆スタイルを学習し、最良の自分の声を保つよう強制しました。怠惰なときや、無駄に時間を費やすときも指摘してくれました。時には本当に意見が食い違い、Eddie が勝つこともありました。

最大の設計教訓は、Eddie の「脳」は英語で書かれ、フォルダーに保存されているということです。フィードバックが一般的すぎる、レジスターが合わない、すでに述べたルールを忘れた、といったミスが出たときは、修正を書き留めて永続的なコンテキストに組み込むだけでした。失敗は AI の失敗ではなく、私が教えるのを怠ったギャップでした。このループ――ミスに気づき、教訓を符号化し、定着させる――がミニチュア版カスタム AI の全工程です。だからこそ、広報、競合調査、ウェブメッセージ用に専門化した Eddie を作り上げました。基盤となる LLM は同じですが、専門領域が異なります。

多くの組織は、カスタム AI に取り組む前にデータを完全にクリーンアップし、集中化しなければならないと考えています。実際に開始するために必要なデータ準備の程度はどれくらいで、完璧な基盤を待たずに価値を生み出すにはどうすればよいですか？

データの「完璧さ」は前提条件ではありません。むしろ、完璧は決して訪れないので、良いニュースです。多くのコンサルタントが勧めるように、まず完璧なデータ資産を構築しようとすると、「配管だけを作る」ことになり、結局蛇口を設置したときに配管がそこに無いという事態に陥ります。

当社は「蛇口優先」アプローチを推奨します。具体的なユースケースを選び、インフラからではなくビジネスインパクトから逆算します。そのユースケースで MVP を構築し、最小限の新インフラで実装します。MVP を本番レベルになるまでイテレーションし、次にインフラを強化する方法を検討します。これによりビジネスインパクトが迅速に得られ、コストを最小化し、将来のプロジェクトに対する洞察が得られます――蛇口レベルでも配管レベルでも同様です。

カスタム AI のプロトタイプはデモでは印象的に見えても、実際の従業員や変化するデータ、エッジケースに直面すると信頼性が低下します。内部 AI システムを本格稼働させる前に、どのような評価、モニタリング、人間による監督体制を整えるべきですか？

例外的なケースを除けば、デモはソフトウェア時代ほど価値がありません。ソフトウェアのデモは常に過大宣伝されていたのは周知の事実です。AI デモはさらに現実から乖離しています。

AI はワークフローです。特定組織を支える何千ものワークフローほどカスタムなものはありません。「全てを知っている博士号取得者」の比喩に戻すと、新入社員が貴社で効果的になるまでにどれだけの研修と実務経験が必要か、デモだけで測れるものではありません。

したがって、デモは「可能性の芸術」を示すために使い、製品を売り込むためではありません。本当のデモはカスタムソリューションのプロトタイプ、すなわち MVP から始まります。そしてそこから迅速にイテレーションし改善します。

ある時点でソフトローンチやパイロットプログラムに移行します。この段階でモニタリング、評価、監督の重要性が鮮明になります。実際に必要になるものは、最初に想像したものとは大きく異なることが多いです。

企業は Crafter に実験の自由を与える一方で、影の AI システムや重複したワークフロー、セキュリティ脆弱性、保守責任のないツールが増えるのをどう防げますか？

シャドウ IT が生まれた背景は「悪意」ではなく、満たされていない需要への必然的な対応です。Crafter は問題に悩むから構築します――それが遺伝子です。承認された道が 1 年待ちになると、影の AI がレーダーの下で危険に満ちて埋め合わせをします。

したがって、承認されたレーンを「楽な」レーンにします。セキュリティガードレール（ID、データアクセス、ロギング）が組み込まれたプラットフォームを Crafter に提供し、コンプライアンスが便利さと同等になるようにします。軽量レジストリを維持し、個人実験から第二者が依存するものに昇格したら所有者名を記載します。この単一ルールで孤立ツール問題の大半が解消されます。名前が付いたツールは静かに放棄されません。

次にエスカレーションモデルを適用します――実験は自由に行い、ミッション・クリティカルになる（ユーザー増、機密性上昇、自律性拡大）につれて段階的にエンジニアリングレビューを受けます。Crafter はビジネスロジックの所有権を保ち、開発者は必要なハードニングを行います。目指すのは成熟度パイプラインであり、許可プロセスではありません。企業はスプレッドシートで同様の流れを経験しており、Excel を禁止した企業が勝者になるわけではありません。

カスタム AI の最初のイニシアチブを始める企業は、初期ユースケースの選定、プロジェクトが実質的なビジネス価値を提供しているかの測定、そして拡大・再設計・中止の判断をどのように行うべきですか？

クライアントと共に、2 つの出発点を用意しています。

① 誰も手を付けていない仕事を探す――削減したい仕事ではなく、誰もやっていない仕事です。私がマネージャーに好んで聞く質問は「もし 1 人が常にこの課題を監視し、考えてくれたら、どれだけ大きく改善できるだろうか？」というものです。これらはしばしば最良の出発点です。リスクが低く、成功体験を積め、誰も標的にされている感覚がなく、代替案は「人がうまくやってくれる」ではなく「誰もやっていない」ことです（私のエディタ友人 Eddie のように）。

② ダッシュボードをデータエージェントに置き換える。ダッシュボードはシンプルに見えても、実際には期待通りに機能しません。ビジネス質問があるとき、その質問をダッシュボードに変換する作業は大変です。どのダッシュボードが答えを提供するか、その名前は何か、存在すらするか、そして「正しい」ものを見つけても、使い勝手はどうか、何度も操作して複数バージョンをスクリーンショットして全体像を組み立てる必要があります。

AI 時代では、ビジネス質問を自分の言葉で入力（または音声入力）すれば、データエージェントがすべて処理し、1〜2 分で認証済みかつ調査済みの回答（ビジュアル付き）を返します。フォローアップ質問も即座に回答し、会議中に意思決定が可能です。

両方の出発点の共通点は、従業員が抵抗せずに受け入れる痛点にアプローチすることです。初期 AI イニシアチブが不信感を生むべきではなく、むしろ従業員をテーブルに呼び込み、改善案や新プロジェクトの提案を促すべきです。貴社は何千ものワークフローで構成されており、従業員はそれらを自社以上に理解しています。

拡大・再設計・中止の判断では、自分に優しくしてください。研究によると、成功した AI 導入の多くは失敗を経ているからです。最初のプロジェクトが利益ではなく教訓を提供した場合、それは学費であり、AI が機能しない証拠ではありません。私の経験則は「人が使っているなら拡大する。使っていなければなぜかを探る」ことです。理由は「機能しない」から「理解できない」まで様々で、最終的に「怖い」から来ることもあります。答えは改善、再設計、または中止の判断材料となります。すべてを予測する必要はありません。正直に始めることが重要です。

素晴らしいインタビューをありがとうございました。読者の皆様は Fair Game: ビジネスに合わせた AI カスタマイズは思ったより簡単 もぜひお読みください。