- このスライドは、**AI（ChatGPT などの生成AI）を開発に導入した「実体験ベース」**の話です。
- 特にテーマにするのは：
- 「AI導入前はどれくらい時間がかかっていたのか」
- 「AI導入後、どれくらい開発速度が変わったのか」
- 「どこまでAIに任せて、どこから先を人間が握るべきか」
- 「スマホからAIに依頼することで、働き方がどう変わったか」
- ここでの内容は、**Rails / Terraform / GitHub Actions / gem開発**など、実際の業務・OSS開発での経験に基づいています

- 私の開発環境には、はっきりした制約がありました。
- 日中はクライアントワークや会社運営で埋まる
- 家庭の時間もあるため、**ガッツリ開発に使えるのは「夜と早朝」だけ**
- つまり、1日に確保できる開発時間はせいぜい **数時間**。
- この制約の中で、以下のような状態になりがちでした。
- 新機能1つ追加するのに、**3日以上**かかるのが普通
- 「やりたいこと」は増えるが、「実装できるもの」は限られる
- プライベートプロジェクト（slidict.io など）の進捗が遅く、モチベーションが下がりやすい

- リリースサイクルが長くなる
- リファクタリングやテスト整備が後回しになる
- 「やれば伸びそうなアイデア」があっても、着手すらできない
- 結果として、**事業アイデアやOSS活動のポテンシャルが活かしきれない**

大まかには以下のような流れでした。

[%step]
- 仕様やアイデアをメモ・頭の中で整理する
- 手を動かしながら、RailsやTerraformのコードを書いていく
- 何度もエラーに当たり、ドキュメントやググりを行き来する
- テストを書き、動作確認をする
- コードをリファクタリングし、レビュー（自分で読み直し）する

- 小さな機能追加でも、以下のような時間感覚でした。
* コード方針を考える：数十分〜1時間
* 実装：数時間
* テスト・動作確認：数時間
* リファクタ・調整：数時間
→ 合計すると、**まとまった3日（夜＋早朝）**がかかるのは珍しくありませんでした。

- 実装・設計・コードリーディング・ドキュメント探索…
すべてを自分の頭と手だけでやるため、どうしても限界が来ます。
- 特にボトルネックになっていたのは：
- 既存コードの読み解き（コードリーディング）
- 新しいライブラリやクラウドサービス（Terraform/Azure等）の仕様理解
- GitHub Actions などYAML系の “書き慣れない” 設定ファイル

これらが、「夜と早朝にしか時間がない個人開発者」にとっては致命的な負荷でした。

生成AI（ChatGPTなど）を本格的に開発に導入すると、まず実感したのはこれです。

- 以前なら3日かかっていたような機能でも、
- 背景
- やりたいこと
- 制約（使いたいフレームワークや既存構成）
- 期待するインターフェース
を **数行〜数十行の依頼文** にまとめることで、
- 「そのまま動きそうなコード」や「かなり精度の高い骨組み」が一気に上がってくるようになりました。

例（イメージ）：

- 「既存のRailsアプリに、タグ付き記事の検索機能を追加したい」
- 「ActiveRecordのモデル構造はこうで、既にこのスコープがある」
- 「Ransackは使わず、シンプルなWHERE条件で書きたい」

→ こういった要件を渡すと、
**モデル・コントローラ・ビュー・RSpec のひな形**まで含めて出てくるケースも珍しくありません。

AI導入後の私の作業は、大きく次のように変わりました。

[%step]
- ゼロから書く → **AIに「こういうものがほしい」と依頼する**
- 一行一行実装 → **出てきたコードを読んで、必要な修正だけする**
- エラー調査 → **AIにエラーメッセージごと渡して、修正案をもらう**

結果として：

- 「実装そのもの」にかける時間は大幅に減り、
- 「仕様を考える時間」「設計の方向性を決める時間」が相対的に増えました。

[%auto-animate]

[%step]
- コード生成があまりに簡単なので、
- 「じゃあもっと複雑な機能も丸ごと頼んでしまおう」と欲張ったことがあります。

[%auto-animate]

