動いた後の変化で見る導入事例
3ヶ月停滞した開発の立て直し、議事録から1日デモ、新規事業の1週間立ち上げなど、発注前に確認したい変化から探せます。
難航案件
3ヶ月停滞 → 3週間
引き継ぎ後、動作状態まで立て直し
構想具体化
議事録 → デモ1日
発注前に画面で認識合わせ
新規事業
1週間で立ち上げ
要件・技術・インフラまで一体で対応
心理学モデルを組み込んだ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が選定されました。
iroAI介護 - 介護情報マッチングプラットフォーム
課題
介護サービスを必要とする方やそのご家族が、最適な介護情報を見つけることが困難でした。情報が散在し、比較検討に時間がかかる状況を解決したいというニーズがありました。
- 介護サービス情報が散在し、比較検討が困難
- 高齢者やインターネット初心者にとって使いにくいUI
- 地域密着型の介護情報へのアクセスが限られている
解決策
LINEベースの介護情報マッチングプラットフォームを開発。文字入力不要で選択肢をタップするだけで最適な介護サービスを紹介。
- 幅広い年齢層が使い慣れたLINE上でサービスを提供
- 文字入力不要、選択肢タップのみで完結するシンプルUI
- いくつかの質問に答えるだけで推奨介護サービスを紹介
結果
探す側は、複数のサイトを見比べずに、使い慣れたLINEで質問に答えるだけで候補にたどり着けます。文字入力をなくしたので、高齢のご本人でも家族の手を借りずに最後まで進められます。事業者側には、絞り込みが済んだ状態で相談が届きます。
技術にユーザーを合わせず、使う人の行動にシステムを合わせる
ITに慣れていない利用者でも、迷わず最後までサービスを使える体験を作れます。
幅広い年齢層が使い慣れたLINEを採用し、文字入力をなくして選択肢のタップだけで介護サービス候補まで到達できる導線にしました。
Beekleは、新しい画面を作ることより、対象ユーザーが実際に使い切れる接点を選びます。この案件では、高齢者にも普及しているLINEをそのまま入口にし、文字入力をなくして選択肢のタップだけで完結する導線にしました。技術選定をユーザー側へ押し付けず、利用者の行動にシステムを合わせています。
ユーザー起点のUX設計
商用モバイルアプリのFlutter移行と開発基盤の整備
課題
すでに配信中のネイティブアプリをFlutterへ移行するプロジェクトに、開発の途中から参画しました。課金・広告・通知など収益と体験の根幹に関わる機能を作り込みつつ、仕様と品質を後から追える形で残す必要がありました。
- 配信中アプリの機能を落とさず、Flutterへ移行し切る必要
- 仕様が実装者の手元に留まり、設計判断の記録が残らない
- 受入基準が明文化されず、動作確認が手作業に依存
解決策
収益・体験の中核機能をFlutterで実装しながら、要件・設計・受入テストを記録として残す開発基盤を整備。開発はユースケース駆動で進め、自社開発のプロジェクト管理ツールとAIエージェントを組み合わせたAI駆動の開発フローで、設計から実装・レビューまでを回しました。
- サブスク課金（iOS/Android）・アプリ内広告・プッシュ通知・ネイティブ機能連携を実装
- ユースケース単位で要件を起票し、設計判断を選択肢と却下理由まで記録・E2E化
- 自社のプロジェクト管理ツールとAIエージェントを組み合わせた開発フローを運用
結果
配信中のアプリを止めずにFlutterへ移行し、課金・広告・通知という売上に直結する機能を作り切りました。なぜその設計にしたのかを却下案まで含めて残しているため、担当者が代わっても過去の判断を掘り起こす作業が発生しません。受入基準をユースケース単位で自動テストにしたので、リリース前の確認が手作業の総当たりでなくなりました。
動くコードだけでなく、次の担当者も判断できる仕様を残す
担当者が変わっても設計意図を掘り起こす必要がなく、機能追加やリリース確認を継続しやすくなります。
課金・広告・通知をFlutterへ移行しながら、要件・設計判断・却下理由・受入基準をユースケース単位で記録し、E2Eテストにつなげました。
Beekleでは、自社開発のプロジェクト管理ツールとAIエージェントを使い、ユースケース単位で要件・設計判断・却下理由・受入基準を残し、そのまま実装とE2Eテストへつなげています。そのため、担当者が変わっても『なぜこの設計なのか』をコードから推測し直さず、仕様を追跡しながら継続開発できます。
仕様駆動・継続開発
サブスク課金型マッチングサービスの開発
課題
ユーザー同士をつなぐ課金制のマッチングサービスを、継続課金・自動マッチング・リアルタイムチャットまで含めて本番運用できる形で構築する必要がありました。広告やキャンペーンによる流入増に耐えることに加え、公開後も数字を見ながら課金率を上げ続けることが求められました。
- クレジットカードの継続課金を安全に扱う決済連携
- 相性に基づく自動マッチングとリアルタイムなチャット・通知
- 流入増に耐える基盤と、課金導線での快適な表示性能
- 公開後にデータで課金率と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で統合し、さらに回答へ引用本文を必須化しました。検索方式と回答の安全性を同じ設計対象として扱っています。
問題に合った技術選定
メンタルヘルス記録アプリの開発（他社難航案件のフルスタック・リカバリー）
課題
先行していた他社ベンダーが約3ヶ月をかけても完成に至らず、開発が停滞していました。リリースの目処が立たず、早期に動く状態へ立て直す必要がありました。
- 先行ベンダーが約3ヶ月開発するも完成に至らず停滞
- 仕様が固まりきらないまま実装が進み、手戻りが発生
- リリース時期が見えず、事業計画に影響
解決策
AIを活用した開発体制で停滞していた案件を引き継ぎ、バックエンド・フロントエンド・インフラまで一貫して再構築。3週間で動作する状態まで仕上げました。
- 既存コードと要件を整理し、AI支援で実装を高速化
- バックエンド・フロントエンド・インフラまで一貫して再構築
- 3週間で完成・動作する状態に到達
- 大手企業が外部委託したセキュリティチェックを一度で通過
結果
3ヶ月動かなかった開発が、引き継ぎから3週間で動く状態になりました。バックエンドからインフラまで一つの体制で見ているため、どこの担当かを切り分ける調整や待ち時間が発生しません。急いで作ると品質が落ちるのではという不安に対しては、発注元の大手企業が外部に委託したセキュリティチェックを、指摘による差し戻しなく一度で通過したことが答えになっています。止まっていたリリースの見通しが立ち、事業計画を引き直せる状態に戻りました。
速くコードを書くのではなく、案件を止めている原因を特定して再構成する
長期停滞した開発でも、事業計画を立て直せるところまで短期間で回復できます。
先行ベンダーが約3ヶ月かけても完成しなかった案件を引き継ぎ、バックエンド・フロント・インフラを再構成して3週間で動作状態へ。外部セキュリティ審査も一度で通過しました。
Beekleは、フロントエンド・バックエンド・インフラを分断せず、一つのシステムとして横断して扱えます。そのため難航案件でも、責任範囲の切り分けから始めるのではなく、既存コードと要件をまとめて読み、ボトルネックを直接直せます。この体制で、約3ヶ月停滞していた案件を3週間で動作状態へ戻し、外部セキュリティ審査も一度で通過しました。
難航案件の立て直し
ヒアリング議事録からRFP生成 → 仕様駆動開発で即日デモ構築
課題
構想段階で要件が言語化されておらず、発注者と開発側でイメージのズレが起きやすい状況でした。動くものを早く見て方向性を確かめたいというニーズがありました。
- 要件が言語化されておらず、認識のズレが起きやすい
- 仕様書作成からプロトタイプまで通常は時間がかかる
- 動くものを見ないと発注者が判断しづらい
解決策
お客様へのヒアリング議事録からRFP（提案依頼書）を生成し、その仕様をもとに仕様駆動開発で実装。1日で動作するデモを完成させ、認識をすり合わせました。
- ヒアリング議事録からRFP（提案依頼書）を生成
- RFPをもとに仕様を定義し、仕様駆動開発で実装
- 1日で動作するデモを完成させ、発注者と認識をすり合わせ
結果
ヒアリングの議事録が、その日のうちに動くデモになりました。発注側は仕様書の文章ではなく画面で判断できるので、思っていたものと違うという事態が、実装を終えたあとではなく初日に分かります。実際に「イメージとずれていない」と評価いただき、以降の打ち合わせを認識合わせではなく中身の検討に使えました。
言葉になりきっていない構想を、その日のうちに仕様と実物へ変える
認識のズレを実装後ではなく初日に見つけ、打ち合わせを「認識合わせ」から「中身の検討」へ進められます。
ヒアリング議事録からRFPを生成し、仕様駆動で実装。1日で動作デモを完成させ、発注者から「イメージとずれていない」と評価されました。
Beekleでは、ヒアリング内容をそのままAIへ渡さず、RFP → 仕様 → 実装という段階に構造化してから開発します。AIは整理された仕様をもとに実装するため、『AIで速い』だけでなく、発注者との認識を保ったまま速く作れます。この案件では議事録から1日で動作デモまで到達し、『イメージとずれていない』という確認まで取れました。
構想の仕様化
お客様の事業成長をサポートします
無料相談、または「動くプロトタイプで発注前に判断する」仕組みをまとめた資料からどうぞ
PDF・約20ページ・無料／メールアドレスのみで受け取れます