AI駆動型コールセンター品質保証・性能最適化システムの開発 本プロジェクトでは、AIとHuman QAを組み合わせ、コールセンターの全通話をモニタリング・評価するシステムを開発しました。音声解析、感情分析、可視化を通じて、通話品質の改善とエージェント育成を支援します。開発工数は100MM、開発期間は1年間です。 プロジェクト概要 開発対象 AI駆動型コールセンター品質保証・性能最適化システム 開発工数 100MM 開発期間 1年間 業務課題 01．一部通話のみを評価 QAリソースの制約により、すべての通話を確認できないことが課題となっていました。 02．失敗原因を把握できない 顧客不満の根本原因をリアルタイムに分析できませんでした。 03．性能改善が難しい 接続率やエージェントのパフォーマンスを効果的に改善することが困難でした。 04．発信業務の無駄 未検証の電話番号への発信により、工数が失われていました。 導入ソリューション 01．AI＋Human QAのハイブリッド評価基盤 AIによる自動分析とQA担当者による確認を組み合わせ、通話品質を継続的に評価する基盤を構築しました。 02．コールセンター業務の統合モニタリング 通話品質、顧客感情、エージェントのパフォーマンスを一元的に可視化しました。 03．データに基づく業務改善 分析結果をエージェントのコーチング、応対品質の改善、発信キャンペーンの最適化に活用しました。 主な実現内容 01．全通話の音声解析 すべての通話を対象に、音声解析と自然言語処理による文字起こし・評価を実施しました。 02．AI自動スコアリング 統一された基準で通話を自動評価し、人による評価バイアスを低減しました。 03．Human QAによる検証 AIの評価結果をQA担当者が確認し、品質保証プロセスを補完しました。 04．リアルタイムダッシュボード トレンド、失敗パターン、改善につながる情報へリアルタイムにアクセスできるダッシュボードを構築しました。 05．コーチング支援・感情分析 エージェントの研修ニーズと顧客感情を把握し、CSATの向上に活用しました。 06．CRM／ダイヤラー統合 通話結果を顧客プロファイルや発信キャンペーンの目標と関連付けました。 使用技術 01．バックエンド：ASP.NET API、C# 02．フロントエンド：ReactJS 03．データ・クラウド：Azure SQL Server、Cosmos DB、Airtable、Azure 04．AI技術：音声解析、自然言語処理（NLP）、感情分析 コールセンターAIについて相談する AIソリューション実績集をダウンロードする
ハラルSNS向け3段階AIコンテンツ審査システムの検証・設計 本プロジェクトでは、インドネシア市場向けのハラルSNSにおいて、テキスト・画像・動画を対象とした3段階のAIコンテンツ審査フローを検証・設計しました。開発工数は22MM、開発期間は5カ月です。 プロジェクト概要 開発対象 ハラルSNS向けAIコンテンツ審査 対象コンテンツ テキスト・画像・動画 作業範囲 3レイヤー構成の実装・検証・評価・ベンチマーク・最終提案 開発工数 22MM 開発期間 5カ月 AIコンテンツ審査フロー ユーザーが投稿したテキスト・画像・動画を、端末、AWS、外部AIの3つのレイヤーで審査します。端末側でNG候補を絞り込み、追加確認が必要な投稿だけを上位レイヤーへ送信する構成です。 01．レイヤー1｜端末 テキストはNGワード辞書、画像・動画はTensorFlow Liteを使用して端末上で審査します。 02．レイヤー2｜AWS テキストはOpenAI Moderation API、画像・動画はONNX Runtimeを使用して追加審査を行います。 03．レイヤー3｜外部AI 追加確認が必要な場合は、SightengineおよびGoogle・AWS・AzureのAIサービスを利用して審査し、投稿可否を確定します。 実装・検証のポイント 01．多言語テキスト処理 テキストを小文字化し、記号・絵文字を除去して表記を統一しました。また、「4→a」「@→a」などの類似文字を置換しました。 言語別にトークン化・ステミングを行い、ホワイトリストを除外したうえでNGワードと照合しました。 02．画像・動画処理の最適化 AIモデルの入力仕様に合わせて画像をリサイズし、動画から判定対象となるキーフレームを抽出しました。 重複フレームを除去して処理データ量を削減し、信頼度スコアに応じて上位レイヤーへ送信しました。 03．AIサービスの比較・評価 顧客提供のデータセットと評価基準を使用して検証し、サービス別に判定精度と処理時間を測定しました。 管理者の目視結果とAIの判定結果を比較し、評価レポートを作成したうえで採用構成を提案しました。 AIコンテンツ審査について相談する AIソリューション実績集をダウンロードする
滅菌バッグの処理状態を判定するAI画像解析システムの開発 本プロジェクトでは、スマートフォンで滅菌バッグを自動撮影し、AIがインジケーターテープの色変化を解析するシステムを開発しました。滅菌処理状態の判定から記録・管理までを一元化しています。開発工数は16MM、開発期間は4カ月です。 プロジェクト概要 開発対象 滅菌バッグのAI自動判定システム 作業範囲 設計、AI開発、ソフトウェア開発、インフラ、テスト 開発工数 16MM 開発期間 4カ月 システムの仕組み 現場スタッフが滅菌バッグを設置すると、iPhoneアプリがバッグを自動検出・撮影し、画像をAI画像解析APIへ送信します。AIがインジケーターテープを抽出して色を解析・分類し、判定結果をアプリへ返します。画像、撮影日時、判定結果はMicrosoft Azureへ保存され、管理者は管理用Webから確認・対応できます。信頼度の低い判定は管理者へ通知されます。 コアテクノロジー 01．AI画像解析 解析精度を高めるため、撮影した画像を前処理します。事前学習済みの分類モデルをファインチューニングし、インジケーターテープの領域を特定・抽出します。 抽出したテープの色変化を解析し、滅菌処理状態と判定結果の信頼度を出力します。 02．自動撮影モバイルアプリ 従業員・医療機関ごとのアカウントでログインし、滅菌バッグを自動検出して撮影・クロップします。判定結果を画面に表示し、処理状況を音で通知します。 オフライン時にはデータを一時保存し、通信の復旧後に自動で再送します。 03．クラウド・管理基盤 画像、撮影日時、判定結果をMicrosoft Azureへ保存し、ユーザーと医療機関の紐付けを管理します。 管理用Webでは、データの検索・編集、画像のダウンロード、CSV出力に対応しました。また、信頼度の低い判定は管理者へ確認通知を送ります。 AI画像解析について相談する AIソリューション実績集をダウンロードする
海運データ分析を支えるLakehouse＋AIエージェント基盤の構築 本プロジェクトでは、船舶・基幹システムのデータをLakehouseへ統合し、自然言語で分析・検索できるAIエージェント基盤を構築しました。全社5部門で220 MAUまで利用が広がり、月間6,800件の質問に活用されています。 プロジェクト概要 構築対象 海運データ分析を支えるLakehouse＋AIエージェント基盤 利用状況 220 MAU、全社5部門、月間6,800問 統合対象 68隻・14システム 文書検索対象 契約書・船級規則など2.4万件のPDF 回答正答率 91.5％（人手評価） 従来の課題 01．データ抽出・加工に時間がかかる 1つの問いに回答するまで15～21日を要し、4部門を経由してデータを手作業で抽出・加工していました。 02．月次報告書の作成負担 月次報告書の作成に6人日を要していました。 コアテクノロジー 01．Lakehouseによるデータ統合 Delta Lake上にBronze、Silver、Goldのメダリオン構成を構築しました。210件の生テーブルを、38件の認証済みGoldマートへ集約・精選しました。 指標ロジックは単一のSQL定義としてGitで管理しました。 02．Unity Catalogによるガバナンス RBAC、行フィルタ、列マスキングを適用しました。AIエージェントは認証済みのGoldマートのみを参照し、質問者本人の権限でSQLを実行します。 権限外または対象範囲外の質問には、理由を示して回答を保留する仕組みとしました。 03．AIエージェント・文書RAG 自然言語による質問からSQLを生成・検証・実行します。SQLの実行成功率は94.2％で、12カ月の監査における捏造数値は0件でした。 さらに、2.4万件のPDFをベクトル検索し、根拠となる条項番号とページを明示して回答します。 導入後の効果 01．自然言語質問への超高速応答 自然言語による質問への平均応答時間を6.2秒としました。 02．低コストでの運用 1回答あたり€0.031のコストで運用しています。 03．コスト削減機会の創出 燃料費・港費において、初年度€1.8Mのコスト削減機会を創出しました。 04．月次報告の自動化 自動化によって、月次報告の作業時間を40分に短縮しました。 AI・データ活用について相談する AIソリューション実績集をダウンロードする
Microsoft Fabric Lakehouseによるデータ統合・AI活用基盤の構築 本プロジェクトでは、複数の内部・外部データをMicrosoft Fabric Lakehouseへ統合し、リアルタイム処理とAI活用に適したデータ基盤を構築しました。プロジェクト規模は20人月、開発期間は5カ月で、テキスト・画像・音声・動画などの多様なデータ形式に対応しました。 プロジェクト概要 構築対象 データ統合・AI活用基盤 プロジェクト規模 20人月 開発期間 5カ月 対応データ形式 テキスト・画像・音声・動画 従来の課題 01．データの分散 データが複数の場所に分散していたため、必要なデータの収集に多くの時間と労力を要していました。 02．意思決定基盤の整備 データ活用に必要な最新型DWHの整備が急務となっていました。 ソリューション 01．データの一元化 内部・外部の構造化データと非構造化データをLakehouseへ集約しました。 02．リアルタイム処理 Delta Tableを活用し、最新データの処理を支援する基盤を構築しました。 03．AI活用基盤 データ分析とAI活用に適したLakehouseアーキテクチャを構築しました。 データ活用の仕組み 01．データ統合：内部・外部のさまざまなデータをLakehouseへ集約しました。 02．データ処理：集約したデータをETLで変換・整理し、Delta Tableで管理しました。 03．分析・AI活用：処理したデータをPower BIとAzure AI Foundryへ展開しました。 使用技術 Python｜pandas｜PyTorch｜Microsoft Fabric｜Azure AI Foundry｜Azure AI・データ活用について相談する AIソリューション実績集をダウンロードする
ECネイティブアプリをReact Nativeへ刷新 本プロジェクトでは、ECプラットフォームを運営する小売企業のiOS／Androidアプリを再構築しました。SwiftとKotlinによる個別開発から、React NativeとTypeScriptを採用したクロスプラットフォームの共通基盤へ移行しました。プロジェクト規模は125人月で、iOSとAndroidの2つのプラットフォームに対応しました。 プロジェクト概要 対象システム ECネイティブアプリ 対象企業 ECプラットフォームを運営する小売企業 プロジェクト規模 125人月 対応プラットフォーム iOS／Android クロスプラットフォーム移行の背景 既存のネイティブアプリは、iOSではSwift、AndroidではKotlinを使用して個別に開発されていました。年間保守工数の約20～25％が更新対応に使用され、1つの機能を両OSで同期するまでに最大約5週間を要していました。 Existing Native Apps Modern Mobile App iOS／Swift Android／Kotlin 年間保守工数の約20～25％を更新対応に消費 1機能の同期に最大約5週間 Framework：React Native Language：TypeScript Platform：iOS／Android Cloud：AWS Service 移行フェーズ：Phase 1｜基本機能 Phase 2｜新機能・UX NTQの担当範囲・進め方 01．共通アーキテクチャ設計 React NativeとTypeScriptを採用し、iOS・Android共通のアプリ基盤を設計することで、2つのコードベースを統合しました。 02．既存機能の再構築 既存アプリの基本機能を移行し、両OSの仕様差異に対応することで、既存機能と同等のUXを提供しました。 03．新機能・UI／UX改善 共通コンポーネントを活用し、新機能の追加とUI／UX改善を実施することで、機能拡張をスピードアップしました。 04．品質検証・本番移行 単体テスト、結合テスト、システムテスト、受入テストを実施しました。テスト後に旧アプリと比較して本番移行を行い、品質を確保しながら円滑に移行しました。 提供価値 01．開発・保守コストの最適化 iOSとAndroidのコードベースを共通化し、二重開発と保守の負担を軽減しました。 02．リリースの迅速化 OS間の機能同期を効率化し、機能提供までのリードタイムを短縮しました。 03．保守性・拡張性の向上 共通コンポーネントを活用し、新機能の追加とUI／UX改善を容易にしました。 マイグレーションについて相談する 実績集をダウンロードする
物流プラットフォームをAWSマイクロサービスへ刷新 本プロジェクトでは、米国物流企業の配送・アカウント・追跡・返品業務を支えるモノリス型の物流プラットフォームを、AWS上のマイクロサービスへ刷新しました。プロジェクト規模は241.45 MMで、システムの拡張性・可用性とデータ活用基盤を強化しました。 プロジェクト概要 対象システム 物流プラットフォーム 対象業務 配送・アカウント・追跡・返品 プロジェクト規模 241.45 MM 使用技術 PHP、PHP 8.1、AWS システム移行の概要 既存の物流プラットフォームはモノリス型で、システム稼働率は85％にとどまり、拡張性と耐障害性に課題がありました。本プロジェクトでは、既存システムをマイクロサービス化し、GCP上のワークロードをAWSへ移行しました。 Services Account、Shipment、Tracking、Return Shipment、Worker Application PHP 8.1、Laravel Platform Docker、Amazon ECS Data RDS MySQL、DynamoDB、ElastiCache NTQの担当範囲・進め方 01．業務・構成設計 物流業務と将来計画を踏まえ、ビジネスドメインを反映したマイクロサービス構成を設計しました。 02．アプリケーション再構築 既存アプリケーションをリファクタリングし、各サービス向けのAPIを開発することで、システムを5つのサービスに分割しました。 03．クラウド基盤移行 AWS基盤を再設計し、GCP上で稼働していたワークロードをAWSへ移行することで、システム基盤をAWSへ統合しました。 04．品質・運用強化 セキュリティテストと監視環境を整備し、監視とセキュリティを強化することで、安定運用を支援しました。 導入効果 01．システム稼働率の向上 障害分離とプロアクティブな監視により、システムの可用性を大幅に向上し、稼働率を85％から99.9％へ改善しました。 02．拡張性・耐障害性の強化 サービス単位で拡張できる構成により、ピーク負荷への対応と障害影響の局所化を実現しました。 03．データ活用基盤の整備 DWHとデータアクセスAPIを整備し、複数のデータソースを対象としたデータ分析を可能にしました。 マイグレーションについて相談する 実績集をダウンロードする
IBM i／AS400生命保険契約管理システムをJava・AWSへ刷新 本プロジェクトでは、生命保険契約管理システムをIBM i／AS400からJava・AWS基盤へ段階的に刷新しました。対象となるRPG資産は約1,200本、プロジェクト規模は約300人月です。資産の特性に応じて60％を自動変換、30％をリファクタリング、10％を再設計するハイブリッド移行方式を採用しました。 プロジェクト概要 対象システム 生命保険契約管理システム RPG資産規模 約1,200本 プロジェクト規模 約300人月 ハイブリッド移行方式 60％自動変換、30％リファクタリング、10％再設計 現行システムの課題 現行の生命保険契約管理システムでは、COBOL 85、RPG、CL、Shift-JIS、DB2 for i、IBM iを使用していました。 ・AS/400ハードウェアの保守EOLによる業務継続リスク ・新商品対応のRPG改修長期化による商品投入の遅延 ・RPG技術者の退職による属人化と技術継承の困難 移行先システム構成 Application Java 17、Spring Boot、JPA、UTF-8 Database Aurora PostgreSQL Batch／Report Spring Batch、PDF帳票 移行支援ツール：Tree Sitter AST解析｜GenAI設計書生成｜AWS DMS｜無停止レプリケーション 課題・アプローチ・提供価値 01．RPG資産の段階移行 課題：約1,200本のRPG資産について、優先度と依存関係を整理する必要がありました。 NTQのアプローチと提供価値：RPG資産を棚卸しして移行ロードマップを策定し、資産特性に応じて60％自動変換、30％リファクタリング、10％再設計を適用しました。これにより、効率と品質を両立し、移行リスクを低減しました。 02．Web・モバイル対応 課題：525画面と紙中心の運用により、Web・モバイルからの契約が困難でした。 NTQのアプローチと提供価値：Java化とAPI整備により契約業務をモダンな基盤へ再構築し、オムニチャネル対応基盤を構築しました。 03．DMSによるDB無停止移行 課題：DB2 for iからAuroraへの移行に伴う業務影響が課題となっていました。 NTQのアプローチと提供価値：AWS DMSを使用してAurora PostgreSQLへ継続的にレプリケーションし、システム切替時の業務影響を最小化しました。 04．バッチ・帳票基盤の刷新 課題：日次バッチ連携により、経営判断にタイムラグが発生していました。 NTQのアプローチと提供価値：規制報告・約款帳票をSpring BatchとPDFで刷新し、標準化・自動化することで、レポーティングをタイムリー化しました。 マイグレーションについて相談する 実績集をダウンロードする
IBM i／AS400物流管理システムをJava・AWSへ刷新 本プロジェクトでは、全国400拠点を展開する大手総合物流企業の倉庫・配送・受発注・料金業務を支える物流管理システムを、IBM i／AS400からJava・AWSのマイクロサービス基盤へ刷新しました。プロジェクト規模は200～300人月で、システムを6つのコアドメインに分割して再構築しました。 プロジェクト概要 対象システム 物流管理システム 対象業務 倉庫・配送・受発注・料金業務 対象拠点 全国400拠点 プロジェクト規模 200～300人月 再構築単位 6コアドメイン 現行システムの問題 現行システムでは、COBOL、RPG、CL、Shift-JIS、DB2 for i、IBM iを使用していました。5年間で取扱量が2.3倍に増加したことで、システム容量が逼迫していました。 ・5年間で取扱量が2.3倍に増加し、システム容量が逼迫 ・夜間バッチの長期化と、EDI連携に数カ月を要する状況 ・紙中心の運用とデータレイクの未整備 移行先システム構成 Backend／Platform Java 17、Spring Boot 3、JPA、AWS EKS Architecture 6コアドメイン、Kafka（MSK）、マイクロサービス Data Platform Aurora、DynamoDB、S3＋Athena DevOps Jenkins、GitLab CI、Prometheus／Grafana NTQの担当範囲・進め方 01．6コアドメインへの分割 ドメイン駆動で業務境界を明確化し、システムを6つのコアドメインに分割しました。各ドメインをSpring Boot 3とAWS EKSで再構築し、サービスの独立性と拡張性を強化しました。 02．Kafkaによるイベント駆動連携 Kafka（MSK）による非同期・疎結合連携とAPI化を行い、リアルタイム連携を実現しました。これにより、システム負荷を平準化し、EDI接続を迅速化しました。 03．用途別データ多層化 Aurora、DynamoDB、S3＋Athenaを用途別に配置し、参照・分析・履歴データを分離しました。これにより、データコストを最適化しました。 04．OR-Toolsによる配車最適化 OR-Toolsの最適化アルゴリズムを導入し、再配車計算と進捗管理を効率化しました。その結果、再配車計算にかかる時間を10分の1に短縮しました。 導入効果 01．可用性・拡張性の向上 サービスの独立性を高め、取扱量の増加に柔軟に対応できるシステムを実現しました。 02．リアルタイム連携の実現 夜間バッチの負荷を平準化し、EDI接続のリードタイムを短縮しました。 03．データ活用基盤の確立 データレイクを整備し、AI／BIによるデータ活用を促進しました。…
COBOL販売管理システムをJava／Webへ刷新 本プロジェクトでは、COBOLで構築された販売管理システムを、Java／Webへ段階的に再構築するモダナイゼーションPoCを実施しました。PoCでは3本、約18,000 LOCのプログラムを対象に、6週間でAIを活用した移行方法と品質を検証しました。 プロジェクト概要 対象システム 販売管理システム 業務範囲 受注 → 出荷 → 請求 → 月次締め PoC検証プログラム 3本（約18,000 LOC） PoC期間 6週間 全体移行計画 301本（511,646 LOC）を全8ウェーブで段階移行 全体移行期間 10カ月想定（当初想定15～18カ月から最大約44％短縮） システム移行の概要 現行システムではCOBOLを使用し、データ構造が索引ファイルに依存しているため、Web化や機能拡張が困難でした。本PoCでは、バックエンドにJava 17、Spring Boot 3、REST API、JPA、フロントエンドにVue 3、TypeScript、FR設計、データベースにPostgreSQL 15以降を採用した移行先システムを検証しました。 現行システム 移行先システム構成 COBOL 索引ファイル依存 Web化・拡張が困難 Backend：Java 17、Spring Boot 3、REST API、JPA Frontend：Vue 3、TypeScript、FR設計 Database：PostgreSQL 15+ 移行・品質検証：Liquibase、Playwright E2E、DB比較自動化 課題・アプローチ・PoC実証結果 01．AI Agentsによる移行高速化 課題：COBOL人材の不足により、システムの保守と移行を継続することが困難でした。 NTQのアプローチとPoC実証結果：25のAI Agentスキルを活用し、ロジック抽出、UML・BPMN生成、検証を自動化しました。その結果、移行作業を64日から11.5日へ短縮し、約5.5倍に高速化しました。 02．3フェーズ分析による可視化 課題：COBOLのロジックがブラックボックス化し、Web化が困難でした。…