Claude Codeで、会社の業務をこう回している｜マーケ・営業・開発を”一つの仕組み”で

少人数で会社を回そうとすると、たいてい各領域の”できる人”に依存します。数字を読める人、商談を設計できる人、システムを直せる人——その誰かが詰まると、そこで全体が止まる。私たち自身、長らくそうでした。いまは違います。Claude Codeを相棒にして、マーケティングも、営業も、開発・社内システムも、同じ運用モデルで回している。この記事は、その全体像——当社が業務全体を実際にどう組み立てているか——を、順を追ってお見せするものです。

先にひとつだけ。ここに書くのはきれいに整った”設計図”です。実際には転んだり、AIに嘘をつかれたり、本番を壊しかけたりもしました。その正直な舞台裏は 実録①（失敗と学びの全記録） にまとめてあります。本稿で全体像をつかんでから読むと、なぜこの形に落ち着いたのかが腹落ちするはずです。

マーケも営業も開発も、”才能”で回すのをやめて、”仕組み”で回す。鍵は、どの業務にも同じ運用モデル——人・AI・コードの分担——を当てはめることです。

全体像：どの業務も、同じ”3つの分担”で回る

いちばん大事なのは、最初の線引きです。AIに何もかも任せるのでも、人が全部抱えるのでもない。役割を三つに分ける。この分担が、マーケでも営業でも開発でも、驚くほど共通しています。

コードが、決定的な処理を受け持つ。集計・整形・データの受け渡し——「毎回まったく同じ答えが出るべき処理」は、AIの気分に委ねず、コードに固定します。ここをAIに任せると、同じ依頼でも月ごとに数字がわずかに揺れ、先月と今月を比べられなくなる。だから”揺れてはいけない処理”はコードで固める。AIが、判断の”下ごしらえ”を受け持つ。膨大な情報から要点を拾い、所見や下書き、叩き台をつくる——人がゼロから始めると重い作業を、AIが8割まで持っていきます。ゼロから1がいちばん時間を食うので、そこをAIに肩代わりさせる。そして人が、方針と最終判断を受け持つ。何を狙い、どこに賭けるか。そして「これを世に出してよいか／本番に反映してよいか」の最後のボタン。ここだけは、人が握り続けます。

なぜ、この線引きが業務を選ばないのか。どの仕事も、突き詰めれば「決まった処理」と「判断の下ごしらえ」と「最終判断」の組み合わせでできているからです。マーケの分析も、営業の商談準備も、開発の定型作業も、構造は同じ。だから一度この分担を体で覚えると、隣の領域にそのまま持っていける。そして効いてくるのが、速くなるほど”判断”が主役になるという逆説です。手を動かす時間が9割から1割に減ると、空いた時間は「どこを攻めるか」「これはやらない」という判断に回る。AIは判断を速くする道具であって、判断を代わりにする道具ではない——この一点さえ外さなければ、同じモデルを業務のどこにでも横展開できます。以降、この分担がマーケ・営業・開発それぞれでどう具体化するかを見ていきます。

マーケティング：分析から実装まで、一本で通す

いちばん作り込んでいるのがマーケ運用です。ここでの狙いは、「分析して終わり」をなくすこと。多くの現場では、分析レポートは作られるのに、それが施策や実装につながらず、次の月にはまた同じ分析をゼロからやり直す——という”分断”が起きています。私たちは、診断・施策案・本番への反映までを一本の流れにして、この分断を消しました。

流れの要点は三つです。まずデータの取り方を”型”に固定する。検索の実績・サイトの行動・広告の数字を、その都度でなく決まった手順（スキル）で取り、誰が回しても、いつ回しても同じ土台がそろうようにする。「その数字、取り方が違うのでは？」で議論が止まらなくなるだけで、後工程の速さがまるで変わります。次に分析を型で回す。ここがいちばん事故が起きやすい。「表示が増えた」と合計を見て安心すると、実は自社と関係の薄いワードで数字だけ膨らんでいた、という罠にはまります（この実話は 実録① に）。だから合計でなく内訳を開き、競合と交差させ、判断の基準をコード化する。そして実装まで通す——見つけた弱点を記事やページの改善案に落とし、本番には”下書き”として投入して、公開の最終ボタンは人が押す。投入後は、図が消えていないか・要素の数は合っているかを機械で往復チェックする。「速く出す」と「壊さない」を両立させる関門を、工程に組み込んでおきます。

