Claude Codeの活用事例

商業保険の仲介は紙の作業が多く手順も遅いままだった。

創業者はエンジニアではなく、仕組みを1人で作る必要があった。

1. AWSのコンソール画面のスクリーンショットをChatGPTに渡した
2. ChatGPTに聞きながらバックエンドとデータベースを立てた
3. CursorやClaude CodeやCodexで開発を進める
4. コーディングエージェントが扱いやすいWeaviateに決めた
5. 保険の書類を分類し項目を取り出してベクトル化する

2025年2月のアイデアから同じ年の11月には顧客のいる本番システムが動いた。

稼働から1年たたずに40口座で2,000万ドルの保険料を運用し、年間50万ドルを超える顧客も8件ある。

客が増えるにつれ書類を扱う手作業が積み上がっていた。

問い合わせの量も増え文書の仕分けや翻訳や下書きに時間を取られて対応が詰まっていた。

1. AWS Bedrock経由でClaudeを社内15以上のアプリへ組み込んだ。
2. 客向けの案内役が5言語で24時間いつでも答える。
3. 毎日数千件の会話を要約して傾向をまとめる。
4. チャージバックでは資料を訳し判断の案まで出す。
5. 紙の申立書を種類ごとに分けて担当チームへ回す。

対象にした業務で最大70%が自動で回るようになり手作業は最大50%減った。

新しい仕組みは着想から最初の評価まで1〜2週間で立ち上がる。

社員が知りたいことを聞くたびに専用のダッシュボードを作る必要があった。

技術の分からない人はデータへ自分でたどり着けなかった。

1. Claudeを複数の専門エージェントの司令塔に据えた
2. 社員の質問からClaudeが動かすエージェントを決める
3. 計算と商品マスタと地域マスタを別々のエージェントに任せた
4. Claudeが各エージェントの結果をまとめ答えと図にする
5. 利用者の権限を確かめながら社内データ基盤へ問い合わせる

会話で聞ける分析の正答率が90%から99%へ上がった。

社内のAI基盤は1日15,000人・月44,000人が使い月250万件のメッセージが行き来している。

APIを作った後のテストや文書や仕様の更新がばらばらの手作業で残り、変更のたびに中身がずれていた。

自社の調べでは開発者の69%がAPI関連の作業に週10時間を超えて使っていた。

1. 開発とコーディングの課題で複数のモデルを比べた
2. Agent Modeの既定にClaude Opus 4.6を選ぶ
3. Amazon Bedrock経由で数時間でつないだ
4. コレクションやテストやGit履歴を読ませる
5. エンドポイント指定でテスト作成と仕様更新まで任せる

自社の見積もりでは開発者1人あたり年間で最大1,150時間を削れる。

10人のチームなら年間で100万ドル近い費用の削減にあたる。

技術者ごとに好みの開発環境が違うため6種類のコーディング支援を用意したが、社外のパッケージを各自で入れる形は供給網を狙った攻撃の危険があり配布に踏み切れなかった。

1. Anthropicと組み署名済みの法人向けバイナリを作る。
2. 2〜3か月かけて検証と手直しを重ねた。
3. 全員のノートPCと開発機にあらかじめ入れておく。
4. ルールとトークンと認証まで設定済みにした。
5. AIを社内を知らない優秀な新人として扱うよう伝える。

あるチームが10,000行のScalaコードを4日でJavaへ書き換えた。

手作業なら10人週かかると見ていた仕事で、新しいJDKへ移れて性能の改善も進んだ。

1.7兆ドルの資産を運用するため毎日大量の調査資料や市場データや規制文書を読み込む必要があった。

投資分析に耐える精度がありながら技術に詳しくない担当者でも扱えるAIが見つからず9,000社分のESG分析も負担になっていた。

1. 複数のLLMを人が採点する形で比べた
2. 拡張思考を使うClaude Sonnet 4.5を選んだ
3. 2週間の試験導入から始め役割ごとの研修を用意した
4. 50人をAIアンバサダーに育て使い方を社内で共有させた
5. 分析担当にClaude Codeを渡し小さな道具を作らせた

社内調査ではAIを使う業務で週の時間の20%以上が浮いた。

2か月で600人以上が日常的に使う状態になり運用や法令対応の部門でも文書作成が自動化された。

手を動かす作業が多く時間が足りなかった。

