導入事例
お客様の課題解決と事業成長をサポートした実績をご紹介します
心理学モデルを組み込んだHR AIエージェントの開発
課題
採用やチーム編成の判断が、面接担当者の経験や紙の診断票に依存していました。属人化・バイアスが課題となっており、防げたはずの人事ミスが多発していました。そこで、心理学の知見を業務判断に使える形へ落とし込み、候補者・従業員の性格特性、職種との適合度、チーム内の相性、入社後のリスクまでAIが支援するプロダクトが必要でした。
- 心理尺度を単なる点数で終わらせず、採用・配置の判断材料として読める形にしたい
- 採用候補者と職種要件の相性を、属人的な印象ではなく根拠付きで見たい
- 企業ごとの招待、診断管理、チーム分析、レポート出力まで業務に載せたい
解決策
HEXACO-100をベースに、6次元24要素のスコアリングを実装。LLMは自由な文章生成ではなく、スコア・ファセット・職種要件・採用ペルソナを入力に、JSON Schemaで出力を固定した分析エンジンとして使いました。個人レポート、職種適合、チーム相性、リスク分析まで返すHR AIエージェントとして、企業アカウント管理、招待URL発行、PDFレポートまで含めて構築しています。
- HEXACO-PI-R 100項目版の逆転項目・ファセット・ドメイン集計を実装
- LLM分析を要約、強み、注意点、職場適応、相性、リスクなどのセクションに分けて並列実行
- 採用ペルソナ生成、候補者マッチング、チーム相性分析を構造化出力付きAIジョブとして非同期化
結果
面接担当者の勘に頼っていた採用判断に、誰が見ても同じ基準の物差しができました。性格特性だけでなく職種との適合度、チームとの相性、入社後に想定されるリスクまで同じ様式のレポートで揃うため、なぜこの人を採るのかを社内に説明できます。招待から診断、レポート出力までが業務フローに乗っているので、診断結果を参考資料で終わらせずに採用と配置を決める場で使えます。
複雑な専門知識を、実際の業務判断に使えるプロダクトへ変換する
心理診断を参考資料で終わらせず、採用・配置・チーム編成の意思決定に直接使える形にできます。
HEXACO-100の6次元24要素を実装し、職種適合・チーム相性・リスクまで構造化したレポートとして出力。招待から診断、分析、PDF出力まで業務フローに載せました。
Beekleは、専門モデルをLLMに説明させるだけでなく、心理尺度のスコアリングロジックからAIの構造化出力、業務フローまで実装できます。この案件でもHEXACO-100の逆転項目・ファセット・ドメイン集計を自前で組み、LLM出力をJSON Schemaで固定したうえで、招待・診断・分析・PDFレポートまで一つのシステムにしました。
専門知のプロダクト化
要件定義から一気通貫で進めた倉庫AI DX
課題
BPOとして受けている倉庫業務をDXするために、まず業務の全体像を要件として定義し直す必要がありました。既存業務をそのまま画面化するのではなく、As-Is/To-Be、データ、例外対応、現場の判断ポイントを整理し、そのうえでスキャンや印刷、実機端末まで含む難度の高い倉庫DXとして実装する必要がありました。
- As-Is/To-Beを整理し、DX後の業務フローを定義したい
- CSV、商品、出荷、在庫、作業ステータスなどのデータ構造を整理したい
- スキャン、プリンター、実機端末など現場固有の制約も含めて設計したい
解決策
要件定義から入り、As-Is/To-Be整理、業務データの分解、ユースケース定義、受け入れ基準、設計、実装までを一気通貫で推進。AIを使って仕様整理、設計レビュー、実装、テスト観点の整備を高速に回しながら、React NativeとFastAPIで、スキャン、プリンター連携、ネイティブ実機対応を含む倉庫DXシステムを構築しました。
- BPO業務のAs-Is/To-Beを整理し、DX後のユースケースとデータモデルを設計
- ユースケース駆動で、要件、設計、API、画面、テスト観点をつなげて開発
- スキャン、プリンター、端末固有のネイティブ制御を含む現場実装まで対応
結果
出荷の現場から、紙とベテランの記憶が抜けました。いま何がどこまで終わっているかは画面に出るので、進捗を確かめるために現場を歩き回る必要がありません。要件定義の段階で例外対応と現場の判断ポイントまで洗い出しているため、月間1万件を超える受注を落とさずに回せています。
曖昧な現場業務を、例外まで含めて実装可能な仕様にする
開発後に「実際の現場では使えない」と発覚する手戻りを減らし、現場の処理量を落とさずDXできます。
As-Is/To-Be、業務データ、ユースケース、例外対応、判断ポイント、スキャン・プリンター・実機制約まで整理し、月1万件超を安定処理する運用へつなげました。
Beekleでは、要件を画面一覧ではなくユースケース単位で定義し、As-Is/To-Be、業務データ、例外、受入基準まで整理したうえで、同じ仕様を設計・API・画面・テストへつなげます。この案件でも要件定義から実機のスキャン・プリンター制御まで一貫して担当したため、現場固有の例外を実装段階で落とさずに済みました。
業務構造化・要件定義
このお客様が、何と比較し、何を不安に感じ、なぜBeekleに決めたか。
比較した選択肢
オフショア開発会社との比較になり、価格はオフショアが下回っていました。Beekleの方が高い状態からの検討です。
不安だったこと
紙とベテランの記憶に依存した例外の多い業務で要件が複雑なうえ、オフショア開発では失敗のリスクが高いことが不安視されていました。
Beekleを選んだ理由
価格差よりも、要件定義から一貫して進められる安心が決め手となり、価格で上回るBeekleが選定されました。
サブスク課金型マッチングサービスの開発
課題
ユーザー同士をつなぐ課金制のマッチングサービスを、継続課金・自動マッチング・リアルタイムチャットまで含めて本番運用できる形で構築する必要がありました。広告やキャンペーンによる流入増に耐えることに加え、公開後も数字を見ながら課金率を上げ続けることが求められました。
- クレジットカードの継続課金を安全に扱う決済連携
- 相性に基づく自動マッチングとリアルタイムなチャット・通知
- 流入増に耐える基盤と、課金導線での快適な表示性能
- 公開後にデータで課金率とUXを改善し続ける体制
解決策
決済・マッチング・チャットを別々の機能として並べず、どこが課金率を左右するかで要件を切り分けてから設計しました。外部決済は差し替え可能なドライバとして抽象化し、課金導線は表示速度が離脱に直結するためサーバーコンポーネント中心に構成。流入増に追従するインフラはコードで管理しています。公開後の改善に向けては、まずBigQueryで購買データを分析し、最終的な顧客データ基盤（CDP）はDatabricks on AWS上に構築しました。約11名体制で、決済からインフラ、データ基盤・分析まで一貫して担当しています。
- 外部決済ゲートウェイを差し替え可能なドライバに抽象化し、トークン化・継続課金・エラー処理まで備えた決済システムを実装
- 属性・条件に基づく相性スコアリングで相手を自動レコメンドするマッチングを実装
- 流入増に備えたECSオートスケール構成をIaC化し、サーバーコンポーネント中心の構成で課金導線の表示性能を確保
- BigQueryで購買データを分析し、最終的な顧客データ基盤（CDP）はDatabricks on AWS上に構築してアプリDB・GA4などを統合
- ロイヤル顧客層を特定し、LP・UGC・課金導線の改善に反映
結果
継続課金・自動マッチング・チャットを備えたサービスが本番で動いています。決済は事業者を差し替えられる形にしてあるので、手数料の見直しや乗り換えのたびにサービス全体を作り直す必要がありません。広告で人が一気に流れ込む場面でも処理能力が自動で増えるため、いちばん申し込みが集まる瞬間に画面が重くなって取りこぼすことがありません。公開後は、BigQueryでの購買データ分析を経てDatabricks上に整えたデータ基盤から優良顧客層を特定し、LPと課金導線の改善に反映しています。作って終わりではなく、次に何を直せば課金率が動くかを数字で決められる状態です。決済、マッチング、インフラ、データ基盤を別々の会社に分けると要件の境目で話が止まりますが、一体の体制で要件定義から運用改善までを持っているため、その議論がそのまま実装につながります。
技術要件ではなく、売上とKPIから「何を作るか」を決める
システム開発をリリースで終わらせず、課金率や顧客価値を改善し続ける事業基盤にできます。
課金率を左右する箇所から要件を切り分け、決済・マッチング・インフラを設計。公開後はBigQueryで購買データを分析し、Databricks上に構築したCDPで優良顧客層を特定して、LP・UGC・課金導線の改善までつなげました。
Beekle自身が課金型プロダクトを運営し、決済、広告流入、インフラ、BigQueryとDatabricksでの顧客分析、LP・課金導線の改善まで当事者として回しています。そのため受託でも、仕様通りに機能を作るだけでなく、課金率や離脱に影響する箇所から要件を切り、リリース後の分析・改善まで含めて設計できます。
事業成果から逆算した設計
カスタマーサポートのAIナレッジ検索（Hybrid GraphRAG）
課題
過去の問い合わせ対応履歴やサポート文書・マニュアルが大量にあるものの、必要な回答を探し出せず活用しきれていませんでした。キーワード検索では言い回しの違いを取りこぼし、複数の文書をまたぐ手順や例外対応を横断的に調べることも難しい状況でした。
- 問い合わせ履歴・サポート文書が大量にあり、目的の回答にたどり着けない
- キーワード検索では言い換え・表記揺れを拾えない
- 複数の文書にまたがる手順や例外対応を横断的に追えない
解決策
自然文で質問すると引用元を示しながらAIが回答する社内ナレッジ検索を構築。単一のベクトル検索に頼らず、メタデータ・全文・ベクトル・グラフ近傍・対応根拠（Claim）の複数経路を統合するHybrid GraphRAGを採用し、根拠付きで精度の高い回答を実現しました。
- 実際のデータ量では通常のベクトル検索だけのRAGは精度・スケールに限界があり、横断回答や引用元の確かさも弱いため、関係をたどれるGraphRAGを採用
- Neo4jのナレッジグラフで文書・概念・手順・対応内容を関連付け
- メタデータ／全文／ベクトル／グラフ近傍／対応根拠（Claim）の検索をRRFで統合
- 回答は必ず引用元の本文を提示し、資料にない内容は断定しない設計
結果
担当者が過去の対応履歴やマニュアルを探し回る時間がなくなりました。普通の文章で聞けば引用元つきで答えが返るので、検索のコツを知っているベテランでなくても同じ回答にたどり着けます。根拠となる本文が必ず添えられ、資料にない内容は断定しない設計にしてあるため、そのままお客様に返してよいかを担当者自身が判断できます。
流行の技術を使うのではなく、検索課題に必要な構造から方式を選ぶ
単純RAGでは拾いにくい横断情報や根拠まで扱い、担当者が回答を検証できる検索体験を作れます。
メタデータ・全文・ベクトル・グラフ近傍・Claimの複数経路をRRFで統合し、回答には必ず引用本文を付け、資料にない内容は断定しない構成にしました。
Beekleは、RAGやGraphRAGといった技術名から方式を決めず、必要な検索精度と検証可能性から検索経路を組み立てます。この案件ではメタデータ・全文・ベクトル・グラフ近傍・ClaimをRRFで統合し、さらに回答へ引用本文を必須化しました。検索方式と回答の安全性を同じ設計対象として扱っています。
問題に合った技術選定
お客様の事業成長をサポートします
無料相談、または「初期費用0円で動くプロトタイプから判断する」仕組みをまとめた資料からどうぞ
PDF・約20ページ・無料／メールアドレスのみで受け取れます