こんにちは、CTO の田中（@stanaka）です。 最近は趣味で LLM の内部構造を勉強していて、LLM 自作などに手を出しています。
さて、世の中は AI コーディングツールの話題で持ちきりですが、弁護士ドットコムでも活用を進めており、現在の状況をまとめてみました。
導入ツール
弁護士ドットコムでは、以前から GitHub Copilot を使ってきましたが、今年の初頭からさまざまな AI コーディングツールの導入を進めています。
ざっとあげると、GitHub Copilot, Cursor, Cline, Claude Code, Devin あたりのメジャーどころは一通り使えるようにしています。 Kiro もすこしだけ乗り遅れて waitlist 待ちになっていたところ、先日無事に invitation が届きました。
実際の利用状況を聞いてみると Cursor 勢と Claude Code 勢が多いようです。 6 月頃は Cursor 勢が主流（Claude Code の 3 倍程度のシェア）でしたが、8 月現在では、 Claude Code ユーザーが大幅に増えてきています。 また、 Slack で直近 1 週間での発言数を調べてみると、Claude Code が倍以上言及されていました。
導入後の変化
AI コーディングツールを導入してからの効果ですが、一般にエンジニアの生産性を定量的に計測することが難しいように、AI コーディングツールの効果を定量的に測ることも難しいです。 そのため、アンケートによる評価や、特定のチームでの状況を深掘りして分析する、ということをしています。
すこし前の 6 月下旬に実施したアンケートでの興味深かった結果を 1 つ紹介します。
上記のグラフは master(main)にマージしたコードのうち、AI コーディングツールを使って書いたコードの割合を聞いたもので、中央値は 40％となりました。 AI が出力した後に手で微調整したものは除外する、という条件なので、比較的厳し目の聞き方ですが、それでも 40％というのは想定以上でした。 本格的に AI コーディングツールを活用しだして数ヶ月というタイミングであっても、人間による微調整が不要な品質のコードが AI によって多く書かれている、ということが言えます。
また直近だと、以下のエントリで紹介されている「手動コーディング禁止祭」という取り組みがあります。これはすべてのコードを AI に書かせよう、という実験的なトライアルですが、チーム内で、より AI を活用することを考えるための契機となったようです。
また AI の活用が進むことで開発プロセスにおけるボトルネックがコードレビューになっている、ということが明確になってきています。 コードレビューの効率化のために、以前から利用している CodeRabbit をさらに活用したり、Claude Code にコードレビューをさせる、ということも試され始めています。 ボトルネックとなっていた箇所の効率を上げて、そのボトルネックを解消すれば、また別の箇所がボトルネックとなるのは必然です。 ですので、開発プロセス上のクリティカルパスの見極めとその改善を繰り返していくことが開発プロセス全体の効率を上げていく上で重要となります。
またデザイナーとの協業にどのように AI コーディングツールを活用できるかも、今後の課題です。 Figma MCP の活用もしていますが、まだまだ満足できるレベルではなく、試行錯誤が引き続き必要となりそうです。
最近の取り組み
最近始めた、もしくは最近も続けている取り組みをいくつか紹介します。
社内勉強会
開発系 AI ツールに関する社内勉強会を実施しており、先月に第 1 回を行いました。面白い発表も多かったので、徐々に技術ブログで公開していってもらえればと期待しています。
MCPサーバー
こちらは最近になって始めた、というわけでもないのですが、さまざまな MCP サーバーを活用して、効率をあげようとしています。
社内で観測したところ、esa, playwright, figma, serena あたりの MCP サーバーが使われているようです。
クラウドサインチームでは、esa や JIRA、Gitlab にアクセスしたり、テストアカウント情報を取得できたり、 開発しているサービスに合わせた独自開発のMCPサーバーを活用しています。
開発を円滑にするためのツールを作ることはこれまでも良くありましたが、それらを MCP サーバーとすることでさらに応用範囲が広がっていきますね。 MCP サーバーを作ること自体はそれほど難しくないので、アイデア次第でより便利にしていけそうです。
サブエージェント
ここ最近は、AI 単体に指示を出した際の性能限界も見えてきています。 その限界を越えるために、複数のエージェントを定義して役割に応じたタスクを処理させたり、複数のエージェントを連携させるような試みが増えてきています。 Claude Code のサブエージェントはその一例ですが、いま試行錯誤を始めているところです。 複数の AI エージェントをうまく協調させられると、大きなタスクや難しいタスクなど、処理できるタスクの幅を広げられる可能性があります。 これは開発効率をさらに向上させられる可能性があり、個人的にも大いに期待しています。
LiteLLMによるLLM APIプロキシ
Claude Code などで利用する LLM API は Azure OpenAI や AWS Bedrock を利用しているのですが、現状の設計では細かいコスト分析が難しい状況でした。 そこで LiteLLM をプロキシとして導入することで、API 利用の詳細なコスト分析ができるようになりつつあります。 大量に利用してる場合には、Claude Max のような定額プランへの移行を促していくなど、コストの最適化をしていこうとしています。
その他
その他にもいろいろ試行錯誤をしており、このブログでもLLMを活用した事例をいくつか紹介しています。
まとめ
最近、新卒やインターンの若いエンジニアと話す機会がありますが、彼ら/彼女らの将来に役立つ指針をなにか持ち帰ってもらうためにも、 AI コーディングツールの現状を伝えています。 ただ、いまの AI の波の後、どのような状況になるのか、まだまだ誰も予測はできていないところです。 ですので、彼ら彼女らには臆することなく、好奇心をもっていろいろ幅広く試すことで波を乗りこなしていくしかない、と伝えています。
そのためにも「新しいツールは、ちゃんとコストをかけて実践の中で評価できるようにする」「どのツールでも使いこなすノウハウが必要となるので、社内での情報共有や勉強会を通じて、ツールの使い方を学ぶ」ということを大事にしています。
また数ヶ月すると状況がいろいろ変っていそうですので、その時々で現在地をまたお知らせします。
