「Claude Codeって、結局エンジニア向けですよね」。社内でそう言われて、話がそこで終わったことはないでしょうか。
名前にCodeが入っている以上、そう受け取られるのは自然です。ところが公式ドキュメントが並べている用途を読むと、Google Driveの設計書を読む、Jiraのチケットを更新する、Slackのデータを取得する、といった作業が同じ一覧に載っています。どれもコードを書く話ではありません。
この記事は、その食い違いを地図にします。任せられる仕事を4つの領域に分け、どこから渡すかを決める判断軸を4つ置き、最後に止める地点の作り方まで通します。根拠は公式ドキュメントと、運営元WEBMARKSが自分の環境で数えた実測です。
本記事の検証環境：claude-opus-5 / Claude Code v2.1.x / macOS 15 / 2026-07-28検証。常駐ジョブの本数だけは、2026-08-20に同じコマンドで測り直しました。
こんなふうに調べていませんか
- 「エンジニア向けの道具」と言われて、自分の部署では検討が止まっている
- 導入はしたものの、コード以外の何を頼めるのか分からないまま使っている
- 渡す業務を思いつきで選んでいて、確認のやり直しが減らない
この記事を読み終えたときに手に入るもの
- 任せられる仕事を4領域に分けて、自分の部署の該当箇所を指させるようになります
- 渡すかどうかを、判断軸4つで自分で決められるようになります
- 事故を止める地点を、任せる前に選べるようになります
結論30秒でわかる、この記事の結論
- Claude Codeの業務活用は、ファイル操作・外部ツール連携・非対話実行を組み合わせた実務全般に及びます。
- 広がる先は、資料作成・調査／定型業務の自動化／外部ツール連携／コード生成・開発の4領域です。
- 対外的に確定する操作は、コードを書かせるときと同じ地点で人に戻します。
進行役は3人です。若葉さん（Web担当2年目）が用語のそもそもを聞き、高梨課長が自分の手で動かす側の疑問を出し、鈴木さん（本誌監修）が答えます。近い立場の人の質問から読んでいただいて構いません。
01Claude Codeの業務活用は、AIエージェントに何を任せる話なんですか？
若葉さんClaude Codeって、名前のとおりコードを書く道具ですよね。業務活用と言われても、広報や経理が使う場面が思い浮かびません。
鈴木さん名前は入口の説明にすぎないんですよ。中でやっているのは、読む・直す・走らせる・つなぐ、の4つです。扱う対象がコードでなくても、同じ動きは効きます。
先に結論を置きます。
Claude Codeの業務活用は、ファイル操作・外部ツール連携・非対話実行を組み合わせた実務全般に及びます。広がる先は主に、資料作成・調査、定型業務の自動化、外部ツール連携（MCP・外部システムをAIに触らせるための共通の口）の3方向です。そして対外的に確定する操作は、コード生成のときと同じ人間ゲートで止めます。
公式ドキュメントは、Claude Code自身をエージェント型のコーディングツールと定義しています（出典: Claude Code公式ドキュメント）。コードベースを読み、ファイルを編集し、コマンドを実行し、開発ツールと連携する、という説明です。ここだけを読むと、対象は開発業務に限られるように見えます。
ところが同じ公式ドキュメントの「できること」一覧には、MCP連携の例が載っています（出典: Claude Code公式ドキュメント）。Google Driveの設計書を読み、Jiraのチケットを更新し、Slackのデータを取得できる、と書かれています。どれもコード編集とは別の使い方です。
つまり「コーディングツール」という説明と、実際に列挙されている用途のあいだにズレがあります。このズレを地図として整理するのが、この記事の役割です。読み終えると、自分の部署で最初に渡す業務を1つ選べる状態になります。
この章のまとめ
名前ではなく、動きで見ます。読む・直す・走らせる・つなぐ。この4つが効く業務は、コードの外にもあります。
02コード専用に見えるClaude Codeは、AI活用の候補からなぜ外れてしまうんですか？
外れる原因は、公式の「できること」一覧に並んだ作業の性質が読み取られていないことにあります。
一覧の先頭には、開発チームが後回しにしがちな作業が置かれています（出典: Claude Code公式ドキュメント）。テストの追加、lintエラーの修正、依存関係の更新、リリースノートの作成の4つです。
この4つは、見た目ほど均質ではありません。テスト追加とlint修正は完全にコード領域です。一方でリリースノートの作成は文章を書く作業であり、依存関係の更新はコード変更というより定型的な確認作業に近い性質を持ちます。入口の説明がコード寄りなだけで、扱う作業の性質はすでに広がっています。
同じページには、コミット作成やプルリクエスト作成の例も並びます（出典: Claude Code公式ドキュメント）。開発チーム以外の担当者がこの一覧だけを見ると、自分の業務との接点を見つけられません。「うちには関係ない」で終わるのは、読み手の判断が雑だからではなく、一覧の並びがそう読ませるからです。
読み替えの方法は単純です。作業の名前ではなく、作業の性質で並べ替えます。文章を書くのか、確認するのか、外の道具を触るのか。並べ替えたものが、次の章の4領域です。
03Claude Codeの業務活用は、AIエージェントに渡せる4領域でどう分かれるんですか？
公式に対応している業務を、性質で4つに分けます。
| 領域 | 公式が挙げる機能 | 世の中の代表的な使い方 | WEBMARKSの実例（2026-07-28） | 人が残す判断 |
|---|---|---|---|---|
| 資料作成・調査 | notes vaultやドキュメントフォルダなど、コード以外のディレクトリでも検索・編集・整理ができる | 議事録やマニュアルの整理、大きな文書群からの該当箇所抽出 | 本記事の執筆と原典照合に使用 | 採用するか |
| 定型業務の自動化 | Routines・デスクトップのスケジュールタスク・GitHub Actions・/loopでスケジュール実行できる | 毎朝のPRレビュー、依存関係の週次監査 | launchdジョブを8本定義し、うち1本が稼働中 | 稼働を続けるか |
| 外部ツール連携（MCP） | MCP経由でGoogle Driveの設計書・Jiraのチケット・Slackのデータへ接続できる | ログの異常をSlackへ通知、新規文言をCIで翻訳してPR化 | 特定SaaS連携は未導入（権限設計を先に固める段階） | 接続先を承認するか |
| コード生成・開発 | バグ修正・リファクタリング・テスト作成・コミットとPR作成 | エラーメッセージを渡すと原因を特定し修正案を出す | 姉妹メディアのサイトエンジンをフォークし設定を差し替える作業に使用 | マージ・公開するか |
（機能の欄はすべてClaude Code公式ドキュメントによります）
この表で見ていただきたいのは、右の2列です。同じ領域でも、世の中の代表例と自社の実例はそろっていません。外部ツール連携は公式にも世の中の事例にも載っているのに、WEBMARKSでは未導入です。権限設計と検証手順を先に固める段階にあるためで、これも実測できる事実の1つです。
4領域は独立していません。資料作成・調査で拾った事実が、定型業務の自動化やMCP連携の設計材料になります。逆にMCP接続を増やすほど、資料作成・調査で扱える情報源も増えます。
では、どの領域から渡すか。領域名で選ぶと迷います。渡しやすさは領域ではなく、繰り返す頻度と、出てきたものを確かめられるかで決まるからです。
自分の部署の業務を、この2軸に置いてみてください。右上に入ったものが、いちばん先に渡す候補です。
この章のまとめ
領域は「何を扱うか」の分類、順番は「どれだけ繰り返すか」と「確かめられるか」の話です。分類と順番を混ぜないでください。
04資料作成と調査は、Claude CodeでAI社員にどこまで任せていいんですか？
高梨課長資料作成に使うとして、実際の操作はどうなるんでしょう。ファイルを1つずつコピーして貼り付けるんですか。
鈴木さんいえ、場所を教えるだけです。@のあとにパスを書くと、その中身やディレクトリの一覧がそのまま渡ります。画像は貼り付けで済みますよ。
高梨課長それなら、フォルダごと渡したくなりますね。
鈴木さんそこが落とし穴なんです。渡した量は、そのまま文脈を食いますから。
基本の操作は2つです。@によるファイル参照と、画像入力です。@src/componentsのようにパスを書くと、ファイル内容やディレクトリ一覧を渡せます。スクリーンショットやモックアップ画像は、ドラッグ&ドロップかCtrl+Vで貼り付けられます（出典: Claude Code公式ドキュメント）。
引っかかるのは量です。大きな文書群を丸ごと読ませると、そのぶん文脈を消費します。公式ドキュメントは、調査だけをサブエージェントに任せると、要点だけが本体の会話に返ってくると説明しています（出典: Claude Code公式ドキュメント）。文脈を汚さずに調べものを進められる、という設計です。
任せてよい範囲は「検証すれば裏が取れる調査」までです。ここを越えると、確かめようのない結論が混ざります。
2026-07-28に、実際に混ざりました。社内の調査業務で、台帳の古い記録だけを根拠に、姉妹メディアAIO Journalを「1本も公開されていない」と報告した例です。実際には251本が公開済みでした（同日にsitemap.xmlで実測）。
原因は、要約結果を検証せずそのまま報告したことです。対策として、稼働や公開状況を否定する報告は、本番のURLで確かめてから出す手順を追加しました。調査の実務活用は、検証手順とセットにしてはじめて任せられます。
05Claude Codeで定型業務をAIエージェントに任せるかは、判断軸4つでどう決めるんですか？
渡すかどうかは、次の4つの軸で決めます。
| 判定軸 | 満たしている状態 | 満たしていない状態 |
|---|---|---|
| ①対象がファイルとして存在する | リポジトリ・ノート・ログなど、パスで指せる形になっている | 口頭説明や記憶だけが情報源になっている |
| ②正誤を機械的に判定できる | テスト・数値突合・チェックリストで合否が決まる | 良し悪しが読み手の感覚に左右される |
| ③繰り返し頻度がある | 週次・日次など同じ形の作業が反復する | 一度きりで終わる作業である |
| ④実行範囲を絞れる | 対象ディレクトリとツールを限定できる | 触ってよい範囲が特定できていない |
この4つは、並列に置かれたチェック項目ではありません。上から順に効きます。
①でつまずく業務は、②以降を考える意味がありません。渡す先そのものが指せないからです。②を満たさない業務も渡せますが、確認の手間は減りません。③が無ければ、型にする値打ちが出ません。④が決まっていない業務は、渡す前に範囲の設計が要ります。
途中で落ちた業務は「任せられない」ではなく、「その条件を先に整える」と読んでください。口頭で回している手順をファイルへ落とす。合否の基準を1行で書く。この作業そのものが、渡せる業務を増やします。
06Claude Codeの非対話実行とスキル化は、エージェントに任せた業務の何を変えるんですか？
高梨課長4条件を満たした業務は、毎回チャットで指示を打つんでしょうか。それだと担当者が替わったときに続きません。
鈴木さんそこから先は、打ち込まなくていい形に落とせます。段は2つあって、まずコマンドへ埋め込む。それでも足りなければ、手順そのものを型にします。
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へ全部書くより、コンテキスト消費を抑えられます。判断軸③の頻度が高い業務ほど、型にする値打ちは上がります。
変わるのは、担当者への依存度です。対話で回している業務は、指示の書き方を知っている人がいなくなると止まります。コマンドと型に落としておくと、手順が読める形で残ります。
この章のまとめ
非対話実行は「毎回打たない」ための段、スキル化は「毎回説明しない」ための段です。頻度が上がるほど、上の段へ移す値打ちが出ます。
07AI社員に任せて事故が起きたら、Claude Codeはどこで止まるんですか？
高梨課長範囲を絞ったつもりでも、うっかり本番のフォルダを触られたら困ります。止まるところはありますか。
鈴木さんあります。ただ、事故のあとに足す機能ではなく、任せる前に選ぶ設定だと考えています。どこで人に戻すかを先に決めておく、という話です。
4条件を満たしても、対外的に確定する操作は境界の外側に置きます。
Claude Codeのフックは、ツール実行の直前にPreToolUseが発火して判定します（出典: Claude Code公式ドキュメント）。判定はallow・deny・ask・deferの4通りで返ります。
送信・公開・削除・決済は、askまたはdenyで止める設計にできます。判断そのものを迷う場面には、実行前に計画だけを見せるplanモードもあります。ファイルは読みますが、承認するまで一切編集しません（出典: Claude Code公式ドキュメント）。
この章のまとめ
止まる場所は、実行の直前に置きます。あとから足す機能ではなく、渡す業務を決めた日に選ぶ設定です。
08Claude Codeの自動承認を広げると、AIエージェントに何が通ってしまうんですか？
止める側だけでなく、自動で通す側にも範囲があります。
acceptEditsは、ファイル書き込みに加えてmkdir・touch・mv・cpまで自動承認します（出典: Claude Code公式ドキュメント）。本番ディレクトリでこの設定を使うと、承認するつもりのなかった操作まで通ります。
やっかいなのは、設定名から受ける印象と、実際に含まれる範囲がずれることです。「編集を自動で通す」と読むと、対象はファイルの中身だけに見えます。ところが実際には、ディレクトリを作る、名前を変える、別の場所へ複製する、といった操作まで入ります。作業用のフォルダでは手数を減らしてくれる設定が、本番の階層では意味を変えます。
だからこの設定は、どこで使うかとセットで決めます。渡す業務の対象ディレクトリが決まっていれば、自動承認を広げてよい範囲もそこまでです。範囲が決まっていない状態で先に緩めると、④の実行範囲を絞るという条件が、あとから崩れます。
WEBMARKSは、送信・公開・削除・決済・契約を人間の直接判断に固定しています。業務活用の範囲を広げるほど、境界線をどこに引くかの設計が先に要ります。
09Claude Codeの業務活用で、AI社員の分担はどう分けているんですか？
自社での業務活用は、この記事自体の制作工程にも表れています。
| 工程 | 担当 | Claude Codeでの使い方 | 人が持つ判断 |
|---|---|---|---|
| 執筆 | AI社員（執筆役） | 構成の作成と本文のドラフト | 公開前の確認 |
| 原典照合 | AI社員（検証役） | 公式ドキュメントへのアクセスと事実確認 | 引用の妥当性の最終判断 |
| 批評 | AI社員（批評役） | 規約との突合と差し戻し指摘 | 差し戻すかどうかの最終判断 |
| 監修 | 鈴木晋介（人間） | ― | 公開の最終承認 |
分けている理由は、確認の回数を増やすためです。1体に全部を任せると、書いた本人が自分の出力を確かめることになります。役を分けると、次の担当が前の担当の出したものを見てから引き継ぎます。
WEBMARKSは2026-06-24に7部署・30体の役割定義を統合しました。姉妹メディアAIO Journalの公開URLは251本です（2026-07-28にsitemap.xmlで実測）。分担そのものは、この統合の枠組みの上に載っています。
10AI導入でつまずく5つの落とし穴は、Claude Codeのどこに出るんですか？
若葉さん先に失敗の形を知っておきたいです。よくあるのは、どんなつまずき方ですか。
鈴木さん入口と出口に集まります。入口は「うちには関係ない」と決めてしまう形、出口は「動かしたつもりで点検を止める」形ですね。
- 「コード生成ツールだから」と最初から対象外にする：公式の「できること」一覧はMCP連携や非対話実行まで含みます。読まずに判断すると、任せられる業務を見落とします。
- MCP接続を増やしすぎて影響範囲の見直しを忘れる：接続先が増えるほど、読み書きできる範囲も広がります。接続を1つ足すたびに、権限設計を点検し直します。
--bareを使わずCI・スクリプトを組む：--bareを付けないと、フックやMCPサーバーが読み込まれます。実行環境によって結果が変わる原因になります（出典: Claude Code公式ドキュメント）。acceptEditsを本番ディレクトリで常用する：ファイル書き込みと一部のシェルコマンドが自動承認されます（出典: Claude Code公式ドキュメント）。確認したい操作まで、そのまま通ってしまいます。- 定型業務にしたつもりで、点検を止める：設定ファイルを書いた事実と、いま動いている事実は別に数えます。
5つ目は、自社でも起きました。次の章で、実際に数えた結果をそのまま出します。
この章のまとめ
落とし穴は入口と出口に出ます。入口は読まずに対象外にすること、出口は点検を止めることです。
11定型業務を任せたあと、Claude CodeのAI活用が続いているかはどう数えるんですか？
数えるのは、設定ファイルの側ではなく実行の側です。書いた本数と、いま動いている本数は、別々に数えます。
WEBMARKSは常駐ジョブの稼働をlaunchctlで数えています。2026-07-28の時点では、定義8本に対して稼働中が1本、残り7本は定義済みで検証待ちでした。自動再開パトロールの最終実行も、その時点で2026-07-13のまま止まっていました。
同じコマンドを2026-08-20に流し直すと、定義20本に対して読み込み済みが16本です。差が縮んだのは、新しい仕組みを足したからではありません。書いたまま読み込んでいなかったものを、入れ直した結果です。
数え直さなければ、この動きには気づけません。定型業務は設計して終わりにせず、稼働を実測し続けてはじめて実態のずれに気づけます。
自社で始めるときも、同じやり方で足ります。定義の数と、読み込まれている数を別々に数えるだけです。その差が、書いたのに動いていない本数になります。
この章のまとめ
書いた本数と、動いている本数は別々に数えます。同じコマンドを日を変えて流すだけで、ずれは見えます。
12Claude Codeの業務活用を始める前に、AI導入の何を点検しておくんですか？
ここまでの内容を、着手前に自分の業務へ当てるための項目にまとめます。「いいえ」が1つでもあれば、着手ではなく、その条件を整えるほうを先に進めてください。
- 対象の業務は、ファイルやリポジトリなどパスで指せる形になっているか
- 結果の正誤を、数分から同日のうちに機械的に判定できるか
- 同じ形の作業が週次・日次で繰り返し発生しているか
- 実行範囲を対象ディレクトリとツールに絞れるか
- 送信・公開・削除・決済を含む工程が混ざっていないか
- CI・スクリプトでの実行に
--bareを使っているか - 自動承認の範囲（
acceptEdits等）を、対象ディレクトリに合わせて絞ったか - MCP接続を追加するたびに、権限設計を点検し直しているか
- 稼働している定型業務を、月に一度は実際に動いているか確認しているか
上の4つは判断軸そのもの、続く3つは止める地点の設計、最後の2つは点検の習慣です。この並びのまま一度通せば、渡す業務と渡さない業務の線は自分で引けます。
13よくある質問
Claude Codeの業務活用は、非エンジニアの部署でも現実的ですか
現実的です。@によるファイル参照や画像の貼り付けは開発知識を要さず、ノートやドキュメントのフォルダでもそのまま使えます。ここまでは部署を選びません。ただしMCP接続や-pでのスクリプト化になると、settings.jsonの権限設計ができる担当者が設定を見直す工程が入ります。非エンジニアの部署で始めるときは、使う人と設定を見る人を分けておくと止まりにくくなります。
最初に任せる業務は、どう選べばよいですか
本記事の4条件をすべて満たす業務から始めます。ファイルとして存在する、正誤を判定できる、繰り返し頻度がある、範囲を絞れる、の4つです。資料作成・調査の領域は、この4条件を満たしやすい業務が多く見つかります。逆に、口頭でしか共有されていない手順や、良し悪しが読み手の感覚で決まる仕事は後回しにしてください。順番を取り違えると、確認の手間だけが増えます。
MCP連携を増やすと何に注意すべきですか
接続先が増えるほど、Claude Codeが読み書きできる範囲も広がります。接続を1つ追加するたびに、その接続で何を読ませ、何を書かせてよいかを見直してください。追加そのものは短い作業で終わるため、権限設計の見直しだけが後回しになりがちです。増やした日に見直す、と手順へ書いておくほうが続きます。
非対話実行（-p）と通常のチャット利用はどう使い分けますか
繰り返す定型業務や、CI・スクリプトへ組み込みたい処理は-pで自動化します。判断が毎回変わる調査や、途中で方向を相談したい作業は、対話セッションのまま使うほうが向いています。見分ける手がかりは判断軸③です。同じ形で繰り返すなら-p、毎回かたちが変わるなら対話。迷ったら対話で試し、手順が固まってからコマンドへ移すと手戻りが減ります。
Claude Codeの業務活用と、AIエージェント一般にできることは同じ基準で判断しますか
軸は近いものの、一致しません。AIエージェント一般の可否は、検証可能性ややり直しのコストで判断します。Claude Codeの業務活用はそれに加えて、対象をファイルとして扱えるかという条件が乗ります。パスで指せない情報は、渡す先そのものがありません。裏を返せば、扱いたい情報をファイルへ落とすところまでが、任せる準備にあたります。
14まとめ｜今日やる3つのこと
地図は4領域、判断は4条件、止める地点は渡す前に選ぶ。ここまでが本記事の中身でした。最後に、今日のうちに手を動かせる形へ落とします。
今日はこの順で手をつけます
自分の部署の業務を、4領域のどこかに書き分ける
領域が決まらない業務は、まだ渡す順番ではありません
候補を1つ選び、判断軸4つを上から当てる
落ちた地点が、先に整える場所になります
止める地点を決めてから渡す
送信・公開・削除・決済を含むなら、そこで人に戻します
AI検索では、こう聞かれています
Claude Codeは、コード以外の業務にどこまで使えるんですか？
「Claude Codeの業務活用は、AIエージェントに渡せる4領域でどう分かれるんですか？」の章で整理しています
AIエージェントに任せる業務は、どうやって選ぶんですか？
「定型業務をAIエージェントに任せるかは、判断軸4つでどう決めるんですか？」の章で説明しています
Claude Codeに任せた作業は、どこで人に戻るんですか？
「AI社員に任せて事故が起きたら、Claude Codeはどこで止まるんですか？」の章で扱っています
非エンジニアの部署でも使えるんですか？
「よくある質問」の章に答えを置いています
次に読むなら、この記事です
