はじめに

最近のAI関連技術の進化は目まぐるしいですよね。私たちfreeeの開発組織でも、世の中のトレンドに追従、あるいは先回りする形でGitHub Copilotや社内から安全にLLMを利用するための基盤整備にも取り組んできました。そして2025年、これまでの検証フェーズを経て、AI活用をさらに加速させるべく、AIツールの本格導入を進めています。

現在、freeeの開発現場では主に GitHub Copilot、Cline、そしてDevinといったAIツールが活用されています（他にも細かなツールはありますが！）。特に最近全開発者向けに開放されたClineは、今後の開発スタイルを変える可能性を秘めていると注目しています。

この記事では、そのClineを全社導入するにあたり、私たちがどのように考え、どのような課題に直面し、そしてどう対策してきたのかをお伝えできればと思います。この記事が、AIツールの導入を検討されている方や、AI駆動開発に興味のある方の参考になれば幸いです。

freee流 AIツール導入の進め方

AIツールの導入は、従来のツール導入とは異なる特有の難しさがあります。例えば、プロンプトインジェクションや意図しない挙動など、前例の少ないセキュリティリスクへの対応も求められるかなと思います。「開発効率が劇的に上がるらしい」という期待と、「でも安全性は大丈夫？」という懸念の板挟みは、多くの組織が抱える悩みではないでしょうか。

AIツール導入のための2つの仕組み

私たちfreeeでは、この課題に向き合うために、AI特区制度、AI駆動開発チームという2つの仕組みを導入しています。

AI特区制度

「いきなり全社展開するにはリスクが高いけど、試してみたい！」そんなAIツールを安全かつ迅速に検証するための制度です。特区に認定されたチーム・メンバーに限り、サンドボックス環境など、定められた条件下でのツール利用を許可します。これにより、限られた範囲で実際の開発現場での利用感や課題を洗い出し、高速な検証サイクルを回します（ちなみに、特区認定にはチームごとのワーキングアグリーメント制定とセキュリティ担当のレビューが必須だったり、スピーディな決裁のためにツール費用予算を分けたりもしています）。

AI駆動開発チーム

AI特区などで明らかになった課題やリスクに対処し、AIツールの全社導入を推進する専門チームです。既存の仕組みでは対応しきれないAI特有のリスク管理、専用の基盤開発やガイドライン策定、そして導入効果の最大化や効果測定などを担う、いわば「実行部隊」です。実行力とスピードを担保するため、今までの組織とは別の専任のチームとして立ち上げられました。

導入の流れ

この体制のもと、freeeでは以下のような流れでAIツールの導入を進めています。

1. AI特区での検証

実際のプロダクト開発メンバーが特区でツールを試用し、リアルな使い勝手や課題をフィードバックします（ここで「うーん、コスパ悪いね」とか「セキュリティ的にちょっと……」となって全社展開に至っていないツールも実はたくさんあります）。

2. ガイドライン策定・基盤構築

「これはイケる！」となったツールについて、特区での知見をもとに全社展開に向けたガイドライン策定や、セキュリティ・利便性を担保する基盤機能を開発します。

3. 全社展開＆運用

準備が整ったら、満を持して全社へ展開！導入後もフィードバックを収集し、継続的に評価・改善（例えばCline向けのMCP整備やコスト監視など）を行っていきます。

Cline導入でぶつかった3つの壁と対策

さて、本題のCline導入です。振り返ると、大きくセキュリティ、コスト、AIリテラシーの3つの壁がありました。それぞれの壁に対してどう対策したかを紹介していきます。

セキュリティの壁

これはClineに限らずAIツール全般に言えることですが、社内コードが意図せず学習データとして利用され、間接的に流出するリスクは常にあります。また、Clineは自律的にファイルを参照するため、アクセスキーなどの機密情報が外部に送信されてしまうリスクも、通常のチャットツールより格段に高まります。さらに、エージェント特有のリスクとして、プロンプトインジェクションなどを経由して危険なコマンド（ファイルを消すぐらいならかわいいですが、外部に情報を送信されるリスクもあります）が実行されてしまう可能性も考慮する必要がありました。

対策1: Amazon Bedrock の採用

学習データ利用の懸念に対しては、Amazon Bedrockの採用が決め手となりました。Bedrockは、入力・出力データがモデルの学習に利用されず、モデルプロバイダーとも共有されないことが明確に謳われています。様々なモデルを試したいClineの特性を考えると、この点は非常に重要でした。加えて、AWS環境に慣れている私たちにとって、IAMによるアクセス管理など、既存の仕組みとの親和性が高い点もメリットでした。

