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

3ヶ月停滞した開発の立て直し、議事録から1日デモ、新規事業の1週間立ち上げなど、発注前に確認したい変化から探せます。

難航案件

3ヶ月停滞 → 3週間

引き継ぎ後、動作状態まで立て直し

構想具体化

議事録 → デモ1日

発注前に画面で認識合わせ

新規事業

1週間で立ち上げ

要件・技術・インフラまで一体で対応

生成AIに書かせない前提で組んだAI検索・比較・推薦エンジン

EC・商品検索/AIレコメンド 商品カタログを持つEC事業者向けPoC 開発期間:PoC: 1週間で動くプロトタイプを構築

課題

探しているものを自然文で伝えると、カタログの中から候補を検索・比較して薦めるサービスの構想でした。ただし、推薦文をAIに自由に書かせることも、候補をまとめてAIに渡して並べさせることもできない前提がありました。「今どきのやり方」がそのまま使えないうえで、なぜこの順番で薦めたのかを運営側が説明できる必要もあります。加えて利用者は、求めているものを商品名で書けるとは限りません。遠回しな言い方からでも意図を拾える検索が要りました。

  • AIに推薦文を自由に書かせる構成が採れない
  • 商品名を知らない言い回しでも、意図した商品にたどり着かせたい
  • なぜこの順番で薦めたのかを、運営側が説明できる形にしたい

解決策

LLMの担当を入口(自然文を条件に構造化する)と出口(理由を言語化する)だけに限定し、検索と並べ替えは自前のスコア関数で決定論的に行う構成にしました。出口でも商品説明の原文はLLMに渡さず、検索エンジンが機械的に照合した根拠(一致した条件・価格・評点)だけを渡して、その範囲内で文章を組ませます。生成結果には最後に、正規表現で書いたNG表現フィルタを必ず一枚かけています。

  • BM25(語彙一致)とベクトル検索を並走させ、RRFで統合。概念辞書でクエリを言い換えごと拡張
  • 条件一致・嗜好適合・品質(レビュー評点のベイズ平均)・予算適合などの重み付き和で並べ替え、同じブランドが続いたらペナルティ
  • 入口の構造化はドメイン定義に列挙した選択肢から選ばせ、存在しない値は破棄。失敗時はルール実装にフォールバック

結果

並べ替えの根拠がスコアの内訳として数値で残るため、「AIが選びました」で終わらせずに、なぜこの並びなのかを運営側が説明できます。重みは設定ファイルの値なので、変えて比べることもできます。検索と並べ替えは10ミリ秒未満(依存ゼロ構成での実測)で、LLMを呼ぶのは候補件数によらず入口と出口の2回だけなので、扱う商品が増えても応答時間と費用が比例して膨らみません。精度は評価ハーネスで測る形にしてあり、回帰検知用のセットでは、概念辞書を1回改訂しただけで(LLM呼び出しはゼロ)nDCG@5が0.907から0.988まで動きました。実力測定用のホールドアウトは別に用意して、そちらの数字も分けて追っています。エンジンは商材ジャンルに依存しない作りで、ドメイン定義ファイルを差し替えるだけで別ジャンルに載せ替えられることも、日本酒のカタログで確認しました。

立ち上げ
1週間で動くPoC
応答
検索・並べ替え10ms未満
説明性
スコアの内訳を数値で提示
Beekleだからできたこと

生成AIに任せられない前提から、動く推薦エンジンを設計する

「AIにお任せ」で済ませられない事情があっても、推薦の質と説明責任を両立した検索・推薦を持てます。

LLMの担当を入口と出口に限定し、BM25とベクトル検索のRRF統合+決定論的なスコア関数で並べ替えを自前実装。生成文には機械的なNG表現フィルタを一枚かけ、精度は評価ハーネスで数値化しました。

Beekleでは、LLMに何をさせないかを先に決めてから設計します。この案件でも、並べ替えをLLMに渡さないことで応答速度・費用・説明責任を同時に確保し、AIが書ける範囲を仕組みとして限定しました。精度も感想ではなく評価ハーネスの数値で語れる状態にしてあるので、辞書や重みを触った影響を回帰込みで確認しながら改善できます。

制約下のAI設計

社会調査系システム開発

社会調査/データ可視化 調査・分析業務を行う事業者向けデモ 開発期間:実装: 1日

課題

