sr-connect

ScriptRunner Connect

このファイルでは、概要について説明します。CLI を使う前に references/cli-workflow.md を読み、スクリプトを書く前に references/scripting.md と、スクリプトが呼び出す各製品について references/product-gotchas/ にファイルがある場合はそのファイルを読んでください。テストを求められた場合に限り、references/testing.md を読んでください。

最初の CLI 呼び出しの前に

セッションごとに一度、ほかの CLI 操作を行う前に、呼び出すコマンドを決めてください。

1. command -v sr-connect を実行します。見つかった場合は、CLI がインストールされ、PATH 上にあります。コマンドをユーザーに渡す場合も含め、どこでも sr-connect <group> <verb> として呼び出してください。見つからない場合は、npx @sr-connect/cli <group> <verb> として呼び出し、セッションの最初の呼び出しは npx @sr-connect/cli@latest に固定して、キャッシュされたコピーを最新の状態にしてください。

   見つからなかった場合は、問題が起きたように受け取られないよう、ユーザーに簡潔な一文で伝えてください。npx はそのまま使え、修正は不要です。呼び出しを速くするには、npm install -g @sr-connect/cli でグローバルにインストールできます。npx は呼び出しのたびにキャッシュを確認するため、1 回あたり数秒、あるエージェントの測定では 4～10 秒かかります。プロジェクトローカルへのインストールでは sr-connect が PATH に追加されないため、役に立ちません。nvm の場合、グローバルインストールはアクティブな Node バージョンに属するため、バージョンを切り替えると sr-connect が再び PATH から外れます。ユーザーがセッション中にインストールした場合は、この手順を再度実行して、セッションで sr-connect を使うように切り替えてください。

2. <cli> cli check-updates --agent --raw を実行します。出力されるドキュメントには、updateAvailable、current、latest が含まれ、更新がある場合は command も含まれます。終了コード 1 はレジストリを読み取れなかったこと、終了コード 4 はレジストリにリリースが公開されていないことを示します。どちらも作業の妨げにはならないため、その旨を伝えて、手元にあるバージョンで作業を続けてください。

3. updateAvailable が true の場合は、両方のバージョンを示し、変更点をユーザーが確認できるように変更履歴へのリンク（https://cdn.jsdelivr.net/npm/@sr-connect/cli@latest/CHANGELOG.md）を貼り、ユーザーがアップグレードするか、こちらで行うかを尋ねてください。回答を得る前にアップグレードしてはいけません。

command フィールドは、このコピーのインストール方法に基づいて生成されたアップグレード用コマンドです。npm、pnpm、bun、npx では正しいコマンドですが、CLI が npm として認識する 2 種類のインストール方法では正しくありません。そのため、このコマンドを提示する前に、sr-connect の実際のパスを解決するか、yarn global bin と volta which sr-connect を実行して確認してください。

インストール方法	アップグレード方法
npm グローバル	npm install -g @sr-connect/cli@latest
pnpm グローバル	pnpm add -g @sr-connect/cli@latest
bun グローバル	bun add -g @sr-connect/cli@latest
Yarn 1 グローバル	yarn global upgrade @sr-connect/cli
Volta	volta install @sr-connect/cli@latest
npx、またはグローバルインストールがない Yarn 2 以降	アップグレード不要です。次の呼び出しを npx @sr-connect/cli@latest として実行してください

ユーザーが実行する場合は、--agent や --raw を付けずに、そのコマンドだけを渡して待ってください。こちらで実行する場合は、同じコマンドを実行し、新しいバージョンで応答したことを確認するために cli check-updates を再実行してください。

このファイルのスナップショット、コネクターの表、制限、プラン、パッケージ一覧は 2026-09-12 時点のもので、出典 URL が記載されています。回答が数値に左右される場合は、出典を再取得してください。

このスキルは最新ですか

各セッションで最初の CLI 呼び出しを行う前に、一度確認してください。可能であればハッシュを比較し、できない場合はバージョンを比較してください。ネットワークに接続できない場合は確認を省略し、その旨を1行で伝えて、このコピーを使って作業を続けてください。

1. インストール済みのコピーのハッシュを確認します。プロジェクトのロックファイルがホームディレクトリのものより優先されます。sr-connect エントリのないロックファイルはハッシュがないことを意味するため、以下のバージョン確認に進んでください。

   • プロジェクトルートの ./skills-lock.json。最近の npx skills によるプロジェクトへのインストールでは、このファイルが作成されます。その computedHash はインストール済みファイルを GitHub とは異なる方法でハッシュ化するため、比較には使わないでください。代わりに、インストール済みフォルダーの git tree sha を計算します。これには git が必要です。利用できない場合は、バージョン確認に進んでください。s に、この SKILL.md の読み込み元フォルダーを設定します。設定フラグと .DS_Store の削除により、ユーザーの git 設定と Finder のファイルがハッシュに含まれないようにします。

     s=.agents/skills/sr-connect; d=$(mktemp -d) && cp -R "$s/." "$d" && find "$d" -name .DS_Store -delete && git -C "$d" init -q && git -C "$d" -c core.excludesFile=/dev/null -c core.attributesFile=/dev/null -c core.autocrlf=false add -A -f && git -C "$d" write-tree; rm -rf "$d"
     

   • ./.agents/.skill-lock.json または ~/.agents/.skill-lock.json。skills["sr-connect"].skillFolderHash を読み取ります。これは公開リポジトリの skills/sr-connect の git tree sha です。

2. このフォルダーの公開済み sha を取得します。このエンドポイントは認証不要で、リポジトリ内のすべてのスキルを一覧表示します。

   curl -s 'https://api.github.com/repos/adaptavist/scriptrunner-skills/contents/skills?ref=main'
   

   name が sr-connect のエントリから sha を取得します。403 は、1つのアドレスあたり1時間に60回という GitHub の未認証呼び出し制限に達したことを意味するため、バージョン確認に進んでください。

3. ハッシュが一致する場合は何も伝えません。異なる場合は、このコピーが公開済みスキルと異なっており、通常は古いことをユーザーに伝えます。公開済みコピーには、このコピーにないガイダンスが含まれているため、更新を強く推奨してください。更新を実行するか、ユーザー自身が実行できるコマンドを案内するかを尋ねます。どちらの場合も、新しいファイルが読み込まれるのは次のセッションからであり、現在のセッションではこのコピーを使い続けることも伝えてください。ユーザーの返答を待ちます。返答を得る前に更新を実行してはいけません。

   npx skills@latest update sr-connect
   

ハッシュを比較できない場合は、バージョンを確認します。公開済みの SKILL.md を取得します。この取得は API の制限を受けません。

