開発実績

多くの企業で、基幹業務を支えているのは十数年前に作られたシステムです。開発した担当者はすでに在籍せず、設計書も更新が止まっている。結果として「触れないから刷新できない」「刷新できないから見積も取れない」という膠着が起きています。

当社では、この膠着を 「仕様の復元」という独立した工程 に切り出して解消します。既存のソースコード・データベーススキーマ・実際の入出力データを解析し、現行仕様書と自動テストスイートを先に作る。ここまで来れば、刷新は「不明なものを作り直す」作業ではなく「定義された仕様を移植する」作業になり、見積も工程も引けるようになります。

生成AIの登場によって、この解析工程のコストは大きく下がりました。従来は解析だけで数千万円規模になり、それが刷新を断念させる主因でしたが、現在は現実的な費用と期間で実施できます。

建築部材の受発注業務では、図面・見積書・機器表といった非構造の紙資料から情報を読み取る工程に多くの人手がかかります。本プロジェクトでは、これらの資料から設計情報・見積項目・発注品目を抽出するAI機能を、要件整理から本番運用まで一貫して担当しました。

中核となる図面読み取りでは、PDFを画像化してマルチモーダルLLMで複数回推論し、多数決と幾何的な制約による検算で精度を引き上げる方式を採用。項目ごとに根拠・確信度・票の内訳を提示し、確信の持てない項目は参考値として明示的に切り分ける設計にしています。

この案件で最も重視したのは、機能を作ることと、その精度を第三者に説明できる状態にすることを分けて考える点です。指標の定義・値・分母・データセット・測定日・再現コマンドを必ず併記する規約を新設し、一つでも欠けたら「精度が分からない」扱いにしました。モデルを更新した際も既存の数値を流用せず測り直す運用を徹底しています。

あわせて、テナント分離の修復やメモリ最適化（Cloud Run のOOM解消）、アイドル課金の停止やディスクのダウンサイズによるクラウドコスト削減、レビュー自動化とドキュメント規約のCI強制まで手掛けています。

与信は、精度がそのまま損益に直結する一方、誤った判定が利用者に不利益を与えるため、運用の安全性が極めて厳しく問われる領域です。

本プロジェクトでは、予測モデル（LightGBM）そのものの改善に加え、推論エンドポイントのレイテンシ要件を満たすアーキテクチャ選定、数億レコード規模のBigQuery特徴量エンジニアリング、そしてパイプライン基盤の全面移行までを担当しました。

モデルの精度低下が疑われた際には、ブートストラップによる信頼区間推定と統計的検定で原因を切り分け、誤った再学習判断を防いでいます。さらに、月次の運用作業やモデル評価をAIエージェントで自動化し、手作業に起因するオペレーションミスそのものを構造的になくすところまで踏み込みました。

採用面接は、対話の流れに応じて次の問いが変わる動的なプロセスであり、同時に評価の一貫性と説明可能性が強く求められる領域です。本プロジェクトでは、面接官・採用担当者が使う生成AI機能一式を、企画から本番運用まで担当しました。

体感品質の面では、「ユーザーが操作した瞬間には生成済み」を実現する事前生成方式を設計。キャッシュの鍵を「LLMへの入力そのもの」から生成することで、古い生成物を誤って表示する事故が構造的に起きない不変条件を担保し、回帰テストで固定しています。

運用の面では、全てのAI出力に対するフィードバック収集、AI判定と人間の判定の一致率ダッシュボード、ゴールデンデータセットとLLM-as-a-judge による週次の自動回帰テストを整備。「最終判断は常に人間、AIはソフトに指摘するのみ」という運用ポリシーを設計に反映しています。

並行して、インフラ構成の調査から本番DBパスワードの平文取得につながる構造的リスクを特定し、提案書化のうえ Terraform で是正。CIの品質ゲート化や、AIコーディングエージェントを前提とした開発プロセスの規約化も行いました。

社外にデータを出せない製造業では、AI基盤をオンプレミスで持つ必要があります。本案件では、オンプレミスKubernetesクラスタの構築からJupyterHubの導入、Ansibleによる構成管理まで、物理サーバから開発体験までを一貫して設計しました。

工場の外観検査AIでは、現場の照明条件や部品ロットの変化による精度劣化が避けられません。そこで、モデルを作って終わりにせず、AWS SageMaker と Greengrass を用いた「エッジ推論 → データ収集 → クラウド再学習 → エッジ再配信」のサイクルを設計。加えて、センサーからの信号処理をFPGAで実装するなど、クラウドから組み込みまで層をまたいで対応しています。

高速道路上の多数のカメラ映像を解析し、走行車両の軌跡を3D空間に再現するプロジェクトです。技術的な難易度に加え、複数の大手企業が並走する多数のステークホルダー環境での合意形成が求められました。

担当したのは、オンプレミスGPUサーバ上での大規模映像解析パイプラインの基本設計、ハードウェア選定とコスト最適化、車両追跡アルゴリズム（YOLO + BoT-SORT）と車長・車幅推定方式の考案、複数カメラ間のID統合方式の検討、そして基本設計書の起草とステークホルダーへの技術説明です。

提案されていたハードウェア構成を精査し、過剰なGPUとストレージを削減した構成へ最適化できたのは、アルゴリズムの計算量とハードウェア性能の両方を定量的に見積もれたためです。アルゴリズムと物理層を分けて考えないことが、この種のプロジェクトでは効きます。

自動車部品の耐久試験装置で、制御周期が不安定になる不具合が発生していました。ドキュメントはほぼ存在せず、開発した担当者への問い合わせも難しい状況です。当社は、ハードウェアに直接触れることなく、ソースコード・ログ・実機実験の結果をもとに原因分析から報告書の執筆までを担当しました。

まず、リアルタイムLinux上のC++制御ソフトを解析し、制御ループのウェイクアップ時刻計算に問題があることを特定。あわせて、自作の計測コードで工場の実機から制御周期のデータを採取し、ばらつきを定量的に評価しました。

その結果、プログラムの修正だけでは解決できない、CPUコアの分離不足といったシステムレベルの要因が存在することを実験で立証。リアルタイムOS専用機の導入や専用ボードの追加など、複数の解決策を費用対効果とともに整理し、経営判断に使える形で報告しています。

ソフトウェアと組み込みの両方を扱えることが、この種の診断では決定的に効きます。クラウドから制御ループまで、層をまたいで原因を追えることが当社の特徴です。

機械学習の導入において、最も精度の高いモデルが最も良い選択とは限りません。本案件では、複雑なモデルと同等の予測精度を、運用コストが桁違いに低いルールベースのアルゴリズムで実現しました。

「MLを使わない」という判断ができることも、AI開発会社に必要な能力だと考えています。運用し続けられない仕組みは、導入した時点から負債になります。