技術的な課題がはっきりしていた構築事例を選び、背景と判断の根拠まで整理しました。
研究員が毎回開発チームに依頼しなければ、データ前処理からモデル推論までのパイプラインを変更できませんでした。研究の方向性が頻繁に変わる国家研究課題の特性上、開発チームを介さずに研究員自身が構成を調整できる必要がありました。
主な技術選定
前処理から推論までをノード単位に分割し、接続方式で構成
研究員ごとに必要な前処理段階やモデルの組み合わせが異なり、固定された一つのパイプラインでは対応できませんでした。各段階を独立したノードとして作り、研究員が必要なノードだけを選んで接続できるようにしたことで、新しい実験構成のたびに開発チームへの依頼なしですぐ試せるようになりました。
採用担当者が一つの求人に集まる応募書類を一つひとつ読み、要件に合っているかを判断していました。応募者が増えるほど検討時間が延びる一方、なぜ特定の候補者を選んだのか根拠を残すのも手間でした。
主な技術選定
適合度スコアだけでなく根拠項目も併せて表示
採用担当者はスコアだけを見てもなぜその結果になったのかを説明できず、実際の意思決定には使えませんでした。どの要件が合致しどの要件が不足しているかを項目別に分けて表示することで、担当者が最終判断の根拠として使えるようにしました。
決済代行会社から届く取引明細と銀行の入金明細を、担当者が毎日Excelで突き合わせていました。件数が増えるにつれて照合作業が1日で終わらなくなり、締めが遅れると次の精算にも影響が出ていました。
主な技術選定
照合結果を自動確定せず、例外案件のみ担当者確認後に締める運用
金額が関わる精算のため、システムが自動的に確定してしまうと誤りがあっても発見が遅れます。ルールに合致する案件は自動処理する一方、ルールから外れる案件は必ず人が確認・承認して初めて締められるようフローを分けました。
社内規程や技術文書を検索したいものの、外部のLLMサービスに文書をアップロードできないというセキュリティ方針がありました。文書を社外に出さずに質問へすぐ答えられる仕組みが必要でした。
主な技術選定
外部LLMではなく社内網の中で動く言語モデルを構築
文書を外部に持ち出さないことが要件の前提でした。モデルを社内インフラに置くことで、質問と文書が会社の境界を越えない構造を作れました。
本部が加盟店の運営指標を店舗別に個別に報告を受けており、どの店舗により支援が必要かを判断するには担当者がその都度レポートを取りまとめる必要がありました。
主な技術選定
指標は店舗が直接入力しつつ、本部で最終確認の段階を設ける構成
店舗現場のデータは店舗自身が最も正確に把握していますが、入力値をそのまま信頼すると誤入力がそのまま指標に反映されてしまう問題がありました。店舗による入力の後に本部担当者が確認する段階を一つ設けることで、データの正確性と現場の負担のバランスを取りました。
設備に異常が発生しても、現場作業者が目視で確認するまで誰も気づけませんでした。設備信号はPLCに残っていましたが、それを集約して見る画面がありませんでした。
主な技術選定
HTTPポーリングではなくMQTTによる設備信号の収集
設備のPLCは1秒あたり数百件単位で信号を送り出しますが、一定周期で状態を問い合わせるポーリング方式では周期の間に発生した信号がそのまま失われていました。ブローカーを置いて設備側が信号をパブリッシュする方式に変え、欠落なく順序どおりに受け取れるようにしました。
各拠点の電力使用量を月末の請求書でしか確認できておらず、削減目標を立てても途中でどれだけ達成できているかを知る方法がありませんでした。使用量が急増した時点をその都度確認できないため、原因の把握も遅れがちでした。
主な技術選定
時系列データの保存にTimescaleDBを使用
各拠点で短い周期で蓄積される電力使用量データは時間が経つほど膨大になりますが、その後は今月ではなく前年同時期と比較するといった、期間をまたぐ照会が必要になりました。時系列データに適した構造を用いることで、期間別の集計照会性能を確保しました。
受注から出荷まで、各工程がどこまで進んでいるかを現場のホワイトボードと担当者の記憶に頼っていました。工程が増えるほど、今どの段階で遅延が生じているのかを把握しづらくなっていきました。
主な技術選定
ホワイトボード方式をそのままボード型画面へ移行し、データ構造は新規設計
現場担当者はすでにホワイトボード上で工程を動かしながら確認する方式に慣れていました。画面の操作方式は慣れ親しんだ形を維持しつつ、裏側のデータは工程移動の履歴が残るよう新しく設計し、後からどの工程で遅延が繰り返されているかを追跡できるようにしました。
動画編集をブラウザ内で完結させたいという顧客でした。デスクトップ編集ソフトのインストールなしにレイヤーとタイムラインを扱える初期バージョンが必要でした。
主な技術選定
キャンバスのレンダリングをWebGLで実装
レイヤーが何層も重なり、タイムラインをスクラブするたびに再描画が必要でしたが、通常のCanvas 2Dではレイヤーが増えるほど画面がカクついていました。GPUを使うWebGLへ移行したことで、レイヤー数が増えても編集中の画面応答を保てるようになりました。
店舗ごとに在庫台帳が別々に運用されていました。本部が全体の在庫を把握するには店舗に電話をかけて回るかExcelを集約する必要があり、その間に実在庫と台帳がずれることが繰り返し起きていました。
主な技術選定
既存の会計システムはそのままにし、在庫データはAPIのみで同期
会計システムを新規に作り直すと税務処理まで再検証する必要が生じ、リスクが大きくなります。在庫管理の領域だけを新しく構築し、締め時点で会計側に必要な数値だけをAPIで渡す方が安全でした。
全国各地でスクリーンゴルフ店舗をフランチャイズ展開する本部でしたが、店舗機器の状態や売上は各店舗のPCにしか残っていませんでした。特定の店舗の機器が停止しても、本部は顧客からのクレーム電話が来るまで気づく方法がありませんでした。
主な技術選定
店舗PCに常駐エージェントを置き、PostgreSQL中央サーバーへ状態をプッシュする構成
店舗のインターネット回線は地域によって品質が異なり、中央から店舗へ毎回状態を問い合わせる方式では応答が遅い、あるいは完全に途切れる店舗がありました。店舗側から先に送信する構成に変えたところ、回線が不安定な店舗でも最低限の周期で状態が届くようになりました。
全24件の実績はポートフォリオでご覧いただけます。
ポートフォリオを見る