企業における生成AIの活用は実験段階から本格活用のフェーズへと進んでいます。一方で、「AIツールを導入したものの、思ったほどの成果が出ない」「現場での定着が進まない」という課題を抱える企業も少なくありません。
本記事では、システム開発現場でAI活用に関する改善活動を 1 年間継続してきた試行錯誤の経験とデータから得た知見について、エンジニアの役割変化や組織への定着アプローチなどの視点も織り交ぜながら解説します。
（2026年7月8日に実施したウェビナーの内容をもとに記事化しています）
データで見る生成AI活用の現実
世の中の動向と生産性向上の実態
企業の約9割において生成AIの実験段階を脱し、本格的な活用のフェーズに入ってきています。なかでも「システム開発」の生産性については、平均で約19%向上し、先行企業では30%から50%向上したという報告もあります※1。
こうした生産性向上の報告がある一方で、「ツールを入れたのに思ったほど変わっていない」「まったくうまく活用できていない」という声も少なくありません。その差を生む要因は、単なるAIツールの性能の問題ではなく、それを使いこなす「文化」と「プロセス」、すなわちどのように進めていくかという点が重要です。
※1 Gartner、Anthropic Economic Index 等の公開情報（2025〜2026年）を基に整理
NCDC社内における1年間の開発実績データ
NCDCでは社内の開発においてAIエージェントを積極的に導入してきました。導入自体は3年ほど前から順次進めていましたが、特に2025年からは開発への活用が急速に進み、複数のツールの導入と検証を繰り返し実施してきました。
その結果、開発量（週あたりのプルリクエスト数＝新機能開発や改善の件数）が、1年前の週126件から267件へと、1年間で約2倍に増加しました。
このデータを詳細に分析すると、大きく3つの変化が読み取れます。
- 開発量※2が2倍に増加しているが、急激に増えたわけではない：特定のツールを導入した瞬間や制度を変えた瞬間に急増したのではなく、少しずつ着実に増えています。単発の施策が当たったのではなく、継続的な改善を積み重ねた結果です。
- レビューに必要な時間が短縮されている：人間のレビュー作業が急に速くなったわけではなく、レビュープロセスにもAIを活用し、AIにある程度事前チェックを担わせることで時間短縮を実現しています。
- 1つの修正にかかるスピード（リードタイム）は大きく変わっていない：一般的に開発量が増えると1件あたりの作業が間延びして滞りがちになりますが、リードタイムの悪化は防げています。一方で、1件ごとの開発スピードそのものが劇的に速くなったわけではないという側面もあります。
※2 本記事での「開発量」は、新機能・改善の件数であるプルリクエスト数を指します（グラフ中の「PR」表記）
改善を支えた「3つの継続」と見えてきた課題
AI活用により着実に右肩上がりの開発量増加を継続できた背景には、3つの要素が揃っていたことが挙げられます。
- 環境の整備：新しいツールの検証、利用許可、契約の見直しを絶えず実施したこと。
- ルールの整備：環境だけ整えて何でも自由に作ってよいとすると、ガバナンスが効かなくなります。そのため、セキュリティレベル別の利用ガイドラインを整備し、新ツールの登場や世の中の動向に合わせて改定を繰り返したこと。
- メンバーの習熟：ツールを入れただけで自動的に成果が出ることはないため、メンバーが日常的に使いながら活用法を磨き続けたこと。
これらに加え、レビューへのAI活用、設計・要件定義・テストといった上流から下流へのAI活用拡大、ルールや開発環境の標準化など、仕事の進め方自体を進化させてきました。
一方で、AI活用による新たな課題も生じています。
1点目は、「1回あたりの開発量が大きくなりがち」という点です。AIは一気にコードを生成してくれるため、1回の変更量が膨らみやすくなります。個人開発であれば問題ありませんが、チーム開発では変更量が大きくなると影響範囲が広がり、問題発生時の手戻りも大きくなります。できる限り変更を小さく保つための改善余地がまだあります。
2点目は、「開発量が増えた分だけ、人間の判断業務が確実に増えている」という問題です。この問題については、次の章で詳しく説明します。
AI活用によるエンジニアの役割の変化
AI駆動開発の本質は「実行はAI、判断は人間」
AI駆動開発の本質は、「実行はAIに任せ、判断は人間に残す」という点にあります。
コードの記述、テストの実施、問題が発見された際の修正といった「実行」部分は、AIに任せてしまって問題ありませんし、任せた方が開発は格段に速くなります。
一方で、「この設計で本当に良いか」「メリットとデメリットのトレードオフをどこまで受け入れるか」「障害が起きた際に今すぐ修正すべきか、1ヶ月後の対応でも問題ないのか」といった「判断」の部分は、AIに任せきりにすることはできず、人間に委ねられます。
すべてをAIに丸投げしてしまうと、誰も把握していない負債をAIが勝手に作り込み、後々大きな問題を引き起こしてしまいます。したがって、判断は人間が責任を持って残さなければならない部分です。
エンジニアに求められるスキルの変化
こうしたことを踏まえると、AI時代のエンジニアに求められるスキルは従来のものから大きく変化すると考えられます。
- これまでのエンジニア：コードを書く人。実装の速さや量が価値の中心。開発の中心は「コード」
- これからのエンジニア：仕様を書き、AIを操り、品質を担保する人。良い判断を任せられることが価値の中心。開発の中心は「仕様・設計」
開発の価値基準の中心は、良いコードを書いた、速く大量に書いたといった「コードの記述」から、良い判断ができた、判断が任せられるといった「仕様・設計」へと移ります。かつて重要とされた実装の速さや量の価値は薄れ、全体設計を見通す力やSIer的な取りまとめ能力、設計の正しさを見極める能力が一般的なエンジニアにも強く求められるようになります。
「判断の需要増」と「人材不足」のボトルネック
開発量が2倍になれば、作られた成果物に対する「これでよいか」という判断の量も2倍になります。AIによって生産量が増えますが、適切な判断ができるのは一定の経験を積んだシニアやベテランのメンバーに限られていると、人間の判断が追いつかなくなり、人間自身がボトルネックになるという現象が発生します。
しかし、判断力は経験の積み重ねによってしか育たないため、人材育成には年単位の時間がかかります。AI駆動開発を真に成功させるためには、目先の短期的な効率化だけでなく、中長期的に判断力を持つメンバーを育成していく仕組みが不可欠です。
「判断できる人」を育成するポイント
効率化の代償と育成の課題
AI活用により「判断」の業務が増えていくという現象を放置すると、ベテラン層に負荷が集中します。ベテランは自らの開発・実装時間を奪われ、チーム全体の進行を滞らせるボトルネックになってしまいます。
一方で、若手層にも問題が生じます。実行作業をすべてAIに任せてしまうと、自分でコードを書いて試行錯誤したり、失敗から学んだりする機会が失われます。試行錯誤と修正のプロセスこそが学びの源泉であり、AIに丸投げする環境では若手が育ちにくくなるというジレンマに陥ります。
この構造は自然には解消しないため、経験の浅いメンバーでも意図的に経験と学びを得られるような仕組みを設計する必要があります。
関連記事「なぜ今、”本物のエンジニアリングスキル”が重要なのか？」
個人の成長と組織で取り組む工夫の両輪
では、どのように人材育成に取り組んでいけばよいのでしょうか。次のように、個人は「判断力」を磨き、組織は「判断できる人」を育てることを目指していく必要があります。
エンジニア個人の「判断力」の磨き方
- AIが生成したコードに対して設計の良し悪しを判断したり、メリット・デメリット両面がある際にデメリットをどこまで受け入れるかというトレードオフの感覚を身につけたりするために自ら学びに行く
- 従来重視されていた構文の暗記や決められたものを作る能力は、現在は価値が薄い
組織での「判断できる人」の育て方
- 判断が一部の人に集中しないように、レビューをあえて新人に任せるなど、判断できる人材育成を意識する
- 制度面では、評価の基準を「実装量」から「判断の質」へとシフトしていく
「判断できる人」を増やす育成の仕組み化
組織での「判断できる人」の育て方として、具体的には、以下のような工夫が考えられます。
- 評価基準の転換：実装量ではなく「判断の質」や「適切な判断を行ったか」を評価の基準に据える。
- レビュープロセスの見直し：単に指摘事項を直す場ではなく、設計思想や思考プロセスを言語化する場として位置づける。あえて若手にレビューを担当させ、判断の訓練を積ませる。
- 設計意図の資産化：なぜその設計にしたのかという背景を、ADR（アーキテクチャ決定記録）として文章に残し、組織の資産とする。
- 意図的な権限移譲と失敗の許容：あえて人間が手を動かして試行錯誤する領域を意図的に残す。
- ナレッジ共有会の開催：個人のプロンプトや使い方にとどまらず、判断のプロセスを含めてチーム内で共有する。
- マネージャー評価への組み込み：判断できる人材を育成できているかを、シニアやマネジメント層の評価基準に加える。
AI駆動開発とクラウドの親和性
クラウドとAI駆動開発が高い親和性を持つ理由
ここからは少し話題を変えて、AI駆動開発とクラウド・マネージドサービスの親和性について解説していきます。
クラウドでAIが活用できることはご存知の方が多いかと思いますが、AIを使った製品を作るだけでなく、一般的なアプリケーション開発においても、AI駆動開発とクラウドサービスは高い親和性を持っています。具体的には、以下のようなメリットがあります。
クラウドの特性によるメリット
- IaC（Infrastructure as Code）の利点：インフラ構築や運用もコードとAPIで操作可能
- 定型運用の自動化：クラウド側の便利なマネージドサービスを活用することで、定型的な運用業務を自動化できる
- 構成情報やログの構造化：システムログや設定情報が構造化され残る
これらはAIにとって非常に読み書きや操作がしやすい環境であるため、開発作業だけでなく、運用の自動化や監視領域へのAI適用が容易になります。マネージドサービスとAIに定型的な開発・運用を任せることで、人間はより上流の判断業務に集中できるようになります。
AI駆動開発を加速させるAWSの最新サービス
以下に、AI駆動開発に役立つAWSの具体的なツールやフレームワークをご紹介します。
Agent Toolkit for AWS
Claude Code 等のコーディングAIに、AWS 公式のスキルとMCP サーバーをまとめて組み込むプラグイン（オープンソース）です。コーディングAIにこれを連携させることで、AWSのベストプラクティスを理解した状態でコードを生成します。AIの操作権限を厳密に制御したり、すべてのリクエストを監査証跡として記録したりできるため、ガバナンスの維持にも寄与します。
サービスの特徴
- AWS公式の30種以上のスキルとMCPサーバーをプラグイン1つで導入
- 設計・構築・運用のAWSの知見をAIに与える
- Claude Code・Codexに対応
- AWS公式サポートのオープンソース
AI駆動開発との相性
- AIがAWSのベストプラクティスに沿ってコードを書ける
- AIの操作と人の操作をIAMで区別し、権限を絞れる
- 全リクエストを監査できるためガバナンスと両立
AWS DevOps Agent（Amazon DevOps Guru等）
監視やインシデント対応を自律的に支援するサービスです。AWS上でアラートを検知すると、調査、根本原因の特定、緩和策の提案までを自律的に実行します。メトリクスやログを横断して原因を推測し、Slack等と連携して通知します。
できること
- 検知→調査→根本原因特定→緩和策提案を自律実行
- メトリクス・ログ・デプロイ履歴を横断して原因を推論
- Slack・PagerDuty・CloudWatch等と連携
- 日次ヘルスチェックやログ異常検知の定期実行
できないこと
- 業務固有の判断ロジック
- 対応していない外部ツールとの連携
AWS Blocks
AIに開発させることを前提として設計された新しいアプリケーション開発フレームワークです。インフラを深く意識することなく、ブロックを組み合わせるような感覚でWebアプリケーションを構築できます。AI向けの手引きが標準で同梱されており、型が厳密に定義されているため、AIが生成したコードの誤りにも気付きやすい構造になっています。
サービスの特徴
- ブロックを組み合わせ、インフラは自動生成（数行から100超のAWSリソースを展開）
- ローカルだけで開発し、同じコードをそのままAWSへ
- Agent・KnowledgeBaseブロックでAI機能も標準部品
- モバイル向けのライブラリ生成にも対応
AI駆動開発との相性
- コーディングAI向けの手引きを標準同梱
- 型が厳密で、AIの書いたコードの誤りに気づきやすい
- 定型はブロック化済み、AIと人は差分に集中
チームに生成AI活用を定着させる実践アプローチ
AIを「単なる便利ツール」から「成果を生むツール」に変えるには、明確なルールを設けて、それを育て続けることが重要です。
AIは開発スピードを速めますが、その速さがそのまま成果になるとは限らないということはここまでに述べてきた通りです。AIは、従うべき開発のルールがあって初めて品質を伴います。
最低限のルールから始めて運用しながら育てる
最初から完璧なルールを作ろうとすると初期コストが大きくかかってしまいます。最適なルールはプロジェクトごとに異なるため、実際に使って初めて分かることも多くあります。また、生成AIの技術進化は極めて速いため、半年前の常識が通用しなくなることも多く、完璧なルールを作ってもすぐに陳腐化します。
そのため、「最低限のルールから始めて、運用しながら改善し、ルールと人を一緒に育てていく」アプローチが効果的です。
最初に整えるべき3つのルール
AIが意図を正しく理解し、品質を保って動くために、以下の3点をまず整えましょう。全工程をAI任せにせず、人が品質を担保することが重要です。
- 仕様・意図を残す：「何を作りたいか」「なぜその設計にしたのか」を言葉として残し、人間同士の理解を深めるとともにAIにも意図を正しく把握させる
- AIに現場の作法を教える：プロジェクトの規約や構造を明文化し、AIにその現場の流儀に沿ったコードを出力させる
- 品質は人が守る仕組みを作る：テストとレビューの仕組みで、品質の最終責任は必ず人が持つようにするテスト駆動開発（TDD）の導入や自動静的解析を組み込み、最終的な品質承認は必ず人間が行う
NCDC社内におけるAI活用定着のための取り組み
NCDCでは、AI活用を日常の営みとして定着させるために以下のような取り組みを行っています。
- 場をつくる：使い方の共有会や勉強会を日常的に開催。開発メンバーだけでなく、コンサルタントやPMなど他職種も巻き込み、学びを組織全体の共有知にする
- 型をそろえる：AIへの指示ルールや設定を標準化。専用リポジトリで全員に共有し、個人のノウハウを組織の資産にする
- 会社全体で活動する：部署横断のタスクフォースを設置。標準化や事例の全社横展開を推進する
業務利用に必要なAIガバナンスの構築
AIの活用を推進する一方で、業務でAIを開発に使う以上、次のような最低限の統制（ガバナンス）の確立も必須です。
- 情報漏洩の防止：機密データやソースコードをモデルの学習に利用させない設定を徹底し、データの送信・持ち出し制限を遵守します。
- 生成コードの品質・セキュリティ：静的解析や自動テストをパイプラインに組み込みます。人間のレビューを経ないマージは禁止します。
- 権限管理と監査ログ：人間およびAIに付与する権限を最小権限の原則に従って絞り込み、全リクエストの監査ログを取得して後から追跡できるようにします。
- コスト管理：利用枠の上限設定やコストの可視化・モニタリングを行い、想定外の費用急増を防ぎます。
ガバナンスは「基盤による統制」と「運用のルール」の2層で構築
| 観点 | 具体例 | 対策（基盤統制 ／ 運用ルール） |
|---|---|---|
| 情報漏洩 | ・ソースコード・機密情報の外部送信 ・モデル学習データへの利用 | Bedrock（入力をモデル学習に不使用）・送信制御 ／ 持ち出しルール |
| 生成コードの品質・脆弱性 | ・入力検証不足や過剰な権限付与 ・レビューなしのマージ | 静的解析のCI組込み ／ TDD(テスト駆動開発)の導入／ セキュリティエージェントによるAIレビュー |
| 権限・監査 | ・権限外の環境・データへの到達 ・「誰が・何を」の記録欠如 | IAMによる最小権限 ／ 操作ログ・監査証跡の取得 |
| コスト | ・利用量の急増 ・想定外の課金 | 利用枠の設定 ／ 利用状況の可視化・コスト監視 |
ガバナンス構築にあたっても、既存の社内セキュリティ規程をAIに読み込ませてドラフト案を作成させ、人間が確認・カスタマイズしていくアプローチをとることで、迅速かつ現実的なルール策定が可能になります。
まとめ：AI活用の「文化」と「プロセス」の育て方
ここまで、NCDCの開発現場における1年間の試行錯誤の結果から分かった「文化」と「プロセス」の育て方について説明してきました。
以下のポイントを押さえて、ぜひAIの活用を成果に繋げてください。
- AIは入れただけでは変わらない：ツールの導入だけでなく、使いながら習熟し、改善を積み上げる文化とプロセスが必要です。
- エンジニアの役割は「実行」から「判断」へ：コードが書けること自体の価値は低下し、適切な判断を担えることに価値がシフトします。
- 育成への投資で負荷の偏りを防ぐ：目先の効率化だけを追うとベテランへの負荷集中と若手の成長阻害を招くため、判断力を養う育成への投資が不可欠です。
- 定着の鍵は「文化とプロセス」：最低限のルールから小さく始め、プロジェクトや環境の変化に合わせて柔軟に育て続けていくことが成功への道筋となります。
質疑応答
2026年7月8日に実施したウェビナー「『AIを入れたのに変わらない』を脱する。ツール導入から文化定着まで、1年間の実践知を公開」での質疑応答もご紹介します。
Q. 良い判断ができる社員を育成するために、社内では具体的にどのような取り組みを行っていますか？
A. 社内でも試行錯誤を重ねている最中ですが、レビューのやり方を工夫しています。具体的には、まだ判断能力が十分に高くないメンバーにもあえてレビューを担当してもらい、「自分はこう考えた」「こういう理由でこの設計が良いと思う」という思考を文章として言語化・アウトプットしてもらっています。
また、レビューを一方通行の指摘で終わらせず、コードを書いた側からも「どういう意図で実装したのか」を説明してもらい、双方向で対話しながらお互いに判断力を高め合っていく取り組みを行っています。
Q. 生成AIの進化が非常に速く、情報の陳腐化が進みやすいと実感しています。エンジニアではない立場で効率よくキャッチアップするにはどうすればよいでしょうか？
A. 公式の一次情報をすべて追うのはエンジニアでないと難易度が高いと思います。個人的に最も効率的でおすすめなのは、X（旧Twitter）などのSNSの活用です。生成AIに関する新しい情報をいち早くキャッチアップして発信してくれている有識者を何人か見つけてフォローし、その発信を追うのが最も早くてわかりやすい方法だと思います。
Q. 自社にフィットしたAIガバナンスを構築するには、どのように進めるべきでしょうか？
A. 会社ごとに求められるセキュリティ水準や従来の規程があるはずですので、まずは既存のセキュリティルールを確認することが第一歩です。もし社内規程を読み解くのが大変であれば、その規程ドキュメント自体をAIに読み込ませて要約させ、「この規程に適合するAI利用ガイドラインのドラフトを作ってほしい」とプロンプトで依頼することをおすすめします。AIに出力させたドラフト案をもとに人間が自社の実情に合わせてカスタマイズしていく形をとると、比較的スムーズにガバナンスを構築できます。
AI活用・内製化支援のご相談はNCDCへ
NCDCでは、自社サービス「BizAIgent」でAIエージェント基盤を本番運用している経験や、多数のプロジェクトでのAI駆動開発の実践経験と知見をもとに、AI駆動開発支援・内製化支援・生成AI活用ワークショップなど、組織の状況や目的に応じた幅広いサービスを提供しています。
「まず何から始めればよいかわからない」という段階から、「ツールは導入したが定着しない」「組織全体の生産性を底上げしたい」というお悩みまでご支援が可能です。ぜひお気軽にご相談ください。
セミナー資料公開（無料）
本記事は、2026年7月9日に実施したオンラインセミナー「『AIを入れたのに変わらない』を脱する。ツール導入から文化定着まで、1年間の実践知を公開」の内容をもとに要点を解説しています。
セミナー動画やセミナー当日に用いた資料（スライド）は下記リンクからご覧ください。
