AI 導入の前に考えたいこと

この記事でわかること

• Fluxell が AI・データ活用支援で大切にしている基本姿勢
• AI 導入がうまく進まないときに起きやすいズレ
• Sansan、キーエンス、独立後の経験から見えた共通課題
• 初回相談から実装・運用定着まで、Fluxell がどう進めるか
• どんな企業・担当者と相性がよいか

対象読者

AI 導入やデータ活用を進めたい経営層、DX 担当、部門責任者を想定しています。

特に「AI を使いたい気持ちはあるが、ツール選定から入ってよいのか不安」「PoC で終わらせたくない」「現場で使われる形にしたい」と考えている方に向けて書きます。

なぜ今このテーマを書くのか

最近、Fluxell へのご相談は「ChatGPT を入れたい」「AI チャットボットを作りたい」「社内データを活用したい」といった話から始まることが増えました。

ありがたいことに、AI 導入に前向きな企業が増えています。一方で、話を聞いていくと、本当に詰まっているのはツール選定ではないことが多いと感じています。

• どの業務を変えたいのかが曖昧
• 現場の判断基準が言語化されていない
• データはあるが、意思決定に使われていない
• PoC は作ったが、日常業務に入っていない
• 社内の温度感やリテラシー差を見ないまま進んでいる

こうしたズレは、AI そのものの問題ではなく、AI 導入の入り方の問題だと感じています。

AI やデータは、業務の外側から急に成果を出してくれるものではありません。むしろ、今ある業務や判断の流れを丁寧に見たうえで、どこに入れると人の仕事が前に進むのかを考える必要があると考えています。

この記事は、Fluxell が AI 導入支援にあたって何を見ているかを、最初に整理しておくものです。後続の Insights では、ここで触れる考え方を前提に、具体的な事例や技術テーマも紹介していく予定です。

これまで現場で感じてきた課題

Fluxell のスタンスは、特定のフレームワークから生まれたものではなく、これまで関わってきた現場の経験から少しずつ形作られてきたものです。少し具体的に振り返ります。

Sansan 時代に見ていたもの

新卒で入った Sansan では、最初は大手企業向けのインサイドセールスを担当していました。商談を生むためにヒアリングをしていく中で、強く感じたのは、顧客の最初の言葉だけでは課題を捉えきれないということです。

ある顧客が「情報共有がうまくいかない」と言ったとして、その裏にあるのは部門間の連携の問題かもしれないし、意思決定プロセスの不明確さかもしれないし、既存システムへの諦めかもしれません。相手が言語化できていない部分を、質問と対話で少しずつ明らかにしていく感覚を身につけました。

その後、データアナリストや UX リサーチャーとしてプロダクト側にも関わりましたが、ここでも同じ学びがありました。ユーザーアクションログを見るだけでは分からないことがあり、定量分析とインタビューを合わせることで、ようやくプロダクト課題の解像度が上がる。分析や AI は目的ではなく、意思決定のための手段だと考えるようになったのは、この時期です。

Eight Team で営業や育成、ダッシュボード構築に関わったときには、属人化していた営業プロセスを、再現可能な形に整える経験をしました。優秀メンバーの行動を分析し、それをチームで使える資料や指標に落とし込んでいく仕事です。人の知見を仕組みに変えるという Fluxell の中核的なテーマは、ここで土台ができたと感じています。

キーエンス時代に見ていたもの

その後キーエンスに移り、法人向けデータ分析ソフトウェア KI の導入支援を担当しました。業種も規模も違う、約 50 社のデータ活用プロジェクトに関わりました。

そこで見えたのは、データ活用が進まない理由が「分析スキル不足」だけではないということでした。むしろ多くの場合、詰まっているのは別のところにありました。

• 目的が曖昧なまま、データを集めようとしている
• 数字の定義が部署ごとに違い、議論が噛み合わない
• 分析結果は出るが、誰がそれを使って何を変えるのかが決まっていない
• 現場のやる気や納得感が置いていかれている

つまり、ツールの使い方を教えるだけでは前に進まない。業務理解、テーマ設定、データ整備、KPI 設計、組織への浸透まで含めて見る必要があるとよく分かりました。

独立後に見えたもの

独立してからは、ChatGPT・n8n・Supabase・Python などを使った AI 実装の支援に幅が広がりました。AI 採用アシスタント YORISAI では、書類選考や候補者対応の負荷を下げる仕組みを設計しました。Racing Oracle では、ボートレース予想 AI を、データ収集・モデル学習・評価・推論運用まで含めて、毎日コンテンツが配信されるサービスに落とし込みました。

技術的な領域は広がりましたが、見ている課題は Sansan・キーエンス時代と地続きでした。技術やデータはあるのに、業務の中で使われる形になっていないという共通の課題が、別の表情で繰り返し現れていました。

Fluxell として大切にしている考え方

これらの経験から、Fluxell では AI 導入を支援するときに 4 つの軸を意識しています。

1. 人を見る

AI で何を置き換えるかを考える前に、まずは人がどこで困っているのかを見ます。

• 担当者は何に時間を使っているのか
• どこで判断に迷っているのか
• どの作業が心理的に重いのか
• どの程度のリテラシーを前提にすべきか
• どんな言葉なら社内に伝わるのか

ここを飛ばすと、便利そうだけれど使われない仕組みができあがります。Sansan 時代に身につけた「本音を引き出す」「行動と文脈から課題を推察する」という姿勢が、ここに直接効いています。

2. 業務に乗せる

AI で何ができるかを考えるよりも、既存業務のどこに入ると自然に使われるかを考えます。

• Slack に通知するのか
• Google Sheets に出すのか
• LINE で使うのか
• 管理画面にするのか
• 会議前のレポートに含めるのか
• 既存の承認フローに組み込むのか