対策2: 社内基盤による独自プロキシ

機密情報の流出や危険なコマンド実行のリスクに対しては、社内のLLM基盤上に独自のプロキシサーバを立てて対策しています。このプロキシは、Bedrockとの通信を仲介し、以下の処理を行っています。

入力マスキング: アクセスキーやクレジットカード番号など、事前に定義した機微情報を検知し、Bedrockに渡さないようにフィルタリングします。
出力ガードレール: Clineが生成したコマンドをチェックし、許可されていない危険なコマンドの実行をブロックします。

なお、このようなマスキング、ガードレールの仕組みは、社内向けMCPに関しても必要に応じて類似の対策をしています。

社内基盤のプロキシの図が描かれている。左からPC, Proxy, Bedrockが並んでいて、PCからProxyにRaw Input, Proxy から Bedrock に Safe Input, Bedrock から Proxy に Raw Output, Proxy から PC に Safe Output のデータが流れることを表現している。 — 社内基盤のプロキシの図

コストの壁

Bedrockをはじめとする多くのLLMサービスの利用料金は基本的にToken数での従量課金のため、利用量の増加に伴うコスト増大が予測しにくいという課題があります。固定料金のGitHub Copilotと異なり、全社展開にあたってはコスト管理が非常に重要な論点となりました。（正直、コストについては絶賛びくびくしながら見守り中です…！）また、それなりにコストがかかるツールである以上、費用対効果をしっかり評価していく必要もあります。

対策: リアルタイム監視とコストの可視化

コスト管理と評価のために、以下の取り組みを行っています。

Bedrockのタグ付け: 推論プロファイルごとにタグを付け、どの用途（どのツール）でどれくらいコストが発生しているかを可視化しています。
プロキシでの詳細計測: 前述のプロキシサーバでリクエストログをDatadogで収集・分析し、開発者ごとのToken数やリクエスト数をリアルタイムで計測できるようにしています。これにより、詳細な利用状況やコスト内訳を把握し、活用度の評価にも繋げようとしています。万が一、想定外に高額な利用が発生した場合、早期に検知して対策を打てるようにするのも狙いです。

AIリテラシーの壁

ClineのようなAIツールは、使い方によってパフォーマンスに大きな差が出ることが、社内での試用段階から指摘されていました。また、単にパフォーマンスが出ないだけでなく、例えば .clineignore ファイルを適切に設定しないまま利用すると、意図せず機密情報を含むファイルをAIに渡してしまうなど、セキュリティリスクに繋がりかねません。

対策: Clineに寄り添った対策 + 多層防御

この課題に対しては、Clineの仕様に合わせた対策と、組織的なセキュリティ対策を組み合わせて対応しています。

共通ルールの策定: 全開発者が必ず設定する共通の Custom Instructions やリポジトリごとの .clineignore の設定を徹底し、安全な利用を促しています。
MCPの制限と開発: セキュリティリスクのあるMCPの利用を制限（現在はホワイトリスト方式）しています。ただし、それではあまりに不便なので社内ツールと連携するカスタムMCPの開発も進めています。
多層防御: Cline固有の対策に加え、アクセス元IPアドレス制限やリポジトリのSecret Scanningの利用など、既存のセキュリティ対策も徹底し、多層的な防御を図っています。

これからどうするの？ - まとめと今後の展望

Clineの全社導入は、私たちにとって大規模なAIツール導入の初めてのケースとなり、多くの学びがありました。

学び1. AIツール導入には専用の対策が不可欠

AIツールはセキュリティやガバナンスを完璧にしてから……と待っていては、いつまで経っても導入できません。かといって、リスクを無視して「えいや！」で導入するにはあまりにも怖い。守るべきラインを明確にし、関係者を巻き込んでリスクと導入効果を天秤にかけながら判断していく、当たり前のようで難しいプロセスが不可欠だと痛感しました。また、システム的な対策だけでリスクを防ぎ切ることは難しく、ガイドラインや利用ルールの整備といった組織的な対策の両輪が重要だと感じています。

学び2: 個別のツールに特化した対策が効果的

AIツールと一口に言っても、その特性やリスクは様々です。Cline一つとっても、画一的な対策では不十分な場面が多くありました。今後登場するであろう新しいツールに対しても、それぞれの特性を深く理解し、個別の対策を講じていく必要があると感じました。（そのためにも、まずは実際に触ってみることが大事で、プライベートで新しいツールを試している社員が多いのは、本当に助かっています。）