GitHub、Confluence、JiraでAIの成果を公開する手順

AIコラボレーションコースに戻る

担当者は、オーナーの承認前にPROP-042を固定します。 Confluenceの公開担当者が要件を更新し、GitHubのメンテナーが実装をマージし、運用担当者がランブックを公開します。Jiraには各手順を記録します。3つのシステムは1つのアトミックなトランザクションを構成しないため、権限を確認してから実施してください。公開台帳を使うと、未完了の配信を把握できます。

要点 #

• 承認された意図と配信後の動作は異なります。
• 固定した提案リビジョンがレビュー対象を特定します。
• 公開台帳によって部分完了を把握できます。
• 最新の読み取りによって変更済みの基準を検出できます。

始める前に #

前提条件: ワークプレイスの設定 、公開権限、オーナー、リポジトリのメンテナー。所要時間の目安: 2時間。難易度: 高度な調整が必要です。

基本インターフェース: ブラウザーでの読み取り、承認済みチャットでの任意の下書き、人による公開。コネクターのサブスクリプションは前提にしません。連携機能を追加する前に、テナントでの利用可否、スコープ、プロバイダー側の処理、IDの対応付けを確認してください。オーナーの認証情報を担当者と共有してはいけません。

読者の到達点: 固定提案、システムごとの公開台帳、読み戻しの証跡、最初の未完了手順に対する復旧判断を作成します。この演習で確認するのは手順と証跡の扱いであり、本番環境での保持動作ではありません。

最新の情報源を記録する #

1. **MAP-01を読み、**対応付けられたページIDでREQ-17とRUN-04を開きます。
2. **ページメニューからページ履歴（Page History）を開き、**数値のバージョン、状態、文面、オーナー、例外を記録します。
3. **Jiraの課題を読み、**固定した提案のエクスポートまたはGitHubコミットを添付します。課題キーだけではレビュー証跡を固定できません。
4. 承認済みのPOL-01と保護された構成ベースラインを確認します。
5. 必要な合成データの抜粋だけをチャットに渡し、スナップショットと明記します。書き込み権限のある操作は無効にします。

Task: PROP-042, propose only
Authority: Confluence REQ-17 for intent, GitHub for behavior
Read: mapped current pages, versions, scope, exceptions
Proposal: synthetic export retention from 7 to 30 days
Output: requirement wording, config diff, runbook, ledger
Evidence: source ID and captured revision for each factual claim
Unknowns: missing access and absent runtime observations
Stop: conflict, changed base, or denied access

オフラインのパケットはスナップショットです。 公開担当者は書き込み前に最新情報を再確認します。アクセス拒否は公開を停止する理由になります。古いエクスポートは現在の承認の代わりになりません。

提案を固定する #

{
  "proposal_id": "PROP-042",
  "proposal_revision": 1,
  "requirement_base_version": 1,
  "runbook_base_version": 1,
  "policy_version": 1,
  "from_days": 7,
  "to_days": 30,
  "status": "awaiting-owner-review",
  "publication_order": ["requirement", "implementation", "runbook", "delivery"]
}

例示用のページバージョンは、実際に記録したバージョンに置き換えます。 固定したJSONと提案文をJiraに添付します。各オーナーは役割、判断、提案リビジョン、情報源のバージョン、レビュー時刻を記録します。内容に関わる変更があれば、パッケージをReviewに戻します。

プロダクト担当は意図と範囲を確認します。運用担当はクリーンアップと復旧を確認します。 メンテナーはdiffを確認します。変更可能なチャットメッセージへのリアクションは、リビジョンに紐付いた承認ではありません。

公開して読み戻す #

1. 公開担当者が両オーナーのレビューと情報源ベースの変更がないことを確認してから、JiraをPublishingにします。
2. 30日と未配信フィールドを設定してREQ-17を公開します。 結果のバージョン、範囲、例外を記録します。
3. 承認済みページバージョンを参照して、GitHubの実装PRを開きます。 構成を30日に変更し、権威のない要件スナップショットを添付します。
4. リポジトリレビュー後にマージし、mainを読み戻します。 コミット上の動作と実行時の動作を分けて記録します。
5. RUN-04を公開し、IDで読み戻して結果のバージョンを記録します。 公開担当者は要件内の配信参照を更新します。
6. すべての記録が一致し、最終読み戻しの証跡を添付した後にJiraを完了します。

ローカルバリデーターはスナップショットの整合性確認にのみ使います。 変更前のConfluence要件をラボのベースラインJSONスキーマにコピーして取得し、候補を30日に変更します。ローカルのスナップショットリビジョンを増やし、実際のConfluenceバージョンはJiraに別途保存します。GitHubを最初の情報源とするワークフローは、ライブのConfluenceを検証しません。緑色の状態を外部権限の確認として提示してはいけません。

