バイブコーディングの不確実性を解消する／AI駆動開発ツール「jinba」で世界市場を狙うCarnot（カルノー）

「知の永久機関」をめざすカルノー

──まずはじめに、これまでのご経験と起業に至った経緯についてお聞かせください。

乗杉：大学時代は現CEOの松森（Carnot代表 松森匠哉氏）とともに、脳波データの深層学習解析に取り組んでいました。その後、私はコンサルティング会社のマッキンゼーに入り、6年間さまざまな業界のクライアントと向き合いました。現場で強く感じていたのは、日本企業が自らプロダクトを作れず、どうしてもシステム開発を外部に委託し、結果として法外なコストが発生してしまうという構造的な課題です。本来、現場の人が自分たちで小さなプロダクトや業務フローを作れるようになれば、IT投資の効率は格段に上がり、企業の利益構造も大きく変わるはずだと考えていました。

　そこに生成AIやバイブコーディングといった新たな技術が登場し、自分たちの手で高効率なIT投資が実現できる未来を感じたことが、Carnot創業の原点です。マッキンゼー時代には、システム開発だけでなく「ビジネス上の本質的な課題をどう解決するか」という視点を多様な業界で鍛えられました。この経験が、AIプロダクト開発における課題設定や解決の解像度を高めてくれたと感じています。

──社名に込めた思いと、事業の全体像についてお聞かせください。

乗杉：Carnot（カルノー）という社名は、熱力学における理想的なエネルギー循環「カルノーサイクル」から取りました。"永久機関"のような自己強化の仕組みを、企業に眠る知や経験値の活用サイクルとして実現したい、というのが私たちの出発点です。

　我々が開発した「jinba」シリーズ^[※1]は、そのためのAI駆動開発ツール群です。現場で使えば使うほど現場知が磨かれ、データが蓄積され、企業システムそのものが進化し続ける――そんな自律強化型サイクルを、事業・プロダクトの根本思想としてきました。創業当初から「現場の課題に根ざしたプロダクトを自分たちの手で作る」という姿勢にこだわってきたんです。

　米国発のCursor、Devinのようなプロダクトが世界的に注目され始める以前から、日本発でもグローバルに通用するSaaSを生み出したいという思いで、共同代表の松森匠哉とCarnotを立ち上げました。

──御社が提唱する「永久機関」的なサイクルの仕組みについて、もう少し具体的に教えてください。

乗杉：Carnotが目指すのは、AI開発と現場業務の間にあった分断を解消し、両者が相互に強化し合う循環を作ることです。自然言語によるバイブコーディングによって、直感的にアプリや自動化フローを開発し、それを現場で使い続けてもらう。その過程で利用ログや生成データがどんどん蓄積され、次の開発や最適化の材料となる──こうした循環を通して、AIも現場も共に進化していく。それが我々の考える自己強化サイクルです。

　ただ、そのためには現場から本当に使われ続ける仕組みである必要がありますし、「現場の人がどんどん触れて、気づきや知が自然と集積・循環する」ことが前提になります。プロダクト自体にそういった循環を仕込むこと、そして現場との"手触り感"をいかに保つかが、設計思想の大きなポイントになっています。

[※1] jinba デモページ

AI駆動開発が持つ不確実性の課題をどう超えるか

──生成AI駆動開発における"不確実性"の課題をどう捉えていますか？また、どのように克服しようとしたのでしょうか。

乗杉：実は、エンタープライズITに本格導入する際に最も大きな壁だったのが、「生成AIの確率論的な不確実性」です。生成AIはその性質上、同じ入力でも必ずしも同じ結果を返すとは限りません。クリエイティブな利用では柔軟性や面白さにつながる一方、企業の基幹業務や業務自動化の現場では、結果が毎回異なると業務フローが破綻してしまう。

　エンタープライズITの現場で使うには「決定論的」に、すなわち同じ条件なら必ず同じ結果が返る仕組みでなければ安心して運用できません。

　私たちCarnotでは、この課題を本気で解決しようと考えました。jinbaシリーズでは、プロトタイピングや試行錯誤の段階では生成AIの柔軟性を活かしつつ、最終的にはTypeScriptなどで確定的なロジックや業務フローに落とし込む仕組みを実装しています。これにより、不確実性の高い部分と厳格に管理すべき業務ロジックの双方を両立させることができる。「安心して本番運用できるAI自動化」を、現場の使いやすさと同時に実現しているのが特徴です。

──jinbaシリーズにはどんなプロダクトがあり、それぞれどんな特徴や違いがあるのでしょうか。

乗杉：最初に開発し、パブリックで公開しているのが「jinbaflow」です。これは自然言語でiPaaS（Integration Platform as a Service）を実現するツールで、たとえば「こういうメールが来たとき、この内容をスプレッドシートに書き起こして保存してほしい」といった指示を出すと、裏側で業務ワークフローが自動構築されます。Difyのようなノードやモジュールが可視化されて組み上がっていきますが、jinbaflowでは最終的にTypeScriptのコードとして確定処理されるため、型安全で堅牢な決定論的業務自動化が実現できるのが強みです。現場の担当者やエンジニア志向のユーザーが、直感的に業務プロセスを設計でき、しかも安心して運用できる点にこだわっています。

　もう一つの「jinba.app」は、MCP（Model Context Protocol）を管理・運用するツールです。MCPは、様々なツールやAPIに対して「何をしてほしいか」を自然言語で指示し、そのプロンプト群を柔軟に組み合わせて業務指示として実行できます。例えばFirecrawlというAPIには「この会社群のSDGsレポートを探してきて」、スプレッドシートには「取得した事例をこのシートに記入して」といった具合に、ノーコード・コードレスで業務連携が可能です。MCPの特徴は、インプット・アウトプットを厳密に定義しなくても動くため、現場ユーザーやノンプログラマーにとっても敷居が低い点です。ただしその分、生成AI特有の確率論的な挙動やランダム性が残るという一長一短があります。

　つまりjinbaflowは決定論的なコード世界を、jinba.appはより探索的で柔軟なMCP世界を担う。ユーザーは状況に応じてこの二つの「世界」を行き来できる。両者の強みを使い分けられることこそがjinbaシリーズの本質だと思っています。

　また、現在「jinba Analytics」という新製品の一般公開を準備しています。誰でも自然言語でデータウェアハウスにアクセスし、「この商品の売上トレンドを教えて」といった指示で分析や可視化まで自動化できるツールです。