数千のサービスが絡むコードの把握に時間がかかり、顧客担当は個別の案内を主要な顧客にしか作れなかった。

1. Claude CodeをMCPで社内のサービスや仕組みにつなぐ
2. 移行や修正の作業をClaude Codeに任せる
3. 実際の業務の課題で比較テストし手直しが少ないものを選ぶ
4. プロジェクト機能に前提の情報と指示をためて記事や案内を作らせる
5. 出てきたものは担当者が確かめて直す

マーケティングはWeb制作とコンテンツ作りで最大40%の生産性向上になった。

複雑な技術の切り分けは3〜5日から1時間未満に縮み、新しく入った人も早く本番へコードを出せるようになった。

新しい薬ごとに数百ページの文書が要り、治験の総括報告書は執筆と修正と承認に何か月もかかっていた。

外部の会社に頼んでも追いつかず、書き手1人が年に2.3本しか仕上げられなかった。

1. 文書づくりの基盤をClaude Codeで開発した
2. Amazon BedrockとMongoDB Atlasの上にRAGを組んだ
3. 承認された文章と案件ごとの変数を合わせて文書を作る
4. まず総括報告書に絞って精度を詰めた
5. 出来た文書は人がレビューして承認する

総括報告書の執筆時間が90%減り、数か月かかっていた冊子や患者向けの案内は1分以内で作れるようになった。

規制当局からも良い評価が返ってきている。

支払いが失敗した理由を1件調べるだけでも、カードの状態や口座情報や残高や取引を順に確かめる必要があった。

欧州2000万人の利用者を従来の窓口ではさばききれず、後続の自動処理に渡すJSONが一つ崩れるだけで流れが止まる状態だった。

1. 複数のモデルをA/Bテストで比べてClaudeを選んだ
2. 社内のLLMルーターに載せ数日で組み込んだ
3. 支払い失敗や異議申し立ての確認順をClaudeに決めさせた
4. 領収書などの書類を画像認識で読み取り本人確認も自動で通した
5. 後続の処理に渡す構造化データもClaudeに作らせた

自動で解決できる問い合わせの割合が8%上がり、全体の8割超に届いた。

新しく入った開発者が使えるコードを出すまでの時間は40時間から16時間になり、口座開設も5分で終わるようになった。

Spotifyは数千のリポジトリを抱え言語やフレームワークの更新が絶えず発生していた。

従来の自動化はASTや正規表現でスクリプトを書く必要があり意味を読み取る複雑な移行は手作業のまま残っていた。

1. 社内のFleet ManagementにClaude Agent SDKを組み込んだ
2. 大きな移行では指示文をGitで管理した
3. 複数のリポジトリへ一斉に実行させた
4. 個別の作業は社内のSlackボットから呼び出した
5. PR前に整形とlintとビルドとテストを自分で回させた

数百人の技術者が使い月650件を超えるプルリクエストが本番にマージされている。

手作業で移行を書いていたときと比べ最大90%の時間が浮いた。

Shopifyで売上データを深く見るにはShopifyQLを覚える必要があった。

店を始めたばかりの人ほどそこで止まり数字をもとにした判断へ進めなかった。

1. 商売の相談役になるSidekickをClaudeで組み立てる
2. 管理画面から話しかけられるようにする
3. 話し言葉の質問をShopifyQLのクエリへ置き換える
4. 1回のやりとりで複数のツールを順番にも並列にも呼び出す
5. Claude Sonnet 4.5をGoogle Cloud上で動かす

以前は技術の知識が要った分析が会話だけでできるようになった。

新しく始めた事業者が最初の売上に届くまでが数週間から数日へ縮まった。

ドキュメント作成やテスト、レビューといった繰り返しの作業に開発者の時間が取られていた。

慣れない部分のコードに触れるまで数週間かかり、レビュー待ちの滞りも起きていた。

1. まず30人のエンジニアで試し開発チーム全体に広げた
2. 共通のプロンプトやコマンドを社内リポジトリに置いた
3. 各自が初期設定で取り込み文書作成やテストに使う
4. CIではヘッドレスで動かしPRを自動で作らせる
5. 出てきた変更はエンジニアが確認して直す

慣れない領域でも数週間でなく数日で手を動かせるようになった。

見た目の回帰テストの基盤は数時間で移行を終え、プルリクエストのレビューも待ち時間なく返ってくるようになった。

