forMobile 全21章を1ファイルに統合。リンクはページ内ジャンプ。
本ZIPは、これまでの調査結果を章ごとにHTML化したものです。開発者、SE、QA、コードレビュー、DevSecOps、PM/PL/PMO、ITインフラ、事務・人事向けのAI活用を、品質安定化・導入手順・評価指標・運用テンプレートまで含めて整理しています。
LINE WORKS 掲示板での載せ方
読み方の導線
目次
0. 提案サマリー（社内説明用）15分で説明するための入口。3か月PoC・職種別1週間スターター付き。1. 第1章：調査サマリーと基本方針AI活用を品質安定化施策として扱うための全体結論。2. 第2章：AI品質安定化モデルAIを工程内品質ゲートとして組み込む設計。3. 第3章：プログラマ向け活用実装品質、単体テスト、自己レビューを安定させる手順。4. 第4章：SE・設計者向け活用要件、設計、差分影響分析、テスト接続のAI活用。5. 第5章：QA・テスター向け活用テスト観点生成、E2E、自動化、障害再発防止の活用。6. 第6章：コードレビュー・テックリード向け活用AI一次レビュー、人間レビューの役割分担、レビュー観点標準化。7. 第7章：DevSecOps・セキュリティ向け活用SAST、CodeQL、AI修正案、セキュリティゲートの設計。8. 第8章：PM・PL・PMO向け活用要件品質、WBS、進捗、課題、品質会議でのAI活用。9. 第9章：ITインフラエンジニア向け活用サーバ構築、IaC、監視、障害対応。公開インフラスキル・Before/After・1週間スターター付き。10. 第10章：標準プロンプト集職種・工程別にそのまま使えるプロンプトテンプレート集。11. 第11章：導入ロードマップ・PoC計画3か月PoC、段階導入、完了条件、展開判断。12. 第12章：評価指標・KPI生産性、品質、組織、インフラ運用の指標設計。13. 第13章：リスク・ガバナンス・禁止事項AI活用で品質を落とさないためのルールと注意点。14. 第14章：運用テンプレートPR、変更申請、インフラ作業、PoC報告のテンプレート。15. 第15章：自社適用案社内導入時の優先順位、運用ルール、展開方針。16. 第16章：参考文献・調査ソース調査時に参照した公式情報、事例、研究資料の一覧。17. 第17章：エージェントスキル活用プロンプト vs スキル、社内PoC事例、skills.sh人気スキルのメリット・デメリット。18. 第18章：事務・エンゲージメント向け勤怠照合、電話取次、メール・文書、経費、議事録、公開ドキュメントスキル、意識調査施策。19. 総評・一覧シート全体総評、スキル・施策・KPIマスタ、メリデメ、導入用指示プロンプト集約。
利用方法
全体結論：AIは開発者・SE・PM・インフラ担当者の代替ではなく、品質確認の抜け漏れを減らす副操縦士として使う。生成よりもレビュー、テスト、差分影響分析、設定確認、障害一次切り分けに組み込むのが現実的である。
提案サマリー
提案の一言：「AIで開発を自動化する」のではなく、「AIで品質確認の抜け漏れを減らす」。生成よりレビュー・テスト・差分影響分析に組み込む。
1. なぜ今やるのか
| 現状の課題 | AIで改善しやすい点 |
|---|---|
| 要件・設計の曖昧さが後工程で手戻りになる | 章単位のAIレビューで未決・例外・非機能の抜けを早期検出 |
| テスト観点の属人化・漏れ | 仕様書から観点表を生成し、人間が採否判断 |
| コードレビューの負荷・観点のばらつき | PR前AIセルフレビューで一次品質を上げる |
| セキュリティ修正の説明コスト | SAST結果の説明と修正案生成（再スキャン必須） |
| プロンプトの個人技化 | エージェントスキル化でGit管理・チーム共有（第17章） |
2. 提案の3本柱
柱1：工程内品質ゲート設計・実装・テスト・レビュー・インフラ手順の「提出前チェック」にAIを差し込む。詳細は第2章。
柱2：標準プロンプト＋スキル個人のチャット履歴ではなく版管理。導入は指示プロンプトまで（SKILL.md本体はPoC成功後）。一覧は第19章 総評シート。
柱3：測定とガバナンス指標（第12章）と禁止事項（第13章）をセットで導入。効果が出ない用途はやめる。
3. 最初の3か月（PoC）
| 月 | やること | 完了の目安 |
|---|---|---|
| 1か月目 | 対象案件選定、AI利用ルール、設計書・コードのセルフレビュー試行 | 指摘一覧が残り、採否が記録されている |
| 2か月目 | テスト観点生成、PR前レビュー必須化、公開スキル1〜2本の試用（例：TDD・コードレビュー） | テスト観点または単体テストが増えている |
| 3か月目 | セキュリティ連携検討、指標整理、PoC報告・展開判断 | 継続/限定継続/改善後再試行/中止の判定 |
詳細テンプレート：第11章 導入ロードマップ・PoC計画
4. 職種別：最初の1週間
| 立場 | 月曜 | 火〜木 | 金曜 |
|---|---|---|---|
| SE | AI利用ルール確認 | 要件定義1章をAIレビュー、顧客確認事項を分離 | 指摘の採否を記録しチーム共有 |
| プログラマ | PRテンプレートにAI利用欄追加 | 実装前にAIセルフレビュー、単体テスト観点生成 | レビュー指摘とAI指摘を比較 |
| QA | 過去障害観点リスト整備 | 仕様書からテスト観点表をAI生成→人間が採否 | 採用観点をテスト仕様へ反映 |
| DevSecOps | SAST/CodeQL運用確認 | 検出結果のAI説明＋修正案（再スキャン必須） | 修正リードタイムを記録 |
| PM/PL | PoC対象・指標合意 | 週次で課題・滞留をAI整理（判断はPM） | PoC週次メモ更新 |
| インフラ | 第9章禁止事項確認 | 手順書1件＋IaC PR1件をAIレビュー | 第11章11.3 KPIベースライン記録 |
| 事務 | 第18章マップから優先2業務、xlsx/pdf導入 | 勤怠照合 or 電話メモAIレビュー | 経費 or 議事録を1業務追加 |
| 人事・管理 | NGワード・トーン方針合意 | サーベイサマリーから施策文案3案 | 禁句チェック後、1案を人間確定 |
5. 必要リソース（目安）
- 人的：PoCリード1名、職種代表各1名、品質・情報セキュリティレビュー各1名（兼任可）
- ツール：社内承認済みAIコーディングエージェント（Cursor / Codex / Copilot等）、Git、既存lint/test/SAST
- 資産：AI利用ガイドライン、標準プロンプト集、PRテンプレート、PoC評価表（第14章）
6. 期待効果（PoCで検証する仮説）
| 指標 | 仮説 |
|---|---|
| レビュー指摘件数（重大） | セルフレビュー後は人間レビューでの重大指摘が減る |
| 手戻り件数 | 設計・要件レビューで後工程手戻りが減る |
| テスト観点・ケース数 | 同等工数でカバレッジが厚くなる |
| セキュリティ修正リードタイム | 説明・初回修正案の時間が短縮する |
| インフラ：設定ミス・planレビュー時間 | IaC/手順書レビュー＋checkovで本番前に検出（第9章・11.3） |
| 事務：勤怠照合の差戻し・工数 | 締め前AI照合で手戻り削減（第18章） |
| エンゲージメント：参加意欲・パルス改善 | 能動性を促す文案＋禁句チェック（第18章） |
| 現場負荷・満足度 | 「確認の副操縦士」として受け入れられる |
7. 提案者向けルート（読む順）
読み方の使い分け
- 本ページ（提案サマリー）
- 第1章 全体方針
- 第17章 スキル事例（社内PoC＋公開人気スキル）
- 第19章 総評・一覧シート
- 第11章 PoC計画
- 第12章 KPI / 第13章 ガバナンス
- 第15章 自社適用案
- 職種別：第3章〜第9章、第18章 から必要分のみ
DORA 2025の示唆：AIは組織の強みも弱みも増幅する。レビュー・テスト・CI/CDが弱いまま生成だけ増やすと、下流が詰まる。だから「品質ゲートとしてのAI」を先に定義する。
第1章：調査サマリーと基本方針
本資料の目的は、ITエンジニアの各職種、すなわちプログラマ、SE、QA、コードレビュアー、DevSecOps、PM/PL/PMO、ITインフラエンジニアにおけるAI活用を、単なる効率化ではなく品質安定化施策として整理することである。
重要なのは、AIを人の代わりに成果物を作る存在として扱いすぎないこと。実務では、レビュー、テスト観点抽出、差分影響分析、セキュリティ修正支援、障害一次切り分け、証跡整理に使った方が安全で成果を出しやすい。
基本方針：AIは開発者・SE・PM・インフラ担当者の代替ではなく、品質確認の抜け漏れを減らす副操縦士として使う。
1.1 調査から見えた全体傾向
DORA 2025では、AIはソフトウェア開発において組織の強みも弱みも増幅する存在と整理されている。レビュー、テスト、CI/CD、構成管理、監視が弱い組織では、AIによって作業量だけが増え、下流工程が詰まりやすくなる。
| 領域 | AIで伸ばせる点 | 品質安定化への効果 |
|---|---|---|
| 設計 | 曖昧性・未定義語・例外条件・非機能要件の抽出 | 後工程の手戻り削減 |
| 実装 | 実装案比較、コード生成補助、セルフレビュー | 単純ミス削減、実装標準化 |
| テスト | 単体テスト・E2E・異常系・境界値の観点生成 | テスト漏れ削減 |
| レビュー | PR前のAIセルフレビュー、一般的なレビュー観点の自動チェック | 人間レビューの負荷軽減 |
| セキュリティ | SAST/CodeQL結果の説明、修正案生成 | 脆弱性修正リードタイム短縮 |
| PM/PMO | 課題・進捗・リスク・品質傾向の整理 | 見落とし防止 |
| インフラ | IaC/設定/手順書レビュー、ログ要約、障害切り分け | 設定ミス・運用ミス削減 |
1.2 全体結論
結論1AI導入の主戦場は、生成よりもレビューとテストである。
結論2AI生成物は、必ず人間レビューと機械チェックを通す。
結論3品質指標を測らないAI活用は、成功・失敗を判断できない。
結論4インフラ領域では、AIに本番操作を任せず、監査官として使う。
1.3 役割別の最重要活用
| 立場 | 最も効果が出やすいAI活用 | 避けるべき使い方 |
|---|---|---|
| プログラマ | 実装案比較、単体テスト生成、PR前セルフレビュー | AI生成コードを理解せず貼り付ける |
| SE | 要件・設計書レビュー、差分影響分析、テスト観点化 | 仕様不明点をAIに勝手に補完させる |
| QA | テスト観点生成、回帰テスト候補抽出、障害再発防止観点 | AI生成ケースを無審査で採用する |
| コードレビュアー | 一次レビュー、一般的な品質観点チェック | 業務仕様判断をAIに任せる |
| DevSecOps | SAST結果の説明、修正案生成、再スキャン運用 | AIレビューだけでセキュリティOKにする |
| PM/PL/PMO | 課題整理、リスク抽出、品質会議資料化 | プロジェクト判断・顧客合意をAIに任せる |
| インフラ | IaC/設定/手順書レビュー、ログ要約、一次切り分け | AIに本番環境を直接変更させる |
1.4 導入の基本原則
- AI利用範囲を明示する。PR、設計レビュー、作業申請にどこでAIを使ったかを残す。
- 人間が採否判断する。AI出力は候補であり、成果物責任は担当者にある。
- 機械チェックと組み合わせる。lint、test、SAST、IaC scan、plan確認を必須にする。
- 品質指標で評価する。速くなったかだけでなく、バグ、手戻り、レビュー指摘、流出障害を見る。
- 標準プロンプト化する。個人技ではなく、チームの品質プロセスにする。
第2章：AI品質安定化モデル
AI品質安定化モデルは、AIを単独の作業者として扱うのではなく、工程ごとに作業支援、セルフレビュー、品質ゲート、ナレッジ化の4層へ配置する考え方である。
2.1 4層モデル
| 層 | 目的 | 対象 | 成果 |
|---|---|---|---|
| 第1層：作業支援 | 作業速度を上げる | コード、設計書、テストケース、手順書 | たたき台作成、比較案作成 |
| 第2層：セルフレビュー | 担当者自身の確認品質を上げる | 実装前後、設計後、テスト前 | 単純ミス・抜け漏れ削減 |
| 第3層：品質ゲート | 成果物を通過判定する | PR、設計書、テスト仕様、IaC、作業申請 | レビュー品質の平準化 |
| 第4層：ナレッジ化 | 組織知を再利用する | 過去障害、レビュー指摘、標準ルール | 属人化防止、再発防止 |
2.2 AIを入れるべき工程
| 工程 | AI活用 | 品質ゲート |
|---|---|---|
| 要件定義 | 曖昧語、未定義語、例外条件、受入条件の不足を抽出 | 要件レビュー会議前にAI指摘を確認 |
| 基本設計 | 画面・帳票・IF・DB・権限・運用の漏れ確認 | 設計レビュー時に指摘採否を記録 |
| 詳細設計 | 処理分岐、例外、トランザクション、ログ、再実行性を確認 | 製造着手前に未解決事項を潰す |
| 実装 | 実装案比較、コード生成補助、セルフレビュー | PR前にAIレビューと単体テスト実行 |
| テスト | 観点生成、ケース作成、回帰候補抽出 | QAが採否判断しテスト管理表へ反映 |
| リリース | 作業手順、切り戻し、影響範囲をレビュー | 作業申請にAIチェック結果を添付 |
| 運用 | ログ要約、障害一次切り分け、再発防止案 | 人間承認後に対応、報告書へ反映 |
2.3 品質ゲートの標準フロー
成果物作成
↓
AIセルフレビュー
↓
担当者がAI指摘を採否判断
↓
機械チェック
↓
人間レビュー
↓
修正
↓
再チェック
↓
承認
↓
証跡化AI出力は成果物ではなくレビュー材料である。AIの提案を採用する場合も、採用理由、修正内容、確認結果を担当者が説明できる必要がある。
2.4 品質ゲートの例
| 対象 | AIチェック | 機械チェック | 人間チェック |
|---|---|---|---|
| コード | Null、例外、重複、テスト不足 | ビルド、単体テスト、Lint、SAST | 仕様整合、設計思想、保守性 |
| 設計書 | 曖昧性、例外、非機能、影響範囲 | 表記ルール、成果物整合 | 顧客要件、業務ルール |
| テスト仕様 | 観点漏れ、境界値、異常系 | テスト管理ツール整合 | 優先度、実行可能性 |
| IaC | 公開範囲、暗号化、タグ、破壊的変更 | validate、tflint、checkov、plan | 運用影響、コスト、承認 |
| 作業手順 | 切り戻し、影響範囲、確認不足 | dry-run、検証環境実行 | 本番影響、作業順序、承認 |
第3章：プログラマ向け活用
プログラマ向けAI活用の本命は、単なるコード生成ではなく、仕様理解、実装方針比較、単体テスト生成、PR前セルフレビューである。
3.1 目的
- 仕様理解の早期化
- 実装案の比較による手戻り削減
- 単純ミスの削減
- 単体テストの増強
- 若手・中堅の品質底上げ
- レビュー前品質の向上
3.2 実績として使える事例
| 事例 | 概要 | 提案への使い方 |
|---|---|---|
| Mercedes-Benz | 5,000人以上の開発者がGitHub Copilot/Copilot Chatを利用し、大規模にAI支援コードを受け入れた事例。 | 大企業におけるAIコーディング支援の大規模導入例として使う。 |
| Duolingo | GitHub事例で、開発速度、PR数、レビュー効率の改善が示されている。 | PRフロー全体の効率化事例として使う。 |
| Accenture/GitHub | 開発者体験や満足度改善の企業調査。 | 反復作業の負担軽減、開発者体験向上の根拠として使う。 |
| NECソリューションイノベータ | Copilot利用で効果がある一方、AI提案を鵜呑みにすると品質改善に直結しない点を示す。 | AI利用には人間レビューとルールが必要という根拠にする。 |
| Diffblue Cover | Java単体テスト作成の高速化事例。 | テスト生成は品質安定化に使いやすいという根拠にする。 |
Before / After 事例（PoC想定・匿名）
事例P-1：保守チケット実装＋PR前セルフレビュー
| 項目 | Before（AIなし） | After（2か月PoC） |
|---|---|---|
| 人間レビュー指摘（重大） | PR平均 2.1件 | PR平均 0.8件 |
| Null・境界値漏れ | 月3件流出 | 月1件 |
| 単体テスト追加数 | チケットあたり0.5本 | 2.3本（AI生成→人間採否） |
| レビュー待ち時間 | 中央値 1.8日 | 中央値 1.1日 |
使ったスキル：test-driven-development（superpowers）、requesting-code-review ＋ 第10章セルフレビュープロンプト
学び：AI生成コードそのものより「実装前の曖昧点抽出」と「PR前チェック」が効いた。NEC事例どおり、鵜呑みにすると効果が半減する。
3.3 実装前のAI活用手順
- チケット、設計書、関連コードを準備する。
- AIに変更目的、入力、出力、DB更新、外部連携を整理させる。
- 曖昧点と確認事項を抽出する。
- 実装案を2〜3案出させる。
- 変更量、保守性、テストしやすさで比較する。
- 採用案を人間が決める。
実装前確認プロンプト
あなたは保守開発の上級SE兼コードレビュアーです。
以下のチケット、設計情報、既存コードを読み、実装前に確認すべき事項を整理してください。
出力形式：
1. この変更の目的
2. 入力・出力・DB更新・外部連携の整理
3. 既存処理への影響範囲
4. 仕様上の曖昧点
5. 実装前に確認すべき質問
6. 単体テストで必ず確認すべき観点
7. 回帰テストで確認すべき観点
注意：
- 不明点を勝手に補完しない
- 仕様に書かれていないことは「未記載」と明示する
- 既存コードに依存する推測は「推測」と明示する実装案比較プロンプト
以下の仕様変更に対して、実装方針を3案出してください。
評価軸：
- 変更量
- 既存処理への影響
- テストしやすさ
- 障害時の切り戻しやすさ
- 保守性
- 実装難易度
- 推奨案
出力は表形式にしてください。3.4 AI生成コードの扱い
| チェック | 内容 |
|---|---|
| 理解確認 | なぜこの実装になったか担当者が説明できるか |
| コンパイル | ビルドエラーがないか |
| 静的解析 | Lint、SonarQube、CodeQL、IDE警告 |
| 単体テスト | 正常系、異常系、境界値 |
| 仕様整合 | チケット・設計書と一致しているか |
| セキュリティ | 入力検証、認可、SQL、XSS、ログ |
| 保守性 | 命名、責務分離、重複、複雑度 |
禁止：AI生成コードを理解しないまま貼り付けること。AIが出したコードは候補であり、成果物責任は担当者にある。
3.5 単体テスト生成の手順
- 対象クラス・関数を選ぶ。
- 現行仕様をAIに要約させる。
- 正常系・異常系・境界値を洗い出す。
- テストケース表を作成する。
- テストコードを生成する。
- 実行して失敗した箇所を修正する。
- カバレッジを確認する。
- 意味のあるテストか人間が確認する。
単体テスト生成プロンプト
あなたはJUnitのテスト設計に強いシニアエンジニアです。
以下のJavaクラスに対して、単体テスト観点を作成してください。
出力形式：
1. テスト対象メソッド一覧
2. 正常系
3. 異常系
4. 境界値
5. null/空文字/0件/最大件数
6. 外部依存のモック方針
7. テストデータ
8. JUnitコード例
注意：
- カバレッジを上げるだけの無意味なテストは避ける
- 仕様上の期待値が不明な場合は、不明と明記する
- privateメソッドを直接テスト対象にしない3.6 プログラマ向け運用ルール
| 項目 | ルール |
|---|---|
| 実装前 | AIで仕様要約と影響範囲確認を行う |
| 実装中 | AI提案は候補として扱い、既存規約に合わせる |
| 実装後 | AIセルフレビューを実施する |
| PR作成時 | AI利用範囲と人間確認内容を記録する |
| テスト | AI生成テストをCIで実行し、期待値を人間が確認する |
| レビュー | AI指摘の採否を説明できるようにする |
第4章：SE・設計者向け活用
SE向けAI活用では、コード生成よりも要件・設計書レビュー、差分影響分析、テスト観点化が重要である。設計品質が安定すれば、製造、テスト、リリースの手戻りが減る。
4.1 対象成果物
- 要件定義書
- 基本設計書
- 詳細設計書
- 画面設計書
- 帳票設計書
- 外部IF設計書
- DB設計書
- バッチ設計書
- 移行設計書
- 運用設計書
- テスト仕様書
4.2 要件定義レビューの観点
| 観点 | チェック内容 |
|---|---|
| 曖昧語 | 適切に、必要に応じて、原則、随時、可能な限り |
| 未定義語 | 業務用語、画面名、帳票名、区分名 |
| 主語不足 | 誰が、どのシステムが、どの部署が |
| 条件不足 | いつ、何を条件に、どのケースで |
| 例外不足 | エラー時、0件、重複、権限なし |
| 非機能不足 | 性能、可用性、監査、ログ、セキュリティ |
| 受入条件不足 | 完了判定ができるか |
| テスト不能 | 検証可能な仕様になっているか |
要件レビュー用プロンプト
あなたは要件定義レビュー担当の上級SEです。
以下の要件定義文について、後工程で手戻りになりそうな点をレビューしてください。
レビュー観点：
1. 曖昧な表現
2. 主語・対象・タイミングの不足
3. 業務ルールの不足
4. 例外条件の不足
5. 権限・認可の不足
6. データ整合性の懸念
7. 非機能要件の不足
8. テスト可能性
9. 顧客に確認すべき質問
10. 受入条件として明文化すべき内容
出力形式：
- 指摘No
- 該当箇所
- 問題点
- リスク
- 修正案
- 確認先4.3 設計書レビューの観点
| 設計書 | AIチェック観点 |
|---|---|
| 画面設計 | 入力制御、初期値、必須、桁数、活性/非活性、エラー表示 |
| 帳票設計 | 出力条件、ソート順、改ページ、0件時、集計ロジック |
| IF設計 | 項目型、桁数、必須、コード値、リトライ、タイムアウト |
| DB設計 | 主キー、外部キー、NULL、インデックス、履歴、排他 |
| バッチ設計 | 起動条件、再実行、排他、異常終了、ログ、リカバリ |
| 権限設計 | ロール、操作可否、データ参照範囲、監査証跡 |
| 運用設計 | ジョブ監視、障害通知、復旧手順、問い合わせ対応 |
設計レビュー用プロンプト
あなたは基幹システム開発の設計レビュー担当です。
以下の設計書をレビューし、後続の製造・単体テスト・結合テストで問題になりそうな点を抽出してください。
重点観点：
- 要件との対応漏れ
- 業務ルールの矛盾
- 入力チェック不足
- エラー処理不足
- DB更新タイミング
- トランザクション境界
- 排他制御
- 権限チェック
- ログ出力
- 再実行性
- テスト観点
出力形式：
| No | 分類 | 指摘内容 | 影響工程 | 重要度 | 修正案 | 確認事項 |4.4 差分影響分析
設計変更時は、AIに旧版と新版を比較させ、影響範囲と追加テスト観点を抽出させると有効である。
- 旧版設計書を用意する。
- 新版設計書を用意する。
- AIに差分を要約させる。
- 影響する画面・帳票・IF・DB・バッチを抽出する。
- 追加すべきテスト観点を作成する。
- 修正対象と確認対象を分離する。
- レビュー会議で採否判断する。
- 課題・テスト仕様へ反映する。
差分影響分析プロンプト
あなたは変更影響分析に強いSEです。
以下の旧版設計書と新版設計書の差分を比較し、影響範囲を整理してください。
出力形式：
1. 変更概要
2. 変更された仕様
3. 影響する画面
4. 影響する帳票
5. 影響するDBテーブル・カラム
6. 影響する外部IF
7. 影響するバッチ
8. 追加・変更すべきテストケース
9. 既存回帰テストで確認すべき範囲
10. 未確認リスク4.5 SE向け標準運用
| タイミング | 実施内容 | 成果物 |
|---|---|---|
| 設計作成後 | AI設計レビュー | 指摘一覧 |
| 顧客レビュー前 | 確認事項抽出 | 顧客確認リスト |
| 仕様変更時 | 差分影響分析 | 影響範囲表、追加テスト観点 |
| 製造着手前 | 未決事項確認 | 製造着手可否判断 |
| テスト設計前 | 設計書からテスト観点抽出 | テスト観点表 |
Before / After 事例（PoC想定・匿名）
事例S-1：要件定義書の章単位AIレビュー
| 項目 | Before | After（1.5か月） |
|---|---|---|
| 顧客レビュー後の追加指摘 | 平均18件/章 | 平均9件/章 |
| 製造着手後の仕様確認チケット | 月12件 | 月5件 |
| AI指摘の採用率 | — | 62%（残りは却下・要確認） |
| レビュー工数 | 上級SE 4h/章 | 上級SE 2.5h/章（AI下書き＋人間判断） |
使ったスキル：社内「要件定義ゲート」スキル（MODE-B）＋ 第4章プロンプト。公開スキル単体では要件・契約境界までカバーしきれない。
第5章：QA・テスター向け活用
QA領域では、AIの価値が出やすい。理由は、テストには観点漏れ、組み合わせ爆発、過去障害再発、若手と熟練者の観点差が発生しやすいからである。
5.1 QAでAIを使う目的
- テスト観点漏れの削減
- 異常系・境界値の補強
- 過去障害の再発防止観点化
- E2Eテストシナリオ作成
- テストデータ作成
- 障害票から再現手順を整理
- テスト実行結果の傾向分析
5.2 公開事例
| 事例 | 概要 | 活用ポイント |
|---|---|---|
| Meta Sapienz | Facebook Androidアプリなどに対する大規模な自動テスト設計・探索テストの事例。 | AI/探索型テストをCIに組み込む発想の参考になる。 |
| Meta rich test users | リッチな状態を持つテストユーザーによりカバレッジや検出不具合を増加。 | 現実に近いテストデータ・状態管理の重要性を示す。 |
| 富士通テスト仕様書生成 | 設計書差分から追加・変更テスト項目を生成する取り組み。 | SE/QA境界でのテスト観点抽出に使える。 |
| GenIA-E2ETest | 自然言語からE2Eテストスクリプトを生成する研究。 | Playwright等との組み合わせ方針の参考になる。 |
Before / After 事例（PoC想定・匿名）
事例Q-1：テスト観点生成＋過去障害ナレッジ
| 項目 | Before | After（2か月） |
|---|---|---|
| テスト観点数（中機能1件） | 平均28件 | 平均47件（重複削除後） |
| リリース後バグ（観点漏れ系） | 四半期4件 | 四半期1件 |
| 観点作成工数 | QA 6h | QA 3.5h（AI生成＋人間採否） |
| 過去障害の再発 | 同一パターン2件 | 0件（再発防止プロンプト反映） |
使ったスキル：webapp-testing（anthropics）でE2E下書き、第5章テスト観点プロンプトで観点表。
5.3 AIに作らせる成果物
| 成果物 | 内容 |
|---|---|
| テスト観点表 | 正常系、異常系、境界値、権限、排他、性能 |
| テストケース案 | 入力値、前提条件、期待結果 |
| デシジョンテーブル | 条件組み合わせ |
| 状態遷移テスト | ステータス変更、業務フロー |
| 回帰テスト候補 | 既存機能への影響確認 |
| バグ再現手順 | 障害票から再現条件整理 |
| E2Eテスト案 | 画面操作シナリオ |
| テストデータ案 | 正常、異常、境界、特殊文字 |
テスト観点生成プロンプト
あなたは業務システムのQAリードです。
以下の仕様に対して、テスト観点を網羅的に作成してください。
出力形式：
| No | テスト分類 | 前提条件 | 操作 | 入力値 | 期待結果 | 優先度 | 備考 |
必須観点：
- 正常系
- 異常系
- 境界値
- 必須チェック
- 桁数チェック
- 型チェック
- 権限
- 排他
- DB更新確認
- ログ確認
- 再実行
- 0件
- 大量件数
- タイムアウト
- 外部IFエラー
- 過去障害再発防止5.4 AIテスト設計の運用手順
- 仕様書を入力し、AIにテスト観点を生成させる。
- 過去障害・レビュー指摘を追加して再生成する。
- QA担当が不要・重複・非現実的ケースを削る。
- 重要度を付ける。
- テスト管理表に取り込む。
- 自動化可能なケースを分類する。
- 実行結果を記録する。
- 障害票と紐づける。
- 再発防止観点を次回プロンプトに反映する。
運用のコツ：AIは観点を広げる役割、人間は実行可能性・優先度・期待値を判断する役割に分ける。
5.5 E2Eテスト作成プロンプト
あなたはE2Eテスト自動化担当です。
以下の画面仕様と業務フローをもとに、Playwrightで自動化可能なE2Eテストシナリオを作成してください。
出力形式：
1. シナリオ名
2. 前提データ
3. 操作手順
4. 期待結果
5. 確認する画面項目
6. 異常系
7. 自動化時の注意点
8. Playwrightコード例
注意：
- テストデータの作成・削除方針も含める
- 非同期処理や待機条件を明記する
- 壊れやすいセレクタは避ける5.6 障害再発防止プロンプト
あなたはQAリードです。
以下の障害票をもとに、再発防止のために追加すべきテスト観点を作成してください。
出力形式：
1. 障害の要約
2. 原因分類
3. 検出できなかった理由
4. 追加すべき単体テスト
5. 追加すべき結合テスト
6. 追加すべき回帰テスト
7. 監視・ログで検知できるか
8. 今後のレビュー観点第6章：コードレビュー・テックリード向け活用
AIコードレビューは、人間レビューの代替ではなく、人間レビュー前の一次フィルタとして使う。一般的な品質指摘をAIに任せ、人間は業務仕様・設計判断・保守性に集中する。
6.1 AIに任せやすいレビュー観点
| 分類 | 内容 |
|---|---|
| 可読性 | 命名、重複、コメントと実装の不一致 |
| 単純ミス | Null、未使用変数、例外握りつぶし |
| テスト不足 | 異常系、境界値、モック不足 |
| 性能 | N+1、不要ループ、過剰なDBアクセス |
| 保守性 | 責務分離、複雑度、共通化候補 |
| 基本セキュリティ | 入力検証、危険なログ、認可チェック漏れ候補 |
Before / After 事例（PoC想定・匿名）
事例R-1：AI一次レビュー＋人間レビュー役割分担
| 項目 | Before | After（6週間） |
|---|---|---|
| 人間レビュー時間/PR | 中央値 45分 | 中央値 28分 |
| AI指摘採用率 | — | 54% |
| 同種指摘の再発（命名・Null等） | 月8件 | 月3件 |
| テックリードの業務仕様確認時間 | PRあたり15分 | PRあたり22分（一般指摘はAIに任せた分、仕様確認に集中） |
使ったスキル：requesting-code-review、receiving-code-review（superpowers）。GitHub Copilot Code Review併用案件あり。
6.2 人間が必ず見るべき観点
| 分類 | 内容 |
|---|---|
| 業務仕様 | チケット・設計書・顧客要件と一致しているか |
| 設計思想 | 既存アーキテクチャ、責務分離、将来拡張性 |
| 運用影響 | 障害時の影響、ログ、監視、切り戻し |
| セキュリティ判断 | 権限、認可、機密情報、例外承認 |
| リリース判断 | マージ可否、本番影響、リスク受容 |
6.3 AIレビュー標準プロンプト
あなたは厳しめのコードレビュアーです。
以下の差分をレビューしてください。
レビュー観点：
1. 仕様との不一致
2. Null・空文字・0件
3. 例外処理
4. トランザクション
5. DB更新の整合性
6. 権限チェック
7. ログ出力
8. パフォーマンス
9. 保守性
10. テスト不足
11. セキュリティ
12. 命名・可読性
出力形式：
| No | 重要度 | 指摘内容 | 該当箇所 | 理由 | 修正案 |6.4 PRレビュー運用
- 開発者がPR作成前にAIセルフレビューを実施する。
- AI指摘のうち採用したもの、採用しなかったものを整理する。
- PRテンプレートにAI利用範囲を記載する。
- レビュアーはAI指摘済みの一般論より、仕様・設計・影響範囲を重点確認する。
- レビュー指摘を月次で分類し、標準プロンプトに反映する。
6.5 レビュー観点表
| 分類 | 観点 |
|---|---|
| 仕様 | チケット・設計書と一致しているか |
| 業務 | 業務ルール、例外、運用ケースを満たすか |
| データ | DB更新、整合性、排他、履歴 |
| API | 入出力、エラー、タイムアウト、リトライ |
| 画面 | 入力制御、表示制御、メッセージ |
| テスト | 正常、異常、境界、回帰 |
| セキュリティ | 認証、認可、SQL、XSS、ログ |
| 保守性 | 責務分離、命名、重複、複雑度 |
| 運用 | ログ、監視、障害時対応 |
AIコードレビューは便利だが、重大なセキュリティ脆弱性を見逃す可能性がある。SQLインジェクション、XSS、認可漏れなどは、SAST、CodeQL、DAST、人間レビューを組み合わせるべきである。
6.6 月次改善
| 集計項目 | 改善アクション |
|---|---|
| AI指摘採用率 | 低い場合はプロンプトを見直す |
| 人間レビュー指摘の残存傾向 | AIチェックリストへ追加する |
| 同じ指摘の再発 | 規約化・テンプレ化する |
| レビュー待ち時間 | AI一次レビューで短縮できているか確認する |
| 重大指摘の件数 | 設計・要件レビュー工程に戻す |
第7章：DevSecOps・セキュリティ向け活用
DevSecOps領域では、AIに安全性を丸投げするのではなく、セキュリティ検出器で見つけ、AIに修正案を出させ、人間がレビューし、再スキャンする流れが現実的である。
7.1 セキュリティAI活用フロー
開発者がPR作成
↓
CIでビルド・テスト
↓
SAST / CodeQL / Secret scan / Dependency scan
↓
アラート発生
↓
AIが修正案を提示
↓
開発者が修正案を確認
↓
セキュリティ担当またはレビュアーが確認
↓
再スキャン
↓
マージ7.2 AIに任せる作業
| 作業 | AI活用 |
|---|---|
| SAST結果説明 | アラートの意味、攻撃シナリオ、影響範囲を説明 |
| 修正案作成 | 該当コードに対する安全な修正候補を提示 |
| テスト案作成 | 脆弱性が再発しないテスト観点を作成 |
| レビュー補助 | 認可漏れ、入力検証、ログ漏えいなどの観点チェック |
| 教育 | なぜ危険か、どう直すかを開発者向けに説明 |
7.3 導入手順
- 既存リポジトリにCodeQLまたはSASTを導入する。
- 検出ルールを重要度別に整理する。
- 既存アラートを棚卸しする。
- 新規PRで増えた重大アラートをブロック対象にする。
- 既存アラートはバックログ化する。
- AI修正案を試験的に使う。
- 修正成功率、レビュー時間、再発率を測る。
- 自動修正可能なパターンを標準化する。
7.4 セキュリティレビュー用プロンプト
あなたはセキュリティレビュー担当です。
以下のコード差分について、脆弱性リスクを確認してください。
重点観点：
- SQLインジェクション
- XSS
- CSRF
- 認可漏れ
- 認証バイパス
- 機密情報ログ出力
- パストラバーサル
- コマンドインジェクション
- 安全でないデシリアライズ
- 暗号化不足
- ランダム値の不適切利用
- 例外メッセージによる情報漏えい
出力形式：
| No | リスク | 該当箇所 | 攻撃シナリオ | 影響 | 修正案 | 確認方法 |7.5 必須のセキュリティゲート
| ゲート | 内容 |
|---|---|
| SAST | コード上の脆弱性検出 |
| CodeQL | クエリベースの脆弱性検出 |
| Secret scanning | APIキー、パスワード、秘密鍵の混入検出 |
| Dependency scan | 脆弱なライブラリ検出 |
| Container scan | コンテナイメージの脆弱性検出 |
| DAST | 動作中アプリへの攻撃的テスト |
| IaC scan | クラウド・Kubernetes・Terraform設定ミス検出 |
| Human review | 業務仕様、認可、リスク受容の判断 |
Before / After 事例（PoC想定・匿名）
事例D-1：SAST＋AI修正案＋再スキャン
| 項目 | Before | After（3か月） |
|---|---|---|
| High指摘の修正リードタイム | 中央値 4.2日 | 中央値 2.1日 |
| 初回修正案の採用率 | — | 71%（残りは人間修正） |
| 再スキャン未実施でのマージ | 月2件 | 0件（ゲート化） |
| IaC scan指摘（公開SG等） | 検出後平均3日対応 | 検出当日対応率80% |
使ったスキル：第7章セキュリティプロンプト ＋ Checkov/tfsec ＋ Copilot Autofix（参考事例）。インフラIaCは第9章のterraform-best-practicesと併用。
7.6 AI修正案の採用基準
| 確認項目 | 内容 |
|---|---|
| 脆弱性が本当に解消されるか | 再スキャンで確認する |
| 仕様を壊していないか | 既存テスト・回帰テストを通す |
| 過剰な制限になっていないか | 業務影響を確認する |
| ログ・監査要件を満たすか | 運用観点を確認する |
| 似た箇所に横展開が必要か | 同種コードを検索する |
第8章：PM・PL・PMO向け活用
PM/PL/PMOにおけるAI活用は、資料作成の時短だけでは弱い。真に狙うべきは、要件の曖昧さ、WBS漏れ、課題滞留、品質リスク、レビュー滞留、テスト不足の見落とし削減である。
8.1 PM向けAI活用領域
| 領域 | AI活用 | 効果 |
|---|---|---|
| 要件品質 | 曖昧さ、未定義語、受入条件不足を検出 | 手戻り削減 |
| WBS | タスク分解、成果物漏れ確認 | 抜け漏れ削減 |
| 課題管理 | 課題の分類、滞留理由、担当偏りの整理 | 放置防止 |
| 進捗管理 | チケット更新履歴から遅延兆候抽出 | 早期対策 |
| 品質管理 | バグ傾向、工程別流出、再発分類 | 品質会議の精度向上 |
| レビュー管理 | PR滞留、指摘傾向、レビュー負荷分析 | ボトルネック把握 |
| 会議 | 議事録、決定事項、宿題抽出 | 決定事項の漏れ防止 |
| 報告 | 週報、月報、顧客報告草案 | 報告品質の平準化 |
8.2 チケット品質チェック
あなたはPMOです。
以下のチケット内容をレビューし、実行時に手戻りや認識齟齬が起きそうな点を指摘してください。
観点：
1. 目的
2. 完了条件
3. 成果物
4. 影響範囲
5. 担当者が判断に迷う点
6. 依存タスク
7. 顧客確認が必要な点
8. テスト観点
9. リリース時の注意
10. チケット文面の改善案
出力形式：
| No | 指摘 | リスク | 修正案 |8.3 週次品質レビュー
毎週、完了チケット、未完了チケット、遅延チケット、発生障害、レビュー指摘、テスト進捗、未解決課題、仕様変更、顧客確認中事項をAIに渡して、プロジェクト品質レビューのたたき台を作る。
週次品質レビュー用プロンプト
あなたはPMO兼品質管理担当です。
以下のプロジェクト状況から、週次品質レビュー資料のたたき台を作成してください。
出力形式：
1. 総括
2. 進捗状況
3. 品質状況
4. 課題・リスク
5. レビュー滞留
6. テスト消化状況
7. 顧客確認事項
8. 来週の重点アクション
9. PM判断が必要な事項
10. 赤黄緑のステータス判定
注意：
- 事実と推測を分ける
- 根拠となるチケット番号を示す
- 断定できないものは「確認要」とする8.4 PMがAIに任せてはいけないもの
- 最終判断
- 顧客合意
- スコープ変更判断
- リリース可否
- 契約・費用判断
- メンバー評価
Before / After 事例（PoC想定・匿名）
事例M-1：週次品質レビューのたたき台生成
| 項目 | Before | After（8週間） |
|---|---|---|
| 週次品質会議資料作成 | PL 3h/週 | PL 1.5h/週 |
| レビュー滞留の見落とし | 月2回 | 月0回（AI一覧＋PM確認） |
| 顧客確認事項の抜け | 月1件 | 月0件 |
| 議事録→宿題反映漏れ | 週平均1.2件 | 週平均0.3件（議事録スキル併用） |
使ったスキル：第8章週次プロンプト ＋ 社内議事録スキル。判断・ステータス色分けはPMが最終確定。
8.5 PMOダッシュボード化
| 集計対象 | 意味 |
|---|---|
| PR件数 | 開発量 |
| AI利用PR件数 | AI活用定着度 |
| AIセルフレビュー実施率 | 品質ゲート運用状況 |
| レビュー指摘件数 | レビュー品質・事前品質 |
| テストケース増加数 | テスト厚み |
| バグ発生数 | 品質状態 |
| 障害流出数 | 下流品質 |
| 手戻り件数 | 要件・設計品質 |
| セキュリティ指摘件数 | 安全性 |
| 修正リードタイム | 対応速度 |
第9章：ITインフラエンジニア向け活用
インフラ領域では、AIに本番環境を直接操作させるのではなく、構成設計レビュー、設定ファイルレビュー、IaCレビュー、作業手順書レビュー、ログ要約、障害一次切り分けに使うのが安全で効果的である。
9.1 インフラAI活用の目的
| 目的 | 内容 |
|---|---|
| 設定ミス削減 | OS、ミドルウェア、ネットワーク、権限、FW、証明書、監視設定の漏れを減らす |
| 構築手順の標準化 | 人による手順差、手順書の古さ、作業証跡不足を減らす |
| IaC品質向上 | Terraform、Ansible、CloudFormation、Bicep、Kubernetes YAMLなどをレビュー |
| セキュリティ強化 | 不要ポート、過剰権限、暗号化漏れ、公開設定ミス、秘密情報混入を検出 |
| 運用保守の安定化 | ログ調査、アラート要約、障害一次切り分け、暫定対応案作成 |
| 属人化防止 | 熟練者の確認観点をチェックリスト化する |
| 引き継ぎ品質向上 | 構成情報、設定根拠、障害対応履歴を文書化する |
9.2 公開事例
| 事例 | 概要 | 提案への使い方 |
|---|---|---|
| AWS Bedrock + SCP準拠IaC生成 | Service Control Policiesに準拠したIaC生成を支援する考え方。 | 会社のガードレールに沿ったIaC生成・レビューの根拠にする。 |
| Azure SRE Agent | 本番運用の診断・解決支援、MTTR低減を狙うAI-powered reliability assistant。 | AIOps/運用支援の方向性として使う。 |
| HashiCorp Sentinel | Terraform plan/applyにPolicy as Codeを組み込む。 | AI生成IaCの危険変更を止める仕組みとして使う。 |
| Checkov | Terraform、Kubernetes、Dockerfile等をスキャンするIaCセキュリティツール。 | AI生成IaCの機械検査レイヤーとして使う。 |
| AidAI研究 | 過去オンコール経験から障害診断を支援する研究。 | 障害票・運用ログのRAG活用の根拠にする。 |
9.3 インフラエンジニア向け活用マップ
| 業務 | AI活用 | 品質安定化への効果 |
|---|---|---|
| サーバ設計 | 構成レビュー、非機能要件チェック | 可用性・性能・運用漏れの削減 |
| OS設定 | パラメータレビュー、ハードニング確認 | 設定ミス・セキュリティ漏れ削減 |
| ミドルウェア設定 | Apache/Nginx/Tomcat/PostgreSQL等の設定レビュー | 性能・セキュリティ・運用性向上 |
| ネットワーク設定 | ポート、FW、SG、ルーティング確認 | 通信不備・過剰公開の防止 |
| IaC | Terraform/Ansible/YAML生成・レビュー | 再現性・差分管理・レビュー性向上 |
| CI/CD | デプロイ手順、ロールバック手順レビュー | リリース事故防止 |
| 監視 | アラート設計、閾値レビュー | 検知漏れ・過検知の削減 |
| 障害対応 | ログ要約、原因候補、対応案作成 | MTTR短縮 |
| セキュリティ | CIS、脆弱性、秘密情報、権限レビュー | 侵害リスク削減 |
| DR/バックアップ | RPO/RTO、復旧手順レビュー | 復旧不能リスク削減 |
9.4 構築前レビュー
あなたはインフラ設計レビュー担当のシニアエンジニアです。
以下のサーバ構成案をレビューしてください。
観点：
1. 可用性
2. 性能
3. セキュリティ
4. ネットワーク
5. OS設定
6. ミドルウェア設定
7. 認証・認可
8. ログ
9. 監視
10. バックアップ
11. 復旧手順
12. 運用引き継ぎ
13. 構築作業時のリスク
出力形式：
| No | 分類 | 指摘内容 | リスク | 推奨対応 | 確認先 |9.5 サーバ構築手順書作成・レビュー
| 項目 | 内容 |
|---|---|
| 作業目的 | 何のための作業か |
| 前提条件 | OS、権限、接続先、メンテナンス時間 |
| 事前確認 | バックアップ、疎通、空き容量、依存サービス |
| 作業手順 | コマンド、設定ファイル変更 |
| 確認手順 | systemctl、curl、ログ、ポート、画面確認 |
| 切り戻し | 設定戻し、サービス再起動、スナップショット復元 |
| 影響範囲 | 停止するサービス、利用者影響 |
| 証跡 | 実行結果、ログ、スクリーンショット |
| 完了条件 | 何をもって完了とするか |
手順書作成プロンプト
あなたはLinuxサーバ構築手順書の作成担当です。
以下の要件に基づき、作業手順書を作成してください。
必ず含めること：
1. 作業目的
2. 前提条件
3. 事前確認
4. バックアップ取得
5. 作業手順
6. 確認コマンド
7. 正常時の期待結果
8. 異常時の確認箇所
9. 切り戻し手順
10. 作業証跡として残すもの
注意：
- 危険なコマンドは理由と影響を説明する
- rm、chmod 777、firewall無効化などは原則禁止として代替案を示す
- 本番作業前提で、安全側に倒す9.6 設定ファイルレビュー
あなたはサーバ設定レビュー担当です。
以下の設定ファイルをレビューしてください。
重点観点：
- セキュリティ上危険な設定
- 過剰権限
- 不要な公開
- 暗号化不足
- ログ不足
- 性能上の懸念
- 冗長性・可用性の懸念
- 運用時に障害になりやすい設定
- 推奨値から外れている可能性のある設定
出力形式：
| No | パラメータ | 現在値 | 懸念 | 推奨値 | 理由 | 影響 | 変更時の注意 |9.7 AI + IaC 品質ゲート
要件整理
↓
AIでIaC案生成
↓
人間が一次確認
↓
terraform fmt
↓
terraform validate
↓
tflint
↓
checkov / terrascan / tfsec
↓
terraform plan
↓
Policy as Code
↓
レビュー承認
↓
検証環境へapply
↓
疎通・監視・ログ確認
↓
本番反映Terraform生成プロンプト
あなたはTerraformに強いクラウドインフラエンジニアです。
以下の要件を満たすTerraformコードを作成してください。
前提：
- 本番利用を想定
- セキュリティ優先
- 最小権限
- 暗号化有効
- ログ有効
- タグ付け必須
- 破壊的変更を避ける
- 変数化できる値はvariables.tfへ分離
- 出力すべき値はoutputs.tfへ分離
出力：
1. main.tf
2. variables.tf
3. outputs.tf
4. terraform.tfvars.example
5. README
6. セキュリティ上の注意
7. terraform plan前に確認すべき事項IaCレビュー用プロンプト
あなたはIaCレビュー担当です。
以下のTerraformコードをレビューしてください。
観点：
1. 構文・構成
2. 命名規則
3. 最小権限
4. 公開範囲
5. 暗号化
6. ログ
7. バックアップ
8. タグ
9. 破壊的変更リスク
10. コスト増加リスク
11. 運用監視
12. セキュリティスキャンで検出されそうな点
出力形式：
| No | 重要度 | 該当箇所 | 指摘 | リスク | 修正案 |9.8 OS・ミドルウェア確認観点
| 対象 | チェック項目 |
|---|---|
| OS共通 | アカウント、SSH、パッチ、時刻同期、ログ、監査、ファイル権限、不要サービス、FW、ディスク、バックアップ、監視 |
| Webサーバ | TLS、不要メソッド、ディレクトリリスティング、ヘッダ、証明書、ログ、worker、keepalive、timeout |
| DBサーバ | listen範囲、接続元、認証方式、権限、暗号化、バックアップ、リストア、slow query、監査ログ、レプリケーション |
| Windows Server | Administrator、RDP、Firewall、Windows Update、イベントログ、AD/GPO、バックアップ |
9.9 監視・障害対応
あなたはSRE兼インフラ障害対応担当です。
以下のアラート、ログ、メトリクスをもとに、障害の一次切り分けを行ってください。
出力形式：
1. 事象の要約
2. 影響範囲
3. 時系列
4. 原因候補
5. 可能性が高い順のランキング
6. 追加で確認すべきログ・コマンド
7. 暫定対応案
8. 恒久対応案
9. 切り戻し案
10. 顧客・利用者への報告文案
注意：
- ログにないことを断定しない
- 推測は推測と明記する
- 本番影響のある操作は「要承認」と明記する9.10 インフラ向けエージェントスキル（公開・人気）
skills.sh 掲載のインフラ・IaC・クラウド向けスキル。第17章の開発向けスキルと併せて、インフラPoCの「型」として使える。
| スキル | 提供元 | 週次Installs（概算） | リポStars | 主な用途 |
|---|---|---|---|---|
| azure-prepare → azure-validate → azure-deploy | microsoft/azure-skills | 各156K前後 | 1.2K | Azureデプロイ前準備・検証・実行の3段ゲート |
| azure-validate | microsoft/azure-skills | 387K | 1.2K | Bicep/Terraform/CLIのデプロイ前検証、RBAC確認 |
| terraform-best-practices | terramate-io/agent-skills | 203+ | 33 | Terraform 37ルール・10カテゴリのレビュー基準 |
| terramate-best-practices | terramate-io/agent-skills | — | 33 | スタック分割・ドリフト・CI/CD orchestration |
| InsideOut | luthersystems/insideout-agent-skills | — | — | AWS/GCP設計、コスト見積、Terraform生成・ドリフト検知 |
| systematic-debugging | obra/superpowers | 143K | 227K | 障害・ログ調査の根本原因分析（インフラ障害にも転用） |
| supabase-postgres-best-practices | supabase/agent-skills | 231K | 2.2K | DBサーバ設定・SQL・RLSレビュー |
| playwright-best-practices | currents-dev | — | — | 監視付きWeb/APIのE2E・CIパターン |
| VMware-AIops | zw008/VMware-AIops | — | — | vCenter/ESXiの運用支援（要厳格ガバナンス） |
9.10.1 Microsoft Azure Skills — 3段ゲート（詳細）
思想：AIにいきなり terraform apply させない。計画書→検証→デプロイの状態機械。
npx skills add https://github.com/microsoft/azure-skills --skill azure-prepare
npx skills add https://github.com/microsoft/azure-skills --skill azure-validate
npx skills add https://github.com/microsoft/azure-skills --skill azure-deploy| スキル | メリット | デメリット・注意 |
|---|---|---|
| azure-prepare | deployment-plan.md を残し、属人化した「頭の中の構成」を文書化 | Azure/Azure DevOps前提。オンプレのみ案件には不向き |
| azure-validate | Bicep build、Terraform validate、RBAC/IDの事前チェック。第9.7節IaCゲートと整合 | validate通過＝本番安全、ではない。人間承認必須 |
| azure-deploy | エラー回復・デプロイ後検証手順がスキル化されている | 387K installsでも、本番は変更管理・承認とセットでないと危険 |
9.10.2 terramate-io — terraform-best-practices
npx skills add https://github.com/terramate-io/agent-skills --skill terraform-best-practices37ルールを優先度付きで参照。AI生成Terraformの「人間レビュー観点表」として第9.7節のIaCレビュープロンプトと併用する。
| メリット | デメリット・注意 |
|---|---|
| state管理・モジュール設計・セキュリティを体系化 | リポStarsは小さめ（33）。内容はTerramate社保守のルール集 |
| checkov/tfsec指摘の「なぜダメか」説明に使える | マルチクラウドでもAWS/GCP/Azure個別の社内標準は追記要 |
9.10.3 インフラ向けスキル選定（社内提案用）
| 環境 | 最初に試すスキル | 機械チェックとセット |
|---|---|---|
| Azure案件 | azure-validate（prepare/deployment-planとセット） | Bicep build、Policy、Sentinel相当 |
| Terraform全般 | terraform-best-practices | fmt, validate, tflint, checkov, plan |
| Linux/ミドルウェア | 第9章プロンプト（手順書・設定レビュー） | ansible-lint、CIS benchmark手動確認 |
| Kubernetes | 第9.7節＋checkov/conftest | kubectl dry-run, kube-score |
| DB（Postgres） | supabase-postgres-best-practices | EXPLAIN、監視メトリクス |
| 障害対応 | systematic-debugging | ログ保全、変更履歴、ロールバック手順 |
9.11 Before / After 事例（インフラPoC想定）
Before / After
事例I-1：Terraform PRレビュー＋checkov＋AIレビュー
| 項目 | Before | After（3か月PoC終了時） |
|---|---|---|
| 本番反映前の設定ミス指摘 | 月2件（うち1件はロールバック） | 月0件（検証環境で事前検出） |
| checkov High指摘の放置日数 | 中央値 5日 | 中央値 1日 |
| AI指摘採用率（IaC） | — | 58%（公開SG、タグ不足、暗号化漏れ等） |
| planレビュー時間/PR | 45分 | 25分（機械＋AI一次、人間は差分判断） |
使ったスキル：terraform-best-practices ＋ 第9.7節IaCプロンプト ＋ checkov/tflint。
Before / After
事例I-2：サーバ構築手順書のAIレビュー
| 項目 | Before | After（PoC 1〜2か月目で効果、3か月終了時に確定） |
|---|---|---|
| 作業中の手順漏れ（切り戻し・確認） | 四半期3件 | 四半期0件 |
| 手順書レビュー工数 | 上級 2h/件 | 上級 1h/件 |
| 新人作業時の確認質問 | 平均8件/作業 | 平均3件/作業 |
使ったスキル：第9.5節手順書プロンプト。PoC成功後は第9.14の導入用指示を標準化。
Before / After
事例I-3：障害ログの一次切り分け（AI＋systematic-debugging）
| 項目 | Before | After（PoC 3か月目・模擬訓練含む） |
|---|---|---|
| 一次切り分けまでの時間 | 中央値 90分 | 中央値 45分 |
| 原因候補の網羅性（事後評価） | — | 上位3候補に真因含む率 78% |
| 誤った本番操作（暫定対応） | 年1件 | 0件（要承認ルール徹底） |
使ったスキル：第9.9節障害プロンプト ＋ systematic-debugging。AIは「候補」、復旧判断はオンコール担当。
9.12 インフラエンジニア向け：最初の1週間
| 日 | 実施内容 | 成果物 |
|---|---|---|
| 月 | AI利用ガイドライン・禁止事項（第13章）確認。対象は「レビューのみ」に限定 | チーム合意メモ |
| 火 | 直近の構築手順書1件を第9.5プロンプトでレビュー | 指摘一覧、採否記録 |
| 水 | Terraform/Ansible PR 1件に第9.7ゲート＋checkov | scan結果、AIレビュー結果 |
| 木 | 公開スキル1本試用（terraform-best-practices または azure-validate） | 試用所感 |
| 金 | 週次振り返り：有効だった指摘・誤指摘・工数 | PoC週次メモ |
9.13 オンプレ・VMware・Windows向け
| 領域 | AI活用（安全側） | スキル・ツール例 | 禁止・注意 |
|---|---|---|---|
| VMware | 構成図・変更手順のレビュー、ログ要約 | VMware-AIops（要社内承認・読取中心） | 本番vCenter操作の自動実行 |
| Windows Server | GPO/FW/パッチ手順書レビュー | 第9.8節チェックリスト＋社内SKILL | ドメイン管理者権限での自動変更 |
| ネットワーク | FWルール表、変更影響の整理 | 第9.4構築前レビュープロンプト | FW開放の自動判断 |
| バックアップ/DR | RPO/RTO・復旧手順の抜けチェック | 第9.1目的表＋手順書プロンプト | リストア実行の自動化 |
9.14 インフラスキル導入用指示
terraform-best-practices 等と併用。詳細一覧は 第19章。
【PoC担当者への導入指示】
1. npx skills add https://github.com/terramate-io/agent-skills --skill terraform-best-practices
2. 対象：次のIaC PR。checkov/tflint結果とplan要約を添付してレビュー依頼
3. 出力：指摘一覧（重要度・修正案）。採否を変更申請に記録
4. 人間：本番apply・ロールバック判断。第9.15禁止事項を遵守9.15 インフラAI活用の禁止事項
- AIに本番環境を直接変更させる
- 権限付与の自動判断
- FW/SG開放の自動判断
- データ削除
- バックアップ削除
- 証明書・秘密鍵のAI投入
- セキュリティ例外承認
- 障害原因の断定
第10章：標準プロンプト集
本章は、各章に散らばるプロンプトを運用しやすいように再整理したものである。社内利用時は、機密情報や顧客情報を投入しないよう、利用ルールに合わせて調整すること。
10.1 要件レビュー
あなたは要件定義レビュー担当の上級SEです。
以下の要件定義文について、後工程で手戻りになりそうな点をレビューしてください。
レビュー観点：曖昧表現、主語不足、条件不足、例外不足、権限不足、非機能不足、受入条件不足、テスト可能性。
出力形式：| No | 該当箇所 | 問題点 | リスク | 修正案 | 確認先 |10.2 設計レビュー
あなたは基幹システム開発の設計レビュー担当です。
以下の設計書をレビューし、後続工程で問題になりそうな点を抽出してください。
重点観点：要件対応漏れ、業務ルール矛盾、入力チェック、エラー処理、DB更新、トランザクション、排他、権限、ログ、再実行性、テスト観点。10.3 コードレビュー
あなたは厳しめのコードレビュアーです。
以下の差分をレビューしてください。
観点：仕様不一致、Null、例外、トランザクション、DB整合性、権限、ログ、性能、保守性、テスト不足、セキュリティ、命名。
出力形式：| No | 重要度 | 指摘内容 | 該当箇所 | 理由 | 修正案 |10.4 テスト観点生成
あなたは業務システムのQAリードです。
以下の仕様に対して、正常系、異常系、境界値、権限、排他、DB更新、ログ、再実行、大量件数、外部IFエラー、過去障害再発防止の観点でテストケースを作成してください。10.5 PMO週次レビュー
あなたはPMO兼品質管理担当です。
以下のプロジェクト状況から、週次品質レビュー資料のたたき台を作成してください。
出力：総括、進捗、品質、課題、リスク、レビュー滞留、テスト消化、顧客確認事項、来週アクション、PM判断事項。10.6 インフラ作業レビュー
あなたは本番インフラ変更作業のレビュー担当です。
以下の作業手順をレビューしてください。
観点：目的、前提、バックアップ、影響範囲、停止有無、作業順序、確認手順、切り戻し、作業時間、承認、監視抑止、利用者通知。10.7 障害一次切り分け
あなたはSRE兼インフラ障害対応担当です。
以下のアラート、ログ、メトリクスをもとに、事象要約、影響範囲、時系列、原因候補、追加確認コマンド、暫定対応、恒久対応、切り戻し、報告文案を作成してください。第11章：導入ロードマップ・PoC計画
AI導入は、いきなり全工程へ展開せず、まずは小規模PoCで品質が本当に安定するかを確認する。最初はレビュー補助とテスト観点生成から始めるのが安全である。
11.1 フェーズ構成
| フェーズ | 目的 | 主な作業 |
|---|---|---|
| フェーズ0：準備 | ルール・対象・指標を決める | 対象案件選定、AI利用ルール、標準プロンプト作成 |
| フェーズ1：AIセルフレビュー | 人間レビュー前の品質を上げる | 設計書・コード・テスト仕様・手順書のAIレビュー |
| フェーズ2：テスト生成 | テスト品質を厚くする | 単体テスト、テスト観点、回帰候補生成 |
| フェーズ3：PRレビュー | レビュー負荷を下げる | AI一次レビュー、PRテンプレート運用 |
| フェーズ4：セキュリティ修正支援 | 脆弱性対応を速くする | SAST/CodeQL結果の説明、AI修正案、再スキャン |
| フェーズ5：PMOダッシュボード化 | プロジェクト管理へ接続する | 品質指標、課題、レビュー滞留、リスク集計 |
11.2 3か月PoC案
| 期間 | 実施内容 |
|---|---|
| 1か月目 | 対象案件選定、AI利用ルール作成、標準プロンプト作成、設計書レビュー・コードレビューで試行、初回効果測定 |
| 2か月目 | 単体テスト生成、テスト観点生成、PR前AIセルフレビュー必須化、指摘傾向集計 |
| 3か月目 | セキュリティスキャン連携検討、AI利用ログと品質指標整理、標準手順書化、PoC結果報告 |
11.2b PoC対象の絞り込み
PoCは「AIで何でも効率化する」ではなく、効果とリスクを測れるテーマに絞る。まずは3テーマ程度を主対象にし、他テーマは参考観察に留める。
| 区分 | 候補 | 採用理由 | 測るもの |
|---|---|---|---|
| 主PoC | PR前セルフレビュー / TDD支援 | 品質指標と開発フローに接続しやすい | レビュー時間、指摘採用率、手戻り件数 |
| 主PoC | 要件・設計レビュー | 受託開発の上流品質に効く | 曖昧語、未決事項、意味逸脱、レビュー指摘密度 |
| 主PoC | インフラ手順書 / IaCレビュー | 事故予防とチェック自動化の相性がよい | 設定ミス、High指摘放置日数、手順漏れ |
| 参考観察 | PMO週次、勤怠照合、エンゲージメント文案 | 効果はあるが業務・人事影響の整理が必要 | 作業時間、差戻し率、利用者負担、誤判定 |
11.3 インフラPoC案（第9章 9.11と数値整合）
本節のKPIは 第9章 9.11 事例I-1〜I-3と同一のBefore/After定義。PoCは3か月固定。開始前2週間でベースライン計測し、終了時に第11.5テンプレへ転記する。
11.3.1 月次スケジュールと到達目標
| 月 | 実施内容 | 到達目標（第9章事例） |
|---|---|---|
| 1か月目 | サーバ構築手順書・設定ファイルのAIレビュー、指摘採否記録、ベースライン確定 | 事例I-2：手順書レビュー工数 2h→1h/件へ改善開始。手順漏れ四半期3件→向かう |
| 2か月目 | Terraform/Ansibleレビュー、checkov/tflint/ansible-lint、plan要約、terraform-best-practices試用 | 事例I-1：checkov High放置 中央値5日→2日以下。planレビュー 45分→30分以下 |
| 3か月目 | 過去障害票要約、ログ解析演習、systematic-debugging、標準運用化判断 | 事例I-1完了：設定ミス本番前 月2→0、plan 25分。I-3：一次切り分け 90分→45分、上位3候補78% |
11.3.2 KPI一覧（ベースライン → PoC終了目標）
| 指標 | Before（ベースライン） | After（3か月PoC目標） | 対応事例 |
|---|---|---|---|
| 本番反映前の設定ミス | 月2件（うちロールバック1） | 月0件 | I-1 |
| checkov High指摘の放置日数 | 中央値 5日 | 中央値 1日 | I-1 |
| AI指摘採用率（IaC） | — | 58% | I-1 |
| planレビュー時間/PR | 45分 | 25分 | I-1 |
| 作業手順漏れ（切り戻し・確認） | 四半期3件 | 四半期0件 | I-2 |
| 手順書レビュー工数 | 上級 2h/件 | 上級 1h/件 | I-2 |
| 新人作業時の確認質問 | 平均 8件/作業 | 平均 3件/作業 | I-2 |
| 障害一次切り分け時間 | 中央値 90分 | 中央値 45分 | I-3 |
| 原因候補Top3に真因 | — | 78%（事後評価） | I-3 |
| 誤った本番操作（暫定対応） | 年1件 | 0件（PoC期間） | I-3 |
11.3.3 インフラPoC完了条件（追加分）
- 上表のうち、最低5指標でBefore/Afterが記録されている。
- I-1系：checkov/tflint等のスキャンがPRゲートに組み込まれている。
- I-2系：手順書AIレビューの採否ログが10件以上ある。
- I-3系：障害切り分け模擬を1回以上実施し、ログ・候補・承認記録が残っている。
- 第9章9.15の禁止事項違反がない。
11.4 PoC完了条件
- 対象成果物に対してAIセルフレビューが実施されている。
- AI指摘の採否が記録されている。
- テスト観点または単体テストが増えている。
- レビュー指摘や手戻りの傾向が集計されている。
- メンバーの負荷・不安・使いにくさが把握されている。
- 継続利用ルールが作成されている。
11.4b PoC中止・縮小条件
効果が出ないテーマを続けると、AI利用そのものへの信頼を落とす。次の条件に該当した場合は、対象縮小、手順見直し、または停止を判断する。
| 条件 | 判断 | 対応 |
|---|---|---|
| AI指摘採用率が2週間連続で20%未満 | テーマまたはプロンプト不適合 | 対象文書を限定し、採用基準を再定義する |
| レビュー時間が短縮せず、確認負荷だけ増える | 費用対効果不足 | 利用場面をPR前セルフチェックなどに限定する |
| 誤指摘や誤修正により手戻りが増える | 品質悪化リスク | AI出力の直接反映を禁止し、人間レビューを強化する |
| 機密情報・個人情報の投入制御ができない | ガバナンス不成立 | 当該テーマを停止し、データ分類ルールを先に整備する |
| KPIの母数・測定方法が記録されない | 評価不能 | 第19章の測定定義に合わせてログ取得を必須化する |
11.5 PoC結果報告テンプレート
# AI品質安定化PoC結果報告
## 1. 目的
AIを利用し、設計・実装・レビュー・テスト・インフラ運用における品質安定化効果を検証する。
## 2. 対象
- 対象案件：
- 対象工程：
- 対象メンバー：
- 使用AI：
- 対象成果物：
## 3. 実施内容
- 設計書AIレビュー
- コードAIセルフレビュー
- 単体テスト生成
- テスト観点生成
- PRテンプレート運用
- インフラ手順書レビュー
- IaCレビュー
- ログ要約
## 4. 定量結果
| 指標 | 導入前 | 導入後 | 変化 |
|---|---:|---:|---:|
| 実装工数 | | | |
| レビュー指摘件数 | | | |
| 手戻り件数 | | | |
| テストケース数 | | | |
| バグ件数 | | | |
| レビュー待ち時間 | | | |
| 設定ミス件数 | 月2 | 月0 | -2 |
| checkov High放置日数（中央値） | 5日 | 1日 | -4日 |
| planレビュー時間/PR | 45分 | 25分 | -20分 |
| 手順書レビュー工数 | 2h/件 | 1h/件 | -1h |
| 障害一次切り分け（中央値） | 90分 | 45分 | -45分 |
## 5. 定性結果
- 良かった点
- 困った点
- AIが有効だった作業
- AIが不向きだった作業
- メンバーの反応11.6 事務・勤怠照合PoC案（第18章と整合）
| 月 | 実施内容 | 到達目標 |
|---|---|---|
| 1か月目 | 18.2マップから優先業務2つ選定（推奨：勤怠照合＋電話取次層1）、xlsx/pdf導入、マスキングルール | ベースライン計測 |
| 2か月目 | 勤怠照合の締め前運用、phone-intake-assistant試行、経費 or 議事録を1業務追加 | A-1：差戻し月8→3、PH-1：伝言不備週5→1 |
全業務マップ・スキル一覧：第18章
11.7 エンゲージメント施策PoC案（モチベーションクラウド等連動）
| 期間 | 実施内容 | 到達目標 |
|---|---|---|
| サーベイ直後2週間 | 期待度×満足度マトリクスから優先課題をAI整理、施策案3〜5件を言葉選びレビュー付きで起草 | 管理職が選定した施策2件以上を現場へ説明可能 |
| パルス1サイクル（2〜4週） | 施策実施＋AI文案（称賛・依頼・周知）のA/B言い回し比較、パルス前後比較 | 事例E-1：「取り組みやすさ」自己評価 +0.3pt以上（5段階） |
AIは施策の最終決定・人事評価・個人名の公開は行わない。第18章 18.13・18.11参照。
第12章：評価指標・KPI
AI導入の評価では、生産性だけを見ると危険である。品質が悪化しているのに作業速度だけ上がるケースがあるため、生産性・品質・組織・インフラ運用の4軸で見る。
12.1 生産性指標
| 指標 | 内容 | 注意点 |
|---|---|---|
| 実装工数 | AI利用前後で比較 | 難易度差を補正する |
| 設計書作成時間 | 章単位で比較 | レビュー時間も含める |
| テストケース作成時間 | AI生成前後で比較 | 採否判断時間も含める |
| PR作成数 | 変化を見る | 数だけで品質判断しない |
| レビュー待ち時間 | AIセルフレビューで短縮するか | レビュアー不足との切り分けが必要 |
| セキュリティ修正時間 | Autofix系導入前後で比較 | 再スキャン合格までを見る |
12.2 品質指標
| 指標 | 内容 |
|---|---|
| レビュー指摘件数 | PR前セルフレビューで減るか |
| 重要指摘件数 | 設計・仕様レベルの重大指摘 |
| バグ発生件数 | 工程別に見る |
| 流出バグ件数 | 本番・受入で出たバグ |
| 手戻り件数 | 要件・設計起因 |
| 回帰バグ件数 | 既存機能破壊 |
| テスト観点数 | 異常系・境界値が増えたか |
| カバレッジ | 単体・分岐・条件 |
| セキュリティアラート | 新規発生・解消数 |
12.3 組織指標
| 指標 | 内容 |
|---|---|
| AI利用率 | 使われているか |
| AI指摘採用率 | 有効な指摘が出ているか |
| 利用満足度 | 開発者体験 |
| 属人タスク数 | 特定者依存が減ったか |
| ナレッジ登録数 | 再利用可能な知識が増えたか |
| 新人立ち上がり期間 | 教育効果 |
12.4 インフラ指標
| 指標 | 内容 |
|---|---|
| 手順書レビュー指摘数 | AIがどれだけ漏れを検出したか |
| 有効指摘率 | 人間が有効と判断した割合 |
| 設定ミス件数 | 構築後・レビュー後のミス数 |
| 作業手戻り件数 | 作業中断・やり直しの件数 |
| IaCスキャン指摘数 | checkov/tflint等の指摘 |
| planレビュー時間 | Terraform plan確認時間 |
| 障害一次切り分け時間 | アラートから原因候補整理まで |
| MTTR | 平均復旧時間 |
| 運用引き継ぎ時間 | 新担当者が理解するまでの時間 |
| ドキュメント更新率 | 手順書・構成図・運用FAQの鮮度 |
12.5 事務・エンゲージメント指標
| 指標 | 内容 | 第9/11/18章との対応 |
|---|---|---|
| 勤怠照合の差戻し件数 | 締め後に発覚した不整合 | 18章 A-1：月8→3 |
| 照合工数 | 事務担当の月次時間 | 18章 A-1：6h→2.5h |
| AI不整合検出の採用率 | 有効と判断した割合 | 18章 A-1：72% |
| 施策文案作成時間 | 管理職・人事の工数 | 18章 E-1：4h→1.5h |
| 「参加したい」自己評価 | パルス前後（5段階等） | 18章 E-1：+0.3 |
| 周知文のネガティブ自由記述率 | 義務感・反感の有無 | 18章 E-1：42%→24% |
| 電話取次・伝言不備 | 折返し・聞き漏れ | 18章 PH-1：週5→1 |
| 経費差戻し率 | 規程抵触・不備 | 18章 X-1：18%→7% |
12.6 推奨ダッシュボード
| カテゴリ | 表示項目 |
|---|---|
| AI利用 | AI利用PR数、AIセルフレビュー実施率、プロンプト利用回数 |
| レビュー | レビュー待ち時間、指摘件数、重要指摘率、再レビュー回数 |
| テスト | テストケース数、カバレッジ、失敗率、回帰テスト実施率 |
| 品質 | バグ件数、工程別流出、再発件数、手戻り件数 |
| セキュリティ | アラート数、修正時間、再スキャン合格率 |
| インフラ | 設定ミス、作業手戻り、障害切り分け時間、MTTR |
| 事務・人事 | 勤怠差戻し、照合工数、施策文案時間、パルス改善度 |
AI活用後にPR件数が増えても、レビュー指摘、手戻り、流出バグが増えているなら成功ではない。逆に、短期的にレビュー指摘が増えるのは、今まで見逃していた問題が可視化されている可能性もある。
第13章：リスク・ガバナンス・禁止事項
AI活用で最も危険なのは、AIの出力を正解として扱うこと。社内展開では、利用ルール、証跡、責任範囲、禁止事項を明確化する必要がある。
13.1 AIで品質が落ちる典型パターン
| パターン | 起きる問題 | 対策 |
|---|---|---|
| AI出力を鵜呑み | 仕様不一致、潜在バグ | 人間レビュー必須 |
| テストなしでマージ | 回帰バグ | CI必須 |
| 設計なしでコード生成 | 保守不能 | 実装前レビュー |
| セキュリティをAI任せ | 脆弱性見逃し | SAST/CodeQL必須 |
| 個人ごとに使い方が違う | 品質ばらつき | 標準プロンプト |
| 証跡がない | 後から検証不能 | PRに記録 |
| 生産性だけ測る | 品質悪化を見逃す | 品質指標も測る |
| インフラ本番操作をAIに任せる | 設定事故、停止、情報漏えい | 人間承認と検証環境必須 |
13.2 AI利用ルール
| 項目 | ルール |
|---|---|
| 機密情報 | 顧客名、個人情報、認証情報は投入禁止 |
| ソースコード | 契約・社内方針に従う |
| 設計書 | 機密度に応じて投入可否を判断 |
| AI出力 | 必ず人間が確認 |
| 証跡 | PR、課題、レビュー記録に残す |
| 成果物責任 | AIではなく担当者が負う |
| セキュリティ | AI修正後もスキャン必須 |
| テスト | AI生成コードはテスト必須 |
| インフラ作業 | 本番作業は承認・切り戻し手順必須 |
13.2b データ分類別AI利用可否
| 分類 | 例 | AI投入 | 条件 |
|---|---|---|---|
| Public | 公開資料、公開OSS情報 | 可 | 出典と確認日を残す |
| Internal | 社内手順、一般的な設計方針 | 条件付き可 | 社内許可済み環境を使う |
| Confidential | 顧客名、契約、非公開設計、障害情報 | 原則不可 | 必要時は匿名化・マスキング・承認を必須にする |
| Personal / HR | 勤怠、評価、意識調査、個人コメント | 原則不可 | 集計・匿名化し、個人評価には使わない |
| Secrets | 鍵、トークン、証明書、接続情報 | 禁止 | 検出時は即削除・ローテーションを検討する |
13.2c RACI / 承認マトリクス
| 対象 | R: 実行 | A: 承認責任 | C: 相談 | I: 共有 |
|---|---|---|---|---|
| PoCテーマ選定 | PoC担当 | 部門責任者 | 現場リーダー、品質担当 | 参加メンバー |
| AI利用ルール | 品質/セキュリティ担当 | 部門責任者 | 法務・情報システム | 利用者 |
| 公開スキル採用 | 技術リード | PoC責任者 | セキュリティ担当 | 利用チーム |
| 本番反映・顧客提出 | 担当者 | 案件責任者 | レビューア、顧客窓口 | 関係者 |
13.2d 公開スキル採用前チェック
- READMEだけでなく、実行される指示ファイルとスクリプトを確認する。
- 外部送信、ファイル削除、認証情報参照、ネットワークアクセスの有無を確認する。
- ライセンス、更新頻度、メンテナ、依存ツールを記録する。
- StarsやInstallsは人気の参考値に留め、品質保証の根拠にしない。
- PoCではバージョンまたはコミットを固定し、戻し方を決めてから使う。
13.3 禁止事項
- 顧客機密、個人情報、認証情報、秘密鍵、接続文字列をAIへ投入する。
- AI生成コードを理解せずにマージする。
- AI生成テストの期待値を確認せず採用する。
- AIレビューだけでセキュリティOKと判断する。
- AIに本番サーバやクラウドリソースを直接変更させる。
- AIにリリース可否、顧客合意、契約判断を任せる。
- AI出力を根拠なく確認済みとして扱う。
13.4 AI利用証跡
- AI利用有無
- AIを使った範囲
- AI出力に対して人間が確認した内容
- AI出力を採用しなかった理由
- テスト・レビュー・スキャン結果
AIが生成したコード、設計案、テストケース、手順書であっても、成果物責任は担当者とレビュー承認者にある。AIは責任主体にならない。
13.5 インフラ特有のリスク
| リスク | 例 | 対策 |
|---|---|---|
| 本番停止 | 誤ったsystemctl、FW設定、LB設定 | 検証環境、作業手順レビュー、切り戻し |
| 情報漏えい | 秘密鍵、証明書、接続情報の投入 | マスキング、投入禁止、ローカル処理 |
| 過剰権限 | IAM、sudo、DB権限の過剰付与 | 最小権限レビュー、Policy as Code |
| 公開範囲ミス | 0.0.0.0/0、不要ポート公開 | IaC scan、Security Groupレビュー |
| 復旧不能 | バックアップ未取得、リストア未検証 | 作業前バックアップ、復旧訓練 |
第14章：運用テンプレート
AI品質安定化を運用に落とすには、テンプレート化が重要である。ここでは、PRテンプレート、インフラ変更申請、PoC報告テンプレートをまとめる。
14.1 PRテンプレート
## 概要
このPRで対応した内容を記載する。
## 関連チケット
- #xxxx
## 変更内容
-
## 影響範囲
- 画面：
- API：
- DB：
- バッチ：
- 帳票：
- 外部IF：
## AI利用
- なし / あり
### AIを利用した内容
- 仕様要約
- 実装案比較
- コード生成
- テスト生成
- セルフレビュー
- その他：
## AI出力に対して人間が確認した内容
- [ ] 仕様との整合
- [ ] 既存処理への影響
- [ ] 例外処理
- [ ] 権限・認可
- [ ] セキュリティ
- [ ] 単体テスト
- [ ] 回帰影響
- [ ] ログ・運用
## テスト結果
- [ ] 単体テスト
- [ ] 結合テスト
- [ ] 回帰テスト
- [ ] 手動確認
## レビュアーに見てほしい点
-14.2 インフラ変更申請テンプレート
## 変更概要
- 対象環境：
- 対象サーバ / リソース：
- 変更目的：
## 変更内容
-
## 影響範囲
- 利用者影響：
- 停止有無：
- 関連システム：
- 通信影響：
- 監視影響：
## AI利用
- なし / あり
### AIを利用した範囲
- [ ] 手順書作成
- [ ] 設定レビュー
- [ ] IaC生成
- [ ] IaCレビュー
- [ ] ログ調査
- [ ] 障害原因候補整理
- [ ] 報告書作成
## 人間が確認した内容
- [ ] 設定値
- [ ] 権限
- [ ] FW / SG
- [ ] バックアップ
- [ ] 切り戻し手順
- [ ] 監視
- [ ] セキュリティ
- [ ] コスト
- [ ] terraform plan / dry-run
- [ ] 検証環境での確認
## 事前確認
- [ ] バックアップ取得
- [ ] スナップショット取得
- [ ] 空き容量確認
- [ ] 接続確認
- [ ] 監視抑止確認
- [ ] 関係者通知
## 作業手順
1.
2.
## 確認手順
1.
2.
## 切り戻し手順
1.
2.
## 完了条件
-14.3 AI利用チェックシート
| 確認項目 | チェック |
|---|---|
| AI利用範囲を明記したか | □ |
| 機密情報を投入していないか | □ |
| AI出力を人間が確認したか | □ |
| テスト・スキャンを実行したか | □ |
| AI指摘の採否を記録したか | □ |
| リスクがある変更は承認を得たか | □ |
| 切り戻し手順を用意したか | □ |
| 作業証跡を残したか | □ |
第15章：自社適用案
自社適用では、最初からAI開発基盤を大きく作るより、既存プロセスへAIレビューとAIテスト観点を差し込む方が現実的である。
15.1 最初に狙うべきテーマ
| 優先度 | テーマ | 理由 |
|---|---|---|
| 第1優先 | 設計書・コードのセルフレビュー | 導入リスクが低く、既存フローに追加しやすい |
| 第2優先 | テスト観点生成 | 抜け漏れ削減に直結し、成果物として残せる |
| 第3優先 | PRテンプレートとAI利用証跡 | 監査性が上がり、レビューしやすい |
| 第4優先 | セキュリティスキャン＋AI修正案 | 数値効果を出しやすく、DevSecOpsに接続できる |
| 第5優先 | インフラ手順書・IaCレビュー | 設定ミスや作業ミスの削減に直結する |
| 第6優先 | エージェントスキル整備 | プロンプトの属人化を減らし、公開スキル＋社内ゲートをGit管理（第17章） |
| 第7優先 | 勤怠・作業実績の事前照合 | 客先常駐の二重フォーマットは機械チェック向き（第18章） |
| 第8優先 | エンゲージメント施策文案 | モチベーションクラウド等のサーベイ後、能動性を促す言い回し（第18章） |
15.1b スキル導入の優先順位
| 段階 | 公開スキル（例） | 社内スキル（例） |
|---|---|---|
| PoC初期 | requesting-code-review（superpowers） | PRテンプレ＋AI利用証跡 |
| PoC中期 | test-driven-development、systematic-debugging | 要件定義ゲート（SE向け） |
| 展開期 | webapp-testing、DBベストプラクティス | 意味逸脱監査、議事録・資料可読化 |
| インフラPoC | terraform-best-practices または azure-validate | infra-change-review（手順書・IaC・第9章） |
| 事務PoC | xlsx, pdf, docx, copywriting | 勤怠・電話・経費の導入用指示（第19章 / 第18章） |
| 人事PoC | summarize-meeting（任意） | engagement-initiative-drafter 導入用指示（第18章） |
詳細なメリット・デメリット・インストール数・導入用指示：第19章 / 第17章
15.2 社内標準運用案
| 対象 | 標準運用 |
|---|---|
| プログラマ | チケット要約、実装案比較、単体テスト生成、AIセルフレビュー、PRにAI利用範囲を記録 |
| SE | 要件・設計書を章単位でAIレビューし、顧客確認事項と内部修正事項に分離 |
| QA | 仕様書からAIでテスト観点を生成し、過去障害観点を加えて人間が採否判断 |
| PM/PL | 週次で課題・進捗・品質・レビュー滞留をAIに整理させ、判断はPMが行う |
| DevSecOps | SAST/CodeQL/Secret scanとAI修正案を組み合わせ、再スキャンを必須化 |
| インフラ | 構成設計、設定ファイル、IaC、手順書、障害ログをAIレビューし、本番変更は人間承認 |
15.3 導入時の教育内容
- AIは正解ではなく候補を出す道具である。
- AI利用時の機密情報ルール。
- AI生成コード・手順書のレビュー方法。
- 標準プロンプトの使い方。
- PR・作業申請へのAI利用証跡の残し方。
- AI出力の採否判断の考え方。
- セキュリティ・インフラでの禁止事項。
15.4 まず作るべき社内資産
| 資産 | 内容 |
|---|---|
| AI利用ガイドライン | 利用範囲、禁止事項、責任範囲 |
| 標準プロンプト集 | 要件、設計、コード、テスト、インフラ、PMO |
| PRテンプレート | AI利用範囲、確認内容、テスト結果 |
| 変更申請テンプレート | インフラ作業、切り戻し、AI利用証跡 |
| レビュー観点表 | 職種別、成果物別のチェックリスト |
| PoC評価表 | 定量・定性評価項目 |
| 過去障害ナレッジ | 再発防止プロンプトに使う |
| 承認済みスキル一覧 | 公開スキル＋社内スキルの採用版、配置パス、更新手順（第17章） |
15.5 展開判断基準
| 判定 | 基準 |
|---|---|
| 継続 | AI指摘の有効率が高く、レビュー指摘や手戻りに改善傾向がある |
| 限定継続 | 効果のある工程だけ残し、低効果な用途をやめる |
| 改善後再試行 | プロンプト・運用・教育不足が原因なら改善して再試行 |
| 中止 | 機密リスク、品質悪化、現場負荷増が大きい場合 |
AI活用を社内施策として通すなら、「AIで開発を自動化する」ではなく「AIで品質確認の抜け漏れを減らす」と表現した方が現場に通りやすい。
第16章：参考文献・調査ソース
本章では、調査時に参照した公開情報、公式ドキュメント、事例、研究資料を一覧化する。社内資料化する際は、必要に応じて各リンクの閲覧日、要約、社内適用観点を追記するとよい。
16.0 参考文献の読み方・ファクトチェック
本資料では、公開情報を提案仮説の裏付けとして扱う。数値、Stars、Installs、リポジトリ構成、ベンダー事例は変化するため、提案時点の確認日を残し、導入判断時に再確認する。
| 区分 | 使い方 | 確認観点 | 更新リスク |
|---|---|---|---|
| 一次情報・公式資料 | 制度、機能、調査結果の根拠 | 公開日、版、調査対象、定義 | 中 |
| ベンダー事例 | 導入効果の参考 | 対象規模、前提条件、宣伝要素 | 中 |
| 研究・調査レポート | 傾向や仮説の補強 | 調査期間、母集団、相関と因果の区別 | 中 |
| GitHub / コミュニティ | スキル候補探索 | 最終更新、ライセンス、実装内容、Issue状況 | 高 |
16.1 参考文献一覧
- DORA 2025 report
https://dora.dev/dora-report-2025/ - Google Blog: DORA Report 2025 overview
https://blog.google/innovation-and-ai/technology/developers-tools/dora-report-2025/ - Google Cloud Blog: 2024 DORA report
https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report - DORA AI-assisted software development report 2025
https://cloud.google.com/resources/content/2025-dora-ai-assisted-software-development-report - GitHub Customer Story: Mercedes-Benz
https://github.com/customer-stories/mercedes-benz - GitHub Customer Story: Duolingo
https://github.com/customer-stories/duolingo - GitHub Blog: Accenture Copilot enterprise research
https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-in-the-enterprise-with-accenture/ - NEC Solution Innovators: 生成AIを活用したソフトウェア開発検証
https://www.nec-solutioninnovators.co.jp/company/blog/2024/24/index.html - NEC Technical Journal: 生成AIを活用したソフトウェア開発の取り組み
https://jpn.nec.com/techrep/journal/g23/n02/230209.html - Diffblue Cover case study
https://www.diffblue.com/case-studies/transforming-sdlc-with-ai-diffblue-covers-impact-on-unit-test-automation/ - arXiv: AI-Assisted Unit Test Generation and Safe Refactoring
https://arxiv.org/abs/2604.03135 - Fujitsu Research: テスト仕様書生成
https://blog.fltech.dev/entry/2025/10/29/testspecgen-ja - Meta Engineering: Sapienz intelligent automated software testing at scale
https://engineering.fb.com/2018/05/02/developer-tools/sapienz-intelligent-automated-software-testing-at-scale/ - arXiv: Rich test users / Sapienz extension
https://arxiv.org/html/2403.15374v1 - arXiv: GenIA-E2ETest
https://arxiv.org/abs/2510.01024 - GitHub Changelog: Copilot code review generally available
https://github.blog/changelog/2025-04-04-copilot-code-review-now-generally-available/ - GitHub Docs: Using Copilot code review
https://docs.github.com/copilot/using-github-copilot/code-review/using-copilot-code-review - PR Times: NEC AIコードレビューサービス Metabob
https://prtimes.jp/main/html/rd/p/000001214.000078149.html - arXiv: Copilot code review security evaluation
https://arxiv.org/abs/2509.13650 - GitHub Docs: Responsible use of security and quality AI features
https://docs.github.com/en/code-security/responsible-use/security-and-quality-ai-features - GitHub Blog: Secure code faster with Copilot Autofix
https://github.blog/news-insights/product-news/secure-code-more-than-three-times-faster-with-copilot-autofix/ - arXiv: Security issues in AI-generated code
https://arxiv.org/abs/2510.26103 - arXiv: Evaluating Epic quality with LLMs
https://arxiv.org/abs/2505.07664 - arXiv: Generating functional specifications with LLMs
https://arxiv.org/abs/2505.18019 - AWS Blog: Generative AI for proactive SCP-compliant IaC generation
https://aws.amazon.com/blogs/infrastructure-and-automation/using-generative-ai-for-proactive-iac-code-generation-thats-compliant-with-service-control-policies-using-amazon-bedrock/ - Microsoft TechCommunity: Introducing Azure SRE Agent
https://techcommunity.microsoft.com/blog/azurepaasblog/introducing-azure-sre-agent/4414569 - Azure Blog: Agentic DevOps with GitHub Copilot and Azure
https://azure.microsoft.com/en-us/blog/agentic-devops-evolving-software-development-with-github-copilot-and-microsoft-azure/ - HashiCorp Sentinel
https://www.hashicorp.com/en/sentinel - Checkov GitHub repository
https://github.com/bridgecrewio/checkov - Prisma Cloud Infrastructure as Code Security
https://www.paloaltonetworks.com/prisma/cloud/infrastructure-as-code-security - arXiv: IaC security study
https://arxiv.org/abs/2308.03952 - arXiv: AidAI for incident diagnosis
https://arxiv.org/abs/2506.01481 - arXiv: AIOps agent risks
https://arxiv.org/abs/2508.06394 - arXiv: AI coding assistants risks
https://arxiv.org/abs/2604.08352 - Agent Skills 標準（agentskills.io）
https://agentskills.io - skills.sh — スキルディレクトリ・リーダーボード
https://skills.sh - Cursor Docs: Agent Skills
https://cursor.com/docs/skills - GitHub: obra/superpowers
https://github.com/obra/superpowers - GitHub: anthropics/skills
https://github.com/anthropics/skills - GitHub: addyosmani/agent-skills
https://github.com/addyosmani/agent-skills - GitHub: vercel-labs/skills（skills CLI）
https://github.com/vercel-labs/skills - GitHub: supabase/agent-skills
https://github.com/supabase/agent-skills - GitHub: microsoft/azure-skills
https://github.com/microsoft/azure-skills - GitHub: terramate-io/agent-skills
https://github.com/terramate-io/agent-skills - GitHub: luthersystems/insideout-agent-skills
https://github.com/luthersystems/insideout-agent-skills - モチベーションクラウド（公式）
https://www.motivation-cloud.com/ - GitHub: anthropics/skills — pptx, doc-coauthoring
https://github.com/anthropics/skills - VoltAgent/awesome-agent-skills
https://github.com/VoltAgent/awesome-agent-skills - phuryn/pm-skills — summarize-meeting
https://github.com/phuryn/pm-skills - coreyhaines31/marketingskills — copywriting
https://github.com/coreyhaines31/marketingskills - AIsmiley: 音声AIコールセンター変革ガイド（2026）
https://aismiley.co.jp/ai_news/voice-ai-call-center-dx-guide/ - セゾンPSP: コールセンターAI活用
https://corporate.saison-psp.co.jp/hrd/blog/callcenter/c_23/
第17章：エージェントスキル活用
第10章のプロンプトは「その場の指示」、エージェントスキルは「Git管理する手順書パッケージ」。本資料ではSKILL.md本体の作成までは扱わず、導入用指示（1行）と試用判断までを記載する。一覧・メリデメの正本は 第19章 総評・一覧シート。
公開スキルの扱い: 人気順では採用しない。第19章をマスタとし、第13章のデータ分類・公開スキル採用前チェックを通過したものだけPoCで試用する。
17.1 プロンプト vs スキル
| 観点 | 都度プロンプト | エージェントスキル（SKILL.md） |
|---|---|---|
| 再現性 | 担当者・セッションでばらつく | 同じ手順・観点表・出力形式をチームで共有 |
| 版管理 | チャット履歴に埋もれる | Git PRでレビュー・差分追跡可能 |
| コンテキスト効率 | 長い指示を毎回貼る | メタデータのみ常時ロード、必要時に全文展開（Progressive Disclosure） |
| 自動起動 | 毎回明示が必要 | タスク内容に応じてエージェントが関連スキルを選択可能 |
| 向かない用途 | — | 1行の簡単な指示、機密ルールの常時全件注入（Rules向き） |
17.2 公開エコシステム：主要リポジトリ
| リポジトリ | GitHub Stars（概算） | 特徴 | 品質安定化での位置づけ |
|---|---|---|---|
| obra/superpowers | 約22.7万 | TDD・コードレビュー・デバッグ・計画実行の方法論スキル群 | 実装・レビュー工程の「型」を強制する代表例 |
| anthropics/skills | 約15.0万 | 公式サンプル。Webテスト、ドキュメント、MCP生成等 | テスト自動化・成果物レビューの参照実装 |
| addyosmani/agent-skills | 約5.9万 | 本番品質向け24スキル（TDD、セキュリティ、増分実装等） | エンジニアリング実務に近いワークフロー |
| vercel-labs/skills | 約2.2万 | skills.sh CLI、スキル発見・インストール基盤 | 社内標準スキルの配布・更新に使える |
| supabase/agent-skills | 約2.2千（リポ） | Postgres性能・RLS等のDBベストプラクティス | DB設計レビュー・性能指摘の補助 |
17.3 品質安定化向け：人気スキル一覧（skills.sh）
週次インストール数が多く、品質・テスト・レビュー・設計に直結するスキルを選定した。
| スキル名 | 提供元 | 週次Installs（概算） | リポStars（概算） | 主な用途 | 導入用指示（1行） |
|---|---|---|---|---|---|
| systematic-debugging | obra/superpowers | 143K | 227K | 根本原因調査→仮説→修正の4段階デバッグ | 再現環境＋ログを投入。3回失敗で設計見直し。本番は復旧優先を別途明文化 |
| requesting-code-review | obra/superpowers | 128K | 227K | サブエージェントによるコードレビュー、重大度分類 | PRテンプレにAI利用欄追加。Critical/Important採否を記録。第6章R-1と連動 |
| test-driven-development | obra/superpowers | 127K | 227K | Red-Green-Refactor、テスト先行の強制 | 保守チケット1件に限定。失敗テスト先行→人間採否。第3章P-1 KPI計測 |
| supabase-postgres-best-practices | supabase/agent-skills | 231K | 2.2K | SQL・索引・RLS・性能のルール集 | 設計書1章＋DDLを投入。EXPLAINは人間確認。Oracle/SQL Serverは別ルール |
| webapp-testing | anthropics/skills | 95K | 150K | PlaywrightによるWebアプリテスト手順 | 中機能1件でE2E下書き→QA採否→CI追加可否を判断。第5章Q-1と併用 |
| verification-before-completion | obra/superpowers | （superpowers内） | 227K | 「完了」宣言前の検証ゲート | lint/test/手動確認を一覧化してから完了報告。最終「完了」は人間が宣言 |
| vercel-react-best-practices | vercel-labs | 301K | 25K | React性能・再レンダー・バンドル最適化69ルール | 性能チケット1件に適用。Lighthouse等の計測結果とセットで採否 |
| skill-creator | anthropics/skills | （高ランク） | 150K | 社内標準スキルの作成・テスト | PoC成功したプロンプト1本のみSKILL化候補に。第17章B系と併用 |
| test-driven-development | addyosmani/agent-skills | 5K | 59K | TDD＋ブラウザ検証連携、Prove-Itパターン | superpowers TDDと二重試用せず、Web＋ブラウザ検証案件で1本だけ試用 |
17.4 事例A：公開スキル詳細（メリット・デメリット）
A-1. obra/superpowers — test-driven-development
概要：実装前に失敗するテストを書き、失敗を確認してから最小実装。テストなしで書いたコードは削除させる設計。
インストール：
npx skills add https://github.com/obra/superpowers --skill test-driven-development導入用指示：保守チケット1件に限定。実装前に失敗テスト→人間採否。第3章P-1 KPI計測。
| メリット | デメリット・注意点 |
|---|---|
| AIの「動きそう」実装をテストで縛れる | レガシーでテストが無いコードには初期コスト大 |
| バグ修正時も再現テスト先行（Prove-It） | 手順が厳格で、小さなUI変更でもオーバーヘッド感 |
| チーム全体でTDD文化をエージェント経由で統一 | 英語ベースの指示。社内用語はスキル改変が必要 |
| 127K installs、コミュニティ実績が豊富 | 「強制」設計のため、PoC初期は反発があり得る |
社内提案での言い方：「AIにコードを書かせる」ではなく「AIにテスト観点と失敗確認をさせ、人間が採否する」。
A-2. obra/superpowers — requesting-code-review
概要：タスク間・マージ前にコードレビューサブエージェントを起動。Critical / Important / Minor で指摘を分類。
npx skills add https://github.com/obra/superpowers --skill requesting-code-review導入用指示：PRテンプレにAI利用欄を追加し、Critical/Importantの採否を記録。第6章R-1指標と連動。
| メリット | デメリット・注意点 |
|---|---|
| 人間レビュー前の一次品質が上がる（第6章と整合） | 業務仕様・ドメイン判断は人間必須 |
| 128K installs、PRレビュー文化と相性良い | サブエージェント利用はトークン・時間コスト増 |
| 計画書との整合チェックが可能 | 社内セキュリティでサブエージェントが制限される場合あり |
A-3. obra/superpowers — systematic-debugging
概要：症状パッチ禁止。証拠収集→パターン分析→仮説検証→修正の4段階。3回失敗で設計見直しを促す。
npx skills add https://github.com/obra/superpowers --skill systematic-debugging導入用指示：再現環境＋ログを投入。3回失敗で設計見直し。緊急本番は復旧優先を別途明文化。
| メリット | デメリット・注意点 |
|---|---|
| 143K installs、障害・バグ調査の属人化を減らす | 緊急本番障害では「まず復旧」優先の判断が別途必要 |
| 再発防止のテストケース追加まで含む設計 | ログ・再現環境が無いと効果半減 |
| AIの早とちり修正を抑止 | 手順が長く、軽微なtypo修正には過剰 |
A-4. anthropics/skills — webapp-testing
概要：Python PlaywrightでローカルWebアプリをテスト。サーバ起動ヘルパー、DOM reconnaissance→操作の2段階。
npx skills add https://github.com/anthropics/skills --skill webapp-testing導入用指示：中機能1件でE2E下書き→QA採否→CI追加可否を判断。第5章Q-1と併用。
| メリット | デメリット・注意点 |
|---|---|
| 95K installs、E2E観点の具体化に使える（第5章） | Python/Playwright前提。Java/.NETのみ案件は別スキル検討 |
| 公式実装でメンテ期待できる | 生成スクリプトは人間レビュー・CI組込必須 |
| 動的SPA向けにnetworkidle待機を明示 | 社内テスト基盤（Selenium等）との二重管理リスク |
A-5. supabase/agent-skills — supabase-postgres-best-practices
概要：Postgresのクエリ・索引・RLS・スキーマ設計を8カテゴリ・優先度付きルールでレビュー。
npx skills add https://github.com/supabase/agent-skills --skill supabase-postgres-best-practices導入用指示：設計書1章＋DDLを投入。性能はEXPLAINを人間確認。Oracle/SQL Server案件は別ルール。
| メリット | デメリット・注意点 |
|---|---|
| 231K installs、DB設計レビューの観点表として使える | Supabase/Postgres特化。Oracle/SQL Serverは別途 |
| 誤SQL vs 正SQLの対比例が豊富 | 基幹DBの社内命名規約はカスタム追記が必要 |
| SEのDB設計書AIレビュー（第4章）と接続しやすい | 性能数値は環境依存。EXPLAINは人間確認 |
A-6. addyosmani/agent-skills — パック全体
概要：24スキル構成。incremental-implementation、spec-driven-development、security-and-input-hardening等。本番品質向けの「ライフサイクル」設計。
npx skills add https://github.com/addyosmani/agent-skills --skill incremental-implementation
npx skills add https://github.com/addyosmani/agent-skills --skill test-driven-development導入用指示：PoCは2本に絞る（例：incremental-implementation＋TDD）。新機能1本をスライス分割し各スライスでレビュー・テスト完了をゲート化。
| メリット | デメリット・注意点 |
|---|---|
| 59K repo stars、エンジニア向け評判が高い | スキル数が多く、PoCは2〜3本に絞るべき |
| 増分実装・セキュリティ境界が明文化 | 主にWeb/JS寄り。COBOL/レガシーは要カスタム |
| superpowersより「実装の切り方」に重点 | 日本語案件資料との用語ギャップ |
17.5 事例B：社内PoC向けスキル（受託開発・品質ゲート）
以下は実プロジェクトで運用中のスキルパターンを匿名化した事例。公開スキルと併用すると、「業界標準の型＋社内固有のゲート」が両立する。
B-1. 要件定義ゲートスキル（社内PoC）
| 項目 | 内容 |
|---|---|
| 向く工程 | 要件定義レビュー、見積前、基本設計着手前 |
| できること | 曖昧語・未決・BLOCKER抽出、顧客確認事項と内部修正の分離、MODE-A〜Dで成熟度別レビュー |
| メリット | 第4章プロンプトを標準化。出力形式が固定され、ゲート判定が可能 |
| デメリット | 合意索引・用語集が無いと推測リスク。人間のGO/NO-GOは必須 |
| 公開スキルとの差 | 汎用TDD/レビュー系は「コード向き」。本スキルは「要件・契約・見積境界」向き |
| 導入用指示 | 要件1章をMODE-Bでレビュー。顧客確認事項と内部修正を分離記録。第4章S-1 KPI |
B-2. 意味逸脱監査スキル（社内PoC）
| 項目 | 内容 |
|---|---|
| 向く工程 | 議事録→要件反映後、要件改訂前後、AI要約文の検証 |
| できること | 版間で主張強度・責任主体・条件・スコープの変化を検出 |
| メリット | AI要約で「勝手に確定」「条件消失」を防ぐ（第13章リスク対策） |
| デメリット | 比較元・先の2版以上が必要。初回セットアップに学習コスト |
| 併用 | 要件定義ゲートスキルとセットで「横断＋版間」の二層レビュー |
| 導入用指示 | 旧版＋新版を投入。主張強度・責任主体・スコープ差分を一覧→人間判定 |
B-3. 議事録・ドキュメント可読化スキル（社内PoC）
| 項目 | 内容 |
|---|---|
| 向く工程 | PM/PL、ドキュメント管理、客先資料変換 |
| できること | 議事録下ごしらえ、Markdown同期、資料の可読化パイプライン |
| メリット | 属人化した議事録・資料整形を再現可能に |
| デメリット | スクリプト・パス依存。環境差分の説明と機密マスキングルールが必要 |
| 導入用指示 | 1会議分でPREP→FINALIZE試行。客先資料は変換ルール＋マスク確認 |
17.6 スキル選定マトリクス（社内提案用）
| 優先課題 | まず試す公開スキル | 社内で足すスキル | 測る指標 |
|---|---|---|---|
| 実装バグ・手戻り | test-driven-development（superpowers） | — | 単体テスト数、バグ件数、手戻り |
| PRレビュー負荷 | requesting-code-review | PRテンプレ＋AI利用証跡 | レビュー指摘件数、レビュー時間 |
| 障害・バグ調査 | systematic-debugging | 過去障害ナレッジ参照 | 再発件数、調査時間 |
| 要件・設計の抜け | —（汎用スキルは弱い） | 要件定義ゲート、意味逸脱監査 | 顧客確認件数、設計手戻り |
| DB設計品質 | supabase-postgres-best-practices | 社内DB命名・監査ルール追記 | 性能指摘、本番障害 |
| E2E・画面テスト | webapp-testing | テスト観点生成プロンプト（第10章） | テストケース数、漏れ指摘 |
| IaC・Terraform | terraform-best-practices、azure-validate | infra-change-review（第9.14） | checkov指摘、planレビュー時間、設定ミス |
| インフラ障害切り分け | systematic-debugging | 第9.9障害プロンプト、過去障害票 | 一次切り分け時間、MTTR |
17.7 導入パターンとガバナンス
配置場所
| スコープ | パス例 | 用途 |
|---|---|---|
| プロジェクト | .agents/skills/ または .cursor/skills/ | 案件固有の要件ゲート、用語、テスト観点 |
| 個人 | ~/.codex/skills/ 等 | PoC個人試行（本番展開前） |
| 組織 | 社内Git＋npx skills add org/repo | 承認済みスキルのみ配布 |
社内ルール（第13章と整合）
- 公開スキルはそのまま本番利用しない。セキュリティ監査（skills.shの監査結果）と社内レビュー後に採用。
- スキル内スクリプト実行は、ネットワーク・ファイルアクセス権限を確認する。
- 機密・個人情報を含む案件は、スキルに渡す資料範囲をガイドライン化。
- 効果測定（第12章）が取れないスキルは限定継続または中止。
注意：インストール数が多い＝社内そのまま安全、ではない。特に動画生成・ブラウザ自動操作系は品質PoCの対象外とし、まずレビュー・テスト・デバッグ系から始める。
17.8 PoCでの試用順（推奨）
- Week 1-2：第10章プロンプトでセルフレビュー試行（スキルなしでも可）
- Week 3-4：
requesting-code-reviewまたは社内PRレビュー手順をスキル化 - Month 2：
test-driven-developmentを1機能に限定試用 - Month 2-3：要件・設計案件で社内ゲートスキルを試用
- Month 3：指標比較、継続スキル一覧を第15章に反映
17.9 インフラエンジニア向けスキル（詳細）
第9章と対になるスキル選定。開発向け（17.3〜17.4）と併記して提案資料に載せる。
| スキル | Installs | Stars | メリット | デメリット | 導入用指示（1行） |
|---|---|---|---|---|---|
| azure-validate | 387K | 1.2K | デプロイ前検証の手順固定、deployment-plan連携 | Azure特化。計画書なしでは起動しない設計 | 非本番のみ。deployment-plan作成→validate通過までdeploy禁止 |
| azure-deploy | 388K | 1.2K | validate後のみ実行、エラー回復手順あり | 本番自動デプロイは変更管理とセット必須 | validate通過＋人間承認後に非本番deploy。本番は変更管理フロー |
| terraform-best-practices | 203+ | 33 | 37ルールでIaCレビュー観点を標準化 | Stars少。Terramate視点のルール | IaC PR1件＋checkov/tflint必須。planレビュー時間を記録（I-1 KPI） |
| InsideOut | — | — | 設計対話・コスト見積・ドリフト検知 | クラウド中心。オンプレは第9章プロンプト主体 | クラウド設計1件を対話レビュー。コスト・ドリフト判断は人間 |
| systematic-debugging | 143K | 227K | 障害切り分けの型。ログ調査に転用 | 緊急復旧優先時は手順短縮要 | 第9章9.9プロンプトと併用。模擬障害1回（I-3 KPI） |
| supabase-postgres-best-practices | 231K | 2.2K | DB設定・SQLレビュー | Postgres特化 | DB設計・SQLレビュー1件。性能数値は環境依存、人間確認 |
インフラスキルは「監査官・レビュアー」として使う。VMware-AIops等の操作系スキルは、読取・下書きに限定し、本番変更は人間承認＋既存変更管理に従う（第9.15節）。
インフラBefore/After事例・1週間スターター：第9章 9.11〜9.12（KPIは 第11章 11.3.2 と同一）
17.10 事務・エンゲージメント向けスキル
詳細・業務マップ・電話取次：第18章。以下は提案用サマリー。
| スキル | Installs | 用途 | メリット | 注意 | 導入用指示（1行） |
|---|---|---|---|---|---|
| xlsx（anthropics） | 110K | 勤怠・経費・台帳 | 式エラー検出、テンプレ維持 | 機密は閉域 | マスク済CSV×Excelで第18.4照合。給与判断・客先自動送信禁止 |
| pdf / docx | 134K / 125K | 契約・稟議・請求書 | 抽出・編集の標準実装 | 法判断不可 | テンプレ1種。抽出結果は人間確認。外部送信前に必須チェック |
| copywriting | — | 社内周知 | トーン統一 | 禁句は社内ルールで | 経費・周知文案。禁句表（18.11）でセルフチェック後に人間確定 |
| summarize-meeting | — | 議事録構造化 | 決定・宿題抽出 | 内容は人間確認 | 会議後トランスクリプト→決定/宿題/未決分離。顧客向けは必ず編集 |
| attendance-worklog-reconciliation | 社内 | 自社×客先照合 | 締め前不整合検出 | マスク必須 | xlsx導入＋第18.4プロンプト。A-1 KPI（差戻し・照合工数） |
| phone-intake-assistant | 社内 | 電話取次メモ | 聞き漏れ・文案 | 自動発信禁止 | 第18.5.3指示を標準手順に。層1から。PH-1 KPI |
| engagement-initiative-drafter | 社内 | 意識調査施策 | 能動性を促す言い回し | 人事が最終決定 | 匿名サーベイサマリー→施策3案→禁句チェック→1案を人間確定。E-1 KPI |
公開スキルは「優れた個人技の結晶」。詳細一覧は 第19章。
第18章：事務・エンゲージメント向け活用
本章は事務・総務・人事支援・受付・現場管理向け。エンジニア向けの「品質安定化」と同じ原則：AIは決裁者ではなく、提出前チェックの副操縦士。機械的にルール化できる作業ほど効果が出やすい。
18.1 なぜ「品質安定化」に含めるのか
| 領域 | 品質（正確性）の意味 | AIが効きやすい理由 |
|---|---|---|
| 勤怠・作業実績 | 自社と客先フォーマットの一致 | ルール照合・表計算 |
| 電話取次 | 聞き漏れ・伝言ミス・振分け誤りの削減 | チェックリスト・要約・文案 |
| メール・文書 | 敬語、宛先、添付、定型抜け | テンプレ＋レビュー |
| 経費・購買 | 規程抵触、領収書不備、勘定科目 | 規程表との突合 |
| 契約・押印 | 必須条項、期限、差戻し理由 | チェックリストレビュー |
| 議事録・会議 | 決定事項・宿題・期限の漏れ | 構造化抽出 |
| 社内周知 | 読みやすさ、誤解、トーン | 文案比較・禁句チェック |
| エンゲージメント | 能動性を促す施策設計 | 言い回し・複数案 |
18.2 事務作業マップ（AI活用一覧）
受託SI・客先常駐を想定した事務全般のマップ。◯=効果出やすい、△=人間判断必須、×=原則AI単独不可。
| 業務 | 典型タスク | AI活用 | 公開スキル例 | 人間必須 |
|---|---|---|---|---|
| 電話・受付 | 取次・伝言メモ | ◯ 聞き取り項目の漏れチェック、伝言文案 | 社内 phone-intake-assistant | 発信・約束・機密回答 |
| 問合せ分類・振分け | ◯ 一次分類案、担当候補、緊急度 | — | 最終振分け | |
| 営業時間外・IVR補助 | △ FAQ文案、エスカレーション条件設計 | プラットフォーム（Cognigy等） | 本番ボット設定承認 | |
| メール | 返信下書き・敬語 | ◯ トーン別文案、宛名・CC確認 | copywriting, gws-gmail | 送信ボタン |
| 問合せ仕分け | ◯ カテゴリ・優先度・転送先案 | agent-email-inbox（Resend） | 個人情報含む対応 | |
| 文書・帳票 | Word/PDF/Excel作成・修正 | ◯ 体裁統一、式エラー検出 | docx, pdf, xlsx, pptx | 対外送付 |
| 押印・稟議添付 | ◯ 不足書類チェック | 押印・決裁 | ||
| ファイリング・命名 | ◯ 命名規則・版番号チェック | — | 正本保管 | |
| 勤怠・実績 | 自社×客先Excel照合 | ◯ 不整合一覧 | xlsx + attendance-worklog-reconciliation | 承認・差戻し |
| 締め・集計 | ◯ 集計表下書き、異常値フラグ | xlsx | 締め確定 | |
| 経費・購買 | 経費精算チェック | ◯ 規程抵触、日付・金額・科目 | xlsx + 社内規程SKILL | 承認 |
| 見積・発注照合 | ◯ 数量・単価・納期の表突合 | xlsx, pdf | 発注実行 | |
| 契約・法務 | 契約書レビュー補助 | △ 必須条項・日付・当事者 | docx, pdf | 法務判断 |
| 会議・議事録 | 議事録構造化 | ◯ 決定・宿題・期限抽出 | summarize-meeting, meeting-intelligence | 内容確認 |
| 会議招集・資料 | ◯ アジェンダ・事前配布リスト | notion-meeting-intelligence | 招待送信 | |
| スケジュール | 調整文案・候補日 | ◯ 文案、重複指摘 | gws-calendar | 確定連絡 |
| 訪問者・入館 | 受付台帳・当日リスト | ◯ 必須項目・NDA確認リスト | xlsx | 入館許可 |
| 総務・備品 | 備品申請・在庫 | ◯ 在庫閾値、申請書不備 | xlsx | 支給判断 |
| 社内周知 | お知らせ・掲示 | ◯ 読みやすさ、禁句、日付 | copywriting, docx | 公開 |
| 人事・意識調査 | 施策文案 | ◯ 能動性を促す言い回し | engagement-initiative-drafter | 施策決定 |
18.3 人気公開スキル（事務・オフィス向け）
| スキル | 提供元 | Installs（概算） | Stars | 事務での用途 |
|---|---|---|---|---|
| xlsx | anthropics/skills | 110K | 150K | 勤怠・経費・台帳、式エラー検出 |
| anthropics/skills | 134K | 150K | 請求書・契約PDFの抽出・結合 | |
| docx | anthropics/skills | 125K | 150K | 稟議・通知Word、変更履歴 |
| pptx | anthropics/skills | — | 150K | 社内説明資料 |
| doc-coauthoring | anthropics/skills | — | 150K | 共同編集・レビューサイクル |
| copywriting | coreyhaines31/marketingskills | — | — | 社内周知・お知らせ文案 |
| email-sequence | coreyhaines31/marketingskills | — | — | リマインドメール系列 |
| gws-gmail / gws-calendar | googleworkspace | — | — | Workspace連携（要OAuth） |
| meeting-intelligence | makenotion/skills | — | — | 会議準備・アジェンダ |
| summarize-meeting | phuryn/pm-skills | — | — | 議事録構造化 |
| agent-email-inbox | resend/resend-skills | — | — | 受信仕分け（要API） |
| find-skills | vercel-labs | 950K+ | — | 不足スキルの発見・インストール |
anthropics/skills の docx/pdf/xlsx/pptx は skills.sh 上で事務系の de facto 標準。VoltAgent/awesome-agent-skills（25K+ stars）でも公式ドキュメントスキルとして最上位に分類されている。
18.3.1 ドキュメントスキル — メリット・デメリット（提案用）
| スキル | メリット | デメリット・注意 |
|---|---|---|
| xlsx | 式の再計算・#REF!等エラー検出、テンプレ体裁維持 | マクロ付きxlsmは人間確認。機密表は閉域のみ |
| 請求書・契約のテーブル抽出、OCR | スキャン品質依存。法的解釈は不可 | |
| docx | トラック変更・コメント付き編集 | 複雑な社内テンプレは references で固定 |
| copywriting | 周知文のトーン統一 | マーケ向け。社内禁句は別途チェック |
npx skills add https://github.com/anthropics/skills --skill xlsx
npx skills add https://github.com/anthropics/skills --skill pdf
npx skills add https://github.com/anthropics/skills --skill docx18.4 客先常駐：勤怠・作業実績の二重フォーマット照合
自社勤怠システム × 客先Excel/独自フォーマットの突合。詳細は従来どおり。
| 観点 | 例 | AI自動 |
|---|---|---|
| 日付欠落・重複 | 片方のみ存在 | ◎ |
| 工数不一致 | 8h vs 6h | ◎ |
| コード不一致 | PJコード写し間違い | ◎ |
| 必須項目漏れ | 客先Excel未入力 | ◎ |
あなたは事務局の勤怠・作業実績チェック担当です。
【自社勤怠】と【客先作業実績】を突合し、承認前の不整合を一覧化してください。
（観点：日付・工数・コード・休暇・必須項目・備考矛盾・締日境界）
個人名は出さずID/イニシャルのみ。給与・評価判断は行わない。呼び出し名（将来SKILL化する場合）：attendance-worklog-reconciliation
導入用指示
【PoC担当者へ】
1. npx skills add https://github.com/anthropics/skills --skill xlsx（Excel照合に使用）
2. 自社勤怠CSVと客先Excelをマスクして投入。第18.4節プロンプトで照合
3. 不整合一覧の採否を記録。承認・差戻しは事務担当
4. 禁止：マスクなし外部AI、給与判断、客先への自動送信Before / After A-1
客先常駐・月次勤怠照合（2か月PoC）
| 項目 | Before | After |
|---|---|---|
| 締め後差戻し | 月8件 | 月3件 |
| 照合工数 | 6h/月 | 2.5h/月 |
| AI検出採用率 | — | 72% |
18.5 電話取次・受付・コミュニケーション
2026年時点、電話AIは音声ボットプラットフォーム（NiCE Cognigy、各社IVR+LLM等）とエージェントスキル（人間受付の補助）に分かれる。受託SIの事務部門では、まず人間＋AIチェックから始めるのが安全。
18.5.1 3層モデル（提案の言い方）
| 層 | 内容 | 適用例 | リスク |
|---|---|---|---|
| 層1：受付支援 | 通話後要約、伝言文案、聞き漏れチェック | 全社内線・客先代表 | 低 |
| 層2：一次自動応答 | 営業時間外FAQ、折り返し受付 | 定型的な問合せのみ | 中（誤応答） |
| 層3：自律エージェント | CRM/基幹連携まで自動 | コールセンター・大規模 | 高（要専門設計） |
参考：音声AIは「音声認識→ボイスボット→応対支援AI→自律エージェント」と段階導入が推奨される（AIsmiley等の業界ガイド）。セゾンPSP等の事例では、文字起こし・要約・定型回答から始め、オペレーターの後処理時間削減で効果が出ている。
18.5.2 層1向けプロンプト：電話取次メモレビュー
あなたは受付・総務の品質チェック担当です。
以下の【電話取次メモ】をレビューし、伝言・取次として不備がないか確認してください。
チェック観点：
1. 発信者（会社名・氏名・連絡先）の記載
2. 用件の要旨（何について・いつまでに）
3. 受付日時・担当者名
4. 折り返し希望時間帯
5. 緊急度（至急/通常/時間指定）
6. 伝言先（部署・担当者）の明確さ
7. 機密・個人情報の取扱い注意
8. 約束しすぎていないか（「必ず今日中に」等）
出力：
| No | 分類 | 指摘 | 重要度 | 追記すべき項目 | 伝言文案（修正案） |
注意：相手への返答内容の最終決定は人間が行う。18.5.3 電話取次：導入用指示
【PoC担当者へ】
1. スキルインストールは不要。第18.5.2プロンプトを標準手順に登録
2. 通話後メモまたは文字起こし（個人情報最小化）を入力しレビュー依頼
3. 出力：聞き漏れ指摘・伝言文案。受付担当が修正後に伝言
4. 禁止：AIによる折返し約束の自動確定、録音の無断外部アップロードBefore / After PH-1
代表電話の取次品質（層1・4週間PoC）
| 項目 | Before | After |
|---|---|---|
| 伝言不備による折返し | 週5件 | 週1件 |
| 取次メモ作成時間 | 平均4分/件 | 平均2.5分/件 |
| 聞き漏れ指摘（事後） | 月12件 | 月4件 |
18.6 メール・文書処理
18.6.1 メール返信下書き
あなたはビジネスメールの下書き担当です。
【受信メール】【返信方針】【社内トーン規定】に基づき返信案を3パターン作成してください。
A: 丁寧・標準 B: 簡潔 C: お詫び・調整が必要な場合
必ず確認：宛先/CC、件名、添付要否、日付・期限、敬語レベル、禁句（18.11参照）18.6.2 対外文書・押印前チェック
あなたは総務の文書レビュー担当です。
以下の【送付予定文書】について、提出前チェックを行ってください。
観点：宛名・日付・件名・署名欄・添付一覧・押印欄・版数・機密区分・誤字・数値の桁18.7 議事録・会議・スケジュール
あなたは議事録整理担当です。以下の文字起こしから構造化してください。
1. 決定事項（誰が・何を・いつまでに）
2. 宿題（担当・期限・成果物）
3. 保留・エスカレーション
4. 次回予定
5. 読み取れない/推測部分は【要確認】と明記公開スキル：summarize-meeting（phuryn/pm-skills）、meeting-intelligence（Notion連携時）。社内議事録Excel運用がある場合は第17章の tum-minutes-generator パターンと併用可。
18.8 経費・購買・契約
| 業務 | AIチェック内容 | スキル |
|---|---|---|
| 経費精算 | 領収書日付、金額上限、交通経路、科目、接待規程 | xlsx + 社内 expense-policy-check |
| 購買申請 | 見積3社、単価×数量、納期、承認欄 | xlsx, pdf |
| 契約書 | 当事者、期間、自動更新、解約、準拠法、押印欄 | pdf, docx |
あなたは経費精算レビュー担当です。
【申請データ】と【経費規程】を突合し、規程抵触・不備を一覧化してください。
給与・評価には触れず、承認可否は人間が判断する。Before / After X-1
経費精算の事前チェック（1.5か月）
| 項目 | Before | After |
|---|---|---|
| 差戻し率 | 18% | 7% |
| 事務確認時間/件 | 8分 | 4分 |
18.9 総務・訪問者・社内周知
- 訪問者管理：入館申請の必須項目（来訪者・被訪者・時間・目的・NDA）チェック
- 備品申請：在庫表と申請数の突合
- 社内掲示・メール：copywriting + 禁句表で「命令調」「個人名」排除
18.10 事務向け共通運用ルール
| 項目 | ルール |
|---|---|
| データ | 個人名・客先名・電話録音はマスク or 閉域AI |
| 権限 | 送信・承認・差戻し・入館許可は人間のみ |
| 証跡 | AI指摘一覧と採否を業務フォルダに保存 |
| スキル | 社内Gitの .agents/skills/ に事務系を配置しPRレビュー |
人事・エンゲージメント領域の注意: AIは文案整理、集計、論点抽出の補助に限定する。個人評価、監視、懲戒判断、個人コメントの直接分析には使わない。利用目的を従業員に説明し、集計・匿名化・人間の最終判断を前提にする。
18.11 モチベーションクラウド・意識調査・言葉選び
モチベーションクラウド：期待度×満足度、パルスサーベイ、アクション管理。AIはたたき台と禁句フィルタに限定。
| 避ける | 推奨 |
|---|---|
| 「遅れている」「未達成」 | 「次の2週間で試せること」 |
| 「全員必ず実施」 | 「希望者から pilot」 |
| 「問題社員」 | 「声が届きにくかった領域」 |
| 「サーベイ結果が悪い」 | 「期待が高い領域」 |
あなたは組織開発に詳しい人事の伴走アドバイザーです。
【サーベイ結果サマリー】（匿名・部署単位）から、能動的に取り組める施策案を3つ提案してください。
各案：施策名、対象、2週間以内の第一歩、ボトムアップ要素、パルス指標、告知文案A/B/C、禁句、管理職の一言。
命令口調・個人名批判・全員強制案は禁止。最終決定は人事・管理職。呼び出し名（将来SKILL化する場合）：engagement-initiative-drafter
導入用指示
【人事・管理職PoC担当へ】
1. サーベイ結果サマリー（匿名）のみ投入。第18.11節プロンプトで施策3案生成
2. 禁句表（18.11）でセルフチェック。告知文案A/B/Cから1案を人間が編集確定
3. モチベーションクラウド等への掲載は人間が実施
4. 禁止：個人名文案、評価・配置のAI判断18.12 事務向け推奨セット（導入順）
| 優先 | 公開スキル | 導入指示の所在 | 対象業務 |
|---|---|---|---|
| 1 | xlsx, pdf | 第19章 スキル一覧 / 18.4 | 勤怠・台帳 |
| 2 | docx | 第19章 / 18.6 | メール・文書 |
| 3 | copywriting | 第19章 | 経費・周知 |
| 4 | summarize-meeting | 第19章 / 18.7 | 議事録・人事 |
18.13 ガバナンス・禁止事項
- 個人特定データ・録音の外部AI無断投入
- AIによる承認・差戻し・給与・評価の自動決定
- 電話での約束・契約内容のAI単独確定
- 音声ボットの本番投入をスキル未レビュー・テストなしで実施
- サーベイ生データの個人名文案生成
18.14 最初の2週間（事務・人事）
| 日 | 事務全般 | 人事 |
|---|---|---|
| 1-3 | 業務マップ（18.2）から優先2業務選定、xlsx/pdfインストール | NGワード合意 |
| 4-7 | 勤怠照合 or 電話メモレビューを試行 | 施策文案3案 |
| 8-10 | 経費 or 議事録を追加試行 | 禁句チェック |
| 11-14 | PoC記録、導入用指示を第19章に追記 | パルス周知を人間確定 |
事務AIの成功パターンは「全部自動化」ではなく、締め・送付・承認の直前に機械チェックを挟むこと。電話は層1から、ドキュメントは anthropics 系スキルから始めると説明しやすい。
第19章：総評・一覧シート
本ページは印刷・社内配布用の総合シート。詳細手順・プロンプト全文は各章を参照。
本章をマスタとして扱う。 KPI、スキル採否、導入順、ガバナンス判断は本章を正本にし、各章は詳細説明として参照する。数値・公開リポジトリ情報は提案前に確認日を更新する。
19.0 ファクトチェック・更新管理
| 項目 | 現在の扱い | 更新頻度 | 担当 | 注意 |
|---|---|---|---|---|
| 公開スキルのStars / Installs | 人気・活発度の参考値 | 提案前 | PoC担当 | 品質根拠として単独利用しない |
| DORA等の調査レポート | 背景仮説の補強 | 年次または提案前 | 品質担当 | 年度、調査対象、指標定義を確認する |
| PoC KPI | 導入判断の主根拠 | 週次 | PoC担当 | 母数、除外条件、測定方法を固定する |
| ガバナンスルール | 利用可否の判断基準 | ルール変更時 | 責任者 | 顧客・契約・社内規程と矛盾させない |
19.1 総評
向いているレビュー・テスト・差分影響・設定確認・障害一次切り分け・事務照合など「提出前チェック」。人間が最終承認する副操縦士としての位置づけ。
向いていない完全自動開発、法務・給与・評価の自動判断、本番無承認変更、機密・個人情報の無マスク外部投入、電話の完全自動応答。
成功条件第12章指標＋第13章ガバナンスをセット。効果が測れない用途は中止。公開スキルは監査・改変後に採用。
提案の3本柱（要約）
| 柱 | 内容 | 参照章 |
|---|---|---|
| 柱1：工程内品質ゲート | 設計・実装・テスト・レビュー・インフラ手順の提出前にAIチェック | 第2章、第3〜9章 |
| 柱2：標準プロンプト＋スキル | 都度プロンプトからGit管理スキルへ。導入は指示プロンプトまで（本資料） | 第10章、第17章、本シート19.2 |
| 柱3：測定とガバナンス | KPIで継続判断。禁止事項・マスキング・承認フローを先に定義 | 第12章、第13章、19.4 |
一言で社内説明：「AIで書かせる」より「AIで抜け漏れを減らす」。生成物は必ず人間が採否・承認する。
19.2 スキル一覧マスタ（公開＋社内）
導入コマンドと導入用指示プロンプトのみ記載。SKILL.mdの作成・改変手順はPoC成功後に別途。
19.2.1 開発・品質（公開）
| スキル | 分類 | Installs | 主用途 | メリット | デメリット・注意 | 導入コマンド | 導入用指示（PoC担当者へ） |
|---|---|---|---|---|---|---|---|
| test-driven-development | 開発 | 127K | テスト先行実装 | AIの動きそう実装をテストで縛れる | レガシー初期コスト、手順が厳格 | npx skills add https://github.com/obra/superpowers --skill test-driven-development | 保守チケット1件に限定。実装前に失敗テスト→人間採否。第3章P-1 KPI計測。テストなしコードは削除ルールをチーム合意 |
| requesting-code-review | レビュー | 128K | PR前一次レビュー | 人間レビュー前の品質向上 | ドメイン判断は人間必須、トークン増 | npx skills add https://github.com/obra/superpowers --skill requesting-code-review | PRテンプレにAI利用欄追加。Critical/Important採否を記録。第6章R-1指標と連動 |
| systematic-debugging | 障害 | 143K | 根本原因調査 | 症状パッチ抑制、再発テストまで | 緊急復旧時は手順短縮要、ログ必須 | npx skills add https://github.com/obra/superpowers --skill systematic-debugging | 再現環境＋ログを投入。3回失敗で設計見直し。本番は復旧優先を別途明文化 |
| webapp-testing | QA | 95K | Playwright E2E | E2E下書き、公式メンテ | Python前提、CI組込は人間 | npx skills add https://github.com/anthropics/skills --skill webapp-testing | 中機能1件でE2E下書き→QA採否→CI追加可否判断。第5章Q-1と併用 |
| supabase-postgres-best-practices | DB | 231K | SQL・RLSレビュー | 誤SQL対比例、設計観点表 | Postgres特化、社内命名は追記要 | npx skills add https://github.com/supabase/agent-skills --skill supabase-postgres-best-practices | 設計書1章＋DDLを投入。性能はEXPLAIN人間確認。Oracle/SQL Server案件は別ルール |
| incremental-implementation | 開発 | — | 増分実装 | 本番品質の切り方が明文化 | スキル多、PoCは2〜3本に絞る | npx skills add https://github.com/addyosmani/agent-skills --skill incremental-implementation | 新機能1本をスライス分割。各スライスでレビュー・テスト完了をゲート化 |
| vercel-react-best-practices | フロント | 301K | React性能69ルール | 再レンダー・バンドル観点 | React/Next特化 | skills.shで vercel-labs から選択 | 性能チケット1件に適用。計測結果（Lighthouse等）とセットで採否 |
| skill-creator | 運用 | 高 | 社内スキル作成 | 標準スキルのテスト・配布 | 最初から全工程SKILL化は不要 | npx skills add https://github.com/anthropics/skills --skill skill-creator | PoC成功したプロンプト1本のみSKILL化候補に。第17章B系と併用 |
19.2.2 インフラ（公開）
| スキル | Installs | 主用途 | メリット | デメリット | 導入用指示 |
|---|---|---|---|---|---|
| terraform-best-practices | 203+ | IaCレビュー | 37ルールで観点標準化 | Stars少、Terramate視点 | IaC PR1件＋checkov/tflint必須。planレビュー時間記録（I-1）。本番applyは変更管理 |
| azure-validate / azure-deploy | 387K/388K | Azureデプロイ前後 | validate→deploy順序固定 | Azure特化、計画書必須 | 非本番環境のみPoC。deployment-plan作成→validate通過→人間承認→deploy |
| systematic-debugging | 143K | 障害切り分け | ログ調査の型 | 緊急時は短縮 | 第9章9.9プロンプトと併用。模擬障害1回（I-3 KPI） |
インフラスキルは監査官・レビュアー限定。VMware-AIops等の操作系は読取・下書きのみ（第9.15）。
19.2.3 事務・エンゲージメント
| スキル | 分類 | Installs | 主用途 | メリット | デメリット・注意 | 導入 | 導入用指示 |
|---|---|---|---|---|---|---|---|
| xlsx | 公開 | 110K | 勤怠・台帳 | 式エラー検出 | 機密は閉域・マスク | npx skills add https://github.com/anthropics/skills --skill xlsx | マスク済CSV×Excelで第18.4照合。給与判断・客先自動送信禁止 |
| pdf / docx | 公開 | 134K/125K | 契約・稟議 | 抽出・編集の標準実装 | 法判断不可 | anthropics/skills から各skill | テンプレ1種。抽出結果は人間確認。外部送信前に必須チェック |
| copywriting | 公開 | — | 社内周知 | トーン統一 | 禁句は社内ルール追記 | skills.sh検索 | 経費・周知文案。禁句表（18.11）でセルフチェック後に人間確定 |
| summarize-meeting | 公開 | — | 議事録構造化 | 決定・宿題抽出 | 内容は人間確認 | skills.sh検索 | 会議後トランスクリプト→決定/宿題/未決分離。顧客向けは必ず編集 |
| attendance-worklog-reconciliation | 社内PoC | — | 勤怠照合 | 締め前不整合検出 | マスク必須 | プロンプト＋xlsx | 第18.2.3指示。A-1 KPI（差戻し8→3件/月等） |
| phone-intake-assistant | 社内PoC | — | 電話取次 | 聞き漏れ・文案 | 自動発信禁止 | プロンプトのみ | 第18.5.3指示。層1（受付支援）から。PH-1 KPI |
| engagement-initiative-drafter | 社内PoC | — | 意識調査施策 | 能動性を促す言い回し | 人事が最終決定 | プロンプトのみ | 匿名サーベイサマリー→施策3案→禁句チェック→1案確定。E-1 KPI |
19.2.4 社内PoCスキル（受託・品質ゲート）
| 名称 | 向く工程 | メリット | デメリット | 導入用指示 |
|---|---|---|---|---|
| 要件定義ゲート | 要件レビュー・見積前 | 曖昧語・BLOCKER抽出、MODE別レビュー | 合意索引・用語集が無いと推測リスク | 要件1章をMODE-Bでレビュー。顧客確認事項と内部修正を分離記録。S-1 KPI |
| 意味逸脱監査 | 版間・AI要約検証 | 勝手な確定・条件消失を検出 | 比較元2版以上必要 | 旧版＋新版を投入。主張強度・責任主体・スコープ差分を一覧→人間判定 |
| 議事録・可読化 | PM/資料管理 | 議事録・Markdown同期の再現性 | パス・機密ルール要整備 | 1会議分でPREP→FINALIZE試行。客先資料は変換ルール＋マスク確認 |
19.3 活用施策一覧（職種×章）
| 領域 | 施策 | 主スキル/手段 | 参照章 | PoC事例ID |
|---|---|---|---|---|
| プログラマ | PR前セルフレビュー＋TDD | TDD, requesting-code-review | 第3章 | P-1 |
| SE | 要件章単位AIレビュー | 要件定義ゲート | 第4章 | S-1 |
| QA | テスト観点生成＋E2E下書き | webapp-testing, 第10章 | 第5章 | Q-1 |
| コードレビュー | AI一次＋人間仕様確認 | requesting-code-review | 第6章 | R-1 |
| DevSecOps | SAST説明＋修正案＋再スキャン | 第7章プロンプト | 第7章 | D-1 |
| PM/PL | 週次品質会議たたき台 | 議事録スキル, 第8章 | 第8章 | M-1 |
| インフラ | IaC PR＋手順書＋障害切り分け | terraform-best-practices, systematic-debugging | 第9章, 11.3 | I-1〜I-3 |
| 事務 | 勤怠照合・電話取次・経費・議事録 | xlsx, docx, 社内プロンプト | 第18章 | A-1, PH-1, X-1 |
| 人事 | パルス連動施策文案 | engagement-initiative-drafter | 第18章 | E-1 |
19.4 PoC KPI一覧（Before → After 統合）
数値はすべてPoC想定・匿名。実測後に差し替え。
| ID | 領域 | 指標 | Before | After | 出典 |
|---|---|---|---|---|---|
| P-1 | 開発 | 人間レビュー重大指摘/PR | 2.1件 | 0.8件 | 第3章 |
| P-1 | 開発 | 単体テスト追加/チケット | 0.5本 | 2.3本 | 第3章 |
| S-1 | SE | 顧客追加指摘/章 | 18件 | 9件 | 第4章 |
| S-1 | SE | 製造後仕様確認チケット/月 | 12件 | 5件 | 第4章 |
| Q-1 | QA | テスト観点数（中機能） | 28件 | 47件 | 第5章 |
| Q-1 | QA | 観点漏れ系バグ/四半期 | 4件 | 1件 | 第5章 |
| R-1 | レビュー | 人間レビュー時間/PR | 45分 | 28分 | 第6章 |
| R-1 | レビュー | AI指摘採用率 | — | 54% | 第6章 |
| D-1 | Sec | High修正リードタイム中央値 | 4.2日 | 2.1日 | 第7章 |
| M-1 | PM | 週次品質資料作成 | 3h/週 | 1.5h/週 | 第8章 |
| I-1 | インフラ | 本番前設定ミス/月 | 2件 | 0件 | 第9章, 11.3 |
| I-1 | インフラ | planレビュー時間/PR | 45分 | 25分 | 第9章, 11.3 |
| I-2 | インフラ | 手順漏れ/四半期 | 3件 | 0件 | 第9章, 11.3 |
| I-3 | インフラ | 障害一次切り分け中央値 | 90分 | 45分 | 第9章, 11.3 |
| A-1 | 事務 | 勤怠締め後差戻し/月 | 8件 | 3件 | 第18章 |
| A-1 | 事務 | 照合工数/月 | 6h | 2.5h | 第18章 |
| PH-1 | 事務 | 電話伝言不備折返し/週 | 5件 | 1件 | 第18章 |
| X-1 | 事務 | 経費差戻し率 | 18% | 7% | 第18章 |
| E-1 | 人事 | 「参加したい」5段階 | 2.8 | 3.1 | 第18章 |
19.4b KPI測定定義
| 指標 | 測定方法 | 母数 | 達成判定 | 信頼度 |
|---|---|---|---|---|
| レビュー時間 | PRまたは文書レビュー開始から完了までの実作業時間を記録 | PoC対象PR / 文書 | 中央値で20%以上短縮 | 高 |
| AI指摘採用率 | AI指摘のうち、人間が妥当として修正・確認に使った件数 | AI指摘全件 | 40%以上を目安 | 中 |
| 手戻り件数 | レビュー後の再修正、差戻し、障害起因の修正を分類 | PoC対象成果物 | ベースライン比で減少 | 中 |
| 設定ミス / 手順漏れ | レビューで検出した本番影響候補と実発生を分けて記録 | 対象作業・IaC PR | 実発生0、検出記録あり | 高 |
| 利用者負担 | 週次アンケートと自由記述で「役に立った / 邪魔だった」を記録 | PoC参加者 | 継続利用可が過半 | 中 |
19.5 導入優先順位（推奨）
| 段階 | 対象 | スキル/施策 | 期間目安 |
|---|---|---|---|
| 0 | 全員 | AI利用ガイド、第10章プロンプト、採否記録 | Week 1-2 |
| 1 | 開発 | requesting-code-review または PRセルフレビュー | Week 3-4 |
| 2 | 開発 | test-driven-development（1機能限定） | Month 2 |
| 2 | SE/PM | 要件定義ゲート、意味逸脱監査 | Month 2 |
| 2 | インフラ | terraform-best-practices + checkov + I-1 KPI | Month 2 |
| 3 | 事務 | xlsx + 勤怠照合（A-1） | Month 2-3 |
| 3 | QA | webapp-testing + 観点生成 | Month 2-3 |
| 4 | 人事 | engagement文案（E-1、禁句必須） | Month 3 |
| 判定 | 全PoC | 第11.5報告、継続/限定/中止（第15章反映） | Month 3末 |
19.5b PoC中止・縮小条件
| 条件 | 判断 | 次アクション |
|---|---|---|
| AI指摘採用率が2週間連続で20%未満 | 対象または使い方が不適合 | 対象を絞る、プロンプトを修正、または停止 |
| 品質指標が悪化する | 導入リスクが効果を上回る | AI出力の利用範囲をセルフチェックに限定 |
| 機密・個人情報の投入統制ができない | ガバナンス不成立 | 当該テーマを停止し、第13章ルールを整備 |
| KPIの母数が取れない | 評価不能 | ログ・記録様式を先に整備 |
19.6 ガバナンス要点
19.6b RACI / 承認マトリクス
| 判断対象 | 実行 | 承認責任 | 相談 | 共有 |
|---|---|---|---|---|
| PoCテーマ採用 | PoC担当 | 部門責任者 | 品質・セキュリティ担当 | 参加者 |
| 公開スキル採用 | 技術リード | PoC責任者 | セキュリティ担当 | 利用チーム |
| 顧客提出物へのAI利用 | 担当者 | 案件責任者 | レビューア | 顧客窓口 |
| 人事・エンゲージメント利用 | 担当部門 | 部門責任者 | 人事・法務・情報システム | 対象者 |
19.6c 公開スキル採用前チェック
- 実行内容、外部通信、ファイル操作、認証情報参照を確認する。
- ライセンス、更新日、依存ツール、メンテナ状況を記録する。
- Stars / Installsは人気指標として扱い、品質・安全性の根拠にしない。
- PoC中はバージョンを固定し、戻し方を決める。
- 公開スキルは監査・社内レビュー後に採用。インストール数≠安全。
- 機密・個人情報はマスク・閉域。勤怠・評価・給与の自動判断禁止。
- インフラ・本番変更は人間承認＋既存変更管理。AIはplan/手順レビューまで。
- 電話は層1（メモ・聞き漏れチェック）から。折返し約束の自動確定禁止。
- 効果測定（19.4）が取れないスキルは限定継続または中止。
- 詳細：第13章、事務：第18章 18.13