AIを組織で使うということ〜全社標準としてのClaude Code

生成AIが業務に入ってきてから、社内でAIを使う人が増えました。便利だ、生産性が上がる、そんな声を耳にすることも多いはずです。

けれど、多くの企業の実態を見ると、AIの活用は個人レベルにとどまっているケースが少なくありません。興味のある人が思い思いにツールを試し、部署ごとに別々のサービスを契約し、誰がどう使っているかは曖昧なまま。「AIを導入した」と言いつつ、組織として何かが変わったかと問われると、答えに詰まってしまう。

これは言ってみれば「壮大な部分最適化」です。一人ひとりは速くなっているのに、組織として何が変わったのかは、見えてこないのです。

個人の効率化と組織の変革は違う

個人がAIを使って速く仕事ができるようになる、それ自体は良いことです。ただ、それは個人の中で完結する効率化にすぎず、一人ひとりが速くなるだけでは、組織そのもののかたちは変わりません。

組織として何かを変えるためには、別の動き方が必要になります。誰かが見つけた知見が、別の誰かに伝わる。誰かが踏んだ落とし穴を、別の誰かが踏まずに済む。一人ひとりの試行錯誤が、組織全体のナレッジとして蓄積されていく。そういう循環が回って初めて、組織としての練度が上がっていきます。

そのためには、全員が同じ道具を使うことが大前提になります。バラバラの道具では知見も分断されてしまい、「使いたい人が使えばいい」のままでは、組織には何も残りません。道具を揃えるとは、そこに組織として向き合うという意思表示でもあるのです。

本当の変化はワークフローから

組織が本当に変わるのは、ワークフローが変わるときです。個人の作業が速くなっても、ワークフロー全体が以前のままなら、ボトルネックは別の場所に移るだけで、全体の流れは変わりません。仕事の受け渡しの順番、誰がいつ何を判断するか、どこに承認が入るか——そういった一連のかたちが変わって初めて、組織の動き方が変わります。

そして、ワークフローは個人では変えられません。自分の作業範囲だけを最適化しても、関わる人たちが同じ前提を共有していなければ、新しい流れは成り立たない。だからこそ、全社で揃えて取り組む必要があるのです。

その先には、ビジネスモデルそのものを問い直す段階も控えています。AIエージェントが当たり前に動く前提でビジネスを設計し直せば、仕事のかたちや収益構造そのものが変わっていく。すぐに答えの出る話ではありませんが、そこまで見据えて備えていく必要があります。

エージェントが現れて、開発のかたちが変わる

特にソフトウェア開発の世界では、AIによって仕事のかたちそのものが変わりつつあります。注目すべきは、AIエージェントの登場です。チャット型やコード補完型と違い、エージェント型のAIは、目的を伝えると自律的に手を動かします。履歴を残しながら、対話を重ねて成果物を少しずつ直していけます。

人間がエディタの前に座り、自分の手でコードを書く——という従来の開発の前提が、ここで変わります。人間はエージェントに何を作ってほしいかを伝え、エージェントが書いたものをレビューし、方向性を調整する。コードを書く主体が、人間からエージェントに移っていきます。

これは効率化の話ではありません。プログラマの仕事のかたちが変わる、パラダイムの移行です。

なぜ全社標準にこだわるのか

ソニックガーデンは、これまで会社として使う技術を「全社標準」として定めてきました。Ruby on Rails、Amazon Web Services、GitHub。プログラマが各自で好きな道具を選ぶのではなく、全員が同じ技術を使うことに意味があると考えてきたからです。

この考え方の根っこには、私が前職でSIerに勤めていた頃の経験があります。一般的な受託開発の現場では、プロジェクトごとに技術選定をし、アーキテクチャから考え直すのが当たり前でした。エンジニアにとっては新しい技術を試せる機会でもあるのですが、それでは案件を終えるたびに知見が散らばってしまい、組織として何も積み上がっていきません。こなれていない技術でお客さまの案件に取り組むことが、プロフェッショナルとしてどうなのか、という疑問もずっと感じていました。

だからソニックガーデンでは、社内で技術を統一し、ミドルウェアを整備し、ナレッジを蓄積していく形をとってきました。お客さまの案件で最高のパフォーマンスを出せるのは、この前提があってこそです。

たとえばRailsを全社で揃えているからこそ、書き方のコツやハマりどころを回避するノウハウを、プログラマ同士で同じ言葉のまま共有できます。誰かが見つけた工夫が、別のメンバーの学びになる。一人ひとりの経験が、そうやって組織のナレッジとして積み重なっていくのです。技術選定が分かれていれば、こうはなりません。

Claude Codeを全社標準に加えた

2026年3月、その全社標準にClaude Codeを加えました。

ある日突然「これにします」と決めたわけではありません。それまでも社内ではAIエージェントの活用が進んでいて、メンバーそれぞれが自分なりにベストだと思うツールを試していました。誰かに強制されるわけでもなく、現場で試行錯誤しながら、自分のスタイルを作っていた段階がしばらく続きました。そうしているうちに、自然と使い手が増え、評価も定まってきたのがClaude Codeでした。実態としてデファクトスタンダードになっていたものを、会社として正式に位置づけ直したかたちです。

Claude Codeを多くのメンバーが選んだのは、現時点でモデルの賢さと、新しい考え方や実装が出てくるスピードが、他のエージェントよりも優れていたからです。成果物を作っていくという目的に対して、最も適しているという感触が、現場の中で共有されていきました。

ただし、半年後の勢力図は誰にもわかりません。AIの進化は速く、今ベストとされるものが、半年後にも同じ位置にいる保証はどこにもない。それでも全社標準を決めるのは、現時点のベストに全員でコミットするためです。より良いものが出てきたら、そのときも全員で乗り換える。バラバラに乗り換えるのではなく、組織として乗り換える。全社標準とは、そういう意思決定の仕方です。

この取り組みは、エンジニアだけにとどまりません。コーポレート部門も含め、ソニックガーデンでは社員全員がClaude Codeを使い、エージェント型の働き方に移行していこうとしています。プログラマではない仕事も、エージェントとの協働で大きく変わるはずだと考えているからです。これについては、また別の記事で詳しく書きたいと思います。

現場の記録を、当事者の言葉で

ソニックガーデンのプログラマたちにとって、AIエージェントとの協働はすでに日常です。コードを書くパートナーとして、Claude Codeが常に隣にいる。何ができて、何が難しいのか。どう指示を出せばよいのか。どこに気をつけるべきか。日々の現場で、新しい知見が生まれ続けています。

それは、プログラマ自身の言葉で語られるべきものです。経営者の私が概念で語るよりも、毎日コードを書いている当事者の体験として語る方が、ずっとリアリティがあります。

そこで、ソニックガーデンのプログラマたちが、Claude Codeにまつわる記事を1ヶ月間毎日書いていくことにしました。テーマは自由。ノウハウでもいい、トラブルの記録でもいい、新しい使い方の発見でも、エージェントと働くことについての所感でもいい。各自がZennやQiitaなどの個人アカウントで投稿していきます。

1ヶ月の短期集中連載として、5月1日から始まります。

記事の一覧は以下のページから辿れます。

まとめページ: https://www.sonicgarden.jp/tech/claudecode

ハッシュタグ: #claude_on_sonicgarden