三層アーキテクチャ：AIによるビジネス判断は「企業にはナレッジグラフが必要だ」で終われない

企業AIに関する提案の多くは、「企業にはナレッジグラフが必要だ、ナレッジベースが必要だ、オントロジーが必要だ」と言ったところで終わってしまう。間違ってはいない。だがそれは概念にすぎず、要件の一面を切り取っただけでもある。顧客は頷いて、こう聞くだろう。「それで、うちの業務では具体的にどう使うのか」。

最近、自分の提案の考え方を整理していて、これは三つの層に分けて捉えないといけないと強く思った。私たちの会社は今、まだ第一層にいる。そして、この話に価値があるかどうかを決めるのは、その下の二層だ。

第一層：概念の層——正しいが、浅すぎる

第一層の主張はこうだ。企業がAIでビジネス判断をしようとするなら、まずナレッジグラフとナレッジベースがあり、オントロジーを構築しなければならない。

これは正しい。企業の業務ロジック、顧客との関係、製品構成、過去のプロジェクトは、もともと一枚の網であって、互いに無関係な表の集まりではない。この網を作らずにいると、AIが手にするのは断片だけになる。

問題は、この層が「何が必要か」にしか答えておらず、「どう使うか」に答えていないことだ。もはや業界のスローガンと言っていい。ネット上で毎日のように見かける。提案がここで止まるなら、私たちが売っているのはコンセプトであって、納品できるものではない。顧客が「正しい一言」にお金を払う理由はない。

第二層：アプリケーションの層——業務ロジックを「判断できる知識」に変える

第二層でやるのは、概念をITアプリケーションの設計に翻訳することだ。この曖昧な需求を抽象化し、企業が具体的にどう適用するのかを答える。

まず一つ目は、企業自身の業務ロジックを抽出し、関連性を持った知識に変えることだ。資料を一つの庫に放り込めば終わり、という話ではない。モノとモノのつながりを明らかにする必要がある。たとえば一件の注文が、どの顧客、どの製品ライン、どの納品工程と結びついているのか。ある遅延が、どの前提条件と結びついているのか。関連性が築けなければ、その先の判断は成り立たない。

二つ目は、人とAIが協働するインターフェースだ。入力には一連のアプリケーションが要る。業務情報を人が入力し、修正し、検証できるようにする。出力にも一連のアプリケーションが要る。抽出と判断の結果を人に見せ、確認や修正をしてもらう。このループは省けない。企業のデータは往々にして汚く、定義も揃っていない。最初から全自動にすると、誤りが増幅されるだけだ。

しかし、人手の入力と人手の判断だけなら、この話には意味がない。人はもともとそれをやっている。AIの価値は、できる限り自動で判断するところにある。

そこで新しい概念が必要になる。AIによる判断だ。判断は当て推量であってはならず、根拠が要る。私が現時点で考えているのは、企業のための判断フレームワークを築くことだ。企業の経営には周期性があり、5つのサイクルに分けられる。各サイクルには6つの能力が必要で、各能力には一組の判断要因が対応する。ある問題が起きたとき、それを「企業自身のデータ＋いまどのサイクルにいるか＋どの能力に関わるか」という座標に置き、判断要因と組み合わせて結論を出す。

このフレームワークが成り立つかどうかは、企業と一緒に検証する必要がある。ただ、一つ確かなことがある。このデータは極めて重要だ。前もって用意するにせよ、企業との協業の中で少しずつ蓄積するにせよ、必要になる。これがなければ、AIの判断はモデルの一般化された推測に頼るしかなく、企業の具体的な状況には降りてこられない。

判断して終わりではない。問題があると判断したら、行動しなければならない。ここでツールの層が出てくる。

ツール層が解くのは、AIが企業の既存システムをどう実際に操作するかという問題だ。方向は二つある。一つは、既存のIT資産や既存ソフトウェアを、AIが呼び出せるツールに変換すること。もう一つは、新しく作るITシステムを最初から「AIが呼び出せる」前提で設計することだ。加えて、ログインや権限といった現実的な問題もある。AIがシステムを動かすには、まずその中に入り込めなければならない。

私は間に一層挟むのがよいと考えている。modernizationと呼んでいる。やり方はこうだ。旧システムは動かさず、業務ロジックも変えない。そのコードとデータベースを使って関連性を抽出し、外側にMCPからアクセスできるサービスを被せる。AIはMCPの記述からそのサービスが何をできるかを知り、skillでいつ使うかを決める。MCPやskillの中にAPIを書いて、旧システムの既存機能を呼ぶか、データベースに直接アクセスして結果を返す。

要するに、旧システムにAIと通信できる殻を被せるということだ。この殻が旧システムを上位の「脳」に接ぎ木し、脳が実行できるツールに変える。これが第二層の中心的な仕事であり、アーキテクチャを設計し、実際に実装まで持っていかなければならない。構想図で止めてはいけない。

第三層：クラウド基盤の層——知性には実行が伴わなければならない

第三層は最下層のシステムアーキテクチャだ。企業のレベルまで上がるなら、クラウドを避けて通れない。クラウドに載せなければ、この仕組みは動かない。

この層で答えるのは、きわめて具体的な問いだ。どのクラウドの、どのサービスにつなぐのか。どの用途に、どの事業者のどのサービスを充てるのか。全体のアーキテクチャをどう設計するのか。

たとえばアプリケーションの場面をまず分ける必要がある。ユーザーとの対話型で、画面と人の参加が要るもの。自律的に実行し、バックグラウンドで走り切って結果を返すもの。この二種類では、計算にもスケジューリングにも求められるものがまったく違う。

データも同じだ。入力はどう入り、どう変換され、どこに保存され、上位からどう呼ばれるのか。Googleに置くのか、別の場所か、それともツールに直接つなぐのか。すべてアーキテクチャの中で決めなければならない。

見落とされがちな点がもう一つある。システムは「賢い」だけでは足りないということだ。知性があっても、実行できてこそ意味がある。そして実行には駆動するものが必要だ。クラウド上でタスクを走らせ、ツールを呼び、失敗と再試行を処理する一連のアプリケーションが要る。この部分のアーキテクチャができていなければ、前の二層の判断がどれだけ美しくても地に足がつかない。

三層がつながって、はじめて製品になる

三層を並べて見ると、論理ははっきりしている。第一層は知識がどんな形をしているかを定義し、第二層は知識を判断でき、実行できるものにし、第三層は判断と実行が本当に動くことを保証する。

第一層だけで終われば、概念をこねているだけだ。ネット上に概念はいくらでもある。誰でも二言三言は語れる。顧客はそれを聞き飽きて、あなたはただ騒いでいるだけだと思うだろう。実装がなければ、信頼は落ちる。

三層が通ってこそ、私たちが差し出せるのは本当の製品であり、提案にも勝算が出る。

第二層を止めてはいけない理由もここにある。それは「正しい言葉」を「使えるもの」に変える区間であり、いちばん難しく、いちばん飛ばされやすい区間なのだ。