チャットの賢さでは決まらない生成AI選定｜接続階層という軸

全社で生成AIを使えるようにしたい。そう考えて稟議書を書きはじめた担当者が、最初につまずく場所があります。

経営層から返ってくる質問です。「それで、うちの生産管理の数字は見られるのか」。

ここで答えに詰まります。担当者が試しに使ったチャットは、たしかに文章をうまくまとめてくれます。ただ、それが社内のデータを見に行けるのかどうかは、使っているだけでは分かりません。持ち帰って比較記事を何本か読んでも、文章が得意なのはこれ、表計算に強いのはこれ、検索と相性がいいのはこれ、と並ぶだけです。どれも間違ってはいないのですが、聞かれた質問には答えていません。

理由は単純です。世に出回っている比較記事の多くは「何が上手か」という軸で作られています。経営層が聞いたのは「どこまで届くか」であって、上手さではありません。軸が違うので、いくら読んでも答えが出てこないのです。

この記事では、その軸を差し替えます。生成AIのサービスを、賢さではなく接続階層——社内システムのどこまで手が届くか——で並べ直します。

生成AIを分ける三つの接続階層

社内のどこまで届くかという軸

接続階層とは、そのサービスがどこまでデータを取りに行けるかの範囲を指します。三段に分かれます。

この三段で分けると、質問に答えられるようになります。「生産管理の数字が見られるか」は階層③の話です。階層①のサービスをいくら比べても、そこには到達しません。上手さの比較が役に立たなかったのは、比べている土俵が階層①の中だけだったからです。

もうひとつ、この軸には実務上の利点があります。階層が上がるほど、確認すべき項目がはっきり増えます。階層①なら、社内のデータを貼らない運用ルールを決めれば足ります。階層③まで行くなら、誰が何を見られるかの権限設計と、誰が何をしたかの記録が要ります。必要な準備の量が、階層の高さでおおよそ決まるということです。

階層が上がるほど、できることは増え、同時に確かめるべきことも増えます。

会議の要約が階層の内側で完結する理由

自社が今どこにいるかは、普段やっている作業から逆算できます。分かりやすいのが会議の要約です。

会議のメモをチャットの画面に貼り付けて、決定事項と次にやることを整理させる。この使い方は珍しくありません。そしてこの作業は、階層①だけで完結しています。貼り付けた文章がすべての材料であって、サービスは社内のどこにも取りに行っていません。

会議の要約が階層①で足りるのは、材料が全部その場に貼られているからです。ここに「先月の不良率と比べて」を足そうとした瞬間、材料は社内にある数字になり、階層②か③の話に変わります。同じ会議の要約でも、どこまでを材料にするかで必要な階層が動きます。

なお、貼り付けたメモを決まった形に整える処理も、階層①の中で完結します。論点・根拠・決定事項・次のアクションといった枠をあらかじめ決めておき、発言をその枠に振り分け、埋まっていない枠を指摘する。ここまでは材料が貼り付けた文章の中に閉じているため、社内システムへの接続を必要としません。階層①は狭いだけの場所ではなく、そこで完結する仕事もあるということです。

自社の現在地が階層①だと分かれば、次に見るのは「では、それぞれのサービスはどこまで行けるのか」です。

主要サービスの到達範囲

接続階層で並べ直した四つのサービス

企業でよく候補に挙がる四つを、先ほどの三段で並べ直します。エージェントの性能評価は入れていません。それぞれの階層に、どういう手段で届くのかという事実だけを置いています。

なお、この領域は動きが速いところです。表の内容は2026年8月時点のもので、検討にあたっては各社の公式ドキュメントで最新の状態を確認してください。

