AI エージェント開発で見えたエンジニアの役割 兒島 祐輔（KOJIMA Yusuke） 

2 このスライドは、登壇時のものから一部修正しております。ご了承ください。 

3 兒島 祐輔 （KOJIMA Yusuke） 出身：埼玉県 所沢市 趣味：読書 活動：AWS案件支援、生成AI活用、DX推進 経歴：エンジニア 8 年生 都内某大学 法学部 法律学科 卒 都内某企業 SES → 現職 最近の出来事: JDLA E 資格で不合格 自己紹介 

4 これからのエンジニアに求められる役割 ✓ “確認と検証” を繰り返す 生成 AI のコーディング速度に人間は追いつかない どんなに生成 AI が発達しても 生成 AI は責任を負わない、責任は人間が負う 

5 生成 AI で “事足りる” ことが増えた • 生成 AI で作った、カッコイイ画面イメージ • 生成 AI で名付けた、イケてる名称 • 生成 AI で開発した、効率的なアプリケーション • 生成 AI で作った、無駄のない資料 ユーザビリティ？ 脆弱性？ 責任境界？ 可用性？ 秘匿情報？ is 本当？ トレーサビリティ？ 保守性？ 後方互換？ ソフトウェア開発の "現場” は慎重 

6 作りたかったもの • 自分の考えや嗜好を理解した AI エージェントアプリケーション（技術的に可能） • Amazon Bedrock AgentCore 長期記憶戦略 Episodic memory の検証 解説は割愛 

7 作ったもの 解説は割愛 

8 すぐ作れた、テストも通った、デプロイもできた、アプリケーションも動くが、 もはやブラックボックス 

9 これからのエンジニアに求められる役割 (再掲) ✓ “確認と検証” を繰り返す 生成 AI のコーディング速度に人間は追いつかない どんなに生成 AI が発達しても 生成 AI は責任を負わない、責任は人間が負う 

10 

11 

12 Spec Driven Development 自然言語による Vibe コーディングを行う際、言語の曖昧さが意図しない実装に繋がっている 仕様駆動型開発 (Specification-Driven) • 自然言語コミュニケーションの “曖昧さ” と仕様書の ”厳密さ” を使い分けることが重要 • Kiro は自然言語を通して、 仕様書にもとにした開発を実現 要件（requirements.md） 設計（design.md） タスク一覧（tasks.md） コーディング 

13 Kiro Steering Kiro（エージェント）実行時、一番最初に読み込むファイル群 • コーディング規約など、適切なルールを Kiro に伝える • .kiro/steering/* に作成 利用シーンの一例 .kiro/ └ steering/ ├ always-baseline.md ├ always-product.md ├ always-structure.md ├ always-tech.md ├ backend-*.md ├ frontend-*.md ├ infra-*.md └ itest-*.md 

14 Kiro Steering 利用パターンは ”Always” の他 ファイパターン一致時の ”Conditional” 、ユーザーが # で指定する “Manual” 

15 Kiro Hooks 様々なトリガーで処理を挟むことができる • File Create • File Save • File Delete • Prompt Submit • Agent Stop • Pre Tool Use • Post Tool Use • Pre Task Execution • Post Task Execution • Manual Trigger 

16 Kiro Hooks AI のコーディングスピードに対して、人間の理解（レビュー品質）が追いつく工夫が必要 利用シーンの一例 File Save • コーディング規約の確認 Agent Stop • 各種ドキュメントの最新化 • セキュリティ品質のレビュー Pre Task Execution • 最初のタスク実施前に、 プロジェクト管理ツールにタスクを一括登録 Post Task Execution • 各タスク実施後に、 プロジェクト管理ツールに作業内容を登録 

17 Pre Task Execution （キャプチャから差替） Task: 1 の実行前に、 API でプロジェクト管理ツールへタスクを一括登録する Outlook Calendar Integration ├── 1. 型定義の追加 ├── 2. バックエンド: Token_Store（tokenStoreService）の実装 ├── 3. バックエンド: Calendar_Service（calendarService）の実装 ├── 4. チェックポイント — 全テストが通ることを確認する ├── 5. バックエンド: calendarTokenハンドラの実装 └── ・・・{割愛} 

18 

19 Post Task Execution （キャプチャから差替） 各タスク完了後、 API でプロジェクト管理ツールへタスクの実施内容を記録する ### 実施内容 - `backend/src/services/calendarService.ts` を新規作成 - `listEvents`: GET /me/calendarView でデフォルト最大50件取得、 $skiptoken によるページネーション対応 - `createEvent`: POST /me/events、 subject/startDateTime/endDateTime の必須バリデーション、開始>=終 了のバリデーション - `updateEvent`: PATCH /me/events/{eventId}、指定フィールドのみ PATCHボディに含める ・・・{割愛} 

20 Kiro が以前の自分（の役割）に置き換わる リポジトリ 以前の自分 PJ管理ツール 要件、設計、タスクの提案と承認 コーディング 作業の記録 パイプライン結果 CI/CD CI/CD 結果含めて レビュー 実装プロセス含めて レビュー 今の自分 ✓ Steering で制御 ✓ Hooks で管理 

21 AI-Driven Development Lifecycle (AI-DLC) 従来の開発手法に ”AI を追加する” ではなく 「AI を中心に AI が開発を主導し、人間がレビュー・承認する」という新しい方法論 “AI” タスク: 能動的な質問・確認と計画の立案 • 大量データの整理と構造化 • カットオフ時点の知識やコンテキストをもとにした生成 “人間” タスク: 状況や検証結果、優先順位などを加味した意思決定 • リスク管理と最終的な責任を持つ • 感覚や深い文脈理解から生まれるコンテキストの記述 

22 これからのエンジニアに求められる役割 (再掲) ✓ “確認と検証” を繰り返す 生成 AI のコーディング速度に人間は追いつかない どんなに生成 AI が発達しても 生成 AI は責任を負わない、責任は人間が負う 

23 Thank you!