Basisは初日のオンボーディングを2時間から30分に短縮し、Clayは毎日およそ1時間分の受信トレイ整理を減らしました。しかし、3社が実際に再利用したのはプロンプトではなく、業務の順序・状態・完了条件でした。
30分の鍵は対話ではなく、作業仕様です
Basisの事例の核心は、オンボーディングの案内をチャットボットに任せたことではありません。人が一度実演した手順を、開始条件、順序、必要なツール、完了条件を備えたスキルに変えたことです。新入社員は初日にCodexと会社専用のオンボーディングスキルを受け取り、エージェントは会社の主要概念を説明しながら、コンピューター統合の設定をバックグラウンドで処理します。OpenAIが公開した企業事例によると、このプロセスにより初日のオンボーディング時間は2時間から30分に短縮されました。
ここでいうスキルは、気の利いたプロンプトの寄せ集めではありません。OpenAIの製品ドキュメントでも、スキルは再利用可能な指示として説明されており、組織管理者は作成・使用・共有・インストールの権限を役割ごとに管理できます。 つまり、スキルを運用資産にするには、少なくとも誰が所有し、誰が実行し、どの変更を次の入社者から適用するのかを決める必要があります。
Basisが例外をなくしたわけでもありません。繰り返される質問や新しい例外が生じればHRがスキルを更新し、複雑な質問には人が介入します。Basisは本業である会計エージェントでも、自律作業の後に重要な判断ポイントで会計士が参加し、成果物をレビューすると明らかにしています。このことから、この会社のパターンは「無人自動化」よりも、反復区間を機械が実行し、判断区間を人が担う構造に近いといえます。
オンボーディング文書をそのまま入れるだけでは足りない理由
文書は何を知る必要があるかを説明しますが、ワークフローはどの画面で何を確認し、どの状態になれば完了なのかまで定めます。「Slackを設定してください」ではなく、「会社メールでログイン → 必須チャンネル5つへの参加を確認 → 通知設定を確認 → 失敗時は停止理由をIT担当者へ送る」のように書くことで、実行と検査が可能になります。
3社は異なる「業務状態」をエージェントに引き渡しました
3つの事例の違いは、自動化した部署ではなく、エージェントが記憶し前に進めるべき状態の種類です。
| 会社 | 引き渡した業務状態 | エージェントの成果物 | 人に残した意思決定 |
|---|---|---|---|
| Basis | 順序が安定したオンボーディング手順 | 説明と統合設定の完了 | 例外処理、文化、サポート |
| Clay | 絶えず変化するアカウント別の文脈 | 毎日更新されたフォルダと優先アクション | 根拠確認後に顧客へ働きかけること |
| Exa | 発見した統合機会の進行状態 | テスト済みPRと告知ドラフト | 優先順位、約束、デプロイ承認 |
Clayは、CRM、メール、Slack、通話、プレゼン資料などに散在する取引の文脈を、アカウント別のワークスペースと専任サブエージェントに集めました。サブエージェントは毎晩一次資料をレビューしてアカウントフォルダを更新し、調整エージェントは毎朝、顧客の質問への回答や購買委員会の空席探しといった優先アクションを選びます。ClayがOpenAIに明かした削減時間は、毎晩およそ1時間です。
この構造で重要なのは「要約」よりも、次の実行にも残る状態です。ClayのAccount Agents公式ページでも、過去の接点、取引、通話、結論を基に次のアクションを選び、その結論と推論を再びアカウントに記録すると説明されています。実行可能なアクションも管理者が許可した範囲内で選択され、CRM記録や担当者への通知といった作業は人の承認構造で設定できます。
Exaはさらに一歩進みます。リポジトリと開発エコシステムから統合機会を見つけ、関連する文脈を集め、PRを作成し、テストを実行し、週次更新と初期告知まで準備します。ただし、実際のデプロイ前には人がレビューし、どの機会に投資するか、外部パートナーに何を約束するかはチームが決めます。 Exaのコード検索自体も、GitHubリポジトリ、ドキュメント、Stack Overflowにある実際のコード例を意味ベースで探すよう設計されており、この探索段階の基盤になります。
成果数値は購入の根拠ではなく、自社実験のベースラインです
2時間から30分、1日およそ1時間の削減は興味深い出発点ですが、そのまま自社のROIに当てはめるべきではありません。この2つの数値は各社がOpenAIの事例を通じて公開した結果であり、サンプル数、比較期間、エラー率などの実験詳細は該当記事には示されていません。 したがって、製品性能の普遍的な証明ではなく、「自社でもこの指標を測ってみよう」という仮説として捉えるほうが安全です。
トークン使用量も同様です。OpenAIのEnterprise Signalsによると、AI利用上位10%の企業は一般企業よりアクティブユーザーあたりの出力トークンを8.3倍多く生成し、2026年6月には企業顧客のCodexとChatGPTを合わせた出力トークンのうちCodexが64%を占めました。ただし、OpenAI自身もトークンは事業価値の不完全な代理指標だと明記しています。出力が長くなったというだけで、処理時間、品質、売上が改善したとはいえません。
接続範囲が広がるほど、権限設計を先に行う必要があります
メール、CRM、Slack、リポジトリを読むエージェントはより有用になる一方、攻撃対象領域も広がります。OpenAIのCodex Actionセキュリティドキュメントは、PR本文、コミットメッセージ、リポジトリの指示ファイル、画像までを信頼できない入力として扱い、作業に必要な最も狭いファイル・ネットワーク権限を選ぶよう推奨しています。
最初の実験では、速度だけを見ないでください。処理時間、無介入完了率、例外率、人のレビュー時間、差し戻し件数を一緒に記録する必要があります。処理時間が短くなっても、レビュー時間やエラー復旧が増えたなら、業務が消えたのではなく、人の後工程のキューに移っただけです。
今週、運用ワークフローを1つ作る方法
新入社員アカウントの設定、週次の顧客状況整理、文書リンクの検査のように、月4回以上繰り返され、正常終了の状態を一文で言える仕事を選びます。採用判断や契約承認のような責任の重い判断を最初の対象にしないでください。
各ステップの入力、使うメニューとツール、出力、失敗条件を書きます。画面録画だけを残さず、「Google Workspace管理者でユーザーを作成 → 会社メールでのログインを確認」のようなテキストチェックリストに変換してください。
トリガー、必要な資料、許可されたツール、完了条件、必ず示すべき証拠、人が承認するポイントを1ページにまとめます。外部メッセージの送信、決済、デプロイ、権限付与は、原則として承認前に停止するよう決めてください。
従来方式とエージェント方式をそれぞれ実施し、開始・終了時刻、成功の有無、介入回数、レビュー時間を記録します。平均だけを見ず、最も時間がかかった事例と失敗理由も残すことで、次のバージョンを改善できます。
失敗を個人のプロンプトのコツで解決せず、「どの条件を見落としたか」で分類します。所有者とバージョンを付けて修正し、変更前の失敗事例を回帰テストとして再実行してから、次のチームに展開してください。
さらに深掘りしたい場合
How AI-native companies turn workflows into operating capability — Basis、Clay、Exaの3つのワークフローと組織拡大の段階を扱う基礎資料です。 openai.com
Basis | About — Basisがエージェントと会計士の判断ポイントをどのように分けているかを確認できます。 getbasis.ai
Account Agents by Clay | AI agents for every account — アカウントごとの記憶、許可されたアクション、可観測性の構造を製品レベルで説明しています。 clay.com
Code Search — Exaがエージェントに最新コードと出典の文脈を提供する検索機能の公式ドキュメントです。 exa.ai
Enterprise Signals — 出力トークン、エージェント利用の比率とともに、この指標の限界も確認できます。 openai.com
codex-action/docs/security.md at main · openai/codex-action · GitHub — リポジトリベースのエージェントにおける信頼できない入力と最小権限の原則を扱います。 github.com
