Upgrade to Pro — share decks privately, control downloads, hide ads and more …

AIをマイクロマネジメントしない ~プロダクトと組織を、同じ原則で動かす~

AIをマイクロマネジメントしない ~プロダクトと組織を、同じ原則で動かす~

AIを「優秀な新卒社員」として扱い、マイクロマネジメントせずに自走させる――そのために必要なのは、人や組織のマネジメントと同じ4原則「情報・安全・自走・改善」である、という話をします。

ママリレシートエールの新規事業開発で実践した、Claude Codeを活用したAI駆動開発の事例を紹介。

- 情報を渡す:[モノレポ構成とCLAUDE.md](http://モノレポ構成とCLAUDE.md)・設計ドキュメント群で、人間とAI双方への「オンボーディング」を共通化する
- 安全を守る:PostToolUse HooksとPre-commit Hooks、[CLAUDE.md](http://CLAUDE.md)の禁止事項による物理的・論理的な多重ガードレールを敷く
- 自走させる:役割とスコープで触れる範囲を限定し、業務マニュアル(スキル)で定型フローを任せる
- 改善を促す:Skill-refinerとAuto Memoryで、AI自身に改善ループを回させる

そしてこの構造は、Notion・設計Doc・規約・LT文化・社内スキルリポジトリといった組織運営とまったく同じ。人間は「意思決定」と「方向づけ」に集中し、継続的な仕事はAIが回せる構造へと再設計していく――そんなビジョンをお話しします。

Avatar for shoki-kitajima

shoki-kitajima

May 17, 2026

More Decks by shoki-kitajima

Other Decks in Business

Transcript

  1. Contents 目次 01 自己紹介 SELF INTRODUCTION 02 本日の論旨 THESIS 03

    ママリレシートエールの紹介 PRODUCT INTRODUCTION 04 いかにしてAI駆動で新規事業を開発したか HOW WE BUILT 05 マネジメントとの類似性 META STRUCTURE 06 ビジョン VISION
  2. 自己紹介 北島 翔貴(しょうぽん) 35歳。文系学部卒、学部時代は 自殺の研究 をしていた。 Web広告企業のエンジニアからキャリアをスタート。 数社渡り歩き、フリーランス・SES経営 など、上も下も様々な立場を経験。 現在はコネヒト株式会社にてシニアエンジニア

    。 マネジメント / 新規事業開発のリード / 技術広報 好きなアーキテクチャは クリーンアーキテクチャ 。 好きなものは哲学と筋トレとアルコール。 SENIOR ENGINEER Clean Architecture 哲学 筋トレ アルコール 35 歳 AGE 10 年+ EXPERIENCE KITAJIMA SHOKI
  3. AIをマイクロマネジメントしない 勇気 STEP 01 情報を渡す STEP 02 STEP 03 STEP

    04 AIとうまくやるには、対人間や組織と同様の マネジメントの方法論 が使えるのでは? と思い、 AIを 一人の優秀な新卒の子が入ってきたという前提 でマネジメントしてみた。 本日の論旨 安全を守る 自走させる 改善を促す
  4. APP SERVICE 01 Q&Aコミュニティ ユーザーが悩みを投稿、相談しあうQ&A機能 専門家による回答も期間限定で提供 SERVICE 02 メディア 妊娠・育児などの記事を毎日配信

    専門家監修の記事も多数 SERVICE 03 SNS インスタのハッシュタグ #ママリ の投稿数が1000万件超 #ママ(約670万件)よりも投稿されている ママリについて
  5. ¥ 1コイン = 1円 相当 300コイン 以上から交換可能 ミルク・育児用品 1点あたり 600

    COIN 飲料 1点あたり 20 COIN 日用品 1点あたり 50 COIN 食料品 1点あたり 100 COIN POINT EXCHANGE コインは他社ポイントに交換 RELEASE コイン交換機能は 6月末リリース予定! かんたん3ステップで完了
  6. 04 いかにしてAI駆動で 新規事業を開発したか 情報 ・ 安全 ・ 自走 ・ 改善

    01 自己紹介 02 本日の論旨 03 ママリレシートエールの紹介 04 いかにしてAI駆動で新規事業を開発したか 05 マネジメントとの類似性 06 ビジョン
  7. 📂 モノレポのフォルダ構成例 root/ ├── apps/ # BE/FE, 各サービス │ ├──

    api │ └── web ├── packages/ # BE/FE共有資産 │ ├── eslint-config/ │ ├── config/ │ └── shared/ └── docs/ # 設計・ドキュメント 💡 情報共有のメリット 関連サービスの 全コードを参照可能 READMEや設計ドキュメント が隣接 変更履歴が一元管理 される AIがコンテキストを理解しやすい モノレポ - 情報を渡す │ └── admin ├──.ecspresso/ # サービス毎環境毎 ECS関連定義
  8. 📜 プロジェクトの憲法 AIと新メンバーが共通して守る3原則 📄 CLAUDE.md 1 推測禁止 2 Plan →

    Execute の分離 3 探索コストの可視化 📚 暗黙知をゼロ化する設計書群 AIは暗黙の了解を読めないが、明文化されたルールには極めて忠実 ARCHITECTURE.md DATABASE.md API_SPEC.md ERROR_HANDLING.md NESTJS_PATTERNS.md TYPEORM_GUIDE.md FRONTEND_DESIGN.md FRONTEND_GUIDE.md 🤝 新メンバーが入ってきたら、まず読んでもらうドキュメントを整える。 「人間へのオンボーディング」と「AIへのコンテキスト注入」は同じ。 オンボーディング資料 - 情報を渡す 新メンバーもAIも、まずはここを読むことでプロジェクトの基礎的な作法を 理解する。
  9. 🪝 PostToolUse Hooks Claude Code の Edit 直後に自動発火する自己診断レイヤ post-edit-typecheck.js 型チェックで構造を担保

    post-edit-format.js 自動整形でスタイル統一 post-edit-console-warn.js console.log の消し忘れ検知 STEP 1 Edit → STEP 2 Hook発火 → STEP 3 エラー検知 → STEP 4 AIに返却 → STEP 5 自律修正 🚀 セルフ修正の自律ループ CIや上司に怒られる前にAIの手元で 完結するフィードバックサイクル 人間がレビューする前に直る ✓ AI自身がミスに気づく仕組み ✓ エラーをコンテキストとして理解 ✓ 「直してください」と言う手間がゼロ マネジメントの視点: 「コードレビューの シフトレフト」 — 上司が指摘する前に、CIが回る前に、その場で即座に直る。 ガードレール - 安全を守る 💡
  10. 🛡 Pre-commit Hooks / 物理的ブロック コミット前の自動機密情報検知 1 .env 等の誤コミット防止 2

    APIキー検出(AWS / GitHub / Stripe) 3 パスワードのハードコード検出 4 秘密鍵 BEGIN PRIVATE KEY 検出 5 DB接続文字列(MySQL等)検出 6 Prettier / TypeScript 型チェック 📝 CLAUDE.md 禁止事項 / 論理的制約 AIへのルールベース・ガードレール ✕ console.log 残存禁止(Logger使用) ✕ any 型禁止(unknown 推奨) ✕ TypeORMマイグレーションの直接実行禁止 ✕ Domain層のPOTO順守。FW依存・環境変数禁止 💡 「すり抜け」を許さない多層防御 ガードレール - 多重の防御網 静的解析による 物理的ブロック と、ドキュメントによる 論理的制約 の組み合わせ。 必要に応じてOWASP ZAPなどの脆弱性診断も実施する。 AIが自律的に動くからこそ、安全性の自動担保が不可欠となる。 明文化されたルールに、AIは極めて忠実
  11. PILLAR ① 役割とスコープ エージェントごとに「触れる範囲」を限定 backend apps/api/ frontend apps/web/ infra ecspresso/

    PILLAR ② 業務マニュアル 定型フローのスキル化 1 /fix-issue でIssueをPRへ 3 実装・テスト・PR完結 💡 役割で 境界 を切り、スキルで 質 を担保する。 新メンバーを扱うように、境界内では 「信頼して任せる」 ことで自走力を最大化。 「役割」と「業務マニュアル」の提供 - 自走させる →構造的に事故を未然に防ぐ 2 読解→確認→プラン作成 人間による承認ポイント
  12. 🔄 スキルを育てるスキル /skill-refiner 1. 実装 AIが見落としを検知し自律進化 2. スキル書き換え /skill-refinerがスキルを記録、スキル自体を改善 🧠

    Auto Memory & /handover 3. フィードバック永続化 事故教訓を蓄積 (createQueryRunner禁止等) 4. 知識注入 /handoverスキルで文脈を理解。事故防止 同じミスは二度と繰り返さない。改善プロセスそのものをAIに回させる。 人間が介入し続けず、AI自身の改善サイクル によって自律性を最大化する 1. 実装&レビュー 3. フィードバック永続化 改善ループ - 改善を促す
  13. PRINCIPLE 01 1. 情報を渡す Notion / 設計Doc / 社内ポータルの文化。 AIにコンテキストを渡すのと同義。

    PRINCIPLE 02 2. ガードレールを敷く 規約 / デプロイプロセス / セキュリティ。AIの暴走を防ぐ System Prompt。 PRINCIPLE 03 3. 自走と改善ループ 振り返り → 共有 → 学習の連鎖。組織における Skill-refinerの実装。 🔄 組織版・改善ループの実装 connehito-skills: 知見のリポジトリ化。エンジニア全員が最新知見を共有 LT LT文 化 ▪振り返りで改善アクションを抽出 ▪共有により他人の試行錯誤を疑似体験 ▪組織全体がより洗練された選択肢を取れる 💡 組織にも「振り返り → 共有 → 学習」のループが不可欠 プロダクトにSkill-refinerが必要なように、組織の自律性は 「スキル共有 + LT文化」 で加速する。 組織運営もプロダクト開発と「全く同じ構造」
  14. PILLAR 01 プロダクト開発 WHO AI が書く PILLAR 02 レビュー HOW

    AI + 人間の二重チェック PILLAR 03 知見の流通 WHERE リポジトリ経由でskillsを 全員に自動配布 PILLAR 04 改善ループ WHAT AIの自己改善と人間への フィードバック 💡 人間は「意思決定」と「方向づけ」に集中 継続的な仕事はすべて、AIが回せる構造へと再設計する AI中心の業務フローへ