はじめに
記事を開いていただきありがとうございます。サーバサイドエンジニアのオーです。
今回は「OSS AIコーディングエージェント、Clineを社内専用ツールにカスタマイズして実務導入した話」をテーマにAIコーディングエージェント導入までの道のりを紹介します。
LDIでは、業務生産性の向上の一環としてAIの導入活動を積極的に進めている段階であり、2025年度の取組拡大領域として「ローソンアプリ領域開発におけるAIエージェント導入」を進めております。
そのスタートの一つとして「AIコーディングエージェントの実務導入」を試み、実現手段として「Cline for LDI」という、Clineをカスタマイズ・CS部(コンシューマサービス部)専用ツール化し、実務導入することに挑戦しました。
Cline とは
Clineは、VSCode上で動作するオープンソースの自律型AIコーディングエージェントです。 主な特徴は以下の通りです。
| 機能 | 説明 |
|---|---|
| 柔軟なLLMプロバイダー対応 | AWS Bedrock, OpenAI, LiteLLM, Ollamaなど10種類以上を連携可能 |
| .clineignore | AIの読み込み対象から除外したいファイルを指定し、セキュリティ確保とトークン節約 |
| .clinerules | コーディング規約や技術スタックを記述し、AIの回答を望む方向へ誘導 |
| Plan & Act | いきなりコードを書かず、計画を立ててから実行に移る |
| Human-in-the-loop | ファイル操作やコマンド実行のたびにユーザー承認を求める(安全確保) |
Cline for LDI とは
「Cline for LDI」は、OSSであるClineをクローンしカスタマイズした、「社内専用のAIコーディングエージェント(実験版)」です。 主に、独自に定めた「機能制限」要件に合わせたカスタマイズ改修が行われたツールになります。

- ※ API ProviderはLiteLLM以外は選択できないようになっているのが特徴です
環境構成
以下は環境構成を表す図です。「Cline for LDI」は、VPN環境での利用が前提となっており、 AWS BedrockのLLMを、LiteLLMを経由して使うことが前提になっています。

