業務を任せたのに、なぜ説明と確認はそのままなのでしょうか？
毎週繰り返す業務をAIに任せても、担当者が文脈を説明し続け、結果を再確認し続けるなら、作業者は変わっても運用方法は変わっていないことになります。プロンプトが長くなり、自動化が増えるほど、例外がどこで起きたのかを見つけるのも難しくなります。
Basis・Clay・Exaの事例は、この問題をそれぞれ異なる方法で解きました。順序が安定した業務は再利用可能なスキルにし、変わり続ける文脈はアカウント別のワークスペースに残し、外部結果を生む実行にはテストと人によるレビューを組み込みました。3社が共通して運用資産にしたのは会話文ではなく、業務の状態と完了の証拠でした。
Basisはオンボーディングの説明を「完了可能な手順」に変えました
Basisが減らしたのは、新入社員に情報を伝える時間だけではありません。人が一度実演したプロセスを、トリガー、実行ステップ、必要なツール、完了条件を持つ会社専用スキルに変えました。新入社員は初日にCodexとオンボーディングスキルを受け取り、エージェントが会社の主要概念を説明する間に、コンピューター統合の設定も進めます。OpenAIが2026年9月に公開した事例で、Basisは初日のオンボーディング時間が2時間から30分に減ったと述べています。
ただし、この数値はBasisが報告した単一事例です。標本数、測定期間、設定エラー率、HRのレビュー時間は公開されていないため、すべての会社が75%を節約できるという意味ではありません。持ち帰るべきなのは数字ではなく、説明を実際の状態変化につなげる設計です。
文書と実行手順は、終わる地点が異なります。
「必須のコラボレーションツールを設定する」という文書は、読んで理解すれば終わりです。実行手順であれば、「承認済みサービス一覧を確認 → 会社メールでログイン → 必須チャンネルへの参加状況を記録 → アカウント競合や追加権限の要求が起きたら停止」のように、完了の証拠と例外処理まで必要です。
例外がなくなるわけでもありません。Basisの事例では、繰り返しの質問や新しい例外が出るとHRがスキルを更新し、複雑な質問には人が介入します。 Basisが自社の会計エージェントでも、重要な意思決定点には会計士が参加し、完成した結果をレビューすると説明していることからも、この会社の運用原則は無人化より反復可能な実行と専門家の判断を分けることに近いといえます。
Clayは要約ではなく、翌日にも残る状態を作りました
取引情報のように毎日変わる業務では、固定された手順だけでは不十分です。Clayは、CRM、メール、Slack、通話、プレゼンテーション資料などに散らばる取引の文脈を、アカウント別ワークスペースに集約しました。専任のサブエージェントが毎晩一次資料を確認してアカウントフォルダを更新し、調整エージェントが朝に、顧客の質問への回答や購買委員会の空席確認など優先すべき行動を選び出します。Clayが明らかにした削減時間は、毎晩受信トレイを仕分けていた約1時間です。
重要なのは、昨日の結論が今日の入力につながる点です。ClayのAccount Agents製品ページでも、過去の接点、取引、通話、結論をもとに許可された行動から次のステップを選び、結論と推論を再びアカウントに記録する構造が説明されています。CRM・データウェアハウスの記録は、人の承認を経る構造として提示されています。 ただし、この商用製品とOpenAIの事例に登場するClay社内システムが、完全に同じ実装なのかは公開資料だけでは確認できません。
Exaは発見で止まらず、テスト済みPRまでつなげました
コードや外部パートナーに影響する業務では、成果物を作ることと同じくらい検証経路が重要です。ExaのCodexワークフローは、開発エコシステムで統合の機会を監視し、関連する文脈を集めたうえでPRを作成し、テストを実行します。週次更新や、必要に応じて初回告知の下書きも準備しますが、実際のデプロイ前には人がレビューします。どの機会に投資するか、外部パートナーに何を約束するかもチームが決めます。
Exaは別途、GitHubリポジトリ、ドキュメント、Stack Overflowをインデックス化し、自然言語クエリを実際のコード例につなぐCode Searchも提供しています。 ただし、公開された事例では、この製品が社内統合ワークフローに直接使われたとは述べられていません。したがって、Code SearchをExa事例の技術的基盤と断定するより、同社がコード探索の問題に取り組む別製品として分けて見るほうが正確です。
| 業務の性質 | 近い事例 | 残すべき運用資産 | 人が判断する地点 |
|---|---|---|---|
| 順序と正常終了が安定している | Basis | トリガー・ステップ・ツール・完了条件を持つスキル | 新しい例外と複雑な質問 |
| 顧客・アカウント別の文脈が変わり続ける | Clay | 一次資料と結論が蓄積される永続的なワークスペース | 根拠を確認したうえで顧客に取る行動 |
| PR・送信・デプロイのように外部結果を作る | Exa | テスト結果とレビュー可能な成果物 | 優先順位・対外的な約束・デプロイ承認 |
実行前に終える最初のパイロット設計チェックリスト
公開資料には、Basisの会社専用オンボーディングスキルをインストールまたは実行する経路は示されていません。したがって、以下の手順は特定製品の使い方ではなく、担当者とともにパイロットを実行する準備ができているかを確認する設計チェックリストです。OpenAIが提案する出発点も、担当者、ベースライン、KPI、ガードレールを定めたうえで、トリガーと権限、完了の証拠、人へ引き渡す停止点を明示することです。
- 現在の実行記録がある業務を一つ選びます。正常終了状態を一文で説明できる必要があります。現在の処理時間、例外、人の介入回数、レビュー時間もベースラインとして記録します。
- 業務状態に合う構造を選びます。順序が安定していれば再利用スキル、情報が変わり続けるなら永続的ワークスペース、外部結果を作るならテストとレビューを伴う制限付き実行に分類してください。
- トリガーと許可範囲を具体的な文章で書きます。たとえば、「入社日と会社メールが確定したら開始する。承認済みアカウント一覧だけを読み、設定状態を確認する。権限付与要求、アカウント競合、一覧外サービスが見つかったら停止する」のように書きます。
- 完了の証拠と人の停止点を先に決めます。新入社員のアカウント設定なら必須サービスごとのログイン確認記録、コード変更ならテスト結果と変更内容のように、担当者が一次資料で確認できなければなりません。外部送信、データ修正、デプロイ、権限付与は承認対象として分けてください。
- 実行前に担当者と使用環境を確定します。製品名と対応プラン、インストールまたはアクセス経路、ログイン・認証の担当者、接続するシステム、付与する最小権限、業務入力の場所、結果と監査記録の確認場所を一つの表に書きます。この項目の一つでも未定なら、まだ実行段階ではありません。GitHubのcodex-actionを選ぶ場合は、PR本文、コミットメッセージ、リポジトリの指示ファイル、画像も信頼できない入力として扱い、最も狭いファイル・ネットワーク権限を選ぶ必要があります。
- 例外を次のバージョンへ戻すルールを決めます。パイロットで発生する失敗を、条件の不足、文脈の不足、誤った権限、レビュー規則のいずれかとして記録し、誰がスキル・ワークスペース・テストを修正して再レビューするかを決めてください。
パイロット実行準備完了の基準
業務担当者、現在のベースライン、使用する製品とアクセス経路、認証・接続の担当者、入力場所、最小権限、完了の証拠を確認する場所、承認主体がすべて決まっている必要があります。一つでも空いている場合は、実行コマンドを推測せず、その製品の公式インストール・認証文書を確認してから、別の実行手順を作成してください。
成功基準は出力量ではありません。
2026年6月、企業顧客のCodex・ChatGPT合算出力トークンにおけるCodexの比率は64%で、月間AI利用量の上位10%企業は、アクティブユーザー当たりの出力トークンが中間層企業の8.3倍でした。しかし、OpenAIもトークン量は事業価値の不完全な代理指標だと明記しています。 実際のパイロット開始後は、完了業務、サイクルタイム、品質、例外、レビュー負荷、コスト、リスクのうち、その業務に合う指標を事前に記録したベースラインと比較する必要があります。
スキルの共有・管理方法も製品ごとに確認する必要があります。ChatGPTのスキルは、指示、例、コードを含めて再利用・共有でき、EnterpriseとEduの管理者は関連権限を役割別に管理できます。 ただし公式ヘルプでも、他製品では可用性、インストール、同期、ガバナンスの方法が異なる場合があると案内されています。この管理画面と権限がCodexにもそのまま適用されると考えてはいけません。
3つの事例からコピーすべきなのは数字ではなく境界です
Basisの30分とClayの1日1時間は可能性を示しますが、標本と比較方法が公開された統制実験の結果ではありません。 自社チームで最初に確認すべきなのは、「どれだけ速くなったか」だけではなく、エージェントがどこまで実行し、何を状態として残し、どの地点で人が責任を持つかです。
安定した手順には完了条件を、変化する業務には持続する文脈を、外部への影響を生む実行にはテストと承認ゲートを加えてください。さらに、使用する製品とアクセス経路、権限、入力・結果の場所まで確定して初めて、実際のパイロットに進めます。この境界が見えれば、AI自動化は個人の長いプロンプトから離れ、次の人も繰り返し改善できる運用ワークフローになります。
さらに深く知りたいなら
How AI-native companies turn workflows into operating capability — Basis・Clay・Exaのワークフローと、エージェントの職務記述書を作成する基準をあわせて確認できる基礎資料です。 openai.com
Account Agents by Clay | AI agents for every account — アカウント別の記憶、許可された行動、人の承認、観察機能がどのようにつながるかを製品レベルで確認できます。 clay.com
Enterprise signals: What frontier firms are doing differently — 企業のAI利用量の数値とともに、トークンが事業価値の不完全な代理指標である理由を確認できます。 openai.com
codex-action security guidance — GitHubベースのエージェントで、信頼できない入力と最小権限をどう扱うべきかを具体的に説明しています。 github.com
