エージェントが、エンジニアの机から離れた
homulaは、エンタープライズ企業のAIエージェント導入を、技術選定から接続・承認・監査まで一気通貫で設計するAIインテグレーターです。本稿で取り上げるのは、「誰がエージェントを使うのか」という前提そのものが、この6月に動いたという話です。
これまでAIコーディング・エージェントは、ほぼ定義上「開発者の道具」でした。ところが2026年6月2日、OpenAIはCodexに6つの職種別プラグイン、自然言語から社内アプリを生成する**「Sites」、そして文書・表計算・スライドにまで広がった「Annotations」**を投入し、Codexを「ソフトウェア開発のツール」から「あらゆる職種の知的労働のツール」へと明確に押し広げました（OpenAI: Codex for every role, tool, and workflow）。
この変化は、単なる新機能リリースではありません。アナリスト・営業・デザイナー・投資担当といった非エンジニアが、自然言語で自分の業務アプリを「作る」側に回る——いわば「シチズン開発」の第二幕が、エージェントを土台に始まったということです。本稿は一次情報で事実を確認したうえで、この転換が日本企業の統制と運用設計に何を突きつけるのかを読み解きます。
何が発表されたのか——Codexの「全職種」化
まず事実関係を整理します。OpenAIの発表（6月2日）と複数の報道で確認できる主要点は次の通りです。
| 項目 | 内容 |
|---|---|
| 利用規模 | Codexの週間利用者は 500万人超。デスクトップアプリ公開（2026年2月）から 6倍超 に成長 |
| 非エンジニア比率 | 全利用者の 約20% が非開発者。その増加は開発者の 3倍超 の速さ |
| 職種別プラグイン | 6種: 営業 / データ分析 / プロダクトデザイン / クリエイティブ制作 / 投資銀行 / 公開株式投資 |
| 同梱範囲 | プラグインは 62の人気アプリ と 110のスキル を束ねる |
| Sites（プレビュー） | プロンプトから、共有可能なダッシュボード・企画ボード・レビュー用ワークスペース等の社内アプリを生成。URLで社内共有 |
| Annotations | コード・サイトに加え、文書・スプレッドシート・プレゼンへ対象拡大 |
非エンジニアの内訳としてOpenAIは、アナリスト、マーケター、オペレーター、デザイナー、リサーチャー、投資家、バンカーを挙げています（OpenAI、VentureBeat）。さらに今後、コーポレートファイナンス、プライベートエクイティ、マーケティング戦略、戦略コンサルティング、法務といった職種別プラグインの追加も予告されています（Reworked）。
ここで起きているのは、ツールの「対象読者」の入れ替えです。コード補完を売りにしてきたエージェントが、**「営業がパイプライン管理の小ツールを自分で作る」「アナリストが分析結果をそのままダッシュボードにして配る」**という用途に最適化され始めた。プラグインという形で、職種ごとに必要なアプリ・スキル・指示・ワークフローが最初から束ねられているのが象徴的です。
なぜこれが転換なのか——「シチズン開発2.0」
この動きを正しく捉えるには、過去の「シチズン開発（市民開発）」と比べるのが早道です。
ローコード／ノーコードが掲げた第一幕のシチズン開発は、「現場の非エンジニアが、画面を組み立ててアプリを作る」というものでした。しかしそこには、ツールの作法を学ぶコストという壁が残りました。コンポーネントの配置、データ連携の設定、条件分岐の組み方——結局は「簡易プログラミング」を覚える必要があり、本当に作れる人は限られていた。
エージェントを土台にした第二幕は、この壁の置き場所を変えます。作法を覚えるのではなく、やりたいことを言葉で伝える。Codex Sitesは「プロンプトから社内アプリをホスティング込みで生成する」機能であり、Annotationsは「最初のドラフトの後に、文書や表計算に対して判断・修正・反復を重ねる」ためのものです（OpenAI）。作る側に求められるのは、ツールの習熟ではなく業務の言語化になりました。
重要なのは、これがOpenAI単独の動きではないことです。AnthropicのClaude Codeが開発の自律化を進める一方、Microsoftはエージェントを業務に常駐させる枠組みを整えています。各社が同時に「エージェントを全職種へ」と動いている事実は、これを一過性の機能ではなく市場の構造変化として読むべきだと示唆します。同じ流れは、OpenAIのワークスペース・エージェントが「チームで共有するAI」を業務に置いたことにも表れていました。
非エンジニアが約20%・開発者の3倍超の速さで増えているという数字は、この壁の移動が現実に効いている証拠です。エンジニアでない人が、自分の手で業務ツールを生み出し始めている。生産性の観点では大きな朗報ですが、企業の統制という観点では、ここから新しい宿題が始まります。
企業に生まれる3つの新しい論点
「全職種がアプリを作れる」状態は、便利さと裏腹に、情報システム部門とガバナンス担当に次の3点を突きつけます。
1. 「シャドーアプリ」の発生。非エンジニアが自然言語で社内ツールを量産できるということは、IT部門の管理外で、業務アプリが無数に生まれうるということです。かつて部門ごとのSaaS乱立が「野良AI」を招いたのと同じ構図が、今度は「現場が作ったエージェント製アプリ」という形で再来します（「野良AI」が企業を蝕む）。誰が・何を・どのデータを使って作ったのかが見えなければ、棚卸しも統制もできません。
2. データ接続の権限設計。職種別プラグインは62のアプリ（Snowflake、Salesforce、Figmaなどが報じられています）を束ねます。便利な反面、エージェントが基幹データや顧客情報にどこまで触れてよいかという権限境界が、利用者の数だけ問われることになります。OpenAI自身、Business／Enterpriseワークスペースでは管理者がアプリ権限を制御でき、Sitesはエンタープライズ／教育向けに既定オフで、RBACと権限設定から有効化する設計としています（OpenAI Developers: Codex permissions）。裏を返せば、権限を最初に設計しない限り、接続は容易に広がりすぎるということです。
3. 成果物の品質と監査。自然言語で作ったアプリやダッシュボードは、ロジックの正しさ、計算の妥当性、機密の取り扱いが「作った本人の言語化能力」に依存します。誰がいつ何を作り、どのデータに基づいて意思決定に使われたのか——**後から検証できる記録（監査ログ）**がなければ、現場の生産性は上がっても、説明責任は宙に浮きます。
ここで陥りやすいのは、「便利だから全員に開放」か「危険だから全面禁止」かの二択に倒れることです。前者はシャドーアプリの氾濫を、後者はせっかくの生産性を殺します。正解は二択の外側、すなわち**「誰が・どの業務で・どのデータと権限で作れるか」を設計したうえで開放する**ことにあります。統制は、開放のブレーキではなく、開放を安全に速くするための前提条件です。
homulaの観点——接続を集約し、統制を一元化したうえで開放する
非エンジニアがアプリを作れる時代の勝ち筋は、「現場に丸投げ」でも「IT部門が抱え込む」でもありません。接続と統制の土台を一元化し、その上で安全に現場へ開放することです。homulaは特定ベンダーに寄り切らないインテグレーターとして、この土台づくりを支援します。
第一に、接続の集約です。AgensはMCPを活用し、200以上のツールと構築ゼロで接続する共通基盤を提供します。職種別プラグインのように接続が各所で個別に広がる前に、社内システムやSaaSへの接続を一面に集めておくことが、「誰が何につながっているか」を見える状態に保つ前提になります。
第二に、統制の一元化です。Agens Controlは、承認フロー・DLP・RBAC・5年分の監査ログを、利用するエージェントやフレームワークをまたいで一貫して効かせます。非エンジニアが作ったアプリであっても、機密データに触れる操作には承認を挟み、権限を役割で定め、すべての実行を後から監査できる——シャドーアプリの氾濫を防ぐ鍵は、ツールごとの設定ではなく、横断的な統制面にあります。これはランタイム・ガバナンスの標準化とも一直線につながる論点です。
第三に、開放の順序設計です。homulaが活用する n8n / Dify / LangGraph などの基盤を用いれば、現場が自由に作れる領域と、IT部門が管理すべき領域を分けて設計できます。どの業務から非エンジニアに開放し、どこに承認と監査を置くか——その当てはめとROI試算は、業務棚卸し・プロトタイプ構築を3〜5日（最短5日でPoC）で行うAIエージェント・ブートキャンプで素早く見極められます。統制を最初に設計した業務ほど、安心して現場に渡せ、処理時間の大幅な削減（過去には93%削減の例も）まで到達しやすくなります。月額30〜80万円規模の小規模検証から、統制を保ちながら段階的に広げるのが現実的です。
まとめ
2026年6月2日、OpenAIはCodexに6つの職種別プラグイン、アプリ生成機能「Sites」、対象を広げたAnnotationsを投入し、エージェントを「開発者の道具」から「全職種の道具」へ押し広げました。非エンジニアはすでに利用者の約2割を占め、開発者の3倍超の速さで増えています。**自然言語で社内アプリを作れる「シチズン開発2.0」**が現実になりつつあるのです。
この変化が日本企業に問うのは、「便利なツールを入れるか否か」ではありません。**「全職種がアプリを作れる前提で、誰が・どの業務で・どのデータと権限で作れるかを設計しているか」**です。接続を集約し（Agens）、権限・承認・監査を一元化し（Agens Control）、そのうえで開放の順序を決める——この土台を先に整えた企業から、現場の創造性を解き放ちながら、シャドーアプリの氾濫を避けて前に進めます。
エージェントを全職種に開くなら、「誰が・どの業務で・どのデータと権限で作れるか」を、開放の前に統制として固めておくのが近道です。自社の業務とリスク要件に合った開放の設計を、早めに整理することをおすすめします。