ブログ

AI Work OS:新たな知能が企業で働く仕組み

Sam Kim

Sam Kim

CTO

サムは、大規模な検索クラウドシステムの豊富な専門知識を持つCTOで、企業環境向けのセキュリティアクセス制御システムを設計する製品部門をリードしています。強固な技術的基盤と革新的なビジョンを持ち、サムはスケーラブルで安全なソリューションを設計し、現代企業の要求に応えています。

2026年6月16日

AI Work OS:新たな知能が企業で働く仕組み
AI Work OSプレゼンテーションの概要

概要

ChatGPTの登場以降、AIは急速に普及しました。当初は、質問に答え、文章を整え、コードを提案するツールとして受け入れられていました。しかし、企業で起きている変化はそれよりもはるかに大きなものです。

AIは今や単なる回答ツールを超え、データを読み、コンテキストを理解し、判断を支援し、実際の業務を実行する新たな知能となっています。企業では、もはや人だけが働いているわけではありません。人とともに働く、もう一つの知能が登場しました。

この変化の本質は、「AIをどう上手に使うか」ではありません。より重要なのは、次の問いです。

企業は、新たな知能が実際の業務で働けるように、どのような運用基盤を整えるべきか?

私は、この運用基盤を AI Work OSと定義します。

AI Work OSは、AIが企業のコンテキストを理解し、業務を実行し、適切な統制を受けながら働くための基盤です。AIが理解できるデータとコンテキスト、実務を遂行する実行基盤、そしてその実行を安全に管理する統制基盤を一体化します。

発表資料

この記事の基になった発表資料は、OpenAI Founder Day - AI Work OS (PDF)でご覧いただけます。

新たな知能の登場

これまで企業の業務システムは人を中心に設計されてきました。

人がシステムにログインし、データを照会し、文書を作成し、決裁を上げ、権限を要求し、実行結果に責任を持ちました。アクセス統制と監査も基本的に人のアカウント、人の権限、人の行為を中心に作られてきました。

しかし、AI Agentが企業業務に入ってくるとこの前提が変わります。

AIは単にユーザーの質問に答えるだけでなく、次のような作業を行います。

  • 複数のシステムから必要なデータを見つけます。
  • 文書、対話、ポリシー、過去の履歴を横断して読み取ります。
  • 判断に必要な根拠を整理します。
  • 報告書、見積書、分析文書のような成果物を作成します。
  • 承認依頼から業務実行までをつなぐ流れを作ります。

このとき、AIは独立した従業員として働くわけではありませんが、企業業務の一部を担う存在になります。したがって、企業はAIを単なるSaaSツールやチャットボットとして捉えることはできません。新たな知能が企業データやシステムにアクセスし、業務を実行する仕組みとして捉える必要があります。

考えるツールの登場と企業の運営、統制の問い
考えるツールの登場と企業の運営、統制の問い

AI Work OSが必要な理由

新たな知能とともに働くには、企業に3つの要素が必要です。

第一に、 AIが理解できるデータとコンテキストです。

企業データの多くは、データベース、SaaS、ファイル、文書、メッセンジャー、決裁システム、業務履歴、担当者の暗黙知に分散しています。AIが意味のある判断をするには、単にデータへアクセスするだけでは不十分です。データがどのような業務コンテキストで作られ、どのポリシーやプロセスに結びつき、どのような例外やドメイン知識を含むのかまで理解する必要があります。

第二に、 実際の業務を遂行できる実行構造です。

AIが分析結果を言葉で提案するだけでは、企業の生産性向上には限界があります。業務は最終的に実行されなければなりません。必要なデータを照会し、システムを呼び出し、文書を作成し、担当者に承認を依頼し、結果を記録する流れが必要です。AI Agentは、この実行プロセスの中で判断と作業を連携させる必要があります。

第三に、 実行を安全に運営するための統制構造です。

AIがデータを参照し、システムを呼び出して業務を実行する段階では、性能だけを見ていては不十分です。どの権限で動いたのか、何を実行したのか、誰が承認したのか、どの記録が残ったのか、機密データが保護されたのかが重要になります。

