AI 企業 OS のループを閉じるのは誰か：システムによる自己調整か、責任者の署名か

GembaOS は、AI エージェントを職務権限規程・稟議・監査のもとで運用するための実行基盤です。ポリシーによる権限判定、パラメータに紐づくワンタイム許可証、人の承認記録を、オンプレミスまたはプライベート VPC 上で提供します。

この記事は、現在シリコンバレーで最も注目を集めているテーゼへの直接の応答です。Y Combinator は 2026 年夏の創業支援テーマ（Requests for Startups）において、Diana Hu による『企業のための AI オペレーティングシステム（The AI Operating System for Companies）』を発表しました：

「私たちが目にする最高の AI ネイティブ企業は、多くの企業がまだ気づいていない事実を掴んでいます。それは『会社全体を照会可能（Queryable）にした』ということです。すべての会議が録音され、すべてのチケットが追跡され、すべての顧客対応が記録され、そのすべてを学習するインテリジェンス層から読み取り可能になっています……閉じたループの中で、システムは現在起きていることを監視し、起きるべきことと比較し、自己調整（Adjusts）します……私たちは、企業をデフォルトで『AI から可読（Legible to AI by default）』にする結合層の構築に大きな勝機があると考えています。」

この論述には 4 つの動詞が含まれています。**記録（Record）、監視（Monitor）、照合（Compare）、そして調整（Adjust）**です。GembaOS は前の 3 つには完全に同意します。しかし、4 つ目の「システムが自己調整する」という点、そして「企業をデフォルトで AI に開放する」という前提には、意図的かつ根本的に反対します。

なぜなら、その前提は大企業のセキュリティ、秘密区分、そして法規制と正面から衝突するからです。

エンタープライズの現実：なぜ「デフォルトで AI に可読」は即座に違反となるのか

15 人のソフトウェアスタートアップであれば、Slack、Linear、GitHub、会議録音のすべてをひとつの AI モデルに読み取らせることは、驚異的な開発スピードをもたらすでしょう。しかし、売上数千億円規模の金融機関、病院グループ、グローバル製造業において、それを実行すれば翌日には重大なセキュリティインシデントと監査失格を招きます。

1. 機密区分と知悉範囲（Need-to-Know）の壁

企業の情報は、決して平坦な一枚岩のナレッジベースではありません。企業活動は、法規と社内規程に裏打ちされた厳格な情報区分によって守られています：公開（Public）、社内限定（Internal）、機密（Confidential）、そして極秘（Strictly Restricted）です。

• 取締役会における未公開 M&A や事業売却の審議内容；
• 役員・社員の評価、報酬、ストックオプション、懲戒履歴；
• 内部通報の告発内容や不正調査ファイル；
• 弁護士・依頼者間特権（Attorney-Client Privilege）に保護された訴訟戦略。

もし会社全体のやり取りを未分別のインテリジェンス層に吸い上げさせた場合、横方向の権限昇格（Lateral Privilege Escalation）をどう防ぐのでしょうか。若手エンジニアのコーディング支援 AI が「来期の部門再編と人員削減の計画を要約して」と尋ねたとき、区分を持たないモデルは役員会議の生々しい議論を平然と要約してしまいます。

GembaOS では、「デフォルトで AI に可読」な情報など存在しません。情報の知悉範囲（Need-to-Know）は、業務アクションの実行権限と同じ職務権限規程（Delegation of Authority）によって厳密に統制されます。権限のないエージェントが機密文書を照会した場合、カーネルは「403 Forbidden」ではなく、文書の存在自体の推測を遮断するために**「404 Not Found」**を厳格に返答します。

2. 顧客データ保護とモデルデータ越境防止（Egress Ceiling）

YC 論文が掲げる「すべての顧客対応を記録し学習させる」という構想も、法規制の現場で即座に頓挫します。個人情報保護法、GDPR、金融庁監督指針（FISC 安全対策基準）のもとで、顧客の通話音声、口座番号、医療記録などの生データを、外部の汎用大規模言語モデルやマルチテナントのクラウドベクトル検索へ直接流し込むことは厳禁とされています。

大手企業の鉄則は明確です：「顧客データはプライベート VPC または自社データセンターの境界から一歩たりとも出してはならない」。

GembaOS はオンプレミスまたはプライベート VPC 内に展開され、強固な**「モデルデータ出境上限（Model Egress Ceiling）」**を強制します：

• 顧客の生データ、音声、契約書面は、隔離されたセキュアな業務基盤内にのみ留まります；
• 生データが外部モデルの学習プールや共有コンテキストへ送信されることは一切ありません；
• 推理モデルへ送られるのは、個別の起案に必要な、匿名化・無害化された最小限の構造化パラメータのみです。

