第三部：実践編 — Agent Scriptを“運用”し、企業全体で価値を出すための総合戦略ガイド

第1部ではなぜAgent Scriptが必要なのか、第2部ではどのようにスクリプトを書くかを理解しました。ではその先に待っているのは何でしょうか？　本章で扱うのは「作ったエージェントを運用し、改善し続ける方法」です。多くのプロジェクトは、プロトタイプを完成させるところで止まってしまいます。しかし本当の勝負は運用フェーズから始まります。

採用判断のフレームワーク — どこまでAgent Scriptが必要か

第1部で紹介したとおり、Einstein Agentforceにはプロンプトだけで動作するL2レベルと、決定論的なロジックを記述できるL6（Agent Script）レベルがあります。本節では、どのようなケースでスクリプトが必要になるのか、判断基準を整理します。

プロンプトだけで対応できる範囲

シンプルなプロンプトだけで十分なケースを再確認しましょう。以下のような業務では、LLMの柔軟性を最大限に活かせます。

• FAQ回答やナレッジ検索 — 製品紹介や規約説明など定型的な情報提供。LLMが外部ナレッジから必要な情報を取り出して回答するため、スクリプトの複雑な制御は不要です。
• 単純な画面ナビゲーション — 「設定ページを開いて」「プロフィールを表示して」など操作が1〜2ステップで終わる場合。LLMにシンプルな指示を与えるだけで完了します。
• 非クリティカルな推薦 — 商品レコメンドやコンテンツ提案など間違えても被害が小さい場面。ユーザーが最終決定者であり、AIは補助的な役割に徹します。

スクリプトが必要になる境界

次のような条件がある場合は、LLM任せではリスクが高く、Agent Scriptが不可欠です。

判断のステップ

採用判断は一度きりではありません。以下のステップを繰り返し、対象範囲を徐々に拡張することで、開発コストを抑えつつ高品質を実現します。 に基づき、フレームワークをまとめました。

1. ユースケースを洗い出し、目的とリスクを整理する。
2. まずはL2（プロンプトのみ）で試作し、どの程度安定して動くか観察する。
3. 第1部で解説した失敗パターン（本人確認スキップ、順序乱れ、ルーティングミス）に当てはめて課題を特定する。
4. 失敗が頻発する箇所に絞ってスクリプトを導入し、他の部分はプロンプトで維持する。
5. 本番でログを分析し、新たな問題が発生すればスクリプト化を拡張する。

この段階的なアプローチなら、いきなりすべてをスクリプト化する必要がなく、学習コストとリスクを抑えられます。

Beta版制約とコーディング規約 — 「壊れない」スクリプトを書くために

Agent Scriptは2026年春時点でベータ機能です。機能追加や仕様変更が予告なく行われるため、最新ドキュメントを確認しつつ、以下の制約に注意しながら開発しましょう。

現在の制約

• インデントと空白に厳格 — YAMLライクな構文のため、半角スペースや改行を揃える必要があります。タブ文字は使用できません。
• コメント記法の制限 — 行末に # でコメントを書くことは可能ですが、行頭に置くとエラーを引き起こすことがあります。
• 算術演算の制限 — + と - のみがサポートされ、乗除や剰余演算は利用できません。計算が必要な場合は外部アクションを利用します。
• else if は未対応 — 複雑な条件分岐は if と else のネストまたは複数の if 文で表現します。ロジックを分割し、トピックを増やすことも検討します。
• スロットフィリング (...) の制約 — プロンプト連結のための ... はベータ版では一部制限があります。長文プロンプトは複数行に分けて記述してください。

コーディング規約とリーディング性

ベータ制約に加え、読みやすく保守しやすいスクリプトを書くための規約をまとめます。

1. 1行1命令 — -> や | の各行には1つの命令だけを記述し、複数処理は改行して順序を明確にします。
2. 意味のある名前 — トピック名や変数名はキャメルケース (orderStatus) またはスネークケース (customer_id) を用い、機能が一目でわかるようにします。
3. 条件を先頭に集める — if 文や認証チェックはトピックの冒頭に配置し、ガードロジックを読みやすくします。
4. コメントの活用 — トピックの目的や条件の理由を行末コメントで記述し、後続の開発者が理解しやすいようにします。
5. ベータ制約に対応したユニットテスト — インデントずれや未対応構文を早期発見できるよう、自動Lintや簡易テストコードを用意します。