マーケティング施策を実施するために数百万という限られた予算で、多くのデータを収集・分析できるシステムが必要でした。スピードが求められる状況で、かつデータ解析の知見と、データの不整合が起こらないように確実に設計する知見が必要でした。リアルタイムの実験中に、1人1回の調査でデータ欠損や二重計上が起きないようにすることが技術上の焦点でした。

  • 対象者の体験を止めずに、反応時点の秒数を非同期で記録したい
  • 複数対象者の反応を時間軸の棒グラフとヒートマップで確認したい
  • 通信断・リロード・再送によるデータ欠損や二重計上を避けたい

解決策

Laravel + Inertia + React のテンプレートを活用し、調査画面、リアクション記録API、管理画面の集計グラフまでを1日で実装。押下イベントはクライアント側のアウトボックスに保存してから送信し、リトライ時も冪等キーで重複保存されない設計にしました。

  • 調査コンテンツ・参加セッション・反応タイプ・押下イベントのデータモデルを定義
  • Rechartsで秒単位ヒストグラムと時間軸ヒートマップを実装
  • localStorageキュー、online復帰時リトライ、client_event_idによる冪等保存を実装

結果

数百万円の枠のなかで、調査の実施から集計・可視化までを1日で立ち上げました。実験のたびに反応を数え直す手作業がなくなり、担当者は結果を読んで次の施策を決めることに時間を使えます。通信断やリロードでデータが欠けたり二重に数えられたりしないので、集まった数字をそのまま意思決定の材料にできます。

立ち上げ
1日で実験に投入
手作業
集計の数え直しが不要
データ品質
欠損・二重計上なし
Beekleだからできたこと

速く作るだけでなく、意思決定に使えるデータまで成立させる

短期間の実験でも、欠損や二重計上を疑わずに結果を次の施策判断へ使えます。

調査画面から集計・可視化までを1日で構築し、通信断・リロード・再送を前提にアウトボックスと冪等キーを設計しました。

Beekleでは、短期PoCでも画面だけを作らず、データモデル・送信失敗時の再送・冪等性まで同時に設計します。この案件でも、再利用可能なLaravel + Inertia + Reactの構成を使って実装速度を確保しつつ、アウトボックスとclient_event_idで通信断や再送時のデータ不整合を防ぎました。

短期検証とデータ設計

リアルタイム翻訳AIプロダクトの開発

多言語コミュニケーション/生成AI 海外ユーザー向けコミュニケーションアプリ 開発期間:AI開発

課題

言語が異なるユーザー同士が、テキストだけでなく音声メッセージや通話でも自然にやり取りできる体験を検証する必要がありました。翻訳結果を返すだけではなく、意味の確認や語彙として残す学習導線まで含めて、AIをプロダクト体験に組み込むことが焦点でした。

  • 音声メッセージの文字起こしと翻訳を、会話体験の中で自然に扱いたい
  • 1対1通話でもリアルタイムに近い翻訳体験を検証したい
  • 分からない表現だけをAIに聞き、語彙として残せる導線を作りたい

解決策

FlutterとCloudflare Workersを組み合わせ、音声の文字起こし・翻訳、リアルタイム通話、選択テキストのAI解説、語彙帳までを含むMVP基盤を構築。OpenAI連携と軽量なエッジAPIを使い、AI翻訳を単機能ではなく継続利用されるモバイル体験として設計しました。

  • 音声メッセージ、通話、AI解説、語彙帳を一つのアプリ体験として統合
  • 過去の会話をRAGで参照し、AIが以前のやり取りを踏まえて解説や語彙の補足を返す
  • Cloudflare Workers、D1、R2を使い、モバイル向けの軽量なAPI基盤を構築
  • RealtimeKitとOpenAI連携で、リアルタイム翻訳の体験検証を可能にした

結果

言語が違う相手とテキストでも音声でも通話でもやり取りできる状態を、企画書ではなく実物で確かめられました。翻訳を返して終わりにせず、分からない表現をその場で聞いて語彙として残す導線まで入っているので、一度使って終わるアプリか毎日開かれるアプリかを、本開発に予算を投じる前に見極められます。

投資判断
本開発前に実物で検証
利用体験
音声・通話まで一体
継続利用
学習導線まで内蔵
Beekleだからできたこと

AIの単機能ではなく、継続利用される体験全体を設計する

