AIはどこまでタスクを自動化できるのか

LLMと既存の自動化技術を用いて、どこまでタスク自動化ができるかを具体例付きで紹介

Transcript

1. AI AIはどこまでタスクを自動化できるのか 〜Issueを渡すと、レビュー待ちのPRが返ってくる開発〜
2. W H AT I S C L A U D E CO D E Claude Code とは チャットAIと違い、「提案」ではなく「作業」をするエージェント型AIツール Anthropic社のAIコーディングエージェント 指示すると、ファイル編集・コマンド実行・テスト実行まで自律的にこなす チャットAIとの違い チャットAI：質問に「答え」を返す Claude Code：手を動かして「成果物」を作る 使える形態も拡大中 CLI（ターミナル） → AIはどこまでタスクを自動化できるのか GitHub連携 → ブラウザからのクラウド実行 2 / 16
3. PREMISE 前提：今日の話の土台 クラウド開発環境 + GitHub + GitHub Actions を前提に、開発タスクの流れ全体を見る 対象は「コーディングだけ」ではない 環境構築からデプロイまで、タスクの一生まるごとが自動化の射程 土台になる3点セット GitHub コード・Issue・PR ＋ AIはどこまでタスクを自動化できるのか GitHub Actions CI/CD・自動実行 ＋ クラウド実行環境 コンテナ 3 / 16
4. OVERVIEW 全体像：タスクの一生マップ 人間／AI／共同で色分けすると、人間専任は「最初と最後」だけになる プロジェクト最初期（共同）：アーキテクチャ・技術選定 ／ 環境構築手順の設計 → Issue作成 → CI / CD 環境構築 → → 仕様書 レビュー・マージ → → 実装 → テスト → Git / PR デプロイ 全工程に横串（共同）：ハーネスエンジニアリング（AIが働きやすい環境の整備） 人間 AI・自動化 人間＋AIの共同 ※ ここから工程を1つずつ見ていきます AIはどこまでタスクを自動化できるのか 4 / 16
5. STEP 1 / 6 工程1：作業環境構築 環境をコンテナ定義にすれば「構築作業」はほぼ消え、定義ファイル自体もAIが書ける 環境構築 仕様書 実装 テスト Git操作 CI/CD 環境＝コードとして定義（devcontainer / Dockerfile） 「手順書を見ながら半日セットアップ」からの脱却 DB（PostgreSQL等のRDB）もコンテナで起動 スキーマはORMのマイグレーション／DDL＋マイグレーションツールでコード化 → 環境ごと再現できる その定義ファイルを書くのもAIに任せられる 共同：「どんな環境にするか」の方針・手順設計は人間＋AI ※ 月額/年間プラン限定だが、ブラウザからクラウドVMでClaude Codeを動かす「Claude Code on the web」もある AIはどこまでタスクを自動化できるのか 5 / 16
6. STEP 2 / 6 工程2：仕様書作成・修正 仕様書のドラフトはAIが書く。人間の仕事は「書くこと」から「正しいかを判断すること」へ 環境構築 仕様書 実装 テスト Git操作 CI/CD 新規開発：要件を壁打ちしながらAIがドラフト作成（ゼロから書き始める負担がなくなる） 既存資産：コードから現状仕様を書き起こし／Issueから変更仕様のドラフト／実装後の追随 ドキュメントが無い古いコードにも効く DBドキュメント： tbls がスキーマからテーブル定義書・ER図を自動生成（CIで常に最新に追随） PDFで欲しい場合： Vivliostyle でMarkdownを組版してPDF化（これもCIで常に最新） 仕様駆動開発（spec-driven）：仕様を先に固め、仕様⇔実装をAIが往復する進め方が広がりつつある AIはどこまでタスクを自動化できるのか 6 / 16
7. STEP 3 / 6 工程3：コーディング（IaC含む） 「書く→動かす→直す」のループごと任せられる。インフラもコード（IaC）なので同じ土俵 環境構築 仕様書 実装 テスト Git操作 CI/CD 1行ずつの補完ではなく、ループを自律的に回す コードを編集 → ビルド・実行 → テスト → 失敗したら自分で修正 ↻ Terraform / CDK などのIaCもコーディング対象＝インフラ構築も自動化の射程内 逆に、IaC化されていないインフラはAIから「見えない」 現状を把握できず判断の精度が落ちる。IaC化はAI活用の前提整備でもある AIはどこまでタスクを自動化できるのか 7 / 16
8. STEP 4 / 6 工程4：テスト テストケース設計もテストコード実装も実行もAI。「書く→実行→落ちたら修正」までワンループ 環境構築 仕様書 実装 テスト Git操作 CI/CD 仕様からテストケースを設計し、テストコードの実装までAIが行う 既存コードのテスト不足も埋められる テストを実行し、落ちたら原因を調べて自分で直す（人間は結果を見るだけ） テストケース設計 → テストコード実装 → 実行 → 失敗したら修正 ↻ ※ テストの「正解の基準」が妥当かのレビューは人間に残る（品質担保の肝） AIはどこまでタスクを自動化できるのか 8 / 16
9. STEP 5 / 6 工程5：Git操作 ブランチ作成からコミット、PR作成・説明文まで、Git操作はAIの標準機能 環境構築 仕様書 実装 テスト Git操作 CI/CD git / gh CLI をAIが直接操作 ブランチ運用、コミット分割、コミットメッセージ作成 Issueの閲覧・コメントも gh CLI 経由でできる PR作成＋変更内容の説明文も自動生成（レビュアーの負担も下がる） コンフリクト解消の下働きも任せられる ブランチ作成 → 実装・コミット AIはどこまでタスクを自動化できるのか → PR作成 → 説明文生成 9 / 16
10. STEP 6 / 6 工程6：CI/CD CI/CDの定義もコード。書くのはAI、回すのはGitHub Actions。人間はGitHubを見ているだけでいい 環境構築 仕様書 実装 テスト Git操作 CI/CD lint / test / build のCI、デプロイパイプラインのワークフロー（YAML）作成もAIに任せられる claude-code-action：Issue や PR で @claude とメンションするだけでAIが動く 「Issueを渡すとPRが返ってくる」の実体。PRの自動レビューや定期実行もできる AI以外の自動化とも組み合わせ：Renovate / Dependabot が依存更新のPRを自動発行 → 対応はAIに回せる Issueに @claude → Actionsが起動 → AIが実装 → PRが返ってくる → 人間がレビュー ※ 正確にはデフォルトでは「ブランチ＋PR作成リンク」が返る（設定でPR作成まで自動化可能） AIはどこまでタスクを自動化できるのか 10 / 16
11. NEW EXPERIENCE 修正のやりとりはGitHub上で完結する レビュー指摘から修正まで、ローカル環境もエディタも不要。自然言語だけで直せる PRにレビューコメントを付けて @claude で号令すると、AIが修正して同じPRを更新する 指摘は日本語の文章でOK。何を直したかの返信もPR上に返ってくる 仕様書（リポジトリ内の文書）への指摘なら、仕様書と対応するコード・テストがまとめて直る 指摘を「変更要求」として読み、仕様とコードの整合まで取りに行く コードを書かない人も、レビューコメントを通じて開発に直接参加できる 仕様書・コードに指摘 日本語の文章で → @claude で号令 → AIが修正・PR更新 → CI再実行 → 確認してマージ ※ @claude での号令は claude-code-action 導入時。未導入やActionsの実行コストを抑えたい場合は、コメントを付けたあと手元のClaude Codeに「このPRのレ ビューコメントに対応して」と号令すれば同じ流れになる（gh CLI経由でコメントを読む） ※ 号令の @claude は最後のコメント1つだけに付ける（コメントごとに付けるとその数だけ起動してしまう） AIはどこまでタスクを自動化できるのか 11 / 16
12. B O N U S : N O N - A I A U T O M AT I O N 補足：タスク管理もGitHub上で自動化できる Issueとタスク管理ボードを紐づければ「管理のための二重入力」が消える。AIでなくても効く自動化 GitHub Projects：Issue / PR をそのまま看板・ロードマップとして管理 Issueクローズ / PRマージで、ボードのステータスが自動で「完了」に動く（内蔵ワークフロー） 条件に合うIssueの自動追加、完了アイテムの自動アーカイブも設定できる sub-issues（Issueの親子化）とマイルストーンで、タスク分解・期限管理もIssueに一元化できる その他の管理系自動化：CODEOWNERS（変更ファイルに応じたレビュアー自動アサイン）、リリースノート自動生成 （マージ済みPRから変更履歴を作成） 開発の実体（Issue・PR）と管理表が同じ場所にある＝転記ゼロで常に最新。これも「ドキュメントの自動化」の一種 ※ GitHub以外のタスク管理（Jira / Backlog / GitLab等）にも、チケット番号でコミット・PRと紐づける同種の連携がある AIはどこまでタスクを自動化できるのか 12 / 16
13. HUMAN'S ROLE それでも人間に残る3つ 残るのは「何を作るか」「良し悪しの判断」「権限の付与」。責任の所在は人間に残り続ける 01 02 03 Issue作成 レビュー アカウント・認証情報 何を作るか・なぜ作るかの定義。タスクの 品質の最終責任。AIによる自動レビューは AIに渡す権限の範囲を人間が設計する。暴 入口であり、ここの質が成果の質を決め 補助になるが、承認するのは人間。 走を防ぐ統制であり、安全装置。 る。 「人間が残る」＝不完全さではなく、統制点が明確ということ AIはどこまでタスクを自動化できるのか 13 / 16
14. CO L L A B O R AT I O N 共同でやること：ハーネスエンジニアリング 「AIがうまく働ける環境」を整える仕事が新しく生まれる。投資のしどころはここ アーキテクチャ・技術選定、環境構築手順の設計（プロジェクト最初期） AIと壁打ちしながら、人間が決める ハーネス＝AIの作業環境の整備 ルールファイル（CLAUDE.md）、自動チェック、定型手順（Skill）など AIがミスするたびに、環境側に恒久的な修正を入れる AIのミス → 環境側を修正 → ルール・チェックとして定着 → チームの資産に ※ プロンプトは使い捨て、ハーネスは資産として蓄積される AIはどこまでタスクを自動化できるのか 14 / 16
15. SUMMARY まとめ 実作業の大半はAIに任せられる。人間は「定義・判断・権限」に集中する 誰がやるか やること 人間 Issue作成（タスクの用意） ／ レビュー ／ 各種アカウントの作成・認証情報の入力 AI 作業環境構築 ／ 仕様書作成・修正 ／ コーディング（IaC含む） ／ テストケース作成 ／ テスト実行 ／ CI/CD環境構築 ／ Git操作 人間＋AIの共同 アーキテクチャ・技術選定 ／ 作業環境構築手順作成 ／ ハーネスエンジニアリング まずはひとつ、Issueを渡すところから始められます AIはどこまでタスクを自動化できるのか 15 / 16
16. AI CLOSING 実作業の大半はAIに任せられる時代になった 人間の仕事は「定義・判断・権限」へ ご清聴ありがとうございました