ソフトバンクが実証、開発工数60倍短縮を生むAIポリシーの整え方3点

開発メンバーが3人いれば、3通りのAIツールを使っている。Copilotを個人契約で使う人、Claude Codeをこっそり試している人、まだ何も使っていない人。コードレビューのコメントが突然丁寧になったのがAIのせいか本人の成長かも分からない。生産性は「上がった気がする」けれど、数字で説明できない。CTOとPMが今、多くの現場で直面しているのはこういう状況だ。

97%が使っているという意味

Stack Overflowの2025年調査では、世界の開発者の97%がAIコーディングツールを利用していると答えた。「業務で正式に使っている」だけでなく「なんらかの形で使っている」を含む数字だが、それだけにポリシーを整えていないチームにもAIはすでに入り込んでいる。だからこそ今は「入れるかどうか」ではなく「どう整備するか」のフェーズだ。

ソフトバンクは2025年9月に「1人100個のAIエージェントを作る」という目標を全社員に公表した。2.5ヶ月後には250万個超のエージェントが社内で動き、モック開発の工数は30時間から30分へと60倍短縮された。偶然の成果ではない。「誰が何を作っていいか」「成果をどう共有するか」というルールを先に決めたから、全員が迷わずに動けた。開発チームへのAIツール展開も、同じ原則が当てはまる。

今週中に決める3つのこと

まず「使っていいツールリスト」を1つ用意する。Claude CodeかGitHub Copilotか、あるいは両方か。会社として契約するか個人任せにするかを決めて、SlackチャンネルかWikiに貼るだけでいい。「公式に使える」という認識が生まれるだけで、チームの動きが変わる。迷ってばかりで結局使わない、という状況が解消される。

次に「コードレビューのルール」に1行追加する。「AIが出力したコードも通常レビューの対象とし、生成元の明示は不要」——これだけで十分だ。申告制にすると運用が面倒になる。コードの品質はレビューで担保するという原則を守れば、AIが書いたかどうかは関係ない。

最後に「生産性の計測指標」を1つ決める。PRのサイクルタイム、週次コミット数、テストカバレッジのどれでもいい。1つだけ選んで3ヶ月前後を比べれば、AIが本当に効いているかどうかが数字で分かる。計測しないままでいると「なんとなく良くなった気がする」という感想止まりになる。

PMが整えるのはゴールの解像度

AIコーディングツールが一番力を発揮するのは、「何を作るか」がはっきりしているときだ。仕様が曖昧なままAIに渡すと、それらしいコードが大量に出てきて逆に収拾がつかなくなる。PMの役割はここでも変わらない。チケットの受け入れ条件を具体的に書く、スプリントゴールを1文で言い切れる状態にする。それだけでAIの出力精度が目に見えて上がる。

大規模なエンジニア組織でのAI活用事例として、MercadoLibreがClaude Codeで23,000人のエンジニア組織を刷新した事例も参考になる。

開発者がAIを使うかどうかはもう選択肢ではない。CTOとPMの仕事は、その前提でチームの動き方を整えることだ。

ドリップ（執筆）

AIツールを使っている人と使っていない人が同じチームに混在している状況、うちの周りでもよく聞きます。

ソフトバンクの60倍短縮って、ツールの話じゃなくてルールを先に決めた話だったんですよね。それが一番の気づきでした。

ツールリスト1枚と指標1つから始めるだけで十分。難しく考えなくていいと思います。

あなたは【会社名】の技術責任者です。開発チーム【人数】名が使用するAIコーディングツールのポリシー文書を作成してください。前提条件：使用を許可するツールは【Claude Code / GitHub Copilot / その他】、コードレビューは既存プロセスに組み込む、機密情報を含むコードは入力しない。出力形式はWikiかSlackに貼れる箇条書きで200字以内。まず現状を確認するための質問を3点以内でしてから、ポリシー案を提示してください。

あなたは【会社名】開発チームのPMです。AIコーディングツール（【Claude Code / GitHub Copilot】）を導入して【3ヶ月】が経ちました。以下のデータをもとに経営陣向けのレポートを作成してください。データ：PRサイクルタイム【導入前X日→導入後Y日】／週次コミット数【A件→B件】／テストカバレッジ【C%→D%】。出力形式：A4 1ページ相当（500字以内）、数字を前面に出した要約形式。不足情報があれば先に質問してください。

あなたは【会社名】のPMです。以下のチケット仕様を、AIコーディングツールが最大限活用できる形に書き直してください。現在の仕様：【例：ユーザーがログインできるようにする】。以下を含む形で再構成してください：①受け入れ条件（Given-When-Then形式）②完了の定義（DoD）③スコープ外の明記④想定する実装アプローチ（任意）。出力形式：JiraやNotionに貼れる箇条書き、各項目3行以内。曖昧な点を2点以内で確認してから書き直してください。