この一連は、シリーズで工程ごとに深掘りしています。分析の型は 広告をLTV基準で回す や 顧客をRFMで分ける、上流の設計は 提案・要件定義の生成、広告運用の自動化は 広告運用×MCP に。

営業：顧客データと商談準備を、AIで整える

同じモデルは、営業まわりにもそのまま効きます。営業の”重さ”の多くは、実は商談そのものより準備にあります。「この会社と過去に何を話したか」を思い出し、名刺や履歴を掘り起こし、提案の下ごしらえをする——この準備が、担当者の頭の中に属人的に溜まっているのが、いちばんの弱点です。担当が変わると、関係がゼロからになる。

ここが、まさにAIの下ごしらえが活きる領域です。名刺や商談の記録をMCPでつなげば、「この会社との過去のやり取り」をAIが即座に束ねて、論点の整理から次の提案の叩き台までを持ってくる。人は、関係構築と意思決定という”人にしかできない部分”に集中できます。ここでも分担は同じ——顧客データの整形はコード、履歴の要約と提案の叩き台はAI、そして「何を提案し、いくらで出すか」の判断は人。名刺・営業データの活用は Sansan×MCP・AIエージェント に、顧客管理基盤そのものの設計（使い分けと連携）は Salesforceとkintone にまとめました。

その延長にあるのがバックオフィスです。会計や記帳のような定型作業も、公式のMCPを通せば、AIが下ごしらえをして人が承認する、という同じ型で回せます。ただし、お金と顧客データに直接触れる領域だけに、権限と承認の設計が要になる。「どこまでAIに見せ、どの操作に人の承認を挟むか」を先に決めないまま繋ぐと、便利さと引き換えに事故の芽を抱えます。この勘所は freee・マネーフォワードの記帳自動化（AIへ渡す情報の設計） に。

開発・社内システム：MCPで社内をつなぎ、定型を自動化する

そして、これらすべての土台になるのが開発・社内システムの領域です。ここでのClaude Codeの役割は、単なるコード生成ではありません。社内の各システムをMCPでつなぎ、”AIが安全に触れる入口”を用意すること。ここが整うと、上のマーケ・営業の自動化が一気に現実味を帯びます。逆に言えば、この土台がないままだと、AI活用は「個人が手元で試す」段階から先に進みません。何を、どういう権限で、どうつなぐかは 社内システムのMCP化ガイド に。

土台ができたら、開発・運用の定型作業を型に落とします。課題の起票や進捗の通知は Backlog自動化 や Slack自動化 で、コードの検証・反映の流れは CI/CDへの組み込み で。ここでも分担は変わりません——検証や反映という”毎回同じであるべき処理”はコードとルールに固め、起票文や通知の下書きはAIが用意し、リリースの最終判断は人が握る。開発領域は「決定的処理はコード」の比重がいちばん高く、AIはあくまで人の手前の下ごしらえに徹する、というバランスになります。

横串で効く、三つの原則

三つの業務を別々に見てきましたが、うまく回るチームは、領域をまたいで共通する”三つの原則”を先に組んでいます。これがあるから、業務を横に広げても品質が落ちません。

第一に、データや手順を”型”に固定する。その都度の思いつきでなく、決まった手順を部品にしておくから、再現性が出る。人が変わっても、同じ品質で回る。第二に、判断をログに残して”次の起点”にする。施策を打つ時に「なぜそう決めたか」を結果とセットで残すと、半年後に「あの判断は本当に効いたのか」に、今の数字で答えられます。効いた型は再利用し、効かなかった型は畳む。運用が”やりっぱなし”でなく、回すほど賢くなるものに変わる——これが、この設計のいちばんの果実です。第三に、繰り返しを”スキル”に部品化して共有する。よく使う手順を入力・処理・出力・確認まで定義し、CLAUDE.md（運用の方針書）で全体の前提——トーン・禁止事項・データの置き場所——をそろえ、GitHubでチーム共有する。成果でなく”手順”を資産にするから、「あの人しかできない」が仕組みで解けます。この部品化の実際は スキル部品化＋GitHub共有、定例業務の仕組み化は 定例レポートの自動化 に。

