| 項目 | 内容 |
|---|---|
| 対象 | AI・AIエージェントを実際の業務に組み込みたい中小企業。窓口はDX推進部門・情報システム部門、または業務部門。業種は問わず、物流・製造・小売の業務に深い経験があります |
| 解決する課題 | PoC後に本番へ移行できない、既存システムを変えずに定型業務を自動化したい、社内資料の検索や問い合わせ対応に時間がかかる |
| 支援内容 | 社内ナレッジ検索（RAG）、定型業務の自動化、業務システム連携AIエージェント、PoCから本番への移行支援 |
| 期間の目安 | PoCまで平均2週間、本番稼働まで平均2か月 |
| 成果物 | 要件定義書、PoC評価レポート、設計書、精度評価セット・評価結果、ソースコード・環境、運用手順書 |
| 体制 | PM1名、AIエンジニア1名。打ち合わせ・資料・連絡はすべて日本語 |
CHALLENGES
バイナリテックジャパンに寄せられるAI・AIエージェント開発のご相談では、次のような状況がよく見られます。
PoCの先に進めない：生成AIのチャットを試したりPoCを実施したりしたものの、既存システムとの連携、セキュリティ、精度が壁になり、本番環境に載せられていない。
定型業務に人手がかかり続けている：データ収集、内容確認、システム入力、メール作成といった繰り返しの作業を自動化したいが、いま使っている業務システムは入れ替えたくない。
社内資料が活かされていない：マニュアルや規程、過去の案件資料は蓄積されているのに、情報を探したり社員の問い合わせに答えたりするのに時間がかかる。
1つ目の状況は、PoCと本番で求められる条件の違いから生じることが少なくありません。一般にPoCは、限られたデータと少数の利用者で「できるかどうか」を確かめる段階です。これに対して本番では、既存システムとのデータ連携、利用者ごとの権限、操作の記録、精度の継続的な確認といった、業務で使い続けるための仕組みが別途必要になります。そのため、PoCの段階から本番の条件を見据えて対象業務と評価指標を選んでおくと、移行時の手戻りを抑えやすくなります。
SERVICE MENU
AI・AIエージェント開発の支援メニューは次の4つです。いずれも、業務のどこにAIを使うと効果が出るかを見極めるところから始めます。
マニュアル、規程、過去の案件資料などの社内文書を集約し、社員が質問すると関連する文書を検索して、出典付きで回答する仕組みを構築します。回答に根拠の文書が示されるため、利用者は原文で内容を確かめられます。参照できる文書は利用者ごとの権限に応じて制御し、閲覧権限のない資料が回答に使われないように設計します。手法はRAGとベクトルデータベースです。RAG（検索拡張生成）は、質問に関連する文書を先に検索し、その内容を根拠に生成AIが回答をつくる手法で、モデルが学習していない社内固有の情報にも答えられる点が特徴です。なお、本メニューは提供しているサービスですが、現時点で実際の案件での導入実績はありません。
データ収集、内容確認、システム入力、メール作成といった定型業務を、既存の業務システムを残したまま自動化します。生成AI（LLM）と、ワークフローや既存システムのAPIを組み合わせるのが基本の構成です。一般に、文章の読み取りや作成のように柔軟さが求められる部分をLLMに、データの受け渡しや登録のように手順が決まっている部分をワークフローに分担させると、処理結果が安定しやすくなります。本メニューには実際の案件での提供実績がありますが、個別の内容は公開していません。
複数の業務システムや外部サービスを連携させ、情報収集、判断、処理、報告までを一連で実行するAIエージェントを構築します。重要な箇所では処理を止め、人が承認してから先に進む設計にします。実装にはLangGraphを使い、処理の流れを状態を持つグラフとして定義したうえで、次の処理への分岐はコードに書いた条件で決め、承認待ちの状態で一時停止できるようにします。外部ツールの呼び出しにはMCP（Model Context Protocol）を、処理状態の保存にはPostgreSQLを用います。処理状態をデータベースに残しておけば、一般に、承認待ちで止まった処理や途中で失敗した処理をその時点から再開できます。実例として、後述するA社の案件があります。
すでに実施したPoCを本番環境へ移行するための支援で、他社で実施したPoCも対象です。既存システムとの連携、セキュリティ、精度評価、運用監視を、本番で使える状態まで整えます。業務に即した評価用データセットと評価指標を用意して精度を測り、ログと監視ダッシュボードで稼働状況を把握できるようにします。本メニューにも実際の案件での提供実績があり、詳細は公開していません。
PROCESS
全体の期間は、PoCまで平均2週間、本番稼働まで平均2か月です。PoCを他社などで実施済みの場合は、STEP 3の本番開発から始めることもできます。その場合も精度評価は省かず、業務に即した評価用データセットと評価指標を用いて、本番で使える水準にあるかを確かめます。一般に、他社で実施したPoCは、評価に使ったデータや指標が本番の条件と異なることがあるため、引き継ぐ際にはこの確認が欠かせません。
判断点は2つあります。1つはPoCがすでに済んでいるかどうかで、済んでいれば、そのPoCで使われたデータと評価指標を確認したうえで本番開発から入ります。もう1つはPoCの結果がSTEP 1で合意した指標に届いたかどうかです。届かなかった場合は本番開発へ進むことを前提にせず、PoC評価レポートの中で本番化を見送る選択肢も含めて提案します。これは独立した工程ではなく、STEP 2の評価結果としてお伝えする内容です。
目的は、AIを適用する業務と、成功を判断する指標を決めることです。ヒアリングを通じて対象業務を選び、成功指標を定めたうえで、使えるデータと既存システムの状態を確認します。お客様には、業務の担当者のご参加と、業務資料・データサンプルのご提供をお願いしています。対象業務、範囲、指標が確定したらPoCに進みます。指標を先に決めておくのは、PoCの結果を印象ではなく、事前に合意した基準で判断できるようにするためです。
実データで試作版を構築し、精度と業務上の効果を評価します。お客様には、実データと、試作版を使って評価する利用者をご用意いただきます。STEP 1で合意した指標を達成していれば、本番開発に進みます。一般に、サンプルデータだけでは表記ゆれや欠けといった現場データ特有の問題が表に出にくいため、この段階から実データで確かめることに意味があります。
既存システムとの連携、権限管理、ログ、承認フローを実装し、テストを行います。お客様には検収の担当者をお願いし、既存システムのAPIを使う場合は、必要に応じてその提供や調整にもご協力いただきます。検収に合格したら本番稼働となり、運用・改善に移ります。
本番稼働後は、稼働状況の監視、精度の定期評価、改善を行い、RAGを使う場合は参照する文書データも更新します。お客様には運用の担当者を置いていただきます。AIの回答品質は業務ルールの変更や資料の追加によって変わりうるため、一般に本番後も定期的な評価が欠かせません。
DELIVERABLES
成果物 01
成果物 02
成果物 03
成果物 04
成果物 05
成果物 06
精度評価セットを成果物に含めるのは、評価に使ったテストケースが手元に残っていれば、本番後や改修後にも同じ基準で品質を確かめられるためです。
TEAM
バイナリテックジャパンは、PM1名とAIエンジニア1名の体制で本サービスを担当します。打ち合わせ、資料、連絡はすべて日本語で行います。
FEATURES
バイナリテックジャパンは、DX・AI導入コンサルティングを中核の事業としています。AI・AIエージェント開発でも、開発に入る前に、AIを適用する業務と成功を判断する指標を決めるところから始めます。一般に、どの業務に使うかを決めないまま開発を始めると、効果を測る基準が定まらず、本番化の判断が難しくなります。そのうえで、実装から本番稼働後の運用・改善までを担当します。ご相談の時点で対象業務が絞り込めていなくても、業務の選定から一緒に進められます。
バイナリテックジャパンは、WMS、TMS、MES、ERPなどの既存システムを活かしたまま、段階的にAIを導入する方針をとっています。基幹システムを入れ替えるのではなく、既存システムのAPIやワークフローを介してAIを組み込みます。一般に、システムの刷新とAI導入を同時に進めると影響範囲が広がり、効果の検証も難しくなります。
AIエージェントを業務で使う場合、誤った回答や操作を完全になくすことは一般に困難です。そこでバイナリテックジャパンは、次の仕組みを設計の段階から組み込みます。
RELATED
A社は従業員約15名のテクノロジー系スタートアップで、ご相談の窓口は営業部門でした。マーケティングまで手が回る人員がいないため、チームの業務を自動化して人員とコストの負担を減らしたいという要望でした。バイナリテックジャパンは、営業リストの調査からメール文案の作成、人による承認、送信、返信の確認までをつなぐマルチエージェントシステムを構築しました。本案件の実施期間は2か月で、現在は実際にメールを送信する本番運用に入っています。成果を示す数値はまだ出ておらず、人員やコストの負担がどの程度減ったかは現時点では示せる段階にありません。
システムは企業情報を分析して適合度を採点し、その企業に合う事例を紹介する敬語のメール文案を作成したうえで、AIによるチェックと人の承認を経て送信し、返信の確認とフォローアップまで行います。通常の流れで人が必ず関わるのは、送信前のメールの承認と、商談で顧客に会い成約につなげる場面です。このほか、3回書き直してもCritic Gateを通過しない文案と、慎重な対応を要する返信は、担当者に引き継ぎます。メールには特定電子メール法に沿って送信者情報と配信停止の案内を記載し、連絡しない企業のリストも管理しています。また個人情報保護法を踏まえ、保存するのは企業単位の情報に限り、送信先の担当者個人の情報は保存していません。
LangGraphで構築した処理の流れは18のノードからなり、LLMを呼び出すのはそのうち約5ノードで、残りは決まった処理を行うロジックです。次にどのノードへ進むかはLLMに選ばせず、採点結果や状態に応じてコードで分岐させ、順に進む状態遷移の形にしました。こうするとテストがしやすく、結果も安定するためです。一般に、LLMに次の処理を選ばせる設計は柔軟な反面、同じ入力でも経路が変わることがあり、動作の検証が難しくなります。
LLMは作業ごとに使い分けています。分類やチェックには軽量なモデル、企業情報の分析と敬語の採点には中位のモデル、メール文案の作成には最上位のモデルを割り当てました。一般に、すべての処理に最上位のモデルを使うとコストがかさみ、軽量なモデルだけでは文章の品質が不足しやすくなります。作業ごとにモデルを分けたのは、品質とコストの釣り合いをとるためです。
さらに、LLMと外部ツールにはすべて代替手段を用意し、接続できないときはルールやテンプレートで処理を続けるようにしました。そのため、代替手段を用意した部分では、障害時も処理を続けられる設計です。また、企業の識別には社名ではなく法人番号を使い、同じ企業への重複送信を防いでいます。一般に社名は表記ゆれが起きやすく、同じ企業を別の企業として扱ってしまうおそれがあるためです。
人の承認の前には、2段階のCritic Gateを置いています。1段目はコードによるチェックで、メール内のパーセント表記の数値が承認済みの数値一覧と一致するか、「必ず」「絶対」「保証します」といった断定表現が含まれていないかを確かめます。2段目はLLMによる敬語の採点で、0〜100点のうち70点未満の文案を差し止めます。差し止められた文案は自動で書き直されますが、AIが書いてAIが止める往復は際限なく続く可能性があるため、書き直しは最大3回までとし、3回書き直しても通過しない場合は人に引き継ぎます。
Critic Gateを通った文案は送信の手前で処理が止まり、担当者がダッシュボード上で承認（Approve）、修正（Edit）、却下（Reject）を選びます。却下時にメモを残すと、AIがその内容に沿って書き直します。運用の初期段階では自動送信を有効にせず、すべてのメールを人が確認しています。送信後に届いた返信に価格の質問や反対意見など慎重な対応を要する内容があれば、AIでは対応せず、常に人に引き継ぎます。
運用面では、各ステップの状態を保存し、送信ログには重複送信を防ぐキーを持たせ、ステップごとにトークン数、応答時間、コストを記録しています。コストについては1日と1年の予算上限を設け、上限に達すると自動処理を一時停止して警告を出します。あわせて、1回の実行で送るメールは最大50通に制限しています。
構成要素は、LangGraphのほか、バックエンドのFastAPI、進捗確認と承認用ダッシュボードのNext.js、グラフの状態保存と事例検索のRAGに使うPostgreSQLとpgvector、Web情報の収集や法人情報の照会を行うMCPサーバー、メール送受信のSMTP/IMAPです。一方で、外部ツールを呼び出すたびに接続し直す作りのため、一括実行では時間がかかるという課題が分かっています。この点は次の段階で最適化する予定です。
PoCの進め方については、次のソリューションページもあわせてご覧ください。
FAQ
一般に、入力したデータの扱いはLLMの提供元やプランごとの利用規約によって異なります。バイナリテックジャパンでは、提供元・プランごとの利用規約に基づいて、お客様のデータを学習に使わない契約条件のプランを選んで利用します。LLMのサービスは、お客様が利用しているクラウド環境に合わせて、クラウドのLLMサービスや企業向けAPIなどから選びます。データの保存場所も、お客様の環境に合わせて決めます。
PoCは範囲に応じた固定価格、本番開発は対象業務の数や連携するシステムの数といった範囲に応じた見積り、運用・改善は月額固定です。料金表は公開しておらず、範囲に応じて個別にお見積りします。最初のご相談の際に、想定される範囲と費用の目安をご説明します。
連携できます。CSVファイルによる連携、データベースからの直接読み取り、画面操作の自動化（RPA）といった方法があり、どれが適しているかはシステムごとに検討します。
ソースコードの所有権はお客様にあり、リポジトリの形でお渡しします。