AIに任せる範囲を安全に広げるためにやっていること

「AIコーディング現状確認会 2026福岡」というイベントで発表した内容です。
ref. https://connpass.com/event/383789/

Transcript

1. AIに任せる範囲を 安全に広げるためにやっていること 福澤 将史 | ACES Inc. | テックリード AIコーディング現状確認会 2026福岡 | 2026.02.25
2. AI駆動開発の4フェーズと現在地 ▲ 私たちは今ここ — Phase 3 の入口
3. 自走と統制を両立する3つの仕掛け ループ構造 plan.md → 実装/検証 → worklog記録 → DR抽 出 → plan.md更新 DR（Decision Required） AIが判断できない時だけ停止。A/B形式で人間は選ぶ だけ ガードレール 認証・課金・コアロジック等「任せない領域」を事前定義 Pilot-Tower開発 ＋ 3つの仕掛け Pilot-Tower開発（P&T開発） AI = Pilot（操縦） plan.mdを読み、実装→検証→ログ記録のループを自走 人間 = Tower（管制塔） 意思決定のみ。DRへの回答で介在 plan.md がそのタスクにおけるSSoT Goal / Constraints / DoDを記載 AIが読み更新する生きた仕様書 「人間の関与を最小化し、AIの自律稼働時間を最大化する開発」は一定程度実現できつつある 数ヶ月運用でAI実装起因のインシデントは0件 ここまでは上手くいった。問題はこの先 → 「人間の関与を最小化し、AIの自律稼働時間を最大 化する」ことを目指した独自フレームワーク
4. 現在の悩みポイント：PRレビュー AIのPRは大きくなりがち。人間のレビューが追いつかない 自走してくれる。品質ゲート (Lint, Tests, Self Review, Codex/Opus Review) も通る。 しかし変更差分の大きなPRが量産されても、人間側のレビューが追いつかない。 「これ本当に出しても良いのかな...？」という不安が残り続ける。 暫定対処 タスク分解に時間を使う・PR分割コマンドを利用す ることで人間がPRを見やすいように調整 → 人間がボトルネックになりやすく、本質的な解では ないと思っている ステータス チーム内で未解決 今一番悩んでいるポイント
5. この問題は一過性かもしれない レビューの前提が変わるなら、PR粒度の問題も構造ごと変わりうる → 今の対処と未来への投資を分けて考える "The concept of understanding and reviewing code is a dying paradigm." コードを理解してレビューするという行為自体が 「死にゆくパラダイム」だという主張 Thomas Dohmke @ashtom | 元GitHub CEO のツイートより一部抜粋 https://x.com/ashtom/status/2021255786966708280
6. 暫定策 vs 本命の投資先 暫定策 人間の介在を増やす 人間の手数を増やすことで 品質を担保している状態 ⚠ 人間の介在が増えると スケールしないことは分かっている リリース安全網 壊れても速く直せる仕組み 「壊れないようにする」だけでは限界 「壊れても速く直せる」 に発想を転換 リリース判断を「人間の目視」から 「データとシステム」に移す
7. 早く検知し、早くリカバリする 01 Progressive Delivery Feature Flag + カナリアリリースで段階的にリリース。 異常時は自動ロールバック。 02 Observability Sentry APM + Grafana でデプロイ起因の異常を早 期検知。 03 SLI/SLO / Error Budget リリース可否を感覚ではなくデータで判断。エラーバ ジェットで定量的に管理。 04 Error Triage Automation エラー発生 → 原因分類 → 対応PR自動生成。人間は判 断だけ。 4つが揃うと → AIが書いたコードでも安心して本番に出せる。 高速にロールバックできるならPR粒度は致命傷にな らない。理想的にはここを目指していきたい。
8. まとめ 1 Pilot-Tower開発で「人間の関与を最小化し、AIの自律稼働時間を最大化する 開発」は一定程度実現できつつある 2 PRの粒度問題は今一番の悩みポイント。だが人間レビュー前提のパラダイム自体 が変わりつつある 3 本命の投資先はリリース安全網。壊れても速く直せる仕組みがあれば、AIへの委 譲範囲はさらに広がる テックブログ 「AIネイティブな組織づくり」 シリーズ 本日公開