セキュリティとコンプライアンス：Einstein Trust Layerとその運用

本番運用では、機能以上に安全性が重要です。SalesforceはAI機能の安全基盤としてEinstein Trust Layerを提供しており、Agent Scriptと組み合わせて利用することで、安心してAIを活用できます。主な機能は表の通りです。

運用手順とチェックリスト

Trust Layerを最大限に活かすには、設定と運用のプロセスを明確化することが重要です。以下にVantagePointのガイドに基づく手順を示します。

1. Trust Layerを有効化する — Setup > Einstein > Trust Layer から機能を有効にします。AI関連機能をオンにするだけではなく、マスキングや監査の設定画面にアクセスできるようになります。
2. データマスキングポリシーを設計する — マスキング対象フィールドと方法（文字列の伏字化、数値のハッシュ化など）を定義し、規制要件に合わせたルールを設定します。
3. トキシック検出基準を調整する — 許容する表現や禁止ワードのリストを設定し、誤検出による業務停止が起きないようテストします。
4. 監査ログ保存期間を決める — コンプライアンス規定に応じてログ保持期間を設定し、システム負荷とバランスを取ります。
5. 運用ガバナンスを定義する — 誰が設定を変更できるか、変更時に誰がレビューするかなど、役割と責任を明文化します。
6. 定期的なレビューとテスト — 新しいモデルや機能追加のたびに、マスキングやトキシック検出の挙動をチェックし、アップデートを適用します。

これらの手順をチェックリスト化し、運用の標準プロセスに組み込むことで、セキュリティ事故の発生率を大幅に下げられます。

開発・デプロイの流れ：組織としてスケールするためのステップ

第2部ではコードの書き方にフォーカスしましたが、本番に持ち込むにはさらに多くの工程が必要です。本節では、プロジェクトの立ち上げから本番展開までのステップを、チーム視点で整理します。

企画と準備 — “何を作るか”と“なぜ作るか”を決める

ユースケースとゴールの明確化

まずは何のためのエージェントなのかを定義します。採用支援、カスタマーサポート、社内ヘルプデスクなど、目的を具体的に設定し、**KPI（Key Performance Indicators）**も決めましょう。例えば、ケース削減率や応答時間短縮など、運用後に測定できる指標を設定します。

業務プロセスの可視化

現状の手作業フローを図示し、どの部分を自動化するかを決めます。手順書、フローチャート、シーケンス図などを使って、プロセスの問題点を洗い出します。

データソースと権限の整理

使用するオブジェクトや外部API、必要な権限を一覧化します。権限の最小化（least privilege）を意識し、不必要なアクセスを防ぐ設定にします。これにより、Trust Layerの「権限尊重」機能が正しく機能します。

ガードレールの策定

実行可能な操作の範囲、エラー処理方針、再試行回数など、運用中のガイドラインを決めます。Beta制約で未対応の機能や構文を使わないように事前にチェックします。

チームの役割分担とコミュニケーション

AIエージェント開発は開発者だけの仕事ではありません。管理者、ビジネス担当、法務など多様な役割が関わります。以下のような分担を決めておくとスムーズです。

設計と実装 — モジュール化とテンプレート化

第2部ではトピックやアクションの設計方法を学びましたが、運用段階では再利用性とスケーラビリティを意識した設計が鍵になります。

モジュール設計のポイント

1. 1トピック1責務 — 本人確認、データ取得、応答生成など機能単位でトピックを分割します。大きなトピックは保守が難しく、バグの原因になります。
2. テンプレート化された共通トピック — 認証、エラー処理、ログ出力などは共通テンプレートとしてモジュール化し、複数エージェントで再利用します。
3. 変数とアクションの明確化 — 状態管理を行う変数は命名規約を統一し、どこで読み書きされているかコメントやドキュメントで明示します。アクションは1アクション1責務で構築し、副作用があるものは必ずコメントと説明を付けます。

手順・コード・解説の例：共通認証モジュール

以下は、従業員向けエージェントで使う本人確認モジュールの例です。手順・コード・解説の3点セットで示します。

