「AIを入れたのに変わらない」を脱する。ツール導入から文化定着まで、1年間の実践知を公開

「AI駆動開発」への注目が高まり、ビジネスの現場は大きく変わりつつありますが、「ツールを導入したものの、現場の生産性が上がらない」という壁にぶつかる組織は少なくありません。

私たちのシステム開発現場では、AI活用に関する改善活動を1年間継続してきました。その結果、エンジニアが書いたコードの確認申請数（プルリクエスト数）が約2倍に向上するという具体的な実績を出しています。

しかし、この成果はツールを導入してすぐに現れたわけではありません。日々の実践の中でデータを振り返ると、成果は一気に跳ね上がったのではなく、メンバーが使いこなし、プロセスが改善されるにつれて徐々にプルリクエスト数が増加していったことが分かりました。成果の鍵はツールそのものではなく、メンバー一人ひとりが使いこなし、日常的に改善が積み上がる「文化」と「プロセス」を組織で育てることでした。

本セミナーでは、開発現場での1年間の試行錯誤とデータから得た実践知をお伝えします。システム開発・内製化を進めるチームはもちろん、生成AIの導入・定着に悩むDXプロジェクトや組織の方々にとっても、次の一手となるヒントをお持ち帰りいただけます。

主な内容
・データで見るAI活用改善活動1年間の軌跡
・AI活用により、エンジニアの役割はどう変わるか
・効率化により浮いた時間でできるようになった新たな取り組み
・AIを日常の働き方に根付かせるアプローチ

こんな方におすすめ
・開発現場におけるAI活用の具体的なステップや、現場のリアルな成功・失敗事例を知りたい方
・AIを導入したものの、社内での活用や定着が進んでいないと感じる経営層・DX推進担当者
・ツール導入による短期的な効率化だけでなく、組織全体の抜本的な生産性向上を目指したいビジネスリーダー
・業務の効率化によって生まれた時間を、どのように新規事業や付加価値の創出に繋げるべきか模索している方

Transcript