ほぼ1日おきに新機能を出す開発の速さが持ち味だが コードとテストの往復や障害時の情報集めに手間がかかっていた。

1. Claude Codeをターミナルから呼び出しテストとつないだ
2. コード作成とテスト修正の繰り返しを自動で回す
3. コードベース全体の説明書きも自動で作らせた
4. 1つのコードベースで複数セッションを同時に走らせる
5. DatadogやSentryとつなぎ障害の情報を集めた

30日で100万行を超えるAI提案のコードを取り込み 開発者のおよそ50%が毎週使うようになった。

障害の初動調査にかかる時間は最大80%減ると見込まれている。

個人開発のプロジェクトが4〜5件同時に走り、実装よりも「今週どれを進めるか」を決める時間が膨らんでいた。

判断が溜まり続けて、放置される案件も出ていた。

1. オーナーは自分だと伝え役割別エージェント作成をClaude Codeに依頼する
2. 返ってきた質問に答えて自律の範囲とモデル配分を決める
3. 承認をDiscordとPCの両方から行えるか確認し計画を一度差し戻す
4. 9役割を定義し自動可と承認要の一覧表をCLAUDE.mdへ固定する
5. 決裁は1件1枚のMarkdownカードにしてディレクトリ移動で状態を表す

サブエージェント9体とスラッシュコマンド、初回会議の成果物まで含む骨組みが59ファイルの1コミットで立ち上がった。

スラッシュコマンドは最終的に7個になり、今はこの仕組みの下で大小10個前後の事業が動いていて、決裁待ちはコマンド1つで一覧できるようになった。

買い替えたSnapdragon X2 Elite搭載のWindowsノートPCでローカルLLMを動かしたかったが、どの実行経路とモデルが使えるかを一つずつ試すのは手間が大きかった。

1. Claude CodeをPCに入れる
2. NPUでLLMを動かす経路の調査とベンチマークをAIに任せる
3. 1モデル1プロセスで温度やseedを同じにそろえて計測する
4. 短文タスクと論文全文の査読メモ作成を走らせる
5. 速度とロード時間とRAM増加量を記録し翻訳品質は自分で確認する

NPUを全層使うqairt経路ではQwen3 4B Instruct 2507が37.1tok/sで動き、英→日1,229字の翻訳が10.4秒で終わった。

コンテキスト長4096固定という制限はあるが、翻訳や要約なら実用になると分かった。

ブログ記事の執筆やSNS投稿、転載の配信といった毎日発生する定型作業が多く、一人では量をさばききれなかった。

AIに任せても完了報告が正しいか分からず、外部への配信が止まる事故も起きていた。

1. CLAUDE.mdに破ってはいけない線を6項目だけ書く
2. main直pushの禁止と秘密情報の置き場所を明記する
3. WordPressは人がGOを出すまで下書き止まりにする
4. 品質チェックの配点や仮説の観点をSkillに固定する
5. 完了報告はgit statusとdiffの実出力を貼らせ再実行で照合する

約1か月の運用でマージしたPRは254本、書き上げた原稿は110本に達した。

Skillは10個、GitHub Actionsのワークフローは15本まで増え、外に出たものはすべて本人がGOを出したものだけで秘密情報の漏れは起きなかった。

夫婦生活費と子ども費とその他という独自の3分類が必要で、既存の家計簿アプリのカテゴリでは合わなかった。

そのため買ったものを一つずつレシートから拾って電卓で足す手作業が家庭内で続いていた。

1. 仕様の原典になる文書の構成をAIと決める
2. 作りたいものを音声入力で話し質問に答える
3. 文書間の食い違い10件を検証役が直す
4. データモデルと分類ルールと認証の3節を読み保留4件を決める
5. テスト駆動で4回に分けて実装させる

自分が手を動かした時間は2〜3時間で、コードは1行も書かなかった。

AIが書いたテストは330本で、テストを通ったあとに見つかったバグは1件だった。

家庭内の電卓での集計もなくなった。

Claude Codeが使うトークンの約9割が、込み入った推論ではなくファイルの読み込みや定型コードの出力に消えていた。

高価なモデルに単純作業まで任せる状態が続いていた。

1. 読む担当bulk-readerと書く担当code-writerの2モードを作る
2. 作業用モデルにGemini 2.5 Flashを割り当てる
3. bulk-readerで大きなファイルを読み要約だけをClaudeへ返す
4. code-writerは参考ファイル指定を必須にしひな型を出力させる
5. shuntのPreToolUseフックで350行超の読み込みを止める

