こんにちは。プラットフォーム開発部 EMのchika (@chika-mirai) です。
2025年に入ってから、AI駆動開発というキーワードや、AIコーディングツールに関する話題が開発現場でも日常的に聞かれるようになりました。
LLMをベースとしたAI開発のツールは、初期はChatGPTやGitHub Copilotから始まり、Cursor、Devin、そして最近ではClaude Code や Gemini CLIまで、次々と新しいツールが登場しています。
個人で使ってみた経験がある方も多いと思いますが、「組織として本格導入する」となると話は別です。
セキュリティは大丈夫？予算は？誰が使う？どうやってツールの効果を測り有用性を判断する？
一筋縄にいかないことは明らかで、マネジメント層としては悩ましいところです。
今回は、みらい翻訳でAI駆動開発の導入を4月から進めてきた4ヶ月間の経験を通して、個人利用では見えてこない組織導入ならではの課題と学びを共有したいと思います。
- AI開発ツール導入前の検討：何をチェックすべきかの整理（2025年4月）
- トライアル設計：段階的アプローチの採用（2025年5月）
- トライアル実行（2025年6月〜7月）
- 現在進行形の本格導入にむけての検討ポイント（2025年8月）
- 参考：AI駆動開発の組織導入における考え方についての事例
- まとめ：ふりかえりと今後の展望
- おまけ
- We are hiring!
AI開発ツール導入前の検討：何をチェックすべきかの整理（2025年4月）
AI駆動開発を部の目標に
2025年4月時点で、AI開発ツールの勢いは誰の目にも明らかでした。この時期は特にAIコーディングツールとしてCursorとDevinの存在感が大きくなっており、SNSやブログでの露出も盛んな時期でした。
「これは流行りで終わるものではない」というのはバズワード的に出てきた新しい技術に対して本気を出すときによく発されるセリフですが、この時はそんな高みから眺めたような余裕感はなく、むしろ「早く取り組まないとヤバい」という危機感すら感じるほどでした。
そこで、EM、VPoEで集まって相談し、部の目標として「AI駆動開発」を位置づけ、AI開発ツールの組織導入・活用を図ることにしました。
ちなみに当時の開発部の状況はこんな感じでした。
- 会社として正式に使えるAIツールはGitHub Copilotのみ（希望さえすれば使える）
- 個人利用としてChatGPTなどがそこかしこで使われている状況
- 汎用チャットではない、開発系のAIツールは個人的な興味で試している人はいるが、組織的な知見の蓄積はない
組織導入で考慮すべき観点の洗い出し
組織導入にあたって最初に検討したのは、会社として何をチェックし、どんな制約が必要かということでした。
言い換えると、使うサービスに対する確認事項と、利用者に対する制約事項の整理です。
利用サービスへの確認事項
SaaSのサービスを使うにあたって社内で記入すべきセキュリティチェックシートがあるのですが、使うサービスに対しては以下2点を最低限の確認事項としました。
1.セキュリティや内部統制に関する公的認証・監査レポートの有無
メジャーなサービスではだいたいサイトを確認すればどこかに掲載されていることが多いですが、まだサービス提供から日が浅いサービスは見つけられない場合もあります。
ただ、この情報が必ずないと利用できないというより、実際は使うサービスの性質や扱うデータを踏まえて利用可能と判断できるかどうかのリスク対策をするのが確認の目的です。
2.プライバシーポリシー
投入したデータが学習されたり二次利用されたりしないかということです。
AI開発ツールの場合はプロダクトのソースコードなど重要な情報を読み込むのがLLMであるため、慎重に確認する必要があります。
多くのAIツールでは企業利用を想定したプランなどではデータプライバシーを保護する機能がありますが、個人プランや無料プランでは保護されなかったり、設定によりON/OFFを切替えるサービスもあるなど、契約・利用時のルール作りやガードレールの必要性が変わります。
利用者に対する制約事項
利用にあたり会社が許可しているツールかどうかということは気になるとは思いますが、AI開発ツールについては「どこまでのデータを使ってよいのか？」ということが特に気になります。
そのため、データに関してはISMS規定として整理している情報分類に沿って機密情報の利用可否を分類し、使ってOKなデータ・NGなデータを明確化しました。
具体的には、ソースコードや要件・設計・議事録などの社外秘扱いのドキュメントについては、ツール側で学習・二次利用などされない前提で利用を許可する一方、個人情報・顧客情報・人事情報など、より秘匿性の高い情報に関してはツール側のポリシーに関わらず絶対に利用・投入してはいけないということにしました。
整理のポイント
上記を整理する際に意識したのは、AIツール導入のスピード感を削がず、且つ、最低限守るべきことは守るようにルールを決めることでした。
AIツールを使ってみるまでのハードルが高くなってしまうと、なかなか導入が進まずスピードを著しく欠くことになります。 そのため、事務的な手続きや確認事項をできるだけ簡素にし、導入・利用にあたって利用者が迷わないようにすることを心がけました。
ただ、確認事項などを整理していて思ったのは、「結局、SaaSを使うときに確認するべき点も同じだよね」ということでした。
「LLMに学習される」という点が意識されるせいか、特にデータの扱いに慎重になる傾向がありますが（それは良いことですが）、これはAI開発ツールに限らずインターネット通信でデータを投入するSaaSなどのツール全般を使うときにもチェックしておくべきことです。
これまであまり一般的に話題になりにくかっただけで、利用規約やプライバシーポリシーに書いていることを読んで、リスクのあるデータを渡すことにならないか、渡したデータはどう扱われるかの確認などはしているかと思います。
トライアル設計：段階的アプローチの採用（2025年5月）
小さく始めるアプローチ
「全員に〇〇を配布します」*1 や 「●●に全部賭けろ」*2 という意思決定ができればカッコいいですが、そのような事例はコツコツと草の根的な活動を積み上げた結果の経営判断であり、私達にその下地はありません。
(「全員にCursorを配布します」はログラス社が発表して話題になったのが最初かなと思いますが、その後同様の方針を取っている例をいくつか見聞きしました。以下はログラス社の事例)
また、今は様々なAI開発ツールが登場し、LLMのモデルが新しくなったり機能が増える勢力図が変わるという凄まじい群雄割拠のフェーズです。
現段階で特定のツールに偏った投資判断を行うのは弊社ではリスクが大きく、「どの程度の効果が見込めるか分からない」状況で投資判断をするのは困難です。そこで、以下のフローで進めることにしました。
- 2-3ヶ月のトライアル利用
- トライアル結果による継続判断
- 本格導入への移行
これは他の一般的なSaaSを導入する際の進め方と同じで、まずはトライアル用の予算だけを確保し、本格導入として利用拡大する際に改めて予算を取るというステップです。
「もう生産性爆上がり確定だから継続しないなんて事ある？」と思う気持ちもどこかでありますが、予算が潤沢にあるわけでもないので、期待どおりの効果が得られなかった場合のリスクを最小化するためには必要です。
とはいえ、ツール1つ1つ全てに対して上記のステップを踏んでいくのは現在のトレンドの速さには合わないため、より柔軟に様々なツールを試していける仕組みについてはトライアル後の現在の検討課題となっています。
トライアル自体のハードルを下げる
一般的なツールの有償トライアルだと「どのような課題を解決するのか」をかなり明確にしないと難しいということも現場によってはあるのではないかと思います。
そのロジックの整理、説明が厄介で、トライアル自体も「面倒くさい」と感じて蓋をするということもよくある気がします。
しかし、AI開発ツールについてはどんなユースケースにマッチし、どんな課題が解決できるのかについては、非常に多くの可能性を秘めていると思います。 （実際に、検証したメンバーからも 「開発フェーズのほとんどで効果がありそう」 という声が聞けています）
その意味で今は「手段を目的化してよいフェーズ」*3でもあり、いくつかの想定するユースケースに対しては最優先で試すものの、日常的に当たり前にツールを使っていくことで、その他の思わぬ価値を模索するのを大事にしたいところです。
利用者とツールのマッチング
マネジメント側でも有力なツールは調査していましたが、実際に使うのは現場のエンジニアです。そこで、部内各チームにヒアリングを実施しました。
- どのツールを使いたいか
- 誰が使いたいか
- どんな用途で使いたいか
- 期待する効果
ヒアリング段階ではEM側で選択肢を絞ることなく自由に挙げてもらいましたが、希望のあった全てのツールをトライアルしようとすると、手続きや管理対象が増える手間もさることながら、それぞれの検証結果が薄くなる懸念があったため、トライアル対象は以下に決定しました。
4月半ばに検討を開始して、GWを挟んだとはいえこのトライアル開始までに1ヶ月半ほどかかってしまったのには正直少し焦りを感じていました。
こうしている間にも環境はどんどん変わっていく...
トライアル実行（2025年6月〜7月）
協業を生み出すトライアル運営
6月からトライアルを開始することにしましたが、その際、2つの仕掛けを用意しました。
1. 7月末の社内Meet upでの結果共有を条件化
- 利用者全員に発表してもらうことで、真剣に取り組んでもらう
- 他の人の学びを共有する場を作る
2. ツール毎にチーム横断でのフィードバック共有を推奨
- 普段業務で関わりが薄いメンバー同士の交流促進
- 異なる視点からの気づきの共有
特に2つ目は、利用者自身が提案してくれた素敵なアイデアでした。
フルリモート環境で働く現場では、チーム内のメンバーとは話す機会があるものの、チーム外のメンバーと話す機会はどうしても少なくなり、話す際にも業務に必要な話しかしない傾向にあります。
今回のトライアルは直接的な業務目的ではなく、お互いただ同じツールを使っている者同士という関係になるため、チームを超えたコミュニケーションが普段と違った場できる良い機会になると考えました。
それに、当初はチームごとにフィードバックを集約する方向で考えていましたが、チームごとだと発表数が多くなってしまいますし、結局は検証するツールごと検証結果を集約したいので、はじめからツールごとに1つの発表としてまとめる方が効率的というのもこのアイデアを採用する大きな要因でした。
同じツールを使っているメンバーが定期的に集まって進捗や発見を共有し合う光景は、新鮮で楽しいものでした。
急速な技術トレンド変化への対応
トライアル期間中に大きな変化が2つありました。
5月頃：MCPの急速な台頭
以前から大きなトレンドにはなっていましたが、MCP (Model Context Protocol) の活用への関心がトライアル開始後に組織内で急激に高まりました。
MCPは明らかに今後重要な仕組みになっていくとは感じていましたが、便利な一方でセキュリティリスクもあるため、トライアル開始までに組織的なルール整備をするのは難しいと判断し、様子を見守ることにしていたのですが、想定以上に需要の高まりが速かったということです。
そこで、対処方針を急遽検討しました。
- プラットフォーム公式など出どころが信頼できるものは基本的に利用OK、その他は個別相談
- MCP接続の都度社内申請は不要（スピードを重視）
- ただし誰がどのMCPサーバを使っているかは記録として残すため、使うMCPサーバ、用途、利用者を共有ページに記載
この判断により、MCPの活用が一気に広がりました。
現状はまだまだMicrosoftやAWS、Figma、Atlassianといった大手プラットフォーマーの公式MCPサーバの利用が中心で、それ以外のOSSのMCPを使いたいというニーズはまだそれほど多くない印象ですが、時間の問題であるのは明らかです。
なんなら、弊社のみらい翻訳APIのMCPサーバを作ってしまったという例も出てくるくらいなので...
miraitranslate-tech.hatenablog.jp
まぁ、とはいえホワイトリストを作って管理するようなやり方はすぐに破綻することが目に見えているので、各自使いたいと思った接続MCPサーバについては、どちらかといえばブラックリスト的な方針で、当面はセキュリティリスク等を判断して個別に利用判断することでカバーしていくしかないかなと思います。
これはエンジニア個人がPC上で導入するツールという位置づけで言えば、Chrome拡張やVSCodeの拡張機能と同じように捉えるものだと感じています。 ChromeやVSCodeの拡張機能も、マイナーなものの中には怪しいものが様々ある印象ですが、ホワイトリストを作ろうとはまず考えないでしょう。
6月半ば：Claude Code 一色に
5月22日に正式リリースされたAnthropicの Claude Codeへの注目が急速に高まり、エンジニア界隈のSNSや記事投稿は、Claude Code 一色といってもよいほどになりました。 それと引き換えに、先月まであれだけ話題をさらったCursorとDevinの存在感が一気に低下しているのを感じました。 トレンドの移り変わりが恐ろしく速いです。
トライアル対象に入っていないClaudeの環境整備が急務となり、7月中には追加でClaudeトライアル用の予算を確保し、既存ツールのトライアルと並行してClaudeのトライアルも開始できるようにしました。
一点、Claudeで悩ましいのは、Claude Codeが定額で利用できるのが個人プランであるPro、Maxのプランのみであることです。
組織導入するにはTeamプランに含まれていてほしいところですが、残念ながら含まれておらず、Teamプランにしても結局 Anthropic APIによる従量課金利用をすることになってしまいます。（それで十分だと判断されているところもあるようですが、これはやってみないとよく分かりません）
よって、ClaudeはPro、Maxプランを従業員個人でそれぞれ契約してもらい、経費として精算することにしました。
7月 社内Meet up：多様な気づきの共有
7月末に、社内で「AI駆動開発 Meet up」というイベントの形で発表会を開催し、各ツールの利用者がトライアル結果を共有しました。
この発表会には私達開発部門のメンバーだけでなく、セールス部門や管理部門など様々な部門の方にも声をかけ参加してもらい、オンラインながらも賑やかな勉強会になったかなと思います。
それぞれのツールの良かった点、イマイチだった点、こんなユースケースに抜群に良い！など具体的なフィードバックはボリュームも多く本記事の主旨からは少しズレてしまいますので、機会を改めて登壇者の方に発信してもらいたいと思っていますが、総括的に自分が感じたことを書いておきます。
書く生産性、読む生産性
登壇者の中で、「書く生産性」 と 「読む生産性」 の2つに分けて効果を説明してくれた方がいました。
- 書く生産性
- イチからコードを書かせる
- 要件だけ与えて実装してもらう
- ドキュメントを作る、など
- 読む生産性
- 要件定義やチケット、既存コード、その他関連資料などを読んで仕様を理解する
- コードレビューをする
- 大量のテストケースを読み込んでテスト観点をまとめる、要件定義に対するテスト観点の漏れ、不足ケースを洗い出す、など
どのツールにも共通して「書く生産性」よりも「読む生産性」の効果の大きさを感じる共有が多かったように思います。
これは開発ツールでなくても、LLMのチャットツールなどでも日々体感している方が多いと思いますが、大量の情報を探す作業、読んで理解する作業、要点などをまとめ作業に人間が費やす場合の時間は圧倒的に大きいということかと思います。
もちろん、「書く生産性」についても大きな生産性向上が見込めるのは確かですが、おそらく「読む」よりもプロンプトで出す指示に細かいコツが必要になったり、ツールに書かせたコードやドキュメントを依頼した人間が「読む」部分が残ってしまう（それは自分が書いたものでないため、第三者のアウトプットを読んで理解する工程や場合によっては手戻りが発生する）ため、「読む生産性」に比べて、End-to-Endで見たときの劇的な省力化を感じにくいからでしょう。
AIエージェントにタスクを依頼することが今後増えていく、増やしていく必要があることを踏まえると、「書く生産性」を如何に上げていくかという部分に、経験の差が大きく出てくるような気がします。
現在進行形の本格導入にむけての検討ポイント（2025年8月）
Meet up結果を踏まえ、評判の良かったCursor、Amazon Q Developer、Claudeなどを中心に本格導入の枠組みや進め方を検討中です。 本格導入にあたって検討が必要だと考えているポイントをいくつか挙げます。
利用拡大の取り組み
AI開発ツールをより多くのメンバーに使ってもらうには、トライアル利用をしてくれた、イノベーター/アーリーアダプターであるメンバーに先導役となってもらい、日々の業務の中でAI開発ツールを使った業務を見せ、実際にやってもらうということが必要です。
活用ノウハウのストック
また、何に使うと良いのかというノウハウを共有知にしていきたいので、引き続き社内勉強会やブログでの発信など、利用者には積極的に働きかけていく必要があります。
とりあえず、この記事では具体的なノウハウにふれる余裕がないので、誰か具体的な活用例の紹介を記事にしてほしいです！
効果測定の方法論
業務効率が上がる、生産性が向上する、というのは必ずしも定量的なものだけではないので数字を求めるのは少々息苦しいですが、とはいえ「仕事が奪われる」と話題になるほど劇的に開発プロセスに影響を与えうる技術なので、何らかの定量的な指標は持っておきたいところです。
要件定義や開発着手〜デプロイまでのリードタイムといったFour Keys指標に明確な改善・変化が出るならそれでも良いですが、例えばコードレビューのリードタイムや、テストプロセス（テスト計画、ケース作成、実施、結果レビューなど）の工数削減など、それぞれチームで計測可能な指標を1つでも決めておき、チームの開発スピードや品質の改善を定量的にも実感してもらいたいです。
ツール選択の柔軟性
本格導入フェーズといっても、トレンドが2,3ヶ月でガラリと変わってしまう状況です。
今の状況だけでいえばClaude Codeは息長く活躍しそうにみえますが、それでも半年先のことは全く読めません。 なるべく多くのメンバーに活用してもらうために、例えばCursorをエンジニア全員に配布して使ってもらうような戦略を取っている企業もありますが、ほとんど使わないという方も一定数出てくるかと思います。 それはあまりに勿体ないので、全員配布などで特定ツールに固定化することなく、使いたい人がそれぞれ希望するものを都度使えるように整備するのが良いと考えています。 また、AI開発ツールの種類は本当に幅広く、複数のツールを併用したり使い分けたりして効率化していくものと捉えているため、予算の範囲内であれば1人あたり1,2種類に限定するなどといった制限も設けないようにしたいと思っています。
ただし1人で多くのツールの利用者になり同時に扱いきれない懸念はあるので、都度フィードバックをしてもらい、利用頻度が低くなったものは解約するなどの運用を丁寧に行う必要は出てきそうです。
予算の取り方
使うツールがコロコロと変わってしまう可能性のある状況では、ツール毎に予算を取るのではとてもじゃないですが変化についていけません。 今後新しいツールの新規採用、乗り換え、利用停止などが頻繁に起こることを想定し、少なくとも今年度は特定のツールに限定しないAI開発ツール用の予算として広く予算確保したいと考えています。
契約内容・プランについて
組織導入の場合、請求を一本で管理できること、有償オプション機能のON/OFF設定、従量課金対象について管理者側で課金上限額を設定してコントロールできることなどから、基本的には「Teamプラン」などの企業向けプランが最も良いのですが、Claude Codeのように個人向けプランでしか定額利用できないものについては、管理に一定のリスクはあることを承知の上で個人ごとに契約してもらい経費として精算するということも必要になってきます。
※他の会社ではClaudeの契約や支払いはどうしてるんでしょうか？事例があったら教えてほしいです。
参考：AI駆動開発の組織導入における考え方についての事例
上に挙げたような、組織導入における検討ポイントや考え方については、様々なところで発表・投稿されている事例や、DX Criteria のタネ：生成AI活用ヒアリングレポート などを参考に方針を決めていきたいと思います。
（↓他社事例）
まとめ：ふりかえりと今後の展望
この4ヶ月間の経験で分かったのは、とにかく速い今のAI開発のトレンドとその変化への対応を経験できたこと、AI開発ツールに限らず、組織への新しいツール導入する際のプロセスや、スムーズに進めるためのポイントを改めて確認できたことでした。
また、技術的な良し悪しの検証以外にも、ツール導入や技術検証の機会を横の組織のつながりを活性化する機会として有効活用できるということに改めて気付かされました。
今後も技術トレンドは変化し続けると思いますが、この4ヶ月で築いた「小さく始めて、トレンドをよく見てキャッチアップし、柔軟に対応する」アプローチは、他の新技術導入にも活かせそうです。「組織として新しいものを取り入れる力」を継続的に向上させていきたいと思います。
私達の取り組みが、少しでもAI開発ツールの組織導入を検討されている方の参考になれば幸いです。何か質問があれば、SNSなどでお気軽にお声がけください。
おまけ
余談ですが、この記事はClaude Codeにこれまでの経緯を箇条書きしたものや作成した資料のリンクをプロンプトとして与えて叩き台を生成してもらって書きました。
構成や見出し、箇条書きした要素の文章化など意外と出来が良かったのであまり手直しせずに出せれば、今後もっと簡単に記事を書いて出せるかも...！と期待して叩き台を推敲し始めたのですが、直したいところ、追記したいところがどんどん出てきて、当初3,000〜4,000文字くらいだった叩き台が、最終的には3倍くらいのボリュームになってしまいました。。
叩き台で触れたことから色々と考えていたことが思い出されるので仕方ないですし、考えていたことを引き出してくれるという意味では叩き台作成の役割は大いに果たしてくれていると思いますが、「どこに重点を置いて説明したいか」といったポイントはちゃんと指示しないとズレたポイントを強調したり、どこも強調しないような薄い印象の記事を作ってしまったりするので、そこは最初にきちんと指示して精度を上げるか、もしくは構成やアウトラインの叩き台と割り切って自分で編集するかのどちらかだな、と感じました。
その意味でこの記事は完全に後者に振り切ってしまっているわけですが。。
あまり想いを込め過ぎない割り切った技術紹介的な内容などであれば、手直し少なく投稿できる記事も作れるかもしれません。
なお、下書き作成後のレビューをしてもらう相手としては、かなり優秀でした。
今後記事を書く際にまた試してみたいと思います。
We are hiring!
みらい翻訳では、私たちと一緒に翻訳プロダクトの開発を進めていただけるエンジニアを募集しています！ ご興味のある方は、ぜひ下記リンクよりご応募・お問い合わせをお待ちしております。
*3:普通なら「手段を目的化するな」なので言いにくいなと思ってましたが、この記事の中で言及されているのを見て激しく同意しました。- 一休の伊藤直也氏に聞く、フルベットしない技術ポートフォリオ戦略 〜実践から学ぶ、医療変革プラットフォーマーの次なる一手〜 | AIと共に進化する開発現場・役割の再定義と人間の価値
