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

解決策

HEXACO-100をベースに、6次元24要素のスコアリングを実装。LLMは自由な文章生成ではなく、スコア・ファセット・職種要件・採用ペルソナを入力に、JSON Schemaで出力を固定した分析エンジンとして使いました。個人レポート、職種適合、チーム相性、リスク分析まで返すHR AIエージェントとして、企業アカウント管理、招待URL発行、PDFレポートまで含めて構築しています。

• HEXACO-PI-R 100項目版の逆転項目・ファセット・ドメイン集計を実装
• LLM分析を要約、強み、注意点、職場適応、相性、リスクなどのセクションに分けて並列実行
• 採用ペルソナ生成、候補者マッチング、チーム相性分析を構造化出力付きAIジョブとして非同期化

結果

面接担当者の勘に頼っていた採用判断に、誰が見ても同じ基準の物差しができました。性格特性だけでなく職種との適合度、チームとの相性、入社後に想定されるリスクまで同じ様式のレポートで揃うため、なぜこの人を採るのかを社内に説明できます。招待から診断、レポート出力までが業務フローに乗っているので、診断結果を参考資料で終わらせずに採用と配置を決める場で使えます。

解決策

要件定義から入り、As-Is/To-Be整理、業務データの分解、ユースケース定義、受け入れ基準、設計、実装までを一気通貫で推進。AIを使って仕様整理、設計レビュー、実装、テスト観点の整備を高速に回しながら、React NativeとFastAPIで、スキャン、プリンター連携、ネイティブ実機対応を含む倉庫DXシステムを構築しました。

• 倉庫業務のAs-Is/To-Beを整理し、DX後のユースケースとデータモデルを設計
• ユースケース駆動で、要件、設計、API、画面、テスト観点をつなげて開発
• スキャン、プリンター、端末固有のネイティブ制御を含む現場実装まで対応

結果

出荷の現場から、紙とベテランの記憶が抜けました。いま何がどこまで終わっているかが画面に出るので、進捗は現場を歩き回らずに確かめられます。例外対応と現場の判断ポイントは、要件定義の段階で洗い出してから作っています。稼働後、お客さまからは、在庫担当が「楽過ぎて無理です。戻れないです」と話していると伺いました。

解決策

LINEベースの介護情報マッチングプラットフォームを開発。文字入力不要で選択肢をタップするだけで最適な介護サービスを紹介。

• 幅広い年齢層が使い慣れたLINE上でサービスを提供
• 文字入力不要、選択肢タップのみで完結するシンプルUI
• いくつかの質問に答えるだけで推奨介護サービスを紹介

結果

探す側は、複数のサイトを見比べずに、使い慣れたLINEで質問に答えるだけで候補にたどり着けます。文字入力をなくしたので、高齢のご本人でも家族の手を借りずに最後まで進められます。事業者側には、絞り込みが済んだ状態で相談が届きます。

解決策

収益・体験の中核機能をFlutterで実装しながら、要件・設計・受入テストを記録として残す開発基盤を整備。開発はユースケース駆動で進め、自社開発のプロジェクト管理ツールとAIエージェントを組み合わせたAI駆動の開発フローで、設計から実装・レビューまでを回しました。

• iOS・Androidのサブスク課金、アプリ内広告、プッシュ通知、ネイティブ機能連携を実装
• ユースケース単位で要件を起票し、設計判断を選択肢と却下理由まで記録・E2E化
• 自社のプロジェクト管理ツールとAIエージェントを組み合わせた開発フローを運用

結果

配信中のアプリを止めずにFlutterへ移行し、課金・広告・通知という売上に直結する機能を作り切りました。なぜその設計にしたのかを却下案まで含めて残しているため、担当者が代わっても過去の判断をそのまま読んで引き継げます。受入基準をユースケース単位で自動テストにしたので、リリース前の確認が手作業の総当たりでなくなりました。

解決策

決済・マッチング・チャットを別々の機能として並べず、どこが課金率を左右するかで要件を切り分けてから設計しました。外部決済は差し替え可能なドライバとして抽象化し、課金導線は表示速度が離脱に直結するためサーバーコンポーネント中心に構成。流入増に追従するインフラはコードで管理しています。公開後の改善に向けては、まずBigQueryで購買データを分析し、最終的な顧客データ基盤（CDP）はDatabricks on AWS上に構築しました。約11名体制で、決済からインフラ、データ基盤・分析まで一貫して担当しています。