Javaのモノレポで4種類の場面を試したところ、bulk-readerを通したケースでClaude側のトークン消費が平均で約90%減った。

一方で軽量モデルはスレッドセーフティーに関わる問題を見落とすことがあった。

2人で予定を共有するために自作したカレンダーアプリに写真アルバムを足したかったが、既存の予定データを壊す不安があった。

着手前に本番のFirestoreルールを見ると誰でも読み書きできる状態だった。

1. Claude Codeに「既存データは壊さず追加のみ」と条件を渡す
2. Firebase MCPで本番ルールを取り出し差分を確認して書き換えた
3. メール確認済み判定をUID判定へ人が切り替えた
4. エミュレータでテスト後にデプロイし本番と一致を確認した
5. CORSが必要という説明は実測させて誤りを訂正させた

実働は約6時間40分で23commits、55ファイル、+5,303/−416行まで進んだ。

セキュリティルールのテスト28件とCloud Functions12個を用意し、写真・動画のアルバムやLINE共有まで動かせた。

コード量を54%減らせるとうたうプラグインの数字が、自分の環境でも同じように出るか分からなかった。

モデルごとの向き不向きも判断できなかった。

1. Express製55行のTODO APIに日本語4行のチケットを7本用意する
2. headlessのclaude -pにチケットを渡し実行する
3. --plugin-dirで足す条件と足さない条件を作る
4. Haiku・Sonnet・Opusの3モデルで合計42セルを回す
5. 差分を同じprettier設定で整形し直してから数え直す

削減率は9〜25%にとどまり、54%は再現しなかった。

コストが下がったのはOpusだけで、Haikuは1件テストを落とした。

自作のタスク管理CLIのバグ修正をClaude Codeに任せていたが、1件直すたびに新しいバグ報告が生まれる感覚が続いた。

AIが自分の仕事を残すためにIssueを作っているのではないかと疑った。

1. 引数処理のバグのIssueを5パートに分けて順に修正させる
2. レビュー時に同じ構造が他に無いか横断で調べさせる
3. 見つかった箇所を新しいIssueとして起票させる
4. 1日分の起票数とクローズ数を手で数え8日分に広げる
5. nextの箱に積むかは人が決める運用に固定する

テストは1,747件から1,914件に増えた。

8日間の収支は起票7件・クローズ14件で、somedayの箱は77件から71件に減り、増加傾向には転じなかった。

原因はAIではなく網羅を求める指示の書き方だと分かった。

定期で走るはずの処理が3日間止まっていたのに誰も気づかなかった。

エラーが出ないまま止まるので、毎日見ていても異常が異常として現れなかった。

1. Claude Codeのセッションを役割で分け統括の下に実作業を並べた
2. セッション間はinbox配下のマークダウンで連絡し人間は統括だけに話す
3. 点検用のルールベーススクリプトを朝夜に走らせた
4. 閉じ忘れや返事なしなどを数え3段で判定しJSONLに残した
5. 定期ジョブが消えるためスケジューラをOS側のlaunchdへ出した

77日の運用で自動巡回は120回走り、異常なしで終わったのは9回（7.5%）だった。

検出311件のうち例外を投げたものは1件だけで、その1件も巡回スクリプト自身の通信エラーだった。

実装が終わった後に別モデルへレビューさせる流れが一般的だが、手戻りが大きいのはコードの欠陥より計画の欠陥だった。

サブゴールの切り方や依存関係の矛盾は、下流でいくら磨いても直らない。

1. 計画立案とコードレビューをClaude Codeに固定する
2. 計画の穴探しと実装をCodex側に固定する
3. 起動時にインタビューでゴールと非ゴールと受入条件を文書化する
4. JSON Schemaに沿ったverdictで計画を検証し最大3回まわす
5. 検証は読み取り専用にしてコミットは人間が行う

品質のチェックを実装後ではなく計画段階に移し、重大な指摘がゼロになってから実装へ進む流れになった。

判定の根拠がファイルに構造化されて残るため、後から見返すこともできるようになった。

詰まったところだけ質問する使い方では判断を全部自分が抱えることになり、開発の速さは1.3倍ほどで止まっていた。