この演習では削除をデプロイしません。 実サービスにはデプロイ証跡、管理されたテストデータ、削除を一時停止する仕組み、実行時の境界テストが必要です。マージで確認できるのはリポジトリの状態であり、本番の保持動作ではありません。

部分公開を追跡する #

次の手順を試す前に、各結果を記録します。 PROP-042が各システムのイベントを関連付けます。1行が完了しても、変更全体の完了を意味しません。

失敗例: Confluenceでは30日が公開されたものの、GitHubでマージが拒否されました。JiraをBlockedのままにし、要件を未配信として扱います。プロダクト担当が先に進めるか、レビューを経て7日に戻すかを選びます。緊急用READMEのコピーを要件の権威ある情報源にしてはいけません。

同時編集に対処する #

ブラウザーを使う基本手順: パイロット期間中の公開担当者を1人にします。編集の直前と公開の直後にページ履歴を再度開きます。別の作成者が情報源を変更した場合は停止し、比較と調整を行ってから承認を取り直します。順番に公開する手順は、アトミックなトランザクションを保証しません。

APIによる拡張: Confluence v2のドキュメントには、バージョンオブジェクトを含む**GET /wiki/api/v2/pages/{id}?body-format=storageとPUT /wiki/api/v2/pages/{id}**が記載されています。レビュー済みの公開連携は、現在のバージョンと承認済みのベースを比較し、次のバージョンを送信して読み戻します。失敗したバージョンを自動更新し、古い本文を再試行してはいけません。

APIが成功しただけでは不十分です。 結果の本文、情報源ID、範囲、バージョンを確認します。このコースには書き込み可能なAPIクライアントはありません。プログラマー以外が実行する基本手順は、人がブラウザーで公開する方法です。

否定的なケースを検証する #

実際のサンドボックス結果を記録します。 実行者の役割と変更前後のリビジョンを含めてください。アクセス拒否されたユーザー向けの証跡に、保護されたページ本文を含めてはいけません。期待値は測定結果ではありません。

レビューパッケージを組み立てる #

提案ラベルだけでなく、内容を固定します。 PROP-042は各システムに表示されますが、ラベルだけではオーナーが確認した本文を特定できません。要件の正確な文面、実装diff、ランブックの文面、情報源のバージョン、公開順序を1つの固定パッケージに含めます。

Package: PROP-042 revision 1, illustrative
Intent: synthetic export retention changes from 7 to 30 days
Exclusions: production data, backups, legal holds
Requirement amendment: fixed proposed REQ-17 wording
Implementation: fixed candidate diff and protected base reference
Runbook amendment: fixed RUN-04 wording and recovery limits
Review: product and operations decisions for this package
Delivery: requirement -> implementation -> runbook -> closure
Stop: changed source, missing review, denied write, failed read-back

両オーナーが読めるパッケージにします。 プロダクト担当には意図と除外事項が必要です。運用担当には運用上の変更と復旧境界が必要です。承認済みの意図と配信済みの構成が異なる期間を、両者が理解する必要があります。リポジトリのファイルを知らないオーナーには、コードdiffだけでは足りません。

この合成例における入力済みパッケージ:

REQ-17 proposed v5: "Synthetic export files are retained for 30 days from creation. This pilot excludes production data, backups, and legal holds. Delivery remains pending until the GitHub configuration and RUN-04 read-backs match this approved wording."

GitHub config.json, proposed change against base-001:
-  "retention_days": 7
+  "retention_days": 30

RUN-04 proposed v3: "Retention days: 30. Synthetic exports only. No deletion job runs in this lab. If publication fails, keep delivery pending, read back each source, and obtain owner approval before restoring the seven-day configuration or completing the thirty-day publication."

これらの文字列は合成例の提案文であり、実際のテナントの記録ではありません。レビュー前に実際のベースコミットとページバージョンを添付します。固定パッケージには、オーナーが内容を推測しなくて済むように、要約ではなく提案する本文全体を含めます。

オフラインのスナップショットとライブ公開を分けます。 整合性チェックで確認できるのは、取得済みの記録どうしの一致です。最初の書き込みの直前に、公開担当者は対応付けられたページを再確認し、メンテナーは保護されたベースを再確認します。どちらかが変更されていたら、古いパッケージをReviewで止めます。

台帳の状態を確認する #

状態遷移の例: 表に示すのは教材用のリビジョンであり、観測値ではありません。サンドボックスでの各書き込み後に、実際の結果バージョンとコミットを記入します。

配信保留は意味のある状態です。 公開が未完了の間、古い実装を新しい意図に準拠していると表現せずに済みます。この期間には「保持期間は30日」という要約だけではなく、両方の値が必要です。