curl -s 'https://raw.githubusercontent.com/adaptavist/scriptrunner-skills/main/skills/sr-connect/SKILL.md'

公開済みファイルとこのファイルのフロントマターから metadata.version を読み取り、各部分を数値として比較します。そのため、1.10 は 1.9 より新しいバージョンです。公開済みのバージョンのほうが新しい場合、このコピーは古いため、上記のハッシュが異なる場合と同じようにユーザーに伝えてください。バージョンが同じ場合、または取得に失敗した場合は何も伝えません。バージョンはスキルを変更するリリースごとに更新されるため、バージョンを上げずに公開された変更は検出できません。ハッシュなら変更をすべて検出できるため、先にハッシュを確認します。

概要

ScriptRunner Connect は、汎用的なコードファーストのサービスとしての統合プラットフォームです。マネージドランタイムで実行される TypeScript スクリプトを作成し、外部アプリからのイベントやスケジュールに関連付け、型付きクライアントを通じて他のアプリを呼び出します。Atlassian と、その周辺のビジネスツールに関する機能が最も充実していますが、このプラットフォームはそれらに限定されません。コードファーストであるため、エージェントにも適しています。統合に必要なものはすべて、スクリプト、設定レコード、または CLI コマンドです。

用語：外部システムを指す公式の用語は app です。この用語を使ってください。

X と連携できますか

前提条件が2つあります。両方を満たしていれば、ほとんどの場合は可能です。

1. アプリにインターネットからアクセスできること。SRC は SaaS です。SRC からの外向きの呼び出しは、インスタンスごとに固定 IP アドレス（EU は 34.251.34.27、US は 35.163.23.171）から送信されるため、ファイアウォールで許可リストに登録すれば、オンプレミスネットワークに接続できます。別の方法として、DMZ にリバースプロキシを設置できます。経路を一切開けられないクライアント向けには、プライベートクラウドホスティングがあります。SRC チームがクライアント専用の AWS アカウントで製品を運用し、必要に応じてクライアント自身の VPC 内に配置することで、内部サービスに直接接続できます。また、必要に応じてインターネットから切り離すこともできます。
2. アプリに HTTP API があること。

HTTP 以外のプロトコルを使う場合は、その前段に HTTP レイヤーが必要です。これはクライアントが設定します。一般的な例として、SQL データベースがあります。

SRC へのインバウンドトラフィック、つまり Webhook は、固定 IP アドレスを持たないクラウドゲートウェイ経由で届きます。制限されたネットワークから Webhook を送信するには、インターネットへのアウトバウンド通信が必要です。OAuth の同意には、アプリと SRC の両方にアクセスできるブラウザーが必要です。

参照先：https://docs.adaptavist.com/src/latest/get-started/connect-to-services-behind-the-firewall, https://www.scriptrunnerhq.com/scriptrunner-connect/private-cloud-hosting

構成要素

構成要素は5つあります。イベントリスナーはアプリからイベントを受け取り、スクリプトを実行します。スクリプトは API 接続をインポートして、アプリと通信します。API 接続は、コネクター（認証済みアカウント）を使ってベース URL と認証ヘッダーを置き換えます。すべての要素はワークスペース内にあります。スクリプトは、手動、スケジュール、または別のスクリプトからも実行できます。

用語集。左側がドキュメントでの用語、右側が CLI グループです。

概念	ドキュメント	CLI
1つのインテグレーションのコンテナ	workspace	workspace
ユーザーが所有し、チームを通じて共有するアプリの認証済みアカウント	connector	connector, connector-sharing
スクリプトが ./api/<path> からインポートするアウトバウンドクライアント	API connection	api-connection
API 接続の背後にある型付きクライアントパッケージ	Managed API	package (type MANAGED_API)
アプリのイベントタイプに紐付けられたインバウンドトリガー	event listener	event-listener
手動実行用に保存されたサンプルイベント	test event payload	event-listener-test-payload
環境ごとの型付き設定	parameters	environment-parameter
CRON によって実行される処理	scheduled trigger	scheduled-trigger
リスナーのイベントを FIFO 方式で処理する仕組み	event queue	event-queue
ワークスペースの編集可能な作業バージョン	HEAD	release フィールドのない環境
不変のスナップショット	release, deployment	release create -e <env>, 1回の呼び出し
環境の設定が保存される場所。HEAD またはリリースを対象とする	environment	environment; -e にはその ID を指定
Web アプリと共有される編集ロック	none	workspace-lock
アウトバウンドの宛先、コネクター、ホスト名に対するチームの許可リスト	Egress Firewall	egress-firewall

機能

ワークスペース、HEAD、リリース、環境

ワークスペースには、スクリプト、API 接続、イベントリスナー、スケジュール済みトリガー、パッケージ、パラメーター、README が含まれます。所属できるチームは最大 1 つです。公開範囲は、チーム管理者と自分のみがアクセスできる非公開か、すべてのチームメンバーがアクセスできる公開のいずれかです。言語は js、ts、ts-strict のいずれかです。必ず ts-strict を使用してください。

HEAD は作業中のバージョンで、常に編集可能です。リリースは、HEAD、スクリプト、README、リスナー、API 接続、トリガーのリリースレベルの設定をスナップショットとして保存したもので、その後変更できません。バージョンはセマンティックバージョニングに従い、必ず増加させる必要があります。release create -e <env> は、1 回の呼び出しでリリースを作成し、環境にデプロイします。environment target-release は、環境の適用先を既存のリリースまたは HEAD に切り替えるだけです。環境は HEAD または単一のリリースを適用先とし、環境固有の設定を保持します。具体的には、各 API 接続のコネクター、各イベントリスナーのコネクターとセットアップ状態、汎用リスナーの URL パス、各スケジュール済みトリガーの CRON と有効状態、各キューの有効状態、パラメーター値です。リリース済み環境でも、これらの設定は編集できます。それ以外はすべて読み取り専用となり、リリース後に作成されたリソースは、それを含むリリースがデプロイされるまで対象外です。

すべてのワークスペースは、HEAD を適用先とする Default という名前の環境を 1 つだけ持った状態で開始します。Default はその環境名です。CLI では、environment list が報告する ID を使って環境を指定します。HEAD を適用先とする環境を常に 1 つだけ維持し、その環境で開発してください。古いリリースを編集せず、新しいリリースを作成して修正してください。ロールバックするには、環境の適用先を以前のリリースまたは HEAD に変更します。スクリプトは context.environment.name を読み取ります。HEAD では context.deployment は未定義です。

ソース：https://docs.adaptavist.com/src/latest/workspaces/deployments-and-environments

パラメーター