ファイル編集のたびに許可を求められて作業が数分おきに止まっていた。

1. 最初にAIへ権限の表を渡した
2. 機能の順番を決める設計だけ人が確認する形にした
3. ファイル編集やマイグレーション、gitコミットは確認なしで進めさせた
4. 外部サービスへの実アクセスは目的を一言伝えさせPCやお金の操作は対象外にした
5. 報告は1時間に1回にまとめ変更ファイル名と設計理由を残させた

社内の顧客管理システムを約6週間で作り、PHPファイル74本、約3,500行のコードはほぼ全てClaude Codeが書いた。

開発に使う時間は1日15〜30分になった。

アプリ開発は素人で、Androidのカメラアプリを一人で作り切る時間も経験も足りなかった。

チャットで相談する形だと実機での動作確認まで手が回らなかった。

1. エージェント型のClaude CodeとCodexを併用しQwenも追加した
2. AGENTS.mdに全AI共通のルールを置き実測か未検証を明示させた
3. 実機投入時はAPKと端末のSHA-256一致まで確認させた
4. hookでadb uninstall等の危険なコマンドを機械的に止めた
5. 課題は自己完結HTMLのWBSで管理し実機5台で目視確認した

2026年7月23日から約50日でGoogle Playのクローズドテストまで到達した。

API従量課金なら約60万円分に当たる使用量を、月額プランの枠内で実費約1.5万円に収めた。

1人で回すWeb制作会社では、顧客管理や請求まわりの社内システムを自力で作る時間が足りなかった。

店舗向けサイトの雛形づくりにも手が回らなかった。

1. Claude Codeを開発担当の社員のように位置づける
2. 作るものの設計を先に固めて合意してからコードを書かせる
3. 指示の粒度を調整しLaravel12のモジュール構成に沿わせる
4. Stripe Cashierなど詰まりやすい箇所は自分で確認して直す
5. 完成したものをさくらのレンタルサーバーに載せて運用する

顧客管理とStripe請求、Instagram連携を持つ社内CMSと、予約や会員機能とLINE連携を備えた店舗サイトの雛形を作り上げた。

制作の過程は約57,889字の記録としてまとめた。

ProプランでClaudeとClaude Codeを毎日使っていたが、5時間や1週間ごとの上限に当たって作業が止まる場面が増えていた。

1. CLAUDE.mdとrulesを必要最小限に削る
2. そのプロジェクトに要るskillsやmcpだけ読み込ませる
3. 対象ファイルのパスと参照元を先に渡し変更後の姿まで書く
4. 単純な調査はサブエージェントに任せ判断を本体に残さない
5. 話題が変わったら新セッションに移り区切りで/compactする

人が既に知っている情報を先に渡し、本当に探索が要る部分だけをClaudeに任せる形にしたことで、体感できるほどトークンの持ちが変わった。

context-modeはフックが有効な環境で最大約98%のトークン削減が見込めるとされる。

複数のAIが会話する様子を見せるだけのデモが多く、出来上がったファイルの作られ方や検証の通過状況をあとから追えなかった。

ログばかりが目立って成果物が脇役になっていた。

1. 一文の依頼からMasterが成果物と前提と依存関係を構造化出力で提案する
2. Runtimeが計画のスキーマや循環や担当や書込範囲や上限を先に検査する
3. 各Botに受信箱と作業領域を持たせ担当タスクと入力の参照だけを渡す
4. ReviewerがSHA-256のリビジョンに紐付けて検証し不合格ならBuilderが直す
5. 最終報告をモデルの要約ではなくイベントログから組み立てる

日本語の紹介LPとSNS投稿草案3案を頼んだ実行では、index.htmlやposts.mdなどが出てプログラム検証10件すべてがpassした。

Reviewer判定も6/6になった。

39ターンで$1.66、18分37秒で完了した。

77件のイベントログを無編集で公開している。

Claude Codeを本格的に使うと開発者1人あたり月200〜500ドル、時に2000ドルを超える費用がかかっていた。

質問に答えるため数千行のファイルを丸ごと読み込み、ほとんど使わない行まで課金される点が重かった。

1. 読み取りや定型生成を安いGemini 2.5 Flashに回す2つのモードを用意した
2. bulk-readerで大きなファイルを読ませ必要な情報だけ箇条書きで返させた
3. code-writerでテストや設定の雛形を作りファイルへ直接書き込んだ
4. プラグインshuntで350行超のReadを止めcatなど抜け道も塞いだ
5. 編集や深い推論や安全性が絡むコードはClaudeに任せた