AI Work OSは、この3つを一つの運用基盤にまとめる概念です。コンテキスト、実行、統制が分断されていると、AIを業務へ深く組み込むことはできません。3つを一体として設計することで、AIは企業で責任ある形で働けるようになります。

QueryPie AI Work OSのコンテキスト、実行、統制構造
QueryPie AI Work OSのコンテキスト、実行、統制構造

重要な課題は実行と統制にある

多くの企業はAI導入を検討する際、モデル性能、回答品質、RAGの精度から考え始めます。もちろん、いずれも重要です。しかし、企業環境ではその先にある課題のほうが難しくなります。

AIが検索、分析、文書作成、承認依頼、実行まで担うようになると、企業は次の問いに答えなければなりません。

  • AIはどのようなデータにアクセスできるか?
  • どのようなシステムを呼び出せるか?
  • どのような権限で実行するか?
  • 実行前に承認や検討が必要か?
  • 実行過程と結果はどこに記録されるか?
  • 問題が起きた時、誰が責任を持ち追跡できるか?

これらの問いに答えられなければ、AIは実証実験や個人向けの生産性ツールにとどまります。企業の中核業務へ組み込むには、実行に伴う責任と統制が欠かせません。

AI時代の重要な課題は、AIをより賢くすることだけではありません。AIに何ができ、何をさせてはならず、実際に何をしたのかを説明できるようにすることです。

AI Agent時代の新たな問題:回答生成を超えて業務実行へ
AI Agent時代の新たな問題:回答生成を超えて業務実行へ

QueryPieが見る3つの軸:AIP、ACP、FDE

QueryPieはAI Work OSを3つの軸として扱っています。

第一の軸は **AIP(AI Platform)**です。AIPはAIを実際に働かせる実行の基盤です。企業がAI Agentを作り、業務の流れを構成し、LLM、RAG、MCP、Skills、Agentを組み合わせて実際の業務実行を試し、実装できるプラットフォームです。

第二の軸は **ACP(Access Control Platform)**です。ACPは、権限、監査、記録を扱う統制の基盤です。AIがどのリソースにアクセスし、どのような権限でシステムを呼び出し、その過程がどのように記録され監査されるかをリソースごとに統制します。

第三の軸は **FDE(Field Domain Engineering)**です。FDEは、顧客現場の業務を理解し、ドメイン知識を構造化して、AIが実際の成果を生み出せる形へ変える実装支援の軸です。

これら3つはそれぞれ単独の製品や機能としてのみ見ることはできません。AI Work OSという観点から見ると、AIPは実行を生み出し、ACPは実行を統制し、FDEは実行が実際の業務価値につながるようにします。

AIP、ACP、FDEが構成するEnterprise AI Work OS
AIP、ACP、FDEが構成するEnterprise AI Work OS

QueryPieの進化:人のアクセス制御から知能のアクセス制御へ

QueryPieは元々人、すなわち人間知能を対象とするアクセス制御会社でした。

人がデータベース、サーバー、Kubernetes、クラウドリソースにアクセスする際、誰が、いつ、どのような権限で、何をしたかを統制し記録することがQueryPieの出発点でした。

しかし、AIが企業のデータとシステムにアクセスする時代となり、統制対象が拡大しました。今では人だけでなく、 人工知能も統制対象となりました。

AIを適切に統制するには、AIがどのように働くのかを理解する必要があります。単に「アクセスを遮断する」というアプローチだけでは不十分です。AIがどのような文脈を見て、どのようなツールを呼び出し、どのような順序で判断し、どのような実行につながるのかを知る必要があります。

そこでQueryPieはAIPを作りました。AIPを通じてAI Agentが実際の業務でどのように動くかを実験し、顧客現場ではFDEを通じてどのようなドメイン知識と業務構造が必要かの経験を積みました。そしてこの経験を再びACPに持ち込み、AIのアクセスと実行を統制する構造へと拡張しています。

これが、QueryPieがAI Work OSへと進化する方向性です。

QueryPieの会社紹介およびAI Work OS拡張の流れ
QueryPieの会社紹介およびAI Work OS拡張の流れ

AIP:実行の基盤

AIPは、企業がAI Agentを構築し、実行・検証するための基盤です。