• 外部決済ゲートウェイを差し替え可能なドライバに抽象化し、トークン化・継続課金・エラー処理まで備えた決済システムを実装
• 属性・条件に基づく相性スコアリングで相手を自動レコメンドするマッチングを実装
• 流入増に備えたECSオートスケール構成をIaC化し、サーバーコンポーネント中心の構成で課金導線の表示性能を確保
• BigQueryで購買データを分析し、最終的な顧客データ基盤（CDP）はDatabricks on AWS上に構築してアプリDB・GA4などを統合
• ロイヤル顧客層を特定し、LP・UGC・課金導線の改善に反映

結果

継続課金・自動マッチング・チャットを備えたサービスが本番で動いています。決済は事業者を差し替えられる形にしてあるので、手数料の見直しや乗り換えは決済部分の差し替えだけで済みます。広告で人が一気に流れ込む場面でも処理能力が自動で増えるため、いちばん申し込みが集まる瞬間に画面が重くなって取りこぼすことがありません。公開後は、BigQueryでの購買データ分析を経てDatabricks上に整えたデータ基盤から優良顧客層を特定し、LPと課金導線の改善に反映しています。作って終わりではなく、次に何を直せば課金率が動くかを数字で決められる状態です。決済、マッチング、インフラ、データ基盤を別々の会社に分けると要件の境目で話が止まりますが、一体の体制で要件定義から運用改善までを持っているため、その議論がそのまま実装につながります。

解決策

自然文で質問すると引用元を示しながらAIが回答する社内ナレッジ検索を構築。単一のベクトル検索に頼らず、メタデータ・全文・ベクトル・グラフ近傍・対応根拠（Claim）の複数経路を統合するHybrid GraphRAGを採用し、根拠付きで精度の高い回答を実現しました。

• 実際のデータ量では通常のベクトル検索だけのRAGは精度・スケールに限界があり、横断回答や引用元の確かさも弱いため、複数資料を突き合わせて照合できるGraphRAGを採用
• Neo4jのナレッジグラフで文書・概念・手順・対応内容を関連付け
• 質問の条件で絞り込んだうえで全文検索と意味の近さによる検索を統合し、資料をまたぐ照合と対応根拠を加えて、回答後に根拠を検証
• 回答には引用元の本文を提示し、資料にない内容を断定しないよう制御する設計

結果

担当者が過去の対応履歴やマニュアルを探し回る時間がなくなりました。普通の文章で聞けば引用元つきで答えが返るので、検索のコツを知っているベテランでなくても同じ回答にたどり着けます。根拠となる本文が添えられ、資料にない内容を断定しないよう制御してあるため、そのままお客様に返してよいかを担当者自身が判断できます。回答の正答率は、複数のプロジェクトで繰り返し計測して、平均95%前後です。

解決策

AIを活用した開発体制で停滞していた案件を引き継ぎ、バックエンド・フロントエンド・インフラまで一貫して再構築。3週間で動作する状態まで仕上げました。

• 既存コードと要件を整理し、AI支援で実装を高速化
• バックエンド・フロントエンド・インフラまで一貫して再構築
• 3週間で完成・動作する状態に到達
• 大手企業が外部委託したセキュリティチェックを一度で通過

結果

3ヶ月動かなかった開発が、引き継ぎから3週間で動く状態になりました。バックエンドからインフラまで一つの体制で見ているため、どこの担当かを切り分ける調整や待ち時間が発生しません。急いで作ると品質が落ちるのではという不安に対しては、発注元の大手企業が外部に委託したセキュリティチェックを、指摘による差し戻しなく一度で通過したことが答えになっています。止まっていたリリースの見通しが立ち、事業計画を引き直せる状態に戻りました。

解決策

お客様へのヒアリング議事録からRFP（提案依頼書）を生成し、その仕様をもとに仕様駆動開発で実装。1日で動作するデモを完成させ、認識をすり合わせました。

• ヒアリング議事録からRFPを生成
• RFPをもとに仕様を定義し、仕様駆動開発で実装
• 1日で動作するデモを完成させ、発注者と認識をすり合わせ

結果

ヒアリングの議事録が、その日のうちに動くデモになりました。発注側は仕様書の文章ではなく画面で判断できるので、思っていたものと違うという事態が、実装を終えたあとではなく初日に分かります。実際に「イメージとずれていない」と評価いただき、以降の打ち合わせを認識合わせではなく中身の検討に使えました。