Claude Codeは非IT企業にこそ効く—「作られなかったソフトウェア」を取り戻す話

初心者の方には、この説明が最も本質的です。

Claude Codeは、会社の仕事の手順を、コンピュータが繰り返し実行できる仕組みに変えるAIです。

コードとは、難しい英語の文字列のことではありません。本質的には「このデータを読み込む」「この条件ならこちらに分類する」「数字を集計する」「異常があれば担当者へ知らせる」「毎週月曜日に実行する」といった、コンピュータに仕事をさせるための具体的な指示書です。

Claude Code(Anthropic社のAIコーディングエージェント)は、会社やプロジェクト内のファイルを読み、コードやファイルを作成・修正し、実行し、動作確認まで進められます。MCPという仕組みで外部ツールやデータとも接続できます。文章としてコードを出すだけでなく、実際の作業環境の中で「読む・作る・動かす・直す」まで進められる点が重要です(基本の解説はClaude Codeとはにまとめています)。

チャットAIとの違いは、毎週の売上報告を例にするとはっきりします。

• 一般的なチャット利用: 人間がCSVを集め、AIにアップロードし、「集計して」と頼む。今週分の報告書ができる
• Claude Codeでの仕組み化: 各店舗からデータを取得→表記ゆれを修正→前週比を計算→異常値を検出→グラフと報告書を作成→指定フォルダへ保存→Slackで担当者へ通知——を、来週以降も同じ手順で動く形にする

つまり、チャットAIは「今回の成果物」を作り、Claude Codeは「次回以降も成果物が生まれる仕組み」を作ります。ウェブサイトを作れることは、この能力が分かりやすく見える入口にすぎません。

画像生成AIは、画像を作るコストを下げます。動画生成AIは、動画を作るコストを下げます。一方でコード生成AIは、会社が仕事を実行するための「生産設備」を作るコストを下げます。

画像生成が「広告画像を1枚作るAI」だとすれば、Claude Codeは「広告データを集める→効果の悪い広告を特定する→新しい訴求案を作る→画像生成AIを呼び出す→LPへ反映する→結果を計測する」という、画像生成AIを含んだ一連の業務システムそのものを作れます。

あらゆる業界で必ずコード生成のほうが重要とまでは言えません。ただ、画像や動画が「成果物」であるのに対し、コードは「成果物を生み続ける装置」になり得ます。反復・連携・蓄積が効く分、企業活動全体への影響は大きくなりやすいのです。

従来、会社が独自のシステムを作るには、エンジニアを採用するか開発会社へ依頼し、数百万円以上の予算と数ヶ月の期間を確保し、完成後も保守費用を払う必要がありました。だから多くの会社では、本当は改善したい業務があっても「月に何十時間かかる程度だから、システム開発するほどではない」と判断され、人間がExcelとメールで処理し続けてきました。

Claude Codeが変えるのは、この部分です。

• 3人だけが使う営業管理画面
• 月末だけ使う請求確認ツール
• 特定の取引先だけに必要な帳票
• 複数のSaaSをつなぐ小さな自動化
• 社内独自の判断ルールを反映したチェックツール

こうした「これまで採算が合わなかった小さな社内ソフトウェア」が作れるようになります。これまでの会社は、SaaSの仕様に人間が業務を合わせてきました。これからは、既存SaaSの間に会社独自の薄いソフトウェアをAIで作り、ソフトウェア側を会社の業務に合わせる方向へ変わっていきます。

「AIに文章を作らせる」のではなく、「業務そのものを仕組みにする」例です。

実際にAnthropicが公開している導入事例でも、Rampでは営業・リスク・経理・採用などの非技術職が自然言語で社内データを扱い、楽天では非エンジニアがコードを直接編集せずに開発へ参加し、Vercelではプログラミング経験のなかったマーケティング担当者が自部門の業務手順を再利用可能な部品(Skill)にしています。各社の導入報告なので効果をそのまま一般化はできませんが、用途がエンジニアに限定されていないことは確認できます。PwCも、対象を開発だけでなく財務・人事・保険引受・業務オペレーションへ広げています。

