AIコーディング時代における人間の本当の仕事

GitHub Copilotを使い始めて数ヶ月。確かにコードを書く速度は上がった。でも、仕事の本質が変わったかというと、そうでもない。

AIが変えたのは「作業の効率」で、「仕事の本質」は変わってない。むしろ、AIが普及したからこそ、人間がやるべきことがはっきりしてきた。それは「何を作るか」を決めることだ。

仕様提案と仕様を固めることの重要性

使ってみて分かったのは、AIコーディングで一番大事なのは「仕様を提案して固める能力」だということ。

昔は曖昧な要件から始めて、実装しながら詰めていけた。でもAIだとそれが通用しない。曖昧な指示を出すと、曖昧なコードが返ってくる。

ログイン機能を作るにしても、認証方式、セッション管理、エラーハンドリング、セキュリティ要件。これ全部決めてから指示しないと、使えるコードは生成されない。

で、その仕様を決めるには、ビジネス要件の理解、技術的なトレードオフの判断、セキュリティリスクの評価、将来の拡張性の考慮が必要になる。これ全部、人間がやる仕事。

もっと言うと、仕様を「提案」する能力が重要。顧客から「ログイン機能がほしい」って言われたとき、そのまま作るんじゃなくて、最適な認証方式を提案して、セキュリティ要件を説明して、選択肢とメリデメを示す。これができて初めて、ちゃんとした仕様が固まる。

AIを使うなら、むしろ従来以上に明確な仕様提案と確定が求められる。

設計フェーズは短縮できない

色々な規模のシステムをAIで作ってみて分かったこと。実装は速くなるけど、設計の時間は変わらない。

CRUD APIを作る場合、AIなしで4時間かかってたのが1時間半になった。60%短縮。でも内訳を見ると、設計の30分は変わってない。短くなったのはボイラープレート、テストコード、ドキュメント。要するに「決まったことを形にする」部分だけ。

認証システム全体だと、設計2時間+実装8時間が、AIを使っても設計2時間+実装4時間。実装は半分になるけど、設計は変わらない。

大規模なマイクロサービスになると、もっと顕著。設計に1週間かかるものは、AIを使っても1週間かかる。下手すると、AIのコードをレビューしたりデバッグしたりで、自分で書いた方が早いこともある。

AIが苦手な領域

AIが得意なのは、パターンがはっきりしてる作業。ボイラープレート、型定義、テストケース、ドキュメント。「お決まりの形」があるやつは精度高く生成できる。

逆に苦手なのがビジネスロジック。在庫管理システムの受注処理とか。在庫の引当、予約、キャンセル、返品、自動発注。これら全部が絡み合って、タイミングで挙動が変わる。どの順で処理する？トランザクションどこで切る？エラー時のロールバックは？

こういう判断には、ドメイン知識が必要。在庫切れの定義って何？予約と確定の違いは？キャンセルはいつまで可能？これ全部、プロジェクトごとに違うし、AIには判断できない。

つまり、AIは「HOW（どう実装するか）」は支援できるけど、「WHAT（何を実装するか）」は決められない。その「WHAT」を決めるには、要件整理して、仕様提案して、関係者と合意形成する能力が必要になる。

セキュリティとパフォーマンスの判断

もっと深刻なのが、セキュリティとパフォーマンス。AIは平気でSQLインジェクションのリスクがあるコードを書くし、非効率なアルゴリズムも生成する。「動く」けど「本番で使える」わけじゃない。

ユーザー検索機能を実装させたとき、全ユーザーをメモリに読み込んでJavaScriptでフィルタリングするコードが出てきた。ユーザーが少ないうちはいいけど、数万人規模になったら破綻する。データベース側でインデックス使って検索して、必要な列だけ取得して、件数制限する。この判断は、システム全体のアーキテクチャを理解してる人間にしかできない。

