AI Work OS: 新たな知能が企業内で働く方式
2026年6月16日
概要
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のコンテキスト、実行、統制構造
核心の課題は実行と統制だ
多くの企業がAI導入を語る際、モデル性能、回答品質、RAGの正確度から悩みます。もちろん重要です。しかし、企業環境ではその次の問題がより難しいです。
AIが検索、分析、文書作成、承認要求、実行まで行うようになると、企業は次の質問に答えなければなりません。
AIはどのようなデータにアクセスできるか？
どのようなシステムを呼び出せるか？
どのような権限で実行するか？
実行前に承認や検討が必要か？
実行過程と結果はどこに記録されるか？
問題が起きた時、誰が責任を持ち追跡できるか？
この質問に答えられなければ、AIは実験室と個人の生産性ツールに留まることになります。企業の核心業務に入るには、実行に伴う責任と統制が必ず必要です。
AI時代の核心課題は、AIをより賢くすることだけではありません。 AIが何ができ、何をしてはいけず、何をしたのか説明できるようにすることです。
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がどのリソースにアクセスし、どのような権限でシステムを呼び出し、その過程がどのように記録され監査されるかをリソースごとに統制します。
第3の軸は FDE(Field Domain Engineering)です。FDEは、顧客現場の業務を理解し、ドメイン知識を構造化して、AIが実際の成果を創出できる形に変える適用の軸です。
これら3つはそれぞれ単独の製品や機能としてのみ見ることはできません。AI Work OSという観点から見ると、AIPは実行を生み出し、ACPは実行を統制し、FDEは実行が実際の業務価値につながるようにします。
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拡張の流れ
AIP：実行の基盤
AIPは企業がAI Agentを作り、実行してみるプレイグラウンドです。
企業業務に合ったAI Agentを作るには複数の要素が必要です。LLMは判断と言語理解を担います。RAGは企業内部の文書と知識を検索し、回答の根拠を提供します。MCPはAIが外部システムやツールを呼び出せる接続構造を提供します。Skillsは特定の業務を実行するための手順と能力を定義します。Agentはこれらの要素を組み合わせて目的を持った実行フローを作ります。
AIP：企業業務システムをAI Agentとつなぐ実行プラットフォーム
構造的に見ると、AgentはLLMを基盤として判断し、MCP Gatewayを通じてDB、SaaS、内部システム、APIのような企業リソースを呼び出します。そしてこの実行はACPの統制の下で行われなければなりません。
MCP Gatewayを中心に複数のLLMと業務ツールを統制する構造
つまりAIPはAIが「考えて答える空間」ではなく、AIが企業業務の実行フローを構成し検証する基盤です。
Apps：実行を業務体験に変える接点
AIPは強力ですが、すべての顧客がMCP、Skills、RAG、Agentを直接理解し組み合わせることを望んでいるわけではありません。
顧客が知りたいのは技術構造そのものではありません。顧客が知りたいことははるかに現実的です。
「自分の業務でどのように使われるか？」
そこでQueryPieはAIPの上で業務単位のAppsを作っています。Lingo、YuhoNavi、NotePie、Outbound AgentのようなAppsは、AIの実行能力を会議、財務分析、ドキュメント作成、営業実行のような日常業務の中で体感させる接点です。
AIP Appsが業務自動化体験につながる方式
これらのAppsは単なるデモではありません。AI Agentが実際の業務の起点と成果物、承認フロー、記録構造の中に入ったとき、どのようなユーザー体験が必要かを検証する装置です。
AI Work OSにおいてAppsは技術を業務言語に変えるレイヤーです。
会議、財務、知識、セールス業務で実行されるAIP Appsの事例
Lingoを活用したグローバル顧客、パートナーコミュニケーションの事例
FDE：顧客現場の実際の価値を実装すること
企業の顧客はAI自体を求めているわけではありません。顧客が求めているのは自分の業務での効果です。
しかし実際の企業業務は文書を読むだけでは理解が難しいです。文書にない例外があり、担当者の暗黙知があり、古い業務履歴があり、顧客ごとの特殊条件があります。同じ用語でも部門によって意味が違い、同じプロセスでも現場では異なる運用がされます。
FDEはこの複雑な業務を理解し、ドメイン知識を構造化して、AIが実行可能な形に変える役割を果たします。
FDEが顧客ドメインとデータパイプラインを実行プロトタイプに変える流れ
例えばPayroll業務では、給与計算の例外と検証手順をAIが扱える構造に変えることが重要でした。Toyotaの事例では、複雑な仕様書の分岐を人が長く解釈していた業務からAIが迅速に判断可能なフローを作りました。見積書Agentは熟練営業担当者の暗黙知を組織の実行資産に転換する方向を示しました。財務自動化は1ヶ月近くかかっていた競合レポート作成業務を数分で処理可能な構造に変えました。
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
ACPは、AIがどのリソースにアクセスするか、どの権限で実行するか、その過程がどのように記録され監査されるかをリソースごとに統制します。データベース、SaaS、API、内部システム、ファイル、業務ツールなど、AIが呼び出すすべてのリソースが権限と監査の対象にならなければなりません。
データベースからMCPまで拡張されるEnterprise Access Control
AI時代の統制は、単に接続を許可または遮断する問題ではありません。実行のコンテキスト、権限の範囲、承認条件、記録と監査の可能性を共に設計する問題です。
製品セキュリティ、運用信頼性、監査追跡性、コンプライアンス認証を備えたプラットフォーム
結論：AI導入の核心は運営体系だ
AI導入の核心は、単にAIツールを使うことではありません。
新しい知能が働けるようにコンテキストを接続し、実際の業務で実行させ、その実行を安全に統制することが核心です。
AI Work OSは、この3つを共に扱う運営体系です。
AIPは、AIが働ける実行基盤を作ります。
Appsは、実行能力を実際の業務体験に変えます。
FDEは、顧客現場の複雑な知識をAIが実行可能な構造に変えます。
オントロジーは、個人のAI活用を組織の生産性へと拡張します。
ACPは、新しい知能のアクセスと実行を安全に統制します。
企業の中に新しい知能が入ってきています。今必要なのは、より多くのAIツールではなく、この知能が責任を持って働ける運営体系です。
その運営体系こそが AI Work OSです。