[%step]
- 結果として起きたのは：
- 大量のコードが一気に生成される
- すべてを読み切るのに時間がかかる
- 既存コードとの整合性・命名・責務の切り方が、プロジェクト全体の流儀と微妙にズレる
- 読み解きと修正で疲弊し、**最終的に採用を断念した実装もあった**

この経験から得た結論はシンプルです。

[%step]
- **AIへの依頼は「ストーリーポイント」を意識して分割したほうがよい。**
- 人間のスクラム開発と同じで、
* 「1タスクで何日もかかりそうなもの」をAIに一気に渡すと、
* レビューと統合にかかるコストがかえって増える。
- 依頼は、
* ログイン画面＋セッション管理
* パスワードリセット機能
* SNSログインの下準備
のように、**人間がレビューしやすい粒度**に分割する。

AI開発術のコアは、
**「AIを使えば何でも一気に終わる」ではなく、「人間がレビュー・統合しやすい単位に分割する」** ことだと実感しています。

AI導入後、体感的に最も恩恵が大きかった領域のひとつが **バグ修正** です。

[%step]
- エラーが出たら、そのまま：
* エラーメッセージ
* 問題のソースコード
* 期待している動作
を **丸ごとAIに渡す** だけで、かなり高精度の修正案が返ってくる。
- 以前は半日〜1日かかっていたようなバグ調査も、
* 数分〜数十分で解決することが増えました。

- バグ修正は、問題の範囲が比較的限定されている
- 「期待値」と「現状の差分」が明確である
- エラーメッセージという“ヒント”がすでに存在する

このため、AIにとっても扱いやすく、人間にとってもレビューしやすい領域です。

AI導入後の大きな変化のひとつは、
**「プロトタイプの立ち上げまでが圧倒的に速くなった」** ことです。

- 以前なら：
* Railsの新規プロジェクトを立ち上げる
* 認証や基本レイアウトを整える
* モデルやテーブル設計を考える
* シードデータを作る
…といった流れだけで、**数日〜1週間**かかることも普通でした。
- AI導入後は：
* やりたいアプリの概要（例：スライド共有サービス、AIと連携するノートアプリ等）を説明し、
* 必要なモデル・画面・ざっくりしたユーザーフローを伝えると、
* 最低限動くレベルのアプリ骨格が一気に手に入るようになりました。

- 「ちょっと試してみたいアイデア」をすぐにコードで検証できる
- 動くプロトタイプをベースに、「ここはこう変えたい」とAIに追加依頼できる

これは、プロダクト開発・OSS開発の両方において、**アイデアの生存率を高める効果**がありました。

AIを使うようになって、地味に効いているのがこれです。

[%step]
- **スマホからAIに依頼できる** ことで、
* 通勤時間
* ちょっとしたスキマ時間
* PCの前に座れない時間帯
にも、開発を前に進められるようになった。
- 具体的には：
* 仕様の整理や要件の文章化
* モデル設計のたたき台の作成
* GitHub Actions や Terraformの雛形生成
* リファクタリング案の相談

こうした「PCを開かなくても進められる開発作業」が、**ほぼチャットベースで完結**するようになりました。

- スマホで：
* 仕様をAIと一緒に固める
* 必要なコードのたたき台を生成しておく
- PCに向かったときには：
* 生成されたコードを取り込み、
* 動作確認と最低限の修正・チューニングに集中する

その結果、**PC前の時間効率がかなり上がりました**。

人間一人で複数の開発タスクを進めるのには限界がありますが、
AIはいい意味で**マルチタスク**です。

[%step]
- あるタスクで：
* 「この機能の実装コードを出して」
- 別のタスクで：
* 「このエラーの原因を一緒に調査して」
- さらに別のタスクで：
* 「こっちのプロジェクトの設計パターンを比較して」

というように、**複数プロジェクト／複数タスクにまたがって支援を並列発注**できます。

- 以前：
* 「1つのタスクを終えるまで次に手を出しづらい」
- AI導入後：
* AタスクでAIにコードを書いてもらっている間に、
* Bタスクの仕様整理を進める

という **並行処理** が自然にできるようになりました。

その結果：

