当社ではエージェント型AI(自分でプロジェクト全体のコードを大まかに調査把握できる)も含めて使ってみてAIでどれだけソフトウェア全体を構築できるのかを制作しながら実験していますが、その際にコードが増えれば増えるほどAIのコーディングパフォーマンスが低下する問題が発生することが体感としてわかってきました。

AIを使ったソフトウェア開発は急速に普及していますが、実際に使ってみると「Aiの作業がどんどん遅くなった」「コードが大きくなればなるほどバグが増えた」という経験をする人も多いはずです。この記事では、AIとの開発でよく起きる問題とその原因、効率的な使い方のコツ、そして今後の展望まで、解説します。

1. AIでの開発で作業が遅くなる・バグが増えるのはよくあること？

結論からいうと、よくある問題です。 主な原因は以下の通りです。

コンテキストウィンドウの問題

  • AIはセッション間で記憶を持たないため、毎回コードベース全体を「再読み込み」する必要がある
  • コードが大きくなるほど、関連ファイルをすべて渡すのが難しくなる
  • 重要なコンテキストが抜けると、AIが的外れな変更をしやすい

「大量検査」によるバグの典型パターン

  • 変更が必要な箇所以外も書き換えてしまう（余計な「改善」）
  • 古いコードと新しいコードが混在して一貫性が崩れる
  • 長いファイルの後半部分の精度が落ちる

作業が遅くなる理由

  • プロンプトが長くなるほど応答も遅くなる
  • バグが増えると修正サイクルが増えて逆に時間がかかる
  • AIの出力をレビューする人間の負担も増える

実際に効果的な対策

  • ファイルを小さく・責務を明確に保つ（1ファイル＝1責務）
  • 毎回全コードを渡さず、関連部分だけを渡す
  • 変更指示を具体的・局所的にする（「このfunctionだけ直して」）
  • エージェント型ツールを使う
  • テストを書いておく（AIの変更が壊れたかどうかすぐわかる）

2. 命名規則とコメントはAIの精度に影響する？

命名規則はAIにとって非常に重要

AIは人間と同様に（むしろそれ以上に）名前からコンテキストを推測します。

# ❌ AIが意図を読みにくい
def proc_d(x, flag):
    ...

# ✅ AIが即座に意図を理解できる
def calculate_daily_discount(price, is_member):
    ...

命名が明確だと、修正箇所の特定が速くなり、関係のない箇所を誤って書き換えるリスクが下がります。

コメントはAIが読む？ → 読みます。むしろ人間より活用します。

# TODO: エラーハンドリング未実装
# NOTE: この処理はAPIレート制限を考慮すること
# FIXME: 大量データ時にメモリ不足になる可能性

TODOやFIXMEも拾ってくれるため、意図的なコメントはAIへの指示書にもなります。 ただし、古くなった嘘コメントは逆効果で、AIが間違った方向に修正することがあります。

最初からAIにプログラムさせるべき？

状況 判断
新規プロジェクト ✅ 最初から任せた方が一貫性が高い
既存コードの改修 ⚠️ AIの命名・構造に統一するか、既存に合わせるか明示が必要
複数人開発 ⚠️ チームの規約とAIの癖が衝突しやすい

最初からAIに作らせるメリットは、命名・構造・コメントスタイルが一貫することです。ただし、最初にきちんと設計方針・命名規則・使用ライブラリをプロンプトで指定しないと、AIが勝手に好みのスタイルで作ってしまいます。この一貫性はそれほど高くなさそうなので、命名規則がしっかりしていれば人間が書くのと大差がないかと思われます。

「設計書プロンプト」を毎回冒頭に渡すのが効果的です：

# プロジェクト規約
- 言語: Python 3.12
- 命名: snake_case、動詞+名詞形式
- コメント: 関数には必ずdocstring
- エラー処理: 例外は必ずログ出力
- 禁止: グローバル変数、マジックナンバー

3. コードが膨れ上がった場合の効率的な修正方法

「調査→修正」の二段階が精度を上げる

AIは一度のプロンプトで「考える」と「書く」を同時にやると精度が落ちます。段階を分けることで、それぞれに集中させられます。

❌ 一発指示：「バグを直して」
→ AIが調査と修正を同時にやって、的外れな変更をしやすい

✅ 二段階：「まず影響範囲を調べて」→「では修正して」
→ 調査結果を人間が確認してから修正に入れる