だから、セキュリティ要件やパフォーマンス要件も、実装前に仕様として固める必要がある。レスポンスタイムは何秒？同時アクセスは何人想定？セキュリティ対策のレベルは？これを明確にして初めて、AIに適切な指示が出せる。

エッジケースへの対処

AIがもう一つ苦手なのが、エッジケース。例外的な状況への対処。

ファイルアップロード機能を作らせると、基本的なケースは書いてくれる。でも、ファイルサイズが上限超えたら？サポート外の形式だったら？同名ファイルが既にあったら？アップロード中にネットワーク切れたら？

こういうエッジケースを全部洗い出して、それぞれの対処方法を決めるのは人間の仕事。AIは指示されたケースには対応するけど、網羅的に想定はできない。

実際、本番で問題になるのは大体このエッジケース。基本機能は動いても、想定外の入力や状況で壊れる。エッジケースを想定するには、ドメイン知識と経験が必要。

レビューと責任

AIが生成したコードをそのまま本番に投入して障害が起きたら、誰が責任取るの？

答えは簡単。レビューせずに投入した人間が責任を取る。AIは責任取れないから。だから、AIが生成したコードを理解して、レビューして、必要なら修正する能力が求められる。

レビューができるってことは、自分でも書けるってこと。コード読めない人はレビューできないし、アーキテクチャ分かってない人は設計レビューできないし、セキュリティの知識がない人は脆弱性を見抜けない。

結局、AIを使いこなすには、従来のプログラミングスキルが全部必要。AIは作業を効率化するけど、スキルの代替にはならない。

学習曲線への影響

AIツールが普及して心配なのは、若手エンジニアへの影響。

初心者がAIに頼りすぎると、基礎を学ぶチャンスを失う。なんで動くか分からないままコピペして、エラー出たらまたAIに聞いて。これじゃ本質的な理解は深まらない。

逆に、ちゃんと使えばAIは優秀な学習ツールになる。分からないコードの説明を聞けるし、複数の実装方法を比較できるし、ベストプラクティスも学べる。効率的に実験もできる。

大事なのは、AIを「考えることを代替するツール」じゃなくて、「学習を加速するツール」として使うこと。

人間とAIの役割分担

数ヶ月使ってみて、こういう役割分担がベストだと感じてる。

人間がやるべきなのは、要件理解、設計、アーキテクチャ決定、技術選定、トレードオフ判断、セキュリティ検討、パフォーマンス最適化、エッジケース想定、コードレビュー、そして最終的な責任。

AIが手伝えるのは、ボイラープレート生成、型定義補完、テストケース作成、ドキュメント作成、リファクタリング提案、既存パターンの適用。

この役割分担を理解せずに、AIに全部任せようとすると失敗する。逆に、ちゃんと理解して使えば、生産性は確実に上がる。

仕様決定能力こそがエンジニアの価値

皮肉だけど、AIが普及したからこそ、仕様を提案して決める能力が一番重要になった。

昔は曖昧な仕様でも、実装しながら詰めていけた。でもAIだと、曖昧な指示には曖昧なコードしか返ってこない。AIを使うなら、実装前に仕様を明確にする必要がある。

つまり、AI時代は「設計重視」「仕様重視」の開発スタイルを求める。実装はAIが手伝うけど、何を作るかは人間が決める。その「何を」を決める能力が、エンジニアの価値を決める。

プロジェクトの要件理解、ユーザーニーズ把握、技術的トレードオフ判断、セキュリティリスク評価、スケーラビリティ考慮、保守性確保。そして、これらを踏まえて実現可能で効果的な仕様を提案する。

顧客が「こういう機能がほしい」って言ったとき、そのまま作るんじゃなくて、「その目的なら、こういう仕様がもっと適切です」って提案できる。これができる人間が、AIを最も使いこなせる。

プロンプトエンジニアリングの正体

「プロンプトエンジニアリング」って言葉が流行ってる。AIに適切な指示を出すスキルのこと。でも、これって誤解を招く言葉。