安全設計は、業務を広げるほど効いてくる

マーケ・営業・開発と、AIにつなぐ範囲が広がるほど、鍵とデータの扱いが全体の安全性を左右します。ここを設計せずに広げると、速さを得た分だけリスクも増える。とくにAIは、外から取ってきた文章に紛れた”命令”に反応してしまうことがあり、権限を広く渡しているほど被害が大きくなります。芯はシンプルで、渡す権限を絞り、後戻りできない操作に人の承認を挟み、そもそも持ち出せない状態にし、外に出す前に機械でチェックする——この型を、業務を広げる”前”に組んでおきます。認証・データ連携のセキュリティ設計は こちら に、組織としての統制（サンドボックス・権限・監査）は Claude Codeセキュリティ運用 にまとめています。速く回すほど、この土台が効いてきます。

どこから始めるか ― 一気に全部はやらない

「マーケも営業も開発も」と聞くと、大がかりに見えるかもしれません。でも、始め方はいたって小さくてよく、むしろ一気に全部やろうとすると、たいてい頓挫します。動く前に、完璧な全体設計を描くことに力を使い果たしてしまうからです。私たちがおすすめするのは、次の順番です。

まず、いちばん頻度の高い”繰り返し作業”を、一つだけ選ぶ。毎週の順位チェックでも、月次のレポートでも、商談前の情報整理でもいい。それを、取得から出力まで通しで一度スキルにする。ここで「今まで手でやっていた作業が、まるごと消える」実感が得られると、次の一歩がぐっと軽くなります。最初の一つは、成果の大きさより“毎回やっていて面倒なもの”を選ぶのがコツです。次に、そのスキルの”型”を、隣の作業に応用する。同じ取得の仕組みを別のレポートに、同じ分析の型を別の商材に——ゼロから作らず、できた型を横にずらしていく。そして最後に、領域をまたいで広げる。マーケで作った「取得→下ごしらえ→人が判断」の型を、営業の商談準備や、開発の定型作業へ持っていく。分担の構造が同じだから、思ったより素直に移ります。

小さく作って、効果を確かめて、横に伸ばす。この順番なら、無理なく、しかし確実に、”仕組みで回る”状態に近づけます。大切なのは、壮大な計画を立てることではなく、まず一つ、実際に回してみること。一つ回れば、次に何を型にすべきかは、自然と見えてきます。

——ただし、この設計図は”失敗のあと”にできた

ここまで整った設計図を描いてきましたが、現実はこの通り一直線ではありませんでした。表示が増えて喜んだ翌日にがっかりし、AIに競合情報を堂々と捏造され、本番の図をぐちゃぐちゃに壊し、大量のファイルを消しかけた日もあります。この運用モデルは、そうした失敗の”あと”にたどり着いた形です。だから、きれいごとに見える一つひとつ——「本番は下書き止まり」「判断はログに残す」「権限は絞る」——に、地味で切実な理由があります。その舞台裏——何を間違え、どう気づき、どう直したか——は、実録① に隠さず書きました。全体像（この記事）と正直な実録（①）を合わせて読むと、”仕組みで回す”の解像度が上がるはずです。

まとめ：才能でなく、仕組みで回す

Claude Codeを相棒にした業務運用の芯は、派手なAI活用ではありません。コードに決定的処理を、AIに判断の下ごしらえを、人に方針と最終判断を——役割を分けて、この同じモデルをマーケ・営業・開発に横展開する。そしてデータの取り方を型に固定し、判断をログに残し、繰り返しをスキルに部品化する。こうして”できる人頼み”から抜け出すと、少人数でも業務が回り、速くなった分だけ、人は”判断”に集中できるようになります。「うちの業務も、この形に組み替えたい」という段階からのご相談も歓迎です。全体設計から、各領域の仕組み化、スキルの定着、安全設計まで、匿名前提でお手伝いします。

よくある質問