1. 手順
   1. start_agent でユーザー入力を受け取ったら、IdentityCheck トピックに遷移する。
   2. IdentityCheck トピックでは認証アクション（SSO、OTPなど）を実行し、結果を variables.isAuthenticated に保存する。
   3. 認証に失敗した場合は AuthError トピックに遷移し、再試行オプションを表示する。
   4. 認証が成功した場合は次の処理トピックへ遷移する。
2. 失敗例

topics:
  IdentityCheck:
    | Please confirm your identity.
    -> run @actions.verify_user
    -> transition to MainProcess  MainProcess:
    | What can I help you with?

上記スクリプトには認証結果のチェックがなく、認証に失敗してもMainProcessに進んでしまいます。これでは本人確認スキップ問題が再発します。

3. 正解例

topics:
  IdentityCheck:
    | 本人確認を行います。認証コードを入力してください。
    -> run @actions.verify_user
    -> if result.success == true
        -> variables.isAuthenticated = true
        -> transition to MainProcess
    -> else
        -> transition to AuthError  AuthError:
    | 認証に失敗しました。もう一度お試しください。  MainProcess:
    -> if variables.isAuthenticated
        | どのようなご用件でしょうか？

上記では、認証結果を条件分岐で評価し、失敗時には必ずAuthErrorへ遷移させています。これにより本人確認を必ず通過させることができます。トピック冒頭で条件チェックを行うのは安全第一のベストプラクティスです。

4. 解説

この認証モジュールでは、verify_userアクションを実行した後、返り値であるresult.successをチェックしています。が強調するように、必須手順は確実に実行されなければなりません。変数isAuthenticatedを用いて状態を管理することで、その後の処理で認証済みかどうかを簡潔に判断できます。失敗時に遷移するトピックを用意することで、ユーザーに再試行やサポートへの連絡を促すことができます。

テストとデバッグ — 品質を保ちながらスピードを上げる

Agentforce StudioのCanvas viewとScript viewでは、スクリプトの実行結果をシミュレーションできるテスト機能が組み込まれています。運用フェーズで重要なのは、テストを単なるデバッグ手段ではなく、継続的な品質保証の仕組みにすることです。

テストのポイントとベストプラクティス

1. テストケースの網羅 — 正常系はもちろん、エラーケースや境界値なども含めてカバレッジを高めます。
2. トピック遷移と変数の検証 — 条件分岐が意図通りに動くか、変数が正しく更新されているかをシミュレーション画面で確認します。
3. アクションの実行結果の確認 — API連携やFlow実行の結果をチェックし、失敗した場合のエラーハンドリングが機能しているかを確認します。
4. 本番と同一条件でのテスト — 権限設定やデータ量が本番と異なると挙動が変わるため、可能な限り本番環境に近い設定でテストします。
5. 自動テストとCI/CDとの統合 — コードレビュー・ユニットテスト・統合テストを自動で実行し、Pull Requestの時点で品質を確保できるようにします。

運用フェーズでは、テストとデバッグに投資することが結果的にコスト削減につながります。テストを手軽に行えるAgentforceの機能は積極的に活用しましょう。

デプロイとマルチチャネル展開

エージェントが完成したら、本番環境へのデプロイと展開を行います。AgentforceはSalesforceの各種UI、Slack、モバイルアプリ、ウェブチャットなど多様なチャネルへの配置が可能です。デプロイ時には次の点を意識します。

1. チャネルごとの権限設定 — Slackやモバイルでは認証方法や権限が異なるため、チャネル固有の設定を確認します。
2. UIと応答の最適化 — モバイルでは長文よりも短い回答、ウェブチャットではリッチリンクや画像を活用するなど、チャネル特性に合わせてプロンプトを調整します。
3. バージョン管理とロールバック — 複数チャネルに展開した際に不具合が出た場合でも迅速にロールバックできるよう、バージョン番号やリリースノートを整備します。
4. 計測基盤の統一 — チャネルごとに応答時間やユーザー満足度を計測し、ダッシュボードで統合的に分析します。KPI評価の基礎データとして利用します。

モニタリングと改善サイクル — KPIを持って育てる

運用が始まったら、計測と改善が成功の鍵を握ります。何をどのように測定し、どう改善サイクルを回すかを定義しましょう。

観測すべきKPI

AIエージェントに共通するKPIと、Salesforce文脈特有のKPIをリストアップしました。これらを定期的にダッシュボード化し、改善サイクルの基盤にします。

ログ分析とインシデント対応