型付きの環境ごとの値で、スクリプトは context.environment.vars から読み取ります。フォルダーの階層は 1 レベルまでです。TEXT や NUMBER から LIST、MAP、FOLDER まで、型は 11 種類あります。型は後から変更できません。デフォルト値は新しい環境やワークスペースのコピーに初期値として設定されますが、値そのものはコピーされず、実行時にデフォルト値が読み取られることもありません。必須パラメーターに値が設定されていない場合、ウェブアプリでは保存できません。CLI は必須かどうかを検証しないため、必須パラメーターでも未設定のままにできます。そのため、ev-params.ts では、必須かどうかにかかわらず、すべてのパラメーターをオプションとして宣言し、スクリプトでは使用前に値が設定されていることを確認します。必須パラメーターには、そこで JSDoc に Required: yes と記載します。

PASSWORD はスクリプトに渡されません。コードとログで確認できるのはプレースホルダーのみで、実際の値は送信する HTTP 呼び出しにのみ置換されます。そのため、PASSWORD の値をコード内でハッシュ化、署名、または base64 エンコードすることはできません。実行時の処理が必要な値には、--masked を指定して作成した TEXT パラメーターを使用してください。型の全一覧、置換の対象となるコンテンツタイプ、ev-params.ts への影響については、references/scripting.md を参照してください。

ユーザーの明示的な許可なしに、パラメーター値を読み取ってはいけません。 environment-parameter list は値を返します。また、TEXT、MULTILINE_TEXT、MAP パラメーターには、PASSWORD 型ではないシークレット（マスクされた TEXT など）を含められます。どのようなパラメーターがあるか確認するには、ワークスペースをクローンして ev-params.ts を読み取ってください。各パラメーターの説明、型、必須かどうかが記載されており、値は含まれていません。references/cli-workflow.md の Posture に、このルールが記載されています。

ソース：https://docs.adaptavist.com/src/latest/workspaces/parameters

API 接続と Managed API

API 接続はアウトバウンド側の接続です。ワークスペース内で一意のパス、ベンダー API パッケージ、環境ごとのコネクターで構成されます。スクリプトではこれをインポートします。import JiraCloud from './api/jira/cloud'。抽象化レベルは3段階あり、利用可能な中で最も高いものが優先されます。Managed API、ベンダー API を1対1で再現する型付きクライアント（例：JiraCloud.Issue.getIssue({ issueIdOrKey })）、ベース URL と認証が提供され、HTTP を記述する接続上の Managed fetch、そして何も提供されないグローバルな生の fetch です。Managed API はすべてのコネクターアプリで利用できます。アプリごとの公開リファレンスはなく、ワークスペース内の型定義がリファレンスです。monday.com の Managed API は GraphQL 形式で、args と fields を受け取ります。製品の API、Managed API、イベント型について型定義に記載されていない内容、410 を返す非推奨メソッド、イベント型に含まれないフィールドは、references/product-gotchas/ の製品ごとのファイルに記載されています。references/scripting.md の「Product gotchas」で説明されているとおり、スクリプトがその製品を呼び出す場合、またはその製品のイベントを処理する場合にのみ、該当ファイルを読み込んでください。

出典：https://docs.adaptavist.com/src/latest/workspaces/api-connections、https://docs.adaptavist.com/src/latest/managed-apis、GraphQL 形式については https://docs.adaptavist.com/src/latest/managed-apis/managed-api-for-monday.com

イベントリスナー

イベントリスナーは、アプリのイベント型をスクリプトに紐付けます。必要に応じてコネクターとイベントキューを介します。イベント型、スクリプト、キューはワークスペースレベルで、リリースに取り込まれます。コネクター、URL パス、有効状態は環境ごとに設定されます。リスナーからスクリプトを作成すると、適切な型付きイベントが割り当てられます。アプリに Webhook を登録する作業は人が行う必要があり、それをもって設定が完了します。CLI は登録するコールバックである webhookUrl と、手順を示す setupUrl を返します。ほとんどのアプリでは、プログラムから Webhook を登録できません。新しい環境では、コネクターを再リンクし、設定をやり直す必要があります。その環境にリスナーは存在し、disabled: false と表示されますが、URL パスは環境ごとに設定され、新しい環境にはまだ設定されていません。そのため、event-listener get -e <env> では urlPath と webhookUrl が null と表示され、リスナーは有効であるものの到達できません。その環境で最初に event-listener update を実行すると、URL パスが割り当てられます。汎用リスナーでは --url-path を指定し、それ以外では --disabled false のような変更を伴わない更新を行います。これによって生成される webhookUrl は HEAD のものと異なるため、Webhook を再登録します。ほとんどのリスナー型ではコネクターは不要です。コネクターが必要な型については、event-listener get が connectionRequired を報告します。それでも、チームがそのアプリの認証済みコネクターをすでに持っている場合は、リスナーに割り当ててください。アプリのベース URL がコネクターから取得され、Webhook のディープリンクがそれを基に作成されるため、設定手順が分かりやすくなります。コネクターがない場合はリスナーに割り当てず、リスナーに割り当てるためだけにコネクターを作成しないでください。テストイベントペイロードでは、保存済みのサンプルを使ってリスナーを実行します。新しいリスナーには、そのイベント型をサンプリングする Default ペイロードがあらかじめ用意されています。各アプリの登録手順、アプリ側で設定できるフィルター、Webhook の保護方法は、references/event-listener-setup/ のアプリごとのファイルに記載されています。references/cli-workflow.md の「Webhook handoff」で説明されているとおり、ユーザーに登録を依頼する際にのみ該当ファイルを読み込んでください。

出典：https://docs.adaptavist.com/src/latest/workspaces/event-listeners

汎用イベントリスナー

Generic アプリの HTTP_ENDPOINT リスナータイプです。プラットフォーム全体で一意となる URL パスへのあらゆる HTTP リクエストを受け付け、メソッド、パス、クエリ、ヘッダー、送信元 IP、コンテンツタイプに応じて json、text、base64 に解析された本文をスクリプトに渡します。モードは 2 種類あります。デフォルトは非同期です。呼び出し元には呼び出し ID を含む確認応答をすぐに返し、その後、通常の 15 分の制限時間内でスクリプトが実行されます。同期モードでは、呼び出し元はスクリプトが返すステータス、ヘッダー、本文を 25 秒以内待ちます。これを超えると呼び出し元には 408 が返され、レスポンスの形式が正しくない場合は 422 が返されます。

