IPA非機能要求グレード2018（可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境）の記入済み要件を入力として、運用設計書を生成する。非機能要件定義が完了しているプロジェクトの運用設計フェーズで使用する。Do NOT use for 非機能要件の定義自体（requirement-managementを使用すること）。
Do NOT use for 業界調査やヒアリングから始める運用設計（operations-designを使用すること）。
The English summary is being prepared. Showing the original description.
Review the instructions the agent will receive before you install.
IPA（独立行政法人情報処理推進機構）の「非機能要求グレード2018」に基づく非機能要件定義書から、運用設計書を自動生成します。デジタル庁「デジタル・ガバメント推進標準ガイドライン」第9章（運用）への準拠も組み込みます。
このスキルは以下の機能を提供します:
| 入力 | 必須/任意 | 説明 |
|---|---|---|
| IPA非機能要件ドキュメント | 必須 | 記入済みの非機能要求グレードシート（ファイルパスまたはテキスト） |
| モデルシステム分類 | 必須 | 社会的影響度（「殆ど無い」「限定される」「極めて大きい」） |
| システム名 | 必須 | 対象システム・サービスの名称 |
| 出力先パス | 任意 | 運用設計書の保存先（未指定時はカレントディレクトリ） |
| 出力 | 形式 | 説明 |
|---|---|---|
| 運用設計書 | Markdown | IPA非機能要求グレード2018・デジタル庁ガイドライン準拠の運用設計書 |
このスキルが行うこと:
このスキルが行わないこと:
このスキルは以下の6カテゴリを処理します:
| カテゴリ | 記号 | 主な要件項目（4階層ID例） | 対応する運用設計セクション |
|---|---|---|---|
| 可用性 | A | A.1.3.2 RTO, A.1.3.1 RPO, A.2.1.1 稼働率 | SLO/SLA定義、障害対応、BCP |
| 性能・拡張性 | B | B.1.2.1 応答時間, B.1.2.3 同時接続数, B.4.1.2 HW専有 | キャパシティ管理、監視 |
| 運用・保守性 | C | C.1.2.5 バックアップ間隔, C.1.3.1-C.1.3.9 監視 | 定常運用、バックアップ、変更管理 |
| 移行性 | D | D.1.1.1 移行期限, D.3.2.1 切戻し | 運用移管計画 |
| セキュリティ | E | E.1.1.1 認証, E.11.1.1 CSIRT | セキュリティ運用 |
| システム環境・エコロジー | F | F.1.1.1 稼働環境, F.2.2.1 廃棄管理 | インフラ運用基準 |
IPA非機能要求グレード2018はシステムの社会的影響度に応じて3つのモデルを定義します。
| モデル | 社会的影響度 | 適用例 |
|---|---|---|
| モデルシステム1 | 社会的影響が殆ど無いシステム | 社内限定ツール、部門内業務システム |
| モデルシステム2 | 社会的影響が限定されるシステム | 企業間取引システム、中規模業務システム |
| モデルシステム3 | 社会的影響が極めて大きいシステム | 公共インフラ、金融基幹システム、行政サービス |
| レベル | 稼働率 | 月間ダウンタイム上限 | 年間ダウンタイム上限 | 適用モデル目安 |
|---|---|---|---|---|
| L0 | 95%未満 | — | — | モデルシステム1 |
| L1 | 95% | 約36時間 | 約438時間 | モデルシステム1 |
| L2 | 99% | 約7時間18分 | 約87時間36分 | モデルシステム2 |
| L3 | 99.9% | 約43分48秒 | 約8時間45分 | モデルシステム2 |
| L4 | 99.99% | 約4分22秒 | 約52分36秒 | モデルシステム3 |
| L5 | 99.999% | 約26秒 | 約5分15秒 | モデルシステム3 |
| レベル | RTO（A.1.3.2） | RPO（A.1.3.1） | RLO（A.1.3.3） |
|---|---|---|---|
| L0 | 72時間超 | 24時間超 | — |
| L1 | 72時間以内 | 24時間以内 | データ消失許容 |
| L2 | 24時間以内 | 8時間以内 | 業務再開可能 |
| L3 | 4時間以内 | 1時間以内 | 主要機能継続 |
| L4 | 1時間以内 | 15分以内 | 全機能継続 |
| L5 | 15分以内 | 5分以内 | 無停止継続 |
IPA非機能要求グレード2018の公式形式はExcelシート（活用シート）です。
Excelシートが提供された場合の処理方針:
1. ファイルパスを確認し、Readツールでファイルを読み込む試みる
2. Excelファイルが直接読めない場合（フォールバック優先順）:
- まず「稼働率・RTO・RPO・サービス稼働時間・認証方式等の主要10項目のみ口頭で伝える」を依頼
→ 未伝達の項目はIPAモデルシステム推奨値を使い `[要確認]` 付きで出力
- 全項目が必要な場合のみ「テキスト/CSV/Markdownに変換して貼り付け」を依頼
3. テキスト形式で受け取った場合: 項目IDと値を対応付けて解析
4. グレード番号（L0-L5）が記入されている場合: 上表の値に変換して使用
重複項目（○マーク）の処理規則:
重複項目の一覧と優先ルールの詳細は references/ipa_nfr_mapping_ja.md の「重複項目（○マーク）の処理規則」セクションを参照。
重複項目で値が矛盾する場合:
→ ユーザーに確認: 「A.1.1.1（可用性カテゴリ）とC.1.1.1（運用保守性カテゴリ）の値が
異なります。どちらが正しいですか？」
確認が取れるまで当該項目を [要確認] として保留する。
flowchart TD
A[1. IPA非機能要件の読み込み] --> B[2. モデルシステム確認・6カテゴリの要件値抽出]
B --> C[3. 不明・未記入項目のヒアリング]
C --> D[4. 運用設計書の生成]
D --> E[5. 整合性チェック]
E --> F[6. 運用設計書の出力]
A -.- A1[Excelシート、Markdown、<br/>テキスト入力から受け取る]
B -.- B1[4階層ID（A.X.X.X形式）で<br/>要件値を抽出・整理]
C -.- C1[AskUserQuestionで<br/>必要最小限の補完]
D -.- D1[IPA要件＋デジタル庁ガイドライン<br/>第9章を統合して生成]
E -.- E1[SLO/SLA・RTO/RPO・<br/>監視閾値の整合確認]
スキル: IPA非機能要求グレード準拠の運用設計書を生成します。
まず、以下を確認します:
1. モデルシステム分類（社会的影響度）
2. 非機能要件ドキュメントの場所
入力形式に応じた処理:
モデルシステムが未指定の場合:
スキル: （AskUserQuestionツールを使用）
対象システムの社会的影響度を教えてください。
A) モデルシステム1: 社会的影響が殆ど無いシステム（社内ツール等）
B) モデルシステム2: 社会的影響が限定されるシステム（中規模業務システム等）
C) モデルシステム3: 社会的影響が極めて大きいシステム（公共インフラ・行政等）
SLAの要否確認（Step1で必ず確認）:
スキル: （AskUserQuestionツールを使用）
SLAを外部に対して正式合意として定めますか？
A) はい（外部顧客・利害関係者との正式なSLAを定める）
→ §3.1にSLO/SLA双方を定義し、付録CにSLA用語を含めます
B) いいえ、内部SLOのみ（外部SLAは設けない）
→ §3.1はSLO定義のみとし、付録CのSLA用語は除外します
C) 未定（プロジェクトで後日決定）
→ SLOのみ定義し、SLAは `[要確認: SLA設定の要否が未定]` として出力します
読み込んだドキュメントから、各カテゴリの要件値を4階層IDで抽出・整理します。
抽出対象（詳細は references/ipa_nfr_mapping_ja.md 参照）:
抽出項目（IPA 4階層ID）:
- A.1.1.1 通常時のサービス継続性（連続稼働時間） ← C.1.1.1と重複
- A.1.1.2 業務継続性（システム継続稼働要件）
- A.1.1.3 障害時のサービス継続性（縮退継続） ← C.2.1.1と重複
- A.1.2.1 サービス稼働時間（運用スケジュール）
- A.1.2.2 サービス切替え時間（フェイルオーバー時間）
- A.1.2.3 業務継続レベル（縮退時の業務継続率）
- A.1.3.1 目標復旧時点（RPO）
- A.1.3.2 目標復旧時間（RTO）
- A.1.3.3 目標復旧レベル（RLO）
- A.2.1.1 稼働率（L0-L5のレベル値）
- A.2.2.1 計画停止の可否
- A.2.2.2 計画停止の許容時間
- A.2.3.1 縮退稼働の可否
- A.2.3.2 縮退稼働のレベル
- A.2.5.3 機器更改計画（2018追加）
- A.2.6.1 ヘルプデスク要件 ← C.1.2.7と重複
- A.2.6.2 ドキュメント整備要件 ← C.1.2.1と重複
- A.3.3.1 BCP方針（事業継続計画）
- A.4.1.1 計画停止要件 ← C.3.1.1と重複
抽出項目:
- B.1.1.1 通常時の業務量（リクエスト数）
- B.1.1.2 ピーク時の業務量
- B.1.2.1 通常時応答時間
- B.1.2.2 ピーク時応答時間
- B.1.2.3 同時接続数（通常時/ピーク時）
- B.2.1.1 スループット目標
- B.2.2.1 データ容量（現在/将来）
- B.3.1.1 スケールアップ/スケールアウト方式
- B.3.2.1 ピーク時対応方針
- B.4.1.1 リソース共有方式
- B.4.1.2 HWリソース専有要否（2018追加）
抽出項目:
- C.1.1.1 サービス提供時間 ← A.1.1.1と重複
- C.1.1.2 運用・監視時間帯
- C.1.2.1 ドキュメント管理要件 ← A.2.6.2と重複
- C.1.2.5 バックアップ取得間隔
- C.1.2.7 ヘルプデスク要件 ← A.2.6.1と重複
- C.1.3.1 ジョブ監視方式
- C.1.3.2 死活監視方式
- C.1.3.3 性能・負荷監視方式
- C.1.3.4 リソース監視方式
- C.1.3.5 障害監視方式
- C.1.3.6 ログ監視方式
- C.1.3.7 セキュリティ監視方式
- C.1.3.8 クラウド構成監視方式
- C.1.3.9 外形監視方式
- C.2.1.1 フォールバック時の継続性 ← A.1.1.3と重複
- C.2.1.2 バックアップ世代数・保管期間
- C.2.1.3 バックアップ保管場所
- C.2.1.4 リストア確認要件
- C.3.1.1 計画停止要件 ← A.4.1.1と重複
- C.3.2.1 ジョブネット定義
- C.3.2.2 ジョブエラー対応
- C.3.2.3 リラン方針
- C.4.1.1 パッチ適用方針
- C.4.1.2 パッチ適用窓
- C.4.1.3 パッチ適用後テスト範囲
- C.5.1.1 ログ取得粒度
- C.5.1.2 ログ保管期間
- C.5.1.3 ログ分析要件
- C.6.1.1 インシデント管理プロセス
- C.6.2.1 問題管理プロセス
- C.6.3.1 変更管理プロセス
- C.6.4.1 リリース管理プロセス
- C.6.5.1 構成管理プロセス
- C.6.6.1 キャパシティ管理プロセス
- C.6.7.1 サービスレベル管理プロセス
抽出項目:
- D.1.1.1 移行期限
- D.1.1.2 移行方式（ビッグバン/段階的）
- D.1.1.3 移行中の許容停止時間
- D.2.1.1 移行対象データ量・種類
- D.2.1.2 データクレンジング要否
- D.3.1.1 並行稼働期間・方式
- D.3.2.1 切戻し手順
抽出項目:
- E.1.1.1 認証方式（パスワード/MFA/SSO、GDPR対応含む）
- E.1.1.2 多要素認証（MFA）要否
- E.1.1.3 認可方式（RBAC等）
- E.1.1.4 アクセスログ取得要件
- E.2.1.1 通信暗号化（TLS版等）
- E.2.1.2 保存データ暗号化
- E.3.1.1 脆弱性診断の頻度・種別
- E.3.1.2 ペネトレーションテスト要否
- E.4.1.1 監査ログ取得要件
- E.4.1.2 監査ログ保管期間・改ざん防止
- E.5.1.1 適用法規制・認証（個人情報保護法、GDPR、PCI DSS等）
- E.11.1.1 CSIRTセキュリティインシデント対応体制（2018追加）
抽出項目:
- F.1.1.1 稼働環境（データセンター/クラウド）
- F.1.1.2 電源・ネットワーク冗長化
- F.2.1.1 省エネ目標（PUE等）
- F.2.2.1 ハードウェア廃棄・リサイクル方針
抽出結果の整理:
スキル: 非機能要件から以下の値を抽出しました。
【可用性（A）】
- モデルシステム: [モデルシステム1/2/3]
- 稼働率(A.2.1.1): [レベル][値]%（例: L3 = 99.9%）
- RTO(A.1.3.2): [抽出値]
- RPO(A.1.3.1): [抽出値]
- RLO(A.1.3.3): [抽出値 or 未定義]
- サービス稼働時間(A.1.2.1): [抽出値]
- サービス切替え時間(A.1.2.2): [抽出値]
- 業務継続レベル(A.1.2.3): [抽出値]
【性能・拡張性（B）】
- 応答時間(B.1.2.1): [抽出値]
- 同時接続数(B.1.2.3): [抽出値]
- HWリソース専有(B.4.1.2): [抽出値]
【運用・保守性（C）】
- 監視時間帯(C.1.1.2): [抽出値]
- バックアップ間隔(C.1.2.5): [抽出値]
- 監視方式(C.1.3.1-9): [抽出値]
- ログ保管期間(C.5.1.2): [抽出値]
- ITIL管理プロセス(C.6.x): [抽出値]
【移行性（D）】
- 移行期限(D.1.1.1): [抽出値]
【セキュリティ（E）】
- 認証方式(E.1.1.1): [抽出値]
- CSIRT体制(E.11.1.1): [抽出値 or 未定義]
【システム環境（F）】
- 稼働環境(F.1.1.1): [抽出値]
重複項目の整合確認: [矛盾あり/なし]
不明または未記入の項目: [リスト]
未記入・不明な項目がある場合のみヒアリングします。
【重要】記入済みの要件値は確認なしで使用すること。ヒアリングは必要最小限に留める。
スキル: （AskUserQuestionツールを使用）
以下の項目が非機能要件に記載されていませんでした。
運用設計書に反映するために確認させてください。
Q1: 監視ツールのカテゴリを教えてください（具体的なツール名があれば括弧内に記入）
A) オープンソース系（Prometheus/Grafana 等）
B) SaaS型（クラウドベンダー提供以外の監視SaaS）
C) クラウドネイティブ（クラウドベンダー標準の監視機能）
D) オンプレ自前構築
E) 未定
Q2: インシデント通知の方式を教えてください
A) チャットツール連携（ツール名: ______）
B) メールのみ
C) 電話・オンコールシステム
D) 未定
[未記入項目の数に応じて追加]
ヒアリング対象の優先順位:
必須（ヒアリングなしでは生成不可）:
重要（品質向上のため確認）:
任意（未定の場合は[要確認]として出力）:
assets/templates/operations_design_ipa_ja.md を Readツールで読み込み、抽出した要件値を埋め込んで運用設計書を生成します。
生成ルール:
| 状況 | 処理 |
|---|---|
| 要件値が明示されている | その値をそのまま使用 |
| グレードレベル（L0-L5）で指定されている | 上記変換表の具体的な値を記載し、根拠（IPA要件ID・レベル）を注記 |
| 未記入でヒアリング回答あり | ヒアリング回答を使用 |
| 未記入かつ未定 | `[要確認: 非機能要件X.X.X.Xが未定義]` と記載 |
デジタル庁ガイドライン要件の統合:
生成時に以下のデジタル庁要件を運用設計書に組み込む:
| デジタル庁要件 | 反映先セクション |
|---|---|
| 運用計画書（作業概要・体制・スケジュール・成果物・形態・SL） | §4 運用体制 |
| 9種監視（ジョブ・死活・性能・稼働状況・セキュリティ・防犯・データ処理・バックアップ・障害復旧） | §5 監視 |
| 問題管理・変更管理・リリース管理（台帳含む） | §8 変更管理 |
| 大規模災害等対応訓練（年1回）・情報漏洩対応訓練（年1回） | §10 BCP/DR |
| 運用改善プロセス・KPI計測 | §9 定常運用 |
| CSIRT体制・セキュリティインシデント対応訓練 | §13 セキュリティ運用 |
| アカウント管理（払出・削除・棚卸） | §13 セキュリティ運用 |
スキル: 非機能要件から運用設計書を生成しています...
[1/6] A（可用性）→ SLO/SLA・障害対応・BCP/DRセクション
[2/6] B（性能・拡張性）→ キャパシティ管理・監視セクション
[3/6] C（運用・保守性）→ 定常運用・バックアップ・変更管理セクション
C.1.3.1-C.1.3.9（9種監視）→ §5 監視
C.6.1.1-C.6.7.1（ITILプロセス）→ §8 変更管理
[4/6] D（移行性）→ 運用移管計画セクション
[5/6] E（セキュリティ）→ セキュリティ運用セクション
E.11.1.1（CSIRT）→ §13 セキュリティ運用
[6/6] F（システム環境）→ インフラ運用基準セクション
＋ デジタル庁ガイドライン第9章 → 全セクションに統合
生成完了: [出力ファイルパス]
生成した運用設計書の整合性を自動チェックします。
チェック項目:
✅ 稼働率とRTO/RPOの整合（IPA レベル対応表に基づく）
→ L3（99.9%）の場合、RTO=4時間以内、RPO=1時間以内であることを確認
✅ バックアップ取得間隔（C.1.2.5）とRPO（A.1.3.1）の整合
→ バックアップ間隔 ≤ RPO であることを確認
✅ 監視インターバルとRTO（A.1.3.2）の整合
→ （監視間隔 + §6.2「一次確認・重大度判定」の所要時間）≤ RTO となることを確認
→ 目安として監視間隔はRTOの1/10以下から設計し、インシデント対応フロー（§6.2）の
一次確認時間との合算でRTOを超過しないか検証する
✅ オンコール体制とサービス稼働時間（A.1.2.1）の整合
→ 24時間365日稼働の場合、オンコール体制が定義されていることを確認
✅ パッチ適用窓（C.4.1.2）と計画停止（A.4.1.1/C.3.1.1）の整合
→ 計画停止許容の場合、パッチ適用窓が設定されていることを確認
✅ CSIRT体制（E.11.1.1）とセキュリティ監視（C.1.3.7）の整合
→ CSIRT体制が定義されている場合、監視・通知フローが整合していることを確認
✅ 重複項目（○マーク）の値一致確認
→ A.1.1.1＝C.1.1.1、A.4.1.1＝C.3.1.1 等の値が一致していることを確認
問題が検出された場合:
スキル: 整合性チェックで以下の問題が検出されました。
⚠️ 問題1: RPO（A.1.3.1）とバックアップ間隔（C.1.2.5）の不整合
- RPO要件(A.1.3.1): 1時間以内
- バックアップ間隔(C.1.2.5): 日次（24時間毎）
- 影響: 最大23時間のデータ損失が発生する可能性があります
対応案:
A) バックアップ間隔を1時間以内に変更する
B) RPO要件を「24時間以内」に修正する
C) そのまま出力し、[要調整]注記を付ける
どの対応を希望しますか？
整合性チェック後、運用設計書を出力します。
スキル: 運用設計書を生成しました。
【生成ファイル】
- ファイル: [システム名]-operations-design-[YYYY-MM-DD].md
- セクション数: [N]セクション
- [要確認]マーカー: [N]箇所（非機能要件が未定義の項目）
- デジタル庁ガイドライン準拠: 第9章（運用）統合済み
【サマリー】
- モデルシステム: [分類]
- 稼働率目標(A.2.1.1): [レベル][値]%
- RTO(A.1.3.2): [値] / RPO(A.1.3.1): [値] / RLO(A.1.3.3): [値]
- 監視体制(C.1.3.x): [採用する監視種別]
- バックアップ(C.1.2.5): [値]
- CSIRT体制(E.11.1.1): [あり/なし/要確認]
- セキュリティ: [主要設定]
[要確認]マーカー一覧付録の生成:
[要確認]マーカーが1件以上ある場合は、運用設計書の末尾に付録D（未確認事項一覧）を必ず生成すること:
### 付録D: 未確認事項一覧（[要確認]マーカー集計）
後工程のレビューで確認漏れを防ぐため、本書中の[要確認]項目を集約しています。
| # | 箇所（セクション） | IPA要件ID | 内容 | 確認担当 | 確認期限 |
|---|-----------------|----------|------|---------|---------|
| 1 | §X.X [セクション名] | X.X.X.X | [未定義の内容] | [担当者] | [YYYY-MM-DD] |
※ 確認完了後は本表から削除し、対象箇所の[要確認]マーカーを実際の値に更新してください。
SLA条件付き出力:
Step1でSLA要否の確認を実施済みの場合:
SLA「あり」の場合:
→ 付録C（用語集）にSLA定義を含める
→ §3.1見出しを「稼働率目標（SLO/SLA）」とし、SLO・SLA双方の値を記載
SLA「なし」の場合:
→ 付録C（用語集）からSLA用語を除外する
→ §3.1見出しを「稼働率目標（SLO）」とし、SLOのみ記載
SLA「未定」の場合:
→ §3.1はSLOのみ記載し、SLAは `[要確認: SLA設定の要否が未定]` として追記
→ 付録C（用語集）のSLA行はそのまま残し、`[要確認]` を維持する（削除しない）
[要確認: 非機能要件X.X.X.Xが未定義] として出力）必須項目（モデルシステム分類・稼働率・稼働時間）が未記入の場合:
→ ヒアリングを実施（スキップ不可）
重要項目（RTO・RPO・バックアップ間隔）が未記入の場合:
→ `[要確認: 非機能要件X.X.X.Xが未定義]` として出力し、後で補完できるようにする
任意項目（移行スケジュール詳細・CSIRT詳細等）が未記入の場合:
→ `[要確認: 非機能要件X.X.X.Xが未定義]` として出力し、値は補完しない
ipa_nfr_mapping_ja.md: IPA非機能要求グレード2018の6カテゴリ → 運用設計項目 詳細マッピング表（4階層ID対応）operations_design_ipa_ja.md: IPA非機能要求グレード2018・デジタル庁ガイドライン準拠の運用設計書テンプレートNo reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
指定されたPRを6観点（セキュリティ、ドキュメント乖離、可読性、ライブラリ選定、PR説明、既知脆弱性）でレビューし、人間向け・AI向けの2形式でPRにコメントする。初回レビューおよび修正後の再レビューに使用する。Do NOT use for レビューコメントへの修正適用（pr-comment-fixerを使用すること）。
The English summary is being prepared. Showing the original description.
キャリア設計のためのデプスインタビューを実施し、本人の価値観・強み・動機を引き出す。5 Whys、ラダリング法を用いてキャリアビジョンの明確化を支援する。転職相談、自己理解、キャリアカウンセリング、1on1面談の深掘りに使用する。Do NOT use for 製品・サービスのユーザーリサーチ（depth-interviewing-productを使用すること）。
The English summary is being prepared. Showing the original description.
サービス開発のためのデプスインタビューを実施し、ユーザーの真のニーズ・課題・動機を引き出す。5 Whys、ラダリング法を用いてプロダクト開発に活かせるインサイトを発見する。ユーザーリサーチ、課題発見、ペルソナ構築、プロダクト仮説検証に使用する。Do NOT use for キャリア相談やキャリアカウンセリング（depth-interviewing-careerを使用すること）。
The English summary is being prepared. Showing the original description.
インフラメトリクスの定期調査を体系的に実施し、サービスの健全性を評価する。2層アプローチで11カテゴリのメトリクスを確認し、構造化レポートを作成する。定期的なサービス監視、障害予兆の検出、パフォーマンス評価に使用する。Do NOT use for 個別インシデントの根本原因分析（incident-rcaを使用すること）。
The English summary is being prepared. Showing the original description.
インシデント調査で根本原因を特定するためのなぜなぜ分析ファシリテーター。推測を避け、ユーザーの発言を記録し、マインドツリーで全体を可視化する。障害発生後の原因究明、ポストモーテム、再発防止策の策定に使用する。Do NOT use for 定期的なサービス健全性チェック（health-checkを使用すること）。
The English summary is being prepared. Showing the original description.
Jules REST APIを使用してタスクを対話的に依頼・管理する。セッション作成・プラン承認・メッセージ送信・進捗監視をAPI経由で行い、Claudeと協調してタスクを完遂する。ベースブランチ指定とPR自動作成に対応。認証はJULES_API_KEY_OP_URI（1Passwordシークレット参照）またはJULES_API_KEYで行う。Do NOT use for 認証情報未設定の環境でのタスク実行（task-executingを使用すること）。
The English summary is being prepared. Showing the original description.