KPIを計測するには、ログやメトリクスの収集が欠かせません。ログ分析の観点と、インシデントが起きた場合の対処フローをまとめます。

1. ロギング設計 — 各トピックの開始・終了時、変数の変更時、アクション実行前後などでログを残します。ログにはユーザーIDやタイムスタンプ、変数値など必要な情報を含めます。
2. ダッシュボード化 — Salesforce ReportsやTableau、外部BIツールを使い、上記KPIを可視化します。データクラウドと連携すれば、多チャネルのメトリクス統合が容易です。
3. アラート設定 — エラー率が閾値を超えた場合に自動通知を行い、早期に問題を発見します。PagerDutyやSlackアラートと連携して即時対応を促します。
4. インシデント対応フロー — 不具合が発生した際の連絡体制、ログ確認手順、ロールバック手順をドキュメント化しておきます。定期的に訓練することで、緊急時に迅速な対応が可能になります。

継続的改善のサイクル

改善サイクルは**PDCA（Plan–Do–Check–Act）**と似ています。以下の手順で回しましょう。

1. Plan — KPIやユーザーフィードバックに基づき、改善目標と施策を立案。例えば、認証のUI改善やFAQの追加、トピック分割など。
2. Do — スクリプト修正やアクション追加を実施し、テスト環境で検証する。Pull Requestレビューを通じて品質を確保する。
3. Check — デプロイ後にKPIやログを再度測定し、改善施策の効果を検証する。
4. Act — 成果を共有し、標準プロセスやテンプレートに反映する。さらなる課題に着手する。

ガバナンスと変更管理 — チームでエージェントを育てる

エージェント開発が進むと、複数の人がスクリプトを変更したり、複数のエージェントが同時に運用されたりします。そのため、ガバナンスと変更管理の体制が重要になります。

バージョン管理とレビュー文化

変更管理プロセス

特に本番エージェントでは、変更管理が欠かせません。以下のプロセスを採用すると安心です。

1. 変更リクエスト提出 — 改善内容やバグ修正案をIssueやチケットで申請し、影響範囲を整理します。
2. 影響分析とテスト計画 — ユースケース、データフロー、他システムへの影響を分析し、テストケースを決定します。
3. レビューと承認 — PR上で設計レビューとコードレビューを行い、必要に応じて法務やセキュリティ担当の承認を得ます。
4. デプロイと検証 — 検証環境でデプロイし、テスト後に本番へ反映します。結果をダッシュボードで監視します。
5. 文書更新と共有 — 変更箇所や理由をWikiやPlaybookに追記し、ナレッジを共有します。

このように、変更プロセス自体をドキュメント化し、誰でも従えるようにすることが重要です。

運用フェーズの失敗パターンと対策

第1部ではLLM特有の失敗パターン、第2部ではコードレベルの失敗パターンを扱いました。第三部では運用でありがちな失敗を紹介し、その対策を示します。これらは実際にエンタープライズ導入時に起こりがちな問題です。

監視不全：ログを見ない・KPIを追わない

失敗例：

デプロイ後、何も監視せず運用を開始。数週間後にユーザーから「質問に対して全く違う回答が返ってきた」とクレームがあり、ログを確認したら実装ミスに気づいた。KPIを設定していなかったため、どこで失敗しているかわからなかった。

対策：

• 運用開始前に必ずKPIダッシュボードを構築し、毎日／毎週レビューする。
• エラー率や正答率をリアルタイムで監視し、閾値超過時に自動通知する仕組みを導入する。
• ログ出力を標準化し、各トピックと変数の状態を追跡できるようにする。

スケール障害：トピック・変数・アクションが爆発

失敗例：

複数部門でエージェントを増やすうちに、トピックが100以上、変数が50個を超え、どこで何をしているか誰も把握できなくなった。変更すると予期せぬ部分に影響が出てバグが頻発。

対策：

• モジュール化とテンプレート化を徹底し、共通部品を切り出す。認証やログ出力など共通機能は単独のトピックにまとめ、他トピックから呼び出す。
• トピックや変数の命名規則を文書化し、どのトピックがどの機能を担当するのか整理する。
• 定期的にリファクタリングの時間を取って古いトピックを整理・統合する。

ガバナンス欠如：勝手な改修や権限事故

失敗例：

