Reliability AI、
企業のAIを精密につくり、
運用まで安全に引き受けます

Why CT

CTは、企業の複雑な業務をAI-nativeなソフトウェアへと転換し、構築から運用までを自動化します。

これまでのソフトウェア構築は、コンサルティング、要件分析、開発、コミュニケーション、保守まで、その大半を人の作業に頼ってきました。CTはこの過程を、AIエージェントを中心とした開発・運用のシステムへと置き換えます。AIが技術コンサルティングと要件、コミュニケーションの記録を理解し、みずからコードを書き、直し、エンジニアがその結果をレビューし評価します。変わるのは開発の速さだけではありません。より少ない費用でより速く構築でき、運用のなかで品質を上げつづけられます。

とりわけAIシステムは、つくることよりも安定して運用することのほうが難しいものです。モデルのハルシネーションや誤り、予期しない判断を統制しなければならないからです。CTは独自のAI Reliability Layerを通じて、AIのあらゆる実行と判断の根拠を追跡し、評価します。問題が起きれば、なぜそう判断したのかを分析し、その結果をふたたびシステムのコードとロジックの改善へとつなげます。

この過程がCT独自のプラットフォーム Nora↗の上で繰り返されるため、CTはソフトウェアだけでなく、AIの導入と運用 までを継続的に自動化できます。だからこそ、バイオ・医療、保険・金融、 公共、Eコマースのように、正確性、追跡可能性、監査が重要な産業で とりわけ強みを発揮します。モデルやデータが変わっても実行の過程を 追跡し検証できるため、企業はAIを実験のレベルにとどめず、実際の 中核業務へ安定して適用できます。

企業が得られる実益

1. AIの利用料を安全に統制でき、価格を下げられます。 CTは複数のAI供給元（OpenAI、DeepSeek、Kimi、Together AI など）を状況に応じて使い分けるため、簡単な作業は安価なモデルへ、重要な作業は高性能なモデルへと自動的に振り分けます。特定の供給元一社に縛られないので、価格が上がっても障害が起きても対応できます。さらに、頻繁に繰り返される業務はCTの小型特化モデルが引き受けるため、使うほど単価が下がっていきます。

2. AIの回答と根拠データを体系的に管理できます。 どの資料をいつ取り込み、どう整理し、どの回答に使われたかが、原本の段階から記録として残ります。回答が誤っていたとき、原因がデータなのか、検索なのか、モデルなのかをたどり直すことができ、監査が求められる業界でも根拠をそのまま提示できます。

3. エージェントを非常に速くつくれます。 データ連携、記憶、検索、外部システム連携、安全装置がすでに用意されているため、現場のチームは「このエージェントが何をすべきか」を決めるだけで済みます。しかも一度整えたデータはすべてのエージェントが共有して使うので、エージェントごとに資料を加工し直す重複作業がなくなります。

4. 運用するほど、ソフトウェアとAIが少しずつ良くなっていきます。 従業員が回答を修正したり低く評価したりした事例が、自動的に次の改善の材料になります。そのため、品質改善のための別プロジェクトを立てなくても、システムは自社の状況に少しずつ合っていきます。改善要望や障害についても、AIエージェントがまず解決案を出し、エンジニアが承認する形なので、運用が止まりません。

本質的には、エージェントのあらゆる行動データを確保するため、将来的に企業がエージェントやモデルを自社資産化するうえで圧倒的に有利になります。つまり、どのような形であれ確保したデータによって、より賢く、あるいはより安価に、自社独自のモデルとシステムを備えられるようになります。

この四つが一度きりの納品で終わらないのは、構造によるものです。実際の業務から出た利用記録とフィードバックは、評価・追跡・検知・検証・記憶・改善がひとつながりで回る信頼性の層に集まります。そこから生まれた改善は、ふたたび企業のAI転換へ、繰り返し検証された業務からつくった製品へ、そしてその下を支えるプラットフォームへと戻っていきます。運用が積み上がるほど、次の導入が速く、安くなる理由です。

Technology

多くの企業は今なお、特定のAIモデルや個別ソリューションの性能だけに依存するという構造的な限界を抱えています。CTは特定のモデルに縛られず、より広い範囲を、より安全なやり方でカバーします。AIモデルをシステム階層で統制・管理することで、より信頼できるものにします。

CTは、企業がAIエージェントをつくり運用するために必要な土台を、 すべて一つにして提供します。社内に散らばった文書、システム、 データをCT一か所につないでおけば、AIエージェントがそのデータを 根拠に答え、業務を処理します。回答ごとに「どの原資料を根拠に したか」が併せて残るため、もっともらしいが誤った答え （ハルシネーション）が生じる余地を構造的に減らします。

