コネヒト開発者ブログ

コネヒト開発者ブログ

AIをマイクロマネジメントしない勇気

みなさんこんにちは、しょうぽんです。

先日、サポーターズ様主催のLT会に登壇させていただいたので、その内容をシェアいたします。

スライドは以下です。

speakerdeck.com

AIをマイクロマネジメントしない勇気

皆さんマイクロマネジメントはお好きですか？一般的には好きな人は少ないですよね。私はするのもされるのも苦手です。

ですが、AIを相手にするとなぜか「あれはどうなってる？」「この順番で進めて」「この情報はこちらに聞いてからやって！」などと口うるさい上司のように接してしまいがちです。

マイクロマネジメントにも良い部分と悪い部分があると思いますが、AIによる作業効率の向上を目指すのであれば、できるだけマネジメントの工数も下げたいですよね。

マイクロマネジメントをしているようでは「AIを使っている」レベルにしか届きません。私は「AIと働いている」世界に到達してみたい、という個人的な思想もあります。

本記事では、いかにしてAIをマイクロマネジメントしないよう努力するか、あるいは勇気を持つか。そのあたりのお話をします。

今回私が取ったアプローチは、対人間や対組織と同様のマネジメントをAIにも適用する、という形です。

  1. 情報を渡す
  2. 安全を守る
  3. 自走させる
  4. 改善を促す

この四つの柱を基本として、AIを一人の優秀な新卒の方が入ってきたという前提でマネジメント体制を構築しました。

結果として、今回取り上げる新規機能開発プロジェクトは100%Claude Code製コードを実現しています。

ママリレシートエールについて

弊社はママリというサービスを運営しており、

promo-app.mamari.jp

先日、ママリに「レシートエール」という新規機能をリリースしました。

家族を想うお買い物に確かな報酬を

というサービスコンセプトをもとに、とてもおトクなサービスとなっておりますのでぜひアプリでチェックしてみてください。

本機能にかける熱い思いについては以下の公式noteをぜひご覧ください。

note.com

いかにしてAI駆動で新規事業を開発したか

それでは本題に入っていきます。まず、先に挙げた四つの柱を思い出していきましょう。

  1. 情報を渡す
  2. 安全を守る
  3. 自走させる
  4. 改善を促す

情報を渡す。新卒の頃、上司によく「まずは自分で考えろ」と言われていました。当たり前のことですが、大切なことです。自分で考えるためには、考えるために必要な情報が十分与えられている、もしくは自分で探索ができる状態になければなりません。

安全を守る。これは部下が失敗をしたとしても、それが致命的なものにならないようガードレールを敷いてやることです。確かに失敗はどうしても起きてしまうことですが、失敗は成功の母、失敗は成功の途中といった言葉もあります。失敗をいかに安全な範囲にとどめ、そして次にどう活かすかということが重要です。

自走させる。情報を渡し、安全を守ったのであれば、あとは信頼して任せることが重要です。役割を与え、業務マニュアルを与え、あとはやらせてみることです。

改善を促す。一度やったタスクは、次はもっと上手くやれるはずです。発生した失敗が二度と起こらないようにマニュアルや進め方を改善し、失敗の記録をとっておきます。

AIを扱うにも、このようなPDCAを回しやすい環境を整えることが重要です。そこで、今回開発したレシートエールのプロジェクトでは、AI向けに以下のような環境を用意しました。

情報を渡す

モノリポジトリ構成

レシートエールのリポジトリ構成は、ざっくりと以下のようになっています。


receipt-yell/                         # Turborepo + pnpm monorepo
  │
  ├── apps/
  │   ├── api/                        # Backend (NestJS + TypeORM)
  │   │   └── src/                    # Clean Architecture 4層
  │   │       ├── presenter/          #   HTTP層
  │   │       ├── usecase/            #   ユースケース層
  │   │       ├── domain/             #   ドメイン層
  │   │       └── infrastructure/     #   インフラ層
  │   │
  │   ├── web/                        # Frontend SPA (React + Vite)
  │   │   └── src/                    # ユーザー向けWebView画面
  │   │
  │   ├── admin/                      # Admin SPA (React + Vite)
  │   │   └── src/                    # CS管理画面 
  │   │
  │   └── lambda/                     # AWS Lambda
  │       └── src/                    # プッシュ通知処理等
  │
  ├── packages/
  │   ├── shared/                     # 共通型定義 (API契約)
  │   ├── config/                     # 共通設定
  │   └── eslint-config/              # 共通ESLint設定
  │
  ├── .ecspresso/                     # ECSpresso (ECSデプロイ設定)
  │   ├── development/
  │   │   └── reci-toku-api/          # dev環境 ECSサービス/タスク定義
  │   └── production/
  │       └── reci-toku-api/          # prd環境 ECSサービス/タスク定義
  │
  ├── scheduled_batch_rules/          # ECS Scheduled Tasks 定義
  ├── scripts/                        # 開発用スクリプト
  │
  ├── docs/                           # ドキュメント類
  │
  ├── turbo.json                      # Turborepo設定
  └── pnpm-workspace.yaml             # pnpm workspace設定

Frontend、 Backendや管理画面、インフラのデプロイ設定までを一つのリポジトリにまとめています。

モノリポにすることで、AIにとってアーキテクチャやコードの見通しがよくなり、コンテキストの理解がしやすくなる効果を狙っています。

また、READMEや設計ドキュメントがコードと隣接している状態が維持でき、変更履歴も一元管理が可能になるメリットもあります。

