AI駆動開発_ワークフロー設計

Claude Codeで考える AI駆動開発のしくみづくりワークショップ　セッション

Transcript

1. 1 W O R K S H O P Claude Codeで考える AI駆動開発のしくみづくり セッション① AI駆動開発におけるワークフロー設計 Context Harness Loop Human in the Loop AIに仕事を任せる“仕組み”を考える 2026.07.12 mae616
2. 2 は じ め に 本イベントは、正解や公式情報を学ぶ場ではなく、 個人の知識やノウハウを実験・共有する場です。 × 正解を教わる場 公式情報や唯一の正解を学ぶことが目的ではありません。今日の 内容も「一つのやり方」です。 ✓ 実験・共有する場 それぞれの知識やノウハウを持ち寄り、試し、分かち合う場です 。気軽にアウトプットしていきましょう。
3. 3 今 日 の ゴ ー ル 本ワークショップで設計するのは、アプリではなく、 「AI駆動開発のしくみ」です。 × アプリそのもの 特定のコードや画面を完成させることが今日の目的ではあり ません。 ✓ AI駆動開発のしくみ AIに仕事を任せるためのワークフロー ── コンテキスト・ 判断軸・手順の設計に取り組みます。
4. 4 0 自己紹介 @ mae616（まえ） フリーランス準備中 運営参加 AI駆動開発 / AIAU X（旧Twitter） @mae616_ 普段やっていること 開発・設計・ディレクション。AI駆動開発を「開発」だけでなく、営業活動や自己管理も含 めた持続可能な仕組みにするための試行錯誤をしています。 AIとの関わり ・Claude Codeを活用した開発 ・AI駆動開発のワークフロー設計・改善 ・AIイラスト・AI音楽における、感性やデザインのコンテキスト化の実験 ・デザイン・体験設計を重視したアプリ開発の試行錯誤 ・技術同人誌の執筆・知見の発信 → 海外のYouTubeや技術コミュニティを中心に、最新情報をキャッチアップしています。
5. 5 0 「AI駆動開発のしくみ」って何？ AIが自律的に開発タスクを進められるように設計された、仕組みのことです。 人が設計・提供する ✓ 目的 何を達成したいか ✓ 必要な情報 与えるべき資料・前提 ✓ 品質基準 どのレベルで完成とする か AI駆動開発のしくみ Skill 例：/plan・/spec Skill 例：/implement・/review 調査・設計 情報収集・仕様検討 実装 コード・テスト作成 レビュー・改善 品質確認・フィードバック ↺ 必要に応じて繰り返し コンテキスト 仕様・制約・コードベース 判断軸 品質基準・優先順位・規約 手順 チェックリスト・自動化 AIモデル（Claude / GPT など） ─ 推論・生成・判断のエンジン 成果物として得られる 完成した アプリ 動くソフトウェアと、品質 確認の結果が手に入る → AIモデルだけでなく、「コンテキスト」「判断軸」「手順」を含めた “AIが仕事をする仕組み” を設計します。
6. 6 0 「AI駆動開発のしくみ」をつくると何がいいの？ 速 開発効率 ・指示を毎回ゼロから考えなくてよい ・試行錯誤を減らせる 質 品質 ・品質基準を統一できる ・結果の再現性が高まる 共 チーム開発 ・ワークフローを共有できる ・Skillsやルールを再利用できる 費 コスト ・開発工程を予測しやすくなる ・モデル利用量（クレジット）を抑えやすい → 開発を “個人技” から “再現可能なプロセス” へ変えられます。
7. 7 S E C T I O N 1 AIとは？ まず、AIが「知っていること」と「できること」を押さえる。
8. 8 1 AIは何を知っているのか AIは汎用的な知識を持っている。でも── 知ってる ✓ 一般知識 言語・歴史・地理・日常知識 ✓ 専門知識 開発をはじめ、多種多様な分野の知識 ✓ 公開された技術情報 OSS・ドキュメント・技術記事 ✓ 安全性・ポリシー Claudeの憲法・安全ガイドライン 知らない＝渡すべき情報 × 最新情報 知識カットオフ以降の出来事・新技術 × 業界・現場の文脈 細かな商習慣・業界文化・暗黙の前提 × 自社・チームの文脈 組織・方針・開発規約・チームの手順 × プロジェクトの文脈 要件・制約・品質基準・優先順位 → だから、AIに必要な文脈を “設計” して渡す。 足りない情報を仕組みに組み込むことで、チームの知識として再利用できるようになる。
9. 9 S E C T I O N 2 AIエージェントの設計パターン 流行してきた言葉の変遷から、設計の考え方の広がりを追う。 Vibe Coding → Context Engineering → Harness Engineering → Loop Engineering ※ Harness / Loop Engineering は比較的新しい用語で、定義には揺れがある。一般には Prompt Engineering を起点に語られることも多い。
10. 10 2 Vibe Coding 会話のノリと勢いで、まず動くものを作るスタイル。 思いつき 指示 生成 確認 また指示… ✓ 特徴 ・まず動くものを作れる ・試行錯誤のスピードが速い ・プロトタイプ作りに向く × 課題 ・品質や再現性は別問題 ・成果が人と偶然に依存しやすい ・同じ結果を再現しにくい ！ 今も有効な場面 ・言語化されていない判断や作業には、 Vibe Coding的なフィードバックスタイル が今も有効 → スタート地点としては優秀。ただし “仕組み” にするには、次の設計が必要になる。
11. 11 2 Context Engineering AIが判断するための “材料” を、ファイルとして整備する。 コンテキスト（AIに渡す判断材料）の例 Rules 行動規範・制約 Knowledge ドメイン知識 設計書 構造・方針 ADR 意思決定の記録 README 全体像・使い方 仕様書 要件・振る舞い AI AIの判断材料になる ・アプリに関わる一貫した情報をファイル化する ・セッションをまたいで引き継ぐ情報もファイル化する ・AIはこれらを参照して、判断・実装する → 現在も、コンテキスト管理の基本的な考え方として使われている。 Note：「プロジェクトで一貫させたいコンテキストはファイル化する」という、コンテキスト管理の仕組みを確立した面もある。
12. 12 2 Harness Engineering AIが安定して作業できる “実行環境（ハーネス）” を設計する。 AIの作業 ハーネスが支える 毎回同じ品質の成果物 ① 判断軸・手順の整備 ・SkillsやCommandsで、判断軸・手順・ タスクを定義する ② 自動チェック ・hooksでフォーマット・Lint・自動テス トを実行（CI/CDやScriptsの実行を含む ） ③ 品質・検収チェック ・SkillやWorkflowで品質チェック・検収 チェックを組み込む → AIが毎回同じ品質で作業できるようにする。
13. 13 2 Loop Engineering AIが自分で状態を確認し、次の行動を判断できるようにする。 これまで ── 人がループを回す 判断するのは：人 コマンドを実行 人が判断 次へ進む？ 手戻りする？ 次のコマンドを実行 手戻り（やり直し）の指示も、毎回人が出す Loop Engineering ── AIがループを回す 判断するのは：AI（判断基準を渡しておく） コマンドを実行 AIが判断 判断基準にもとづき、人の判断なしで 次のコマンドをAIが実行 ↺ 手戻り（ループ）もAIが自分で決める ※ 判断に迷うときだけ、人へ確認する → 人が回していた「進む／手戻りする」の判断を、判断基準ごとAIへ渡す。 より長時間、人の介入なしで作業を続けられるようになる。
14. 14 S E C T I O N 3 人間の判断をどこで挟むか？ 自動化は「ゼロか100か」ではなく、関わり方のグラデーション。 Human in the Loop Human on the Loop Human out of the Loop
15. 15 3 人の関わり方は、3段階のグラデーション どこに人間の判断を残すかを、意図して設計する。 人の関わり：多い 少ない Human in the Loop 人が “毎回” 判断する ・レビュー・承認・仕様変更 ・人間の判断を残す場所を決める Human on the Loop AIが主体。人は監視する ・基本はAIが進める ・異常や迷いのときだけ介入する Human out of the Loop 人は関与しない（完全自動化） ・定型処理・CI・テスト・ビルド ・迷いのない作業から自動化する → 「ゼロか100か」ではなく、工程ごとに関わり方を選ぶ。 各パターンの詳細は、巻末のAppendixを参照。
16. 16 3 中まとめ：開発フロー設計テクニックの全体像 エージェント設計パターン Context 判断材料を用意する Harness AIをどう動かすか整える Loop 状態を見て次を決めさせる 人はどこで判断するか Human in the Loop 人が毎回判断する Human on the Loop AI主体。人は必要時のみ介入 Human out of the Loop 完全自動化 → この2つの軸の組み合わせを、自分たちの開発に合わせて選ぶのが「ワークフロー設計」。
17. 17 S E C T I O N 4 なぜ自分で開発フローを作るのか？ 便利な既製の仕組みがあっても、自作する理由。
18. 18 4 なぜ自分で開発フローを作るのか Claude Code には、便利な仕組みがすでにある /goal /loop …など でも、チームごとに違う ── 目指す品質 SOLID原則をどこまで重視するか レビューの場所 どの工程で人が確認するか 人の判断の置き方 Human in the Loop をどこに置くか 開発で「求めるもの」も、人や会社で違う ── 品質 / 速度 / 再現性 / 保守性 / クライアントの本当のニーズ / 伴走での改善。 この優先順位の違いが、そのまま開発フローの違いになる。 だから ── 自分たちの判断軸をAIへ渡すために、開発フローを自分で作る。
19. 19 Q U E S T I O N 開発フローを作るにあたって、考えること ここからは、あなた自身への問いです。
20. 20 Q U E S T I O N 1 あなたや、あなたの会社にとって、 「良い開発・良い設計」とは何ですか？ 考えるヒント ・AIによって変わるのは「AIにどう仕事を任せるか」。どんなアプリを作るか、は変わっていない。 ・AI駆動ではSOLID原則を重視しない開発もある。一方で「人間のミスを減らす手法」と 「AIのミスを減らす手法」は似ている、という見方もある。 → あなたや、あなたの会社は、どういう手法を取りますか？
21. 21 Q U E S T I O N 2 AI駆動開発が当たり前になった時代に、 何をあなたや、あなたの会社の強みにしますか？ 品質 品質の高さにこだわる 例：ウォーターフォール型 ── 工程と品質基準を先に固めて進める 本当のニーズ クライアントが本当に求めるものにこだわる 例：プロトタイプ型 ── 試作を重ねて “欲しいもの” を探る 伴走 開発中のフィードバックや試行錯誤にこだわる 例：アジャイル型 ── 作る・見せる・直すを回す 独自性 自分たち独自の何かにこだわる → あなたの会社だけの開発フローを設計する → その「こだわり」が、あなたのワークフロー設計の軸になります。
22. 22 A P P E N D I X 参考資料：Human in / on / out of the Loop 人の関わり方3パターンの詳細。ワークショップ中の参考にどうぞ。
23. 23 A Human in the Loop 人が “毎回” 判断に関わる。 人の関わり： Human in the Loop Human on the Loop Human out of the Loop 多い ← → 少ない AIが作業 人が判断 AIが次の作業 1 レビュー 成果物の内容を人が確認する 2 承認 先へ進めてよいか人が決める 3 仕様変更 方向転換の判断は人が下す → 「人間の判断を残す場所」を、意図して設計する。
24. 24 A Human on the Loop 基本はAIが進める。人は監視し、必要なときだけ介入する。 人の関わり： Human in the Loop Human on the Loop Human out of the Loop 多い ← → 少ない AIが連続して作業を進める（ループ） ↺ 人が監視（ダッシュボード・通知など） 監視する 進み方と結果を見守る 必要なら介入する 異常や迷いが出たときだけ手を入れる 基本はAIが進める 通常時は人は手を動かさない → 人は “見守る側” に回り、介入を例外にしていく。
25. 25 A Human out of the Loop 人が関与しない、完全自動化できる領域。 人の関わり： Human in the Loop Human on the Loop Human out of the Loop 多い ← → 少ない トリガー コミット・定時実行など 自動実行 人は関与しない 結果を通知 成功・失敗が知らされる 完全自動化しやすいものの例 ✓ 定型処理 ✓ CI ✓ 自動テスト ✓ ビルド → 迷いのない定型作業から、自動化を進めていく。