「翻訳できるか」だけでなく、ユーザーが実際に使い続けるプロダクトになるかを本開発前に検証できます。

音声メッセージ、通話、AI解説、語彙帳を一つのモバイル体験に統合し、翻訳後の学習導線までMVPに組み込みました。

Beekleは、AI APIだけでなくモバイルUI、リアルタイム通話、エッジAPI、データ保存まで一つのプロダクトとして実装できます。この案件ではFlutter、Cloudflare Workers、D1、R2、RealtimeKit、OpenAIを組み合わせ、翻訳・通話・AI解説・語彙帳を別機能ではなく一続きの利用体験として検証できる形にしました。

プロダクト体験設計

生成AI OCRによるレシート売上データ化システム

多拠点運営/生成AI OCR 多拠点の売上集計業務 開発期間:PoC開発

課題

複数拠点から集まるレシート画像を見ながら、売上金額や件数を手入力する業務に時間がかかっていました。機器や帳票の形式が一定ではないため、従来型の固定OCRだけでは実務に必要な精度と確認しやすさを両立しにくい状況でした。

  • レシート画像から売上金額、件数、日付、拠点名を構造化したい
  • 帳票形式や表記ゆれがあっても、同じ項目として扱いたい
  • 読み取り結果を人が確認・修正できる画面まで必要

解決策

Laravel + Inertia + Reactで、画像アップロード、生成AI OCR、構造化データ化、確認画面までを備えたPoCを構築。画像から一度テキストを抽出し、その後に業務項目へ整形する二段階のLLM処理により、読み取り結果を確認しやすい形にしました。

  • レシート画像をアップロードし、OCR結果と元画像を並べて確認できる画面を実装
  • 生成AIで生テキスト抽出と業務項目へのJSON構造化を分けて処理
  • 金額、件数、日付、拠点名などを標準項目にそろえて出力

結果

レシートを見ながら数字を打ち込む作業が、アップロードして目視で確かめるだけの作業になりました。拠点ごとに帳票の形が違っても同じ項目に揃うので、集計前の整形が要りません。読み取り結果は元画像と並べて直せるため、精度を人が担保したうえで売上データとして扱えます。

入力作業
打ち込みから確認へ
集計準備
整形作業が不要
精度
人の確認を前提に設計
Beekleだからできたこと

AIを100%自動化ではなく、人が安心して使える業務フローに組み込む

AIの読み取り精度に業務全体を賭けず、入力工数を減らしながら最終的なデータ品質は人が担保できます。

OCRと業務項目への構造化を二段階に分け、元画像と抽出結果を並べて確認・修正できる画面まで実装しました。

Beekleは、AIの精度を一発勝負にせず、処理を分解して人が検証できる地点を設計します。この案件では、画像からの生テキスト抽出と業務項目へのJSON構造化を二段階に分け、さらに元画像と結果を並べて確認・修正できる画面まで実装しました。AIが誤った場合でも業務を止めない構造を最初から持たせています。

AIと業務設計

飲食店レコメンドAIプロダクトのプロトタイプ開発

飲食・営業支援/AIレコメンド 店舗紹介・会員向け推薦サービス 開発期間:プロトタイプ開発

課題

会員や営業担当が、目的・好み・人数・利用シーンに合う飲食店を毎回手作業で探して提案していました。単なる店舗一覧ではなく、利用者の文脈に合わせて候補を絞り込み、推薦理由まで説明できるプロダクト体験が必要でした。

  • 条件検索だけでは、会食・接待・記念日などの文脈に合う提案になりにくい
  • 営業担当の経験に依存し、提案品質や推薦理由が属人化する
  • 会員情報、店舗情報、推薦履歴を一つの体験として扱いたい

解決策

React + Honoで、AI推薦セクション、飲食店一覧・詳細、推薦ダイアログ、会員管理、営業担当ダッシュボードまで含むプロトタイプを構築。店舗データと利用者の条件をもとに、AIが候補を絞り込み、提案理由を添えてレコメンドする業務アプリとして設計しました。

  • 希望条件・利用シーン・会員属性をもとに飲食店候補を提示するAI推薦UIを実装
  • 店舗カード、詳細画面、推薦ダイアログをつなぎ、提案までの導線をプロトタイプ化
  • 会員管理、担当者向けダッシュボード、Hono APIを含む構成で検証可能にした

