Claude Codeという名前から、コードを書く道具だと思われがちです。しかしClaude Codeの業務活用は、資料作成・調査・定型業務にまで伸びています。本記事は4領域の仕事の地図と、任せる判断軸4つを、公式ドキュメント7件と自社の実測（2026-07-28）から整理します。

検証環境：claude-opus-5 / Claude Code v2.1.x / macOS 15 / 2026-07-28検証

01結論：Claude Codeの業務活用は、コード生成の外側にこそ伸びている

結論は3点です。

  1. Claude Codeの業務活用は、ファイル操作・外部ツール連携・非対話実行を組み合わせた実務全般に及びます。
  2. 広がる先は主に、資料作成・調査、定型業務の自動化、外部ツール連携（MCP）の3領域です。
  3. 対外的に確定する操作は、コード生成のときと同じ人間ゲートで止めます。

Claude Codeの公式ドキュメントは、自身をエージェント型のコーディングツールと定義しています（出典: Claude Code公式ドキュメント）。具体的には、コードベースを読み、ファイルを編集し、コマンドを実行し、開発ツールと連携すると説明します。この定義だけを見ると、対象は開発業務に限られるように読めます。

同じ公式ドキュメントの「できること」一覧には、MCP連携の例が載っています（出典: Claude Code公式ドキュメント）。Google Driveの設計書を読み、Jiraのチケットを更新し、Slackのデータを取得できると書かれています。MCPは外部ツールとAIをつなぐ標準規格で、コード編集とは別の使い方です。

つまり「コーディングツール」という説明と、実際に列挙されている用途のあいだにズレがあります。このズレを地図として整理するのが本記事の役割です。読み終えると、自分の部署で最初に任せる業務を1つ選べる状態になります。

02なぜコードを書く道具に見えるのか、業務活用が遅れてきた理由

Claude Codeという製品名自体が、対象を開発者に限定しているように見せます。公式ドキュメントの「できること」一覧の先頭は、開発チームが後回しにしがちな作業です（出典: Claude Code公式ドキュメント）。具体例は、テストの追加・lintエラーの修正・依存関係の更新・リリースノートの作成です。

この4つのうち、テスト追加とlint修正は完全にコード領域です。一方でリリースノートの作成は文章作成であり、依存関係の更新はコード変更というより定型的な確認作業に近い性質を持ちます。入口の説明がコード寄りなだけで、扱う作業の性質はすでに広がっています。

同じページには、コミット作成やプルリクエスト作成の例も並びます（出典: Claude Code公式ドキュメント）。開発チーム以外の担当者がこの一覧だけを見ると、自分の業務との接点を見つけられません。次章のマップは、この接点を可視化するために作ります。

03Claude Codeの業務活用マップ｜4つの仕事領域

Claude Codeが公式に対応する業務を、4つの領域に分けます。

領域公式機能（出典）世の中の代表的な使い方WEBMARKSの実例（2026-07-28）人が残す判断
資料作成・調査notes vaultやドキュメントフォルダなど、コード以外のディレクトリでも検索・編集・整理ができる（Claude Code公式）議事録やマニュアルの整理、大きな文書群からの該当箇所抽出本記事の執筆と原典照合に使用採用するか
定型業務の自動化Routines・デスクトップのスケジュールタスク・GitHub Actions・/loopでスケジュール実行できる（Claude Code公式）毎朝のPRレビュー、依存関係の週次監査launchdジョブを8本定義し、うち1本が稼働中（2026-07-28実測）稼働を続けるか
外部ツール連携（MCP）MCP経由でGoogle Driveの設計書・Jiraのチケット・Slackのデータへ接続できる（Claude Code公式）ログの異常をSlackへ通知、新規文言をCIで翻訳してPR化特定SaaS連携は未導入（権限設計を先に固める段階）接続先を承認するか
コード生成・開発バグ修正・リファクタリング・テスト作成・コミットとPR作成（Claude Code公式）エラーメッセージを渡すと原因を特定し修正案を出す姉妹メディアのサイトエンジンをフォークし設定を差し替える作業に使用マージ・公開するか

