AI駆動開発をチームに根付かせる - 「1行も書かない」チームがHarnessを育てた1年 -

2026/8/27に開催された「現場を動かすAIエージェント〜製造・リテール・モビリティ各業界の実践〜」での登壇資料です。

https://kinto-technologies.connpass.com/event/400133/

1. AI駆動開発をチームに根付かせる - 「1行も書かない」チームがHarnessを育てた1年 2026/08/27 現場を動かすAIエージェント〜製造・リテール・モビリティ各業界の実践〜 株式会社オルターブース クラウドソリューション部 木村健一郎 Copyright © Alterbooth Inc. All Rights Reserved. 1
2. 自己紹介 株式会社オルターブース クラウドソリューション部 副部長 木村 健一郎(Kenichiro KIMURA) 大学院在籍中に未踏ソフトウェア創造事業に 採択され、その成果を元に設立したスタート アップに20年在籍。 2014年頃からクラウドの世界に触れる中で サーバレスとIoTに魅せられ、JAWS-UG福岡 やSORACOM UG九州のコアメンバーとして コミュニティ活動を行っている。 2020年にオルターブースにジョイン。テッ クリードとしてお客様の支援やプロダクトの 開発に従事している。 家に帰ると9歳の娘と戯れる日々。 AWS Samurai2019受賞 AWS APJ Community Award 2023受賞 SORACOM MVC2020/2023受賞 Copyright © Alterbooth Inc. All Rights Reserved. 2
3. AI 駆動開発、 「 結局どこから始める？」 「AI駆動開発、結局どこから始める？」 Agent Custom Instructions Skills プロンプト エンジニアリング Custom Prompt Multi-Agent ハーネス エンジニアリング MCP 仕様駆動開発 コンテキスト エンジニアリング ループ エンジニアリング 手法や道具は多い。でも「いつ」「何のために」「どれを」使うのかが分からない 約1年間、問題にぶつかるたびに仕組みを進化させてきた過程を話します
4. 1年間の歩み ― 問題が次のStageを生んだ PoC 探索 Stage 1 Harness Stage 2 Team Stage 3 Review Stage 4 肥大化 Stage 5 Multi-Agent 新しい技術が出たからではなく、前の段階で課題があったから次へ進んだ 各Stageで何に困り、何を作ったのかを順に話します
5. 仕様を書けないPoCから、動くものを作って要件を発 見する 発注側 どんなシステムにしたいかが整理できてい ない ▪ 既存業務と課題も整理しきれていない ▪ 仮説 動くものを 作る 開発側 ▪ 対象業務の知識がまだない ▪ 学びながら要件を形にする必要があった 見てもらう フィード バック 要件を発見 「要件を整理 → 仕様を書く → 実装する」が成り立たない。だから、このサイクルを高速に回す 要件とUIは高速に探索し、ソフトウェア設計(アーキテクチャ)にはガードレールを置いた
6. Stage 1 ― AIをHarnessする 人間は1行もコードを書かない。すべてAgentに書いてもらう GitHub Coding Agentを、Public Preview直後から実戦投入した 課題 各自が自由に指示すると、生成されるコードも設計もバラバラになる だからAIを自由に走らせず、Harness（枠組み）を先に作った 要件と Iは高速に探索し、ソフトウェア設計 アーキテクチャ にはガードレールを置いた
7. Agentの 行動を制御するHarness Agentの行動を制御するHarness Custom Prompt Custom Instructions Issue Template Project Structure Architecture・Design 既に配置されたコード プロンプトだけがAIへの指示ではない 構造も設計も既存コードも、Agentにとっては同じContextになる
8. Stage 2 ― Harnessを チームへ展開する Stage 2 ― Harnessをチームへ展開する Before 熟練者がうまく使えば、良いコー ドが生成できる After 誰がAIを使っても、一定の方向へ 収束する 途中参加のメンバーも、同じ環境(Harness)を渡すだけで短期間で合流できた 個人のAI活用を、チームで再現可能な開発プロセスにする
9. Stage 3 ― レビューもHarnessする 課題 コード生成が安定すると、次のボトルネックはHuman Reviewになった レビュー負荷 Agentによる実装 Human Reviewの負荷を大幅に削減 レビュー用Custom Promptでレ ビュー リーダーのレビュー 観点をPrompt化 Copilot Code Review 一般的な問題を 検出 品質 チーム全体のコード品質が安定 人の役割 Human Review 仕様・設計・判断など高レベルなレビューへ 集中 新メンバーもプロセスを共有するだけで、同じ品質基準で開発できる
10. Stage 4 ― 制御を強めたら Harnessが 、 重く なった Stage 4 ― 制御を強めたら、Harnessが重くなった Contextが大きくなる Token使用量が増える 毎回読み込む情報が増える コストに効いてくる 処理時間が長くなる 不要な指示まで読み込む Agentの応答を待つ時間が伸びる 今の作業に関係ない指示も毎回 品質のために作ったHarness自体が、ボトルネックになり始めた
11. Stage 5 ― Multi-Agentへ （ 現在地） Stage 5 ― Multi-Agentへ（現在地） 設計・調査Agent 肥大化した単一のHarness 実装Agent レビューAgent 運用したから見えたこと • • • 何を分割すべきか どのAgentに何を担当させるか どのContextがどの処理に必要か 最初からMulti-Agentにしたわけではない。そして完成形でもない
12. 1 も 原則1： 覚悟― 全員、行 手でコードを書かない 原則1：覚悟 ― 全員、1行も手でコードを書かない 「自分で書いた方が早い」で終わらせない うまく実装できないとき、何を疑うか – Instructionsが悪いのか – Contextが不足しているのか – 採用したソフトウェア設計に問題があるのか – タスクの渡し方が悪いのか – Agentの役割を分割すべきなのか 自分で書かない制約があるから、開発プロセス自体を改善することになる
13. 原則2：責任 ― 生成コードの責任は、指示した人間が 持つ メンバーに求めたこと • なぜこのコードになっているのかを説明できる • この設計の意図は何かを説明できる • なぜこのSoftware Designを選んだのかを説明できる • Reviewの指摘が本当に正しいかを自分で判断する 分からないときは、自分で書くのではなく、分かるまでAIに質問して理解する 全部AIに書いてもらう。でも、全部AIに委ねない。
14. AI 駆動開発で 、人はどう 育ったか AI駆動開発で、人はどう育ったか 育ったとは言い切れないもの 確かに育ったもの 何もない状態から、自分の手でコードを書く 力 ▪ コードを読んで理解する ▪ Software Designを理解し、選ぶ ▪ AIの生成コードを評価する ▪ 自分の選択を説明する これが正解かはまだ分からない。 ただ、これからのAI時代、「設計を考え、選び、判断する力」の価値は上がる
15. まとめ ― AI駆動開発は、一段ずつ進化させる PoC 探索 Harness 制御 Team 再現 Review 標準化 Multi-Agent 分割 原則1：コードは全部AIに書かせる 原則2：でも、責任と判断は人間が持つ Now 改善中
16. 「自分たちのチームは、今どの段階にいるか」 「いきなり完成形を持ち込む必要はない」 「今の課題を解決するために、AIへの委譲とHarnessを一段ずつ進化させる」 「AI駆動開発を根付かせるとは、AIと一緒に開発できるチームとプロセスを育てること」 みなさんが次に解決すべき課題は何ですか？