良いプロンプトを書くには、何を作るべきか完全に理解してる必要がある。機能の目的、技術的制約、セキュリティ要件、パフォーマンス要件、エッジケース。全部把握して、明確な言葉で表現する。

つまり、プロンプトエンジニアリングって、実は従来の「要件定義」「仕様策定」「設計」のスキルそのもの。新しいスキルじゃなくて、既存のスキルを別の形で表現してるだけ。

結局、ソフトウェア開発の本質は変わってない。何を作るか決めて、仕様固めて、設計して、実装する。AIはこの「実装」を効率化するけど、「何を」「なぜ」「どう」は人間が決める。その決定プロセスこそが、エンジニアリングの本質。

開発の未来

AIの進化でエンジニアの仕事はなくなるのか？答えはノー。

むしろ、エンジニアの仕事はより「エンジニアリング」になる。コーディング作業から解放されて、もっと本質的な問題解決に集中できる。要件分析、アーキテクチャ設計、技術選定、パフォーマンスチューニング、セキュリティ強化。こういう「判断」を伴う仕事は、AIには代替できない。

ただし、「指示されたとおりにコード書くだけ」のエンジニアには厳しい時代になる。AIがその役割を効率的に果たせるから。逆に、「何を作るべきか理解して、適切な設計を行って、技術的な判断ができる」エンジニアの価値は、むしろ高まる。

AI時代は、エンジニアに「考えること」をより強く求める時代。

実践的な心得

AIツールを使う上で、実際に効果があった心得をいくつか。

まず、AIは道具として扱う。副操縦士として横に座らせて、最終判断は自分が下す。AIの提案を鵜呑みにせず、必ずレビューする。

次に、段階的に使う。設計を固めてから、AIにボイラープレート生成させて、ビジネスロジックは自分で書いて、テストはAIに生成させて内容は自分で確認する。

そして、学習機会として活用する。AIが生成したコード読んで理解する。なんでこの実装なのか考える。他の方法ないか検討する。この過程で、自分のスキルも上がる。

最後に、基礎を疎かにしない。AIに頼れるからこそ、基礎的なプログラミング能力、アルゴリズム理解、設計原則の習得が重要。これがあって初めて、AIを正しく使いこなせる。

結論：仕様提案こそがエンジニアの本質

AIコーディングツールは確かに革新的。でもそれは「実装作業の効率化」であって、「ソフトウェア開発の本質の変化」じゃない。

何を作るか決めるのは人間。仕様を提案するのも人間。設計するのも人間。実装の一部をAIが手伝う。生成されたコードをレビューするのは人間。最終的な責任を取るのも人間。

AIの登場で、むしろ人間の役割ははっきりした。それは「仕様を提案し、固めること」。顧客の要望を聞いて、ビジネス要件を理解して、技術的実現可能性を評価して、最適な仕様を提案する。これができる人間が、AIを最も使いこなせる。

AI時代の優れたエンジニアとは、AIを使いこなせる人じゃない。適切な仕様を提案できる人。要件を整理できる人。技術的トレードオフを判断できる人。そして、その判断を明確な言葉で表現して、チームや顧客と合意形成できる人。

技術は進化する。でも、ソフトウェア開発の本質は変わらない。問題を理解して、解決策を提案して、仕様を固めて、それを実装する。AIはこの「実装」を効率化するけど、「提案」と「決定」は代替しない。

だから、AIが普及した今、エンジニアは改めて問うべき。自分は何を提案できるのか。なぜその仕様が最適なのか。どう実現すべきなのか。これらの問いに答えられる人間が、AIと協働して、より良いソフトウェアを作り出していく。

仕様を提案し、固める能力。これこそが、AI時代におけるエンジニアの最も重要な価値。

仕様駆動開発を実践するツール：cc-sdd