効果的な段階分けパターン

① 調査フェーズ（コードを書かせない）

「このコードベースで○○機能を追加したい。まず修正が必要なファイルと関数を列挙して。コードは書かなくていい。」

→ ここで人間がリストを確認・修正できる

② 影響分析フェーズ

「上記の変更をした場合、他にどこが壊れる可能性がある？依存関係を調べて。まだ修正しなくていい。」

→ 見落としを防げる

③ 修正フェーズ（局所的に）

「では user_service.py の fetch_user() だけを修正して。他のファイルは触らないこと。」

コードが膨れた場合の追加テクニック

  • 地図を先に作らせる：「このコードベースの構造を説明して。各ファイルの責務と主要な関数の関係を図にして。」→ メモしておくと次回以降のコンテキスト圧縮に使える
  • 差分だけ渡す：ファイル全体を毎回貼るのではなく、「前回からの変更点はここだけ」と差分だけ渡す
  • 修正の順序を決めさせる：「依存関係の少ない順に修正順序を提案して。一つずつ確認しながら進めたい。」

推奨フェーズ分け

フェーズ 目的 コードを書かせる？
調査 影響範囲の把握 ❌
設計 修正方針の合意 ❌（擬似コード程度）
実装 局所的な修正 ✅（ファイル単位）
検証 テスト・確認 ✅（テストコードのみ）

人間がレビューできるチェックポイントを意図的に挟むのが本質です。AIを「一発で全部やる機械」ではなく「思考パートナー」として使う感覚が重要です。

4. ファイルをピンポイントで指定するために必要な人間のスキル

AIを使いこなすほど、人間側のスキルが重要になるという逆説的な現実があります。

必要なスキル①：アーキテクチャを頭に入れる力

コードを全部読まなくても「どこに何があるか」を把握する能力です。

プロジェクト構造を即座に読める
├── 認証関連 → auth/
├── DB操作  → repositories/
├── ビジネスロジック → services/
└── API定義  → routes/

「ログインバグ」→ auth/ か services/ を見ればいい
と即座に判断できる

AIに全部任せているとこの感覚が育たないのが最大のリスクです。

必要なスキル②：依存関係を追う力

修正するファイルを特定するには「どこが何を呼んでいるか」を理解する必要があります。スタックトレースを読む力、呼び出し元を逆にたどる力、データの流れを図で思い描く力が求められます。

必要なスキル③：ログ・エラーの読解力

❌ 「なんかエラーが出た」→ AIに丸投げ
✅ 「line 47のこの例外を見ると、DBの接続処理で失敗してる。
   db_connection.pyを見て」

ログを読んで原因の仮説を立てられるかどうかが、AIへの指示精度に直結します。

人間が行うべき習慣

  • 自分でドキュメントを書く（AIに書かせても読む）：どのファイルに何があるかのメモが、指示精度を劇的に上げる
  • 変更履歴を人間が把握する：Gitのコミットログを定期的に見る。「最近どこを触ったか」が頭に入ると、バグ原因を絞りやすい
  • 小さく動かして確認する習慣：AIに大きな修正をさせる前に、手動で該当ファイルを開いて眺め、関係する関数名・変数名を確認してから指示する

AIで代替できるスキルとそうでないスキル

スキル AIで代替できる？
コードを書く かなり代替可能
アーキテクチャ把握 代替困難
エラーの仮説立て 部分的に可能
影響範囲の判断 代替困難
何を作るかの判断 代替困難

AIが得意なのは「どう書くか」であって、「どこを・何を」は人間の判断が精度を左右します。

5. 今後の展望：忖度なしの未来予測

確実に改善していく部分

コンテキストウィンドウの拡大
現在でも100万トークン超のモデルが存在し、大規模コードベースを丸ごと読めるようになってきています。「関連ファイルだけ渡す」という作業自体が不要になる方向です。

エージェント型ツールの進化
Claude Codeのようなツールが成熟すれば、「このバグを直して」の一言で、自分でリポジトリを調査→影響範囲を特定→テストを書いて確認→修正完了、という流れが現実的になります。すでに部分的には動いています。

長期記憶・プロジェクト記憶
今は会話をまたいで記憶できませんが、プロジェクト全体の構造を記憶し続ける仕組みの研究・実装が進んでいます。

改善が難しい・遅い部分