1. 「AIを入れたのに変わらない」を脱する ツール導入から文化定着まで、 1年間の実践知を公開 NCDC Online Seminar NCDC株式会社 2026 / 07 / 08
2. 2 茨木 啓太 NCDC株式会社 テクノロジーディレクター 2026 Japan AWS Top Engineers AWS Certified Solutions Architect – Professional AWS Certified DevOps Engineer – Professional Google Certified Professional - Cloud Architect ← AWS本を2025/11に出版しました 書籍『はじめてのAWSモダンアプリ開発入門』 NCDCにて、システムのインフラ構築からWebサービスのバックエンド開発・モバイルアプリ 開発まで、幅広い領域での開発を担当 複数のプロジェクトで、AWSをはじめとしたクラウドを活用したモダンなアプリの設計・開発 や、DevOpsやCI/CDの構築・運用の実績を持つ 近年は、生成AIを活用した開発や、NCDCのAIエージェントプロダクトである BizAIgentの開発に関わる
3. ⚫ 多様な強みをお客さまごとのニーズに応じて、柔軟にお客様へ提供。 ⚫ 多様なプロジェクトを通じて見極めた「共通課題」に対しては、製品やパッケージ化したサービスを提供。 Product Services 共通の課題を解決する 製品・サービスを 市場に幅広く展開 サービス・プロダクトの二軸による価値提供 3 ⚫ AWSアドバンストティア サービスパー トナー ⚫ AWS Lambdaパートナー ⚫ 内製化支援推進AWSパートナー ⚫ 内製化における生成AI活用支援サー ビスオファリング ⚫ SORACOMソリューションパートナー Professional Services お客さまごとのニーズに 応じたソリューションを One to Oneで提供 Synergy デジタル戦略 , AI , IoT , データ活用 , モダンアーキテクチャ , アジャイル , 内製化支援 , UX/UIデザイン , プロダクトマネジメント NCDCの強み
4. デジタルビジネス立ち上げを一元的にサポート ⚫ デジタルビジネスに必要な要素にフォーカスし、一元的に提供。 ⚫ スモールスタートでの検証から、本開発・継続的な改善まで長期間お客さまをサポート。 4 ユーザ視点を大切にした アイデア・企画 モックやプロトタイプ の開発・検証 継続的な改善 システム・アプリ開発 ワークショップを中心とした合 理的なプロセスで、ビジネス モデルの検討からUXデザイ ンまで、迅速に行います。 関係者が多数いる場合の組 織横断、会社横断のファシリ テーションも得意です。 新規性の高いプロジェクトでは MVP（Minimum Viable Product） を用いた検証を行うなど、目的 に応じて段階的な開発を企画し ます。 早い段階でモックやプロトタイプ を用意してユーザの評価を確認 します。 ユーザとのタッチポイントとなる各種デバイス のフロントエンドデザインから、クラウドサービ スを駆使したバックエンドの開発まで。 多様なテクノロジーをインテグレーションします。 ⚫AI / IoT ⚫モバイル・ウェブ アプリ開発 ⚫クラウドインテグレーション ⚫システムアーキテクチャコンサルティング など ビジネスモデルのデザイン スモールスタート・PoC システム・インテグレーション
5. ⚫ デジタルサービス開発の知見を活かしたNCDC独自プロダクトを複数運営。 ⚫ 自社プロダクトの経験で得た知見をお客さまへの支援に還元。 プロフェッショナルサービスとプロダクト開発の両輪 5 プロジェクト支援SaaS PJ Insight 隠れたプロジェクトの本質を見抜くためのツール。 従来の進捗報告手法では把握できなかった品質や納期など に対するメンバーの本音・不安をオンラインの定期アンケー トで収集し、時系列データでプロジェクトの状況を可視化しま す。 建設業向けSaaS ミエルコウジ 土 木や 建築 の工 事現 場で 実測 値を収 集する IoT 機 能 とW EB アプ リや A PIで構 成され るプラッ ト フォ ーム。 現 場で の データ 収集 や シス テム へ の登 録・確 認にか か る手 間 を大幅 に削 減 し、 他 部 門・ 他 社 への 情 報 共 有 を圧 倒的 なス ピードで 実現 しま す。 「社内の情報×生成AI」を実現。 法人専用 BizAIgent AIが外部データと連携する標準プロトコルMCPを活用し、企 業が社内で利用しているシステムと生成AIを連携。 販売管理、生産管理、顧客管理等の業務システムのほか SharePoint、Teams、Box、Googleドライブ、Slack、Backlog、 GitHubなど多様なSaaSと連携可能。 法人専用 AIチャット
6. NCDCのAI活用・内製化支援の実績 NCDCは生成AIやAWSを活用した内製化支援・スキルトランスファーを、国内でトップクラスの企業との直接取引で 多数実施してきました。その伴走実績を活かして、 AI駆動開発の支援も実施しています。 顧客 主なキーワード NCDCの支援内容（要約） 三菱電機 生成AI(RAG)／内製化／AWS(Bedrock) ／技術移管 Amazon BedrockでRAGを開発。 開発に加えて技術移管で内製化人材を育成 戸田建設 内製化／スキルトランスファー／ アジャイル／DevOps／AWS 両社の「共創チーム」でアジャイル開発を推進し、 実践的にスキルを移管 ライフネット 生命保険 AWS移行／クラウドネイティブ／ マイクロサービス／DevOps 大規模システムのAWS刷新で、アーキテクチャ標準策定 ・API設計標準化を主導 本田技研工業 内製化／アジャイル／技術支援／UX-UI 製造部門の内製ITチーム立ち上げを伴走し、アジャイル開発体 制を構築 航空ビジネス サービス AIエージェント／業務自動化／ROI試算 AI活用の実務棚卸しWSで削減工数を定量化し、 導入判断を支援 6
7. 本日のセミナーについて ⚫こんな課題をお持ちの方に向けたセミナーです ⚫開発現場でのAI活用の実例やデータを知りたい ⚫AIツールを導入したものの、定着や成果に課題を感じている ⚫開発チームの生産性向上を目指している （経営層・DX推進ご担当の方を含む） ⚫本日お持ち帰りいただきたいこと ⚫「ツールを入れる」だけでは変わらない理由 ⚫文化・プロセスとして定着させるための実践知 7
8. 本日のアジェンダ ⚫ 1. データで見るAI活用改善活動 ⚫ 2. AI活用によるエンジニアの役割変化 ⚫ 3. 効率化の代償 ― 「判断」の集中を防ぐ育成 ⚫ 4. AI駆動開発とクラウドの親和性 ⚫ 5. 生成AI活用のチームへ定着アプローチ ⚫ 6. NCDCの生成AI活用支援 ⚫ 7. まとめ 8
9. 1. データで見るAI活用改善活動
10. 世の中の動き ― 生成AIによる開発は「本格活用」の段階へ ⚫企業の約9割が、実験段階を脱し本格活用のフェーズへ ⚫開発生産性は平均で約+19%向上 先行企業では30〜50%の向上報告もあり ⚫一方で「ツールを入れたのに、思ったほど変わらない」という 現場の声も少なくない ⚫差を生むのは単純なAIツールの性能だけでなく、 それを使いこなす「文化」と「プロセス」 10 出典: Gartner、Anthropic Economic Index 等の公開情報（2025〜2026年）を基に整理
11. NCDC社内の開発量は、昨年度(2025年度)の1年間で、約2倍になりました NCDCでは、社内の開発に、生成AIエージェントを積極的に導入 特に2025年度は複数のツールの導入と検証を繰り返し実施 11 開発量が2025/ 03 は週平均 126 開発量が2026/ 03 は週平均 267 ※ 本資料での「開発量」は、新機能・改善の件数であるPR（プルリクエスト）数を指します（グラフ中の「PR」表記） 1年間で約2倍に
12. グラフが示す3つの事実 データからは「開発量」「スピード」「レビュー」の3つの変化が読み取れる 開発量は約2倍に • 開発件数 週平均 126→267 • 急激にではなく、少しずつ 着実に増加 • 単発の施策ではなく、 継続的な改善の結果 １つの修正の スピードは変わらず • 完了までの時間（リードタ イム）は悪化せず • 通常は、量が増えると作 業が滞りがち • 一方で、早くもなっていな い レビューは速く • レビューに必要な時間が 短縮 • レビューにもAIを活用する ことで時間を短縮 • レビュー関連の各工程も 安定して推移 12
13. この動きが何を意味するか ⚫ 着実な右肩上がりは、3つの「継続」がそろった結果 ⚫ 環境整備の継続：新しいツールの検証・許可、契約の見直しを絶えず実施 ⚫ ルールの整備：セキュリティレベル別の利用ガイドライン等を整備・改定 ⚫ メンバーの習熟：メンバーが使いながら、使い方を磨き続けた ⚫ 個人の頑張りに加えて、仕事の進め方ごと進化 ⚫ レビューへのAI活用 ⚫ ルール・開発環境の標準化が進んだ ⚫ ただし、万事順調ではない ⚫ 1回あたりの変更が、大きくなりがち（AIが一気に開発してしまう） ⚫ 1回の変更量を小さく保つことで、より開発を素早く実施することが見込めるため、改善の余地あり ⚫ 作った分だけ、人の「判断」業務が確実に増えている 13
14. 2. AI活用によるエンジニアの役割変化
15. AI駆動開発の本質 ― 「実行」はAIへ、「判断」は人間に AIにコードの「実装」は移管できる。でも「判断」は人間に残る 実行 コードを書く テストする 修正する AI に任せる 判断 この設計でいい？ トレードオフを許 容する？ 人間 に残る 15 判断を人間に残さないと、 誰も把握していない負債を 後に残すことになる 今、修正する べき？
16. AI時代のエンジニアはこう変わる 開発の中心は、「コード」から「仕様」「設計」へ これまでのエンジニア • コードを書く人 • 実装の速さ・量が価値の中心 • 開発の中心は「コード」 これからのエンジニア • 仕様を書き、AIを操り、品質を担保する人 • 良い判断を任せられることが価値の中心 • 開発の中心は「仕様・設計」 16
17. 開発量が2倍になると、「判断」も2倍に ⚫実行が速くなり、作られるものが増えた（開発量2倍） ⚫作った分だけ「これで良いか？」の判断が必要になり、判断も2倍に ⚫一方で、判断できる人は急には増えない ⚫実行はAIで増やせる一方で、判断が追いつかなくなる ⚫ このままでは、人間の判断がボトルネックに 17
18. 「判断」の需要は急増する一方、供給はすぐには増えない 需要は実行量に比例して増えるが、供給はすぐには増えない 判断の需要 • 実行コストが下がり、作られるものが増える • 作った分だけ「これで良いか？」の判断が必 要 • 開発量が2倍なら、レビューと判断も2倍 判断の供給 • 判断力は経験の積み重ねでしか育たない • 人材育成には年単位の時間がかかる • 採用だけで埋めるには限りがある 18 AI駆動開発を真に成功させるには、短期的な効率化だけでなく、 中長期的に判断力があるメンバーを育てる必要がある
19. 3. 効率化の代償 ― 「判断」の集中を防ぐ育成
20. 判断はベテランに集中し、若手は経験を積めなくなる AIが「実行」を担うほど、判断はできる人へ集中し、若手からは学びの機会が失われていく ベテランに起きること • 判断・レビュー・意思決定が集中する • 自分の実装・設計の時間が失われる • チーム全体のボトルネックに 若手に起きること • 「実行」をAIが担い、自分で書いて試行錯誤 する機会が減る • 失敗と修正から学ぶ経験が積みにくい • 「判断できる人」へ育つ道筋が細る この構造は放置しても、自然には解消しない。だからこそ、経験の積み方・学び方を意図的に設計する。 20
21. どう向き合うか ― 個人と組織で 個人は「判断力」を磨き、組織は「判断できる人」を育てる エンジニア個人は • 磨くべきは「判断力」 • 設計の良し悪し、トレードオフの感覚 • 構文暗記・タイピングは価値が薄い 組織は • 「判断できる人」を育てる • 判断が一部の人に集中しないように • 評価を「実装量」から「判断の質」へ 21
22. 「育成」を仕組みにする ― 判断できる人を増やす工夫 22 ⚫個人として ⚫評価軸を「実装量」から「判断の質」へ移す ⚫レビューを「修正」ではなく「思考の言語化」の場にする ⚫なぜその設計にしたのかを記録し、資産化する（ADRを残す） ⚫組織として ⚫意図的に「任せる」領域を作り、経験を積む機会を守る ⚫勉強会・共有会で判断のプロセスごと共有する ⚫「判断できる人を育てたこと」自体を評価する
23. 4. AI駆動開発とクラウドの親和性
24. AI駆動開発とクラウド・マネージドサービスの親和性 AIが操作できる面が広く、適用が開発から運用へ広がる クラウドの特性 • インフラも運用もコードとAPIで操作できる （IaC） • マネージドサービスが定型運用を担ってくれ る • 構成情報やログが構造化されている AI駆動開発との相乗効果 • AIが読み書き・操作できる面が広い • 開発だけでなく、運用・監視にも適用が広が る • 人はより上流の判断に集中できる 24
25. 例：Agent Toolkit for AWS ― AIにAWSの作法を教える公式プラグイン Claude Code 等のコーディングAIに、AWS公式のスキルとMCPサーバーをまとめて組み込むプラグイン集。 AIがAWSの「作法」を知った状態で開発を始められる（2026年5月 GA・無償）。 どんなサービスか • AWS公式のスキル30種以上とMCPサーバーを、 プラグイン1つで導入 • 設計・構築・運用のAWSの知見をAIに与える • Claude Code・Codexに対応 • AWS公式サポートのオープンソース AI駆動開発との相性 • AIがAWSのベストプラクティスに沿って書け る • AIの操作と人の操作をIAMで区別し、権限を 絞れる • 全リクエストを監査できて、ガバナンスと両立 25
26. 例：AWS DevOps Agent ― 監視・インシデント対応までマネージドで DevOps Agent は、アラート起点で「検知→調査→根本原因特定→緩和策提案」まで自律実行する、SRE 的な存在。 自社の運用タスクを賄えるかを見極めたうえで活用する。 できること • 検知→調査→根本原因特定→緩和策提案を 自律実行 • メトリクス・ログ・デプロイ履歴を横断して原因を 推論 • Slack・PagerDuty・CloudWatch 等と連携 • 日次ヘルスチェックやログ異常検知の定期実行 できないこと • 業務固有の判断ロジック • 外部ツールとの連携 • 必要になれば、独自実装で補う 26
27. 例：AWS Blocks ― AI駆動開発を前提にした開発フレームワーク AWS Blocks は、認証・DB・AIなどの「ブロック」を組み合わせてアプリを作る、新しい開発フレームワーク。 AIが書きやすいことを前提に設計されている（2026年6月 Public Preview・オープンソース・追加料金なし）。 どんなサービスか • ブロックを組み合わせ、インフラは自動生成 （数行から100超のAWSリソースを展開） • ローカルだけで開発し、同じコードをそのままAWSへ • Agent・KnowledgeBaseブロックでAI機能も標準部品 • モバイル向けのライブラリ生成にも対応 AI駆動開発との相性 • コーディングAI向けの手引きを標準同梱 • 型が厳密で、AIの書いたコードの誤りに気づ きやすい • 定型はブロック化済み、AIと人は差分に集中 27
28. 5. 生成AI活用のチームへ定着アプローチ
29. AIを“成果”に変える鍵 ― 明確なルールを設けて、それを育て続ける AIは開発を速くするが、その速さがそのまま成果になるとは限らない。 AIが従う「開発のルール」があって、初めて品質を伴う。 最初から完璧は目指さず最低限のルールから始め、プロジェクトに合わせて育て続けることが大切。 なぜ「最低限から始めて育てる」のか ・最初から完璧なルールを定めることは初期コストが大きい。ミニマムで素早く始め、効果を確かめながら広げる ・最適なルールはプロジェクトごとに異なる。実際に使って初めて分かることが多い ・「ツールを配って終わり」では定着しない。整える→使う→改善するのループを回し続ける ・生成AIは進化が早く、完璧なルールを用意してもすぐに陳腐化する 1 最低限のルールを整える 2 AIで実際に開発・運用 3 効く点・合わない点を発見 4 現場に合わせて改善 1〜4を繰り返す： 運用しながらルールも人も育て続ける 29
30. 「最低限のルール」とは、何を整えることか AIが意図を正しく理解し、品質を保って動くために、まず3つを薄く整える。全工程をAIに任せず、人が品質を担保する。 仕様・意図を残す • 何を作りたいか・なぜその 設計かを言葉で残す • AIが意図を正しく理解でき るようになる AIに作法を教える • プロジェクトの規約や構造 を明文化する • AIが「その現場の流儀」で 動けるようになる 品質は人が守る • テストとレビューの仕組み で担保する • 品質の最終責任は人が持 つ 30
31. NCDC社内での定着の取り組み 場をつくる • 使い方の共有会・勉強会 を日常的に開催 • エンジニア以外（コンサル・ PM）も巻き込む • 学びをチームの共有知に する 型をそろえる • AIへの指示ルールや設定 を標準化 • 専用リポジトリで全員に共 有 • 個人のノウハウを組織の 資産に 会社全体で活動 • 部署横断のタスクフォース を設置 • 標準化と横展開を推進 31 特別な施策ではなく、日常の営みとして回し続けている
32. 業務利用に必要なAIガバナンス 業務でAIを開発に使う以上、最低限の統制は不可欠。 「基盤による統制（Amazon Bedrock 等）」と「開発の運用ルール」の二層で備える。 観点 具体例 対策（基盤統制 ／ 運用ルール） 情報漏洩 ・ソースコード・機密情報の外部送信 ・モデル学習データへの利用 Bedrock（入力をモデル学習に不使用）・送信制御 ／ 持ち出しルール 生成コードの 品質・脆弱性 ・入力検証不足や過剰な権限付与 ・レビューなしのマージ 静的解析のCI組込み ／ TDD(テスト駆動開発)の導 入／ セキュリティエージェントによるAIレビュー 権限・監査 ・権限外の環境・データへの到達 ・「誰が・何を」の記録欠如 IAMによる最小権限 ／ 操作ログ・監査証跡の取得 コスト ・利用量の急増・想定外の課金 利用枠の設定 ／ 利用状況の可視化・コスト監視 32
33. 進め方 ― 小さく始めて、育てる 大きな計画より、小さな実践。1チームで始めて、育てながら広げる。 1 1チームから始める 効果が見えやすい1チーム・1プロジェクトを 選ぶ 2 最低限だけ整える 完璧を目指さず、ルールは薄く始める 3 使いながら育てる 効く点・合わない点を直し、他チームへ広 げる この繰り返しが、第1章でご覧いただいた「継続の積み重ね」になっていく 33
34. 6. NCDCの生成AI活用支援
35. NCDCなら「内製化支援の伴走実績」と「AI駆動開発の実装力」の両立が可能 ・自社サービス「BizAIgent」でAIエージェント基盤を本番運用 ・社内開発でAI駆動開発を実践し、ノウハウを蓄積 観点 NCDCの特徴 実装まで踏み込む co-developerとして実プロジェクトに参加（「手を動かす」会社） 内製化支援 顧客が自走できる状態を作る（運用を肩代わりして終わりにしない） 実践に基づく知見 自社・社内開発での AI駆動開発の実体験を提供 日本企業への適合 国内企業の組織文化に踏み込んだ伴走 35
36. BizAIgent ― 「社内の情報×AI」を実現する法人向けAIチャット ⚫ MCPで社内のシステムやデータと安全に連携 ⚫ Google Drive / Box / SharePoint / Notion / Backlog など主要サービスに標準対応 ⚫ 重要な業務データを生成AIで活用し、社内に散ら ばった情報を統合 ⚫ 管理者が許可したデータのみを連携し、ガバナンス と回答精度を両立 ⚫ AWS製OSS「Strands Agents」を採用し、NCDCが 自社開発・本番運用 ⚫ Findy Tools「AIエージェント開発特集」でも アーキテクチャを紹介いただきました 36
37. まず小さく始める入口 ― NCDCの生成AIワークショップ 「まず何から始めるか」の入口として、3種類のワークショップをご用意しています。参加人数は20名程度を想定（ご相談可能 です）。 ワークショップ こんな課題に 内容と期間 ① 生成AI Kick Starter 自社でのAI活用方法が分からない ／ 社内のスキルや理解を揃えたい 実際の生成AIツールを使いながら、AIの基礎と 一般的な活用実績を学ぶ（1日・2時間程度） ② 生成AIエージェント Discovery Workshop 生成AIを適用する業務を見極めたい ／ 効果やコストを試算したい 業務の課題を抽出し、生成AI適用時の効果を試算。 結果をレポートで報告（1日・2時間程度） ③ カスタムAI業務改善 Hands-on 実務で活用するツールを開発したい ／ AIを用いた開発のスキルを得たい 業務改善シナリオをコワーク形式で検討し、 生成AIツールでの業務改善プログラム作成を支援 （4週間・週1回2時間程度） 37
38. まとめ ⚫ AIは「入れただけ」では変わらない ⚫ 成果はツールではなく、使いながらの習熟と改善の積み上げが必要 ⚫ エンジニアの役割は「実行」から「判断」へ ⚫ コードを速く書けることより、良い判断を任せられることが価値になる ⚫ 育成への投資で偏りを防ぐことが必要 ⚫効率化の代償として「判断」は一部のメンバーに集中しがち。後進を育てることが重要 ⚫ 定着の鍵は「文化」と「プロセス」 ⚫ 最低限のルールから始めて、プロジェクトに合わせて育て続けましょう ⚫AI駆動開発の導入や、開発の内製化で困ったら、NCDCに相談 38