チーム向けワークフローを設計する

課題：変更前チェックを再現可能にする

チームで繰り返している「プルリクエストを出す前の確認」を題材に、導入提案を作ります。ゴールは機能をできるだけ多く使うことではありません。手作業の問題を特定し、必要なものだけを選び、失敗したら安全に手動へ戻せる設計にします。

この演習では実プロジェクトの設定を変更したり、実サービスへ接続したりしません。架空のリポジトリとデータを使い、導入前の設計書を完成させます。

まず、現在の手順を箇条書きにして、担当者が判断している箇所、繰り返し抜ける確認、時間のかかる調査を分けます。少なくとも通常の変更と、失敗・例外を含むケースを一つずつ想定します。

実測できていない数字は推定値として分け、導入効果の根拠に混ぜないでください。

次の表を埋めます。採用しない機能にも理由を書き、目的のない仕組みの追加を避けます。

機能	今回の候補	判断の例
プロジェクト指示	共有すべき検証コマンドと既知の規約	常に必要な短い事実だけを記載する
Skill	変更前チェックの手順と報告形式	手順が安定してから再利用可能な形にする
サブエージェント	差分から関連テストを探す調査	独立して返せる読み取り専用の作業に限る
Hook	決定的なローカル検証	起動条件、入力、副作用、失敗時動作が明確な場合のみ
MCP	課題管理の情報を参照する必要性	必要な情報がローカルにないと確認できるまでは接続しない

複数の機能を選ぶ場合は、役割の重複と、機能間で受け渡す情報を説明します。たとえば、手順の説明だけならSkillで足り、イベントに応じた決定的なコマンド実行まで必要な場合にのみHookを別途検討します。

文章または図で、次の流れを記録します。

開始条件 → 入力データ → 読み取り・処理 → 人の確認 → 出力先

各段階について、実行主体、読み書きできる対象、外部送信の有無を記載します。課題本文やコードコメントなど外部から入る文字列は、指示ではなく未信頼データとして扱います。最初のPoCではテスト用データと読み取り専用の範囲を優先し、書き込みや公開操作は自動化の対象にしません。

秘密情報を演習用ファイル、プロンプト、ログに貼り付けないでください。認証情報が必要な構成は、チームの承認済みの保管方法と運用規則を別途確認します。

導入前に、通常ケースと失敗ケースの両方で確認する項目を定めます。最低限、出力が正しいこと、禁止した書き込みが起きないこと、異常時に処理を止めて人へ報告することを評価します。速度や利用量は、レビューにかかった時間も含めて既存の手順と比較します。

PoCの合格・中止条件は「便利そう」といった印象ではなく、観察できる結果で書きます。安全や品質の条件を満たさない場合は、速度が向上していても合格にしません。

次の見出しを使い、1〜2ページ程度の提案を作ります。

公式ドキュメントの参照先を2026年10月18日に確認しました。実際の設定、権限、利用可能な機能は導入時点の公式資料とチームの運用ポリシーで確認してください。