4領域は独立していません。資料作成・調査で拾った事実が、定型業務の自動化やMCP連携の設計材料になります。逆にMCP接続を増やすほど、資料作成・調査で扱える情報源も増えます。

コード生成・開発だけが「未導入」ではなく実例がある一方、MCP連携は自社では未導入です。理由は権限設計と検証手順を先に固める段階にあるためで、これも実測できる事実の1つです。

Claude Codeの業務活用を、頻度と検証しやすさの2軸でどう仕分けるか Claude Codeの業務活用マップ。横軸は繰り返し発生する頻度、縦軸は結果の正誤を検証できるかを表す2軸マトリクス。定型レポート作成は頻度が高く判定しやすいため任せやすい領域、経営判断や対外送信は頻度が低く判定も難しいため人が持つ領域に入る。資料の下書きとMCP経由の外部データ取得は条件つきで任せる領域に位置し、実線は実行範囲を絞れること、破線は範囲が未確定であることを示す。 MATRIX Claude Codeの業務活用マップ Claude Codeに任せやすい頻度も高く、判定もしやすい 定型レポート作成 条件つきで任せる低頻度でも検証はしやすい 資料の下書き 条件つきで任せる頻度は高いが判定が難しい MCP経由の外部データ取得 人が持つ頻度が低く、判定も難しい 経営判断・対外送信 低い 高い 繰り返し発生する頻度 結果の正誤を検証できるか 実線＝実行範囲を絞れる 破線＝実行範囲が未確定 右上に近いほど任せやすいが、実行範囲を絞れているかも合わせて見る
Claude Codeの業務活用マップ

04資料作成・調査に使う実務活用と、任せてよい範囲

資料作成・調査での実務活用は、@によるファイル参照と画像入力の2つが基本操作です。@src/componentsのようにパスを書くとファイル内容やディレクトリ一覧を渡せます。スクリーンショットやモックアップ画像はドラッグ&ドロップかCtrl+Vで貼り付けられます（出典: Claude Code公式ドキュメント）。

大きな文書群を丸ごと読ませると、そのぶん文脈を消費します。公式ドキュメントは、調査だけをサブエージェントに任せると、要点だけが本体の会話に返ってくると説明しています（出典: Claude Code公式ドキュメント）。文脈を汚さずに調べものを進められる、という設計です。

任せてよい範囲は「検証すれば裏が取れる調査」までです。2026-07-28、社内の調査業務で台帳の古い記録だけを根拠に、姉妹メディアAIO Journalを「1本も公開されていない」と報告した例があります。実際には251本が公開済みでした（2026-07-28にsitemap.xmlで実測）。

原因は、要約結果を検証せずそのまま報告したことです。対策として、稼働や公開状況を否定する報告は、本番のURLで確かめてから出す手順を追加しました。調査の実務活用は、検証手順とセットにしてはじめて任せられます。

05定型業務での使いどころと、任せる判断軸4つ

定型業務での使いどころを判定する軸は、次の4つです。

判定軸満たしている状態満たしていない状態
①対象がファイルとして存在するリポジトリ・ノート・ログなど、パスで指せる形になっている口頭説明や記憶だけが情報源になっている
②正誤を機械的に判定できるテスト・数値突合・チェックリストで合否が決まる良し悪しが読み手の感覚に左右される
③繰り返し頻度がある週次・日次など同じ形の作業が反復する一度きりで終わる作業である
④実行範囲を絞れる対象ディレクトリとツールを限定できる触ってよい範囲が特定できていない

4条件を満たす業務は、非対話実行（-pフラグ）でスクリプト化できます。公式ドキュメントの例では、ビルドログをパイプで渡して原因を要約させたり、差分を渡して誤字を指摘させたりします（出典: Claude Code公式ドキュメント）。

{"scripts": {"lint:claude": "git diff main | claude -p \"you are a typo linter. for each typo in this diff, report filename:line on one line and the issue on the next. return nothing else.\""}}

このpackage.jsonの例は、Claude Codeを誤字チェッカーとしてスクリプトに組み込んでいます（出典: Claude Code公式ドキュメント）。標準入力からの取り込みは、v2.1.128以降10MBが上限です（出典: Claude Code公式ドキュメント）。