結果

毎回ゼロから店を探して提案する時間が要らなくなりました。会食か接待か記念日かで出てくる候補が変わり、なぜその店なのかも一緒に返るため、提案の質が担当者の経験年数に左右されません。会員管理や担当者向けの画面まで動くので、運用の形まで含めて社内で判断できます。

提案時間
探す手間が不要に
提案品質
経験年数に依存しない
判断材料
運用画面まで確認可
Beekleだからできたこと

ベテランの暗黙知を、理由を説明できるAI体験へ変える

担当者の経験年数に左右されず、利用シーンに合う提案を同じ品質で行えるようになります。

会食・接待・記念日などの文脈と会員属性をもとに候補を絞り、推薦理由まで返すAI推薦UIと営業ダッシュボードを構築しました。

Beekleは、AIの推薦ロジックだけでなく、それを現場が使うための会員情報・店舗情報・推薦UI・担当者ダッシュボードまで一体で設計できます。この案件でも、利用シーンや会員属性から候補を出すだけでなく、推薦理由を表示し、そのまま営業担当が提案に使える業務導線までプロトタイプ化しました。

属人業務のAI化

生成AI OCRによる商品カタログデータ化PoC

製造・EC/生成AI OCR メーカー向けDX PoC 開発期間:PoC開発

課題

商品カタログPDFに含まれる適合情報を、CMSで扱える構造化データへ変換できるかを検証する必要がありました。単純なOCRではなく、表の読み取り、表記ゆれの整理、既存マスタとの照合まで含めた業務フローのPoCでした。

  • カタログPDFから商品と適合情報を読み取りたい
  • 表記ゆれや範囲表記を既存マスタと照合したい
  • 完全自動化ではなく、曖昧な候補だけ人が確認できる運用にしたい

解決策

Pythonで、PDFからの情報抽出、生成AIによる表構造の整理、既存マスタとの照合、CMS取込CSV生成までを行うPoCパイプラインを構築。抽出結果と候補を人が確認できるレビュー画面も用意し、実運用に近い形で検証しました。

  • PDF文字抽出とVisionモデルを使い分け、読み取り対象を効率化
  • 抽出結果を既存マスタ候補へ照合し、確信度で振り分け
  • レビュー後にCMS取込用CSVを出力する流れを試作

結果

カタログPDFから適合情報を転記する作業が、確認だけで済むかを実データで検証しました。表記ゆれや範囲表記は既存マスタの候補に自動で当たり、迷うものだけがレビュー画面に上がるため、全件に目を通す必要がありません。本開発に進む前に、どこまで自動化できて残りにどれだけ人手が要るかを把握できます。

転記作業
確認だけに縮小
確認範囲
迷う項目のみに限定
投資判断
自動化の範囲を事前把握
Beekleだからできたこと

自動化できる範囲と、人が見るべき範囲をPoCで切り分ける

本開発前にAIで削減できる作業量と残る人手を把握し、投資判断を具体化できます。

PDF抽出、Vision、既存マスタ照合、確信度による振り分け、レビュー、CMS用CSV生成まで実運用に近いパイプラインを試作しました。

Beekleでは、PoCをモデル精度のデモで終わらせず、本番業務に必要な前後工程まで組み込みます。この案件でも、PDF抽出・Vision・既存マスタ照合・確信度による振り分け・人のレビュー・CMS取込CSVまで一連のパイプラインを作ったため、本開発前に『どこまで自動化でき、どこに人手が残るか』まで判断できました。

AI PoC設計

完成しなかった調査プラットフォームの引き継ぎ開発

心理学研究/調査プラットフォーム 株式会社イデアラボ 開発期間:2026年7月下旬に引き継ぎ、約1か月で稼働状態(継続中)

課題

先行する開発会社が長期にわたって開発を進めたものの完成に至らず、リリースの見通しが立たない状態でした。心理学研究で使う調査の配信と回答収集だけでなく、個人契約とチーム契約、サブスクリプション課金までを含む範囲で、決めきれていない仕様が各所に残っていました。

  • 長期化した開発を引き継ぎ、どこまで作れているかの把握から始める必要があった
  • 契約終了や決済失敗が起きたとき、利用可否とデータをどう扱うかが未決だった
  • 調査者・運営管理者・チーム管理者で必要な画面と権限が整理されていなかった