企業業務に合ったAI Agentを作るには複数の要素が必要です。LLMは判断と言語理解を担います。RAGは企業内部の文書と知識を検索し、回答の根拠を提供します。MCPはAIが外部システムやツールを呼び出せる接続構造を提供します。Skillsは特定の業務を実行するための手順と能力を定義します。Agentはこれらの要素を組み合わせて目的を持った実行フローを作ります。

AIP:企業業務システムをAI Agentとつなぐ実行プラットフォーム
AIP:企業業務システムをAI Agentとつなぐ実行プラットフォーム

構造的に見ると、AgentはLLMを基盤として判断し、MCP Gatewayを通じてDB、SaaS、内部システム、APIのような企業リソースを呼び出します。そしてこの実行はACPの統制の下で行われなければなりません。

MCP Gatewayを中心に複数のLLMと業務ツールを統制する構造
MCP Gatewayを中心に複数のLLMと業務ツールを統制する構造

つまりAIPは、AIが「考えて答えるだけの場」ではなく、企業業務の実行フローを構築し、検証するための基盤です。

Apps:実行を業務体験に変える接点

AIPは強力ですが、すべての顧客がMCP、Skills、RAG、Agentを直接理解し組み合わせることを望んでいるわけではありません。

顧客が知りたいのは技術構造そのものではなく、より具体的な業務上の価値です。

「自分の業務でどのように使われるか?」

そこでQueryPieはAIPの上で業務単位のAppsを作っています。Lingo、YuhoNavi、NotePie、Outbound AgentのようなAppsは、AIの実行能力を会議、財務分析、ドキュメント作成、営業実行のような日常業務の中で体感させる接点です。

AIP Appsが業務自動化体験につながる仕組み
AIP Appsが業務自動化体験につながる仕組み

これらのAppsは単なるデモではありません。AI Agentが実際の業務の起点と成果物、承認フロー、記録構造の中に入ったとき、どのようなユーザー体験が必要かを検証する装置です。

AI Work OSにおいてAppsは技術を業務言語に変えるレイヤーです。

会議、財務、知識、セールス業務で実行されるAIP Appsの事例
会議、財務、知識、セールス業務で実行されるAIP Appsの事例
Lingoを活用したグローバル顧客、パートナーコミュニケーションの事例
Lingoを活用したグローバル顧客、パートナーコミュニケーションの事例

FDE:顧客現場の価値を実装する

企業顧客が求めているのは、AIそのものではありません。自社の業務で得られる具体的な成果です。

しかし実際の企業業務は文書を読むだけでは理解が難しいです。文書にない例外があり、担当者の暗黙知があり、古い業務履歴があり、顧客ごとの特殊条件があります。同じ用語でも部門によって意味が違い、同じプロセスでも現場では異なる運用がされます。

FDEはこの複雑な業務を理解し、ドメイン知識を構造化して、AIが実行可能な形に変える役割を果たします。

FDEが顧客ドメインとデータパイプラインを実行プロトタイプに変える流れ
FDEが顧客ドメインとデータパイプラインを実行プロトタイプに変える流れ

例えばPayroll業務では、給与計算の例外と検証手順をAIが扱える構造に変えることが重要でした。Toyotaの事例では、複雑な仕様書の分岐を人が長く解釈していた業務からAIが迅速に判断可能なフローを作りました。見積書Agentは、熟練営業担当者の暗黙知を組織の実行資産へ転換できる可能性を示しました。財務自動化は1ヶ月近くかかっていた競合レポート作成業務を数分で処理可能な構造に変えました。

Payroll, Toyota T-Connect, AI見積書Agent, 財務自動化などのFDE事例
Payroll, Toyota T-Connect, AI見積書Agent, 財務自動化などのFDE事例

ここで重要なのは製品のインストールではありません。重要なのは 実際の業務が変わるかどうかです。

FDEは、AI Work OSが抽象的なプラットフォームにとどまらず、顧客現場の成果につながるようにする重要な軸です。

オントロジー:個人の生産性を組織の生産性へと拡張する基盤

AIが個人の生産性を高めることと、組織全体がより良く仕事をするようになることは異なります。

