Engineered Intelligence for the Real World

どのデータを残し、どのデータを捨てるのか。文書に書かれた手順ではなく、実際のワークフローはどう回っているのか。そしてそのうち、どこまでをAIに任せ、どこからを人が判断するのか。この三つに答えないまま始めた導入は、たいていPoCで止まります。技術が足りないからではなく、何を自動化するのかが定義されていないからです。

モデルは毎月良くなり、デモはいつもうまくいきます。しかしそれが、保険会社の査定部門や診断企業の検査室で実際の効率につながるのは、まったく別の種類の仕事です。数十のシステムに閉じ込められたデータを取り出し、部署ごとに異なる規則と例外を流れの中に収め、間違ってはならない地点で間違えないようにしなければなりません。

企業全体のオントロジーをまず立てようという進め方は、完成までに長い時間がかかり、現場が変わった瞬間から古びはじめます。

一つのフォルダにも、部署・職級・プロジェクトごとに異なる権限が重なっており、その例外は文書ではなく担当者の頭の中にあります。エージェントがこの構造を知らないまま文書を読めば、その瞬間に権限の境界は崩れます。

データが古かったのかもしれず、検索が見当違いの資料を持ってきたのかもしれず、組み合わせの過程でずれたのかもしれず、モデルが思い違いをしたのかもしれません。どこでずれたのかが分からないシステムは、どれほど精度が高くても中核業務には使われません。多くの企業がPoCから先へ進めない理由が、ここにあります。

企業全体のオントロジーを先に立てるのではなく、CTはNoraの上で原本段階のデータを前処理し、各エージェントがどのデータを根拠に使うのかを明示的にバインドし、複数のエージェントが役割を分けて実際の業務の流れをそのままなぞるようにします。一度整えたデータはすべてのエージェントが共有して使うため、エージェントを一つ増やすたびにデータを加工し直すことは起こりません。

標本検査は、抜き取られなかった回答については何も教えてくれません。ところが実際に問題になるのは稀にしか現れない例外であり、標本はまさにその稀なものを取りこぼします。一件あたりの検知精度がどれほど高くても、見たものが一部であれば、残りは調べられていないままです。

CTのハルシネーション検知モデルは一件あたり92%の水準でハルシネーションを捉え、それを行き交うすべての回答に適用します。一部だけを抜き取る方式と比べると、実際に捕捉される量は最大で50倍まで開きます。これが可能なのは、検証を担うのがNoraの検証層にある27B規模の自社モデルであり、同じ検査をフロンティアモデルで回す場合より63倍安く済むからです。

エージェントが実行すればハルシネーションを検知し、検知されたものを評価し、企業が承認したものだけが改善へ進みます。多くの企業でこれらの段階は、別々の道具、別々の担当者、別々のプロジェクトに散らばっています。CTはこれをNoraの中で一つのループに束ね、承認された改善が人の手を介さず次の実行へ反映されるようにします。品質を上げるために別のプロジェクトを立てる必要がない理由です。

誤った判断が見つかれば、原本データから前処理、検索、組み合わせ、回答に至る全経路をたどって、どの段階でずれたのかを突き止めます。その原因は人の手を介さずデータと設定に反映されるため、同じ種類の誤りが何か月も繰り返されることは、この構造では起きません。

ループが一周するたびに、整えられたデータと検証されたワークフロー、エージェントの行動記録が積み上がります。運用が長くなるほどシステムは自社の状況によく合うようになり、積み上がったものは少しずつ企業の資産になります。どのモデル供給元にも縛られず、望むなら、そのデータで自社独自のモデルにまで進むこともできます。

CTのエンジニアが現場で直接デプロイし、データとエージェントを安全に運用できる強固な基盤を整えます。

数十万件の文書を扱う保険会社や診断企業、病院や臨床センターで、CTはすでにこのように働いています。簡単な業務を先に自動化し、難しい業務を後回しにするのではなく、実際にボトルネックがある場所から始めます。

CTは汎用の大規模モデルを自ら開発することはしません。代わりに、CTのシステムが正しく機能するために不可欠な二つの役割に絞った独自モデルを開発します。一つは回答が信頼に足るかを判定するモデル、もう一つは企業の業務に合わせてコストを下げるモデルです。いずれもCTの強化学習の手法で学習され、運用データが蓄積されるほど共に良くなるよう設計されています。

1. ハルシネーション検知およびシミュレーションモデル

エージェントが出した回答が根拠と合っているか、どこで食い違ったか を判定し、新しいエージェントやデータの変更を実際の展開前に シミュレーションで検証するモデルです。Qwen を基盤に、正誤を検証 可能な信号として学習させる RLVR（検証可能な報酬に基づく強化学習） の方式で開発しています。人の主観的な評価ではなく「根拠と一致 するか」という確認可能な基準で学習するため、業界規程や社内文書の ように正解が明確な領域で判定の精度が高くなります。このモデルが、 CTの自己改善ループにおいて「何が誤っていたか」を見つけ出す目の 役割を果たします。

このモデルは約27B規模で、最新の Opus モデルの92%の水準でハルシネーションを捉えます。モデルが小さいぶん、呼び出しコストは63分の1です。だからこそ、一部を標本として抜き取るのではなく、やり取りされるすべての応答を全数検査できます。

（比較チャートは近日公開予定）

2. コスト最適化に特化したモデル

企業内で実際にやり取りされるAIの質問と応答のデータを収集し、 頻繁に繰り返される業務類型に合わせた小型の特化モデルを強化学習で 開発します。単純で反復的な要求はこのモデルが処理し、難しい要求や 重要な要求だけを外部の高性能モデルに送るため、全体のトークン費用 が大きく下がります。企業が使うほどデータが蓄積され、その分だけ 特化モデルがより多くの要求を担うようになるため、コストは時間が 経つほど下がっていく構造です。このモデルはCTの自己改善ループに おいて「見つけた改善をコストとして還元する」役割を果たします。