主な用途は、SRC が標準でサポートしていないアプリからイベントを受信することです。HTTP リクエストを送信できるものであれば、何でもスクリプトをトリガーできます。また、他の手段でイベントを送信できる場合は、独自のウェブフックを持たないアプリにも対応します。代表例は Confluence Cloud です。ウェブフックを提供していないためリスナータイプもありませんが、ScriptRunner for Confluence Cloud を使えば Confluence 内のイベントを監視し、汎用リスナーの URL に転送できます。これにより、結果的に SRC で Confluence Cloud のイベントフィードを利用できます。さらに 2 つのアプリも同じ方法で SRC にイベントを送信できます。Trello にはウェブフックを登録する API があるため、そのウェブフックの送信先に汎用リスナーを指定します。Google Calendar と Google Sheets にはコネクタレベルのイベントはありませんが、Google Apps Script でカレンダーやシートを監視し、汎用リスナーの URL に POST リクエストを送信できます。

同期モードではレスポンスを返すため、リスナーは受信だけでなく、何かを公開する手段にもなります。JSON で応答するスクリプトは、ワークスペースからアクセスできる任意のシステムの前段に置く、小規模な独自 API になります。ホスティング、認証ヘッダー、ログ記録は SRC が処理します。HTML で応答するスクリプトは、ステータスページ、フォーム、検索画面などのカスタムユーザーインターフェースになります。別途ウェブホストを用意せず、ワークスペースから配信できます。この 2 つの用途に加え、同じリスナーで、通常のウェブフックにはないセキュリティを追加できます。共有シークレットヘッダーの確認、sourceIp の許可リスト登録、署名の検証を行ってから処理を開始できます。これを行わない場合、エンドポイントは匿名でアクセス可能です。

スクリプトで確認を行わない汎用リスナーは、URL を秘密にしておくことだけで保護されています。しかし、URL はチャットメッセージ、ブラウザー履歴、プロキシログ、スクリーンショット、共有ドキュメント、通知ペイロードなどから漏れる可能性があります。非公開データの読み取り、状態の変更、スクリプトのトリガーを行うエンドポイントには、認証が必要だと考えてください。このようなエンドポイントを作成する場合は、指示がなくても確認処理を追加し、最後の要約でその旨を伝えてください。純粋な公開受け口の場合に限り確認処理を省略し、その旨を伝えてください。デフォルトの確認方法は、マスクされた TEXT パラメーターと共有シークレットヘッダーを照合し、確認に失敗した場合は処理を拒否するものです。コードは references/scripting.md の Generic HTTP events にあります。Slack に投稿するリンクやメールにシークレットを含めてはいけません。シークレットの入力を求めるページへのリンクを使うか、代わりに有効期間の短い署名付きトークンをリンクに含めてください。

ソース：https://docs.adaptavist.com/src/latest/workspaces/event-listeners/generic-http-events

スケジュールトリガー

秒を先頭にした 6 フィールドの CRON で、スクリプトを UTC で実行します。最短間隔は 15 分です。これより短いスケジュールは 15 分に引き上げられ、分単位の間隔は 15 の倍数にする必要があります。CRON と有効状態は環境ごとに設定され、スクリプトは共有されます。リリース後に作成したトリガーは、その環境を再デプロイするまでリリース済み環境では無効です。

ソース：https://docs.adaptavist.com/src/latest/workspaces/scheduled-triggers

イベントキュー

デフォルトでは並行処理されます。キューを使うと、リスナーのイベントを FIFO にし、たとえば issue.key のように、ペイロード内のドット区切りパスによる最大 10 個のグループ分けに従って独立したストリームに分割できます。退避ポリシーでは、キューに保持する最大時間（分）と、順序を無視して処理するか、メールを送信して破棄するかを指定します。キューに入った実行では context.queue.{id,name,groupId} と context.queuedAt を参照できます。有料の非レガシープランのみが対象です。team get で features.eventQueues を確認できます。

ソース：https://docs.adaptavist.com/src/latest/workspaces/event-queues

パッケージ

パッケージには 3 つの種類があります。コアパッケージである @sr-connect/convert、record-storage、trigger と、イベントライブラリ @sr-connect/<app> は、作成したリスナーとともに提供されます。管理対象 API パッケージである @managed-api/<service>[-v<N>]-sr-connect は、宣言した API 接続とともに提供されます。サードパーティの NPM パッケージは手動で追加します。いずれの種類も追加時点のバージョンに固定され、アップグレードは手動で行います。例外は @sr-connect/runtime-types だけで、常に最新バージョンが適用され、変更できません。ESM のインポートのみを使用できます。独自の型定義を持たないパッケージには、@types/<name> を併せて追加します。Node 専用に構築されたパッケージは動作しません。ランタイムは Web 標準のサブセットです。製品で動作確認済みの一覧は references/scripting.md を参照してください。

ソース：https://docs.adaptavist.com/src/latest/workspaces/package-manager

レコードストレージ

スクリプトが呼び出しをまたいで状態を保持するために使用するキーと値のストアです。取得、設定、削除、存在確認、キーの一覧表示ができます。スコープは環境、デフォルト、ワークスペース、チーム、呼び出しです。オプションには TTL、暗号化、上書き拒否があります。通常の書き込みでは上書きされ、最後の書き込みが優先されます。上書き拒否を指定した書き込みは、アトミックな「未存在の場合のみ作成」となり、競合する複数の書き込みのうち成功するのは厳密に 1 つだけです。これにより、ロック、冪等性ガード、追記ログを実現できます。チームごとにレート制限があり、自動的に再試行されます。容量はプランごとに異なります。「制限」を参照してください。

ソース：https://docs.adaptavist.com/src/latest/scripting/record-storage

スクリプトからスクリプトを起動する

@sr-connect/trigger は、同じ環境の別のスクリプトを JSON ペイロードとともに非同期で起動し、呼び出し ID を返します。作業の分散や長時間実行ジョブの構築に使用できます。たとえば移行では、各呼び出しを 15 分の制限以内に収め、進行状況をレコードストレージに保持しながら、呼び出しを連鎖させます。連鎖数には上限があります。「制限」を参照してください。実際の例として、Tempo Cloud の作業ログ移行テンプレートがあります：https://templates.scriptrunnerconnect.com/template/tempo-cloud-worklogs-migration?expand=true

ソース：https://docs.adaptavist.com/src/latest/scripting/triggering-scripts

コネクターと共有