「何を作るか」は人間が決め続ける
これは技術的な問題ではなく本質的な問題です。AIは「言われたものを作る」のは上手くなりますが、「何を作るべきか」を判断する主体にはなれません。要件定義・仕様判断は人間の仕事であり続けます。

責任の問題
AIが自律的に大規模修正をした場合、バグの責任は誰が取るのかという問題が解決していません。企業・法律レベルの整備が技術より遅れているため、「人間がレビューする」ステップはしばらく残ります。

幻覚（ハルシネーション）の完全解消は困難
精度は上がっていますが、自信満々に間違えるリスクはゼロにはなりません。特に古いライブラリのAPI、プロジェクト固有のビジネスロジック、曖昧な仕様の解釈には、今後もチェックが必要です。

タイムライン別予測

3〜5年以内

  • 単純なCRUDアプリ・社内ツール程度はAIがほぼ作れるようになる
  • ジュニアエンジニアの仕事の多くはAIが代替する
  • ただしレビューする人間は必須で、その人間には高いスキルが求められる

5〜10年

  • ソフトウェアエンジニアの人数は減るが、一人あたりの生産性は劇的に上がる
  • 「コードを書けるかどうか」より「システムを設計・判断できるか」で価値が決まる
  • AIが書いたコードのリスク管理・監査という新しい職種が生まれる

変わらないこと

  • ユーザーが何に困っているかを理解する力
  • トレードオフを判断する力
  • システム全体の整合性を保つ責任感
  • おかしいと気づく感覚（経験から来るもの）

まとめ

AIツールは確実に強力になっていきます。

AIの限界を理解して、適切に使うという思考そのものが、今後最も重要なスキルになっていくでしょう。「AIに何でも任せる」のではなく、「AIを思考パートナーとして活用する」姿勢が、これからのエンジニアに求められてくるかもしれません。

関連記事:

  1. AIで中規模ソフトウェアを丸ごと作るのは可能か？その方法論と限界
    AIは単一ファイルの生成は得意ですが、複数ファイルにまたがる設計の一貫性・依存関係の維持が苦手です。「とりあえずAIに投げる」だけでは、後から修正も拡張もできない壊れやすいコードが生まれます。この記事では、それを防ぐための具体的な方法論を解説します。 ⚠️ まず知っておくべき：AIへの矛盾した指令は危険 AIは「矛盾をエラーで止める」コンパイラではありません。矛盾した指令を与えると、次のような問題が起きます。 パターン...
  2. 【完全無料】Ollamaで“ChatGPTみたいなAI”をローカルPCで動かす方法｜VRAM 8GBでもOK・セキュリティ安心
    「ChatGPTみたいなAIを、自分のPCだけで無料＆無制限に使いたい」 そんな人におすすめなのが、ローカルAI実行ツール Ollama と、高性能モデル DeepSeek-R1...
  3. LLMはなぜコードが書けるのか？現状・限界・リスク
    ChatGPTやClaude、GitHub CopilotなどのLLM（大規模言語モデル）が、プログラムコードをすらすら書く姿を見て「なぜ？」と思ったことはないでしょうか。また、実際に使ってみると「意外と使えない場面もある」と感じた方も多いはず。 この記事では、LLMがコードを書ける仕組みから、現在の実用レベル、エラーを防ぐ方法、そして将来の限界までを解説いたします。 なぜLLMはプログラムが書けるのか コードも「テキスト」だからです。...
  4. Python（embed版）でCUDA対応PyTorchを使ったGPU推論環境の作り方
    はじめに 最近のGPU環境では「CUDAは自動で入っているのか？」「PyTorchはどこまで自動でやってくれるのか？」といった疑問を持つ人が多いと思います。 この記事では、Pythonのembed版（ポータブル環境）でCUDA対応PyTorchを使ったGPU推論を行う方法を、最小構成でわかりやすく解説します。 結論（重要ポイントまとめ） RTX...
  5. PyInstallerでStable DiffusionやQwenなどAIアプリをスタンドアロン化する方法と注意
    Python製のAIアプリ（Stable Diffusion、Qwen、Wanなど）を「Python未導入のPCでもそのまま動くスタンドアロン実行ファイル」にしたい場合、よく使われるのが PyInstaller です。 pip...
  6. Stable Diffusion U-Net の ONNX に別の ONNX モデルを結合する方法
    Stable Diffusion ONNX U-Net に別モデルを統合する方法...