非エンジニア組織の私たちが、Claude Codeに一本化する理由

チームでAIを活用するには、リテラシーの集中が要る

ただ、ここから先に進もうとしたときに、気づいたことがあります。

非エンジニアの組織でAIのチーム活用を突き詰めていくと、結局、リテラシーの問題に行き着くんです。

個人で使うぶんには、好きなツールを好きなように使えばいい。でもチーム全体で成果を出そうとすると、「全員が共通の理解とスキルを持っている」ことが前提になります。

実際に起きたことを一つ挙げると、毎月たくさんのツールを作ったけれど、自分が作ったものは使うのに、他の人が作ったツールはなかなか使おうとしない。チームの中からも「使われるシステムじゃないと、開発の意味がない」という声が出てきました。

象徴的だったのが、各人がそれぞれログイン画面を作ってしまったことです。ツールを作ると、認証が要る、ログイン画面が要る、デプロイ先が要る。非エンジニアがバイブコーディングでそこまで作れること自体はすごいんですが、立ち上げるのがしんどいんですよね。URLを探して、ログインして、操作を思い出して。使うまでの工数が多すぎる。

これは作り手の問題ではなくて、環境の問題です。ツールがVercel、GitHub、Cursorの各所に散らばっていて、UIも操作もバラバラ。非エンジニアにとっては、一つひとつ探して立ち上げて使い方を思い出す、というだけでハードルになります。

つまり、ツールを増やすよりも先に、チーム全体のAIリテラシーを集中して鍛えるための「土台」が必要だったんです。

実験的に、Claude Codeへ一本化してみる

そこで、一度ゴリッと環境を変えてみることにしました。Claude Codeにすべてを一本化する。非エンジニア、マーケターのチーム全員で。

あくまで実験的にです。一旦変えてみて、どうなるのかを理解する。そのうえで判断していく。

ただ、確信に近いものはあります。去年の3月頃からいろいろなAIツールが出てきて片っ端から試してきた中で、私が一番革命的だと感じたのはClaude Codeでした。業務によっては5分の1、10分の1の速度になる。そういう手応えがあります。

一本化を決めた理由は3つあります。

理由①：一つに絞って、集中して鍛える

私たちはクライアントワークが主業務です。成果を出すことが第一にあるので、学習に割ける時間はそれほど多くありません。

その中で、あれもこれも使ってトライするのは相当ハードルが高い。新しいツールが出るたびに少しずつ触って、でもどれも中途半端なまま次が出てきて。その繰り返しになりかねません。

だったら、1つのツールに絞って、とことん使い倒したほうがいい。全員が同じツールを使えば、情報のシェアも進みます。「これどうやるの」と聞いたら、すぐに答えが返ってくる環境を作れる。チーム全体で知見を持ち寄って、一緒にリテラシーを高めていける。

PowerPointで素晴らしいデザインを作れる人は、Keynoteに移っても学べばできるようになります。それと同じで、まず一つのツールでAIを活用するベースを徹底的に鍛えておけば、その力は他のツールにも転用できると考えています。大事なのは、どのツールを使うかよりも、AIで業務を設計する力そのものを身につけることです。

実際に切り替えを決めたとき、チームメンバーにはこう伝えました。「今日と明日、通常業務を止めていい。全部止めていい環境を作るから、Claude Codeを触ることに集中してくれ」と。2日間、丸々使って学ぶ。そのくらい振り切って、一点集中で鍛えたほうがいいと判断しました。

Claude Codeの構成はシンプルです。claude.mdという設計書があって、コンテキストを呼び出して、ルールで制限をかける。スキルで機能を呼び出して使う。この構造さえ理解すれば、非エンジニアでも自分の業務に合わせた環境を構築できます。

覚えることが少ないぶん、深く使うことに集中できる。これが非エンジニア組織にとっては大きいと感じています。

理由②：UIを一つにまとめる

チーム全体で使う以上、UIが一つにまとまっていることは想像以上に重要でした。

先ほど触れたとおり、ツールがバラバラの場所にあって、UIも操作もまちまちだと、非エンジニアはそれだけで使わなくなります。これは意志の問題ではなく、構造の問題です。

Claude Codeなら、すべてが一つのインターフェースに集約されます。スラッシュコマンドで呼び出せば、即座にツールが立ち上がる。「/」と打つだけで一覧が出てくる。URLを探す必要もない、ログインもない、立ち上げもない。探す手間がゼロになります。

作る側にとっても変わります。「側（がわ）」を作らなくていい。見た目を作らなくていい、デプロイ先を考えなくていい、認証を作らなくていい。ツールの中身、つまりロジックだけに集中できるようになる。機能だけをSkillsとして定義すれば、それがそのまま全員に使える状態になります。

非エンジニアの私たちは作りたがりなので、つい側まで含めて作りまくっていました。でも本当に必要なのは、中身のロジックをチーム全体で共有できることのほうだったと気づきました。

理由③：自分たちの業務に最適化された仕組みを作れる

最後が、Claude Codeの拡張性です。

私たちの主業務はマーケティングの支援です。成果が求められ、人を対象とするコミュニケーションを考える仕事なので、非定型業務が大半を占めます。

世の中に汎用的なAIツールやテンプレートは大量にありますが、使うかって言ったら使いません。マーケティングの仕事は非定型業務の塊だからです。汎用的なものを持ってきてもそのままでは業務にフィットしない。

私たちがクライアントに成果を出すために必要なのは、自分たちの業務フロー、自分たちのデータ、自分たちの判断基準に最適化されたものです。

Claude Codeには、その最適化を実現するための仕組みがいくつも用意されています。定型ワークフローをスラッシュコマンドで呼び出せるSkills。複雑なタスクを専門エージェントに委任するSubagent。複数のエージェントを同時に動かして協調させるAgent Team。どんなプロンプトを書き、どんなコンテキストを渡し、どんなデータを参照させるのかを設計することで、自分たちの業務に合った仕組みを組み上げていける。

すでにチーム内では、業務の一部をSkillsとして定義し始めているメンバーがいます。一度作れば、チーム全員が同じ品質で業務を回せるようになる。複数の工程を並列で処理したいときはAgent Teamで同時に走らせる。やりたいことに応じて、組み方を変えられる柔軟さがある。

ここで重要なのが、これらの仕組みの「作り方のルール」をチームで共有することです。どういうコンテキストを持たせるか、どういう制限をかけるか、どういうデータを参照させるか。その設計思想が統一されていれば、誰が作ったものでも全員が迷わず使えます。

これは、ツールごとに作り方も使い方もバラバラだった時代には、できなかったことです。

まずはベースを鍛える

Claude Codeに一本化するという話は、ツール選定の話に見えるかもしれません。でも私たちにとっては、チーム全体のAIリテラシーをどう鍛えるかの話です。

個人がそれぞれ好きなツールで速くなるのと、チーム全員が同じ環境で共通言語を持って動けるのとでは、プロジェクト全体のスピードがまるで違います。全員が同じツールを使い、同じルールで動き、同じSkillsを共有している。その状態を作りたい。

まだ実験を始めたばかりなので、これからどうなるかはわかりません。ただ、一つのツールでAIを活用するベースをとことん鍛えておけば、その先の発展はいくらでもできると思っています。

まずは集中して、みんなで知見を持ち寄って、ベースを作る。そこからです。