開発者が本番エージェントを直接変更してしまい、ユーザーが操作できる権限を超えた処理を実行してしまった。ロール分離やレビューがなかったため検出が遅れた。

対策：

• すべての変更はPRベースで行い、レビュワーの承認を必須にする。
• ロールと権限を分離し、デプロイ権限を限られた担当者にのみ付与する。
• 定期的にセキュリティ監査を実施し、不正アクセスや権限漏れがないか確認する。

チーム間コミュニケーション不足：担当が不明確

失敗例：

エージェントが誤回答を出した際、開発チームは「ビジネス要件が変わったからだろう」、ビジネスチームは「技術側の問題だろう」と責任の所在が不明確になり、修正に数週間を要した。

対策：

• ドキュメントと担当表を整備し、エージェントごとに設計者・レビュワー・運用者を明記する。
• 定例会を設け、KPIやフィードバック、変更要件を共有する場を作る。
• Canvas viewを利用してノーコード担当者もスクリプトの概要を確認できるようにし、チーム間の理解を深める。

アーキテクチャとスケーラビリティ — 全体構成を俯瞰する

Agent Scriptは単体では動きません。Apex、Flow、GraphQL、Data Cloudなど周辺技術と連携して初めて実用的なエージェントが完成します。本節では、エンタープライズ環境における代表的なアーキテクチャパターンとスケーラビリティの課題を扱います。

代表的な構成パターン

1. Agent Script ＋ Flow — 操作の順序が複雑なときはFlowを利用し、Agent ScriptからFlowを呼び出します。Flowの中にトリガー処理や条件分岐をまとめ、スクリプト側では単に引数を渡して結果を受け取ります。
2. Agent Script ＋ Apex — 複雑なロジックや外部API連携はApexクラスとして実装し、Agent Scriptのアクションから呼び出します。Apexでトランザクション制御とエラーハンドリングを行い、スクリプトでは結果のみ扱うようにします。
3. Agent Script ＋ GraphQL — Spring ’26からはLightning Web ComponentでGraphQLのmutationがサポートされ、データ更新も可能になりました。データ取得もGraphQLで統一することで、一貫したAPI設計ができます。
4. Agent Script ＋ Data Cloud — Salesforce Data Cloudと連携し、顧客360の情報を活用したパーソナライズを行う。リアルタイムイベントやインサイトをAgent Scriptの変数に反映し、高度な推論を行います。

スケーラビリティとパフォーマンス

大規模な導入では、性能と拡張性も重要な課題です。

スケーラビリティを考慮した設計は、後からの拡張や変更を容易にし、継続的な改善に耐えられる基盤となります。

テンプレート集：再利用できるパターン

最後に、実務でよく使うAgent Scriptパターンをテンプレートとして紹介します。これらはユースケースに合わせて編集・組み合わせて使えるように設計されています。

エラーハンドリングテンプレート

topics:
  ErrorHandler:
    | 申し訳ありません、エラーが発生しました。{{errorMessage}}
    -> if variables.retryCount < 3
        | もう一度試してみます。
        -> variables.retryCount = variables.retryCount + 1
        -> transition to variables.previousTopic
    -> else
        | サポート担当者にお繋ぎします。
        -> transition to Escalation

解説：エラー発生時には ErrorHandler トピックに遷移し、リトライ回数を管理します。3回失敗したら人間の担当者へエスカレーションします。変数 previousTopic に直前のトピック名を保持することで、自動リトライが可能になります。

認証テンプレート

topics:
  Authentication:
    | 認証コードを送信しました。コードを入力してください。
    -> run @actions.send_code
    -> run @actions.verify_code
    -> if result.success
        -> variables.isAuthenticated = true
        -> transition to NextStep
    -> else
        -> transition to AuthError

解説：認証コード送信と検証を行うテンプレート。アクションは独立しているため、SMS・メール・アプリ通知など手段を変えて再利用できます。

ログ記録テンプレート

topics:
  LogAction:
    -> run @actions.log_event
    -> transition to variables.nextTopic

解説：トピックの開始や終了時に呼び出す共通ログモジュール。変数 nextTopic に遷移先をセットしておき、ログ記録後に処理を戻します。標準化したログ出力により、後の分析が簡単になります。

