ドキュメント

AI Work OS: 新たな知能が企業内で働く方式

Sam Kim / CTO

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ヶ月近くかかっていた競合レポート作成業務を数分で処理可能な構造に変えました。