AI駆動開発の歩き方 ～入門・エージェント・ハーネス・そして3つのリスク～
-- Views
August 17, 26
スライド概要
AI駆動開発の概要とコツ、注意点を知ろう (2026年8月版)
AI駆動開発の基礎からエージェント設計、ハーネス・ループエンジニアリング、セキュリティ・理解負債・教育リスクまで包括的に解説。実践的な開発管理と効果測定も紹介。
I'm a software development engineer. (Microsoft MVP Jul. 2005 - Jun. 2026)
関連スライド
各ページのテキスト
AI駆動開発の歩き方 入門・エージェント・ハーネス・そして3つのリスク 2026年8月 小島 富治雄
自己紹介 小島 富治雄 @Fujiwo 福井コンピュータ グループ Microsoft MVP (22年目) C#関連
社内での取り組み 2018年 『機械学習勉強会』 2019年 『AI/ML勉強会 基本編』 『AI/ML勉強会 IoT編』 2021年～ 『AI・ML勉強会』 チャンネル (Teams) 2024年 『生成AI入門 ～人工知能/機械学習とは～』 2025年 『AIエージェント勉強会 ～マイクロソフトの最新技術発表を受けて～』 『AIエージェント開発ハンズオンセミナー』 2
社外での取り組み 2018年 【de:code 2018】『C# でニューラルネットワークをスクラッチで書いて機械学習の原理を理解しよう』 講演 2019年 【Global AI Nights Fukui】 主催・ 講演 【福井工業大学 AI&IoTセンター設立シンポジウム】 講演 2020年 【de:code 2020】 『Azure Machine Learning Studio (Preview) と Python と C#/.NET による ディープ ラーニングのサンプル/チュートリアル』 【Global AI On Tour Toyama】 主催 3
本日のゴール AI駆動開発の概要とコツ、 注意点を知る 4
アジェンダ 序章: なぜ今、AI駆動開発を整理し直すのか 第7章: リスク① セキュリティ 第1章: AI駆動開発とは何か 第8章: リスク② 理解負債・認知負債 第2章: AI駆動開発入門 第9章: リスク③ ジュニアエンジニアの教育 第3章: コーディングエージェント 第10章: 効果測定 — 「速くなった」は本当か 第4章: エージェント指示ファイル 第11章: トークン節約とコスト設計 第5章: ハーネス エンジニアリング 終章: まとめ 第6章: ループ エンジニアリング 資料 5
アジェンダ 理解から実践までを5つの観点でたどる 現在地 開発とエージェント 指示と制御 リスク コストと行動 序章〜第2章 第3章〜第4章 第5章〜第6章 第7章〜第9章 第10章〜終章 最初の一歩 コーディング エージェント ハーネス・ループ 組織で守る 次の一歩へ 個人の利用から、チームで制御できる開発へ アジェンダ 6
序章 なぜ今、AI駆動開発を 整理し直すのか 論点は「どう書くか」から 「書かれたものをどう統治するか」へ移った 序章 7
序章 論点は「書けるか」から「統治できるか」へ移った 2025年 2026年 自然言語で 大量に生成されたものを どこまで書けるか どう統治するか 開発の主戦場は、生成そのものから評価・統制へ広がる 序章 8
序章 現場の4つの困りごとは、速度だけでは解けない 速いのに終わらない レビューが追いつかない ボトルネックが 生成速度が 別の場所にある 検査速度を超える 若手が育たない 請求額が読めない 学ぶ過程を 利用量が 外部委託してしまう 経営上の変数になる 序章 9
第1章 AI駆動開発とは何か 定義と全体像 ボトルネックは、記述から 評価・仕様・観測可能性へ移る 第1章 10
AI駆動開発 すべてのソフトウェア開発工程に生成AIを AIの役割 企画、計画、設計、実装、テスト、運用 エンジニアの役割 Before コードを自ら書く After 「AIへ的確に指示し、結果を見極める監督」 要件の言語化、全体設計、AI生成物のレビューや最終的な意思決定 11
第2章 AI駆動開発入門 最初の一歩とツール選定の観点 最初に決めるのは、AIに任せることではなく 人間が意思決定に専念できる協調関係である 第2章 12
AI駆動開発 初期のステップ 要件整理 コード レビューさせる 設計相談 リファクタリングさせる 開発計画を立てさせる テストケースを作成させる (条件を明確にして) テストさせる コード生成させる デバッグさせる 最終判断は人間が行う 13
AI駆動開発導入の3段階 0. Traditional 1. AI Augmented 2. AI Native 3. Agent • 手動プロセス中心・属人 化 • 人間の認知能力を基準に した設計 • 人が主役 / AI は副操縦 士 • Copilot を補完 • Human In The Loop 形態 • 仕様を「契約」に • 生成・レビュー・修正・完了 証明を一気通貫 • 人がループ内で成果確認 • Human On The Loop 形態 • AIが生成・レビュー・修 正・完了証明ループを実 施 • 複数エージェントが役割 分担 • 人はAIプロセスを設計・ 維持・監督 14
AI Native における開発フロー AI: 連続ループ コード生成とテストがシームレスに循環し、AIが自律的にエラーを修正 人間の新たな役割 意図・仕様入力 → 結果を確認 → 元の仕様を更新・洗練 プロダクトの価値を最大化 1. 人 意図/仕様 2. AI 設計生成 3. AI コード生成 4. AI テスト生成 5. 人 レビュー • 人が意図を入力 • 最適な構造を提案 • 実装を自動化 • 検証を自動実行 • アウトプット確認 と仕様更新 15
5つの柱 批判的レビュー 自動デバッグ 承認 完了証明 境界定義 • 生成物を別の • 問題あり → 原 • 計画、仕様、 • 客観的に「本 • 行ってよい範 AIが「あら探 因分析 → 修正 設計、実装で 当に完了した 囲を予め設定 し」の視点で → 再検証 人が承認する か」を証明 し、安全性確 チェック を自動化 仕組み AIが生成 批判的レ ビュー 問題? 保 自動修正 完了証明 人が承認 16
仕組みの構築 導く・止めるだけでなく, 直して完了を証明するまでを仕組みにする ハーネス (方向・主観) Constitution / Skills - AI に「どう走るか」を事前に設計する ガードレール (逸脱を止める・客観) lint / 型 / test / CI / Hooks - 逸脱を機械的に検知・ブロックする 能動品質ループ 役割分離 (生成 ≠ レビュー ≠ 検証) → 自己修復 → 完了証明 17
管理するもの ドキュメント 仕組みの構築 プロンプト、計画書、仕様書、 設計書 テスト コード 18
ドキュメント管理が肝 常に管理・アップデート 人とAIが読めるものを MarkDown など 階層化・構造化 曖昧だとぶれる 多過ぎてもぶれる トークン消費量に注目 19
言語化が重要 知識を共有する プロセス SECIモデル - Wikipedia 20
言語化が重要 AI とは形式知をやり取り 言語化が重要! 暗黙知 • 個人の頭や体にある • 言葉での説明が難しい • ベテランの勘、職人の技など 形式知 • 文字や数字、図になっている • 共有できる • 業務マニュアル、手順書など 21
第3章 コーディングエージェント 選定軸は機能だけではない コスト構造とガバナンス要件を読む 第3章 22
第3章 補完型からエージェント型へ、役割の重心が移っている 補完型 エージェント型 入力中の提案を受け、 タスクを受け、探索、変更、検証を 人が作業の流れを主に進める まとまりとして進める 自律性が上がるほど、権限と承認の設計が選定条件になる 参考: Claude Code・Cursor・GitHub Copilot を徹底比較 第3章 23
AIコーディング エージェント ツール名 分類 主な動作環境 自律度 GitHub Copilot インライン補完・機能拡張型 / CLI IDEプラグイン (VS Code, JetBrains, Visual Studio等) 低 Cursor AIネイティブ統合IDE型 専用GUIエディタ (VS Codeフォーク) 中〜高 Windsurf AIネイティブ統合IDE型 専用GUIエディタ 中〜高 Claude Code CLI / ターミナル自律エージェント型 ターミナル / シェル / IDEプラグイン 高 Aider CLI / ターミナル自律エージェント型 ターミナル / Git統合環境 高 Grok Build CLI / ターミナル自律エージェント型 ターミナル / ビルドパイプライン 高 Google Antigravity マルチエージェント・オーケストレー ション型 クラウド環境 / ブラウザワークスペース 最高 Devin マルチエージェント・オーケストレー ション型 完全分離型クラウドサンドボックス 最高 OpenAI Codex CLI / エージェント基盤 API / カスタムCLI環境 中〜高 24
【参考】 コーディング エージェントの比較 Claude Code・Cursor・GitHub Copilot を徹底比較 — 「コード補完」と「エージェント型」で使い 分けが分かれるAIコーディングアシスタント選択指南 - TechFeed ツール名 Claude Code 特長 Cursor VS Code系IDEに深く統合。 文脈理解と改善提案が強い。 GitHub Copilot 高速なコード補完と自然言語→コード生成が得意。 エージェント型。 ターミナル操作や複数ファイル編集を自動化できる。 25
第3章 コストは、定額の席数から利用量の予測へ論点が広がる 従来の見方 従量課金が増える見方 利用者数を基準に、 自律実行、試行回数、利用モデルにより 予算を見積もりやすい 費用の変動要因が増える GitHub Copilotのプラン変更など 参考: github.comでCopilotを使いこなす ～コードの調査、AIレビュー、自律実装をWebブラウザで完結 | gihyo.jp 第3章 26
第3章 選定軸は、機能比較からコスト構造とガバナンスへ 実行形態 コスト構造 ガバナンス どこで、どこまで 利用量が増えたときの 権限、承認、監査を 自律実行させるか 予測と上限をどう置くか どう設計するか 組織が安全に使い続けられるか → ライセンスの確認 第3章 27
第4章 エージェント指示ファイル 指示ファイルは、書き足すものではない AIが間違える行だけを残す 第4章
第4章 エージェント設計は、3つの層に分けて考える コンテキスト ハーネス ループ 何を渡すか どんな足場で動かすか どう反復し、いつ止めるか 出典:プロンプト、ループ、グラフ——AIエージェント設計の「3層構造」を整理する — どの層を選ぶかの判断基準も 第4章
第4章 指示ファイル CLAUDE.md SKILL.md プロジェクト固有の手順とハマりどころ 手続きの標準化 出典: Best practices for Claude Code - Claude Code Docs 第4章
第4章 プロジェクト固有の前提を `CLAUDE.md` に置く CLAUDE.md # Project rules - Run unit tests before completion - Do not edit generated files - Keep public APIs stable - Read docs/architecture-decisions.md 手順ではなく、間違えると困る前提を残す 第4章
第4章 繰り返す特定作業は `SKILL.md` にする SKILL.md --name: verify-change description: Validate a scoped change --- 1. Run targeted tests 2. Check diagnostics 3. Report evidence 再現可能な手順を、必要なときに呼び出せる形へする 第4章
第5章 ハーネス エンジニアリング AIを賢くする工夫ではない AIが間違っても壊れない足場を設計する 第5章
第5章 ハーネスは、AIの失敗を検知して止める足場である AIが変更する 決定論的に検査する 失敗を検知して止める モデルの回答品質に期待するのではなく、失敗しても影響を広げない仕組みを置く 第5章
ハーネスの例 1. 権限 5. ファイル変更 • AIは main 変更不可 / push不可 / 削除不可 / 設定 変更不可 • 変更はすべて diff で記録 • 破壊的変更は 人間承認必須 AIが触れるのは 作業ブランチ内のコードのみ 6. ドキュメント • 2. タスク • AIは proposal.md に案を出力 • タスクは人間が細分化 • 本番ドキュメントは人間が統合 • AIは 1タスク=1変更 のみ 7. レビュー • 大きい作業は渡さない • AIの出力は必ず人間がレビュー 3. テスト • 人間が commit → push → CI → merge • AIは コード+テストを同時生成 8. ログ • テスト・lint・静的解析は自動実行 • 修正は 最大3回まで(ハーネス側で制御) 4. 実行環境 • AIは sandbox / read-only プロジェクト • 書き込みは workspace/ai/ のみ • 外部アクセス禁止 • AIの生成物・変更・テスト結果をすべて保存(90日) 9. 暴走防止 • 出力サイズ上限 • 変更ファイル数上限 • 実行時間上限 • 再試行上限 (3回) 35
36
【参考】 ハーネス エンジニアリング ハーネスエンジニアリングとは何で、何ではないのか 〜作る側のハーネス、使う側の ハーネス〜 最近知った「ハーネス設計」という考え方がかなり重要だった #AI – Qiita Claude Codeでハーネスエンジニアリングを実践する — 5層の設計パターン Claude Codeハーネスエンジニアリング まず抑えるべき基礎知識 - YouTube 37
第6章 ループ エンジニアリング プロンプトを書くな 止まれるループを設計する 第6章
第6章 進化の焦点は、指示から反復の設計へ広がってきた 1 2 3 4 プロンプト エンジニアリング コンテキスト エンジニアリング ハーネス エンジニアリング ループ エンジニアリング 単発の指示 前提を渡す 実行の足場 評価して反復 第6章 39
ループ エンジニアリング STEP 1. プロンプト プロンプト → AI が処理 → … の繰り返し Human In The Loop: 人がループの中 Human On The Loop: 人はループの外から監督 41
ループ エンジニアリング STEP 2. 人間が方向付け 1. プロンプト 2. コンテキスト 3. ハーネス 4. ループ 42
ループ エンジニアリング 1. プロンプト: 頼み方の設計 2. コンテキスト: 見せる情報を選ぶ 3. ハーネス: 制約/足場 4. ループ: Human On The Loop (人はループの外から監督) 43
ループ エンジニアリング 1. プロンプト: 頼み方の設計 2. コンテキスト: 見せる情報を選ぶ Claud.md 3. ハーネス: 制約/足場 Skill.md LINT 4. ループ: Human On The Loop テスト 権限 (人はループの外から監督) 44
第6章 ループの難しさは、回すことではなく、いつ止めるかにある 止める理由 止める上限 止める判断 目的を満たした 予算・時間・試行回数を 評価できない状態を 差分が残っていない 超えない 人へ戻す 停止条件は、ループの外側から人が設計する 第6章
46
47
第7章 リスク① セキュリティ エージェントは「読む」「実行する」の 2方向で攻撃面を広げる 第7章
AI駆動開発のセキュリティ リスク 機密情報や認証情報 (APIキーなど) の流出 連携ツールの権限逸脱 (RAG/MCPリスク) エージェントがRAG/MCPを介して社内DB、社内リソース、GitHubな どにアクセスし、機密情報をLLMに読み込ませてしまう AI が環境を壊す 49
セキュリティ対策 セキュリティガイドライン(運用ルール)の制定 利用エディションと契約の確認 Enterprise 向けか コード内機密情報/認証キー記載の禁止 RAG/MCPへのアクセス認可 専用の開発環境 (サンドボックス: 仮想・コンテナ環境) サンドボックス環境を選択する - Claude Code Docs 50
【参考】 リスク① セキュリティ AIエージェント導入で「セキュリティどうするの?」と聞かれたと きの技術的な答え方 LLMのコスト暴走と情報漏洩を防ぐ社内Gateway設計: Azure/AWSガバナンスとLiteLLM実装 (Phase1→Phase2) #Security - Qiita りなたむ(Ryota)@ITの町医者 : 「生成AI利用ガイドライン」 / Twitter 51
第8章 リスク② 理解負債・認知負債 コードは綺麗でも、誰も理解していない 前提が反転したなら、設計の優先順位も反転させる 第8章
第8章 「2025年の崖」: 生成量が理解を追い越す 生成 レビュー 保守 AIが変更を素早く 積み重ねる 人が全体像を保てなくなる 意図を説明できない コードが残る 崖とは、コード量と人の理解の差が短期間で広がる状態を表す 第8章
理解負債 (LLMによって) 思考はアウトソースできても、 理解はアウトソースできない 54
責任 責任はAIに転嫁できない 55
第8章 技術負債と理解負債では、遅れるものが逆になる 技術負債 理解負債 先行するもの 先行するもの 人の理解が先行する コードの生成が先行する 遅れるもの 遅れるもの コードの整理が追いつかない 人の理解が追いつかない 1992年の技術負債の比喩は、人の理解が先行することを前提としていた 第8章
第8章 認知の放棄は、個人と組織の沈黙から始まる 個人: Cognitive Surrender 組織: 沈黙の共謀 理解の過程をAIへ全面的に委ね、 短期の速度を優先し、 分かったつもりで変更を受け入れる 理解不足を見えないままにする 理解を外注すると、障害時に判断するための前提も失われる 第8章
第8章 速度は前払い、失敗は後払いになる 前払いされるもの 後払いされるもの 実装と変更の速度 障害時の調査と判断 短期の進捗と見かけの成果 保守時の理解と修正 開発が速くなっても、デリバリーまで速くなるとは限らない 参考: AIが書いたコードは誰も理解していない — 「レビュー負債」という見えないコストを定量化する試み 第8章
【参考】 技術負債・理解負債・認知負債 認知負債 - kawasima AIコーディングはなぜ後から苦しくなるのか? 技術負債に続く 「理解負債」「認知負債」という新たな落とし穴:Deep Insider Brief ― 技術の“今"にひと言コメント - @IT AIで開発速度は上がったのにデリバリーは速くならない — GitLab調査が示す「制御なき速度は負債」という現実 TechFeed 59
第9章 リスク③ ジュニアエンジニアの教育 教育は制度ではなく、 開発プロセスの設計で守る 第9章
これからの人材育成 コルブの経験学習モデル 1. やってみる (具体的経験) 4. 新たに試す (能動的実験) 2. 振り返る (内省的観察) 3. コツを引き出す (抽象的概念化) 61
これからの人材育成 AIに丸投げすると… ① 経験が積めない ② 振り返れない →学習できず、成長もしない 1. やってみる (具体的経験) 4. 新たに試す (能動的実験) 2. 振り返る (内省的観察) 3. コツを引き出す (抽象的概念化) 62
AIと学習 AIに頼りきると「考える力」が落ちる AIを信じると批判的思考力が低下する CHI'25 Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems 答えを簡単に教えるAIは学習を阻害する Generative AI without guardrails can harm learning: Evidence from high school mathematics | PNAS 63
ジュニアエンジニアの育成方法 AIを使いつつ人間側に思考・判断・検証の経験を残す設計 まず自らの考えを出させる 要件・タスク分解・設計案・リスク・テスト方針・仮説や不明点 AIのレビューを見せる AIの結果をレビューさせる ― 誤りを発見し修正させる 「意思決定」を早い段階から「実環境で」体験させる 要件定義、設計レビュー、優先順位決定 障害対応、リリース判断、セキュリティレビュー、振り返り 64
ジュニアエンジニアの育成方法 AIを使いつつ人間側に思考・判断・検証の経験を残す設計 まず自らの考えを出させる • 目的・背景 • なぜそうしたか AIのレビューを見せる • なぜこの設計か • どう実装したか AIの結果をレビューさせる ― 誤りを発見し修正させる • 学び・気づき • 継続的に改善 「意思決定」を早い段階から「実環境で」体験させる • チームの知恵として再利用・成長 要件・タスク分解・設計案・リスク・テスト方針・仮説や不明点 要件定義、設計レビュー、優先順位決定 障害対応、リリース判断、セキュリティレビュー、振り返り 65
ジュニアエンジニアの育成方法 人とチームが育ち続けるような AI の利用 66
67
68
【参考】 エンジニアに求められる力 「AI時代、エンジニアに本当に求められる力とは」──株式会社Arcobaleno取締役 前田修宏氏 – TechFeed AIの登場で燃え尽き症候群に陥るテック人材が増加--最大の懸念は業務量の増加 - ZDNET Japan AIがコードを書く時代に「コーディングを教える」とはどういうことか — UT Austin が試みる3つのアプローチ – TechFeed 69
第10章 効果測定 — 「速くなった」は本当か 体感と実測のズレを前提に、 測る対象をコード量からデリバリーへ移す 第10章
生産性の実態・効果測定 「AIで速くなった」は本当か——実験では19%遅くなっていたという研究が示す自己 欺瞞のメカニズム - TechFeed なぜ、AIで生産性があがっていると錯覚してしまうのか エンジニアは、なぜ生成AIで仕事が楽にならないのか #Claude - Qiita Vibe Coding、最初は速い。でも後半で急にしんどくなる #AI - Qiita AIでコードは速くなったが、出荷は速くならない — GitLabの調査が示す「コーディ ング高速化の罠」 - TechFeed 71
第10章 利用率が高くても、ボトルネックは開発サイクル全体に残る 局所の効率化 全工程で問うこと 実装や下調べは速くなる レビュー待ち、テスト、リリース、 しかし、生成量だけでは成果を説明できない 運用のどこが制約になっているか 国内の公開事例は、利用率ではなく工程全体を問う必要を示している 第10章
第11章 トークン節約とコスト設計 節約とは我慢ではない 渡す情報と判断の配置を設計する 第11章
コスト・トークン節約 1. 会話コンテキストの管理 毎ターン過去のやり取りが入力トークンとして送られるので、会話が長くなると消費が激しくなる 次のタスクに移る前に `/clear`（または CLI の再起動）を行い、会話履歴を一度リセット コンテキストの要約 (`/compact`) で過去の経緯をAIに要約・圧縮させる プロンプトは自分で管理 2. 指示ファイル (`.claudeignore`) で読み込み範囲を制限 3. 明確なスコープ指定とプロンプトの工夫 対象ファイルや関数を明示する 最初に「作業方針を挙げて」と指示し、問題がなければ「作業を進めて」と段階を踏む 74
コスト・トークン節約 (続き) 4. 指示ファイル (`Claude.md` や `Skill.md` など) の最適化 長くしない 5. LLM モデルの使い分け 6. 丁寧語をやめる・やめさせる 7. genshijin 原始人 Skill その他 code-review-graph など 75
第11章 システムプロンプトは、ルールを足すより重複を削る 細かく縛る 判断を委ねる ルールを重ねるほど、 必要な制約と停止条件を残し、 重複と矛盾がコンテキストを消費する 詳細な手順は状況に合わせて選ばせる 指示ファイルは、消しても間違えない行から削る 参考:システムプロンプトを約80%削減できた — Claude 5世代で変わる「ルールを与える」から「判断を委ねる」へのプロンプト設計 第11章
コストの測定 消費トークンを記録する 77
コスト・トークン節約 楽しかったコーディングエージェントサブスク時代の終わり AIコーディングエージェントのコストを35%削減する「賢いモデルを全タスクに使わ ない」設計 — Devinがフロンティアモデルとサイドキックモデルをセッション中に動 的に使い分ける仕組みを公開 - TechFeed LLM APIのコストを60%削減する4つの技術 — プロンプト圧縮・セマンティック キャッシュ・CoT剪定・出力長制約を組み合わせた実践ガイド – TechFeed システムプロンプトを約80%削減できた — Claude 5世代で変わる「ルールを与え る」から「判断を委ねる」へのプロンプト設計 - TechFeed 78
終章 まとめ 全部任せるか、一切使わないか その二元論から離れる 終章
終章 AI駆動開発を貫く、4つのメッセージ 人間の判断を残す ハーネスで安全にする 承認と説明の責任を 決定論的なセンサーと AIへ転嫁しない 境界で支える ループを止められるようにする 速さをデリバリーで測る 停止条件と人へ戻す コード量ではなく 経路を設計する 本番採用までを測る 終章
終章 過大評価も過小評価も避け、選択肢を広げ続ける 短期の見方 長期の見方 変化を過大評価し、 変化を過小評価し、 すぐに万能の答えを求めてしまう 学び直しと選択肢を閉じてしまう AI時代にも銀の弾丸は存在しない だから、判断を保留して検証を続ける 参考: 2026年のソフトウェア開発を考える（2026/07版） / Agentic Software Engineering 2026-07 Findy Edition - Speaker Deck 終章
まとめ 序章: なぜ今、AI駆動開発を整理し直すのか 第7章: リスク① セキュリティ 第1章: AI駆動開発とは何か 第8章: リスク②理解負債・認知負債 第2章: AI駆動開発入門 第9章: リスク③ ジュニアエンジニアの教育 第3章: コーディングエージェント 第10章: 効果測定 — 「速くなった」は本当か 第4章: エージェント指示ファイル 第11章: トークン節約とコスト設計 第5章: ハーネス エンジニアリング 終章: まとめ 第6章: ループ エンジニアリング 82
83