Human / Tool / AI の責務をどう分けるか

2026/09/04 AI駆動開発勉強会 登壇資料

Transcript

1. 2026/09/04 AI駆動開発勉強会 Human / Tool / AI の 責務をどう分けるか Webエンジニア(新卒3年目) shiyo__
2. ABOUT US Webエンジニア(新卒3年目) shiyo__ 趣味 ・個人開発 ・スポーツ (フットサル・ランニング・水泳) ⇨ 福岡マラソンに向けて、日々ランニングをしています。 技術領域 ・React / TypeScript / Nuxt / Next ・Ruby (Rails) / Nest / Symfony / AWS / New Relic
3. 0 1 | アジ ェ ン ダ 1. AIという福利厚生が導入された結果 2. 福利厚生を相棒に変えるために 3. Human / Tool / AI の責務分け
4. 0 2 | アジ ェ ン ダ ① AIという福利厚生が導入された結果
5. 02 | AIという福利厚生が導入された結果 仕事量と範囲が爆増した 以前 = 自分の経験や領域を少し超えるような仕事 + 予測可能なPRや相談事項 メリット 個人の経験・領域を超えるタスクもAIを利用することで、挑戦できるようになった。 適切な設計をすれば人が書いていた時よりも速度を上げて対応することができた デメリット PR レビュー依頼が爆速で大量で大依存が大発生するようになった。 プログラムや事業背景がわかるメンバーがボトルネックになってしまった 環境を整えていないのに、AI駆動開発したもんだから僕は毎日レビュー地獄
6. 02 | AIという福利厚生が導入された結果 システム開発の「プログラムを書く」という工程だけが速くなった。 ただ速くなっただけで品質は劣化、コード量は増大、責務破綻 僕が人柱となってこの荒波を打ちどめる決意 荒波を打ちどめるために、丁寧に何度もコメント
7. 0 2 | アジ ェ ン ダ ② 福利厚生を相棒に変えるために
8. 0 3 | 福 利 厚 生 を 相 棒 に 変 える た め に 問題設定 開発工程における生産性の向上 目的 (what) 生産性向上のための切り口 切り口 (where) 1. プログラム品質が人によって異なる 2. お問い合わせで開発時間が少なくなっている 3. 性能要件が曖昧で本番後に問合せ発生 生産性向上のためのアプローチ 手段 (how) 1. 責務違反パターンをPR時に自動レビューする 2. 問い合わせをナレッジ化、問い合わせ導線の整理 3. 類似案件から性能要件の初期値提案
9. 0 3 | 福 利 厚 生 を 相 棒 に 変 える た め に As-is To-be AIに依頼すればコードは書ける AIと仕組みの中でコードを完成させる 動けばレビューに出す 一定品質を満たしてからレビューに出す 品質基準が個人の経験に依存 品質基準をチームのルールとして共有 不足をレビュアーが発見する 不足を開発中に検知する 可読性・型・テスト・設計まで人が見る ツールで判断できるものはツールに任せる AIが埋めた「わからない部分」もそのままPRへ AIで埋める範囲を制御 レビュアーが品質を決める 開発者が品質を担保する 人間レビュー = 品質保証 人間レビュー = 意図・仕様・事業判断
10. 0 4 | アジ ェ ン ダ ③ Human / Tool / AI の責務分け
11. 0 4 | H u m a n / To o l / A I の 責 務 分 け Human 責務: 判断すること 事業ドメイン、仕様、優先順位、設計上のトレードオフ、最終意思決定 Tool 責務: 強制すること Formatter、Lint、Type、Test、CIなど、決めたルールを確実に守らせる AI 責務: 補助・探索・隙間を埋める 実装、レビュー補助、抜け漏れ検知、ルールに沿った修正、知識の検索・適用
12. 0 4 | H u m a n / To o l / A I の 責 務 分 け ツールについて Ai Guardrail Test Claude Code Prettier / ESLint Jest / Storybook GitHub Copilot TypeScript / Knip Chromatic / Playwright CI Maintenance Husky / lint-staged Dependabot GitHub Actions / CodeQL OpenTelemetry
13. 0 4 | H u m a n / To o l / A I の 責 務 分 け AIについて (claude 責務) Layer 責務 例 Prompt 今回だけの要求・目的を伝える 「商品検索機能を追加して」 Skill 繰り返し利用する手順・専門知識を定義する API追加時の実装手順 プロジェクト固有の前提・原則を与える レイヤー構造、命名方針、設計原則 MCP Claudeが持っていない外部コンテキスト・能力を接続する 社内仕様、GitHub上のIssue、最新Docs Hooks 特定のイベントに対して決められた処理・判断を自動適用する 作業完了時にプロジェクトルールとの整合性を確認させる Permissions Claudeが実行してよい操作の境界を定義する 特定ディレクトリの変更禁止、本番環境への操作禁止 CLAUDE.md / Rules Rules
14. 0 4 | H u m a n / To o l / A I の 責 務 分 け 抽象的なルールはAIに理解させ、 具体化できたルールはToolに落とす。
15. 0 4 | H u m a n / To o l / A I の 責 務 分 け ( 実 践 編 ) 僕たちの進み方 (チーム内) Tips FB項目ごとの出現回数を抽出して おくと、後続の導入効果試算に 利用できるのでおすすめ ① 個人/チームのナレッジを棚下ろす GitHub CLIを利用して過去FBコメントの抽出 既存のプログラム規約 / 品質規約 / 命名規約を抽出 ② 抽出した内容を整理 誰が、どの層で、どのイベントでチェックするか ③ チーム内で合意形成
16. 0 4 | H u m a n / To o l / A I の 責 務 分 け ( 実 践 編 ) Tips 僕たちの進み方 (意思決定) As-is To-beを複数軸で整理 投資対効果 = 削減工数 - 作成 ・運用コスト ④ 導入効果試算 ハーネス導入に伴う工数・効果の試算 ⑤ 上長合意 ⑥ ハーネス導入
17. 0 4 | H u m a n / To o l / A I の 責 務 分 け 具体例 No, Label PRコメント 対象リポジトリ Naming / Readability この変数名だと役割が分かりにくい。業務上の意味が伝わる名前にしてください backend-api 2 Architecture ControllerからRepositoryを直接呼ばず、UseCaseを経由してください 3 Test 4 Dead Code 1 5 Domain / Requirement 出現回数 誰が 層 ツール どのイベントで 8 AI Rules Claude Code 実装中 / セルフレビュー backend-api 6 Tool ― ESLint Custom Rule / dependency-cruiser commit / CI 正常系だけでなく、異常系・境界値のテストも追加してください backend-api 11 AI Skill Claude Code 実装完了時 使用されていないexportが残っています frontend-web 5 Tool ― Knip commit / CI この仕様の場合、在庫0の商品も表示対象になる認識で合っていますか？ product-service 3 Human ― ― PRレビュー
18. 05 | まとめ AIを福利厚生から、チームの開発基盤へ 目指すべきは「人が頑張って支える開発」ではなく、品質が自然に積み上がる開発ループ レビューで品質を作る 属人化した品質 開発ループの中で品質が育つ 生産性向上 FB → Rules / Skills /Tools → PR前に検知・修正 01 開発者が自走できる 02 レビューが判断に集中する 03 ナレッジがチーム資産になる AIやツール利用により、PRでFBされる 前に自分で治せる状態へ 人が可読性の粗探しではなく、仕様 意図・トレードオフに集中できるように FBがClaude.md / rules / Skills に残り 属人化を減らすことができる