- 体感的には「**一人で3〜5人体制**」くらいの進捗感が出てきます。
- もちろん、最終判断とマージ責任は人間が持つ必要がありますが、
「手と頭」の数が増えた感覚はかなり強いです。

開発速度が上がると、意外なところに影響が出ます。

[%step]
- 前は：
* 夜も早朝も「コードを書かないと進まない」という焦りが強い
* ずっとPCに向かってしまい、精神的にも疲弊しやすい
- AI導入後は：
* 必要なときにAIに投げておけば、かなりの部分が進む
* 自分が集中すべきタイミングだけしっかりPCに向かえばよい
* その結果、**ゲームで遊ぶ時間が生まれるくらいの余裕**が出てきた。

- この「ゲームする時間」は単なる娯楽以上の意味があります。
* メンタルがリセットされる
* 新しいアイデアがふと浮かぶ
* 開発に対する義務感が減り、「やりたいからやる」に戻れる

AIは「開発を速くする道具」であると同時に、
**「生活の余白」を取り戻すツール**でもあると感じています。

[%step]
- どれだけAIがコードを書いてくれても、**責任を持つのは人間**。
- 特に、依頼範囲を広げすぎると：
* 生成されたコード量が爆発する
* 読み切れない・把握しきれない
* 思わぬ副作用やバグが紛れ込む
- 「AIに任せたから大丈夫」という発想は危険で、
むしろ **「AIが提案したからこそ、人間が最後まで目を通す必要がある」** と考えたほうが安全です。

第三者視点（上司・レビュアー・顧客）の目線で見ると、以下の懸念もあります。

- セキュリティ：
* 入力値のチェック不足
* 権限まわりの抜け漏れ
- ライセンス：
* AIが提案したコードが、どこかのOSSコピペに近すぎないか
- 技術的負債：
* 今だけ動くコードになっていないか
* プロジェクト全体の設計思想から外れていないか

AI開発術を語るとき、
**「速くなります」という話だけでは偏ってしまう** ため、
こうしたリスクも同時に意識する必要があります。

- メリット
* 単純作業やドキュメント読みの時間を圧縮できる
* 「やりたい設計」に集中しやすくなる
- リスク
* 自分の基礎体力（読み書きの力）が育ちにくくなる可能性
* 「AIがいないと書けない」状態への依存

- メリット
* 少人数でも高いアウトプットが期待できる
* 新規プロダクトの検証スピードが上がる
- リスク
* メンバーの実力評価が難しくなる
* AIを使っている前提の前後で、工数見積もりがぶれやすい

- メリット
* 機能追加・改善のサイクルが速くなる
- リスク
* 「動いてはいるけれど、設計が荒い」システムを掴まされる可能性
* 長期保守性への不安

- 私自身の経験から言えるのは、AI開発の本質は **「丸投げ」ではない** ということです。

* 制約があるからこそAIが活きる
** 夜と早朝しか時間がないような個人開発者にとって、AIは「時間を増やす道具」になりうる。

* 3日 → 数分を実現する条件
** 依頼文（プロンプト）をしっかり書く
** ストーリーポイントの感覚で、タスクを小さく分ける
** バグ修正やプロトタイプなど、相性のよい領域に優先的に使う

* 働き方の変化
** スマホからAIに依頼し、PC作業を「最小限の確認と調整」にする
** 複数タスクを並行させやすくなる
** 余白の時間（ゲームする時間すら）を取り戻せる

* それでも人間が握るべきもの
** 設計・意図・責任
** リスクと盲点のチェック
** 「このプロジェクトでAIをどう使うか」という方針

[quote]
AI開発術とは、
「AIに任せる領域を増やすこと」ではなく、
「人間が握るべき領域をはっきりさせること」でもある。

このスライドは、

- AI導入前後の開発速度
- 生活・働き方への影響
- リスクと多角的な視点

にフォーカスした内容でした。

続編として考えられるテーマは、例えば：

- 「AIにどう依頼すればよいか」プロンプト設計術
- aijoin / slidict.io など、具体プロジェクトでのAI利用事例
- 「小さな組織 × AI」で事業を大きくするための経営視点

などがあります。
```