これらテンプレートを組み合わせれば、エラー処理や認証、ロギングを簡潔かつ一貫性のある形で実装できます。社内ドキュメントや共有リポジトリに保管し、エージェント開発者がすぐに利用できるようにしましょう。

非エンジニアとの協働：Canvasと分業モデル

Agent Scriptの運用では、コードを書かないメンバーとの連携が欠かせません。Agentforce StudioにはCanvas viewが用意されており、ノーコードユーザーでもトピックと遷移の全体像を把握できます。協働を進める上でのポイントをまとめます。

CanvasとScriptの使い分け

分業とハンドオフ

1. プロセス設計はCanvasから始める — ビジネス担当者が理想のフローをCanvasで描き、これを開発者がスクリプトに落とし込みます。
2. レビューは双方のビューで行う — Script viewのレビューと同時に、Canvasでユーザー導線やUXを確認します。1つの変更が他のトピックに影響を与えないかチェックします。
3. ドキュメント共有 — Canvas図、Scriptコード、プロンプト文言、アクション仕様を一つのプレイブックにまとめ、非エンジニアでも理解できるようにします。

この協働モデルにより、エージェント開発はエンジニアだけの活動ではなく、ビジネスやUXの専門家も参加するプロジェクトとなります。

ケーススタディ：Agent Scriptで採用プロセスを刷新する

ここでは、実際にAgent Scriptを用いて採用プロセスを自動化した架空企業「SkyOffice社」の事例を、運用視点で振り返ります。

課題と目標設定

SkyOffice社は急成長中で、採用問い合わせが急増していました。候補者からの質問が多岐にわたり、担当者が手作業で回答していたため、平均2日もの回答遅延が発生していました。そこで次の目標を設定しました。

1. 回答時間を数秒に短縮 — 24時間365日いつでも即答できるようにする。
2. 担当者の負荷削減 — よくある質問や手続きはAIに任せ、担当者は面接や候補者フォローに集中する。
3. データ保護とコンプライアンスの徹底 — 候補者の個人情報を保護しつつ、リアルタイムに情報を提供する。

設計と実装

企画段階でユースケースを整理し、RecruitInfo、ApplicationProcess、InterviewSchedule などのトピックを設計しました。認証は不要と判断したため、データマスキングルールを細かく設定し、応募書類の内容はLLMに渡さないように制限しました。

手順・コード・解説の例

1. 手順
   1. ユーザーが採用に関する質問を入力すると、start_agent でキーワードを判定し、RecruitInfo へ遷移。
   2. RecruitInfo トピックではFAQを参照し、質問が一般的な内容かを判断。一般的ならそのまま回答し、個別に応答が必要なら担当者にエスカレーション。
   3. 応募希望の場合は ApplicationProcess トピックに遷移し、応募の手順を案内。応募後のステータス確認は ApplicationStatus トピックに遷移。
   4. 面接日程調整の場合は InterviewSchedule トピックへ遷移し、空きスロットを取得して候補日を提案。
2. 失敗例

topics:
  RecruitInfo:
    | 採用情報をご案内します。どのようなことを知りたいですか？
    -> if @system_variables.user_input contains "応募"
        -> transition to ApplicationProcess
    -> transition to RecruitInfo  ApplicationProcess:
    | 応募したい場合はフォームに入力してください。
    -> | エントリーフォームはこちらです。<form link>
    -> transition to End

上記では、FAQの分岐もなく、応募希望の場合以外は永遠にRecruitInfoにループしてしまいます。また応募完了後のステータス確認や面接調整機能がありません。

3. 正解例

topics:
  RecruitInfo:
    | 採用情報についてお知らせします。質問を入力してください。
    -> if @system_variables.user_input contains "応募"
        -> transition to ApplicationProcess
    -> if @system_variables.user_input contains "面接"
        -> transition to InterviewSchedule
    -> if @system_variables.user_input contains "状況"
        -> transition to ApplicationStatus
    -> | よくある質問: 募集職種・選考フロー・福利厚生などについてお答えします。  ApplicationProcess:
    | 応募手続きについて説明します。フォームはこちらです。<form link>
    -> | 応募が完了したら、応募状況を確認する方法もご案内します。
    -> transition to RecruitInfo  ApplicationStatus:
    | 応募の状況をお調べします。応募者IDを入力してください。
    -> run @actions.lookup_application
    -> | 現在の選考状況は{{result.status}}です。
    -> transition to RecruitInfo  InterviewSchedule:
    | 面接の調整を行います。ご希望の日程を教えてください。
    -> run @actions.get_available_slots
    -> | 以下の日程が空いています: {{result.slots}}
    -> transition to RecruitInfo