- ※1: Cline for LDI。カスタマイズされたVSCode拡張機能
- ※2: LLM Proxy。社内サーバー上のLiteLLM(ログ監査・モデル統合)
LiteLLMを利用したAI活用環境の詳細については以下の記事を参考できます。
techblog.ldi.co.jp
カスタマイズ解説1: Clineのディレクトリ構造
Clineは大きく分けて「Webview」「Extension Host」の2つの領域で構成されます。
- Webview
- Reactベースのチャット画面や設定画面
- 改修例: 設定画面から不要な項目(MCP, LLM URL入力欄)を削除
- Extension Host
- Node.js環境。ファイル操作、ターミナル実行、API通信を担当
- 改修例: .clineignoreの強制適用や、テレメトリー送信の遮断ロジックを追加
※「改修例」の実施理由は「カスタマイズ解説3」セクションで後述します。
実際のディレクトリ構造から見ると、以下のようなイメージです。
cline/ ├── webview-ui/ # Webview(ReactベースのUI、フロントエンド) │ ├── src/components/ # チャットインターフェースおよび設定画面コンポーネント │ └── ... ├── src/ # Extension Host(コアロジック、バックエンド) │ ├── api/ # LLMプロバイダー(Anthropic, OpenAIなど)連携ロジック │ ├── core/ # Clineエージェントのメインロジック(プロンプト管理、コンテキスト処理) │ ├── services/ # MCP, Telemetryなど外部サービス連携モジュール │ ├── extension.ts # 拡張機能実行エントリーポイント │ └── ... └── package.json # 拡張機能の権限(activationEvents)およびコマンド定義
カスタマイズ解説2: ビルド
以下のコマンドを参考し、手元のClineソースコードをベースにビルドを行い、VSCodeにインストールすることができます。
# 1-1. リポジトリのクローン: # GitHubからClineのソースコードをローカル環境に複製 git clone https://github.com/cline/cline.git git checkout -b my-custom-cline v3.51.0 # 1-2. 環境設定および依存パッケージのインストール: # プロジェクトのルートと`webview-ui`ディレクトリの両方で必要なパッケージをインストール npm install cd webview-ui npm install # 1-3. 拡張機能のパッケージング: # VSCode拡張機能管理ツール(`vsce`)を使用して、`.vsix`インストールファイルを生成します。 npm install -g @vscode/vsce vsce package # 1-4. VSCodeに拡張機能をインストール code --install-extension {パッケージングで生成されたvsixファイル名}.vsix
カスタマイズ解説3: 独自に定めた「機能制限」要件と改修
今回カスタマイズした機能はいくつかありますが、今回は代表的なものとして、以下の4つに絞って紹介します。
※ 本記事では、改修対象として参考にした元のソースコードファイル(GitHub)のみを参考情報として記載しています。
要件① - LLMエンドポイントの固定 (社内LiteLLMのみ利用可)
- 内容: Clineのエンドポイント設定を強制的に「社内に構築されたLiteLLMプロキシサーバー」に固定
- 目的: 意図しない未許可LLMサービスなどに情報を送信するリスクを遮断
- 参考にしたソースコード:
要件② - .clineignoreの設定強制・ホワイトリスト化
- 内容:
.clineignoreのデフォルト動作を「ファイル遮断」に変更し、明示的に許可されたファイルのみアクセス可能な、ホワイトリスト方式に改修 - 目的: 設定漏れやミスによる、意図しない機微なファイルアクセスのリスクを抑制
- 参考にしたソースコード:
要件③ - MCP機能の無効化
- 内容:
- フロントエンドの関連UIに対してMCP関連機能を排除
- MCP関連バックエンド機能の無効化
- 目的: 意図せぬMCP関連セキュリティ事故可能性を抑制
- 参考にしたソースコード:
- webview-ui/src/components/mcp/configuration/McpConfigurationView.tsx
- webview-ui/src/components/chat/ServersToggleModal.tsx
- webview-ui/src/components/menu/Navbar.tsx
- webview-ui/src/components/settings/sections/FeatureSettingsSection.tsx
- src/core/controller/index.ts
- ※MCP関連サービスインスタンスの無効化
- package.json
- ※ VSCode上で立ち上がるUIアイコンと、ClineのUIと連携するメニューを無効化など
要件④ - テレメトリー機能の無効化
- 内容: PostHog(ユーザーパターンログ)およびSentry(エラーログ)への送信を機能的に排除
- 目的: 意図しないユーザー情報の収集同意および送信の可能性を抑制
- 参考にしたソースコード:
振り返り: 安全なAIコーディングエージェント導入の第一歩
今回は、企業環境に適した「安全なAIコーディングエージェント」を導入したいという思いから、OSSのソースコードを直接改修し、機能を制限することでさまざまな不明や検討ポイントを物理的に排除し、迅速に社内導入を行うというアプローチを試みました。
これは、社内におけるAIコーディングエージェント導入の道を切り拓くための第一歩でしたが、同時に技術や運用面などにおける課題と、その先にある新たな可能性を確認するキッカケでもありました。
今回の試みの振り返りとして「良かった点」「課題点」「今後やりたいこと」の3つの観点で振り返り、本記事を締めくくりたいと思います。
良かった点
① OSSをベースとした社内ツール開発という「経験と知見」を少しながら得た
以下の観点で、少しながら自分にとっても知見を広めるいい機会でした。
- VSCode拡張機能の仕組みを知れた
- Cline内部のアーキテクチャを知れた
- OSS▶︎社内ツール化のメリット・デメリットや運用の経験を得た
② 「AIコーディングエージェントの実務導入」に関して、セキュリティ懸念で停滞していた状況から「突破口を開く過程」がやりがいがあった
突破口を開くための自らの行動として取り組んだ以下の過程は、とってもやりがいがあって良かったと思っております。
- 仮説を立てて、実現可能性の裏付けを先行してリサーチ
- 具体的なソリューションとしてまとめ実務導入提案
- ステークホルダーの理解と承認を獲得
③ 「AIコーディングエージェントの実務導入」に関して、「当分難しいだろう」と多くの人が考えていた状況から、実務導入を成し遂げて「開発者体験を向上」に貢献できた
社内規定がまだ不明瞭でAIコーディングエージェントの導入に向けた動きが停滞していた中、 「まずは実務への導入を形にしてメンバーに届ける」という思いを持って推進してまいりました。
以下の観点で、微力ながら開発者体験を向上できたと考えています。
- 業務効率の向上: コード分析・生成などの日常業務で実質的な時短と効率アップを体感
- 業務満足度向上: 「AIコーディングをしてみたいができない」現場のモヤモヤを解消
- 実務向けAIコーディングエージェント文化の形成: チーム内でナレッジ共有文化が生まれ、組織的な資産として蓄積を開始
実際に、導入後のユーザーアンケートでは以下のようなポジティブな結果も得ることができました。 以下は、アンケート結果の一部引用です。
Cline for LDIユーザーアンケート分析引用 (2025年12月時点)
※ 回答者数: 14名
▶︎ 85.7%が作業時間短縮を実感
▶︎ 78.6%がコード作成・修正で利用したことがある
▶︎ 64.3%が技術調査・仕様確認で利用したことがある
課題点
① 本家のプロジェクトとのアップデートの同期と「保守の難しさ」
当初、本家の最新機能やコードの取り込みは、定期的に一括更新を行えば問題なく運用できると考えていました。 しかし、実際に運用に入ってからは、アップデート管理における困難な状況が課題となっていると感じています。
- 保守リソースの不足: 本業と並行では、サイドプロジェクト的な位置づけのため優先度が下がりがち
- 本家コードとの差分広がり問題: 独自修正が積み重なることで本家との差分が広がり、アップデート取り込み時の競合解決が困難になる状況に直面
② 急変するAI環境に柔軟に対応しづらいという「拡張性の制約と限界」
日々新しい技術が登場するAIエージェント市場の状況を考えると、現在の環境は以下の観点で、拡張に限界があると感じています。
- 環境の固着化: 特定ツールに固着化されているため、追加ツール導入や環境拡張に限界がある。今後登場する優れたAIエージェントやMCP、SaaSなどを柔軟に試すことが困難。
- 安全性と拡張性のトレードオフ: 有用な機能を制限することで安全性を確保しているが、本来得られる生産性向上の機会を逃している。
今後やりたいこと
Cline for LDIの導入は、社内でのAIコーディングエージェント活用の第一歩となりました。
まだ個人の思いの段階ですが、今後は現在の環境の価値を最大化しつつ、並行して次なる環境への高度化に挑むという、二つの軸で取り組みを進めていきたいと思っております。
① 現環境の価値最大化:Cline for LDIのさらなる活用
これまでの取り組みにより、以下の価値を生み出すことができました。
- AIコーディングエージェント環境を0から1にできたこと
- コード生成・分析において一定水準の生産性向上を確保
- AIコーディング文化形成を0から1にできたこと
- 「考え方」「ノウハウ」を集団ナレッジとして蓄積
この価値を活かし、以下の方向での活用の拡大について挑みたいと考えています。
.clinerules整備による活用領域拡大- 社内コーディングルールに沿ったコードサジェスト
- より高度なAI駆動開発のリサーチ・検証(仕様駆動AI開発など)
- ユースケースの拡大
- レガシーシステム移行への活用
- コードからの仕様書逆生成
- PM・SE領域への活用拡大
② 安全性と最新AI技術恩恵を両立できる「次なるAIコーディング環境」の検討
一方で、「保守の難しさ」や「拡張性の制約」という課題も明確になっています。 これらを根本的に解決するため、並行して次なる環境へのリサーチ・検証も挑んでいこうと思います。
- コンテナベース隔離環境&トラフィック中央管理環境の活用によって、安全性と柔軟性を両立させたAIエージェント実行環境のリサーチ
- AI活用ポリシーの段階的な見直しと整備
- 複数のAIツール・SaaSサービスとの連携可能性の調査
これらの取り組みにより、短期的には現環境での成果を最大化しつつ、中長期的には安全性と最新技術の恩恵を両立できる、より持続可能なAIコーディング環境の実現を目指したいと思います。
おわりに
これから定期的に技術ブログを更新していくので、興味がある方は是非「読者になる」で応援していただけますと幸いです。今後ともローソンデジタルイノベーションをよろしくお願いいたします!