Javaのモノレポで4つの場面を比べたところ、bulk-reader経由のときのClaude側のトークン消費は平均で約90%減った。

ただし委譲1回につき10〜30秒かかり、要約には正確な行番号が残らないため編集は任せられない。

電子請求書発行システム「楽楽明細」の新オプションを、実装に使える期間が1か月弱という条件で12機能ぶん作る必要があった。

要求仕様書は例外系や受け入れ条件が足りず、そのままAIに渡せる粒度ではなかった。

1. 決めた仕様をClaudeでプロトタイプ化し40社に見せて機能を約30%削った
2. 要件をEARS形式で1アクション単位に分け例外パスも書いた
3. kiro（cc-sdd）でspec化しエージェントに読ませた
4. Codexを主軸にgit worktreeで機能ごとに複数セッションを同時に走らせた
5. 一次レビューをGitHub CopilotとClaude Codeで出し人が二次で確認した

4月7日の開発決定から5月末リリースと実質2か月未満で出せた一方、12機能を1本のプルリクにまとめたため変更ファイルは700超、サーバーサイドのレビューは全量確認に5営業日かかった。

実装方針を決めきらなかったため同じ指摘を機能の数だけ受けた。

AIを知っている社員はいても自分でAIの仕組みを作れる人がいなかった。

使う側から作る側へ移すための学びの道筋が社内に無かった。

1. Udemyを土台にした社内のAIアカデミーを作った
2. 学びを2段階に分け前半でClaude Codeを扱う
3. 後半はエージェント型AIとMCPを学ぶ内容にした
4. 受講の進み具合を追い社内ハッカソンで手を動かして作らせた
5. 作ったものを他の部署でも使い回せる形にそろえた

視聴した学習時間は19,527時間になりAIアカデミーの受講者は879人に届いた。

ハッカソンからは再利用できるAIスキルが200以上生まれた。

顧客の開発者向けチームが同じような文書の質問への対応に追われていた。

コードの変更に文書が追いつかず、古いAPIの例が何週間も残ることがあった。

1. 複数のAIを比べ回答率と取り込み率でClaudeを選ぶ
2. 20万トークンの文脈へ文書一式をまとめて渡す
3. 質問には実際のAPIの定義を取りに行かせて答えさせる
4. コード倉庫を見張らせずれがあればプルリクを作る
5. Claude Codeで機能追加やテスト作成を進め人が直す

文書への質問の67%が人の手を介さずに解決し、1人あたりのコード量は3〜4倍になった。

要望から公開までは3〜4週間から1〜2週間に縮まり、顧客の継続率は15%改善した。

それまでのAIコーディングツールは1つのIDEの中の単一プロジェクトしか読めず、コードの移行でつまずいた。

開発者全員の生産性を上げる方法を探していた。

1. 社内に専任チームを作り少人数の試用から始めた
2. 評判が良かったものだけを全社へ広げた
3. 自社のスタイルガイドに沿ったテンプレートを用意する
4. Claude CodeをPRの流れに組み込み他のツールと比べた
5. 開発者は設計を決めて出力を確かめる側に回った

エンジニアの8割超が使うようになり、7割超が毎日使っている。

API実装は2日から5時間になり、1人あたり週7時間の削減になった。

経営判断の前に財務やマーケの数字を手作業で集める必要があり、集計に時間を取られていた。

複数のAIを動かすと誤った数字が報告に混ざる心配もあった。

1. Claude Codeを核に9体の役をMarkdownのfrontmatterで定義した
2. CFOは会計API、CTOはリポジトリとCIと一次データの担当を分けた
3. CEOは各役の報告を統合するだけにして数字の創作を防いだ
4. 連携はinbox・today・archiveの3つのYAMLで秘書役が管理した
5. 月次決算の手順はSKILL.mdにまとめコマンドで呼び出せるようにした

CEO役が常にダッシュボードを更新するようになり、経営者の時間を集計から判断へ移せた。

ただし運用期間は短く、安定稼働と言えるかは今後の実績待ちだと本人は述べている。

営業に付随する細かい作業が積み重なり、毎週まとまった時間を取られていた。