道具を導入するのではなく、業務の流れに合わせて入り口を設計するイメージです。キーエンス時代に学んだ「分析結果を次のアクションにつなげる」観点が、ここに繋がっています。

3. 小さく実装する

最初から大きなシステムにはしません。n8n、GAS、Supabase、Google Sheets、Python、LLM API、Dify、簡易 UI といった選択肢を業務に合わせて組み合わせ、業務で試せる最小単位を作ります。

ただし、小さく作る = 雑に作る ではありません。早く検証し、現場の反応を見て、改善の方向性を掴むために、意図して小さく作ります。完成度のために小ささを使う、というイメージです。

4. 運用に浸透させる

実装して終わりではなく、使われ続ける状態まで見ます。

• 誰が、どのタイミングで使うのか
• 出力結果を誰が確認するのか
• どこまで AI に任せて、どこから人が判断するのか
• 例外時はどうするのか
• 改善要望をどう拾うのか

独立後の AI チャットボット、社内 RAG、生成 AI 動画パイプライン、Racing Oracle のような運用型サービスでは、ここまで含めて設計しないと、せっかく作ったものが使われずに終わります。

これら 4 つは、独立した工程というよりも、見るべき視点として常に同時に意識しているものです。Fluxell が見ているのは AI ツール単体ではなく、人・業務・データ・実装・運用がつながった状態だと考えています。

実務でどう反映しているか

考え方だけだと抽象的なので、実際の支援プロセスにも触れておきます。

初回ヒアリングで聞いていること

最初のお打ち合わせでは、「何を作りたいか」だけを聞かないようにしています。要件をそのまま受け取ると、まだ言葉になっていない課題が抜け落ちることが多いためです。

聞く観点は、たとえばこんなところです。

• 今どんな業務があるか
• どこに時間がかかっているか
• 誰が困っているか
• 何を判断しているか
• どの資料やデータを見ているか
• すでに試したことはあるか
• 社内で誰を巻き込む必要があるか

要件を聞くというより、業務の地図を一緒に描くフェーズだと考えています。

課題整理

ヒアリング後は、相談内容をそのまま実装要件にはしません。次のように分けて整理します。

• 業務課題
• データ課題
• AI で支援できる部分
• 人が判断すべき部分
• すぐ作れるもの
• 先に確認すべきもの
• 運用で詰まりそうなもの

ここで「無理に AI 化しない」という選択肢を持っておくことも大切にしています。

PoC の作り方

PoC は見栄えよりも「実務で試せること」を重視します。たとえば、採用なら候補者情報の整理や一次スクリーニングの補助、社内問い合わせならまずよくある質問の検索補助、データ分析なら予測モデルより先に判断指標の可視化、といった形です。

技術スタックは案件ごとに変わりますが、選定の基準は常に「業務に合うかどうか」です。技術名の羅列ではなく、業務に合う手段を選ぶ、という姿勢で進めています。

どんな人・企業と相性がよいか

合うケースと、合わないかもしれないケースの両方を書いておきます。誇張せず、誠実に判断していただくためです。

相性がよいと感じるケース

• 業務改善や AI 活用に関心はあるが、何から始めるか整理したい企業
• 現場に深い知見はあるが、それを仕組みにできていない企業
• データはあるが、意思決定やアクションにつなげきれていない企業
• PoC だけでなく、実装・運用定着まで見たい企業
• 社内に技術者は少ないが、業務理解の深い担当者がいる企業
• 経営と現場の間を翻訳できる外部パートナーを探している企業

合わないかもしれないケース

• とにかく安くツールだけ導入したい
• 仕様書どおりの開発だけを依頼したい
• 業務整理やヒアリングには時間を使いたくない
• 現場の運用を変えるつもりはない
• AI にすべて任せれば良いと考えている

Fluxell の支援は、きれいな要件を受け取ってそのまま作るというより、まだ言葉になりきっていない課題を一緒に整理し、使える形にしていく関わり方に近いです。

今後どのような価値を提供したいか

提供したい価値はシンプルで、AI やデータを使って、現場にある知見を「使われる仕組み」に変えることです。

今後は、採用・営業・社内問い合わせ・データ分析・業務自動化・AI 研修・AI プロダクト開発・コンテンツ生成・現場知見のナレッジ化 といった領域で、少しずつ事例を増やしていきたいと考えています。

ただ、何でもできます、という方向にはあえて広げません。共通しているのは、人が持っている知見や判断を、AI・データ・プロダクトで再現可能にすることで、ここは変わらず軸として持ち続けたい部分です。

まとめ

• AI やデータは目的ではなく、現場の判断や知見を仕組みに変えるための手段です
• 大切なのは、業務、人、データの流れを丁寧に読み解くこと
• そのうえで、業務に乗る形で小さく実装し、運用に浸透させる
• Fluxell は、その一連の流れを伴走する事業者です

まずは、自社の業務の中でどこに時間がかかっているのか、どこで判断が属人化しているのかを整理するだけでも、AI 活用の方向性は見えやすくなります。

この考え方を前提に、今後の Insights では、より具体的なテーマも紹介していきます。たとえば現場の知見を仕組みに変えるという視点や、相談から実装・運用までの進め方については別の記事に切り出して書いていますので、興味のある方は併せてご覧ください。

ご相談について

AI 導入、データ活用、業務自動化、AI プロダクト開発について、まだ要件が固まっていない段階でも構いません。

「この業務を少しでも楽にしたい」「社内の知見を仕組みにしたい」「AI を使える形に落としたい」といった段階から、課題整理をご一緒できます。お気軽に お問い合わせ よりご連絡ください。