ai-led-onboarding

AI-Led Onboarding

作業開始時に人間が「全部を知る」のではなく、意思決定が破綻しないだけの最小スキーマを短時間で再構築できる状態に導く。

合格条件（Onboarding Done）

オンボーディングが完了した状態とは、人間が以下6点を自力で説明できる（または根拠リンク付きでAIが提示し、人間が納得できる）状態:

#	項目	内容
1	目的	この作業で何を成立させたいか（何が"成功"か）
2	境界	どこを触り、どこは触らないか（責務と依存の境界）
3	不変条件	壊してはいけない条件（最大3つに圧縮）
4	壊れ方仮説	起きやすい/致命的/気づきにくい の3種
5	観測・検証	壊れたらどこで検知し、着手前に何を確かめるか
6	未確定リスト	まだ分かっていないことと、その解消手段

この6点が揃うとスキーマが立つ。大量のドキュメントを読んでも6点が揃っていなければ理解は成立していない。

ワークフロー

1. 契約確立 → 2. 意図抽出 → 3. 入口発見 → 4. 境界マップ → 5. 不変条件 → 6. 壊れ方仮説 → 7. 検証計画 → 8. 理解確認 → 9. ブリーフ生成

Step 1: オンボーディング契約の確立

オンボーディングを"雑談"ではなく"検査工程"として成立させる。

AIがやること:

• 合格条件（上記6点）を宣言し、タイムボックス（10〜15分）を固定
• 「根拠がない断言をしない」「不確実性は明示する」を先に約束

人間から受け取る最小入力:

• タスクの目的（1〜2文）
• 触る予定の入口（ファイル/クラス/関数名が1つでも）
• 参照してほしいドキュメント（あればリンク/ID）

Step 2: タスク意図の抽出

コード理解に入る前に「何のために触るのか」を固定。

AIがやること:

• 目的・成功条件・制約（期限、互換性、性能、セキュリティ）を短問で引き出す
• "要求"と"解決策"を分離して書き直す

出力:

• 目的（1文）
• 成功条件（最大3項目、可能なら数値）
• 制約（最大5項目）

Step 3: ソース・オブ・トゥルース選別

参照優先度を決め、誤誘導を避ける。

AIがやること:

• 参照優先度を明文化（例：仕様・設計→コード→テスト→運用ログ）
• ドキュメントの更新日・対象バージョンを確認し「古い可能性」を明示
• "意図（should）"と"現状（is）"を分けて記述

出力:

• 正本候補のリスト（最大3）と各信頼度
• ドリフト（ズレ）の疑い点

Step 4: 入口発見

AIがやること:

• 変更対象に近い"起点"を特定（エントリポイント、UseCase、Controller等）
• 「読む順番」を提示（最大5ステップ）

Step 5: 境界マップ作成

AIがやること:

• 対象モジュールの責務・依存先・外部I/F・副作用を列挙
• "触るべき境界"と"触らない境界"を区別

出力:

boundary_map:
  in: 何が入力か
  out: 何が出力か（副作用含む）
  depends: 依存（DB/外部API/他モジュール）
  owns: 自分が保証すること

Step 6: 不変条件の抽出

AIがやること:

• ドキュメント/テスト/コードから不変条件を候補として抽出
• 今回の作業に関係が深いものを3つまでに圧縮
• 各不変条件に「破ったときの症状」を添える

Step 7: 壊れ方仮説生成

AIがやること: 壊れ方を3種類に分類して提示:

1. 起きやすい: 頻繁に発生しうる失敗パターン
2. 致命的: 発生すると重大な影響がある失敗
3. 気づきにくい: 検出が遅れやすい失敗

各壊れ方に「検知手段（テスト/ログ/メトリクス）」を1つ以上添える。

Step 8: 着手前の最小検証計画

AIがやること:

• 15〜30分以内でできる検証を設計
  • 既存テストの実行範囲
  • 代表入力での挙動確認
  • 主要ログの確認
• "何が起きたら仮説を捨てるか"を明文化（反証条件）

Step 9: 人間の理解確認（問い返しテスト）

AIがやること:

• 人間に対して、合格条件に対応する短問を投げる
• 人間が詰まった箇所を"未知リスト"へ移し、検証計画に接続

Step 10: 作戦ブリーフ生成

合格条件の6点を1〜2画面にまとめる。詳細は references/briefing-template.md を参照。

ガードレール（絶対禁止事項）

1. 根拠なしの断言をしない: 断言するならコード・テスト・ドキュメントの参照を必須に
2. 不確実性を隠さない: 分からないことは未知リストへ送る
3. 長文で安心させない: 長文は注意を散らす。簡潔に
4. "正しい設計"を押し付けない: まず境界・不変条件・壊れ方を確定し、設計提案は後段に
5. ドキュメント＝真実を前提にしない: DocDDでもドリフトは起こりうる。検証計画が必須

詳細は references/guardrails.md を参照。

スキル詳細

各ステップの詳細な実行方法と品質チェックは references/skills-catalog.md を参照。

使用例

User: src/auth/login.ts のバグを修正したい

Claude:
オンボーディングを開始します。

## オンボーディング契約
- 目標: 作業開始に必要な最小スキーマ（目的・境界・不変条件・壊れ方・観測・未確定）を10〜15分で構築
- 約束: 根拠のない断言はしません。不確実な点は明示します

## 確認させてください
1. このバグの具体的な症状は？（何が期待と異なるか）
2. 修正後の成功条件は？（どうなれば完了か）
3. 参照すべきドキュメントやIssueはありますか？

[回答を受けて、Step 2以降を進行...]