思想の合流：GembaOS が同意し、すでに実装している 3 つの動詞

全面開放という危険な幻想を排したとき、Diana Hu 氏が指摘した運用ループは、エンタープライズの自動化が目指すべき姿を確かに射抜いています：

記録し、監視し、照合する。このループは不可欠です。決定的な違いは、**「誰がそのループを閉じるのか」**という点です。

第 4 の動詞：なぜシステムが自らの権限を「自己調整」してはならないのか

YC 論文では、*システムが調整する（The system adjusts）*と書かれています。しかし GembaOS では：システムが提案（Proposes）し、人間が調整（Adjusts）し、その調整自体が台帳に刻まれる署名付きアクションでなければなりません。

これは学習を禁じるという意味ではありません。与えられた権限の範囲内であれば、エージェントは仕事の質を上げ続けます。読める情報を読み、下書きを作り、手順やルールの変更を提案します。決してできないのは、権限そのものを変えることです。誰が押印するか、どの条件なら押印なしで進めるか、何に触れてよいか。これらは人が決めます。

誰が社内で何をできるかは、機械学習の振る舞いから推論させてはなりません。どの金額でどの承認帯が選ばれ、誰が押印し、実行前にどの項目を照合するかは、職務権限規程において明示的にコード化されるべき宣言です。

AI は不足台帳を通じて規程の変更案を提案できます。GembaOS コンパイラは、現行規程と提案規程の差分を正確に出力し、その変更の方向性を明示します：緩和（Looser）（承認者の削減や自動化枠の拡大）、厳格化（Stricter）、あるいはロールの閲覧権限の変更。

指名された責任者がその差分を確認し、変更履歴にデジタル署名を付与します。規程はバージョン管理システムで管理されているため、合意の証跡とコード差分は、ソフトウェアのピアレビューと全く同様に隣り合って保存されます。

これこそが閉じたループです。しかしそれは、「人の名前で閉じるループ」です。

これは形式的な官僚主義ではありません。Diana Hu 氏の例はソフトウェアエンジニアリング組織です：スプリント期間が半減し、2 倍のコードがリリースされる。1 年後、スプリントの進行許可を誰が出したかを法廷で問われることはありません。

しかし GembaOS が統制するループは、返金、保険金支払い、特採放行、退職者のアカウント剥奪、本番データベースの変更です。ここではすべての誤ったアクションに金銭的・法的な代償が伴い、事後に必ず「誰がこれを許可したのか」が監査されます。

もしシステムが権限を自己調整していた場合、監査人に対する唯一の回答は*「アルゴリズムが状況を見て自分で限度額を広げました」*となります。これはあらゆる内部監査において即座に重大インシデントと判定される禁忌です。自らの権限を調整するループは企業の武器ではなく、監査によって暴かれる最大の脆弱性です。

権限はコードレビューされるべきものであり、推論されるべきではありません。GembaOS の提案側は学習によって賢くなりますが、権限側は厳格に静的設定され、その変更自体が署名された監査対象のアクションです。ルールに責任を持つ人が、そのルールが効いているかをどう確かめるか（抽出点検の回答、案件終了後の結果、比率の変動、ルール自身に書いた一時停止）、そして変更を広げる前にどう試すかは、「そのルールは効いているか」にまとめました。

GembaOS はループのどこを担うのか

YC 論文は、「Slack、Linear、GitHub、Notion、通話録音など十数個のツールをつなぎ合わせる過酷な統合労働」について述べています。

それはループの**入力・集約側（Ingesting end）**です。GembaOS はその領域で競合しません。

GembaOS が担うのは**実行・アクション側（Acting end）**です。集約層が学んだ知識が基幹システムへの書き込みへと変わる瞬間、稟議書、人の押印、ワンタイム許可証、そして改変すれば検知できる監査記録を課す最後の防壁です。

この二つの終端は、Model Context Protocol（MCP）を通じて双方向につながります：

• LangGraph や CrewAI で構築された既存のエージェントは、ツールの接続先を GembaOS ゲートウェイに向けるだけで、コードを書き直すことなくゼロトラストの関門を獲得できます；
• GembaOS の背後にあるレガシー基幹システムは、標準的な MCP ツールとして公開され、既存の社内 AI から安全に呼び出せるようになります。

まとめ

GembaOS は、社内の機密対話や顧客データを未分別のまま外部モデルに学習させることはありません。それはゼロトラストの思想と真っ向から矛盾するからです。また、AI エージェントが都合の良いメトリクスを盾に、自分自身の実行権限を勝手に拡大することも断じて許しません。

照会可能な会社（Queryable Company）は、何が起きたかを教えてくれます。そして人の名前で閉じるループ（Signed Loop）だけが、誰が責任を負ったのかを証明できるのです。