前々回、前回とオープンAIの最新のAIモデル「GPT-6 Astra」関連について、以下のようにお伝えしてきました。
アイデアよもやま話 No.6632 オープンAIの最新のAIモデル「GPT-6 Astra」が市販化され、需要急増
アイデアよもやま話 No.6633 「GPT-6 Astra」とSBGが国内展開に取り組んでいるクリスタルインテリジェンスとの関連について
そこで、今回は、SBGのクリスタルインテリジェンスの近況に焦点を当てて、チャットＧＰＴで調べた結果をお伝えします。
添付全般の要約は以下の通りです。
要約のポイントは以下の通りです。
Crystal intelligenceの近況
- Crystal intelligenceは、構想・開発段階から、ソフトバンク社内での実装・検証を経て、日本企業への展開を準備する段階へ進んでいる。
- 2025年にSB OAI Japanが発足し、ソフトバンク自身を最初の利用者「カスタマーゼロ」として実証を進めている。
- 2026年には、OpenAIの企業向けAIプラットフォームFrontierを技術基盤とすることが明確になった。
- 2026年度から日本企業へ順次展開し、本格的な業績寄与は2027年度以降が想定されている。
- GPT-6 Astraなど最新AIの能力を将来活用できる可能性はあるが、Crystal intelligenceがAstraを正式に中核モデルとして採用したことは確認されていない。
OpenAI Frontierとは
- 企業データ・既存業務システム・AIモデル・AIエージェントを接続し、AIを「デジタル労働力」として働かせる企業向け共通基盤。
- 主な役割は、
企業データとの接続 → Business Context構築 → AIエージェント実行 → セキュリティ・権限・評価・管理。
- 既存システムを全面的に作り直すのではなく、API・コネクター・MCPなどを通じて既存資産をAIから利用できるようにすることが重要となる。
既存業務システムとの接続
- COBOL、PL/I、Javaなど、既存プログラムをすべて解析して業務を理解することが基本ではない。
- 既存システムに**APIなどの「AI用受付窓口」**を設け、必要なデータ取得や許可された処理だけをAIエージェントから利用できるようにする。
- APIのない古いレガシーシステムでは、APIやデータ連携・変換層などを新たに構築する必要がある。
- AIによるCOBOLなどのソースコード解析は、既存システムの理解や接続方法の検討を補助する手段として利用できるが、Frontierがあらゆるレガシーシステムを完全に自動解析するわけではない。
データウェアハウス（DWH）
- 営業・会計・在庫・生産・調達などに分散した企業データを集約し、分析・経営判断・AI利用に使えるようにする「企業データの倉庫」。
- 業務データベースが日々の処理を担うのに対し、DWHは複数システムや過去データを横断的に分析するために使う。
Business Contextとは
- 企業のデータが何を意味し、会社の中で仕事がどのように行われているのかをAIが理解・利用するための業務知識。
- データ項目の意味だけでなく、
業務ルール、社内規程、組織、権限、承認関係、業務プロセス、システム機能などを関連付ける。
- 例えば「CUST_ID＝顧客番号」「1,000万円以上の発注＝部長承認」といった意味やルールをAIが利用できるようにする。
- AIが項目名だけから推測するのではなく、データ定義書、メタデータ、データカタログ、API仕様、業務マニュアルなどを使って意味付けすることが重要。
RAGとの関係
- RAG（検索拡張生成）は、AIが必要なときに社内規程やマニュアルなどを検索し、その情報を使って回答・判断する仕組み。
- RAGはBusiness Contextそのものではなく、Business Contextを構築・利用するための技術の一つ。
- 簡単に言えば、
RAG＝「社内資料を調べる能力」
Business Context＝「会社の仕事の意味・ルール・関係を理解して利用する仕組み」。
全体を一つの流れにすると
既存業務システム
COBOL・PL/I・Java・ERPなど
↓
API・コネクター・MCP
既存システムへの「AI用受付窓口」
↓
データウェアハウス等
企業データを集約
↓
Business Context
データ・業務・ルール・組織・権限に意味付け
↓
OpenAI Frontier
企業データ・システム・AIエージェントを接続・管理
↓
Crystal intelligence
日本企業向けに実装・運用
↓
AIエージェント
分析 → 判断 → 提案 → 承認 → 業務実行
一文で総括すると、Crystal intelligenceとは、既存システムをすべて作り直したりプログラムを全面解析したりするのではなく、OpenAI Frontierを基盤として既存のデータ・システム・業務ルールをAIに接続し、日本企業の仕事を理解して実行できるAIエージェントを実装・運用する仕組みであり、現在はソフトバンクでの実装・検証を経て日本企業への順次展開を進める段階にある、と整理できます。
以下は私とチャットＧＰＴとの協力によるコメントです。
上記の要約を更にまとめると、
Crystal intelligenceの近況と仕組み：
- Crystal intelligenceは、OpenAI Frontierを技術基盤として、ソフトバンク社内での実装・検証を経て、日本企業への順次展開を進める段階にある。
- 既存のCOBOL・PL/I・Javaなどのプログラムをすべて解析するのではなく、API・コネクター・MCPなどを介して既存業務システムをAIにつなぐ。
- データウェアハウス（DWH）やCRM、社内アプリなどの企業データ・システムを接続し、Business Contextによってデータの意味、業務ルール、組織、権限、承認関係などをAIが利用できるようにする。
- RAGは、必要な社内規程やマニュアルなどを検索してAIの判断に利用する仕組みであり、Business Contextを支える技術の一つである。
- これによりAIエージェントが、企業の仕事を理解し、分析 → 判断 → 提案 → 必要に応じた人間の承認 → 業務実行まで担うことを目指している。
要するに、Crystal intelligenceとは、既存システムを全面的に作り直したり、既存プログラムをすべて解析したりするのではなく、必要に応じてAPI・コネクター・MCPなどの接続手段を整備し、OpenAI Frontierを基盤として既存のデータ・システム・業務ルールをAIに接続し、日本企業の仕事を理解して実行できるAIエージェントを実装・運用する仕組みなのです。
そして、現在は日本企業への本格展開に向けた段階にあるのです。
それにしても、OpenAI Frontier、そしてCrystal intelligenceの活用により、企業内の既存システムやデータ、業務ルールをAIが利用できるかたちに整理・接続するとともに、業務プロセスそのものをAIエージェントとの協働を前提に再設計しようという取り組みは、まさにAI革命の時代に相応しい企業システムの再構築と言えます。
なお、従来の企業ITは、
人間が業務を行う
→ ITシステムが人間を支援する
という構造でした。
Crystal intelligenceが目指す方向は、
人間が目的・ルールを設定する
↓
AIエージェントがBusiness Contextを理解する
↓
既存システムを利用する
↓
分析・判断・提案・実行する
↓
人間が重要事項を監督・承認する
という構造です。
つまり、これは単なる「生成AI導入」ではなく、企業システムを「人間がシステムを操作する構造」から「人間とAIエージェントが共同で業務を遂行する構造」へ変える取り組みと捉えることができます。
OpenAIも現在、企業AIについて「assistance（支援）」から「execution（実行）」への移行を明確に打ち出しています。
ただし、これはAIへの全面的な業務移管を意味するものではなく、権限管理や人間による監督・承認を組み込みながら、AIエージェントが実際の業務を担う方向への転換といえます。
ということで、Crystal intelligenceを単なる「新しい生成AIサービス」としてではなく、既存の企業IT資産を生かしながら、「人間によるシステム操作を前提とした企業IT」から「人間＋AIエージェントによる業務遂行を前提とした企業IT」へ移行するための仕組みとして捉えることができます。
なお、Crystal intelligenceが本格化すると、企業のシステム設計で重要になるのは、従来のように「人間にとって使いやすい画面を作ること」だけではなく、「AIエージェントにとって利用しやすい機能・データ・権限・業務ルールを整備すること」になります。
つまり、
従来：人間がシステムに合わせて操作する
から、
これから：人間が目的を設定し、AIエージェントが複数のシステムを横断して仕事をする
という変化です。
ですから、これからは人間だけでなくAIエージェントも企業活動の重要な担い手になっていくと考えられることから、人間が働きやすい環境を整えるのと同様に、「AIエージェントが働きやすい環境」を整備するという視点の重要性も増していくのです。
そして、企業ITの設計思想そのものが、「人間が操作するためのシステム」から「人間とAIエージェントが共同で仕事をするためのシステム」へ変わり始めていると捉えることができます。
まさに今は、AI革命によって企業の仕事とITのあり方そのものが再設計され始めた、大きな変革期なのです。
添付１）
SB OAI Japanは、OpenAIの企業向け最新プロダクトと、日本企業向けの導入支援・運用サポートを組み合わせ、2026年に国内展開するとしている というが、クリスタルインテリジェンスの近況は？
ChatGPT:
結論から言うと、2026年9月15日時点で、クリスタル・インテリジェンスは「構想・開発段階」から「ソフトバンク社内での実装・検証を経て、日本企業への本格展開を準備する段階」まで進んでいます。 ただし、一般の日本企業へ広く本格提供が完了した状態ではありません。ソフトバンク側は2026年度から順次立ち上げ、本格的な業績寄与は2027年度以降と見ています。
現在までの進捗を時系列で見ると
�� 2025年11月：SB OAI Japanが正式発足
ソフトバンクグループとOpenAIの合弁会社 SB OAI Japan が発足しました。当初から、ソフトバンク自身を最初の利用者としてクリスタル・インテリジェンスを導入・検証し、そこで得たノウハウを日本企業へ展開する方針でした。グループ内では約250万個のカスタムGPTを作成するなど、事前のAI活用基盤も整備していました。
�� 2026年2月：技術的な「土台」が具体化
ここが大きな進展です。
クリスタル・インテリジェンスは、OpenAIの法人向けAIプラットフォーム**「Frontier」（添付1-1参照）**を基盤として構築されることが正式に発表されました。
Frontierによって、
企業データ
＋既存業務システム
＋複数のAIエージェント
＋セキュリティ・ガバナンス
を統合し、AIエージェントを設計・開発・運用・管理・連携させる構造です。
つまり、「クリスタル・インテリジェンスとは具体的に何を基盤に作るのか」がかなり明確になりました。（添付1-2参照）
�� ソフトバンク社内で実際のAIエージェント・ワークフローを検証
OpenAI側は、SB OAI Japanとともにソフトバンクのコア事業でAIエージェント・ワークフローを実装・展開してきたと説明しています。
これは単なる研究段階から一歩進んでいます。
構想
→ プロトタイプ
→ ソフトバンク自身が「カスタマーゼロ」として実装・検証
→ 日本企業へ展開
という段階に入ったと見ることができます。
�� 2026年7月：企業実装と同時にサイバー防衛も具体化
7月のSoftBank World 2026では、SB OAI Japanの野崎大地CEOが、目標は部門単位のAI導入ではなく、複数のAIエージェントが企業内のデータ・システムと連携し、企業全体を最適化することだと説明しています。
同時にSB OAI Japanは、OpenAIの技術を使った「Patching as a Service」を7月から3,000社へ対象拡大して本格提供しています。これはクリスタル・インテリジェンスそのものではありませんが、企業AIを導入する前提となるセキュリティ基盤の商用化が先行している点は注目できます。（添付1-3参照）
現在地を一言で表すと
私は次のように整理するのが最も正確だと思います。
2025年
構想・合弁会社設立
↓
2026年前半
OpenAI Frontierを技術基盤として確定
↓
現在
ソフトバンク社内で実装・検証
＋AIエージェントの業務統合
＋セキュリティ／ガバナンス整備
↓
2026年度
日本企業へ順次展開
↓
2027年度以降
本格的な事業・収益への寄与を想定
そして、GPT-6 Astraの登場で状況が変わる可能性がある
ここが昨日までの話との接点です。
2月時点ではクリスタル・インテリジェンスの基盤としてFrontierが発表されました。その後9月にGPT-6 Astraが登場しました。
したがって概念的には、
GPT-6 AstraなどOpenAIの高度な基盤AI
＝「知能」
↓
OpenAI Frontier
＝AIエージェントを企業データ・システムにつなぎ、管理する基盤
↓
Crystal intelligence
＝Frontierを基盤に、日本企業向け機能・導入支援・運用サポートなどを統合したソリューション
↓
日本企業
＝営業・経理・調達・生産・経営などでAIエージェントを利用
という構造になります。OpenAI自身も現在、SB OAI Japanを日本企業のAI導入を一気通貫で支援するパートナーとして掲載しています。
ただし、「Crystal intelligenceがGPT-6 Astraを正式採用した」「Astraを中核モデルとして切り替えた」という公式発表は、今回確認した最新資料にはありません。 ここは推測と事実を分ける必要があります。
ですから現在のクリスタル・インテリジェンスを一文で表すなら、
「OpenAIのFrontierを技術基盤として、ソフトバンク自身を実証環境にAIエージェントの企業システム統合を進め、日本企業への順次展開に向けて実装・運用・セキュリティ体制を整えている段階」
とするのが適切です。
そして、今後最大の注目点は、GPT-6 Astraの高度な知能がクリスタル・インテリジェンスへどのような形で組み込まれるのかだと思います。ここが明らかになれば、昨日お話しした「Astra・クリスタル・インテリジェンス」の別ブログ記事の核心になってきます。
添付1-1）
OpenAI Frontier とは？
ChatGPT:
結論から言うと、OpenAI Frontierとは、企業内のデータ・業務システム・AIモデル・AIエージェントを接続し、AIエージェントを企業の「デジタル労働力」として安全に働かせるための企業向けAIプラットフォームです。
単なるGPT-6 Astraのような「AIモデル」ではありません。OpenAIはFrontierを、AIエージェントを構築・導入・管理するためのプラットフォームとして位置づけています。
Crystal intelligenceとの関係
今回の一連の話では、ここを整理すると非常に分かりやすくなります。
GPT-6 Astraなど
＝「頭脳・知能」
↓
OpenAI Frontier
＝「AIを企業のデータ・システムにつなぎ、エージェントとして働かせる共通基盤」
↓
Crystal intelligence
＝「FrontierなどOpenAIの技術を日本企業向けに実装・運用する企業AIソリューション」
↓
AIエージェント
＝「デジタル労働力」
という関係です。
Frontierは具体的に何をするのか
重要なのは大きく4つあります。
- 企業データとの接続
CRM、データウェアハウス（添付1-1-1参照）、社内アプリ（添付1-1-2参照）などと接続します。
- Business Contextの構築
単にデータをAIに渡すのではなく、「この項目は顧客番号」「この数字は売上」「この処理には部長承認が必要」といった、会社固有の仕事の意味やルールをAIが扱えるようにします。 （添付1-1-2参照）
- AIエージェントの実行
複数のAIエージェントが協力して、企業の実際の業務フローを遂行できるようにします。
- 管理・セキュリティ・評価
「このAIは何のデータを読めるのか」「どこまでシステムを操作できるのか」「何を実行したのか」などを管理・監視します。
OpenAI自身も、Frontierの中核としてBusiness Context、Agent Execution、Evaluation & Optimization、Security & Governanceなどを挙げています。
例えば「来月の生産計画を作れ」と指示すると
将来的には、
営業システム → 受注予測
↓
在庫システム → 在庫確認
↓
調達システム → 部品納期確認
↓
生産管理システム → 工場能力確認
↓
会計システム → 原価・予算確認
↓
AIエージェント → 生産計画を作成
というように、従来は人間が複数のシステムを行き来して行っていた仕事を、AIエージェントが横断的に行えるようにするのが狙いです。
つまり一言で言えば、
GPT-6 Astraが「賢い頭脳」だとすれば、OpenAI Frontierは、その頭脳に会社のデータ・システム・権限・業務ルールを接続して、実際に会社で働けるようにする「企業AIの共通基盤」
です。
そしてSB OAI JapanのCrystal intelligenceは、このFrontierを核として日本企業への実装・運用まで持っていく仕組みと捉えると、これまでの話が一本につながります。
添付1-1-1）
データウェアハウス とは？
ChatGPT:
結論から言うと、**データウェアハウス（Data Warehouse：DWH）とは、企業内のさまざまなシステムに分散しているデータを集め、分析や経営判断、AI利用などに使いやすい形で蓄積する「企業データの倉庫」**です。
例えば会社には、
営業システム → 顧客・受注情報
会計システム → 売上・利益・経費
在庫システム → 在庫量
生産システム → 生産量・設備稼働率
調達システム → 仕入価格・納期
など、別々のシステムがあります。
これらのデータをまとめて、
各業務システム
↓
データを収集・整理・統合
↓
データウェアハウス（DWH）
↓
分析・経営判断・AI
という形にします。
例えば社長が、
「過去5年間について、地域別・商品別・顧客別の売上と利益率を分析してほしい」
と指示した場合、営業・会計・顧客などのデータがDWHに統合されていれば、複数の業務システムを一つずつ調べる必要がありません。
普通のデータベースとの違い
業務用データベースは「毎日の仕事を処理する場所」です。
例えば、
注文を登録する
在庫を10個減らす
入金を登録する
といった処理をします。
一方、データウェアハウスは、
「蓄積されたデータを横断的に分析する場所」
です。
したがって、
データベース＝日々の業務を動かす
データウェアハウス＝蓄積した企業データを分析する
という違いがあります。
そして先ほどのOpenAI Frontierとの関係では、
営業・会計・生産などの業務システム
↓
データウェアハウス
↓
Business Context（データの意味・関係・業務ルール）
↓
Frontier / Crystal intelligence
↓
AIエージェント
↓
分析 → 判断 → 提案 → 業務実行
という構造で考えると分かりやすいです。
つまり、**DWHが「会社のデータを集めた倉庫」なら、Business Contextは「そのデータが会社の仕事の中で何を意味するのかをAIに理解させる案内書」**という関係です。
添付1-1-2）
社内アプリで使われている言語にはCOBOLやPL1 といったように、いろいろな言語が使われているが、Frontier は これらの言語を全て解読できるのか？
ChatGPT:
結論から言うと、「FrontierがCOBOL、PL/I、Java、C、C#など、企業内のあらゆるプログラム言語をすべて解読してから社内アプリと接続する」という仕組みではありません。 むしろFrontierは、既存アプリをそのまま残し、APIやコネクター、MCP（添付1-1-2-1参照）などの接続手段を介して、そのアプリが持つデータや機能をAIエージェントから利用できるようにするのが基本的な考え方です。（添付1-1-2-2参照）OpenAIも、Frontierは既存システムの全面移行を要求せず、既存アプリケーションと統合すると説明しています。
COBOLの古い基幹システムを例にすると
例えば銀行に、
COBOLで書かれた預金管理システム
があり、その内部に、
などがあるとします。
Frontierが、
COBOLプログラム数百万行を全部読む
→ プログラムの意味を完全に理解
→ 預金システムを操作
する必要はありません。
むしろ、
COBOL基幹システム
↓
既存API・データ連携・コネクター・必要なら新たな接続層
↓
FrontierのBusiness Context
↓
AIエージェント
という構造にします。
例えば接続層から、
get_customer_balance(顧客番号)
＝指定した顧客の預金残高を取得する
という機能をAIエージェントに提供すれば、AIはその裏側がCOBOLなのかPL/IなのかJavaなのかを意識する必要がありません。
これは、MCPの考え方にも近いものです。MCPは、異なるアプリケーションがデータやツールをAIへ提供する方法を標準化する仕組みで、OpenAIの説明では「AIアプリケーションにとってのUSB-C」のようなものとされています。
では、古すぎてAPIがないシステムはどうするのか
ここが実際の企業導入では難しいところです。
例えば1970〜80年代から使われている、
COBOL
PL/I
メインフレーム
独自データベース
独自通信方式
などでは、現在のAPIが用意されていない場合があります。
その場合は、例えば、
�� 既存システムにAPIを追加する
あるいは、
�� 既存データベースとの連携層を作る
あるいは、
�� 既存の画面・ファイル・バッチ処理などを利用する接続手段を作る
など、企業ごとの統合作業が必要になります。
OpenAI自身も、Frontier導入ではForward Deployed Engineersが企業側と一緒にアーキテクチャを設計し、重要なシステム・ワークフロー・意思決定プロセスへのAI統合を支援するとしています。
ただしAIによるCOBOL解析自体は可能
ここは別問題です。
現在の高度なAIモデルには、COBOLなどのソースコードを読んで、処理内容を説明したり、既存コードの理解・改修を支援したりする能力があります。Frontierでもソフトウェア開発がユースケースとして挙げられています。
したがって、
古いCOBOLプログラムをAIで解析
↓
「この処理は顧客マスターを参照している」
「この項目が顧客番号らしい」
↓
人間が確認
↓
API・接続層を構築
↓
Frontierから利用
という使い方は十分考えられます。
しかし、Frontierが世界中のあらゆるレガシー言語を自動的かつ完全に解読できる、とOpenAIが保証しているわけではありません。
ここがFrontierの重要な設計思想
したがって、「FrontierはCOBOLもPL/Iも全部理解できなければ使えないのでは？」という問題は、実は接続方式によってかなり回避できます。
イメージとしては、
COBOL ─┐
PL/I ──┤
Java ──┤
C# ───┼→ API・コネクター・MCP等 → Frontier → AIエージェント
SAP ──┤
Salesforce ─┘
です。
つまり、Frontierが各プログラム言語を完全に理解することよりも、「異なるシステムを共通の接続方法でAIから利用できる状態にする」ことの方が重要なのです。
これは日本企業へのCrystal intelligence導入を考えるうえでも重要です。日本企業には長年使われているCOBOLなどのレガシーシステムが多数あります。そのため、Crystal intelligence普及の大きなポイントの一つは、**「古いシステムを全部作り直す」のではなく、「既存システムを残しながら、その上にAIエージェントが利用できる接続層を構築できるか」**になると考えられます。
添付1-1-2-1）
MCP とは？
ChatGPT:
結論から言うと、**MCP（Model Context Protocol）とは、AIエージェントが企業のデータ・業務システム・各種ツールを、共通の方法で利用するための「オープンな共通接続規格」**です。
もともとはAnthropicが2024年に公開した規格で、その後OpenAIなどにも採用が広がっています。
例えば企業に、
顧客管理システム
在庫管理システム
販売管理システム
会計システム
があるとします。
それぞれにAPIがあっても、AI側から見れば使い方がバラバラです。
そこでMCPを使って、
AIエージェント
↓
MCP＝共通の接続・利用ルール
↓
API・コネクターなど
↓
既存業務システム
という形にします。
これによってAIは、「どんなデータが利用できるのか」「どんな機能を呼び出せるのか」「どう呼び出すのか」を共通の方式で扱いやすくなります。
例えば人間が、
「在庫が不足している商品を調べて」
とAIエージェントに指示すると、
AIが必要な作業を判断
↓
MCPを通じて「在庫照会」という利用可能なツールを認識
↓
在庫システムへ問い合わせ
↓
在庫データ取得
↓
AIが分析
↓
結果を人間へ報告
という処理ができます。
ここで重要なのが、APIとMCPの違いです。
API＝個々のシステムに用意された「受付窓口」
MCP＝AIがそれらの受付窓口を共通の方式で見つけ、理解し、利用するための「共通ルール」
と考えると分かりやすいでしょう。
したがって、Crystal intelligenceとの関係を簡略化すると、
既存業務システム
↓
APIなどの受付窓口
↓
MCP＝AI向け共通接続規格
↓
OpenAI Frontier
↓
Crystal intelligence
↓
AIエージェント
となります。
一文でまとめれば、MCPとは「AIと企業のさまざまなデータ・システム・ツールをつなぐための共通語」であり、既存システムをAIエージェントから利用しやすくするための標準規格です。
添付1-1-2-2）
APIやコネクター、MCPなどの接続手段を介して、そのアプリが持つデータや機能をAIエージェントから利用できるようにする とは？
ChatGPT:
結論から言うと、**「既存の社内アプリのプログラムそのものをAIに全部読ませるのではなく、そのアプリの“入口”を用意し、AIが必要なデータを取得したり、許可された処理を実行したりできるようにする」**という意味です。
例えば、COBOLで作られた販売管理システムがあるとします。
具体例で考えると分かりやすいです
販売管理システムには、
などがあります。
AIエージェントが、
「ABC商事の過去1年間の売上と現在の未処理注文を調べて」
と指示されたとします。
AIがCOBOLのプログラムを直接読み解いてデータを探しに行くのではありません。
基本的には、
AIエージェント
↓
「ABC商事の売上を取得したい」
↓
MCP・コネクターなど
↓
API
↓
COBOL販売管理システム
↓
売上データを取得
↓
AIエージェント
↓
分析・回答
という流れになります。
APIとは「システムの受付窓口」
例えば販売管理システム側に、
顧客情報を取得する
売上を取得する
在庫を確認する
注文を登録する
という機能が用意されているとします。
AIは、
「売上を取得する」という受付窓口に
「顧客番号12345、期間2026年1月〜8月」
という条件を渡します。
するとシステム側から、
売上＝8,250万円
と返ってきます。
AIにとって重要なのは、裏側の処理がCOBOLなのかPL/IなのかJavaなのかではありません。
コネクターとは「接続を簡単にする部品」
APIを一から作らなくても、すでに広く使われている企業システムなどでは、接続用の仕組みが用意されている場合があります。
イメージとしては、
Frontier
↕ コネクター
CRM
Frontier
↕ コネクター
データウェアハウス
Frontier
↕ コネクター
社内アプリ
という関係です。
つまり、**AIと既存システムをつなぐ「変換アダプター」**と考えると分かりやすいです。
MCPはさらに「共通規格」に近い
MCP（Model Context Protocol）は、AIが外部のデータやツールを利用するための共通の接続方式です。
例えば企業側がAIに、
顧客検索
在庫照会
注文登録
請求書検索
という4つの「道具」をMCP経由で公開したとします。
するとAIエージェントは、
「この仕事には在庫照会が必要だ」
と判断して、その機能を呼び出せます。
ここで大切なのは、AIにデータだけでなく「できること」も提供できることです。
例えば「在庫が少ないので追加発注して」と頼むと
将来的な企業AIでは、
人間
「在庫不足の商品を調べて、必要なら発注して」
↓
AIエージェント
↓
API等で在庫システムを照会
「商品A＝残り20個」
↓
Business Contextを参照
「50個未満なら補充対象」
↓
調達システムを利用
「100個発注」
↓
Business Context
「100万円以上の発注には課長承認が必要」
↓
課長へ承認依頼
↓
承認後、API等を通じて
調達システムに正式発注
というところまで発展できます。
つまり、
API＝個々のシステムが持つ機能への「受付窓口」
コネクター＝AIと既存サービスをつなぐ「接続部品」
MCP＝AIがさまざまなデータや機能を利用するための「共通接続規格」
と理解するとよいでしょう。
そしてFrontierの重要なところは、これらを利用して、
既存システムを全部作り直す
のではなく
既存システムをAIから利用できるようにする
という発想です。
ですから、先ほどのCOBOLの話につなげるなら、**「COBOLをAIに完全解読させる」のではなく、「COBOLシステムにAI用の受付窓口を付ける」（添付1-1-2-2-1参照）**と考えると、一番分かりやすいと思います。
添付1-1-2-2-1）
「COBOLシステムにAI用の受付窓口を付ける」 について、具体的には？
ChatGPT:
結論から言うと、「COBOLシステムにAI用の受付窓口を付ける」とは、COBOLプログラム自体をAI向けに書き換えるというより、COBOLシステムの外側に「APIなどの接続層」を設け、AIから決められたデータ取得や処理だけを呼び出せるようにすることです。
銀行の古いCOBOLシステムを例にすると分かりやすいです。
�� 既存のCOBOLシステムはそのまま残す
例えば銀行に、長年使われているCOBOLの預金システムがあるとします。
内部では、
顧客マスター
口座マスター
残高データ
入出金履歴
などをCOBOLプログラムが処理しています。
AIのために、この巨大なシステム全体を作り直す必要はありません。
�� 外側に「API」を作る
例えば、
口座残高照会API
という受付窓口を作ります。
このAPIには、
「口座番号1234567の残高を教えてください」
という要求を送れるようにします。
すると、
AIエージェント
↓
APIへ「口座1234567の残高照会」
↓
API接続層
↓
既存COBOL処理を呼び出す
↓
COBOLシステム
↓
残高を返す
↓
API接続層
↓
AIが扱いやすい形式に変換
↓
AIエージェント
となります。
例えばCOBOL側では、
1234567 000001250000
のような古い固定長データだったとしても、接続層がAI側には、
口座番号：1234567
残高：1,250,000円
という意味の分かる形に変換できます。
�� AIには「許された機能」だけを公開する
ここが非常に重要です。
COBOLシステムのすべてをAIに開放する必要はありません。
例えばAIに提供する機能を、
顧客検索：○
残高照会：○
取引履歴照会：○
住所変更：承認後のみ○
振込実行：原則×
というように限定できます。
つまりAIは、
「COBOLシステムの中を自由に動き回る」
のではなく、
「会社が用意した受付窓口から、許可された仕事だけを依頼する」
わけです。
�� MCPはその「受付窓口一覧」をAIに分かりやすくする
さらにMCPなどを利用すると、AIエージェント側に、
利用可能なツール
顧客を検索する
口座残高を調べる
取引履歴を取得する
住所変更を申請する
といった形で機能を提示できます。
するとAIエージェントは、人間から
「ABC商事の最近の取引状況を調べて」
と言われた場合、
ABC商事を検索
↓
顧客番号を取得
↓
関連口座を検索
↓
取引履歴を取得
↓
AIが分析
↓
人間へ報告
というように、複数の「受付窓口」を組み合わせて仕事を進められるようになります。
では、APIの裏側は実際にどうやってCOBOLにつなぐのか？
ここにはいくつか方法があります。
例えばメインフレーム上ですでに動いているトランザクション処理、メッセージング、データベース、バッチ処理などに対して、API管理・統合用ソフトウェアを介して接続する方法があります。
IBMも、既存のIBM Z上のアプリケーションやデータをAPIとして公開し、既存資産を新しいアプリケーションから利用するための仕組みを提供しています。つまり、レガシーCOBOLを全部Javaなどへ書き換えなくても、既存機能をAPI化できます。
ですから、実際の構造は、
人間
↓
AIエージェント
↓
Frontier
↓
MCP／コネクター
↓
API ← ここが「受付窓口」
↓
API接続・変換層
↓
既存COBOLプログラム
↓
メインフレーム／データベース
と考えるとよいでしょう。
「受付窓口」という表現の核心
例えば昔ながらの役所を想像してください。
役所の内部では非常に複雑な手続きが行われています。しかし、市民が内部の仕組みを全部理解する必要はありません。
市民は、
住民票窓口
税金窓口
戸籍窓口
など、目的に応じた受付窓口を使います。
同じように、
COBOLシステム＝役所の内部
API＝受付窓口
MCP＝「どんな窓口があり、どう利用するか」をAIに知らせる共通方式
AIエージェント＝窓口を利用して仕事をする担当者
と考えると非常に分かりやすくなります。
したがって、**Frontier／Crystal intelligenceを日本企業へ導入する際の重要な仕事の一つは、「古いCOBOLシステムを全部作り直すこと」ではなく、「既存システムのどの機能をAIに公開するかを決め、安全な受付窓口を整備すること」**だと考えられます。
添付1-1-3）
具体的に 会社固有の仕事の意味やルールをAIが扱える方法は？
ChatGPT:
結論から言うと、会社固有の仕事の意味やルールを「AIが参照・検索・実行できる情報」に変換し、企業データや業務システムと結び付けることで、AIエージェントが扱えるようにします。
ポイントは、会社の規則を全部AIモデルそのものに再学習させる必要はないということです。
具体的には、主に次の5種類の情報をAIから利用可能にします。
- データの意味を定義する
例えば販売システムに、
CUST_NO = 12345
SLS_AMT = 30000000
としか書かれていなければ、意味が曖昧です。
そこでデータ定義書やメタデータとして、
CUST_NO → 顧客番号
SLS_AMT → 売上金額（円、税抜）
と対応付けます。
するとAIは「30000000という数字」ではなく、**「売上3,000万円」**として扱えます。
- 業務マニュアルや社内規程を検索できるようにする
例えば社内規程に、
1,000万円以上の発注は部長承認が必要
と書かれているとします。
規程、マニュアル、FAQ、契約ルールなどをAIが検索・参照できる状態にします。
AIが3,000万円の発注を処理するとき、
3,000万円の発注
↓
社内規程を検索
↓
「1,000万円以上＝部長承認」
↓
部長承認が必要と判断
という処理ができます。
これは一般にRAG（検索拡張生成）的な仕組み（添付1-1-3-1参照）でも実現できます。
- 業務ルールを機械が実行できる形にもする
重要なルールは、文章をAIに読ませるだけでは危険です。
例えば、
発注額 < 1,000万円 → 課長承認
1,000万円以上 → 部長承認
5,000万円以上 → 役員承認
というように、ワークフローやルールエンジンとしてシステム側にも設定します。
つまり、
AIがルールを理解する
だけでなく、
システムもルールを強制する
という二重構造にします。
- 人・組織・権限を結び付ける
例えば、
田中さん＝営業部長
佐藤さん＝営業課長
営業部長＝5,000万円未満まで承認可能
AIエージェントA＝顧客データ参照可、変更不可
といった情報をIAM（添付1-1-3-2参照）などと連携します。
そのためAIが、
「部長承認が必要だ」
と判断した後、誰に承認を求めればよいのか、AI自身には何をする権限があるのかまで判断・実行できるようになります。
- データ・ルール・業務システムを関連付ける
ここがBusiness Contextの核心です。
例えば、
「売上」
↓
販売DBのSLS_AMT
「顧客」
↓
顧客DBのCUST_NO
「部長」
↓
組織・IAM（ID・アクセス管理）情報
「1,000万円以上は部長承認」
↓
購買規程・承認ワークフロー
「発注する」
↓
購買システムの発注API
というように、会社の言葉、データ、ルール、人、システム機能を結び付けます。
OpenAIはFrontierのBusiness Contextについて、企業のデータウェアハウス、CRM、社内アプリなどから、エージェントが組織の仕組みや情報の流れ、意思決定の場所などを理解するための共有された意味的な層を構築するものと説明しています。
したがって、実際のイメージは、
会社が既に持っているもの
データベース
＋ データ定義書
＋ 業務マニュアル
＋ 社内規程
＋ 組織図
＋ 権限情報
＋ API
＋ 過去の業務情報
↓
意味付け・関連付け
↓
Business Context
↓
AIエージェント
↓
「このデータは何を意味するか」
「この仕事はどう進めるか」
「どの規則が適用されるか」
「誰の承認が必要か」
「自分には何をする権限があるか」
「どのシステムを使えば実行できるか」
という構造になります。
ですから、Business Contextとは新しく巨大な「会社説明書」を人間が一から書くというより、会社がすでに持っているデータ・文書・規則・組織・権限・システムをAIが理解できるように意味付けし、相互に結び付ける仕組みと捉えるのが一番近いです。
そして先ほどの「COBOLシステムにAPIという受付窓口を付ける」という話と合わせると、**APIが「AIが会社のシステムを使うための窓口」、Business Contextが「AIに会社の仕事の意味とルールを教える案内書」**という関係になります。
添付1-1-3-1）
RAG（検索拡張生成）的な仕組み とは？
ChatGPT:
結論から言うと、RAG（Retrieval-Augmented Generation：検索拡張生成）とは、AIが自分の学習済み知識だけで回答するのではなく、必要なときに社内文書やデータベースなどを検索し、見つけた情報を材料にして回答・判断する仕組みです。
先ほどのBusiness Contextとの関係で考えると非常に分かりやすいです。
例えば「3,000万円の発注」を処理する場合
会社には「購買規程」という文書があり、
1,000万円以上の発注には部長承認が必要
と書かれているとします。
AIエージェントに、
「A社へ3,000万円分の部品を発注して」
と指示するとします。
RAGを使えば、
�� 人間から指示
「A社へ3,000万円発注して」
↓
�� AIが社内情報を検索
「発注」「3,000万円」「承認」などに関連する社内規程を探す
↓
�� 購買規程を発見
「1,000万円以上は部長承認が必要」
↓
�� AIがその情報を読んで判断
「この発注には部長承認が必要」
↓
�� 承認ワークフローへ
部長に承認依頼
という流れです。
普通の生成AIとの違い
通常の生成AIだけなら、
質問
↓
AIが学習済み知識から回答
です。
RAGでは、
質問
↓
外部情報を検索（Retrieval）
↓
関連する情報を取得
↓
その情報をAIへ追加
↓
AIが回答を生成（Generation）
となります。
つまり、「記憶だけで答えるAI」から「必要な資料を調べてから答えるAI」へ変える技術です。
なぜ企業ではRAGが重要なのか
AIモデルは通常、その会社固有の最新情報までは知りません。
例えば、
2026年度の購買規程
社内人事規程
製品マニュアル
顧客との契約書
社内技術資料
過去の障害報告書
などです。
そこで、これらを検索対象にしておけば、AIは必要なときに関連資料を取り出して利用できます。
さらに、規程が変更された場合も、AIモデルそのものを一から再学習させるのではなく、検索対象となる文書を更新することで対応しやすいのが大きな利点です。
RAGとBusiness Contextは同じものではありません
ここは重要です。
RAGは主に、
「必要な情報を探してAIに渡す仕組み」
です。
一方、Business Contextはもっと広く、
「会社のデータ、文書、業務ルール、人、権限、システムなどの意味と関係をAIが扱えるようにする仕組み」
と考えると分かりやすいです。
例えば、
Business Context
データの意味
＋ RAGによる社内文書検索
＋ 組織情報
＋ 権限
＋ 業務ルール
＋ API・システムとの接続
＋ 業務上の関係
というイメージです。
したがって、RAGはBusiness Contextを実現するために利用できる技術の一つであって、Business Contextそのものではありません。
一言でたとえるなら、
RAG＝AIに「社内資料を調べる能力」を与える仕組み
Business Context＝AIに「この会社では何が何を意味し、誰が何を決め、どう仕事を進めるのか」を理解・利用させる仕組み
です。
この違いを押さえておくと、FrontierやCrystal intelligenceの仕組みがかなり見通しやすくなります。
添付1-1-3-2）
IAM とは？
ChatGPT:
結論から言うと、IAMとは「Identity and Access Management（アイデンティティ・アンド・アクセス・マネジメント）」の略で、「誰が、どの情報やシステムに、どこまでアクセスできるか」を管理する仕組みです。
Crystal intelligenceでは、人間だけでなくAIエージェントにもIDと権限を持たせることが重要になります。
例えば、購買担当AIの場合、
AIエージェントを識別する
「これは購買AIである」
↓
アクセスできる情報を決める
在庫情報 → ○
仕入価格 → ○
顧客情報 → △
人事情報 → ×
↓
実行できる操作を決める
在庫照会 → ○
発注案作成 → ○
100万円以下の発注 → 条件付き○
1,000万円の発注 → 人間の承認が必要
銀行送金 → ×
というように制御します。
つまりIAMには、大きく
Identity（誰なのか）
＋
Authentication（本当に本人・そのAIなのか）
＋
Authorization（何をしてよいのか）
＋
Audit（実際に何をしたのか）
という考え方があります。
Crystal intelligenceの基盤となるOpenAI Frontierでも、AIエージェントに固有のIDを与え、必要な範囲の権限だけを付与するIAMが重要な仕組みになっています。(openai.com)
したがって一言で言えば、
IAM＝「人間やAIエージェントに、必要な情報・システムだけを、必要な範囲で使わせるための身分証＋鍵＋入退室管理」
と考えると分かりやすいです。
そしてCrystal intelligenceのリスク対策では、**「AIを信用するか」ではなく、「仮にAIが間違っても、IAMによって被害が許可された範囲を超えないようにする」**ことが非常に重要になります。
添付1-2）
FrontierとCrystal intelligenceの具体的な役割分担について
ChatGPT:
結論から言うと、**Frontierは「企業AIを動かす共通技術基盤」、Crystal intelligenceは「そのFrontierを使って日本企業にAIを実際に導入・定着させるソリューション」**という役割分担です。これはSB OAI Japanの公式説明とも一致します。
|
項目
|
OpenAI Frontier
|
Crystal intelligence
|
|
提供主体
|
OpenAI
|
SB OAI Japan
|
|
基本的な役割
|
企業AIの技術基盤
|
日本企業向けの導入・運用ソリューション
|
|
Business Context
|
○
|
Frontierを利用して企業ごとに実装
|
|
AIエージェント実行基盤
|
○
|
Frontier上で企業業務に適用
|
|
データ・システム接続
|
接続するための基盤を提供
|
各企業のDWH・CRM・既存システム等との接続を具体化
|
|
権限・セキュリティ・監査
|
基盤機能を提供
|
企業ごとの要件に合わせて設計・実装
|
|
業務設計
|
基盤を提供
|
企業の業務を調査し、ユースケースを設計
|
|
FDE（添付1-2-1参照）
|
OpenAIにもFDE組織あり
|
SB OAI Japan側もFDEによる企業導入支援
|
|
運用・定着
|
基盤・プログラムを提供
|
日本企業での実装・定着を一気通貫で支援
|
OpenAIはFrontierを、企業のDWH・CRM・社内アプリなどをつないでBusiness Contextを形成し、AIエージェントを本番業務で実行・評価・管理する「エンタープライズAIの中核プラットフォーム」と位置付けています。
一方、SB OAI JapanはCrystal intelligenceについて、Frontierを基盤として、日本企業が全社横断でAIを活用するための機能群と、導入支援・運用サポートを統合した法人向けAIソリューションと明記しています。FDEが業務整理、ユースケース設計、既存システムとの統合、セキュリティ・ガバナンス設計、実装・定着まで支援します。
ですから、先ほどの「一般企業は導入要件を明確にすべき」という話とつなげると、全体像はかなり明快です。
企業
「AIに何をさせたいか」
「何を成果とするか」
「どこまで権限を与えるか」
を要件定義
↓
Crystal intelligence／SB OAI Japan
その要件を日本企業の実際の業務に落とし込み、FDEが業務・データ・既存システム・セキュリティ・ガバナンスを設計・統合
↓
OpenAI Frontier
Business Context、Agent Execution、権限管理、評価・監査などの共通技術基盤を提供
↓
AIエージェント
Frontier上で企業のデータ・システムを利用し、実際の業務を遂行
という関係です。
たとえば、ある製造会社が、
「在庫を20％削減しながら欠品を減らしたい」
という要件を出したとします。
Crystal intelligence側は、「販売・在庫・生産・調達データをどうつなぐか」「どんなAIエージェントを作るか」「どこまで自動発注を許すか」「誰が承認するか」などを企業と一緒に設計します。
その裏側でFrontierが、企業データのBusiness Context、AIエージェントの実行、権限管理、監査、評価・改善などの共通基盤を担います。
つまり、
Frontier＝AIエージェントが企業で働くための「共通OS・基盤」
Crystal intelligence＝その基盤を使って、日本企業ごとの仕事に合わせてAIエージェントを導入・運用する「実装ソリューション」
と理解すると分かりやすいと思います。
そして、ここが重要ですが、Crystal intelligenceはFrontierと競合する別のAI基盤ではありません。Frontierを土台として、その上に日本企業向けの機能・導入・システム統合・運用支援を組み合わせる関係です。SB OAI Japan自身もこの関係を明示しています。
したがって、企業側から見ると、「Frontierをどう使うか」を自社ですべて考えるのではなく、「自社はAIで何を実現したいか」をCrystal intelligence側に要件として提示し、Frontierを使った具体的な企業AIシステムへ落とし込んでもらう、というのが基本的な役割分担になります。
添付1-2-1）
FDE とは？
ChatGPT:
結論から言うと、FDEとは「Forward Deployed Engineer（フォワード・デプロイド・エンジニア）」の略で、顧客企業の現場に深く入り込み、AIをその会社の実際の業務・データ・既存システムに組み込み、本番運用まで支援するエンジニアです。
Crystal intelligenceの場合、FDEは単なる「AIの技術サポート担当」ではありません。SB OAI Japanは、FDEが企業と並走して、業務整理 → AIを使う業務の選定 → AIエージェント設計 → データ・既存システムとの接続 → セキュリティ・ガバナンス設計 → 実装 → 社内定着・運用まで一気通貫で支援すると説明しています。
例えば、ある製造会社がCrystal intelligenceを導入するとします。
企業側
「在庫管理と発注業務をAI化したい」
↓
FDE
「どのデータが必要か」
「現在の発注ルールはどうなっているか」
「どのシステムと接続するか」
「AIにどこまで権限を与えるか」
を調査
↓
既存システム・データ
在庫DB・販売システム・調達システム・業務規程など
↓
Frontier／Crystal intelligenceと接続
↓
AIエージェントを構築
↓
テスト・評価・セキュリティ確認
↓
実際の業務へ導入
というところまでFDEが企業と一緒に進めます。
特に日本企業では、これまで話してきたCOBOLなどのレガシーシステム、複雑な業務ルール、データ定義、権限・承認プロセスがあります。FDEは、こうした「その会社特有の事情」とOpenAIのAI技術との橋渡しをする重要な役割になります。
一言で表すなら、
FDE＝「Crystal intelligenceを売る人」ではなく、「顧客企業の現場に入り、AIが本当に仕事をできるところまで作り上げる技術者」
と理解すると分かりやすいです。
実際、SB OAI JapanのFDE求人でも、単なるPoC（実証実験）ではなく、業務に定着して成果を出し続ける本番システムまで構築することをミッションとして掲げています。
添付1-3）
SB OAI Japanが目指す「3,000社へのCrystal intelligence投入」の進捗状況について
ChatGPT:
結論から言うと、
👉 2026年時点では、約3,000社へのCrystal intelligenceの本格展開が完了しているわけではなく、ソフトバンク自身での先行検証を踏まえながら、日本企業への導入・商用展開を進めている段階です。
そして重要なのは、
👉 「3,000社のうち、すでに何社へ導入したのか」という具体的な導入社数は、現時点では公表されていない
という点です。
■ そもそも「3,000社」とは何か
SB OAI Japanが目指しているのは、単純に約3,000社へChatGPTのようなAIサービスを販売することではありません。
Crystal intelligenceを、
企業固有の業務・データ・システムと接続し、AIエージェントが企業活動そのものを支援・自動化する基盤
として展開する構想です。
そのため、一般企業への導入では、
業務整理
→ AIを使う業務の選定
→ AIエージェントの設計
→ 社内データ・既存システムとの接続
→ セキュリティ・ガバナンス設計
→ 実装
→ 社内定着・運用
という作業が必要になります。
■ なぜ3,000社への展開に時間がかかるのか
Crystal intelligenceは、通常のSaaSのように「契約してアカウントを作れば導入完了」という製品ではありません。
企業ごとに、
- どの業務をAIに任せるのか
- どのデータをAIに利用させるのか
- AIにどこまで権限を与えるのか
- どこで人間の承認を必要とするのか
- 既存システムとどう接続するのか
- セキュリティや監査をどう設計するのか
を決める必要があります。
ここで重要になるのが、**Forward Deployed Engineers（FDE）**です。
FDEは企業の現場に入り込み、
企業の業務を理解する
→ AI化できる業務を特定する
→ AIエージェントを設計する
→ 既存システムと接続する
→ 実際に業務で使える状態まで持っていく
という役割を担います。
■ したがって現在の位置づけ
大きく整理すると、
第1段階：ソフトバンク自身での検証・導入
↓
第2段階：先行企業への導入・ユースケース確立
↓
第3段階：FDEなどを活用した導入体制の構築
↓
第4段階：約3,000社への本格展開
という流れになります。
2026年時点では、
👉 「3,000社への導入が進んでいる」というより、「3,000社へ展開できる仕組みを作りながら、実際の企業導入を進めている段階」
と理解する方が適切です。
■ さらに重要なのは「3,000社」という数字より企業の再設計
Crystal intelligenceの本質は、AIツールを企業に追加することではありません。
従来は、
人間中心の会社
→ AIを追加
→ 業務効率化
でした。
Crystal intelligenceが目指している方向は、
最初から人間＋AIエージェントを前提に業務を設計
→ AIにできる仕事はAIへ
→ 人間は目的設定・重要判断・監督を担当
という企業構造への転換です。
これは、以前取り上げた**「AIソロプレナー」**とも非常によく似た方向です。
AIソロプレナーが、
「個人＋多数のAIエージェント」
だとすれば、Crystal intelligenceは、
「企業＋多数のAIエージェント」
を実現しようとしている、と捉えることができます。
■ 一文で総括
👉 SB OAI Japanの「3,000社構想」は、2026年時点では3,000社への導入が完了・大量展開している段階ではなく、ソフトバンクでの先行検証を起点に、FDEなどを通じて企業ごとの業務・データ・システムにAIエージェントを組み込み、本格展開できる体制を構築している段階、と見るのが適切です。
そして、この構想の本当の意味は、
👉 「3,000社にAIを売ること」ではなく、「3,000社を人間とAIエージェントが共同で働く企業へ変えていくこと」
にある、と整理できます。
添付２）
Crystal intelligence は既存のプログラム言語を解析して業務システムを理解するということか？
ChatGPT:
結論から言うと、基本的には違います。Crystal intelligenceが既存システムのJava、COBOL、C#などのプログラム言語をすべて解析して、「この会社の業務はこうなっている」と理解することが中心ではありません。
むしろ、既存システムが持っているデータ、API、業務上の意味、権限、ワークフローなどを接続して、AIエージェントが「会社の仕事の仕組み」を理解できるようにするという考え方です。OpenAIはFrontierについて、既存システムを別のプラットフォームへ移行させることなく、データウェアハウス（添付2-1参照）、CRM、社内アプリなどを接続して共通の「Business Context」を構築すると説明しています。
例えば、既存の販売管理システムがある場合
仮に30年前に作ったシステムが、
COBOLプログラム
＋
顧客データベース
＋
受注データベース
＋
在庫データベース
で動いていたとします。
Crystal intelligenceが、
COBOLの数百万行のソースコードを全部読む
↓
プログラムを解析する
↓
「これは販売管理システムだ」と理解する
という方法だけで業務を理解するわけではありません。
むしろ、
販売管理システム
↓
API・データベース・コネクターなど
↓
Frontier / Crystal intelligence
↓
「これは顧客情報」
「これは受注情報」
「これは在庫情報」
「この操作は発注処理」
という**業務上の意味（Business Context）**を与える
↓
AIエージェントが業務を理解して利用する
という構造です。OpenAIは、既存データを移動したり既存アプリを捨てたりする必要はなく、オープンスタンダード（添付2-2参照）を使って既存アプリケーションと統合できるとしています。
ただし、プログラム解析を「しない」という意味でもありません
ここは区別が必要です。
AIには現在でもソースコードを読み、プログラムの構造や処理内容を理解する能力があります。
したがってCrystal intelligenceの導入過程で、
「この古いプログラムは何をしているのか」
「この処理はどのデータベースを書き換えているのか」
「このAPIをどう接続すればよいか」
などを調べるために、AIによるコード解析を利用することは十分考えられます。
しかし、「Crystal intelligenceは既存プログラムを自動解析することによって企業業務を理解する製品である」ことは、現在の公式説明では確認できません。
SB OAI Japanの公式説明では、FDE（添付2-3参照）が企業ごとに、業務整理 → ユースケース設計 → データ・既存システムとの統合 → セキュリティ・ガバナンス設計 → 実装・定着まで支援するとされています。
ですから、以前の説明をさらに正確にすると、
既存プログラムを読む
＝システムが「どう作られているか」を理解する
のに対して、
Crystal intelligence / Frontier
＝企業のデータ・システム・業務プロセスを接続し、「会社がどう仕事をしているか」をAIエージェントが理解・実行できるようにする
という違いです。
そしてこれは重要で、古いCOBOLシステムであっても、必ずしもAI向けに全面的に作り直す必要はありません。 既存システムとの接続方法を構築できれば、その上にAIエージェントという新しい「知能・実行層」を載せられる、というのがFrontier／Crystal intelligenceの大きな狙いだと考えると分かりやすいです。
添付2-1）
データウェアハウス とは？
ChatGPT:
結論から言うと、**データウェアハウス（Data Warehouse：DWH）とは、会社のさまざまな業務システムに分散しているデータを集め、分析・経営判断などに利用できるよう整理して蓄積する「企業データの大規模な倉庫」**です。
例えば企業には、
営業システム → 顧客・受注データ
会計システム → 売上・利益・経費データ
在庫システム → 商品・在庫データ
生産システム → 生産量・設備稼働データ
調達システム → 部品・仕入先・価格データ
などがあります。
これらは通常、それぞれ別々のデータベースに保存されています。
そこで、
営業システム ─┐
会計システム ─┤
在庫システム ─┼→ データウェアハウス（DWH）
生産システム ─┤ ↓
調達システム ─┘ 分析・経営判断・AI
という形で、一か所に集約します。
普通の「データベース」と何が違うのか
大きな違いは目的です。
|
業務用データベース
|
データウェアハウス
|
|
主な目的
|
日々の業務処理
|
分析・意思決定
|
|
例
|
注文登録、在庫更新
|
売上分析、需要予測
|
|
データ
|
現在の業務データ中心
|
複数システム＋過去データ
|
|
利用者
|
業務システム
|
経営者・分析担当・AIなど
|
例えば「顧客番号12345の注文を登録する」のが業務データベース。
一方、
「過去5年間で、どの地域の、どの顧客層が、どの商品を多く購入し、利益率がどう変化したか」
を分析するために使うのがDWHです。
Crystal intelligenceとの関係
ここが先ほどの話につながります。
Crystal intelligence／AIエージェントから見ると、データウェアハウスは企業全体を理解するための重要な情報源になります。
例えば、
各業務システム
↓
データウェアハウス
↓
Business Context（データの意味・業務上の関係）
↓
Crystal intelligence
↓
AIエージェント
↓
分析 → 判断 → 提案 → 業務実行
という構造です。
したがって、データウェアハウス＝企業のデータを集めた「倉庫」、**Business Context＝そのデータが会社の仕事の中で何を意味するかを示す「説明書」**と理解すると、両者の違いが分かりやすいです。
添付2-2）
オープンスタンダード とは？
ChatGPT:
結論から言うと、**オープンスタンダード（Open Standard）とは、特定の企業だけが独占するのではなく、多くの企業や製品が共通して利用できるよう、仕様が公開・標準化された「共通ルール」**のことです。
身近な例では、USB、Wi-Fi、HTML、HTTPなどがあります。
例えば、会社に、
販売管理システム
＋ 会計システム
＋ 在庫管理システム
＋ Crystal intelligence
があるとします。
それぞれが独自の方法でしか通信できないと、接続するのが非常に大変です。
そこでオープンスタンダードという「共通語」を使います。
既存業務システム
↓
オープンスタンダードに基づく接続方法
↓
OpenAI Frontier / Crystal intelligence
↓
AIエージェント
という形です。
例えばOpenAIはFrontierについて、既存システムとの統合にMCP（Model Context Protocol）やAGENTS.mdなどのオープンスタンダードを利用すると説明しています。これによって既存データを別の場所へ移したり、既存アプリを全面的に作り直したりせずに、AIエージェントを接続することを狙っています。
したがって、今回のCrystal intelligenceの話でいう「オープンスタンダード」は、簡単に言えば、
既存の業務システムとAIエージェントをつなぐための、企業をまたいで利用できる共通の接続ルール
と理解するとよいでしょう。
なお、「オープンスタンダード」と「オープンソース」は別物です。オープンスタンダードは「仕様・ルールが公開されていること」、オープンソースは「プログラムのソースコードが公開されていること」を指します。
添付３）
例えば、Crystal intelligence は顧客データベースのどの項目が顧客番号と認識するのか？
ChatGPT:
結論から言うと、Crystal intelligenceが「この項目は顧客番号だ」と勝手に推測することを基本にするのではなく、企業側が持っているデータ定義・スキーマ・メタデータ・API仕様などをAIに与えることで認識させる、と考えるのが正確です。
例えば顧客データベースが次のようになっているとします。
|
データベース上の項目名
|
内容
|
|
CUST_ID
|
顧客番号
|
|
CUST_NM
|
顧客名
|
|
TEL_NO
|
電話番号
|
|
ADDR
|
住所
|
|
SALES_AMT
|
売上金額
|
人間なら社内の「データ項目定義書」を見て、
CUST_ID ＝ 顧客番号
と理解します。
AIエージェントにも同じように、データの構造だけでなく「そのデータが企業内で何を意味するのか」というBusiness Context（添付3-1参照）を与えるわけです。OpenAI Frontierも、データウェアハウス、CRM、社内アプリなどをBusiness Contextで接続し、AIエージェントが人間と同じ企業情報を利用できるようにする考え方です。
では「CUST_ID＝顧客番号」をどう教えるのか
大きく言えば、
既存データベース
CUST_ID = 00012345
↓
スキーマ・メタデータ・データカタログ・API仕様・業務定義など
「CUST_IDは顧客を一意に識別する顧客番号」
↓
Frontier / Crystal intelligence
↓
AIエージェント
「00012345は顧客番号である」と理解
という形です。
実際、OpenAIが提供する企業データ連携では、データカタログのメタデータ、意味定義、データ系統（lineage）、品質情報、ドキュメントなどをAIに与える仕組みもあります。
AIが項目名だけから推測する場合もある
例えば、
customer_id
customer_name
address
なら、AIはかなり容易に意味を推測できます。
しかし、
A001
A002
A003
のような昔のシステムでは、AIだけでは「A001＝顧客番号」と確実には判断できません。
そこで、
�� データ項目定義書
�� データベースのスキーマ
�� API仕様書
�� 業務マニュアル
�� データカタログ
�� 必要に応じて既存プログラムやSQL
などを使って意味を対応付ける必要があります。OpenAIの企業AIに関する資料でも、企業知識を機械が扱える形に整理し、主要データパイプラインにAPIを整備することが重要だとされています。
ですから、前の質問とつなげると非常に重要な違いがあります。
「既存プログラムを全部読ませる」
→ 業務を理解させる
というより、
「既存システムのデータ＋データの意味＋業務ルール＋権限」をAIに接続する
→ 業務を理解させる
という考え方です。
つまり、Crystal intelligence導入で重要になるのは、AIの賢さだけではなく、企業側が何十年も蓄積してきた「このデータは何を意味するのか」という業務知識を、AIが理解できる形に整理することです。
これは日本企業の古い基幹システム、いわゆるレガシーシステムをCrystal intelligenceにつなげられるのかという問題にも直結します。
添付3-1）
Business Context とは？
ChatGPT:
結論から言うと、Business Context（ビジネス・コンテキスト）とは、AIが企業のデータを単なる数字や文字としてではなく、「そのデータが会社の業務の中で何を意味するのか」まで理解するための業務上の背景・意味・関係性のことです。
先ほどの「顧客番号」の例が非常に分かりやすいです。
例えばデータベースに、
|
項目
|
データ
|
|
CUST_ID
|
12345
|
|
CUST_NM
|
山田商事
|
|
SALES
|
5,000,000
|
|
RANK
|
A
|
と入っていたとします。
AIにとって、これだけでは単なるデータです。
しかしBusiness Contextとして、
- CUST_ID＝顧客を一意に識別する顧客番号
- CUST_NM＝顧客の会社名
- SALES＝当年度の累計売上高（円）
- RANK＝自社基準による顧客重要度
- Aランク＝重要顧客
- Aランク顧客への値引きには営業部長の承認が必要
といった情報が加わると、AIは**「データの意味」と「その会社での扱い方」**まで理解できるようになります。
OpenAIはFrontierのBusiness Contextについて、企業内で情報がどのように流れるか、意思決定がどこで行われるか、何が重要な成果なのかといった組織固有の文脈をエージェントに提供するものと説明しています。
したがって、Business Contextは単なる「データ項目辞書」より広い概念です。
データの意味
＋ データ同士の関係
＋ 業務プロセス
＋ 社内ルール
＋ 権限・承認関係
＋ 組織構造
＋ 過去の業務知識
などを組み合わせた、いわば**「その会社では仕事がどう動いているのかをAIに理解させるための会社の業務知識」**です。
これをCrystal intelligenceの流れにすると、
企業の既存データ・業務システム
↓
Business Context＝「このデータや業務が何を意味するのか」
↓
OpenAI Frontier / Crystal intelligence
↓
AIエージェント
↓
企業の仕事を理解して判断・提案・実行
となります。
一言で言えば、**Business Contextとは「会社の仕事の意味をAIに理解させるための説明書」**と考えると最も分かりやすいです。
