Claude Code は、コードを書くAIエージェントとして知られています。エンジニアのツールという認識は、いまも大筋で正しいと思います。
ただ、この認識は少しずつ変わりはじめています。ビジネス職でも使えるという話が増え、非エンジニアの「使ってみた」記事もよく見かけるようになりました。中には没頭して、エンジニア顔負けに使い込む人もいます。
私たちも使っています。開発だけでなく、セールスもマーケも経営陣も、日常の道具として使っています。この記事を載せているサイトの運用も、顧客管理の設定も、Claude Code で回っています。
では、新規事業チームの道具として勧められるのか。使い込んだうえでの答えは二段になります。**個人の制作にははっきり勧められます。チームの常用には、体制が要ります。**この2つを分けて、順に書いていきます。
Claude Code は何をするものか
Claude Code は、Anthropic社のAIエージェント（指示を受けて、複数の手順を自分で進めるAI）です。ターミナル（文字で命令を打ち込む操作画面）で動き、フォルダの中のファイルを読み、作業を進め、結果をファイルに残します。
扱えるのはプログラムのコードだけではありません。文章でも、画像でも、データでも、フォルダに置けるものなら同じように読み書きします。MCP（AIエージェントと外部アプリをつなぐ共通規格）を使えば、Slack や Notion、Figma のような外部のアプリケーションにもつながります。
つまり「コードを書く道具」という紹介は半分だけ正しくて、実体は、手元のファイルと外部アプリを行き来しながら作業を進める実行環境です。コードが書けなくても使い道はあります。ここが、認識が変わりはじめた理由だと思います。
個人の制作には、はっきり勧められる
勧められる側から書きます。効くのは制作です。
ウェブサイトを作る。プロトタイプを作る。Canva や Figma、Google スライドにつないで資料を作る。作りたいものを日本語で伝えれば形になって返ってくるので、エンジニアリングの知識はそれほど要りません。新規事業の検証で使う LP やモックアップ、顧客に見せる説明資料あたりは、そのまま守備範囲です。
私たちの場合も、営業資料の下書きやイベントの告知まわりは、担当が自分の Claude Code で作っています。作る、直す、また作るの回転が速いので、検証の初速がほしい新規事業とは相性のよい使い方だと思います。
ターミナルに抵抗があるなら、入口はほかにもあります。Claude Desktop や Claude Code のWeb版なら見た目は普通のアプリで、難しさをほとんど感じさせません。個人で使う分には、この道で十分です。
類似のツールには Codex や OpenCode などの選択肢もあります。好みの差はあると思いますが、私たちが試した範囲では、いまのところ Claude Code がいちばん勧めやすいです。
チームの常用には、体制が要る
問題は、これをチームの共有インフラにしようとしたときです。私たちが実際に越えてきたハードルを順に並べます。
まず、全員が git を理解する必要があります。git はファイルの変更履歴と合意を管理する仕組みで、エンジニアには空気のような前提ですが、初めての人には概念の学習からになります。決して低くない学習コストです。
次に、データのモデリングです。チームで情報を共有するには、顧客・案件・商談のような「扱う対象をどう分け、どう関係づけるか」を設計しないと、フォルダはすぐに崩れます。この設計はデータモデリングと呼ばれ、対象の意味や関係の定義まで含めてオントロジーと呼ばれることもあります。私たちには顧客管理システムを自前設計して Claude Code から運用していた時期がありますが、ここはかなりエンジニアリングの脳みそを必要としました。向き不向きがはっきり出ます。
さらに、権限管理の知識と、ある程度のマシンスペックも要ります。そして機密の扱いです。Claude Code 自体には、ファイル単位でアクセス権を分ける仕組みがありません。フォルダが見える人には中身も見えるので、機密を扱う新規事業では、置けるファイルを選ぶ必要があります。使える場面は多くても、範囲は限定的になります。
効き目を体感で測れない、という事情もあります。研究機関のMETRが2025年に公開したランダム化比較試験では、自分のプロジェクトを熟知した開発者がAIツールを使うと、タスクの完了はむしろ19%遅くなりました。本人たちは「20%速くなった」と感じていたそうです（METR、2025年）。効く条件と効かない条件は入り組んでいて、「速くなった気がする」だけでは導入の判断材料になりません。
整理すると、エンジニアだけの集団なら迷わず勧めます。エンジニアの割合が低い組織には、常用インフラとしてはあまり勧められません。チームで使うなら、オペレーションを設計するエンジニアを入れることが実質的な前提条件だと考えています。
「SaaS is Dead」とは、まだ距離がある
Claude Code のようなエージェントが広がると、業務アプリはどうなるのか。この文脈でよく引かれるのが「SaaS is Dead」という言説です。マイクロソフトのサティア・ナデラCEOが2024年末のポッドキャストで、業務アプリケーションの多くはデータベースに業務ロジックを載せたものであり、そのロジックがAIエージェント側へ移ることで、業務アプリという概念はエージェント時代に崩壊していくだろうと語りました（BG2 Pod、2024年12月）。AIで自分たちのアプリやUIを作れるようになる、という話もこの延長線上にあります。
方向としては分かります。ただ、実運用の実感を正直に書くと、Claude Code を使って自分たちのアプリを作るのが楽になった、という感覚は全然ありません。私たちにできているのは、さまざまなアプリケーションと MCP でつなぎ、ファイルシステムを使って各自が作業する、というところまでです。
それでも SaaS は解約していない
実際、私たちは相当なハードユースの部類だと思いますが、Slack も Notion も顧客管理も会計ソフトも、SaaS を使い続けています。
理由ははっきりしています。SaaS が提供しているのは機能だけではなく、練り込まれたデータ構造とワークフロー、そしてそれをメンテナンスし続けてくれる保証（SLA）だからです。これらを自前で保証し続けるコストを払うのは、もったいないというのが私たちの判断です。
逆に、データ構造もワークフローも単純で、自前で維持しても頭を使わないものは、ほぼ解約しました。AI系のSaaSもいくつか使っていましたが、「AIのスキルが詰まっている」「これで楽になれる」というレベルのものは、SaaSである必要がほとんどありませんでした。守るべき固有のデータ構造やワークフローを持っていないからです。
いまの形はこうです。データ構造とワークフローのメンテナンスが難しいものは SaaS に任せ、Claude Code からは CLI や MCP でつないで活用する。構造が単純なものはファイルに寄せて、Claude Code で直接扱う。当社のサービス Vividir も MCP に対応しているので、Claude Code からつないで使うこともしています。
判断の目安
タイトルの問いに戻ります。新規事業チームで Claude Code は使えるのか。
個人の制作には使えます。ウェブサイトも、プロトタイプも、資料も、今日から作れますし、Claude Desktop や Web版から入れば敷居もほとんどありません。ここは素直に勧めます。
チームの常用は、結構大変です。git、データモデリング、権限、機密。どれも解けない問題ではありませんが、オペレーションを設計するエンジニアがいて初めて回ります。私たちも数ヶ月かけて整え、いまも直し続けています。
そして、どちらの道を選ぶにしても、道具より先に要るものがあります。チームの判断基準の言語化です。AIは書かれた基準しか参照できないので、基準が言葉になっていなければ、どの道具を選んでも同じ壁に当たります。基準の言語化そのものはAI時代の新規事業に必要不可欠な「ポリシー」とはなにかに整理しています。
道具を入れずに小さく体験するなら、ハンドブックの基礎編のテストが入口になります。基礎編の本文をAIチャットに読ませて出題者にする仕掛けで、「書かれた文書をAIに読ませて動かす」がどういうことかを、導入なしで確かめられます。