個人がAIを使って素早く文書を作成し、分析を行っても、その過程で生み出された知識とコンテキストが組織内に蓄積されなければ、生産性は個人の内に留まります。組織の生産性につなげるには、データ、プロセス、ポリシー、ドメイン知識、暗黙知が相互に接続される必要があります。

このときに必要なのが、オントロジーです。

オントロジーは、AIが企業の業務を理解するための意味地図です。どのデータがどの業務と接続されているか、どのポリシーがどの実行を制限するか、どの役割がどの責任を持つか、どの例外がどの判断につながるかを構造化します。

AI Work OSにおいて、オントロジーは単なるナレッジグラフではありません。個人のAI活用を組織の生産性へと拡張するための基盤です。

オントロジーが組織の業務の意味関係を示すマップ
オントロジーが組織の業務の意味関係を示すマップ

救急医療の事例:つながったコンテキストに基づく推論

救急医療を考えてみると、この原理が明確になります。

救急患者、救急車、病院、病床、医療スタッフ、設備、移動経路がそれぞれ別々に存在しているなら、AIができることは限定的です。しかし、これらの情報が一つのコンテキストとして接続されると、AIは実行可能な判断を支援できます。

どの患者をどの病院へ送るべきか、どの病床と医療スタッフが利用可能か、移動経路と時間はどうか、必要な設備が準備されているかといった判断は、単一の情報からは生まれません。接続されたコンテキストの上から生まれます。

救急医療で病床、重症度、移動経路を総合的に判断する推論例
救急医療で病床、重症度、移動経路を総合的に判断する推論例

この原理は病院にのみ適用されるものではありません。製造、サプライチェーン、航空宇宙、金融、公共サービスなど、複雑な産業であればあるほど、重要な判断は単一のデータではなく、接続されたコンテキストから生まれます。

AI Work OSは、このような接続されたコンテキストを基盤としてAIが判断し、実行できるようにする構造です。

ACP:知能を統制する基盤

AIが複数のデータを参照し、システムを呼び出し、実行に関与するようになると、人間中心のアクセス制御だけでは不十分です。

既存のアクセス制御は、人がどのシステムへアクセスするかを中心に設計されていました。しかし、AI Agentはユーザーに代わって複数のリソースを呼び出し、複数の段階を経て処理し、ときには承認依頼や自動化されたタスクまで実行します。

したがって、今やAIという新しい知能のアクセスと実行も統制しなければなりません。

AI Agentと業務システムのアクセスを統制するQueryPie ACP
AI Agentと業務システムのアクセスを統制するQueryPie ACP

ACPは、AIがどのリソースにアクセスするか、どの権限で実行するか、その過程がどのように記録され監査されるかをリソースごとに統制します。データベース、SaaS、API、内部システム、ファイル、業務ツールなど、AIが呼び出すすべてのリソースが権限と監査の対象にならなければなりません。

データベースからMCPまで拡張されるEnterprise Access Control
データベースからMCPまで拡張されるEnterprise Access Control

AI時代の統制は、単に接続を許可または遮断するだけの問題ではありません。実行のコンテキスト、権限の範囲、承認条件、記録、監査可能性を一体として設計する必要があります。

製品セキュリティ、運用信頼性、監査追跡性、コンプライアンス認証を備えたプラットフォーム
製品セキュリティ、運用信頼性、監査追跡性、コンプライアンス認証を備えたプラットフォーム

結論:AI導入の要点は運用基盤にある

AI導入の要点は、単にAIツールを使うことではありません。

新しい知能が働けるようにコンテキストを接続し、実際の業務を担わせ、その実行を安全に統制することが重要です。

AI Work OSは、この3つを一体で扱う運用基盤です。

  • AIPは、AIが働ける実行基盤を作ります。
  • Appsは、実行能力を実際の業務体験に変えます。
  • FDEは、顧客現場の複雑な知識をAIが実行可能な構造に変えます。
  • オントロジーは、個人のAI活用を組織の生産性へと拡張します。
  • ACPは、新しい知能のアクセスと実行を安全に統制します。

企業には、新しい知能が入り始めています。今必要なのは、より多くのAIツールではなく、この知能が責任ある形で働ける運用基盤です。

その運用基盤こそが AI Work OSです。