第20章:AI前提の学び方&運用🤖💡(教材の仕上げ)
この章はね、「AIを使って速く作る」だけじゃなくて、レイヤードのルールを“守り続ける”ためにAIを使う回だよ〜!👯♀️✨ (ここまで作ってきた4プロジェクト構成を、ずっとキレイに保つやつ!🧹💖)
1. AIは“3つの使い方”に分けると超ラク🤖🧠

AIって、ざっくりこの3モードで使い分けると事故りにくいよ〜!✨
A) その場で補完:Inline Suggestions ✍️⚡
入力中に候補が出るやつ! 「細かい記述」「ちょい面倒なif/guard」「LINQの形」みたいな手の動きを止めない用途に最強だよ🫶
B) 会話で相談:Copilot Chat 💬🧩
「これどの層に置く?」「この責務どこ?」みたいな設計相談に使うやつ! Copilot ChatはIDE(Visual Studio含む)でも使えるよ〜! (GitHub Docs)
C) まとめて作業させる:Agent / Code Review / PR Summary 🧰🛠️
- Issueを投げてPR作らせたり(coding agent) (GitHub Docs)
- PRの要約を作らせたり(pull request summaries) (GitHub Docs)
- レビューコメントをAIに出させたり(code review) (GitHub Docs)
「一気にやって、最後に人が判断する」系だね!✨
2. レイヤー違反チェックをAIに“習慣化”させよう✅🧱
レイヤードの一番こわい敵はこれ👇
- 便利だから…でDomainからDBを触り始める😇💥
- PresentationがDomainの内部事情に口出しする🙅♀️
- Infrastructureの型が上位に漏れる😵💫
ここをAIに毎回チェックさせると、かなり安定するよ〜!🧡
2-1. “依存ルール”をAIに渡す(最初の一手)🗺️
まず、AIにルール表を渡すのが超大事!
例(4プロジェクト想定)👇
- Presentation → Application 参照OK ✅
- Application → Domain 参照OK ✅
- Infrastructure → Application/Domain 参照しがちだけど、基本はApplication/DomainがInfrastructureを参照しない形にする(interfaceは上位に置く)✅
- Domain → どこも参照しない(最強の純粋層)💎
これを“毎回”AIに同じ形式で渡すと、判断がブレにくいよ✨
3. Visual StudioのCopilot Chatで“解決策全体”を見せて相談💬🏗️
Visual StudioのCopilotには「解決策(#solution)を参照して質問する」系の使い方があるよ〜!🧠 (ファイル参照や意図指定のコツも紹介されてる) (Visual Studio)
たとえば、レイヤー違反チェックはこう聞く👇
あなたはレイヤードアーキテクチャの設計レビュー担当です。
#solution を前提に、次をチェックして:
1) Domain層が外部(DB/HTTP/IO)に触っていない?
2) PresentationがDomainルールを持ち込んでない?
3) Applicationが「手順」以上のルール(ドメイン知識)を持ってない?
違反っぽい箇所があれば、(a)問題点 (b)移動先 (c)修正案 を箇条書きで。
可能ならクラス名・メソッド名も添えて。
この質問をPR前に毎回やるだけで、だいぶ“設計の健康”が保てるよ✅💖
4. 変更が来たらAIにまず聞く:「どの層が変わる?」🧠🔍
機能追加や仕様変更で一番やるべきはこれ👇
変更点を、層ごとに分解する🧩
AIに「分解」をやらせると速いよ✨
仕様変更です:
- ToDoに「期限」と「重要度」を追加
- 期限切れは一覧で警告表示
- 重要度は High/Normal/Low
質問:
1) Presentation/Application/Domain/Infrastructure のうち、どこに変更が入る?
2) 各層で追加・変更すべきクラス候補
3) Domainルール(不変条件・禁止状態)として置くべきもの
4) DTO変換が増える場合の整理案
出力は「層ごとのToDoリスト」で。
ポイントは、AIにコードを書かせる前に“設計の地図”を作らせることだよ🗺️✨
5. AIレビューを“儀式”にする(PR前の3点セット)🧪📝✅
Copilotにはコードレビュー支援やPR要約もあるので、運用に組み込みやすいよ〜! (GitHub Docs)
PR前の3点セット(おすすめ)🎀
- レイヤー違反チェック(第2章のプロンプト)✅
- 例外・エラーの境界チェック⚠️
- テスト抜けチェック🧪
AIに投げるテンプレ👇
PRレビューして!
観点:
- レイヤード違反(参照方向/責務の混入)
- 例外の握り場所(UIに漏れてない?Domainの意図は残ってる?)
- テスト観点(境界値/例外系/ユースケースの分岐)
出力形式:
[指摘] -> [理由] -> [修正案] -> [該当ファイル/クラス]
6. テストはAIに増やしてもらうのが最強🍰🧪
レイヤードのご褒美はテスト! 特にDomainは依存が少ないからAIがテストを書きやすい💎✨
AIに渡すコツ🎯
- “仕様”を文章で渡す
- “不正ケース”も明示する
- 期待する例外 or 結果を指定する
次のDomainメソッドのユニットテストを xUnit で作って。
ルール:
- 期限が過去なら例外
- 重要度は High/Normal/Low のみ
- タイトルは空文字NG(空白もNG)
欲しいテスト:
- 正常系3本(重要度ごと)
- 異常系4本(過去期限、空、空白、未知の重要度)
- 境界値(今日/明日)
AIが出したテストは、最後に自分の言葉で仕様チェックしてね🫶 (AIは平気で“それっぽいけど違う”期待値を置くことあるある😇)
7. 安全運用:秘密情報・ライセンス・脆弱性は要注意🔐⚖️🛡️
ここ、超だいじ!!!✨
7-1. Copilotの出力は“脆弱性チェック”などを通る仕組みがある🛡️
GitHub側では、提案がセキュリティ脆弱性(例:SQLインジェクション等)を含まないか等のチェックが説明されてるよ。 (GitHub Resources) さらに、公開コードに近い提案を抑制するフィルタ(管理者が有効化できる)も案内されてる。 (GitHub Resources)
7-2. “公開コードに似てるか”を後から確認できる仕組みもある🔎
Copilotが公開コードに似た提案をした場合に、参照情報をログで確認する手順が用意されてるよ(Visual Studio/VS Codeなど)。 (GitHub Docs)
7-3. Visual Studio 2026:NuGetの脆弱パッケージ修正をCopilotで支援🧯📦
Visual Studio 2026のリリースノートでは、Copilot Chatの“ツール”として NuGet MCP Server を有効化して、 「パッケージ脆弱性を直して」みたいなプロンプトで更新提案を出せる流れが書かれてるよ。 (Microsoft Learn)
Fix my package vulnerabilities
これ、運用でめちゃ助かる〜!🧡
7-4. 絶対ルール(やりがち事故を先に潰す)🚫
- APIキー・トークン・接続文字列は貼らない🔑🙅♀️
- 社外秘のログ全文を丸ごと貼らない📄🙅♀️
- コードが提案されたら「テスト・ビルド・静的解析」を必ず通す✅🧪
- コピペ採用したら、ライセンス面も“確認できる導線”を残す🔎⚖️(上のログ確認など) (GitHub Docs)
8. “AI運用フロー”のおすすめ(毎回これで回す)🔁✨
① 変更の分解(どの層が変わる?)🧠
→ 第4章テンプレでAIに地図を書かせる🗺️
② 実装(小さく刻む)✍️
→ Inline補完で速度UP⚡
③ 迷ったら即相談(どの層?責務は?)💬
→ Copilot Chatで「責務」「移動先」を確認🧩 (GitHub Docs)
④ テスト追加🧪
→ Domain中心にAIで増やす🍰
⑤ PR前レビュー(3点セット)✅
→ レイヤー / エラー境界 / テスト抜け
⑥ 依存更新・脆弱性対応📦🛡️
→ VS 2026ならNuGet MCP Server活用✨ (Microsoft Learn)
9. Codex(OpenAI)を“作業者”として使うときの考え方👷♀️🤖
Codexは「クラウド上の隔離環境で、リポジトリを読み書きして、コマンドも実行できる」タイプのエージェントとして紹介されてるよ。 (OpenAI) さらにGPT-5.2-Codexは、大規模リファクタや移行みたいな“長い作業”に強く、Windows環境での作業性にも言及がある。 (OpenAI)
向いてる仕事🎯
- 大きめリファクタ(命名・分割・フォルダ移動)🧹
- 仕様に沿った一括修正(DTO追加、マッピング修正)📦
- テスト失敗の修正ループ🧪🔁
- 移行(パッケージ更新、破壊的変更への追従)📦⚠️
ただし最後は人間の責任💡
「動くけど設計が崩れる」も起きるから、レイヤー違反チェックは最後に必ずやろうね✅🧱
10. Copilotを“設計相棒化”する小ワザ集🎁✨
10-1. カスタム指示・モデル選択・エージェント系機能は“育てゲー”🎮
Copilot側は、モデル選択・カスタム指示・エージェントモード等に触れていて、ワークフローに合わせて調整できる方向性があるよ。 (Visual Studio Marketplace)
おすすめは、「レイヤード憲法(ルール)」をカスタム指示として固定すること!📜✨ (毎回説明しなくてよくなる)
11. コピペで使える!プロンプト10連発🤖💖
① レイヤー違反スキャン
#solution を設計レビューして。
層の責務混入と参照方向違反を列挙して、移動先と修正案を出して。
② “このクラス、どの層?”
このクラスの責務を要約して、Presentation/Application/Domain/Infrastructure のどこが妥当か判定して。
理由も。
③ Domainに置くべきルール抽出
このユースケースの文章仕様から、Domainに置くべき不変条件(禁止状態)を箇条書きで。
④ Application手順書化(やりすぎ防止)
ユースケースを「手順」だけに分解して。Domainルールとして置くべき部分は別枠で分けて。
⑤ DTO/Mapping整理
DTOが増えてきた。境界変換の置き場所と命名規約案を提案して。フォルダ案も。
⑥ 例外の握り場所レビュー
例外がどこからどこへ漏れているか追跡して。
UIに返す形へ変換する境界点も提案して。
⑦ テスト観点生成
このDomainメソッドのテスト観点を列挙して。
境界値・異常系・同値分割を意識して。
⑧ リファクタ計画(安全に小分け)
このリファクタを“安全なコミット単位”に分割して。各コミットで通すべきテストも書いて。
⑨ PRレビュー依頼
PRレビューして。
観点:レイヤー違反 / エラー境界 / テスト抜け / 命名と責務
[指摘]->[理由]->[修正案]->[該当箇所]
⑩ 依存更新・脆弱性対応(VS 2026向け)
依存パッケージの脆弱性を直したい。
更新方針(安全な順番・互換性の見方・影響範囲)を提案して。
(VS 2026だと「Fix my package vulnerabilities」みたいな誘導も公式に載ってるよ〜!) (Microsoft Learn)
12. 章末チェックリスト✅🎀
- 変更点を層ごとに分解してから実装した🧠
- Domainが外部詳細に触れてない💎
- Applicationが“手順書”のまま保たれてる📋
- DTO/Mappingが境界に隔離されてる📦
- PR前にAIレビュー(レイヤー/例外/テスト)を通した✅
- 依存更新・脆弱性は定期的に面倒見れてる🛡️📦(VS 2026のCopilot支援も活用) (Microsoft Learn)
- 公開コード類似・ライセンス確認の導線を理解した🔎⚖️ (GitHub Docs)
次の一歩としてはね、あなたのサンプルアプリで「わざとレイヤー違反を1つ作って」→AIに見つけさせるのが超おすすめ!😈🧱✨ やるなら、違反例のコード(1ファイルだけでもOK)貼ってくれたら、プロンプト込みで“直し方の筋”を一緒に作るよ〜!🤝💖