コネクターにはアプリの認証情報が保持され、ワークスペースの外で作成され、ユーザーに属し、チームを通じて参照されます。共有には3つのレベルがあります。Useを付与すると、相手はワークスペース内でコネクターを使用でき、対象はすべてのチームまたは指定したチームです。Editを付与すると、名前の変更と再認証もできるようになります。Ownを付与すると、共有と削除もできるようになり、作成者が所有者であり続けます。チームのワークスペースに接続されたコネクターは、チームメンバーが暗黙的に使用できます。Useの権限を取り消す、チームの範囲を狭める、またはチームから抜けると、そのコネクターはワークスペースから強制的に切り離されます。ほとんどのコネクターはブラウザーで認証します。CLIでは未認証のコネクターを作成し、URLを返します。connector list と connector get では、コネクターが接続するベースURL、つまり認証に使われたAtlassianサイトまたはセルフマネージドホストが表示されます。このホストはコネクターがどのインストール先に接続しているかを判断する最も確かな手がかりであり、本番環境かどうかの判断にも役立つことがよくあります。名前だけでは何も判断できません。「Jira Cloud」という名前のコネクターが2つあっても、サンドボックスと本番サイトをそれぞれ指している可能性があるためです。connector list --app-id <appId> を使うと、1回の呼び出しですべてのコネクターについて表示できます。コネクターが未認証の場合、このフィールドは表示されません。認証済みかどうかにかかわらず、コネクターのレコードにホストが記録されないアプリでも、このフィールドは表示されません。該当するのは、GitHub、Azure DevOps、Bitbucket Cloud、Microsoft Teams、NetSuite、Zoom、Statuspageです。そのため、フィールドがないことは、これらのアプリについては何も意味しません。JiraおよびConfluence Cloud、オンプレミスのコネクター、GitLab、Zendesk、ServiceNow、Salesforce、monday.com、Opsgenieでは顧客固有のホストが記録されるため、ベースURLの確認が役立ちます。Slackではapi.slack.com上のアプリ設定ページが記録されます。これは接続先を区別する手がかりにはなりませんが、イベントリスナーが登録されているページです。2026-09-14のスナップショットは、Jira Cloudのコネクター、Slackのコネクター、未認証のGitHubコネクターから取得しました。残りの2つのリストについては、各コネクターがホストを保存するかどうかから判断できます。connector list のフィールドは2026-10-16に再確認しました。

各アプリのコネクターの認証方法、ウィザードで提供される方法、Genericコネクターを介した固定キーの代替方法については、コネクターの種類ごとに references/connector-setup/ 内のファイルを参照してください。コネクターの認証または再認証が必要な場合にのみ、ファイルを読み込んでください。手順は references/cli-workflow.md の「Connector setup」で説明しています。

