https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/index.html Recent content in 4. お客様での運用設計・構築 on JP1 Cloud Service 運用統合 利用ガイド Hugo -- gohugo.io ja https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/design_pre/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/design_pre/index.html 前提知識について説明します。 節構成 4.1.1 各機能の関係と必要な知識 4.1.2 YAMLファイル定義時の注意事項 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/required/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/required/index.html 業務の整理について説明します。 節構成 4.2.1 定常業務/随時業務の洗い出し 4.2.2 ユーザーの整理 4.2.3 運用に必要なスキル 4.2.4 扱うドキュメントの整理 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/index.html 「業務の整理」で業務を整理したら、それらの業務に対して、どの範囲をどのようにOps Iで実装していくかを検討します。 本章では、データモデルやワークフロー、ドキュメントの保管方法など、業務をOps Iで実現するために必要な具体的な設計観点を記載します。 （表）業務設計一覧 項目 設計項目 サービスカタログの設計 ・Catalog ワークフローの設計 ・Workflow 通知の設計 ・Notification ・Notifier ドキュメントの保管方法 ・Attachment ・Distribution ユーザーとACL ・User ・Group ・Role ・ACL ・GitRole ・組織内のロール スキル管理 ・Skill ・Skillset 自動化 ・Playbook ・Vault チケット管理 ・チケットの作成、確認、更新、および関連付け スケジュール管理 ・スケジュールの作成、確認、および更新 ・Calendar サイト管理 ・サービスポータルの作成、更新、および公開 ナレッジ管理 ・ナレッジの作成、編集、削除、添付ファイルの登録、および公開 ・カテゴリーの作成、編集、削除、および公開 データモデルの設計 ・Datamodel 節構成 4.3.1 サービスカタログの設計 4.3.2 ワークフローの設計 4.3.3 通知の設計 4.3.4 ドキュメントの保管方法 4.3.5 ユーザーとACL 4.3.6 スキル管理 4.3.7 自動化 4.3.8 チケット管理 4.3.9 スケジュール管理 4.3.10 サイト管理 4.3.11 ナレッジ管理 4.3.12 データモデルの設計 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/uidesign/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/uidesign/index.html UI設計では、UIとScriptのYAML定義を行います。 UIのYAMLファイルには、UIバージョン1.0とUIバージョン1.1があり、新規でUIを作成する場合はUIバージョン1.1の使用を推奨します。UIバージョンの詳細は「UIバージョン」を参照してください。また、UIのURLを定義する機能（Uipath）については、「画面のURL定義（Uipath）」を参照してください。 Scriptは一部JavaScriptで記述するものがあります。詳細については「Script」を参照してください。 （表）UI設計項目と概要 項目 定義手段 設計のポイント UI ・YAMLファイル 操作ボタンの種類や入力項目など画面に必要なものを洗い出し、それらをどのように配置するかなど、画面構成について事前に検討しておきます。 Script ・YAMLファイル ・JavaScript UI上のメニューなどの操作時に実行するアクション定義のカスタマイズは可能ですが、Ops I内蔵の部品を活用するなど、操作の統一性を考慮します。 【UI定義】 UI定義ではワークフローの各ステップで使う画面を定義します。さまざまなUI表示部品であるコンポーネントを配置して画面を構成します。また、コンポーネントに加え、アクションを行うボタンやメニューを構成します。 Ops Iでは複数のコンポーネントを組み合わせることで画面を構成します。画面で表示するレコードやリストのデータはデータモデルで定義したものを利用します。 データモデルの詳細については「データモデルの設計」および「Datamodel」を参照してください。 また、UIバージョン1.0のUIでFormコンポーネント上の添付ファイルを保存する場合、"save"や"accept"などのOps Iで提供しているアクションボタンで実行してください。UIバージョン1.1ではカスタムスクリプトの使用が可能です。 （図）コンポーネントの組み合わせの概念図 【Script】 ScriptのYAMLファイルではUIのYAMLファイルで定義した画面上に配置する項目やボタンなどのコンポーネントに対するアクション（動作）を定義することができます。 特定の項目に入力した場合に実行するバリデーションチェックなどはYAML定義のみで実現できますが、Scriptを使用することにより、より高度なチェックやアクションの実装を行うことができます。 例えば、ボタンをクリックした時に項目Aが入力されている場合に項目Bの入力も必須であるといったような、各入力値の相関をチェックすることができます。また、ボタンのクリックに応じて入力値A、B、Cから自動的に合計値などを算出し特定項目を自動入力する、または別のデータモデルに入力値を反映させるなども可能となります。 （図）UIとScriptの概要図 ScriptのYAMLファイルで定義したアクションはUIのYAMLファイルで定義したコンポーネントのアクション名と一致する場合に実行されます。そのため、ScriptとUIのYAMLファイルの定義内容は対応づけて作成してください。以下にScriptの概念図とYAMLファイルで定義する内容を示します。 ScriptのYAML定義の詳細については「Script」を参照してください。 （図）Scriptの概念図 たとえばVM貸出の申請の場合、申請番号などの各項目に対して、画面上でどのように操作させるかを前提に表示方法を検討し、それにあわせてパラメータやボタンなどの種別をUIのYAMLファイルで定義します。以下に、VM貸出の申請の場合の各設定内容一覧と、画面構成イメージ図を示します。 （表）VM貸出業務の「申請」を例とした設定内容一覧 作業名 ワーク フロー ステップ 操作者 UI 種別 名称 アクション バリデーション チェック 補足 VMの貸出 申請 申請者 パラメータ 申請番号 ❶ 表示のみ - 自動採番 パラメータ システム名 ❷ 入力待ち（必須） - リスト選択 パラメータ OS種別 ❸ 入力待ち（必須） - リスト選択 パラメータ CPU ❹ 入力待ち（必須） 4≦値≦128 チェックエラー時はメッセージ表示 パラメータ メモリ ❺ 入力待ち（必須） 32GB≦値≦256GB チェックエラー時はメッセージ表示 パラメータ ストレージ ❻ 入力待ち（必須） 10GB≦値≦4,096GB チェックエラー時はメッセージ表示 パラメータ 利用申請者 ❼ - - - パラメータ 利用開始日 ❽ 入力待ち（必須） - - ノート 申し送り事項 ❾ 入力待ち（任意） - - ボタン 申請 ❿ 申請の送信 - - ボタン 保存 ⓫ 申請の保存 - - ボタン 取り消し ⓬ 申請の取り消し - ワークフロー終了 設定内容がどのように画面構成されるか、表中の赤丸数字と下図の赤丸数字により示します。 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/tips/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/tips/index.html その他運用設計Tipsについて説明します。 節構成 4.5.1 Library 4.5.2 Application 4.5.3 チケット画面のカスタム 4.5.4 ワークフロー画面のカスタム 4.5.5 初期YAMLファイルのカスタム https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/reg_step/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/reg_step/index.html これまでの運用設計により開発したYAMLファイルは、GitLabに登録して初めて有効となります。 本章では、開発プロセスの流れに沿って、開発したYAMLファイルをGitLabに登録する手順を記載します。 節構成 4.6.1 YAMLファイルコード開発から本番運用までのプロセス 4.6.2 YAMLファイルのアップロード方法 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/reg_sequence/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/reg_sequence/index.html ジョブ自動実行の設定手順では、自動化機能を伴う処理について、YAMLファイルの登録とAWX設定の一連の流れを説明します。 本説明に用いるワークフロー定義例では、サービスカタログ画面から起動すると、バックグラウンドでWebブラウザーにメッセージを出力するPlaybookを実行し、ワークフローを完了します。 以下の順序で作業を行います。 （表）YAMLファイルの登録とAWX設定の流れ # 項目 （1） ワークフローの追加 （2） サービスカタログの更新 （3） ジョブテンプレートの作成 （4） カタログアイテムの起動 ワークフローの詳細については「ワークフローの設計」、「Workflow」、サービスカタログの詳細については、「サービスカタログの設計」、「Catalog」、ジョブテンプレートの詳細については「ジョブテンプレートの登録」を参照してください。 （1）ワークフローの追加 以下のワークフローを追加します。 本説明に用いるYAMLファイルには依存関係があります。すべてのYAMLファイルを同時にGitLabに登録する場合は、依存関係を意識する必要はありませんが、1つずつYAMLファイルを登録する場合、Script、UI、Workflowの順番で登録してください。ここでの「登録」は、GUIでの操作ではcommit、CUIでの操作ではpushを指します。Playbookは順番を問いません。 （表）登録するYAMLファイル フォルダ・ファイル名 概要 dummy - script Script定義： 申請画面を初期表示した時にメッセージダイアログを表示します。 dummy_script manifest.yaml output_message.js ui GUI定義： UIの定義とScriptの定義（include）をします。 dummy_ui manifest.yaml workflow Workflow定義： ワークフローの各ステップを定義します。 ワークフローからジョブテンプレートを実行するために、Task modelのactionでOps I提供部品の「awx.run_job_template」を、inputでジョブテンプレート名（本例では「dummy_template」）を定義しています。 launch_job_wf manifest.yaml playbook Playbook test.yaml YAMLファイルの詳細については、「Script」、「UI」、「Workflow」を、YAMLファイルが正しく登録できたことを確認する場合は、「YAMLファイルの登録状況確認方法」を参照してください。 YAMLファイルの登録が成功すると、Ops Iへワークフローが登録された状態になります。 （2）サービスカタログの更新 登録されたワークフローをサービスカタログ画面から確認するために、サービスカタログのYAMLファイルに以下を追記してください。 （表）サービスカタログ更新内容 追記箇所 追記内容 includes:   - kind: workflow     name: launch_job_wf categories:  - name: dummy    label: AWX    sub:      - name: launch_job        label: ジョブ実行        items:          - workflow: launch_job_wf            label: AWXジョブ実行            description: AWXジョブ実行するWFです。 正しく登録されるとサービスカタログ一覧に、登録されたカタログアイテムが表示されます。 （3）ジョブテンプレートの作成 ジョブテンプレートはジョブを実行するための認証情報、プロジェクト、インベントリーなどを組み合わせた定義のセットになります。プロジェクトに設定されているリポジトリからPlaybook用のYAMLファイルを指定することにより、Playbookと連携することができます。 本作業は、Playbook用のYAMLファイル（test.yaml）を、手順「ワークフローの追加」で登録した後に実施することを想定しています。 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/outpost_step/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/outpost_step/index.html 以下の手順は、中継サーバーの設定が終わっていることを想定しています。中継サーバーの設定については「中継サーバーの設定」を参照してください。 中継サーバーを使用する際は、以下の手順①～⑥で設定をします。 ①～③はシステム管理、④～⑥は自動化アプリケーション（AWX）で設定を行います。 ⑦ではワークフローのYAMLファイル記載内容について説明します。 ①～③の操作を行うユーザーは、Primitiveロール「automation_manager」が付与されている必要があります。また、④～⑥の操作を行うユーザーはAWXの組織が持つロールが付与されている必要があります。AWXのロールの詳細については、付録 「OSSのバージョンおよびエディション、参照先のマニュアル」のAWXのマニュアルを参照してください。また、組織の概要や組織の作成や各ロールの割り当てについては「組織の設定」、「組織管理」を、ロールの割り当て全般については「ロール」、「Ops I上のロールとサポート機能の対応関係」を参照してください。 【システム管理】 ①ノードグループを追加します。 ノードグループを追加すると、自動化アプリケーション（AWX）に自動的にノードグループID名のインスタンスグループが作成され、ジョブテンプレートとひもづけられます。ジョブはノードグループ内のいずれかのノードで実行されるため、ジョブ実行の負荷を複数のノードに分散させることができます。また、ジョブテンプレートに影響を与えずにノードの追加や入れ替えを実施することができます。 ノードグループ追加の詳細は「ノードグループ管理」を参照してください。 （図）ノードグループ画面 （図）インスタンスグループ画面 ②IPブロックを追加します。 IPブロック追加については、「IPブロック管理」を参照してください。 ③ノードとIPブロックをノードグループにひもづけます。 IPブロックが1つもひもづいていないノードグループで実行されたジョブは、すべてのIPアドレスにアクセスできます。ノードとIPブロックをノードグループにひもづける方法については、「ノードグループ管理」を参照してください。 【自動化アプリケーション（AWX）】 ④～⑥では中継サーバーを使用するため必要となるAWXの設定について説明します。AWXの標準的な設定については「自動化」を参照してください。 ④認証情報に、中継サーバーから接続する管理対象サーバー情報を登録します。 管理対象サーバーの認証方法にあわせて設定を行ってください。その際、認証タイプは「マシン」など、接続先に合わせて選択してください。また「Outpost」は予約語のため、名前として使用しないでください。設定方法の詳細は付録 「OSSのバージョンおよびエディション、参照先のマニュアル」の、AWXのマニュアルを参照してください。 （図）管理対象サーバー認証情報登録画面 ⑤ジョブテンプレートを作成します。 ジョブテンプレートのインスタンスグループとして、①で自動生成されたインスタンスグループを選択します。その結果、ジョブテンプレートからノードグループがひもづけられます。 （図）ジョブテンプレート画面 （図）インスタンスグループ選択画面 ⑥ジョブテンプレートの実行環境に「OpsI Outpost EE」を指定します。 「OpsI Outpost EE」はOps IのAWXにデフォルトで存在します。 （図）実行環境画面 【YAMLファイル記載内容】 ⑦ワークフローのYAMLファイルに④で作成したジョブテンプレートを指定します。 ワークフローのYAMLファイルで、Task modelのactionとしてOps I提供部品の「awx.run_job_template」を設定し、inputに④で作成したジョブテンプレート名を定義します。 その結果、ワークフローからノードグループにひもづけられたジョブテンプレートを使用することができます。 ユーザーがカタログアイテムを起動すると、ワークフローでawx.run_job_templateを設定したステップでAWXのジョブテンプレートが実行され、コントロールプレーンにジョブが登録されます。中継サーバーのエージェントがそのジョブを取得し、管理対象サーバーに対しジョブを実行します。 ワークフローのYAMLファイルについては「Workflow」を参照してください。 （図）ジョブ実行の流れ 【ジョブ数使用制限】 1つのノードで同時に実行できるジョブ数はハードウェアの構成により制限があり、例えば「RPMパッケージインストール前提条件」の最小構成の場合、最大12個になります。それ以上のジョブが同時に実行された場合、制限を超えるジョブは待機状態となり、実行中のいずれかのジョブが完了次第実行されます。ただし、最大待ち時間の5分以内に実行されない場合、待機しているジョブはエラーとなります。 ジョブ数使用制限以上のジョブを実行したい場合、ノードを分割し1つのノードあたりの使用制限を超えないよう対処が必要です。 【アウトポストの稼働監視】 エージェントが正常に稼働しているかを定期に確認することを推奨します。確認方法はOps Iの画面ステータス、または状態監視コマンドの実行により行います。また、プロセス監視も可能です。 Ops I画面ステータスでの確認： ノード詳細画面でステータスが「Not Ready」の場合、エージェントが停止状態と判断できます。ノード詳細画面については「ノード管理」を参照してください。 状態監視コマンド「opsiopctl.sh status」での確認： エージェントではchiselとk3sのsystemdサービスが動作しており、「opsiopctl.sh status」の実行結果としてコマンドラインにそれぞれのサービスのステータスが出力され、停止状態の場合「inactive」と表示されます。また、ステータスの少なくとも1つが稼働状態「active」ではない場合「Outpost Agent is NotActive.」と出力され、コマンドの返り値として「1」が返却されます。 また、「opsiopctl.sh status」を定期実行することでコマンドの返り値（0または1）を元に起動状態を確認することができます。 コマンドの詳細は 「RPMパッケージのコマンドスクリプト」の【アウトポストエージェントの状態監視：opsiopctl.sh status】を参照してください。 プロセス監視を行う場合： chiselとk3sのプロセス監視が可能です。プロセスの実行ファイルのPathは以下になります。 chisel：/opt/opsi/outpost/bin/chisel k3s：/opt/opsi/outpost/bin/k3s https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/integration_template/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/integration_template/index.html Ops Iは連携テンプレートを使用することで、以下の他製品と連携することができます。 （表）連携製品とバージョンおよびOS 製品名 バージョン OS JP1/AJS3 V11-00以降 Windows JP1/IM JP1/AJS3のジョブ管理機能と連携することにより、Ops IからJP1/AJS3のジョブの実行が可能になります。また、JP1/IMのシステム管理機能と連携することにより、Ops IからJP1/IMのイベント監視の制御を行うことが可能です。また、JP1/IMでインシデントが発生した際には、Ops Iにチケットが自動登録されます。これらにより、ジョブ運用やシステム監視運用の統合管理が可能になります。 節構成 4.9.1 JP1/AJS3 4.9.2 JP1/IM https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/awxee_extension/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/awxee_extension/index.html 追加モジュール（Ansibleコレクション、Pythonモジュールなど）や追加ツール（AWS CLI、OpenTofuなど）を使用した自動化を実現するためには、Ops Iで提供する実行環境を拡張する必要があります。ユーザーが拡張した実行環境を、ここではカスタム実行環境と呼びます。 実行環境の作成や管理は、Gitアプリケーション（GitLab）によって行います。また、自動化の実行は自動化アプリケーション（AWX）で行います。GitLabやAWXのマニュアルについては「OSSのバージョンおよびエディション、参照先のマニュアル」を参照してください。 自動化実行環境拡張の流れを以下に示します。 （図）自動化実行環境拡張の流れ 自動化実行環境拡張と自動化の実行は以下の流れで実施します。 カスタム実行環境の開発：①、②、③ カスタム実行環境の管理：④ カスタム実行環境のAWXへの登録：⑤ 自動化の実行：⑥、⑦ 「カスタム実行環境の開発」、「カスタム実行環境の管理」、および「カスタム実行環境のAWXへの登録」を行うユーザーは、Pre-Installedロール「Site Reliability Engineer」が付与されている必要があります。 また「自動化の実行」を行うユーザーはPre-Installedロール「Operation Management Office Agent」が付与されている必要があります。 ロールについての詳細は「Ops I上のロールとサポート機能の対応関係」を参照してください。 また、実行環境の追加を行うには、組織内のロール「実行環境管理者」または「管理者」を付与されている必要があります。組織内のロールについては「組織管理」を参照してください。 さらに、GitLabのプロジェクトのforkを行うには、GitLabのグループ「ops-i-system-engineers」に対して「Maintainer」以上のGitロールが必要です。Gitロールについては「（表）グループ追加時の関連するリソースエリアのタブ」を参照してください。 各作業の詳細を以下に示します。 （1）カスタム実行環境の開発 カスタム実行環境の開発を行います。ここでの操作はGitアプリケーションで行います。 GitLabのGUIで画面右上に表示されている[Explore projects]をクリックし、表示された一覧から「system」グループの「awx-ee」プロジェクトを選択します。「awx-ee」は読み取り専用のプロジェクトです。 [Fork]ボタンをクリックします。以下の項目を入力し、[Fork project]ボタンをクリックするとカスタム用プロジェクトが作成されます。 （表）カスタム用プロジェクトの入力項目 項目 説明 Project name 任意の値 Project URL - Select a namespace ops-i-system-engineersを選択 Project slug 任意の値 ただし以下は予約語のため使用しないでください。 GitLabの予約語。該当の予約語は以下を参照してください。 https://archives.docs.gitlab.com/18.4/user/reserved_names/の「Reserved project names」"opsi"で始まる値 Visibility level Privateを選択 forkしたプロジェクトの[Settings]-[General]を開き、[Visibility, project features, permissions]に表示される以下の項目を有効化します。 CI/CDContainer registry カスタム用プロジェクトの以下のファイルに、自動化に組み込むモジュールやツールの情報を追記します。 （表）カスタム用プロジェクトの編集可能なファイル ファイル 説明 _build/requirements.yml インストールされるansibleコレクションとロールのリスト ansibleの要件ファイルの形式で記述されています。 _build/requirements.txt インストールされるPythonパッケージのリスト pipの要件ファイルの形式で記述されています。 _build/bindep. https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/ai_agent/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/ai_agent/index.html Ops Iではお客様のAIエージェントと連携することにより、チケットの操作やOps Iの定義の作成・編集を効率的に行うことができます。 AIエージェントがOps Iと連携するために、Ops IのMCPサーバーを利用できます。Ops IのMCPサーバーをここでは「MCPサーバー」と呼びます。 初めに接続設定を行い、その後はユーザーがプロンプトをAIエージェントへ入力すると、AIエージェントが必要に応じてMCPサーバーのツールを実行します。 MCPサーバーにはツールが用意されており、以下の操作を行えます。 インシデントチケットの検索・作成・更新、問い合わせチケットの検索・更新、ナレッジ記事の検索・作成 詳細は「チケット・ナレッジ記事の操作」を参照してください。 Ops Iの定義ファイルについてマニュアル記載情報を取得 詳細は「Ops I定義ファイルのAI支援コーディング」を参照してください。 接続設定については「接続設定」を、ツールの詳細は「JP1 Cloud Service 運用統合 APIリファレンス」の「APIリファレンス概要＞MCPサーバー」を参照してください。 （図）AIエージェントとMCPサーバーの関係 （1）接続設定 AIエージェントと連携してOps Iの操作を行うためには、環境の準備と接続設定が必要です。 【環境の準備】 以下をお客様の環境で準備してください。 AIエージェント： 操作したい内容に適したAIエージェントを選択してください。 LLMと接続できる環境： AIエージェントが利用するLLMを選択し、接続してください。 【MCPサーバーとの接続設定】 AIエージェントごとに定められた方法で以下を設定し、AIエージェントとMCPサーバーを接続してください。 エンドポイントの設定： エンドポイントの詳細は「JP1 Cloud Service 運用統合 APIリファレンス」の「APIリファレンス概要＞MCPサーバー」を参照してください。 Ops Iトークンによる認証設定： MCPサーバーへ接続する際には、AIエージェントを利用するユーザーのOps Iトークンを利用してください。Ops Iトークンにひもづくユーザーに付与されたグループ、ロールの設定が、AIエージェントがOps Iに対して行える操作と操作対象に影響します。ユースケースごとに必要なグループ・ロールを設定してください。Ops Iトークンの取得方法は「JP1 Cloud Service 運用統合 APIリファレンス」の「APIリファレンス概要＞前提知識＞Ops Iトークンの取得」を参照してください。 接続設定の例は「AIエージェントとの連携例」を参照してください。 （2） チケット・ナレッジ記事の操作 インシデントチケットの検索・作成・更新、問い合わせチケットの検索・更新、ナレッジ記事の検索・作成を行えます。行いたい操作をプロンプトとしてAIエージェントに入力してください。プロンプトの入力例は「AIエージェントとの連携例」を参照してください。また、ツールの詳細については「JP1 Cloud Service 運用統合 APIリファレンス」の「APIリファレンス概要＞MCPサーバー」を参照してください。 【必要な権限】 チケット・ナレッジ記事の操作を行うために、ユーザーには以下のPrimitiveロールのいずれかが付与されている必要があります。 itsm_admin itsm_manager itsm_user また、インシデントチケットまたは問い合わせチケットから現象を抽出する操作およびナレッジ記事を作成する操作については、Primitiveロール「ai_extension_user」が付与されている必要があります。Primitiveロールの詳細は「Ops I上のロールとサポート機能の対応関係」を参照してください。 （3） Ops I定義ファイルのAI支援コーディング ソフトウェア開発に特化したAIエージェントのことを、コーディングエージェントと呼びます。