AIツールを配るだけでは、開発チームは変わらない

生成AIを開発現場へ導入したのに、使う人と使わない人に分かれてしまう。
そんな状況は珍しくありません。

GitLab社の社内事例では、AIツールの配布に加えて、学習機会、現場の推進役、中央のガバナンスを組み合わせています。

私たちは、AI導入の成否を分けるのはツールの性能より、仕事のなかで使い続けられる仕組みだと考えます。

問題はプロンプトより、AIに任せる仕事を決められないことです

AIを使い始めた開発者がつまずくのは、プロンプトの書き方だけではありません。

コードを書く、レビューする、脆弱性を修正する。

どこをAIに任せ、どこを人が確認するかを決める必要があります。

GitLab社は中央の統制と現場の裁量を組み合わせました

2026年9月3日公開のGitLab社の記事では、
Enterprise TechnologyチームとTalent Developmentチームが協力して、
エンジニアリング組織のAIフルエンシーを育てた取り組みが紹介されています。

AIフルエンシーとは、ツール操作だけでなく、何を任せ、結果をどう評価するかを含む実務上の判断力です。

Enterprise AIが標準やセキュリティのガードレールを管理し、
各機能組織にはAI Transformation Ownerを置きます。

さらに、先に試して同僚を支援するAIチャンピオンのコミュニティも設けています。

学習内容も実務に結びつけています。

メンバーが現在地を確認する「AI Literacy Ladder」を用意し、
役割に応じた学習パスを設けました。

エンジニア向けの内容には、プランニング、コードレビュー、
パイプラインの修復、セキュリティ修正が含まれます。

成果は利用量だけで測りません。

自己診断や学習パスの完了状況を示す「リーチ」、
継続的に学んでいるかを見る「デプス」、
研修が仕事に役立ったかを問う「適用価値」を組み合わせます。

記事では、エンジニア向けワークショップ参加者の87%が、
すぐ業務に適用できる学びがあったと回答しています。

また、主要な社内AIコーディングツールの1日あたりのインタラクション数は、
施策開始から1か月後に22.3%増えました。

利用回数だけを追うと、意味のない入力を増やす誘因にもなります。数字の意味を分けて見ます。

真似るべきなのは制度名ではなく、三つの判断です

GitLab社の仕組みをそのまま導入する必要はありません。

自社の仕事に合わせて、次の三点をまとめます。

全社で守る境界、各チームで試行を進める人、実際の仕事に接続した研修。

この三つを自社向けに決めます。

入力してはいけない情報や本番前の確認方法を明確にし、
自社のリポジトリでレビューを試すなど、使う場面を用意します。

私たちはAI導入を、更新される運用として考えます

アットマーク・ソリューションでは、AI活用の仕組みを一度作って終わるものとは考えていません。

モデルやツールが変われば、適した仕事の切り分けも変わります。

ルール、学習内容、評価指標を更新できる運用まで導入範囲に入れるべきです。

一般的なケースでは、一つの開発チームで対象業務を絞るほうが判断しやすくなります。

経営者が見るべきなのは契約数ではなく、開発者の判断と確認方法が仕事に定着したかです。

利用率だけでは足りません。

次に考えること

AI導入を検討するなら、「どのツールを買うか」より先に、「どの仕事をAIに任せ、誰が結果を確認するか」を一枚に書いてみてください。

そこに必要なルール、学習、相談先、測定方法を足すと、自社に足りないものが見えてきます。

ツールは後から入れ替えられます。

チームが結果を確かめる習慣は、時間をかけて育てるものです。