01
情シス2〜3名で、一日の半分近くを問い合わせ対応に使っている
一件一件は短いが、仕事が細切れになる。セキュリティ対策や基盤改善のようなまとまった時間が要る仕事が進まない。
少人数の情シスに、問い合わせが集中している
同じ質問に何度も答える仕事を、情シスから減らします
社内マニュアル・申請ルール・システム情報を参照してAIが一次回答し、権限変更や個別判断が必要なものは情シスへ引き継ぐ社内問い合わせシステムを作ります。全社の文書を整理してから始める必要はありません。問い合わせの多い一領域から動かします。
まず「アカウント・SaaS関連」のような一領域。AIが答える範囲と人へ渡す範囲を業務ごとに受入条件として先に書きます。
最初の対象
問い合わせの多い一領域
検証期間
4〜6週間
検証費用の目安
200〜400万円程度
01PAIN POINTS
こんな状態になっていませんか
この状況で相談をいただくことが多い順に挙げています
02
同じ質問が、違う社員から、違う言葉で、月に何度も来る
FAQやマニュアルは作ったが、社員は読まずにチャットで直接聞いてくる。
03
SaaSが増えて、手順がどこに書いてあるか情シス自身も把握しきれていない
古い手順が残っていて、読んだ社員がかえって混乱することがある。
04
権限やアカウントの手続きに、部署や役職ごとの例外が多い
FAQには書き切れず、結局「情シスに個別相談」になっている。
なぜ、情シスに問い合わせが集中するのか
担当者の頑張りの問題ではなく、構造の問題
情シスは、会社で唯一「全部のシステムを知っている」とみなされる部署です。どこに聞けばいいか分からない質問がすべて来ます。
情シスの人数は、会社の規模に比例して増えない
従業員が100名から300名になっても情シスは2名のまま、ということが普通に起きます。SaaSの数だけは増え続けるので、問い合わせの種類も増えます。
FAQを作っても、社員は検索しない。検索しても言葉が違って見つからない
資料が複数あってどれが正しいか判断できない。古い手順が残っていて読んだ結果かえって混乱する。情シスが丁寧に答えるほど「聞く方が速い」が強化されます。
生成AIを付けるだけでは、古い資料・権限・例外に対応できない
古い資料と新しい資料を両方読ませれば古い手順を自信を持って答えます。全社員に同じ情報を見せれば管理者向けの手順が一般社員に出ます。「情シスに個別相談」の例外を勝手に一般化することもあります。
BEFORE / AFTER
「システムのことは情シス」で一本化された問い合わせに、一次対応の受け皿を作る
質問の多くは答えが社内のどこかに書いてあります。社員がそれを探さないのは、探すより聞く方が速いからです。
1
今の状態
一日の半分近くが細切れの対応で埋まる
一件一件は数分で終わるが、そのたびに手元の作業が止まる。セキュリティ対策や基盤改善のようなまとまった時間が要る仕事が後ろに押し出される。
2
Beekleの設計
境界を業務ごとに決め、対象領域の資料だけ整える
資料を参照すれば答えられるもの、担当者の操作が要るもの、即座に人へ渡すべきものに分ける。部署・役職で見せる情報を変え、根拠が無い質問には答えず経緯つきで引き継ぐ。
3
導入後
SlackやTeamsから、根拠つきで一次回答が返る
社員は普段いるチャットから質問し、根拠の資料つきで数分以内に一次回答を得る。情シスには判断が要る質問だけが、質問内容と試した検索を添えて届く。
✓
目的は問い合わせゼロではなく、人が判断すべき質問へ情シスの時間を使える状態です。
FAQを作っても、質問は減らないことがある
生成AIを付けるだけでも十分ではない。古い資料、権限、例外の扱いが要る
1
情シスに問い合わせが集中するのは、担当者の頑張りの問題ではなく、構造の問題です
2
情シスは、会社で唯一「全部のシステムを知っている」とみなされる部署です
3
社内FAQを作っても問い合わせが減らない理由は重なっています
情シスに問い合わせが集中するのは、担当者の頑張りの問題ではなく、構造の問題です。
POINT 02
情シスは、会社で唯一「全部のシステムを知っている」とみなされる部署です。社員から見れば「システムのことは情シス」で一本化されているので、どこに聞けばいいか分からない質問がすべて情シスに来ます。質問の多くは答えが社内のどこかに書いてありますが、社員はそれを探しません。探すより聞く方が速いからです。一方で情シスの人数は会社の規模に比例して増えず、SaaSの数だけは増え続けます。
POINT 03
社内FAQを作っても問い合わせが減らない理由は重なっています。社員がFAQを検索しない。検索しても社員の言葉とFAQの言葉が違って見つからない。資料が複数あって、どれが正しいか社員には判断できない。古い手順が残っていて、読んだ結果かえって混乱する。
POINT 04
生成AIを使えば自然な文章で質問でき、言葉の違いは吸収できます。ただ、AIを付けるだけでは十分ではありません。古い資料と新しい資料を両方読ませれば、古い手順を自信を持って答えます。全社員に同じ情報を見せれば、管理者向けの手順が一般社員に出ます。「この場合は情シスに個別相談」と書いてある例外を、AIが勝手に一般化して答えることもあります。外部のヘルプデスク代行やチャットボット製品は定型質問には有効ですが、自社固有の申請ルール、部署ごとの例外、システム構成を参照して答えるには、その情報を参照できる形で持ち、更新し続ける仕組みが要ります。
SERVICE PACKAGE
約束 × 工程 × 成果物を、最初に明確にする
「支援します」だけでは、何を買うのか分かりません。このサービスでどこまで進め、何が手元に残るかを先に共有します。
PROMISE / 約束
対象領域の資料を整え、AIが答える範囲と人へ渡す範囲を業務ごとに決めて、社員が普段いるチャットから根拠つきで一次回答を得られる状態まで作ります。
PROCESS / 工程
- 1.目的・業務ヒアリング（As-Is/To-Be）
- 2.業務を1つ選ぶ
- 3.要求・ストーリー化と受入条件
- 4.動くデモ（PoC）で確かめる
- 5.小さく本番に載せて測る
- 6.運用しながら広げる
DELIVERABLES / 成果物
- ✓問い合わせの分類と境界（受入条件）
- ✓対象領域の資料整理と正本の決定
- ✓部署・役職別の参照権限
- ✓Slack・Teamsからの一次回答と経緯つき引き継ぎ
- ✓答えられなかった質問を資料に戻す運用
- ✓導入前後の指標の比較
SCOPE / 前提・境界
問い合わせの完全無人化は前提にしません。根拠が無い質問には答えず、経緯を添えて情シスへ渡します。全社文書の整理を待たずに一領域から始めます。
どういう仕組みで実現するか
AI USE CASE DESIGN
AIで効く業務を、要件と評価基準で見極める
モデル選定より先に、どの業務をどう変え、何をもって使えると判断するかを確定します。
INPUT
業務フロー
判断基準
例外処理
評価基準
CONNECT
CONNECT
ユースケース設計
CONNECT
DELIVERABLES
✓
動く試作品
✓
社内説明できる材料
1
聞く
徹底ヒアリング
背景・業務・例外を聞き出す
2
絞る
ユースケース確定
効果が出る範囲に絞る
3
描く
設計図に落とす
構造・権限・評価基準を決める
なぜ、作る前に決めるのか
AI開発が止まるのは、モデルの選び間違いだけが理由ではありません。どの業務のどの手間を減らすか、何をもって使えると判断するかを先に決めておくと、動いたけれど本番に進めない、という止まり方を避けられます。決めた基準は、そのまま社内説明の材料になります。
02WHY BEEKLE
なぜBeekleなら、使われる社内問い合わせAIを作れるのか
チャット画面を置くことではなく、境界の設計と、答えられないときの渡し方でお答えします。
01
要件定義から入る。AI・DXが失敗する原因の大半はモデルではなく要件のズレ
誰が、どの場面で、何を見て判断しているかが決まらないまま作り始めると、動くものはできても使われません。ヒアリングでいまの業務の流れ（As-Is）を書き出し、あるべき流れ（To-Be）との差分からアクターとユースケースを定義してから作ります。要求を洗い出して「作る・後回し・作らない」に絞り、作るものだけをユーザーストーリーと受入条件（Gherkin）に落とします。ChatGPTなどのAI検索で要件定義について尋ねたとき、Beekleの記事が最も多く引用されている領域です。
02
同じ構成の社内ヘルプデスクを、実際に動かしている
従業員100名規模のSaaS企業で、月200件以上のIT問い合わせとFAQ150件を対象に社内ヘルプデスクのAI対応を構築しました。定型質問の75%をAIが自動回答し、情シスへの引き継ぎは月50件に、社員の回答待ちは4時間から5分になり、情シスはセキュリティ対策に月30時間を戻せました。これは実案件の実測値です。同じ結果を約束するものではなく、御社の数字はヒアリングの段階で見立てます。
03
PM on Railsで、要求から動作の証拠までを一本でつなぐ
要求カード、ユースケース、ユーザーストーリー、受入条件、実装タスク、テスト結果を切れ目なくつなぐ自社開発のツールを、自社の案件だけでなく外部のお客様の案件でも使っています。「何を作ると言ったか」と「何が動いているか」が常に照合できるので、途中で要件が増えても、どこに影響するかがその場で分かります。
04
RAGを本番で運用してきた知見を使う
データの更新と削除、権限、検索精度の評価、再埋め込み、顧客のクラウド環境や自社インフラでの運用まで、実案件で扱っています。社内問い合わせは「資料が更新され続ける」「見せてよい情報が人によって違う」という、本番運用の難所がそのまま出る領域です。外部のAIサービスに社内文書を送らない構成も設計できます。
05
大手企業の外部セキュリティチェックを、一度で通過した
他社で約3か月停滞していた大手企業のアプリを引き継いで3週間で完成させ、発注元が外部に委託したセキュリティチェックを、指摘による差し戻しなく一度で通過しました。情シスが自分の管轄に入れるシステムとして、確認いただきたい点です。
06
動くものを先に見せる（ゼロスタート）
要件を言葉だけで固めず、ヒアリングの直後に動くプロトタイプを作って画面で確かめます。お客様のヒアリング議事録から提案依頼書を生成し、そのまま1日で動作するデモまで進めて「イメージとずれていない」と評価された案件があります。最初の動くデモは0円で作り、そこから先に進めるかを判断していただけます。
この流れを支えているのが、自社開発のPM on Railsです
PM on Railsとは、もともとBeekle社内で回していた開発の進め方を、AIエージェントで動くようにした仕組みです。打ち合わせで出た要望、決まった条件、作業、確認結果を1か所でつなぐため、仕様が変わってもどこに影響するかを追えます。外部のお客様の案件でも使っています。
PM on Railsの公開サイトを見る（外部提供は準備中）03CASE STUDIES
関係する実績を、事実の範囲で挙げます
この業界での納入実績と、持ち込める経験を分けて書いています
SaaS企業（従業員100名）の社内ヘルプデスクボット
課題
情報システム部門2名で月200件以上のIT問い合わせに対応しており、パスワードリセットや接続設定といった定型質問に追われて、本来やるべきセキュリティ対策やインフラ改善に手が回らない状態が続いていました。
解決策
Slack上でIT関連FAQ150件と社内マニュアルから即答し、答えられない質問だけを担当者にメンションで引き継ぐボットを構築しました。
成果
- 定型質問の75%をAIが自動回答
- 情シスへの引き継ぎが月50件に
- 回答待ちが4時間から5分に
- セキュリティ対策に月30時間を戻せた
Beekleだからできたこと
どこまでAIに任せ、どこから人に渡すかを先に決めてから作ります。線引きのないまま広く任せると、誤った回答で信用を落として使われなくなります。数字は実案件の実測値で、同じ結果を約束するものではありません。御社の数字はヒアリングの段階で見立てます。
他社が約3ヶ月完成できなかった案件を、引き継いで3週間で動く状態へ
課題
先行していた他社ベンダーが約3ヶ月かけても完成に至らず、リリースの目処が立っていませんでした。
解決策
既存コードと要件を整理し直し、バックエンド・フロントエンド・インフラまで一貫して再構築しました。
成果
- 3ヶ月停滞 → 引き継ぎから3週間で動作
- 外部セキュリティ審査を一度で通過
- バックエンドからインフラまで一つの体制
Beekleだからできたこと
情シスが自分の管轄に入れるシステムとして、確認いただきたい点です。この案件では、発注元の大手企業が外部に委託したセキュリティチェックを、指摘による差し戻しなく一度で通過しました。
04SOLUTIONS
Beekleではこうする
ヒアリングとAs-Is/To-Beから入り、1業務に絞って実装し、測ってから広げます
SOLUTION 01
ヒアリングから始め、AIが答える範囲と人へ渡す範囲を受入条件にする
情シスの担当者に、問い合わせが一件届いてから解決するまでの流れをそのままたどってもらいます。どのチャンネルで届き、何を調べ、どこで手続きに回し、どこで手が止まるか。過去の問い合わせを集め、「パスワード再設定の手順」のように資料を参照すれば答えられるもの、「このフォルダへのアクセス権をください」のように担当者の操作が要るもの、「不審なメールを開いてしまった」のように即座に人へ渡すべきものに分けます。AIだけで完結させることより、どこで人へ渡せば安全に運用できるかを重視します。
業務ごとに境界が決まる
答えすぎも答えなさすぎも防ぐ
過去の問い合わせが設計材料になる
SOLUTION 02
対象領域の資料だけを整え、部署・役職に応じて見せる情報を変える
全社文書を整理してから始めるのではなく、たとえば「アカウント・SaaS関連」なら、その領域のマニュアル、FAQ、申請ルールだけを集め、どれが正なのかを情シスと一緒に決めます。社内の認証基盤と連携し、一般社員、管理職、管理者で参照できる資料を分け、管理者向けの手順が一般社員に出ないようにします。
全社文書の整理を待たない
正本が決まる
見せてよい情報が人ごとに違っても対応
SOLUTION 03
答えられないときは無理に答えず、経緯つきで引き継ぐ。資料更新を運用に組み込む
根拠となる資料が見つからない質問には「該当する手順が見つかりませんでした。情シスに引き継ぎます」と返し、質問内容と試した検索を添えて担当者に渡します。情シス側はゼロから聞き直さずに対応を始められます。SaaSの手順変更や規程改定があったときの反映手順を決め、AIが答えられなかった質問を定期的に取り出して資料の追加に回します。使う場所はSlackやTeamsなど、社員がすでにいる場所にします。
引き継ぎ後の対応が速い
古い資料が残らない
新しいツールを開かせない
05FEATURES
このサービスで引き受ける範囲
ヒアリングから、動く仕組みと運用まで
問い合わせのヒアリングと分類
過去の問い合わせを集め、資料で答えられるもの、操作が要るもの、即座に人へ渡すものに分け、境界を受入条件にします。
対象領域の資料整理と正本の決定
一領域のマニュアル、FAQ、申請ルールを集め、どれが正なのかを情シスと一緒に決めます。全社文書の整理は待ちません。
権限連携とSlack・Teamsへの組み込み
社内認証基盤と連携して属性別に参照範囲を分け、社員が普段いるチャットから質問できるようにします。
人への引き継ぎと資料更新の運用
根拠が無い質問は経緯つきで情シスへ。答えられなかった質問を定期的に取り出して資料の追加に回す運用まで設計します。
何を測るか
目的は問い合わせゼロではなく、人が判断すべき質問へ情シスの時間を使える状態
1
情シスへの問い合わせ件数
2
一次回答までの時間と、情シスが回答に使う時間
3
AIから人へ引き継がれた割合
導入前に現状値を取り、導入後に同じ定義で測ります。
01
情シスへの問い合わせ件数
人に届く件数が減るか。
02
一次回答までの時間と、情シスが回答に使う時間
社員が回答を待つ時間。対応時間の合計。
03
AIから人へ引き継がれた割合
境界の設計が妥当か。高すぎれば資料不足、低すぎれば答えすぎを疑います。
04
引き継ぎ後の解決時間
質問内容と経緯が添えられているぶん短くなるか。
向いている会社、向いていない会社
先に線を引いておきます
1
向いている会社
2
向いていない会社
従業員100名以上で情シスが1〜5名、同じ種類の問い合わせが繰り返し届いている会社に向いています。
01
向いている会社
従業員100名以上で、情シスが1〜5名。同じ種類の問い合わせが繰り返し届いている。SaaSの数が増え、手順や申請ルールが分散している。マニュアルやFAQは一応存在するが、社員に読まれていない。SlackやTeamsを全社で使っている。
02
向いていない会社
従業員が50名以下で、問い合わせの件数自体が少ない（FAQの整理で足りることが多いです）。社内ルールや手順が文書として存在せず、すべて担当者の記憶にある（先に文書化から始めることをお勧めします）。情シスの問い合わせ対応を完全に無人化したい（人へ渡す境界を持つ運用を前提にしています）。
費用・期間の考え方
モデルケースと、段階ごとの目安
1
業務整理・初期設計（1〜2週間）
2
1業務の検証・実装（4〜8週間、150〜400万円程度）
3
高難度PoC（6〜12週間、300〜600万円程度）
費用は「業務整理」「1業務の検証・実装」「本番展開」「継続改善」の段階に分けて見積もります。投資判断は「削減できる時間×人件費 −（導入費＋運用費）」がプラスに転じる回収期間で見ます。他社の削減率を当てはめるのではなく、動くデモの段階で御社の業務にどれだけ効くかを確かめてから、本番展開の投資を判断していただきます。
POINT 02
モデルケース: 情シスへの定型問い合わせの一部をAI一次対応にする（4〜6週間、200〜400万円程度）。社員から「アカウント申請」「SaaSの使い方」「社内ルール」などの質問が繰り返し届いている会社を想定します。まずは問い合わせの多い一領域だけを対象にします。たとえばアカウント・社内SaaS関連なら、その領域のマニュアル、FAQ、申請ルールを整理し、AIが一次回答できるようにします。回答できないものは無理に答えず、情シスへ引き継ぎます。検証では、問い合わせ件数、回答までの時間、情シスが回答に使った時間、人への引き継ぎ率を導入前後で比較します。費用は対象部署の範囲、参照する文書の量と分散の度合い、既存SaaSとの連携、部署別の権限管理の複雑さで変わります
POINT 03
TeamsやSlackとの連携、部署別権限、複数業務への拡張、問い合わせ履歴の分析を追加した本番展開の目安は500〜800万円程度です。
POINT 04
別料金になるもの: 御社クラウドやオンプレへの構築費とクラウド利用料、LLMのAPI利用料（月額の従量）、紙資料の電子化やOCR、正本が決まっていない資料の整理作業、APIの無い既存システムとの連携開発、導入後の保守と精度改善（月額）。
POINT 05
上記は、Beekleの過去の開発案件をもとにしたモデルケースです。実際の費用と期間は、対象業務、利用するデータ、既存システムとの連携、精度要件、権限・セキュリティ要件によって変わります。最初から全社導入するのではなく、投資対効果を確認しやすい一業務から始めることを基本としています。
01
業務整理・初期設計（1〜2週間）
実データと業務を確認し、改善対象を決めます。費用は案件内で設計します。
02
1業務の検証・実装（4〜8週間、150〜400万円程度）
一つの業務を実際に動かします。
03
高難度PoC（6〜12週間、300〜600万円程度）
GraphRAG、複雑なデータ、評価設計などが要る場合。
04
本番展開（2〜6か月程度、500〜1,500万円以上）
権限、連携、監視、運用まで含めます。
05
継続改善（月単位、個別見積もり）
評価結果から改善と拡張を続けます。
発注の流れ
相談から本番運用まで、どう進めるか
AI開発は、作る前にどれだけ業務を理解し、ユースケースと評価基準を固められるかで決まります。Beekleはヒアリングから入り、設計した範囲だけを小さく検証して本番化します。
- 1
STEP 1
ヒアリングでユースケースを確定する
現場の作業、判断基準、例外処理、使っているデータを聞き出します。「AIで何か」ではなく、どの業務をどう変えるかまで絞り込みます。
- 2
STEP 2
知識構造・権限・評価基準を設計する
RAGなら文書同士の関係や根拠提示、エージェントなら任せる範囲・承認・ログを設計します。評価データと合格基準も先に決めます。
- 3
STEP 3
設計したユースケースをPoCで検証する
いきなり大きく作らず、決めたユースケースだけを動く形にします。現場で使えるか、削減時間・精度・確認工数・運用負荷を見ながら検証します。
- 4
STEP 4
効果が見込めれば実導入
PoCで効果が確認できたら本番化し、現場で使われる状態まで伴走します。期待した効果が見込めなければ、ここで撤退も判断できます。PoC止まりや過剰投資を避けられるのが、この進め方の狙いです。
✓
技術検証で終わらせず、業務で使える設計に落とす。ここがBeekleの強みです。
06RELATED COLUMNS
もっと詳しく知りたい方へ
このサービスの背景にあるデータ活用の考え方
07FAQ
発注前によくある質問
発注前に確認されやすい論点をまとめています
Q 社内文書が整理されていません。それでも始められますか？ +
始められます。どの資料が正しいのか分からない状態そのものが課題なので、対象領域の資料に限って情シスと一緒に整理します。全社文書を整理してから始める必要はありません。
Q 社員ごとに見せてよい情報が違います。対応できますか？ +
できます。社内の認証基盤と連携し、一般社員、管理職、管理者などの属性で参照できる資料を分けます。管理者向けの手順が一般社員に出ないようにします。
Q AIが間違った手順を答えたらどうなりますか？ +
回答には根拠にした資料を表示し、根拠が見つからない質問には答えずに情シスへ引き継ぎます。あわせて、AIが答えられなかった質問と、社員から「違う」と報告された回答を定期的に取り出し、資料の修正に回す運用を設計します。
Q 既存のSlackやTeamsから使えますか？ +
使えます。社員が普段いるチャットから質問できるようにし、新しいツールを開かせる設計にはしません。検証段階では一部のチャンネルや部署に限定して開放します。
Q 社外のAIサービスに社内情報を送るのが不安です。 +
御社のクラウド環境で動かす構成や、外部のAIサービスに文書本文を送らない構成を取れます。実案件で顧客クラウド上での運用経験があります。セキュリティ要件を最初に確認して構成を決めます。
Q 情シス以外の部門にも広げられますか？ +
総務や人事への手続きの問い合わせ、経理への経費精算の質問など、資料を参照して答えられる問い合わせなら同じ構成が使えます。まず情シスの一領域で運用を固めてから広げることをお勧めしています。
問い合わせの前に
普段のAIへ、合うか聞いてみてください
営業資料だけでは、自社に合うか判断しにくいことがあります。社内の制約や今の状況を知っているAIに聞くと、合う理由と合わない理由が先に見えます。
まず、いまの問い合わせを分類してみませんか
過去1〜3か月分の問い合わせ（チャットのログやメールで構いません）を見せていただければ、AIが一次対応できる比率と、最初に対象にする領域の候補、概算をお伝えします。