Upgrade to Pro — share decks privately, control downloads, hide ads and more …

QA4AIDDを考える会#3 コンテキストエンジニアリングの先へ

Sponsored · SiteGround - Reliable hosting with speed, security, and support you can count on. →

QA4AIDDを考える会#3 コンテキストエンジニアリングの先へ

Avatar for ino-kz

ino-kz

May 14, 2026

Other Decks in Programming

Transcript

  1. ©︎2026 VeriServe Corp. CONFIDENTIAL 会社名・製品名・サ−ビス名は各社の登録商標、または商標です 3 今日のメッセージ • AIDDで効くのは、実装中の指示より実装前の詰め •

    コンテキスト(AGENTS.mdやruleファイル)は有効だが、単体で は不十分 • 必要なのは「正しいコンテキストを、正しいタイミングで、正しい エージェントに渡す」設計
  2. ©︎2026 VeriServe Corp. CONFIDENTIAL 会社名・製品名・サ−ビス名は各社の登録商標、または商標です 4 用語と前提の説明 • Cursor:IDE型のコーディングエージェント ▹Cursorは、.cursor/rules

    内の .mdc ファイル(複数指定可)を実装時の制約として 参照します(≒ AGENTS.md ) • ruleファイル:rulesフォルダ内の .mdc ファイル群 • SPEC.md:AIDDで使用される仕様書 • PLAN.md: AIDDで使用される作業指示書 ここでは Cursor を例に説明しますが、 話の中心はAIDDにおけるコンテキスト(ハーネス)です
  3. ©︎2026 VeriServe Corp. CONFIDENTIAL 会社名・製品名・サ−ビス名は各社の登録商標、または商標です 6 AIDDで最初に起きやすい問題 曖昧な仕様のまま進めると ▹実装が止まる ▹意図と違う判断をする

    ▹後戻りコストが大きくなる AIDDの成否は、プロンプト力より「仕様の曖昧性をどこまで消せたか」で決まる 先に論点を詰めておくと ▹実装で止まりにくい ▹環境要因以外の不動作が減る ▹レビュー対象を絞りやすい AIはコードを書く前に、不足している前提を勝手に補完しようとする
  4. ©︎2026 VeriServe Corp. CONFIDENTIAL 会社名・製品名・サ−ビス名は各社の登録商標、または商標です 7 「実装前」のAI活用フロー 1.要求 :人 2.

    仕様のたたき台 :AI 3. 仮仕様書認定 :人 4. レビュー :AI 5. 不足を決める :人 典型的な問い 「この仕様書で実装をするに当たって、実装が止まるところや、 決めてほしいところはないですか?」
  5. ©︎2026 VeriServe Corp. CONFIDENTIAL 会社名・製品名・サ−ビス名は各社の登録商標、または商標です 9 実装前にここまで詰める理由 実感値 • AIの自己判断と、自分の想定挙動

    は一致しない • AIの判断を減らすほど、出力のブ レを抑えられる 今回の実例 SPEC.mdファイル参照 PLAN.mdファイル参照 何を作るか どう作るか SPEC.md PLAN.md SPEC.mdとPLAN.mdは、 実際に作成した「ローマ字学習アプリ」のものです
  6. ©︎2026 VeriServe Corp. CONFIDENTIAL 会社名・製品名・サ−ビス名は各社の登録商標、または商標です 11 rule ファイル(AGENTS.md)の役割 コーディングルール 書き方の癖をそろえる

    レビューしやすさ向上 セキュリティルール 危ない実装の抜けを 減らす 入力検証・認可・ロ グ分離 汎用ルールとして有 効 設計ルール 作り方そのものを変 える 責務分離・依存方向 ・抽象化 rule ファイルは契約書ではなく、エージェントに与えるコンテキスト
  7. ©︎2026 VeriServe Corp. CONFIDENTIAL 会社名・製品名・サ−ビス名は各社の登録商標、または商標です 12 コーディングルール • 例 ▹

    ` 3項演算子禁止` ▹ `マジックナンバー禁止` ▹ `else/defaultは省略しない` • これは 局所的な書き方 には効きやすい • 読みやすさやレビューしやすさは上がる • コーディングルールは、書き方のルールを定義するもの コーディングルールは守らせやすい ただし、元の実装とかけ離れていれば守られない(経験上の主観)
  8. ©︎2026 VeriServe Corp. CONFIDENTIAL 会社名・製品名・サ−ビス名は各社の登録商標、または商標です 13 セキュリティルール(=security.mdc) OWASP TOP10 2025を参考に作成

    以下の2つを除いた8つの制約を追加 ・A02 運用ルールとして担保すべき項目 ・A06 設計時に担保すべき項目 失敗から学んだこと localhost限定アプリにおいて、コーディングエージェントが A07( Authentication Failures )を守り、認証を実装 → 起動時に認証を求められた 制約は与えるだけではダメ、プロセスや仕様に合わせ た制約を与える必要がある 詳細はAppendixの「OWASP TOP10 2025」参照
  9. ©︎2026 VeriServe Corp. CONFIDENTIAL 会社名・製品名・サ−ビス名は各社の登録商標、または商標です 15 設計ルール適用の効果 設計ルール ルールなし ルール適用:実装時

    ルール適用:設計時 レイヤー構成 △ △ 〇 責務の分離 △ 〇 〇 入力層を薄く △ △ 〇 インターフェースと抽象化 △ △ 〇 ポートとアダプター × × △ データフローと方向性 △ 〇 〇 状態管理 △ 〇 〇 エラーハンドリング △ △ △ 拡張性・保守性 △ 〇 〇 命名規則 〇 〇 〇 依存関係の方向 △ 〇 〇 循環参照の禁止 〇 〇 〇 詳細はAppendixの「設計ルール適用の効果」参照 ルールのみで効く項目(依存関係等)もあるが、設計から適用が必要な項目(レイヤー構成等)も存在する 〇:効果あり △:一部効果あり ×:効果なし 凡例
  10. ©︎2026 VeriServe Corp. CONFIDENTIAL 会社名・製品名・サ−ビス名は各社の登録商標、または商標です 16 制約を満たし切れない理由 • AIの出力は 確率的

    • コンテキストがそろっていても、渡すタイミングで効き方が変わる 完全解は難しい。だからこそ、 ・曖昧性を減らし、 ・選択肢を絞り、 ・タイミングを合わせる
  11. ©︎2026 VeriServe Corp. CONFIDENTIAL 会社名・製品名・サ−ビス名は各社の登録商標、または商標です 17 コンテキストを増やすことも重要だが、その作業に必要な指示を、その時点で渡すことが重要 何を渡すか 仕様 /

    設計 / セキュリテ ィ / レビュー観点 いつ渡すか 実装前 / 設計時 / レビュ ー時 誰に渡すか どのエージェントに担当 させるか ルールは万能化するほど強くなるのではなく、 対象に合うほど強くなる 「渡し方」も設計する必要がある
  12. ©︎2026 VeriServe Corp. CONFIDENTIAL 会社名・製品名・サ−ビス名は各社の登録商標、または商標です 19 • 何を渡すか: 仕様、設計、セキュリティ、レビュー観点 •

    いつ渡すか: 実装前、設計時、レビュー時 • 誰に渡すか: どのエージェントに担当させるか 結論 コンテキストの設計だけでは不十分 正しいタイミングで正しいコンテキストを与える設計が必要
  13. ©︎2026 VeriServe Corp. CONFIDENTIAL 会社名・製品名・サ−ビス名は各社の登録商標、または商標です 20 AIDDでは、思った通りには作られない、指示した通りに作られる まとめ 1. 実装前に曖昧性をつぶす

    2. ruleファイルやAGENTS.mdのようなコンテキストは重要 3. 同じ分野(セキュリティ/設計)のルールでも、仕様で効くもの、設計に効くもの、実装で 効くものがある 4.重要なのは、必要なコンテキストを、必要なタイミングで、必要な相手に渡す設計である 持ち帰りポイント
  14. ©︎2026 VeriServe Corp. CONFIDENTIAL 会社名・製品名・サ−ビス名は各社の登録商標、または商標です 23 OWASP TOP10 2025 OWASP

    TOP10 2025を参考に作成 • A01 Broken Access Control • A03 Supply Chain Failures • A04 Cryptographic Failures • A05 Injection • A07 Authentication Failures • A08 Integrity Failures • A09 Logging / Alerting • A10 Exceptional Conditions A02 Security Misconfiguration :運用ルールとして担保すべき項目 A06 Insecure Design :設計時に担保するべき項目 • A02 Security Misconfiguration • A06 Insecure Design OWASP Top 10:2025
  15. ©︎2026 VeriServe Corp. CONFIDENTIAL 会社名・製品名・サ−ビス名は各社の登録商標、または商標です 24 設計ルール適用の効果 設計ルール ルールなし (A)

    ルール適用: 実装時(B) ルール適用: 設計時(C) レイヤー構成 △ △ 〇 Cはサーバー、フロントを分離し、ユースケース、型定義/制御・外部部接続層と別 れているが、A、Bは明確に層が分かれていない 責務の分離 △ 〇 〇 Aは内部ロジックにデータの読み込みが存在する。Bはデータ読み込みとロジックが 関数として分離している。Cは更にフロント側のユースケースの分離まで進んでいる。 入力層を薄く △ △ 〇 A、Bはメイン処理層がやや厚い、Cは入力処理中心でビジネスロジックの混入が抑 えられている インターフェースと抽象化 △ △ 〇 A、Bは境界は明確だが、データを直接やりとりしている。Cは抽象化レイヤーと型 定義を持つ ポートとアダプター × × △ A、Bはインターフェース定義はない。フロント側はポートとアダプターがあるが、 サーバー側には存在しない データフローと方向性 △ 〇 〇 Aは一部がクライアント側に分散している。B、Cは一方向のフローを守っている。 状態管理 △ 〇 〇 Aはクライアント側が保持している。Bはデータをサーバー側で完結させている。C は型付きでより明確に管理している エラーハンドリング △ △ △ Aは一部チェック漏れがある。Bは一部例外を細くできていないところがある。Cは 内部の詳細まで分離できていない 拡張性・保守性 △ 〇 〇 Aはロジックの分散と入出力が混在して入れ替えが困難。Bはロジックと入出力の入 れ替えが容易。Cはレイヤー分離ができているため追加機能の影響を抑え込みやすい 命名規則 〇 〇 〇 全て、責務が分かる命名がされている 依存関係の方向 △ 〇 〇 Aはロジック層が入出力を保持している。Bはメイン処理→ロジックへの方向が守ら れている。Cはポートとアダプターを軸に方向が守られている 循環参照の禁止 〇 〇 〇 循環参照はどれも見当たらない