もう一つの特徴は、つくることと運用することがつながっている点です。エージェントを使う中で蓄積される記録と評価が自動的に次の改善へ反映されるため、一度つくって放置されるのではなく、使うほど自社の業務によく合うように磨かれていきます。

CT独自のモデルCT's Own Models

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

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

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

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

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

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

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

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

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

既存市場のアプローチExisting System Players

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

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

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

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

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

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

既存の構造が残す問題Problem

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

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

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

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

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

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

Mission

現実の産業で動く知能をつくります。

ソフトウェアの実行力とAIの知能を結び、実際の業務をこなし、運用され、改善しつづけるシステムをつくります。

Our Story

CTはハルシネーションを捉える会社として始まりました。金融、法律、 医療のように、AIが一度間違えればそのまま損失や責任問題につながる 産業において、「AIの回答の中から誤りを見つけ出す技術」があれば、 導入における最後の壁を越えられると信じていました。

そこで当時の市場のやり方に倣いました。すでにできあがったエージェントの回答を受け取り、根拠と照合し、モデルで再検証し、誤りを示す。そうした検知技術に注力しました。技術そのものは進歩し、検知率も上がりました。

ところが現場では、三つの壁にぶつかりました。

間違っていることはわかっても、なぜ間違ったのかがわかりませんでした。 回答だけを見ても、原因が古い文書なのか、切り方を誤った資料なのか、検索が見当違いのものを拾ってきたのか、モデルの誤りなのかを区別できませんでした。元データから回答までの経路がシステムのあちこちに散らばっていて、たどり直す道がなかったからです。

見つけた問題が改善につながりませんでした。 検知結果を渡しても、データを直し、設定を変え、再び評価する作業はお客様側のエンジニアの仕事でした。そのエンジニアたちはすでに多忙で、結果として同じ種類のハルシネーションが何か月も繰り返されるのを見守ることになりました。

検知はいつも後手に回りました。 ハルシネーションは回答ができあがった後に捉えるものではなく、データが用意され、検索され、組み合わされる過程ですでに決まっていました。最終段階でどれだけ精緻に濾しても、上流で生まれる問題の速さには追いつけませんでした。

ここで私たちは方向を変えました。ハルシネーションは「検知」の問題では なく、システム全体の問題でした。元データから回答までが一本につながって いてはじめて原因を突き止められ、突き止めた原因が人の手を介さずに データと設定へ反映されてはじめて改善が止まりません。そこでCTは、 検知ツールではなく、エージェントをつくり運用する全工程を一つに束ね、 自ら改善されていくシステムをつくることにしました。

ハルシネーション検知から始まった会社が、結局システム階層の全体をつくることになった理由は一つです。ハルシネーションを本当に減らすには、それが生まれる場所の全体を扱わなければならないと、現場で学んだからです。

Team

私たちは、幅広い研究と速い製品化を志向する組織です。

Kris（ユ・スンヒョン）· 代表 高麗大学校 統計学修士。大学2年で最初の起業をし、CTは3社目。本質的で深い研究を通じて製品をつくることを好みます。

Paul（キム・ドングァン）· 共同創業者、リサーチエンジニア 数学が好きで祥山高校に進学し、高校2年からコーディングとコンピュータに没頭しました。CSとメディアを融合した技術と研究に取り組み、現在はAIのハルシネーション検知の研究に打ち込んでいます。

Dia（ナ・ヒヨン）· 共同創業者 17歳で最初の起業をし、2社目からKrisと共に歩んでいます。フロンティア領域の製品と技術に対する優れた企画力を備えています。

そのほかにも、イ・ハクジュン、ヤン・ヘソク、キム・ハンウル、ペ・ジュヒャンなど、大規模プロジェクトの遂行経験と多様な研究歴を持つメンバーが集まっています。ソウル大学校、高麗大学校、建国大学校の出身者が在籍しています。

How we work

構築は成果物で契約します。

人月（M/M）ではなく、つくられるシステムとその範囲を基準に見積もります。プロトタイプの段階で範囲と金額を確定し、それ以降に追加費用が発生することはありません。規模に応じて数千万ウォンから数億ウォン、期間は2〜6か月です。

運用は月額サブスクリプションです。

観測・修正・検証・改善提案を含む月額定額で、システムの規模とAI機能の範囲に応じて決まります。人員の常駐ではないため、担当者の交代や人件費の変動に関係なく、同じサービスが同じ金額で維持されます。

小さく始められます。

最初のプロジェクトは2週間のプロトタイプから始めます。プロトタイプの後に進めるかどうかを判断していただけますし、進めない場合でもプロトタイプはお渡しします。

Contact

プロジェクトのご相談や協業のご提案をお寄せください。営業日2日以内にご返信いたします。

メールをご希望の場合は cx@conscience.technology