失敗した試行は別のイベントとして追加します。 ランブックの書き込みに失敗しても、要件と構成の成功結果を残します。ランブックの試行、失敗、変更されなかったバージョン、割り当てられた役割、次の対応を記録します。完了行をPendingに戻して、観測した順序を消してはいけません。

古いバージョンが拒否される例: 公開担当者がREQ-17 v4を読み、別の許可された編集者がv5を公開した後、公開担当者がv4にPROP-042 r1を適用しようとします。プラットフォームがバージョン競合を報告するか、書き込み前の読み取りでv5が見つかります。実行者publisher、初期バージョンv4、試行PROP-042 r1、検出した競合または変更後の現在のバージョン、この試行では未変更の最終バージョンv5、割り当て先product ownerを記録します。JiraはReviewのままにします。v5を再読込し、文面を調整してから、新しい固定パッケージのレビューを依頼します。実環境でテストする場合は、実際のプラットフォーム応答とページ履歴を使います。この行は教材用の例です。

完了した教材例、値はすべて合成:

上記のラベルは説明用であり、テナントの証跡ではありません。台帳にはネイティブなページバージョンへのリンクとコミットIDが必要です。JiraをDoneにする前に、固定提案、両方の役割のレビュー、情報源ベースの記録、各公開結果の読み戻し、否定テストの結果、残っている実行時の制限を添付します。1つでも欠ける場合、配信をオープンまたはBlockedにします。

パッケージゲート: 5つの確認項目をそれぞれSupportedまたはBlockedにします。情報源のリビジョンが最新であること、両オーナーが同じ固定リビジョンを承認したこと、必要な公開がすべて読み戻し結果と一致すること、実行時の制限が明示されていること、復旧状態が調整済みであることです。Doneには5項目のSupportedと未承認の書き込みがないことが必要です。

結果が不明な書き込みに対処する #

タイムアウト後は結果が不明です。 成功も失敗も確認できません。ブラウザーを使う基本手順では、再試行する前に対応付けられた情報源を再度開き、現在の内容と履歴を調べます。

1. 次の手順を一時停止します: 配信を未完了のままにします。
2. 宛先を読み戻します: 現在の文面、バージョン、範囲を固定パッケージと比較します。
3. 確認結果を記録します: 完了、変更なし、競合、アクセス不可のいずれかです。
4. 次の対応を決めます: 確認済みの完了から続けるか、許可された変更のない手順を再試行するか、競合をエスカレーションします。
5. 不確実性を残します: 失敗または不明の試行を、後の読み戻しと一緒に保管します。

手順全体を無条件に再実行してはいけません。 完了済みの手順を再実行すると新しいリビジョンが作られ、関係のない編集を上書きするおそれがあります。確認済みの状態から再開します。情報源にアクセスできない場合は、古い台帳から推測せずHoldを選びます。

復旧の判断を比較する #

現在の状態とオーナーの判断を基に選択します。 続行には現在の承認と実行可能な制御が必要です。補償には、途中の変更を踏まえて復元案をレビューする必要があります。復旧の変更も新たな公開であり、プロセスの特権的な例外ではありません。

公開完了を確認する #

独立したレビュアーが照合できるパッケージを提出します。 レビュアーは、実際に確認した提案、その情報源ベース、両方の役割のレビュー、各書き込み結果、最終値、残っている実行時の制限を確認できる必要があります。中断後の最初の未完了手順を特定してもらいます。

期待する考え方: 次の対応は、前のアシスタントの自信ではなく、最新の情報源と台帳から決まります。最終的な対応付け参照を取得テストに引き継ぎ、検索でも同じ権威の区別が維持されるようにします。

トラブルシューティングと復旧 #

バージョンが変更された: 履歴を比較してレビューを更新します。スナップショット検証は成功したがwikiが異なる: 現在のConfluence情報源を再取得します。早すぎる完了: 許可された手順で再度開き、欠けている手順を記録します。

復旧: ページ履歴を比較し、オーナーがレビューした復元または補償編集を行います。復元で番号が初期化されると思い込まず、結果のバージョンを記録します。Productが取り消しを選んだ場合は、保護されたPRで構成を戻します。削除済みファイルはロールバックの対象外です。

演習と自己チェック #

**REQ-17の公開後に中断し、**別の公開担当者にはマップと台帳だけを渡します。

期待する考え方: 最新の情報源を取得し、固定承認を確認してから、許可された未完了の手順だけを再開します。証跡がなければ、作業をReviewに戻します。

主な参照資料 #

• 履歴と復元: Confluenceの技術文書
• バージョン管理されたAPI操作: Confluence REST API v2のページ
• ワークフロー制御: Jiraの高度なワークフロー
• 連携のセキュリティ: MCPセキュリティのベストプラクティス

次のステップ #

レビュー済みの公開を完了したら、 マップに基づく検索 に進みます。