動いた後の変化で見る導入事例

解決策

HEXACO-100をベースに、6次元24要素のスコアリングを実装。LLMは自由な文章生成ではなく、スコア・ファセット・職種要件・採用ペルソナを入力に、JSON Schemaで出力を固定した分析エンジンとして使いました。個人レポート、職種適合、チーム相性、リスク分析まで返すHR AIエージェントとして、企業アカウント管理、招待URL発行、PDFレポートまで含めて構築しています。

• HEXACO-PI-R 100項目版の逆転項目・ファセット・ドメイン集計を実装
• LLM分析を要約、強み、注意点、職場適応、相性、リスクなどのセクションに分けて並列実行
• 採用ペルソナ生成、候補者マッチング、チーム相性分析を構造化出力付きAIジョブとして非同期化

結果

面接担当者の勘に頼っていた採用判断に、誰が見ても同じ基準の物差しができました。性格特性だけでなく職種との適合度、チームとの相性、入社後に想定されるリスクまで同じ様式のレポートで揃うため、なぜこの人を採るのかを社内に説明できます。招待から診断、レポート出力までが業務フローに乗っているので、診断結果を参考資料で終わらせずに採用と配置を決める場で使えます。

発注判断の裏側

このお客さまが、何と比べ、何を不安に感じ、なぜBeekleに決めたか。

比べたもの

既製の適性検査サービス

不安だったこと

AIの出力が毎回ぶれて、診断結果を判断材料として説明できないことが不安でした。

決め手

2週間のPoCで確かめてから本開発に進められたことが決め手になりました。

解決策

要件定義から入り、As-Is/To-Be整理、業務データの分解、ユースケース定義、受け入れ基準、設計、実装までを一気通貫で推進。AIを使って仕様整理、設計レビュー、実装、テスト観点の整備を高速に回しながら、React NativeとFastAPIで、スキャン、プリンター連携、ネイティブ実機対応を含む倉庫DXシステムを構築しました。

• 倉庫業務のAs-Is/To-Beを整理し、DX後のユースケースとデータモデルを設計
• ユースケース駆動で、要件、設計、API、画面、テスト観点をつなげて開発
• スキャン、プリンター、端末固有のネイティブ制御を含む現場実装まで対応

結果

出荷の現場から、紙とベテランの記憶が抜けました。いま何がどこまで終わっているかが画面に出るので、進捗は現場を歩き回らずに確かめられます。例外対応と現場の判断ポイントは、要件定義の段階で洗い出してから作っています。稼働後、お客さまからは、在庫担当が「楽過ぎて無理です。戻れないです」と話していると伺いました。

発注判断の裏側

このお客さまが、何と比べ、何を不安に感じ、なぜBeekleに決めたか。

比べたもの

既製の倉庫管理システム（WMS）／オフショア開発

不安だったこと

既製品では、欠品・途中中断・印刷失敗といった現場の例外処理に合いません。オフショアは安くても、要件が複雑で任せきれないのが不安でした。

決め手

要件定義から入り、スキャン・プリンターの実機まで同じ会社で作れることが決め手になりました。Figma Makeで作ったプロトタイプで打ち合わせ、ユースケース駆動とAI駆動開発でモバイルアプリまで一気に作るので、費用を抑えたまま質を保てます。

解決策

LINEミニアプリで選択肢をタップして答えると、条件に合う介護サービスが点数順に並ぶように作り直しました。推薦のルールは頻繁に変わるので、施設が条件に当てはまるかの判定はAI（jev）に任せ、ルールを書き換えるだけで推薦を変えられるようにしています。まずSQLで候補を絞り込み、AI（jev）で条件に当てはまるかを一つずつ判定します。そのあとTursoに入れた施設の詳細情報をRAGで引いて、利用者の希望と自然文でマッチングし、最後はルールに沿って点数を付けて並べます。あわせて、本部と掲載企業の管理画面と、表示回数やクリック率を見る分析画面も作りました。

• LINEミニアプリで選択肢をタップするだけで、入所施設・在宅介護・病院・生活支援など5種類の検索ができる
• SQLで絞り込み、AI（jev）で条件を判定したあと、Tursoを使ったRAGで施設の詳細情報と利用者の希望を自然文でマッチングし、ルールで点数を付けて並べる
• 本部が、利用者には見せずAIだけが読む施設の詳細情報を登録できる
• エリアごとにLINE公式アカウントを足せる作り。本部・掲載企業の管理画面と分析画面

結果

探す側は、複数のサイトを見比べずに、使い慣れたLINEで質問に答えるだけで、条件に合う介護サービスを点数順に見られます。AIの判定は、公開中の574件・72個のチェックで、ルールどおりの答えと全問一致しました。並び順はルールで決めているので、なぜその施設を薦めたのかを説明できます。他社なら約300万円かかる開発を、約100万円・約2週間半でリニューアルしました。

