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

集客後の問い合わせ・購入まで設計

要件整理からデザイン、画面実装、プログラミングまで担当しました。問い合わせ・購入につながる導線を設計し、企業サイト内にショッピング機能を追加しました。

• 問い合わせ・購入につながるコンバージョンポイントの設計
• デザインの刷新と企業サイト内へのショッピング機能の追加
• 商品情報を管理する仕組みの設計・構築

結果

サイトの引き継ぎ後、問い合わせ・購入へ進む導線を見直して売上を回復させました。商品紹介とショッピングを同じサイトで利用できるようにしています。

発注判断の裏側

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

不安だったこと

前の大手制作会社がトップページだけを作り直してリニューアルし、アクセスが大きく落ちて売上が戻らなくなっていました。

決め手

見た目の刷新だけでなく、問い合わせ・購入につながる導線の設計、システムや商品管理まで作れることが決め手になりました。

利用者向けの画面と管理画面を構築

Laravelを使い、会員向けの情報ポータルと運営者向けの管理画面を構築しました。フロントエンドとバックエンドに加え、デザインの一部も担当しています。

• フロントエンドの実装
• Laravelによるバックエンドと管理画面の構築
• デザインの一部を担当

結果

会員や業界関係者が情報を探すポータルサイトを構築しました。利用者向けの画面と、運営側が掲載情報を管理する画面の両方を担当しています。

発注判断の裏側

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

不安だったこと

情報が多く、会員が目的の情報を探せないことが不安でした。

決め手

利用者の画面と、運営側の管理機能まで作れることが決め手になりました。

商品選びと情報収集を同じサイトで

商品の検索・販売に加えて、生産地やワイナリーの紹介、現地レポート、ワインを学ぶ読み物を掲載するECサイトの開発に携わりました。

• 複数の切り口から商品を探せる構成
• 生産地・ワイナリーの紹介と現地レポート
• 商品を知ってから選び、購入するまでの導線

結果

利用者が商品情報や読み物を確認し、好みや用途に合うワインを選んで購入できるECサイトです。

発注判断の裏側

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

比べたもの

ECのパッケージ

決め手

デザインからEC、UXまで考えて作れることと、産地・ワイナリーの読み物と販売を1つのサイトで作れることが決め手になりました。

既存ロジックを活かして画面と機能を接続

バックエンドのドキュメントを読み、既存ロジックを流用しながらReactの画面を実装しました。設計に不備がある箇所は関係者に確認し、改善案を提案して実装を進めました。

• デザインに沿ったReactの画面実装
• NFT発行のサービスフローに合わせた画面側ロジックの調整
• 仕様の確認と改善提案を重ねながら実装

結果

Web3のサービスフローを把握し、NFTを発行する機能と画面をつなぐ実装を行いました。既存ロジックを活かし、関係者と確認を重ねながら短納期の開発に対応した実績です。

発注判断の裏側

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

不安だったこと

開発途中からの引き継ぎで、Web3の流れを短期間で理解できるかが不安でした。

決め手

不明点を確かめ、設計の改善案を出しながら実装できることが決め手になりました。

解決策

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

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

結果

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

発注判断の裏側

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

比べたもの

AIに推薦文や並べ替えを任せる、よくある作り方

不安だったこと

なぜこの順番で薦めたのかを説明できないことと、応答の遅さ・費用が不安でした。

決め手

AIに任せる範囲を入口と出口だけに絞り、並べ替えの根拠を数値で残せることが決め手になりました。

解決策

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

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

結果

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

発注判断の裏側

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

不安だったこと

実験中にデータが欠けたり、二重に数えられたりすることが不安でした。

決め手

短いPoCでも、通信が切れたときの再送とデータの不整合まで設計しながら、速く作れることが決め手になりました。

解決策

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

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

結果

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

発注判断の裏側

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

比べたもの

翻訳APIを組み込むだけの開発

不安だったこと

翻訳・通話・学習の機能がばらばらになり、使い続けてもらえないことが不安でした。

決め手

モバイルの画面、通話、AI、データ保存まで、1社で一続きの体験として作れることが決め手になりました。

解決策

画像のアップロードから、読み取り結果の確認・修正までを試せるPoCをLaravel・Inertia・Reactで構築しました。生成AIで画像から生テキストを抽出し、台数や支払方法別の売上などを業務項目へ整理する二段階の処理です。Excelへの転記を自動化する方式を検証しました。

• レシート画像をアップロードし、OCR結果と元画像を並べて確認できる画面を実装
• 生成AIで生テキスト抽出と業務項目へのJSON構造化を分けて処理
• 台数・現金売上・カード売上・日数などを共通の集計項目にそろえて出力

結果

機種やレイアウトの異なる精算レシートから必要な項目を抽出し、Excel転記を自動化する方式を検証しました。読み取った値を元画像と並べて確認・修正できる画面も実装しています。

発注判断の裏側

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

比べたもの

従来の固定OCR

不安だったこと

機器や帳票の形式がばらばらで、読み取りの精度が出ないことが不安でした。

決め手

読み取りと項目への整理を分け、元の画像と並べて人が直せる画面まで作れることが決め手になりました。