AIを開発の「おまけ」ではなく「中心」に据えて約1年半。
私たちMKDTグループが何に取り組み、何が変わったのか。これから全6回でご紹介していきます。今回はその全体像です。
- AIツールを入れても、すぐには開発が速くならなかった理由
- 約1年半の歩みと、数字で見る変化
- 成果を支えた3つの考え方と5つの取り組み
- よくいただく質問と、これから始める方へのヒント
「ツールを入れたのに、思ったほど速くならない」
最近、お取引先やパートナーの皆さまから「AIを使った開発、実際どうですか？」と聞かれることが増えました。生成AIのコーディングツールは誰でも使える時代になり、試しに導入してみたという会社も多いと思います。
ところが、よく伺うのが「便利なのは確かだけど、チーム全体の開発が劇的に速くなったわけではない」という声です。実は私たちも、最初は同じところでつまずきました。
AIの使い方は人によってバラバラで、出てくるコードの品質も安定しない。AIに渡す前提情報が足りず、手戻りが起きる。結局、一部の詳しい人だけが恩恵を受けている——。問題はAIの性能ではなく、AIを迎え入れる側の準備にありました。
世の中では「AI駆動開発」と呼ばれることも多い取り組みですが、私たちはAIに開発を任せきりにするのではなく、AIを前提に開発のやり方そのものを作り直すという意味を込めて、「AIネイティブ開発」と呼んでいます。
このシリーズでは、私たちがそこから何を準備し、どんな仕組みを作り、どこへ向かおうとしているのかを、できるだけ率直にお伝えしていきます。
約1年半の歩み
- 2025年夏 きっかけ 納期の迫ったフロントエンド案件で、AIエディタを本格活用 実装に入る前に、設計とAIへのルール作りにじっくり時間をかけたことで、想定を大きく上回るスピードで開発を進められました。「AIは準備しだいで化ける」という手応えを得たのがこの案件です。
- 2026年春 全社展開 AIへのルールをテンプレート化し、全社の開発に展開 個人の工夫に頼らず、誰でも同じ前提でAIを使えるようにしました。あわせて開発ツールを自社で運用するOSSの基盤へ移し、AIとの連携や統制を自由に設計できる土台を整えました。
- 2026年秋 次のステージ Issue（タスク）を起点に、AIエージェントが実装まで進める仕組みの運用を開始 人が「何を作るか」を起票すると、エージェントが実装からPR作成までを担当し、最後は人が承認する。AIを「道具」から「チームの一員」に近づける取り組みが始まっています。
数字で見る変化
※ 12〜15倍は特定案件における実装行数ベースの数値です。+70%は導入前後それぞれ6か月の比較、AIプランの削減は50名で利用した場合の今後の見込みです。
数字の裏側にあること
成果を支えた3つの考え方
振り返ると、効いたのはAIそのものよりも、AIが力を発揮できる環境を先に整えたことでした。その根っこには、次の3つの考え方があります。
AIは「読めるもの」しか理解できない
だから、設計や手順、判断の理由まで、プロジェクトの情報を一か所に集めて、AIが読める状態にする。
人は「何を作るか」と「最後の判断」に集中する
実装はAIに任せ、人は設計とレビュー、承認に時間を使う。役割を分けることで、全体が速くなる。
安全は、人の注意ではなく仕組みで守る
AIで開発量が増えるほど、目視だけでは守りきれない。ルールと自動チェックで、スピードと安全を両立する。
5つの取り組み
この考え方を形にしたのが、次の5つの取り組みです。次回以降、1つずつ掘り下げていきます。
AIが「読める」状態をつくる
アカウント情報などの秘密以外は、プロジェクトの情報をほぼすべてリポジトリに集めました。設計書や手順書だけでなく、「なぜこうしたか」という判断の理由も残しています。
近日公開ルール・品質・セキュリティを標準化
AIへの指示やテストの書き方をテンプレートで共通化し、情報漏えい対策も自動化しました。設計を日本で行い、実装をAIとオフショアで進める体制とも相性が良いことが見えてきました。
近日公開Issueを起点にAIエージェントが動く
AIとの会話からそのままタスクを起票し、エージェントが実装からPR作成までを担当。エージェントも社員と同じように権限と記録を管理し、最後の承認は必ず人が行います。
近日公開AIへ投資する原資をつくる
開発ツールを自社で運用するOSSへ移行し、浮いた費用をAIへ再投資しています。さらにエージェント化によって、AIの利用コストそのものも見直しています。
近日公開開発の外へ、自社プロダクトとの連携へ
脆弱性の検知から改修タスクの起票までを自動でつなぐ構想や、デザインなど開発以外の業務へエージェントを広げていく計画についてお話しします。
近日公開よくいただく質問
AIが書いたコードの品質は大丈夫ですか？
AIに任せきりにはしていません。AIにはテストもあわせて書かせ、自動チェックを通ったものだけを人がレビューし、承認してから取り込みます。品質を「人の頑張り」ではなく「仕組み」で担保するのが基本の考え方です。詳しくは第2回でご紹介します。
社内の情報をAIに渡して、セキュリティは問題ありませんか？
アカウント情報やアクセスキーなどの秘密は、そもそもリポジトリに置かないルールにしています。万一混入しても登録時に自動で止める仕組みや、AIが機密ファイルを読めないようにする設定も入れています。
エンジニアの仕事はなくなりませんか？
仕事の中身が変わる、というのが実感です。手を動かして書く時間が減り、「何を作るか」を考える設計や、AIの成果物を見極めるレビューの比重が大きくなりました。むしろ、設計力や判断力の価値が上がっています。
大きな投資がないと始められませんか？
いいえ。私たちも最初は1つの案件から始めました。高価なツールより、情報の整理とルールづくりのほうが効果は大きいと感じています。周辺ツールの見直しで、AIに回す費用をつくることもできます。
これから始める方へ：まずはこの3つから
- プロジェクトの情報を一か所に集める
設計や手順、決めたことの理由を、AIが読める場所（リポジトリなど）にまとめます。ここが一番の近道です。 - AIへのルールを書いて、チームで共有する
コーディングの決まりや進め方をファイルにして、誰が使っても同じ前提でAIが動くようにします。 - 人が判断するポイントを決めておく
どこまでAIに任せ、どこで人が確認・承認するのかを決めておくと、安心して任せる範囲を広げていけます。
これまでの記事から
このシリーズの土台になった取り組みは、過去の記事でも詳しくご紹介しています。
AI活用の全体像は、取り組み紹介ページでもご覧いただけます。AIを使った開発体制づくりや、オフショアを組み合わせた開発のご相談もお気軽にどうぞ。
MKDTグループのAIの取り組みを見る次回は「第1回 準備：AIが『読める』状態をつくる」。プロジェクトの情報をどうリポジトリに集め、どんなドキュメントを残しているのかをご紹介します。
コメント