サービス	階層① 外部だけ	階層② 許可した外部	階層③ 社内ネットワーク
ChatGPT（OpenAI）	標準で対応	コネクタで各クラウドサービスへ接続	Secure MCP Tunnel。社内側からの外向き通信だけで成立し、ポートの開放は不要
Claude（Anthropic）	標準で対応	通信先を許可した範囲に絞る設定あり	MCPトンネル（リサーチプレビュー）と、実行環境を自社側に置く自己ホスト型サンドボックス（パブリックベータ）。2026年5月19日提供開始
Gemini Enterprise（Google）	標準で対応	コネクタと認証基盤の連携	Private Service Connect で、自社が管理するデータソースへ接続。公共のインターネットを経由しない
Microsoft 365 Copilot＋Copilot Studio	標準で対応	Power Platform のコネクタ群	オンプレミスデータゲートウェイを社内に置き、社内サーバーのデータベースと連携

• 出典：New in Claude Managed Agents: self-hosted sandboxes and MCP tunnels（Anthropic・2026年8月11日確認）
• 出典：Secure MCP Tunnel（OpenAI 公式ドキュメント・2026年8月11日確認）

表を横に読むと、どのサービスも三段すべてに何らかの手段を持っていることが分かります。つまり「このサービスだから社内システムに届かない」という時代ではなくなりました。

差がつくのは三段目だけ

表を縦に読むと、別のことが見えます。階層①と階層②は、四つとも実質的に横並びです。貼り付けた文章を扱う力も、クラウドサービスにつなぐ仕組みも、どこも一通り揃えています。ここで差をつけようとすると、上手さの比較にしかならないのです。世に出回る比較記事が用途別の使い分けに落ち着くのは、階層①と②の中だけで比べているからです。

サービス選定で実際に差がつくのは、階層③をどう実現するかという一点です。

そしてその階層③の手段は、ここへ来て各社から出そろいました。Anthropicは2026年5月19日に、OpenAIも自社の公式ドキュメントで、社内に置いたサーバーへ外向きの通信だけで届く仕組みを公開しています。いずれも共通しているのは、ファイアウォールに受け入れ口を作らなくてよいという設計です。社内から外へ出ていく通信だけで成立するため、ネットワークの構成を変えずに済みます。

ただし、横並びに見えて決定的に違う点があります。提供の状態です。

Anthropicのトンネルはリサーチプレビュー、実行環境を自社側に置く仕組みはパブリックベータです。一方、Microsoftのオンプレミスデータゲートウェイは古くからある仕組みです。生成AIが登場するよりずっと前からPower Platformで使われてきました。同じ「社内につながる」でも、業務に載せてよい段階かどうかが違います。

ここまでで、サービス側の到達範囲は分かりました。次は自社の側です。自社の環境が三段のどこにいるのかを、順に確かめます。

自社の到達範囲を確かめる三つの確認

サービス側の到達範囲が分かっても、自社の側が受け入れられるかは別の話です。ここからは、自社の環境で確かめる項目を三つに絞ります。この三つに答えられれば、冒頭の質問には答えられます。いずれも自分で調べる必要はなく、聞く相手が決まっています。

基幹システムにデータの出口があるか

階層③の可否は、ほぼこの一点で決まります。生産管理や販売管理のシステムに、外部のプログラムからデータを読み出す口があるかどうかです。技術の言葉ではAPIと呼びますが、意味は「決まった手順で問い合わせれば、決まった形でデータが返ってくる窓口」です。

聞く相手は、そのシステムを入れたベンダーか保守会社です。聞き方は次の一文で足ります。「このシステムから、外部のプログラムでデータを読み出す仕組みはありますか。あれば仕様書をいただけますか」。

答えは大きく三つに分かれます。仕様書が出てくれば階層③の検討に進めます。「データベースを直接見てもらう形なら可能」という答えも、条件つきで進めます。「対応していません」なら、そのシステムに関する限り階層③はいったん諦めるのが早道です。画面を人が操作する前提で作られたシステムを外から動かす方法もありますが、費用も手間も別次元になります。

データが自社の契約範囲から出るか

二つ目は、扱うデータがどこまで出ていくかです。ここが決まらないと、社内の承認は先へ進みません。