4. 解説

このスクリプトでは、ユーザーの入力内容に応じて複数のトピックへ遷移する分岐を用意しています。ApplicationStatus トピックでは応募状況を取得する外部アクションを呼び出し、結果を提示しています。InterviewSchedule では面接日程調整に必要な空きスロットを取得し、候補日を提示しています。これにより、候補者の問い合わせに対し即座に対応できるようになりました。

運用と成果

導入後、問い合わせへの平均応答時間は数秒に短縮され、担当者は応募後のフォローや候補者対応などの付加価値業務に集中できるようになりました。データマスキングと権限尊重により、個人情報の漏洩リスクを低減できました。KPI計測を定期的に行い、FAQの充実やプロンプト改善を継続した結果、候補者満足度と採用効率が大幅に向上しました。

未来展望とキャリア — Agent Scriptが切り開く新しい役割

テクノロジーの進化

2026年以降、Agent ScriptとAgentforceは更なる発展が期待されています。GraphQLとTypeScriptによるカスタマイズ性の向上、CanvasとScriptの融合によるノーコードユーザーへの開放、Trust Layerの高度化、マルチチャネル統合の強化、エンタープライズ全体への拡大など、進化の方向はさまざまです。

新しい役割とキャリアパス

AIエージェントの登場により、従来の開発者や管理者の役割も変化します。例えば：

• AIエージェント設計者 — エージェントのユースケース定義とフロー設計を担い、ビジネスと技術の橋渡しを行います。
• AIガバナンス担当 — セキュリティ設定やコンプライアンス遵守、倫理的配慮を担当します。
• AIオペレーター — モニタリングと改善サイクルを回し、ユーザーからのフィードバックを取り込んでスクリプトを更新します。
• AIプロダクトマネージャー — エージェントを製品の一部として位置付け、ROIやマーケットフィットを評価します。

これらの役割は今後さらに専門化し、AIオペレーションが企業の重要な職種の一つになっていくでしょう。技術者にとっては、エンジニアリングスキルだけでなく、ガバナンスやUX、倫理の視点も求められるようになります。

まとめと次の一歩 — “運用フェーズこそ真の勝負”

本章では、Agent Scriptの実践運用に関するあらゆる側面を見てきました。重要なポイントを振り返りましょう。

1. 採用判断は段階的に行う。 プロンプトだけで足りる部分と、決定論的制御が必要な部分を見極め、失敗が多い箇所からスクリプトを導入する。
2. セキュリティとコンプライアンスを第一に。 Trust Layerの活用や権限管理を徹底し、AIが個人情報を扱うリスクを最小限に抑える。
3. 組織的な運用と改善サイクルを構築する。 KPIを設定し、ログ分析とPDCAで継続的に改善する。ガバナンスと変更管理のプロセスを整備し、チーム全員で品質を担保する。
4. スケーラビリティとアーキテクチャを考慮する。 Flow、Apex、GraphQL、Data Cloudと組み合わせ、拡張性と性能を両立させる。
5. 未来を見据え、キャリアの糧とする。 Agent ScriptはAI時代の業務オーケストレーション基盤であり、新しい役割とキャリアパスが広がる。

今すぐやるチェックリスト（3分）

1. 現状のエージェントのKPIを設定し、正答率やエラー率を測定する準備をする。
2. 運用プロセスのガバナンス表を作成し、担当者と権限を明確にする。
3. モジュール化とテンプレート化を進め、認証やエラーハンドリングなど共通機能を共有リポジトリにまとめる。
4. 次の改善サイクルの計画を立て、改善案をIssueに登録する。

この3部作を通じて、あなたはAgent Scriptの必要性の理解、正しい実装方法、そして運用で価値を最大化する方法を習得しました。これからは、学んだ知識をプロジェクトに適用し、AIエージェントで業務と顧客体験を向上させてください。

お問い合わせ

現在Salesforceを効果的に活用できていない企業様や、これからSalesforceの導入を検討している企業様で、設定や運用、保守に関するサポートが必要な場合は、ぜひお気軽にご相談くださいませ！