解決策

引き継ぎ後、やりたいことを要求カードとして洗い出し、作る・後回し・作らないを先に決めてからユーザーストーリーと受入条件へ展開しました。仕様と進捗は自社開発のPM基盤「PM on Rails」で1本につなぎ、打ち合わせで出た未決事項がそのままタスクと進捗まで流れる状態にしています。

  • 要求を47件のカードに整理し、必須・重要・できれば・見送りで範囲を確定
  • Laravel と Stripe のサブスクリプションで、個人・チームの契約と決済失敗時の復旧を実装
  • 契約終了後の移行猶予、データ保持期間、利用停止の条件を仕様として決めきった

結果

引き継ぎから約1か月で動く状態まで到達し、現在も開発を継続しています。決まっていないことを先に洗い出して潰す進め方にしたため、実装が進んでから仕様が揺れて作り直す場面がありません。契約や決済まわりのように後から矛盾が出やすい箇所も、条件を先に確定させています。

引き継ぎ後
約1か月で稼働状態
先行ベンダー
完成に至らず
体制
要件整理から実装まで一貫
Beekleだからできたこと

止まった開発は、決まっていないことから片づける

引き継いだ開発が、途中で仕様が揺れて止まり直すことなく、動く状態まで進みます。

完成に至らないまま長期化していた開発を引き継ぎ、要求を47件のカードに整理して範囲を確定させたうえで、約1か月で稼働状態まで持っていきました。

Beekleは、引き継いだ開発でいきなり実装を再開しません。まず決まっていないことを洗い出し、契約終了時の扱いや決済失敗時の復旧のように後から矛盾が出る箇所を先に確定させます。この案件では、その進め方を自社のPM基盤に載せて、打ち合わせの未決事項からタスクの進捗までを同じ流れで追える状態にしました。

難航案件の引き継ぎ

BtoB受発注マッチングプラットフォームの新規開発

BtoBマッチング/業務システム 事業会社の新規プラットフォーム事業(受託)

課題

既存事業を持つ事業会社が、買い手と供給側をオンラインで結ぶ新しいマッチングプラットフォームを立ち上げるにあたり、会員管理・課金・運営管理までを備えた本番サービスを一から構築する必要がありました。

  • 発注者・受注者・運営の3者で権限と画面が異なる
  • 継続課金と従量課金を併用する料金モデルの実装
  • 長期運用に耐える保守性とデータ整合性の確保

解決策

APIとWeb、管理画面までを一貫して開発。APIスキーマを起点に型安全なクライアントを自動生成し、フロントとバックの齟齬を抑えました。約3年にわたり継続開発・運用しています。

  • NestJS + Prisma + PostgreSQLのAPIと、Next.js + 管理コンソールを構築
  • OpenAPIスキーマからクライアントを自動生成し型安全に連携
  • サブスク+チケット課金、3ロールの認証、CI・AIレビューを整備

結果

発注者・受注者・運営の3者が同時に使える形で立ち上がり、継続課金と従量課金を併用する料金モデルもそのまま運用に乗りました。APIの定義から画面側のコードを自動生成しているため、機能を足すたびに認識違いで作り直す事態が起きません。結果として約3年、土台を作り直さずに機能を積み増せています。

立ち上げ
3者分を同時に運用開始
収益モデル
課金の併用に対応
保守性
3年間作り直しなし
Beekleだからできたこと

初期開発だけでなく、事業が伸びても作り直さない土台を設計する

料金や機能を追加するたびに大規模な作り直しをせず、サービスを長期的に育てられます。

3ロール、サブスク+従量課金、APIと管理画面を一貫して構築し、OpenAPIから型安全なクライアントを生成。約3年間、土台を作り直さず継続開発しています。

Beekleは、API・Web・管理画面を別々に作るのではなく、APIスキーマを中心に型を共有する設計を採れます。この案件ではOpenAPIからクライアントコードを自動生成し、3ロールの権限と複数課金方式を含むサービスを約3年間継続開発。土台を作り直さず機能を積み増せていること自体が設計の再現性を示しています。

長期運用を前提とした設計

全26件中 9〜16件を表示

お客様の事業成長をサポートします

無料相談、または「動くプロトタイプで発注前に判断する」仕組みをまとめた資料からどうぞ

PDF・約20ページ・無料/メールアドレスのみで受け取れます