--- title: 少人数で複数のAIサービスを育てる、AI駆動経営の実践 ― 人の確認で止まる場所を、絞り切ってみた tags: #ai駆動経営 #claudecode #ai仕様駆動開発 author: [岡崎フトシ](https://image.docswell.com/user/f_uto) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/87DGD3WY7G.jpg?width=480 description: 2026年11月12日「AI駆動経営」勉強会 #4 のライトニングトーク（10分）の資料です。 Claude Code を使った開発で、人の確認で止まる場所を絞り切ったやり方（AI仕様駆動開発）を紹介し、それを経営にどこまで持ち込めるかを考えました。人の介入を「必要」「補修的」「儀式的」の3つに分け、経営者の口ぐせを判断のロジックにしてスキルやフローに組み込む方法をお話ししています。 書籍『AI駆動経営：会社は仕様で動く』にまとめています。 https://feelflow.net/books 株式会社フィールフロウ https://feelflow.net/ published: November 13, 26 canonical: https://image.docswell.com/s/f_uto/5Q2W9J-ai-driven-management-2026-11-12 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/87DGD3WY7G.jpg) 題 少⼈数で複数のAIサービスを育てる、 AI駆動経営の実践 ⼈の確認で⽌まる場所を、絞り切ってみた。 経営には、どこまで持ち込めるか 岡崎 太 株式会社フィールフロウ CTO ／ 2026年11⽉12⽇ ライトニングトーク 1 / 16 # Page. 2 ![Page Image](https://bcdn.docswell.com/page/VJP3X492E8.jpg) ⾃⼰紹介 岡崎 太 株式会社フィールフロウ CTO 少⼈数で、複数のAIサービスを育てています 趣味はムエタイです Xでは @f_uto（岡崎フトシ）で活動しています 今⽇は、Claude Codeを使っている経営者の⽅へ。 2 / 16 # Page. 3 ![Page Image](https://bcdn.docswell.com/page/2EV4LXMXJQ.jpg) Anthropic 公開情報 Anthropic 社内で、1⽇にマージされる変更 約2,500件 2026年5⽉ → 30,000件超 2026年9⽉ Anthropic では、コードを書くことは、もうボトルネックではない。 ⼈の規模に合わせて作られた開発の基盤がボトルネックになった。 （ソース管理・ビルド・CI。ソース管理はその⼀例） 出典：Anthropic「Redesigning source control at Anthropic」（2026年10⽉13⽇） 3 / 16 # Page. 4 ![Page Image](https://bcdn.docswell.com/page/57G1XVGREL.jpg) 著者の提案（⾃社の実例） 私の開発で、やったこと ⼈が⽌める場⾯を絞り切り、 ⼈のコード確認を待たずに、マージまで進むフローを作った。 仕様 → AIが実装 → テスト・ AIレビュー → マージ → ⼈は 動くものを⾒る ⼈の確認を、すべてやめたわけではない。⼈に判断を上げる条件は書いて残す 仕様の⽭盾／権限を超える操作／元に戻せない操作 考え⽅と⼈に上げる条件：岡崎 太、株式会社フィールフロウ ブログ（2026年10⽉14⽇）。運⽤の実物：執筆⽤の指⽰・運⽤ルール（⾮公開。2026年10⽉23⽇時 点） 4 / 16 # Page. 5 ![Page Image](https://bcdn.docswell.com/page/4EQD86XYJP.jpg) 著者の提案（⾃社の実例） AI仕様駆動開発：使うほど、仕組みが育つ 考え⽅ 開発での仕組み 仕様を先に書く ⽬的と、何ができたら完了かの条件を書いてから着⼿する。 AIは、その条件を満たすまで実装・テスト・レビューを進める 条件を照合してからマージする 完了の条件を、AIが⼀つずつ確かめる。 （レビュー&マージ） ⼈に上がるのは、仕様の⽭盾・権限を超える操作・元に戻せない操作 フィードバック蓄積 作業で得た知⾒や⼈の指摘を、そのつど Playbook に⾜す。 （ACE） Playbook は、AIが作業のたびに参照する知⾒の台帳 ワークフロー改善 作業の終わりに、⼿戻りと無駄を記録する。 （振り返り） 同じ問題が繰り返し起きたら、仕組みのほうを直す この仕組みを ff-dev-toolkit として、オープンソースで公開している（Apache-2.0） ff-dev-toolkit：github.com/feel-flow/ff-dev-toolkit。⼈に上げる条件は著者のブログより。⾊の付いた2⾏が、仕組みを育てる循環 5 / 16 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/KJ4Z246Z71.jpg) 当社調べ AI仕様駆動開発、⼈の介⼊をどこまで減らせたか 介⼊を減らしきれなかった 確認待ちを外せた チームA・4⼈ 私・1⼈ ⼈がAIを待たせた時間（1⽇あたり） 0.4〜1.2時間 0.55〜1.18時間 AIを2本以上同時に動かしていた割合 1〜17% 22〜32% PR作成からマージまで（中央値） 2〜20時間 0.0〜0.4時間 指標 • 当社調べ：2026年9〜10⽉。両チームともAI仕様駆動開発を実践。チームAは⼈の承認・レビューが残る運⽤（4⼈）、私はテスト・AIレビューで進み、 ⼈に上げる条件だけを残す運⽤（1⼈） • ⼈数・集計⽅法・作業の中⾝が異なる。品質は⽐べていない。私1⼈の運⽤は、⾃分で測った記録 • 待たせた時間：AIが⽌まってから次の⼊⼒までの空⽩を、10分まで／30分まで数えた幅。同時に動かしていた割合：定義は近いが、抽出⽅法は同じで はない。マージまで：GitHub のマージ済み PR 6 / 16 # Page. 7 ![Page Image](https://bcdn.docswell.com/page/LE1RM4VDEG.jpg) 著者の⾒⽴て 差を⽣む⼀因は、⼈の反応の速さより ⼈の確認で⽌まる場所の数だと⾒ている ⼈の承認で進む ⼈の確認 ⽌める場⾯を絞る テスト ⼈の確認 AIレビュー ⼈の確認 完了 条件のときだけ⼈ 完了 確認を待つ場所がある限り、どれだけ速く読んでも、仕事はそこで⽌まる。 模式図（⽌まる場所の数は実測値ではない） 7 / 16 # Page. 8 ![Page Image](https://bcdn.docswell.com/page/GEW13XL872.jpg) 著者の提案 今⽇の問い 開発では、⼈が⽌める場⾯を絞り切った。 経営には、どこまで持ち込めるか。 今⽇の出典の⾊ 青 Anthropic 公開情報 緑 当社調べ オレンジ 著者の⾒⽴て・提案 8 / 16 # Page. 9 ![Page Image](https://bcdn.docswell.com/page/47ZPV6M9E3.jpg) 著者の提案 経営に置き換えると 例（架空） ⾒積書の作成 AIで10分 部長の承認待ち ここでは、決裁権を持つ⼈を「部長」と呼ぶ 3⽇ 作業は速くなった。会社の仕事は速くならない。 詰まる場所は、作業から承認と意思決定へ移る。 9 / 16 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/YJ6M52ND7V.jpg) 著者の提案 ⼈の確認で⽌まる場所を、3つに分ける 分類 例 対処 必要な介⼊ 仕様の⽭盾、権限を超える判断、元に戻せない判断、価値判断、対 残す。⼈を厚く置く 外的な約束、顧客との信頼関係 補修的な介⼊ AIや部下が迷ったので⼈が補う、前提を毎回説明し直す 仕様で消す 儀式的な介⼊ 押印、転記、確認のための確認、慣例で続く会議 ルールを廃⽌して消す 3分類は著者の提案。儀式的な介⼊は、開発の知⾒から直接導いたものではなく、経営に持ち込むにあたって著者が⾜した分類 10 / 16 # Page. 11 ![Page Image](https://bcdn.docswell.com/page/GJ5ZY258E4.jpg) Anthropic 公開情報 著者の提案 ⼈をなくす話ではない Anthropic 公開情報 著者の提案 新しいソース管理（Scion）を作ったチーム ⼈が⾒るものを、 は、そのシステムへの変更要求を、今もすべ 変える話。 て⼈がレビューしている。ただし、コードを 1⾏ずつ読むのではなく、変更の意図を⾒て 必要な介⼊には、⼈を厚く置く いる。 出典：Anthropic「Redesigning source control at Anthropic」（2026年10⽉13⽇） 11 / 16 # Page. 12 ![Page Image](https://bcdn.docswell.com/page/LE395KNGE5.jpg) 著者の提案 ⼝ぐせを、判断のロジックにする(仕組み化) 部長が毎回⾔っていること 例（架空） 値引きの判断ロジック - 通常：粗利率30%以上なら次へ進む その値引きはダメ → 例外：年間取引1,000万円以上の既存顧客は25%以上なら進む。25%未満 は社長判断 その他：基準を満たさない値引きは差し戻す 組込み：スキルで判定し、フローで⾏き先を分ける 理由・基準・例外・確認⽅法を整理し、判断のロジックにする。 ロジックをスキルやフローに組み込む。 12 / 16 # Page. 13 ![Page Image](https://bcdn.docswell.com/page/8EDGD3WNEG.jpg) 著者の提案 仕組み化に迷ったら、議事録を⾒返す ① 拾う ② 判断基準にする ③ スキルにする ④ 動かして確かめる 議事録・チャット・差し戻 理由・条件・例外・⼈に上 Agent Skillsとしてフローに 基準づくりに使わなかった しから、本⼈も気づいてい げる条件を整理する 組み込み、AIが使って進め 過去の案件で、当時の判断 る と⽐べる（再現テスト） ない⼝ぐせや判断を拾う ずれの原因を確かめ、⼊⼒・スキル・⼈の判断を⾒直す。 直したら、検証⽤の全案件でもう⼀度試す。 使ったスキルと結果を確認し、確かめた範囲から任せる。 検証⽤の案件は基準づくりの前に取り分け、当時の判定結果はAIに⾒せない。 顧客情報など機密データの扱いは、AIに渡す前に決めておく。 13 / 16 # Page. 14 ![Page Image](https://bcdn.docswell.com/page/V7P3X49NJ8.jpg) 著者の提案 確認の考え⽅ → 再現テストで確かめた範囲は、⼈の都度確認を省く。例外に当た る判断は、途中でも⼈に上げる 最後の確認 → まずスキルが基準でチェック。⼈は、⽬的に合っているか、例外 の判断が必要かを確認する それでも⼈が指摘したら → スキルを直す機会。成果物で終わらせず、スキルにも返す ⼯程ごとの確認 「やはり⼈が⾒ないとだめだ」 「スキルを1⾏⾜せる」 ⼯程の確認に戻る 次から同じ指摘は⼈に届かない 14 / 16 # Page. 15 ![Page Image](https://bcdn.docswell.com/page/2JV4LXMY7Q.jpg) 著者の提案 AIに置き換えるのではなく、仕組みを変える 1. 判断基準を仕様に書き、AIが進められる仕組みに変える 2. AIだけで進む範囲が広がり、⼈を増やさなくても複数のサービスが育つ 3. ⼈は、判断と設計、責任を引き受ける場⾯に時間を使い、仕組みを育てる 15 / 16 # Page. 16 ![Page Image](https://bcdn.docswell.com/page/5EG1XVGWJL.jpg) 出典・ご案内 出典・注記とご案内 1. Anthropic 公開情報 Anthropic「Redesigning source control at Anthropic」 2026年10⽉13⽇ https://www.anthropic.com/engineering/redesigning-source-control 2. 3. 著者の提案 岡崎 太「AI開発のボトルネックを、⼈間にしないために」フィー 『AI駆動経営』 会社は仕様で動く この本をはじめ、 ルフロウ ブログ、2026年10⽉14⽇ AI活⽤・開発に関する https://feelflow.net/blog/2026-10-anthropic-source-control-human-bottleneck/ ほかの書籍もご紹介しています。 当社調べ 書籍⼀覧 2026年9〜10⽉、運⽤の異なる2チーム・計5⼈のAI作業記録。⼈ 数・集計⽅法・作業内容が異なり、品質は⽐べていない。当社側は登壇者本⼈ feelflow.net/books 1⼈分。 4. 著者の⾒⽴て・提案 ⽌まる場所の数、介⼊の3分類、⼝ぐせの仕様化、確認の 考え⽅。⾒積書（10分・3⽇）と値引き基準は架空の例。 5. 著者の提案（⾃社の実例） ff-dev-toolkit（オープンソース） https://github.com/feel-flow/ff-dev-toolkit 株式会社フィールフロウ AI仕様駆動開発を軸に、 AI伴⾛コンサルティング・受託開発・ ⾃社AIプロダクトの開発・運営を⾏っています。 feelflow.net 16 / 16