同じ手順を毎回貼り直している場合は、スキル化も選択肢です。SKILL.mdを1つ作ると、本文は使うときだけ読み込まれます（出典: Claude Code公式ドキュメント）。CLAUDE.mdへ全部書くより、コンテキスト消費を抑えられます。③の頻度が高い業務ほど、スキル化の価値が上がります。

業務をClaude Codeへ任せてよいかを判定する4段階のフロー 業務をClaude Codeへ渡すかどうかを判定する分岐フロー図。対象の業務から①ファイルとして存在するか②正誤を機械的に判定できるか③繰り返し頻度があるか④実行範囲を絞れるかの4段階を順に確認し、いずれかを満たさなければその場で人が持つへ分岐する。4段階すべてを満たした場合だけClaude Codeへ業務活用として任せるへ進み、非対話実行でスクリプト化するか対話セッションで都度実行するかに分かれる。④の判定が甘いと自動承認で想定外の操作まで通る注意点も添える。 BRANCH 業務をClaude Codeへ渡すかの判定フロー 対象の業務 ①対象がファイルとして存在するか ②正誤を機械的に判定できるか ③繰り返し頻度があるか ④実行範囲を絞れるか Claude Codeへ業務活用として任せる 非対話実行でスクリプト化する 対話セッションで都度実行する 人が持つ4条件のどれか1つでも満たさなければここへ ④の判定が甘いと想定外の操作まで自動承認される 4段階すべてを満たした業務だけが、次の運用の選び方まで進む
業務をClaude Codeへ渡すかどうかを判定する分岐フロー図

06コード生成に戻ってくる場面と、業務活用の境界

4条件を満たしても、対外的に確定する操作は境界の外側に置きます。Claude Codeのフックは、ツール実行の直前にPreToolUseが発火して判定します（出典: Claude Code公式ドキュメント）。判定はallow・deny・ask・deferの4通りで返します。

送信・公開・削除・決済は、askまたはdenyで止める設計にできます。判断そのものを迷う場面には、実行前に計画だけを見せるplanモードもあります。ファイルは読みますが、承認するまで一切編集しません（出典: Claude Code公式ドキュメント）。

非対話実行での自動承認にも境界があります。acceptEditsは、ファイル書き込みに加えてmkdir・touch・mv・cpまで自動承認します（出典: Claude Code公式ドキュメント）。本番ディレクトリでこの設定を使うと、承認のつもりがなかった操作まで通ります。

WEBMARKSは送信・公開・削除・決済・契約を人間の直接判断に固定しています。業務活用の範囲を広げるほど、境界線をどこに引くかの設計が先に必要になります。

07自社での業務活用実例｜AGI Journal制作の3分担

自社での業務活用は、この記事自体の制作工程にも表れています。

工程担当Claude Codeでの使い方人が持つ判断
執筆AI社員（執筆役）構成の作成と本文のドラフト公開前の確認
原典照合AI社員（検証役）公式ドキュメントへのアクセスと事実確認引用の妥当性の最終判断
批評AI社員（批評役）規約との突合と差し戻し指摘差し戻すかどうかの最終判断
監修鈴木晋介（人間）―公開の最終承認

WEBMARKSは2026-06-24に7部署・30体の役割定義を統合しました。姉妹メディアAIO Journalの公開URLは251本です（2026-07-28にsitemap.xmlで実測）。

設定ファイルを書いた事実と、いま動いている事実は別に数えます。WEBMARKSは常駐ジョブの稼働をlaunchctlで毎回実測しており、2026-07-28時点で稼働中は1本、残り7本は定義済みで検証待ちだと把握しています。自動再開パトロールの最終実行は2026-07-13です。定型業務は設計して終わりにせず、稼働を実測し続けてはじめて実態のずれに気づけます。

