Inside the collaboration paradox -AI駆動開発とアジャイル開発と60%と20%とハーネスと私-

2. Naoki Yokomachi / 横町 直樹 KDDI アジャイル開発センター株式会社 ソフトウェアエンジニア AWS Community Builders : AI Engineering 2026 Japan All AWS Certifications Engineers 最近の趣味：料理 個人開発しているエージェントやOSS、ガジェット系の アウトプットをしているのでZennも見てね！ https://zenn.dev/yokomachi
3. そのままではAIに任せきれないことは ハーネス未整備のサイン
4. DEFINE ─ ハーネスとは ハーネスとは、 AIエージェントができることを制約し（Constrain） 、 何をすべきかを伝え（Inform） 、 正しく実行できたかを検証し（Verify） 、 誤ったときに修正する（Correct）こと OPENAI ハーネスのあらゆるコンポーネントには、 「モデル単体ではこれができないはずだ」 という仮定が織り込まれている ANTHROPIC モデルが生の知性を提供する一方で、その知性が どれだけ効果的に適用されるかを形作るのがハー ネス。ツール、コンテキスト、ワークフローはハ ーネスによってオーケストレーションされる。 GITHUB AIエージェントハーネスとは、大規模言語モデル （LLM）を包み込み、単にプロンプトに応答する だけでなくタスクに対して行動できるようにする ソフトウェアインフラである。 エージェント = モデル + ハーネス。 DATABRICKS モデルでないものは、すべてハーネスである。 ハーネスとは、モデルそのもの以外の、あらゆる コード・設定・実行ロジックのことである。 LANGCHAIN I f y o u ' r e n o t t h e m o d e l , y o u ' r e t h e h a r n e s s . このLT での定義 Harness engineering: leveraging Codex in an agent-first world | OpenAI Harness design for long-running application development | Anthropic Evaluating performance and efficiency of the GitHub Copilot agentic harness across models and tasks | GitHub Blog What is an AI Agent Harness? | Databricks Blog The Anatomy of an Agent Harness | LangChain Blog
5. 1PBIを取ってから終わらせるまでを巡るツアーへ 各フェーズでどうAIを組み込んでいるかを⾒ていきます 要件・UI 設計 実装 レビュー ドキュメント
6. BEFORE AFTER STATION 1 ─ 要件・UI Claude Design / Claude Code モック作成は 画面・機能のモックを作ってチーム内外で共通認識を作る 実装 → レビューで認識ズレが発覚 → 手戻り Claudeでモックを作る →デザイナー＞PO＞ステークホルダー の3段レビュー →要望を引き出したり認識を握る トークンに余裕がある＆新規画面はClaude Design 、既存画⾯への変更はClaude Code デザイン資産が貯まってきたのでClaude Design にデザインシステムを連携してモック作成の速度と品質の向上を企んでいる AC は議事録から生成 画面や機能を含むPBI のAC が埋まっていないこともある Confluence に貯まっている議事録やSlack などからPBI のAC や前提条件、コンテキストをClaude Code で抽出、生成する 要件・UI 設計 実装 レビュー ドキュメント
7. 設計はエージェントとのペアプロで詰める 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.　 要件・UI 設計 実装 レビュー ドキュメント
8. FLOW １ PBI（Jira）のURLをSuperpowersに渡す → brainstormで設計 → spec出力 → writing-plansでタスク計画 → subagent-driven-development で実装 　：CCはauto mode 　：SubAgent形式でメインコンテキストは汚さず実装 　：TDDとセルフレビューを1Taskごとに実行 → finishing-a-development-branchで後処理 FLOW ２ ｛ STATION 3 ─ 実装 実装はエージェントに任せて別タスクを並行 実装はゴールまで自律的に動くので、 その間に次のPBI準備やPRのレビューなどを並列実行 次PBIの brainstorming 他メンバーの PRレビュー 打ち合わせ 要件・UI 設計 実装 レビュー ドキュメント
9. FLOW １ PBI（Jira）のURLをSuperpowersに渡す → brainstormingで設計 → writing-plansでタスク計画 → subagent-driven-development で実装 　：CCはauto mode 　：SubAgent形式でメインコンテキストは汚さず実装 　：TDDとセルフレビューを1Taskごとに実行 → finishing-a-development-branchで後処理 FLOW ２ ｛ STATION 3 ─ 実装 実装はエージェントに任せて別タスクを並行 実装はゴールまで自律的に動くので、 その間に次のPBI準備やPRのレビューなどを並列実行 次PBIの brainstorming 他メンバーの PRレビュー 打ち合わせ spops : SuperpowersをラッパーするオリジナルSkill Superpowers Skillsの何を使えばいいのかを解決し、とりあえず spopsを叩けばエージェント主導でJiraのURLを要求したりする 要件・UI 設計 実装 レビュー ドキュメント
10. 二つ目のタブではプロジェクト外の作業 STATION 3 ─ 実装 実装はエージェントに任せて別タスクを並行 並列実行にはgit-worktree （私は）Ghostty + tmuxでタブやペインでセッションを監視 要件・UI 設計 実装 レビュー ドキュメント ペイン① : 実装セッション ペイン② : レビューセッション ペイン③ : lazygitでGit操作
11. STATION 3 ─ 実装 実装はエージェントに任せて別タスクを並行 並列実行にはgit-worktree （私は）Ghostty + tmuxでタブやペインでセッションを監視 要件・UI 設計 実装 レビュー ドキュメント 二つ目のタブではプロジェクト外の作業 worktree-start / list / end : worktreeを管理するオリジナルSkills 渡したPBIの番号でworktree名を作り、新規のtmuxペインを作って Claude Codeのセッション開始までやる ペイン① : 実装セッション ペイン② : レビューセッション ペイン③ : lazygitでGit操作
12. STATION 4 ─ レビュー AIと⼈間の多段レビュー FLOW →実装 　→ Superpowers標準のセルフレビュー → Push 　→ /self-review Skillで設計と実装の突合やテストカバレッジ、コーディング規約のチェック → Pull Request 　→ /review-pr Skillでサブエージェントによるコードレビューし、PRに注意ポイントや指摘をコメント 　→ 他のメンバーからApprove必須。各メンバーはローカルで/reivew-prしつつ、自分自身でもレビュー まだ人間のレビューを必要とするところは多い。 特にドメインロジック的な部分や、UIデザインまわり ここはハーネスがまだ弱いが、特にUIについてはデザインシステムやデザイン用Skillを整備しているところ 要件・UI 設計 実装 レビュー ドキュメント
13. 要件・UI 設計 実装 レビュー ドキュメント STATION 5 ─ ドキュメント Specは実装時のコンテキストとして一時保管 仕様は別途ドキュメントやソースコードを直接参照する AI用ドキュメント Spec ソースコード／API設計／DBスキーマ ソースコードそのものが仕様・設計書という前提で、 AI向けの資料としてAPI設計やDBスキーマをリポジトリに同梱 人間用ドキュメント 人間用ドキュメント プロダクト概要、環境設定、簡易的な設計書、 運用系の手順書、開発Tips、議事録、技術検証の記録、など 上記は一つのプラットフォームでまるっと管理 →必要な時はMCPでエージェントにコンテキスト注入 これの継続的な最新化と活用が今後のハーネス作りの前提か →SSOT（Single Source of Truth） PBI ごとのセッションコンテキストであり、FIX した仕様と思い込 んで古いSpec を参照してしまうとContext Rot に繋がる。今は 大した量じゃないのでほったらかしだがそのうち定期的にアーカ イブするつもり。
14. 60% 0~20% →
15. "AI serves as a constant collaborator, but using it effectively requires thoughtful set-up and prompting, active supervision, validation, and human judgment" — 効果的に使うには、丁寧なセットアップと⼈の関与が要る Source: Anthropic, 2026 Agentic Coding Trends Report (Foreword) AIは開発者の仕事の 完全に手放しで で使われているが までしか委任できていない Anthropic はこれを "The collaboration paradox"と呼ぶ 協 働 の パ ラ ド ッ ク ス 60% 0~20% →
16. この鍵こそ、AIに任せきれない領域にある ── ハーネス Inside the collaboration paradox 完全に任せられる 〜20% 〜60% 協働はするが完全委任はまだ 残り40% AIの導入がまだ or できない | 0 | 20% | 60% | 100% 完全委任のラインを引き上げる AIの導入検討 or 人間にしかできない領域に集中 ハーネスエンジニアリングの目的とは、 AIを盲信せず、AIを使う私たち自身と私たちが作ったハーネスを信じて 完全委任する領域を広げ、一方で真に人間が必要とされる領域に集中すること
17. THANK YOU | 0 | | | 100% 今日までの20% つぎの60%へ