発注判断の裏側

このお客さまが、何と比べ、何を不安に感じ、なぜBeekleに決めたか。

比べたもの

専用アプリを作る／ほかの開発会社

不安だったこと

前任の開発会社がいなくなり、開発が止まっていました。高齢者はアプリを入れず、文字も入力しにくいことも不安でした。

決め手

AI駆動開発ですぐに作れることと、代表同士で話して日ごろの仕事への向き合い方を評価していただいたことが決め手になりました。LINEを入口にして選択肢をタップするだけで終わる作りを提案し、プロトタイプをそのまま納品まで持っていきました。

解決策

収益・体験の中核機能をFlutterで実装しながら、要件・設計・受入テストを記録として残す開発基盤を整備。開発はユースケース駆動で進め、自社開発のプロジェクト管理ツールとAIエージェントを組み合わせたAI駆動の開発フローで、設計から実装・レビューまでを回しました。

• iOS・Androidのサブスク課金、アプリ内広告、プッシュ通知、ネイティブ機能連携を実装
• ユースケース単位で要件を起票し、設計判断を選択肢と却下理由まで記録・E2E化
• 自社のプロジェクト管理ツールとAIエージェントを組み合わせた開発フローを運用

結果

配信中のアプリを止めずにFlutterへ移行し、課金・広告・通知という売上に直結する機能を作り切りました。なぜその設計にしたのかを却下案まで含めて残しているため、担当者が代わっても過去の判断をそのまま読んで引き継げます。受入基準をユースケース単位で自動テストにしたので、リリース前の確認が手作業の総当たりでなくなりました。

発注判断の裏側

このお客さまが、何と比べ、何を不安に感じ、なぜBeekleに決めたか。

比べたもの

社内での移行／別の開発会社

不安だったこと

課金・広告・通知など、収益に関わる機能を移行で壊さないか。前任が失敗した開発を引き継げるかも不安でした。

決め手

要件定義の力と、少ないやり取りで意図をくみ取る力を評価していただきました。前任が失敗した開発を引き継いで最後までやり切ることと、要件・設計判断・受入基準を記録に残しながら作る進め方が決め手になりました。

解決策

決済・マッチング・チャットを別々の機能として並べず、どこが課金率を左右するかで要件を切り分けてから設計しました。外部決済は差し替え可能なドライバとして抽象化し、課金導線は表示速度が離脱に直結するためサーバーコンポーネント中心に構成。流入増に追従するインフラはコードで管理しています。公開後の改善に向けては、まずBigQueryで購買データを分析し、最終的な顧客データ基盤（CDP）はDatabricks on AWS上に構築しました。統合にあたって、アプリDBとGA4にある同じ人のデータを1人分にまとめました。重複と表記のゆれを直し、欠けた値や誤った値も整えています。約11名体制で、決済からインフラ、データ基盤・分析まで一貫して担当しています。

• 外部決済ゲートウェイを差し替え可能なドライバに抽象化し、トークン化・継続課金・エラー処理まで備えた決済システムを実装
• ルールで候補を絞り込み、AIでお相手を薦めるレコメンド機能を実装
• 流入増に備えたECSオートスケール構成をIaC化し、サーバーコンポーネント中心の構成で課金導線の表示性能を確保
• BigQueryで購買データを分析し、最終的な顧客データ基盤（CDP）はDatabricks on AWS上に構築してアプリDB・GA4などを統合
• アプリDBとGA4にある同じ人のデータを1人分にまとめ、重複・表記のゆれ・欠けた値・誤った値を前処理で整理
• 課金データを数理分析して優良顧客層を特定し、LP・UGC・課金導線の改善に反映

結果

継続課金・自動マッチング・チャットを備えたサービスが本番で動いています。決済は事業者を差し替えられる形にしてあるので、手数料の見直しや乗り換えは決済部分の差し替えだけで済みます。広告で人が一気に流れ込む場面でも処理能力が自動で増えるため、いちばん申し込みが集まる瞬間に画面が重くなって取りこぼすことがありません。公開後は、BigQueryでの購買データ分析を経て、Databricks上にデータ基盤を整えました。Databricks上の課金データを数理分析して優良顧客層を特定し、LPと課金導線を改善して売上アップに貢献しました。作って終わりではなく、次に何を直せば課金率が動くかを数字で決められる状態です。決済、マッチング、インフラ、データ基盤を別々の会社に分けると要件の境目で話が止まりますが、一体の体制で要件定義から運用改善までを持っているため、その議論がそのまま実装につながります。