自動化ジョブは定義8本のまま、実測1本になるまで何が起きたか WEBMARKSの自動化タイムライン。2026-06-24にAI社員30体・7部署が稼働を開始し、常駐の自動化ジョブは8本と定義された。この定義は自動再開パトロール最終実行日の2026-07-13まで変わらず、2026-07-28の実測ではロードされていたのは1本のみだった。2026-07-13から2026-07-28までの15日間を「点検が止まっていた空白期間」として帯で強調し、定義と実測のズレが広がった期間を示す。出典：WEBMARKS社内実測（2026-07-28）。 TIMELINE 常駐ジョブ、定義8本に対し実測1本 8 常駐ジョブの定義値 1 実測でのロード数 1 2 3 2026-06-24 AI社員30体・7部署が始動 2026-07-13 自動再開パトロール最終実行 2026-07-28 本記事の実測日 点検が止まっていた空白期間 経過15日間 定義8本と実測1本のズレは、点検停止の15日間に広がった 出典：WEBMARKS社内実測（2026-07-28）
WEBMARKSの自動化タイムライン

08業務活用でつまずきやすい5つの落とし穴

  1. 「コード生成ツールだから」と最初から対象外にする：公式の「できること」一覧はMCP連携や非対話実行まで含みます。読まずに判断すると、任せられる業務を見落とします。
  2. MCP接続を増やしすぎて影響範囲の見直しを忘れる：接続先が増えるほど、読み書きできる範囲も広がります。接続を1つ足すたびに、権限設計を点検し直します。
  3. --bareを使わずCI・スクリプトを組む：--bareを付けないと、フックやMCPサーバーが読み込まれます。実行環境によって結果が変わる原因になります（出典: Claude Code公式ドキュメント）。
  4. acceptEditsを本番ディレクトリで常用する：ファイル書き込みと一部のシェルコマンドが自動承認されます（出典: Claude Code公式ドキュメント）。確認したい操作まで、そのまま通ってしまいます。
  5. 定型業務にしたつもりで、点検を止める：WEBMARKSの自動再開パトロールは、2026-07-13を最後に実行が止まっています。設計した業務活用と、実際に動いている状態は別物です。

09Claude Code業務活用チェックリスト｜9項目で今日から点検する

  • 対象の業務は、ファイルやリポジトリなどパスで指せる形になっているか
  • 結果の正誤を、数分〜同日で機械的に判定できるか
  • 同じ形の作業が週次・日次で繰り返し発生しているか
  • 実行範囲を対象ディレクトリとツールに絞れるか
  • 送信・公開・削除・決済を含む工程が混ざっていないか
  • CI・スクリプトでの実行に--bareを使っているか
  • 自動承認の範囲（acceptEdits等）を、対象ディレクトリに合わせて絞ったか
  • MCP接続を追加するたびに、権限設計を点検し直しているか
  • 稼働している定型業務を、月に一度は実際に動いているか確認しているか

10FAQ

Claude Codeの業務活用は、非エンジニアの部署でも現実的ですか

現実的です。@によるファイル参照や画像貼り付けは開発知識を必要とせず、ノートやドキュメントフォルダでもそのまま使えます。ただしMCP接続や-pでのスクリプト化は、settings.jsonの権限設計ができる担当者が設定を見直します。

最初に任せる業務は、どう選べばよいですか

本記事の4条件（ファイルとして存在する・正誤を判定できる・繰り返し頻度がある・範囲を絞れる）をすべて満たす業務から始めます。資料作成・調査の領域は、この4条件を満たしやすい業務が多く見つかります。

MCP連携を増やすと何に注意すべきですか

接続先が増えるほど、Claude Codeが読み書きできる範囲も広がります。1つ接続を追加するたびに、その接続で何を読ませ何を書かせてよいかを見直します。

非対話実行（-p）と通常のチャット利用はどう使い分けますか

繰り返す定型業務や、CI・スクリプトへ組み込みたい処理は-pで自動化します。判断が毎回変わる調査や、途中で方向を相談したい作業は、対話セッションのまま使うほうが向いています。

Claude Codeの業務活用と、AIエージェント一般にできることは同じ基準で判断しますか

軸は近いものの一致しません。AIエージェント一般の可否は、検証可能性ややり直しのコストで判断します。Claude Codeの業務活用はそれに加えて、対象をファイルとして扱えるかという条件が加わります。