runtime-behavior-probe

ランタイム動作の調査

概要

コードやドキュメントの内容を言い換えるのではなく、実際のランタイム動作を調査するには、このスキルを使用します。まず調査を計画し、次にケースマトリックスを実行して、観察した動作を記録したうえで、調査結果とその取得方法の両方を報告します。

基本ルール

• このスキルは手動でのみ使用してください。暗黙的な呼び出しには依存しないでください。
• このスキルの呼び出しによって許可されるのは、計画の作成のみです。実行時の調査を行う場合は、調査内容を正確に提示した後、ユーザーから明示的な承認を得る必要があります。このスキルの呼び出しや、実行時の挙動を調査したいという一般的な依頼を、実行の承認とみなさないでください。
• 承認を求める前に、提案する調査の対象、正確なコマンド、推移的に実行されるもの、既知のファイルシステム・環境・ネットワーク・ホストサービスに対する機能、予想される副作用、制御方法を開示してください。不明な機能は、利用不可と決めつけずに不明と明記してください。
• 実行前に、肯定的な返答を待ってください。承認の対象は、開示した対象、コマンド、実行されるもの、機能の範囲に限られます。これらの項目を変更する場合、別の調査を追加する場合、または承認済みのマトリックスを拡張する場合は、あらためて承認を得てください。
• openai-agents-js では、このスキルをリポジトリ実装のワークフローではなく、一時的な調査のワークフローとして扱ってください。
• ユーザーが再利用可能なリポジトリアーティファクトを明示的に求めない限り、書き込み可能な範囲は次のとおりです。
  • 調査用スクリプトまたはアーティファクトに使用する一時ディレクトリ
  • ユーザーがこのスキル自体を編集している場合の .agents/skills/runtime-behavior-probe/**
• openai-agents-js で一時的な調査を行う場合、examples/**、packages/**、いずれかの package.json、README.md、ワークスペース設定、ビルド設定は変更しないでください。
• 計画案が許可されていないパスに触れる場合は、何も編集せずに中断し、計画を作り直してください。
• まずベースラインの成功例またはスモークテストから始めるのが適切な場合は多いですが、実際の疑問にエッジケース、変動、または失敗時の挙動が関係する場合は、そこで止めないでください。
• 実行前に計画を立ててください。最初にケースマトリックスを作成し、その後、観測した結果を記入してください。マトリックスはスクラッチノート、一時ファイル、または調査用スクリプトのヘッダーに置けます。
• ローカルまたは読み取り専用の調査を優先して提案してください。ライブサービスを検討するのは明らかに関連性がある場合に限り、承認を求める前に以下の簡易ゲートを適用してください。
• 判断に必要な範囲に調査を収めてください。現在の仮説を否定または検証できる最小のマトリックスから始め、不確実性が残る場合にのみ拡張してください。
• ライブ調査の前に、次の3つの簡易ゲートを適用してください。
  • 接続先ゲート。タスクで明確に許可されているライブの接続先のみを使用してください。
  • 意図ゲート。ユーザーがその連携に関する実行時検証を明示的に希望している場合にのみ、ライブ調査を提案してください。実行には、調査内容を正確に提示した後、別途承認が必要です。
  • データゲート。調査で環境変数の読み取り、リモート状態の変更、相応の費用の発生、または非公開データやユーザーデータの使用がある場合は、対象となる正確な変数名またはデータの種類を明示し、事前に明示的な承認を得てください。
• 実行前に各ケースを、読み取り専用、変更あり、または費用発生ありに分類してください。変更ありまたは費用発生ありのケース、あるいは環境変数を読み取るライブケースでは、調査の実行前にクリーンアップまたはロールバックの方法を定めてください。
• 単発の調査用スクリプトには、一時ファイルまたは一時ディレクトリを使用してください。
• openai-agents-js では、既定で git の追跡対象外に一時的な調査ファイルを置いてください。ユーザーがチェックイン対象のアーティファクトを明示的に求めない限り、単発の調査、ハーネス、ベンチマーク、サンプルを examples/、packages/、その他のリポジトリディレクトリに追加しないでください。
• 最終回答の作成が終わるまで、一時的なアーティファクトを保持してください。その後、ユーザーが保持を依頼した場合、または後続作業で必要な場合を除き、既定で削除してください。アーティファクトを削除した場合でも、コマンドの形式、実行時のコンテキスト、アーティファクトの状態を簡潔にまとめて報告してください。
• 環境変数を読み取るライブ調査を実行する前に、使用予定の正確な変数名とその使用理由をユーザーに伝え、明示的な承認を待ってください。例として、OPENAI_API_KEY や、対象システムで想定されるその他の標準的な名前があります。
• 環境変数の承認ゲートが必要で、request_user_input ツールが利用可能な場合は、プレーンテキストで承認を求めるのではなく、そのツールを使用してください。「今回のみ許可（推奨）」や「許可しない」など、相互排他的な選択肢を含む簡潔な質問を1つだけ行い、autoResolutionMs は省略してください。承認は単一の調査に限定し、名前を明示した変数と接続先に限ってください。このツールを利用できない場合は、簡潔なプレーンテキストの質問に切り替え、ユーザーが明示的に承認するまで実行しないでください。
• 標準の環境変数に含まれている場合でも、シークレットを決して出力しないでください。
• このリポジトリで OpenAI API または OpenAI プラットフォームを調査する場合は、パラメーター、フィールド名、上限など、仕様に左右される詳細を早期に確認するため、$openai-knowledge を使用してください。実行時の調査は、ドキュメント確認を省略するためではなく、記載された挙動を検証または再評価するために使用してください。ドキュメント MCP を利用できない場合は、公式 OpenAI ドキュメントを代替として使用し、その旨を報告してください。
• ベンチマークまたは比較の調査では、実行前に条件の同等性を明確にしてください。固定する条件、検証する変数、公平な比較を保つ応答形式の制約、レイテンシや費用の解釈に関係する使用量またはトークンのカウンターを記録してください。
• openai-agents-js では、調査用コードの作成には軽量なローカルループを既定としてください。一時的な probe.ts と一時的な tsconfig.json を使い、pnpm exec tsc --noEmit -p <tmp-tsconfig> を実行してから、pnpm exec tsx <tmp-probe> を実行します。dist/、出力されたエクスポート、またはパッケージ化された出力が実行時の疑問に特に関係する場合にのみ、pnpm build に進んでください。
• openai-agents-js では、実行時の検証、ベンチマーク、またはモデル比較の依頼を、再利用可能な例、ベンチマークハーネス、パッケージスクリプト、チェックイン対象サンプルを追加する許可とみなさないでください。これらのリポジトリ変更には、ユーザーの明示的な意図が必要です。
• OpenAI ホスト型ツールを調査する場合、否定的な結果を実行時の挙動に帰属させる前に、セットアップの曖昧さを取り除いてください。
  • ツール呼び出しが検証対象の場合は、対応する tool_choice を使ってツールの経路を強制してください。
  • container_auto と container_reference は、互換性のあるセットアップの詳細ではなく、別々のケースとして扱ってください。
  • 調査結果を無効にしないよう、サポートされていないモデルまたはツールのオプションは、まず取り除いてください。

Workflow

1. 調査対象を運用上の観点から言い換えます。ランタイムの対象領域、主要な不確実性、テストすべき最もリスクの高い動作を明示します。
2. openai-agents-js では、実装作業を始める前に、許可される書き込み範囲を宣言します。通常の使い捨てプローブでは、一時ディレクトリのみとします。
3. 事前確認を簡潔に行います。まず関連するコードやドキュメントを確認し、ローカル検証とライブ検証のどちらが必要かを判断して、重要なリポジトリ、ベースライン、リリースの境界を記録します。
4. マトリクスを作成する前に、判断シグナルを定義します。不具合が疑われる場合は、ユーザーに見える具体的な症状、それを正常な動作と区別できるコマンドまたはプローブ、予想される失敗時の観測結果、正常動作が確認済みの対照ケースを明示します。そのシグナルが、隣接するヘルパーだけでなく、実際のプロデューサーと呼び出し元の経路を検証することを確認します。問いに答えられる場合は、高速で決定論的なローカルループを優先します。信頼できるシグナルを作れない場合は、不足しているアクセス権や成果物を明示し、近接する別の動作を証拠の代わりにしないでください。
5. プローブを実行する前に、検証マトリクスを作成します。ベースラインの動作と、関連性の高い失敗または逸脱のケースを両方含めます。マトリクスは、スクラッチノート、一時ファイル、またはプローブスクリプト内の構造化されたヘッダーに記載できます。
6. 各ケースについて、実行モードを事前に選択します。
   • 決定論的な単発チェックには single-shot を使用します。
   • キャッシュ、リトライ、ストリーミング、中断、レート制限、同時実行、その他の実行ごとの変動の影響を受ける動作には repeat-N を使用します。
   • 初回実行のコールドスタート効果が結果を歪める可能性がある場合は warm-up + repeat-N を使用します。タスクで明確に別の方法が必要でない限り、次をデフォルトとして使用します。
   • 実行ごとの変動がある問いの簡易スクリーニング：repeat-3。
   • 意思決定に使えるレベルのレイテンシー測定またはリリース推奨：warm-up + repeat-10。
   • コストの高いライブケース：まず repeat-3 で開始し、回答が不明確な場合にのみ拡張します。追加の実行にかかる時間やコストに見合うか本当に判断できない場合は、プローブを拡張する前にユーザーに確認します。
7. 問いがベンチマーク形式または比較を伴う場合は、段階的に実行します。まず対照ケースを含む、情報量の高いパイロットマトリクスを実行し、その後、候補として残ったケースまたは未解決のケースのみを拡張します。
8. 問いが回帰または動作変更の疑いに関する場合は、origin/main、最新リリース、または疑わしいオプションを指定しない同一リクエストなど、正常動作が確認済みの対照ケースを少なくとも1つ追加します。
9. 比較プローブでは、実行前に同等性の条件を定義します。プロンプトまたは入力の形式、ツール選択の設定、モデル設定の同等性、状態の再利用ルール、公平な比較を保つ応答形式の制約を記録します。出力長に大きな差があり結果が偏る可能性がある場合は、使用量またはトークンに関する注記も記録します。
10. あるオプションが別のオプションと同等の知能または品質を持つかを問われた場合、マトリクスで示せるのが例示したパターンの同等性のみか、より広範な品質の主張かを判断します。より広範な主張をする場合は、少なくとも1つ、より難しいケースまたは自由度の高いケースを追加します。そうでない場合は、結果が対象としたパターンに限られることを明記します。
11. 隠れた状態が結果に影響する可能性がある場合は、実行前に状態の制御方法を計画します。各ケースで状態を新規作成するか再利用するか、キャッシュの再利用またはキャッシュバスティングをどう扱うか、繰り返しの実行を分離する一意のID、クリーンアップの検証方法を記録します。
12. ライブケースが環境変数を読み取る場合は、ケースごとに変数名と用途を正確に列挙し、実行前にユーザーの承認を求めます。この承認ゲートでは、利用可能な場合は request_user_input を優先し、自動解決は行わず、この特定のプローブのみを許可または拒否する選択肢を用意します。承認の依頼は簡潔にし、実行先、読み取り専用か変更またはコストを伴うリスクがあるか、正確な変数名、該当する場合はクリーンアップまたはロールバックを含めます。
13. タスク固有のプローブスクリプトは一時的な場所に作成します。スクリプトは小さく、観測しやすく、簡単に破棄できるものにします。
14. openai-agents-js 用のスクリプト、サンプル、ベンチマーク、またはワークスペーススクリプトをリポジトリに追加する提案をしようとしている場合は、ユーザーが再利用可能なリポジトリ成果物を明示的に求めたかどうかを確認するため、いったん立ち止まります。明示的な依頼がなければ、プローブは一時的なものにします。
15. openai-agents-js では、ランタイムコンテキストを明示します。

• 実用的な場合は、リポジトリのルートから pnpm exec tsx で TypeScript プローブを実行します。
• プローブを作成する場合は、probe.ts と、mktemp -d 配下に一時的な tsconfig.json を兄弟として両方作成し、最初のライブ実行の前に pnpm exec tsc --noEmit -p <tmp-tsconfig> を実行します。
• 現在のコミット、作業ディレクトリ、Node 実行ファイル、Node バージョン、およびインポートしたパッケージまたはソースパスを記録します。
• 別のチェックアウトや /tmp/node_modules からの偶発的なインポートを避けます。プローブがリポジトリのコードを必要とする場合は、process.cwd() をルートとするリポジトリ相対の file:// URL からインポートします。
• 質問が「このブランチは今何をするのか?」である場合は現在のブランチの src/ インポートを優先し、質問がビルド後のパッケージ化された出力に特化している場合にのみ dist/ インポートを優先します。
• 使い捨てのプローブを型チェックするためだけにリポジトリ全体のビルドを実行しないでください。pnpm build は dist/ プローブ、または出力された結果自体が質問の一部である場合のために取っておきます。

16. 上記で求められる開示を含む完全なプローブ提案を、各ケースまたは承認済みマトリックスの正確なコマンドとともに提示し、その後、ユーザーに明示的な承認を求めて待機します。
17. 承認されたマトリックスのみを実行し、証拠を取得します。リクエストの形、セットアップ、観察の要約、予期しない結果または否定的な結果、エラーの詳細、タイミング、ランタイムコンテキスト、承認された環境変数名、繰り返し回数、ウォームアップの扱い、関連する場合はばらつき、クリーンアップの挙動を記録し、比較については何を一定に保ったか、および解釈に影響するレスポンス形状や使用上の注意を記録します。
18. マトリックスは推測ではなく、実際の結果で更新します。
19. 最終回答を作成するまで一時的な成果物を保持します。その後、ユーザーが保持を求めた場合、またはフォローアップに必要な場合を除き、それらを削除します。ベンチマークや繰り返しの多いプローブはフォローアップが必要になることが多いため、結果を再訪する可能性がある場合は成果物を保持するのが普通です。削除した場合は、短い実行サマリーを保持して報告します。
20. まず調査結果を報告し、予期しない結果または否定的な結果を最初に示します。次に、検証がどのように行われ、どのケースがカバーされたかを要約します。
21. プローブが 1 つの明確な欠陥を切り分ける場合は、短い実装仮説や最小限の再現の方向性を含めてもかまいません。ユーザーが求めていない限り、より大きな次のステップの計画にまで広げないでください。

検証マトリックス

ニュースをすばやく読み取れるようにするマトリックスを使用します。expected と pass または fail だけでなく、ランタイムの問いと観察の要約から始めます。

少なくとも次の列を持つマトリックスを使用します:

• case_id
• scenario
• mode
• question
• setup
• observation_summary
• result_flag
• evidence

調査を実質的に改善する場合は、次の列を追加します:

• comparison_basis
• variable_under_test
• held_constant
• output_constraint
• status
• confidence
• state_setup
• repeats
• warm_up
• variance
• usage_note
• risk_profile
• env_vars
• approval
• control

result_flag は unexpected、negative、expected、blocked などのすばやくスキャンするためのフィールドとして扱います。status は、比較できる信頼性の高い基準、ベースライン、または文書化された契約が存在する場合にのみ使用します。

マトリックスに次のカテゴリを含めるべきかどうかを常に検討します:

• ベースラインの成功。
• リグレッションが疑われる場合の対照またはベースライン比較。
• 境界入力またはパラメーターの変動。
• 無効または未サポートの入力。
• 欠落または不正確な構成。
• タイムアウト、ネットワーク中断、レート制限などの一時的な外部障害。
• リトライ、冪等性、またはクリーンアップの挙動。
• 共有状態や順序が問題になり得る場合の並行処理または重複する操作。
• 問いがパターンの一致よりも広い場合の、自由形式の品質または知能のサンプル。

より強力な優先順位付けモデルや再利用可能なケーステンプレートが必要な場合は、validation-matrix.md を開いてください。

一時的なプローブスクリプト

mktemp -d で作成したディレクトリなど、一時ファイルまたは一時ディレクトリに単発のスクリプトを作成します。リポジトリのコードをインポートする場合でも、既定ではスクリプトをリポジトリの外に置いてください。

openai-agents-js の使い捨てランタイムプローブは、使い捨てのままにしてください。ユーザーから再利用可能なリポジトリアーティファクトを明示的に求められない限り、パッケージスクリプトの追加、ワークスペース設定の変更、またはチェックインするベンチマークやサンプルの作成は行わないでください。

openai-agents-js では、既定の作成手順を次のようにします。

1. tmpdir=$(mktemp -d)
2. $tmpdir に probe.ts と tsconfig.json を書き込みます
3. リポジトリのルートから pnpm exec tsc --noEmit -p "$tmpdir/tsconfig.json" を実行します
4. 簡易型チェックが通ったら、pnpm exec tsx "$tmpdir/probe.ts" を実行します
5. プローブが意図的に dist/ をインポートする場合、またはパッケージ化された出力を検証する場合に限り、pnpm build を実行します

リポジトリのサンプル設定を拡張し、使い捨てのプローブだけを含める一時的な tsconfig.json を使用します。例：

{
  "extends": "/absolute/path/to/openai-agents-js/tsconfig.examples.json",
  "compilerOptions": {
    "noEmit": true
  },
  "include": ["./probe.ts"]
}

プローブでリポジトリのコードが必要な場合：

• リポジトリのルートを作業ディレクトリとして実行します。
• 実用上問題がなければ、リポジトリのルートから pnpm exec tsx /tmp/probe.ts を実行します。
• プローブを実行する前の既定の簡易型チェック手順として、pnpm exec tsc --noEmit -p /tmp/probe-tsconfig.json を使用します。
• process.cwd() とリポジトリ相対パスから作成した file:// URL を使って、リポジトリのモジュールをインポートします。@openai/agents-core のようなワークスペースの裸のインポートが /tmp から解決されるとは想定しないでください。
• 現在のブランチの動作をプローブする場合は src/ から、パッケージ化された出力をプローブする場合は dist/ からインポートします。

観測可能性を最大化するようにプローブを設計します。

• 検証しているシナリオを正確に出力またはログに記録します。
• git SHA、作業ディレクトリ、Node の実行ファイルとバージョン、関連するパッケージのバージョン、モデルまたはデプロイ名、エンドポイントまたはベース URL のエイリアス、動作に大きく影響するリトライやツールのオプションなど、ランタイムコンテキストを記録します。
• ライブプローブでは、使用が承認された環境変数の名前だけを記録します。値は決して出力しないでください。
• 可能な場合は、構造化された出力を取得します。
• エラーの型、メッセージ、ステータスコードを未加工のまま保持します。
• 繰り返しに敏感なケースでは、試行インデックス、ウォームアップ状態、実行間の比較に役立つ安定した識別子を取得します。
• 繰り返し実行するプローブやベンチマーク形式のプローブでは、実用上可能であれば、未加工の結果と簡潔な要約アーティファクトの両方を書き出します。
• 分岐は最小限にし、各スクリプトが狭い範囲の問いに答えるようにします。

一時スクリプトまたはディレクトリを削除する前に、スクリプトのパス、使用したコマンド、ランタイムコンテキスト、証拠を保持したか削除したかを簡潔にまとめてください。

軽量で使い捨ての TypeScript プローブ用ひな形を使う場合は、typescript_probe.ts を開いてください。一時スクリプトから現在のブランチのワークスペースコードを読み込む必要がある場合は、repo-import-patterns.md を開いてください。

報告

次の順序で報告します。

1. 所見。予想外の所見や否定的な所見を最初に記載します。新しい所見がなかった場合は、そのことを明記します。
2. 検証方法。使用したコード、検証したランタイムの範囲、実行モード、ケースマトリクスの網羅状況を要約します。
3. ケースの結果。ケース数が多い場合は、マトリクスまたはその要約版を含めます。
4. アーティファクトの状態と簡潔な実行概要。一時アーティファクトを削除したか保持したかを明記し、保持した場合はパスまたは残した概要を示します。
5. 任意の実装メモ。明確な不具合を1つ特定でき、その短い実装方針が役立つ場合に限り記載します。

比較プローブでは、固定した条件と検証対象の変数に加え、結果が裏付けるのはパターンの同等性に限られるのか、それともより広い品質に関する主張まで支持するのかも報告してください。

推奨される回答テンプレートについては、reporting-format.md を開いてください。

リソース

• ケースマトリクスの設計と優先順位付けには、validation-matrix.md を開いてください。
• よくある失敗シナリオの拡充には、error-cases.md を開いてください。
• OpenAI と Responses API の繰り返し使用されるプローブパターンについては、openai-runtime-patterns.md を開いてください。
• リポジトリ相対の TypeScript インポートに関するガイダンスについては、repo-import-patterns.md を開いてください。
• 最終レポートの構成については、reporting-format.md を開いてください。
• 最小限の使い捨て TypeScript プローブのひな形については、typescript_probe.ts を開いてください。