理論は分かった。でも実際どうやって仕様を固めて、AIと協業すればいいのか。

そこで役立つのが cc-sdd（Spec-driven development） というツール。GitHub Copilot を含む8つのAIエージェントで使える仕様駆動開発ツール

cc-sddの特徴

cc-sddは、まさにこの記事で書いた「仕様を提案し、固める」プロセスを体系化したツール。

対応AI：

• GitHub Copilot
• Claude Code
• Cursor
• Gemini CLI
• Codex CLI
• Qwen Code
• OpenCode
• Windsurf

基本的なワークフロー：

# インストール（GitHub Copilot用）
npx cc-sdd@latest --copilot --lang ja

# 1. プロジェクト初期化
/kiro:spec-init 写真アルバム機能

# 2. 要件定義（EARS形式で生成）
/kiro:spec-requirements photo-albums

# 3. 設計書作成（アーキテクチャ図含む）
/kiro:spec-design photo-albums -y

# 4. タスク分解（依存関係付き）
/kiro:spec-tasks photo-albums -y

# 5. 実装
/kiro:spec-impl task-001

なぜデグレ地獄から抜け出せるのか

従来のバイブコーディングでは、AIに曖昧な指示を出して、生成されたコードをそのまま使うから、デグレが頻発する。

cc-sddを使うと：

1. 要件を明文化 - 「EARS形式」で要件を構造化して記録
2. 設計を事前承認 - 実装前にアーキテクチャを確定
3. タスクを分解 - 並列実装可能な単位に分割、依存関係も明確
4. プロジェクトメモリ - AIがアーキテクチャ、パターン、基準を記憶
5. 開発過程の可視化 - 各フェーズの成果物が.kiro/specs/配下に保存される

つまり、AIに「何を作るか」を明確に伝えられる。これがあるから、AIは正確な実装ができる。

実例：10分で生成される成果物

「写真アルバム機能」を例にすると、10分で以下が生成される：

• requirements.md - 15個のEARS形式要件
• design.md - アーキテクチャとMermaid図
• tasks.md - 12個の実装タスク（依存関係付き）

この成果物があれば、人間がレビューして承認してから、AIに実装させられる。つまり、「判断は人間、実装はAI」という理想的な分業が実現する。

テンプレートカスタマイズ

さらに重要なのは、チーム独自のドキュメント形式に合わせられること。

.kiro/settings/templates/ で以下をカスタマイズできる：

• 要件定義書の形式
• 設計書の構成
• タスク管理の方法
• 承認プロセス
• JIRA連携

一度設定すれば、チーム全体で統一されたドキュメントが自動生成される。これで「AIがバラバラなコードを書く」問題も解決する。

他のCLIツールとの協業

記事で言及されていた「gemini-cliやcopilot-cli（間にワンクッション置く方式）」との協業も可能。cc-sddで仕様を固めておけば、どのAIツールを使っても同じ仕様に基づいて実装できる。

つまり、GitHub Copilot Pro のリミットに達したら、Gemini に切り替えて続けられる。仕様ファイルという共通言語があるから。

参考リンク

• cc-sdd GitHub
• バイブコーディングという地獄 - 実践例
• Kiroの仕様書駆動開発プロセスをClaude Codeで徹底的に再現した

---

2026年2月3日 記

この記事は、実際にAIコーディングツールを数ヶ月使い込んだ経験をもとに書いた。AIは日々進化してる。でも、人間が担うべき役割の本質は、たぶん変わらない。

cc-sddのようなツールが登場したのは、まさにこのニーズが広く認識された証拠だろう。仕様駆動開発は、AIコーディング時代の標準になっていくかもしれない。

# 「このコードをクラスベースに書き直して」
# → 構造化されたコードに変換

時間短縮: 2時間→30分

4. ドキュメント作成

   # `/doc` コマンドで自動生成
   # → JSDoc、docstring、README生成

   時間短縮: 1時間→15分

