Claude CodeやMCPを実務で使って見えてきた現実。AIエージェントは誰でも使える魔法ではなく、エンジニアリングの知識があるほど真価を発揮する増幅器だった。
「AIがあればエンジニアいらない」——本当にそう思いますか？
ここ1〜2年で、AIエージェントという言葉をよく耳にするようになりました。「Claude Codeに指示したらコードが自動で書けた」「ChatGPTにお願いしたらブログ記事が量産できた」——そんな話題がSNSを賑わせています。
経営者の方から「うちもAIエージェント導入すればエンジニアに頼まなくてよくなりますよね？」と聞かれることも、正直、増えてきました。
その問いに対して、私たちFIVENINEは**「半分正しくて、半分まったく違う」**とお答えしています。
私たちはClaude Code、MCP（Model Context Protocol）、AI記事生成パイプライン、動画自動化など、複数のAIエージェントを実務に投入してきました。その経験から見えてきたのは、**「AIエージェントはエンジニアの代替ではなく、エンジニアの能力を10倍に増幅させるツール」**だという現実です。
この記事では、実際の業務で直面した「5つの壁」を通じて、AIエージェントを本当に使いこなすために何が必要かを、技術者視点でリアルにお伝えします。エンジニアの方には「そうそう、あるある」と共感していただけるはず。非エンジニアの経営者・Web担当者の方には、「だからプロのエンジニアに任せる価値があるんだ」と腹落ちしていただける内容になっています。
AIエージェントとは何か——まず認識をそろえよう
AIエージェントとは、単に質問に答えるAI（ChatGPTへの一問一答）ではなく、複数のツールやAPIを組み合わせて、一連のタスクを自律的に実行するAIシステムのことです。
flowchart LR
A[人間の指示] --> B[AIエージェント]
B --> C[コード生成]
B --> D[ファイル操作]
B --> E[API呼び出し]
B --> F[ブラウザ操作]
C --> G[実行・検証]
D --> G
E --> G
F --> G
G --> H[結果を返す]たとえば私たちが使っているClaude Codeは、コードの読み書きだけでなく、ターミナルでコマンドを実行し、エラーを読み取り、修正し、再実行する——という一連のループを自律的にこなします。MCPを使えば、GitHubやSlack、データベースとも直接連携できます。
ここが重要なポイントです。 この「自律的に動く」という部分こそが、エンジニアリング知識なしには制御できない領域を大量に含んでいます。
壁1：環境構築の壁
「まずツールを動かす」ことすら、一仕事
AIエージェントを使い始めるには、それを動かすための環境が必要です。これが最初にして最大のハードルです。
たとえばClaude Codeを本格的に活用しようとすると、以下のような環境が前提になります。
# Node.js環境の確認
node -v # v18以上が必要
npm -v
# Claude Codeのインストール
npm install -g @anthropic-ai/claude-code
# MCPサーバーの設定（例：Filesystemツール）
# ~/.config/claude/claude_desktop_config.json に設定を追記
MCPの設定ファイルを書くだけでも、JSONの構文、パスの概念、環境変数の扱い、APIキーの管理といった知識が次々と要求されます。さらに既存のLaravelプロジェクトと連携しようとすると、DockerのネットワークやPHP環境との整合性も考慮しなければなりません。
よくある失敗パターン
APIキーを .env ではなくコード内にハードコーディングしてしまい、Gitにそのまま push してしまうケース。AIエージェント自身が「とりあえず動く」コードを生成したとき、セキュリティ的に問題のある書き方になっていることがあります。この手の事故については、VS Code拡張機能のセキュリティリスクでも詳しく取り上げていますが、開発環境のセキュリティは常に意識が必要です。
乗り越えのヒント
まずDockerで隔離された開発環境を用意し、APIキーは必ず環境変数で管理する習慣を作りましょう。docker-compose.yml で環境をコード化しておけば、チームメンバー間での再現性も担保できます。
壁2：プロンプト設計の壁
「いい感じにして」では動かない
これは非エンジニアの方が最もつまずく壁です。AIエージェントへの指示（プロンプト）は、曖昧であればあるほど、出力の品質が下がります。
たとえばLaravelのAPI開発でClaude Codeに指示するとき、次の2つでは結果が天と地ほど違います。
「ユーザー登録機能を作って」
→ 認証方式は？バリデーションルールは？ レスポンス形式は？エラー処理は？ 何も決まっていないので、AIが「それっぽいもの」を 勝手に作り、後で全部作り直しになる。
的確なプロンプトを書くためには、コードの構造・設計パターン・フレームワークの仕様を理解していることが前提です。「どんな制約の中で何を作るか」を言語化できるのは、エンジニアリングの知識を持っている人だけです。
乗り越えのヒント
「コンテキスト → 制約 → 期待する出力形式」の3点セットで指示を組み立てる習慣が効果的です。さらにClaude Codeでは CLAUDE.md というプロジェクト設定ファイルにアーキテクチャの概要や命名規則を書いておくことで、毎回説明しなくてもよくなります。
壁3：エラーハンドリングの壁
AIの出力は「常に正しい」わけではない
AIエージェントが生成したコードが一発で動くことは、複雑なシステムほど少なくなります。むしろ**「それっぽく見えるが微妙にずれている」**アウトプットが出てくることの方が多い。
実際に私たちがNext.jsプロジェクトでAIエージェントを活用したとき、生成されたコードのエラーログは次のようなものでした。
TypeError: Cannot read properties of undefined (reading 'data')
at BlogList (components/BlogList.tsx:24:18)
at renderWithHooks
このエラーを読んで「非同期フェッチの完了前にデータにアクセスしている」と瞬時に判断し、optional chaining や loading state の追加で解決できるのは、JavaScriptとReactの動作を理解しているエンジニアだからです。
AIエージェント自身にエラーを渡して修正させることもできますが、「何が問題なのか」を判断してAIに正しく伝え、その修正案が妥当かを評価するのは人間のエンジニアの仕事です。
よくある失敗パターン
AIが「エラーを修正しました」と言ったので信じたら、別の場所で新しいバグが発生していた——というケース。AIはローカルなエラーを直すために、他の箇所の整合性を壊すことがあります。「動いた」と「正しく動いている」は別物です。
壁4：品質管理の壁
「動くコード」と「良いコード」は違う
AIエージェントが書いたコードをそのまま本番に投入するのは、非常に危険です。これは、AIを信頼していないという話ではなく、レビューなしのコードをリリースすること自体がエンジニアリングとしてあり得ないという話です。
私たちがAI生成コードのレビューで実際によく見つける問題は以下のようなものです。
- SQLインジェクションの可能性：クエリビルダーではなく生のSQL文字列が使われている
- N+1問題：ループ内でDBクエリが発生し、パフォーマンスが劣化する
- 認証チェックの漏れ：エンドポイントに
auth:sanctumミドルウェアが付いていない - XSSの可能性：ユーザー入力をサニタイズせずにHTMLに直接出力している
AIエージェントの出力を過信することのリスクについても、私たちは別の記事で詳しく論じています。AIはコード生成の速度を劇的に上げてくれますが、セキュリティと品質の最終判断は人間のエンジニアが担わなければなりません。
乗り越えのヒント
AI生成コードにも通常の開発と同じレビューフローを適用しましょう。PHPStanやESLintによる静的解析、PHPUnitやVitestによる自動テストをCIに組み込んでおけば、機械的に品質の下限を担保できます。「AIが書いたから大丈夫」ではなく「CIが通ったから大丈夫」という文化を作ることが重要です。
壁5：統合・運用の壁
「作れる」と「本番で動かせる」はまったく別の話
ローカルで動いたAIエージェントの成果物を、実際のプロダクション環境に統合し、安定して運用するのは純粋なエンジニアリング作業です。
私たちがAI記事生成パイプラインを本番運用する際に対応した項目を挙げると、その難易度が伝わるかと思います。
# GitHub ActionsでのCI/CDパイプライン例（抜粋）
jobs:
deploy:
steps:
- name: Run AI content generation
run: php artisan ai:generate-articles --schedule=daily
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
- name: Quality check generated content
run: php artisan ai:review-content --strict
- name: Deploy to production
run: ./deploy.sh --zero-downtime
- APIレート制限の管理：Anthropic APIの呼び出し回数を監視し、超過しないようにキューで制御
- エラー時のリトライとフォールバック：生成失敗時に通知を送り、前回の結果にフォールバック
- コスト管理：APIの使用量を記録し、月次コストを予測する仕組みの構築
- 既存のLaravelシステムとの統合：既存のDBスキーマ、認証、キャッシュレイヤーとの整合性確保
これらはすべて、CI/CD、クラウドインフラ、既存システムのアーキテクチャを理解していなければ手が出ない領域です。
よくある失敗パターン
AIエージェントをローカルで試してうまくいったので「もう完成だ」と本番に手動デプロイしてしまい、環境差異でエラー発生。しかもロールバックの手順がないため、本番障害が長引く——というケースです。「動いた」と「運用できる」は、工数にして数倍の差があります。
エンジニア vs 非エンジニアが同じAIエージェントを使うと何が違うか
| フェーズ | エンジニアが使う場合 | 非エンジニアが使う場合 |
|---|---|---|
| 環境構築 | Docker+API設定を30分で完了 | インストールで数日詰まる可能性 |
| プロンプト設計 | 構造・制約・出力形式を明確に指定 | 曖昧な指示で期待外れの出力が続く |
| エラー対応 | ログを読んで根本原因を特定・修正 | 何が悪いかわからず試行錯誤で終わる |
| 品質管理 | コードレビュー・テスト・セキュリティ確認 | 「動いているように見える」で終了 |
| 本番運用 | CI/CD・監視・ロールバック計画まで整備 | 手動作業の繰り返しでミスが発生しやすい |
| ROI | 生産性が5〜10倍に増幅 | 一時的に便利だが品質リスクが残る |
同じAIエージェントを使っても、エンジニアリングの知識があるかどうかで、アウトプットの質と速度に雲泥の差が出ます。
AIエージェント時代、エンジニアの価値はむしろ上がっている
「AIがエンジニアの仕事を奪う」という言説は、少なくとも現時点では現実と乖離しています。私たちが体感しているのは正反対の現象です。
AIエージェントが得意なのは「既知のパターンを高速に実装すること」。一方でエンジニアが担うべきは「何を作るべきか設計すること」「品質と安全を保証すること」「システム全体を統合して運用すること」——これらはAIが自律的にこなせる領域ではありません。
むしろエンジニアリングスキルが高い人ほど、AIエージェントから得られる恩恵が大きくなります。ルーティンな実装の時間が減り、設計・判断・最適化という高付加価値な仕事に集中できるようになるからです。
FAQ
このAI技術、御社の業務にも導入できます
AI導入・業務自動化
ChatGPT活用や業務自動化など、最新のAI技術を御社に合わせてご提案します
※ 通常1営業日以内にご返信します
まとめ：AIエージェントはエンジニアの「代替」ではなく「増幅器」
5つの壁を整理すると、こういう結論になります。
AIエージェントは「使えば誰でも同じ結果が得られるツール」ではありません。 環境構築・プロンプト設計・エラーハンドリング・品質管理・システム統合——これらすべてにエンジニアリングの知識と経験が必要です。
エンジニアにとっては、AIエージェントは最強の武器になります。1日かかっていたコーディングが数時間に短縮され、その分をアーキテクチャの設計や品質向上に使えます。非エンジニアの経営者・Web担当者の方にとっては、「だからこそプロのエンジニアに頼む価値がある」という話でもあります。AIエージェントを正しく制御できるエンジニアの価値は、AI登場後も変わらず——むしろ高まっています。
FIVENINEでは、LaravelやNext.jsを使った開発に加え、AIエージェントを活用した業務効率化・自動化の設計・実装もご支援しています。「AIを使ってこんなことができるか試したい」「今の業務フローをもっと効率化したい」といったご相談から、ぜひお気軽にお声がけください。