すでにMicrosoft 365やGoogle Workspaceを全社で使っているなら、その契約の中で完結する構成が最も話が早く進みます。データの置き場所も、誰がアクセスできるかの管理も、いま情報システムの担当者が見ている範囲から動きません。新しく承認を取り直す範囲が小さいほど、稟議は通りやすくなります。

別のサービスを使う場合は、契約書と設定画面の二か所を見ます。入力した内容が学習に使われない設定になっているか、データがどの国に保存されるか、この二つです。聞く相手は、そのサービスの営業担当か、導入を支援する会社です。

誰が何をしたかの記録が残るか

三つ目は見落とされやすい項目です。社内システムにつなぐということは、そのAIが社内データへの通り道を持つということです。通り道ができれば、どこまで通ってよいかを決める必要が生まれます。つなぐ仕組みを用意すること自体は難しくありません。難しいのは何をつなぐか、どこまで見せるか、どう記録するかを決めることです。

決めるべきことは三つに整理できます。誰がその仕組みを使えるのか。どの範囲のデータまで取りに行けるのか。そして、いつ誰が何を取り出したかが後から追えるのか。三つ目の記録があるかどうかが、事故が起きたときに原因を特定できるかを分けます。

聞く相手は、サービスの提供元です。「操作の履歴を管理者が確認できますか。書き出せますか」と聞けば足ります。

三つの確認は、上から順に当てます。一つ目で止まれば、二つ目と三つ目を調べる必要はありません。

三つの答えが出たところで、最後に残る問いがあります。そもそも自社に階層③が要るのか、という問いです。

階層を上げるべき場合と、上げなくてよい場合

転記の回数で決まる必要階層

階層③が要るかどうかは、企業の規模では決まりません。判断の材料は、もっと具体的なところにあります。同じ数字を、人が手で運んでいる回数です。

基幹システムの画面を開いて数字を見て、それをExcelに打ち直す。その作業が毎日発生しているなら、階層③に上げる価値があります。逆に、月に数回しか起きないのであれば、準備の重さに見合いません。階層③には準備が伴います。つなぐ相手の仕様を調べ、権限を設計し、記録の残し方を決める作業です。その手間を回収できるだけの回数があるかが分かれ目です。

ここで大事なのは、上げないという答えも正解になることです。統計では、中小企業のAI導入率は20.4パーセント、製造業に限ると16.4パーセントにとどまります。裏を返せば、階層①の範囲でできることすら、まだ着手されていない会社が大半だということです。階層③に進まなくても、伸ばせる余地は手前に残っています。

出典：中小企業のAI等の利活用に係る実態調査（報告書）（独立行政法人中小企業基盤整備機構・2026年8月11日確認）

転記が毎日でないなら、いまは階層①か②で組み立て、階層③は見送るという判断で構いません。

階層を上げる前に押さえる二つの注意

階層③へ進むと決めた場合に、先に知っておいたほうがよいことが二つあります。

一つ目は、提供の状態です。先に見たとおり、社内ネットワークへ届く手段のうち、いくつかはまだ試験段階にあります。とくにリサーチプレビューと書かれているものは、稼働率もサポートも提供の継続も保証されていません。止まったら業務が止まる仕事を、この段階の仕組みに預けないことです。試すのは構いませんが、載せるのは業務の本流から外れたところから始めます。

二つ目は、階層を上げれば成果が出るとは限らないことです。売上500億円以上の企業を対象にした調査では、生成AIの活用・推進度は87パーセントに達しています。一方で、期待を大きく上回る効果を出せたと答えた企業は9パーセントにとどまります。導入まで到達した企業と、効果まで到達した企業の差は大きいのが実態です。

出典：生成AIに関する実態調査2026 春（PwC Japanグループ・2026年8月11日確認）

この差が生まれるのは、つないだ後に何をさせるかが決まっていないからです。階層を上げる作業は手段であって、目的ではありません。どの転記をやめたいのかを先に一つ決めてから、その一つに必要な階層を選ぶ。この順序であれば、つないだのに使われないという結果は避けられます。