3. シミュレーションモデル（Beta）— どう直すかを試し、選びます

問題が見つかったとき、直し方は一つではありません。データを整理し直すことも、検索の方式を変えることも、プロンプトやモデルを入れ替えることもできます。シミュレーションモデルは、それらの候補を実際の展開前に走らせ、性能とコストを併せて見ながら最も有望な候補群に絞り込むことを目指します。現在はベータ段階で、一部のお客様環境で試験中です。この段階ではエンジニアがCTの記録と評価結果を見て判断し、シミュレーションモデルはその判断を助ける補助的な道具として先に組み込まれています。ループの中でこのモデルが定着すれば、人は候補の中から最終的に選ぶことだけに関わるようになります。

エージェントをうまくつくり、良くなり続けさせるには、データ準備、モデル呼び出し、記憶と検索、外部システム連携、安全装置、運用記録と評価のすべてが必要です。これまで市場は、その一つひとつを個別に売る道具で埋めてきました。大きく五つの類型があります。

モデル供給元です。 OpenAI、Anthropic、DeepSeek といった各社が高性能なモデルを提供 します。ただしこれらが売っているのは「頭脳」であって、自社データ をつないだり、回答の根拠を管理したりしてくれるわけではありません。 供給元一社に依存すれば、価格や方針の変更にもそのままさらされます。

エージェント開発フレームワークです。 LangChain や LlamaIndex のような開発ツールを使えば、検索・記憶・ツール呼び出しをコードで組み立てられます。柔軟ではあるものの、結局は開発者が自ら書く必要があり、つくった後の運用中に何が問題なのかを見る機能は別途つけ足さねばなりません。

ノーコードのエージェントビルダーです。 Dify や Flowise のような画面ベースの道具を使えば、開発者がいなくても簡単なエージェントをつくれます。始めるのは容易ですが、自社データを整えて最新に保つパイプラインや、複数のモデルをコスト基準で選び分ける機能は弱いのが実情です。

データ・検索インフラです。 ベクトルDB（Pinecone、Weaviate など）とデータパイプラインの道具 が、資料の保存と検索を担ってくれます。しかしこれらの道具は 「どの回答がどの資料を使ったか」までは把握せず、資料が古く なったときにエージェント側へ知らせてくれることもありません。

運用・評価の道具です。 LangSmith、Langfuse、Arize のような道具が呼び出しの記録を残し、回答の品質を評価します。問題を見つけるには有用ですが、見つけた問題をデータや設定へ反映する作業は、結局また人がやることになります。

それぞれの道具は自分の役割をよく果たします。問題は、その間をつなぐ仕事がすべて企業側に残るという点です。たいてい次のようなことが起こります。

五つの道具をつなぎ合わせるのに開発期間と人員がかかり、つなぎ合わせた後は、その接続を維持すること自体が仕事になります。

回答が誤っていたとき、原因がデータなのか、検索なのか、モデルなのか、プロンプトなのかを道具ごとに別々に確認せねばならず、原資料までたどり直す経路は途切れています。

評価の道具が問題を見つけても、それをデータの再整備やモデルの入れ替えにつなげるのはエンジニアの手作業であるため、改善はしばしば止まります。

エージェントごとにデータ準備を別々に行うため、同じ資料を何度も加工することになり、個人情報の基準が変われば複数の箇所を直さねばなりません。

結局のところ「つくること」と「良くしていくこと」が、別の道具、 別の人、別のプロジェクトに分かれていました。CTは、この二つを 一つのシステム、一つのループに束ねるところから出発します。

CTでは、以下のポジションで共に働く方を探しています。AIが間違ってはならない産業で、つくることと運用することを一つに束ねるシステムを共につくっていく方です。

1. TEM (Technical Engagement Manager) お客様のAIシステムの展開と運用を統括する役割です。現場の要求を技術の言葉に翻訳し、導入後の安定した運用と改善の方向をお客様と共に設計します。

2. Operation Manager 会社が急速に成長する間も、組織とプロセスが揺らがないようにする役割です。採用、財務、契約、社内運営を体系化します。

3. MTS (Member of Technical Staff, Engineer) CTシステムの中核をつくるエンジニアです。データパイプライン、エージェントランタイム、観測・評価の階層まで、システム全域にわたって設計し実装します。

ご関心のある方は cx@conscience.technologyまでご連絡ください。

• —すでに業界内で安定した売上パイプラインを持つ企業に適しています。
• —非常に複雑なドメインに対する集中的なコンサルティング。代表およびCレベルが直接行います。
• —2026年基準で年間5社以内に限って進め、圧倒的な集中度と正確性の確保を目的に働きます。
• —構築費は最低1億ウォン以上、年間ライセンスは5,000万ウォン以上で、KPIにもとづき成功を保証して働きます。
• —トークン費または保守契約は、別途の取り決めが必要になる場合があります。

AIは以前からありましたが、産業へ適用することはいまだ初期です。その責任とリスクを分かち合いながら働きます。

• —構築費、トークン費または保守契約は、別途の取り決めが必要になる場合があります。
• —ライセンス費をなくし、責任あるソフトウェアとAIの部分をCTが全面的に運営します。
• —一例として、コマース企業とJVを設立し、一部の品目をCTの自動化システムと協力会社の専門人材で完全に引き受けます。

• —私たちはRondoをつくっています。前の二つの契約で繰り返し現れる顧客のニーズをもとにしています。
• —コマースとブランドに最適化された、リファレンスにもとづく自動ショートフォーム・画像生成プロダクトです。