Genericコネクターは、ベースURLと、ヘッダーなし、Basic認証ヘッダー、またはカスタムヘッダーを指定して、任意のHTTP APIに接続できます。OAuth 2.0には対応していません。その場合は、references/scripting.md のレシピを参照してください。API接続で公開されるのは fetch のみです。対応する @managed-api/*-sr-connect パッケージの <Product>Api クラスに connectionId を渡すことで、その上にManaged APIを構築できます。

出典：https://docs.adaptavist.com/src/latest/connectors, https://docs.adaptavist.com/src/latest/connectors/generic-connector

Egress Firewall

スクリプトからリクエストを送信できる宛先を、チーム単位で許可リストに登録します。スクリプトの送信リクエストは、宛先が承認済みのエントリーに含まれている場合にのみ実行されます。エントリーの種類は相互に適用されません。

• コネクターのエントリーを登録すると、そのコネクターを通じてスクリプトが行うリクエスト、つまりManaged APIと、API接続上のマネージド fetch が許可されます。
• Fetch APIの宛先エントリーを登録すると、グローバルな fetch 呼び出しで、指定した1つのホスト名へのアクセスが許可されます。https://API.Example.com:8443/v2 は api.example.com として保存され、サブドメインは別々のエントリーになります。ワイルドカードは拒否されます。また、localhost や 10.0.0.1、192.168.1.1 などのプライベート、ループバック、リンクローカルのアドレスも拒否されます。これらには、リストの内容にかかわらずスクリプトはアクセスできません。これらのアドレスに解決されるホスト名は受け付けられますが、実行時に失敗します。

https://api.example.com のGenericコネクターを許可しても、fetch('https://api.example.com/...') は許可されません。また、そのホスト名を許可しても、コネクターは許可されません。 エントリは、承認済みか承認待ちのいずれかです。追加する人がチームの Admin または Super Admin のロールを持ち、リクエストで自動承認を無効にしておらず、チームの接続数上限に空きがある場合に限り、その場で承認されます。それ以外の場合はリクエストとして記録され、チーム管理者にメールが送信されます。上限に達していてもエラーにはなりません。エントリは作成され、承認待ちになります。上限はプランのコネクター数で、team get の connections に表示されます。無制限プランでは max が null です。承認済みエントリは上限を使用します。API 接続で使われなくなった承認済みコネクターエントリ（usedByApiConnection: false）も、削除されるまで枠を占有します。承認待ちエントリは上限を使用しません。また、公開されている 2 つの ScriptRunner Connect API ホスト api.scriptrunnerconnect.com と api.us.scriptrunnerconnect.com も上限を使用しません。これらも他の宛先と同様にエントリが必要ですが、egress-firewall list では exemptFromLimit: true としてマークされています。

エントリが作成されると、公開 API で受け付けられる操作によって変更することはできません。管理者が自動承認を有効にして再度追加しても、API 接続がコネクターを再度アタッチしても、承認待ちエントリはそのまま承認待ちです。再度追加しても問題ありません。どちらの場合も、保存済みのエントリが変更されずに返されます。承認、却下、削除は、Web アプリの Team Settings、Egress Firewall からのみ行えます。コネクターを削除すると、そのエントリも削除され、上限の枠が空きます。Fetch API の宛先は、そこでのみ削除できます。枠を空けても、自動的に承認されるエントリはありません。枠が空くのを待っていたエントリは、管理者が承認するまで引き続き待機します。

コネクターを API 接続にアタッチすると、同じ呼び出しで許可リストに追加されます。上記のルールを満たす場合は承認されます。api-connection create と update は、アタッチされたコネクターの egressFirewall.state として、承認済み、承認待ち、未登録、またはデプロイメントにファイアウォールがない状態を返します。承認待ちエントリには、呼び出し元にとって承認を妨げている理由も、すべての書き込み操作とリストで表示されます。上限に達しており、枠が空くまで誰も承認できない、呼び出し元がチーム管理者ではない、呼び出しで承認を求めている、または妨げるものがなく、呼び出し元自身が Web アプリで承認できる、のいずれかです。egress-firewall check-api-connections は、同じ情報を 1 つの環境内のすべての API 接続について一度に読み取ります。チーム内の API 接続で使用されるまでは、コネクターを単独で追加できません。

ブロックされた呼び出しは、エラーコード 11007 で実行に失敗します。ランタイムが出力するメッセージは次のとおりです。

Request blocked by the team's Egress Firewall.
google.com is not on the allowed destinations list. A team admin can allow it under Team Settings → Egress Firewall. - ScriptRunner Connect Error code: 11007

Request blocked by the team's Egress Firewall.
The "Jira Cloud" connector is not on the allowed connectors list. A team admin can allow it under Team Settings → Egress Firewall. - ScriptRunner Connect Error code: 11007

別のエラーは別の原因を示します。エラーコード 10001 はランタイムが接続に失敗したことを示し、ファイアウォールより先に確認されます。Connection not allowed for URL は、名前解決できないホスト名、またはスクリプトから到達できないアドレスを意味します。この場合は URL または DNS を修正します。許可リストで修正することはできません。それ以外の 10001 メッセージは原因を示します。呼び出しを行うサービスのメモリが不足した、または応答が大きすぎてスクリプトに返せないというメッセージは、取得するには大きすぎる応答を意味します。ページを小さくして取得するか、ベンダーのエクスポート機能を使用してください。呼び出しがタイムアウトしたというメッセージは、リモートホストが応答全体の送信に時間をかけすぎたことを意味します。Error while performing HTTP call (Fetch API) は、応答を受信できなかったコネクター呼び出しなど、残りのケースを示します。このメッセージだけではファイアウォールが関係しているかどうかわからないため、そのワークスペースと環境で egress-firewall check-api-connections を実行してください。そこで APPROVED と表示された場合は、ベンダー、コネクターのベース URL、または接続を確認してください。それ以外の状態は、呼び出しもブロックするため、修正が必要なエントリを示しています。「Request blocked by the team's Egress Firewall」というメッセージを伴う 11007 だけが、ファイアウォール自体からの応答です。 デプロイメントは、ファイアウォールが有効かどうかを示します。プライベートクラウドのインスタンスではファイアウォールなしで実行でき、その場合、egress-firewall list は EGRESS_FIREWALL_DISABLED で拒否され、何もフィルタリングされず、ここでの内容も適用されません。この機能より前のデプロイメントで同じ読み取り操作を行うと、Path not found と終了コード 4 が返され、こちらも何もフィルタリングされません。これらのいずれかの応答で無効と分かるまでは、ファイアウォールが有効であると想定してください。エージェントが承認を求め、エントリーを追加し、人間の確認のために処理を止める方法については、references/cli-workflow.md の「Egress Firewall」を参照してください。

チーム

役割は 3 つあります。メンバーは、自分と共有されているワークスペース、使用状況、メンバー一覧を確認できます。管理者はそれに加えて、チーム内のすべてのワークスペースを開き、スーパー管理者より下位の役割への招待や編集、共有設定の変更、および自分が管理するチーム間でのワークスペースの移動ができます。スーパー管理者はそれに加えて、すべての役割、プラン、請求情報を編集でき、チームを削除できます。ワークスペースを編集できるのは一度に 1 人だけです。他のユーザーには読み取り専用のコピーが表示され、編集権限を引き継ぐことができます。CLI のワークスペースロックは、この編集権限と同じ仕組みです。

出典：https://docs.adaptavist.com/src/latest/collaborate-with-teams

可観測性

呼び出しログはチームごとに 6 か月間保持されます。各行にはステータス（Finished、Running、Denied、Timed out、Aborted、Function Error、Malformed Payload Error、Runtime Error のいずれか）、トリガーの種類（Manual、Manual Event Listener、External、Chained、Scheduled のいずれか）、コンソールログ数、HTTP ログ数が記録されます。コンソールログは呼び出しごとに最大 1,000 行で、1 行が大きすぎる場合は別途保存されます。HTTP ログには、ヘッダーと本文をそれぞれ 1 KB を超える部分で切り詰めた、すべての送信リクエストが記録されます。監査ログには、ユーザーのすべての操作が 6 か月間記録されます。リプレイでは、イベントトリガーによる呼び出しを編集可能なペイロードで再実行できます（手動実行とスケジュール実行は対象外で、上限は 4 MB です）。スクリプト失敗通知は、捕捉されないエラーが発生した場合に、ユーザー、ワークスペース、環境ごとにメールを送信します。

出典：https://docs.adaptavist.com/src/latest/observability

セキュリティ

AWS を使用し、サインアップ時に EU（アイルランド）または米国（オレゴン）を選択します。選択したリージョン外にデータが保存されることはありません。認証情報は AWS KMS AES-256-GCM で暗号化され、転送中は TLS 1.2 で保護されます。スクリプトは新しい V8 アイソレートで実行されます。強化された分離機能では、コールドスタートが増える代わりに、テナントごとに専用のコンピューティングリソースを使用します。ISO 27001、SOC 2 Type 2、GDPR に準拠し、CREST によるテストを受けており、Bugcrowd のバグ報奨金プログラムを実施しています。アプリ内の AI 機能では OpenAI モデルを使用しますが、コードがトレーニングに使用されることはありません。

出典：https://docs.adaptavist.com/src/latest/security

テンプレート

テンプレートは、特定のユースケース向けの接続、トリガー、コードを含む、公開済みのワークスペースです。ほとんどはサンプルです。ユースケースが合致する場合は、Sync カテゴリと Migration カテゴリにある、すぐに使える連携機能を出発点にするのがおすすめです。手順：template list で ID とプレビュー URL を確認します。同期または移行の場合は、https://templates.scriptrunnerconnect.com/ の公開ライブラリも参照してください。sitemap.xml にすべてのテンプレートが一覧表示され、/template/<slug>?expand=true で README とソース全体が表示されます。workspace create --source-template-id でテンプレートから作成します。言語は引き継がれるため、その後 ts-strict にアップグレードしてください。

出典：https://docs.adaptavist.com/src/latest/templates

REST API と CLI

アカウントのメールアドレスと、ユーザーメニューの「API Keys」で作成した API キーを使って Basic 認証を行います。キーは一度だけ表示されます。ベース URL は EU の場合 https://api.scriptrunnerconnect.com、米国の場合 https://api.us.scriptrunnerconnect.com です。CLI の @sr-connect/cli はこの API のクライアントで、ワークスペース、環境、パラメーター、スクリプト、リスナー、ペイロード、キュー、API 接続、コネクター、共有、パッケージ、リリース、ロック、ログ、リプレイ、停止に対応しています。

出典：https://docs.adaptavist.com/src/latest/rest-api

AI アシスタント

ウェブアプリには組み込みのアシスタントがあります。外部から作業する場合は、自身の機能を使い、組み込みアシスタントは無視してください。

プランとホスティング

プラン	コネクター	月間の実行回数	イベントキュー	ホスティング
Free	4	5,000	なし	AWS 共有環境、EU または US
Basic	4	無制限（上限 500,000）	あり	AWS 共有環境
Advanced	8	無制限	あり	AWS 共有環境
Pro	無制限	無制限	あり	AWS 共有環境
Enterprise	無制限	無制限	あり	プライベート AWS アカウント、VPC は任意

プランはチームに属し、その上限はチーム内のすべてのワークスペースで共有されます。「コネクター」列はチームの接続数の上限であり、承認済みの Egress Firewall エントリーもこの上限に含まれます。詳しくは「Egress Firewall」をご覧ください。SSO は Enterprise 未満のプランでは有料のアドオンです。Free プランのサポートはコミュニティのみです。

出典：https://www.scriptrunnerhq.com/atlassian-apps/jira/scriptrunner-connect-pricing

制限

出典：https://docs.adaptavist.com/src/latest/limits-and-quotas および上記のページ。

制限	値
非同期呼び出しの実行時間	15 min
同期 HTTP 呼び出しの実行時間	25 s
呼び出しごとのメモリ	400 MB。有料プランでは、サポートを通じて 800 MB のバリエーションをリクエストできます
イベントペイロード	6 MB
再生ペイロード	4 MB
呼び出しの連鎖	200
呼び出しごとのコンソール行数	1,000
保持される HTTP ログ本文	1 KB。その後は切り捨てられます
スケジュール済みトリガーの間隔	最短 15 min
リスナーごとのキューグループ数	10
ログの保持期間（監査、呼び出し、HTTP）	6 months
レコードストレージ	Free 100 MB、Basic 1 GB、Advanced 5 GB、Pro 10 GB
ワークスペースごと：API 接続、リスナー、ペイロード、トリガー、環境	各 1,000
ワークスペースごとのデプロイ数	10,000
アカウントごとのワークスペース、コネクター	各 1,000
スクリプト呼び出し（チーム）	Free 1/s、有料 100/s
外部 API 呼び出し（チーム）	Free 5/s、有料 100/s
レコードストレージ呼び出し（チーム）	Free 1/s、有料はプランに応じて最大 50/s。すべてのワークスペースと呼び出しで共有されます
トリガースクリプト呼び出し（チーム）	Free 1/s、有料 10/s
REST API 呼び出し（ユーザー）	Free 5/s、有料 20/s。ユーザーのすべての API キーとエージェントで共有されます

ひと段落でわかるランタイム

Node ではありません。Web 標準のサブセットを実装したカスタム V8 ランタイムで、構文と標準ライブラリの両方が ES2020 に準拠し、ESM のみをサポートします。fetch の本文は完全にバッファーされ、Request／Response／Headers／URL／FormData／Blob、TextEncoder／TextDecoder、btoa／atob、タイマー、console、およびキーの生成、署名、検証のみをサポートする crypto.getRandomValues と crypto.subtle が利用できます。送信するすべての呼び出しには、そのコネクター用の承認済み Egress Firewall エントリーが必要です。生の fetch の場合は、ホスト名のエントリーが必要です。Buffer、process.env、node:*、WebSocket、ストリーム、subtle.digest、およびプローブで確認されるまでは ES2020 より新しいライブラリメソッドやオプションは利用できません。既知の例外は Intl.DateTimeFormat の timeStyle です。@sr-connect/convert は Buffer の変換に代わり、jose-browser-runtime は JWT に署名します。全体の表とコーディングルールについては references/scripting.md を参照してください。

ソース：https://docs.adaptavist.com/src/latest/scripting/runtime

コネクター一覧、2026-09-15 時点

ソース：https://docs.adaptavist.com/src/latest/connectors と Web アプリケーションの認可ウィザード。すべてのコネクターに Managed API があります。ID を含む最新のカタログは app list で確認できます。構築時にはこの表を鵜呑みにせず、カタログを照会してください。各アプリのイベントライブラリと Managed API パッケージの NPM 名は references/scripting.md に記載されています。この表のアプリ名から推測することはできません。Auth 列にはウィザード独自の方式が記載されています。アプリごとの手順は references/connector-setup/ にあります。

コネクター	認証	イベントリスナー
AWS	生成された信頼ポリシーを使用する IAM ロール、またはアクセスキー	いいえ
Azure DevOps	OAuth 2.0、プラットフォームの Azure アプリ、または独自のアプリ	はい
Bitbucket Cloud	OAuth 2.0、独自の OAuth クライアント	はい
Bitbucket On-Premise	OAuth 2.0、独自の受信アプリケーションリンク	はい
Confluence Cloud	OAuth 2.0、プラットフォームのアプリ、または独自のアプリ	いいえ、汎用リスナーを介してブリッジします
Confluence On-Premise	生成されたキーペアを使用するアプリケーションリンク	はい
GitHub	OAuth 2.0、プラットフォームの GitHub アプリ	はい
GitLab	OAuth 2.0、gitlab.com 上のプラットフォームのアプリ、または独自のアプリ	はい
Google Calendar	Google サインイン、プラットフォームのアプリ	いいえ、Google Apps Script からブリッジします
Google Drive	Google サインイン、プラットフォームのアプリ。プラットフォームで作成されたファイルのみ	いいえ
Google Sheets	Google サインイン、プラットフォームのアプリ	いいえ、Google Apps Script からブリッジします
Jira Cloud	OAuth 2.0、プラットフォームのアプリ、または独自のアプリ	はい
Jira On-Premise	生成されたキーペアを使用するアプリケーションリンク	はい
Jira Service Management Cloud	OAuth 2.0、プラットフォームのアプリ、または独自のアプリ	はい、Jira Cloud のウェブフック経由
Jira Service Management Cloud Assets	メールアドレスと API トークン	いいえ
Jira Service Management On-Premise	Jira On-Premise と共有	はい
Jira Service Management On-Premise Assets	Jira On-Premise と共有	いいえ
Microsoft	OAuth 2.0、プラットフォームの Azure アプリ（Teams のみ）、または独自のアプリ	はい
monday.com	OAuth 2.0、管理者がインストールしたプラットフォームのアプリ	はい
NetSuite	生成された証明書を使用するクライアント認証情報	はい
Opsgenie	API キー	はい
Salesforce	OAuth 2.0、独自の Connected App	はい
ServiceNow	OAuth 2.0、独自の OAuth API エンドポイント	はい
Slack	アプリ ID、署名シークレット、ボットトークン	はい
Statuspage	API キー	はい
Tempo Cloud	OAuth 2.0、Tempo 上の独自のアプリケーション	いいえ
Tempo Planner On-Premise	Jira On-Premise と共有	いいえ
Tempo Timesheets On-Premise	Jira On-Premise と共有	いいえ
Trello	独自の Power-Up の API キーとトークン	いいえ、API を介してウェブフックを登録します
Zendesk	OAuth 2.0、独自の OAuth クライアント	はい
Zoom	OAuth 2.0、独自の General アプリ	はい
Generic	なし、基本認証、ヘッダー	はい、汎用 HTTP イベント
ほとんどのリスナーアプリには、サンプルのテストペイロードがあります。Zoom、Azure DevOps、Microsoft、NetSuite、Salesforce、ServiceNowにはありません。これらのペイロードは、各アプリのドキュメントを参考に作成してください。

依頼の種類

依頼	最初に行うこと	読み込むもの	CLI が必要
SRC で X ができるか、X の仕組みを知りたい	このファイルをもとに回答します。既存のワークスペースが指定されている場合は、まずそのセットアップを読みます	ワークスペースを読む場合のみ cli-workflow.md	場合による
何かが失敗したので調べてほしい	チーム、ワークスペース、期間を確認します。呼び出しログを読み、次にコンソールログと HTTP ログを読み、その後スクリプトを確認します	cli-workflow.md、次に修正に必要な scripting.md と product-gotchas/<app>.md	はい
インテグレーションを構築または変更したい	要件を集め、コネクターと環境を調査し、ロックを取得してクローンします	cli-workflow.md、scripting.md、スクリプトが呼び出す製品ごとの product-gotchas/<app>.md	はい
単発のジョブ	cli-workflow.md の簡単な手順を使います。繰り返し実行するか確認し、繰り返さない場合は実行後に削除します	cli-workflow.md、scripting.md	はい
Webhook を登録したい、またはイベントが届かない	リスナーとそのコネクターを読み、その後、該当するアプリのファイルを 1 つ読み込みます。cli-workflow.md の Webhook の引き継ぎを参照してください	cli-workflow.md、event-listener-setup/<app>.md	はい
コネクターを認証したい、または動作しなくなった	まず connector list と connector get を実行します。新しいコネクターまたは期限切れのコネクターを認証する必要がある場合に限り、該当するコネクターのファイルを 1 つ読み込みます。cli-workflow.md のコネクターのセットアップを参照してください	cli-workflow.md、connector-setup/<type>.md	はい
実行がエラーコード 11007 で失敗する	Egress Firewall が接続先をブロックしました。egress-firewall check-api-connections でコネクター名を ID に対応付け、egress-firewall list でホストを確認します。cli-workflow.md の Egress Firewall を参照してください	cli-workflow.md	はい
実行がエラーコード 10001 で失敗する	Connection not allowed for URL：Egress Firewall の問題ではありません。ホスト名が解決できないか、アドレスがプライベートです。URL と DNS を確認し、エントリーは追加しないでください。メモリ不足またはサイズ超過の場合は、ページを小さくします。コネクターの呼び出しで Error while performing HTTP call (Fetch API) が発生した場合は、まず egress-firewall check-api-connections を実行し、Egress Firewall を参照してください	scripting.md、cli-workflow.md	場合による
テスト	依頼された場合に限ります	testing.md	はい

専用コネクターがない場合は、固定キー認証に Generic コネクターを使用します。OAuth の場合は、代わりにワークスペースでフローを設定します。手順は references/scripting.md にあります。専用コネクターがあるものの、ユーザーがウィザードで提示されるすべての方法を拒否した場合は、ベンダーが対応していれば、references/connector-setup/ にあるアプリのファイルに、Generic コネクターを使う固定キー認証の代替方法が記載されています。

フィードバックの送信

agenticFeedback スイッチがオンの場合、作業内容に関するメモが ScriptRunner Connect チームに送られます。メモに何を含めるか、いつ投稿するか、送信に使う動詞については、references/cli-workflow.md の Feedback を参照してください。スイッチがオフの場合、ユーザーは望んでいません。メモを残さず、有効にするよう促すこともなく、概要でフィードバックに触れることもありません。

質問する

最初にまとめて確認してください。最初の変更を加える前に、作業で有効にするものをすべて確認します。対象となるアプリと環境、本番環境の定義、各アプリの非本番環境の有無、ない場合はユーザーが用意するかどうか（所要時間は references/dev-instances.md に記載）、プローブを実行してよいか、プローブで変更を加えてもよいか、テスト用ペイロードでシミュレーションループを実行してよいか、作業で追加する Egress Firewall エントリを自動承認してよいか、希望するパッケージのアップグレード、エンドツーエンドでのテスト方法です。10 分ごとに質問するより、最初に一度に質問するほうがユーザーの負担は軽くなります。これにより、許可された時間だけシミュレーションループを実行して構築し、テストできる状態になったら一度だけ戻って報告できます。待機と構築は別です。ユーザーが発生させるイベントやユーザーからの承認を待つ場合、references/cli-workflow.md の Posture にあるとおり、1 回の待機は 30 分で終了します。

非常に重要：計画を求められても、この確認を省略してはいけません。どの環境があるか、本番環境の定義、プローブの実行可否を知らずに書く統合の計画は、推測を計画らしく見せているだけです。ハーネスにどのような質問手段が用意されていても、計画モードを含め、計画を書く前にそれを使って確認してください。計画はワークスペースと対象アプリの状況によって変わります。したがって、プローブには計画の後ではなく前に着手します。ただし、プローブの実行についてユーザーの同意を得てからに限ります。同意がなければプローブは実行せず、CLI で許可されている読み取りとユーザーからの情報に基づいて計画を作成し、プローブで確認できたはずの各箇所を明記してください。

最初にまとめて質問するからといって、推測してよいわけではありません。回答で触れられていない疑問が作業中に生じた場合や、プローブで事前に聞いた内容と矛盾するものが見つかった場合は、作業を止めて確認してください。統合で誤った前提を置くと、実システムを使ったデバッグをもう一度行うことになります。質問にかかるのは 1 分です。プローブで答えが分かる場合はプローブを実行し、ユーザーにしか答えられない場合は質問してください。作業の勢いを保つために、どちらも省略してはいけません。

明らかに一致していても、それは推測にすぎません。依頼でリソース名が曖昧に示されていて、たとえば「Jira コネクタ」や名前の一部だけで示されたスクリプトを検索した結果、候補が 1 つだけ見つかったとしても、それだけを根拠に書き込みを行ってはいけません。何を照合したのかを、名前だけでなく ID も示して伝え、何を行うのかを説明し、ユーザーの返答を待ってください。読み取りにこの確認は必要ありません。先にプローブを実行し、候補を確認の際に示してください。どれを指しているかを先にユーザーに尋ねる必要はありません。

候補が 1 つだけ見つかったことは、確認を省いてよい理由ではなく、落とし穴です。サンドボックス用コネクタと本番用コネクタは同じ名前であることがよくあり、スクリプト名はワークスペース間で重複します。また、候補が 1 つしか見えないのは、スコープが間違っているからかもしれません。依頼が厳密で、ID が指定されている場合や、他に似たものがない名前が指定されている場合は、そのまま進めてください。