ここは非常に重要です。5年後、経理や営業の全員がターミナルを開いて操作しているとは限りません。Slackや社内画面から「昨日の未入金を確認して、担当営業別にまとめて」と頼むと、裏側でコードエージェントが処理して結果を返す形のほうが自然です。実際にAnthropicは、Slack上で接続されたデータを使って複数段階の仕事を実行するClaude Tagのように、コードエージェントを非開発者向けの画面へ広げ始めています。

したがって企業に必要なのは「全社員へのプログラミング教育」ではなく、次の3つの役割です。

中小企業では1人が複数を兼ねて構いません。重要なのは、会社の中に「業務とAIの間をつなげられる人」がいることです。

分かれ目は「非IT企業かどうか」ではありません。

効果が出やすいのは、毎日・毎週・毎月繰り返す仕事が多い、Excel・PDF・メール・SaaS間の転記が多い、会社独自の判断ルールがある、入力データがデジタルで取れる、正しい結果かを人間が確認できる、改善する業務の責任者がいる会社です。

逆に、業務ルールが担当者の頭の中にしかない、同じ仕事でも人によって正解が違う、システムからデータを取り出せない、作った後の責任者がいない、最初から完全自動化を求めている——という状態のままでは効果が出にくくなります。

なお、飲食・建設・介護・物流など現場が物理作業中心の会社でも、シフト管理・報告・発注・請求・顧客連絡・写真整理といった周辺の情報処理には大きな余地があります。Claude Codeが料理や建築をするわけではありませんが、その前後の事務と調整はかなり減らせる可能性があります。

この記事で一番お伝えしたい考え方です。企業におけるAIの成果は、モデル性能の単独では決まりません。

AIの成果 = モデル性能 × 業務の明確さ × データへのアクセス × 権限設計 × 結果を確認する仕組み × 現場の運用能力

どれかがゼロに近ければ、最先端モデルを渡しても成果は出ません。仮に5年後のClaude Codeが世界最高のエンジニアより優秀でも、「この会社では売上を税込・税抜どちらで扱うのか」「どのデータが正式な数字か」「例外的な値引きを誰が承認できるのか」「顧客への送信前に誰が確認するのか」は、会社側から教えなければ分かりません。世界最高の社員を採用しても、資料も権限も説明も渡さなければ仕事ができないのと同じです。

「高性能なAIを入れれば自動的に生産性が上がる」という期待には、反証もあります。独立研究機関METRが2025年初頭のAIツールで行った実験では、経験豊富な開発者が自分のプロジェクトで作業した場合、AI使用時のほうが平均19%遅いという結果が出ました。これは「AIが遅い」という意味ではなく、暗黙知や高い品質基準がある仕事では、モデル性能だけで成果が決まらないことを示しています。Anthropic自身の調査でも、複雑な仕事ほど成功率が下がりやすく、利用者側の指示や情報の質が出力品質と強く関係することが報告されています。

5年後に残る差は、AIを持っている会社と持っていない会社の差ではありません。AIが仕事をできる状態を作っている会社と、作っていない会社の差です。

モデル自体はいずれ誰でも使えます。プロンプトの上手さも、操作方法の知識も、数年で陳腐化します。本当に蓄積すべきは次の資産です。

これらを持つ会社は、モデルが新しくなるたびに性能向上をすぐ自社業務へ反映できます。持っていない会社は、モデルが進化するたびに「何に使えばいいのか分からない」から始め直すことになります。先取りする価値があるのは、ボタン配置を覚えることではなく、自社の業務を「AIが読める・動かせる・検証できる」状態に変えていくことです。

最初から経理全体や基幹システムを置き換えるべきではありません。最初の題材は、次の6条件で選びます。

1. 1月に何度も繰り返している
2. 2入力情報がデジタルで取得できる
3. 3手順を文章で説明できる
4. 4人間が短時間で正誤を確認できる
5. 5失敗しても取り返しがつく
6. 6業務責任者がいる

5つ以上当てはまれば良い候補です。逆に、自動送金・人事評価の確定・契約書の最終承認・大量の顧客への自動送信・データの完全削除のような不可逆で影響の大きい処理は、AIに準備をさせても最後は人間の承認を残してください。Claude Codeにはファイル変更やコマンド実行前の許可確認、細かな権限制御の仕組みがありますが、権限を持ったAIには誤操作や悪意ある指示の混入(プロンプトインジェクション)のリスクもあります。最小権限と人間承認を前提に設計するのが原則です(データの学習利用についてはこちらの解説も参照)。