向いていない作業

使ってみて微妙だった作業：

1. 複雑なビジネスロジック

   • AIは要件を理解できない
   • 生成されたコードが要件を満たさないことが多い
   • 結局自分で書いた方が早い

2. パフォーマンス最適化

   • O(n²)のコードを平気で生成する
   • 計算量の概念を理解していない
   • 最適化前のコードとして使える程度

3. セキュリティが重要な部分

   • SQLインジェクションのリスクあるコードを生成
   • XSS対策が甘い
   • 必ず人間がレビュー必要

4. 既存の大規模コードベースの理解

   • コンテキストウィンドウに収まらない
   • 全体構造の理解は苦手
   • ドキュメントを別途用意する必要あり

実践的な使い方

1. プロンプトの書き方

悪い例:

「ログイン機能を作って」

→ 何を作ればいいか不明確

良い例:

「Expressで以下の仕様のログイン機能を実装:
- POST /api/loginでメール・パスワードを受け取る
- bcryptでパスワード検証
- JWTトークンを返す
- エラーは400/401で返す
- バリデーションにexpress-validatorを使う」

→ 具体的で実装可能

ポイント:

• 使用技術を明示
• 入出力を明確に
• エッジケースの処理方法を指定
• コーディング規約があれば伝える

2. レビューの必須ポイント

AIが生成したコードは必ずレビューする。特に以下をチェック：

セキュリティ:

// ❌ 危険: SQLインジェクションのリスク
const query = `SELECT * FROM users WHERE id = ${userId}`;

// ✅ 安全: プリペアドステートメント使用
const query = 'SELECT * FROM users WHERE id = ?';
db.query(query, [userId]);

エラーハンドリング:

// ❌ エラーを無視
try {
  await api.call();
} catch (e) {
  console.log(e);
}

// ✅ 適切な処理
try {
  await api.call();
} catch (e) {
  logger.error('API call failed', e);
  throw new ApiError('Failed to fetch data', e);
}

パフォーマンス:

// ❌ O(n²): 遅い
for (let i = 0; i < arr1.length; i++) {
  {
    for (let j = 0; j < arr2.length; j++) {
      {
        if (arr1[i] === arr2[j]) result.push(arr1[i]);
      }
    }
  }
}

// ✅ O(n): 速い
const set2 = new Set(arr2);
const result = arr1.filter((item) => set2.has(item));

3. 効率的なワークフロー

実際に使っているワークフロー：

Phase 1: 設計

1. 人間が要件を整理
2. AIに構造案を提案させる
3. 人間が最終判断

Phase 2: 実装

1. AIにボイラープレート生成させる
2. 人間がビジネスロジック実装
3. AIにテストコード生成させる

Phase 3: レビュー

1. 人間がコードレビュー
2. AIにリファクタリング案を提案させる
3. 人間が最終調整

Phase 4: ドキュメント

1. AIにドキュメント生成させる
2. 人間が内容を確認・修正

よくある失敗と対策

失敗例1: AIを盲信

状況:

// AIが生成したコード
async function getUser(id) {
  return await db.query('SELECT * FROM users WHERE id = ' + id);
}

問題:

• SQLインジェクションのリスク
• パスワードハッシュも返している
• エラーハンドリングなし

対策:

• 生成されたコードは必ずレビュー
• セキュリティチェックを怠らない
• 本番投入前にテスト必須

失敗例2: 不明確な指示

悪い指示: 「データベースから取得して表示して」

結果:

• どのテーブル？
• どのデータ？
• どう表示？ → 使えないコードが生成される

良い指示: 「usersテーブルからアクティブユーザー（status='active'）を全件取得し、 {id, name, email}の形式でJSON配列として返すAPIエンドポイントを実装」

失敗例3: 既存コードの無視

状況: プロジェクトにはTypeScriptの型定義があるのに、 AIがany型だらけのコードを生成

原因:

• プロジェクトの規約を伝えていない
• 既存コードのコンテキストが不足

対策: Custom Instructionsで規約を設定：

---
applyTo: '**/*.ts'
---

# TypeScript規約

- any型の使用禁止
- 必ず型定義を付ける
- nullableな値は明示的に型で表現

失敗例4: テストなし投入

状況: AIが生成した関数をテストせず本番投入

結果:

• エッジケースでバグ発生
• 本番環境で障害
• ロールバック対応

教訓:

• AIが生成したコードも必ずテスト
• 特にエッジケースを重点的に
• /testsでテストコード自動生成してから投入

AIとの協働スタイル

タイプA: コパイロット型（推奨）

AIを副操縦士として使う。

特徴:

• 人間が主導権を持つ
• AIは提案と補助
• 最終判断は人間

実践例:

1. 要件を人間が理解
2. 設計を人間が考える
3. 実装でAIを活用
4. レビューは人間が行う

メリット:

• コードの質を維持
• 学習機会を失わない
• 責任の所在が明確

タイプB: ゴースト型（非推奨）

AIに丸投げして結果だけもらう。

特徴:

• 人間は要件を伝えるだけ
• AIが全部やる前提
• レビューも適当

問題点:

• バグに気づけない
• セキュリティリスク
• スキルが向上しない
• 保守が困難

タイプC: 先生型（学習時）

AIを教師として使う。

特徴:

• わからないことを質問
• コードの説明を求める
• 複数の実装案を比較

実践例:

「このコードとこのコード、どちらが良い？理由も説明して」
「このエラーの原因は？どう修正すべき？」
「この設計パターンの使い所を教えて」

メリット:

• 効率的に学習できる
• 理解が深まる
• スキルアップにつながる

現実的な時間配分

AIを使った場合と使わない場合の比較（実測値）：

小規模機能（CRUD API 1つ）

工程	AI なし	AI あり	差分
設計	30分	30分	±0
実装	2時間	40分	-67%
テスト作成	1時間	15分	-75%
ドキュメント	30分	10分	-67%
合計	4時間	1時間35分	-60%

中規模機能（認証システム）

工程	AI なし	AI あり	差分
設計	2時間	2時間	±0
実装	8時間	4時間	-50%
テスト作成	3時間	1時間	-67%
デバッグ	2時間	2.5時間	+25%
ドキュメント	1時間	20分	-67%
合計	16時間	9時間50分	-38%

注目点:

• 設計フェーズは変わらない（人間の仕事）
• デバッグは増えることもある（AIのバグ修正）
• 全体では30-60%の時間短縮

大規模機能（マイクロサービス）

工程	AI なし	AI あり	差分
設計	1週間	1週間	±0
実装	3週間	2週間	-33%
テスト作成	1週間	3日	-57%
結合テスト	1週間	1週間	±0
デバッグ	1週間	1.5週間	+50%
ドキュメント	3日	1日	-67%
合計	7.4週間	5.8週間	-22%

傾向:

• 規模が大きいほど効率化率は下がる
• 複雑さが増すとAIの精度も下がる
• デバッグ時間は増加傾向

使い分けの判断基準

実際に使ってみて、こういう基準で判断している：

AIに任せる（効率的）

• ボイラープレートコード
• 型定義の自動生成
• テストコードの骨組み
• ドキュメントコメント
• 簡単なデータ変換処理
• よくあるパターンの実装

人間が書く（確実）

• ビジネスロジックの核心部分
• セキュリティクリティカルな処理
• パフォーマンス重視の処理
• プロジェクト固有の複雑な処理
• 既存コードとの綿密な統合

協働する（バランス）

• API設計（AIが提案→人間が判断）
• リファクタリング（AIが案出し→人間が選択）
• エラーハンドリング（AIが基本形→人間が調整）
• データベース設計（AIが初期案→人間が最適化）

トラブルシューティング