1. 営業に関わる19の業務を洗い出す
2. 洗い出した業務に取り組む順番を決める
3. 各業務をClaude Codeに任せる形へ置き換える
4. 空いた時間の使い道を事前に決めておく

週14時間55分かかっていた作業が週54分になった。

一方で最初の2か月は商談数が1件も増えなかった。

Jira・Salesforce・Confluenceなど多くのSaaSに情報が散らばり、担当者や過去の経緯を探すのに時間がかかっていた。

必要な文脈をつかむのにSlackのやり取りを何度もたどっていた。

1. GleanをJiraやSalesforceなどにつないだ
2. 一つの窓口で横断検索できるようにした
3. 利用状況を点検するエージェントを作った
4. 通話記録やメールから導入準備の情報を集めさせた
5. Glean MCPをClaude Codeにつなぎバグ修正に使った

アカウント監査は1件3〜4時間から10分になり、96%短縮した。

新規顧客の導入準備にかかる時間も90%減り、一部の顧客だけでなく全ての顧客を詳しく点検できるようになった。

社員がおらず、サイト制作や動画、経理の突き合わせといった作業を外に出すしかなかった。

中小企業のAI導入の話はうまくいった例ばかりで、実際にどこまで置き換わるのかが分からなかった。

1. コードを書かずに、やりたいことを言葉でClaude Codeに指示した
2. 作り直しの内容を伝えてホームページを自社で生成した
3. 机に並べた名刺をiPhoneで撮った写真12枚を渡してデータ化させた
4. 相手のサイトを読ませて法人向けメールを1社ずつ書かせた
5. 広告とLINEとサイトの数字をまとめた日報を毎朝8時30分に届かせた

外に出していた仕事をほぼやめ、少なく見積もって年300万円の外注費が消えた。

一方で無料で渡した業務用の道具8社分は誰にも使われ続けず、広告が6日間止まっていた期間は問い合わせが5件まで落ちた。

全社員にClaudeのTeamプランを配って個人の作業は速くなったが、各自が書いた手順書やスキルが個人の環境に閉じたままで会社の資産にならなかった。

さらに社員それぞれが業務アプリを動かすには保存や定期実行のできる本物のサーバが必要だった。

1. Claude Codeに切り替え1つのGitリポジトリへ文書とスキルを集約する
2. members/とteams/のディレクトリを作り個人の手順書を共有資産にする
3. アプリをCloudflareのWorkers for Platformsの上に置く
4. エージェントのコードは必ずPR経由で反映し履歴と巻き戻しを残す
5. 非エンジニアにはPRで確認用URLが出ることとマージで本番反映の2点だけ教える

非エンジニアが指示してClaudeが書いたアプリが、エンジニアの作るものと同じ厚みで本番を回すようになった。

エンジニア1人で作った基盤を5ヶ月運用し、社外APIの登録は40を超えた。

リサーチや資料作成、データ加工など小さな手作業が全社に散らばり、個別のシステム化がしにくかった。

AIを入れても使い方が個人任せだと、成果が人ごとの慣れに左右されてしまう。

1. 社員と業務委託の計59名に実行環境をそろえてClaude Codeを配る
2. 2026年7月から8月に全部門向け研修を行う
3. うまくいったやり方をスキルという手順書にして共有基盤へ登録する
4. 配色や書体やロゴの規定をAIが読める形に直す
5. 登録されたスキルをレビューして部門をまたいで共有する

2026年8月末までに45名の手で、手順書が743件、業務ごとのAIエージェントが127体たまった。

研修後の社内調査では、エンジニア以外の回答者のうち53％が毎日のように使っており、その中の69％が同じ成果物を作る時間は半分以下になったと答えた。

SEO記事はキーワード選びから競合調べや執筆をへて入稿まで工程が多い。

1本あたりの時間と費用がかさみ、外注すれば1記事数千円〜1万円かかっていた。

1. 人がキーワードを決め以降の工程をAIエージェントに渡す
2. 上位記事の見出し構成と文字数を調べH2/H3の構成案を作る
3. セクションごとに文字数を割り振り本文を書く
4. 11体のサブエージェントが観点別に並行で校閲する
5. 基準未達なら修正エージェントが直し再び校閲に回す

2025年から自社で回し続けた結果、月間3万PVを記録し複数のキーワードで検索上位を取った。

企業向け提供版のAPI利用料は100記事あたり約5万円前後が目安になっている。