---
title: AI駆動開発の歩き方 ～入門・エージェント・ハーネス・そして3つのリスク～
tags:  #ai #ai agent #vibe-coding #ai-driven development  
author: [Fujio Kojima](https://www.docswell.com/user/Fujiwo)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/LELM1YV37R.jpg?width=480
description: AI駆動開発の概要とコツ、注意点を知ろう (2026年8月版)  AI駆動開発の基礎からエージェント設計、ハーネス・ループエンジニアリング、セキュリティ・理解負債・教育リスクまで包括的に解説。実践的な開発管理と効果測定も紹介。
published: August 17, 26
canonical: https://www.docswell.com/s/Fujiwo/KX2QDY-2026-08-17-130347
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/LELM1YV37R.jpg)

AI駆動開発の歩き方
入門・エージェント・ハーネス・そして3つのリスク
2026年8月
小島 富治雄


# Page. 2

![Page Image](https://bcdn.docswell.com/page/4JMYWNGMJW.jpg)

自己紹介
 小島 富治雄
 @Fujiwo
 福井コンピュータ グループ
 Microsoft MVP (22年目) C#関連


# Page. 3

![Page Image](https://bcdn.docswell.com/page/PJR9YDZL79.jpg)

社内での取り組み
 2018年 『機械学習勉強会』
 2019年
 『AI/ML勉強会 基本編』
 『AI/ML勉強会 IoT編』
 2021年～ 『AI・ML勉強会』 チャンネル (Teams)
 2024年 『生成AI入門 ～人工知能/機械学習とは～』
 2025年
 『AIエージェント勉強会 ～マイクロソフトの最新技術発表を受けて～』
 『AIエージェント開発ハンズオンセミナー』
2


# Page. 4

![Page Image](https://bcdn.docswell.com/page/PEXQG116JX.jpg)

社外での取り組み
 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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/3EK9422GED.jpg)

本日のゴール
AI駆動開発の概要とコツ、
注意点を知る
4


# Page. 6

![Page Image](https://bcdn.docswell.com/page/L73WL44575.jpg)

アジェンダ
 序章: なぜ今、AI駆動開発を整理し直すのか
 第7章: リスク① セキュリティ
 第1章: AI駆動開発とは何か
 第8章: リスク② 理解負債・認知負債
 第2章: AI駆動開発入門
 第9章: リスク③ ジュニアエンジニアの教育
 第3章: コーディングエージェント
 第10章: 効果測定 — 「速くなった」は本当か
 第4章: エージェント指示ファイル
 第11章: トークン節約とコスト設計
 第5章: ハーネス エンジニアリング
 終章: まとめ
 第6章: ループ エンジニアリング
資料
5


# Page. 7

![Page Image](https://bcdn.docswell.com/page/87DKNQQYJG.jpg)

アジェンダ
理解から実践までを5つの観点でたどる
現在地
開発とエージェント
指示と制御
リスク
コストと行動
序章〜第2章
第3章〜第4章
第5章〜第6章
第7章〜第9章
第10章〜終章
最初の一歩
コーディング
エージェント
ハーネス・ループ
組織で守る
次の一歩へ
個人の利用から、チームで制御できる開発へ
アジェンダ
6


# Page. 8

![Page Image](https://bcdn.docswell.com/page/VJPK5LL2E8.jpg)

序章
なぜ今、AI駆動開発を
整理し直すのか
論点は「どう書くか」から
「書かれたものをどう統治するか」へ移った
序章
7


# Page. 9

![Page Image](https://bcdn.docswell.com/page/2EVVPQQXEQ.jpg)

序章
論点は「書けるか」から「統治できるか」へ移った
2025年
2026年
自然言語で
大量に生成されたものを
どこまで書けるか
どう統治するか
開発の主戦場は、生成そのものから評価・統制へ広がる
序章
8


# Page. 10

![Page Image](https://bcdn.docswell.com/page/57GLPWWREL.jpg)

序章
現場の4つの困りごとは、速度だけでは解けない
速いのに終わらない
レビューが追いつかない
ボトルネックが
生成速度が
別の場所にある
検査速度を超える
若手が育たない
請求額が読めない
学ぶ過程を
利用量が
外部委託してしまう
経営上の変数になる
序章
9


# Page. 11

![Page Image](https://bcdn.docswell.com/page/4EQY233YJP.jpg)

第1章
AI駆動開発とは何か
定義と全体像
ボトルネックは、記述から
評価・仕様・観測可能性へ移る
第1章
10


# Page. 12

![Page Image](https://bcdn.docswell.com/page/KJ4WL11Z71.jpg)

AI駆動開発
すべてのソフトウェア開発工程に生成AIを
AIの役割
企画、計画、設計、実装、テスト、運用
エンジニアの役割
Before コードを自ら書く
After 「AIへ的確に指示し、結果を見極める監督」
要件の言語化、全体設計、AI生成物のレビューや最終的な意思決定
11


# Page. 13

![Page Image](https://bcdn.docswell.com/page/LE1YLGGD7G.jpg)

第2章
AI駆動開発入門
最初の一歩とツール選定の観点
最初に決めるのは、AIに任せることではなく
人間が意思決定に専念できる協調関係である
第2章
12


# Page. 14

![Page Image](https://bcdn.docswell.com/page/GEWGVKK8J2.jpg)

AI駆動開発 初期のステップ
要件整理
コード レビューさせる
設計相談
リファクタリングさせる
開発計画を立てさせる
テストケースを作成させる
 (条件を明確にして)
テストさせる
コード生成させる
デバッグさせる
最終判断は人間が行う
13


# Page. 15

![Page Image](https://bcdn.docswell.com/page/47ZL4ZZ9J3.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/YJ6W3ZZDJV.jpg)

AI Native における開発フロー
AI: 連続ループ
コード生成とテストがシームレスに循環し、AIが自律的にエラーを修正
人間の新たな役割
意図・仕様入力 → 結果を確認 → 元の仕様を更新・洗練
プロダクトの価値を最大化
1. 人 意図/仕様
2. AI 設計生成
3. AI コード生成
4. AI テスト生成
5. 人 レビュー
• 人が意図を入力
• 最適な構造を提案
• 実装を自動化
• 検証を自動実行
• アウトプット確認
と仕様更新
15


# Page. 17

![Page Image](https://bcdn.docswell.com/page/GJ5MLWW8J4.jpg)

5つの柱
批判的レビュー
自動デバッグ
承認
完了証明
境界定義
• 生成物を別の
• 問題あり → 原
• 計画、仕様、
• 客観的に「本
• 行ってよい範
AIが「あら探
因分析 → 修正
設計、実装で
当に完了した
囲を予め設定
し」の視点で
→ 再検証
人が承認する
か」を証明
し、安全性確
チェック
を自動化
仕組み
AIが生成
批判的レ
ビュー
問題?
保
自動修正
完了証明
人が承認
16


# Page. 18

![Page Image](https://bcdn.docswell.com/page/9E29LQQV7R.jpg)

仕組みの構築
導く・止めるだけでなく, 直して完了を証明するまでを仕組みにする
ハーネス (方向・主観)
Constitution / Skills - AI に「どう走るか」を事前に設計する
ガードレール (逸脱を止める・客観)
lint / 型 / test / CI / Hooks - 逸脱を機械的に検知・ブロックする
能動品質ループ
役割分離 (生成 ≠ レビュー ≠ 検証) → 自己修復 → 完了証明
17


# Page. 19

![Page Image](https://bcdn.docswell.com/page/D7Y4QWWQEM.jpg)

管理するもの
ドキュメント
仕組みの構築
プロンプト、計画書、仕様書、
設計書
テスト
コード
18


# Page. 20

![Page Image](https://bcdn.docswell.com/page/VENYK992J8.jpg)

ドキュメント管理が肝
常に管理・アップデート
人とAIが読めるものを
MarkDown など
階層化・構造化
曖昧だとぶれる
多過ぎてもぶれる
トークン消費量に注目
19


# Page. 21

![Page Image](https://bcdn.docswell.com/page/Y79PV22DE3.jpg)

言語化が重要
知識を共有する
プロセス
SECIモデル - Wikipedia
20


# Page. 22

![Page Image](https://bcdn.docswell.com/page/G78DP5557D.jpg)

言語化が重要
AI とは形式知をやり取り
言語化が重要!
暗黙知
• 個人の頭や体にある
• 言葉での説明が難しい
• ベテランの勘、職人の技など
形式知
• 文字や数字、図になっている
• 共有できる
• 業務マニュアル、手順書など
21


# Page. 23

![Page Image](https://bcdn.docswell.com/page/L7LM1YY3JR.jpg)

第3章
コーディングエージェント
選定軸は機能だけではない
コスト構造とガバナンス要件を読む
第3章
22


# Page. 24

![Page Image](https://bcdn.docswell.com/page/4EMYWNNMEW.jpg)

第3章
補完型からエージェント型へ、役割の重心が移っている
補完型
エージェント型
入力中の提案を受け、
タスクを受け、探索、変更、検証を
人が作業の流れを主に進める
まとまりとして進める
自律性が上がるほど、権限と承認の設計が選定条件になる
参考: Claude Code・Cursor・GitHub Copilot を徹底比較
第3章
23


# Page. 25

![Page Image](https://bcdn.docswell.com/page/PER9YDDLJ9.jpg)

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


# Page. 26

![Page Image](https://bcdn.docswell.com/page/P7XQG126EX.jpg)

【参考】 コーディング エージェントの比較
 Claude Code・Cursor・GitHub Copilot を徹底比較 — 「コード補完」と「エージェント型」で使い
分けが分かれるAIコーディングアシスタント選択指南 - TechFeed
ツール名
Claude Code
特長
Cursor
VS Code系IDEに深く統合。
文脈理解と改善提案が強い。
GitHub Copilot
高速なコード補完と自然言語→コード生成が得意。
エージェント型。
ターミナル操作や複数ファイル編集を自動化できる。
25


# Page. 27

![Page Image](https://bcdn.docswell.com/page/37K942MG7D.jpg)

第3章
コストは、定額の席数から利用量の予測へ論点が広がる
従来の見方
従量課金が増える見方
利用者数を基準に、
自律実行、試行回数、利用モデルにより
予算を見積もりやすい
費用の変動要因が増える
GitHub Copilotのプラン変更など
参考: github.comでCopilotを使いこなす ～コードの調査、AIレビュー、自律実装をWebブラウザで完結 | gihyo.jp
第3章
26


# Page. 28

![Page Image](https://bcdn.docswell.com/page/LJ3WL4Y5J5.jpg)

第3章
選定軸は、機能比較からコスト構造とガバナンスへ
実行形態
コスト構造
ガバナンス
どこで、どこまで
利用量が増えたときの
権限、承認、監査を
自律実行させるか
予測と上限をどう置くか
どう設計するか
組織が安全に使い続けられるか → ライセンスの確認
第3章
27


# Page. 29

![Page Image](https://bcdn.docswell.com/page/8JDKNQ5YEG.jpg)

第4章
エージェント指示ファイル
指示ファイルは、書き足すものではない
AIが間違える行だけを残す
第4章


# Page. 30

![Page Image](https://bcdn.docswell.com/page/VEPK5LG278.jpg)

第4章
エージェント設計は、3つの層に分けて考える
コンテキスト
ハーネス
ループ
何を渡すか
どんな足場で動かすか
どう反復し、いつ止めるか
出典:プロンプト、ループ、グラフ——AIエージェント設計の「3層構造」を整理する — どの層を選ぶかの判断基準も
第4章


# Page. 31

![Page Image](https://bcdn.docswell.com/page/27VVPQ6X7Q.jpg)

第4章
指示ファイル
CLAUDE.md
SKILL.md
プロジェクト固有の手順とハマりどころ
手続きの標準化
出典: Best practices for Claude Code - Claude Code Docs
第4章


# Page. 32

![Page Image](https://bcdn.docswell.com/page/5JGLPWNR7L.jpg)

第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章


# Page. 33

![Page Image](https://bcdn.docswell.com/page/47QY23QYEP.jpg)

第4章
繰り返す特定作業は `SKILL.md` にする
SKILL.md
--name: verify-change
description: Validate a scoped change
---
1. Run targeted tests
2. Check diagnostics
3. Report evidence
再現可能な手順を、必要なときに呼び出せる形へする
第4章


# Page. 34

![Page Image](https://bcdn.docswell.com/page/KE4WL1NZJ1.jpg)

第5章
ハーネス エンジニアリング
AIを賢くする工夫ではない
AIが間違っても壊れない足場を設計する
第5章


# Page. 35

![Page Image](https://bcdn.docswell.com/page/L71YLG5DJG.jpg)

第5章
ハーネスは、AIの失敗を検知して止める足場である
AIが変更する
決定論的に検査する
失敗を検知して止める
モデルの回答品質に期待するのではなく、失敗しても影響を広げない仕組みを置く
第5章


# Page. 36

![Page Image](https://bcdn.docswell.com/page/G7WGVK58E2.jpg)

ハーネスの例
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


# Page. 37

![Page Image](https://bcdn.docswell.com/page/4JZL4ZN9E3.jpg)

36


# Page. 38

![Page Image](https://bcdn.docswell.com/page/YE6W3Z8DEV.jpg)

【参考】 ハーネス エンジニアリング
 ハーネスエンジニアリングとは何で、何ではないのか 〜作る側のハーネス、使う側の
ハーネス〜
 最近知った「ハーネス設計」という考え方がかなり重要だった #AI – Qiita
 Claude Codeでハーネスエンジニアリングを実践する — 5層の設計パターン
 Claude Codeハーネスエンジニアリング まず抑えるべき基礎知識 - YouTube
37


# Page. 39

![Page Image](https://bcdn.docswell.com/page/GE5MLW98E4.jpg)

第6章
ループ エンジニアリング
プロンプトを書くな
止まれるループを設計する
第6章


# Page. 40

![Page Image](https://bcdn.docswell.com/page/9729LQ2VJR.jpg)

第6章
進化の焦点は、指示から反復の設計へ広がってきた
1
2
3
4
プロンプト
エンジニアリング
コンテキスト
エンジニアリング
ハーネス
エンジニアリング
ループ
エンジニアリング
単発の指示
前提を渡す
実行の足場
評価して反復
第6章
39


# Page. 41

![Page Image](https://bcdn.docswell.com/page/DJY4QWYQ7M.jpg)



# Page. 42

![Page Image](https://bcdn.docswell.com/page/V7NYK9P2E8.jpg)

ループ エンジニアリング
STEP 1. プロンプト
プロンプト → AI が処理 → … の繰り返し
Human In The Loop: 人がループの中

Human On The Loop: 人はループの外から監督
41


# Page. 43

![Page Image](https://bcdn.docswell.com/page/YJ9PV23D73.jpg)

ループ エンジニアリング
STEP 2. 人間が方向付け
1.
プロンプト
2.
コンテキスト
3.
ハーネス
4.
ループ
42


# Page. 44

![Page Image](https://bcdn.docswell.com/page/GJ8DP5M5JD.jpg)

ループ エンジニアリング
1.
プロンプト: 頼み方の設計
2.
コンテキスト: 見せる情報を選ぶ
3.
ハーネス: 制約/足場
4.
ループ: Human On The Loop
(人はループの外から監督)
43


# Page. 45

![Page Image](https://bcdn.docswell.com/page/LJLM1Y33ER.jpg)

ループ エンジニアリング
1.
プロンプト: 頼み方の設計
2.
コンテキスト: 見せる情報を選ぶ
Claud.md
3. ハーネス: 制約/足場
Skill.md
LINT
4. ループ: Human On The Loop
テスト
権限
(人はループの外から監督)
44


# Page. 46

![Page Image](https://bcdn.docswell.com/page/47MYWNDM7W.jpg)

第6章
ループの難しさは、回すことではなく、いつ止めるかにある
止める理由
止める上限
止める判断
目的を満たした
予算・時間・試行回数を
評価できない状態を
差分が残っていない
超えない
人へ戻す
停止条件は、ループの外側から人が設計する
第6章


# Page. 47

![Page Image](https://bcdn.docswell.com/page/P7R9YD4LE9.jpg)

46


# Page. 48

![Page Image](https://bcdn.docswell.com/page/PJXQG1Z67X.jpg)

47


# Page. 49

![Page Image](https://bcdn.docswell.com/page/3JK9428GJD.jpg)

第7章
リスク① セキュリティ
エージェントは「読む」「実行する」の
2方向で攻撃面を広げる
第7章


# Page. 50

![Page Image](https://bcdn.docswell.com/page/LE3WL425E5.jpg)

AI駆動開発のセキュリティ リスク
機密情報や認証情報 (APIキーなど) の流出
連携ツールの権限逸脱 (RAG/MCPリスク)
エージェントがRAG/MCPを介して社内DB、社内リソース、GitHubな
どにアクセスし、機密情報をLLMに読み込ませてしまう
AI が環境を壊す
49


# Page. 51

![Page Image](https://bcdn.docswell.com/page/8EDKNQZY7G.jpg)

セキュリティ対策
セキュリティガイドライン(運用ルール)の制定
利用エディションと契約の確認
 Enterprise 向けか
コード内機密情報/認証キー記載の禁止
RAG/MCPへのアクセス認可
専用の開発環境 (サンドボックス: 仮想・コンテナ環境)
 サンドボックス環境を選択する - Claude Code Docs
50


# Page. 52

![Page Image](https://bcdn.docswell.com/page/V7PK5LD2J8.jpg)

【参考】 リスク① セキュリティ
AIエージェント導入で「セキュリティどうするの?」と聞かれたと
きの技術的な答え方
LLMのコスト暴走と情報漏洩を防ぐ社内Gateway設計:
Azure/AWSガバナンスとLiteLLM実装
(Phase1→Phase2) #Security - Qiita
りなたむ(Ryota)@ITの町医者
: 「生成AI利用ガイドライン」
/ Twitter
51


# Page. 53

![Page Image](https://bcdn.docswell.com/page/2JVVPQ1XJQ.jpg)

第8章
リスク② 理解負債・認知負債
コードは綺麗でも、誰も理解していない
前提が反転したなら、設計の優先順位も反転させる
第8章


# Page. 54

![Page Image](https://bcdn.docswell.com/page/5EGLPW2RJL.jpg)

第8章
「2025年の崖」: 生成量が理解を追い越す
生成
レビュー
保守
AIが変更を素早く
積み重ねる
人が全体像を保てなくなる
意図を説明できない
コードが残る
崖とは、コード量と人の理解の差が短期間で広がる状態を表す
第8章


# Page. 55

![Page Image](https://bcdn.docswell.com/page/4JQY23PY7P.jpg)

理解負債
(LLMによって)
思考はアウトソースできても、
理解はアウトソースできない
54


# Page. 56

![Page Image](https://bcdn.docswell.com/page/K74WL1YZE1.jpg)

責任
責任はAIに転嫁できない
55


# Page. 57

![Page Image](https://bcdn.docswell.com/page/LJ1YLG6DEG.jpg)

第8章
技術負債と理解負債では、遅れるものが逆になる
技術負債
理解負債
先行するもの
先行するもの
人の理解が先行する
コードの生成が先行する
遅れるもの
遅れるもの
コードの整理が追いつかない
人の理解が追いつかない
1992年の技術負債の比喩は、人の理解が先行することを前提としていた
第8章


# Page. 58

![Page Image](https://bcdn.docswell.com/page/GJWGVKW872.jpg)

第8章
認知の放棄は、個人と組織の沈黙から始まる
個人: Cognitive Surrender
組織: 沈黙の共謀
理解の過程をAIへ全面的に委ね、
短期の速度を優先し、
分かったつもりで変更を受け入れる
理解不足を見えないままにする
理解を外注すると、障害時に判断するための前提も失われる
第8章


# Page. 59

![Page Image](https://bcdn.docswell.com/page/4EZL4Z5973.jpg)

第8章
速度は前払い、失敗は後払いになる
前払いされるもの
後払いされるもの
実装と変更の速度
障害時の調査と判断
短期の進捗と見かけの成果
保守時の理解と修正
開発が速くなっても、デリバリーまで速くなるとは限らない
参考: AIが書いたコードは誰も理解していない — 「レビュー負債」という見えないコストを定量化する試み
第8章


# Page. 60

![Page Image](https://bcdn.docswell.com/page/Y76W3Z9D7V.jpg)

【参考】 技術負債・理解負債・認知負債
認知負債 - kawasima
AIコーディングはなぜ後から苦しくなるのか? 技術負債に続く
「理解負債」「認知負債」という新たな落とし穴:Deep Insider
Brief ― 技術の“今"にひと言コメント - @IT
AIで開発速度は上がったのにデリバリーは速くならない —
GitLab調査が示す「制御なき速度は負債」という現実 TechFeed
59


# Page. 61

![Page Image](https://bcdn.docswell.com/page/G75MLWN874.jpg)

第9章
リスク③ ジュニアエンジニアの教育
教育は制度ではなく、
開発プロセスの設計で守る
第9章


# Page. 62

![Page Image](https://bcdn.docswell.com/page/9J29LQ5VER.jpg)

これからの人材育成
コルブの経験学習モデル
1. やってみる
(具体的経験)
4. 新たに試す
(能動的実験)
2. 振り返る
(内省的観察)
3. コツを引き出す
(抽象的概念化)
61


# Page. 63

![Page Image](https://bcdn.docswell.com/page/DEY4QWKQJM.jpg)

これからの人材育成
AIに丸投げすると…
① 経験が積めない ② 振り返れない
→学習できず、成長もしない
1. やってみる
(具体的経験)
4. 新たに試す
(能動的実験)
2. 振り返る
(内省的観察)
3. コツを引き出す
(抽象的概念化)
62


# Page. 64

![Page Image](https://bcdn.docswell.com/page/VJNYK9R278.jpg)

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


# Page. 65

![Page Image](https://bcdn.docswell.com/page/YE9PV2MDJ3.jpg)

ジュニアエンジニアの育成方法
AIを使いつつ人間側に思考・判断・検証の経験を残す設計
まず自らの考えを出させる
 要件・タスク分解・設計案・リスク・テスト方針・仮説や不明点
AIのレビューを見せる
AIの結果をレビューさせる ― 誤りを発見し修正させる
「意思決定」を早い段階から「実環境で」体験させる
 要件定義、設計レビュー、優先順位決定
 障害対応、リリース判断、セキュリティレビュー、振り返り
64


# Page. 66

![Page Image](https://bcdn.docswell.com/page/GE8DP5L5ED.jpg)

ジュニアエンジニアの育成方法
AIを使いつつ人間側に思考・判断・検証の経験を残す設計
まず自らの考えを出させる
• 目的・背景
• なぜそうしたか
AIのレビューを見せる
• なぜこの設計か
• どう実装したか
AIの結果をレビューさせる ― 誤りを発見し修正させる
• 学び・気づき
• 継続的に改善
「意思決定」を早い段階から「実環境で」体験させる
• チームの知恵として再利用・成長
 要件・タスク分解・設計案・リスク・テスト方針・仮説や不明点
 要件定義、設計レビュー、優先順位決定
 障害対応、リリース判断、セキュリティレビュー、振り返り
65


# Page. 67

![Page Image](https://bcdn.docswell.com/page/LELM1YL37R.jpg)

ジュニアエンジニアの育成方法
人とチームが育ち続けるような
AI の利用
66


# Page. 68

![Page Image](https://bcdn.docswell.com/page/4JMYWNMMJW.jpg)

67


# Page. 69

![Page Image](https://bcdn.docswell.com/page/PJR9YDVL79.jpg)

68


# Page. 70

![Page Image](https://bcdn.docswell.com/page/PEXQG1W6JX.jpg)

【参考】 エンジニアに求められる力
 「AI時代、エンジニアに本当に求められる力とは」──株式会社Arcobaleno取締役
前田修宏氏 – TechFeed
 AIの登場で燃え尽き症候群に陥るテック人材が増加--最大の懸念は業務量の増加 -
ZDNET Japan
 AIがコードを書く時代に「コーディングを教える」とはどういうことか — UT Austin
が試みる3つのアプローチ – TechFeed
69


# Page. 71

![Page Image](https://bcdn.docswell.com/page/3EK942VGED.jpg)

第10章
効果測定 — 「速くなった」は本当か
体感と実測のズレを前提に、
測る対象をコード量からデリバリーへ移す
第10章


# Page. 72

![Page Image](https://bcdn.docswell.com/page/L73WL4M575.jpg)

生産性の実態・効果測定
 「AIで速くなった」は本当か——実験では19%遅くなっていたという研究が示す自己
欺瞞のメカニズム - TechFeed
 なぜ、AIで生産性があがっていると錯覚してしまうのか
 エンジニアは、なぜ生成AIで仕事が楽にならないのか #Claude - Qiita
 Vibe Coding、最初は速い。でも後半で急にしんどくなる #AI - Qiita
 AIでコードは速くなったが、出荷は速くならない — GitLabの調査が示す「コーディ
ング高速化の罠」 - TechFeed
71


# Page. 73

![Page Image](https://bcdn.docswell.com/page/87DKNQ6YJG.jpg)

第10章
利用率が高くても、ボトルネックは開発サイクル全体に残る
局所の効率化
全工程で問うこと
実装や下調べは速くなる
レビュー待ち、テスト、リリース、
しかし、生成量だけでは成果を説明できない
運用のどこが制約になっているか
国内の公開事例は、利用率ではなく工程全体を問う必要を示している
第10章


# Page. 74

![Page Image](https://bcdn.docswell.com/page/VJPK5LY2E8.jpg)

第11章
トークン節約とコスト設計
節約とは我慢ではない
渡す情報と判断の配置を設計する
第11章


# Page. 75

![Page Image](https://bcdn.docswell.com/page/2EVVPQGXEQ.jpg)

コスト・トークン節約
1. 会話コンテキストの管理

毎ターン過去のやり取りが入力トークンとして送られるので、会話が長くなると消費が激しくなる

次のタスクに移る前に `/clear`（または CLI の再起動）を行い、会話履歴を一度リセット

コンテキストの要約 (`/compact`) で過去の経緯をAIに要約・圧縮させる

プロンプトは自分で管理
2.
指示ファイル (`.claudeignore`) で読み込み範囲を制限
3.
明確なスコープ指定とプロンプトの工夫

対象ファイルや関数を明示する

最初に「作業方針を挙げて」と指示し、問題がなければ「作業を進めて」と段階を踏む
74


# Page. 76

![Page Image](https://bcdn.docswell.com/page/57GLPW8REL.jpg)

コスト・トークン節約 (続き)
4.

指示ファイル (`Claude.md` や `Skill.md` など) の最適化
長くしない
5.
LLM モデルの使い分け
6.
丁寧語をやめる・やめさせる

7.

genshijin 原始人 Skill
その他
code-review-graph など
75


# Page. 77

![Page Image](https://bcdn.docswell.com/page/4EQY239YJP.jpg)

第11章
システムプロンプトは、ルールを足すより重複を削る
細かく縛る
判断を委ねる
ルールを重ねるほど、
必要な制約と停止条件を残し、
重複と矛盾がコンテキストを消費する
詳細な手順は状況に合わせて選ばせる
指示ファイルは、消しても間違えない行から削る
参考:システムプロンプトを約80%削減できた — Claude 5世代で変わる「ルールを与える」から「判断を委ねる」へのプロンプト設計
第11章


# Page. 78

![Page Image](https://bcdn.docswell.com/page/KJ4WL1XZ71.jpg)

コストの測定
消費トークンを記録する
77


# Page. 79

![Page Image](https://bcdn.docswell.com/page/LE1YLGND7G.jpg)

コスト・トークン節約
 楽しかったコーディングエージェントサブスク時代の終わり
 AIコーディングエージェントのコストを35%削減する「賢いモデルを全タスクに使わ
ない」設計 — Devinがフロンティアモデルとサイドキックモデルをセッション中に動
的に使い分ける仕組みを公開 - TechFeed
 LLM APIのコストを60%削減する4つの技術 — プロンプト圧縮・セマンティック
キャッシュ・CoT剪定・出力長制約を組み合わせた実践ガイド – TechFeed
 システムプロンプトを約80%削減できた — Claude 5世代で変わる「ルールを与え
る」から「判断を委ねる」へのプロンプト設計 - TechFeed
78


# Page. 80

![Page Image](https://bcdn.docswell.com/page/GEWGVK48J2.jpg)

終章
まとめ
全部任せるか、一切使わないか
その二元論から離れる
終章


# Page. 81

![Page Image](https://bcdn.docswell.com/page/47ZL4Z29J3.jpg)

終章
AI駆動開発を貫く、4つのメッセージ
人間の判断を残す
ハーネスで安全にする
承認と説明の責任を
決定論的なセンサーと
AIへ転嫁しない
境界で支える
ループを止められるようにする
速さをデリバリーで測る
停止条件と人へ戻す
コード量ではなく
経路を設計する
本番採用までを測る
終章


# Page. 82

![Page Image](https://bcdn.docswell.com/page/YJ6W3ZVDJV.jpg)

終章
過大評価も過小評価も避け、選択肢を広げ続ける
短期の見方
長期の見方
変化を過大評価し、
変化を過小評価し、
すぐに万能の答えを求めてしまう
学び直しと選択肢を閉じてしまう
AI時代にも銀の弾丸は存在しない
だから、判断を保留して検証を続ける
参考: 2026年のソフトウェア開発を考える（2026/07版） / Agentic Software Engineering 2026-07 Findy Edition - Speaker Deck
終章


# Page. 83

![Page Image](https://bcdn.docswell.com/page/GJ5MLWD8J4.jpg)

まとめ
 序章: なぜ今、AI駆動開発を整理し直すのか
 第7章: リスク① セキュリティ
 第1章: AI駆動開発とは何か
 第8章: リスク②理解負債・認知負債
 第2章: AI駆動開発入門
 第9章: リスク③ ジュニアエンジニアの教育
 第3章: コーディングエージェント
 第10章: 効果測定 — 「速くなった」は本当か
 第4章: エージェント指示ファイル
 第11章: トークン節約とコスト設計
 第5章: ハーネス エンジニアリング
 終章: まとめ
 第6章: ループ エンジニアリング
82


# Page. 84

![Page Image](https://bcdn.docswell.com/page/LE3WL4MGE5.jpg)

83