「AIエージェントを作れと言われたのですが、また新しいツールを契約するのかと思うと気が重いです」
「Copilot Studio と Codex と Gemini Enterprise、何がどう違うのか、社内に説明できません」
「自動で動かすのは正直まだ怖いです。どこまで任せていいのか、判断する基準がありません」
社内のAI活用の相談をいただくと、この3つはほぼ毎回出てきます。
そして多くの場合、いちばん先に必要なのは製品の比較表ではありませんでした。
結論：社内AIエージェントを作る場所は、いま払っている契約の中にある
社内AIエージェントとは、社内の手順やデータに沿って、人の代わりに調べる・書く・実行するところまでを受け持つAIのことです。3社の公式ドキュメントを読むかぎり、Microsoft・OpenAI・Google はいずれも、それを作る場所を既存の業務基盤の上に置いているように見えます。
だから最初に決めるのは製品ではなく、どこで人が確認するかと、誰のアカウントで動かすかの2つです。
この2つは、3社の公式ドキュメントに書かれている事実だけで決められます。
この記事で持ち帰れること
- 3社が「エージェントを作る場所」をどこに置いているか（公式ドキュメントの記述ベース）
- Copilot Studio の課金が、機能ではなく実行基盤の選択で変わるという公式の明記
- Codex の定期実行が既定では無人で走り、管理側の設定次第で承認挙動に戻るという公式の記述
- 同じ機能名でも、使う場所（Web版／デスクトップ版）で触れる範囲が変わること
- 弊社が自社の無人ジョブで実際に踏んだ失敗と、何を任せていないか
社内AIエージェントとは何か｜3社が「作る場所」をどこに置いているか
3社の公式ドキュメントは、自分たちの位置づけをそれぞれこう書いています。
Microsoft Copilot Studio は、公式の概要ページで「a graphical, low-code studio for building and managing AI-powered agents and workflows」と説明されています。作れるものについては「Copilot Studio supports several building blocks」とされ、その building block として Agents・Workflows・Agent flows がそれぞれ説明されています。
OpenAI の Codex には、Automations のドキュメントがあり、「run tasks on a schedule or from supported app events in ChatGPT」と書かれています。ChatGPT の中で、スケジュールまたは対応アプリのイベントからタスクを走らせる仕組みです。
Google の Gemini Enterprise のドキュメントは、自身を「an intranet search, AI assistant, and agentic platform」と位置づけています。「empowers knowledge workers with generative AI and agentic workflows by leveraging data sources from across your organization」とも書かれており、社内のデータソースを前提にした設計です。カスタムエージェントをホストでき、既製エージェントをまとめた Agent Gallery も用意されています。
| 製品 | 公式の位置づけ（原文） | 作る／動かす単位 |
|---|---|---|
| Microsoft Copilot Studio | a graphical, low-code studio for building and managing AI-powered agents and workflows | building block として Agents・Workflows・Agent flows を説明 |
| OpenAI Codex（Automations） | run tasks on a schedule or from supported app events in ChatGPT | 時刻起動またはイベント起動のタスク |
| Google Gemini Enterprise | an intranet search, AI assistant, and agentic platform | カスタムエージェントのホストと Agent Gallery |
3つを並べると、どれも「まったく新しい何か」ではなく、すでに使っている業務基盤の延長に置かれていることが分かります。
なお Gemini Enterprise の概要ページには、エージェントの作成手順やガバナンスの具体、技術的な上限までは書かれていません。この記事でもそこには踏み込みません。
課金は機能ではなく「実行基盤」の選択で決まる
ここがいちばん見落とされやすいところだと感じています。
Copilot Studio の概要ページには、「The harness you use affects the billing, features, and capabilities of what you build.」と明記されています。使う harness が、課金と機能と能力に影響する、という書き方です。
harness の解説ページでは、harness は「a runtime that exists between the two: it determines when to call the model, what components to send it, interprets what comes back, and calls the right tools」と定義されています。モデルとツールの間にあるランタイムで、いつモデルを呼ぶか、何を渡すか、返ってきたものをどう解釈して、どのツールを呼ぶかを決める層です。
用意されているのは3種類です。
| harness | 公式に書かれている性格 | 課金 | 問題からの復帰 |
|---|---|---|---|
| GitHub Copilot harness | the most capable option。connectors・knowledge・MCP・connected agents をまたいでツールを呼び、Word・Excel・PowerPoint・PDF をネイティブに作成・編集できる。skills と memory に対応。runs each task in a secure sandbox governed by Copilot Studio | Copilot Credits を消費 | Retries and finds alternative paths automatically |
| standard harness | トピック・プロンプト・経路を自分で定義して、予測可能に動かすルールベース | — | Follows the paths you’ve built |
| Copilot chat harness | Microsoft 365 Copilot Chat の拡張として動く | Billing is consumption-based or included in Microsoft 365 Copilot user subscription license | — |
つまり選ぶのは機能ではなく harness で、その選択に課金がついてきます。
もうひとつ、公式が但し書きを置いているほど誤解されている点があります。同じページに「The GitHub Copilot harness is a Microsoft Copilot Studio authoring and orchestration framework, not the GitHub Copilot service.」と書かれており、「customer data isn’t sent to or processed by the GitHub Copilot service when agents run in Copilot Studio」とも続きます。名前は GitHub Copilot ですが、GitHub Copilot というサービスそのものではない、ということです。
金額そのものは、この記事では書きません。見積もる段階になったら Copilot Studio のライセンスのページを開いて、自社の契約と突き合わせるのが確実だと考えています。
無人実行は承認を挟まない｜公式にそう書いてある
Codex の Automations のドキュメントには、「Scheduled tasks run unattended with your default sandbox settings」と書かれています。定期実行されるタスクは、既定のサンドボックス設定のまま無人で走る、ということです。
ただし同じページには条件も書かれています。「Scheduled tasks use approval_policy = "never" when your organization policy allows it. If admin requirements disallow approval_policy = "never", scheduled tasks fall back to the approval behavior of your selected permission mode.」——組織のポリシーが許す場合に承認なしで動き、管理者の要件がそれを許可しない場合は、選んでいる permission mode の承認挙動に戻ります。つまり承認が入るかどうかは、管理側の設定で変わります。
起動のしかたは2系統あります。
- 時刻起動：チャットの中に置く定期タスクは「minute-based intervals for active follow-up loops, or daily and weekly schedules」と説明されています。独自の周期が要るときは custom schedule controls を使い、さらに細かく指定する場合は RFC 5545 の recurrence rule（RRULE）を編集します
- イベント起動：Gmail の新着、選択した Slack チャンネルの新着、GitHub の pull request の動き
ただしイベント起動には条件があります。公式には、イベント起動は web とモバイルのみで、「Desktop app, Codex CLI, or the IDE extension」では使えないと書かれています。また、1つのタスクに複数のイベント起動を付けることはできますが、時刻起動との併用はできません。
一方 Copilot Studio は、人の確認を製品側の機能として持っています。概要ページでは Workflows について「built-in testing and human-in-the-loop controls for enterprise-ready automation」、Agent flows について「can run prompts, call agents, and include human review steps」と説明されています。
同じ「自動化」でも、人の確認をどこに置くかの考え方が違う、という読み方になります。承認を内側に置けない設計のまま無人実行するなら、確認の関門は外側に自分で作るしかないと考えています。
どこで動かすか・誰のアカウントで動かすかで、触れる範囲が変わる
Codex は、同じ機能名でも版によって触れる範囲が違います。公式ドキュメントによると、デスクトップ版はローカルで動き、「run in the project directory or an isolated worktree」と書かれています。対して Web版は、アップロードした文脈や接続済みのツールは使えるものの、「they can’t work directly in a folder on your computer」とされています。PC上のフォルダを直接は触れない、ということです。
運用上の注意も書かれています。「frequent schedules can create many worktrees over time」——実行頻度を上げると worktree が増えていくため、掃除が必要になります。サンドボックスは既定の設定で動き、full-access にするとリスクが上がる点も明記されています。
誰のアカウントで動かすかについては、Copilot Studio 側に踏み込んだ記述があります。「Some agents can be given their own account so they can work proactively on tasks and take part in shared business processes」——エージェントに専用のアカウントを与えられる、という書き方です。運用面では Analytics・Evaluations・Administration が用意され、Administration には「role-based access and cost management」と Agent inventory が挙げられています。
Gemini Enterprise については、エディションが複数あることがドキュメントに示されています。Business Edition と、Standard / Plus / Pay-as-you-go / Frontline です。どのエディションを持っているかで前提が変わるため、社内に入れる前に自社の契約内容を確認しておくのが安全だと考えています。
自動化をどこまで伸ばすかという線引きについては、Google Apps Script で業務システムを作るときの限界でも同じ論点を扱っています。
部署別の使いどころ｜まず1つの作業に当てる
ここから先は公式仕様の読み方ではなく、弊社の判断です。
最初から全社に広げると、どこで止まったのかが分からなくなります。1部署・1作業から始めるのが結果的に速いのではないでしょうか。
| 部署 | 最初に当てる作業 | 人が確認する位置（弊社の推奨） |
|---|---|---|
| 営業 | 訪問先の下調べと、アプローチ文の下書き | 送信の直前。送信そのものは人が押す |
| 総務・管理 | 申請書や社内規程の問い合わせ対応（社内検索） | 回答テンプレートの承認時。個別回答は都度確認 |
| 経理 | 請求データの突き合わせと、差異のリストアップ | 仕訳の確定前。計上は人が押す |
| 製造・在庫 | 在庫の日次サマリと、下限を割った品目の抽出 | 発注の直前。発注は人が押す |
| 情報システム | 不具合の一次調査と、原因候補の整理 | 本番へ反映する直前。反映は人が押す |
並べてみると、人が確認する位置はどれも同じところに来ます。外に出る直前と、本番が変わる直前です。
業務システムそのものを作り直したほうが早い場合もあります。その判断は業務システム開発のサービスページ側で扱っています。
CodeClimbの見解
ここからは弊社の解釈と、自社で実際に起きたことです。
任せていないこと
弊社は無人で動くジョブに、次の4つを任せていません。
- 外部への送信
- 公開
- 本番環境の置き換え
- 課金が発生する操作
このブログ記事の制作も無人ジョブが回していますが、任せているのは下書きまでです。公開の判定には別のチェックを通していて、そこを通らなければ下書きのまま残ります。
怖いのは失敗ではなく、失敗が届かないこと
正直、いちばん痛かったのは失敗そのものではありませんでした。
弊社の定期ジョブは、2026年9月28日から30日の3晩、起動していませんでした。そして健全性チェックの異常一覧には、一度も載りませんでした。失敗したジョブは載るのに、起動しなかったジョブは載らない作りだったためです。
通知の側にも問題がありました。通知を送る行が || true で終わっていて、通知そのものが失敗しても、それを捨てていた時期がありました。
他にも、モデルの指定を省いたために意図しない既定モデルを拾った件、環境変数ファイルの export 漏れで子プロセスがハングした件、認証が切れて全自動ジョブが止まった件があります。どれも「動いているように見えて、何も進んでいない日」を作りました。
だから無人実行を置くときは、動かす設計と同じ重さで、止まったことが人に届く経路を作るべきだと考えています。
足すより減らすほうが効くこともある
エージェントの話をしていると、つい何かを足す方向に寄ります。ただ弊社の経験では、減らしたほうが効いた例のほうがはっきりした結果になりました。
ミラフル株式会社の案件では、外部SaaS 3サービスを撤廃して自社開発のシステムへ移行しました。2026年1月1日の切替で、月9万円・年間で約108万円の削減になっています。
株式会社NeCoNeの案件では、複数拠点の在庫を kintone 7アプリで一元管理する形にしました。狙ったのは機能を増やすことではなく、「誰が入力しても同じ形式のデータになる」構造にして、担当者が変わっても運用が続く状態にすることでした（事例の詳細）。
弊社自身の見積書・請求書の作成も、1件15分かかっていたものが1分もかからなくなりました。新しいソフトを入れたからではなく、入力する場所を1か所に減らしたからです。
このあたりの「属人化したものを減らして直す」考え方は、原価管理がExcelで崩れる理由にも書いています。
まとめ
社内AIエージェントは、新しい契約を増やす前に、いま払っている契約の中に作る場所があります。
そのうえで先に決めるのは、次の2つだと考えています。
- どこで人が確認するか：Copilot Studio は human-in-the-loop controls や human review steps を機能として持ちます。Codex の定期実行は既定のサンドボックス設定のまま「run unattended」と公式に書かれており、承認が入るかは管理側の設定で変わります。内側に置けないなら、外側に作る
- 誰のアカウントで動かすか：Copilot Studio はエージェントに専用アカウントを与えられると明記しています。個人アカウントのまま置くと、権限変更や認証切れで止まります
課金は機能ではなく harness の選択で変わる、という公式の記述も、見積もる前に押さえておきたいところです。
そして、動かす設計と同じだけ、止まったことが届く経路に手をかけてください。正直ここを軽く見て、弊社は3晩気づきませんでした。
よくある質問
Q. 社内に開発できる人がいません。それでもエージェントは作れますか。
Copilot Studio は公式に「low-code studio」と位置づけられており、standard harness ではトピックや経路を自分で定義して予測可能に動かす作り方ができます。ただ、作れることと運用が続くことは別だと考えています。止まったときに誰が気づいて誰が直すのか、そこまで決まっていないなら、最初の1本は外部と一緒に組んだほうが早いのではないでしょうか。
Q. 既存のツールを社内から呼び出せますか。
Copilot Studio の GitHub Copilot harness については、connectors・knowledge・MCP・connected agents をまたいでツールを呼ぶと公式に説明されています。Codex のイベント起動は、Gmail の新着・選択した Slack チャンネルの新着・GitHub の pull request の動きに対応しています。ただし Codex のイベント起動は web とモバイルのみで、デスクトップアプリや CLI、IDE 拡張では使えないと明記されています。呼べるかどうかは、製品名ではなく「どの版を使うか」で変わります。
Q. 毎晩自動で走らせたいのですが、何から準備すればいいですか。
実行そのものより、確認と通知のほうを先に用意することをおすすめします。定期実行は既定では無人で走るため、外に出る操作・本番を変える操作・課金が発生する操作を止める関門が必要になります。あわせて、ジョブが「起動しなかった」ケースも検出できる監視にしておいてください。弊社は失敗しか見ていなかったため、3晩気づきませんでした。
自社の契約の中で、どこまで任せられるか整理します
CodeClimb は、自社の業務をAIで回しながら、企業のAI導入とシステム開発を支援しています。売る側ではなく作る側の立場で、いま払っている契約の中でどこまでできるか、どこから人が確認するべきかを一緒に整理します。
- 何を任せて何を任せないかの線引きから入りたい場合 → AI導入支援・AI構築代行
- 業務システムそのものを作り直したほうが早いと感じている場合 → 業務システム開発・DX支援
現状のヒアリングから承ります。お問い合わせはこちらからお気軽にご相談ください。
出典
https://learn.microsoft.com/en-us/microsoft-copilot-studio/fundamentals-what-is-copilot-studio ｜ Microsoft Learn ｜ 2026年9月
https://learn.microsoft.com/en-us/microsoft-copilot-studio/harnesses-overview ｜ Microsoft Learn ｜ 2026年9月
https://learn.chatgpt.com/docs/automations ｜ OpenAI Codex ドキュメント ｜ 参照 2026-10-01
https://docs.cloud.google.com/gemini/enterprise/docs ｜ Google Cloud ｜ 2026年9月
https://learn.microsoft.com/en-us/microsoft-copilot-studio/billing-licensing ｜ Microsoft Learn ｜ 参照 2026-10-01