オンボーディング資料

一例として、以下のようなドキュメント類を整備しています。

  • CLAUDE.md
  • ARCHITECTURE.md
  • DATABASE.md
  • API_SPEC.md
  • ERROR_HANDLING.md
  • NESTJS_PATTERNS.md
  • FRONTEND_DESIGN.md

新入社員が入ってきた時のオンボーディング資料のようですね。まさしく同じ効果を狙っています。

過去の意思決定経緯、このリポジトリでの作法、デザインシステムやエラー一覧など、それぞれの書類をメンテナンスしながらリポジトリに含めています。

AIがプロジェクトにスムーズに馴染むこと、セッションが違っても同じような方向性のコードを書き出すように、という狙いを込めてこれらの書類を作りました。

副次的な効果として、実際に別のエンジニアがこのPJに参画してくれた際、これらの書類を読むことでスムーズに参加できたということもありました。

人間へのオンボーディングとAIへのコンテキスト注入を同じものとして捉える試みです。

安全を守る - ガードレール

AIのコード品質を一定水準以上に保つため、PostToolUse HooksやPre-commit Hooksも使用しています。一例としては、以下のとおりです。

  • PostToolUse Hooks
    • 型チェック
    • フォーマットチェック
  • Pre-commit Hooks
    • .envの誤コミット検出
    • APIキー検出
    • パスワードハードコード検出

このHooksを整備したきっかけの一つは、AIが生成したコードにany型が混入した状態でPRを出してしまい、CIで弾かれた経験です。PRを出してからCIの結果を待って修正して、というサイクルは非常に非効率です。それならコミット前に弾けばいい、という発想でPostToolUse HooksやPre-commit Hooksを整備しました。フィードバックループを短くすることで、AIも次のアクションをすぐに取れるようになります。

linter類が自動実行されることに加え、.envやAPIキーなどが誤コミットされない仕組みを作っています。

このHooks類に加え、先述したドキュメントにもany型禁止などさまざまな禁止事項が書かれています。なるべくすり抜けを許さないよう、物理的なブロックと論理的制約による多層防御の体制を作っています。

自走させる - 役割と業務マニュアルの提供

エージェントも定義しています。簡略化すると、Backend専任 / Frontend専任 / infra専任、というような役割毎にエージェントを立てています。それぞれが触れる部分はそれぞれの専任領域にとどめ、構造的な衝突や事故を未然に防ぐよう工夫しています。

コネヒトでは、社内にSkillsのマーケットプレイスリポジトリを作り、皆が作った汎用的なスキルをそこで共有できるようにしています。

リポジトリ特有のスキルは各リポジトリで、汎用的なPRレビュー用スキルなどはマーケットプレイスで、というふうに管理しています。

役割で境界を切り、スキルで質を担保する。これをすることである程度信頼してAIに任せることが実現できています。

具体的な自走の例として、/fix-issue というスキルがあります。GitHub IssueのURLを渡すだけで、Issue理解→プラン作成→実装→テスト→PR作成まで一気に完走するスキルです。

また、大きめのタスクを投げる際は以下のような運用をしています。

  1. プランを作成させる
  2. AIがそのプランをセルフレビュー（2回）
  3. Geminiによるセカンドオピニオンを取得
  4. 私がプランを承認
  5. 実装

プランの段階で複数の視点からレビューを回しておくことで、実装に入ってからの手戻りを大幅に減らせています。私が関与するのはプラン承認の1点だけで、その前後はAIが自律的に動いています。

改善を促す - 改善ループ

振り返りも重要な開発プロセスです。工夫していることは多々ありますが、特に工夫している点は以下の二つです。

  • /skill-refiner skillを育てるskill
  • /handover セッション間の引き継ぎドキュメントを作るスキル

skill-refinerスキルによって、今回うまくいかなかった点や、改善の余地があるスキルを洗い出し、スキルの改善がなされます。使えば使うほどスキルが育っていくスキルというわけです。

handoverスキルによって、プロジェクト固有の落とし穴や注意点、特に注目すべき過去の判断経緯などがセッション間で引き継がれます。これによりcompactionよりも詳細に過去セッションの記憶を引き継ぐことが可能になります。もちろん読み込み分のコンテキストウィンドウも消費するため乱用は避けるよう工夫が必要です。

AIをマイクロマネジメントしないことで何が得られたか

AIはどういうことが得意で、どういうことが苦手なのか。どういう失敗をして、どうすればそれを繰り返さないのか。AIと二人三脚でそれらを学びながらこのマネジメントスタイルは確立されていきました。この経験自体がとても深い学びとなりました。

AIをただ使うだけではなく、中心に据えて業務フローを設計します。昨今よく言われていることですが、その第一歩としてAIをマネジメントしてみるというのは効果的な方法であったと感じています。

100%AIコード製のプロジェクトが実現できたことも、組織として一段深いAIへの知見・自信を得られる良い機会でした。

また、開発スピードという観点でも手応えを感じています。レシートエールはバックエンド・フロントエンド・インフラを含む新規機能ですが、実装着手からリリースまでおよそ1〜2ヶ月で完了できました。マイクロマネジメントをやめ、AIが自走できる環境を整えたことで、私自身は設計や意思決定に集中でき、実装の多くをAIに委ねることができた結果だと感じています。

さいごに

コネヒトでは一緒に働く仲間を募集しています！ぜひ私と一緒にAIと三人四脚しませんか？

herp.careers