正しさだけではプロジェクトは進まないから | Become an AI Agent Orchestration Engineer

Transcript

1. yokomachi@dev $ whoami naoki yokomachi -- dev $ cat agenda.txt 正しさだけではプロジェクトは進まないから $ ./start Become an AI Agent Orchestration Engineer 2026/08/25
2. Naoki Yokomachi / 横町 直樹 アジャイル開発センター株式会社 ソフトウェアエンジニア KDDI AWS Community Builders : AI Engineering 2026 Japan All AWS Certifications Engineers 最近の仕事：とある報告業務のシステム化に伴うAIプロダクト開発
3. AI駆動開発（AIDD: AI-Driven Development） Vibe Coding 仕様駆動開発（SDD: Spec-Driven Development） ハーネス／ループエンジニアリング etc. などの手法・定義は置いといて… 要件・UI 設計 現場の実践的／具体的なAI活用の事例と、 特に今エンジニアに求められるスキルの話をします 実装 レビュー
4. 要件・UI STATION 1 設計 実装 レビュー ─ 要件・ U I 画面・機能のモックを作ってチーム内外で共通認識を作る BEFORE 実装 → レビューで認識ズレが発覚 → 手戻り AFTER Claudeでモックを作る →デザイナー＞PO＞ステークホルダー の3段レビュー →要望を引き出したり認識を握る モック作成は Claude Design / Claude Code トークンに余裕がある＆新規画面はClaude Design、既存画⾯への変更はClaude Code デザイン資産が貯まってきたのでClaude Designにデザインシステムを連携してモック作成の速度と品質の向上を企んでいる AC は議事録から生成 画面や機能を含むPBIのACが埋まっていないこともある Confluenceに貯まっている議事録やSlackなどからPBIのACや前提条件、コンテキストをClaude Codeで抽出、生成する
5. 要件・UI STATION 2 設計 実装 レビュー ─ 設計 設計はエージェントとのペアプロで詰める Superpowers Claude Code Plugin 対話による設計・実装とセルフレビューのイテレーション 以下の開発フローが Skills として定義 Brainstorm → Spec → Plan → SubAgented TDD → Self Review 特に Brainstorm が最高！ エージェントとの会話で、頭の中の散文的な設計の整理ができたり、 設計判断を選択する中で漏れていた要望や落とし穴に気づける 人間同士のモブプロはやっていない ※ 随時 Spec をベースにメンバー間で相談 ※dev メンバーが少ないのでこれでも回っている バス係数 ≒ dev人数 バス係数：何人バスに轢かれたらプロジェクトが⽌まるか PBIは完全に優先度順 → 分野横断化・非属人化 AI用の詳細設計をリポジトリに同居 →セッションを跨いでもAIがオンボーディング 誰がどこからでもタスクを始めやすく 運用系のSkillsもリポジトリに同居 →PRのテンプレート、Dev環境へのデプロイ、 レビューの手順、運用中のログ分析、etc.
6. 要件・UI STATION 3 設計 実装 レビュー ─ 実装 実装はエージェントに任せて別タスクを並行 FLOW １ PBI（Jira）のURLをSuperpowersに渡す → brainstormで設計 → spec出力 → subagent-driven-development で実装 ：CCはauto mode ：SubAgent形式でメインコンテキストは汚さず実装 ：TDDとセルフレビューを1Taskごとに実行 → finishing-a-development-branchで後処理 ２ ｛ → writing-plansでタスク計画 FLOW 実装はゴールまで自律的に動くので、 その間に次のPBI準備やPRのレビューなどを並列実行 次PBIの brainstorming 他メンバーの PRレビュー 打ち合わせ
7. 要件・UI STATION 4 設計 実装 レビュー ─ レビュー AIと⼈間の多段レビュー FLOW →実装 → Superpowers標準のセルフレビュー → Push → /self-review Skillで設計と実装の突合やテストカバレッジ、コーディング規約のチェック → Pull Request → /review-pr Skillでサブエージェントによるコードレビューし、PRに注意ポイントや指摘をコメント → 他のメンバーからApprove必須。各メンバーはローカルで/review-prしつつ、自分自身でもレビュー まだ人間のレビューを必要とするところは多い。 特にドメインロジック的な部分や、UIデザインまわり ここはハーネスがまだ弱いが、特にUIについてはデザインシステムやデザイン用Skillを整備しているところ
8. | 要件・UI | 設計 | 実装 AI 人間 Q.エンジニアって、要る？ レビュー
9. A. エンジニアは必要 だが、その役割はもう不可逆的に変わりつつある →ただしそれは、 「AIは間違うから、信用できないから人間のチェックが必要」 という意味ではない むしろAIは大体正しいことを言う
10. 一般化された判断軸 AIの提案する正論・ベストプラクティス プロジェクトにおける判断軸 チームの習熟領域 開発環境の都合 他プロジェクトとのリソース共有／分離 セキュリティポリシー 速度・性能 PoCか？本格実装か？ 拡張性／可用性 タスクの分解可能性 リリーススケジュール リソース・コスト ステークホルダーの期待値調整 運用保守性 可用性 メンバーの休暇日程 移行 etc. “正しさ”は必ずしもプロジェクトを進めない 「コードを速く書けること自体は、価値を届けていることを意味しない」 Source: DORA 2026, The ROI of AI-assisted Software Development
11. プロジェクトを俯瞰し 技術的知見とビジネス的経験則から 最適な設計判断を下す A I A g e n t O r c h e s t r a t i o n E n g i n e e r AIをオーケストレーションするエンジニア "make human expertise count where it matters most（最も重要な場面で、人間の専門知識を最大限に活かす）" Source: Anthropic, 2026 Agentic Coding Trends Report
12. Claude Codeがリリースされてまだ１年半 開発の進め方は不可逆的に変わった 今回紹介したAI活用事例もここ半年で導入したばかりだし 現在進行形で改善を回している 学ぶべきは二つの地力 ハードスキル：ソフトウェア工学 / AIオーケストレーション ハーネスエンジニアリング⇨ループエンジニアリング⇨グラフエンジニアリング⇨次は？ ソフトスキル：マネジメント / 交渉・折衝力 / 問題解決能力
13. 一般化された判断軸 AIの提案する正論・ベストプラクティス プロジェクトにおける判断軸 チームの習熟領域 開発環境の都合 他プロジェクトとのリソース共有／分離 セキュリティポリシー 速度・性能 PoCか？本格実装か？ 拡張性／可用性 タスクの分解可能性 リリーススケジュール リソース・コスト ステークホルダーの期待値 運用保守性 可用性 移行 技術要素の相性 etc. “正しさ”は必ずしもプロジェクトを進めない 「コードを速く書けること自体は、価値を届けていることを意味しない」 Source: DORA 2026, The ROI of AI-assisted Software Development
14. 正しさだけではプロジェクトは進まないから Become an AI Agent Orchestration Engineer チームの習熟領域 開発環境の都合 セキュリティポリシー リソース・コスト THANK YOU 他プロジェクトとのリソース共有／分離 速度・性能 PoCか？本格実装か？ 拡張性／移行性 タスクの分解可能性 リリーススケジュール ステークホルダーの期待値調整 運用保守性 可用性 メンバーの休暇日程 移行 etc.