発注判断の裏側

このお客さまが、何と比べ、何を不安に感じ、なぜBeekleに決めたか。

比べたもの

機能を作るだけの開発会社

不安だったこと

公開後に課金率が上がらないことが不安でした。

決め手

決済・広告流入・顧客分析まで自分たちで回した経験があり、課金率に効くところから要件を切れることが決め手になりました。

解決策

自然文で質問すると引用元を示しながらAIが回答する社内ナレッジ検索を構築。単一のベクトル検索に頼らず、メタデータ・全文・ベクトル・グラフ近傍・対応根拠（Claim）の複数経路を統合するHybrid GraphRAGを採用し、根拠付きで精度の高い回答を実現しました。

• 実際のデータ量では通常のベクトル検索だけのRAGは精度・スケールに限界があり、横断回答や引用元の確かさも弱いため、複数資料を突き合わせて照合できるGraphRAGを採用
• Neo4jのナレッジグラフで文書・概念・手順・対応内容を関連付け
• 質問の条件で絞り込んだうえで全文検索と意味の近さによる検索を統合し、資料をまたぐ照合と対応根拠を加えて、回答後に根拠を検証
• 回答には引用元の本文を提示し、資料にない内容を断定しないよう制御する設計

結果

担当者が過去の対応履歴やマニュアルを探し回る時間がなくなりました。普通の文章で聞けば引用元つきで答えが返るので、検索のコツを知っているベテランでなくても同じ回答にたどり着けます。根拠となる本文が添えられ、資料にない内容を断定しないよう制御してあるため、そのままお客様に返してよいかを担当者自身が判断できます。回答の正答率は、複数のプロジェクトで繰り返し計測して、平均95%前後です。

発注判断の裏側

このお客さまが、何と比べ、何を不安に感じ、なぜBeekleに決めたか。

比べたもの

既製のAIチャットボット・社内検索ツール

不安だったこと

既製品では言い回しの違いを拾えず、複数の文書にまたがる手順にも答えられません。根拠のない回答が出ることと、作ったあとの保守も不安でした。

決め手

案件に合うRAGの手法を選べることと、インフラからRAGまで一気通貫で本番まで持っていける知見が決め手になりました。

解決策

AIを活用した開発体制で停滞していた案件を引き継ぎ、バックエンド・フロントエンド・インフラまで一貫して再構築。3週間で動作する状態まで仕上げました。

• 既存コードと要件を整理し、AI支援で実装を高速化
• バックエンド・フロントエンド・インフラまで一貫して再構築
• 3週間で完成・動作する状態に到達
• 大手企業が外部委託したセキュリティチェックを一度で通過

結果

3ヶ月動かなかった開発が、引き継ぎから3週間で動く状態になりました。バックエンドからインフラまで一つの体制で見ているため、どこの担当かを切り分ける調整や待ち時間が発生しません。急いで作ると品質が落ちるのではという不安に対しては、発注元の大手企業が外部に委託したセキュリティチェックを、指摘による差し戻しなく一度で通過したことが答えになっています。止まっていたリリースの見通しが立ち、事業計画を引き直せる状態に戻りました。

発注判断の裏側

このお客さまが、何と比べ、何を不安に感じ、なぜBeekleに決めたか。

比べたもの

前のベンダーに続けてもらう

不安だったこと

約3か月止まっていて、リリースの見通しが立たないことが不安でした。

決め手

最後までやり切る姿勢、スピード、技術力、設計力、要件定義の力を評価していただきました。フロント・バック・インフラをまとめて引き受け、止まっている箇所を直接直せることが決め手になりました。

解決策

お客様へのヒアリング議事録からRFP（提案依頼書）を生成し、その仕様をもとに仕様駆動開発で実装。1日で動作するデモを完成させ、認識をすり合わせました。

• ヒアリング議事録からRFPを生成
• RFPをもとに仕様を定義し、仕様駆動開発で実装
• 1日で動作するデモを完成させ、発注者と認識をすり合わせ

結果

ヒアリングの議事録が、その日のうちに動くデモになりました。発注側は仕様書の文章ではなく画面で判断できるので、思っていたものと違うという事態が、実装を終えたあとではなく初日に分かります。実際に「イメージとずれていない」と評価いただき、以降の打ち合わせを認識合わせではなく中身の検討に使えました。

発注判断の裏側

このお客さまが、何と比べ、何を不安に感じ、なぜBeekleに決めたか。

比べたもの

要件定義書を作ってから開発する

不安だったこと

発注者と開発側でイメージがずれることが不安でした。

決め手

議事録から1日で動くデモを出し、ずれていないことを確かめられることが決め手になりました。