問題1: 提案が出ない

原因:

• ファイルサイズが大きすぎる
• コンテキストが不足
• 言語サポートが弱い

対策:

# 1. ファイルを分割
# 2. コメントでコンテキスト追加
# 3. より具体的にChatで指示

問題2: 的外れな提案

原因:

• プロンプトが曖昧
• プロジェクトの規約を理解していない

対策:

# Custom Instructionsを設定

# プロンプトをより具体的に

# 既存コードを参照として提示

問題3: 古い情報に基づいた提案

原因:

• 学習データが古い
• 最新フレームワークに未対応

対策:

「2026年の最新のReact 19で実装して」
「Next.js 15のApp Routerを使って」
のように、バージョンを明示

問題4: 同じ提案の繰り返し

原因:

• AIが文脈を理解していない
• キャッシュの問題

対策:

# 1. チャット履歴をクリア
# 2. より詳細な指示を追加
# 3. 別のアプローチを明示的に指示

実践的なTips

Tip 1: コメントドリブン開発

先にコメントで処理を書いてからAIに実装させる：

// ユーザーをメールアドレスで検索
// - 存在しない場合は404エラー
// - パスワードをbcryptで検証
// - 一致しない場合は401エラー
// - JWTトークンを生成して返す

// ← ここでTabを押すと、上記の処理を実装してくれる

Tip 2: 段階的な実装

一度に全部やらせずに、段階的に実装：

// Step 1: まず基本形を実装させる
function login(email, password) {
  // 基本的な処理
}

// Step 2: エラーハンドリング追加
// 「エラーハンドリングを追加して」

// Step 3: バリデーション追加
// 「入力バリデーションを追加して」

Tip 3: 既存コードを参照

「このファイルのgetUser関数と同じスタイルで、
updateUser関数を実装して」

Tip 4: 比較検討

「このタスクを実装する方法を3つ提案して。
それぞれのメリット・デメリットも」

Tip 5: テストファースト

# 1. まずテストコードを生成
# 2. テストを通るように実装
# 3. リファクタリング

学習への影響

良い影響

1. 効率的な学習

   • わからないコードの説明を即座に得られる
   • 複数の実装方法を比較できる
   • ベストプラクティスを学べる

2. 実験しやすい

   • 新しい技術を試すハードルが下がる
   • 失敗のコストが低い
   • プロトタイプを素早く作れる

悪い影響（注意）

1. 思考停止のリスク

   • AIに頼りすぎて自分で考えなくなる
   • アルゴリズムを理解しないまま使う
   • デバッグ能力が育たない

2. 基礎の軽視

   • 動けばいいと思ってしまう
   • なぜそうなるかを理解しない
   • 応用が効かない

対策:

• AIのコードを写すだけでなく、理解する
• 定期的にAIなしでコーディング
• アルゴリズムとデータ構造は別途学習

結論: AIコーディングの現実的な使い方

2026年現在、AIコーディングアシスタントは「革命」ではなく「良い道具」。

現実的な期待値:

• 30-60%の時間短縮（タスク次第）
• ボイラープレート削減
• ドキュメント作成の自動化
• 学習の効率化

過度な期待は禁物:

• AIが全部やってくれるわけではない
• 人間の判断は不可欠
• バグはある
• セキュリティリスクもある

推奨される姿勢:

1. AIは道具として活用
2. 最終判断は人間が行う
3. 生成されたコードは必ずレビュー
4. 学習機会として活用
5. 基礎知識は別途習得

適切に使えば、確実に生産性は向上する。ただし、AIに丸投げするのではなく、 人間が主導権を持ち、AIを補助として使うのが現時点でのベストプラクティス。

---

このドキュメントの更新:

• AIの進化に応じて定期的に見直し
• 実際の使用経験を追記
• 新しいTipsを追加

フィードバック歓迎: 実際に使ってみた感想や、追加すべき内容があれば教えてください。